Integrar Stripe, Redsys o Bizum en una app española parece un problema técnico y en realidad es sobre todo un problema de orden. El código de una pasarela moderna se escribe en pocos días. Lo que retrasa los lanzamientos son las cuentas sin verificar, los contratos de TPV virtual que el banco tarda tres semanas en firmar, la autenticación reforzada que nadie previó en el diseño y las devoluciones que no se probaron. Todo eso ocurre fuera del editor de código y todo eso se puede planificar.
Esta guía recorre el proceso en el orden en que conviene hacerlo, con las particularidades del mercado español y con los plazos reales que hemos visto en proyectos. Si lo que buscas es decidir cuál elegir antes de integrarla, esa comparativa está en Stripe vs Redsys vs Bizum para apps españolas. Aquí damos la decisión por tomada y nos centramos en ejecutarla bien.
¿Qué hace falta para integrar Stripe, Redsys y Bizum?
Para integrar Stripe, Redsys o Bizum necesitas tres cosas antes de escribir código: una entidad dada de alta con CIF o NIF, una cuenta bancaria a nombre del negocio, y las condiciones de venta y la política de privacidad publicadas y accesibles. Con eso puedes abrir cuenta y empezar la verificación, que es el paso que marca el calendario del proyecto.
La razón de insistir tanto en el orden es que la verificación no depende de ti. Stripe puede pedir documentación adicional sobre la actividad o sobre la titularidad real de la sociedad. Un banco español que te dé acceso a Redsys tiene sus propios plazos, sus propios formularios y, con frecuencia, una oficina intermedia que hay que perseguir. Ninguno de esos plazos se acelera porque tu desarrollo esté terminado. Se aceleran empezando antes.
Qué método elegir para el mercado español
La respuesta corta para la mayoría de apps españolas es tarjeta más Bizum, y la duda real es a través de quién.
Stripe es la opción por defecto para producto digital, suscripciones y equipos pequeños. Se abre en una tarde, la documentación es excelente, gestiona la autenticación reforzada por ti y ofrece Bizum como método adicional en España. Las comisiones publicadas para el mercado español parten de 1,5 % más 0,25 € en tarjetas estándar del Espacio Económico Europeo, suben a 1,9 % más 0,25 € en tarjetas prémium europeas y llegan a 3,25 % más 0,25 € en tarjetas internacionales. Comprueba las tarifas vigentes en la página de precios de Stripe antes de fijar tus márgenes, porque cambian.
Redsys es la infraestructura que hay detrás del TPV virtual de la mayoría de bancos españoles. No contratas con Redsys, contratas con tu banco, y ahí está su gran ventaja y su gran inconveniente. La ventaja es que si mueves volumen puedes negociar una comisión sensiblemente mejor que la tarifa pública de cualquier pasarela internacional, y el dinero entra directamente en tu banco de siempre. El inconveniente es que la experiencia de integración es más áspera, la documentación es más escueta y el soporte depende de a quién te toque al teléfono.
Bizum no es una alternativa a las dos anteriores, es un método de pago que se activa dentro de una de ellas. Merece mención propia porque en España cambia la conversión de forma perceptible: el cliente confirma en la aplicación de su banco, sin teclear el número de tarjeta, y eso elimina el punto exacto donde más gente abandona en el móvil. Si vendes a consumidor final en España, actívalo.
Página de pago alojada o componentes propios
Es la decisión de diseño con más consecuencias del proyecto, y conviene tomarla pronto.
Con una página de pago alojada, el usuario sale hacia una pantalla de la pasarela, paga allí y vuelve. Los datos de tarjeta no tocan tus servidores en ningún momento, con lo que tu carga de cumplimiento de la normativa de la industria de tarjetas se reduce drásticamente. También heredas gratis todo lo que la pasarela mejore con el tiempo, incluida la gestión de la autenticación reforzada.
Con componentes integrados, el formulario vive dentro de tu app y controlas cada píxel. La experiencia es mejor y más continua, y ese salto de pantalla desaparece. A cambio asumes más responsabilidad, más trabajo de mantenimiento y más superficie que auditar.
Nuestra recomendación por defecto, sobre todo en primeras versiones, es la página alojada. La diferencia de conversión entre ambas opciones es pequeña y medible; la diferencia de riesgo y de trabajo no lo es. Cambia de opinión cuando tengas datos propios que digan que ese salto te está costando ventas.
La autenticación reforzada no es opcional
La normativa europea de servicios de pago, conocida como PSD2, exige verificación adicional del cliente en buena parte de los pagos electrónicos. En la práctica significa que el usuario recibirá una pantalla de su banco, o una notificación en su aplicación bancaria, en mitad de tu flujo de compra.
El error clásico es diseñar el flujo de pago como si esa pantalla no existiera y descubrirla en la última semana. Entonces aparecen las prisas: qué pasa si el usuario cierra la app durante la verificación, qué ve si la cancela, cómo se recupera un pedido que quedó a medias. Diseña esos tres estados desde el principio y el problema desaparece. Diséñalos al final y te comes un retraso.
Hay excepciones y exenciones previstas en la normativa, por importe bajo o por comercio de confianza, pero no construyas tu experiencia asumiendo que se te aplicarán. Asume siempre que habrá verificación y llévate una alegría cuando no la haya.
Los avisos del servidor son la única fuente de verdad
Este es el error técnico que más dinero cuesta y el más fácil de evitar. Cuando un pago termina, la pasarela devuelve al usuario a tu app y además envía un aviso a tu servidor. Mucha gente da el pedido por bueno con lo primero. Es un fallo, porque el usuario puede cerrar el navegador antes de volver, perder la cobertura o pulsar atrás, y el pago habrá ocurrido igualmente.
Trata el aviso de servidor a servidor como la única confirmación válida. Verifica su firma, procesa cada aviso una sola vez aunque llegue repetido, y guarda un identificador propio de cada intento de pago para poder reconciliar después. Los sistemas de pago reintentan avisos, y un sistema que crea dos pedidos porque recibió dos veces la misma notificación es un sistema que vas a estar arreglando a mano durante meses.
Qué probar antes de abrir al público
La lista mínima, por orden de probabilidad de que te ocurra:
- Tarjeta rechazada por fondos insuficientes, y que el mensaje que ve el usuario sea comprensible.
- Autenticación reforzada cancelada por el usuario a mitad del proceso.
- Doble pulsación del botón de pagar, comprobando que no se generan dos cobros.
- Devolución total y devolución parcial desde tu panel, comprobando el estado en la app.
- Pago con Bizum completado y pago con Bizum abandonado en la aplicación del banco.
- Pérdida de conexión justo después de confirmar y antes de volver a la app.
- Un pago real de importe bajo en producción, con dinero de verdad, llegando a la cuenta bancaria.
Ese último punto no es paranoia. Entre el entorno de pruebas y producción cambian claves, dominios y a veces comportamientos, y la primera compra real es siempre el momento en que aparece lo que faltaba.
Plazos y coste realistas
El desarrollo de una integración de pagos acotada suele llevar de una a tres semanas según si necesitas suscripciones, pagos guardados o solo compras puntuales. El calendario real lo marcan los trámites: abrir y verificar una cuenta de Stripe puede resolverse en días, mientras que conseguir TPV virtual con Redsys a través de un banco español oscila entre una y varias semanas, con mucha varianza según la entidad.
El desglose económico de esa integración, con horas y rangos, lo tenemos en cuánto cuesta integrar Stripe en tu app. Y como cobrar implica tratar datos personales, revisa que tu información al usuario y tus bases legales estén en orden antes de lanzar, siguiendo el criterio de la Agencia Española de Protección de Datos que resumimos en cómo cumplir el RGPD en una app española.
Suscripciones y pagos guardados: el escalón siguiente
Cobrar una vez es sencillo. Cobrar todos los meses cambia el proyecto, y conviene saberlo antes de prometer un plan de suscripción en la web.
Con Stripe, la parte recurrente viene resuelta: hay productos, precios, periodos de prueba y reintentos automáticos cuando una tarjeta falla. Ese último detalle vale más de lo que parece, porque una parte nada pequeña de las bajas de suscripción no son bajas, son tarjetas caducadas que nadie reintentó a tiempo. Con Redsys la recurrencia existe mediante pagos por referencia, pero la lógica de reintentos, avisos y cambio de tarjeta la construyes tú, y eso son semanas de desarrollo que no aparecen en ninguna estimación inicial.
Guardar un método de pago para compras futuras tiene su propia consecuencia normativa. Un cobro que el usuario no está presenciando en ese momento se trata de forma distinta a efectos de autenticación reforzada, y para que funcione hay que haber recogido el consentimiento adecuado durante el primer pago. Si tu producto va a cobrar sin que el usuario esté delante, díselo al equipo técnico en la semana uno y no en la semana diez, porque afecta a cómo se implementa la primera transacción.
El orden que funciona
Abre las cuentas la primera semana. Elige página alojada salvo motivo de peso. Diseña la autenticación reforzada como parte del flujo, no como un imprevisto. Confía solo en los avisos de servidor. Prueba los fallos antes que los aciertos. Y haz compras reales pequeñas antes de abrir la puerta.
Hecho en ese orden, integrar Stripe, Redsys o Bizum deja de ser el riesgo del proyecto y pasa a ser una tarea aburrida, que es exactamente lo que quieres que sea un sistema de pagos. Si prefieres que lo montemos nosotros o que revisemos una integración que ya tienes en marcha, cuéntanos el caso en el formulario de proyecto.
.webp)
.webp)
