Testes de 3D Secure: 3DS1 vs 3DS2 e cartões de teste que acionam cada fluxo
O 3D Secure (3DS) é a camada de autenticação que transfere a responsabilidade por fraudes dos comerciantes para os emissores. Também é a parte dos testes de checkout que mais quebra, porque envolve redirecionamentos, iframes, SDKs mobile e resultados assíncronos. Este guia aborda o que testar, quais cartões de teste disparam cada fluxo e os bugs que sempre passam despercebidos.
3DS1 vs 3DS2 em um parágrafo
3DS1 é o fluxo original de redirecionamento no navegador: o cliente sai da sua página, se autentica na página do emissor e volta com um resultado. O 3DS2 substitui o redirecionamento por um SDK ou pela impressão digital do dispositivo: o emissor recebe dados adicionais do dispositivo e da transação e pode aprovar sem atrito (sem interação do usuário) ou emitir um desafio (um modal na própria página, ou um redirecionamento como alternativa nos navegadores que não suportam o SDK). A maioria dos gateways de pagamento ainda suporta 3DS1 para integrações antigas, então um plano de testes real cobre os dois.
Os três resultados que você precisa tratar
Toda transação 3DS termina de uma de três formas, e as três exigem estados de interface explícitos:
- Sucesso sem atrito: a autenticação é concluída sem interação do usuário. É o resultado mais comum do 3DS2.
- Desafio: o cliente é solicitado a se autenticar (OTP, aprovação no app). Trate tanto o sucesso quanto a falha ou o cancelamento.
- Não inscrito / não suportado: o cartão não participa. Dependendo da configuração do seu gateway de pagamento, a transação prossegue ou falha.
Os caminhos de falha são onde os checkouts quebram: um desafio cancelado não é o mesmo que uma recusa, e os usuários que fecham o modal precisam conseguir tentar de novo sem refazer todo o carrinho.
Cartões de teste da Stripe para fluxos 3DS
A Stripe documenta números de teste específicos para cada comportamento de autenticação:
| Número do cartão | O que dispara |
|---|---|
| 4000 0025 0000 3155 | Exige autenticação 3D Secure |
| 4000 0027 6000 3184 | Exige 3DS para que o pagamento seja aprovado |
| 4000 0000 0000 3055 | Suporta 3D Secure 2 |
| 4000 0000 0000 3220 | 3DS2: obriga a concluir o fluxo de desafio |
Esses cartões foram criados apenas para uso em sandbox. Para outros provedores, a Adyen documenta 4917 6100 0000 0000 para cenários 3DS1, além dos cartões genéricos de sucesso (4242…, 4111 1111 1111 1111) no sandbox. Sempre confira a documentação atual do provedor: o comportamento dos cartões de teste muda sem aviso.
Uma lista mais completa está na nossa referência de números de cartão de teste.
Checklist de configuração do sandbox
- Ative o 3DS no painel do gateway de pagamento, não apenas na chamada de API. Muitos gateways têm um botão por conta que desativa a autenticação no modo de teste sem avisar.
- Use o SDK do 3DS2 quando disponível e teste o fallback de redirecionamento separadamente.
- Adicione as URLs de retorno à lista de permissões em todos os ambientes, incluindo túneis de desenvolvimento local.
- Teste em dispositivos móveis reais, não apenas estreitando a janela no desktop. Os navegadores internos de apps (Instagram, TikTok, apps de bancos) se comportam diferente do Safari e do Chrome.
- Mantenha a janela do desafio responsiva. Um desafio renderizado dentro de um iframe de altura fixa é um clássico assassino de conversões.
Bugs que passam despercebidos
- Perder o carrinho no redirecionamento. Persista o pedido antes de iniciar a autenticação, não depois.
- Não tratar o botão voltar. Os navegadores restauram a página pelo bfcache; seu JavaScript precisa consultar novamente o estado do pagamento em vez de assumir um carregamento novo.
- Envio duplicado. Os usuários clicam em "Pagar" duas vezes enquanto o desafio está aberto. Use chaves de idempotência na requisição de autorização.
- Assumir sucesso depois do desafio. O resultado da autenticação é um sinal separado; a autorização ainda pode ser recusada depois.
- Ignorar os webhooks assíncronos. Alguns fluxos 3DS2 são concluídos de forma assíncrona. Se você escutar apenas o redirecionamento, vai perder resultados.
- Valor ou moeda errados. A autenticação está vinculada à intenção de pagamento; alterar o carrinho entre a autenticação e a captura a invalida.
Como testar sem cartões reais
Você não precisa de um cartão real para testar 3DS. Os cartões de teste do provedor somados a dados gerados cobrem toda a matriz:
- Use os cartões do provedor para os fluxos de sucesso autenticado, falha e sem atrito.
- Use o nosso gerador de cartões para produzir grandes volumes de números estruturalmente válidos para testes de carga, fuzzing e interface.
- Use o gerador avançado quando precisar de todas as combinações de um padrão específico.
- Valide qualquer número de teste com o validador de Luhn.
Resumo
Os testes de 3DS são, em grande parte, sobre cobrir os caminhos difíceis: desafios cancelados, autenticação falha, resultados assíncronos e navegadores móveis. Os cartões de teste do provedor disparam cada fluxo de forma deliberada, e um conjunto de dados gerado preenche as lacunas. Trate a autenticação como uma máquina de estados separada da autorização e você evitará a maioria dos incidentes em produção.