Pagos reales en una app hecha con IA: Stripe, webhooks e idempotencia
Publicado el 2026-10-27 por frfrand
Cómo completar pagos de una app Lovable o vibe coding: confirmación en servidor, webhooks firmados, reservas y reintentos seguros.
El botón 'Pagar' es la parte fácil
Una demo puede mostrar una animación y cambiar el estado a 'pagado'. Con clientes reales eso no demuestra que el cobro haya ocurrido. Debés confirmar la operación en el backend contra el proveedor de pagos y guardar un estado coherente en tu base. La URL de éxito que ve el usuario no es una fuente fiable de confirmación.
Por qué los webhooks cambian el diseño
Los proveedores pueden enviar eventos repetidos y, según el caso, en orden diferente del esperado. Verificá la firma del webhook, conservá un identificador único y manejá la operación de forma idempotente: si llega el evento dos veces, no se crean dos pedidos ni se cobran dos reservas. Las claves privadas de Stripe, SumUp u otro proveedor nunca van dentro del frontend generado por IA.
Ejemplo: entradas de un tour
El cliente compra dos entradas, pero cierra el navegador antes de que vuelva a la página de confirmación. El pago se completa y el webhook llega dos veces. El backend debe registrar un cobro confirmado, asignar el cupo una sola vez y enviar una confirmación. Si no hay cupos disponibles se inicia una revisión o reembolso según la política comercial, sin inventar un éxito. Probá ese recorrido en sandbox antes de publicar.
Implementación responsable
1. Definí estados: pendiente, confirmado, fallido, reembolsado y cancelado. 2. Creá pagos desde el servidor con claves protegidas. 3. Verificá firma y origen de cada webhook según el proveedor. 4. Registrá IDs únicos para evitar operaciones duplicadas. 5. Validá disponibilidad en la base mediante transacciones. 6. Probá expiración, fallos, reintentos y conciliación de ingresos.
No todo proveedor funciona igual
Stripe, SumUp y otros tienen eventos, APIs y reglas propias. La idea general de confirmación e idempotencia se mantiene, pero la implementación depende de la documentación oficial y de la región. Tampoco confundas procesar datos de tarjeta en tu servidor con delegar el pago en una pasarela: son obligaciones distintas.
Preguntas frecuentes
### ¿La página de gracias confirma el cobro? No. Verificá el pago mediante backend o evento autenticado. ### ¿Qué es idempotencia? Que una misma solicitud repetida no tenga efectos duplicados inesperados. ### ¿Dónde van las claves privadas? En la configuración del servidor, no en JavaScript del navegador. ### ¿Qué hago si falló el email pero el pago fue exitoso? Conservá el pedido y reintentá notificación, sin cobrar otra vez.
Fuentes
¿Y ArduMaker?
Este trabajo encaja en la idea de un servicio que revise código generado por IA, implemente lo necesario y lo lleve a infraestructura operable. La futura página ardumaker.com/lovable presentará esta modalidad de migración y despliegue. La página todavía no existe, por lo que no debe anunciarse como un servicio automático ya disponible. Para los productos que existen hoy podés visitar ardumaker.com. El alcance real se determina con una auditoría: permisos, datos, integraciones y mantenimiento.
Revisión editorial: octubre de 2026. Las referencias oficiales prevalecen sobre ejemplos genéricos; hacé backup y pruebas de staging antes de cualquier intervención en producción.