Involuntary churn: measure your number

Your processor has been retrying failed payments for months, and you still cannot say how much of that involuntary churn you recovered. The published recovery rates you would compare against do not share a denominator, so none of them is a target.

The claim in three sentences, with every Stripe mechanic verified on 2026-09-28.

• The four most-quoted figures (12.7, 47.6, 53, and 55 percent) divide by different things, and most trace to a vendor selling recovery tooling. None can rank your account.
• Recovered dollars per failed dollar is the number to own; Stripe's Recovery analytics shows the components, and both denominators belong in the report.
• The layers go in cost-and-dependency order: processor retries, then the card-update flow, then soft-decline segmentation.

Why involuntary churn benchmarks cannot be compared

Search for an involuntary churn benchmark and four figures come back: Baremetrics at 12.7 percent, Recurly at 53 percent, Stripe's billing page at 55 percent, and a secondhand "industry median" of 47.6 percent.

They differ on the denominator, the sample, and who profits from the number.

Baremetrics sells recovery software, and it is the one vendor here that states whether its denominator counts attempts or failures. Its report says recovered divided by all failed charges "contaminates the denominator with failures the dunning system never attempted to recover." If a source cannot say whether its rate is attempted or naive, do not trust it.

Four published figures, four definitions. The 47.6 percent median is secondhand: a 2025 page attributes it to a Recurly study that could not be found. None of the four shares your pricing, geography, or payment-method mix. Source: Baremetrics 2026-06, Recurly 2026-01, Stripe billing page, Slicker 2025-09; verified 2026-09-28.

One more figure circulates: 9 percent of monthly recurring revenue lost to failed payments. It is a Baremetrics average over its own customers, repeated as an unsourced estimate and set against Paddle's 10 percent on a different measurement. Vendor lore, not a target.

None of these shares your pricing, geography, or payment-method mix. So here is the claim this post defends: published recovery rates do not share a denominator and trace mostly to vendor reports. The only honest target is recovered dollars per failed dollar, measured in your own account, and the layers move in cost-and-dependency order: retries, the card-update flow, then soft-decline segmentation.

Measure failed payment recovery in your account

Stripe's Recovery analytics metric definitions name the metrics you need, over recurring subscription payments only, excluding the first invoice after a trial.

• Failed payments: payments failing on the first attempt.
• Recovery rate: failed volume recovered by any means.
• Recovered volume by method: Retries, Emails, and Other (third-party or API attempts).
• Failed volume by decline reason: your top five decline codes.

A synthesized month: 300 subscribers at $100, so $30,000 MRR. Fifteen invoices fail on the first attempt, so failed volume is $1,500. Recovery analytics shows $400 recovered by retries and $500 by emails, so recovered volume is $900.

Recovered dollars per failed dollar: $900 / $1,500 = $0.60. Set it next to the two official rates:

Stripe shows 60 percent because its denominator is all failed volume. The attempted rate is 45.5 percent because the four invoices resolved by retries never reached the dunning layer, so the $500 it recovered divides by the $1,100 it attempted - 5 of 11 invoices, not 9 of 15. That difference is the denominator problem in miniature; report both or the number is not auditable.

Log it by subscribing to invoice.payment_failed and reading attempt_count and next_payment_attempt. With Billing Automations, next_payment_attempt is set in invoice.updated instead. attempt_count includes scheduled retries that never executed on a hard decline, so it overstates charges made.

One month is a small sample, so keep a rolling three-month column. On the first of each month, read four things:

• Failed dollars. A jump while MRR is flat means your payment mix or price changed.
• Recovered volume by method. If Emails beats Retries, the card-update path deserves a look.
• Recovery rate next to your attempted rate. A widening gap means retries resolve more before dunning engages.
• Top five decline codes. This picks the next layer.

That number belongs on a short list; the metrics that decide survival covers the rest.

Build failed payment recovery in cost order

The order is cost and dependency, not measured ROI. No published dataset measures these three layers on one denominator, and the vendor tables disagree with each other. Test the order in your own account, cheapest and most mechanical first.

Four paths out of one failed invoice. The last box in each lane is the action that can recover the money; the middle box is the distinction that decides the action. Source: Stripe Billing, Smart Retries, and card decline docs, verified 2026-09-28.

What Stripe Smart Retries can and cannot recover

Stripe's Smart Retries documentation describes the first layer, and the docs treat retries as a setup step: check that yours are enabled. The recommended policy is 8 tries within 2 weeks; the windows are 1 week, 2 weeks, 3 weeks, 1 month, or 2 months. A custom schedule caps at 3 retries, each set as days after the previous attempt. Stripe recommends a maximum of 8 because issuers can read more attempts as fraud, raising declines on legitimate charges.

