O 3DS1 e o 3DS2 estão disponíveis para a integração completa de agendamentos da Central de ações. É possível implementar uma ou ambas as opções para 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 decidir 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 apenas para transações em que a PSD2
se aplica (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 implementar o 3DS2, você precisa adicionar outros campos ao seu feed do comerciante na mensagem TokenizationConfig. Se todos os pagamentos forem para a mesma conta, você repetirá 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á adquirindo os fundos
na transação.
Alterações no feed do comerciante
merchant_of_record_name: nome do comerciante responsável pelo processamento (MOR). 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.CardNetworkParameters: essa mensagem é repetida com os valores específicos para diferentes redes (necessária apenas para Visa e American Express)card_network: a rede (Visa, American Express) a que esses valores se aplicamacquirer_bin: o número de identificação do banco adquirente usado para processar o cartão.acquirer_merchant_id: o identificador do comerciante atribuído pela credenciadora ao comerciante 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ê receberá um criptograma
3DS2 dentro do unparsed_payment_method_token recebido pelo
servidor de reservas sempre que a PSD2 se aplicar à transação. Você precisa 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 um
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 dentro da mensagem PaymentFailureInformation:
acs_url= o URL de onde carregar um formulário para apresentar ao usuário para autenticação.pa_req= uma solicitação PaymentAuthentication que será publicada no formulário ACSUrl.transaction_id= um identificador usado pelo provedor de ACS que será exibido no formulário ACSUrl.md_merchant_data= dados que a Central de ações compartilhará com o provedor do ACS, se fornecidos.
Em seguida, reenviaremos a solicitação
CreateBooking
original com o pa_response localizado na mensagem
PaymentInformation. O campo pa_response contém o payload retornado de um provedor de ACS e precisa ser usado por você para autorizar a transação com seu processador.
Veja este diagrama que descreve o fluxo 3DS1:
