First find the outgoing record and transaction hash, then check the correct network, then the receiving deposit history. “Completed” at the sender, “Success” on-chain and “Credited” in an account describe different stages. Do not send again before you understand the first transfer.
Already confirmed on-chain? Go to the receiving-side checks, or use the table to find who can investigate.
Was it dispatched or is the sender still processing?
Match the amount, address and time to the correct record. The platform's internal order number is for its own support; a TxID or transaction hash identifies a blockchain transaction. An internal platform transfer may have no public hash at all.
If the record is under review or processing, read the sender's explanation. Missing hash information alone does not prove it was never broadcast. Ask the sender if the status is contradictory or outside its stated processing range. For a failed or cancelled request, check balances and fees separately rather than assuming everything was refunded.
Equal amounts can belong to different transfers
Open the specific outgoing record. Two sends of the same amount are easy to confuse in chat screenshots, and displayed times may use different time zones. Match the complete hash, network and destination together; use amount and time as supporting clues.
An internal order number means something inside the service that issued it. An explorer finding nothing for that number does not prove no transaction was sent. Ask the sender whether the operation was broadcast and whether a chain record exists.
For an internal platform transfer, check the receiving account or internal recipient identifier. Requiring a public hash for every internal movement sends the investigation in the wrong direction.
Check the actual token movement on the right network
A search on the wrong blockchain can return nothing. Confirm the network and full hash first. For a recent record, also consider whether the explorer has indexed it.
On Ethereum, a transaction's headline Value is an ETH amount and To may be a called contract. Read the USDT token-transfer details for recipient, amount and contract; see the transaction documentation.
- Pending: read your sender or wallet's supported options. Replacement or speed-up is not available for every network, state or exchange-sent transfer.
- Execution failed: inspect the asset movement and fee separately. An executed Ethereum transaction that reverts can still use gas, as the gas documentation explains.
- Success: confirm destination, token version and any required memo. It does not establish exchange credit.
Which explorer fields belong in the comparison?
| Field | Use for a USDT investigation |
|---|---|
| Transaction Hash / TxID | Match the complete value in the outgoing record |
| Status | Separate pending, success and execution failure, then inspect asset movements |
| Token Transfers | Find the intended token's recipient and amount, not only the main Value field |
| Token contract | Identify the asset version rather than trusting its name |
| Confirmations | Compare progress with the receiver's current requirement |
A main transaction Value of 0 ETH can coexist with a USDT transfer in the token details. These describe different assets. Conversely, seeing USDT somewhere on the page is insufficient: find the intended recipient in its transfer record.
Contract activity can produce several asset movements. Do not automatically choose the first or largest line. If the record is unclear, ask support which movement corresponds to the complete hash. Reading public records does not require connecting your wallet.
Success is a reason to continue with receiving conditions, not to stop the investigation.
Four receiving-side checks
- Compare actual confirmations with the current deposit requirement.
- Confirm network and asset support, including maintenance notices.
- Compare the amount actually received with the minimum after outgoing deductions. Do not assume a second deposit will be combined with the first.
- Check the required memo or tag. A confirmed transaction cannot be amended after the event; use the recipient's specific recovery process.
Search deposit history rather than only total balance. A credited asset may sit in a different account area. For your own wallet, inspect the actual chain and token display; do not give a “balance detection” website your seed phrase.
A deposit record exists but the balance looks wrong
Read that record's asset, amount, destination account and status. A portfolio's fiat estimate changes with prices and cannot alone establish whether USDT arrived. Account compartments and balances reserved for other actions need their own records.
If no deposit record exists, revisit the actual address and receiving conditions. Do not send again to “create a record,” and do not assume two below-minimum deposits will be combined.
Name what you are waiting for
- Sender review: investigate the sender's processing, rather than a confirmation count that may not apply yet.
- A pending transaction on the actual network: follow that network's progress; receiving support cannot turn it into another chain.
- Enough confirmations with compatible asset and network: look for the recipient's maintenance, review or crediting notice.
These are hypothetical situations, not time estimates. If a page gives a range, establish when its clock begins. Withdrawal submission time is not necessarily broadcast time.
Who can investigate the next step?
| What you know | Next contact or check |
|---|---|
| Sender processing, chain status unclear | Ask the sender to confirm dispatch |
| Pending on the actual network | Sender or wallet's network-status guidance |
| Success, matching address and asset | Recipient's deposit conditions and history |
| Wrong network, address or memo | Controller of the receiving address |
For a deposit into your own Binance account, its deposit-recovery guidance has specific conditions. It does not cover every outgoing withdrawal or another person's account. An application option is not a guarantee of recovery.
If each side refers you to the other, ask questions within each side's control. The sender can identify the actual broadcast network and outgoing result; the receiver can explain accepted assets and whether a deposit record exists for your account. Preserve their exact responses in the existing case instead of opening many disconnected “not arrived” tickets.
Before following a new instruction, identify the cause it addresses. Waiting alone does not correct the wrong network; insufficient confirmations do not justify sending recovery fees to a stranger. When the records establish an incorrect address or memo, use the corresponding error guide.
Prepare one clear transaction record
Supply asset, actual network, amount, destination, hash, sending status and the recipient's exact notice. Label internal order numbers with the service they belong to. Keep unknown details unknown and continue an existing support case rather than scattering records across private chats.
Submit necessary account-linked evidence only through verified support. Public requests do not need identity documents, unrelated balances, passwords or recovery secrets. If you arrange another payment while waiting, tell the recipient the first may still complete.
Finish the record with the actual outcome: received, returned, still pending or declared unsupported. Note the received asset and amount, or the new return transaction. An acknowledgement that support received the case is not proof of credit.