How to Accept USDT TRC20 on Your Website: Step-by-Step
Updated: September 4, 2026
USDT on the TRON network is the most common way customers want to pay with crypto: the rate does not swing, network fees are low, and a transfer settles in about a minute. We break down three ways to accept it on a website — with the honest downsides of each — and walk through an integration that fits into a single evening.
Why TRC20 specifically
USDT (Tether) is issued on several networks, but payments almost always come through two of them: Ethereum (the ERC20 standard) and TRON (the TRC20 standard). For payment acceptance the difference is practical:
- Network fee. An ERC20 transfer on a busy Ethereum network costs from a few to tens of dollars. A TRC20 transfer costs under a dollar when paid with network resources — and that fee can be shifted to the payer (we explain how below).
- Speed. TRON produces a block every 3 seconds; a payment is visible almost immediately and reliably confirmed within a minute.
- Habit. Exchanges default to TRC20 for USDT withdrawals — your customer has most likely paid this way before.
Bottom line: if you add exactly one crypto payment method to your site, it is USDT TRC20. A stablecoin removes the volatility fear on both sides: an invoice for 50 USDT is still an invoice for 50 dollars an hour later — and a week later.
Three ways to accept — with the honest downsides
1. Manually: your own address on the payment page
You create a wallet, put the address and a QR code on your site, and ask the customer to mention the order number in a comment or message you after paying.
- Upside: free and quick — you can launch today.
- Downside: payments do not match themselves to orders. Two customers paid the same amount — you cannot tell whose payment arrived. Nobody reconciles at night — delivery gets delayed.
- Downside: no underpayment handling, no exchange rate, no timer. The customer sent 2 USDT less than due — settle it over chat.
Works for "a couple of payments a week from people I know". Breaks on the first dispute.
2. Depositing through an exchange
Some accept payments straight to the deposit address of an exchange account: the exchange shows incoming transfers by itself.
- Upside: no key management to think about.
- Downside: an exchange is not a payment tool. Deposit addresses rotate from time to time, and receiving "commercial activity" violates the terms of most exchanges — the account can be frozen together with the money pending review.
- Downside: the same reconciliation problem — the exchange will not tell you which customer paid.
3. A payment gateway
A gateway issues a separate address for every invoice — so a payment is unambiguously tied to its order without comments or chat. It watches the network, counts confirmations, catches underpayments and late payments, and calls your backend with a webhook once the money has arrived.
- Upside: reconciliation is automatic, goods ship without a human — including at night.
- Downside: it is a service, and it has a price. Look past the "0.5% fee" headline at the full math: a percentage of turnover quickly overtakes a flat subscription at any real volume.
- The downside nobody mentions: with most gateways the wallet keys belong to the gateway and only to it. Ask any service: "can you show me my wallet's seed phrase?" Silence is an answer too. With us you can take it from the dashboard at any moment.
A one-evening integration
You need a backend able to send an HTTPS request — any language. The whole path: sign-up → key → one POST request → a payment link. Working requests are below, and the same ones live in the documentation in PHP, Python, Node and Java.
Step 1. An API key
Signing up at /portal or in the
@coinrail_bot Telegram
bot issues API_KEY and WEBHOOK_SECRET immediately — no waiting for
an operator. The key is shown once: store it in environment variables, not in code.
Step 2. An invoice
When the customer picks "pay with USDT", your backend creates an invoice:
curl -X POST https://coinrail.net/v1/invoices \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"coin": "USDT",
"amount": "50",
"externalRef": "order-4821",
"callbackUrl": "https://shop.example/webhook"
}'
The response contains a fresh address for this invoice, an invoiceId and a
checkoutUrl: a hosted payment page with the amount, a QR code, a countdown and
a live status. You do not have to build your own page — just send the customer to the link.
externalRef is the order id in your system: it makes retries safe and comes
back in the webhook.
Step 3. The webhook
Once the payment collects its confirmations, the gateway POSTs to your
callbackUrl with a signature made with WEBHOOK_SECRET. Verify the
signature → mark the order paid → ship. Underpayment, overpayment and late payment arrive
as separate events — you do not untangle those cases by hand.
Fees and energy: what is actually paid for in TRON
In Bitcoin the sender pays the network fee with the same coins being sent. TRON does not work that way: the fee for a token transfer is paid not in USDT but with network resources — energy and bandwidth. Energy can be obtained three ways: by freezing TRX, by burning TRX, or by renting it on the energy market. Renting is several times cheaper than burning — everyone who moves USDT regularly relies on it.
For you as a merchant this means:
- Accepting USDT is free — the network fee is paid by your customer, the sender (their wallet or exchange).
- For a payout the gateway pays the network fee and withholds a flat
charge: 2.5 USDT when the fee is covered by rented energy (the typical case), or 4 USDT if
renting failed and TRX had to be burned. It is not a percentage: the payout amount does not
change the charge. Both rates are visible in advance via
POST /v1/payouts/estimateand on the pricing page.
Why many services price a USDT payout at "up to $10" — exactly because of burning: without rented energy, a token transfer costs tens of TRX. A separate guide on TRON energy with our gateway's production numbers is in the works.
A permanent address: when an invoice is not the right tool
Invoice-per-payment is the right mode for a store. But sometimes you just need a
permanent receiving address: payment details in a contract, donations, a
transfer from your own exchange account. Free-standing addresses cover this:
POST /v1/addresses issues an address with no invoice and no expiry, and incoming
transfers to it show up in the dashboard and the API. Up to ten addresses per coin — free.
Frequently asked questions
The customer sent less than the invoice says. What happens?
How long does a USDT TRC20 payment take to settle?
How much does accepting USDT cost?
Does the customer need an account to pay?
Who holds the wallet keys?
Can I issue an invoice right in Telegram, without a website?
Next: the API documentation — the full reference for invoices, payouts and webhooks — and pricing: a flat monthly fee, 0% of turnover, seven days free with no card.