Stripe Smart Retries are good. If you're on Stripe Billing, they're already working in the background, using machine learning to pick the optimal time to retry failed payments. They analyze data from billions of transactions across the Stripe network to predict when a specific card, bank, and decline type combination is most likely to succeed on a second attempt.
For a free, built-in feature, Smart Retries deliver real results. Stripe reports they recover about 11% more revenue than fixed retry schedules. That's not nothing. For a $100K MRR business, that's potentially $700-800/month in additional recovered revenue without you lifting a finger.
But Smart Retries have clear boundaries. Understanding what they do and don't do helps you decide whether they're enough or whether you need a dunning layer on top.
What Smart Retries actually do
Smart Retries operate at the payment level. When a subscription invoice fails, Stripe doesn't just retry at fixed intervals. It feeds the transaction details (card network, issuing bank, decline code, amount, time of day, day of week, and other signals) into a model trained on outcomes across the entire Stripe network.
Specifically, Smart Retries handle:
- Optimal timing. The model predicts the best hour and day to attempt the next charge based on when similar transactions have succeeded in the past.
- Card network signals. Visa, Mastercard, and other networks share data about when specific issuers are more likely to approve retries. Smart Retries incorporate these signals.
- Decline code interpretation. Different decline codes have different retry profiles. An
insufficient_fundsdecline has a very different optimal retry window than aprocessing_error. Smart Retries adjust accordingly. - Multiple retry attempts. The system typically makes 4-8 retry attempts over the course of your configured dunning period (up to your retry limit).
- Cross-merchant learning. Because Stripe processes payments for millions of businesses, they see patterns that no individual merchant could detect. If a particular issuing bank approves retries more often on Tuesdays at 10 AM, Smart Retries know that.
This is genuinely useful technology. The network effect of billions of transactions creates a dataset no individual SaaS business could build.
What Smart Retries don't do
Here's where the gaps appear.
No customer communication
Smart Retries are silent. They retry the charge in the background without telling the customer anything. The customer doesn't know their payment failed, doesn't know retries are happening, and doesn't receive any prompt to take action.
This matters because a large percentage of failed payments (30-40% are hard declines) can only be recovered if the customer provides new payment information. An expired card won't un-expire no matter how many times or how cleverly you retry it. The customer needs to enter their new card number, and they can only do that if someone tells them there's a problem.
Stripe does offer basic built-in dunning emails (called "failed payment emails" in their settings). But they're separate from Smart Retries. They're simple, template-based, and limited: one email when the payment fails, optionally one more before cancellation. That's it. No sequence. No escalation. No multi-channel approach.
No SMS
Smart Retries are card-network-level retries only. There's no SMS component. Given that SMS has a 95-98% read rate compared to email's 35-45%, and that adding SMS to dunning lifts recovery by 15-25%, this is a significant gap.
For customers who don't check email regularly, or whose dunning email lands in the Promotions tab, Smart Retries plus email-only communication misses a channel that could reach them.
No payment links
When Smart Retries fail (because the card on file is permanently dead), recovery requires the customer to update their payment method. Smart Retries don't generate a payment link. They don't create a simple one-click page where the customer can enter a new card.
Stripe's hosted customer portal can handle payment updates, but it requires the customer to navigate to it. A dedicated payment link embedded in a dunning email ("Click here to update your card in 30 seconds") reduces friction significantly. Customers who receive a direct payment link are 2-3x more likely to update their payment method compared to those directed to a generic account settings page.
No brand control
Smart Retries are invisible to the customer by design. The basic dunning emails Stripe sends are functional but generic. They come from Stripe (or from your configured reply-to address) with Stripe's template. You can customize the text slightly, but you can't control the design, the tone, the sender name, or the surrounding experience.
For SaaS businesses that have invested in their brand voice, this is a gap. Your customer relationship is with you, not with Stripe. A dunning email that matches your brand, uses your tone, and comes from a familiar sender name performs better than a generic payment processor notification.
In testing across dunning platforms, branded dunning emails show 8-15% higher open rates than generic payment processor notifications. The customer recognizes the sender, trusts the email, and is more likely to act.
No sequence logic
Smart Retries don't support the concept of a dunning sequence: a series of messages that escalate in urgency, shift tone, and use different channels over time. They retry the charge on a schedule, and that's it.
An effective dunning sequence looks like this:
| Day | Action | Channel | Tone |
|---|---|---|---|
| 0 | Payment fails, retry queued | Auto retry | — |
| 0-1 | "Your payment failed" | Informational | |
| 1-2 | Smart Retry attempt 1 | Auto retry | — |
| 3 | "Reminder: update needed" | Helpful | |
| 4-5 | Smart Retry attempt 2 | Auto retry | — |
| 5-6 | "Update your payment" | SMS | Direct |
| 7-8 | Smart Retry attempt 3 | Auto retry | — |
| 10-11 | "Last chance" | Urgent | |
| 13-14 | Smart Retry attempt 4 | Auto retry | — |
Smart Retries handle the "auto retry" rows. Everything else, the emails, SMS, tone escalation, and payment links, needs to come from somewhere else.
No analytics on what's working
Stripe provides basic metrics on payment success and failure rates, but Smart Retries don't give you visibility into why a specific retry succeeded, which retry attempt recovered the payment, or how your recovery rate compares to benchmarks.
A dedicated dunning tool provides:
- Recovery rate by decline type
- Performance by email position in the sequence
- SMS vs email attribution
- Time-to-recovery metrics
- A/B test results on messaging
Without this data, you're optimizing blind. You know your overall churn number, but you don't know which parts of your recovery process are working and which aren't.
When Smart Retries are enough
Smart Retries alone may be sufficient if:
- You're very early stage. If you have fewer than 100 subscribers, the absolute number of failed payments is small. Manually following up on the 5-10 failures per month is feasible, and the ROI of a dedicated tool is limited.
- Your failure rate is already low. If you're seeing 2-3% failure rates (common in B2B with corporate cards), Smart Retries may recover enough on their own.
- You have very high natural recovery. If your customers are highly engaged and proactively update their payment information without being prompted, Smart Retries catch the transient failures and your customers handle the rest.
- Your ARPU is very low. If you're charging $5/month, the revenue recovered by adding a dunning layer may not justify even a modest tool cost. Smart Retries capture what they can, and the remainder is accepted as cost of business.
When you need a dunning layer on top
Most SaaS businesses above $10K MRR benefit from adding dunning on top of Smart Retries. Here are the signals that you've outgrown Smart Retries alone.
Your involuntary churn is above 1% monthly. If more than 1% of your subscribers are churning due to payment failure each month, Smart Retries aren't capturing enough. A dunning layer typically recovers 40-60% of what Smart Retries miss.
You have a meaningful percentage of hard declines. If 30%+ of your failures are hard declines (expired cards, lost/stolen cards, closed accounts), retries alone will never solve them. You need customer communication.
Your ARPU is above $30/month. At this price point, each recovered customer is worth enough to justify a dedicated tool. A $50/month customer recovered is $600/year in revenue. A dunning tool costs $30-100/month.
You're growing. As you scale, the absolute number of failed payments grows with your subscriber count. At 1,000 subscribers with a 7% failure rate, you have 70 failed payments per month. Manual follow-up doesn't scale. Automated dunning does.
You care about the customer experience. Smart Retries are invisible to the customer. If their payment fails and your only communication is a generic Stripe email (or nothing), the customer experience is poor. A branded, well-timed dunning sequence is a service to the customer, not just a recovery mechanism.
The math: Smart Retries vs Smart Retries + dunning
For a SaaS with $50K MRR and a 7% failure rate:
| Metric | Smart Retries Only | Smart Retries + Dunning |
|---|---|---|
| Monthly failures | $3,500 | $3,500 |
| Smart Retry recovery | $525 (15%) | $525 (15%) |
| Remaining after retries | $2,975 | $2,975 |
| Dunning recovery | $0 | $1,785 (60% of remainder) |
| Total recovered | $525 | $2,310 |
| Monthly revenue lost | $2,975 | $1,190 |
| Annual revenue lost | $35,700 | $14,280 |
| Dunning tool cost | $0 | $600-1,200/year |
Adding dunning recovers an additional $1,785/month, or $21,420/year, for a tool cost of $600-1,200/year. That's a 17-35x return.
Smart Retries alone leave $35,700/year on the table. Smart Retries plus dunning reduces that to $14,280. The difference is $21,420 in recovered revenue per year.
How Rekko works with Stripe Smart Retries
Rekko sits on top of Stripe's existing infrastructure. It doesn't replace Smart Retries. It adds the layers that Smart Retries lack.
When a payment fails on your connected Stripe account, Rekko receives the webhook, categorizes the failure by decline type, and triggers your configured dunning sequence. Smart Retries continue running in the background on Stripe's side. Meanwhile, Rekko sends branded emails, delivers SMS at the right point in the sequence, provides payment links that make updating a card frictionless, and tracks every touchpoint in a dashboard.
If Smart Retries recover the payment before the dunning sequence completes, Rekko automatically stops the sequence. No redundant emails. No "your payment failed" message after the customer already paid.
The two systems complement each other. Stripe optimizes when to retry the charge. Rekko handles everything around that: communication, payment method updates, multi-channel delivery, and analytics.
For most SaaS businesses on Stripe, this combination of Smart Retries for automated retries and a dunning tool for customer communication is the approach that maximizes recovery while minimizing complexity.