Why TRC-20 is the rail your customers default to
Most people holding USDT hold it on Tron. Exchanges withdraw it cheaply over TRC-20, self-custody wallets default to it, and a small transfer costs the sender very little in network fees — so when a customer wants to pay a $20 top-up or a $90 invoice, TRC-20 is the rail that doesn't eat the payment in fees. For a merchant, that translates directly into fewer abandoned payments at the low end of your ticket sizes.
Tron's throughput is the other half of the story. The network confirms transfers quickly and handles high volume without the fee spikes that hit congested chains, which makes TRC-20 a sensible default when you are processing a lot of small stablecoin payments rather than a handful of large ones. If your business is subscriptions, wallet top-ups, gaming credits, or anything with a high count of modest payments, this is the rail most of that volume will arrive on.
USDT itself is a dollar-denominated stablecoin issued by Tether — a token designed to track the US dollar one-to-one. You are not taking a position on its price. On Tron specifically, you get that dollar-stable unit on the cheapest, busiest rail Tether is issued on, which is why TRC-20 tends to be the first network customers reach for and the first one merchants ask to support.
How halfin handles a TRC-20 payment
You don't run a Tron-specific integration. Accepting USDT on Tron is the ordinary halfin invoicing flow: you create a fiat-anchored invoice, and TRC-20 USDT is one of the networks the customer can settle it on. halfin generates the Tron deposit address, watches the chain for the payment, and credits it once it has held to Tron's confirmation threshold.
Crediting is reorg-aware. halfin does not treat a freshly-seen transfer as final the instant it appears — it waits for Tron's per-chain confirmation threshold before the invoice is marked paid, so a transaction that gets unwound by a chain reorganization is reflected rather than counted prematurely. The figure you fulfill against is one that actually stuck.
Because the invoice is anchored to fiat, the amount that lands in your ledger is the dollar amount you billed, not a raw token figure you have to convert later. USDT/USDT-on-Tron tracks the dollar closely, and halfin maps your USD figure to the payable TRC-20 amount and locks it when the invoice activates — so the number the customer is shown to send doesn't drift while they open their wallet and confirm.
- Low network fees — a small TRC-20 transfer stays cheap for the payer, which protects completion rates on low-ticket payments.
- High throughput — Tron clears transfers quickly, suiting high-volume stablecoin acceptance.
- Reorg-aware credit — the invoice is marked paid only after Tron's confirmation threshold, not on first sight.
- Fiat-anchored — you bill USD, the customer pays the equivalent in TRC-20 USDT, your ledger records the dollar figure.
TRC-20 next to the other USDT rails
USDT on halfin settles on three networks, and TRC-20 is one choice among them. They are the same dollar token issued on different chains and are not interchangeable mid-payment — a payment sent on Tron arrives on Tron. The table below places TRC-20 next to the other two so you can see what picking it actually means, and what a customer who holds USDT elsewhere would use instead.
| Network | Token standard | Character | Reach for it when |
|---|---|---|---|
| Tron | TRC-20 | Low network fees, high throughput; the common default. | Most stablecoin payments, especially small or high-volume ones. |
| Ethereum | ERC-20 | Most broadly integrated; variable network fees. | EVM-native or institutional payers who hold USDT on Ethereum. |
| Solana | SPL | Fast, low-fee settlement. | Payers already living in the Solana ecosystem. |
Take a TRC-20 USDT payment with one API call
There is no TRC-20-specific endpoint. You post a fiat amount and currency to the public REST API with a scoped API key, and halfin returns a payable invoice the customer can settle in USDT on Tron — alongside the other supported networks — through hosted checkout or a checkout you render yourself. You don't pin the network when you create the invoice; the customer chooses TRC-20 at the point of payment.
Below is a minimal create call. The amount is a string — monetary values are strings end to end, never floats — and the currency is your fiat anchor. The idempotency_key field in the request body makes a retried request safe: the same key never creates a second invoice. The exact response fields are defined in the docs and the @halfin/sdk-merchant types; the point here is that one authenticated call gives you an invoice a customer can pay in TRC-20 USDT.
curl -X POST https://api.thehalfin.com/api/v1/invoices \
-H "X-API-Key: $HALFIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount_fiat": "20.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Wallet top-up — USDT accepted",
"idempotency_key": "00000000-0000-4000-8000-000000000002"
}'
# halfin locks the rate at activation, pins the payable USDT amount, and
# returns an invoice the customer can pay on Tron (TRC-20) among the
# supported networks. Track state via signed webhook events; verify the
# HMAC signature before acting. Full response schema at docs.thehalfin.com.Paying out USDT on Tron, not just accepting it
TRC-20's low fees and throughput cut the other way too. If you owe a stablecoin to a partner, affiliate, or supplier, single and mass payouts send USDT back out on Tron — and the same per-transfer economics that make TRC-20 attractive to your customers make it attractive for disbursing at volume. A mass payout batch is idempotent, so a retried batch doesn't double-send.
If a customer is owed money back, refunds return value on a supported rail. And a balance that arrived as TRC-20 USDT does not lock you into TRC-20 USDT — balance conversion lets you rebalance into another asset or network when your treasury needs it. Accepting, refunding, paying out, and converting all run against the same fiat-anchored balance, so TRC-20 USDT sits in the same ledger as every other asset you handle.