Aviso de privacidad
de la aplicación.
Borrador del 17 de octubre de 2026. No sustituye la revisión de Ben ni de un abogado.
Este borrador describe el tratamiento de datos personales en la aplicación PuestoVenta: la cuenta del vendedor, el puesto, el menú, el equipo, los pedidos y el menú público en el que un cliente arma su orden. La lista de espera sigue cubierta por el aviso de privacidad de la lista de espera. Este texto no describe un banco, una cuenta de fondos ni un cobro ya habilitado para varios vendedores.
El marco de referencia es la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, nueva ley publicada en el Diario Oficial de la Federación el 20 de marzo de 2025 y en vigor desde el 21 de marzo de 2025. Esa ley abrogó la del mismo nombre publicada el 5 de julio de 2010. El texto vigente incluye la reforma del artículo 4 publicada el 14 de noviembre de 2025. La autoridad que la ley llama Secretaría es la Secretaría Anticorrupción y Buen Gobierno. El abogado debe confirmar si el reglamento anterior sigue aplicando y cuál es la vía exacta para una queja.
Quién es responsable
YayaSocial LLC es el responsable de los datos personales que trata PuestoVenta. Su domicilio es 435 E Live Oak Ave, APT 210, Arcadia, CA 91006-5661, Estados Unidos. Puedes escribir a [email protected]. El responsable está en Estados Unidos, así que operar la cuenta implica una transferencia internacional hacia ese país.
Qué datos tratamos
Lo siguiente sale del código revisado el 17 de octubre de 2026. No pedimos datos sensibles: origen racial o étnico, salud, genética, creencias, opiniones políticas ni preferencia sexual. No los uses en el nombre del puesto ni en el texto del menú.
- Cuenta. Nombre, correo electrónico y, si entras con contraseña, un hash scrypt de esa contraseña. No guardamos la contraseña en claro. Si entras con Google o Apple, guardamos el identificador de esa cuenta y los tokens que el proveedor devuelve para mantener la sesión. Si Apple no comparte un correo, guardamos un identificador técnico no entregable, formado con el identificador de Apple. El sistema de acceso puede guardar en la sesión la dirección IP y el identificador del navegador o de la app.
- Puesto, equipo y menú. Nombre y enlace del puesto, productos (nombre, descripción, categoría y precio), complementos, miembros (nombre, correo y rol) e invitaciones. La invitación guarda el rol, quién la creó, su vencimiento y un hash del enlace. No guarda el correo de la persona invitada hasta que entra con su propia cuenta.
- Pedidos. Productos, complementos, cantidades, precios, total, origen (equipo o autoservicio), estado y fechas. Si lo arma alguien del equipo, relacionamos el pedido con su usuario. El pedido de autoservicio no pide nombre, correo ni teléfono del cliente. Guardamos solo un hash del token con el que esa pantalla consulta el estado.
- Pagos, cuando existan. El sitio público corre como vista previa. El menú de demostración no crea un cargo real. Registrar una CLABE no enciende los pagos de varios vendedores: si el puesto tiene un alta bancaria, el servidor rechaza crear el cobro porque Pey todavía no permite elegir esa cuenta como destino de cada pago. PuestoVenta no es un banco, no retiene el dinero y no ofrece pagos con tarjeta. Si se crea un cobro CoDi con Pey, guardamos el identificador del proveedor, el método (QR o solicitud al celular), el estado y, en el QR, el texto del código. El celular de 10 dígitos se envía a Pey solo si alguien pide la notificación CoDi en ese número. No lo guardamos. El aviso que Pey devuelve se usa para marcar el pedido como pagado; no archivamos el cuerpo completo del aviso.
- Alta bancaria. Si la persona propietaria registra una cuenta, enviamos a Pey el alias (el nombre del puesto), el nombre legal del titular, la CLABE completa, el tipo de titular (persona o negocio) y el RFC si lo escribe. Eso solo ocurre después de que marca la casilla de titularidad. En la vista previa el servidor rechaza el alta y no llama a Pey. En nuestra base guardamos el identificador de cuenta de Pey, el estado inicial, el tipo de titular y los últimos 4 dígitos de la CLABE. No guardamos la CLABE completa, el nombre del titular ni el RFC. Una conexión Pey anterior, si existe, guarda cifrados la clave de API y el secreto del aviso de ese puesto. No es el flujo de cobro a varias cuentas.
- Uso del producto. En la web, una cookie httpOnly llamada pv_visitor guarda un identificador aleatorio, con SameSite Lax y vigencia de hasta un año. En la app instalada, un identificador aleatorio queda en el almacenamiento seguro del teléfono. No es un identificador de hardware ni de publicidad. Esos identificadores se asocian a eventos como ver el inicio, entrar, abrir el panel, el punto de venta, el menú público o la app. Si hay sesión, también puede guardarse el identificador de usuario. No guardamos la IP en esa tabla. Los eventos de más de 90 días se borran cuando llegan eventos nuevos. La compilación de desarrollo y la vista web de la app móvil no envían ese identificador.
- Analítica de PostHog. El sitio web ya la usa para medir el producto, incluido el panel del vendedor en el navegador. El navegador envía a la ruta /ingest de este mismo sitio y el servidor reenvía a PostHog. El destino por defecto es la nube de Estados Unidos, en us.i.posthog.com. Si no hay clave de proyecto, no sale ningún evento. La app instalada envía vistas de pantalla y el perfil de persona cuando la compilación trae la clave pública del proyecto.
Cuando el vendedor entra, el navegador llama a identify con el identificador de usuario de Better Auth. El perfil de persona recibe el correo, el nombre, el nombre del puesto, el plan (free o pro), si la suscripción está pagada, la fecha de alta y, cuando hay cifras, lo pagado a PuestoVenta y el total de pedidos pagados, en pesos. La primera visita fija una sola vez la fecha de alta, la campaña utm y el referrer, sin parámetros secretos. El teléfono, la CLABE, el RFC, la contraseña, los tokens, el identificador de sesión, la tarjeta y las líneas del pedido no se envían. Copiar correo y nombre a PostHog en Estados Unidos es una transferencia que el abogado debe confirmar antes de quitar la marca de borrador. La app instalada, si la compilación trae la clave pública del proyecto, identifica con esas mismas propiedades de persona. PostHog solo crea perfil de persona para quien ya quedó identificado. La autocaptura está apagada, la grabación de sesión está apagada y no capturamos excepciones del navegador. Sí enviamos la salida de página y una vista de página manual. Cualquier dirección de página sale sin parámetros de consulta distintos de utm_source, utm_medium, utm_campaign, utm_term, utm_content y src=qr.
La primera vez que la dirección trae utm_source, utm_medium, utm_campaign, utm_term o utm_content, el navegador guarda esos valores en localStorage, con la clave puesto_first_touch_utm, y no los sustituye si llega otra campaña. Esos valores de primera visita acompañan los eventos posteriores del navegador. Al identificar, los valores iniciales se fijan una sola vez.
Con clave de proyecto, estos son los eventos de producto:
- signup. En el servidor, al crear la cuenta. Solo el identificador de usuario. Sin otras propiedades.
- store_created y menu_published. En el servidor, al crear el puesto. Propiedades: identificador y enlace del puesto. menu_published sale en ese mismo momento porque el menú público queda activo de inmediato.
- storefront_viewed. En el navegador, al abrir un menú público real. Propiedades: identificador y enlace del puesto. El menú de demostración y la vista previa no se envían. Quien no ha entrado queda con el identificador anónimo de PostHog.
- qr_scanned. En la misma carga, solo si la dirección trae src=qr. Los códigos QR nuevos del puesto llevan ese parámetro. Un enlace compartido, o un QR ya impreso sin él, abre el menú y envía storefront_viewed, sin qr_scanned.
- order_placed. En el servidor, al guardar un pedido. El identificador es el del propietario del puesto. Propiedades: puesto, pedido, origen (equipo o autoservicio), total en centavos, moneda MXN y, si el pedido es de demostración, demo verdadero. Sin líneas del pedido. Los puestos demo-store y preview no se envían.
- order_paid. En el servidor, después de verificar la firma de Pey, aplicar el pago y registrar el aviso por primera vez. Un reintento no lo vuelve a enviar. Propiedades: puesto, pedido, monto en centavos, revenue en pesos y moneda MXN. Si el pedido o el entorno es de demostración, incluye demo verdadero. Sin líneas del pedido.
- purchase_completed y subscription_renewed. En el servidor, cuando Stripe confirma una factura de suscripción etiquetada para PuestoVenta. El primero es la factura inicial (subscription_create) y el segundo es una renovación (subscription_cycle). Propiedades: revenue, moneda, puesto e identificador de suscripción. El identificador de la persona es el propietario del puesto. Un aviso repetido no se envía otra vez. En vista previa llevan demo verdadero.
- Correo de la cuenta. Resend ya envía el correo transaccional. Al crear la cuenta con correo y contraseña mandamos un mensaje para confirmar la dirección. También mandamos un enlace si pides restablecer la contraseña. Puedes entrar sin haber confirmado el correo. Resend recibe tu dirección, tu nombre, el asunto y el cuerpo, incluido el enlace con su token. El enlace de restablecimiento caduca en 1 hora y el de confirmación en 24 horas. Resend puede tratar esos datos en Estados Unidos. No usamos Resend para noticias de producto.
- Lista de espera. Correo, tipo de negocio, página de origen, datos de campaña y consentimiento para noticias del lanzamiento. Ese tratamiento, con Sequenzy, el píxel de Meta, Railway y el reenvío de Namecheap a Gmail, ya está descrito en el aviso de la lista de espera. El píxel de Meta no corre en la aplicación ni en el menú público.
Los mensajes a [email protected] se reciben por el reenvío de Namecheap hacia un buzón de Gmail del equipo. Railway aloja la aplicación y la base de datos, y puede tratar información fuera de México, incluido Estados Unidos. El alojamiento también puede ver datos técnicos de conexión, como la dirección IP, aunque la analítica propia no la archive.
Para qué los usamos
Finalidades primarias, necesarias para la relación con el vendedor o para el pedido que el cliente arma: crear y proteger la cuenta; enviar por Resend la confirmación de correo y, si la pides, el restablecimiento de contraseña; operar el puesto, el menú, el equipo y los pedidos; mostrar el menú público y la pantalla de cobro; prevenir abuso; atender soporte y solicitudes de privacidad; y, cuando un cobro real esté habilitado, pedir a Pey la instrucción CoDi que la persona solicitó y registrar su resultado. Los datos patrimoniales de la CLABE, el titular y el RFC solo se envían a Pey con la confirmación expresa de la casilla de titularidad, y hoy esa alta está bloqueada en la vista previa.
Finalidades secundarias, que puedes rechazar sin perder la cuenta ni el menú: medir qué pantallas se usan, con la cookie pv_visitor y el identificador de la app, y medir el producto en la web y, si la compilación trae la clave pública, en la app instalada, con PostHog, como se describe arriba. No enviamos correos de producto aparte de la confirmación de cuenta y el restablecimiento de contraseña. Las noticias de la lista de espera son otra finalidad y se rigen por su propio aviso. Puedes oponerte a las finalidades secundarias escribiendo a [email protected] con el asunto “Privacidad PuestoVenta”. También puedes bloquear cookies en el navegador. Cerrar sesión en la web borra la campaña de primera visita guardada en ese navegador y reinicia el identificador de PostHog. Borrar los datos de la app o reinstalarla reinicia el identificador del teléfono. Limitar la medición no impide usar el puesto.
Encargados, transferencias y Estados Unidos
Tratamos datos con encargados y, cuando el dato sale hacia un tercero distinto, mediante transferencia. Railway aloja el servicio. Pey recibe el alta bancaria y, si algún día se crea un cobro, la instrucción CoDi, incluido el celular de 10 dígitos solo para la notificación. Google y Apple intervienen si eliges entrar con ellos. Resend ya envía la confirmación de correo y el restablecimiento de contraseña. PostHog recibe, en la web y en la app instalada si hay clave de proyecto, la analítica descrita arriba, con destino por defecto en Estados Unidos. Sequenzy y Meta intervienen solo en la lista de espera. Namecheap reenvía el correo de contacto a Gmail.
El responsable está en California. Railway, Google, Apple, PostHog, Resend, Sequenzy, Meta y Gmail pueden tratar datos fuera de México, incluido Estados Unidos. Pey es el proveedor mexicano de CoDi y aplica además su propio aviso. Este borrador informa esas transferencias. La cláusula definitiva sobre si el uso de la cuenta vale como aceptación, y qué transferencias pueden hacerse sin un consentimiento nuevo, queda para el abogado. Mientras este texto sea borrador, no lo tomes como un consentimiento cerrado.
Cookies y rastreo
- Sesión de la cuenta. Cookie httpOnly del sistema de acceso, necesaria para seguir dentro del puesto.
- pv_visitor. Cookie propia, httpOnly, de medición. No es de publicidad.
- Identificador de la app. UUID aleatorio en el teléfono, solo en compilaciones nativas que no son de desarrollo.
- PostHog. En la web, si hay clave de proyecto, guarda un identificador en localStorage y en una cookie del navegador. La primera campaña queda en localStorage. No hay autocaptura ni grabación de sesión. La app instalada lo usa cuando la compilación trae la clave pública.
- Meta. Solo en las páginas de la lista de espera, según el aviso de esa lista.
No vendemos datos personales ni los usamos para decidir de forma automatizada si alguien recibe el servicio.
Derechos ARCO y revocación
Puedes pedir acceso, rectificación, cancelación u oposición, y revocar tu consentimiento, escribiendo a [email protected] con el asunto “Privacidad PuestoVenta”. Incluye tu nombre, un medio para responder, los documentos con los que acredites tu identidad o la de quien te representa, qué derecho ejerces y, si no pides acceso, qué datos abarca la solicitud. Para rectificar, indica el dato correcto y adjunta lo que lo respalde. Si necesitamos comprobar la identidad, pediremos solo lo necesario para atenderte.
La ley da hasta veinte días hábiles para comunicarte la determinación, contados desde que recibimos la solicitud, y quince días hábiles más para hacerla efectiva si procede. Cada plazo puede ampliarse una sola vez por un periodo igual, con justificación. El ejercicio es gratuito, salvo el costo de reproducción o envío cuando la ley lo permite. La revocación no tiene efectos retroactivos. La cancelación, la oposición o la revocación no proceden cuando el dato sea necesario para cumplir el contrato, una obligación legal, un proceso o la seguridad de otras personas. Después de cancelar, puede existir un bloqueo por el tiempo de prescripción de las acciones relacionadas.
Si no estás de acuerdo con la respuesta, o si no la hay al vencer el plazo, la ley permite acudir a la Secretaría Anticorrupción y Buen Gobierno. El plazo de la ley para esa solicitud de protección es de quince días desde la respuesta, o desde que venció el plazo del responsable si no hubo respuesta. La vía concreta de presentación queda pendiente de confirmación del abogado.
Conservación, seguridad y cambios
Conservamos la cuenta mientras exista y el tiempo posterior que haga falta para seguridad, reclamos o deberes legales. El plazo exacto de pedidos, estados de pago y metadatos bancarios (últimos cuatro dígitos, identificador de Pey y estado) está pendiente de definición. Los eventos de uso se eliminan al superar unos noventa días, cuando el sistema recibe eventos nuevos. La CLABE completa, el RFC y el celular del pagador no se almacenan en PuestoVenta. Aplicamos medidas para limitar el acceso: la contraseña va hasheada, la clave Pey antigua va cifrada y el alta bancaria solo deja los últimos cuatro dígitos.
Publicaremos los cambios en esta misma página, con una fecha nueva. Si un uso nuevo requiere otro consentimiento, lo pediremos antes de aplicarlo. La versión que gobierne será la que deje de identificarse como borrador.
También puedes leer los términos de uso, que están en el mismo estado de borrador.