Política de privacidad

1. Quiénes somos

Mesalto es un software de gestión para restaurantes que incluye punto de venta, comandas, pantalla de cocina, mesas, caja y reportes. Lo desarrolla y opera Delpa Tecnología, que publica la app para Android en Google Play con el nombre DELPA TECNOLOGIA. La app para Windows no se publica en una tienda de aplicaciones: Delpa Tecnología publica su instalador y sus actualizaciones en GitHub.

Contacto para temas de privacidad: fernando.romero20@gmail.com

2. Quién usa Mesalto y quién responde por los datos

Mesalto no es una app para el público general. La usan los restaurantes que contratan el servicio:

• El personal del restaurant (cajeros, garzones y cocina) usa la app en equipos del restaurant, como tablets, celulares o computadores con Windows. Cada equipo se empareja con un código de un solo uso que genera un administrador, y cada persona entra con su PIN.
• Los administradores del restaurant usan la Administración web con su correo y contraseña. Desde ahí configuran la carta, el personal, los equipos y la caja, y ven los reportes.
• Las empresas con convenio usan el portal de su empresa con un correo y una contraseña que les da el restaurant. Desde ahí mantienen la lista de sus colaboradores con el beneficio.

Frente a los datos, cada uno cumple un rol distinto:

• El restaurant es el responsable de los datos de su operación, de su personal, de los clientes a quienes factura y de quienes le piden por una app de delivery. Decide a quién registra, qué vende, qué se escribe en las órdenes y cómo usa la información.
• Delpa Tecnología es el encargado. Trata esos datos por cuenta del restaurant, siguiendo sus instrucciones y solo para prestarle el servicio. No los usa para fines propios.
• Delpa Tecnología decide por su cuenta solo sobre los datos que necesita para operar y proteger el servicio: las cuentas de administrador, los registros técnicos, los reportes de fallos y las solicitudes de demostración que llegan desde el sitio.
• La empresa con convenio responde por la lista de colaboradores que carga: por tener una base para entregarla y por informar a sus colaboradores. El restaurant la usa para dar el beneficio y cobrarle a la empresa, y Delpa Tecnología la trata por su cuenta, como el resto de su operación. Si el convenio va con la credencial de la empresa, no hay lista: el restaurant responde por los RUT que registra su caja.
• Defontana, el sistema contable que contrata el restaurant para emitir boletas y facturas, trata esos documentos por encargo del restaurant, no nuestro (ver la sección 6).
• Uber Eats, Rappi y PedidosYa responden por los datos que les das al pedir en su app. Si el restaurant conecta una de ellas a Mesalto, la app le entrega tu pedido y nosotros lo recibimos por cuenta del restaurant (ver la sección 6).

Si trabajas en un restaurant que usa Mesalto, si el personal anotó tu nombre en un pedido, si pediste una factura o si pediste por una app de delivery, quien responde por tus datos en Mesalto es el restaurant. Puedes dirigirte a él o escribirnos a nosotros. Si nos escribes, coordinaremos la respuesta con el restaurant.

3. Qué datos tratamos

Personal del restaurant

El administrador registra a cada persona en la Administración web. De cada una guardamos:

• nombre, rol (por ejemplo, cajero o garzón), código de garzón, locales asignados y si está activa o desactivada;
• el PIN de 6 dígitos y la fecha de su último cambio. El PIN lo define un administrador en la Administración web y viaja cifrado a nuestro servidor, que lo convierte en un código que no se puede revertir (hash) y no guarda el PIN. Ese código se copia a los equipos del local para que el personal pueda entrar aunque no haya internet. Cuando escribes el PIN en el equipo, se compara ahí mismo y no se envía a ningún servidor. Como el administrador conoce tu PIN al crearlo, pídele cambiarlo si crees que otra persona lo sabe;
• un identificador interno de la persona, que queda asociado a lo que hace en la app: abrir y cobrar órdenes, anular productos, autorizar descuentos y abrir o cerrar la caja. También queda asociado a cada equipo en que fue la última en entrar con su PIN (ver «Equipos», más abajo). Las comandas de cocina guardan además su nombre.

Administradores

• Correo electrónico y contraseña. Los gestiona el servicio de autenticación (Supabase Auth), que guarda la contraseña solo como un código que no se puede revertir (hash): nadie puede leerla, tampoco nosotros.
• Un identificador interno, asociado a su organización y su rol, y a las acciones que realiza (por ejemplo, crear un código de emparejamiento o editar la carta).
• Su dirección IP al iniciar sesión. La reenviamos al servicio de autenticación para limitar los intentos de acceso por persona, y queda en los registros de ese servicio.
• Una cookie de sesión (ver la sección 14).

Operación del restaurant

• Órdenes: mesa o etiqueta, número de comensales, productos, cantidades, asiento y tiempo, notas de cada producto, anulaciones con su motivo, y descuentos con su nota y quién los autorizó.
• Pagos: monto, propina, medio de pago y, si el medio lo exige, el código de autorización del voucher u otra referencia. Nunca pedimos ni guardamos el número de la tarjeta, su fecha de vencimiento ni el código de seguridad (CVV). Hoy los pagos con tarjeta se registran a mano, porque Mesalto no se conecta a ningún procesador de pagos.
• Caja: turnos, aperturas, movimientos de dinero con su detalle, arqueos y diferencias.
• Boletas, facturas y guías de despacho electrónicas y sus notas de crédito: productos, montos, fecha, folio, timbre electrónico y su estado en el SII. La boleta no lleva datos del cliente; la factura lleva los de quien la pide (ver «Clientes que piden factura», más abajo), y la guía de un consumo con crédito de convenio, los de la empresa.
• Comandas de cocina, con el nombre del garzón y la mesa.

Salvo que pidan factura, Mesalto no pide el RUT, el correo, el teléfono ni la dirección de los comensales. Fuera de la factura y de los pedidos de apps de delivery (más abajo), hay un solo dato de un cliente: un campo opcional, «Nombre del cliente», en la venta de mostrador (hasta 40 caracteres), que se guarda con la orden y se imprime en la comanda. Además, en los campos de texto libre (notas, motivos, detalles) alguien podría escribir datos de personas. Recomendamos al personal no anotar datos personales innecesarios.

Clientes que piden factura

Cuando un cliente pide factura, el cajero o el garzón escribe en el equipo los datos de quien la recibe (el receptor): RUT, razón social, giro, dirección, comuna, ciudad y, si el cliente quiere, un correo. Si el receptor es una empresa, sus datos no son personales, salvo el correo de una persona de contacto (por ejemplo, juan@empresa.cl). Si es una persona natural con giro, todos lo son. Con esos datos:

• enviamos el RUT a Defontana, el sistema contable del restaurant, para mostrar en la caja los datos de su ficha y para emitir la factura. Si el cliente no tiene ficha allí, se crea con los demás datos, incluido el correo (ver la sección 6);
• guardamos una copia junto al pago y otra en la factura, que también pasa a su nota de crédito si se anula. El timbre electrónico de la factura y el de su nota de crédito contienen el RUT y la razón social del receptor;
• guardamos una ficha del cliente en Mesalto, una por RUT en cada restaurant, compartida entre todos sus locales y razones sociales, para que su próxima factura se complete sola. Cuando el personal escribe ese RUT en cualquier equipo de caja o de garzón del restaurant, el equipo muestra los datos de la ficha, incluido el correo. Cada factura reemplaza la ficha con los datos que trae. Estas fichas no se recorren como lista ni se buscan por nombre: la búsqueda por nombre es la de la boleta, en las fichas de Defontana;
• si nuestro servidor rechaza el cobro, lo que subió el equipo, con los datos del receptor, queda en el registro de operaciones rechazadas (ver la sección 9);
• si la emisión falla, el documento guarda el mensaje de error que devuelve Defontana, que podría repetir algún dato del receptor. Ese mensaje se ve en los equipos de caja y garzón del local y en la Administración web, y si alguien vuelve a intentar la emisión queda también en el registro de auditoría.

La factura impresa y su nota de crédito llevan la razón social, el RUT, el giro, la dirección, la comuna y la ciudad del receptor, pero no el correo. Mesalto no le envía la factura por correo al cliente. En la Administración web, el detalle de cada factura muestra los datos del receptor, con el correo, a quienes tienen acceso a los reportes (por omisión, el dueño y los administradores). Quienes administran los equipos pueden ver el contenido de un cobro rechazado.

Clientes que piden boleta a su nombre

Si un cliente pide que su boleta salga a su nombre, el cajero o el garzón busca su ficha en Defontana por una parte del nombre o por el RUT. La búsqueda la hace nuestro servidor: recorre las fichas de clientes que el restaurant tiene en Defontana y le devuelve al equipo hasta 10 que calcen, con el nombre, el RUT, el giro, la dirección, la comuna y la ciudad, sin el correo. Esas fichas no se guardan en Mesalto ni quedan en el equipo. Cada búsqueda queda en el registro de auditoría sin lo que se escribió, y cada equipo puede hacer hasta 30 por hora.

Con la ficha elegida, la boleta se emite a ese cliente: guardamos sus datos junto al pago y en la boleta, y el timbre electrónico contiene su RUT y su nombre. La boleta impresa lleva su nombre y su RUT. En la Administración web, el detalle de la boleta muestra esos datos a quienes tienen acceso a los reportes. Si se paga con una app o una tarjeta de beneficio, la boleta va a la ficha de esa empresa y no a la del cliente.

Clientes que piden por una app de delivery

Si el restaurant conecta Uber Eats, Rappi o PedidosYa a Mesalto, los pedidos que le haces en esa app llegan a nuestro servidor para que el restaurant los prepare. La app envía el pedido con datos tuyos, pero de ti solo guardamos tu nombre y la inicial de tu apellido (por ejemplo, «Juan P.»). Además guardamos:

• el pedido: su código en la app, los productos con sus opciones, cantidades y precios, los descuentos, si lo lleva un repartidor de la app o del restaurant o si lo retiras tú, si está pagado, sus horas y las instrucciones que escribiste;
• el nombre de la orden, con la app, el código y tu nombre (por ejemplo, «Uber Eats · 4F2A · Juan P.»), que se ve en los equipos de caja, de garzón y de cocina y se imprime en la comanda;
• una copia del pedido tal como lo envió la app, ya sin tus datos de contacto, para revisar errores. Se borra a los 7 días (ver la sección 9).

No guardamos tu teléfono, tu dirección, tu RUT u otro documento, tus datos de facturación ni tu correo, aunque la app los envíe: los descartamos al recibir el pedido. Tampoco recibimos los datos de tu tarjeta. Las instrucciones se guardan tal como las escribiste: no incluyas en ellas datos que el restaurant no necesite.

La boleta de tu pedido la emite el restaurant a nombre de la app, no a tu nombre, y no lleva tus datos.

Clientes que usan el asistente del tótem

Si el restaurant enciende el asistente en su tótem de autoatención, puedes hacerle preguntas sobre la carta escribiéndolas o tocando una pregunta sugerida. Para responderte, nuestro servidor envía a Google (Gemini) tu pregunta, lo que llevan conversado, la carta que muestra el tótem y lo que el restaurant le cuenta al asistente sobre su negocio. El asistente no te pide datos personales: no escribas en él tu nombre, tu RUT, tu teléfono ni datos de pago.

No guardamos la conversación. Queda solo en la memoria del tótem y se borra cuando terminas el pedido o el tótem vuelve al inicio. De cada pregunta guardamos el equipo, la hora y su tamaño en tokens, sin el texto, para limitar el uso y mostrarle al restaurant cuánto lo usa.

Colaboradores de empresas con convenio

Un restaurant puede tener convenios con empresas para dar un descuento o un crédito mensual a sus colaboradores. La empresa, o el restaurant por ella, carga la lista. De cada colaborador guardamos:

• RUT y nombre;
• el crédito mensual que le asignó su empresa, si el convenio tiene crédito;
• si está activo y, si se dio de baja, desde cuándo.

No pedimos su correo, su teléfono ni su dirección. La lista la ven quienes administran los convenios del restaurant (por omisión, el dueño y los administradores) y los usuarios del portal de su empresa, cada uno solo la suya. No se copia a los equipos del local: la caja consulta el RUT en línea cuando el colaborador pide su beneficio y recibe solo el nombre de la empresa y el nombre abreviado (por ejemplo, «María P.»), que quedan en la orden. De cada consulta registramos el equipo, la persona de la caja, la hora y los convenios que encontró; si no encontró ninguno, no guardamos el RUT. Cuando alguien carga una planilla, el registro de auditoría guarda cuántas personas entraron, cambiaron o salieron, pero no sus RUT ni sus nombres; cuando cambia a una persona, guarda el crédito y si quedó activa.

