3-D Secure 2. 0 e SCA

1) Porquê a operadora iGaming 3DS2 e o que é SCA

3-D Secure 2. x (EMV 3DS) - Protocolo de autenticação do portador de cartão no e-commerce.
SCA é uma exigência regulatória (PSD2/UK) que obriga a verificação de dois efeitos em vários cenários.

• Liability shift: se a autenticação for bem sucedida, o risco de fraude passa para o emissor.
• Acima da conversão vs 3DS1: coleta 100 + dados permite frictionless sem challenge.
• Cenários nativos: SDK para iOS/Android, in-app, decoupled e out-of-band confirmação.

2) Papéis e componentes (EMV 3DS)

3DS Server (com você ou com o PSP): cria solicitações para o esquema, agregando dados de device, gerenciando versões 2. 1/2. 2/2. 3.
Direy Server (DS): roteador de circuitos (Visa/Mastercard/AmEx etc.).
ACS: servidor emissor; decide: frictionless ou challenge.
SDK/Method: coleta de sinais device (fingerprinting), web-SDK/iframe e mobile-SDK.

3) Fluxos UX típicos

3. 1 Frictionless (sem challenge)

1. Merchant/PSP → DS: AReq com dados 3DS (histórico, sinais de risco).
2. DS/ACS → ARes (frictionless): Autenticação superada sem participação do usuário.
3. A seguir → autorização (Auth).

Quando o risco é baixo, whitelist (Trusted Benficary), LVP, dados de qualidade.

3. 2 Challenge (com challenge)

1. O ARes requer CReq/CRES (OTP, comprovante de perna no banco, biometria).
2. Após o sucesso da →, a permissão, a liability shift foi salva.

3. 3 Decoupled / Out-of-Band

Confirmação no aplicativo do banco sem Redirect. Bom para os cenários mobil.

3. 4 3RI (3DS Requestor Initiated)

Usado para MIT (transações iniciadas merchant) - subscrição, retraí. Não há SCA em cada repetição, mas é necessário um link correto para o CIT inicial.

4) SCA: onde é obrigatório e onde funciona

Obrigatório: a maioria das transações e-commerce em EEA/UK, se o emissor e o equador estiverem na zona SCA.
Fora da área/Out-of-scope: MOTO (e-mail/telefone), alguns canais corporativos, rotas interzonais (pode ser aplicado por um emissor TRA).

4. 1 Exceções (Excemptions)

TRA: baixo risco do provedor/banco (confirmado por métricas de frode).
LVP (Low-Value Payments): pequenas somas, com liminares e contadores de emissor.
Whitelist (Trusted Benficiary): Beneficiário na lista branca do cliente do emissor.
Secure Corporate/Merchant Iniciated (MIT): cancelamentos posteriores fora do SCA, se houver CIT inicial com SCA e links corretos.

5) Marcação de transações e bandeiras para iGaming

CIT (Customer Iniciated Direction): cancelamento primário, normalmente exigido por SCA (ou exempção).
MIT Recurring/Unscheduled COF: cancelamentos posteriores; não necessitam de SCA se houver um vínculo com o CIT inicial (links/identificadores interligados).
Indicadores corretos nas solicitações de PSP/esquema são críticos para a liability shift e para o passe SCA em repetições.

6) Dados que afetam a solução ACS

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Conta data: idade da conta, data da última senha, número de ingressos pendentes.
• Mudança data: SS/categoria, soma/moeda, tentativas anteriores, velocity.
• Shipping/Billing: correspondência de endereços, histórico do destinatário.
• 3DS method competition indicator: se o 3DS Method (fingerprint) chegou a tempo.
• Quanto mais rico o contexto, maior a chance de frictionless.

7) Fluxos de integração com orquestrador de pagamentos

7. 1 Sequência (web/mobile)

1. O Iniciate 3DS (3DS Server ↔ DS/ACS) → obter o ARES.
2. Se o challenge → trabalhar CReq/CRES por SDK/iframe.
3. Sucesso do → Auth (autorização) com o resultado 3DS (ECI, CAVV/cryptograma, dsTransID).
4. Webhook PSP → orquestrador → Ledger/DWH (sem PAN).

7. 2 Soft-decline e retais

A autorização sem SCA pode retornar 'soft-decline (código)' → repetir o pagamento com o SCA.
O orquestrador mantém uma máquina de tentativa state no SCA → soft-decline → 3DS2 → Auth.

7. 3 Multi-PSP

