> 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/flycodes-approach-to-churn.md). # FlyCode's Approach to Churn How FlyCode reduces involuntary churn: AI-optimized retry timing, backup cards, credential updates, coordinated email and SMS, root-cause analytics, and the best practices merchants should keep alongs FlyCode treats involuntary churn as a payment optimization problem: recover silently first, communicate second, and only involve the customer when automation has been exhausted. This page explains how that works, whether it prevents churn rather than just reacting to it, and what merchants should keep doing themselves. ## How does FlyCode attack involuntary churn? With five coordinated mechanisms, applied in order of least customer friction. AI-optimized retry timing: a per-merchant model trained on your own transaction data predicts the moment each failed card is most likely to succeed, using the decline code, issuer behaviour, card type, geography and prior payment dates, within card network retry limits. Backup payment methods: when the primary card fails hard, FlyCode charges another card the customer already has on file. Credential updates: Card Account Updater and Network Tokens refresh replaced or reissued cards automatically. Coordinated outreach: personalized email and SMS reminders are held while silent recovery still has a good chance, then sent in the customer's local time with a message matched to the failure reason. Root-cause analytics: decline distribution, recovery KPIs and anomaly alerts so you can see what is failing and why. All of it plugs directly into Stripe, Shopify subscription apps (Recharge, Skio, Stay AI), Braintree and PayPal, with no integration work on your side. ## Can automation really stop failed-payment churn before it happens? Yes, a large share of it. Automatic card credential updates prevent failures from replaced cards before the renewal is attempted. Real-time decline handling recovers most soft declines within the grace period, often before the customer notices. Machine-learning risk prediction flags accounts likely to fail on the next cycle, so a backup method or a billing-date adjustment can be arranged in advance. Flexible billing (for example aligning renewal dates with the customer's likely payday) removes the most common trigger for insufficient funds. Across FlyCode's merchant base these measures move recovery rates from an industry baseline of roughly 40 to 55 percent to 70 percent or more, which is what turns a failed payment from a churn event into a delay. ## What best practices should I follow alongside FlyCode? Four habits make recovery work better. Keep cards up to date: enable Card Account Updater and Network Tokens with your processor and prompt customers to update details at natural touchpoints. Offer multiple payment options: collect a backup card or an alternative method such as PayPal or bank debit at checkout so there is a fallback. Let customers adjust billing timing: allowing a change of renewal date or a short pause removes many insufficient-funds failures at the source. Use predictive analytics: watch the accounts FlyCode flags as high-risk and treat a repeat decline pattern as a customer-success signal, not just a billing one. Finally, keep your past-due grace period at 30 days or more; once a subscription is cancelled, recovery drops close to zero. ## Related * [Handling Failed Payments](https://help.flycode.com/handling-failed-payments) * [Failed Payment Outreach](https://help.flycode.com/failed-payment-outreach) * [What Makes FlyCode Different](https://help.flycode.com/what-is-flycode/what-makes-flycode-different) --- # 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/flycodes-approach-to-churn.md?ask=&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.