Android Pay is coming(stripe.com)
stripe.com
Android Pay is coming
https://stripe.com/android-pay
48 comments
The form highlight animation is sexy!
It's from Google's Polymer project https://www.polymer-project.org/1.0/
That's the ripple animation from Material Design[1]--it looks good on an product page for Android.
[1]: http://www.google.com/design/spec/animation/responsive-inter...
[1]: http://www.google.com/design/spec/animation/responsive-inter...
And I'm SO thankful for this. It really makes selling a client on the service much easier, since many of them seem to only care about fancy spash pages...
I've noticed that on their last few announcements. Their landing pages for announcements have been top notch.
Yes, it's beautiful. However, looks like there's no form validation on the email submit. I just submitted "r" as an email address.
Strange, its still working as you mentioned earlier. What a weird bug to leave out in the open like that.
Not sure why you're getting downvotes, for such a slick page basic email address form validation is an odd omission.
As long as you can receive a confirmation email, any address could work :)
But basic \S+@\S+ check on the UI side won't hurt and would be courteous.
But basic \S+@\S+ check on the UI side won't hurt and would be courteous.
But what if I worked at stripe and only wanted to type my username? :D
On this form it's less relevant, but that's very handy a lot of the time. I get frustrated when some outsourced app seems to believe that just sending mail to my username would not work, and refuses to let me do it.
I agree. How do you learn to become such a great front-end developer?
You 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.
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.
Wait. 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.
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.
No, it's more like a sdk. Wallet is it's own app that uses pay. So you can integrate pay into things using nfc more easily. I am not sure on how apple pay works as a sdk.
On Android the Google Wallet app is being replaced by Android Pay, so it is more of a re-brand.
Seem like a mix of things.
Yep, the app is rebranded.
But they are also now partnering with banks etc rather than sitting as some generic middle man. Basically they seem to have copied Apple in this regard, and bent to the demands of the banks.
Yep, the app is rebranded.
But they are also now partnering with banks etc rather than sitting as some generic middle man. Basically they seem to have copied Apple in this regard, and bent to the demands of the banks.
[deleted]
Read: Android Pay is being re-marketed until we find a way that we think might catch on. This time.
I'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.
I'm assuming, for instance, we won't see Android Pay integration in to Bitcoin apps any time soon.
Based just on Google's blog post, this seems like another implementation of the standard that Apple helped create and push through with the banks and card networks for Apple Pay. They mention tokenization and virtual card numbers, which is exactly how Apple Pay works.
Did Apple really push it through? They weren't mentioned when the spec was released, six months before Apple Pay was announced.
http://www.nfcworld.com/2014/03/11/328236/emvco-publishes-to...
http://www.nfcworld.com/2014/03/11/328236/emvco-publishes-to...
They may have helped. Apple was definitely working on it more than six months before it was announced.
Google Wallet initially capitalized on Mastercard PayWave (or was that Visa's?) and when the other cards wouldn't play ball they made a virtual Mastercard for use.
Now that the card companies started playing ball, maybe b/c of Apple's push, Google can work with the new standards.
Google Wallet initially capitalized on Mastercard PayWave (or was that Visa's?) and when the other cards wouldn't play ball they made a virtual Mastercard for use.
Now that the card companies started playing ball, maybe b/c of Apple's push, Google can work with the new standards.
Yes, Apple Pay uses tokenization, no Apple neither created it nor pushed it through. Google Wallet 1.0 used issuer-side tokenization, and switched to HCE when the networks weren't interested in network-level tokenization. Yes, Apple participated in the spec but the most you can credit Apple with was smart negotiation, and taking advantage of lessons learned by Wallet.
Why do people have to constantly put down Apple's contributions? Their customers tend to be more desirable (because they're higher income) and Apple uses that as leverage to cut through bureaucracy to make things happen.
USB type C would not exist without lightning. Why? Because the customers for the USB-IF aren't end-users... they're bottom-feeding OEMs who want to shave $0.001 off the cost of each port and don't give a shit. Apple doesn't have to care about that and can forge ahead with their own standard. That creates demand in the market (specifically the actual customers of the USB-IF like Samsung who immediately want to copy anything and everything Apple does.)
Android Pay would be the same mostly-dead-end that Google Wallet was without Apple Pay. Why? Because Google has no power to get banks, card networks, or merchants on board. Because even if they release it that doesn't mean any of the OEMs will necessarily adopt it. Because a huge number of Android devices are cheap junk only purchased because it's almost impossible to buy plain feature phones anymore, not because the buyer actually gives a shit. Apple doesn't have any of those problems. If Apple offers Apple Pay they know higher-end merchants will adopt it. Apple customers are more likely to use it. The whole brand/cachè thing creates pressure to get on board the train.
Go ahead and ask Verizon and Sprint how holding out against the iPhone worked for them.
Many barriers to adoption of technology are social, cultural, or just plain old inertia. Apple is in a unique position to force change, yet there appears to be a pathological desire to lie and claim Apple isn't relevant.
USB type C would not exist without lightning. Why? Because the customers for the USB-IF aren't end-users... they're bottom-feeding OEMs who want to shave $0.001 off the cost of each port and don't give a shit. Apple doesn't have to care about that and can forge ahead with their own standard. That creates demand in the market (specifically the actual customers of the USB-IF like Samsung who immediately want to copy anything and everything Apple does.)
Android Pay would be the same mostly-dead-end that Google Wallet was without Apple Pay. Why? Because Google has no power to get banks, card networks, or merchants on board. Because even if they release it that doesn't mean any of the OEMs will necessarily adopt it. Because a huge number of Android devices are cheap junk only purchased because it's almost impossible to buy plain feature phones anymore, not because the buyer actually gives a shit. Apple doesn't have any of those problems. If Apple offers Apple Pay they know higher-end merchants will adopt it. Apple customers are more likely to use it. The whole brand/cachè thing creates pressure to get on board the train.
Go ahead and ask Verizon and Sprint how holding out against the iPhone worked for them.
Many barriers to adoption of technology are social, cultural, or just plain old inertia. Apple is in a unique position to force change, yet there appears to be a pathological desire to lie and claim Apple isn't relevant.
With google being all about data mining and getting as much information on you as they possibly can, I am having the hardest time believing that google will introduce a payment system that cannot track peoples individual shopping behavior.
It was one of Apple's selling points that they do not see what you buy. They only handle the monetary transaction. Only the merchant and you know what was purchased etc.
It is funny to imagine google knowing this valuable information is running right through their service/device and they do not or cannot take a look. As a data miner that would be more than frustrating.
It was one of Apple's selling points that they do not see what you buy. They only handle the monetary transaction. Only the merchant and you know what was purchased etc.
It is funny to imagine google knowing this valuable information is running right through their service/device and they do not or cannot take a look. As a data miner that would be more than frustrating.
And Google Wallet did before it.
Google Wallet did not use tokenization.
See here: http://arstechnica.com/business/2015/05/android-pay-will-emb...
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.
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.
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.
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.
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 Service Provider). Tokens once provisioned on the mobile hold among other things a Digitized Personal Account Number + a set of single use payment keys (or limited use keys) for payment.
This payment solution relies on tokenization. Tokens are mapped to physical payment cards (Google will probably act as a Token Service Provider). Tokens once provisioned on the mobile hold among other things a Digitized Personal Account Number + a set of single use payment keys (or limited use keys) for payment.
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).
Stripe is going to make boatloads of money. They're now going to be powering both Apple Pay and Android Pay? Wow. Let me get some stock on that sucker when they go public.
Is stripe popular because it's cheaper than paypal and also doesn't have an API & payment flow that looks like a train wreck?
[deleted](2)
Does this version have the arbitary "we hold you funds a-la paypal style-e"? functionality you have started to roll out to standard stripey?
No thanks.
Not that the product isn't anything less than mint, it's just that their front-end developers are so amazing.