如何设计统一支付网关架构以应对在线支付系列挑战？

在线支付系列（五）：统一支付网关架构设计 这是在线支付系列的最后一篇。前四篇里，我们分别搞定了支付宝、微信支付、Stripe 和 PayPal。如果你真的一篇一篇跟着做了下来，你的代码库里大概率已经出现了这样的场景—— 一、噩梦的开始 小陈是一家跨境电商的后端工程师。过去三个月，他依次接入了支付宝、微信支付、Stripe 和 PayPal，每接一个都花了一两周。他觉得自己挺厉害的——四种支付全搞定了。 直到有一天早上，他打开了工作群： 产品经理：支付宝回调好像有问题，昨晚有几笔订单没到账 运营：微信退款怎么还没处理？ 老板：PayPal 那边有个争议需要处理，你看看 财务：这个月的对账差了 3 笔，帮忙查查是哪个渠道的 小陈盯着屏幕发呆。四套支付渠道，四种签名机制，四种回调格式，四套退款逻辑，四份对账文件。每次改一个公共逻辑（比如加个日志字段），他得改四个地方。每次排查问题，他得在四套代码之间来回跳。 他突然意识到：接入四个渠道不是终点，而是噩梦的开始。 这正是「统一支付网关」要解决的问题。 二、思考：到底哪些东西可以统一？ 在动手之前，小陈做了一张表，把四个渠道的差异摊开来看： 维度 支付宝 微信支付 Stripe PayPal 金额单位 元（字符串 "99.99"） 分（整数 9999） 分（整数 9999） 元（字符串 "99.99"） 签名方式 RSA2（SHA-256） HMAC-SHA256 HMAC-SHA256 调 API 验签 回调格式 form 表单 JSON + XML JSON JSON 回调响应 返回 "success" 返回 {"code":"SUCCESS"} 返回 HTTP 200 返回 HTTP 200 退款接口 同步返回结果 异步回调通知 同步返回结果 同步返回结果 认证方式 应用私钥签名 商户证书 + API Key Secret Key OAuth 2.0 差异这么大，还能统一吗？ 小陈画了一张图后发现：差异在细节，但流程是相通的。 每笔支付不管走哪个渠道，本质上都是这几步： 创建订单 → 调用渠道下单 → 等待用户支付 → 接收回调 → 更新状态 → 通知业务 ↓ （可选）退款 → 对账 所以策略很清楚了：流程统一，差异下沉。