Subscription payment recovery: retries, account updater and dunning

A subscription business works hard to win a customer and then can lose them without anyone deciding anything. The card on file expires, the bank replaces it after a fraud alert, or the account is a little short on renewal day. The customer still wants the service. The payment simply fails, and if nothing happens next, the subscription ends.

This article covers how to recover those payments: why renewals fail, how account updaters and network tokens keep stored cards current, how to schedule retries, why the flags on each renewal matter, what dunning emails should do, and which local recurring methods help outside card markets. Which decline codes to retry is covered in soft vs hard declines, and how tokens differ in network tokens vs PSP tokens. Here we put the pieces together for subscriptions.

What is involuntary churn, and how big is it?

Involuntary churn is losing a customer who did not choose to leave. Mastercard’s developer page for its Automatic Billing Updater cites two figures from third parties: 40% of cardholders replace their cards every year because of expiry, loss or fraud, according to Worldline, and 1 in 4 lost subscriptions result from involuntary churn caused by payment declines, according to Recurly. These are other companies’ numbers, quoted by a card scheme selling an updater service, so treat them as an order of magnitude. Your own figure comes from your own decline data.

The useful split is between failures the merchant can fix without the customer and failures only the customer can fix. Recovery design is mostly about moving payments from the second group into the first.

Why do recurring card payments fail?

Cause	What the issuer says	Who can fix it
Card expired or replaced	Expired card, invalid account	Merchant, with an updater or network token; otherwise the customer
Short-term funds problem	Insufficient funds, amount limit	Time: a later retry
Issuer wants authentication	Authentication required	The customer, on-session
Card closed, lost or stolen	Closed account, lost or stolen card	Only the customer, with a new card
Customer stopped the payments	Stop payment, revocation	Nobody: stop charging
Technical failure	Issuer unavailable, system error	Merchant: retry or another route

The response codes behind each row, and which ones the card schemes forbid you to retry, are listed in our article on soft and hard declines. Stripe’s billing documentation follows the same split: it does not automatically retry renewals after hard declines such as lost or stolen card, incorrect number, revocation of authorization or authentication required, and only executes scheduled retries once the customer adds a new payment method.

How do account updaters keep stored cards current?

An account updater is a card scheme service that tells the merchant when a stored card has changed. Visa describes Visa Account Updater as a service that lets issuers, acquirers and qualified merchants exchange updated card numbers, expiry dates, closed accounts and cardholder advices for recurring and credential-on-file payments. It covers renewals and replacements, upgrades and downgrades, portfolio moves between banks, account closures and lost or stolen card replacements.

Mastercard’s Automatic Billing Updater does the same for Mastercard cards and offers two models: a push model, in which merchants and acquirers receive notifications when a subscribed account changes, and a pull model, in which they query for updates before a card-not-present payment. Mastercard says merchants using credentials available from the updater see 3.8 times higher transaction approvals, based on its own data.

Three practical points:

• Coverage is uneven. Stripe says automatic card updates are widely supported in the United States but that international support varies by country, and that it is not possible to identify in advance which cards support updates. In CIS, MENA and LATAM markets, assume a share of stored cards will never be refreshed this way.
• Run the update before the renewal, not after the decline. A pull query before the billing run avoids a decline altogether.
• Update refunds too. Visa’s guidance to acquirers on refund authorization suggests including accounts to be refunded in the updater file, so refunds to replaced cards do not fail.

How do network tokens help?

A network token is a scheme-issued stand-in for the card number that stays valid when the underlying card is reissued, so the merchant does not need to learn about the new card at all. For subscriptions this is the strongest fix for the first row of the table above, where it is supported. The differences between scheme tokens and provider vault tokens, and how to combine them across providers, are covered in network tokens vs PSP tokens. For recovery, the rule is simple: use network tokens wherever your processing provider supports them, keep account updaters for cards that are not tokenized, and measure expired-card declines on renewals to see how much is still slipping through.

How should retries be scheduled?

Retries recover the middle rows of the table: funds, limits and technical failures. The schedule matters more than the count.

Spread the attempts. Stripe lets merchants set a Smart Retries policy over 1 week, 2 weeks, 3 weeks, 1 month or 2 months, and recommends a default of 8 tries within 2 weeks. Its custom schedules allow up to three retries, each a set number of days after the previous attempt. A renewal that fails on insufficient funds is more likely to succeed after the customer’s next salary than an hour later.

Respect the scheme limits. Visa caps reattempts and charges for excess ones, and Mastercard sends merchant advice codes that tell you when to retry an insufficient funds decline and when to stop. Our soft vs hard declines article has the limits and fees. A schedule of 8 tries in 2 weeks fits within them only if every attempt is counted per card across all your providers.

