2

5

@CoderGeek 取消订阅走当前周期结束时取消也就是不退款更合适些。
我的产品是像 cursor/readdy 这种订阅周期开始时发放额度或积分的，订阅按天计算退款不合适。
订阅模式是预付费，没有试用期，应该是不支持多个订阅？

6

@HaibaraDP 每个产品不一样 国外有些产品就是要退还费用 还是看你的定位 。有些 VIP 之类的 肯定是取消自动续费 当前已生效的不退还

7

@HaibaraDP 有这些规则的话 也可以考虑是否根据用量模式 stripe 也有 还有你可以规则都是你自己的 你去接 stripe 的 api
他主要是支付工具 订阅模型 可以用他的也可以是你自己的

9

1. 这个时候你自己的系统里面要限制。是否 stripe 能够限制没有研究过。
2. 这个是不可靠，而且顺序次数都不可靠，所以你要选择性的处理一些事件，自己要存库写逻辑。
3. 我的策略是只能有一个订阅，但是多个订阅可以升级降级，升级降级时设置 stripe 将对应的金额进行退费或者收取。

10

@CoderGeek 接 stripe api 的话如何保证调用 api 拿到的是最新的数据呢？感觉不在一个事务内拿到数据无法保证准确啊

11

12

@XTTX 按比例退款不合适（订阅是购买的用量，像 cursor 一样分配额度，不是 claude code 那种），有办法让 stripe 根据我的用量计算吗（定时上报这种不太准确的也行）？第二种创建订阅再退款感觉处理并发和事务很复杂。我用 cursor 接的 stripe mcp ，写的代码都有不满意的地方

13

@HaibaraDP 那你就 1. 创建新的订阅 2. webhook 接创建成功 event ， 查有没有其他有效订阅， 有就取消， 然后在取消成功 event 里再处理退款。 stripe 这么成熟了， 不行你就换一个 AI

14

@XTTX sonnet 4.1 opus 很快就能写出来，但前提是没有并发、分布式事务，尤其是分布式事务，没有银弹，中间遇到超时、停机、快照之类问题很难处理，补偿的逻辑又非常复杂，很浪费时间。可能是我写后端的，考虑的比较多

15

@HaibaraDP 那可真够复杂的了。 以前我还写 go 后台， 现在直接 supabase + edge function+ ts 撸一切。