Plataforma de Envíos Colaborativos — Documento de Definición del Proyecto (PRD)

Estado: Borrador v3.1 · Última actualización: Junio 2026 Objetivo del documento: dejar asentados los detalles necesarios para arrancar a trabajar en el producto (alcance, flujos, modelo económico, arquitectura y decisiones pendientes).

1. Resumen ejecutivo

Plataforma tipo marketplace de dos lados que conecta empresas de logística que tienen envíos que no pueden realizar con repartidores individuales que están dispuestos a hacerlos, según la zona desde donde sale el paquete y la zona a donde va.

La empresa publica un envío (origen → destino, paquetes, precio) subiendo el QR/etiqueta de Mercado Envíos (Flex) de cada paquete. El repartidor recibe una notificación cuando el envío coincide con su zona de residencia o con una ruta/zona que tiene declarada. Acepta, retira (escaneando el QR para confirmar el paquete correcto), entrega y registra la prueba de entrega. El pago se libera cuando hay una confirmación fuerte (código del destinatario, o vencimiento de la ventana de 24–48 hs sin reclamo): el repartidor cobra el 95 % del valor y la plataforma retiene el 5 % (comisión configurable, valor por defecto).

Mercado principal: Argentina, operando casi en un 100% sobre envíos Flex de Mercado Envíos, en general con empresas cuyos repartidores ya están registrados en Mercado Flex. La expansión a otros países es un objetivo a futuro, no del MVP.

Se contemplan dos productos: una app móvil (principalmente para repartidores) y una plataforma web (principalmente para empresas y administración).

2. Visión y objetivos

Visión. Aprovechar la capacidad ociosa de movilidad de personas que ya se desplazan por la ciudad/provincia para resolver el "último kilómetro" y los picos de demanda de las empresas de logística, a un costo menor y con mayor flexibilidad.

Objetivos del MVP.

1. Permitir que una empresa publique envíos, cargando el QR/etiqueta de Mercado Envíos de cada paquete.
2. Notificar a los repartidores correctos según su configuración de zonas.
3. Gestionar el ciclo completo por paquete: aceptación → retiro (con escaneo de QR) → entrega → prueba → confirmación → pago.
4. Garantizar que el pago se libere sólo con una señal de confirmación fuerte (código del destinatario o ventana vencida sin reclamo), nunca con la sola marca de "entregado" del repartidor.
5. Procesar pagos con retención en garantía (escrow) y liberación diferida del 95 % al repartidor.
6. Construir confianza entre las partes (verificación de identidad + reputación).

Fuera de alcance del MVP (a evaluar más adelante). Optimización automática de rutas multi-paquete, integración directa vía API con Mercado Envíos, seguros propios, expansión a otros países, facturación electrónica automática.

3. Problema y propuesta de valor

4. Actores del sistema

1. Empresa de logística (publicador / demanda). Publica y paga envíos, sube el QR de cada paquete, sigue el estado, confirma o disputa la entrega. Opera principalmente desde la web.
2. Repartidor (oferta). Configura sus zonas, recibe notificaciones, acepta paquetes, retira (escaneando el QR), entrega (idealmente con código del destinatario) y cobra. Opera principalmente desde la app móvil.
3. Destinatario final. No necesariamente es usuario registrado; recibe notificaciones (link de seguimiento + su código de confirmación) y, al recibir, le da el código al repartidor o confirma por el link.
4. Administrador / equipo de soporte. Verifica usuarios, resuelve disputas, monitorea fraude, gestiona pagos y configuración. Opera desde un panel web (back-office).

5. Flujos principales

5.1 Publicación de un envío (empresa)

1. La empresa crea una publicación: zona de origen, zona de destino, ventana horaria de retiro y entrega, monto ofrecido por paquete.
2. Carga los paquetes, cada uno con su QR/etiqueta de Mercado Envíos (Flex), su dirección puntual de destino, datos del destinatario y características (tamaño/peso/frágil). Puede cargarse de a uno o de forma masiva.
3. El sistema genera, por paquete, un código de confirmación que se le hará llegar al destinatario.
4. Define si la publicación se puede tomar completa o por partes (ej.: 10 paquetes, un repartidor toma 4 y otro 6).
5. Paga el total al publicar → los fondos quedan retenidos en garantía (escrow).
6. La publicación pasa a estado Publicada y dispara las notificaciones de matching.

5.2 Matching y notificación (repartidor)

