Stripe 眼中的 MoR：Marketplace、PayFac 与交易责任如何区分

最近在看 Stripe Connect 的一份官方文档，标题叫《Determine and configure the merchant of record (MoR)》。

原本以为只是讲几个支付参数怎么配置，结果仔细读下来，发现里面有些内容还挺值得支付行业认真聊聊。

尤其是 Stripe 对 Marketplace 的解释。

在这份文档中，Stripe 列举了三种典型场景：

SaaS 平台、以自己名义销售商品或服务的 Marketplace，以及帮助不同卖家完成交易的 Marketplace。

有意思的是，后面两种 Marketplace，Stripe 给出的典型 MoR 都是平台本身。

这和很多人的直觉可能不太一样。

我们平时理解 Marketplace，往往会把它看成一个撮合交易的平台。消费者购买的是第三方卖家的商品，平台提供流量、订单、支付和售后服务，最后从交易中收取佣金。

既然商品不是平台的，为什么平台可以成为 MoR？如果平台成为 MoR，是不是意味着平台必须拥有商品所有权？如果平台只是代收资金，能不能把自己定义成 MoR？再往下问，Marketplace 和 Payment Facilitator（PayFac）到底有什么区别？

这些问题其实涉及支付行业一个长期存在的混淆：

我们经常把商业交易中的销售主体、银行卡收单体系中的商户身份，以及资金结算中的收款主体，当成同一个概念。

在传统单一商户模式下，这样理解通常不会出太大问题。消费者向商户购买商品，商户通过收单机构收款，资金最终进入商户银行账户。消费者合同、支付交易和资金结算大多指向同一个主体。

但到了 Marketplace、SaaS 和 MoR 服务商这里，这几个角色就不一定重合了。

当然，这其实不只是 Stripe Connect 的产品设计问题。Visa 在其《Payment Facilitator and Marketplace Risk Guide》中，也对 Marketplace 和 PayFac 做出了明确区分。在该指南描述的 Marketplace 模式下，平台可以代表底层零售商处理支付，并在相应的银行卡交易中被视为 Merchant of Record。

这意味着，至少在 Visa 的特定 Marketplace 收单框架中，平台即使不是商品的最终提供方，也可以成为银行卡交易中的 MoR。

但这里有个非常重要的前提。

它必须是真正符合相应卡组织规则、并获得收单机构认可的 Marketplace，而不是随便找一家香港公司，开一个普通商户账户，再把几百家商户的交易集中收进来。

这两件事，完全不是一个概念。

一、谁才是真正的 MoR？可能和你理解的不一样

先看一个实际业务中很常见的场景。

一家中国 AI 公司开发了一款面向全球消费者的 AI 应用，每个月收取 20 美元订阅费。但这家公司没有海外主体，也没有能力直接接入国际收单机构。

于是它找到一家香港支付平台。香港平台提供收银台、信用卡收单、订阅管理、退款、拒付处理以及跨境结算。消费者支付的 20 美元，通过香港平台接入的收单机构完成处理。平台扣除服务费，再把剩余款项结算给 AI 开发者。

那么问题来了。这笔交易的 MoR 到底是谁？

很多人可能会说，当然是香港平台。因为它签了收单合同，资金通过它的账户处理，拒付发生时也可能先从它的余额扣款。

但按照 Stripe 的判断逻辑，事情没这么简单。

Stripe 对 MoR 的定义，首先强调的是消费者认为自己正在向谁购买商品或服务，以及谁对交易承担责任，包括退款、争议等消费者救济。

它给出了四个判断维度。

消费者认为自己向谁购买商品？

谁对消费者的退款和拒付承担责任？

银行卡账单显示的是谁的品牌？

谁拥有商品所有权，或者有权提供、转售相关服务？

其中Stripe 明确指出，不能仅仅根据 Charge Type 或支付配置来判断 MoR。

甚至商品所有权，也不是一个能够单独决定 MoR 的标准。

例如，平台在交易过程中短暂获得商品所有权，并不意味着平台自动成为 MoR。如果消费者始终认为自己是在向第三方卖家购买商品，那么这种短暂的货权转移并不足以支持平台的 MoR 身份。反过来，如果消费者面对的是平台品牌，交易责任也由平台承担，那么即使商品来自第三方卖家，平台仍然可能成为 MoR。

这里真正重要的是消费者面对的商业关系，而不是后台资金经过了几个账户。

这也是 Stripe 这份文档最值得关注的地方。

MoR 应当由真实交易关系决定，而不是由支付系统的技术架构倒推。

但如果只看 Stripe 的文档，可能会认为 Marketplace 成为 MoR，只是 Stripe Connect 的一种产品设计。

实际上，Visa 在其 Marketplace 规则框架中，也明确讨论了类似安排。Visa 的《Payment Facilitator and Marketplace Risk Guide》将 Marketplace 描述为一种通过统一品牌平台连接买家和零售商，并代表零售商处理线上支付的第三方机构。在这一框架下，Marketplace 与收单机构签约，接收交易结算资金，并在银行卡收单体系中被视为 MoR。

但是这里有一个很重要的细节。

Visa 并没有要求 Marketplace 必须先买下所有商品，再转售给消费者，才能成为卡交易中的 MoR。

在它描述的 Marketplace 模式中，底层零售商仍然存在，平台可以代表这些零售商接受支付。

这和传统的自营电商并不完全一样。例如，一家平台允许几千家独立卖家销售商品。消费者在平台的网站上浏览、下单、付款。商品由卖家提供，平台负责统一支付体验、交易管理、消费者支持以及相应的结算安排。在符合适用规则的前提下，这种平台可以采用 Marketplace 收单模式，由平台在卡交易中承担 MoR 身份。

但这不等于平台在所有法律关系中都自动成为商品的所有权人或税法上的销售方。卡组织对交易责任的安排，与民商法、会计和税务对销售主体的判断，需要分别分析。

这里其实有一个容易被忽略的问题。Stripe 和 Visa 都在讨论 MoR，但两者的出发点并不完全相同。

Stripe Connect 更关注如何根据消费者交易关系，正确配置平台与关联账户的支付身份。Visa 的 Marketplace 框架则涉及银行卡收单网络中的商户识别、交易处理和责任安排。

二者存在交集，但不能认为 Stripe Connect 中的 MoR 配置，就自动满足 Visa 所有 Marketplace 规则。更不能由此推导出，所有自称 Marketplace 的平台，都可以直接使用普通商户账户处理第三方交易。

对于一家想做全球支付的平台来说，真正的问题不是：我能不能把自己叫作 Marketplace？

而是：

我的交易结构，究竟符合哪一种银行卡收单模式？收单银行是否按照这种模式为我进件？

这两个问题如果没有解决，仅仅把网站包装成 Marketplace，并不能解决收单合规问题。

二、Marketplace 和 PayFac，到底有什么区别？

讲到这里，就必须把 Payment Facilitator 拿出来讨论。因为在实际业务中，Marketplace 和 PayFac 经常被混在一起。

从资金流来看，两者确实可能非常相似。消费者付款，平台接收结算资金，平台再向底层商户分配资金。但从银行卡收单体系来看，它们不是完全相同的角色。

Visa 在其风险指南中，对 PayFac 和 Marketplace 分别进行了描述。

典型的 PayFac 与收单机构建立合作关系，再与 Sponsored Merchants 签订支付服务协议，为这些商户提供支付服务。在这种模式下，底层 Sponsored Merchant 仍然是被识别和管理的商户。PayFac 则负责商户进件、支付接入以及相应的风险管理，并按照适用规则承担责任。

而在 Visa 描述的 Marketplace 模式下，Marketplace 自身与收单机构签约，并在相关银行卡交易中被视为 MoR。

