9 月的第一天，刚卸任苹果 CEO 的库克出门旅行，却忘了带 iPhone 充电头。路过一家沃尔玛，他拿起一个 Anker 充电头，犹豫片刻，还是掏出了 Visa 信用卡。毕竟，iPhone 快没电了。

收银台“滴”了一声，屏幕显示 Approved。库克收起卡，拿走充电头。这笔买卖看起来已经结束了。

但如果此时去查沃尔玛的银行账户，未必能找到刚刚进来的 29.99 美元。银行已经同意这笔消费，商户也交出了商品，钱却还没有走完它的路。为什么沃尔玛敢先交货？后面的银行又凭什么知道该付多少钱？

这笔看似简单的消费，藏着银行卡交易中一个有意思的时间差：顾客只等了几秒钟，后台的收付款却还在继续。我们就跟着这笔消费，看看：

1. 刷卡终端读到了什么，银行据此作出了什么决定？
2. 商户交货之后，交易怎样变成银行账上的记录和实际到账的款项？
3. 如果后来退货，或者持卡人不承认这笔消费，已经完成的交易会怎样处理？
4. 谁提供了这些服务，又从交易中收取了哪些费用？

四方模型

如果库克付的是现金，沃尔玛验过钞票，就可以把它放进钱箱。银行卡却不同：库克的银行卡背后是他的账户，这个账户由另一家机构管理。沃尔玛的收银员既看不到账户余额，也无权决定能否使用那笔信用额度。

于是，买卖双方各自需要一家处理支付的机构。把它们放在一起，就是银行卡交易常见的 四方模型（Four-party Model）：

• 持卡人（Cardholder）：库克，使用银行卡支付货款。
• 商户（Merchant）：沃尔玛，提供商品并接受银行卡付款。
• 发卡机构（Issuer）：向库克发行信用卡，管理他的账户和信用额度，决定是否批准这笔消费。
• 收单机构（Acquirer）：为沃尔玛提供银行卡受理服务，把交易提交出去，并按约定向商户支付货款。它可以与沃尔玛日常存款账户所在的银行不同。

这还留下一个问题：全球有那么多发卡机构，沃尔玛的收单机构难道要逐家谈合作、逐家接系统吗？

卡组织（Card Network / Card Scheme） 解决了这种共同接入的问题。Visa、Mastercard、银联、JCB 等卡组织建立网络，约定交易数据怎样传递、机构之间怎样付款、出了纠纷怎样处理。参与机构接入同一套网络并遵守相应规则，就有了跨机构合作的基础。本例中，连接收单侧和发卡侧的便是 Visa。

可以做一个简单的假设：有 100 家发卡机构、20 家收单机构，如果每一对都单独建立合作关系，就有 2,000 组关系需要维护。接入共同网络后，各机构则可以依照统一的标准接入和协作。这个例子虽然简化了实际的合作安排，但足以说明共同网络的好处：新加入一家机构，不必让所有商户重新改造一次收银系统。

共同标准也不只是让数据传得到。收单侧说这笔消费已经获得批准，发卡侧后来是否认可？商户把相同记录提交了两次，怎样识别？顾客否认消费，双方依据什么材料处理？如果这些事情每次都要临时协商，终端即便能联网，商户也很难放心交货。卡组织的规则使参与机构事先知道自己该做什么，以及没有做好时要承担什么责任。

因此，四方模型中的四方是买卖双方及各自一侧的金融机构，卡组织是连接它们的共同网络。它虽然画在图中央，却不算在“四方”之内。

请求从收银台出发，经收单侧和 Visa 到达发卡侧，批准或拒绝的回答再沿原路返回。

此时往返的是交易信息。机构之间实际怎样付款，还要等后面的财务处理。

这也解释了为什么卡面上的 Visa 标志与发卡银行名称可以同时出现：一个说明这张卡接入哪套网络，另一个说明谁管理持卡人的账户。库克的额度够不够，要由发卡侧判断；沃尔玛出了收款问题，通常先找收单侧。

下面的图列出了四方模型中一些常见参与者。现实中的一家公司可能兼有多种业务，图中按角色归类，是为了方便辨认它在某笔交易中的位置。

四方模型把合作关系画清楚了。接下来还要看看，一张小小的卡片，怎样向这套网络说明自己是谁。

卡里的信息

库克把卡贴近收银台的 POS 终端（Point-of-Sale Terminal）。短短一瞬间，终端与卡片交换了一组数据。不过，知道卡号与确认这张卡可信，是两回事；确认卡片可信与确认正在用卡的人有权付款，也不是同一道检查。

银行卡上那串熟悉的数字，正式名称是 主账号（Primary Account Number，PAN）。它是支付账户的标识。PAN 开头的 6 位或 8 位称为 发卡机构识别号（IIN），行业里也常用 银行识别号（BIN） 这个名称。网络结合这些号码及更细的号段信息，查找对应的发卡侧，把请求送到正确的地方。这个选择转发路径的过程，称为 路由（Routing）。¹

卡面上还可能有持卡人姓名、有效期，以及通常印在背面的 卡面安全码（CVV2/CVC2）。下图展示的是这些信息的位置，卡面数据仅作示意。

这些信息有一个共同特点：一段时间内保持不变。卡号能帮助银行找到账户，但仅凭别人也能抄下来的数字，很难判断终端面前究竟是一张真卡，还是一份复制品。

库克在店里使用实体卡，属于 卡在场（Card Present，CP） 交易。插卡和非接触式拍卡，通常都依照 EMV 芯片支付规范（EMV Chip Specifications） 处理。EMV 约定了卡片和终端如何协作，使不同厂商的设备也能读懂同一张卡。

中国内地常把刷磁条、插芯片和挥卡都笼统叫作 刷卡。其中，银联卡面的 闪付（QuickPass） 表示可以在相应终端进行非接触式支付；符合条件的小额免密免签交易可以不输入 PIN、也不签名，但这只是特定场景下的持卡人验证安排，并不表示终端没有读取芯片数据，也不等于所有银联交易都免密。²

终端与卡片先选择双方支持的支付应用，由 应用标识（AID） 区分；一张卡可能支持多个应用。AID 决定接下来按哪套应用规则交互，PAN 及其号段帮助网络查找账户和发卡侧。选对应用、找到账户，都还不等于确认了卡片可信。

向发卡侧申请本次消费的批准，称为 授权（Authorization）。在需要联机授权的 EMV 交易中，卡片会使用自身的密钥，结合金额、终端提供的不可预测数、卡内交易计数器等数据，计算出 授权请求密码文（Authorization Request Cryptogram，ARQC）。终端把它连同相关交易数据一起送给发卡侧验证。³

密码文可以看作卡片针对本次交易给出的可核验回答。抄下卡号或截获上一笔密码文，不足以直接构造下一笔有效凭证；但它并不把整段通信加密，也不隐藏其中所有账户数据。卡号、PIN 的传输和存储仍需各自的保护机制。

假设库克稍后又买了一个同价的充电头。两次消费都是 29.99 美元，但终端提供的数据和卡内交易计数器已经不同，卡片需要重新计算密码文。正常交易中，终端取得的是计算结果，卡内密钥不会跟着交出来。发卡侧除了验证计算结果，还要结合交易计数和已有记录判断重复提交等情况。动态凭证的作用，正是在每次付款时增加这种可以核验、又与本次交易有关的证据。

银行卡里还保留着服务于不同读取方式的校验值。传统磁条数据中有 磁条校验值（CVV1/CVC1）；Visa 芯片数据中则有 芯片卡校验值（iCVV）。这些名称相近，却不能混用：iCVV 与磁条上的校验值区分开，能帮助发卡侧识别把芯片数据冒充成磁条数据提交的情况。它也不是每笔新生成的 ARQC。⁴

于是，验证一张卡时，既要看 提交了什么值，也要看 声称以什么方式取得它。卡面安全码、磁条校验值、芯片数据及动态密码文，各有对应的使用场景。把一种场景下取得的数据搬到另一种场景，并不能自动获得同等效力。

不过，真卡也可能被偷走，所以还需要考虑 持卡人验证方式（Cardholder Verification Method，CVM）。常见方式包括输入 个人识别码（Personal Identification Number，PIN），也就是用卡密码；某些场景也可能要求签名，或者允许无需持卡人验证。具体采用哪一种，要看卡片、终端、金额及适用规则。

PIN 有两种验证路径：联机 PIN 交给发卡侧校验，脱机 PIN 由卡片芯片本地校验。“脱机”在这里仅说明密码在哪里核验。另有符合卡片、终端和网络规则的 脱机批准，由卡片与终端在无联机授权时作出交易决定；它不同于后文由网络代替发卡侧决定的代授权，也不同于终端先保存请求、联网后再提交。⁵

因此，库克拍卡后没有输入密码，并不意味着银行什么都没检查。卡片可能已经生成动态凭证，终端也记录了本次采用的验证方式。这些结果会一起参与后面的判断。

现在，请求已经能够说明 哪个账户、怎样读的卡、做过哪些验证。剩下的问题是：即使凭证可信，这个账户眼下还有没有足够额度，银行愿不愿意批准这笔消费？这些问题，就要交给发卡侧来判断了。

授权

发卡侧收到请求后，需要把卡片凭证与账户状况放在一起判断：账户能不能用，金额是否可接受，这笔消费看起来是否正常。授权的批准或拒绝，就是综合这些信息得出的结果。

终端把刚才取得的卡片数据，与 29.99 美元的金额、币种、商户名称、终端信息等合在一起，形成授权请求。其中还有一个 商户类别码（MCC），用来表示商户所属的业务类别，例如餐饮、住宿或零售。银行据此了解消费场景，而不是逐件检查购物篮里的商品。

请求还要说明究竟是哪家商户，以及怎样取得卡片数据。商户标识（MID） 用来标识收单关系下的具体商户；卡片输入方式（POS Entry Mode） 则区分插卡、拍卡、手工输入等情形。前者帮助找到交易所属的商户，后者让发卡侧知道应当核验哪些数据。若一笔交易声称使用了芯片，却没有带上相应数据，银行就需要进一步检查这种不一致。

请求从沃尔玛出发，经收单侧和 Visa，到达发卡侧。下面先按正常收到批准的情况，把这几秒钟展开：

sequenceDiagram
    autonumber
    participant CH as 库克
    participant PO as 沃尔玛终端
    participant AC as 收单侧
    participant NW as Visa
    participant IS as 发卡侧

    CH->>PO: 拍卡购买 29.99 美元的充电头
    PO->>AC: 发送金额、商户及卡片数据
    AC->>NW: 提交授权请求
    NW->>IS: 路由至对应发卡侧
    IS->>IS: 验证凭证，检查账户、额度与风险
    IS-->>NW: 批准本次消费
    NW-->>AC: 返回批准结果
    AC-->>PO: 通知授权获批
    PO-->>CH: 显示结果，完成收银

发卡侧的检查大致分为三组。首先是凭证：ARQC 能否通过验证，当前场景要求的持卡人验证是否完成。其次是账户：卡片是否挂失，账户是否受限，可用额度是否足够。最后是风险：消费地点、金额和频率，是否与这个账户平时的使用情况相符。

同样一张真卡，刚刚挂失后再使用，仍然会被拒绝；密码输入正确，也不能让一张额度已用完的卡继续消费。前一章的验证结果提供了证据，授权则把这些证据和账户状况放在一起，作出本次交易的决定。

结果通常用 响应码（Response Code） 表达。常见的 00 表示批准，51 表示余额或额度不足，05 则是较笼统的拒绝。响应码的具体含义及处理要求，要以相应网络和收单接口为准；仅凭一个 05，商户无法判断银行究竟发现了哪一种风险。消费者看到的“付款失败”，也往往比后台记录少了许多细节。

