支付智能重试：在不制造新风险的前提下挽回交易

支付智能重试不等于简单地“再试一次”。它需要综合判断失败类别、支付状态、客户上下文、渠道规则，以及改变条件后是否真的可能成功。

设计合理的重试可以挽回临时性失败；设计不当则会产生重复扣款、不必要费用、更长的支付流程和更多发卡行拒绝。

重试之前先对结果分类

渠道响应通常可以分为四类：

类别	示例	默认动作
成功	已授权、已请款、已完成	不得重试，继续推进订单生命周期。
硬拒绝	账户无效、卡片关闭、交易类型不支持	没有新的客户信息时不得重试。
软拒绝	临时发卡行限制、需要身份验证、订阅扣款余额不足	仅在改变条件或合理调度后重试。
技术失败或结果不明确	超时、连接中断、响应丢失、结果未知	先确认状态，不能直接认定支付失败。

不同 PSP 的原始错误码并不一致，因此重试引擎需要统一的失败分类，同时保留原始渠道码和消息用于排查。

幂等是第一道安全控制

最危险的是结果不明确：渠道可能已经完成扣款，只是商户没有收到响应。

安全的系统应当：

1. 为业务支付操作分配幂等键；
2. 单独记录每一次渠道尝试；
3. 结果未知时主动查询渠道状态；
4. 在适用场景下等待异步通知；
5. 重复扣款风险未消除前，禁止发起新的资金尝试。

幂等可以避免单个渠道集成内部的重复操作，但不能自动保证跨渠道重试安全，因为两家 PSP 并不共享同一个幂等域。

智能重试需要改变什么

有效的重试至少会改变一个与结果相关的条件：

• 路由： 选择具有不同表现特征的 PSP 或收单机构。
• 身份验证： 在渠道要求时触发 3D Secure 或客户操作。
• 时间： 对订阅支付延迟重试，等待余额或发卡行条件变化。
• 支付方式： 引导客户提供其他方式，而不是静默替换支付工具。
• 上下文： 修复配置、渠道可用性或请求格式问题后再尝试。

策略还应限制尝试次数、冷却时间、最长恢复窗口，并遵守渠道和卡组织规则。

收银台支付与订阅支付需要不同策略

在交互式收银台中，每一次额外尝试都会增加客户可感知的延迟。对明确且可重试的技术失败执行一次即时备用路由可能合理，但长重试链会降低转化率，也让最终结果更难解释。

订阅支付拥有更长的恢复窗口。重试计划可以考虑工资周期、发卡行行为、订阅宽限期和客户通知，但遇到硬拒绝、卡片关闭、客户取消或已经支付成功时必须停止。

一个可执行的决策流程

每次失败后：

1. 确认不存在已经成功或仍在处理中的尝试。
2. 将渠道结果归一为统一失败类别。
3. 检查失败类别和渠道规则是否允许再次尝试。
4. 确认重试预算和时间窗口尚未耗尽。
5. 选择能够改变成功概率的路由或执行时间。
6. 在原业务幂等上下文中创建下一次尝试。
7. 记录策略版本和决策原因。

任何状态不明确时，都应进入查询或对账流程，而不是继续重试链。

衡量挽回效果，而不是重试次数

• 按原始失败类型统计的挽回率；
• 相对“不重试”基线带来的增量授权；
• 每笔挽回交易需要的尝试次数；
• 新增延迟和处理成本；
• 重复扣款及对账异常率；
• 重试后的客户投诉、退款和拒付；
• 定时重试挽回的订阅流失。

重试次数多不代表成功。目标是用尽可能少且安全的尝试挽回符合条件的支付。

运营保护措施

• 维护渠道级可重试与禁止重试错误码清单。
• 对重试策略做版本管理，并保留决策审计记录。
• 提供全局停止开关和渠道级熔断器。
• 防止多个工作线程同时重试同一笔支付。
• 监控 Webhook 和状态查询，正确处理延迟到达的成功结果。
• 由风控、合规、财务和客服共同评审策略。

智能重试应与支付智能路由配合，并纳入完整的支付成功率漏斗评估。