Cómo integrar pasarelas de pago Stripe y Redsys en una aplicación web a medida

Cuando una aplicación web mueve dinero real, la elección de la pasarela deja de ser un detalle técnico. En España hay dos actores que concentran la mayoría de las integraciones: Redsys, conectada directamente con el sistema bancario español, y Stripe, que lleva ganando cuota en Europa desde 2019. El comercio electrónico en España superó los 72.000 millones de euros en 2024 según Statista, y en ese contexto, qué pasarela usas y cómo la integras tiene consecuencias reales en conversión, costes y seguridad.

Lo que encontrarás aquí: cómo integrar ambas en una aplicación web a medida, qué ofrece cada una, cómo cumplir con PCI DSS, cómo diseñar webhooks que aguanten en producción y cómo estructurar el testing antes de desplegar.

Stripe vs. Redsys: comparativa para el mercado español

Antes de tocar código, vale la pena entender dónde brilla cada plataforma.

Redsys: el estándar bancario español

Redsys procesa más del 60 % de las transacciones con tarjeta en España. Su ventaja más práctica es la integración directa con los TPV virtuales de los bancos españoles —CaixaBank, BBVA, Santander, Sabadell—, lo que te permite negociar comisiones directamente con tu entidad. Desde 2022 también soporta Bizum, y el usuario final español la reconoce sin fricción. El reverso: la documentación es irregular, el onboarding depende del banco con el que trabajes y el ecosistema de SDKs queda lejos del nivel de otros procesadores internacionales.

Stripe: flexibilidad y experiencia de desarrollador

Stripe es otra liga en cuanto a API. La documentación es clara, las herramientas —Stripe Elements, Stripe CLI, Dashboard— están bien pensadas, y el soporte para modelos de negocio complejos es amplio: marketplaces con Stripe Connect, suscripciones, facturación automática, pagos en más de 135 divisas. Las comisiones estándar en Europa son del 1,5 % + 0,25 EUR por transacción con tarjeta europea, sin cuota mensual ni coste de alta. Lo que pierdes: comisiones fijas sin margen de negociación y, en algunos segmentos, usuarios españoles menos familiarizados con el formulario de pago.

Cuándo usar cada una (o ambas)

Si tu aplicación apunta exclusivamente al mercado español, manejas volúmenes altos y ya tienes relación bancaria, Redsys suele salir más barata. Para un SaaS, un marketplace o un proyecto con mercado internacional, Stripe gana en flexibilidad. Muchas aplicaciones web a medida acaban con ambas: Stripe como pasarela principal y Redsys como alternativa para quien prefiere pagar desde su banco o usar Bizum. No es redundancia, es cobertura.

Cumplimiento PCI DSS: lo que tu aplicación debe garantizar

PCI DSS es obligatorio para cualquier entidad que almacene, procese o transmita datos de tarjeta. La versión 4.0, vigente desde marzo de 2024, endurece los requisitos en autenticación multifactor y monitorización continua.

Niveles de cumplimiento

El nivel de cumplimiento depende del volumen anual de transacciones. La mayoría de aplicaciones web a medida caen en el nivel 4 —menos de 20.000 transacciones anuales con Visa— y pueden completar el proceso con un cuestionario de autoevaluación (SAQ). Qué tipo de SAQ aplica depende de cómo fluyen los datos de tarjeta por tu sistema:

• SAQ A: los datos de tarjeta no tocan en ningún momento tu servidor. Aplica cuando usas Stripe Elements, Stripe Checkout o el formulario redirigido de Redsys.
• SAQ A-EP: tu página aloja el formulario de pago, pero los datos van directamente al procesador sin pasar por tu backend. Mayor carga de cumplimiento.
• SAQ D: tu servidor recibe datos de tarjeta. Requiere auditoría completa. Evita este escenario siempre que puedas.

La recomendación técnica es inequívoca: tokeniza siempre en el cliente. Con Stripe Elements, el iframe seguro captura los datos de tarjeta y los transforma en un token antes de que tu servidor los vea. Con Redsys, el formulario redirigido o el modo iFrame InSite logran el mismo efecto.

