1) Google Wallet wasn't just going through Google and their banking partner, but at first didn't even allow a CC or Debit card. They wanted you to connect a bank account which affects security of payments made, and reduces points that many use to reduce costs. For me, the funds I filter back as account credit (and once as an Amtrak ticket since their exchange rate made a $60 ticket cost only about $20 account credit from one of my cards) ends up being substantial.
Note too that as originally envisioned it really quite similar to what Apple Pay is, particularly on an iPhone without fingerprint reader. TBH Google Wallet's biggest problem was timing IMO. They had the right idea.
From 2011:
"Google Wallet is currently being field-tested in New York and San Francisco, with release on the first Android smartphone, the Nexus S 4G from Sprint, planned for this summer. The app, Google says, will not only enable users to make purchases by waving their NFC-capable phones at a shop's MasterCard PayPass-enabled point-of-sale devices, it will also enable participating merchants to offer a raft of digital coupons, cutomer-loyalty programs, and the like.
In a nod to shoppers savvy enough to worry about device security, Google was careful to offer reassurance that security is on Mountain View's mind, as well. "[Google Wallet] will require an app-specific PIN and in the first release," their announcement reads, "all payment card credentials will be encrypted and stored on a chip, called the secure element, that is separate from the Android device memory and is only accessible by authorized programs."[/B]
In addition to the MasterCard PayPass/Citi partnership, Google also announced that it's currently working with VeriFone, Hypercom, Ingenico, VIVOTech, and others to develop SingleTap point-of-sale systems that will be Google Wallet–enabled. Sixteen retail chains are currently participating in this effort, including major deparment stores Macy's and Bloomingdale's, and bagel-brokers Noah's and Einstein Bros."
Google "announces" stuff all the time, but did that "announcement" also come with Google Wallet allowing you to add your bank's credit or debit card to Google Wallet to make payments from your credit or debit card via your mobile device? I don't recall that being possible when they launched. I distinctly recall, but admit that my memory could be off, that they only had an option through a partner service for tying your bank account and routing number to Google Wallet for payments.
[QUOTE]Note too that as originally envisioned it really quite similar to what Apple Pay is, particularly on an iPhone without fingerprint reader. TBH Google Wallet's biggest problem was timing IMO. They had the right idea.[/QUOTE]
1) It had nothing to do with timing, but about competency in their design. Google could have been ahead of Apple by many years and could have Apple playing catch up, instead of the other way around but they focused only on their immediate data mining and getting a "me first" product out the door. Had they looked at 'us' as the customer and not as the product things could have been very different.
2) You say it's "really quite similar to what Apple Pay is" and "they had the right idea," but they didn't. Not even close! They are both mobile payments using an NFC chip for communication, but that's where it ends. You want to prove m wrong? Then show me where Google got with the multinationals and banks to have them redesign their back end to offer a representational card number and token system. Show me where Google never stored the physical card info on the device. Show me where Google purposely kept themselves and 3rd-parties out of the loop from issued card to merchant to bank.
Google "announces" stuff all the time, but did that "announcement" also come with Google Wallet allowing you to add your bank's credit or debit card to Google Wallet to make payments from your credit or debit card via your mobile device? I don't recall that being possible when they launched. I distinctly recall, but admit that my memory could be off, that they only had an option through a partner service for tying your bank account and routing number to Google Wallet for payments.
1) It had nothing to do with timing, but about competency in their design. Google could have been ahead of Apple by many years and could have Apple playing catch up, instead of the other way around but they focused only on their immediate data mining and getting a "me first" product out the door. Had they looked at 'us' as the customer and not as the product things could have been very different.
2) You say it's "really quite similar to what Apple Pay is" and "they had the right idea," but they didn't. Not even close! They are both mobile payments using an NFC chip for communication, but that's where it ends. You want to prove m wrong? Then show me where Google got with the multinationals and banks to have them redesign their back end to offer a representational card number and token system. Show me where Google never stored the physical card info on the device. Show me where Google purposely kept themselves and 3rd-parties out of the loop from issued card to merchant to bank.
Soli, I would think it was pretty obvious to you that Google Wallet used tokens from day one. Your CC details were never shared with the retailer, instead storing payment credentials within a hardware-based secure element on the phone itself with a "token" replacing the card number just as Apple does today. How else to handshake with the SE if not for tokens?
Eventually Google Wallet moved from an SE implementation to Host-card Emulation (HCE) tho. Why? The carriers had their own ideas, much preferring that payment information be stored on the SIMM card which they could control and tap rather than the secure element with the NFC chip that they couldn't access. Google didn't have the market power to pressure them.
But if Google couldn't get value directly from the transaction itself since the details were tokenized what was Google's angle for making money from it? They didn't have access to the payment info (unless their payment card was used)., and they weren't setting up a charity. Google planned to make money from placing ads, coupons, special offers and such thru "loyalty programs" when a Wallet user visited a participating retailer. With businesses on board Sprint and Google would gain really good data on what folks were interested in. They planned a perfect ad targeting opportunity, one I imagine they could charge a premium for. Apple is getting ready to roll out a "loyalty/reward program" for partners too aren't they according to various reports?
Anyway why do I think the timing was wrong? In 2011 there wasn't yet any reason for a retailer to spend the money on NFC-enabled terminals. It didn't cost them anything to just leave things as is. Those swipe machines were perfectly serviceable... and cheap. Most banks weren't yet motivated to change anything as those huge CC data breaches hadn't yet happened. Why worry right? The carriers weren't going to budge on wanting to control mobile payments. After all, they had ISIS.their own mobile payment platform. Consumers didn't understand yet how security lapses from retailers would personally affect their lives. Most folks had no idea retailers were even storing personal information about them and their credit cards, Now it's all changed, Some of it by regulation and some because of high-profile data break-ins. Now that's all changed. In the past couple of years security became a hot topic.
So the contactless infrastructure is finally being put in place, not because retailers wanted to but because they HAVE to. The carriers finally gave up on ISIS, seeing the writing on the wall and throwing in the towel last year. They'll back SE implementations after all and stop standing in the way. Data breaches affecting millions of consumers have been in the news for a couple of years now. and we're all sick of it. Now even "Joe Lunchbucket" is concerned about data security. And banks were finally seeing a big impact from those retailer failures to protect personal information. It's costing them real money.
Now EVERYONE is ready to change. But they weren't ready in 2011 and nothing Google could have done at the time could change that. Even Apple would have hit the infrastructure wall IMO.
Soli, I would think it was pretty obvious to you that Google Wallet used tokens from day one.
FUÇK TOKENS! Tokenization is not the fucking same as getting banks to change their back end to store a representational card number on your device so that even if your device was stolen an could be hacked, or if Google was hacked that your physical card info could never be stolen.
Anyway why do I think the timing was wrong? In 2011 there wasn't yet any reason for a retailer to spend the money on NFC-enabled terminals.
1) IF that were the case then Google would still have been at the forefront with Google Wallet with Apple playing catch up, but they aren't because their entire foundation for Google Wallet is shit which is why they are now moving to Android Pay which is NOT simply a rebinding of a name with no changes in place. They built Google Wallet on sand. Now i's a concert slab because of Apple.
2) If it was only about NFC terminals why don't the countries that are heavy with NFC terminals have a huge part of their population using Google Wallet nearly every time it's possible? It's because it's a flaw system. In a few years it will be Apple Pay, Android Pay, and all the others that followed Apple's lead, and it's not because of some "Apple got lucky with timing" or "Apple is just good at marketing" bullshit. It's because they worked with the banks. They gave them the control and showed them how they can all work at their own pace to support mobile payments that work, that is secure, that reduces theft, and is convenient. Show me a single screenshot from a Google event in 2011 where they listed all the major US banks supporting Google Wallet.
2) You say it's "really quite similar to what Apple Pay is" and "they had the right idea," but they didn't. Not even close! They are both mobile payments using an NFC chip for communication, but that's where it ends. You want to prove m wrong? Then show me where Google got with the multinationals and banks to have them redesign their back end to offer a representational card number and token system.
Apple didn't get the banks to design the supporting back-end either, nor push them to support the token system. The Payment Card Industry Security Standards Council did that. PCI has been working on the standards for years and tokens are a compliance requirement to meet the standards. Apple Pay was designed to comply with PCI requirements not the other way around. That's why Android Pay, Samsung Pay and others will all generally work the same way with the same general security features. Not at all dissing Apple's hard work in getting everything working right from the get go, and all the players on board, but Apple didn't design the system or even help create the rules AFAIK.
[quote name="Gatorguy" url="/t/187687/apple-pay-challenger-currentc-could-postpone-launch-into-2016/40#post_2760269"] Apple didn't get the banks to design the supporting back-end either Soli. [/QUOTE] 1) I didn't say Apple got the banks to design it. Apple designed Apple Pay and then let the banks to know what they had to do make it work.
2) I'm sill waiting for you to show where Google first got with all the banks and credit union so they could all get onboard with the same system that would work with Google Wallet seamlessly and securely by strong a representational card instead of the physical card on the device.
1) I didn't say Apple got the banks to design it. Apple designed Apple Pay and then let the banks to know what they had to do make it work.
No sir. PCI told Apple what they would have to do to make it work. It's their rules on security and payment handling that Apple has to comply with. The banks, just a part of PCI, and Apple had to get together to agree on how to divvy up the money and promotion IMO. It was going to happen one way or another. They did a great job with the roll-out too! Much better than Google Wallet/Android Pay could have put together. I'm sure they're happy as can be to ride in on Apple's PR coattails.
... and no I probably can't show you the specific things you asked for, at least not without a good amount of research in technical and industry reports and papers. So I'll pass for now (since I'm supposed to be researching a cable cutting per the wife's proclamation ) and just say I can't prove you wrong. If I run across it later I'll either post it here or if much later on PM you instead.
No sir. PCI told Apple what they would have to do to make it work. It's their rules on security and payment handling that Apple has to comply with. The banks, just a part of PCI, and Apple had to get together to agree on how to divvy up the money and promotion IMO. It was going to happen one way or another. They did a great job with the roll-out too! Much better than Google Wallet/Android Pay could have put together. I'm sure they're happy as can be to ride in on Apple's PR coattails.
... and no I probably can't show you the specific things you asked for, at least not without a good amount of research in technical and industry reports and papers. So I'll pass for now (since I'm supposed to be researching a cable cutting per the wife's proclamation ) and just say I can't prove you wrong. If I run across it later I'll either post it here or if much later on PM you instead.
Oh, PCI told Apple how to build Apple Pay on their devices? PCI told the banks to sign up with Apple but ignore Google Wallet because "they were too soon"? Come on!
edit: Here's a prime example of Google having all the right elements before Apple: Google Now. Siri was integrated first but Google had built a solid foundation from their GOOG-4111 so even though they didn't see the whole service until Apple showed it to them Google was both quick to market and surpassed Siri because they Google did it right. Google Wallet was never right, and that's why it took them so long to even come out with a replacement that is still only vapourware.
Anyone want to pile on?
1) Google Wallet wasn't just going through Google and their banking partner, but at first didn't even allow a CC or Debit card. They wanted you to connect a bank account which affects security of payments made, and reduces points that many use to reduce costs. For me, the funds I filter back as account credit (and once as an Amtrak ticket since their exchange rate made a $60 ticket cost only about $20 account credit from one of my cards) ends up being substantial.
2) Android Pay's back-end and giving control to the banks mirrors Apple Pay, but how are they going to implement it with Android so that it's not accessible by simply getting access to a system dump. I assume they are using the secure element of the Android chip, and I hope that they incorporate extra security measures to make it both seamless and protected, which includes phones that have a biometric. I don't want to see another article like we saw with HTC (below), although I'm expecting we will unless Google has found a way to get all HW vendors to follow a rigid path with certain HW elements so that a generic version of the Android Open Source Project (AOSP) or the licensed version with Google Mobile Services (GMS) can easily work with with enough ease that any decent Android-based device will be able to use Android Pay in a secure and safe manner.*
* There are a lot of people here that want Android to die or at least don't want them to have any successes, but the fact remains that they do make a large part of the mobile device ecosystem and there no evidence that will go away anytime soon. Because of this, it behooves everyone that loves Apple Pay and wants to see it in more places so they can eschew carrying their physical plastic cards so they can truly be protected from having their wallet lost or stolen to want Android-based devices and every other mobile platform to have something that mirrors Apple Pay in place as soon as possible. This is for our good but it benefits us best if everyone is on board.
I didn't mention the earlier problems of Google Wallet, but the credit card problem is gone. I still would never trust it.
HTC isn't the only ones with fingerprint problems. Every Android manufacturer that uses fingerprints has that problem now, because so far, Google hasn't implemented anything on the OS level, and the OEMs are doing it themselves. I imagine that when Android Pay becomes available, this will be solved, or at least, I hope it will be.
This is kind of a cavalier attitude I know, but considering my current options of swiping a credit card, I don't see anything less secure about Current C, Android Pay, or truly any other mobile payment system a merchant or bank are likely to accept. I don't currently have an Apple device that supports ?Pay, so an alternative mobile pay system compatible with my iPhone would be appreciated, and as I said, is not likely to be less secure than the credit card I'm currently using, yet more convenient. But the end goal for me is to ultimately migrate to ?Pay.
There's more to it of course. Apple Pay is the mist secure of the current services. When Android Pay comes out, it should be pretty secure as well.
Google Wallet goes through Google's servers to complete the transaction. Not terribly secure, despite tokenization.
CurrentC is about secure as a debit card, but has so many bad features for consumers, it's hardly worth considering. The is no fraud protection for consumers. None! You've got to argue with the retailer directly. That alone makes this worthless. It's very clumsy.
I do t see anything other that Apple Pay, and possibly, Android Pay, when it comes es out, as being useful. And unless Google can fix the fingerprint problems current Android devices have, then that can't be trusted too much either. Read the link I gave above.
Note too that as originally envisioned it really quite similar to what Apple Pay is, particularly on an iPhone without fingerprint reader. TBH Google Wallet's biggest problem was timing IMO. They had the right idea.
From 2011:
"Google Wallet is currently being field-tested in New York and San Francisco, with release on the first Android smartphone, the Nexus S 4G from Sprint, planned for this summer. The app, Google says, will not only enable users to make purchases by waving their NFC-capable phones at a shop's MasterCard PayPass-enabled point-of-sale devices, it will also enable participating merchants to offer a raft of digital coupons, cutomer-loyalty programs, and the like.
In a nod to shoppers savvy enough to worry about device security, Google was careful to offer reassurance that security is on Mountain View's mind, as well. "[Google Wallet] will require an app-specific PIN and in the first release," their announcement reads, "all payment card credentials will be encrypted and stored on a chip, called the secure element, that is separate from the Android device memory and is only accessible by authorized programs."[/B]
In addition to the MasterCard PayPass/Citi partnership, Google also announced that it's currently working with VeriFone, Hypercom, Ingenico, VIVOTech, and others to develop SingleTap point-of-sale systems that will be Google Wallet–enabled. Sixteen retail chains are currently participating in this effort, including major deparment stores Macy's and Bloomingdale's, and bagel-brokers Noah's and Einstein Bros."
Soli, I would think it was pretty obvious to you that Google Wallet used tokens from day one. Your CC details were never shared with the retailer, instead storing payment credentials within a hardware-based secure element on the phone itself with a "token" replacing the card number just as Apple does today. How else to handshake with the SE if not for tokens?
Eventually Google Wallet moved from an SE implementation to Host-card Emulation (HCE) tho. Why? The carriers had their own ideas, much preferring that payment information be stored on the SIMM card which they could control and tap rather than the secure element with the NFC chip that they couldn't access. Google didn't have the market power to pressure them.
But if Google couldn't get value directly from the transaction itself since the details were tokenized what was Google's angle for making money from it? They didn't have access to the payment info (unless their payment card was used)., and they weren't setting up a charity. Google planned to make money from placing ads, coupons, special offers and such thru "loyalty programs" when a Wallet user visited a participating retailer. With businesses on board Sprint and Google would gain really good data on what folks were interested in. They planned a perfect ad targeting opportunity, one I imagine they could charge a premium for. Apple is getting ready to roll out a "loyalty/reward program" for partners too aren't they according to various reports?
Anyway why do I think the timing was wrong? In 2011 there wasn't yet any reason for a retailer to spend the money on NFC-enabled terminals. It didn't cost them anything to just leave things as is. Those swipe machines were perfectly serviceable... and cheap. Most banks weren't yet motivated to change anything as those huge CC data breaches hadn't yet happened. Why worry right? The carriers weren't going to budge on wanting to control mobile payments. After all, they had ISIS.their own mobile payment platform. Consumers didn't understand yet how security lapses from retailers would personally affect their lives. Most folks had no idea retailers were even storing personal information about them and their credit cards, Now it's all changed, Some of it by regulation and some because of high-profile data break-ins. Now that's all changed. In the past couple of years security became a hot topic.
So the contactless infrastructure is finally being put in place, not because retailers wanted to but because they HAVE to. The carriers finally gave up on ISIS, seeing the writing on the wall and throwing in the towel last year. They'll back SE implementations after all and stop standing in the way. Data breaches affecting millions of consumers have been in the news for a couple of years now. and we're all sick of it. Now even "Joe Lunchbucket" is concerned about data security. And banks were finally seeing a big impact from those retailer failures to protect personal information. It's costing them real money.
Now EVERYONE is ready to change. But they weren't ready in 2011 and nothing Google could have done at the time could change that. Even Apple would have hit the infrastructure wall IMO.
Really now, you seem to forget a lot about this. This wasn't anything lime Apple Pay, and you should,d know it. About the only similar item was tokenization. Everything else was different. You needed to go through a bothersome process to actually pay at the counter. Only later on, did they simplify that.
No body cared about Google Wallet, that was why it failed. Well, that and a bad design of the process from the consumer's end. It was said for years, apparently correctly, that no one would care, and that mobile payments wouldn't get moving until Apple did it. And they were right.
FUÇK TOKENS! Tokenization is not the fucking same as getting banks to change their back end to store a representational card number on your device so that even if your device was stolen an could be hacked, or if Google was hacked that your physical card info could never be stolen.
1) IF that were the case then Google would still have been at the forefront with Google Wallet with Apple playing catch up, but they aren't because their entire foundation for Google Wallet is shit which is why they are now moving to Android Pay which is NOT simply a rebinding of a name with no changes in place. They built Google Wallet on sand. Now i's a concert slab because of Apple.
The purpose of tokenization is to protect your credit card info in case the merchants get hacked. If like most people you buy stuff from iTunes or Google Play, Apple or Google already have your credit card number on file and you're entrusting them with securing their systems. No Apple Pay/Google Wallet tokenization scheme will save you if their internal databases get hacked. For Google Wallet, Google rolled its own tokenization scheme using a virtual mastercard number together with a per-transaction CVV code.
Quote:
Show me a single screenshot from a Google event in 2011 where they listed all the major US banks supporting Google Wallet.
The whole point of building Google Wallet with Google acting as an intermediary was to support all banks at once instead of having to sign up banks individually like Apple Pay does right now and Android Pay presumably will have to when it rolls out:
Quote:
But the small number of partners made Google Wallet adoption stall. In 2012, the company tried to bring more users into the fold by issuing an update that permitted “all credit and debit cards from Visa, MasterCard, American Express, and Discover” to be uploaded to Google Wallet's cloud-based app. That didn't mean that Google developed partnerships with these companies necessarily (American Express notably balked at the announcement), but Google's new scheme opened the payments system up to greater mobile payments adoption than ever before. That scheme, which remains intac tas per Google Wallet's Terms of Service (TOS), last updated in July 2014, is facilitated by issuing the customer a Google Wallet Virtual Card.
The purpose of tokenization is to protect your credit card info in case the merchants get hacked.
Stop using tokenization like it in and of itself is all that's needed for proper, end to end security! Tokenization on Google Wallet is like padlocking a screen door to a vault then saying it's the same as Apple Pay.
If like most people you buy stuff from iTunes or Google Play, Apple or Google already have your credit card number on file and you're entrusting them with securing their systems.
Which is why Apple Pay is a brilliant solution.
For example, I no longer have to my CC on file with Starbucks because I can simply use Apple Pay from their app to reload my card. This no protects my card on file being used to fund to new gift cards that can then be transferred to another account instantly. There was even a recent story about that happening, not that I am a likely victim do to the manner in which I use my credentials and the complexity of my password.
No Apple Pay/Google Wallet tokenization scheme will save you if their internal databases get hacked.
As noted above, it most certainly can.
What we need is for Apple Pay to scale to include Macs, which will eventually get Winows OEMs to include NFC chips on their HW and Windows to support those chips. If that doesn't happen then the only other solution to make each website (or parent company if they have more than one website) store a unique, representational card that, if compromised, can be easily wiped and replaced by your participating bank. That is certainly possible but it seems like more a complex situation than eventually adopting NFC on Macs.
For Google Wallet, Google rolled its own tokenization scheme using a virtual mastercard number together with a per-transaction CVV code.
Which is why Google Wallet is faulty solution.
The whole point of building Google Wallet the way they did was to support all banks at once instead of having to sign up banks individually like Apple Pay does right now and Android Pay presumably will have to when it rolls out:
(http://arstechnica.com/gadgets/2014/10/how-mobile-payments-really-work/)
Their whole point was both pointless and stupid, and it's probably because they were looking at it from their common viewpoint as 'us' as the product, not the customer, hence them scurrying to adopt what Apple built.
Stop using tokenization like it in and of itself is all that's needed for proper, end to end security! Tokenization on Google Wallet is like padlocking a screen door to a vault then saying it's the same as Apple Pay.
All the recent personal information breaches have been laid squarely at the feet of the retailers. Retailers like Target or Home Depot are the weakest link. Shielding your credit information from the retailers is therefore already a marked improvement from the status quo even if it is not optimal.
Quote:
What we need is for Apple Pay to scale to include Macs, which will eventually get Winows OEMs to include NFC chips on their HW and Windows to support those chips. If that doesn't happen then the only other solution to make each website (or parent company if they have more than one website) store a unique, representational card that, if compromised, can be easily wiped and replaced by your participating bank. That is certainly possible but it seems like more a complex situation than eventually adopting NFC on Macs.
So is Apple going to delete your credit card number from their databases now that you've signed up for Apple Pay? NFC serves no purpose when the transaction takes place over the internet.
Their whole point was both pointless and stupid, and it's probably because they were looking at it from their common viewpoint as 'us' as the product, not the customer, hence them scurrying to adopt what Apple built.
Google Wallet did not have the luxury three years ago of a marketwide mandate for banks and merchants to upgrade their systems like there is now with the upcoming liability shift. There was also no EMV standard for tokenization at the time. If you were going to build a payment system back then, you could not expect banks to deploy custom backends just for your payment system.
So is Apple going to delete your credit card number from their databases now that you've signed up for Apple Pay? NFC serves no purpose when the transaction takes place over the internet.
Apple didn't get the banks to design the supporting back-end either, nor push them to support the token system. The Payment Card Industry Security Standards Council did that. PCI has been working on the standards for years and tokens are a compliance requirement to meet the standards. Apple Pay was designed to comply with PCI requirements not the other way around. That's why Android Pay, Samsung Pay and others will all generally work the same way with the same general security features. Not at all dissing Apple's hard work in getting everything working right from the get go, and all the players on board, but Apple didn't design the system or even help create the rules AFAIK.
I still have no idea why you brought up NFC. The sole purpose of NFC is to wirelessly transmit your token to the merchant's receiver for an in person transaction. It's just a wireless communication protocol and provides no authentication. It has no use when buying things from a remote merchant; in particular, NFC plays no role in in-app purchases through Apple Pay.
I don't think I understand what you're saying, if one has a debit card, it must be used as a debit card. It's not a credit card, and can't be used that way. What are you talking about?
The retailer runs it as credit but MasterCard/Visa just debits from your bank account as a debit card. It can be used as a debit card but also a credit. That is why there is an option at the checkout to process it as credit.
Comments
http://newsroom.mastercard.com/press-releases/google-citi-mastercard-first-data-and-sprint-team-up-to-make-your-phone-your-wallet/
Note too that as originally envisioned it really quite similar to what Apple Pay is, particularly on an iPhone without fingerprint reader. TBH Google Wallet's biggest problem was timing IMO. They had the right idea.
From 2011:
"Google Wallet is currently being field-tested in New York and San Francisco, with release on the first Android smartphone, the Nexus S 4G from Sprint, planned for this summer. The app, Google says, will not only enable users to make purchases by waving their NFC-capable phones at a shop's MasterCard PayPass-enabled point-of-sale devices, it will also enable participating merchants to offer a raft of digital coupons, cutomer-loyalty programs, and the like.
In a nod to shoppers savvy enough to worry about device security, Google was careful to offer reassurance that security is on Mountain View's mind, as well. "[Google Wallet] will require an app-specific PIN and in the first release," their announcement reads, "all payment card credentials will be encrypted and stored on a chip, called the secure element, that is separate from the Android device memory and is only accessible by authorized programs."[/B]
In addition to the MasterCard PayPass/Citi partnership, Google also announced that it's currently working with VeriFone, Hypercom, Ingenico, VIVOTech, and others to develop SingleTap point-of-sale systems that will be Google Wallet–enabled. Sixteen retail chains are currently participating in this effort, including major deparment stores Macy's and Bloomingdale's, and bagel-brokers Noah's and Einstein Bros."
http://www.theregister.co.uk/2011/05/26/google_wallet1/
Soli, I don't think you're remembering this correctly. This is the original press release announcing Google Wallet a little over four years ago . Notice the partners
http://newsroom.mastercard.com/press-releases/google-citi-mastercard-first-data-and-sprint-team-up-to-make-your-phone-your-wallet/ [/QUOTE]
Google "announces" stuff all the time, but did that "announcement" also come with Google Wallet allowing you to add your bank's credit or debit card to Google Wallet to make payments from your credit or debit card via your mobile device? I don't recall that being possible when they launched. I distinctly recall, but admit that my memory could be off, that they only had an option through a partner service for tying your bank account and routing number to Google Wallet for payments.
[QUOTE]Note too that as originally envisioned it really quite similar to what Apple Pay is, particularly on an iPhone without fingerprint reader. TBH Google Wallet's biggest problem was timing IMO. They had the right idea.[/QUOTE]
1) It had nothing to do with timing, but about competency in their design. Google could have been ahead of Apple by many years and could have Apple playing catch up, instead of the other way around but they focused only on their immediate data mining and getting a "me first" product out the door. Had they looked at 'us' as the customer and not as the product things could have been very different.
2) You say it's "really quite similar to what Apple Pay is" and "they had the right idea," but they didn't. Not even close! They are both mobile payments using an NFC chip for communication, but that's where it ends. You want to prove m wrong? Then show me where Google got with the multinationals and banks to have them redesign their back end to offer a representational card number and token system. Show me where Google never stored the physical card info on the device. Show me where Google purposely kept themselves and 3rd-parties out of the loop from issued card to merchant to bank.
Eventually Google Wallet moved from an SE implementation to Host-card Emulation (HCE) tho. Why? The carriers had their own ideas, much preferring that payment information be stored on the SIMM card which they could control and tap rather than the secure element with the NFC chip that they couldn't access. Google didn't have the market power to pressure them.
But if Google couldn't get value directly from the transaction itself since the details were tokenized what was Google's angle for making money from it? They didn't have access to the payment info (unless their payment card was used)., and they weren't setting up a charity. Google planned to make money from placing ads, coupons, special offers and such thru "loyalty programs" when a Wallet user visited a participating retailer. With businesses on board Sprint and Google would gain really good data on what folks were interested in. They planned a perfect ad targeting opportunity, one I imagine they could charge a premium for. Apple is getting ready to roll out a "loyalty/reward program" for partners too aren't they according to various reports?
Anyway why do I think the timing was wrong? In 2011 there wasn't yet any reason for a retailer to spend the money on NFC-enabled terminals. It didn't cost them anything to just leave things as is. Those swipe machines were perfectly serviceable... and cheap. Most banks weren't yet motivated to change anything as those huge CC data breaches hadn't yet happened. Why worry right? The carriers weren't going to budge on wanting to control mobile payments. After all, they had ISIS.their own mobile payment platform. Consumers didn't understand yet how security lapses from retailers would personally affect their lives. Most folks had no idea retailers were even storing personal information about them and their credit cards, Now it's all changed, Some of it by regulation and some because of high-profile data break-ins. Now that's all changed. In the past couple of years security became a hot topic.
So the contactless infrastructure is finally being put in place, not because retailers wanted to but because they HAVE to. The carriers finally gave up on ISIS, seeing the writing on the wall and throwing in the towel last year. They'll back SE implementations after all and stop standing in the way. Data breaches affecting millions of consumers have been in the news for a couple of years now. and we're all sick of it. Now even "Joe Lunchbucket" is concerned about data security. And banks were finally seeing a big impact from those retailer failures to protect personal information. It's costing them real money.
Now EVERYONE is ready to change. But they weren't ready in 2011 and nothing Google could have done at the time could change that. Even Apple would have hit the infrastructure wall IMO.
FUÇK TOKENS! Tokenization is not the fucking same as getting banks to change their back end to store a representational card number on your device so that even if your device was stolen an could be hacked, or if Google was hacked that your physical card info could never be stolen.
1) IF that were the case then Google would still have been at the forefront with Google Wallet with Apple playing catch up, but they aren't because their entire foundation for Google Wallet is shit which is why they are now moving to Android Pay which is NOT simply a rebinding of a name with no changes in place. They built Google Wallet on sand. Now i's a concert slab because of Apple.
2) If it was only about NFC terminals why don't the countries that are heavy with NFC terminals have a huge part of their population using Google Wallet nearly every time it's possible? It's because it's a flaw system. In a few years it will be Apple Pay, Android Pay, and all the others that followed Apple's lead, and it's not because of some "Apple got lucky with timing" or "Apple is just good at marketing" bullshit. It's because they worked with the banks. They gave them the control and showed them how they can all work at their own pace to support mobile payments that work, that is secure, that reduces theft, and is convenient. Show me a single screenshot from a Google event in 2011 where they listed all the major US banks supporting Google Wallet.
https://www.pcisecuritystandards.org/documents/pa-dss_mobile_apps-faqs.pdf
https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
Apple didn't get the banks to design the supporting back-end either Soli. [/QUOTE]
1) I didn't say Apple got the banks to design it. Apple designed Apple Pay and then let the banks to know what they had to do make it work.
2) I'm sill waiting for you to show where Google first got with all the banks and credit union so they could all get onboard with the same system that would work with Google Wallet seamlessly and securely by strong a representational card instead of the physical card on the device.
... and no I probably can't show you the specific things you asked for, at least not without a good amount of research in technical and industry reports and papers. So I'll pass for now (since I'm supposed to be researching a cable cutting per the wife's proclamation
Oh, PCI told Apple how to build Apple Pay on their devices? PCI told the banks to sign up with Apple but ignore Google Wallet because "they were too soon"? Come on!
edit: Here's a prime example of Google having all the right elements before Apple: Google Now. Siri was integrated first but Google had built a solid foundation from their GOOG-4111 so even though they didn't see the whole service until Apple showed it to them Google was both quick to market and surpassed Siri because they Google did it right. Google Wallet was never right, and that's why it took them so long to even come out with a replacement that is still only vapourware.
I didn't mention the earlier problems of Google Wallet, but the credit card problem is gone. I still would never trust it.
HTC isn't the only ones with fingerprint problems. Every Android manufacturer that uses fingerprints has that problem now, because so far, Google hasn't implemented anything on the OS level, and the OEMs are doing it themselves. I imagine that when Android Pay becomes available, this will be solved, or at least, I hope it will be.
This is a really good article about that:
http://arstechnica.com/security/2015/08/severe-weaknesses-in-android-handsets-could-leak-user-fingerprints/
While Apple has had its share of security nightmares lately, Android just seems to be having them piled on one after the other.
There's more to it of course. Apple Pay is the mist secure of the current services. When Android Pay comes out, it should be pretty secure as well.
Google Wallet goes through Google's servers to complete the transaction. Not terribly secure, despite tokenization.
CurrentC is about secure as a debit card, but has so many bad features for consumers, it's hardly worth considering. The is no fraud protection for consumers. None! You've got to argue with the retailer directly. That alone makes this worthless. It's very clumsy.
I do t see anything other that Apple Pay, and possibly, Android Pay, when it comes es out, as being useful. And unless Google can fix the fingerprint problems current Android devices have, then that can't be trusted too much either. Read the link I gave above.
Where's the mention that every transaction needs to go through Google's servers? Did you miss that one.
And of course, there's that Google guarantee that they will never look, or use, any of your personal information. Oops, that's not Google, sorry.
Really now, you seem to forget a lot about this. This wasn't anything lime Apple Pay, and you should,d know it. About the only similar item was tokenization. Everything else was different. You needed to go through a bothersome process to actually pay at the counter. Only later on, did they simplify that.
No body cared about Google Wallet, that was why it failed. Well, that and a bad design of the process from the consumer's end. It was said for years, apparently correctly, that no one would care, and that mobile payments wouldn't get moving until Apple did it. And they were right.
FUÇK TOKENS! Tokenization is not the fucking same as getting banks to change their back end to store a representational card number on your device so that even if your device was stolen an could be hacked, or if Google was hacked that your physical card info could never be stolen.
1) IF that were the case then Google would still have been at the forefront with Google Wallet with Apple playing catch up, but they aren't because their entire foundation for Google Wallet is shit which is why they are now moving to Android Pay which is NOT simply a rebinding of a name with no changes in place. They built Google Wallet on sand. Now i's a concert slab because of Apple.
The purpose of tokenization is to protect your credit card info in case the merchants get hacked. If like most people you buy stuff from iTunes or Google Play, Apple or Google already have your credit card number on file and you're entrusting them with securing their systems. No Apple Pay/Google Wallet tokenization scheme will save you if their internal databases get hacked. For Google Wallet, Google rolled its own tokenization scheme using a virtual mastercard number together with a per-transaction CVV code.
The whole point of building Google Wallet with Google acting as an intermediary was to support all banks at once instead of having to sign up banks individually like Apple Pay does right now and Android Pay presumably will have to when it rolls out:
(http://arstechnica.com/gadgets/2014/10/how-mobile-payments-really-work/)
Stop using tokenization like it in and of itself is all that's needed for proper, end to end security! Tokenization on Google Wallet is like padlocking a screen door to a vault then saying it's the same as Apple Pay.
Which is why Apple Pay is a brilliant solution.
For example, I no longer have to my CC on file with Starbucks because I can simply use Apple Pay from their app to reload my card. This no protects my card on file being used to fund to new gift cards that can then be transferred to another account instantly. There was even a recent story about that happening, not that I am a likely victim do to the manner in which I use my credentials and the complexity of my password.
As noted above, it most certainly can.
What we need is for Apple Pay to scale to include Macs, which will eventually get Winows OEMs to include NFC chips on their HW and Windows to support those chips. If that doesn't happen then the only other solution to make each website (or parent company if they have more than one website) store a unique, representational card that, if compromised, can be easily wiped and replaced by your participating bank. That is certainly possible but it seems like more a complex situation than eventually adopting NFC on Macs.
Which is why Google Wallet is faulty solution.
Their whole point was both pointless and stupid, and it's probably because they were looking at it from their common viewpoint as 'us' as the product, not the customer, hence them scurrying to adopt what Apple built.
Originally Posted by SolipsismY
Stop using tokenization like it in and of itself is all that's needed for proper, end to end security! Tokenization on Google Wallet is like padlocking a screen door to a vault then saying it's the same as Apple Pay.
All the recent personal information breaches have been laid squarely at the feet of the retailers. Retailers like Target or Home Depot are the weakest link. Shielding your credit information from the retailers is therefore already a marked improvement from the status quo even if it is not optimal.
So is Apple going to delete your credit card number from their databases now that you've signed up for Apple Pay? NFC serves no purpose when the transaction takes place over the internet.
Their whole point was both pointless and stupid, and it's probably because they were looking at it from their common viewpoint as 'us' as the product, not the customer, hence them scurrying to adopt what Apple built.
:infinite facepalms:
You're not getting the entire story. Apple did work with the banks and credit card companies to get this system working.
:infinite facepalms:
I still have no idea why you brought up NFC. The sole purpose of NFC is to wirelessly transmit your token to the merchant's receiver for an in person transaction. It's just a wireless communication protocol and provides no authentication. It has no use when buying things from a remote merchant; in particular, NFC plays no role in in-app purchases through Apple Pay.
I don't think I understand what you're saying, if one has a debit card, it must be used as a debit card. It's not a credit card, and can't be used that way. What are you talking about?
The retailer runs it as credit but MasterCard/Visa just debits from your bank account as a debit card. It can be used as a debit card but also a credit. That is why there is an option at the checkout to process it as credit.