用户主动取消订阅：三个时点、两笔钱、一张最终发票

直接答案

用户主动取消订阅（voluntary churn）与扣款失败（involuntary churn）是两条不同的流失路径。前者是「客户决定不续了」，后者是「客户想续但钱没扣到」。两件事的运营动作几乎不重叠：后者要管重试、催收与终态；前者要管时点、钱、发票。

这三件事经常被一句「帮他取消掉」糊在一起，于是出现两种典型事故：

• 客户以为「取消＝退款」，你按文档默认立即取消、没有退款，下一封邮件就是投诉；
• 你答应了「月底停」，却在周期中间改了 cancel_at，产生了一笔客户没预期的 proration，最终发票比平时还高。

本文以 Stripe Billing 的三份公开文档为例（2026-10-25 读取），把「系统实际会做什么」与「你必须自己决定什么」分开写。字段名换成别家计费系统会不同，但这三层结构可以直接搬过去核对。

一、三个时点，三种后果

Stripe 的取消入口有三个时点：立即、期末、指定日期。它们在「服务到哪天」「能不能反悔」「钱怎么算」上都不一样。

时点	怎么设	服务与订阅	钱与发票	能否反悔
立即	API 默认；Dashboard 也可选	立即生效，之后不再为该订阅生成发票	是否退款要另选；未结项目要另处理	已取消的订阅不能恢复
期末	cancel_at_period_end=true	走完客户已付费的这段时长	待处理的 proration 仍会在期末收取	期末前把该字段改回 false 即可恢复
指定日期	cancel_at=<时间戳>	到期日生效；若早于本周期结束，会缩短当前周期	不能退款；能否关掉 credit proration 取决于日期是否在当前周期内	生效前可改；已取消不能恢复

立即取消：默认值，不是「最安全值」

文档写得很直白：

By default, cancellation takes effect immediately and invoices are no longer generated for canceled subscriptions. After it’s canceled, you can no longer update the subscription except for its metadata and cancellation_details.

这句话有两个容易被忽略的尾巴。

第一，「不再生成发票」只说明未来不再开票，没有说退回已经收过的钱。Dashboard 的取消流程里，退款是单独一步：按比例退、退最后一笔、或不退；API 的取消参数里则根本没有「退款」这一项——它只按 prorate 规则记账，真要退钱得另走退款接口。

第二，取消后订阅几乎变成只读：除了 metadata 和 cancellation_details，不能再改。客户三天后回来说「我还是想继续」，你不能把原订阅「打开」，只能新建一条订阅。文档在争议自动取消一节把后果写得更直接：

You can’t restart a canceled subscription. You must create a new subscription for the customer if you want to continue billing them.

另一处「停止待取消」也重复了同一句：「You can’t reactivate a canceled subscription.」所以这不是某个特殊场景的限制，而是已取消订阅的通用状态。

期末取消：客户还能反悔，pending proration 照收

设 cancel_at_period_end=true 的含义是「让订阅走完客户已经付过的时间」。文档给的恢复方式也很清楚：

You can reactivate subscriptions scheduled for cancellation by updating cancel_at_period_end to false. You can reactivate the subscription at any time up to the end of the period.

这里有一个反直觉的账单细节：

If you set the subscription to cancel at period end, any pending prorations are left in place and still collected at the end of the period.

也就是说，「期末取消」不是「期末把所有账一笔勾销」。之前因为改套餐、改数量留在那儿的 proration，期末仍会进最终发票。客户如果只盯着「我已取消」四个字，很容易把这张发票当成乱收费。

指定日期：最灵活，也最容易踩「不能退款」

cancel_at 可以定一个未来时间。如果这个时间早于当前周期结束，订阅的 current_period_end 会跟着缩短，并产生 proration——除非你在这次更新里明确禁用 proration。

但文档专门用「Common mistake」标出了两个边界：

If you set a custom cancel date, you can’t provide a refund. You can also only prevent the credit proration from generating if the cancel_at date is within the current billing period. If you cancel the subscription for a date outside the current period, you can’t disable the proration.

翻成运营语言：

1. 指定日期取消不提供退款。想让客户拿到钱，得走退款流程，而不是指望取消动作顺手退。
2. 只有取消日落在当前周期内，你才能关掉 credit proration。如果取消日在一个周期之外，proration 关不掉。
3. 如果取消日比当前周期更远，订阅在续进包含该日期的那个周期之前不受影响；等续进去时，current_period_end 才会缩短到取消日。

所以「帮我定在三个月后停」不是一句无害的排期。它跨了周期，proration 的行为已经不由你选；对客户承诺「到时候一分不多收」之前，先在测试模式把这笔账跑出来。

二、proration 是算账方式，不是退款按钮

很多人把 proration 理解成「按比例退钱」。它更准确的意思是：把当前周期的费用，按改动前后的时间重新分摊。结果可能是退，也可能是补。

文档的例子：客户从 10 美元/月升到 20 美元/月，周期过半时升级。

项目	金额	合计
原 10 美元套餐未使用时间的 credit	−5 美元	−5 美元
新 20 美元套餐剩余时间的 debit	+10 美元	+5 美元

客户这次要补 5 美元，不是收 5 美元。降级则反过来，通常产生未使用时间的 credit。所以第一句话应该是「proration 可能补收」，而不是「proration 会退钱」。

文档还有四句会直接影响客服话术：

Negative prorations aren’t automatically refunded and positive prorations aren’t immediately billed, although you can do both manually.

负的 proration 不会自动退，正的也不会立刻扣。系统只是把账记在那儿，什么时候收、什么时候退，仍然要你决定。

When calculating proration credits or debits, Stripe uses the subscription’s discounted price, not the original price.

proration 按折后价算，不按标价算。客户拿着标价自己算出来的数字，和你实际记的账会对不上。

Updating subscription-level promotion codes, coupons, or discounts by themselves doesn’t create proration invoice items.

只改折扣、不改价格或数量，不产生 proration。反过来说，同一个 API 调用里既改数量又改折扣，proration 会用改完之后的折扣算——顺序会影响金额。

By default, Stripe calculates prorations down to the second.

默认精确到秒。你按「用了几天」手算，和系统按秒算，差几块钱是正常的，不是系统算错。

取消时的 proration，和改套餐时的 proration 不是一回事

这里有一个很容易混的点。proration 的通用规则是「只作用于提前收取的费用」：

Prorations only apply to charges that occur ahead of the billing period. Usage-based billing isn’t subject to proration.

按用量计费的部分不参与 proration。但取消时，文档又给了一个单独的开关：

If you don’t prorate the subscription, all metered usage gets discarded and the customer won’t receive credit for any potential prorations.

也就是说，取消时如果你选择不 prorate，本周期已经上报的计量用量会被丢弃，客户也拿不到任何未使用时间的 credit。对按月预收 + 按量后付的混合订阅，这一刀切下去，客户可能同时损失「未用完的订阅费」和「已经产生的用量」。

取消时选择 prorate，还可以进一步决定要不要立刻开票收两笔钱：未结的 proration，以及计量用量。文档给的参数是 invoice_now；如果你欠客户 credit，可以放进 credit balance 抵未来发票，也可以先退款再把账户余额调回零。

未付发票会让 proration 算出一笔「还没收到的钱」

文档里有一段很值得一人公司抄进对账流程：

Stripe calculates prorations based on the subscription’s status at the time of an update, assuming that any previous invoices for the subscription will eventually be paid. If a customer changes their subscription while having an unpaid invoice for the current period, they might receive a credit for unused time on the higher-priced plan, even if they haven’t paid for that time yet.

客户上一张发票还没付，你给他降级，系统仍可能按「他付过高价套餐」给他 credit。要避免这种「给未收的钱发信用」，可以在最新发票未付时把 proration_behavior 设为 none，再选择保留原账期、单独开一张一次性发票，或者把 billing_cycle_anchor 设为 now 重开周期。

