Stripe Smart Retries Not Working: How to Fix It (And Prevent It Forever)

Smart Retries are probably working. they're just not enough. Stripe's ML-based retries recover 5-10% more than fixed schedules, but they still only recover 15-25% of total failed payments. The rest require customer action (updating their card). If you're expecting Smart Retries alone to solve involuntary churn, you need to add dunning emails and card expiry alerts on top. See our SaveMRR vs Stripe Smart Retries comparison for the full picture.

Why Smart Retries Seem Broken

Stripe Smart Retries use machine learning to pick the optimal time to retry a failed charge. considering day of week, time of day, and historical success patterns across Stripe's network. They're enabled by default for new Stripe accounts. But they have hard limits that founders misunderstand.

Smart Retries only help with soft declines. temporary issues like insufficient_funds or processing_error where retrying at a different time might succeed. For hard declines (expired_card, stolen_card, card_not_supported), no amount of retry timing optimization will recover the charge. The card is permanently rejected.

Here are the 4 most common reasons Smart Retries appear to not be working:

1. You're looking at hard declines. Check the decline_code on your failed invoices. If most failures are expired_card or generic_decline with a hard-fail flag, Smart Retries can't help. You need the customer to update their payment method.

2. Smart Retries aren't actually enabled. Go to Dashboard > Settings > Subscriptions and emails > Manage failed payments. Confirm "Use Smart Retries" is toggled on. If you're using a fixed schedule, Stripe retries at your configured intervals instead of using ML.

3. Your subscription status after all retries is set to "Cancel subscription." If Stripe cancels the subscription after exhausting retries, the customer loses access and you lose the recurring relationship. Switching to "Mark as unpaid" or "Leave as past due" gives you more time to recover.

4. You have no customer communication layer. Smart Retries silently retry the charge; the customer has no idea it's happening. Without dunning emails prompting them to update their card, you're relying entirely on Stripe's retries to get lucky. That's a 15-25% recovery ceiling.

// List recent invoices that were recovered by retry
const invoices = await stripe.invoices.list({
  status: 'paid',
  limit: 100,
});

// Filter for invoices that had a previous failed attempt
const recoveredByRetry = invoices.data.filter(inv =>
  inv.attempt_count > 1 && inv.status === 'paid'
);

console.log(`Recovered by retry: ${recoveredByRetry.length}/${invoices.data.length}`);
console.log(`Recovery rate: ${(recoveredByRetry.length / invoices.data.length * 100).toFixed(1)}%`);

Quick Fix (Manual)

const invoices = await stripe.invoices.list({
  status: 'open',
  limit: 100,
});

const declineCounts = {};
for (const inv of invoices.data) {
  const code = inv.last_payment_error?.decline_code || 'unknown';
  declineCounts[code] = (declineCounts[code] || 0) + 1;
}

console.log('Decline breakdown:');
Object.entries(declineCounts)
  .sort((a, b) => b[1] - a[1])
  .forEach(([code, count]) => {
    console.log(`  ${code}: ${count}`);
  });

// If most are "expired_card" or "card_not_supported",
// Smart Retries can't help. You need dunning emails.

Permanent Fix (Automated)

Smart Retries are step 1, not the whole solution. Think of them as the silent background process that handles the easy recoveries. To capture the other 75-85% of failures, you need two additional systems:

Dunning emails; a 5-7 email sequence sent to the customer over 21 days with escalating urgency and one-click card update links. This is the single highest-impact recovery mechanism: customers can't fix what they don't know about, and Stripe's Smart Retries are silent. Dunning emails turn a 15-25% recovery rate into 40-55%.

Pre-dunning card expiry alerts. emails sent 30, 14, and 7 days before a card expires. This prevents the failure from ever happening. Stripe fires the customer.source.expiring webhook ~30 days before expiry, but doesn't send any customer communication by default. You need to build that yourself. or let SaveMRR handle it.

SaveMRR layers all three systems. Smart Retries (Stripe's) + dunning sequences (7 automated emails) + card expiry alerts. into a single $19/mo tool. Paste your Stripe key and the entire recovery pipeline activates in minutes. No webhook code, no email templates, no cron jobs.

// The 3-layer recovery stack:
//
// Layer 1: Smart Retries (Stripe handles this)
//   - ML-optimized retry timing for soft declines
//   - Recovers ~15-25% of failures automatically
//
// Layer 2: Dunning emails (SaveMRR handles this)
//   - Email 1: Immediate notification + card update link
//   - Email 2: Day 3 follow-up with urgency
//   - Email 3: Day 7 mid-cycle reminder
//   - Email 4: Day 10 consequence warning
//   - Email 5: Day 14 final notice
//   - Email 6: Day 18 last-chance offer
//   - Email 7: Day 21 grace period end
//   - Recovers additional 25-30% on top of retries
//
// Layer 3: Pre-dunning (SaveMRR handles this)
//   - 30-day card expiry alert
//   - 14-day follow-up
//   - 7-day urgent reminder
//   - Day-of last chance
//   - Prevents 15-20% of failures before they happen
//
// Combined: 40-55% total recovery rate vs 15-25% with
// Smart Retries alone. That's 2-3x more revenue recovered.

Related Stripe Billing Issues