Why no news of Google Wallet tokenization upgrade?

[Menel]

The EMVco tokenization standard for NFC seems pretty open and standard. Google should have been able to fire back with An update, or at least with their new Lollipop OS, or their new Nexus device.

So what's holding them back?

Is it the lack of sophisticated biometrics technology?
Or maybe the lack of hardware control from hardware partners to specify a 'Secure Element'?
The desire to track and index users they process through their proxy credit card?

 

[gotluck]

I believe it is the second one.
And of course arguably third as always

 

[mi7chy]

Nothing new about one-time use token based transaction. I worked for a company that used it for check image retrieval back around 2007 and I doubt we were the first.

 

[Lloydbm41]

The EMVco tokenization standard for NFC seems pretty open and standard. Google should have been able to fire back with An update, or at least with their new Lollipop OS, or their new Nexus device.

So what's holding them back?

Is it the lack of sophisticated biometrics technology?
Or maybe the lack of hardware control from hardware partners to specify a 'Secure Element'?
The desire to track and index users they process through their proxy credit card?

Biometrics and indexing data has nothing to do with it. Google used the secure element when Wallet was first released, but the restrictions this placed on the various phones meant limited use. The secure element was replaced with what is in use now and enables a large range of devices to use the service.

Apple is new to the game. We have to wait and see how Apple Pay pans out. Will it succeed, stumble around for a while or fail? Time will tell.

 

[jrswizzle]

Biometrics and indexing data has nothing to do with it. Google used the secure element when Wallet was first released, but the restrictions this placed on the various phones meant limited use. The secure element was replaced with what is in use now and enables a large range of devices to use the service.

Apple is new to the game. We have to wait and see how Apple Pay pans out. Will it succeed, stumble around for a while or fail? Time will tell.

Over 1 million cards added in 72 hours, already the most popular mobile wallet out there (with more card activations than all others combined)....I think it's clear customers desperately want it to succeed.

Mobile Payments are an area where Google and Apple can work together as neither or their implementations are mutually exclusive and they have the banks on their side.

It's retailers and, to a lesser extent now, carriers that are pushing back because they don't want to pay CC fees and want to track user data.