这里的区别其实非常关键。

PayFac 的核心，是帮助多个底层商户接入银行卡收单网络。Marketplace 的核心，则是平台以自己的品牌组织消费者交易，并在特定收单框架中承担交易商户身份。

当然，这只是 Visa 相关模式的主要区别，并不意味着现实中所有平台都能被简单划分为两类。

不同卡组织、地区和收单机构，可能存在不同的定义、准入要求及交易安排。

但为了方便理解，我们可以先看一个简化对比。

维度

Marketplace

PayFac 模式

核心业务

组织买家与卖家之间的交易

帮助底层商户接受银行卡支付

面向消费者品牌

通常是 Marketplace

通常是底层商户

Visa相关模式中交易商户

Marketplace

Sponsored Merchant

与收单机构关系

Marketplace 与收单机构签约

PayFac与收单机构建立合作安排

底层商户管理

需要管理平台零售商及相关风险

需要管理Sponsored Merchants

资金结算

可由平台接收并向零售商结算

可由PayFac接收并向 Sponsored Merchants 结算

主要风险

平台交易、底层零售商及消费者责任

底层商户准入、交易处理及持续风险监控

这里还有一个值得注意的地方。MoR 和 PayFac 并不是两个完全对等、互斥的监管分类。

MoR 是交易中的商户身份。PayFac 则是银行卡收单体系下的一类支付服务安排。

一家企业是否能够同时涉及两种角色，需要结合具体交易、收单合同和卡组织规则判断，不能简单地说二者绝对互斥。而且，在不同卡组织文件和商业产品介绍中，MoR 这个词的使用范围也未必完全一致。

所以，不能只看名称。真正需要看的，是具体规则中谁被视为交易商户、谁承担收单义务，以及底层商户如何被识别和管理。

从收单银行的角度看，这个区别尤其重要。

假设两家公司都服务 1,000 家 AI 开发者。

第一家公司是一家 SaaS 支付平台。消费者直接向各个开发者购买服务，平台提供统一的收银台、订阅管理和支付技术。

第二家公司是一家 Marketplace。消费者通过平台购买不同开发者提供的数字服务，平台以自己的品牌组织交易，并按照获批准的 Marketplace 收单模式处理支付。

两家公司的交易量可能一样，支付方式一样，资金流也可能非常相似，但收单银行需要审核的内容并不完全相同。

对于前者，银行需要理解底层商户如何进件、如何审核、如何持续监控，以及平台是否符合适用的支付服务安排。对于后者，银行需要确认平台是否真正符合 Marketplace 模式，是否承担相应的交易责任，以及如何管理底层零售商风险。

所以，Marketplace 与 PayFac 的区别，不是简单看谁收钱、谁分账。

真正的区别在于平台与消费者、底层商户和收单机构之间，分别建立了什么关系。

三、平台统一收款，为什么可能触发 Transaction Laundering？

支付行业里有一种风险，叫 Transaction Laundering。

中文有时会翻译成交易洗白或交易洗钱，但它与传统反洗钱语境中的 Money Laundering 并不是同一个概念。

在银行卡收单体系中，Transaction Laundering 通常涉及交易真实来源被错误披露，或者未经授权将其他商户的交易提交到支付网络。

Visa 在其商户风险筛查资料中，将未经授权的交易聚合，以及代表其他商户提交交易的特定行为，列入 Transaction Laundering 相关风险情形。

这对平台支付业务非常重要。

假设一家香港公司向收单银行申请普通 SaaS 商户账户，它告诉银行，自己经营的是软件订阅服务，但实际情况是，这家公司服务着 500 家不同的 AI 应用。每家 AI 应用都有独立的网站、品牌、消费者合同和服务内容，香港公司并没有真正向消费者销售这些 AI 服务，只是统一收款，再向开发者结算。

