沙箱支付成功且有交易号，但一直未收到回调怎么办？

结论

“支付成功并生成交易号”只能说明支付平台已完成交易，不能证明回调已经成功送达。长时间收不到回调，常见原因有：

• 回调地址无法从公网访问，仍然指向内网、测试机或错误域名
• 沙箱回调地址配置错误，或者生产环境与沙箱环境的配置发生混用
• HTTPS 证书、TLS 版本、DNS、端口或防火墙导致平台无法连接
• 请求已经到达网关，但被鉴权、CSRF、WAF 或重定向机制拦截
• 服务收到回调后，在验签、解析或业务处理时失败，而且没有留下完整日志
• 接口未按平台要求及时返回确认内容，被平台判定为通知失败
• 创建支付订单时没有正确传递回调参数，或者平台不会为该交易类型发送异步通知

建议先确认交易状态，再沿着”平台是否发出、网络是否送达、应用是否处理”这条链路逐层排查。不要反复重新支付来测试，也不要把回调作为确认支付成功的唯一方式。

第一步：主动查询交易状态

既然已经拿到交易号，应先调用支付平台的订单查询 API，确认平台侧的交易状态。

需要核对：

• 交易号是否属于当前沙箱商户
• 商户订单号是否正确
• 订单是否确实处于支付成功状态
• 支付渠道、应用 ID、商户号是否与当前配置一致
• 该交易类型是否支持异步回调
• 订单或请求参数中是否记录了回调地址

不同支付平台使用的状态字段和查询 API 并不相同，请以所接入平台的沙箱文档为准。

订单查询接口也应作为回调缺失时的补偿手段。业务系统可以定时查询仍处于”待支付”状态的订单，确认平台状态后，再以幂等方式更新订单。

创建订单
   ↓
等待异步回调
   ↓
超过合理等待时间仍未收到
   ↓
使用商户订单号或平台交易号查询
   ↓
验签并核对金额、商户号、订单号
   ↓
幂等更新订单状态

第二步：检查回调地址是否真的可访问

支付平台通常从公网服务器发起回调，因此下面这些地址一般不能使用：

http://localhost:8080/payment/notify
http://127.0.0.1/payment/notify
http://192.168.x.x/payment/notify

回调地址应是平台能够访问的公网地址，例如：

https://sandbox.example.com/payment/notify

最好从服务器之外的公网网络测试该地址，不要只在本机或公司内网中验证。

curl -i -X POST 'https://sandbox.example.com/payment/notify' \
  -H 'Content-Type: application/json' \
  -d '{"test":true}'

检查时不能只看页面是否”能打开”，还要确认：

• 域名是否解析到正确的服务器
• HTTPS 和 TLS 配置是否受平台支持
• 证书是否有效，证书链是否完整，域名是否与证书匹配
• 端口是否已向公网开放
• CDN、WAF、安全组或防火墙是否拦截了请求
• 接口是否发生 301、302 或 307 重定向
• POST 请求是否被强制转换为 GET
• 请求能否在平台规定的超时时间内完成

如果使用临时内网穿透地址，还要检查地址是否发生变化、隧道是否在线，以及支付请求中的回调 URL 是否已经更新。

第三步：确认回调地址的配置来源

不少支付 SDK 同时支持全局配置和下单参数配置，最终生效的回调地址可能来自：

• 创建支付订单时传入的 notify_url
• 商户后台配置
• SDK 全局配置
• 环境变量
• 网关或反向代理重写后的地址

应记录最终发送给支付平台的下单参数，并对密钥、令牌等敏感信息进行脱敏。重点检查回调地址是否为空、是否存在拼写错误，以及是否意外使用了生产环境的配置。

例如：

{
  "out_trade_no": "ORDER_202609090001",
  "notify_url": "https://sandbox.example.com/payment/notify"
}

这里的字段名称仅作示意，实际名称应以对应平台的 API 文档为准。

还要确认沙箱应用、沙箱商户号、沙箱网关和沙箱密钥来自同一套环境。常见情况是通过沙箱网关创建交易，却使用了生产商户的回调配置，或者应用 ID 与商户号不匹配。

第四步：判断请求有没有到达服务器

先查看各接入层的日志，包括：

• CDN 或负载均衡访问日志
• Nginx、Apache 等反向代理日志
• API 网关日志
• 应用访问日志
• WAF 和防火墙拦截日志

以 Nginx 为例，可以按回调路径和时间范围搜索：

grep '/payment/notify' /var/log/nginx/access.log
grep '/payment/notify' /var/log/nginx/error.log

根据日志结果缩小排查范围：

• 完全没有访问记录：优先检查回调 URL、DNS、证书、端口、防火墙，以及平台是否发送了通知
• Nginx 有记录，应用没有记录：检查反向代理路由、容器端口和网关转发
• 返回 401 或 403：检查登录鉴权、CSRF、IP 白名单和 WAF
• 返回 404：检查部署路径、路由前缀和 HTTP 方法
• 返回 500：检查验签、参数解析、数据库操作和空指针等异常
• 返回 301 或 302：检查 HTTP 到 HTTPS 跳转、域名规范化和登录跳转
• 返回 200，但平台仍在重试：响应正文可能不符合平台要求

第五步：排除应用框架拦截

