Czym jest 3D Secure? 3D Secure (3DS) to protokół uwierzytelniania posiadacza karty w transakcjach internetowych, zarządzany przez EMVCo. Zanim sklep wyśle transakcję do autoryzacji, trzy współpracujące systemy – 3DS Server po stronie sklepu, Directory Server (DS) po stronie sieci płatniczej i ACS po stronie banku wydawcy – wymieniają dane i decydują, czy oraz jak potwierdzić tożsamość kupującego.
Definicja kanoniczna: EMV 3-D Secure (EMV 3DS) to zarządzany przez EMVCo protokół uwierzytelniania posiadacza karty w transakcjach bez fizycznej obecności karty, oparty na wymianie komunikatów między domenami sklepu, sieci płatniczej i wydawcy.
Ten artykuł wyjaśnia protokół dwutorowo: dla laika, który chce zrozumieć, co dzieje się po kliknięciu „zapłać”, oraz dla organizacji rozważającej świadczenie usług 3DS innym firmom.
3D Secure – w skrócie:
- Nazwa „3-D” pochodzi od trzech domen bezpieczeństwa: domeny acquirera (sklep i 3DS Server), domeny interoperacyjności (sieć płatnicza i DS) oraz domeny wydawcy (bank i ACS).
- Aktualna wersja specyfikacji to EMV 3DS 2.3.1.1 (2023), która zastąpiła wydanie 2.3.1.0 z 2022 r.; EMVCo rekomenduje wersje 2.2 lub wyższe dla pełnej obsługi wymogów SCA (EMVCo).
- Większość transakcji przechodzi ścieżką frictionless: wydawca uwierzytelnia kupującego na podstawie analizy ryzyka z ponad stu atrybutów danych, bez żadnego pytania do klienta.
- DS (Directory Server) to rola techniczna sieci płatniczych – nie mylić z PCI DSS, standardem bezpieczeństwa danych kartowych o zupełnie innym zakresie.
- Produkty ACS, DS, 3DS Server i 3DS SDK przechodzą formalny proces aprobaty EMVCo (testy pre-compliance na uznanej platformie, laboratorium, ICS, testy zgodności), a środowiska, w których działają, podlegają standardowi PCI 3DS Core Security Standard v1.0.
- Patronusec jako akredytowany QSA wspiera dostawców usług 3DS w certyfikacji PCI 3DS – od klasyfikacji ról po przygotowanie środowiska do oceny.
Spis treści
Czym jest 3D Secure i skąd nazwa „trzy domeny”?
3D Secure dodaje do płatności kartą w internecie etap, którego fizyczny terminal nie potrzebuje: potwierdzenie, że płacący jest rzeczywiście posiadaczem karty. Nazwa pochodzi od trzech domen (three domains), w których działają uczestnicy protokołu: domeny acquirera, domeny interoperacyjności i domeny wydawcy.
Analogia dla laika: transakcja 3DS przypomina kontrolę na lotnisku. Sklep (linia lotnicza) zgłasza pasażera, sieć płatnicza (lotnisko) kieruje go do właściwej bramki, a bank wydawca (kontrola paszportowa) decyduje – większość osób przechodzi bez zatrzymywania, a wybrane prosi o dokument. Analogicznie: sklep inicjuje uwierzytelnienie, sieć znajduje bank klienta, a bank ocenia ryzyko i tylko czasem prosi o potwierdzenie.
Historia w trzech zdaniach. Pierwsza wersja protokołu (3DS 1.0) powstała na początku lat dwutysięcznych i opierała się na statycznych hasłach, które klienci zapominali, a sklepy traciły koszyki. EMVCo przejęła rozwój i opublikowała EMV 3DS 2.x – protokół zbudowany wokół analizy ryzyka i danych z urządzenia zamiast haseł. Aktualne wydanie specyfikacji to 2.3.1.1 (2023), rozwijające m.in. uwierzytelnianie out-of-band i Secure Payment Confirmation (EMVCo).
W Europie znaczenie 3DS wzmocniła regulacja: dyrektywa PSD2 wymaga silnego uwierzytelnienia klienta (SCA) w płatnościach elektronicznych, a EMV 3DS jest podstawowym protokołem, którym wydawcy realizują ten obowiązek – EMVCo rekomenduje do tego wersje 2.2 lub wyższe.
EMV 3DS odwraca logikę pierwszej wersji protokołu: zamiast pytać każdego klienta o hasło, przekazuje wydawcy dane o transakcji i urządzeniu, aby pytać wyłącznie wtedy, gdy ryzyko tego wymaga.
Jak przebiega uwierzytelnienie 3DS krok po kroku?
Uwierzytelnienie 3DS to wymiana komunikatów trwająca zwykle ułamki sekund: sklep wysyła żądanie z danymi transakcji, sieć płatnicza kieruje je do banku wydawcy, a bank odpowiada wynikiem – albo od razu (ścieżka frictionless), albo po dodatkowym potwierdzeniu przez klienta (ścieżka challenge).
Przebieg w sześciu krokach:
- Klient klika „zapłać” w sklepie internetowym lub aplikacji.
- 3DS Server sklepu buduje komunikat AReq (Authentication Request) z danymi transakcji, przeglądarki lub urządzenia i wysyła go do sieci płatniczej.
- DS (Directory Server) sieci rozpoznaje po numerze karty, który bank ją wydał, i przekazuje AReq do właściwego ACS.
- ACS banku ocenia ryzyko: porównuje dane transakcji z historią klienta, urządzeniem, kwotą i typowymi wzorcami.
- Ścieżka frictionless: ryzyko niskie – ACS zwraca wynik pozytywny (ARes) i klient niczego nie zauważa. Ścieżka challenge: ryzyko podwyższone lub wymóg regulacyjny – klient potwierdza tożsamość, np. biometrią w aplikacji banku lub kodem jednorazowym.
- Wynik uwierzytelnienia (w tym wartość kryptograficzna potwierdzająca jego przebieg) trafia do sklepu, który dopiero teraz wysyła transakcję do autoryzacji.
Kluczowa korzyść biznesowa: w schematach kart uwierzytelnienie 3DS wiąże się co do zasady z przeniesieniem odpowiedzialności za fraud (liability shift) ze sklepu na wydawcę – szczegółowe warunki określają zasady poszczególnych organizacji płatniczych.
Uwierzytelnienie 3DS poprzedza autoryzację i jest od niej odrębne: 3DS odpowiada na pytanie „czy płaci właściciel karty”, a autoryzacja na pytanie „czy na karcie są środki”.
Czym jest 3DS Server i kto go utrzymuje?
3DS Server to komponent domeny acquirera: system, który w imieniu sklepu inicjuje uwierzytelnienie, buduje komunikaty AReq, utrzymuje certyfikowane połączenia z Directory Serverami sieci płatniczych i zwraca sklepowi wynik. Historycznie tę rolę pełnił komponent MPI (Merchant Plug-In) z protokołu 3DS 1.0.
W praktyce niewiele sklepów utrzymuje własny 3DS Server. Standardowy model rynkowy to usługa: bramka płatnicza, acquirer lub wyspecjalizowany dostawca operuje jednym 3DS Serverem dla setek merchantów, którzy integrują się przez API. Sklep widzi jedną prostą odpowiedź („uwierzytelniono / wymagany challenge / odmowa”), a całą złożoność protokołu – wersje specyfikacji, rozszerzenia komunikatów, certyfikaty do DS – obsługuje dostawca.
Dla organizacji rozważającej świadczenie tej usługi innym firmom 3DS Server jest najczęstszym punktem wejścia na rynek 3DS: nie wymaga bycia bankiem ani siecią płatniczą, a klientem może być każdy merchant lub PSP. Produkt musi jednak przejść aprobatę EMVCo (sekcja o świadczeniu usług poniżej), środowisko – certyfikację PCI 3DS, a operator – rejestrację w programach poszczególnych sieci płatniczych.
3DS Server jest jedynym komponentem protokołu EMV 3DS, który może operować dostawca niezależny zarówno od banków, jak i od sieci płatniczych – dlatego to wokół niego koncentruje się rynek usług 3DS dla merchantów.
Czym jest Directory Server (DS) i dlaczego to nie PCI DSS?
Directory Server (DS) to komponent domeny interoperacyjności, operowany przez sieci płatnicze: rozpoznaje na podstawie zakresów numerów kart, który wydawca obsługuje daną kartę, i kieruje komunikaty uwierzytelniające między 3DS Serverem a właściwym ACS. To router i strażnik zaufania całego protokołu.
Zadania DS w praktyce:
- utrzymywanie katalogu zakresów kart (card ranges) i informacji o uczestnictwie wydawców w 3DS – 3DS Serwery pobierają te dane komunikatami PReq/PRes,
- routing komunikatów AReq/ARes między tysiącami 3DS Serverów a tysiącami ACS,
- zarządzanie zaufaniem: każdy 3DS Server i ACS łączy się z DS na podstawie certyfikatów wydanych w ramach programu danej sieci,
- fallback: sieci oferują mechanizmy obsługi uwierzytelnienia, gdy wydawca nie uczestniczy w 3DS lub jego ACS jest niedostępny.
Rozjaśnijmy częstą pomyłkę językową. DS (Directory Server) to rola techniczna w protokole EMV 3DS. PCI DSS (Payment Card Industry Data Security Standard) to standard bezpieczeństwa danych kartowych obowiązujący każdy podmiot przetwarzający dane kart. Skróty brzmią podobnie, ale opisują zupełnie różne byty – a na dokładkę istnieje jeszcze PCI 3DS: standard bezpieczeństwa środowisk, w których działają komponenty ACS, DS i 3DS Server.
Directory Server (DS) to rola w protokole uwierzytelniania EMV 3DS pełniona przez sieci płatnicze, natomiast PCI DSS to standard ochrony danych kartowych – zbieżność skrótów jest przypadkowa.
Czym jest ACS i co robi wydawca podczas uwierzytelnienia?
ACS (Access Control Server) to komponent domeny wydawcy: system, który w imieniu banku decyduje, czy transakcję uwierzytelnić bez udziału klienta, poprosić o dodatkowe potwierdzenie, czy odmówić. To w ACS zapada decyzja frictionless kontra challenge i to ACS przeprowadza sam challenge.
Na wejściu ACS otrzymuje w komunikacie AReq bogaty zestaw danych o transakcji, przeglądarce lub urządzeniu i kanale sprzedaży. Silnik ryzyka wydawcy zestawia je z tym, co bank wie o kliencie: historią transakcji, typowymi urządzeniami, geografią, limitami. Wynik analizy określa ścieżkę:
- frictionless – uwierzytelnienie kończy się w tle; klient nie widzi żadnego dodatkowego kroku,
- challenge – ACS prezentuje klientowi wyzwanie: powiadomienie push z potwierdzeniem biometrycznym w aplikacji banku, kod jednorazowy albo inną metodę zgodną z SCA; w Europie dobór metod determinuje PSD2 i jej standardy techniczne.
Rynkowo ACS to domena wyspecjalizowanych dostawców: większość banków nie buduje własnego ACS, lecz kupuje go jako produkt lub usługę od firm technologicznych obsługujących wielu wydawców. To drugi, obok 3DS Servera, realny model wejścia na rynek usług 3DS – z tym że klientem jest bank, a wymagania integracyjne (systemy antyfraudowe, kanały challenge, aplikacja mobilna wydawcy) są istotnie głębsze.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że organizacje wchodzące na rynek usług 3DS najczęściej zaskakuje nie sama aprobata EMVCo, lecz zakres środowiskowy PCI 3DS. Standard obejmuje systemy wykonujące funkcje ACS, DS lub 3DS Server oraz systemy mające na nie wpływ – a więc także zaplecze: zarządzanie HSM dla kluczy protokołu, panele administracyjne, monitoring. Zanim zaplanujesz certyfikację produktu w EMVCo, narysuj granice środowiska 3DE tak, jak zrobi to asesor – to od nich zależy realny koszt utrzymania usługi.
Co trzeba zrobić, żeby świadczyć usługi 3DS innym firmom?
Wejście na rynek usług 3DS wymaga trzech równoległych ścieżek: aprobaty produktu w EMVCo, certyfikacji środowiska według PCI 3DS oraz rejestracji i testów w programach poszczególnych sieci płatniczych. Dopiero komplet otwiera komercyjne świadczenie usług ACS, DS lub 3DS Server.
Ścieżka pierwsza – aprobata EMVCo dla produktu (ACS, DS, 3DS Server lub 3DS SDK), według opublikowanego procesu EMVCo:
- rejestracja w EMVCo i podpisanie umowy (numer rejestracyjny),
- testy pre-compliance produktu na platformie testowej uznanej przez EMVCo,
- przegląd raportu z testów przez wybrane laboratorium,
- złożenie formularza ICS (Implementation Conformance Statement) i testy zgodności,
- przegląd wyników przez EMVCo i publikacja produktu na liście zatwierdzonych (Letter of Approval).
Ścieżka druga – bezpieczeństwo środowiska. Systemy wykonujące lub wspierające funkcje ACS, DS i 3DS Server podlegają standardowi PCI 3DS Core Security Standard v1.0, ocenianemu przez kwalifikowanych asesorów 3DS. Standard składa się z części bazowej (Part 1) i wymogów specyficznych dla 3DS (Part 2), obejmujących m.in. ochronę kluczy kryptograficznych protokołu w HSM. Jeżeli środowisko przetwarza też dane kartowe, równolegle stosuje się PCI DSS.
Ścieżka trzecia – programy sieci płatniczych: operator ACS lub 3DS Servera rejestruje się w programach 3DS poszczególnych organizacji (uzyskując m.in. certyfikaty do połączeń z ich DS) i przechodzi ich testy integracyjne. Warunki określa każda sieć osobno.
Patronusec prowadzi dostawców przez ścieżkę środowiskową w ramach usługi certyfikacji PCI 3DS – od wyznaczenia granic środowiska 3DE po przygotowanie do oceny.
Mit i fakt: co się myli w temacie 3D Secure?
MIT: DS w protokole 3DS to to samo co PCI DSS.
FAKT: DS (Directory Server) to komponent routingu w protokole EMV 3DS operowany przez sieci płatnicze. PCI DSS to standard bezpieczeństwa danych kartowych. Łączy je wyłącznie podobieństwo skrótów.
MIT: 3DS zawsze oznacza dodatkowy krok i utratę konwersji.
FAKT: Protokół EMV 3DS 2.x zaprojektowano wokół ścieżki frictionless: wydawca uwierzytelnia klienta na podstawie danych o transakcji i urządzeniu, a challenge pojawia się tylko przy podwyższonym ryzyku lub wymogu regulacyjnym.
MIT: Uwierzytelnienie 3DS gwarantuje, że transakcja nie jest oszustwem.
FAKT: 3DS potwierdza tożsamość posiadacza karty i co do zasady przenosi odpowiedzialność za fraud na wydawcę, ale nie zastępuje autoryzacji ani systemów antyfraudowych – pozostaje jedną z warstw ochrony.
MIT: Do świadczenia usług 3DS wystarczy aprobata EMVCo.
FAKT: Aprobata EMVCo dotyczy produktu. Operator potrzebuje dodatkowo certyfikacji środowiska według PCI 3DS oraz rejestracji i testów w programach sieci płatniczych.
MIT: 3DS Server to program instalowany w sklepie internetowym.
FAKT: 3DS Server to certyfikowany system klasy serwerowej, zwykle operowany przez bramkę, acquirera lub wyspecjalizowanego dostawcę dla wielu merchantów; sklep integruje się z nim przez API.
FAQ
Czy 3D Secure jest obowiązkowy?
W Europejskim Obszarze Gospodarczym silne uwierzytelnienie klienta (SCA) wymaga PSD2, a EMV 3DS jest podstawowym protokołem jego realizacji dla płatności kartą – z wyjątkami przewidzianymi w standardach technicznych (m.in. transakcje niskokwotowe, analiza ryzyka). Poza EOG o wymogach decydują zasady sieci płatniczych i lokalne regulacje.
Czym różni się ścieżka frictionless od challenge?
Frictionless to uwierzytelnienie w tle: ACS ocenia ryzyko na danych z komunikatu AReq i zwraca wynik bez udziału klienta. Challenge to dodatkowe potwierdzenie tożsamości – np. biometria w aplikacji banku lub kod jednorazowy – stosowane przy podwyższonym ryzyku lub wymogu regulacyjnym.
Kto operuje Directory Server?
Sieci płatnicze – każda utrzymuje własny DS dla swoich zakresów kart w ramach swojego programu 3DS. 3DS Serwery i ACS łączą się z DS na podstawie certyfikatów wydawanych w tych programach. Merchant ani bank nie komunikują się z DS bezpośrednio – robią to ich certyfikowane komponenty.
Czym jest liability shift w 3DS?
To przeniesienie odpowiedzialności finansowej za fraud typu „nieautoryzowana transakcja” ze sklepu na wydawcę karty po poprawnym uwierzytelnieniu 3DS. Szczegółowe warunki (typy transakcji, wyjątki, regiony) określają zasady poszczególnych organizacji płatniczych, dlatego warto weryfikować je u swojego acquirera.
Jaka jest aktualna wersja EMV 3DS?
EMV 3DS 2.3.1.1 (2023), która zastąpiła wydanie 2.3.1.0 z 2022 r. i dodała m.in. usprawnienia uwierzytelniania out-of-band oraz wsparcie Secure Payment Confirmation. Dla wymogów SCA w PSD2 EMVCo rekomenduje stosowanie wersji 2.2 lub wyższych.
Czym jest PCI 3DS i kogo dotyczy?
PCI 3DS Core Security Standard v1.0 to standard bezpieczeństwa środowisk, w których działają komponenty ACS, DS i 3DS Server. Obejmuje część bazową i wymogi specyficzne dla 3DS (m.in. ochronę kluczy protokołu w HSM). Dotyczy podmiotów wykonujących lub wspierających te funkcje – nie zwykłych merchantów.
Jak Patronusec pomaga dostawcom usług 3DS?
Wspieramy ścieżkę środowiskową: wyznaczamy granice środowiska 3DE, prowadzimy analizę luk względem PCI 3DS (część bazowa i wymogi 3DS), planujemy remediację i przygotowujemy organizację do oceny. Po bezpłatnej rozmowie scope-assessment przedstawiamy stałą wycenę dopasowaną do roli (ACS, DS lub 3DS Server).
Warto przeczytać
Ścieżka lektury dla tematu uwierzytelniania płatności:
- Karta, BLIK, BNPL, raty czy przelew – porównanie 5 metod płatności w e-commerce – kontekst: gdzie 3DS mieści się wśród metod płatności.
- Agentic payments od Visa – bezpieczeństwo transakcji inicjowanych przez AI – przyszłość uwierzytelniania, gdy kupującym jest agent.
- Zakres certyfikacji PCI DSS – od czego zacząć i jak go określić – jak środowisko 3DS sąsiaduje z zakresem PCI DSS.
3D Secure i PCI 3DS – bezpłatna konsultacja
Patronusec jako akredytowany QSA wspiera dostawców komponentów ACS, DS i 3DS Server w certyfikacji PCI 3DS. Jeśli rozważasz świadczenie usług 3DS, umów bezpłatną rozmowę scope-assessment.
