发送平台显示“完成”，接收端却没看到余额，先别把这两个状态当成同一件事。需要分别查清：发送平台处理到哪一步，链上发生了什么，接收端是否完成自己的入账流程。
本文只做公开记录查询，不操作账户、不发起转账。样本是Ethereum官方交易文档引用的历史记录，于2026年10月23日核对；它不是本站的提币，也不用来证明任何平台当前的充值服务。
先把三个环节分开
| 环节 | 主要证据 | 能说明什么 |
|---|---|---|
| 发送平台处理 | 提币订单、网络、状态、TxID | 平台对该订单的处理记录 |
| 链上执行 | 对应网络的交易详情、回执和资产记录 | 交易是否被纳入区块、执行结果及涉及对象 |
| 接收平台入账 | 充值记录、支持网络、确认要求 | 接收平台是否识别并记入账户 |
Binance的相关帮助也将提币请求、网络确认和接收平台入账分开。这里引用的是这个区分，不把某个平台的等待时限或确认门槛套到全部资产上。
第一步：拿到的是订单号还是TxID？
回到发送记录，保存完整的网络名、资产、数量、目标地址及TxID。订单号往往属于平台内部系统，不能保证能在区块浏览器里查询。TxID也不能脱离网络单独判断。
如果平台还没提供链上编号，先核对原订单及平台官方状态说明。不要为了制造一条可查记录重复提现，也不要通过陌生“修复链接”补交验证款。
关于地址和编号的外形，可以先看首篇对象辨认指南。本文接着解决“找到交易后该怎样读”。
第二步：在正确网络中查状态
根据订单注明的网络，从对应网络的可信入口打开区块浏览器，再输入完整TxID。以下分支以Ethereum类交易为例，不能直接替代其他链或跨链协议的专门状态说明。
| 查询结果 | 先核对什么 | 暂时不能推出什么 |
|---|---|---|
| 查不到 | 网络、完整编号、是否为订单号、查询服务是否已发现 | 不能仅凭一次空结果断言交易不存在 |
| Pending | 是否尚未进入区块、原平台是否仍处理 | 不等于已完成转移 |
| Failed／回执失败 | 失败原因、实际费用、是否另有替代交易 | 不能把失败记录视为预期转账成功 |
| Success | 具体资产、目标记录、数量及确认情况 | 不自动等于接收平台已入账 |
Ethereum交易文档区分了广播、进入区块和后续最终确定过程。JSON-RPC回执中的执行状态则回答本次执行是否成功。确认数量会随时间变化，不应把一张旧截图中的数量当作当前读数。
第三步：用真实样本读“Success”后面的内容
本例在 Ethereum Mainnet，完整哈希为：
0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1
打开公开交易详情，本次核对到的固定历史字段如下。地址用小写列出，浏览器可能采用大小写校验写法。
| 字段 | 样本值 |
|---|---|
| Status | Success |
| Block | 14330693 |
| 时间 | 2022-03-06 02:41:09 UTC |
| 交易From | 0xbae7ebe87fc708426a193f49c4829cdc6221ac84 |
| Interacted With (To) | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 |
| ERC-20记录中的接收方 | 0x4f6742badb049791cd9a37ea913f2bac38d01279 |
| 该记录显示的数量 | 990.206452 USDC |
| 交易Value | 0 ETH |
这个例子最容易看错两处：
其一，交易To是被调用的USDC合约，而代币记录里的To才是本例的代币接收方。 两者不能互换。其二，Value为0 ETH不代表没有发生代币转移。 它说明本笔交易的原生ETH Value为零，代币部分要看对应合约的转移记录。
ERC-20标准定义了Transfer事件中的发送方、接收方和数量。实际查询还要核对发出记录的代币合约，不能仅凭一个相同符号的“USDC”标签认定资产。
本例只能证明这条历史记录显示了这些对象和执行结果；浏览器对地址的命名标签，不是接收平台当前的服务承诺，更不能用它判断该地址现在属于谁。
第四步：回到自己的接收信息做逐项比对
看一笔陌生的成功交易，只是学会读字段。排查自己的记录，需要把以下内容逐项与原订单及接收页面对应：
- 网络一致吗？ 同名资产经不同网络发送，属于不同记录范围。
- 资产合约或该链的资产标识一致吗？ 不只比对符号和Logo。
- 目标地址一致吗？ 对代币交易要看实际资产记录；需要Memo或Tag的网络另核对该字段。
- 数量一致吗？ 区分申请数量、平台说明的费用与实际链上数量，保留差额而不自行猜原因。
- 接收平台要求满足了吗？ 查看该资产和网络当前的充值支持、最低金额、确认要求及暂停通知。
如果链上记录匹配，而接收平台仍无入账记录，可以通过接收平台的官方支持入口提供网络、TxID、时间和必要订单信息。公开发帖时不必附上完整账户截图或身份资料。
一张可以直接使用的核查卡
| 要记录的内容 | 填写方法 |
|---|---|
| 网络与资产标识 | 完整网络名；代币记录补合约或对应标识 |
| TxID与查询入口 | 完整编号、浏览器URL和查询时间 |
| 链上状态 | 原样记录，不把“Success”改写成“已入账” |
| 接收方与数量 | 从实际资产记录核对，不只抄交易To |
| 未解决环节 | 平台未给编号、链上待处理，或接收端未入账 |
这张卡的作用是把问题定位到一个环节。查不到、待处理、执行失败和平台未入账，需要的下一条证据不同，不应该都用“再等一会儿”或“再转一次”处理。