Sempre que trabalhar com um cartão de teste, use chaves de API de teste em todas as chamadas de API. Isso vale para testes interativos de formas de pagamento ou para testes de programação.
Erro comum
Não use dados de cartão reais. O Contrato de Serviços da Stripe proíbe testes no modo de produção usando de forma de pagamento reais. Use suas chaves de API de teste e os números de cartão abaixo.
Testar interativamente
Em testes interativos, use um número de cartão como 4242 4242 4242 4242. Informe o número do cartão no Dashboard ou em qualquer formulário de pagamento.
Use uma data futura válida, como 12/34.
Use qualquer CVC de três dígitos (quatro em cartões American Express).
Use qualquer valor nos outros campos do formulário.
Testar interativamente um formulário com o número de cartão de teste 4242 4242 4242 4242
Testar programação
Ao escrever código de teste, use um PaymentMethod como pm_card_visa em vez de um número de cartão. Não recomendamos usar números de cartão diretamente em chamadas de API ou código do lado do servidor, mesmo no modo de teste. Se você usá-los, seu código pode não estar em conformidade com o PCI quando entrar em modo de produção. Por padrão, um PaymentMethod não é vinculado a um Cliente.
A maioria das integrações não usa mais tokens, mas temos tokens de teste como tok_visa, caso sejam necessários.
Quando estiver com tudo pronto para usar a integração no ambiente de produção, substitua suas chaves de API de teste publicáveis e secretas pelas chaves do modo de produção. Não é possível processar os pagamentos no modo de produção com a integração usando as chaves de API de teste.
Cartões por bandeira
Para simular um pagamento bem-sucedido com uma bandeira de cartão específica, use os cartões de teste da lista a seguir.
Cuidado
As tarifas internacionais são avaliadas de acordo com o país do emissor do cartão. Os cartões em que o país do emissor não é os EUA (como JCB e UnionPay) podem estar sujeitos a uma tarifa internacional, mesmo no modo de teste.
Marca
Número
CVC
Data
Visa
Quaisquer 3 dígitos
Qualquer data futura
Visa (débito)
Quaisquer 3 dígitos
Qualquer data futura
Mastercard
Quaisquer 3 dígitos
Qualquer data futura
Mastercard (2 séries)
Quaisquer 3 dígitos
Qualquer data futura
Mastercard (débito)
Quaisquer 3 dígitos
Qualquer data futura
Mastercard (pré-pago)
Quaisquer 3 dígitos
Qualquer data futura
American Express
Quaisquer 4 dígitos
Qualquer data futura
American Express
Quaisquer 4 dígitos
Qualquer data futura
Discover
Quaisquer 3 dígitos
Qualquer data futura
Discover
Quaisquer 3 dígitos
Qualquer data futura
Discover (débito)
Quaisquer 3 dígitos
Qualquer data futura
Diners Club
Quaisquer 3 dígitos
Qualquer data futura
Diners Club (cartão de 14 dígitos)
Quaisquer 3 dígitos
Qualquer data futura
BCcard e DinaCard
Quaisquer 3 dígitos
Qualquer data futura
JCB
Quaisquer 3 dígitos
Qualquer data futura
UnionPay
Quaisquer 3 dígitos
Qualquer data futura
UnionPay (débito)
Quaisquer 3 dígitos
Qualquer data futura
UnionPay (cartão de 19 dígitos)
Quaisquer 3 dígitos
Qualquer data futura
A maioria dos cartões Cartes Bancaires e eftpos é de marca conjunta com Visa ou Mastercard. Os cartões de teste na tabela a seguir simulam pagamentos bem-sucedidos com cartões de marca conjunta.
Marca/marca conjunta
Número
CVC
Data
Cartes Bancaires/Visa
Quaisquer 3 dígitos
Qualquer data futura
Cartes Bancaires/Mastercard
Quaisquer 3 dígitos
Qualquer data futura
eftpos Austrália/Visa
Quaisquer 3 dígitos
Qualquer data futura
eftpos Austrália/Mastercard
Quaisquer 3 dígitos
Qualquer data futura
Cartões por país
Para simular pagamentos bem-sucedidos em países específicos, use os cartões de teste das seções a seguir.
Para testar a lógica de tratamento de erros da sua integração simulando pagamentos que o emissor recusa por vários motivos, use os cartões de teste desta seção. Usar um desses cartões resulta em um erro no cartão com o código de erro informado e o código de recusa.
Erro comum
Para simular um CVC incorreto, forneça um usando qualquer número de três dígitos. Se você não fornecer um CVC, a Stripe não realizará a verificação de CVC e a falha não ocorrerá.
Não é possível anexar os cartões da tabela anterior a um objeto Customer. Para simular um pagamento recusado com um cartão anexado, use o próximo.
Descrição
Número
Detalhes
Pagamento recusado após anexação
Este cartão pode ser anexado a um objeto Customer, mas as tentativas de cobrar o cliente falham.
Prevenção de fraudes
O sistema de prevenção de fraudes da Stripe, o Radar, pode bloquear pagamentos com nível elevado de risco ou que falham nas verificações. Você pode usar os cartões desta seção para testar as configurações do Radar e como a integração responde a pagamentos bloqueados.
Cada cartão simula fatores de risco específicos. As configurações do Radar determinam quais fatores de risco bloqueiam um pagamento. Os pagamentos bloqueados geram erros de cartão com um código de erro de fraude.
Erro comum
Para simular uma falha de verificação de CVC, informe um CVC usando qualquer número com três dígitos. Para simular uma falha de verificação de código postal, informe qualquer código postal válido. Se esses valores não forem informados, o Radar não realizará as verificações e, portanto, não indicará uma falha de verificação.
Informe dados inválidos para testar os erros resultantes. Você não precisa de um cartão de teste especial para isso. Qualquer valor inválido funciona. Por exemplo:
Com as configurações padrão da conta, a cobrança é bem-sucedida, mas é contestada como fraudulenta. Esse tipo de contestação é protegido após a autenticação do 3D Secure.
Não recebido
Com as configurações padrão da conta, a cobrança é bem-sucedida, mas é contestada como produto não recebido. Esse tipo de contestação não é protegido após a autenticação do 3D Secure.
Pedido de informação
Com configurações de conta padrão, a cobrança é bem-sucedida, mas é contestada como uma consulta.
Se você responder no Dashboard, informe o valor da tabela no campo Mais informações e clique em Enviar comprovante.
Comprovante
Descrição
winning_evidence
A contestação é encerrada e marcada como ganha. Sua conta recebe o crédito no valor da transação e as tarifas relacionadas.
losing_evidence
A contestação é encerrada e marcada como perdida. Sua conta não é creditada.
Reembolsos
No modo de produção, os reembolsos são assíncronos: um reembolso pode parecer bem-sucedido e falhar depois ou pode aparecer como pending e depois ser bem-sucedido. Para simular reembolsos com esses comportamentos, use os cartões de teste desta seção (com todos os outros cartões de teste, os reembolsos são bem-sucedidos imediatamente e não mudam de status depois).
Descrição
Número
Detalhes
Sucesso assíncrono
A cobrança é bem-sucedida. Se você iniciar um reembolso, o status começa como pending. Depois de algum tempo, o status muda para succeeded e envia um eventorefund.updated.
Falha assíncrona
A cobrança é bem-sucedida. Se você iniciar um reembolso, o status começa como succeeded. Depois de algum tempo, o status muda para failed e envia um eventorefund.failed.
Você somente pode cancelar um reembolso de cartão usando o Dashboard. No modo de produção, você pode cancelar um reembolso de cartão em um período curto, mas não específico. O modo de teste simula esse período permitindo que você cancele um reembolso de cartão em 30 minutos.
Saldo disponível
Para enviar os fundos de uma transação de teste diretamente ao saldo disponível, use os cartões de teste desta seção. Outros cartões de teste enviam fundos de um pagamento bem-sucedido para o seu saldo pendente.
Descrição
Número
Detalhes
Desconsiderar saldo pendente
A cobrança dos EUA é bem-sucedida. Os fundos são adicionados diretamente ao saldo disponível, desconsiderando o saldo pendente.
Desconsiderar saldo pendente
A cobrança internacional é bem-sucedida. Os fundos são adicionados diretamente ao saldo disponível, desconsiderando o saldo pendente.
Autenticação do 3D Secure
O 3D Secure exige uma camada adicional de autenticação para transações com cartão de crédito. Use os cartões de teste desta seção para permitir que você simule o acionamento de autenticação em diferentes fluxos de pagamento.
Somente os cartões desta seção testam sua integração do 3D Secure de forma eficaz ao simular um comportamento 3DS definido, como um fluxo de desafio ou um cartão não aceito. Outros cartões de teste da Stripe ainda podem acionar 3DS, mas retornamos attempt_acknowledged para contornar as etapas adicionais, pois o teste de 3DS não é o objetivo desses cartões.
Dashboard não compatível
Os redirecionamentos do 3D Secure não ocorrem em pagamentos criados diretamente no Stripe Dashboard. Para redirecionar, use o front-end da integração ou uma chamada de API.
Autenticação e configuração
Para simular fluxos de pagamento que incluem a autenticação, use os cartões de teste desta seção. Alguns deles também podem ser ou já foram configurados para pagamentos futuros.
Descrição
Número
Detalhes
Autenticar se não configurado
Este cartão exige autenticação para pagamentos fora da sessão, exceto quando configurado para pagamentos futuros. Depois de configurado, ele deixa de exigir autenticação. Entretanto, pagamentos na sessão com este cartão sempre exigem autenticação.
Autenticar sempre
Este cartão exige autenticação em todas as transações, independentemente da forma como foi configurado.
Já configurado
Este cartão já está configurado para uso fora da sessão e exige autenticação para pagamentos avulsos e outros pagamentos na sessão. No entanto, todos os pagamentos fora da sessão serão bem-sucedidos como se o cartão tivesse sido previamente configurado.
Fundos insuficientes
Este cartão de teste exige autenticação para pagamentos avulsos. Todos os pagamentos serão recusados com o código insufficient_funds, mesmo depois de autenticados ou previamente configurados.
Aceitação e disponibilidade
A Stripe exige autenticação para cumprir regulamentações ou quando acionada pelas suas regras do Radar ou programação personalizada. Mesmo quando solicitada, nem sempre é possível executar a autenticação. Por exemplo, o cartão pode não estar inscrito ou um erro pode ocorrer. Use os cartões de teste desta seção para simular diversas combinações desses fatores.
A autenticação do 3D Secure precisa ser concluída para que o pagamento seja feito. Por padrão, suas regras do Radar solicitam autenticação do 3D Secure para este cartão.
3DS obrigatório
Recusado
A autenticação do 3D Secure é obrigatória, mas os pagamentos são recusados com o código card_declined depois da autenticação. Por padrão, suas regras do Radar solicitam autenticação do 3D Secure para este cartão.
3DS obrigatório
Erro
A autenticação do 3D Secure é obrigatória, mas a solicitação de busca do 3D Secure falha com um erro de processamento. Os pagamentos são recusados com o código card_declined. Por padrão, suas regras do Radar solicitam autenticação do 3D Secure para este cartão.
3DS aceito
OK
A autenticação do 3D Secure ainda pode ser feita, mas não é obrigatória. Por padrão, suas regras do Radar não solicitam autenticação do 3D Secure para este cartão.
3DS aceito
Erro
A autenticação do 3D Secure ainda pode ser feita, mas não é obrigatória. No entanto, tentativas de executar o 3D Secure resultam em erro de processamento. Por padrão, suas regras do Radar não solicitam autenticação do 3D Secure para este cartão.
3DS aceito
Não inscrito
O 3D Secure é aceito com este cartão, mas o cartão não está inscrito no 3D Secure. Mesmo que suas regras do Radar solicitarem 3D Secure, o cliente não será solicitado a fazer autenticação. Por padrão, suas regras do Radar não solicitam autenticação do 3D Secure para este cartão.
3DS não aceito
Este cartão não aceita 3D Secure, e a autenticação não pode ser invocada. O PaymentIntent ou SetupIntent prossegue sem fazer a autenticação.
Fluxos de desafio para dispositivos móveis do 3D Secure
Vários fluxos de desafio, nos quais o cliente precisa interagir com solicitações na IU, estão disponíveis para pagamentos em dispositivos móveis. Use os cartões de teste desta seção para acionar um fluxo de desafio específico em testes. Esses cartões não são úteis para formulários de pagamento baseados em navegador ou em chamadas de API. Nesses ambientes, eles funcionam, mas não acionam nenhum comportamento especial. Como eles não são úteis para chamadas de API, não fornecemos versões de PaymentMethod ou Token para testes.
Fluxo de desafio
Número
Detalhes
Fora da Stripe
A autenticação do 3D Secure 2 precisa ser feita em todas as transações. Ela aciona o fluxo de desafio com a IU de fora da Stripe.
Senha de uso único
A autenticação do 3D Secure 2 precisa ser feita em todas as transações. Ela aciona o fluxo de desafio com a IU de senha de uso único.
Seleção única
A autenticação do 3D Secure 2 precisa ser feita em todas as transações. Ela aciona o fluxo de desafio com a IU de seleção única.
Seleção múltipla
A autenticação do 3D Secure 2 precisa ser feita em todas as transações. Ela aciona o fluxo de desafio com a IU de seleção múltipla.
Desafio de captcha
Para evitar fraudes, a Stripe pode exibir um desafio de captcha ao usuário na página de pagamento. Use os cartões de teste abaixo para simular esse fluxo.
Descrição
Número
Detalhes
Desafio de captcha
A cobrança é bem-sucedida se o usuário responde corretamente ao desafio de captcha.
Desafio de captcha
A cobrança é bem-sucedida se o usuário responde corretamente ao desafio de captcha.
Pagamentos com PINs
Use os cartões de teste desta seção para simular pagamentos presenciais bem-sucedidos que envolvem um PIN. Há muitas outras opções para testar pagamentos presenciais, incluindo uma máquina simulada e cartões de teste físicos. Consulte Testar o Stripe Terminal para obter mais informações.
Descrição
Número
Detalhes
PIN offline
Este cartão simula um pagamento em que o titular do cartão informa um PIN offline. Na cobrança resultante, cardholder_verification_method é definido como offline_pin.
Nova tentativa de PIN offline
Simula um fluxo de nova tentativa acionado pela SCA em que a cobrança original por aproximação do titular do cartão falha, e a máquina solicita a inserção do cartão e a digitação do PIN offline. Na cobrança resultante, cardholder_verification_method é definido como offline_pin.
PIN online
Este cartão simula um pagamento em que o titular do cartão informa um PIN online. Na cobrança resultante, cardholder_verification_method é definido como online_pin.
Nova tentativa de PIN online
Simula um fluxo de nova tentativa acionado pela SCA em que a cobrança original por aproximação do titular do cartão falha, e a máquina solicita a inserção do cartão e a digitação do PIN online. Na cobrança resultante, cardholder_verification_method é definido como online_pin.
Destinos de evento
To test your webhook endpoint or event destination, choose one of these two options:
Se as solicitações de teste começarem a receber erros HTTP 429, reduza a frequência dessas solicitações. Esses erros são causados pelo limitador de fluxo, que é mais restrito no modo de teste que no modo de produção.
Não recomendamos realizar testes de carga da integração com a API da Stripe no modo de teste. Como o limitador de carga é mais restrito no modo de teste, podem ocorrer erros que não acontecem no modo de produção. Consulte os testes de carga para ver outra abordagem.
Pagamentos sem cartão
Sempre que usar uma forma de pagamento sem cartão de teste, use chaves de API de teste em todas as chamadas de API. Isso vale para testes interativos de formas de pagamento ou para testes de programação.
Formas de pagamento diferentes têm procedimento de teste distintos:
After you collect the bank account details and accept a mandate, send the mandate confirmation and microdeposit verification emails in a sandbox. To do this, provide an email in the payment_method_data.billing_details[email] field in the form of {any-prefix}+test_email@{any_domain} when you collect the payment method details.
A Stripe fornece vários números de conta de teste e tokens correspondentes que você pode usar para verificar se sua integração para contas bancárias inseridas manualmente está pronta para produção.
Número da conta
Token
Routing number
Behavior
000123456789
pm_usBankAccount_success
110000000
O pagamento é aprovado.
000111111113
pm_usBankAccount_accountClosed
110000000
O pagamento falha porque a conta está fechada.
000111111116
pm_usBankAccount_noAccount
110000000
O pagamento falha porque nenhuma conta foi encontrada.
000222222227
pm_usBankAccount_insufficientFunds
110000000
O pagamento falha devido a fundos insuficientes.
000333333335
pm_usBankAccount_debitNotAuthorized
110000000
O pagamento falha porque o uso de débitos não está autorizado.
The payment fails due to payment amount causing the account to exceed its weekly payment volume limit.
Antes que as transações de teste possam ser concluídas, você precisa verificar todas as contas de teste que aprovam ou falham automaticamente o pagamento. Para fazer isso, use as quantias de microdepósito de teste ou códigos de descrição abaixo.
Testar valores de microdepósito e códigos de descrição
Para simular diferentes cenários, use estas quantias de microdepósito ou valores de código de descrição 0,01.
Valores de microdepósito
Valores de código da descrição 0,01
Scenario
32 and 45
SM11AA
Simula a verificação da conta.
10 e 11
SM33CC
Simula o excesso de tentativas permitidas de verificação.
40 e 41
SM44DD
Simula um tempo limite de microdepósito.
Link
Cuidado
Don’t store real user data in sandbox Link accounts. Treat them as if they’re publicly available, because these test accounts are associated with your publishable key.
Currently, Link only works with credit cards, debit cards, and qualified US bank account purchases. Link requires domain registration.
You can create sandbox accounts for Link using any valid email address. The following table shows the fixed one-time passcode values that Stripe accepts for authenticating sandbox accounts:
Valor
Resultado
Quaisquer outros 6 dígitos não listados abaixo
Sucesso
000001
Erro, código inválido
000002
Erro, código expirado
000003
Erro, número máximo de tentativas excedido
Várias fontes de fundos
À medida que a Stripe adiciona outras fontes de financiamento, você não precisa atualizar sua integração. A Stripe aceita essas fontes automaticamente com o mesmo tempo de liquidação de fundos da transação e com as mesmas garantias dos pagamentos com cartão e conta bancária.
Redirecionamentos
Para testar a lógica de processamento de redirecionamentos da sua integração simulando um pagamento que usa um fluxo de redirecionamento (por exemplo, iDEAL), use uma forma de pagamento aceita que exija redirecionamentos.
Para criar um PaymentIntent de teste bem-sucedido ou com falha: