Usługi 3DS1 i 3DS2 są dostępne w ramach kompleksowej integracji spotkań w Centrum działań. Na potrzeby swojej integracji możesz wdrożyć jeden z tych formatów (lub oba).
Zarówno 3DS1, jak i 3DS2 spełnią wymóg silnego uwierzytelniania klienta dyrektywą PSD2, ale istnieją pewne kluczowe różnice:
- 3DS1: możesz aktywować 3DS1 dla transakcji, gdy otrzymasz sygnały, że obciążenie jest fałszywe.
- Wdrożenie 3DS1 wymaga wprowadzenia zmian na serwerze rezerwacji.
- 3DS2: usługa 3DS2 będzie używana tylko w przypadku transakcji objętych dyrektywą PSD2 (bank autoryzacyjno-rozliczeniowy i bank klienta znajdują się w Europejskim Obszarze Gospodarczym).
- Wdrożenie 3DS2 wymaga wprowadzenia zmian w pliku danych sprzedawcy.
Implementacja 3DS2
Implementacja 3DS2 wymaga dodania dodatkowych pól do pliku danych sprzedawcy w komunikacie TokenizationConfig. Jeśli wszystkie płatności trafiają na to samo konto, powtarzasz wartość we wszystkich wpisach sprzedawcy. Jeśli płatności trafiają na różne konta, wartości w każdym wpisie sprzedawcy muszą dotyczyć konta pozyskującego środki w ramach transakcji.
Zmiany w pliku danych Merchant Center
merchant_of_record_name: imię i nazwisko zarejestrowanego sprzedawcy. Ta nazwa widoczna dla użytkownika będzie widoczna w testach zabezpieczających logowanie w 3DS2.payment_country_code: kraj, w którym zostanie przetworzona transakcja, w formacie ISO 3166-1 alfa-2.- Komunikat
CardNetworkParameters: ten komunikat jest powtarzany z wartościami odpowiednimi dla różnych sieci (wymagane tylko w przypadku kart Visa i American Express)card_network: sieć (Visa, American Express), do której mają zastosowanie te wartości.acquirer_bin: numer identyfikacyjny banku autoryzacyjnego użytego do przetworzenia karty.acquirer_merchant_id: identyfikator sprzedawcy przypisany przez centrum autoryzacyjne do sprzedawcy na potrzeby autoryzacji transakcji (w przypadku transakcji Visa i American Express).
Jeśli dodasz te pola do pliku danych sprzedawcy, otrzymasz kryptogram 3DS2 w unparsed_payment_method_token otrzymanym przez serwer rezerwacji za każdym razem, gdy dla transakcji obowiązuje zasada PSD2. Użytkownik unparsed_payment_method_token i jego umieszczony kryptogram należy przekazać do partnera obsługującego przetwarzanie zgodnie z jego specyfikacją.
Implementacja 3DS1
Zmiany na serwerze rezerwacji
Wykonamy żądanie CreateBooking. Jeśli stwierdzisz, że 3DS1 jest potrzebny do transakcji, zwrócimy Booking Failure z metody CreateBooking i jako przyczynę podasz PAYMENT_REQUIRES_3DS1. W tej odpowiedzi o błędzie musisz też określić komunikat ThreeDS1Parameters w komunikacie PaymentFailureInformation:
acs_url= adres URL, z którego ma zostać wczytany formularz, który zostanie przedstawiony użytkownikowi w celu uwierzytelnienia.pa_req= żądanie uwierzytelniania płatności. Do opublikowania w formularzu ACSUrl.transaction_id= identyfikator używany przez dostawcę usługi ACS. Do opublikowania w formularzu ACSUrl.md_merchant_data: dane, które Centrum działań mają być udostępnione dostawcy usługi ACS, jeśli zostaną udostępnione.
Następnie wyślemy ponownie pierwotne żądanie CreateBooking z adresem pa_response zawartym w wiadomości PaymentInformation. Pole pa_response będzie zawierać ładunek zwrócony do nas od dostawcy ACS. Powinno ono zostać użyte przez Ciebie do autoryzacji transakcji z firmą obsługującą płatności.
Oto schemat opisujący przepływ 3DS1:
