A&A INSIGHTS
Raising prices for existing customers: three things to decide first
Three rows to fill before the notice: effective date, the mid-period difference, and a failed payment. A&A reads Stripe's billing documentation.
日本語で読む
THE STARTING POINT
Decide three things before you write the notice: when the new price takes effect, which invoice the mid-period difference lands on and when, and what happens to the subscription if the payment at the new price fails. With those settled, the notice only has to report decisions.
Three things to decide before the notice: effective date, the mid-period difference, and a failed payment
A&A perspective
When you raise the monthly price for existing customers, three things have to be decided before you write the notice. First, when the new price takes effect. Second, when the effective date falls inside a billing period, which invoice the resulting difference lands on and when — or whether it appears at all. Third, what happens to the subscription if the payment at the new price fails: does the contract stay at the new price, or fall back to the old one? Once those three are settled, the notice becomes a document that only reports decisions. Send a notice with those three still blank and, however carefully it is worded, the questions start arriving once customers see invoices that differ from one another.
A&A perspective
When founders discuss a price increase, the first thing on the table is usually the wording: how to phrase it so nobody leaves, what percentage is tolerable. But what actually consumes the founder's hours after the notice goes out is rarely an argument about the amount. It is the invoice question — what is this line for? — and the one-by-one handling of customers whose payment did not go through. The first comes from the effective date and the treatment of the difference; the second comes from never having decided what a failed payment means. Neither is a wording problem. Both are questions about which path you execute the change through, and that path already exists on the billing side. What follows reads Stripe's public documentation as the primary source for what that path forces you to decide. Even if you do not use Stripe, the three items you have to settle are the same.
A change that affects billing and a change that does not are different operations
From the sources
Stripe's page on modifying subscriptions splits changes into two kinds. Changing prices, quantities or billing periods, and adding or removing subscription items, are billing-related updates: they "create prorations and can generate invoices". Updating metadata, payment methods or tax settings, and applying or removing discounts, are non-billing updates, which "apply immediately without prorations". The same page advises that for changes which automatically create a new subscription invoice you use pending updates, "so that the updates are only applied if the new invoice is successfully paid".
A&A perspective
That split is the starting point for thinking about a price increase. A price change is always in the first category — the one that shows up on the customer's invoice as money. So the sequence "send the notice, then swap the price in the dashboard" is itself an operation that rewrites the customer's invoice. In A&A's reading it is worth stopping here. If you recast a price increase as an operation that creates new lines on someone's invoice rather than as a negotiation, the question you have to answer shifts from "how much" to "which line appears, when, and for what amount".
| Item to decide | What happens if you notify without deciding it | Form it takes in the notice |
|---|---|---|
| Effective date | "From next month" lands mid-period at a different point for each customer, so invoices differ in shape | The new price applies from your next billing date (stated individually) |
| The mid-period difference | An unexplained credit for unused time and a debit for remaining time appear as two lines no normal month has | There is no additional charge this month; the new price starts with your next invoice |
| A failed payment | The contract says the new price while nothing was collected, and the rollback becomes manual work | Until your payment is confirmed, your current rate stays in place |
| Customers with arrears | A credit for time they have not paid for can enter the difference calculation | We will apply the price change after the outstanding invoice is settled |
| Metered items | Usage in a month where the change expired while held is discarded and can no longer be billed | Usage is settled at the previous rate and the change starts with the next billing period |
| Path per collection method | Pending updates are unavailable for collection other than automatic charging (bank transfer, payment on invoice), leaving ad hoc handling with no procedure | For customers paying by transfer or on invoice, the new price applies from the next invoice issued |
The moment you fix the effective date, you fix the size of the difference
From the sources
Stripe's prorations page says the most complex aspect of changing existing subscriptions is prorations, where the customer is charged a percentage of a subscription's cost to reflect partial use. Its worked example: if a customer upgrades from a 10 USD monthly plan to a 20 USD option halfway through the billing period, the customer is billed an additional 5 USD. The breakdown is a credit of -5 USD for unused time on the original 10 USD plan and a debit of +10 USD for remaining time on the new 20 USD plan, totalling +5 USD. The page also states that by default Stripe calculates prorations down to the second.
A&A perspective
What that example shows is structural: the effective date decides not only when the new price starts but simultaneously how large the difference is. Raise the price inside a billing period and the customer's invoice carries two lines that never appear in a normal month. You may write "from next month" in the notice, but if the customer's billing date is not the first, that "next month" lands inside a billing period. When customers started on different dates, the same wording produces a differently shaped invoice for each of them. In A&A's view the decision here reduces to two options: align the effective date with each customer's next billing date so the difference is zero, or decide to apply it mid-period and tell them in advance that those two lines will appear. Either is defensible. Deciding nothing gives you the second one by default.
You can model the customer's invoice before the notice goes out
From the sources
The same prorations page describes how to check amounts before applying a change. Creating a preview invoice is an API call that does not modify the subscription; it returns the upcoming invoice based only on the parameters you pass. The page says to use this information to confirm the changes with the customer before modifying the subscription. It also records a caveat: "Because Stripe prorates to the second, prorated amounts might change" between the time they are previewed and the time the update is made. To avoid that, it says to pass a proration date when creating the preview and to pass the same date when you update the subscription.
A&A perspective
So there is no need to calculate after announcing. You can read each customer's invoice, confirm the actual difference, and then write the notice. That is the order A&A recommends. With a dozen or so customers, previewing them one at a time is not much work in itself. But one premise should be stated plainly: the preview the source describes is an API call, not something you do by clicking through a dashboard. The failed-payment path below is the same — it needs a parameter passed on the update call. So the order this article recommends comes with developer work; if you are not writing it yourself, budget for that. On top of that there is a trap that follows directly from the per-second behaviour. Put a previewed figure into the notice, then execute the change several days later without passing proration_date, and the amount on the customer's invoice will not match the number you announced. Even a one-yen gap is a reason for someone to write in.
Three options for the difference, and the default does not necessarily invoice right away
From the sources
Proration is controlled by the proration_behavior parameter, which the page says has three possible options: create_prorations, always_invoice and none. The default is create_prorations, which creates proration invoice items when applicable, but those items are only invoiced immediately under certain conditions. Setting always_invoice calculates the proration and then immediately generates an invoice. With none, no prorations are created, and in that case "customers are billed the full amount at the new price when the next invoice is generated". The page raises a further point: if a customer changes their subscription while holding an unpaid invoice for the current period, they might receive a "credit for unused time on the higher-priced plan" even though they have not paid for that time. The page offers proration_behavior=none as a way to avoid that, but adds that either workaround "can lead to double payment if the customer eventually pays the old invoice", so the unpaid invoice has to be voided.
A&A perspective
These three options map directly onto sentences in the notice. Choose none and the notice can say: the new price applies from your next invoice, with no additional charge this month. Choose always_invoice and it has to say: an invoice for the difference is being sent today. Leave create_prorations untouched and the proration items exist while the timing of the charge depends on conditions, which means there is no settled sentence to put in the notice at all. A&A's judgement is that with a dozen customers on identical terms, none is worth making the default: it removes one number you would otherwise have to explain, and the notice fits on one line. Using more of the machinery is not the goal. For customers with unpaid invoices, the simplest answer is an internal rule: settle the arrears first, then apply the price change.
When the payment fails, by default only the price goes up
From the sources
Stripe's pending updates page states the default behaviour plainly: "By default, Stripe applies updates regardless of whether payment on the new invoice succeeds." If payment fails, it says, "rolling back the updates is a manual process" — you need to create a new invoice, prorate items on the invoice, and then initiate payment again.
From the sources
The same page describes the alternative path. With pending updates, "changes normally only apply if payment on the resulting invoice succeeds". When payment fails, the subscription carries a pending_update hash and the change is not applied. If you take no action, "Stripe voids the invoice and discards the update after it expires". The expiry matches the trial end or the earliest item's current period end when either falls within 23 hours of the update request; otherwise "the expiration is 23 hours from the update request". So the grace period is at most 23 hours, and shorter when the period end is near. Expiry is not the only way a held update disappears: a later subscription update that includes billing_cycle_anchor, a nonempty items list, trial_end or trial_from_plan=true removes the existing pending update "even if their values match the pending changes", and reaching a billing threshold or a subscription schedule moving to a new phase also voids the invoice and drops it. One exception is stated too: when a resumption attempt moves a paused subscription to active or past_due, Stripe applies a matching pending update even if the payment does not succeed. The conditions are narrow: pending updates require the subscription's collection method to be charge_automatically and the payment method to be one of a listed set including card and Link. The supported fields are limited too — "Pending updates only support attributes that control proration behavior or generate new invoices". There is a further note for metered items: if the pending update expires before payment, Stripe discards that usage, which prevents any subsequent invoices from billing for it.
A&A perspective
This is the branch A&A considers most often missed in practice. Raising the price and being paid at the new price are two separate events, and by default only the first one happens. A customer whose card has expired, or whose limit is tight, stops at the payment step even though they agreed to the notice. On the default path that leaves a state where the contract says the new price and the cash says nothing was collected, and the rollback is manual work. Choose pending updates and, in the ordinary failed-payment case, the state stays coherent: old price, change held. It is not an absolute guarantee — the source explicitly says a resumption attempt on a paused subscription applies the pending update even without a successful payment. And because the grace period is at most 23 hours, and shorter when the period end is near, this is not a mechanism that waits for people. It presupposes that you will contact the customer to update their payment method inside the window. There is a second practical trap: if it does not work and you simply run the price change again, that update carries items, and per the source the held update is removed. Retrying can destroy the very mechanism you chose. Using this path also means passing payment_behavior=pending_if_incomplete on the update call — not something a dashboard click covers. And since the path is unavailable for collection methods other than automatic charging (bank transfer, payment on invoice), those customers need a separate procedure. For a service with metered items, the fact that a month's usage becomes unbillable when a pending update expires is itself a reason to choose the execution date carefully.
An example of adding a billing model to a business already charging customers
From the sources
According to Stripe's published customer page on Lovable, the company used Stripe Billing at its November 2024 launch to spin up subscription plans "including a free tier for individuals and paid tiers" that offered graduated levels of monthly usage credits and specialised features. In 2025 it launched Lovable Cloud and Lovable AI, and implemented usage-based billing to support them. The page states this enabled the team in just two weeks to "define meters and rate cards" and to "automatically bill customers for actual consumption". It also carries figures: 4.6 million credits being granted every month, and 400 million dollars in ARR in the 14 months since launch. These are statements published by the vendor, not findings of an independent audit.
A&A perspective
Reading this as a success story to copy would be a mistake. The figures the page carries, 400 million dollars in ARR and 4.6 million credits a month, are not usable as a forecast for a one-person or small company. What A&A takes from the page is something else: a company with paying customers already in place went ahead and added a whole billing model on top, and the work is described as work on the billing system. The order is the same for a price increase: settle the model and the execution path first, then tell customers. Be explicit about what does not transfer. The page describes adding usage-based billing for new products, and says nothing about raising prices for existing customers, mid-period prorations, or failed payments. All this section supports is the single point that changing live billing is treated as design work on the billing system. And note that the two weeks the vendor cites is implementation time, not the time needed to explain the change to customers or to reach agreement on the migration. At a small company the latter is usually the longer half.
Three rows to fill internally, three rows to put in the notice
A&A perspective
The table below turns the preceding sections into something you fill in before writing the notice. The left column is the item to decide, the middle is what happens if you send the notice without deciding it, and the right is the form it takes in the notice itself. Only when the right-hand column is filled can you start drafting. Put the other way round: if you cannot write the right-hand column, the problem is not the wording — the decision has not been made.
Hypothetical example
As a hypothetical, take a one-person company raising an AI operations service from 50,000 yen a month to 70,000 yen. It has 12 customers, all paying by card, with billing dates that vary by the month they signed. The three rows it fills in first might read: effective date, each customer's next billing date; treatment of the difference, no prorations, no additional charge this month; failed payment, use pending updates, hold the current price until payment is confirmed, and contact the customer inside the window. With those settled, the body of the notice needs three sentences: from your next billing date (stated individually) the monthly fee becomes 70,000 yen; there is no additional charge this month; until payment is confirmed your current rate stays in place. This is an illustration built on invented settings — not an A&A result and not a customer outcome. The amounts and the customer count are numbers placed there to make the example concrete.
What this article does not decide
A&A perspective
This article does not judge how much you should raise the price to, or whether raising it is warranted. The primary source — Stripe's documentation — says nothing about whether a price is appropriate. Nor does A&A offer a benchmark for fair pricing, or figures for how a price increase affects churn or new business. We have not measured those. Contractual notice obligations, notice periods, and how changes to terms of trade must be handled depend on your contract with the customer and on applicable law. This article stays within the scope of operational design and does not determine what is legally permissible.
A&A perspective
The limits on the specification side are explicit too. Every behaviour quoted here is as the pages read on 4 October 2026. The supported attributes for pending updates, the at-most-23-hour expiry and the proration defaults can all change, so re-read the originals immediately before implementing. If Stripe is not your payment processor, the same path may not exist. If you issue invoices by hand, there is no mechanism that makes a price change conditional on successful payment, and the only way to get the same result is to run it as an internal procedure. And if you have few customers, all on identical terms, skipping prorations and letting the new price start at the next invoice — with no difference to explain — may well be less total effort. Using more machinery is not the goal; reducing the one-by-one handling after the notice is.
The hard part of a price increase is choosing the number, but the work that follows the notice comes from the execution path, not the number. Stripe's documentation shows that a price change is an operation that creates proration lines on a customer's invoice, that you can preview that invoice before applying the change, that by default the change applies regardless of whether payment succeeds, and that pending updates normally make it conditional on successful payment. Fill in three rows first: the effective date, the mid-period difference, and what a failed payment means. Write the notice after that and it becomes a report rather than a negotiation. Neither this article nor its sources says anything about what price is appropriate or what a price increase does to your business.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Modify subscriptions
Stripe Docs · no date shown on page; continuously updated product documentation
Accessed 2026-10-04 - Prorations
Stripe Docs · no date shown on page; continuously updated product documentation
Accessed 2026-10-04 - Pending updates
Stripe Docs · no date shown on page; continuously updated product documentation
Accessed 2026-10-04 - Riding the AI boom: How Lovable Grew into a Vibe-Coding Juggernaut with Stripe
Stripe · no date shown; text describes a Nov 2024 launch and 2025 usage billing
Accessed 2026-10-04
AI-assisted editorial production
A&A uses AI for research, writing, translation and editorial checks. Source facts, our analysis and hypothetical examples are labeled separately.
Editorial check: 2026-10-04