Article · Updated August 2026

Find failed payments before they become churn

A failed renewal is not yet the same thing as a customer choosing to leave. It is a billing state with a recovery window, a customer experience and an eventual outcome.

Track the lifecycle from the first failed attempt through recovery or expiration. Then report voluntary churn and billing loss separately.

Define the states

Use states that reflect your billing source rather than one generic “churned” flag.

Stripe documents invoice.payment_failed for subscription failures and retry updates. RevenueCat sends a BILLING_ISSUE event and distinguishes billing-error cancellation and expiration in supported store flows. Implement against the source’s current event contract rather than these labels alone.

Capture a canonical billing incident

For each incident, store:

• source and source account;
• customer/account and subscription IDs;
• invoice or store transaction ID;
• product, amount and currency;
• first failure time;
• failure category without exposing sensitive payment data;
• retry count and next attempt when available;
• grace-period deadline;
• communication status;
• final outcome and time;
• recovered amount.

Make ingestion idempotent. Webhooks can be delivered more than once or out of order. Key events by the provider’s event identifier and derive current state from timestamps and source objects.

Separate initial-payment failure from renewal failure

An initial payment failure means the customer may never have become paid. A renewal failure affects an existing subscriber and can become involuntary churn.

Keep separate reporting:

Do not divide failed-payment value by ending MRR and call it churn without defining the cohort and outcome window.

Build the recovery queue

The queue should answer:

1. Which active customers have an unresolved billing issue?
2. What amount is exposed?
3. Is the source retrying automatically?
4. Does the customer need to act?
5. When does grace or retry end?
6. Who owns exceptional follow-up?

Sort by deadline and customer impact, not only amount. A small account about to lose access may need action sooner than a larger invoice with automated retries remaining.

These are fictional accounts and values.

Configure source recovery first

Stripe Billing supports Smart Retries or custom retry schedules, failed-payment email and recovery automation. Stripe notes that some failures are recoverable while hard declines require a new payment method. Use the current source configuration as the control plane rather than building a competing retry engine accidentally.

For app subscriptions, store billing and grace rules vary. RevenueCat documents BILLING_ISSUE, RENEWAL and EXPIRATION flows and whether entitlements remain active during grace. Configure App Store or Play policies, RevenueCat behavior and your entitlement code as one system.

Document:

• retry duration and attempts;
• grace-period duration;
• when access changes;
• which notifications are source-generated;
• when the product communicates;
• final subscription state;
• support escalation rules.

Test the full lifecycle in supported sandbox environments. A webhook arriving is not proof that access and customer messaging behave correctly.

Communicate without creating a phishing pattern

A recovery message should explain the affected product/account, what happened, any access deadline and the trusted place to update payment.

Avoid requesting card data by reply. Send customers to the billing provider’s authenticated portal or your own authenticated billing settings. Make the destination domain recognizable.

Coordinate source email, product messaging and human outreach. Three different notices for one failure can damage trust.

Segment communication by state:

• retry pending: explain that payment did not succeed and whether action is needed;
• action required: provide the direct authenticated update path;
• grace ending: state the access consequence and deadline;
• recovered: confirm normal status without unnecessary alarm;
• expired: explain access and reactivation options.

A fictional recovery cohort

During one mature weekly cohort:

For the 18 initially failed accounts:

• account recovery rate at the mature cutoff: 13 / 18 = 72.2%;
• value recovery rate: $1,070 / $1,420 = 75.4%;
• final involuntary MRR loss: $230;
• unresolved exposure: $120, shown separately rather than prematurely counted as loss.

This fictional example does not provide a benchmark. Its job is to demonstrate denominators and maturity.

Diagnose the unrecovered tail

Group final failures by actionable category supported by the source:

• no usable payment method;
• authentication required;
• hard decline;
• insufficient funds or temporary decline;
• expired card not automatically updated;
• store billing issue;
• configuration or integration failure;
• unknown.

Then compare recovery by source, product, interval, currency, retry policy and customer segment. Use minimum sample sizes and show counts beside rates.

A low recovery rate can be a communication problem, a retry-policy problem, a customer-quality problem or a measurement bug. Inspect the incident records before choosing a fix.

Put failed payments in the founder report

Use a compact block:

Follow with one action: for example, inspect an increase in authentication-required failures after a checkout change.

Do not add unresolved failures to final churn and then add them again if they expire. Why MRR never matches Stripe or RevenueCat explains how lifecycle definitions create reporting differences.

Operational checks

• webhook signatures verified;
• events stored idempotently;
• event timestamps used rather than arrival order;
• sandbox excluded from production reporting;
• source retry configuration recorded;
• entitlement state tested through grace and expiration;
• notification links authenticated and recognizable;
• recovered incidents closed automatically;
• unresolved incidents aged and owned;
• voluntary and billing churn separated;
• customer payment data never copied into analytics.

Frequently asked questions

Sources

• Stripe automated payment retries
• Stripe subscription webhooks
• RevenueCat billing issues and grace periods
• RevenueCat webhook event flows
• A SaaS that died quietly from failed payments
• Failed payments versus cancellation MRR discussion
• Quiet revenue leakage discussion
• Billing issues as a pricing signal