Card Testing Attacks: Prevent Authorization Abuse and Follow-On Chargebacks

Card testing is a payment fraud tactic where attackers submit small or zero-dollar authorization attempts against stolen or synthetic card data to find out which numbers are still live before using them for larger fraud.

The tactic persists because the supply of compromised card data keeps refreshing. Recorded Future's 2025 Annual Payment Fraud Intelligence Report counted 142 million stolen card records listed for sale on dark web marketplaces last year, a 19% decline in raw volume from 2024 but a shift toward higher-quality data: 82% of stolen card-not-present records now come bundled with matching contact details, up from 73% a year earlier. The Identity Theft Resource Center's 2025 Annual Data Breach Report documented 3,322 US data breaches affecting 278,827,933 victims, the lowest victim count since 2014 even as the number of breach events kept climbing.

For merchants, the impact is direct: a Merchant Risk Council survey found 33% of merchants experienced card testing attacks, which drive processing fees, chargeback fraud exposure, and operational strain long after the initial probe.

Most guides on this topic stop at detection. This one goes further, into what happens after a test transaction succeeds: how it turns into a real dispute, who ends up liable depending on how the transaction was authenticated, and what evidence actually holds up when the resulting chargeback lands.

¿Qué es el fraude en las pruebas de tarjetas?

Card testing fraud, also called carding or card cracking, is a systematic payment fraud technique cybercriminals use to confirm whether stolen, generated, or partially known card details are still active, authorized for use, and carry available spending power.

Rather than immediately making large purchases, which carry a higher risk of instant detection and blocking, attackers initiate a series of low-value or even zero-dollar authorization requests. Successful authorizations signal that the card is live and ready for exploitation. Failed attempts help narrow down invalid or canceled cards, refining the usable dataset for resale or additional fraud.

Cómo funcionan los ataques de suplantación de tarjetas

En esencia, las pruebas de tarjetas se aprovechan del entorno de «tarjeta no presente» (CNP) de los pagos en línea, las aplicaciones móviles, los formularios de donación y los servicios de suscripción. Este solapamiento con el fraude de «tarjeta no presente» es precisamente la razón por la que las herramientas de verificación presencial, como los lectores de chip o las firmas, no ofrecen protección en este caso. Dado que estas transacciones no requieren la tarjeta física, los estafadores pueden automatizar el proceso a gran escala utilizando bots, scripts o plataformas especializadas de «pruebas de tarjetas como servicio». Una sola campaña puede suponer miles de intentos por minuto en múltiples sitios web de comerciantes.

A continuación se describe el proceso típico de comprobación de tarjetas en cuatro pasos:

Paso 1: Obtención: Los estafadores obtienen los datos de las tarjetas a través de diversos canales, entre los que se incluyen filtraciones de datos a gran escala, phishing e ingeniería social, malware y programas de robo de información, skimming o ataques de apropiación de cuentas.

Paso 2: Validación: Las herramientas automatizadas envían microtransacciones o pruebas de autorización para comprobar elementos clave como:

1. Si se acepta la combinación de número de tarjeta, fecha de caducidad y código CVV.
2. Si se superan las comprobaciones del Sistema de Verificación de Direcciones (AVS) (o si es posible saltárselas).
3. Crédito disponible o límites de gasto.

Paso 3: Monetización: Las tarjetas «activas» confirmadas se utilizan para realizar compras fraudulentas de mayor valor en el mismo sitio web o en otros, se convierten en tarjetas regalo o instrumentos de prepago, o se venden con un recargo en mercados negros.

Step 4: Escalation: In many cases, testing serves as the gateway to broader attacks, such as making a spree of high-value purchases through compromised accounts or combining with other fraud vectors. As automated purchasing tools become more common at checkout, the same low-friction flows that make card testing profitable are also raising new AI agent chargeback liability questions about who answers for a dispute when an autonomous agent, not a human, completed the transaction.

El fraude con tarjetas pasa deliberadamente desapercibido. Los pequeños cargos suelen pasar desapercibidos para los titulares de las tarjetas (que pueden considerarlos simples comisiones o suscripciones de poca importancia), y muchas de las reglas tradicionales de detección de fraudes están diseñadas para señalar patrones de gasto inusualmente elevados o sospechosos, en lugar de los micrintentos de alta velocidad.

Señales de alerta de actividades de pruebas con tarjetas

Las señales de pruebas de tarjetas que se indican a continuación se han agrupado en función de lo que revelan. Así es como se manifiestan en la práctica y así es como deben configurarse las herramientas de supervisión para detectarlas.

Señales de fraude con tarjetas a nivel de transacción

• Picos repentinos en las microtransacciones. Un fuerte aumento de las autorizaciones de entre 0,50 y 5 dólares, o solicitudes de autorización por valor de cero dólares que se producen en rápida sucesión. Los clientes legítimos rara vez realizan microcompras repetidas en un intervalo de tiempo tan breve.
• Abnormal decline rates. An unusual surge in declines, particularly codes tied to invalid card numbers, expired credentials, AVS failures, or CVV mismatches, is a primary indicator. Attackers test large batches of compromised data, much of which is already canceled or partially known, producing a high decline-to-approval ratio by design.
• Un volumen de autorizaciones que supera las ventas reales. Una brecha cada vez mayor entre las solicitudes de autorización y las compras realizadas, especialmente durante las horas de menor actividad o en períodos en los que no hay tráfico ni campañas correspondientes.

Señales de identidad y de origen

• Varias tarjetas de un mismo emisor. Se han intentado números de tarjeta diferentes desde la misma dirección IP, huella digital del dispositivo o firma del navegador. Un cliente legítimo no suele alternar entre numerosas tarjetas en un mismo dispositivo, lo que convierte a este en uno de los indicadores más claros de pruebas por lotes.
• Suspicious or inconsistent customer data. Generic or disposable email addresses, billing information that doesn't align with the card issuer's records, and mismatched billing and shipping addresses. Watch especially for repeated attempts sharing the same Bank Identification Number (BIN) range, a strong sign that cards came from the same breach or dataset.
• Anomalías geográficas. Transacciones procedentes de regiones ajenas a su base de clientes habitual, o de direcciones IP asociadas a redes VPN o servidores proxy. El volumen procedente de estas fuentes que no se corresponda con ningún segmento de clientes reconocible debe ser objeto de una revisión inmediata.

Señales conductuales

• Velocidad de transacción excesiva. Docenas de intentos por minuto desde una misma dirección IP, dirección de correo electrónico o dispositivo, muy por encima de cualquier umbral que pueda explicarse por el comportamiento normal de un usuario. Los picos de velocidad son especialmente significativos en el ámbito de las microtransacciones, donde las reglas básicas de detección de fraudes, diseñadas para compras de gran cuantía, a menudo no se activan.
• Intentos repetidos con ligeras variaciones. Los estafadores vuelven a intentarlo sistemáticamente con pequeños cambios, probando diferentes valores del CVV, fechas de caducidad o campos de dirección, mientras mantienen constante el número principal de la tarjeta. Los grupos de intentos casi idénticos son un indicio claro de que se trata de herramientas de prueba automatizadas.
• Anomalías en los patrones de comportamiento. Las herramientas de análisis de comportamiento pueden detectar patrones de interacción no humanos, como velocidades de escritura anormalmente constantes, ausencia de movimientos del ratón o cumplimentación de formularios a una velocidad superior a la que podría alcanzar cualquier persona. Estas señales complementan los datos de las transacciones y son cada vez más habituales en los sistemas modernos de detección de fraudes.

Cómo se relacionan estas señales

Una oleada de intentos de pago con importes bajos procedentes de una única dirección IP, que genera un elevado número de rechazos con fallos repetidos en el sistema AVS y rangos de BIN compartidos, rara vez es una coincidencia. Cada uno de estos indicios por sí solo podría justificar un análisis más detallado. En conjunto, constituyen un indicador casi seguro de que se está llevando a cabo una campaña activa de pruebas con tarjetas.

