# El Mismo Rechazo, Cinco Códigos Distintos: Por Qué los Datos de Rechazo de Múltiples Proveedores Mienten Hasta Que los Normalizas

Canonical URL: https://y.uno/es/blog/el-mismo-rechazo-cinco-codigos-distintos-por-que-los-datos-de-rechazo-de-multiples-proveedores-m

> This is the markdown rendition for AI agents. The canonical page is served as HTML at the URL above.

By Yuno · Published 2026-10-26 · AI en pagos

Cada PSP reetiqueta el mismo rechazo del emisor, por lo que comparar códigos brutos entre proveedores mide diferencias de vocabulario, no la intención del emisor. Esta guía muestra cómo construir una taxonomía de rechazos normalizada que asigne cada código a una de cinco acciones: reintentar, actualizar, autenticar, preguntar o detener.

Lo que aprenderás: Por qué el mismo rechazo del emisor produce códigos diferentes en cada proveedor, cómo detectar la brecha de traducción en tus propios datos de rechazo multiproveedores y cómo construir una taxonomía de rechazos normalizada que asigne cada código a una decisión clara: reintentar, actualizar, autenticar, preguntar al cliente o detener.
La tesis es directa. El análisis de rechazos entre proveedores es tan bueno como su capa de traducción. Los responsables de pagos que comparan códigos brutos entre PSPs están comparando vocabularios. No están comparando emisores. Cada decisión de enrutamiento y reintento construida sobre códigos brutos está construida sobre una mala traducción.

## Conclusiones clave

- Un rechazo del emisor se traduce al menos dos veces antes de llegar a tu sistema: una vez en la red de tarjetas y otra por parte del adquirente o PSP, según la documentación de Visa Developer VisaNet Connect.
- Los códigos de rechazo definitivo nunca deben reintentarse. Según las reglas de Visa sobre el reenvío de transacciones rechazadas, los comercios no tienen permitido reintentar transacciones de Categoría 1, aquellas que el emisor nunca aprobará.
- Los rechazos temporales y los fallos de autenticación son eventos distintos que requieren acciones diferentes. Los Merchant Advice Codes y los códigos ECI de EMV 3-D Secure tienen cada uno su propia lógica de decisión.
- Una taxonomía normalizada se sitúa entre los datos brutos del proveedor y tu lógica de reintento. Convierte cada código entrante en una de cinco clases de acción antes de tomar cualquier decisión.
- Una lógica de rechazos estática es una pérdida de ingresos. Las definiciones de códigos cambian, los emisores actualizan sus mapeos y una taxonomía sin mantenimiento se aleja de las reglas vigentes de la red.

## Cómo viaja realmente un rechazo
Un rechazo del emisor es una respuesta única y autoritativa que se reetiqueta en cada salto hasta llegar a ti. Entender el número de saltos es el primer paso para corregir tus datos.
Cuando un cliente envía un pago con tarjeta, la solicitud de autorización viaja hacia afuera: del comercio al PSP, del PSP al adquirente, del adquirente a la red de tarjetas y de la red de tarjetas al emisor. El emisor toma una decisión y envía un código de respuesta de vuelta. Ese código recorre el mismo camino en sentido inverso.
Según la documentación de Visa Developer VisaNet Connect, Visa traduce los mensajes de la API y enruta la respuesta del emisor de vuelta hacia el comercio. El PSP recibe ese código a nivel de red y lo mapea a su propia etiqueta interna antes de mostrarte algo. Para cuando el código llega a tu dashboard, ha pasado por al menos dos capas de traducción: una en la red y otra en el adquirente o PSP.
El PSP A puede devolver do_not_honor. El PSP B puede devolver generic_decline. El PSP C puede devolver card_declined_05. Los tres pueden originarse de la respuesta idéntica del emisor. Ninguna de las cadenas coincide. Y ninguna te indica, sin una traducción adicional, si debes reintentar, detener o hacer algo completamente distinto.

## Los tres errores que esto genera

