# Prompt para Cursor — instalar y comprobar Wompi en GoberData Copia el texto de la sección siguiente en Cursor con el proyecto abierto. El código del ZIP ya implementa la compra de planes; este encargo consiste en integrarlo con tu copia actual y verificar el recorrido completo. ## Texto para Cursor Actúa como desarrollador responsable de GoberData. Revisa primero el repositorio, sus instrucciones y `LEEME_WOMPI.md`. Necesito que termines de instalar y verificar la compra de planes con Wompi en Sandbox. Trabaja sobre el código real de Laravel existente, aplica los cambios necesarios y entrega evidencia concreta. No te limites a explicar una solución ni sustituyas el proyecto por una demostración. ### Objetivo El comprador entra a `/planes`, elige un plan, registra sus datos y paga en Checkout Web de Wompi. Únicamente después de una aprobación verificada por el backend, GoberData activa la membresía y crea o asocia su cuenta y ambiente. Si la cuenta es nueva, envía al correo registrado el usuario, una contraseña temporal y el enlace de ingreso. Debe exigir cambiar esa contraseña al entrar. Una cuenta existente conserva su contraseña. En esta etapa todos los pagos son de prueba. Los ambientes creados por las compras Sandbox son privados, con datos ficticios; no alteran una campaña comercial ni los ingresos reales. El dominio de instalación indicado es `https://goberdata.com`; si estamos en un servidor QA diferente, utiliza su origen real en la configuración y en el webhook y explica esa diferencia. ### Revisión inicial y conservación de datos 1. Identifica qué archivos de esta entrega ya están incorporados. Consulta `docs/ARCHIVOS_CAMBIADOS_WOMPI.txt`, compara versiones y conserva los cambios locales del proyecto. No sobrescribas código nuevo del usuario sin revisarlo. 2. Antes de aplicar en un servidor con datos, conserva una copia recuperable del código y la base de datos mediante el procedimiento existente. No uses `migrate:fresh`, no borres tablas ni ejecutes seeders generales contra una base existente. 3. Mantén `.env`, `APP_KEY`, almacenamiento privado y credenciales existentes. Las cuatro llaves Wompi Sandbox están en el entorno original. No las copies al prompt, al código, a un commit, a un log ni al informe. Si falta una, informa únicamente su nombre. 4. No ejecutes `key:generate` en una instalación existente: las credenciales de perfiles y órdenes están cifradas con la clave actual. 5. Para probar código utiliza base aislada y correo capturado. No ejecutes pruebas que refresquen la base sobre la base del servidor. ### Configuración de pruebas Comprueba estos valores sin revelar los secretos: ```dotenv APP_URL=https://goberdata.com PAYMENTS_ALLOW_LIVE_CHARGES=false PAYMENTS_SANDBOX_EMAILS=BUZON_CONTROLADO_PARA_PRUEBAS PAYMENTS_SANDBOX_MAIL_ENABLED=true MEMBERSHIP_MAILER=smtp MAIL_MAILER=smtp ``` El buzón es un marcador: usa una dirección controlada que el propietario haya indicado. No uses una dirección ficticia para probar entrega real. Conserva servidor, puerto, usuario, contraseña, remitente y TLS del proveedor SMTP actual; comprueba que el remitente esté autorizado. Si `MAIL_URL` está definido, recuerda que puede reemplazar el transporte y la configuración SMTP. Valida que existan los cuatro campos de Sandbox: `WOMPI_PUBLIC_KEY`, `WOMPI_PRIVATE_KEY`, `WOMPI_EVENTS_SECRET`, `WOMPI_INTEGRITY_SECRET`. Los valores públicos y privados y ambos secretos deben pertenecer al mismo comercio y ambiente. No reemplaces las llaves existentes por los marcadores de la documentación. Tras revisar las dependencias y migraciones, ejecuta en la copia apropiada: ```bash composer install --no-interaction --prefer-dist php artisan optimize:clear php artisan migrate --force php artisan goberdata:wompi:sandbox-sync --activar php artisan goberdata:wompi:probar php artisan goberdata:wompi:diagnostico --remoto ``` Corrige los errores concretos del diagnóstico. No interpretes código de salida 0 como una compra completa: solo confirma las comprobaciones que el comando enumera. Su consulta remota valida acceso al comercio con llave pública, no los otros secretos. ### Webhook y procesamiento periódico Configura en el panel de comercios Wompi, ambiente Sandbox, la URL del servidor donde quedó instalado el código: ```text https://goberdata.com/webhooks/membresia/wompi/sandbox ``` La URL debe ser HTTPS y accesible desde Wompi. No basta con añadirla al `.env`. Si no tienes acceso al panel de Wompi, deja la URL exacta y el paso pendiente para el propietario; no afirmes que quedó registrada. El checkout genera automáticamente su URL de retorno. Nunca se debe activar una membresía porque el navegador diga `APPROVED`. Verifica que exista el cron del scheduler de Laravel cada minuto y evita instalarlo dos veces. Ejemplo, adaptando rutas reales: ```cron * * * * * cd /RUTA_REAL_GOBERDATA && /RUTA_REAL_PHP artisan schedule:run >> /dev/null 2>&1 ``` El comando `goberdata:pagos:procesar` procesa confirmaciones pendientes, conciliaciones y la bandeja de accesos. Conserva la contraseña cifrada durante fallos SMTP y la elimina tras enviar. Las entregas de membresías anuladas o vencidas deben descartarse sin bloquear otras compras. Los transportes `log`, `array` o respaldos de captura deben mantener la bienvenida pendiente, sin registrar su contraseña. ### Acceso administrativo y tenant ficticio Comprueba las rutas de ingreso `/login`, panel `/m/dashboard`, superadministración `/superadmin/estadisticas`, ambientes `/superadmin/ambientes` y pasarela `/admin/payment-gateways`. Identifica en la base autorizada qué correo corresponde a la cuenta real del propietario con rol `super_admin`. No presentes como credenciales vigentes las que encuentres en un seeder. No inventes una contraseña ni intentes obtenerla del hash. No restablezcas cuentas existentes como parte de esta instalación; si el propietario necesita recuperación, prepara el procedimiento para la cuenta identificada. Para su laboratorio privado utiliza el comando idempotente existente, sustituyendo el marcador por su correo autorizado: ```bash php artisan goberdata:qa:provision --email=BUZON_CONTROLADO_DEL_PROPIETARIO ``` Comprueba que `qa-juan-villa-aurora`, Villa Aurora QA y Sierra Clara QA sean privados y no aparezcan en catálogos públicos. Conserva los datos sintéticos existentes; no uses `--reset-synthetic` por defecto. El comando indica un archivo privado con contraseñas nuevas; ese archivo no debe publicarse. Una cuenta existente conserva su contraseña. Este aprovisionamiento manual no envía la bienvenida de compra. ### Prueba de compra completa Realiza la compra en Checkout Web de Wompi con los datos oficiales de Sandbox, usando un buzón autorizado y controlado. La persona que realiza la prueba acepta los términos que Wompi muestre; no suplantes su aceptación mediante llamadas automáticas al API. Comprueba y documenta, sin contraseñas ni llaves: 1. Los precios de portada y `/planes` coinciden con el catálogo guardado. El navegador no puede alterar el importe que usa el servidor. 2. Un visitante nuevo autorizado inicia una orden Sandbox. El checkout muestra el ambiente de prueba. Un segundo clic conserva la misma orden. 3. Un pago aprobado se valida por firma del evento y consulta backend de la transacción, comprobando referencia, moneda COP, centavos y ambiente. 4. La aprobación crea una sola membresía, cuenta y ambiente privado. Un webhook repetido no duplica el beneficio ni el correo. 5. El scheduler entrega el correo al buzón registrado. Verifica recepción real, también spam si corresponde. Registra referencia local, ID de transacción, estado y hora; nunca la contraseña. 6. El comprador ingresa con esas credenciales y cambia su contraseña temporal. Después puede usar su panel privado. 7. Un rechazo no crea cuenta ni ambiente y no envía bienvenida. Un estado pendiente no activa acceso anticipadamente. 8. Una compra con cuenta existente exige login y conserva su contraseña. Una compra Sandbox de un cliente comercial no amplía su ambiente real. 9. Un cambio de campaña o ambiente exige un nuevo intento; no reutiliza el checkout anterior. Las órdenes conservan el importe y las credenciales con las que nacieron. 10. Un fallo SMTP conserva la entrega para reintento; una compra anulada no bloquea los siguientes envíos. Usa exclusivamente los datos de pago Sandbox que aparecen en la documentación oficial vigente de Wompi. No uses una tarjeta real. Si falta acceso al servidor, panel de Wompi o buzón, completa la integración y las pruebas aisladas disponibles y deja exactamente identificado lo que falta comprobar. ### Pruebas automatizadas y entrega En un entorno aislado ejecuta: ```bash php artisan test --filter='DemoYMembresia|WompiYQaPrivado|WompiCompraCompleta' ``` Comprueba las rutas modificadas y la compilación de Blade si cambias vistas. Ajusta o añade pruebas únicamente para fallos concretos que encuentres. No declares éxito si quedan errores relevantes. Entrega un resumen de archivos cambiados, resultado de las pruebas, configuración requerida, URLs confirmadas y evidencia del recorrido manual. Distingue entre validación con HTTP/correo simulados y validación real de Sandbox. No declares instalado, webhook registrado o correo recibido si no lo comprobaste. Mantén producción deshabilitada. Al cerrar esta etapa, deja documentado el procedimiento posterior para cargar las cuatro credenciales del perfil `production`, registrar su webhook independiente, validar el comercio y habilitar cobros reales solo cuando el propietario solicite esa transición. ### Referencias oficiales - https://docs.wompi.co/docs/colombia/ambientes-y-llaves/ - https://docs.wompi.co/docs/colombia/widget-checkout-web/ - https://docs.wompi.co/docs/colombia/eventos/ - https://docs.wompi.co/docs/colombia/datos-de-prueba-en-sandbox/ - https://laravel.com/docs/12.x/mail