Retry the right thing. Only a soft decline deserves a retry. A technical failure can go to another eligible provider at once; an insufficient funds decline should wait; a hard decline should trigger a request for a new card, not another attempt.

Direct debits have their own rules. Stripe retries a failed SEPA Direct Debit payment at most twice, within 30 days of the original attempt, and only for insufficient funds, because the debit takes several business days to complete.

Why do MIT and CIT flags matter?

Because the issuer decides differently when it knows the customer agreed to be charged. Visa Acceptance Solutions’ credentialed transactions guide sets out the sequence. The first payment is a customer-initiated transaction, in which the merchant must get the customer’s consent to store their credentials and flags the payment as storing them. Later renewals are merchant-initiated transactions, processed without the customer’s active involvement, flagged as recurring, instalment or unscheduled, and carrying the transaction ID of the original payment.

Getting this wrong costs approvals. A renewal sent as if the customer were present can be challenged for authentication that nobody is there to complete. A renewal without the original transaction reference looks like a fresh card-not-present payment from an unknown merchant. Our credential on file entry explains the terms; the practical rule is to store the original transaction ID with every subscription and send it with every renewal, whichever provider processes it.

What should dunning emails do?

Dunning is the sequence of messages that asks the customer to act when the merchant cannot fix a payment alone. Stripe’s billing documentation describes the main ones: an email after each failed payment with a link to update the payment method, an email one month before a stored card expires, reminders when a payment needs the customer to confirm it, for example with 3-D Secure, and renewal reminders before the period ends.

Good dunning follows a few rules:

1. Send it when the customer can act. A pre-expiry email a month ahead turns a future decline into a card update.
2. Link straight to the fix. One click to a page where the customer can update the card or pay the open invoice.
3. Match the message to the cause. “Your bank asked you to confirm this payment” and “your card has expired” need different calls to action.
4. Decide the end state in advance. Stripe lets merchants cancel the subscription, mark it unpaid, leave it past due or pause it once retries are exhausted. Pausing keeps the customer relationship without giving away the service.

Can local methods carry recurring payments?

Increasingly, yes, and they matter in markets where card penetration is low.

Pix Automático in Brazil. Agência Brasil reported that Pix Automático launched as an optional service in June 2025 and became mandatory on 13 October 2025. The customer authorizes the merchant once in their banking app, choosing the frequency, a fixed or variable amount and a maximum per transaction, and can cancel or adjust it at any time. Only individuals can pay with it, and the merchant must have been operating for more than six months. Stripe’s documentation adds the mechanics on its side: each recurring charge triggers a pre-debit notice and a 3-day wait, the payment shows as processing in that period, confirmation can take up to 7 days with retries, and charges above the authorized amount fail.

Direct debits in Europe. SEPA Direct Debit supports recurring payments under a mandate. Stripe notes that the customer can dispute a debit through their bank on a no questions asked basis for eight weeks, so clear pre-notification and an easy cancellation path reduce disputes more than any retry rule.

Offering a local recurring method alongside cards gives a customer whose card keeps failing a second route that does not expire.

Worked example: a month of failed renewals

Example figures, for illustration only.

A streaming service bills 50,000 subscribers a month by card and sees 4,000 renewals fail.

Cause	Failed renewals	Recovery step	Recovered (assumed)
Expired or replaced card	1,400	Updater or network token before billing	900
Insufficient funds or limits	1,600	Spread retries over 2 weeks	800
Authentication required	300	Dunning email to confirm	120
Lost, stolen or closed	500	Dunning email for a new card	100
Technical	200	Retry on another eligible provider	180
Total	4,000		2,100

Under these assumptions, a merchant with no recovery process loses 4,000 subscribers this month, and one with all four steps loses 1,900. The largest single gain comes from fixing stored card data before the billing run, not from retrying harder.

What are the common mistakes?

• Retrying hard declines, which costs scheme fees and recovers nothing.
• Running every retry on the same day, before the customer’s funds have changed.
• Sending renewals without the merchant-initiated flag and the original transaction ID.
• Emailing about a failed payment with no link to fix it.
• Treating card recovery as the only option when the customer could switch to a local recurring method.

Where does Omno fit?

Recurring payments through Omno are not available yet; they are on the roadmap, so the billing schedule, renewals and dunning stay in your subscription system. What Omno does today is store saved cards as tokens at the orchestration layer rather than in one provider’s vault, so returning customers can pay without re-entering their card details. A payment with a saved card follows the routing rules you set, and if a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. The transaction trail shows every attempt, provider response and webhook, and the final status of every payment arrives by webhook. Whether network tokens or account updater services are applied depends on the connected provider. The tokenization and saved cards page has the details.