支付生态系统全景拆解：发卡、收单、清算与结算的参与者分工（system-design-101）

金融科技公司如何在众多支付公司中找到新的机会？PayPal、Stripe、Square 这些公司到底在做什么？本文以 system-design-101 仓库中的《The Payments Ecosystem》指南为核心，把一笔银行卡交易背后从持卡人开户到商户收款的全链路拆开来看：谁在发卡、谁在收单、谁负责清算与结算，以及收单（acquiring）与发卡（issuing）两侧的处理器（processor）分别承担什么职责。读完本文，你将掌握支付生态的完整参与者图谱与 8 步交易链路，能够用同一套框架去理解 Visa、Stripe、PayPal 等公司在生态中的位置，以及它们为什么往往从单一垂直领域起步、再向多垂直领域扩张。

为什么需要一张支付生态全景图

支付行业是一个高度分工的生态：一次刷卡动作背后，往往横跨发卡行、收单行、卡组织（card network / card scheme）、支付网关、支付处理器等多个角色。正如仓库中 支付学习路线指南 所归纳的，虽然不同国家有各自的支付框架，但支付行业大体由以下部分组成：

• 监管机构（Regulatory Authority）
• 中央银行（Central Bank）
• 商业银行（Commercial Banks）
• 非银行支付公司（Non-Bank Payment Companies）
• 支付系统（Payment Systems）
• 清算网络（Clearing Networks）
• 结算系统（Settlement Systems）

《The Payments Ecosystem》指南正是用一张图、8 个步骤，把这些角色串成一条完整的交易链路，并回答了"PayPal、Stripe、Square 到底做什么"这个基础问题——它们各自占据生态中的某一环，再向外扩张。

生态核心参与者速览

在进入步骤拆解之前，先建立角色清单。下表基于指南原文与仓库内支付相关文档整理：

角色	一句话职责	指南中的定位
持卡人（Cardholder）	在发卡行开户并获得借记卡/信用卡	Step 0-1 起点
发卡行（Issuing Bank）	发卡并维护客户账户	Step 6-8 发卡侧
商户（Merchant）	通过 ISO/MSP 注册开通线下收款	Step 0-1
ISO / MSP	独立销售组织/会员服务提供商，为商户接入收单服务	Step 0-1
支付处理器（Payment Processor）	利用客户信息完成收款	Step 2-5 收单侧
支付网关（Payment Gateway）	受理购买交易、收集支付信息	Step 2-5
卡组织（Card Network）	连接收单与发卡两侧，负责清算与结算	Step 2-8 中间枢纽
发卡处理商（Issuing Processor）	代表发卡行与卡组织通信、校验并维护客户账户	Step 6-8

注意一个易混淆点：指南中出现了两个"processor"——收单侧的"acquiring processor"与发卡侧的"issuing processor"，它们分别服务于交易链路的两端，职责并不相同。

Step 0-1：账户开设与商户准入

交易链路从两个平行的"开户"动作开始：

• 持卡人侧：持卡人在发卡行（issuing bank）开设账户，获得借记卡或信用卡。
• 商户侧：商户为了开展线下销售，向 ISO（Independent Sales Organization，独立销售组织）或 MSP（Member Service Provider，会员服务提供商）注册。ISO/MSP 再与支付处理商（payment processor）合作，为商户开通商户账户（merchant account）。

这一步的意义在于：生态两侧的参与者都必须先完成"身份与账户的建立"，之后每一次交易才能够在既有账户体系内流动。从仓库的 支付系统文档 可以看到类似的落点——真实的支付系统也是围绕"支付事件（payment event）→ 支付订单（payment order）→ 外部 PSP → 钱包 → 账本"的账户与订单体系来组织的。

Step 2-5：收单流程（Acquiring）

收单流程是整个交易链路的"前半程"，目标是"把钱收上来"。按指南原文拆解：

1. 支付网关（Payment Gateway） 受理购买交易，并收集支付信息（卡号、有效期、CVV 等）。
2. 交易被发送到 支付处理器（Payment Processor），处理器利用客户信息完成收款动作。
3. 收单处理商（Acquiring Processor） 将交易发送给 卡组织（Card Network）。
4. 收单处理商同时负责在结算期间"拥有并运营"商户账户——注意，这一过程不是实时的（settlement doesn't happen in real-time）。

