Reebler

En la mayoría de soluciones de hostelería estas piezas viven separadas. El menú QR resuelve la interacción, el sistema de cocina resuelve la comanda, la pasarela de pago resuelve el cobro y el cumplimiento fiscal se conecta después como una obligación externa. El resultado suele ser una cadena de integraciones donde cada parte entiende solo una fracción del pedido.

Reebler parte de una tesis distinta: el pedido debe ser la unidad operativa central. Eso significa que, desde que el cliente escanea el QR, el sistema ya está modelando una sesión, un contexto de seguridad, una política de cobro, una ruta de cocina y un posible destino fiscal. No se trata solo de mostrar una carta digital; se trata de gobernar el recorrido completo del pedido.

Esa decisión reduce fricción para el cliente final, pero también reduce fricción interna para el restaurante. Cocina, sala y administración no trabajan sobre eventos desconectados, sino sobre estados que derivan del mismo objeto de negocio. En la práctica, eso permite que una decisión como exigir pago antes de cocina o mantener abierta una mesa para varias rondas no sea un parche, sino una configuración del propio flujo.

Cuando el negocio activa cobro online, el restaurante actúa como merchant of record y liquida directamente en su cuenta conectada. Esta decisión es estructural: evita que la plataforma se convierta en una capa de custodia de fondos y mantiene alineado el cobro con el comercio real que presta el servicio.

Desde un punto de vista técnico, esto simplifica algunas responsabilidades y endurece otras. Simplifica la capa de liquidación, porque Reebler no necesita actuar como cámara de compensación. Pero endurece la necesidad de modelar con precisión cuándo un pedido debe considerarse válido, cuándo puede pasar a cocina y qué relación guarda con el cierre de la sesión de mesa.

Por eso el sistema admite varias políticas de cobro. El negocio puede permitir servicio antes del pago, exigir pago antes de cocina o pedir una preautorización al abrir la sesión. Cada una de esas opciones no solo cambia la experiencia del cliente; cambia la semántica del pedido y los estados que el backend debe gobernar.

Esta arquitectura también encaja con el modelo BYOK. El coste transaccional pertenece al restaurante y se liquida contra su proveedor de pago, mientras la plataforma conserva su papel de orquestador. El valor del sistema no depende de tocar el dinero, sino de gobernar bien el flujo.

Cuando un pedido entra en el ciclo fiscal, el sistema genera o puede generar un registro con numeración correlativa, desglose de importes y un hash que referencia al registro anterior dentro de su ámbito fiscal. Esa cadena convierte el histórico en una secuencia auditable y resistente a manipulación posterior.

La intención no es añadir complejidad criptográfica por sí misma, sino garantizar tres propiedades concretas: orden, integridad y verificabilidad. Orden, porque la numeración correlativa evita lagunas arbitrarias. Integridad, porque un cambio sobre un registro histórico rompe la cadena. Verificabilidad, porque el registro queda modelado como una entidad fiscal propia y no como un apéndice opaco del pedido.

El sistema actual opera sobre el flujo de ES_VERIFACTU. La arquitectura, sin embargo, ya está pensada para convivir con más de una jurisdicción y con secuencias fiscales separadas. Esto es importante porque evita acoplar la lógica fiscal al caso español como si fuera la única topología posible, aunque la cobertura efectiva siga siendo hoy específica de esa normativa.

En términos de diseño, esta capa también desacopla dos responsabilidades distintas: crear el registro localmente y enviarlo al proveedor fiscal. Eso permite que el pedido conserve su consistencia interna incluso si el proveedor externo exige reintentos o confirmaciones posteriores.

Un sistema de pedido en mesa funciona mejor cuando el acceso es inmediato, pero ese mismo acceso puede abrir la puerta a pedidos fantasma, uso fuera del local, ocupación indebida de mesas o manipulación del contexto de sesión. El problema no es anecdótico: depende del tipo de local, de su rotación y de su tolerancia a fricción.

Por eso el sistema no impone un único modelo de confianza. Cada negocio puede combinar validación geográfica, PIN diario, validación por red local, activación por staff, preautorización o pago obligatorio antes de cocina. La idea es que una cafetería tranquila y un entorno de mucho volumen no tengan que operar bajo la misma premisa.

La seguridad útil, sin embargo, no puede descansar solo en el cliente. El backend recalcula precios, valida tokens de sesión, exige contexto correcto para operar sobre la mesa y gobierna las transiciones de estado relevantes. Esto convierte la sesión en una frontera de acceso real y al backend en la fuente de verdad para las decisiones críticas.

El enfoque es deliberadamente honesto. El sistema ya incorpora capas maduras de control operativo, pero la documentación interna mantiene separadas las mitigaciones cerradas de la deuda de endurecimiento que sigue abierta. Esa distinción mejora la credibilidad del producto y evita presentar la seguridad como una promesa abstracta.

La mesa física es una referencia insuficiente para gobernar un flujo real. El sistema necesita además una sesión viva que delimite contexto, continuidad y permisos. Esa sesión es la que permite saber si el cliente está operando dentro de un turno activo, si comparte contexto con otros comensales y si el carrito o el estado del pedido siguen siendo válidos.

Esta separación entre mesa y sesión permite soportar varios modelos operativos sin forzar una lógica única. En algunos escenarios la sesión es compartida, persiste durante varias rondas y se cierra con el pago. En otros, especialmente en flujos Express o de takeaway, cada usuario puede generar un contexto más aislado y la sesión termina antes.

La sesión también es el punto donde convergen varias decisiones de seguridad. El token de sesión, el QR dinámico, la activación por staff y la preautorización no son piezas independientes: son mecanismos que endurecen el acceso al mismo contexto operativo.

Desde el punto de vista del restaurante, esto evita dos errores comunes. El primero es cerrar demasiado pronto y romper la continuidad del servicio. El segundo es dejar una mesa abierta más de lo debido y exponerla a reutilización indebida. El cierre de sesión se decide en función de tipo de mesa, estado del pedido y política de pago.

El restaurante puede operar con su propia cuenta de pagos, su propio proveedor fiscal y sus propias claves de IA. Esto no es solo una preferencia comercial; es una decisión de diseño que reduce el lock-in y hace visible el coste real de cada servicio externo.

La plataforma no necesita revender esos servicios para aportar valor. Su papel es orquestar cómo se conectan con el flujo del negocio: qué ocurre cuando se cobra, cuándo se genera un registro fiscal, cómo se digitaliza una carta o cómo se resuelve la configuración por restaurante. El valor está en la coordinación del sistema, no en la captura de dependencias artificiales.

Este enfoque también clarifica responsabilidades. El negocio conserva su relación contractual con los proveedores que soportan coste variable, mientras Reebler se concentra en la capa de producto. Eso simplifica ciertas decisiones económicas y jurídicas, aunque exige una UX administrativa más explícita y una gestión de credenciales cuidada.

BYOK no es gratis. Introduce más configuración y más responsabilidad por negocio. Pero esa complejidad es aceptable si el resultado es un sistema con menos dependencia estructural y con una separación más honesta entre software, fondos y consumo externo.