The Renewal Failed and Nobody Committed Fraud

A subscriber who still wants your product stops paying for it. No cancellation, no complaint, no email. Their card expired, or their bank flinched, and the charge failed. Two weeks later the account switches off and they find out from the login screen. Nobody in that story wanted the outcome.

This is the least glamorous revenue in a subscription business and usually the cheapest to win back, because the customer is already sold. What decides whether you get it is a handful of settings most shops never open.

Why did the payment fail if the customer still wants the product?

Because most renewal failures have nothing to do with the customer's intent. A card reaches its expiry date. A bank declines a recurring charge it does not recognise. A balance runs low for three days. A card is reissued after a breach somewhere else entirely and the number you hold is dead while the account is fine.

The industry term for the result is involuntary churn, and the word involuntary is doing real work. A customer who cancels has told you something. A customer whose renewal failed has told you nothing, and treating the two the same way is how a subscription business loses people it had already convinced.

Stripe's documentation on automating payment retries opens on the useful framing: payments fail for a number of reasons and many of them are recoverable. The whole job is telling the recoverable ones apart from the rest, quickly and without annoying anyone.

Which failures can be retried, and which are a waste of money?

The dividing line is the decline code, and there is a published list of the ones where retrying is pointless. Stripe names nine hard decline codes it will not retry: an incorrect number, a lost card, a pickup card, a stolen card, a revoked authorisation, a revocation of all authorisations, authentication required, highest risk level, and transaction not allowed.

Two of those deserve a second look. Authentication required means the bank wants the cardholder present to approve it, which no background retry can supply. And highest risk level is your own fraud model refusing the charge, which connects this subject to what it costs when fraud software blocks a good order. A renewal that keeps failing on that code is not a billing problem at all.

There is a subtlety in how a hard decline behaves that will confuse anybody reading their own logs. Stripe states that when a hard decline comes back, retries continue to be scheduled and the attempt count keeps incrementing, but the retry only executes once a new payment method appears. Unexecuted retries do not create a charge. So a dashboard showing attempt 5 of 8 does not mean five charges were tried. It can mean one charge failed hard and four scheduled slots passed with nothing happening.

Visa's own grouping is the wider version of the same idea. According to Chargebacks911's account of the excessive reattempts rule, declines fall into four categories: permanent blocks where the issuer will never approve, temporary conditions such as insufficient funds or velocity limits, data quality problems that suggest retrying with corrected details, and a generic bucket where the issuer gave nothing useful. Only the first is a genuine dead end. The third is the interesting one, because it implies retrying the same data forever is the wrong move and asking the customer for details is the right one.

How many retries before the network starts charging you?

Fewer than you would guess, and the published figures do not agree. This is worth showing plainly rather than picking the answer that sounds authoritative:

Two reputable payments sources describing the same private rulebook land five attempts and fifteen cents apart. Neither is being careless. Visa's core rules are not a public document, the fee schedules change, and secondary accounts drift. Payway's version and the one above were both written to help merchants comply.

The practical conclusion is not to split the difference. It is to ask your own acquirer for the reattempt limit and fee schedule that applies to your account, in writing, and to notice that Stripe's recommended 8 attempts in 2 weeks sits comfortably below every published version of the cap. If you build your own retry loop, that headroom is the thing you are spending.

What should the retry schedule actually look like?

Something chosen deliberately, which for most shops means leaving the default alone. Stripe describes Smart Retries as a model picking retry timing from time dependent signals, two of which it names: how many different devices have presented that payment method in the last few hours, and the best time of day to attempt, noting that debit card payments in some countries do slightly better at one minute past midnight local time.

That second detail is a good illustration of why a rules based schedule loses. A human picking retry days will choose round numbers, day 1, day 3, day 7, because those are memorable. The model is aiming at the moment a salary lands in a particular country. You are not going to out-guess that with a spreadsheet.

The settings that matter are the window and the count. Stripe offers 1 week, 2 weeks, 3 weeks, 1 month or 2 months, and recommends 8 tries across 2 weeks. If you write your own schedule instead, you get at most three retries, which is a strong hint about where the value sits. Longer windows are not automatically better either. A customer who has been switched off for six weeks and then successfully charged is a support ticket, not a save.

The wrong field problem

This one costs real money and leaves no trace. Stripe retries against the first available payment method in a fixed order: the subscription's default payment method, then the subscription's default source, then the customer's default payment method, then the legacy customer default source.

The documentation spells out the trap. If a subscription has its own default payment method and you update only the customer level default, retries keep going to the subscription's old card. So the customer types in a new card, your interface accepts it, your dashboard shows a card on file, and every remaining retry hits the dead one. The fix is one line of the documentation: update the field where the payment actually failed. Worth testing once with your own card before you trust the flow.

How long should you keep the account switched on?

Through the retry window, and not much past it. Leaving access on while you chase gives the customer every reason to fix the card, since the thing they are paying for still works. Switching it off on the first failure guarantees a support message and often a cancellation, because the first thing a person does when a service stops is decide whether they miss it.

