3-D Secure 2: menos fricção, menos fraude, e de quem fica o chargeback

Todo mundo que opera cartão conhece o dilema, mesmo sem dar nome a ele. De um lado, você quer que a compra passe: cada verificação a mais no caminho é gente que desiste no meio. Do outro, quer barrar a fraude, porque o chargeback não volta só como estorno, volta como custo, como reputação e, às vezes, como bandeira te colocando num programa de monitoramento. Aprovar mais e fraudar menos puxam para lados opostos.

O 3-D Secure foi criado para afrouxar esse nó. A primeira versão, aquela da janela do banco pedindo senha no meio do checkout, resolvia a fraude e matava a conversão junto. A segunda geração, o 3DS2, reescreveu a lógica. E mudou também uma coisa que quase ninguém lê no contrato: de quem fica a conta quando a fraude acontece mesmo assim.

O que o 3DS2 mudou

O protocolo é mantido pela EMVCo, o mesmo consórcio das bandeiras (Visa, Mastercard e as outras) que padroniza o chip do cartão. A ideia central do EMV 3-D Secure 2 é simples de dizer e difícil de fazer: em vez de desafiar todo mundo, avaliar o risco de cada transação em tempo real e só interromper quando vale a pena.

Para isso, o lojista e a adquirência mandam para o emissor uma pilha de sinais junto com a compra: dados do dispositivo, histórico do portador, valor, comportamento, endereço, mais de cem pontos de contexto. Com esse retrato, o banco emissor decide o caminho. É ele quem tem a palavra final, não o lojista.

Daí saem dois fluxos. No frictionless, o emissor reconhece a transação como legítima e libera sem pedir nada: o cliente nem percebe que foi autenticado. No challenge, o banco viu algo que quer confirmar e aciona uma verificação, em geral um código no app, uma biometria ou um token. A régua não é sua nem da adquirência: é do emissor, e ela muda de banco para banco.

De quem fica o chargeback

Aqui está a parte que separa 3DS de teatro de segurança. Quando uma transação é autenticada via 3DS, seja no fluxo frictionless, seja no challenge, e depois o portador abre uma disputa alegando fraude, a responsabilidade muda de lado. É o chamado liability shift: em vez de o lojista comer o prejuízo, a conta vai para o banco emissor. Sem 3DS, o mesmo chargeback de fraude quase sempre para no seu colo.

Vale a letra miúda: cada bandeira publica as próprias regras de programa em cima do protocolo da EMVCo, então o shift não é automático em todo cenário. O que importa entender é o incentivo. Autenticar não é só reduzir fraude, é transferir o risco da fraude que restar. Por isso o resultado da autenticação não é um selo genérico; ele carrega uma nota de status que diz exatamente quem responde.

O contexto internacional que puxou tudo isso

Na Europa, o 3DS2 deixou de ser opcional. A diretiva PSD2 tornou a autenticação forte do cliente, a SCA (Strong Customer Authentication), obrigatória para a maioria dos pagamentos online, e o 3DS2 virou o trilho técnico para cumprir a regra sem destruir a conversão. Foi esse empurrão regulatório que amadureceu o protocolo e as integrações que hoje o mercado inteiro usa.

No Brasil o caminho é outro, mais por incentivo do que por lei geral, mas a direção converge. A Normativa 31 da ABECS empurrou a autenticação para cenários de cartão em arquivo e recorrência, justamente onde o dado do cartão fica guardado e o risco de uso indevido cresce. A conclusão prática é a mesma dos dois lados do Atlântico: 3DS deixou de ser enfeite e virou infraestrutura de quem processa cartão a sério.

Por que 3DS não é uma peça só

Quem já tentou plugar 3DS descobre rápido que não existe um 3DS único. Cada adquirência implementa a autenticação do seu jeito, e os jeitos são estruturalmente diferentes. Tem o modelo criptograma, em que um servidor de autenticação devolve um bloco cifrado (o CAVV, o ECI, o identificador da transação, a versão do protocolo) que a autorização precisa carregar. E tem o modelo token, em que a autenticação vive dentro da própria adquirência e devolve um identificador de sessão mais um código de status, sem criptograma nenhum.

