关于连续订阅的业务设计

[aababc]

老铁们，我又来求助了，公司在做出海的业务，需要对接 apple/google 的自动订阅，订阅的回调每次都会有一个 expires_date_ms 的结束时间告诉我们订阅啥时间结束。为了方便我们会直接使用这个 expires_date_ms 作为用户的到期时间，但是产品又希望能做一些优惠活动比如赠送用户时长。现在遇到的问题就是如何协调 apple/google 订阅的到期时间和自己赠送的时长。我们现在的技术方案是使用两个字段来存储，一个是到期时间一个是赠送的时长，判断如果用户到期了但是又有赠送时长，就使用当前时间+赠送的订阅时长作为用户新的到期时间，这里还需要一个定时脚本来扣减赠送时长。但是个人总觉得这种方案不够优秀，看看大家有没有更好的方案

[tomatocici2333]

不需要定时任务吧，每次去计算到期时间的时候动态计算到期时间，有赠送时间就加上。

[tomatocici2333]

@tomatocici2333 要是业务上需要单独去更新赠送时间 直接去动态扣除就好，赠送时间优先级大于正常结束时间

[LucasLee92]

用户带状态，并且存过期时间，每天轮训一天过期时间更新状态即可
至于用户时长怎么来的，可以设计一张流水表存下即可（包括支付、赠送的）

[aababc]

@tomatocici2333 这里有个问题，假设用户过期很久了，突然送几天时长就有问题

[klo424]

没接过，想问一下 apple/google 的自动订阅不能服务端主动推给用户赠送时间，也叠加到 expires_date_ms 中吗？

[LoNeZ]

不要用他们的时间... 自己转一下 赠送了 xx 时长, 区分会员失效期和订阅失效期.

[aababc]

@klo424 #5 这个应该是不行的

[fengYH8080]

订阅模式跟赠送时长底层逻辑上就有冲突，逼着别人把订阅关了去用赠送的，不然一直订阅的人根本用不上，而一旦有取消订阅的动机就代表用户已经准备脱坑，要么就是下单订阅然后立刻取消订阅薅羊毛。只能说做产品也是要经过大脑的，还不如搞些优惠券来得实际。
至于技术方案，这种方式的核心逻辑越单一越好，产品是无时无刻不在变化，维护越复杂的核心逻辑最终会导致产品的发展而写越多的特殊情况。建议只维护一个到期时间，购买订阅或者订阅自动扣费回调等其他所有形式的增加时长通过消费唯一凭证去处理，过期了就按当前时间加，未到期就叠加。
然而你说的为了方便用 expires_date_ms 作为过期时间，我看不出为啥会方便，订阅的到期时间只是其中一种支付方式的属性，为啥要跟系统的核心体系的过期时间挂钩。

[gfreezy]

@fengYH8080 +1 。我们也是类似的实现，只要订阅没关，所有赠送的时长都永远用不上

[tomatocici2333]

@aababc 过期很久送天数，那就不能用之前的时间的，应该用客户登录的日期。把天数赠送触发在长时间未登录第一次登录上 or 手动领取时间

[wetalk]

不太清楚 apple 、Google 订阅规则，我们的订阅对接微信和支付宝，用户签约后，每个周期的扣费由我们主动发起的，例如本月已经扣费过了，用户参加活动获得 7 天时长，下次扣费时间顺延 7 天就行。
用户获得时长的明细，和用户到期时间，二者应该分开，到期时间作为一个指针，在每条明细之间切换。

[linauror]

只通过 expires_date_ms 计算续费了多久,比如 X 天，然后把天数加到到期日期上，赠送天数也再次加到到期日期上

[aababc]

@fengYH8080 关于 expires_date_ms 可以理解为在订阅的场景中，我们直接使用了 这个自动作为自己系统的过期时间，是两个独立属性

[aababc]

@gfreezy 是的，现在的设计就是，只要订阅不关闭，赠送的永远也用不上

[aababc]

