Cadenas y activos
InfraIO Pay es EVM-first y stablecoin-first. Cada cadena soportada
está configurada en el registro networks.json de payment-service;
la matriz de abajo refleja lo que está activo en test y mainnet hoy.
Mainnet
| Cadena | Chain ID | Nativa | USDC | USDT | Confirmaciones | Orden mín. |
|---|---|---|---|---|---|---|
| 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-decimales) | ✓ (18-decimales) | 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 |
USDC + USDT en BSC usan 18 decimales, no 6 como en el resto. Si por alguna razón calculas importes en el lado cliente, tenlo en cuenta: si no, los campos de importe del SDK lo manejan.
“Orden mín.” es el piso en USD aplicado al crear el payment-intent.
Los valores por defecto enviados hoy son $1.00 mainnet / $0.50
testnet, con Ethereum subido a $5 porque el gas de L1 eclipsa
órdenes menores. Admin ops puede sobreescribir por red: las
órdenes por debajo del piso se rechazan con AMOUNT_BELOW_MINIMUM
(HTTP 400), y details.floor_usd lleva el valor configurado
efectivo para que tu FE pueda mostrarlo.
Testnet
| Cadena | Chain ID | Nativa | Confirmaciones | Orden mín. |
|---|---|---|---|---|
| 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 |
El modo de prueba usa testnets reales, no una cadena simulada. Para disparar un pago de prueba necesitas fondos testnet reales: obtén desde un faucet (p. ej., sepoliafaucet.com , coinbase.com/faucets ) y envía a la dirección de depósito que la página de checkout genera.
Códigos de moneda usados en la API
currency (en el body de nivel superior y en cada line item) es la
moneda de visualización de la orden: lo que el comprador ve
como importe. Hoy la plataforma acepta un único código al crear:
"USD": el único valor para el queIsSupportedCurrencydevuelve true enpayment-service. TantoPOST /v1/orderscomoPOST /b2b/v1/checkout-sessions/quickrechazan cualquier otro conINVALID_INPUT(“unsupported currency”). La lista anunciada vive enGET /v1/supported/currenciespara que el enum del servidor y tu cliente nunca se desincronicen.
El activo on-chain en el que el comprador liquida (USDC, USDT, …)
no es el campo currency. Lo elige el comprador en la página de
checkout entre las combinaciones cadena × token que has habilitado
en tu config de comerciante, y aparece de vuelta en el PaymentIntent
- payload del webhook como
settlement_token(símbolo + cadena). Los tokens de gas nativos (ETH,BNB,POL,MNT) son solo metadatos de cadena, no monedas de pago válidas.
La cadena en sí tampoco se especifica al crear: misma razón, el comprador elige la combinación en la página de checkout.
Confirmaciones vs finalidad
La columna “Confirmaciones” de arriba es el número de bloques que
el chain watcher espera antes de cambiar un PaymentIntent a
SETTLED y disparar payment.settled. Los valores por defecto
están afinados para dar finalidad probabilística en cada cadena a
profundidades típicas de reorg:
- El 12 de Ethereum mainnet es el valor que la mayoría de exchanges usan post-Merge.
- Las L2 liquidan más rápido pero eventualmente heredan la finalidad de Ethereum: el conteo por cadena refleja el riesgo de reorg propio de la L2, no el de la L1.
- Las testnets están en 1 conf para mantener rápido el ciclo de dev; no extrapoles a seguridad de grado mainnet en tu entorno de dev.
Si necesitas confirmaciones más estrictas (o más laxas) para una cadena específica, el conteo por cadena es configurable en la cuenta del comerciante: habla con tu contacto de cuenta.
Habilitar cadenas para tu comerciante
Por defecto un nuevo comerciante tiene un set permisivo de cadenas en testnet y un set más estrecho en mainnet. El set de mainnet está condicionado a:
- KYB completado
- Attestation de wallet de tesorería por cadena (firmas un mensaje probando custodia)
Habilita cadenas adicionales desde Settings → Networks en el dashboard del comerciante.
Direcciones de depósito deterministas
Las direcciones de depósito EVM son deterministas por checkout: la plataforma las deriva de antemano a partir de parámetros internos vinculados al comerciante, la orden y el intent. No precreas ni financias nada: solo recibes la dirección de vuelta en el PaymentIntent y se la das al comprador.
- Dos intents para el mismo comerciante obtienen direcciones diferentes: no hay colisiones entre compradores.
- La dirección aparece en la página de checkout antes de cualquier setup on-chain, así que el comprador ve un destino inmediatamente.
- Los compradores nunca pagan gas de setup. Los fondos se liquidan directamente en la tesorería del comerciante sin un paso de sweep separado que el comerciante tenga que rastrear.
Implicaciones prácticas para integradores:
- La
deposit_addressdevuelta en un PaymentIntent es una dirección EVM regular: puedes mostrarla como código QR, escanearla, enviarle desde cualquier wallet. No se necesita soporte especial del cliente. - Enviar a la dirección antes de que el intent expire liquida la orden. Enviar tras la expiración se recupera con mejor esfuerzo: la plataforma puede re-sweep depósitos tardíos en algunos casos, pero nunca asumas que los fondos tardíos están seguros.
- Cada dirección es de un solo uso por intent. Si un comprador necesita un segundo intento, emite una nueva sesión de checkout: obtendrás una dirección fresca.
Lo que NO se soporta hoy
- Tron / TRC-20. Solicitado frecuentemente para USDT-TRC20; en el roadmap, no activo.
- Solana / SPL. En el roadmap.
- Bitcoin / Lightning. No en el roadmap.
- Stablecoins nativas de Layer-1 (USDe, FDUSD, …). Añade vía solicitud al dashboard; la cadena subyacente solo necesita estar habilitada.
Qué sigue
- Conceptos → Sesiones: cómo ocurre la selección de cadena/activo en el momento del checkout.
- Empezar → Introducción: el modelo general.