# 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:

1. **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.
2. **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}`](https://docs.verygoodsecurity.com/cmp/developer-resources/api/cards#get-cards-card_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.