一家中国 AI 创业公司，团队只有五个人，产品是一个面向欧美用户的 AI 工具，每月收费 29 美元。

产品上线后，用户开始付费。创始人很快发现，真正麻烦的事情才刚刚开始。

美国用户用信用卡，欧洲用户需要处理 VAT，日本用户希望使用熟悉的本地支付方式。

订阅到第二个月，银行卡扣款失败；有人申请退款，有人发起拒付；随着销售规模扩大，不同国家的税务登记、消费者权益和发票要求也开始出现。

如果自己做，就需要支付服务商、税务软件、订阅系统、风控工具、财务对账和法律顾问。

但市场上还有另一种方案：找一家 Merchant of Record，简称 MoR。

开发商负责产品和获客，MoR 以自己的名义向消费者销售产品，处理支付、适用的销售税务、退款及相关交易责任，再按照合同向开发商结算。

看起来只是把几个服务打包在一起。

但仔细研究会发现，MoR 与 PSP 最根本的区别，不是提供多少支付方式，而是谁站在消费者面前，承担这笔交易的销售责任。

这背后实际上是两种完全不同的商业模式。

一、理解 MoR，首先要把支付和销售分开

传统支付行业最熟悉的是 PSP（Payment Service Provider）。

商户销售商品，消费者付款，PSP 提供支付技术、支付方式接入、交易处理及相关服务。根据不同业务模式，PSP 可能自己具备收单资质，也可能连接其他收单机构。

但无论支付技术多复杂，通常有一个前提：商品是商户卖的。

消费者购买的是商户的产品，商户承担主要销售义务，PSP 负责其合同约定范围内的支付服务。

MoR 改变的恰恰是这个前提。

在典型的 MoR 转售结构下，消费者不是直接向软件开发商购买产品，而是向 MoR 购买。

MoR 成为消费者交易的合同销售方，开发商则根据与 MoR 的协议提供软件、授权或服务交付。

PSP 解决的是：这笔钱如何安全、顺利地收进来？

MoR 还需要解决：这笔销售由谁完成，谁向消费者负责，谁承担适用的销售税务义务，以及交易出现问题时谁负责处理？

所以 MoR 不是简单的高级支付网关，也不是拥有更多支付方式的 PSP。

它改变了交易中的商业和法律关系。

当然，MoR 不是全球统一定义的法律牌照。某个平台是否真正成为销售主体，需要看消费者条款、开发商合同、发票、实际交易安排，以及相关司法辖区的法律。

不能因为一家企业自称 MoR，就认为所有责任已经自动转移。

二、一笔 29 美元的 AI 订阅，背后其实有五条链路

理解 MoR 最有效的方法，不是研究产品介绍，而是拆开一笔真实交易。

假设一家 AI SaaS 公司向美国消费者销售每月 29 美元的订阅服务，使用一家第三方 MoR。

用户在开发商网站上点击 Subscribe，完成银行卡付款，系统随后为用户开通服务。

表面上，整个过程只需要几秒钟。

但在后台，至少存在五条不同的链路。

第一条：合同流。

在典型转售模式下，消费者的购买合同由 MoR 承接。

MoR 与开发商之间另有协议，规定软件授权、产品供应、销售收入分配、退款追偿及风险责任。

这意味着一笔消费者购买，可能对应两个层次的商业关系。

消费者向 MoR 购买产品，MoR 根据与开发商的协议取得销售权，而开发商继续负责实际产品功能和服务交付。

第二条：支付流。

消费者输入银行卡信息，交易经过支付网关、收单机构、卡组织和发卡银行。

MoR 可以直接与收单机构合作，也可以使用第三方 PSP。交易授权、清算和结算依赖具体支付网络及合同安排。

这里有一个重要区别：消费者向 MoR 购买，不代表 MoR 必须亲自处理银行卡交易的每一个技术环节。

支付处理完全可以外包，但销售主体责任不能仅靠外包支付处理而消失。

第三条：资金流。

消费者付款成功，不意味着 MoR 已经拿到了可以立即支付给开发商的现金。

授权成功之后，还存在清算、收单结算、退款、拒付、税款及开发商结算等不同时间点。

假设用户支付 29 美元，MoR 最终收到收单结算款后，还需要根据合同计算开发商应得金额。

部分 MoR 会保留滚动准备金、延迟结算或设置风险调整机制。

因此，开发商后台显示的销售收入，与银行账户最终收到的资金，往往不是同一个数字。

第四条：税务流。

在 MoR 负责销售的适用市场，平台需要判断消费者所在地、商品税务分类、适用税率、税收豁免及发票要求，并完成相关税款申报和缴纳。

但开发商不能因此认为自己没有任何税务义务。

开发商获得的款项，仍可能涉及其注册地的企业所得税、跨境服务收入、预提税或其他申报要求。

MoR 主要解决的是其承担的终端销售税务责任，不是替开发商解决全部税务问题。

第五条：风险责任流。

如果消费者申请退款，或者向发卡行提出拒付，MoR 通常需要作为交易销售方进行处理。

但最终经济损失由谁承担，要看合同。

例如，一笔交易发生 100 美元拒付，MoR 可能先承担对收单机构的付款义务，再根据开发商协议扣回相应金额。

所以，不能把 MoR 承担拒付处理责任，理解为开发商永远不承担拒付损失。

MoR 把复杂性集中到了自己身上，但不代表所有风险都由自己最终买单。

三、MoR、PSP、PayFac、Marketplace，真正的边界在哪里？

支付行业经常把这几个概念放在一起讨论，但它们实际上描述的是不同维度。

PSP 是支付服务能力。

PayFac 是一种支付聚合和商户接入安排。

Marketplace 是平台商业模式。

MoR 则涉及交易中谁作为销售主体，以及由此承担的法律和商业责任。

值得注意的是，这些模式并不互斥。

一家 Marketplace 可以自己成为 MoR，也可以让入驻卖家成为销售主体。

一家 MoR 可以同时使用 PSP 和 PayFac 基础设施。

一家 Reseller 也可能承担 MoR 的角色。

真正需要避免的，是把技术平台中的 Merchant of Record 标记，直接等同于完整的税务转售模式。

以 Stripe 为例，Stripe Connect 的不同交易模式可能使平台或连接账户在支付系统中被视为 Merchant of Record，但这并不自动说明平台已经承担了全球数字产品转售所需的全部销售税务义务。

Stripe 同时也提供专门的 Managed Payments MoR 方案。

这也是为什么判断一家企业是不是完整的 MoR，不能只看支付 API 或账单描述。

应该看合同、实际销售安排、消费者条款、税务处理和资金结算。

四、MoR 最值钱的能力，可能不是收款，而是税务

为什么一家 AI SaaS 公司不直接使用 Stripe，再接一个税务软件？

因为计算税款与承担税务责任，是两件不同的事。

税务软件可以帮助企业识别适用税率、生成税务数据，部分服务还提供登记和申报支持。

但在商户直接销售模式下，法定销售税务义务通常仍属于商户自身。

MoR 的价值，在于它作为销售主体，对自己承担的交易进行税务处理。

比如，同样是一款 AI 软件，向美国、德国、日本消费者销售时，可能面对完全不同的间接税规则。

美国需要判断州级 Sales Tax 规则及经济关联标准。

德国可能涉及欧盟数字服务 VAT 规则。

日本则需要分析消费税制度、交易性质和适用的跨境数字服务规定。

对一家只有五个人的创业公司来说，逐个市场研究和维护这些规则的成本很高。

而对一家已经拥有大量数字产品交易的 MoR 来说，同一套税务能力可以重复服务数千家开发商。

这就形成了规模经济。

但它并不是零成本的软件功能。

MoR 仍需要维护税务登记、产品分类、证据留存、申报流程、退款税务调整和法律变化监控。

所以我认为，税务合规能力不是 MoR 的附加功能，而是它区别于普通 PSP 的核心基础设施之一。

五、MoR 如何赚钱？不能只看 5% 的收费

假设一家 MoR 专门服务 AI SaaS 开发商，月 GMV 达到 1,000 万美元，平均收费为交易额的 5%。

表面看，它每月有 50 万美元收入。

但真正决定这门生意好不好的，是扣除支付成本、欺诈损失、税务运营和其他直接成本后，还能剩下多少。

我们做一组假设测算。

也就是说，在这组假设中，MoR 的贡献利润仅相当于 GMV 的 1.55%，占服务收入的 31%。

而且这还没有扣除研发、销售、管理和融资等费用。

这里的 GMV 假设不包含另外收取的销售税，贡献利润也不等于会计净利润。

这组数据揭示了一个重要问题：

MoR 收费 5%，并不意味着它赚取 5% 的净利。

更关键的是，MoR 的盈利能力会受到商户结构的强烈影响。

假设两家 MoR 都处理 1,000 万美元月 GMV。

第一家主要服务企业级 SaaS，平均客单价 200 美元，退款率和欺诈率较低。

第二家主要服务低客单价的 AI 娱乐产品，平均客单价 9.99 美元，用户流失快，争议率高。

两家公司 GMV 一样，但交易笔数、固定交易手续费、风控损失、客服负担和续费表现可能完全不同。

尤其是固定交易费，对低客单价业务影响很大。

一笔 200 美元交易的 0.30 美元固定手续费，占比只有 0.15%。

一笔 9.99 美元交易，同样的固定手续费，占比已经达到约 3%。

这意味着 MoR 的客户组合，本身就是利润模型的一部分。

MoR 的核心经营能力，不只是扩大 GMV，而是筛选可以持续产生正贡献利润的 GMV。

六、为什么 AI 行业可能成为 MoR 的重要增长市场？

过去，MoR 主要服务软件授权、数字下载、游戏和 SaaS。

现在，AI 创业公司的商业模式正在变得更加复杂。

一家公司可能同时销售月度订阅、年度订阅、Credits、按量使用额度，以及额外的模型调用套餐。

用户分布在多个国家，产品迭代速度快，团队规模却可能很小。

这使 MoR 具有明显吸引力。

但 AI 行业并不是一个同质化市场。

AI 编程工具、AI 设计、AI 视频、AI 投资工具，虽然都带有 AI 标签，但在收单机构眼中可能具有完全不同的风险特征。

特别是 AI 用户生成内容及部分金融相关产品，可能面临更严格的内容审查、商户准入和持续监控要求。

对 MoR 而言，问题不只是能不能接入 API，而是它的收单合作伙伴是否接受这些业务，以及平台是否有能力管理相关法律和卡组织风险。

因此，未来 AI MoR 的竞争，很可能不是谁支持最多 AI 网站，而是谁能识别不同 AI 产品的风险和盈利特征。

七、为什么开发商愿意支付 5%，而不是自己搭支付系统？

这是 MoR 商业模式最值得思考的问题。

假设一家 AI SaaS 公司月流水 3 万美元。

MoR 收费 5%，每月成本约 1,500 美元。

如果它自己使用 PSP、税务工具、订阅管理系统，表面上的支付费率可能更低。

但创始人还要承担技术集成、税务管理、跨境销售合规、退款和账单运营成本。

对于早期公司来说，MoR 买到的其实是时间。

创始人不需要为了进入新的市场，立即建设一套全球销售运营体系。

但当公司规模增长到每月 100 万美元 GMV，5% 就是每月 5 万美元。

这时，企业可能开始认真考虑：

能不能自己承担税务责任？

能不能通过直接收单获得更好的费率？

能不能把订阅管理、风控和财务系统掌握在自己手里？

能不能通过多个 PSP 优化不同市场的支付成功率？

因此，MoR 存在一个天然的商业挑战：

它最容易吸引的是早期企业，但部分成功长大的客户，可能开始考虑离开。

当然，这并不意味着所有大客户都会迁移。

多市场税务复杂度、团队运营成本、支付成功率、迁移风险和合同条件，可能使成熟企业继续使用 MoR。

真正的决策依据应该是总拥有成本，而不是简单比较支付费率。

八、MoR 最危险的地方，是它承担了风险，却不完全控制产品

传统商户通常控制自己的产品、定价、营销、用户获取和履约。

MoR 则可能处在一个比较特殊的位置。

它是对消费者的销售主体，却未必能直接控制开发商的所有产品行为。

例如，一家 AI 工具网站在入驻时提供正常的图像生成服务。

几个月后，开发商修改产品功能，增加高风险内容，或者通过激进营销吸引了大量高争议用户。

MoR 的支付和销售责任可能仍然存在，但风险已经发生变化。

所以 MoR 必须持续进行商户管理。

不仅需要在入驻时审查 KYB、UBO、网站、商品和商业模式，还需要在交易发生后监控退款率、拒付率、用户投诉、产品变化和异常资金流。

这与传统 PSP 的风险管理有重合，但 MoR 的销售责任可能使它需要更深入地理解产品本身。

还有一个经常被忽视的问题：资金流动性。

当 MoR 向开发商结算后，如果消费者在之后发起大额退款或拒付，MoR 可能需要先向支付合作伙伴承担相应责任。

如果开发商已经提现、停业或无法追偿，MoR 就可能形成实际损失。

因此，准备金、延迟结算、交易限额、商户风险分层和追偿机制，都可能成为 MoR 的核心运营工具。

