PAYATHON 2026

小程序使用 tradeNO 拉起支付时提示订单不存在

支付老李

结论

tradeNO 不能填写第三方支付公司自行生成的订单号。小程序调用支付接口时，需要传入对应支付平台创建并返回的交易号，而且创建该交易号所用的支付账号和应用环境必须与当前小程序一致。

出现“支付失败，订单不存在”，通常有两种原因：传入的号码不是支付平台能够识别的交易号，或者该交易号与当前小程序的应用、商户账号或运行环境不匹配。

常见原因

1. 混淆交易号与商户订单号

一条支付链路中可能同时存在多种订单号：

  • 第三方支付公司的订单号
  • 商户订单号，如 out_trade_no
  • 支付平台创建订单后返回的交易号，如 trade_no
  • 小程序支付接口要求的 tradeNO

这些字段不能互换。即使变量名都叫 tradeNO，也不代表它们是同一种编号。

例如，支付宝小程序调用 my.tradePay 时，tradeNO 应填写支付宝创建交易后返回的交易号，不能使用第三方支付公司的内部订单号或商户订单号。

2. 创建订单和拉起支付使用了不同应用

即使传入的是支付平台交易号，如果创建订单时使用的 app_id 与当前小程序的 AppID 不一致，也可能查询不到订单。

需要逐项核对：

  • 服务端创建订单时使用的 app_id
  • 小程序实际运行时对应的 AppID
  • 签约商户或收款账号
  • 第三方支付公司的渠道配置
  • 支付产品是否支持当前小程序场景

3. 混用了测试环境和正式环境

沙箱订单只能在对应的沙箱环境中使用，正式环境创建的订单也不能在沙箱环境中拉起。

开发版、体验版和正式版小程序还可能连接不同的后端地址或使用不同的渠道配置，因此需要确认实际请求进入了哪套环境。

4. 第三方渠道返回字段的含义不同

第三方支付公司返回的 tradeNO 可能只是内部字段名，其中保存的内容未必是支付平台交易号。应查看该渠道的接口说明，确认：

  • 该字段由哪个系统生成
  • 该字段能否直接用于小程序支付
  • 是否还要调用“创建支付”“预下单”或“换取支付凭证”接口
  • 小程序端需要传入交易号、支付令牌，还是完整的支付参数

不能只看字段名称来判断它的用途。

5. 订单没有创建成功或已经失效

如果服务端创建订单失败，却仍将某个订单编号返回给小程序，拉起支付时也会提示订单不存在。订单已经关闭、超时或被撤销时，也可能出现相同或相近的错误提示，具体表现取决于支付平台和渠道的实现。

排查步骤

第一步：记录完整的支付链路

分别记录以下信息，但不要在日志中输出私钥、签名密钥或完整的用户敏感信息：

商户订单号：
第三方渠道订单号：
支付平台交易号：
创建订单使用的 app_id：
当前小程序 AppID：
支付环境：sandbox / production
创建订单接口返回码：
创建订单接口返回消息：
小程序支付接口错误码：
小程序支付接口错误信息：

先确认传给小程序的值是否就是创建交易接口响应中的支付平台交易号。

第二步：检查服务端的创建订单响应

服务端不能只判断 HTTP 请求是否成功，还要检查支付平台或第三方渠道返回的业务状态。

以下代码仅演示处理逻辑，实际字段名应以所用渠道的接口文档为准：

async function createPaymentOrder(order) {
  const response = await paymentProvider.createOrder({
    out_trade_no: order.orderNo,
    total_amount: order.amount,
    subject: order.subject
  });

  if (!response || response.success !== true) {
    throw new Error(
      `创建支付订单失败：${response?.code || "UNKNOWN"} ${
        response?.message || ""
      }`
    );
  }

  // 必须确认该字段确实是小程序支付接口要求的支付平台交易号
  const tradeNO = response.trade_no;

  if (!tradeNO) {
    throw new Error("创建订单成功，但响应中未返回可用于小程序支付的交易号");
  }

  return { tradeNO };
}

如果第三方渠道只返回自己的渠道订单号，还需要继续调用其小程序预下单接口，取得真正的支付凭证，不能直接拉起小程序支付。

第三步：核对小程序端的参数

以支付宝小程序的接口形式为例：

my.tradePay({
  tradeNO: paymentResult.tradeNO,
  success(result) {
    console.log("支付接口返回：", result);
  },
  fail(error) {
    console.error("拉起支付失败：", error);
  }
});

这里的 paymentResult.tradeNO 应由服务端返回。不要在小程序端自行拼接订单号，也不要把 out_trade_no 或第三方渠道订单号直接赋给它。

同时，不能仅凭 success 回调判断业务订单已经支付成功。最终支付结果应由服务端主动查询订单，或通过支付平台的异步通知确认。

第四步：从服务端查询订单

使用创建订单时相同的支付平台账号、app_id 和运行环境查询该交易号：

  • 如果服务端也查询不到，可能是订单号类型错误、订单未创建成功或环境不一致。
  • 如果服务端能够查询到，但小程序无法拉起，需要继续检查小程序 AppID、支付产品签约关系和渠道授权关系。
  • 如果只能通过第三方渠道查询，无法通过支付平台查询，该号码很可能是渠道内部订单号。

第五步：绕过第三方渠道进行对照测试

条件允许时，可以使用相同的小程序和商户配置，通过支付平台官方的创建订单接口生成一笔测试订单：

  • 如果官方链路能够正常拉起，问题通常出在第三方渠道的字段映射、应用配置或预下单流程。
  • 如果官方链路也提示订单不存在，应优先检查 AppID、商户账号、运行环境和支付产品配置。

推荐的服务端返回结构

为了避免混用不同类型的订单号，可以在业务接口中明确区分各个字段：

{
  "merchantOrderNo": "ORDER_202609140001",
  "channelOrderNo": "CHANNEL_987654321",
  "platformTradeNo": "2026091422000000000000000000",
  "payToken": null
}

小程序端只读取服务端明确指定的拉起支付字段：

const tradeNO = response.platformTradeNo;

if (!tradeNO) {
  my.showToast({
    content: "未获取到有效的支付交易号"
  });
  return;
}

my.tradePay({
  tradeNO,
  success: handlePayResult,
  fail: handlePayError
});

如果渠道要求传入的不是 platformTradeNo，而是 payToken、orderStr 或其他支付凭证，就应按照该渠道对应的小程序支付流程处理，不能直接套用 tradeNO 的调用方式。

注意事项

  • 不要根据字段名猜测订单号类型，应以支付渠道的接口文档和实际创建订单响应为准。
  • 创建订单、查询订单和拉起支付必须使用同一账号、应用和环境。
  • 支付金额应由服务端根据业务订单计算，小程序端只负责发起支付。
  • 不要把私钥、渠道密钥或服务端签名逻辑放进小程序代码。
  • 支付结果必须以服务端查询结果或可信的异步通知为准，同时做好签名验证和幂等处理。
  • 排查日志可以保留订单号，但应隐藏用户标识、授权信息、密钥及其他敏感数据。
  • 如果第三方渠道声称其返回值可以直接用作 tradeNO，应要求对方确认该号码对应的支付平台、创建订单时使用的 AppID、运行环境以及适用的小程序支付接口。

备注：内容仅供参考。