Early detection depends on tools that analyze linked patterns, not just individual transactions, across IP, device, email, and behavioral data in real-time. Most modern fraud platforms flag these combinations automatically, which lets merchants act before a testing probe escalates into high-value fraud or chargebacks.

From Test Transaction to Chargeback: How Card Testing Becomes a Dispute

Most of the attention in card testing goes to the probe itself, but not every test attempt gets caught before it converts into a real order. When a validated stolen card is used to complete an actual purchase, the merchant is no longer dealing with a fraud signal. They're dealing with a live transaction that the true cardholder never authorized.

When that cardholder reviews their statement and doesn't recognize the charge, they file a dispute, almost always coded as an unauthorized transaction or fraud claim rather than a service complaint. That puts the merchant into the standard chargeback process, on the same clock and evidence requirements as any other fraud-driven case. Understanding what a chargeback actually is and which reason code gets assigned determines what happens next, and how much room the merchant has to respond.

Fulfillment timing matters here. If a test-derived order ships before the underlying fraud is caught, whether it's physical goods, gift cards, or a digital subscription, the merchant absorbs the cost of the goods on top of the eventual chargeback and any associated fees. That's the real cost of card testing: it rarely shows up in the decline itself. It shows up two or three steps downstream, once a test attempt slips through.

Liability by Channel and Authentication State

Whether the merchant or the issuer ultimately absorbs the loss on a card-testing-driven purchase depends heavily on the channel and how the transaction was authenticated, not simply on whether the underlying card turned out to be stolen.

The overwhelming majority of card testing today happens in card-not-present environments, which means EMV chip protections never enter the picture. Liability instead runs through whatever authentication was applied at checkout, most commonly 3D Secure. For the full mechanics of how that determination gets made, see Chargeflow's guide to the EMV liability shift. The short version for card testing specifically: if 3D Secure was triggered and completed successfully, liability for a resulting fraud dispute typically shifts to the issuer. If it wasn't triggered, was skipped, or failed, the merchant stays on the hook regardless of how convincingly the card had been "validated" through prior testing.

A merchant's payment service provider applies these liability rules at the point of checkout, but the PSP doesn't make the liability determination in a dispute. That decision sits with the issuer, based on how the transaction was authenticated, not on whether the payment was approved.

Cómo prevención el fraude en las pruebas prevención

Los controles básicos de AVS, la aplicación de CVV, 3DS y los límites de velocidad son requisitos imprescindibles. Lo que marca la diferencia hoy en día es cómo se utilizan las señales de detección de tarjetas fraudulentas antes de que el ataque se materialice, y con qué grado de deliberación se aumenta el coste de los intentos de suplantación sin que ello afecte a las tasas de aprobación de los clientes legítimos.

Aquí tienes algunas recomendaciones:

Considerar la actividad de comprobación de tarjetas como información de inteligencia preliminar

Las pruebas con tarjetas son una forma de reconocimiento. Una serie de fallos en microautorizaciones procedentes de rangos de BIN vinculados y huellas digitales de dispositivos compartidas es una señal de lo que está por venir. Los mismos atacantes, con tarjetas validadas, vuelven para realizar compras de mayor cuantía en cuestión de horas o días. Introduce esas señales directamente en tu motor de riesgo como reglas de supresión temporales para endurecer los umbrales del rango de BIN, el grupo de direcciones IP o la cohorte de dispositivos de los atacantes antes de que se produzca el ataque posterior.

This requires decline data that's queryable in near real time, not batched into a morning report. For teams where streaming full transaction records is cost-prohibitive, a metadata-only sidecar stream tracking IP, BIN, and timestamp achieves the same detection capability at a fraction of the infrastructure cost. Pairing that suppression logic with a chargeback alert service closes the loop faster than waiting for the dispute itself to show up days later.

Las fuentes de datos del Indicador de Tipo de Cliente (CTI) que realizan un seguimiento de las campañas de pruebas de tarjetas pueden proporcionar indicadores horas antes de que se produzca una oleada. Sin embargo, su valor depende totalmente de la rapidez con la que tu equipo pueda convertir un indicador en una regla activa. Una integración que requiera abrir un ticket y un ciclo de implementación no resulta útil.