Si el convenio va con la credencial de la empresa, no hay lista: quien compra muestra su credencial y da su RUT en la caja. Guardamos solo ese RUT, el convenio, si está activo y desde cuándo, para darle el beneficio y saber cuántas personas lo usan, cuántas veces y con cuánto descuento. La caja recibe el RUT enmascarado (por ejemplo, «RUT **.***.678-9»), que queda en la orden y en el comprobante; esas consultas no van al registro de consultas de RUT. Un convenio con credencial no tiene crédito.

Si el convenio tiene crédito, de cada consumo pagado con él guardamos el RUT, el nombre, la sucursal, la fecha, el monto y la venta a la que corresponde, para cobrarle a la empresa a fin de mes. La empresa ve en su portal la fecha, la sucursal, el colaborador y el monto de cada consumo, pero no qué se compró. La ley exige que cada consumo con crédito salga con una guía de despacho electrónica a nombre de la empresa, y que la empresa reciba una factura al mes: la guía lleva los productos, las cantidades, los montos, la fecha y la sucursal, pero no el nombre ni el RUT del colaborador.

Usuarios de empresas con convenio

De quienes entran al portal de una empresa guardamos su correo, la cuenta con que entran (como la de los administradores, en Supabase Auth), el convenio al que entran, si siguen teniendo acceso, cuándo aceptaron las condiciones del portal y lo que cambian en la lista, en el registro de auditoría.

Empresa y local

Guardamos el RUT, la razón social, el giro, la dirección y la comuna del restaurant; el nombre, la dirección, la comuna y la zona horaria de cada local; y la dirección IP de cada impresora en la red local. Si el restaurant emite boletas o facturas, guardamos además su resolución del SII y las credenciales de su cuenta de Defontana, cifradas. Si el restaurant es una persona natural, su RUT y su dirección son datos personales.

Equipos

De cada equipo emparejado registramos:

• un identificador interno que genera nuestro servidor y una letra (A, B, …);
• el nombre que se le pone (por ejemplo, «Caja mostrador») y su modo: caja, garzón o cocina;
• la versión de la app, la plataforma (Android o Windows) y el modelo o la versión del sistema del equipo (por ejemplo, «Samsung SM-X200»);
• la fecha de emparejamiento y la última conexión, que se actualiza cada vez que el equipo renueva su acceso (más o menos cada 10 minutos mientras está en línea);
• su estado de salud, que el equipo informa cada minuto mientras tiene conexión: cuántos cambios le quedan por subir y desde cuándo, cuántas impresiones fallaron en las últimas 24 horas y cuándo sincronizó por última vez. Sirve para avisar al restaurant si un equipo deja de sincronizar durante el turno. No incluye datos de las órdenes;
• quién lo usa: el identificador interno de la última persona que entró con su PIN y si hay alguien en sesión. El equipo lo informa junto con su estado de salud y también apenas entra o sale alguien. La última persona sigue registrada aunque el equipo vuelva a «¿Quién atiende?». Sirve para saber si una pantalla de cocina está atendida y para avisarle al garzón de una mesa, en su celular, que su comanda está lista;
• en el celular en modo garzón, el token de notificaciones que Google (Firebase Cloud Messaging) le asigna a esa instalación de la app, para enviarle esos avisos. Se guarda en nuestro servidor y no se copia a los demás equipos. Como el resto de los datos del equipo, pasa también por el servicio de sincronización (PowerSync), que no lo entrega a ningún equipo.

La credencial de cada equipo se guarda en nuestro servidor solo como hash.

La app para Android no lee el IMEI, el Android ID, el número de serie, la dirección MAC ni el ID de publicidad.

Registro de auditoría

Para que la operación y la caja sean trazables, registramos las acciones importantes: quién las hizo (una persona del personal, un administrador o un equipo), qué hizo, cuándo y qué valores cambió. Por ejemplo:

• cambios en la carta o en el personal, incluido el nombre;
• anulaciones y descuentos;
• cierres de caja, con lo contado, la diferencia y la nota;
• emparejamiento (con la plataforma y el modelo del equipo) y revocación de equipos;
• reintentos de boletas y facturas que fallaron, con el mensaje de error que tenían.

Cuando alguien cambia un PIN, queda registrado el cambio, pero nunca el PIN.

Diagnóstico y fallos

Usamos Sentry para detectar y corregir errores. La app envía un reporte cada vez que ocurre un error o un cierre inesperado, y también avisa a Sentry si cada sesión de uso terminó bien o con un error. Un reporte incluye:

• el tipo de error y el lugar del código donde ocurrió;
• los eventos previos al error: las llamadas de la app a nuestro servidor (dirección, método y resultado), los mensajes técnicos que registran la app y sus bibliotecas y, en Android, eventos del sistema, como cambios de conectividad, de batería o de pantalla, o el paso de la app a primer o segundo plano. En Android no se registran las pantallas visitadas ni los toques en la pantalla. En Windows sí se registran las pantallas por las que pasó la app, con su dirección interna (que puede llevar identificadores internos de una orden, una mesa o un garzón), pero no el detalle de los clics ni de lo que se escribe en los campos;
• datos técnicos del equipo. En Android, por ejemplo: marca, fabricante, modelo, procesador, sistema operativo y su versión, si el equipo está rooteado, memoria y almacenamiento (totales y libres), nivel, carga y temperatura de la batería, pantalla, idioma, zona horaria, tipo de conexión, hora de encendido y si es un emulador. En Windows, datos del sistema operativo y del navegador integrado en la app, como sus versiones, y la dirección interna de la pantalla en que ocurrió el error;
• la versión de la app y, en Android, un identificador de instalación aleatorio que crea Sentry. No es el Android ID ni el IMEI;
• el código y el modo del equipo (por ejemplo, «B» y «caja») y el identificador interno del local, para saber en qué equipo ocurrió el error.

La app no envía a Sentry el nombre de la persona, su PIN, su correo ni los datos de las órdenes. Tampoco le envía la dirección IP del equipo, y le indica que no la deduzca de la conexión. Aun así, excepcionalmente el texto de un error o de un mensaje técnico podría contener un fragmento de datos de la operación.

