Teste sua integração com o Stripe.
Conheça os diferentes métodos para testar a sua integração com o Stripe antes de a lançar.
Ele não é um desenvolvedor?
Contrate um especialista certificado aqui Você pode fazer você mesmo ou usar uma solução pré-desenhada criada por um de nossos parceiros verificados (sem necessidade de código).
Esta página inclui números de cartões de teste e outras informações para garantir que sua integração funcione conforme o esperado. Use-a para acionar diferentes fluxos em sua integração e certifique-se de que sejam tratados adequadamente.
API de intenção de pagamento
Ao usar a API Payment Intent com as bibliotecas de cliente e SDKs do Stripe, certifique-se de que:
- Os fluxos de autenticação são ativados quando necessário (utilizando os números de cartão e métodos de pagamento de teste regulamentares).
- Sem autenticação (cartão padrão dos EUA): 4242 4242 4242 4242.
- Autenticação necessária: 4000 0027 6000 3184.
- A tentativa de pagamento é criada com uma chave de chave de idempotência Para evitar a criação errônea de tentativas de pagamento duplicadas para a mesma compra.
- Os erros são detectados e exibidos corretamente na interface do usuário.
API de cobranças
Ao usar o API de cobranças Ao usar as bibliotecas de cliente e os SDKs do Stripe, certifique-se de que:
- O elemento do cartão foi passado com sucesso para criar o token no seu controlador de envio.
- No controlador de resposta para criação do Token, os erros de cartão são tratados e exibidos corretamente.
- Somente tokens válidos são enviados para o seu servidor como parte do processo de submissão do formulário de pagamento.
Código do lado do servidor
No seu código do lado do servidor, certifique-se de que:
- Todas as solicitações estão sendo processadas com sucesso. Pode ser útil visualizar os eventos e registros da sua conta enquanto testa a integração.
- Todos os erros da API são tratados corretamente.
- Os webhooks relevantes são tratados corretamente.
- Quando estiver pronto para lançar sua integração, substitua sua chave secreta de teste e as chaves de API publicáveis pelas chaves de produção. Pagamentos em produção não poderão ser processados se sua integração ainda estiver usando as chaves de teste.
Números básicos de cartões de teste
As informações originais do cartão não podem ser usadas no modo de teste. Em vez disso, use qualquer um dos seguintes números de cartão de teste, uma data de validade futura válida e um código CVC aleatório para criar um pagamento bem-sucedido. O país de faturamento para cada cartão de teste básico está definido como os EUA. Se precisar criar pagamentos com cartões de teste de outros países de faturamento, use nossos cartões de teste internacionais.
|
Sessão |
Marcas |
CVC |
Data |
|---|---|---|---|
|
|
Visa | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Visa (débito) | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
MasterCard | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Mastercard (série 2) | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Mastercard (débito) | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Mastercard (pré-pago) | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
American Express | Quaisquer 4 dígitos | Qualquer data no futuro |
|
|
American Express | Quaisquer 4 dígitos | Qualquer data no futuro |
|
|
Descubra | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Descubra | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Diners Club | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
Diners Club (cartão de 14 dígitos) | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
JCB | quaisquer 3 dígitos | Qualquer data no futuro |
|
|
UnionPay | quaisquer 3 dígitos | Qualquer data no futuro |
Recomendamos o uso de nossos IDs de teste ao testar sua integração e gerar cobranças, em vez de enviar informações de cartão diretamente para a API. O uso desses IDs de teste em vez de números de cartão ajuda a garantir que sua integração em produção esteja em conformidade com o PCI e não manipule informações de cartão diretamente. Cada ID de teste é legível e representa informações de cartão que foram tokenizadas usando nossas bibliotecas do lado do cliente (por exemplo, Stripe Elements, Stripe.js).
Números de cartão de teste internacional
Você pode usar qualquer um dos seguintes cartões de teste para simular um pagamento bem-sucedido para diferentes países de faturamento.
|
Sessão |
Token |
Pagamentos |
País |
Marcas |
|---|---|---|---|---|
|
|
tok_us |
pm_card_us |
Estados Unidos (EUA) | Visa |
|
|
tok_br |
pm_card_br |
Brasil (BR) | Visa |
|
|
tok_ca |
pm_card_ca |
Canadá (CA) | Visa |
|
|
tok_mx |
pm_card_mx |
México (MX) | Visa |
Números de cartão de teste regulamentar (3D Secure)
As informações de cartão a seguir testam pagamentos afetados por regulamentações regionais, como a Autenticação Forte do Cliente (SCA). Use-as para testar cartões de desconto com a API Setup Intents.
|
Sessão |
Descrição |
|---|---|
|
|
Este cartão requer autenticação para pagamentos únicos. No entanto, se você Configure este cartão e utilize o cartão salvo para pagamentos subsequentes fora da sessão, sem necessidade de autenticação adicional. |
|
|
Este cartão requer autenticação em todas as transações, independentemente de como o cartão esteja configurado. |
|
|
Este cartão requer autenticação para pagamentos únicosTodos os pagamentos serão recusados com um insufficient_funds código de falha mesmo após autenticação bem-sucedida ou anteriormente estabelecer. |
|
|
Este cartão requer autenticação para um tempo e outro em sessão pagamentos. No entanto, todos pagamentos fora do período letivo terá sucesso como se o cartão já tivesse sido usado anteriormente. estabelecer. |
Números de cartão e tokens de teste 3D Secure
Nem todos os cartões são compatíveis com o 3D Secure ou exigem que você redirecione o cliente para a página de autenticação da emissora do cartão. Use as informações do cartão abaixo para testar pagamentos com 3D Secure; observe que os redirecionamentos do 3D Secure não ocorrerão para pagamentos criados diretamente no painel do Stripe.
|
Sessão |
Uso do 3D Secure |
Descrição |
|---|---|---|
|
|
Exigido | A autenticação 3D Secure 2 deve ser concluída para que o pagamento seja bem-sucedido. Por padrão, suas regras do Radar solicitarão a autenticação 3D Secure para este cartão. |
|
|
Exigido | A autenticação 3D Secure deve ser concluída para que o pagamento seja bem-sucedido. Por padrão, suas regras do Radar solicitarão a autenticação 3D Secure para este cartão. |
|
|
Exigido | A autenticação 3D Secure é obrigatória, mas os pagamentos serão recusados com um erro. card_declined Código de falha após a autenticação. Por padrão, suas regras do Radar solicitarão autenticação 3D Secure para este cartão. |
|
|
Exigido | A autenticação 3D Secure é necessária, mas a solicitação de consulta 3D Secure falhará com um erro de processamento. Os pagamentos serão recusados. card_declined Código de falha. Por padrão, suas regras do Radar solicitarão autenticação 3D Secure para este cartão. |
|
|
Suportado | A autenticação 3D Secure ainda pode ser realizada, mas não é obrigatória. Por padrão, suas regras do Radar não solicitarão autenticação 3D Secure para este cartão. |
|
|
Suportado | A autenticação 3D Secure ainda pode ser realizada, mas não é obrigatória. No entanto, tentativas de realizar a autenticação 3D Secure resultarão em um erro de processamento. Por padrão, suas regras do Radar não solicitarão a autenticação 3D Secure para este cartão. |
|
|
Suportado | O 3D Secure é compatível com este cartão, mas ele não está cadastrado no 3D Secure. Isso significa que, se o 3D Secure for solicitado pelas suas regras do Radar, o cliente não passará por autenticação adicional. Por padrão, suas regras do Radar não solicitarão autenticação 3D Secure para este cartão. |
|
|
Não suportado | O 3D Secure não é compatível com este cartão e não pode ser ativado. A intenção de pagamento prosseguirá sem realizar a autenticação. |
Todos os outros cartões de teste Visa e Mastercard não exigem autenticação da instituição emissora do cartão do cliente.
Testando respostas específicas e erros
Você pode usar os seguintes cartões de teste para criar pagamentos que geram respostas específicas, úteis para testar diferentes cenários e códigos de erro. As verificações só são executadas quando as informações necessárias são fornecidas (por exemplo, um código CVC deve ser fornecido para que o verificador de CVC falhe).
|
Sessão |
Descrição |
|---|---|
|
|
A cobrança foi concluída com sucesso e os fundos serão adicionados diretamente ao seu saldo disponível (ignorando o saldo pendente). |
|
|
A cobrança foi concluída com sucesso e os fundos serão adicionados diretamente ao seu saldo disponível (ignorando o saldo pendente). |
|
|
A cobrança é bem-sucedida e utiliza-se a tarifa nacional (outros cartões testados utilizam a tarifa internacional). Este cartão só é relevante em países com preços diferenciados. |
|
|
As address_line1_check e address_zip_check As verificações falharam. Se a sua conta for Bloquear pagamentos que não passarem na validação do código postal.A cobrança foi recusada. |
|
|
O ataque é bem-sucedido, mas o address_line1_check A verificação falhou. |
|
|
As address_zip_check A verificação falhou. Se a sua conta for Bloquear pagamentos que não passarem na validação do código postal.A cobrança foi recusada. |
|
|
O ataque é bem-sucedido, mas o address_zip_check e address_line1_check as verificações são ambas unavailable. |
|
|
O ataque é bem-sucedido, mas O reembolso de uma cobrança já efetuada falha. assincronamente com um failure_reason of expired_or_canceled_cardObserve que, como as falhas de reembolso são assíncronas, o reembolso parecerá ter sido bem-sucedido inicialmente e terá apenas o failed status em buscas subsequentes. Também notificamos você sobre falhas de reembolso usando o charge.refund.updated webhooks evento. |
|
|
A cobrança é bem-sucedida, mas os reembolsos são inicialmente retidos no caixa. pending estado. Algum tempo depois, o reembolso é liberado do status de pendente e envia um charge.refund.updated webhooks evento. |
|
|
Se um número CVC for fornecido, o cvc_check falha. Se sua conta for Bloquear pagamentos que não passarem na validação do código CVC.A cobrança foi recusada. |
|
|
Anexar este cartão a um O cliente O objeto é processado com sucesso, mas as tentativas de cobrança ao cliente falham. |
|
|
Resulta em uma acusação com um risk_level of elevado. |
|
|
Resulta em uma acusação com um risk_level of mais. |
|
|
Resulta em uma acusação com um risk_level of maisA cobrança foi bloqueada por ser considerada fraudulenta. |
|
|
A cobrança foi recusada com um card_declined código. |
|
|
A cobrança foi recusada com um card_declined código. o código_de_declínio atributo é insufficient_funds. |
|
|
A cobrança foi recusada com um card_declined código. o código_de_declínio atributo é lost_card. |
|
|
A cobrança foi recusada com um card_declined código. o código_de_declínio atributo é stolen_card. |
|
|
A cobrança foi recusada com um expired_card código. |
|
|
A cobrança foi recusada com um incorrect_cvc código. |
|
|
A cobrança foi recusada com um processing_error código. |
|
|
A cobrança foi recusada com um incorrect_number O código, pois o número do cartão falha. Luhn verifica. |
|
|
A cobrança é bem-sucedida e retorna um brand_product of MWE. |
Por padrão, incluir o endereço ou o código de segurança (CVC) juntamente com o número do cartão garante a verificação bem-sucedida do endereço e do CVC. Se essas informações não forem especificadas, as verificações serão inválidas. Qualquer data de validade futura será considerada válida.
Você também pode fornecer detalhes de cartões inválidos para testar códigos de erro específicos resultantes de informações incorretas. Por exemplo:
- invalid_expiry_month: Use um mês inválido (por exemplo, 13)
- invalid_expiry_year: Use um ano no passado (por exemplo, 1970)
- invalid_cvc: Use um número de dois dígitos (por exemplo, 99)
Números de cartão de teste Cartes Bancaires
No modo de teste, você pode usar os cartões de teste abaixo para simular uma cobrança do Cartes Bancaires:
|
Sessão |
Descrição |
|---|---|
|
|
Cria um método de pagamento com cartão Cartes Bancaires em parceria com a Visa. |
|
|
Cria um método de pagamento com cartão Cartes Bancaires em parceria com a Mastercard. |
disputas
No modo de teste, você pode usar os cartões de teste abaixo para simular uma transação contestada:
Envie qualquer um dos seguintes valores de texto não categorizados para comprovar o resultado de uma disputa, seja ela ganha ou perdida:
|
evidência |
Descrição |
|---|---|
winning_evidence |
A disputa foi encerrada e marcada como ganha. O valor da cobrança e as taxas relacionadas foram creditados em sua conta. |
losing_evidence |
A disputa foi encerrada e marcada como perdida. Sua conta não foi creditada. |
Você também pode usar esses valores para testar os resultados das disputas em o painelInsira um destes valores no campo Informação adicional durante o processo de submissão de provas e, em seguida, clique em Enviar provas.
Link com Stripe
Você pode criar contas de teste para o Link com o Stripe usando qualquer endereço de e-mail válido. Você pode usar códigos de acesso fixos e de uso único para autenticar contas de teste, conforme descrito abaixo:
|
Valor |
Resultado |
|---|---|
| Quaisquer outros 6 dígitos não listados abaixo. | A autenticação foi bem-sucedida. |
| 000001 | A autenticação falhou porque a senha de uso único é inválida. |
| 000002 | A autenticação falhou porque a senha de uso único expirou. |
| 000003 | A autenticação falhou porque o número máximo de tentativas foi excedido. |
Limites de tarifa
É altamente improvável que os usuários experimentem limites de taxa com o uso normal da API, mesmo em volumes elevados. As causas mais comuns de limites de taxa são erros, recuperação massiva de dados ou testes de carga extremos.
Se suas requisições começarem a receber erros HTTP 429, reduza a frequência delas. É seguro tentar novamente cada requisição com falha, pois a limitação de taxa ocorre antes de qualquer outra ação e impede que a requisição seja processada. Ao reduzir a frequência das requisições, recomendamos o uso de um backoff exponencial, aguardando um segundo antes de tentar novamente. Se a requisição continuar recebendo a mesma resposta, aguarde dois segundos, depois quatro segundos e assim por diante.
O limite de frequência no modo de teste é menor do que no modo de produção. Se você tiver limites tarifários, mas não souber o motivo, entre em contato conosco.
Fontes
Utilize as informações a seguir ao testar pagamentos por meio das fontes.
Redirecionar fontes
Ao criar um objeto de origem de teste que usa um fluxo de redirecionamento (por exemplo, iDEAL), você pode seguir a URL retornada no campo de redirecionamento [url]. Isso leva a uma página do Stripe que exibe informações sobre a solicitação da API e onde você pode autorizar ou cancelar o pagamento.
Após autorizar o pagamento, você será redirecionado para o URL especificado no redirecionamento [return_url].
Débito direto BECS na Austrália
Você pode criar um PaymentIntent de teste que seja bem-sucedido ou falhe fazendo o seguinte:
Crie um método de pagamento de teste usando o código BSB de teste 000-000 e um número de conta de teste da lista abaixo.
Utilize o PaymentMethod resultante em uma solicitação confirmAuBecsDebitPayment para criar a cobrança de teste.
Números de comprovação de conta
|
Número de Conta |
Descrição |
|---|---|
000123456 |
O status PaymentIntent transita de processing para succeededO mandato permanece em vigor. active. |
900123456 |
O status PaymentIntent transita de processing para succeeded (com um atraso de três minutos). O status do mandato permanece active. |
111111113 |
O status PaymentIntent transita de processing para requires_payment_method com um account_closed código de falha. O status do mandato mudará para inactive. |
111111116 |
O status PaymentIntent transita de processing para requires_payment_method com uma no_account código de falha. O status do mandato mudará para inactive. |
222222227 |
O status PaymentIntent transita de processing para requires_payment_method com uma refer_to_customer código de falha. O status do mandato permanecerá inalterado. active. |
922222227 |
O status PaymentIntent transita de processing para requires_payment_method com uma refer_to_customer Código de falha (com um atraso de três minutos). O status do mandato permanecerá inalterado. active. |
333333335 |
O status PaymentIntent transita de processing para requires_payment_method com uma debit_not_authorized código de falha. O status do mandato mudará para inactive. |
Webhooks
Consulte a seção Webhooks para aprender como instalar e configurar um endpoint.
Para testar sua integração, execute ações usando a API (em modo de teste) para enviar eventos legítimos ao seu endpoint. Por exemplo, a criação de uma cobrança aciona o evento `charge.succeeded`, que contém os dados da cobrança. Você pode facilmente acionar eventos usando a CLI do Stripe ou o Stripe para Visual Studio Code. Em seguida, você pode usar a API para verificar os dados do evento resultante. Se você estiver migrando para a API Payment Intent, consulte também Monitorando uma Intenção de Pagamento com Webhooks.
Você também pode enviar eventos de teste para o seu endpoint de integração nas configurações de webhooks da sua conta. No entanto, os dados contidos nesses eventos são fictícios e não estão disponíveis na API; seu propósito é apenas testar se o seu endpoint está funcionando e configurado corretamente.
[hover_color align="center" background="" background_hover="" border="" border_hover="" border_width="0px" padding="60px 60px" link="https://selfish.com.mx/servicios/" target="" class="cta-blog themecolorbg" style=""] Pronto para levar seu e-commerce para outro nível? [/hover_color]
