Total $ leaked through soft declines that Smart Retries / dunning could recover next month.
At a glance
The 30-day rolling estimate of revenue recoverable through Smart Retries, dunning, and 1:1 customer outreach if the merchant acted on their soft-decline backlog. Where Revenue at Risk (live) shows live spike-driven loss, this card captures the cumulative leak from the recoverable subset.
Calculation
Calculated automatically from your Stripe data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US subscription brand selling at $49 / month on Shopify + Stripe. Window covers 13 Mar 26 to 12 Apr 26 (30 days, 980 charges within the cap).- **The hard-decline buckets are 637 / month leaving the business with no plausible recovery path. The fix isn’t retries; it’s a payment-method-update flow that prompts customers to add a new card before the next billing cycle.
- Radar blocks are the loudest hidden cost. 441 with no retry effort. The card excludes these from the headline number deliberately, retries don’t help, but Radar Score Distribution does.
- A subscription store gets near-perfect repurchase rate (96%). A DTC apparel merchant with the same gross soft-decline of 4,508 × 0.42 × 0.12 = $227. Same gross leak, very different recoverable number. Subscription business models recover much more from the same backlog.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Stripe Dashboard: Stripe Dashboard does not expose a “recoverable revenue” composite. The closest Stripe-native screens for cross-checking the inputs:- Payments → Failed payments for the soft-decline backlog (filter
outcome.reasontodo_not_honor,insufficient_funds,expired_card,generic_decline). - Billing → Subscriptions → Recovery insights for Stripe’s own dunning-recovery view (subscription stores only).
- Reports → Decline analysis report for the historical retry-success-rate input.
- Stripe Billing’s “Recovered MRR” tile. This is post-retry recovered revenue (i.e. money that already came back). Our card is the forecast of how much could still be recovered.
- Stripe Sigma “soft-decline value” queries. Closest Stripe-native equivalent. They typically don’t apply repurchase-rate / Smart-Retry multipliers; the gross number runs higher than ours.
- Recharge / Bold Subscriptions dunning dashboards (third-party). Show the third-party app’s recovered revenue, scoped to that app only.
Cross-connector reconciliation:
This is a cross-connector card by design.
End-to-end: this card is meant to answer “is the recovery effort worth doing?”. A merchant looking at 20k / month should.
Known limitations / merchant FAQs
Reconciliation questions are answered in the Reconciling against the vendor’s own dashboard section above.“Why is the recoverable number lower than my failed-payment total?” By design. The card multiplies the soft-decline gross by a realistic Smart-Retry success rate (typically 30, 45%) and a repurchase rate (8% DTC, 95%+ subscription). Both multipliers reflect what’s actually achievable, not the theoretical maximum. The gross-recoverable view is on Recoverable Declines. Use that for “what could possibly be recovered if every retry worked”; use this card for “what the recovery effort is worth committing to”. “Are 3DS abandons in the recoverable estimate?” No. 3DS abandons sit at
status = canceled or requires_action, not failed, so they don’t reach the soft-decline filter. The merchant either implemented 3DS optimisation already or has a different leak; either way the recovery action is different. See 3DS Friction Loss for that view.
“Are SCA-required charges that the customer abandoned counted?”
No, same reason as above.
“Why are Radar-blocked charges (highest_risk_level) excluded?”
Because retries don’t recover them. Stripe Radar evaluates each new charge against the same rules; a card flagged highest_risk_level will be flagged again on retry. The recovery action for Radar-blocked charges is rule tuning, not retry. The dollars are real but they belong on a different recovery card; see Radar Score Distribution.
“Are hard-decline charges (lost_card, stolen_card, pickup_card) counted?”
No. These are unrecoverable: the customer needs a new card, not a retry. The fix is a payment-method update flow that prompts the customer to add a fresh card before next billing. The dollars are real but the recovery is a fundamentally different motion. We deliberately exclude to keep the recoverable headline honest.
“Multi-currency, what currency is the estimate in?”
The commerce sibling’s primary store currency. Soft-decline amounts in non-primary currencies are FX-converted at the day’s mid-market rate. The conversion is estimate-grade; for accurate per-currency views use Revenue by Currency and apply the per-currency Smart-Retry rate yourself.
“My subscription store sees a much higher number than a DTC merchant with the same backlog, why?”
Because subscription stores have near-100% repurchase rate (the customer is already on the renewal schedule). DTC stores see 8, 25% repurchase rates because the customer would need to come back and buy again. Same gross soft-decline backlog, very different recoverable. This is also why subscription stores get the most ROI from Smart Retries.
“What if I haven’t run any Smart Retries yet?”
The card uses a 35% default Smart-Retry success rate (Stripe-published industry average) until you have 90 days of retry history. The estimate is a “if you were running industry-average retries” view. Once you actually start retrying, the rate becomes merchant-specific within 90 days.
“How does the alert threshold work?”
The card alerts when the rolling 30-day estimate goes above 5k / month the recovery effort isn’t worth a quarter of engineering, above $5k it usually is. Recurring revenue stores hit this threshold faster because of the repurchase-rate multiplier.
“Will my actual recovery match the estimate?”
Roughly, within ±25%. The multipliers are population averages; individual customers vary. You can validate by comparing this card’s estimate from 30 days ago to the actual recovered revenue you saw in the last month, the gap is your calibration error.