全球付款系统：从指令生命周期到失败退回

JaxToken原创2026/7/2大约 12 分钟

全球付款系统：从指令生命周期到失败退回

付款系统的第一原则不是快，而是任何重试、超时和未知状态都不能造成重复出款。

为什么值得讨论

付款会经过校验、定价、锁资、渠道受理和最终结算，任何环节都可能失败或处于未知状态。完整状态机决定了系统能否安全恢复。

适合读者：负责 Payout、资金指令、收款人管理、渠道接入或付款风控的团队。

1. 付款业务全景

1.1 典型场景

场景	特点	对时效/成本的敏感度
付海外供应商货款(B2B)	大额、低频、需贸易背景	重成本(汇率+手续费)
全球发薪 / 付佣金	一对多批量、金额中小	重时效与到账体验(全额到账)
付广告费 / SaaS 服务费	定期、收款方固定(Google/Meta 等)	重自动化
电商退款	小额、原路或指定账户	重成功率
付中国供应商(人民币)	出海企业采购、平台代付货款	重合规(贸易背景+申报)

1.2 参与方与角色

商户(付款指令发起方)
   ▼  API / 后台批量文件
跨境支付平台 ── 校验、合规、换汇、计费、路由
   ▼
出款渠道(自有 Nostro 头寸行 / 合作机构 / 聚合服务商)
   ▼  SWIFT / 本地清算 / CIPS
收款人银行账户(全球)

与收款的根本区别：收款是被动的(钱来了再处理)，付款是主动的(平台对指令的最终状态负责)。因此付款业务的核心是指令生命周期管理与状态一致性。

2. 付款指令生命周期(信息流主线)

2.1 状态机

CREATED(已创建)
  → VALIDATED(校验通过:账号格式/必填字段/余额)
  → SCREENING(合规筛查:收款人过名单、交易监控)
       ├─ HIT → PENDING_REVIEW(人工审核)→ 放行 / REJECTED
  → PRICED(报价锁定:汇率+费用,商户确认或自动)
  → FUNDED(资金锁定:扣减商户余额,冻结至出款过渡户)
  → ROUTED(选定渠道)
  → SUBMITTED(已发送渠道)
  → PROCESSING(清算中)
       ├─ SUCCEEDED(渠道确认成功 / 视为成功)
       ├─ FAILED(事前失败:渠道拒绝,资金未出)→ 退回余额
       └─ RETURNED(事后退票:清算后资金退回)→ 退汇处理

2.2 设计要点

幂等：商户侧以 client_order_id 去重;渠道侧以平台流水号防重发。任何重试都不能造成双重出款——这是付款系统的第一军规。
资金先行锁定：进入 FUNDED 前必须完成扣款/冻结，杜绝"指令已出、账上没扣"。
终态谨慎：很多渠道(尤其 SWIFT)没有明确的"成功"回执，只有"已发出 + N 天没退票 = 视为成功"，状态机要支持"推定终态 + 可逆"。
批量与单笔统一模型：批量文件解析后拆为单笔指令处理，批次只是聚合视图。
收款人要素预校验:IBAN 校验位、路由号库、账名匹配(如英国 CoP、印度 penny-drop 验证)，校验前置能大幅降低退票率。
一方提现与三方付款分层:PayoutOrder 增加 first_party 标识(收款人账名与商户主体名称匹配判定，复用预校验的账名匹配能力)。一方提现(付回商户同名自有账户)风险低：简化审核、放宽限额、可豁免贸易背景卡点;三方付款才走完整收款人尽调与贸易背景审核(05 篇：跨境支付合规风控：从 KYB 到交易监控 §4.4)。既降合规成本，也是商户体验的免费提升。

3. 资金流

3.1 商户侧资金来源

模式	说明	适用
余额付款	用收款余额直接对外付款(收付一体的核心价值)	主推：省去一次资金进出
充值付款	商户先汇款充值到平台账户，再发起付款	纯付款客户
授权扣款	从商户绑定银行账户直接扣款(如 ACH debit)	部分市场可用

