Most lost subscribers never chose to leave

We did not set out to build a churn product. We were looking at why subscriptions ended across the platforms we operated, expecting to find dissatisfaction. What we found instead was a bank. Cards had expired. Issuers had declined transactions for reasons that had nothing to do with the customer's opinion of the service. A large share of the people we had lost had never made a decision to leave at all. They had simply stopped paying, because a machine somewhere said no and nobody followed up. That finding became Churn Solution.

The distinction matters more than it sounds. A customer who cancels deliberately is telling you something about your product. A customer whose card expires is telling you nothing. Treating the two as one number, which most dashboards do, hides the fact that a big part of what looks like a product problem is an operations problem. Operations problems are cheaper to fix.

Read the decline code before you do anything

Every failed charge comes back with a reason, and the reasons fall into groups that call for completely different responses. Some are hard declines. The card is closed, the account does not exist, the issuer has blocked the merchant. Retrying a hard decline is not just useless, it is harmful. Card networks track retry behaviour, and a merchant who hammers dead cards accumulates a record that raises decline rates on good transactions later. The correct response to a hard decline is to stop charging and ask the customer for a new instrument.

Others are soft declines. Insufficient funds. A temporary hold. A risk engine that fired on an unusual pattern and will not fire the same way tomorrow. These recover on their own with time, and time is the only treatment that works. A third group is expiry, which is neither. The card will never work again, but the customer almost certainly still has an account at the same bank with a new card in their wallet. That is a different conversation and a different message.

So the first thing we built was not a retry engine. It was a classifier that sorts declines into those groups and routes each one to its own path. Teams that skip this step end up with one retry schedule applied to everything, which means they annoy the customers who were going to pay anyway and give up on the ones who needed a nudge.

The schedule should match how banks behave

The common approach is a fixed timer. Retry after one day, then three, then seven, then give up. It is easy to build and it ignores everything about how money actually moves. Balances refresh when salaries land, and salaries land on dates that vary by country and by employer. Issuer risk systems relax their hold after a period that has nothing to do with your timer. A retry at hour twenty-four on a payroll-driven decline is a wasted attempt that also burns a slot in the network's view of your behaviour.

What worked for us was fewer attempts, placed better. We spread retries across different days of the week and different times of day, because a Friday morning attempt and a Tuesday evening attempt reach different states of the same account. We avoided clustering them in the first forty-eight hours. We stopped at a small number of attempts rather than grinding on for a month, because the recovery curve flattens quickly and everything after the flattening is cost without return. And we treated a successful retry as information: if a particular pattern recovers well for a particular issuer or country, the schedule for that segment adapts.

There is a trap in the adaptive part. It is tempting to build a model that optimises retry timing continuously. We would advise against it early on. A simple, explainable schedule that a finance team can read and argue with beats a black box that recovers two percent more and cannot be audited when a regulator or a board asks why a customer was charged four times in a week.

One message, one link, and a way to stop

The payment side only gets you so far. Expiry cases need the customer to act, and that means a message. The failure mode here is volume. A subscriber whose card expired receives a failure notice, then a reminder, then a warning, then a final notice, then a cancellation confirmation. Five emails about a payment problem reads as harassment, and it converts worse than one clear message did.

We settled on a small set of rules. Tell the customer once, early, in plain language, with the amount and the date. Give them a single link that takes them straight to the card update form, already authenticated where that is safe to do, with no login wall and no marketing page in between. If the link expires, say when. Send at most one follow-up. And when someone says stop, stop, immediately and across every channel, not just the one they replied to.

The link is where most implementations fail. We have seen recovery flows that send a customer to a homepage, then a login, then a password reset because they signed up through a social provider, then a settings menu with eleven tabs. Every one of those steps loses people. The number of clicks between the message and the saved card is the single variable we would optimise first.

When recovery is the wrong thing to do

There is a version of this work that is indefensible, and it is easy to drift into. If a customer has forgotten they are subscribed, has not used the service in a year, and their card fails, recovering that payment is not saving a relationship. It is extracting money from inattention. It produces chargebacks, which cost more than the recovered revenue, and it produces a reputation that is expensive to repair.

So we build usage into the decision. A dormant account gets a different message, one that says plainly that they have not used the service and asks whether they want to continue. Some of them say no. That is the correct outcome. We would rather a clean cancellation than a recovered payment that turns into a dispute six weeks later.

The same logic applies to cancellation flows. Offering a discount to someone who is leaving because the product does not do what they need is a way of delaying a decision, not changing it. The offer should match the stated reason, and if there is no honest offer, let them go in two clicks.

What it costs

The build is not large, but it is not trivial either. The classifier and the retry scheduler are a few weeks of engineering. The messaging templates and the card update flow are more, because they touch identity, and identity is always the slow part. The real cost is ongoing. Decline code meanings shift as processors update their APIs. Card networks change retry rules. Someone has to own this, read the release notes, and run a monthly check that recovery rates have not quietly collapsed because a code stopped being returned.

The political cost inside an organisation is different. Recovery work sits between finance, engineering and support, and it usually has no owner. Whoever picks it up will be asked to justify a project whose success looks like an absence of a problem. Name an owner in writing before the work starts.

The same problem in a fee portal

This is not only a subscription concern. A government service that collects a fee has the same structure. A citizen tries to pay a licence renewal, the card fails, the session times out, and the application sits in a pending state. Nobody in the department knows whether that citizen refused to pay or hit a technical wall. The default assumption is usually refusal, and the default response is usually a penalty.

Almost always it is a process gap. The payment page did not support the card type. The three-D secure step opened in a window the citizen's phone blocked. The session held the application for fifteen minutes and then dropped it. Each of those is fixable, and none of them is visible unless the portal records the decline reason alongside the application and someone reviews the aggregate.

If you are writing a tender for a payment-enabled service, the clauses we would insist on are these. The system must store the gateway decline reason with every failed attempt and expose it in a report. A failed payment must not destroy the citizen's submitted data. There must be a resume link, valid for a stated period, that returns the citizen to the exact step they were on. And the acceptance test should include a deliberately failed payment, followed by a successful one, with the reviewer checking that the application survived intact. That test takes ten minutes and it catches a problem that otherwise surfaces as thousands of abandoned applications and a call centre nobody budgeted for.