Given they're active on the list in question and while the content crossed a line, the style was not out of character, nor was it later claimed to have been posted by somebody else, so I think we can rule this out.
Why not publish the offending emails? As it is, those who threatened you face no repercussions. Their tactic worked, and they have every incentive to visit abuse upon others in the future.
Edit: Thank you. I was under the impression that the emails were addressed specifically to you, not a mailing list.
They're on debian-devel, and I'm sure the hivemind fill find them quickly enough, but sure: https://lists.debian.org/debian-devel/2014/05/msg00585.html (and yes, they got pushback, but it took approximately that much until people said WTF).
Thorsten has always been a jerk. I don't think systemd is a new trigger, but it's interesting to see him show up (though I'm not surprised). He used to haunt the OpenBSD lists a decade ago, but was basically sent packing after all his "contributions" were rejected.
I get zero chargebacks via Google and struggle to find anything that's comparable?
I've got the usual horror story behind PayPal (that cost a lot) and Stripe does not have adequate anti-fraud.
At the moment Amazon Payments seems to be a worthwhile competitor (they guarantee no chargebacks related to fraud) however their service is much harder to integrate. Although plenty of humans in the mix which is a very nice touch.
As a merchant, this is why Bitcoin is so valuable.
Google was handy because their policies weren't overly restrictive - perhaps this is what sunk the digital goods api... Stripe is wonderfully easy to set up but doesn't allow integration for certain types of app e.g. telecoms (I understand that this is because of retrictions banks have placed on them).
Trustworthy Bitcoin payment processors are tricky to find. The stripe approach to this does give the lowest amount of customer friction imo (i.e. options to convert usd to btc on the spot) but the market restrictions and the beta status make it a non starter for now.
That would only help if the customer had enrolled in it (since it's completely optional). It just makes it more difficult for customers to contest fraud transactions, so why would anyone enroll?
From my understanding is that it lets the customer's bank see exactly who's making the payment and gives them a chance to deny it. The merchant is then protected from fraudulent chargebacks and these are covered by the bank.
Essentially, they get to perform their own fraud prevention and it's a way of trying to improve confidence in online payments.
I believe the idea that it takes away rights from the customer is a misconception (I also think most of these protections are given by law).
I heard years ago that Level 3 were trying to encourage people (non-customers?) not to use these DNS servers. I guess this is one way to ask people not to use them.
Having said that, 8.8.8.8, Google DNS, has been planted firmly in my memory as my go to "is this machine up?" IP.
My issue is that level3's dns has always been very fast, and more importantly, up... When google's dns is slow, level3 is fast... when my isp's dns goes down or wonky, level3's is up... I'd pay them $10/year to use them without the ads.
And then they have your entire history of internet activity, matched to you name, address and CC number. Fine if all you want is reliablility. For those who want to imped surveillance it is as bad as the ISP.
@karlshea was responding to @tracker1 who said that he/she would pay for the service. If someone is already willing to pay for the service, then I doubt this their major concern. You responded as if @karlshea was ignoring some requirement of the parent post...
Earlier today I received a phone call from a number in Mountain View CA. It was Google letting me know in advance that Google Checkout was to be shut down (and asking to keep the call quiet). This was, to say the least, very surprising considering I have very little correspondence with Google Checkout and was actually thinking there was a huge problem with my account. Thankfully not but this is still bad news for myself and I presume the industry at large.
Google Checkout was very good with their fraud protection to the point that I did not have to think about it. In fact, over the years I have been growing my business Google have been my rock---never a real issue with them.
PayPal was a similar story but it also seemed to attract the sort of customer that would open a dispute at almost any issue (or just threaten it). You can also count me in one of their horror stories that indirectly cost me £5k and even got to the point where they just flat out refused refunds for my customers who wanted them.
I have a Stripe and GoCardless account as well and I've been trying to make it work but their fraud protection is just not up to scratch compared to Google and PayPal, which is a real shame. I'm not sure if I'll ever be able to see enough data to get quite the same fraud protection. Stripe do look fun though.
Another perspective from a merchant: roll on Bitcoin. With exchanges offering guaranteed payouts in another currency (for me, GBP) I take on zero risk by accepting it and it solves so many problems. There's no wonder more and more websites are starting to accept it.
Definitely a third party service. Then place the bumper sticker "No Bitcoins on our servers" somewhere :)
I integrated MtGox and BitPay. Compared to Google Checkout (XML mania) and PayPal (documentation drama) they take about 5 seconds to implement (test is another thing entirely).
I went with MtGox in the end since it was cheaper. I was then happy to offer a 3% discount to make up for the fees users got stung with purchasing BTC. However MtGox has a number of bugs that make it a show stopper for some customers.
If you ask the right questions they will acknowledge the bugs and tell you they are working on it and need plenty of time. I would probably not use MtGox if I had known about the bugs prior to integrating.
Just wanted to public thank you for detailing your experience as a merchant, setting up with MtGox and BitPay.
Just curious, would you give BitPay a second look?
Obligatory: I'm currently using MtGox and haven't really had the time to try BitPay, but the MtGox legal issues could be a reason to need a second option.
Coinbase! I'm not with YCombinator, who is invested in Coinbase, but I checked out Coinbases API and they KEY WORDING: as a merchant accepting it, you're not subjected to the volatility of Bitcoin's exchange rate, if your batch at the end of the day is $1k you can expect that.
I'd personally go with Coinbase (we're going to add it shortly), since they have probably the best API.
All of the Bitcoin options suffer from a long delay between "oh, I want to use your product/service" and "can pay", if your user doesn't already have bitcoin. As long as 5 days.
What I'd recommend, if you're selling a service, is to do a 15-30 day trial AND take Bitcoin (or give someone free initial service IFF they pay with bitcoin, if you don't do demo anyway), to give them a chance to get started immediately. Unless you're shipping a physical product, losing 5 days of service if someone's bitcoin payment doesn't happen isn't a big deal, usually.
"The concept is simple: Google Wallet is an app, rather than just a website or an integration via MasterCard’s PayPass. It’s an actual payment app that lives on Android devices. Users can sign in using their Google+ username and account, and then pay for online purchases directly via the app."
In the manager you can select the netboot / PXE option and "boot from rescue mode". From there you get e-mailed the logins from the server booted onto a Debian rescue image. You have full access to the OS / hard drives.
I personally feel this is a really minor problem (if that!)
I found my personal phone number appearing on customer bank statements as a Stripe merchant. That's a bigger deal than exposing an e-mail address, but it's still a minor issue.
Do you know how Google Checkout solves this? It explicitly states what's public information to buyers so I can make the decision of what I'm exposing.
Sorry this wasn't clear! I can imagine it was a shock to have your number appear; I'll make sure we make this clearer when signing up.
For some background: it's a card network rule that you include a customer service phone number; this is intended to help reduce confusion with your customers and to ensure they have an opportunity to reach out to you. Since Google is an aggregator, they may include a phone number they control if you choose to not expose your own.
One approach you might consider is to have your phone number respond with a message suggesting users email you or visit a certain page on your website. The important bit is just that your customers have a clear way to get in touch with you.
Have you considered providing this data to merchants? For example, it would be great to know if you do get any calls for customers (or my prospective customers) and to see roughly what they're asking.
That way the merchants can act on the data too (and hopefully reduce the number of customer calls).
Tim from GoCardless here - that's a really cool idea.
We'll look into it for sure, and we'd definitely consider down the line releasing more general data about what our merchants' customers call us about. We think it's really important to help those using us to optimise their integrations.
It would probably be best not to perpetuate these things and to just end the vitriol now.