En la Administración web y en el sitio público, Sentry recibe los errores, una muestra del 10 % de las mediciones de rendimiento y los pasos previos a cada error: páginas visitadas, elementos en que se hizo clic (identificados por su ubicación en la página, no por el texto escrito), mensajes técnicos y llamadas al servidor. También recibe la dirección visitada, el navegador, el tipo de contenido y si cada sesión terminó bien o con un error. No recibe el contenido de los formularios, las cookies, los datos del usuario ni la dirección IP, aunque las mediciones de rendimiento podrían incluir fragmentos de consultas a la base de datos. En la página pública de una boleta o factura (ver la sección 6), la dirección visitada incluye el código que da acceso a ese documento.

Nuestro servidor también avisa a Sentry cuando rechaza un cambio que subió un equipo o cuando un equipo deja de sincronizar con el turno abierto. Esos avisos llevan el código del rechazo, el tipo de operación, el código y el modo del equipo y los identificadores internos de la organización y del local, pero no el contenido del cambio. Si falla un pedido o la conexión con una app de delivery, el aviso lleva la app y los identificadores internos de la organización, del local y de la conexión, pero no el pedido ni el nombre del cliente. Si Google no acepta un aviso de comanda lista, el aviso a Sentry lleva los identificadores internos de la organización y del local, pero no el token del celular ni el contenido del aviso.

Datos que quedan en el equipo

Para funcionar sin internet, la app guarda en el equipo una copia de lo que necesita:

• la carta y la configuración de la empresa, incluidos sus datos tributarios (RUT, razón social, giro y dirección);
• el personal habilitado en el local, con el hash de cada PIN;
• los equipos del local, con la última persona que entró en cada uno y si hay alguien en sesión, y las direcciones IP de sus impresoras;
• en modo caja o garzón, las órdenes, los pagos, los documentos tributarios y la caja del turno abierto, con los datos del receptor de cada factura, y además los documentos del local que todavía no se emiten o que fallaron, aunque sean de un turno anterior; en modo cocina, solo las comandas de sus estaciones;
• en modo caja o garzón, las fichas de los clientes que pidieron factura en cualquier local del restaurant;
• en modo caja, los pedidos de apps de delivery del turno abierto, con el nombre y la inicial de cada cliente y sus instrucciones;
• los cambios que todavía no se suben, como un cobro hecho sin internet, y los que nuestro servidor rechazó, hasta que alguien marca el aviso como leído;
• en el celular en modo garzón, el token de notificaciones y el identificador de instalación que guarda la biblioteca de Google (Firebase) para recibir los avisos de cocina;
• los intentos fallidos de PIN, que sirven para bloquear el acceso después de varios errores y nunca salen del equipo.

En Android, la credencial del equipo se guarda cifrada con el almacén de claves de Android. En Windows, se guarda cifrada con DPAPI, la protección de datos de Windows, ligada a la cuenta de Windows con que se usa la app. Los datos de la app en un computador con Windows quedan en la carpeta %LOCALAPPDATA%\Mesalto de esa cuenta.

Solicitudes de demostración

Si pides una demostración desde el formulario del sitio, guardamos tu nombre, el nombre de tu local, tu correo y, si los escribes, tu teléfono y tu mensaje, junto con la fecha del envío. Para limitar los envíos repetidos desde una misma conexión guardamos además un código derivado de tu dirección IP con una función de hash (SHA-256); no guardamos la dirección IP. Para enviar la solicitud tienes que aceptar este tratamiento.

4. Qué no hacemos

• No vendemos, arrendamos ni cedemos datos personales.
• No mostramos publicidad, no usamos el ID de publicidad y no armamos perfiles de marketing.
• No usamos analítica de comportamiento, de marketing ni de publicidad, ni herramientas de seguimiento entre apps o sitios, ni cookies de terceros. Solo usamos datos de diagnóstico (Sentry) para analizar fallas y el rendimiento del servicio; Google Play clasifica ese uso como «Análisis».
• No accedemos a la ubicación, los contactos, la cámara, el micrófono, las fotos ni los archivos del equipo.
• No guardamos datos de tarjetas de pago.
• No usamos los datos de quienes piden factura para nada más que emitir sus documentos y completar su próxima factura: no les escribimos ni armamos perfiles con ellos.
• No usamos los datos de quienes piden por una app de delivery para nada más que preparar, entregar y documentar su pedido: no les escribimos ni armamos perfiles con ellos.
• No tomamos decisiones automatizadas que produzcan efectos sobre las personas.

5. Para qué usamos los datos

• Prestar el servicio al restaurant: tomar pedidos, enviarlos a cocina, avisarle al garzón cuando están listos, imprimir, cobrar, emitir sus boletas y facturas electrónicas, llevar la caja, sincronizar los equipos y mostrar reportes.
• Recordar los datos de facturación de los clientes del restaurant, para no volver a pedirlos y evitar errores en su próxima factura.
• Recibir los pedidos de las apps de delivery que conecta el restaurant: prepararlos, avisarle a la app cuando se aceptan, se rechazan, están listos o se entregan, y emitir la boleta de la venta a nombre de la app.
• Mantener la lista de colaboradores con beneficio de los convenios que el restaurant tiene con empresas, o registrar el RUT de quien lo pide con la credencial de su empresa, para dárselo, saber cuánto se usa y, si el convenio tiene crédito, cobrarle a la empresa lo consumido.
• Autenticar al personal, a los administradores y a los equipos, y bloquear los equipos perdidos para que no sigan vendiendo ni sincronizando.
• Mantener la trazabilidad de la operación y prevenir fraudes o errores en la caja.
• Analizar el funcionamiento de la app para detectar, diagnosticar y corregir fallas (análisis de estabilidad y rendimiento).
• Cumplir obligaciones legales, por ejemplo las tributarias, cuando correspondan.
• Responder las solicitudes de demostración: escribirte para coordinarla. No usamos esos datos para enviarte publicidad ni los compartimos con otras empresas.

Tratamos los datos de la operación por cuenta del restaurant, según el acuerdo que tenemos con él. Al restaurant le corresponde contar con una base legal para tratar los datos de su personal y de su operación, como la relación laboral, sus obligaciones legales o el pedido que un cliente le hace por una app de delivery. Hasta el 30 de noviembre de 2026, tratamos los datos de diagnóstico y de seguridad porque son necesarios para prestar el servicio que contrató el restaurant. Desde el 1 de diciembre de 2026, los tratamos sobre la base de nuestro interés legítimo en mantener el servicio seguro y funcionando (artículo 13 de la Ley 19.628, modificada por la Ley 21.719).

