Skip to Content
EmpezarIntroducción

Introducción

La forma de un pago

Un comerciante integrando InfraIO Pay trata con cuatro piezas en movimiento:

Sesión de checkout

Creas una sesión en el lado del servidor con artículos de línea y totales. La respuesta lleva una session_key (cst_…) y una checkout_url. Las sesiones tienen TTL (por defecto 30 min) y son de un solo uso.

Página de checkout alojada

Cargas nuestro SDK de navegador y abres la sesión: popup, redirect o iframe incrustado. El comprador elige una combinación cadena × activo (USDT en Polygon, ETH en Base, …), ve una dirección de depósito generada + QR, y envía fondos desde su wallet.

Confirmación de pago

El payment-service vigila la cadena relevante para transferencias entrantes que coincidan con la dirección de depósito de la sesión. Una vez que se alcanza el número de confirmaciones configurado (p. ej. 12 en Ethereum mainnet, 5 en Polygon: ver Cadenas y activos), el PaymentIntent subyacente se mueve a SETTLED y la Orden padre se mueve a PAID.

Webhook

Enviamos (mediante POST) un evento firmado payment.settled a tu URL de webhook registrada. Tu servidor verifica la firma, se vincula a tu propia orden vía external_ref y procede con el cumplimiento del pedido.

El modelo de datos en un diagrama

CheckoutSession  ←  1:1  →  Order  ←  1:N  →  PaymentIntent
   (con TTL)                (permanente)       (uno por intento)

Piensas en Órdenes para el cumplimiento del pedido, creas Sesiones para cobrar pago, y el sistema gestiona PaymentIntents detrás de escena para reintentos / selección de cadena.

Lo que manejamos vs. lo que manejas tú

InfraIO Pay manejaTú manejas
UI de checkout alojado (dirección de depósito, QR, selector de activos)Creación de catálogo + Orden en tu DB
Monitorización de cadena + lógica de confirmación a través de 8 cadenas EVMReceptor de webhook + verificación de firma
Checkout multi-activo (USDT, USDC, ETH/BNB/POL/MNT nativos por cadena)Mapeo de nuestro order_id ↔ tu ID de orden vía external_ref
Contabilidad de reembolsos (máquina de estados, dashboard, API)Firma + difusión de la tx de reembolso on-chain
Claves de modo de prueba + webhooks de prueba aisladosFinanciación de wallets testnet desde faucets

No tenemos custodia de los fondos del comerciante. Las transferencias comprador-a-comerciante ocurren directamente on-chain; nosotros somos la capa de indexador + reconciliación que te dice cuándo se confirmó la transferencia.

Modo de prueba vs modo live

Cada cuenta empieza en modo de prueba. Las claves de prueba llevan prefijo pk_test_ / sk_test_. Las claves live (pk_live_ / sk_live_) están condicionadas a:

  1. KYB completado
  2. Certificación de wallet de tesorería (firmas un mensaje probando que controlas la wallet de destino en cada cadena en la que quieres recibir)

La misma URL base de la API sirve ambas: el entorno se determina por el prefijo de la clave, no por la URL. El modo de prueba corre contra testnets reales (Sepolia, Base Sepolia, BSC Testnet, etc.): no hay cadena simulada. Para disparar un pago de prueba necesitas fondos testnet reales desde un faucet.

Lo que InfraIO Pay no es

  • No es un custodio. Los fondos se mueven comprador → wallet de comerciante on-chain directamente. Nunca tenemos saldo.
  • No es un proveedor de wallets. Los clientes traen su propia wallet; el checkout alojado tiene una opción WalletConnect integrada pero no custodia nativa.
  • No es una pasarela fiat-cripto. Los compradores pagan en el activo cripto que tienen; no convertimos.
  • No es un gateway de Tron o Solana hoy. EVM-first. Ver Cadenas y activos para la matriz actualizada.

Qué sigue

BienvenidoInicio rápido