先分清：取消“计划”还是取消“订阅”
Subscription schedule 是按时间控制订阅变更的对象，并不等同于它管理的 subscription。客户说“取消已经排好的变更”，并不一定是要求终止正在使用的服务。release 会立即停止 schedule 的阶段调度，但保留已经存在的订阅；cancel 则会立即取消 schedule，以及它关联的活跃订阅。[1][2][3] 因此，后台按钮如果只写“取消计划”，很容易让客服把撤回未来变更误操作成终止当前服务。
还要区分“现在执行的动作”和“将来结束时的规则”。调用 release 或 cancel 接口是立即操作；end_behavior 决定 schedule 跑完最后一个阶段后如何处理订阅。对象文档明确规定默认值是 release，即计划结束后保留底层订阅继续运行；cancel 则是在计划结束时取消底层订阅。[1][4] 把 end_behavior 改成 cancel，不等于此刻立即取消订阅；调用 cancel，也不是只改最后阶段的配置。
根据业务结果选择操作
- 当前订阅继续，所有剩余的计划变更都不要了：选择 POST /v1/subscription_schedules/{id}/release。它现在就解除阶段调度，而不是等最后阶段结束。[2]
- 计划和当前活跃订阅都要立即停止：选择 POST /v1/subscription_schedules/{id}/cancel。即使对象上保存的 end_behavior 是 release，立即取消接口仍按自身语义取消活跃订阅；end_behavior 并不是阻止取消的保护开关。[3][4]
- 所有阶段照常执行，最后继续续订：选择 end_behavior=release。这里保留的是计划结束时的订阅状态，而不是自动恢复到创建计划之前的价格、数量或其他配置。[4]
- 所有阶段照常执行，最后终止订阅：选择 end_behavior=cancel。核对最后阶段真正的结束时间，不要把它未经核实地等同于下一个账期结束时间。[1][4]
例如，客户撤回下个月的计划调整、但今天的服务继续，是 release 的场景；一份固定期限服务合同要求按现有阶段运行到约定结束日，是 end_behavior=cancel 的场景；要求立即停止当前服务，则是 cancel 接口的场景。这些是帮助选择的假设情景，不是本文对真实账户执行后的测试报告。
release 后应该检查哪些字段
release 接口仅允许 status 为 not_started 或 active 的 schedule。原来存在关联订阅时，释放会移除 schedule 的 subscription 属性，并把该订阅 ID 放入 released_subscription。返回的 schedule 状态为 released，released_at 表示释放时间。[2] 因此，看到释放后的 schedule.subscription 为空，不能据此认定客户订阅被删除；应该沿 released_subscription 查询底层订阅。
释放还有一个很容易漏掉的参数：preserve_cancel_date。接口对它的说明是保留由 schedule 在订阅上设置的取消安排。[2] 操作前应先确认业务意图：只是撤掉阶段控制，还是连原本的终止安排也要改变？如果要保留取消安排，应明确使用该参数，并在操作后复核订阅的取消字段。不能只凭“release 成功”就向客户承诺以后一定无限续订。此次取得的参数说明没有标出默认值，因此本文不推测省略参数时的默认结果。
对于尚未开始、也没有现存订阅的 schedule，不应强制要求返回一个非空的 released_subscription 才认为成功。官方说的是保留“已经存在的订阅”，而标识符转移以此前存在订阅关联为前提。[2] 同样，停止未来阶段调度，不代表撤销此前已经生效的变更，也不能作为自动退款的依据。
cancel 的账务参数需要单独确认
cancel 接口同样只允许 not_started 或 active 状态。对于 active 的 schedule，invoice_now 默认为 true，决定是否生成最终账单，将尚未开票的计量用量以及新产生或待处理的按比例调整项目纳入其中；prorate 也默认为 true，决定本次取消是否按比例处理。[3] 这两个参数属于取消操作，不应和 schedule 更新或阶段切换的 proration_behavior 混为一谈。[1][3]
因此，审批立即终止服务时，要同时记录是否需要最终开票，以及是否需要取消时的按比例处理。不能把 invoice_now=false 描述成“所有欠款清零”，也不能把取消成功描述成“退款完成”；这两种结论都没有得到本次接口文档支持。订阅生命周期、账务处理和你自己的产品访问权限，是需要分别核对的三个层面。
常见问题：按对象状态排查
- “release 成功，为什么订阅还在？”先确认需求是不是只撤掉未来变更。保留现有订阅正是 release 的正常语义，而不是执行失败。[2]
- “已经设置 end_behavior=cancel，为什么没有取消日期？”先看是否进入最后阶段。Stripe 指南说明，订阅的取消日期直到进入最终阶段才设置，因此前面的阶段没有该日期，不足以说明结束规则失效。[1]
- “原来的 schedule ID 为什么不能继续拿来管理？”先重新查询状态。schedule 的 not_started、active、completed、released、canceled 是不同状态，不能全部映射成“订阅已结束”。[4] 官方建议释放后将旧 schedule ID 从活跃管理链路中移除，随后直接修改订阅或创建新的 schedule。[1] 历史审计记录可以保留，但不要再把旧 ID 当成当前控制对象。
- “直接改过订阅，后来为什么又变了？”检查是否仍绑定 schedule。官方说明，直接修改 subscription 的内容并不全部传播到 schedule，后续阶段可能覆盖这些改动；绑定期间应优先使用 schedule API 管理。[1]
- “如何确认执行结果？”立即释放后核对 released_subscription 和 released_at；立即取消后核对 status=canceled 与 canceled_at。[2][3] 这些字段只能证明对应对象状态，不证明账单已支付，更不证明业务系统已经收回或保留了访问权限。
建议的上线验收与边界
建议每次操作记录客户真实意图、操作前的两个对象 ID、当前阶段、期望的最终结束时间，以及操作后的两个对象状态。测试应覆盖尚未开始、正在运行、进入最后阶段和已经终态的情况。客服界面最好把“解除计划，保留当前订阅”和“立即取消计划及订阅”分开呈现，确认文案明确说明影响对象。以上是实现与验收建议；本文没有访问凭据，没有执行任何需要认证的 Stripe 写入，也没有进行支付实测。
本文官方来源检索于 2026-09-22，取得的页面文本没有明确的发布日期或最后更新时间，因此不把检索日期冒充发布时间。这里解释的是 API 生命周期，不是全球商业可用性承诺。所读来源没有列出上述语义的地区特例，但不能据此推出任何地区都能开通 Stripe、使用所有支付方式，或忽略当地取消、税务及合同要求。实际接入还需核对账户可用地区、法律义务和自己固定使用的 API 版本。
来源与日期
来源为官方文档，站点可能返回本地化语言文本；未注明发布或更新日期，于2026-09-22读取核验。检索日期不等于原文发布日期。本文为文档研究，不是实际账户测试，不代表 PayIn 产品功能，也不是法律、税务或财务意见。