Resumo
O padrão 3D Secure, também conhecido por marcas como Visa Secure, Mastercard Identity Check ou American Express SafeKey, pretende reduzir fraudes e aumentar a segurança dos pagamentos online.
O 3D Secure 2 (3DS2) introduz a “autenticação sem atrito” e melhora a experiência de compra em relação ao 3D Secure 1. É a principal forma de autenticação de cartões usada para cumprir os requisitos da Autenticação forte de cliente (SCA) na Europa e um mecanismo fundamental para que as empresas possam solicitar isenções da SCA.
A Stripe usa 3D Secure 2 em nossas APIs de pagamentos, SDKs móveis e no Stripe Checkout.
Breve história do 3D Secure 1
Apesar de medidas extras de segurança usadas em algumas regiões, como o sistema de verificação de endereço (AVS) ou o CVC, pagamentos com cartão de crédito e débito ainda correm grandes riscos de fraudes. Na verdade, é por causa desse risco que os clientes têm liberdade para contestar pagamentos fraudulentos feitos com seus cartões.
Tentando resolver esse problema, as bandeiras de cartão implementaram a primeira versão do 3D Secure em 2001. Quem costuma fazer compras online já sabe como funciona o fluxo do 3D Secure: você insere os detalhes do cartão para confirmar um pagamento e, em seguida, é redirecionado automaticamente para outra página, onde seu banco pede um código ou senha para aprovar a transação. Como a página de autenticação tem a marca compartilhada com as bandeiras de cartões, a nomenclatura que elas adotam (como Visa Secure, MasterCard Identity Check ou American Express SafeKey) é mais reconhecida pelos clientes do que o 3D Secure em si.
Para empresas, a vantagem do 3D Secure é clara: a solicitação de mais informações oferece uma camada adicional de proteção contra fraudes e garante a aceitação de pagamentos com cartão feitos apenas por clientes legítimos. Outro incentivo é que a autenticação 3D Secure transfere a responsabilidade pelos estornos por fraude da sua empresa para o banco do cliente. É por isso que compras de valor mais alto, como passagens aéreas, costumam passar pelo 3D Secure.
Infelizmente, o uso do 3D Secure 1 também tem desvantagens: a etapa adicional necessária para finalizar o pagamento aumenta os atritos no fluxo de checkout e pode provocar abandono de carrinho pelo cliente. Além disso, muitos bancos ainda obrigam o titular do cartão a criar e lembrar de uma senha estática para fazer a verificação 3D Secure. Fáceis de esquecer, essas senhas reforçam ainda mais o número de carrinhos abandonados.
O que muda com o 3D Secure 2
A EMVCo, uma organização formada por seis grandes bandeiras de cartão, lançou uma nova versão do 3D Secure. O 3D Secure 2 (ou EMV 3-D Secure, 3D Secure 2.0 ou 3DS2) pretende resolver vários problemas do 3D Secure 1 introduzindo uma autenticação mais conveniente e melhorando a experiência do usuário.
Autenticação sem atrito
Com o 3D Secure 2, as empresas e os provedores de pagamentos podem enviar mais dados sobre cada transação ao banco do titular do cartão. Isso inclui dados específicos relacionados ao pagamento (como endereço de entrega) ou contextuais (o ID do dispositivo do cliente ou seu histórico de transações, por exemplo).
O banco do titular do cartão pode usar esses dados para avaliar o nível de risco da transação e selecionar a resposta adequada:
Se os dados são suficientes para que o banco reconheça que o titular legítimo está fazendo a compra, a transação passa pelo fluxo “sem atrito”, e a autenticação é concluída sem necessidade de solicitar mais informações do titular.
Se o banco decide que precisa de mais evidências, a transação é enviada para o fluxo de “desafio”, e o cliente precisa enviar mais informações para autenticar o pagamento.
Embora já houvesse uma versão limitada da autenticação baseada em riscos no 3D Secure 1, a possibilidade de compartilhar mais dados com o 3D Secure 2 deve aumentar o número de transações autenticadas sem interferência do cliente.
Exemplo de fluxo de autenticação de um pagamento usando 3D Secure 2 com fallback para 3D Secure 1
Mesmo que uma transação siga pelo fluxo sem atrito, a empresa se beneficiará da mesma transferência de responsabilidade das transações que passam pelo fluxo de desafio.
Melhor experiência do usuário
Ao contrário do 3D Secure 1, o 3D Secure 2 foi projetado após o surgimento dos smartphones e permite que os bancos ofereçam facilmente experiências de autenticação inovadoras nos aplicativos de serviços bancários móveis (denominados, às vezes, “autenticação fora de banda”). Em vez de informar uma senha ou receber uma mensagem de texto, o titular do cartão pode autenticar o pagamento por meio do aplicativo de serviços bancários usando apenas a impressão digital ou o reconhecimento facial. Esperamos que muitos bancos aceitem essas experiências mais práticas de autenticação com o 3D Secure 2.
O segundo aprimoramento da experiência do usuário é que o 3D Secure 2 foi projetado para incorporar o fluxo de desafio diretamente nos fluxos de checkout web e móvel, sem necessidade de redirecionamentos de página completa. Se um cliente autenticar em seu site ou página web, a solicitação do 3D Secure aparecerá em uma janela restrita na página do checkout (fluxo do navegador).
Fluxo do navegador do 3D Secure 2
Se estiver criando um aplicativo, os SDKs móveis compatíveis com o 3D Secure 2 permitirão elaborar um fluxo de autenticação dentro do aplicativo sem redirecionamentos para o navegador.
3D Secure 1: fluxo de autenticação para dispositivos móveis com redirecionamento de navegador
3D Secure 2: fluxo de autenticação aprimorado para dispositivos móveis executado dentro do aplicativo
3D Secure 2 e Autenticação forte de cliente
A entrada em vigor da Autenticação forte de cliente (SCA) torna o 3D Secure 2 ainda mais importante para quem opera na Europa. Como essa regulamentação requer mais autenticações em pagamentos europeus, a experiência de usuário melhorada do 3D Secure 2 pode reduzir o prejuízo nas conversões.
O próprio protocolo 3D Secure 2 também permite que provedores de pagamentos como a Stripe solicitem isenções da SCA e pulem a autenticação em pagamentos de baixo risco. Pagamentos que exigem SCA precisam passar pelo fluxo de “desafio”, enquanto aqueles que são isentos podem passar pelo fluxo “sem atrito”. No entanto, é importante lembrar que, se o provedor de pagamentos solicitar uma isenção para pagamentos que exigem SCA e a transação passar pelo fluxo “sem atritos”, ela não será abrangida pela transferência de responsabilidade.
Como a Stripe funciona com o 3D Secure 2?
A Stripe aceita o fluxo 3D Secure 2 para navegador em nossas APIs de pagamento e no Checkout, permitindo que você aplique o 3D Secure de forma dinâmica aos pagamentos de alto risco e proteja sua empresa contra fraudes. Exigimos o 3D Secure 2 quando aceito pelo banco do titular do cartão, mas recorremos ao 3D Secure 1 quando a nova versão ainda não é aceita.
Se você estiver desenvolvendo um aplicativo para dispositivos móveis, confira nossos SDKs para iOS e Android para criar um fluxo de autenticação dentro do aplicativo e oferecer uma experiência de autenticação “nativa”, evitando que os clientes sejam redirecionados para fora do aplicativo. Mesmo que o banco do titular do cartão ainda não aceite o 3D Secure 2, nossos SDKs móveis recorrerão automaticamente ao 3D Secure 1 em uma visualização web integrada ao seu aplicativo.
Saiba mais sobre nossas APIs de pagamentos, SDKs móveis ou Stripe Checkout para começar a usar o 3D Secure 2.
|
MIT
|
Para transações iniciadas pelo comerciante (MITs), a SCA só precisa ser aplicada na definição do pedido, mas não em MITs subsequentes. O direito de reembolso incondicional de oito semanas, semelhante aos débitos automáticos SEPA, será introduzido em MITs. |
|---|---|
|
MOTO
|
Em transações de pedidos por correio ou telefone (MOTO), apenas o início de uma transação de pagamento precisa ser não digital para que essa transação seja isenta de SCA. |
|
Vinculação dinâmica
|
Os elementos da SCA que vinculam dinamicamente a transação a um valor e a um beneficiário específicos devem ser usados para transações com pagamento eletrônico nas quais o pagamento é feito por meio de um dispositivo do pagador usando tecnologia por proximidade (por exemplo, comunicação de campo próximo, ou NFC) e a aplicação da SCA requer que o dispositivo do pagador tenha acesso à Internet. |
|
Serviços de informações da conta
|
Para os PSPs que prestam serviços de informações da conta no open banking, a SCA só é exigida no primeiro acesso aos dados. No entanto, a SCA é exigida quando os clientes acessam dados agregados da conta no domínio do provedor de serviços de informações da conta, pelo menos a cada 180 dias. |
|
Tokenização
|
A tokenização requer a aplicação da SCA quando o titular do cartão tem envolvimento ativo no processo de tokenização (por exemplo, ao registrar ou substituir um cartão em uma carteira ou solução de preenchimento de cartão). |
|
Monitoramento de transações
|
A Autoridade Bancária Europeia emitirá Normas Técnicas Regulamentares para a utilização do monitoramento de transações pelos provedores de serviços de pagamento, inclusive por meio de características ambientais e comportamentais (por exemplo, localização do cliente ou hábitos de consumo). Isso preserva a utilização de isenções de SCA em transações que representam um risco baixo (ou seja, isenções na Análise de Risco de Transação). |
|---|---|
|
Isenções de SCA
|
Também foi exigido que a EBA desenvolva novas Normas Técnicas Regulamentares relacionadas às isenções e aos requisitos SCA, tendo em conta uma abordagem baseada no risco e a utilização de tecnologia. |
|
Autenticação de dois fatores
|
As novas regras sugerem que os fatores utilizados para a autenticação de dois fatores de acordo com a SCA não precisam pertencer a categorias diferentes, desde que tenham total independência. Isso poderia permitir que os clientes se autenticassem usando duas senhas, ou uma impressão digital e reconhecimento facial. |
|
Acessibilidade
|
Os PSPs têm de oferecer diferentes formas de realizar a SCA que não dependam da posse de um dispositivo inteligente, por exemplo, por meio de SMS. |
|
Responsabilidade dos TSPs
|
A responsabilidade é atribuída aos provedores de serviços técnicos (TSPs) e aos operadores de sistemas de pagamento em caso falta de suporte à aplicação da SCA. Isso visa garantir maior cooperação entre todas as partes envolvidas na execução da SCA. |
|---|---|
|
Terceirização
|
Os provedores de serviços de pagamento que dependem de TSPs para o fornecimento e verificação de elementos da SCA precisam celebrar acordos de terceirização com esses TSPs. A EBA estabelecerá os requisitos para esses acordos de terceirização. |