> For the complete documentation index, see [llms.txt](https://help.flycode.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.flycode.com/handling-failed-payments/reducing-churn-from-failed-payments.md).

# Reducing Churn from Failed Payments

How to solve involuntary churn from failed payments: AI-optimized retries, alternate card on file routing, and predictive dunning that reaches customers before the subscription lapses.

Involuntary churn is mostly a payment problem, which means it can be solved in the payment flow. This page describes the three-front approach FlyCode uses and the order in which the fronts are applied.

## How can I solve involuntary churn?

Attack it on three fronts, in this order.

**1. AI-optimized retries.** Most failed subscription payments are soft declines (insufficient funds, generic bank declines, transient processing errors) that will succeed if retried at the right time. A per-merchant model that predicts the best retry moment for each card recovers the majority of these silently, before the customer is aware of any issue. This is where most of the recoverable revenue is.

**2. Alternate card on file routing.** When the primary card fails hard (closed, lost, stolen, invalid), retrying is pointless. If the customer has another payment method on file, charging it automatically recovers the payment with zero friction. Collecting a backup method at checkout, and enabling Card Account Updater and Network Tokens so replaced cards are refreshed automatically, widens this path.

**3. Predictive dunning.** For the failures that neither retries nor backup methods can fix, reach the customer before the subscription lapses, not after. Messages should go out only once automation has been exhausted, be timed to the customer's local hours, name the specific action needed, and link to a one-click card update. Predictive signals (repeat declines, high-risk issuers) let you prompt at-risk accounts before the next renewal fails.

The result is fewer cancellations for non-payment and higher lifetime value, because every recovered subscriber keeps paying for the rest of their expected tenure. Merchants applying all three fronts move from industry-average recovery of 40 to 55 percent to 70 percent or more.

## What should I measure?

Track involuntary churn separately from voluntary churn. The core metrics are payment failure rate (failed charges divided by attempted charges), recovery rate (recovered divided by failed), recovery speed (days from first failure to success), passive-to-active conversion (customers who cancel after receiving a dunning email) and revenue at risk (failed MRR times remaining customer lifetime). The [Involuntary churn guide](https://docs.flycode.com/docs/involuntary-churn-hidden-revenue-killer) has healthy benchmarks for each.

## Related

* [Understanding Involuntary Churn](https://help.flycode.com/understanding-involuntary-churn)
* [Failed Payment Outreach](https://help.flycode.com/failed-payment-outreach)
* [Free churn analysis](https://www.flycode.com/churn-audit-failed-payments)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.flycode.com/handling-failed-payments/reducing-churn-from-failed-payments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.