El restaurant trata los datos de quienes piden factura para cumplir su obligación tributaria. La ley lo obliga a emitir factura (artículos 53 y 54 de la Ley sobre Impuesto a las Ventas y Servicios) y su reglamento exige que identifique al comprador con su nombre o razón social, RUT, dirección, comuna y giro (artículo 69, letra A, n.° 5, del Decreto Supremo 55 de 1977). Hasta el 30 de noviembre de 2026, esas normas son la autorización legal que pide el artículo 4 de la Ley 19.628. Desde el 1 de diciembre de 2026, la base es el cumplimiento de una obligación legal (artículo 13) y, si el receptor es una persona natural, también la ejecución del contrato con el restaurant.

La ley no exige el correo ni la ciudad: se tratan con la misma base que la ficha del cliente en Mesalto. Hasta el 30 de noviembre de 2026, esa ficha es parte del mismo tratamiento para emitir las facturas. Desde el 1 de diciembre de 2026, se basa en el interés legítimo del restaurant en facturar rápido y sin errores a los clientes que vuelven. Puedes oponerte y pedir que se borre (ver la sección 11).

La lista de colaboradores de un convenio la entrega la empresa, a la que le corresponde contar con una base para hacerlo (como la relación laboral y la aceptación del beneficio por cada colaborador) e informarles. El restaurant la trata para cumplir el convenio que firmó con la empresa. Si el convenio va con la credencial, el RUT lo da la persona para pedir el beneficio: el restaurant lo trata para dárselo y cumplir ese convenio.

Los datos de una solicitud de demostración los tratamos con tu consentimiento, que das al enviar el formulario. Puedes retirarlo cuando quieras pidiendo que borremos la solicitud (ver la sección 11).

6. Dónde se guardan y qué proveedores intervienen

Usamos estos proveedores, que tratan los datos por nuestra cuenta y solo para prestarnos su servicio:

Supabase Inc.

Base de datos, autenticación de administradores y tareas programadas.

Dónde: São Paulo, Brasil.

Vercel Inc.

Aloja la Administración web y la API. Recibe todas las peticiones con su dirección IP y guarda registros técnicos. Su red de entrega guarda una copia del PDF de cada boleta y factura que se abre por su enlace.

Dónde: las funciones corren en São Paulo, Brasil. Su red de entrega y sus registros técnicos se procesan principalmente en Estados Unidos y en otros países donde opera Vercel.

Journey Mobile, Inc. (PowerSync)

Sincroniza los datos del restaurant entre el servidor y los equipos, y mantiene una copia de esos datos.

Dónde: Brasil.

Functional Software, Inc. (Sentry)

Reportes de errores y de rendimiento.

Dónde: Estados Unidos.

Google LLC (Firebase Cloud Messaging)

Entrega en el celular del garzón el aviso de que una comanda está lista. De nuestro servidor recibe el token de notificaciones de ese celular y el aviso: la mesa o el número de la orden, la estación, los productos y los identificadores internos de la orden y de la comanda, sin nombres de personas ni del cliente. Del celular recibe un identificador de la instalación de la app, que no identifica a la persona, y datos técnicos del equipo y de la app, como sus versiones.

Dónde: en la infraestructura global de Google, que puede procesar los datos en cualquiera de sus centros de datos.

Si el restaurant emite boletas y facturas electrónicas con Mesalto, lo hace a través de Defontana, el sistema de gestión (ERP) que contrata el propio restaurant. Defontana trata los datos de esos documentos por encargo del restaurant, según el contrato que tiene con él, y los envía al Servicio de Impuestos Internos (SII), que los recibe porque la ley lo ordena. Nuestro servidor se conecta a Defontana con las credenciales del restaurant y por instrucción suya:

• por cada venta que se documenta, le envía los productos, las cantidades, los montos y la fecha, y recibe el folio y el timbre electrónico. La boleta se emite a un cliente genérico, sin el nombre, el RUT ni otros datos personales del cliente, salvo que el cliente la pida a su nombre;
• en una factura, le envía además el RUT del receptor: cuando el personal lo escribe en la caja o el garzón, para mostrar los datos de su ficha de cliente en Defontana, y después en la venta misma. Cada consulta queda registrada sin el RUT, y cada equipo tiene un límite de consultas por hora. Si la ficha no existe, Mesalto la crea con la razón social, el giro, la dirección, la comuna, la ciudad y, si se escribió, el correo. Si ya existe, Mesalto no la modifica ni la borra, y la factura sale con los datos de esa ficha. Si el equipo no pudo consultarla, por ejemplo sin internet, la factura impresa en el local muestra los datos escritos en la caja.

Si el documento todavía no se emite o no trae su timbre, lo que se imprime, al cobrar o después desde la pantalla Documentos, lleva un código QR hacia una página de Mesalto que muestra la boleta o la factura y, una vez emitida, permite descargar su PDF. A esa página y a su PDF solo se llega con ese código o con su enlace. Los equipos de caja y garzón del local guardan ese código para imprimirlo, el enlace aparece en la Administración web y la API de solo lectura que el restaurant puede conectar a sus propios sistemas entrega el enlace al PDF. En una factura, el timbre de esa página contiene el RUT y la razón social del receptor, y el PDF que genera Defontana muestra sus datos, como cualquier factura.

Si el restaurant conecta Uber Eats, Rappi o PedidosYa, nuestro servidor se comunica con esa app por instrucción del restaurant: recibe sus pedidos, le avisa cuando se aceptan, se rechazan, están listos o se entregan, y le envía la carta del local, lo que está agotado y si la tienda está abierta. No le enviamos datos personales. Cada app trata los datos de sus clientes según su propia política de privacidad.

Si el restaurant enciende el asistente del tótem, nuestro servidor envía a la API de Gemini de Google, con la llave de la cuenta de Google del propio restaurant y por instrucción suya, cada pregunta del cliente con la conversación en curso, la carta del tótem y lo que el restaurant le contó al asistente. Google trata esos datos según los términos de su API y puede procesarlos en cualquiera de sus centros de datos. Mesalto pide que esa cuenta tenga la facturación activa: así, Google no los usa para mejorar sus productos.

La app para Android se distribuye por Google Play. Google trata los datos de tu cuenta Google y de la descarga según su propia política de privacidad; eso es aparte de los avisos de cocina, que Google entrega por nuestra cuenta con Firebase Cloud Messaging (en la lista de arriba). La app para Windows no pasa por Google Play ni por otra tienda: se descarga de GitHub (Microsoft), donde Delpa Tecnología publica su instalador, y cada hora le pregunta a GitHub si hay una versión nueva para descargarla e instalarla. En esas consultas GitHub recibe la dirección IP del computador y la versión que descarga, y las trata según su propia política de privacidad; no recibe datos del restaurant, de su personal ni de sus clientes. Ambas apps están construidas con Expo (650 Industries), pero no le envían datos mientras se usan, porque no usan sus servicios de actualizaciones remotas ni de notificaciones.

