Nope. That's deliberately confusing Apple marketing. You get one PAN per device. The new "number" is just the EMV unpredictable number. You get that with any EMV card.
https://emvlab.org/emvtags/show/t9F37/
> and not care about skimming.
Because the PAN is only valid for online authorized EMV transactions.
The unpredictable number is an (of a few) inputs into the generation of the CVV3, which is also based on a dynamic key from the issuer. Key rotation is on the order of weeks to months (depending on issuer). This is the "unique number" per transaction (part of tag 57 https://emvlab.org/emvtags/show/t57/ )
DPAN is only good for card-present transactions, provided CVV3, transaction counters, etc.
Has anyone made a habit of rotating DPANs on a regular basis like this? Does Apple or your bank get irritated at some point?
The other week a store clerk failed to look up my purchase when using my physical credit card, but succeeded when using the same credit card via Apple Pay. I would have been out of luck if I had rotated my Apple Pay number.
So far my banks have not complained.
I once had a very long call trying to explain to a very upset Mastercard person why this behaviour wasn’t an issue. I don’t think they understood.
They are using an industry standard protocol that is 25 years old.
Maybe because people know the word "token" and don't know what a "PAN" is. Apple has built a trillion-dollar company by speaking at the level of its customers, not technobabble.
I'm somewhat uninitiated, and I definitely got the wrong impression. So thanks for your clear-up.
However a seemingly trivial but important difference with Apple Pay is that it doesn't use your physical card number—instead it uses a different card number randomly assigned to your device. The payment networks can therefore recognise Apple Pay-assigned numbers and know to demand full Apple Pay authentication when they are used.
This reduces the scope for downgrade attacks.
I do wonder if the security gain is significant enough to make Apple Pay integration a gross-positive for all parties. Apple appears to charge a ~0.1-0.2% fee per transaction made via Apple Pay [0], so it might be reasonable that the security adds enough value in its own right to make sense from a fraud/insurance perspective.
Might also be the fact that possibly being "Top of wallet" on Apple Pay (Which users might use anyway, irrespective of if their normal card is supported) provides enough value to take a small hit in fees.
[0] https://appleinsider.com/articles/16/02/22/apple-halved-tran...
But to be fair, after trying to do payments in various other ways, Google eventually built their Android payments platform to be an almost perfect 1:1 recreation of Apple Pay.
(And this is a recurring theme with Android. I'm not saying Google aren't within their rights to build things however they wish, but it is remarkable how often Google make loud smug noises about how they've done things differently to Apple—only for those points of differentiation to quietly disappear a few years later. Say what you will about Apple, a company that makes plenty of horrible mistakes, but it's remarkable how often they do get things exactly right the first time.)
There are varying reports of people seeing unfamiliar (i.e. device) numbers and their card number on receipts. I've no knowledge about exactly why there's no consistency, but my suspicion is that Apple Pay sends these four digits as metadata during the contactless transaction. Older contactless terminals would ignore it and naively print four digits of the account number, whereas newer terminals might recognise that metadata and print that on the receipt instead.
It's also possible that the physical card's last four digits are being sent back to the terminal by the network.