Sua Stack de Pagamentos está Pronta para PSD2? O Que Ainda Surpreende Equipes em 2026

A maioria das equipes de pagamento acredita ter resolvido a conformidade PSD2 SCA ao ativar o 3DS2. Não resolveu. O que fizeram foi deslocar a complexidade uma camada mais fundo: para a lógica de isenções, o sequenciamento de MIT e o comportamento de autenticação do lado do emissor, que nenhum dashboard de PSP expõe com clareza. Vemos as consequências toda semana: quedas de taxa de aprovação sem explicação, perdas de conversão atribuídas a "comportamento do emissor" e achados de auditoria SCA que só aparecem quando um novo mercado é adicionado.

Principais Conclusões

• Ativar o 3DS2 atende ao requisito técnico de SCA, mas a lógica de isenções mal configurada é onde os merchants realmente perdem pontos de taxa de aprovação.
• Transações iniciadas pelo merchant estão fora do escopo de SCA, mas a autenticação inicial do mandato deve passar por SCA; caso contrário, os emissores recusarão cobranças subsequentes.
• As isenções de TRA (Análise de Risco da Transação) ficam no nível do adquirente e dependem de manter taxas de fraude abaixo dos limites da EBA. Suas decisões de roteamento afetam diretamente as isenções que você pode reivindicar.
• O PSD3 e o Regulamento de Serviços de Pagamento deslocam mais responsabilidade por fraude para os PSPs e introduzem obrigações mais rígidas de Verificação do Beneficiário. Merchants que usam serviços de iniciação de pagamento devem iniciar suas avaliações de lacunas agora.
• O roteamento multi-PSP é uma alavanca subutilizada para otimização de SCA: diferentes adquirentes têm diferentes limites de TRA, o que significa que a mesma transação roteada por outro provedor pode liberar um fluxo sem atrito.

O Que a Conformidade PSD2 SCA Realmente Exige em 2026

A Autenticação Forte do Cliente (SCA) do PSD2 exige que pagamentos eletrônicos remotos com cartão na UE e no Reino Unido usem pelo menos dois fatores de autenticação independentes: algo que o cliente sabe, tem ou é. O EMV 3DS2 é o principal mecanismo técnico para transações sem presença do cartão, e quando o ACS de um emissor apresenta um desafio multifator, a transação atende ao padrão SCA.

Essa é a linha de base. A complexidade operacional está em tudo que é construído sobre ela: quais transações estão no escopo, quais se qualificam para isenções e o que acontece quando um emissor discorda da sua solicitação de isenção.

O SCA se aplica a transações sem presença do cartão em que tanto o pagador quanto o provedor de serviços de pagamento estão sediados no Espaço Econômico Europeu ou no Reino Unido. Transações com apenas uma parte no escopo, onde somente um dos lados está sujeito às regras, ficam em uma zona cinzenta que os emissores tratam de forma inconsistente. Vemos isso regularmente com merchants que têm entidades domiciliadas na UE, mas atendem clientes em mercados com geografia mista de emissores.

Os Quatro Erros de SCA que Continuam Aparecendo em Produção

As falhas de SCA mais comuns em produção não são falhas técnicas; são falhas de configuração na lógica de isenções, no sequenciamento de MIT e no roteamento de fallback. Cada uma é evitável com a infraestrutura certa, mas cada uma também exige visibilidade de toda a sua stack de PSP, não apenas do dashboard de um único adquirente.

Tratar Isenções de SCA como Regras Definitivas

As isenções de SCA não são estáticas. As isenções de análise de risco da transação (TRA) exigem que seu adquirente mantenha taxas de fraude abaixo dos limites definidos pela Autoridade Bancária Europeia. Se sua taxa de fraude ultrapassar o limite em um determinado período, as isenções de TRA ficam indisponíveis para esse adquirente, e cada transação que dependia delas passará a acionar um desafio ou uma recusa suave.

Com base nas nossas integrações em verticais de e-commerce e marketplace, vemos merchants descobrirem isso apenas quando a conversão cai inesperadamente após um pico de fraude. Quando a queda é percebida, a janela de isenção já foi perdida por dias. A elegibilidade para isenções precisa de monitoramento ativo, não de uma revisão trimestral.

Vale manter em um só lugar as principais isenções disponíveis sob o PSD2 e seus escopos:

• Transações de baixo valor abaixo de €30, sujeitas a limites cumulativos de cinco transações ou €100 antes que o SCA seja exigido.
• Listas de beneficiários confiáveis, em que o cliente adicionou explicitamente um merchant à lista de permissões junto ao emissor.
• Pagamentos corporativos que usam processos e protocolos de pagamento dedicados confirmados como de baixo risco.
• Isenções de TRA em limites de valor de transação baixo, médio e alto, cada um exigindo taxas de fraude abaixo de 0,13%, 0,06% e 0,01%, respectivamente.
• Transações recorrentes após o primeiro mandato autenticado por SCA.

Configuração Incorreta de Transações Iniciadas pelo Merchant

Transações iniciadas pelo merchant estão fora do escopo do SCA. Assinaturas, cobranças diferidas e coletas de parcelas após o primeiro pagamento se qualificam como MITs, e aplicar 3DS a elas gera atrito desnecessário e às vezes quebra o fluxo completamente. O erro que vemos com mais frequência ocorre na direção oposta: merchants pulam a autenticação SCA na configuração inicial do mandato e depois ficam sem entender por que os emissores recusam cobranças MIT subsequentes.

O pagamento de estabelecimento do mandato deve passar por SCA. Essa primeira transação ancora todas as cobranças futuras da série. Se for ignorada, recusada suavemente ou roteada por um PSP que não a identifica corretamente como um acordo recorrente, a cadeia de MIT quebra no nível do emissor. Isso é especialmente comum quando merchants migram para um novo adquirente no meio do ciclo de vida da assinatura e não re-autenticam os mandatos existentes.

Aplicar 3DS de Forma Uniforme em Todas as Transações

Aplicar 3DS a todas as transações não é gestão de risco conservadora. É um imposto de conversão sobre seus melhores clientes. Compradores recorrentes e confiáveis em categorias de baixo risco não precisam de um desafio. Adicioná-lo reduz as taxas de conclusão e sinaliza ao emissor que você não tem inteligência de risco no nível da transação.

Com base na nossa infraestrutura, a abordagem correta coloca Risk Conditions em camadas sobre a lógica de 3DS. Transações de dispositivos conhecidos, padrões de baixa velocidade e perfis de clientes confiáveis devem fluir sem um desafio de 3DS. Sinais suspeitos, novos dispositivos, valores discrepantes e incompatibilidades geográficas devem acioná-lo. O produto 3DS do Yuno suporta lógica de condição personalizada que roteia transações por caminhos de desafio ou sem atrito com base em sinais reais, não em regras genéricas.

Ignorar o Tratamento de Recusas Suaves do Emissor

Quando um emissor recusa uma solicitação de isenção, ele retorna uma recusa suave com um sinalizador de autenticação exigida. Merchants que não estão configurados para lidar com essa resposta perdem a transação completamente. A resposta correta é reapresentar a transação pelo desafio 3DS. Sem lógica de fallback automatizado, essa recuperação nunca acontece.

Este é um problema particularmente sério em ambientes multi-PSP, onde cada provedor trata recusas suaves de forma diferente. Já vimos casos em que um adquirente tenta novamente automaticamente, outro abandona a transação e um terceiro gera um erro que fica sem tratamento por horas. A orquestração centralizada fecha essa lacuna ao aplicar lógica de fallback consistente em todos os adquirentes da stack.

Como o Roteamento Multi-PSP Afeta os Resultados de SCA

As decisões de roteamento e os resultados de SCA estão diretamente conectados porque a elegibilidade para isenções de TRA é específica do adquirente, não do merchant. Um adquirente com uma taxa de fraude consistentemente baixa tem acesso a isenções de TRA de maior valor que outro adquirente na sua stack pode não ter.

Isso significa que a mesma transação roteada por diferentes adquirentes pode ter resultados de autenticação materialmente diferentes. Um caminho aciona um fluxo sem atrito. Outro aciona um desafio. Um terceiro faz uma recusa suave e exige uma nova tentativa. Os dados da plataforma Yuno mostram que o roteamento com consciência de isenções, direcionando transações para o adquirente mais bem posicionado para reivindicar uma determinada isenção, melhora as taxas de fluxo sem atrito nos mercados da UE sem qualquer alteração na UX de checkout do merchant.

Essa é uma percepção que só aparece quando você tem visibilidade multi-PSP em um único lugar. Um único adquirente não consegue comparar sua própria elegibilidade para isenções com a de um concorrente. O Yuno consegue, porque vemos o quadro completo de todos os provedores na sua stack. O Payment Concierge expõe essas diferenças no nível do adquirente em tempo real, para que as equipes de operações de pagamento possam agir sobre elas em vez de descobri-las em uma análise pós-incidente.

O Que PSD3 e o PSR Mudam para Merchants que Já Operam com Stacks Conformes ao PSD2