但文档同时警告：这两种做法都可能在客户后来付掉旧发票时造成重复收款。要避免，就把旧的那张未付发票作废。这不是一个可以「先这样、以后再说」的选项，而是一组必须一起做的动作。

三、最终发票：三笔最容易漏的钱

取消当天的「最终发票」不是一个按钮，而是三笔账的合集。

第一笔：待处理的 invoice items。 文档写得很清楚：如果取消时开了最终发票，或者客户还有另一个活跃订阅，pending invoice items 仍可能被计费。要避免，必须手动删除这些 items。系统不会因为你取消了订阅就自动清空。

第二笔：本周期已经上报、但还没到出账时间的用量。 文档的说法是：周期内上报的 usage 会在期末计费；要避免最终用量费，得用 clear_usage 把计量价格从订阅上移除。注意这是「移除计量价格」，不是「把已经产生的用量改小」。

第三笔：开放中和草稿状态的发票。 取消订阅时，这些发票的 auto_advance 会被设成 false：

When you cancel a subscription, all open and draft invoices for that subscription have their auto_advance property set to false.

这会暂停自动扣款，也会停掉自动提醒邮件。你仍然可以手动收款、手动发邮件，但系统不会再替你追。对一人公司来说，这意味着「取消后忘了跟进」的发票会静静躺在那里，不会有人提醒你。

事件：哪个是「打算取消」，哪个是「已经取消」

订阅取消会发两个不同的事件，监控脚本不能混：

事件	什么时候发	该做什么
customer.subscription.updated	任何订阅更新，包括 cancel_at_period_end 被设为 true	记录「已申请取消」，启动挽留或确认邮件
customer.subscription.deleted	订阅真正取消时（直接删除，或期末到期）	关服务、结账、归档，不要再发续费提醒

把 updated 当成 deleted，会在客户还没到期时就断服务；把 deleted 当成 updated，会在客户已经走了之后还继续发「您的订阅已续费」。

四、自助取消页：默认值是「不出事」，不是你的策略

Stripe 客户门户的取消相关选项，默认值如下（来自配置页的表格）：

选项	默认	页面原话/含义	对一人公司的含义
Cancel subscription	开	「Let your customer cancel their subscription. After canceling, customers can still renew subscriptions until the billing period ends.」	客户可以自己走，不必发邮件等你处理
Cancellation reason	开	「capture a cancellation reason when your customer cancels」	你能拿到原因，但页面没说必须填
Retention coupons	关	「Offer coupons to customers before they cancel … churn reduction strategy」	想让挽留券生效，得自己打开
Prorate subscription updates	关	只作用于「改套餐/改数量」时是否按剩余时间 credit	不要把它当成取消退款开关
Manage downgrades	立即生效	默认「Update immediately」	降级会立刻改变当期账单

三个判断：

① 取消原因不是门槛。 页面只说可以「capture」，没有说可以强制、也没有说必填。把它做成「不填原因就不能取消」，是在文档没授权的地方加限制；客户真要走，只会去发邮件或找支付平台争议。

② 挽留券默认关闭。 页面把它写成「churn reduction strategy」的一部分，但默认值是 Off。你不打开，取消页就只有「取消」一个按钮。

③ 「Prorate subscription updates」不是取消退款开关。 这一行的限定语是「If customers can change their plan or quantity」——它管的是升级、降级、改数量时的 credit，不管取消时退不退款。取消时的退款/credit 是取消流程里的另一个选择。把两者混为一谈，会在客户取消时给出错误的退款承诺。

门户页还有一句容易被误读的话：

After canceling, customers can still renew subscriptions until the billing period ends.

这不是「取消没生效」，而是「到期末之前，客户仍可以反悔续订」。具体你的门户把取消落在立即还是期末，页面没有在这句里说明；上线前应该在测试模式走一遍，看订阅状态和最终发票，而不是靠读这一句推断。

五、别把「暂停收款」和「取消」混在一起

