Dodanie obsługi uwierzytelniania 3DS1 i 3DS2

W przypadku kompleksowej integracji rezerwacji w Centrum działań dostępne są zarówno 3DS1, jak i 3DS2. W ramach integracji możesz zastosować jedną lub obie te metody.

Zarówno protokół 3DS1, jak i 3DS2 spełniają wymagania dyrektywy PSD2 dotyczące silnego uwierzytelniania klienta, ale występują pewne kluczowe różnice:

• 3DS1: możesz uruchomić 3DS1 w przypadku transakcji, jeśli masz sygnały wskazujące na to, że obciążenie jest oszukańcze.
  • Wdrożenie 3DS 1 wymaga wprowadzenia zmian w serwerze rezerwacji.
• 3DS2: protokół 3DS2 będzie używany tylko w przypadku transakcji, w których obowiązuje dyrektywa PSD2 (bank przejmujący i bank klienta znajdują się w Europejskim Obszarze Gospodarczym).
  • Wdrożenie 3DS2 wymaga wprowadzenia zmian w pliku danych sprzedawcy.

Wdrożenie uwierzytelnienia 3DS2

Wdrożenie 3DS 2 wymaga dodania dodatkowych pól do pliku danych sprzedawcy w wiadomości TokenizationConfig. Jeśli wszystkie płatności trafiają na to samo konto, powtarzasz tę samą wartość w każdej pozycji dotyczącej sprzedawcy. Jeśli płatności mają trafiać na różne konta, wartości w każdej pozycji sprzedawcy muszą być wartościami konta, które pobiera środki w ramach transakcji.

Zmiany w pliku danych sprzedawcy

• merchant_of_record_name: nazwa zarejestrowanego sprzedawcy (MOR). Ta nazwa widoczna dla użytkowników będzie wyświetlana w wyzwaniach 3DS2.
• payment_country_code: kraj, w którym transakcja będzie przetwarzana, w formacie ISO 3166-1 alfa-2.
• CardNetworkParameters message: ten komunikat jest powtarzany z wartościami określonymi dla różnych sieci (wymagany tylko w przypadku kart Visa i American Express).
  • card_network: sieć (Visa, American Express), do której odnoszą się te wartości
  • acquirer_bin: numer identyfikacyjny banku akceptującego, używany do przetwarzania karty.
  • acquirer_merchant_id: identyfikator sprzedawcy przypisany przez instytucję nabywającą do autoryzacji transakcji (w przypadku transakcji z kart Visa i American Express).

Dodając te pola do pliku danych sprzedawcy, otrzymasz kryptogram 3DS2 w unparsed_payment_method_token otrzymanym przez Twój serwer rezerwacji, gdy transakcja będzie podlegać przepisom PSD2. Musisz przekazać unparsed_payment_method_token wraz z zawartym w nim kryptogramem swojemu partnerowi realizującemu przetwarzanie zgodnie z jego specyfikacją.

Wdrożenie uwierzytelnienia 3DS1

Zmiany w serwerze rezerwacji

Wyślemy CreateBooking prośbę, a jeśli uznasz, że do przeprowadzenia transakcji potrzebna jest weryfikacja 3DS1, zwracamy Booking Failure z formy płatności CreateBooking, podając jako przyczynę PAYMENT_REQUIRES_3DS1. W odpowiedzi na błąd musisz też podać wiadomość ThreeDS1Parameters w wiadomości PaymentFailureInformation:

• acs_url = adres URL, z którego wczytywane jest formularz do przedstawienia użytkownikowi na potrzeby uwierzytelnienia.
• pa_req = żądanie autoryzacji płatności. Aby opublikować w formularzu ACSUrl:
• transaction_id = identyfikator używany przez dostawcę ACS. Aby opublikować w formularzu ACSUrl.
• md_merchant_data = dane, które Actions Center udostępnia dostawcy usługi ACS (jeśli został podany).

Następnie ponownie wyślemy pierwotną prośbę CreateBooking z pa_response w wiadomości PaymentInformation. Pole pa_response będzie zawierać ładunek zwrócony do nas przez dostawcę ACS. Użyj go, aby autoryzować transakcję w swojej firmie obsługującej płatności.

Oto diagram przedstawiający proces 3DS1: