Changing a Subscription Mid-Period: What Should the Customer See Before Confirming?

For a subscription plan change, show more than the new monthly price. The customer needs to know when the new plan begins, what happens to the unused part of the old period, what is payable now and what will appear later. Agree these outcomes before commissioning an upgrade screen.

This guide concerns a change to a recurring plan, not ordinary catalogue discounts, invoice corrections or temporarily stopping collection. Stripe's proration documentation provides a product example. It does not decide your contract terms, tax obligations or customers' statutory rights.

Separate the new plan from the transition charge

A hypothetical customer moving to a larger plan during an existing period is making two decisions: choosing the ongoing service and accepting how the transition is billed. A screen that shows only the new recurring price hides the second decision.

Write down the effective time, the new recurring amount and frequency, the current period's adjustment and the next expected billing event. If your first version permits changes only at renewal, say so. Do not display an immediate upgrade while silently scheduling it for later.

Also define access timing. Will new features start after the change is confirmed, after payment succeeds, or at renewal? That is a requirement for your app and integration to implement. A calculation preview does not itself grant access.

Preview the real billing change, not a homemade daily estimate

Stripe's proration guide explains that its default calculation is precise to the second. A portal that independently estimates a change by counting calendar days can therefore disagree with the provider. Discounts, billing settings and other details require the integration's actual calculation rather than a universal “divide by days in the month” formula.

The same guide provides an invoice-preview operation that does not modify the subscription. Use an appropriate provider-backed preview to explain the proposed outcome before confirmation. Present the adjustment separately from ordinary renewal charges so customers can tell which lines result from changing plans.

A preview is not a completed change or a paid invoice. Agree how long your app treats it as usable and when it refreshes. If the customer returns after another plan change or after the billing period ends, do not apply a stale proposal without showing the current result again. These are acceptance requirements, not automatic guarantees of the preview API.

A credit is not necessarily money sent back

Stripe explicitly states that negative prorations are not automatically refunded and positive prorations are not immediately invoiced, although both actions can be performed manually. Therefore an adjustment amount alone cannot support the messages “refund sent” or “charged now.”

Ask the developer to name the actual outcome: an adjustment held for a later invoice, an invoice created now, a confirmed payment, or a separate refund process. Select the supported behavior with the person responsible for billing, then make the confirmation text match it. Do not use “you receive” for an account credit if the customer could reasonably understand it as a bank refund.

Stop and review when the current invoice is unpaid

Stripe warns that a change can produce credit for unused time on a higher-priced plan even when the customer has not paid for that time. Treat that as a specific review case, not a reason to assume all calculated credits reflect received money.

Agree whether self-service changes are blocked, referred to staff or processed through an explicitly approved unpaid-invoice policy. Have billing staff decide the handling of the existing invoice and any replacement charge. A quick workaround can create double-payment risk if the old invoice remains collectible; do not have a portal invent accounting corrections to make a preview look tidy.

Demonstrate both directions of change

Before acceptance, test an upgrade and a downgrade during a period, a renewal-boundary change, an unpaid current invoice and a preview reopened after another change. Inspect the resulting subscription, access permissions, invoice lines and actual payment state. The customer's confirmation should agree with all of them.

If the service is metered, do not automatically reuse this model: Stripe's cited guide says usage-based billing is not subject to this proration treatment. Specify that billing model separately.

Bring the actual plan-change policy to your web-app project discussion. A good change screen makes the transition understandable, not merely the next plan attractive.