3D Secure 2 e SCA na PSD2: isenções, transferência de responsabilidade e conversão

O que é o 3D Secure 2 e como se relaciona com a SCA?

A autenticação forte do cliente é uma obrigação legal: nos termos da PSD2, um pagamento iniciado online pelo ordenante tem de ser confirmado com dois fatores independentes, e o código de autenticação tem de estar dinamicamente associado ao montante e ao beneficiário. O 3D Secure 2 é a norma técnica, mantida pela EMVCo, que as redes de cartões usam para a cumprir. Os compradores veem-na sob marcas como Visa Secure, Mastercard Identity Check, American Express SafeKey e Cartes Bancaires FAST'R.

A primeira versão do 3D Secure enviava todos os compradores para uma página de palavra-passe do banco. A versão 2 troca mais de 100 elementos de dados sobre o dispositivo, a encomenda e a conta, para que o emissor possa aprovar a maioria dos pagamentos sem mostrar nada e reservar um desafio, normalmente uma confirmação na aplicação do banco, para os arriscados. Suporta também fluxos nativos em aplicações, o que o protocolo antigo não fazia.

Quando é exigida a SCA e que pagamentos estão fora do âmbito?

A SCA aplica-se a pagamentos eletrónicos iniciados pelo ordenante quando o emissor e o adquirente estão ambos no EEE; o Reino Unido aplica as mesmas regras através da sua própria versão das normas técnicas. Para uma loja online da UE, isto abrange quase todos os primeiros pagamentos com cartão, todos os checkouts pontuais e qualquer alteração a um mandato de cartão guardado.

Vários tipos de transação ficam totalmente fora da obrigação, o que é diferente de uma isenção: não é legalmente exigida autenticação, mas o emissor pode recusar na mesma. Assinale-os corretamente na mensagem de autorização, porque um indicador errado é uma causa frequente da recusa suave "SCA required".

• Transações iniciadas pelo comerciante (MIT): subscrições de valor variável, cobranças diferidas e não comparências, desde que o mandato tenha sido criado com SCA
• Pagamentos por correspondência e por telefone (MOTO), em que os dados do cartão não são introduzidos online pelo comprador
• Pagamentos one-leg-out, em que o emissor ou o adquirente está fora do EEE; a SCA aplica-se com o melhor esforço
• Pagamentos iniciados pelo beneficiário a partir de um mandato de débito direto, como o débito direto SEPA

Que isenções de SCA podem os comerciantes usar?

As isenções são opcionais: o adquirente ou o emissor pode aplicá-las, e o emissor tem sempre a palavra final. Se recusar uma isenção, devolve uma recusa suave (código de resposta 1A na Visa, 65 na Mastercard) e o pagamento tem de ser repetido com autenticação. O quadro resume as isenções do Regulamento Delegado (UE) 2018/389 que importam para as vendas online.

A análise de risco da transação é a mais valiosa para comerciantes com pouca fraude, porque cobre cestos até 500 €. A taxa que conta é a taxa de fraude do PSP que aplica a isenção, calculada sobre 90 dias, pelo que um adquirente com uma carteira limpa pode pedi-la em seu nome.

Como funcionam o fluxo sem fricção e o fluxo com desafio?

O servidor 3DS do comerciante, geralmente gerido pelo PSP, envia um pedido de autenticação através do servidor de diretório da rede de cartões para o servidor de controlo de acesso do emissor. O emissor avalia o pedido com os dados do dispositivo, da encomenda e da conta e responde em cerca de um segundo.

Se o risco for baixo, o pagamento é autenticado sem fricção e o comprador não vê nada. Caso contrário, o emissor abre um desafio: uma confirmação push na aplicação do banco, uma verificação biométrica ou um código de utilização única. Em ambos os casos, o resultado e um criptograma são passados à autorização, para que o emissor possa ver que a SCA foi realizada.

1. Recolher dados O checkout reúne dados do navegador ou da aplicação, dados de faturação e de entrega e o histórico da conta do comprador.
2. Autenticar O servidor 3DS envia o pedido; o emissor responde sem fricção, com desafio ou com rejeição.
3. Autorizar O resultado da autenticação e o criptograma seguem com o pedido de autorização para o emissor.

O que é a transferência de responsabilidade do 3D Secure?

Quando um pagamento é autenticado com sucesso através do 3D Secure, a responsabilidade por estornos de fraude, como o código de motivo 10.4 da Visa ou 4837 da Mastercard, passa do comerciante para o emissor. Na maioria dos casos, isto também se aplica quando o comerciante tentou a autenticação mas o emissor não estava disponível.

A transferência não cobre litígios que não sejam de fraude, como mercadoria não recebida ou não conforme, e perde-se quando se aplica uma isenção do lado do adquirente: ganha-se conversão mas mantém-se o risco de fraude. É por isso que os comerciantes aplicam a TRA de forma seletiva, por exemplo a clientes recorrentes e a cestos de baixo risco, e enviam o resto para autenticação.

Como afeta o 3D Secure 2 a conversão do checkout?

Cada desafio acrescenta um passo em que o comprador pode desistir ou falhar, sobretudo quando a aplicação do banco está noutro dispositivo. A EBA e o BCE comunicaram em dezembro de 2025 que os pagamentos com cartão autenticados por SCA continuam menos expostos à fraude, pelo que o objetivo não é evitar a SCA mas desafiar apenas onde compensa.

A conversão melhora com dados completos no pedido de autenticação, indicadores de transação corretos, um SDK nativo de aplicação em vez de uma vista web, pedidos de isenção através de um adquirente com baixa taxa de fraude e uma nova tentativa imediata com autenticação após uma recusa suave. Meça separadamente a taxa sem fricção, a taxa de sucesso dos desafios e a taxa de autorização por país do emissor; um valor de aprovação agregado esconde onde os compradores desistem.

Como adicionar o 3D Secure 2 através da OrsunPay?

A OrsunPay é um serviço técnico sobre as contas de PSP e de adquirente do próprio comerciante. Com o seu checkout alojado, os dados do cartão e o fluxo 3D Secure decorrem na interface do próprio PSP, pelo que a autenticação, os pedidos de isenção e as regras de responsabilidade são os do seu contrato com esse PSP. O encaminhamento baseado no risco e uma integração com a RiskCogs estão no plano de desenvolvimento e não estão disponíveis hoje.