LunApp
LunApp como plataforma multi comercio
Ultima actualizacion: Junio 2026
LunApp esta estructurada para que cada comercio conecte y opere sus propios activos de Meta y WhatsApp mediante el onboarding oficial. Esta separacion reduce mezcla de activos, mejora la trazabilidad y ayuda a sostener el cumplimiento operativo.
Principios del modelo
LunApp opera como capa tecnologica para comercios independientes, no como un numero compartido entre varios negocios.
Cada comercio mantiene propiedad y control administrativo sobre sus propios activos de Meta y WhatsApp.
La asociacion entre comercio, WABA, Phone Number ID y permisos se conserva de forma aislada para trazabilidad y soporte.
Aislamiento por comercio
Cada comercio debe conectar su propio Business Manager autorizado, su propia WABA y su propio numero.
LunApp no debe reutilizar un mismo numero como activo compartido entre varios comercios.
Los permisos, tokens y eventos webhook deben asociarse al comercio correcto para mantener trazabilidad y aislamiento.
El comercio sigue siendo responsable de la base legal para contactar a sus clientes y del cumplimiento de las politicas de mensajeria de Meta.
Autonomia del proyecto LunApp
LunApp debe mantener su propio repositorio, despliegue, variables de entorno y ciclo de cambios.
Cualquier backend, persistencia, facturacion o panel operativo futuro de LunApp debe vivir dentro de su propia arquitectura y no depender de otro proyecto ajeno.
No se deben compartir tokens, webhooks, colas, bases de datos ni estados administrativos con otros sistemas.
Toda nueva integracion de Meta para LunApp debe apoyarse solo en documentacion, APIs, SDKs y lineamientos oficiales vigentes.
Este sitio y cualquier backend futuro de LunApp deben mantenerse como una solucion aislada, con su propio control operativo y sin depender de repositorios o servicios ajenos para la logica central.
Controles operativos
Minimo privilegio: solo solicitar permisos y accesos que el flujo oficial exige para coexistencia.
Aislamiento por comercio: no mezclar historial, contactos ni tokens entre comercios distintos.
Prevencion operativa: suspender integraciones o comercios cuyo uso exponga a LunApp o a Meta a abuso, spam o incumplimientos.
Procesamiento eficiente: historial y sincronizaciones pesadas deben ejecutarse en backend asincrono, no en la interfaz publica.
Ruta por comercio
1. Completar la configuracion publica de la app y el producto Facebook Login for Business en developers.facebook.com.
2. Verificar negocio y solicitar Advanced Access unicamente para los permisos oficiales del caso de uso.
3. Lanzar Embedded Signup con response_type=code, override_default_response_type=true y los extras oficiales del flujo de coexistencia.
4. Canjear el code en backend y suscribir la app a /<WABA_ID>/subscribed_apps antes de operar el comercio.
5. Procesar history de forma asincrona y persistir la asociacion WABA ID, Phone Number ID y Business ID por comercio.
Dos capas de administracion
Panel del comercio
Espacio aislado para que cada comercio conecte y administre sus propios activos de Meta y WhatsApp usando el flujo oficial de onboarding.
Iniciar o reintentar Embedded Signup del propio comercio.
Ver el estado del numero conectado, WABA ID, Phone Number ID y Business ID.
Administrar operadores internos autorizados por el comercio.
Consultar estado de mensajeria, historial y sincronizaciones pendientes.
Revisar consumo, vigencia de prueba y estado de su plan dentro de LunApp.
Panel de plataforma LunApp
Espacio exclusivo de la plataforma para cumplimiento, soporte, facturacion, trazabilidad y control preventivo sobre todos los comercios.
Monitorear estado de onboarding y salud de webhook por comercio.
Aplicar suspension preventiva por fraude, spam, deuda o incumplimiento.
Definir y controlar reglas de trial, activacion y facturacion.
Mantener trazabilidad de permisos, IDs y eventos administrativos.
Separar soporte operativo del comercio respecto de la configuracion global de la app de Meta.
Estados operativos por comercio
Borrador: Comercio creado en LunApp, aun sin iniciar onboarding oficial de Meta.
Onboarding pendiente: El comercio puede lanzar Embedded Signup, pero aun no conecta activos.
Onboarding en curso: El comercio ya inicio el flujo oficial y LunApp espera el code o los IDs del activo.
Activos recibidos: LunApp ya conoce Business ID, WABA ID y Phone Number ID del comercio.
Webhook pendiente: Falta completar suscripcion operativa y validacion del activo en backend.
Historial pendiente: El comercio ya quedo conectado, pero aun falta procesar history o sincronizacion inicial.
Activo: Comercio habilitado para operar dentro de los limites del modelo oficial de coexistencia.
Suspendido: Operacion detenida por deuda, riesgo, incumplimiento o decision administrativa.
Desconectado: El comercio retiro o perdio la conexion de sus activos.
Estados de trial y facturacion
Sin prueba: El comercio aun no entra en trial ni en ciclo facturable.
Trial activo: LunApp habilita uso temporal segun politica comercial propia.
Trial vencido: La prueba termino y el comercio debe pasar a plan pagado o quedar limitado.
Plan activo: El comercio tiene plan habilitado y puede seguir operando.
Pago vencido: Existe deuda o pago pendiente; la plataforma debe iniciar controles.
Suspendido por no pago: LunApp detiene operacion no critica hasta regularizar el cobro.
Cancelado: El comercio ya no tiene servicio activo y queda sujeto a retencion y baja controlada.
Dominios minimos de datos
Esta lista define los dominios recomendados para el futuro backend multi-tenant. No se implementan aqui porque este repositorio sigue siendo la capa publica de LunApp.
Dominios de control de plataforma
Identidad y permisos: Asociar cada comercio con sus propios IDs de Meta y WhatsApp. No compartir numeros, tokens ni activos entre comercios distintos. Mantener roles internos separados para comercio y plataforma.
Trial y habilitacion: Controlar ventana de trial por comercio, no de forma global. Permitir onboarding aun en trial, pero con reglas claras de activacion real. Definir que acciones se suspenden al vencer trial o al caer en deuda.
Facturacion y costos: Separar costo externo de Meta del precio SaaS cobrado por LunApp. Medir volumen y uso por comercio para evitar subsidios invisibles. Usar metrica asincrona y agregada; no introducir listeners o procesos persistentes innecesarios.
Soporte y auditoria: Registrar acciones administrativas relevantes por comercio. Mantener trazabilidad de suspensiones, reconexiones y cambios de plan. Dejar visible si el bloqueo proviene de Meta, de LunApp o de un tema de cobro.
Orden recomendado de implementacion
Fase 1: base multi-comercio
Crear entidad comercio y operadores del comercio.
Persistir Business ID, WABA ID, Phone Number ID y estado de onboarding por comercio.
Separar panel del comercio de panel de plataforma desde el inicio.
Fase 2: activacion operativa
Canjear code y suscribir app por comercio.
Procesar history y sincronizacion inicial con jobs asincronos.
Guardar resumenes de uso por comercio para soporte y control.
Fase 3: trial y facturacion
Agregar trial por comercio con fechas y reglas de expiracion.
Definir plan, estado de cobro y razon de suspension.
Medir costo externo de Meta por comercio para conciliacion.
Fase 4: centro de control
Dashboard de plataforma con salud de webhook, onboarding y cobro.
Alertas administrativas y bitacora de acciones.
Controles de suspension preventiva y reactivacion trazable.