一、下架销售方案，不是取消订阅
归档 Stripe 价格对象属于商品目录变更，不是取消订阅。Stripe 明确说明，使用已归档价格的现有订阅会继续有效，直到被取消；归档会阻止将该价格添加到新的发票或订阅中。[1] 这正对应一位开发者的公开提问：创建替代价格后，怎样关联原产品，现有用户又会怎样？[3] 关键是区分两件事：停止按旧价格销售，以及修改已经存在的订阅安排。
二、选择影响范围最小的目录变更
如果只想撤下一种报价，而产品仍以其他价格销售，应归档对应的价格对象。如果整个产品都不再用于新的发票或订阅，则考虑归档产品。Stripe 对这两种操作都明确说明了现有订阅继续有效的行为。[1] 这并不保证此后每笔付款都会成功。建议将访问权限判断与目录可售状态分开，不要把 price.active=false 当作客户订阅已取消的证据。
销售渠道也可能受影响：Stripe 的归档章节提示，使用该产品的现有支付链接会被停用。[1] 因此，应检查相关链接，不能假设归档对所有销售入口都没有影响。
三、金额变化应新建价格，可更新属性才原地修改
如果改变基础金额，应在原产品下创建新的价格对象。Stripe 表示不能通过接口修改现有价格的金额，并建议先创建替代价格、切换到新价格标识符，再将旧价格设为不可用。[1] 单纯改变金额，不需要复制整个产品。
如果只是管理信息变更，应查阅价格更新接口。该接口支持 active、metadata、nickname 和 lookup_key 等参数。[2] 不要笼统地说价格对象的所有字段都不可修改：接口还提供 currency_options，以及受限制的 tax_behavior。税务行为一旦明确设为含税或不含税，就不能再更改。[2] 这些更新能力并不意味着可以覆盖原来的基础金额。
四、有计划地切换新购买入口
建议先创建替代价格，核对其产品关联和目标金额，再调整应用中新购买流程选择价格的逻辑。如果要退役的价格是产品默认价格，应在归档前将默认价格切换到替代价格，因为 Stripe 要求默认价格处于可用状态。[1] 分别检查已保存的价格标识符、价格展示页配置和支付链接；修改默认价格，不能代替对这些引用的检查。
对于动态查询价格的集成，Stripe 提供了将固定 lookup_key 转移到新价格的做法。接口说明 transfer_lookup_key=true 会以原子方式移除旧价格上的查找键，并将其赋予新价格。[1][2] 建议在切换时同步刷新应用缓存。
五、保留老客户价格与迁移订阅是两项决策
如果政策是“新客户用新价格，现有订阅者保留旧方案”，就不修改现有订阅项，只让旧价格退出新销售入口。这符合文档说明的订阅延续行为。[1] 不要因为清理了目录，就顺带增加批量改写订阅的操作。
如果现有客户也必须改用新价格，应将其作为独立、经过明确审批的订阅变更项目。归档本身不会执行这种迁移。[1] 本文有意不展开按比例计费、发票收款或定时变更；这些属于客户订阅变更流程，而不是报价下架操作。
六、优先归档，不要执着于删除
Stripe 只允许删除从未使用过的价格，并且不提供删除价格对象的接口；文档给出的接口替代方案是归档。[1] 建议在内部目录历史中保留旧价格标识符，方便客服解释某位订阅者当时购买的方案。
通过接口归档现有价格时，向 /v1/prices/{PRICE_ID} 提交 active=false；改回 true 可以解除归档。[1][2] 重新开放该价格用于购买，只是目录层面的回退，不能据此认定应用引用或支付链接也已全部恢复。
七、上线前验证职责边界
以下是建议检查项，并非本文已经执行的测试：记录有代表性的订阅和价格标识符；确认新购买流程选择替代价格；读取现有订阅，确认其价格引用未变；检查相关支付链接及缓存目录数据。保留默认价格和查找键的回退记录。这些检查用于验证集成假设，不应把订阅延续误解为付款成功保证。归档的基础行为有官方文档支持，但应用的价格选择、缓存和权益逻辑，仍须在自己的环境中核查。[1][2]
来源与日期
技术行为以官方文档为依据；社区提问只说明定性需求。于2026-09-22读取核验，检索日期不等于原文发布日期；未注明的日期仍视为未知。本文为文档研究，不是实际账户测试，不代表 PayIn 产品功能，也不是法律、税务或财务意见。账户资格与地区可用性需要另行确认。
- [1] 管理产品与价格 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [2] 更新价格 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [3] 我想更新 Stripe 产品的价格 · 发布于2024-03-20; 更新日期未注明 · 核验于2026-09-22。