批准时，发卡机构通常会设置 授权占用（Authorization Hold），并返回一个用于后续关联的 授权码（Authorization Code）。假设库克原本还有 1,000 美元可用额度，这次授权占用 29.99 美元后，可用额度便降至 970.01 美元。

此时，银行应用里可能出现一笔“待入账”交易。它表示这部分额度已经留给了本次消费。之后如果商户取消交易，占用可以解除；如果商户确认收款，银行再按后续记录正式入账。对于借记卡，类似的占用作用在账户可用资金上。

占用解决的是这段等待时间里的一个实际问题。假设某张卡只剩 30 美元可用额度，两家商户先后各发来一笔 29.99 美元的请求。第一笔获批后，如果银行没有记下这项占用，第二笔检查时仍可能看到“还有 30 美元”。两家商户都得到了批准，合计金额却已超过可用额度。把已批准的金额及时从可用额度中扣除，后面的请求才能看到更新后的状态。

如果两笔请求同时到达，银行还必须保证：一笔请求检查额度并登记占用时，另一笔不能拿着尚未更新的额度获批。否则，两笔请求都可能读到“还有 30 美元”，造成超额批准。

沃尔玛敢交货，是因为批准对应着有条件的付款义务：商户应在适用期限内，提交金额及关联数据符合要求的财务记录。发卡侧仍需按规则付款，商户也仍需承担交付、退款和争议责任。⁶

这里要区分三个时限：银行保留占用多久、授权批准有效多久、财务记录最迟何时提交。它们不必相同。占用自然释放或“待入账”消失，不等于销售已取消；稍后收到的清算记录仍可能形成正式消费，而迟交或无有效授权可能引发额外费用及争议责任。

把批准与正式财务记录分开，有很实际的用途。网店接单时可以先确认顾客能否付款，等商品出库再确认收款；酒店也不必在客人入住时就猜准最终账单。银行卡系统把这两件事分成两个步骤，称为 双信息模式（Dual-message Model），本文的主线采用的就是这种模式。另有 单信息模式（Single-message Model），在一条交易消息中同时承载授权和财务处理，常见于部分借记卡和 ATM 交易；即使如此，机构间资金划拨也未必在那一秒完成。

充电头的价格在付款前已经确定，所以请求金额和批准金额都是 29.99 美元。换到其他场景，授权需要多一点弹性：

最后一种情形里，充电头仍然卖 29.99 美元，顾客还需要补付 9.99 美元。它与商户给了优惠券是两回事：部分授权改变的是这张卡能够承担多少付款，优惠券改变的则是顾客应付多少。上述能力是否可用，取决于卡产品、商户类别及网络规则。⁷

酒店入住时预计花费 300 美元，先取得 300 美元预授权；续住后预计总额为 400 美元，就关联原授权追加 100 美元。Visa 网络的增量请求表达追加金额，部分服务商接口则要求填写新的总额，不能混用两种口径。退房时实际消费 360 美元，酒店请款 360 美元，并及时部分撤销多余的 40 美元占用。增量授权不会延长原授权有效期；住宿超过适用期限时，还需按收单侧要求撤销并重新授权。⁷

普通购买和预授权都可能占用额度。区别在于，购买充电头时应付金额已经确定，酒店入住时还需要估算。“预授权”的“预”，主要说明最终金额或业务完成情况尚未确定，并不是说其他授权都不会占用额度。

授权链路中一个棘手的情况，是终端一直在转圈，最后提示超时。请求可能根本没有送到发卡侧，也可能已经获批，只是回答丢在了返回途中。

比如，同一次请求可能留下这样两种观察结果：

两边的记录都可能是如实描述各自经历。超时说明商户没有及时拿到回答，不能反推出发卡侧一定没有处理。这也是为什么“结果未知”需要被当成一种待核实的情况，不能直接归入“已拒绝”。

如果收银系统立刻生成一笔全新的请求，发卡侧可能再次批准，于是顾客看到两笔额度占用。实际只买了一个充电头，银行却暂时为两个充电头留了额度。

处理超时，应沿原支付尝试的标识查询结果；销售取消时，再按收单接口发起撤销并核对处理结果。系统还要保证同一次操作被重复提交时，不重复占用或收款，这叫 幂等性（Idempotency）。同一次支付尝试重新发送时，应沿用原来的标识；明确拒绝后换卡重付，则是新的尝试，不能只用订单号把两者当成同一次付款。检查是否重复、执行操作和记下结果，也必须作为一个整体处理，否则并发请求仍可能被重复执行。

银行批准与收银最终完成也可能存在间隔。在适用的终端流程中，卡片移开、用户取消或连接中断，都可能使已获批的交易未完成后续确认，形成“银行有占用、收银台却失败”。因此，排查还要核对终端完成记录。⁸

另有一种可用性安排叫 代授权（Stand-in Processing，STIP）：发卡系统暂时不可用时，卡组织可以在事先约定的条件下，按照发卡方设置的金额、频率和风险限制代为决定。它有助于维持受理，但不表示卡组织会无条件批准所有请求。⁹

无论是核实超时结果，还是继续处理已经获批的交易，都得先认出原来的那笔记录。授权码能说明曾经获得批准，却不是整笔业务在所有系统中的唯一编号。库克的小票、沃尔玛的订单、收单侧的记录和发卡侧的记录，可能各有一套号码。它们需要被关联起来，后面的入账和问题排查才有依据。

在授权记录中，系统跟踪号（STAN）用于跟踪消息，检索参考号（RRN）帮助检索和关联交易；它们的格式、唯一性范围和重复周期由具体网络规定。因此，不能拿一个授权码或 STAN，直接当成永不重复的业务主键。

实际排查时，可以从沃尔玛的订单号找到内部支付记录，再取得收单侧的参考号，最后关联到网络记录。一张订单如果经历过重试，可能对应多条消息；一笔授权如果后来取消了部分金额，也会多出关联记录。订单号回答“顾客买了什么”，消息编号回答“系统这一次传了什么”，把两者分开保存，才不会在异常处理中丢掉来龙去脉。

有了这些记录，沃尔玛还没有真正收到货款。收银结束后，商户需要用它们说明：刚才获批的那笔交易，现在应该正式收取多少钱。

请款、清算与结算

库克走出超市时，沃尔玛已经知道银行愿意批准这笔消费。接下来，商户还需要明确告诉收单侧：“商品已交付，这笔交易最终收取 29.99 美元。”这个确认收款金额并提交后续财务处理的动作，叫 请款（Capture）。¹¹

请款有时由收银系统自动完成，有时需要等业务系统确认发货。商户不一定要另点一次按钮，但后台仍需把“银行批准过”和“商户决定正式收款”区分开。收单系统收到请款后，也可能先记录下来，等约定的批次截止时间（Cut-off Time），再统一提交当批交易。

银行看不到缺货、取消或交付的完整过程，需要商户把最终业务结果变成收款要求。线下收银可以紧接授权自动请款，网店则可能等商品发出后再请款。

这种安排使最终收款金额不必机械地照抄第一次授权金额。网店一张订单中的商品分批出库，在规则允许时可以分次请款；酒店预先占用的金额高于实际房费时，可以按最终账单请款，并通过相应流程释放剩余占用。每笔请款都要与原授权正确关联，金额和提交时间也必须符合要求。否则，银行未必能够把“现在要收的钱”与“当初批准的钱”顺利对应起来。

商户确认了金额，下一步是让各机构取得同一笔交易的正式财务记录。这就是 清算（Clearing）：收单侧提交最终金额、币种、商户信息、授权码和交易参考号等数据，卡组织及相关处理系统进行校验、计算应计费用，再把记录送到发卡侧。发卡机构据此将消费记入持卡人账户，机构之间也由此形成相应的应收应付。¹²

清算记录比一句“请扣 29.99 美元”多得多。发卡侧需要知道它对应哪次批准、最终金额是否符合要求、是否已经处理过相同记录。正确的关联数据让系统能够把商户的最终收款要求，接到先前的授权占用上。少了这层联系，金额相同的两笔消费也可能被认错，或者原占用未解除，正式账单却已经记了进去。

库克在银行应用中看到的变化，通常就是那笔“待入账”变成“已入账”。若金额仍为 29.99 美元，且期间没有其他交易，原先的占用会与正式记账衔接，可用额度仍应是 970.01 美元。这不是在第一次占用之外，再收一次 29.99 美元。 如果两笔记录短暂并存，需要核实的正是授权与入账有没有匹配、占用有没有及时解除。

同一笔消费，此时在不同参与方的账上有不同含义。暂不计手续费，发卡机构记下的是库克需要偿还的 29.99 美元消费，以及自己在机构间需要履行的付款义务；收单侧据收到的财务记录确认应收款项及对商户的应付款项；沃尔玛则在等待销售货款到账。它们记录的是彼此之间的债权债务，所以可以先入账，再按约定时间实际付款。

账上确认了应付金额，还要实际履行付款，这一步叫 结算（Settlement）。结算可以采用全额或净额方式。本例采用卡网络常见的净额安排：卡组织按周期、参与机构和币种汇总清算结果，将应收应付抵销，即 轧差（Netting），得到各机构的 净头寸（Net Position），再通过约定结算账户完成资金划拨。

可以把网络暂时缩小到两家银行，并假设两家都同时提供发卡与收单服务。在同一结算周期内，A 银行的持卡人向 B 银行服务的商户消费了 120,000 美元，其中就包括库克的 29.99 美元；反方向的消费则合计 100,000 美元。暂不计手续费和其他调整：

两边的消费记录合计 220,000 美元，实际只需要划拨 20,000 美元，就能履行这里相互抵销后的资金义务。交易记录仍然逐笔保留，库克的消费不会因为轧差而变成另一种金额。实际网络有更多参与机构，计算也更复杂，但同样需要把单笔交易记录与机构间净资金义务分开处理。

信用卡还有一层时间差：发卡机构必须按网络安排结算，不能等库克还清账单才付款。持卡人不还款所形成的信用风险，通常由发卡侧承担；参与机构未履行结算义务，则属于另一层结算风险。以 Visa 为例，网络按规则提供结算保障，并以信用评估、抵押品等安排管理风险。这些安排也不能免除商户因未交货而承担的争议责任。¹³

到这里，还要分清最后一层：收单机构收到了网络结算资金，和沃尔玛的银行账户收到了货款，是两件事。收单侧按合同向商户付款，属于 商户付款（Merchant Funding / Payout）。付款频率、扣费方式以及需要暂留的款项，都可能影响实际到账时间和金额。

把这几步接起来，可以看到信息与资金在不同阶段各自承担的任务。下图画出一种先完成机构间结算、再向商户付款的常见安排：

sequenceDiagram
    participant ME as 沃尔玛
    participant AC as 收单机构
    participant NW as Visa
    participant IS as 发卡机构
    participant SB as 结算银行

    Note over ME,IS: 授权已经批准
    ME->>AC: 请款，确认收取 29.99 美元
    AC->>NW: 提交清算记录
    NW->>IS: 传递可入账的财务记录
    IS->>IS: 匹配授权，记入持卡人账户
    NW->>NW: 汇总应收应付，计算净头寸
    NW->>SB: 发送结算指令
    SB->>SB: 借记净付款方账户，贷记净收款方账户
    Note over IS,SB: 本例发卡侧净付、收单侧净收；机构可兼有两种业务
    SB-->>AC: 确认收单侧结算结果
    AC->>ME: 按合同支付商户款项

