invocation.io

Billing · Guide

Failed payments and dunning: recovering subscription revenue

Andrej Dragojevic

Andrej Dragojevic

August 27, 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 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 never 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? A 90-minute clarity call with your billing data on screen usually finds the answer. 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 never recover by retrying at all and need the card updater or the customer. 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.

How much are failed payments costing you?

I build dunning and recovery systems on Stripe Billing rails. A clarity call scopes your leak in 90 minutes.

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