O PSD3 não é uma versão renomeada do PSD2; é uma expansão estrutural que redistribui a responsabilidade por fraude, amplia o escopo de SCA em cenários específicos e introduz novas obrigações para usuários de serviços de iniciação de pagamento. Merchants que tratam o PSD3 como uma atualização incremental serão surpreendidos quando os prazos de transição se apertarem.

As mudanças operacionalmente mais significativas incluem:

• Maior transferência de responsabilidade por fraude para os PSPs, com prestação de contas mais explícita quando golpes de push payment autorizado ocorrem por canais de iniciação de pagamento.
• A Verificação do Beneficiário passa a ser obrigatória para fluxos conta a conta, com os estados-membros da zona do euro já obrigados a suportá-la desde outubro de 2025.
• Requisitos mais rígidos em torno de cenários de engenharia social, em que merchants e PSPs devem demonstrar diligência devida quando clientes são manipulados a autorizar pagamentos fraudulentos.
• Regras de SCA mais claras para métodos de pagamento que não são cartão, fechando as lacunas que o PSD2 deixou em aberto para carteiras digitais e pagamentos baseados em conta.
• Direitos ampliados para que PSPs compartilhem inteligência sobre fraudes entre instituições, o que muda a dinâmica da seleção de ferramentas de prevenção a fraudes.

Para merchants que atualmente usam serviços de iniciação de pagamento junto com trilhos de cartão, o framework de responsabilidade é o item mais urgente a revisar. As disposições de responsabilidade por fraude do PSD3 criam exposição que não existia sob o PSD2 para certos tipos de transação.

Como o Yuno Gerencia a Infraestrutura de Conformidade SCA

O produto 3DS do Yuno dá aos merchants controle total sobre quando e como a autenticação é aplicada, sem exigir engenharia personalizada para cada mercado ou adquirente. A lógica de condição personalizada roteia transações com base em pontuação de risco, geografia, status do cliente e padrões de velocidade.

Clientes confiáveis ignoram o atrito. Sinais suspeitos acionam verificações em camadas. E o fallback de recusa suave é tratado automaticamente em todos os adquirentes da stack, para que uma solicitação de isenção rejeitada não se torne uma transação perdida. A camada Risk Conditions do Yuno fica à montante do 3DS, filtrando transações conhecidamente legítimas antes que cheguem à etapa de autenticação e bloqueando agentes mal-intencionados conhecidos antes que consumam recursos do PSP.

O resultado é uma abordagem em camadas que faz o que o 3DS genérico não consegue: proteger a conversão de clientes legítimos enquanto mantém as taxas de fraude que mantêm as isenções de TRA disponíveis. Os dados da plataforma Yuno mostram uma redução de 29% em fraudes para merchants que usam Risk Conditions em combinação com roteamento inteligente de 3DS.

Para a transição para o PSD3, a infraestrutura do Yuno já está dimensionada para lidar com as obrigações de Verificação do Beneficiário e as condições de SCA ampliadas que o regulamento introduz. Merchants no Yuno não precisam rearquitetar sua stack de autenticação quando o PSD3 entrar em vigor. A camada de configuração absorve a mudança.

A Auditoria Prática que Todo Líder de Pagamentos Deve Realizar Agora

Antes que os prazos do PSD3 se comprimam ainda mais, vale completar três auditorias na sua stack atual.

• Mapeie cada tipo de transação em relação à taxonomia de isenções e exclusões de SCA. Confirme que os mandatos MIT estão corretamente autenticados na configuração. Identifique qualquer fluxo de transação em que os sinalizadores de isenção estejam ausentes ou aplicados incorretamente.
• Verifique as taxas de fraude no nível do adquirente em relação aos limites de TRA atuais da EBA. Se algum adquirente na sua stack estiver se aproximando de um teto de limite, construa a lógica de roteamento para deslocar volume antes que a elegibilidade para isenções seja perdida.
• Teste suas rotas de fallback de recusa suave. Acione uma recusa suave deliberada no ambiente de homologação e confirme que a nova tentativa automatizada pelo desafio 3DS funciona corretamente em todos os adquirentes. Se não funcionar, você está perdendo transações em produção agora mesmo.

Essas três verificações levam menos de uma semana com as ferramentas certas. Sem visibilidade centralizada da sua stack de PSP, cada uma exige extrair dados de dashboards separados, reconciliar formatos e tomar decisões com informações incompletas. É aí que a maioria das equipes perde tempo, e onde a maioria das lacunas de SCA permanece oculta por mais tempo.