Overview#

Apple Pay is a Mobile-Digital Wallet system.

Apple Pay works using a device-based Secure Element. [1]

Apple Pay does not store the real card or token data in their cloud servers. The on-device Secure Element essentially performs Card-Emulation in addition to secure storage.

Apple Pay sends payment data to the contactless terminal when you Tap & Pay utilizing NFC and the EMVCo’s Contactless suite of specifications to communicate with the contactless reader terminal.

Apple Pay does not store the real card data inside the Secure Element. This is in direct contrast to Google Wallet and Softcard. Apple Pay stores a token that conforms to EMVCo Tokenization specification. This token (along with a cryptogram) that gets sent to the contactless terminal. Apple refers to the "Device Account Number" (PAN) as the EMVCo token in their documentation.[2]

During the authorization flow, the card network identifies the token, de-tokenizes them into real PAN with the help of a Token Service Provider (TSP) and sends the real PAN over to Issuer for authorization.

Since Apple owns and controls the Secure Element embedded inside the device thereby avoiding unnecessary challenges from the MNOs.

Secure Enclave and Touch ID #

Each Apple Pay transaction is authenticated using Touch ID or the user’s passcode. The Secure Enclave manages the Authentication process and enables a payment transaction to proceed.

As far as we can tell, other than the Authentication process, neither the Secure Enclave or Touch ID are involved in the Apple Pay process.

Could there be some Cryptography Functions involved?

How it Works#

Adding a Card to Apple Pay#

When a customer adds a Payment Card to their wallet, the PAN details are submitted to Apple Pay servers.

Apple Pay sends the information over to the corresponding Issuer Bank asking for a Payment Token in return.

The Issuer Bank calls a Token Service Provider (TSP) and requests for a Payment Token. As far as we know, the payment network themselves play the role of TSP at present.

The TSP vaults the PAN, maps it to a Payment Token and returns the token and a Payment Token-Key.

The Issuer Bank receives a token and Payment Token-Key, and adds a CVV-Key to the mix.

The Issuer Bank returns the Payment Token, Payment Token-Key and CVV-Key back to Apple Pay.

Apple Pay, acting as its own Trusted Service Manager (TSM) provisions the Payment Token, Payment Token-Key and CVV-Key and maybe other data into the Secure Element. This combination is the "Token" that Apple calls as "Device Account Number" DAN in its press releases.

Making a POS Payment#

When a customer taps or waves their iPhone in front of a point of sale terminal, a payment transaction is initiated.

Apple Pay uses EMVCo’s Contactless Suite of Specifications to communicate with the contactless reader terminal.

When it is time for the Secure Element to send information to the terminal:

To put this in Apples terms, The Device Account Number or DAN represents the Payment Token, the One-time Unique Number represents the Dynamic Cryptogram and the Dynamic Security Code represents the Dynamic CVV Value.

The Payment Network identifies that it is a Payment Token and not a real PAN based on BIN tables. Consequently, they send a request out to the TSP to de-tokenize passing in the Payment Token and the Dynamic Cryptogram.

The TSP, among other things, validates the Dynamic Cryptogram using the Payment Token-Key that it shared earlier during the provisioning process. If the Dynamic Cryptogram is valid, the TSP de-tokenizes and returns the real PAN back to the Payment Network.

The Payment Network attaches the real PAN to the authorization request and sends it over to the Issuer Bank for authorization.

The Issuer Bank validates the Dynamic CVV Value based on the CVV-Key it shared earlier during the provisioning process. Then it authorizes the transaction depending on the customer’s account status. The authorization status flows back from the Issuer Bank to the Payment Network, back to the Payment Card Acquirer and back to the Merchant where your receipt gets printed.

About the Apple Pay Payment Token#

The Merchant is sent the Payment Token, which is a Virtual Credit Card Number, from the Card-Emulation process. With Apple Pay this will appear as a Credit Card Number issued from the bank that issued the Credit Card that is stored in Apple Pay that was selected to make the payment.

You may see the last four digits of this Payment Token on the receipt of your purchase. If the cashier asks for the last four digits used in the transaction, (Generally, they should not), you should give the last four of your Payment Token. (TBD Where to find this value.)

As far as we know this Payment Token will be the same every time you select the same Credit Card for payment within Apple Pay.

Patent Filing #

The U.S. Patent and Trademark Office published Apple's application for a "Method to send payment data through various air interfaces without compromising user data," which details a readily deployable digital system based on existing mobile hardware technology. Prior to today's filing, most of Apple's payment-minded patents have focused on use case scenarios, not backend infrastructure. Uses the term Secure Element.[3]

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-29) was last changed on 06-Jul-2016 13:26 by jim