There will be so much (as if there isn't a ton already) push back against CurrentC, it'll die before it even gets going. If Apple and Google can get the banks to reduce their fees (perhaps with the billions Apple is saving them in fraud protection) to retailers, they might give up the fight earlier.

One thing is certain though, Apple Pay is here to stay. And implementations like it (Google Wallet) are the future.

 

[Oletros]

The EMVco tokenization standard for NFC seems pretty open and standard. Google should have been able to fire back with An update, or at least with their new Lollipop OS, or their new Nexus device.

So what's holding them back?

Is it the lack of sophisticated biometrics technology?
Or maybe the lack of hardware control from hardware partners to specify a 'Secure Element'?
The desire to track and index users they process through their proxy credit card?

Google Wallet has used tokenization since a long time ago

 

[hallux]

Over 1 million cards added in 72 hours, already the most popular mobile wallet out there (with more card activations than all others combined)....I think it's clear customers desperately want it to succeed.

Mobile Payments are an area where Google and Apple can work together as neither or their implementations are mutually exclusive and they have the banks on their side.

It's retailers and, to a lesser extent now, carriers that are pushing back because they don't want to pay CC fees and want to track user data.

There will be so much (as if there isn't a ton already) push back against CurrentC, it'll die before it even gets going. If Apple and Google can get the banks to reduce their fees (perhaps with the billions Apple is saving them in fraud protection) to retailers, they might give up the fight earlier.

One thing is certain though, Apple Pay is here to stay. And implementations like it (Google Wallet) are the future.

"Clear customers want it to succeed"? More like how many millions of users now have a new "toy" and are working to set it up. All those people that got iPhone 6's on launch day, how many do you think have only ONE credit card? Personally, I have 4 plus my debit card not to mention 2 or 3 store cards that RARELY get used (once a year, MAYBE). When Google Wallet was released there was, what, ONE device that had the hardware that it needed? That ONE device had sold how many? Not a lot as it was a Nexus device that was only available on 2 carriers.

CVS and RiteAid have already blocked ALL mobile device tap-to-pay capabilities, and there are others in the CurrentC group that are MAJOR players (Walmart being one). If those others follow suit and allow ONLY their mobile payment app/system to work at their locations, it likely means the end of Apple Pay AND Google Wallet.

 

[jrswizzle]

"Clear customers want it to succeed"? More like how many millions of users now have a new "toy" and are working to set it up. All those people that got iPhone 6's on launch day, how many do you think have only ONE credit card? Personally, I have 4 plus my debit card not to mention 2 or 3 store cards that RARELY get used (once a year, MAYBE). When Google Wallet was released there was, what, ONE device that had the hardware that it needed? That ONE device had sold how many? Not a lot as it was a Nexus device that was only available on 2 carriers.

CVS and RiteAid have already blocked ALL mobile device tap-to-pay capabilities, and there are others in the CurrentC group that are MAJOR players (Walmart being one). If those others follow suit and allow ONLY their mobile payment app/system to work at their locations, it likely means the end of Apple Pay AND Google Wallet.

Do you know anything about CurrentC? As big as Walmart is, they can't stand up to Apple, Google and all the major US Banks and Credit Card companies (not including the retailers who have fallen on the side of NFC payments).

That 1 million was within 72 hours. I'm sure the number has exploded since then. I think it's pretty clear customers want a more secure, simpler payment option (given the 2013-2014 year of the hacker). Apple Pay (and even Google Wallet) offer that.

CVS and Rite-Aid have likely been backed into a corner through an exclusivity clause as part of the MCX group. My guess is, if they had their choice, they'd rather forgo all this negative press and leave their NFC terminals enabled.

 

[hallux]

Do you know anything about CurrentC? As big as Walmart is, they can't stand up to Apple, Google and all the major US Banks and Credit Card companies (not including the retailers who have fallen on the side of NFC payments).

That 1 million was within 72 hours. I'm sure the number has exploded since then. I think it's pretty clear customers want a more secure, simpler payment option (given the 2013-2014 year of the hacker). Apple Pay (and even Google Wallet) offer that.

CVS and Rite-Aid have likely been backed into a corner through an exclusivity clause as part of the MCX group. My guess is, if they had their choice, they'd rather forgo all this negative press and leave their NFC terminals enabled.

So, 1 million card adds in 1.5 days is a lot? When you consider there were over 10x that many devices sold in the first weekend, that actually isn't a whole lot.

Do you have a source showing how many activations there are on the other systems?

If WalMart is part of MCX, they would have the same exclusivity clause as CVS and RiteAid and should be disabling NFC on their terminals in short order BUT Apple did announce them as a partner for Apple Pay, didn't they? So, while I brought up the idea that they're blocking other mobile payment capabilities to push their own, there may be something else going on there.

 

[jrswizzle]

So, 1 million card adds in 1.5 days is a lot? When you consider there were over 10x that many devices sold in the first weekend, that actually isn't a whole lot.

Do you have a source showing how many activations there are on the other systems?

If WalMart is part of MCX, they would have the same exclusivity clause as CVS and RiteAid and should be disabling NFC on their terminals in short order BUT Apple did announce them as a partner for Apple Pay, didn't they? So, while I brought up the idea that they're blocking other mobile payment capabilities to push their own, there may be something else going on there.

Walmart was never a partner for Apple Pay. And, at least in my area, they don't have NFC capability on their new Chip-and-pin terminals.

Walmart is the ring leader of MCX. They were never going to go for NFC payments.

My source for activations comes from Tim Cook....he was the one who said Apple Pay outpaces all other mobile wallets combined. I don't have any more information than that.

You can compare it to the overall number of devices. But I don't think that's really fair - compare it to other services of its kind.

What's going on here is pretty simple and obvious. Walmart (and a bunch of other retailers, notably CVS, Rite-Aid and Best Buy) created a gang of retailers called the MCX (merchant customer exchange) with the goal of creating a mobile wallet solution that does two things:

(1) Bypasses credit card company fees
(2) Gathers additional customer data

Since Apple Pay (and Google Wallet) utilize NFC to make credit card payments, the processing fees to the retailer still apply. MCX retailers are killing NFC payments because they don't want it to catch on and be the norm for payments in their stores as their own solution (called CurrentC) is set to launch in 2015.

CurrentC is a terribly convoluted and horribly inconvenient system utilizing QR codes scanned by the customer and then by the cashier. It requires one's bank account number (to bypass CC companies) and other very personal data (SSN, health data, transaction data etc) to work.

Not only is it more inconvenient, its also more intrusive and if compromised, far more dangerous.

What's going to happen is MCX will either completely overhaul CurrentC after all the negative press it's getting or cave to NFC payment options like Apple Pay and Google Wallet. Because there's no way in hell the current iteration of CurrentC will ever get off the ground.

 

[Menel]

Google Wallet has used tokenization since a long time ago

Not according to Google and tech websites they don't...

They use a proxy account to process transactiobs, acting as a middle man.

 

[Oletros]

Not according to Google and tech websites they don't...

They use a proxy account to process transactiobs, acting as a middle man.

Proxy account has nothing to do with tokenization, Google uses tokenization.

I think you're a little confused

 

[Menel]

So, 1 million card adds in 1.5 days is a lot? When you consider there were over 10x that many devices sold in the first weekend, that actually isn't a whole lot.

Do you have a source showing how many activations there are on the other systems?

If WalMart is part of MCX, they would have the same exclusivity clause as CVS and RiteAid and should be disabling NFC on their terminals in short order BUT Apple did announce them as a partner for Apple Pay, didn't they? So, while I brought up the idea that they're blocking other mobile payment capabilities to push their own, there may be something else going on there.

WalMart has always rejected ApplePay verbally, even though has worked in some stores.

Meijer is both ApplePay launch partner, as well as MCX member... So they avoided any rumored exclusivity agreements somehow.

I think RiteAid and CVS just dicks.

 

[Menel]

Proxy account has nothing to do with tokenization, Google uses tokenization.

I think you're a little confused

http://arstechnica.com/gadgets/2014/10/how-mobile-payments-really-work/
This will help you.

Virtual Card

That scheme, which remains intact as per Google Wallet's Terms of Service (TOS), last updated in July 2014, is facilitated by issuing the customer a Google Wallet Virtual Card. This Virtual Card is issued by Bancorp Bank through Google, and it essentially acts as an intermediary between the customer's preferred card and the merchant. ... [Google Payment Corporation] has arranged for Bancorp to provide you with access to a MasterCard®-branded virtual prepaid debit payment card product ... As Google describes a transaction: “When you place your mobile device near the merchant's NFC reader, your Google Wallet Virtual Card information will be transferred from your NFC mobile device to the merchant for use in processing the Payment Transaction. The Google Wallet Virtual Card is a prepaid debit card that can be used to make purchases when you use the Google Wallet Mobile Service at a merchant location that accepts contactless payments ... The Google Wallet Virtual Card is different from your debit or credit card registered in Google Wallet. The merchant will not receive your registered debit or credit card information. ... your real credit card information is still stored on Google's servers.

PROS:
Merchants don't get your acct information.

CONS:
Google stores your acct information, and gets it to bolster the information they have on their flock, to sell to their corporate customers.

Details on the merchant, and rewards your issuer might grant you, are hidden from your actual credit card issuer.

Google takes a hit for every transaction.

On the other hand, this setup makes transactions more complex, requiring Google to shoulder part of the burden in securing those card numbers stored on its servers. It might even be costing Google a bit of money. ... Google will transfer the sales amount from the card that was actually selected by the user to the virtual card. And now the issuer of the ultimate payment source will also have to collect its interchange fee. This time Google will have to pay for it, and it doesn’t seem like the search giant can offload the interchange to anyone else.”

If this which Arstechnica proposes at the end of the Google Wallet section is true... and knowing Google's business... it likely is:

... it does seem apparent that Google's goal in its mobile payments endeavor is the same as with the rest of its free services—to collect as much data as possible from its customers.

Google will not be in a hurry to implement the new EMVco Tokenization Standard, authenticated directly to VISA/MC and the card issuers, because they wouldn't be able to gather as much data on their flock.

In this way... Google Wallet is looking a lot like MCX CurrentC.

----------

The EMVco tokenization standard for NFC seems pretty open and standard. Google should have been able to fire back with An update, or at least with their new Lollipop OS, or their new Nexus device.

So what's holding them back?

Is it the lack of sophisticated biometrics technology?
Or maybe the lack of hardware control from hardware partners to specify a 'Secure Element'?
The desire to track and index users they process through their proxy credit card?

Going back to my first post. Arstechnica makes it pretty clear... Google corporate profit motive in number 3 is preventing them from bringing secure transactions to Android users

 

[Oletros]

http://arstechnica.com/gadgets/2014/10/how-mobile-payments-really-work/
This will help you.

Perhaps you should read the links you post, it will help you:

"Your actual credit card number is not stored. Only the virtual prepaid card is stored and Android's native access policies prevent malicious applications from obtaining the data. In the unlikely event that the data is compromised, Wallet also uses dynamically rotating credentials that change with each transaction and are usable for a single payment only. Finally, all transactions are monitored in real-time with Google’s risk and fraud detection systems."

Googler uses ****ing one time tokens.

http://arstechnica.com/gadgets/2014/10/how-mobile-payments-really-work/
Google will not be in a hurry to implement the new EMVco Tokenization Standard, authenticated directly to VISA/MC and the card issuers, because they wouldn't be able to gather as much data on their flock.

In this way... Google Wallet is looking a lot like MCX CurrentC.

----------


Going back to my first post. Arstechnica makes it pretty clear... Google corporate profit motive in number 3 is preventing them from bringing secure transactions to Android users

Taking into account that your main premise is wrongt, that quote is a good chunk of *********

 

[gotluck]

They are likely gathering data but it is not insecure.

At least on the payment side.
Some data could likely be obtained on the online google account side. Use two factor auth people.

This has been enlightening.

 

[Oletros]

They are likely gathering data but it is not insecure.

He is confusing tokenization with the payment method

 

[minimo3]

I wouldn't quite call the transaction method Google Wallet uses tokenization, its probably better described as a virtual card. In its most current implementation Google Wallet utilizes Host Card Emulation that does not require a physical secure element (prior to KitKat Google Wallet did use physical secure elements found in SIM cards - hence Wallet only worked with certain wireless carriers that allowed access to their SIM's SE). With 4.4 HCE, software (Android) emulates the secure element. With Google Wallet in particular you would store your actual credit / debit card information in Google's cloud (this is significantly different from Apple where they do not store your actual credit card info anywhere). The Google Wallet app meanwhile is issued a virtual Mastercard by Bancorp. Anytime you make a payment in a store via NFC the Bancorp Mastercard virtual card is used to pay, and then your linked credit/debit cards are used to fund the Bancorp Mastercard.

So basically, Apple Pay is more secure (fingerprint auth, credit card info is never stored anywhere) ...
but Google Wallet is more flexible because you can add any credit / debit card (with Apple Pay the bank has to be on board)

 

[sviato]

So, 1 million card adds in 1.5 days is a lot? When you consider there were over 10x that many devices sold in the first weekend, that actually isn't a whole lot.

Well the iPhone 6 launched in multiple countries but ApplePay only in one. If we knew how many were sold in the US then you can claim whether it's a lot or not.

 

[gotluck]

I wouldn't quite call the transaction method Google Wallet uses tokenization, its probably better described as a virtual card. In its most current implementation Google Wallet utilizes Host Card Emulation that does not require a physical secure element (prior to KitKat Google Wallet did use physical secure elements found in SIM cards - hence Wallet only worked with certain wireless carriers that allowed access to their SIM's SE). With 4.4 HCE, software (Android) emulates the secure element. With Google Wallet in particular you would store your actual credit / debit card information in Google's cloud (this is significantly different from Apple where they do not store your actual credit card info anywhere). The Google Wallet app meanwhile is issued a virtual Mastercard by Bancorp. Anytime you make a payment in a store via NFC the Bancorp Mastercard virtual card is used to pay, and then your linked credit/debit cards are used to fund the Bancorp Mastercard.

