Most failed payments are not lost customers. They are expired cards, bank declines, and maxed limits — all fixable, usually by the customer, in under a minute. A dunning process exists to make that fix easy and to make the rare real decision — pause or cancel — deliberate instead of accidental.
The shape of a recovery timeline
A timeline that works for small B2B SaaS looks roughly like this:
- Day 0 — payment fails. Record the state on the invoice. Do not change the subscription yet.
- Day 1-2 — first retry. Many declines clear on their own; card networks often resolve temporary holds within a day.
- Day 3-5 — notify the customer clearly, with a link to update their payment method. This message recovers more revenue than any other step.
- Day 7-10 — second retry after the update prompt.
- Day 14-21 — final decision: pause the subscription or cancel it, explicitly, with the record showing why.
Write to the customer, not about the transaction
The recovery email has one job: get a card updated. Say what happened in plain language, say what happens next and when, and link directly to a payment-method update. No shame, no legalese. In Canada, bilingual obligations reach into collections-adjacent messaging — French is a requirement, not a courtesy.
Self-service beats email ping-pong
Every message should land on a page where the customer can fix it themselves: see the invoice, update the card, see the result. A portal that accepts a payment-method update recovers revenue at 2 a.m. without anyone on your team awake.
Keep the cancel decision human
Auto-cancel on the third failed retry feels efficient and quietly churns fixable customers. Keep pause and cancel as explicit operator decisions, backed by the retry history and an audit trail. When someone asks why you lost an account six months later, the answer should be one click away.
Measure two numbers
- Recovery rate — of payments that failed, how many eventually paid. Healthy processes recover the large majority.
- Involuntary churn — customers lost purely to payment issues. If it exceeds voluntary churn, your dunning is the problem, not your product.
The state machine behind the timeline
Dunning is a state machine with a human at one transition. Make the states explicit in your system, because every tool — billing, product, email — will need to agree on them:
- paid — nothing to do
- failed — charge declined; clock starts
- recovering — retry scheduled; customer notified
- recovered — payment collected; state closes
- paused — operator decision after the final notice; data intact, billing suspended
- canceled — explicit end, by policy or by customer
The transitions that matter are recovering → paused and paused → canceled: both should require a human action and both should be auditable. Everything else can be automatic.
Trials, upgrades, and other payment moments
- Trial with card capture. Verify the card with a $0 or $1 authorization at trial start. Dunning at conversion fails far less when the card was validated up front.
- Failed capture at conversion. Do not silently downgrade to a free plan — the customer believes they upgraded. Fail loudly, in-product, with one update link.
- Annual invoices. One failure covers twelve months of service. A $1,200 failed charge deserves a direct email from a human, not template three of seven.
Card updater networks, honestly
Most major processors offer account updater services that refresh expired or reissued cards automatically before you ever email the customer. They genuinely reduce dunning volume — and they have consent nuances by region, so confirm how your processor handles enrollment and whether customers can opt out. Automatic recovery first, human recovery second, is the right order.
Two emails that do most of the recovering
The card-expired email (day 3-5).
Subject: Your Floatless invoice needs an updated card
Hi Sam — the card on file for your workspace (ending 4242) was declined on September 12. Nothing is wrong with your account; the card has most likely expired.
Update your payment method here: [billing.floatless.ca/payment-method]
We will retry the charge on September 17. If the card is updated before then, nothing else is needed.
— The Floatless team
The final notice (day 14+).
Subject: Action needed: your workspace pauses on September 26
Hi Sam — we have not been able to collect the September invoice after three attempts. To avoid interruption, please update your payment method by September 26.
Update payment: [billing.floatless.ca/payment-method]
If the invoice remains unpaid after September 26, your subscription will pause. Your data stays intact and billing resumes the moment the payment method is updated.
— The Floatless team
La version française (exigence, pas option, au Québec).
Objet : Mise à jour de carte requise pour votre facture Floatless
Bonjour Sam — la carte enregistrée pour votre espace de travail (se terminant par 4242) a été refusée le 12 septembre. Votre compte est en bon état; la carte a probablement expiré.
Mettez à jour votre mode de paiement ici : [billing.floatless.ca/payment-method]
Nous réessayerons le paiement le 17 septembre. Si la carte est mise à jour d'ici là, aucune autre action n'est nécessaire.
— L'équipe Floatless
Both do the same four things: say what happened, say what happens next and when, give one link, and reassure that data is safe. In Quebec, customer-facing billing messages like these should be available in French — treat it as product quality, not paperwork.
The recovery math
Say 40 payments failed in a month. After retries and card updates, 29 eventually paid.
- Recovery rate: 29 / 40 = 72.5 percent
- Involuntary churn: 11 customers lost to payment issues, not product issues
Now the useful question: of those 11, how many contacted support or opened the email? If most never opened anything, your timing or sender is broken. If they opened and still churned, your offer or product moment is the problem. The numbers tell you where to look.
What to gate during a grace period
When an invoice is overdue, decide what the customer loses and when:
| Stage | Keep on | Gate |
|---|---|---|
| Days 1-7 past due | Everything | Nothing |
| Days 8-14 | Read access, data export | New usage, premium features |
| Day 15+ | Data export | Everything but account access |
Never hold data hostage. Blocking export during a payment dispute turns a recoverable invoice into a trust problem and, eventually, a chargeback.
Frequently asked questions
How many retries before we cancel? Two to three retries over two to three weeks, with a card-update prompt between each. Cancellation should be a decision, not the automatic end of a counter.
Should dunning emails come from a no-reply address? No. A failed payment is exactly when a customer might want to reply. Use an address a human reads.
Do we pause or cancel at the end? Pause. It preserves the relationship, the data, and the restart path. Cancellation is for explicit customer requests or clear non-payment policy after a pause period.
What about annual plans with one failed payment? Same flow, higher stakes — one failure covers a year of service. Prioritize a human touch (a direct email or call) over automation for annual invoices.
Where this lives in Floatless
Failed-payment state is tracked per invoice, retries run against customer billing state, the customer portal handles payment-method updates, and webhooks let your product react to payment events — dunning management covers the workflow, and the webhooks API drives product-side reactions.