支付是代驾系统里最不能出错的环节。本文梳理一套开源代驾系统在微信、支付宝双通道下的支付下单、回调处理与分润对账设计。
源码地址： gitee.com/zhoujian666…
一、支付下单流程
用户行程结束、系统计价完成后，生成一笔待支付订单：
- 订单写入数据库，状态为“待支付”，记录金额、计价明细
- 根据用户选择的支付方式，调用微信/支付宝统一下单接口，拿到预支付参数
- 用户在小程序/App内完成支付
关键：下单前对订单金额做服务端二次校验，不信任前端传入金额。
二、异步回调是支付成功的唯一依据
用户支付后，微信/支付宝会异步回调系统接口。系统以回调为准：
- 校验回调签名，防止伪造
- 幂等处理：同一笔订单重复回调，只更新一次
- 校验金额与订单金额一致后，把订单置为“已支付”
前端的“支付成功”页面只做展示，真正的状态变更等回调。为防止回调延迟，系统还提供主动查询订单状态的兜底接口。
三、分润逻辑
代驾平台需要在订单收入中与司机结算。支付成功后触发分润：
- 按平台规则（比例或固定）计算平台收入、司机收入
- 生成对应的分润明细、司机账单记录
- 分润与订单状态解耦，通过消息队列异步处理，避免阻塞回调
四、对账设计
资金系统必须可对账。系统按天/按批次做对账：
- 拉取微信/支付宝对账单（或使用账单文件）
- 与系统内支付订单逐笔比对：金额、状态、渠道流水号
- 标记差异：渠道有平台无、平台有渠道无、金额不一致
- 输出对账结果，异常人工介入
五、几个关键取舍
- 一致性：支付状态以渠道为准，回调+主动查询双保险
- 幂等：所有资金接口必须可重复调用而不产生重复入账
- 金额计算：使用最小货币单位（分）用整数运算，避免浮点误差
- 异步解耦：分润、通知等非核心动作走 MQ，保证支付主流程快、稳
项目其他模块
除支付分润外，系统还包含：订单状态机、智能派单（Redis GEO）、Netty WebSocket 实时推送、计价引擎、Redis 分布式锁与缓存、Vue 管理后台。后端 + 管理后台已开源（Java 17 + Spring Boot 2.7），可直接部署。
欢迎评论区交流支付系统设计经验，觉得有用欢迎 Star。
