海外 SaaS 收款不只是接一个支付按钮，还会涉及订阅、退款、拒付、税务、发票、支付方式、商户主体和用户权限。MVP 阶段最重要的选择，是要自己承担这些工作，还是交给 Merchant of Record（MoR）。
本文只比较数字产品和 SaaS 常见方案，费率、地区支持和审核规则会变化，上线前应以各家官网和合同为准。
先理解两种模式
PSP：你是商户，平台负责支付能力
Stripe 属于典型 PSP + Billing 方案。你的企业或个人主体直接面向客户销售产品，Stripe 提供 Checkout、Payment Intents、订阅、发票、Webhook 和税务工具。
这种模式的优点是控制力强：结账体验、价格模型、客户和订阅数据都更容易按自己的业务设计。代价是你需要自行处理主体审核、税务注册与申报、退款、拒付、账单状态和支付失败后的权益回收。
MoR：平台作为交易中的法定卖方
Lemon Squeezy、Paddle、Polar 等 MoR 会代你处理一部分销售税、VAT、退款、拒付和支付合规。你收到的是平台结算后的收入，客户账单上通常也会出现平台名称。
MoR 能明显降低跨境销售的启动成本，但不是“完全不用管税务”：平台结算收入可能仍涉及你所在国家或地区的所得税、公司税和合规义务；同时你还要接受平台的商品类别审核、结算周期和账户风控。
总表
| 项目 | 模式 | 适合场景 | 优点 | 主要代价 |
|---|---|---|---|---|
| Stripe | PSP / Billing | 需要高度定制的 SaaS、复杂订阅和平台业务 | API、Checkout、订阅和生态成熟 | 主体、税务、退款和拒付需要自己负责 |
| Lemon Squeezy | MoR | 数字产品、软件和早期 SaaS | 上手快，跨境税务与支付合规负担较低 | 定制能力和审核范围受平台约束 |
| Paddle | MoR | 面向全球销售的 SaaS 和数字产品 | 订阅、税务、支付方式和客户门户较完整 | 平台费率、审核和结算规则需要接受 |
| Polar | MoR | 开发者产品、开源项目和数字产品 | API 与开发者工作流友好 | 业务类型限制较多，不适合实体商品和人工服务 |
| FastSpring | MoR | 软件、数字产品和全球订阅 | 软件销售、税务、订阅和数字交付较完整 | 商业审核、费用和结算规则需要接受 |
| PayPal | PSP / 钱包 | 需要覆盖 PayPal 用户和常规订阅的产品 | 用户认知高，支持订阅、试用和支付恢复 | 结账体验、地区能力和争议处理要单独设计 |
| Payoneer | 跨境收款 | 接收平台、企业或海外客户付款 | 适合收款和提现，不局限于 SaaS Checkout | 不是完整的订阅结账与权益管理系统 |
| Paddle Billing | 订阅计费 | 已确定使用 Paddle 生态 | 订阅生命周期和 Webhook 较完整 | 仍然要围绕 Paddle 的产品模型设计 |
Stripe：控制力优先时的默认选择
Stripe 适合把支付作为产品核心能力来建设的团队。常见组合是：
- Stripe Checkout 负责收集支付信息；
- Stripe Billing 管理订阅、试用、升级、降级和取消；
- Webhook 驱动本地订单和用户权益状态；
- Stripe Tax 或其他税务方案处理交易税计算；
- 你的数据库保存用户、订单、订阅和权益的业务映射。
需要注意，Stripe 的支付成功页面不是业务状态的唯一来源。用户关闭页面、网络超时和重复事件都可能让前端状态不完整，应该以经过验签的 Webhook 为准，并为事件处理做幂等。
Stripe 更适合：
- 有明确海外企业主体和税务方案的团队；
- 需要复杂用量计费、按席位计费或多种价格组合的 SaaS；
- 需要把客户、发票、订阅和产品数据掌握在自己系统里；
- 未来可能做平台分账、Connect 或较深的支付定制。
Lemon Squeezy：数字产品 MVP 的低运维方案
Lemon Squeezy 是 MoR，适合软件、数字下载、订阅和在线课程等能通过数字方式交付的产品。它的核心价值不是“支付 API 比 Stripe 简单”，而是减少早期团队自己处理全球销售税、VAT、欺诈、退款和拒付的工作。
它更适合：
- 还没有海外公司或不想先搭完整税务体系；
- 产品是数字服务，不涉及实体发货和人工交付；
- 需要尽快验证“注册 → 付费 → 开通权益”闭环；
- 可以接受平台 Checkout、审核和结算流程。
使用时要把 Lemon Squeezy 的订单和订阅 ID 保存到自己的数据库里。不要只在支付回调里直接修改用户权限而不留订单记录，否则后续退款、取消和争议处理会很难追踪。
Paddle：更完整的 SaaS 商业化平台
Paddle 也是面向 SaaS 和数字产品的 MoR，除了 Checkout，还提供订阅生命周期、税务、退款、拒付、客户门户和开发者 API。
Paddle 适合已经确定要面向多个国家销售，并且希望把账单、税务、支付方式和订阅管理放在同一个商业化平台中的团队。相比只接一个支付按钮，它需要你更认真地理解产品、价格、订阅、交易和 Webhook 事件之间的关系。
FastSpring：软件和数字产品的 MoR
FastSpring 同样面向软件、数字产品和 SaaS，提供 MoR、订阅、数字发票、税务处理、支付方式和 Webhook。它适合已经确认要销售可数字交付产品，同时希望保留一定品牌化 Checkout 能力的团队。
FastSpring 与 Lemon Squeezy、Paddle 的取舍，重点看产品类别、审核、B2B 发票、结算周期和客户门户，不要只比较表面费率。
PayPal：补充钱包支付和订阅
PayPal 适合作为支付方式补充，尤其是目标用户习惯使用 PayPal，或者产品需要支持固定周期、试用、升级和降级订阅的场景。它可以通过 Subscriptions API 接入自己的产品界面。
PayPal 更像支付渠道，而不是完整的 SaaS 权益系统。订单、订阅状态、退款、拒付和用户权益仍要通过 Webhook 同步到自己的数据库。
Polar：开发者产品与开源项目优先
Polar 面向数字产品、软件、SaaS、GitHub 仓库和社区访问等场景。它的开发者体验和 API 取向比较明显，适合开源项目、开发者工具和轻量数字产品。
但 Polar 对实体商品、人工服务、市场平台、金融服务等类别存在限制。选型前先核对产品是否符合可接受业务范围，不要等到上线后才发现审核无法通过。
怎么选
| 情况 | 推荐 |
|---|---|
| 只想快速验证数字产品是否有人付费 | Lemon Squeezy 或 Paddle |
| 需要软件类 MoR，并希望保留更完整的数字销售能力 | FastSpring、Paddle 或 Lemon Squeezy |
| 没有成熟海外主体，优先降低税务和合规负担 | 先看 MoR：Lemon Squeezy、Paddle、Polar |
| 需要复杂订阅、用量计费和深度定制 | Stripe |
| 目标客户经常使用 PayPal | Stripe + PayPal，或先用 PayPal 验证支付接受度 |
| 开源项目、开发者工具和数字权益 | Polar、Lemon Squeezy 或 Paddle |
| 实体商品、人工服务或平台分账 | 先确认 MoR 是否支持；通常要评估 Stripe 等 PSP |
支付接入的最小数据模型
即使使用 MoR，也建议至少保存以下数据：
| 数据 | 用途 |
|---|---|
customer_id | 对应支付平台客户 |
product_id / price_id | 对应平台商品和价格 |
subscription_id | 查询订阅状态和周期 |
order_id / transaction_id | 退款、对账和客服查询 |
status、current_period_end | 判断权益是否有效 |
provider | 未来迁移或同时接入多个支付平台 |
用户权益应该由自己的业务状态决定，而不是把支付平台的对象直接当成权限系统。支付平台的 Webhook 负责同步事件，你的数据库负责产生最终可查询的业务状态。
上线前的检查清单
- 测试支付成功、支付失败、退款、部分退款、取消和续费失败；
- 对 Webhook 验签，并按事件 ID 做幂等；
- 明确试用期结束、宽限期和欠费后的权益策略；
- 确认账单上显示的商户名称和客服联系方式；
- 核对产品是否属于平台允许销售的类别；
- 记录平台结算、退款和手续费，方便对账；
- 不要把免费档和当前费率写死在产品文档里，定期复核官方页面。
结语
MVP 阶段通常不需要自己实现一整套支付基础设施。数字产品优先考虑 MoR，验证成功后再根据控制力、费率、税务和客户规模决定是否迁移到 Stripe。真正重要的不是哪个平台“最便宜”，而是支付成功后你的订单、订阅和用户权益能否稳定同步。