Stripe proration_behavior explained: create_prorations vs none vs always_invoice

A worked example

A customer pays $20/month and renews on the 1st. On the 16th, halfway through the period, you move them to a $30/month price. Here's what each setting produces (rounded, ignoring tax):

With none, the customer already paid $20 for this month, keeps it, and pays $30 from next month. That's how most people expect a price increase to work, and it's the easiest one to explain in a notice email.

Why the default surprises people

Stripe defaults to create_prorations because the most common subscription change is a customer upgrading their own plan, and there prorating is fair. A company-wide price increase is a different kind of change: you're changing terms, not the customer's usage. Leave the default on in a bulk migration and every customer gets an unexplained partial line item on their next invoice. That tends to bring support tickets and, sometimes, disputes.

The Dashboard applies the same default. If you change prices by hand in the Update subscription screen, check the proration option on every single one.

The interval exception

proration_behavior doesn't cover everything. If the new price has a different billing interval than the old one (monthly to annual, or annual to monthly), Stripe resets the billing_cycle_anchor to now and invoices right away, whatever setting you pass. To move people to annual billing, treat it as its own project, separate from a price increase.

How to preview the effect before committing

Stripe can show you the invoice a change would produce before you make it: call the upcoming invoice preview endpoint with the proposed subscription items and proration setting. The Dashboard shows the same preview in the update screen. Run it on a couple of real subscriptions before any bulk change.

Skip the setting entirely

• The Change Subscription Price App always updates with no prorations. Customers pay the new price from their next renewal, never a partial charge.
• It also avoids the other classic mistake: it replaces the price on the existing item instead of adding a second one, and keeps the item's quantity.
• It needs no code and runs from your Stripe Dashboard. It was built by former Stripe Billing product managers and engineers.

Setting it in code

stripe.subscriptions.update('sub_123', {
  items: [{ id: 'si_abc', price: 'price_new' }],
  proration_behavior: 'none',
});

Pass the existing item ID. Without it, Stripe adds the new price as a second line and bills both. For the full bulk loop, see the migration script guide. For the no-code route, the Change Subscription Price App always updates with no prorations, so there's no setting to get wrong.

Frequently asked questions

What is Stripe's default proration_behavior?

create_prorations. If you update a subscription's price and don't pass proration_behavior, Stripe calculates a credit for unused time on the old price and a charge for the remaining time on the new price, and puts both on the next invoice.

How do I change a Stripe price without prorating?

Pass proration_behavior=none on the subscription update. The customer keeps paying the old amount for the current period, and the new amount applies from the next renewal. Finrite's Change Subscription Price App always updates this way.

Does proration_behavior=none change the billing date?

No, as long as the new price has the same billing interval. Switching intervals (for example monthly to yearly) resets the billing cycle anchor and invoices immediately, whatever proration setting you pass.

When should I use always_invoice?

When the customer should pay, or be credited, for the difference right away, as in a self-serve plan upgrade. It's rarely the right choice for a price increase applied to your whole customer base.

Related guides

• How to change the price of existing Stripe subscriptions
• How to bulk update Stripe subscription prices (without billing mistakes)
• Writing a Stripe price migration script: a complete example