# Stripe smart retries complete guide **TL;DR:** Stripe Smart Retries use ML trained on billions of transactions to optimize retry timing. They're better than fixed-interval retries and free for all Stripe Billing users. But they're capped at 8 retries, can't coordinate with customer communications, don't support cross-processor routing, and optimize for the average merchant — not yours specifically. This guide covers every setting, the real-world numbers, card network retry limits you need to know, and how leading SaaS and eCommerce brands push recovery rates 16–25% higher by layering specialized tools on top. ## How Stripe Smart Retries Actually Work Stripe's Smart Retries replace fixed-interval retry schedules with ML-optimized timing. Instead of retrying every 3 days on a fixed clock, the system analyzes signals to determine when each specific payment is most likely to succeed. ### Signals Stripe's Model Uses According to Stripe's documentation, Smart Retries analyze time-dependent, dynamic signals including: * Historical payment patterns for the specific card and customer * Device activity signals (how recently the card was used elsewhere) * Time of day, day of week, and month-end patterns * Card type, issuer, and geographic factors * Decline code specifics (soft vs. hard) * Seasonal and merchant-category patterns This is a meaningful upgrade over custom retries, which simply retry on a fixed schedule regardless of context. Stripe reports that Smart Retries recovered over $6.5 billion in revenue for users in 2024, with a 60% year-over-year improvement in retry success rates. *** ## Smart Retries vs. Custom Retries: Head-to-Head Stripe offers two retry policies. Here's exactly how they differ. ### Feature Comparison | Feature | Custom Retries | Smart Retries | | ------------------------------- | ----------------------------------------------- | ------------------------------------ | | **Retry count** | Up to 3 (up to 8 with Billing Scale) | 4 or 8 | | **Timing** | Fixed intervals: 1, 3, 5, or 7 days | ML-optimized per payment | | **Duration window** | Determined by intervals | 1 week to 2 months | | **Time-of-day optimization** | No — processes in bulk during off-hours | Yes — factors in optimal time of day | | **Decline code awareness** | No — same schedule for all failures | Yes — adjusts based on decline type | | **Customer timezone awareness** | No | Partial | | **Cost** | Free with Stripe Billing | Free with Stripe Billing | | **Configuration** | Dashboard: Billing > Revenue Recovery > Retries | Dashboard: same location | | **Typical recovery rate** | 25–35% | 40–55% | When Custom Retries make sense: If you have a very specific use case requiring charges on exact days (e.g., contractual billing dates), or you need to control timing precisely for compliance reasons. When Smart Retries win: For nearly every other scenario. The ML-optimized timing consistently outperforms fixed intervals across all decline types. *** ## How to Configure Smart Retries: Step-by-Step Navigate to **Billing > Revenue Recovery > Retries** in your Stripe Dashboard. ### Recommended Settings | Setting | Recommended Value | Why | | --------------------- | ------------------------------------ | --------------------------------------------------------------------------------------- | | **Retry mode** | Smart Retries | ML timing outperforms fixed schedules | | **Number of retries** | 8 | More retries = more recovery opportunities | | **Recovery window** | 1 month (minimum) | Card networks allow up to 15 retries in 30 days for soft declines — use the full window | | **After final retry** | Cancel subscription OR mark past due | See guidance below | | **Dunning emails** | Enable selectively | Don't email after every retry | ### What Happens After All Retries Fail? {% stepper %} {% step %} ### Cancel the subscription Clean for forecasting, but the customer must re-subscribe. Revenue is permanently lost. {% endstep %} {% step %} ### Mark as past due Keeps the subscription alive. The customer still has access (or you can gate it). If they update their card later, Stripe will attempt to collect automatically. {% endstep %} {% step %} ### Leave as-is The subscription continues with an unpaid invoice. Best for businesses that can absorb temporary revenue gaps. {% endstep %} {% endstepper %} Our recommendation: For most SaaS businesses, mark as past due with a 30-day grace period, then cancel. This maximizes recovery time without creating forecasting noise. For high-value enterprise customers, extend the window further and add manual outreach. *** ## The Hidden Limitations of Smart Retries Smart Retries are excellent as a baseline. But there are structural limitations you should know about. ### Limitation 1: Retry Count Caps vs. Card Network Allowances | Network | Max Retries Allowed (30-day window) | Stripe Smart Retries Max | Gap | | -------------------------------- | ----------------------------------- | ------------------------ | ----------------- | | **Visa** | 15 retries for soft declines | 8 | 7 unused retries | | **Mastercard** | 35 retries (with MAC code guidance) | 8 | 27 unused retries | | **Penalty for exceeding limits** | Fines up to $15,000 per violation | N/A | N/A | Stripe caps Smart Retries at 8 to stay well within safe limits — a reasonable default. But for soft declines (insufficient funds, processing errors), the networks allow significantly more attempts. Specialized recovery platforms that track card-level retry counts can safely use more of this allowance, recovering payments that Stripe's 8-retry cap would have missed. ### Limitation 2: No Coordination Between Retries and Emails This is the biggest gap. Stripe's email system and retry system operate independently: | What Happens | Customer Experience | | ---------------------------------------------- | ------------------------------------------------------------------------------- | | Payment fails → Stripe sends email immediately | Customer learns about failure before any retry is attempted | | Retry #1 succeeds (Day 2) | Customer already got a "payment failed" email for a problem that's now resolved | | Retry fails → another email | Customer gets 2–8 "payment failed" emails over the recovery window | | Customer gets frustrated → cancels | Involuntary churn becomes voluntary churn | There's currently no native way in Stripe to delay dunning emails until retries have been exhausted, or to coordinate email timing with retry attempts. You can toggle emails on or off — but not schedule them intelligently. ### Limitation 3: One-Size-Fits-All Model Stripe's ML model is trained on data from millions of merchants across every industry, geography, and business model. That's a strength for general accuracy, but it means the model optimizes for the average — not for your specific customer base. | Optimization Approach | Training Data | Personalization Level | Typical Recovery Rate | | ----------------------------------- | -------------------------------------------------------------------------- | ------------------------------------ | --------------------- | | **Stripe Smart Retries** | Billions of transactions across all Stripe merchants | Merchant-category level | 40–55% | | **Per-merchant ML model (FlyCode)** | Each merchant's specific transaction history + cross-merchant intelligence | Individual merchant + customer level | 60–80%+ | The difference is analogous to using a general-purpose LLM vs. one fine-tuned on your company's data. Both work. The fine-tuned version consistently outperforms on your specific use case. ### Limitation 4: Single-Processor Only Smart Retries can only retry through Stripe. If a payment fails on Stripe due to an issuer-specific issue, there's no option to route the retry through a different processor. Stripe's new Orchestration product (currently in private preview) begins to address this — and FlyCode is one of Stripe's first global design partners for Orchestration, enabling cross-processor retry routing with ML-optimized decisions. *** ## Card Network Retry Rules: What Every Stripe User Must Know Violating card network retry limits can result in fines. Here's the full picture. ### Visa Retry Rules | Decline Category | Can Retry? | Max Retries (30 days) | Notes | | ------------------------------------------------------------- | --------------------------- | --------------------- | --------------------------------- | | **Soft declines** (insufficient funds, processing error) | Yes | 15 | Must respect time between retries | | **Hard declines** (expired card, invalid number, stolen card) | No — customer action needed | 0 effective retries | Retries will continue to fail | | **Do Not Honor (05)** | Case-by-case | 15 (treated as soft) | But often masks a hard decline | | **Penalty** | — | — | Up to $15,000 per violation | ### Mastercard Retry Rules | Decline Category | Can Retry? | Max Retries (24h) | MAC Code Guidance | | ----------------- | ---------- | ----------------------------------------- | --------------------------------------- | | **Soft declines** | Yes | 10 per 24h period | MAC 03, MAC 21 | | **Hard declines** | No | Do not retry | MAC 01, MAC 02, MAC 04 | | **Penalty** | — | $0.10 per attempt after 10 retries in 24h | Fines escalate with repeated violations | Key takeaway: Stripe stays well within these limits by capping at 8 retries. But this conservative approach means leaving recoverable revenue on the table — particularly for soft declines where the networks allow significantly more attempts. *** ## What's Missing: Where Specialized Tools Layer On Top Smart Retries should be your floor, not your ceiling. Here's the gap analysis. ### Smart Retries vs. Full Recovery Stack | Capability | Stripe Smart Retries | Specialized Tool (e.g., FlyCode) | | --------------------------------- | -------------------------------- | -------------------------------- | | ML-optimized retry timing | ✅ | ✅ (per-merchant) | | Cross-processor routing | ❌ (coming with Orchestration) | ✅ | | Coordinated email + retry timing | ❌ | ✅ | | Backup card charging | ❌ (requires custom code) | ✅ (automatic) | | Decline code-specific workflows | Partial | ✅ (granular per code) | | SMS outreach | ❌ | ✅ | | In-app notifications | ❌ | Depends on integration | | Per-merchant ML model | ❌ (global model) | ✅ | | Real-time issuer/BIN intelligence | Partial | ✅ | | Recovery analytics dashboard | Basic (Stripe Billing dashboard) | ✅ (detailed) | | Outcome-based pricing | N/A (free) | ✅ (pay only on recovery) | *** ## Real-World Recovery Rates: What Stripe Alone Achieves vs. Stripe + FlyCode Based on documented customer case studies: | Company | Industry | Stripe Alone Recovery | Stripe + FlyCode Recovery | Improvement | | ----------------- | --------------------- | --------------------- | ------------------------- | -------------------------- | | **BUBS Naturals** | DTC Supplements | \~51% | 66% (peak 71%) | +28.5% | | **Capsho** | SaaS (AI Podcasting) | \~63% | 91% | +44% | | **Gardencup** | DTC Meal Delivery | \~62% | 82% | +32% | | **Framer** | SaaS (Web Builder) | Baseline | +18% lift | 6% ARR impact | | **GitBook** | SaaS (Developer Docs) | Baseline | +29% lift | 8% ARR impact | | **Workiz** | SaaS (Field Service) | Baseline | +15% lift | Significant MRR gain | | **Lucy** | DTC (Nicotine) | Baseline | +46% lift | 11% failure rate reduction | The pattern is consistent: Stripe Smart Retries provide a solid baseline of 40–55%. Layering a per-merchant ML model adds 16–25 percentage points on top. *** ## How to Set Up the Optimal Recovery Stack on Stripe {% stepper %} {% step %} ### Enable Smart Retries (Free) * Navigate to Billing > Revenue Recovery > Retries * Select Smart Retries with 8 retries over 1 month * Enable for both subscription and one-time invoices {% endstep %} {% step %} ### Enable Card Account Updater (Free) * Stripe automatically uses card network updaters to replace expired card details * No configuration needed — but verify it's active in your account {% endstep %} {% step %} ### Configure Email Settings Carefully * Enable "card expiring" pre-dunning emails (30 days before expiry) * For payment failure emails: consider toggling OFF Stripe's native emails and handling comms through a specialized tool for better timing control {% endstep %} {% step %} ### Set Subscription End-of-Life Policy * After final retry: Mark as past due (not cancel) * Set your own cancellation logic with a 30-day buffer via webhook or your app {% endstep %} {% step %} ### Layer a Specialized Recovery Tool * Install FlyCode from the [Stripe App Marketplace](https://marketplace.stripe.com/apps/flycode-payments) * FlyCode reads your Billing webhooks, takes over retry optimization, coordinates communications, and routes payments for the highest-approval path * Go live in hours with outcome-based pricing {% endstep %} {% endstepper %} *** ## Conclusion: Smart Retries Are Your Floor, Not Your Ceiling Stripe Smart Retries are genuinely good — and free. They should be the default for every Stripe Billing user. But they're designed as a general-purpose solution serving millions of merchants globally. For subscription businesses where failed payments represent a material percentage of ARR, the gap between Stripe's baseline and best-in-class recovery is 16–25 percentage points. That gap is pure revenue waiting to be recovered. The winning strategy in 2026: use Smart Retries as your foundation, then layer a per-merchant ML model that coordinates retries, communications, and routing into a unified recovery engine. *** Take the next step: 👉 👉 👉 *** ### Related Reading * * * * *