Processor 与 MoR 责任怎么选

客户购买一份税前 100 美元的 SaaS 年付订阅，结账时另付 20 美元税款。订单在两套系统里都可能显示 paid，但账上发生的事并不一样：接入普通 Payment Processor 时，通常由你的公司向客户销售并承担这笔交易的税务、退款与交付责任；接入 Merchant of Record（MoR）时，MoR 在协议覆盖的订单中成为买家面对的卖方，再把扣除税款、费用和合同调整项后的供应商款付给你。

这就是两者最重要的区别。Payment Processor 解决“钱怎么完成授权、扣款和结算”，MoR 还改变“这笔商品是谁卖给买家的”。结账页是跳转还是嵌入、接口由谁提供、资金曾停在哪个余额里，都不能单独证明卖方身份。

企业客户要求合同、采购订单、发票和收款主体都写你的公司时，直接使用 Processor 通常更顺。标准化数字产品面向许多国家自助销售，而团队无力长期处理多地间接税、交易凭证和争议操作时，MoR 的价值更大。B2C 与企业销售的要求相反，可以按订单拆成两条渠道，但卖方、账票、退款和续费记录也必须随订单分开。

这项选择以收款准入已经成立为前提。签约主体、商品范围或结算账户尚未确认时，先完成中国开发者做海外 SaaS 收款的准入判断；不适用的路线不会因为换一种责任模型而恢复可用。

Payment Processor 和 Merchant of Record 的区别：买家向谁购买

Payment Processor 是支付执行服务。它把商家发出的支付请求送到收单机构、卡组织、发卡行或其他支付网络，再返回授权结果并完成扣款、退款和结算。现代 Payment Service Provider（PSP）还会提供结账页、风控、订阅计费、税额计算和报表，但这些功能本身不会把商品卖方改成 PSP。Adyen 对 PSP 的说明把网关、处理与收单放在支付服务范围内，普通 PSP 场景中的商家仍是法律卖方。Adyen：Payment service provider（在新标签页打开）

Merchant of Record 是一笔销售中的商业角色。MoR 在协议覆盖的订单中，以卖方或授权经销实体与买家成交，然后依照供应商协议向产品提供方支付净额。Paddle 的供应商协议（在新标签页打开）采用经销关系；买家条款（在新标签页打开）也明确，买家从 Paddle 购买，产品则由供应商提供。

因此，“Stripe 是 Processor，Paddle 是 MoR”只能描述某个具体产品，不能给整个品牌定性。普通 Stripe Payments 通常不改变商家的卖方身份；Stripe Managed Payments 是另一项服务，符合条件的交易会由 Link 作为买家看到的 Merchant of Record，并承担文档列出的间接税、交易支持与争议工作。Stripe 对 Merchant of Record 的说明（在新标签页打开）、Managed Payments 工作方式（在新标签页打开）

即使合同写明 MoR 是卖方，也不能把所有责任概括成“平台负责”。一笔退款或拒付至少涉及五个不同位置：

卖方身份只回答第一项。其余四项是否转移、转移到什么程度，要回到当前产品、目标交易和生效协议逐项确认。

同一笔订阅会生成两套合同与资金关系

直接使用 Processor 时，产品销售发生在买家与 SaaS 经营主体之间。SaaS 主体另行签署支付服务协议，请 Processor 通过金融网络完成扣款，并把可结算资金转入商家余额或银行账户。Processor 经手资金，不等于它向买家出售了产品；交易税、退款决定和产品履约仍以 SaaS 主体的销售关系为起点。

MoR 路径多了一层经销关系。买家依照 MoR 的买家条款付款，SaaS 主体则依照供应商协议提供销售权、产品和交付能力。MoR 收取买家款项后，扣除税款、服务费和合同允许的调整项，再向 SaaS 主体支付供应商款。Paddle 当前协议把这些工作分开规定：Paddle 负责经销与订单相关事务，供应商负责产品可用、交付和技术支持。Paddle 协议第 2、3、6 条（在新标签页打开）

资金先进入哪个余额，无法单独判断谁是卖方：Processor 可能暂时持有商家资金，MoR 也需要收单机构或 Processor 执行支付。可靠的判断来自同一笔订单上的一组相互印证的记录——买家条款中的签约实体、结账页卖方披露、发票或收据抬头、银行卡账单名称，以及供应商结算文件。界面上的一个 Logo 或字段都不能替代生效协议。

交易税跟着覆盖范围内的销售主体走

