用户付了钱，订单却卡在待支付

钱已经从用户账上扣走，订单还停在待支付，客服工单挂上来，退款流程被迫启动。这是支付系统最让人难堪的故障，行业里叫掉单。一次掉单的善后成本，远比把防掉单做扎实要高。

掉单的根子在于支付这件事天然跨系统。本方记账和渠道扣款是两个独立动作，中间靠一条网络回调串联。只要这条串联在任意一环断裂，就会出现渠道那边钱已收、本方这边订单没更新的不一致。掉单无法彻底消灭，因为网络总在抖动，渠道也总有抽风的时候。能做的是把断裂的概率压到极低，并且一旦断裂能自动补回来。

只靠回调是危险的

图：回调丢失的四种方式——把支付状态正确性赌在一条 HTTP 请求上是危险的

最朴素的实现是相信渠道的回调。渠道支付成功后主动 POST 一个通知过来，本方收到就更新订单。这套逻辑在测试环境永远跑得通，因为测试环境没有丢包。

生产环境里回调会以四种方式丢掉。渠道那侧网络抖动或本方接口短暂不可用，通知压根没送达，这是回调丢失。通知送到了，本方处理时 DB 抛了主键冲突或分布式锁拿不到，处理失败，订单没更新。再往下，渠道把钱扣了但自己的回调系统出 bug 没发出通知。最隐蔽的一种，本方收到了也处理了，但更新订单那条 SQL 因为库压力大超时回滚，渠道却以为通知成功了。

只挂一道回调等于把整个支付状态正确性赌在一条 HTTP 请求上。任何严肃的支付系统都不会这么干，必须叠上主动查询和对账两层兜底。

第一层，被动回调

回调仍然是主路径，因为它的延迟最低，正常情况下秒级到账。把回调做对有三个不能省的动作。

第一是验签。渠道用私钥对通知签名，本方用渠道公钥校验，确认这条通知确实来自声称的渠道，而不是被构造的伪造请求。跳过验签或验签实现有漏洞，攻击者就能伪造支付成功通知白嫖商品。

第二是幂等。渠道为了保证通知到达，普遍带重试机制，本方没回成功确认就重发。于是同一条支付结果可能被通知好几次，处理逻辑必须容忍重复。靠状态机约束最省心，更新语句写成带条件的原子操作，已是 PAID 的订单再来一条重复通知，UPDATE ... WHERE status = WAITING 直接 affected 为 0，不会重复处理。

第三是及时确认。处理完就立刻返回渠道约定的成功标识，比如微信要求的 SUCCESS。不返回或返回慢，渠道按策略重试，高峰期重试流量叠加正常流量，回调接口先被自己人打爆。

处理失败也别让渠道重发

回调处理失败时，把失败透传给渠道看似合理，实际是个坑。渠道收到失败会立刻重发，本方 DB 还在异常，重发又一次失败，再次重发，短时间内回调堆积。更稳的做法是处理失败也返回成功，同时把这条回调原样落到失败回调表，由本地定时任务重试。渠道不再重发，本地保证最终处理成功，压力不出本方。

第二层，主动查询补偿

图：防掉单的三层兜底体系——回调为主路径，主动查询修复主力，对账终极保险，层层递进

回调再稳也有送达不到的时候，所以不能干等。开一个定时任务，扫描待支付超过若干分钟的订单，逐笔调渠道的订单查询接口，确认这笔支付在渠道侧的真实状态。

1
@Scheduled(fixedDelay = 60000)
2
public void compensateLostPayment() {
3
    List<Order> pending = orderDao.findPendingOverMinutes(5);
4
    for (Order order : pending) {
5
        PaymentStatus status = channelApi.query(order.getPaymentId());
6
        if (status == PAID) {
7
            orderService.markPaid(order);
8
        }
9
    }
10
}

这段逻辑是掉单修复的主力。它把渠道已收钱、本方没更新的订单找出来补上。扫描窗口设多长是个取舍。太短，订单刚下单还没付就被查，浪费渠道查询配额，还可能误判。太长，掉单的订单在待支付里挂太久，用户等不及已经发起客诉。实践中五到十分钟是个常见区间，既给用户正常支付留出时间，又不让掉单拖太久。

主动查询也不是免费的。它会持续打渠道的查询接口，量大了要跟渠道申请配额。我参与过的营销侧大促保障里，大促零资损的目标就建立在这种自动补偿能稳定兜住的基础上，而不是寄望于回调一次都不丢。

第三层，对账兜底

即便有主动查询，仍会有漏网。查询时刻刚好踩在渠道状态还没翻过来之前，或者渠道有延迟入账。这些零星的漏网，靠日终对账兜住。

每天本方订单和渠道下发的对账文件逐笔比对。渠道账单里有、本方没有的，是掉单，补单。本方有、渠道没有的，是长款，要核查是不是重复记账或异常。这一层是终极保险，前面两层能修复绝大多数，对账把剩下那点边角也清干净。

状态对齐，面向用户的最后一公里

图：状态对齐的最后一公里——前端轮询或长连接推送，把后端账面正确翻译成用户能感知的一致性

前面三层保证的是账的正确，但用户感知到的是页面上那个状态。回调到达有几秒延迟，这几秒里用户付完款跳回订单页，看到的还是待支付，第一反应是没付成功，要么反复点支付造成重复扣款风险，要么直接找客服。

所以前端不能只查一次。支付完成后前端轮询订单状态，或者保持一条长连接，回调在本方落库后立刻把最新状态推给前端，几秒内把页面从待支付翻到已支付。这是把后端的状态正确翻译成用户能感知的一致性。

把掉单率当成核心指标

掉单治理的成效最终落在一个数字上，掉单率，掉单笔数除以总支付笔数。做得好的系统能把这个数压到万分之一以下，再往下边际成本急剧上升，不值得死磕，剩下的交给对账兜底。

监控除了掉单率，还要盯补偿成功率，即主动查询修复掉的订单占总掉单的比例，反映补偿机制是否有效。回调平均到达延迟、待支付订单积压量也是预警信号，积压上升往往意味着回调接口在出问题。掉单率一旦跳升，基本就是回调链路异常，要立刻排查而不是等对账。掉单治不治得好，是支付系统可靠性的试金石。