USDT Not Received: Eight Reasons and What to Do
In most cases the money has not gone anywhere: the transaction exists on-chain and the delay comes down to confirmations, a network mismatch, or the recipient's own crediting rules. The first thing to do is not to message support but to look up the transaction hash in the right network's explorer. Five minutes of checking gives a more precise answer than a day of correspondence. Below is how to run that check and what to do with each possible result.
Written by Alexander Lebedev, analyst at OneSix. OneSix is mentioned in the section on in-service payments, with its actual timings stated.
Step one: find the transaction in an explorer
A block explorer is a public site showing every operation on a network. You will need the transaction hash (TxID), which the sender or the sending platform provides.
The explorer is chosen by network, not by coin. USDT exists on several networks at once, and a transfer on one is invisible on another's explorer:
- USDT on Tron (TRC-20) — tronscan.org
- USDT on Ethereum (ERC-20) — etherscan.io
- USDT on BNB Chain (BEP-20) — bscscan.com
If you do not know the network, check the withdrawal confirmation on the sending side — it always states TRC-20, ERC-20 or BEP-20.
Reading the result
| What the explorer shows | What it means |
|---|---|
| Transaction not found | Either you are on the wrong network's explorer, or it was never sent |
| Pending confirmation | It is on-chain; wait |
| Success, address matches | Delivered — the question is on the recipient's side |
| Success, different address | It went somewhere else |
| Failed | It did not go through, usually for lack of network fee |
Eight reasons USDT does not arrive
1. It is not confirmed yet
The most common and least alarming. On Tron confirmation usually takes under a minute; on Ethereum under load it takes considerably longer, especially if the sender set a low fee. The action is to wait. A transaction already broadcast cannot be cancelled.
2. It was sent on a different network
The classic and most expensive mistake. USDT went out on BEP-20 to an address the recipient thinks of as their TRC-20 address. On their own explorer they see nothing and conclude the transfer failed. In reality the funds sit at the same address on a different chain.
Recovery depends on who controls the address. An exchange or service holding keys to that address on both networks can usually help through support, often for a fee. A non-custodial wallet is accessible only to whoever holds the private key — and if that is you, the funds simply need to be displayed by adding the relevant network in the wallet.
3. There was not enough for the network fee
Sending USDT is paid for not in USDT but in the network's base coin: TRX on Tron, ETH on Ethereum, BNB on BNB Chain. If a wallet holds only USDT, the transaction either will not send or will fail. Such an operation shows as failed in the explorer and the funds stay with the sender. The fix is to top up with the base coin and retry.
4. A wrong address, or a poisoned one
Beyond ordinary typos there is a specific scheme. An attacker sends a negligible amount to your wallet from an address whose first and last characters match one you use regularly. That address lands in your transaction history, and next time you copy it from there.
The defence always works: compare the address in full rather than the first four and last four characters, and copy it from the source rather than from your history.
5. A required payment memo was missing
Some networks and some exchanges require a memo, tag or comment alongside the address. Without it the funds reach the platform's pooled address but are not attributed to your account. This is usually solvable — with the transaction hash, exchange support can locate and credit the payment, though it takes days.
6. The recipient has not credited the deposit yet
The transaction is confirmed but the balance has not moved. Services do not credit deposits instantly: some wait for extra confirmations beyond the minimum, others route deposits through a review. Everything looking fine in the explorer is itself the signal that the issue sits with the recipient, not the network.
7. The amount is below the crediting minimum
Many platforms set a minimum deposit. A transfer below the threshold may not be credited automatically, and occasionally not at all. The threshold is always stated on the deposit page — before you send, not after.
8. The address is on the issuer's blacklist
Rare but real. USDT is a centralised token and its smart contract holds a list of addresses barred from transacting. Only Tether's administrators can add an address, typically on a law enforcement request (Tether's law enforcement requests policy). Tokens at such an address remain visible in the explorer but will not move, and the wallet type makes no difference.
What not to do
Do not send again. Until you know where the first transfer went, a second one only doubles the problem. A pending transaction can confirm at any moment.
Do not use "crypto recovery services". Advertising for these appears exactly where people search for lost transfers. The pattern is always the same: an upfront fee for "unlocking" or "tracing", then silence. Funds sent to someone else's on-chain address cannot be recovered by anyone except the holder of that address.
Never share a seed phrase. No exchange support, no wallet support and no "recovery specialist" has any reason to ask for it. Any such request is an attempted theft.
When recovery is impossible
An honest list of hopeless cases: a transfer to a stranger's address, a transfer on a network nobody holds keys for, and a mistyped address with no owner at all. Blockchains have no reversal mechanism — that is the point of the design.
There is a chance whenever an organisation sits at the other end: an exchange, a payment service, a custodial wallet. Then it becomes a matter of correspondence rather than cryptography.
A different case: a payment, not a deposit
Everything above concerns wallet-to-wallet transfers on a blockchain. A payment inside a service — settling a ruble QR code from a crypto balance, for instance — works differently: nothing moves on-chain and the money stays within the system.
In the OneSix mini app, a failed payment returns to the wallet balance usually within 30 minutes. If the balance has not recovered after that, contact support — such a payment will not resolve itself. Do not retry the same code before you see the refund, or you risk paying twice.
How to avoid this next time
- Confirm the network on both sides before sending, every time.
- Keep a small amount of the network's base coin for fees.
- Make the first transfer to a new address a small one.
- Copy addresses from the source, never from transaction history.
- Save the transaction hash — no support case starts without it.
Quick answers
What is the first step?
Take the transaction hash and look it up in the explorer for the network used.
Can USDT sent on the wrong network be recovered?
Sometimes — if an organisation controls that address on both networks. If it is your own non-custodial wallet, the funds just need the right network added to be displayed.
Confirmed but not credited. Why?
Most likely the recipient credits deposits with a delay, the amount is below the minimum, or a required memo was missing.
Not in the explorer at all. What now?
Either the wrong explorer, or the funds never left the sender's wallet.
About the author
Alexander Lebedev — analyst at OneSix. Covers Russian payment infrastructure and settlement scenarios from crypto balances.
Published: 5 August 2026. Last updated: 5 August 2026.
This article is for information only and is not investment, tax or legal advice.
Fewer transfers, fewer chances to get it wrong
Every wallet-to-wallet transfer is a network choice, a fee and an opportunity for error. Paying ruble QR codes straight from a USDT balance removes that step entirely — nothing moves on-chain. Open the OneSix wallet on Telegram — it runs as a mini app, with nothing to install.
Payment infrastructure breakdowns and service updates are posted in the OneSix channel.
