Stripe Billing vs. Chargebee vs. Recurly：选择适合你的 SaaS 订阅计费平台

你推出了自己的 SaaS 产品，拿下了最初的十位付费客户，现在你正盯着一个感觉比它本该有的分量还要重的决定：该在哪个订阅计费平台上搭建业务？选错了，十八个月后你会手忙脚乱地花一整周去迁移成千上万个正在使用的订阅，一边迁移一边祈祷别出岔子。选对了，计费就会变成一套你再也不用去想的隐形基础设施。

这里的风险是真实存在的。所有订阅流失中大约有 20%-40% 是非自愿的——客户并不是真的想取消，只是他们的银行卡过期或被拒付了，而没人及时发现。仅这一种失败模式，在全行业范围内就吞掉了估计 9% 的月经常性收入（MRR），而过期银行卡本身就导致了 42% 的支付失败。无论你现在是否意识到，你选择的计费平台同时也是你抵御每月悄然流失收入的主要防线。

对于正在成长的 SaaS 公司来说，有三个平台主导着这场讨论：Stripe Billing、Chargebee 和 Recurly。它们各自为一类不同的公司做了优化。下面来看看该如何判断哪一个是你的选择。

快速结论​

• 产品由开发者主导构建、团队规模小、希望快速上线？ → Stripe Billing
• 非工程背景的同事需要无需提交工单就能调整定价？ → Chargebee
• 企业级 B2B 业务、合同和计量复杂，或者支付挽回是你最大的增长杠杆？ → Recurly

下面来逐一拆解原因。

Stripe Billing：开发者的默认之选​

如果你的工程团队已经集成了 Stripe 来处理一次性支付，那么 Stripe Billing 就是阻力最小的选择。它不是一个外挂的第三方工具，而是你很可能已经在使用的支付基础设施的原生延伸。

优势所在：

• API 的一致性。 Stripe 的 API 以文档完善著称，其 CLI 工具让本地测试 webhook 和订阅事件变得毫不费力——对于一个两三人的工程团队来说，这能真正节省大量时间。
• 无需自建的客户门户。 Stripe 提供了一个预构建、可自定义品牌的客户门户，订阅用户可以在其中升级、降级或更新支付方式，完全不用给你的客服邮箱发邮件。
• 透明的按用量计费。 没有单独的平台订阅费——你只需为处理的经常性收入支付约 0.5% 的费用，不过如果你需要 Stripe Tax（每笔交易 +0.5%）或 Stripe Revenue Recognition（+0.25%）等附加模块，费用会逐渐累加。

局限所在： Stripe Billing 功能强大，但本质上是代码优先的。如果你的定价模型变得复杂——比如阶梯定价加用量加超额，再加上周期中途升级和年度合同按比例分摊——你很可能最终需要编写并维护自定义逻辑，来处理平台原生不支持的边缘情况。而且由于它是为开发者打造的，市场或财务团队的成员通常无法在没有工程团队参与的情况下安全地调整方案。

最适合： MRR 大致在 50 万美元以下、由开发者主导的早期 SaaS 公司，它们希望以最短路径从"我们能收款"走到"我们在运营订阅"，并且愿意在代码中自行承担一部分计费逻辑。

Chargebee：为定价实验而生​

Chargebee 存在的全部理由就是灵活性。对于预期会调整定价模型的团队来说，它是首选平台——如果你是创业第一年或第二年的 SaaS 创始人，你很可能会调整。几乎每一家成功的 SaaS 公司都会在了解客户真正看重什么的过程中，至少对定价迭代一次。

优势所在：

• 无代码的方案管理。 产品和财务团队无需提交 pull request，就可以创建、测试并修改定价档位、附加项、优惠券以及用量加固定费率的混合模式。
• 真正能处理复杂性。 带用量超额的阶梯定价、支持中途升级的年度合同、多主体计费——在这三者中，Chargebee 往往是唯一能原生处理这些场景、无需变通方案的平台。
• 强大的会计集成。 相较于 Stripe Billing 的原生工具，Chargebee 在收入确认以及导出到会计/ERP 系统方面往往更成熟——一旦你有了财务主管或外部记账员每月对账结账，这一点就会变得重要。

局限所在： 一旦你的业务超出免费档位，Chargebee 的价格会明显上一个台阶（累计计费大约达到 10 万美元后，就会开始收取每月数百到超过一千美元不等的固定费用），因此在你尚未产生收入或刚刚起步时，相比纯按收入百分比计费的模式，这是一项更大的投入。

最适合： 正在超越最初定价模型、持续扩张的 SaaS 公司，尤其是那些需要由非工程背景人员（增长负责人、财务负责人）直接掌管计费配置的团队。

Recurly：为止血而生​

Recurly 的定位更窄，但对于合适的公司来说，它比另外两个竞争对手更有价值：它存在的目的就是减少你因支付失败而默默流失的资金。

优势所在：