Implementación técnica: enfoque por capas

Una integración de pasarela de pago bien pensada separa responsabilidades. Si en el futuro necesitas cambiar de proveedor o añadir uno nuevo, no quieres tocar la lógica de negocio.

Capa de abstracción de pagos

Define una interfaz común —PaymentGateway— con métodos como createPayment, capturePayment, refund y getTransactionStatus. Cada pasarela la implementa por separado. El patrón no es nuevo, pero en pagos se nota especialmente: cuando cambias o añades un procesador, el resto del sistema no se entera.

Integración con Stripe

El flujo recomendado usa Payment Intents, que gestionan de forma nativa la autenticación 3D Secure, obligatoria en Europa bajo PSD2/SCA:

1. El backend crea un PaymentIntent con importe y divisa, y recibe un client_secret.
2. El frontend, con Stripe.js y Elements, recoge los datos de tarjeta en un iframe seguro y confirma el PaymentIntent usando ese client_secret.
3. Si se requiere 3D Secure, Stripe gestiona el flujo de autenticación sin que tengas que orquestar nada.
4. El resultado llega al backend tanto por respuesta síncrona como por webhook.

Integración con Redsys

El flujo estándar de Redsys utiliza redirección al TPV virtual:

1. El backend genera los parámetros de la operación (Ds_MerchantParameters), los codifica en Base64 y calcula la firma HMAC SHA-256 con la clave del comercio.
2. El usuario aterriza en el formulario de Redsys, introduce los datos de tarjeta y completa la autenticación 3D Secure.
3. Redsys redirige al usuario a la URL de retorno configurada y envía una notificación al endpoint de callback, que funciona como un webhook.

Existe también Redsys InSite, que incrusta el formulario de pago en tu propia página mediante un componente JavaScript —similar a Stripe Elements en filosofía—. Mejora la experiencia al eliminar la redirección, aunque requiere SAQ A-EP.

Webhooks: la pieza que muchos equipos subestiman

Los webhooks son notificaciones asíncronas que la pasarela envía a tu servidor cuando ocurre algo relevante: pago completado, pago fallido, reembolso procesado, disputa abierta. Son la fuente de verdad para el estado de las transacciones. Si confías solo en la respuesta síncrona, pierdes el evento en cuanto el navegador del usuario se cierra antes de completar la redirección.

Principios de diseño para webhooks robustos

Idempotencia. Tu endpoint debe procesar el mismo evento varias veces sin efectos secundarios. Guarda el identificador del evento y comprueba si ya lo procesaste antes de ejecutar cualquier lógica de negocio.

Verificación de firma. Stripe firma cada webhook con HMAC SHA-256 usando un secreto específico por endpoint; Redsys usa la clave del comercio. Verificar esa firma impide que un atacante inyecte eventos falsos.

Respuesta rápida. Devuelve HTTP 200 antes de ejecutar lógica pesada. Encola el procesamiento en un worker —Celery, BullMQ, Sidekiq— para evitar timeouts que disparen reintentos innecesarios.

Cola de fallidos. Implementa una dead-letter queue para eventos que fallan repetidamente. Un evento perdido puede ser un cobro sin registrar o un pedido sin procesar.

Si necesitas ayuda para diseñar la arquitectura de pagos de tu aplicación o migrar una integración existente, en Tangram Consulting llevamos años trabajando con Stripe y Redsys y podemos ayudarte a definir la solución que mejor encaja con tu modelo de negocio.

Pagos recurrentes y suscripciones

Los modelos basados en suscripción exigen funcionalidades adicionales que las dos pasarelas cubren de formas muy distintas.

Stripe Billing

Stripe ofrece un motor de suscripciones completo: planes, precios, períodos de prueba, prorratas, cupones, facturas automáticas y gestión de impagos con reintentos configurables (dunning). Los webhooks notifican eventos como invoice.payment_succeeded o customer.subscription.deleted. Para modelos complejos, es difícil igualar esa cobertura sin construirla desde cero.