Nine codes cannot be retried at all without a new payment method: incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level, and transaction_not_allowed. On these hard declines the docs describe a trap: retries stay scheduled and attempt_count keeps incrementing, but no new Charge is created.

No payment methods on file means no retry; India-issued cards are excluded; a disconnected Connect account stops retries. Local methods such as ACH and SEPA are not retried by default and carry their own caps.

When the window exhausts, the subscription lands in canceled (terminal), unpaid (draft invoices keep generating), or past_due, per your Dashboard settings, which affect future retries only.

When only a card update helps

Stripe's failed-payment email mechanics ship with Billing: when enabled, an email goes out after each failure and links to a hosted page where the customer updates the payment method. The link stops working in cases the docs define, including 30 days after a trial-ending email, when the subscription becomes canceled, incomplete_expired, or unpaid, or when the renewal period expires. The sandbox does not auto-send these.

The field gotcha is where integrations break. Retries read subscription.default_payment_method first, then subscription.default_source, then customer.invoice_settings.default_payment_method, then the legacy customer.default_source. Stripe's rule: "When you update payment methods after a failed payment attempt, update the field where the previous payment failed." If you update only the customer-level field, retries keep hitting the dead card.

For a customer-scoped failure, the verified call looks like this:

curl https://api.stripe.com/v1/customers/{{CUSTOMER_ID}} \
  -u "<<YOUR_SECRET_KEY>>:" \
  -d "invoice_settings[default_payment_method]={{PAYMENTMETHOD_ID}}"

For a subscription-scoped failure, set the Subscription's default_payment_method; the Smart Retries documentation is the reference.

Card Account Updater runs underneath. Stripe's explainer says it is automatic for stored cards with a customer attached, widely supported for US-issued cards, and limited to credential failures: it will not fix insufficient funds, fraud blocks, or credit limits. Cardholders can opt out, a reissue near a billing date can miss, and it can update a card for a customer who wanted to leave. Stripe's pricing page lists card account updater as included at no additional charge on standard payments pricing, while Stripe's own explainer quotes 25 cents per update for custom services, so check your invoice line.

Segment soft declines from hard ones

Stripe's card declines page notes that issuers categorize most declines as generic (generic_decline), so the code alone tells you little. The issuer's next-step hint is advice_code: do_not_try_again, try_again_later, or confirm_card_data.

Published decline mixes disagree: one vendor aggregation puts insufficient funds at 28 to 35 percent of failures; a Forrester figure quoted by Chargebee says 53 percent. Your own top five codes are the only mix that matches your customers.

One r/stripe thread times retries to payday and claims 60 to 70 percent recovery. Treat it as an unverified anecdote, not a target.

Buy or build at solo volume

Two vendor tables, the same promise, different numbers and different layer names. Both sellers aggregate other vendors' data; the gap between the tables is a reason to measure your own account, not a target to chase. Source: Recurflux (2026) and DunningBee (2026-03) vendor pages, verified 2026-09-28; taxonomies differ.

The native layers are also the cost lines to compare against a tool.

A synthesized month: $600 still unrecovered, and a $49/month tool recovers $500 of it. Cost per recovered dollar: $49 / $500 = $0.10, before counting anything the native layers would have missed. The native layers were $0 incremental. Recompute monthly.

At low volume, the buy question is not which tool carries the best AI label. It is which customer-facing layer you have not built. Test your own account before buying anything.

What this number leaves out

Vendor selection bias runs through every figure above: each comes from a party selling recovery tooling or billing software, and no independent study was found. That is the strongest argument for measuring your own account.

Card updater coverage is US-centric, limited to credential failures, and silent when a cardholder opts out. Recovered dollars are gross: processor fees still apply, refunds and disputes can claw back revenue, and revenue recognition timing is out of scope. This is not tax or accounting advice.

Never collect or store raw card numbers; use the hosted page or Elements. Verify webhook signatures before acting on invoice.payment_failed, which how to make a webhook handler idempotent covers, and never surface a reason Stripe presents as generic_decline. Test in a sandbox first, where emails do not auto-send. The 9 percent line and community percentages stay anecdotes, not targets.

The number to keep watching

One number: recovered dollars per failed dollar, read monthly against your decline mix, one layer added at a time, with the previous month kept for comparison. It will not match any vendor headline, and that is the point: it is the only involuntary churn number whose denominator is your business.

The one-time Stripe Checkout flow is covered in the payments chapter of the AI Development Handbook; recurring billing and dunning are outside that chapter's scope. If the deployment side is the blocker instead, Deploy & Ship is the second option.