Limita la información que los atacantes pueden obtener de tus respuestas

Cada respuesta de rechazo supone información de retroalimentación. Los mensajes genéricos que no permiten distinguir entre un CVV no válido, una tarjeta caducada o un error de AVS obligan a los atacantes a realizar más intentos para evaluar la calidad de sus propios datos. Esa resistencia se acentúa a gran escala.

Considera la posibilidad de combinar esto con una latencia aleatoria en las sesiones sospechosas. Los scripts de prueba están optimizados para la velocidad. Un retraso de dos o cuatro segundos en las sesiones marcadas como sospechosas reduce el rendimiento sin afectar a los usuarios legítimos. Utiliza pruebas de seguridad progresivas activadas específicamente por señales de velocidad o de vinculación, en lugar de un CAPTCHA generalizado, que reduce la tasa de conversión de forma indiscriminada.

Cubre primero las zonas de mayor riesgo

Guest checkout, donation forms, and save-card flows are disproportionately targeted because they require no account context and produce clean authorization signals. These endpoints require their own rule sets as part of a broader ecommerce fraud prevention program: stricter velocity caps, enforced session validation, and a regular audit of whether your response patterns unintentionally reveal the difference between successful and failed authorizations. Many do.

Abordar el problema de los falsos positivos de forma explícita

Las defensas agresivas bloquean transacciones legítimas. Una regla que bloquee un rango de BIN sometido a pruebas activas también bloqueará a los titulares legítimos de tarjetas de ese emisor. La supresión por tiempo limitado con caducidad automática puede gestionar la parte de las reglas. Sin embargo, tu equipo de atención al cliente también necesita la autoridad para incluir en la lista blanca a un usuario verificado en tiempo real, sin tener que pasar por el mismo motor de reglas que lo ha marcado. Si no se dispone de esa capacidad, cada ataque importante se convierte en un problema de retención de clientes.

La biometría conductual puede minimizar el problema de los falsos positivos al distinguir las sesiones humanas de las automatizadas sin depender de datos de tarjetas o de identidad. No elimina los falsos positivos, por lo que la vía de escalación sigue siendo importante en cualquier caso. Realiza un seguimiento de la tasa de falsos positivos como una métrica de primer orden, junto con las tasas de rechazo.

Mide lo que realmente importa

Hay cuatro indicadores que revelan si las defensas están funcionando:

• Índice de autorizaciones respecto a las ventas. Un índice al alza indica que el volumen de pruebas está aumentando en relación con las compras reales, independientemente de cuántas se bloqueen.
• Authorization fees. Payment gateways typically charge $0.02 to $0.10 per authorization attempt regardless of whether it's approved or declined. A 50,000-attempt campaign, even one fully blocked, can still generate $1,000 to $5,000 in fees before any fraud completes. Suppressing sessions before they reach the gateway is a finance argument as much as a fraud one.
• Repercusión de la conversión en los segmentos de bajo riesgo. Si las tasas de fraude disminuyen al mismo tiempo que la conversión legítima, el resultado neto no es positivo.
• Tiempo transcurrido desde la primera señal hasta la aplicación de la regla. Si se mide en horas, siempre estarás respondiendo al ataque de ayer.

La brecha organizativa que merece la pena destacar

La respuesta ante las pruebas de tarjetas abarca los ámbitos del fraude, la ingeniería y las operaciones de pago, y normalmente ninguna de estas áreas asume la responsabilidad total. Los programas que responden con mayor rapidez cuentan con un único responsable y un manual de actuación preaprobado para los patrones de ataque más habituales. No es necesario que sea sofisticado. Lo importante es que exista y que se pueda poner en práctica bajo presión, sin necesidad de alcanzar un consenso entre equipos durante una campaña en curso.

Refund, Block, or Fight: Deciding How to Respond to a Suspected Test Purchase

Once a card-testing-driven order slips through, there are three practical response paths, and picking the wrong one is expensive in a different way each time.

