关于连续订阅的业务设计

124 天前
 aababc

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

2920 次点击
所在节点    程序员
26 条回复
tomatocici2333
124 天前
不需要定时任务吧,每次去计算到期时间的时候动态计算到期时间,有赠送时间就加上。
tomatocici2333
124 天前
@tomatocici2333 要是业务上需要单独去更新赠送时间 直接去动态扣除就好,赠送时间优先级大于正常结束时间
LucasLee92
124 天前
用户带状态,并且存过期时间,每天轮训一天过期时间更新状态即可
至于用户时长怎么来的,可以设计一张流水表存下即可(包括支付、赠送的)
aababc
124 天前
@tomatocici2333 这里有个问题,假设用户过期很久了,突然送几天时长就有问题
klo424
124 天前
没接过,想问一下 apple/google 的自动订阅不能服务端主动推给用户赠送时间,也叠加到 expires_date_ms 中吗?
LoNeZ
124 天前
不要用他们的时间... 自己转一下 赠送了 xx 时长, 区分会员失效期和订阅失效期.
aababc
124 天前
@klo424 #5 这个应该是不行的
fengYH8080
124 天前
订阅模式跟赠送时长底层逻辑上就有冲突,逼着别人把订阅关了去用赠送的,不然一直订阅的人根本用不上,而一旦有取消订阅的动机就代表用户已经准备脱坑,要么就是下单订阅然后立刻取消订阅薅羊毛。只能说做产品也是要经过大脑的,还不如搞些优惠券来得实际。
至于技术方案,这种方式的核心逻辑越单一越好,产品是无时无刻不在变化,维护越复杂的核心逻辑最终会导致产品的发展而写越多的特殊情况。建议只维护一个到期时间,购买订阅或者订阅自动扣费回调等其他所有形式的增加时长通过消费唯一凭证去处理,过期了就按当前时间加,未到期就叠加。
然而你说的为了方便用 expires_date_ms 作为过期时间,我看不出为啥会方便,订阅的到期时间只是其中一种支付方式的属性,为啥要跟系统的核心体系的过期时间挂钩。
gfreezy
124 天前
@fengYH8080 +1 。我们也是类似的实现,只要订阅没关,所有赠送的时长都永远用不上
tomatocici2333
124 天前
@aababc 过期很久送天数,那就不能用之前的时间的,应该用客户登录的日期。把天数赠送触发在长时间未登录第一次登录上 or 手动领取时间
wetalk
124 天前
不太清楚 apple 、Google 订阅规则,我们的订阅对接微信和支付宝,用户签约后,每个周期的扣费由我们主动发起的,例如本月已经扣费过了,用户参加活动获得 7 天时长,下次扣费时间顺延 7 天就行。
用户获得时长的明细,和用户到期时间,二者应该分开,到期时间作为一个指针,在每条明细之间切换。
linauror
124 天前
只通过 expires_date_ms 计算续费了多久,比如 X 天,然后把天数加到到期日期上,赠送天数也再次加到到期日期上
aababc
124 天前
@fengYH8080 关于 expires_date_ms 可以理解为在订阅的场景中,我们直接使用了 这个自动作为自己系统的过期时间,是两个独立属性
aababc
124 天前
@gfreezy 是的,现在的设计就是,只要订阅不关闭,赠送的永远也用不上
aababc
124 天前
@fengYH8080 #8 你的这个关于 订阅和赠送本质上又冲突,我是认同的,但是奈何产品就是要有赠送这个业务,有时候也是难评。这里最开始确实是想只使用到期时间,但是 apple/google 的业务场景上有 restore(恢复购买), upgrade(升级订阅), 而且我现在看是不能获取到订阅时长(也就是这次订阅是多长时间的)。关于使用 expires_data_ms 作为过期时间,我想表达的意思是在订阅的场景下会使用这个值作为用户的过期时间字段的值。
aababc
124 天前
@gfreezy #9 这里有一个问题,是如何处理 restore 和退费的。我最开始也是按照单一的到期时间来处理的,后来发现后续的越来越复杂。
gfreezy
124 天前
restore 并不会影响 expire time 。expire time 只受 3 个因素影响:
1. 自动扣费成功,延长时间
2. 退款完成,扣减时间
3. 其他类似赠送、单次购买等


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

@aababc
htxy1985
124 天前
感觉这是一个产品问题
aababc
124 天前
@gfreezy #17 看来在这一块经验比较丰富了,我第一次做 apple 的订阅相关的内容。还有几个问题咨询一下,比如我想知道一次订阅的时长应该怎么计算,是否可以使用 expires_date - purchase_date ,还有这个 restore 是不是可以理解只需要处理 latest_receipt_info 中日期最大的时间。还有这个我看 apple 文档上些的 续订的时候会在扣款不成功的时候在几天内重复,那这时候这个 expires_date 的时间会不会变?
GXD
124 天前
我们的方案是做了两个到期时间,购买的订阅使用 google/apple 提供的 expires_date ,赠送的免费时长叠加到后面。赠送的截止日期根据 购买订阅 的(续订/到期/退款/暂停/宽限期)等不同行为动态调整,然后保存变更历史

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1055568

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX