SAAS 应用可以使用哪些 Billing provider？

结论

不建议从零开发一套完整的 Billing 系统。对大多数 SaaS 应用来说，更稳妥的方案是使用成熟的订阅计费平台，再通过 API 和 Webhook 接入业务系统。

常见方案主要分为三类：

如果产品面向中小企业，套餐也比较简单，可以先评估 Stripe Billing 或 Paddle。如果业务涉及销售团队报价、年度合同、阶梯计价、多币种、用量计费或复杂的财务确认，则更适合评估 Chargebee、Recurly、Zuora 或 Maxio。

各平台支持的国家和地区、税务能力、支付方式及价格都可能调整。正式选型前，需要查看服务商的当前文档，并确认其是否覆盖目标客户所在地区。

Billing 服务需要覆盖哪些能力

Billing 不只是定期扣款。一套能够投入生产的方案，至少需要处理以下事项：

• 产品、套餐、价格和优惠规则
• 月付、年付、试用期和自动续订
• 套餐升级、降级及按比例计费
• 固定计费、席位计费和用量计费
• Invoice 的创建、发送、作废和贷项通知单
• 信用卡、银行转账及其他本地支付方式
• 支付失败重试与催收流程，即 dunning
• 到期提醒、续费提醒和付款失败通知
• 退款、争议付款和 chargeback
• 税率、税号、发票编号及账单地址
• 与财务系统、CRM 和数据仓库同步
• Webhook 重试、幂等处理和审计日志

还需要区分”商业 Invoice”和当地法律定义的税务发票。Billing 平台能够生成账单，不等于它自动符合所有国家或地区的税务开票要求。

如何选择 Provider

1. 先确定由谁承担交易责任

使用 Stripe Billing 这类服务时，通常由你的公司直接向客户销售，平台提供支付和订阅工具。税务登记、退款政策和大部分合规责任仍由你的公司承担。

在 Merchant of Record 模式下，服务商通常以名义销售方的身份处理交易，并承担更多销售税、付款和退款事务。这样可以减少运营工作，但手续费通常更高，你对结账流程和客户关系的控制也可能更少。

2. 明确计费模型

选型前，先列出业务实际需要支持的计费方式：

• 每个公司固定收费
• 按用户席位收费
• 按供应商数量分档收费
• 按 API 调用量或存储量收费
• 基础订阅费加超额用量费
• 由销售团队协商的年度合同

如果业务只有固定月费，没有必要一开始就采用企业级 Billing 平台。但如果涉及合同变更、补差价、多实体结算或复杂的收入确认，简单的支付 API 很快就会难以维护。

3. 检查地区和财务要求

需要重点确认：

• 是否支持公司的注册地和目标市场
• 结算币种及外汇费用
• 是否支持信用卡、ACH、SEPA 或本地支付方式
• 是否能够采集企业税号
• VAT、GST、sales tax 的计算和申报范围
• 是否支持符合当地要求的发票或开票系统
• 退款、拒付和资金冻结规则
• 数据导出与迁移能力

不要只看每笔交易的手续费。订阅管理费、税务服务费、拒付费、货币转换费和退款成本都会影响总成本。

推荐的集成方式

Billing 平台管理支付状态，应用管理授权和功能访问。两者不能直接依赖前端返回结果来绑定状态，应以通过签名验证的 Webhook 作为同步依据。

典型流程如下：

1. 应用在本地建立 tenant 和 customer 的映射。
2. 后端通过 Billing Provider 创建 Checkout Session 或 Subscription。
3. 客户在托管页面完成付款。
4. Provider 发送 Webhook。
5. 后端验证签名，并根据事件 ID 进行幂等处理。
6. 应用在本地更新订阅状态和功能权限。
7. 定时任务执行对账，修复遗漏或长时间未处理的事件。

下面是一个简化的 Express Webhook 示例。具体事件名称和 SDK 调用方式应以 Provider 的当前文档为准：

import express from "express";

const app = express();

// 需要保留原始请求体，以便验证 Webhook 签名
app.post(
  "/webhooks/billing",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    let event;

    try {
      event = verifyWebhookSignature({
        rawBody: req.body,
        signature: req.headers["billing-signature"],
        secret: process.env.BILLING_WEBHOOK_SECRET
      });
    } catch {
      return res.status(400).send("Invalid signature");
    }

    const alreadyProcessed = await webhookEventExists(event.id);
    if (alreadyProcessed) {
      return res.sendStatus(200);
    }

    await database.transaction(async (tx) => {
      await saveWebhookEvent(tx, event.id, event.type);

      switch (event.type) {
        case "subscription.activated":
        case "subscription.updated":
          await updateSubscription(tx, {
            providerSubscriptionId: event.data.subscriptionId,
            status: event.data.status,
            planId: event.data.planId,
            currentPeriodEnd: event.data.currentPeriodEnd
          });
          break;

        case "subscription.cancelled":
          await markSubscriptionCancelled(
            tx,
            event.data.subscriptionId
          );
          break;

        case "invoice.payment_failed":
          await restrictAccountIfRequired(
            tx,
            event.data.customerId
          );
          break;
      }
    });

    return res.sendStatus(200);
  }
);

