> 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/ai-payment-recovery/hard-declines-and-backup-logic.md). # Hard Declines & Backup Logic Which Stripe decline codes FlyCode treats as hard declines, what it does with them (faster, action-specific outreach and backup card charging), automatic updates for replaced cards, and backup payment Not all failed payments are the same. A soft decline is a timing problem; a hard decline means the card cannot be charged again. FlyCode applies different logic to each, and for hard declines it has two paths that do not depend on the customer responding to an email: charging a backup card and refreshing replaced card credentials automatically. ## Which decline codes does FlyCode treat as hard declines? The issuer responses that mean the card should not be retried. In Stripe's vocabulary these are `incorrect_number`, `lost_card`, `pickup_card`, `stolen_card`, `revocation_of_authorization`, `revocation_of_all_authorizations`, `authentication_required` (the customer must complete 3D Secure, so a silent retry cannot succeed) and `highest_risk_level` (Stripe Radar's block). Codes such as `invalid_account` and anything returned with `do_not_try_again` advice are handled the same way. Everything else, including `insufficient_funds`, `generic_decline`, `do_not_honor`, `try_again_later` and `processing_error`, is a soft decline and goes to the retry model. See [Decline Codes Explained](https://help.flycode.com/decline-codes-explained) for what each code means. ## What does FlyCode do with hard declines? For a hard decline the customer has to change the card on file, so FlyCode does not spend attempts or grace-period days retrying it. First it checks for a backup payment method already on file and charges that if one exists. If not, it adjusts the messaging cadence to be faster than for soft declines, uses dynamic templates with the specific action required ("update your card", "complete verification with your bank"), links to a one-click payment update page, and sequences follow-ups based on the customer's past engagement with emails. Once the customer updates the card, FlyCode retries immediately and marks the invoice recovered. ## Can FlyCode update replaced or reissued cards automatically? Yes. FlyCode supports both Card Account Updater (CAU) and Network Tokens. When an issuing bank replaces or reissues a customer's card, Visa and Mastercard push the new credentials to the card on file, and FlyCode retries with the current details. No action is needed from the customer, and no dunning email has to go out first. A large share of hard declines caused by outdated card credentials are resolved silently this way, so outreach can be reserved for the failures that truly need the customer's attention, such as insufficient funds and generic declines that do not clear after optimized retries. ## Does FlyCode support backup payment methods? Yes. FlyCode can automatically retry a failed payment using an alternate card already on file for the customer, without any manual workflow and without interrupting the customer's service. It is enabled with a single toggle and requires no additional code or collection flow, because it uses the payment methods your billing platform already stores. If every card on file fails, FlyCode falls back to its standard retry and communication logic. Details, legal requirements and reporting are in [Backup Payment Methods](https://help.flycode.com/backup-payment-methods). ## Related * [What to Do When You See These Other Codes](https://help.flycode.com/decline-codes-explained/what-to-do-when-you-see-these-other-codes) * [Failed Payment Outreach: Delivery Strategy](https://help.flycode.com/failed-payment-outreach/delivery-strategy) --- # 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/ai-payment-recovery/hard-declines-and-backup-logic.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.