手机网站支付成功后支付宝回调偶尔缺失或延迟如何排查

2026-10-24支付老李

结论

支付宝手机网站支付成功后，异步通知偶尔缺失或延迟，通常与前端跳转无关，常见原因包括：

notify_url 没有正确传入，或无法从公网稳定访问。
支付宝已发送通知，但请求被网关、WAF、反向代理或应用拦截。
应用收到通知后验签失败、处理超时，或返回内容不符合要求。
业务代码依赖 return_url 判断支付结果，把同步跳转误当成支付回调。
通知处理没有幂等和主动查询机制，网络抖动后，订单一直停留在”待支付”状态。

处理这类问题时，应以支付宝异步通知为主要入口，用 alipay.trade.query 主动查询作为补偿。通知接口必须能从公网访问，并完成快速验签和幂等更新。处理成功后，应向支付宝返回纯文本 success。

先确认回调类型

手机网站支付通常会涉及两个地址：

return_url：用户支付完成后，浏览器同步跳转的地址。
notify_url：支付宝服务器主动请求的异步通知地址。

return_url 不能作为可靠依据。用户可能关闭页面、断网、阻止跳转，参数也可能在跳转过程中丢失，因此不能据此最终确认订单已经支付。

后台应以 notify_url 收到的异步通知为准。如果一段时间内仍未收到通知，再调用订单查询接口确认交易状态。

排查步骤

1. 检查实际提交的 `notify_url`

确认发起支付时确实设置了 notify_url，并核对最终发送给支付宝的地址，不要只检查配置文件。

需要注意：

必须是支付宝服务器能够访问的公网地址。
不能使用 localhost、内网 IP 或只能从公司网络访问的域名。
域名、路径和端口必须正确。
HTTPS 证书应有效，证书链应完整。
地址不能依赖 Cookie、登录状态或浏览器 Session。
接口不能要求额外的自定义请求头。
尽量不要使用会强制跳转的地址，例如从 HTTP 跳转到 HTTPS，或从旧域名跳转到新域名。
测试环境和生产环境的 notify_url 不能混用。

如果请求会经过 Nginx、API 网关、CDN、WAF 或负载均衡，还要检查回调路径是否被限流、鉴权、缓存或安全规则拦截。

2. 从入口层确认支付宝是否发起过请求

不要只查看业务日志。应按照请求链路逐层检查：

CDN 或 WAF 日志。
负载均衡日志。
Nginx、Ingress 或 API 网关访问日志。
应用服务器请求日志。
支付通知业务日志。

根据日志结果，可以把问题分为两类：

所有入口日志中都没有请求：重点检查 notify_url、公网连通性、域名解析和网络策略。
入口日志中有请求，但业务没有处理成功：重点检查路由、请求解析、验签、异常、数据库事务和响应内容。

日志至少应记录：

请求到达时间。
app_id。
out_trade_no。
trade_no。
trade_status。
验签结果。
业务处理结果。
返回给支付宝的 HTTP 状态码和响应正文。
请求耗时。

不要在日志中记录私钥、完整签名材料或无关的用户隐私信息。

3. 检查通知接口的 HTTP 行为

支付宝异步通知接口应保持简单，并满足以下要求：

接收支付宝实际发送的表单请求。
不依赖前端页面。
不执行登录校验。
不返回 HTML 页面。
不发生 301、302 等重定向。
不在请求中长时间调用第三方服务。
处理成功后返回纯文本 success。
验签失败或业务处理失败时，不能返回 success。

以下返回内容都可能有问题：

"success"
success\n<html>...</html>
{"status":"success"}
SUCCESS

响应体应只包含：

success

如果支付宝没有识别到成功响应，通常会按照通知机制再次发送。具体重试次数和时间间隔可能随产品规则变化，应以当前支付宝开放平台文档和实际通知记录为准，不要让业务代码依赖固定的重试时间表。

4. 检查验签配置

回调已经到达，但程序将其判定为无效时，最常见的原因是验签配置错误。

重点核对：

验签使用的是支付宝公钥，不是应用公钥或应用私钥。
公钥与当前应用、当前环境对应。
app_id 与发起支付的应用一致。
字符集通常为 UTF-8，必须与实际配置一致。
sign_type 与请求参数一致，常见值为 RSA2。
验签前不要自行修改、排序、解码或删除业务参数。
使用官方 SDK 读取并验证原始通知参数。
不要混用沙箱和生产环境的网关、公钥及应用 ID。

下面是一个 Java Servlet 风格的示例。具体 SDK 类名和方法签名，应以项目实际使用的支付宝 Java SDK 版本为准：

