Resumen

Este documento describe el diseño propuesto para un mercado secundario (reventa oficial de boletos fan-a-fan) integrado en Boletito. Es una propuesta de trabajo, preparada por menta tech, sujeta a aprobación mutua antes de comenzar el desarrollo.

Los usuarios de Boletito podrán publicar para reventa un boleto que no van a usar y comprar boletos de reventa, todo dentro de la experiencia de Boletito, sin salir nunca de Boletito ni ver la marca menta. menta orquesta el mercado de punta a punta; Boletito sigue siendo la única fuente de verdad de usuarios, boletos y códigos QR.

De un vistazo

Cómo funciona, a alto nivel

Lo que no cambia. menta actúa como capa de orquestación del mercado secundario. Boletito sigue siendo la única fuente de verdad de usuarios, titularidad de boletos y códigos QR, y la integración es 100% marca blanca: el usuario final nunca ve la marca menta, nunca sale de Boletito y nunca interactúa con menta directamente.

Lo que menta nunca hace. menta nunca genera ni modifica códigos QR, nunca entrega boletos al usuario y nunca participa en la venta primaria. Emitir el nuevo boleto al comprador tras una reventa es siempre responsabilidad de Boletito.

El ciclo básico. Un vendedor publica un boleto → un comprador lo adquiere dentro de Boletito → menta le avisa a Boletito que la titularidad cambió → Boletito crea la cuenta del comprador (si hace falta), invalida el boleto del vendedor y emite un nuevo boleto con nuevo QR → el vendedor recibe su pago.

Términos usados en este documento

Características de la plataforma y qué significan

Estas son las características de la plataforma de Boletito que condicionaron el diseño. Cada una es un hecho fijo de cómo funciona Boletito hoy, con su implicación para el mercado secundario en lenguaje claro.

Enfoque de integración

Esta sección detalla, pilar por pilar, cómo funcionará el mercado secundario para Boletito. Para cada pilar se describe qué se decidió, qué requiere e implica y, cuando corresponde, qué se descartó y por qué.

Resumen de decisiones

• Datos de eventos — API de menta (push con cola interna)
  • Boletito notifica al crear, editar o cancelar un evento
  • Solo los eventos con reventa activada generan notificaciones
  • Una API key por boletera (multitenant)
• Verificación de boletos — GetUserData (consulta a demanda)
  • menta consulta solo cuando el usuario inicia la venta
  • Excluye boletos cancelados, transferidos y escaneados
  • Sin sincronización masiva de boletos
• Publicación — URL personalizada con autologin
  • Flujo inteligente: publicar, editar o gestionar la orden
  • Acceso a vender en web y en la app
  • CTA por orden desde Mis Órdenes
• Compra — Banner/botón, lista de categorías y mapa con redirección (Fase 1)
  • Componentes dibujados desde la API de menta; en agotado, redirige a reventa
  • Fase 1: boletos de reventa en el mapa → modal con CTA "Ir a reventa oficial"
  • Fase 2: mapa totalmente integrado (selección en el mapa → carrito y checkout en menta)
• Autenticación — Autologin (vendedor) + cuenta guest (comprador)
  • El usuario nunca ve una pantalla de login de menta
  • Boletito crea la cuenta guest al concretarse la venta
  • Login Force descartado por fricción
• Cambio de titularidad — Flujo dedicado que regenera el QR
  • Invalida el boleto anterior y emite uno nuevo
  • El ticketId se mantiene; admite múltiples cambios y es reversible
  • Usa la transferencia con flag de reventa para reportería
• Precios — Estructura estándar (precio único por sector)
  • Cada boleto conserva su valor nominal
  • Sin reglas de precio avanzadas; sin abonos
• Cierre del mercado — Sincronizado con el desbloqueo del QR
  • Cierra ~3 h antes del evento
  • Puede quedar abierto si el QR es estático
  • "Abierto durante el evento" queda para una etapa posterior
• Señales de demanda — Inventario (live) + Ticket Leads
  • Inventario por evento y por categoría
  • Habilita banners de agotado y campañas de demanda
• Cancelaciones y contracargos — Avisar revendidos + cancelar payout
  • Contracargos del mercado secundario los gestiona menta
  • Cancelación de eventos por notificación manual

Datos de eventos

