Política de Disputas — Mercanica

Versión: 1.2 Última actualización: 6 de abril de 2026

1. Objeto

Esta Política de Disputas regula el proceso de protección de compra (disputa formal vinculada al pedido) dentro de Mercanica.

Aplica a pedidos que sigan un flujo con custodia de fondos (escrow) y en los que el sistema permita abrir una disputa mientras los fondos sigan en custodia según el estado del pedido y las reglas vigentes en la interfaz.

No sustituye los reclamos de garantía posteriores a la liberación del pago al vendedor, que son un canal distinto y no congelan la custodia una vez completada la orden según las reglas del producto.

2. Alcance y motivos

La disputa formal puede abrirse por motivos alineados al producto, entre otros (según opciones en la interfaz). En la implementación coexisten el motivo declarado por el usuario (`DisputeReason`) y la clasificación del caso (`CaseKind`) cuando el producto lo active: p. ej. no recibido frente a entrega declarada por el vendedor (`NOT_RECEIVED`), problema con el artículo tras entrega verificada (`RETURN_OR_ITEM_ISSUE`), o escalación tras rechazo de una solicitud de cancelación (`CANCEL_REQUEST_ESCALATED`). La interfaz puede agrupar o etiquetar según `CaseKind` sin sustituir los motivos legales de lista.

Motivos habituales (lista orientativa):

• Artículo no recibido (en el contexto de entrega registrada por el vendedor en la Plataforma, cuando corresponda)
• Artículo no conforme a la descripción
• Artículo dañado
• Artículo equivocado
• Sospecha de fraude
• Otro (con explicación)

Canal distinto — cancelación por demora: la solicitud de cancelación y reembolso cuando el pedido aún no consta como entregado con verificación de entrega del vendedor puede tramitarse como solicitud al vendedor (aceptar/rechazar) sin ser aún una disputa formal, hasta que el comprador escale según reglas del producto. Ver `docs/business-logic.md` (cancelación D7 / D15 / D16).

No constituyen por sí solos motivos de esta política (y pueden rechazarse o archivarse según reglas del producto):

• Arrepentimiento o cambio de opinión sin incumplimiento relevante
• Diferencias menores o cosméticas que no alteren de forma sustancial el valor o uso del bien, salvo que el Operador evalúe lo contrario en casos concretos

3. Plazo para abrir la disputa

Los plazos exactos y los requisitos de elegibilidad (p. ej. que el pedido conste como entregado según la verificación de entrega del vendedor en la Plataforma) son los publicados en la interfaz y en `docs/business-logic.md`. A efectos de esta política:

• Problemas con el artículo (calidad, descripción, daño, equivocación, etc.): el Comprador podrá abrir una disputa formal dentro de la ventana de protección posentrega contada desde la fecha/hora de entrega registrada en el pedido (`deliveredAt`), típicamente 3 días naturales, solo si el pedido cumple los requisitos de estado y elegibilidad publicados (no basta con que el envío esté “marcado como enviado” sin el cierre que fije el producto). Si el comprador confirmó recepción por el carril que libera el escrow de inmediato, las reglas de la Plataforma pueden excluir nuevas disputas formales de custodia para ese pedido; puede seguir aplicando garantía u otros canales documentados.

• Discrepancia “no recibí” cuando el vendedor sí registró entrega verificada en la Plataforma: el Comprador podrá abrir la disputa conforme a las mismas reglas de ventana y elegibilidad que el producto publique para ese tipo de caso (`NOT_RECEIVED`).

• Solicitud de cancelación por demora (sin entrega verificada dentro del plazo de gestión): se rige por el flujo de solicitud y respuesta del vendedor y, en su caso, por la escalación a disputa; no sustituye los plazos anteriores salvo que el caso pase a disputa formal.

Transcurrido el plazo aplicable sin disputa abierta (o sin escalación cuando corresponda):

• El pedido puede seguir su curso hacia completado según estados del producto
• Los fondos en custodia pueden liberarse al vendedor cuando cumplan las demás condiciones (sin disputa bloqueante; ventana de protección o confirmación de recepción con liberación inmediata, según el flujo del pedido — ver `docs/business-logic.md`)

4. Efecto al abrir la disputa

Mientras la disputa esté abierta y el escrow lo permita:

• Los fondos pueden permanecer retenidos y no liberarse al vendedor de forma automática
• Se puede bloquear la liberación hasta resolución o cierre del caso según estados del sistema
• Se inicia el flujo de revisión (respuesta del vendedor, evidencia, revisión por el Operador)

5. Flujo de la disputa (etapas)

La narrativa canónica de negociación estructurada (propuestas de solución, plazos y escalación) está en `docs/business-logic.md`, `docs/post-purchase-case-redesign.md` §1.8 y `docs/dispute-thread-logic.md`. A efectos de esta Política:

5.1 Apertura

El Comprador debe:

• Indicar el motivo entre los permitidos (y, cuando el sistema lo muestre, la vía o tipo de caso coherente con `CaseKind` en la implementación)
• Aportar descripción y, cuando el sistema lo solicite, evidencia inicial (por ejemplo enlaces a archivos o documentación admitida por la Plataforma)
• Cuando el producto lo exija, enviar una propuesta inicial de solución estructurada (p. ej. reembolso total, devolución con reembolso total, reembolso parcial en porcentajes discretos permitidos) como constancia de intención. A partir de entonces el caso puede quedar pendiente de respuesta del vendedor y comenzar un plazo del orden de 48 horas para esa respuesta, contado desde que la propuesta queda registrada como pendiente en el sistema (salvo extensiones operativas que la Plataforma comunique).

La aceptación entre partes no sustituye por sí sola la resolución y ejecución monetaria por el Operador cuando así lo prevea el producto (MVP).

El hilo del caso puede incluir mensajes breves entre comprador y vendedor dentro de la Plataforma, sin intercambio de datos de contacto externos, y acciones estructuradas (propuestas, aceptaciones, rechazos a contrapropuestas, constancia de «reclamo sin fundamento», solicitud de intervención del soporte) según `docs/dispute-thread-logic.md`.

5.2 Respuesta del vendedor a la propuesta del comprador

Cuando corresponda según la interfaz, el vendedor dispone de opciones que incluyen, de forma orientativa:

• Aceptar la propuesta del comprador: queda registro del acuerdo; el caso pasa a trámite de resolución por el Operador conforme al MVP.
• Rechazar y formular una contrapropuesta de solución: el caso puede quedar pendiente de respuesta del comprador y abrir un nuevo plazo del orden de 48 horas para el comprador, desde la contrapropuesta pendiente.
• Indicar que el reclamo no tiene fundamento, como acción distinta del mero rechazo con contrapropuesta: el caso puede escalarse de inmediato a revisión por el Operador sin continuar la negociación por propuestas en ese carril.

Si el vendedor no actúa dentro del plazo aplicable frente a una propuesta pendiente del comprador, la Plataforma puede considerar la propuesta no atendida y derivar el caso a revisión por el Operador, sin que ello implique, por sí solo, un resultado monetario automático a favor de una parte (según `docs/business-logic.md`).

5.3 Respuesta del comprador a la contrapropuesta

Si el vendedor formuló una contrapropuesta, el comprador podrá, según la interfaz:

• Aceptarla (registro de acuerdo y trámite ante el Operador), o
• Rechazarla, lo que puede llevar el caso a una fase final en la que el vendedor solo podrá aceptar la propuesta original del comprador o solicitar la intervención del Operador, sin nuevas rondas libres de contraofertas, salvo que el producto publique otra cosa.

Si el comprador no responde dentro del plazo aplicable frente a una contrapropuesta pendiente, la Plataforma puede derivar el caso a revisión con la misma cautela de no ejecutar automáticamente desenlaces monetarios sin intervención conforme a reglas publicadas.

5.4 Evidencia adicional

Comprador y vendedor pueden aportar evidencia en las fases permitidas por la interfaz. El envío de evidencia puede cambiar el estado del caso (por ejemplo hacia evidencia presentada / revisión).

5.5 Revisión por el Operador

El Operador (o personal autorizado) evalúa la evidencia, el historial disponible en la Plataforma (incluidas propuestas y acuerdos registrados) y las reglas del sistema, sin actuar como tribunal estatal.

5.6 Resolución

El Operador podrá resolver, según el caso:

• A favor del comprador (reembolso total o parcial cuando aplique resolución parcial)
• A favor del vendedor (liberación de fondos al vendedor)
• Resolución parcial con montos determinados para reembolso al comprador, liberación al vendedor y ajustes de comisión de plataforma según la implementación (incluido redondeo controlado)

La ejecución monetaria sigue los servicios de escrow y pago; las resoluciones quedan registradas en la Plataforma.

6. Tipos de resultado (orientativos)

Los desenlaces dependen de los hechos y la evidencia. De forma orientativa:

• Reembolso total al comprador: cuando corresponda por no entrega, incumplimiento grave, fraude verificable u otras causas que el Operador determine según reglas internas.
• Reembolso parcial: cuando exista entrega parcial, diferencia parcial sustancial o acuerdo de división reflejado en la resolución parcial implementada.
• Liberación al vendedor: cuando la evidencia respalde el cumplimiento o la disputa sea manifiestamente infundada según criterio operativo razonable.

7. Evidencia válida

Puede incluir, según lo permita el sistema:

• Fotos o videos cargados a través de la Plataforma
• Comprobantes de envío o entrega registrados en el pedido
• Mensajes o hilos dentro de la Plataforma (ofertas, chat de pedido, mensajes de disputa)

El Operador no está obligado a considerar como prueba principal contenido externo no verificable por el sistema, salvo que la ley o una orden competente lo exija.

8. Criterios de decisión

El Operador podrá considerar, entre otros factores:

• Coherencia y fuerza probatoria de la evidencia
• Historial de comportamiento y riesgo del usuario (incluidos sistemas de puntuación o umbrales si el producto los implementa)
• Cumplimiento de plazos por parte de comprador y vendedor
• Reglas de negocio publicadas y estados técnicos del pedido y del escrow

Este proceso es administrativo y operativo, no es un juicio civil ni sustituye la jurisdicción ordinaria.

9. Disputas abusivas o fraudulentas

Se consideran abusivas o sujetas a sanción, entre otros supuestos:

• Reclamos falsos o engañosos
• Uso reiterado de disputas sin fundamento suficiente
• Maniobras para eludir normas de la Plataforma o obtener beneficios indebidos

Consecuencias posibles:

• Suspensión o cierre de cuenta
• Pérdida de acceso a protecciones o límites adicionales
• Ajustes en puntuación de riesgo según el producto

10. Relación con contracargos (chargebacks)

Las disputas internas de Mercanica son independientes del proceso de contracargo de la red de tarjetas o del banco.

Un contracargo se gestiona frente al procesador de pago y puede implicar reconciliación y ajustes de saldo según los Términos. Abrir una disputa en la Plataforma y además iniciar un contracargo sobre el mismo pago puede considerarse abuso o doble vía y dar lugar a sanciones o compensaciones conforme a políticas de riesgo y a la ley.

11. Carácter de las decisiones y correcciones

En la máxima medida permitida por la ley, las decisiones del Operador sobre la disputa son vinculantes entre las partes y el Operador en el ámbito del servicio, sin perjuicio de derechos imperativos del consumidor.

No existe un procedimiento interno de apelación tipo judicial. Aun así, el Operador podrá corregir errores evidentes de hecho o de sistema (por ejemplo duplicidad, fallo de asignación de montos) cuando se detecten y conforme a auditoría.

12. Plazos de resolución

Los tiempos hasta una resolución final no son fijos ni garantizados de antemano; dependen de la complejidad del caso, la carga operativa y la completitud de la evidencia. El Operador procura actuar en un plazo razonable, sin crear expectativa de un número concreto de días hábiles salvo que la interfaz publique un compromiso explícito en el futuro.

13. Efectos de la resolución

Según el resultado implementado:

• Pueden liberarse fondos al vendedor, reembolsarse al comprador o aplicarse una combinación en resolución parcial
• Pueden ajustarse saldos, comisiones o registros contables asociados al pedido, conforme a los servicios de la Plataforma y a la ley

14. Integración con los Términos y el Acuerdo de vendedor

Esta Política complementa los Términos y condiciones y el Acuerdo de vendedor. Ante inconsistencia sobre una misma regla operativa (plazos, estados, montos), prevalece lo implementado en la Plataforma dentro del marco legal, debiendo actualizarse estos documentos para alinear el texto.

_Fin del documento._