Apple Pay and Google Pay Subscriptions: Why Visa Is Declining Device-Bound Tokens

A subscriber pays with Apple Pay at signup. Renewals go through cleanly for eight months. Then, with no warning and no expired card involved, the next charge fails. Nothing changed about their bank account, their credit limit, or their card. What changed is that they upgraded their phone in the spring, tapped through Apple's "transfer your data" flow, and never thought about it again — because from where they were sitting, nothing about their wallet looked different. Behind the scenes, the token your payment processor had on file for that subscription stopped existing the moment the old device was set aside.

This is a different failure mode from anything covered in our guides to card account updater or Stripe dunning. Those tools fix a stale card number or a temporarily declined charge. This one is about the tokenization architecture underneath a wallet payment method — and it's specific enough, and new enough, that most dunning stacks have no idea it's a distinct category at all.

What a DPAN actually is

When a customer adds a card to Apple Pay or Google Pay, the wallet doesn't store the actual card number on the device. It requests a token from the card network — a Device Primary Account Number, or DPAN — that stands in for the real card and is cryptographically bound to that specific piece of hardware. Every transaction from that device carries a fresh, per-transaction cryptogram, and the real PAN never has to leave Apple's or Google's secure element. This is genuinely good security design for point-of-sale and in-app purchases: even if the token leaked, it's useless anywhere but that one device.

The design that makes DPANs safe for a coffee shop tap is exactly what makes them fragile for a subscription. A DPAN is invalidated whenever the customer removes the card from Wallet, resets the device, or upgrades to a new phone without the transfer preserving wallet cards correctly — none of which the customer experiences as "cancelling a subscription," because from their side of the screen, they haven't touched your product at all.

Why Visa is pushing standing instructions off device tokens

Visa's answer is to stop treating DPAN-based recurring charges as reliable for merchant-initiated billing at all. Per the policy reported by ACI Worldwide and documented across Apple's own developer forums, device-bound standing instructions built on a DPAN issued after July 30, 2025 are subject to decline, and merchants are directed to move recurring and subscription charges onto merchant tokens instead. Instructions already running on DPANs issued before that date are grandfathered — but only until the token itself breaks, which happens on the same device-upgrade schedule described above. The grandfathered pool doesn't fail all at once; it erodes one phone upgrade at a time.

Compiled from Apple Developer documentation, Very Good Security's tokenization guides, and Stripe's Apple Pay merchant token documentation.

Why this doesn't look like a normal decline

The reason this category is easy to miss is that a DPAN failure doesn't announce itself the way an expired card does. There's no card_expired reason code, no obvious "please update your payment method" trigger, because as far as the customer's bank is concerned, nothing about their underlying card changed at all — the card is still open, still funded, still theirs. What failed is a token that existed one layer above the card, in a system most subscription teams never look at because Apple Pay and Google Pay have historically just worked. Depending on how your processor classifies it, this can surface as a generic decline, an authentication failure, or a token-not-found error that lands in whatever bucket your dashboard uses for "unexplained."

That matters because your recovery playbook depends entirely on correctly identifying the failure. Smart Retries assumes the underlying payment method is temporarily unavailable and will work again later — true for insufficient funds, false for a token that no longer exists. A pre-expiry reminder email assumes the customer knows their card is about to lapse — but nothing lapsed from their perspective. Sending either of those in response to a dead DPAN just burns a retry attempt and a support ticket on a fix that can't work.

The stakes here scale with how much of your base pays through a wallet, and that share skews toward exactly the subscribers you most want to keep — the ones who signed up recently, on a newer phone, with the fastest checkout you offer them. A subscription business with a young, mobile-first user base isn't looking at an edge case; it's looking at a growing slice of renewals routed through the payment method most exposed to this failure mode.

What Stripe does about it, and what's on you

If you take Apple Pay or Google Pay through Stripe's standard integration — Elements, Checkout, or the mobile SDKs — Stripe requests a merchant token rather than a device token for saved payment methods used in off-session, recurring contexts, and this runs as part of the same network tokens infrastructure covered in our card account updater guide. You don't configure DPAN versus MPAN per transaction; it's handled by Stripe's tokenization layer, bundled with card account updater and Adaptive Acceptance into Authorization Boost. The gap shows up in two places worth checking directly:

• Custom or legacy integrations. If your Apple Pay or Google Pay flow predates Stripe's current subscription tooling, or if it stores a payment method token captured outside the standard SetupIntent flow, confirm with Stripe that those saved methods are eligible for merchant tokenization rather than silently falling back to whatever token type was available at capture time.
• Decline-reason granularity. Pull your failed-payment logs and check whether wallet-token failures are distinguishable from generic card_declined reasons. If they're not broken out separately, you have no way to measure how much of your involuntary churn this specific mechanism is responsible for, and no way to tell whether enabling network tokens actually moved the number.

Where this fits in your involuntary churn reporting

Treat a dead wallet token as its own failure category, not a subspecies of card decline. It behaves differently at every stage: it isn't fixable by retry timing like a soft decline, it isn't fixable by a pre-expiry email like a card nearing its expiration date, and it isn't fixable by a fresh authentication prompt like an SCA challenge. The only fix is the customer re-entering their payment details — through your customer portal, a checkout link, or your cancellation flow if that's where they land after losing access, since from their side of the screen the product just stopped working one day with no explanation.

The practical move is to write a dunning email variant specifically for this case — one that says plainly "your Apple Pay / Google Pay payment method needs to be re-added" instead of the generic "your card was declined" copy that sends a confused customer to double-check a card that was never the problem. A customer who removed a subscription's payment token by upgrading their phone isn't disengaged and isn't price-sensitive; they're the easiest possible save if you catch it with the right message, and the worst kind of silent, misdiagnosed loss if you don't. You can model what a percentage point of recovered involuntary churn is worth to your business with our churn calculator, using your Apple Pay / Google Pay subscriber share as the segment to isolate — it's a fast-growing input, not a rounding error.

None of this is a cancellation decision in the ordinary sense — nobody clicked cancel, nobody read a save offer, nobody weighed staying against leaving. That's exactly why it's worth fixing upstream of your involuntary churn recovery flow rather than downstream in a cancellation flow. A tool like CancelFlow is built for the moment someone consciously decides to leave; a dead wallet token never gives you that moment at all, just an account that goes quiet because a piece of infrastructure the customer never knew existed stopped working on their behalf.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.