3-D Secure 2.x: Protocolo, Fluxos e Mitigação de Fraude

Os 5 atores do ecossistema

• Cardholder — o portador do cartão (quem está comprando).
• Merchant / PSP — a loja virtual ou o gateway de pagamento que inicia o processo.
• 3DS Server (3DSS) — servidor técnico (geralmente fornecido pelo PSP/adquirente) que orquestra a mensagem do lado do lojista.
• Directory Server (DS) — ecossistema da bandeira (Visa, Mastercard, Elo) que valida as chaves e roteia a transação.
• Access Control Server (ACS) — o cérebro do banco emissor (ex: Itaú, Nubank) que autentica o portador.

O fluxo de autenticação (3DS 2.2)

[Browser/App] ─► (3DS Method / Device Data) ─► [3DSS]
   └─► (AReq: ~150 campos) ─► [DS Bandeira] ─► [ACS Emissor]
                                                   │
              ┌────────────────────────────────────┴────────────────────────────────────┐
              ▼                                                                          ▼
      [ Frictionless ]                                                          [ Challenge ]
      Aprovação instantânea                                                     Validação ativa do portador
      sem que o cliente perceba.                                                CReq/CRes via iframe/WebView:
                                                                                OTP, biometria ou push no app.

1. Coleta silenciosa (3DS Method): o navegador ou app do cliente coleta dados do dispositivo e os envia ao 3DSS.
2. A Requisição (AReq): o 3DSS monta a Authentication Request com cerca de 150 campos (BIN, valor, moeda, IP, histórico da conta) e envia ao Directory Server.
3. Roteamento: o DS direciona essa carga de dados para o ACS do banco emissor.
4. Tomada de decisão: o ACS analisa os dados e escolhe entre Frictionless (risco baixo, aprovação invisível) ou Challenge (risco suspeito, abre canal seguro CReq/CRes para OTP, biometria ou push notification).
5. Token de sucesso: as mensagens de resultado (RReq/RRes) finalizam o fluxo e geram o criptograma CAVV/ECI, que deve ser enviado junto com a requisição de autorização financeira para garantir o Liability Shift.

Dados que movem o ponteiro para o Frictionless

O banco emissor precisa de contexto para confiar na transação sem desafiar o cliente. Os campos mais críticos são:

• Consistência digital — browserUserAgent, browserAcceptHeader, browserLanguage, e combinação de resolução de tela com timezone.
• Intenção de compra (merchantRiskIndicator) — recompra, histórico de entrega no mesmo e-mail, vale-presente ou pré-venda.
• Maturidade da conta (acctInfo) — idade do cadastro na loja, modificações recentes de senha e histórico de tentativas falhas de pagamento.
• Relação comercial — histórico prévio de transações bem-sucedidas entre aquele portador específico e a sua loja.
• Isenções regulatórias — TRA Exemption (Transaction Risk Analysis) quando a taxa de fraude global do adquirente é extremamente baixa (comum sob PSD2 europeia).

Boas práticas de integração (lado merchant)

• Não invente a roda — colete os dados de dispositivo utilizando estritamente o SDK oficial do seu PSP. Coletas customizadas quebram as regras do EMVCo.
• Enriqueça o payload — preencha o objeto merchantRiskIndicator com o máximo de detalhes possível. Mais contexto para o emissor = maior taxa de frictionless.
• Antecipe o processo — execute o 3DS Method de forma invisível em um iframe assim que o cliente insere o número do cartão, antes mesmo do clique em Finalizar Compra.
• Amarre a autorização — garanta que os códigos ECI e CAVV retornados na autenticação sejam repassados integralmente na etapa de autorização. Sem eles, você perde o direito ao liability shift.
• Monitore por BIN — acompanhe taxas de conversão e challenge divididas por emissores. Se um banco específico força challenge em 100% das transações, acione seu adquirente para calibrar as regras junto à bandeira.