跨境 SaaS 的“税务处理”不是一个计算开关。它至少包含义务判断、税务注册、税额计算、申报缴纳、交易凭证和退款后的调整。结账页算出正确税额，只完成了计算。

直接使用 Processor 时，SaaS 主体通常仍是卖方。税务产品可以依据商品分类和买家位置计算 VAT、GST 或销售税，经营主体仍要判断在哪些地区形成义务，并完成相应注册、申报和缴款。Stripe Tax 也把注册、计算、申报缴纳列为不同环节；对已注册地区收取的税款，仍由商家负责申报和缴纳。Stripe Tax：File and remit（在新标签页打开）

MoR 可以处理协议覆盖交易的间接税，是因为它在这些订单中承担卖方或相关法定角色。覆盖范围外的国家、产品或渠道不会随之消失；供应商提供的产品描述、税务分类和来源信息也必须准确。Stripe Managed Payments 明确说明，未覆盖地区仍由商家负责间接税合规；Paddle 协议同样要求供应商提交正确的产品、分类和价格信息，并保留对错误资料追责的权利。Stripe Managed Payments 税务边界（在新标签页打开）、Paddle 供应商税务条款（在新标签页打开）

税务责任需要分两笔账。第一笔属于买家交易：谁是卖方，哪些间接税由它注册、收取和申报。第二笔属于 SaaS 经营主体：收到 Processor 结算或 MoR 供应商款后，怎样确认收入并处理自身税务。更换收款服务商只可能改变第一笔的部分责任，不会让第二笔消失。

发票卖方和银行卡账单名称会直接影响买家

买家付款后，至少会接触三类可见记录：证明向谁购买的发票或收据、银行卡或支付账户里的交易名称，以及退款时的贷项或退款通知。SaaS 主体收到的是另一组文件，包括服务商余额、结算单、汇款通知，或 MoR 与供应商之间的反向发票。前一组证明买家交易，后一组解释供应商款，后台订单详情不能代替其中任何一组。

在商家作为卖方的 Stripe Invoicing 场景中，发票可以显示商家的品牌和业务信息，准确性与当地格式要求仍由商家负责。银行卡账单名称也应反映实际对外经营名称（DBA），让买家能够认出交易。Stripe 发票定制（在新标签页打开）、statement descriptor 规则（在新标签页打开）

MoR 的交易凭证必须同时反映它的卖方身份。Paddle 当前使用 PADDLE.NET* COMPANYNAM 形式的银行卡账单名称，Stripe Managed Payments 使用 LINK.COM* [商家描述]。产品或商家名称可以保留一部分，但 Paddle 或 Link 的标识仍会出现。Paddle 账单描述（在新标签页打开）、Stripe Managed Payments 账单描述（在新标签页打开）

消费者认不出账单名称，常见结果是先向银行发起争议，而不是先找客服。企业采购的阻力则不同：合同主体、供应商档案、采购订单、发票卖方和收款账户可能被要求一致。服务商支持“发票付款”，并不代表买家的采购制度一定接受 MoR。年付 B2B 是主要收入时，应该让真实采购联系人走一遍报价、供应商准入、PO、发票、付款和贷项流程，再决定默认渠道。Paddle 可以提供销售辅助发票并接收付款，采购能否通过仍取决于买家制度和合同。Paddle Invoices（在新标签页打开）

MoR 处理退款和拒付，不等于供应商不再承担损失

“平台处理退款和拒付”最容易造成误判。买家向谁提出请求、谁决定退款、谁把钱退回、谁向银行举证，以及金额和费用最后从谁的余额扣除，可能分别属于不同主体。

普通 Stripe Payments 发生卡争议时，Stripe 通知商家并提供证据提交通道。争议金额和费用会从商家余额扣除，最终结果由持卡人银行决定；商家可以接受争议，也可以在截止日期前提交证据。Stripe：How disputes work（在新标签页打开）。Stripe 执行争议流程，不代表它替商家吸收损失。

Paddle 作为 MoR 时，争议直接针对 Paddle，证据也由 Paddle 的系统收集和提交；但争议金额与处理费会先从供应商余额扣除。胜诉后返还争议金额，处理费不退。Paddle：Understanding Chargebacks（在新标签页打开）。供应商协议还允许 Paddle 在约定情形下主动退款、抵销余额、要求补足负余额，或为未来退款和拒付保留资金。Paddle Master Services Agreement（在新标签页打开）

