Stop losing subscribers to declined cards.

A subscriber’s card declines on the third of the month. Nobody tells them. Your subscription platform retries on whatever schedule it shipped with, the retries fail for exactly the same reason the first charge did, and after the last attempt the subscription cancels itself. Two weeks later the customer notices the box never arrived — and by then they have bought something else.

That is not churn. It is a billing failure wearing churn’s clothing, and it is why involuntary churn commonly accounts for between 20% and 40% of everything a subscription business loses. The revenue is already yours. These are people who chose the product, are still using it, and never decided to leave.

None of this is a marketing problem. A declined card is a systems problem with a marketing symptom, and it gets solved in the retry logic — not in the subject line.

Nobody has ever audited the retry ladder

Every subscription platform ships with a default retry schedule and almost every brand is still running it, untouched since the day the app was installed. A flat schedule treats every failure identically: the card that hit its limit on the 1st, the card that expired in March, the card the bank flagged over an address mismatch. Retrying the expired card four times and the limit-hit card once has the logic exactly backwards, and no amount of copywriting corrects it.

A flat schedule is a single decision, made once, in advance, on behalf of every subscriber you will ever bill. What a failed charge actually needs is a decision made about that charge — and everything required to make it is already attached to the failure.

Decline codes are collected and never read

The processor tells you why each charge failed. An insufficient funds decline is a timing problem — retry it later, on a day people are more likely to have been paid. An expired card decline is a data problem, and no number of retries will solve it, because the customer has to hand you a new number. A do not honor is a bank-side response that frequently clears on its own. Treating all three as one bucket marked “failed” is how a brand ends up with retry activity that looks busy and recovers very little.

Read that list again and it stops being a copy problem and starts being a prediction problem. The code is there on every failure, with the issuing bank, the age of the stored card and that subscriber’s own payment history sitting next to it. Behind them is a year of failed charges where the outcome is already known — which retries eventually cleared, on which day, after how many attempts. That is a labelled dataset, and the thing worth predicting from it is not whether to retry but when: which hour of which day this particular card, at this particular bank, for this reason, is most likely to clear.

The dunning email reads like a collections notice

The messages that do go out — usually one, usually email only — are written in the register of an overdue invoice. “Your payment failed. Update your details to avoid interruption.” But the customer never chose to stop paying and is not a debtor; they are a subscriber whose bank declined a charge they never saw. They will act on a message that reads like a useful heads-up from a brand they like, and delete one that reads like a threat. Which of those messages a subscriber gets, and on which day, is a second decision the platform makes for you by default: one template, one delay, one tone, for a bank hold and a dead card alike.

And then the mechanical layer nobody owns

No card-expiry warning before the charge that was always going to fail. No account updater, so a reissued card is treated as a lost customer. A payment-update page that wants a desktop, a login and three screens, when the email was opened on a phone. And no reporting, so nobody inside the business can say what any of it costs — which is why it stays unfixed.

What the system decides, and what it does not

It decides timing and targeting: when a charge is retried, how many attempts it is worth, who gets a warning before the failure, and which of the messages you approved goes out next. Everything with money on the other side of it stays with a person — refunds, credits, discounts to save a subscriber, a price change, a cancellation. It never writes the messages either; we do, in your voice, and you sign them off before anything can send. Billing is the one place where an automated mistake repeats every month instead of ending, so the boundary is drawn deliberately rather than where the technology happens to run out.