Antes de comparar pasarelas, hay una pregunta que decide casi todo lo demás: ¿tienes derecho a usar una pasarela, o Apple y Google te obligan a su compra in-app? La respuesta no depende de tus ganas, depende de qué vendes. Si cobras por un bien físico o un servicio que se consume fuera de la app, como un pedido de comida, una reserva o una clase presencial, usas una pasarela externa y las tiendas no se llevan comisión. Si cobras por contenido o funciones digitales que se consumen dentro de la app, la compra in-app es obligatoria y la tienda se queda entre un 15% y un 30%.

Equivocarte en esa primera bifurcación tiene dos finales conocidos: regalar un 30% que no tenías por qué pagar, o comerte un rechazo en la revisión de la App Store. Vamos por orden.

La regla que decide por ti (y que te ahorra el rechazo)

La norma que importa es la guía 3.1.1 de Apple y su contraparte 3.1.3(e), más la política de pagos de Google Play. Resumida sin la jerga legal:

  • Contenido digital consumido en la app → compra in-app obligatoria. Suscripciones a contenido, funciones premium, monedas de juego, desbloqueos. Aquí no hay elección: si metes un enlace a Stripe para esto, te rechazan.
  • Bienes físicos y servicios del mundo real → pasarela externa, y la tienda no puede cobrarte comisión ni obligarte a su sistema de cobro. No existe un producto de compra in-app para una pizza, una noche de hotel o un fontanero.

El problema está en las zonas grises, que es donde se cae la gente. Una clase de yoga que reservas en la app pero haces en un local es un servicio presencial: pasarela. El mismo vídeo de esa clase, visto dentro de la app, es contenido digital: compra in-app. Un marketplace de productos físicos cobra por pasarela; si ese marketplace vende además packs de "créditos" para gastar dentro de la app, esos créditos vuelven a ser compra in-app. Si tu carrito mezcla las dos cosas, necesitas dos caminos de cobro en el mismo carrito.

La regla práctica: antes de integrar nada, clasifica cada cosa que cobras en "se consume dentro" o "se consume fuera". Primero esa clasificación, luego el stack. Y no intentes colar bienes físicos por compra in-app (no hay tipo de producto para eso) ni contenido digital por Stripe fuera de las excepciones de la UE y EE. UU. Las condiciones de la UE cambiaron el 1 de octubre de 2026; si te afectan, eso va por otra parte.

Si te toca pasarela: Stripe o Redsys

Supongamos que vendes algo físico o un servicio real. Ahora sí toca elegir pasarela. Las dos candidatas en España suelen ser Stripe y Redsys, y resuelven el mismo problema desde filosofías opuestas.

Stripe tiene paquete oficial para Flutter, flutter_stripe, y su flujo recomendado hoy es PaymentSheet, la hoja de pago que ya trae tarjeta, Apple Pay y Google Pay, y que gestiona el reto de 3D Secure por su cuenta. El CardField y el CardForm manuales están en retirada; para integraciones nuevas, PaymentSheet. La experiencia de desarrollo es buena, la documentación es honesta, y el soporte multipaís y SEPA viene de serie. La comisión es por transacción (en torno al 1,5% para tarjetas del Espacio Económico Europeo, más para las de fuera; mira su tarifa vigente), lejos del 15% o 30% de la tienda.

Cuándo no Stripe: si tu banco adquirente te ata a su TPV virtual por las condiciones de tu cuenta, si necesitas un terminal bancario español concreto que tu entidad solo da vía Redsys, o si tu volumen es tan alto que una comisión negociada con el banco sale más barata que la tarifa de Stripe.

Redsys es el estándar que usan la mayoría de bancos españoles. No hay SDK oficial de Flutter: integras por redirección o WebView contra su pasarela, o servidor a servidor. La comisión no la fija Redsys, la negocias con tu banco, y en volumen puede ganar a Stripe. El precio lo pagas en otra moneda: por defecto Redsys pide autenticación reforzada en casi todas las operaciones, así que tu checkout tiene más fricción y tu conversión lo nota. La experiencia de desarrollo también es más áspera.

Cuándo no Redsys: si lo que más te importa es la conversión del checkout y la velocidad de integración, y no tienes un acuerdo bancario que te obligue.

Tampoco es una decisión binaria de por vida. Es habitual usar Stripe para tarjeta internacional y mantener Redsys por el acuerdo con el banco, con el backend eligiendo la ruta según el caso. Lo que no recomendamos es empezar por ahí: la doble pasarela es una optimización para más adelante, no el punto de partida.

SCA y 3D Secure en el móvil, sin romper el checkout

Desde la PSD2, casi todo pago europeo pasa por autenticación reforzada (SCA), y en la práctica eso es 3D Secure 2. En una app, el flujo es este: tu servidor crea un PaymentIntent, el cliente abre la hoja de pago, y si el banco pide reto, PaymentSheet lo presenta y devuelve el resultado a la app. Con Stripe lo tienes resuelto; con Redsys lo montas tú.

Los errores que vemos repetirse no están en el pago, están en la vuelta. El primero es el enlace de retorno: el usuario sale al banco a autenticarse y, si el deep link de vuelta está mal configurado, regresa a una pantalla en blanco sin saber si pagó, aunque en el servidor el cobro haya salido bien. El segundo es confiar en el "éxito" que muestra el cliente: que la app pinte la confirmación no significa que el dinero se haya movido, porque un PaymentIntent puede quedarse en processing y resolverse unos segundos después. Y el tercero es no contemplar los estados intermedios: entre "iniciado" y "pagado" hay pasos, y una interfaz que solo entiende esos dos extremos se cuelga en cuanto aparece un reto 3DS.

La parte que casi siempre se hace mal: la arquitectura

El fallo más caro es de arquitectura. La clave secreta de Stripe, o las credenciales de comercio de Redsys, no viven en el cliente. Una app se puede descompilar, y una clave metida en el binario es una clave filtrada. El patrón correcto es el de siempre: tu backend guarda los secretos, crea el PaymentIntent y le pasa al cliente solo el client secret, que sirve para ese pago y nada más. Lo contamos a fondo en nuestra guía de claves y secretos en una app Flutter, y aplica igual aquí.

Dos cosas más separan una integración de juguete de una de producción. La confirmación de verdad llega por el webhook del servidor; el callback del móvil no basta, porque es la única fuente fiable de que el dinero se movió. Y toda petición que cobra necesita una clave de idempotencia, para que un reintento por mala cobertura no cobre dos veces al mismo usuario. Son dos líneas de disciplina que ahorran una semana de soporte.

Nuestra recomendación

Para la mayoría de apps que empiezan a cobrar por bienes o servicios físicos, Stripe con PaymentSheet es la opción por defecto: menos código, 3DS resuelto, buena conversión. Redsys entra cuando un acuerdo bancario o el volumen lo justifican, no antes. Y si vendes contenido digital, deja de pelear con la tienda: la compra in-app es obligatoria, y la pregunta útil es si te aplica el 15% reducido.

Lo que no haríamos con un cliente: montar la doble pasarela el primer día, meter la clave secreta en el cliente "para salir rápido", o decidir el stack de cobro sin clasificar antes qué se consume dentro y qué fuera. Ese orden (primero la regla de la tienda, luego la pasarela, luego la arquitectura) es lo que evita rehacer el checkout a mitad de proyecto.

Si estás diseñando cómo va a cobrar tu app y prefieres que la decisión la tome alguien que ya ha pasado por la revisión de ambas tiendas, así trabajamos el software a medida. Y si tu caso toca cumplimiento financiero más serio, lo que te obliga la normativa fintech merece su propio análisis.