PSD3 i PSR: co tak naprawdę muszą zmienić sprzedawcy

W ramach PSD2 codzienne zasady postępowania — terminy zwrotów, odpowiedzialność za oszustwa, obsługa reklamacji — były ustalane przez dyrektywę. Dyrektywy nie są stosowane bezpośrednio. Każde z 27 państw członkowskich musiało transponować PSD2 do swojego prawa krajowego, każde robiło to według własnego harmonogramu, z własnymi lukami i własną lokalną interpretacją. Sprzedawca działający w pięciu krajach UE de facto funkcjonował według pięciu nieco różnych zestawów zasad, mimo że wszystkie miały wdrażać „tę samą" dyrektywę.

Nowy pakiet dzieli tę pracę inaczej. PSD3 pozostaje dyrektywą i obejmuje głównie licencjonowanie, nadzór oraz dostęp do rynku dla instytucji płatniczych — to, co wpływa na status regulacyjny Twojego PSP, a nie na Twój checkout. Zasady postępowania, które faktycznie dotyczą sprzedawców — odpowiedzialność za oszustwa, obowiązki zwrotu, wymogi uwierzytelniania, obsługa reklamacji — przechodzą do PSR, czyli rozporządzenia. Rozporządzenia są stosowane bezpośrednio i identycznie w każdym państwie członkowskim, bez etapu transpozycji krajowej i bez miejsca na lokalne osobliwości legislacyjne.

Według analiz prawnych uzgodnionych tekstów jest to celowa odpowiedź na problem fragmentacji, który stworzyła PSD2 — PSR ma dać sprzedawcom i PSP jeden jednolity zbiór zasad, a nie 27 lokalnych wariantów (przegląd uzgodnionych tekstów przez Freshfields). Dla sprzedawców oznacza to, że przegląd zgodności przeprowadzany dla niemieckiego podmiotu powinien, po wejściu w życie PSR, dawać takie same odpowiedzi jak przegląd dla podmiotu irlandzkiego czy portugalskiego. To realne uproszczenie, ale oznacza też, że nie będzie już argumentu „lokalny regulator jest w tej sprawie łagodny", na który można się powołać.

Zasady odpowiedzialności w PSD2 zbudowano wokół dość wąskiej definicji transakcji „nieautoryzowanej" — takiej, na którą klient nie wyraził zgody. Oszustwa poszły dalej od tego czasu. Oszustwa metodą inżynierii społecznej, gdzie przestępca podaje się za pracownika banku lub przekonuje klienta do bezpośredniej autoryzacji przelewu, technicznie skutkują transakcją „autoryzowaną" w rozumieniu starych ram prawnych, co historycznie pozostawiało klienta (a w konsekwencji także sprzedawcę, który liczył na tę płatność) z mniejszymi możliwościami odwołania.

PSR rozszerza odpowiedzialność w kilku kierunkach istotnych dla sprzedawców:

• Oszustwa oparte na spoofingu — gdy przestępca podaje się za pracownika lub markę PSP — przenoszą większą odpowiedzialność na dostawców usług płatniczych, a nie tylko na klienta, który musi pokryć stratę.
• Niezastosowanie lub nieprawidłowe zastosowanie silnego uwierzytelnienia klienta (SCA) obarcza odpowiedzialnością tę stronę w łańcuchu, która nie zastosowała go prawidłowo, co obejmuje acquirerów, a w niektórych przepływach także sprzedawców, którzy obchodzą uwierzytelnienie.
• Wolne przetwarzanie zgłoszeń o oszustwie przez PSP może samo w sobie generować odpowiedzialność, co ma zmusić banki i PSP do szybszego reagowania na zgłoszenia, a nie traktowania każdej reklamacji jako długotrwałego dochodzenia.

Dla sprzedawcy praktyczny efekt jest taki, że spory dotyczące oszustw będą w coraz większym stopniu rozstrzygane na podstawie dowodów przebiegu uwierzytelnienia, a nie tylko oświadczenia klienta, że nie autoryzował płatności. To sprawia, że logi uwierzytelnienia i dane wyników SCA stają się częścią dowodów w sporze, a nie tylko zapisem zgodności, który przechowujesz i o którym zapominasz.