支付回调接口通常不应要求用户登录，也不应依赖浏览器 Cookie。检查接口是否受到以下机制影响：

• 登录中间件
• CSRF 防护
• API Token 校验
• 请求频率限制
• IP 白名单
• 请求体大小限制
• 全局 JSON 解析器
• 路由方法限制

例如，平台使用 POST 发送回调，但代码把路由注册成了 GET。也可能是平台发送表单数据，而应用只按 JSON 解析。

常见的请求类型包括：

application/json
application/x-www-form-urlencoded
text/xml
application/xml

实际格式取决于支付平台，不能仅凭经验判断。

第六步：保留原始请求体并正确验签

部分平台要求使用未经修改的原始请求体计算签名。如果框架先把 JSON 解析为对象，再重新序列化，字段顺序、空格或转义方式可能改变，从而导致验签失败。

下面以 Express 为例说明处理方式。签名算法和响应内容需要替换为目标平台的官方要求：

import express from 'express';

const app = express();

app.post(
  '/payment/notify',
  express.raw({ type: '*/*' }),
  async (req, res) => {
    const rawBody = req.body;
    const signature = req.get('Payment-Signature');

    console.info('payment callback received', {
      contentType: req.get('Content-Type'),
      contentLength: rawBody.length,
      hasSignature: Boolean(signature)
    });

    try {
      const verified = verifyPaymentSignature(rawBody, signature);

      if (!verified) {
        console.warn('payment callback signature verification failed');
        return res.status(400).send('invalid signature');
      }

      const event = JSON.parse(rawBody.toString('utf8'));

      await processPaymentEventIdempotently(event);

      return res.status(200).send('success');
    } catch (error) {
      console.error('payment callback processing failed', error);
      return res.status(500).send('failed');
    }
  }
);

日志可以记录请求时间、请求头名称、订单号和处理结果，但不要直接输出私钥、完整签名密钥、银行卡信息或其他敏感数据。

第七步：按平台要求返回确认响应

支付平台一般要求回调接口在较短时间内返回指定状态码或固定正文。只返回 HTTP 200 未必足够，有些平台还会校验响应正文。

平台可能要求返回：

success

也可能要求返回特定 JSON：

{
  "code": "SUCCESS",
  "message": "成功"
}

这些只是常见形式，不对应任何特定平台的规范。具体要求必须查阅当前支付产品的回调文档。

回调接口中不要执行耗时任务。可以按以下顺序处理：

1. 验证签名。
2. 校验商户号、订单号、金额和币种。
3. 以幂等方式记录事件或更新订单。
4. 尽快返回成功响应。
5. 将发货、积分和通知等后续操作交给消息队列或异步任务。

如果接口先执行复杂业务，最后因超时未能及时响应，平台可能把本次通知判定为失败并继续重试。

第八步：检查平台侧通知记录

如果沙箱后台提供通知日志、Webhook 日志或重试记录，应查看：

• 是否生成了回调事件
• 实际请求的 URL
• 首次发送时间和重试次数
• HTTP 状态码
• 响应正文
• 是否出现超时、DNS、TLS 或连接失败

如果平台明确显示”未发送”，应检查订单创建参数和沙箱产品能力。如果显示”已发送且返回 200”，问题通常出现在应用日志、验签或业务状态更新环节。如果显示连接失败，应优先处理网络和 HTTPS 配置。

部分沙箱环境的行为可能与生产环境不同，例如通知存在延迟、部分支付方式不触发通知，或者后台不展示完整日志。是否存在这些限制，应以具体平台的沙箱文档和平台侧记录为准，不能只根据交易号判断。

建议采用的最小排查方案

可以临时准备一个只记录请求并立即返回确认内容的回调端点，以排除业务代码的影响：

app.post(
  '/payment/notify-debug',
  express.raw({ type: '*/*' }),
  (req, res) => {
    console.info({
      time: new Date().toISOString(),
      headers: req.headers,
      body: req.body.toString('utf8')
    });

    res.status(200).send('success');
  }
);

测试时，把沙箱订单的回调地址改为这个端点：

• 仍然收不到：重点检查平台配置、公网连通性和沙箱通知机制
• 能收到：问题出在原回调接口的路由、鉴权、解析、验签或业务处理
• 能收到但平台不断重试：检查响应状态码、响应正文和处理耗时

调试端点不应长期保留。请求头和请求体中可能包含敏感信息，上线前应删除相关日志或对其脱敏，并恢复完整的验签流程。

注意事项

• 不要因为回调请求来自某个 IP 就跳过验签。
• 不要只凭回调中的”支付成功”字段直接发货，还要核对商户号、订单号、金额和币种。
• 回调可能重复、延迟或乱序，业务处理必须保证幂等。
• 不要通过浏览器手动访问回调 URL 来证明接口正常。浏览器发出的 GET 请求与平台实际发送的 POST 请求并不等价。
• 不要把”前端支付成功页面”作为服务端的支付凭证。
• 对长时间停留在待支付状态的订单，应增加主动查询和对账补偿。
• 如果本地和服务端都没有访问记录，平台后台也没有通知日志，应携带脱敏后的商户订单号、平台交易号、支付时间和沙箱应用标识，联系平台技术支持核查。不要公开商户密钥、私钥或完整支付凭证。

备注：内容仅供参考。