# 2026 年 SaaS 创始人经常性付款完整指南

> SaaS 创始人需要了解的经常性付款知识：从支付方式和重试逻辑，到计费模式与合规要求。
- **Author**: Ayush Agarwal
- **Published**: 2026-04-04
- **Category**: Payments, SaaS, Billing
- **URL**: https://dodopayments.com/blogs/zh/recurring-payments-guide

---

经常性付款是订阅型企业的支柱。做好了，你就能获得可预测、不断增长的收入；做错了，你会因为扣款失败、用户困惑，以及你甚至不知道存在的合规漏洞，在不知不觉中大量流失客户。

本指南涵盖 SaaS 创始人需要了解的一切：经常性付款在技术层面如何运作、哪些支付方式真正支持经常性付款、重试逻辑和催收机制如何保护你的收入，以及 2026 年的合规要求是什么。

## 什么是经常性付款？

经常性付款是指在固定或可变的时间间隔自动扣款，客户无需每次重新输入支付信息。客户只需授权一次扣款，商户便会存储支付凭证（或代表这些凭证的令牌），以便发起后续扣款。

其核心机制包括三部分：

- **首次授权**：客户提供支付信息，并明确同意未来的扣款
- **凭证存储**：支付信息会被安全存储，通常由支付处理商转换为网络令牌
- **商户发起交易（MIT）**：后续由商户触发、无需客户实时参与的扣款

这与客户每次返回商店后重新付款有本质区别。发起交易的责任转移到了商户身上，这既带来了机会（自动化、可预测性），也带来了责任（合规和客户信任）。

## 经常性付款在技术层面如何运作

了解技术流程有助于你构建更具韧性的计费系统，并更快地排查故障。

```mermaid
sequenceDiagram
    participant C as Customer
    participant M as Merchant / SaaS App
    participant G as Payment Gateway
    participant N as Card Network
    participant I as Issuing Bank

    C->>M: Enter card details + accept terms
    M->>G: Tokenize card credentials
    G->>N: Request network token
    N-->>G: Network token issued
    G-->>M: Return token + setup confirmation

    Note over M: Billing date arrives

    M->>G: Initiate MIT with stored token
    G->>N: Route transaction
    N->>I: Authorization request (flagged as recurring)
    I-->>N: Auth response (approve / decline)
    N-->>G: Auth result
    G-->>M: Webhook: payment.succeeded or payment.failed
    M->>C: Receipt or failure notification
```

这个流程中有几点值得注意：

