Stripe's Oct 28 Release Lets a Checkout Session Change Its Mind About Saving the Card. Credit Top-Up Flows Used to Have to Guess First.

Sell prepaid credits and you run into the same awkward fork every time: do you save the customer's card for next time, or not? Say yes by default and you're storing payment credentials for people who only ever wanted a one-time purchase. Say no by default and your heaviest users — the ones burning through a credit pack fast enough to need another one in two weeks — have to type in a card number every single time they reload. Until October 28, 2026, Stripe made you pick one of those defaults the moment you created the Checkout Session, before the customer had told you which one they wanted.

That's the backdrop this change actually lands on. Usage and credit-based billing stopped being a niche AI-company quirk a while ago — it's now the default assumption for most of the software market, which means the "sell a block of credits, let people top up" checkout flow isn't a corner case anymore either. It's a mainstream piece of billing plumbing that, until this release, had one specific gap in it.

What actually shipped on October 28

Stripe added payment_intent_data as a parameter on the Checkout Session update endpoint. It's scoped narrowly: it only works on sessions created with mode: 'payment' — one-time charges, not subscriptions — and only when the session uses ui_mode: 'elements', Stripe's embedded-components integration rather than the hosted redirect page. Within that scope, you can now set five things after the session already exists and before the customer confirms it: description, metadata, setup_future_usage, statement_descriptor, and statement_descriptor_suffix.

Before this, every one of those five was a creation-time decision. If the right value for any of them depended on something that happened after the session was already live — a customer ticking a box, selecting a quantity, confirming an order detail — your only option was to throw away the session and start a new one. For an embedded Elements flow, that means tearing down and remounting the payment form the customer is actively looking at. It works, but it's the kind of integration tax that quietly pushes teams toward the worse default: just pick one setting for everybody and stop thinking about it.

Where this actually bites: the auto-reload checkbox

The clearest version of the problem is a credit top-up flow with an optional auto-reload toggle — exactly the pattern Anthropic, OpenAI, and Perplexity all ship under different names for their own API billing. A customer buys a block of credits as a one-time purchase, and somewhere in that same flow there's a checkbox: "automatically reload my balance when it runs low." If they check it, you need a stored, chargeable payment method. If they don't, you don't — and you shouldn't store one anyway, because every saved card you're not using is dead weight you have to account for in how you declare card-on-file usage to the networks.

Rows two and three are where most teams actually sat before this release, because they're the two options that don't require storing a card nobody asked you to store. Row two means your most engaged, highest-usage customers — the ones depleting a credit balance fast enough to need a reload within weeks — pay the single biggest friction tax in your entire product, over and over, specifically because they're your best customers. Row three avoids that, but trades it for a worse failure: remounting an Elements form the customer is mid-way through filling out, which risks losing whatever they already typed and resetting their place in the flow. Row four is the only one that gets the right outcome for both buyer types without picking a lesser evil.

Why this is a one-time-payment problem, not a subscription problem

It's worth being precise about why this is scoped to mode: 'payment' at all. A subscription created through Stripe Billing already has a payment method attached to it by definition — that's what makes it a subscription instead of a series of invoices nobody's committed to paying. The ambiguity only exists for one-time charges that might or might not turn into something recurring later: a credit pack that might get auto-reloaded, a setup fee that might get followed by an annual renewal charged to the same card, a usage top-up that's sometimes a one-off and sometimes the first of many.

That's a bigger surface than it sounds. We've written before about how fast credit-based pricing has grown as a billing shape, and about how usage-based billing hides its own churn signals compared to flat-rate subscriptions. Both of those pieces are about what happens after a customer already has a billing relationship with you. This one is earlier than that — it's about the moment the relationship is still being decided, one-time purchase or recurring commitment, and Stripe just removed the requirement to guess which one it'll be before the customer tells you.

Hybrid pricing — a base subscription plus usage or credit components bolted on — is the fastest-growing shape in that survey, and it's exactly the model that produces this fork most often. A hybrid-priced product routinely needs a one-time top-up purchase to decide, mid-flow, whether it's also setting up a recurring relationship. Pure seat-based and pure flat-fee pricing, both losing share in the same data, rarely hit this problem at all, because the billing relationship is settled the moment the subscription starts.

What skipping the declaration costs you if you don't fix it

None of this is catastrophic on its own — a customer who re-enters a card for the third reload this month is annoyed, not lost. But it compounds with everything else already pulling at a checkout flow. We've covered how checkout abandonment happens to people who already decided to pay and still don't finish; a form that resets itself mid-fill because your backend had to recreate the session is a self-inflicted version of exactly that problem, on your most engaged users specifically, which is the worst segment to be losing friction battles with.

There's a second, quieter cost on the other side of that fork: storing a card nobody asked you to store. Every saved payment method you're holding has to be declared to the card networks as recurring, unscheduled, or installment usage — the mechanics we've covered in credential-on-file usage types — and a card stored "just in case" for a buyer who only ever wanted one purchase is a card you now have to account for in that declaration, with no actual future charge to justify it. Deferring the decision until the customer actually makes it is the cleanest way to avoid accumulating payment methods you have no real use for.

How to actually use it

1. Create the Checkout Session without setup_future_usage set, as soon as you'd normally create it, using mode: 'payment' and ui_mode: 'elements'.
2. Render your auto-reload (or equivalent) checkbox inside the same flow, before the payment form is confirmed.
3. On check, call the Checkout Session update endpoint with payment_intent_data.setup_future_usage set to off_session or on_session, wrapped in runServerUpdate on the client so the payment method list and terms copy stay synchronized with the change.
4. Leave it unchecked and the session stays exactly as created — no card gets stored, no extra declaration to make later.
5. Use the same mechanism for order-specific metadata or description if those values also depend on a choice made after the session exists, rather than reaching for a second session for that alone.

It's a small parameter addition, and Stripe's own changelog entry undersells how directly it maps onto a fork every credit-based or hybrid-pricing product eventually runs into. If you're running that kind of checkout today and still choosing between storing every card and losing your heaviest users to re-entry friction, this closes the gap between those two bad options without you having to build a workaround yourself.

None of this touches what happens once a customer actually wants to leave — that's what a cancellation flow is for, and it's the problem CancelFlow is built around. What it does fix is a step earlier: the moment a willing buyer is still deciding how they want to pay you, where the wrong default costs you either unnecessary stored cards or unnecessary friction on your best customers. If you're not sure which of those two is currently costing you more, run the numbers through our churn calculator before you decide whether this is worth the integration time.

Frequently asked questions

Stop losing subscribers today

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