2. 支付基础与行业全景

在动手写统一收单与交易编排之前，必须先建立一张“行业地图”。因为支付网关的每一次接口设计、每一笔状态机流转，背后都对应着真实的资金链路和监管约束。理解这些约束，才能判断哪些逻辑必须放在网关层，哪些必须交给渠道或银行处理。

一、核心原理：一笔支付背后的四层结构

从用户点击“确认支付”到商户最终拿到钱，资金和信息并不是一步完成的。可以把整个体系拆成四层：

• 支付层：面向用户，负责发起支付指令，包括银行卡、扫码、钱包、快捷支付等形态。
• 收单层：负责受理商户交易，完成订单创建、渠道路由、结果回执，是支付网关最直接的服务对象。
• 清算层：负责交易数据的清分与对账，计算“谁应该给谁多少钱”，通常由清算机构或银行完成。
• 结算层：负责实际资金划拨，把清算结果变成账户余额变动，最终到达商户结算账户。

这四层中，收单层是支付网关的主战场，清算和结算则决定了资金到账时间和对账口径。很多线上问题，比如“支付成功但商户没到账”，本质上是收单状态与清算结算状态不一致造成的。

二、收单业务：网关真正要解决的问题

收单业务的核心是“受理并确认一笔交易”。对支付网关来说，收单不是简单转发请求，而是要完成以下动作：

1. 订单创建：生成全局唯一支付单号，记录金额、币种、商户、渠道等要素。
2. 渠道路由：根据商户配置、费率、可用性、限额等选择最优支付渠道。
3. 请求编排：把内部统一参数转换为渠道要求的报文格式，完成签名、加密、重试。
4. 结果处理：接收同步返回和异步通知，驱动支付状态机流转。
5. 对账与差错：与渠道账单核对，处理长款、短款、单边账。

其中“渠道路由”和“结果处理”是统一收单平台最容易被低估的部分。渠道越多，参数差异越大，状态回执越不可控，网关的价值就越体现在编排和兜底能力上。

三、清算、结算与备付金：资金到底怎么走

清算和结算经常被混用，但在支付体系里它们有明确分工：

备付金是监管红线中的红线。支付机构不能把客户的钱和自己的钱混在一起，必须集中存管在指定银行，并按比例或全额缴存。对网关系统而言，这意味着：交易状态、清算状态、结算状态必须分开建模，不能用一个“支付成功”字段覆盖所有含义。

四、支付牌照与监管要求：系统设计的边界条件

支付牌照决定了机构能做什么、不能做什么。常见的牌照类型包括银行卡收单、互联网支付、移动电话支付、预付卡受理等。不同牌照对应不同的业务范围和监管要求，直接影响网关的功能边界：

• 商户准入：必须完成实名认证、资质审核、风险评级，网关需要支持商户进件和审核状态管理。
• 交易限额：单笔、单日、单月限额，以及不同商户类型的差异化配置。
• 反洗钱与风控：大额、可疑交易需要上报，网关要预留风控拦截和人工复核入口。
• 数据留存：交易日志、报文、对账文件需要按规定期限保存，且不可篡改。
• 资金隔离：客户资金与自有资金分账管理，系统层面要支持多账户体系。

这些要求落到代码和配置上，通常体现为商户维度的参数模板。例如：

merchant_config:
  merchant_id: "M20240001"
  license_type: "internet_payment"
  settle_account: "6222********1234"
  settle_cycle: "T+1"
  single_limit: 50000
  daily_limit: 200000
  risk_level: "normal"
  notify_url: "https://merchant.example.com/pay/notify"

网关在路由和下单前，必须读取这类配置做校验。如果商户牌照不支持当前交易类型，或者金额超过限额，应该在进入渠道之前就拦截，而不是等渠道返回错误再处理。

五、案例复盘：一次“支付成功但未结算”的排查

某商户反馈：用户支付成功，订单显示已支付，但结算账户没有收到钱。排查路径如下：

1. 查网关支付单：状态为“支付成功”，渠道回执正常。
2. 查清算文件：该笔交易在渠道对账文件中存在，但清分状态为“待处理”。
3. 查结算批次：该商户结算周期为 T+1，但当日批次因备付金账户余额不足被挂起。
4. 查备付金账户：前一日有大额出款，导致存管账户可用余额低于应结算金额。

最终结论不是网关 bug，而是备付金管理和结算批次调度的问题。这个案例说明：支付网关不能只关注“支付成功”，还要把清算、结算、备付金状态纳入统一视图，否则排查会非常低效。

掌握支付体系的分层结构、收单业务的核心动作、清算结算与备付金的区别，以及牌照监管对系统的约束，是后续设计统一收单接口和交易编排引擎的基础。只有先看清行业全景，才能判断哪些能力必须自建，哪些可以依赖渠道，哪些必须为合规留出扩展点。