Disclosure: we're the Swipe Again team. We build failed-payment recovery software, and a 90-day backfill on connect is part of what we sell — so treat this as an argument to evaluate, not a finding to cite. Deliberately, there are no recovery statistics in this post. The case below is built from mechanics, and it's labeled as reasoning throughout. If the mechanics don't convince you, no chart we invented would deserve to.
Picture the day a subscription business finally sets up payment recovery. New tool connected, retries armed, dunning emails branded and ready. From that moment forward, every failed payment gets the full treatment.
And the failures from last month? The ones from six weeks ago, eight weeks ago? In most setups, they get nothing. The tool watches the future. The backlog — which is where the recoverable money is densest — sits untouched, aging.
We think that's exactly backwards. Here's the mechanical case.
A failed payment decays
Reason it through from the customer's side, because a failed payment is not a static asset. The day a renewal fails, the subscriber is in the warmest possible state: they were recently being charged successfully, the card problem is fresh, and in most cases they don't even know anything went wrong. They still think of themselves as a subscriber.
Every week after that, the failure gets colder, for reasons that have nothing to do with anyone's software:
- The card on file gets replaced or the situation changes. The fix that would have worked in week one — a well-timed retry, a quick card update — has a shelf life. Accounts close, cards roll over, people reorganize their finances.
- The customer re-decides. A subscriber who failed to pay in March and heard nothing has, by May, effectively made a decision — they've lived without the product for two months and built their habits around its absence. You're no longer recovering a payment; you're re-selling a subscription, at a much worse conversion rate.
- The trail goes quiet. The dunning window where a simple "your card needs updating" reads as a helpful heads-up closes. The same email, sent two months late, reads as a collections notice from a company they'd forgotten about.
None of this requires a statistic. It's just what time does to an unresolved transaction: the failure doesn't wait politely at the same value. It decays.
The backlog is the near end of the decay curve
Now invert it. If failures decay with age, then at any given moment the most recoverable failures in your account are the recent ones — and the day you connect a recovery tool, you are sitting on up to a few months of them, already accumulated, already past the point where your old setup did anything about them.
That's the backfill: on connect, work backward through the recent failed payments — in our case, 90 days' worth — and run the recovery sequence on failures that already happened, not just the ones that happen next. The 90-day window isn't magic; it's a judgment about the decay curve. Recent enough that the card on file might still be fixable and the customer still considers themselves a subscriber. Old enough to actually contain a backlog worth working.
A tool that only watches future failures starts at the slowest possible point: zero backlog, waiting for new failures to trickle in one billing cycle at a time, while the densest recoverable pool in the account quietly finishes decaying in the corner.
What a backfill has to do differently
Working a backlog isn't identical to working fresh failures, and doing it carelessly is worse than not doing it:
Triage by decline code first. A 90-day backlog contains every species of failure — timing problems that a retry can still fix, replaced cards that need a customer email, and hard declines that should never be touched again. Running one schedule across all of them sprays attempts at dead cards. The backfill has to sort before it acts.
Respect the age gradient. The two-week-old failures deserve the full sequence. The eighty-day-old failures deserve a lighter touch — a graceful, final card-update invitation rather than an aggressive retry ladder. Age isn't just context; it's instructions.
Don't double-drive. If your billing platform's native retries are still churning on some of these failures, two systems retrying the same charge on independent schedules is how customers get double-charged and issuers get suspicious. One driver per failure, with a shared attempt ceiling.
The honest limits
A backfill is not a resurrection machine. Some of the backlog is genuinely gone — decided customers, closed accounts, cards that no email will revive. Recovery on old failures will always underperform recovery on fresh ones, and any vendor who quotes you a backlog recovery rate before seeing your data is inventing it.
What the mechanics support is narrower: of the failures a recovery tool will ever touch, the ones already in your account on day one are the warmest it will ever get — and they're the ones most setups ignore.
We built Swipe Again with the backfill as a first-class step — here's how the whole sequence fits together — because starting recovery at tomorrow's failures felt like installing a smoke detector and ignoring the smell of smoke already in the kitchen. Whatever tool you use, ask it one question before you connect: what happens to the failures I already have? If the answer is "nothing," you're starting at the slowest point in the system, and the fastest money in your account is aging while you wait.
