Cryptocurrencies you can accept with halfin

You don't pick a blockchain — your customer does. They already hold USDT on Tron, or USDC on Base, or BTC in cold storage, and they want to pay with that. halfin accepts the assets people actually carry, on the networks they actually use, and settles every one of them against the fiat amount you billed. This page is the index: what each asset is, where it settles, and which one to reach for first.

The short answer: stablecoins for billing, native coins for reach

There are two kinds of asset on this page, and the distinction decides most of your integration. A stablecoin is a token pegged to a fiat currency — USDT and USDC both track the US dollar — so one unit is meant to stay worth about one dollar. A native coin is the base asset of its chain: BTC on Bitcoin, ETH on Ethereum, SOL on Solana, XRP on the XRP Ledger. Its value floats against the dollar, sometimes by a lot in a single day.

If you price in dollars or euros and want your books to stay clean, stablecoins are the lowest-friction path. A customer paying 49 USDT settles to roughly the 49 USD you billed, with almost no exchange-rate drift between the moment you quote and the moment they confirm. That is why most fiat-anchored billing — subscriptions, invoices, top-ups — runs on USDT and USDC.

Native coins are about reach, not stability. A Bitcoin-only customer, or someone who only holds ETH or SOL, can still pay you, and halfin still settles them against your billed fiat figure — the invoice locks the conversion rate at activation, so a moving BTC price doesn't leave you short. You accept the volatile asset; the fiat anchor absorbs the volatility. Reach for native coins when your audience holds them, not as your default billing rail.

Every asset, every network, in one table

An asset is not a single thing on a single chain. USDT on Tron and USDT on Ethereum are the same dollar token issued on different networks, and they are not interchangeable in flight — a payment sent on Tron arrives on Tron, with Tron's confirmation behavior and Tron's fee profile. So when you accept an asset, you are really accepting an asset-and-network pair.

The matrix below is the real supported surface — only gates that actually run. It is the same set every halfin invoice draws from, so a customer can only ever be shown a network you can actually credit. Crediting across all of them is reorg-aware and waits for each chain's own confirmation threshold before an amount counts as settled.

How merchants actually search for this — and where to land

People rarely ask "which chain should I support." They ask "can I accept USDT," "do you take Bitcoin," "is USDC on Base supported." The way you choose an asset usually maps to one of a few concrete situations, so here is how to read the list by intent rather than by alphabet.

• You bill in dollars and want clean reconciliation — start with USDT and USDC. They settle close to the fiat amount you charged, so a 49 USD invoice lands as roughly 49 dollars of stablecoin.
• Your customers are fee-sensitive on small amounts — TRC-20 USDT on Tron and stablecoins on Solana keep network costs low, which matters when the ticket size is a top-up rather than an enterprise invoice.
• Your audience is EVM-native — USDC and native assets on Base, Arbitrum, Polygon, and BNB Smart Chain meet people on the L2 they already bridge to and hold value on.
• You need to reach Bitcoin holders — accept BTC natively so someone paying from cold storage isn't forced to first swap into a token.
• You want the broadest single page to point a customer at — a halfin invoice can present the supported networks together and let the payer settle in whichever asset they hold.

Same asset, different network — what changes

Choosing the network is not cosmetic. The asset's dollar value is the same, but the experience around the payment differs by chain, and those differences are worth knowing before you decide what to surface to a customer.

Confirmation time is the first difference. Each chain has its own threshold before halfin marks a payment final, because each chain has a different cost to reorganize recent history. A high-throughput chain confirms a payment in seconds; Bitcoin deliberately takes longer in exchange for stronger settlement assurance. halfin applies the per-chain threshold for you — you don't tune it — but it explains why one customer sees "paid" almost immediately and another waits a few minutes.

Fee profile is the second. "Low-fee" here describes the network, never a halfin rate: moving USDT on Tron or a token on Solana costs the payer very little in network fees, while the same token on Ethereum mainnet can cost more at busy times. For small payments, steering customers toward a low-fee network is often the difference between a completed payment and an abandoned one.

Finality model is the third, and it is why reorg-awareness matters. A chain reorganization can briefly unwind a recent transaction. halfin reflects that rather than ignoring it: an amount is only reported as settled once it has held to the chain's threshold, so the figure you fulfill against is one that actually stuck.

You accept an asset with one API call

Accepting any asset on this page is the same operation: create a fiat-anchored invoice and let the customer settle it in whatever they hold. You don't enable assets one transaction at a time — you bill in your currency, and the supported matrix above is what the payer can choose from. The example below creates an invoice priced in dollars; the customer can pay it in USDT, USDC, BTC, ETH, SOL, XRP, or a supported native asset, and it all reconciles back to the same figure.

The fiat amount is sent as a string — monetary values are strings end to end, never floats — and an idempotency key makes a retried request safe to repeat without creating a duplicate. The full request and response schemas live in the docs; the point here is that one authenticated call gives you an invoice payable in every asset on this page.

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": "49.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Pro plan — March",
    "idempotency_key": "00000000-0000-4000-8000-000000000002"
  }'

# Billed in fiat with no asset pinned, so the payer chooses the
# asset/network at activation — USDT, USDC, BTC, ETH, SOL, XRP, or a
# supported native asset. halfin locks the rate at activation. See
# docs.thehalfin.com for the full request and response schema.

Where the asset list fits in the platform

The assets here are the input to everything downstream. The network a customer pays on is what the invoice presents and what hosted checkout renders; the asset that lands accrues to a balance you can convert between currencies or pay out; a refund returns value on a supported rail. So the choice you make on this page propagates — picking stablecoins for billing keeps the whole chain, from invoice to settlement to payout, denominated close to the dollar.

If you want the network-level view — confirmation thresholds, fee character, and finality side by side — the networks page lays the chains out directly. If you came here to confirm a specific coin, the per-asset pages go deeper on Bitcoin, USDT, and USDC, including which networks each one settles on and when to prefer it.