Qué se decidió. Boletito notifica a menta la creación, modificación y cancelación de eventos mediante llamadas a la API de menta. Para mayor resiliencia, Boletito encola internamente la notificación antes de enviarla, evitando depender de la disponibilidad instantánea de la API de menta. Como ambas infraestructuras operan en AWS (US East / Virginia), queda abierta la posibilidad de un VPC peering para comunicación directa sin exposición a internet público.

Qué requiere e implica. Boletito notifica todas las actualizaciones por API (crear/editar/cancelar), incluyendo los eventos y áreas en draft (ocultos al público), para que se pueda preconfigurar la reventa antes de que el evento salga a la venta. El cuerpo incluye nombre, fecha, venue, shows y categorías. Por la arquitectura multitenant, cada boletera usa su propia API key, con entornos aislados. (El mecanismo exacto —webhook push o exponer una API que menta consulte— se confirma en la próxima reunión.)

Qué se descartó. Un GET-polling cada 10–20 minutos sobre el endpoint público de Boletito: es viable pero filtra los eventos en draft, y menta los necesita para preconfigurar la reventa. Por eso Boletito notifica directamente.

Verificación de boletos

Qué se decidió. menta no mantiene una copia de todos los boletos emitidos. Usa el método de consulta a demanda (Pull): consulta los boletos de un usuario al sistema de Boletito únicamente cuando ese usuario inicia el flujo de venta. Esto elimina la sincronización masiva y reduce drásticamente la carga sobre la infraestructura de Boletito.

Qué requiere e implica. El endpoint de verificación debe devolver exclusivamente boletos válidos y en posesión actual del usuario: debe omitir cancelados, reembolsados, transferidos a otra persona y escaneados (checked-in), además de cualquier producto que no represente un boleto con acceso. menta consulta el endpoint en varios momentos —entrada al flujo de venta, limpieza periódica de publicaciones activas, gate al entrar al checkout, durante la reserva del carrito y como verificación final antes del cambio de titularidad—, por lo que Boletito debe dimensionarlo para ese patrón (es una consulta de lectura, cacheable). Como efecto secundario positivo, un boleto transferido o cancelado simplemente desaparece de la respuesta y la limpieza de menta deslista la publicación automáticamente.

Qué se descartó. El método Push (Boletito envía cada boleto a vender): descartado por la preferencia de Boletito de minimizar escrituras hacia APIs externas y la preocupación por la concurrencia en eventos masivos.

Cómo publica un vendedor

Qué se decidió. Como los boletos se muestran agrupados por orden (no hay vista por boleto), el vendedor parte de un enlace personalizado en su sección de Mis Órdenes / Mis Boletos. Al hacer clic llega ya autenticado (autologin) a la gestión de reventa marca blanca de menta. El flujo es inteligente: si todos los boletos están disponibles, va directo a publicar; si están todos en una misma publicación, va directo a editarla; y solo si hay una mezcla (disponibles, en venta y vendidos) se muestra una pantalla para gestionar la orden boleto por boleto (ver a cuánto está publicado, compartir, editar, despublicar).

Qué requiere e implica. Boletito inserta un CTA por orden; al completar la publicación el usuario vuelve a Boletito y el CTA cambia a "Editar publicación", idealmente con un indicador de cuántos boletos publicó. El acceso a vender debe existir tanto en la web como en la app, porque algunos usuarios solo ven sus boletos en la app (boletos recibidos por transferencia) y otros en la web. Generar el enlace con autologin requiere un llamado server-side a la API de menta.

Qué se descartó. CTAs por boleto (no hay interfaz por boleto donde anclarlos) y la URL estática con OTP (peor experiencia; Boletito puede hacer llamados server-side, lo que habilita el autologin).

Cómo compra un comprador

Qué se decidió (Fase 1). La oferta de reventa aparece dentro de las páginas de evento de Boletito, dibujada con los componentes de menta: un banner o botón, la lista de categorías con la cantidad de boletos disponibles y —también en el MVP— los boletos de reventa dibujados sobre el mapa de asientos primario con un ícono diferenciado. Al seleccionar un asiento de reventa aparece un modal que aclara que es un boleto del mercado de reventa oficial y debe comprarse allí, con un CTA ("Ir a reventa oficial") que redirige al checkout de reventa de menta. Cuando un evento o categoría se agota en venta primaria, Boletito redirige al mercado secundario en lugar de mostrar "Agotado" —un disparador de conversión clave, porque el usuario ya está en la página con intención de compra.