Verifique o suporte às versões 3DS (2. 1/2. 2/2. 3), app-SDK, decoupled.
Smart-roting: Ao degradar ACS em parte dos emissores, use o caminho de reserva (se as políticas/esquemas permitirem).

8) Pattern Ux que aumentam a conversão

Native/SDK em aplicativos móveis: menos redits, mais completação.
Pré-collect de dados (e-mail, endereço, sinais comportamentais) até 3DS.
Telas de espera transparentes e textos compreensíveis (localização por idioma/região).
Temporizações com reembolso suave e reaproveitamento de challenge.
Whitelisting prompt: Sugira que o cliente adicione merchant a um banco de confiança (onde estiver disponível).

9) Erros e casos extremos

Timeout/Unavailable ACS → códigos corretos e repetição (ou fallback de política).
Version downgrade: se 2. 2/2. 3 não disponível, reversão à versão compatível.
Partial method: Se o 3DS Method falhar, envie ainda AReq - melhor dados parciais do que zero.
Mixed flows: 3DS + verificação de AVS simultaneamente - Muppem corretamente as estatais.
Marceback após 3DS: conteste com artefatos (ECI, CAVV, ARES/CRES refs).

10) Documentos e artefactos que devem ser armazenados

Identificadores de transação 3DS (dsTransID, threeDSServerTransID).
Resultados de autenticação (ECI, CAVV/AVV, ARes/CRES estates).
Logs SDK (sem PII/PAN), temporizadores e códigos de erro.
Links MIT para o CIT inicial para assinaturas/repetições.
Políticas de processamento de soft-decline e TRA-exceções.

11) Métricas e alvos (KPI para iGaming)

Conversão

3DS complition rate (taxa de autenticação concluída com sucesso).
Frictionless vs challenge (alvo: ↑ frictionless).
Abandonment rate em ecrãs 3DS.

Risco

Frod-reit após liability shift (abaixo - melhor).
Proporção de soft-decline e sucesso de retrações posteriores com 3DS.

Técnica

Tempo 3DS p95 (iniciação → resultado).
Erros SDK/iframe, temporizações ACS.

12) Folha de cheque de lançamento 3DS2 + SCA

• 3DS Server está conectado (versão 2. 1/2. 2/2. 3), teste-bins trabalhados.
• O SDK/mobile-SDK está integrado (in-app + webview).
• A coleta de-vice/browser data está ativada (3DS Method).
• As marcações CIT/MIT/COF são corretas; armazenado um link para o CIT inicial.
• Fluxo soft-decline → repetição com SCA implementado no orquestrador.
• As Excemptions (TRE/LVP/whitelist) são configuradas e as razões/resultados são logadas.
• Multi-PSP: versão 3DS e caminho fallback testados.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• Políticas de armazenamento de artefatos 3DS e playbooks dispute estão prontas.
• Os testes A/B das dicas UX (localização, textos, temporizações) estão programados.

13) Relação com o PCI DSS e o torneamento

O 3DS2 não substitui o PCI DSS, que é sobre autenticação, e o PCI, sobre proteção de dados.
Para safe PAN: digite um cartão no hosted fields/iframe; o orquestrador só vê tocens e artefatos 3DS (ECI/CAVV).
Para o COF/MIT, use a rede tocens ou vault-tokens para reduzir o frod e aumentar a permissão.

14) FAQ curta

É sempre necessário fazer 3DS? Na zona SCA, sim, se não houver uma exempção/exceção correta. O emissor pode precisar de um challenge.
Se o banco partiu? Use políticas de retrações/temporizações e, se possível, uma rota diferente.
O 3DS vai aumentar a conversão? O 3DS2 configurado corretamente com dados ricos aumenta a proporção de frictionless e reduz o frod/charjbacks.
O que é mais crítico para o sucesso? Dados contextuais ricos, bandeiras CIT/MIT/COF corretas, UX rápido e processamento de soft-decline.

15) Resumos

Para o iGaming 3DS2 + SCA não é uma «dor obrigatória», mas uma ferramenta de crescimento: mais frictionless, menos frod, transferência de responsabilidade para o emissor, monetização estável de assinaturas e cancelamentos repetidos. Coloque as bandeiras certas (CIT/MIT/COF), mantenha as excempções de acordo com as regras, garanta a entrada pan-segura e construa uma orquestração com retalhos inteligentes e observabilidade - para que a autenticação seja um aliado e não um freio de conversão.