Braintree is one of the most forward thinking payment providers out there. A good number of startups on HN have integrated with them (we have, too). They have an excellent policy about porting customer data (e.g., stored credit card numbers) when moving to a different provider. Amazing customer service overall.
I'm not sure Braintree is being all that different.
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.
For merchants processing less than 1-2k a month, Braintree probably is a bit more expensive (~$50 a month) but I think it's worth it, knowing you'll get great customer service, clean APIs, bundled services, data portability, and no hidden fees. For me it's a no brainer.
@bshep: A bit offtopic, but how has your experience been with PayPal so far?
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.
You might want to consider Beanstream -- they're based out of Victoria and offer services broadly similar to Braintree (data vault for CCs, etc).
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.
>I can't afford to go with Braintree, and I'm not quite sure they even deal with Canadian companies.
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.
FWIW I've been quite pleased with PayPal, both standard and "pro." They get a bad rap (somewhat deserved), but for ease of setup and low barriers to entry, they're the best I've found.
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.
I've also had a good experience with paypal. I've also tried google wallet (much cheaper) but google does not allow for subscriptions which I need for my business.
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.
Have you ever integrated PayPal in a way that requires a PayPal account for purchase (ie: turning the "PayPal account optional" setting off)? How many people bounce when they have to pay with their PayPal account? I was looking into their Adaptive Payments API, but it requires both sender and receiver(s) to have a PayPal account. I'm not sure if that's a good idea.
They also require a 3 year contract where if you go out of business before then they require you to pay thousands in monthly minimums (read the ENTIRE contract before signing up). They claim to be very startup-friendly, but really their terms are not that great.
I've heard great things about their service, but I found CDGCommerce to have much better terms.
We (Braintree) have no contracts and no termination fees. Merchants can leave whenever they want and for whatever reason without penalty. Some of our sponsoring banks unfortunately have cancellation fee language (that we don't control and are trying to get removed) but we provide an addendum to every customer that states they will never be responsible for any cancellation fees.
I see on your application page that you have that addendum. I'm sorry for the incorrect statement, the rep I worked with last year didn't do a good job of communicating requirements (also was very inflexible with monthly fees).
I will be sure to keep Braintree in mind for my next venture
Braintree has gone out of their way to help my company out, they are extremely startup friendly.
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.
It seems kind of lame to beg the incumbents to make it easy for you to poach their customers. The big evil guys have their customers by the balls. It's safe to assume there's no way they're going voluntarily let go.
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.
Yeah no doubt. And maybe this is really the best way to get things started. It definitely isn't enough though. Anymore than The Gimp guys asking the CEO of Adobe to make Photoshop save files in XCF format.
I'm one of those angry former customers. You can yell at PayPal all you want but you won't get that data.
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.
I got frightened by all the PCI DSS fear that permeates this board. I assumed you guys had it all figured out, and to a man, you seem to all be of the same mind on this issue. Fear, fear, fear.
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.
Funny. I have a friend in the 'business', he does a very substantial amount of volume every year. I've helped a bit coding the now mandatory 'VBV' component for their system.
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.
There were a pile of supporting document as well regarding all the different encryption protocols that you have to support because the various banks could not agree on a single one.
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.
I respectfully suggest that you undergo a 3rd party Type 1 PCI audit....
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.
One what? One person who's actually undergone multiple type 1 PCI audits? :)
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.
I note you sidestepped the question that you had been audited by (as they put it so nicely) a "Qualified Security Assessor" to complete your "Report On Compliance" ?
Well, I have to admit, I am certainly not a 6,000,000 transaction per year merchant, which is when I would need a level 1 audit that you and your friend so gleefully salivate over. I wish I was! If I was, I think it very reasonable to audit your processes to insure security.
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".
One thing at the time here. Lennart, my buddy does indeed do well over 6M transactions per year, so a level 1 audit is his lot. Technically his company (vxsbill.com) is an IPSP, not a merchant. But because he has the requirement anyway all the merchants that he works with and for benefit from the secure facility that he offers.
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.
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.
I'm not aware of how exporting the credit card data stored in the databases of these companies could ever be valid under PCI compliance rules.
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.
Braintree is great for bringing this issue to light. I've personally been hurt by the lack of portability and have seen it affect several other companies. Here is Recurly's response:
At some point, your customer's card expires, and you need to ask them to re-enter their details. New details -> new provider. It might take two years to migrate most of your clients - even if it isn't ideal, it's not like you're locked in forever.
Not directly related, but we (Braintree) recently blogged about credit card expiration dates. Here is a snippet: "If you run a transaction in our gateway and enter a date in the past for the credit card expiration date, you may be surprised to discover that we don't validate it. We run the transaction knowing that the card is expired. Why do we do this? The short answer is that financial institutions will still approve transactions with expired expiration dates."
Not true. Dirty little secret - you can roll forward the expiration on a credit card with impunity. The expirations are because the magnetic strips wear, not for any security.
This is cute. Not even Chargify or Recurly support[1] the "standard" (as far as I know), and they have vaults! Show me a list of other gateways that support the standard, and then maybe you can get the big boys on board.
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.
Just to clarify, we at Recurly will gladly return your credit card data to you (in a secure fashion) if you decide to migrate away. I've been burned before by Authorize.NET holding my business' credit card data hostage and I wouldn't wish that on anyone. We'll be posting more on this shortly.
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.
The problem: not many people actually switch payment processors. Once you get with Auth.Net, you spend a lot of time negotiating better rates with different companies, but your Auth.Net gateway stays the same.
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.
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.
I have fun questions:
Who is the target audience for this letter? What is it trying to achieve? How effective is this letter in its current state in a) reaching the target audeience and b) achieving its goals?
If braintree cares this much about this, why don't they allow people who use authorize.net currently to store their credit cards in the braintree vault?
