O 3DS1 e o 3DS2 estão disponíveis para a integração completa de reservas do Centro de ações. Você pode implementar qualquer um deles ou ambos na sua integração.
O 3DS1 ou o 3DS2 atendem ao requisito de autenticação forte do cliente da PSD2, mas há algumas diferenças importantes:
- 3DS1: você pode acionar o 3DS1 para uma transação quando tiver sinais de que a cobrança é fraudulenta.
- A implementação do 3DS1 requer alterações no seu servidor de agendamento.
- 3DS2: ele será usado somente nas transações onde o PSD2
for aplicável (o banco adquirente e o banco do cliente estão no EEE).
- A implementação do 3DS2requer alterações no seu feed do comerciante.
Implementação do 3DS2
Para essa implementação, você precisa adicionar outros campos ao seu
feed do comerciante na mensagem TokenizationConfig. Se
todos os pagamentos forem para a mesma conta, repita o valor em cada
entrada do comerciante. Se os pagamentos forem para contas diferentes, os valores em cada entrada do comerciante precisarão ser da conta que está recebendo os fundos da transação.
Alterações no feed do comerciante
merchant_of_record_name: nome do comerciante responsável pelo processamento (MOR, na sigla em inglês). Esse nome visível ao usuário será mostrado nos desafios do 3DS2.payment_country_code: país onde a transação será processada, no formato ISO 3166-1 Alfa-2.- Mensagem
CardNetworkParameters: é repetida com os valores específicos para diferentes redes (necessária apenas para Visa e American Express)- .
card_network: a rede (Visa, American Express) aplicável a esses valores.acquirer_bin: o número de identificação do banco adquirente usado para o processamento do cartão.acquirer_merchant_id: o identificador do comerciante atribuído pelo adquirente para uso na autorização de transações (para transações Visa e American Express).
Ao adicionar esses campos ao seu feed de comerciante, você vai receber um criptograma 3DS2
dentro do unparsed_payment_method_token recebido pelo seu servidor de agendamento sempre que o PSD2 for aplicável à transação. Você deve transmitir o unparsed_payment_method_token e o criptograma incorporado ao parceiro de processamento, de acordo com a especificação dele.
Implementação do 3DS1
Alterações no servidor de agendamento
Faremos uma solicitação CreateBooking
e, se você determinar que o 3DS1 é necessário para a transação, retorne uma
Booking Failure do método CreateBooking e especifique
PAYMENT_REQUIRES_3DS1 como a causa. Nessa resposta de falha,
você também precisará especificar a mensagem ThreeDS1Parameters
na mensagem PaymentFailureInformation:
acs_url: URL que direciona o usuário para um formulário de autenticação.pa_req= uma solicitação PaymentAuthentication que será enviado ao formulário ACSUrl.transaction_id= um identificador usado pelo provedor de ACS a ser exibida no formulário ACSUrl.md_merchant_data= dados que o Centro de ações vai compartilhar com o provedor de ACS, se informados.
Em seguida, reenviaremos a solicitação
CreateBooking
original com o pa_response localizado na
mensagem PaymentInformation. O campo pa_response vai
conter o payload informado por um provedor de ACS e deverá ser usado por você para autorizar a transação junto ao seu processador.
Veja este diagrama que descreve o fluxo 3DS1:
