Most subscription businesses treat churn as a single number and a product problem. Customers left, so the product must not have been good enough, so the response is more features or a lower price.
A meaningful share of those customers did not leave. Their card expired, or their bank declined a charge on the twenty-eighth of a month when the account was low, and nobody told them clearly enough for them to fix it.
That revenue is recoverable at a cost close to zero, and a great many businesses make no organised attempt to recover it because they have never separated the two causes in their own reporting.
Two kinds of churn, one number
Voluntary churn is a customer deciding your product is not worth the money. It is a real signal, it is worth understanding, and winning that customer back is slow and expensive.
Involuntary churn is a customer who still wants your product and has stopped paying for reasons neither of you intended. Their card expired. It was replaced after a fraud alert. The bank declined for risk reasons. The account was short that day.
They usually have no idea anything has happened.
These respond to completely different remedies, and combining them into a single churn percentage guarantees that any improvement effort is aimed at whichever cause happens to be larger, without anybody knowing which that is.
The first thing to do is separate them. Take last month's ended subscriptions and split them: customers who actively cancelled, and subscriptions that lapsed after a payment failed. Most billing systems can show you both.
That second number is usually larger than people expect. For many businesses it is the moment they realise they have been treating a collections problem as a product problem.
We are deliberately not quoting an industry figure for how much revenue is typically involved. Every published number on this comes from billing providers who sell recovery tooling. Your own number takes an hour to produce and is the only one worth acting on.
Why payments actually fail
Treating all failures as one category is why recovery efforts underperform. There are several distinct causes and they need different responses.
| Cause | Nature | Response |
|---|---|---|
| Card expired | Predictable, dated | Prevent: email before expiry, account updater |
| Card replaced or reissued | Common, invisible to you | Prevent: card account updater |
| Insufficient funds | Timing problem | Retry on a sensible schedule |
| Bank declined for risk | May resolve on retry | Limited retries, then ask the customer |
| Limit exceeded | Timing problem | Retry after the cycle turns |
| Card lost, stolen or closed | Permanent | Do not retry, ask for new details immediately |
| Technical failure | Transient | Retry promptly |
Read down the response column and the point becomes obvious: the decline reason should route your response, and most businesses ignore the reason entirely and retry everything identically.
Processors return codes distinguishing temporary problems from permanent ones. Using them is the single largest improvement available in most setups, and it costs configuration rather than development.
Retrying a card that has been reported stolen eight times over two weeks achieves nothing except irritating a customer who needs to be asked for new details on day one.
The two mechanisms that prevent failures
Before recovery, prevention. Two things remove entire categories of failure.
The card account updater. The card networks operate services that supply merchants with updated details when a customer's card is replaced or reissued. Visa and Mastercard both run one [3]. Where your processor participates, recurring billing continues working through a card replacement without you or the customer doing anything at all.
Check three things: whether your processor supports it, whether it is enabled on your account, and whether it covers the card types your customers actually use, because coverage varies by network and region. Many businesses have it available and switched off.
Emailing before expiry. The most underused message in subscription billing, and it costs one automated email.
You know the expiry date. Write to the customer a fortnight before, asking them to update. That converts a future failure into routine housekeeping, at a moment when nothing has broken and nobody is annoyed. Compare that to the alternative sequence, where the charge fails, access is threatened, and the customer's first awareness of the problem arrives with a warning attached.
Retries, and getting the schedule right
Retrying a failed charge rather than treating the first decline as final is standard practice, and the schedule matters more than the fact of retrying.
A charge declined for insufficient funds on the twenty-eighth may well succeed on the second of the following month, because salaries arrive. Retrying it four hours later almost certainly fails again.
So retries should be spread across days rather than hours, and shaped around when people are likely to have funds.
Stripe's documentation describes a smart retry approach that uses time-dependent signals, such as how many devices have presented a given payment method recently, to choose retry timing, and notes a recommended default of around eight attempts over two weeks [1][2]. Whether that specific pattern suits you depends on your billing cycle and your customers, and it is a reasonable starting point.
How many is too many? Enough that they stop working or start damaging the relationship. Repeated declines can draw attention from your processor, and a customer receiving eight failure notifications experiences your billing as harassment rather than as help.
The resolution is to separate the two: retry on a schedule that reflects funding cycles, and notify sparingly. Those do not have to happen at the same frequency, and in a well-configured system they do not.
Dunning, without sounding like a debt collector
Dunning is the communication side: reaching customers after a failure to turn it into a successful payment without losing them. It typically combines automated retries, notifications and a grace period, and most billing platforms can send these messages when a payment fails, a card expires, or a method needs updating [1].
What the message should say. That something went wrong with the payment, not that the customer did something wrong. What happens next and when. And a single obvious link to update the card.
The tone difference is not cosmetic. The same underlying facts written as a helpful notification perform better than the same facts written as a demand, and businesses default to the second because whoever wrote the template was thinking about the money rather than the customer.
How many. Three works for most businesses: at first failure, part-way through the retry window, and before access is affected. The last one carries a real consequence and a deadline, which is what actually prompts action. Beyond three it becomes noise.
Where the link goes. This is where most recovery is lost. Send the customer to a single-purpose page that opens from the email, works on a phone, and requires no password if you can do that securely with a signed link.
Sending them to a general login page and expecting them to find the billing section loses customers who fully intended to pay. Every additional step costs you some of them.
Show it in the product too. Email is unreliable. Billing messages land in promotions folders, go to addresses nobody monitors, or reach somebody who left the company. A clear, non-alarming in-product banner with a direct link reaches engaged customers who never opened the email.
For business customers this matters more, because the person using the product is frequently not the person whose card is on file. The user sees the banner and forwards it to whoever handles payments, which is a path email alone never creates.
A worked recovery sequence
Abstract advice about retries and dunning becomes actionable once you see it as a single timeline. Here is one that works for a monthly subscription, with the reasoning attached.
Day minus 14, before anything fails. If the card expires this month, send the expiry reminder. Nothing has gone wrong, nobody is annoyed, and a proportion of customers update straight away. This message alone removes a slice of everything that follows.
Day zero, the charge fails. Do not email immediately for a transient decline. Wait a few hours, retry once, and see. A meaningful share resolve themselves and messaging those customers creates alarm for no reason.
Day one, first notification. Neutral tone, states what happened, one link to update. Full access continues and the email says so, because reassurance on that point prevents support contacts.
Days two to ten, retries continue on a spread schedule shaped around likely funding dates rather than fixed intervals. No further email during this window unless the decline reason changes to something permanent.
Day seven, second notification and in-product banner. The banner matters more than the email, particularly for business customers where the user and the cardholder are different people.
Day twelve, final notification. Names the date access changes. This is the message that actually drives action, because it carries a consequence and a deadline rather than a request.
Day fifteen, access restricted rather than cancelled. The subscription still exists, the data is intact, and one payment restores everything. Say that plainly on the restriction screen.
Day thirty, cancel and archive. Keep the account recoverable for as long as your retention rules allow, because customers do come back weeks later.
Note what the sequence does. It separates retry frequency from message frequency, escalates consequence rather than tone, and never deletes anything until the last moment.
Grace periods and cutting off access
Do not cut access immediately. The customer usually has no idea anything happened, and cutting them off is how a recoverable billing problem becomes an angry cancellation and sometimes a chargeback.
A grace period should cover your retry schedule plus a few days for the customer to act, which for most businesses means two to three weeks. Too short punishes people for their bank's behaviour. Too long teaches customers that payment is effectively optional.
Degrade gradually where you can: full access during the retry window, a visible in-product notice, then restriction. The exception is where continued service creates genuine cost or risk for you, in which case a shorter window is defensible and should be stated clearly at signup.
Annual plans behave differently
Worth a note, because most advice on this subject implicitly assumes monthly billing and annual subscriptions fail in their own way.
The failure is rarer and more expensive. A monthly customer whose card fails costs you one month's revenue while you recover them. An annual customer whose renewal fails costs you a year, and there is no second attempt next month to catch it.
The card is also far more likely to have changed, because twelve months is long enough for an expiry, a replacement, or the cardholder leaving the company entirely. The account updater matters more here than anywhere else.
And the notice period should be longer. Writing to an annual customer a fortnight before renewal, confirming the amount and the date and inviting them to update the card if anything has changed, is both good practice and good manners. It also surfaces the customers who intended to cancel, which is better discovered before the charge than after it as a dispute.
For business customers on annual plans, add one more step: check whether the person whose card is on file still works there. On a twelve-month cycle that assumption fails often enough to be worth testing, and a single email asking whether billing contact details are still correct prevents a renewal failing for a reason nobody could have diagnosed from the decline code.
The call nobody makes
For higher-value subscriptions, a two-minute phone call recovers revenue that three ignored emails did not.
Almost nobody does this, which is why it works. Set a value threshold above which a human follows up on a failed payment. At the top of your customer base the arithmetic is obvious; at the bottom it is not, which is exactly why a threshold rather than a policy.
The same applies to customers on invoice terms rather than cards. The failure mode is a missed invoice rather than a declined charge, the cycle is longer, and the remedy is a structured reminder sequence with a named human at the end. Business customers on invoice are the group most likely to lapse through simple inattention.
Make cancellation easy, genuinely
Businesses that hide the cancel button trade a small short-term retention gain for chargebacks, complaints and reputational damage.
A customer who cannot find how to cancel disputes the charge with their bank instead. That costs you the money, a dispute fee, and a mark against your processing account. It also produces a review that stays online permanently.
A clear billing page reduces support volume more than almost anything else you could build. It should show the current plan, the next charge amount and date, the payment method with its expiry, invoice history, and an obvious route to update payment or cancel.
If you want to retain people at the point of exit, do it with a well-designed offer or a question about why they are leaving, not with a maze.
While you are there: decide your proration rules and make them visible before the customer commits. Whether an upgrade charges immediately or at renewal, and whether a downgrade refunds or credits, matters far less than that it is stated clearly and applied consistently. Proration disputes are a common and entirely avoidable source of support contacts.
Common mistakes, and what they cost
Six patterns that account for most of the avoidable loss.
Treating every decline the same. Retrying a closed card eight times while sending the customer no request for new details. Costs you the recovery and annoys the customer simultaneously.
Emailing at the same frequency as retrying. Eight retries producing eight emails reads as harassment. The two schedules should be independent.
Sending customers to a login page. Every step between the email and the update form loses people. A single-purpose link recovers customers that a general login page does not.
Cutting access on first failure. Converts a bank's decision into your cancellation. Almost never justified and it produces disputes rather than payments.
Never checking what the platform is configured to do. The single most common one. Capability that exists and is switched off recovers nothing at all.
Reporting one churn number. Guarantees that improvement effort is aimed at whichever cause you assumed rather than whichever is larger. Costs you nothing directly and misdirects everything else.
None of these requires development work to fix. All six are configuration, copy and process decisions, which is why this area has an unusually good return relative to effort and an unusually poor rate of anybody actually doing it.
Build or buy
Use a platform.
Recurring billing has an enormous number of edge cases: proration, tax treatment, currency, retries, refunds, partial periods, plan changes mid-cycle, failed payments during a plan change. Building it yourself means discovering each one in production, with a real customer attached and money involved.
This is among the clearest build-versus-buy decisions in software, and our guide on build versus buy covers how to think about the general case.
But do not assume the platform is doing this for you. Retries, the account updater and dunning emails are usually configurable rather than automatic, and that distinction costs businesses real money. Many assume these are on by default and never check.
Log in and confirm what is actually enabled. The gap between what your platform can do and what it is currently doing is where the recoverable revenue sits.
Your UAE payment setup
Which capabilities you have access to depends on your gateway and acquiring arrangements, so this is worth asking about directly rather than assuming.
Ask your provider what retry logic they support, whether card account updater is available and for which networks, and what decline codes they pass through to you. That last one determines whether you can route your response by reason, which is the improvement with the best return.
Our guide on UAE payment gateways covers choosing the underlying acceptance layer.
On local card behaviour: decline patterns, updater coverage and how banks treat recurring charges can differ from other markets. Rather than assuming behaviour you have read about elsewhere transfers, look at your own decline data broken down by card type and issuer. If one issuer declines disproportionately, raise it with your provider rather than absorbing it as background noise.
Offering an alternative payment method at the point of failure, rather than only at signup, converts some failures directly. Keep the choice small, though. A page offering six options to somebody trying to fix a problem performs worse than one offering two.
What to measure
Four numbers, tracked over time:
Failed payment rate. What share of charges fail.
Recovery rate. What share of those are eventually collected.
Time to recovery. How long it takes, because a payment recovered on day three is worth more than one recovered on day twenty.
Involuntary churn as a share of total churn. The number that tells you whether this whole area deserves more attention.
To get the fourth, tag every ending subscription with a reason at the point it ends: cancelled by customer, lapsed after payment failure, or ended for another cause. Without that tag, your churn figure conceals two different problems and any effort to improve it is aimed at whichever one you happened to assume.
Two checks this week
Split last month's cancellations into customers who chose to leave and subscriptions that lapsed after a failed payment.
Log into your billing platform and check whether retries, the card account updater and dunning emails are actually enabled.
Those two take about an hour between them and typically reveal both a number nobody had seen and a switch nobody had turned on. Turning on retries, enabling the updater where supported, and switching on standard dunning emails addresses most of the recoverable loss for well under an hour of work.
It is unusual to find anything in software with that ratio of effort to return, which is the main reason this article exists.
If you want the fuller version, a billing and recovery review covering your current failure and recovery rates, what your platform is configured to do, what it could do, and the customer-facing flows around failure starts from around AED 2,500 with us. Implementation is priced separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- Stripe Documentation, revenue recovery
- Stripe Documentation, automate payment retries
- Stripe, managing expired cards for recurring payments
- Stripe Documentation, automatic collection
- SKIMBOX, UAE payment gateway comparison
- SKIMBOX, build versus buy for UAE businesses
- SKIMBOX, checkout optimisation for UAE ecommerce
- SKIMBOX, in-app purchases and subscriptions in the UAE
- SKIMBOX, SaaS MVP development in Dubai
Product capabilities and default configurations described here are drawn from platform documentation and change over time. No recovery rate statistics are quoted in this article, because the published figures originate from vendors selling recovery tooling. Measure your own.
