PSD3 a PSR: co musí obchodníci skutečně změnit

Podle PSD2 byla pravidla chování v běžném provozu — načasování refundací, odpovědnost za podvod, řešení stížností — stanovena směrnicí. Směrnice se neuplatňují přímo. Každý z 27 členských států musel PSD2 transponovat do svého vlastního národního práva, a každý to udělal s vlastním časováním, vlastními mezerami a vlastním lokálním výkladem. Obchodník působící v pěti zemích EU tak v praxi fungoval podle pěti mírně odlišných sad pravidel, přestože všechny tvrdily, že implementují "tutéž" směrnici.

Nový balíček rozděluje práci jinak. PSD3 zůstává směrnicí a zabývá se především licencováním, dohledem a přístupem na trh pro platební instituce — tedy věcmi, které ovlivňují regulatorní status vašeho PSP, ne váš checkout. Pravidla chování, která se skutečně týkají obchodníků — odpovědnost za podvod, povinnosti při refundacích, požadavky na autentizaci, řešení stížností — se přesouvají do PSR, nařízení. Nařízení se uplatňují přímo a stejně ve všech členských státech, bez kroku národní transpozice a bez prostoru pro lokální redakční odchylky.

Podle právních analýz dohodnutých textů je to záměrná reakce na problém fragmentace, který PSD2 vytvořila — PSR má obchodníkům a PSP dát jedno jednotné pravidlo místo 27 lokálních variant (přehled dohodnutých textů od Freshfields). Pro obchodníky to znamená, že kontrola shody, kterou provádíte pro svou německou entitu, by po nabytí použitelnosti PSR měla dát stejné odpovědi jako kontrola pro vaši irskou nebo portugalskou entitu. To je skutečné zjednodušení, ale zároveň to znamená, že už nebude fungovat argument "místní regulátor to řeší benevolentně".

Pravidla odpovědnosti podle PSD2 byla postavena na poměrně úzké představě "neautorizované" transakce — tedy takové, kterou zákazník neschválil. Podvody se od té doby posunuly dál. Podvody typu social engineering, kdy se pachatel vydává za bankovního zaměstnance nebo přesvědčí zákazníka, aby přímo autorizoval převod, technicky vytvářejí podle staré úpravy "autorizovanou" transakci, což historicky zákazníkovi (a v důsledku i obchodníkovi, který se na danou platbu spoléhá) dávalo méně možností nápravy.

PSR rozšiřuje odpovědnost v několika směrech, které se obchodníků týkají:

• Podvody založené na spoofingu — kdy se pachatel vydává za zaměstnance nebo značku PSP — přesouvají větší část odpovědnosti na poskytovatele platebních služeb, místo aby ztrátu nesl zákazník.
• Neposkytnutí nebo nesprávné uplatnění silné autentizace klienta (SCA) zakládá odpovědnost té straně v řetězci, která ji neuplatnila správně, což se týká i acquirerů a v některých flows i obchodníků, kteří autentizaci obcházejí.
• Pomalé zpracování hlášení podvodu ze strany PSP může samo o sobě zakládat odpovědnost, což má banky a PSP motivovat k rychlejšímu vyřizování hlášení podvodů, místo aby každý nárok byl řešen jako zdlouhavé šetření.

Pro obchodníka je praktickým důsledkem to, že spory o podvod se budou stále více odvíjet od důkazů o tom, co se stalo během autentizace, nikoli jen od toho, zda zákazník tvrdí, že platbu neautorizoval. To znamená, že vaše logy autentizace a data o výsledcích SCA se stávají součástí důkazů ve sporu, ne jen záznamem shody, který si vedete a pak na něj zapomenete.

Jedna z nejkonkrétnějších změn pro checkout flow se týká ověřování, zda jméno na účtu skutečně odpovídá tomu, komu si plátce myslí, že peníze posílá. To navazuje na mechanismus ověření příjemce (Verification of Payee, VoP), který je již vyžadován pro okamžité úhrady podle nařízení EU o okamžitých platbách, a nový platební balíček tuto logiku dále rozšiřuje na další platební služby.

V praxi VoP znamená, že banka plátce před dokončením převodu ověří jméno majitele účtu proti IBAN a případný nesoulad — "žádná shoda" nebo "částečná shoda" — nahlásí plátci před potvrzením platby. To cílí přímo na podvody typu autorizovaná push platba, kdy je zákazník oklamán, aby poslal peníze na účet, který nepatří tomu, komu si myslí.

Pro obchodníky se to dotýká jakéhokoli flow, kde zákazník zahajuje bankovní převod, aby vám zaplatil — platebních metod typu account-to-account, plateb iniciovaných přes otevřené bankovnictví, nebo jakéhokoli kroku checkoutu, kde zobrazujete vlastní údaje příjemce, aby je zákazník použil k dokončení převodu:

• Právní název registrovaný na vašem obchodním bankovním účtu musí přesně odpovídat obchodnímu názvu, který zákazníci vidí na vaší stránce checkoutu, jinak zákazníci začnou vídat varování o nesouladu, která vypadají jako signál podvodu, i když je vše v pořádku.
• Pokud podnikáte pod obchodním názvem odlišným od názvu vaší právní entity, je čas buď je sladit, nebo zajistit, aby váš checkout jasně vysvětlil rozdíl ještě dřív, než zákazník uprostřed platby narazí na varování VoP.
• Jakoukoli interní dokumentaci, která pro účely rekonciliace uvádí údaje o vašem zúčtovacím účtu, je třeba porovnat s tím, co je skutečně registrováno u vaší banky, protože zastaralý záznam se každému zákazníkovi používajícímu metodu založenou na převodu projeví jako nesoulad.

Jde o případ, kdy pětiminutová administrativní kontrola — ověření, že registrované jméno na vašem bankovním účtu odpovídá brandingu vašeho obchodu — předejde vlně zmatku na straně zákazníků, jakmile budou kontroly typu VoP plošně v platnosti.

PSD2 dávala bankám vedoucím účty dvě možnosti, jak zpřístupnit údaje o účtu třetím stranám: vyhrazené API, nebo záložní rozhraní postavené na jejich stávajících obrazovkách internetového bankovnictví pro klienty. V praxi byla záložní rozhraní často pomalejší, méně spolehlivá a nekonzistentně udržovaná, což dělalo checkout flows založené na otevřeném bankovnictví — možnosti platby přes bankovní účet, informace o účtu pro rizikové skórování a podobné funkce — méně spolehlivými než platby kartou.

Nový rámec toto zpřísňuje. Banky budou čelit jasnějším, lépe vymahatelným povinnostem ohledně výkonu vyhrazeného rozhraní — blíže parity se spolehlivostí jejich vlastních klientských kanálů, s definovanými očekáváními ohledně dostupnosti a odezvy, místo volně vymahatelného standardu "přiměřeného úsilí", který charakterizoval části implementace PSD2 (analýza vývoje PSD3/PSR od MoFo).

Pro obchodníky, kteří nabízejí nebo zvažují platby přes bankovní účet nebo jiné možnosti checkoutu typu account-to-account, to má dva praktické dopady:

• Méně neúspěšných nebo vypršelých pokusů o autorizaci by mělo znamenat méně opuštěných košíků u platebních metod založených na převodu, které historicky měly nižší úspěšnost dokončení oproti kartám částečně právě kvůli spolehlivosti rozhraní.
• Pokud se pro riziková rozhodnutí spoléháte na služby informací o účtu — ověřování vlastnictví účtu nebo kontrolu zůstatku před odesláním objednávek vysoké hodnoty — tyto datové toky by měly být konzistentnější a lépe se na nich stavějí workflows, místo toho, abyste kolem nich musely budovat logiku opakovaných pokusů a záložního zpracování.

Nic z toho neruší potřebu testovat vaši integraci proti reálnému chování banky, jakmile pravidla vstoupí v platnost. Znamená to ale, že by se měla zlepšit výchozí spolehlivost, kterou testujete.

Toto je část, která se ve většině právních shrnutí vynechává. Tady je to, co se pohne na vaší straně stolu.

Vaše smlouvy s PSP a acquirerem. Prověřte klauzule o rozdělení odpovědnosti ve svých stávajících smlouvách o platebních službách. Ve smlouvách z éry PSD2 často vycházela formulace odpovědnosti ze staré, užší definice "neautorizované transakce" a starých pravidel výjimek ze SCA. Jakmile se uplatní ustanovení o odpovědnosti podle PSR, smlouvy, které nebyly aktualizovány, mohou odkazovat na standardy, jež už neodpovídají zákonu, což vytváří nejasnost přesně ve chvíli, kdy potřebujete jasno — uprostřed sporu. Zeptejte se svého PSP přímo, zda budou jejich standardní obchodní podmínky aktualizovány tak, aby odrážely rozdělení odpovědnosti podle PSR, a získejte odpověď písemně, ne jen předpoklad, že je to vyřešeno.

• Váš checkout flow. Tři konkrétní změny ke kontrole:
• Ověřte, že právní název navázaný na váš zúčtovací účet odpovídá brandingu vašeho obchodu, aby se předešlo zbytečným varováním o nesouladu VoP u platebních metod založených na převodu.
• Zajistěte, aby vaše flow výzvy SCA (3DS nebo ekvivalent) degradovalo elegantně — zákazník, který opustí nákup, protože krok autentizace technicky selhal, ne proto, že by ho odmítl, je přesně scénář, na který nová pravidla odpovědnosti cílí, a nechcete být na nesprávné straně, když se spor bude posuzovat.
• Pokud nabízíte platby přes bankovní účet nebo jiné možnosti account-to-account, plánujte znovu testovat míry dokončení, jakmile vstoupí v platnost nové povinnosti ohledně výkonu API — předpoklady o spolehlivosti, na kterých je postavena vaše záložní logika, už možná nebudou omezujícím faktorem.