这里的"非实时"非常关键。为什么刷卡后商户不能立刻到账？因为收单侧完成的是授权与信息流转，而真正的资金移动发生在日终清算与结算阶段。仓库的 资金流动指南 对此做了更细致的解释：整条链路分成三层——

• 交易层（Transaction layer）：在线购买发生的地方；
• 支付与清算层（Payment and clearing layer）：支付指令与交易轧差（netting）发生的地方；
• 结算层（Settlement layer）：真实资金移动发生的地方。

前两层属于"信息流（information flow）"，结算层属于"资金流（fund flow）"。信息流与资金流是分离的：在信息流中，钱看起来从 A 账户扣掉、加到了 B 账户，但真实的资金移动要等到日终，在结算银行的储备账户（reserve account）之间完成。

收单侧的真实处理链路

在 支付系统文档 中，收单侧的工程实现被拆得更细，可作为本步骤的源码级佐证：

• 用户点击"购买"后，生成支付事件并发送给支付服务（payment service），支付服务将支付事件存入数据库；
• 一个支付事件可能包含多个支付订单（例如一次结算购买了多个卖家的商品），支付服务会为每个支付订单调用支付执行器（payment executor）；
• 支付执行器将支付订单存入数据库后，调用外部 PSP（Payment Service Provider）完成信用卡支付；
• 支付执行成功后，支付服务更新钱包（wallet）以记录卖家应收金额，钱包服务将余额信息落库；
• 钱包更新成功后，支付服务再调用账本（ledger）服务追加账本记录。

由此可见，指南中的"支付处理器"在真实系统里往往被进一步拆分为支付服务、支付执行器、外部 PSP 等多个组件，职责边界清晰、逐步落库。

Step 6-8：发卡流程（Issuing）

发卡流程是交易链路的"后半程"，目标是"确认这笔钱确实来自客户"。按指南原文：

• 发卡处理商（Issuing Processor） 代表发卡行（issuing bank）与卡组织对话；
• 它负责校验（validate）并运营客户账户。

也就是说，当收单侧的处理器把交易经由卡组织送过来时，发卡侧的处理商要代表银行核实：这个客户是谁、账户是否有效、额度是否足够、交易是否被批准。这笔"批准/拒绝"的答复会沿着链路原路返回。

授权流程与捕获结算流程

仓库的 Visa 刷卡流程指南 把这一侧拆成了两个流程，可以与本指南的 Step 2-8 一一对应：

• 授权流程（Authorization Flow）：持卡人刷卡 → POS 终端把交易发给收单行 → 收单行发给卡组织 → 卡组织发给发卡行审批 → 发卡行批准后冻结资金并回传审批结果。这对应指南中收单（Step 2-5）与发卡（Step 6-8）的实时通信部分。
• 捕获与结算流程（Capture and Settlement Flow）：商户在日终点"捕获（capture）"，把交易批量发送给收单行，收单行将批次文件（batch file）提交给卡组织；卡组织对来自不同收单行的交易执行清算（clearing），并把清算文件发给各发卡行；发卡行核对无误后向相关收单行划转资金，收单行再把钱转入商户账户。

指南中强调"结算不是实时的"，与这里"日终批量捕获、次日到账"的节奏完全吻合。

清算与结算：卡组织为什么存在

为什么交易必须经过卡组织，而不是收单行与发卡行直接对账？仓库的 Visa 指南 给出了经典答案：

Visa、Mastercard、American Express 作为卡组织负责清算与结算。收单行和发卡行往往不是同一家银行。如果各家银行绕过中间机构逐笔结算，每家银行都必须与所有其他银行分别结算，效率极低。

卡组织承担了"与每家银行对话"的负担，并以此收取服务费作为回报。清算（clearing）的本质是轧差（netting）：把互为抵消的交易合并，从而大幅减少需要实际结算的交易笔数。仓库的 资金流动指南 给出了一个直观的例子：假设日终时 Bank A 欠 Bank B 100 美元，Bank B 欠 Bank A 500 美元，轧差后净头寸是 Bank B 只需向 Bank A 支付 400 美元。而真正的资金移动发生在结算银行中两个储备账户之间——各家银行在结算银行预先存入资金作为储备（money reserves）。

这也是为什么**对账（reconciliation）**在支付系统中如此重要：信息流与资金流是异步的，各环节系统之间的数据一致性必须依赖日终对账来兜底，详见仓库的 支付对账指南。该文档指出对账的三个典型痛点及应对方式：

• 数据格式不统一：不同系统的时间戳格式各异（如 2022/01/01 vs Jan 1, 2022），解决方案是增加一层做格式转换与归一化；
• 数据量巨大：需要近实时对账时用 Flink 等流式平台，日终批量对账则可用 Hadoop 等批处理方案加速比对；
• 日切时间（cut-off time）问题：内部系统记为 23:59:55 的记录，在外部系统（如 PayPal）可能被记为次日 00:00:30，导致当日匹配不上——解决方案是把这类差异归类为"临时性差异（temporary break）"，放到次日的记录里继续匹配，匹配上即销账。

生态参与者如何赚钱：一张费率结构图

理解了职责分工之后，再看各环节的收入来源。仓库的 Visa 盈利指南 用一个 100 美元交易的例子，展示了收单侧的费用拆分（以下数值为该文档举例，实际费率因商户类别、地区与协议而异）：

环节	角色	金额/比例（示例）
交易金额	持卡人向商户支付	$100
商户折扣费（merchant discount fee）	收单行与商户约定的费率，用于补偿发卡行与卡组织	覆盖 interchange fee 及以下各项
收单加价（acquiring markup）	收单行留存	$0.25
交换费（interchange fee）	支付给发卡行，由卡组织统一设定	$1.75
网络评估费与使用费（network assessments and fees）	卡组织每月向各家银行收取	如 VISA 每笔 0.11% 评估费 + $0.0195 使用费
持卡人服务费	持卡人向发卡行支付	视卡产品而定

指南与相关文档共同说明了生态里的两条"定价逻辑"：交换费由卡组织统一设定，是因为让每家发卡行与每个商户逐一谈判费率效率过低；而发卡行应当被补偿，则是因为它需要先行垫付资金（即使持卡人最终不还款也要先付给商户）、承担账户管理、账单出具、欺诈检测、风险管理、清算结算等运营成本。

从单一垂直领域到多垂直扩张

指南在结尾给出了一个对理解整个行业至关重要的观察：

注意，支付公司通常从一个垂直领域起步，但之后会扩张到多个垂直领域。

这就是 PayPal、Stripe、Square 这类公司的成长路径的抽象概括——它们往往先在某个细分环节（例如在线支付网关、移动收款终端、开发者支付 API）建立据点，再借助已沉淀的商户网络、合规牌照与技术栈，向相邻领域（收单、钱包、信贷、对账工具等）延伸。理解这张生态图，也就理解了它们各自的起点与扩张方向。

延伸阅读

本文以 the-payments-ecosystem.md 为核心，以下仓库文档可用于继续深入对应环节：

• 支付系统架构与资金流（Payment System）：支付事件、支付订单、钱包、账本的工程实现；
• 资金流动：清算与结算（Money Movement）：信息流与资金流的分离、轧差与结算层；
• Visa 刷卡全流程（Authorization & Settlement）：授权流程与捕获结算流程的逐步拆解；
• 支付对账（Reconciliation in Payment）：数据归一化、海量数据比对与日切问题的解决方案；
• 支付行业学习路线（How to Learn Payments）：监管机构、央行、商业银行、清算网络、结算系统的行业全景；
• Visa 如何赚钱（How Does Visa Make Money）：商户折扣费、交换费与网络评估费的费率结构；
• ACH 支付如何工作（How ACH Payment Works）：以批次处理与日切截止时间为特点的另一种清算网络形态。

结合这些文档，你可以从"生态全景 → 单笔交易链路 → 清结算机制 → 对账一致性"逐层建立完整的支付知识体系，这套框架同样适用于系统设计面试中回答"设计一个支付系统"类问题。