Misturar isso no meio do fluxo de cobrança é como acabar a margem: um adaptador que trata Cielo e Pagar.me como se falassem a mesma língua quebra na primeira exceção. É exatamente o tipo de acoplamento que a Bunne desenha para fora do caminho do dinheiro.

Como a Bunne modela 3DS por driver

Na Bunne, 3DS entra pela mesma disciplina das adquirências e dos payouts: uma interface de provider com registry, o fluxo de cobrança fala só com a interface, e cada adquirência plugável tem o seu provider por trás. O modelo criptograma da Cielo e do Braspag preenche CAVV, ECI e versão que a autorização consome; o modelo token da Pagar.me (sobre o TDS da Stone) devolve o identificador de sessão e o status da transação. O core financeiro não sabe, nem precisa saber, qual dos dois rodou.

A saída da autenticação nunca vira um sim vago. Ela chega como um status com significado de responsabilidade: autenticado com o risco no emissor, tentativa com o shift a favor do lojista, desafio concluído, ou falha em que a proteção não existe e o certo é não autorizar. Isso é o liability shift virando dado auditável dentro do ledger, e não uma promessa perdida em log.

Trocar de adquirência não deveria significar reescrever o 3DS. Como o provider é um driver, o mesmo checkout e o mesmo core seguem valendo quando o roteamento manda a cobrança por outro caminho. A autenticação acompanha a adquirência escolhida, sem obra no meio.

O desafio dentro do seu checkout

Do lado do navegador, a diferença entre os modelos não pode sobrar para quem integra. Por isso o SDK do 3DS é um arquivo único, hospedado e sem segredo dentro, que a Bunne serve pronto. O lojista chama uma função, ela olha a resposta da cobrança e resolve tudo: se a compra passou frictionless, devolve a cobrança sem tela nenhuma; se o emissor pediu challenge, ela roda o desafio pelo adaptador da adquirência daquela transação e confirma o resultado de volta na API. O checkout nunca precisa ramificar por adquirência.

O desafio aparece integrado à compra, não numa página estranha que assusta o cliente. E como o SDK carrega só configuração pública, cada whitelabel pode servir esse mesmo arquivo debaixo da própria marca, coerente com a régua de que o cliente final vê a marca do operador, nunca a infraestrutura por baixo.

Quem decide quando exigir 3DS

Exigir autenticação em toda compra derruba conversão à toa; nunca exigir deixa a fraude passar. O ponto de equilíbrio não é global, é por operação. Na Bunne, 3DS é uma regra: vale só para cartão, dispara sempre ou a partir de um valor, e o seller pode ter a própria regra sobrepondo o padrão do whitelabel. Quem opera calibra onde quer trocar um pouco de atrito por muito menos risco, sem tocar em código.

E quando a fraude passa mesmo assim, com split no meio, a conta não cai inteira num lugar só. A responsabilidade do chargeback é roteada: cada recebedor marcado como responsável devolve a sua fatia, proporcional ao valor disputado, e o dono da cobrança absorve o resto. É o mesmo princípio do 3DS levado até o fim do ciclo: risco não some, risco tem dono, e o dono precisa estar escrito.

Onde isso te leva

3DS2 não é um botão de segurança que você liga e esquece. É um trade-off que alguém vai calibrar de qualquer jeito: a pergunta é se você calibra com intenção ou no escuro. Autenticação baseada em risco para não espantar a compra boa, desafio para a duvidosa, liability shift para tirar do seu colo a fraude que restar, e uma régua por seller para ajustar a mão.

Se hoje o seu 3DS é uma caixa-preta amarrada a uma adquirência só, o próximo passo não é trocar de provedor. É tratar a autenticação como um driver de um core que é seu. A página de segurança mostra como a Bunne encara isso no conjunto, e a documentação mostra o fluxo de cobrança de ponta a ponta, do token do cartão à confirmação do desafio.