> 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/decline-codes-explained/how-flycode-makes-decline-codes-work-for-you.md). # How FlyCode Makes Decline Codes Work for You How FlyCode ingests decline codes from Stripe and the card networks, classifies soft versus hard declines, applies issuer-specific retry timing and coordinates outreach, without touching your existing Decline codes are only valuable if something acts on them in real time. FlyCode turns each code into a decision: retry or not, when, on which payment method, and whether to contact the customer. This page explains how that works and how it fits alongside what you already run on Stripe. ## How does FlyCode use decline codes to improve recovery? FlyCode receives every failed charge as it happens through Stripe webhooks, enriched with issuer and card network data from its Visa and Mastercard partnerships. Each decline is classified automatically as soft or hard, and soft declines are routed to a per-merchant model that chooses the retry moment most likely to succeed for that specific card, based on the decline code, issuer behaviour, card type and brand, geography, past successful charge dates and time of day. Hard declines skip retries entirely and go straight to a backup payment method on file, if there is one, or to customer outreach. Retries and communication are coordinated rather than independent: no dunning email goes out while silent recovery still has a good chance, and when an email is needed it is timed to local hours and matched to the failure reason, so an `insufficient_funds` customer is not told to "update your card". The model also respects the card networks' limits on retry attempts per billing cycle, which protects your issuer relationships and avoids excessive-retry fees. The result, across FlyCode's 500-plus merchant cohort, is 17.6 to 26.2 percentage points more recovery on `insufficient_funds` than Stripe Smart Retries or ProfitWell baselines, with fewer attempts and fewer customer emails, and no engineering work on the merchant's side beyond installing the Stripe app. ## Does FlyCode interfere with my existing Stripe webhooks or apps? No. FlyCode listens to Stripe events passively through its own app installation and then calls the Stripe API to retry a payment, update invoice metadata or adjust subscription status. It never modifies, replaces or overwrites your other webhook endpoints, Radar rules, Billing settings or third-party apps. Your existing integrations keep receiving the same events they always did, and every action FlyCode takes appears in the Stripe Dashboard and event log under the FlyCode app, so it is fully auditable. The only settings to align at go-live are Stripe's own retry and dunning email schedule, so that Smart Retries and Stripe emails do not run in parallel with FlyCode's. The [Stripe integration guide](https://docs.flycode.com/docs/integrations/stripe-integration-guide-for-flycode) walks through those steps. ## Which decline codes does FlyCode never retry? Hard declines and fraud signals: `lost_card`, `stolen_card`, `pickup_card`, `invalid_account`, `invalid_number`, `fraudulent`, `security_violation` and any code Stripe returns with `do_not_try_again` advice. For these the model moves to a backup card on file or immediate outreach. FlyCode also applies a built-in safeguard that never attempts a given customer's charge more than a handful of times per hour, regardless of code. ## Related * [What Decline Codes Tell You](https://help.flycode.com/decline-codes-explained/what-decline-codes-tell-you) * [How does FlyCode decide when to retry a payment?](https://help.flycode.com/handling-failed-payments/when-and-how-payments-are-retried) * [Stripe integration guide for FlyCode](https://docs.flycode.com/docs/integrations/stripe-integration-guide-for-flycode) --- # 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/decline-codes-explained/how-flycode-makes-decline-codes-work-for-you.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.