Stripe Just Gave Saved Cards Three Labels — Recurring, Unscheduled, Installment. Most Subscriptions Ship With None.

Every Stripe subscription you've ever shipped has been doing something the card networks have required for years without most teams ever setting a field for it: charging a saved card off-session, on a recurring schedule, without telling the network which of three legally distinct scenarios that charge belongs to. On September 30, 2026, Stripe closed that gap by shipping two new parameters — setup_credential_usage and stored_credential_usage — that finally let you declare it directly, instead of leaving Stripe to infer it from off_session and hope the inference matches what Visa and Mastercard actually expect.

Credential-on-file isn't new. Declaring it correctly is

The underlying rule predates this release by years. Visa's Stored Credential Transaction Framework and Mastercard's equivalent have long required merchants who store a cardholder's details for future use to tag each stored-credential transaction with its purpose, so the network can distinguish a subscription renewal from a one-off charge from a financed purchase. Stripe handled a version of this implicitly: set setup_future_usage: off_session on a PaymentIntent, and Stripe would signal the network that a future off-session charge was coming. What it couldn't do was tell the network which kind of off-session charge — because until September 30, there was no field for that distinction at all.

That's the actual gap this release closes, and it's a quieter one than most Stripe changelog entries we cover. Nothing in your integration breaks if you ignore it. The two new parameters are purely additive, so a subscription business that does nothing differently keeps billing exactly as it did in August. What changes is whether the network has the specific context it's designed to use when something goes wrong with that charge later — an authorization decision, a dispute, a compliance audit of your stored-credential program.

Three usage types, one field each

Stripe's documentation lays out the three values both new parameters accept, and the distinction between them is more concrete than "recurring vs. not recurring."

Notice that setup_credential_usage and stored_credential_usage don't have to match. You declare recurring when the customer first saves their card for subscription billing, then declare unscheduled on the specific charge where that same card gets hit for a one-time overage six weeks later. Stripe's own guidance is explicit that a saved credential can legitimately be charged under more than one usage type over its life — which also means you're on the hook to disclose every scenario you intend to use it for at the point the customer consents to saving it, not just the one you had in mind that day.

Why the "unscheduled" slice is where teams actually get exposed

The recurring slice mostly takes care of itself, because Stripe Billing already threads off_session through subscription renewals correctly, and will set recurring for you by default once you adopt the new parameter. The risk sits in that unscheduled bucket — the usage-based overage you bill mid-cycle, the one-time add-on a customer buys from your billing portal, the manual charge a support rep triggers from the dashboard to cover a plan change. Those are all legitimately card-on-file charges, run against a credential the customer already saved. But if your integration treats every saved-card charge as interchangeable with a subscription renewal, you're declaring — or failing to declare — the wrong usage type on exactly the charges most likely to get disputed as unrecognized, because they don't arrive on a schedule the customer is expecting.

This is the same blind spot we flagged in our piece on Stripe's unified payment-method error codes: a failure category that technically always existed, but had no dedicated signal until Stripe decided to name it. The difference here is that an undeclared usage type doesn't throw an error at all. Your charge still succeeds. The gap only shows up later, when a customer disputes that unscheduled top-up as a charge they don't recognize, and the network has less structured evidence tying it back to a declared stored-credential agreement than it would if you'd set the field correctly.

The re-authorization trap credential-on-file shares with card updates

Stripe's documentation on merchant-initiated transactions pairs directly with something we've already covered in our card account updater guide: when a card's brand changes — Visa reissued as Mastercard, for instance, which Stripe's own update pipeline can trigger automatically — you lose the right to charge that card for merchant-initiated transactions until you get a fresh cardholder agreement. A card account updater silently swapping the brand on file doesn't just change a logo in your dashboard. It resets your standing to run recurring MITs against that credential at all, regardless of what usage type you'd previously declared, until the customer re-authorizes. Teams that treat card updates as a pure decline-prevention tool, with no corresponding check for brand changes, can end up technically unauthorized to bill a card that Stripe just helpfully refreshed for them.

What to actually change in your integration

• Set setup_credential_usage on every SetupIntent or PaymentIntent that saves a card, matching the primary reason you're saving it — recurring for subscription signup, unscheduled if you're only saving the card for occasional future charges.
• Set stored_credential_usage per charge, not per customer. A subscription renewal and a mid-cycle overage against the same saved card should carry different values, even though they're hitting the same PaymentMethod ID.
• Disclose every usage type at the point of consent. If a card saved for subscription billing might also get charged for ad hoc portal purchases, your terms and your "save my card" checkbox need to say so before the first charge, not after a dispute asks why they didn't know.
• Listen for payment_method.automatically_updated and check the brand, not just the expiry date. A brand change means your MIT authority on that card is gone until the customer re-consents — pair this with the retry-eligibility logic from our decline code guide, since re-authorization isn't a retryable decline, it's a hard stop.

None of this changes how Stripe dunning handles a charge that's already failed — the retry windows, the network reattempt caps, the recovery emails are all unaffected. What it changes is the evidence you're building before a charge ever has a chance to fail or get disputed in the first place, on exactly the saved-card charges that don't look like a predictable subscription renewal. If you're trying to size how much of your current involuntary churn traces back to saved-card charges that were never cleanly declared to begin with, our churn calculator will turn a specific decline or dispute segment into an MRR number worth fixing first. And for the subscribers whose saved card was never the problem — the ones who looked at a surprise unscheduled charge and decided to just cancel rather than ask what it was — that's exactly the moment a CancelFlow cancellation flow is built to catch the real reason before the account disappears.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.