Ask ten subscription operators what dunning software does and nine will describe email. A failed payment happens, the software sends a sequence of increasingly apologetic messages, and somewhere in there a retry fires. That description is not wrong so much as it is a photograph of the smallest part of the job. The email is the visible tip. Underneath it sits a scheduling problem, a reading problem, and an accounting problem, and the tools worth paying for are the ones that solve all three.
The scheduling problem comes first. A failed card is not one event; it is a type. Insufficient funds clears on a payday rhythm. An expired card never clears on any rhythm, because the number itself is dead. A generic decline is the issuing bank declining to explain itself, and it often succeeds when the retry is presented cleanly a short while later. Software that retries every failure on the same fixed calendar, day one, day three, day seven, is treating three different problems as one, and it pays for the confusion in burned attempts and annoyed customers. The first thing to ask of any tool in this category is whether the decline code changes what happens next.
The reading problem is quieter. Before every retry, something has to re-read the invoice: has the plan changed, has the customer already cancelled, has a manual payment landed through support? Retrying a stale invoice is how double charges are born, and double charges are how a recoverable customer becomes a chargeback and a refund and a story they tell other people. Good dunning reads before it reaches. Bad dunning reaches on a timer and apologizes later.
The accounting problem is the one nobody demos. When money comes back, which attempt gets the credit? If the platform's native retry and the recovery tool both touched the account, vendors will both claim the save, and the merchant ends up paying a percentage on revenue that would have returned on its own. A tool that counts honestly, one door for every recovered dollar, attribution stamped at the moment of recovery, is not a reporting nicety. It is the difference between knowing what you bought and funding someone else's dashboard.
For a fuller map of the category, including how the major approaches differ on exactly these three problems, this explainer on a plain-language map of what dunning software actually does is a solid place to start before any vendor call.
None of this requires the software to be complicated for the merchant. The complexity lives under the hood: the decline taxonomy, the retry calendar, the re-read, the ledger. What the merchant should see is a short list of what failed, what was tried, what came back, and what it cost. When a tool's demo leads with email templates, ask to see those four lists instead. The answers will tell you, in about ten minutes, whether you are looking at dunning software or at an email tool with a retry button.
A small worked example makes the difference concrete. Take a business with 2,000 renewals a month and a first-attempt failure rate of 8 percent: 160 failures. Say roughly half are soft declines, a quarter are expired or replaced cards, and the rest are a mix of generic declines and genuinely dead accounts. A fixed calendar retries all 160 the same way and typically works hardest on exactly the wrong slice — it spends its early, best attempts on the dead-card quarter, which no timing can save, while the insufficient-funds half waits for slots chosen without any reference to payday. A decline-aware schedule inverts that effort: the dead-card slice goes straight to a card-update request and stops consuming attempts, the soft declines are timed to when money actually lands, and the generic declines get one clean, well-presented retry before anyone concludes anything. Same failure queue, same number of total attempts — the recovery differs because the attempts were spent where attempts can work.
That is also the standard Swipe Again's recovery work is built to be judged against: flat-fee, retries woven around the billing platform's own schedule rather than racing it, and a recovered dollar counted exactly once. Judge it the same way you would judge anything else in this category, on your own failure queue, and let the arithmetic argue.
Top comments (0)