Paypal and Authorize.net: Help End the Credit Card Hostage Situation
braintreepaymentsolutions.com
braintreepaymentsolutions.com
Most of the bigger providers care more about their own interests than those of their customers.
I've heard nothing but good things about them ... except that their minimum transaction level is high enough many/most/all??? startups can't meet it. So the latter obviously go to Paypal and when/if larger Auth.net.
Braintree is asking those companies to make it easier to "graduate" to Braintree. Since Braintree provides one of the highest quality services in this field, they're obviously not worried about too many customers defecting, or at least not until they get so big they bring it in house.
Which in the current startup capital climate is going to be very rare, I suspect.
I think you hit the nail on the head.
I just looked at their pricing and we cant afford them, so we are stuck with paypal for now.
By the time we grow enough we will be locked into paypal.
I'm investigating payment gateways for a SAAS offering (I'm based in Canada), and despite all the negativity surrounding PayPal, it seems to be the easiest way to go. I can't afford to go with Braintree, and I'm not quite sure they even deal with Canadian companies.
For one customer (a music festival) I set up paypal integration for ticket sales three years ago and haven't had to change anything since.
The only thing with paypal is that if they decide your business is somehow in a legal gray area they will take your paypal balance and you have very little recourse. At least this is what I have always heard in Paypal horror stories.
IIRC, it is possible for a Canadian company to use Braintree and other US based payment processors, but you need: a) A US EIN number b) A US chequing account
The US chequing account is easy -- you can get that through Harris (www.harrisbank.com). They are actually a subsidiary of BMO, and so are used to opening US accounts for Canadian individuals and companies. You can work with them entirely by mail/e-mail (including the account opening process). I know foreign companies can apply for an EIN -- but it's not something we've done, so I can't speak from experience there.
There's a link (it's an ajaxy modal window or I'd give the link) on their pricing page for people outside of the US. If you don't have a legal US presence "you can work with one of their partners for a merchant account" but you have to be "processing at least 3 million in volume or will meet those thresholds within 12-18 months." So even less of an option.
I'm glad to see them trying to make moves like this. It's one of the reasons that our business is with them.
I've heard great things about their service, but I found CDGCommerce to have much better terms.
I will be sure to keep Braintree in mind for my next venture
My customer service rep at Braintree handles regular billing inquiries and has also helped me with some coding issues - that speaks volumes in my book.
They need angry former customers to do the talking. Maybe this raises awareness a bit, but what really resonates is horror stories. A few high profile former Authorize.net/PayPal customers that are angry and willing to tell people about it would probably go much further.
The sweet begging approach isn't likely to work.
Honestly, I think there needs to be some regulation here, since there's just no incentive for the large incumbents to change.
From a security perspective, it's a huge disservice to the consumer. It's a great thing to not worry about storing card details in your application. The auth.net/paypal policies incent anyone using those providers to store those details anyway to ensure portability.
When I actual Read the F----ing Manual about this ...., actually read that what was required was peanuts compared to the thousands of posts and comments I've read here pontificating on how to safely store a freaking password to a dating site, I am perplexed. How can a group of people who can talk your arm off for two hours about salts, rainbow tables, hashes, and password entropy, be frightened of PCI? https://www.pcisecuritystandards.org/security_standards/pci_...
I store my own credit card info. Exactly how I do it is none of your business, as, while I don't rely on obscurity for my security, I'd be foolish to deny myself it's added protection. I don't just meet PCI standards, which are easy, I greatly, greatly, exceed them. Why anybody would use a third party billing company is not mysterious, but why somebody who reads HN would do so, is strange to me.
I already know the comments I'll get for uttering such blasphemy. I would respectfully request that you actually spend 10 minutes reading actual PCI DSS guidelines before doing so, however.
The amount of legal and policy documentation you are required to have is by itself a massive undertaking. The 3rd party audit will cost $150,000-$300,000 and a huge amount of man hours.
Encrypting the credit card is the smallest part of it (although the number of people who actually pull off the encrypted key, key pieces kept by different people/systems, etc... is low). The networking, server, secure audit/logging to a dedicated server, patch within 90 days, policy documents, and so on are the hard parts.
In fact, I am a level 4 merchant, to my shame, so I have not spent money having an expensive "Certified QSA Security Consultant" audit my systems. I would remind everybody, that, sadly, they are probably level 4 merchants as well, unless they do over 20K transactions a year. Even if you do more than 20K,you're not in the scary big leagues till you get to 6M transactions.
Finally, I'd like to note that we hear a lot about these "possible fines", in theory, but have you heard of any in real life? I assume they must exist, but I invite you to read about the Heartland data breach, which exposed over 130 million credit card numbers. You'll note they still haven't been fined, but they "may be fined over $150K".
If you are a level 4 merchant, so less than 20K transactions per year (which sounds like a lot but really is only about 55 transactions per day, which I've already crossed over all by myself) then you could theoretically roll your own, but you are setting yourself up for a big fall if there ever would be a breach of security involving your site. And you'll still be paying access fees to a gateway, or have you found a way around that?
As for your 'theoretical fines', the two biggest instances that I remember wrecked the companies involved, the first one involved a company called Dacotah Marketing and Research, one of the largest internet billing companies during the .com boom, the second involved iBill.com, which you could probably qualify as their successor.
Both of these companies offered 'third party billing', which is one thing you are at least staying away from.
But if VISA doesn't care about blowing 10K+ merchants to kingdom come by fining an IPSP that does not abide by their rules out of existence, you certainly are not going to be felt any more than a gnat would be felt if a car ran over it.
They really don't care about individual merchants at VISA or MC, and to work with a large to mid sized IPSP will have a significant advantage in that effectively you are bundling your negotiation powers against the card issuers.
This will help during acceptance, charge back issues, merchant account revocation for some imaginary sleight and so on (you did check if you have permission to run those logos, did you get it in writing?).
Last but not least, working through an IPSP rather than 'rolling your own', no matter how satisfying is that you get the benefit of a large pool of knowledge on scrubbing and pre-authorization checks to make sure that your customer is legit. But of course you've never had a fraudulent charge.
I don't know much about the Heartland data breach, other than what I read in the media so I'll decline to comment on that.
Let me close this bit with that 100 days ago you didn't know about PCI at all (http://news.ycombinator.com/item?id=1092224) and now you are the expert in the field and will tell people that they should just roll their own because you slapped something together and it worked - so far.
Me, I'll be leaning on a decade+ of experience and a couple of very dedicated employees to make sure that my money keeps rolling in, and that my customers data does not get compromised. There is only so much time.
I also don't make my own computer chips, circuit boards, and so on. I've found it to be un-economical to do so and the same logic is what stops me from rolling my own billing solution.
Incidentally, I'm the original author of 'webpay', the software that powered the first major IPSP, so it's not as though I wouldn't have an idea where to start, but some things require a whole lot more dedication than I'm willing to spend on it to do it right.
http://web.archive.org/web/19980507122555/http://mattheij.nl...
cheers!
edit: afterthought, you may be talking cross purposes when you compare the $150K that Hearland might be fined to the most common kind of fine, the chargeback penalty. If you haven't had a chargeback yet then I urge you to read up on this and why scrubbing is so important, especially if your volume is low a single group of unfortunately timed chargebacks can kill your merchant account, depending on your contract the permissable percentages can be as low as 0.7% of the volume in the running month, the latter is a real problem is there is a temporary change in volume on your website. I'll leave it up to you to figure out why that is a problem.
If he did get an audit and passed I'll eat my proverbial hat.
The spec was about 400 pages, it took weeks to read it and digest it to find out that it was relatively simple to implement.
This work gave me some insight in what goes on behind the scenes to get those deceptively simple rules from that page that you link put in to practice.
On paper, it's very easy to be PCI compliant. The problem is that in practice it really isn't all that easy. The auditing firms that will verify that you are indeed PCI compliant (you did request an audit?) are not going to sign off on this on a lark, they want really hard proof.
The nasty ones are requirement '9', anything short of a cage at a provider with biometric access protection and a whole host of other measure simply isn't going to do. That alone will outweigh the costs for most small time merchants of doing this by themselves.
Requirement '6', '7', '10', '11' and '12' are beyond the capabilities of most small business to implement anyway.
A guy like cperciva (and you, by your moniker) could probably do it in their sleep but I think you're the exception, not the rule.
It's fairly easy to miss a trick or two, the consequences would be pretty grave, the cost of outsourcing it is actually not that bad so that's the way most people will choose to go.
I'm not saying that a lot of consultants aren't out there, making a crap load of money. Hmmmmm.
Also, that's not the VBV documentation but an entirely different thing you are linking to there.
PCI compliance and VBV have little to do with each other, you could be PCI compliant without implementing VBV, but if you implement VBV you probably should be PCI compliant otherwise you will not be using it.
"Dear guys who are bigger than me: please make it easier for me to steal your customers."
They say it is, but I don't think it is up to braintree to say that it is, it would be up to the issuers to say that it is, and as long as they don't come out on the subject nobody is going to risk getting fined 10 million bucks or so by VISA or MC (or worse, to get shut down) to find out.
Braintree should probably do it's best to lower the barrier to entry to their services rather than to try to create a portability layer with competitors that don't care. And then braintree could give the right example by allowing merchants to take their data with them to other providers of payment services.
Note that just as you can't 'export' from Paypal or authorize.net you also can't simply 'import', the reason for that is that bulk import with random 3rd parties is extremely risky, it bypasses all the safeguards that have been installed to prevent all kinds of fraud.
http://www.braintreepaymentsolutions.com/blog/credit-cards-a...
I used to work in politics. This is the sort of poke-the-giant thing that longshot candidates do, and it actually ends up reflecting more negatively on Braintree than anyone else. It's a tone-deaf PR move from a great company.
EDIT: Looks like Chargify sends the CC details to the gateway and they don't have their own vault: http://chargify.com/features/pci-compliant-security/
I'm really happy that Braintree is pushing this forward. I've seen it hurt several companies when they need to switch gateways or merchant accounts.
Isaac Recurly, CEO
I could see data portability being an issue in the long run, but for now, with Auth.net being basically one of two gateways, not enough moving around happens for their to be a "call for portability" (that will actually be heard).
I do, though, applaud a forward-thinking move like this. It may be looked back on as the small spark that got the fire going.
(My startup.)
Seriously, the industry has no incentive to change. They make a killing. Merchant contracts are strict and likely forbid alternative standards such as the one being proposed here.
How about a flat $0.25 per transaction?