Cómo reducir los contracargos con la detección de IP
Reduce los contracargos con la detección de IP: puntúa la IP detrás de cada pedido sin tarjeta presente para frenar el fraude CNP y gana las disputas de fraude amistoso con evidencia de IP.

Todos los comercios se encuentran con el contracargo de la misma manera. Una tarjeta se aprueba, el pedido se envía y, cuarenta días después, el dinero se retira de tu cuenta junto con una comisión, a veces una comisión mayor que la propia venta. Si ocurre con suficiente frecuencia, ya no discutes sobre pedidos concretos. Discutes con Visa y Mastercard sobre si puedes seguir procesando tarjetas.
La mayoría de los consejos contra los contracargos tratan la disputa como el evento. No lo es. La disputa es la factura de una decisión que ya tomaste: el momento en que autorizaste una transacción que deberías haber filtrado, o en que enviaste un pedido de un cliente que nunca registraste lo bastante bien como para defenderte. La detección de IP no es una forma de argumentar mejor a posteriori. Es una forma de llevar la decisión de vuelta a los dos puntos en los que todavía puede salir a tu favor: la autorización y la evidencia.

Un contracargo son en realidad dos problemas distintos
Antes de hablar de herramientas, conviene tener clara la clasificación, porque los dos tipos de contracargo requieren respuestas opuestas.
El fraude real es un desconocido que usa una tarjeta robada. El número de otra persona, tu tienda, mercancía enviada a una dirección de recogida. Este es el contracargo que quieres prevenir, porque cada uno que se cuela supone inventario perdido más una comisión más una marca en tu ratio. La detección de IP combate este en la puerta de entrada, antes de enviar, leyendo la red del pedido como una puntuación de riesgo de IP con franjas de permitir, revisar, paso adicional y bloquear.
El fraude amistoso (también llamado uso indebido por el propio titular) es tu cliente real disputando un cargo que sí hizo. Se olvidó de la suscripción, hizo el pedido un familiar o simplemente aprendió que "no reconozco este cargo" le devuelve el dinero. Según las propias cuentas de Visa, este tipo de uso indebido por el propio titular supone hasta el 75% de todos los contracargos. No puedes evitarlo en el checkout, porque la transacción era legítima. Lo ganas después, con evidencia, y la dirección IP es una pieza de esa evidencia citada expresamente.
Un campo, dos funciones: filtra el fraude real antes de que se dispute y te ayuda a revertir el fraude amistoso después de que se dispute. Por eso es el mejor punto de partida.
Por qué el ratio es ahora una cuestión de supervivencia
La razón por la que los contracargos dejaron de ser un coste más del negocio y pasaron a ser una cuestión de supervivencia es que las redes de tarjetas reescribieron sus programas de supervisión, y las dos nuevas versiones apuntan directamente a los pedidos online.
Visa unificó sus dos antiguos programas (el Visa Dispute Monitoring Program y el Visa Fraud Monitoring Program) en un único Visa Acquirer Monitoring Program (VAMP), en vigor desde abril de 2025. Lee el funcionamiento en la propia ficha informativa de VAMP de Visa, porque dos detalles cambian la forma en que deberías pensar en el problema:
- Solo cuentan las transacciones sin tarjeta presente. El ratio VAMP se calcula a partir de la actividad sin tarjeta presente. Los contracargos que amenazan tu cuenta de comercio son, por definición, los pedidos online: justo los pedidos en los que tienes la dirección IP del cliente para trabajar.
- El fraude y las disputas se cuentan juntos, y a menudo dos veces. El ratio combina los informes de fraude TC40 y las disputas TC15 sobre las transacciones liquidadas. Como una transacción reportada como fraude suele convertirse también en disputa, un solo pedido malo puede aparecer dos veces en tu ratio. Prevenirlo una vez elimina ambos.
- El listón está bajando. El umbral "Excessive" para comercios se lanzó en el 2,2% y baja al 1,5% a partir de abril de 2026 en EE. UU., Canadá y la UE. El suelo se está acercando a ti.
Mastercard sigue una vía paralela. Su Excessive Chargeback Program marca a un Excessive Chargeback Merchant (ECM) con un ratio del 1,5% y entre 100 y 299 contracargos en un mes, y a un High Excessive Chargeback Merchant (HECM) con un 3,0% y 300 o más. Las multas aumentan cuanto más tiempo te mantienes por encima, y el desenlace final para un comercio que no consigue recuperarse es la lista MATCH, un exilio de hecho de cinco años del procesamiento de tarjetas.
| Programa | Umbral que importa | Qué cuenta | Desenlace |
|---|---|---|---|
| Visa VAMP (comercio) | 2,2% ahora → 1,5% desde abr. 2026 (EE. UU./CA/UE) | Fraude + disputas sin tarjeta presente, combinados | Multas crecientes, presión del adquirente |
| Mastercard ECM | Ratio del 1,5%, entre 100 y 299 contracargos | Todos los contracargos, por cualquier motivo | Multas mensuales que aumentan con el tiempo |
| Mastercard HECM | Ratio del 3,0%, 300 o más contracargos | Todos los contracargos, por cualquier motivo | Aumento más rápido de las multas, riesgo de lista MATCH |
La conclusión no es la cifra exacta (consulta a tu propio adquirente, porque las regiones y las fechas de implantación varían). Es la dirección. Las redes han decidido que tu ratio de contracargos sin tarjeta presente es una métrica de cumplimiento, el umbral está bajando y el tráfico que mide es exactamente el tráfico que puede leer una consulta de IP.
Dónde encaja la detección de IP en el ciclo de vida del contracargo
Un pedido sin tarjeta presente pasa por tres puertas en las que la IP es decisiva, dentro de una pila de detección de fraude en pagos por capas más amplia con comprobaciones de dispositivo, del emisor y de revisión. Reducir los contracargos significa usar las tres, no solo la primera.
| Etapa | Cuándo | Qué hace la IP |
|---|---|---|
| Filtrado previo a la autorización | Antes de aprobar/enviar | Marca el fraude con tarjetas robadas para que puedas rechazar, revisar o pedir un paso adicional. Esto evita que el contracargo llegue a existir. |
| Decisión de paso adicional (3DS) | En el checkout, de forma selectiva | Decide qué pedidos reciben un desafío de 3-D Secure, para que obtengas el traslado de responsabilidad sin fricción en los pedidos limpios. |
| Evidencia en la disputa | Semanas después, en la representación | Aporta la IP registrada como Compelling Evidence 3.0 para revertir los contracargos por fraude amistoso. |
La mayoría de los comercios solo usan la primera puerta, e incluso entonces de forma tosca. Las ganancias que se acumulan están en usar la IP para decidir quién ve un desafío 3DS y en haberla registrado para poder ganar las disputas que llegan a la representación. Empezamos por la puerta delantera, porque es donde están las señales de mayor confianza y con menos falsos positivos.
Las señales de IP que predicen un contracargo
Esto es lo que hay que leer de la dirección que hay detrás de un pedido, más o menos en orden de relación señal/ruido para los pagos sin tarjeta presente.
| Señal | Por qué predice un contracargo | Cómo tratarla |
|---|---|---|
| El tipo de conexión / ASN es hosting | Los compradores reales no pagan desde AWS. El origen en un datacenter es la señal clásica del carding automatizado. | Fuerte en el checkout, débil solo en la puntuación. Añade tu propia regla sobre ella (consulta la consulta de más abajo). |
| VPN / proxy público / Tor | La ocultación deliberada del origen en un pago es un motivo para mirar con más atención. | Pondérala, pero nunca bloquees solo por ella. Muchos compradores reales usan una VPN. |
| País de facturación ≠ país de la red | Una tarjeta facturada en un país que paga desde una red de otro es un patrón de fraude CNP muy conocido. | Negativa moderada. Combínala con el tipo de conexión antes de actuar. |
| Aparición en fuentes de amenazas / listas de bloqueo | La infraestructura con un historial de abuso activo se reutiliza en distintas campañas de fraude. | Fuerte cuando es reciente. Pondérala por su antigüedad, no por el mero hecho de estar en una lista. |
| Proveedor de VPN/anonimizador identificado | La atribución a una VPN comercial o un relé concretos refuerza la señal de ocultación. | Corroborante: aumenta la confianza en los demás indicadores. |
| ISP residencial / móvil | Aquí es donde están realmente tus clientes reales. | Exonerante. Un motivo para ser más indulgente, no menos. |
| NAT de nivel de operador (CGNAT) | Cientos de abonados móviles comparten una misma dirección pública. | Exonerante. Limita el riesgo aquí o castigarás a compradores reales. |
Fíjate en el sentido de las dos últimas filas. Un modelo de puntuación que solo suma puntos convertirá a tu público móvil legítimo en una fuente de rechazos falsos, y un rechazo falso en el checkout no es un inicio de sesión bloqueado. Es un cliente que paga y al que has rechazado. Un modelo que también resta (que trata un ISP residencial como un motivo de indulgencia y pone un tope a los rangos CGNAT) es lo que evita que la prevención de contracargos se convierta discretamente en prevención de ingresos. Ese equilibrio se construye a partir de los motivos que bajan una puntuación de riesgo, y en el checkout importa más que casi en ningún otro sitio.
Lo fundamental es que la IP es evidencia, no un veredicto. No vetes la dirección. Una misma IP pública la comparten muchas personas sin relación entre sí, así que un bloqueo rígido elimina a clientes reales junto con el fraude. Puntúala, pondérala frente a las demás señales y actúa sobre el conjunto. Lo argumentamos en detalle en detectar tráfico anonimizado sin bloquear a clientes reales, y es la misma disciplina que separa un filtro de checkout inteligente de uno tosco en frenar el fraude de agentes de compra con IA y de bots en el checkout por IP.
Leerlo en una sola llamada
En concreto, se trata de una consulta sobre la IP que hizo el pedido, antes de decidir si lo apruebas, lo desafías o lo revisas.
curl -H "x-api-key: YOUR_API_KEY" \
https://api.geoiphub.com/v1/lookup/45.33.32.156
Los campos que importan para un pedido sin tarjeta presente se reparten entre cuatro grupos de la respuesta:
const res = await fetch(`https://api.geoiphub.com/v1/lookup/${orderIp}`, {
headers: { "x-api-key": process.env.GEOIPHUB_API_KEY },
});
const ip = await res.json();
ip.asn.asn_type; // "hosting": a checkout should not originate here
ip.asn.connection_type; // "datacenter" | "residential" | "mobile"
ip.detection.is_hosting; // true: datacenter origin on a consumer payment
ip.detection.is_vpn; // deliberate concealment; weigh it, don't ban
ip.detection.vpn_provider; // the named provider, when concealment is present
ip.geo.country_code; // compare against the billing country on the card
ip.threat.threat_types; // e.g. ["vpn"] or ["tor"] when a feed or probe tags the address
ip.threat.is_cgnat; // shared mobile address: a reason for leniency
ip.scoring.fraud_score; // 0-100 composite
ip.scoring.recommended_action; // "allow" | "review" | "step_up" | "block"
ip.scoring.detection_methods; // exactly which signals fired: your audit trail
detection_methods es el campo que convierte esto de una caja negra en una decisión que puedes defender. Cuando un pedido se desafía o se retiene, puedes decir por qué (ASN de hosting, ocultación mediante VPN, discrepancia con el país de facturación, en dos fuentes esta semana) en lugar de encogerte de hombros ante una puntuación. Y country_code es el que hay que cotejar con la dirección de facturación de la tarjeta: una tarjeta facturada en Alemania que paga desde una red de hosting de otro país es la historia de fraude CNP más antigua que existe.
Puedes probar el resultado de la puntuación con cualquier dirección en el comprobador gratuito de puntuación de riesgo de IP antes de integrarlo, y la misma consulta está documentada como una pieza reutilizable en añadir detección de fraude por IP en tiempo real a tu aplicación.
Una IP de hosting obtiene allow; una VPN verificada obtiene block
Las dos señales de la parte superior de la tabla se comportan de forma muy distinta en la puntuación: una dirección de hosting sin más devuelve allow, y un servidor VPN con evidencia de protocolo devuelve block. Aquí están ambas, recortadas de consultas reales hechas el 26 de octubre de 2026 (los resultados cambian a medida que se mueven los rangos). Primero, 45.33.32.156, la dirección de hosting de la llamada anterior (el host de pruebas público de Nmap, scanme.nmap.org):
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": { "country_code": "US", "city": "Fremont" },
"detection": {
"is_hosting": true,
"is_vpn": false,
"is_proxy": false,
"is_tor": false
},
"threat": { "is_cgnat": false, "threat_types": [] },
"scoring": {
"fraud_score": 10,
"confidence": 0.25,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
Después, 185.213.155.73, un servidor VPN de Mullvad en Fráncfort:
{
"ip": "185.213.155.73",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": { "country_code": "DE", "city": "Frankfurt am Main (Innenstadt I)" },
"detection": {
"is_vpn": true,
"is_hosting": true,
"is_anonymous": true,
"vpn_provider": "Mullvad",
"vpn_confidence": 95
},
"threat": { "threat_types": ["vpn"] },
"scoring": {
"fraud_score": 100,
"confidence": 0.7075,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "wireguard_open", "datacenter_with_vpn_proxy", "no_ptr_datacenter"]
}
}
La IP de hosting activó un método, datacenter_ip, y obtuvo 10: la puntuación general no trata un origen en un datacenter como fraude por sí solo, así que la regla de checkout para ese caso la tienes que añadir tú. La VPN activó cuatro: está en la lista de servidores que publica la propia Mullvad (que además identifica al proveedor), esa lista la marca como servidor WireGuard, el protocolo en una red de hosting añade datacenter_with_vpn_proxy y no tiene nombre de DNS inverso. Obtuvo 100. No todas las VPN se identifican por su nombre: un servidor encontrado solo por nuestra propia sonda de protocolo devuelve vpn_provider "none", así que no cuentes con ello. Como los compradores reales también usan VPN, trata ese block en el checkout como "enviar a 3-D Secure o a revisión" salvo que una segunda señal coincida, como un país de facturación distinto de geo.country_code.
3-D Secure sin el impuesto de la fricción
La segunda puerta es donde reducir los contracargos deja de ser puramente defensivo.
Cuando una transacción sin tarjeta presente se autentica mediante EMV 3-D Secure, la responsabilidad por un contracargo posterior por fraude pasa, por lo general, del comercio al emisor de la tarjeta. Esa es la palanca más poderosa que tienes contra los contracargos por fraude real: un pedido autenticado que más tarde resulta ser fraude no suele ser una pérdida tuya.
Entonces, ¿por qué no enviar todos los pedidos por 3DS? Porque un desafío es fricción, y la fricción son carritos abandonados. Obliga a todos los compradores a un paso adicional y perderás más ingresos por abandono de carrito de los que nunca perdiste por fraude.
Este es exactamente el equilibrio que resuelve una puntuación de riesgo de IP. En lugar de desafiar a todos o a nadie, desafías según el riesgo:
- Puntuación baja (ISP residencial, historial limpio, país coincidente): déjalo pasar sin fricción. La mayor parte de tu tráfico está aquí.
- Puntuación elevada (discrepancia de país, señales escasas), o una VPN sin nada más en contra: envíalo a un desafío 3DS. Una VPN verificada cae por sí sola en la franja de bloqueo, así que esto es una excepción deliberada. Obtienes el traslado de responsabilidad justo en los pedidos en los que lo quieres.
- Puntuación alta (una VPN verificada o un nodo de salida de Tor con una segunda señal que coincide, como una discrepancia de país): rechaza o retén para revisión; no malgastes el intento de 3DS en infraestructura evidente.
La puntuación de IP decide quién ve el desafío. Así es como obtienes la protección de responsabilidad de 3DS en la porción de riesgo sin tocar a tu mayoría limpia. Es el mismo razonamiento por acción que exponemos en a partir de qué puntuación de riesgo de IP deberías bloquear, aplicado específicamente al paso del checkout.
Ganar la disputa por fraude amistoso
La tercera puerta es la que la mayoría de los comercios dejan completamente desarmada, y es donde están realmente hasta tres cuartas partes de los contracargos.
Cuando un cliente real disputa una compra que sí hizo, no podrías haberlo evitado en el checkout, porque el pedido era legítimo. Lo que sí puedes hacer es demostrar que fue él. Visa creó un estándar exactamente para esto: Compelling Evidence 3.0, en vigor desde abril de 2023, que permite a un comercio revertir una disputa por fraude sin tarjeta presente (código de motivo de Visa 10.4) demostrando una huella histórica con el titular de la tarjeta.
Lee el requisito con atención, porque la dirección IP está escrita en él:
- Aportas dos transacciones anteriores no disputadas con las mismas credenciales, de entre 120 y 365 días de antigüedad.
- Esas transacciones deben compartir elementos de datos principales con el pedido disputado. Los elementos que nombra Visa son la dirección IP, el ID/huella digital del dispositivo, el ID de usuario y la dirección de envío.
- Al menos dos elementos deben coincidir en las tres transacciones, y al menos uno de ellos debe ser la dirección IP o el ID/huella digital del dispositivo.
- Si la evidencia cumple los requisitos, la responsabilidad pasa al emisor y te quedas con el dinero.
Aquí la dirección IP no es un extra. Es uno de los dos elementos ancla que Visa acepta como prueba de que la persona que disputa el cargo es la misma que lleva meses comprándote. Pero esta es la parte que, sin que se note, hace perder a los comercios disputas que podían ganar: solo puedes presentar esta evidencia si registraste la IP en cada pedido desde el principio, y la guardaste el tiempo suficiente como para remontarte un año completo.
Eso replantea por completo la consulta previa a la autorización. La IP que registras en el checkout no es solo una señal de fraude para el pedido de hoy. Es la materia prima para ganar una disputa por fraude amistoso dentro de un año. Regístrala en cada transacción, guárdala junto al historial del cliente, y Compelling Evidence 3.0 deja de ser una norma que no puedes usar para convertirse en un contracargo que puedes revertir.
Empezar esta semana
- Registra la IP en cada pedido. Guárdala junto a la transacción y al cliente, con una marca de tiempo, y consérvala al menos 18 meses para que esté disponible para una presentación de Compelling Evidence 3.0. No puedes puntuar (ni defender) lo que no registraste.
- Puntúa, no vetes. Pasa cada IP de checkout por una consulta y guarda la puntuación con el pedido, para poder segmentar las disputas por franja de riesgo y ajustar a partir de resultados reales.
- Empieza por el suelo del datacenter. Un ASN
hostingoconnection_type: "datacenter"en un checkout de consumo es una señal de alta confianza y con pocos falsos positivos. La puntuación general valora una IP de hosting sin más comoallow, así que escribe esto como tu propia regla de checkout sobredetection.is_hostingen lugar de esperar a que la puntuación lo detecte. - Comprueba la coincidencia de país. Compara
geo.country_codecon el país de facturación de la tarjeta. Una discrepancia junto con cualquier indicador de ocultación es un motivo sólido para pedir un paso adicional. - Envía a 3DS según la puntuación, no por defecto. Envía la porción de riesgo al desafío para obtener el traslado de responsabilidad; deja pasar a la mayoría limpia sin fricción.
- Protege a los clientes reales. Trata el CGNAT y los ISP residenciales/móviles como exonerantes. La protección contra los rechazos falsos es lo que mantiene esto rentable.
El contracargo ya te dijo de dónde venía, dos veces: en el pedido y en la disputa. Reducirlos es, sobre todo, cuestión de escuchar en ambos momentos en lugar de en ninguno.
Preguntas frecuentes
¿Cómo reduce los contracargos la detección de IP?
En dos momentos. Antes de la venta, una consulta de IP sobre el pedido marca las transacciones de mayor riesgo (una conexión de hosting/datacenter, una VPN anonimizadora o un nodo de salida de Tor, un país de facturación que no coincide con el país de la red, o una dirección ya incluida en fuentes de amenazas) para que puedas enviarlas a 3-D Secure o a revisión manual en lugar de enviar un pedido que acabará en disputa con toda seguridad. Después de la venta, cuando un cliente real presenta un contracargo por fraude amistoso sobre una compra que sí hizo, la dirección IP es uno de los "elementos de datos principales" que cita Compelling Evidence 3.0 de Visa, así que una IP registrada y coincidente te ayuda a ganar la representación. El mismo campo reduce tanto el fraude que se convierte en contracargo como el fraude amistoso que puedes revertir.
¿Con qué ratio de contracargos se mete en problemas un comercio?
Según el Visa Acquirer Monitoring Program (VAMP), que sustituyó a los antiguos programas VDMP y VFMP en abril de 2025, un comercio es "Excessive" con un ratio del 2,2% en el lanzamiento, que baja al 1,5% a partir de abril de 2026 en EE. UU., Canadá y la UE. Lo decisivo es que solo cuentan para ese ratio las transacciones sin tarjeta presente (online). El Excessive Chargeback Program de Mastercard marca a un Excessive Chargeback Merchant con un ratio del 1,5% y entre 100 y 299 contracargos, y a un High Excessive Chargeback Merchant con un 3,0% y 300 o más. Los incumplimientos sostenidos llevan a multas crecientes y, en última instancia, a la lista MATCH, que puede impedir a una empresa procesar tarjetas durante cinco años.
¿Se puede frenar un contracargo simplemente bloqueando direcciones IP de riesgo?
No. Bloquear es la herramienta equivocada y cuesta más de lo que ahorra. Una misma IP pública la comparten habitualmente muchas personas a través del NAT de nivel de operador, y muchos compradores legítimos usan una VPN, así que un bloqueo rígido de una dirección o de un rango elimina a clientes reales junto con el fraude. La IP es evidencia, no un veredicto: puntúala como una entrada ponderada más, envía solo los pedidos de riesgo realmente alto a autenticación reforzada o a revisión, y reserva los bloqueos directos para infraestructura inequívoca, como una dirección de datacenter en un checkout de consumo.
¿Elimina 3-D Secure los contracargos?
Traslada la responsabilidad en lugar de eliminar las disputas. Cuando una transacción sin tarjeta presente se autentica mediante EMV 3-D Secure, la responsabilidad por un contracargo posterior por fraude pasa, por lo general, del comercio al emisor de la tarjeta. El problema es que desafiar a todos los clientes con un paso adicional de 3DS añade fricción y hace perder ventas. Una puntuación de riesgo de IP te permite aplicar 3DS de forma selectiva: envía los pedidos de riesgo por el desafío y deja pasar los limpios sin fricción. Así obtienes la protección de responsabilidad sin penalizar a tus buenos clientes.
¿Cómo se usa la dirección IP como evidencia en un contracargo?
Compelling Evidence 3.0 de Visa, en vigor desde abril de 2023, permite a un comercio defenderse de una disputa por fraude sin tarjeta presente (código de motivo 10.4) mostrando una "huella histórica": dos transacciones anteriores no disputadas con las mismas credenciales, de entre 120 y 365 días de antigüedad, que comparten elementos de datos principales con el pedido disputado. La dirección IP es uno de esos elementos principales, y al menos una de las dos coincidencias exigidas debe ser la dirección IP o el ID/huella digital del dispositivo. Si la evidencia cumple los requisitos, la responsabilidad pasa al emisor. Eso solo funciona si registraste y guardaste la IP en cada pedido desde el principio.
¿Qué señales de IP predicen un contracargo?
Los campos con más señal son el tipo de conexión y el tipo de ASN (un checkout desde una red de hosting/datacenter no es un comprador normal), los indicadores de anonimizador (VPN, proxy público, Tor), una discrepancia entre el país de la red y el país de facturación, y las apariciones en fuentes de amenazas ponderadas por su antigüedad. El NAT de nivel de operador y un ISP residencial normal funcionan al revés: son motivos para ser más indulgente, no menos. Una buena puntuación de riesgo combina todo esto en un único número explicable con las señales exactas que se activaron, para que un pedido rechazado o desafiado pueda justificarse en lugar de adivinarse.
El equipo detrás de la API de GeoIPHub
Escrito por el equipo de GeoIPHub, las personas que crean la API de inteligencia IP de GeoIPHub y su escáner. Los borradores se preparan con ayuda de IA y el equipo los edita; los ejemplos de la API son consultas reales contra la API en producción, salvo que se indique que son ilustrativos.


