Every billing platform produces a retry report, and every retry report looks reassuring in isolation. Attempts were made, some succeeded, the recovery rate is a single tidy percentage. What the report never shows is the space around the attempts: the hours when nothing happened, the accounts that were never queued at all, and the customers who fixed their card a day after the last scheduled try had already given up on them. That space is where a surprising share of subscription revenue quietly disappears.
A practical way to see it is to keep a second document next to the report. Call it a gap ledger. For one month, write down every renewal that failed and then note three things the retry report does not: how long passed between the failure and the first human-readable notice the customer actually received, whether the account was still inside the retry window when the customer eventually updated their card, and whether anyone at the company could have seen the risk before the charge was attempted. Three columns, one month, no tooling required. The pattern that emerges is usually uncomfortable.
The first column tends to expose timing debt. Platforms retry on schedules designed for the average account, which means a payday-sensitive customer can be retried twice before their salary lands and never again after it does. The attempts look diligent on the report. In the ledger they read as effort spent at the wrong moments. The second column exposes window debt: customers who genuinely wanted to stay, who clicked the update link and fixed the problem, but who arrived after the subscription had already been cancelled by the schedule. Those are not saves that failed. They are saves that were never given a slot.
The third column is the hardest to fill in honestly, because it asks what was knowable in advance. An expiring card is knowable. A card replaced after a bank reissue is often knowable through network updater signals. A first renewal right after a trial is statistically riskier than a tenth renewal, and that too is knowable. When you read a gap-by-gap account of where Recurly renewals leak outside the native retry window, the useful question is not whether the platform retries well. It usually does. The question is how much of the loss sits outside the retry mechanism entirely, in the notice timing, the window length, and the risks nobody reviewed beforehand.
Keeping the ledger changes the conversation inside a team. Instead of arguing about whether the recovery percentage is good, people start arguing about specific gaps with dates attached, and specific gaps can be closed. A notice can go out earlier. A window can stay open long enough for a willing customer to finish fixing their card. A pre-renewal check can catch the expiring cards before they become failures at all. None of those fixes require replacing the billing platform, and that is precisely the point: the platform was never the whole system, even when its report was the only document anyone reviewed.
After a month, most teams find the ledger gets shorter, not because the writing improved but because the easy gaps got closed and stopped recurring. What remains is the genuinely hard residue: customers who left silently and never intended to return. That residue is smaller than the original failure queue suggested, which is its own useful discovery. It means the addressable problem was mostly operational all along.
That operational layer, worked early and kept open long enough for people to act, is how Swipe Again approaches recovery: surface the risk before the charge, time the effort to when it can succeed, and treat the platform's retry report as one input rather than the whole story. Start the gap ledger with the next failed renewal. By the end of the month you will know exactly where your renewals actually go.
Top comments (0)