> For the complete documentation index, see [llms.txt](https://docs.flycode.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flycode.com/docs/guides/backup-payment-methods-on-stripe-for-subscription-recovery.md). # Backup payment methods on Stripe for subscription recovery How to collect and use a backup card on Stripe subscriptions: what Stripe does and does not do, consent language, and how FlyCode's adaptive backup cards work. {% hint style="info" %} **TL;DR:** Stripe can store several payment methods per customer but only charges the default one for subscriptions; it does not fall back to a second card when the first fails. Collecting a backup payment method and charging it automatically when the primary fails recovers roughly 10 to 15 percent of failures that would otherwise need the customer to act. FlyCode's adaptive backup cards do this inside the recovery flow, choosing the next best valid method on file and syncing the result back to Stripe. {% endhint %} *By the FlyCode team. Last reviewed September 2026.* {% hint style="success" %} **Key takeaways** * A backup payment method turns a hard decline (closed account, replaced credentials) into a silent recovery with no email, no login and no customer effort. * Stripe stores multiple payment methods on a Customer but subscription invoices charge only `default_payment_method`; switching to another card is your job, or FlyCode's. * Collect the backup at the moments of highest intent: checkout (optional second card), after a successful recovery, and in the card-update page your dunning emails link to. * Consent language should say plainly that the additional method will be charged if the primary fails; keep the order of methods visible and editable in your customer portal. {% endhint %} ## Why a second card matters Most failed-payment recovery is about soft declines, which retries fix. Hard declines are different: the card is closed, replaced, reported lost or stolen, or the account no longer exists. Retrying cannot help, so the usual answer is a dunning email asking for a new card, which recovers 40 to 60 percent at best because it depends on the customer reading, clicking and typing. If a second valid payment method is already on file, none of that is needed. The charge is moved to the backup, the invoice is paid, and the customer sees only a normal receipt. ## What Stripe does and does not do | Capability | Stripe today | What you (or FlyCode) add | | --------------------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------- | | Store more than one payment method per Customer | Yes (`PaymentMethod` objects attached to the Customer) | Nothing | | Charge a subscription invoice | Uses the subscription's `default_payment_method`, then the Customer's default | Nothing | | Fall back to another stored method when the default fails | No | Detect the failure, pick a backup, pay the open invoice with it | | Update credentials for replaced or reissued cards | Yes, via Card Account Updater and network tokens | Nothing, but confirm they are enabled | | Collect a second card at checkout | Not by default in Checkout; possible via Elements or a post-purchase step | Your checkout or portal design | ## How to collect backup payment methods 1. **At checkout, optionally.** Add an optional "backup card" step after the primary method is saved. Keep it optional; a required second card lowers conversion. 2. **In the customer portal.** Let customers add and order payment methods. Stripe's hosted customer portal allows adding methods; make the backup role explicit in your own UI if you build one. 3. **After a recovery.** When a dunning email leads to a new card, keep the old method attached if it is still valid, and ask whether the new one should be primary. 4. **For high-value accounts.** For B2B plans, invoice-based fallbacks (bank debit, ACH) work as a backup to a corporate card that hits limits. ## Consent language Card network rules for stored credentials require disclosure of how a stored method will be used. When collecting a backup method, state at the point of collection that it will be charged if the primary payment method fails, that the customer can change or remove it at any time, and where to do so. Example wording: "If your primary payment method fails, we will charge this backup method for the same amount. You can change or remove it in your account settings." Keep the wording next to the form field, not only in the terms. ## How FlyCode's adaptive backup cards work 1. A subscription invoice fails on the primary method and the decline is classified. For hard declines the backup path is taken immediately; for soft declines it is taken once the model judges further retries on the primary unlikely to succeed within the recovery window. 2. FlyCode selects the next best valid payment method attached to the Customer, taking into account card type, issuer behaviour and past success. 3. The open invoice is paid with the backup method through Stripe's API, so the invoice, subscription status and receipt stay in sync and the customer sees only a normal payment. 4. Optionally, the backup becomes the new default so the next renewal does not fail the same way. 5. The event appears in the FlyCode dashboard as a backup-card recovery, separate from retry and outreach recoveries. The feature is switched on per account during onboarding; no code is required beyond the standard [Stripe app install](/docs/integrations/stripe-integration-guide-for-flycode.md). ## FAQ ### Does Stripe automatically charge a backup card when a subscription payment fails? No. Stripe retries the same default payment method. Falling back to another stored method has to be done by you or by a recovery tool such as FlyCode. ### Is charging a backup method allowed under card network rules? Yes, provided the customer agreed to it when the method was stored and can manage it. Disclose the fallback use at collection time and keep it editable. ### Does this replace Card Account Updater? No. CAU and network tokens fix replaced or reissued credentials on the primary card without any customer involvement and should stay enabled. Backup methods cover the cases CAU cannot: closed accounts, cards without an update available, and persistent declines. ### How much does a backup payment method recover? Across FlyCode accounts, backup card charging recovers roughly 10 to 15 percent of failures that would otherwise require the customer to act. ## Related * [How FlyCode works](/docs/guides/how-flycode-works-architecture-of-the-recovery-engine.md) * [Subscription payment decline codes guide for Stripe](/docs/subscription-payment-decline-codes-guide-for-stripe.md) * [Failed payment recovery glossary](/docs/read-more/failed-payment-recovery-glossary.md) * [Backup payment methods](https://help.flycode.com/backup-payment-methods) in the Help Center --- # 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://docs.flycode.com/docs/guides/backup-payment-methods-on-stripe-for-subscription-recovery.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.