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.
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.