Si administras cobros recurrentes, seguramente ya conoces esta escena: un pago con tarjeta falla y la pantalla muestra un mensaje genérico, "Transacción no autorizada". Detrás de eso hay un viaje de la transacción entre el adquirente, la red (Visa o Mastercard) y el emisor, donde docenas de campos de información estructurada deciden si el cobro se aprueba o se rechaza. En Toku, dentro de ese espacio, una de las apuestas más importantes ha sido la adopción de los Tokens de Red.
¿Qué es un Token de Red?
La idea detrás de un Token de Red es simple: en lugar de almacenar y transmitir el número real de la tarjeta (el PAN, o Primary Account Number), se usa un token generado directamente por la red. Visa y Mastercard tienen sus propios servicios para esto, y ambas documentan mejoras de entre 3 y 4.6 puntos porcentuales en tasas de autorización para transacciones donde la tarjeta no está físicamente presente.
En teoría, es un muy buen sistema: cada transacción con Token de Red incluye un criptograma dinámico que acredita que fue generada legítimamente, reduciendo rechazos por sospecha de fraude. Si la tarjeta se renueva, el token se actualiza automáticamente sin que el tarjetahabiente ni el comercio tengan que hacer nada. Y si el token se filtra, solo puede usarlo quien lo solicitó originalmente, lo que reduce bastante el riesgo de fraude.
Pero la práctica es más complicada
Los Tokens de Red tienen un ciclo de vida propio: pueden quedar marcados como activos en nuestra base de datos mientras el emisor ya los desactivó por reemplazo de tarjeta o sospecha de fraude. Cuando ese desfase ocurre, el cobro falla con códigos como "05 - Do Not Honor" o "14 - Invalid Card Number", los mismos que devuelve un emisor cuando rechaza por sospecha de fraude, cuando la tarjeta está bloqueada, o cuando hay un problema con la cuenta. El token no tiene su propio código de error. Esa ambigüedad hace que la lógica de reintento sea un problema genuino de diseño: no se puede derivar la respuesta correcta desde primeros principios, porque el mismo código puede significar cosas completamente distintas según el contexto. La decisión de reintentar, re-provisionar el token, o usar el número de tarjeta original como alternativa en casos específicos no tiene una respuesta universal, y cada elección incorrecta tiene un costo: conversión perdida o intentos que el emisor penaliza.
La razón de fondo es que esta tecnología es relativamente reciente. La adopción completa del modelo donde el emisor procesa el token directamente todavía está en curso, y más aún en Latinoamérica. Hay emisores con implementaciones incompletas que generan rechazos que en teoría no deberían existir cuando se usa un token. Aun así, es una apuesta que vale la pena, y la forma de navegar esa complejidad es la misma que aplicamos a cualquier otro frente en Cards: medir qué funciona, con quién, y en qué condiciones.
Cómo navegamos esa ambigüedad
Para navegar esa ambigüedad, diseñamos experimentos que corrían cobros con ambos instrumentos, el Token de Red y el número real de la tarjeta, y comparábamos los resultados cruzando el código de error recibido, el banco emisor, e incluso el BIN (los primeros dígitos de la tarjeta, que identifican al emisor y el tipo de tarjeta). No nos interesaba tanto cuál instrumento aprobaba más en general, sino entender los casos puntuales donde el token fallaba y el número original funcionaba, o al revés. Eso nos permitió construir un mapa de comportamiento por emisor: para algunos, el token es claramente superior; para otros, en ciertos tipos de error, vale la pena intentar con el número original. Y en algunos casos, el resultado con ambos es un rechazo, lo que indica que el problema no es el instrumento sino que la tarjeta ya no está activa.
Medir caso a caso
Los datos agregados de Visa y Mastercard respaldan la apuesta por Tokens de Red, y nuestra propia experiencia también. Pero no funcionan igual con todos los emisores, y ahí está la parte que más nos afecta la conversión. Por eso en Toku seguimos midiendo caso a caso: qué emisor responde bien al token, cuál todavía no, y ajustamos la estrategia de cobro según nuestros propios datos.