9 networks. Native coins,
USDT and USDC
Customers pay with what they already hold. You choose which assets to accept, in the dashboard or per invoice via allowed_assets.
| Network | Coin | USDT | USDC | When it's “paid” |
|---|---|---|---|---|
 Bitcoin | BTC | — | — | 2 blocks; 3 for large amounts |
 Litecoin | LTC | — | — | 6 blocks |
 Ethereum | ETH | ERC-20 | ERC-20 | finalized; 12 blocks for small amounts |
 BNB Smart Chain | BNB | BEP-20 | BEP-20 | 15 blocks |
 Polygon PoS | POL | yes | native | finalized |
 Base | ETH | — | native | finalized; 20 blocks for small amounts |
 Arbitrum One | ETH | yes | native | finalized; 20 blocks for small amounts |
 TRON | TRX | TRC-20 | — | 19 blocks (solidified) |
 Solana | SOL | SPL | SPL | commitment finalized |
These are default confirmation thresholds, and the operator can tune them: the larger the amount, the more confirmations. The exact number for a given payment is returned on the invoice as required_confirmations.
Tokens by contract, not by name
USDT is credited only if the transfer comes from an allowlisted contract address. A counterfeit coin with the same name won't change the status.
Rates: median of three exchanges
Kraken, Coinbase and Bitstamp; quotes no older than 2 minutes and no more than 1% apart. If the sources disagree, no amount in a volatile asset is quoted.
Minimum amount
Each asset has its own minimum (min_amount in GET /v1/assets). If the invoice amount is below it, that asset simply isn't offered on the invoice.
Narrow the choice with one field
Without allowed_assets, the customer sees every asset enabled in your dashboard. With it, they see the intersection of your list and what's available.
An asset ID combines the coin and network: USDT-TRON, USDC-BASE, USDT-ETH, USDC-SOL, BTC, ETH, ETH-ARB… For the full list available to you, call GET /v1/assets.
{
"order_id": "ORDER-1001",
"price_amount": "49.99",
"price_currency": "USD",
"allowed_assets": ["USDT-TRON", "USDC-BASE", "BTC"]
}