Reintentar el pago o detenerse: cómo evitar que un rechazo se convierta en un doble cobro

El botón más peligroso después de un timeout es «intentar de nuevo» cuando nadie sabe qué pasó con la primera operación. Pueden pulsarlo casi al mismo tiempo el cliente, el servidor y la cola en segundo plano. Una política de reintentos debe responder primero qué pasó con el pago original, luego verificar la siguiente acción permitida y solo después contar la venta recuperada.

La primera pregunta: ¿el rechazo está confirmado?

Distinga tres situaciones: la solicitud no pasó la validación de parámetros, el pago recibió un resultado negativo definido o la respuesta se perdió y el resultado es desconocido. En el último caso, un nuevo pago es especialmente peligroso. Primero verifique el estado de la operación original por el medio disponible y procese sus notificaciones. El texto para el usuario debe reflejar la incertidumbre, por ejemplo: «Estamos verificando el resultado del pago. Espere la actualización, por favor».

Stripe indica que una falla de red no prueba que la operación no se haya ejecutado. Para un reintento válido de la misma solicitud se usan la misma clave de idempotencia y los mismos parámetros dentro de la ventana establecida; un resultado indeterminado exige conciliación. Las reglas concretas dependen de la versión de la API. Fuente: Stripe, Advanced error handling.

Soft y hard solo sirven junto con el código

La división práctica entre rechazos temporales y definitivos ayuda a elegir la siguiente acción. Pero los términos soft decline y hard decline no sustituyen la documentación de cada método. Un motivo temporal puede desaparecer más tarde; otro rechazo exige corregir datos, la participación del cliente o dejar de intentar. Un motivo desconocido no puede considerarse temporal de forma automática solo porque se quiere recuperar la venta.

En la referencia de Stripe, la exigencia de autenticación adicional lleva a la acción correspondiente del cliente, una tarjeta vencida exige otra tarjeta y un rechazo genérico puede requerir que el cliente contacte a su emisor. Las recomendaciones varían según el código, así que una regla única de «reintentar cualquier rechazo» es incorrecta. Fuente: Stripe, Decline codes.

Ejemplo de una política pequeña y segura

Supongamos que el equipo atiende compras únicas con tarjeta y quiere limitar la automatización. Permite como máximo un intento automático adicional, solo para un motivo temporal que el proveedor permita de forma explícita y solo después del intervalo recomendado. Si el reintento no funciona, el proceso se detiene y muestra el siguiente paso disponible. El número «uno» ilustra aquí un límite interno conservador, no una regla de la red de pagos.

La política debe respetar al mismo tiempo las restricciones más estrictas del proveedor y de la red. Si el reintento automático está prohibido, el límite interno no lo autoriza. Si se requiere autenticación, esperar no la reemplaza. Si el cliente canceló la acción o se revocó la autorización de cobro, el proceso en segundo plano no debe seguir con el escenario anterior.

Imaginemos 100 pedidos fallidos. En 60 el resultado todavía es desconocido, en 25 figura un rechazo definitivo y 15 admiten reintento según las reglas del proveedor. No se pueden enviar otros 100 cobros. Primero se resuelven las 60 operaciones inciertas; a los 25 se les propone la acción correcta del cliente, y solo el grupo restante se evalúa para un reintento limitado. Esta segmentación evita mezclar la recuperación técnica con una nueva decisión de pago.

Dos contadores en lugar de un solo límite

Separe la entrega técnica de una solicitud de un nuevo intento de autorización. En el log conviene tener dos contadores: cuántas veces se envió la misma acción para obtener una respuesta confiable y cuántos intentos de pago independientes tuvo el pedido. De lo contrario, tres envíos de red pueden confundirse con tres cobros nuevos o, al revés, los intentos nuevos pueden ocultarse bajo la palabra genérica «retry».

Para cada siguiente acción permitida, guarde el fundamento: la respuesta concreta, la regla aplicada, la hora y el estado verificado del pedido. Esto permite explicar la decisión después de un incidente. Un registro de «reintento autorizado automáticamente» no muestra si esa autorización aplicaba justo a esta operación.

Al restablecerse la conexión, verifique algo más: la cola acumulada no debe ejecutar a la vez acciones que ya no hacen falta. Antes de lanzar cada intento diferido, vuelva a leer el estado del pedido y la autorización vigente. Si durante la falla el cliente pagó por otro medio, la tarea antigua debe terminar sin un nuevo cobro.

Dónde poner la protección contra duplicados

• Guarde el estado del pedido, el identificador de la operación, el número de intentos y la hora permitida para la siguiente acción.
• Coordine los reintentos de la interfaz, el servidor, la cola y el proveedor mediante un único responsable del proceso.
• Antes de reintentar, verifique que el pedido no esté pagado, cancelado ni en procesamiento.
• No cree una clave nueva solo para esquivar el resultado incierto de la solicitud anterior.
• Detenga la automatización ante una prohibición, al alcanzar el límite o cuando haga falta la participación del cliente.

Incluso el éxito a nivel de transporte requiere verificar el resultado de negocio. Adyen explica que un HTTP 200 puede acompañar un rechazo de autorización; el resultado lo describen los campos de pago de la respuesta. Por eso el código HTTP no puede ser la única señal de que un pedido está pagado. Fuente: Adyen, Refusal reasons.

Evalúe el costo de la recuperación en el grupo adecuado

Volvamos a los 15 pedidos que en el ejemplo admiten reintento. Supongamos que, con un intento adicional cada uno, se recuperaron seis. La tasa de éxito de ese paso es de 6 / 15 = 40%, y cada pedido recuperado costó 15 / 6 = 2,5 intentos adicionales. Son indicadores de ese grupo apto concreto, no un porcentaje general de recuperación de los cien casos originales.

Compare el resultado con la calidad del cierre. ¿Hubo algún cobro duplicado, pedido cancelado, entrega de producto de más o mensaje incorrecto al cliente? Un pedido que técnicamente se volvió exitoso, pero que exigió un reembolso por duplicidad, no puede contarse sin reservas como un beneficio neto de la política.

El procedimiento operativo necesita un freno de emergencia con responsable: quién puede detener los reintentos automáticos, qué señal lo activa y cómo se procesa la cola después de la detención. Prevea por separado el regreso a la operación normal con una verificación de los estados acumulados. Simplemente reactivar la cola anterior después de la falla puede volver a lanzar solicitudes cuyo sentido ya cambió.

Qué decirle al cliente después de la detención

El equipo de soporte necesita instrucciones claras que no revelen las señales antifraude internas. Ofrezca solo las acciones permitidas para el motivo concreto: completar la autenticación, corregir los datos mediante un formulario seguro, contactar al banco o elegir un medio de pago válido. Este esquema se refiere a ejemplos con tarjeta; para transferencias bancarias y otros métodos, use sus propios estados y procedimientos. Los controles de seguridad y las restricciones de los participantes deben mantenerse en cada paso.