Cartões de teste do Stripe

Como usar um cartão de teste do Stripe

Três passos. Cartão de teste só é aceito por chave de API de teste, então nada aqui encosta num cartão ou num cliente de verdade.

1. Use as chaves de teste. As chaves de API publicável e secreta de teste, ou uma área restrita (sandbox). O Contrato de Serviços da Stripe proíbe testar em produção com dados reais de pagamento, e número de teste enviado a uma chave de produção é simplesmente recusado.
2. Escolha o cartão pelo desfecho que você quer. 4242 4242 4242 4242 para um pagamento aprovado simples, 4000 0007 6000 0002 para um cartão emitido no Brasil. Para exercitar o tratamento de erros, pegue o cartão cuja linha traz o decline code que você quer ver, com qualquer CVC de três dígitos e qualquer data futura.
3. No código do servidor, use o PaymentMethod. A Stripe recomenda passar um PaymentMethod como pm_card_visa ou pm_card_br nas chamadas de API, em vez do número, para o código de teste nunca conter um número de cartão. A coluna PaymentMethod traz o token de todo cartão que tem um.

O cartão do Brasil: o que ele testa, e o que não testa

Cartões de teste do Stripe são números de cartão que só funcionam com as chaves de API de teste e simulam, cada um, um desfecho — pagamento aprovado, recusa por fundos insuficientes, contestação, 3D Secure. Esta página reúne os 119 que a Stripe lista na página de testes, 64 deles por país, numa tabela só, com o código de erro, o decline code e o evento de webhook de cada um. Para o Brasil existe um: 4000 0007 6000 0002, Visa, com o PaymentMethod pm_card_br. Ele abre o grupo por país, marcado como o seu mercado.

O que esse cartão muda é o país do emissor, e é para isso que ele serve. A Stripe calcula a tarifa internacional pelo país do emissor do cartão e avisa que cartões emitidos fora dos EUA podem ter tarifa internacional mesmo em ambiente de teste: é o cartão para passar por qualquer código que leia a tarifa ou o país do cartão. O que ele não testa é parcelamento. A documentação de parcelas da Stripe cobre o Japão, o México e o Mastercard Installments — o Brasil não está lá, e não há cartão de teste de parcelas para ele.

Para simular onde o cliente está, e não de onde vem o cartão, a Stripe documenta e-mails com localização para Checkout Sessions, Payment Links e tabelas de preços: test+location_BR@example.com como customer_email na Checkout Session, ou como prefilled_email no Payment Link. A página do Checkout passa a mostrar a moeda e as formas de pagamento que um cliente no Brasil veria.

Um cuidado com a tabela da própria Stripe: na versão em português, conferida em 26 de setembro de 2026, o cartão do Chile (4000 0015 2000 0001) aparece como "Chipre (CL)". Aqui o nome do país sai do código ISO; na dúvida, confie no código entre parênteses.

Boleto (e Pix): o desfecho sai do e-mail, não do número

Embaixo da tabela de cartões ficam os valores de teste do Boleto, primeiro por ser o seu mercado. Não há número para digitar: o desfecho é escolhido pelo e-mail do pagador, em billing_details.email — qualquer prefixo, qualquer domínio e, quando for o caso, uma palavra-chave antes da arroba.

Numa área restrita, o tax_id precisa passar pela validação de CPF ou CNPJ, e a Stripe reserva dois valores que a dispensam: 000.000.000-00 e 00.000.000/0000-00. O resto da documentação muda o desenho do seu código em três pontos que cartão nenhum ensina:

• O pagamento chega um dia útil depois. No teste, o payment_intent.succeeded sai em segundos ou em 3 minutos; em produção, diz a Stripe, ele chega 1 dia útil após o pagamento. O pedido precisa aguentar ficar em aberto até lá sem ser cancelado por engano.
• Boleto não tem reembolso. A Stripe diz que pagamentos em boleto não podem ser reembolsados; quem precisa devolver cria um processo próprio para repassar o crédito ao cliente.
• Boleto não tem contestação. Os cartões do grupo de contestações não têm equivalente aqui.

