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.

O que é fraude por teste de cartão?

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.

Como funcionam os ataques de teste de cartões

Em essência, o teste de cartões explora o ambiente de transações sem a presença física do cartão (CNP) em pagamentos online, aplicativos móveis, formulários de doação e serviços de assinatura. Essa sobreposição com a fraude em transações sem a presença física do cartão é exatamente o motivo pelo qual ferramentas de verificação presencial, como leitores de chip ou assinaturas, não oferecem proteção nesse contexto. Como essas transações não exigem o cartão físico, os fraudadores podem automatizar o processo em grande escala usando bots, scripts ou plataformas especializadas de “teste de cartões como serviço”. Uma única campanha pode envolver milhares de tentativas por minuto em vários sites do tipo “ Lojista ”.

Aqui está o fluxo de trabalho típico para testes de cartões, dividido em quatro etapas:

Etapa 1: Aquisição: Os fraudadores obtêm dados de cartões por meio de diversos canais, incluindo violações de dados em grande escala, phishing e engenharia social, malware e programas de roubo de informações, skimming ou ataques de apropriação de contas.

Etapa 2: Validação: Ferramentas automatizadas enviam microtransações ou testes de autorização para avaliar elementos-chave como:

1. Se a combinação de número do cartão, data de validade e CVV é aceita.
2. Se as verificações do Sistema de Verificação de Endereço (AVS) forem aprovadas (ou puderem ser ignoradas).
3. Crédito disponível ou limites de gastos.

Etapa 3: Monetização: Os cartões confirmados como “ativos” são utilizados para compras fraudulentas de alto valor no mesmo site ou em outros sites, convertidos em cartões-presente/instrumentos pré-pagos ou vendidos com lucro em mercados clandestinos.

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.

O uso fraudulento de cartões é deliberadamente discreto. Pequenos débitos muitas vezes passam despercebidos pelos titulares (que podem considerá-los como taxas ou assinaturas de pouca importância), e muitas regras tradicionais de detecção de fraudes são configuradas para sinalizar padrões de gastos suspeitos ou excepcionalmente elevados, em vez de microtentativas em alta frequência.

Sinais de alerta de atividades de teste de cartões

Os sinais de teste de cartão abaixo estão agrupados de acordo com o que revelam. É assim que eles se apresentam na prática e como as ferramentas de monitoramento devem ser configuradas para detectá-los.

Sinais de fraude com cartões de crédito observados no nível da transação

• Picos repentinos nas microtransações. Um aumento acentuado nas autorizações entre US$ 0,50 e US$ 5, ou solicitações de autorização de valor zero que aparecem em rápida sucessão. Clientes legítimos raramente realizam microcompras repetidas em um intervalo de tempo curto.
• 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.
• Authorization volume that outpaces actual sales. A widening gap between authorization requests and completed purchases, especially during off-peak hours or periods with no corresponding traffic or campaign activity.

Identidade e sinais de origem

• Vários cartões de uma única origem. Tentativas com números de cartão diferentes a partir do mesmo endereço IP, impressão digital do dispositivo ou assinatura do navegador. Um cliente legítimo não alterna entre vários cartões em um único dispositivo, o que torna esse um dos indicadores mais evidentes de testes em lote.
• 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.
• Anomalias geográficas. Transações originadas em regiões fora da sua base de clientes habitual ou a partir de endereços IP associados a VPNs ou proxies. O volume proveniente dessas fontes que não se correlacione com nenhum segmento de clientes reconhecível justifica uma análise imediata.

Sinais comportamentais

• Velocidade excessiva de transações. Dezenas de tentativas por minuto a partir de um único endereço IP, e-mail ou dispositivo, muito acima de qualquer limite que possa ser explicado pelo comportamento normal de um usuário. Os picos de velocidade são particularmente significativos no âmbito das microtransações, onde as regras básicas de detecção de fraudes, ajustadas para compras de grande valor, muitas vezes não são acionadas.
• Tentativas repetidas com pequenas variações. Os fraudadores tentam sistematicamente novamente com pequenas alterações, alternando entre valores de CVV, datas de validade ou campos de endereço, mantendo o número principal do cartão inalterado. Grupos de tentativas quase idênticas são um indício confiável da utilização de ferramentas de teste automatizadas.
• Anomalias nos padrões de comportamento. As ferramentas de análise comportamental podem sinalizar padrões de interação não humanos, como velocidades de digitação anormalmente consistentes, ausência de movimentos do mouse ou preenchimento de formulários que ocorrem mais rapidamente do que qualquer ser humano seria capaz. Esses sinais complementam os dados de transações e são cada vez mais comuns nas estruturas modernas de combate à fraude.

