Detección de fraude en pagos: dónde encajan las señales de IP en tu stack

Pregunta a diez equipos de pagos qué detiene el fraude y oirás diez respuestas únicas distintas: reglas, machine learning, 3-D Secure, revisión manual. La respuesta honesta es un stack. Toda defensa de pagos que funciona es por capas, porque cada capa tiene un punto ciego y los atacantes apuntan a la que te saltaste. Esta guía recorre el stack de principio a fin y se centra en la capa que actúa primero y cuesta menos: la red, normalmente condensada en una puntuación de fraude de IP de 0 a 100 sobre la que puedes actuar. Bien usada, la inteligencia de IP elimina clases enteras de ataques antes de que lleguen a tu procesador de pagos, y mejora discretamente todas las capas que hay detrás.

El problema, dimensionado con honestidad

El fraude con tarjetas no se está reduciendo. The Nilson Report cifra las pérdidas mundiales por fraude con tarjetas en 33.450 millones de dólares en 2022, con una proyección de más de 43.000 millones para 2028, y en Estados Unidos las pérdidas son, de forma abrumadora, un problema de tarjeta no presente (Nilson Report). Y la asimetría de costes es brutal en ambas direcciones: cada dólar de fraude les cuesta a los comercios minoristas y de ecommerce de EE. UU. 4,61 dólares una vez contados el trabajo, la investigación y la recuperación (The Paypers), mientras que bloquear en exceso pedidos legítimos hace perder ingresos en silencio. Una defensa de pagos tiene que reducir a la vez el fraude y los falsos rechazos, que es justo para lo que sirven los sistemas graduados y por capas.

Conoce a tu atacante: las cuatro familias de ataques a pagos

El catálogo de amenazas automatizadas de OWASP da nombre a las versiones industriales (OWASP Automated Threats):

El fraude amistoso, en el que el titular real de la tarjeta disputa una compra genuina, queda fuera de esta tabla a propósito: ninguna señal de red lo ve venir, y eso ya es en sí una lección sobre el stack.

El stack, capa por capa

1. Capa de red (previa a la autorización). Puntúa la IP en cada checkout, actualización de tarjeta e intento de pago. Aquí es donde los scripts en datacenters, las sesiones anonimizadas y los orígenes de alta velocidad se filtran antes de costarte nada.
2. Capa de velocidad. Intentos por IP, por prefijo /64, por tarjeta, por cuenta y por campaña. Unos contadores baratos detectan lo que la reputación pasa por alto.
3. Capa de dispositivo y comportamiento. Las huellas digitales y el comportamiento de la sesión reconocen a los clientes recurrentes y detectan la automatización que ha sobrevivido al filtro de red. El reparto de tareas se explica en device fingerprinting frente a inteligencia de IP.
4. Capa de autenticación del emisor. Autenticación basada en riesgo de 3-D Secure, en la que el emisor aprueba sin fricción los pedidos de bajo riesgo y desafía el resto, y la responsabilidad por el fraude autenticado pasa al emisor (Visa sobre 3-D Secure).
5. Capa de revisión y evidencias. Colas de revisión manual para lo genuinamente ambiguo y evidencias registradas para las disputas que defiendas más adelante, como se explica en reducir contracargos con la detección de IP.

El orden importa porque el coste aumenta con la profundidad. Una consulta de IP son milisegundos y fracciones de céntimo. Un desafío 3-D Secure cuesta conversión. Una revisión manual cuesta minutos de un analista humano. Un contracargo cuesta la mercancía, las comisiones y tu ratio de disputas. Cada ataque que detienes en la capa uno nunca te pasa factura en la capa cinco.

Lo que aporta la capa de IP antes de la autorización

Honestidad de la infraestructura. Los clientes reales pagan desde conexiones residenciales y móviles. Un checkout desde un rango de datacenter o hosting es automatización mientras no se demuestre lo contrario, y el tipo de conexión junto con el tipo de ASN es el filtro de primera pasada más barato que puedes ejecutar.

Anonimización en el paso de pago. Los indicadores de VPN y proxy durante la navegación son, por sí solos, una evidencia débil. Esos mismos indicadores apareciendo justo en el paso de introducir la tarjeta, o un nodo de salida de Tor en el checkout, merecen fricción. La mecánica de detección está en cómo funciona la detección de VPN y proxy.

