Integrar delivery con POS de restaurante: guía 2026
Integrar delivery con POS: qué debe ocurrir después de recibir el pedido
Tres tabletas pueden convertirse en una sola pantalla y aun así dejar una operación frágil. Integrar delivery con el POS del restaurante no consiste únicamente en copiar una orden desde un marketplace. La conexión debe interpretar el menú, impedir duplicados, conservar el estado del pedido, enviar la información correcta a cocina y explicar por qué el dinero recibido no coincide con la venta bruta.
La documentación oficial de Uber Eats separa acciones como consultar, aceptar, rechazar, cancelar y actualizar el tiempo de preparación. Los requisitos de integración de DoorDash contemplan validaciones de pedidos, menú, disponibilidad y manejo de fallos. Es decir: una integración real es una máquina de estados con excepciones, no un cable invisible.
Esta guía se concentra en esa implementación. Si aún estás decidiendo si el canal conviene por comisiones, demanda y experiencia del cliente, empieza por la estrategia de delivery para restaurantes. Aquí partimos de que el canal ya existe y debe conectarse de manera confiable.
Resultado esperado:
- un menú canónico que alimente cada canal;
- pedidos identificados una sola vez;
- estados coherentes entre marketplace, POS y cocina;
- una cola visible para excepciones;
- un procedimiento manual cuando falle la conexión;
- conciliación entre orden, cobro, ajuste y depósito.
Elige una arquitectura que puedas operar
Hay tres rutas habituales. Ninguna es mejor en todos los restaurantes.
| Ruta | Ventaja | Costo operativo oculto | Cuándo evaluarla |
|---|---|---|---|
| Conector nativo | Menos intermediarios y configuración acotada | Dependencia de las funciones que ambas plataformas hayan habilitado | Un POS, pocos canales y compatibilidad confirmada por escrito |
| Middleware o agregador | Normaliza varios canales en un solo flujo | Añade proveedor, soporte, contrato y otra capa de fallos | Varias plataformas, sucursales o menús complejos |
| API directa | Control del modelo de datos y las excepciones | Desarrollo, monitoreo y mantenimiento permanentes | Equipo técnico responsable y acceso autorizado a las APIs |
No asumas que una API pública equivale a acceso inmediato. Los requisitos de integración de DoorDash Marketplace describen acceso y certificación antes de producción. La autenticación de Uber Eats utiliza credenciales y alcances cuya habilitación en producción puede requerir aprobación. Rappi distingue entre una conexión directa y el uso de un socio integrador.
Antes de firmar, pide una matriz de compatibilidad que incluya país, versión de POS, sucursal, marketplace, función, responsable de soporte y evidencia de una prueba reciente. “Tenemos integración” no responde si transmite modificadores, propinas, reembolsos o disponibilidad.
Define la fuente de verdad de cada dato
Cuando dos sistemas pueden editar el mismo campo, tarde o temprano divergen. El equipo debe decidir quién manda:
| Dato | Fuente recomendada | Pregunta de control |
|---|---|---|
| Identidad del producto | Catálogo canónico | ¿Un SKU conserva el mismo ID aunque cambie de nombre? |
| Precio por canal | Sistema autorizado por finanzas | ¿Incluye impuestos, promociones y recargos de forma explícita? |
| Disponibilidad | Inventario o control operativo elegido | ¿Qué ocurre si la actualización llega tarde? |
| Horario y capacidad | Operación de la sucursal | ¿Quién puede pausar y reactivar pedidos? |
| Estado del pedido | Flujo acordado con cada plataforma | ¿Qué sistema puede cancelar o marcar listo? |
| Pago y depósito | Marketplace más conciliación contable | ¿Se separan venta, comisión, ajuste, devolución y depósito? |
El POS no debe convertirse por accidente en la fuente de todos los datos. Puede ser el registro de venta mientras otro sistema gobierna la disponibilidad y el marketplace conserva el pago. Lo importante es documentar la relación.
Construye un menú canónico antes de conectar canales
La causa más visible de fallos es el mapeo incompleto. Un platillo no es solo un nombre: tiene identificador, categoría, formato, precio, impuesto, modificadores, mínimos, máximos, disponibilidad y relación con cocina.
Empieza con una tabla por artículo:
- ID interno persistente y SKU del POS;
- ID asignado por cada marketplace;
- nombre operativo y nombre comercial;
- sucursal y horario;
- modificadores obligatorios y opcionales;
- límites de selección;
- estación de cocina;
- precio, impuesto y promoción;
- regla para agotados y sustituciones.
DoorDash recomienda evitar publicaciones duplicadas de menú y documenta la actualización de estado de artículos agotados. Eso no significa que toda plataforma o POS mantenga inventario “en tiempo real”. La frecuencia, el sentido de la sincronización y el comportamiento sin conexión deben probarse.
Prueba combinaciones difíciles: dos tamaños, modificadores anidados, un extra con costo, una instrucción libre, un artículo agotado y una promoción. Un menú que pasa la prueba del producto simple todavía puede fallar en el pedido real.
Diseña el ciclo completo del pedido
Un flujo robusto puede describirse así:
- El marketplace notifica un evento.
- La integración verifica origen, firma y estructura.
- Registra el ID externo y descarta reintentos ya procesados.
- Consulta o valida la orden completa.
- Decide si puede aceptarse según horario, menú y capacidad.
- Crea una sola orden en el POS.
- Envía la información necesaria al KDS o impresora.
- Propaga los cambios de estado permitidos.
- Conserva eventos, tiempos, errores y responsable de intervención.
- Incluye la orden en la conciliación del depósito.
Los webhooks de Uber Eats utilizan una firma para comprobar la procedencia del evento y contemplan reintentos. Por eso la idempotencia es obligatoria: recibir dos veces la misma notificación no debe crear dos comandas. Responder al webhook tampoco sustituye aceptar o rechazar la orden en el flujo correspondiente.
Define estados internos capaces de representar las diferencias entre proveedores: recibido, validando, aceptado, rechazado, en preparación, listo, entregado, cancelado y con incidencia. No fuerces estados distintos dentro de una misma etiqueta si después necesitas explicar un reembolso.
Trata las excepciones como parte del diseño
El camino feliz no basta. Prepara una cola con prioridad, hora, pedido, canal, causa, último estado confirmado y acción disponible. Entre las incidencias que conviene simular están:
- POS o middleware sin conexión;
- sucursal cerrada o saturada;
- producto o modificador desconocido;
- diferencia de precio;
- webhook duplicado o fuera de orden;
- pedido cancelado después de enviarse a cocina;
- impresión fallida;
- reembolso parcial;
- entrega sin depósito asociado.
Cada incidencia necesita propietario y tiempo de escalamiento. Cocina no debería investigar credenciales; soporte no debería decidir una sustitución culinaria. Cuando la automatización se detenga, el procedimiento manual debe especificar quién acepta, cómo evita duplicados y dónde deja evidencia para la conciliación.
Protege credenciales y datos de clientes
Una integración consume datos de terceros; no debe confiar ciegamente en ellos. OWASP recomienda validar y sanear respuestas, usar conexiones cifradas, limitar recursos, controlar redirecciones y fijar tiempos de espera. Además:
- guarda secretos fuera del código y rótalos;
- concede el alcance mínimo necesario;
- registra acciones sin exponer teléfono, dirección o token;
- limita accesos por rol;
- define retención y eliminación;
- documenta incidentes y recuperación.
No amplíes el alcance de pagos sin necesidad. Si la arquitectura almacena, procesa o transmite datos de tarjeta, revisa el alcance aplicable de PCI DSS con especialistas. Integrar el estado comercial del pago no obliga a copiar credenciales de tarjeta al POS.
Ejecuta un piloto que pueda fallar sin afectar toda la operación
Empieza con una sucursal, un canal y una parte representativa del menú. Conserva el proceso anterior como contingencia durante una ventana definida, pero asigna una sola fuente oficial para no duplicar pedidos.
La matriz de prueba debe incluir:
| Prueba | Evidencia de aprobación |
|---|---|
| Pedido simple | ID externo e interno relacionados; precio correcto |
| Modificadores complejos | Cantidad, costo y texto llegan a la estación correcta |
| Agotado | El canal muestra el resultado previsto y queda registro |
| Duplicado | Solo existe una comanda |
| Cancelación | POS, cocina y conciliación conservan el cambio |
| Corte de red | Alerta, contingencia y recuperación verificadas |
| Reembolso parcial | Venta, ajuste y depósito pueden reconciliarse |
Mide tasa de excepciones, órdenes duplicadas, pedidos que requirieron captura manual, latencia por etapa, diferencias de menú y partidas sin conciliar. No prometas un porcentaje universal de mejora: compara contra la línea base del propio restaurante.
Concilia la venta con el dinero recibido
El cierre diario no termina al sumar órdenes. Para cada pedido conserva:
- venta bruta;
- impuestos y propina según su tratamiento;
- descuento financiado por restaurante o plataforma;
- comisión y cargos;
- cancelación o devolución;
- ajuste posterior;
- depósito neto y fecha;
- identificadores del marketplace y POS.
El reporte útil muestra diferencias, no solo totales. Una orden puede existir en ambos sistemas y aun tener distinto importe. Otra puede cancelarse después de producirse. Una tercera puede formar parte de un depósito posterior. La integración debe permitir seguir esa historia sin editar silenciosamente el dato original.
Si también necesitas que la venta descuente existencias, revisa la guía para integrar POS e inventario del restaurante. Esa conexión es posterior: primero demuestra que el pedido y sus modificadores llegan de forma consistente.
Checklist antes de pasar a producción
- Acceso contractual y técnico confirmado para cada país y sucursal.
- IDs, campos y fuentes de verdad documentados.
- Menú y modificadores probados con casos límite.
- Firma, autenticación e idempotencia verificadas.
- Estados y cancelaciones mapeados.
- Cola de excepciones con responsables.
- Procedimiento manual ensayado.
- Credenciales, permisos, registros y retención revisados.
- Conciliación de una muestra completa aprobada.
- Monitoreo, soporte y criterio de rollback acordados.
Una integración confiable no es la que oculta todas las tabletas. Es la que permite saber qué ocurrió con cada pedido, quién intervino y cómo llegó al depósito. Para ordenar el resto del ecosistema operativo, consulta cómo Kavasoft apoya la gestión del restaurante y su programa de vinos.
