支付系统核心领域模型与交易链路解析

在所有的互联网后端系统中，支付系统是对“数据一致性”和“鲁棒性”要求最严苛的领域。一笔资金的流转，往往需要跨越内部的业务线、交易中台、支付网关，以及外部的网联、银联和各大银行。

构建支付系统的第一步，是理清最基础的业务概念和单据模型。

1. 核心概念：支付、清算与结算

很多人容易混淆支付、清算和结算的边界。在行业标准中，它们的定义有着严格的先后顺序：

• 支付（Payment）： 资金从付款方到收款方转移的指令流转过程。例如用户在收银台点击确认，支付系统将扣款指令发送给银行。
• 清算（Clearing）： 俗称“算账”。算清楚整个支付过程中，各个参与方（业务线、支付公司、渠道方、商户）的应付、应收金额，生成清算对账单。
• 结算（Settlement）： 俗称“给钱”。根据清算的结果，完成实际的账户余额变动和资金转移。

以快捷支付为例，完整的资金流通常伴随着“断直连”后的网联清算体系：

1. 用户扣款： 用户A使用银行卡支付 -> 支付公司上送指令 -> 网联 -> 开户行A扣减余额。
2. 网联清算（资金流）： 银行A在央行的备付金/清算账户 -> 划拨至支付公司在央行的清算账户（ACS账户）。
3. 商家结算（资金流）： 支付公司通过网联 -> 划拨至商户B的开户行B账户，完成最终结算。

2. 单据数据模型：一笔订单的衍生

在支付域，绝对不能用一张表打天下。标准的支付单据模型通常是分层的：

• 交易单（Trade Order）： 面向业务。记录买卖双方的交易信息（谁买了什么，花了多少钱）。
• 支付单（Payment Order）： 面向支付核心。记录这笔交易的支付动作（用什么方式，支付了多少钱）。
• 收款单 / 内部单（Channel Order）： 面向底层通道。收款单对应外部支付工具（如微信、银行卡），内部单对应内部支付工具（如余额、营销抵扣）。

它们的关系与演进：

• 1 个交易单 -> N 个支付单： 因为用户可能会支付失败后重试，或者中途取消更换支付方式。每一次新的收银台拉起动作，都应该生成一张新的支付单。
• 1 个支付单 -> 1 个收款单 + N 个内部单： 常见的组合支付场景。例如一笔 100 元的订单，用户使用了 10 元内部余额（内部单） + 90 元银行卡快捷支付（收款单）。

3. 核心挑战：状态流转与并发控制

单据状态机的设计，是支付系统稳定性的基石。通常的流转方向是自下而上的：底层收款单成功 -> 驱动支付单成功 -> 驱动交易单成功。

线上环境最容易出问题的，是超时关单与支付异步回调发生的并发碰撞。

场景：网关回调通知支付成功，但此时交易系统发现订单刚好超时。

为了防止资金损失（用户钱扣了，但订单关闭没发货），支付回调交易的流程必须严格遵循以下校验逻辑：

1. 加锁： 根据交易单号加分布式锁，锁住该笔交易单。
2. 校验交易单状态：
   • 情况 A（交易单已成功）： 对比交易单关联的支付 ID 与当前回调的支付单 ID。如果不一致，说明用户发生了重复支付，立刻触发退款流程；如果一致，则是通道的重复通知，直接忽略并返回成功。
   • 情况 B（交易单已关单）： 用户钱已经扣除，但订单已失效。立刻触发关单退款，把钱原路退回给用户。
   • 情况 C（处理中，但已到关单时间）： 不推进订单状态，直接触发关单退款。

通过对单据状态机的严格校验和悲观锁控制，才能在极端网络延迟下，守住资金安全的底线。

返回博客列表