Resumen: prevención de card testing con velocidad pre-autorización
- Las reglas de velocidad por IP se diseñaron para un estafador perezoso con una IP estática. El card testing distribuido se reparte entre IPs rotatorias y montos pequeños, así cada intento individual queda por debajo del umbral y los ML transaccionales los puntúan uno a uno.
- cside lee movimiento del cursor, ritmo de rellenado de formularios, cadencia de sesión y firmas de agentes de IA en el checkout antes de que se envíe la autorización, así una sesión de card testing bloqueada produce cero exposición a chargebacks. Las credenciales robadas aparecieron en el 39% de las brechas según Verizon DBIR 2026, y el stack conecta directo con la exportación CE 3.0 si algo se cuela.
- Si usas Stripe Radar y solo ves una puntuación post-autorización, añade detección de sesión pre-autorización. Si tu checkout es realmente de bajo volumen y sin riesgo de automatización, quédate con reglas de velocidad.
El software de prevención de fraude por card testing detiene los intentos automatizados de validar números de tarjeta robados antes de que se complete ningún cargo. Las tandas de testing las impulsan scripts y agentes IA, así que la señal que los delata vive en el comportamiento de la sesión de checkout: tiempos mecánicos, ausencia de movimiento del cursor y firmas de agentes IA que la detección en la capa del navegador lee antes de que se dispare el cargo.
El fraude por card testing es la práctica de ejecutar transacciones automatizadas a través del checkout de un comercio para validar si los números de tarjeta robados están activos antes de usarlos para compras de mayor importe. El atacante tiene una lista de números de tarjeta robados y no sabe cuáles siguen activos. Ejecuta pequeñas transacciones (a menudo de $0.00 o $1.00) para probar cada tarjeta contra un procesador de pago real. El comercio absorbe el volumen de contracargos de los rechazos, y las tarjetas que pasan se convierten en munición para fraudes mayores.
El card testing causa daño de dos formas distintas. El daño directo es el volumen de contracargos y las comisiones del procesador que generan las transacciones de prueba fallidas. El daño indirecto es que cada tarjeta validada se usa después para compras de mayor importe en otros sitios, contribuyendo al ecosistema de fraude más amplio. El Verizon DBIR 2026 halló que las credenciales robadas aparecen en el 39% de todas las brechas de datos, y los datos de tarjetas robadas de esas brechas alimentan las operaciones de card testing a escala.
| Herramienta | Capa de detección | Detecta card testing por agentes IA | Detecta antes de que se dispare la transacción | Evidencia de contracargos | Nivel gratuito |
|---|---|---|---|---|---|
| cside | Navegador (comportamiento de sesión + device fingerprint) | Sí | Sí | Sí (exportación CE 3.0) | Sí (1,000 llamadas API/mes) |
| Stripe Radar | ML de transacciones (post-autorización) | Limitado | No (puntúa tras la transacción) | Sin evidencia de sesión | No (solo clientes de Stripe) |
| Reglas de velocidad | Limitación de tasa de peticiones | No (el testing distribuido las evade) | Parcial | No | Varía |
Por qué las herramientas de la capa de transacción no detectan el card testing distribuido
Los sistemas de puntuación de fraude basados en transacciones, como Stripe Radar, evalúan el riesgo de transacciones individuales usando machine learning entrenado con datos históricos de pagos. Son eficaces para marcar transacciones sospechosas individuales según los patrones de comportamiento de la tarjeta.
La limitación para el card testing en concreto es el tiempo y la distribución. Las operaciones modernas de card testing distribuyen las pruebas entre muchas tarjetas, muchos importes pequeños y, a veces, muchas cuentas de comercio a la vez. Las transacciones de prueba individuales parecen normales porque el importe es pequeño, la tarjeta es real (solo que puede estar robada) y la operación es lo bastante lenta como para mantenerse por debajo de los umbrales de velocidad. El patrón solo es visible cuando agregas muchas sesiones a lo largo del tiempo, lo que requiere datos a nivel de sesión que las herramientas de la capa de transacción no recopilan.
Las reglas de velocidad (límites de tasa sobre la frecuencia de transacciones por IP o por tarjeta) se evaden rotando IPs y repartiendo las pruebas en el tiempo. Las operaciones de card testing distribuido están diseñadas específicamente para mantenerse por debajo de los umbrales que imponen las reglas de velocidad.
cside: detección de card testing en la capa del navegador
El card testing lo llevan a cabo scripts y agentes IA en lugar de humanos, y esa distinción se manifiesta en la propia sesión de checkout, antes de que se dispare cualquier transacción.
La detección de card testing de cside recopila señales de la capa del navegador durante la sesión de checkout: el movimiento del cursor (o su ausencia), el tiempo entre eventos de rellenado de formularios, la cadencia de sesión, las firmas de agentes IA y las características del device fingerprint. Un comprador humano que navega por un formulario de checkout mueve el cursor, hace una pausa antes de confirmar el pago y rellena los campos con una variación de tiempo natural. Un script automatizado de card testing rellena los campos a intervalos calculados, mueve el cursor en líneas rectas o no lo mueve en absoluto y completa el checkout a una velocidad mecánicamente constante sin importar la complejidad del formulario.
La API devuelve un veredicto de riesgo en tiempo real antes de que se envíe la autorización del pago. Tu flujo de checkout usa esta señal para bloquear la sesión, inyectar un desafío CAPTCHA o marcar la transacción para revisión manual. Una sesión de card testing que se bloquea antes de la autorización produce cero responsabilidad por contracargos. La evidencia de sesión (device fingerprint, un veredicto de agente IA, una puntuación de comportamiento de sesión) está disponible para exportar en formato Visa Compelling Evidence 3.0 si alguna transacción de prueba llega a completarse y genera una disputa.
Stripe Radar
Stripe Radar es un sistema de puntuación de fraude con machine learning disponible para los clientes de Stripe. Evalúa el riesgo de la transacción según el comportamiento de la tarjeta, la velocidad y los patrones a través de la red de Stripe.
Para la prevención del card testing, Stripe Radar aporta una señal útil sobre transacciones sospechosas individuales, pero actúa después de que se inicia la autorización del pago. No recopila señales de la sesión del navegador antes de que se dispare la transacción, y no detecta las características de agente IA o de automatización que identifican una sesión como card testing antes de que se intente ningún cargo. Las organizaciones que usan Stripe Radar para prevenir el card testing operan con un modelo de respuesta a posteriori en lugar de un bloqueo previo a la autorización.
Checklist del comprador
- ¿Detecta las sesiones de testing antes de la autorización? La detección previa a la autorización es la única forma de lograr cero responsabilidad por contracargos en las transacciones de prueba.
- ¿Detecta el testing impulsado por agentes IA? El card testing moderno usa cada vez más agentes IA que superan el CAPTCHA y parecen humanos en la capa de red.
- ¿Funciona con operaciones de testing distribuido? La detección de sesión única que no puede agregar device fingerprints entre sesiones se perderá los ataques coordinados.
- ¿Produce evidencia utilizable en disputas? Cuando las transacciones de prueba se completan, la evidencia en formato CE 3.0 determina si la disputa se puede ganar.
- ¿Se integra a nivel de la página de checkout? La integración del lado del servidor en la capa de transacción se pierde las señales de sesión que identifican las operaciones de testing.
