In reply to Slava Gomzin.

Absolutely a theory, until it's live, everything is speculation.

Visa's token service references that they are being used in ApplePay, and it has mentioned elsewhere. Clover/First Data also released a nice writeup that addresses it a bit, especially a the issue of the word token being use (differentiating between a Token like this that functions like a PAN, and a token that is an unrelated number or string that doesn't resemble a PAN at all and cannot be used as a surrogate) but as mentioned by inthebiz it is possible that it will depend on the issuer.

EMV Payment Tokenization works similar enough though, the Token Service Provider creates a surrogate PAN that passes the Luhn check and so works with out existing infrastructure.

I did reread the Venture Beat article and one thing I noticed is that I believe part of this is a misinterpretation by the writer, or maybe a matter of semantics. They looked at a developer document that referred to a Device PAN. The Device PAN is the token/substitute PAN. The authors issue is in Apple saying they store no "card data" when here we see they are storing a PAN. So either it's the semantics of whether a SPAN is actually "card data" or whether they misinterpreted that this is the token.

Also, "How difficult is to trick the Apple Pay system in order to decrypt the payment token and retrieve the original card data?"

That to me is an interesting question. I think it is being used to imply there is a weakness. I think it misses the point that the conversion from PAN to token/SPAN is one way .