Apple Pay
Overview
CMP supports storing Apple Pay wallet cards, including Device Primary Account Numbers (DPANs) and Merchant Primary Account Numbers (MPANs).
Merchants can store Apple Pay cards in CMP in two ways:
Submit a decrypted wallet token (DPAN or MPAN) directly to CMP. This means the merchant already has the clear wallet token value — meaning the clear DPAN or MPAN — and sends that token directly in the Create Card request.
Submit an encrypted Apple Pay payment token to CMP. CMP decrypts the Apple Pay payload, extracts the underlying DPAN or MPAN, and converts it into a stored card.
Both approaches result in a card stored in CMP that can be retrieved using the standard GET /cards/{id} API.
Understanding Apple Pay Tokens
When a customer pays using Apple Pay, Apple Pay returns tokenized card data rather than exposing the original PAN. For standard one-time Apple Pay transactions, Apple Pay uses a device-specific tokenized credential (DPAN) in place of the PAN.
DPAN (Device PAN)
A DPAN is a device-specific tokenized credential generated for a particular device and card combination. It is commonly used for Apple Pay customer-initiated transactions.
Characteristics:
Device-specific
Used in customer-initiated Apple Pay transactions
Requires a cryptogram for the first authorization
Can support recurring payments when properly linked to prior transactions
MPAN (Merchant PAN)
An MPAN is a merchant-specific network token provisioned by the card network and is not tied to a specific device. Apple positions merchant tokens for recurring payments and automatic reload scenarios, where continuity across devices is important.
Characteristics:
Merchant-scoped rather than device-scoped
Intended for recurring payments and automatic reload use cases
Supports token lifecycle management (card updates, expiration changes, deleted)
Designed to improve authorization rates for recurring payments
Not tied to a specific device
MPAN support is expected to expand as Apple and card networks increase adoption.
Apple Pay Recurring Payment Model
When using Apple Pay for subscriptions, recurring billing, or automatic reload flows, the payment model typically begins with a customer-authorized Apple Pay transaction and is followed by subsequent merchant-initiated or preauthorized transactions, depending on the payment processor, network, and stored credential framework in use. Apple’s merchant token guidance is specifically designed to support recurring and automatic reload payment experiences across a customer’s devices.
Step 1 — Customer-Initiated Transaction (CIT)
The first payment is initiated by the customer, for example during checkout using Apple Pay.
During this step:
The customer authorizes the payment in Apple Pay.
Apple Pay returns tokenized payment data together with a single-use cryptogram for authorization.
The merchant submits the authorization request to their PSP using the DPAN and cryptogram, and the PSP processes the transaction.
If the transaction is approved, the card network returns a Network Transaction ID (NTID).
The merchant can then store the returned wallet credential for future use, subject to processor and network requirements.
The merchant must store:
DPAN (vaulted by CMP)
Expiration date
Network Transaction ID (NTID)
The cryptogram:
Is single-use
Expires quickly
Cannot be reused if the authorization fails
If the initial transaction fails, the customer may need to complete a new Apple Pay authorization flow to generate fresh payment data.
Step 2 — Merchant-Initiated Transactions (MIT)
All subsequent recurring or preauthorized payments occur without customer interaction.
MIT requests typically include:
DPAN or MPAN
Expiration date, when applicable
Previous Network Transaction ID (NTID)
Stored credential indicators
ECI value
The NTID links the recurring payment chain back to the original customer-authorized transaction. Without it, authorization rates may drop or transactions may be declined.
Last updated