Revisado el 7 de noviembre de 2026.
Tener más de un PSP parece resolver un problema evidente: si un proveedor falla, basta con enviar el pago a otro. En la práctica, este es precisamente uno de los puntos en los que una arquitectura aparentemente resiliente puede introducir nuevos riesgos.
El motivo es sencillo. En pagos, la ausencia de respuesta no significa necesariamente que no se haya procesado la operación. El proveedor puede haber autorizado un intento aunque la aplicación haya recibido un timeout.
Por tanto, el failover no consiste únicamente en cambiar de ruta. Consiste en decidir cuándo un nuevo intento es seguro, necesario y compatible con el estado real del pago.
¿Qué es el failover en pagos?
El failover es el mecanismo que permite utilizar un camino alternativo cuando la ruta principal no puede continuar en determinadas condiciones.
En una arquitectura multi-PSP, esto puede significar dirigir un nuevo intento a otro proveedor tras un fallo técnico que cumpla los criterios establecidos.
Esos criterios son fundamentales. No todo fallo, rechazo o timeout debería provocar un reintento automático.
¿Por qué no basta con la redundancia?
Integrar dos proveedores crea caminos alternativos, pero no define cómo utilizarlos. Si la aplicación carece de una política de estados y fallos, el segundo camino puede limitarse a duplicar la complejidad.
Una arquitectura resiliente debe saber qué ocurrió en el primer intento, si el resultado es concluyente, si existe riesgo de procesamiento pendiente y qué acciones están permitidas a continuación.
Sin esas respuestas, cambiar de proveedor puede ser más peligroso que esperar y conciliar el estado.
Un fallo técnico y un rechazo son cosas distintas
| Fallo técnico | Rechazo | Timeout | |
|---|---|---|---|
| Qué se sabe | El camino no se completó | El emisor o el proveedor respondió que no | No llegó respuesta a tiempo |
| Otro intento | Puede tener sentido por otro camino | No siempre debe reenviarse | Solo después de consultar el estado |
| Riesgo | Reintentar sin idempotencia | Insistir en un rechazo definitivo | Cobrar de nuevo lo que ya se procesó |
Un nuevo intento no sustituye la autenticación de EMV 3-D Secure (se abre en una pestaña nueva ↗) ni debería volver a exponer el PAN si la operación ya usa tokenización de pago de EMVCo (se abre en una pestaña nueva ↗). PCI DSS (se abre en una pestaña nueva ↗) sigue aplicando al entorno que trata los datos de cuenta en ese reenvío.
Un fallo técnico puede indicar indisponibilidad, un error de comunicación u otro problema de ejecución. Un rechazo puede representar una decisión válida del ecosistema de pagos.
Tratar ambas situaciones de la misma forma es un error conceptual. Cambiar de PSP no debería ser una respuesta automática a cualquier resultado negativo.
La clasificación del resultado debe formar parte de la política de failover.
El caso más delicado: el timeout
Imagina una autorización enviada al PSP A. El PSP recibe y procesa la solicitud, pero la respuesta se pierde. La aplicación observa un timeout.
Si el sistema interpreta que el timeout significa un fallo y envía inmediatamente el mismo cobro al PSP B, puede producirse una segunda autorización para la misma intención comercial.
Este escenario muestra por qué la resiliencia depende del estado. Antes de repetir, es necesario comprender qué puede haber ocurrido en el intento anterior.
La idempotencia ayuda, pero no lo resuelve todo
La idempotencia es un mecanismo esencial para reducir los efectos duplicados cuando una misma operación se repite dentro de un contexto compatible.
Sin embargo, una clave de idempotencia en un proveedor no necesariamente existe ni tiene el mismo significado en otro. Al cambiar de PSP, la infraestructura entra en un nuevo dominio de ejecución.
Por eso, la idempotencia debe formar parte de una estrategia más amplia que incluya la identidad del pago, la identidad de los intentos, las consultas de estado y la conciliación.
Hay que separar el pago del intento
El pago representa la intención comercial. Un intento representa una ejecución técnica de esa intención en una ruta concreta.
Esta distinción permite registrar un intento como pendiente, fallo técnico, rechazado o completado sin perder la identidad del pago original.
Cuando existe failover, este modelo resulta aún más importante, porque distintos intentos pueden coexistir en el historial de una misma intención.
¿Qué es el fallback?
El fallback consiste en utilizar una alternativa cuando el camino principal no puede continuar. En pagos, el término suele aparecer junto a failover.
Las definiciones pueden variar entre plataformas. Desde el punto de vista arquitectónico, lo esencial es que exista una política para elegir otro camino en condiciones específicas.
Esa política debe indicar qué errores permiten un fallback, cuáles exigen consultar el estado y cuáles ponen fin al flujo.
¿Qué es el cascading?
El cascading describe una secuencia controlada de intentos por distintas rutas. La idea puede resultar atractiva porque aumenta el número de caminos disponibles.
Pero cada intento adicional incrementa la necesidad de control. Hay que definir límites, condiciones, estados y efectos sobre la experiencia, el riesgo y la operación.
El cascading no debería consistir en probar proveedores sucesivamente hasta que alguno acepte. Cada nuevo intento debe responder a un motivo técnico y a una política.
¿Cómo clasificar los errores?
Una arquitectura multi-PSP debe traducir respuestas distintas a categorías operativas comprensibles.
Dos proveedores pueden utilizar códigos diferentes para situaciones similares. Sin normalización, la política de failover queda acoplada a los detalles de cada API.
Una capa común puede ayudar a distinguir resultados concluyentes, errores técnicos, estados pendientes y situaciones que exigen una investigación adicional.
No todos los rechazos deberían reintentarse
Un rechazo puede deberse a una decisión del emisor o a condiciones que no cambian simplemente porque la transacción pase por otro procesador.
Además de resultar potencialmente inútil, un reintento indiscriminado puede empeorar la experiencia y dificultar el análisis operativo.
Una política madura empieza preguntándose qué significa el resultado, no si hay otra integración disponible.
La consulta de estado forma parte de la resiliencia
Cuando el resultado es incierto, consultar el estado en el proveedor puede ser más seguro que crear otro intento de inmediato.
El diseño concreto depende de las API disponibles y del flujo utilizado. Los webhooks también pueden aportar una actualización asíncrona después de que haya terminado la solicitud original.
Esto significa que la arquitectura debe convivir con estados intermedios y con la posibilidad de recibir información fuera del orden esperado.
El tratamiento de webhooks debe ser idempotente
Los eventos asíncronos pueden entregarse más de una vez. También pueden llegar después de una consulta de estado o de otra actualización interna.
El consumidor debe reconocer la identidad del evento o de la operación y aplicar las transiciones de estado de forma segura.
El failover no puede diseñarse únicamente para el camino síncrono de la API. El ciclo de vida completo del pago incluye mensajes y conciliaciones posteriores.
La conciliación es la última línea de coherencia
Incluso una arquitectura bien diseñada necesita mecanismos para comparar el estado interno con los registros de los proveedores.
La conciliación ayuda a detectar diferencias, pagos que permanecen en un estado incierto y eventos que no se procesaron como se esperaba.
Cuantas más rutas existan, más importante será disponer de una visión consolidada de la intención comercial y de los intentos técnicos.
Circuit breaker y protección de la ruta
Cuando una ruta falla repetidamente, seguir enviándole tráfico puede agravar el incidente. Un mecanismo de circuit breaker puede interrumpir temporalmente los nuevos intentos en esa ruta según unos criterios definidos.
Esto es distinto de marcar un proveedor simplemente como conectado o desconectado. La degradación puede ser parcial y afectar solo a determinadas operaciones.
La política debe equilibrar una reacción rápida con el riesgo de retirar una ruta por ruido temporal.
Un health check no cuenta toda la historia
Un endpoint de salud puede responder correctamente mientras las transacciones reales sufren problemas. Del mismo modo, un fallo aislado no implica necesariamente una indisponibilidad general.
Por ello, la disponibilidad operativa puede combinar distintas señales, como errores técnicos, latencia y resultados transaccionales.
El diseño debe evitar decisiones precipitadas basadas en un único indicador.
¿Cómo definir una política de reintentos?
Una política de reintentos debería definir las condiciones, el intervalo, el número máximo de intentos y el comportamiento ante estados inciertos.
Reintentar por la misma ruta puede ser adecuado para algunos fallos transitorios. En otros casos, puede considerarse una ruta alternativa. Y, en determinadas situaciones, lo correcto es no repetir.
Lo importante es que la política sea explícita, comprobable y observable.
El backoff evita tormentas de reintentos
Cuando muchos pagos fallan a la vez, los reintentos inmediatos pueden aumentar la carga sobre un servicio que ya está degradado.
Las estrategias de espera progresiva pueden reducir este efecto en operaciones en las que resulte apropiado repetir.
En pagos, sin embargo, el intervalo no sustituye la necesidad de saber si la operación puede repetirse de forma segura.
Failover y experiencia de checkout
Cada nuevo intento añade tiempo. Una arquitectura puede ser técnicamente resiliente y aun así ofrecer una mala experiencia si el usuario espera indefinidamente.
Por ello, las políticas de timeout y fallback deben tener en cuenta los límites de latencia percibida por el cliente.
A veces, cerrar el flujo con un estado claro es mejor que prolongar una cadena de intentos inciertos.
¿Cómo medir el failover?
Entre las métricas útiles están los fallos técnicos por ruta, el número de fallbacks, el tiempo adicional introducido, los intentos por pago y los resultados de las transacciones que pueden recuperarse.
La tasa de recuperación debe interpretarse en su contexto. Un aumento puede indicar que el mecanismo está ayudando, pero también revelar una degradación frecuente de la ruta principal.
Las métricas de failover deben analizarse junto con la salud de los proveedores y la experiencia de checkout.
Probar los fallos antes de que ocurran
Una política de failover que nunca se ha puesto a prueba puede dar sorpresas precisamente durante un incidente.
Los entornos de prueba, las simulaciones y los mecanismos controlados de inyección de fallos ayudan a verificar las transiciones de estado y el comportamiento de las reglas.
El objetivo es descubrir antes de llegar a producción si un timeout genera una duplicidad, si un webhook tardío sobrescribe un estado o si una ruta alternativa está realmente disponible.
¿Cuándo tiene sentido el failover automático?
Tiene más sentido cuando la operación dispone de rutas verdaderamente alternativas, puede clasificar los fallos con confianza y mantiene un control coherente del estado.
Si no se dan esas condiciones, automatizar el cambio puede crear una falsa sensación de resiliencia.
En algunos escenarios, el primer paso consiste en mejorar la observabilidad y la conciliación antes de automatizar nuevos intentos.
¿Qué tiene que ver AZPay con el failover?
El failover forma parte de una discusión más amplia sobre cómo construir una infraestructura de pagos desacoplada, observable y preparada para múltiples caminos.
Las técnicas presentadas aquí son principios arquitectónicos. No deben interpretarse como una afirmación de que todos estos mecanismos son funcionalidades concretas disponibles actualmente en AZPay.
La implementación concreta depende de las capacidades de la plataforma, de los proveedores conectados y de las reglas definidas para cada operación.
Una redundancia segura exige controlar el estado
El segundo PSP no es la parte más difícil del failover. Lo más difícil es saber cuándo utilizarlo.
Para ello, la infraestructura debe distinguir la intención del intento, el fallo del rechazo, el timeout del resultado concluyente y la alternativa de la repetición indiscriminada.
La resiliencia en pagos no significa intentarlo más veces. Significa seguir operando sin perder el control sobre lo que ha ocurrido con el dinero.