Hacker Newsnew | comments | show | ask | jobs | submit | cosgroveb's comments login

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.


Sorry to hear you had a rough time with Transparent Redirect. Having fielded quite a few e-mails on this very issue, I'd say it's possibly the biggest limitation with TR.

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.


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.


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.


The link to "helpful info from a redditor" about calling representatives is not-so-ironically blacked out.


What's exactly what you'd expect if SOPA passes.


At least they didn't provide a one-line install from a non-https server, too.

Just use "curl http://www.example.com/install_this.sh | sudo sh"!


Google Closure Tools is not the same thing as Clojure.

A little confusing I am sure since Closure Templates is a templating system that dynamically generates HTML in Java and JavaScript... And Clojure is a language that targets the JVM.

I have no experience with Closure Tools but Clojure is awesome definitely.


ClojureScript uses Closure Tools: https://github.com/clojure/clojurescript/wiki/Google-Closure


Either the author of the comment I replied to ninja edited his comment or I need to work on my reading comprehension. I think it was the first thing though...


So not being sexist makes an industry boring? Maybe we need to throw in some racism and make things even more edgy!


What slides from the presentation were sexist?


"So not being sexist makes an industry boring?"

No, but being self-important and all-too-cautious and "professional" makes it.


Well I think you're right...but this "culturism" that you talk about has something to do with the fact that Indians from India are not inherently very good at managing people or software projects.

It's not racism if it's true!


Hypothesizing that a trend could be explained by cultural differences is different than discriminating on race.


I'd be interested to know the stats on how many people have had overdraft fees and never let it happen again (or seldom) vs. those who get them routinely.

It's happened to me. Once. Never again.


FDIC studied it in 2006:


They state that the sampling wasn't random and shouldn't be extrapolated, but for the banks with automated overdraft protection that they studied closely, 4.9% of customers had 20 or more overdrafts per year and paid 68% of all non sufficient funds fees collected by the banks. An additional 4% of customers had between 10 and 19 overdrafts and paid about 16% of the fees (so as a group, people with more than 10 overdrafts a year paid 84% of overdraft fees).

The people with 20 or more overdrafts averaged about $1,500 a year in overdraft fees.


I know a guy who was a broker on Wall Street throughout the 80's and 90's... He retired to take over the family farm, the sort of thing a lot of his peers wanted to do, and after 10 years of working non-stop to almost-not-quite break-even he's almost ready to sell it.

He says that he had no idea how much harder than working on Wall Street it would be. He's got to know everything about the domain, he's got to know accounting, sales, marketing, and just about every other aspect of running a business and it is exhausting for such small potential gains.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact