Entenda 3‑D Secure (3DS): autenticação, desafios e falhas comuns em pagamentos

Por que isso importa

3‑D Secure (especialmente 3DS2) é o principal método técnico para autenticação pelo emissor em pagamentos online sem cartão físico; as falhas costumam ser por lacunas de integração, interrupções no dispositivo/UX, políticas do emissor, tratamento por gateways ou regras regionais de SCA — e há mitigação prática para cada caso.

O que é 3‑D Secure e versões em uso

3‑D Secure é um protocolo que integra a autenticação do emissor (ACS) no fluxo de finalização de compra online, permitindo que o emissor avalie risco ou desafie a transação antes da autorização. EMVCo mantém a especificação; implementações modernas usam EMV® 3‑D Secure (3DS2).

A EMVCo publica lançamentos v2.x — recomenda‑se v2.2 ou posterior para funcionalidades melhoradas; v2.3 adicionou suporte a WebAuthn/FIDO. Verifique a versão válida na data de publicação.

• 3DS conecta a solicitação do comerciante (AReq) ao ACS do emissor para avaliação de risco.
• Utilize EMVCo v2.x (recomendado >= v2.2) para reduzir atrito no checkout.

Como funciona um fluxo típico 3DS2

O comerciante envia um AReq com contexto de transação e dispositivo para o diretório da scheme e para o ACS do emissor. O emissor avalia o risco e pode retornar uma resposta frictionless ou iniciar um challenge (OTP, push app, WebAuthn).

Após a ARes, o comerciante prossegue com a autorização através do adquirente e da rede. O 3DS2 suporta dados mais ricos e SDKs nativos para aplicativos móveis, reduzindo challenges desnecessários.

• AReq → diretório/ACS → frictionless ou challenge → ARes → autorização.
• 3DS2 oferece suporte a WebAuthn e métodos OOB/app‑push.

Principais causas de falhas de autenticação

Falhas frequentes decorrem de: dados 3DS ausentes/incompletos (integração), interrupções no cliente (iframes bloqueados, troca de app), políticas do emissor e falta de suporte a 3DS2, problemas com OTP via SMS e erros do gateway ou de roteamento que não transmitem corretamente o resultado da autenticação.

Diagnóstico inclui verificar AReq quanto a campos obrigatórios, testar SDKs em contexto nativo, revisar códigos de recusa do emissor e confirmar o mapeamento dos resultados 3DS no fluxo do PSP.

• AReq incompleto → fallback ou recusa; garanta o envio de campos necessários.
• Interrupções no cliente → timeouts; prefira SDKs nativos.
• OTP via SMS é vulnerável; apoiar WebAuthn onde possível.
• Gateways podem falhar em propagar resultados de autenticação — testar em sandbox.

Mitigações práticas e boas práticas

Use um SDK 3DS2 aprovado pela EMVCo, envie o contexto completo do dispositivo/transação na AReq e teste em sandbox do seu PSP para reproduzir frictionless, challenge e timeout scenarios.

Melhore a experiência do usuário: explique o que esperar durante o challenge, aconselhe a não trocar de app durante a verificação, ajuste timeouts adequadamente e ofereça métodos alternativos de pagamento caso a autenticação falhe.

• Confirmar SDK na lista aprovada da EMVCo.
• Enviar todos os campos device/transaction obrigatórios na AReq.
• Testar com cartões de teste oficiais no ambiente sandbox.
• Implementar mensagens acionáveis e rotas de pagamento alternativas.

O que verificar

• Instalar e verificar um SDK 3DS2 aprovado.
• Enviar dados completos de dispositivo e transação na AReq.
• Testar fluxos em sandbox com cartões de teste do PSP.
• Fornecer instruções ao usuário durante o challenge e métodos alternativos.