Skip to main content
Quando uma cobrança é enviada com dados de 3DS2, o provedor irá solicitar uma analise ao banco emissor.
O banco emissor pode exigir que o cliente faça uma autenticação. Esse processo é conhecido como desafio.
Uma cobrança pode ser autorizada pelo banco emissor sem exigir desafio.
A cobrança com desafio exigirá uma ação por parte do usuário para autenticar a transação. Nesse caso o usuário será redirecionado ao banco para autenticar a transação.
O resultado final da transação será enviado via webhook

Cobrança com 3D Secure 2

Para iniciar uma cobrança com 3DS2, primeiro certifique-se de que o provedor está na lista de provedores suportados.
Inclua o objeto threeDSecure2 na cobrança.

Principais informações

  • redirectURL: A URL que o provedor irá utilizar para retornar ao site de origem após o redirecionamento
  • requestorURL: A URL do site do portador do cartão
  • browser: Dados do navegador do portador do cartão
  • cardHolder: Dados do portador do cartão
  • billingAddress: Endereço de cobrança
  • shippingAddress: Endereço para envio

Exemplo de cobrança com 3D Secure 2

Exemplo de resposta com 3D Secure 2

A resposta da transação irá incluir o objeto authData dentro do objeto threeDSecure2, com dados para a ação de autenticação.

Examinando o objeto authData

  • O atributo action representa que tipo de ação foi solicitada para autenticação.
  • O atributo providerType identifica em qual provedor o 3DS2 foi processado.
  • O atributo responseType mostra qual é a etapa do desafio, podendo ser uma etapa de autenticação ou autorização.
  • O atributo response é um objeto dinâmico com a resposta do provedor com dados para autenticação.
Os provedores implementam o desafio de formas diferentes, exigindo tratamentos específicos.
Na próxima sessão iremos mostrar como lidar com o fluxo com desafio.