1. El sistema evalúa qué repartidores coinciden (ver Sección 6).
2. Los repartidores compatibles reciben una notificación push con: zonas, cantidad de paquetes disponibles, monto por paquete y ventana horaria.
3. El repartidor ve el detalle y puede aceptar la cantidad de paquetes que quiera (hasta el máximo disponible).

5.3 Retiro y entrega (por paquete)

1. Al aceptar, el repartidor recibe los datos de retiro (dirección/punto y contacto).
2. Escaneo del QR al retirar: confirma que se lleva el/los paquete(s) correcto(s).
3. Realiza la entrega de cada paquete en su dirección de destino. Al entregar registra el tipo de entrega:
   • Entrega al destinatario (fuerte): el destinatario le dicta su código de confirmación, que el repartidor ingresa en la app. Es la prueba robusta de recepción real.
   • Dejado en portería / paquetería / a un tercero (débil): cuando no hay destinatario presente. Requiere foto + GPS y se registra como entrega indirecta. No equivale a recepción confirmada.
4. En ambos casos: foto del paquete entregado + GPS + timestamp obligatorios.

5.4 Confirmación y pago (por paquete)

1. Si la entrega fue con código del destinatario → el paquete pasa directo a Confirmado (señal fuerte).
2. Si la entrega fue a portería/tercero (sin código) → el paquete pasa a Pendiente de confirmación y se abre la ventana de 24–48 hs:
   • El destinatario puede confirmar por el link de seguimiento, o la empresa puede confirmar.
   • Si nadie reclama al cierre de la ventana → confirmación automática.
   • Si el destinatario reclama "no lo recibí" → pasa a Disputado.
3. El pago se libera sólo en estado CONFIRMED, nunca con la sola marca de "entregado" del repartidor. Al confirmarse: 95 % al repartidor, 5 % a la plataforma.
4. En disputa → el paquete entra al flujo de resolución del administrador.

5.5 Resolución de disputas (admin)

• Revisión de pruebas (tipo de entrega, código ingresado o no, foto, GPS, escaneo de QR, estado en Mercado Envíos, chat, historial).
• Resoluciones posibles: liberar pago, reembolsar a la empresa, pago parcial, sanción/baja de usuario.

6. Sistema de matching geográfico (núcleo del producto)

Es la pieza diferencial. La idea base: un repartidor recibe envíos cuando el paquete sale cerca de él o cuando va hacia donde el repartidor ya va o suele ir.

6.1 Configuración del repartidor

• Zona base / domicilio: desde dónde sale habitualmente (ej.: Caballito, CABA).
• Zonas de destino declaradas / rutas: a dónde está dispuesto a ir o suele ir (ej.: "voy seguido para zona norte / Escobar").
• Radio de cobertura: cuántos km está dispuesto a desviarse del origen o destino.
• Disponibilidad: días y franjas horarias.
• Tipo de vehículo y capacidad: a pie, bici, moto, auto, utilitario (define qué paquetes puede tomar por tamaño/peso/cantidad).

6.2 Criterio de coincidencia

Un repartidor recibe la notificación si se cumple al menos una de estas condiciones:

• Origen ≈ zona base del repartidor (dentro del radio configurado), o
• Destino ∈ zonas declaradas por el repartidor (dentro del radio), idealmente
• ambas condiciones (match fuerte → prioridad de notificación más alta).

6.3 Definición de "zona"

Hay que decidir el modelo (ver decisiones pendientes). Opciones:

• Por barrio/partido/localidad (ej.: barrios de CABA + partidos de GBA). Simple de entender para el usuario.
• Por código postal.
• Geográfico por radio/polígono (geofencing con lat/long). Más flexible y preciso, permite el concepto de "radio de desvío".
• Híbrido recomendado: el usuario elige zonas con nombre (barrio/partido) y por detrás se geocodifican a coordenadas + radio.

6.4 Priorización y orden

Cuando varios repartidores coinciden, ordenar/notificar según: match fuerte (origen+destino) > reputación > cercanía exacta > disponibilidad inmediata. Evaluar si el envío se ofrece a todos a la vez (primero que acepta gana) o en cascada por scoring.

7. Modelo económico y flujo de pagos

7.1 Comisión

• La comisión de la plataforma es un parámetro configurable (commissionRate) almacenado en base de datos y editable desde el back-office. Valor por defecto: 5 % (el repartidor cobra el 95 %).
• Cada Transaction guarda la tasa aplicada en ese momento (appliedCommissionRate), de modo que cambiar la comisión a futuro no altera los pagos ya calculados.
• Definir si la comisión se calcula sobre el monto que paga la empresa o se suma por encima (impacta en cómo se muestra el precio).

7.2 Retención en garantía (escrow) y liberación

1. La empresa paga el total de la publicación al publicar; el dinero queda retenido por la plataforma.
2. La liberación es por paquete y sólo en estado CONFIRMED:
   • Entrega con código del destinatario → confirma y libera (señal fuerte).
   • Entrega a portería/tercero → libera recién al vencer la ventana de 24–48 hs sin reclamo, o si el destinatario/empresa confirma.
3. Regla dura: la marca de "entregado" del repartidor (DELIVERED) nunca libera el pago por sí sola. Es un estado provisorio.
4. Esto protege al repartidor (hay fondos asegurados) y a la empresa/destinatario (no se paga por un paquete cuya recepción no está confirmada). Replica el modelo de Mercado Libre, que libera al vendedor pasada la ventana sin reclamo.

⚠️ Nota regulatoria: retener fondos de terceros tiene implicancias legales/financieras en Argentina. Conviene apoyarse en un proveedor de pagos / cuenta recaudadora que ofrezca esquema de marketplace / split de pagos, en lugar de operar la custodia uno mismo. (Pagos en pausa para el MVP — ver Sección 13.)

7.3 Billetera y retiros

• Al confirmarse un paquete, su 95 % se acredita en la billetera interna (saldo) del repartidor.
• El repartidor solicita retiro a su cuenta/CVU/CBU (definir mínimos de retiro, frecuencia y eventuales costos).

7.4 Medios de pago (Argentina)

• MercadoPago es el estándar de facto (tarjeta, dinero en cuenta, QR) y ofrece esquemas de marketplace.
• La integración de pagos está en pausa para el MVP: se modela como una interfaz con implementación mock (un ledger que registra el split 95/5 sin mover plata real) y se enchufa la cuenta recaudadora cuando esté lista.

7.5 Cancelaciones y reembolsos

• Definir política según el estado del paquete: antes de aceptación, después de aceptación, después de retiro.
• Posibles penalidades por cancelación tardía del repartidor o de la empresa.

8. Prueba de entrega, confirmación y antifraude

8.1 Principio clave: "entregado" ≠ "recibido"

Ni la marca DELIVERED del repartidor en nuestra app, ni el estado delivered de Mercado Envíos, prueban que el destinatario real recibió el paquete. Ambos son una declaración del operador/repartidor y son compatibles con escenarios como "lo dejé en portería" donde el destinatario después dice "acá no hay nada". Por eso el diseño no confía en "entregado" como prueba de recepción.

8.2 Señal fuerte: código de confirmación del destinatario (obligatorio)

• Por cada paquete se genera un código de confirmación que se le hace llegar al destinatario (junto con el link de seguimiento).
• En la entrega, el destinatario le dicta el código al repartidor, que lo ingresa en la app. Código válido = recepción real confirmada → libera el pago.
• Es la pieza central antifraude: resuelve el caso portería/paquetería, donde no hay prueba de que la persona correcta recibió.

8.3 Prueba de entrega (obligatoria, por paquete)

• Foto del paquete entregado.
• Geolocalización (GPS) en el momento de la foto.
• Timestamp del servidor.
• Tipo de entrega: al destinatario (con código) o a portería/tercero (sin código).
• Opcional: firma en pantalla.

8.4 El QR como pieza antifraude

• Escaneo en el retiro: el repartidor escanea el QR de Mercado Envíos para confirmar que retira el paquete correcto.
• Dato complementario: como cada paquete guarda su mercadoEnviosTrackingId, se puede leer el estado de Mercado Envíos para conciliar (ver Sección 9). Pero su delivered no reemplaza al código del destinatario como prueba de recepción.

8.5 Otras medidas antifraude

• Verificación de identidad (KYC) del repartidor en el onboarding (DNI + selfie / prueba de vida).
• Cotejo de GPS de la foto con la zona/dirección de destino esperada.
• Detección de fotos reutilizadas (hash/EXIF, forzar captura desde cámara).
• Sistema de reputación y baja automática ante reincidencias.
• Límite de paquetes en paralelo para usuarios nuevos / sin historial.

9. Integración con Mercado Envíos (Flex)

Para el MVP es lectura/conciliación opcional; la confirmación de pago no depende de ML sino del código del destinatario. Esta sección define cómo se usa cuando se integre.

9.1 Acceso

