To check a TRON transaction, find its full transaction ID in the sending wallet or withdrawal history and search it in a TRON Mainnet explorer such as TRONSCAN. The useful result is not just “found”: verify the recipient, asset, amount and execution outcome, then investigate whichever stage has not completed.
An exchange order number is an internal reference. If the sender has not supplied an on-chain hash, you cannot yet establish from that reference that funds were broadcast.
Use the full hash or the sending wallet's explorer link. Check that the explorer is showing TRON Mainnet, since a test-network record or a transaction on another chain does not establish this payment.
Compare the sender and recipient with the payment instructions. For native TRX, inspect the coin transfer. For USDT, inspect the token transfer entry, genuine contract and amount: the destination of the outer contract call can be the token contract rather than the person receiving the tokens. The coin-versus-token distinction helps interpret these fields.
For a TRX to USDT exchange, keep the deposit and payout hashes separate. A successful deposit proves one transfer; it does not by itself prove that the later payout has been sent.
The next action depends on the missing stage. Repeating the payment before identifying that stage can create a second transfer while leaving the original problem unresolved.
Without a hash, check whether the sending platform is still approving or queuing the withdrawal. Ask whether it has actually broadcast the transaction and request its on-chain identifier.
With a hash, compare the full string, network and sending record. Allow for explorer indexing and check another current explorer if needed. A record missing from one interface is not enough to conclude that the sender failed or that a second payment is necessary.
Read the execution receipt rather than treating inclusion in a block as success. A failed contract execution will not become successful merely by waiting longer, and an included failure may still consume network resources.
Out of Energy: inspect available resources, spendable TRX and the transaction's permitted execution budget. A larger USDT balance does not supply the missing Energy. Reassess the wallet's estimate and settings before retrying; raising a budget does not make an unfamiliar contract safe.
Contract revert: the contract rejected an operation under its own rules. Check the genuine contract, token balance and requested action; the precise cause depends on the application. Use that application's official troubleshooting information instead of paying a “support” address supplied in a message.
Compare the receiving address with the account currently open in the wallet. Check the actual token transfer and balance before refreshing or adding the verified token to the display. Importing a contract changes visibility; it does not move funds.
If the transfer went to another account, this is a recipient problem rather than a display problem. Compare it with the TRON address you intended to fund; no interface refresh can redirect a completed payment.
Check the platform's accepted asset and network, minimum deposit and confirmation policy. An explorer's success label cannot override an unsupported deposit or establish that the provider has finished its own processing.
If those conditions match, contact the receiving provider with the evidence below. If the sender has not broadcast a payout, investigate with the sender instead: the two support teams control different stages.
TRON normally schedules blocks approximately every three seconds. Inclusion, solidification and a provider's account credit are different events, so that interval is not a guaranteed payment deadline.
End-to-end time can also include a withdrawal queue before broadcasting and processing after chain confirmation. Time the on-chain stage from the actual transaction, not from the Withdraw button. Where a platform specifies a confirmation threshold, compare the transaction against that condition rather than an unrelated transfer's completion time.
A focused support request identifies the payment and explains which expected outcome has not occurred. Public transaction evidence is enough for an initial investigation; a private key or recovery phrase is never required.
You cannot cancel a finalized transfer from its explorer record. Contact the recipient about a return if appropriate; someone claiming to unlock a reversal for an advance payment is not providing a normal network function.
A screenshot can help explain a problem but is not conclusive on-chain evidence. Verify the transaction and token transfer record directly.
A custodial service may send from its operational wallet. Match the recipient, asset and amount to your payout record instead of expecting the sender to be your original deposit address.
You can inspect its history and narrow by time and amount, but busy accounts may have many similar transfers. Obtain the exact transaction ID from the sender to avoid identifying the wrong payment.