用积分激励场景化行为，是提升用户留存最高效的路径。

可一搞积分，支付麻烦事就多一堆，一致性、退款、对账、库存锁等等。

不过问题不大，今天，极特就跟大家分享下，混合支付，到底该怎么搞~

业务模型与挑战

混合支付，本质是让一笔交易同时结算两种货币，现金（微信/支付宝，强一致性）与积分（内部资产，弱一致性）。

公式与汇率

混合支付的公式很简单：

订单总额 = 现金支付额 + (消耗积分数 / 兑换汇率)

不过，这里会有两个问题。

• 汇率波动：积分汇率是否动态？下单时100:1，支付时已变成200:1，咋搞？

  • 原则：下单锁定汇率。在创建订单时，将当时的汇率固化在订单数据中

• 抵扣上限：一般不会允许100%积分抵扣，要配置最大抵扣比例（栗如最多抵扣50%）

分布式事务场景

用户点击支付按钮，系统要处理两个事：

• 调用第三方支付网关扣用户的钱

• 调用内部积分服务扣用户的分

两个动作，一个在外部，一个在内部，怎么保证原子性？

• 先扣钱，后扣分？如果钱扣了，分没扣成功（服务挂了），用户白嫖了积分？或者反过来，分扣了，钱没付，用户亏了？

• TCC 还是 Saga？这种高频C端场景，上太重的分布式事务框架，性能扛不住

推荐方案：积分预扣+异步实扣。

交易流程设计

流程围绕用户体验和资金安全，分三步：下单锁分、支付回调、异常回滚。

积分现金混合支付核心流程图

下单锁分

支付成功后再扣积分，会有并发扣减压力和超卖风险。用户提交订单时，调用积分服务进行预扣。

• 成功：订单状态流转为WAIT_PAY，生成支付参数，唤起收银台

• 失败：阻断下单，提示用户

支付回调

用户第三方支付完成支付后，支付网关回调系统。

• 核对金额：确保回调金额与订单现金一致

• 更新订单：状态变更为PAID_SUCCESS

• 实扣积分：异步通知积分服务，将预扣的积分真正扣除

异常回滚

对于下单后一直没支付或主动取消订单的。

• 超时关单：延迟队列触发关单逻辑

• 释放库存：回滚商品库存

• 解冻积分：通知积分服务，将预扣的积分返还用户账户

系统架构分层设计

流程梳理完，接下来就是系统设计。

混合支付系统架构图

• 商城聚合层：计算现金+积分的混合明细

• 订单域：状态机维护，负责交易流转，不处理积分细节

• 积分域：负责积分账户的增删改查、冻结解冻流水

• 支付域：对接微信/支付宝，处理退款和对账

各领域间相互解耦，订单系统不需要知道积分是怎么计算的，只需知道这单要扣多少分。

订单状态机与一致性

混合支付最怕状态不一致，那么，用状态机来约束流转。

混合支付订单状态机

关键状态流转

• CREATED：订单创建

• POINTS_LOCKED ：积分预扣成功，等待付款

• PAID_SUCCESS：钱已到账，积分已扣

• REFUNDED ：退款完成，交易关闭

还有引入补偿机制。遇到支付成功后扣积分失败的，就定时任务不断重试，保证数据最终一致性。

退款

混合支付退款难在分摊。

假设用户买了两件商品：

• 商品A：100元

• 商品B：200元

• 总计300元。用户使用了 3000积分（抵扣30元） + 270元现金

用户只退商品A，系统该退多少钱？多少分？

退款比例计算逻辑

按行分摊原则

金额积分的分摊，在下单的时候，就分摊到每行商品上。

对于商品A（占总价1/3）：

• 应分摊现金：270 * (100/300) = 90元

• 应分摊积分：3000 * (100/300) = 1000分

退款时，直接读取数据库中商品A的实付明细，退90元现金 + 返还1000积分。账目清晰，永不出错。

写在最后

混合支付，考验的是交易系统一致性与清结算能力。做好了是增长引擎，做不好就是财务黑洞。

正常流程谁都能做，否处理好那1%的异常，才是真正分水岭。

真正的架构师，用代码画图。

我把本文同款的 AI 绘图工具包 (MDC规则 + 100款源码) 已上传至知识星球。

加入星球，免费领取。

从此，画出一张企业级架构图，只需要一句话。

▲ 添加微信：JiteStart，获取架构资料

往期推荐

 

AI架构图

别再用手画图了！看看字节研发怎么用AI画图

我是怎么画架构设计图的？

架构设计

通知中心设计：邮件、短信、Push与站内信

敏感词过滤系统的AC自动机设计

智能导购Agent设计

社交排行榜的架构设计：实时排名与周期性更新

软技能

如何向非技术人员讲明白复杂的技术？

如何优雅地拒绝不合理需求？