Qué requiere e implica (Fase 1). Boletito consulta la capa de acceso de menta por evento/show y dibuja los componentes que menta retorna (banner, modal, botón, lista de categorías) y los boletos de reventa sobre su mapa, con la redirección al checkout de reventa al seleccionarlos. Si no se cumplen las condiciones (reventa inactiva o sin inventario), menta no retorna componentes y no se dibuja nada. Toda la activación se gobierna desde el panel de menta, sin cambios de código en Boletito.

Fase 2 — mapa totalmente integrado. En una segunda fase, la reventa se integra por completo en el mapa: el usuario selecciona los boletos de reventa directamente sobre el mapa, se arma un carrito en menta con esos boletos y va directo al checkout de esos boletos en menta, sin salir a una página de reventa aparte. Es una experiencia totalmente embebida que reemplaza el modal de redirección por una compra continua dentro del mapa.

Qué requiere (Fase 2). Boletito debe permitir la selección de asientos de reventa en su mapa, integrar el armado del carrito y el checkout de menta, y gestionar el bloqueo de asientos durante la compra. Por eso se difiere: requiere desarrollo adicional sobre su mapa propio.

Autenticación

Qué se decidió. El usuario nunca ve una pantalla de login de menta. El vendedor llega pre-autenticado por el enlace personalizado (autologin). El comprador compra como invitado: se valida su correo con un código (OTP de menta) y, al concretarse la venta, Boletito crea su cuenta por detrás. Se confirmó que una cuenta guest es suficiente para ejecutar el cambio de titularidad.

Qué requiere e implica. Boletito incluye el parámetro de autologin (correo del usuario) al generar la URL del vendedor. Para el comprador, al recibir el webhook de venta, Boletito crea la cuenta guest con el correo —y con nombre y apellido separados y teléfono formateado, datos que menta captura en el checkout— y ejecuta el cambio de titularidad. Como muchos compradores compran como invitados y no entran por su cuenta a la web, el correo de confirmación de compra debe incluir un acceso directo para vender.

Qué se descartó. Login Force (redirigir al usuario a registrarse en Boletito antes de pagar): descartado por su impacto negativo en conversión y porque la creación programática de cuenta lo hace innecesario.

Cambio de titularidad

Qué se decidió. Al concretarse una reventa, menta envía a Boletito los datos completos (identificación del boleto, correo del nuevo y del anterior titular, monto y comisiones). Boletito ejecuta un flujo dedicado de cambio de titularidad que crea la cuenta del comprador si no existe, invalida el boleto del vendedor, emite un nuevo boleto con nuevo QR, preserva la reportería del vendedor y marca la operación como reventa para analítica. Debe soportar además una acción reversa para contracargos o fraude.

Qué requiere e implica. El comportamiento ideal es changeTicketOwner(buyerEmail, ticketId): crear usuario si no existe, remover del vendedor, emitir al comprador, regenerar el QR e invalidar el original. Confirmado con Boletito (29/05): el ticketId se mantiene tras el cambio; el cambio se puede ejecutar múltiples veces sobre el mismo boleto (un comprador de reventa puede revender) y es reversible (necesario para contracargos y cancelaciones). Se implementa con la capacidad de transferencia de Boletito + un flag de reventa para reportería y trazabilidad, por un camino directo (sin los pasos intermedios del flujo de transferencia entre usuarios).

Protección de integridad. Mientras un boleto tiene una publicación activa, si se transfiere o imprime fuera de la reventa, al usar consulta a demanda el boleto deja de aparecer en el endpoint y menta deslista la publicación; antes de cada compra menta verifica que el vendedor siga siendo el dueño.

Estructura de precios

Qué se decidió. Boletito usa precio único por sector, que mapea directamente a la estructura simple (Standard). Cada boleto conserva su valor nominal original.

Qué requiere e implica. La configuración de precios en el mercado secundario es directa: no hay preventas, generales ni precios diferenciados por fase dentro de un mismo sector, así que no se requieren reglas de precio avanzadas. Boletito tampoco maneja abonos ni pases de temporada: cada boleto da un único acceso y se revende individualmente.

Cierre del mercado secundario

Qué se decidió. Para eventos cuyo QR se libera el día del evento, el mercado se cierra sincronizado con la liberación de los QR (Boletito desbloquea por defecto unas 3 horas antes). Para eventos con QR estático o ya visible, el mercado puede permanecer abierto, porque el cambio de titularidad regenera el QR en cada venta y el anterior queda inválido.