取消页开头专门区分了这两件事：

If you want to keep a subscription active but temporarily stop collecting payment, you can pause payment collection. Pausing payment collection doesn’t affect the subscription status, which we recommend using as the trigger for starting or stopping service to your customer.

暂停收款（pause_collection）只停收款，不改订阅状态。取消则改变状态。对交付系统来说，订阅状态才是该用来开关服务的信号；用「最近有没有收到钱」当信号，会在暂停收款期间误断服务。

同一页还给了一条与扣款失败的交叉边界：订阅在最多 8 次扣款失败后会自动取消。这是非自愿流失的终态之一，不是客户主动取消。两条路径的邮件、时点与退款政策都应该分开写。

六、一张可照抄的取消处理清单

触发	动作	依据
收到取消请求	记录三件事：生效时点、是否退款、原因分类	时点决定后面的所有分支
选「立即」	决定退款/credit；用 invoice_now 开最终发票；clear_usage 处理未出账用量；手动删除 pending invoice items	默认立即生效且不再开票，但退款与未结项目要另做
选「期末」	服务保留到期末；告知客户期末前可恢复；提醒 pending proration 仍会期末收取	cancel_at_period_end 可恢复；pending proration 不消失
选「指定日期」	不承诺退款；确认取消日是否在当前周期内，再判断能否关掉 credit proration	自定义取消日不能退款；跨周期关不掉 proration
订阅已取消	不再改原订阅；客户回流要新建订阅	已取消订阅不能 reactivate
有开放/草稿发票	知道 auto_advance=false，自动扣款与提醒都停了，安排人工跟进	取消会暂停这些发票的自动收款
开了争议自动取消	二选一：立即取消且不 prorate，或期末取消留出争议处理时间；改动约 1 小时生效	该功能只支持全额争议的信用卡/借记卡，且不支持 test clocks

七、上线前八项检查

1. 取消页写清「取消不等于退款」。 退款政策单独一段，不要藏在 FAQ 里。
2. 三种时点都在测试模式走一遍。 看订阅状态、最终发票、proration 明细，而不是只看后台显示「已取消」。
3. 确认你的取消落在哪个时点。 API 默认立即，门户可能不同；不要靠猜。
4. 检查门户的取消原因是否开启。 开启是为了拿数据，不是为了设门槛。
5. 决定挽留券开不开。 默认是关的；开了也要设预算上限，避免把取消页变成折扣页。
6. 把 pending invoice items 与未出账用量列进取消清单。 这两笔不会自动消失。
7. 区分 updated 与 deleted 两个事件。 一个代表「打算取消」，一个代表「已经取消」。
8. 每月对一次账。 抽三笔取消，核对「客户以为退了多少」与「实际退了多少」。

八、五种常见误读

「取消就是退款。」 不是。立即取消默认只是停止未来开票；退款是取消流程里的另一个选择。

「期末取消会马上断服务。」 不是。cancel_at_period_end 让订阅走完已付费时长，期末前还能恢复。门户页也写「到期末前仍可续订」。

「proration 一定是退钱。」 不是。升级/延长可能是 debit，要补收；降级才通常是 credit。负的不会自动退，正的不会立刻扣。

「取消原因必须填。」 文档只说可以 capture，没有说必填。把它做成硬门槛，是把客户往站外赶。

「暂停收款就是取消。」 不是。暂停收款不改订阅状态；取消才改。服务开关应该看状态，不看最近一次收款结果。

九、这周能做的五件事

1. 在测试模式各走一次「立即 / 期末 / 指定日期」，把三次的最终发票截图存档。
2. 写一句能直接发给客户的退款政策，贴到取消页与确认邮件里。
3. 打开（或明确关闭）门户的取消原因收集，并决定挽留券预算。
4. 检查取消后的开放发票：auto_advance=false 之后，谁负责跟进。
5. 把 customer.subscription.updated 与 deleted 接到不同的内部动作上，别再用一个事件通吃。