Jedną z najbardziej konkretnych zmian dla przebiegu checkoutu jest weryfikacja tego, czy nazwa przypisana do konta faktycznie odpowiada temu, komu płatnik sądzi, że wysyła pieniądze. Bazuje to na mechanizmie weryfikacji odbiorcy (Verification of Payee, VoP), już wymaganym dla natychmiastowych przelewów kredytowych na mocy unijnego rozporządzenia o płatnościach natychmiastowych, a nowy pakiet płatniczy rozszerza tę logikę na kolejne usługi płatnicze.

W praktyce VoP oznacza, że bank płatnika sprawdza nazwę posiadacza konta względem numeru IBAN przed zakończeniem przelewu i zgłasza niezgodność — „brak zgodności" lub „częściowa zgodność" — płatnikowi przed potwierdzeniem płatności. Jest to wymierzone bezpośrednio w oszustwa typu autoryzowany przelew push (APP fraud), gdzie klienta oszukuje się, by przelał pieniądze na konto, które nie jest tym, za które je uważa.

Dla sprzedawców dotyczy to każdego przepływu, w którym klient inicjuje przelew bankowy jako płatność — metody płatności typu konto-do-konta, płatności inicjowane przez open banking lub każdy etap checkoutu, gdzie wyświetlasz swoje dane odbiorcy, aby klient mógł dokończyć przelew:

• Nazwa prawna zarejestrowana na Twoim koncie bankowym sprzedawcy musi dokładnie odpowiadać nazwie handlowej widocznej dla klientów na Twojej stronie płatności, w przeciwnym razie klienci zaczną widzieć ostrzeżenia o niezgodności, które wyglądają jak sygnały oszustwa, mimo że nic złego się nie dzieje.
• Jeśli działasz pod nazwą handlową różną od nazwy podmiotu prawnego, teraz jest czas, aby je zestandaryzować albo jasno wyjaśnić tę różnicę na checkoucie, zanim klient natrafi na ostrzeżenie VoP w trakcie płatności.
• Każda wewnętrzna dokumentacja zawierająca dane Twojego konta rozliczeniowego do celów uzgadniania powinna być porównana z tym, co faktycznie jest zarejestrowane w Twoim banku, ponieważ nieaktualny zapis pojawi się jako niezgodność u każdego klienta korzystającego z metody opartej na przelewie.

To przypadek, w którym pięciominutowa kontrola administracyjna — potwierdzenie, że zarejestrowana nazwa Twojego konta bankowego zgadza się z brandingiem sklepu — pozwala uniknąć fali zamieszania u klientów, gdy kontrole w stylu VoP zaczną obowiązywać powszechnie.

PSD2 dawała bankom prowadzącym rachunki dwie opcje udostępniania danych rachunku podmiotom trzecim: dedykowane API albo interfejs zastępczy zbudowany na ich istniejących ekranach bankowości internetowej dla klientów. W praktyce interfejsy zastępcze bywały wolniejsze, mniej wiarygodne i niekonsekwentnie utrzymywane, co czyniło przepływy checkoutu oparte na open banking — opcje pay-by-bank, informacje o rachunku do oceny ryzyka i podobne funkcje — mniej pewnymi niż płatności kartą.

Nowe ramy zaostrzają to. Banki będą podlegać jasniejszym, bardziej wymuszalnym obowiązkom dotyczącym wydajności dedykowanego interfejsu — bliżej parytetu z wiarygodnością ich własnych kanałów dla klientów, z określonymi oczekiwaniami co do czasu dostępności i czasu odpowiedzi, a nie luźno wymuszanym standardem „rozsądnego wysiłku", który charakteryzował część wdrożenia PSD2 (analiza rozwoju PSD3/PSR przez MoFo).

Dla sprzedawców, którzy oferują lub rozważają opcje checkoutu pay-by-bank albo inne opcje konto-do-konta, ma to znaczenie w dwóch aspektach:

• Mniej nieudanych lub przekroczonych czasowo prób autoryzacji powinno oznaczać mniej opuszczonych koszyków przy metodach płatności oparte na przelewach, które historycznie osiągały słabsze wyniki niż karty pod względem wskaźnika finalizacji, częściowo z powodu niewiarygodności interfejsu.
• Jeśli korzystasz z usług informacji o rachunku do decyzji dotyczących ryzyka — weryfikacji własności konta lub sprawdzania sald przed wysyłką zamówień o wysokiej wartości — te przepływy danych powinny stać się bardziej konsekwentne, aby można było na nich budować procesy, a nie tworzyć logikę powtórzeń i obsługi błędów.

Nic z tego nie usuwa potrzeby przetestowania integracji względem rzeczywistego zachowania banku, gdy nowe przepisy zaczną obowiązywać. Oznacza to jednak, że bazowa wiarygodność, względem której testujesz, powinna się poprawić.

To jest ta część, która jest pomijana w większości podsumowań prawnych. Oto co zmienia się po Twojej stronie biurka.

Umowy z PSP i acquirerem. Przejrzyj klauzule dotyczące alokacji odpowiedzialności w istniejących umowach o usługi płatnicze. W umowach z ery PSD2 sformułowania dotyczące odpowiedzialności często zakładały starą, węższą definicję „transakcji nieautoryzowanej" i stare zasady wyjątków SCA. Gdy zaczną obowiązywać przepisy PSR dotyczące odpowiedzialności, umowy, które nie zostały zaktualizowane, mogą odwoływać się do standardów, które już nie odpowiadają prawu, co tworzy niejasność właśnie wtedy, gdy potrzebujesz jasności — w trakcie sporu. Zapytaj swojego PSP bezpośrednio, czy standardowe warunki dla sprzedawców zostaną zaktualizowane, aby odzwierciedlały alokację odpowiedzialności zgodną z PSR, i uzyskaj odpowiedź na piśmie, a nie zakładaj, że sprawa jest już rozwiązana.

• Twój przebieg checkoutu. Trzy konkretne zmiany do sprawdzenia:
• Potwierdź, że nazwa prawna przypisana do Twojego konta rozliczeniowego zgadza się z brandingiem Twojego sklepu, aby uniknąć niepotrzebnych ostrzeżeń o niezgodności VoP przy metodach płatności opartych na przelewie.
• Upewnij się, że Twój przepływ wyzwania SCA (3DS lub odpowiednik) degraduje się w kontrolowany sposób — klient, który rezygnuje z zakupu, ponieważ etap uwierzytelnienia technicznie zawiódł, a nie ponieważ sam go odrzucił, to właśnie scenariusz, który nowe przepisy o odpowiedzialności mają wychwytywać, i nie chcesz być po niewłaściwej stronie tego przy rozpatrywaniu sporu.
• Jeśli oferujesz pay-by-bank lub inne opcje konto-do-konta, zaplanuj ponowne testowanie wskaźników finalizacji, gdy nowe obowiązki dotyczące wydajności API zaczną obowiązywać — założenia o wiarygodności, na których zbudowałeś swoją logikę zastępczą, mogą już nie być wiążącym ograniczeniem.

• Twój proces reklamacyjny. Dowody rozstrzygające spór dotyczący oszustwa lub chargebacku się zmieniają. Tam, gdzie spory z ery PSD2 często zależały od tego, czy SCA zostało w ogóle zastosowane, spory z ery PSR będą częściej zależeć od tego, jak zostało zastosowane, czy przeprowadzono kontrolę VoP i jaki dała wynik oraz jak szybko zgłoszenie oszustwa zostało zeskalowane. To oznacza, że:
• Twój zespół wsparcia potrzebuje dostępu do logów wyników uwierzytelnienia, a nie tylko statusu transakcji, przy odpowiadaniu na spór.
• Dokumentacja dotycząca składania dowodów powinna zostać zaktualizowana, aby zawierać wyniki zgodności/niezgodności VoP jako standardowe pole, gdy takie dane znajdą się już w Twoich rekordach transakcji.
• Wewnętrzne SLA dotyczące eskalowania podejrzanych zgłoszeń oszustw do PSP powinny się zaostrzyć, ponieważ zwłoka sama staje się czynnikiem odpowiedzialności, a nie neutralnym krokiem administracyjnym.