如果它把所有交易都作为自己的普通 SaaS 销售收入提交给收单机构，而没有向银行披露实际交易来源，那么就可能涉及未经授权的第三方交易聚合风险。

这里的问题，不是香港公司有没有收钱。而是银行原本批准的是一家普通 SaaS 商户，却实际上处理了数百家不同商户的交易。这会直接影响银行的商户风险管理。

例如，银行原本以为自己服务的是一家提供办公软件的企业。但底层交易可能来自 AI 聊天、图片生成、视频生成、数字内容、虚拟商品等不同业务。这些业务的退款率、拒付率、欺诈风险和消费者投诉情况可能完全不同。如果底层商户中还存在受限制或禁止的业务，风险就更加复杂。

当然，不能因此认为所有平台统一收款都属于 Transaction Laundering。经过适当披露、获得收单机构认可，并按照相应 Marketplace、PayFac 或其他获批准模式处理交易的平台，与未经授权隐藏真实交易来源的聚合行为，有本质区别。

问题不是平台能不能替别人收钱，而是它究竟以什么身份收钱，以及收单机构是否知道并批准了真实业务模式。

这里再回头看 Stripe Connect 的技术设计，就比较容易理解了。

Stripe Connect 主要支持三种常见的 Charge Type。Direct Charges、Destination Charges，以及 Separate Charges and Transfers。

Direct Charges 是在 Connected Account 上创建支付。

Destination Charges 通常由平台创建支付，并按照配置将资金转移到目标关联账户。

Separate Charges and Transfers 则把支付和后续资金转账拆开处理。

很多技术团队习惯按照资金流选择模式。

例如，想让资金由平台统一管理，就选择 Destination Charges。想把一笔交易分配给多个卖家，就选择 Separate Charges and Transfers。

但 Stripe 明确要求，必须先确定 MoR，再选择相应的 Charge Type。

按照其文档中的配置要求：

MoR 为 Platform：Charge Type 用 Destination Charges，on_behalf_of 不设置。

MoR 为 Platform：Charge Type 用 Separate Charges and Transfers，on_behalf_of 不设置。

MoR 为 Connected Account：Charge Type 用 Direct Charges，on_behalf_of 不适用。

MoR 为 Connected Account：Charge Type 用 Destination Charges，on_behalf_of 设置。

MoR 为 Connected Account：Charge Type 用 Separate Charges and Transfers，on_behalf_of 设置。

这组配置说明，同样一种 Charge Type，可以对应不同的 MoR。

例如，Destination Charges 并不必然意味着平台就是 MoR。如果真实交易中的 MoR 是 Connected Account，那么在 Stripe 这套配置规则下，就需要通过相应的 on_behalf_of 设置反映其身份。

但按这个逻辑来看：

on_behalf_of 不是一个可以任意改变交易商业性质的开关。

它是 Stripe Connect 的支付配置参数，必须与真实交易关系一致。

如果消费者实际上向第三方商户购买商品，平台不能仅仅因为希望统一管理支付，就随意把自己配置成 MoR。

反过来，如果平台实际以自己的名义向消费者销售商品或服务，也不能简单通过设置 on_behalf_of，就把本应由平台承担的消费者责任转移给底层商户。

Stripe 还要求，MoR 身份需要在收银台、消费者条款、发票、收据、银行卡账单描述以及争议处理流程中保持一致。

这里尤其值得关注的是 Statement Descriptor。

也就是消费者银行卡账单上的商户描述，很多平台会把它当成一个普通的技术参数。但对于卡组织和发卡银行来说，这个字段关系到消费者能否识别交易。

假设消费者在一家 AI 应用上购买了 20 美元订阅服务。网站品牌叫 Alpha AI，但银行卡账单显示的是一家完全陌生的香港公司，消费者可能根本不知道这笔交易来自哪里。尤其是订阅业务，消费者第一次付款时可能还记得自己购买了什么。但三个月后自动续费，银行卡账单上突然出现一个陌生名称，就很容易引发无法识别交易的投诉。进一步可能发展为 Chargeback。

