01

被动层，Webhook 通知

订阅过期这件事，主动权不在我们手里。

用户在 Stripe/PayPal/Creem 付了钱，续没续费、取没取消、有没有到期——这些状态变更，全部由支付平台掌控。我们能做的，就是等通知。

这就是 Webhook 的角色，各个支付平台在状态变更的瞬间，给我们服务器发一个事件。收到了，处理；没收到，就不知道。

听起来简单，但订阅的状态远比想象的多。

每一种状态变更，支付平台发的事件类型都不一样。漏处理一个，后果，就不说了，反正总有一方亏。

我最早就在这里也翻过车。比如「到期取消订阅」这件事，Stripe 其实分两步通知，第一步告诉我「用户发起了取消」，第二步等周期结束才告诉我「订阅真正终止了」。如果我在第一步就把权限收了，用户会很生气——人家这个月是付过钱的。

这两步之间怎么处理，我试了好几版才稳住。而且 Stripe、PayPal、Creem 三家的事件命名和时序还都不一样，统一起来又是一道坎。

Webhook 是 99% 场景的主力。Stripe、PayPal 这些平台做了很多年了，可靠性很高，还有自动重试机制。但——

它不是 100%。

网络抖动、服务器重启、部署间隙、Supabase 偶尔超时……都可能导致 Webhook 丢失或处理失败。概率很低，但在 SaaS 里，「很低」不等于「不会」。

所以，就需要做兜底了。

主动层，两道兜底

Webhook 丢了，用户也没来访问——这种情况下，数据库里的状态就一直是错的。没人通知，也没人触发，订阅永远「有效」。

这还不只是「数据不准」的问题。你的 dashboard 上，活跃订阅数是虚高的，你拿这个数据做决策就是在骗自己。

更麻烦的是什么呢，如果系统里有别的逻辑读了这个状态——比如发营销邮件——全都跟着错。一个漏网的过期订阅，能污染一串下游数据。

所以我加了一层定时巡检，周期性地扫一遍，把该过期的过期掉。

听起来简单，但真正做的时候会发现，光改状态不够，关联的数据也要一起处理，否则下次用户访问时数字对不上，其次，你统计收入的时候也对不上账，是吧。

一次巡检要处理多少东西、怎么保证不误杀正常续费的订阅——这些才是坑。

定时任务有延迟，Webhook 可能丢。但有一个时刻是确定的——用户来了。

用户访问的那一瞬间，我会做一次实时校验。如果发现数据不对，当场修正。用户感知不到延迟，但状态已经是准的了。

这是最后一道防线。不管前面两层怎么漏，用户来了就一定是准的。

而且实际做下来会发现，需要在这个时刻校验的东西远不止「订阅有没有过期」一项。跟时间相关的状态变更，比你想象的要多得多呢。

你可能会说，Webhook 那么稳，搞这么复杂干嘛？

因为支付是不能赌的。

Webhook 是被动的——第三方不通知，我们就不知道。定时任务是有延迟的——两次巡检之间有窗口期。懒加载是有前提的——用户得来访问。

三层各有短板，但组合在一起，就形成了闭环。

做支付系统最怕的不是出 bug——bug 能查能修。最怕的是悄悄地错，错了你都不知道，直到某天对账发现数字对不上。

三层防御的意义不在于它们每一层都经常被用到，而在于——不管哪个环节出了问题，总有站长兜着。

这就是我在 pay4saas 里处理订阅过期的完整思路。Webhook、定时任务、懒加载，三层叠在一起，确保从订阅到取消、从续费到过期，每一个状态变更都不会被漏掉。

如果你也在做 SaaS 变现，不想在支付这层踩坑，pay4saas，更多的坑，都已经填好了。让你放心收钱。