If your integration type is Direct API and you want to support Apple Pay, you will need to tokenize this payment method as well.

Apple Pay is an e-wallet payment method: instead of collecting raw card data, the Apple Pay session* returns an encrypted payment payload cryptographically bound to Apple's payment certificates. Because of this, Apple Pay tokenization requires passing this additional encrypted payload, rather than just a card number, to our tokenization endpoint.

How it works

1. Checkout — The shopper selects Apple Pay at checkout.
2. Apple Pay session — The merchant (or a third-party provider acting on their behalf) opens an Apple Pay session with Apple on the verified domain.
3. Encrypted payment token — Apple returns an encrypted payment token (paymentData) containing the encrypted card data, an ephemeral public key, a public key hash, a transaction ID and a signature. Apple does not expose the raw card number to the merchant.
4. Tokenization call to /token — The merchant forwards this encrypted data, unchanged, to our /token endpoint. We store the encrypted payload against our token and return that token.
5. Create order call to /order endpoint: The merchant uses the token we returned, instead of the raw Apple Pay payload.
6. Authorization: We forward the original encrypted payload, unchanged, to the PSP. The PSP decrypts it using the certificate and private key associated with the merchant's Apple Pay identity, then submits the authorization request to the acquiring bank. The result is relayed back through the PSP and our gateway to the merchant.