3-D Secure (3DS)

3-D Secure to protokół, którym organizacje kartowe sprawdzają, czy osoba płacąca w internecie jest posiadaczem karty. EMVCo, organizacja standaryzacyjna należąca do organizacji kartowych, publikuje go jako EMV 3-D Secure i opisuje jako protokół zapobiegania oszustwom w handlu elektronicznym, który pozwala uwierzytelnić konsumenta przy zakupach bez fizycznej obecności karty. Pierwsza generacja działała tylko w przeglądarce i została wycofana. EMV 3DS (wersja 2.x) działa w przeglądarkach i w aplikacjach mobilnych. Wersja 2.1 obsługuje już silne uwierzytelnienie klienta, a EMVCo zaleca wersję 2.2 lub nowszą.

W sprawdzeniu 3DS biorą udział trzy domeny. Po stronie sprzedawcy serwer 3DS (a w aplikacji mobilnej SDK 3DS) zbiera dane o transakcji i urządzeniu. Organizacja kartowa prowadzi serwer katalogowy (Directory Server), który kieruje komunikat do właściwego wydawcy. Po stronie wydawcy serwer kontroli dostępu (Access Control Server, ACS) decyduje, czy posiadacz karty musi cokolwiek zrobić.

Strona sprzedawcy wysyła żądanie uwierzytelnienia (AReq). ACS ocenia ryzyko i odpowiada (ARes) statusem transakcji. Status Y w ARes oznacza, że posiadacz karty jest uwierzytelniony bez żadnej interakcji: to ścieżka bez dodatkowej weryfikacji (frictionless). Status C oznacza, że potrzebne jest wyzwanie (challenge): posiadacz karty potwierdza płatność kodem jednorazowym, w aplikacji wydawcy albo biometrią, a ACS przekazuje wynik końcowy w komunikacie RReq. Pozostałe statusy oznaczają odmowę uwierzytelnienia (N), odrzucenie z prośbą, by nie autoryzować płatności (R), uwierzytelnienie, którego nie dało się przeprowadzić (U), oraz próbę bez pełnego uwierzytelnienia (A). Wersja 2.2 dodała uwierzytelnienie poza sesją sprzedawcy (decoupled, status D). Wynik trafia do komunikatu autoryzacyjnego, więc wydawca widzi przy autoryzacji, czy i jak posiadacz karty został uwierzytelniony.

Zakres pracy zależy od tego, po której stronie płatności stoi Twój system. Pożyczkodawca, który przyjmuje w aplikacji spłaty kartą, jest po stronie sprzedawcy. Pożyczkodawca, który oferuje własną kartę przez partnera wydającego, jak w haśle wydawanie kart, jest po stronie wydawcy, a jego aplikacja często staje się miejscem, w którym klient zatwierdza płatności internetowe.

Po stronie sprzedawcy 3DS uruchamia bramka płatnicza, ale wyzwanie musi obsłużyć aplikacja. Ekran wyzwania otwiera się w aplikacji przez SDK 3DS albo w WebView. Aplikacja musi poczekać na wynik, trzymać płatność w stanie oczekującym i obsłużyć klienta, który zamknie ekran albo w ogóle nie wróci. Spłata zakończona statusem N lub R powinna pokazać powód zrozumiały dla klienta, a nie ogólny błąd.

Po stronie wydawcy praca dotyczy kanału zatwierdzania. PSD2 wiąże kod uwierzytelnienia zdalnej płatności kartą z kwotą i odbiorcą (dynamic linking). Zgodnie z art. 5 RTS (rozporządzenie delegowane 2018/389) płatnik musi widzieć kwotę i odbiorcę, a każda zmiana któregoś z nich unieważnia kod. Gdy zatwierdzenie odbywa się w Twojej aplikacji, powiadomienie push otwiera ekran z kwotą i sprzedawcą, klient potwierdza PIN-em albo biometrią, a aplikacja odsyła odpowiedź, zanim minie limit czasu ACS. Art. 4 ogranicza liczbę kolejnych nieudanych prób uwierzytelnienia do pięciu w określonym czasie, po czym czynność zostaje zablokowana, więc aplikacja potrzebuje widocznego stanu blokady i ścieżki odblokowania.

To, jak często klient zobaczy ten ekran, zależy od wyjątków przewidzianych w RTS. Według art. 16 zdalna płatność do 30 EUR może pominąć silne uwierzytelnienie, dopóki łączna kwota od ostatniego uwierzytelnienia nie przekroczy 100 EUR, a liczba takich płatności z rzędu nie przekroczy pięciu. Art. 18 pozwala na wyjątek po analizie ryzyka transakcji, do 100, 250 albo 500 EUR przy zdalnych płatnościach kartą, w zależności od wskaźnika oszustw dostawcy. Strona wydawcy musi prowadzić te liczniki dla każdej karty i zerować je po każdym uwierzytelnieniu.

Gdy płatność kartą nie przejdzie, klient i dział obsługi muszą wiedzieć dlaczego. Wynik 3DS zapisany przy każdej transakcji kartą pozwala odróżnić w historii w aplikacji nieudane uwierzytelnienie od braku środków albo zablokowanej karty.

Art. 97 ust. 1 PSD2 (dyrektywa (UE) 2015/2366) wymaga silnego uwierzytelnienia klienta, gdy płatnik uzyskuje dostęp do rachunku płatniczego online, inicjuje elektroniczną transakcję płatniczą albo przeprowadza przez kanał zdalny czynność, która może wiązać się z ryzykiem oszustwa płatniczego lub innych nadużyć. Art. 97 ust. 2 dodaje dynamiczne powiązanie przy zdalnych płatnościach elektronicznych. Art. 98 zlecił przygotowanie regulacyjnych standardów technicznych, które stały się rozporządzeniem delegowanym 2018/389, stosowanym od 14 września 2019 r. Europejski Urząd Nadzoru Bankowego (EBA) dał rynkowi czas do 31 grudnia 2020 r. na przejście z płatnościami kartą w handlu elektronicznym na silne uwierzytelnienie. RTS nie wymieniają 3-D Secure. Są neutralne technologicznie, a płatności kartą spełniają je przez EMV 3DS. W listopadzie 2025 r. Parlament Europejski i Rada osiągnęły wstępne porozumienie w sprawie PSD3 i rozporządzenia w sprawie usług płatniczych (PSR), które zastąpią PSD2 i przeniosą większość jej przepisów do bezpośrednio stosowanego rozporządzenia. W październiku 2026 r. nowe przepisy jeszcze nie obowiązują: zaczną działać po formalnym przyjęciu, publikacji w Dzienniku Urzędowym UE i okresie przejściowym, więc dziś system projektuje się według PSD2 i RTS.

Art. 74 ust. 2 PSD2 określa, kto ponosi stratę. Jeśli dostawca płatnika nie wymaga silnego uwierzytelnienia, płatnik nie ponosi strat, chyba że działał umyślnie w celu oszustwa. Jeśli odbiorca albo jego dostawca nie akceptuje silnego uwierzytelnienia, zwraca szkodę dostawcy płatnika. Dlaczego numer karty i CVV nie mogą być składnikiem uwierzytelnienia, opisuje hasło wydawanie kart.

W Aasa24, aplikacji pożyczkowej, którą od maja 2023 r. budujemy dla Aasa Polska, klienci zarządzają kartą kredytową Visa wydaną przez licencjonowanego partnera, jak opisuje hasło wydawanie kart. Dodajemy do Aasa24 3-D Secure; w październiku 2026 r. prace trwają.