Apple Pay for Recurring Payments: What Every Subscription Merchant Needs to Know

Your customer signed up for your service eighteen months ago. They tapped their iPhone, Face ID confirmed, and the whole thing took four seconds. You stored the token, set up the recurring billing, and figured you were done. Then July 2025 arrived, and somewhere in your payments stack, a device token that used to work just fine started failing on Visa, quietly and without escalation, one declined renewal at a time, draining subscription revenue from customers who never intended to leave. 

This post explains how Apple Pay recurring payments work, what the Visa mandate means for your billing stack, and how to build MPAN infrastructure that keeps subscription revenue where it belongs.

Why Apple Pay matters for recurring billing

Apple Pay is the dominant mobile wallet in the United States, with a 92% market share among U.S. mobile wallet users and a presence in 14.2% of all online payments globally. For subscription businesses specifically, 44% of subscription services now offer Apple Pay as a preferred payment method, which means nearly half the subscription economy treats Apple Pay as a first-class billing option. Merchants who haven't optimized for it are creating friction for a meaningful share of their customer base on every single billing cycle.

The good news is that Apple Pay's recurring payment infrastructure is genuinely well-designed. The credential type that makes it work, the Merchant Primary Account Number, solves problems that device-based tokens never could. Understanding the difference between the two is where everything starts.

What is an Apple Pay merchant token?

An Apple Pay merchant token (MPAN) is a payment credential tied to a customer's iCloud account and a specific merchant, issued by the customer's bank rather than by Apple. Unlike a device token, an MPAN survives phone upgrades, card reissuances, and device changes, making it the correct credential type for subscription billing and any recurring payment use case. Visa mandated the use of MPANs for standing instruction transactions from July 2025.

What is the difference between a DPAN and an MPAN?

A DPAN (Device Primary Account Number) is an Apple Pay token tied to a specific device, which means it becomes invalid when a customer upgrades their phone or gets a new card. An MPAN (Merchant Primary Account Number) is tied to the customer's iCloud account and a specific merchant, so it remains valid across device changes and card reissuances. For recurring billing, MPANs are the required token type under Visa's July 2025 standing instruction mandate.

The practical difference is significant. A customer who upgrades from one iPhone to another, an event that happens to tens of millions of people every autumn when Apple releases new hardware, invalidates every DPAN a merchant has stored for that customer. 

The merchant's vault still holds the old credential, the next recurring charge goes out against it, and the decline triggers a dunning sequence the customer may never respond to. With an MPAN, when a customer gets a new card due to loss or expiry, Apple updates the token automatically behind the scenes, eliminating the service disruptions and failed payments that typically occur in subscription billing when cards change.

Does Apple Pay support recurring payments?

Yes. Apple Pay supports recurring payments through Merchant Primary Account Numbers (MPANs), that allow merchants to charge customers on a scheduled or unscheduled basis without requiring the customer to re-authenticate at each billing cycle. Merchants must use the stored credential framework and request an MPAN at the point of initial authorization to enable recurring Apple Pay charges.

Recurring Apple Pay transactions through Spreedly require the stored_credential_initiator and stored_credential_reason_type fields to be correctly populated for every transaction. Gateways that don't receive correct stored credential flagging will process the charge as a standard Apple Pay payment, which means the issuer has no record of a prior consent agreement and subsequent recurring charges arrive without context. 

The result is a higher decline rate and a billing operation that looks compliant on the surface but isn't. Full implementation details are in Spreedly's stored credentials guide.

What's changed since Apple Pay launched recurring payments

Apple Pay's entry into recurring billing was gradual. MPANs were introduced as a capability, supported by a subset of issuers, recommended but not required. That era is over. The landscape has shifted in three meaningful ways since the original MPAN rollout, and subscription merchants need to understand all three.

Why are Apple Pay device tokens no longer valid for subscriptions?

Visa's July 2025 mandate requires merchants to use merchant tokens (MPANs) rather than device tokens (DPANs) for all standing instruction transactions, which includes recurring payments, installments, and unscheduled credentials on file. Device tokens provisioned after July 30, 2025 are not valid for these use cases on the Visa network. Merchants still using device tokens for subscription billing should transition to MPANs to maintain compliance and avoid declined recurring charges.