The representment path only works with the right paperwork already in hand, which is why the evidence you keep matters as much as the decision you make. Chargeflow's guide to chargeback representment covers the mechanics of building and submitting that evidence package.

Evidence Checklist for Card-Testing-Related Disputes

• AVS and CVV match or mismatch results at the time of authorization
• Device fingerprint, IP address, and geolocation captured at checkout
• Velocity data showing how many other cards were attempted from the same device or IP in the surrounding window
• Any 3D Secure authentication result tied to the transaction
• Fulfillment status (shipped, delivered, or digital delivery confirmation) as of the dispute filing date
• Prior account history, if the order came through a registered account rather than guest checkout

None of this is useful after the fact if it isn't captured at the moment of the transaction. Build the logging first. The representment case gets built from what's already on file, not from what you can reconstruct weeks later.

Herramientas de detección y prevención de fraudes con tarjetas

El marco anterior (consulta de señales en tiempo real, supresión de preautorizaciones, gestión de falsos positivos y claridad en la responsabilidad) describe cómo se traduce en la práctica un sistema de defensa maduro. La cuestión más difícil es decidir qué desarrollar internamente y en qué casos las herramientas externas amplían de forma significativa tus capacidades.

La mayoría de los equipos tienen dificultades porque sus sistemas no son capaces de vincular las señales con la rapidez suficiente, actuar sin retrasos debidos a la falta de coordinación o resolver los falsos positivos de forma clara. Cualquier herramienta que merezca la pena evaluar debe analizarse a la luz de esas tres limitaciones.

Un enfoque que se ajusta a este modelo es Chargeflow prevención. Es útil precisar en qué aspectos encaja y en cuáles no:

1) Eliminación de los cuellos de botella en la coordinación de los flujos de trabajo de respuesta

En muchas organizaciones, responder a las pruebas de tarjetas implica una serie de pasos: el departamento de prevención del fraude detecta un patrón, el departamento de ingeniería aplica una regla y el departamento de operaciones supervisa el impacto. Ese retraso, que a menudo se mide en horas, es precisamente donde las campañas de pruebas logran su objetivo.

Un punto de toma de decisiones que ejecuta acciones como cancelar, verificar o aprobar en tiempo real elimina esa dependencia. En lugar de tener que pasar el asunto de un equipo a otro, las reglas se aplican de inmediato a nivel de transacción. El resultado práctico es una reducción del tiempo de respuesta, que es lo único que puede interrumpir de forma fiable las pruebas en curso.

2) Vinculación de señales de identidad entre distintos comercios

La mayoría de las plataformas internas tratan señales como la IP, la huella digital del dispositivo, el correo electrónico y los datos de la tarjeta como datos independientes que se evalúan por transacción. Esto funciona en casos de fraude aislado, pero no cuando hay actores coordinados que reutilizan la misma infraestructura en varios comercios.

Los sistemas a nivel de red intentan resolver esto vinculando estas señales en un gráfico de identidad compartido. En este modelo, es posible reconocer un dispositivo o un patrón de comportamiento asociado a un uso fraudulento en otro lugar antes de que se complete una transacción, incluso si la tarjeta en sí es nueva en su sistema.

Lo importante aquí no es el tamaño de la red, sino la transferibilidad de las señales de riesgo. Se trata de hasta qué punto el comportamiento observado en un entorno permite predecir de forma fiable los abusos en otro, y de la rapidez con la que se aplica esa información.

3) Resolver el dilema de los falsos positivos sin intervención manual

Bloquear de forma agresiva es fácil. Recuperar a los clientes legítimos, no tanto.

Most teams stop at detection and leave resolution to customer support, which results in manual reviews, ticket queues, and delayed overrides. That doesn't scale during an active attack.

Un modelo más eficaz introduce una fase de verificación estructurada en el punto de fricción. Cuando se detecta una transacción sospechosa, el comprador confirma su titularidad mediante un proceso sencillo vinculado al contexto del titular de la tarjeta. Si se diseña correctamente, esto:

• Garantiza la conversión para los usuarios legítimos
• Genera registros de auditoría verificables para disputas
• Elimina la necesidad de anular manualmente las reglas

La diferencia fundamental, además de reducir los falsos positivos, es crear una vía de resolución que funcione a la misma velocidad que el motor de reglas.

Casos en los que este enfoque no es aplicable

Card testing often begins upstream, at the probe stage. Bots submit authorization attempts before any purchase is completed. This is where authorization fees accumulate and where attackers learn from gateway responses.

Los controles en este punto de contacto, como la limitación de velocidad, el bloqueo a nivel de sesión, la ofuscación de respuestas y la inyección de latencia, deben implementarse en la pasarela o en el perímetro. Ningún sistema posterior a la autorización puede prevención que prevención solicitudes lleguen a tu procesador.

Esto permite una clara separación de responsabilidades:

• Preautorización: bloquear y reducir los intentos de prueba antes de que lleguen a la pasarela
• Postautorización: evaluar, vincular y actuar sobre las transacciones que superan los controles iniciales

Chargeflow prevención funciona según el segundo enfoque. Es eficaz en ese contexto, pero no sustituye la necesidad de reforzar la primera interfaz.

Cómo evaluar en la práctica

Una evaluación significativa de las herramientas de prevención de fraudes con tarjetas no se basa en el número de transacciones bloqueadas. Todo se reduce a dos preguntas:

• ¿El sistema pone de manifiesto elementos recurrentes o comportamientos relacionados que tu pila actual no recoge?
• ¿Es posible reducir los falsos positivos en los pedidos legítimos sin aumentar la carga de trabajo que supone la revisión manual?

Si la respuesta a ambas preguntas es «sí», la herramienta está cubriendo una necesidad real. Si no es así, no es más que otro panel de control.

Card Testing Is an Economics Problem That Doesn't End at the Decline

Card testing is an operation problem with a simple economic logic: attackers probe until the cost of probing exceeds the return. Most merchants make this math too easy for fraudsters. Why? Open endpoints, specific decline feedback, slow response cycles, and no shared intelligence mean the cost of testing is effectively zero, right up until a validated card converts into an order and, weeks later, a dispute.

The programs that manage this well do two things well. They're faster and more deliberate. They treat the first signal as the incident, not the chargeback that follows weeks later, and they've resolved the organizational ambiguity before an attack forces the question. They've also accepted that the false positive problem is as real as the fraud problem, and built for both.

Card testing will continue to evolve. Infostealer-sourced data, AI-assisted enumeration, and testing-as-a-service platforms lower the barrier for attackers faster than most internal controls are updated. The defensive advantage is the speed at which your system learns and responds, end to end from the first probe through to the evidence you'd need if a resulting purchase gets disputed.

Preguntas frecuentes

What is card testing fraud?

Card testing fraud is when attackers run small or zero-dollar authorization attempts against stolen or synthetic card data to find out which card numbers are still active before using them for larger purchases or reselling the validated data.

How can I tell if my store is being hit by a card testing attack?

Watch for spikes in micro-transactions between $0.50 and $5, an abnormal surge in declines (especially AVS or CVV failures), and multiple different card numbers being attempted from the same IP address or device in a short window.

Can a card testing attack turn into a chargeback?

Yes. If a validated stolen card is used to complete an actual purchase before the fraud is caught, the real cardholder will typically dispute the charge once they notice it, putting the merchant into a standard fraud-related chargeback case.

Is card testing the same thing as carding?

Yes, carding, card cracking, and card testing all refer to the same technique: using small authorization attempts to confirm which stolen or generated card numbers are still usable.

Who is liable if a card-testing-driven purchase gets disputed?

It depends on how the transaction was authenticated, not on the fact that the underlying card was stolen. If 3D Secure was successfully completed at checkout, liability for the resulting fraud dispute generally shifts to the issuer; if it was skipped or failed, the merchant is typically the one who has to respond to and fight the dispute.

Ready to close the gap between a card testing signal and a filed dispute? See how Chargeflow automates chargeback response and recovery.