> 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/backup-payment-methods/product-overview.md). # Product Overview What FlyCode's backup payment method product is, its benefits (higher and faster recovery, less involuntary churn, no integration), why it is allowed and standard practice, and the terms-of-use langua Backup payment methods turn a hard decline from a customer-action problem into an automatic recovery. This page explains the product, its benefits, why it is legitimate, and what you need in your terms before switching it on. ## What is the backup payment method product? FlyCode's backup payment method product automatically charges any other valid payment method linked to the customer's account when the primary payment method fails. If a subscriber has two cards on file and the first is declined (for example because it was closed or reported lost), FlyCode charges the second at the appropriate point in the recovery sequence, the invoice is paid, and the subscription continues without interruption. The customer is not asked to do anything and does not receive a dunning email unless every method fails. ## What are the key benefits of the backup payment method product? No additional integration or collection flow: FlyCode uses the payment methods your billing platform already stores. Higher recovery rates, because a class of failures that previously depended on the customer responding to an email now resolves automatically. Faster recovery, since the fallback charge happens within the retry sequence rather than after days of outreach. Less involuntary churn and higher lifetime value, because customers never experience a service interruption. And a better customer experience, with fewer payment emails. ## Do backup payment methods make sense? Is it allowed? Yes on both counts. Backup card retries are standard practice among leading subscription companies: Netflix, Amazon, Microsoft and LinkedIn all charge a backup payment method to minimize churn and maximize lifetime value. Card network rules permit charging a stored credential the customer has authorized for recurring billing, provided the customer has agreed to the arrangement. The requirement is disclosure and consent, which is why the terms-of-use step below matters. ## What kind of legal terms should we have in order to enable the product? Your customers must be aware that you may charge another payment method they have on file if the primary fails. In practice that means your terms of use or subscription agreement should state it explicitly (for example: "If your primary payment method fails, we may charge any other payment method you have saved to your account"), the same language should appear where customers add a payment method, and you should notify existing customers of the change before enabling the product. FlyCode can provide sample wording, but you should confirm it with your own counsel, since consumer protection and auto-renewal laws vary by jurisdiction. See also [Subscription Compliance](https://help.flycode.com/subscription-compliance). ## Related * [Functionality](https://help.flycode.com/backup-payment-methods/functionality) * [Reporting](https://help.flycode.com/backup-payment-methods/reporting) --- # 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/backup-payment-methods/product-overview.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.