O prazo de vencimento é seu: expires_after_days vai de 0 a 60 dias, com 3 por padrão, e a guia vence às 23:59 no horário de São Paulo (UTC−3). O Pix não está na tabela, mas o guia de Pix da Stripe usa os mesmos padrões de e-mail, aceita 000.000.000-00 como identificador fiscal de teste e tem um botão Simular digitalização, que abre uma página de Pix de teste hospedada pela Stripe para autorizar ou expirar o pagamento. A diferença que importa: em produção, o webhook de sucesso do Pix chega logo depois do pagamento, e não no dia útil seguinte.

Qual cartão dispara qual falha — e o que o seu webhook vai ver

Tratar bem um pagamento que falhou exige ter três coisas na cabeça ao mesmo tempo: o error.code que a chamada da API devolve, o decline_code que o emissor anexou — o "código de pagamento recusado" da documentação em português — e o evento que depois chega ao seu endpoint de webhook. A Stripe documenta os três em páginas diferentes. Aqui estão numa linha por desfecho:

Dois hábitos saem de ler isso como uma tabela só. Primeiro, card_declined não é motivo, é categoria: o motivo está no decline_code, e só uma parte das recusas traz um. Um tratamento de erros que olha só o error.code vê fundos insuficientes e cartão roubado como a mesma coisa — e mostra a mensagem errada para o cliente cujo cartão só estava sem limite. Segundo, parte dos desfechos nunca aparece na resposta: a cobrança que foi para revisão, a contestação de três semanas depois, o reembolso que muda de concluído para falhou chegam como evento, ou não chegam porque o endpoint nunca foi escrito.

Duas notas de rodapé. A Stripe pula as verificações de CVC e de CEP quando esses campos não são enviados, então os cartões que simulam falha nelas passam em silêncio se o seu formulário não os coleta. E nos pagamentos bloqueados pelo Radar, o generic_decline cobre, pela própria definição da Stripe, o caso em que o Stripe Radar ou o Adaptive Acceptance bloqueou o pagamento — de propósito: o cliente não deve saber que foi marcado como suspeito.

Testar o 3D Secure

O pagamento que exige autenticação não falha e não é aprovado: volta com o PaymentIntent em requires_action, e o seu front-end precisa passar o controle ao Stripe.js para o cliente completar o desafio. É onde uma integração que funciona no caminho feliz costuma cair.

• 4000 0000 0000 3220 — autenticação obrigatória e concluída. É o cartão para construir em cima: mostra se o seu cliente chama mesmo a etapa de confirmação ou trata requires_action como falha.
• 4000 0084 0000 1629 e 4000 0084 0000 1280 — os dois finais ruins: o cliente autentica e o emissor recusa mesmo assim, ou a própria consulta dá erro. Os dois voltam como card_declined, então quem supõe que desafio concluído é pagamento concluído mostra tela de sucesso para um pagamento que não aconteceu.
• 4000 0025 0000 3155 e 4000 0027 6000 3184 — os casos de cartão salvo: o primeiro exige autenticação fora da sessão até ser configurado para uso futuro; o segundo exige sempre. Se você vai cobrar depois, sem o cliente presente, estes dois separam a renovação que funciona da que morre.

Só os cartões do grupo 3D Secure testam o fluxo de verdade: outros podem acioná-lo, mas a Stripe devolve attempt_acknowledged e pula as etapas extras. E o redirecionamento não acontece em pagamento criado direto no Dashboard — teste pelo seu front-end ou por uma chamada de API. Vale saber também que os cartões europeus do grupo por país simulam pagamento aprovado sem autenticação: para o desafio, use este grupo.

Reembolsos, contestações e o que chega atrasado

Em produção, reembolso não é instantâneo nem garantido: pode aparecer como concluído e falhar horas depois, ou ficar pendente e se resolver mais tarde. Com um cartão de teste comum, o reembolso conclui na hora e nunca muda de status. 4000 0000 0000 7726 começa pendente e depois conclui; 4000 0000 0000 5126 aparece concluído e depois falha. Os dois emitem evento depois — exatamente o caminho de código que você quer pronto antes de um cliente ligar atrás do dinheiro. No Boleto, lembre, reembolso não existe.