• No se accede "desde el QR" de forma anónima. El QR sólo aporta el shipment_id. Para consultar el estado se necesita acceso a la API de Mercado Libre con un token OAuth autorizado sobre la cuenta de la empresa de logística (la que es vendedora/operadora en ML).

9.2 Qué se puede leer

• El historial de estados del envío (/shipments/{id}/history): handling → ready_to_ship → shipped → delivered (o not_delivered), con timestamps.
• Vía webhooks/notificaciones de envíos para no hacer polling.

9.3 Limitación clave

• El delivered de Mercado Envíos es declarado por el operador/repartidor (que en este circuito ya usa la app de Flex). No es una confirmación independiente del destinatario y no existe un evento separado de "recibido" distinto del "entregado".
• Por lo tanto, el delivered de ML sirve como dato complementario / de conciliación, pero la señal fuerte de pago en nuestra plataforma sigue siendo el código del destinatario (o la ventana vencida sin reclamo).

9.4 Mejora futura

• Suscribirse a las notificaciones de Mercado Envíos para enriquecer el seguimiento (en camino, entregado, no entregado) y detectar inconsistencias entre el estado de ML y el de nuestra plataforma.

10. Funcionalidades por plataforma

10.1 App móvil (repartidor) — prioritaria

• Registro + verificación de identidad y vehículo.
• Configuración de zona base, zonas de destino, radio, disponibilidad y vehículo.
• Notificaciones push de envíos compatibles.
• Listado y detalle de paquetes disponibles; aceptar cantidad.
• Escaneo de QR en el retiro.
• Navegación a punto de retiro y de entrega (deep link a Maps/Waze).
• Entrega: ingreso del código del destinatario o registro de entrega a portería/tercero; captura de foto + GPS.
• Billetera: saldo, historial de cobros, solicitud de retiro.
• Reputación y calificaciones recibidas.
• Chat / contacto con la empresa.
• Historial de paquetes entregados.

10.2 Plataforma web (empresa) — prioritaria

• Registro de empresa y datos fiscales.
• Alta de publicaciones y carga de paquetes con su QR/etiqueta de Mercado Envíos (individual y por lote/carga masiva).
• Definición de zonas, precio, ventanas horarias, fraccionamiento del lote.
• Pago y seguimiento de fondos retenidos.
• Tablero de estado de paquetes en tiempo real.
• Confirmación / disputa de entregas por paquete.
• Calificación del repartidor.
• Reportes y facturación.

10.3 Back-office (administración)

• Verificación y gestión de usuarios (alta/baja, KYC).
• Gestión y resolución de disputas.
• Monitoreo de pagos, comisiones y retiros.
• Configuración de parámetros (comisión, ventana de confirmación, radios por defecto).
• Métricas y alertas de fraude.

10.4 Features adicionales sugeridas (post-MVP)

• Seguimiento en vivo (GPS) durante la entrega y link de tracking para el destinatario.
• Integración con Mercado Envíos vía API (estado real, conciliación).
• Optimización de rutas para lotes multi-paquete.
• Calificación bidireccional y niveles/insignias de repartidor.
• Pago instantáneo opcional (con comisión extra) sin esperar la ventana.
• Seguro por paquete opcional.
• Tarifas dinámicas según demanda/distancia/urgencia.
• Programación de envíos recurrentes para empresas.

11. Modelo de datos (entidades principales)

Cambio clave respecto de v1: el paquete es una entidad de primera clase (cada uno con su QR de Mercado Envíos, su dirección y su confirmación), no un simple contador. La confirmación de recepción se basa en un código del destinatario, no en la marca de "entregado".

