虚拟商品订单不到账，先查推送还是接口？

用户已付款却迟迟看不到商品，多数处理动作会先催促补发或重新触发发货。真正的问题在于没有先确认订单在平台的处理状态和通知链路，不同商品类型的推送机制存在差异，盲目重发只会放大重复发货风险。

卡密类和充值类商品的完成通知不同，卡密订单成功时只发送 order.credentials.ready，其中 orderState 为 success，不会再重复发送 order.changed(success)；充值类订单每次产生新结果都会携带当前状态与 rechargeResult，成功时发送 order.changed(success)。同时，订单扣款并创建成功后的初始 pending 不发送推送，后续进入 processing、取消等状态才会触发。若你以“没收到 success 推送”判定未到账，很可能因类型差异误判。

先核对订单真实状态

先调用查询接口，按 clientOrderRef 或 platformOrderRef 精确查询，不要依据后台待处理记录断定原因。重点核对四个字段：orderState确认当前处于 pending、processing、success、canceled、partially_refunded 还是 refunded；amount确认实际扣款金额是否与预期一致；updatedAt确认订单最后更新时间；allowedActions查看当前订单可执行操作，若为空数组说明没有待处理动作。

• 状态为 processing：属于处理中，需等待，可记录 updatedAt 观察是否有更新。
• 状态为 success：订单已完成，问题集中在通知链路或前端未同步，不再重复发货。
• 状态为 canceled 或 refunded：说明订单已结束，需核对取消或退款的触发来源。
• 查询返回 404 且业务码为 404002 ORDER_NOT_FOUND：当前账户下不存在对应 OpenAPI 订单，应核对第三方订单号或平台订单号是否匹配。

区分未到账的两种成因

在确认状态后，未到账可分为两类。一类是订单本身未完成，用户付款后因上游供货或核销延迟，订单仍处于 processing，此时任何补发动作都不会让商品提前到账。另一类是订单已完成但通知丢失，充值类订单正常会收到 order.changed(success)，卡密类订单会收到 order.credentials.ready，推送失败时前端展示不出结果，实际订单已可交付。

判断标准是先读状态，再验证推送。若状态为 success 但未收到对应通知，问题出在接收地址、网络、签名校验或重复处理上。例如，你可以保留 eventId 用于后续防重，并在回调接口记录接收到的 clientOrderRef、platformOrderRef 与 orderState，再与查询接口返回的值对比。若接收地址无法访问，回调必然中断，但订单状态不会因此改变。

按优先级完成排查与处理

1. 用原单信息查询最新状态。卡密订单不填 purchaseSchemaRevision 与 purchaseEntries，充值订单需保留下单模板版本与充值资料，查询时只提交 clientOrderRef 或 platformOrderRef。
2. 若状态为 processing，保留 requestId，延迟后复查，不要关闭安全校验，也不要重新创建订单。
3. 若状态为 success，检查回调地址是否为公网可访问的 HTTPS 地址，核对返回的 HTTP code 与业务 code，不要只依赖 message 文案。
4. 若查询失败，按业务码修正后再查询：404002 核对订单号，401001 核对账户与凭证，409001 说明同一引用提交了不同内容，须使用原内容重试。
5. 若订单不存在重复或异常状态，再核对商品可用性与可用余额，余额不足时返回 422103 BALANCE_INSUFFICIENT，应充值后使用原 clientOrderRef 查询，不更换引用。

处理完成后，以查询接口返回的 orderState 为最终依据。仅当 orderState 为 success，且对应商品类型的完成通知或 rechargeResult 可读取时，才认定已到账。此判断不适用于因上游供货渠道长期维护、商品临时不可购买（返回 422102 INVENTORY_UNAVAILABLE）导致无法推进的场景，此时应等待恢复，而不是反复触发发货。

参考资料：创建订单（2026-08-31）；订单状态推送（2026-08-22）；接入指南（2026-09-20）；查询订单列表（2026-08-31）。具体操作与适用范围以对应文档为准。