所以 Stripe 要求，账单描述必须清晰识别正确的 MoR，并与消费者在收银台、收据和服务条款中看到的品牌保持一致。

对于真正采用 MoR 模式的平台来说，这里还会涉及一个产品设计上的挑战。

消费者可能是在开发者自己的 App 或网站里完成购买，但法律销售方和支付 MoR 是第三方平台。那么，平台就需要通过消费者条款、支付页面、订单确认和账单描述，让消费者能够清楚理解谁是实际交易责任主体。

否则，即使合同中写明了 MoR，消费者体验也可能与合同安排不一致。这也是为什么技术上能够成功完成交易，并不意味着交易结构一定符合收单要求。对于平台来说，最容易出现的问题，往往不是 API 接错了，而是商业模式没有定义清楚。

四、签一份 Reseller Agreement，就能成为 MoR 吗？

这个问题在 AI 出海行业尤其现实。

假设一家香港公司希望为中国 AI 开发者提供全球 MoR 服务。它不直接开发 AI 产品，但它与开发者签订 Reseller Agreement，获得相关软件或数字服务的转售授权。

然后由香港公司以自己的名义向全球消费者销售订阅服务。消费者通过 AI 应用网站完成支付，香港公司负责收款、退款、拒付处理以及相关税务安排，底层 AI 服务仍然由中国开发者提供。这种模式能不能成立？

原则上，真实的转售模式是一种可以考虑的商业安排。

但仅仅签订一份 Reseller Agreement，并不足以证明香港公司已经成为真正的 MoR。

原因很简单。

Stripe 判断 MoR，并不是只看合同里有没有出现 Reseller 这个词。它还要看消费者实际面对的交易关系。

例如，消费者购买服务时，网站服务条款究竟写的是谁？

如果服务条款明确说明，消费者向香港公司购买订阅服务，香港公司承担相应的销售和消费者责任，那么这种安排更有可能支持香港公司的 MoR 身份。

但如果消费者合同仍然由中国 AI 开发者签订，开发者承担全部销售和售后责任，而香港公司只是负责收钱，那么这份 Reseller Agreement 就可能与实际交易关系不一致。

这里还有一个更复杂的问题。如果香港公司成为 MoR，它是否必须承担所有产品责任？

答案并不能简单概括为必须承担所有责任。不同司法辖区对数字服务销售、消费者保护、产品责任和合同责任的规定并不完全相同。平台可以通过商业合同与开发者约定内部责任分配，例如服务交付、技术支持、赔偿和追偿。但这些内部安排，并不必然能够对抗消费者依法享有的权利，也不能自动改变收单机构对 MoR 的要求。

因此，真正的 MoR 模式通常需要两层合同关系。

第一层是平台与消费者之间的销售关系。第二层是平台与底层开发者之间的采购、授权、转售或服务合作关系。

这两层关系必须能够相互解释。如果消费者向平台购买服务，那么平台需要有合理的商业基础向消费者提供该服务。如果底层开发者负责实际交付，那么平台与开发者之间也需要有相应的授权和履约安排。这不是简单修改一份收单合同就能完成的事情。

还有一个问题不能跳过，就是 VAT。

对于 AI 出海企业来说，选择 MoR 服务商，一个重要原因就是希望解决全球 VAT 和 GST。

例如，向欧洲消费者销售数字服务，可能涉及 VAT。向英国、澳大利亚以及其他国家销售数字产品，也可能涉及当地间接税义务。

如果开发者需要自己处理几十个国家的税务登记、税率计算、申报和缴纳，成本可能非常高。

于是 MoR 服务商把税务作为核心产品能力，消费者向 MoR 购买服务，MoR 负责相应的税务处理，开发者按照合同获得收入。

但这里必须区分两个问题。

第一个是支付体系中的 MoR，第二个是税法上的供应商或纳税义务人。

