2. 支付基础概念
在支付工厂端到端建设项目中，业务人员、产品经理、研发与运维经常在同一场评审里使用“通道”“路由”“订单”“网关”“清算”“结算”这些词，但各自脑中的边界并不一致。概念不统一，直接导致接口设计反复、对账口径冲突、故障定位扯皮。本节把六个核心术语放回真实业务链路中，先建立共同语言，再讨论它们之间的协作关系。
一、核心原理：一笔支付在系统里到底经过了谁
可以把一次支付请求理解为“从用户点击到资金到账”的接力过程。用户发起支付后，最先接触的是支付网关：它负责协议适配、签名验签、参数校验、限流与幂等控制，是外部流量进入支付工厂的统一入口。网关不会直接决定用哪家银行或第三方，它把标准化后的请求交给支付路由。路由根据币种、金额、商户资质、通道成本、成功率、限额、可用余额等因子，选出一条最优支付通道。通道是真正与银行、网联、银联或第三方支付机构对接的链路，包含证书、密钥、报文规范和限额配置。
与此同时，系统会生成一笔支付订单，它是贯穿全链路的主键与状态载体，记录商户单号、支付单号、金额、状态、通道流水号、时间戳等。支付成功后，资金并不会立刻变成商户可用余额，还要经过清算与结算：清算解决“谁欠谁多少钱”，按通道流水、手续费、退款、差错进行净额计算；结算解决“什么时候把钱真正打给谁”，生成结算单并触发打款。二者一个偏计算与核对，一个偏资金划拨与账务落地。
二、方法流程：从请求到资金的可执行路径
把上述概念落到工程实现，通常遵循以下顺序：
- 网关接入：接收商户请求，完成签名验证、参数规范化和幂等键检查，防止重复下单。
- 订单创建：生成支付订单并落库，状态置为“待支付”，同时写入路由所需上下文。
- 路由决策：读取路由规则，结合通道健康度、费率、限额和商户白名单，输出目标通道。
- 通道调用：按通道协议组装报文，发起支付请求，记录通道流水号和原始响应。
- 状态回调：接收异步通知或主动查询，更新订单状态，触发后续账务与通知。
- 清算处理：按日或按批次汇总成功、退款、手续费，生成清算文件并与通道对账。
- 结算出款：根据清算结果生成结算单，经审核后发起打款，完成商户余额入账。
关键设计原则：网关不选路，路由不记账，通道不持有订单状态，订单不直接打款。每个组件只做自己边界内的事，才能让支付工厂在新增通道、调整费率、处理差错时保持可控。
三、案例/场景：一次电商大促支付的成功与失败
某电商大促期间，用户提交订单后，支付网关在 80ms 内完成验签并创建支付订单。路由发现主用通道 A 的成功率从 99% 跌至 82%，自动降级到备用通道 B，支付成功。通道 B 返回的流水号被写入订单，异步回调将状态更新为“支付成功”。
日终清算时，财务发现通道 B 的手续费比预期高 0.1%，且有一笔退款未在通道对账文件中体现。清算系统以支付订单和通道流水为基准进行差错登记，生成差异清单；结算系统暂缓该笔结算，待差错处理完成后再打款。这个案例说明：支付成功不等于结算完成，订单状态与资金状态必须分开管理。
| 概念 | 核心职责 | 关键数据 | 常见故障 |
|---|---|---|---|
| 支付网关 | 统一入口、验签、幂等、限流 | 商户号、签名、请求号 | 验签失败、重复请求 |
| 支付路由 | 选择通道、降级、重试 | 路由规则、成功率、费率 | 选路错误、通道不可用 |
| 支付通道 | 与外部机构通信 | 证书、限额、报文规范 | 超时、限额、证书过期 |
| 支付订单 | 状态主键、链路追踪 | 支付单号、状态、金额 | 状态不一致、重复支付 |
| 清算 | 净额计算、对账、差错 | 流水、手续费、退款 | 长短款、对账不平 |
| 结算 | 打款、入账、结算单 | 结算周期、收款账户 | 打款失败、延迟到账 |
四、误区与复盘：概念混淆带来的真实代价
误区一：把网关当路由用。有些团队在网关里硬编码通道选择逻辑，导致新增通道必须改网关代码，发布风险高。正确做法是网关只做标准化，路由独立配置化。
误区二：用订单状态代替资金状态。订单显示“支付成功”只代表通道受理成功，不代表资金已清算结算。若财务直接按订单状态出款，极易造成垫资或重复打款。
误区三：清算与结算混为一谈。清算关注“算得对不对”，结算关注“打得准不准”。把两者合并，会导致差错处理时无法区分是计算错误还是打款错误。
复盘要点：支付工厂的稳定性不仅取决于代码质量，更取决于概念边界是否清晰。建议在项目启动阶段就输出一张“概念职责矩阵”，明确每个术语的输入、输出、状态和责任人，并在接口文档、对账文件、运维手册中保持一致口径。
掌握这六个基础概念后，后续讨论通道接入、路由策略、订单状态机、清结算规则时，团队才能在同一张图上对话，避免“各说各话”的返工成本。