扣款失败之后：8 次重试不是保证，暂停也不等于取消

直接答案

订阅扣款失败（involuntary churn）不是「打开重试就完事」。它其实是三个互相独立的开关：

1. 重试：失败后还试不试、试几次、试多久、用哪张卡；
2. 通知：客户怎么知道卡失效了、点哪个链接去改；
3. 终态：重试耗尽后，订阅是取消、挂账、继续欠费，还是暂停。

三个开关的默认值都不是「对你最有利」的值，而是「对大多数账户最不容易出事」的值。比如重试的推荐默认是 8 次 / 2 周，但有些失败根本不会执行重试；邮件通知需要你手动开启；暂停听起来最温和，却有资格限制，而且暂停失败时系统会直接取消订阅。

本文以 Stripe Billing 的四份公开文档为例（2026-10-24 读取），把「系统实际会做什么」与「你需要自己决定什么」分开写。其他计费系统的字段名不同，但这三层结构可以直接搬过去核对。

一、先分清四种「根本不重试」

Stripe 在重试页开头就把边界写死了：

Stripe doesn’t retry payments if:

• No payment methods are available.
• The issuer returned a hard decline code.
• The payment card is India-issued.
• The Stripe Connect account has been disconnected.

这四条里，第一条和第三条最容易被忽略。

没有可用支付方式：客户删了卡、或者卡过期后系统里没有任何可扣的支付方式。此时重试策略配置得再漂亮，也没有东西可扣。它不是一个「重试问题」，而是一个「资料缺失问题」，应该走另一条通知与补录流程。

印度发行的卡：页面只写了不重试，没有解释原因，也没有给替代方案。本文不替它补原因；如果你有印度客户，这是需要单独确认的收款路径，而不是靠调重试次数解决。

Connect 账户断开：平台型业务里，子账户断开后重试不会发生。对一人公司来说，这意味着「重试失败」有时根本不是支付问题，而是账户状态问题。

硬拒付是第四条，也是最容易误读的一条。页面先列了一组硬拒付码，包括 incorrect_number、lost_card、pickup_card、stolen_card、revocation_of_authorization、authentication_required、highest_risk_level、transaction_not_allowed 等；随后写：

Retries continue to be scheduled, and attempt_count continues to increment, but retries only execute after detecting a new payment method. Unexecuted retries don’t create a new Charge.

这句话把「计划」和「执行」拆开了。表面上看，8 次重试还在日程上，attempt_count 也在涨；实际上，只要客户没换一张能用的卡，这些重试一次都不会真的去扣款，也不会产生 Charge。

对运营的直接影响有两个：

• 你不能拿 attempt_count 当「我们已经扣了他 8 次」的证据去和客户沟通——那只是排期计数；
• 你也不能把「最后一次尝试的日期」当成「最后一次真实的扣款机会」。真正的转折点是「检测到新支付方式」那一刻。

二、8 次 / 2 周是推荐默认，不是行业规则

重试页对 Smart Retries 的描述是：用模型选择「什么时候重试最可能成功」，信号包括同一支付方式在最近 N 小时内出现过的设备数，以及某些国家借记卡在本地时间凌晨 12:01 成功率略高这类时间因素。页面里的 N 就是字面上的占位符，没有给具体小时数。

策略本身只有两个参数：总时长与次数。可选时长是 1 周、2 周、3 周、1 个月、2 个月；页面给的推荐默认是：

The recommended default setting is 8 tries within 2 weeks.

注意它用的是「recommended default」，不是「best practice」，更不是「保证挽回」。页面没有公布任何挽回率数字，也没有说 8 次比 5 次多挽回多少。你能确定的只有：窗口越长、次数越多，系统尝试的机会越多；但每一次尝试是否执行，仍受上一节的四条边界约束。

如果你不用 Smart Retries，可以自定义规则，但有一条硬上限：

You can configure up to three retries, each with a specific number of days after the previous attempt.

也就是说，自定义最多 3 次；想要「8 次」这种密度，只能走 Smart Retries 的预设窗口。这不是优劣问题，而是两条不同的产品路径：一条把时间点交给模型，一条把时间点交给你。

重试会用哪张卡

顺序是固定的，页面列了四级：

1. 订阅上的默认支付方式（subscription.default_payment_method）；
2. 订阅上的默认支付来源（subscription.default_source）；
3. 客户上的默认支付方式（customer.invoice_settings.default_payment_method；客户配置型 Account 则是 configuration.customer.billing.default_payment_method）；
4. 遗留的客户默认支付来源（customer.default_source）。

这里有一个非常具体的坑，页面专门警告：

