1. Retire the offer, not the subscription
Archiving a Stripe Price is a catalog change, not a subscription cancellation. Stripe explicitly says existing subscriptions using an archived price remain active until canceled; archiving prevents that price from being added to new invoices or subscriptions.[1] This answers a real developer question: after creating a replacement price, how should it connect to the product, and what happens to existing users?[3] The useful distinction is between stopping new sales at an old price and changing agreements already in place.
2. Choose the smallest catalog change
Archive a Price when one offer should disappear but the product remains available at other prices. Archive the Product when the whole offering should stop being available for new invoices or subscriptions. Stripe documents subscription continuity for both operations.[1] Neither is a promise that every later payment succeeds. Recommendation: keep access-control logic separate from catalog availability; do not treat price.active=false as evidence that a customer’s subscription was canceled.
There is also a sales-channel consequence: Stripe’s archive sections warn that existing payment links using the product are deactivated.[1] Review affected links rather than assuming an archive is invisible everywhere.
3. Replace amounts; mutate supported attributes
For a changed base amount, create a new Price associated with the existing Product. Stripe says a price’s amount cannot be changed through the API and recommends creating the replacement, switching to its ID, and making the old price inactive.[1] A new amount does not require duplicating the product.
For administrative edits, consult the update endpoint instead. It supports active, metadata, nickname, and lookup_key, among other parameters.[2] Avoid the blanket claim that every price field is immutable: the endpoint also exposes currency_options and constrained tax_behavior. Once tax behavior is explicitly inclusive or exclusive, it cannot be changed.[2] Those capabilities are not permission to overwrite the original base amount.
4. Move new sales deliberately
Recommendation: create the replacement first, confirm its product association and intended amount, then update the application’s new-purchase selection. If the retired price is the product’s default, choose the replacement as default before archiving: Stripe requires the default price to be active.[1] Audit stored price IDs, pricing-page configuration, and payment links independently; a default-price change is not a substitute for reviewing those references.
For integrations that resolve prices dynamically, Stripe documents transferring a stable lookup_key to a new price. The API describes transfer_lookup_key=true as atomically removing the key from the old price and assigning it to the new one.[1][2] Recommendation: refresh any application cache during that handover.
5. Keep grandfathering separate from migration
If the policy is “new customers pay the new price; current subscribers keep the old offer,” leave existing subscription items alone and retire the old price from new sales. That follows the documented continuity behavior.[1] Do not add a bulk subscription rewrite merely because you cleaned up the catalog.
If existing customers must move too, make that a separate, explicitly approved subscription-change project. Archiving itself does not perform that migration.[1] This article intentionally does not prescribe proration, invoice collection, or scheduling: those decisions belong to the customer-change workflow, not to removing an offer from sale.
6. Archive instead of seeking deletion
Stripe only permits deletion of never-used prices, and provides no API operation to delete a Price; the documented API alternative is archiving.[1] Recommendation: retain old price IDs in your internal catalog history so support can explain which offer a subscriber purchased.
To archive an existing price through the API, update /v1/prices/{PRICE_ID} with active=false; setting it back to true unarchives it.[1][2] Reopening a price for purchases is a catalog rollback, not a reason to assume every application reference or payment link has been restored.
7. Verify the boundary before production
Recommended checks, not tests performed for this article: record representative subscription and price IDs; confirm new purchases select the replacement; retrieve existing subscriptions to confirm their price references remain unchanged; inspect affected payment links and cached catalog data. Keep a rollback record of defaults and lookup keys. These checks validate your integration’s assumptions without treating subscription continuity as a payment guarantee. The underlying archive behavior is documented; your routing, caching, and entitlement behavior must be checked in your own environment.[1][2]
Sources and dates
Official documentation supports technical behavior; community questions demonstrate qualitative demand only. Retrieved and checked on 2026-09-22. Retrieval is not publication. Unstated dates remain unknown. This is documentation research, not a live-account test, PayIn feature claim, or legal, tax or financial advice. Account eligibility and regional availability require separate confirmation.
- [1] Manage products and prices · Publication date not stated; update date not stated · Checked 2026-09-22.
- [2] Update a price · Publication date not stated; update date not stated · Checked 2026-09-22.
- [3] I want to update the price for a product on Stripe · Published: 2024-03-20; update date not stated · Checked 2026-09-22.