# Fiabilidad de los pagos

La pasarela de pagos de comercio electrónico de Tieto (EGW) incorpora un motor inteligente de enrutamiento inteligente diseñado para optimizar la fiabilidad de las transacciones, mejorar las tasas de éxito de los pagos y minimizar las interrupciones en el procesamiento. Mediante el uso de lógica de enrutamiento dinámica, mecanismos de conmutación por error y toma de decisiones contextual, EGW garantiza un rendimiento de pago constante en una amplia gama de métodos y procesadores de pago.

\
Esta función es fundamental para adquirentes, PSP y comerciantes que buscan maximizar el tiempo de actividad, reducir el abandono del carrito y aumentar la conversión.

## ¿Qué es el enrutamiento inteligente?

El enrutamiento inteligente se refiere a la capacidad de EGW para determinar dinámicamente:

* Seleccionar la mejor ruta de pago disponible (procesador, esquema o método)
* Pasar a opciones alternativas en caso de tiempos de espera agotados o errores
* Aplicar reglas de negocio personalizadas según la categoría del comerciante, la geografía, el valor o el horario
* Supervisar la disponibilidad de los métodos de pago en tiempo real
* Equilibrar el volumen de transacciones entre canales (distribución de carga)

{% hint style="info" %}
[**Conmutación en cascada**](/documentation-es/caracteristicas/transacciones-en-cascada.md) **frente a Enrutamiento inteligente:**

Si bien el Enrutamiento inteligente de EGW determina la ruta de pago óptima antes de iniciar el pago, la plataforma también admite la Conmutación por error en cascada, un mecanismo de reintento secuencial que intenta procesadores o métodos alternativos si falla la ruta principal. Estos dos mecanismos trabajan en conjunto para garantizar la máxima fiabilidad y tasa de éxito en todas las transacciones.

* El enrutamiento inteligente decide el procesador, adquirente o método de pago inicial en función de:
  * Configuración a nivel de plataforma (por ejemplo, por hora, MCC, región, importe de la transacción)
  * Preferencias de enrutamiento definidas por el comerciante (por ejemplo, adquirente de tarjeta preferido, alternativa a A2A)
  * Condiciones en tiempo real (por ejemplo, disponibilidad del procesador, supervisión de salud)
* [Conmutación en cascada](/documentation-es/caracteristicas/transacciones-en-cascada.md) gestiona la lógica de reintento cuando el intento inicial falla — reintentando o cambiando al siguiente procesador o método disponible o configurado, según:
  * Secuencia de respaldo predefinida (dentro del mismo método o entre métodos)
  * Tipos de error (por ejemplo, rechazos suaves, tiempos de espera)
  * Configuraciones específicas del comerciante (si se permite)

#### Flujo de ejemplo:

1. El enrutamiento inteligente selecciona el Procesador A para un pago con tarjeta

   *(según el MCC, la hora, el país y la preferencia del comerciante)*
2. El pago falla (por ejemplo, tiempo de espera agotado o emisor sin respuesta)
3. Se activa la conmutación en cascada → reintento mediante el Procesador B

   *(alternativa definida por el comerciante o configurada en la plataforma)*
4. Si el Procesador B también falla → pasar a A2A u otro método de pago

   *(si el comerciante permite la alternativa entre métodos)*
5. Si ninguna ruta tiene éxito → la transacción se marca como fallida y se informa al cliente
   {% endhint %}

## Escenarios clave de enrutamiento

<table><thead><tr><th width="318">Escenario</th><th>Respuesta del enrutamiento</th></tr></thead><tbody><tr><td>Tiempo de espera agotado del adquirente principal</td><td>Cambiar al adquirente de respaldo o poner la transacción en cola</td></tr><tr><td>Interrupción de SEPA Instant</td><td>Dirigir a tarjeta o a un esquema A2A alternativo</td></tr><tr><td>Rechazo de tarjeta específico del emisor</td><td>Redirigir a otra red compatible o sugerir un método alternativo</td></tr><tr><td>Mantenimiento programado del proveedor</td><td>Evitar los periodos de inactividad conocidos usando lógica basada en el tiempo</td></tr><tr><td>MCC sensible (por ejemplo, juegos de azar)</td><td>Dirigir a través de un procesador de alto riesgo con lógica mejorada de KYC</td></tr><tr><td>Transacción de alto valor</td><td>Dirigir mediante una autorización más estricta con aplicación de 3DS</td></tr></tbody></table>

