Gateway de Pagamento 3D Secure: Como o 3DS2 Protege os Comerciantes da Fraude
O 3D Secure é um protocolo de autenticação desenvolvido pelos circuitos de cartões que acrescenta uma camada de verificação de identidade às transações online com cartão. Quando um cliente paga através de um gateway com 3D Secure ativo, o seu banco emissor verifica a transação antes de ser autorizada, seja através de uma verificação em segundo plano sem fricção ou solicitando ao cliente autenticação pela sua aplicação bancária. Para os comerciantes, o 3D Secure proporciona dois benefícios críticos: reduz significativamente as perdas por fraude em transações online e transfere a responsabilidade por contestações de fraude do comerciante para o banco emissor. Este guia explica como funciona o 3D Secure, em que difere a versão 2 da versão 1 e como implementar o 3DS2 através da RoxPay.
O Que É o 3D Secure e Como Funciona
O 3D Secure (3DS) é um protocolo de autenticação baseado em XML para transações sem cartão presente. Os três domínios no nome referem-se ao domínio do comerciante, ao domínio do adquirente e ao domínio de interoperabilidade (a rede do circuito de cartões e o banco emissor). Em conjunto, estes três intervenientes participam na verificação de que a pessoa que inicia a transação é o titular do cartão autorizado.
Fluxo da transação com 3DS:
O cliente insere os dados do cartão no checkout e submete o pagamento. O gateway do comerciante submete a transação com um pedido de autenticação 3DS. O circuito de cartões encaminha o pedido para o Servidor de Controlo de Acesso do emissor do cartão. O emissor realiza uma avaliação de risco da transação. Se a avaliação de risco indicar baixo risco (fluxo sem fricção), a transação é autenticada sem interação do cliente. Se o risco estiver acima do limiar sem fricção, o cliente é solicitado a autenticar-se, tipicamente aprovando uma notificação push na sua aplicação bancária, introduzindo uma senha de utilização única ou fornecendo confirmação biométrica. O resultado da autenticação (autenticada, tentada ou falhada) é devolvido ao gateway do comerciante, que o inclui no pedido de autorização ao adquirente.
A transferência de responsabilidade: Quando uma transação é autenticada com sucesso via 3DS, e o titular do cartão mais tarde a contesta como fraudulenta, a responsabilidade pela contestação transfere-se do comerciante para o banco emissor. O banco emissor aprovou a transação autenticada; não pode depois contestá-la com sucesso como não autorizada. Esta transferência de responsabilidade é o principal benefício comercial do 3DS para os comerciantes.
Para os comerciantes que operam um gateway de pagamento de alto risco, implementar o 3DS2 é particularmente importante porque as categorias de alto risco tendem a ter taxas elevadas de fraude e fraude amigável, tornando a proteção de responsabilidade comercialmente significativa.
3DS1 vs 3DS2: O Que Mudou e Por Que Importa
A especificação original do 3D Secure (3DS1) foi introduzida no início dos anos 2000. Embora fornecesse um mecanismo de transferência de responsabilidade, tinha sérios problemas de usabilidade e conversão que os comerciantes experimentavam como abandono do carrinho na etapa de autenticação. O 3DS2 (EMV 3DS) foi desenvolvido para resolver estes problemas.
Problemas do 3DS1:
O 3DS1 exigia um redirecionamento para a página de autenticação do emissor, que era muitas vezes mal concebida e confusa para os clientes. O modelo de senha estática utilizado por muitos emissores (Verified by Visa, MasterCard SecureCode) era fácil de esquecer e criava fricção em cada transação. Em dispositivos móveis, o fluxo baseado em redirecionamento e pop-up era particularmente problemático. Muitos comerciantes desativaram o 3DS1 especificamente porque a etapa de autenticação estava a causar mais abandono de transações do que as perdas por fraude que tentavam prevenir.
Melhorias do 3DS2:
O 3DS2 introduz um modelo rico de partilha de dados. O gateway do comerciante envia até 150 pontos de dados com o pedido de autenticação, incluindo impressão digital do dispositivo, características do browser, histórico de encomendas e sinais comportamentais. O emissor usa estes dados para tomar uma decisão de risco. Para transações de baixo risco, o emissor pode conceder uma autenticação sem fricção, o que significa que o cliente nunca é solicitado a fazer nada e a transação prossegue sem interrupção.
Métodos de autenticação no 3DS2: Quando a autenticação é necessária, o 3DS2 suporta métodos modernos: notificações push para uma aplicação bancária com confirmação biométrica, senhas de utilização única por SMS e autenticação in-app sem redirecionamento. Estes são significativamente menos perturbadores do que o redirecionamento por pop-up do 3DS1.
PSD2 e Autenticação Forte do Cliente: A Diretiva Revista de Serviços de Pagamento (PSD2) da UE impõe a Autenticação Forte do Cliente (SCA) para a maioria das transações europeias sem cartão presente. O 3DS2 é o mecanismo principal para a conformidade SCA. Os emissores são obrigados a aplicar SCA a transações que não se qualificam para uma isenção. Os comerciantes que não suportam 3DS2 descobrem que as transações são recusadas suavemente pelos emissores que requerem SCA mas não a conseguem concluir porque o gateway não passa dados de autenticação 3DS2.
Como o 3D Secure Reduz a Responsabilidade por Contestações para os Comerciantes
A transferência de responsabilidade fornecida pela autenticação 3D Secure é o mecanismo através do qual os comerciantes reduzem as perdas por contestações em disputas de fraude.
Como a transferência de responsabilidade funciona na prática: Um cliente conclui uma compra e autentica-se via 3DS2 (por exemplo, aprovando uma notificação push na sua aplicação bancária). A transação é processada e os bens são entregues. Um mês depois, o cliente contacta o seu banco emissor afirmando que a transação não foi autorizada. O banco inicia uma contestação sob um código de razão de fraude (Visa 10.4, Mastercard 4853).
Quando o gateway do comerciante submete a réplica, inclui o registo de autenticação 3DS2: o ID da Transação de Autenticação (ATID), o estado de autenticação (autenticada) e o valor ECI indicando autenticação completa. Este registo demonstra que o próprio banco emissor do titular do cartão autenticou a transação. A equipa de disputas do banco vê que o mesmo banco que agora processa a disputa foi o que autenticou a transação. Na prática, isto resulta na reversão da contestação na grande maioria dos casos.
Transações que não beneficiam da transferência de responsabilidade: Nem todos os resultados 3DS2 proporcionam transferência de responsabilidade. Uma transação que passa pelo processo de autenticação mas resulta num estado de autenticação "tentada" (o cartão não suporta autenticação completa) proporciona proteção limitada comparativamente a um resultado totalmente autenticado. A transferência de responsabilidade aplica-se mais fortemente a transações com um resultado de autenticação bem-sucedido e um valor ECI de 05 (Visa) ou 02 (Mastercard).
Isenções e responsabilidade: Certas isenções 3DS2 (transações de baixo valor abaixo de 30 euros, listas de beneficiários de confiança, transações recorrentes) permitem que as transações prossigam sem SCA. A posição de responsabilidade para transações baseadas em isenções varia consoante o tipo de isenção. As transações de isenção de baixo valor onde o emissor aplica a isenção retêm a responsabilidade no comerciante. As transações onde o comerciante solicita uma isenção que o emissor subsequentemente aprova podem resultar na responsabilidade permanecer no comerciante.
Quando o 3D Secure É Obrigatório vs Opcional
Ao abrigo do mandato de Autenticação Forte do Cliente da PSD2, o 3D Secure é obrigatório para a maioria das transações europeias sem cartão presente, mas uma série de isenções e cenários fora do âmbito definem quando a SCA não se aplica.
Quando o 3DS é obrigatório (SCA aplica-se):
Todos os pagamentos padrão sem cartão presente iniciados pelo cliente (transações iniciadas pelo cliente, ou CITs) por montantes acima do limiar de baixo valor estão sujeitos a SCA. A posição padrão é que a SCA é obrigatória; as isenções são as exceções.
Isenções que permitem transações sem 3DS:
Transações de baixo valor: As transações abaixo de 30 euros podem qualificar-se para uma isenção de baixo valor. No entanto, os emissores acompanham os montantes cumulativos e as contagens de transações; uma vez aplicadas cinco isenções consecutivas de baixo valor ou o montante cumulativo exceder 100 euros, a SCA é exigida para a transação seguinte.
Análise de risco de transação (TRA): Os emissores e adquirentes podem aplicar isenções TRA a transações que avaliem como de baixo risco com base em benchmarks de taxa de fraude. Para aplicar uma isenção TRA ao nível do adquirente, o adquirente deve cumprir limiares específicos de taxa de fraude definidos pela PSD2.
Transações recorrentes: O pagamento inicial numa série recorrente requer SCA. As transações iniciadas pelo comerciante (MITs) subsequentes no mesmo mandato recorrente podem prosseguir sem SCA, desde que a transação inicial tenha sido autenticada e as transações subsequentes sigam o quadro de credenciais armazenadas.
Beneficiário de confiança: Os titulares de cartões podem adicionar comerciantes a uma lista branca junto do seu emissor, aplicando uma isenção de beneficiário de confiança a transações futuras com esse comerciante.
Fora do âmbito de SCA: As transações iniciadas pelo comerciante sem interação do cliente (MIT), as transações em que uma das partes está fora do EEE (transações com uma perna fora) e as transações com cartão corporativo estão fora do âmbito da SCA da PSD2 em circunstâncias específicas.
Implementar o 3DS2 com a RoxPay
O gateway de pagamento da RoxPay suporta 3DS2 nativamente. A implementação é gerida dentro da arquitetura de integração existente, sem necessidade de um fornecedor 3DS separado ou contrato adicional.
Abordagem de IU drop-in: Se usar a IU drop-in da RoxPay (introdução de cartão baseada em JavaScript), o 3DS2 é gerido automaticamente. Quando o emissor requer autenticação, a biblioteca gere o redirecionamento para o ambiente de autenticação do emissor, trata a resposta e continua o fluxo de pagamento sem código adicional do lado do comerciante. Este é o caminho mais simples para a conformidade 3DS2.
Abordagem de integração API: Para os comerciantes que usam uma integração API direta, os dados de autenticação 3DS2 são passados através dos parâmetros de intenção de pagamento. A API devolve o resultado de autenticação e a ação necessária para o frontend do comerciante gerir, seguindo o fluxo de desafio 3DS2 padrão. A documentação completa está disponível em app.roxpay.eu/api/v4/docs.
Otimização da taxa sem fricção: A RoxPay passa o máximo de dados disponíveis no pedido de autenticação 3DS2 para suportar altas taxas sem fricção. A autenticação sem fricção significa que o cliente nunca é solicitado a confirmar nada; o emissor aprova a transação em segundo plano. Quanto maior a taxa sem fricção, melhor o impacto de conversão do 3DS2.
Teste no sandbox: O sandbox da RoxPay fornece cenários de teste para todos os resultados 3DS2: autenticação sem fricção, autenticação com desafio, falha de autenticação e cartão não inscrito. Teste todos os cenários antes de ir para produção para garantir que o seu checkout gere corretamente cada resultado.
Para iniciar a sua candidatura RoxPay e começar a testar o 3DS2 no sandbox, o registo demora menos de dez minutos e as credenciais de sandbox são emitidas imediatamente. A RoxPay é certificada PCI DSS Level 1 (QS83A47X629) e ISO 27001.
Perguntas frequentes
O 3D Secure reduz as taxas de conversão?
O 3DS2 com implementação adequada tem um impacto mínimo na conversão comparativamente ao 3DS1. O fluxo de autenticação sem fricção, onde o emissor autentica a transação em segundo plano sem ação do cliente, representa 80 a 90% das transações autenticadas para os comerciantes bem configurados. As transações restantes que requerem um desafio (tipicamente notificação push da aplicação bancária ou OTP) registam algum abandono, mas este é significativamente inferior ao abandono observado com o modelo de redirecionamento e senha estática do 3DS1.
O que é o valor ECI na autenticação 3DS?
O valor do Indicador de Comércio Eletrónico (ECI) numa resposta de autenticação 3DS indica o nível de autenticação alcançado. ECI 05 (Visa) ou 02 (Mastercard) significa que a autenticação completa foi concluída e proporciona transferência total de responsabilidade. ECI 06 ou 01 significa que o cartão tentou a autenticação mas o emissor não a suportou, proporcionando transferência limitada de responsabilidade. ECI 07 significa que a autenticação não foi realizada; não se aplica qualquer transferência de responsabilidade.
O que acontece se um cliente falhar a autenticação 3D Secure?
Se o cliente não concluir o desafio 3DS2 (cancela o push da aplicação bancária, introduz o OTP errado ou deixa a sessão expirar), a autenticação falha e o pagamento não é processado. O seu gateway deve exibir uma mensagem de erro clara e permitir que o cliente tente novamente ou use um método de pagamento diferente. A autenticação falhada não é uma contestação; a transação simplesmente não é autorizada.
Também pode gostar de
Gateway de pagamento de alto risco
Processamento seguro para setores de alto risco, com encaminhamento para vários adquirentes e proteção contra contestações.
Soluções de pagamento para pequenas empresas
Preços IC++ transparentes, terminal Smart POS incluído e ativação em 24 horas para pequenos negócios.
Integrações de pagamento para e-commerce
Plugins de instalação rápida para Shopify, WooCommerce, Magento e PrestaShop, com acesso completo à API.
Otimize os seus pagamentos hoje
A RoxPay suporta 3DS2 nativo com otimização da taxa sem fricção, transferência de responsabilidade para transações autenticadas e testes completos em sandbox. Certificada PCI DSS Level 1, preços IC++ a partir de 0,45%.
✓ Sem custos fixos mensais · ✓ Ativação em 24 horas · ✓ Suporte técnico dedicado
