> 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/understanding-involuntary-churn/causes-and-risks.md).

# Causes & Risks

Why subscription payments fail (insufficient funds, generic bank declines, incorrect details, gateway errors), what hard declines mean for automatic retries, and what failed-payment churn costs beyond

Most failed subscription payments are not the customer's fault and are not permanent. Understanding the causes tells you which failures can be recovered silently and which need the customer, and understanding the risks shows why the lost invoice is the smallest part of the cost.

## What are the main reasons a payment fails?

The main causes, in rough order of frequency, are insufficient funds, generic bank or card declines, incorrect or outdated billing details, and gateway or processor technical errors.

**Insufficient funds** is the largest single category, 50 to 70 percent of declines in FlyCode's 500-plus merchant study, driven by renewals that land before payday, pending holds and card spending limits. **Generic and issuer declines** (`do_not_honor`, `generic_decline`) are the next largest: the bank refuses without a stated reason, usually because of internal risk rules, velocity limits or restrictions on recurring or cross-border charges. **Incorrect or outdated details** cover wrong numbers, failed CVC or postcode checks and cards that have been replaced, closed, lost or stolen. **Technical errors** (`processing_error`, `issuer_not_available`, `try_again_later`) are transient failures in the bank, network or gateway and almost always succeed on a prompt retry.

The first two categories and the technical errors are soft declines and make up roughly 60 to 70 percent of all failures. Only the outdated-details category is hard. See [Decline Codes Explained](https://help.flycode.com/decline-codes-explained) for code-level detail.

## What are hard decline codes in failed payments?

A hard decline is a permanent refusal for that card: the issuer has said the card cannot be charged again, so retrying will not work. Typical codes are `lost_card`, `stolen_card`, `pickup_card`, `invalid_account`, `invalid_number` and anything returned with `do_not_try_again` advice. When the issuer returns a hard decline, FlyCode does not automatically retry the same card. Instead it moves to the next recovery path: charging a backup payment method already on file, refreshing card credentials through Card Account Updater or Network Tokens where the issuer has reissued the card, and if neither applies, contacting the customer immediately with a specific request for a new payment method. Because hard declines are identified on arrival, no retry attempts or grace-period days are wasted on them.

## Beyond revenue, what else is at risk?

Three things. First, customer experience: failed-payment churn cuts off otherwise happy customers, and a badly timed or generic dunning email can turn a customer who did not know about the problem into one who decides to cancel, converting involuntary churn into voluntary churn. Second, brand perception: a locked account or a stream of payment reminders reads as the business's failure, not the bank's. Third, acquisition cost: every subscriber lost to a failed payment has to be replaced, at a customer acquisition cost that is typically 5 to 10 times higher than the cost of recovering the payment, and the replacement starts from zero lifetime value.

There is also a compliance dimension: retrying declined cards too aggressively breaches Visa and Mastercard retry rules and can trigger excessive-retry fees or issuer penalties, so recovery has to be intelligent as well as persistent.

## Related

* [How to Handle the Most Common Declines](https://help.flycode.com/decline-codes-explained/how-to-handle-the-most-common-declines)
* [Backup Payment Methods](https://help.flycode.com/backup-payment-methods)
* [Failed payment cost recovery ROI](https://docs.flycode.com/docs/failed-payment-cost-recovery-roi)


---

# 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/understanding-involuntary-churn/causes-and-risks.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.
