A failed renewal is 3 different problems, and retrying harder only touches 1 of them

A subscription merchant showed me a dashboard with 14 per cent of renewals failing each month and a retry setting turned up to the maximum. I told him to retry harder and more often. That was bad advice, and I had assumed for years that a failed renewal is a timing problem, when a large share of them are a data problem or a hard decline that no amount of retrying will ever move.

So recovering failed subscription payments turns out to be 3 different jobs wearing 1 name. I went looking for what the networks and processors actually publish about each of them, which took most of an afternoon, and the useful material sat in 2 places: Visa’s own description of its account updater and Stripe’s documentation of how its retries behave.

Job 1: the card changed, and your file did not

Cards get reissued constantly, for expiry, loss and fraud, and every reissue silently breaks every subscription stored against the old number. Visa’s answer is Visa Account Updater, which it describes as a “secure electronic exchange of account information updates between participating Visa card issuers and acquirers for credential-on-file merchants”.

I had never read how this works, and the mechanics turn out to be specific. When participating issuers re-issue cards, they “submit the new account number and expiration date” to the service. They also report whether “an account is closed or a card holder has opt-out out”. Merchants, through their acquirers, send inquiries on the cards they hold and get back updated details where they exist.

The responses come in 3 kinds, and I would treat each of them as a separate instruction rather than as 3 flavours of the same update, because a system that reacts to all 3 the same way will keep charging a closed account, keep swapping a card that the holder has asked not to be updated, and keep waiting for a machine to solve something only a person can answer. An account number or expiry update means you swap the card and charge again. A closed account advice means stop retrying that card at all. A contact cardholder advice means the fix is a human conversation, not a system action.

One word carries a lot of weight here. Participating appears on both sides, and it matters. An issuer that does not participate never sends an update, and a merchant whose acquirer does not enrol it never asks. I cannot tell you what share of cards is covered, because the page does not say, and I have not found a Visa figure I would repeat.

I went through this with the merchant from the top on a call, card by card for his largest 20 accounts, and it was a slightly uncomfortable hour. Nine of the 20 failures were reissued cards. His processor offered an updater, it had been switched off, as far as anyone could tell ever since the account was opened 3 years earlier, nobody on his team knew it existed because it lived on a settings page nobody had any reason to visit, and for 3 years every reissued card in his base had quietly turned a loyal customer into a failed renewal. I would rather have found that before telling him to retry harder.

Job 2: the decline that retries cannot touch

This part changed my advice. Stripe’s documentation says plainly that if a failure “returns a hard decline code, we can’t retry invoice payment without a new payment method”.

Then it describes what happens to the retries anyway, and it is quietly revealing. Retries “continue to be scheduled, and attempt_count continues to increment, but retries only execute after detecting a new payment method”. And “Unexecuted retries don’t create a new Charge.”

So a dashboard can show a subscription at attempt 6 of 8 when not a single charge has been tried since the first hard decline. The counter measures the schedule, not the effort. That merchant’s maximum retry setting was spending a counter, not a chance, on every hard decline in his base, and I find it hard to read that paragraph without thinking about how confidently I told him to turn it up.

Job 3: the decline that timing really does fix

Retries earn their keep on the remaining failures, where the card is valid and the moment was wrong. Stripe says its Smart Retries use AI to choose “the best times to retry failed payment attempts” from time-dependent, dynamic signals.

The settings are concrete. You can let it retry “a specific number of times within a time period: 1 week, 2 weeks, 3 weeks, 1 month, or 2 months”, and the recommended default is “8 tries within 2 weeks”. A custom schedule is narrower: up to 3 retries, each set a fixed number of days after the previous attempt.

My guess is that the default exists because 2 weeks covers a typical pay cycle, but that is a guess about the design rather than anything the documentation states, and I would not build a policy on my reading of it.

What happens at the end of the schedule

When the retries run out, the subscription has to land somewhere, and Stripe offers 2 endings with different consequences. It can move to canceled after the maximum number of days in the schedule. Or it can be marked unpaid, in which case “Invoices continue to be generated and stay in a draft state”.

