Teste de cartão de crédito é a prática em que alguém usa um checkout para descobrir quais dados de cartão roubados ainda funcionam, sem interesse no produto que está sendo vendido. O mercado também chama isso de carding, enumeração ou validação de cartão. A tentativa de compra existe, mas a intenção de compra não. O objetivo é a resposta da transação, não o produto. Para quem vende, o efeito aparece como uma sequência de tentativas de pagamento recusadas, em geral de valor baixo, feitas em um espaço de tempo pequeno e com dados de contato sem sentido. Uma tentativa bloqueada nesse cenário não é a mesma coisa que uma venda perdida. Ela é a recusa de uma transação que nunca teria se tornado uma venda, e que, se tivesse passado, voltaria depois como contestação.
Entre as três e as quatro da manhã, o checkout registra trinta tentativas de pagamento de valores baixos, quase todas recusadas, com nomes e e-mails que não se parecem com nada.
Pela manhã, o painel mostra uma fila de transações canceladas e a leitura imediata é de que alguma coisa deixou de funcionar.
Normalmente, o que aconteceu foi o contrário. Nenhuma daquelas tentativas vinha de alguém que queria comprar.
Esse comportamento já foi medido em condições controladas.
Uma equipe da Universidade de Newcastle, no Reino Unido, analisou como as páginas de pagamento dos maiores sites comerciais do mundo tratam a validação de cartão e publicou o resultado na revista IEEE Security & Privacy.
Mohammed Ali, autor principal do estudo, resumiu em uma frase por que o problema não está em nenhum checkout isolado:
Neste artigo, explicamos o que é o teste de cartão de crédito e como reconhecer os sinais no seu checkout.
Além disso, tratamos sobre como separar um bloqueio de segurança de uma recusa do banco, o que a prática custa para quem vende e por que o período de Black Friday concentra esse tipo de tentativa.
Acompanhe!
O teste de cartão de crédito é a tentativa de validar dados de cartão obtidos de forma ilícita, usando um checkout real como ferramenta de verificação.
Quem conduz o teste já tem uma lista de números de cartão, comprada ou obtida em vazamentos, e não sabe quais ainda estão ativos.
O checkout entra nessa operação porque é o único lugar onde a pergunta pode ser feita. A resposta de uma transação, aprovada ou recusada, é a informação que estava faltando.
Por isso, a escolha e a configuração do checkout também são importantes para prevenir esse tipo de fraude. Quem está estruturando uma operação de vendas pode entender melhor como criar um checkout de pagamento online e quais recursos considerar desde o início.
Daí vem a característica que mais confunde quem vende: a tentativa é real, o pagamento é real e o pedido é real, mas o interesse pelo produto não existe.
Nenhuma métrica de intenção de compra captura essa realidade, porque do lado de fora o comportamento se parece com uma compra que não deu certo.
Duas distinções ajudam a não misturar as coisas:
Um ataque de teste de cartões acontece em três etapas: obtenção dos dados, validação em estabelecimentos reais e monetização dos cartões confirmados.
Para quem vende, a etapa mais importante é a validação, pois é nela que as tentativas aparecem no checkout. E elas podem passar despercebidas porque costumam ser distribuídas entre diferentes operações.
O estudo da Universidade de Newcastle analisou as páginas de pagamento de 389 dos 400 maiores sites comerciais mais visitados do ranking Alexa. Os pesquisadores avaliaram quantos campos cada site exigia para autorizar uma compra e quantas tentativas incorretas permitia antes de impedir novas tentativas.
O estudo mostrou que 276 sites permitiam de seis a dez tentativas. Cada um exigia de dois a quatro campos de dados, em combinações diferentes.
Com essa variação, os pesquisadores estimaram que seria possível descobrir os dados que faltavam de um cartão com cerca de mil tentativas. Se todos os sites exigissem os mesmos campos, seriam necessárias dezenas de milhares.
Por isso, as tentativas são distribuídas entre vários sites. Como cada checkout permite poucas verificações, os criminosos fazem apenas algumas em cada operação.
Segundo os autores, essa estratégia funciona porque a rede de pagamentos não consegue identificar que as tentativas feitas em sites diferentes estão relacionadas ao mesmo cartão.
Por isso, dez tentativas recusadas no checkout não descartam um ataque. Pelo contrário: esse volume reduzido é compatível com a forma como ele costuma acontecer. Esperar milhares de tentativas para suspeitar de fraude pode significar deixar passar os primeiros sinais.
O estudo também apontou que apenas 12% dos sites analisados utilizavam autenticação adicional no pagamento, reforçando a importância de validar os dados na entrada do checkout.
As tentativas suspeitas de teste de cartões no checkout aparecem como um conjunto de sinais que acontecem juntos, e é a combinação que importa, não cada sinal isolado.
| Sinal | O que ele costuma indicar |
|---|---|
| Pico de tentativas em poucos minutos | Automação, porque uma pessoa não preenche o checkout nesse ritmo |
| Vários cartões diferentes na mesma sessão ou no mesmo dispositivo | Lista de números sendo verificada, e não um comprador com dificuldade |
| Valores baixos, próximos do mínimo que o checkout aceita | Tentativa de passar sem que o titular perceba no extrato |
| Taxa de recusa muito acima da média da operação | Dados inválidos em série, e não problema de limite dos compradores |
| Nomes, e-mails e telefones sem coerência entre si | Preenchimento gerado, não digitado |
| Concentração fora do horário comercial, sobretudo de madrugada | Janela em que ninguém da operação está acompanhando |
| Tentativas repetidas em que só um campo muda | Verificação de campo por campo, e não erro de digitação |
Nenhum desses sinais, isoladamente, confirma um ataque. Um cliente pode digitar o número errado, uma campanha pode concentrar compras em pouco tempo e produtos de entrada naturalmente têm ticket baixo.
A suspeita aumenta quando vários sinais aparecem juntos. Por isso, antes de alterar as configurações do checkout, é importante analisar o conjunto.
Bloqueios de segurança, recusas do banco e erros técnicos aparecem como tentativas que não geraram vendas. Mas têm causas diferentes e exigem respostas distintas.
Confundir essas situações pode levar o vendedor a interpretar uma proteção como falha ou uma falha como proteção.
| Tipo | Onde acontece | O que significa | O que fazer |
|---|---|---|---|
| Bloqueio de segurança | No checkout, antes do envio ao processador | A tentativa foi barrada por dados inconsistentes ou comportamento suspeito. Não houve cobrança. | Registrar e acompanhar se o volume aumentar. |
| Recusa do emissor | No banco que emitiu o cartão | O banco recusou a transação por limite, bloqueio, divergência de dados ou análise própria. | Verificar se há um cliente real com dificuldade para pagar. |
| Erro técnico | Na comunicação entre as partes | Uma falha impediu a conclusão da transação, como tempo esgotado, sessão expirada ou erro de integração. | Acionar o suporte da plataforma com os registros. |
A principal diferença está em até onde a tentativa chegou. No bloqueio de segurança, ela não é enviada à processadora e não entra nas estatísticas de autorização nem na relação com o adquirente.
Nos outros dois casos, a transação já avançou e deixou registros. Por isso, o bloqueio funciona como proteção: impede que uma tentativa suspeita gere consequências e custos para a operação.
O teste de cartões gera custos em diferentes áreas da operação. E o impacto vai muito além do valor das transações testadas.
Quando uma tentativa fraudulenta é aprovada, o titular pode não reconhecer a cobrança e abrir uma contestação.
O vendedor precisará responder dentro do prazo, mobilizar a equipe e ainda correrá o risco de perder a disputa, mesmo que tenha feito o reembolso.
Outro impacto está na reputação junto às redes de cartão. A Visa detalha esse acompanhamento no documento oficial do seu programa de monitoramento de adquirentes, publicado em 2025.
O documento monitora a enumeração separadamente, considerando autorizações aprovadas e recusadas. Os limites mensais combinam pelo menos 20% de autorizações identificadas como enumeração sobre o total e um volume mínimo de 300 mil dessas autorizações. As atualizações entraram em vigor em 1º de junho de 2025.
O documento também previa o anúncio posterior do programa para o Brasil. Portanto, esses limites descrevem o modelo global, não regras comprovadamente aplicadas ao mercado brasileiro.
Os efeitos também chegam aos dados da operação. As tentativas podem aparecer como pedidos e até como novos clientes, distorcendo indicadores de conversão, ticket médio e origem do tráfego.
Além disso, a equipe precisa investigar picos de tentativas, reembolsar cobranças aprovadas, responder a contestações e ajustar as proteções. É um trabalho extra que compromete tempo e recursos.
Por isso, o custo do teste de cartões não está apenas nas cobranças indevidas: envolve também reputação, indicadores e esforço operacional. Proteger o checkout significa evitar que esses impactos se acumulem.
Na cobrança recorrente, o impacto do teste de cartões pode durar mais. Uma cobrança fraudulenta aprovada pode voltar a acontecer a cada renovação da assinatura.
Em uma venda única, o problema costuma terminar com um reembolso ou uma contestação.
Já em uma assinatura, a cobrança é renovada a cada ciclo. Enquanto não houver cancelamento, o problema pode se repetir, gerando novas cobranças e contestações.
Há outro risco: uma régua de retentativas mal configurada pode apresentar o mesmo padrão de um ataque de teste de cartões. Isso acontece quando o sistema faz muitas tentativas em sequência, mas poucas são aprovadas.
Insistir em cartões que já falharam várias vezes pode aproximar os indicadores da operação dos padrões monitorados pelas redes de cartão.
Por isso, após identificar um ataque, os cartões cadastrados durante o período afetado não devem continuar no ciclo automático de retentativas. Caso contrário, a própria operação pode repetir as tentativas suspeitas.
Para bloquear tentativas suspeitas sem prejudicar vendas legítimas, é preciso ajustar o nível de proteção ao risco de cada transação.
Sem barreiras, o checkout pode ser usado para testar cartões de terceiros. Com restrições excessivas, o comprador legítimo também enfrenta dificuldades.
O ideal é aplicar proteções em camadas, das menos perceptíveis às mais rigorosas:
Cada camada precisa ser avaliada pela conversão do checkout, comparando períodos equivalentes antes e depois das mudanças. Assim, é possível identificar se a proteção está funcionando sem prejudicar as vendas.
Essa é a diferença entre um checkout seguro e um checkout apenas restritivo: o primeiro bloqueia tentativas suspeitas sem dificultar desnecessariamente a compra legítima.
Na Black Friday, o grande volume de compras legítimas facilita a ação dos fraudadores.
Com milhares de tentativas acontecendo ao mesmo tempo, fica mais difícil identificar atividades suspeitas e agir rapidamente.
Um levantamento da Serasa Experian acompanhou 5,2 milhões de transações no e-commerce brasileiro entre 28 de novembro e 1º de dezembro de 2024.
Nesse período, foram movimentados R$ 3,5 bilhões e interceptadas 32,4 mil tentativas de fraude digital, que representariam R$ 51,8 milhões em perdas.
Um dos dados mais importantes do estudo é a distribuição das tentativas por horário. Entre meia-noite e duas da manhã, o volume caiu para cerca de 65 mil pedidos por hora. No início da tarde, ultrapassou 300 mil.
Mesmo com menos pedidos, a proporção de tentativas de fraude aumentou. Às três da manhã, a taxa chegou a 2%, o dobro do registrado em outros períodos. Isso mostra que a atividade suspeita pode ser proporcionalmente maior justamente quando há menos pessoas acompanhando a operação.
Rodrigo Sanchez, diretor da Serasa Experian, resumiu esse comportamento:
Em 2026, a Black Friday será em 27 de novembro. Para evitar problemas, três medidas precisam ser definidas antes da data:
Os critérios de bloqueio não são divulgados porque isso ajudaria os fraudadores a adaptar suas tentativas para escapar da proteção.
O estudo da Universidade de Newcastle ajuda a entender o motivo: os ataques se ajustam às exigências de cada checkout e ao número de tentativas permitidas. Se as regras forem conhecidas, os criminosos podem preparar novas tentativas para contorná-las.
Outro motivo é que esses critérios mudam conforme surgem novos padrões de ataque. Divulgar uma lista fixa de regras daria a impressão de que a proteção é sempre a mesma, quando ela precisa acompanhar as mudanças no comportamento dos fraudadores.
Isso não significa que o vendedor fique sem informações. O suporte pode ajudar a identificar se o volume de tentativas está fora do normal, se alguma cobrança aprovada precisa de atenção e como agir diante de um aumento suspeito, com base nos registros da operação.
A Digital Manager Guru é uma plataforma de checkout e gestão de assinaturas que verifica os dados da compra antes de enviá-los ao processador. Essa etapa cria uma camada extra de proteção contra tentativas suspeitas.
A plataforma não processa pagamentos. Ela conecta o checkout ao processador escolhido pelo negócio, entre mais de 35 opções integradas. A verificação acontece justamente entre o preenchimento dos dados e o envio da transação.
| O que o ataque explora | Como o checkout da Guru protege |
|---|---|
| Preenchimento automatizado com dados falsos | Valida os dados em tempo real, exigindo e-mail com domínio existente, celular real e CPF ou CNPJ válido. |
| Anonimato da origem da tentativa | Identifica automaticamente o endereço IP e a localização de onde a compra está sendo feita, permitindo rastrear a origem da transação. |
| Divergência entre os dados preenchidos e o titular do cartão | Envia informações detalhadas de contato ao processador, permitindo identificar divergências e apoiar a recusa da transação. |
| Sequência de tentativas com valores baixos | Identifica padrões atípicos em conjunto com a inteligência do processador, especialmente em operações de ticket alto. |
| Captura de dados do cartão durante a transmissão | Utiliza criptografia e padrões de segurança do PCI Compliance. |
Com essa estrutura, muitas tentativas de teste de cartões são barradas antes de chegar ao processador. Assim, não geram tarifas de autorização, não entram nas estatísticas de recusa e não podem resultar em contestações.
Operações de produtos digitais também podem ter um benefício adicional.
Como o checkout já faz uma validação prévia, o processador pode ajustar as regras antifraude do gateway para reduzir recusas indevidas de compras legítimas. Essa possibilidade é negociada com cada processador, não sendo uma configuração automática.
Nenhuma proteção elimina todos os riscos. O objetivo é dificultar as tentativas e tornar o checkout menos atrativo para fraudadores que procuram meios de pagamento vulneráveis.
Por isso, a segurança depende do conjunto de medidas adotadas em cada etapa da operação, e não apenas de uma barreira isolada.
Uma tentativa bloqueada é um problema que não vai voltar.
Conheça o checkout da Digital Manager Guru
O teste de cartão de crédito é uma fraude em que criminosos usam checkouts reais para validar dados de cartões obtidos ilegalmente. Para quem vende, o ataque pode gerar contestações, distorcer indicadores, afetar a reputação junto às redes de pagamento e sobrecarregar a equipe.
A identificação depende da análise conjunta de sinais, como tentativas repetidas, valores baixos, dados inconsistentes e taxas elevadas de recusa. Para reduzir os riscos, o checkout precisa combinar validação de dados, limites de tentativas, análise de comportamento e autenticação conforme o nível de risco.
Com uma camada de verificação antes do envio ao processador, como a oferecida pela Digital Manager Guru, muitas tentativas suspeitas podem ser barradas antes de gerar custos para a operação, preservando a experiência de compra dos clientes legítimos.
Não. O bloqueio acontece do lado de fora, sobre uma tentativa de compra que chegou ao checkout como qualquer outra. Nada precisa ter sido acessado para que alguém tente usar o seu checkout, e o bloqueio indica que a tentativa foi avaliada e barrada antes de seguir para o processador.
Não. A maior parte das recusas vem do banco que emitiu o cartão, por limite, bloqueio, dado divergente ou análise própria do emissor, e essas transações chegaram a ser enviadas. Há ainda as falhas técnicas, em que nenhuma decisão foi tomada. Tratar toda recusa como bloqueio de segurança distorce a leitura da operação.
Pela coincidência de sinais na mesma janela de tempo: pico de tentativas em poucos minutos, cartões diferentes na mesma sessão, valores próximos do mínimo, taxa de recusa muito acima da média, dados de contato sem coerência e concentração fora do horário comercial. Um sinal isolado não indica ataque.
Não quando a tentativa vem de um teste de cartão, porque ela nunca teria se tornado receita. Se tivesse sido aprovada, voltaria como contestação, com prazo de resposta e trabalho de atendimento. A dúvida legítima é outra: se a proteção está barrando compra real, e isso se verifica comparando a conversão do funil em períodos equivalentes, não caso a caso.
Pode. Volume anormal de tentativas altera o perfil de risco da operação, e as redes de cartão acompanham essa métrica. A Visa, no documento de 2025 do seu programa de monitoramento, conta a enumeração separadamente e soma autorizações aprovadas e recusadas no cálculo, com o programa específico para o Brasil indicado como anúncio posterior.
Não sozinho. Ele barra automação simples, mas existe automação que usa navegador real e alterna origem entre as tentativas. Como desafio visível custa conversão em todo o tráfego, o uso mais eficiente é reservá-lo para tentativas já classificadas como suspeitas, dentro de um conjunto de camadas.
O reembolso antecipado evita a contestação, que é a consequência mais cara, e por isso costuma ser a recomendação quando a suspeita é clara. Como a decisão envolve prazo e registro da transação, o caminho é acionar o suporte da plataforma com os dados do pedido em mãos antes de agir.
Validando o que já foi preenchido antes de enviar a transação. A Digital Manager Guru é a plataforma de checkout e gestão de assinaturas que faz essa verificação no intervalo entre o preenchimento e o envio ao processador, exigindo e-mail com domínio existente, celular real e documento válido, registrando IP e localização, e identificando padrão atípico junto à inteligência do processador. Quem digita os próprios dados não percebe a verificação; quem usa dado inventado não avança.
CEO e fundador da Digital Manager Guru
Envolvido com análise de sistemas e grandes volumes financeiros desde 1999. Passou por empresas renomadas como Vivo, IG e VTEX. Sua atenção aos mínimos detalhes foram fundamentais em todos os projetos em que participou.
