In this guide 6 sections
Sort each failed renewal by cause first: expired card, bank decline, broken mandate or a customer who forgot. Each cause needs its own fix. Then set a retry schedule, plain reminder emails, a short grace period and a staged limit on access, so a payment problem never turns into a lost account.
Four causes hide behind one failed charge
Your payment gateway returns a decline code with every attempt. That code is the diagnosis. Read it before you write a single retry rule. A retry that suits one cause wastes attempts on another.
Expired or replaced cards cause the most quiet churn. The number changed after a lost card, the customer never noticed, and the renewal bounced. Bank declines come from the other side: low balance, a fraud hold or a blocked merchant category. Mandate failures hit direct debit and card-on-file agreements that were cancelled or never confirmed.
The fourth group is plain. The customer forgot, or the invoice landed in a shared inbox that nobody opens.
- Expired or replaced card: codes such as expired_card or invalid_account
- Bank decline: insufficient funds, do_not_honor, suspected fraud
- Mandate failure: revoked, expired or unconfirmed debit authorisation
- Forgetful customer: no decline at all, only an unpaid invoice
- Gateway or network error: a timeout that says nothing about the customer
Set retry rules that match the cause
Never retry a hard decline. A card reported lost will not work on day three. Retrying only adds noise to the issuer’s record and can push your merchant account toward a review.
Soft declines are different. A low balance often clears after payday, so schedule the second attempt a few days later and the third near the start of the next month. Timeouts get an immediate retry with the same idempotency key, so the customer is never charged twice.
Log every attempt against the invoice. Support should see the code, the date and the next scheduled try on one screen.
Write reminders a customer will actually act on
Say what happened, what it costs them and what to click. Skip the legal tone. Be plain. A subject line such as “Your card ending 4421 was declined” gets opened because it names a fact.
Send the first note the moment a charge fails, a second halfway through the grace period and a final notice one day before access changes. Each message links straight to a hosted card-update page that needs no login. Every extra step between the email and the form loses people.
For expired cards, write before the failure too. A courtesy email a fortnight ahead of expiry catches most of them while the customer is calm.
- Day 0: charge failed, update link, plain reason
- Day 3: reminder, invoice attached, support reply address
- Day 7: final notice stating the exact date access will narrow
- After payment: a receipt that confirms the account is whole again
Choose a grace period and a ladder for access
A grace period is the stretch where the customer keeps full access while the retries run. Pick a length from your own recovery data. Count the late payments that arrive on day two, day five and day ten, then set the line where recoveries thin out.
After that, limit access in steps rather than cutting it off. First show a banner. Then make the account read-only. Last, suspend logins but keep the data. Never delete anything during a billing dispute. Ever.
Decide who may override. A finance lead should be able to extend grace for one account, and the extension should leave an audit entry with a name and a reason.
Measure recovery and close the loop
Track involuntary churn separately from cancellations. A customer who left because a card expired never chose to leave, and the fix belongs to billing, not to the product team.
Review recovered invoices by cause each month. If mandate failures recover poorly, move those customers to card payment. If forgetful customers dominate, send the invoice earlier and to more than one contact. Start this week by exporting last quarter’s failed charges and sorting them by decline code.
Failed payment triage sheet
One page lists every decline code your gateway returns, a row for each. Columns hold the cause group, retry or no retry, days between attempts, the reminder template to send, the grace period and the access step reached. A second block lists override owners and the audit note required.
Open a blank worksheet to printQuestions owners ask
How many times should a failed subscription payment be retried?
It depends on the cause. Hard declines get no retry. Soft declines usually get three or four attempts spread over the grace period. Use your own recovery data to find the point where extra attempts stop paying off.
How long should the grace period be?
Long enough to cover a payday cycle and a reminder sequence, short enough that unpaid use stays small. Many teams settle on one to two weeks, then adjust once they see when late payments arrive.
Should we cancel the subscription after the last failed attempt?
Move to a limited state first. Read-only access with the data intact lets the customer come back by fixing the card. Cancel only after a stated further period, and tell them the date.
Do we need a dunning tool or can the app do it?
Gateways include basic retries. A custom build adds rules by cause, per-account overrides and access limits tied to your own product. Start with the gateway and build more when recoveries plateau.