3 ms·

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

by 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.)
  - DannyBee 12y ago
    "That whitepaper is from 2012" 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 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.
deleted 12y ago
[deleted]

by natrius 12y ago

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.)
- DannyBee 12y ago
  "That whitepaper is from 2012" 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 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.

deleted 12y ago

[deleted]