AI 工具出海收款,别只比手续费:先选你要不要自己当卖家

一个小团队准备把 SaaS 卖到美国和欧洲，开发已经做完，结果卡在了一个看起来很初级的问题：到底选哪个收款平台？

这个问题出现在 8 月 21 日的 r/SaaS。发帖人说预算不是问题，他更怕今天选错，几个月后被迫重建整套支付系统。

我觉得很多 AI 工具开发者从第一步就问错了。你不该先比较谁的卡费低几个小数点，而应该先决定：这笔交易里，你要不要自己当那个卖家。

如果这个责任没选清楚，你后面比的手续费、结账周期、订阅界面，根本不在同一张答卷上。

你以为在选收款按钮，实际在选责任边界

最简单的两条路，一条是支付服务商（PSP），一条是 Merchant of Record（MoR，登记卖家）。

用普通支付服务时，你自己是向客户卖数字产品的主体。收款平台帮你处理付款页、支付方式、卡网络和一部分风险控制，但产品售卖、订阅规则、税务配置、退款与客户关系的整体责任仍在你这边。Stripe Checkout 本质上是一个可托管的收银台 UI 与 Checkout Sessions API，它可以结合 Billing、Tax 和自适应定价等能力，但“结账页由 Stripe 托管”不等于“Stripe 自动替你成为卖家”。

MoR 的结构不一样。Paddle 在官方说明中把它描述成两段交易：终端客户向 MoR 购买，MoR 再与你结算。因为它是交易中面向买家的卖家，所以会承担计算和缴纳销售税、部分支付合规、退款和拒付处理等交易责任。

所以你不是在比“两个收银台”。你在比一套自己组装的支付栈，和一套把交易责任一起打包的服务。

Stripe 也有 MoR，所以别再用旧印象选型

事情又多了一层变化。Stripe 已经推出 Managed Payments，官方把它称为面向数字产品的 Merchant of Record 解决方案。官方文档写明，它处理 80 多个国家和地区的销售税、VAT 与 GST 合规，也包含欺诈防护、支付争议管理和交易级客服。

这意味着“Stripe 还是 Paddle”已经不是一个足够精确的问题。更正确的问法是：

我用的是 Stripe 普通 Checkout，还是 Managed Payments？

我是否符合 Managed Payments 的资格与产品类型限制？

我需要多少自定义结账、订阅变更、销售辅助与发票能力？

我想把税务工具接在自有账户上，还是希望连交易卖家责任一起外包？

Lemon Squeezy 的官方文档也明确把平台定义为 Merchant of Record，也就是说，它和 Paddle、Stripe Managed Payments 的可比较层级，会比它和普通 Stripe Checkout 更接近。

这些产品都在变，资格、支持市场和功能也会变。因此不要把一张两年前的“平台对比表”当今天的架构结论。

小团队真正该比的六件事

如果是一个刚准备收第一笔钱的 AI 工具，我会按下面这个顺序选，而不是先打开价格页。

第一，你卖的是什么。

数字内容、SaaS 订阅、按量计费、定制服务、市场平台分账，对结账和责任的要求不一样。先用官方资格页确认你的产品类型能不能进。

第二，你第一年真正卖到哪些地方。

“面向全球”通常不是一个计划。把现有流量、语言、客服能力和支付方式放在一起，先锁两三个真实市场。

第三，你是否有人处理交易后工作。

收款不是卡成功了就结束。订阅变更、失败重试、退款、拒付、账单、客服和税务记录都会跟上来。没有专门运营与财务的小团队，管理成本往往比支付按钮本身更贵。

第四，你需要多大的自定义权。

如果你有复杂订阅、销售代理报价、信用额度、多方分账或自建财务系统，就不能只看“上线快”。

第五，失败时能不能搬家。

客户、产品、价格、订阅状态、优惠、发票和支付方法令牌，哪些能导出，哪些需要重新授权，一定要在开发前问清楚。

第六，账号被限制时怎么停损。

任何一家收款服务都不应成为你唯一的客户和权益数据库。产品权益要能从自己的账本里恢复，不要只靠某个平台的后台页面证明谁买了什么。

手续费之外，还有三笔更容易漏掉的钱

第一笔是支付失败带来的收入损失。同一张卡在不同地区、币种和风险规则下，是否能成功付款，不是一个固定手续费能表达的。如果目标用户经常付不出去，表面费率低也没有意义。

第二笔是人工处理成本。每月花多少时间对账、处理退款、回复交易级问题、追失败订阅，这些时间不会出现在平台价格表上。Stripe Managed Payments 把争议管理和交易级客服列入产品能力，就说明 MoR 卖的不只是一个收银页。

第三笔是迁移成本。把一个付费用户从 A 平台搬到 B 平台，不是把一行 ID 改掉。你要处理订阅周期、未使用权益、优惠、支付授权、发票历史和用户通知。一开始没留映射和导出能力，节省的那一点费率很容易在搬家时一次还回去。

最小可行的收款架构，要为搬家留一扇门

这里有一套可直接复制的实现方式。

不管选哪家，都在自己数据库保留五个核心对象：用户、内部产品、内部价格方案、权益状态和外部支付对象映射。平台的 customer ID、subscription ID 和 price ID 只是外部标识，不要直接变成你的产品模型。

所有 webhook 要支持幂等：同一个事件来两次，不能给用户叠加两次权益。权益变更要留日志，要能看到是哪个支付事件、人工操作或试用规则改了状态。

每月导出一次客户、订阅和结算摘要，然后真正演练一次“不登录平台后台，我能否知道哪些人应该有权益”。这个答案比“SDK 集成只要几分钟”重要得多。

这套架构本身也是一个可卖的窄产品机会：不要做“又一个全能支付平台”，而是做某个技术栈的收款上线门禁和迁移助手。它可以检查 webhook 幂等、产品映射、退订回收、数据导出和演练清单，按一次上线审计或迁移项目收费。

我不会根据一篇平台文章做税务决定

Paddle 和 Lemon Squeezy 对 MoR 的说明是官方产品资料，Stripe Managed Payments 的覆盖与能力也是厂商当前陈述。它们可以帮你理解架构，不能代替你根据公司注册地、客户所在地和产品类型做税务与法律判断。

更现实的做法是，先用官方资格页排除不可用选项，再把真实销售地区、产品类型和交易规模交给专业顾问确认。功能和价格变化时，回到官方文档重新核对，不要拿截图做永久决策。

收款选型的真正问题从来不是“哪家更便宜”。它是：哪些责任值得自己控制，哪些责任已经足以把一个小团队拖离产品。