Como esses sinais CONECTE

Uma onda de tentativas de transações de baixo valor provenientes de um único endereço IP, resultando em altas taxas de rejeição com falhas repetidas no AVS e intervalos de BIN compartilhados, raramente é uma coincidência. Cada um desses sinais, por si só, já pode justificar uma análise mais aprofundada. Juntos, eles constituem um indicador quase certo de uma campanha ativa de teste de cartões.

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.

Como PREVENÇÃO Detectar fraudes em cartões

Os controles básicos de AVS, verificação do CVV, 3DS e limites de velocidade são requisitos mínimos. O que faz toda a diferença hoje é como você utiliza os sinais de teste de cartões antes que o ataque se concretize e com que cuidado aumenta o custo das tentativas de fraude sem prejudicar as taxas de aprovação para clientes legítimos.

Aqui estão algumas recomendações:

Trate a atividade de teste de cartões como informação preliminar

Card testing is reconnaissance. A cluster of micro-authorization failures from linked BIN ranges and shared device fingerprints signals what's coming. The same actors, with validated cards, are returning for larger purchases within hours or days. Feed those signals directly into your risk engine as temporary suppression rules to tighten thresholds for testers' BIN range, IP cluster, or device cohort before the follow-on attack lands.

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.

Customer Type Indicator (CTI) feeds that track card testing campaigns can provide indicators hours before a wave floods in. But their value depends entirely on how quickly your team can translate an indicator into a live rule. An integration that requires a ticket and a deployment cycle isn't useful.

Limite o que os invasores podem descobrir a partir das suas respostas

Cada resposta de recusa é um feedback. Mensagens genéricas que não permitem distinguir entre um CVV inválido, um cartão vencido ou uma falha no AVS obrigam os invasores a realizar mais tentativas para avaliar a qualidade de seus próprios dados. Esse atrito se agrava em grande escala.

Considere combinar isso com latência aleatória em sessões suspeitas. Os scripts de teste são otimizados para velocidade. Um atraso de dois ou quatro segundos em sessões sinalizadas prejudica a taxa de processamento sem afetar os usuários legítimos. Utilize desafios progressivos acionados especificamente por sinais de velocidade ou de ligação, e não CAPTCHAs genéricos, que prejudicam a conversão de forma indiscriminada.

Feche primeiro a área de superfície de alto risco

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.

Lidar explicitamente com o problema dos falsos positivos

Defesas agressivas bloqueiam transações legítimas. Uma regra que bloqueie um intervalo de BINs em fase de teste ativo também bloqueará titulares de cartões legítimos daquele emissor. O bloqueio por tempo limitado com expiração automática pode lidar com o aspecto das regras. No entanto, sua equipe de atendimento ao cliente também precisa ter autoridade para colocar um usuário verificado na lista de permissões em tempo real, sem passar pelo mesmo mecanismo de regras que o sinalizou. Se essa capacidade não existir, todo ataque de grande porte se torna um problema de retenção de clientes.

A biometria comportamental pode minimizar o problema dos falsos positivos ao distinguir sessões humanas das automatizadas, sem depender de dados de cartões ou de identidade. Ela não elimina os falsos positivos, e é por isso que o fluxo de escalonamento continua sendo importante de qualquer maneira. Acompanhe a taxa de falsos positivos como uma métrica de primeira linha, juntamente com as taxas de recusa.

Meça o que realmente importa

Quatro indicadores revelam se as defesas estão funcionando:

• Índice de autorização de venda. Um índice em alta indica que o volume de testes está crescendo em relação às compras efetivas, independentemente do número de transações bloqueadas.
• 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.
• Impacto da conversão nos segmentos de baixo risco. Se as taxas de fraude caírem ao mesmo tempo que a conversão legítima, o resultado líquido não é positivo.
• Time from the first signal to the live rule. If this is measured in hours, you're always responding to yesterday's attack.

A lacuna organizacional que vale a pena destacar

A resposta a testes de cartões abrange as áreas de fraude, engenharia e operações de pagamento, e, normalmente, nenhuma delas assume a responsabilidade total por ela. Os programas que respondem mais rapidamente têm um único responsável e um manual de ações pré-aprovado para padrões comuns de ataque. Não precisa ser sofisticado. É preciso que exista e que possa ser executado sob pressão, sem exigir consenso entre as equipes durante uma campanha em andamento.

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.

