Ambigüedad y montos repetidos

Estado documental: Contrato propuesto. Los mecanismos internos de evaluación y sus umbrales no forman parte del contrato público.

Cuándo existe ambigüedad

Existe ambigüedad cuando la información disponible no permite relacionar con seguridad una operación con un ingreso.

Ejemplos:

• varias órdenes por el mismo monto;
• varios ingresos similares;
• información incompleta;
• comprador distinto del titular de la cuenta;
• falta de referencias adicionales;
• horarios muy cercanos;
• una constancia que podría corresponder a varias órdenes;
• pago fraccionado;
• pago acumulado para varias ventas;
• datos contradictorios.

YUPY no debe decidir arbitrariamente

Información insuficiente
→ no asignar arbitrariamente
→ registrar ambigüedad
→ solicitar o esperar más evidencia
→ revisión cuando corresponda

Resultados conceptuales

Confirmado

La operación quedó conciliada.

Pendiente

Existe información relacionada, pero todavía falta sustento para confirmar.

reconciliation_pending

Ambiguo

La información disponible requiere revisión.

ambiguous
review_required

Sin confirmación

Todavía no existe información suficiente para confirmar el pago.

awaiting_payment

Verificación reforzada

Cuando un usuario informa que pagó o envía una constancia, YUPY puede ejecutar una verificación reforzada.

Esto significa que YUPY:

• registra la señal;
• incorpora la evidencia;
• vuelve a evaluar la información disponible;
• mantiene auditoría;
• evita efectos duplicados ante clics repetidos.

No implica que YUPY solo consulte la cuenta después de presionar “Ya pagó”.

Evidencia solicitada

YUPY puede solicitar:

• captura;
• fotografía;
• número de operación;
• fecha y hora;
• monto;
• medio utilizado;
• nombre visible;
• otra referencia comercial.

Recibimos tu constancia.
Estamos verificando la operación.

Aún estamos esperando la confirmación del pago.
La verificación continúa.

Revisión manual

Un caso de revisión debe mostrar, según los permisos de la empresa:

• orden;
• monto esperado;
• información financiera relacionada;
• monto recibido;
• fechas y horas;
• cuenta receptora;
• turno;
• dispositivo;
• contexto opcional;
• constancias;
• datos extraídos de la evidencia;
• acciones previas;
• riesgo de duplicidad.

Acciones permitidas

confirm_reconciliation
maintain_pending
request_more_evidence
mark_unresolved
accept_late_payment
reject_commercial_operation
create_supplemental_order
create_refund_case
close_without_financial_match

Confirmación manual

Una conciliación manual debe registrar:

• responsable;
• fecha y hora;
• orden seleccionada;
• motivo;
• evidencia utilizada;
• advertencias;
• estado anterior;
• estado nuevo.

Corrección de una decisión

La historia no debe modificarse directamente. Una corrección posterior se registra como una nueva acción auditada.

decisión original
→ acción de reversión
→ nueva evaluación
→ nuevo estado

Webhook relacionado

Este ejemplo reutiliza el evento y el sobre canónico documentados en API y Webhooks.

{
  "event_id": "evt_01J008",
  "event_type": "payment.review_required",
  "event_version": "1.0",
  "created_at": "2026-07-20T15:11:00-05:00",
  "data": {
    "yupy_transaction_id": "ypt_01JXYZ",
    "external_transaction_id": "ORDER-10482",
    "reason": "insufficient_matching_evidence",
    "state": {
      "operational": "active",
      "financial": "review_required"
    }
  }
}

Criterios de aceptación

1. YUPY no concilia arbitrariamente.
2. El monto y el nombre no resuelven todos los casos.
3. La revisión muestra la información disponible para la empresa.
4. Puede solicitarse evidencia.
5. La verificación reforzada no expone mecanismos internos.
6. Las acciones manuales requieren autorización.
7. Toda decisión manual queda auditada.
8. Las correcciones conservan la historia.
9. Los casos aparecen en operación y reportes.
10. El sistema del cliente puede recibir payment.review_required.