Braintree V.Zero SDK – Faster integration, drop-in UI, and pay with PayPal | Hacker News Reader

Braintree V.Zero SDK – Faster integration, drop-in UI, and pay with PayPal

braintreepayments.com

76 pointsdrewolson30 comments

And what happens when Braintree (owned by Paypal) decides to drop you as a merchant? What if you're running a website supporting Tor, or selling proxies or VPNs, and they decide your content is "against policy?"

They'll "drop" you, and suddenly your "drop in" SDK is completely worthless and you're forced to write your billing system from the ground up.

From a risk perspective, using a solution like Chargebee, that integrates with multiple merchant accounts (including Braintree), is a much better choice. If for whatever reason your merchant drops you (it does happen!), you don't need to make any code changes. You only need to swap out the backend merchant account in your Chargee dashboard.

These "batteries included" payment solutions are nice for getting up and running quickly, but if you have any semblance of long term planning, it's a bad idea to build your entire billing infrastructure around the API of a single merchant account provider.

This anyone considering a "serious" long term business should avoid Paypal, they eventually screw every merchant one way or another, their history is littered with horror stories and business that have grown reliant on then and went under when their funds get eventually frozen over some automated stupidity and no customer support.

Some usability things I noticed on the Drop-in UI Sample Page: (https://www.braintreepayments.com/features/drop-in)

It appears that the PayPal is a header, rather than a button, it has no call to action. Separating the credit card form from the button and giving it a clear header (Like: "Pay With Credit Card") would help indicate the choice of PayPal or Credit Card.

Also, I'm not sure if it's intentional, but the credit card form doesn't actually do anything. Completing the form with a test credit card gives no follow-up call to action. This could be confusing to people wanting to see a "working" integration.

I'm one of the developers who works on v.zero. We're planning on constantly improving the drop-in UI based on feedback and data. Currently we allow you to embed the form shown in your own form. It's expected you would include your own call to action that would be more contextual for the user.

On native mobile we,ve taken the approach to render the call to action for you and allow you to configure the text. Is that something you would find useful on web as well? It's definitely something we've debated internally.

I like that I've got the ability to control the display, I'm looking forward to testing the integration. But, for some people, providing the full look and feel might fit better with the "drop-in" notion.

I don't quite understand the recent developments at Braintree. We were using both them and PayPal for awhile before deciding to turn out card transactions over to PayPal also as it would secure a better rate. Meanwhile BrainTree has been working to make it easier to split processing between the two. Is the end goal here to make sure you're paying the highest rate? Why wouldn't you only use PayPal?

Will this be able to save credit cards on the device so the user doesn't need to re-enter their credit card every single time they need to make a purchase?

Kristi from Braintree here. You can securely store the card info to the Braintree vault so the user only has to enter the credit card info in your app one time. You won't be able to save credit cards to the device to use across apps.

Will we be able to do the same for Paypal credentials? So if someone wants to do paypal, store that and charge later?

Yep, you're able to save PayPal credentials to the vault. From there, you can treat it exactly like you would a stored credit card.

Kristi, what are you actually saving to the vault when I use PayPal? I know you present the merchant with a token, but how is it accomplished? Has PayPal had a charge-whenever token capability before that was not widely understood, or are you actually saving the customer's paypal email and password so you can charge arbitrary transactions in the future?

Paypal does have a future payments token capability [1]. The user must explicitly authorize the merchant the ability to use the token in order to use it for future transactions. We save the email for reference, but we never save the password.

[1] https://developer.paypal.com/docs/integration/mobile/make-fu...

Can Paypal (not Braintree) also authorize future Credit Card purchases from the same user without having to enter the CC number again? As in, could PayPal pass me a customer ID when someone purchases with CC via PayPal?

Does the PayPal SDK do the same thing? (saving credit cards to a vault) https://developer.paypal.com/webapps/developer/docs/integrat...

Huh. I'm confused, what's to stop someone from copying the "Paypal" button and associated modal, but simply directing the form to themselves to absorb the Paypal credentials?

I suppose anyone could do this to take advantage of silly users, but this is encouraging users to trust 3rd party websites by design.

Seems wide open for phishing.

There is also nothing stopping anyone from slapping on the old PayPal button or the Checkout with Amazon button on a phishing site. Do you prefer something non-branded out of the box, such as Stripe's Pay with Card button? Generally, you can't turn these services on without at least having the page serving the production version on SSL.

Yeah, but those sites don't have people enter in their login/password until after they've been forwarded to an `amazon.com` or `paypal.com` domain. Try it. This is encouraging users to engage in fundamentally unsafe behavior (enter credentials for site A on site B because site B looks like site A).

Google Wallet does the same thing as Stripe checkout with the overlay: https://www.humblebundle.com/ Is the URL inspection the best way to make sure you're going to the right site? I know that for us deeply technical folks that's the case, but for someone less technical, they wouldn't know the difference between one URL redirect vs. another.

Not quite. If you're not logged in, Google Wallet will open a popup (as opposed to a JS modal overlay), clearly identified as "https://accounts.google.com", prompting you to enter your username and password. The username and password are never entered under the same URL bar as the 3rd party site.

If Braintree's checkout process opened a popup window, with a clear URL bar, into which the user entered their username/password, then this would not be a problem.

This is Pedro, one of the developers at Braintree who worked on this product. Security is our top priority which is why we will show a pop-up window hosted on a PayPal domain in the environments that support it. We are incrementally rolling this feature out. Here's more info about this particular issue: https://developers.braintreepayments.com/javascript+ruby/sdk...

Interesting. I understand that popups might not be supported in certain environments, but it would seem the preferable flow in that case would be to forward to Paypal, authorize, then forward back. I just don't see any way to protect a lightbox from phishing, even if that's only on a subset of devices.

I guess I'm not up on the limitations of mobile browsers, but if they really make it so hard to expose the URL, it would seem to re-open a huge array of phishing attacks (and, once these are heavily exploited, mobile browsers will probably get better about exposing URLs.)

The most interesting part to me is that this is a regression. Paypal integration used to work like you said, and like I said here[1], though now they seem to favor usability over security.

[1]: https://news.ycombinator.com/item?id=8011614

I remember seeing these same concerns with the Stripe button. Edit: found the old discussion link: https://news.ycombinator.com/item?id=5079702&mobify=0

When I've used Stripe payment before, I remember just entering my credit card info. I can do this anywhere, regardless of how it's branded.

If someone malicious gets my credit card info, I have a lot of ways to defend myself. Someone malicious getting my PayPal login info could be much, much more dangerous, and I'd have considerably less protection. Essentially we're talking about leaking login info here -- that's very different than credit card info.

This phishing concern is part of why we decided to use one-time SMS tokens with Checkout -- there's no password to steal.

That's good to know -- thanks for clarifying that this is a real security concern.

Does this work for marketplace payments?

The new integration method is available for our marketplace merchants, but PayPal as a payment method is not available for marketplaces in this initial launch.

I skimmed but does anyone know why they called it V.zero?

Hey I'm Tony, one of the devs at Braintree. We chose v.zero because we tried to rethink how our merchant integrated with us from first principles. This represents our simplest integration yet. You can check out more at https://www.braintreepayments.com/v.zero

Reply on news.ycombinator.com