Testes de 3D Secure: como funciona o 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.

Do 3DS1 ao 3DS2 em um parágrafo

3DS1 era o fluxo original de redirecionamento no navegador: o cliente saía da sua página, se autenticava na página do emissor e voltava com um resultado. Visa, Mastercard e American Express desativaram o 3DS1 (3-D Secure 1.0.2) em outubro de 2022, e as últimas extensões regionais terminaram em 2023, então hoje os planos de teste só precisam cobrir o EMV 3DS (3DS2). O 3DS2 envia ao emissor muito mais dados do dispositivo e da transação, para que ele possa aprovar sem atrito (sem interação do usuário) ou emitir um desafio. Ele tem dois canais: um fluxo de navegador, que coleta dados do dispositivo por meio de um iframe oculto do 3DS Method e exibe o desafio em um iframe (ou em um redirecionamento hospedado pelo provedor), e um fluxo de app, que usa o SDK do 3DS em apps móveis nativos.

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:

1. Sucesso sem atrito: a autenticação é concluída sem interação do usuário. É o resultado mais comum do 3DS2.
2. Desafio: o cliente é solicitado a se autenticar (OTP, aprovação no app). Trate tanto o sucesso quanto a falha ou o cancelamento.
3. Não inscrito / não suportado: o cartão ou o emissor não participa. Ou nenhuma autenticação é executada, ou a bandeira responde em nome do emissor com uma tentativa (attempt). Dependendo da configuração do seu gateway de pagamento, a transação prossegue ou falha.

Por trás de tudo, cada resultado é um valor de transStatus: Y (autenticado), A (tentativa; normalmente ainda transfere a responsabilidade para o emissor), N (não autenticado), R (rejeitado; não autorize), U (indisponível, uma falha técnica sem transferência de responsabilidade). C e D indicam que um desafio ou uma autenticação desacoplada ainda está em andamento.

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:

Esses cartões foram criados apenas para uso em sandbox. Para outros provedores, a Adyen documenta 4917 6100 0000 0000 (Visa inscrito no 3DS2; validade 03/2030, CVC 737) para fluxos de desafio, e 4111 1111 1111 1111 entre seus cartões Visa de teste gerais. 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 em apps nativos e teste o fluxo de navegador (o iframe e qualquer redirecionamento que o seu provedor use) 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 cobre o valor e a moeda que você enviou; se o carrinho mudar, autentique novamente (na Stripe, alterar o valor de um PaymentIntent significa confirmá-lo outra vez).

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:

1. Use os cartões do provedor para os fluxos de sucesso autenticado, falha e sem atrito.
2. Use o nosso gerador de cartões para produzir grandes volumes de números estruturalmente válidos para testes de carga, fuzzing e interface.
3. Use o gerador avançado quando precisar de todas as combinações de um padrão específico.
4. 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.