1. 先确认停在哪个状态转换
草稿发票不是一张银行卡付款失败的 open 发票。Stripe 将 draft 到 open 定义为定稿，将 open 到 paid 定义为付款；open 发票付款失败后仍为 open。没有定稿的发票不能收取付款。[3] 排查应从当前发票状态开始，而不是仅依据客户说还没有被扣款就启动付款重试。
建议先记录发票编号、当前状态、创建时间、自动收款设置和相关事件投递。如果发票已经 open，本文关于草稿延迟的分支就不是首要诊断方向；如果仍为 draft，要求客户换卡可能是在处理错误的流程阶段，还会增加不必要的客服往返。
2. 准确理解回调等待规则
启用自动收款时，Stripe 文档描述的是：所有监听 invoice.created 的 webhook 成功响应后，再等待一小时尝试付款。如果72小时内没有收到成功响应，则尝试定稿并发送发票；文档也指向可配置更长宽限期的设置。[3] 这不是所有发票从创建时刻开始一小时内都会扣款的保证。
同一文档说明，这一行为适用于账户上定义的全部端点，包括无法正常处理回调的 Connect 应用或第三方服务。[3] 因此应检查所有相关投递，而不是只看团队最近发布的服务。你自己的端点成功响应，并不等于所有监听端点都已确认接收。
3. 区分投递故障与主动保留草稿
修改设置之前，先确认自动收款是否开启，以及发票是否为了人工审核而被有意保留。Stripe 提供 Dashboard 和 finalize 接口进行手动定稿，并在定稿发生时发送 invoice.finalized。[3] 存在手动操作入口，不代表应该在查明草稿原因前直接执行它。
建议按职责分流：失败投递交给集成负责人，主动保留草稿交给账单负责人，状态记录不一致则联合排查。保留投递时间和响应信息。没有付款尝试证据时，不要直接告诉客户是银行卡拒付；draft 状态本身不能证明发生过银行卡尝试。
4. 修复投递但不要承诺立即扣款
文档描述正式环境对未正确响应的回调采用指数退避，最长重试三天；sandbox 则是在数小时内重试三次。在此期间，除非收到成功响应，否则不会尝试扣款，并会发送回调失败通知邮件。[3] 因此测试环境的等待时间不能直接作为正式环境重试节奏的实测替代。
建议的恢复顺序为检查失败记录、修复端点、确认成功响应，然后重新读取发票状态。对客户宜说明发票仍在等待账单处理，而不是承诺一个未经核实的扣款时刻。所引文档并未提供适用于所有宽限期、端点和账户设置组合的统一恢复时限。
5. 手动定稿前检查不可逆边界
定稿使发票可付款、确保发票编号存在、生成相关付款对象，并使部分属性不能再修改。Stripe 明确说明，大多数与金额和客户有关的信息在定稿后不能改变。[3] 因此人工介入前，应由账单负责人检查客户资料、行项目和目标金额，不要把 finalize 当作没有副作用的刷新按钮。
对于自动税务计算，Stripe 表示使用的是发票定稿时的税率，而不是最初创建草稿时的税率。[4] 如果延迟跨越税率变更日期，金额可能受到影响。本文不判断任何司法辖区的具体税务处理；必要时请税务负责人确认，也不要把草稿预览承诺为最终合规税额。
6. 分开验证账单状态与通知
官方流程把定稿和邮件发送区分开来。collection_method=send_invoice 默认会发送，但自动扣款、关闭自动收款或关闭 Email finalized invoices to customers 等设置存在例外。[3] 发票定稿不自动证明客户已收到邮件，邮件发送也不能证明付款完成。
建议结案记录至少包含当前发票状态、故障投递修复证据、所选账单动作和单独的客户通知检查。在安全测试数据中覆盖 invoice.created 端点失败、成功响应、主动保留草稿以及人工定稿。本文未测试真实 Stripe 账户，提供的是有来源的诊断路径，不是实测故障恢复时间。
来源与日期
以下为 Stripe 官方英文文档。未注明发布或更新日期；抓取核验日期为 2026-09-21，不把抓取日当成来源发布日期。本文为编辑研究，不代表 PayIn 产品能力、账户资格验证或法律意见。
- [3] Status transitions and finalization · 核验 2026-09-21；原文日期未注明。
- [4] Automatically collect tax on invoices · 核验 2026-09-21；原文日期未注明。