二者可能是同一个主体，但不能直接画等号。

不同国家的 VAT 或 GST 规则，可能根据法律供应商、电子平台规则、消费者所在地、服务类型以及其他条件，确定具体纳税责任。

例如，在某些司法辖区，电子平台可能因为特定的视同供应商规则承担 VAT 责任。即使平台并没有按照传统买断转售模式持有商品所有权，也可能被税法要求承担相关义务。反过来，某家公司即使在支付体系中被认定为 MoR，也不意味着它自动成为所有国家的 VAT 纳税义务人。实际税务责任仍然需要根据各国法律判断。

对于 AI 开发者来说，还有另一个容易被忽略的问题。

即使消费者层面的间接税由 MoR 服务商处理，开发者与 MoR 之间的 B2B 收入，也可能涉及开发者所在地的企业所得税、增值税、预提税或其他税务事项。

所以，不能简单理解为：把收款交给 MoR，全球税务问题就全部解决了。

真正成熟的 MoR 服务，需要同时设计消费者销售关系和底层供应商关系，并分别评估相关税务义务。

对于收单银行来说，这种模式同样需要更深入的审核。银行不仅需要确认平台是否真正承担消费者交易责任，还需要了解底层供应商是谁、销售的商品或服务是什么、平台是否具备必要授权，以及是否有能力持续管理相关风险。

因为 MoR 改变的是交易责任安排，并不是让底层供应商风险消失。

五、MoR 不是支付产品，而是一种商业责任

过去几年，很多支付公司都在做 Payment Orchestration，核心逻辑是帮助商户连接不同的 PSP、Acquirer 和本地支付方式。

商户仍然是商户，平台负责提高支付成功率、优化路由、管理支付成本。PayFac 则主要解决多个底层商户如何接入银行卡收单网络，以及相应的商户管理和支付服务安排。

但 MoR 的逻辑不太一样。

它解决的不只是如何让消费者完成付款，而是让开发者不必独立处理大量面向消费者的商业和合规事务。

对于一家刚刚出海的 AI 公司来说，问题可能远不止信用卡收单。它可能还需要处理不同国家的消费者保护要求、订阅取消和自动续费规则、退款与拒付、数字服务 VAT、支付欺诈、本地支付方式，以及跨境资金结算。如果这些问题全部由开发者自己解决，运营成本可能非常高。

MoR 服务商的价值，就是把其中相当一部分复杂性集中到自己身上。但这种价值也意味着更高的责任和成本，它需要真正的消费者交易管理能力，需要税务和法律支持，需要供应商风险管理，还需要能够支持相应商业模式的收单和结算合作伙伴。

所以，如果一家平台只是把支付资金集中收取，再按照一定比例分给开发者，它本质上并没有自动获得这些能力。这可能只是一套支付聚合或资金分配架构。距离真正成熟的 MoR 服务，还有相当长的一段距离。

这里还有一个值得讨论的商业问题。

为

什么一些 MoR 服务商的收费，会明显高于普通 PSP？

表面上看，大家都是帮助开发者收取一笔 20 美元的订阅费。但普通 PSP 主要承担支付处理相关的成本和风险。

而真正的 MoR 服务商，还可能需要承担消费者交易、退款、争议、税务处理、供应商管理等一系列额外责任。

两者的成本结构并不一样。当然，这并不意味着 MoR 一定比 SaaS 或 PayFac 更高级。

对于已经具备海外主体、税务能力和收单渠道的大型 AI 公司来说，直接作为商户可能更合适。它们可以保留消费者关系、控制支付成本，并自主决定收单和结算策略。

但对于刚刚出海、缺少海外商业和税务基础设施的小型开发者来说，MoR 服务可能更有吸引力。它们愿意支付更高的服务费用，换取更简单的全球销售和运营体验。

所以，MoR 与 SaaS/PayFac 的选择，本质上不是技术路线之争。

