Apple Pay operates using network tokenization, which is part of the EMV standard. This works in two parts.
When you add a card to Apple Pay, your device checks if the bank can use Apple Pay, and gets a device token from your bank, along with some cryptographic data. The original card number your typed in is discarded; it is replaced by the device token, which looks like a credit card number. All this data is stored in the device’s Secure Enclave. It’s important to note that Apple does not store card data, and doesn’t even take part in the transaction flow.
When you pay with Apple Pay, your device generates a network token. In practice, this network token is your device token, which is sent along with a cryptographic signature, the cryptogram (generated using the data previously stored into the Secure Enclave). This data fits into traditional card fields (name/number/expiration date/cvv), plus an additional field for the cryptogram. The token is transmitted through the merchant to their gateway/acquirer, which sends passes it to the payment network (Visa/Mastercard). The network checks the cryptogram, does a reverse lookup of the device token and associates it with the real card number. The transaction proceeds like a normal transaction using the real card number.
IIRC, Android Pay works using the same standard, with Google storing the device tokens in the cloud and generating network tokens on the behalf of the user (not all Android devices have secure elements). May be inaccurate, I haven’t had the opportunity to implement it at the payment provider level (yet!).
From what you write and from the diagram in that pdf, it's the issuer bank that creates the device token, but then it's the network that does the reverse lookup. Do both the issuer bank and the network know the mapping between device tokens and cards?
Yes. The network needs of course to map tokens back to PANs (Primary Account Numbers). Tokens are included in authorization requests to issuing banks, in addition to the actual payment details.
Also, both issuers and networks need to be able to suspend and unlink tokens in case of fraud or if the end user loses their device, which implies that they know individual device tokens.
It seems that Android devices are allowed to store a few pre-generated tokens to use offline for a limited duration. I don't have a first-party source for that however.
When you add a card to Apple Pay, your device checks if the bank can use Apple Pay, and gets a device token from your bank, along with some cryptographic data. The original card number your typed in is discarded; it is replaced by the device token, which looks like a credit card number. All this data is stored in the device’s Secure Enclave. It’s important to note that Apple does not store card data, and doesn’t even take part in the transaction flow.
When you pay with Apple Pay, your device generates a network token. In practice, this network token is your device token, which is sent along with a cryptographic signature, the cryptogram (generated using the data previously stored into the Secure Enclave). This data fits into traditional card fields (name/number/expiration date/cvv), plus an additional field for the cryptogram. The token is transmitted through the merchant to their gateway/acquirer, which sends passes it to the payment network (Visa/Mastercard). The network checks the cryptogram, does a reverse lookup of the device token and associates it with the real card number. The transaction proceeds like a normal transaction using the real card number.
https://www.emvco.com/wp-content/uploads/documents/EMVCo_Pay... : The official tokenization specification. Page 71 has a good diagram of the flow (the Token Service Providers are usually the networks themselves).
https://www.apple.com/business/docs/iOS_Security_Guide.pdf : The iOS Security Guide, which has interesting information in the Apple Pay section (page 34).
IIRC, Android Pay works using the same standard, with Google storing the device tokens in the cloud and generating network tokens on the behalf of the user (not all Android devices have secure elements). May be inaccurate, I haven’t had the opportunity to implement it at the payment provider level (yet!).