Stripe Raised the Subscription Item Cap From 20 to 100. The Workaround It Replaces Has Its Own Cancel-Button Problem.

On August 26, 2026, Stripe raised the item cap on flexible billing mode subscriptions from 20 to 100. It's a one-line changelog entry, filed as non-breaking, sitting next to five other Billing updates from the same release. It's also the kind of change that only registers as a big deal if you've already hit the old ceiling — and a lot of hybrid and usage-heavy SaaS products have.

A subscription item is one line — one price, one quantity — on a Stripe subscription. A simple flat-fee plan uses one. A hybrid product with a base fee, a per-seat add-on, and a couple of metered usage lines might use four or five. Once a product starts billing separately for individual AI models, individual tools an agent can call, or individual feature modules, the item count climbs fast, and 20 stops being a generous ceiling and starts being a wall a growing number of teams were quietly building around.

Why 20 items ran out for real products, not edge cases

The item limit isn't a Stripe quirk that only shows up in stress tests. It's a real constraint that hybrid and usage-based pricing runs into on purpose, because the whole appeal of metering is billing for what actually gets consumed at a granularity customers can audit. A monthly base fee is one item. A per-seat charge is a second. From there, every distinct thing you meter separately — input tokens versus output tokens, three tiers of API call, storage plus bandwidth, five different agent tools each billed at a different rate — is its own subscription item, because Stripe has no native concept of "usage line with sub-categories" inside a single item. Model that kind of pricing honestly and you can burn through 15-20 items before you've covered every product surface, let alone left room for a coupon-driven discount item or a one-off credit.

Classic billing mode never moved on this — it's been capped at 20 items since before flexible mode existed, and still is. Flexible mode had the same 20-item ceiling until August 26. The fix wasn't a redesign of how subscription items work; Stripe just widened the door on the newer mode.

What teams actually did instead of hitting the wall

Faced with a pricing model that needed more lines than one subscription could hold, the practical answer for most teams wasn't to simplify the pricing. It was to give the customer a second Stripe subscription object — same customer ID, a different subscription ID, tied together by whatever metadata convention the engineering team invented that week. We've written before about the version of this problem that shows up with mixed billing intervals, where an annual fee and a monthly usage line used to force two subscriptions because Stripe wouldn't let one subscription hold two intervals. The item-cap version of the same instinct is older and more common: it's not about intervals at all, it's simply running out of room.

Two Stripe subscriptions for one customer is a workable pattern for billing. It's a much worse pattern for cancellation, and this is where the item-limit story turns into a churn story rather than a purely technical one.

Where the multi-subscription workaround breaks the cancel button

Stripe subscriptions are independent objects. There is no customer-level cancel — cancelling sub_A does nothing to sub_B, even though both belong to the same cus_ ID and, from the customer's point of view, represent one relationship with your product. If your cancellation flow, your Stripe customer portal configuration, or a support agent's runbook was built assuming "a customer has a subscription" rather than "a customer might have several," it will cancel exactly the one it was pointed at and leave the rest running.

That gap shows up in three specific, avoidable ways:

• The cancel-my-account flow only knows about the primary subscription. A customer clicks cancel, gets a confirmation email, and closes the tab. The secondary subscription — the one holding the overflow usage items — keeps billing on its own schedule with no page that ever surfaces it.
• The customer portal session is scoped to one subscription ID. Stripe's hosted Billing Portal shows and manages what you configure it to show. Point it at a single subscription and the customer never even sees that a second one exists, let alone gets a control to cancel it.
• Support tooling searches by subscription ID, not customer ID. An agent pulls up "the subscription," processes the cancellation request against it, and closes the ticket — with no prompt telling them there's a second object attached to the same customer.

The customer's experience in all three cases is identical: they believe they cancelled, the charge shows up on their statement anyway, and the next thing you hear from them is a dispute rather than a support ticket. That's a strictly worse outcome than a normal failed cancellation, because a chargeback carries a fee and a mark against your dispute rate on top of the lost revenue, and it lands on a customer who was actively trying to do the right thing before your billing architecture got in the way.

It also corrupts your churn reporting in a quieter way. If your MRR churn calculation walks subscription-cancelled events, a customer who cancelled their primary subscription but left a secondary one running registers as a full churn event on one revenue line and zero churn on the other — neither number describes what the customer actually intended, which was to leave.

What else changes if you move to flexible mode

The higher item cap is one line in a longer list of behavior differences between classic and flexible billing mode. If you're evaluating the move — and most new Stripe integrations are already defaulted into flexible mode as of API version 2025-09-30.clover — these are the ones that actually affect a live product, not just the item count.

The proration difference deserves its own callout for any team that already runs proration-sensitive cancellation logic: flexible mode can generate multiple credit prorations for a single cancellation if the credited time period was originally billed across more than one debit, where classic mode would have produced one clean credit line. If your support team or your cancellation confirmation copy assumes a single proration amount, test that assumption against flexible mode specifically before you migrate, not after a customer flags a refund total that doesn't match what they expected.

The 100-item cap doesn't undo the split you already made

Here's the part that's easy to miss: raising the cap to 100 doesn't automatically merge subscriptions you already split. Stripe lets you migrate an individual subscription from classic to flexible mode, but there's no operation that takes two existing subscription objects for the same customer and folds them into one. If you're carrying legacy customers on the two-subscription pattern, consolidating them back down to a single object means building an actual migration: create a new flexible-mode subscription with every item combined, cut the customer's billing over to it on a clean cycle boundary, and cancel the old objects once the new one is confirmed active — not flipping a billing-mode flag and walking away.

That migration is worth planning carefully, not skipping. A rushed cutover creates its own short-lived version of the exact problem you're trying to fix — a window where the old subscriptions and the new one are both technically live, and a customer who cancels during that window might hit the same "which one did I actually cancel" confusion this whole workaround was already causing.

What to actually check this week

• Query for customers with more than one active subscription. This is the list of accounts where the cancel-button gap above can happen right now, whether or not you plan to consolidate them.
• Confirm your cancellation flow and Billing Portal configuration act on every subscription tied to a customer, not just one ID. If they don't, that's the fix to ship before anything else here, independent of whether you ever touch the item cap.
• If you're building new hybrid or metered pricing, default to flexible mode and one subscription per customer from day one. A 100-item ceiling gives most hybrid products real headroom; there's rarely a reason to pre-emptively split a new integration the way legacy ones had to.
• Group metered dimensions before you multiply items. Not every distinct thing you track needs its own subscription item — a single metered price with reported usage broken out by an internal category can often replace three or four separate items, and it keeps you further from whatever cap you're on.

The item limit itself was never the interesting problem — it's a number in a docs page, and Stripe just made it five times bigger. What's worth an actual audit is whatever workaround your team built while that number was smaller, because those workarounds tend to outlive the constraint that created them. If your product has customers spread across more than one Stripe subscription for any reason, that's exactly the kind of billing state CancelFlow needs visibility into before a cancel page can make the right call — a subscriber trying to leave shouldn't have to know your internal object model to actually succeed at leaving. If you want to see how much of your reported churn might already be undercounting these partial cancellations, our churn calculator is a fast way to sanity-check a blended number against what your subscription-level data actually shows.

Frequently asked questions

Stop losing subscribers today

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