cryptoinfraA customer says "I sent it." Your dashboard still shows nothing. Five seconds later they send a screenshot. Ten seconds later they ask again.
Every crypto business lives through this moment. The payment is real, but it is not final yet. Between the customer pressing send and your balance going up, the TRON network and your platform do several checks. Knowing what those checks are helps you build a better product, write clearer help pages and answer the "where is my money?" question with confidence.
This guide walks through each step, in plain words.
#Sent is not the same as confirmed
When a customer sends USDT, TRX or USDC, their wallet signs a transaction and broadcasts it to the network. At that point the transaction is only a request. It is not yet part of the blockchain.
Three things still have to happen:
- A block producer has to put the transaction into a block.
- The transaction has to actually succeed when it runs.
- Enough new blocks have to be added on top, so the payment cannot be undone.
Only after all three is it safe to treat the money as yours. Crediting a balance earlier is how businesses get burned.
#Step 1: the transaction lands in a block
TRON makes a new block every few seconds. Each block holds a batch of transactions. Once a transaction is inside a block, anyone can look it up by its transaction hash (often called the TXID) on a TRON block explorer.
This is the moment the customer's wallet often shows "success". It is good news, but it is the start of the process, not the end.
On our platform, a scanner reads every new block and looks for transfers into the addresses we issued to your users. It does this for all three supported tokens on the same address. When it finds one, it records a deposit for that user and starts tracking it. You do not run a node and you do not poll the chain yourself.
#Step 2: the transfer must actually succeed
This step surprises many people. A transaction can be in a block and still fail.
USDT and USDC on TRON are TRC20 tokens. Moving them means calling a smart contract. If the contract call runs out of resources or is rejected, the transaction is recorded on-chain as reverted. The sender may still pay a network cost, but no tokens moved.
A careless system that only checks "is the TXID in a block?" would credit this fake payment. A careful one checks the result. On our platform, a reverted transfer is marked as orphaned and is never credited. If you are new to how TRC20 transfers work, our earlier guide What is TRC20? explains the smart-contract side.
#Step 3: confirmations pile up
Each new block added after the one holding your transaction is one confirmation. More confirmations mean the payment is buried deeper, and it becomes practically impossible to reverse.
Why wait at all? Because in rare cases the network can briefly disagree about the newest blocks. When that settles, a very recent block can be replaced, and a transaction in it can disappear. Waiting for a set number of confirmations protects you from crediting a payment that later vanishes.
Our platform waits for a fixed number of confirmations on TRON before it credits anything. The exact number is shown live on the pricing page and in the deposit address docs. Because TRON blocks come quickly, this wait is usually short — often around a minute from the moment the payment lands in a block.
If a transaction is seen and then drops out of the chain, or is never found again after a long time, it is marked orphaned and never credited.
#Step 4: the balance moves and a webhook fires
When the confirmation count is reached, three things happen together:
- the user's balance goes up in a double-entry ledger;
- the deposit moves to the credited status;
- your server receives a signed
deposit.creditedwebhook.
That webhook is your signal to act: mark the order paid, unlock the feature, send the receipt. Check its signature first, and deduplicate it, because a webhook can arrive more than once if your server was slow to answer. The webhooks docs show how.
#The deposit lifecycle at a glance
| Status | What it means | Is money credited? |
|---|---|---|
confirming | In a block, counting confirmations | No |
credited | Enough confirmations; balance moved, webhook sent | Yes |
orphaned | Reverted on-chain, or dropped from the chain | Never |
ignored_dust | Below the minimum deposit for that token | Never |
The last row is worth knowing. Very small transfers are often spam sent to many addresses. A deposit below the token's minimum is recorded as dust and not credited. The minimums are part of the live schedule on the pricing page. There is no deposit fee: a deposit at or above the minimum is credited in full, minus only your own fee if you have chosen to set one.
#What this means for your product
#Show the right state to your customer
Do not show "Paid" when the customer presses send. Show something honest, like "Payment detected — confirming", and switch to "Paid" only when the deposit.credited webhook arrives. Customers are calm when they can see progress. They panic when the screen says nothing.
#Credit only on the webhook
Never credit an account because a customer sent a screenshot or a TXID. Screenshots can be faked, and a TXID can point to a reverted or wrong-token transfer. The webhook is the one source of truth.
#Remember the token
One TRON address receives TRX, USDT and USDC. The webhook names the token. Your code should credit the right balance for each, and not assume every deposit is USDT. The wallets page explains how one permanent address per user works.
#Match payments to orders
A user's address stays the same forever, so the address alone cannot tell you which order was paid. Keep your own record of what the user owes, and match the credited amount and time against it.
#A checklist for handling deposits
- [ ] Your UI shows "confirming" until the credited webhook arrives.
- [ ] Your webhook handler verifies the signature before trusting the body.
- [ ] Your handler deduplicates on event type and deposit id.
- [ ] Your handler answers quickly with a success code and does the work afterwards.
- [ ] Each token is credited to its own balance.
- [ ] Your help page tells customers to pick TRON as the network when they send.
- [ ] Your support team knows how to look up a TXID on a block explorer.
- [ ] You have tested a full deposit flow in the sandbox.
#Common mistakes
| Mistake | What goes wrong | Fix |
|---|---|---|
| Crediting on "in a block" | A reverted transfer is treated as paid | Credit only on deposit.credited |
| Trusting screenshots | Fake or wrong payments get through | Use the webhook, never the customer's word |
| No deduplication | The same deposit is credited twice | Store the event type and deposit id |
| Slow webhook handler | Deliveries time out and repeat | Reply fast, process in the background |
| Assuming USDT only | A USDC or TRX deposit looks unpaid | Read the token from the webhook |
#In summary
A TRON deposit goes through a short but important journey: it lands in a block, it must succeed, it gathers confirmations, and only then is it credited. Reverted and dropped transfers are never credited, and tiny spam transfers are set aside as dust. Your job is simple: wait for the signed webhook, verify it, and show your customer honest progress along the way.
Want confirmed TRON deposits, signed webhooks and per-user addresses under your own brand, without running a node? Sign up free and send your first test deposit in the sandbox today.