The second option is the one I would pick for most businesses, with a caveat. An unpaid subscription keeps the relationship and the invoice trail alive, which makes recovery by email possible later, but it also keeps generating drafts that someone has to read, and a finance team that never looks at drafts has simply hidden its churn inside a status.

The same 14 per cent, sorted

Here is the sort done on paper, with illustrative numbers rather than that merchant’s real ones, because the shape is the point. Take 2,000 renewals a month with 14 per cent failing: 280 failures. Suppose the sort gives 90 reissued or expired cards, 60 hard declines and 130 soft declines.

Turning retries up to the maximum touches only the 130. The 60 hard declines accumulate attempts that never execute, and the 90 reissued cards fail on every attempt because the number itself is dead. So the setting he maximised addressed less than half of his problem, 130 out of 280, and the other 150 needed a data fix and an email.

Now apply the right lever to each group. An account updater that returns new details for, say, 2 in 3 of the 90 reissued cards rescues 60 renewals with no customer action. A same day message to the 60 hard declines, if 1 in 3 responds, rescues 20 more. Retry timing works on the 130. None of these percentages are measurements. They are placeholders so the arithmetic is visible, and your own sort replaces them in an afternoon.

The lesson survives any realistic numbers. When the 3 groups are mixed into 1 retry setting, the biggest lever is the one being ignored, and in most subscription bases I have looked at that lever is the reissued card rather than the timing.

How I would set this up now

Split the failures before tuning anything. Pull 1 month of failed renewals and sort them into reissued cards, hard declines and soft declines, because each group needs a different lever and a single retry setting treats them as one.

Turn on the account updater through your acquirer if it is available, since it fixes the first group without the customer lifting a finger. For hard declines, stop counting retries as effort and send the customer a message asking for a new card the same day, because no schedule will execute until they do. Leave retry timing to govern only what is left.

And watch the right number. Attempt count is a schedule metric. Recovered revenue per failed renewal, split by the 3 groups, is the metric that tells you which job you are actually bad at.

Questions we get

These arrive from subscription businesses the month churn stops making sense, and 2 of the 5 are really the same question about hard declines.

How does a card account updater work? Participating issuers send new account numbers and expiry dates when they reissue cards, plus closed account and opt-out information. Merchants ask through their acquirers about the cards they store and receive updates where available.

Should I retry after a hard decline? Not without a new payment method. Stripe keeps scheduling retries and incrementing the attempt count, but they only execute once a new payment method is detected, and unexecuted retries create no charge.

What is a sensible retry schedule for subscriptions? Stripe’s recommended default for Smart Retries is 8 tries within 2 weeks, with policy windows from 1 week to 2 months. A custom schedule allows up to 3 retries at fixed day intervals, which I would only choose if you already know from your own data which days of the month your customers get paid, because a fixed interval that lands on the wrong side of a payday is simply a slower way of declining the same card 3 times.

What should a dunning email say? For a hard decline, ask for a new card directly and early, because nothing else will work. Keep it to 3 sentences and 1 link. For a contact cardholder advice from the account updater, the message is the fix, so it should be the first action rather than the last.

Canceled or unpaid when retries run out? Canceled ends the subscription after the schedule, and I use it only when the product has nothing to deliver to a customer who has stopped paying, since it closes the door on any later recovery. Unpaid keeps generating invoices as drafts, which preserves the relationship but needs someone to read the drafts, otherwise it hides churn instead of recovering it.

A short digression about the word retry

Retry sounds like effort. Effort sounds like recovery. In a system where scheduled attempts can increment without executing, a retry is sometimes just a row in a table, the word flatters the number, and a monthly report that says a subscription was retried 8 times can describe a card that was actually charged once, declined hard, and then left alone for 2 weeks while a counter climbed on its own. I still find that one sentence about unexecuted retries more useful than any recovery rate a vendor has ever quoted me. Anyway, back to the 3 groups.

What is not settled here

How much revenue an account updater recovers. The Visa page describes the mechanism and gives no figure, and I do not know of a published number I trust.

The network rules on how many times you may retry a declined card. Those rules exist, they were outside this piece, and nothing above describes them.

How well Smart Retries performs. The documentation describes the policy and not its results, and a vendor’s own case study is not something I would put in front of a finance lead as evidence.