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.
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...
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Until he wants to convert that to fiat. Or to buy Bitcoin in the first place, while not in US. I'm a huge fan of Bitcoin, but the ecosystem, especially outside US, is still very immature. It can take days before an exchange verifies you, recognizes your fiat deposit, and processes your withdrawals. Learned that the hard way (it took igot.com 17 days to process my Bitcoin withdrawal).
You can do exactly what you just outlined using Venmo (in the US). Or any number of other solutions worldwide. With the added benefit that you're transferring currency which you can easily put in your bank account and spend absolutely anywhere you want.
Bitcoin is great, but let's not pretend it is ready to be the go-to money transfer solution for everyone.
Not that the product isn't anything less than mint, it's just that their front-end developers are so amazing.