Las comandas, precuentas, comprobantes, boletas y facturas se imprimen enviándolos por la red local del restaurant a sus propias impresoras. La impresión no pasa por nuestros servidores.

Revelaremos datos si una ley o una autoridad competente lo exige.

7. Transferencias internacionales

Los datos se alojan fuera de Chile. La base de datos, la ejecución de la API y la sincronización están en Brasil. La red de entrega de la plataforma web (Vercel), que guarda copias de los PDF de boletas y facturas, y sus registros técnicos se procesan principalmente en Estados Unidos, y los reportes de fallos (Sentry), en Estados Unidos. Los avisos al celular del garzón (Google) pasan por la infraestructura global de Google, en cualquiera de sus centros de datos. Los cinco proveedores son empresas extranjeras y pueden acceder a los datos desde otros países para darnos soporte o a través de sus propios subencargados.

Hacemos estas transferencias solo para prestar el servicio y compartimos con cada proveedor únicamente lo que necesita para su función. Si quieres saber qué garantías aplican a cada transferencia, escríbenos.

Defontana es proveedor del restaurant, no nuestro: dónde guarda los datos lo indican su contrato con el restaurant y su propio aviso de privacidad. Lo mismo vale para Uber Eats, Rappi y PedidosYa, a las que no enviamos datos personales.

8. Cómo protegemos los datos

• Toda comunicación entre la app, la Administración web y nuestros servidores va por conexiones cifradas. La app no admite conexiones HTTP sin cifrar. También van cifrados los avisos de cocina que nuestro servidor le envía a Google y lo que la app intercambia con Google para recibirlos. La única comunicación sin cifrar es la que va a las impresoras, por TCP, hacia la dirección IP que configura el administrador, que debe ser de la red local del restaurant.
• Cada restaurant ve solo sus propios datos: la base de datos aplica control de acceso por organización en cada tabla. Cada equipo recibe solo los datos de su organización que necesita: la carta y la configuración de la empresa, el personal habilitado en su local, los equipos y las impresoras del local, la operación del turno abierto de su local, los documentos de su local que todavía no se emiten o que fallaron, sus propias operaciones rechazadas y, en caja y garzón, las fichas de los clientes que pidieron factura.
• Los PIN se guardan solo como un código que no se puede revertir (hash) y, al entrar, se verifican en el equipo.
• Los códigos de emparejamiento duran 10 minutos, sirven una sola vez y se guardan como hash.
• El acceso de cada equipo se renueva cada 10 minutos. Un administrador puede revocar un equipo desde la Administración: la próxima vez que se conecta a internet, el equipo deja de vender y de sincronizar, y borra la copia de los datos del local que guardaba. Si pierdes un equipo, revócalo y, si es Android y puedes, bórralo a distancia con Encontrar mi dispositivo de Google.
• La app para Android excluye sus datos del respaldo en la nube de Google y de la transferencia a otro equipo (por ejemplo, al pasar los datos a un teléfono nuevo).
• Las credenciales de Defontana del restaurant se guardan cifradas y solo las usa nuestro servidor.
• Nuestro servidor solo acepta un pedido de una app de delivery si llega con la firma o el token de esa app. Las credenciales de Mesalto ante cada app se guardan cifradas y solo las usa nuestro servidor.
• El registro de auditoría no se puede modificar ni borrar desde la app ni desde la Administración.

Hay tres límites que el restaurant debe conocer:

• En Android, la copia de datos que queda en el equipo está protegida por el aislamiento entre apps de Android, pero no lleva un cifrado adicional. Por eso recomendamos usar bloqueo de pantalla en los equipos.
• En Windows, la copia de datos queda en el disco, sin cifrar, protegida solo por los permisos de la cuenta de Windows con que se usa la app; quien administre el computador también puede leerla. El cifrado con DPAPI cubre la credencial del equipo, pero no la defiende de otros programas que corran con esa misma cuenta. Por eso recomendamos cifrar el disco (por ejemplo, con BitLocker) y que solo quienes atienden la caja usen esa cuenta.
• La impresión viaja sin cifrar por la red local, así que la red del restaurant debe estar protegida.

9. Cuánto tiempo guardamos los datos