• Váš proces řešení sporů. Důkazy, které rozhodují spor o podvod nebo chargeback, se posouvají. Zatímco spory z éry PSD2 se často odvíjely od toho, zda byla SCA vůbec uplatněna, spory z éry PSR se budou častěji odvíjet od toho, jak byla uplatněna, zda proběhla kontrola VoP a jaký výsledek vrátila, a jak rychle bylo hlášení podvodu escalováno. To znamená:
• Váš support tým potřebuje při reakci na spor přístup k logům výsledků autentizace, nejen ke stavu transakce.
• Vaše dokumentace pro předkládání důkazů by měla být aktualizována tak, aby jako standardní pole obsahovala výsledky shody/neshody VoP, jakmile tato data existují ve vašich transakčních záznamech.
• Interní SLA pro escalaci podezření na podvod směrem k vašemu PSP by se měly zpřísnit, protože zpoždění se samo stává faktorem odpovědnosti, ne neutrálním administrativním krokem.

Přechod z PSD2 na PSR se netýká tolik nových povinností, které se objevují odnikud, jako spíš uzavírání stávajících mezer.

Obchodníci, kteří odpovědnost za podvod, SCA a důkazy ve sporech řešili podle zásady "jak to řekne místní banka", zjistí, že tato odpověď už neplatí, jakmile se ve všech členských státech uplatní stejný text nařízení. Tato práce je administrativní — aktualizace smluv, textů checkoutu a šablon důkazů — ale musí proběhnout před obecnou použitelností, ne poté, co mezeru odhalí první spor podle nových pravidel.

Nic z toho nevyžaduje přestavbu vašeho checkoutu na jinou platformu. Vyžaduje to, abyste ke smlouvě s PSP, registrovaným údajům o účtu a šablonám důkazů ve sporech přistupovali jako k živým dokumentům, které potřebují kontrolu podle konkrétního harmonogramu — a to je smysl checklistu níže.

Přesné datum obecné použitelnosti závisí na tom, kdy Úřední věstník zveřejní finální text, ale posloupnost je pevná. Berte to jako pracovní harmonogram, ne fixní termín, a jednotlivá data ověřte, jakmile bude zveřejnění v Úředním věstníku potvrzeno.

• Do 4. čtvrtletí 2026 — očekává se zveřejnění v Úředním věstníku (červen–červenec 2026). Po zveřejnění vypočítejte své pevné datum obecné použitelnosti 21 měsíců poté a zapište si ho do svého compliance kalendáře. Kontrolu smluv s PSP začněte hned, ne až u termínu.
• Během roku 2027 — ověřte plán svého PSP na aktualizaci obchodních podmínek tak, aby odrážely rozdělení odpovědnosti podle PSR. Zkontrolujte registrovaný právní název svého zúčtovacího účtu proti brandingu vašeho checkoutu. Zmapujte, které z vašich checkout flows používají SCA, a zdokumentujte aktuální logiku výjimek, abyste ji mohli porovnat s finálními požadavky PSR.
• Začátek roku 2028 — otestujte celý proces důkazů ve sporech od začátku do konce: dokáže váš support tým na požádání skutečně získat výsledek SCA a data shody VoP pro danou transakci, nebo to vyžaduje ticket pro vývojáře? Tuto mezeru vyřešte dřív, než ji prověří živý spor.
• Při obecné použitelnosti (odhad březen–duben 2028) — potvrďte, že aktualizované smlouvy s PSP jsou podepsané, texty checkoutu odrážejí veškeré požadavky na jméno příjemce a vaše dokumentace sporů obsahuje nová pole důkazů. Berte datum obecné použitelnosti jako bod, ke kterému by vše výše uvedené už mělo běžet, ne jako bod, kdy s tím začínáte.

Cost+ funguje na cenách IC++ (Interchange Plus Plus) přesně proto, že věříme, že obchodníci dělají lepší rozhodnutí, když jsou jednotlivé složky platby — interchange, scheme fee a naše marže — viditelné, ne slité do jednoho čísla. Stejný princip platí i pro regulatorní změny: čím dřív vidíte, co se skutečně posouvá v odpovědnosti a požadavcích na důkazy, tím méně rušivý bude přechod. Pokud chcete probrat, jak vaše aktuální nastavení checkoutu a řešení sporů odpovídá harmonogramu PSR, kontaktujte náš tým, nebo si při revizi smluv porovnejte aktuální strukturu poplatků se zveřejněnými nízkorizikovými cenami na našem webu.