3. 支付聚合场景分析：多支付渠道的API差异与聚合支付核心流程
在聚合支付系统中，核心挑战在于统一管理多个支付渠道（、支付宝、银联）的API差异，同时保证交易的一致性和可靠性。本章将深入分析三大主流支付渠道的接口差异，并拆解聚合支付的标准核心流程。
3.1 三大支付渠道API核心差异对比
支付、支付宝和银联在线支付在接口设计、签名机制、回调通知、退款逻辑等方面存在显著差异。下表从契约校验角度归纳了关键差异点：
| 对比维度 | 支付 | 支付宝 | 银联在线支付 |
|---|---|---|---|
| 接口协议 | XML + HTTPS | JSON + HTTPS | XML + HTTPS（部分场景REST） |
| 签名算法 | HMAC-SHA256 / MD5 | RSA2 (SHA256WithRSA) | SHA-1 / SHA-256 + 证书 |
| 支付请求参数 | appid、mch_id、nonce_str、sign、body、out_trade_no、total_fee、spbill_create_ip、notify_url、trade_type | app_id、method、charset、sign、sign_type、timestamp、version、biz_content（含out_trade_no、total_amount、subject、product_code） | version、encoding、certId、txnType、txnSubType、merId、orderId、txnTime、txnAmt、currencyCode、backUrl、signature |
| 金额单位 | 分（整数） | 元（小数，两位精度） | 分（整数） |
| 异步通知 | POST + XML，需返回“SUCCESS”/“FAIL” | POST + JSON，需返回“success”/“failure” | POST + XML，需返回“ok”/“error” |
| 退款接口 | 需使用证书（p12） | 无需证书，使用应用私钥签名 | 需使用证书（pfx） |
| 订单查询 | 通过out_trade_no或transaction_id | 通过out_trade_no或trade_no | 通过orderId或queryId |
契约校验要点： 聚合层必须为每个渠道维护独立的参数映射模板和签名器。金额单位转换（元 ↔ 分）是高频错误点，建议在聚合层统一使用“分”作为内部存储单位，在请求渠道API时按需转换。
3.2 聚合支付核心流程拆解
一个标准的聚合支付流程通常包含以下六个核心阶段，每个阶段都涉及渠道适配与契约校验：
- 订单创建与路由： 商户系统提交统一订单，聚合层根据支付方式（扫码、JSAPI、APP）和渠道规则（如金额上限、商户号配置）选择目标渠道。
- 参数组装与签名： 聚合层将统一订单参数转换为目标渠道要求的格式，并调用对应渠道的签名器生成签名。
- 发起支付请求： 通过HTTP客户端向渠道API发送请求，并处理同步响应（如返回支付链接、二维码内容或交易凭证）。
- 异步通知处理： 接收渠道的支付结果回调，验证签名、校验订单状态，并更新内部订单状态。
- 订单查询与对账： 提供统一查询接口，支持按内部订单号或渠道订单号查询；日终对账时拉取渠道账单进行逐笔匹配。
- 退款与逆向流程： 发起退款请求，处理部分退款、全额退款及退款结果通知。
设计建议： 在聚合层引入“渠道适配器”模式（Channel Adapter），每个渠道实现统一的接口（如
pay()、query()、refund()、parseNotify()），将渠道差异隔离在适配器内部，上层业务无需感知具体渠道逻辑。
3.3 聚合支付核心流程架构图
下图展示了聚合支付系统在标准交易流程中的核心组件与数据流转关系：
3.4 异步通知处理流程对比
异步通知是支付流程中最容易出现契约校验失败的环节。三大渠道在通知机制上的差异如下：
| 特性 | 支付 | 支付宝 | 银联 |
|---|---|---|---|
| 通知方式 | POST + XML | POST + JSON | POST + XML |
| 签名验证 | 验证sign字段（MD5/HMAC-SHA256） | 验证sign字段（RSA2） | 验证signature字段（证书验签） |
| 重复通知 | 可能重复，需做幂等处理 | 可能重复，需做幂等处理 | 可能重复，需做幂等处理 |
| 成功响应 | 返回“SUCCESS” | 返回“success” | 返回“ok” |
| 失败响应 | 返回“FAIL” | 返回“failure” | 返回“error” |
| 通知超时 | 最多重试9次（间隔递增） | 最多重试7次（间隔递增） | 最多重试5次（间隔递增） |
常见陷阱： 部分开发者在处理通知时，直接使用支付宝的验签逻辑，导致签名校验失败。聚合层必须为每个渠道实现独立的验签器，并严格区分响应格式（XML vs JSON）。另外，通知处理接口必须实现幂等性，防止重复通知导致订单状态被多次更新。
3.5 聚合支付统一订单模型设计
为了屏蔽渠道差异，聚合层需要设计一个统一的内部订单模型，该模型应包含以下核心字段：
// 聚合支付统一订单模型（核心字段）
{
"orderId": "2025032100012345", // 内部订单号（唯一）
"merchantId": "M10086", // 商户编号
"channel": "WECHAT", // 目标渠道：WECHAT / ALIPAY / UNIONPAY
"payMethod": "JSAPI", // 支付方式：JSAPI / NATIVE / APP / H5
"subject": "商品名称",
"totalAmount": 1000, // 总金额（单位：分）
"currency": "CNY",
"status": "WAITING_PAY", // 内部状态：WAITING_PAY / PAID / REFUNDING / REFUNDED / CLOSED
"channelOrderId": "", // 渠道订单号（支付成功后回填）
"notifyUrl": "https://.../notify",
"returnUrl": "https://.../return",
"extraParams": {}, // 渠道特定扩展参数
"createdAt": 1711000000,
"updatedAt": 1711000000
}
契约校验实践： 在聚合层入口处，对统一订单进行契约校验（必填字段、金额范围、支付方式合法性），校验通过后再进行渠道路由。这样可以提前拦截无效请求，避免无效调用渠道API造成资源浪费和错误响应。
3.6 渠道路由策略
聚合支付系统需要根据业务规则动态选择支付渠道。常见的路由策略包括：
- 固定路由： 根据商户配置固定使用某个渠道（如仅支持支付）。
- 金额路由： 小额（< 5000元）走/支付宝，大额走银联（银联通常支持更高的单笔限额）。
- 优先级路由： 按渠道优先级排序，优先调用费率低的渠道，失败时自动切换备用渠道。
- 用户路由： 根据用户设备（iOS/Android）或用户偏好选择渠道（如支付宝在淘宝场景优先）。
路由决策应在聚合引擎中完成，并将决策结果（目标渠道、支付方式）传递给对应的渠道适配器。