1. 把排程、执行与成功分开
重试计数增加，很容易被理解为又向客户扣了一次款。但Stripe说明：发生hard decline（硬拒绝）后，重试仍会被安排，attempt_count仍会增加，只有检测到新的付款方式后才会执行；未执行的重试不会创建新的Charge。[1]
编辑建议：把计划重试、实际执行、成功收款作为三个独立状态。未来时间戳只是计划，计数增加本身不能证明产生了新扣款。客服应按已掌握的证据说明进展，不能把每次重试状态更新都写成再次扣款，也不应据此判断客户重复支付。编辑建议：内部记录应能分别回答何时计划再试、是否实际执行、是否取得收款结果，避免将三个问题压缩成一个含糊的“已重试”。
2. 先识别硬拒绝的执行门槛
原文列出的硬拒绝代码包括incorrect_number、lost_card、pickup_card、stolen_card、revocation_of_authorization、revocation_of_all_authorizations、authentication_required、highest_risk_level和transaction_not_allowed；这些失败需要取得新的付款方式后才能执行自动重试。[1]
编辑建议：保留完整错误码，并安排更换付款方式的跟进，而不是仅缩短重试间隔。新增付款方式也不等于付款成功：原文给出的是执行前提，不是新卡必定被接受的保证。在付款证据改变前，账单仍应保留为待解决事项。编辑建议：跟进人员应明确下一步是在等待替代方式，还是在核对执行结果；不要因为计数继续变化就取消需要人工处理的任务。
3. 修正真正生效的那个字段
Stripe依次选择首个可用项：subscription.default_payment_method、subscription.default_source、客户默认付款方式，以及旧版customer.default_source。第三项对Customer对象是customer.invoice_settings.default_payment_method，对配置为客户的Account对象则是configuration.customer.billing.default_payment_method。[1]
原文特别提醒：订阅已有default_payment_method时，只更新客户的invoice_settings.default_payment_method，重试仍会使用订阅层的默认付款方式；应更新此前付款失败所使用的字段。[1]
编辑建议：修改前先记录实际命中的层级，逐项检查更高优先级字段。不要默认新保存的客户默认卡会覆盖订阅配置。字段更新成功与重试目标修正成功，是两项不同的验收条件。编辑建议：交接时写明修改对象和字段，不能只写“已换卡”；否则接手人员无法判断修复是否触及真正控制重试选择的配置。
4. 虚构演练：新卡保存到了错误层级
以下是虚构的离线操作演练，并非真实客户事件。订阅指向付款方式A，账单返回lost_card。客服把替代方式B只保存为客户账单默认方式。后续模拟数据中attempt_count增加，却没有新增Charge。处理人员最初把工单写成“已使用新卡重试”。
这个结论与两条原文规则冲突：硬拒绝后的排程可以推进而不执行，订阅默认方式也仍优先于客户默认方式。[1] 编辑建议：更正工单措辞，把订阅层字段列为修复目标，并仅在模拟数据中将其改为B。不要触发线上扣款，更不能把模拟配置修复写成已收到款项。编辑建议：保留修复前后的模拟快照，用来说明此前为何仍选中旧方式，以及修复后为何选中替代方式，而非只展示编辑成功。
5. 按字段与证据执行操作清单
编辑操作清单：确认账单、订阅、客户或客户配置账户；保留失败代码；检查四个优先层级；记录原选中方式与拟替代方式；通过获准流程更新对应字段；最后核对更新后的实际选择。这些标识应保存在有访问控制的操作记录中，不应直接放进公开工单说明。
Stripe使用invoice.payment_failed提供付款失败和重试更新；启用automations时，next_payment_attempt设置在invoice.updated中，而非invoice.payment_failed中。[1] 编辑建议：将事件类型与时间戳一起记录，不要把某个事件里缺少字段，直接认定为系统没有后续重试计划。编辑建议：复核记录应注明观察来自哪一类事件；证据不足时写“尚未确认”，而不是补写一个想当然的重试时间。
6. 明确这套排查的适用边界
Stripe还列出没有可用付款方式、印度发行的银行卡、Connect账户已断开连接等不进行重试的情况。本地付款方式有单独的重试设置，默认也不会自动重试。[1]
编辑建议：遇到这些情况应分流检查，不要把所有失败都归因于默认方式层级错误。本文不是跨支付服务商的通用规则，也不提供法律授权结论，更不声称PayIn实现了Stripe重试功能。演练仅使用离线数据；生产修复须另有获准流程与结果证据。更换方式或调整排程都不保证追回欠款。编辑建议：把此次验收限定为排查逻辑与配置选择是否正确，不把离线测试通过扩展成线上付款通道可用或收款成功的证明。
7. 用相互匹配的证据验收
编辑验收标准：模拟计数增加时不得凭空生成Charge；只更新客户层后，仍须选中订阅方式；修正订阅字段后，模拟选中方式才应改变。另设automations场景，从invoice.updated读取排程信息。没有实际付款证据就标记收款结果未核实；本次离线演练不会产生这类证据。编辑建议：验收结论应逐项列出通过的检查和仍待确认的结果，让运营与客服知道配置问题已经修正，但实际收款状态并未由演练证实。
来源与日期
以下为 Stripe 官方英文文档。未注明发布或更新日期；抓取核验日期为 2026-09-21，不把抓取日当成来源发布日期。本文为编辑研究，不代表 PayIn 产品能力、账户资格验证或法律意见。
- [1] Automate payment retries · 核验 2026-09-21；原文日期未注明。