Integración de Pagos Distribuidos para SaaS (Aurex Assembly & Aurex Billing)
Autor: XZanderU
1. Visión Arquitectónica: Enfoque de Microservicios
Para la gestión de suscripciones del ecosistema Aurex, se diseñó e implementó una arquitectura distribuida basada en el principio de Separación de Responsabilidades (Separation of Concerns). El flujo comercial y transaccional se dividió en dos dominios completamente desacoplados:
Aurex Assembly (Main App)
Núcleo del negocio. Gestiona el marketing, la adquisición de usuarios, la lógica de asambleas y la vitrina comercial. Su responsabilidad financiera se limita exclusivamente a capturar la intención de compra.
Aurex Billing (Micro-frontend)
Caja registradora blindada y aislada. No conoce detalles de asambleas; intercepta intenciones de compra, congela precios, renderiza la pasarela y valida respuestas criptográficas.
Esta separación garantiza que cualquier vulnerabilidad, pico de tráfico o actualización en la plataforma principal no comprometa el entorno de procesamiento de pagos.
2. Flujo Transaccional del Ciclo de Vida
El proceso de compra sigue un modelo asíncrono y de transferencia de estado:
Vitrina Comercial: El usuario explora los planes SaaS desde la ruta pública en aurex-assembly.
Intención de Compra (Draft Order): Se genera un registro inmutable con estado PENDING y un código de referencia único atado a un timestamp estricto.
Handshake y Redirección: El usuario es redirigido al micro-frontend (aurex-billing) llevando únicamente el código de referencia en la URL.
Bloqueo y Renderizado: El servicio financiero consulta la BD de forma privilegiada, bloquea el valor (amount_in_cents) y renderiza el widget de Wompi evitando manipulaciones de precios.
3. Estrategia de Seguridad y Prevención de Fraude
El ecosistema implementa tres capas de seguridad robustas:
A. Políticas RLS (Row Level Security) en PostgreSQL
Privilegios mínimos en Supabase. INSERTs públicos y anónimos permitidos, pero lectura (SELECT) bloqueada. El micro-frontend lee mediante un cliente con Service Role Key en entorno seguro SSR.
B. Firmas de Integridad Criptográfica (Frontend)
Se concatena referencia, centavos, moneda y WOMPI_INTEGRITY_SECRET aplicando hash SHA-256 para rechazar transacciones alteradas en el DOM.
C. Validación Anti-Spoofing en Webhook (Backend)
El endpoint /api/webhooks/wompi intercepta el payload, reconstruye el hash localmente usando WOMPI_EVENTS_SECRET y valida el checksum antes de consolidar el pago en Supabase.
4. Stack Tecnológico
- Framework Core: Next.js (App Router, Server Components, API Routes)
- Base de Datos & Auth: Supabase (PostgreSQL, RLS)
- Pasarela de Pagos: Wompi API (Widgets & Event Webhooks)
- Seguridad: Node.js Crypto module (SHA-256 Hashing)