Since July 2025, Apple Pay device tokens issued after that date are no longer compatible with Standing Instruction Transaction use cases. The impact is broad, covering recurring payments, installments, and unscheduled credential on file scenarios. This isn't a soft recommendation or a future-dated advisory. It's a network requirement with real consequences for recurring revenue.

What still works with device tokens

Device tokens haven't disappeared entirely, and it's worth being precise about what still works. Device tokens continue to be supported for customer initiated transactions and one-time MITs such as incremental authorization or partial shipments. Existing DPANs provisioned before the mandate date will still function, though without performance guarantees going forward. 

Put simply: DPANs remain appropriate for one-time checkout flows, and any standing instruction use case now requires an MPAN. If your billing system can't distinguish between the two token types, that's the first thing to fix.

iOS compatibility requirements

Apple Pay MPANs require iOS 16.4 or higher, or Xcode 14.3 for development environments. Given that iOS 16.4 was released in March 2023, the vast majority of active Apple Pay users are already on a compatible version. That said, merchants building or updating their Apple Pay integration for recurring use cases should verify their minimum supported iOS version before go-live, particularly if their customer base skews toward older devices.

Apple doubling down on recurring

The Visa mandate is the compliance story, but there's a product story running alongside it. iOS 26 adds Preauthorized Payments, allowing users to set up recurring payments with a single authorization, deepening the consumer-facing recurring payments experience without requiring changes to the underlying credential and routing infrastructure. 

Apple is treating recurring billing as a product category, which means the investment merchants make in MPAN infrastructure now will continue to pay out as Apple extends the capability.

Which payment gateways support Apple Pay recurring payments?

For Spreedly users, Apple Pay recurring payments are supported on Adyen, Braintree, Checkout.com, CyberSource, CyberSource REST, Stripe Payment Intents, and Worldpay. 

These gateways support Spreedly's stored credential framework, which is required to correctly flag recurring Apple Pay transactions as merchant initiated. Gateways outside this list will process the transaction as a standard Apple Pay payment, which may result in declined charges on subsequent billing cycles.

If your current gateway isn't on this list and you're running Apple Pay subscriptions, that's a conversation worth having with your payments team before the next billing cycle. The fix is a routing change, not a re-architecture, but it needs to happen deliberately. Full details are available in our Apple Pay developer documentation.

How Spreedly Connect makes Apple Pay recurring payments manageable

Building compliant Apple Pay recurring payment infrastructure means coordinating certificate management, MPAN handling, stored credential flagging, lifecycle management, and gateway routing correctly for every transaction type across every gateway you use. Doing that without an orchestration layer means rebuilding and maintaining the same logic in multiple places, which is how billing stacks accumulate technical debt quietly and expensively.

Spreedly Connect is the unified orchestration layer that handles wallet and alternative payment method complexity so your engineering team doesn't have to. For Apple Pay specifically, Connect manages the certificate issuance and decryption layer, supports both DPAN and MPAN transaction flows, returns full MPAN metadata for vault storage, and routes recurring Apple Pay charges through the appropriate gateway with correct stored credential indicators applied automatically.

Apple Pay is not the last wallet to move toward merchant-specific tokens for recurring billing, and as other wallets follow the same trajectory, merchants running on Spreedly Connect can onboard new wallet recurring capabilities through the same integration rather than building bespoke recurring billing logic for each one. 

The payments chaos of managing multiple wallet types, multiple token formats, and multiple gateway routing requirements across a growing subscription business is exactly the problem Connect is built to solve.

As Spreedly has already demonstrated with agentic commerce, the infrastructure required for the next generation of automated payments, clean stored credentials, compliant consent records, and intelligent routing, is the same infrastructure required to run Apple Pay recurring billing correctly today.

Get your Apple Pay recurring billing right

Apple Pay's recurring payment infrastructure is mature, well-documented, and now mandatory for any merchant running subscription billing on Visa. The DPAN era for standing instruction transactions is over, and the merchants who transition to MPANs, implement the stored credential framework correctly, and route through a supported gateway are the ones whose recurring revenue survives device upgrades, card reissuances, and the steady churn of customers whose tokens quietly expire without anyone ever deciding to cancel. 

Book a demo to see how Spreedly Connect supports Apple Pay recurring payments, MPAN lifecycle management, and multi-wallet routing for subscription businesses operating at scale.

‍