Para añadir pagos con Stripe a una app creada con IA, elija el producto de Stripe que corresponda a lo que vende (un Payment Link, Checkout o Checkout con suscripción), mantenga la clave secreta de Stripe en el servidor, en una edge function, y deje que un webhook, no la página de éxito, escriba el estado de pago en su base de datos. Después pruebe todo en el modo de prueba de Stripe antes de pasar a producción. Un creador de apps con IA puede escribir todo el código, pero necesita que usted le indique estas decisiones con claridad, paso a paso.
Esta guía cubre las tres opciones de Stripe, la configuración del servidor, el webhook, el portal del cliente, las pruebas y los prompts exactos que conviene enviar. Para el contexto más amplio de la construcción de la app, consulte nuestra guía para crear una app con IA.
Payment Links, Checkout o suscripciones: cuál elegir
Use un Payment Link cuando venda algo sencillo y su app no necesite reaccionar en tiempo real, use Checkout cuando su app decida qué cobrar y quién paga, y use una sesión de Checkout en modo suscripción cuando el acceso dependa de un plan recurrente. Según la documentación de Payment Links de Stripe, un Payment Link es una página alojada por Stripe que usted crea sin código y comparte mediante un enlace, un código QR o un botón de compra incrustable. Puede vender un producto, una suscripción o recibir donaciones, con una personalización visual limitada.
Checkout es el mismo tipo de página de pago, pero su código la crea a través de la API de Checkout Sessions, como describe la documentación de Checkout de Stripe. Eso es lo que permite a su app asociar el pago a un usuario con sesión iniciada, elegir el precio desde su base de datos y devolver al cliente a la pantalla correcta. Checkout puede ser una página alojada por Stripe o un formulario incrustado en su sitio.
| Opción | Código necesario | Sabe qué usuario pagó | Ideal para | Límite principal |
|---|---|---|---|---|
| Payment Link | Ninguno para crearlo | Solo cruzando después el correo o un parámetro de la URL | Una primera venta, un producto puntual, una donación, una preventa | Personalización limitada; su app no interviene a menos que añada un webhook |
| Checkout (pago único) | Una función del servidor | Sí, usted pasa el id de usuario al crear la sesión | Compra de créditos, un informe de pago, un depósito de reserva | Usted mantiene la función y el webhook |
| Checkout (modo suscripción) | Una función del servidor más la gestión del webhook | Sí | Planes de SaaS, membresías, todo lo que se factura cada mes o cada año | Las renovaciones, los pagos fallidos y las cancelaciones llegan más tarde y hay que gestionarlos |
La clave secreta nunca va en el navegador
La clave secreta de Stripe debe vivir solo en un servidor, porque quien la tenga puede crear cobros, emitir reembolsos y leer datos de clientes. Lo único que necesita el navegador es una URL de Checkout de corta duración que su servidor devuelve después de llamar a Stripe. Un creador de apps con IA que pone la clave secreta en un archivo de React ha dejado la app sin protección, y es lo primero que hay que comprobar en cualquier código de pagos generado.
El patrón habitual es una edge function, un pequeño fragmento de código de servidor que se ejecuta junto a su base de datos. El navegador la llama con la sesión del usuario, la función comprueba quién es, crea la sesión de Checkout con la clave secreta y devuelve la URL. La clave se guarda como variable de entorno, nunca en el código. Nuestra guía sobre la seguridad del vibe coding recoge otras comprobaciones útiles para el código generado.
Por qué la base de datos se actualiza desde el webhook y no desde la página de éxito
Marque un pedido como pagado solo cuando Stripe se lo comunique a su servidor mediante un webhook, nunca cuando el cliente llegue a su página de éxito. La página de éxito es solo una pestaña del navegador: puede cerrarse antes de cargar, abrirla alguien que escribió la dirección, o no llegar a verse porque la conexión del cliente se cortó tras pagar. Un webhook es Stripe llamando directamente a su servidor, y la documentación de webhooks de Stripe lo describe como la forma de reaccionar a eventos asíncronos, como la confirmación de un pago por parte del banco, una disputa o el éxito de un pago recurrente.
Un gestor de webhook necesita cuatro propiedades:
- Verifica la firma. Cada petición lleva una cabecera
Stripe-Signature. El gestor la comprueba con el secreto de su endpoint, de modo que se rechaza a un desconocido que envíe falsos eventos de "pagado". La marca de tiempo incluida en la cabecera también limita las repeticiones. - Responde rápido con un código de éxito. Stripe espera una respuesta 2xx. En modo real sigue reintentando una entrega fallida hasta tres días, con esperas crecientes; en modo de prueba hace tres intentos a lo largo de unas horas.
- Es seguro ejecutarlo dos veces. Con los reintentos, el mismo evento puede llegar más de una vez. Guarde el id del evento, o escriba el estado de forma que una segunda ejecución dé el mismo resultado.
- Es accesible sin inicio de sesión de usuario. Stripe no es un usuario con sesión iniciada en su app, así que esta función debe aceptar peticiones sin la comprobación de sesión habitual y apoyarse en la firma.
Qué guardar en la base de datos
Guarde junto a cada usuario el id de cliente de Stripe, el id de suscripción, el plan y el estado de la suscripción, y actualícelos solo a partir de eventos del webhook. Así su app lee una única fila local para decidir qué puede hacer un usuario, sin llamar a Stripe en cada página. Para las suscripciones, la guía de webhooks de suscripciones de Stripe enumera los eventos y estados que hay que gestionar:
| Señal de Stripe | Qué significa | Qué hace su app |
|---|---|---|
invoice.paid | Se pagó una factura, incluida una renovación | Conceder o ampliar el acceso (Stripe aconseja comprobar antes que el estado de la suscripción es activo) |
invoice.payment_failed | Falló un intento de pago | Avisar al cliente y pedirle que actualice su tarjeta |
customer.subscription.updated | Cambió el plan, la renovación o el estado | Copiar el nuevo plan y estado en su tabla |
customer.subscription.deleted | La suscripción terminó | Retirar el acceso de pago |
Estado past_due | El último pago falló, Stripe puede reintentarlo | Avisar al cliente; decidir cuánto tiempo mantener el acceso |
Estado canceled o unpaid | Ya no paga | Revocar el acceso, según las indicaciones de Stripe |
Como los usuarios leen su propio plan en esta tabla, necesita seguridad a nivel de fila: un usuario puede leer su propia fila y nadie puede escribir en ella desde el navegador. Solo escribe la función del webhook, que se ejecuta con una clave de servidor. Nuestra guía de la seguridad a nivel de fila en Supabase explica la política.
Deje que los clientes cancelen desde el portal del cliente
Use el portal del cliente de Stripe para las cancelaciones, los cambios de tarjeta y las facturas, en lugar de construir esas pantallas. Según la documentación del portal del cliente de Stripe, los clientes pueden actualizar sus datos de facturación y sus métodos de pago, cambiar o pausar una suscripción, cancelarla de inmediato o al final del periodo de facturación, y ver o pagar facturas. Se configura en el panel de Stripe.
Su app necesita un solo botón, "Gestionar facturación", que llama a una segunda edge function. La función crea una sesión del portal para el id de cliente de Stripe del usuario con sesión iniciada y devuelve una URL. Dos límites de esa misma página importan: el portal no puede mostrarse dentro de un iframe, y el enlace de una sesión nueva caduca a los 5 minutos, así que créelo cuando el usuario haga clic, no por adelantado. Las cancelaciones hechas allí llegan a su base de datos con los mismos eventos del webhook, así que no hace falta código adicional.
Modo de prueba y tarjetas de prueba
Pruebe todo con las claves de prueba de Stripe antes de tocar el modo real, porque los entornos de prueba están aislados y no mueven dinero real. Según la guía de pruebas de Stripe, nunca debe usar datos de tarjetas reales en las pruebas. Estas son las tarjetas que conviene probar:
| Escenario | Número de tarjeta |
|---|---|
| Pago correcto | 4242 4242 4242 4242 |
| Rechazo genérico | 4000 0000 0000 0002 |
| Fondos insuficientes | 4000 0000 0000 9995 |
| 3D Secure, autenticar salvo que ya esté configurado | 4000 0025 0000 3155 |
Como fecha de caducidad use cualquier fecha futura, como CVC tres dígitos cualesquiera y cualquier valor en los demás campos. Ejecute al menos cuatro escenarios: un pago correcto, una tarjeta rechazada, una cancelación desde el portal y un webhook entregado dos veces. Revise la fila de la base de datos después de cada uno.
Comisiones, impuestos y facturas
La comisión estándar de Stripe por tarjeta es un porcentaje de cada pago más un importe fijo, y ambos varían según el país, así que consulte la cifra de su país en stripe.com/pricing antes de fijar sus precios. No encontramos una tarifa para Estados Unidos en las páginas que pudimos leer en noviembre de 2026, así que aquí no indicamos ninguna comisión por tarjeta. La misma página muestra Billing, el producto de suscripciones, como un cargo aparte sobre el volumen recurrente (0,7 % en pago por uso, comprobado en noviembre de 2026 en la página de precios en francés), y Stripe Tax como otra línea opcional.
A grandes rasgos: Checkout y los Payment Links admiten Stripe Tax, que calcula por usted el impuesto sobre las ventas o el IVA, y Stripe puede enviar recibos y facturas automáticamente. Si debe registrarse y cobrar impuestos depende de dónde estén usted y sus clientes, así que consulte a un asesor fiscal antes del lanzamiento en lugar de preguntárselo a un creador de apps con IA.
Los prompts que enviar, paso a paso
Envíe estos prompts en orden y revise cada resultado antes del siguiente, porque un único prompt que pida pagos, webhooks y portal a la vez produce código difícil de depurar. Cree antes su cuenta de Stripe, un producto y un precio en modo de prueba, y tenga a mano el id del precio. Sustituya las partes entre [corchetes].
- Checkout. "Añade una página de Precios con un plan [Pro] a [19 $ al mes]. El botón Suscribirse llama a una función del servidor que comprueba que el usuario ha iniciado sesión, crea una sesión de Stripe Checkout en modo suscripción para el id de precio [price_xxx] con el id del usuario adjunto y devuelve la URL. Redirige el navegador a esa URL. La clave secreta de Stripe solo debe usarse dentro de esa función."
- Base de datos. "Crea una tabla subscriptions con id de usuario, id de cliente de Stripe, id de suscripción, plan, estado y fin del periodo actual. Añade seguridad a nivel de fila para que un usuario pueda leer solo su propia fila y no se pueda escribir nada desde el navegador."
- Webhook. "Crea una función de webhook de Stripe que verifique la cabecera Stripe-Signature con el secreto del webhook y gestione checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated y customer.subscription.deleted actualizando la tabla subscriptions. Debe ser seguro recibir dos veces el mismo evento y no debe exigir inicio de sesión de usuario."
- Acceso. "Lee la tabla subscriptions para decidir qué puede usar un usuario. Muestra un estado bloqueado con un botón de mejora de plan en [función] para los usuarios cuyo estado no sea active o trialing. No te fíes nunca de la página de éxito para desbloquear nada."
- Portal. "Añade un botón Gestionar facturación en los ajustes que llame a una función del servidor que cree una sesión del portal del cliente de Stripe para el usuario actual y devuelva su URL."
- Fallos. "Cuando un pago falle, muestra un aviso que pida al usuario actualizar su tarjeta, con un enlace al portal."
El primer mensaje es el que más importa; nuestra guía sobre cómo escribir el prompt correcto para crear una app explica por qué.
Cómo lo hace Cadrant
Cadrant, nuestro creador de apps, genera aplicaciones web en React con un backend de Supabase, y gestiona Stripe mediante edge functions de Supabase en su propio proyecto de Supabase. Usted pide la integración en el chat, por ejemplo "Añade pago con Stripe para suscripciones". Cadrant escribe el código de la edge function y la despliega en su proyecto de Supabase. Según nuestra documentación de edge functions, el navegador llama a la función a través de la API de Supabase y las claves nunca llegan a él.
La clave la añade usted mismo en el panel Environment del proyecto, dentro del panel Database, como una variable del tipo STRIPE_SECRET_KEY, y el secreto del webhook como una segunda variable. Según la página de variables de entorno, las variables solo están disponibles para el código de servidor y pueden cambiarse sin volver a desplegar la app. No pegue nunca una clave secreta en el chat. La IA también escribe las migraciones de base de datos con seguridad a nivel de fila, así que la tabla subscriptions del paso 2 sigue las mismas reglas que el resto de sus datos.
Cadrant no es la única forma de hacerlo. Cualquier creador que genere funciones de servidor puede seguir los mismos pasos, y si quiere un control total de la lógica de facturación, sigue siendo buena idea que un desarrollador revise el código generado antes del lanzamiento. En todos los casos Stripe gestiona el dinero y los datos de las tarjetas; su código solo decide quién obtiene acceso.
Cuando los pagos funcionen, publique la app en su propio dominio; nuestra guía para desplegar una aplicación web cubre ese paso.