A padronização do 3DS é uma tarefa pendente para operadores multi-PSP enterprise

Um líder de pagamentos enterprise perguntou recentemente a um fornecedor algo que revela todo o problema: "Vocês suportam 3DS standalone, ou ele tem que rodar dentro do PSP?". Essa pergunta só é feita por alguém que já descobriu que seus três PSPs estão executando três políticas de autenticação distintas, e que a variabilidade já aparece nos dados de autorização. The Paypers publicou um explainer sobre autenticação EMV 3DS em 29 de abril de 2026, percorrendo o protocolo em um nível apropriado para quem o estuda pela primeira vez. Na mesma semana, em conversas privadas, líderes de pagamentos em merchants multi-PSP faziam uma pergunta mais avançada. Tinham lido a spec anos atrás. O que queriam saber era o que fazer com o fato de que cada um de seus PSPs estava implementando a spec de forma diferente.

EMV 3DS é um protocolo padronizado. A política de autenticação que roda em cima dele não é, porque a política vive no PSP, e cada PSP tem a sua. Há dois anos isso era um incômodo operacional. Agora vira uma deadline arquitetônica, porque duas pressões convergentes se encontram no mesmo lugar: relógios regulatórios que redesenham quem é responsável por Strong Customer Authentication, e variabilidade operacional que piora com cada PSP adicionado. Ambas se resolvem na mesma pergunta — onde vive o 3DS Server — e a maioria dos enterprises a respondeu por default há três anos sem pensar.

O protocolo está padronizado. A política não.

EMV 3DS 2.x define o formato da mensagem: como o 3DS Server do merchant conversa com o Directory Server do scheme, como o Directory Server roteia ao Access Control Server do emissor, quais dados circulam, e como o resultado volta, o valor ECI e o Cardholder Authentication Verification Value. Essa parte está padronizada. Toda implementação certificada lida com o mesmo protocolo.

O que não está padronizado é a camada de tomada de decisões que se apoia em cima: quando solicitar uma isenção de Transaction Risk Analysis, quando marcar um pagamento como low-value, quando usar o indicador de merchant-initiated transaction, como popular os campos opcionais de risco, o que fazer com um soft decline. Essas decisões se configuram por PSP. O merchant que se conecta a três PSPs herda três configurações, três estratégias de isenção por default, e três handlers de soft decline. O protocolo por trás é idêntico. A política não.

Por que o relógio regulatório importa agora

O framing de "tarefa pendente" tem um calendário anexado. Três deadlines chegam na mesma janela, e cada uma eleva o custo de deixar a política de 3DS dentro do PSP.

O Digital Authentication Framework da Visa termina em setembro de 2026, e a partir daí toda implementação do Visa Secure roda sobre a versão mais alta do protocolo EMV 3DS que o emissor suporte, negociada por transação através do fluxo PReq/PRes. Um merchant cujos três PSPs negociam essa versão independentemente com cada emissor produz resultados inconsistentes por design.

A PSR, a metade diretamente aplicável do pacote PSD3, foi acordada politicamente em novembro de 2025 e deve entrar em vigor em 2027 após uma transição de 21 meses. Sua cláusula de delegated authentication permite ao emissor terceirizar SCA a um provedor técnico sob acordo escrito, com a parte que autentica carregando a responsabilidade por fraude. Sob a PSD2, SCA era implicitamente trabalho do emissor, executado via 3DS. Sob a PSR, o merchant ou seu orchestrator podem ser a parte que autentica — mas só se o merchant for dono do 3DS Server. Um merchant cujo 3DS vive dentro de três PSPs não tem caminho para aceitar delegated authentication; só pode consumir o que seus PSPs produzem.

O target de migração para AES da Visa, sinalizado para 2030, significa que as primitivas criptográficas embaixo do 3DS mudam ao mesmo tempo em que o perímetro regulatório é redesenhado. A variabilidade existe há anos. O relógio regulatório muda o que ela custa: passa de operacionalmente inconveniente a estruturalmente cara, em um horizonte de 12 a 18 meses.

Lógica de isenções: onde a variabilidade operacional começa

Os Regulatory Technical Standards da PSD2 permitem várias isenções de SCA: Transaction Risk Analysis para transações de baixo risco sob um value band, Low-Value Payments abaixo de trinta euros (com limite acumulado de cem euros ou cinco transações consecutivas), Merchant-Initiated Transactions após setup autenticado, whitelisting de beneficiários confiáveis, e Secure Corporate Payments. A Visa Europe estima que entre 40 e 50 por cento das transações de e-commerce por volume poderiam qualificar para isenção de SCA se os critérios forem atendidos.

