Agregar pagos a una app web no significa solamente poner un botón que diga “Pagar”. La parte importante es entender toda la lógica que hay detrás: qué está comprando la persona, cómo se valida ese pago, dónde se guarda el estado de la suscripción y cómo se decide quién puede usar las funciones premium.
Esto se vuelve todavía más importante cuando la aplicación utiliza inteligencia artificial. Cada consulta, generación o procesamiento puede tener un costo asociado en tokens y APIs. Si no tienes una estrategia de monetización y control de uso desde el comienzo, puedes terminar con usuarios consumiendo más de lo que están pagando.
En este caso vamos a trabajar con una app React conectada a Supabase, PayPal en modo Sandbox y Google Antigravity con el MCP de PayPal. El objetivo es completar el ciclo entero: crear un plan, cobrar una suscripción de prueba, registrar el estado en la base de datos y habilitar el acceso premium.
Tabla de contenido
- 💡 Antes de programar: define cómo va a ganar dinero tu app
- 🔄 La lógica real detrás de un pago en una app
- 🌎 Elegir PayPal, Stripe u otra pasarela de pago
- 🧰 Preparar PayPal Sandbox y el MCP en Antigravity
- 💳 Crear un modelo gratuito y un plan premium
- 🖥️ Construir una pantalla de precios que conecte con el flujo
- 🧪 Probar una suscripción con cuentas de Sandbox
- ✅ Confirmar que el acceso premium se habilita de verdad
- 🔐 Lo que debes preparar antes de pasar a producción
- 🚀 El pago es una parte del producto, no un añadido final
💡 Antes de programar: define cómo va a ganar dinero tu app
Antes de abrir el editor y conectar una pasarela de pago, hay que responder una pregunta mucho más importante: ¿cuál es la lógica comercial de tu aplicación?
Hoy existen varias formas habituales de monetizar una app web:
- Suscripción mensual: el cobro se realiza automáticamente cada mes mientras la suscripción permanezca activa.
- Suscripción anual: se cobra un periodo completo por adelantado, normalmente con algún descuento frente al plan mensual.
- Paquetes de créditos: la persona compra una cantidad de usos, consultas o acciones dentro de la aplicación.
- Plan gratuito más plan premium: se entrega acceso limitado sin costo y se cobra por desbloquear funciones o uso ampliado.
- Acceso vitalicio: se cobra una vez por acceso permanente.
Para una primera app, sobre todo si tiene funcionalidades de IA, me parece más razonable partir con una suscripción mensual o con paquetes de créditos. Son modelos que te dan flexibilidad. Puedes ajustar los límites, el precio y el valor ofrecido a medida que entiendes cómo se comportan los costos reales.
El acceso vitalicio puede ser tentador porque permite recibir dinero por adelantado. Pero es una apuesta riesgosa si tu producto tiene costos continuos. Si una persona paga una vez y sigue generando costos de IA mes tras mes, el negocio puede dejar de ser sostenible muy rápido.
El costo oculto de las aplicaciones con IA
Una aplicación con IA no es igual a una herramienta estática. Cada vez que alguien usa una función conectada a un modelo, hay consumo de API. Por eso no basta con copiar el precio de otra app o definir un plan “porque suena bien”. Hay que investigar cuánto cuesta realmente cada acción.
La investigación debería considerar qué API vas a usar, cuánto cuesta cada modelo, cuántos tokens puede consumir una interacción promedio y qué comportamiento podría tener un usuario intensivo. Si no haces ese cálculo, puedes crear un plan barato que atrae mucha gente pero te hace perder dinero con cada uso.
La idea es simple: cada funcionalidad de IA tiene un costo, y tu sistema de pagos debe convivir con ese costo. En algunos casos una suscripción premium puede dar acceso amplio. En otros, lo más sano es limitar el uso mensual o vender créditos adicionales.
🔄 La lógica real detrás de un pago en una app
Cuando una persona paga, no basta con redirigirla a PayPal y mostrar una pantalla de “gracias”. La aplicación debe saber si esa persona realmente pagó, qué plan contrató, si su suscripción sigue activa y qué permisos tiene dentro del producto.
El flujo completo se puede entender así:
- La persona inicia sesión o crea una cuenta en la aplicación.
- Elige un plan, por ejemplo Premium por 20 dólares mensuales.
- La app solicita a PayPal la creación de una suscripción.
- PayPal entrega una URL de aprobación y la persona completa el pago.
- La aplicación recibe y valida el resultado del proceso.
- La base de datos guarda la suscripción, el plan y su estado.
- La app consulta ese estado antes de permitir el uso de funciones premium.
Ese último punto es clave. El acceso no debe depender simplemente de que alguien haya llegado a una URL de éxito. Debe depender de un estado validado y almacenado. Si el plan se cancela, expira o falla un cobro, la aplicación debe poder reflejarlo.
En una arquitectura de este tipo, PayPal se encarga del cobro, Supabase guarda la información de usuarios y suscripciones, y la app React muestra la interfaz correcta según los permisos disponibles.
Qué datos necesitas guardar
La estructura exacta depende de tu producto, pero como mínimo necesitas relacionar al usuario con su plan y su estado de acceso. Para una app con suscripción y límites de IA, normalmente necesitas registrar:
- El identificador del usuario en tu sistema.
- El plan activo, por ejemplo gratuito o premium.
- El identificador de producto o plan creado en PayPal.
- El identificador de la suscripción de PayPal.
- El estado de la suscripción.
- Las fechas relevantes de activación o renovación.
- El uso acumulado si vas a controlar créditos, consultas o acciones de IA.
Por eso, aunque el botón de pago es la parte más visible, la integración real conecta varias piezas al mismo tiempo. Usuario, proveedor de pagos, base de datos, plan, suscripción y control de acceso tienen que estar funcionando en sintonía.
🌎 Elegir PayPal, Stripe u otra pasarela de pago
PayPal es una opción práctica para este ejemplo porque tiene herramientas de desarrollo, ambiente Sandbox y una integración MCP disponible en Antigravity. Pero no es la única alternativa.
La mejor pasarela depende de tu mercado, tu país y el tipo de persona que usará tu aplicación. En entornos hispanohablantes puedes encontrarte con opciones como PayPal, Stripe, RedSys, Paycomet, Mercado Pago, PayU o Pix en Brasil. No se trata de elegir la herramienta más famosa, sino la que tenga sentido para tu caso.
Una forma simple de investigar es pedirle a tu IA favorita una comparación concreta. Por ejemplo:
- Qué medios de pago con API son populares en Latinoamérica.
- Qué opciones funcionan mejor en España.
- Qué pasarela permite suscripciones recurrentes en tu país.
- Qué costos, monedas y métodos de pago admite cada proveedor.
- Qué documentación e integración existen para tu stack tecnológico.
No necesitas ser programador para investigar estas decisiones. Lo importante es comprender los conceptos: una API es el puente que permite que tu aplicación se comunique con una herramienta externa, como una pasarela de pagos.
Para este ejercicio utilizaremos PayPal. Puedes abrir una cuenta y acceder a sus herramientas desde PayPal Developer. Más adelante, si tu producto requiere otro proveedor, la lógica general se mantiene: crear el pago, validar el resultado, guardar el estado y proteger el acceso.
🧰 Preparar PayPal Sandbox y el MCP en Antigravity
Lo primero es trabajar en un ambiente de pruebas. PayPal ofrece dos entornos principales:
- Sandbox: para realizar pruebas sin dinero real.
- Production: para cobrar a clientes reales cuando tu integración esté lista.
Durante el desarrollo, usa Sandbox. Es el lugar para cometer errores, probar flujos, crear cuentas ficticias y validar que todo funcione antes de pasar a producción.
En Antigravity se puede instalar el MCP de PayPal desde el listado de servidores disponibles. Un MCP permite que el agente tenga acceso a herramientas específicas de un servicio. En este caso, herramientas para crear productos, planes, facturas, suscripciones y consultar información de PayPal.
La configuración requiere un access token y seleccionar el ambiente Sandbox. Para obtener el token necesitas ingresar al dashboard de PayPal Developer y utilizar las credenciales de una aplicación.
Client ID, Secret y access token
Dentro del dashboard de PayPal Developer debes crear o abrir una aplicación de Sandbox. Allí encontrarás dos datos importantes:
- Client ID
- Secret
Con esas credenciales se obtiene un access token. Ese token es el que se incorpora en la configuración del MCP para que Antigravity pueda interactuar con las herramientas de PayPal dentro del ambiente de pruebas.
Las credenciales son sensibles. No deben quedar expuestas en el frontend de la aplicación ni compartirse públicamente. Aunque en este ejercicio se trabaja en Sandbox, el hábito correcto es tratar estos datos como secretos desde el primer día.
Una vez guardada la configuración puede aparecer algún error inicial de instalación. No siempre significa que toda la integración falló. En este caso fue necesario revisar la configuración del servidor MCP y reiniciar Antigravity para cargar correctamente las herramientas.
Después del reinicio, quedaron disponibles herramientas como crear factura, listar facturas, crear producto y gestionar suscripciones. Ese es el punto en que el agente ya puede ayudar a construir la parte de pagos dentro del proyecto.
💳 Crear un modelo gratuito y un plan premium
Con el MCP funcionando, el siguiente paso es definir una oferta mínima para probar el sistema. Para avanzar rápido se puede crear una estructura simple:
- Plan gratuito: asignado automáticamente a las personas que se registran por primera vez.
- Plan premium: acceso ilimitado por 20 dólares mensuales.
El precio de 20 dólares es solo un ejemplo de implementación. En una aplicación real ese valor debe venir de una decisión comercial respaldada por los costos de la herramienta, el uso esperado y el valor entregado.
El agente puede recibir una instrucción clara: crear la pantalla de precios, asignar el plan gratuito a nuevos usuarios, crear el plan mensual de 20 dólares y agregar las pantallas necesarias para hacer upgrade.
Esto no significa que puedas olvidarte de la lógica. La IA acelera la construcción, pero tú debes definir qué se vende, quién puede usarlo, cuáles son los límites y qué datos deben persistir.
Las tablas de suscripción y uso en Supabase
Al implementar pagos, no basta con crear el producto en PayPal. También debes preparar la base de datos. En este caso se generaron tablas para almacenar suscripciones y uso.
Supabase se encarga de la autenticación y de los datos de la aplicación. Es ahí donde puedes revisar los perfiles de usuarios, ejecutar SQL y confirmar que las tablas se hayan creado correctamente.
La integración puede generar el SQL necesario, pero en algunos casos tendrás que copiarlo y ejecutarlo manualmente desde el editor SQL de Supabase. Es normal. Lo relevante es verificar el resultado: la consulta debe ejecutarse con éxito y las tablas deben aparecer disponibles para que la app pueda guardar el estado de cada cuenta.
Cuando la app crezca, esa información será esencial para responder preguntas como estas:
- ¿Esta cuenta tiene un plan activo?
- ¿Qué plan contrató?
- ¿Puede generar más contenido con IA?
- ¿Ya agotó el uso incluido?
- ¿Debe ver el botón de upgrade o el panel premium?
🖥️ Construir una pantalla de precios que conecte con el flujo
La pantalla de precios no es solamente diseño. Es el punto donde la decisión comercial se transforma en una acción dentro de la app.
En la práctica, la interfaz debe hacer evidentes las diferencias entre el plan gratuito y el premium. La persona debe entender qué obtiene, cuánto cuesta y qué sucede al presionar el botón para mejorar el plan.
Para la prueba se creó una pantalla donde el plan premium tiene un botón tipo “Obtener Premium”. Al pulsarlo, la aplicación debe iniciar la creación de la suscripción mediante PayPal, no simplemente enviar a una URL estática.
Este detalle es muy importante: una URL directa de suscripción no resuelve por sí sola el flujo completo. PayPal requiere crear la suscripción mediante la API y obtener una URL de aprobación. Esa URL es la que permite llevar a la persona al proceso correcto de autorización.
Cuando se intentó el primer flujo, la app llegó a PayPal pero apareció un error en consola. El problema era justamente ese: se estaba intentando usar una URL de suscripción directa sin crear la suscripción correctamente vía API.
Los errores son parte de la implementación
En vez de ignorar el error, conviene aprovecharlo. Copia el mensaje de la consola y también el mensaje visible que entrega la página. Ambos aportan contexto diferente.
Un error de consola puede señalar exactamente dónde está fallando el código. El error visible indica cómo está viviendo el problema la persona que usa tu producto. Con esa información, el agente puede detectar que falta crear la suscripción mediante la API y corregir el flujo.
Esta es una forma muy útil de trabajar con IA: no necesitas adivinar todo. Ejecutas una prueba, capturas el comportamiento, entregas el contexto completo y solicitas una corrección específica. Después vuelves a probar.
🧪 Probar una suscripción con cuentas de Sandbox
Una vez corregida la creación de la suscripción, toca probar el pago sin utilizar dinero real. Para eso PayPal Developer incluye cuentas de Sandbox dentro de sus herramientas de prueba.
Normalmente tendrás al menos dos tipos de cuentas:
- Cuenta personal: representa a quien realiza el pago.
- Cuenta business: representa a quien recibe el pago.
Con la cuenta personal de Sandbox puedes iniciar sesión durante el checkout y aprobar la suscripción de prueba. PayPal también permite trabajar con tarjetas de prueba, pero hay que usar datos válidos para el entorno de Sandbox.
Un problema habitual es intentar pagar con una tarjeta genérica que Sandbox rechaza. Si eso ocurre, no significa necesariamente que tu integración esté rota. Puede ser un detalle de la cuenta de pruebas o de la tarjeta utilizada.
En este caso, la solución fue generar una nueva tarjeta Visa desde el administrador de cuentas Sandbox y asociarla a la cuenta personal. Con una tarjeta de prueba nueva, el proceso pudo continuar correctamente.
Qué debe comprobar una prueba completa
No des por terminado el trabajo cuando aparece el checkout. El objetivo es cerrar el ciclo entero. Una prueba de suscripción realmente útil debería confirmar:
- La persona puede iniciar sesión en la app.
- Puede entrar a la pantalla de upgrade.
- El botón inicia la creación de la suscripción.
- PayPal muestra el proceso de aprobación en Sandbox.
- La cuenta de prueba puede aprobar el cobro.
- PayPal confirma la suscripción activa.
- Supabase registra la información necesaria.
- La app reconoce que esa cuenta ahora tiene acceso premium.
Si fallas en cualquiera de esos puntos, ya sabes dónde investigar. Puede ser la interfaz, la creación de la suscripción, las credenciales, el ambiente configurado, la cuenta Sandbox, la base de datos o la validación del acceso.
✅ Confirmar que el acceso premium se habilita de verdad
Después de aprobar la suscripción de prueba, la aplicación debe actualizar el estado de la cuenta. El resultado esperado no es solo un mensaje de pago exitoso, sino que el usuario vuelva a entrar y aparezca identificado como Premium.
Ese momento confirma que las piezas principales quedaron conectadas: PayPal procesó la suscripción de Sandbox, la aplicación pudo detectar el cambio y el acceso premium se reflejó dentro del producto.
Es justo ahí donde el sistema empieza a tener sentido comercial. Ya no tienes una app con un botón decorativo. Tienes una estructura capaz de distinguir entre plan gratuito y premium, registrar pagos y proteger funcionalidades de mayor valor.
🔐 Lo que debes preparar antes de pasar a producción
Sandbox sirve para aprender y validar. Producción es otro paso. Antes de cambiar el ambiente a Production, revisa cuidadosamente que el flujo completo esté funcionando y que tu producto esté listo para cobrar.
Como mínimo, conviene revisar estos puntos:
- Que las credenciales de producción sean distintas de las de Sandbox.
- Que el plan y el precio estén bien configurados.
- Que la aplicación valide el estado de la suscripción antes de habilitar funciones premium.
- Que los datos de suscripción queden correctamente vinculados a cada usuario.
- Que el mensaje de error sea claro si el pago no puede completarse.
- Que los límites de uso de IA estén alineados con tus costos reales.
- Que las pantallas de precios expliquen bien el valor de cada plan.
Y ojo: una suscripción no debe ser una promesa indefinida de uso ilimitado si la aplicación tiene costos variables de IA. Primero mide. Después ajusta. Puedes comenzar con una oferta sencilla, pero necesitas observar el consumo y tener margen para cambiar límites, precios o paquetes de créditos.
🚀 El pago es una parte del producto, no un añadido final
Muchas personas construyen una app completa y recién al final piensan cómo cobrar. Yo creo que el sistema de pagos debe entrar temprano en la planificación, especialmente cuando existe un costo operativo detrás de cada uso.
La buena noticia es que hoy puedes construir mucho más rápido. Con una app React, Supabase, PayPal Developer y un MCP conectado a Antigravity, puedes crear productos, planes, tablas, pantallas y flujos de suscripción con apoyo de IA.
Pero la herramienta no reemplaza la decisión estratégica. Tú tienes que decidir qué problema resuelve tu app, cuánto vale, cuál es el costo de entregar ese valor y qué tipo de acceso vas a ofrecer.
Si estás trabajando en prompts, automatizaciones o ideas de producto, puedes explorar Primera App. Para aprender y compartir procesos de vibe coding y creación de apps con IA, puedes unirte a la comunidad de vibe coding.
Y si ya tienes un proyecto en marcha y quieres trabajar directamente en su implementación, puedes contar tu caso y solicitar ayuda para tu proyecto.
La meta no es agregar un botón de PayPal. La meta es construir una aplicación donde pago, suscripción, base de datos y acceso premium trabajen como un solo sistema.
