Un fallback se puede traducir como un plan de respaldo o solución alternativa que se activa cuando la opción principal falla o no está disponible. Vamos a ver qué significa utilizar fallback en los pagos online y cómo permite recuperar pagos que sin fallback estarían perdidos.

Recordatorio de cómo funciona un pago online

Cuando una web vende online con tarjeta, necesita conectarse a un PSP o procesador de tarjetas. En el momento del pago, los datos de la tarjeta del comprador recorren una cadena de intermediarios: el procesador, las redes de tarjetas y el banco emisor. Cualquier eslabón de ese viaje puede fallar y devolver un rechazo.

Si ocurre un rechazo, por ejemplo que el procesador da error por problemas técnicos, el pago se rechaza y el vendedor pierde la venta.

No todos los rechazos son iguales:

• Los soft declines son temporales. Por ejemplo, un saldo insuficiente en ese momento, un problema técnico puntual del banco emisor o una autenticación incompleta. Representan entre el 80% y el 90% de todos los rechazos, y aquí reintentar por otro procesador tiene sentido. 

• Los hard declines son definitivos: tarjeta robada, cuenta cerrada, fraude confirmado. Reintentar no solo no recupera el pago sino que además puedes acumular penalizaciones ante los esquemas de tarjetas. 

Qué es un “fallback”

Un fallback es el mecanismo por el que, cuando una transacción falla con un procesador, el sistema la redirige automáticamente a otro procesador alternativo para intentar completarla.

El objetivo es recuperar pagos que de otra forma se perderían. Es un proceso técnico y ocurre en milisegundos por lo que el comprador no tiene que hacer nada y no nota el proceso. 

El rol del fallback dentro de la orquestación de pagos

La orquestación de pagos permite decidir por dónde pasa cada pago según reglas y variables previamente definidas. Los orquestadores de pagos funcionan como una capa por encima de los PSP, procesadores y métodos de pago. De esta forma el negocio tiene una capa de control sobre su sistema de pagos.

Tiene varias ventajas:

• Mejorar la conversión 

• Optimizar costes

• Escalar fácilmente a otros mercados

• Recuperar pagos fallidos con reglas de fallbacks

El fallback vive dentro de esa lógica. No es una capa aparte: es una de las reglas que el orquestador ejecuta cuando un procesador falla.  

Retos a la hora de implementar fallbacks

Implementar un fallback tiene tres retos que vale la pena conocer antes de empezar.

El primero: la infraestructura. Para que funcione, el negocio necesita estar conectado con más de un procesador. Sin alternativa, no hay a dónde redirigir el pago. Construir esa infraestructura por cuenta propia implica integraciones, contratos y mantenimiento técnico continuo.

El segundo: la experiencia del comprador. Sin 3DS agnóstico, cada vez que el pago se reintenta por un procesador distinto el usuario tiene que autenticarse de nuevo. Lo que era una redirección transparente se convierte en fricción visible.

El tercero: la lógica. Definir en qué casos se activa el fallback, y por qué procesador, no es trivial. Si la lógica no distingue entre un soft decline recuperable y un hard decline definitivo, el fallback añade reintentos que no recuperan nada y pueden deteriorar la relación con los procesadores.

Por eso tiene sentido apoyarse en un orquestador de pagos que ya tenga esta infraestructura montada y la lógica de fallback integrada.

Qué tener en cuenta a la hora de elegir un proveedor de fallback

No todos los proveedores permiten gestionar la lógica de fallback con el mismo nivel de autonomía.

En algunos, para crear o modificar una regla de fallback hay que contactar con el proveedor. El equipo de pagos no puede hacer ese cambio solo: depende de que el proveedor lo implemente. Eso ralentiza cualquier ajuste.

En otros, la lógica se gestiona por API. La decisión pasa al equipo técnico: el Head of Payments o el equipo financiero no pueden cambiar nada en la operativa sin implicar a desarrollo.

Vale la pena preguntar si el proveedor permite gestionar los fallbacks directamente desde el panel, sin depender de él ni del equipo técnico propio, y si esa lógica puede ajustarse cuando la operativa lo requiere.

Cómo se crea un fallback en Zru

En Zru, la lógica de fallback se configura directamente desde el módulo de Orquestación del panel. Sin necesidad de contactar con el equipo de Zru para crearlo ni de que el equipo técnico del comercio toque código.

Crear o modificar una regla lleva minutos. Si un procesador empieza a dar problemas o hay que ajustar el comportamiento para ciertos mercados, el cambio se hace en el momento.

Para el equipo de pagos, esto se traduce en cuatro ventajas concretas.

• Independencia del proveedor: sin esperar a que Zru implemente ningún cambio.

• Independencia del equipo técnico: el equipo de pagos gestiona la lógica directamente desde el panel.

• Reactividad operativa: los ajustes se hacen cuando la operativa lo requiere.

• Reglas combinadas: el fallback puede cruzarse con otras variables de la orquestación (tipo de tarjeta, país, importe) e integrarse con la lógica de fraude.

En el editor de orquestación de Zru, cada procesador que añades puede tener uno o varios procesadores de respaldo. Si el principal falla, el pago pasa al siguiente de la cadena de forma automática. Se define una vez y funciona solo.

Si quieres afinar cuándo se activa, el bloque de condiciones permite cruzarlo con variables del pago: el importe, el tipo de tarjeta, el país de emisión o el score de fraude, entre otras. El fallback no tiene que ser igual para todos los pagos.

Si quieres ver un ejemplo concreto de cómo se configura la lógica de fallbacks en Zru, aquí lo explicamos con detalle.