A fonte estrutural da variabilidade multi-PSP é a mecânica de isenção TRA. Sob o RTS da European Banking Authority, a taxa de fraude que determina elegibilidade para TRA é calculada no nível do PSP em base trimestral móvel. Três PSPs servindo o mesmo merchant têm taxas de fraude, value bands e elegibilidade de isenção distintos. O adquirente a 0,11 por cento de taxa de fraude qualifica para a isenção até um threshold mais alto; o adquirente a 0,14 por cento não qualifica para nada acima do band mais baixo. Somando as decisões de implementação de cada PSP — pedir o flag TRA agressivamente, pedi-lo só acima de um score de risco configurado, ou não pedi-lo nunca porque o merchant não configurou a integração — o merchant que não faz nada diferente entre os três PSPs obtém três resultados de SCA distintos em transações idênticas. O impacto na taxa de aprovação é invisível no dashboard de qualquer PSP individual, porque cada um só vê o que ele mesmo roteou.

Normalizar a lógica de isenções entre PSPs significa tomar a decisão de isenção em um único lugar, antes do routing, contra a política de risco do próprio merchant e não contra os defaults de cada PSP. A decisão depois é comunicada ao PSP que processar a autorização.

Comportamento do challenge rate: a parte invisível do spread

A taxa frictionless é o percentual de transações 3DS que se completam sem challenge ao cardholder. Depende de três inputs que o merchant não controla diretamente: o modelo de risco do emissor em seu Access Control Server, a qualidade dos dados que chegaram ao emissor, e a sinalização de isenção do PSP.

O segundo input é onde o merchant multi-PSP paga mais. EMV 3DS 2.x suporta mais de 170 elementos de dados que o 3DS Server do merchant pode popular para autenticação baseada em risco. Emissores usam essa informação para decidir se emitem challenge. Os PSPs variam em quanto populam a partir do checkout: qualidade do device fingerprint, dados do browser, histórico de transações prévias, indicadores de risco do merchant, verificação de endereço, idade da conta, sinais de comportamento. Um PSP que popula 40 campos vai produzir um challenge rate diferente de um que popula 110, no mesmo cartão, na mesma sessão, com o mesmo emissor.

The Paypers publicou uma entrevista separada em 21 de abril de 2026 sobre a psicologia do atrito no checkout, apontando que os challenge rates afetam a conversão de maneiras que variam por mercado e dispositivo. A implicação para operadores multi-PSP é que a medição de conversão no nível agregado oculta a variabilidade emissor-por-PSP que está gerando o spread. Fazer benchmarking exige dados no nível BIN unidos a dados de routing por PSP. Sem isso, a camada analítica não pode ver qual PSP está empurrando para cima o challenge rate do emissor.

Mecânicas operacionais para normalizar o challenge rate: capturar os elementos de dados 3DS 2.x disponíveis na camada de orchestration, antes de invocar o 3DS Server do PSP, para setar a qualidade uma única vez e não por integração; trackear o challenge rate por BIN do emissor por PSP, não só por PSP ou por mercado, para tornar visível a variabilidade que o dashboard por PSP não mostra; e tratar o challenge rate como um input ajustável do routing, não como uma caixa preta por PSP.

Manejo de fallback: o custo que se acumula com cada PSP adicionado

Um soft decline é uma resposta do emissor indicando que a transação seria aprovada se SCA fosse executada. EMV 3DS 2.x e PSD2 esperam que o merchant tente novamente com challenge SCA completo. O código de soft decline da Visa para isso é 20154, com códigos paralelos da Mastercard. Manejá-los corretamente é a diferença entre recuperar a transação e perdê-la.

Em uma arquitetura multi-PSP onde o 3DS vive dentro de cada PSP, o manejo de soft decline tem um modo de falha oculto. Quando uma transação é roteada ao PSP A, recebe soft decline por SCA, e é cascateada ao PSP B para tentar novamente, a autenticação 3DS do PSP A não pode ser reutilizada no PSP B. O cardholder, que acabou de completar um challenge SCA momentos antes, tem que completar outro. Em mercados PSD2, o operador pede ao cliente para se autenticar duas vezes na mesma tentativa de pagamento. A taxa de drop-off no segundo challenge é substancialmente pior que no primeiro.