@PostMapping(
    value = "/payment/alipay/notify",
    consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE,
    produces = MediaType.TEXT_PLAIN_VALUE
)
public String notify(HttpServletRequest request) {
    Map<String, String> params = new HashMap<>();

    request.getParameterMap().forEach((name, values) -> {
        if (values != null && values.length > 0) {
            params.put(name, String.join(",", values));
        }
    });

    try {
        boolean verified = AlipaySignature.rsaCheckV1(
            params,
            alipayPublicKey,
            "UTF-8",
            "RSA2"
        );

        if (!verified) {
            log.warn("Alipay notify signature verification failed, outTradeNo={}",
                params.get("out_trade_no"));
            return "failure";
        }

        String appId = params.get("app_id");
        String outTradeNo = params.get("out_trade_no");
        String tradeNo = params.get("trade_no");
        String tradeStatus = params.get("trade_status");
        String totalAmount = params.get("total_amount");

        if (!configuredAppId.equals(appId)) {
            log.warn("Unexpected app_id, outTradeNo={}", outTradeNo);
            return "failure";
        }

        paymentService.handleAlipayNotification(
            outTradeNo,
            tradeNo,
            tradeStatus,
            totalAmount
        );

        return "success";
    } catch (Exception e) {
        log.error("Failed to process Alipay notification", e);
        return "failure";
    }
}

不要在验签前把参数转成 JSON，也不要对字段再次进行 URL 编码。验签应使用请求中收到的参数集合，并交给官方 SDK 按支付宝的签名规则处理。

5. 校验通知中的订单信息

验签成功后，不能直接把订单改为”已支付”。至少还要核对：

app_id 是否属于本系统。
out_trade_no 是否存在。
total_amount 是否与订单金额一致。
seller_id 是否符合预期。是否需要校验，应根据当前产品及接入方式确定。
当前订单状态是否允许变更。
trade_no 是否已经关联到其他订单。
trade_status 是否属于业务认可的成功状态。

金额不能使用 double 比较。Java 中可以使用 BigDecimal：

BigDecimal notifiedAmount = new BigDecimal(totalAmount);
BigDecimal orderAmount = order.getPayableAmount();

if (notifiedAmount.compareTo(orderAmount) != 0) {
    throw new IllegalStateException("Payment amount mismatch");
}

哪些 trade_status 在业务上表示支付成功，应以手机网站支付当前接口文档为准。不能收到任意通知后就把订单更新为”已支付”。

6. 保证通知处理幂等

支付宝可能重复发送同一笔交易的通知，所以回调接口必须支持重复调用。

可以采用以下方式实现幂等：

为 out_trade_no 设置唯一约束。
为 trade_no 设置唯一约束，或建立唯一关联。
使用条件更新，只允许订单从”待支付”变为”已支付”。
收到重复通知时，只返回当前处理结果，不重复发货、加积分或发券。
将发货等后续操作投递到具备幂等能力的消息队列或任务表。

示例：

UPDATE payment_order
SET status = 'PAID',
    alipay_trade_no = :tradeNo,
    paid_at = :paidAt
WHERE out_trade_no = :outTradeNo
  AND status = 'PENDING';

如果更新行数为 0，还要查询订单当前状态：

如果订单已经是 PAID，说明这是重复通知，可以返回 success。
如果订单不存在、金额不匹配或状态异常，应记录告警并继续处理。

7. 缩短回调处理时间

不要在通知请求中同步执行耗时操作，例如：

调用多个下游系统。
发送短信或邮件。
生成复杂报表。
长时间等待库存、物流等外部服务响应。
执行大范围数据库查询。

推荐的处理流程如下：

接收参数
  → 验签
  → 校验订单、金额和应用信息
  → 幂等更新支付状态
  → 写入本地事件或可靠消息
  → 返回 success
  → 异步执行发货等后续业务

在支付状态可靠写入数据库之前，不能返回 success。否则即使本地处理失败，支付宝也可能认为通知已经完成。

8. 增加主动查询补偿

网络通知只能尝试最终送达，业务系统不能无限期等待回调。以下订单需要执行补偿查询：

用户已从 return_url 返回，但订单仍处于待支付状态。
订单创建一段时间后，仍未收到异步通知。
通知验签成功，但本地处理出现暂时性异常。
客服或对账发现支付宝状态与本地状态不一致。

查询时，可以使用商户订单号 out_trade_no 或支付宝交易号 trade_no 调用 alipay.trade.query。示意代码如下：

AlipayTradeQueryRequest request = new AlipayTradeQueryRequest();
request.setBizContent("""
{
  "out_trade_no": "%s"
}
""".formatted(outTradeNo));

AlipayTradeQueryResponse response = alipayClient.execute(request);

if (response.isSuccess()) {
    String tradeStatus = response.getTradeStatus();

    // 校验订单、金额等信息后，以幂等方式更新本地状态。
    paymentService.reconcileOrder(
        outTradeNo,
        response.getTradeNo(),
        tradeStatus,
        response.getTotalAmount()
    );
} else {
    log.warn(
        "Alipay trade query failed, outTradeNo={}, code={}, subCode={}",
        outTradeNo,
        response.getCode(),
        response.getSubCode()
    );
}

这段代码只用于说明调用方式。请求对象、字段获取方法和异常类型可能因 SDK 版本不同而变化，应以项目实际使用的 SDK 接口定义为准。

补偿任务要限制查询频率和最长查询周期，不能对每笔订单进行没有上限的轮询。订单关闭、交易不存在和暂时查询失败，也需要分别处理。