Frankly about time. We evaluated Braintree and just couldn't get over the amount of information requested to get started as compared to Stripe. Secondarily, we reached out to a member of the sales team and got a fairly curt response about their 1,000 startup initiative. Mix it with disjointed API docs (that appears to be better than it was 3 months ago, but not by much), and it wasn't even a decision. (And this is coming from someone who had opened a merchant account in 2003 over the phone with a previous startup)<p>It's all really a bummer because we'd love to see some serious competition in this space, but at the moment no one appears to be up to the task.
Direct Source Link: <a href="https://github.com/braintree/braintree.js" rel="nofollow">https://github.com/braintree/braintree.js</a><p>Neat, it uses the Stanford Javascript Crypto Library[0] and jsbn[1] to do all the encryption in javascript. I guess this is a good stopgap until the WebCryptoAPI[2] gets adopted.<p>[0] <a href="http://crypto.stanford.edu/sjcl/" rel="nofollow">http://crypto.stanford.edu/sjcl/</a><p>[1] <a href="http://www-cs-students.stanford.edu/~tjw/jsbn/" rel="nofollow">http://www-cs-students.stanford.edu/~tjw/jsbn/</a><p>[2] <a href="http://www.w3.org/TR/WebCryptoAPI/" rel="nofollow">http://www.w3.org/TR/WebCryptoAPI/</a>
I just signed up to post this comment and upvote, out of sheer excitement. I also upvoted Stripe.I was blown away by Stripe's dead simple API, I mean they put it right in your face, and it works.<p>However, the deal breaker for me was Braintree's two business day payout. I hope this still applies for Braintree.js. However, if somebody can convince me otherwise then I'm willing to listen. I'm just super stoked for both services.<p>Also it seems that Braintree has much more experience and established. If it's good for 37signals, it's good enough for me.
Wasted a month with braintree, creating sample forms etc<p>had to submit a rediculous amount of personal and business information (6 year old company in western europe), passport scans, bank statements etc<p>only to be refused (by their bank apparently) since hosting is somehow "risky" nowadays<p>despite having 5+ years of profit and 6 figure turnovers<p>their loss, if you are in europe dont waste your time with braintreepayments
> Braintree retains the private key of the key pair so that merchants are unable to decrypt the encrypted fields server-side.<p>This sounds cool, but at risk of being slightly off-topic, IIRC, this is still in scope of PCI. Storing encrypted data (even if you don't have the ability to decrypt it) falls under some rules in PCI compliance.<p>This is all hand-wavy of course. I had to comb through so many pages of PCI compliance documentation, rules, definitions, etc when working as a sys admin to create actionable plans on getting PCI compliant before we'd actually be audited. I remember this because I found it absolutely inane that it required storage of encrypted materials be stored as if they were sensitive but was fine with transmitting credit card #s over untrusted networks and the internet as long as they were "strongly" encrypted (this wasn't qualified, either).<p>Im really thankful we have people trying to simplify this headache for people, but why are we content letting this be our problem? It can easily cost hundreds of thousands of $$ PER SITE to become PCI compliant (which has, from what I've seen, been insufficient to protect the information anyway). Is there any proposed legislation that would force these companies (VISA, MC, Discover, etc) to adopt a fundamentally secure transaction system? Right now they're content with shoving all costs to third parties and ignoring theft because everyone has to be insured.. why isn't there severe outcry over this? It's wasteful on the magnitude of billions a year, I'm sure, and despite its brokenness, they STILL charge for every transaction. Sure, engineering around the problem creates a niche for companies like Braintree and other payment gateways to fill, but that's really just shifting a cost that shouldn't exist from one place to another. Why?<p>It's all so terrible. I'd rather just use bitcoins or something.
Edit: Nvm, they don't tokenize with the data. How did I miss that...<p>The first place I saw this code pattern was of course at Stripe, but I would be happy to learn that it predates them.<p>I also have a little service that attaches to web forms and does interesting things with the data in a similar way. It also scrapes the form at submission time just like Stripe and Braintree do. Nothing malicious in case you were thinking it.
Interesting approach. On one hand, I like that it avoids the initial round-trip to a third party server. However I bet Stripe takes advantage of data that it's getting that Barintree may or may not be (or at least not reliably) such as IP address, useragent, cookies or really anything Stripe would want to bake into the JavaScript.
How is this new? We've had a Braintree client side library ("Braintree End-to-End Encryption Library") to do exactly this for at least a year. File is even called braintree.js.<p>Or was it in a "beta" and now this is a final release? Or am I missing something big here?
There is a potential security flaw in their suggest html and js implementation. If the user is browsing with js turned off or the Braintree.js library doesn't load the cc information will be submitted to the server unencrypted. You really should exclude the action attribute from the form to stop the form submitting and add the action back in after encryption.<p>Edit:
It's not quite a bad actually, did see all the code as on small phone. As they exclude the name attribute from the cc inputs they won't be included in the submission, I think it's still worth excluding the action until the form has be verified by js to not included any unencrypted data though.