Stripe Built-In Dunning vs a Dedicated Dunning Tool: What Stripe Does and Doesn’t Cover (2026)

Stripe's built-in revenue recovery — Smart Retries, customer emails, no-code automations and automatic card updates — is a genuine dunning system, and for a small subscription business it is often enough. A dedicated dunning tool earns its fee in three situations: you want emails written around the decline reason, you want to go back for failures Stripe has already stopped retrying, or you bill on a processor other than Stripe.

We build a recovery tool, so we have a stake in this question — which is exactly why we wrote it from Stripe's own documentation first. Stripe is not the weak link people assume. The honest version of the decision is not "native versus tool"; it is "which of the five recovery jobs do I still have to do myself after Stripe has done its part?" This guide lists what Stripe documents, what it leaves out, and how to work out whether the gap is worth $29 a month to you.

What does Stripe's built-in revenue recovery include?

Stripe groups five features under revenue recovery in Stripe Billing, and Stripe's own checklist tells you to enable them. Here is what each one does according to the documentation, with the limits that matter.

1. Smart Retries (or a custom schedule)

Smart Retries uses machine learning to pick retry times. You choose a policy — a number of tries within a window of 1 week, 2 weeks, 3 weeks, 1 month or 2 months — and Stripe's recommended default is 8 tries within 2 weeks. If you would rather control it, you can switch Smart Retries off and write a custom schedule of up to three retries, each a set number of days after the previous one. When the final retry fails, your setting decides what happens next: cancel the subscription, mark it unpaid, or leave it past_due (our subscription statuses guide covers what each of those means for your access control). For the mechanics of the timing model see Stripe Smart Retries explained.

2. Customer emails

Under email notifications, Stripe can send a failed-payment email after each failed card payment, a 3D Secure confirmation request with reminders, a trial-ending reminder seven days before a trial ends, renewal reminders, and an expiring-card email one month before the default card expires. Each links to a page where the customer updates their payment method — either a Stripe-hosted Customer Portal page or your own page — and all use your Stripe branding settings.

3. No-code automations

Automations let you build a workflow of a trigger, optional filters (customer metadata, invoice amount, yearly or monthly interval, product) and a sequence of actions with delays. There are six triggers, including Subscription payment fails, and Stripe's own recipe is a longer retry policy plus a 7-day grace period for annual subscribers. One detail worth knowing: when an automation runs, it overrides your global settings for that event.

4. Automatic card updates

Stripe refreshes a customer's card details when the issuer reissues the card, which is the network-level mechanism we explain in Account Updater explained. It is silent and useful, and it cannot fix a card the customer closed or a decline for insufficient funds.

5. Recovery analytics

The revenue recovery overview reports failed payments, failure rate, recovered payments and recovery rate, with breakdowns by recovery method and decline code. Stripe notes that the data covers recurring subscription payments only and excludes the first invoice after a trial.

Where does Stripe's toolkit stop?

Stripe covers retrying and a single notification well; the gaps are in what happens between the customer and the update-card page, and in everything that already failed. These are the four we see most often — each one stated as "the documentation does not describe," because we are reading Stripe's pages, not claiming to know its internals.

1. Copy that changes with the decline reason. An insufficient_funds decline wants a patient, payday-aware message; an expired_card wants a direct "your card expired, update it" request; do_not_honor wants reassurance that it is probably not the customer's fault. Stripe's failed-payment email is one toggle with your branding. See our dunning email templates for what reason-specific copy looks like.
2. A sequence, not a notification. The documented email behavior is an email after each failed payment. A recovery sequence — a gentle first note, a firmer second, a last-chance third, spaced across the retry window — is something you assemble yourself. And the automation action list has a team email and a cancellation email, but no customer-facing dunning email.
3. Failures that already ran out of retries. Once a schedule ends and the subscription is canceled or unpaid, the invoice sits there. Stripe does not describe a feature that goes back for it. We cover why that backlog matters in the historical recovery guide.
4. Everything that is not Stripe. If part of your revenue bills through Paddle, Braintree, Chargebee or Recurly, Stripe's recovery stack does not touch it.

Stripe built-in vs a dedicated dunning tool, feature by feature

Side by side, the difference is mostly about customer communication and reach. The right-hand column uses Revova as the example because we can state its behavior precisely; other tools differ on the details, which our six-tool roundup compares.

Should you stay on Stripe's built-in tools or add a dedicated one?

Stay on Stripe alone if your failed-payment volume is small enough to chase by hand and you have not yet measured a recovery rate worth improving; add a tool when the arithmetic says it pays. The arithmetic is simple, because a tool only needs to recover more than it costs.

A quick fit grid

• Stay on Stripe built-in: a handful of failures a month, all on Stripe, and your recovery rate in Stripe's analytics is already high.
• Add Revova (Starter, $29): failures every week, you want reason-aware emails, or you have never gone back for old failures.
• Add Revova (Pro, $79): you also want SMS, the cancel flow, five-email sequences or multi-language emails (Pro; Stripe features need Stripe).
• Look at a premium suite: if you are well-funded and want deep cancel-flow tooling, see our Churnkey alternatives page for how the tiers compare.

How do you run Stripe's recovery features and a dedicated tool together?

Decide which system owns each job and switch the overlapping Stripe setting off — otherwise your customer gets two emails or two retries for one failure. Stripe makes this practical because the settings are independent.

1. Pick the retry owner. Smart Retries can be turned off in the Dashboard (and replaced with custom rules). One system should own retry timing per invoice.
2. Pick the email owner. If your tool sends the failure emails, turn off Send emails when card payments fail. Keep the 3D Secure confirmation and expiring-card emails on unless your tool covers them, because they solve different problems.
3. Leave automatic card updates on. It is silent, and it removes failures before any email is needed.
4. Keep Stripe analytics as your scoreboard. Its recovery rate counts any method, so it shows the combined effect of both systems.
5. Check the first failure end to end. Use a test failure and confirm one email arrives, not two.

Setup details for the Revova side are in the dunning email sequence setup guide, and the prevention half of the picture — emails before the card fails — is in our pre-dunning setup guide.

The verdict

Turn on everything Stripe offers first; it costs you an afternoon and recovers real revenue. Then measure. If Stripe's recovery rate is high and your volume is low, stop there. If failures keep landing, or you have a backlog nobody chased, add a tool whose gap-filling matches your gaps. For most small SaaS teams on Stripe, that is reason-aware emails plus a one-time sweep of old failures.

Frequently asked questions