在复杂的订阅规则下支付后端如何设计？

[cinlen]

我没有支付后端相关设计、编码经验。请教一下：

假设付费点是 a,b,c：

• 有月订阅制，每个月发放 100 个 a ，用不完可一直向后叠加
• 可单独购买套餐增加 a,b,c(例如学生套餐 10 个 a, 优惠套餐 30 个 a, 企业套餐 100 个 a)，套餐有时效性。
• 不定时活动，例如邀请好友注册可以免费领取 a 或 b 或 c 。
• 签到 n 天可以领取 a 或 b 或 c 。
• 新人注册免费体验 10 个 a 或 b 或 c 。
• 不定时发放的优惠券或 xx 优惠券，可以按 5 折(或其他折扣) 购买套餐。 有的券可叠加，有的券不可叠加。
• 早鸟价购买某套餐，立减 xx 元。
• 618 大促活动，在指定时间范围内购买的，都可以有优惠。

比如 a 是游戏道具数量，b 是游戏里的财富，c 是 xx 等等。a,b,c 不是绑定在一起的，可以单独购买。有的可以累加到下个月，有的有时效性过期清空。

在这种非常复杂的体系下，要怎么去做后端设计？ 包括：

• 如何做数据库表设计才能应对这么复杂的订阅规则？
• 如何做编码设计才能少改动代码来适应将来的新营销活动、订阅规则（有什么设计模式之类的吗？）
• 要注意哪些坑？

[needpp]

请教 ai 更加靠谱和周全

[hytex]

其实你已经分出来了
可拆分为功能和套餐，套餐可以关联功能，功能可再分为次数和时长。专门拿一张表记录下当前用户对应功能的到期时间或次数。如果功能可叠加，则在当前表再进行类型的区分，在功能鉴权或者新增时长或次数时进行判断并进行相关的处理。
不定时活动/签到/注册可约等于领取对应的功能的次数或者时长

发放优惠券作为前置条件进行判断
早鸟套餐也可以当作优惠券（早鸟优惠券）

指定时间范围内购买则为套餐的定时上下线时间

[yidinghe]

根据你描述，ABC 没有本质区别，所以可以放一张表，用类型字段区分即可，当然你一定要分不同的表，问题也不大。下面只说 A 好了。

你的核心问题是 A 的额度、期限与增减。方式是这样：

A 的进账每笔都要记下来，包括该用户本次进账的额度、来源、过期时间（可为空）、消费优先级、已消费额度（初始为 0 ）、是否已完全消费（方便减少计算量）。

当查询剩余 A 额度时，将所有未完全消费的记录的进账额度减去已消费额度然后合并起来即可。

当进行 A 消费时，根据消费优先级扣减一条或多条记录，如果扣完则更新改记录的完全消费标记即可。

优惠券只影响支付金额，不影响最终的 A 进账额度，所以不需要考虑。

[xuanbg]

不是，你卖的套餐和支付有什么关系？？？无非就是用户选择购买一种或多种套餐，然后支付成功套餐的「权益」生效而已。

在技术实现上就是业务调用支付接口，成功后支付服务回调业务系统激活订单中购买的套餐，将套餐权益赋予用户。

[xuanbg]

一张权益表，一张套餐表和一张套餐权益关系表。这个是基础数据，交给运营去维护。

一张订单表和一张订单明细表，里面保存订单购买的套餐 id 。

最后，一张用户权益表，这个是业务的核心数据，用户有什么权益看这一张表就够了。里面的数据来自于付款成功后的订单购买的套餐。