撰文：阿望，Web3小律
数字支付已经进入主流，但结算还没有。
这是前 Visa 高管、Beam 创始人 Dan Mottice 的判断。Visa 的交易在全球任意商户完成授权，但背后的结算仍然跑在 SWIFT 上——聚合批量交易，通过跨境电汇转移资金，经历本地监管、节假日、多级中间行，然后商户等着收款。这不是 Visa 的问题，是整个行业的结构性欠账。而 PSP，是这笔欠账最集中的地方。
本文聚焦支付服务商（PSP），它已从单纯的收款工具，演变为治理资金流动、结算与记账的核心基础设施层。它们最初是为一个更简单的时代设计的——单轨道系统、线性交易流程、高度捆绑的基础设施。
在现代支付环境中，一笔「支付」不再是单笔交易，而是跨多个参与方和支付轨道的一系列状态转变。今天，一笔支付可能涉及：C 端应用、PSP、反欺诈 / 身份核验服务商、托管银行、一条或多条支付轨道，以及企业内部的记账系统。
企业必须同时支持银行卡、ACH、电汇、RTP、FedNow，乃至越来越多基于稳定币的结算。每种轨道都有不同的结算时效、故障模式、数据格式和运营要求。
本文编译了 Modern Treasury 的指南，将探讨 PSP 如何演变、其底层架构需要如何适应现代支付系统，以及正在构建支付产品的团队在选择下一个 PSP 时应采取怎样的策略。
核心判断
01｜数字支付进入了主流，但结算没有。 Visa 让你在全球任何商户完成授权，但背后的结算仍然跑在 SWIFT 上。界面解决了，底层没解决。
02｜PSP 执行支付，但不解释资金流动。 Stripe 告诉你它那一段发生了什么，但告诉不了你这笔钱现在真实的状态是什么。执行层和记录层，是两件不同的事。
03｜每条支付轨道是一套独立的操作系统，不是同一模型的变体。 ACH 可以撤销，RTP 不能；卡网络可以争议，稳定币是链上最终确认。PSP 的抽象层掩盖了这些差异，但只掩盖到出问题为止。
04｜实时支付消灭了缓冲器，控制必须前移。 传统 PSP 的风控、审批、对账逻辑，都假设「出错了还有时间补救」。RTP 和 FedNow 让这个假设不再成立。决策必须在资金移动之前完成，不是之后。
05｜稳定币是结算轨道，不是新的支付方式。 它解决的不是支付界面的问题，是资金从「记账完成」到「实际到账」之间的那段延迟。最实际的落地路径是三明治结构：法币进、链上流转、法币出，两端用户不需要懂稳定币。
06｜在途资金可以产生收益，这在传统体系里几乎不存在。 跨境支付中，资金在结算完成之前沉淀 24 到 72 小时，既无收益，又占用营运资本。稳定币第一次让「流动中的资金」也能产生价值。
07｜支付运营最大的失败，是无法回答一个简单问题：这笔钱去哪了。 对账、异常处理、流动性管理——这些问题不在支付发起时出现，在事后出现。没有统一的协调层，每个服务商只能告诉你它自己那一段的故事。
08｜真正的战略风险，不是你用不用稳定币。 而是竞争对手用稳定币重构了他们的结算成本和资金效率，而你还在等一个完美的入场时机。
一、PSP 的历史演进
过去二十年，PSP 的角色发生了根本性变化。
电子商务早期，PSP 主要作为支付网关运作。它们的职责简单明了：将商户连接至卡网络和收单银行，使交易得以授权和结算。
这些 PSP 系统是为一个非常特定的世界设计的。支付以卡为主，流经单一商户账户，遵循从授权到结算的线性生命周期。PSP 被优化为在这一模型内高效处理交易。
2010 年代，Marketplace、SaaS 平台和金融科技产品开始将支付直接嵌入其产品。平台需要完成用户入驻、在多方之间拆分支付、管理打款。PSP 随之扩展，引入了商户入驻、打款基础设施和欺诈防控工具。
然而，尽管 PSP 的能力不断扩展，其底层架构仍然植根于为线性支付流程设计的模型——主要针对交易处理优化，而非协调跨服务商、跨轨道的复杂多步骤资金移动。
到 2020 年代初，企业开始跨多条轨道、多个地域和多种场景运营。传统 PSP 继续捆绑众多组件，让企业与单一平台交互。但随着支付流程变得更加复杂，一个支付流程可能跨越多个步骤：身份核验、风险排查、资金决策、轨道执行、内部追踪。
这一转变使 PSP 的角色从「连接者」演变为「协调者」（from connectors to coordinators），但其架构并未以同等速度演进。
结果是：PSP 仍然负责转移资金，但是在一个更加复杂的完整交易支付生命周期的环境中运作。
二、现代 PSP 支付技术栈
要理解 PSP 的局限，必须先理解其所处的更广泛支付环境。
2.1 PSP 技术栈
现代支付环境并非单一平台或服务商，而是一套分层的基础设施组件，共同支撑资金的移动、结算与记账。
应用层：支付发起的电商平台、Marketplace、金融科技 App、嵌入支付的 SaaS 产品。
PSP 层：负责执行支付指令（executing payment instructions），如将交易路由至卡网络、发起银行转账、接入支付轨道。在大多数情况下，这些底层复杂性被抽象在 PSP 的接口之后，用户与单一系统交互，而非直接面对其背后涉及的多个服务商。
合规层：现代支付流程还依赖身份核验服务商、欺诈检测工具和合规基础设施，这些系统决定支付是否应当被允许推进。
银行层：托管银行持有资金、提供受监管账户，并支持对 ACH、电汇、RTP 和 FedNow 等支付网络的接入。
内部对账层：企业用于追踪余额、表示交易状态、维护财务活动一致性记录的系统。
上述每一层都在资金移动中扮演着角色，但没有任何一个能提供支付发起后实际发生情况的完整图景。这正是内部对账层变得不可或缺的原因。
2.2 同步与异步
传统 PSP 有一个根本性的设计缺陷：它只管把钱发出去，不管发出去之后发生了什么。
问题在于，「发出去之后」恰恰是支付最复杂的部分。
PSP 的 API 接口逻辑是同步的——你发一条指令，它返回一个结果。但真实的资金流动是异步的：结算是事后才完成的，失败是延迟才浮现的，退款和冲正随时可能打回来。这个错配，制造了一个持续存在的信息黑洞。
黑洞的具体表现，是状态碎片化：
没有任何一个节点能告诉你，这笔钱此刻的真实状态是什么。
以市场平台的卖家提现为例，整个流程是一条很长的链：核验资格 → 风控合规 → 确认资金 → 发出指令 → 轨道执行 → 返回确认 → 事后结算 → 更新账本。PSP 只覆盖中间几个环节，前面的决策和后面的对账都不在它的职责范围内。一旦这笔打款失败或被退回，没有任何一个系统能给出完整的答案。
这就是内部对账层存在的意义：它不替代 PSP 执行支付，而是在整条链的上方建立一个统一的观察层——把来自不同服务商、不同时序、不同格式的异步事件，持续翻译成企业内部可以信赖的单一状态。不管钱流经了多少个中间环节，始终有一个地方能回答那个最基本的问题：这笔钱，现在到底在哪里。
三、传统 PSP 的支付局限
传统 PSP 的抽象层围绕银行卡支付构建——授权、捕获、结算，生命周期可预测。虽然也存在例外（如争议和拒付），但整体结构可预测且被充分理解。这一模型塑造了 PSP 的设计方式。
随着新支付方式的出现，PSP 将支持范围扩展至更多轨道，但这些轨道的行为与银行卡不同，也不符合相同的假设：
- ACH 转账：引入了延迟，以及支付发起后数天内仍可能被退单的可能性。
- 电汇：结算更快，但通常需要人工流程且成本较高。
- RTP 和 FedNow 等实时支付网络：实现资金的即时移动，但交易一经完成通常不可撤销。
- 稳定币转账：运行于完全不同的基础设施之上，具有不同的保障机制和运营考量。
以一笔美国企业打款给菲律宾供应商为例：
- 走 ACH，T+2 到账，但菲律宾银行不直接接收 ACH，中间还要转一次本地轨道，实际到账可能 T+4，期间随时可能因账户信息不匹配被退单。
- 走电汇，快一些，但要赶在下午 3 点的 wire cut-off 之前提交，遇到节假日顺延，SWIFT 手续费 $25 到 $45，收款方银行还可能再扣一笔中间行费用，最终到账金额和发出金额对不上。
- 走稳定币三明治，USDC 从美国账户发出，链上几秒确认，菲律宾合作伙伴收到后换成比索打入本地账户，全程不超过一小时，成本低于转账金额的 1%。
三条路，同一笔钱，结算时间差了 96 小时，成本差了几十美元，可追溯性也完全不同。这不是产品体验的差异，是三套操作系统之间的差异。PSP 的抽象层无法掩盖这些，只能把差异向上推给开发者和运营团队去消化。
这些不是同一支付模型的变体，而是根本不同的操作模型。
传统 PSP 的应对方式是为每种轨道暴露不同的 API 和状态定义——没有真正统一差异，只是把差异向上推给了开发者。工程团队开始为每条轨道写特殊逻辑，运营团队开始手动处理不同故障模式，财务团队开始对账走过完全不同路径的同类交易。
这就是抽象泄漏：原本应该被屏蔽的轨道复杂性，开始渗透到应用层。
随着更多轨道被添加进来，支付环境变成了一系列松散连接的集成，而非统一的抽象层。在较慢的轨道上，延迟为检测问题提供了时间窗口。在实时轨道上，这一窗口消失了——支付在数秒内完成结算，错误无法轻易撤销，决策必须在资金移动之前做出，而非之后。
四、实时支付迫使 PSP 将控制前移
向实时支付网络的转变，不仅仅是加快了资金流动速度——它从根本上改变了支付基础设施的设计要求。
在 ACH 和电汇的时代，时间是一个缓冲器。
ACH 可能需要数天结算，银行卡交易可以在授权后发起争议，电汇也往往涉及人工审核步骤。这些延迟虽然带来效率损耗，但也为检测错误、干预可疑活动、在结算最终化之前完成对账提供了机会。
传统 PSP 模型正是围绕这一缓冲器构建的。
然而，RTP、FedNow 等实时支付网络彻底打破了这一假设。资金在数秒内直接在账户间流动，支付一旦完成通常不可逆转。
- 欺诈检测必须更早完成
- 合规筛查必须实时进行
- 资金决策必须在支付释放的瞬间准确完成
- 事后纠错的机会不复存在
提供即时打款的平台无法依赖为延迟结算设计的工作流。跨多个账户管理支付资金的企业内部系统，无法在执行瞬间确定流动性。客服团队无法承诺可撤销性，当底层轨道根本不允许的时候。
结果是责任的转移：PSP 必须演进，以支持那些决定支付应何时执行的内部系统。换言之，控制必须前移。
支付基础设施必须被设计为：审批、资金逻辑、风险核查和状态验证必须在资金流动之前完成，而非之后。这要求对余额、交易状态和跨服务商条件有比传统 PSP 架构所能提供的更协调的视图。
实时轨道不是终态，只是一个拐点。稳定币进来之后，问题会进一步升维。
五、稳定币：新轨道，不是新支付方式
稳定币最容易被误解的地方，是把它当成一种新的支付产品。它不是。它是一条新的结算轨道，解决的是资金从「记账完成」到「实际到账」之间的那段延迟。
与卡、ACH、电汇不同，稳定币交易运行在区块链网络上：
- 结算持续进行，而非批量处理
- 可接近即时最终确认（取决于网络）
- 7×24 小时运转，不受银行截止时间和节假日限制
- 不依赖特定国内支付系统
- 追踪余额、所有权和交易历史的原语完全不同
传统 PSP 架构围绕银行和支付网络的集成构建，稳定币引入了不依赖这些中间商的网络。起源、结算、记账均发生在原始设计之外。一个企业可能同时需要协调银行轨道、实时网络和链上结算，每种类型对最终性、时序和控制的假设各不相同——这些差异无法通过单一 API 统一，PSP 作为单一抽象层的定位愈加难以维持。
如同实时支付系统挑战了关于时序和可撤销性的假设，稳定币挑战了关于支付发生地点和表示方式的假设。
此过程中，它们引入了一层新的复杂性。
稳定币三明治，是当前最实际的落地路径：法币进 → 链上流转 → 法币出。
交易两端的客户和供应商不需要懂稳定币，稳定币只是中间通道——专门用于解决传统跨境结算慢、贵、不稳定的那段路径。最有价值的应用集中在「困难通道」，即传统方式慢、贵或根本不可达的跨境场景。
企业不会也不应该 All-in 稳定币，现实路径是选择一两个具体用例做局部替换，建立认知之后再扩大。
稳定币还带来了一个额外维度：在途资金收益，这在传统体系几乎不存在。传统支付流程中，资金从发出到到账，中间沉淀 24 到 72 小时，既无收益，又占用营运资本。链上稳定币可以在流动中产生收益——这不是对支付成本的小幅优化，是对整个资金效率逻辑的重构。
六、当前生态：十层分工与缺失的那一层
随着支付基础设施跨越更多轨道、更多服务商和更多基础设施类型，PSP 角色的定义变得越来越困难。
过去在单一 PSP 内捆绑的资金移动职责，现在已成为分布在技术栈多个层次上的一系列责任。
PSP 的工作不再只是移动资金，而是解释资金的流动。
这一转变反映了更深层的变化：执行本身已不再足够。PSP 现在必须支持企业的内部系统，使其能够表示、记账和对账资金如何跨不同环境流动。
① 产品层平台：将支付嵌入软件
Shopify、Square、Toast、Mindbody、ServiceTitan、Housecall Pro 等垂直软件平台将支付直接嵌入其产品。
在这些场景中，支付被整合进应用体验，而非作为独立的支付系统处理。这些平台通常依赖底层 PSP、银行合作伙伴和基础设施服务商，在应用与资金流动之间叠加了另一层抽象。
② 执行层：跨轨道资金移动
技术栈的核心是负责执行支付的服务商。包括 Stripe、Adyen、Checkout.com、Worldpay、PayPal、Nuvei、dLocal 等传统 PSP，其角色是将企业连接至支付轨道并促进资金移动。
它们仍然是支付技术栈的关键组成部分，但主要在执行层运作——发起支付、报告状态、暴露 API，但本身并不提供资金如何跨服务商和内部系统流动的完整模型。
你问 Stripe「这笔钱现在到底在哪」，它只能告诉你它自己那一段发生了什么。Stripe 只是其中一个节点，这个交易里还可能包括 PSP、银行、轨道、内部账本四五个环节，但它看到的永远是局部，不是全局。
③ 编排与路由层：连接执行服务商
随着企业采用多个 PSP 和支付方式，编排平台应运而生，负责管理跨服务商的路由。Primer、Gr4vy、Spreedly、Paydock、CellPoint Digital 等公司允许企业根据地域、成本或性能来引导交易。这些系统提升了执行层的灵活性，但不提供支付发起后行为的统一模型。
④ 风控与合规层：决定资金是否应当移动
一批独立的服务商负责判断支付是否应被允许推进。Persona、Sardine、Alloy、Unit21、Sift、Sumsub 等供应商的身份核验、欺诈检测和合规系统，在执行前对用户和交易进行评估。在实时环境中，这些决策必须在资金移动之前完成，关键控制逻辑因此被移至 PSP 之外。
⑤ 银行基础设施层：持有资金并支持接入
Cross River Bank、Lead Bank、Column、Sutton Bank 等托管银行提供受监管账户和对支付网络的接入。它们持有客户资金、管理流动性，并充当接入 ACH、电汇、RTP 和 FedNow 等轨道的门户。这一层对接入金融系统至关重要，但独立于应用逻辑和 PSP API 运作。
⑥ 卡发行层：扩展支付功能
Marqeta、Lithic、Rain 等卡发行平台使企业能够作为其产品的一部分发行借记卡和信用卡，支持费用管理、企业卡和市场消费等使用场景。发行平台连接银行和卡网络，但作为技术栈中独立的一层运作，引入了需要与支付技术栈其他部分协调的额外工作流、控制机制和状态。
⑦ 支付轨道层：底层执行网络
支付轨道是在金融机构间移动资金的网络。传统轨道包括 ACH、电汇和卡网络，而 RTP 和 FedNow 等新网络则支持实时结算。每条轨道在时序、最终性和可撤销性方面的假设各不相同，制造出 PSP 必须暴露或规避（而非完全抽象）的不一致性。
⑧ 稳定币网络层：扩展至银行基础设施之外
以太坊、Solana、Polygon、Base 等稳定币网络引入了一种运行于传统银行体系之外的支付基础设施新形式。这些网络以不同的结算模型和保障机制，在全球基础设施上实现数字美元的转账。它们将支付系统的范围延伸至基于银行的轨道之外，为现有工作流带来了必须整合的额外复杂层。
⑨ 银行即服务层：连接应用与银行
Unit、Galileo、Treasury Prime 等银行即服务（BaaS）平台提供连接金融科技应用与受监管银行的基础设施。它们使企业无需成为银行即可提供账户、卡和支付能力。这一层简化了对银行基础设施的接入，但在应用、PSP 和底层资金流动之间增加了另一个中间方。
⑩ 缺失的那一层：覆盖资金流动完整生命周期的统一 PSP
纵观以上九层，规律是一致的：每个服务商负责特定功能，没有任何一个能独立提供资金流动的完整视图——包括对它的理解、控制与对账。
执行由一个服务商处理，风险决策由另一个处理，资金托管在银行，支付流程可能跨卡网络、实时轨道和链上系统延伸。每个系统暴露不同的数据、时间线和状态定义。
在碎片化的环境中，这个问题不在发起阶段显现——它在事后出现：当系统出现分歧、资金延迟或被退回、团队需要答案的时候。这正是支付系统开始崩溃的地方。
七、支付运营在哪里崩溃
周五下午 2 点 55 分，财务团队提交了一笔 $50,000 的供应商电汇。3 点整，银行 wire cut-off。系统显示「已提交」，但确认邮件没有进来。
下午 4 点，供应商发消息问款项状态。财务去查 PSP 后台，显示「处理中」。去查银行账户，显示「待结算」。两个系统，同一笔钱，两个不同的状态，没有一个能告诉你钱现在在哪个节点。
周五下午 5 点，银行客服下班。供应商在等款项安排周末的货运。财务团队不知道该告诉供应商什么，也不知道周一早上钱会不会自动到账，还是已经被退回需要重新发起。
这不是极端情况，是支付运营团队每周都在经历的场景。它不会出现在 PSP 的产品手册里，但会出现在每一家跨境支付团队的工作记录里。
支付中最棘手的问题往往不在发起阶段，而在事后——当团队需要解释究竟发生了什么。
上一章的市场地图揭示了支付生态系统的广度。一笔看似单一的支付，往往在结算发生之前已经流经技术栈中的多个服务商。每一方可能对同一笔资金移动有不同的表示，时序不同，状态不同，文件按不同时间表到达，异常通过不同渠道报告。
这正是支付运营变得困难的地方。
对账：同一事件的多个版本
财务团队需要将内部账本与银行流水、结算报告、处理商数据进行匹配。如果一个服务商显示支付已完成，另一个显示仍在处理中，企业需要一套解决差异的模型。如果退单在内部余额已更新后才到达，账本需要相应撤销或调整。
异常处理：没有明确归属的故障
一笔出款可能因目标账户无效、使用了错误的资金账户、合规审查挂起交易或错过轨道截止时间而失败。这些故障并不相同，也不在同一时间发生。但用户仍然期待得到一致的答案，内部团队仍然需要处理流程。
流动性与资金：钱在错误的地方
跨多个服务商和账户运营的企业，必须确保正确的资金在正确的时间出现在正确的账户中。即便整体余额充裕，若资金停留在错误账户，支付执行仍可能失败——这制造了产品逻辑与运营现实之间的鸿沟。
可审计性与控制：还原发生了什么
审批、挂起、释放和对账操作跨团队和系统发生，企业需要可靠记录谁在何时做了什么、以及为什么。这不仅是合规要求，也是出问题时追溯交易历史的基础。
这些问题既是运营层面的，也是架构层面的。
支付运营中最大的失败，往往发生在团队无法回答一个简单问题的时候：这笔钱到哪里去了？
所缺失的，不是另一个在现有模型内执行支付、路由交易或持有资金的服务商，而是一个能够协调所有这些功能、跨服务商追踪状态、管理资金流动工作流、并随时间维护可靠财务记录的进化型 PSP。
八、PSP 的下一次进化
挑战不在于接入支付基础设施，而在于能否对资金在其中流动的方式保持一致、可靠的理解。
当前生态的分工：PSP 执行支付，银行持有资金，合规系统评估风险，编排工具路由交易。但没有任何单一服务商负责提供跨支付全生命周期资金流动的完整一致视图。
PSP 的下一次进化方向，是提供覆盖整个技术栈的一致可见性——让每一笔支付从发起到最终结算，都能被理解、被记账、被信任。
这一层必须能够：
- 跨银行、传统轨道和稳定币网络执行支付
- 通过内部账本维护一致的记录系统
- 管理审批、资金和异常处理的工作流
- 将外部活动与内部财务状态进行对账
- 随规模扩展，内置合规、账户基础设施和持续增长的轨道连接
结语：从哪里开始
现代支付基础设施不再由单一处理商或单一轨道定义。它是一个由多个服务商组成的环境，每个服务商负责资金流动、审批、结算和记账的不同环节。
纵观本指南，我们看到了这一环境的演变历程：
支付服务商超越了交易处理的范畴，支付轨道不断增多，实时系统移除了延迟结算的安全网，稳定币等新形式的基础设施进一步延伸了整个系统。
对于构建金融产品或将支付嵌入软件的团队而言，切入路径比战略讨论更重要。
不要从「是否全面拥抱稳定币」开始，而是找一个具体痛点：一条跨境通道结算太慢，一个供应商付款流程人工操作太多，一部分闲置资金在途中没有收益。选一个用例，开一个账户，做一次实际支付。先内部试点，从资金管理（treasury）场景入手，而不是直接改造客户侧流程。这样可以控制风险，同时建立认知。
合规层面，KYC、AML、制裁筛查等规则仍然完全适用，稳定币只是底层轨道的变化。监管框架在 GENIUS Act 之后已经比两年前清晰很多，不应成为阻碍试点的理由。
真正的战略风险不是你用不用稳定币，而是竞争对手用稳定币重构了他们的结算成本和资金效率，而你还在等一个完美的入场时机。
缺少统一协调层，复杂性随规模增长而叠加。拥有它，企业可以以清晰、掌控和自信的姿态运营资金流动。
部分内容来源：Modern Treasury — A Practical Guide to PSPs in 2026
