Every vendor promises recovery. Put five dunning demos in a row and you will hear the same words: smart retries, AI timing, beautiful emails, recovered revenue. None of that helps you choose, because none of it tells you how a tool behaves on your failures, with your billing system, for your customers. A shortlist is not a list of names. It is a method for forcing different products to answer the same questions in the same units.
Start with your failures, not with features
Before you book a demo, pull the last 90 days of failed payments and sort them. How many were insufficient funds, expired cards, authentication required, generic declines, or closed accounts? What were the amounts, how old were the subscriptions, and which billing platform produced them? A tool that is excellent at expired cards may do little for soft declines that need better timing. If you do not know your mix, every pitch will sound plausible, because every pitch is built for a mix — usually someone else's.
Write the criteria before anyone shows you pricing
Use criteria that match the work, not the brochure:
- Decline handling: Does the tool treat decline codes differently, or does it retry everything on one schedule?
- Retry logic you can inspect: Can you see why a retry happened when it did, and can you change the rules?
- Customer messaging: Are emails and texts in your voice, from your domain, with a card-update page that works on a phone?
- Card updating: Does it use network account updating where available, and does it check for a new card before retrying an old one?
- Measurement: Can it separate money it recovered from money that would have paid anyway on a normal retry?
- Commercial fit: Is pricing flat, per recovery, or per subscriber, and what does that cost at your failure volume in a bad month?
If a vendor cannot answer one of these plainly, that is an answer. Write it down as a gap, not as a promise that the feature is on a roadmap.
For a starting framework, you can compare against a shortlist of dunning software options worth testing — then replace any generic weighting with the failure mix you found in your own data.
Ask every vendor for evidence in the same shape
Ask the same five questions, in writing, to everyone on the list. What counts as recovered? Over what window? Is a customer who pays after clicking an email but before any retry counted the same as one saved by a retry alone? What share of recovered customers are still subscribed 60 days later? What happens to customers the tool fails to save — how are they handed back to you?
Vague definitions are where recovery rates grow. One vendor counts any later payment. Another counts only payments inside its campaign. Both can quote a large number and both can be telling the truth about different things. Your job is to make the definitions identical before you compare the numbers.
A scoring rubric you can actually use
Score each criterion from 0 to 3, and weight it by your failure mix:
- 0 — Not offered, or the vendor would not explain it.
- 1 — Offered, but fixed. You take the default schedule, template, or report as given.
- 2 — Offered and configurable. You can change timing, messages, and rules without filing a ticket.
- 3 — Configurable and observable. You can change it and see, in reporting, what the change did.
Then apply weights. If most of your failures are soft declines, retry logic and decline handling might each count double. If most are expired cards, card updating counts double and retry timing counts less. If you sell a low-priced product, commercial fit matters more, because a percentage-of-recovery fee can quietly take a large share of a small payment. Add the weighted scores, but also keep a veto list: no control over sender domain, no clear recovered definition, or no export of your own data should end the conversation regardless of total score.
Run a short, honest test
Shortlist two, at most three, tools and test them on the same slice of failures for the same length of time. Keep a holdout on your current process if you can. Judge on recovered revenue net of fees, recovery by decline type, complaints and support contacts, and how many recovered subscribers are still active a month later. A tool that saves a payment and loses the customer to annoyance has not saved much.
That discipline — define, compare in identical units, and measure what survives — is also the idea behind Swipe Again's failed payment recovery service. Whatever you choose, choose it because it scored well on your failures, not because its demo promised the largest number in the room.
Top comments (0)