01订单号对应兑换，哈希对应链上交易
创建兑换后，系统返回订单号；这时尚未付款，也可能没有任何交易哈希。待你发送资产、订单发出目标资产，或发生实际退款时，才会出现相应的链上记录。
因此，不要把订单号粘贴进区块浏览器当作哈希查询，也不要把充值哈希当作整笔兑换的唯一编号。订单查询会区分订单编号与处理阶段。
02用一笔教学记录示例把编号串起来
示例仅说明查询关系：订单号「ORDER-示例」对应整笔 BTC → USDT 兑换；充值哈希「TX-IN-示例」对应你在 Bitcoin 网络发出的 BTC；转出哈希「TX-OUT-示例」对应 FeilongEX 订单在 TRON 网络转出的 USDT。只有实际发生退款时，才会再出现退款哈希「TX-REFUND-示例」。
排查时先用订单号确认当前阶段，再到各自网络查询对应哈希。充值哈希成功，只能证明那笔充值进入区块链记录；它不能代替目标网络的转出证明。示例编号不能用于 FeilongEX 查询，也不是可付款信息。
资料依据：FeilongEX：当前报价与订单字段说明 ↗FeilongEX：订单编号与数据边界 ↗Bitcoin 开发者指南：交易标识与交易输出 ↗
03先确定你想确认哪一步
想知道订单是否仍在处理，用订单号打开订单查询；想确认钱包里的付款是否上链，用充值哈希查发送网络。收到转出哈希后，再到目标网络核对接收记录。
例如 ETH 换 SOL 涉及两个网络，Ethereum 上的充值交易和 Solana 上的转出交易应分别查看。在 USDT TRC20 换 BTC 中，也不能用 TRON 充值成功推断 Bitcoin 收款完成。
资料依据：FeilongEX：当前报价与订单字段说明 ↗Ethereum：区块浏览器中的交易状态、代币转移和公开数据 ↗
04预计数量不属于付款凭证
订单创建时就会记录预计发送与预计接收数量，这些数字描述订单要求，不证明资金已经移动。即使页面已有接收数量，也可能尚未实际转出；需要结合转出哈希与对应链上状态核对。
充值是否被识别，则要结合实际收到数量及充值时间等记录判断。这些字段在订单接口中具有不同含义。若不清楚估算为何变化，可先看浮动与固定汇率指南。
05有哈希后，还要检查状态和转账内容
哈希是检索线索，不是成功保证。区块浏览器可能显示待处理、失败或成功；核对时还应查看网络、收款地址、资产和数量。以 Ethereum 为例，代币转账应检查代币转移记录，不能只看交易最上方的 ETH 数值。
查不到记录时，先确认网络是否正确、哈希是否复制完整，以及发送端是否已广播。需要进一步定位到账问题，再按未到账排查指南逐步检查。
06保存订单号，分享信息时区分范围
FeilongEX 当前可凭订单号查询订单详情。基于这一查询方式，应把订单号及带编号的完整查询链接当作敏感信息，不要公开贴到论坛、评论或社交账号。需要协助时，通过已核实的官方支持渠道提供。
公开链上的哈希通常可供任何人查询，也可能关联地址、金额与时间。提交支持请求时，注明哪一个是订单号、哪一个是充值或转出哈希，避免把不同交易混在一起。
资料依据：FeilongEX：当前报价与订单字段说明 ↗Ethereum：区块浏览器中的交易状态、代币转移和公开数据 ↗
常见问题
有订单号，但没有交易哈希，正常吗？
可能正常。创建订单不会自动付款；是否已有链上交易，要查发送端和当前订单阶段。
充值哈希显示成功，就代表兑换完成了吗？
不代表。它只能帮助核对充值这一笔交易，目标资产的转出还需另外查验。
订单号能公开发给别人帮忙查吗？
不建议。知道编号的人可能看到订单详情，求助时应使用官方支持渠道。