

Introducing Braintree.js - europa
https://www.braintreepayments.com/braintrust/braintree-js?&partner_source=jsannouncementemail&utm_source=et&utm_medium=email&utm_campaign=jsannouncement

======
jspaur
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)

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.

~~~
nthj
About time is right. I had to use Transparent Redirect for a high-volume-sales
app recently (couldn't use Stripe for legacy reasons), and the experience was
frustrating, error-prone, and didn't fit well within "the rails way",
requiring a lot of custom code that would have just worked with Stripe.

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.

~~~
vailripper
How recently was this? I used the CSE encryption library instead of
transparent redirect in my implementation, and it wasn't bad at all.

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?

~~~
cosgroveb
I explain this in a comment that's a bit further down the page but here it is
in a nutshell:

* 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.

------
jared314
Direct Source Link: <https://github.com/braintree/braintree.js>

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/>

[1] <http://www-cs-students.stanford.edu/~tjw/jsbn/>

[2] <http://www.w3.org/TR/WebCryptoAPI/>

------
joloko
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.

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.

~~~
juskrey
Balanced has no-brainer API and next day payout.

------
mb123
Wasted a month with braintree, creating sample forms etc

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

~~~
nahname
Yea, I wish I knew that we would be dealing with Moneris by choosing to use
Braintree in Canada. The signup process quickly switched from, not much
different from stripe to not much different from paypal.

------
just2n
> Braintree retains the private key of the key pair so that merchants are
> unable to decrypt the encrypted fields server-side.

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.

~~~
michaelfairley
Braintree.js cuts down PCI scope as much as tokenization. We've worked with
banks and auditors to make sure that this doesn't add any headaches for our
merchants.

~~~
nahname
What canadian merchant does stripe use? I was very close to using Stripe, but
active merchant didn't provide what we needed through your API (pre-
auth/settlement). I hope to use Stripe for other things down the road though.

------
thetrumanshow
Edit: Nvm, they don't tokenize with the data. How did I miss that...

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.

------
ricardobeat
What happens if someone gets his hands on the private key from braintree and
then breaks into your server? What are the views on PCI compliance?

~~~
michaelfairley
We recommend that you don't store or log credit card data encrypted with
Braintree.js.

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).

------
pbreit
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.

~~~
Silhouette
_However I bet Stripe takes advantage of data that it's getting ... such as IP
address, useragent, cookies or really anything Stripe would want to bake into
the JavaScript._

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.

~~~
someone13
I can't speak to anything like IP or user agent, but they're not doing
anything with cookies. You can put their JS code:

<https://js.stripe.com/v1/>

Into a JavaScript beautifier:

<http://jsbeautifier.org/>

And see that there's no mention of cookies at all, and, their server won't see
cookies from another domain.

~~~
pbreit
Do cookies need to be explicitly referenced in code or do they just come along
with the request? The cc processor is only interested in its own cookies, not
the merchants'.

------
MichaelGG
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.

Or was it in a "beta" and now this is a final release? Or am I missing
something big here?

~~~
cosgroveb
Hi Michael,

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.

~~~
Osiris
Thanks for the explanation. I've also been using v1.1.1 for a while now and
the release notes weren't particular enlightening as to the differences. I
don't plan on changing our workflow since it's working and tested, but I did
change the link to the JS file from our servers to yours.

------
justinph
We use this where I work. Passed several million dollars through it last year.
Works pretty good.

------
samwillis
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.

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.

