Why a customer pays USDT on Solana
If a customer's USDT lives on Solana, asking them to move it to another chain before they can pay you is friction you don't need. They would have to bridge the token, pay a fee to do it, and wait — and every one of those steps is a place the payment can fall apart. Accepting USDT natively on Solana lets that customer pay from the wallet they already have open, with the balance they already hold.
Solana's appeal for a stablecoin payment is speed and cost. The network settles transfers quickly and a small SPL transfer carries a low network fee, so a customer paying a modest invoice isn't watching a confirmation crawl or losing a chunk of the payment to fees. For a merchant whose audience skews toward the Solana ecosystem — trading tools, on-chain apps, anything where the customer is already transacting on Solana — this is the rail a lot 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 Solana specifically, you get that dollar-stable unit as an SPL token on a fast, cheap rail, which is exactly what a Solana-native payer reaches for when they want to spend dollars on-chain.
How halfin handles an SPL USDT payment
You don't run a Solana-specific integration. Accepting USDT on Solana is the ordinary halfin invoicing flow: you create a fiat-anchored invoice, and SPL USDT is one of the networks the customer can settle it on. halfin generates the Solana deposit address, watches the chain for the payment, and credits it once it has held to Solana's confirmation threshold.
Crediting is reorg-aware. halfin does not treat a freshly-seen transfer as final the instant it appears — it waits for Solana's per-chain confirmation threshold before the invoice is marked paid, so a transaction that gets unwound 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 tracks the dollar closely, and halfin maps your USD figure to the payable SPL 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.
- Fast settlement — Solana clears transfers quickly, so a payer isn't waiting on a slow confirmation.
- Low network fees — a small SPL transfer stays cheap for the payer, protecting completion rates on low-ticket payments.
- Reorg-aware credit — the invoice is marked paid only after Solana's confirmation threshold, not on first sight.
- Fiat-anchored — you bill USD, the customer pays the equivalent in SPL USDT, your ledger records the dollar figure.
Solana next to the other USDT rails
USDT on halfin settles on three networks, and Solana 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 Solana arrives on Solana. The table below places SPL 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 |
|---|---|---|---|
| Solana | SPL | Fast, low-fee settlement. | Payers already holding USDT in the Solana ecosystem. |
| 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. |
Take an SPL USDT payment with one API call
There is no Solana-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 Solana — 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 Solana 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 SPL 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": "30.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Credits 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 Solana (SPL) 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 Solana, not just accepting it
Solana's speed and low fees cut the other way too. If you owe a stablecoin to a partner, affiliate, or supplier on Solana, single and mass payouts send USDT back out as an SPL transfer — and the same per-transfer economics that make Solana attractive to your customers make it attractive for disbursing. 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 SPL USDT does not lock you into SPL 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 SPL USDT sits in the same ledger as every other asset you handle.