3.2 平台侧头寸模式

商户余额(平台负债)
   → 出款过渡户(冻结)
   → 平台在各币种头寸行的 Nostro 账户
   → 经清算网络付出

两种头寸策略：

预置头寸(Pre-funding)：提前在各币种头寸行备好资金，出款快但占用资金、有隔夜敞口;
即时头寸(JIT)：换汇成交后 T+0/T+1 调拨，资金效率高但时效受限。

现实是按币种/走廊分层：高频币种预置、长尾币种即时，由头寸管理系统(04 篇：换汇与头寸管理：定价、敞口与流动性的系统解法)统一调度。

4. 路由选择：SWIFT 与本地清算

4.1 两类通道的本质差异

维度	SWIFT(代理行模式)	本地清算(Local Rails)
本质	报文网络，资金靠代理行账户链逐跳划转	直接进入目标国清算体系
覆盖	全球几乎所有银行	仅覆盖单一国家/区域
成本	高(电报费+中转行扣费 10-50 USD/笔)	低(几乎本地转账成本)
时效	1-5 工作日，不确定	秒级~T+1
金额	适合大额	常有单笔上限
到账金额	SHA/BEN 模式下会被中转行扣费，非全额	全额到账
可追踪性	gpi 后有 UETR 全程追踪，但仍不完整	状态明确
接入前提	有代理行/合作行即可	需本地牌照+清算资格，或借助本地合作方

费用承担方式(SWIFT):OUR(付款方承担全部，收款人全额到账，平台需预估中转费)、SHA(共担，最常用)、BEN(收款方承担)。发薪等场景必须支持 OUR 全额到账，涉及"电报费/中转费"计费项。

4.2 智能路由决策因素

输入:目标币种、目标国家、金额、时效要求、商户等级
决策维度:
  ① 可达性:该渠道能否到达目标银行/账户类型
  ② 成本:渠道费 + 预估中转费 + 换汇点差
  ③ 时效:承诺到账时间
  ④ 成功率:该渠道对该走廊的历史成功率
  ⑤ 限额与合规:单笔/单日限额、渠道对行业类目的限制
输出:渠道 + 兜底渠道(失败自动切换 failover)

产品上可让商户选择"经济模式(慢而便宜)/ 快速模式"，对应不同路由策略与计费。

5. 人民币付款专题(CNY / CNH)

平台需支持付款到中国大陆的人民币账户，以及离岸人民币支付。核心概念：

5.1 在岸 CNY 与离岸 CNH

CNH(离岸人民币)：香港等离岸市场的人民币，汇率与在岸 CNY 存在价差，离岸间划转相对自由;
CNY(在岸人民币)：进入中国大陆的人民币，受跨境人民币政策管理，需通过合规通道并申报。

5.2 跨境人民币入境通道

通道	说明
CIPS(人民币跨境支付系统)	跨境人民币清算主干道;平台通常经由 CIPS 间接参与者(境外代理行/清算行)接入
代理行模式	境外银行经境内代理行完成人民币划转
境内持牌合作方	与境内银行/持牌支付机构合作，由其完成入境端的申报与入账

业务规则要点：

贸易背景真实性：付往大陆的货款须具备真实贸易背景(合同、发票、物流单)，收款企业需能配合银行的跨境人民币收款申报;
申报义务：境内收款方涉及国际收支申报(即使是人民币，跨境即申报);
账户类型限制：大陆收款账户为对公账户为主，对私人民币跨境付款(如付个人佣金)政策敏感，需单独评估合规方案;
汇率处理：商户用 USD 余额付 CNY 时，平台按 CNH 或购售价成交，报价引擎需区分 CNY/CNH 两个价格源。

5.3 产品形态

对商户而言体验统一："选择收款人(中国大陆账户)→ 填金额(可按 CNY 计价)→ 平台自动换汇+走合规通道"。复杂度全部封装在路由与合规层。

6. 退票与退汇处理

6.1 三类"付款失败"

类型	时点	资金状态	处理
事前拒绝(Reject)	渠道受理前/受理时	资金未出	解冻退回商户余额，失败原因透出
事后退票(Return)	清算后数日内	资金已出又退回	见 6.2
召回(Recall)	商户主动申请撤回	视清算阶段	尽力而为，SWIFT 靠 MT192/gpi stop

常见退票原因：账号不存在/已销户(ACH R03/R04)、账名不符、收款行拒收、合规拦截。

6.2 退票的关键问题：退回的钱怎么处理

渠道退票入账(通常金额可能有损耗:被扣中转费/汇率变动)
  → 匹配原付款指令(以渠道流水/UETR 关联)
  → 若已换汇:是否反向换汇回原币种?
       方案A:按退回币种原样入商户余额(商户自担汇率风险)——推荐
       方案B:平台垫付按原金额退回(平台承担FX风险)——仅高等级商户
  → 记账 + 通知商户 + 手续费是否退还(政策:渠道费不退,平台费可配置)

退票匹配同样存在"无法自动匹配"的挂账队列，与收款侧共用差错处理框架。

7. 计费功能专题

7.1 计费项(收费什么)

计费项	形式	说明
付款手续费	按笔固定 / 按比例 / 固定+比例	按通道类型差异化(SWIFT 贵、本地便宜)
电报费/中转费(OUR)	按笔固定或实报实销	SWIFT OUR 模式专属
换汇加点(FX Markup)	在中间价/成本价上加 bps	通常是最大收入来源，隐性计费
收款手续费	按比例(如 0.3%-1%)	收款侧，列出以求计费引擎统一
账户/月费	周期性	增值服务(如多用户、API 高级功能)
退票手续费	按笔	转嫁渠道退票成本

7.2 计费模式与时点

实时内扣：从付款金额中扣除(收款人到账 = 金额 - 费用)，适合费用敏感度低的场景;
实时外扣：费用另从余额扣除，收款人全额到账(发薪必备);
账单制(后收费)：按月汇总出账单，对大客户友好，但有坏账风险，需授信管理。

7.3 费率配置模型(计费引擎核心)

费率规则 = f(商户/商户分组, 产品线, 币种对, 通道类型, 金额区间, 时间)
匹配优先级:商户专属价 > 商户分组价 > 标准价
计算类型:固定 | 比例 | 固定+比例 | 阶梯(按月累计量跳档) | Min/Max 封顶

设计要点：

计费与记账分离但联动：计费引擎算出费用 → 生成费用分录进入账务系统，费用本身可追溯到费率规则版本(审计要求);
报价即锁定:PRICED 状态锁定的费用与汇率在有效期内(如 30s~24h)不变，防止"报价与实扣不一致"的客诉;
免费额度与营销：支持新客免费笔数、阶段性折扣，本质是计费规则的时间维度;
对账维度：每月给商户的账单必须能与其每笔交易的费用明细严格对平。

7.4 计费的账务分录(补充 02 篇：全球收款拆解：资金流、信息流与账务流如何对齐框架)

[外扣付款 1000 USD,费 8 USD,电报费 15 USD(OUR)]
  Dr 商户余额-USD            1023
  Cr 出款过渡户-USD          1000
  Cr 平台手续费收入             8
  Cr 电报费预收(负债)          15    → 实际中转费结算后差额转损益

设计取舍

头寸策略：哪些币种预置头寸、敞口限额多大(与 04 篇：换汇与头寸管理：定价、敞口与流动性的系统解法换汇头寸管理联动);
人民币对私付款：是否支持付中国大陆个人账户(佣金/薪酬场景)，合规方案需专项论证;
计费收入结构：显性手续费与隐性 FX 加点的比例策略，影响定价竞争力展示;
账单制授信：是否对大客户开放后付费，风控政策如何定。

核心结论

订单事实、渠道事实和账务事实需要分开建模。
未知状态是常态，必须先查单再重试。
一方提现和三方付款应使用不同的合规与体验策略。

落地检查表

为客户侧和渠道侧分别设计幂等机制
覆盖拒绝、失败、退票、召回和未知状态
验证每个状态迁移对应的锁资与解资动作