Inglés
Alemán
Español
Francés
Turco
Volver a Guías
Tipos de Pasarela de Pago: Hospedada, API, Autoalojada y Cripto (España 2026)
Las pasarelas de pago se agrupan en cuatro categorías arquitectónicas, cada una con un compromiso distinto entre esfuerzo de integración, control del checkout, alcance PCI DSS y tasa de conversión. Las pasarelas cripto forman una quinta categoría que queda fuera de la taxonomía de tarjeta por completo.
Esta guía compara las cinco clases aplicadas a España (Redsys, Bizum, SEPA Instant, Iberpay) con casos de uso concretos, implicaciones de cumplimiento PCI y un marco de decisión al final para elegir la arquitectura adecuada para su negocio.
Impulse su negocio aceptando pagos criptográficos
Por qué el tipo de pasarela condiciona los próximos años
El tipo de pasarela que elija decide tres cosas con las que convivirá durante años:
- Cuánto control tiene sobre la UX del checkout. Marca, diseño, campos, mensajes de error, embudo de conversión.
- Cuánto alcance PCI DSS v4.0.1 asume. De casi cero (SAQ-A) a auditoría completa (SAQ-D). La diferencia son decenas de miles de euros y meses de ingeniería al año.
- Con qué rapidez entrega y mantiene la solución. Una pasarela hospedada son semanas; una API pura son meses. Ambas son opciones legítimas; elegir sin conocer el compromiso sí es un error.
Hay cuatro tipos tradicionales en tarjeta: hospedada, autoalojada, API/integrada e integración bancaria local (en España, Bizum y SEPA Instant). Las pasarelas cripto forman un quinto tipo, estructuralmente distinto: no hay tarjeta ni alcance PCI que gestionar.
Pasarela hospedada
Una pasarela hospedada redirige al comprador de su sitio a una página de checkout del PSP para completar el pago, y lo devuelve luego a su sitio. En España, la página Redsys clásica es el arquetipo: 5.000 comercios siguen usándola con mínima personalización.
Pros
- Integración rapidísima; puede estar en producción en horas.
- Alcance PCI mínimo (SAQ-A). El PSP gestiona todo.
- El PSP mantiene UI, nuevos medios (Bizum, Apple Pay, Google Pay) y actualizaciones de cumplimiento.
- Opción por defecto para pymes, pilotos y equipos no técnicos.
Contras
- La redirección fuera del sitio penaliza la conversión móvil entre 2 % y 8 %.
- Personalización de marca limitada.
- Algunos PSP modernos lo mitigan con iframes o widgets drop-in.
Encaje ideal: pymes, equipos reducidos, comercios no técnicos, pilotos, cualquier negocio donde la UX de pago no sea diferencial competitivo.
Pasarela autoalojada
Una pasarela autoalojada mantiene al comprador en su sitio, pero el formulario lo construye, estiliza y aloja usted. Los datos de tarjeta viajan de su servidor a la pasarela por su backend.
Pros
- Control total de UI. El checkout se siente parte del producto.
- Sin redirección ni iframe; conversión óptima.
Contras
- Alcance PCI máximo (SAQ-D). Los datos de tarjeta pasan por sus servidores.
- Coste típico de 50.000 a 200.000 EUR anuales en cumplimiento.
- Superficie de ataque amplia para skimmers (Magecart).
Encaje ideal: grandes comerciantes con equipo de cumplimiento dedicado y programa PCI ya vivo. Excepcional en nuevos desarrollos en 2026 porque una API moderna con hosted fields alcanza el 95 % del beneficio de UX con el 5 % del coste de cumplimiento.
Pasarela API / integrada (el estándar moderno)
Una pasarela API usa SDK del lado del cliente (hosted fields, componentes drop-in, iframes tokenizadores) para enviar los datos de tarjeta directamente del comprador a la pasarela, saltándose sus servidores. Construye un checkout nativo con su UI, pero los datos sensibles nunca tocan su infraestructura. Stripe España, Adyen ES y CaixaBank Payments son referentes en esta categoría.
Pros
- Control total de UI + alcance PCI mínimo (SAQ-A). Lo mejor de los dos mundos.
- SDK móviles nativos, Apple Pay / Google Pay, 3DS2 (SCA bajo PSD2), tokenización listos de serie.
- Experiencia moderna para desarrolladores; webhooks, idempotencia, paridad sandbox.
Contras
- Más trabajo de ingeniería que una hospedada (semanas, no horas).
- Exige disciplina JS/SDK para preservar el SAQ-A.
Encaje ideal: la opción por defecto para e-commerce moderno, SaaS, marketplaces y cualquier negocio que quiera checkout nativo sin auditoría PCI. El 80 % de las nuevas integraciones en 2026 son de este tipo.
Integración bancaria local: Bizum, SEPA Instant, pay-by-bank
Una integración bancaria local conecta directamente con el banco del comprador, normalmente por vías cuenta-a-cuenta (A2A). En España, Bizum domina el peer-to-peer y crece con fuerza en e-commerce; SEPA Instant (reglamento UE 2024/886 obligatorio desde octubre de 2025) lo acompaña para importes mayores. Por debajo late Iberpay.
Pros
- Comisiones muy bajas (0,1 % a 0,5 % planos habituales).
- Liquidación instantánea en la mayoría de esquemas.
- Sin contracargos en muchos esquemas locales.
- Esencial en España: Bizum supera el 70 % de adopción entre adultos con cuenta bancaria.
Contras
- Geodependiente; Bizum solo aplica en España.
- Protección del consumidor varía por esquema.
- UX dispar entre países.
Encaje ideal: comerciantes internacionales con volumen en mercados concretos o cualquier negocio donde recortar 2 o 3 puntos porcentuales de comisión sea material.
Pasarela cripto (el quinto tipo)
Una pasarela cripto queda fuera de la taxonomía de tarjeta. No hay PAN, no hay PCI, no hay intercambio, no hay adquiriente, no hay cuenta mercantil. El monedero del comprador firma una transacción; la blockchain la liquida. En España, el proveedor custodio debe estar autorizado por la CNMV como PSC bajo MiCA.
Pros
- Comisiones planas por debajo del 1 % frente al 2,9 % de tarjeta.
- Cero contracargos.
- Liquidación transfronteriza instantánea.
- Sectores de alto riesgo aceptados.
- Los raíles stablecoin eliminan la volatilidad.
Contras
- El comprador necesita un monedero cripto (mercado direccionable ~600 millones y creciendo).
- El equipo de operaciones debe entender confirmaciones, reorganizaciones y off-ramp.
- MiCA añade requisitos regulatorios claros, pero también obligaciones nuevas.
Como las API, las pasarelas cripto modernas vienen en versión hospedada y API. Una hospedada es una redirección a una página con QR; una API es un widget embebido o creación programática de facturas. Misma decisión arquitectónica, raíles distintos por debajo.
Encaje ideal: cualquier negocio donde comisiones, contracargos o alcance global sean restricciones materiales. Cada vez más una opción por defecto junto a la tarjeta, no un reemplazo.
Los cinco tipos de un vistazo
| Tipo | Esfuerzo de integración | Control UX | Alcance PCI | Comisión típica | Encaje ideal |
|---|---|---|---|---|---|
| Hospedada | Horas | Bajo | SAQ-A (mínimo) | 1,2 % a 1,8 % + 0,25 EUR | Pymes, pilotos |
| Autoalojada | Semanas + auditoría | Total | SAQ-D (máximo) | 1,5 % a 2,5 % | Grandes con programa PCI |
| API / integrada | 1 a 4 semanas | Total | SAQ-A | 1,4 % a 1,9 % | Estándar moderno |
| Bancaria local (Bizum, SEPA Instant) | Semanas | Medio | Fuera (no es tarjeta) | 0,1 % a 0,5 % plano | España, volumen local |
| Cripto | Días a 2 semanas | Total (hospedada o API) | Fuera | 0,4 % a 1 % plano | Alto riesgo, global, margen fino |
Cómo elegir un tipo
Un marco de decisión rápido adaptado al mercado español:
- ¿Tiene programa PCI y presupuesto de cumplimiento? Si no, descarte la autoalojada.
- ¿Necesita checkout nativo? Sí: elija API/integrada. Si tolera la redirección, la hospedada es más barata y rápida.
- ¿Vende a consumidor en España? Añada Bizum de serie y SEPA Instant para importes medios y altos. Perder Bizum en 2026 equivale a dejar dinero sobre la mesa.
- ¿Son un problema sus comisiones, contracargos o alcance global? Añada una pasarela cripto como segundo checkout. Fiat y cripto son complementos, no sustitutos.
- ¿Opera en sector de alto riesgo? Lidere con cripto. Muchos adquirientes de tarjeta le rechazarán; las pasarelas cripto no.
El stack moderno en España suele ser: API para tarjeta + Bizum + SEPA Instant + pasarela cripto junto a todo. Un checkout, varios raíles, el más barato y rápido para cada comprador.
Impulse su negocio aceptando pagos criptográficos
Comenzar
Preguntas frecuentes
Cuatro tradicionales: hospedada (redirección al PSP), autoalojada (formulario en su sitio, datos por su servidor), API o integrada (formulario en su sitio, datos directos a la pasarela por SDK) e integración bancaria local (en España, Bizum y SEPA Instant). La quinta categoría moderna es la pasarela cripto, que no encaja dentro de la taxonomía de tarjeta.
La hospedada redirige al comprador a una página del PSP. La API mantiene al comprador en su sitio con checkout nativo, mientras los datos sensibles viajan directos del cliente a la pasarela por SDK, sin pasar por su servidor. La API da control total de UX al mínimo alcance PCI; por eso es el estándar moderno.
Las hospedadas y las API/integradas califican para PCI DSS v4.0.1 SAQ-A, la autoevaluación más corta. Las autoalojadas que tocan datos de tarjeta en su servidor exigen SAQ-D, la más extensa. Las pasarelas cripto no tienen alcance PCI alguno.
No es obligatorio por ley, pero omitirlo en un checkout B2C español penaliza la conversión de forma material. Con más del 70 % de adopción entre adultos bancarizados y comisiones por debajo del 0,5 %, es el segundo medio de pago tras la tarjeta en la mayoría de verticales.
Funcionalmente sí, estructuralmente aparte. Hacen el mismo trabajo (captura, autorización, liquidación) pero sobre raíles blockchain en lugar de redes de tarjeta, por lo que modelo de comisiones, cumplimiento (MiCA) y detalles operativos son distintos.
Parcialmente. La mayoría permite personalizar logo, color y copy, pero no cambiar del todo el layout o el orden de campos. Para control pixel-perfect, use una API con hosted fields.
Las API/integradas, porque el comprador no sale de su sitio y la UX es íntegramente nativa. Las hospedadas pierden entre el 2 % y el 8 % de conversión móvil por la redirección. La autoalojada iguala a la API pero con coste de cumplimiento mucho mayor.
Sí, y los comercios maduros lo hacen. El stack típico en España: API para tarjeta y wallets, Bizum y SEPA Instant para A2A, y una pasarela cripto para clientes globales o alto riesgo. Una capa de orquestación puede enrutar por reglas.