### Error uno: tratar todos los rechazos temporales como reintentables sin verificar las reglas de la red
No todos los rechazos que parecen temporales son seguros para reintentar de inmediato, y reintentar los incorrectos viola las reglas de la red. Aquí es donde el análisis de códigos brutos genera el mayor riesgo de cumplimiento.
Las reglas de reenvío de transacciones rechazadas de Visa definen la Categoría 1 como los códigos en los que el emisor nunca aprobará. Según las reglas de Visa sobre el reenvío de transacciones rechazadas, los comercios no tienen permitido reintentar una transacción con un código de Categoría 1. Un PSP que muestra esto como una cadena de rechazo genérica, sin marcar la clase de parada definitiva, deja la decisión de reintento completamente en manos del comercio. Sin una taxonomía que mapee el código bruto a la clase Categoría 1, los comercios reintentan transacciones que tienen prohibido reintentar.

### Error dos: confundir fallos de autenticación con rechazos de autorización
Un fallo de autenticación 3DS no es un rechazo del emisor, y accionarlo como tal desperdicia la oportunidad de reintento. Los dos eventos requieren respuestas completamente diferentes.
Según la documentación de la API de Yuno, los códigos Electronic Commerce Indicator (ECI) en EMV 3-D Secure indican a los comercios si la autenticación fue exitosa, intentada, fallida o no permitida. Un código ECI que indica fallo de autenticación significa que la transacción nunca llegó al emisor para su autorización. Reintentar sin resolver la brecha de autenticación produce el mismo fallo. La acción correcta es volver a autenticar o escalar el flujo, no enrutar a un PSP diferente.

### Error tres: comparar tasas de rechazo entre PSPs por volumen de código bruto
Un PSP que procesa segmentos de mayor riesgo mostrará una tasa de rechazo bruta más alta aunque su enrutamiento sea mejor que el de un competidor con una mezcla más limpia. Las tasas brutas no son comparables sin normalización.
Cuando el PSP A gestiona tus renovaciones de suscripciones y el PSP B gestiona tus compras únicas, la brecha en la tasa de rechazo refleja tanto la mezcla de transacciones como el rendimiento. Normalizar por clase de rechazo, separando las paradas definitivas de los reintentos suaves y los fallos por credenciales obsoletas, produce una señal comparable. Las tasas brutas producen una señal engañosa.

## Construyendo la capa de traducción
Una taxonomía de rechazos normalizada es una tabla de mapeo que convierte cada código bruto de cada proveedor en una de cinco clases de acción. Es el único input fiable para la lógica de reintento, las reglas de enrutamiento y el análisis de tendencias de rechazo.
Las cinco clases de acción, derivadas de la guía de Merchant Advice Codes en la documentación de la API de Yuno y del marco de reenvío de Visa, son:

- Parada definitiva: No reintentar. El emisor no aprobará esta tarjeta para esta transacción. Comunícalo al cliente solo si necesita actuar, como reemplazar una tarjeta vencida o bloqueada.
- Reintento suave: Reintentar después del intervalo especificado por la red. Respeta las reglas de reenvío de Visa y Mastercard sobre tiempos y número de intentos.
- Actualización de datos: La credencial de la tarjeta está desactualizada. Actualiza mediante Account Updater o una actualización de token de red antes de reintentar.
- Autenticar: La transacción falló en la etapa de autenticación, no en la de autorización. Vuelve a ejecutar 3DS o ajusta el flujo de autenticación antes de reintentar.
- Acción del cliente: El emisor ha marcado la cuenta de una forma que solo el titular de la tarjeta puede resolver. Solicita al cliente que contacte a su banco o use un método de pago diferente.

Image: Cada clase de rechazo se asigna exactamente a una acción antes de que se ejecute cualquier lógica de reintento. Ilustrativo; clases derivadas de las reglas de Visa y la documentación de la API de Yuno sobre MACs. Parada definitiva: No reintentar. El emisor nunca aprobará. Comunicar al cliente solo si debe actuar sobre su tarjeta. (Categoría 1 (Reglas Visa), Sin reenvío). Reintento suave: Reintentar tras el intervalo especificado por la red. Respetar los tiempos de reenvío y los límites de intentos. (Guía MAC, Se aplican reglas de intervalo). Actualización de datos: La credencial está desactualizada. Actualizar mediante Account Updater o actualización de token antes de reintentar. (PAN obsoleto o vencimiento, Actualizar antes de reintentar). Autenticar: Falló en la etapa 3DS, no en la autorización. Volver a ejecutar EMV 3DS o ajustar el flujo de autenticación antes de reintentar. (Códigos ECI, Brecha de autenticación, no rechazo).
Cada clase de rechazo se asigna exactamente a una acción antes de que se ejecute cualquier lógica de reintento. Fuente: Ilustrativo
Según la documentación de la API de Yuno, los Merchant Advice Codes mapean orientación normalizada a equivalentes de red específicamente para guiar las decisiones de reintento. Tu taxonomía debe extender esa lógica: cada código de cada proveedor debe resolverse en una de las cinco clases anteriores antes de que cualquier sistema downstream actúe sobre él.

