Caída de un PSP: cómo pasar al respaldo y volver sin duplicados

El PSP principal vuelve a responder y la persona de guardia le devuelve el tráfico. Un minuto después, el enrutamiento de pagos automático activa de nuevo el respaldo. Mientras el equipo averigua quién controla la ruta, parte de los pagos anteriores sigue con resultado desconocido. Es un escenario hipotético para un simulacro: el failover debe cubrir los intentos nuevos, las operaciones sin terminar y el regreso seguro a la ruta principal.

Analice el cambio con un ejemplo hipotético

La plataforma tiene conectadas de antemano las rutas A y B para un mismo método de pago autorizado. A las 14:05, los timeouts en A aumentan. El equipo limita las nuevas solicitudes hacia A y comprueba si B es apta. El pedido R-902 ya se envió por A, pero no hay respuesta: queda en conciliación. El pedido R-903 todavía no se ha enviado: después de los controles habituales puede dirigirse por B si sus parámetros son compatibles con esa ruta.

En el caso de R-902 no basta con copiar la clave de idempotencia en B y suponer que la protección es compartida. En la arquitectura propuesta existe un único registro interno de intentos, y la autorización para una nueva acción financiera solo se concede cuando se conoce el resultado de la anterior o mediante un proceso seguro previsto por el proveedor. Soporte ve el motivo de la espera y no invita al cliente a repetir el pago sin control.

Primero clasifique el problema

La indisponibilidad técnica, un error en la solicitud, la exigencia de autenticación adicional y una restricción de la operación requieren decisiones distintas. El código HTTP por sí solo no siempre describe el resultado de negocio. Por ejemplo, Stripe recomienda considerar indeterminado el resultado de una operación con respuesta 500 y averiguar qué pasó con la solicitud original antes de intentar con una clave nueva. Una respuesta con error no prueba que no haya habido efecto financiero.

Conviene dividir las acciones del operador en tres grupos. Una operación nueva, aún no enviada, puede evaluarse para la ruta alternativa autorizada. Una ya enviada con resultado desconocido debe aislarse y conciliarse. Un rechazo confirmado debe analizarse según su motivo y las reglas del método. Es mejor mostrar estos grupos por separado en el panel, para que la guardia no intente resolver con un solo botón tareas de naturaleza muy distinta.

La ruta de respaldo debe estar lista con antelación

Antes del incidente, elabore una ficha de cada ruta: persona jurídica, cuenta conectada, tipos de operación permitidos, métodos, monedas, geografía, límites de monto, procedimiento de reembolsos y contactos de soporte. Aclare qué consentimientos del cliente y qué controles son obligatorios. Si el respaldo aún no está conectado o sus condiciones no se ajustan a una operación concreta, considérelo no disponible.

Revise con especial atención las diferencias entre el pago de un producto, una transferencia bancaria y un pago a un participante de una plataforma P2P. Que la interfaz de usuario se parezca no hace que estas acciones sean intercambiables. No cambie el propósito de la operación, el beneficiario ni los datos del comercio para que la ruta funcione. Si no hay una opción adecuada y autorizada, una pausa honesta es más segura que la improvisación.

La referencia de motivos de rechazo de Adyen distingue entre la indisponibilidad del emisor, los errores de autenticación, la sospecha de fraude y la operación no permitida. Es un ejemplo concreto de por qué una regla única de «reenviar cualquier rechazo» es demasiado burda. El respaldo no debe eludir los requisitos AML/KYC, las restricciones por sanciones, el antifraude ni la decisión de que una operación no es admisible. Derive los motivos dudosos al especialista responsable.

Limite la carga durante la recuperación

El cambio de ruta no elimina los límites del canal de respaldo. Indique la proporción máxima del flujo nuevo, la cola admisible y la condición de detención. Elija los valores según las restricciones contractuales y los resultados de pruebas de capacidad acordadas. Primero traslade un volumen limitado de operaciones nuevas autorizadas, observe los resultados y solo después aumente la carga.

AWS explica cómo los reintentos agravan la sobrecarga y por qué son útiles los intervalos crecientes con una pequeña variación aleatoria, conocida como jitter. Para un servicio de pagos, es un argumento en contra de reintentar toda la cola de forma masiva y sincronizada. Defina un único lugar que controle los reintentos y verifique que los SDK no agreguen sus propios reintentos invisibles.

El regreso a la ruta principal también requiere control. Registre quién autoriza el regreso, qué señales de recuperación se necesitan y cómo detener un nuevo cambio en sentido contrario. Averigüe qué dependencias comparten A y B: dos contratos distintos no prueban por sí solos que la infraestructura sea independiente. Contraste la disponibilidad con las métricas internas, y no solo con el indicador verde de la página de estado externa.

El costo del respaldo aparece después del cambio

En la revisión propuesta, el respaldo se evalúa a lo largo de todo el ciclo de vida. ¿Quién procesará el reembolso de una operación antigua? ¿Cómo encontrará soporte la ruta si el comprador solo conoce el número de pedido? ¿En qué conciliación entrará un pago que llegó con retraso? Si estas respuestas dependen de la memoria de un solo ingeniero, el segundo PSP agrega una integración, pero todavía no aporta una resiliencia controlada.

Guarde desde el principio, para cada intento, la ruta, la cuenta y la versión de las reglas de selección. Un mismo pedido puede tener varios intentos, pero sus efectos financieros deben seguir siendo distinguibles. En el reporte, separe la ruta inicial de la ruta del pago confirmado en definitiva. De lo contrario, después de la caída el equipo comparará grupos de compradores distintos y atribuirá por error la mejora a la calidad del proveedor.

Volver a la ruta principal también es un despliegue

Tras la recuperación, no abra todo el flujo solo porque una solicitud de control funcionó. Defina una verificación limitada con operaciones nuevas autorizadas, evalúe la latencia y las confirmaciones, y luego amplíe el flujo según condiciones elegidas de antemano. Las proporciones y los tiempos concretos dependen de la carga: no existen «cinco minutos sin errores» universales para todos los servicios.

Acuerde por separado qué ocurre con el conmutador automático mientras las personas realizan la recuperación. Dos mecanismos que cambian la ruta al mismo tiempo pueden provocar oscilaciones y volver ilegible el experimento. El registro de decisiones debe mostrar quién controla la ruta en cada momento. El simulacro es exitoso cuando el equipo sabe pasar al respaldo, volver y cerrar la lista pendiente de pagos inciertos.

En el informe del simulacro deje tres cifras: las operaciones nuevas que pasaron por el respaldo, las operaciones anteriores con resultado sin establecer y los efectos financieros duplicados confirmados. Incluso con una conversión alta, la segunda cifra necesita responsables, y una tercera distinta de cero exige analizar la causa.