支付系统设计实战架构思维与踩坑心得从零接入支付 SDK 到上线稳定运行聊聊那些比写代码更重要的设计决策。前言最近独立负责了一个后端支付系统的 SDK 集成工作。回头看整个过程真正花时间的不是写代码——HTTP 调一下、回调接一下、签名验一下几天就写完了。真正耗时的是搞清楚三个问题支付网关和后端是什么关系客户端、后端、支付网关谁跟谁说话钱到了但货没发出去怎么办一、先搞清楚谁是谁任何一个支付系统至少有三个角色客户端 ──── 游戏后端 ──── 支付网关 ──── 微信/支付宝问题的起点永远是边界在哪里目前一般大众化的方式是分开部署服务只管什么不管什么支付网关封装微信/支付宝/Steam 等多渠道差异玩家背包、道具、订单履约后端商品定价、订单管理、发放物品支付渠道的签名算法、证书管理一个很常见的反模式(一开始我也以为是)是把支付网关做成后端的一个子模块。短期虽省事长期耦合到死——渠道换一个回调格式游戏后端就得跟着发版。核心原则支付网关是支付网关游戏后端是后端。它们通过 HTTP 说话仅此而已。二、谁跟谁说话两种架构的取舍这是整个设计阶段最值得纠结的问题。方案 A客户端直连支付网关客户端拿到支付参数──直接调──► 支付网关 ──► 微信 │ 回调后端后端只做两件事下单告诉客户端 “用这些参数去支付”收回调支付网关通知 “钱到了”验签发货方案 B后端全代理客户端 ──► 后端 ──代理调──► 支付网关 ──► 微信 ▲ │ └────── 回调 ─────────┘所有跟支付网关的交互由游戏后端代理客户端只跟后端说话。怎么选维度方案 A方案 B后端复杂度低高客户端复杂度中低后端负载低高多一跳代理适合场景移动端 AppH5 / 对客户端代码无控制权当前也有不同的选择需要根据环境具体分析。个人可能觉得A方案合适些后端工作小很多。移动端 App 集成微信/支付宝 SDK 是标准操作客户端的复杂度本来就在那里不需要后端再包一层。后端的职责是下单 收回调而不是当代理。决策的核心不是哪个更好而是哪个更适合你的场景。三、两条支付路径——不要混在一起这点容易被忽略但其实非常关键系统里其实有两条完全不同的支付路径。路径 1用户真金白银买创建订单 → 调支付网关 → 返回 pay_params → 客户端拉起支付 → 支付网关回调 → 验签 → 更新订单 → 发放奖励路径 2运营直接发不花钱创建订单 → 跳过支付网关 → 直接标记已支付 → 发放奖励两个路径走到最后都是发货但中间完全不同用户购买运营发放真扣钱✅❌走支付网关✅❌要验签✅ RSA2❌ 内部认证典型场景玩家买钻石补偿、补发、迁移为什么不混在一起因为它们的失败模式不一样用户购买怕的是“付了钱没拿到货”最严重的事故运营发放怕的是“发多了/发错了”内部操作风险如果混在一个函数里if isAdmin { skip }时间长了必出 bug——可能是运营操作走了支付验证也可能是一个本该验签的入口被绕过了。分开设计各自独立我觉得是更安全的做法。四、签名验签——安全的底线为什么需要两层验签一开始我也以为验签1次不是基本就OK了吗。微信自己不就已经验签了吗为什么支付网关回调后端还要再验一次微信 ──验签①──► 支付网关 ──验签②──► 后端答案验签①保护的是支付网关不被假微信骗②保护的是后端不被假支付网关骗。信任域不同不能互相替代。RSA2 验签的原理整个验签就四步但每一步都可能踩坑参数字典 → 按 key 排序 → k1v1k2v2 → SHA256 → RSA 公钥验签排序是坑必须用 ASCII 码排序不是字典序。AppId和app_id的顺序不一样。空值是坑空值参数要不要参与签名这个要和支付网关对齐。一般规则是空值跳过——但如果你跳过而对方没跳过签名就对不上。编码是坑kvkv里面的值要不要 URL 编码也是一致性问题。验签失败 90% 是因为 “我拼接的字符串和你拼接的字符串不一样”。排查技巧打印签名前的原始字符串跟对方对比一秒钟就能定位。微信支付 V3 的自动验签微信支付 V3 有个很实用的能力AutoVerifySign()。它会自动下载和更新微信平台证书你不用自己管证书过期的问题。但注意——这只是微信 ↔ 支付网关之间的验签。支付网关 ↔ 后端之间的 RSA2 验签还是得自己写。五、发货——最难的不是发是一定能发到回调失败的真实场景支付网关回调你的时候什么情况都可能发生网络超时支付网关发了你没收到你收到了但处理到一半 Redis 挂了你发物品的时候用户仓库服务超时了同一个订单回调了你三次支付网关重试四道防线靠一重保障远远不够需要层层兜底第一道实时发货 └─ 回调中同步处理。失败 → 记日志 告警 第二道异步重试 └─ 失败消息进 MQ延迟重试指数退避1s → 5s → 30s → 5min 第三道定时对账 └─ 每天凌晨拉支付网关账单跟本地发货记录比对 「支付成功但没发货记录」的全部捞出来 第四道人工兜底 └─ 运营后台一键补发有个容易被忽略的点回调处理失败时要不要给支付网关返回失败答案是不要。返回{code: 0}让支付网关停止重试。然后把失败订单写入自己的重试队列自己控制节奏。否则支付网关会疯狂重试把你的服务打得更死。幂等——回调三次跟回调一次结果一样// 最简单的幂等查状态order:db.Find(orderID)iforder.StatusPAID{returnnil// 已经处理过了直接返回成功}// 加锁 → 处理 → 更新状态核心思路状态本身就是幂等键。设计状态机的时候已支付到已发货必须是单向的不可逆。六、代码组织——三层够用别过度设计项目里我用的分层server/ → HTTP Handler解析参数、验签、返回 JSON biz/ → 业务逻辑创建订单、更新状态、发奖编排 repo/ → 数据层数据库读写自己封装对支付网关的 HTTP 调用。七、踩过的坑坑 1回调地址拼错了回调地址其实是从三个地方拼出来的网关域名 路由前缀 回调路径。三个配置散落在不同文件里很容易改漏。后来才知道其实早就在 CI 配置和 API 网关路由里配好了只需要确认。教训回调地址这种关键配置最好一个地方集中管理不要到处散落。坑 2签名排序不一致Go 里sort.Strings()是字典序Java 里TreeMap也是字典序——但 Python 的sorted()默认也是字典序。看起来都一样对吧但如果 key 里有大写字母和数字混在一起不同语言的 ASCII 排序行为可能不同。验签失败的时候打印原始字符串跟支付网关侧对比1 分钟就能定位。坑 3日志记了但查不到一开始日志里没有统一的order_id查问题的时候要从用户 ID、时间戳各种字段拼凑。后来强制所有支付相关日志必须带order_id一行 grep 就能串起整条链路。教训日志不是记了就行要能grep 一条 ID 串起来。八、架构思维总结回过头看整个支付模块的开发写代码大概只占 30%。剩下 70% 的时间花在思考占比搞清楚项目边界和服务间关系20%选择正确的架构方案A vs B15%设计失败兜底策略重试 对账20%排查和调试签名、回调路径15%做支付最重要的三个意识安全第一验签不能省、不能简化、不能先上线再补兜底意识没有任何一个系统是 100% 可靠的——网络会断、服务会挂、回调会丢。必须有一个当一切失败时怎么办的答案可观测性出了问题能快速定位比不出问题更重要因为一定会出问题总结支付系统的核心不是怎么写而是怎么不丢。每一笔订单背后都是一个付了钱的真实用户——做支付敬畏心比技术重要。