• User (base): id, role ('company' | 'courier' | 'admin'), email, phone, kycStatus, reputationScore, createdAt.
• Company: userId, taxId, paymentMethods.
• Courier: userId, baseZone {name, lat, long}, destinationZones [{name, lat, long, radiusKm}], coverageRadiusKm, availability, vehicleType ('foot'|'bike'|'motorcycle'|'car'|'van'), walletBalance.
• Shipment (publicación/lote): id, companyId, originZone {name, lat, long}, destinationZone {name, lat, long}, pricePerPackage, pickupWindow, deliveryWindow, allowsSplit, status (derivado), createdAt.
• Package (paquete individual): id, shipmentId, mercadoEnviosTrackingId, qrCodeData, labelFileUrl, scannedAtPickup, recipientName, recipientAddress, recipientPhone, dimensions, weight, fragile, confirmationCode (el secreto que recibe el destinatario), mercadoEnviosStatus (último estado leído de ML, opcional), status, assignmentId, courierId, proofOfDeliveryId.
• Assignment (paquetes tomados por un repartidor): id, shipmentId, courierId, packageIds[], acceptedAt.
• ProofOfDelivery (por paquete): packageId, deliveryType ('recipient' | 'proxy'), photoUrl, lat, long, timestamp, confirmationCodeEntered (requerido si deliveryType = 'recipient'), proxyDetails (quién/dónde recibió si 'proxy': portería, paquetería, vecino), signature?.
• Transaction (por paquete): packageId, amount, platformFee, courierPayout, appliedCommissionRate (tasa usada en esta transacción), escrowStatus, releaseAt.
• Dispute: packageId, status, evidence, resolution.
• Rating: fromUserId, toUserId, score, comment.
• PlatformConfig (parámetros editables): commissionRate (default 0.05), confirmationWindowHours (default 48) y otros tunables (radios por defecto, etc.). Editable desde el back-office; es la fuente del valor de comisión que se usa al crear cada Transaction.

11.1 Máquina de estados

• Package.status: AVAILABLE → ASSIGNED → PICKED_UP → {DELIVERED_TO_RECIPIENT | DELIVERED_TO_PROXY} → ... → (CONFIRMED | DISPUTED); CANCELLED desde estados previos a la entrega.
  • DELIVERED_TO_RECIPIENT (con confirmationCodeEntered válido) → CONFIRMED (inmediato; señal fuerte).
  • DELIVERED_TO_PROXY (portería/tercero, sin código) → PENDING_CONFIRMATION → CONFIRMED (al vencer la ventana 24–48 hs sin reclamo, o si el destinatario/empresa confirma) | DISPUTED (si el destinatario reclama no recibido).
  • Regla dura: el pago se libera sólo al entrar en CONFIRMED. Ninguna variante de "entregado" libera por sí sola.
• Shipment.status: PUBLISHED → PARTIALLY_ASSIGNED → FULLY_ASSIGNED → COMPLETED (y CANCELLED), derivado de los estados de sus Packages.

12. Aspectos legales y regulatorios (Argentina) — a validar con asesor

No constituye asesoramiento legal. Son puntos a revisar con un profesional antes de operar.

• Relación con el repartidor: definir si son trabajadores independientes (monotributistas) y los términos de uso que regulan la relación, para evitar contingencias laborales.
• Custodia y procesamiento de fondos: retener dinero de terceros puede requerir esquemas/licencias específicos; preferible usar un proveedor/cuenta recaudadora con esquema de marketplace/split.
• Uso de Mercado Envíos / Flex: revisar los términos de uso de MercadoLibre respecto de operar/transportar envíos Flex a través de un tercero, la manipulación de las etiquetas/QR y el acceso a su API por cuenta de la empresa.
• Responsabilidad por pérdida/daño de paquetes: quién responde, límites, seguro.
• Protección de datos personales (Ley 25.326): consentimiento, almacenamiento de DNI, fotos, geolocalización, código y datos del destinatario.
• Términos y Condiciones + Política de Privacidad desde el día 1.
• Facturación / impuestos de la comisión de la plataforma.
• Mercaderías prohibidas o reguladas: política clara de qué no se puede transportar.

13. Arquitectura técnica (propuesta inicial)

Propuesta orientativa; sujeta a preferencias del equipo de desarrollo.

• Monorepo: pnpm workspaces + Turborepo, con apps/web, apps/mobile y packages/shared (tipos + validaciones + máquina de estados, fuente de verdad compartida).
• App móvil: Expo (React Native, TypeScript). Cámara/GPS/push y escaneo de QR.
• Web (empresa + back-office): Next.js (TypeScript), desplegada en Vercel (puede empezar en un path o subdominio del sitio existente).
• Backend / base de datos / auth / storage: Supabase (Postgres + PostGIS para el matching geográfico, Auth, Storage para fotos y etiquetas).
• Notificaciones push: servicio de mensajería (ej.: Firebase Cloud Messaging) + email para eventos críticos (incluido el envío del código al destinatario).
• Mapas y geocodificación: proveedor de mapas para zonas, direcciones y ruteo.
• Integración Mercado Envíos: cliente para la API de ML con OAuth sobre la cuenta de la empresa (post-MVP / conciliación).
• Pagos: en pausa para el MVP. Interfaz PaymentProvider con implementación mock (ledger 95/5); se conecta la cuenta recaudadora cuando esté disponible.

14. Requisitos no funcionales

