Un timeout de pasarela es ambiguo: el cliente puede ver un error cuando el proveedor ya ha aceptado el pago. El diseño seguro asume que la respuesta del navegador puede perderse y protege creación/cobro con identificadores estables y conciliación.
No pidas reintentar inmediatamente
Comprueba primero si existe pedido o intento de pago. Un reintento ciego puede crear un segundo cargo antes de que llegue el callback.
Usa idempotencia cuando exista
Liga la petición de pago a una clave estable de checkout/pedido. Repetir la misma operación de red debería recuperar el mismo pago.
Conserva el pedido antes de salir
Crea un estado recuperable con datos suficientes para reconciliar la respuesta aunque el navegador agote el tiempo.
Acepta webhooks tardíos
Un evento de éxito posterior debe mover el pedido existente a pagado una sola vez. Stock, emails y fulfilment también deben protegerse contra duplicados.
Concilia los casos ambiguos
Crea una vista operativa para “cliente vio error / estado del proveedor desconocido” y compara ID, importe y clave antes de capturar o devolver manualmente.
Compara con pedidos o cobros duplicados y usa el rastreo de pagos para reconstruir la transacción.
Diseña el estado de recuperación para el cliente
Tras un timeout ambiguo, el mensaje seguro no es “pago fallido” ni “pago correcto” hasta que termine la conciliación. Mantén el pedido recuperable, muestra que se está comprobando la confirmación y evita reenvíos rápidos. Soporte debe poder localizar el caso por pedido y referencia del proveedor.