而是平台愿意承担多少商业责任，以及客户希望把多少复杂性外包出去。如果一家企业按照普通 PSP 的成本结构定价，却承担了真正 MoR 的全部责任，长期来看未必是一门好生意。

反过来，如果一家平台只提供普通支付聚合服务，却按照完整 MoR 的方式对外宣传，也可能给客户和收单机构造成错误预期。

这也是为什么我觉得，MoR 的竞争最终不只是支付渠道的竞争。更重要的是，谁真正具备承担全球消费者交易复杂性的能力。

六、最后，平台到底是在帮别人收钱，还是自己在做生意？

回到最初的问题。谁才是真正的 MoR？

Stripe 给出的答案，并不是一个简单的账户配置规则。它要求从消费者视角出发，结合交易品牌、退款和争议责任、账单描述，以及商品或服务的实际销售关系综合判断。

而 Visa 的 Marketplace 规则，则进一步说明，在符合特定卡组织要求的情况下，平台即使不是底层商品的最终提供方，也可以成为银行卡交易中的 MoR。

这两件事放在一起看，其实说明了一个很重要的问题。

商业交易中的销售主体、银行卡收单体系中的商户身份，以及资金结算中的收款主体，并不总是同一个概念。

对于平台来说，真正需要做的不是简单选择其中一个身份，而是让实际商业关系、收单架构和资金处理方式相互匹配。

如果平台只是帮助开发者收钱，就应该按照真实的支付服务模式设计产品，并解决相应的商户进件、资金处理和监管问题。

如果平台希望成为 MoR，就应该真正建立相应的消费者交易关系，承担交易责任，并让收单银行理解和接受这种模式。

不能因为资金先进入平台账户，就认为自己自然成为了 MoR。也不能因为签了一份 Reseller Agreement，就认为所有消费者交易、卡组织和税务问题都已经解决。更不能因为 Stripe Connect 支持某种 Charge Type，就认为这种支付架构在任何商业模式下都可以使用。

支付行业有时候太习惯从资金流出发讨论问题。

钱从哪里来，经过哪个账户，最后结算给谁。

但资金流只能解释支付是如何完成的，它未必能够完整解释消费者究竟向谁购买商品，也无法单独决定谁应当承担交易责任。

对于平台支付来说，这才是 MoR 问题的核心。

你到底是在帮助别人完成一笔交易，还是自己已经成为这笔交易的一方？

两者看起来可能只有一线之隔。

但背后对应的商业责任、收单架构、风险管理和税务安排，可能完全不同。

而真正成熟的平台支付产品，应该先回答这个问题，再决定钱怎么走。

参考资料

Stripe Connect — Determine and configure the merchant of record

Visa — Payment Facilitator and Marketplace Risk Guide

Visa — Merchant Screening Service Documentation

Payment Infra系列文章合集

为什么全球PSP都想开J.P. Morgan账户？

TP3 Underwriting：JPMC如何评估一家PSP？

代理行如何连接全球资金流动？

支付的终点，为什么是账户？

深度｜全球支付的隐形天花板：Liquidity

支付越快，为什么越需要 Credit？

支付的最后一公里：Settlement

一家全球支付公司，是怎么管理客户资金的？

支付成功了，钱也到账了，为什么还要对账？

深度｜谁真的在用 Stablecoin？

什么是 Nesting？你的客户在银行眼里是谁

当First-party Payment遮住了Third-party Funds

稳定币行业下的隐形巨头

渣打的 Crypto 十年

大行与 Crypto 之间，长出了一家 SGB

Banking Circle：支付巨头的银行，是怎样炼成的

OpenPayd：Kraken、B2C2 和 Ripple 背后的资金生意

跨境老兵系列文章合集

支付老兵，为什么都去做四方了？

跨境收款老兵，究竟靠什么赚钱？

一些支付行业碎碎念

互联网大厂的 FI BD：能力、姿态，和支付的位置