Adicionar compatibilidade com 3DS1 e 3DS2

Os dois estão disponíveis para a integração completa de reservas 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 aplicam
  • acquirer_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: