How to retry failed charges using backup cards on Stripe

3 min read

When a subscription has a failed charge, Stripe retries automatically with its Smart Retries system. It’s useful, reduces some involuntary churn, but it has a big limitation few businesses notice: it only retries with the card that failed. If that card has structural issues (canceled, insufficient funds, expired), those retries will never work.

And yet many of your customers have other cards on file in Stripe. A secondary payment method, the one they used in a past purchase, the one left as backup. That data is there, in Stripe, unused.

The classic retry problem

Stripe retries with the original card because it’s the conservative behavior: it won’t assume it can swap payment methods for you. If the card is expired, obsolete, or over its limit, retries fail day after day. Eventually the system gives up, the subscription cancels, and you’ve lost the customer.

The customer usually doesn’t even notice. They receive Stripe’s emails (sometimes), but if they’re traveling, or the email filters as spam, or they just ignore it, the subscription disappears with no conscious action.

For many subscription businesses, involuntary churn (cancellations from failed payments, not customer decision) is 20% to 40% of total churn. That’s money evaporating for purely mechanical reasons.

What changes with backup cards

If the first retry fails, instead of trying the same card again, you try the next payment method the customer has saved in Stripe. Then the next. Until reasonable options are exhausted.

Often customers have saved another card in Stripe at some point (from another purchase, another subscription, a service they tried). Trying it costs one API call and can recover the charge with zero customer action.

And when no card works, a direct payment link sent to the customer is the next step: a link to a page where they can update their payment method and settle the pending invoice in one go. No portal diving, no friction.

The pain of building it yourself

You could do it manually:

  • Query the customer’s saved cards on Stripe.
  • For each, try the charge.
  • Detect the failure reason on each attempt.
  • Skip to the next if it’s a failure that doesn’t warrant persistence.
  • Stop as soon as one works.
  • And do all this without exceeding Stripe’s rate limits or hammering your own infrastructure.

Within reach of a senior developer. But then you monitor it, maintain it, adjust when Stripe changes something, handle edge cases (shared subscriptions, mid-cycle plan changes, active promotions). It’s infrastructure you’ll maintain for years.

Combined effect

Backup cards + direct payment link typically recovers an extra 15% to 30% on top of what Stripe recovers by default. For a business with 500 subscribers and $30/month average, that’s thousands of dollars a year that stop leaking.

No magic. Just using information you already had (saved cards) with smarter retry logic.

In Stripe Control backup-card retries and direct payment link sends are included and run automatically. When a charge fails and the first retry doesn’t resolve, the system tries the customer’s additional saved cards, and if none work, sends a link to the customer to update the method. The dashboard shows how much you’ve recovered each month by mechanism.

Keep reading