The counterweight is obvious for anything with a real marginal cost. If each active account costs you money in hosting, licences or delivered goods, an indefinite grace period is a subsidy you did not agree to. A sensible default for a digital product is full access for the length of the retry window, then a read only or paused state rather than deletion, so a customer who returns in March finds their work still there. Deleting on day fifteen saves almost nothing and destroys the only reason they would come back.

For physical subscription boxes the calculation inverts. You cannot un-ship a box, so the shipment has to wait for cleared funds rather than the other way round, and the message to the customer should say exactly that. A missed box with an explanation is a delay. A missed box with silence is a cancellation.

What about direct debit rather than cards?

Different rules, tighter limits, and off by default. Stripe does not automatically retry local payment method failures unless you switch it on, and each scheme has its own ceiling for insufficient funds:

There is also a liability sentence in that section that a careful reader should not skim past. Stripe says that if you enable local payment method retries a payment can still fail, and that it is not responsible for any losses if it does not retry one. Automatic recovery on direct debit is a convenience, not a guarantee, and your own records remain the source of truth for who owes what.

What happens when recovery genuinely fails?

Whatever you decided in advance, which is why deciding in advance matters. Stripe offers three end states after the last attempt, and they behave very differently for a small business.

Cancel moves the subscription to cancelled once the retry window closes. Clean and final, and it ends the billing relationship. Mark as unpaid moves it to an unpaid state while invoices keep generating as drafts, which preserves the record of what was owed without charging further. Leave past due keeps the subscription alive in a past due state with invoices still generating and still attempting according to your settings.

For most one person operations, cancel is the honest choice for consumer plans and unpaid is the better choice where you invoice businesses, because the debt stays visible. Leaving something past due indefinitely is how a shop ends up charging a person who thought they had left, which is the exact situation regulators have been circling. Stripe also notes that changes to these settings only affect future retries, so fixing the setting today does nothing for the subscriber who failed last week.

Whatever you choose, the cash consequence belongs in your forecast. A subscription book with a 3 percent monthly involuntary failure rate does not lose 3 percent of revenue, it loses whatever share of that never recovers, and that is a number you can only get from your own history. It is the same discipline as building a cash forecast on real dates rather than hopeful ones.

Does the law care how you handle this?

Yes, and the picture got more confusing rather than less. The FTC's Click to Cancel rule, which would have required separate consent for an automatic renewal and a simple online cancellation path, was struck down before it took effect. Cooley's write up of the decision records that the Eighth Circuit vacated the entire rule on 8 July 2025, on the ground that the rulemaking process was procedurally defective, six days before the rule was due to take full effect on 14 July 2025.

Reading that as permission would be a mistake. The same analysis lists what survived: ROSCA still requires clear disclosure of automatic renewal terms before you collect billing information, express consent, and a simple means of cancellation. FTC enforcement under Section 5 continues. State automatic renewal laws in California, New York, Massachusetts and elsewhere remain live, with California amendments effective 1 July 2025 and a Massachusetts regulation from 2 September 2025.

So the federal rule died and the obligations it was going to codify mostly already existed elsewhere. For a small seller the practical reading is unchanged: say clearly what renews and when, take real consent, make cancelling easy, and keep the record. A recovery process that quietly keeps charging somebody who tried to leave is not a revenue strategy, it is the thing the state laws are aimed at.

What a dunning email should actually say

Fewer words than you think, and one specific detail. The customer does not know their card failed, does not know which card, and cannot act on a message that says there was a problem with your payment.

Name the card brand and last four digits, say what happens and when if nothing changes, and give one link that goes straight to updating the card. Send the first one immediately rather than after the second failed attempt, because the window where the customer still remembers subscribing is the window where they fix it. Keep the tone neutral. The customer has not done anything wrong, and a payment reminder that reads like a debt letter is how a recoverable renewal becomes a cancellation. The same principle governs the way automated chasing should sound when an invoice is genuinely late.

One more thing worth wiring: the failure event is a signal about the customer, not only about the card. Somebody whose payment fails twice and who has not logged in for a month is probably leaving anyway. Somebody who uses the product daily and whose card expired is a save worth an actual human email. A subscription business that treats those two identically is either wasting attention or losing customers, and the segmentation costs nothing beyond noticing.

Three things to set before your next billing run

All three take minutes, and none of them need an engineer.

First, open the retry settings and confirm the window and the count are something you chose rather than something you inherited. Second, send yourself the dunning email and check that it names a card and links straight to a working update page, then check that updating the card there actually clears the next retry rather than writing to a different field. Third, pick the end state on purpose, and make sure a cancelled subscriber can still see what they had and come back.

Recovered renewals are the most boring growth available to a subscription business and among the cheapest. A shop that runs its own billing and owns the records behind it can look at last quarter's failures, count how many never came back, and price the fix in an afternoon. Most never look, which is why the setting nobody opens is usually the one with money behind it.