A supplied transaction hash is a lookup reference, not sufficient proof that you received the promised crypto payment. Open the record independently on the correct network and verify its execution, asset, recipient and amount. A valid hash can belong to a failed, pending, older or unrelated transaction, while a convincing screenshot can show something different from the actual network record.
Establish the payment you were expecting first
Keep the expected asset and network, receiving address, amount and any order-specific routing requirement. Without that reference, finding a transaction only establishes that some transaction exists. If you are settling an invoice or releasing something after payment, match the evidence to that obligation rather than accepting a familiar token logo and a long string. Preserve the original instructions so a later conversation does not silently change the agreed destination.
Coinbase's hash explanation describes using the identifier to retrieve a transaction on the appropriate explorer. The identifier helps locate evidence; the contents determine whether it is the evidence you need. Do not infer a universal hash format for every blockchain or treat a format checker as verification of execution.
Open your own route to the ledger record
Use a trusted explorer reached independently of the sender's link, then paste the identifier. A page supplied as a receipt can imitate an explorer, and a browser padlock only concerns that connection's certificate. Compare the domain with reliable network documentation. MetaMask's network-verification guidance also treats supplied network and explorer information as something to verify, not accept solely because an app displays it.
If the transaction is not found, check the copied identifier and network before declaring fraud. A wrong network, incomplete copy or unresolved submission can also explain an absent result. Ask the sender for the exact network and its original sending record. Keep the payment unverified while that evidence is missing; uncertainty is not a reason either to accuse immediately or to release goods as though payment were confirmed.
Use a sequence of checks rather than one green badge
| Evidence offered | Why it may be insufficient | Independent check |
|---|---|---|
| A hash with no matching record | It has not established a network transaction | Identifier, network and original sending record |
| A pending transaction | Execution is not yet established | Result and required settlement state |
| An included transaction with execution failure | Block inclusion does not prove the intended transfer | Receipt result and actual movements |
| A successful transaction to another address | It does not pay your destination | Complete recipient comparison |
| A familiar token name or logo | Another contract can use similar metadata | The actual asset identity on that network |
| An old successful payment | It may not settle the current obligation | Order association and whether it was already used |
| A fee or transaction total | It may not be the recipient amount | The specific movement to your address |
For an Ethereum example, EIP-658 defines a receipt status for top-level execution success or failure. Even success is not a complete business-payment verdict: the transaction could have performed a different action. Inspect the recipient movement. For an ERC-20 payment, the outer transaction's To field may identify a token contract instead of your receiving address.
A real hash can support a false claim
Consider a fictional invoice expecting 25 units of token R at address A. The sender supplies a real successful transaction showing 25 R to address B. The hash itself is real; the statement that it paid A is false. The useful response identifies the mismatch and asks for the actual sending evidence. Do not get diverted into debating whether the string looks long enough or whether the screenshot's color is convincing.
In another fictional case, the recipient is correct but the movement is zero units, or belongs to a different token contract with the same ticker. The ERC-20 specification permits zero-value transfers and their events, so the existence of a transfer entry does not establish the amount due. Compare units and token identity. If several movements exist, identify those relevant to the expected payment rather than adding unrelated entries.
A third case uses a prior valid receipt for a new order. Confirm whether it is the same earlier settlement already recorded in your books. Time alone is not the full rule, since payment instructions and business workflows differ. What matters is the evidence connecting the transfer to this obligation without counting it twice. Keep those internal records; the blockchain does not know your private invoice-allocation rules.
Turn the checks into a payment decision
- Write down the original asset, network, recipient and amount expected.
- Open a verified explorer independently and locate the supplied transaction.
- Establish its execution result and the settlement evidence relevant to the payment.
- Inspect the exact asset movement, full recipient and actual units delivered.
- Reconcile any memo, order reference or earlier allocation required by your receiving process.
- Accept, keep pending or challenge the payment claim based on those specific findings, retaining the evidence.
For reading the Ethereum fields, use the Etherscan guide. Keep the same discipline on other networks while using their own terminology and structures. A Bitcoin output, a Solana token movement and an Ethereum token event are not identical interface rows. The general question remains whether the correct value reached the intended destination under the agreed conditions.
Resolve discrepancies without creating another exposure
Tell the sender what is missing or inconsistent: no located record, wrong destination, wrong asset, failed execution or a previously allocated payment. Do not request wallet secrets as proof, and do not connect your wallet to a sender's verification page merely to read public evidence. A fee to validate a hash does not substitute for the network record. If the discussion involves an intermediary platform, preserve its order reference and use its official dispute or support process.
The P2P payment-scam guide covers related pressure around releasing an obligation. For a no-account swap, compare the actual payment with the current order's instructions rather than using an unrelated receipt. The goal is a verifiable match, not a promise of recovery or a reason to send an extra payment. A correct hash is valuable evidence only after its contents answer the payment question.
FAQ
Can a fake payment claim include a real transaction hash?
Yes, a genuine identifier can point to a transfer that failed, paid another destination or settled something else. Verify the record's contents against the expected payment.
What should a USDT transaction hash check include?
Check the network, actual token identity, recipient, delivered units and execution result. A token name or successful outer transaction alone is not enough.
Does transaction hash not found on Ethereum prove a scam?
Not by itself: first check the copied identifier, network and original sending record. Keep the payment unverified until the missing evidence is resolved.