Como funciona o 3D Secure 2
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.
Was this page helpful?