Autenticação 3DS 2.0

O que é 3DS 2.0?

Com o objetivo de minimizar o índice de fraude sem prejudicar a taxa de conversão, a indústria de meio de pagamento desenvolveu um novo padrão de autenticação, chamado EMV 3DS , ou também chamado de 3DS 2.0. A nova versão é capaz de analisar dezenas de variáveis que são utilizadas como critérios para determinar se um comprador é de fato o portador cartão, permitindo em alguns casos, a autenticação silenciosa do mesmo (autenticação sem desafio), sem prejuízo à questão do Liability Shift dos estabelecimentos.

Principais benefícios:

Palavras chaves: Autenticação de Cartão de Crédito e Débito, EMVCO, 3DS 2.0, Visa, Mastercard, E-Commerce

Quem pode usar o 3DS 2.0?

Todos os estabelecimentos eCommerce devem se adequar à solução a partir de Maio de 2019 frente ao Release de Bandeiras. O 3DS 2.0 é válido para todas as transações de eCommerce, sejam de débito, crédito ou pré-pago. Aos segmentos que possuem alto índice de chargeback/fraude, a solução tende a ser ainda mais vantajosa frente ao benefício de passar o liability shift ao banco emissor.

Quais são requisitos para a utilização do 3DS 2.0?

O estabelecimento comercial deve atender aos requisitos abaixo para a utilização do 3DS 2.0:

Bandeiras e Emissores Disponíveis

Para envio de transações com pedido de autenticação 3DS 2.0 é fundamental que, além da Cielo, o Emissor e Bandeira estejam prontos com a solução. Dentre as bandeiras do mercado, atualmente estão disponíveis Visa e Mastercard no 3DS 2.0 Cielo. Ambas possuem um modelo de Stand-In, caso o Emissor ainda não esteja apto a responder um pedido de autenticação usando EMV 3DS 2.0. Nesse cenário, a bandeira avalia os dados enviados, como por exemplo o histórico comportamental do cliente e transacional, classificando os pedidos de autenticação como “Baixo Risco” e “Não Baixo Risco”. A partir dessas informações, os Emissores poderão contar com uma proteção mesmo não possuindo uma solução própria de 3DS 2.0, e terão uma maior confiança nas transações autenticadas. Em casos de Stand-In, a autenticação ocorre de forma silenciosa (sem desafio para o portador) e, uma vez que a transação foi autenticada, o liability em caso de fraude ficará com o Emissor. A decisão de autorizar ou não a transação é do Emissor.

Em breve as bandeiras Elo e Amex também estarão disponíveis.

  BANDEIRAS    
BANCO EMISSOR MASTERCARD VISA ELO
Banco do Brasil Crédito/Débito
Caixa Econômica Crédito
Santander Crédito/Débito Crédito/Débito
Itaú Crédito Crédito
Midway Crédito
PagSeguro Crédito
Acesso Crédito
Banco Neon Crédito
Realize Crédito
C6 Crédito/Débito
Porto Seguro Crédito
Pernambucanas Crédito

O que é o Data Only – Somente Notificação

O Data Only é um campo opcional ao lojista que poderá ser utilizado exclusivamente para cartões Mastercard. Para esses casos, o ECI será sempre 04.

Para utilizá-lo, deverá ser parametrizado o campo bpmpi_auth_notifyonly descrito no item Etapa de Autenticação – passo 3 – Mapeamento de classes. No modelo Data Only, os campos adicionais do 3DS 2.0 são mapeados da mesma forma, e enviados para a Mastercard e Bancos Emissores, porém, sem solicitar a autenticação.

O benefício do uso do Data Only é enriquecer o banco de dados dos Bancos Emissores e da Mastercard, que passará a receber mais informações sobre os portadores de cada lojista. Esse campo busca aprimorar a autenticação silenciosa e o índice de aprovação dos Emissores, considerando o contexto atual onde o mercado está evoluindo para a integração com o novo protocolo de autenticação 2.0. Além disso, a partir de Maio de 2019, a bandeira Mastercard cobrará um fee adicional por transação não autenticada do adquirente, que poderá impactar no preço negociado entre a Cielo e o estabelecimento. O Data Only isenta o valor do fee cobrado.

Vale destacar que nesse modelo, visto que não há autenticação do Emissor, o risco de chargeback por fraude permanece com o lojista.

Fluxo de Pagamento 3DS 2.0 | Com desafio

