Accept USDT payments across Tron, Ethereum and Solana

USDT is the stablecoin most of your customers already hold, and the one they reach for when they want to pay without watching a price chart. halfin lets you accept it on the three networks where Tether actually has the liquidity that matters for payments — Tron (TRC-20), Ethereum (ERC-20) and Solana — while you keep pricing in dollars. You bill a USD amount, the customer pays the equivalent in USDT on whichever of those networks suits them, and the figure that lands in your ledger is the dollar figure you started with.

Why merchants ask for USDT first

When a customer says they want to "pay in crypto," they usually mean USDT. It is the default unit of account across most exchanges and self-custody wallets, and because it tracks the US dollar one-to-one, neither side has to absorb a price swing between the moment you quote and the moment they pay. For a merchant, that removes the single biggest objection to crypto payments: "what if the coin moves before it clears."

USDT is a dollar-denominated stablecoin issued by Tether. It is not a coin you speculate on; it is a way to move dollars over public networks, fast, and across borders that card rails handle poorly or not at all. That is exactly why it shows up at checkout — your customer holds dollars on-chain and wants to spend them, and you want to be paid in something stable.

halfin treats USDT as a settlement asset, not a bet. You never have to take a view on its price, because your invoice is anchored to fiat. The customer is shown a concrete USDT amount; you see the USD figure you billed. The two stay in lockstep for the life of the invoice.

Three networks, one balance

Tether is issued natively on several chains, but the three that matter for payments — and the only three halfin accepts USDT on — are Tron, Ethereum and Solana. They are not interchangeable from the customer's point of view: the same dollar of USDT costs a different network fee and confirms on a different timescale depending on which rail it rides. halfin exposes all three so the customer can pay from wherever they already hold the token, and credits every one of them to the same dollar-denominated balance.

TRC-20 — USDT on Tron — is the rail most customers default to, because Tron's network fees are low and its throughput is high, which keeps a small stablecoin transfer cheap. ERC-20 — USDT on Ethereum — is the most widely integrated form and what many institutional or EVM-native payers hold, at the cost of Ethereum's variable network fees. USDT on Solana settles quickly and cheaply and suits payers already living in the Solana ecosystem.

Whichever network the customer chooses, crediting is reorg-aware and waits for that chain's confirmation threshold before the invoice is marked paid. You do not maintain three integrations or three reconciliation flows — you maintain one, against the fiat amount, and let the customer pick the rail.

• Tron (TRC-20) — commonly chosen for low network fees and high throughput; the default for most stablecoin payers.
• Ethereum (ERC-20) — the most broadly supported form of USDT; favored by EVM-native and institutional wallets.
• Solana — fast, low-fee settlement for payers already in the Solana ecosystem.
• Every network credits to the same dollar-anchored balance — one reconciliation, not three.

USDT networks at a glance

The table below is the real supported surface for USDT on halfin — these three networks and no others. If a customer asks to pay USDT on a chain that is not listed here, halfin does not accept it, because there is no gate for it. Confirmation behavior is per-chain: halfin waits for the network-appropriate number of confirmations and reflects reorganizations rather than ignoring them.

Fiat-anchored: bill in dollars, get paid in USDT

USDT tracks the dollar, but "tracks" is not "is" — the live USDT/USD rate sits very near one, not exactly on it, and it moves in small amounts. halfin does not ask you to reason about that. You create an invoice with a fiat amount and currency; halfin maps that USD figure to the payable USDT amount using the live rate and locks it when the invoice activates. The customer sees a concrete number to send, and your books record the dollar amount you billed.

Because the quote is pinned at activation rather than at draft time, the amount the customer is shown does not drift while they fetch their wallet and confirm. Each invoice carries an expiry; if the payment window elapses, the invoice expires instead of silently re-pricing against a newer rate, and you decide whether to re-issue. If a customer underpays — for instance, an exchange skims a withdrawal fee on the way out — the shortfall is recorded against the invoice rather than stranded, and an overpayment is recorded the same way, so the excess stays visible and accountable.

The result is that USDT behaves, in your ledger, like the dollars you priced in. You get the cross-border reach and speed of a stablecoin without inheriting the job of converting token amounts back to fiat at month-end.

Take a USDT payment with one API call

Accepting USDT does not require a USDT-specific integration. It is the same invoicing flow as every other asset halfin supports: you post a fiat amount and currency to the public REST API with a scoped API key, and halfin returns a payable invoice you present through hosted checkout or render yourself. The customer chooses USDT on Tron, Ethereum or Solana at the point of payment; you do not have to decide the network for them when you create the invoice.

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 settle in 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": "100.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "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), Ethereum
# (ERC-20) or Solana. Track state via signed webhook events; verify the
# HMAC signature before acting. Full response schema at docs.thehalfin.com.

Where USDT fits in the platform

Accepting USDT is the front door; what you do with the balance afterward is the rest of the platform. Paid USDT invoices accrue to a balance you can convert to another asset or pay out. If you owe a stablecoin to a partner, affiliate or supplier, single and mass payouts send USDT back out on the same networks. If a customer is owed money back, refunds handle the return path.

On the conversion side, a balance that arrives as USDT on Tron does not lock you into USDT on Tron — balance conversion lets you rebalance into another asset or network as your treasury needs. And because the whole flow is fiat-anchored, USDT, USDC and the native chain assets sit side by side in the same ledger, settled to the same dollar figures, rather than as separate pots you have to reconcile by hand.