Stripe Managed Payments 把交易支持交给 Link。Stripe 会判断是否应对争议，也可能在原交易 60 天内的特定情况下直接退款；收到争议仍会产生费用。部分司法辖区在退款后仍要求缴纳原销售税，对应税额会减少商家账户余额。Stripe Managed Payments：退款与争议（在新标签页打开）。因此，产品名称写着 Merchant of Record，仍要继续核对退款税额、争议费和余额调整。

MoR 可以承担对外交易角色、日常操作和一部分合规工作，供应商却未必免于经济损失。合同里的 handle、manage、defend 和 liable 不是同一个承诺；必须连同退款金额、处理费、储备金（reserve）、抵销（set-off）、负余额和终止后责任一起读。真正影响现金的是下一份结算单，而不是产品页上的“处理拒付”。

风控、PCI 和产品交付不会随着卖方身份一起外包

托管结账页（Hosted Checkout）和托管支付字段可以缩小商家接触卡数据的范围，但“没有接触明文卡号”不等于没有支付安全责任。PCI Security Standards Council 明确要求：即使支付处理全部外包，商家仍要确认服务商的合规范围、在书面协议中分配责任，并持续管理第三方关系。PCI SSC：外包支付处理后的责任（在新标签页打开）

Paddle 当前协议允许其审查供应商、商品和网站，也允许在风险条件下限制交易、延迟结算、退款或停止销售。供应商则继续对产品描述、税务分类、定价、交付信息、知识产权、可用性和技术支持负责。Paddle Master Services Agreement（在新标签页打开）。其他 MoR 的风险控制权与供应商义务未必相同，只能按实际协议确认。

无论谁是卖方，SaaS 都要自己决定用户当前能使用什么。业务系统应保存用户、可售目录、订单、订阅、付款尝试和权益状态，并记录外部客户、价格、交易与订阅 ID 的映射。服务商事件只提供外部支付或合同事实，不能直接代替本地订单与权益。否则，一次渠道切换、迟到事件或争议退款，就可能把“曾经付过钱”和“现在仍有权限”混成同一个状态。

客户数据不是一句“归谁所有”能够回答的

下载一份客户邮箱 CSV，只能证明数据可导出。它不能证明卡凭证能转走、原扣款授权仍有效，也不能授权商家把履约数据用于营销。判断客户数据是否“在自己手里”，至少要分开看五种能力。

Paddle 当前的数据共享附录把 Paddle 与供应商视为各自独立的数据控制者（controller），并列出姓名、地址、邮箱、购买历史和 Dashboard 交易分析等共享数据。双方都要为自己的处理目的负责。Paddle Data Sharing Addendum（在新标签页打开）。所以，“客户属于 MoR”或“客户永远属于供应商”都不足以描述真实的数据权利。

符合条件时，Stripe 可以把客户卡信息安全转给新的 PCI DSS Level 1 处理方；由 Link 保存的支付凭证不在这项转移范围内。Stripe：Request a payment data export（在新标签页打开）。同一账户可能同时包含可转移卡数据和不可跨处理方转移的 Link 凭证。迁移能力属于具体凭证类型，不能从“Stripe 支持迁出”推断所有存量续费都能搬走。

本地客户 ID、产品权限、合同版本和支持记录应持续保存在 SaaS 系统中。服务商侧的客户、订阅、发票和交易是外部对象，本地记录通过稳定 ID 与它们映射；邮箱不适合作为唯一主键，因为它会变化，也可能对应重复客户。这样才能在数据删除、邮箱变更或渠道迁移时维持同一业务身份。

迁移成本从第一笔自动续费开始累积

一次性付款切换渠道相对简单：新订单进入新系统，旧订单继续在原系统处理退款和争议。自动续费不同。每个存量订阅都带着旧卖方、支付凭证、扣款授权、远端状态、下次扣款时间和历史税票；这些对象不会随着 API key 一起搬走。

通过安全检查后，Paddle 可以把客户支付详情转到新的 PCI 合规凭证库，订阅者数据由供应商另行导出；Stripe 的卡数据迁出也需要旧、新处理方协作完成加密传输。Paddle Subscription Migration Process（在新标签页打开）。凭证能够转移，只解决了续费链的一部分。产品价格、订阅状态、Webhook、本地映射和历史对账仍要重建或接续。

