Arquitectura y especificaciones.
Ubikapp es un SaaS B2B multi-tenant para comercios en Chile. Enfocado en operar “vida real”: e-commerce + POS + inventario + pagos agnósticos, con seguridad aplicada por base de datos (RLS) y SSR para performance/SEO.
Multi-tenant real: Organización + Tienda
Separación estricta entre “Org” (suscripción, límites, miembros) y “Store” (operación: catálogo, POS, inventario, pagos). Reduce riesgo de fugas de datos y permite escalar a multi-sucursal.
SSR para SEO + “islas” React para interacción
Astro SSR para páginas públicas (catálogo/productos) y React solo donde hay interacción (carrito, formularios, paneles). Menos JavaScript, mejor performance percibida y mejor indexación.
Seguridad basada en RLS (Row Level Security)
RLS actúa como firewall de datos a nivel de filas en Postgres: permisos por org/store/rol. El frontend no “decide” seguridad; la base de datos la impone.
Pagos y eventos: idempotencia + auditoría
Procesamiento por eventos (webhooks) con dedupe y transacciones atómicas para evitar dobles estados. Cada acción sensible queda trazable para soporte y auditoría.
Especificaciones
Tecnología, seguridad y operación.
Descripción técnica pensada para equipos TI/seguridad. Sin promesas infladas: solo arquitectura y decisiones implementables.
Entrega y hosting (Vercel)
- → SSR y rutas server-side desplegadas como funciones (sin administrar servidores).
- → CDN para assets estáticos y delivery global.
- → Configuración enfocada en Web Vitals: HTML rápido + hidratación mínima.
- → Resolución por host/dominio para multi-tenant (tiendas por subdominio o dominio propio).
Capa de datos (Supabase / Postgres)
- → Postgres como fuente de verdad transaccional (órdenes, stock, pagos, auditoría).
- → RLS (Row Level Security) para aislar datos por organización/tienda.
- → Storage para archivos (comprobantes, imágenes, assets según módulo).
- → Edge Functions para lógica server-side (webhooks, normalización, operaciones sensibles).
Seguridad operativa
- → Principio: “service_role solo en servidor”. Nunca se expone en navegador.
- → Credenciales/tokens: no se guardan planos en cliente; se manejan como referencias seguras (*_ref) y flujos server-side.
- → Permisos por rol: miembros de org y usuarios de tienda con alcance controlado.
- → Auditoría: eventos críticos registrables (pagos, cambios administrativos, acciones sensibles).
Pagos agnósticos (0% comisión Ubikapp)
- → Cada tienda conecta su propia pasarela (Ubikapp no custodia fondos).
- → Checkout normalizado por proveedor (payment factory).
- → Webhooks idempotentes para evitar duplicados y estados inconsistentes.
- → Diseño orientado a “cash-in-hand”: el estado cambia solo con confirmación real.
Facturación integrada (SII básico incluido)
- → Incluye emisión de boletas y facturas desde el flujo estándar del sistema.
- → Pensado para operación diaria del comercio (sin herramientas externas).
- → No incluye contabilidad completa (eso es un producto aparte).
Operación y confiabilidad
- → Flujos críticos diseñados para ser trazables (eventos + estados).
- → Validaciones y controles anti-spam en formularios públicos (honeypot, timing).
- → Separación clara entre “billing Ubikapp” (suscripción) y “pagos de tienda” (ventas del comercio).
- → Checklist de soporte: reproducibilidad, logs y auditoría para resolver incidentes.
Nota para evaluación TI
Si tu equipo necesita revisar alcances, roles, aislamiento por tenant, webhooks o flujos de integración, lo resolvemos vía reunión técnica + demo enfocada. Esta página describe la base; la implementación exacta depende del caso (volumen, sucursales, pasarela, operación).
FAQ TI
Preguntas típicas de tecnología.
Respuestas directas para revisión interna.
¿Cómo separan datos entre tiendas (multi-tenant)?
Por diseño de tenancy (Org + Store) y por RLS en Postgres. El acceso a filas se restringe por policies; el SSR resuelve el contexto (store) por dominio/host.
¿Ubikapp cobra comisión por venta o toca el dinero?
No. El comercio conecta su propia pasarela; Ubikapp no custodia fondos. El objetivo es independencia del proveedor y cero comisión Ubikapp por transacción.
¿Cómo evitan “doble procesamiento” en webhooks?
Con idempotencia: dedupe por identificadores del proveedor (event_id / payment_id) y transacciones atómicas para actualizar estado + registrar auditoría.
¿Cómo manejan secretos y credenciales?
Nunca en el cliente. Tokens/secretos se manejan server-side y se almacenan como referencias seguras. El navegador opera con sesiones y permisos de usuario (no con credenciales de sistema).
¿Evaluación enterprise o multi-sucursal?
Para franquicias, grandes volúmenes o requerimientos de integración, coordinamos una revisión técnica y propuesta.
Hablar con equipo corporativo