实际付款顺序也可能不同。有些服务商先垫付，有些等网络资金收到后再付款；服务商已发出商户款项，也不等于商户银行账户已经完成入账。因此，“当天到账”本身不能证明底层网络也在当天结算。¹⁴

这条链路也会中断：例如请款接口已接收请求，后续清算却因数据问题失败，或者网络资金迟迟未到。此时要根据异步处理结果和清算报表找到失败环节，修正或核实后再决定是否重提，不能另建一笔无关联消费反复扣款。对已经垫付的交易，后续失败还可能形成商户余额调整。¹⁴

现在再看这些容易混淆的词，就可以分别问一个具体问题：

阶段不同，记录的日期自然也不同。周五晚上完成的消费，可能进入下一批请款；批次跨过了午夜，或者遇到不同的时区，清算报表上的日期又可能变化。机构间结算与商户付款还各自受处理日历和合同影响，不能用收银小票上的日期代替所有后台日期。

报表中的 业务日（Business Date） 是系统归集交易所用的日期，它由处理日历、时区和批次截止时间共同决定，未必在当地午夜切换。理解这一点，才能解释为什么同一笔消费在两份报表上落在不同的一天。

沃尔玛也不会只收到充电头这一笔货款。收单侧可能把当天许多笔销售合在一起，扣去手续费、退还给顾客的款项和其他调整，再支付一个净额。财务人员需要把订单、请款记录、清算明细和银行到账逐层核对，确认哪些已经收齐，哪些还在途中。这项工作就是 对账（Reconciliation）。¹⁵

比如，一家店当天卖出 10 个同价充电头，销售记录应合计 299.90 美元，收单报表的对应批次却只有 9 笔，共 269.91 美元。后面的清算和付款都准确地处理了这 9 笔，只拿收单报表与银行到账比较，可能看不出异常；把销售记录也放进来，才会发现还差一笔 29.99 美元。它可能漏提交了，也可能仍在另一个批次中，需要沿订单和支付记录继续追查。

即使 10 笔都已收齐，到账也不必是 299.90 美元。例如每笔扣费 0.69 美元，当批另扣一笔 29.99 美元退款、暂留准备金 10 美元，则净出款为 299.90 − 6.90 − 29.99 − 10.00 = 253.01 美元。逐笔记录核对有没有遗漏，批次汇总核对各项增减，最后再与银行到账对应；准备金还需在以后释放时继续核对。

至此，一笔正常消费从收银台走到了商户账户。可库克买回去后，如果发现充电头不合用，这条已经走完的路又该怎样处理？

撤销、退款与争议

先把库克放回三个不同的时刻。刚拍完卡，他发现拿错了型号；第二天，他拿着小票来退货；一个月后，他翻到银行账单，表示自己从未买过这个充电头。三种情况都会让人说“把钱退回来”，但支付系统需要采取不同的动作。

第一种情况，如果交易尚未进入后续财务处理，商户可以发起 授权撤销（Authorization Reversal），通知发卡侧取消全部或部分授权占用。此时最主要的变化，是先前被占用的额度重新变得可用。顾客不一定会看到一笔单独的返款记录，也可能只是原来的“待入账”记录消失了。

这也是前文授权超时后可能需要做的事：销售没有继续，就应尽快通知发卡侧解除相应占用，而不是一味等它自然过期。有些收单接口把取消操作称为 撤单（Void），它可能取消尚未处理的请款，也可能触发授权撤销。具体效果要看取消的是哪一阶段的记录，不能仅凭接口名称判断钱是否已经退回。

第二天再来退货时，原消费可能已经请款或入账。这时通常要另发起一笔 退款（Refund），把款项返还到持卡人账户。原消费仍然保留，退款有自己的金额、处理记录和状态，并与原消费建立关联。

从持卡人账务看，退款是一笔 贷记交易（Credit Transaction）：对于信用卡，它可以冲减应还金额；对于借记卡，则可以增加账户余额。这里的“贷记”是记账方向，与银行又发放了一笔贷款无关。商户确认退款，只说明返款流程已经发起，消费者实际看到入账还需要后续处理。¹⁶

若消费和全额退款均正常入账，顾客净支出可以回到零，但原消费与退款两条记录都应保留。对于本文的 Visa 路径，适用退款还需要先发起 退款授权，并可能被发卡侧拒绝；它不能重放原消费的密码文或认证数据。退款请求被接收、退款获批、顾客账户入账，是不同的确认。¹⁷

退款也不必一次退完。已退 10 美元后，剩余可退金额为 19.99 美元。计算时，还要扣除正在处理中的退款；检查和预留可退金额也必须作为一个整体处理，避免两个客服同时操作，合计退多了钱。换卡后原账户仍可能承接退款；若原账户失效或退款授权被拒绝，应联系收单侧，按允许的替代退款流程处理，不能自行任意换一个收款账户。¹⁷

银行卡账户还可能接收与退货无关的付款。例如，企业通过支持的服务，向个人支付报酬。Visa 提供的 原始贷记交易（Original Credit Transaction，OCT） 可把这类款项付入符合条件的卡账户。普通退款要解释“哪次消费应当返还多少”，这类独立付款则有自己的出款依据、接入条件和处理规则。虽然持卡人都可能看到一笔贷记入账，后台需要记录的业务来由并不相同。¹⁸

第三种情况就不同了：库克向发卡机构表示“这笔消费不是我做的”。这属于 争议（Dispute）。本文用它泛指对交易事实或履约情况提出异议的过程；疑问经过核查，符合网络条件时，发卡侧可以发起 拒付（Chargeback），向收单侧追索相应款项。不同卡组织对具体阶段的名称有所差异，但都不能把持卡人的一次询问直接等同于商户已经承担最终损失。

争议也不只限于盗刷。没有收到商品、重复扣款、金额错误、承诺的退款未到账，都可能构成不同的争议理由。网络用 原因码（Reason Code） 区分这些情况，并规定各自需要什么材料、应在多久之内响应。

以“重复扣款”为例，顾客看到两行相同金额，还需要继续核实。它们可能是两笔授权占用，也可能是一笔尚未消失的占用加上一笔正式消费，还可能确实是两笔已经入账的销售。前两种情况要检查占用是否重复、是否应当释放，以及与正式入账是否匹配；若同一次购买被正式收了两次钱，则需要围绕重复收款处理。金额相同只是排查的起点，交易处在哪个阶段同样重要。

商户可以接受追索，也可以经收单侧提交证据 抗辩（Representment）。仍有分歧时，符合条件的一方可发起 预仲裁（Pre-arbitration），由另一方回应；进一步提交 仲裁（Arbitration） 后，才由卡组织依规则裁决。各网络与争议类型并非都依次经过所有阶段，下图只展示一条可能路径。¹⁹

sequenceDiagram
    participant CH as 持卡人
    participant IS as 发卡机构
    participant NW as 卡组织争议系统
    participant AC as 收单机构
    participant ME as 商户

    CH->>IS: 对交易提出异议
    IS->>IS: 核查情况与适用条件
    IS->>NW: 提交争议及相应资金追索
    NW->>AC: 转交案件，按规则调整资金
    AC->>ME: 通知争议原因和举证期限

    alt 商户接受
        ME-->>AC: 接受资金处理
    else 商户抗辩
        ME->>AC: 提供与争议原因对应的证据
        AC->>NW: 提交抗辩材料
        NW->>IS: 转交材料
        IS-->>NW: 接受抗辩，或继续争议
        opt 双方仍有分歧且符合条件
            IS->>NW: 发起预仲裁（此路径示例）
            NW->>AC: 转交主张，收单侧回应
            AC-->>NW: 接受或反驳
            NW-->>IS: 转交回应
            opt 仍有争议且一方申请仲裁
                IS->>NW: 提交仲裁申请（此路径示例）
                NW->>NW: 依据规则及证据裁决
                NW-->>AC: 通知裁决结果
                NW-->>IS: 通知裁决结果
            end
        end
    end

资金往往不等最后一步才发生变化。拒付发起后，相关款项就可能先从收单侧扣回，收单侧再按合同调整商户余额；商户抗辩成功后，款项又可能返还。因此，看到钱被扣回，只能说明发生了资金调整，不能单凭这一条记录判断最终责任。 同样，银行先给持卡人的临时返款，也可能在调查后被调整。

举证应正面回答争议理由：“没买过”要核对卡片验证、终端和消费记录；“没收到”要看交付或签收；“退款没到”则查返款记录。实体卡场景也有适用的 EMV 欺诈责任转移：是否具备芯片受理能力、实际使用何种读取方式、是否发生回退，会影响特定伪卡欺诈损失的承担。芯片证据不能代替交货证据，也不使所有争议自动转给发卡侧。²⁰

回应“退款未到账”，应提供原订单、退款时间、金额、处理结果及可追踪参考号。适用卡交易可向收单侧取得 收单参考号（Acquirer Reference Number，ARN），供持卡人交给发卡侧查询；商户内部退款 ID 未必能被银行识别。一张内部“退款成功”截图，也不能代替对账户入账的核实。²¹

还可以设想，沃尔玛第二天已经发起退款，库克第三天尚未看到入账，于是向银行提出争议。两边都在处理同一次返款，却未必立刻知道对方的进度。此时客服如果再开一笔普通退款，同时又接受拒付，就可能把同一笔钱返还两次。正确的处理需要先把原消费、已发退款和争议案件关联起来，再根据各自状态决定下一步。

这也解释了为什么系统不能只用一个“这笔交易是否退款”的字段包办全部售后。消费可以正常完成，退款可以还在处理中，争议也可以同时处于调查阶段。分别保存这些事实，才能既回答顾客“钱到哪里了”，又核对商户究竟还应付出多少。

还有一种争议，起因可能只是消费者认不出账单。银行账单上用来描述收款方的文字，叫 商户描述（Merchant Descriptor）。库克明明记得去过沃尔玛，账单上却出现一个陌生公司名，就可能把正常消费误认成盗刷。清楚的名称、订单通知和联系方式，能帮助他先找到这笔买卖，而不是直接向银行否认交易。

回过头看，收银台的批准，只回答了当时能不能进行这次消费。事后判断谁应承担损失，还得看当时留下的验证证据和后来发生的事情。实体卡有芯片可以验证；如果库克是在网站上买同一个充电头，银行又能凭什么认出他？

线上支付与凭证安全

如果库克坐在酒店里，用浏览器输入卡号下单，商户就读不到那张实体卡的芯片。这类支付属于 卡不在场（Card Not Present，CNP） 交易。四方之间的授权、清算和结算仍然继续，只是银行用来判断付款人的证据发生了变化。

首先能取得的，是 PAN、有效期和卡面安全码等信息。Visa 常把卡面安全码称为 CVV2，Mastercard 常称为 CVC2。它们与芯片每次计算出的 ARQC 有不同用途：前者可以说明付款人掌握了某些卡片资料，后者用于验证本次芯片交易的数据。卡面资料如果被一起抄走，安全码也可能随之泄露。

因此，线上支付通常还会结合登录账户、设备、网络地址、历史订单和收货信息判断风险。部分市场提供 地址验证服务（Address Verification Service，AVS），由发卡侧比较提交的账单地址或邮编，并返回匹配结果。它可以增加一条判断依据，但地址匹配本身不能证明正在下单的就是库克。²²

中国内地的普通网购则常见 银行卡快捷支付，或者在支付宝、微信支付、云闪付等应用中选择已经绑定的卡。首次绑卡或签约时通常要完成银行要求的身份和账户验证，后续付款再按银行与支付机构约定，结合支付密码、短信动态码、生物识别、设备和风险控制完成验证；用户界面不一定跳转到银行网页。它并非少了验证，只是交互方式不同，也意味着下面的 3DS 流程不能被当作每一笔内地线上银行卡付款的必经步骤。²³

