Transaction hash
A transaction hash is present. Open the explorer to confirm the token transfer details.
Paste the transaction facts and the order facts to see the exact checks a payment gateway should perform before marking an order as paid.
Fetch on-chain USDT transfer facts, then compare them with order facts.
Local browser diagnosis
Result
The key gateway checks pass. In production, the backend should still verify the token contract, block timestamp, duplicate tx hash, and order expiration window.
A transaction hash is present. Open the explorer to confirm the token transfer details.
The transfer destination matches the order settlement address.
The transfer amount matches the order amount after 6-decimal normalization.
The order status is still eligible for payment matching.
The transfer has reached the required confirmation threshold.
Check that the explorer transaction is a USDT Transfer on TRC20, not another token or native coin transfer.
01
A native ETH, BNB, or TRX transfer is not the same as a USDT token Transfer event.
02
A single transaction hash should never complete more than one merchant order.
03
When customers pay late, wrong amount, or wrong network, compare explorer facts with order facts first.
Payment troubleshooting
Most support cases are not blockchain failures. They are usually a wrong network, a wrong token contract, an amount mismatch, an expired order, or a transaction that has not reached the gateway confirmation rule.
A TRC20 payment cannot complete an ERC20 or BEP20 order. The network selected by the order and the explorer transaction must match.
Only USDT token Transfer events should be matched. Native ETH, BNB, TRX, or another stablecoin contract must be rejected.
Gateways usually require the exact USDT amount generated for the order. Even a small difference can keep the order pending.
The transaction can appear on the explorer before it reaches your safe confirmation threshold. Wait until the configured block depth is reached.
A valid on-chain transfer may still need manual review if the order expired before the payment was detected.
One blockchain transaction should never settle multiple orders. Keep transaction hashes unique in your payment database.
FAQ
These checks match how a production USDT gateway should investigate pending or unmatched payments.
Check the selected network, USDT contract address, transfer destination, exact amount, order status, and confirmation count. A mismatch in any of these fields can keep the payment pending.
Yes. For diagnostics, you can use a real historical USDT Transfer transaction from the matching network and compare its amount and destination with a test order.
No. It is a diagnostic tool. It queries and compares facts, but it does not mark orders as paid, write payment records, or trigger webhooks.
The most common causes are wrong network selection, sending native coin instead of USDT, wrong receiving address, exact amount mismatch, or insufficient confirmations.