Networks: confirmations & TTL
Confirmation thresholds per network (TRON, EVM incl. Ethereum/BSC, BTC/LTC/DOGE/BCH, XRP, NEAR, Solana, TON, Monero) and invoice TTL rules: mempool waiting, expiry and rescan behaviour.
ZeroKYC Pay accepts payments on several blockchains. Each network has its own finality rules, so the number of confirmations required before an invoice is marked confirmed differs. This guide lists the exact production thresholds and the invoice TTL rules.
Confirmation thresholds
An invoice flips from pending to confirmed after the payment option's network reaches its confirmation threshold:
| Asset | Network | API Asset ID | Confirmations required | Typical time |
|---|---|---|---|---|
| USDT (TRC-20) | TRON | USDT_TRON | 20 | ~1 minute |
| TRX | TRON | TRX | 20 | ~1 minute |
| USDC (Polygon) | Polygon | USDC_POLYGON | 50 | ~5 minutes |
| USDT (Polygon) | Polygon | USDT_POLYGON | 50 | ~5 minutes |
| USDC (Arbitrum) | Arbitrum | USDC_ARBITRUM | 40 | ~5 minutes |
| USDT (Arbitrum) | Arbitrum | USDT_ARBITRUM | 40 | ~5 minutes |
| ETH | Ethereum | ETH | 12 | ~2.5 minutes |
| USDT (Ethereum) | Ethereum | USDT_ETHEREUM | 12 | ~2.5 minutes |
| USDT (BSC) | BNB Smart Chain | USDT_BSC | 15 | ~45 seconds |
| BNB | BNB Smart Chain | BNB | 15 | ~45 seconds |
| BTC | Bitcoin | BTC | 2 | ~20 minutes |
| LTC | Litecoin | LTC | 6 | ~15 minutes |
| DOGE | Dogecoin | DOGE | 20 | ~20 minutes |
| BCH | Bitcoin Cash | BCH | 3 | ~30 minutes |
| XMR | Monero | XMR | 10 | ~20 minutes |
| TON | TON | TON | 1 | seconds |
| USDT (Solana) | Solana | USDT_SOL | 32 | ~13 seconds |
| USDC (Solana) | Solana | USDC_SOL | 32 | ~13 seconds |
| SOL | Solana | SOL | 32 | ~13 seconds |
| XRP | XRP Ledger | XRP | 3 | ~12 seconds |
| NEAR | NEAR Protocol | NEAR | 3 | ~3 seconds |
| USDT (TON jetton) | TON | USDT_TON | 1 | seconds |
Where these come from: The thresholds are enforced by the ZeroKYC Pay detection engine (
app/domain/assets.py). This table reflects the production configuration as of v1.
TON-based payments (TON and USDT-TON) additionally require a memo/tag — the option's payment_url_extra field. The hosted checkout and the payment QR encode it automatically; if you build your own payment flow, a transfer without the memo is unrecoverable. See Invoice lifecycle.
Invoice TTL
Every invoice has a time-to-live. The default is 360 minutes (6 hours); you can set your own between 10 minutes and 72 hours (4320 minutes) via the ttl_minutes field when creating an invoice.
If the payment is already visible in the mempool when the TTL ends, the invoice still confirms normally — the expiry rule only applies to payments that never arrived.
Underpaid payments: A payment below the expected amount marks the invoice
underpaidinstead ofconfirmed. Handle thepayment.underpaidwebhook and decide whether to accept, refund or contact the customer.
Rate rules
Stablecoins are pegged for invoicing: USDT (all networks) is exactly 1:1 against USD invoices, other assets use the market rate refreshed automatically. Non-USD base currencies convert at the prevailing rate.
What's next
- Invoice lifecycle — statuses, detection windows and which webhook fires when.
- Quickstart — Create your first invoice in one REST call.
- Webhooks reference — Webhook event lifecycle and delivery guarantees.
- Direct checkout guide — Non-custodial direct payments to your own wallet.