Tu primer cobro: agregar dinero real a tu app hecha con IA sin equivocarte

Hay un momento muy específico en el que una app hecha con IA deja de ser un juguete y se vuelve un negocio: la primera vez que dinero real se mueve a través de ella. Hasta ese punto, los errores son baratos. Un botón roto es molesto. Un total equivocado en una pantalla por la que nadie paga es una errata. Pero el día en que se le cobra a la tarjeta de un cliente real, un error cuesta dinero de verdad — tuyo o suyo — y “así lo construyó la IA” no es una frase que quieras decirle a alguien que está disputando un cargo.

La buena noticia: cobrar pagos en una app hecha con IA es más accesible de lo que suena, si sabes qué partes entregarle a tu creador con IA y qué partes no tocar nunca tú mismo. Esta es una guía sobre esa línea.

La única regla que te mantiene a salvo: nunca guardes números de tarjeta

Empieza aquí, porque es la regla de la que cuelga todo lo demás. Tu app nunca debería ver, guardar ni manejar un número de tarjeta de crédito en bruto. Ni en una base de datos, ni en un formulario que hayas construido, ni “solo temporalmente”. Manejar datos de tarjeta directamente te deja encima una montaña de obligaciones legales y de seguridad que ningún creador primerizo debería cargar.

En su lugar, usas un proveedor de pagos — Stripe es el común, y la mayoría de los creadores de apps con IA lo conocen bien. El proveedor te da un formulario de pago seguro, ya construido. El cliente teclea su tarjeta en el formulario del proveedor, el proveedor le cobra, y tu app solo recibe un mensaje de “sí, esto se pagó”. Tu app sabe que el pago ocurrió. Nunca conoce el número de tarjeta.

Cuando le digas a tu creador con IA que agregue pagos, dilo explícitamente: “Usa Stripe Checkout (o el formulario de pago alojado por Stripe) para que mi app nunca maneje datos de tarjeta en bruto.” Si el creador empieza a generar un formulario a medida con un campo de número de tarjeta, detenlo. Eso es lo único que no quieres que construya.

Qué implica de verdad “agregar pagos”

Ayuda conocer las piezas móviles antes de empezar, para que notes cuándo falta algo. Un flujo de pago funcional tiene cuatro piezas:

Un precio. Lo que estás cobrando, y si es único o recurrente. Esto vive en tu proveedor de pagos, no incrustado en tu app.
Un paso de checkout. El botón que el cliente presiona, que lo envía al formulario seguro del proveedor.
Una confirmación de regreso a tu app. Después del pago, el proveedor le dice a tu app “esta persona pagó por esta cosa”. Esta es la parte que los principiantes más suelen saltarse — y saltársela es cómo terminas con gente que pagó pero no obtuvo acceso.
Un registro de quién pagó por qué. Para que tu app desbloquee lo correcto y para que puedas responder “¿esta persona pagó?” más adelante.

Si tu creador con IA te da un botón de Pagar que cobra una tarjeta pero tu app no hace nada distinto después, construyó la pieza 2 y olvidó las piezas 3 y 4. Ese es el flujo de pago a medio construir más común, y parece que funciona justo hasta que un cliente paga y no recibe nada.

Cómo describirlo a tu creador con IA

Aquí hay un prompt que cubre las piezas de arriba:

Agrega acceso de pago a esta app usando Stripe Checkout. Hay un solo plan: $19/mes.

Cuando un usuario con sesión iniciada presione “Mejorar plan”, envíalo a la página de checkout alojada de Stripe. No construyas un formulario de tarjeta a medida — mi app nunca debe manejar números de tarjeta.

Después de un pago exitoso, marca a ese usuario como “pagado” en la base de datos y desbloquéale la página de Reportes. Después de un pago fallido o cancelado, regrésalo a la página de precios con un mensaje.

Usa un webhook de Stripe para confirmar el pago del lado del servidor antes de desbloquear nada — no desbloquees solo porque el usuario aterriza de vuelta en una página de éxito.

Ese último párrafo es el que separa un flujo de pago real de uno frágil. Dejar que la página de éxito desbloquee el acceso significa que cualquiera que averigüe la dirección de la página de éxito puede desbloquearlo gratis. El webhook — un mensaje directo y verificado de Stripe al backend de tu app — es la señal confiable. Tu creador con IA sabe cómo configurar esto; solo tienes que pedírselo por su nombre.

Prueba con dinero falso antes que con dinero real

Stripe (y la mayoría de los proveedores) te dan un modo de prueba con números de tarjeta falsos que se comportan como reales — incluyendo tarjetas que aprueban, tarjetas que se rechazan y tarjetas que provocan errores. Úsalo. Antes de que una sola tarjeta real toque tu app, recorre cada camino:

Un pago exitoso. ¿Se desbloqueó lo correcto? ¿El estado del usuario cambió a “pagado”?
Una tarjeta rechazada. ¿La app lo manejó con elegancia, o dejó al usuario atorado en una pantalla rota?
Un checkout cancelado — el usuario presiona “atrás” en lugar de pagar. ¿Terminó en algún lugar sensato, todavía sin mejora de plan?
Pagar, luego cerrar sesión y volver a entrar. ¿Sigue siendo “pagado”? (Esto atrapa apps que solo desbloquean el acceso para la sesión actual y lo olvidan al día siguiente.)

Pídele a tu creador con IA los números de tarjeta de prueba, o búscalos en la documentación de tu proveedor. Una tarjeta de prueba común para “este pago aprueba” es una que tu creador puede darte si la pides. Corre los cuatro escenarios. El camino de tarjeta rechazada y el de checkout cancelado son los que los creadores con IA más suelen dejar rotos, porque el camino feliz es el que optimizan.

Los errores que cuestan dinero real

Unos cuantos modos de falla específicos aparecen una y otra vez con los primeros flujos de pago:

Desbloquear en la página de éxito en lugar del webhook. Ya lo cubrimos arriba, pero vale repetirlo porque es el caro. Si tu app desbloquea las funciones de pago en el instante en que el usuario aterriza en /success, estás confiando en que el navegador del usuario sea honesto sobre si pagó. No siempre lo es. Desbloquea en el webhook.

Sin registro de por qué pagaron. Si tu app solo cambia una bandera global de “pagado: sí”, vas a batallar en el momento en que tengas más de un plan, o alguien cancele, o necesites emitir un reembolso. Guarda la cosa específica: qué plan, cuándo y el ID del proveedor para ese pago. Lo vas a necesitar para preguntas de soporte más adelante.

Olvidar que las suscripciones terminan. Un pago único es simple: pagado es pagado. Una suscripción recurrente puede caducar — la tarjeta vence, el pago falla el mes que viene. Si tu app solo escucha “pagaron” y nunca “su suscripción terminó”, vas a tener gente conservando el acceso gratis después de dejar de pagar. Dile a tu creador que maneje también el mensaje de “suscripción cancelada o pago fallido”, no solo el de éxito.

Cobrar el monto equivocado porque el precio vive en dos lugares. Si el precio está escrito en la pantalla de tu app y configurado en tu proveedor de pagos, tarde o temprano se van a desfasar, y un cliente verá $19 pero se le cobrará $29. Mantén el precio en un solo lugar — tu proveedor — y haz que tu app muestre lo que sea que diga el proveedor. Una sola fuente de verdad.

Una lista corta antes de salir en vivo

Antes de cambiar del modo de prueba al dinero real:

Mi app nunca tiene un campo donde alguien teclee un número de tarjeta en bruto.
El pago lo confirma un webhook del proveedor, no el usuario llegando a una página de éxito.
Probé un pago exitoso, una tarjeta rechazada y un checkout cancelado — los tres se comportan sensatamente.
Después de pagar, el acceso sigue desbloqueado tras cerrar sesión y al día siguiente.
Mi app registra por qué pagó cada persona, no solo que pagó.
Si una suscripción caduca, el acceso se retira automáticamente.
Cambié las claves del proveedor del modo de prueba al modo en vivo (fácil de olvidar — tu primer cliente real chocando contra las claves de prueba recibe un error confuso).

Si todas las casillas están marcadas, estás listo para una tarjeta real. Si no, esa es tu próxima conversación con tu creador con IA — antes de compartir el enlace, no después de la primera disputa.

La mentalidad que ayuda

El dinero es la parte de tu app donde “parece que funciona” y “de verdad funciona” están más lejos una de otra. Un diseño roto lo ves de inmediato. Un flujo de pago que desbloquea el acceso sin verificar el pago se ve perfecto — hasta que alguien lo nota y se lo cuenta a sus amigos.

Así que trata el flujo de pago como la única parte de tu app hecha con IA que pruebas como un escéptico. Intenta entrar sin pagar. Intenta romperlo. Paga y luego intenta perder tu acceso. Los 30 minutos que pases tratando de hacerle trampa a tu propia app son el seguro más barato que jamás vas a contratar para ella.

¿A punto de agregar pagos a algo que construiste? Abre tu próxima sesión con el creador con IA describiendo el flujo completo — el precio, el checkout, la confirmación por webhook y qué se desbloquea — todo de una vez, en lugar de solo pedir un botón de Pagar. El botón de Pagar es el 10% fácil. El otro 90% es lo que mantiene el dinero honesto.