invocation.io

Billing · Guide

Failed payments and dunning: recovering subscription revenue

Andrej Dragojevic

Andrej Dragojevic

April 13, 2026 · 9 min read

Involuntary churn is the quietest leak in subscription revenue: nobody decides to leave, nothing shows up in cancellation surveys, and the money is simply gone at renewal. Having built billing systems that protect $100M+ in recurring revenue, I can tell you the uncomfortable part: most businesses under-invest here precisely because no one is complaining. Here is the recovery system that works.

Why good cards fail

Expired and reissued cards, breached-BIN reissues, spending limits, issuer fraud models that dislike a merchant category that day, insufficient funds at the wrong hour. The customer did nothing; the rail hiccuped. Every recovery mechanism below exists because the failure is usually circumstantial, not intentional.

The recovery stack, in order of yield

  • Card updaters first. Network-level card updating silently refreshes reissued cards before renewal even runs. It is usually the highest-yield, zero-customer-contact fix, and on modern platforms it is a setting, not a project.
  • Adaptive retries second. Retry by decline reason: insufficient-funds recovers days later; do-not-honor sometimes recovers at a different hour; expired-card rarely recovers by retrying. A fixed every-24h schedule burns retry budget where it cannot work and under-tries where it can.
  • Dunning emails that behave like service, not collections. Plain sender, plain subject, one-click card update, no shame. The sequence spans the retry window: a gentle note after the second failure, a clearer one as options narrow, a final notice with an exact date. Every email a customer reads as "helpful heads-up" converts; every one read as "debt collector" churns.
  • In-app recovery beats email. A banner for the logged-in user with a failed payment converts far better than any message in an inbox — they are already engaged, mid-value.
  • Grace states, explicitly modeled. Active → past-due (full access) → restricted → cancelled, each a real state with real dates in your billing data — not a boolean and a prayer. This is also what keeps support and your ledger telling one story.

Measure it or it is not happening

  • Recovery rate — recovered ÷ failed renewals, monthly, by decline reason and by card country.
  • Involuntary share of churn — the number that tells you whether this deserves engineering time (it does).
  • Time-to-recovery — long tails mean your retry window and access states are misaligned.
  • Updater hit rate — how much churn never happens; the invisible win worth reporting.

On Stripe Billing most of this stack is configuration plus a well-built email layer — which is why the honest first step is rarely "build a dunning system" and usually "wire the one you already pay for, correctly, and measure it."

Want the leak sized before you invest? The billing health audit puts a number on it in five days, from your own billing data. Deeper builds are payments engagements.


Frequently asked questions

How much revenue does involuntary churn actually cost?

For a typical subscription business, failed payments cause a meaningful share of all churn — often rivaling voluntary cancellation — and most of it is recoverable. Cards expire, get reissued, hit limits, or trip an issuer's fraud model on a normal renewal. The customer never decided to leave, which is exactly why treating the failure as a payments problem rather than a retention problem recovers so much of it.

What is the best retry schedule for failed subscription payments?

Not a fixed schedule — an adaptive one. Retry timing should follow the decline reason and issuer behavior: insufficient-funds failures recover best days later (often just after typical paydays), while expired-card failures rarely recover from retries alone — the card updater or the customer usually has to supply the new card. Modern billing platforms ship machine-tuned retry timing; if you hand-roll, vary hour-of-day and day-of-week rather than hammering a dead card nightly.

Should failed payments cancel the subscription immediately?

No. A grace state that preserves access briefly, degrades gracefully after, and communicates clearly outperforms immediate cancellation on every metric that matters. The customer who hits a paywall because their bank reissued a card feels punished for nothing they did. The sequence that works: silent retry, then helpful notice, then restricted access, then cancellation as the last step, not the first.

Written by Andrej Dragojevic, Stripe Certified Professional Billing Architect.

Useful? Set Invocation as a preferred source on Google to see these guides more often.

How much are failed payments costing you?

I build dunning and recovery systems on Stripe Billing rails. The billing health audit puts a number on your leak in five days.

I reply within one business day. Now booking new engagements.