> 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/functionality.md). # Functionality How backup card retries work in practice: what counts as a backup method, why no manual collection is needed, the fallback order, and what happens when every card on file fails. This page covers how backup retries behave once enabled: what qualifies as a backup, where the cards come from, and the fallback path. ## What counts as a "backup" payment method? Any additional valid card already on file for the customer in your billing platform. If the primary card fails and the recovery sequence has determined that further retries on it are unlikely to succeed (immediately for hard declines, after optimized retries for soft declines), FlyCode automatically retries using the next available card on file, without asking the customer or interrupting service. Where the customer has more than one backup, FlyCode orders them by likelihood of success. Non-card methods such as bank debit or wallets can be included where the processor supports charging them off-session. ## Do I need to collect backup cards manually? No. FlyCode works with the cards your billing platform already has on file, so there is no extra collection flow and no customer input required. Many customers already have more than one card stored from past purchases, plan changes or card replacements. If you want to increase coverage, you can invite customers to add a backup method at checkout or in account settings, and FlyCode's outreach templates can include that prompt, but it is optional. ## What happens if all cards on file fail? FlyCode reverts to its standard retry and communication logic. The smart retry engine continues to work the primary card within card network limits where the decline type allows, and coordinated outreach asks the customer for a new payment method with a one-click update link. Nothing is lost by trying the backup first; it simply adds a recovery path before the customer has to be involved. ## Related * [Product Overview](https://help.flycode.com/backup-payment-methods/product-overview) * [What FlyCode does with hard declines](https://help.flycode.com/ai-payment-recovery/hard-declines-and-backup-logic) --- # 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/functionality.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.