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.
| What it counts | SUM(charges.amount WHERE outcome.reason ∈ {do_not_honor, insufficient_funds, expired_card, generic_decline}) × commerce_sibling.avg_repurchase_rate × estimated_smart_retry_success_rate. The reason-filter isolates only soft (recoverable) declines; the multipliers convert the gross loss into the realistic recovery estimate. |
| API resource & fields | GET /v1/charges for amount, status, outcome.reason, failure_code; commerce sibling for avg_repurchase_rate. |
| Currency | The commerce sibling’s primary store currency. Soft-decline amounts in non-primary currencies are FX-converted at the day’s mid-market rate (a reasonable estimate, not a settlement-accurate number). |
| Fees / processing cost | NOT deducted. The card answers “how much top-line revenue is recoverable”, not “how much net revenue”. A successful retry would generate a new processing fee. |
| Refunds | NOT a factor. The charges in scope never succeeded, so they could not have been refunded. |
| Disputes / chargebacks | NOT a factor. Same reason. |
| Failed / declined payments | This is the metric source. Specifically, the soft-decline subset of failed charges. Hard declines (lost_card, stolen_card, pickup_card) are excluded because they’re unrecoverable. |
| Smart-Retry success-rate input | A merchant-specific historical rate, computed from the last 90 days of metadata.retry_attempt-tagged charges. New merchants without retry history use a 35% default (Stripe-published industry average). |
| Repurchase-rate input | The commerce sibling’s avg_repurchase_rate. Subscription stores see this near 100% (they’ll retry next billing cycle); single-purchase DTC stores see 8, 25%. |
| Page cap | 1,000 charges per refresh. High-volume merchants (>1,000/day) see the recoverable estimate computed on the most recent slice, the trailing edge of the 30-day window can be missed. |
| Time window | 30D (rolling) |
| Alert trigger | > $5k/month, suggests the recovery effort would be worth dedicated work (Smart Retries enabled, dunning emails configured, payment-method update flow in place) |
| Roles | owner, finance, marketing |
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).outcome.reason (status=‘failed’ subset) | Count | Sum (USD) | Recoverable? | Notes |
|---|---|---|---|---|
insufficient_funds | 28 | $1,372 | YES | Customer side, recoverable next billing cycle |
do_not_honor | 41 | $2,009 | YES | Issuer side, recoverable on retry |
expired_card | 14 | $686 | YES | Recoverable via Stripe Card Updater + payment-method update flow |
generic_decline | 9 | $441 | YES | Loosely defined, often recoverable |
lost_card | 3 | $147 | NO | Hard decline, never retry |
stolen_card | 2 | $98 | NO | Hard decline, never retry |
incorrect_cvc | 7 | $343 | NO | Customer typo; some retry on re-attempt but card-level recovery rate is poor |
pickup_card | 1 | $49 | NO | Hard decline |
highest_risk_level (Radar) | 18 | $882 | NO | Radar block; needs rule tuning, not retry |
- **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
| Card | Why merchants reach for it next to Recoverable Revenue |
|---|---|
| Recoverable Declines | The Stripe-only count + sum, before the repurchase-rate / Smart-Retry-rate multipliers. The “gross recoverable” before realism applied. |
| Decline Reasons | The decomposition driving this card. Recovery action depends on whether do_not_honor, insufficient_funds, expired_card is the dominant reason. |
| Retry Success Rate | The Smart-Retry input. If this rate climbs, the recoverable estimate climbs in lockstep. |
| Revenue at Risk (live) | The live spike-driven loss. This card is the rolling 30-day version of the same conceptual loss. |
| Decline vs Funnel | The signal that detects decline-driven losses in real time. |
| Dunning Recovery Rate | For subscription stores, measures the merchant’s existing dunning system’s effectiveness. |
| Shopify Repeat Customer Rate / BC Customer Lifetime Value | The commerce-side input. The repurchase-rate driver of the multiplier. |
| Payment Health Score | A high recoverable-revenue value typically co-moves with a low health score; recovering soft declines is the fastest health-score lift. |
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.
| Reason | Direction | Why |
|---|---|---|
| Multipliers | Ours lower than gross soft-decline sum | Stripe Dashboard’s Failed Payments tab shows the gross number; we apply two realism multipliers (Smart-Retry success rate × repurchase rate) before reporting. Our number is meant to be actionable. |
| Page cap (1,000 charges) | Ours based on the most recent slice | High-volume merchants see the trailing edge of the 30-day window dropped. |
| FX conversion | Ours estimate-grade | Multi-currency soft declines are FX-converted at the day’s mid-market rate to a single store-currency number. Stripe Dashboard may show per-currency tiles or settlement-currency totals. |
| Smart-Retry success-rate input | Variable | We use the merchant’s last 90 days of retry history; Stripe Dashboard recovery views may use a different lookback. |
| Repurchase-rate input | Depends on commerce sibling | A merchant connected to GA4 will see slightly different repurchase rates than one on Shopify; we use the commerce sibling’s rate, with Shopify > BC > Adobe in priority order. |
| Hard-decline exclusion | Ours strict | We exclude lost_card, stolen_card, pickup_card, incorrect_cvc, highest_risk_level from the recoverable set. Some Stripe Dashboard views treat all failed charges as “potentially recoverable”. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
stripe_xc_recoverable_revenue ↔ stripe.stripe_recoverable_declines | The latter is gross; ours is gross × Smart-Retry rate × repurchase rate, so ours always sits below. The ratio is the merchant’s combined recovery efficiency. | A ratio < 0.10 means low repurchase rate and / or low Smart-Retry rate; recovery efforts have low ROI. |
stripe_xc_recoverable_revenue ↔ stripe.stripe_dunning_recovery_rate | Subscription stores: the recovery rate is essentially the Smart-Retry success rate input. The two numbers should reconcile via recoverable_revenue ≈ gross_soft_decline × dunning_recovery_rate × subscription_repurchase_assumption. | A large gap suggests the merchant’s dunning is reaching only a subset of customers (e.g. only past_due, not unpaid). |
stripe_xc_recoverable_revenue ↔ commerce sibling Customer Lifetime Value | A high CLV / repeat rate makes the recoverable estimate higher (more customers will re-attempt purchase next cycle). | Subscription vs DTC stores see very different multipliers; same Stripe backlog, very different recoverable estimates. |
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.