Card testing: qué le pasa realmente a tu checkout antes de que llegue el primer contracargo

Un pico de rechazos que todavía no es un contracargo

Una mañana tu panel de pagos muestra algo raro: decenas de registros nuevos en la última hora, cada uno añadiendo una tarjeta y probando un cargo pequeño, la mayoría rechazados. Nadie ha llamado para quejarse. No ha llegado ninguna disputa. Si lo revisas la semana siguiente, puede que todavía no haya ni una. Es tentador leer esto como nada, un problema de bots para tu bandeja de soporte en lugar de un problema de pagos para tu cuenta de comercio. Esa lectura es errónea, y para cuando produce un contracargo que puedas señalar, el daño que más importa ya se ha hecho en otro sitio.

Lo que estás viendo es card testing: alguien hace pasar un lote de números de tarjeta robados o adivinados por tu checkout, o por tu formulario de "añadir una tarjeta", para averiguar cuáles siguen funcionando. Tu sitio no es el objetivo. Es la herramienta. El estafador no quiere nada de lo que vendes; quiere que tu formulario de pago le diga, gratis, cuál de los números de una lista que compró es una tarjeta viva y cuál es plástico muerto.

Esto importa especialmente a quien gestiona un directorio de anuncios para adultos, porque los consejos escritos para comercios en línea suelen suponer un minorista genérico con un procesador genérico. Tu cuenta casi seguro pasa por una pasarela de alto riesgo, con sus propios términos de reserva y su propia tolerancia, más estrecha, justo para el tipo de pico de rechazos que produce un ataque de testing. El mecanismo es el mismo en todas partes; lo que te cuesta no lo es.

Este texto trata de ese mecanismo: cómo funciona el testing, qué cuesta realmente antes de que exista una sola disputa, por qué una cuenta de alto riesgo absorbe el mismo ataque peor que una cuenta estándar, y qué cambiar en tu checkout esta semana en lugar de después del próximo ataque.

Nada de esto exige que te conviertas en analista antifraude. Exige saber qué es realmente el pico en tu panel, para dejar de tratarlo como ruido de fondo.

Qué es realmente el card testing, y por qué un checkout como el tuyo resulta cómodo

Un estafador que compra o recopila un lote de números de tarjeta tiene un problema antes incluso de tener una oportunidad: la mayoría de esos números ya están muertos, cancelados o reportados. Probarlos uno por uno con una compra real sería lento y quemaría comercios legítimos rápido, porque una compra rechazada es el tipo de cosa que un titular nota y un banco marca. Así que el estafador busca una forma más barata y silenciosa de hacer la misma pregunta: ¿sigue viva esta tarjeta?

La forma silenciosa es vincular una tarjeta a una cuenta, o ejecutar una verificación de autorización, en lugar de completar una compra. La propia documentación de Stripe dice que los estafadores prefieren esta vía porque las verificaciones implicadas normalmente no aparecen en el extracto del titular, así que el titular real no tiene un motivo evidente para notarlo y reportarlo. Cuando esa vía no está disponible, una compra pequeña, un dólar o dos, es el recurso de respaldo, elegido porque sigue siendo lo bastante pequeña como para pasar inadvertida en un extracto lleno de cargos reales.

En cualquier caso, la solicitud tiene que llegar a algún sitio, y a un script no le importa qué venda ese sitio. Le importa si el formulario es fácil de alcanzar y si algo se interpone entre un número de tarjeta enviado y una respuesta. Un flujo de registro que deja a un visitante crear una cuenta y vincular una tarjeta sin un muro de inicio de sesión, un CAPTCHA, o un límite a cuántos intentos puede hacer un visitante, es exactamente ese tipo de formulario, sea cual sea el negocio detrás.

La guía de J.P. Morgan para comercios sobre estos ataques hace explícito el patrón de selección de blanco: los estafadores buscan comercios no equipados para detectar o defenderse del ataque, usándolos a menudo como lo que la guía llama una mula, un objetivo intermedio usado solo para averiguar si una cuenta sigue activa. Un operador de anuncios pequeño o mediano con un checkout mínimo, a menudo en una pasarela de alto riesgo más barata que no incluye el CAPTCHA ni las defensas de aprendizaje automático que una plataforma como Stripe ofrece por defecto, se ajusta a esa descripción más que un gran minorista, no por lo que trate el sitio sino por lo que puede permitirse construir.

El resultado es una forma de fraude que no tiene nada que ver con tus anuncios, tu moderación, o la honestidad de tus anunciantes, y todo que ver con cuán expuesto está tu flujo de entrada de tarjeta a un script que no tiene otro sitio más productivo adonde ir.

Qué te cuesta antes de que nadie dispute nada

El instinto de esperar un contracargo antes de tratar esto como un problema es comprensible, y es el instinto equivocado. La guía de J.P. Morgan lo dice sin rodeos: no confíes en el proceso de contracargo para detectar un ataque de card testing, porque la ventana entre una transacción y una disputa es lo bastante larga como para que un sitio pueda ser golpeado varias veces antes de que alguien note que hay un problema. Para cuando llega la primera disputa, el ataque que la causó puede haber terminado ya, y un segundo puede estar ya en marcha.

El coste que llega primero no es una disputa, es una comisión. Cada solicitud de autorización que tu pasarela envía a las redes de tarjetas en tu nombre, aprobada o rechazada, es una transacción que tu adquirente procesa y suele facturar. Un script de testing que lanza cientos de intentos en una hora no te cuesta en ventas perdidas; te cuesta en tráfico de autorización que pagas sin importar el resultado, encima de cualquier comisión fija o porcentual que tu procesador ya cobra por ser una cuenta de alto riesgo.

El segundo coste es reputacional en un sentido muy literal y mecánico: Stripe describe un pico de rechazos como algo que puede, por sí solo, dañar cómo los emisores de tarjetas y las redes leen tu negocio, haciendo que cada una de tus transacciones parezca más arriesgada incluso después de que el ataque termine, lo que puede significar que las tarjetas de clientes legítimos empiecen a ser rechazadas también. La guía de Checkout.com dice lo mismo desde el lado del adquirente: una alta tasa de rechazos señala riesgo a quienes decidan cuán de cerca vigilar tu cuenta, independientemente de si esos rechazos llegan a ser alguna vez un contracargo.

El tercer coste es el que termina mostrándose realmente como una disputa. Una parte de un ataque de testing tiene éxito, porque algunos de los números son tarjetas vivas vinculadas a personas reales. Esos pequeños cargos exitosos son exactamente los que un titular acaba notando en un extracto y reportando como fraude, convirtiéndose en los contracargos que esperabas como primera señal. Para ver cómo esas disputas pesan en tu cuenta una vez que llegan, consulta qué decide realmente la proporción de contracargos de un directorio de anuncios: el ataque de testing suele ser el primer acto silencioso de un problema que solo encuentras más tarde con esa forma.

Por qué una cuenta de alto riesgo absorbe peor el mismo ataque

Los programas a nivel de red que vigilan las proporciones de disputas y fraude no son la primera línea de defensa en la que se apoya tu procesador. Por debajo de ellos está el umbral interno de tu propio adquirente, más estrecho, el que se fija él mismo precisamente porque responde ante la red si toda su cartera de comercios se acerca demasiado a la línea. Para cuando una cuenta cruzaría oficialmente un umbral que una red de tarjetas publica, el adquirente ya suele haber actuado sobre su propio número, más bajo y privado, a menudo con un aumento de reserva o una revisión manual en lugar de un aviso formal que nombre el programa.

