Cómo añadir pagos a tu app: pago, suscripciones y webhooks

La forma más sencilla de añadir pagos a tu app es Stripe: usa un Payment Link si solo necesitas un botón de «Comprar» y puedes gestionar los pedidos a mano; Stripe Checkout si tu app necesita saber quién ha pagado y reaccionar automáticamente; y Checkout en modo suscripción más el portal de cliente de Stripe para los cobros recurrentes. En todos los casos salvo el más sencillo, también necesitas un webhook: un endpoint del servidor al que Stripe llama cuando un pago se completa. Además, conviene probar todo con las claves de prueba y las tarjetas de prueba de Stripe antes de pasar a las claves reales.

Esta guía explica cada opción, la parte del webhook que la mayoría de tutoriales omiten y lo que hay que comprobar antes de cobrar dinero real. Los detalles de Stripe proceden de su propia documentación a fecha de septiembre de 2026.

Por qué usar un proveedor de pagos

Nunca recopiles números de tarjeta en tus propios formularios. Manejar datos de tarjeta en bruto te somete al PCI DSS (el estándar de seguridad del sector de tarjetas) y supone un riesgo serio. Un proveedor de pagos como Stripe aloja el formulario de pago, guarda la tarjeta, gestiona la autenticación con el banco y le dice a tu app el resultado. Tu app solo ve «el cliente X ha pagado por Y».

Esta guía usa Stripe porque está muy extendido, tiene buena documentación y la admiten la mayoría de creadores de apps con IA. Existen otros proveedores, y algunos actúan como «merchant of record» (vendedor registrado) y asumen por ti la gestión del impuesto sobre las ventas; si la fiscalidad te preocupa, ese modelo merece compararse.

Las tres formas de cobrar con Stripe

Opción	Código necesario	¿Tu app sabe quién ha pagado?	Ideal para
Payment Links	Ninguno	Solo si añades un webhook	Vender unos pocos productos fijos, donaciones, probar la demanda
Checkout (pago único)	Código de servidor para crear una sesión	Sí, mediante webhook	Tiendas, descargas de pago, compras puntuales
Checkout (suscripción)	Código de servidor más gestión de webhooks	Sí, mediante webhook	SaaS, membresías, cualquier cosa recurrente

Payment Links

Un Payment Link es una página de pago alojada en Stripe que creas en el panel de Stripe sin código. Obtienes una URL que puedes poner detrás de un botón de tu app, compartir en un correo o mostrar como código QR. La documentación de Stripe indica que los Payment Links pueden vender un producto, una suscripción o aceptar una donación, y puedes dejar que el cliente elija qué pagar o limitar el número de compras.

La pega: tu app no sabe automáticamente que un usuario concreto que ha iniciado sesión ha pagado. Para una página de donaciones o una pequeña tienda en la que gestionas los pedidos a mano a partir de los correos de notificación de Stripe, sirve. Para «paga para desbloquear las funciones Pro», no.

Stripe Checkout

Checkout es una página de pago que tu servidor crea bajo demanda para una compra concreta. Tu servidor le dice a Stripe qué se compra (y, opcionalmente, qué cliente compra), Stripe devuelve una URL y envías al cliente a ella. La documentación de Stripe lo describe como compatible con pagos únicos y con suscripciones, como página completa alojada en Stripe, como página integrada en tu web o como formulario incrustado.

El flujo:

El cliente pulsa Comprar en tu app.
Tu servidor crea una sesión de Checkout con tu clave secreta, incluyendo un ID que la vincula a tu usuario o pedido.
El cliente es redirigido a Stripe y paga.
Stripe le redirige de vuelta a tu página de éxito.
Stripe envía un evento checkout.session.completed a tu webhook, y tu servidor marca el pedido como pagado o desbloquea el acceso.

El paso 2 debe ocurrir en el servidor, porque usa tu clave secreta. Esa es la principal razón por la que Checkout necesita un backend.

Suscripciones

Las suscripciones usan Checkout en modo suscripción con un precio recurrente que configuras en Stripe. El primer pago funciona como el flujo anterior. Después, las renovaciones, las tarjetas rechazadas, las mejoras de plan y las cancelaciones ocurren con el tiempo, a menudo cuando el cliente ya no está en tu app, así que tu app se entera solo mediante webhooks.

Para que los clientes gestionen su propia suscripción, Stripe ofrece un portal de cliente alojado. Según la documentación de Stripe, allí los clientes pueden actualizar los métodos de pago y los datos de facturación, cambiar o cancelar suscripciones, y ver y descargar facturas. Lo configuras en el panel de Stripe y añades un botón de «Gestionar facturación» que envía al cliente a él. Así te ahorras construir tú esas pantallas.

