Cómo integrar una pasarela de pago en una app a medida en España

Cobrar dentro de una aplicación parece sencillo hasta que aparece el primer pago rechazado a las tres de la madrugada, el cliente que jura haber pagado y un extracto bancario que no cuadra con tu base de datos. Integrar una pasarela de pago en una app a medida no es pegar un botón: es diseñar un flujo que sobreviva a fallos de red, redirecciones de autenticación bancaria, devoluciones, suscripciones que caducan y auditorías de seguridad. Quien lo monta bien duerme tranquilo; quien lo improvisa acaba reconciliando pagos a mano en una hoja de cálculo.

Esta guía recorre las decisiones reales que enfrentas cuando desarrollas para el mercado español: qué pasarelas tienen sentido aquí, cómo encajan la PSD2 y la autenticación reforzada, dónde guardar (y dónde nunca guardar) datos de tarjeta, y qué pasos sigue una integración que aguante producción.

Qué hace realmente una pasarela de pago

Una pasarela de pago es el intermediario técnico que conecta tu app con el sistema bancario. Recibe los datos del pago, los enruta hacia las redes de tarjetas (Visa, Mastercard) o hacia sistemas locales como Bizum, gestiona la autenticación del titular y devuelve un resultado: autorizado, rechazado o pendiente. Por debajo coordina al menos cuatro actores: el banco emisor del cliente, las redes de tarjeta, tu entidad adquirente (el banco donde ingresas el dinero) y la propia plataforma de la pasarela.

Esa cadena explica por qué un pago tarda segundos y por qué puede fallar en muchos puntos. Tu integración tiene que tratar el pago como un proceso asíncrono que puede quedar a medias, no como una llamada a función que devuelve verdadero o falso.

Adquirente, agregador y pasarela: no son lo mismo

En España conviene distinguir tres figuras. El adquirente es la entidad que liquida el dinero en tu cuenta; típicamente tu banco (Santander, BBVA, CaixaBank) o un proveedor especializado. La pasarela es la capa técnica que procesa la transacción. El agregador (Stripe, PayPal) hace ambas cosas bajo un único contrato y te ahorra negociar con el banco, a cambio de comisiones algo mayores.

Si trabajas con un TPV virtual de un banco español, casi siempre estarás usando Redsys, la plataforma que da servicio a la mayoría de entidades del país. La cuenta y las comisiones las negocias con el banco; la integración técnica la haces contra Redsys.

API directa o checkout alojado: la decisión que condiciona todo

La primera elección arquitectónica determina cuánto código escribes y cuánta responsabilidad legal asumes.

El checkout alojado (hosted) redirige al usuario a una página de la pasarela, o carga un formulario embebido servido por ella, donde introduce los datos de tarjeta. La tarjeta nunca pasa por tu servidor. Es la opción rápida, segura y la que reduce drásticamente tus obligaciones de cumplimiento PCI-DSS, porque los datos sensibles los captura la pasarela. El coste es menos control sobre la experiencia visual, aunque las soluciones modernas (Stripe Elements, formularios embebidos de Redsys) permiten personalizar bastante.

La integración por API directa (server-to-server) hace que tu backend hable directamente con la pasarela. Tienes control total del flujo y de la interfaz, pero asumes mayor responsabilidad: si los datos de tarjeta tocan tu infraestructura, entras en un nivel de certificación PCI-DSS mucho más exigente. La forma sensata de tener API directa sin esa carga es la tokenización en cliente: un SDK de la pasarela captura la tarjeta en el dispositivo y devuelve un token; tu servidor opera siempre con ese token, nunca con el número real (el PAN).

Para la mayoría de apps a medida en España, la recomendación práctica es checkout alojado o tokenización en cliente. La API server-to-server con datos de tarjeta en claro solo compensa cuando hay un volumen muy alto y un equipo capaz de mantener la certificación.

PSD2 y SCA: la autenticación reforzada no es opcional

La normativa europea PSD2 obliga a aplicar SCA (autenticación reforzada de cliente) en la mayoría de pagos electrónicos. En la práctica significa que el titular debe confirmar la operación con al menos dos factores: algo que sabe (PIN), algo que tiene (el móvil) o algo que es (huella, cara). El mecanismo técnico es 3D Secure 2 (3DS2), que en muchos pagos redirige momentáneamente al usuario a la app o web de su banco para confirmar.

Esto tiene consecuencias directas en tu integración:

