⚠️ Aviso legal importante: Os dados gerados são exclusivamente para desenvolvimento e testes de software. Os números não possuem saldo real, não estão associados a nenhuma conta bancária e não podem ser usados em transações reais. O uso em qualquer contexto financeiro real é crime de fraude (Lei 7.492/1986).
Por que você precisa de cartões fictícios para testar sistemas de pagamento?
Desenvolver e testar integrações com gateways de pagamento (Stripe, PagSeguro, Mercado Pago, Cielo, Rede, Getnet) é uma das tarefas mais críticas no e-commerce. Você precisa testar fluxos de aprovação, recusa, parcelamento, estorno e erro sem movimentar dinheiro real. Para isso, todos os gateways profissionais oferecem ambientes de sandbox que aceitam números de cartão de teste — e é exatamente o que nossa ferramenta gera.
O Algoritmo de Luhn: a matemática por trás dos cartões
O Algoritmo de Luhn (também chamado de Fórmula de Luhn ou MOD 10) foi criado pelo cientista da IBM Hans Peter Luhn em 1954. É um simples algoritmo de soma de verificação usado para validar números de identificação como cartões de crédito, CPFs, CNPJs e números IMEI de celulares. O objetivo não é segurança criptográfica — é detectar erros de digitação.
O algoritmo funciona assim: partindo do último dígito (o verificador) e movendo para a esquerda, dobre o valor de cada segundo dígito. Se o resultado for maior que 9, subtraia 9. Some todos os dígitos. Se a soma total for divisível por 10, o número é válido segundo Luhn.
Prefixos de bandeiras e tamanho dos números
| Bandeira |
Prefixos IIN/BIN |
Dígitos |
CVV |
Formato |
| Visa |
4 |
16 |
3 dígitos |
XXXX XXXX XXXX XXXX |
| Mastercard |
51–55, 2221–2720 |
16 |
3 dígitos |
XXXX XXXX XXXX XXXX |
| American Express |
34, 37 |
15 |
4 dígitos (frente) |
XXXX XXXXXX XXXXX |
| Elo |
4011, 4312, 4389… |
16 |
3 dígitos |
XXXX XXXX XXXX XXXX |
| Hipercard |
606282, 637095… |
16 |
3 dígitos |
XXXX XXXX XXXX XXXX |
Cartões de teste específicos dos principais gateways brasileiros
Além de nossa ferramenta, os gateways fornecem números específicos para simular cenários:
- Stripe: 4242 4242 4242 4242 (aprovação), 4000 0000 0000 0002 (recusa)
- Mercado Pago: 5031 7557 3453 0604 (Mastercard teste)
- PagSeguro: 4111 1111 1111 1111 (Visa aprovação)
- Cielo: 4551870000000183 (Visa aprovação sandbox)
- Braintree: 4111 1111 1111 1111 (aprovação), 4000 1111 1111 1115 (recusa)
Perguntas frequentes — Gerador de Cartão
O cartão gerado pode ser usado para compras reais?▼
Absolutamente não. Os cartões gerados são matematicamente válidos (passam na verificação de Luhn e nos prefixos de bandeira) mas não existem em nenhum banco ou bandeira. Qualquer tentativa de uso em transações reais será recusada pela rede de pagamentos e pode configurar crime de fraude.
Por que o gateway recusa o cartão de teste gerado?▼
Gateways de pagamento fazem muito mais verificações além do Luhn: consultam a bandeira para verificar se o BIN existe, validam a data de expiração e solicitam autorização do banco emissor. Em ambiente de produção, todos os cartões fictícios serão recusados. Para testes reais, use o ambiente sandbox do seu gateway com os cartões de teste específicos que eles fornecem.
Como implementar a verificação de Luhn no front-end?▼
function luhn(n){const r=n.split('').reverse().map(Number).reduce((s,v,i)=>{if(i%2===1){v*=2;if(v>9)v-=9;}return s+v;},0);return r%10===0;} Esta validação deve ser feita no front-end para UX, mas sempre revalidada no servidor antes de processar qualquer pagamento.
Qual a diferença entre BIN e IIN?▼
BIN (Bank Identification Number) e IIN (Issuer Identification Number) referem-se à mesma coisa: os primeiros 6 a 8 dígitos de um cartão que identificam a instituição emissora e a bandeira. São usados para determinar a bandeira do cartão em tempo real conforme o usuário digita.
Como detectar a bandeira do cartão automaticamente em formulários?▼
Implemente verificação de prefixo em tempo real: Visa começa com 4, Mastercard com 5 (51-55) ou 2 (2221-2720), Amex com 34 ou 37, Elo com vários BINs específicos. Bibliotecas como payment.js ou card-validator (npm) já incluem essa lógica completa.
O que é tokenização de cartão e por que é importante?▼
Tokenização substitui o número real do cartão por um token inútil fora do contexto específico. Gateways como Stripe, Braintree e MercadoPago oferecem tokenização: o número do cartão vai direto do browser para o gateway (nunca passando pelo seu servidor), e você recebe apenas um token seguro para processar pagamentos futuros.
Como testar cenários de recusa em sistemas de pagamento?▼
Cada gateway tem cartões específicos para simular diferentes tipos de recusa: saldo insuficiente, cartão expirado, CVV incorreto, cartão bloqueado, etc. Consulte a documentação de sandbox do seu gateway. Nunca use cartões reais para simular recusas.
O que é PCI DSS e como afeta o desenvolvimento de sistemas de pagamento?▼
PCI DSS (Payment Card Industry Data Security Standard) é o conjunto de normas de segurança para sistemas que processam, armazenam ou transmitem dados de cartão. Qualquer sistema que "veja" um número de cartão real precisa estar em conformidade. A tokenização no front-end (Stripe Elements, PaymentBrick) é justamente para evitar que seu servidor veja o número, reduzindo drasticamente o escopo de conformidade PCI.