Przejście od PSD2 do PSR to w mniejszym stopniu pojawienie się nowych obowiązków z niczego, a w większym zamknięcie istniejących luk.

Sprzedawcy, którzy traktowali odpowiedzialność za oszustwa, SCA i dowody w sporach jako „to, co powie lokalny bank", odkryją, że ta odpowiedź już nie wystarcza, gdy ten sam tekst rozporządzenia zaczyna obowiązywać w każdym państwie członkowskim. Praca ma charakter administracyjny — aktualizacja umów, treści checkoutu i szablonów dowodowych — ale musi nastąpić przed ogólnym zastosowaniem, nie po tym, jak pierwszy spór na nowych zasadach ujawni tę lukę.

Nic z tego nie wymaga przebudowy platformy checkoutu. Wymaga jedynie traktowania umowy z PSP, zarejestrowanych danych konta i szablonów dowodowych do sporów jako żywych dokumentów, które wymagają przeglądu w określonym harmonogramie — na tym właśnie polega poniższa lista kontrolna.

Dokładna data ogólnego zastosowania zależy od tego, kiedy Dziennik Urzędowy opublikuje tekst ostateczny, ale sekwencja jest ustalona. Traktuj to jako roboczy harmonogram, a nie sztywny termin, i potwierdź daty po potwierdzeniu publikacji w Dzienniku Urzędowym.

• Do IV kwartału 2026 roku — oczekiwana jest publikacja w Dzienniku Urzędowym (czerwiec–lipiec 2026). Po publikacji oblicz swoją ostateczną datę ogólnego zastosowania (21 miesięcy później) i wpisz ją w swój kalendarz zgodności. Zacznij przegląd umowy z PSP już teraz, a nie czekaj na termin.
• W trakcie 2027 roku — Potwierdź plan swojego PSP dotyczący aktualizacji warunków dla sprzedawców, aby odzwierciedlały alokację odpowiedzialności zgodną z PSR. Sprawdź, czy zarejestrowana nazwa prawna Twojego konta rozliczeniowego zgadza się z brandingiem checkoutu. Zmapuj, które z Twoich przepływów checkoutu korzystają z SCA, i udokumentuj obecną logikę wyjątków, aby móc ją porównać z finalnymi wymogami PSR.
• Początek 2028 roku — Przetestuj cały proces dowodowy w sporach: czy Twój zespół wsparcia może faktycznie na żądanie pobrać wynik SCA i dane zgodności VoP dla transakcji, czy wymaga to zgłoszenia do zespołu technicznego? Napraw tę lukę, zanim zostanie sprawdzona przez rzeczywisty spór.
• W dacie ogólnego zastosowania (szacowana marzec–kwiecień 2028) — Potwierdź, że zaktualizowane umowy z PSP są podpisane, treści checkoutu odzwierciedlają wszelkie wymogi dotyczące nazwy odbiorcy, a Twoja dokumentacja dowodowa zawiera nowe pola dowodowe. Traktuj datę ogólnego zastosowania jako moment, w którym wszystko powyższe powinno już działać, a nie moment, w którym zaczynasz.

Cost+ działa na cenniku IC++ (Interchange Plus Plus) właśnie dlatego, że wierzymy, że sprzedawcy podejmują lepsze decyzje, gdy składniki płatności — interchange, scheme fee i nasza marża — są widoczne, a nie zbiorczo ukryte. Ta sama zasada dotyczy zmian regulacyjnych: im wcześniej widzisz, co faktycznie zmienia się w wymogach dotyczących odpowiedzialności i dowodów, tym mniej zakłócające jest przejście. Jeśli chcesz przedyskutować, jak Twoja obecna konfiguracja checkoutu i procesu reklamacyjnego wypada na tle harmonogramu PSR, skontaktuj się z naszym zespołem lub sprawdź swoją obecną strukturę opłat względem opublikowanego cennika dla niskiego ryzyka na naszej stronie, w trakcie przeglądu umów.