Native TRX on a high-throughput, low-fee network
When a customer pays this invoice in TRX, the native Tron asset moves on the Tron blockchain itself — not a wrapped representation on another chain. halfin's Tron gate watches the address, recognises the incoming transfer, and credits it once the network has confirmed it. The customer sends from whatever Tron wallet they already hold balance in, and there is no bridge or swap between their wallet and your invoice.
Tron's appeal as a payment rail is mechanical: high throughput and a small per-transfer network fee. That combination is why so much value moves on it, and it applies to native TRX as much as to the tokens on top. For a merchant, the practical effect is that small and frequent payments stay economic — a low-value TRX payment does not get eaten by the cost of moving it, and confirmation is quick enough that the customer's wait at checkout stays short.
TRX is the chain's native asset, so there is no token contract to verify the way there is for a TRC-20 token. The trade-off versus a stablecoin is price exposure: TRX is a volatile asset, not dollar-denominated, so the amount you receive is fixed in TRX while its value in your billing currency moves. Anchor the invoice to fiat and that exposure is bounded — the rate is locked when the invoice activates, so the TRX figure the customer pays maps back to the dollar amount you billed.
- Real TRX on the Tron network — no bridge, no swap, no wrapped token.
- High throughput and a low per-transfer fee keep small-ticket payments economic.
- Fast confirmation keeps the customer's wait at checkout short.
- Fiat-anchored invoicing bounds TRX price exposure: the rate locks at activation.
Confirmation and reorg-aware crediting
A TRX transfer is not settled the instant it broadcasts. The Tron gate waits for the network's confirmation threshold before halfin marks the payment paid, and crediting is reorg-aware — if the chain reorganises and unwinds a transaction halfin was tracking, that is reflected rather than ignored. You do not implement confirmation counting or reorg handling yourself; that logic lives in the gate. The amount you see as settled is one that actually held on the canonical chain.
Practically, treat the early states as in-flight, not done. Tron confirms quickly, but quick is not the same as final — the only state that should release goods or fulfil an order is the settled one. The table below is the shape of a single TRX payment as your integration observes it, through the dashboard, the REST API, or a signed webhook.
| State | What is happening on the Tron network | What you should do |
|---|---|---|
| Awaiting payment | Invoice is live, the rate is locked, and the gate is watching for an incoming TRX transfer before the invoice expires. | Show the Tron address, the exact TRX amount, and the countdown. |
| Confirming | A matching transfer has been seen and confirmations are accumulating toward the Tron threshold. | Tell the customer the payment is in flight. Do not release goods yet. |
| Paid | The confirmation threshold is met; the billed amount settles to your balance. | Fulfil the order and reconcile against the fiat figure you billed. |
| Underpaid / overpaid | The TRX that arrived is short of, or above, the expected amount. | Request a top-up or refund the excess under your own policy — both are tracked, not lost. |
| Expired | The invoice window elapsed before a sufficient TRX payment arrived. | Re-issue at the current rate if the customer still wants to pay. |
Three ways to take a TRX payment
How you collect TRX depends on the flow. Billing a known customer for a known amount is one shape; needing a standing place for value to land is another. halfin gives you the same Tron gate underneath three surfaces, so you pick the one that fits instead of rebuilding the on-chain plumbing each time. Each option produces a Tron address and an expected TRX amount — the difference is lifecycle.
An invoice is a one-time, rate-locked request with an expiry. A static deposit address is a persistent Tron address that does not expire. Hosted checkout is a halfin-rendered page wrapped around an invoice, so you have nothing to build yourself. Most businesses use invoices for priced sales and a static address for top-ups or deposits that are not a single order.
- Invoicing — bill in your own currency and let the customer pay the equivalent in TRX. The rate locks when the invoice activates, so the figure you book never drifts while the customer fetches their wallet. Underpaid and overpaid amounts are tracked against the expected figure rather than lost.
- Hosted checkout — hand the customer a halfin-hosted link that shows the Tron address, a scannable QR, the exact TRX amount, the network, and a live status. Nothing to render yourself; the page walks the same states as the table above.
- Static deposit addresses — a persistent per-merchant Tron address that does not expire, for deposits and top-ups rather than a single priced sale. TRX arriving on it is credited the same reorg-aware way.
Where TRX sits next to TRC-20 USDT
Most Tron payers reach for TRC-20 USDT, the dollar-denominated stablecoin that dominates the network. Accepting native TRX is the complement to that, not a replacement: it covers the customer who holds and prefers the chain's own asset, on the same Tron gate, with the same confirmation-and-reorg discipline. A single fiat-anchored invoice can present both — TRX and TRC-20 USDT — and let the customer settle in whichever they hold, while the dollar anchor stays fixed regardless of which one they pick.
The difference a payer feels between the two is price behaviour, not plumbing. TRC-20 USDT tracks the dollar, so the amount maps one-to-one to what you billed. TRX is volatile, so its value in your currency moves — which is exactly why anchoring the invoice to fiat and locking the rate at activation matters more for the native asset. For the deeper view of the stablecoin side of this rail, see the Tron asset hub.
Create a TRX-payable invoice
TRX acceptance runs on the same spec-first REST API as every other asset. Authenticate with a scoped API key via the X-API-Key header, post the fiat amount and currency, and halfin locks the rate at activation, computes the payable TRX amount, and returns an invoice you can present through hosted checkout or render yourself. Send idempotency_key in the request body so a retried request never creates a duplicate invoice.
The call below is the minimal create. The amount is a string — monetary values are strings end to end, never floats — and the currency is your fiat anchor, not the asset. You do not name TRX here; the customer chooses it at pay time from the networks you support. The exact request and response fields are defined in the docs and the @halfin/sdk-merchant types.
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": "Order #5120",
"idempotency_key": "00000000-0000-4000-8000-000000000001"
}'
# The customer chooses TRX at pay time. halfin locks the rate at
# activation, pins the payable TRX amount, and credits the deposit
# reorg-aware once it meets the Tron confirmation threshold. Track
# the transition to paid via signed webhook events; verify the HMAC
# signature first. See docs.thehalfin.com for the full schema.