@fengYH8080 #8 你的这个关于 订阅和赠送本质上又冲突，我是认同的，但是奈何产品就是要有赠送这个业务，有时候也是难评。这里最开始确实是想只使用到期时间，但是 apple/google 的业务场景上有 restore(恢复购买), upgrade(升级订阅), 而且我现在看是不能获取到订阅时长（也就是这次订阅是多长时间的)。关于使用 expires_data_ms 作为过期时间，我想表达的意思是在订阅的场景下会使用这个值作为用户的过期时间字段的值。

[aababc]

@gfreezy #9 这里有一个问题，是如何处理 restore 和退费的。我最开始也是按照单一的到期时间来处理的，后来发现后续的越来越复杂。

[gfreezy]

restore 并不会影响 expire time 。expire time 只受 3 个因素影响：
1. 自动扣费成功，延长时间
2. 退款完成，扣减时间
3. 其他类似赠送、单次购买等


如果说切换账号 restore ，这是另外一个问题了。原来的账号要如何处理，是否要作废掉？新账号怎么算？

@aababc

[htxy1985]

感觉这是一个产品问题

[aababc]

@gfreezy #17 看来在这一块经验比较丰富了，我第一次做 apple 的订阅相关的内容。还有几个问题咨询一下，比如我想知道一次订阅的时长应该怎么计算，是否可以使用 expires_date - purchase_date ，还有这个 restore 是不是可以理解只需要处理 latest_receipt_info 中日期最大的时间。还有这个我看 apple 文档上些的 续订的时候会在扣款不成功的时候在几天内重复，那这时候这个 expires_date 的时间会不会变？

[GXD]

我们的方案是做了两个到期时间，购买的订阅使用 google/apple 提供的 expires_date ，赠送的免费时长叠加到后面。赠送的截止日期根据 购买订阅 的（续订/到期/退款/暂停/宽限期）等不同行为动态调整，然后保存变更历史

[iosyyy]

@aababc #4 那就把过期时间设为 now+赠送时间呗
也就是说你这个加的时间起点应该是从订阅时间结束算的
如果订阅时间已经结束代表是一个新的订阅周期开始那就把时间调到现在变成 现在+订阅时间

[gfreezy]

@aababc 不记得细节了，只参与了设计，没写具体的代码。
但是 expire date 和扣费肯定是一致的，扣费成功 expire date 延长，扣费失败，expire date 不变。

是否可以使用 expires_date - purchase_date

这个应该是不行的。purchase date 不是开始时间。自动续费的时候一般会在周期结束前几天扣款。

我记得我们好像是固定死 31 天，这样实现比较简单（相当于没有 31 天的月份多送用户几天）

[encro]

@gfreezy

微信读书也就这样，我订阅没关，赠送 vip 已经超过过半年了。没用。。。

[aababc]

@gfreezy 感谢，我再梳理一下看看，感觉还是有点糊涂，头大！

[aababc]

@GXD #20 感谢，我看看大家的这几种方案，那个比较合适

[diagnostics]

获取赠送时长的时候增加一个 expired_date_ms = 订阅的 expires_date_ms + 赠送时间 ms

没有订阅的时候就是 expired_date_ms = now + 赠送时间 ms

判断过期的时候，遍历现有的所有 expired_date_ms 取最大值

多个赠送的时候，遍历现有的所有 expired_date_ms 取最大值 + 赠送时间的 ms

中途取消订阅的时候，比较复杂，那就直接取消订阅一起把赠送的取消（产品设计上辅助开发）不就行了吗？不行的话，那就是取出最大赠送时间的 expired_date_ms - 减去当前时间，得到剩余赠送。或者另一个设计就是吧每个赠送时间单独成一个策略主体，这个时候可能需要单独计算每个策略的赠送时间。


-------------------------

或者重构设计，过期时间是计数的设计，每到 XX 时候，调度把时间减去 YY 时间。有订阅优先扣订阅，无订阅扣最近的赠送时间。。。