Para una cuenta comercial de alto riesgo, ese umbral privado y anticipado es ya aquel bajo el que vives cada día; por eso la cuenta lleva precios de alto riesgo y un término de reserva que una cuenta comercial genérica no tiene. Un fin de semana de rechazos por card testing no necesita tocar ningún número que una red de tarjetas publique jamás para producir una respuesta: solo necesita mover el número que tu propio adquirente ya vigila más de cerca de lo que vigila una cuenta genérica, lo cual es por definición un umbral más bajo de superar.

La reserva en sí agrava el problema en lugar de limitarse a reflejarlo. Un procesador que reacciona a un pico de rechazos reteniendo una parte mayor de los ingresos, o reteniéndola más tiempo, está quitando capital de trabajo a un negocio que ya paga más que un comercio genérico por procesar el mismo volumen. Ese es dinero que no puedes gastar en las herramientas antifraude que habrían detenido el próximo ataque, que es exactamente la trampa en la que cae más fácilmente un operador de alto riesgo magro y corto de liquidez.

Nada de esto significa que tu cuenta sea frágil por lo que vendes. Significa que el adquirente ya vigilaba tus números más de cerca antes de que la primera transacción de prueba tocara tu checkout, y un ataque de testing es una de las formas más rápidas de mover un número que está vigilando.

Qué revisar y cambiar esta semana

Empieza por averiguar si siquiera te darías cuenta. Extrae tu tasa de rechazos del último mes y busca un patrón que J.P. Morgan señala directamente: un grupo de cuentas nuevas, creadas en una ventana corta, cada una añadiendo una tarjeta o probando un cargo de bajo valor que es rechazado, a menudo desde un rango estrecho de direcciones IP o dispositivos. Si tu panel no hace visible ese patrón de un vistazo, ese es ya el hallazgo: ahora mismo dependes de un contracargo, semanas después, para decirte algo que tu registro de rechazos ya sabe hoy.

Reembolsa de inmediato, no esperes. Si alguna de las transacciones de prueba tuvo éxito, reembolsarla en cuanto detectes el patrón, en lugar de esperar a ver si el titular se da cuenta, es lo más barato que puedes hacer, y es también el primer paso en la lista de verificación oficial de Stripe contra el card testing. Un reembolso que haces tú cuenta de forma muy distinta a una disputa que presenta el titular: el cargo nunca llega a ser un contracargo, así que nunca llega a pesar en cómo se resuelven realmente las disputas sobre tu proporción.

Activa los controles que ya existen. La verificación de dirección y la coincidencia del CVV son funciones estándar en prácticamente cualquier pasarela, y a menudo se dejan en un ajuste permisivo porque endurecerlas puede rechazar a algún cliente legítimo junto con los bots. Para un negocio que ya absorbe precios de alto riesgo, esa concesión suele valer la pena hacerla deliberadamente en lugar de dejarla en un ajuste predeterminado que nadie eligió de verdad.

Pon fricción específicamente en la creación de cuentas y la entrada de tarjetas, no solo en el checkout. El verdadero objetivo de un script de testing es tu flujo de registro y añadir tarjeta, no tu página de compra, así que un CAPTCHA y un límite estricto a cuántas cuentas o tarjetas puede crear una dirección IP en un día deben ir ahí primero. Pregunta directamente a tu pasarela qué herramientas de velocidad y límite de frecuencia incluye tu plan específico, porque los proveedores de alto riesgo varían enormemente en esto, y los más baratos a menudo venden la cuenta sin las defensas que una pasarela genérica incluye por defecto.

Por último, deja de decirle a los clientes rechazados por qué fueron rechazados. Exponer un motivo específico, un CVV incorrecto, una dirección que no coincide, le da a un script de testing exactamente la pieza que le falta de un registro de tarjeta robado para afinar el siguiente intento. Un mensaje de rechazo genérico no le cuesta nada a un cliente real, que de todos modos puede llamar al soporte, y le cuesta al estafador la única información que hace su siguiente intento más preciso que el anterior.