Context

To make recurring payments, some businesses need to save the Apple Pay payment method on file when a user is on session then make the recurring payments later when the user is off session. The first on-session payment is often called a customer initiated transaction (CIT), and the later recurring payments are often called merchant initiated transactions (MIT). Two examples of recurring payments (or MIT) are:

• Subscriptions where users get billed on a fixed frequency.
• Recurring off-session payments where the billing frequency is inconsistent, or where customers can vary the frequency.

Apple Pay provides two type of tokens to handle recurring payments—the current Device Token (DPAN) based solution and the Merchant Token (MPAN) based solution.

Problem

When users interact with the Apple Pay payment sheet, Apple Pay processes a card PAN (the original card number) and generates a DPAN (Device Primary Account Number also known as the “Digital” Primary Account Number) to keep the PAN private. DPANs are tied to the specific Apple device, and can be unintentionally deactivated if a user switches to a new device (for example, an iPhone or an iPad) and adds the same card on it. When a DPAN generates, it also comes with an expiring one-time use cryptogram. Stripe needs to send both the DPAN and cryptogram to the authorization network shortly after Apple generates the cryptogram and before it expires. This expiration mechanism adds a layer of security to Apple Pay Wallets. A deactivated DPAN or an expired DPAN cryptogram can both lead to authorization failures when making payments.

Use the following solutions to resolve MIT failures caused by expired cryptograms, and adopt MPAN to avoid DPAN activation caused by device changes.

Solutions

New MPAN based solution

MPAN is a more reliable option for MIT. We recommend using the MPAN APIs provided by Apple rather than DPANs. Compared to DPANs, the lifecycle of MPANs is longer (they’re not deactivated when users switch their devices), and comes with better visibility and lifecycle management features to gain insights into changes to a token.

For more information on how to integrate with MPAN, please read our integration documentation at Apple Pay Merchant Tokens.

Current DPAN based solution

For recurring Apple Pay transactions, Stripe API does the following:

1. Save the DPAN and cryptogram in a Card.
2. Make a CIT. Consume the cryptogram before its expiration by sending a $0 validation or a charge transaction to the auth network, and keep a record of the returned network transaction.
3. Make MITs. When the payment method is reused for future off-session charges, Stripe sends the DPAN and the network transaction ID of above transaction to the auth network.

You should use Checkout or Elements as a payment UI: best practices to improve Apple Pay authorization rates are built into those products. If you don’t use a Stripe payment UI, follow these best practices to improve your authorization success rate.

Best practice: trial subscriptions

Users aren’t charged when subscription is created, they’re charged later off session by MIT when the free trial period ends. We recommend using Stripe Subscriptions in this case. The Subscription creates a SetupIntents for you in this case. When a SetupIntent is created, we perform a 0 USD validation with the authorization network, and this consumes the DPAN cryptogram before it expires.

You can also call SetupIntents directly to set up a payment method for future usage, and use that payment method to create Stripe Subscriptions. When the SetupIntent is confirmed, Stripe performs the same 0 USD validation as in the Subscriptions flow to consume the cryptogram.

If you’re using the legacy Tokens to create an Apple Pay payment token and then calling Charges later to charge the user when the trial ends:

1. Create a Payment Method with the token.
2. Call SetupIntents with the payment method to perform a 0 USD validation transaction immediately.

Completing these two steps creates the SetupIntent and the CIT.

You can now make off session MIT payments using the saved payment method. If you’re using PaymentIntents, set off_session=true to indicate that the customer isn’t in your checkout flow.

Best practice: off-session payments

If you’re setting up deferred off-session Apple Pay payments and aiming to collect payment information for future off-session uses. Apple Pay documented a list of supported payment types.

usage=off_session payments using DPANs are okay if the user is outside of the checkout flow. However, they have a slightly higher risk because they don’t get a liability shift from the network and might get lower authorization rates than average. Apple Pay terms forbid using a saved payment method for usage=on_session payments—if the user is in the flow, then you’re required to have them authorize and generate a new cryptogram for that transaction.

Incremental authorizations are supported by Apple Pay, you must increase the amount of an authorized charge before capturing it.

To complete the CIT you have two options:

• Follow the same steps as the previous scenario using SetupIntents to create a reusable DPAN based payment method for off session payments.
• You can also make a payment using PaymentIntents with setup_future_usage=off_session.

You can now make off session MIT payments using the saved payment method. If you’re using PaymentIntents, set off_session=true to indicate that the customer isn’t in your checkout flow.