Webhooks: la parte que no puedes saltarte

Un webhook es una petición HTTP que Stripe envía a tu servidor cuando ocurre algo. (Consulta qué es un webhook para la idea general). La guía de cumplimiento de Stripe es explícita: no puedes fiarte solo de la página de éxito para cumplir los pedidos, porque un cliente puede pagar y perder la conexión antes de que esa página cargue. Para las suscripciones y los métodos de pago diferidos, los webhooks son obligatorios.

Eventos que conviene gestionar

Evento	Qué significa	Qué hace tu app
`checkout.session.completed`	Checkout ha terminado	Marcar el pedido como pagado o activar el acceso
`checkout.session.async_payment_succeeded`	Un método diferido (como un adeudo bancario) se confirmó más tarde	Cumplir el pedido ahora
`checkout.session.async_payment_failed`	Ese pago diferido falló	Avisar al cliente; no cumplir el pedido
`invoice.paid`	Un pago de suscripción se completó, incluidas las renovaciones	Ampliar el acceso
`invoice.payment_failed`	Una renovación falló	Avisar al usuario; Stripe puede reintentarlo
`customer.subscription.updated`	Ha cambiado el plan, o hay una cancelación programada	Actualizar el plan del usuario
`customer.subscription.deleted`	La suscripción ha terminado	Retirar el acceso de pago

Reglas para un gestor de webhooks correcto

Vienen directamente de la documentación de webhooks de Stripe, y los gestores generados con IA a veces se dejan alguna:

Verifica la firma. Cada evento incluye una cabecera Stripe-Signature. Tu gestor la comprueba con el secreto de firma del endpoint (empieza por whsec_). Sin esto, cualquiera podría enviar a tu servidor un falso «pago completado».
Usa el cuerpo de la petición sin procesar. Las comprobaciones de firma fallan si tu framework analiza o modifica antes el cuerpo.
Devuelve una respuesta 2xx rápidamente y haz después el trabajo más lento. Los tiempos de espera cuentan como fallos.
Gestiona los duplicados. Stripe puede entregar el mismo evento más de una vez. Registra los ID de eventos procesados, o haz que el cumplimiento sea seguro aunque se ejecute dos veces.
No des por hecho el orden. Stripe no garantiza que los eventos lleguen en el orden en que ocurrieron.
Espera reintentos. En modo real, Stripe reintenta las entregas fallidas durante hasta tres días, así que una caída breve no pierde pagos, pero tu gestor debe poder con eventos tardíos.

Los webhooks necesitan una dirección HTTPS pública, así que normalmente solo funcionan cuando tu app está publicada (la CLI de Stripe puede reenviar eventos a una máquina local para los desarrolladores).

Un prompt que cubre todo el flujo

Añade una compra única con Stripe Checkout para el «Pro pack» (ID de precio en STRIPE_PRICE_ID). Crea la sesión de Checkout en el servidor usando STRIPE_SECRET_KEY de los secretos, e incluye el ID del usuario que ha iniciado sesión en la sesión. Añade un endpoint POST /api/stripe/webhook que verifique la firma de Stripe con STRIPE_WEBHOOK_SECRET usando el cuerpo de la petición sin procesar, gestione checkout.session.completed y marque a ese usuario como que tiene el Pro pack. Haz que sea seguro si el mismo evento llega dos veces. Páginas de éxito y de cancelación. Nunca expongas la clave secreta al navegador.

Para suscripciones, añade: «Usa el modo suscripción con STRIPE_PRICE_ID. Gestiona invoice.paid, invoice.payment_failed, customer.subscription.updated y customer.subscription.deleted. Añade un botón Gestionar facturación que abra el portal de cliente de Stripe.»

Modo de prueba

Stripe tiene entornos separados de sandbox (prueba) y de producción, con claves distintas. Las claves de prueba empiezan por pk_test_, sk_test_ o rk_test_; las de producción, por pk_live_, sk_live_ o rk_live_. Las transacciones de prueba no mueven dinero.

Tarjetas de prueba útiles de la documentación de pruebas de Stripe (cualquier fecha de caducidad futura, cualquier CVC de tres dígitos):

Número de tarjeta	Resultado
`4242 4242 4242 4242`	El pago se completa
`4000 0000 0000 0002`	La tarjeta es rechazada
`4000 0000 0000 3220`	Requiere autenticación 3D Secure y luego se completa

Prueba al menos:

Un pago correcto desbloquea lo correcto para el usuario correcto
Una tarjeta rechazada muestra un mensaje claro y no desbloquea nada
Cerrar la pestaña del navegador justo después de pagar sigue dando acceso (esto demuestra que funciona el webhook, no solo la página de éxito)
Cancelar en la página de Stripe devuelve al usuario a tu app sin cobrarle nada
En suscripciones: cancela en el portal de cliente y confirma que el acceso termina cuando debe

