Accept Tron payments: TRX and TRC-20 USDT

A large share of stablecoin volume moves on Tron, and for a reason: TRC-20 USDT clears fast and the network fee is small enough that a five-dollar payment is worth taking. halfin runs a Tron gate that accepts native TRX and TRC-20 tokens — chiefly USDT — and pays out over the same rails. If your customers reach for USDT, this is where most of them already hold it.

Why so much stablecoin traffic settles on Tron

When someone says "send me USDT" without naming a chain, more often than not they mean Tron. TRC-20 USDT became the default stablecoin rail across large parts of the world because the transfer cost is low and confirmation is quick, which makes it practical for the kind of small, frequent payments that would be uneconomic on a higher-fee chain. For a merchant, that is not a preference to fight — it is where the wallets and the balances already live.

The practical upshot is reach. If you accept TRC-20 USDT, you can take money from customers who hold their stablecoins on exchanges and self-custody wallets that lead with Tron, without asking them to bridge to another network first. Every extra step between "I want to pay" and "paid" is a step where a customer drops off; supporting the chain they already use removes one.

Tron carries native TRX as well, and halfin's gate accepts it. But the centre of gravity for this rail is the stablecoin: USDT on TRC-20 is the asset most Tron payers actually send, and it is the one that makes Tron worth wiring into your checkout.

• TRC-20 USDT is the most widely held stablecoin on Tron — accepting it meets payers where they are.
• Low per-transfer network fee makes small-ticket and high-frequency acceptance viable.
• Native TRX is accepted too, for customers paying in the chain's own asset.
• Fast confirmation keeps the customer's wait at the checkout short.

What halfin accepts on Tron

The Tron gate is the part of the platform that watches Tron addresses, recognises incoming deposits, and credits them once the network has confirmed them. It accepts native TRX and TRC-20 tokens; in practice the TRC-20 token that matters for almost every merchant is USDT.

Crediting on Tron follows the same discipline as every other chain halfin supports. A deposit is only marked paid after it reaches Tron's confirmation threshold, and crediting is reorg-aware — if the chain reorganises and unwinds a transaction that was tentatively seen, that is reflected rather than ignored. The amount you see as settled is an amount that actually held on the network.

USDT is a dollar-denominated stablecoin, which is the property that makes it useful here: a customer pays a number of USDT, and that number maps cleanly back to the dollar figure you billed. Pair Tron acceptance with fiat-anchored invoicing and the customer settles in TRC-20 USDT while your ledger still reconciles against the clean USD amount you started with.

Tron next to the rest of the supported assets

Tron is one acceptance rail, not the whole picture. USDT also settles on Ethereum and Solana, and a customer who holds dollars on a different chain should be able to pay there. A single fiat-anchored invoice can present several supported networks and let the customer settle in whichever one they hold — the dollar anchor stays fixed regardless of which rail they pick.

The matrix below is the real supported surface, not an aspirational list. Where a chain runs a confirmation-and-reorg discipline, that applies uniformly; the difference a payer feels between rails is mostly fee and speed.

Tron is a payout rail as well as an acceptance rail

The same property that makes Tron good for taking money — low transfer cost, fast confirmation — makes it good for sending it. If you run affiliate commissions, creator earnings, gaming withdrawals, or any operation where you pay many recipients in stablecoins, TRC-20 USDT is frequently the rail those recipients ask to be paid on. halfin sends payouts over the Tron gate, so the chain you accept on is also the chain you can disburse on.

Mass payouts on halfin are a fan-out over the single-payout API rather than a separate batch endpoint, and every payout carries a caller-supplied idempotency key. That matters most on a high-volume rail like Tron: a timeout, a worker restart, or a re-run of a payout file never double-pays a recipient, because halfin returns the payout it already created for that key instead of making a new one. You stage a run of TRC-20 USDT payouts, retry safely if something hiccups, and release them through the dashboard's approval step before any funds move.

So a Tron integration tends to be two-sided: take TRC-20 USDT at checkout, accrue it to a balance, and pay TRC-20 USDT back out to your network of recipients — all on rails where the per-transfer fee stays small even at volume.

Take a Tron payment with one call

Accepting on Tron does not require a Tron-specific integration. You create a fiat-anchored invoice the same way you would for any asset; the customer chooses to settle in TRC-20 USDT and pays the address and amount halfin presents. The amount is sent as a string — monetary values are strings end to end, never floats — and the currency is your fiat anchor.

Below is a minimal create call against the public API. The exact response shape, including how supported networks are surfaced on the invoice, is defined in the docs and the @halfin/sdk-merchant types; the point here is that one authenticated, idempotent call gives you a payable invoice a Tron payer can settle.

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": "25.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Top-up — TRC-20 USDT",
    "idempotency_key": "00000000-0000-4000-8000-000000000001"
  }'

# halfin locks the rate at activation and returns an invoice the customer
# can settle in TRC-20 USDT (or another supported network). Track the
# transition to paid via signed webhook events.
# See docs.thehalfin.com for the full request and response schema.

Where Tron fits in the platform

On the acceptance side, a Tron payment is just an invoice that settled in TRC-20 USDT, so everything downstream behaves the same way it does for any asset. When the invoice reaches paid, a signed webhook tells your backend — verify the HMAC signature before you act on it. The canonical events you will see are invoice.confirming, invoice.paid, invoice.underpaid, invoice.overpaid, and invoice.expired; a completed disbursement raises payout.completed.

On the settlement side, the TRC-20 USDT you take in accrues to a balance you can convert or pay out, and the low-fee Tron rail is a natural place to send those payouts back out. If you need a persistent receive address for Tron rather than a per-invoice flow, static deposit addresses cover that pattern. Read the networks overview for how chain-level confirmation and routing behaviour applies across the supported rails, and the dedicated USDT page for how the stablecoin behaves across Tron, Ethereum, and Solana.