MoR 的风险，本质上来自销售责任与产品控制权之间的不对称。

九、如果今天从零创办一家 MoR，我会怎么做？

我不会从开发 Checkout 开始。

Checkout 是最容易被看见的部分，却不是最难的部分。

真正应该先验证的是三件事：

第一，有没有足够明确的客户需求。

第二，能不能找到愿意承接这种商业模式和行业风险的收单合作伙伴。

第三，能不能建立经得起法律、税务和财务审查的转售结构。

如果这三件事没有解决，Checkout 做得再漂亮，也只是一套支付界面。

第一阶段，我会只选择一个行业。

比如先服务低风险的 AI SaaS、开发者工具或生产力软件。

不急着覆盖所有数字内容，更不急着承接高拒付、高监管复杂度的业务。

第二阶段，把法律关系设计清楚。

需要确定 MoR 是如何取得销售权的，消费者向谁购买，谁开具销售凭证，谁承担退款和产品交付责任。

还需要确定开发商收入的法律性质，以及 MoR 如何处理不同市场的税务义务。

其中一个关键问题是：企业在商业和会计意义上究竟是 Principal 还是 Agent？

这会影响收入确认方式。

MoR 的交易销售主体身份，不自动决定它可以将全部 GMV 确认为会计收入，仍需要根据具体合同及适用会计准则判断。

第三阶段，建立收单合作。

必须向收单机构充分披露真实商业模式，包括 MoR 身份、底层开发商类型、商品类别、目标国家、退款规则和资金结算方式。

不能用普通 SaaS 商户账户包装多开发商转售业务，更不能隐瞒实际产品或终端交易来源。

第四阶段，建立资金与 Ledger 系统。

每一笔交易至少需要记录消费者实际付款金额、税款、支付成本、退款与拒付调整、开发商应得款项、准备金以及最终结算金额。

Ledger 需要能回答一个最基本的问题：

今天银行账户里的钱，有多少属于已经确认的应付款，有多少对应尚未完成的退款或税务义务，又有多少真正可以自由使用？

资金在法律上是否属于 MoR 自有资金、是否需要隔离或受支付监管约束，还要根据实际交易结构和司法辖区单独判断。

第五阶段，先做小规模真实交易。

不要一开始就追求数千万美元 GMV。

先选择十几家业务透明、低风险、能够配合审查的开发商。

观察三个完整的运营周期：首次付款、续订、退款与争议。

验证收单成功率、净收入、税务处理、结算准确性和实际损失。

当每一笔钱都能解释清楚，每一种责任都能找到对应合同和运营流程，才有资格讨论规模化。

十、未来的 MoR，会不会被 Stripe 和大型 PSP 吃掉？

这个问题已经不能简单地回答为不会。

因为大型支付公司正在进入 MoR 市场。

Stripe 已经推出 Managed Payments 方案，将全球销售税务、欺诈与争议管理及消费者交易支持纳入其 MoR 服务范围。

这意味着，传统 MoR 不能再依靠“我们比 Stripe 多做税务”建立永久壁垒。

大型 PSP 拥有支付网络、开发者生态、商户关系、数据和资金规模。

一旦它们把 MoR 产品化，独立 MoR 就需要回答：

除了税务和支付打包，我还能提供什么？

我认为有三个可能的方向。

第一个是行业垂直化。

不同数字产品需要不同的定价、交付、退款和风险模型。专门服务 AI 开发者、游戏发行商或特定软件生态的 MoR，可能比通用平台更理解客户。

第二个是支付与收入优化。

MoR 如果能帮助开发商提升支付成功率、续费率、LTV，并降低拒付损失，就不再只是成本中心，而开始直接影响客户收入。

第三个是嵌入式分销。

MoR 不一定需要直接获得每一家开发商。

它可以嵌入 AI 建站平台、开发工具、SaaS 平台和其他开发者生态，让平台用户在创建产品时直接获得全球销售能力。

这已经不完全是未来设想。

例如，Paddle 的 Embedded Billing 就提供了让其他平台接入开发者、并由 Paddle 承担相关 MoR 职责的产品模式。

这让我想到一个更值得关注的趋势：

MoR 可能从一个独立收款产品，逐渐变成其他软件平台背后的全球商业化基础设施。

开发者甚至不需要知道底层有多少收单机构、税务系统和结算银行。

他们只需要完成产品开发、设置价格，然后开始销售。

当然，谁能成为这种基础设施，还取决于风险控制、渠道合作、单位经济模型和监管适配能力。