签约前就应确认可迁出的对象与格式、处理时限、接收方资质、不可转移的支付方式、终止后的访问期限，以及旧交易退款和争议由谁继续处理。“支持导出”若没有这些细节，对存量订阅几乎没有决策价值。等到终止协议时再问，客户是否需要重新绑卡往往已经无法避免。

用 100 美元年费复算经营净额

这笔订单的税前订阅价为 100 美元，买家另付 20 美元间接税。假设 Processor 对这笔支付收取 3.60 美元，MoR 从税前销售额中扣 5.50 美元。汇兑、退款、拒付、储备、跨境结算费和供应商自身税款暂不计入；费率只为演示计算方法，不代表任何服务商报价。

Processor 路径可能先显示 116.40 美元可结算余额，其中 20 美元仍是待缴税款，可支配经营收入只有 96.40 美元。MoR 路径由 MoR 记录并缴纳买家税款，供应商应收为 94.50 美元；这笔供应商收入仍要进入自身会计和税务记录。

金额相近，到账节奏也可能完全不同。若 Processor 暂留买家付款的 10%，即 12 美元，未预留部分在第 7 天结算，12 美元在第 30 天释放；MoR 不另设预留，但要到第 30 天才支付供应商款。真实测算必须替换成账户协议里的滚动预留比例、结算周期、最低付款门槛和银行入账时间。

预留金只是暂时不可用，不应直接记成费用；若出现退款、拒付或负余额，服务商可以按合同从中扣减。MoR 也可能设置预留、抵销或最低付款门槛。表里的 94.50 美元要在没有额外扣留、余额达到付款门槛且银行按期入账时，才会在第 30 天全部可用。因此，全年成本模型要把“扣了多少钱”和“多久能用这笔钱”分开。

按上述假设，直接处理的单笔经营净额多 1.90 美元。这 1.90 美元没有覆盖税务注册与申报、发票、争议、财务工时、工程维护和错误成本。MoR 的成本也不止 5.50 美元，还包括结算周期、汇兑、储备金、退款拒付扣减、标准化结账带来的控制损失和未来迁移。两种方案必须使用相同的交易数、国家、币种、退款率、客单价和人力成本计算全年结果。

Processor 全年成本 = 支付与汇兑费用 + 税务与账票运营 + 风控争议 + 工程财务工时 + 资金占用 + 退出成本

MoR 全年成本 = MoR 合同扣费 + 结算与汇兑 + 未吸收的退款争议 + 控制成本 + 资金占用 + 退出成本

合同没有明确承接的工作，不能从成本中删掉。把内部工时记为零，或把“平台处理拒付”当成零损失，都会把结论推向错误的一侧。

出现这些症状时，责任并没有完整转移

paid 只能证明支付请求完成，不能证明合同、税票、争议、资金和续费都已结束。出现异常时，先确认是哪一类记录没有收敛，再找负责该记录的主体；不要用一个支付状态覆盖整笔交易。

选择 Processor 还是 MoR，取决于哪组责任更难承受

主体无法签约或结算、产品不在服务范围、目标买家或支付方式不可用，都会让候选方案直接变成“不适用”。这些硬边界属于海外 SaaS 收款准入。如果缺的是当前协议、账户审核结果或目标交易覆盖证据，状态应保留为“需要核验”，不能默认可用，也不应误判为永久不支持。

准入成立后，先让买家的合同与发票要求决定销售主体。企业买家必须和你的公司直接成交，就优先使用 Processor；消费者订单接受 MoR、企业订单又要求直接签约时，才需要两条销售渠道。买家没有强制要求，再比较团队是否承受得起多市场税票和争议运营，以及是否承受得起定价、数据、资金和退出控制的让渡。

两种模式都满足硬条件时，才进入成本比较。使用同一组交易量、国家、币种、退款率和人力价格复算，并把支付凭证迁出、历史账票保留和旧订单争议写进退出成本。公开费率只占其中一行。

选择 Processor，经营主体保留买家合同、账票、退款策略、支付编排和资金关系，同时也要给这些工作配置长期负责人。选择 MoR，多市场的交易工作由同一卖方运营，供应商则要接受它的商品范围、风控决定、买家凭证、结算节奏、数据用途和退出流程。

混合模式只有在订单约束确实不同的时候才成立。例如，自助 B2C 由 MoR 销售，企业年付合同由自有主体通过 Processor 收款。这是两条明确的销售渠道，不是随机展示两个付款按钮。每笔订单都必须保存卖方主体、服务商商品、税务责任方、发票出具方、退款入口和续费授权方；服务商支持交易级 MoR 只是前提，本地目录、订单、权益和财务也要识别两套事实。

