2. 支付网关基础
支付网关是商户系统与银行/清算网络之间的“交易接入与协议转换层”。它对外提供统一支付API，对内完成报文转换、路由选择、安全校验、结果回执与对账文件生成。理解支付网关，是后续讨论灾备与多活架构的前提：只有先明确它在交易链路中的位置和职责边界，才能判断哪些组件需要双活、哪些数据必须强一致、哪些环节可以降级。
一、支付网关的定义与核心功能
从架构视角看，支付网关不是单一进程，而是一组能力集合。它通常部署在DMZ或独立接入区，向下连接收单系统、风控系统、清算系统与渠道适配层。其核心功能可归纳为以下六类：
- 协议适配：将商户的HTTP/JSON、SDK、文件等接入方式，转换为银行或渠道要求的ISO8583、XML、定长报文等格式。
- 安全与鉴权：完成商户证书验签、校验、敏感字段加密、防重放与限流。
- 路由与渠道路由：根据支付方式、币种、金额、商户等级、渠道健康度选择最优通道。
- 交易编排：串联风控、收单、清算、通知等步骤，管理超时、重试与补偿。
- 结果回执与通知：同步返回受理结果，异步推送最终支付结果，保证商户可感知。
- 对账与文件服务：生成渠道对账文件、商户对账单，支持差错处理与人工补单。
关键认知：支付网关的“受理成功”不等于“扣款成功”。网关返回的通常是受理状态，最终结果依赖渠道异步回执。灾备设计中必须区分“接入层可用”与“资金状态一致”两个目标。
二、交易生命周期：从请求到清算
一笔支付交易在网关内通常经历以下阶段，理解这些阶段有助于识别灾备切换时的断点：
- 接入与鉴权：商户发起请求，网关验签、解密、限流，生成全局交易流水号。
- 风控前置：调用风控系统进行实时规则判断，返回通过、拒绝或人工审核。
- 路由决策：根据渠道健康度、费率、限额选择目标通道，并记录路由快照。
- 渠道交互：向收单/渠道发送支付指令，等待同步应答或异步回执。
- 状态落库：将交易状态写入交易库，状态机通常为“初始化→处理中→成功/失败/未知”。
- 结果通知：通过回调或轮询向商户推送最终状态，失败进入重试队列。
- 清算与对账：日终生成对账文件，与渠道清算系统核对，处理长短款。
其中“未知状态”是灾备场景中最棘手的部分：当网关在渠道交互后、落库前发生故障，交易可能已扣款但本地无记录。多活架构必须通过渠道查询、幂等重试和对账补偿来收敛这类状态。
三、与收单、清算、风控系统的关系
支付网关处于交易链路的“入口”，但它不孤立存在。下表梳理了它与周边系统的职责边界与交互方式：
| 系统 | 核心职责 | 与网关的交互 | 灾备关注点 |
|---|---|---|---|
| 风控系统 | 实时规则、名单、评分、反欺诈 | 同步调用，返回通过/拒绝/审核 | 风控不可用时是否降级放行 |
| 收单系统 | 商户管理、交易受理、资金归集 | 网关将交易转发收单，收单对接渠道 | 收单主备切换与交易幂等 |
| 清算系统 | 日终清算、对账、差错处理 | 网关提供交易流水与对账文件 | 对账文件完整性与时延 |
| 渠道适配层 | 银行/第三方渠道报文转换 | 网关路由后调用适配层 | 渠道健康探测与自动摘除 |
可以看到，网关是“交易编排者”，收单是“资金受理者”，清算是“资金结算者”，风控是“交易守门人”。四者职责不同，灾备策略也不同：风控可降级，收单需幂等，清算需可重放，网关需无状态或会话外置。
四、场景与误区复盘
以一个典型场景说明：某商户发起100元支付，网关验签通过，风控返回通过，路由选择A渠道。网关向A渠道发送指令后，自身数据库主节点宕机。此时渠道已扣款，但网关未落库。若直接切换备节点，商户查询显示“处理中”，渠道回执到达备节点后因无原始流水而无法匹配，形成单边账。
常见误区：认为网关无状态即可随意多活。实际上网关虽可无状态部署，但交易流水、幂等键、路由快照必须持久化且全局可读。否则切换后无法识别重复请求，也无法关联异步回执。
正确的做法包括：交易流水号在接入层生成并全局唯一；落库采用“先写流水再发渠道”或“发渠道前写预登记”；异步回执通过流水号幂等匹配；对账系统每日扫描“处理中”超时交易并主动查询渠道。这些机制共同保证灾备切换后资金状态可收敛。
交易状态机示例：
INIT -> PROCESSING -> SUCCESS
-> FAIL
-> UNKNOWN -> (查询/对账) -> SUCCESS | FAIL
幂等键建议：merchantId + merchantOrderNo + 交易类型
路由快照字段：channelCode, routeTime, ruleVersion综上，支付网关是交易链路的编排中枢，其核心价值在于统一接入、安全转换与状态收敛。理解它与收单、清算、风控的边界，是设计灾备与多活架构的基础：哪些环节可降级、哪些数据必须强一致、哪些状态需要补偿，都取决于本节所梳理的职责划分。