When a Deal Stalls: the Troubleshooting Lane
Every smoother exchange can hit gravel. This page names the three stalls in the order they usually arrive: a transfer stuck in pending, a fiat payout that does not appear, and a compliance hold. For each, the two artifacts that will matter most to whichever desk is trying to solve it.
Stall one: the transfer stays pending
You sent USDT. The chat says "waiting for blockchain confirmation." Your wallet says "success." These can both be true — wallet success means the transaction was broadcast, not confirmed on-chain. Open the hash in an explorer. If the status is "confirmed" in the explorer but the service has not acknowledged it, the delay is likely on their processing side; screen the explorer page and send it. If the status is "pending" — unusually long for TRC20, past about ten minutes — both you and the service are waiting for the same thing: a block. Resending or panicking will not help; waiting will.
- Open the hash in an explorer — do not rely on wallet status alone
- Screen the explorer page once it says "confirmed"
- If a longstanding pending: check the TRON status page (congestion, halts)
Stall two: the fiat does not arrive
The crypto side is confirmed, the service acknowledges the deal, but the money has not hit your bank app. Fiat delays are bank delays far more often than service delays. Two pieces of information are worth having: the exact time the service says the payout was sent, and a screenshot of your bank statement covering the hours since. The first gives the support desk a timeline; the second proves the absence.
- Ask the service for the payout timestamp — exact hour and minute
- Screen your bank statement for the window since payout
- Do not initiate a replacement transfer unless the service explicitly tells you to — duplicate payouts create their own problems
Stall three: compliance hold
A compliance hold means the service flagged something about the incoming transaction or the associated wallet. Most holds are not personal — they are triggered by automated risk scoring on the transaction history or source. The service usually asks for provenance: where the coins came from, a previous transaction hash, sometimes a statement. Provide the hash of the transaction that funded the wallet you are sending from, and keep your answers short and factual — the desk is working through a checklist, and every extra sentence they do not need slows the checklist down.
- Provide the funding hash — the transaction that brought USDT into your wallet
- Answer questions factually, not defensively
- Hold length varies by jurisdiction and risk scoring — ask about the expected resolution window
Frequently asked questions
What should I have ready before contacting support about a stalled deal?
Two things: the transaction hash and the quote you accepted (a screenshot of the chat is fine). The hash tells them what happened on-chain; the quote tells them what should have happened on their side. With those two, you skip the first round of "please send us your hash."
Should I send a test transaction first?
With a service that issues one-time addresses per deal, a test is rarely useful — the next deal gets a new address, so you are not testing the same pipe. Instead, keep the first deal small: a minimum viable amount that proves the full loop works before scaling.