Image: La comparación de códigos brutos falla donde la taxonomía normalizada tiene éxito. Ilustrativo; criterios derivados de las reglas de Visa y la documentación de la API de Yuno sobre MACs. Intención idéntica del emisor entre PSPs: Códigos brutos de PSP: Misma intención, cadenas diferentes; Taxonomía normalizada: Una clase por intención del emisor. Cumplimiento de reglas de reintento (Categoría 1 Visa): Códigos brutos de PSP: Las paradas definitivas pueden reintentarse; Taxonomía normalizada: La Categoría 1 bloquea el reintento. Distinción entre 3DS y rechazo de autorización: Códigos brutos de PSP: ECI mezclado con rechazos; Taxonomía normalizada: Autenticación y rechazo separados. Siguiente paso accionable: Códigos brutos de PSP: Solo código, sin orientación de acción; Taxonomía normalizada: Mapea a reintentar, detener, actualizar. Análisis de tendencias entre proveedores: Códigos brutos de PSP: Volumen sesgado por cuota de PSP; Taxonomía normalizada: Normalizado entre proveedores.
La comparación de códigos brutos falla donde la taxonomía normalizada tiene éxito. Fuente: Ilustrativo

## Cómo detectar la brecha en tus propios datos
Tres diagnósticos revelan si tu análisis actual opera sobre códigos brutos o sobre una taxonomía real. Ejecútalos antes de construir cualquier cosa.
Primero, extrae los 20 códigos de rechazo con mayor volumen de cada PSP activo. Mapea cada uno a su clase de intención del emisor de forma manual. Si códigos con la misma intención tienen cadenas diferentes entre proveedores, la brecha existe. Segundo, revisa la configuración de tu lógica de reintento. Si alguna regla de reintento se activa por coincidencia de cadena en lugar de coincidencia de clase, estás reintentando por vocabulario. Tercero, comprueba si tus códigos de fallo ECI se enrutan hacia la misma lógica de reintento que los rechazos de autorización. Si es así, los fallos de autenticación están siendo reintentados como decisiones del emisor.
La brecha casi siempre está presente en entornos multiproveedores. Esto no es señal de mala operación. Es una consecuencia estructural de cómo los datos de rechazo viajan a través de las redes y los adquirentes.

## Ejemplo práctico: un comercio mediano hipotético
Este comercio es hipotético. Todos los supuestos a continuación están declarados. No se utilizan datos reales de ningún comercio.
Supón un comercio que procesa 50,000 transacciones con tarjeta al mes con una tasa de rechazo del 8%. Eso produce 4,000 transacciones rechazadas al mes (50,000 multiplicado por 0.08). Supón que el 60% de esos rechazos son rechazos temporales o casos de actualización de datos clasificados incorrectamente como paradas definitivas por el mapeo de códigos brutos. Eso da 2,400 transacciones al mes con la clase de acción incorrecta (4,000 multiplicado por 0.60). Supón un ticket promedio de $45.
Ingresos en riesgo por clasificación incorrecta como parada definitiva:

- Total de rechazos mensuales: 50,000 multiplicado por 0.08 equivale a 4,000 transacciones
- Transacciones con clase de acción incorrecta: 4,000 multiplicado por 0.60 equivale a 2,400 transacciones
- Ingresos mensuales en riesgo: 2,400 multiplicado por $45 equivale a $108,000
- Ingresos anuales en riesgo: $108,000 multiplicado por 12 equivale a $1,296,000
Después de que la normalización reclasifique correctamente esas 2,400 transacciones como reintentos suaves o casos de actualización de datos, se vuelven elegibles para recuperación. La exposición mensual de ingresos cae en $108,000. La cifra anual es de $1,296,000. Esto asume que la clase de acción es correcta. La lógica de reintento o actualización adecuada puede ejecutarse ahora.