## Lógica de enrutamiento configurable

El motor de enrutamiento de EGW es totalmente configurable a través del Portal de Administración. El propietario de la pasarela puede definir la lógica mediante un conjunto flexible de reglas basado en una combinación de atributos.

**Criterios de la regla de enrutamiento:**

<table><thead><tr><th width="319">Criterio</th><th>Descripción</th></tr></thead><tbody><tr><td>Tipo de método de pago</td><td>Enrutar de forma diferente para Tarjetas, A2A, Carteras, BNPL</td></tr><tr><td>Código de categoría del comerciante (MCC)</td><td>Aplicar reglas específicas por vertical (por ejemplo, 6012 para servicios financieros, 7995 para juegos de azar)</td></tr><tr><td>Valor de la transacción / Moneda</td><td>Escalar o enrutar de forma diferente según los umbrales</td></tr><tr><td>BIN del emisor / ID del banco</td><td>Lógica específica del adquirente basada en el emisor de la tarjeta</td></tr><tr><td>Geografía (país/región)</td><td>Enrutamiento regional, localización o cumplimiento normativo</td></tr><tr><td>Nivel del comerciante o nivel de riesgo</td><td>Segmentar el enrutamiento según el perfil o el plan SLA</td></tr><tr><td>Disponibilidad del procesador</td><td>Los controles de salud dinámicos determinan el comportamiento de conmutación por error</td></tr><tr><td>Programación basada en el tiempo</td><td>Aplicar reglas basadas en la hora del día o en la ventana de mantenimiento</td></tr><tr><td>Fraude o puntuación de confianza</td><td>Enrutamiento basado en el riesgo hacia rutas con mayor fricción si es necesario</td></tr></tbody></table>

> Reglas de ejemplo:
>
> * Todo MCC 7995 (juegos de azar) se enruta al Adquirente X con diligencia debida reforzada
> * Entre 22:00 y 06:00, dirigir todas las transacciones de contenido digital superiores a 200 € al procesador de respaldo
> * SEPA Instant no disponible → poner A2A en cola y sugerir Tarjeta o BNPL en tiempo real

## Conmutación por error y protección del tiempo de actividad

EGW realiza:

* Supervisión continua de procesadores y esquemas
* Conmutación por error automatizada sin interrupción para el usuario final
* Cola y lógica de reintento para métodos no en tiempo real
* Tiempos de espera y umbrales de reintento configurables
* Sugerencias de respaldo presentadas al usuario final en la página de pago alojada

## Transparencia para comerciantes y propietarios de pasarelas

Operador de la pasarela (Banco/PSP)

* Configurar y probar reglas de enrutamiento a través del Portal de Administración
* Acceder a registros de enrutamiento de transacciones y eventos de conmutación por error
* Aplicar anulaciones a nivel de plataforma o específicas del comerciante
* Supervisar decisiones de enrutamiento en tiempo real con análisis de rendimiento

Comerciante (a través del Portal del Comerciante)

* Definir preferencias (por ejemplo, preferir A2A sobre Tarjeta)
* Ver los resultados de enrutamiento de las transacciones
* Ver el historial de respaldo y las tasas de éxito por método

## Beneficios comerciales

* Mejora las tasas de éxito de pago al evitar rutas conocidas débiles
* Minimiza la pérdida de ingresos por transacciones fallidas o retrasadas
* Permite el enrutamiento regulatorio y específico por vertical (por ejemplo, por MCC)
* Admite la diferenciación de SLA para niveles y segmentos de comerciantes
* Reduce la intervención manual mediante la toma de decisiones automatizada
* Proporciona control transparente a los propietarios de la pasarela y a los comerciantes


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.ecomm.api.tietoevry.com/documentation-es/caracteristicas/fiabilidad-de-los-pagos.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.