¿Stripe Checkout o Payment Element? Cuál usar en tu app
Checkout alojado, formulario embebido o Payment Element: cómo difieren las interfaces de pago de Stripe en esfuerzo, control y mantenimiento, y cuál elegir.
Read in English →
Para la mayoría de los SaaS pequeños y de las apps hechas con IA, Stripe Checkout es la mejor opción: es una página de pago completa, maneja suscripciones, descuentos, impuestos y decenas de métodos de pago, y es lo que menos código y mantenimiento pide. El Payment Element conviene cuando el formulario de pago tiene que vivir dentro del diseño de tu propia página y estás dispuesto a construir y mantener más partes del flujo. Hoy ya no compiten de verdad: Stripe recomienda usar el Payment Element sobre la misma API de Checkout Sessions.
En esta guía verás las opciones tal como Stripe las ofrece hoy, una comparación lado a lado y una forma simple de decidir.
¿Qué opciones hay ahora?
La documentación de Stripe describe una API recomendada, Checkout Sessions, con tres maneras de mostrarla:
- Página completa. Una página de pago completa hecha por Stripe. Puedes redirigir a ella en el dominio de Stripe o incrustarla en tu sitio. Stripe la marca como la opción recomendada.
- Formulario embebido. Un formulario de pago ya armado que va dentro de tu página, con un resumen de compra más corto.
- Elements. Armas la página tú mismo con componentes como el Payment Element, mientras la Checkout Session sigue resolviendo por detrás los productos, descuentos y suscripciones.
Aparte, puedes usar el Payment Element con la API de Payment Intents, que es de más bajo nivel. Ahí calculas tú el monto final y construyes en tu código los impuestos, descuentos, conversión de moneda y creación de suscripciones. La documentación de Stripe lo dice sin rodeos: elige Payment Intents solo si quieres ser dueño de cada parte de tu checkout.
También existe Payment Links, un enlace sin código a una página de pago de Stripe, útil incluso antes de tener una app.
¿Cómo se comparan?
Según la propia comparación de Stripe:
| Página completa (Checkout) | Formulario embebido | Elements sobre Checkout Sessions | Payment Element + Payment Intents | |
|---|---|---|---|---|
| Mantenimiento | Bajo | Algo | El mayor de los tres | El más alto, la lógica es tuya |
| Dónde vive | Página de Stripe o incrustada | Tu página | Tu página | Tu página |
| Control del diseño | Ajustes de marca | Appearance API | CSS completo vía Appearance API | Total |
| Resumen de compra | Completo, con impuestos, descuentos y pruebas | Más corto | Ninguno, lo armas tú | Ninguno, lo armas tú |
| Suscripciones, impuestos, cupones | Incluidos | Incluidos | Incluidos | Los integras tú |
En todos los casos los datos de la tarjeta se escriben en campos alojados por Stripe, así que los números de tarjeta nunca pasan por tu servidor.
¿Cuándo conviene el Checkout alojado?
Elige la página completa si se cumple alguna de estas condiciones:
- Vendes suscripciones con pruebas gratis, cupones o varios planes. Checkout crea la suscripción por ti; en la guía de suscripciones con Stripe mostramos cómo sincronizarla con tu app mediante webhooks.
- Quieres métodos de pago locales, billeteras y Link sin programar cada uno.
- No tienes un desarrollador a mano para mantener un formulario propio a medida que cambian las APIs de Stripe.
- Quieres estar cobrando esta misma semana.
La contra es visual. El cliente sale de tu diseño (o ve el diseño de Stripe incrustado) y tu control se limita a los ajustes de marca: logo, colores y tipografía. En la mayoría de los SaaS B2B y para profesionales, los compradores están acostumbrados a pagar en una página de Stripe.
¿Cuándo vale la pena el trabajo extra del Payment Element?
Elige Elements cuando el paso de pago tiene que sentirse parte de tu producto:
- Un onboarding de varios pasos en el que el pago es un paso más dentro de la misma pantalla.
- Un marketplace o un flujo de reservas donde la página muestra cosas que el resumen de Checkout no puede, como un mapa o un calendario.
- Necesitas combinar componentes, por ejemplo el Address Element para la dirección de envío y el Express Checkout Element para pagar con billeteras en un clic, con una disposición concreta.
Si vas por este camino, empieza con Elements sobre Checkout Sessions y no con Payment Intents. Stripe sigue encargándose de suscripciones, descuentos e impuestos, y tú solo te encargas de la página. Con Payment Intents también eres dueño de la lógica del dinero, que es justo donde más se equivoca el código de pagos generado por IA: montos calculados en el navegador, descuentos aplicados dos veces o impuestos que faltan.
¿Qué suele fallar en los flujos de pago hechos con IA?
Elijas la interfaz que elijas, se repiten los mismos errores:
- El precio viene del navegador. El frontend manda
amount: 4900y el servidor le cree. Crea siempre la sesión o el intent en el servidor, a partir de un ID de precio o un lookup key. - El acceso se da en la página de éxito. La redirección no prueba que hubo pago. Usa webhooks. Si hay clientes que pagaron y no tienen acceso, empieza por pagos con Stripe en una app hecha con IA.
- La clave secreta está en el código del frontend. En el navegador solo va la clave publicable.
- Se reutilizan Checkout Sessions viejas. Una Checkout Session vence sola a las 24 horas. Crea una nueva cada vez que el usuario hace clic en "Comprar".
¿Cómo decidir en cinco minutos?
Responde tres preguntas:
- ¿Vendes suscripciones o necesitas impuestos y cupones? Si la respuesta es sí, usa Checkout Sessions, como página completa o con Elements.
- ¿El formulario de pago tiene que estar dentro de una página propia? Si no, usa la página completa y listo.
- ¿Tienes a alguien que mantenga código de pagos a medida? Si no, quédate con la página completa aunque un formulario propio se vea mejor.
Un camino habitual es empezar con la página completa y pasar a Elements más adelante para una pantalla concreta. El código del backend cambia poco, porque los dos usan Checkout Sessions.
Respuestas rápidas
¿Con Checkout embebido el cliente se queda en mi dominio? Sí. Tanto la página completa como el formulario embebido se pueden incrustar en tu sitio en lugar de redirigir.
¿Puedo pasar de Checkout al Payment Element más adelante? Sí. Como en ambos casos usas Checkout Sessions, la mayor parte del código del servidor y los webhooks siguen igual.
¿Y en apps móviles? Stripe ofrece un Mobile Payment Element para iOS, Android y React Native. Las reglas de las tiendas para bienes digitales son otro tema; mira nuestro servicio para publicar tu app en App Store.
¿Cuál sale más barato en comisiones? Las comisiones dependen de los métodos de pago y de tu cuenta, así que revisa la página de precios de Stripe en vez de elegir la interfaz por costo.
¿No sabes cuál le sirve a tu app?
Si estás decidiendo entre las dos o desenredando un formulario a medida que generó una herramienta de IA, nuestro servicio de pagos con Stripe puede ayudarte a elegir y a construirlo. Puedes pasar la revisión gratuita de tu app, comparar las opciones en la guía de pagos en línea de Stripe o preguntarnos directamente.