Puesta en producción

Activa tu cuenta de Stripe con los datos de tu empresa y de tu banco.
Cambia a las claves de producción en los secretos de tu app. Stripe recomienda claves restringidas con solo los permisos que necesita tu integración, en lugar de una clave secreta sin restricciones.
Crea un endpoint de webhook en modo real que apunte a tu app publicada. Tiene su propio secreto de firma, distinto del de prueba: actualízalo.
Vuelve a crear los productos y precios en modo real; los ID del modo de prueba no existen allí.
Haz una compra real pequeña y devuélvela.

Guarda todas las claves en los secretos del proyecto, nunca en el código ni en el chat. Nuestra lista de comprobación de seguridad explica con más detalle las claves y la verificación de webhooks.

Impuestos, devoluciones y papeleo

Los pagos traen obligaciones que el código no resuelve. Esto no es asesoramiento fiscal; consulta con un asesor o gestor.

IVA y otros impuestos sobre las ventas. Según dónde estés tú y tus clientes, puede que tengas que darte de alta, cobrar el impuesto y presentarlo. Stripe Tax puede calcular y recaudar el impuesto en el checkout, vigilar dónde tus ventas pueden generar una obligación y ayudarte con los registros y las declaraciones, pero la responsabilidad sigue siendo tuya. Los proveedores «merchant of record» son una alternativa que asume más parte de esto.
Devoluciones y disputas. Define tu política de devoluciones antes del lanzamiento y publícala en tu web. Las disputas (contracargos) ocurren; guarda registros de lo que se compró y se entregó.
Recibos y facturas. Stripe puede enviar recibos por correo; las empresas pueden necesitar facturas en regla.
Comisiones. Todo proveedor cobra por transacción. Consulta la página de precios actual del proveedor en lugar de fiarte de cifras de artículos.

Qué configuración encaja con tu app

Donaciones o unos pocos productos: Payment Links. Consulta cómo crear una web de donaciones para una ONG.
Una tienda con carrito: Checkout con líneas de producto y un webhook. Consulta cómo crear una tienda online.
SaaS o membresías: Checkout en modo suscripción, webhooks y el portal de cliente. Consulta cómo crear un MVP de SaaS y cómo fijar el precio de un producto SaaS.
Un marketplace que paga a vendedores: una configuración distinta y más regulada (Stripe Connect o similar). Planifícala por separado.

Añadir pagos en Mythex

Los pagos en las apps que creas en Mythex usan tu propia cuenta y tus propias claves de Stripe; no hay un «Conectar Stripe» de un solo clic para tu app. El flujo habitual:

Consigue las claves de prueba de Stripe.
Añade STRIPE_SECRET_KEY (y más adelante el secreto del webhook) a los secretos del proyecto, mediante /secrets, los ajustes del proyecto o la tarjeta de secretos que muestra el agente cuando necesita una clave.
Pide al agente un Checkout con un prompt como el de arriba.
Prueba en la vista previa con tarjetas de prueba. Publica antes de registrar el webhook, ya que necesita tu URL pública.
Tras cambiar a las claves reales, publica de nuevo para que la app en producción las recoja.

Consulta Aceptar pagos con Stripe y Gestionar webhooks en tu backend en la documentación.

Preguntas

¿Cuál es la forma más fácil de aceptar pagos en una app?

Un Payment Link de Stripe no necesita código: lo creas en el panel de Stripe y enlazas a él desde tu app. Si tu app necesita saber quién ha pagado y desbloquear algo automáticamente, usa Stripe Checkout con un webhook.

¿Necesito un webhook para cobrar?

Si tu app tiene que reaccionar a un pago (desbloquear una cuenta, marcar un pedido como pagado, gestionar una renovación), sí. La documentación de Stripe indica que no puedes fiarte solo de la página de éxito, porque el cliente puede pagar y no llegar nunca a ella. Los webhooks también son obligatorios para las suscripciones.

¿Cómo pruebo los pagos sin dinero real?

Usa las claves de API de sandbox (prueba) de Stripe y sus números de tarjeta de prueba, como 4242 4242 4242 4242 con cualquier fecha de caducidad futura y cualquier CVC de tres dígitos. Las transacciones de prueba no mueven dinero real.

¿Stripe se encarga por mí del IVA y de los impuestos sobre las ventas?

Stripe Tax puede calcular y recaudar el impuesto en el checkout y avisarte de dónde podrías tener que darte de alta, pero tú sigues siendo responsable de tus obligaciones fiscales. Consulta con un asesor o gestor para tu caso concreto.