全球 B2C、企业 B2B 与混合销售的选择结果

多国自助 B2C：小团队更难承受税票与争议运营

一家小团队销售标准化在线工具，采用月付自助订阅，买家分布在欧盟、英国、美国和亚太多个市场，团队没有专职税务、财务和争议人员。只要主体、产品和结算账户通过准入，买家也接受 MoR 的卖方名称与退款流程，MoR 通常更匹配这类订单：多地间接税、交易凭证和争议操作可以由同一卖方处理。

但这不等于随便选一家 MoR。销售国家、商品分类、结算币种、退款拒付扣减、数据用途和支付凭证迁出都要与这家公司的真实条件相符。第一笔正式小额订单还应核对买家发票、账单名称、Webhook、本地权益和最终结算。覆盖证据缺失时保留“需要核验”；协议明确拒绝某项硬条件时才是“不适用”。

企业年付 B2B：买家的采购制度决定卖方

一家香港公司主要签企业年付合同。客户要求供应商准入、采购订单、合同盖章、30 天账期，并要求凭证使用香港公司的税务信息；团队已有会计和跨境税务支持，网页结账也不是主要销售入口。此时，合同与账票的一致性比自助税务自动化更重要，Processor、银行转账和自有发票体系通常更容易保持同一个供应商身份。

只有企业客户接受 MoR 作为卖方，销售辅助发票能够承载 PO 与税务字段，产品服务条款也能继续执行，MoR 路径才成立。让真实客户的采购和财务先验证完整文档链，比集成完成后才发现合同主体不被接受便宜得多。

B2C 与企业销售并存：按订单保留两套事实

自助版面向多个国家的个人买家，企业版采用议价年费、PO 和实施服务。所有订单强行使用同一模型，要么让 B2C 承担沉重的多地税务运营，要么让企业销售失去合同和开票能力。两条路径可以分别使用 MoR 与 Processor，前提是产品目录标明可售渠道，订单记录真实卖方，订阅续费不会跨渠道漂移，财务也能分别对账。

企业合同若还包含第三方卖家分账、代收代付或平台入驻，问题已经越过普通 SaaS 的 Processor/MoR 选择。此时需要单独设计 marketplace、Connect 或平台支付责任，数字产品 MoR 账户不能充当第三方资金通道。

主体、产品、买家和销售渠道变化后必须重判

账户获批只能证明当时提交的主体、产品和交易条件被接受。以下任一变化，都可能让原来的合同与覆盖证据失效：

这笔 100 美元订单的责任模型能否成立，要看五件事能否落到明确主体：谁与买家成交，谁执行交易工作，谁掌握决定权，谁承担经济结果，谁控制并保留数据证据。任何一项只能用“平台会处理”回答，都还不能签下长期续费关系。

确认这五项后，把真实订单的主体、买家国家、B2B/B2C、币种、支付方式、税票要求、退款率、结算账户和退出条件带入Stripe、Paddle、Lemon Squeezy 与 Creem 的同口径比较。这些条件相同，平台结论才可比；公开费率只是其中一个输入。

常见问题

Stripe 是 Payment Processor 还是 Merchant of Record？

取决于具体产品和交易。普通 Stripe Payments 通常提供支付处理服务，商家仍是卖方；Stripe Managed Payments 可在符合条件的交易中由 Link 担任 Merchant of Record。品牌名不能代替产品、交易范围和生效协议。

使用 Merchant of Record 后还需要处理税务吗？

需要。MoR 通常处理覆盖交易的 VAT、GST、销售税等间接税，供应商仍要保证商品分类与交易资料准确，并处理自身所得税、企业税、预提税以及范围外销售。

Merchant of Record 处理拒付后，供应商还会损失钱吗？

可能。MoR 可以接收争议并提交证据，合同仍可能把退款金额、拒付金额、处理费或负余额从供应商余额及后续结算中扣除。

使用 Merchant of Record 后，客户数据归谁？

“归谁”不足以判断控制权。需要分别确认可访问字段、允许用途、普通数据导出、支付凭证转移、续费授权，以及终止后还能保留哪些历史记录。

同一个 SaaS 可以同时使用 Payment Processor 和 Merchant of Record 吗？

可以。前提是服务商支持对应交易范围，系统也能按订单保存真实卖方、税务责任、账票来源、退款入口和订阅续费归属。