It’s really more about payment cards (debit, credit) in general, not credit per se.
Where exactly does Apple Pay fit in this chain? Do they replace the card issuer or are they a new link between the acquiring bank and the issuer?
Where exactly does Apple Pay fit in this chain? Do they replace the card issuer or are they a new link between the acquiring bank and the issuer?
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!).
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.