Pagos recurrentes con Redsys

Redsys soporta pagos recurrentes mediante el identificador de referencia (Ds_Merchant_Identifier), que almacena la tarjeta tokenizada para cargos posteriores sin que el usuario vuelva a introducir los datos. Ahí termina el servicio: la gestión de suscripciones —cobro periódico, reintentos, cambios de plan— recae sobre tu aplicación. Para modelos complejos, lo habitual es usar Stripe Billing como motor y ofrecer Redsys para el pago puntual o el primer cobro de alta.

Gestión de errores y códigos de respuesta

El tratamiento de errores separa una integración frágil de una que aguanta en producción.

Errores de Stripe

Stripe categoriza los errores con claridad: card_error, authentication_required, rate_limit_error, api_error e invalid_request_error. Cada uno incluye un código específico —insufficient_funds, expired_card— que te permite mostrar al usuario algo útil en lugar de un genérico "algo salió mal".

Errores de Redsys

Redsys devuelve un código numérico (Ds_Response) del 0000 al 9999. Los códigos 0000-0099 indican operación aprobada. Los más frecuentes son 0101 (tarjeta caducada), 0184 (error en autenticación) y 0190 (denegación del emisor). Mantener una tabla de mapeo actualizada de esos códigos a mensajes legibles en español no es opcional si quieres que el usuario sepa qué pasó y qué puede hacer.

Estrategia unificada

Con la capa de abstracción mencionada antes, define tu propio vocabulario de errores que normalice las respuestas de ambas pasarelas. La lógica de negocio y el frontend trabajan con ese vocabulario y no dependen de si por debajo está Stripe o Redsys.

Testing: entornos de prueba y simulación

Ambas pasarelas tienen entornos de prueba. Usarlos a fondo antes de cualquier despliegue no es negociable.

Stripe ofrece un modo de prueba completo con tarjetas documentadas: 4242 4242 4242 4242 para éxito, 4000 0000 0000 0002 para rechazo. Su CLI permite reenviar webhooks al entorno local con stripe listen --forward-to, lo que simplifica mucho el ciclo de desarrollo. Redsys tiene un entorno de integración (sis-t.redsys.es) con tarjetas y claves de prueba, aunque el acceso requiere solicitud previa al banco.

Tests automatizados recomendados

• Unitarios: validar firmas HMAC para Redsys y construcción de PaymentIntents para Stripe.
• De integración: flujos completos contra los entornos de prueba, incluyendo 3D Secure, rechazos y reembolsos.
• De webhooks: simular la recepción de eventos y verificar que la base de datos refleja el estado correcto.
• De concurrencia: confirmar que webhooks duplicados no generan cobros dobles.

Seguridad más allá de PCI DSS

PCI DSS es el suelo, no el techo.

Rate limiting en endpoints de pago. Previene ataques de enumeración de tarjetas (card testing), que según Stripe representaron el 15 % de los intentos de fraude en su plataforma durante 2024. Sin límite de intentos, tu formulario de pago puede convertirse en una herramienta para validar tarjetas robadas.

Logging seguro. Registra eventos de pago sin incluir datos sensibles —nunca el PAN completo, nunca el CVV, nunca datos de 3D Secure—. Usa identificadores opacos para mantener la trazabilidad sin exponer lo que no deberías tener.

Alertas en tiempo real. Configura alertas para patrones sospechosos: múltiples intentos fallidos desde la misma IP, importes fuera de rango, picos de tráfico inusuales en el endpoint de pago.

Actualización de dependencias. Automatiza la detección de versiones vulnerables con Dependabot o Renovate integrados en tu pipeline CI/CD. Las librerías de pagos se actualizan con frecuencia; quedarse atrás tiene un coste real.

Una arquitectura limpia —abstracción de proveedores, webhooks robustos, testing riguroso— reduce incidencias en producción y deja la puerta abierta a escalar sin reescrituras cuando el negocio evolucione.