十一、MoR 的终局，不是成为另一家 PSP

过去十几年，全球支付行业主要解决的是如何让资金跨越不同银行、卡组织、币种和国家。

支付网关降低技术接入门槛。

PSP 整合支付方式。

PayFac 降低商户接入成本。

支付编排让企业可以在多个 PSP 之间管理路由和交易。

这些能力不断提高资金流动的效率。

但一家企业要向全球消费者销售产品，仍然需要处理销售合同、税务、退款、消费者权益、支付风险和跨境结算。

这就是 MoR 的切入点。

它没有消除这些复杂性，而是把复杂性从大量独立开发商那里集中起来，再通过规模化运营降低单位成本。

从这个角度看，MoR 出售的不是一个支付接口，而是一套全球销售能力。

这也决定了它的商业边界。

如果 MoR 只是把支付、税务和订阅软件打包，然后收取更高费率，那么随着 PSP 和税务软件能力提升，它的优势可能逐渐缩小。

但如果 MoR 真正掌握跨市场销售、风险定价、交易优化、开发商分销和结算运营能力，它就可能成为独立的商业基础设施。

未来最有竞争力的 MoR，不一定是支持国家最多、支付方式最多的公司。

而是能够以合理成本，持续帮助开发商在更多市场完成合规、成功且有利润的销售的公司。

支付行业一直在研究如何让钱流动得更快。

MoR 提醒我们，收钱之前，还有一个更基本的问题：

谁有能力、也愿意承担把产品卖出去的责任？

当全球支付基础设施越来越标准化，真正稀缺的可能不再只是支付连接能力，而是把全球交易复杂性转化为可运营、可定价、可规模化的商业能力。

这才是我认为 MoR 最值得研究的地方。

参考资料与来源

本文主要参考以下官方资料，涉及 MoR 商业模式、销售主体责任、支付处理、税务合规、订阅管理及嵌入式支付架构。

1. Paddle — What is Paddle? / Merchant of Record Model

https://developer.paddle.com/get-started/how-paddle-works/

Paddle 官方对 MoR 的定义，解释 MoR 如何作为销售主体承担支付、销售税、退款、拒付及相关合规责任。

2. Stripe — What Is a Merchant of Record?

https://stripe.com/resources/more/merchant-of-record

Stripe 对 MoR 的定义及其与普通支付处理、Stripe Connect 的区别，特别是不同交易结构下 Merchant of Record 的认定。

3. Stripe — Managed Payments

https://stripe.com/managed-payments

Stripe 官方 MoR 产品介绍，涵盖间接税计算与缴纳、欺诈管理、支付争议、消费者支持及按交易选择 MoR 服务的模式。

4. Stripe — Services Agreement / Managed Payments Terms

https://stripe.com/zh-us/legal/ssa-service-terms

Stripe Managed Payments 的正式服务条款，可用于理解 MoR 的合同身份、销售授权、交易责任及服务范围。

5. Paddle — Embedded Billing

https://developer.paddle.com/partners/embed-billing/

Paddle 嵌入式 MoR 方案，说明 SaaS 平台及 AI 开发平台如何将全球收款、税务、订阅及商户结算能力嵌入自身产品。

6. Paddle — How an Embedded Billing Integration Works

https://developer.paddle.com/partners/embed-billing/get-started/

通过完整交易流程说明消费者付款、MoR 支付处理、税款计算、开发商产品交付、Webhook 通知及开发商结算之间的关系。

7. Paddle — Paddle for AI Companies

https://developer.paddle.com/get-started/how-paddle-works/ai-companies/

介绍 AI SaaS、Credits、订阅及按量计费等商业模式如何与 MoR 基础设施结合。

8. Stripe — How to Evaluate Merchant of Record Providers

https://stripe.com/guides/evaluate-merchant-of-record-provider

从税务覆盖、支付优化、风险管理、结算和全球市场扩张等维度，讨论企业选择 MoR 服务商时应考虑的因素。

注：文中关于月 GMV 1,000 万美元、5% 收费、支付成本及贡献利润的测算，均为作者构建的示例模型，不代表 Paddle、Stripe 或其他 MoR 公司的实际财务数据。关于 MoR 的竞争壁垒、客户迁移、行业垂直化及创业路径，属于作者基于支付行业商业模式的独立分析，不应视为上述企业的官方结论。

资料整理时间：2026 年 10 月。

本文采集自 可冉笔记，作者：衣莎贝，原文发布于 2026年10月29日。原文版权归原作者所有，此处仅作学习与记录之用。