• El flujo de pago no es lineal. Tras enviar el pago puede aparecer un paso de autenticación (un challenge) gestionado por el banco emisor. Tu app debe saber pausar, abrir esa pantalla y retomar el flujo con el resultado.
• Existen exenciones: importes pequeños, pagos recurrentes ya autenticados, comercios de bajo riesgo o transacciones iniciadas por el comercio (MIT). La pasarela suele gestionar la lógica de exenciones, pero tú decides cómo marcar cada pago.
• Los pagos recurrentes requieren guardar un mandato o credencial de la primera autenticación para poder cobrar después sin molestar al usuario en cada renovación.

Ignorar SCA se traduce en rechazos masivos: el banco emisor declina el pago por falta de autenticación. No es un detalle, es la causa más común de transacciones perdidas en integraciones nuevas.

Métodos de pago en España: tarjeta, Bizum y carteras

El abanico que esperan los usuarios españoles va más allá de la tarjeta. Conviene cubrir:

• Tarjeta (Visa, Mastercard): base imprescindible, con 3DS2.
• Bizum: muy extendido para pagos persona a comercio. Está disponible a través de Redsys y de algunos agregadores; si tu público es español, el soporte de Bizum sube la conversión de forma notable.
• PayPal: útil para confianza percibida y compradores que no quieren teclear la tarjeta.
• Carteras móviles (Apple Pay, Google Pay): especialmente relevantes en apps, porque eliminan la fricción de introducir datos en una pantalla pequeña.
• Transferencias y domiciliación SEPA: para B2B o suscripciones de importe alto.

No todas las pasarelas ofrecen todos los métodos. El soporte de Bizum, en concreto, suele inclinar la balanza hacia Redsys o hacia agregadores que lo integren explícitamente.

Comparativa de pasarelas para el mercado español

La tabla resume tres opciones habituales. Las comisiones son orientativas (varían según contrato, volumen y país de la tarjeta) y sirven para situarte, no como tarifa cerrada.

Pasarela	Comisión orientativa	Métodos	Ideal para
Redsys (TPV virtual del banco)	~0,3–0,9 % + condición del banco	Tarjeta, Bizum, 3DS2	Negocio español, volumen estable, Bizum imprescindible
Stripe	~1,4 % + 0,25 € (tarjetas europeas)	Tarjeta, Apple/Google Pay, SEPA, recurrentes	Apps a medida, desarrollo ágil, cobertura internacional
PayPal / Adyen	~1,2–2,9 % + fija (PayPal); negociado (Adyen)	Tarjeta, carteras, métodos locales	Confianza del comprador (PayPal) o gran volumen multinacional (Adyen)

Una pauta razonable: si tu negocio es esencialmente español y necesitas Bizum con comisiones ajustadas, parte de Redsys con tu banco. Si priorizas velocidad de desarrollo, documentación excelente y vender fuera de España, Stripe es difícil de superar. Adyen entra cuando hay volumen muy alto y operativa internacional que justifique negociar condiciones a medida.

Flujo de pago paso a paso

Conviene tener claro el recorrido completo de una transacción con tarjeta y SCA antes de escribir una línea:

1. El usuario inicia el pago en la app y esta pide a tu backend que cree la operación (un PaymentIntent en Stripe, una petición firmada en Redsys), con importe, moneda y referencia interna.
2. Tu backend devuelve a la app un identificador o token de cliente que no expone secretos.
3. La app captura los datos de tarjeta mediante el SDK de la pasarela, que los tokeniza en el dispositivo.
4. Se confirma el pago. Si el banco exige autenticación, se lanza el challenge 3DS2 y el usuario lo resuelve.
5. La pasarela devuelve el resultado. Importante: el resultado fiable llega por webhook a tu servidor, no solo por la respuesta visible en la app.
6. Tu backend, al recibir el webhook verificado, marca el pedido como pagado, dispara la entrega y registra la conciliación.

El error clásico es dar el pedido por bueno con la respuesta que ve la app. Una redirección perdida o una app cerrada antes de tiempo puede dejar el pago cobrado y el pedido sin confirmar. La fuente de verdad es el webhook.

Webhooks y conciliación: el corazón silencioso

Los webhooks son notificaciones que la pasarela envía a una URL de tu servidor cuando cambia el estado de un pago: autorizado, rechazado, reembolsado, en disputa. Tres reglas no negociables:

• Verifica la firma de cada webhook. Si no validas que viene de la pasarela, expones un endpoint que cualquiera puede falsificar para marcar pedidos como pagados.
• Hazlos idempotentes. La pasarela puede reenviar el mismo evento varias veces; procesarlo dos veces no debe duplicar un pedido ni un cobro. Guarda el identificador del evento y descarta repetidos.
• Concilia a diario. Cruza tus pagos registrados con el extracto de liquidación del adquirente. Las diferencias revelan webhooks perdidos, reembolsos no reflejados o comisiones mal calculadas.