Ferramentas de detecção e prevenção de fraudes com cartões

A estrutura acima (consulta de sinais em tempo real, supressão de pré-autorizações, gerenciamento de falsos positivos e responsabilidade clara) descreve como uma defesa madura se apresenta na prática. A questão mais complexa é distinguir o que deve ser feito internamente ( Crie ) e em que áreas as ferramentas externas ampliam significativamente suas capacidades.

A maioria das equipes enfrenta dificuldades porque seus sistemas não conseguem interligar sinais com rapidez suficiente, agir sem sobrecarga de coordenação ou resolver falsos positivos de maneira eficaz. Qualquer ferramenta que valha a pena ser avaliada deve ser analisada à luz dessas três restrições.

Uma abordagem que se alinha a esse modelo é a “Chargeflow ” (PREVENÇÃO). É importante ser preciso ao definir em que aspectos ela se encaixa e em quais não se encaixa:

1) Eliminar gargalos de coordenação nos fluxos de trabalho de resposta

In many organizations, responding to card testing requires a chain of actions: fraud flags a pattern, engineering implements a rule, and operations monitors the impact. That delay, often measured in hours, is where testing campaigns succeed.

Um ponto de decisão que executa ações como cancelar, verificar ou aprovar em tempo real elimina essa dependência. Em vez de passar de uma equipe para outra, as regras são aplicadas imediatamente no nível da transação. O impacto prático é a redução do tempo de resposta, que é o único fator que realmente atrapalha os testes ativos.

2) Interligação de sinais de identidade entre Lojistas

A maioria das plataformas internas trata sinais como IP, impressão digital do dispositivo, e-mail e dados do cartão como entradas independentes, avaliadas por transação. Isso funciona para casos isolados de fraude, mas não para grupos coordenados que reutilizam a infraestrutura em várias Lojistas.

RedeOs sistemas de nível tentam resolver isso vinculando esses sinais a um gráfico de identidade compartilhado. Nesse modelo, um dispositivo ou padrão de comportamento associado a fraudes em outros lugares pode ser reconhecido antes que uma transação seja concluída, mesmo que o próprio cartão seja novo no seu sistema.

O que importa aqui não é a dimensão do “ Rede ”, mas a transferibilidade dos sinais de risco. Trata-se da confiabilidade com que o comportamento observado em um ambiente permite prever casos de abuso em outro, e da rapidez com que essas informações são aplicadas.

3) Resolvendo o dilema dos falsos positivos sem intervenção manual

Bloquear de forma agressiva é fácil. Recuperar clientes legítimos, não.

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.

Um modelo mais eficaz introduz uma etapa de verificação estruturada no ponto de atrito. Quando uma transação é sinalizada, o comprador confirma a titularidade por meio de um fluxo simplificado vinculado ao contexto do titular do cartão. Se projetado corretamente, isso:

• Preserva a conversão para usuários legítimos
• Gera trilhas de auditoria verificáveis para disputas
• Elimina a necessidade de substituir regras manualmente

A diferença importante, além de reduzir os falsos positivos, é criar um caminho de resolução que funcione na mesma velocidade que o mecanismo de regras.

Quando essa abordagem não se aplica

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.

Os controles nesse ponto de contato, como limitação de taxa, bloqueio no nível da sessão, ofuscação de respostas e injeção de latência, devem ser implementados no gateway ou na borda. Nenhum sistema pós-autorização pode PREVENÇÃO impedir que essas solicitações cheguem ao seu processador.

Isso cria uma separação clara de responsabilidades:

• Pré-autorização: bloquear e reduzir as tentativas de teste antes que elas cheguem ao gateway
• Pós-autorização: avaliar, vincular e tomar medidas em relação às transações que passam nas verificações iniciais

Chargeflow PREVENÇÃO funciona na segunda abordagem. É eficaz nesse contexto, mas não substitui a necessidade de fortalecer a primeira interface.

Como avaliar na prática

Uma avaliação significativa das ferramentas de prevenção contra fraudes com cartões não se baseia no número de transações bloqueadas. Tudo se resume a duas perguntas:

• A interface do sistema apresenta atores ou comportamentos interligados que faltam na sua pilha atual?
• É possível Reduza evitar falsos positivos em pedidos legítimos sem aumentar a carga de trabalho da revisão manual?

Se a resposta para ambas as perguntas for “sim”, a ferramenta está preenchendo uma lacuna real. Caso contrário, trata-se apenas de mais um painel de controle.

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.

Perguntas frequentes

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.