When you update payment methods after a failed payment attempt, update the field where the previous payment failed. For example, if a subscription has a default payment method, but you only update customer invoice settings default payment method, Stripe continues to retry on the subscription’s default payment method.

翻译成运营动作：客户在门户里换了卡，不代表重试会用上新卡。 如果失败发生在订阅级默认支付方式上，而新卡只写进了客户级默认，重试仍会盯着旧的那张。做自助更新页面时，必须确认写入的是「失败的那一层」，否则客户以为改好了，系统还在原地打转。

事件里的两个时间字段

重试期间用 invoice.payment_failed 接收失败与重试更新；attempt_count 表示已经尝试了多少次；next_payment_attempt 表示下一次收款尝试的日期。

但如果你用了 automations，页面给了一条很容易漏掉的差异：

For automations users, next_payment_attempt is no longer set in invoice payment failed webhooks but is set in invoice updated webhooks.

也就是说，同一份「下次什么时候扣」的数据，在不同产品配置下挂在不同的事件上。监控脚本如果只订阅 invoice.payment_failed，在 automations 账户里会读到一个空值——这不是扣款没排期，而是字段搬家了。

三、终态四选一：取消、挂账、继续欠费、暂停

重试耗尽后，订阅按你的设置进入四种状态之一。页面把它们写成一张表，我把它连同「之后还会不会继续开票」一起列出来：

终态	订阅状态	之后还会不会生成发票	适合什么情况
取消	canceled	不会	低价、低触达、服务边际成本近乎为零之外的大多数情况
挂账	unpaid	会，但停在草稿状态	想保留债权、但暂时不想继续提供服务
继续欠费	past_due	会，并按重试设置继续扣款	高客单、愿意等客户恢复支付方式
暂停	paused	不会，直到恢复	想保留客户关系、同时停止交付与开票

这张表的第三列是编辑补的，不是 Stripe 的原表。原文的对应句子分别是：

Mark the subscription as unpaid: The subscription changes to unpaid after the maximum number of days defined in the retry schedule. Invoices continue to be generated and stay in a draft state.

Leave the subscription past-due: The subscription remains past due after the maximum number of days defined in the retry schedule. Invoices continue to be generated and charge the customer based on retry settings.

Pause the subscription: If the subscription is eligible, it changes to paused. Stripe doesn’t generate new subscription invoices until the subscription resumes.

还有一条时间边界：

After the final payment attempt, Stripe makes no further payment attempts. Changing your subscription settings only affects future retries.

所以「终态」不是重试过程中的动态判断，而是重试结束那一刻的落点。中途改设置，只影响还没发生的重试，不会把已经结束的这轮重新拉起来。把它写进流程的意思是：终态要在开卖前定，不要在第一个客户失败的那天临时想。

四、暂停：保留关系，但停交付、停开票

暂停是四种终态里最像「人性化处理」的一种，也是限制最多的一种。页面开头就写明：

Payment-failure settings apply globally to your account, but only eligible subscriptions that use flexible billing mode can pause.

两个关键词：全局与flexible billing mode。前者意味着你不能只给「高价值客户」开暂停、给其他人取消——至少在这个设置层面不行；后者意味着如果你的订阅不是 flexible billing mode，暂停这个选项根本用不了。

什么时候暂停

可以选两个时点：

• 首次续费扣款失败后：只对续费发票生效，不适用于订阅的初始发票；
• 重试耗尽后：跑完整个重试计划，在最后一次失败后暂停。

页面还给了一条「两个都想要」的配置约束：如果开启了「首次续费失败就暂停」，最终失败动作必须设成取消或暂停。另外，如果失败的是「待定订阅更新」关联的发票，系统既不暂停也不取消，原订阅保持 active。

暂停失败会怎样

这是全文最该划线的一句：

When pause is the configured action and Stripe can’t pause the subscription after the first failed payment attempt, the subscription remains past due. If Stripe can’t pause it after the final failed payment attempt, Stripe cancels the subscription instead.

你选的是「暂停」，但系统没资格暂停时：第一次失败后先留在 past_due；最后一次失败后直接取消。也就是说，「暂停」不是「取消」的安全替代品——在不适用的账户上，它反而可能把客户推到取消。

暂停期间发生了什么

页面列得很细，运营上要记住五件事：

1. 订阅变成 paused；
2. 暂停时点的计量用量会被记成 pending invoice item；
3. 首次续费失败就暂停的，会按每个 item 当前周期的起始日到周期结束，生成一笔未使用时间的抵扣；重试耗尽后暂停的，不生成这笔抵扣；
4. 暂停当时不开发票，已产生的计费项留到下一张发票；导致暂停的那张发票保持 open；
5. 暂停后不再生成新的订阅发票；这张发票上再有失败尝试，也不会把订阅改成 past_due。

