Constructor de apps con IA y Stripe: cobros y suscripciones
Sí. Stripe es la integración de pagos de Zugo y cubre las dos formas habituales de cobrar: el pago único y la suscripción recurrente. La cuenta de Stripe es tuya, el dinero llega a tu cuenta y las comisiones las fija Stripe, no el constructor. Conectar la integración no consume créditos: esos se gastan en generar y editar el proyecto.
Aceptar dinero cambia el nivel de exigencia de un proyecto, así que conviene mirar con detalle qué resuelve la integración y qué sigue siendo trabajo tuyo.
¿Qué resuelve Stripe y qué sigue siendo tuyo?
Stripe resuelve la parte que nadie debería programar en casa: recibir los datos de la tarjeta, procesar el cobro, gestionar la seguridad del pago y guardar el histórico de transacciones. Tu proyecto no toca en ningún momento el número de tarjeta, y eso es una ventaja de seguridad, no un detalle técnico.
Lo que sigue siendo tuyo es todo lo que rodea al pago. Qué vendes exactamente, a qué precio, en qué moneda, qué recibe el cliente después de pagar y qué pasa si pide la devolución. Esas decisiones no las toma ninguna integración.
También sigue siendo tuya la relación con Stripe. Abres la cuenta, verificas tu identidad o la de tu empresa y aceptas sus condiciones. Si el proyecto un día sale de Zugo, la cuenta de Stripe se queda contigo con todo su histórico.
¿Pago único o suscripción?
La elección determina el resto del proyecto, así que conviene decidirla antes de la primera construcción y no después.
| Modelo | Encaja cuando | Lo que hay que resolver además |
|---|---|---|
| Pago único | Vendes un producto, un archivo, una entrada o una sesión | Entrega tras el pago y política de devolución |
| Suscripción | Das acceso continuo a contenido o a una herramienta | Acceso ligado al estado del pago, cancelación y pago fallido |
| Pago único con acceso | Vendes un curso o material que se consulta después | Cuenta de usuario, si no el cliente pierde lo comprado |
| Donación o pago libre | Proyecto de apoyo, propina, causa | Poco más, es el caso más simple |
La fila de la suscripción es la que más trabajo esconde. Cobrar cada mes es la parte fácil; la difícil es que el acceso se corte cuando el pago falla y vuelva cuando se resuelve. Esa lógica se describe en el prompt y se afina con ediciones, no aparece sola.
Si dudas, empieza por el pago único aunque tu idea final sea una suscripción. Validar que alguien paga una vez es más rápido y no compromete la estructura del proyecto.
¿Cómo describir el cobro en el prompt?
Con los mismos tres elementos siempre: qué se vende, qué pasa justo después de pagar y qué pasa si algo sale mal.
Una descripción floja: "quiero cobrar por el acceso". El modelo tiene que inventarse el precio, el momento de la entrega y el comportamiento ante un fallo.
Una descripción sólida: "Suscripción mensual de $19 que da acceso al área de miembros. El visitante se registra con correo, paga y entra directamente al área. Si el pago mensual falla, pierde el acceso al área pero conserva la cuenta y ve un aviso con un enlace para actualizar la tarjeta. Puede cancelar desde su perfil y mantiene el acceso hasta el final del periodo pagado."
Ahí hay precio, recorrido feliz, recorrido fallido y cancelación. Cada una de esas frases es una decisión que el generador tendría que adivinar si no la escribes, y adivinar mal cuesta ediciones.
¿Qué falta casi siempre en la primera versión?
Cuatro cosas, y las cuatro se notan justo cuando llega el primer cliente real.
La pantalla de después del pago. Un pago que termina en la misma página con un cambio pequeño deja al cliente sin saber si funcionó. Pide una página de confirmación explícita, con lo que compró y qué va a pasar ahora.
El correo de recibo. La confirmación en pantalla se cierra y desaparece; el correo se queda. Esto se resuelve con la integración de Resend y merece describirse a la vez que el cobro.
El estado intermedio. Entre pulsar pagar y recibir la confirmación pasa un momento, y si la interfaz no muestra nada, la gente pulsa otra vez. Un indicador de proceso evita medio soporte.
La política de devolución escrita. No es un detalle legal aburrido: es la respuesta que darás por escrito la primera vez que alguien la pida, y decidirla en caliente sale mal.
¿Qué revisar antes de aceptar el primer pago real?
Cinco pruebas, en este orden, y ninguna se puede sustituir por razonamiento.
Prueba el pago completo desde el móvil, en una red que no sea tu wifi. Es el escenario mayoritario y el que menos se revisa.
Prueba una tarjeta rechazada. El proyecto tiene que decirlo con claridad y dejar reintentar sin volver a empezar todo el recorrido.
Prueba cerrar la pestaña a mitad del pago y volver. El cliente no debe acabar con un cobro sin acceso ni con un acceso sin cobro.
Si vendes suscripción, prueba la cancelación entera y comprueba cuándo se corta realmente el acceso. Esta es la que más veces sale distinta de lo esperado.
Si el proyecto tiene cuentas, prueba con dos usuarios a la vez en dos ventanas: uno que ha pagado y otro que no. Cada uno debe ver exactamente lo suyo. Es la comprobación que separa un proyecto con cobros de un proyecto con cobros y fugas.
¿Cuánto cuesta esto?
Hay tres bolsillos y se confunden con frecuencia.
Los créditos pagan la generación. Una construcción cuesta 6 créditos, una edición 3, una plataforma multipágina 12 por las tres primeras páginas y 3 por cada adicional. El modo Hi-Fi cuesta el doble: 12 y 6. El plan gratuito da 5 créditos, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes.
Las comisiones de Stripe las cobra Stripe sobre cada transacción, con sus propias tarifas según país y método de pago. No pasan por Zugo y no se pagan en créditos.
El tercer bolsillo es el tiempo. Un proyecto con cobros necesita más rondas de prueba que una página informativa, y ese es el coste que más gente olvida presupuestar. Con 200 créditos tienes margen para varias plataformas y sus ediciones, así que el límite práctico suele ser tu atención, no el saldo.
¿Dónde están los límites honestos?
Tres puntos que conviene tener claros antes de cobrar dinero de verdad.
Zugo no sustituye a un equipo de desarrollo en un producto complejo. Un catálogo con variantes, impuestos por región, cupones acumulables y devoluciones parciales es un producto complejo, y la lógica muy específica se afina con ediciones sucesivas en lugar de con un solo prompt.
La comprobación en entorno de pruebas confirma que el proyecto arranca antes de entregártelo, y una construcción que no abre no se entrega. Eso reduce el riesgo de publicar algo roto; no verifica que tu precio esté bien puesto ni que la lógica de acceso sea correcta.
Las obligaciones fiscales y legales de vender son tuyas. Facturación, impuestos y condiciones de venta dependen de dónde estés y de a quién vendas, y ninguna integración responde esa pregunta por ti.
¿Qué hacer ahora?
Decide el modelo de cobro y escribe las cuatro frases del recorrido: qué se vende, qué pasa al pagar, qué pasa si falla el pago y cómo se cancela. Con eso la primera construcción sale mucho más cerca de lo que quieres.
Después conecta Stripe, prueba las cinco situaciones de la lista y solo entonces enseña el enlace. Para el resto del montaje, Supabase para base de datos y acceso cubre las cuentas de usuario, Resend para los correos cubre el recibo y puedo vender lo que construyo responde a la pregunta de propiedad. Puedes montar la primera versión en zugo.dev y probar el recorrido de pago completo antes de anunciarlo.