Stripe Checkout Can Now Refuse Prepaid Cards Outright. The Case for It Isn't Fraud.

Stripe Checkout has let you block specific card brands for a while — no Amex, no Discover, whatever your processing agreement or fraud model calls for. On August 26, 2026, that same restriction object grew a second lever. You can now block a card by funding type instead of brand: refuse credit, debit, or prepaid outright, before the customer ever gets to enter a card number that's going to work. Most of the discussion around this kind of control jumps straight to fraud. That's the wrong frame for this specific field, and the right frame is one most billing teams have never priced out.

What actually shipped on August 26

The change landed in the same release that gave the Billing Portal its custom cancellation reasons, which we covered when it shipped. Buried further down the same changelog: funding_types_blocked on Checkout.Session.payment_method_options.card.restrictions and the matching Payment Link field. It's a list parameter — pass any combination of credit, debit, and prepaid, and a customer whose card matches gets stopped at the card-entry step with an error, the same way brand_blocked already stops a customer from paying with a blocked network.

Nothing about the mechanism is exotic — it's the same restriction object gaining a second axis. What's worth sitting with is who ships this kind of field and why. Brand blocking exists mostly for cost and contractual reasons — some merchants don't want to eat Amex's higher discount rate, or a card network agreement excludes certain brands. Funding-type blocking is aimed at exactly the same category of decision, just applied to a dimension most merchants have never had a one-line way to act on before.

Why this isn't the fraud tool it looks like

Our guide to free trial abuse covers Stripe Radar's dedicated trial-abuse control in detail, and it's worth being precise about how differently that control treats prepaid cards. Radar's model uses prepaid and virtual card detection as one signal among several — card BIN, device fingerprint, IP-to-card-country mismatch — and it deliberately flags rather than hard-blocks on that signal alone, specifically because plenty of real customers pay with prepaid cards and a blanket block trades a fraud problem for a lost-revenue problem.

funding_types_blocked makes no such distinction. It doesn't score risk, it doesn't look at device or IP, and it doesn't care whether the person holding the card is a fraud ring or someone's grandmother who only owns a reloadable Visa. It's a static rule evaluated once, at Checkout, for every customer. That's a feature if you've already decided the tradeoff is worth it for your business, and a serious footgun if you deploy it thinking it's a smarter fraud filter than the one you already have. It isn't a fraud filter at all — it's closer to the accept/decline logic you'd write into a merchant agreement.

The renewal-risk case

The mechanical reason prepaid cards fail more often at renewal isn't complicated. A credit card authorizes against a revolving line; a checking-account debit card authorizes against a balance that gets replenished by a paycheck; a prepaid card authorizes against whatever's left of a fixed amount that was loaded once and, per Recurly's own documentation on recurring-billing failures, is uncommonly reloaded on any predictable schedule. There's no payday for a prepaid card to wait for. Once the loaded balance is spent down — often on the very purchase that got the card in the door — every subsequent charge attempt has nothing left to draw against. Some issuers compound this by rejecting any authorization flagged with a recurring-transaction indicator outright, regardless of balance, which is a failure mode a retry schedule can't fix at any interval.

We've written before about how debit cards decline at close to double the rate of credit on the same subscription base, citing Recurly's benchmark data. Prepaid sits inside that same funding-type story as the sharper edge case: not a card that occasionally runs low before payday, but a card with no replenishment mechanism at all. It's exactly the profile that our decline code retry limits guide flags as the worst use of a limited reattempt budget — Visa caps you at 15 reattempts per card in any 30-day window, and spending several of them retrying a balance that was never going to refill is a worse use of that budget than almost any other decline category.

The cost most teams never model

Decline rate is the half of this story that gets discussed. The half that doesn't is what a prepaid card costs you on the transactions that do clear. Regulation II — the Durbin Amendment's implementing rule — caps debit interchange at roughly $0.21 plus 0.05% of the transaction, plus a small fraud-prevention adjustment, but only for card issuers with more than $10 billion in total assets. Smaller issuers are exempt entirely, and their debit interchange is set by Visa and Mastercard's published network schedules instead — the same schedules that set credit card interchange, which typically run well above the capped rate.

Prepaid card programs are frequently structured around exactly this exemption. A large share of general-purpose reloadable prepaid cards are issued through small, out-of-network partner banks rather than a top-20 issuer, which is a deliberate program design choice as much as a historical accident — it keeps the card's interchange economics closer to credit than to regulated debit.

Put the two halves together and prepaid is an unusual combination: the funding type most likely to fail on a renewal charge, and — because it's so often issued outside the interchange cap — one of the more expensive funding types on the charges that succeed. A subscription business accepting prepaid isn't just tolerating more involuntary churn per our involuntary churn guide; it's frequently paying credit-level processing costs for a card with debit-level (or worse) reliability.

What the restriction covers, and where it stops

The scope of funding_types_blocked is narrower than it might first appear, and the gap matters more for a subscription business than a one-time purchase.

That last row is the one worth planning around. Turning the restriction on doesn't do anything about the prepaid cards already sitting on active subscriptions — it only changes what's allowed to enter going forward, and only through Checkout or a Payment Link specifically. A subscriber who signed up two years ago on a prepaid card keeps that card until it fails or they change it themselves, and if they change it through the Billing Portal rather than a fresh Checkout Session, they can swap in another prepaid card without the new restriction ever seeing the transaction.

Deciding whether to turn it on

This is a underwriting decision, not a fraud setting, and it's worth treating it with the same rigor you'd apply to dropping a card brand. A few questions worth answering with your own data before flipping it on:

• What share of your active subscriber base is on prepaid today? Pull it from payment_method_details.card.funding across your subscriptions before assuming this is worth building. If it's a rounding error, the interchange savings won't move your P&L and the lost signups from blocking it might cost more than it saves.
• What's your involuntary churn rate specifically on prepaid-funded subscriptions? If you're not already segmenting decline data by funding type — the first recommendation in our debit card guide — you don't have this number yet, and it's worth pulling before this one.
• Is prepaid disproportionately common in a market you serve deliberately? Prepaid usage skews higher among unbanked and underbanked consumers, and in some international markets it's close to the default. Blocking it outright in those markets isn't a cost optimization — it's turning away a segment of customers who have no other way to pay you.

None of this changes what happens when a subscriber with a perfectly good card decides they want to leave anyway — that's a product and pricing conversation, not a payments one, and it's the one our cancellation flow is built to handle with the right offer instead of a blanket discount. But for the narrower question of which cards you let in the door in the first place, Stripe just handed every merchant a one-field answer to a decision that used to require either accepting the risk blindly or building a custom BIN-lookup check to make it yourself. Whether that answer is worth using depends entirely on numbers most teams have never pulled — and now there's no excuse not to, before deciding what to block.

Frequently asked questions

Stop losing subscribers today

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