Como identificar um número de cartão de crédito falso
Detectar um cartão de crédito falso é um trabalho em camadas. Algumas verificações rodam na hora no navegador, outras exigem uma consulta de BIN, e só o banco emissor pode confirmar que a conta existe de verdade. Este guia percorre cada camada do ponto de vista de um lojista e de um desenvolvedor.
Pontos-chave
- As verificações de formato (prefixo, tamanho, Luhn, validade e tamanho do CVV) pegam erros de digitação e dígitos aleatórios na hora, mas qualquer pessoa consegue gerar números que passam nelas.
- Uma consulta de BIN mostra a bandeira, o país do emissor e o tipo de cartão, o que permite notar incoerências com o IP ou o país de cobrança do cliente.
- Só uma autorização ou uma verificação de conta de valor zero prova que a conta existe; os resultados de CVV, AVS e 3-D Secure trazem evidências sobre quem está usando o cartão.
- Um cartão real roubado passa em todas as verificações de formato, por isso regras de velocidade e sinais de comportamento importam tanto quanto validar o número.
Nesta página
- O que “falso” significa no checkout
- Camada 1: verificações de formato instantâneas
- O que o Luhn pode e não pode provar
- Camada 2: coerência da consulta de BIN
- Camada 3: deixe o emissor responder
- Sinais de alerta no checkout
- Cartões físicos no balcão
- Teste seus controles sem cartões reais
- Como juntar as camadas
- Perguntas frequentes
Quando um lojista fala de um número de cartão “falso”, normalmente está falando de quatro coisas bem diferentes. Cada uma é pega por uma verificação diferente, e tratá-las como um único problema é exatamente o que leva a recusar bons clientes ou a deixar a fraude passar. Este guia separa os quatro casos e mostra quais sinais você consegue coletar em cada etapa de um pagamento.
O que “falso” significa no checkout
| Tipo | Exemplo | Quem pega |
|---|---|---|
| Erro de digitação num número real | Dois dígitos trocados ao digitar | A verificação de Luhn no formulário |
| Dígitos aleatórios ou inventados | Alguém digita qualquer coisa | As verificações de prefixo, tamanho e Luhn |
| Número gerado com formato válido | A saída de um gerador de cartões de teste | A resposta de autorização do emissor |
| Cartão real roubado | Dados obtidos num vazamento ou por phishing | CVV, AVS, 3-D Secure, velocidade e sinais de comportamento |
Os dois primeiros são erros honestos ou lixo de baixo esforço, e o seu formulário deve pegá-los antes que qualquer requisição saia do navegador. Um número gerado cumpre todas as regras de formato por definição, então só o banco consegue recusá-lo. O quarto caso é o que custa dinheiro: o número é perfeitamente real, e a pergunta passa a ser se quem está digitando é o titular.
Camada 1: verificações de formato instantâneas
A validação de formato é gratuita, rápida e privada. Ela roda no navegador antes do envio e pega a maioria dos erros de digitação. Use-a para dar mensagens úteis, não como veredito de fraude.
Prefixo da bandeira e tamanho
Os primeiros dígitos de um cartão, o número de identificação do emissor (IIN), identificam a bandeira. Cada bandeira também tem um conjunto fixo de tamanhos. Um número que começa com 34 mas tem 16 dígitos não é um número válido de American Express, seja como for o resto.
| Bandeira | Começa com | Tamanho | Código de segurança |
|---|---|---|---|
| Visa | 4 | 13, 16 ou 19 | 3 dígitos |
| Mastercard | 51–55, 2221–2720 | 16 | 3 dígitos |
| American Express | 34, 37 | 15 | 4 dígitos (frente) |
| Discover | 6011, 644–649, 65 | 16–19 | 3 dígitos |
| JCB | 3528–3589 | 16–19 | 3 dígitos |
| Diners Club | 300–305, 36, 38–39 | 14–19 | 3 dígitos |
| UnionPay | 62 | 16–19 | 3 dígitos |
A lista completa, com Maestro e as regras de agrupamento, está na nossa página de formato do número do cartão (em inglês). Mantenha essas tabelas num único lugar do seu código: as faixas mudam (a faixa 2 da Mastercard é uma adição relativamente recente) e uma lista desatualizada recusa clientes reais. No Brasil, vale lembrar que bandeiras locais como Elo e Hipercard têm faixas próprias que também precisam estar na sua tabela se você as aceita.
Dígito verificador Luhn
O último dígito de todo cartão das grandes bandeiras é um dígito verificador calculado com o algoritmo de Luhn. Se o cliente errar um dígito, ou trocar a maioria dos pares de dígitos vizinhos, a verificação falha e você pode pedir que ele confira o número antes de clicar em “Pagar”.
Data de validade
Recuse meses fora de 01–12 e datas no passado. Um cartão normalmente vale até o último dia do mês impresso, então 10/26 ainda é válido em 31 de outubro de 2026. Limite também até quando você aceita: cartões raramente são emitidos para mais de alguns anos, e um ano como 2099 quase sempre é erro ou valor de teste.
Tamanho do código de segurança
A American Express usa um código de quatro dígitos impresso na frente; as outras grandes bandeiras usam três dígitos no verso. Valide o tamanho de acordo com a bandeira detectada. Não dá para verificar se o código está correto: só o emissor consegue, porque o valor é derivado de chaves secretas (explicamos no nosso guia sobre CVV, CVC e CID, em inglês).
Uma verificação compacta no navegador fica assim. Ela devolve um motivo que você pode mostrar ao cliente, não uma pontuação de fraude:
function luhnOk(num) {
let sum = 0, dbl = false;
for (let i = num.length - 1; i >= 0; i--) {
let d = num.charCodeAt(i) - 48;
if (dbl) { d *= 2; if (d > 9) d -= 9; }
sum += d; dbl = !dbl;
}
return sum % 10 === 0;
}
const BRANDS = [
{ name: 'amex', re: /^3[47]/, lengths: [15], cvc: 4 },
{ name: 'visa', re: /^4/, lengths: [13, 16, 19], cvc: 3 },
{ name: 'mastercard', re: /^(5[1-5]|222[1-9]|22[3-9]\d|2[3-6]\d\d|27[01]\d|2720)/, lengths: [16], cvc: 3 },
];
function checkCard(raw, cvc) {
const num = raw.replace(/[\s-]/g, '');
if (!/^\d{12,19}$/.test(num)) return 'O número deve ter de 12 a 19 dígitos';
const brand = BRANDS.find(b => b.re.test(num));
if (!brand) return 'Bandeira não aceita';
if (!brand.lengths.includes(num.length)) return 'Tamanho incorreto para ' + brand.name;
if (!luhnOk(num)) return 'Confira o número do cartão';
if (!new RegExp('^\\d{' + brand.cvc + '}$').test(cvc)) return 'O código de segurança deve ter ' + brand.cvc + ' dígitos';
return null; // bem formado: a palavra final é do emissor
}Os padrões de todas as bandeiras, testados em três linguagens, estão no nosso guia de regex para cartão de crédito. Você também pode colar qualquer número no validador de cartão para ver cada verificação passo a passo.
O que o Luhn pode e não pode provar
A verificação de Luhn é a parte mais mal compreendida da detecção de cartões falsos. É um código de detecção de erros dos anos 1950, não um recurso de segurança, e a conta é pública.
| Pergunta | O Luhn responde? |
|---|---|
| O cliente errou um dígito? | Sim: qualquer erro num único dígito muda a soma |
| Ele trocou dois dígitos vizinhos? | Quase sempre (a exceção é 09 ↔ 90) |
| O número pertence a uma conta real? | Não |
| O cartão está ativo, dentro da validade e sem bloqueio? | Não |
| Quem digita é o titular? | Não |
| O número foi gerado em vez de copiado de um cartão? | Não: uma em cada dez sequências aleatórias passa, e os geradores sempre passam |
Ou seja, uma falha no Luhn é um bom motivo para parar e pedir que o número seja digitado de novo. Um acerto no Luhn não diz quase nada sobre fraude.
Camada 2: coerência da consulta de BIN
Os primeiros seis ou oito dígitos, o BIN, identificam a faixa do emissor. Uma consulta de BIN devolve a bandeira, o banco emissor, o país e muitas vezes se o cartão é de crédito, débito ou pré-pago. Esses dados não provam que um cartão é real, mas permitem checar se a história do pedido faz sentido.
Sinais que vale comparar
- País do emissor versus país do IP e de cobrança. Um cartão emitido num país, um endereço de cobrança em outro e um IP num terceiro merece uma olhada mais atenta, principalmente em valores altos ou produtos digitais.
- Cartões pré-pagos. São um meio de pagamento legítimo, mas alguns negócios — assinaturas com período grátis, locações, produtos de alto risco — preferem revisá-los ou recusá-los.
- BINs desconhecidos ou não atribuídos. Um prefixo que nenhuma base de BIN conhece pode ser uma faixa nova, mas também pode denunciar dígitos aleatórios.
- Bandeira divergente. Se os dados do BIN atribuem a faixa a uma bandeira diferente da que suas regras de prefixo detectaram, revise primeiro a sua tabela de bandeiras: ela pode estar desatualizada.
Incoerências são sinais, não vereditos
Viajantes, pessoas que moram no exterior, compradores internacionais e usuários de VPN geram incoerências honestas. Use os dados do BIN para decidir quanta verificação pedir — por exemplo, acionar o 3-D Secure ou uma revisão manual — e não para recusar de cara.
Camada 3: deixe o emissor responder
Tudo o que vimos acontece sem falar com o banco. A única forma de saber se uma conta existe, está aberta e pertence a quem está pagando é perguntar ao emissor por meio da bandeira.
Autorização e verificação de conta
Uma autorização normal pede ao emissor que aprove um valor específico. Quando você quer verificar um cartão sem cobrar — por exemplo, ao salvá-lo para compras futuras —, a maioria dos gateways oferece uma verificação de conta: uma autorização de valor zero (ou muito baixo) que devolve aprovada ou recusada, junto com o resultado das verificações de CVV e endereço. Um número gerado é recusado nessa etapa porque o emissor não tem essa conta.
Resultados de CVV e AVS
Quando você envia o código de segurança e o endereço de cobrança, o emissor compara com os registros dele. Os gateways informam o resultado em campos padronizados. A Stripe, por exemplo, devolve cvc_check, address_line1_check e address_postal_code_check no cartão:
| Resultado | Significado | Ação comum |
|---|---|---|
pass | O valor confere com os registros do emissor | Seguir |
fail | O valor não confere | Recusar ou pedir que o cliente corrija |
unavailable | O emissor não verificou (comum na verificação de endereço fora de poucos países) | Pesar junto com outros sinais |
unchecked | O dado não foi enviado ou a verificação ainda não rodou | Pedir o campo se suas regras dependem dele |
A orientação da Visa para lojistas sobre ataques de enumeração recomenda exigir CVV2 e AVS em transações com cartão não presente, porque juntos encarecem muito a tentativa de adivinhar dados. O PCI DSS permite coletar o código de segurança para a autorização, mas não guardá-lo depois.
3-D Secure
O 3-D Secure pede ao emissor que autentique o titular diretamente — pelo app do banco, por um código de uso único ou por biometria — e é obrigatório em muitos pagamentos na Europa por causa da autenticação forte do cliente (SCA). É o sinal mais forte de que quem paga controla a conta, e pode transferir para fora do lojista a responsabilidade por chargebacks de fraude. Nosso guia de testes de 3-D Secure (em inglês) explica como implementar e testar.
Sinais de alerta no checkout
Cartões reais roubados passam nas verificações de formato e, muitas vezes, também nas do emissor. Por isso os melhores sinais de fraude têm a ver com comportamento, não com o número. Fique de olho em:
- Muitos números de cartão diferentes vindos do mesmo dispositivo, IP, e-mail ou conta em pouco tempo.
- Várias recusas seguidas de uma aprovação, principalmente com cartões diferentes ou datas de validade ligeiramente diferentes.
- Números de cartão numa mesma sessão que compartilham os primeiros dígitos e só mudam no final.
- Muitos pedidos ou doações de valor muito baixo, ou cartões salvos com valor zero, a partir de contas novas.
- Nomes e e-mails sem sentido, ou o mesmo endereço de cobrança usado com muitos cartões.
- Entrega expressa para um redirecionador de encomendas ou para um endereço que não bate com os dados de cobrança.
Padrões assim costumam indicar um ataque automatizado, e não uma compra fraudulenta isolada. Nosso guia sobre fraude de teste de cartões (em inglês) explica como detectar e bloquear esse tipo de ataque.
Cartões físicos no balcão
Nos pagamentos presenciais, o chip faz a maior parte do trabalho: um chip EMV gera um criptograma para cada transação que uma tarja magnética copiada não consegue reproduzir. Se a equipe manuseia cartões, as verificações clássicas ainda ajudam: os quatro últimos dígitos do comprovante batem com os do cartão, a impressão e o holograma parecem corretos e o cartão não está adulterado. Prefira chip ou aproximação em vez de passar a tarja sempre que o terminal permitir.
Teste seus controles sem cartões reais
Nunca use números de cartões reais para testar regras antifraude. Use números gerados para a camada de formato e os cartões de teste documentados pelo seu gateway para a camada do emissor. No modo de teste da Stripe, por exemplo:
| Cartão de teste da Stripe | Resultado simulado |
|---|---|
4000 0000 0000 0101 | Falha na verificação do CVC (envie um CVC, senão a verificação é ignorada) |
4000 0000 0000 0036 | Falha na verificação do CEP |
4000 0000 0000 0028 | Falha na verificação da linha 1 do endereço |
4100 0000 0000 0019 | Sempre bloqueado pelo Radar como risco máximo |
A lista completa de cada gateway está na nossa página de cartões de teste da Stripe e nas páginas dos outros gateways.
Como juntar as camadas
- No navegador: prefixo da bandeira, tamanho, Luhn, validade e tamanho do CVV, com mensagens de erro claras e sem decisões de fraude.
- Antes da autorização: país e tipo de cartão do BIN comparados com o IP e a cobrança; limites de velocidade por dispositivo, IP, e-mail e conta.
- Na autorização: exija CVV e CEP, leia os resultados das verificações e use 3-D Secure quando for obrigatório ou o risco for alto.
- Depois da autorização: acompanhe a taxa de recusas e os alertas antecipados de fraude, e estorne pedidos suspeitos antes que virem disputas.
Nenhuma camada basta sozinha. As verificações de formato barram erros de digitação, as do emissor barram números inventados, e os sinais de comportamento são o que pega cartões reais nas mãos erradas.
Perguntas frequentes
Dá para saber se um número de cartão é real só de olhar?
Não. Dá para saber se ele está bem formado: prefixo certo para a bandeira, tamanho certo e dígito verificador Luhn válido. Se existe uma conta por trás, só o banco emissor sabe, e ele responde por meio de uma autorização.
Passar no algoritmo de Luhn significa que o cartão é válido?
Não. O Luhn só prova que os dígitos são coerentes entre si, o que serve para pegar erros de digitação. Cerca de uma em cada dez sequências aleatórias passa por acaso, e os geradores produzem números que passam de propósito.
Qual é a melhor forma de detectar um cartão falso numa loja virtual?
Combinar camadas: validar o formato no navegador, comparar o país e o tipo de cartão do BIN com o pedido, exigir o CVV e o CEP de cobrança, usar 3-D Secure quando disponível e observar padrões de velocidade, como muitos cartões vindos do mesmo dispositivo.
Um cartão de um país diferente do IP do cliente é falso?
Não necessariamente. Viajantes, pessoas que moram no exterior e usuários de VPN geram incoerências legítimas. Trate isso como mais um sinal de risco, por exemplo pedindo 3-D Secure ou revisando o pedido manualmente.
Uma autorização de valor zero verifica o cartão sem cobrar?
Sim. A maioria dos gateways oferece uma verificação de conta (uma autorização de valor zero ou muito baixo) que pergunta ao emissor se a conta é válida e pode devolver os resultados de CVV e endereço, sem capturar dinheiro.
Fontes
Ferramentas deste guia
Guias relacionados
Escrito para desenvolvedores, equipes de QA e lojistas. Os números gerados são dados de teste: não são cartões reais e não servem para pagar.