Regulacja z obszaru usług płatniczych potrafi zadecydować o sukcesie lub porażce sklepu internetowego. Zmiany wprowadzone przez PSD2 i związane z nią silne uwierzytelnianie płatnika to nie tylko dodatkowe zabezpieczenia transakcji, lecz również nowe oczekiwania wobec dostawców płatności, banków i samych sprzedawców. Poniższy tekst porządkuje pojęcia, tłumaczy wpływ SCA na proces zakupowy, a także wskazuje praktyczne kierunki wdrożeń, które pozwalają zwiększyć bezpieczeństwo i nie tracić przy tym cennej konwersja.
Podstawy: czym jest PSD2 i czym naprawdę jest SCA
Dyrektywa o usługach płatniczych w wersji drugiej to zestaw zasad regulujących rynek płatności elektronicznych w Unii Europejskiej i EOG. Jej cele są trojakie: zwiększyć bezpieczeństwo, wpuścić do gry innowacyjnych graczy (tzw. TPP – podmioty trzecie) i ułatwić rozwój handlu cyfrowego. W praktyce PSD2 zobowiązała banki do udostępnienia interfejsów API dla podmiotów świadczących inicjowanie płatności oraz usługi dostępu do informacji o rachunku. Z punktu widzenia e-commerce kluczowe jest jednak to, że PSD2 wymaga silnego uwierzytelnianie klienta przy większości transakcji elektronicznych.
Silne uwierzytelnianie (ang. Strong Customer Authentication – SCA) opiera się na użyciu co najmniej dwóch kategorii elementów: wiedzy (coś, co zna tylko użytkownik, np. hasło lub PIN), posiadania (coś, co ma użytkownik, np. telefon z aplikacją banku, token sprzętowy) oraz cechy osobiste (coś, czym użytkownik jest, np. odcisk palca, rozpoznanie twarzy). Elementy te muszą być niezależne, by naruszenie jednego nie obniżało skuteczności pozostałych. SCA obejmuje również tzw. dynamic linking – mechanizm powiązania konkretnej kwoty i konkretnego odbiorcy z procesem autoryzacji, tak aby nie można było „przemycić” innego przelewu lub innego numeru akceptanta bez wiedzy płatnika.
Wymóg SCA dotyczy przede wszystkim transakcji inicjowanych przez płatnika (customer-initiated). Oznacza to, że gdy klient sklepu płaci kartą, przelewem pay-by-bank, portfelem powiązanym z kartą lub inną metodą, najczęściej dojdzie do weryfikacji tożsamości w trybie dwu- lub trzyelementowym. Istnieją jednak wyjątki i obszary wyłączone (out of scope), jak np. płatności telefoniczne/mailowe (MOTO) czy tzw. MIT – merchant initiated transactions, inicjowane przez akceptanta bez udziału klienta, np. rozliczenie subskrypcji po wcześniejszej zgodzie.
Warto też rozróżniać obowiązki na linii bank (ASPSP), dostawca usług płatniczych i sprzedawca. Banki są odpowiedzialne za wdrożenie SCA po swojej stronie i określają metody weryfikacji (aplikacje mobilne, hasła SMS, tokeny). Sprzedawca z kolei musi zapewnić, że integracja z procesorem płatności wspiera przekazywanie niezbędnych danych do oceny ryzyka i że logika obsługi wyjątków nie psuje doświadczenia użytkownika.
Co zmienia PSD2 w procesie płatności online
Najbardziej widoczna zmiana w kartowych płatnościach internetowych to ewolucja protokołu 3D Secure. Wersja 3DS2 wprowadziła bogatszą wymianę danych kontekstowych, lepszą obsługę urządzeń mobilnych i możliwość tzw. frictionless flow, czyli akceptacji płatności bez wyświetlania wyzwania (challenge) klientowi, jeśli ryzyko transakcji jest niskie. Z kolei gdy ocena jest niepewna lub wysoka, dochodzi do step-up – pojawia się żądanie potwierdzenia w aplikacji banku, kodem lub biometrycznie.
Aby frictionless był w ogóle możliwy, sprzedawcy i PSP muszą przekazywać do systemów emitentów bogaty zestaw pól: szczegóły urządzenia, adres do wysyłki, historię konta, dane o wcześniejszych transakcjach, wynik filtrów antyfraudowych. To właśnie te elementy, w połączeniu z polityką banku, przesądzają, czy dojdzie do cichej autoryzacji, czy też klient zobaczy dodatkowy ekran potwierdzenia.
PSD2 i regulacyjne standardy techniczne (RTS) przewidują szereg wyjątków od SCA. Najczęściej wykorzystywane w e-commerce to: transakcje niskokwotowe (z limitem jednostkowym i kumulacyjnym), ocena niskiego ryzyka po stronie dostawcy płatności (TRA – Transaction Risk Analysis), biali zaufani odbiorcy (white-listing w banku), a także subskrypcje o stałej kwocie po dokonaniu silnego uwierzytelnienia przy pierwszym obciążeniu. Są również płatności pozostające poza zakresem, m.in. MOTO czy MIT, w których płatnik nie jest obecny w chwili obciążenia.
Wprowadzenie wyjątków nie oznacza swobody ich dowolnego stosowania. Każda prośba o zwolnienie musi przejść walidację po stronie emitenta. Jeśli bank uzna, że powinno nastąpić SCA, odpowie miękką odmową (soft decline) i płatność trzeba ponowić z uwzględnieniem uwierzytelnienia. Dla sklepów i integratorów oznacza to konieczność obsługi wielu ścieżek reakcji na odrzucenia oraz przejrzyste komunikaty do klienta, które wyjaśniają, dlaczego pojawia się dodatkowy krok.
Osobnym wątkiem jest odpowiedzialność za obciążenia zwrotne. W przypadku poprawnie przeprowadzonego 3D Secure następuje zwykle przesunięcie odpowiedzialności (liability shift) na stronę banku wydawcy karty. Nie zwalnia to jednak akceptanta z dbałości o sygnały ryzyka i politykę zwrotów, bo spór z klientem może dotyczyć nie tylko nieautoryzowanej transakcji, ale także jakości towaru, terminu dostawy czy zgodności z opisem.
Wpływ SCA na doświadczenie klienta i konwersję
Każdy dodatkowy krok w procesie zakupowym to potencjalny punkt tarcia, a zasada ta działa niezależnie od segmentu. SCA jest jednak na tyle elastyczne, że dobrze wdrożone potrafi łączyć efektywną ochronę z wysokim poziomem wygody. Najlepszym przykładem jest biometria na smartfonach: potwierdzenie transakcji odciskiem palca czy rozpoznaniem twarzy trwa sekundy i jest przez klientów uznawane za naturalne. Kluczem jest spójność: jeśli klient często wraca do tego samego sklepu i korzysta z tej samej metody płatności, powinien widzieć przewidywalny, krótki przebieg autoryzacji.
Dane z rynków, które najwcześniej wdrożyły SCA, pokazują, że trafna gra wyjątkami (TRA, low-value, trusted beneficiaries) podnosi udział transakcji akceptowanych bez wyzwania. Równie ważna jest jakość danych przekazywanych do emitenta: kompletne informacje o urządzeniu, historii klienta i jego wzorcach zakupowych zmniejszają niepewność po stronie systemów decyzyjnych. W efekcie rośnie odsetek przepuszczonych płatności bez prośby o potwierdzenie, a to przekłada się na lepszą konwersja.
Współpraca z dostawcą płatności powinna uwzględniać projektowanie przepływów dla różnych kanałów: przeglądarka w desktopie, mobilna przeglądarka, aplikacja natywna. Z perspektywy UX krytyczne jest „mostkowanie” użytkownika pomiędzy środowiskami – np. przekierowanie do banku w trybie in-app, zamiast otwierania nowego okna przeglądarki. Warto też skracać do minimum momenty niepewności: czytelny komunikat, progres bar, automatyczne powroty z banku oraz jawna informacja, co zrobić w razie problemów z potwierdzeniem.
Ostatni element to praca z błędami. Sklepy powinny wdrożyć logikę rozpoznającą miękkie odmowy i powtórzenia transakcji z inną ścieżką autoryzacja. Użytkownik, który wróci do koszyka po nieudanym potwierdzeniu, nie może stracić wprowadzonych danych, rabatów ani zawartości. Pomaga także wielometodowość – szybkie przełączenie na alternatywną formę płatności może uratować sprzedaż.
Scenariusze płatności stosowane po PSD2
Płatności kartowe pozostają trzonem e‑commerce, ale realizacja po PSD2 niemal zawsze przechodzi przez 3D Secure. W praktyce poprawny flow wymaga przekazania do bramek i wydawców kilkudziesięciu pól opisujących kontekst. Dobrze skonfigurowany procesor zastosuje frictionless tam, gdzie ryzyko jest niskie, a w razie potrzeby wyświetli wyzwanie do zatwierdzenia w banku. Dzięki temu odpowiedzialność za nieautoryzowane obciążenia zwykle przenosi się na emitenta, a rola akceptanta skupia się na dostarczeniu jakościowych danych i dobrym UX.
Szybko rośnie popularność płatności rachunek‑do‑rachunku inicjowanych przez podmioty trzecie (open banking). Dla sklepu to atrakcyjna alternatywa w sytuacjach, gdy chce ominąć koszty interchange lub uprościć zwroty. Taka płatność wymaga SCA po stronie banku, ale przebiega w trybie natywnym – klient zatwierdza przelew w swojej aplikacji bankowej, a sprzedawca od razu otrzymuje potwierdzenie inicjacji.
Portfele cyfrowe i rozwiązania bigtechów łączą w sobie zalety kart i wygody SCA. Przykładowo, gdy użytkownik płaci portfelem opartym na karcie, uwierzytelnienie może dziać się po stronie urządzenia (biometria), a tokenizacja redukuje ekspozycję danych wrażliwych. Dodatkowo niektóre portfele wspierają delegowane uwierzytelnianie, co oznacza, że to sprzedawca lub dostawca portfela przeprowadza SCA zgodnie z wymogami banku.
Subskrypcje w modelu powtarzalnym mają kilka wariantów: stała kwota i harmonogram, zmienna kwota, lub zmienny harmonogram. Po PSD2 pierwsze obciążenie zazwyczaj wymaga silnego uwierzytelnienia, a kolejne – jeśli spełniają kryteria MIT – są poza zakresem SCA. Kluczem jest poprawne zebranie i przechowywanie zgody, jasna komunikacja cykliczności i wyświetlanie informacji o zbliżających się obciążeniach. Dobrą praktyką jest też umożliwienie klientowi prostego zarządzania zgodą i metodą płatności w panelu konta.
Istnieją też mniej typowe scenariusze: płatności odroczone (BNPL) z elementem oceny kredytowej, linki do płatności wysyłane e-mailem, czy prośby o dopłaty za wysyłkę. Każdy z nich powinien być przeanalizowany pod kątem tego, kto i kiedy inicjuje transakcję, jaki jest kanał komunikacji i czy wymagane jest SCA. Wspólnym mianownikiem pozostaje rzetelne udokumentowanie zgody i ograniczanie okazji do socjotechniki.
Obowiązki sprzedawców i integratorów
Po stronie sklepu główna zmiana polega na zarządzaniu większą liczbą stanów procesu płatniczego. Trzeba rozumieć kody odpowiedzi i reagować na nie różnymi ścieżkami: inny jest retry po soft decline, inny po odrzuceniu z powodu ryzyka, a jeszcze inny po błędzie technicznym ACS banku. Tę logikę należy opisać i przetestować nie tylko na środowiskach testowych dostawcy płatności, lecz także w realistycznych warunkach produkcyjnych, uwzględniając różne urządzenia i przeglądarki.
Bardzo ważne jest przekazywanie kompletnych danych do oceny ryzyka. W e-commerce często zaniedbywane pozostają pola dotyczące konta klienta (wiek konta, liczba poprzednich zamówień, data ostatniej zmiany hasła), dokładne dane adresowe czy identyfikatory urządzeń. Brak tych informacji zmniejsza szansę na frictionless i zwiększa liczbę wyzwań, co przekłada się na spadki konwersji.
Sklep powinien także ustalić strategię korzystania z wyjątków: kiedy prosić o TRA, jak traktować transakcje o niskiej wartości, czy i jak zachęcać klientów do dodawania sprzedawcy do listy zaufanych odbiorców w banku. Nie jest to „ustaw i zapomnij” – polityka powinna być korygowana w oparciu o dane o skuteczności akceptacji, wskaźniki zwrotów i profil fraudowy.
W obszarze prawnym i procesowym trzeba m.in. zaktualizować regulaminy (sposób i częstotliwość obciążeń cyklicznych), zadbać o przejrzystość komunikacji zgód i politykę przechowywania danych zgodną z RODO. Warto również mieć plan ciągłości działania na wypadek awarii komponentów SCA – np. gdy wybrany bank ma problem z autoryzacją mobilną, należy automatycznie oferować alternatywę lub podpowiadać opóźnione ponowienie płatności.
Bezpieczeństwo, ryzyko i nowe wektory ataków
SCA znacząco utrudniło klasyczne nadużycia oparte na kradzieży samych danych karty. Jednak pejzaż zagrożeń ewoluował. Coraz większym wyzwaniem jest przejęcie konta (ATO) – atakujący nie tylko zna dane logowania, ale przechwytuje również drugi czynnik, np. dzięki SIM‑swap lub zainfekowanemu urządzeniu. Wzrosło też znaczenie socjotechniki: przestępcy podszywają się pod kurierów, dostawców płatności czy banki, wyłudzając kody jednorazowe i prośby o zatwierdzenie w aplikacji.
Warto inwestować w ochronę punktów styku: detekcję anomalii logowania, reputację urządzeń, analizę behawioralną i listy zaufanych urządzeń. Dostawcy płatności oferują dziś mechanizmy RBA (risk‑based authentication), ale to sprzedawca dostarcza wiele sygnałów kontekstowych: tempo wpisywania danych, nietypowe zmiany w adresie dostawy, rozbieżności językowe. Tam, gdzie to możliwe, miejmy włączoną tokenizację i nie przechowujmy surowych danych karty.
Inny obszar to spory transakcyjne i nadużycia przyjazne (tzw. friendly fraud) – klient twierdzi, że nie rozpoznał obciążenia lub że nie otrzymał towaru, choć transakcja była autoryzowana. SCA utrudnia podważanie autentyczności, ale nie eliminuje sporów. Dlatego dokumentacja całego cyklu (zamówienie, wysyłka, potwierdzenia e-mail, komunikacja z klientem) pozostaje krytyczna. Z kolei śledzenie wskaźnika chargeback i jego przyczyn pozwala zidentyfikować problemy operacyjne, zanim przerodzą się w ograniczenia narzucane przez schematy kartowe.
Ostatnim wątkiem jest edukacja. Nawet najlepsza technologia zawiedzie, gdy użytkownik zostanie zmanipulowany do potwierdzenia oszukańczej płatności. Warto więc budować jasne komunikaty na stronie checkoutu, informować o tym, jak wygląda prawdziwe potwierdzenie w banku i czego nigdy nie wolno podawać konsultantowi. Krótkie przypomnienia na krytycznych etapach potrafią zmniejszyć ryzyko nawet o kilkanaście procent.
Praktyczne wdrożenie: kroki, które działają
Wdrożenie po PSD2 to projekt wielowątkowy. Największe sukcesy odnoszą zespoły, które łączą kompetencje techniczne, produktowe i analityczne. Zaczyna się od audytu: jakie metody płatności są dostępne, jak wyglądają ścieżki w kanałach, jakie są wskaźniki akceptacji, ile czasu zajmuje klienckie potwierdzenie i na jakich etapach pojawiają się rezygnacje. Kolejny krok to wybór lub weryfikacja partnera płatniczego – czy wspiera najnowsze wersje protokołów, czy ma SDK dla aplikacji mobilnych, jak wygląda obsługa wyjątków i retry.
- Mapowanie ścieżek płatności: desktop, mobile web, aplikacja, call center (MOTO), linki do płatności.
- Konfiguracja 3DS: kompletne pola danych, obsługa frictionless, strategie wyjątku TRA i low‑value.
- Integracja mobilna: SDK 3DS w aplikacji, deep linki do banków, zamknięta pętla powrotu.
- Obsługa błędów: rozróżnianie soft decline, twardych odrzuceń, timeoutów i powtarzanie w odpowiedniej ścieżce.
- Komunikacja: proste instrukcje na ekranach potwierdzenia, wsparcie dla najczęstszych banków i metod.
- Monitorowanie: dashboardy z akceptacją, udziałem frictionless, czasem do autoryzacji, odsetkiem porzuceń.
- Zgodność i dowody: przechowywanie logów SCA, zgód MIT, audyty bezpieczeństwa i testy penetracyjne.
- Plan B: scenariusze awaryjne na wypadek niedostępności SCA w wybranych bankach lub metodach.
Po uruchomieniu przychodzi czas na optymalizację. Tu sprawdzają się eksperymenty A/B: różne sposoby prezentacji kroków, moment pobierania adresu e-mail, informowanie o możliwym wyzwaniu, czytelność przycisków i tekstów pomocy. Warto też współpracować z PSP przy tzw. smart routing – kierowaniu transakcji do tych bram i ścieżek, które statystycznie mają wyższą akceptację w danym banku lub regionie.
Ważnym tematem jest rozliczanie i obsługa posprzedażowa. Jeśli sklep pracuje w modelu subskrypcyjnym, powinien posiadać przejrzysty kalendarz obciążeń, z wyprzedzającymi powiadomieniami o zbliżającej się płatności, oraz prostą drogę zmiany karty czy rezygnacji. Z kolei w tradycyjnym modelu zamówieniowym liczy się szybkość zwrotów i proaktywna komunikacja przy opóźnieniach – to zmniejsza eskalację do sporów i poprawia relacje z bankami wydawcami, które widzą mniej kwestionowanych obciążeń.
Przyszłość: PSD3/PSR, delegowane uwierzytelnianie i nowe możliwości
Na horyzoncie widać kolejne zmiany regulacyjne: projekt PSD3 i rozporządzenia o usługach płatniczych (PSR) ma doprecyzować ramy odpowiedzialności i wzmocnić egzekwowanie otwartej bankowości. Możemy spodziewać się większego nacisku na jakość interfejsów bankowych, szybszych czasów reakcji i bardziej konsekwentnego wdrażania wyjątków. Dla sklepów oznacza to potencjalnie płynniejsze płatności rachunek‑do‑rachunku i rosnącą konkurencję w obszarze inicjowania płatności.
Po stronie kart rozwój standardu EMV 3DS (np. 2.3.1) poprawia obsługę środowisk mobilnych i urządzeń IoT, a także wspiera bogatsze dane kontekstowe. Coraz dojrzalsze staje się delegowane uwierzytelnianie: merchant albo portfel przeprowadza SCA w imieniu emitenta zgodnie z zatwierdzonymi zasadami. To skraca ścieżkę i pozwala budować rozpoznawalne, zaufane flow w ramach marki sklepu, przy zachowaniu pełnej zgodności regulacyjnej.
Coraz istotniejsza staje się także tokenizacja sieciowa i odświeżanie tokenów w tle. Z perspektywy klienta oznacza to mniej niespodziewanych odrzuceń z powodu wygaśnięcia karty, a dla sklepu – stabilniejsze wskaźniki akceptacji. W połączeniu z dobrze zaprojektowanym SCA i mechanizmami oceny ryzyka daje to wypadkową w postaci szybszej ścieżki płatności i niższej ekspozycji na nadużycia.
W obszarze otwartej bankowości dynamicznie rozwijają się płatności zmienne (VRP) oraz modele autoryzacji oparte na z góry udzielonej zgodzie na zakres i częstotliwość. To szansa dla subskrypcji i płatności cyklicznych poza środowiskiem kart, gdzie koszty bywają niższe, a przepływy bardziej przewidywalne. Warunkiem sukcesu jest jednak szeroka adopcja po stronie banków i spójna, intuicyjna bankowa ścieżka SCA dla klienta końcowego.
Na przecięciu regulacji i technologii pojawia się europejski portfel tożsamości cyfrowej (eIDAS 2.0). Jeżeli banki i akceptanci nauczą się wykorzystywać silną weryfikację tożsamości w sposób przyjazny dla UX, część dzisiejszych wąskich gardeł może zniknąć. To także szansa na jeszcze lepsze powiązanie procesu płatności z minimalizacją ryzyka nadużyć przy zachowaniu zgodności z zasadą minimalizacji danych.
Najbardziej pragmatyczna rekomendacja dla sklepów pozostaje niezmienna: mierzyć, uczyć się i iterować. Zarówno SCA, jak i 3DS wciąż ewoluują, a różnice między bankami potrafią być znaczące. Stała współpraca z PSP, testy z klientami, monitorowanie akceptacji na poziomie BIN‑ów oraz szybkie reagowanie na zmiany po stronie emitentów będą najlepszym zabezpieczeniem biznesu, który sprzedaje w wielu krajach i obsługuje różnorodne metody płatności.
601 162 666