01

做订阅之前，我以为就 2 件事，用户付钱，用户取消。

真开始做才发现，状态多得让我头皮发麻。

当时心里第一反应是，订阅不就是订阅一下然后能取消，不就行了吗，怎么这么麻烦？

结果越深入越发现，这个「麻烦」不是多余的，是真实存在的业务需求。

02

先说国内的场景，自动续费、试用期、到期前取消、立即取消，大致也就这 4 种。

但我阅读了支付平台的开发文档以及学习订阅以后，发现海外的 SaaS，还有这些，升级套餐、降级套餐、升降级立即生效还是下个周期生效、升级时按比例补差价、降级时在下个周期、年付转月付、月付转年付、支付失败，以及多个 Webhook 的接收处理……

第一次看到这些词的时候，我心里直接打了个问号，这也太多了吧？

光是「取消」这一个动作，就分 2 种，立即取消和到期取消，处理的逻辑是不一样的，处理不好就是用户抱怨、甚至投诉。

你可能会说，我简单点不就行了，只支持续费和取消，省事儿。

可以，但用户体验有很大差距。

比如，如果我们不做升降级，用户想换高级套餐，步骤是，他得先取消当前套餐，然后再付费，需要 2 步。

但如果做了升降级，用户有多省事？点一下确认，立即升级，差价自动补，钱到你账上，用户体验也好，何乐不为呢？是吧。

而用户体验上差的那一点，也许就会变成流失。

有些设计，应当极简，比如，昨天的支付按钮数量分析，但这个，是真的不能省。

那为什么，海外订阅，会有这么多场景呢？

因为，国外的 SaaS 环境跟国内完全不一样。

国内用户买软件，习惯一次性付费，或者包年，续不续看心情。但国外 SaaS 的主流模式是按月订阅，用户跟你的产品是长期关系，关系越长，状态越复杂。

其次呢，国外用户对订阅的权利意识很强。他们会认真看条款，知道自己有权随时取消，有权在升级时只补差价。这不是挑剔，这是他们默认的消费预期。我们不做，他们就觉得我们的产品不专业。

更为重要的是，国外主流支付平台，Stripe 也好，Creem 也好，本身就把这套状态机建进去了。

Creem。

Stripe。

proration、grace period、trial、immediate cancel、cancel at period end……这些不是我们可以选择做不做的东西，这是支付标准。如果绕开它，就是不跟随行业标准，心里总会担心出问题的。

所以状态多，不是过度开发，过度设计，是是融入国际市场的入场券。

当时我硬着头皮把每个场景的逻辑都捋了一遍，捋完以后反而释然了。真正麻烦的不是逻辑，是边界情况。因为这些状态虽然多，但背后的逻辑是自洽的，做完一个，下一个就顺了。

现在我走完整个订阅的生命周期，就特别自如了。毕竟订阅的 60 多个测试用例反复测了几遍了，都快被我翻烂了，哈哈。

比如用户在试用期最后一天升级，比如年付用户在第 11 个月降级，比如用户支付失败了，每一个没处理好，没想到的场景，都是一个潜在的漏洞。

光是把这些边界情况一个个列出来，测试，验证，就花了我大量的时间。

毕竟，出了问题，不是我们损失，就是用户损失，没有第三种结果。

这些场景，不管是升降级、试用期、年付转月付，月付转年付等等各种边界情况，我在 Pay4SaaS 里都处理好了，你直接用就行，感兴趣的可以访问 pay4saas.cn 了解。