Changing a plan while its invoice is unpaid: avoid crediting time never paid for

The unpaid invoice changes the decision

Stripe calculates prorations using the subscription state at the moment of an update and assumes earlier invoices will eventually be paid. A customer with an unpaid invoice can therefore receive a credit for unused time on a more expensive plan even though that time was never paid for.[1] The operational question is not simply whether the new plan is cheaper. It is whether the credit has a corresponding paid obligation and which invoice will collect the remaining amount. Editorial recommendation: treat a plan-change request and its current invoice as one review case, while retaining their separate identifiers. This guide addresses that review, not general refund policy, tax treatment, or the customer's legal right to change plans. The documented behavior belongs to Stripe; it is not a claim that PayIn offers subscription billing.

Read the invoice before approving the preview

Stripe allows a proration preview before changes are applied. It also says negative prorations are not automatically refunded and positive prorations are not immediately billed, although either can be done manually.[1] Editorial recommendation: before sharing a price-change estimate, record the subscription ID, current period, latest invoice ID and status, proposed plan, and intended change time. Explain to the customer whether the displayed amount is an estimate, a credit on an invoice, or an amount that will actually be collected. Do not describe a negative line as money already returned to a bank card. A proposed review should also identify whether another operator is trying to collect the original invoice; otherwise two individually reasonable actions can conflict. These review fields are an editorial checklist, not required Stripe API fields.

Choose what happens to the billing period

To avoid a credit for unpaid time, Stripe documents setting proration_behavior to none when updating a subscription whose latest invoice is unpaid.[1] It then offers two approaches: keep the original billing period and manually create a one-off invoice for new charges, or charge immediately for the new plan and set billing_cycle_anchor to now to reset the period.[1] These are different commercial outcomes, not interchangeable parameter combinations. Editorial recommendation: obtain agreement on the new service period before execution. Keeping the existing anniversary may fit a customer who expects one stable renewal date; resetting it requires explaining the new date and charge. Do not copy the reset option merely to make an invoice total look simpler. Determine the approved amount through a current preview and your pricing policy rather than arithmetic copied from an unrelated example.

Close the old collection path deliberately

Stripe warns that either documented approach can cause double payment if the customer eventually pays the old invoice; its stated prevention is to void the unpaid invoice.[1] Editorial recommendation: inspect that invoice again immediately before applying the approved change. If payment completed while the case was being reviewed, stop and recalculate rather than follow an instruction written for an unpaid invoice. Have the billing owner determine whether voiding is appropriate under the business's invoice and accounting procedures. Keep the original invoice reference and reason for its disposition in the case record. An API setting that suppresses proration is not, by itself, a promise that a previously sent invoice can no longer be paid. Conversely, do not void every overdue invoice as a generic collection shortcut: this source describes a specific plan-change risk, not a universal debt-waiver policy.

Do not infer the credit from list prices alone

Stripe documents two credit-proration calculation approaches, depending on whether billing_mode is classic or flexible.[1] Editorial recommendation: retain the billing mode alongside the preview and avoid promising that every downgrade produces the same result for the same advertised plans. As an illustrative review scenario, imagine a customer requesting a downgrade halfway through a period whose invoice remains unpaid. No money amount is asserted here. The operator should identify the unpaid obligation, choose the period strategy, obtain approval for the new amount, and resolve the old invoice's collection path. The key result is a coherent invoice history, not a hand-computed half-month credit. Usage-based billing is outside this guide's advance-billing scope; the Stripe page states that usage-based billing is not subject to proration.[1]

A support handoff that avoids conflicting instructions

Editorial recommendation: hand support a short decision record rather than a screenshot of the new price. It should identify which invoice the customer should pay, which prior invoice must not be collected, the approved renewal date, and who can resolve a payment that arrives during the change. Keep the amount approval separate from the execution confirmation. If the customer has already been sent the old payment link, explain the approved replacement route through the normal support channel. Do not claim that changing a plan alone revoked the old demand for payment. A reviewer who was absent from the original conversation should be able to reconstruct the intended result without guessing whether the customer requested an immediate change or a next-period change.

Acceptance checks before a live rollout

Editorial recommendation: rehearse an unpaid downgrade, an unpaid upgrade, and a case where the old invoice becomes paid during review. For each, inspect the resulting invoice items, period boundaries, remaining open invoices and customer-facing explanation. Include both a preserved anniversary and a deliberately reset anniversary if the business supports both policies. A reviewer should be able to answer what changed, what remains collectible, and why any old invoice was voided. These are proposed tests, not reported payment executions. This article was published and its public source checked on 2026-09-21; the source does not state a publication or update date. It does not establish legal or tax compliance, validate any account's feature eligibility, or guarantee a transaction outcome. Escalate uncertainty about an already-paid invoice instead of forcing it through the unpaid-invoice procedure.

Sources and dates

Verified on 2026-09-21. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.

1. Stripe: Prorations [1] ↗

   Source date: Not stated · Verified: 2026-09-21