第 3 条是两种暂停时点的实质差异：同样是「暂停」，早停会给未使用时间抵扣，晚停不给。对按月预收的订阅，这会直接影响客户恢复时的账单金额，也会影响客服解释口径。

恢复：自动与手动

自动恢复的条件是「导致暂停的发票被支付，或被手动标记为 uncollectible」。如果系统因此创建了 resumption invoice，这张新发票也必须被支付或标记 uncollectible，订阅才会恢复。

页面还列了四种不会自动恢复的情况：

• 系统把导致暂停的发票自动标记为 uncollectible，而这就是最终失败动作；
• 客户的另一张发票被支付；
• 导致暂停的发票的某个修订版本被支付；
• 导致暂停的发票被作废（void）——此时只能手动恢复。

最后一条很容易踩：作废发票看起来像「这笔账不要了」，但系统不会因此把订阅恢复。要恢复，得手动点。

五、邮件：三件事要手动开，日志只留 60 天

失败扣款的邮件不是「系统默认就会发」。页面写的是条件句：

Enable Send emails when card payments fail in the revenue recovery settings page. When you enable this setting, Stripe automatically sends an email to your customer after each failed payment.

开启之后，每次失败都会发一封，邮件里带一个让客户更新支付方式的链接。链接可以指向 Stripe 托管的 Customer Portal，也可以指向你自己的订阅管理页。

但链接会失效。页面列了四个让托管页链接失效的条件：

• 距离试用结束邮件发出已过 30 天；
• 订阅状态变成 cancelled、incomplete、expired 或 unpaid；
• 试用已结束，且客户已经为这个订阅提供了支付方式；
• 订阅当前续费周期已过期。

这意味着「把链接放在一封三个月前的邮件里」不可靠。真正要保证的是：客户在当前周期内能拿到一个可用链接。对一人公司，最稳的做法是把「更新支付方式」的入口同时放在账单页、应用内提示和邮件里，而不是只靠一封失败通知。

另外三类邮件是独立开关，不要以为开了失败通知就都有了：

• 试用结束提醒：试用结束前 7 天发送；
• 续费提醒：只对 collection_method 为 charge_automatically 的订阅发送，send_invoice 不发；
• 卡到期提醒：默认支付方式或默认来源的卡到期前 1 个月发送。

最后是日志边界：

You can find logs for emails sent within the last 60 days in the Customers page. The logs are updated daily, and they don’t include emails from the current date.

60 天、按天更新、不含当天。换句话说，今天的发送记录今天查不到，60 天前的记录永远查不到。如果客服需要用「我们某月某日发过提醒」作为沟通依据，就得自己把日志导出留档，而不是需要时再回后台翻。

六、怎么衡量：四个指标与两个时间陷阱

Stripe 的 Revenue recovery analytics 给了四个核心指标，定义分别是：

• Failed payments：首次尝试就失败的订阅付款笔数（量）；
• Failure rate：首次尝试失败的订阅付款金额占比；
• Recovered payments：通过重试、邮件，以及你使用的其他方式成功挽回的付款量；
• Recovery rate：失败之后、通过任何方式成功挽回的订阅付款金额占比。

三个细节决定了这些数字能不能直接拿来做决策：

第一，统计范围不含试用后的首张发票。

Data in the revenue recovery overview represents recurring subscription payments only and excludes the first invoice payment following a trial.

试用转化时的首扣失败，不会进这套分母。所以「recovery rate 很高」不代表试用转化顺畅；那是另一个漏斗。

第二，当月和上月可能还在「挽回中」。

页面明确说，当前月与上个月很可能还有处于 in recovery 的付款，因为重试窗口还没结束；也正因为如此，这两个月的 recovery rate 可能出现暂时性下降。

You may see a temporary drop in your recovery rate for the current and previous month if not all automatic retries have been attempted yet.

所以「这个月挽回率掉了，赶紧改策略」多半是误判。正确的观察窗口是：等这批失败的重试窗口走完，再看同批次的最终落点。用「按失败月份分组、等窗口结束后回填」的口径，比看 dashboard 的当月实时值可靠。

第三，recovery rate 的分子包含「其他方式」。

页面把 recovered 拆成三类：Retries、Emails、Other。Other 包括通过 API 或 Dashboard 手动发起的扣款尝试、第三方邮件活动、应用内流程、其他重试算法等。