• Datos del restaurant (personal, carta, órdenes, pagos, boletas, facturas con los datos de su receptor, caja y equipos): se guardan mientras el restaurant tenga el servicio activo. Si se desactiva a una persona o se revoca un equipo, sus datos se conservan para mantener la trazabilidad de las ventas y de la caja.
• Fichas de los clientes que pidieron factura: se borran solas 24 meses después de la última factura de ese RUT en el restaurant, o antes si el cliente o el restaurant lo piden. Cada equipo borra su copia la próxima vez que sincroniza.
• Consultas de RUT desde la caja: se borran solas a los 12 meses.
• Conversaciones con el asistente del tótem: no se guardan. El tótem las borra al terminar cada pedido; el conteo de preguntas, sin su texto, se guarda mientras el restaurant tenga el servicio activo.
• Colaboradores de empresas con convenio: se guardan mientras estén activos. Se borran solos 13 meses después de su baja o del término del convenio, o antes si la empresa o el restaurant lo piden.
• RUT de convenios con credencial: se borran solos 13 meses después de su último uso, o a los 7 días si nunca se usaron (por ejemplo, un RUT mal escrito), o antes si la persona o el restaurant lo piden. Sus visitas siguen en las ventas del restaurant, sin el RUT.
• Consumos con crédito de convenio: se conservan 6 años, como respaldo del cobro a la empresa y de las ventas. Al vencer ese plazo, los borramos con un procedimiento manual.
• Pedidos de apps de delivery: la copia del pedido tal como lo envió la app se borra sola a los 7 días. El nombre y la inicial del cliente, el pedido y su venta quedan con las órdenes del restaurant, que son su registro de ventas, mientras tenga el servicio activo.
• Registro de auditoría: se conserva mientras el restaurant tenga el servicio y hasta 6 años después de su término, para respaldar la trazabilidad de la caja y las obligaciones tributarias. Al vencer ese plazo, lo borramos con un procedimiento manual.
• Registros técnicos de sincronización: se borran solos a las 72 horas, salvo los asociados a una operación rechazada.
• Operaciones rechazadas por el servidor, con su contenido, que en un cobro con factura incluye los datos del receptor: se conservan mientras el restaurant tenga el servicio activo, para que pueda revisarlas.
• Códigos de emparejamiento, guardados solo como hash: se conservan mientras el restaurant tenga el servicio activo, como registro de qué administrador emparejó cada equipo.
• Avisos de cocina: borramos el token de notificaciones de un celular cuando se revoca el equipo, cuando Google informa que ya no sirve o cuando esa instalación de la app pasa a otro equipo. Google descarta el aviso que no logra entregar en 10 minutos, da por vencido el registro de un celular que pasa 270 días sin conectarse a su servicio y conserva el identificador de instalación hasta que se pide borrarlo; desde ese pedido, lo elimina de sus sistemas y respaldos en hasta 180 días. Hoy no le pedimos a Google que lo borre, tampoco al revocar un equipo, así que lo conserva sin un plazo definido.
• Reportes de fallos: Sentry los elimina automáticamente a los 90 días.
• Solicitudes de demostración, con el código derivado de la dirección IP: se conservan hasta 12 meses desde el envío y luego las borramos con un procedimiento manual, o antes si nos lo pides.
• Registros técnicos de nuestros proveedores (peticiones a Vercel e inicios de sesión en Supabase Auth, con la dirección IP): se conservan por el plazo que fija cada proveedor y luego se eliminan.
• PDF de boletas y facturas en la red de entrega de Vercel: cada vez que alguien abre el PDF por su enlace, desde el QR, la Administración web o la API, la red de entrega puede guardar una copia hasta por un año.
• Respaldos: lo que borramos puede seguir en los respaldos automáticos de la base de datos hasta que se reemplacen por otros más nuevos. Solo los usamos para recuperar el servicio ante una falla.
• Datos en el equipo: se mantienen mientras el equipo esté emparejado. Si un administrador revoca el equipo, la próxima vez que el equipo se conecte a internet deja de vender y de sincronizar, y borra la copia de los datos del local, incluidos los cambios que no alcanzó a subir. Si su local o el servicio del restaurant quedan inactivos, el equipo deja de vender y de sincronizar, pero conserva su copia hasta que se reactiven o se revoque el equipo. Si el equipo no vuelve a conectarse, en Android la copia se borra al desinstalar la app o al borrar sus datos desde los Ajustes; en Windows, desinstalar la app no la borra: para eliminarla, borra la carpeta %LOCALAPPDATA%\Mesalto. Qué copia recibe el equipo se explica en la sección 3.
• Fin del servicio: dentro de 90 días desde el término del servicio, borramos o anonimizamos a mano los datos del restaurant, salvo el registro de auditoría, que sigue el plazo indicado más arriba, y la información que la ley nos obligue a conservar (por ejemplo, la tributaria).

10. Tus derechos

Hoy la Ley 19.628 sobre protección de la vida privada te permite pedir acceso, rectificación, cancelación (supresión) y bloqueo de tus datos. Desde el 1 de diciembre de 2026, la Ley 21.719, que la modifica, agrega la oposición y la portabilidad. Atenderemos todas estas solicitudes desde ya:

• Acceso: saber qué datos tuyos tratamos, de dónde vienen, para qué los usamos y a quién se comunican.
• Rectificación: corregir datos inexactos o incompletos.
• Supresión (cancelación): que se eliminen tus datos cuando ya no corresponda tratarlos. La sección 11 explica cómo pedirlo.
• Oposición: que tus datos no se usen para un fin determinado.
• Portabilidad: recibir tus datos en un formato estructurado y de uso común. Hoy la exportación es manual: te enviaremos tus datos por correo en un archivo CSV.
• Bloqueo: suspender temporalmente el tratamiento mientras se resuelve una solicitud.

Cómo ejercerlos: escribe a fernando.romero20@gmail.com con el asunto «Privacidad». Indica tu nombre, el restaurant donde trabajas, que administras o donde fuiste atendido (si pediste una factura, también el RUT con que la pediste; si pediste por una app de delivery, la app, el día y el código del pedido), y lo que pides. Es posible que te pidamos información para verificar tu identidad. El trámite es gratuito. Si los datos son de la operación de un restaurant, coordinaremos la respuesta con él, porque es el responsable. Te responderemos dentro del plazo que fije la ley y, como máximo, en 30 días corridos, que podremos extender una sola vez por otros 30 días avisándote antes.

Los datos del registro de auditoría no se pueden corregir ni borrar a pedido mientras dure su plazo de conservación, y lo mismo pasa con los datos que la ley nos obligue a conservar. En esos casos bloqueamos su uso para cualquier otro fin y te lo informamos.

Si pediste una factura y tus datos cambiaron, dalos de nuevo en tu próxima factura: tu ficha en Mesalto se actualiza con ellos. Si el restaurant ya tiene tu ficha en Defontana, la factura sale con los datos de esa ficha hasta que el restaurant los corrija en su cuenta: pídeselo, o escríbenos y lo coordinamos con él. Una factura ya emitida no se puede modificar: si tiene un error, el restaurant la anula con una nota de crédito y emite otra.

Si eres colaborador de una empresa con convenio, tu empresa puede corregir tus datos o darte de baja desde su portal: pídeselo, o escríbenos y lo coordinamos con el restaurant. Si tu convenio va con la credencial de tu empresa, pídeselo al restaurant o escríbenos.

Si no quedas conforme con la respuesta, puedes reclamar ante la Agencia de Protección de Datos Personales, cuando esté en funciones, o ante los tribunales de justicia, según corresponda.

11. Cómo pedir que se eliminen tus datos

Esta sección aplica a la app Mesalto para Android (Google Play) y para Windows, y a la Administración de Mesalto, de Delpa Tecnología, que publica la app en Google Play con el nombre DELPA TECNOLOGIA. Las apps no tienen un botón para borrar datos: atendemos cada solicitud a mano.

1. Escribe a fernando.romero20@gmail.com con el asunto «Privacidad» y pide la eliminación de tus datos.
2. Indica tu nombre y el restaurant donde trabajas, que administras o donde fuiste atendido.
3. Verificaremos tu identidad y coordinaremos la solicitud con el restaurant, porque es el responsable de esos datos.
4. Te responderemos en el plazo indicado en la sección 10.

