A failed recurring charge is not a customer who left. The order of operations - automatic retries, a reminder, a channel switch, a call - and when to stop.
Key takeaways
- Most failures resolve with a retry or a card update, with no conversation.
- Order matters: automatic first, then a message, then another channel, and only then a call.
- Service cut off mid-stream triggers cancellations, even when the failure was technical. Decide where to stop.
- What to measure: failure rate, recovery rate, and how many days until the money arrives.
A failed recurring charge is usually a fault, not a decision. A credit limit reached mid-month, a replaced card, an expiry date passed - in all of those the customer still wants the service. The recovery ladder exists to collect the money without turning a technical fault into a conversation about cancelling.
The ladder, in order
| Step | What happens | Timing | Who does it |
|---|---|---|---|
| 1 | Automatic charge retry | After 1-3 days | The system |
| 2 | Second attempt, after the month turns | After 5-7 days | The system |
| 3 | Message to the customer with a link to update the payment method | Immediately after the second attempt | The system |
| 4 | Second reminder on another channel | After 3-5 days | The system |
| 5 | Phone call | 10-14 days after the first failure | A person |
| 6 | Decision: pause, payment arrangement, or end | After the call | A person |
The timing in step 2 is the practical detail that changes outcomes: a failure caused by a monthly credit limit often resolves itself once the next month begins and the limit resets. A retry scheduled for the start of the month collects subscriptions that a same-day retry would not.
Why not start with a call?
Because a call turns a technical fault into a decision point. A customer told their card expired updates it in thirty seconds; the same customer on a phone call about a debt asks themselves whether they need the service at all. That is why the order alone saves money, without improving any mechanism.
There is one exception: a large customer, or one whose charge has failed three months running. There the call comes earlier, because there is something to find out.
What to write in the message
This message is written once and used for years, so it is worth getting right:
- What happened, without blame: "the monthly charge did not go through".
- Why, if known: an expired card is a reason you can state; "declined" tells the customer nothing.
- The last four digits of the card on file, so they recognise what this is about.
- A direct update link, not instructions.
- What happens if they do not update, and when. Without that there is no urgency.
- How to reach you if there is a problem. A customer who wants to pay and is blocked needs a way to say so.
What does not go in: a request to send card details in reply, threats, and a detailed description of the decline code. You need the codes, not the customer - and what to do with them is in the decline code workflow.
The three failure causes, and what each one needs
Not every failure is the same, and the handling should match the cause:
| Cause | How to spot it | What works |
|---|---|---|
| Credit limit exhausted | Common at month end, and repeats on the same customer | A retry at the start of the next month. Usually resolves with no message |
| Card expired | The expiry on file has passed or is close | A message with an update link. Retries will never help |
| Card replaced or blocked | A sudden failure on a stable customer | A message, then a call. That card will not start working |
| Unusual amount | The failures began right after a price change | Check your change notice before blaming the customer |
The second row is what wastes effort in systems that do not distinguish: a retry on an expired card will fail on the fifth attempt too. A system that separates the causes sends the message immediately instead of retrying, which shortens time-to-collection by a week.
When do you cut off the service?
That is a business decision rather than a technical one, and it should be defined in advance rather than by mood. Practical considerations:
- Service cut off immediately produces cancellations even among customers whose failure was technical.
- Service never cut off produces accumulating debt and customers who get used to it.
- The common middle model: cut off after the ladder is exhausted - that is, after the call, not before it.
- In a service holding customer data, separate blocking access from deletion. Deletion is irreversible; blocking is not.
And after a cut-off, explain exactly what needs to happen to come back. A cut-off with no clear route back is a cancellation, whether or not you called it one.
What to measure, monthly
- Failure rate: how many charges failed out of active subscribers.
- Recovery rate: what share was eventually collected, and at which step of the ladder.
- Time to collection: average days from failure to money received.
- Churn after failure: how many failed customers cancelled within three months.
The fourth metric is the one that exposes a ladder that is too aggressive. If the recovery rate is high and churn has risen, you collected the month and paid for it with a customer.
What to do with a customer who has failed three months running
That is no longer a technical failure but a signal, and usually one of three: the customer is in difficulty, the card they gave is not the card they use, or they do not really want the service and never bothered to cancel. One call separates the three.
What to offer on that call: moving to a different collection rail - a bank mandate instead of a card - changing the charge date to the start of the month, or a payment arrangement. All three beat another month of retries, and the first two fix the problem permanently rather than for a month.
Sources
Frequently asked questions
How many automatic retries should I configure?
Two or three, at intervals that are not on the same day. One after one to three days, and one scheduled for the start of the next month to catch limits that have reset. More than that adds very little collection, and at some providers every attempt is also counted.
What is a normal failure rate for recurring charges?
It varies widely by audience, amount and card mix, so a benchmark from the internet will not help you. What does help: measure your own rate for three months and treat it as a baseline. What matters is the direction, not the comparison to others.
Is a failed charge the same as churn?
No, and that distinction saves revenue. Churn is a customer's decision; a failed charge is a fault. If your system marks a failure as a cancellation, you lose customers who wanted to stay - and you get a churn report that inflates the real problem.
Who should be alerted on a failed charge?
A named person, not a shared mailbox. And there should also be a weekly review of the report, because individual alerts get swallowed. That is exactly why a failure report appears as a requirement in [the non-negotiables in a recurring-charge system](/blog/choose-provider-for-recurring-charges-israel).
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.