Every subscription business has two kinds of churn, and they could not be more different.
Voluntary churn is a decision. The customer weighed your product, decided it wasn't worth it, and cancelled. That churn is feedback. You argue with it using a better product, better pricing, better onboarding.
Involuntary churn is an accident. The customer never decided anything. Their card expired. Their bank replaced the card after a fraud alert and the new number never reached you. Their account was short on the specific morning the charge ran. A bank's risk system declined a transaction it would have approved on a different day. The subscriber still wants the product. You still want the subscriber. A failed transaction ended the relationship anyway — often silently, with the customer finding out later, or never.
If you've never separated these two numbers in your own billing data, it's worth an afternoon. Voluntary churn tells you about your product. Involuntary churn tells you about your plumbing — and plumbing is fixable in a way opinions aren't.
What a decline actually is
"Payment failed" is not one event. It's a category of very different events that happen to share a label:
- The card is gone. Expired, replaced, reissued. No retry schedule on earth recovers this payment — the credential itself no longer exists. The only fix is a new card from the customer.
- The money wasn't there at that moment. Insufficient funds is frequently a timing problem, not a solvency problem. The same charge, run days later, succeeds.
- The bank said no without saying why. Issuers decline transactions for risk reasons they deliberately don't disclose. Some of these succeed on a later attempt; some never will.
- The charge looked wrong. Amount, timing, or merchant pattern tripped a fraud heuristic — often on a perfectly legitimate renewal.
Treating these four situations as one problem, with one response, is where most recovery efforts quietly fail. Retrying a replaced card six times recovers nothing and trains banks to like you less. Emailing "update your card!" to a customer whose only problem was payday timing is noise they learn to ignore.
The recovery stack, in plain terms
Real payment recovery is four layers, and each one exists because the others have a hole in them.
Smart retries. Retry the failures that are worth retrying, when they're most likely to succeed. "Smart" means the schedule reads the decline code: a funds problem gets time, a hard decline gets few or no further attempts, and the retry count has a ceiling — ours is up to six attempts over about 16 days. The dumb version of this — retry everything, on a fixed schedule, forever — is barely better than nothing and occasionally worse.
Dunning emails. When a payment fails, the customer has to hear about it from you — in your name, in your branding, in a tone that sounds like a heads-up rather than a collections notice. Most people don't know their payment failed. A clear email at the right moments in the retry window turns "silent cancellation" into a thirty-second fix.
Card-update pages. The email has to land somewhere. A hosted, branded page where the subscriber enters a new card — no login maze, no support ticket, no "call us during business hours." Every extra step between "my card expired" and "here's the new one" is a place subscribers abandon a subscription they meant to keep.
Backfill. The day you set up recovery, you already have a backlog: failed payments from the last weeks and months, subscribers mid-drift toward cancellation. A backfill works that existing backlog — in our case, 90 days of it on connect — instead of only protecting you from tomorrow's failures. For most businesses, the backlog is the fastest money in the whole system, because it's already there.
What recovery can't do
Honesty matters here, because this category oversells. Recovery cannot save a customer who has decided to leave — that's voluntary churn wearing a payment costume, and chasing it with retries is how you earn chargebacks. It cannot fix a product people don't want. And it cannot recover a payment from a card that no longer exists until the human attached to it hands you a new one, which is why layers two and three exist.
What it can do is narrower and more valuable: make sure that the subscribers who wanted to stay, and whose money was good, don't disappear because a transaction failed at the wrong moment. That's not a growth hack. It's maintenance — the unglamorous work of not leaking customers you already earned.
The takeaway
Pull your billing platform's failed-payment list and read the decline codes before you do anything else. Sort them. You'll find the four situations above, and each one has a correct response. If your current setup applies one response to all of them — or worse, has no response and lets the platform's default cancellation do the talking — that's the leak.
We build Swipe Again (https://swipeagain.com), which runs this stack — decline-code-aware retries, branded dunning, card-update pages, and a 90-day backfill — across the major subscription platforms for a flat monthly fee. But the stack matters more than the vendor. Whoever runs it for you, run it deliberately: read the decline, match the response, and stop losing the customers who never meant to leave.
