支付行业里最常见、也最容易被误解的词之一，就是 PSP。
很多人第一次进入行业时，会自然地把它理解成一个简单角色：
- 一个帮商户收钱的第三方
这个理解不能说错，但如果停在这里，很快就会发现越来越多事情解释不通。
为什么同一家公司有时候被叫 PSP，
有时候又被叫 PayFac、ISO、MSP、Marketplace、MoR、TPSP、MPI、PISP？
为什么同一家公司在不同会议、不同协议、不同审计文件里，身份看起来完全不一样？
问题不在于行业乱用名词，
而在于一个更底层的现实：
PSP 早就不是一个单一角色，而是四套并行系统里的重叠存在。
这四套系统分别是：
- 商业/业务视角
- 卡组织视角
- PCI DSS 视角
- 监管视角
很多支付行业的误判，都是因为把这四套话语体系混在一起看。
而一旦拆开，你会发现所谓的“PSP 复杂”，其实不是复杂在术语多，
而是复杂在：
同一家支付公司，可能同时生活在四套不同的制度世界里。
一，商业视角下，PSP 只是一个泛称，但行业真正运作靠的是层级分工
在商业语境里，PSP 是一个很宽的词。
它可以泛指任何帮商户接受支付、做网关、做风控、做结算、做对账的第三方。
这个语境里的典型代表包括：
- Stripe
- Adyen
- Checkout.com
- PayPal
- Airwallex
但如果继续往下看，就会发现“PSP”其实只是一个外壳。
真正重要的是它在商业结构里扮演哪一种变体。
例如：
- LPSP 强调的是本地支付方式接入和本地牌照
- SPSP / Sub-PSP 强调的是挂靠在主 PSP 下面的二级结构
- PayFac 强调的是聚合 sub-merchant 的模式
- ISO / MSP 强调的是代表收单行销售和拓展商户，但不持有商户资金
- Marketplace 强调的是平台撮合与多边交易组织
- MoR 强调的是谁在交易记录上承担最终法律与财务责任
也就是说，商业视角里的 PSP，从来就不是一个稳定的单点角色，
而更像是一整个家族。
这也是为什么很多公司表面上都叫 PSP，
但商业模式完全不一样。
有的 PSP 真正在卖的是：
- 接入能力
- 本地支付方式覆盖
- 风控和收单成功率
有的在卖的是：
- 平台化聚合能力
- 商户 onboarding
- 资金分账和 marketplace 编排
有的则更接近：
- Merchant of Record
- 税务与法务责任外包
- 全球销售名义承接
所以在商业世界里，PSP 更像一个入口词，而不是一个精确定义。
二，卡组织视角下，PSP 不是“支付产品”，而是“接入身份”
如果切换到 Visa、Mastercard 这类卡组织的语境，世界马上就变了。
在这里，行业不太关心你 marketing 怎么讲，
也不太关心你 checkout 页面是不是好看。
它们更关心的是：
你到底以什么身份接入网络、提交交易、服务商户、承担责任。
于是你会看到另一套术语系统：
- PayFac
- ISO / MSP
- Marketplace
- SDWO / PTDW / DWO
- Token Requestor
- Token Service Provider
这套体系和商业视角最大的不同在于：
它不是在描述你卖什么，而是在定义你怎么合法地存在于卡网络里。
举个最典型的例子。
在商业视角里，很多公司都可以自称 PSP。
但在卡组织视角里，PayFac 和 ISO/MSP 是完全不同的结构。
- ISO / MSP：为每个商户开独立账户，更多像销售/代理渠道
- PayFac：在主 MID 下聚合多个 sub-merchant，自己承担更多商户管理和交易责任
再比如，做 Network Tokenization 的公司，还可能要以 Token Requestor 的身份存在。
这个身份和 PayFac 并不互相替代，而是并行叠加。
所以一家公司在商业上可以说“我们是全球 PSP”，
但在卡组织那边，它可能同时又是：
- 一个 PayFac
- 一个 TR
- 某些场景下的钱包运营相关角色
这就是支付行业结构复杂的真正来源之一。
不是概念混乱，而是网络接入身份本来就多层。
三，PCI DSS 视角下，PSP 不再是商业角色，而是安全责任节点
再切换到 PCI DSS 语境，事情又会彻底变一个样子。
在这里，行业关心的不是：
- 你卖什么
- 你怎么收钱
- 你是不是平台
而是：
你有没有接触、处理、存储、传输持卡人数据，或者影响持卡人数据的安全。
于是 “TPSP” 在这里的意思就完全不同了。
它指的是 Third Party Service Provider，也就是可能直接处理卡数据，或者影响卡数据安全的第三方服务商。
这个定义非常关键，因为它会把很多商业上不被直觉认为是“支付公司”的角色也拉进来：
- tokenization service
- fraud vendor
- 3DS server provider
- 云基础设施
- 某些客服和外包处理团队
更重要的是，PCI 还会出现 Nested TPSP 这种链式责任结构。
也就是说，在真实世界里，路径可能是：
- Merchant
- PSP A
- PSP B
- Cloud provider
- Data center
从 PCI 角度看，这不是一条单纯的商业合作链，
而是一条责任链。
所以在 PCI 世界里，PSP 不是“帮助交易的人”，
而是“安全边界中的责任节点”。
这也解释了为什么很多支付公司在审计和合同里显得比产品页面上复杂得多。
因为一到 PCI 语境，产品包装会退后，责任边界会冲到最前面。
四，监管视角下，PSP 甚至不一定存在，真正存在的是牌照和业务类型
最后再切到监管视角，你会发现“PSP”这个词本身有时都不再重要了。
监管者真正关心的是：
- 你做的是什么支付服务
- 规模多大
- 有没有持牌
- 适用哪套规则
- 触发哪些资本、申报、客户资金、AML、消费者保护义务
例如在新加坡 MAS PSA 体系下，大家更常看到的是：
- SPI
- MPI
- 以及 7 类具体支付服务
在 PSD2 体系下，则是另一套：
- ASPSP
- PISP
- AISP
- CBPII
- TPP
这时候如果你还用一个宽泛的“PSP”去理解一切，就会不断出错。
因为监管不是在给你一个 marketing category，
而是在判定：
你能不能做某项业务，以及你需要为此承担什么监管义务。
所以一家支付公司在监管者眼里，未必是一个“PSP”，
而可能是：
- 一个 Major Payment Institution
- 一个 Merchant Acquirer
- 一个 Cross-border Money Transfer provider
- 或者一个 PISP/AISP 类角色
这和商业、卡组织、PCI 的定义都不是一回事。
五，真正让支付行业复杂的，不是术语太多，而是同一家公司同时存在于四套系统里
如果把前面几层重新压一下，我觉得最值得记住的一句话是：
支付行业真正复杂的地方，不是名词多，而是同一家公司经常同时活在四套系统里。
比如一家公司可能：
- 在商业上是全球 PSP
- 在卡组织里是 PayFac / TR / wallet 相关注册角色
- 在 PCI 世界里是 TPSP，甚至还有自己的下游 Nested TPSP
- 在监管上又是 MPI、PI、EMI 或某种 money transfer / merchant acquisition license holder
这四个身份不会互相取消，
而是叠加存在。
这也意味着行业里真正成熟的理解方式，不是问：
- 这家公司到底是什么？
而是问：
- 在商业上它是什么？
- 在卡组织规则上它是什么？
- 在 PCI 责任链里它是什么？
- 在监管制度里它又是什么？
只有这样看，很多“看起来矛盾”的现象才会变得清楚。
六，未来支付竞争不只是产品竞争，也会越来越是角色编排能力的竞争
我觉得这篇最值得往下延伸的一点，是很多人会低估角色编排本身的价值。
过去大家看支付，更容易盯：
- 费率
- 成功率
- 支付方式数
- 页面体验
- 风控模型
这些当然重要。
但随着市场越来越复杂，真正能建立壁垒的，还包括：
谁更能把这些角色关系编排清楚。
因为你一旦跨境、跨牌照、跨钱包、跨卡组织、跨 token、跨 open banking，
你就在同时处理：
- 商业角色
- 卡组织接入角色
- 安全责任角色
- 监管角色
这意味着未来强的支付公司，未必只是技术最强，
而更可能是：
- 最懂多角色叠加
- 最会做结构设计
- 最会把复杂责任压成清晰产品
- 最会把四套系统翻译成对商户可用的能力
结语
如果今天要给这轮整理压一句最核心的话，我会这样写：
PSP 早就不是一个角色，而是四套并行系统。
商业视角里，它是一个业务家族；
卡组织视角里，它是接入身份；
PCI 视角里，它是安全责任节点；
监管视角里，它又被拆成不同牌照和业务类型。
所以未来真正理解支付行业，不该再问：
- PSP 是什么？
而应该问：
- 它在四套系统里分别是什么？
只有把这四层拆开，很多关于 PayFac、ISO、MSP、TPSP、Marketplace、MoR、MPI、PISP 的混乱，才会真正变成结构化认知。
而这，才是支付行业从“术语理解”走向“结构理解”的起点。