Chains & assets
InfraIO Pay is stablecoin-first and multi-chain: eight EVM networks plus TRON, Solana and TON. The matrix below lists the networks InfraIO Pay supports. TRON, Solana and TON are coming soon to production.
Mainnet
| Chain | Chain ID | Native | USDC | USDT | Confirmations | Min order |
|---|---|---|---|---|---|---|
| Ethereum | 1 | ETH | ✓ (ERC-20) | ✓ (ERC-20) | 12 | $5.00 |
| Base | 8453 | ETH | ✓ (ERC-20) | — | 10 | $1.00 |
| Polygon | 137 | POL | ✓ (ERC-20) | ✓ (ERC-20) | 5 | $1.00 |
| BSC | 56 | BNB | ✓ (18-decimal) | ✓ (18-decimal) | 5 | $1.00 |
| Arbitrum | 42161 | ETH | ✓ (ERC-20) | ✓ (ERC-20) | 5 | $1.00 |
| Optimism | 10 | ETH | ✓ (ERC-20) | ✓ (ERC-20) | 5 | $1.00 |
| ZKsync Era | 324 | ETH | — | — | 5 | $1.00 |
| Mantle | 5000 | MNT | — | — | 5 | $1.00 |
BSC USDC + USDT use 18 decimals, not 6 like everywhere else. If you compute token amounts yourself, account for this. The SDK and hosted checkout handle it for you.
“Min order” is the minimum order amount in USD. The defaults are
$1.00 on mainnet and $0.50 on testnet, with Ethereum at $5 because
network fees (gas) on Ethereum would outweigh smaller orders. The minimum can differ per network.
Orders below it are rejected with AMOUNT_BELOW_MINIMUM (HTTP 400), and
details.floor_usd carries the minimum for that network so you can show it to the buyer.
TRON, Solana and TON
Coming soon. TRON, Solana and TON are not yet available in production.
| Chain | Chain ID | Native | USDC | USDT | Confirmations | Min order |
|---|---|---|---|---|---|---|
| TRON | 728126428 | TRX | — | ✓ (TRC-20) | 19 | $1.00 |
| Solana | 1151111081099710 | SOL | ✓ (SPL) | ✓ (SPL) | 32 | $1.00 |
| TON | 607000000000000 | TON | — | ✓ (Jetton) | 1 | $1.00 |
Solana and TON have no EVM chain ID, so the IDs above are the internal identifiers the API uses for them. Every stablecoin listed here uses 6 decimals. TON finalizes each block, so a single confirmation is final.
Testnet
| Chain | Chain ID | Native | Confirmations | Min order |
|---|---|---|---|---|
| Ethereum Sepolia | 11155111 | ETH | 1 | $0.50 |
| Base Sepolia | 84532 | ETH | 1 | $0.50 |
| Polygon Amoy | 80002 | POL | 1 | $0.50 |
| BNB Smart Chain Testnet | 97 | tBNB | 1 | $0.50 |
| Arbitrum Sepolia | 421614 | ETH | 1 | $0.50 |
| OP Sepolia | 11155420 | ETH | 1 | $0.50 |
| Mantle Sepolia | 5003 | MNT | 1 | $0.50 |
| ZKsync Sepolia | 300 | ETH | 1 | $0.50 |
Test mode uses real testnets, not a mock chain. To trigger a test payment you need actual testnet funds — pull from a faucet (e.g., sepoliafaucet.com , coinbase.com/faucets ) and send to the deposit address the hosted checkout generates.
TRON Nile, Solana Devnet, TON Testnet
| Chain | Chain ID | Native | Test tokens | Confirmations | Min order |
|---|---|---|---|---|---|
| TRON Nile | 3448148188 | TRX | USDT, IUSD | 19 | $0.50 |
| Solana Devnet | 1151111081099711 | SOL | USDC, IUSD | 32 | $0.50 |
| TON Testnet | 607000000000003 | TON | IUSD | 1 | $0.50 |
Test mode on these networks also uses real testnets. IUSD is the IUSD test stablecoin, a test-only token with no real value.
Currency codes used in the API
currency (on the top-level body and each line item) is the
order’s display currency — what the buyer sees as the amount.
Today the platform accepts a single code at create time:
"USD"— the only supported value. BothPOST /v1/ordersandPOST /b2b/v1/checkout-sessions/quickreject anything else withINVALID_INPUT(“unsupported currency”).GET /v1/supported/currenciesreturns the current list.
The on-chain asset the buyer settles in (USDC, USDT, …) is not
the currency field. It’s chosen by the buyer on the checkout page
from the chain × token combinations you’ve enabled in your merchant
config, and is returned to you on the PaymentIntent and webhook
payload as settlement_token (symbol + chain). Native coins used to pay network fees (gas)
(ETH, BNB, POL, MNT, TRX, SOL, TON) are chain metadata only — not valid
payment currencies.
The chain itself isn’t specified at create time either — same reason: the buyer picks the combination on the checkout page.
Confirmations vs finality
The “Confirmations” column above is the number of blocks InfraIO Pay waits
before moving a PaymentIntent to SETTLED and sending
payment.settled. The counts are chosen per network to make a reorg
unlikely:
- Ethereum mainnet uses 12 confirmations.
- L2s use lower counts that reflect each network’s own reorg risk.
- Testnets use 1 confirmation to keep testing fast. Don’t treat test payments as mainnet-grade finality.
If you need stricter (or looser) confirmations for a specific chain, the per-chain count is configurable on the merchant account — talk to your account contact.
Enabling chains for your merchant
A new account starts with a broad set of testnets. Mainnet networks become available when you have completed account verification and added a treasury wallet for the network (you sign a message to prove you control it).
Payments go straight to your treasury wallets — InfraIO Pay never holds your funds.
Enable additional chains from Settings → Networks in the merchant dashboard.
Per-order deposit addresses (EVM)
EVM networks use a per-order deposit address (CREATE2). Each address is unique to one checkout and is generated in advance. You don’t create or fund anything: you get the address back on the PaymentIntent and show it to the buyer.
- Two intents for the same merchant get different addresses — no collisions across buyers.
- The buyer sees the address on the checkout page immediately.
- Buyers never pay a setup network fee. Funds are forwarded automatically to your treasury wallet, with no separate step for you to track.
Practical implications for integrators:
- The
deposit_addressreturned on a PaymentIntent is a regular EVM address — you can show it as a QR code, scan it, send to it from any wallet. No special client support needed. - Sending to the address before the intent expires settles the order. Late deposits (sent after expiry) can sometimes be forwarded to your treasury wallet, but this isn’t guaranteed, so don’t rely on it.
- Each address is single-use per intent. If a buyer needs a second attempt, mint a new checkout session — you’ll get a fresh address.
Direct-to-wallet networks
TRON, Solana and TON work differently from EVM. There is no per-order deposit address and no sweep step (sweep means moving funds from the deposit address to your treasury wallet). This is the Direct to wallet model: the buyer’s wallet pays your treasury wallet directly. When the platform fee is collected on-chain, it is split off within that same payment (your share plus the fee). Otherwise the fee is billed from your prepaid credit. The platform decides which of the two applies, not the merchant.
| Network | How the buyer pays |
|---|---|
| TRON | TronLink. Checkout opens inside TronLink and the buyer approves the transfer. |
| Solana | Solana Pay. The buyer scans a QR code with Phantom, Solflare or any Solana Pay wallet; the wallet fetches the transaction from the checkout. |
| TON | TON Connect (Tonkeeper, Telegram Wallet, MyTonWallet). The buyer approves a single request; the transfers carry an order reference comment that identifies the payment. |
Before buyers can choose one of these networks, add a treasury wallet for that network family (EVM, TRON, Solana or TON) in the merchant dashboard. Accepted address formats:
- TRON — base58 address starting with
T… - Solana — base58 public key
- TON — user-friendly
UQ…/EQ…(or raw0:…), basechain only
There is no deposit address to show on these networks, so let the hosted checkout drive the payment.
What’s NOT supported today
- Bitcoin / Lightning. Not supported.
- Native-currency payments. Buyers pay in stablecoins only. Native coins (ETH, BNB, POL, MNT, TRX, SOL, TON) are not accepted as payment on any network.
- Other stablecoins (USDe, FDUSD, …). Contact support to request an additional token on a network that is already enabled.
What’s next
- Concepts → Sessions — how chain/asset selection happens at checkout time.
- Get started → Introduction — the big-picture model.