支付订单状态机与领域建模工程 - 第1节
1. 支付系统概述
1.1.1 聚合支付的定义
聚合支付（Aggregated Payment），又称“第四方支付”，是指通过一个统一的支付服务平台，将多家支付机构（如支付、支付宝、银联云闪付、Apple Pay、银行卡收单等）的支付接口进行技术整合，为商户提供一站式支付接入、对账、结算与增值服务的解决方案。聚合支付本身不持有支付牌照，不触碰资金清算，核心在于“连接”与“聚合”。
关键特征： 一个商户二维码，支持多种支付方式；一套 API 对接，覆盖全渠道；一个管理后台，完成统一对账与报表。
1.1.2 核心价值矩阵
| 价值维度 | 具体说明 | 受益方 |
|---|---|---|
| 降低接入成本 | 商户只需对接一次聚合支付 SDK/API，即可获得所有主流支付渠道能力，避免逐个渠道重复开发 | 中小商户、ISV |
| 提升收银效率 | 一码多扫、智能路由、自动对账，减少人工操作与差错率 | 收银员、财务 |
| 数据统一沉淀 | 所有渠道交易数据集中存储，便于经营分析、会员营销与风控建模 | 运营、管理层 |
| 资金管理灵活 | 支持 T+0/T+1 结算、分账、代发，满足连锁、平台类商户复杂资金需求 | 财务、资金管理 |
| 用户体验一致 | 消费者无论使用哪种支付工具，均获得一致的支付交互流程与结果反馈 | 终端消费者 |
1.2 典型业务场景
1.2.1 线下扫码支付（最核心场景）
消费者在实体店使用、支付宝、银联云闪付等 App 扫描商户聚合二维码完成支付。聚合支付系统需识别用户所用渠道，并路由至对应支付网关。
- 主扫模式： 商户收银台生成聚合二维码，消费者主动扫码支付。
- 被扫模式： 消费者出示付款码，商户用扫码枪/盒子识别并发起扣款。
- 刷脸支付： 聚合终端调用人脸识别设备，完成支付验证。
1.2.2 线上 H5/小程序支付
商户在自有 App、公众号、小程序或 PC 网页中嵌入聚合支付 SDK，用户选择支付方式后跳转至对应渠道完成支付。系统需处理渠道回调、订单状态同步与超时关单。
1.2.3 商户资金管理（分账与结算）
平台型商户（如外卖平台、连锁门店）需要将一笔交易资金按比例分给多个收款方。聚合支付系统提供分账指令下发、分账结果查询与结算单生成能力。
场景示例： 一笔 100 元的订单，平台抽佣 10%，门店收款 90%，聚合支付系统需在结算时自动完成分账，并生成双方可查的对账单。
1.3 系统边界与核心模块
1.3.1 聚合支付系统的边界
聚合支付系统处于“商户端”与“支付渠道端”之间，不直接处理资金清算，而是作为技术中台完成以下职责：
- 上游： 对接商户收银系统、商户管理后台、商户 App/小程序。
- 下游： 对接支付、支付宝、银联、银行收单等支付渠道网关。
- 内部： 包含订单中心、支付路由、对账中心、商户中心、风控引擎等核心模块。
1.3.2 核心模块清单
| 模块名称 | 职责描述 | 状态机关注点 |
|---|---|---|
| 支付订单中心 | 管理支付订单的创建、状态流转、超时处理 | 订单状态机（待支付→支付中→成功/失败/关闭） |
| 支付路由引擎 | 根据渠道费率、成功率、商户配置选择最优支付渠道 | 路由策略状态（可用/降级/熔断） |
| 对账中心 | 每日与各渠道进行交易流水比对，处理长款、短款、差错 | 对账批次状态机（待对账→对账中→已对账→差错处理） |
| 商户中心 | 管理商户入驻、费率配置、结算账户、API 密钥 | 商户状态（正常/冻结/注销） |
| 结算中心 | 生成结算单、执行分账、发起代付指令 | 结算单状态机（待结算→结算中→已结算/失败） |
1.4 聚合支付系统架构总览
下图展示了聚合支付系统的核心模块与外部交互关系，帮助理解后续状态机设计所处的上下文位置。
1.5 聚合支付与支付渠道的交互流程
为了更清晰地理解支付订单状态机的触发条件，下图展示了聚合支付系统与支付渠道之间的典型交互时序。