结论

不能仅凭这一现象认定“回调不稳定只存在于沙箱环境”。沙箱链路可能有延迟、限流或模拟机制不完整等问题，但生产环境的支付通知同样无法保证实时送达、只发送一次或严格按顺序到达。

判断支付是否成功，不能只依赖异步 POST 回调。建议这样处理：

• 将回调作为主要入账信号；
• 验证签名、金额、商户号和订单号；
• 使用订单查询接口进行主动补偿；
• 通过幂等处理避免重复通知造成重复入账；
• 最终以支付平台服务端的查询结果为准。

如果支付平台没有公开沙箱回调的服务等级，就不能直接断定“正式环境一定稳定”。

常见原因

回调地址无法被平台访问

支付平台的服务器必须能从公网访问通知地址。以下情况都可能导致请求无法送达：

• 使用 localhost、内网 IP 或仅限局域网访问的域名；
• 防火墙、安全组或 WAF 拦截了平台请求；
• HTTPS 证书过期、证书链不完整或 TLS 配置不兼容；
• 域名解析错误，或者 IPv6 记录指向不可用的服务器；
• 回调接口出现 301、302、登录鉴权或其他跳转；
• 测试隧道或代理服务临时离线。

排查时不要只看应用日志。请求可能在 CDN、负载均衡、网关或 WAF 层就被拒绝，根本没有进入应用。

回调接口没有及时返回成功响应

许多支付平台要求商户在较短时间内返回指定内容或 HTTP 成功状态。如果接口同步执行数据库事务、调用第三方服务或发送消息，很容易超时。

平台未收到符合协议的响应时通常会重试。具体的重试次数、间隔和成功响应格式，应以对应支付平台的文档为准，不能一概而论。

请求体被中间件修改

部分签名算法要求使用原始请求体。如果 JSON 中间件先解析数据，再重新序列化，空格、换行或字段顺序可能发生变化，导致验签失败。

遇到这种情况，请求其实已经到达服务器，只是业务代码将其判定为非法通知。日志应分别记录“收到请求”和“验签结果”，不要只记录支付成功后的业务处理。

订单或测试数据重复使用

连续扫描多个二维码时，要确认每次生成的商户订单号都唯一，并检查二维码是否过期。重复使用订单号、复用旧二维码或混淆不同测试账号，都可能造成支付状态与本地订单无法正确对应。

沙箱自身存在延迟

只有在公网连通性、响应内容、签名验证和订单数据都确认无误，并且问题只出现在沙箱时，才有理由怀疑沙箱通知链路存在延迟或异常。即便如此，仍需通过平台提供的通知记录、订单查询结果或技术支持工单加以确认。

推荐排查步骤

1. 确认支付平台实际使用的回调地址

检查创建订单时提交的通知地址，以及商户后台配置的默认地址，确认环境变量没有用错、路径没有拼错、测试域名也没有过期。

回调地址应是完整的公网 HTTPS 地址，例如：

https://pay.example.com/webhooks/payment

不要混淆浏览器支付完成后的跳转地址和服务端异步通知地址。前者供用户浏览器访问，后者由支付平台服务器调用。

2. 从公网测试接口

使用外部网络向回调地址发送测试请求：

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

需要确认：

• 请求没有发生重定向；
• 请求没有被登录页面或验证码拦截；
• HTTP 状态码符合预期；
• 网关日志和应用日志中都能找到这次请求；
• 接口能在足够短的时间内响应。

这条命令只能证明普通公网请求可以到达接口，不能代替支付平台的真实签名验证。

3. 分层查看日志

至少检查以下位置：

1. DNS、CDN 或云防护日志；
2. 负载均衡、反向代理或 API 网关日志；
3. Web 服务器访问日志；
4. 应用收到请求时的入口日志；
5. 验签失败日志；
6. 数据库更新和幂等冲突日志。

日志可以记录订单号、通知 ID、HTTP 状态码和耗时，但不要记录私钥、完整签名密钥、银行卡信息或其他敏感数据。

4. 让回调处理尽快完成

回调接口应先完成必要的校验和订单落库，随后立即返回协议要求的成功响应。发送短信、发放权益等耗时操作，应交给消息队列或后台任务处理。

下面是一个简化的 Express 示例。verifySignature、字段名称和响应内容必须按照实际支付平台的协议实现：

import express from "express";

const app = express();

app.post(
  "/webhooks/payment",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const rawBody = req.body;
    const signature = req.get("X-Payment-Signature");

    console.info("payment callback received", {
      contentLength: rawBody.length
    });

    if (!verifySignature(rawBody, signature)) {
      console.warn("payment callback signature verification failed");
      return res.status(401).send("invalid signature");
    }

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

    // 还应核对商户号、订单号、金额、币种和支付状态。
    await savePaymentIdempotently({
      notificationId: event.notification_id,
      orderNo: event.order_no,
      transactionId: event.transaction_id,
      amount: event.amount,
      status: event.status
    });

    // 必须替换为支付平台文档规定的成功响应。
    return res.status(200).send("success");
  }
);

幂等写入通常可以依赖通知 ID、平台交易号或商户订单号的唯一约束：

CREATE UNIQUE INDEX uk_payment_transaction
ON payment_records (transaction_id);

收到重复通知时，系统不能重复发货或重复增加余额。

5. 增加主动查询补偿

对于长时间停留在“待支付”状态的订单，可以定时调用支付平台的订单查询 API。伪代码如下：

async function reconcilePendingOrder(order) {
  const result = await paymentClient.queryOrder({
    orderNo: order.orderNo
  });

  if (result.status === "SUCCESS") {
    await markPaidIdempotently({
      orderNo: order.orderNo,
      transactionId: result.transactionId,
      amount: result.amount
    });
  }
}

查询后仍要核对订单号、商户号、金额和币种，不能只看到 SUCCESS 就直接发货。

如何判断是沙箱问题

可以针对一次失败支付整理以下证据：

• 商户订单号和平台交易号；
• 创建订单的时间和支付完成时间；
• 平台订单查询接口返回的状态；
• 平台后台是否有通知发送记录；
• 回调地址及其解析结果；
• CDN、网关和应用在对应时间段的日志；
• 回调接口的响应状态码和响应内容；
• 同一套代码在其他公网环境中的测试结果。

如果订单查询显示支付成功，平台后台没有任何通知记录，服务端入口也没有请求痕迹，问题更可能出在支付平台或沙箱通知链路。此时应携带上述信息提交技术支持工单。

如果平台显示通知已经发送，则应根据发送时间、响应码和请求 ID，优先排查网络入口及接口响应。

注意事项

不要通过关闭签名验证、放行所有来源或信任客户端的“支付成功”页面来绕过回调问题。客户端结果可以用来更新页面展示，但不能作为入账和发货依据。

生产环境也应按“通知可能延迟、重复甚至暂时丢失”的情况设计。可靠的支付处理需要验签、幂等、快速响应、主动查询和对账补偿，不能建立在回调一定会即时到达的假设上。

备注：内容仅供参考。