Stripe 测试自动续费与积分发放的小技巧

这篇文章复盘了我在排查“用户自动续费成功但积分未到账”时，怎么把一个很难复现的线上问题变成可控的测试流程。核心技巧是把 Stripe 订阅的计费周期设成按天，用 1 天订阅模拟第二天自动续费，从而验证“续费→Webhook→业务发放积分”这条链路是否完整跑通。除此之外，如果是 Webhook 当时处理失败，还可以在 Stripe 后台对未送达/失败的事件进行重试/手动处理，快速定位是事件没到还是业务逻辑没处理

我遇到的真实问题是：

用户自动续费成功了
但我的系统里积分没有到账
我后来修好了逻辑，但这个场景有个硬伤：很难测试，因为你不可能每次都等一个月再看续费链路。

一、为什么这类问题很难测

自动续费的积分发放，通常依赖一条链路：

Stripe 生成续费账单/支付成功
Stripe 通过 Webhook 推送事件到你的服务
你的服务收到事件后，执行业务逻辑：给用户加积分
写库/记账/发通知

这条链路只要任意一环出问题，就会出现“钱扣了，但权益没到”的投诉。

而难测点在于：

续费周期通常是按月/按年
你很难在短时间内反复验证第二次、第三次续费的行为

二、核心技巧：把订阅周期改成 1 天来模拟续费

我后来才意识到：Stripe 的订阅周期可以做到按天设置。

在 Stripe 的价格/订阅模型里，计费周期由 interval 和 interval_count 决定，比如 interval=day，interval_count=30 就是每 30 天计费一次。那同理，你把它设成：

interval=day
interval_count=1

就能得到一个一天一续费的订阅，用来测试自动续费逻辑非常实用。

我是怎么用的

新建一个专门用于测试的订阅产品/价格
计费周期选按天
自己用测试账号订阅一次
第二天看续费发生时：
- Stripe 是否扣款/生成 invoice
- Webhook 是否触发
- 我的积分是否到账

这样你就不用等一个月，一天就能验证一次完整续费链路。

三、一个更“专业”的加速方式：Test Clocks

如果你不想真的等一天，其实 Stripe 还提供了测试用的 Test Clocks，可以在测试环境里模拟时间推进，用来验证订阅续费逻辑。这个更适合你要做自动化测试或回归测试时用。

我这次分享的“1 天订阅”更偏实操土办法：简单、直接、能跑通链路。

四、当 Webhook 事件失败时：在后台重试/手动处理

另一个常见情况是：不是你积分逻辑写错，而是 Webhook 事件根本没处理成功。

Stripe 的 Webhook 投递有自动重试机制：

Live 模式下会在最多 3 天内按退避策略持续重试
你也可以在 Dashboard 里查看投递情况并加速处理未送达事件

我常用的排查/补救动作

去 Stripe 后台的 Webhook/事件投递列表
找到失败/未送达的事件
直接点 重试/重新发送
看你的服务端日志有没有收到，业务有没有执行

这个动作的价值是：

你能快速区分问题到底在Stripe 没投递，还是你服务端收到了但没处理对。

五、我现在的测试清单

为了避免以后再被这种问题“线上暴雷”，我把测试固定成一套清单：

用 1 天订阅验证续费链路（或用 Test Clocks 加速）
重点盯这两个事件相关的数据是否闭环：
- 续费发生后，系统权益是否到账
- Webhook 投递是否成功、是否有失败重试
发现异常就直接用后台 重试事件来复现/补发