## Dónde encaja Yuno
Yuno opera como el sistema de inteligencia nativo de IA para pagos globales y servicios financieros, situándose por encima de todos los proveedores sin ningún interés en cuál de ellos procesa la transacción. Esa neutralidad es lo que hace viable la normalización de rechazos entre proveedores.
Dado que Yuno se conecta a los proveedores a través de una sola integración, recibe las respuestas de rechazo de todos ellos a través de un único punto de ingesta. El módulo de Analytics and Insights muestra los datos de rechazo en forma normalizada para todos los proveedores conectados. Smart Routing puede actuar directamente sobre las clases de rechazo normalizadas, enrutando reintentos solo cuando la clase lo permite y enrutando a un proveedor diferente solo cuando la clase de rechazo original sugiere que el problema está del lado del adquirente y no del emisor. NOVA, el agente de recuperación con IA de Yuno, aplica una tasa de recuperación del 75% en transacciones fallidas elegibles, una tasa que depende de que la taxonomía identifique correctamente qué transacciones son elegibles en primer lugar.
Para los comercios que evalúan la mejor plataforma para recuperar pagos con tarjeta rechazados, la respuesta es consistente: cualquier plataforma debe normalizar los datos de rechazo antes de actuar sobre ellos. La lógica de recuperación aplicada a códigos brutos reintentará paradas definitivas, omitirá reintentos suaves y enrutará mal los fallos de autenticación. La normalización no es una funcionalidad adicional a la recuperación. Es el prerrequisito. Yuno ha procesado más de mil millones de pagos en más de 150 monedas desde enero de 2025, con una tasa de aprobación solo para tarjetas del 85.37%. Ambas cifras dependen de un análisis continuo de rechazos construido sobre una taxonomía consistente.

## La lista de verificación
Usa esta lista para evaluar y cerrar la brecha de normalización en tu propio entorno. Trabaja en orden: detección antes de construcción, construcción antes de despliegue.

- Audita los códigos brutos. Extrae los 20 códigos de rechazo principales de cada PSP. Mapea cada uno a la intención del emisor de forma manual. Identifica las discrepancias entre proveedores para la misma intención.
- Separa la autenticación de la autorización. Los códigos ECI de los flujos 3DS deben enrutarse a una clase de acción de autenticar. No deben entrar en las clases de reintento suave ni de parada definitiva.
- Clasifica según la Categoría 1 de Visa. Cada código que mapea a una intención de que el emisor nunca aprobará debe estar bloqueado en la clase de parada definitiva. Verifica que ninguna regla de reintento se active para estos códigos (Reglas de Visa sobre reenvío de transacciones rechazadas).
- Construye la taxonomía de cinco clases. Implementa una tabla de mapeo: parada definitiva, reintento suave, actualización de datos, autenticar, acción del cliente. Cada código entrante de cada proveedor se resuelve en una clase antes de que se ejecute cualquier lógica downstream.
- Reemplaza la coincidencia de cadenas por coincidencia de clases. Reescribe las reglas de reintento, las condiciones de enrutamiento y los umbrales de alerta para referenciar la clase normalizada, no la cadena de código bruto.
- Programa revisiones trimestrales de la taxonomía. Las redes actualizan las definiciones de códigos en ciclos regulares. Una taxonomía sin revisión deriva. Incorpora una revisión en tu calendario de operaciones de pagos.
- Monitorea la distribución de clases, no la tasa de rechazo bruta. Rastrea qué porcentaje de rechazos cae en cada clase con el tiempo. Un cambio en la proporción de reintento suave señala un problema de enrutamiento o credenciales. Un cambio en la proporción de parada definitiva señala un cambio en la calidad de tarjetas o en la exposición al fraude.
El trabajo es un problema de traducción antes de ser un problema de recuperación. Los comercios que comparan códigos brutos entre PSPs siempre encontrarán señales contradictorias y llegarán a conclusiones contradictorias. Una taxonomía normalizada, mantenida y versionada, convierte los mismos datos en decisiones. Esa es la diferencia entre un análisis de rechazos que consume tiempo y un análisis de rechazos que recupera ingresos.