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 3DS nativo, o provedor precisa declararoperation=3ds2. Confirme essa capacidade na matriz de modalidades do hub 3DS2 e pelo badge de 3DS nativo na tabela de meios de pagamento. O badge de 3DS2 Malga representa paymentTypes=3ds2_malga, uma capacidade diferente.Inclua o objeto threeDSecure2 na cobrança sem
setupId, sem mpi e sem dataOnly.
Esse fluxo não é o mesmo do 3DS2 Malga: cobranças com setupId exigem paymentTypes com 3ds2_malga e não exigem operation=3ds2. A comparação completa das modalidades está no hub 3DS2.
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
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.
Na próxima seção iremos mostrar como lidar com o fluxo com desafio.