Desarrollador 7 min de lectura

Gestionar timeouts y reintentos en la Verification of Payee

Toda integración de Verification of Payee acaba encontrando un banco respondedor lento o inalcanzable. La diferencia entre una integración robusta y una frágil es cómo gestiona el timeout.

Por Verification of Payee EU · con tecnología de RoxPay

Gestionar timeouts y reintentos en la Verification of Payee

Claves

  • Fija un timeout síncrono sensato y trata el exceso como no disponible, no como un fallo duro.
  • Reintenta con backoff, pero solo con solicitudes idempotentes indexadas por un identificador estable.
  • Define una política de fallback clara para el pagador cuando no se puede obtener un resultado a tiempo.

La Verification of Payee depende de una respuesta remota del banco del beneficiario. Cuando ese banco es lento, está sobrecargado o temporalmente inalcanzable, tu integración tiene que decidir qué hacer — y esa decisión afecta tanto a la experiencia del pagador como a tu posición de cumplimiento. Los peores resultados son un checkout congelado o una verificación que se cobra o cuenta dos veces en silencio.

El resultado no disponible es una característica

El esquema define un resultado no disponible precisamente para que no tengas que inventar la semántica de errores. Cuando el lado respondedor no puede responder a tiempo, trátalo como un resultado de primera clase en lugar de una excepción.

  • Fija un timeout síncrono alineado con tu presupuesto de checkout (a menudo un par de segundos).
  • Ante un exceso, muestra al pagador un estado neutral no disponible en lugar de un error alarmante.
  • Decide, por política, si el pagador puede continuar, debe esperar o debe enrutarse para revisión.

Reintentar de forma segura

Los reintentos ayudan con los fallos transitorios pero causan daño si no son idempotentes. Un reintento nunca debe crear una segunda verificación lógica o un segundo cargo.

  1. 1 Adjunta un identificador de solicitud estable a cada intento de verificación.
  2. 2 Reintenta los errores de red transitorios con backoff exponencial y un tope pequeño.
  3. 3 Nunca reintentes un resultado definitivo (coincidencia, coincidencia parcial, sin coincidencia) — reintenta solo los verdaderos fallos de transporte.
  4. 4 Reconcilia cualquier respuesta tardía con el identificador de solicitud para que se registre una sola vez.

Presupuesta la espera, luego decide

Elige un presupuesto síncrono que puedas defender ante tus equipos de UX y cumplimiento. Pasado ese presupuesto, repliega deliberadamente — muestra pendiente o no disponible — en lugar de dejar la solicitud colgada y que el pagador abandone.

RoxPay devuelve los resultados estandarizados incluido no disponible, soporta reintentos idempotentes por ID de solicitud, y se repliega a un webhook para las respuestas tardías — para que tu política de timeout siga siendo simple.

FAQ

Preguntas frecuentes

Alinéalo con tu experiencia de checkout — a menudo un par de segundos para uso síncrono. Más allá, repliega a un estado pendiente o no disponible en lugar de bloquear al pagador indefinidamente.

Solo para fallos de transporte, y solo con solicitudes idempotentes indexadas por un identificador estable. Nunca reintentes un resultado de coincidencia definitivo; es un resultado, no un error.

Trátalo como un resultado definido y aplica tu política: permitir al pagador continuar con cautela, esperar una respuesta asíncrona o enrutar el pago a revisión manual según el riesgo.

Haz la VoP fiable en producción

Habla con RoxPay sobre timeouts, reintentos idempotentes y fallbacks de webhook en el esquema SEPA VoP.