在支持 3DS（EMV 3-D Secure） 的电商支付中，商户可以通过共同协议向发卡侧提交交易和设备信息，取得身份认证结果，再据此决定后续授权处理。它是一种认证安排，并非所有线上银行卡支付的必经步骤。²⁴

商户与银行在这里各有一部分信息。网店知道顾客买了什么、寄到哪里、是否经常在本站购物；发卡机构则掌握卡片和账户的历史，也有自己与持卡人联系、验证身份的渠道。3DS 使双方能够在付款前交换所需数据，让银行利用这些信息判断，而不必要求每一家网店自行核实所有银行卡用户的身份。

这套交换也需要解决 找到对应银行 的问题。商户侧的 3DS 服务器先把请求交给 目录服务器（DS），由它找到对应发卡侧的 访问控制服务器（ACS）。ACS 是发卡侧处理这次认证的系统角色，负责判断是否需要顾客补充验证、采用什么方式，并形成认证结果。这样，商户接入一套共同协议，就能与不同发卡侧的认证系统协作。

有些认证在后台就能完成，称为 无感认证（Frictionless Flow）。例如，发卡侧认为已有数据足以判断，顾客便不需要额外操作。需要补充验证时，则进入 挑战认证（Challenge Flow），要求顾客在银行页面或应用中输入一次性验证码、进行生物识别，或者完成其他指定操作。

无感与挑战描述的是交互路径，不是成功与失败。没有验证码页面，也可能做过认证；完成页面操作，也还要读取最终结果。结果可能是通过、拒绝、无法完成或已进行尝试处理，后两类不能当成认证成功；能否继续授权取决于结果、网络规则及适用要求。例如 R 表示发卡侧拒绝认证并要求不再尝试授权。²⁵

下面省略 3DS 内部的服务节点，只看顾客、商户与发卡侧之间发生了什么：

sequenceDiagram
    participant CH as 库克
    participant ME as 商户及其 3DS 服务
    participant IA as 发卡侧认证系统
    participant AU as 后续银行卡授权

    CH->>ME: 提交订单与付款信息
    ME->>IA: 通过 3DS 提交交易、账户及设备数据
    IA->>IA: 判断是否需要额外验证
    alt 无感认证
        IA-->>ME: 返回认证结果
    else 挑战认证
        IA-->>CH: 要求验证码或其他身份验证
        CH->>IA: 完成指定操作
        IA-->>ME: 通过 3DS 返回最终认证结果
    end
    alt 结果及适用规则允许继续
        ME->>AU: 携带相应认证数据申请授权
        AU-->>ME: 返回批准或拒绝
    else 不允许继续或顾客取消
        ME-->>CH: 结束此次付款尝试
    end

传入授权的数据中，可能包括说明电商认证情况的 电商交易标识（ECI），以及供发卡侧校验的认证值，例如 Visa 的 持卡人认证验证值 CAVV。这些结果帮助发卡侧判断请求，也可以成为后续争议处理的依据。

Mastercard 有相应用途的 账户持有人认证值 AAV。它与 CAVV 的用途相近，都是把认证结果交给后续授权流程核验。至于两者的格式、生成方式和报文位置，仍应按各自网络规范处理，不能只换个字段名称就当成同一种值。²⁶

这些数据把前面的认证与后面的授权联系起来。商户系统里写着“认证通过”，只是本地知道了结果；授权请求还需要按要求携带相应数据，发卡侧才能核验这次付款所引用的认证。字段遗漏、关联错误，都可能使原本完成的认证无法在后续处理中发挥应有作用。

认证通过，仍然可能因为额度不足而授权失败。认证主要在回答 是否有理由相信付款人有权使用这张卡，授权还需要回答 这个账户此刻是否允许支付这笔金额。两者分别完成自己的检查，才不会把身份可信误读成这笔钱一定能付。

3DS 还可能影响某些欺诈争议的责任分配。满足相应条件时，商户可获得 欺诈责任转移（Fraud Liability Shift），由发卡侧承担原本可能落在商户侧的特定欺诈损失。适用范围取决于网络、地区、交易类型和认证数据，不能推广到所有拒付原因。即便库克确实亲自通过了认证，商户没有发货，仍然需要面对未交付商品的争议。²⁷

前面几种办法都在增加验证证据。还有一条思路，是减少支付过程中反复暴露真实卡号的机会，这就是 支付令牌化（Payment Tokenisation）。

以 网络令牌（Network Token） 为例，令牌服务用一个替代值代表 PAN，并可以把它限制在特定设备、商户或支付场景内使用。网络与发卡侧按约定识别它及其对应账户，交易仍能沿银行卡体系处理。由于使用范围受到限制，即使令牌被窃取，也不容易像完整卡号那样被拿到其他场景复用。²⁸

钱包或商户可作为 令牌申请方（Token Requestor），向 令牌服务提供方（TSP） 申请凭证。发放令牌前，需要按发卡侧的要求核实用户是否有权绑定这张卡；验证通过后，才建立令牌与 PAN 的对应关系，并管理令牌的状态。后续交易中，令牌服务、网络和发卡侧还要核验适用的设备、商户或场景限制及动态数据。安全性来自这些持续执行的限制，而不只是把号码换了一串。²⁹

手机钱包就采用了类似方式。同一张实体卡加入两台设备后，可以分别配置设备相关的支付凭证。若其中一台丢失，就能针对那台设备停用凭证，另一台设备和实体卡不必一起失效。至于付款时手机会把哪些数据交给终端，我们在后面的钱包一章再看。

商户自己保存什么数据，同样重要。支付卡行业数据安全标准（Payment Card Industry Data Security Standard，PCI DSS） 对卡片数据的处理提出了要求。对商户及其受理服务商而言，卡面安全码在授权后不得保存，即使加密保存也不行。不能因为顾客同意“记住这张卡”，就把安全码一起长期留在数据库里。³⁰

那订阅服务下个月怎样自动扣款？它可以使用事先保存的卡片凭证，这类安排常称为 卡片凭证留存（Card-on-file，COF），同时还要有顾客同意的后续扣款约定。保存的可以是受适当保护的卡号或替代凭证，而不需要把安全码一并留存。

还要区分 持卡人发起交易（CIT） 与 商户发起交易（MIT）：库克主动点击付款，即使使用保存的卡片，仍是 CIT；服务商根据先前同意的订阅安排，在他未当场参与时发起续费，才可能按 MIT 处理。后续扣款应正确标记，并保留与首次交易及约定的关联。COF 说明保存了凭证，CIT／MIT 说明谁发起本次交易，仅保存卡号不构成任意扣款的许可。³¹

从芯片到 3DS，再到令牌化，这些技术各自处理不同的问题：卡片数据能否验证，付款人身份是否可信，泄露的凭证还能在多大范围内使用。这些技术提供了验证和保护手段，但交易仍需经过授权、记账，必要时还要处理争议。商户要把这些能力接进自己的收银系统，往往还需要专业服务商，这也引出了四方模型之外的那些名字。

四方模型以外的参与者

前面为了看清交易，把商户与收单侧之间的许多工作合并画成了一条线。真要开一家网店，这条线却不能凭空出现：网页要安全地接收付款信息，订单要能关联交易结果，不同银行和支付方式的数据格式也要有人处理。

网店最先要解决的，是付款信息怎样从网页安全地进入支付后端。这通常由 支付网关（Payment Gateway） 提供接入能力。顾客填写付款信息，商户提交订单金额，网关把相应请求交给后面的处理系统，再把结果带回商户。

进入后台后，还要把消息转换成对方能够接收的格式，按要求发送、接收响应并记录状态。这些交易处理工作由 支付处理器（Payment Processor） 承担。处理器既可能服务收单侧，也可能服务发卡侧。它描述的是处理能力，并不自动意味着这家公司同时经营持卡人的账户或负责商户收款。

商户如果希望一次接入就能用上这些服务，可以选择 支付服务商（Payment Service Provider，PSP）。PSP 通常把接入、处理、风控、报表和多种支付方式组合起来，由它协调其中若干环节。对一家刚开业的配件网店来说，差别体现在要签哪些合同、对接多少接口、出了问题找谁；在底层，银行卡交易仍需要找到发卡侧作决定，并由收单侧承担相应的商户受理责任。

放到中国内地，PSP 更适合作为方便理解的功能性总称，并不对应一张名为 PSP 的统一许可证。实际签约时要分清银行、依法取得支付业务许可的非银行支付机构，以及只提供系统接入或聚合收银台的技术服务商。³²

因此，网关、处理器和 PSP 描述的是工作内容与服务范围。一家公司可以兼做其中几项，也可以外包一部分工作。看到某家公司既自称 PSP，又提供网关，并不矛盾。

分清这些工作，对排查问题也有帮助。付款页面连不上，需要先看接入环节；请求已经送到发卡侧且被明确拒绝，就要继续看授权结果；交易已经请款，商户却没收到款项，则需要查清算、付款批次及合同安排。商户可以统一向 PSP 求助，但 PSP 仍要沿不同环节追查，不能用一个“接口正常”回答所有问题。

同样，商户接入服务商后拿到的一个“卡片编号”，可能只是该服务商内部保存凭证的引用，并不一定就是前文的网络令牌。内部编号由谁识别、是否可以迁移到别的服务商，与卡组织直接识别的令牌各有安排。看见一个替代卡号的字符串，还需要弄清它在哪一层有效。

如果一家平台要为许多小商户开通收款，还可以采用 支付便利商（Payment Facilitator，PayFac） 模式。PayFac 在收单机构支持和卡组织规则下，为它所服务的 子商户（Submerchant / Sponsored Merchant） 办理准入、提供交易服务并持续监控风险，也可能参与资金分配。收单机构需要按网络规则注册和管理这种关系，仍然承担相应的收单责任。³³

与每家小店分别建立一套收单接入相比，PayFac 可以把许多共用的接入和运营工作集中起来。小商户获得了更方便的开通和管理方式，平台也因此需要识别这些商户实际在经营什么、是否有异常交易，以及后续款项该付给谁。

假设某个子商户收款后停止经营，后来又出现应由商户侧承担的拒付，网络层面的处理仍会落到相应收单关系上，不能因为子商户消失就自动结束。收单机构、PayFac 与子商户之间，再按规则和合同分配责任、追索款项。这解释了为什么 PayFac 不能只提供一个开户页面，还需要持续管理商户及其资金风险。

这种接入安排本身，并不自动决定谁在向消费者销售商品。交易中的 正式销售方（Merchant of Record，MoR），是另一个经常被混在一起的概念。它指在这笔销售中对消费者承担相应销售责任的主体，通常负责收款、销售相关税务、退款和拒付处理；具体责任仍需结合合同及适用规则判断。³⁴

例如，软件开发者可以通过一家 MoR 向海外消费者销售应用。消费者付款时，交易中的销售方可能是这家 MoR，开发者再按双方约定取得收入。若开发者只是采购一家 PSP 的支付接口，销售方身份通常仍在自己这里。支付服务与销售责任是两个可以分别安排的问题。

判断销售方身份，应看消费者条款、销售合同及责任安排，而非支付页面上的标志。开发者可以继续提供软件服务，MoR 承担相应销售责任，两者也不必是同一主体。

这也解释了前文的账单名称问题。账单可能显示商户自己的名称，也可能显示 MoR 的名称，或者由 PayFac 与子商户名称组合而成。付款页面、订单邮件和银行账单之间若缺少可辨认的联系，消费者就容易把它们当成几笔不同的买卖。把这层关系写清楚，往往比事后解释一堆支付术语更有效。