• Seguridad: cifrado en tránsito y en reposo de datos sensibles (DNI, fotos, ubicación, código y datos del destinatario); control de accesos por rol. El código de confirmación nunca se expone al repartidor antes de la entrega.
• Disponibilidad y escalabilidad: soportar picos de notificaciones simultáneas.
• Rendimiento del matching: notificación al repartidor en segundos tras la publicación.
• Trazabilidad / auditoría: todo cambio de estado y movimiento de dinero queda registrado.
• Privacidad: mostrar la dirección exacta de retiro/entrega sólo al repartidor asignado.

15. Métricas / KPIs

• Tasa de match (paquetes publicados que reciben al menos una aceptación).
• Tiempo desde publicación hasta aceptación.
• Tasa de entregas confirmadas con código vs. a portería.
• Tasa de disputas y de fraude detectado.
• GMV (volumen transado) y comisión generada.
• Repartidores activos / recurrentes y empresas activas.
• Calificación promedio de ambos lados.

16. Riesgos y mitigaciones

17. Roadmap por fases

Fase 0 — Definición. Cerrar decisiones pendientes (Sección 18), elegir stack y proveedor de pagos, T&C y privacidad.

Fase 1 — MVP. Registro + KYC básico, publicación de envíos con carga de QR por paquete, generación de código por paquete, matching por zonas, notificaciones, aceptación, escaneo en retiro, entrega con código del destinatario (o a portería), prueba de entrega, escrow + liberación 95/5 (mock) sólo en CONFIRMED, billetera y retiros, back-office mínimo de disputas.

Fase 2 — Confianza y escala. Reputación avanzada, tracking en vivo, chat, carga masiva de paquetes, integración/conciliación con Mercado Envíos vía API, mejoras antifraude.

Fase 3 — Crecimiento. Optimización de rutas multi-paquete, tarifas dinámicas, seguro propio, expansión a otros países.

18. Decisiones pendientes (a definir antes de arrancar)

1. Modelo de "zona": ¿barrios/partidos, código postal o geográfico por radio? (Recomendación: híbrido).
2. Fraccionamiento de lotes: ¿una publicación de 10 paquetes la toma un solo repartidor o se puede dividir entre varios?
3. Asignación: ¿primero que acepta gana, o asignación por scoring/cascada?
4. Cálculo de la comisión: ¿el 5 % se descuenta del precio o se suma por encima?
5. Ventana de confirmación: ¿24 o 48 hs? ¿La define la empresa por publicación?
6. Entrega a portería/tercero: ¿se permite siempre, sólo con autorización previa del destinatario, o se penaliza?
7. Cómo llega el código al destinatario: ¿SMS, email, WhatsApp, link de seguimiento? ¿Lo provee la empresa o lo genera la plataforma?
8. Pago instantáneo opcional: ¿se ofrece desde el MVP?
9. Estado fiscal/laboral del repartidor: definir con asesor.
10. Proveedor de pagos / cuenta recaudadora y esquema de custodia/split.
11. Cobertura inicial: ¿qué zona/corredor se lanza primero para asegurar liquidez? (ej.: CABA ↔ Zona Norte).
12. Integración con Mercado Envíos: ¿se usa la API para conciliar estados desde el MVP o se deja para Fase 2? ¿La empresa autoriza el acceso OAuth?

19. Glosario

• Flex / Mercado Envíos: servicio de envíos de MercadoLibre; en Flex el manejo de la entrega lo gestiona el vendedor/logística, y cada paquete tiene su etiqueta con QR.
• QR / etiqueta: código de cada paquete que identifica el envío en Mercado Envíos; se escanea al retirar.
• Código de confirmación: secreto por paquete que recibe el destinatario y que el repartidor ingresa al entregar; es la prueba fuerte de recepción real.
• Señal débil / fuerte: "entregado" del repartidor o de ML (débil, no prueba recepción) vs. código del destinatario o ventana sin reclamo (fuerte).
• Escrow / retención en garantía: fondos pagados por la empresa que la plataforma retiene hasta confirmar la entrega de cada paquete.
• Matching: proceso de vincular un envío publicado con los repartidores compatibles.
• KYC: verificación de identidad del usuario.
• GMV: volumen monetario total transado en la plataforma.
• Última milla: tramo final de la entrega hasta el destinatario.
• commissionRate: comisión de la plataforma, parámetro configurable en base de datos (por defecto 5 %); cada transacción guarda la tasa aplicada (appliedCommissionRate).