La mayoria de las guias sobre Compelling Evidence 3.0 se detienen en las reglas de calificacion: hacer coincidir dos de cuatro elementos de datos en tres transacciones, asegurar que uno sea IP o device ID, y presentar bajo el codigo de motivo 10.4. Si se cumplen esos criterios, el traslado de responsabilidad es automatico.
Pero no todas las disputas por fraude califican para CE 3.0. Cuando no califican, se vuelve al representment estandar, donde la evidencia presentada realmente se evalua. Este articulo cubre los cuatro elementos de datos que Visa exige para CE 3.0 y luego recorre seis puntos de evidencia adicionales que importan para las disputas que CE 3.0 no cubre.
La regla, de forma compacta
CE 3.0 aplica a disputas Visa de tarjeta no presente bajo el codigo de motivo 10.4 ("Other Fraud: Card-Absent Environment"). El comercio debe presentar dos transacciones previas no disputadas con las mismas credenciales de pago, cada una con antigueedad de entre 120 y 365 dias respecto a la fecha de la disputa. Al menos dos de cuatro elementos de datos principales (User ID, direccion de envio, direccion IP o device ID) deben coincidir en las tres transacciones, y uno de los dos debe ser direccion IP o device ID.
Fuente: Documento de preparacion de comercios para Visa Compelling Evidence 3.0.
Los cuatro elementos de datos que Visa exige
La calificacion de CE 3.0 requiere que al menos dos de cuatro elementos de datos coincidan en las tres transacciones (la disputada y las dos previas no disputadas). Uno de los dos debe ser direccion IP o device ID.
- Coincidencia de User ID. Cualquier identificador que el comercio use para la cuenta del titular. Debe ser consistente en las tres transacciones.
- Coincidencia de direccion de envio. Direccion de entrega en las tres transacciones. Las diferencias menores (numeros de departamento, puntuacion) pueden ser problematicas; la mayoria de los adquirentes requieren coincidencia exacta.
- Coincidencia de direccion IP. IP capturada al momento de la compra para las tres transacciones. La coincidencia a nivel de ISP es aceptable para la mayoria de los emisores; la direccion exacta es mas fuerte.
- Coincidencia de device ID. Huella digital del dispositivo capturada al checkout en las tres transacciones. Debe ser producida desde la misma fuente para ser tratada como determinista. Un browser fingerprint combina docenas de senales no sensibles (resolucion de pantalla, zona horaria, configuracion de idioma) en un hash estable que persiste entre sesiones, modo incognito y almacenamiento borrado.
Un quinto campo, el numero de cuenta principal (PAN), es la base. El mismo PAN en las tres transacciones es un prerrequisito, no uno de los cuatro elementos a comparar. Los PAN tokenizados cuentan si la referencia del token es estable entre sesiones.
Mas alla de CE 3.0: seis puntos de evidencia para disputas que no califican
Si la disputa cumple los criterios de CE 3.0, el traslado de responsabilidad es automatico. No se necesita nada mas alla de los cuatro elementos de datos exigidos para ganar.
Pero no todas las disputas por fraude califican para CE 3.0. El codigo de motivo puede no ser 10.4, puede no haber dos transacciones previas no disputadas en la ventana de 120 a 365 dias, o los elementos de datos pueden no coincidir con suficiente precision. Para esos casos, se recurre al representment estandar, donde el emisor evalua la evidencia y toma una decision. Estos seis puntos de evidencia son los que marcan la diferencia en ese proceso:
- Consistencia del descriptor first-6. Los primeros seis caracteres del descriptor de facturacion en las transacciones deben ser identicos para que el adquirente las trate como el mismo comercio. La variacion del descriptor entre cargos iniciales y recurrentes es una de las razones mas comunes de fallo en la calificacion CE 3.0, y tambien debilita el representment estandar.
- Registro de autenticacion. Visa Secure o Visa Data Only asociado a la transaccion. En un representment estandar esto demuestra que el titular se autentico, lo que debilita la reclamacion de fraude. En un contexto CE 3.0 puede activar la autocalificacion.
- Confirmacion de entrega o cumplimiento. Para bienes fisicos, un numero de seguimiento y prueba de entrega firmada. Para bienes digitales, una sesion con coincidencia de IP que muestre acceso al contenido. Esta es evidencia estandar de representment que contradice directamente "no lo recibi".
- Patron de tiempo de transacciones previas. Un historial de transacciones que muestre una relacion plausible con el cliente, no dos compras agrupadas artificialmente. En representment estandar, esto establece el patron de uso legitimo del titular.
- Senales de continuidad de sesion. Evidencia de que la misma sesion de navegador o dispositivo fue usada para navegar, agregar al carrito y completar el pago. Esto vincula la transaccion a una sesion de usuario real en lugar de un unico punto de datos al checkout. El device fingerprinting disenado para CE 3.0 puede producir este tipo de continuidad a nivel de sesion de forma nativa.
- Perfil de disputas del comercio. Un comercio con un historial de disputas limpio obtiene el beneficio de la duda en representment estandar. Un comercio con un largo historial de casos revertidos enfrenta un escrutinio mas severo incluso con evidencia solida.
De donde proviene cada punto de evidencia
User ID y direccion de envio provienen de la base de datos de pedidos. Descriptor de facturacion y autenticacion provienen del procesador de pagos y la configuracion 3DS. Direccion IP y device ID (los dos que determinan si calificas para CE 3.0) provienen de la sesion de checkout, y la mayoria de los comercios no los capturan de forma confiable.
Elementos exigidos por Visa:
| Elemento de datos | Fuente | Generalmente capturado al momento del representment? |
|---|---|---|
| PAN (prerrequisito) | DB de pedidos / procesador de pagos | Si |
| User ID | DB de pedidos | Si |
| Direccion de envio | DB de pedidos | Si |
| Direccion IP | Sesion de checkout | A veces (inconsistente) |
| Device ID | Sesion de checkout | Raramente (requiere instrumentacion) |
Puntos de evidencia adicionales:
| Punto de evidencia | Fuente | Generalmente capturado al momento del representment? |
|---|---|---|
| Descriptor first-6 | Configuracion del procesador de pagos | Si |
| Registro de autenticacion | Flujo 3DS | Si donde 3DS esta activo |
| Cumplimiento / entrega | OMS / transportista | Si |
| Patron temporal de transacciones previas | DB de pedidos + herramienta de respuesta a disputas | Si |
| Continuidad de sesion | Sesion de checkout | Raramente (requiere instrumentacion) |
| Perfil de disputas | Adquirente | Implicito |
La direccion IP y el device ID son donde la mayoria de los casos de representment fallan por merito. Son datos de la sesion de checkout, no de la base de datos de pedidos. Una herramienta de chargeback del lado del servidor no puede reconstruirlos despues del hecho. Si la instrumentacion no estaba presente al momento de la compra, los datos simplemente no existen.
El requisito de evidencia en la capa del navegador
Device ID e IP con estandar de calificacion CE 3.0 significan la misma firma de dispositivo y red en las transacciones previas y la disputada. Esa firma se captura al checkout, en el navegador, en el momento en que el titular envia el pago. Ningun sistema post-hoc puede producirla.
El producto Chargeback Evidence de cside captura los datos de la capa del navegador al checkout. La identidad del dispositivo es estable entre sesiones en el mismo comercio, lo que permite que una transaccion previa de hace ocho meses pueda vincularse deterministicamente con una transaccion disputada hoy. La IP capturada es la IP que el titular realmente uso en la compra, no una IP inferida posteriormente.
Para el paquete de evidencia en su conjunto, la captura en la capa del navegador cierra los dos campos obligatorios que las herramientas del lado del servidor no pueden (direccion IP y device ID) y refuerza la confirmacion de entrega al vincular el acceso de cumplimiento al mismo dispositivo. El paquete presentado al emisor se lee como una cadena de evidencia completa en lugar de un ensamblaje de papeles.
Que significa esto operativamente
Empieza auditando si tus disputas pueden calificar para CE 3.0. Si los cuatro elementos de datos exigidos coinciden, el traslado de responsabilidad es automatico y no necesitas construir un caso mas amplio. La correccion de mayor impacto es asegurarte de que realmente puedas capturar IP y device ID al checkout para que mas disputas califiquen.
Para las disputas que quedan fuera de CE 3.0, audita los seis puntos de evidencia complementarios. Las correcciones mas baratas son la alineacion del descriptor first-6 y la cobertura 3DS. La de mayor impacto es la captura de evidencia en la capa del navegador, que te da datos a nivel de sesion para respaldar el representment estandar.
Una auditoria de treinta minutos:
- Extrae diez disputas recientes con codigo de motivo 10.4. Para cada una, verifica si tenias los cuatro elementos de datos exigidos por Visa disponibles. Cuantas podrian haber calificado para CE 3.0 pero no lo hicieron porque faltaba IP o device ID?
- Para las que no calificaron, revisa cuales de los seis puntos de evidencia complementarios podrias haber presentado en un representment estandar. El patron suele ser claro: device ID e IP estan ambos ausentes o son de baja calidad, y el descriptor first-6 varia entre ciclos de facturacion.
- Compara tu tasa de victorias en disputas calificadas para CE 3.0 (que deberia acercarse al 100%) contra tu tasa de representment estandar. La diferencia te dice cuanto ingreso esta en juego en las disputas que CE 3.0 no cubre.
El Informe Global de Fraude y Pagos 2025 del Merchant Risk Council encontro que la mayoria de los comercios encuestados ya usan el programa Compelling Evidence. Los comercios en la parte superior de esa cohorte son los que instrumentaron la capa del navegador, calificando mas disputas para CE 3.0 desde el principio. Los comercios en la parte inferior carecen de IP y device ID, lo que significa menos victorias automaticas y representments estandar mas debiles.
Errores comunes
Los tres errores mas comunes de CE 3.0 son la variacion del descriptor entre ciclos de facturacion, depender de la captura de IP del lado del servidor (que a menudo refleja el balanceador de carga en lugar del cliente) y tratar los device fingerprints como oportunistas. Cada uno de estos puede evitar que una disputa califique para CE 3.0 en primer lugar, y cada uno debilita tu posicion en representment estandar tambien.
Variacion del descriptor. Los procesadores de pagos a veces reescriben los descriptores entre transacciones iniciales y recurrentes, o los varian por moneda. Incluso un cambio de un caracter en los primeros seis rompe la calificacion.
Captura de IP del lado del servidor. Muchos comercios registran la IP desde el servidor que recibe el POST del checkout, que en arquitecturas modernas a menudo registra un balanceador de carga o edge CDN en lugar del cliente. La IP debe capturarse del lado del cliente en la capa del navegador para coincidir de forma fiable.
Device fingerprints oportunistas. Un device fingerprint capturado a traves de un script de terceros que carga en el checkout no es lo mismo que un fingerprint determinista de sesion de checkout. Si el comercio no puede reproducir la logica de fingerprinting bajo demanda, el emisor puede descontar la coincidencia.
Mas lectura en cside
Sobre el autor
Mike Kutlu es Head of GTM en cside, donde trabaja con responsables de pagos, riesgo y finanzas en la instrumentacion de evidencia de chargeback en la capa del navegador para representment con Compelling Evidence 3.0. Escribe sobre VAMP, friendly fraud y la mecanica de la evidencia de disputas para comercios enterprise.