So basically, Apple Pay is more secure (fingerprint auth, credit card info is never stored anywhere) ...
but Google Wallet is more flexible because you can add any credit / debit card (with Apple Pay the bank has to be on board)

However as oletros quoted wallet uses tokinization in between the virtual card and google wallet.

It uses both tokenization and virtual card.

Apple pay is more secure, but I wouldn't call google wallet insecure. Have to remember google is making money from data, and a loss on every payment AFAIK, while apple takes a piece of every transaction.

 

[Oletros]

I wouldn't quite call the transaction method Google Wallet uses tokenization, its probably better described as a virtual card.

Using a virtual card or not has nothing to do with using tokenization in the payment.

You can call waht you want, it still is tokenization

 

[Menel]

Perhaps you should read the links you post, it will help you:



Googler uses ****ing one time tokens.




Taking into account that your main premise is wrongt, that quote is a good chunk of *********

They DO NOT use the EMVco Tokenisation Standard.. which I asked about in the topic opening.

1. The EMVco Tokenization Standard didn't exist when Google Wallet launched.
2. *IF* Google used the EMVco Tokenisation Standard, the wouldn't need the proxy card system, wouldn't need to store your account credentials in their cloud, and wouldn't be able to track consumers.

 

[Oletros]

They DO NOT use the EMVco Tokenisation Standard.. which I asked about in the topic opening.

1. The EMVco Tokenization Standard didn't exist when Google Wallet launched.
2. *IF* Google used the EMVco Tokenisation Standard, the wouldn't need the proxy card system, wouldn't need to store your account credentials in their cloud, and wouldn't be able to track consumers.

They use the standard, they changed the system for KitKat.

EMVco has nothing to do with storing the credentials in the cloud or not

Really, read, learn and stop posting wrong things

 

[Menel]

They use the standard, they changed the system for KitKat.

EMVco has nothing to do with storing the credentials in the cloud or not

Really, read, learn and stop posting wrong things

Show proof to your claim.

I've posted links showing how it is not involved, which is a known, and the entire reason why I started this thread asking why not from Google. Ars answered this, in the form of basically: 'google wanting to continue mining their sheep for data'. Sad, but expected I suppose.

Here is another.

Apple Pay, by the way, is the first implementation of the new EMVCo tokenization specifications

http://www.aviso.io/apple-pay-brings-new-problems-acquirers/

When you read this article, make sure you follow the directions...

last March when the EMVCo tokenization specifications (it’s a large PDF – but keep it open, it comes in useful later in this blog

For example

Token Requestors will be required to register with Token Service Providers and comply with their proprietary registry requirements, systems, and processes. After successful registration with a Token Service Provider, the Token Requestor will be assigned a Token Requestor ID.

VISA's Token Service didn't even itself launch until this past October... How was Google using this service which DID not exist? And such they have had to use a proxy card account?

 

[Oletros]

Show proof to your claim.

I've posted links showing how it is not involved, which is a known, and the entire reason why I started this thread asking why not from Google. Ars answered this, in the form of 'google wanting to continue mining their sheep for data'.

Here is another.


http://www.aviso.io/apple-pay-brings-new-problems-acquirers/

When you read this article, make sure you follow the directions at the top.


For example

VISA's Token Service didn't even itself launch until this past October... How was Google using this service which DID not exist? And such they have had to use a proxy card account?

My God, read your ****ing links and read the ****ing Google FAQ.

As it is clear what is your role in this thrad i stop here, believe what you want, reality won't change