Cartão de Crédito Falso para Testes: Fake, Teste ou Sandbox?

"Número de cartão falso" aparece em tickets de QA, README de projetos e issues do GitHub toda semana. O problema: "falso" pode significar três coisas diferentes dependendo do contexto — um número gerado matematicamente, um cartão fornecido pelo gateway para ambiente sandbox, ou o próprio ambiente sandbox. Usar o tipo errado no momento errado gera testes que passam localmente e quebram em homologação, ou chamadas desnecessárias à API de pagamento durante testes de formulário.

Número de cartão "falso" não é fraude — é estrutura válida sem vínculo financeiro

Todo número de cartão segue duas regras estruturais: prefixo de BIN (Bank Identification Number, os primeiros 6 a 8 dígitos) e dígito verificador calculado pelo algoritmo de Luhn. Um número fake respeita essas duas regras sem pertencer a nenhuma conta bancária real.

O que faz um número de cartão ser estruturalmente válido (BIN + Luhn)

O BIN identifica a instituição emissora e a bandeira. Visa começa com 4, Mastercard com 51–55 ou 2221–2720, Elo cobre faixas específicas como 636368, 438935 e 504175. O Luhn é o dígito verificador que garante integridade de digitação, não autenticidade financeira.

4111 1111 1111 1111 é estruturalmente válido: começa com 4 (Visa) e passa no Luhn. Não existe em nenhum banco. Qualquer formulário que valida apenas o Luhn vai aceitá-lo.

Por que dados fake passam na validação de formulário mas falham no gateway

A validação de formulário verifica Luhn e comprimento. O gateway vai além: consulta o BIN em tabelas de emissores, envia o PAN para autorização junto à bandeira e aguarda resposta do banco emissor. Um número fake não tem banco emissor — a autorização é recusada imediatamente.

Algoritmo de Luhn: a única regra que número fake precisa respeitar

O Luhn (ISO/IEC 7812-1) foi criado por Hans Peter Luhn na IBM em 1954. É um checksum simples para detectar erros de digitação, não criptografia nem autenticação.

Como o dígito verificador é calculado (passo a passo com código)

Partindo do último dígito para o primeiro, dobre cada segundo dígito. Se o resultado for maior que 9, subtraia 9. Some todos os dígitos. Se a soma for divisível por 10, o número é válido.

function isValidLuhn(pan: string): boolean {
  const digits = pan.replace(/\D/g, '').split('').map(Number);
  let sum = 0;
  let double = false;

  for (let i = digits.length - 1; i >= 0; i--) {
    let d = digits[i];
    if (double) {
      d *= 2;
      if (d > 9) d -= 9;
    }
    sum += d;
    double = !double;
  }

  return sum % 10 === 0;
}

console.log(isValidLuhn('4111111111111111')); // true
console.log(isValidLuhn('4111111111111112')); // false

Por que Visa, Mastercard, Elo e Hipercard usam o mesmo algoritmo

O Luhn é mandatório para todos os PANs (Primary Account Numbers) segundo ISO/IEC 7812. Nenhuma bandeira pode dispensá-lo. A lógica de validação é idêntica independente da bandeira — o que muda é apenas prefixo e comprimento.

Três categorias distintas de dados de cartão em ambiente de desenvolvimento

Fake — número matematicamente válido, sem BIN real registrado

Gerado localmente ou via ferramenta como o gerador de cartão do FakeForge BR. Passa no Luhn, tem prefixo de bandeira correto, mas não existe no sistema de autorização de nenhum gateway.

Uso adequado: testar máscara de input, detecção de bandeira, validação client-side, fixtures de banco de dados de teste.

Teste — número fornecido pelo gateway, com BIN real apontando para ambiente sandbox

Cada gateway publica uma lista de números de cartão de teste. Esses números têm BINs registrados internamente pela própria gateway, mas apontam para um ambiente de autorização que nunca debita conta real.

Uso adequado: testar fluxo completo de pagamento, webhooks, estornos, falhas de autorização por cenário.

Sandbox — ambiente completo da gateway com chaves separadas de produção

O sandbox é a infraestrutura, não o número do cartão. Você usa chaves de API separadas (sk_test_... no Stripe, credenciais de homologação no Cielo) que roteiam todas as chamadas para servidores de teste da gateway.

Uso adequado: integração de ponta a ponta, CI/CD, testes de regressão de pagamento.

Quando usar número fake e quando usar o cartão de teste do gateway

Validação de formulário, máscaras e detecção de bandeira (fake suficiente)

Se o teste cobre apenas o front-end — formatação 4111 1111 1111 1111, ícone da bandeira aparecendo, campo de CVV com 3 ou 4 dígitos — número fake é suficiente. Chamar a API da gateway para isso é overhead desnecessário e consome cota.

Fluxo de autorização, webhook, estorno e 3DS (exige cartão de teste do gateway)

