支付终端显示 Approved 时，商户通常还没有收到银行间结算资金。这个结果只说明一笔 Authorization（授权）请求获批；交易还可能等待 Capture、Clearing（清算）与 Settlement（结算）。
这三个阶段分别回答不同问题：
| 阶段 | 回答的问题 | 系统在做什么 | 银行间资金是否已经划拨 |
| Authorization | 这笔交易现在能不能做 | 实时校验卡片、账户、可用余额或额度与风险条件，返回批准或拒绝 | 通常没有；获批金额可能先占用可用余额或额度 |
| Clearing | 最终应该记哪笔账、谁欠谁多少钱 | 接收并校验交易记录，匹配授权，处理币种、费用、退款和调整，形成成员机构的应收应付 | 不一定；核心结果是清算记录与财务义务 |
| Settlement | 怎样履行已经算清的财务义务 | 计算并报告净头寸，通过约定的结算账户、结算银行或资金系统完成划拨 | 是；资金在参与机构的结算账户之间移动 |
Authorization 通常是实时或近实时消息；Clearing 可以随交易提交，也可以批量处理；Settlement 则取决于卡组织、币种、地区与结算服务的窗口。把三者固定成「毫秒级、夜间跑批、次日到账」容易建立直觉，却不是通用时序。
1. Authorization：先决定这笔交易能不能做
Authorization 的核心是风险与支付能力判断。持卡人在 POS、App 或网页发起付款后，一次典型的在线授权会经过以下参与方：
持卡人（Cardholder）向商户提供卡片或数字化支付凭证。
商户（Merchant）与终端、网关收集金额和受保护的交易数据，向收单机构发起请求。
收单机构（Acquirer）识别商户与交易场景，把授权报文送入相应卡组织或处理网络。
卡组织或转接网络（Card Scheme / Switch）把请求路由到发卡行。
发卡行（Issuer）根据卡片和账户状态、可用余额或额度、持卡人验证信息与风险规则返回批准或拒绝。
批准结果可能使可用余额或授信额度减少，并在账单中显示为 Pending。这不是银行间资金已经划给收单机构，而是发卡行在授权有效范围内为后续请款保留支付能力。SMS（Single Message System）交易可能把 Authorization 与财务信息放在同一条初始消息中，但也不能据此认定商户已经收到结算资金。
发卡行暂时不可用时，谁来决定
部分网络支持 Stand-In Processing（STIP）：当发卡行无法及时响应时，网络依据发卡行预先配置的参数代为批准或拒绝。STIP 不是「断网就放行」，规则可以同时限制金额、频率、交易渠道与风险条件。
| 参数类别 | 可以考虑的条件 | 说明性配置示例 |
| 金额与频率 | 单笔限额、日累计金额、日累计笔数、Debit Card 透支容忍度 | 单笔不超过 200 美元、单日不超过 1000 美元且最多 3 笔；这些数字不是网络默认值 |
| 交易场景 | POS Entry Mode、Card-Not-Present、MCC、ATM、跨境与币种 | 允许 EMV Chip，限制手工输卡、高风险 MCC 或 ATM 取现 |
| 安全与风控 | CVV/CVV2、EMV Cryptogram、Negative File、网络风险评分 | 安全校验失败、卡片命中挂失库或风险评分过高时拒绝 |
| 系统恢复 | 响应超时阈值、特殊客户策略、Advice 生成与重试 | 发卡行恢复后接收 Advice，并补记代授权结果 |
具体责任边界必须看网络规则与成员协议。以 2026 年 4 月版 Visa Core Rules 为例，Issuer 对 Visa STIP 批准或拒绝的交易负责；这不能直接外推成所有卡组织都采用相同责任与争议规则。
2. Clearing：把交易、币种与费用算清楚
Clearing 解决的是「最终应记什么账」。假设一个批次中，一组成员机构的应付为 800 万，另一组成员机构的应收为 750 万，在同一币种和规则口径下抵销后，可能只需要处理 50 万的净头寸，而不是逐笔搬运所有交易本金。
在 DMS（Dual Message System）中，商户在金额确定后执行 Capture，收单侧再提交 Presentment 或 Clearing Record。交易可以日终批量提交，也可以按处理平台的更短周期提交。「Clearing 等于夜间跑批」只描述了一种运营方式。
SMS 的初始 Financial Request 同时携带 Authorization 与 Presentment 信息，收单侧不必再为同一笔购买发送独立的首次请款消息。它仍然需要后续的清算、净额计算与资金结算，也可能出现 Advice、Reversal、退款或调整。SMS 与 DMS 的消息差异可参见《单信息与双信息卡交易：为什么授权成功后还要等待入账》。
第一步：校验记录并匹配原授权
清算记录需要与授权阶段保持一致。Visa 公共规则明确要求 Authorization Request、Authorization Response 与后续 Clearing Record 或 Authorization Reversal 中的可比数据一致；Account Number、Acquiring Identifier、交易金额与 Authorization Code 等字段都可能参与匹配。
只依赖一个较短的 Authorization Code 不足以可靠判重。高并发环境中，系统通常还会组合交易日期、金额、收单机构标识、支付凭证或网络分配的交易引用进行关联。Acquirer Reference Number（ARN）的长度和组成属于网络与报文规范，不能把某一种 23 位结构当成所有卡组织的统一规则。
匹配还要检查请款窗口和金额关系。普通零售、酒店、租车等场景可能采用不同期限与金额容忍规则；Late Presentment、无法匹配授权或超过允许金额，可能改变费用、争议权利或责任。不存在适用于所有卡组织和 MCC 的「普通消费 7～14 天、酒店租车 30 天」统一窗口。
第二步：处理不同币种
跨境交易至少要区分以下币种：
| 币种 | 含义 | 由谁决定或配置 |
| Transaction Currency | 商户标价并经持卡人确认的交易币种 | 商户定价与持卡人的支付指示 |
| Cardholder Billing Currency | 持卡人账户最终入账的币种 | Issuer 与卡产品配置；接受 DCC 时可能直接采用报价币种 |
| Acquirer Settlement Currency | 网络与 Acquirer 结算净头寸使用的币种 | Acquirer、卡组织与具体结算服务约定 |
| Issuer Settlement Currency | 网络与 Issuer 结算净头寸使用的币种 | Issuer、卡组织与具体结算服务约定 |
以 Visa 为例，Original Presentment 必须使用持卡人授权的 Transaction Currency。Acquirer 与 Issuer 的 Settlement Currency 往往是成员参数，不一定逐笔出现在商户提交的清算文件中。
DCC（Dynamic Currency Conversion）与卡组织清算换汇发生在不同位置。DCC 在支付时向持卡人同时展示商户币种和持卡人币种的报价，由持卡人选择；报价包含转换费用。持卡人拒绝 DCC 并按商户币种支付时，后续仍可能由卡组织或 Issuer 在清算、入账环节完成币种转换。
下面沿用一组纯计算示例。它只用于展示币种之间的关系，不代表 Visa、Mastercard 或任何机构的实际汇率与费率：
一位持中国某银行发行、USD 账单币种卡片的持卡人，在英国商户购买标价
100 EUR的电子书。Acquirer Settlement Currency 为 GBP，Issuer Settlement Currency 为 USD。
假设清算换算关系为
1 EUR = 1.08 USD、1 EUR = 0.85 GBP。Issuer 侧本金是
100 EUR × 1.08 = 108.00 USD。Acquirer 侧本金是
100 EUR × 0.85 = 85.00 GBP。
两侧金额属于不同币种的结算头寸，不能直接用 108 USD - 85 GBP 得出一个所谓「汇差」。网络需要在各自币种账簿中应用约定汇率、舍入规则与费用。
第三步：计算 Interchange 与网络费用
Visa 公共规则把 Interchange Fee 定义为 Acquirer 与 Issuer 之间的默认转移价格。实际费率取决于卡组织、地区、产品、MCC、受理方式、交易数据质量和适用的费率计划。把它单纯解释为对 Issuer 坏账风险的补偿并不完整。
继续使用上面的假设算例：若 Issuer 侧适用的 Interchange Fee 仅为演示而设为 1.50% + 0.10 USD，则费用是：
108.00 USD × 1.50% + 0.10 USD = 1.72 USD
网络还可能向 Issuer、Acquirer 或 Processor 收取转接、清算、跨境或其他服务费用。假设 Acquirer 侧费率为 0.15%，费用是 85.00 GBP × 0.15% = 0.1275 GBP；假设 Issuer 侧费率为 0.10%，费用是 108.00 USD × 0.10% = 0.108 USD。这些比例同样只是演示值，真实费用应以合同、费率表与最终清算报告为准。
第四步：轧差并下发结果
清算引擎会汇总当前周期内的请款、退款、贷项、调整、Interchange 与网络费用，形成各成员在每个结算币种下的净应收或净应付。一个简化的 Issuer 侧表达可以写成：
净应付头寸 = 请款本金 + 应付网络费用 - 退款或贷项 - 应收 Interchange
公式中的正负方向会随成员角色、交易类型与网络记账口径变化，不能把它当成通用报文字段。
Clearing 完成后，网络会向参与方提供用途不同的输出：
Issuer 收到交易明细、费用和入账相关记录，用于更新持卡人账单并对账。
Acquirer 收到成功请款、拒绝或退回记录、费用与应收信息，用于收单账务和商户对账。
结算服务收到每个成员、币种与窗口对应的净头寸或结算报告，作为后续资金划拨依据。
不同网络的文件名和处理平台并不通用。Visa 公共规则使用 Clearing Record，并把 VisaNet Settlement Service（VSS）定义为提供净结算头寸与报告的系统；不能据此把 VSS、Mastercard 的处理文件或 ISO 20022 报文当成同一种格式。
3. Settlement：按净头寸完成资金划拨
Settlement 履行 Clearing 已经确定的财务义务。所谓「钱动了」，实际是结算银行或中央银行账簿上的账户余额发生变化，不是每笔消费都单独搬运一笔现金。
卡组织与结算银行分别做什么
卡组织或其结算服务计算净头寸、生成报告，并按结算服务的规则发出资金处理要求。实际资金路径取决于地区、币种、成员资格和银行安排：
| 参与方式 | 机构怎样履行净头寸 | 资金划拨怎样触发 |
| 直接结算 | 成员使用符合要求的指定结算账户，并在 Cut-off 前准备足够流动性 | 结算服务或资金系统按既定授权与结算文件借记、贷记账户 |
| 代理结算 | 成员通过 Settlement Bank、Correspondent Bank 或 Sponsor 等代理安排结算 | 代理机构接收净头寸后，在自己的结算账户中代表成员完成划拨 |
并不存在适用于所有卡组织和国家的单一「卡组中央资金池」结构。Visa 公共规则同时定义了 National Net Settlement Service、International Settlement Service、Settlement Bank 与 Visa Settlement Bank，已经说明结算路径会随服务和地区变化。
银行间资金系统只是可能使用的底层轨道。例如，美国的 Fedwire Funds Service 可以结算金融机构或清算安排形成的头寸，并在 Federal Reserve Bank 主账户中提供付款终局性；欧元区当前使用 T2 在中央银行货币中逐笔实时结算大额支付。T2 于 2023 年 3 月取代 TARGET2，因此继续把现行系统写成 TARGET2 已经过时。
T2 使用 ISO 20022，Fedwire Funds Service 也已经采用 ISO 20022 消息，但这不代表卡组织发给成员的 Clearing Record、Settlement Advice 或报表都采用 ISO 20022。卡网络处理格式与底层资金系统格式需要分别确认。
Issuer、Acquirer 与 Merchant 的最后动作
Issuer 要在结算窗口前准备足够头寸，或确保代理结算安排可以履行净应付。Acquirer 在资金到账后，需要把实际到账金额与卡组织的清算、费用和结算报告核对，完成内部总账核销。
随后才是 Acquirer 或支付服务商向 Merchant 付款。付款可以按 T+1、D+1、实时或其他合同周期执行，也可能先进入商户可用余额，再由商户提现。它属于收单机构与商户之间的 Merchant Settlement，不等同于卡组织已经完成的成员机构结算。
因此，商户后台若只显示一个 Settled，产品与财务团队还要确认它究竟表示「卡组织已结算」「支付服务商余额已可用」，还是「资金已经进入商户银行账户」。这三个状态可能发生在不同时间。