Webhook 处理逻辑必须允许事件重复投递和乱序到达。收到一次付款失败事件后，不要立即删除客户数据，也不能把浏览器跳转到”支付成功”页面视为最终的付款证明。

除 Billing 外还要关注的组件

多租户与权限模型

供应商管理 SaaS 通常需要严格隔离不同 tenant。所有业务记录都应关联 tenant_id，并由服务端强制执行隔离，不能只靠前端筛选。

权限至少应分为：

• Organization Owner
• Administrator
• Procurement Manager
• Reviewer
• Read-only User
• External Supplier

如果客户是中大型企业，还可能需要 SSO、SAML、SCIM、细粒度 RBAC 和审批流程。

身份认证和账户生命周期

系统需要完整处理注册、邮箱验证、密码重置、多因素认证、成员邀请、成员移除和账户关闭。企业客户通常还会关注域名验证、登录审计及会话管理。

数据安全与隐私

云平台提供安全能力，但不会自动保障应用安全。云服务通常采用 shared responsibility model。Provider 负责底层设施，应用方仍需负责代码、访问权限、密钥、网络配置和客户数据。

至少要落实以下措施：

• 全程使用 TLS
• 对敏感数据进行静态加密
• 将密钥存入 Secret Manager，而不是代码仓库
• 为数据库设置最小权限
• 记录管理操作审计日志
• 定期备份并进行恢复演练
• 执行漏洞扫描和依赖更新
• 对登录操作限速并检测异常行为
• 建立数据保留、导出和删除流程
• 明确隐私政策、服务条款和数据处理协议

Firewall 或 WAF 只能降低部分风险，无法替代安全设计、权限检查和代码审计。

基础设施与可靠性

使用云计算是合理的选择，但没有必要过早搭建复杂的 Kubernetes 集群。产品早期通常可以先使用托管数据库、对象存储、容器或 PaaS。

以下事项需要提前确定：

• 开发、测试和生产环境的隔离方式
• Infrastructure as Code
• 自动化部署和回滚
• 数据库迁移策略
• 日志、指标、Tracing 和告警
• 备份恢复目标，即 RPO 和 RTO
• 后台任务队列与失败重试
• 限流、超时和熔断
• 容量预算与云成本告警

Scalability 不只是增加服务器数量。数据库索引、租户数据分布、后台任务、缓存策略和第三方 API 限额，往往会更早成为瓶颈。

邮件和通知

邀请、付款提醒、续费通知及系统告警都需要可靠的邮件基础设施。系统还要处理模板、多语言、退信、投诉、退订，以及 SPF、DKIM、DMARC 等域名配置。

业务提醒应与 Billing Provider 的催收邮件协调，避免同一位客户收到重复或互相矛盾的信息。

供应商数据治理

产品用于管理供应商信息，因此还要重点考虑：

• 自定义字段和数据校验
• 重复供应商识别
• 批量导入、导出和字段映射
• 附件存储与访问控制
• 修改历史和审批记录
• 联系人信息的隐私保护
• 停用供应商，而不是直接删除
• 与 ERP、采购系统和会计软件集成
• 恶意文件扫描及上传大小限制

客户支持与运营

系统上线并不等于发布工作已经完成。还需要准备：

• Onboarding 流程和示例数据
• 帮助中心与 API 文档
• 客服渠道和问题升级机制
• 服务状态页面
• Incident Response 流程
• SLA 或服务可用性说明
• 套餐限制和超额处理规则
• 取消订阅、退款与数据导出流程

一个务实的上线组合

早期 B2B SaaS 可以从下面这套组合起步：

• 托管云运行环境
• 托管关系型数据库
• 对象存储
• 第三方身份认证或成熟的认证组件
• Stripe Billing、Paddle 或同类 Billing Provider
• 事务邮件服务
• 错误监控、日志和可用性告警
• 自动备份与恢复验证
• 基础 RBAC、审计日志和 tenant 隔离

初期应把套餐和计费规则控制在少数几种，避免产品尚未验证就引入复杂的价格引擎。Billing Provider 能省去大量重复开发，但应用仍需自行设计订阅状态、客户权限、数据隔离、安全责任和财务对账。

备注：内容仅供参考。