Pagos recurrentes y suscripciones

Para suscripciones necesitas guardar un método de pago tokenizado y un mandato derivado de la primera autenticación SCA. A partir de ahí, los cobros periódicos son transacciones iniciadas por el comercio (MIT), normalmente exentas de pedir autenticación de nuevo. Detalles que marcan la diferencia:

• Gestiona el ciclo de vida: alta, renovación, cambio de plan, impago, cancelación. Cada estado dispara lógica distinta en tu app.
• Implementa reintentos inteligentes (dunning): si un cobro falla por fondos insuficientes, reintenta tras unos días en lugar de cancelar de inmediato. Recuperas un porcentaje significativo de pagos así.
• Avisa antes de caducidades de tarjeta. Muchas pasarelas ofrecen actualización automática de credenciales; actívala si está disponible.

Seguridad y cumplimiento

La regla de oro: nunca almacenes el número de tarjeta (PAN), el CVV ni la banda magnética en tus sistemas. El CVV no puede guardarse jamás, ni cifrado. Trabaja siempre con tokens que devuelve la pasarela.

Más allá de eso, tu integración debe contemplar:

• PCI-DSS: el estándar de seguridad de la industria de tarjetas. Usando checkout alojado o tokenización en cliente, tu alcance se reduce normalmente al cuestionario más ligero (SAQ A), porque los datos sensibles no tocan tu servidor. La API directa con PAN en claro dispara las exigencias.
• RGPD: los datos de pago y de cliente son datos personales. Minimiza lo que guardas, cifra en reposo lo que sí conserves (correo, historial de pedidos, token), define plazos de retención y refleja la pasarela como encargado del tratamiento en tus contratos y política de privacidad.
• Cifrado en tránsito: TLS en todas las comunicaciones, sin excepción, también para los webhooks.
• Gestión de secretos: las claves de API viven en variables de entorno o en un gestor de secretos, nunca en el repositorio ni en el código del cliente. La app móvil solo maneja claves públicas.

Entorno de pruebas y gestión de errores

Toda pasarela seria ofrece un entorno sandbox con tarjetas de prueba que simulan cada escenario: pago aprobado, rechazado por fondos, challenge 3DS2, tarjeta caducada, fraude. Construye tu integración entera contra sandbox y no pases a producción hasta cubrir los casos de borde.

La gestión de errores distingue una integración profesional de un prototipo:

• Diferencia errores recuperables (red caída, timeout) de definitivos (tarjeta denegada). Los primeros admiten reintento; los segundos requieren acción del usuario.
• Muestra mensajes útiles y honestos. "Pago rechazado por tu banco, prueba otra tarjeta o contacta con tu entidad" ayuda; "Error 500" no.
• Registra logs de cada paso sin volcar datos sensibles, para poder diagnosticar un fallo concreto sin comprometer tarjetas.
• Controla los timeouts: si la pasarela no responde, no dejes al usuario en una pantalla colgada ni cobres dos veces por un reintento mal gestionado. Aquí vuelve a brillar la idempotencia.

Cómo elegir y cómo abordar la integración

Reduce la decisión a criterios concretos: comisiones reales para tu mix de tarjetas y volumen, métodos que tu público espera (Bizum pesa mucho en España), calidad de documentación y SDKs, soporte y, si vendes fuera, cobertura internacional y monedas. Suma el coste de mantenimiento: una pasarela con buenos SDKs y webhooks claros ahorra semanas de desarrollo y meses de incidencias.

Un orden de trabajo que funciona: define los métodos de pago objetivo, elige pasarela según ese mix, monta el flujo en sandbox con webhooks verificados e idempotentes, cubre SCA y los casos de error, valida la conciliación contra liquidaciones reales y solo entonces abre producción con un periodo de vigilancia estrecha. Si manejas suscripciones, prueba a fondo el ciclo de renovación y los reintentos antes de tener clientes dependiendo de ellos.

Integrar pagos bien hecho es invisible para el usuario y robusto para el negocio: cobra cuando debe, no cobra de más, cuadra las cuentas y resiste el día que algo falla. Ese nivel de fiabilidad se diseña desde el principio, no se parchea después.

Si quieres montar una pasarela de pago en tu app a medida con SCA, Bizum y conciliación bien resueltos desde el primer día, cuéntanos tu proyecto y te ayudamos a integrarlo.