Para testar o que acontece após o submit — resposta de autorização, webhook payment.authorized, tratamento de recusa por saldo insuficiente, fluxo de 3DS 2.0 — você precisa dos cartões de teste publicados pelo gateway. Número fake retorna erro imediato de BIN desconhecido.

Testes de carga contra o próprio back-end (fake + mock do client gateway)

Testes de carga no seu back-end de pagamento não devem chamar o gateway de verdade. Use número fake junto com um mock do client HTTP do gateway. O objetivo é medir throughput do seu código, não da infraestrutura do gateway.

Cartões de teste das principais gateways brasileiras

Mercado Pago — números, CVV e validade documentados

Fonte: documentação do Mercado Pago (2024). Para o campo de titular, use qualquer nome com CPF válido — o gerador de CPF do FakeForge BR gera um instantaneamente.

PagSeguro / PagBank — conjunto de cartões por cenário

O PagBank publica números Visa e Mastercard para cada cenário. Aprovado: 4111 1111 1111 1111 com CVV 123 e validade 12/26. Para recusa, o conjunto varia por tipo de erro — consulte a documentação oficial do PagBank Sandbox antes de fixar valores em CI.

Stripe no Brasil — pm_card_visa e equivalentes para rejeição e 3DS

O Stripe usa Payment Method IDs em testes, não PANs. Você passa pm_card_visa (aprovação), pm_card_visa_chargeDeclined (recusa) ou pm_card_threeDSecure2Required (3DS obrigatório). Isso evita lidar com PAN em testes de integração Stripe.

Cielo e Rede — ambiente de homologação com credenciais separadas

Cielo tem ambiente em apisandbox.cieloecommerce.cielo.com.br com credenciais distintas das de produção. Número de cartão Visa publicado pela Cielo para testes: 4000000000000010. Rede segue padrão similar com endpoint próprio.

AVISO: Os números de cartão de teste de cada gateway mudam com atualizações de documentação. Sempre consulte a fonte oficial antes de fixar um número em fixture de CI.

O que a gateway verifica além do número

BIN lookup — emissor, país, tipo (crédito/débito/pré-pago)

Ao receber um PAN, o gateway consulta tabelas de BIN para identificar banco emissor, país de emissão e tipo do produto. Um número fake com BIN não registrado retorna erro antes mesmo da tentativa de autorização.

CVV e data de validade — não são validados pelo Luhn

O CVV é calculado com chave criptográfica do emissor — o Luhn não cobre isso. A data de validade é verificada diretamente no emissor. Para testes que chegam ao gateway, use os valores de CVV e validade publicados na documentação oficial.

Tokenização e 3DS 2.0 — exigem chamada real à rede do cartão

Tokenização e 3DS 2.0 exigem comunicação com a rede da bandeira (Visa, Mastercard). Isso só funciona com cartões de teste em ambiente sandbox real do gateway — número fake não serve aqui.

LGPD e dados de cartão em testes

PCI-DSS scope: por que dados reais de cartão nunca devem entrar em ambiente de dev

O PCI-DSS v4.0, requisito 6.3.2, proíbe explicitamente o uso de PANs reais em ambientes de desenvolvimento e teste. Qualquer sistema que armazena, processa ou transmite PANs reais entra no escopo PCI, com obrigações de auditoria, segmentação de rede e relatórios anuais.

LGPD Art. 7º, IX — tratamento legítimo de dados sintéticos sem titular identificável

Dados sintéticos gerados sem relação com pessoa real não são dados pessoais segundo a LGPD Art. 5º, I. O Art. 7º, IX permite o tratamento com base em legítimo interesse do controlador, mas dados que não identificam titular saem do escopo da lei. Número fake gerado pelo FakeForge BR não tem titular — não há tratamento de dados pessoais.

O que configura infração: capturar PAN real em log, banco de dados de dev ou fixture de teste

Capturar um PAN real em log de aplicação, inserir em banco de dados de desenvolvimento ou incluir em fixture de teste é infração ao PCI-DSS e potencialmente à LGPD se o cartão pertence a pessoa identificável. A ANPD pode aplicar multa de até 2% do faturamento (LGPD Art. 52).

Detectando a bandeira a partir do BIN em TypeScript

Prefixos de BIN para Visa, Mastercard, Elo, Hipercard e Amex

Implementação de detectBrand(pan: string): Brand sem dependência externa

type Brand = 'visa' | 'mastercard' | 'elo' | 'hipercard' | 'amex' | 'unknown';

function detectBrand(pan: string): Brand {
  const p = pan.replace(/\D/g, '');

  if (/^4/.test(p)) return 'visa';

  if (/^(5[1-5]|2(2[2-9][1-9]|[3-6]\d{2}|7[01]\d|720))/.test(p)) return 'mastercard';

  const eloPrefixes = ['636368', '438935', '504175', '451416', '636297', '5067', '4576', '4011'];
  if (eloPrefixes.some(prefix => p.startsWith(prefix))) return 'elo';

  if (/^(606282|3841)/.test(p)) return 'hipercard';

  if (/^3[47]/.test(p)) return 'amex';

  return 'unknown';
}

