Most recovery-tool evaluations start with demos and end with opinions. There is a cheaper order: arithmetic first. A subscription business knows, or can pull in ten minutes, its monthly charge volume, its failure rate, and its average ticket. Those three numbers bound the whole conversation, because no tool recovers more than the recoverable share of the failed pool — and most arguments about recovery tools are, underneath, arguments about how big that share really is.
Three numbers, one pool
Suppose, just to have something concrete on the page, a business charges $50,000 in a month, 8% of those charges fail, and the average ticket is $40. The failed pool is $4,000 of attempted revenue, spread across roughly 100 failed payments. Change the inputs to your own and the shape stays the same: the pool is the ceiling. Everything any vendor, script, or spreadsheet can ever talk about lives inside those $4,000, and a surprising amount of sales material quietly talks as if it lives outside them.
This is why the first question is never "what does the tool cost?" It is "how much of this pool is already coming back?" Your platform's native schedule is already retrying some of these payments, and some customers are already updating cards on their own. That baseline is not the tool's work, and any honest estimate counts native tooling first, so a second engine is only credited with the headroom above it. Skip that step and you will double-count the baseline, buy the difference between two definitions, and spend a year arguing with a dashboard.
The recoverable share is a range, not a rate
The honest unknown in the pool is the recoverable share, and it splits by cause. Expiry and timing failures recover at high rates under any competent discipline, because the customer intended to pay and the obstacle was a date or a moment. Hard declines recover at zero under all of them, because the issuer has closed the door; the correct response there is not another attempt but a card-update request, and the arithmetic should price that at zero recovery no matter whose logo is on the tool.
Between those poles sit the timing cases. Insufficient-funds failures are not refusals; they are appointments missed, which is why a payday ladder that rides out toward day 25 treats them differently from a card that was reported lost. Soft declines get re-read and re-spaced. Every attempt, whatever the cause, starts by re-reading the invoice fresh, so money that already settled is never counted — or chased — twice.
Because the split by cause is an estimate, the truthful output is a range. Run the pool twice: once with a cautious split, once with a generous one, and treat anything a vendor quotes as a point estimate with suspicion. Paired scenarios are not indecision. They are what honesty looks like when one of the inputs is genuinely unknowable in advance.
Where the numbers come from
You do not have to guess the split from nothing. At connect, we backfill 90 days of past failures, and a business can do the same exercise by hand: pull last quarter's failed invoices, group them by decline reason, and mark which ones eventually settled and through which door. Attribution, kept at a single choke point — retry, then card update, then save offer, then honest external — is what makes that history usable. Without it, your own past data has the same fog as a vendor's brochure.
With a baseline and a range, the rest is comparison. A dedicated engine earns its place only on the headroom: attempts woven into the gaps of the native schedule, under a combined cap of 15, with its own ceiling at 8 attempts per failed payment, dunning emails on day 1, 3, and 7 and SMS where the merchant's program allows. If the headroom, at the cautious end of the range, does not cover the fee, the arithmetic has saved you a purchase. If it does, it has also given you the number to hold the tool to afterwards.
That is the design of a payment recovery ROI calculator: monthly revenue in, failure profile in, a recoverable range out, with native-versus-dedicated scenarios side by side. No point estimates dressed up as promises, and no pool quietly expanded to make the answer prettier.
Whatever the range says, it disciplines the next step. It might justify a purchase. It might point at a configuration change — a grace period written down, a retry schedule re-spaced — that costs nothing. Or it might support the respectable decision to do nothing yet, because the pool is small and the native schedule is already catching most of what can be caught. A demo cannot give you any of those three answers. Ten minutes of arithmetic can, and it costs less than the meeting you would otherwise schedule to argue about opinions.
Published by Swipe Again - failed-payment recovery for subscription businesses.
Top comments (0)