How to Evaluate Stripe Dunning Software: A Technical Buyer's Checklist
Nine questions that separate failed-payment recovery tools that work from ones that look like they work — access model, send idempotency, sender identity, cancellation latency, and pricing that survives contact with your actual numbers.
Most comparison pages in this category are written by vendors and rank their own product first. This one is written by a vendor too — PaidGuard builds one of these tools — so treat the criteria as the useful part and verify the conclusions yourself. Every question below is answerable from a vendor's documentation in under five minutes. If it is not, that is itself an answer.
First, three architectures that get called the same thing
"Dunning software" covers three genuinely different products. Buying the wrong category is the most expensive mistake available here.
Authorisation optimisers. These sit on the transaction itself, using issuer-level signals and retry timing to get more charges approved before any customer is contacted. Butter Payments is the reference example. They work best at volume, where a two-point lift in approval rate is a real number, and their pricing is typically attribution-based.
Dunning layers. These do not touch the charge. They detect the failure and run a customer communication sequence — email, sometimes SMS and in-app — designed to get a card updated. Churn Buster, Baremetrics Recover and PaidGuard are in this category.
Analytics suites with a recovery add-on. Subscription analytics platforms that bundle recovery as an upsell. Baremetrics prices Recover as a separate add-on on top of its analytics base — which is rational if you already want the analytics, and expensive if you do not.
If your approval rate is fine and your problem is that expired cards never get updated, an authorisation optimiser will not help you. If your volume is large enough that a fraction of a point of approval rate exceeds your entire dunning recovery, the reverse is true.
The nine questions
1. What Stripe permissions does it require?
Stripe offers third-party tools two ways in. A Connect integration asks for an OAuth scope, and the common default is read-write — which lets the tool create charges, issue refunds and modify subscriptions on your account. A Stripe App declares named permissions in a manifest, each one read or write, and Stripe lists them on the install screen before you approve.
A pure dunning layer does not need write access to any of that. It needs to read invoices, customers and payment intents. Ask directly: does your integration hold write access to my Stripe account, and if so, what specifically does it write?
There is a legitimate answer — a tool that offers one-click retry from the email does need write access, and that is a reasonable trade. What is not reasonable is a security page promising "we can't move money" backed by a read-write grant. Read the consent screen when you connect: whichever model the tool uses, Stripe shows you what is being granted before you approve it.
2. Can you see your own number before you pay?
Every vendor publishes a recovery rate. None of those numbers are about your account. Your recoverable revenue is a function of your churn mix — expired cards recover well, insufficient funds recover moderately, hard declines and fraud blocks barely recover at all — and no benchmark tells you your mix.
A tool that connects read-only can compute your last 90 days of failed payments and show you the actual dollar figure before you enter a card. If a vendor requires payment details before showing you what you are losing, you are buying their average instead of measuring your own.
3. What happens the instant a customer pays?
Ask for the latency and the mechanism, not the marketing answer.
The failure mode is a customer who updates their card on Tuesday and receives "final notice — your account will be suspended" on Wednesday. It is the single most damaging email a recovery tool can send, because it lands on someone who just did what you asked.
Two things must be true. Recovery must cancel the remaining sequence before any other processing — not as a step in a nightly reconciliation. And every send must revalidate state at send time rather than trusting the schedule, because Stripe can invalidate an invoice on its own between scheduling and delivery, with no webhook most integrations listen for.
4. Where is send idempotency enforced?
Webhook events from Stripe are delivered at least once, not exactly once, and without ordering guarantees. Any tool built on those events will receive duplicates.
The question is where duplicates get stopped. Application-level checks — "look up
whether we already sent this, then send" — leave a race window between the check
and the send, and two concurrent workers will both pass the check. The robust
answer is a database uniqueness constraint on (invoice, stage) plus atomic
claiming (UPDATE … WHERE sent_at IS NULL RETURNING id, or FOR UPDATE SKIP LOCKED).
You will not find this in a feature list. Ask the vendor's engineer. The answer takes one sentence if they have thought about it, and considerably longer if they have not.
5. Who is the sender of record on the email?
Your customer has a relationship with you, not with your vendor. If the recovery email arrives from the vendor's brand, the recipient sees an unfamiliar company writing to them about their subscription — and the most likely outcome is a spam report, not a card update.
The correct construction identifies both parties: a From of the form
"Your Company via VendorName", sending from the vendor's authenticated domain.
This satisfies the one CAN-SPAM rule that actually applies here — headers must
not be misleading — while keeping your brand as the visible sender.
A related detail worth checking in an actual sent email, not a dashboard preview: what does the footer claim? A dunning email sent on your behalf is billed by you, on your Stripe account. A footer reading "billing handled by [vendor]" tells your customers the opposite, in writing, and contradicts any read-only promise on the vendor's own security page.
6. Is a payment-failure notice transactional or marketing?
It matters, because it determines what the email must contain.
A notice that an existing subscription's payment failed is transactional. It concerns a commercial relationship already in place. Under CAN-SPAM, the physical address and unsubscribe-link requirements that apply to commercial messages do not attach to it. The rule that does apply is that headers must not be misleading.
Watch for vendors who get this backwards in either direction: adding an unsubscribe link to a dunning email (giving customers a way to opt out of hearing that they are about to lose access), or omitting sender identification from a message sent from the vendor's own domain.
7. Can you control tone, and when is it read?
Three tones — friendly, standard, premium — cover most positioning. A B2B tool billing $2,000/month and a $9 consumer app should not send the same copy.
The subtler question is when the tone and business name are read. If they are frozen at scheduling time, editing your settings today does nothing to the four emails already queued for the customer who failed yesterday. Configuration read at send time applies to the remainder of every in-flight sequence, which is almost always what you want.
The exception is the deadline. Once a date has been announced to a customer, it is a commitment; it should be frozen at scheduling and repeated identically across every email in the sequence.
8. Does the pricing survive your numbers?
Run the arithmetic before the demo, not after.
Monthly failed-payment volume F
Recovery rate you expect r
Recovered revenue R = F × r
Fixed platform fee P
Performance fee rate c
Total cost C = P + (R × c)
Net gain R − C
The shape of the fee matters as much as the size. A flat subscription is cheapest when recovery is high and punishing when it is low — you pay the same whether the tool works or not. A pure performance fee aligns incentives but can exceed a flat fee at volume. A hybrid caps neither risk perfectly but keeps the vendor exposed to outcomes.
Two traps in published pricing. Tiers keyed to MRR rather than to failed-payment volume charge you for growth that has nothing to do with the problem being solved. And recovery add-ons priced on top of an analytics base mean the recovery line item is not the number you should be comparing.
For reference, PaidGuard is $39/month plus 5% of revenue actually recovered, with the first month's platform fee waived. At $4,000/month recovered, that is $239 against $4,000 — but run your own F and r; if your recovery rate is low, every model in this category looks worse and a flat fee looks worst of all.
9. What happens when you cancel?
Two questions, both underspecified in most terms of service. Does disconnecting revoke the Stripe token immediately, and can you export your recovery history — which invoices were recovered, which emails were sent, on what dates? That history is your evidence for what the tool was worth. If it leaves with the vendor, you cannot audit the decision to keep paying.
Quick reference
| Criterion | Acceptable | Disqualifying |
|---|---|---|
| Stripe access | Read-only, or write access with a stated, narrow purpose | Read-write with no explanation; "we can't move money" claims unbacked by scope |
| Pre-purchase visibility | Your own 90-day figure before payment | Vendor benchmark only |
| Recovery cancellation | Immediate, ahead of all other processing | Nightly batch reconciliation |
| Idempotency | DB constraint + atomic claim | Application-level check-then-send |
| Sender identity | "Your Company via Vendor" | Vendor brand alone |
| Deadline handling | Frozen at scheduling, identical in every email | Recomputed per template |
| Pricing basis | Tied to failed-payment volume or recovered revenue | Tied to total MRR |
| Exit | Token revoked on disconnect, history exportable | Neither documented |
Build versus buy, briefly
The honest version: a competent team can build this. The list of things that must
be correct — deduplication, atomic claiming, timeout headroom on every sending
route, invoice revalidation before each send, frozen deadlines, header
sanitisation on merchant-supplied data, and a test harness capable of producing
invoice.payment_failed at all — is long, and most items fail silently. The
detailed version is in
Building dunning on invoice.payment_failed.
The question is not capability. It is whether three weeks of senior engineering time on a solved problem is your best available trade, given that the bugs do not appear in your logs.
See your own number first. PaidGuard connects to your existing Stripe account (we only ask Stripe for read access), audits the last 90 days of failed payments, and shows you what the gap is worth before you enter a card. $39/month plus 5% of revenue actually recovered — first month free.
Related: Measuring involuntary churn before you fix it
Sources: Churn Buster — dunning software comparison · Butter Payments comparison · Baremetrics Recover comparison · Stripe — receiving webhook events