MoR 不是「更省事的支付按钮」。它会改掉整条交易链：客户账单上看到谁，税由谁收，退款谁处理，争议谁出面，平台费和净收入怎么进报表。
独立开发者选 MoR，最容易犯的错是只看首页费率。费率当然要算，但半年后更折磨人的通常是迁移订阅、补开发票、解释 payout、处理 chargeback。
三家应该先看谁？
| 场景 | 默认候选 | 为什么 |
|---|---|---|
| B2B SaaS、订阅、团队席位 | Paddle | 订阅、发票、tax、payout reconciliation 和 chargeback 流程更成熟 |
| 模板、插件、小工具、数字下载 | Lemon Squeezy | 接入轻，payments、sales tax、VAT、refunds、chargebacks 文档清楚 |
| 开源赞助、license、GitHub 生态 | Polar | 面向开发者，公开 MoR 费率和订阅附加费，适合先验证购买意愿 |
| 还没有真实客户 | 先别急着 MoR | 5 个手动客户用 invoice 或 Stripe 也能跑，确认谁愿意付钱 |
这张表只是第一轮分流，不是最终答案。真正的选择，要回到你的产品形态、客户类型和财务对账能力。
MoR 到底替你承担什么？
| 事项 | Lemon Squeezy | Paddle | Polar | 你自己还要做什么 |
|---|---|---|---|---|
| 销售税/VAT/GST | 文档说明平台作为 MoR 处理 sales tax 和 VAT | MoR 模型下处理 tax compliance | MoR 文档说明处理全球税务合规 | 公司所得税、个人税务居民身份、本地申报 |
| 发票 | 客户发票由平台链路产生 | transaction、invoice entity、tax 字段进入对账报表 | 客户收到 Polar 作为 MoR 的发票 | 把发票样张给会计看 |
| 退款 | Orders/Refund 流程处理 | transaction adjustment、credit note | 走 Polar 的订单和 payout 流程 | 内部权益回收、客服记录 |
| Chargeback | 文档列出 refunds/chargebacks 规则和 dispute fee | Paddle 作为 MoR 处理抗辩，余额会扣交易额和费用 | 费用页列出争议相关费用 | 订阅滥用、退款政策、风控文案 |
| Payout | 平台结算到你账户 | 报表里有 gross、tax、Paddle fee、chargeback fee、retained fee | payout 和 reverse invoice 进入财务链路 | 银行流水、记账科目、收入确认 |
| 客户关系 | 部分账单和税务沟通由平台承担 | 客户发票和争议面对 Paddle | 客户发票面对 Polar | 产品支持、功能交付、客户成功 |
MoR 省的是交易层杂事，不是公司治理。你仍然要解释收入来自哪里、客户在哪里、平台扣了什么、银行收到的每一笔 payout 对应哪些订单。
费用和报表要怎么比？
公开费率只是一行，报表字段才决定你月底能不能对账。
| 费用/字段 | Lemon Squeezy | Paddle | Polar |
|---|---|---|---|
| 基础费率口径 | 官方费用页常见示例为 5% + $0.50，另有国际卡、PayPal、订阅等附加费用 | 以合同、后台和产品方案为准，别用第三方旧费率做预算 | 公开 MoR 费率为 4% + $0.40，国际卡和订阅附加费按官方 fees 页面当日口径比对 |
| 税额 | 订单税额和发票链路 | tax_in_transaction_currency、tax_in_balance_currency、tax_rate_list | 发票和 payout 资料体现税务处理 |
| 平台费 | order / payout 里看 fee | paddle_fee_in_transaction_currency、paddle_fee_in_balance_currency | MoR fee、payout fee、reverse invoice |
| 争议费 | 文档提到 chargeback 场景下可能有 dispute fee | 卡争议常见 $15/£15/€15，PayPal 常见 $20/£20/€20 | 看官方 fees 页面当日口径 |
| 对账货币 | 看 payout 账户和结算币种 | Paddle 文档建议 always use balance currency fields | 看 Stripe payout 和 reverse invoice |
Paddle payout reconciliation 文档里的字段很值得抄进自己的台账，尤其是 total_gross_in_balance_currency、tax_in_balance_currency、paddle_fee_in_balance_currency、chargeback_fee_in_balance_currency、retained_fee_in_balance_currency 和 invoice_entity。
这些字段决定你和会计说的是同一笔钱，还是三个人在看三张表。
接入前要跑哪 8 个测试？
别只跑一次成功付款。至少把下面 8 个动作跑完：
- 创建产品和价格。
- 新客户付款。
- 老客户升级订阅。
- 取消订阅。
- 全额退款。
- 部分退款。
- 下载发票。
- 导出 payout 或 reconciliation 报表。
跑完后，把 webhook 或 API 事件写进表：订单 id、客户 id、订阅 id、税额、平台费、退款 id、发票 id、payout id。哪家平台让你更容易拿到这些字段，哪家才适合你的业务。
MoR 会自动解决税务解释吗？
不会。
Reddit 上关于 MoR 和 VAT 的讨论，常见问题不是「平台有没有收税」，而是客户、会计或卖家自己不知道账单链路该怎么解释。比如 B2B 客户要求公司抬头、VAT 号和 reverse charge，MoR 发票却是平台抬头，这时客服脚本必须提前写好。
另一个常见坑是迁移。你从 Lemon Squeezy 迁到 Paddle，或者从 Polar 迁到 Stripe，订阅、客户税号、发票历史、license entitlement、退款窗口都不会自动跟着你走。
早期可以轻，但别把客户数据锁死在一个后台里。
什么情况下先别上 MoR？
如果你只有少量手动客户，并且客户都来自同一个国家或地区，MoR 可能太早，用 Stripe Invoice、银行转账或手动合同收款，也能把产品、定价和退款政策跑清楚。
如果你开始自动卖给 EU、UK、US 多州客户，或者下载类产品每天都有小额订单，MoR 价值会变明显。判断标准不是收入数字，而是你是否愿意自己处理税、发票、退款和争议。
MoR 后台管理
MoR 后台、Stripe、银行、GitHub、Cloudflare 经常要一起打开。退款、webhook 调试和 payout 对账都属于高风险操作，不适合在临时设备、公共网络或多人混用环境里随手处理。
可以把财务、部署和收款后台放进固定登录环境，用独立开发者出海稳定专线承载核心后台操作。这样做是为了让退款、对账、部署这些动作有固定设备、固定负责人和固定记录，而不是换一个网络名词。
最后怎么选？
| 你的情况 | 更稳的下一步 |
|---|---|
| 开源项目刚有人愿意赞助 | 先试 Polar，确认 license、订阅和 payout 报表能用 |
| 模板、插件、小数字商品 | 试 Lemon Squeezy，重点看发票、退款和税额显示 |
| B2B SaaS 已有订阅客户 | 认真评估 Paddle，跑升级、退款、chargeback 和 payout 对账 |
| 客户主要是企业采购 | 确认 invoice 抬头、税号、采购流程和退款政策 |
| 未来可能迁移 | 第一周就导出 customer、subscription、invoice、license 映射表 |
选 MoR 的目标不是找到一个永远不用管的后台。目标是把销售税、发票和争议从你的日常工作里移走，同时别让对账和迁移变成新的坑。