2. 支付核心概念：交易、订单、流水、账户、对账、清结算基础解析

在支付中间件落地之前，必须统一团队对支付领域基础概念的认知。交易、订单、流水、账户、对账、清结算这六个概念构成了支付系统的数据骨架。任何一个概念的定义模糊，都会导致后续对账不平、资金差错、系统耦合混乱。

2.1 六大核心概念全景

下表从定义、生命周期、存储特征、典型场景四个维度，对这六个概念进行横向对比：

2.2 交易与订单：业务与资金的桥梁

交易（Transaction） 是支付系统的最小业务单元。一次交易包含交易金额、交易时间、支付渠道、交易状态等核心字段。交易记录一旦生成，原则上不允许修改，只允许通过冲正或退款产生新的交易。

订单（Order） 是交易的上层业务载体。一个订单可以对应多笔交易（例如：一次支付 + 一次退款）。订单状态驱动着整个业务流转，而交易状态只反映资金层面的结果。

// 交易与订单的典型数据结构（简化）
// 订单表
{
  "order_id": "ORD20250321001",
  "user_id": "U10086",
  "total_amount": 29900,       // 单位：分
  "status": "PAID",            // 待支付/已支付/已退款
  "items": [{"sku": "A001", "price": 19900}, {"sku": "B002", "price": 10000}]
}

// 交易表
{
  "trade_id": "T20250321001",
  "order_id": "ORD20250321001",
  "channel": "wechat_pay",
  "amount": 29900,
  "trade_status": "SUCCESS",   // 支付中/成功/失败/退款
  "channel_trade_no": "wx_20250321_xxxxx",
  "created_at": "2025-03-21 10:30:00"
}

2.3 流水：资金的不可篡改轨迹

流水（Ledger / Journal） 是支付系统中最接近“证据”的数据。每一笔资金从 A 到 B 的移动，都必须产生一条流水记录。流水具有以下特征：

• 只追加（Append-Only）：流水一旦写入，不允许修改或删除。
• 双向记账：一笔支付至少产生两条流水——借方流水（用户扣款）和贷方流水（商户入账）。
• 全局唯一：流水号通常由发号器生成，保证全局有序。

流水与交易的关系：交易是业务视角，流水是会计视角。一笔交易成功，必然对应一组流水；但流水也可能在交易失败时产生（例如：冻结流水）。

// 流水记录示例（复式记账风格）
[
  {
    "流水号": "JNL_20250321_0001",
    "账户": "用户钱包-10086",
    "方向": "借",
    "金额": 29900,
    "余额": 500000,
    "关联交易": "T20250321001",
    "摘要": "支付-购买商品"
  },
  {
    "流水号": "JNL_20250321_0002",
    "账户": "商户账户-20001",
    "方向": "贷",
    "金额": 29900,
    "余额": 1200000,
    "关联交易": "T20250321001",
    "摘要": "支付-商品销售入账"
  }
]

2.4 账户：资金归属与余额管理

账户（Account） 是资金的容器。支付中间件中的账户体系通常分为：

• 用户账户：余额、冻结金额、可用金额。
• 商户账户：待结算金额、可提现金额、保证金。
• 平台账户：手续费收入、营销补贴、备付金。
• 银行账户：渠道侧资金池映射。

账户余额的更新必须通过流水驱动，严禁直接修改余额字段。典型的更新流程是：

1. 读取当前账户余额（带行锁）。
2. 写入流水记录。
3. 更新余额 = 原余额 ± 变动金额。
4. 提交事务。

2.5 对账：资金一致性的守护者

对账（Reconciliation） 是支付系统中最容易被忽视、但出错后代价最高的环节。对账的核心目标是：确保我方记录与渠道方记录一致。

对账流程通常分为三个步骤：

对账的粒度决定了系统的可靠性：

• 日终对账：T+1 对前一日所有交易进行全量比对。
• 实时对账：对单笔交易进行即时回调校验（非严格对账，仅做状态确认）。
• 资金对账：核对银行账户余额与系统账户余额的差值。

2.6 清结算：资金流转的终点

清结算（Clearing & Settlement） 是支付流程的最后一环，也是资金真正到账的环节。

• 清算（Clearing）：计算各方应收应付金额。例如：用户支付 100 元，扣除手续费 0.6 元，商户应收 99.4 元。
• 结算（Settlement）：根据清算结果，执行资金划拨。通常由支付机构向银行发起结算指令，将资金从备付金账户划入商户银行账户。

清结算的核心数据模型：

// 清算结果示例
{
  "settlement_id": "STL_20250322_001",
  "merchant_id": "M20001",
  "period": "2025-03-21",
  "total_trade_amount": 50000000,   // 总交易额 50 万
  "total_fee": 300000,              // 总手续费 3000 元
  "net_settle_amount": 49700000,    // 净结算金额 49.7 万
  "status": "PENDING_SETTLE"        // 待结算/结算中/已结算
}

2.7 六大概念关系图

下图展示了交易、订单、流水、账户、对账、清结算之间的数据流转关系：

2.8 企业级落地要点

在支付中间件中落地这六个概念时，需要关注以下设计原则：

• 数据隔离：交易、订单、流水、账户使用独立的数据库或分库，避免相互影响。
• 幂等设计：交易和流水必须支持幂等，防止重复支付或重复记账。
• 最终一致性：对账和清结算允许短暂的不一致，但必须在 T+1 内修复。
• 可追溯性：每一笔资金变动都能通过流水号追溯到原始交易和订单。