Is stripe popular because it's cheaper than paypal and also doesn't have an API & payment flow that looks like a train wreck?
Probably not cheaper for larger customers, but the easy API & payment flow are for sure part of the success.
Android Pay is coming
41–49 of 49 posts
Re: Android Pay is coming
#42I've found myself more interested in Stripe's UI/UX than the product itself. Not that the product isn't anything less than mint, it's just that their front-end developers are so amazing.
I agree. How do you learn to become such a great front-end developer?
Re: Android Pay is coming
#43Is stripe popular because it's cheaper than paypal and also doesn't have an API & payment flow that looks like a train wreck?
Can you even use PayPal for accepting credit cards without redirecting the user to PayPal?
Re: Android Pay is coming
#44You should be able to do this without stripe in a few lines of code. HTML5 has `requestAutocomplete` which, on Chrome, can load Google Wallet, fill out the payment form using a proxy card, and submit the information. http://www.html5rocks.com/en/tutorials/forms/requestautocomp... It's not a complete solution (because it's only on chrome), but it's pretty cool and built in.
That API is awesome, and works for more than just payment info. Can't wait until its universally accepted.
Re: Android Pay is coming
#45Earlier quoted context omitted.
Google Wallet did not use tokenization. See here: http://arstechnica.com/business/2015/05/android-pay-will-emb...
solyentcola is actually correct. Google Wallet 1.0 used tokenization, but it was issuer side, not network side. When the networks weren't interested in tokenization, Google Wallet relaunched with HCE.
Do you have a source for this? I work in the payments industry and have lately been trying to follow things closely but this I must have missed.
Re: Android Pay is coming
#46Wait. Again? Re-Relaunch of Google Wallet?
And Google Wallet was just a re-launch of Google Checkout. I guess it's worth the risk of continual failure, because if they eventually do get a foot in the door it's incredibly lucrative. Taking a percentage of every payment someone makes is a pretty good incentive.
What's kind of laughable is that if Google hadn't been its half-baked self. They could have locked down electronic mobile payment, what, almost a decade ago now?
Re: Android Pay is coming
#47Earlier quoted context omitted.
Google Wallet did not use tokenization. See here: http://arstechnica.com/business/2015/05/android-pay-will-emb...
solyentcola is actually correct. Google Wallet 1.0 used tokenization, but it was issuer side, not network side. When the networks weren't interested in tokenization, Google Wallet relaunched with HCE.
As far as I understand it, they were issuing an actual credit card applet to the secure element for the first version, and later switched to the "proxy card" model and HCE.
Issuer-side tokenization wasn't even launched until 2014-09 by both Mastercard and Visa ("coinciding" with the launch of Apple Pay), so they couldn't have used it for the first version of Google Wallet.
Re: Android Pay is coming
#48I'm curious how Android Pay works on the retail side. Does it use a traditional VISA payment terminal system or are Google running some sort of server-side payment hub? I'm assuming, for instance, we won't see Android Pay integration in to Bitcoin apps any time soon.
For payment in store, it is standard EMV contacless payment (with some specificities for HCE) like for contactless physical credit card. Therefore you should be able to pay with any NFC enabled Point Of Sale connected to payment networks (Visa/Mastercard at least I assume for Android Pay). This payment solution relies on tokenization. Tokens are mapped to physical payment cards (Google will probably act as a Token Se…
It would be very interesting to know if Google will indeed act as a TSP, or if they will delegate that to the card networks (like Apple does, IIRC).
Re: Android Pay is coming
#49Earlier quoted context omitted.
solyentcola is actually correct. Google Wallet 1.0 used tokenization, but it was issuer side, not network side. When the networks weren't interested in tokenization, Google Wallet relaunched with HCE.
As far as I understand it, they were issuing an actual credit card applet to the secure element for the first version, and later switched to the "proxy card" model and HCE. Issuer-side tokenization wasn't even launched until 2014-09 by both Mastercard and Visa ("coinciding" with the launch of Apple Pay), so they couldn't have used it for the first version of Google Wallet.
Mastercard and Visa launched network-side tokenization, not issuer-side tokenization. And yes, it used a Mastercard PayPass applet, as does network-side tokenization.
When it comes down to it, tokens are just credit cards that have a mapping back to an account. The network-side tokenization spec includes additional measures for provisioning and security, but they're still just credit cards. (If that weren't true, then all of the merchants would require terminal upgrades to work with them).
In issuer-side tokenization, it's the issuer (the user's bank/cc company) that creates the token, and they map it to accounts internally. In network-side tokenization, it's the network (MC, Visa, etc.) that handles the token creation, and they map it back to the previously issued credit card before the charge goes back to the issuer.