Could you elaborate on the dozens of identical systems? I haven't yet managed to find one where no one except the credit card networks can see my CC number (and I thought the tokenization spec was only released 6 months ago...)
For example: https://support.google.com/wallet/answer/2740044?hl=en
Token-like services are also common for contactless payment systems ...
(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.
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?
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-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.
This is how things work in 2014: http://clover-developers.blogspot.com/2014/09/apple-pay.html
(Clover is owned by First Data.)
It's pointed to from their apple pay solution as to how it works?
"This is how things work in 2014: http://clover-developers.blogspot.com/2014/09/apple-pay.html "
Again, I have not seen a single implementation that claims to actually perform token usage all the way back to the issuing bank, just some diagrams that say "it's supposed to work that way" in some magical world where issuing banks run token service.
(and i've looked at actual implementations).
If you look at the comments on the blog, the author actually agrees with what i said: "Yes, the token is issued by the payment network, but Apple is not the payment network. The network would be Visa/MasterCard/AMEX. Apple receives the token from the payment network when the card is stored in Apple Pay (or Passport), then the token is provided each time a payment is made."
Note: Issued by the payment network. This is not the same as "bank who issued you the card". In fact, it's exactly the people I said it was (look at definition of payment network in the spec).
Also note: Apple sees the card to get the token to store in the wallet (it has to, unless the client directly understands how to route to an agent for a given card and connect there, which at least as apple has implemented, it doesn't). If you remember, above you said in an EMV world, only the issuer sees the real number. This is 100% false. Apple has no other way to get a token other than providing the PAN and letting an agent do ID & verification as part of a token request.
As I also said, the spec very specifically does not require anything else, delegating token service providing to agents.
Do you have anything to refute that issuing banks are going to be 100% compliant with the EMV tokenization spec (and apple pay) if they delegate the vault/lookup to someone else, like the payment processors? (I pasted the definitions from the spec, it specifically says the card issuer or the agent can perform this )
How about if they delegate to multiple people?
How about if they delegate to stripe, or google, or whoever?
The tokens only go exactly as far as the parties agree they want them to.
Two parties still see your card in Apple Pay: Whoever initially asks for the token to store (Apple right now), and whoever is playing vault. Apple just doesn't store it.