Inglés
Alemán
Español
Francés
Turco
Volver a Guías
Cómo Funciona una Pasarela de Pago Cripto: Guía Técnica 2026
Una pasarela cripto parece simple por fuera (generar QR, esperar pago) pero por dentro es rica. Sustituye la red de tarjeta, el procesador y la cuenta mercantil por una blockchain, lo que plantea un conjunto distinto de problemas de ingeniería: rate locks, reorganizaciones de cadena, políticas de confirmación, gestión de claves y off-ramp a euros.
Esta guía recorre el ciclo técnico completo (API de facturas, rate lock, mempool, confirmaciones, webhooks, modelos de custodia y cómo los fondos on-chain se convierten en euros en una cuenta española) para equipos de ingeniería, producto y finanzas.
Impulse su negocio aceptando pagos criptográficos
Arquitectura de alto nivel
Una pasarela cripto en producción no es un único servicio, es una constelación de servicios con responsabilidades claras.
Capa de API
REST o GraphQL. Crea facturas, devuelve URLs de checkout, expone webhooks. Rate-limited, autenticada con HMAC u OAuth.
Servicio de precios
Toma tipos de varias fuentes (exchanges, oráculos), calcula mediana y bloquea un tipo por factura durante 10 a 30 minutos.
Generación de direcciones
Deriva una dirección única por factura con rutas HD (BIP-32/44) o cuentas contrato en EVM. Una dirección por factura.
Indexador blockchain
Conectado a nodos propios o a Alchemy, Infura, QuickNode. Vigila mempool y bloques nuevos en direcciones monitorizadas.
Motor de confirmaciones
Aplica políticas por activo y por importe. Mueve la factura de detected a confirming y a completed.
Wallet y custodia
Hot para liquidez, cold para reservas, MPC o HSM para material de claves. Barrido a wallets consolidadas.
Servicio de webhooks
Firma, entrega y reintenta callbacks con backoff exponencial. Registra entregas para depuración.
Off-ramp a EUR
Convierte cripto entrante a stablecoin o EUR por exchange regulado u OTC. Liquida por SEPA o SEPA Instant en T+0.
Cada servicio escala, monitoriza y despliega por separado. Indexador y motor de confirmaciones son los dos que más sudan bajo carga.
Ciclo de vida de la factura
Todo pago cripto es una factura. Desde el punto de vista del comercio:
- Crear.
POST /invoicescon importe, moneda fiat,order_idy URL de callback. Respuesta: ID de factura, activos soportados y URL de checkout hospedado. - Mostrar. Se redirige al comprador o se embebe en iframe. Elige activo. La pasarela devuelve dirección de depósito y cantidad exacta al tipo bloqueado.
- Detectar. La wallet del comprador hace broadcast. El indexador la ve en mempool. La factura pasa a
detected. Webhook opcional. - Confirmar. Espera al umbral de confirmaciones configurado (mayor en importes grandes, menor en stablecoins en cadenas rápidas). Pasa a
confirmingy luegocompleted. - Liquidar. Fondos disponibles en la wallet del comercio. Si hay autoconversión, swap a stablecoin o off-ramp a EUR. Webhook
settled. - Expirar, pagar de menos o de más.
expired,underpaid,overpaid. Cada una detona su ruta de excepción.
Una pasarela madura expone cada transición como webhook independiente para que su sistema de pedidos reaccione correctamente. Una mala lo resume en "pagado/no pagado" y pierde información.
Rate lock y precios
Los precios cripto se mueven. Entre que el comprador ve "0,0023 BTC" y que su transacción mina, el precio puede variar 1 % a 3 %. Alguien debe absorber ese riesgo.
| Modelo | Funcionamiento | Riesgo lo asume |
|---|---|---|
| Tipo bloqueado | La pasarela fija la cantidad cripto durante 10 a 30 minutos. Si el mercado se mueve, la pasarela absorbe. | Pasarela |
| Tipo flotante | La factura muestra un objetivo en EUR; se abona el valor real al confirmar. | Comercio |
| Tolerancia variable | Tipo bloqueado con ±1 % a 2 % de tolerancia. Fuera de banda, rechazo automático. | Compartido |
El tipo bloqueado es el estándar porque los comercios quieren ingresos predecibles. Las pasarelas cubren la exposición manteniendo inventario en stablecoins, rebalanceando automáticamente o comprando cobertura a escala. Una ventana de 10 a 30 minutos cubre la distribución estadística de tiempos de confirmación en todas las cadenas relevantes.
Mempool y políticas de confirmación
Dos hitos independientes mueven la máquina de estados. Detección en mempool: tras el broadcast, los nodos completos ven la transacción sin confirmar. El indexador la observa directamente (nodos propios) o indirectamente (websocket de un proveedor). En pagos de bajo valor en cadenas rápidas (Tron, Solana, L2, Lightning) esto basta para liberar un bien digital.
Confirmaciones de bloque: la red mina la transacción. Cada bloque añadido es una confirmación más. Un bloque puede quedar huérfano por una reorganización (reorg), de ahí que se esperen varias confirmaciones en cadenas probabilísticas.
| Cadena | Tiempo de bloque | Confirmaciones típicas | Finalidad |
|---|---|---|---|
| Bitcoin | ~10 min | 3 (pequeño) a 6 (> 10.000 EUR) | Probabilística |
| Ethereum mainnet | ~12 s | 12 a 30 | Finalidad 2 épocas (~12 min) |
| Tron | ~3 s | 1 a 2 | Casi instantánea |
| Solana | ~0,4 s | 1 (confirmed) | Compromiso confirmed |
| Polygon PoS | ~2 s | 128 a 256 | Checkpoint a Ethereum |
| Arbitrum / Base | ~0,25 s | 1 en L2 + L1 opcional | Casi instantánea en L2 |
| Lightning Network | Instantáneo | 0 (off-chain) | Instantánea |
La política de confirmaciones es una decisión de gestión de riesgo, no técnica. Una cafetería no espera seis confirmaciones para liberar un café de 3 EUR. Un concesionario de vehículos, sí.
Casos frontera: pago de menos, de más, reorgs, red equivocada
El grueso del presupuesto de ingeniería en checkouts cripto se gasta en casos frontera. Los principales:
- Pago de menos. Envía menos (a menudo olvida la tasa de red). Una buena pasarela permite configurar tolerancia, auto-devolución o mantener la factura abierta para top-up.
- Pago de más. Envía de más. El estándar: acreditar el exceso al pedido o devolverlo. Política del comercio, no restricción técnica.
- Pago tardío. Paga tras expirar el rate lock. Rechaza, devuelve o acredita al tipo nuevo. Cada opción tiene UX y contabilidad distintas.
- Red equivocada. Envía USDC en Ethereum mainnet a una dirección esperada en Polygon. Recuperación no trivial. Las pasarelas serias avisan en el widget y bloquean errores obvios.
- Reorgs. Un bloque confirmado queda huérfano. Una factura
completedvuelve a no confirmada. El motor revierte y vuelve a trackear. Raro en cadenas modernas, pero no nulo. - Transacción atascada. Gas demasiado bajo, la transacción languidece en mempool. Se permite RBF en Bitcoin o aceleración en EVM.
- Dust y spam. Direcciones no relacionadas envían microimportes. El indexador ignora transferencias por debajo del umbral.
Pregunte al candidato cómo gestiona los siete. La respuesta revela la madurez de la plataforma.
Webhooks, idempotencia e integración
El webhook es donde la pasarela se encuentra con su sistema de pedidos. Acertar aquí es la diferencia entre un equipo de operaciones tranquilo y uno miserable.
- Eventos, no estados. Una buena pasarela dispara eventos distintos:
invoice.created,payment.detected,payment.completed,payment.settled,invoice.expired,invoice.underpaid. Cada uno con su clave de idempotencia. - Payloads firmados. HMAC-SHA256 con secreto compartido. El comercio verifica la firma antes de procesar. Menos que eso es phishable.
- Entrega al menos una vez. Reintentos con backoff exponencial (1s, 5s, 30s, 2min, 15min, 1h...). El comercio debe ser idempotente.
- Ack rápido, procesado diferido. Devuelva HTTP 200 en menos de 500 ms y empuje el trabajo pesado a una cola. Handlers que hacen lógica inline caen bajo carga.
- Reenvío manual. La pasarela debe dejar reenviar un webhook por ID del evento. Siempre hay un firewall mal configurado tarde o temprano.
Las prácticas son idénticas a webhooks en fiat. La especificidad cripto está en los eventos (confirmaciones, reorgs, pagos incompletos), no en la entrega.
Modelos de custodia y gestión de claves bajo MiCA
Cuando la cripto llega a la dirección de la pasarela, alguien custodia las claves. Es la decisión arquitectónica más determinante, y en España define qué autorizaciones CNMV necesita su proveedor.
Off-ramp: de on-chain a EUR por SEPA
La mayoría de comercios acaban queriendo euros. El off-ramp convierte cripto entrante en fiat y lo empuja a su cuenta bancaria española.
Mecánica: la pasarela agrega flujos, los enruta por un socio bancario o exchange regulado, y emite SEPA o SEPA Instant a la cuenta del comercio.
| Dimensión | Detalle |
|---|---|
| Venue de conversión | Exchange autorizado UE, OTC para tickets grandes, AMMs on-chain para conversiones entre cripto |
| Spread | 0,5 % a 1,5 % en stablecoins, 1 % a 3 % en activos volátiles |
| Canal de liquidación | SEPA Instant (T+0, minutos), SEPA estándar (T+1), SWIFT fuera de zona euro (T+1 a T+3) |
| Cumplimiento | SEPBLAC, Ley 10/2010, Reglamento UE 2023/1113 (Travel Rule) a partir de 1.000 EUR |
| Cadencia | Por factura, barrido diario o bajo demanda en panel |
Un comercio con off-ramp automático a EUR experimenta una UX muy parecida a un PSP fiat: el dinero aparece en su banco. Que el cliente pagara en USDC en Tron es un detalle de implementación.
Integre una pasarela cripto probada en producción
La arquitectura que acabamos de describir, ya construida.
GatewayCrypto opera todos los componentes descritos (indexador multi-cadena, motor de confirmaciones, custodia MPC, webhooks firmados y off-ramp a EUR por SEPA Instant) con el cumplimiento MiCA y SEPBLAC que exige el mercado español.
- API REST con paridad sandbox-producción. SDK para Node.js, Python, PHP, Ruby, Go, Java.
- Webhooks firmados e idempotentes. Reenvío por ID, logs accesibles.
- Custodia MPC + HSM. Niveles hot, warm, cold con cribado de direcciones.
- Off-ramp a EUR. SEPA Instant T+0, SEPA estándar T+1.
Impulse su negocio aceptando pagos criptográficos
Comenzar
Preguntas frecuentes
Crea una dirección única por pedido, vigila la blockchain para el pago, espera el número configurado de confirmaciones y notifica al comercio por webhook, con autoconversión opcional a stablecoin o EUR por SEPA Instant.
No. La pasarela opera los nodos o usa infraestructura como Alchemy, Infura o QuickNode. El comercio solo ve la API REST y los webhooks.
La pasarela auto-devuelve, acredita al tipo nuevo o mantiene para revisión manual, según su política configurada. Es un caso frontera resuelto en cualquier pasarela madura.
1 a 2 en stablecoins sobre Tron o L2. En Bitcoin, 3 por debajo de 10.000 EUR y 6 por encima. En Ethereum mainnet, 12 a 30 para finalidad de 2 épocas. Mayor importe, política más estricta.
Una vez pasada la ventana de reorg, no. El comercio puede emitir devolución como transacción saliente nueva, pero ningún tercero puede retraer fondos como hace un emisor de tarjeta. Esta es la razón estructural de que no haya contracargos.
Bloquea el tipo al crear la factura durante 10 a 30 minutos. Si paga en esa ventana, se acredita el importe exacto en EUR. La pasarela absorbe el movimiento de mercado durante el lock.
La pasarela custodia debe estar autorizada por la CNMV como PSC, cumplir DORA desde enero de 2025 y aplicar Travel Rule para transferencias a partir de 1.000 EUR. Antes del 1 de julio de 2026 debe ver la autorización sobre la mesa; tras esa fecha, operar sin ella es ilegal en España.
Con SEPA Instant, el mismo día, en minutos, 24/7. Con SEPA estándar, T+1. La parte cripto es T+0; el plazo total lo marca el canal bancario y la ventana de cierre de su banco.