至此，四方模型外增加的公司已经不少，但“四方”仍是描述责任关系的框架，不能用经手交易的公司数量来理解。反过来，如果同一体系同时承担发卡、收单和网络运营，结构还可以进一步集中，形成经典的 三方模型（Three-party Model）：持卡人、商户，以及兼有这些职能的运营方。

美国运通（American Express，Amex）常被用来说明这种模式。与多家发卡、收单机构共同接入的 开环网络（Open-loop Network） 相比，这种 闭环网络（Closed-loop Network） 把两侧关系更多地集中在同一体系内。不过，现实中的 Amex 也会与其他机构合作发卡或受理，三方图表达的是经典结构。³⁵

无论角色是分开承担，还是集中在一家公司，受理、处理、风险管理和资金服务都需要有人完成。商户支付的费用，也正是沿着这些分工形成的。

手续费、收入与成本

沿着前面的分工，现在可以算一算：库克支付 29.99 美元，沃尔玛最后能留下多少？

商户通常按合同向收单机构或 PSP 支付受理费用。以比例表示的商户收费，常称为 商户折扣费率（Merchant Discount Rate，MDR）。这个名称里的 折扣 指商户收到的款项相对交易金额有所扣减，并不是给顾客打折。实际报价还可能包含每笔固定费用、月费或其他项目。

从这笔费用的去向看，可以先分成三部分：

其中，交换费尤其容易被误解为 Visa 自己收走的钱。它通常是收单机构与发卡机构之间的费用；商户与收单侧约定的 MDR，则是另一层商业价格。交换费会影响商户的受理成本，但商户一般不是直接逐笔向发卡机构交费。³⁶

继续用充电头举例，假设这一笔的商户受理费用共 0.69 美元，约占交易金额的 2.30%。其中交换费 0.50 美元，卡组织相关费用 0.05 美元，收单及处理服务费用 0.14 美元，沃尔玛净得 29.30 美元。

sankey

"Total Fee $","Interchange Fee $",0.50
"Total Fee $","Card Scheme Fees $",0.05
"Total Fee $","Acquirer / Processor Markup $",0.14

这张图只拆分 0.69 美元受理费用，不表示各机构的净利润。把费用接回前面的账务：假设该例交换费在结算中抵扣，发卡侧对这笔消费应付 29.99 − 0.50 = 29.49 美元；收单侧取得对应资金后，假设承担上述网络费用 0.05 美元、保留服务费 0.14 美元，向商户支付 29.30 美元。这里只展示单笔经济归属，实际会合并其他交易及调整，部分费用也可能另行出账，并非每笔消费都单独汇出这些款项。

这组 2.30% 只是美国情境下的假设。对境内发卡、在境内银行卡受理终端发起的适用消费，中国大陆定价机制规定：发卡行服务费借记卡最高 0.35% 且每笔不超过 13 元，贷记卡最高 0.45%；网络服务费合计最高 0.065% 且每笔不超过 6.5 元，由发卡、收单两侧各承担一半，即各最高 0.0325%、3.25 元。符合条件的非营利医疗、教育、社会福利、养老及慈善机构适用这两项费用全额减免。收单服务费由商户与收单侧协商，条码支付不能直接套用这组费率。³⁷

退款时，这笔费用还会带来一个容易忽略的差额。假设合同约定，上面这 0.69 美元受理费用在退款后全部不退，商户先前净收到 29.30 美元，却需要向顾客退还完整的 29.99 美元，差额就是商户仍然承担的支付成本。实际哪些费用会退、哪些保留，要看网络与服务合同。顾客的净支出回到零，与商户的处理成本回到零，并不是一回事。

为什么同样是 29.99 美元，换一张卡，商户成本就可能变化？因为交换费通常按一套条件表计算。信用卡还是借记卡、消费卡还是商务卡、商户的 MCC、CP 还是 CNP、境内还是跨境，以及交易数据和提交时效，都可能影响适用的费率。³⁸

有些费率还要求商户按时、完整地提交特定数据。交易没有满足相应条件，就可能发生 费率降级（Downgrade），转入成本更高的档位。于是，授权成功、商品交付都没有问题的一笔交易，也可能因为后续记录不合要求而变贵。这就是前文强调请款与清算数据质量的另一个原因。

卡组织费用同样可能按金额、按笔数或按特定服务计收。收单侧则还要考虑商户的规模、平均客单价、退款与争议情况、服务范围和付款周期。把这些费用打包报价，还是逐项列出，会形成不同的定价方式：

常见的 统一比例加每笔固定金额，也称 统一费率定价（Flat-rate Pricing），通常可以视为混合定价的一种。它与混合定价并不是完全互斥的两个类别。不同服务商对这些名称的用法也可能不同，比较时仍要把实际收费项目放在一起看。

两种报价的区别，要结合商户每天受理的卡交易来看。假设一部分交易的底层成本较低，另一部分较高：IC++ 会把这种差异逐笔反映出来，再加服务费；混合定价则可能对两者采用相同报价，由服务商在整个交易组合中平衡成本。因此，评价哪种报价合适，需要看商户自己的交易构成。只拿某一笔特别便宜或特别贵的卡交易比较，容易得出失真的结论。

尤其要留意每笔固定费。假设报价为 2% + 每笔 0.10 美元，5 美元指甲刀的费用是 0.20 美元，有效费率为 4%；若拿大额艺术品购买作演算，按约 6,200,000 美元计算，费用为 124,000.10 美元，有效费率约 2%。固定费对小额交易的影响更大。这里借用了孙宇晨购买香蕉艺术作品的故事：苏富比公布的真实成交价为 6,240,000 美元，演算取了近似金额，费率也并非该拍卖的真实收费。³⁹

商户到账时还可能被暂留一部分款项。例如，收单侧按约定比例逐批留存资金，经过约定期限再释放，这种安排称为 滚动准备金（Rolling Reserve），用于覆盖后续退款、拒付等风险。它会影响商户当期能拿到多少现金，但暂留款项与已经收取的手续费应分别核算。⁴⁰

前面的例子一直在美国境内，用美元计价。若把购买地点换到欧洲，货架上标的是欧元，费用问题就又多了一层。商户标价与提交消费所用的是 交易币种（Transaction Currency）；库克信用卡上记账所用的是 账单币种（Billing Currency）；机构间划拨和商户收款，还分别有约定的 结算币种（Settlement Currency） 和 商户收款币种（Payout Currency）。这些币种可以相同，也可以不同。

跨境与跨币种是两个维度：前者依网络规定的商户、发卡或收单等所在地关系判断，后者关心币种是否不同。同为美元计价，也可能是跨境交易。若以欧元消费、美元记账，需要由相关网络或发卡侧换算；商户要求以另一币种收款时，收单侧还可能再次换汇。汇率时点、费用和舍入会影响结果，发卡侧也可能依卡产品约定另收境外交易费。

举一组纯粹用于计算的汇率：商品应付 29.99 欧元，若按 1 欧元兑换 1.10 美元记账，且暂不计额外费用，库克账单上的金额约为 32.99 美元。商户仍然是收取 29.99 欧元的那笔销售。一个是交易金额，一个是换算后的持卡人账单金额，不能因为数字不同就认定发生了多扣款。

如果后来退回 29.99 欧元，而发卡侧按退款时的汇率重新换算，美元返款又可能与原来的 32.99 美元不同。商户是否全额退款，需要先在原交易币种下核对；持卡人账单上的差额，则要继续检查换汇及收费安排。跨币种交易中，“金额一致”必须先说清是在比较哪一种币种、哪一阶段的金额。

有时终端会提前询问：“要不要直接用美元付款？”这就是 动态货币转换（Dynamic Currency Conversion，DCC）。选择后，商户侧的 DCC 服务方在付款时给出换算后的金额和汇率；若选择当地货币，则按银行卡原有安排进行后续换算。DCC 应向持卡人展示币种、金额、汇率及相关费用，并让持卡人作出选择。用美元付款，也不意味着发卡侧一定免收境外交易费。⁴¹

最后，再看信用卡上的积分和返现。发卡机构的收入可能来自交换费、年费、利息和其他服务，支出则包括奖励、资金成本、欺诈与信用损失，以及运营和获客。返现是整套卡业务收支安排的一部分，不能把这只充电头的 0.50 美元交换费，逐笔对应成库克拿到的奖励。

对沃尔玛而言，受理成本会影响商品毛利，也可能进入整体定价；是否向持卡人另行收取 刷卡附加费（Surcharge），还要看当地法规与网络规则。顾客没有看到一行“支付手续费”，并不代表提供这次支付服务没有成本。

算到这里，29.99 美元背后的收入、费用和到账差额都有了来由。不过，收银台上除了 Visa，还有手机钱包、银行转账等选项。换一个支付按钮，是否就会绕开刚才的全部过程？

钱包与 APM

假设库克来到一家支持 Apple Pay 的商店，用 iPhone 中绑定的 Visa 卡买充电头。手机换掉了他手里的塑料卡，后面的银行卡交易是否也随之消失了？

先看凭证。卡片加入 Apple Pay 后，设备取得 设备账号（Device Account Number） 及相关密钥，保存在 安全元件（SE） 中。普通店内付款时，库克先用人脸、指纹或设备密码确认，再让手机通过 NFC 与终端交互；支付应用按方案使用交易计数、密钥及适用的终端数据，生成本次动态密码文。⁴²

这类设备侧持卡人验证称为 CDCVM。它与生成交易密码文是不同动作：前者确认用户有权启用凭证，后者为交易提供可核验数据。终端会提供支付应用所需的数据，并取得设备账号及动态凭证；部分方案的计算包含终端不可预测数，不能理解为手机在靠近终端前已独自生成全部交易数据。

终端接到这些数据后，仍会发起银行卡授权，经过收单侧、卡组织和发卡侧处理。商户后面的请款、清算、结算也仍然存在。变化主要发生在凭证和持卡人验证这一段：商户接触到的是设备支付凭证，通常不需要取得实体卡的完整 PAN。

sequenceDiagram
    autonumber
    participant CH as 库克
    participant IP as iPhone
    participant PO as POS 终端
    participant AC as 收单侧
    participant NW as 卡组织及令牌服务
    participant IS as 发卡侧

    CH->>IP: 选择卡片，确认付款
    IP->>IP: 完成设备侧持卡人验证
    PO->>IP: NFC 交互，提供适用的交易数据
    IP->>IP: 按支付方案生成动态凭证
    IP->>PO: 返回设备账号及动态凭证
    PO->>AC: 发起银行卡授权
    AC->>NW: 提交请求
    NW->>IS: 按令牌规则处理后转交发卡侧
    IS-->>NW: 返回授权结果
    NW-->>AC: 返回授权结果
    AC-->>PO: 返回批准或拒绝
    PO-->>CH: 展示支付结果

在中国内地，银联手机闪付也是相近的例子：它可以通过 Apple Pay、Huawei Pay 等设备钱包呈现，使用 NFC 和支付令牌完成线下非接触式付款。可同一部手机如果改用支付宝或微信支付的二维码，前台动作虽然同样只是拿手机付钱，后台却未必走这条令牌化银行卡路径。⁴³

所以，前台看起来像手机本身在付款，后台仍可能是一笔熟悉的卡交易。另一些钱包则允许用户先充值，再用钱包账本里的余额消费，属于 储值钱包（Stored-value Wallet）；还有些钱包在付款时从绑定银行卡或银行账户取得资金。同一个钱包甚至可以提供多种资金来源，不能只凭应用名称判断它走哪套网络。