Qué requiere e implica. Boletito envía, por show, el tiempo de desbloqueo del QR; desde el panel de menta se configura el cierre del mercado para que ocurra antes o al mismo tiempo que ese desbloqueo, garantizando que no haya reventa una vez que los usuarios vieron sus códigos. Las funciones de desbloqueo del dashboard quedan ocultas, exponiendo solo el control de cierre.

Qué se descartó por ahora. Mantener el mercado abierto durante el transcurso del evento: es valioso (hay reventas de último minuto) pero requiere validación de check-in en tiempo real para que los boletos escaneados desaparezcan del endpoint, y el escaneo de Boletito necesita los datos congelados para flujos offline. Se difiere a una iteración posterior y se registra como limitación.

Señales de demanda

Qué se decidió. Market making activo en dos dimensiones: Inventory (capacidad, agotado y disponibilidad por categoría, en tiempo real) y Ticket Leads (la base de poseedores de boletos como fuente para comunicaciones de reventa).

Qué requiere e implica. Para inventario, Boletito alimenta los endpoints a nivel evento y por categoría (capacidad, agotado, porcentaje vendido). Esto habilita la activación dinámica del mercado por reglas de agotado, banners de soldout, métricas de demanda y la optimización de la compra. Los datos de ticket holders se envían a pedido y habilitan campañas post-compra del tipo "¿No podés ir? Vendé tu boleto", que aumentan la oferta y la conversión.

Devoluciones, cancelaciones y contracargos

Qué se decidió. Boletito permite cancelación parcial por boleto. En lugar de bloquear de forma dura la cancelación de boletos revendidos, al cancelar una orden que los contiene se muestra un aviso ("estos N boletos fueron revendidos — ¿cancelar igual?"). Si se cancela, Boletito notifica a menta para cancelar el pago al vendedor y menta gestiona el reembolso al comprador de reventa. Los reembolsos son totales.

Qué requiere e implica. Boletito registra el estado de cada boleto (incluido "revendido") y puede mostrar un indicador. Los contracargos del mercado secundario los gestiona y absorbe menta; los del mercado primario se notifican manualmente para el cruce de usuarios y la retención de pagos. El detalle operativo completo —incluida la cancelación de eventos y la retención fiscal SAT/RFC— está en Operaciones.

Por qué este enfoque. Existen escenarios legítimos para cancelar un boleto ya revendido (por ejemplo, lugares de primera fila liberados por error o acuerdos con el artista), por lo que el diseño prioriza avisar y permitir, protegiendo al comprador de reventa con el reembolso correspondiente.

Reglas de negocio

Reglas específicas de Boletito que rigen el comportamiento del mercado secundario. Solo se listan las confirmadas para esta integración.

• Reventa habilitada por evento. El mercado secundario se activa por evento desde el panel de menta; Boletito controla en qué eventos se ofrece.
• Reventa incluso con QR estático. Como el cambio de titularidad regenera el QR en cada venta, estos eventos también pueden tener reventa: el boleto anterior queda inválido y se emite uno nuevo al comprador. Activarlo o no es decisión de Boletito por evento.
• Reventa de boletos físicos — a definir. Habilitar la reventa de boletos físicos es un objetivo del diseño (la mayoría del inventario es físico); el mecanismo está pendiente de validación — ver la sección "Reventa de boletos físicos" más abajo.
• Re-reventa permitida. Un comprador de reventa puede volver a vender su boleto: el cambio de titularidad admite múltiples ejecuciones sobre el mismo boleto y es reversible.
• Reventa permitida aun con el QR ya visto. El usuario puede revender aunque ya haya descargado o visto su QR.
• Solo boletos de acceso único. Boletito no maneja abonos ni pases de temporada; cada boleto da un acceso único y se revende individualmente.
• Visibilidad respetada. Shows o categorías marcados como no visibles (no anunciados, test, cortesías) no aparecen en el mercado secundario, evitando spoilers o publicar algo aún no anunciado.
• Boletos transferidos / escaneados quedan fuera. Un boleto transferido a otra persona, o ya escaneado en el acceso, deja de estar disponible para reventa automáticamente.
• Carrito de un solo evento. Las compras (incluida la reventa) son por evento.
• Reventa sobre el mapa de asientos: Fase 2. En la Fase 1 el acceso a compra es por banner/botón y lista de categorías.