Si trabajas en el restaurant o lo administras, eliminamos o anonimizamos de tu ficha del personal el nombre, el código de garzón, el PIN (su hash) y los locales asignados; el nombre anotado en órdenes y comandas; las notas de texto libre que te identifiquen; y, si eres administrador, tu cuenta de acceso (correo y contraseña).

Qué conservamos y hasta cuándo:

• el registro de auditoría, que puede incluir tu nombre, hasta que venza su plazo de conservación (sección 9), con su uso bloqueado para cualquier otro fin;
• la información que la ley nos obligue a conservar, por ejemplo la tributaria, mientras dure esa obligación;
• los identificadores internos, sin tu nombre, asociados a las ventas y a la caja, para mantener su trazabilidad mientras el restaurant tenga el servicio activo.

Si pediste una factura: escribe a fernando.romero20@gmail.com con el asunto «Privacidad» e indica el restaurant y el RUT con que la pediste. Coordinaremos la solicitud con el restaurant y:

• borraremos tu ficha en Mesalto, que desaparece de cada equipo la próxima vez que sincroniza, y tus datos del registro de operaciones rechazadas, si quedaron ahí;
• borraremos tu correo de la copia que se guarda con el pago y de tus facturas y notas de crédito, porque la ley no lo exige;
• conservaremos el resto de los datos de tus facturas y notas de crédito, con su uso bloqueado para cualquier otro fin, porque respaldan documentos tributarios que la ley obliga a conservar;
• conservaremos el registro de auditoría, que puede incluir el mensaje de error de una factura tuya que se volvió a intentar emitir, hasta que venza su plazo (sección 9), con su uso bloqueado para cualquier otro fin.

Si el PDF de tu factura ya se abrió, la copia que guarda la red de entrega de Vercel puede seguir disponible hasta un año. Tu ficha y tus documentos en Defontana los administra el restaurant desde su propia cuenta: para borrarlos o corregirlos, pídeselo a él. Los documentos enviados al SII quedan en el SII, y las facturas impresas, en manos de quien las tenga. Si vuelves a pedir una factura en ese restaurant, se creará una ficha nueva.

Si pediste por una app de delivery: escribe a fernando.romero20@gmail.com con el asunto «Privacidad» e indica el restaurant, la app, el día y el código del pedido. Coordinaremos la solicitud con el restaurant y borraremos tu nombre de ese pedido, de su orden y de sus comandas. La venta y su boleta, que no llevan tus datos, se conservan. Tus datos en la app los administra la app: para borrarlos, pídeselo a ella.

Si pediste una demostración: escribe a fernando.romero20@gmail.com con el asunto «Privacidad» desde el correo que dejaste en el formulario y borraremos tu solicitud completa, incluido el código derivado de tu dirección IP. En este caso no hay un restaurant con quien coordinar.

12. Menores de edad

Mesalto es una herramienta de trabajo y no está dirigida a niños, niñas ni adolescentes. Si un restaurant registra a un trabajador adolescente contratado conforme al Código del Trabajo, lo hace como empleador y responsable de sus datos, y nosotros los tratamos por su cuenta con las mismas protecciones que al resto del personal.

13. Permisos de las apps

Android

La app usa el permiso de internet para comunicarse con nuestros servidores y con las impresoras de la red local. El permiso de estado de la red lo usa la herramienta de reportes de fallos (Sentry) para anotar el tipo de conexión.

Desde la versión 0.11.0 usa además estos permisos para los avisos de cocina:

• el de notificaciones, para avisarle al garzón que está lista una comanda de sus mesas o de un pedido para llevar que tomó en ese celular, aunque esté bloqueado. El aviso se ve en la pantalla bloqueada: por eso solo dice la mesa o el número de la orden, la estación y los productos;
• el de recibir mensajes de Google (Firebase Cloud Messaging) y el de mantener el equipo activo un momento, para recibir el aviso con la pantalla apagada;
• el de vibración, para que los avisos de cocina vibren además de sonar.

Todos los equipos declaran estos permisos, porque es la misma app, pero solo el celular en modo garzón pide el de notificaciones (en Android 13 o superior) y se registra en Google para recibirlas. La caja y la pantalla de cocina muestran sus avisos dentro de la app.

La app no pide permisos de almacenamiento, de superposición sobre otras apps, de biometría ni de huella digital, ni para cambiar la conectividad de red. Las versiones anteriores a la 0.3.0 los declaraban, aunque no los usaban, porque venían con la plantilla de Expo con que está construida la app y con algunas de sus bibliotecas. Tampoco pide los que traen las bibliotecas de notificaciones y no usa: abrirse al encender el equipo, mostrar un número en su ícono y saber desde dónde se instaló.

Windows

La app para Windows no pide acceso a la cámara, al micrófono, a la ubicación ni a tus archivos. Usa la red para comunicarse con nuestros servidores y con las impresoras de la red local, y guarda sus datos en su propia carpeta (ver la sección 3). Se instala solo para la cuenta de Windows de quien la instala y se abre sola cuando esa cuenta inicia sesión. No usa las notificaciones de Windows: sus avisos se ven dentro de la app.

14. Cookies de la Administración web

La Administración web usa solo las cookies de sesión del servicio de autenticación, que un administrador necesita para mantenerse conectado. Son estrictamente necesarias, se envían solo por conexiones seguras, no son accesibles desde JavaScript y duran hasta 400 días. Al conectar Uber Eats, la Administración crea además una cookie cifrada que dura 10 minutos: guarda el estado de ese inicio de sesión en Uber, para comprobar que la vuelta viene de quien lo empezó. También es estrictamente necesaria. No usamos cookies de analítica, de publicidad ni de terceros. El sitio público, incluido el formulario de demostración, no crea cookies. Las apps de Android y de Windows no usan cookies.

15. Cambios a esta política

Si cambiamos esta política, publicaremos la nueva versión en esta misma dirección, con su fecha de vigencia. Si el cambio es importante, como un nuevo tipo de dato o un nuevo proveedor, avisaremos antes a los administradores de los restaurantes.

Con Mesalto, el restaurant emite boletas, facturas y guías de despacho electrónicas a través de Defontana (ver la sección 6). Hoy Mesalto no envía documentos por correo, no se conecta a procesadores de pago y no usa analítica de uso ni de marketing. Si incorporamos alguna de esas funciones, actualizaremos esta política antes de activarla.

16. Contacto

Delpa Tecnología (DELPA TECNOLOGIA en Google Play)

• Correo: fernando.romero20@gmail.com
• Sitio: mesalto.com