Fluxo com desafio 01 Fluxo com desafio 02

  1. O Portador preenche os dados do cartão no checkout do estabelecimento.
  2. O Estabelecimento aciona a solução 3DS 2.0 da Cielo via script para autenticação.
  3. A solução 3DS 2.0 da Cielo envia ao MPI (plataforma de autenticação) os dados do comprador.
  4. O MPI se comunica com a Bandeira para processar a autenticação. A Bandeira identifica o emissor do cartão, e envia dos dados do comprador para análise. O emissor identifica o portador como um possível risco, desta forma, exige o desafio e retorna a URL de Autenticação.
  5. A Bandeira retorna a URL de autenticação ao MPI.
  6. O MPI retorna a URL de autenticação à solução 3DS 2.0.
  7. A solução 3DS 2.0 retorna a URL de Autenticação ao estabelecimento via script.
  8. O script apresenta a tela da autenticação via lightbox.
  9. O portador resolve o desafio na tela do emissor.
  10. O emissor retorna o resultado da autenticação à Bandeira.
  11. A Bandeira retorna o resultado da autenticação ao MPI.
  12. O MPI retorna o resultado da autenticação à solução 3DS 2.0.
  13. A solução 3DS 2.0 retorna o resultado da autenticação ao estabelecimento via script (CAVV, ECI e XID).
  14. O estabelecimento envia uma requisição de autorização com os dados da autentiação à API Cielo 3.0.
  15. A API Cielo 3.0 retorna o resultado da autorização ao estabelecimento.
  16. O estabelecimento informa o resultado do pagamento..

Fluxo de Pagamento 3DS 2.0 | Sem desafio

Fluxo se desafio

  1. O Portador preenche os dados do cartão no checkout do estabelecimento
  2. O Estabelecimento aciona a solução 3DS 2.0 da Cielo via script para autenticação
  3. A solução 3DS 2.0 da Cielo envia ao MPI (plataforma de autenticação) os dados do comprador
  4. O MPI se comunica com a Bandeira para processar a autenticação. A Bandeira identifica o emissor do cartão, e envia dos dados do comprador para análise. O emissor identifica o portador como um possível risco, desta forma, exige o desafio e retorna a URL de Autenticação
  5. A Bandeira retorna o resultado da autenticação silenciosa (CAVV e ECI)
  6. O MPI retorna o resultado da autenticação silenciosa à solução 3DS 2.0
  7. A solução 3DS 2.0 retorna o resultado da autenticação silenciona ao estabelecimento via script
  8. O estabelecimento envia uma requisição de autorização com os dados da autentiação à API Cielo 3.0
  9. A API Cielo 3.0 retorna o resultado da autorização ao estabelecimento
  10. O estabelecimento informa o resutlado do pagamento

Como funciona a autorização com autenticação via 3DS 2.0?

O processo de autorização de cartão autenticada via 3DS 2.0 ocorre em duas etapas:

  1. Etapa 1: Autenticação
  2. Etapa 2: Autorização

O fluxo abaixo descreve as etapas em alto nível:

Fluxo 3DS 2.0

  1. O portador escolhe pagar com cartão de crédito ou débito
  2. O estabelecimento solicita a autenticação através da solução Cielo
  3. A plataforma de autenticação poderá seguir um dos dois fluxos: requisitar a autenticação do portador ou realizar a autenticação de forma silenciosa. No primeiro caso, a plataforma retornará a URL de Autenticação ao estabelecimento. No segundo caso, o passo seguinte já é o retorno com o resultado da autenticação.
  4. O estabelecimento apresenta a interface de autenticação no lightbox (URL de Autenticação do emissor)
  5. O portador se autentica no emissor (processo conhecido como realizar o desafio )
  6. O emissor retorna o resultado da autenticação à plataforma 3DS, que por sua vez repassa para o estabelecimento
  7. O estabelecimento poderá ou não, seguir com o processo de autorização. Quando optar por autorizar deverá submeter o resultado da autenticação no contrato técnico de autorização
  8. A Cielo retorna o resultado da autorização para o estabelecimento, que por sua vez, retorna para o portador

Autenticação

A solução é composta pelo passo de solicitação de token de acesso via API. Clique em uma das opções abaixo para visualizar o manual mais adequado para sua necessidade:

  1. Autenticação via Java Script: ideal para implementação em websites
  2. Autenticação via SDK Android: ideal para implementação in-app Android em websites
  3. Autenticação via SDK IOS: ideal para implementação em in-app IOS em websites

Autorização com Autenticação

Após autenticação ser concluída, submete-se ao processo de autorização, enviando os dados de autenticação no modelo de "autenticação externa" (nó ExternalAuthentication ). Veja maiores detalhes em: https://developercielo.github.io/manual/autorizacao-com-autenticacao