Contestação é a mesma coisa em câmera lenta: a cobrança é aprovada e o chargeback aparece dias depois, com charge.dispute.created como único aviso. 4000 0000 0000 0259 abre uma contestação por fraude, 4000 0000 0000 2685 uma de produto não recebido e 4000 0000 0000 1976 um pedido de informação em vez de um chargeback. 4000 0000 0000 5423 gera um alerta antecipado de fraude, que é a rede avisando que uma contestação provavelmente vem aí, enquanto ainda dá para reembolsar por conta própria.

Para simular o resultado além do evento, responda à contestação com os textos que a Stripe reserva para teste, no campo de texto sem categoria: winning_evidence fecha como ganha, losing_evidence como perdida e escalate_inquiry_evidence transforma um pedido de informação num chargeback de verdade. E 4000 0000 0000 0077 manda os fundos direto para o saldo disponível, sem passar pelo pendente — um teste de conciliação, não de pagamento.

Baixe os fixtures em JSON ou CSV

Tabela copiada à mão é tabela copiada errado. Os dois botões no topo da página entregam os mesmos 119 cartões em arquivos legíveis por máquina, gerados no navegador a partir dos dados com que a página foi montada — o que você baixa não tem como divergir do que acabou de ler.

O JSON é um objeto com source, checked, count e a lista cards. Cada cartão traz um id estável para usar no nome do teste, os dígitos, a bandeira, o grupo, a descrição, as regras de CVC e validade, os quatro campos da tabela cruzada — payment_method, error_code, decline_code e webhook_event — e country, o código ISO do país emissor nos cartões do grupo por país. Campo que não se aplica vem como null, não some.

O CSV tem as mesmas doze colunas, com aspas no padrão RFC 4180: abre em planilha e carrega no pandas sem argumento extra. Os dois arquivos são iguais em qualquer idioma da página — em inglês e na ordem da Stripe —, e os valores do Boleto e das outras formas locais ficam fora deles: estão aqui para copiar, não para baixar. Os downloads seguem o filtro aplicado; filtre as recusas, baixe o JSON e você recebe dez linhas em vez de 119, que é o que um teste parametrizado costuma querer:

test.each(fixtures.cards.filter(c => c.group === 'decline'))(
  '$id devolve $decline_code',
  async ({ payment_method, error_code, decline_code }) => { /* … */ },
);

Os arquivos carregam a URL da fonte e a data da conferência, porque lista de cartões sem data é lista em que não dá para confiar daqui a seis meses. Se a Stripe mudar um número, o conserto honesto é conferir a fonte de novo, não manter uma cópia velha no repositório.

O que você está construindo de fato

Ninguém procura cartão de teste por diversão. Você está montando um checkout, e o checkout é um pedaço de algo maior: um catálogo, um preço que o cliente não pode editar, uma sessão criada em algum lugar com uma chave secreta, um webhook que decide se o pedido conta como pago e tudo o que acontece depois que o dinheiro chega.

O pedaço que mais quebra não é o cartão, é o preço. Um site estático que guarda o preço no HTML e manda um valor para o endpoint de checkout está confiando o número ao navegador, e o navegador não é confiável — é uma classe inteira de erro que os cartões de teste nunca pegam, porque um pagamento adulterado é aprovado lindamente.

A Clize se apoia no Stripe Checkout exatamente por isso e deixa o preço do lado do servidor: uma loja hospedada precifica cada carrinho contra o _catalog.json publicado com o site e ignora o valor que o cliente disser. Se esse é o formato do seu problema, o arquivo de catálogo tem gerador e validador aqui (em inglês); e, se você só precisa que um cliente pague um valor, clize pay link --amount 49 devolve uma URL de Stripe Checkout real sem conta Stripe própria. Essa cobrança é dinheiro de verdade: mantenha-a longe dos números desta página.

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 49 --for "fatura 1042"