Expiración y pagos tardíos

Estado documental: Contrato propuesto. La duración exacta de la observación posterior depende de la configuración y del servicio contratado.

Qué es un pago tardío

Un pago tardío es un ingreso identificado después de que la experiencia de cobro dejó de estar activa.

Puede ocurrir después de:

vencer una sesión de Web Checkout;
expirar la vigencia operativa;
cancelar una orden;
cerrar un turno;
informar al comprador que la ventana terminó.

Sesión vencida
≠ imposibilidad de recibir dinero

Orden cancelada
≠ desaparición de un ingreso posterior

El vencimiento no elimina la operación financiera

YUPY puede continuar identificando ingresos posteriores asociados con una orden vencida o cancelada.

La documentación no promete un periodo universal. La ventana aplicable se define por configuración y contrato.

Flujo

Orden creada
        ↓
Checkout vence o la orden se cancela
        ↓
Comprador paga después
        ↓
YUPY identifica el ingreso
        ↓
No reactiva automáticamente la venta
        ↓
Genera un caso pendiente
        ↓
Alerta a la empresa

Estado separado

{
  "state": {
    "operational": "expired",
    "financial": "late_detected"
  }
}

Una orden puede estar operativamente vencida y, al mismo tiempo, tener dinero identificado.

Acciones de YUPY

YUPY debe:

conservar la relación con la orden original;
registrar el resultado financiero;
identificar que ocurrió fuera de la ventana;
crear un pendiente;
alertar a los responsables configurados;
mostrarlo en los reportes;
entregar la información necesaria para resolverlo.

YUPY no debe:

reactivar automáticamente la venta;
entregar automáticamente el producto;
aceptar comercialmente el pago en nombre de la empresa;
devolver automáticamente el dinero.

Decisión de la empresa

aceptar el pago tardío
continuar la venta
reprogramar el servicio
mantener el caso pendiente
rechazar la operación comercial
crear un caso de devolución

Toda decisión debe quedar auditada.

Comunicación al comprador

Detectamos un pago realizado después de la vigencia
de la operación.

La empresa debe revisar el caso.
Conserva tu código de transacción.

YUPY no comunica que el pago fue aceptado comercialmente hasta que la empresa lo determine.

Alertas

La empresa puede configurar alertas para:

vendedor;
supervisor;
responsable del dispositivo;
administrador;
otra persona autorizada.

Canales posibles:

WhatsApp
correo electrónico
chat operativo
consola
webhook

Webhook relacionado

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

{
  "event_id": "evt_01J007",
  "event_type": "payment.late_detected",
  "event_version": "1.0",
  "created_at": "2026-07-20T15:10:00-05:00",
  "data": {
    "payment_order_uid": "pay_01JXYZ",
    "external_transaction_id": "ORDER-10482",
    "expected_amount": "85.50",
    "detected_amount": "85.50",
    "currency": "PEN",
    "detected_at": "2026-07-20T15:10:00-05:00",
    "state": {
      "operational": "expired",
      "financial": "late_detected"
    },
    "action_required": "client_review"
  }
}

Pago posterior a una cancelación

cancelled
+ ingreso identificado
→ cancelled_order_with_payment
→ pending case

La cancelación no se elimina ni se transforma silenciosamente.

Reportes

Los pagos tardíos deben aparecer en:

reporte de pagos tardíos;
bandeja de pendientes;
reporte de transacciones;
reporte de conciliación;
reporte de canceladas con pago;
resumen operativo correspondiente;
exportaciones programadas cuando estén configuradas.

Criterios de aceptación

La expiración no borra la orden.
La cancelación no oculta ingresos posteriores.
El pago tardío se asocia con la orden original.
No se reactiva automáticamente la venta.
Se crea un pendiente.
Se alerta a la empresa.
La empresa decide la resolución comercial.
Una devolución sigue siendo ejecutada por la empresa.
El caso conserva trazabilidad.
El caso aparece en reportes y auditoría.

Payment Order / API Engine v1.0

Quién define el timeout de la Payment Order

El caller no controla la vigencia de la Payment Order enviando expires_in_seconds. Para Web Checkout, YUPY resuelve la duración efectiva desde la policy canónica aplicable al cliente autenticado, Counter, canal y payment_method; el instrumento concreto se resuelve internamente.

cliente autenticado
+ Counter resuelto
+ channel
+ payment_method
        ↓
master_data policy
        ↓
instrumento resuelto por YUPY
timeout_seconds
        ↓
Payment Order / expires_at

Esto permite que la política cambie en el futuro sin alterar retroactivamente la vigencia que fue aplicada a una Payment Order ya creada.

Payment Order y checkout session tienen relojes distintos

payment_order.expires_at
≠
checkout_session.expires_at

payment_order.expires_at controla el lifecycle de la orden y la ocupación de su Counter. checkout_session.expires_at controla la sesión, token o experiencia Web. Una sesión Web puede vencer sin borrar la Payment Order, y una nueva sesión puede ser posible mientras el lifecycle de la Payment Order lo permita.

Qué ocurre al expirar o cancelar la Payment Order

Cuando la Payment Order alcanza expired o cancelled, se considera terminal: YUPY registra closed_at y libera inmediatamente el Counter que estaba adquirido en exclusividad.

Payment Order abierta
Counter adquirido
        ↓
expires_at o cancelación
        ↓
expired / cancelled
closed_at
COUNTER_RELEASED
ORDER_CLOSED

El Counter queda disponible para nuevas Payment Orders. La observación financiera posterior de la orden histórica continúa sin mantener ocupado ese recurso operativo.

Pago detectado después del cierre

Si Reconciliation o una fuente financiera identifica posteriormente un ingreso asociado a la Payment Order histórica, YUPY conserva el estado terminal operativo original y registra la evidencia tardía en la dimensión financiera.

Payment Order = expired o cancelled
Counter = released
        ↓
ingreso identificado después
        ↓
late_detected
payment.late_detected
        ↓
pending case / client_review

El pago tardío no reabre la Payment Order original. Tampoco elimina closed_at, no cambia silenciosamente expired o cancelled a confirmed y no vuelve a ocupar el Counter ya liberado.

La evidencia financiera queda asociada a la Payment Order original para trazabilidad, conciliación, reportes y revisión. La empresa decide la resolución comercial posterior, incluyendo aceptación, ajuste, nueva venta o devolución según corresponda.

Webhook público

Se conserva payment.late_detected como evento público. El payload utiliza payment_order_uid para identificar la Payment Order histórica y external_transaction_id para correlacionarla con el sistema origen.

Métricas

Cuando los timestamps estén disponibles, YUPY puede distinguir el tiempo operativo de presentación del tiempo financiero de confirmación o detección:

presented_at
confirmed_at
detected_at
closed_at

En un pago tardío puede existir detected_at > closed_at. Esa relación temporal es normal y no implica reapertura del recurso operativo.

Changelog — Payment Order / API Engine

2026-08-09 — Payment Order / API Engine v1.0: se renombró en esta página la identidad canónica pública yupy_transaction_id a payment_order_uid; se estableció que el timeout de la Payment Order proviene de una política de YUPY y no de expires_in_seconds enviado por el caller; se separaron payment_order.expires_at y checkout_session.expires_at; se documentó que expired y cancelled registran closed_at y liberan el Counter; y se fijó que payment.late_detected conserva la evidencia histórica sin reabrir ni reocupar la Payment Order original.

API Technical Docs