以一个允许充值的储值钱包为例，用户先转入 100，再用余额消费 20 和 10，余额降至 70。若消费完全在钱包体系内记账，银行侧看到的是最初充值，不会再出现这两笔钱包消费；钱包内部则要记录用户余额减少、商户余额增加。下图仅借用熟悉的零钱界面示意账本关系，不代表特定产品的全部充值或结算规则。

若退回第一笔 20，用户钱包余额回到 90，商户余额从 30 降到 10；商户随后提现这 10，才形成钱包向商户银行账户的另一笔划款。消费退款留在钱包余额，与把余额退回银行账户不同，充值、消费、退款、提现应各有记录。

扫码也是如此。二维码可以承载商户、订单或收款信息，把顾客带到对应付款页面。至于后面扣的是钱包余额、银行卡还是银行账户，要看所选的资金来源和处理安排。“扫了一个码”描述了付款入口，还没有说明资金怎样完成转移。

中国内地的业务规范还把条码交互分成两种：付款扫码 是顾客扫描商户展示的收款码，收款扫码 是商户扫描顾客手机上的付款码。两种方式改变了谁展示、谁读取凭证，却仍没有单独回答资金来自支付账户余额还是银行账户；涉及跨行交易时，还要进入相应的清算安排。⁴⁴

在银行卡之外，行业常用 替代支付方式（Alternative Payment Methods，APM） 统称当地钱包、银行账户支付、现金凭证等方案。“替代”是相对于传统银行卡受理而言的，并不代表这些方式在当地处于次要地位，也不是一套共同的技术标准。

例如，顾客可以直接从银行账户向收款账户付款，这类安排称为 账户到账户支付（Account-to-account Payment，A2A）。由付款人发出指令、把钱转给对方，属于 贷记转账（Credit Transfer）；若收款人根据付款人事先授予的扣款许可发起收款，则属于 直接借记（Direct Debit）。两者都使用账户，却在谁发起指令、付款人如何同意、款项可以怎样退回等方面有所不同。

用缴电费来比较就很直观。第一种做法是每月看到账单后，打开银行应用，确认金额并向电力公司转账；第二种做法是事先约定扣款，电力公司在账单到期时发起收款。后一种省去了每月手动付款，却更依赖对扣款许可、金额和日期的管理。收款方提交了扣款请求，仍需等待相应系统处理；遇到余额不足、扣款许可失效等情况，也可能收不到钱。不同直接借记方案还规定了各自的退回与退款权利。⁴⁵

部分账户支付通过 即时支付（Instant Payments） 网络处理，让收款人很快就能使用资金。但“更快到账”还不足以描述全部差异：机构之间何时完成结算，消费者遇到欺诈或未交付商品时有何救济，仍需看具体制度。银行卡的拒付规则，不能直接套到每一种账户支付上。

这里还要区分 结算最终性（Settlement Finality）：它关心的是，一项转移何时在法律和系统规则下成为不可撤销、无条件的结果。系统必须有这样一个确定时点，参与机构才能据此管理资金，而不必把每一笔已经完成的收款都永远当成待定。⁴⁶

结算具有最终性，与顾客后来能否获得退款，回答的是两个问题。例如，原付款已经最终结算，商户仍可通过另一笔付款退回货款；适用制度也可能要求有关机构处理欺诈返款。这不会把原来那次结算变成“从未发生”。判断一种支付方式是否适合某项业务，既要看付款多久完成，也要看出错以后依据什么规则、由谁发起返款。

还有 先买后付（Buy Now, Pay Later，BNPL）。它主要安排顾客先取得商品、之后再按约定还款，底层付款却仍可能使用银行卡或银行账户。它与“扫码”“银行卡”“转账”并不是同一层面的分类：一个说明信用怎样提供，另一些说明付款怎样发起或资金经过什么网络。

各地支付体系中的主要机构、系统与结算关系，见文末附录A。

最后再回到那只充电头。库克听见“滴”的时候，发卡侧刚刚作出批准；沃尔玛随后确认收款金额，财务记录进入清算，机构之间履行结算义务，货款再按合同进入商户账户。如果后来退货或发生争议，各方还能沿着原交易的记录找到当时的金额、凭证与交付情况。

收银台之所以只需等几秒钟，是因为这些工作有先后之分：哪些必须当场决定，哪些可以随后处理，出了问题又怎样查证，都已有相应安排。顾客可以先把商品带走，后台仍把每一步的账继续记完。

库克回到酒店，插上充电头。手机亮了。对他来说，这笔交易终于只剩下小票上那一行：29.99 美元。

附录A：各国家和地区的体系

读这些图时，可以依次问：谁能接入、用户何时能用钱、机构之间何时结算、资金记在哪类账户。实时全额结算（RTGS） 是逐笔履行资金义务；延迟净额结算则先计算净头寸，再在约定时点划拨。客户即时到账可以先于机构间结算，从客户到账到机构间结算的这段时间，需要有资金和风险保障。央行账户中的资金、商业银行存款和钱包余额，也不是同一种账户关系。英国和印度还把 RTGS 用作特定结算服务的名称。

图中实线表示主要接入、处理或结算关系，不全部代表资金流向；虚线表示规则、查询或流动性支持等辅助联系，具体含义以连线文字为准。双向箭头表示双方交换或系统互联。

美国

美国的特点是公共与私营网络并行。银行和信用合作社连接用户与后台系统，批量付款、即时付款、大额汇款和刷卡消费使用不同的支付安排。

flowchart TD
    U["个人、企业、政府<br/>付款与收款"]
    B["银行与信用合作社<br/>账户、转账、代收代付"]
    P["支付应用与商户服务机构<br/>钱包、支付处理、商户受理"]

    U --> B
    U --> P
    P -. "使用银行账户支付能力" .-> B

    subgraph PUBLIC["美联储运营的支付服务"]
        FA["FedACH<br/>批量贷记与扣款"]
        FN["FedNow<br/>全天候即时支付"]
        FW["Fedwire Funds<br/>大额与时效敏感支付"]
    end

    subgraph PRIVATE["The Clearing House 运营的支付系统"]
        EPN["EPN<br/>批量 ACH"]
        RTP["RTP<br/>即时支付与系统内最终结算"]
        CHIPS["CHIPS<br/>大额美元支付；日内连续处理<br/>支付释放后具有最终性"]
    end

    subgraph OTHER["其他支付网络"]
        CARD["信用卡与借记卡网络<br/>连接发卡机构和收单机构"]
        CHECK["支票收集与交换<br/>美联储及私营渠道"]
    end

    B --> FA & FN & FW
    B --> EPN & RTP & CHIPS
    B --> CHECK
    P --> CARD
    CARD --- B
    FA <-->|"ACH 网络互通"| EPN

    subgraph SUPPORT["结算支持"]
        ACCOUNT["美联储账户<br/>参与机构自有或代理结算账户"]
        NSS["NSS<br/>私营清算安排的多边净额结算服务"]
        AGENT["卡支付结算银行与代理安排"]
    end

    FA -->|"按结算窗口记账"| ACCOUNT
    FN -->|"逐笔实时结算"| ACCOUNT
    FW -->|"逐笔实时结算"| ACCOUNT
    EPN --> NSS --> ACCOUNT
    RTP -. "联储联合账户中的预存资金支持" .-> ACCOUNT
    CHIPS -. "联储专用账户中的预存资金支持" .-> ACCOUNT
    CARD --> AGENT
    CHECK -. "依渠道完成结算" .-> ACCOUNT

工资、定期账单和批量代收付主要使用 ACH。FedACH 与 EPN 是两家 ACH 运营网络，能够互通；ACH 可以有当日结算窗口，但不等于全天候逐笔即时支付。⁴⁷

FedNow 和 RTP 都提供即时支付基础设施。FedNow 直接在参与机构自有或代理机构的联储账户上结算；RTP 在自身账簿内实时结算，由联储联合账户中的预存资金支持。图中两者连接联储账户的线，含义不同。⁴⁸⁴⁹

Fedwire 采用央行货币实时全额结算；CHIPS 在系统内通过支付匹配与抵销节约流动性，支付满足条件并释放后具有最终性。CHIPS 既用于美国国内，也用于跨境美元资金支付。⁵⁰⁵¹

银行卡和支票各有自己的业务处理、清算和结算安排。刷卡显示成功，不能直接理解为商户已收到最终结算资金。

可以把美国理解为“多套专用支付网络，共同依托银行账户和联储结算基础”。RTP、CHIPS 的预存资金支持，不等于每笔客户支付都再交给 Fedwire 处理。FedNow 和 RTP 是两套独立系统，选择哪条路径还取决于双方机构的接入和服务安排。

中国大陆

中国大陆以人民银行支付系统为银行间资金支付骨干，银行卡和非银行网络支付清算与之衔接，CIPS 等安排服务跨境支付。用户看到的银行转账、扫码付款和跨境汇款，后台可能采用不同路径。

flowchart TB
    U["个人、企业、政府"]

    BANK["银行业金融机构<br/>存款账户、汇款、代收付、发卡与收单"]
    PAY["非银行支付机构<br/>支付账户、网络支付、收单"]

    U --> BANK
    U --> PAY

    subgraph MARKET["银行卡与非银行支付清算"]
        CLEAR["银联、网联等清算机构<br/>按业务类型和规则连接银行与支付机构"]
    end

    BANK <-->|"银行卡与相关网络支付"| CLEAR
    PAY <-->|"涉及银行或其他支付机构的合作业务"| CLEAR

    subgraph CORE["人民银行支付系统骨干"]
        HVPS["大额实时支付系统 HVPS<br/>大额、紧急及金融市场资金支付"]
        BEPS["小额批量支付系统 BEPS<br/>批量收付款与净额清算"]
        IBPS["网上支付跨行清算系统 IBPS<br/>即时跨行零售支付与账户互联"]
        SETTLE["人民银行账户结算体系"]
    end

    BANK --> HVPS
    BANK --> BEPS
    BANK --> IBPS
    HVPS -->|"实时全额结算"| SETTLE
    BEPS -->|"净额结算"| SETTLE
    IBPS -->|"实时轧差、定时净额结算"| SETTLE
    CLEAR -->|"按清算安排提交结算"| SETTLE

    RESERVE["支付机构客户备付金<br/>人民银行集中存管账户"]
    PAY -. "客户资金存管" .-> RESERVE
    CLEAR -. "依交易办理备付金划转" .-> RESERVE

    subgraph CROSS["跨境支付：以人民币业务为主"]
        CIPS["CIPS<br/>跨境人民币清算与结算"]
        OVERSEA["境内外参与机构<br/>连接跨境贸易与投融资收付款"]
    end

    BANK <-->|"直接或间接参与"| CIPS
    CIPS <--> OVERSEA
    CIPS_ACCOUNT["CIPS 直接参与者账户<br/>在 CIPS 内完成结算"]
    CIPS -->|"实时全额或定时净额"| CIPS_ACCOUNT
    CIPS <-. "注资、调增及回流等流动性联系" .-> HVPS

    HKFPS["香港 FPS 转数快"]
    IBPS <-->|"跨境支付通：系统互联"| HKFPS

HVPS 主要处理大额、紧急及金融市场资金支付，采用实时全额结算；BEPS 处理适用的小额批量收付款，采用净额结算；IBPS 支持银行线上即时跨行零售支付和账户互联。IBPS 的“实时处理、实时轧差、定时结算”能够与用户侧即时到账并存。⁵²⁵³

