Stripe 账单扣款失败后，怎样区分重试与已付款
先给结论：扣款失败后，Stripe 的 Smart Retries 只是“重试安排”，不是付款结果。判断一张账单到底还处在重试中、还是已经付清，应看这张发票（invoice）的状态，以及发票上记录的重试时间；不要用“已经过了多久”“大概还会扣几次”来推断。状态仍然是未支付、且存在后续重试时间，通常说明系统还会继续尝试——除非命中下面列出的不重试条件。状态已变为已支付，就说明这笔钱已经收到，不再需要重试。两者是两个不同层面的事实，不能混为一谈。
先分清两个层面
第一层是机制。Stripe Billing 可以自动对失败的订阅付款和一次性发票付款发起重试，以减少非自愿流失。Smart Retries 用模型选择重试的时间点，它安排的是“什么时候再试”，并不承诺最终一定能扣款成功。所以看到“有重试安排”，不等于“这笔账会付上”。
第二层是结果。一次扣款是否成功，体现在发票本身的状态上。重试是过程，付款是结果。核对时先看发票状态，再看重试时间，顺序不要颠倒。
可执行的核对动作
- 打开这张发票，看状态。 如果状态显示已支付，说明款项已收到，后续不会再因这笔账单重试；如果仍是未支付或待处理，说明还没付成，需要继续关注。
- 在同一张发票上找重试时间。 有明确的下一次重试时间，说明系统还排在队列里；没有后续时间时，需结合发票状态和不重试条件判断，不能仅凭时间假设仍会重试。
- 确认这张账单是否属于“不会重试”的情形。 Stripe 明确不重试的情况包括：没有可用的支付方式；发卡行返回硬拒付代码（hard decline）；卡由印度发行；Stripe Connect 账户已断开。命中任一条，等待重试就是空等。
- 失败后改过支付方式，要改对字段。 重试时 Stripe 按固定优先级取第一个可用的支付方式：订阅默认支付方式（
subscription.default_payment_method）、订阅默认支付来源（subscription.default_source）、客户默认支付方式（customer.invoice_settings.default_payment_method，或客户自行配置账户对象时的configuration.customer.billing.default_payment_method）、旧版客户默认支付来源（customer.default_source）。如果订阅有默认支付方式，而你只更新了客户层级的默认支付方式，Stripe 仍会按订阅的默认支付方式重试。改哪里失败，就改哪个字段。
一个可复算的假设例子
以下为假设场景，仅用于说明“看状态、看时间”的核对顺序；天数为示意，不代表 Stripe 的默认重试间隔或任何统一频率。
假设一笔订阅月费 100 元，首次扣款失败。
- 第 1 天：发票状态为未支付，页面显示下一次重试时间。此时是“重试中”，钱没到账。
- 第 5 天：你再次查看，发票状态仍是未支付，重试时间已更新为更晚的日期。仍是“重试中”，不能记作收入。
- 第 9 天：发票状态变为已支付。此时是“已付款”，这笔 100 元才计入已收，后续不再为这张发票重试。
反过来，如果第 1 天就发现没有可用支付方式，或者发卡行给的是硬拒付，那么无论过多少天，状态都不会自己变成已支付——这时该做的是补支付方式或联系客户，而不是等重试。
常见误判
把“设置了 Smart Retries”当成“会自动付上”，是最典型的混淆。Smart Retries 只决定重试时机，最终成败仍取决于发卡行和支付方式是否可用。另一个误判是看到发票金额没变就以为没处理过——重试本身不改变发票的应付金额，只会在发票上留下新的尝试记录和下一次时间。还有一种是把“已付款”和“重试结束”等同：重试可能因硬拒付等原因提前停止，而账单依然未付，这时状态仍是未支付，只是不会再自动重试。
因此，区分重试与已付款，只需守住一条：以发票状态定结果，以重试时间定是否还在排队，以不重试条件排除空等。 三者对上，就不会把“还会再试”误读成“已经付了”。