Teste de cartão (card testing) é usar o seu checkout para descobrir quais cartões roubados ainda funcionam. Alguém compra uma lista de números de cartão e testa todos em lote, com pagamentos pequenos ou salvando um cartão, e fica com os que o seu provedor de pagamentos aceita. A Stripe lista outros nomes para ele: carding, account testing, enumeration e card checking; a OWASP o chama de carding, "várias tentativas de autorização de pagamento para verificar a validade de dados de cartões roubados em lote". É feito por script, porque uma lista só vale a pena testar em volume.
O que o teste de cartão custa
- Disputas. Alguns dos pagamentos de teste são aprovados, os titulares os veem e denunciam fraude, e cada um pode virar uma disputa com a sua taxa.
- Os pagamentos dos seus clientes reais. Milhares de recusas ligadas à sua empresa fazem os emissores verem cada pagamento seu como mais arriscado, e a Stripe avisa que pagamentos legítimos podem ser recusados com mais frequência, mesmo depois que o teste para.
- Taxas e carga. Taxas de autorização em alguns planos de preço, e uma onda de requisições que os seus servidores e o seu provedor precisam responder.
- A atenção das bandeiras. A Visa conta isso: desde junho de 2025, o seu programa de monitoramento de adquirentes aponta um lojista cujas autorizações de enumeração chegam a 20% de todas as suas autorizações, com pelo menos 300.000 delas em um mês.
- Os seus números. Os pagamentos pequenos do testador parecem clientes novos nos seus dados.
Como aparece nos seus pagamentos
A Stripe aponta os sintomas de sempre:
- um pico de pagamentos com falha ou bloqueados;
- um pico de requisições recusadas, muitas com uma recusa genérica;
- mais pagamentos pequenos, muitas vezes com nomes e emails sem sentido.
Olhe também o cadastro de cartões, não só o pagamento. A Stripe observa que os testadores preferem esse caminho, porque um cartão salvo numa conta normalmente não aparece na fatura do titular, e ninguém denuncia.
Por que um controle só não basta
Os testadores trocam de cartão, de endereço e de sessão, então um filtro por um único sinal, como o endereço IP, normalmente não basta sozinho, nas palavras da Stripe. O conselho dela é um conjunto de controles nas rotas que salvam um cartão ou recebem um pagamento: um CAPTCHA verificado no servidor, um login antes do pagamento, limites de taxa, e uma combinação deles. Cada um acrescenta um passo, e o passo cai sobre os seus compradores tanto quanto sobre o script.
Pergunte antes de cobrar
Um script de teste normalmente envia direto para a sua rota de pagamento e nunca carrega a página de checkout. O Bot Protection julga a requisição antes de o seu servidor chamar o provedor de pagamentos, e nessa rota você pode pedir a prova de que a página foi visitada de verdade: uma ação que precisa da tag. Coloque isso no post que cobra o cartão, no que salva um cartão e no que resgata um vale-presente. Depois aja conforme a classe:
bot_high: recuse com a mesma mensagem que um cartão recusado mostra, ou com uma resposta isca (decoy), para o script não aprender nada sobre os seus cartões.bot: peça primeiro a sua própria verificação, como o 3-D Secure, ou mande o comprador pela página de desafio.unknown,human,human_high: o pagamento normal.
Comece no modo monitor: ninguém é parado, e cada resposta diz o que o modo bloqueio teria feito, então você vê quantas requisições do seu checkout são scripts antes de ativá-lo. A configuração completa, rota por rota e linguagem por linguagem, está em proteger um checkout.
Depois do pagamento
Estorne os pagamentos pequenos que passaram antes que os titulares os contestem, como a Stripe recomenda. Depois envie o resultado do pagamento como feedback: um chargeback ou uma fraude confirmada pesa nas próximas decisões sobre o mesmo navegador, e um bom cliente as eleva.
Mantenha o fail-open
A verificação fica no seu checkout, então ela nunca pode pará-lo. Use um timeout curto e deixe o comprador passar em qualquer erro: alguns pagamentos de teste durante uma queda custam menos do que um checkout que não responde. Mais em por que uma verificação de bots precisa fazer fail-open.
Fontes
Verificadas em 28 de outubro de 2026.