¿Cuándo es peligroso reintentar un pago tras un tiempo de espera agotado?

El tiempo de espera solo describe lo que sabe el cliente

Un tiempo de espera agotado en la red significa que quien hizo la llamada no recibió una respuesta concluyente a tiempo. No demuestra que el sistema remoto rechazó, revirtió o nunca recibió la solicitud. En pagos, la autorización, la captura o el reembolso pueden haber tenido efecto financiero aunque el cliente vea una excepción.

Después de un tiempo de espera agotado ambiguo, el estado más seguro no es failed, sino unknown. Convertir unknown en failed mezcla dos realidades distintas y aumenta el riesgo de una ejecución duplicada.

La idempotencia cambia la decisión de reintentar

Un reintento es mucho más seguro cuando el proveedor ofrece idempotencia para esa operación y se puede reutilizar la misma clave. La identidad debe representar la acción de negocio, no el intento HTTP. Crear una clave nueva en cada reintento permite que el proveedor interprete cada llamada como una operación distinta.

Los proveedores difieren en las operaciones admitidas, la retención de claves, la concurrencia y la respuesta a una repetición. Estas diferencias deben estar en la lógica de recuperación de pagos y no ocultarse en un middleware genérico.

Recupera el estado antes de crear una segunda acción financiera

Si el resultado es incierto, primero intenta reconciliar la intención original con el estado del proveedor: consulta por merchant reference, consume eventos o usa un mapping durable entre el attempt y el recurso del proveedor. Solo si no puede recuperarse el estado debe evaluarse otra ejecución.

Por eso, el reintento de pago es una decisión de orquestación, no solo de confiabilidad de HTTP. Depende del estado del negocio, del proveedor, del tiempo transcurrido y de la consecuencia financiera de repetir.

Regla práctica

Reintenta automáticamente solo si la operación es segura según el contrato de idempotencia del proveedor o si el sistema ha demostrado que la acción original no se completó. En cualquier otro caso, mueve el pago a un estado de recuperación explícito y resuelve la incertidumbre antes de continuar.

Separa el fallo de transporte del fallo del estado de negocio

Una máquina de estados de pago fiable necesita al menos tres conceptos distintos: el estado de la solicitud del cliente, el estado de la operación en el proveedor y el estado de negocio que tu sistema decide exponer. En el flujo ideal suelen coincidir y por eso resulta tentador fusionarlos. El problema aparece cuando falla la red: una solicitud puede fallar localmente mientras la operación remota termina con éxito, o el proveedor puede aceptar el trabajo y publicar el resultado de forma asíncrona después de que la llamada original ya haya agotado el tiempo de espera.

La consecuencia práctica es que un error de transporte no debería activar automáticamente transiciones de negocio irreversibles. Un intento de pago que termina por agotarse el tiempo de espera puede necesitar un estado como pendiente de verificación, desconocido o requiere recuperación. Ese estado permite detener la progresión automática mientras se reúnen pruebas y evita que los servicios posteriores interpreten la falta de respuesta como prueba de que no se movió dinero.

Construye una jerarquía de recuperación según el proveedor

La recuperación debe comenzar por la fuente de verdad más sólida disponible. Si el proveedor permite buscar por clave de idempotencia, referencia del comerciante, intención de pago o ID de transacción del proveedor, úsala antes de crear otro intento. Si esperas un evento durable del proveedor, correlaciónalo con el intento original y espera dentro de una ventana de recuperación limitada. Si no existe ninguno de esos mecanismos, es mejor escalar a una conciliación diferida o manual que adivinar.

Esa recuperación específica de cada proveedor explica por qué las bibliotecas genéricas de reintentos HTTP no bastan para las operaciones financieras. Repetir una lectura no equivale a repetir una autorización; repetir una autorización no equivale a repetir una captura; repetir un reembolso puede ser aún más peligroso porque la transacción visible para el cliente ya puede haberse completado. La política de recuperación debe estar cerca de la semántica de los pagos, no solo de la semántica de la red.

Diseña la observabilidad para gestionar la incertidumbre

Los paneles operativos deberían mostrar los pagos inciertos como un grupo propio. Mide cuántos intentos entran en un estado ambiguo, qué proveedores los generan, cuánto tarda la recuperación y cuántos se resuelven mediante consulta, webhook, conciliación o intervención manual. Si los estados desconocidos se ocultan dentro de una tasa de errores genérica, el equipo optimizará la métrica equivocada y puede responder aumentando los reintentos, precisamente lo que eleva el riesgo de duplicados.

Las alertas también deben distinguir el aumento de resultados ambiguos del aumento de rechazos explícitos. Un proveedor con más rechazos del emisor tiene un problema distinto al de uno que agota el tiempo de espera después de recibir la solicitud. El primero afecta principalmente la conversión; el segundo añade incertidumbre sobre la conversión y riesgo para la integridad financiera. Distintas clases de fallos necesitan distintos procedimientos de respuesta.

Criterios antes de un reintento automático

Antes de reintentar, responde cuatro preguntas: ¿se sabe que la operación original no terminó? ¿El proveedor garantiza un comportamiento idempotente para esa operación y esa clave? ¿Se puede consultar o conciliar el intento original? ¿Qué impacto financiero tendría que ambos intentos terminaran? Si las dos primeras respuestas son inciertas y el impacto de un duplicado es importante, el reintento automático debe detenerse.

Este enfoque prioriza deliberadamente la corrección financiera por encima de la finalización inmediata. No significa aceptar una mala experiencia para el cliente. Significa hacer explícita la recuperación: mostrar que está pendiente cuando corresponda, continuar la verificación de forma asíncrona y comunicar al cliente un estado solo cuando haya pruebas. Unos segundos de incertidumbre honesta suelen costar menos que un cargo duplicado y el soporte, reembolso, disputa y pérdida de confianza que le siguen.