Coherencia geográfica. Normalmente deberían coincidir tres países: la ubicación de la IP, el país emisor del BIN de la tarjeta y la dirección de envío o facturación. Una discrepancia es un viajero o una VPN. Que los tres discrepen en un primer pedido con envío urgente es un patrón que merece un desafío.

Velocidad calculada sobre la clave correcta. El card testing lanza cientos de intentos por origen. Calcula tus contadores sobre la IP y, en IPv6, sobre el prefijo /64 en lugar de la dirección completa, o una sola red de fraude parecerá miles de usuarios (limitar la tasa de IPv6 por /64).

Los amortiguadores. El NAT de operador (CGNAT) agrupa a miles de clientes legítimos detrás de una sola dirección, y el 42 % de los adultos de EE. UU. afirmó usar una VPN en la encuesta de Security.org de agosto de 2026 a 1.008 personas. Un indicador de CGNAT debería suavizar tu respuesta ante la velocidad en IPs compartidas, no endurecerla.

Un nodo de salida de Tor y un relay de iCloud en el mismo checkout

La misma pregunta sobre anonimización recibe respuestas opuestas según lo que sea realmente la IP. Consultamos un nodo de salida de Tor y una IP de salida de iCloud Private Relay el 5 de octubre de 2026 (los resultados cambian a medida que se mueven los rangos):

El nodo de salida de Tor obtiene 100 con recommended_action: "block", y detection_methods muestra por qué: tor_exit más rdns_tor por su DNS inverso, sobre infraestructura de hosting. Esa es la franja de riesgo corroborado que detienes antes de la autorización. El relay obtiene 9 y allow, porque is_relay: true con relay_provider: "iCloud Private Relay" es un cliente de Apple usando una función de privacidad integrada, no un proxy. Fíjate en el país del lado de la IP, Angola: la salida de un relay puede estar lejos del titular de la tarjeta, así que una discrepancia entre el país del BIN y el de la IP en una IP de relay es una evidencia débil y no debería llevar el pedido, por sí sola, a la franja de bloqueo.

El card testing merece su propio párrafo

El card testing afecta a aproximadamente un tercio de los comercios de ecommerce en todo el mundo (estadísticas de card testing), y es el ejemplo más puro de un ataque que la capa de IP debería eliminar sin más. Los bots validan tarjetas robadas con pequeñas autorizaciones, tú pagas las comisiones de autorización y de rechazo en cualquier caso, y cada tarjeta que validan se convierte en fraude real en otro sitio. El perfil del tráfico es inconfundible: orígenes de datacenter y proxy, ritmos de intentos a velocidad de máquina, importes mínimos o de cero dólares. Puntúa la IP antes de que la petición llegue a tu procesador, limita la tasa por dirección y por prefijo, y rechaza o aísla discretamente lo que no pase. Detener el card testing en el borde de la red es el control de fraude con mayor retorno que la mayoría de los equipos de pagos aún no ha desplegado del todo.

Alimenta al emisor, no luches contra él

3-D Secure no es un rival de tu propia detección; es una capa que funciona con señales. El emisor decide entre sin fricción o desafío según el panorama de riesgo que puede ver, y tú decides qué pedidos envías a ese flujo. El patrón que funciona replica los umbrales de puntuación de fraude por acción: permite la franja limpia sin fricción, envía la franja media a un desafío 3-D Secure para que la responsabilidad por el fraude autenticado pase al emisor, y bloquea la franja de riesgo corroborado antes de la autorización para que nunca afecte a tu tasa de aprobación. La inteligencia de IP es lo que clasifica esas franjas de forma barata y explicable.

Lo que la capa de IP no puede ver

Sé preciso con los puntos ciegos, porque definen el resto del stack. La IP no puede ver el fraude amistoso, en el que el titular legítimo, desde su red doméstica habitual, disputa una compra que sí hizo. No puede señalar una tarjeta robada usada desde el propio barrio de la víctima. No puede distinguir a dos clientes detrás de una misma dirección CGNAT sin ayuda. Esas carencias son la razón de que existan el reconocimiento de dispositivos, la autenticación del emisor y la revisión posterior a la transacción, y de que la puntuación de riesgo de IP esté diseñada para ser una entrada explicable en una decisión, no la decisión en sí.

Una consulta por intento de pago

