<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Mark</title>
    <description>The latest articles on DEV Community by Mark (@pricepilot).</description>
    <link>https://dev.to/pricepilot</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4206650%2Fe8958faa-21cd-488b-8455-902512efbadc.png</url>
      <title>DEV Community: Mark</title>
      <link>https://dev.to/pricepilot</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/pricepilot"/>
    <language>en</language>
    <item>
      <title>How to Change the Price of Existing Stripe Subscriptions Without Cancelling Anyone</title>
      <dc:creator>Mark</dc:creator>
      <pubDate>Sun, 25 Oct 2026 16:15:51 +0000</pubDate>
      <link>https://dev.to/pricepilot/how-to-change-the-price-of-existing-stripe-subscriptions-without-cancelling-anyone-3an8</link>
      <guid>https://dev.to/pricepilot/how-to-change-the-price-of-existing-stripe-subscriptions-without-cancelling-anyone-3an8</guid>
      <description>&lt;p&gt;Sooner or later every membership site and SaaS hits the same wall. You raise your price, update the pricing page, and then realize the new price only applies to people who sign up from today onward. Everyone who subscribed last year keeps paying the old rate forever, because that is how Stripe works. A subscription is pinned to the price it started on, and prices themselves cannot be edited. Your platform is not broken. Paid Memberships Pro, MemberPress, Ghost, beehiiv, Thinkific, all of them change the price for new checkouts and leave existing subscribers exactly where they are.&lt;/p&gt;

&lt;p&gt;People usually discover this at the worst moment, when a client or their own pricing change is already announced and hundreds of subscribers need to move. Here is how to actually do it, from the manual route up.&lt;/p&gt;

&lt;h2&gt;
  
  
  What does not work
&lt;/h2&gt;

&lt;p&gt;Cancelling everyone and making them resubscribe. You will lose a chunk of them to expired cards, forgotten passwords, and simple inertia, and the ones who stay will be annoyed. Some platforms even suggest this. Do not do it.&lt;/p&gt;

&lt;p&gt;Editing the price is also off the table, because Stripe prices are immutable once created. You create a new price and move subscriptions onto it. The moving is the whole job.&lt;/p&gt;

&lt;h2&gt;
  
  
  Option 1: Do it by hand in the Stripe dashboard
&lt;/h2&gt;

&lt;p&gt;For a handful of subscribers this is honestly fine. Open the customer in Stripe, open their subscription, choose update subscription, swap the old price item for the new price, and set proration off so the change takes effect on the next billing cycle instead of charging or crediting mid-cycle. Because it is the same subscription, the member keeps their billing date, their trial if they are still in one, and their coupon if they have one. Nothing is required from the member at all.&lt;/p&gt;

&lt;p&gt;The catch is arithmetic. At two or three minutes per subscriber, fifty subscribers is an afternoon and five hundred is a week of clicking, with every click a chance to fat-finger the wrong price onto somebody's live billing.&lt;/p&gt;

&lt;h2&gt;
  
  
  Option 2: Script it against the API
&lt;/h2&gt;

&lt;p&gt;The script version is a loop. List the subscriptions sitting on the old price, update each one's item to the new price with proration behavior set to none, or build a subscription schedule when the change should land on a specific future date. Log every success and failure so you can rerun the failures.&lt;/p&gt;

&lt;p&gt;It works, and it is also where people get hurt, because the edge cases are all in your list somewhere. Trialing subscriptions behave differently from active ones. Paused and past due subscriptions need a decision, not a default. Some subscribers have two price items, or a quantity, or a coupon that expires the same week. A script that handles the happy path perfectly and silently mangles the other four percent is worse than doing it by hand, because you find out from your customers.&lt;/p&gt;

&lt;h2&gt;
  
  
  Either way, tell people first
&lt;/h2&gt;

&lt;p&gt;Whatever route you take, email your members before the new price hits their card. Most people accept a price increase they were warned about, especially if you offer to let long-time members keep the old rate, which you can do by simply leaving their subscriptions out of the run. Surprises are what turn a routine price change into chargebacks and angry support tickets.&lt;/p&gt;

&lt;h2&gt;
  
  
  Option 3: Use a tool built for the move
&lt;/h2&gt;

&lt;p&gt;Full disclosure, this is the problem I built PricePilot for. Migrate Pro connects to the Stripe account with a restricted key, shows you the MRR impact and the full list of affected customers before anything runs, then re-prices the subscriptions in place, in batches, with the change scheduled for the next cycle so nobody gets a surprise mid-cycle charge. Trials and coupons carry over because the subscription itself never gets cancelled, and a run can be reversed. Testing is free end to end with a Stripe test key, so you can rehearse the whole migration against test data before it touches anything live.&lt;/p&gt;

&lt;p&gt;If you have twenty subscribers, do it by hand and spend the afternoon on something better. If you have hundreds sitting on a price from two years ago, that gap is money you have already decided to collect. Go collect it carefully.&lt;/p&gt;

&lt;p&gt;Mark&lt;br&gt;
Founder, PricePilot (pricepilot.cloud)&lt;/p&gt;

</description>
      <category>stripe</category>
      <category>saas</category>
      <category>webdev</category>
      <category>payments</category>
    </item>
  </channel>
</rss>
