Accept USDT TRC20 Payments in a Bot or Service: Addresses, Fees, Mistakes

Short answer: accepting USDT TRC20 payments in a bot or service costs you nothing by itself, because the sender pays for an incoming transfer. The costs come later: when you sweep USDT from deposit addresses into your main wallet, each of those transfers uses about 64,500–65,000 energy (if the main wallet already holds USDT), and without energy the network burns about 6.5 TRX. Below: how to choose an address scheme, how to credit payments reliably, and where services most often lose money.

How USDT TRC20 payments work: what the network sees

USDT on TRON is a TRC-20 token, which means it is a smart contract. When a customer pays your bot, they call the contract's transfer function: "send this much USDT to this address." The contract updates balances and writes a Transfer event to the blockchain with the sender, the recipient and the amount.

For payment acceptance this means three things. First, a USDT transfer has no "order ID" field you can reliably depend on, so a service can tell who paid only by the recipient address or by the amount. Second, the amount is stored in base units, and USDT TRC-20 has six decimals, so 1 USDT appears in the event data as 1,000,000. Third, proof of payment is a Transfer event from the official USDT contract, not anything else that shows up in the address history.

Two schemes: one address per customer or one shared address

An address per customer or per invoice

The service gives each user (or each invoice) its own deposit address. Everything that arrives at that address is credited to its owner. This is how exchanges and most top-up bots work.

• Pro: a payment is unambiguously tied to the customer, any amount works, and crediting the wrong person is nearly impossible.
• Con: funds end up spread across many addresses and have to be swept into the main wallet. Every sweep is a separate transaction with its own fee.
• Con: you end up with a lot of addresses, and every address you send from needs energy or TRX.

One address and a unique amount

Everyone pays to a single wallet, and the service tells payments apart by amount: an invoice for 100 USDT gets a small "tail" such as 100.0137. No sweeping is needed because the money already sits in one place.

• Pro: no cost of sweeping deposit addresses.
• Con: the customer must send the exact amount. Exchanges and some wallets deduct their own withdrawal fee, so less arrives and the payment is not matched automatically.
• Con: two invoices with the same amount at the same time cause confusion, so each amount needs an expiry.

For a bot with recurring top-ups, a per-customer address is usually the better choice because it tolerates user mistakes. The unique-amount scheme fits one-off invoices and small volumes.

How to credit a payment without falling for a fake

The most common mistake in homegrown integrations is trusting the first thing that shows up in an address's history. A proper payment check looks like this:

• Contract. The event must come from the official USDT contract on TRON, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t (you can verify it on Tronscan). A token named "USDT" with the same icon but a different contract is not a payment.
• Event type is Transfer. An approve (a spending permission) moves no money, even if it carries a huge amount. Never credit it as a deposit.
• The recipient is your address, and the amount is read in base units with six decimals.
• The transaction status is successful. A failed transaction is also recorded on-chain, but it does not change balances.
• The block is irreversible. Credit the payment once the block is solidified (confirmed by validators), not the moment the transaction appears.
• Idempotency. The payment key is the transaction hash plus the event index inside it. Processing the same event again must never credit funds twice.

Confirmations and crediting speed

A TRON block is produced every 3 seconds, so a transaction becomes visible almost immediately. But "visible" and "irreversible" are different states. For small amounts many services credit after the transaction first appears in a block; for large amounts they wait until the block is irreversible. Public TRON APIs have separate methods for reading confirmed data (walletsolidity).

How often you poll the network depends on your API. Free tiers of public nodes cap requests per second, and a service that polls thousands of addresses every second quickly hits the limit. It is more reliable to subscribe to USDT contract events, or to read new blocks in full and filter transfers to your own addresses, than to poll every address one by one.

What accepting USDT TRC20 really costs

An incoming transfer is free for you: the sender spends the energy and TRX. Costs appear when the money has to move.

• Sweeping a deposit address into a main wallet that already holds USDT: about 64,500–65,000 energy per transfer, or about 6.5 TRX without energy.
• Sending to an empty address (for example, a new cold wallet): roughly twice the energy, about 131,000, or about 13 TRX without energy.
• Bandwidth: a simple transfer takes about 345–360 bandwidth. The network gives every activated address 600 free bandwidth per day, so one or two transfers a day from an address usually need nothing extra.
• Customer payouts and refunds are regular outgoing transfers under the same rules.

The cost of a transfer does not depend on the amount. Sweeping 5 USDT costs the same as sweeping 5,000. That is why, with a per-customer address scheme, small deposits can cost more than they bring in if you sweep them one at a time.

The fee is charged per transaction, not per amount. The economics of accepting payments are the economics of sweeps: less often, larger, and with energy.

How to sweep USDT from deposit addresses for less

• Sweep threshold. Don't sweep every deposit right away; wait until an address holds an amount worth spending energy on.
• Never empty the main wallet. As long as it holds USDT, every sweep runs at the regular rate instead of twice as much.
• Energy instead of burning TRX. Before a batch of sweeps, delegate energy to the deposit addresses so you don't have to keep TRX on each of them.
• Keep bandwidth in mind. If an address sends more than a couple of transactions a day, the free allowance may run out and the network will burn a little TRX for bandwidth.
• Schedule. Run sweeps in one batch at a set time instead of reacting to every incoming payment.

Common mistakes services make when accepting USDT

• Crediting an approve or a fake token transfer as payment.
• Crediting a payment before the block became irreversible and delivering goods for a transaction that later was not in the chain.
• No idempotency: after a handler restart, the same transfer got credited twice.
• The customer sent USDT on another network (ERC-20, BEP-20) to a "similar-looking" address. Warn in the interface: TRC-20 only.
• Underpayment due to an exchange's fee in the unique-amount scheme; you need manual review or an amount tolerance.
• Deposit addresses with no energy and no TRX: the money arrived, but there's nothing to sweep it with.
• Keys to all deposit addresses sit on the same server as the bot. A server breach means losing all funds. Keep keys separate from the public part of the service and sweep into a wallet whose keys are not stored on that server.

AML and freezes: what to remember when accepting USDT

Tether can freeze USDT at a specific address. If funds linked to fraud land on your deposit address, the risk is now yours: the address may be blocked, and an exchange may refuse to accept those USDT. Services with meaningful volume screen incoming payments with AML tools and have rules for a "dirty" deposit: hold, return to sender, manual review.

Launch checklist for accepting USDT TRC20 in a bot

• You have chosen a scheme: per-customer address or shared address with a unique amount.
• A payment is credited only on a Transfer event from the official USDT contract, with a successful status and your address as recipient.
• You have a confirmation rule: when to credit small and large amounts.
• The payment key is the transaction hash plus the event index; double crediting is impossible.
• You have a sweep threshold and schedule for deposit addresses; the main wallet is never emptied.
• You have an energy source for sweeps and payouts: your own TRX stake or rental.
• Deposit address keys are stored separately from the bot.
• The interface clearly says: TRC-20 network only.