例如，实体银联卡消费通常由收单侧经银联连接发卡侧；支付机构发起、涉及银行账户的网络支付，则经网联或其他具备相应资格的清算安排处理。完全在同一钱包内部记账的余额消费，又不同于上述银行账户扣款。银联与网联不是每笔付款依次经过的两个步骤。支付机构客户备付金集中存管，也不等于每位钱包用户都在人民银行开了存款账户。⁵⁴⁵⁵

CIPS 是清算结算系统，直接参与者在 CIPS 开立账户，间接参与者通过直接参与者办理业务。其汇款业务支持实时全额与定时净额两种模式，与 HVPS 的联系主要用于人民币流动性调拨，不能理解为所有 CIPS 支付最后都逐笔交给 HVPS 结算。此图聚焦其人民币业务。⁵⁶⁵⁷

个人通过手机银行向另一家银行的账户即时转账，可能使用 IBPS；批量代收付和紧急大额汇款则可能选择其他系统。前台都叫“转账”，后台采用哪种路径由业务类型和银行安排决定。

大陆与香港的“跨境支付通”于2025年6月22日上线，连接大陆 IBPS 和香港 FPS，支持符合条件的即时小额跨境汇款。这是一条零售系统互联路径，不能把所有跨境收付款都归入 CIPS。⁵⁸

中国香港

香港的特点是多币种支付结算。FPS 服务港币和人民币即时支付，CHATS 提供按币种划分的银行间资金支付基础设施，各币种对应不同的结算机构。

flowchart TD
    U["个人与企业"]
    BANK["银行<br/>账户与本地／跨境收付款"]
    SVF["储值支付工具运营商<br/>储值账户与商户支付"]
    RETAIL["卡支付与储值消费体系<br/>发卡、收单、运营商内部处理"]

    U --> BANK
    U --> SVF
    U --> RETAIL
    RETAIL -. "商户出款及相关资金收付" .-> BANK
    SVF --> RETAIL

    subgraph HKICL["HKICL 运营的主要资金支付基础设施"]
        FPS["FPS 转数快<br/>港币／人民币全天候即时支付"]
        HKD["港币 CHATS<br/>实时全额支付及批量结算"]
        RMB["人民币 CHATS<br/>实时全额支付及批量结算"]
        USD["美元 CHATS<br/>实时全额支付及适用批量结算"]
        EUR["欧元 CHATS<br/>实时全额支付"]
        BULK["支票与电子批量清算<br/>工资、自动转账、账单等"]
    end

    BANK --> FPS
    SVF -->|"清算参与：通过结算银行完成资金结算"| FPS
    BANK --> HKD & RMB & USD & EUR
    BANK --> BULK
    BULK -->|"按币种及业务安排"| HKD
    BULK -->|"适用人民币业务"| RMB
    BULK -->|"适用美元业务"| USD

    H["香港金管局<br/>港币 CHATS／FPS 分账"]
    R["中银香港<br/>人民币 CHATS／FPS 分账"]
    D["汇丰<br/>美元结算账簿"]
    E["渣打香港<br/>欧元结算账簿"]

    HKD --> H
    RMB --> R
    USD --> D
    EUR --> E
    FPS -->|"港币"| H
    FPS -->|"人民币"| R

    MAINLAND["中国大陆 IBPS"]
    FPS <-->|"跨境支付通：系统互联"| MAINLAND

FPS 转数快连接银行和参与的储值支付工具，支持港币和人民币支付。用户可以利用绑定的手机号码等标识收款。SVF 是“储值支付工具”，可包括符合相应牌照范围的电子钱包。⁵⁸

CHATS 按港币、人民币、美元和欧元分别运行，承担实时全额支付，并按币种及业务安排结算支票和电子批量清算结果。HKICL 是系统运营机构，不应与提供结算账户的机构混为一谈。⁵⁹

港币结算机构是香港金管局；人民币清算行为中银香港；美元和欧元结算机构分别是汇丰及渣打香港。因此，不能把香港所有币种的结算都称为直接在央行账簿上结算。⁶⁰

FPS 与 CHATS 是不同的支付处理安排。港币结算账户包括 CHATS 和 FPS 分账，图中的共同结算机构节点不表示两个系统完全共用同一个处理账簿。储值支付工具可作为 FPS 清算参与者，经结算参与银行提供资金结算服务；钱包接入 FPS 不代表钱包自己直接持有金管局结算账户。⁶¹

香港的突出特点是“本地即时支付与多币种银行间结算并存”。跨境支付通进一步把 FPS 与大陆 IBPS 连接起来，具体跨境服务仍由参与机构按适用规则提供。

日本

日本国内跨行转账以全银系统为重要枢纽，BOJ-NET 和日本银行当座账户提供最终资金结算基础。Cotra 为小额个人转账提供便利的即时服务，并与既有清算体系衔接。

flowchart TB
    U["个人与企业"]

    subgraph RETAIL["日常收付款的不同组织方式"]
        MERCHANT["消费支付<br/>卡、二维码支付、预付电子货币"]
        COLLECTION["账单与公共缴费<br/>账户扣款、代收服务"]
        TRANSFER["账户转账"]
        SMALL["小额个人转账"]
    end

    U --> MERCHANT & COLLECTION & TRANSFER & SMALL

    OP["发卡、收单、电子货币及支付服务机构<br/>按各自支付安排处理商户交易"]
    BANK["银行等存款类金融机构<br/>客户账户与机构资金收付"]
    COTRA["Cotra ことら<br/>小额个人即时转账<br/>连接金融机构与资金移转业者"]

    MERCHANT --> OP
    OP -->|"商户结算及相关银行资金收付"| BANK
    COLLECTION --> BANK
    TRANSFER --> BANK
    SMALL --> COTRA

    subgraph CLEAR["银行间清算与支付安排"]
        ZENGIN["全银系统 Zengin<br/>国内转账处理与资金清算"]
        BILL["电子交换所<br/>票据与支票交换"]
        FX["外汇日元清算 FXYCS<br/>跨境及外汇交易相关日元支付"]
    end

    COTRA -->|"机构间资金清算每日两次衔接"| ZENGIN
    BANK -->|"国内跨行转账"| ZENGIN
    BANK -->|"票据与支票业务"| BILL
    BANK -->|"外汇日元业务"| FX

    BOJ["BOJ-NET 资金转账系统<br/>日本银行当座账户"]
    ZENGIN -->|"一般以1亿日元为界：净额或 RTGS，详见正文"| BOJ
    BILL -->|"清算差额结算"| BOJ
    FX -->|"逐笔结算"| BOJ
    BANK -->|"其他大额及银行间资金支付"| BOJ

银行卡、二维码支付和预付电子货币由各服务商组织处理，相关商户收款和机构资金收付再与银行体系衔接。它们不是全银系统本身。

全银系统负责转账信息处理和机构间清算。一般而言，低于1亿日元的转账汇总轧差后，通过日本银行当座账户结算；1亿日元及以上的转账通常交由 BOJ-NET 实时全额结算，工资、奖金等存在例外。图中金额边界解释的是结算机制，不是所有用户产品的转账限额。⁶²⁶³

Cotra 的个人汇款服务支持每笔10万日元及以下，可借助手机号码等信息收款。用户侧即时处理，机构间资金清算每日两次衔接全银系统。不是所有小额转账都必须使用 Cotra。⁶⁴

电子交换所处理票据、支票交换；FXYCS 处理跨境及外汇交易相关的日元支付；BOJ-NET 提供央行账户资金结算基础。这里的 FXYCS 处理的是日元资金支付，不是一个外汇买卖交易所。⁶⁵

个人通过参与机构的应用使用 Cotra 向朋友转账，朋友可能立即看到到账，但机构之间仍按既定安排衔接全银系统完成资金结算。即时到账，并不意味着机构间的结算也在同一时刻完成。

欧洲欧元支付体系

欧洲欧元支付的特点是共同规则与多套基础设施并存。先看支付适用哪套 SEPA 规则，再看由哪个系统处理，最后看资金在哪类账户上结算。

flowchart TB
    U["个人、企业与公共部门"]
    PSP["银行与其他支付服务商<br/>账户服务、商户收款、支付发起"]
    U --> PSP

    EPC["欧洲支付委员会 EPC<br/>制定 SEPA 支付方案规则"]

    subgraph RETAIL["欧元零售支付"]
        CARD["卡支付<br/>国际卡与本地卡方案"]
        SCT["SCT／SDD<br/>普通转账与直接扣款"]
        INST["SCT Inst<br/>即时转账"]
    end

    PSP --> CARD & SCT & INST
    EPC -. "共同规则" .-> SCT
    EPC -. "共同规则" .-> INST

    subgraph EXECUTE["执行共同规则的基础设施"]
        STEP["STEP2／EBA CLEARING<br/>批量零售支付；连续全额结算 CGS"]
        LOCAL["其他本地或区域<br/>清算结算机制"]
        RT1["RT1／EBA CLEARING<br/>即时支付与系统内结算"]
        TIPS["TIPS／欧元体系<br/>全天候即时支付结算"]
    end

    SCT --> STEP & LOCAL
    INST --> RT1 & TIPS

    subgraph WHOLESALE["大额与银行间资金支付"]
        EURO1["EURO1／EBA CLEARING<br/>大额支付；已处理支付即时最终"]
        T2["T2<br/>欧元体系实时全额结算"]
    end

    PSP -->|"大额与银行间业务"| EURO1
    PSP -->|"大额与银行间业务"| T2
    EURO1 -->|"日终净头寸结算"| T2
    STEPSET["STEP2 技术账户<br/>以中央银行货币连续全额结算"]
    STEP --> STEPSET
    T2 -. "流动性调拨" .-> STEPSET
    LOCAL -. "依系统安排连接结算服务" .-> T2

    CARDSET["发卡、收单与结算银行安排"]
    RTSET["RT1 系统内结算<br/>资金位于 TIPS 技术账户"]
    TIPSET["TIPS 专用现金账户<br/>此处展示欧元的中央银行货币结算"]

    CARD --> CARDSET
    RT1 --> RTSET
    TIPS --> TIPSET

EPC 制定 SEPA 支付方案。SCT 是普通贷记转账，SDD 是直接扣款，SCT Inst 是即时贷记转账；这些是共同业务规则，不是三家清算机构。STEP2、RT1、TIPS 等基础设施负责实际处理和结算。SEPA 范围包括欧元区以外的一些国家，所以“欧元区”“SEPA”“欧洲”不能互换。⁶⁶⁶⁷

STEP2 及其他清算结算机制执行适用的 SEPA 业务。STEP2 采用连续全额结算（CGS），将批量业务形成的双边支付指令在资金充足时连续结算，相关资金位于央行技术账户，并可从 T2 调拨。批量处理不等于一定采用延迟净额结算，也不等于 STEP2 是全天候即时支付服务。⁶⁸

RT1 由 EBA CLEARING 运营，在系统内结算，其技术账户位于 TIPS；TIPS 由欧元体系提供，在专用现金账户之间以中央银行货币全天候结算。RT1 与 TIPS 是不同基础设施，不能把“RT1 的资金账户位于 TIPS”理解为每笔 RT1 交易都转成一笔 TIPS 客户支付。TIPS 具有多币种能力，本图仅展示欧元路径。⁶⁹⁷⁰

T2 提供实时全额结算；EURO1 提供私营大额支付处理。EURO1 的已处理支付立即具有最终性，日终再将参与者的最终净头寸提交 T2 结算，两个时点对应不同层面的义务处理。⁷¹

本节展示的是欧洲以欧元为主的支付安排；英国英镑体系另见下文，瑞士法郎等其他本币体系不在此展开。它的突出特点是“共同规则下，多套公共与私营基础设施并存”。统一规则也不意味着所有服务商具有相同的直接接入资格。