Reventa de boletos físicos — pendiente de definición

Como ~70–80% de los boletos de Boletito son físicos (y los eventos más grandes lo son), habilitar su reventa es importante para el alcance del proyecto. El mecanismo concreto queda a definir entre ambos equipos; estas son las opciones conversadas:

• Vender mientras el boleto no se imprimió/retiró. En la ventana entre la compra y el retiro en taquilla, el boleto se puede revender sin fricción (el cambio de titularidad regenera el QR).
• Boletos ya impresos/retirados → entrega en taquilla. Se muestra igual la opción de vender; al tocarla, un aviso indica que el usuario debe acudir a taquilla y entregar el físico para invalidarlo y habilitar la venta (proceso operativo + capacitación del personal de taquilla).
• Pago condicionado a la entrega del físico. El vendedor recibe el pago solo una vez que entregó el boleto físico.
• Mostrar siempre el accionable de vender (p. ej. un banner "¿Deseás vender?"), aun para físicos, gatillado con la leyenda de entrega — para que el usuario sepa que la reventa oficial existe.
• PDF: demorar el envío del código hasta cerca del evento (el PDF es marginal: eventos chicos de 50–100 personas).
• Refuerzo en el acceso: el cambio de titularidad regenera el QR e invalida el anterior; se complementa con capacitación en puerta y el aviso "boleto revendido" en la app de escaneo (un físico impreso puede seguir circulando — riesgo a mitigar).

Pendiente: definir y diseñar el flujo de físicos en conjunto (menta + Boletito). La reventa de físicos se va a habilitar; lo que está abierto es el cómo.

Propuesta operativa: validación en el acceso

Para los eventos con QR estático o ya visible, se propone agregar en la app de escaneo propia de Boletito un mensaje de "boleto revendido" cuando alguien intente ingresar con un QR que ya fue revendido oficialmente. Esto oficializa y vuelve segura una reventa que hoy igual ocurre por canales informales. (Boletito lo evaluará internamente.)

Operaciones y contingencia

Cómo se manejan las situaciones operativas una vez en vivo. Solo se describe lo confirmado para Boletito.

Cancelaciones con boletos revendidos

Boletito puede cancelar boletos individuales dentro de una orden. Cuando una orden contiene boletos ya revendidos, en lugar de bloquear la cancelación, Boletito muestra un aviso ("estos N boletos fueron revendidos en el mercado secundario — ¿cancelar de todos modos?"). Existen escenarios legítimos para cancelar un boleto revendido (por ejemplo, lugares de primera fila liberados por error, o acuerdos con el artista). Si se cancela, Boletito notifica a menta para cancelar el pago al vendedor y menta gestiona el reembolso al comprador de reventa. Boletito registra el estado de cada boleto y puede mostrar un indicador de "revendido". Los reembolsos son totales.

Importante: los pagos a vendedores se ejecutan solo después del evento. menta retiene el dinero de la reventa hasta entonces, lo que permite revertir ante contracargos o cancelaciones sin pérdida (si el comprador original mete un contracargo, menta cancela el pago al vendedor y el dinero queda en Boletito; el comprador de reventa conserva su boleto válido).

Contracargos del mercado secundario

Los contracargos originados en el checkout del mercado secundario son responsabilidad de menta: menta gestiona la disputa, el procesador, la prevención de fraude (3D Secure, validaciones) y absorbe el costo. Si se detecta un usuario fraudulento, se bloquea su acceso a futuras compras de reventa.

Contracargos del mercado primario

Cuando un titular con boletos publicados en reventa genera un contracargo en una orden primaria, Boletito notifica manualmente el correo involucrado al equipo de operaciones de menta. menta identifica a la persona detrás del usuario (mediante datos de publicación: CURP/RFC, cuenta bancaria) y, si detecta múltiples usuarios asociados a la misma persona, retiene todos los pagos pendientes y los incluye en lista negra.

Cancelación de eventos

Boletito no tiene hoy una bandera de "evento cancelado". Como mecanismo, una inactivación del evento puede disparar una notificación a menta como "potencial evento cancelado" para revisión. menta entonces despublica las publicaciones activas y deja los pagos on-hold (no se eliminan datos ni se disparan comunicaciones al usuario; todo es reversible si fue un falso positivo). En una cancelación total confirmada, Boletito reembolsa al comprador original y menta retiene el pago de reventa. Boletito evaluará agregar un flag explícito de evento/boletos cancelados. Como los pagos salen después del evento, una notificación tardía no genera pérdida.