这对一人公司的实际含义是：你不能把 recovery rate 全部记在「重试策略」的功劳上。 如果你同时在发人工催收邮件、在应用内弹窗提醒，这些都会被算进 Other。要判断「8 次 / 2 周」这个设置到底有没有用，得看 by method 的拆分，而不是看一个总数。

页面还给了一张「Top customers in recovery」表：最近失败、仍在重试中的客户，附带失败金额与客户时长。它的用途不是自动催收，而是让你判断「哪些客户值得人工介入」。对一人公司，这张表比任何自动化规则都更接近现实：金额大、合作久的客户，值得一封人工邮件；金额小、刚注册的客户，交给系统跑完即可。

七、一张可以照抄的时间表

把上面的规则压成一条时间线，大概是下面这样。「第 0 天」指首次扣款失败当天；具体第几天重试由系统策略决定，页面没有公布逐次间隔，所以表里不写「第 3 天」「第 7 天」这类未经证实的节点。

时点	系统会做什么	你该做什么	判断依据
第 0 天：首次失败	记录失败、触发 invoice.payment_failed；若已开启，发失败邮件	确认失败码是不是硬拒付；确认客户有没有可用支付方式	硬拒付 / 无支付方式 → 重试不会真正执行
重试窗口内（默认 2 周）	按策略排期重试；更新 attempt_count 与 next_payment_attempt	监控「排期」与「实际执行」的差异；客户换卡后确认写入的是失败的那一层	硬拒付下只有检测到新支付方式才执行
最后一次失败后	停止重试，按设置进入终态	核对终态是否符合预期；暂停失败时确认是否被取消	canceled / unpaid / past_due / paused
终态之后	按终态决定是否继续开票	对高价值客户人工介入；对低价值客户停止投入	发票是否继续生成、服务是否继续交付
次月复盘	更新 recovery analytics	按失败月份分组，等窗口结束再算最终挽回率	当月/上月可能仍在 in recovery

表里最值得单独盯的是第二行。大多数「重试没用」的抱怨，根源不是次数不够，而是失败落在硬拒付、无支付方式、印度卡或 Connect 断开这四类里——系统从头到尾就没真正扣过。

八、五种常见误读

「设了 8 次，就会扣 8 次。」 不会。硬拒付下重试只是排期，attempt_count 会涨，但不产生 Charge；无支付方式、印度卡、Connect 断开则根本不重试。

「失败邮件会自动发。」 不会。要先开启「Send emails when card payments fail」。而且日志只保留 60 天、不含当天，历史沟通记录要自己留。

「暂停比取消温和，先选暂停总没错。」 暂停只对 flexible billing mode 的合格订阅生效。首次失败后暂停失败，订阅留在 past_due；最后一次失败后暂停失败，系统直接取消。选暂停之前，先确认你的订阅类型。

「客户更新了卡，重试就会用新卡。」 只有在更新的是「失败的那一层」时才成立。订阅级默认支付方式失败、却只改了客户级默认，重试仍会用旧卡。

「这个月挽回率掉了，说明策略变差了。」 当月与上月可能还有大量 in recovery 的付款，recovery rate 会暂时性下降。等重试窗口结束再判断。

还有一句不属于「误读」但必须写清楚：更新支付方式不保证扣款成功。 页面只说重试会使用新的支付方式，最终是否成功仍由发卡行决定。任何「换卡必过」的承诺都没有公开依据。

九、这周能做的五件事

1. 拉一份最近的失败清单，按失败码分组。 先看硬拒付、无支付方式、印度卡、Connect 断开各占多少。如果前三类占了大头，调重试次数是无效动作。
2. 把重试窗口与终态写成一张内部表。 明确写清：默认 2 周 / 8 次；自定义最多 3 次；终态是取消、挂账、继续欠费还是暂停；暂停是否适用于你的 billing mode。
3. 检查失败邮件是否真的开着。 然后用一个测试客户走一遍：邮件是否到达、链接落到哪个页面、链接在周期过期后是否失效。
4. 建一张 dunning 事件表。 至少包含：发票 ID、失败码、attempt_count、next_payment_attempt、是否真的执行、邮件发送时间、终态、恢复时间。没有「是否真的执行」这一列，你会把排期当成扣款。
5. 把挽回率的统计口径固定下来。 按失败月份分组、等重试窗口结束后回填；同时看 by method 的拆分，别把人工催收的功劳算进重试策略。

一句话收尾：失败扣款的处理质量，不取决于你把重试次数调到了多少，而取决于你是否知道哪些失败根本不会重试、以及重试结束后客户会落到哪个状态。