巴西

巴西的 Pix 为即时账户支付提供统一安排，SPI 是央行运营的主要即时结算基础设施，DICT 帮助把 Pix 标识对应到收款账户。同时，传统转账、付款单和银行卡仍有各自的清算结算路径。

flowchart TD
    P["付款人"]
    R["收款人／商户"]
    A["付款账户机构<br/>银行或支付机构"]
    B["收款账户机构<br/>银行或支付机构"]

    P --> A
    B --> R

    subgraph PIX["Pix 即时支付：经 SPI 结算的典型路径"]
        DICT["DICT<br/>Pix 标识与收款账户目录"]
        DA["付款侧 SPI 直接参与者<br/>可代理间接参与者"]
        SPI["SPI<br/>巴西央行运营<br/>央行 PI 账户间实时全额结算"]
        DB["收款侧 SPI 直接参与者<br/>可代理间接参与者"]
    end

    A -. "使用 Pix 标识时查询账户" .-> DICT
    A -->|"Pix 指令"| DA
    DA --> SPI --> DB
    DB --> B

    ONUS["机构内部 Pix<br/>在机构账簿内完成"]
    A -->|"同一机构内部的适用交易"| ONUS
    ONUS --> B

    subgraph OTHER["其他主要支付路径"]
        CARD["卡支付<br/>发卡机构、卡方案、收单机构"]
        BOLETO["Boleto<br/>付款单收付"]
        SILOC["Núclea／SILOC<br/>Boleto 与适用卡业务的清算结算"]
        TED["TED 等银行转账"]
        SITRAF["Núclea／SITRAF<br/>银行间资金转账"]
        STR["STR<br/>巴西央行实时全额结算系统"]
    end

    P --> CARD
    A --> BOLETO
    CARD -->|"适用卡业务，可通过 SLC 服务"| SILOC
    BOLETO --> SILOC
    SILOC -->|"通过央行结算账户安排完成结算"| STR
    A --> TED
    TED --> STR
    TED --> SITRAF
    SITRAF -->|"接收机构获得转账"| B
    SITRAF -. "资金调拨联系" .-> STR
    STR -->|"相关机构资金收付"| B

Pix 是一套即时支付安排，用户在银行或支付机构的应用中使用它付款或收款。它不是某一家银行的钱包，也不等同于底层的 SPI 结算系统。

DICT 是 Pix 标识与收款账户的目录。当付款人使用 Pix 标识时，目录帮助确认对应的收款账户。图中的查询线传递的是信息，不是资金；不使用 Pix 标识的适用付款方式不必按同一路径查询。

经 SPI 结算的交易，在直接参与者开立于巴西央行的 PI 账户之间实时全额结算。间接参与者可由直接参与者提供结算服务。SPI 全天候运行，并以付款参与者的可用账户资金为基础。⁷²

部分交易在参与机构内部账簿上完成。因此，上图分别展示了经 SPI 结算和机构内部处理的路径；付款账户机构与收款账户机构是角色，可能属于同一家机构。⁷³

TED 是银行转账方式，可按适用安排经央行 STR 或 Núclea 的 SITRAF 处理；它并没有因为 Pix 出现而自动消失。STR 同时承担更广泛的银行间实时全额资金结算。⁷⁴

Boleto 是带付款信息的缴款单，常用于账单收付。Núclea 的 SILOC 处理 Boleto 与适用银行卡业务的清算结算，卡业务还可通过 SLC 服务组织处理；刷卡授权、商户出款则各有流程。⁷⁵⁷⁶

印度

印度的特点是由 NPCI 提供多种相互配合的零售支付基础设施，RBI（印度储备银行，即印度央行）运营 NEFT 和 RTGS，并提供央行账户结算基础。UPI 是最容易被用户感知的即时支付入口之一，但印度的支付体系还包括普通转账、批量代收付、银行卡和大额支付等路径。

flowchart TB
    U["个人、企业与政府"]
    BANK["银行及符合资格的账户机构<br/>账户服务、直接或间接参与"]
    APP["UPI 应用<br/>银行应用或第三方应用 TPAP"]
    PSP["UPI 支付服务商银行<br/>第三方应用通过合作银行接入"]

    U --> BANK
    U --> APP
    APP --> PSP

    subgraph NPCI["NPCI 运营的主要零售支付基础设施"]
        UPI["UPI<br/>即时转账与商户支付"]
        IMPS["IMPS<br/>全天候即时资金转账"]
        NACH["NACH<br/>批量贷记与授权扣款"]
        RUPAY["RuPay<br/>本地银行卡网络"]
        NET["NPCI 清算与结算处理<br/>按系统及周期形成机构净头寸"]
    end

    PSP <--> UPI
    BANK <-->|"付款及收款账户处理"| UPI
    BANK --> IMPS & NACH & RUPAY
    UPI --> NET
    IMPS --> NET
    NACH --> NET
    RUPAY -->|"适用境内业务"| NET

    subgraph RBI["RBI 运营的系统与央行账户"]
        NEFT["NEFT<br/>全天候运行；半小时批次处理"]
        RTGS["RTGS<br/>大额支付逐笔实时全额结算<br/>同时支持附属系统净额批次结算"]
        ACCOUNT["RBI 结算账户<br/>参与机构自有或代理账户安排"]
    end

    BANK -->|"普通转账"| NEFT
    BANK -->|"大额资金转账"| RTGS
    NEFT -->|"批次净额结算"| ACCOUNT
    NET -->|"多边净额结算批次 MNSB"| RTGS
    RTGS --> ACCOUNT

    OTHER["其他卡网络及支票等<br/>按各自业务安排清算结算"]
    BANK --> OTHER
    OTHER -. "依系统及代理安排完成结算" .-> ACCOUNT

UPI 由 NPCI 提供，连接不同应用和账户机构。用户使用的是银行应用或第三方应用，第三方应用通过合作的支付服务商银行接入 UPI。应用提供操作界面，UPI 提供互联支付能力，账户机构负责相应账户处理，三者不是同一个角色。本图主要展示常见银行账户支付路径；UPI 的其他资金来源及特殊产品不逐项展开。⁷⁷⁷⁸

IMPS 同样由 NPCI 提供，支持银行等参与机构提供全天候即时资金转账。UPI 在 IMPS 基础设施之上发展，但图中将两类服务分别列出，避免把用户的 UPI 支付理解成必须先在应用里发起一笔 IMPS 转账。⁷⁹

NEFT 和 RTGS 均由 RBI 运营，均可全天候运行，但结算机制不同：NEFT 按半小时批次处理，RTGS 对客户大额转账逐笔实时全额结算。因此，“全天候可用”不等于“所有交易逐笔即时结算”。RTGS 还支持来自 NPCI 等附属系统的多边净额结算批次，这不意味着每笔 UPI 支付都作为一笔客户 RTGS 汇款处理。⁸⁰⁸¹

NACH 适用于重复、定期和大批量的收付款，如工资、养老金、补贴发放，以及水电费、贷款和保险费扣款。它与 UPI 即时付款的业务组织方式不同。⁸²

RuPay 是 NPCI 提供的本地银行卡网络，连接发卡和收单等参与者；它不是 UPI 的别名。其他国际卡网络也有各自的支付与结算安排。⁸³

顾客用第三方 UPI 应用扫商户二维码，应用经合作银行和 UPI 网络发起支付，由两侧账户机构处理。普通银行账户直接收款时，资金可很快进入商户账户；只有采用聚合收款等安排时，才另需区分聚合方收款与向商户出款。用户侧到账后，NPCI 按适用周期计算机构净头寸，再在 RBI 账户体系结算，并非每笔 UPI 都单独发起一笔客户 RTGS 汇款。⁸⁴⁷⁸

英国

英国英镑支付按用途分工：Faster Payments 主要服务快速账户转账，Bacs 服务批量付款和直接扣款，CHAPS 服务大额或时效敏感支付。Pay.UK 运营主要银行间零售系统，英格兰银行运营 CHAPS 和 RTGS，并提供央行货币结算。

flowchart TB
    U["个人、企业与公共部门"]
    PSP["银行与符合资格的支付服务商<br/>账户、转账、收单及代理接入"]
    U --> PSP

    subgraph PAYUK["Pay.UK 运营的零售支付系统"]
        FPS["Faster Payments<br/>全天候近实时账户转账"]
        BACS["Bacs<br/>批量直接贷记与直接扣款"]
        ICS["Image Clearing System<br/>支票影像清算"]
        NET["各系统分别计算净头寸<br/>按各自结算周期提交"]
    end

    PSP --> FPS & BACS & ICS
    FPS --> NET
    BACS --> NET
    ICS --> NET

    subgraph BOE["英格兰银行运营的支付与结算基础设施"]
        CHAPS["CHAPS<br/>大额及时间敏感的英镑支付"]
        RTGS["RTGS 服务与央行结算账户<br/>结算 CHAPS 支付及零售系统净头寸"]
        PREFUND["专用预存资金账户<br/>覆盖有关零售系统的净借记限额"]
    end

    PSP -->|"直接或通过代理参与"| CHAPS
    CHAPS -->|"逐笔实时全额结算"| RTGS
    NET -->|"分系统、分周期净额结算"| RTGS
    PSP -. "结算参与者预存资金" .-> PREFUND
    PREFUND -. "为上述零售系统提供结算资金保障" .-> NET

    OTHER["卡支付与 LINK ATM 网络<br/>分别按各自规则处理"]
    PSP --> OTHER
    OTHER -->|"适用英镑净头寸经结算参与者结算"| RTGS

Faster Payments 支持全天候近实时付款，常用于网上银行转账、账单支付和定期转账。用户可能在几秒内看到到账，但机构间净头寸按结算周期提交英格兰银行；目前通常每个营业日结算三次，周末和公众假期的相关周期在下一营业日结算。本节的 Faster Payments 与香港 FPS 转数快是不同地区的独立系统。⁸⁵

Bacs 包括 Direct Credit（直接贷记，如工资发放）和 Direct Debit（直接扣款，如获授权的水电费扣款），通常采用三个工作日的处理周期。它适合按计划处理的批量付款，不能与 Faster Payments 的到账速度等同。Pay.UK 还运营支票影像清算系统 ICS。⁸⁶⁸⁷

CHAPS 在英格兰银行 RTGS 服务中逐笔结算，常用于金融机构资金支付，也用于购房款等需要确定结算时点的付款。CHAPS 是支付系统，RTGS 是支持其结算的央行账户基础设施；英国零售系统的净头寸也使用 RTGS 服务，所以不能把“英国 RTGS 服务”理解为只处理 CHAPS。⁸⁸

Bacs、Faster Payments 和 ICS 的直接结算参与者按要求预存资金，以覆盖最大净借记头寸。这样的资金保障支持净额结算，不会把每笔零售付款变成一笔央行逐笔实时结算。⁸⁹

银行卡网络和 LINK 自动取款机网络分别组织相应业务，适用的英镑净头寸也可在英格兰银行 RTGS 账户中结算；图中将它们合并展示，不代表它们是同一系统。⁸⁵

同一家银行可以用 Faster Payments 帮个人快速转账，用 Bacs 帮企业按发薪计划批量付款，再用 CHAPS 处理一笔需要当日确定结算的大额购房款。前台都属于“银行付款”，采用的后台系统和结算节奏却不同。

本节聚焦英镑。英国仍在 SEPA 支付方案的适用范围内，英国机构办理符合条件的欧元支付时可使用相应 SEPA 安排；英国本地的英镑支付则使用本节介绍的系统。⁶⁷

参考资料