Stripe Mixed Interval Subscriptions: What One Subscription With Two Billing Clocks Means for Churn

Until recently, if you wanted to charge a customer an annual platform fee plus a monthly usage line, Stripe made you choose: put both prices on one subscription and force them onto the same interval, or run two separate subscriptions per customer and stitch the billing relationship together yourself. Most teams picked the second option and quietly accepted the mess — two subscription IDs to track per account, two cancellation events to reconcile, two places a webhook can arrive out of order. Stripe's mixed interval subscriptions remove that constraint. One subscription can now hold items on genuinely different intervals. It's a clean fix for a real modeling problem, and it opens a failure mode that didn't exist when a subscription meant one price, one clock, one invoice.

That's the context this feature landed into. Hybrid pricing — a predictable base fee that covers platform access, plus a variable layer tied to actual consumption — went from a minority pattern to the single most common pricing structure among software companies in about a year, according to Poyar's survey of more than 230 companies. Billing infrastructure that assumed one subscription meant one interval was already the wrong shape for over a third of the market.

What actually changed

A Stripe subscription is a container for one or more items, and each item points at a Price. Historically, every Price on a given subscription had to share the same recurring.interval — all monthly, or all annual, no mixing. If your pricing was "$199/year for the platform, $0.02 per API call billed monthly," Stripe had no native object to represent that as one thing. You either forced the usage line onto an annual cadence (batching a year of usage into one invoice, which defeats the point of metering) or ran two subscriptions and glued them together with your own account-linking logic.

Mixed interval subscriptions remove the same-interval requirement. You can put an annual Price and a monthly Price as items on one subscription, and Stripe treats it as a single object with a single ID, a single customer relationship, and — this is the part worth sitting with — potentially multiple, independently-timed invoices. The feature requires flexible billing mode, and you need to be on API version 2025-06-30.basil or later to configure it through the Dashboard or the API.

That last row is the tradeoff nobody advertises. The old two-subscription workaround was messy, but it gave you an escape hatch: you could cancel the monthly usage subscription while leaving the annual platform subscription alone, if that's what a customer actually wanted. A mixed interval subscription doesn't offer that through the standard cancel action — cancel the subscription and every item goes with it. If you need to keep one item alive while dropping another, you remove that item from the subscription directly instead of canceling the whole thing, which means your cancellation flow needs to know the difference between "cancel everything" and "drop this one line" before it calls the API.

How Stripe decides whether you get one invoice or several

This is the mechanism that actually matters for churn reporting. Stripe generates a single, combined invoice for a mixed interval subscription when the item-level billing periods happen to align, and separate invoices per item once those periods diverge. For an annual-plus-monthly combination, alignment only lasts for the very first cycle — the moment the subscription starts, both items' periods begin on the same date, so the first invoice covers both. From the second month onward, the monthly item is on its own clock and the annual item won't renew again for another eleven months, so they diverge and generate independent invoices.

In practice, a $199/year-plus-usage subscription produces one combined invoice at signup, then eleven monthly usage-only invoices, then a combined (or separate, depending on exact timing) invoice again around the annual renewal. That's thirteen billing events across the first year instead of the two your accounting mental model might expect from "one annual fee, one usage line." Every one of those thirteen events is also a payment attempt — which means thirteen chances for something to fail, on a subscription your dashboard still shows as a single row.

The part that should worry your dunning setup

Before mixed interval subscriptions, a subscription's payment status was a reasonably reliable proxy for "is this customer current." One invoice, one outcome, one signal. Once a single subscription can be generating an annual invoice and a monthly invoice on independent schedules, that stops being true. The usage invoice can fail — a card that's fine for a $199 annual charge can still decline a $6 metered charge if it happens to hit right after a balance dips, which does happen with debit cards — while the annual item sits paid and current. Or the reverse: the big annual renewal fails a soft decline and enters your normal retry window, while the small monthly usage invoice keeps clearing every month in the background, masking the fact that the subscription's core revenue is actually at risk.

Stripe's documentation doesn't currently spell out how a failed item-level invoice interacts with the subscription's overall status — whether one failed usage invoice alone can push the whole subscription into past_due, or whether that only happens if the larger item fails too. Until that's documented explicitly, don't assume your existing past_due-triggers-cancellation logic behaves the same way on a mixed interval subscription as it does on a single-invoice one. Test the specific failure combination — annual paid, monthly failed, and the reverse — in a sandbox before you let it drive an automated cancellation.

Where this is actually useful

None of the above is a reason to avoid the feature — it's a reason to model it correctly. The businesses this is built for are exactly the ones behind the 37% figure above: SaaS and AI products with a predictable base fee and a metered layer on top, who've been stuck either batching usage into an annual invoice or maintaining two linked subscriptions per account. Mixed interval subscriptions collapse that into one object with one customer relationship, which simplifies everything downstream of billing — your customer portal shows one subscription instead of two, your MRR reporting doesn't need to stitch two rows together, and a single webhook subscription ID maps to the whole relationship.

It also composes with Stripe's other recent billing primitives instead of competing with them. You can prebill the annual platform item on a mixed interval subscription the same way you'd prebill any other item, while the usage line stays billed as consumed. And if the annual renewal invoice itself gets large enough to cause approval friction, nothing stops you from applying payment plans to that specific invoice once it's generated. The three features stack rather than substitute for each other, which is the clearer signal that Stripe is building toward flexible billing mode as the default rather than a special case.

What to check before you turn this on

• Confirm your subscription is on flexible billing mode and your integration is pinned to API version 2025-06-30.basil or later — mixed intervals aren't available on the legacy billing mode at all.
• Decide how partial payment failure maps to subscription status before you go live, and test it directly rather than inferring behavior from the single-invoice model you're used to.
• Rebuild your cancel logic around item removal, not just subscription cancellation, if you ever need to let a customer drop one line without losing the other.
• Expect more webhook volume per subscription — thirteen invoice events a year instead of one or two means more invoice.paid and invoice.payment_failed events to handle for the exact same customer relationship you used to track with a single invoice per cycle.

For a product priced this way, the cancel button was already doing double duty — is this customer leaving the platform, or just trying to zero out a usage line that got away from them one month? A cancellation flow that can't tell those apart, and that only offers a blanket cancel action against a subscription that now silently controls two independent billing clocks, is going to lose people who only meant to fix one part of their bill. That's exactly the kind of nuance CancelFlow is built to sit in front of — reading what a subscriber actually has active before deciding whether the right save offer is a pause, a downgrade to a lower usage tier, or nothing at all. If you're trying to see how much of your reported churn on hybrid-priced accounts is really just usage-line noise versus genuine platform cancellations, our churn calculator is a fast way to separate the two instead of reading one blended number off a subscription status field that no longer means what it used to.

Frequently asked questions

Stop losing subscribers today

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