微信公众号支付退款业务中，当退款状态发生变化时，微信支付服务器会向商户配置的回调地址发送异步通知。不少刚接入退款接口的同学会发现，自己明明只发起了一次退款，后台却连续收到好几条内容相同的通知报文。翻看日志还能看到，这些通知并不是密集连续到达，而是先隔了15秒来一次，再过15秒来一次，接着30秒、3分钟、10分钟这样逐渐变长。这背后其实是微信支付为了保障整个生态稳定性而设计的异步通知重试机制。
微信退款异步通知的重试间隔规则解析
微信支付退款异步通知的重试策略并不是随意设定的。根据官方文档与大量线上日志的统计，其推送节奏通常表现为：首次通知失败后，隔15秒发起第二次；若仍失败，再隔15秒发起第三次；之后间隔变为30秒、3分钟、10分钟、30分钟、1小时、2小时、6小时、15小时，直到达到最大重试次数（一般为24次左右）后停止。这种前密后疏的曲线，本质上是一种混合退避算法。
之所以前两次都是15秒，是为了在网络出现短暂抖动或商户服务刚重启尚未完全就绪时，能够快速补推，尽量让通知在秒级内被成功处理。从第三次开始，间隔逐步拉长，是因为如果商户系统持续不可用，继续高频重试只会白白消耗微信侧的连接资源，也可能对已经不堪重负的商户服务器造成进一步打击。下面是一段模拟该间隔生成的伪代码：
# 模拟微信退款通知重试间隔
intervals = [15, 15, 30, 180, 600, 1800, 3600, 7200, 21600, 54000]
retry_count = 0
def next_retry_delay():
global retry_count
if retry_count < len(intervals):
delay = intervals[retry_count]
retry_count += 1
return delay
else:
return None # 超过最大重试次数
while True:
delay = next_retry_delay()
if delay is None:
print("停止重试")
break
print("等待" + str(delay) + "秒后重试")
从上面的逻辑可以看出，微信并没有使用纯指数退避（如1秒、2秒、4秒、8秒），而是在最开始使用了两个固定的短间隔，随后才将间隔大幅拉开。这样的设计兼顾了实时性与系统开销，比单纯的指数退避更适应支付场景。对于商户来说，清楚这些数字意味着：如果你的接口只是宕机了20秒，大概率还会收到后续通知，不必过度恐慌。
商户侧如何正确处理重复通知与幂等
由于重试机制的存在，商户的退款回调接口必然会面临同一个退款单被通知多次的情况。如果代码里直接每次收到通知就修改用户余额或记录流水，那就极有可能出现重复退款或重复记账的资金事故。因此，幂等性是接入微信退款通知时第一条必须守住的底线。常见的做法是利用退款单号（out_refund_no）或微信返回的退款流水号作为唯一键，在数据库里做唯一索引或分布式锁。
具体落地时，可以在接收到通知后，先查询本地退款记录表。如果已经存在该退款单且状态为已处理，则直接返回成功响应，告诉微信不必再推；如果不存在或处于未处理，则开启事务更新状态并执行业务逻辑。注意微信要求回调接口必须在规定时间内（通常5秒）返回包含<return_code>SUCCESS</return_code>的报文，否则视为通知失败触发重试。以下是一段简化的PHP处理示例：
// 微信退款通知回调处理片段
$refund_no = $_POST['out_refund_no'];
$status = $_POST['refund_status'];
$exist = $db->query("SELECT id FROM refund_log WHERE out_refund_no='$refund_no' AND done=1");
if ($exist) {
// 已处理过，直接返回成功
echo '<xml><return_code><![CDATA[SUCCESS]]></return_code></xml>';
exit;
}
// 未处理，执行业务逻辑并标记完成
$db->beginTransaction();
$db->exec("UPDATE user_balance SET balance=balance+{$amount} WHERE uid={$uid}");
$db->exec("INSERT INTO refund_log(out_refund_no,done) VALUES('$refund_no',1)");
$db->commit();
echo '<xml><return_code><![CDATA[SUCCESS]]></return_code></xml>';
除了数据库唯一约束，也可以在Redis里用SETNX做短期锁，防止并发通知同时穿过判断。需要提醒的是，有些开发者误以为微信只推一次，于是在接口里写了大量耗时操作，导致响应超时，反而诱发了更多重试。合理的做法是把耗时任务丢进消息队列异步执行，回调接口本身只做校验和快速落库。
重试机制对系统架构与监控的启示
理解微信这套管退避重试节奏，对商户系统本身的架构也有反向指导意义。既然微信前两次间隔仅15秒，说明商户的退款通知接口必须保证在分钟级故障内可恢复，最好配合健康检查与自动重启。如果使用了容器编排，可以设置 liveness 探针，在进程卡死时快速拉起，从而不错过早期的密集重试。
在监控层面，建议单独采集微信退款通知的到达时间与次数，绘制成时序图。一旦观察到某个退款单重试超过5次仍未成功，往往意味着商户接口已出现异常，需要告警介入。同时，日志中应当完整记录每次通知的头部信息、报文内容和处理结果，以便事后核对。因为微信的重试可能跨越数小时，如果没有连贯的日志，排查资损将非常困难。
另外，有些团队会搭建一个中间层来接收微信通知，再由中间层通过内部MQ分发给自己多个业务系统。此时中间层也必须继承幂等和快速响应特性，否则在转换环节引入延迟，同样会被微信判定为失败。总之，微信的15秒、15秒、30秒节奏不是负担，而是一份关于如何构建弹性支付系统的免费教科书。