Testes

Teste sua integração em um sandbox simulando transações com valores de teste. Essas transações não transferem fundos.

Você pode acessar suas áreas restritas usando o seletor de contas no Dashboard.

Os cartões de teste funcionam como cartões de crédito “falsos” e permitem simular os seguintes cenários:

• Pagamentos realizados por bandeira do cartão ou país
• Erros de cartão devido a pagamento recusado, fraude ou dados inválidos
• Contestações e reembolsos
• Autenticação com 3D Secure e PINs

Você também pode testar pagamentos que não sejam pagamento com cartão em uma área restrita. Pagamentos que não são pagamento com cartão são formas de pagamento que não são cartões de crédito ou débito. A Stripe suporta várias opções que não são pagamento com cartão, como carteiras digitais e transferências bancárias.Cada forma de pagamento tem seus próprios valores especiais.

Não use ambientes de teste para testar a carga da sua integração porque você pode atingir a limitação de fluxo. Para testar a carga da sua integração, consulte testes de carga.

Como usar cartões de teste

Ao trabalhar com um cartão de teste, use chaves da API de teste em todas as chamadas da API. Isso vale para testes interativos de formas de pagamento ou para testes de programação.

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 um 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.

Código de teste

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 em ambientes 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.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=500 \
  -d currency=gbp \
  -d payment_method=pm_card_visa \
  -d "payment_method_types[]"=card

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.

Simule um pagamento por bandeira de cartão

Para simular um pagamento realizado com uma bandeira de cartão específica, use os cartões de teste da lista a seguir.

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 em ambientes de teste.

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.

Simule um pagamento por país

Para simular pagamentos realizados em países específicos, use os cartões de teste das seções a seguir.

Simule um pagamento com cartão HSA ou FSA

Abaixo estão números de cartão de teste para simular transações usando uma conta poupança saúde (HSA) e uma conta com gastos flexíveis (FSA). Essas contas são comumente usadas para despesas médicas, e testar com elas garante o tratamento adequado das transações relacionadas à saúde no seu aplicativo.

Simule um pagamento recusado

Para testar a lógica de tratamento de erros da sua integração simulando pagamentos que o emissor recusa por vários motivos, use cartões de teste desta seção. Esses cartões retornam um erro do cartão com o código de erro listado e o código do pagamento recusado.

Forneça um CVC quando testar o comportamento do CVC. A Stripe ignora a verificação do CVC se você omiti-lo, então a verificação não pode falhar. Para simular um CVC incorreto, utilize o teste do cartão de “pagamento recusado em função de CVC incorreto” listado na tabela a seguir e forneça qualquer CVC com três dígitos.

Prevenção a 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.

Para acionar uma falha na verificação CVC, inclua um CVC (qualquer número com três dígitos). Para acionar uma falha na verificação do CEP, inclua qualquer código postal válido. Se você omitir esses campos, o Radar ignora essas verificações, então elas não podem falhar.

Acione um erro com dados inválidos

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:

• invalid_expiry_month: use um mês inválido, como 13.
• invalid_expiry_year: use um ano até 50 anos no passado, como 95.
• invalid_cvc: use um número de dois dígitos, como 99.
• incorrect_number: Use um número cartão que falhe na verificação de Luhn, como 4242424242424241.

Simule um contestação

Para simular uma transação contestada, use os cartões de teste desta seção. Para simular ou ganho ou a perda da contestação, forneça comprovantes de ganho/perda.

Comprovante

Para simular o ganho ou perda da contestação, responda com um dos valores de comprovante da tabela abaixo.

• Se você responder usando a API, passe o valor da tabela como uncategorized_text.
• Se você responder no Dashboard ou nos componentes incorporados do Connect, insira o valor da tabela no campo Informações adicionais. Em seguida, clique em Enviar comprovantes.

Simule um reembolso assíncrono

No modo de produção, os reembolsos são assíncronos: um reembolso pode parecer bem-sucedido e falhar depois ou pode aparecer como pendente 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).

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. Os ambientes de teste simulam esse período permitindo que você cancele um reembolso de cartão em 30 minutos.

Envie fundos para seu 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.

Teste a 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.

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.

Suporte 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.

Todas as referências do 3DS indicam 3D Secure 2.

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.

Simule um desafio 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.

Simule um pagamento presencial com um PIN

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 terminal da Stripe para obter mais informações.

Teste um Webhook ou destino de evento

Para testar o endpoint do webhook ou o destino do evento, escolha uma destas duas opções:

1. Execute ações em uma área restrita que enviem eventos legítimos ao destino do evento. Por exemplo, para acionar o evento charge.succeeded, você pode usar um cartão de teste que gera uma cobrança bem-sucedida.
2. Acione eventos usando o Stripe CLI ou usar o Stripe para Visual Studio Code.

Limitações de fluxo

Se suas solicitações em ambientes de teste começarem a receber erros HTTP 429, reduza a frequência dessas solicitações. Esses erros vêm da nossa limitação de fluxo, que é mais rigorosa em ambientes de teste do que no modo de produção.

Não recomendamos testes de carga da integração usando a API Stripe em ambientes de teste. Como o limitador de carga é mais rigoroso em ambientes de teste, você poderá encontrar erros que não veria em produção. Consulte Teste de carga para uma abordagem alternativa.

Teste uma forma de pagamento que não seja um cartão

Sempre que usar um teste da forma de pagamento que não seja um cartão, use as 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:

Testar o Link

No momento, o Link só funciona com cartões de crédito, cartões de débito e compras qualificadas de contas bancárias dos EUA. O Link requer registro de domínio.

Você pode criar contas de área restrita para o Link usando qualquer endereço de e-mail válido. A tabela a seguir mostra os valores fixos de senha de uso único que a Stripe aceita para autenticar contas de área restrita:

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.

Teste um fluxo baseado em redirecionamento

Para testar a lógica de gerenciamento de redirecionamento da sua integração simulando um pagamento que usa um fluxo de redirecionamento (por exemplo, iDEAL), use uma forma de pagamento compatível que exija redirecionamentos.

Para criar um PaymentIntent de teste bem-sucedido ou com falha:

1. Acesse as configurações das formas de pagamento no Dashboard e ative uma forma de pagamento compatível clicando em Ativar no seu ambiente de teste.
2. Colete dados de pagamento.
3. Envie o pagamento para a Stripe.
4. Autorize ou gere falha no pagamento de teste.

Verifique se a página (correspondente a return_url) no seu site fornece o status do pagamento.