A TxID, an order number, an internal transfer ID — which one is support actually asking for? Your transfer record often shows all of them within a few pixels of each other, and only one of them can be looked up on a chain.
That string is the entry point to every later step. Without it, you, support and the receiving platform are all working from memory. With it, where a transfer got to becomes something anyone can re-check.
What's here
What the string is, and why it looks different per chain
Binance's English help page calls a TxID "a unique string of characters given to every transaction that's verified and added to the blockchain" (checked 2026-09-16). The part worth holding on to is where it comes from: the chain produces it. No platform issues it to you, and none can edit it afterwards.
The shape varies by chain. Binance Academy's glossary entry says of Bitcoin: "On Bitcoin, SHA-256 (Secure Hash Algorithm 256-bit) produces a 64-character hexadecimal string." The same entry describes Ethereum and most other major blockchains as using a similar 64-character hexadecimal format, generated through their own hashing processes — EVM interfaces conventionally print theirs with an 0x prefix, Bitcoin's without. Solana is where people trip: there the first signature on a transaction doubles as its id, and a signature is 64 raw bytes of ed25519, so what you see is a different length and a different character set. Length and prefix therefore prove nothing. The one usable test: paste it into that chain's explorer and see whether the record comes back.
An order or withdrawal ID exists only inside the platform's own system. An internal transfer ID exists only inside that platform's books. Only the transaction hash exists on a chain, which is why it is the only one an explorer can answer for.
A transfer marked [Internal] never had one
Sometimes the hash can't be found because it was never created. Moving crypto between two accounts on the same platform runs on that platform's books and never touches a chain. Binance's English page How to Make an Internal Transfer to Another Binance Account? puts it plainly: "no TxID will be created. The TxID field will be shown as [Internal] and you will see an internal transfer ID." The recipient sees the same marker — the page notes the transaction "has the same internal transfer ID and will be marked as [Internal] under [TxID]" (checked 2026-09-16; the page's timestamps, converted to UTC, read published 2020-07-06 05:54 and updated 2025-12-03 06:59).
So [Internal] is a stop sign for explorer searches: take the internal transfer ID to the platform's support instead. Mistake 7 in deposit and withdrawal mistakes covers what goes wrong when internal and on-chain sends get mixed up in the first place.
It lives on the sending side
Most people look in the wrong place first. A deposit hasn't landed, so they dig through the receiving platform's records — but the receiving side knew nothing about the transaction until it appeared on-chain. The TxID belongs to whoever signed and broadcast it: your own wallet, or the platform you withdrew from. If someone else sent the funds to you, they have it and you don't.
On the Binance side, the English page How to Find My Transaction ID (TxID)? describes opening [Wallet] then [Overview] from the dropdown and going to [Transaction History], where "all your deposit or withdrawal history" is listed with the TxID in its own column; on mobile it gives [Assets] → [Spot] → [Transaction History], then tapping the transaction (checked 2026-09-16; the page states published 2021-03-18, updated 2025-12-19). Menu names get shuffled between app versions; the logic behind them doesn't move. The entry point sits in the transfer record, not in a chat with support.
Wallets work the same way. Open the transaction's detail view and look for a field called TxID, Transaction Hash or Tx Hash. Many wallets copy it on tap; some only offer a link out, in which case the last segment of the URL that opens is the hash itself.
Pick the right explorer before you paste
Hashes are per-chain. The same string in another chain's explorer is simply a record that doesn't exist. The usual pairings: Etherscan for Ethereum and its family, BscScan for BSC, Tronscan for Tron, a Solana explorer such as Solscan, and mempool.space for Bitcoin. So you need to know which network the transfer used — the record shows it, and it's the same network you chose when you pasted the address.
An empty result usually has a mundane cause.
- Wrong explorer. Easily the most common, because a 0x address is valid on several EVM chains and people misremember which one they used.
- Wrong string. Usually the receiving address, pasted in whole.
- Just broadcast, not yet indexed. Give it a few minutes and search again.
- It hasn't reached the network. A wallet showing pending while the explorer finds nothing is its own state — see a transfer stuck pending.
Looking up a transfer takes one pasted hash and nothing else. Any page that wants you to connect a wallet, or to type a private key or seed phrase, before it will show you a result is a fake. Impostor explorer domains sit in search results a letter or two away from the real ones, so reach them from a bookmark or the chain's own docs rather than an ad slot. The other way addresses get swapped on you is covered in clipboard-hijacking malware.
The four rows that decide the answer
An explorer's transaction page is dense — gas price, nonce, input data, internal calls. Only four rows decide what happened to a transfer; for this purpose the rest is noise.
- Status (Success / Failed). Whether the chain accepted it. A failed transaction moved no funds, though on EVM chains the gas it burned is gone.
- Block and confirmations. A block number means it was mined; confirmations count what came after. Etherscan's information centre defines them as "the number of blocks in the blockchain that have been processed (or mined) since the block that your transaction was included in was processed" (English page, published 24 August 2020).
- From and To addresses. Where it left and where it landed. Compare the opening and closing characters yourself; the truncated middle hides everything that matters.
- Amount, asset and timestamp. Confirms this is your transfer. Timestamps are usually UTC, which can sit hours away from the clock you were watching.
How many confirmations a platform wants differs by chain and by platform, so it isn't a number worth memorising — confirmations by chain gives you the order of magnitude, and the number printed on your deposit page when you send is the one that governs.
Token transfers: the "To" row isn't the recipient
Move USDT, USDC or any other token and the transaction talks to the token's contract, so the main "To" row shows a contract address. The recipient you care about sits further down, inside the token transfer section.
Checking one public Ethereum transaction row by row on 2026-09-16 (hash 0x4d96bede…abbbd8a): the main row was labelled Interacted With (To) and pointed at a contract, Value on that row read 0 ETH, and the 20,630.42 USDT that actually moved — from which address to which — appeared only under ERC-20 Tokens Transferred. Read the top row as "who got my coins" and you will conclude you sent them into an unrecoverable contract.
It comes below the From / To rows and above Value and the fee, headed ERC-20 Tokens Transferred or just Tokens Transferred depending on the explorer. Each line reads From one address, To another, For an amount plus the token name — the address and amount you want to verify are both on that line. On a phone the block is often collapsed until you tap it. For what the destination address means for recovery, read wrong network — are the funds safe.
What the lookup settles, and what it can't
After those rows you can state, with evidence anyone can re-check: the transaction exists, it used this chain, it went from this address to that one, it succeeded or failed, and it has this many confirmations. Enough to open a useful support ticket, and enough to choose between waiting and escalating.
Some questions stay outside an explorer's reach:
- Whether the receiving platform credited you. On-chain success ends at "the funds reached that address"; crediting is a separate process on their side. Confirmations in and still nothing? Work through confirmations done, not credited; for how long the waiting normally runs, see how long a deposit takes.
- Who is behind an address. Explorers show addresses, plus labels on a handful of well-known exchange wallets. Whether a mistyped address is recoverable depends on who controls it — see sent to the wrong address.
- Whether the asset is supported over there. The chain delivered it; that doesn't mean the platform ever listed it. Outcomes for that case are in depositing an unsupported token.
Success, confirmations still climbing → nobody to contact yet; wait out the range in how long a deposit takes.
Success, confirmations well past the requirement, address and asset correct → it's the receiving platform's move; hand its support the hash, network, destination address, amount and rough send time.
Failed → the funds never left your address; send again rather than wait.
Nothing found in the explorer → re-check the chain and that you pasted a hash; if both hold, follow stuck pending.
TxID column says [Internal] → off-chain; the internal transfer ID goes to platform support.
Read next
Transfer stuck pending? Which kind of stuck is it Confirmations done but not credited How long a deposit takes to arrive Confirmations and arrival times by chain Run the address through the format checker firstSources: Binance Support, How to Find My Transaction ID (TxID)? (English version; published 2021-03-18, updated 2025-12-19; checked 2026-09-16), Binance Support, How to Make an Internal Transfer to Another Binance Account? (English version; timestamps converted to UTC read published 2020-07-06 05:54, updated 2025-12-03 06:59; checked 2026-09-16), Binance Academy glossary, Transaction ID (TXID) (page dated 14 September 2026), Etherscan information centre, Understanding an Ethereum Transaction (published 24 August 2020) and the Solana terminology reference (a signature is 64 bytes of ed25519; the first signature can be treated as the transaction id). The public record quoted above: etherscan.io/tx/0x4d96bede…abbbd8a, opened 2026-09-16. Interface paths, confirmation requirements and menu names change with versions and policy, so what we saw while writing may already differ from what you see.