查询订单

商家主动查单。这条接口的存在本身就是设计的一部分：回调是"平台通知你"，而它会失败、会被漏 —— 你的地址挂了、正在发版、想主动对账，都需要一条"我自己去问"的路。

http

GET {API_BASE}/api/pay/open/queryOrder?merchantOrderNo=SHOP-2026-0001
X-Pay-Api-Key: <你的 API KEY>

请求参数

参数	类型	必填	说明
`merchantOrderNo`	string	否	你自己的订单号
`orderNo`	string	否	平台订单号

两个都传时按 AND 过滤；都不传则无法定位订单。建议用 merchantOrderNo 查 —— 它是你系统里已有的那个号，对账时不用维护一张映射表。

bash

curl "$API_BASE/api/pay/open/queryOrder?merchantOrderNo=SHOP-2026-0001" \
  -H "X-Pay-Api-Key: $PAY_API_KEY"

只能查自己的单

越权防线是服务端那句按商户过滤的查询条件：客户端传什么单号都越不过它。你拿别人的订单号来查，得到的是"查不到"，而不是别人的单据。

响应

返回的订单视图与创建订单时一致：

json

{
  "code": 0,
  "data": {
    "orderNo": "PO20261011XXXXXXXXXXXX",
    "merchantOrderNo": "SHOP-2026-0001",
    "merchantNo": "M00000XXXX",
    "status": 3,
    "statusText": "已确认",
    "orderType": 1,
    "amountMinimal": "100500000",
    "payAmountMinimal": "100500123",
    "payAmountDisplay": "100.500123",
    "receivedAmountMinimal": "100500123",
    "chainId": 2,
    "chainKey": "tron",
    "tokenId": 1,
    "tokenSymbol": "USDT",
    "payAddress": "TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "txHash": "0x...链上交易哈希",
    "confirmations": 19,
    "requiredConfirmations": 19,
    "paidAt": "2026-10-11T09:58:12Z",
    "confirmedAt": "2026-10-11T09:58:41Z",
    "identify": { "mode": 1, "orderNo": "PO20261011XXXXXXXXXXXX", "calldataSuffix": "0x..." }
  },
  "msg": "获取成功"
}

状态字段

值	名称	你的系统该做什么
1	待支付	等待，或检查买家是否还没付
2	已提交	链上看到了这笔钱，等确认数攒够。不要在这个状态下发货
3	已确认	确认数达标，可以放心处理订单（回调也在此刻发出）
4	已完成	回调成功，终态
5	已过期	订单作废，不要再等
6	待人工认领	链上那笔钱归属有歧义，需人工处理，主动联系平台

不要用数值大小判断"付没付"

状态数值不是按付款程度递增的：已过期(5)、待人工认领(6) 的数值比 已确认(3) 大。判断"已付款"只认 3 与 4。

怎么用它

补回调

没收到回调、或回调处理失败时，用查询接口拿真实状态，把订单补上。

定时对账

对自己的订单列表逐日核对，把状态不一致的单子挑出来。

发货前复核

重要订单在发货前再查一次，避免只信一条可能被伪造或过期的通知。

以查询结果为准

回调可能延迟、可能重复、也可能因为你的地址不可达而没送到。任何关键动作之前，以查询接口的结果为准，回调只当作"变更触发的提醒"。

查询订单 ​

请求参数 ​

只能查自己的单 ​

响应 ​

状态字段 ​

怎么用它 ​

补回调