• 将智能催收作为核心产品。 Recurly 基于机器学习优化的重试逻辑会自行判断何时以及重试多少次来重新发起一笔被拒绝的扣款，而不是按照固定时间表重试——那样要么放弃得太早，要么因重试次数过多惹恼客户。
• 流失预测。 Recurly 的分析功能会在有风险的账户取消订阅之前就标记出它们——异常的用量下滑、反复出现的接近失败——从而给你的团队一个介入的机会。
• 按收入百分比计费，没有平台费，与 Stripe Billing 类似，这让小公司也能负担得起，同时依然能够争取企业级合同。

局限所在： Recurly 的核心优势——催收与挽回——只有在你真正拥有交易量之后才最重要。一家只有 40 个客户、五人规模的初创公司感受不到差别；而一家每月处理数万笔扣款的公司会立刻感受到，因为数据能佐证这一点：自动化催收能挽回本会流失的 40%-70% 失败支付，相比之下完全不加干预时只能挽回约 15%。

最适合： 支付失败已成为可衡量、持续增长的成本项的订阅制业务——尤其是 B2C 或高交易量的 B2B——又或者是计量和合同条款复杂的企业级 B2B SaaS。

一览对比​

切换成本是真实存在的——提早规划​

把这个决定当作低风险的选择很有诱惑力("如果我们用不下去了以后再换就是了")。但实际上，在计费平台之间迁移一个正在运行的订阅用户群，是成长中的 SaaS 公司可能承担的最痛苦的项目之一。你迁移的不只是一张数据库表——你迁移的是：

• 有效的支付方式。 取决于涉及的平台，你可能无法以编程方式转移已存储的银行卡，这意味着一定比例的客户必须重新输入支付信息，否则就有可能在切换过程中流失。
• 按比例分摊与合同状态。 周期中途的订阅、带有未使用额度的年度合同，以及任何自定义折扣，都需要被精确地重建，否则客户就会被错误计费，你的客服队列也会迅速被填满。
• 历史报表的连续性。 依赖计费平台数据模型的 MRR、流失率和分群仪表盘，在迁移前后可能出现数据断层，除非你已经仔细规划了历史数据回填。
• 催收与挽回逻辑。 举例来说，如果你出于成本原因迁离 Recurly，你就要承担起重建其智能重试机制原本默默守护的那部分挽回率的责任。

这并不意味着你会被永远锁定——很多公司确实成功完成了迁移。这只是说明"现在选最便宜的，以后再换"这种思路，低估了"以后"实际有多昂贵。相比单纯为了今天的账单去做优化，为十二到十八个月后仍然适配你业务模型的平台稍微多做一些预留，通常更划算。

一个简单的决策方法​

按顺序问自己三个问题：

1. 我的工程团队规模小、计费逻辑简单吗？ 如果是，Stripe Billing 能让你最快上线。
2. 是否需要非工程背景的人员来调整定价，或者我的模型已经很复杂（阶梯+用量+合同）？ 如果是，Chargebee 更高的价格是值得的。
3. 我是否正在因扣款失败和非自愿流失而损失一笔可衡量的收入？ 如果支付失败正在成为一个不断增长的成本中心，那么 Recurly 的专精投入会自行回本——通常只需挽回最初几笔交易就能收回成本。

MRR 大致在 10 万美元以下的创始人，应该更看重"上手的简便程度"。而当 MRR 超过 50 万美元后，权衡的重点会转向支付表现与挽回能力，因为随着规模扩大，即便是催收挽回率上几个百分点的提升，也会转化为实实在在的收入。

无论选择哪个平台，都要留意这一点​

无论哪个计费平台最终胜出，有一个问题都不会自行消失：订阅收入不仅需要被收取，还需要被正确记录。一笔在 Stripe、Chargebee 或 Recurly 上成功的扣款，在到账的那一刻并不会自动成为你账本上的"收入"——递延收入、退款、按比例分摊的抵扣，以及先失败后被挽回的扣款，都需要与你的计费平台所报告的数据进行核对。那些把支付处理商的仪表盘当作财务真相来源的创始人，往往就是在第一次融资或报税前被一团糟的账本清理工作打个措手不及的人。

这正是良好记账习惯能提早带来回报的地方。每一笔订阅扣款、退款、催收挽回和方案变更，都是一笔应该记录在你的账本里的交易——而不能只留在计费平台的报表界面里，因为那本来就不是为了兼任你的会计系统而设计的。

让你的账本和计费系统一样干净​

选对订阅计费平台只解决了问题的一半——准确记录这些收入是另一半。Beancount.io 为 SaaS 创始人提供透明、可版本控制、且易于与 Stripe、Chargebee 或 Recurly 导出数据对账的纯文本记账方式，没有供应商锁定，也没有黑箱账本。查看文档了解它如何处理经常性收入，或者体验 Fava 提供的账本可视化仪表盘——然后免费开始使用，让你的财务记录像代码一样可审计。