A causa estrutural é a mesma do problema de lógica de isenções. O resultado da autenticação 3DS está amarrado ao PSP que o produziu. Não existe um artefato de autenticação portável que sobreviva a uma decisão de routing. A orientação da indústria para resolver é consistente: o merchant é dono do 3DS Server, se torna PCI-L1 compliant onde for necessário, e roda a autenticação uma única vez antes de selecionar o PSP. O resultado da autenticação, ECI e CAVV incluídos, depois é passado ao PSP que for autorizar a transação.

Essa é a arquitetura sobre a qual o practitioner perguntando por "3DS standalone" sabia que existia. Não é um gap de produto. É uma pergunta de padrão de deployment. Se o 3DS Server do merchant é independente da camada de routing do PSP é a pergunta que determina se o cascading de soft decline funciona sem re-autenticar o cliente, se o merchant pode aceitar delegated authentication sob a PSR, e se a migração para AES em 2028 é um projeto único ou três.

Um cenário que deveria parecer familiar

Um marketplace de alto volume operando nos EUA e Europa integra três PSPs há dezoito meses para expandir cobertura de acquiring. Cada PSP maneja 3DS do seu jeito e cumpre seu SLA individual. No mês nove, o time constrói um dashboard no nível BIN unindo autenticação a routing por PSP, e descobre um spread de seis a oito pontos em taxa frictionless entre os três PSPs sobre BINs sobrepostos. O PSP com o frictionless rate mais baixo é também o mais barato em fees de acquiring, então as regras de routing mandam o maior volume para ele. O arrasto de conversão, anualizado, excede a economia de acquiring por uma ordem de magnitude.

O fix não é uma mudança de regra de routing. O fix é tirar o 3DS Server dos três PSPs e levá-lo à camada de orchestration, para que o mesmo flagging de isenções, a mesma população de dados e o mesmo manejo de fallback se apliquem independente de qual PSP autoriza. O time que faz isso em 2026 tem dados limpos no nível BIN entrando na janela de enforcement da PSR. O time que adia reconstrói a mesma arquitetura sob pressão de deadline em 2027.

O custo assumido

Ser dono do 3DS Server na camada de orchestration não é o caminho de menor esforço. Exige certificação direta contra EMV 3DS, manutenção ongoing à medida que o protocolo avança, e responsabilidade operacional por um componente que costumava estar dentro do PSP. O primeiro trimestre rodando produz menos time-to-launch do que delegá-lo a um PSP. Os números mudaram porque a variabilidade por PSP se acumula a cada mês em que a arquitetura está errada, e a janela regulatória para converter essa variabilidade de custo em capacidade fecha entre fim de 2026 e 2027.

O custo de rodar 3DS fragmentado é pago todo mês em autorizações perdidas e conversões perdidas. O custo de unificá-lo é pago uma única vez.

O que operadores multi-PSP devem avaliar antes de adicionar o próximo PSP

O diagnóstico é curto. Onde vive o 3DS Server por cada PSP integrado? Se a resposta é "dentro do PSP", a lógica de isenções, o comportamento do challenge rate e o manejo do soft decline estão configurados por PSP em vez de por merchant. Que flags de isenção são pedidos em quais transações, e pela política default de qual PSP? Se o merchant não consegue responder sem abrir a UI de configuração de cada PSP, a política está fragmentada. O que acontece quando um soft decline no PSP A é cascateado ao PSP B? Se o cliente enfrenta um segundo challenge SCA, o manejo de fallback é o próximo a se mover para a camada de orchestration. Quem carrega a responsabilidade por SCA quando a PSR entrar em vigor? Se a resposta é "o PSP", o merchant não tem caminho para otimizar a economia de conversão na camada de autenticação.

EMV 3DS padronizou o formato da mensagem. A padronização que importa para o operador multi-PSP — a parte em que isenções, challenges e fallbacks se comportam igual independente de qual PSP autorizou — ficou como tarefa a cargo do merchant. Há três anos era fácil de adiar porque a variabilidade era pequena e a responsabilidade regulatória vivia com o emissor. Os próximos doze meses definem se a termina o operador que decide assumi-la, ou se a adia o que segue assumindo que seus PSPs estão fazendo isso por ele. Quem for dono do 3DS Server é dono da política. Essa é a parte que segue pendente.