3 ms·

Your linked example is drastically different. Although the merchant only sees a virtual card number, Google sees, stores and charges your real credit card numbe

by surreal 12y ago

Your linked example is drastically different. Although the merchant only sees a virtual card number, Google sees, stores and charges your real credit card number the old-fashioned way.

DannyBee 12y ago
You say "Google sees your real credit card number". (I'll address the rest later) Somebody sees the credit card number, even in token based systems, even if it's only for a moment to acquire a token. In other words, either Apple stills sees it while it acquires a payment token, or someone does to issue the payment token, as it's the only mechanism that identifies the account number to get a token for. The tokenization specification has a whole section on what identification and verification should be taking place to ensure the "primary account number" (credit card number) that the payment token is replacing is one the user has authorization for. So let's focus on the "stores and charges". Yes, Google stores and charges your primary account number. This is just because Google happens to be the one doing the payment processing. Even in a token based system, again, somebody on the other side knows what real primary account number (credit card number) this token links back up to so they know what to subtract money from. The token based stuff is not an full anonymization protocol, it's mainly a way to securely avoid transmitting and storing credit card info to/by random merchants. In that respect, the virtual credit card numbers provide the same protection. They are one time use, and interception or storage by the merchant can not harm you. Secondarily, the payment tokens are also a way to reduce the number of networks your credit card number goes over, when used properly. The virtual credit card numbers perform the same function here too. The person who knows in either system is usually your payment processor (though in case it isn't, it's possible for the tokens to be used there too. however, nothing in Apple Pay currently guarantees this happens with the tokens). Since that is google here, it makes sense they would have the primary account data to do the lookup. If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that. The TL;DR is that virtual credit card numbers are in fact, a method of tokenization. The only reason they went with "token" is because they don't have to be credit card numbers, and because not all virtual credit card implementations have the same guarantees. In any case, if you want fully tokenized systems, those have existed too, just not en masse.
- natrius 12y ago
  EMVCo payment tokenization is more secure and more private than Google Wallet. With Google Wallet, two people know your card number and purchase history: Google and your issuer. With EMVCo tokenization, just your issuer knows your card number and purchase history. It's better. It's the future. "If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that." I disagree. Care to explain?
  - DannyBee 12y ago
    "just your issuer knows your card number and purchase history." If this was true, i'd agree. But it's not, AFAIK. "I disagree. Care to explain?" Nothing in the spec that i have seen requires that it be used all the way to the issuing bank. In fact, here is one actual implementation: http://www.firstdata.com/downloads/thought-leadership/EMV-Encrypt-Tokenization-WP.PDF http://www.firstdata.com/downloads/thought-leadership/EMV-En... Now look at figure 2 on page 8, and you can see ... It's not the issuer doing the tokenization or the PAN lookup, firstdata is doing it (in this case), just as Google is doing it in the Wallet case. Firstdata sells an approved apple pay solution. It happens that Apple does not provide payment processing services, and is thus not doing it. That of course, does not change how many parties see your card number :) Now, maybe there are issuers doing the tokenization, storage, and lookup themselves. But it's not required. The actual spec leaves these functions to an "Agent" (not an issuer) and defines an Agent as "An entity appointed by the Card Issuer to perform specific functions on behalf of the Card Issuer. Some examples of these functions include card processing, Cardholder verification using the 3-D Secure protocol, and Token Service" There is also nothing that assumes they do not appoint multiple agents (and in fact, specifically forsees this happening), etc. Love to see something that says otherwise, but i can't find it.
    - natrius 12y ago
      That whitepaper is from 2012. The tokenization there is for merchants to be able to keep a token on file for a customer instead of keeping a card on file. It's like getting a Braintree or Stripe token to use for payments, but instead, you're getting a First Data token. This is how things work in 2014: http://clover-developers.blogspot.com/2014/09/apple-pay.html http://clover-developers.blogspot.com/2014/09/apple-pay.html (Clover is owned by First Data.)

by surreal 12y ago

Your linked example is drastically different. Although the merchant only sees a virtual card number, Google sees, stores and charges your real credit card number the old-fashioned way.

DannyBee 12y ago

You say "Google sees your real credit card number". (I'll address the rest later) Somebody sees the credit card number, even in token based systems, even if it's only for a moment to acquire a token. In other words, either Apple stills sees it while it acquires a payment token, or someone does to issue the payment token, as it's the only mechanism that identifies the account number to get a token for. The tokenization specification has a whole section on what identification and verification should be taking place to ensure the "primary account number" (credit card number) that the payment token is replacing is one the user has authorization for. So let's focus on the "stores and charges". Yes, Google stores and charges your primary account number. This is just because Google happens to be the one doing the payment processing. Even in a token based system, again, somebody on the other side knows what real primary account number (credit card number) this token links back up to so they know what to subtract money from. The token based stuff is not an full anonymization protocol, it's mainly a way to securely avoid transmitting and storing credit card info to/by random merchants. In that respect, the virtual credit card numbers provide the same protection. They are one time use, and interception or storage by the merchant can not harm you. Secondarily, the payment tokens are also a way to reduce the number of networks your credit card number goes over, when used properly. The virtual credit card numbers perform the same function here too. The person who knows in either system is usually your payment processor (though in case it isn't, it's possible for the tokens to be used there too. however, nothing in Apple Pay currently guarantees this happens with the tokens). Since that is google here, it makes sense they would have the primary account data to do the lookup. If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that. The TL;DR is that virtual credit card numbers are in fact, a method of tokenization. The only reason they went with "token" is because they don't have to be credit card numbers, and because not all virtual credit card implementations have the same guarantees. In any case, if you want fully tokenized systems, those have existed too, just not en masse.

natrius 12y ago
EMVCo payment tokenization is more secure and more private than Google Wallet. With Google Wallet, two people know your card number and purchase history: Google and your issuer. With EMVCo tokenization, just your issuer knows your card number and purchase history. It's better. It's the future. "If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that." I disagree. Care to explain?
- DannyBee 12y ago
  "just your issuer knows your card number and purchase history." If this was true, i'd agree. But it's not, AFAIK. "I disagree. Care to explain?" Nothing in the spec that i have seen requires that it be used all the way to the issuing bank. In fact, here is one actual implementation: http://www.firstdata.com/downloads/thought-leadership/EMV-Encrypt-Tokenization-WP.PDF http://www.firstdata.com/downloads/thought-leadership/EMV-En... Now look at figure 2 on page 8, and you can see ... It's not the issuer doing the tokenization or the PAN lookup, firstdata is doing it (in this case), just as Google is doing it in the Wallet case. Firstdata sells an approved apple pay solution. It happens that Apple does not provide payment processing services, and is thus not doing it. That of course, does not change how many parties see your card number :) Now, maybe there are issuers doing the tokenization, storage, and lookup themselves. But it's not required. The actual spec leaves these functions to an "Agent" (not an issuer) and defines an Agent as "An entity appointed by the Card Issuer to perform specific functions on behalf of the Card Issuer. Some examples of these functions include card processing, Cardholder verification using the 3-D Secure protocol, and Token Service" There is also nothing that assumes they do not appoint multiple agents (and in fact, specifically forsees this happening), etc. Love to see something that says otherwise, but i can't find it.
  - natrius 12y ago
    That whitepaper is from 2012. The tokenization there is for merchants to be able to keep a token on file for a customer instead of keeping a card on file. It's like getting a Braintree or Stripe token to use for payments, but instead, you're getting a First Data token. This is how things work in 2014: http://clover-developers.blogspot.com/2014/09/apple-pay.html http://clover-developers.blogspot.com/2014/09/apple-pay.html (Clover is owned by First Data.)