DICA: A detecção de bandeira deve ocorrer enquanto o usuário digita, não apenas no submit. Isso permite exibir o ícone correto e ajustar o comprimento esperado do CVV (3 dígitos para a maioria, 4 para Amex) antes da validação final.

Integrando cartão fake em testes automatizados com Jest e Playwright

Factory de cartão fake tipada — generateCard(brand: Brand): CardFixture

type Brand = 'visa' | 'mastercard' | 'elo' | 'hipercard' | 'amex';

interface CardFixture {
  pan: string;
  cvv: string;
  expiry: string;
  holderName: string;
  brand: Brand;
}

const FAKE_PANS: Record<Brand, string> = {
  visa:       '4111111111111111',
  mastercard: '5500005555555559',
  elo:        '6362970000457013',
  hipercard:  '6062826786276634',
  amex:       '378282246310005',
};

function generateCard(brand: Brand): CardFixture {
  return {
    pan:        FAKE_PANS[brand],
    cvv:        brand === 'amex' ? '1234' : '123',
    expiry:     '12/28',
    holderName: 'JOAO SILVA',
    brand,
  };
}

Exemplo de teste Jest cobrindo Luhn válido e CVV com comprimento esperado

import { isValidLuhn } from './card-utils';
import { generateCard } from './card-factory';

describe('card fixtures', () => {
  const brands = ['visa', 'mastercard', 'elo', 'hipercard', 'amex'] as const;

  brands.forEach(brand => {
    it(`${brand}: PAN passa no Luhn`, () => {
      const card = generateCard(brand);
      expect(isValidLuhn(card.pan)).toBe(true);
    });

    it(`${brand}: CVV tem comprimento correto`, () => {
      const card = generateCard(brand);
      const expectedLength = brand === 'amex' ? 4 : 3;
      expect(card.cvv).toHaveLength(expectedLength);
    });
  });
});

Exemplo Playwright: preencher formulário de checkout com cartão fake e validar máscara

import { test, expect } from '@playwright/test';
import { generateCard } from '../fixtures/card-factory';

test('checkout aceita Visa fake e formata PAN com espaços', async ({ page }) => {
  const card = generateCard('visa');
  await page.goto('/checkout');

  await page.fill('[data-testid="pan"]', card.pan);
  await page.fill('[data-testid="cvv"]', card.cvv);
  await page.fill('[data-testid="expiry"]', card.expiry);
  await page.fill('[data-testid="holder"]', card.holderName);

  const displayedPan = await page.inputValue('[data-testid="pan"]');
  expect(displayedPan).toBe('4111 1111 1111 1111');
});

Separando fixtures de cartão fake dos cartões de teste do gateway no mesmo repositório

Organize em diretórios distintos para deixar o escopo de cada fixture evidente:

tests/
  fixtures/
    fake-cards.ts        # PANs sintéticos — UI e testes unitários
    gateway-cards.ts     # Cartões de teste do Stripe/Mercado Pago — integração
  unit/
    card-validation.test.ts
  integration/
    payment-flow.test.ts
  e2e/
    checkout.test.ts

A separação evita que um teste de unidade acidentalmente chame a API do gateway, e torna óbvio qual conjunto de dados usar por escopo.

Para gerar cartões via API do FakeForge BR:

# 5 cartões Visa em JSON
curl "https://fakeforge.com.br/api/generate?type=cartao-visa&quantity=5&format=json"

# 10 cartões Mastercard em CSV
curl "https://fakeforge.com.br/api/generate?type=cartao-mastercard&quantity=10&format=csv"

# Cartão Elo com export SQL
curl "https://fakeforge.com.br/api/generate?type=cartao-elo&quantity=1&format=sql"

Veja os parâmetros completos na referência da API. Para volume acima de 100 chamadas por dia, consulte os planos disponíveis.

Resumo

• Número fake passa no Luhn e tem prefixo de bandeira correto, mas não tem emissor — use para testes de formulário, máscaras e fixtures de banco de dados de teste.
• Cartão de teste do gateway tem BIN registrado no sandbox — use para fluxo de autorização, webhooks, estornos e 3DS 2.0.
• Sandbox é o ambiente (chaves de API separadas), não o número do cartão — os dois conceitos são independentes.
• PCI-DSS v4.0 req. 6.3.2 proíbe PANs reais em dev — dados sintéticos eliminam esse risco sem reduzir cobertura de testes.
• Implemente isValidLuhn e detectBrand localmente para testes de UI sem dependência externa de biblioteca de cartão.
• Gere números Visa, Mastercard, Elo e Hipercard com Luhn válido via /gerador-cartao ou via API REST.