- 卡组织会签发一个替代原始卡号的**网络令牌**。当客户更换新卡时，发卡行可以自动更新网络令牌，这意味着即使实体卡被更换，你存储的凭证仍然有效。
- MIT 交易会在授权请求中携带特定标记，以便发卡行应用正确的规则（不会触发 3DS 验证，但对异常金额的审查会更加严格）。
- 你的系统通过[webhook](https://docs.dodopayments.com/developer-resources/webhooks)获知交易结果，而不是通过轮询。对于生产环境中的计费系统而言，构建可靠的 webhook 处理机制是不可妥协的要求。

> 我见过 SaaS 团队在经常性计费方面犯的最大错误，就是把 webhook 处理当成事后再考虑的问题。你的重试逻辑、催收邮件和访问控制都依赖于可靠且幂等地处理支付事件----如果这里出错，你可能会在数月内悄无声息地流失收入。
>
> - Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO

## 支持经常性付款的支付方式

并非所有支付方式都支持商户发起的经常性扣款。下面介绍哪些方式可行，以及它们的运作方式。

### 信用卡和借记卡

银行卡（Visa、Mastercard、Amex）是全球经常性计费中使用最广泛的方式。其支付网络成熟，网络令牌化普及度高，重试逻辑也经过充分验证。

银行卡支持三种经常性交易：

- **固定金额经常性付款**：金额和间隔都相同（经典订阅模式）
- **可变金额经常性付款**：每个周期的金额会变化（按用量计费、计量型套餐）
- **分期付款**：将一次性购买金额分成固定次数的扣款，分期完成支付

在北美和西欧以外，银行卡的覆盖率会明显下降。如果你计划拓展全球市场，值得提前考虑这一点。你可以查看[适合 SaaS 的最佳支付方式](https://dodopayments.com/blogs/best-payment-methods-for-saas)，了解各地区的完整对比。

### ACH（美国银行转账）

ACH 扣款允许你直接从美国客户的银行账户中扣取资金。其成本低于银行卡（通常收取固定费用，而不是按比例收费），而且由于银行账户很少会意外关闭，因此几乎不存在卡片过期问题。

需要权衡的是：ACH 结算通常会延迟 2-3 个工作日；如果在客户预期之前扣款，退回率可能会较高。ACH 授权记录必须至少保存两年。Nacha 规则还要求授权协议使用特定措辞。

对于银行卡费用会显著增加的高客单价 B2B 订阅，ACH 非常适合。

### SEPA 直接借记（欧洲）

SEPA 直接借记覆盖欧元区及其他几个欧洲国家。与 ACH 一样，它会直接从银行账户扣款，费用低于银行卡。

SEPA 授权有严格要求：唯一的授权参考号、特定的预先通知期限（首次扣款前至少 14 个自然日，除非你与客户约定更短的通知期限），以及明确的争议期限，在此期间客户可以申请追回资金。

对于拥有欧洲客户的 SaaS 公司，除了银行卡之外，也值得支持 SEPA。它在德国和荷兰尤其重要，因为这两个市场的在线支付银行卡渗透率较低。

### UPI Autopay（印度）

印度的 UPI Autopay 通过统一支付接口，直接从银行账户发起经常性扣款。对于印度客户的经常性计费，这是正确的处理方式。自印度储备银行实施额外身份验证要求、导致银行卡经常性扣款变得更加困难后，UPI Autopay 的采用率大幅提升。

[UPI autopay](https://dodopayments.com/blogs/upi-autopay)支持固定和可变金额的经常性授权。对于可变金额，在每次扣款金额超过基础金额前，都必须通知客户。可变金额的通知窗口为 24 小时。

对于在印度拥有可观收入的 SaaS 公司来说，UPI Autopay 并非可有可无。由于印度储备银行要求额外的身份验证因素，基于银行卡的经常性付款体验存在明显阻力。

> 当我们与计划拓展印度、巴西或东南亚市场的 SaaS 创始人交流时，最大的收入阻碍通常不是产品市场匹配，而是支付方式覆盖。如果你的计费技术栈只支持银行卡，那么对于全球市场中大量使用其他支付方式的用户来说，你就等于不存在。
>
> - Rishabh Goel，Dodo Payments 联合创始人兼 CEO

### 直接借记（英国、澳大利亚及其他地区）

英国的 Bacs Direct Debit 和澳大利亚的 BECS 与 SEPA 遵循类似模式：通过银行账户之间的扣款完成支付，并要求提供授权记录，同时设有争议期限。它们在各自市场的订阅型企业中都很受欢迎，拓展特定地区时应将其纳入考虑。

直接借记也是最能体现"自行构建还是购买现成方案"这一取舍的领域，因为每个支付计划都有自己的授权格式、提交时间表和退回代码体系。如果你正在权衡专用银行扣款服务商，还是同时处理银行卡和银行支付网络的支付处理商，可以参考 [GoCardless alternatives](https://dodopayments.com/blogs/gocardless-alternatives) 对 ACH、SEPA 和 Bacs 之间取舍的详细比较。

## 经常性收入的计费模式

如何设计经常性收费模式，与如何收取费用同样重要。不同模式适合不同产品。更深入的对比请参阅[订阅定价模式](https://dodopayments.com/blogs/subscription-pricing-models)。

### 固定费率（固定订阅）

一个价格、一组功能、每个计费周期收取一次。它易于理解、构建和沟通。其局限在于：无法充分从高频用户身上获得收入，也会让低频用户觉得自己支付过多。

适用于：客户使用量相对均匀的通用型 SaaS 工具，以及会员或门控内容业务。在这些业务中，经常性收费购买的是访问权限，而不是实际消费。如果这是你的模式，可以参考 [Memberstack alternatives](https://dodopayments.com/blogs/memberstack-alternatives) 汇总，了解将会员访问控制与本文所述经常性计费结合的平台。

### 分层定价

提供多个套餐，功能或使用限额逐级增加。客户根据自身需求选择套餐，并在升级时带来收入增长。

分层定价需要仔细设计阈值。层级之间差距太小，会让升级变得困惑；差距太大，则会形成价格断层，导致需求中等的客户支付过多。

### 按用量计费

客户为实际使用量付费，例如 API 调用次数、活跃席位数、处理的数据量和发送的消息数。收入会随着客户成功自然增长，双方激励也能更好地保持一致。

这种模式会显著增加计费复杂度。你需要计量基础设施来准确追踪用量，计费周期也必须处理可变金额，而不是固定扣款。[按用量计费](https://dodopayments.com/blogs/usage-based-billing-saas)有一套值得单独研究的工程和产品考量。

### 混合模式

大多数成熟的 SaaS 企业最终都会结合多种模式：基础平台费用加超额用量费用，或按席位收费并附带用量额度。混合模式可以针对不同客户群优化收入，同时让客户的基础成本保持可预测。

随着模式复杂度增加，[计费自动化](https://dodopayments.com/blogs/billing-automation-saas)会变得越来越重要。手动追踪混合收费容易出错，也无法规模化。

## 重试逻辑与催收

经常性付款失败并不意味着一切结束。你如何处理这次失败，将决定你能挽回多少收入，以及有多少收入会变成[非自愿流失](https://dodopayments.com/blogs/involuntary-churn-failed-payments)。

### 支付为什么会失败

银行卡支付失败分为两类：

**硬拒付**：发卡行明确拒绝交易。例如银行卡被报告为失窃、账户已关闭或卡号无效。重试硬拒付不会奏效，还可能触发对商户账户的风控标记。

**软拒付**：资金不足、达到银行卡交易频率限制或临时预授权等暂时性失败。这类交易值得重试，因为根本原因可能会自行消除。

卡组织返回的拒付代码会告诉你遇到的是哪一类。支付处理商会以标准化响应代码的形式提供这些信息，而将每个代码映射到"重试"或"不重试"的决定，是提升收入恢复率最有效的措施。我们关于[信用卡拒付代码](https://dodopayments.com/blogs/credit-card-decline-codes)的参考资料详细说明了哪些代码适合重试。用同一种方式处理所有拒付，会在硬拒付上浪费重试机会，也会错过软拒付的收入恢复机会。

### 智能重试策略

简单的重试策略会按固定间隔重试：第 1 天、第 3 天、第 7 天。智能重试策略会考虑以下因素：

- **拒付代码**：只重试软拒付
- **时间段**：在某些时间，银行的风控模型不那么激进，授权率会更高
- **星期几**：工作日中段的授权率通常高于周末
- **客户通常的付款规律**：如果客户通常在发薪日成功付款，就在该时间附近重试

重试窗口通常持续 7-14 天，之后订阅会被标记为需要评估是否取消。

### 催收沟通

在进行重试的同时，你的[催收管理](https://dodopayments.com/blogs/dunning-management)系统会与客户沟通：

- **预催收**：在客户银行卡过期前提醒客户（从已存储的支付凭证中可以看到卡片有效期）
- **支付失败通知**：首次失败后立即通知客户，并提供直接更新支付信息的链接
- **后续提醒序列**：间隔发送提醒，逐步提高紧迫感，但避免显得咄咄逼人
- **最终通知**：取消订阅前，明确给客户一次挽救订阅的机会

语气很重要。即使失败原因只是银行卡过期，带有指责意味的催收邮件也会损害客户关系。保持沟通客观，并让更新支付信息尽可能顺畅。

催收的目标是以最少的客户操作解决支付问题，而不是让客户感到羞愧后被迫付款。能够顺利更新银行卡的客户会继续留下；即使付款成功，如果客户觉得自己一直被催促，也可能选择取消。

## PCI DSS 合规

PCI DSS（支付卡行业数据安全标准）规定了你应如何处理持卡人数据。对于大多数 SaaS 公司，正确做法是完全不接触原始银行卡数据。

如果你使用支付处理商提供的托管支付字段或 SDK，银行卡数据会直接从客户的浏览器流向支付处理商。你的服务器永远不会看到原始卡号。这样可以让你处于 PCI 合规要求最低的等级（SAQ-A），只需每年进行自我评估，而不必接受完整审计。

需要注意的是，SAQ-A 不再只是走文书流程。根据 PCI DSS v4.0，自 2025 年 3 月 31 日起强制执行的未来要求将 SAQ-A 扩展到了支付页面本身：你现在需要管理并授权加载在包含支付字段页面上的每个脚本，并检测该页面 HTTP 标头和脚本内容的未经授权更改。实际上，这意味着即使银行卡字段是你无法控制的嵌入式 iframe，你仍需要维护结账页面上的第三方脚本清单并对其进行监控。

在经常性计费设置中维持 PCI 合规的关键实践包括：

- 任何地方都不要记录原始卡号、CVV 或完整磁条数据
- 使用网络令牌或支付处理商签发的令牌存储支付凭证，而不是原始 PAN
- 仔细界定 PCI 评估范围：只有接触或可能接触持卡人数据的系统才属于范围之内
- 每年对范围内系统进行渗透测试
- 清晰记录数据流

[Dodo Payments](https://dodopayments.com)在基础设施层面处理 PCI 合规，这意味着你无需自行构建合规能力，就可以继承相应的合规状态。

## 经常性付款的强客户身份验证与 3DS

欧洲 PSD2 下的 SCA（强客户身份验证）要求银行卡支付进行双因素身份验证。这与经常性计费之间存在冲突：你不可能在每次自动扣款时都要求客户完成双因素验证。

实际运作方式如下：

- 经常性付款序列中的**首次交易**必须完成完整的[3D Secure](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication)验证，由客户完成双因素验证挑战
- 客户完成一次身份验证后，即可为后续 MIT 扣款豁免商户的重复验证
- 如果风控模型标记后续 MIT 交易，发卡行仍可能要求升级至 SCA，但这属于例外情况，而不是常规做法

对于使用 SCA 设置的经常性付款，你需要在授权请求中传递正确的 MIT 标记和豁免指标。如果配置错误，就会导致不必要的 3DS 验证提示，降低转化率；或者导致交易因不符合 SCA 要求而被拒绝。

在欧洲以外，3DS 对经常性付款不是强制要求，但在发卡行更信任经过验证的支付凭证的市场，它可能提高授权率。正确方案取决于你的客户所在地区，以及授权数据反映出的情况。

## 设置经常性付款

如果你要从头构建订阅计费，以下步骤最为重要：

**1. 选择支付基础设施**

你需要一个支持以下能力的支付处理商：网络令牌化、MIT 交易类型、基于 webhook 的结果通知，以及面向目标市场的本地支付方式。[订阅管理](https://docs.dodopayments.com/features/subscription)文档是了解 API 需要处理哪些内容的良好起点。

**2. 设计授权流程**

首次结账必须收集正确的授权措辞。客户需要明确同意未来扣款、计费间隔，以及在扣款前接收通知的方式。这些措辞不仅是用户体验的一部分：它们是 ACH、SEPA 和 UPI 授权的法律要求，也是应对银行卡拒付的重要防线。

**3. 在上线前构建 webhook 处理机制**

支付结果通过 webhook 到达，而不是通过同步 API 响应返回。你的 webhook 处理程序需要验证签名，以幂等方式处理事件（同一事件可能会多次到达），并触发正确的后续操作（开通访问权限、发送收据、失败时进入催收队列）。

**4. 实现重试和催收逻辑**

根据拒付代码类别确定重试计划、催收沟通序列和取消阈值。这些设置应该无需部署代码即可调整。

**5. 明确测试失败场景**

大多数测试套件都会覆盖成功路径。但对于计费而言，失败路径才是收入所在。上线前测试硬拒付、软拒付、部分重试、催收序列和银行卡更新流程。

如果从头构建这些功能听起来过于复杂，或者你正在拓展新市场并需要本地支付方式支持，那么值得了解作为托管式替代方案的 [Dodo Payments pricing](https://dodopayments.com/pricing)。

## 经常性付款的替代方案与补充方式

经常性计费并不总是正确的模式。有些客户更喜欢每年预付，有些商业模式更适合开具发票，还有一些市场拥有更匹配的支付机制。

[经常性计费替代方案](https://dodopayments.com/blogs/recurring-billing-alternatives)介绍了纯经常性模式会产生摩擦、而其他方式能够解决这些问题的场景。

## 常见问题

### 订阅和经常性付款有什么区别？

订阅是一种商业模式：客户通过定期付款持续获得产品或服务的使用权。经常性付款则是自动收取这些款项的技术机制。并非所有经常性付款都是订阅：分期付款和自动充值也是经常性付款，但从传统定义上看并不属于订阅。

### 客户的银行卡过期时，如何处理经常性付款？

有两种机制可以提供帮助。第一种是网络令牌化：当银行卡因有效期正常到期而重新签发新卡时（这种情况很常见），卡组织会自动更新令牌，你存储的凭证无需任何操作即可继续有效。第二种是[账户更新服务](https://dodopayments.com/blogs/account-updater-service)：对于不支持网络令牌自动更新的银行卡，许多支付处理商会提供账户更新服务，定期向卡组织查询最新的银行卡信息。如果这两种机制都未能及时捕获更新，你的催收系统应从存储的卡片数据中检测有效期，并在下一个计费日之前提示客户更新。

### 每次经常性扣款都需要 3DS 验证吗？

不需要。在欧洲 PSD2 规则下，经常性付款序列中的首次交易需要 SCA（通常通过 3DS 完成）。只要初始身份验证设置正确，并在后续每次扣款中传递正确的豁免标记，后续由商户发起的交易即可豁免 SCA。在欧洲以外，经常性交易中的 3DS 是可选的。一些商户会根据发卡行反馈或风险信号选择性地启用 3DS。

### 失败的经常性付款采用什么重试计划最好？

不存在适用于所有情况的最佳计划，但一个实用的起点是：仅针对软拒付，在第 1 天（失败当天，尽可能选择不同时间）、第 3 天、第 7 天和第 14 天进行重试。硬拒付不应重试。更复杂的系统会利用机器学习，根据拒付代码、客户历史和发卡行模式预测最佳重试时间。首次失败后，通常在 2-5 天内启动催收沟通；如果扣款仍无法恢复，则在 14-21 天后评估是否取消。

### ACH、SEPA 和 UPI Autopay 的经常性付款有何不同？

三者都是银行间的经常性扣款机制，但具体细节存在显著差异。ACH（美国）的结算延迟为 2-3 天，除了授权条款中的要求外，没有额外的预先通知要求，退回通常在 5 个工作日内处理。SEPA（欧洲）要求在首次扣款前提前 14 天通知（经双方约定可缩短），使用标准化授权参考号，客户还可以在最长 13 个月内追回未经授权的扣款。UPI Autopay（印度）支持固定和可变金额授权；对于超过基础金额的可变扣款，需要在扣款前 24 小时通知客户，且结算几乎即时完成。每种方式都有自己的授权存储和争议解决要求，你的计费系统必须将其纳入考量。
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)