2、移动支付基础概念：支付、清算、结算、账户、交易、订单、流水等核心术语的定义与区别

移动支付体系看似复杂，但拆解到最底层，无非是“账户”与“交易”的交互。无论是扫码支付、App 内免密支付还是 NFC 闪付，其背后都遵循一套严谨的金融语义体系。理解支付、清算、结算、账户、交易、订单、流水这些核心术语，是构建支付系统架构、排查交易异常、设计对账逻辑的基石。本章将逐一拆解这些概念的本质、边界与关联，帮助你在业务与技术之间建立清晰的映射。

2.1 核心术语定义与边界

2.1.1 支付（Payment）

定义：支付是付款人为了获取商品或服务，主动向收款人转移货币价值的行为动作。在移动支付场景中，支付通常指用户通过手机等移动终端发起、授权并完成资金转移的整个过程，包括身份认证、支付工具选择、交易指令发送等环节。

核心特征：

• 行为属性：支付是一个“动作”，强调用户的主观意愿和操作过程。
• 实时性：支付动作本身是实时的，用户点击“确认支付”到收到结果反馈通常在秒级完成。
• 多要素组合：支付包含支付工具（银行卡、余额、花呗等）、支付渠道（微信、支付宝、银联等）、认证方式（密码、指纹、人脸）等要素。

2.1.2 清算（Clearing）

定义：清算是支付完成后，参与交易的各方（如发卡行、收单机构、清算组织、商户）之间计算应收应付债权债务关系的过程。清算不涉及实际资金划拨，而是“算账”——确定谁欠谁多少钱。

关键要点：

• 时间维度：清算通常按日终（T+0日终）或批次进行，将当日所有交易汇总。
• 轧差（Netting）：多方之间通过抵消债权债务，只计算净额。例如，A银行应支付给清算组织100万，同时应收80万，则净支付20万。
• 参与方：清算组织（如银联、网联）是核心，负责收集各成员机构的交易数据，计算净额并生成清算报表。

2.1.3 结算（Settlement）

定义：结算是根据清算结果，实际完成资金从付款方账户划转到收款方账户的过程。结算是资金转移的“最后一公里”，完成后债权债务关系才真正消灭。

结算方式：

• 全额结算（RTGS）：逐笔实时完成资金划拨，适用于大额、紧急支付。
• 净额结算（DNS）：按轧差后的净额进行划拨，适用于小额、高频的零售支付场景。

2.1.4 账户（Account）

定义：账户是记录资金所有权、余额变动及交易明细的载体。在移动支付体系中，账户分为用户账户（余额账户、银行卡账户）、商户账户、平台内部账户（如备付金账户、手续费收入账户）等。

账户核心属性：

• 余额（Balance）：当前可用资金总额。
• 冻结金额（Frozen）：因交易进行中、风控限制等原因被锁定的资金。
• 可用余额（Available）：实际可支配资金 = 余额 - 冻结金额。
• 币种（Currency）：账户计价的货币类型。

账户设计是支付系统的核心，通常采用“总账+分户账”模式，确保每一笔资金变动都有据可查。

2.1.5 交易（Transaction）

定义：交易是支付行为的系统化记录，是支付系统中一次完整的业务处理单元。每笔交易有唯一的交易号（Transaction ID），记录交易类型（消费、退款、充值、提现等）、金额、时间、渠道、状态等信息。

交易状态机：

创建(CREATED) → 处理中(PROCESSING) → 成功(SUCCESS)
                              ↘ 失败(FAILED)
                              ↘ 关闭(CLOSED)
                              ↘ 退款(REFUNDED)

交易是支付系统对账、风控、审计的基础数据单元。

2.1.6 订单（Order）

定义：订单是业务层面的契约记录，描述用户购买了什么商品或服务、数量、单价、总金额、收货信息等。订单与交易是多对多的关系：一个订单可以对应多笔交易（如部分支付、多次退款），一笔交易也可以关联多个订单（如合并支付）。

2.1.7 流水（Ledger Entry / Flow）

定义：流水是账户余额变动的明细记录，是账户系统的“账本”。每笔流水包含：流水号、账户ID、变动方向（借/贷）、变动金额、变动前余额、变动后余额、交易关联号、时间戳等。

流水与交易的区别：

2.2 术语之间的关系与流转链路

2.2.1 从订单到流水的完整链路

一次典型的移动支付流程，其术语流转如下：

1. 用户下单：生成订单（订单状态：待支付）。
2. 发起支付：用户选择支付工具，系统创建交易（交易状态：处理中）。
3. 账户校验与扣减：系统检查付款账户余额/额度，冻结或扣减资金，生成付款流水。
4. 支付成功：交易状态更新为成功，订单状态更新为已支付。
5. 日终清算：支付机构汇总当日交易，与清算组织进行轧差计算。
6. 资金结算：根据清算净额，通过央行支付系统完成资金划拨，商户账户收到款项，生成收款流水。

2.2.2 案例拆解：一笔100元扫码支付的全过程

场景：用户小李在便利店使用微信支付购买一瓶水，金额10元。商户为“XX便利店”，收单机构为微信支付（财付通）。

复盘要点：

• 用户看到的“支付成功”在第5步即返回，但商户真正收到资金在第8步（T+1）。
• 手续费在结算环节扣除，而非支付环节，这是行业惯例。
• 每一步都有独立的记录（订单、交易、流水），便于后续对账与审计。

2.3 常见误区与设计要点

2.3.1 误区一：混淆“支付成功”与“结算完成”

很多初入支付领域的人将用户端的“支付成功”等同于资金已到商户账。实际上，支付成功仅代表交易链路完成，资金还在清算过程中。若商户在T+0日发起提现，可能面临资金未达账的问题。

2.3.2 误区二：订单与交易混为一谈

订单是业务契约，交易是资金动作。例如，用户下单后可能分多次支付（定金+尾款），或支付后部分退款。若将订单与交易强行一对一，将导致退款、分账等场景无法处理。

2.3.3 误区三：忽略流水的重要性

流水是账户系统的“真相之源”。没有流水，就无法追溯余额变动原因，无法进行日终对账，也无法应对用户投诉和监管审计。任何账户余额变动都必须有对应的流水记录，且流水不可修改、只能冲正。

2.3.4 设计要点总结

• 唯一性：订单号、交易号、流水号必须全局唯一，建议使用分布式ID生成器。
• 状态机：订单、交易、流水各自维护独立状态机，状态流转必须合法且可追踪。
• 幂等性：支付接口必须支持幂等，防止重复扣款。
• 对账机制：每日对账是支付系统的“安”，通过比对交易、流水、清算报表，发现差异并处理。

2.4 术语速查表