Testes

Para confirmar se sua integração funciona corretamente, simule transações sem mover nenhum dinheiro usando valores especiais enquanto estiver no modo de teste ou em áreas restritas.

Os cartões de teste funcionam como cartões de crédito falsos e permitem simular vários cenários:

• Pagamentos sucedidos por marca ou país do cartão
• Erros de cartão devidos a pagamentos recusados, fraudes ou dados inválidos
• Contestações e reembolsos
• Autenticação com 3D Secure e PINs

Os testes de pagamentos sem cartão funcionam de maneira semelhante. Cada forma de pagamento tem seus próprios valores especiais. Devido às limitações de fluxo, não recomendamos o uso de ambientes de teste para testar cargas na integração. Em vez disso, consulte testes de carga.

Como usar cartões de teste

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.

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 da API ou programação do lado do servidor, mesmo em ambientes de teste. Se você usá-los, seu código pode não estar em conformidade com 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

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.

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.

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.

Cartões de teste HSA e FSA

Veja abaixo os números de cartões de teste para simular transações usando contas-poupança para saúde (HSA) e contas de gastos flexíveis (FSA). Essas contas normalmente são usadas para despesas médicas, e os testes com elas garantem o tratamento adequado de transações relacionadas à assistência médica dentro do seu aplicativo.

Pagamentos recusados

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.

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.

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 de cartão que falha na verificação de Luhn, como 4242424242424241
  .

Contestações

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

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, informe o valor da tabela no campo Mais informações e clique em Enviar comprovante.

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

Você só 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.

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.

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.

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.

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.

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.

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.

Destinos de evento

To test your webhook endpoint or event destination, choose one of these two options:

1. Perform actions in a sandbox that send legitimate events to your event destination. For example, to trigger the charge.succeeded event, you can use a test card that produces a successful charge.
2. Trigger events using the Stripe CLI or using Stripe for Visual Studio Code.

Limitações de fluxo

Se as solicitações em seus ambientes 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 rigoroso em ambientes de teste do que no modo em tempo real.

Não recomendamos realizar testes de carga da integração com a API Stripe em ambientes de teste. Como o limitador de carga é mais restrito em ambientes de teste, podem ocorrer erros que não acontecem no modo de produção. Consulte 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:

Link

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:

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:

1. Acesse as configurações de formas de pagamento no Dashboard e ative uma forma de pagamento aceita clicando em Ativar no ambiente de testes.
2. Coletar 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.