用户已付款，订单仍显示待支付

用户从微信支付页面返回，只能说明客户端完成了一次支付操作，商户订单不能据此直接改成“已支付”。微信支付异步回调是微信支付向商户服务端发送的通知；通知到达后，服务端还要核实来源和交易内容，再更新订单。

接到“钱扣了，商品却没发”的反馈时，先用商户订单号定位本地订单，再查看通知接收记录。记录里有请求，不代表业务已经处理成功：通知可能在验签时被拒绝，也可能在数据库更新前中断。若完全没有接收记录，还需核对下单时填写的通知地址能否被微信支付访问，以及线上环境是否仍指向旧接口。

采用微信支付 API v3 时，商户服务端要按协议使用请求头中的签名信息验签，并用 API v3 密钥解密通知中的交易数据。解密后，将商户号、商户订单号和支付金额与本地订单核对，确认交易状态符合预期。接口路径能被访问，不代表其中的订单号和金额就可信。

同一笔支付通知又到了一次

假设有这样一种情况：商户服务端收到支付成功通知，已经把订单改为已支付，却在返回响应前发生超时。微信支付没有收到成功响应，随后重发同一笔交易的通知。日志里出现两次请求，用户实际可能只付了一次款；此时若业务代码每收到一次通知就发一次货，重复交付会比页面延迟更棘手。

处理这类重复通知时，先核对商户订单号与微信支付交易号。订单仍处于待支付状态，且金额等信息一致，才执行支付状态更新；订单已支付，则保留原处理结果并返回成功响应。状态变更和依赖这次变更写入的业务记录，应放在可靠的事务或等效机制中，避免订单已改、发货任务却没留下记录。发货等耗时操作可由后续任务接手，回调接口不必等它全部完成。

这笔订单的通知记录暂时保留，运营反馈仍在跟进：还要核对发货任务有没有被实际消费。接口测试也补入“更新成功后响应超时”的情形，观察重发通知会不会生成第二条任务。

通知没到，或处理到一半

异步回调依赖网络和商户服务状态，不能把“暂时没收到”直接当成支付失败。对长时间停留在待支付、又有用户付款反馈的订单，用商户订单号调用微信支付查询订单接口，按查询结果处理，并留下查询时间与返回信息。这样既能处理漏掉的通知，也能避免客服仅凭用户截图改动订单。

回调处理失败时，不要为消除报错而直接返回成功响应。微信支付收到符合要求的成功响应后，会认为这次通知已被接收；业务尚未可靠落库却提前确认，后续只能依靠主动查询或对账发现遗漏。若本地更新失败，保留错误日志，让重试有机会重新处理，同时由定时核对补上通知始终未成功送达的订单。

排查时先分清“通知未进入接口”和“进入后未改订单”，再查看验签、解密及订单更新停在哪一步。上线前用一笔测试订单覆盖正常通知和重复通知，确认订单状态只更新一次，业务任务也只留下有效的一份。