# 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 * * * * * --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.flycode.com/docs/stripe-smart-retries-complete-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.