Una consulta por intento de pago devuelve el panorama previo a la autorización: connection_type y asn_type separan a los clientes residenciales y móviles de los scripts en datacenters y hosting; el bloque de detección señala salidas de VPN, proxy, Tor y relay con el proxy_type y el anonymity_level detrás de cada indicador; el bloque geo te da el país del lado de la IP para las comprobaciones de coherencia con el BIN y la dirección, con un geo_confidence para que sepas cuánto apoyarte en él; is_cgnat marca las direcciones compartidas de operador para que amortigües en lugar de rechazar; y la puntuación de fraude explicable de 0 a 100 llega con un recommended_action (allow, review, step-up o block) que se corresponde directamente con las franjas sin fricción, desafío y bloqueo de tu enrutamiento 3-D Secure. Todos los campos están incluidos en el plan gratuito con 1.500 consultas al día, y puedes comprobar la puntuación de fraude de cualquier IP sin clave de API antes de integrarla en tu flujo de pago.

Empieza el stack de detección de fraude en pagos por la red

Este artículo es el mapa; las guías vecinas son el terreno. Las cifras de los umbrales están en la guía de umbrales por acción enlazada arriba, la puerta de la seguridad de cuentas se trata en detectar la toma de cuentas y el credential stuffing, la recompensa en el lado de las disputas en la guía de contracargos de la lista del stack, y la integración en diez minutos en añadir detección de fraude por IP con una API gratuita. Construye primero la capa de red. Es la única capa que sale más barata cuanto antes se ejecuta.

Preguntas frecuentes

¿Qué es la detección de fraude en pagos?

La detección de fraude en pagos es el conjunto de comprobaciones que una empresa ejecuta antes, durante y después de una transacción para detectar pagos no autorizados o engañosos: uso de tarjetas robadas, card testing, toma de cuentas en el checkout y fraude amistoso. Los sistemas maduros son por capas, no monolíticos. Las comprobaciones de red e IP se ejecutan primero, las señales de velocidad y de dispositivo corroboran, la autenticación del emisor como 3-D Secure se encarga de la franja de riesgo medio, y la revisión posterior a la transacción junto con las evidencias para contracargos cierra el ciclo.

¿Qué señales de IP importan más en el checkout?

Cuatro familias hacen la mayor parte del trabajo: el tipo de conexión y el tipo de ASN (un checkout de consumidor desde un rango de datacenter o hosting es un script mientras no se demuestre lo contrario), los indicadores de anonimización (VPN, proxy o Tor en el paso de pago), la coherencia geográfica (país de la IP frente a país del BIN de la tarjeta frente a dirección de envío) y la velocidad calculada sobre la IP y su prefijo IPv6 /64 (muchos intentos con tarjetas desde un mismo origen es card testing). Cada una necesita contexto, ya que el NAT de operador (CGNAT) y el uso habitual de VPN son normales.

¿Qué es el card testing y cómo lo detengo?

El card testing (OWASP OAT-001 Carding) son bots que lanzan pequeñas autorizaciones con lotes de números de tarjeta robados para averiguar qué tarjetas siguen activas. Cada intento te cuesta comisiones de autorización, y cada acierto se convierte después en fraude real en algún otro sitio. Es el ataque de pagos que más se resuelve con la IP: los bots operan desde rangos de datacenter y pools de proxies a un ritmo que ningún humano alcanza, así que puntuar la IP y limitar la tasa por dirección y por prefijo /64 antes de que la petición llegue a tu procesador elimina la mayor parte.

¿3-D Secure sustituye a la detección de fraude?

No. 3-D Secure es una capa de autenticación que traslada la responsabilidad por fraude al emisor de la tarjeta en las transacciones autenticadas, y su flujo basado en riesgo funciona mejor cuando recibe señales ricas. Si desafías todo, pierdes conversiones; si no desafías nada, te quedas con la responsabilidad. El patrón práctico es usar tu propia puntuación de riesgo, incluida la inteligencia de IP, para decidir qué transacciones enviar a un desafío 3-D Secure, cuáles permitir sin fricción y cuáles bloquear antes incluso de la autorización.

¿Debo bloquear a los usuarios de VPN en el checkout?

No de forma automática. Aproximadamente uno de cada cuatro usuarios de internet usa una VPN, sobre todo por privacidad legítima, así que un bloqueo estricto ante cualquier indicador de VPN rechaza ingresos reales. Trata un indicador de VPN corriente como motivo para añadir verificación, por ejemplo enviando el pedido a un desafío 3-D Secure, y reserva los bloqueos estrictos para casos corroborados como nodos de salida de Tor o IPs con abuso conocido combinados con otras señales de riesgo, como una discrepancia geográfica o una velocidad alta.