Vigencia, espera y pagos tardíos

Estado documental: Propuesto. Este documento define el comportamiento operativo esperado del Web Checkout; los tiempos y alertas definitivos se configuran por empresa.

Objetivo

Definir cómo se configura la vigencia de una sesión, qué ocurre durante la espera y cómo se trata un pago detectado después del vencimiento.

La vigencia es configurable por la empresa

La duración de la sesión de Web Checkout es configurable desde la consola de YUPY.

La empresa puede establecer valores distintos según:

• sitio web;
• marca;
• tipo de venta;
• canal;
• producto o servicio;
• perfil de cobro;
• caso de uso;
• otra regla comercial habilitada.

Cuando no existe una configuración específica, YUPY utiliza el valor general de la empresa. Si tampoco existe, se aplica el valor predeterminado de YUPY.

Configuración específica del uso
    ↓
Configuración general de la empresa
    ↓
Valor predeterminado de YUPY

La solicitud puede proponer expires_in_seconds cuando el contrato lo permita, pero YUPY devuelve siempre el valor efectivo mediante expires_at.

{
  "expires_in_seconds": 900
}

{
  "checkout_session": {
    "expires_at": "2026-07-20T14:45:02-05:00"
  }
}

Tres conceptos distintos

Sesión de checkout

Es el acceso temporal a la ventana administrada por YUPY.

Orden de pago

Es la operación comercial que YUPY debe seguir y conciliar.

Destino receptor

Es el QR de Yape, QR de Plin o cuenta bancaria al que llega el dinero.

Estado durante la espera

Mientras YUPY procesa las señales financieras disponibles, la ventana debe utilizar mensajes neutrales:

Estamos esperando la confirmación del pago.

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

Recibimos tu constancia y estamos verificando la operación.

La experiencia no debe acusar al comprador ni revelar detalles internos de consulta, frecuencia o proveedores financieros.

Actualización de la experiencia

YUPY mantiene actualizado el estado de la sesión utilizando sus mecanismos internos de verificación y conciliación.

Ventana de checkout
    → consulta o recibe el estado de YUPY

YUPY
    → procesa las señales financieras
    → ejecuta la conciliación
    → actualiza la sesión

Ventana de checkout
    → refleja el resultado

La empresa no necesita consultar directamente la cuenta bancaria.

Cuando se alcanza expires_at

La ventana deja de presentarse como una sesión activa, pero la operación permanece registrada.

Mensaje propuesto:

Esta sesión de pago venció.
No realices un nuevo pago desde esta pantalla.
Si ya pagaste, la verificación puede continuar.
Conserva tu código de transacción.

Estado conceptual:

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

Pago efectuado antes del vencimiento y detectado después

Puede ocurrir que el comprador pague dentro de la vigencia, pero que el movimiento sea procesado por YUPY después.

YUPY debe evaluar la hora financiera disponible y puede conciliar la operación aunque la ventana haya vencido.

Pago realizado después del vencimiento

Un QR fijo o una cuenta pueden seguir recibiendo dinero después del cierre visual de la sesión. Por ello, el pago tardío es un caso operativo crítico y no debe ignorarse.

YUPY debe:

1. detectar el movimiento;
2. intentar vincularlo con la transacción original;
3. marcarlo como pago tardío;
4. avisar a la empresa con la mayor inmediatez permitida por el canal configurado;
5. incorporarlo a la pantalla de pendientes;
6. incluirlo en los reportes periódicos acordados;
7. entregar la información necesaria para resolverlo;
8. conservar trazabilidad completa.

Estado conceptual:

late_detected

Resolución del pago tardío

La empresa decide, según su política comercial, si:

• acepta y regulariza la venta;
• contacta al comprador;
• solicita evidencia complementaria;
• rechaza la operación comercial;
• inicia un procedimiento de devolución.

El comprador puede:

• solicitar atención o devolución desde el canal habilitado;
• presentar su código de transacción o código de atención;
• contactar directamente a la empresa;
• enviar una captura o constancia de pago.

El formato exacto del código público de atención queda pendiente de definición. No debe exponerse el token de checkout ni una credencial interna.

Avisos, pendientes y reportes

Los mecanismos de comunicación se acuerdan con cada empresa.

Pueden incluir:

• alerta inmediata en consola;
• webhook;
• correo o mensajería configurada;
• pantalla de pagos tardíos y casos pendientes;
• reporte periódico;
• exportación;
• consulta por API.

La periodicidad de los reportes y los responsables de atención deben definirse durante la integración.

Reapertura y recarga

Reabrir o recargar la URL recupera el estado central y no crea una nueva orden.

Recargar la página
≠ crear otra sesión
≠ crear otra orden

La sesión puede mostrar:

• estado activo;
• pago conciliado;
• vencimiento;
• pago tardío;
• caso en revisión;
• token inválido o revocado.

Renovación

La renovación no debe ocurrir silenciosamente desde el navegador.

La política puede permitir:

• crear otra sesión para la misma orden;
• crear una nueva orden;
• renovar desde backend;
• regresar al proceso comercial.

La regla final se configura por empresa y caso de uso.

Cierre del componente

Cerrar o desmontar la ventana no cancela la orden, no detiene la conciliación y no impide detectar un pago posterior.

Eventos propuestos

checkout.expired
payment.detected
payment.reconciled
payment.late_detected
payment.review_required

Criterios de aceptación

1. La empresa puede configurar la vigencia por caso de uso.
2. Existe un valor general y un valor predeterminado.
3. YUPY devuelve expires_at efectivo.
4. El vencimiento de sesión se diferencia de la orden y del destino receptor.
5. Los mensajes al comprador son neutrales.
6. La recarga no crea otra orden.
7. El cierre visual no cancela la conciliación.
8. Los pagos tardíos se detectan y registran.
9. La empresa recibe avisos, pendientes y reportes.
10. El comprador puede reclamar con un código seguro y enviar constancia.