Introducing Braintree.js
braintreepayments.com
braintreepayments.com
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.
The worst part about Transparent Redirect is that you can't run any server-side callbacks (like confirming inventory is still available) at the point of sale, you have to run it when they first load the checkout page. Why? Because by the time the checkout page data hits your server, Braintree has already charged the customer's card. If you need to abort the transaction at that point it's frustrating at best.
Maybe there's a really obvious way to work-around that but multiple emails to their developer support weren't helpful.
With Stripe, you can run callbacks and validations all day long and you'll never capture your customer's money until you explicitly say "do it." Much cleaner.
There are only a couple options available in the situation you describe. First, you could vault the card before you charge it. Not great. Extra code, and you may not really want to store the card after the sale (depending upon your use-case). The other work-around, while not involving the vault may even be worse. If you don't want to vault the card, you could issue a void after confirming TR if something went awry (or say you're out of stock).
This is why we're really excited about getting Braintree.js into people's hands. It eliminates an extra round-trip for the customer to a third-party which is necessary with tokenization or TR. You can validate the form data before you decide to initiate the sale. It's really simple, too.
I'm actually a bit confused by this announcement, as it looks essentially the same as their existing client side encryption solution that they've had for at least a year?
* You're right that this is very similar to our previous offering. At its core, the encryption logic is the same.
* While both libraries offer an object which will encrypt your data, that's literally all our previous offering did. New helpers used in conjunction with data attributes eliminate the need to write custom onSubmit handlers, making your integration far simpler.
* We host the JavaScript, making linking directly to it an option.
These things make our JavaScript library substantially easier to use. That, plus the fact that we now recommend Braintree.js over Transparent Redirect motivated us to rebrand it.
We'd be happy to offer a discount for businesses on track to charge over $1M/year. Simply email us at support@stripe.com
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.
[0] http://crypto.stanford.edu/sjcl/
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.
Also it seems that Braintree has much more experience and established. If it's good for 37signals, it's good enough for me.
had to submit a rediculous amount of personal and business information (6 year old company in western europe), passport scans, bank statements etc
only to be refused (by their bank apparently) since hosting is somehow "risky" nowadays
despite having 5+ years of profit and 6 figure turnovers
their loss, if you are in europe dont waste your time with braintreepayments
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.
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).
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?
It's all so terrible. I'd rather just use bitcoins or something.
The first place I saw this code pattern was of course at Stripe, but I would be happy to learn that it predates them.
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.
As far as PCI compliance, Braintree.js minimizes your PCI scope as much as tokenization. As long as you serve your site over SSL and maintain adequate security around access to servers, administrative passwords, etc., when using Braintree.js, you'll fall under SAQ A (the lowest possible PCI scope for online merchants).
They'd better not be. That would be a serious violation of the merchant's trust in incorporating external JS from Stripe, not to mention introducing privacy and data protection concerns that could be deal-breakers for even using Stripe at all.
With the recently announced UK beta, it would be reassuring to see someone from Stripe pop up here and categorically deny that they do (or ever will do) anything in their externally-supplied JS other than the tokenization that is why merchants load it.
Into a JavaScript beautifier:
And see that there's no mention of cookies at all, and, their server won't see cookies from another domain.
I don't care for your attempt to scare an entity away from doing something quite reasonable.
Tracking us all over the Internet is useful, if you're a spammer who wants to hassle everyone to buy their junk all the time. Most of us don't like spammers, either.
The privacy concerns should be minimal.
Please correct me if I'm misunderstanding you, but you appear to be advocating the collection of arbitrary information, via a third party script downloaded from an external source, in the middle of a payment process where sensitive credentials are in use, without necessarily giving notice to either the customer or the merchant about what is being done.
I normally prefer to make logical arguments and cite real data in this kind of discussion, but I genuinely don't know how to respond to the suggestion that this has minimal privacy concerns.
I don't care for your attempt to scare an entity away from doing something quite reasonable.
You and I have very different ideas of what "quite reasonable" means. Indeed, this "quite reasonable" behaviour seems to be illegal on several different grounds here in the UK, and as a merchant I would worry not only that I could not trust any third party service doing it to treat my customers well but also that they could get my own business caught up in at best dubiously legal activities without us even doing anything. That sort of ambiguity/distrust is toxic and grounds for staying far away from any such service.
Do you actually have any evidence that Stripe is in fact doing this kind of thing, or were you just stirring up trouble?
Or was it in a "beta" and now this is a final release? Or am I missing something big here?
Braintree developer here. You're right that Braintree.js is based upon our end-to-end encryption library. While that's been out of beta for some time, it was strictly for encryption (that's literally the only thing it did).
In this iteration we've added some helper methods to the Braintree object that make it much easier, in our opinion, to encrypt your payment form. In the past, if you wanted to use our encryption library, you had to intercept the POST to your server with a custom onSubmit handler to encrypt the data. Now, it's as simple as giving the id of the form you wish to encrypt and substituting the "name" attribute on your form inputs with "data-encrypted-name".
Additionally, unlike our previous encryption library, we're now hosting the JavaScript in our datacenter using the same highly available infrastructure we built for our gateway. This makes it easier to get up and going when you're spiking out your integration.
Ultimately, we felt that these improvements justified re-branding the library, especially since we now recommend Braintree.js over Transparent Redirect. Transparent Redirect unfortunately made it kind of awkward if you wanted to do your own server-side validation on the form data or do anything with AJAX.
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.