Retención fiscal (México — SAT/RFC)

Por la normativa vigente, al intermediar pagos entre usuarios menta valida el RFC del vendedor contra el SAT, retiene los impuestos según el estatus fiscal de la persona y emite el comprobante de retención vía un facturador externo. menta gestiona esto 100%; el RFC se solicita al publicar. El formulario de pago varía por país.

App y deeplinks

El enlace "Mis boletos" en las comunicaciones de reventa abre la app de Boletito mediante deeplink (App Store / Google Play), para una experiencia consistente. El deeplink solo abre la tienda/app; la autenticación del usuario dentro de la app sigue las reglas de seguridad de Boletito (se evaluará para evitar inicios de sesión forzados).

Multitenant y routing

Cada boletera (tenant) opera con su propia API key de menta y su entorno aislado, con reglas de negocio independientes por evento. Boletito enruta cada llamada a la API key correspondiente según el evento y el tenant.

Comunicaciones

La integración incluye un conjunto inicial de comunicaciones marca blanca que impulsan la actividad de reventa. Todas se envían bajo la identidad de Boletito.

Comunicación obligatoria de Boletito

Boletito debe incluir, en el correo de confirmación de compra primaria, un mensaje sobre la disponibilidad del mercado secundario: que si el comprador no puede asistir, puede revender su boleto de forma segura en la reventa oficial integrada en Boletito, con un acceso para ir a vender. Esto es clave porque muchos compradores compran como invitados y no entran por su cuenta a la web. El contenido, diseño y CTA se coordinan en la capacitación administrativa.

Starter pack (gestionado por menta)

menta gestiona todas las comunicaciones transaccionales del mercado secundario en nombre de Boletito, personalizadas con su identidad visual. Boletito es responsable de la mención al mercado secundario en sus comunicaciones de compra primaria.

API y webhooks

Mapa completo de los puntos de integración para el equipo técnico de Boletito. Las especificaciones de request/response completas están en la documentación de la API de menta.

Endpoints

El mismo endpoint POST /v1/wrapper/accesslayer opera en dos modos según el cuerpo: per-ticket (cuerpo con tickets) o per-orden (cuerpo con orders, mínimo uno). Como Boletito agrupa por orden, usa el modo orders.

Webhooks

menta envía webhooks HTTP POST a Boletito cuando ocurre un evento relevante del mercado. La estructura del payload es: { message: { family, action, type, data } }.

Solo ticket.updated requiere acción inmediata de Boletito — dispara el cambio de titularidad. Los demás webhooks son informativos y pueden procesarse de forma asíncrona.

El webhook de reventa incluye los datos para crear la cuenta del comprador: correo, nombre y apellido (separados) y teléfono formateado, además de la identificación del boleto, el titular anterior, el monto y las comisiones.

Confiabilidad y seguridad

• Reintentos: ante un fallo de entrega, menta reintenta con backoff exponencial hasta ~100 veces; además emite alertas si una transferencia no se confirma a tiempo.
• Seguridad: los webhooks se originan desde una IP fija (para reglas de firewall de Boletito) e incluyen una clave secreta en los headers. Configurable por tenant.
• Sincronización de eventos: Boletito notifica las actualizaciones por API (incluyendo eventos/áreas en draft). El mecanismo exacto —webhook o API expuesta— se confirma en la próxima reunión.

Qué debe construir Boletito

Lista accionable para el equipo técnico de Boletito, derivada del diseño anterior. Los ítems marcados (Fase 2) no son necesarios para el lanzamiento inicial.

Ningún requerimiento se asume: cada uno se desprende de una característica de la plataforma o de una decisión confirmada para esta integración.

Limitaciones

Limitaciones conocidas del diseño de Fase 1, con su motivo, impacto y manejo.

Etapas futuras

• Fase 2: mapa de reventa totalmente integrado (selección en el mapa → carrito y checkout en menta, sin redirección); evaluación de mercado abierto durante el evento; descuentos y cupones (en el roadmap de Boletito).
• Expansión a Estados Unidos: sujeta a definición regulatoria; impacta moneda (USD), idioma y medidas antifraude transfronterizas.

Aprobación

Este documento se considera aprobado cuando ambas partes otorguen su conformidad formal. La implementación técnica no comenzará hasta contar con dicha aprobación.