PSD3 és PSR: mit kell tényleg megváltoztatniuk a kereskedőknek

A PSD2 alatt a napi szintű magatartási szabályokat — visszatérítési határidők, csalási felelősség, panaszkezelés — egy irányelv szabta meg. Az irányelvek nem alkalmazandók közvetlenül. A 27 tagállam mindegyikének át kellett vennie a PSD2-t a saját nemzeti jogába, és ezt mindegyik a saját ütemezésével, saját hiányosságaival és saját helyi értelmezésével tette meg. Az az öt EU-országban működő kereskedő valójában öt kissé eltérő szabálykönyv szerint működött, még ha mindegyik ország azt is állította, hogy „ugyanazt” az irányelvet ülteti át.

Az új paketta másképp osztja fel a feladatokat. A PSD3 irányelv marad, és elsősorban a pénzforgalmi intézmények engedélyezését, felügyeletét és piacra jutását szabályozza — ez inkább a PSP-je szabályozói státuszát érinti, nem a checkoutot. A kereskedőket valóban érintő magatartási szabályok — csalási felelősség, visszatérítési kötelezettségek, hitelesítési követelmények, panaszkezelés — a PSR-be, egy rendeletbe kerülnek. A rendeletek közvetlenül és azonos módon alkalmazandók minden tagállamban, nemzeti átvételi lépés és helyi szövegezési eltérések nélkül.

Az elfogadott szövegek jogi elemzése szerint ez tudatos válasz a PSD2 által kialakított töredezettségi problémára — a PSR célja, hogy a kereskedők és a PSP-k egységes szabálykönyvet kapjanak 27 helyi variáns helyett (a Freshfields áttekintése az elfogadott szövegekről). A kereskedők számára ez azt jelenti, hogy a német leányvállalatra vonatkozó megfelelőségi ellenőrzésnek — miután a PSR alkalmazandóvá válik — ugyanazokra a válaszokra kell jutnia, mint az ír vagy portugál leányvállalatra vonatkozó ellenőrzésnek. Ez valódi egyszerűsítés, de azt is jelenti, hogy nincs többé olyan argumentum, hogy „a helyi felügyelet ebben engedékeny”.

A PSD2 felelősségi szabályai egy meglehetősen szűk „jogosulatlan” tranzakció-fogalomra épültek — olyanra, amelyet az ügyfél nem hagyott jóvá. A csalás azóta továbbfejlődött. A social engineering típusú csalásoknál, amikor egy csaló banki alkalmazottnak adja ki magát, vagy meggyőzi az ügyfelet, hogy közvetlenül jóváhagyjon egy átutalást, a régi keretrendszer szerint technikailag „jogosult” tranzakció keletkezik, ami korábban kevesebb jogorvoslatot hagyott az ügyfélnek (és ezáltal az adott fizetésre hagyatkozó kereskedőnek).

A PSR néhány, a kereskedők számára fontos irányban terjeszti ki a felelősséget:

• A megszemélyesítésen alapuló csalás — amikor a csaló egy PSP munkatársának vagy márkájának adja ki magát — nagyobb felelősséget hárít a pénzforgalmi szolgáltatókra, nem hagyva magára az ügyfelet a veszteséggel.
• Az erős ügyfél-hitelesítés (SCA) felajánlásának elmulasztása vagy hibás alkalmazása azt a felet terheli felelősséggel a láncban, amelyik nem alkalmazta megfelelően — ez magában foglalja az acquirer-eket, és bizonyos folyamatokban a hitelesítést megkerülő kereskedőket is.
• A csalásbejelentések lassú kezelése egy PSP részéről önmagában is felelősséget teremthet, amelynek célja, hogy a bankokat és a PSP-ket gyorsabb csalásbejelentés-kezelésre ösztönözze, ne kezeljék minden panaszt hosszas vizsgálatként.

A kereskedő számára a gyakorlati hatás az, hogy a csalási viták egyre inkább a hitelesítés során történtek bizonyítékain dőlnek el, nem csak azon, hogy az ügyfél azt állítja, nem hagyta jóvá a fizetést. Ez azt jelenti, hogy a hitelesítési naplói és az SCA-eredmény adatai a vitabizonyítékok részévé válnak, nem csak egy megfelelőségi nyilvántartás, amit elraktároz és elfelejt.

Az egyik legkonkrétabb változás a checkout folyamatokra vonatkozóan az, hogy ellenőrizni kell, hogy egy számlához tartozó név valóban megegyezik-e azzal, akinek a fizető fél gondolja, hogy pénzt küld. Ez a Kedvezményezett-ellenőrzés (Verification of Payee, VoP) mechanizmusra épül, amely már az azonnali átutalások esetében kötelező az EU Azonnali Átutalásokról szóló rendelete alapján, és az új fizetési szabályozási paketta ezt a logikát tovább terjeszti a fizetési szolgáltatásokra.

A gyakorlatban a VoP azt jelenti, hogy a fizető fél bankja a tranzakció befejeződése előtt ellenőrzi a számlatulajdonos nevét az IBAN-hoz képest, és eltérés esetén — „nincs egyezés” vagy „közeli egyezés” — jelzést küld a fizető félnek a fizetés megerősítése előtt. Ez kifejezetten a jóváhagyott átutalási csalás (authorized push payment fraud) ellen irányul, amikor egy ügyfelet becsapva egy olyan számlára utaltatnak pénzt, amely nem az, akinek gondolja.

A kereskedők számára ez minden olyan folyamatot érint, amelyben az ügyfél maga indít bankátutalást a fizetéshez — számláról számlára történő fizetési módok, nyílt bankolás alapú fizetések, vagy bármilyen checkout lépés, amelyben megjeleníti a saját kedvezményezetti adatait, hogy az ügyfél be tudja fejezni az átutalást:

• A kereskedői bankszámlájához bejegyzett jogi névnek pontosan egyeznie kell a checkout felületen az ügyfelek által látott kereskedelmi névvel, különben az ügyfelek olyan eltérési figyelmeztetéseket fognak látni, amelyek csalásjelzésnek tűnnek, még akkor is, ha semmi baj nincs.
• Ha a jogi entitása nevétől eltérő kereskedelmi név alatt működik, most van itt az ideje, hogy vagy összehangolja ezeket, vagy gondoskodjon arról, hogy a checkout világosan elmagyarázza az eltérést, mielőtt az ügyfél VoP-figyelmeztetésbe ütközne a fizetés közben.
• Minden belső dokumentációt, amely az elszámolási számlaadatokat tartalmazza egyeztetési célokra, ellenőrizni kell azzal, amit a bankjánál valójában bejegyeztek, mert egy elavult adat minden átutalás-alapú fizetési módot használó ügyfélnél eltérésként fog megjelenni.

Ez egy olyan eset, amikor egy ötperces adminisztratív ellenőrzés — annak megerősítése, hogy a bankszámlájához bejegyzett név megegyezik a webáruháza márkanevével — elkerülhet egy hullámnyi ügyfélzavart, amint a VoP-típusú ellenőrzések széles körben életbe lépnek.

A PSD2 két lehetőséget adott a számlavezető bankoknak a számlaadatok harmadik felek felé történő megnyitására: egy dedikált API-t, vagy egy meglévő, ügyfélszolgálati online banki felületre épülő tartalék interfészt (fallback interface). A gyakorlatban a tartalék interfészek gyakran lassabbak, kevésbé megbízhatóak és következetlenül fenntartottak voltak, ami a nyílt bankolás alapú checkout folyamatokat — bankon keresztüli fizetési opciók, kockázatbecsléshez használt számlainformációk és hasonló funkciók — kevésbé megbízhatóvá tette a kártyás fizetéseknél.

Az új keretrendszer ezt szigorítja. A bankokra egyértelműbb, jobban érvényesíthető kötelezettségek vonatkoznak a dedikált interfészek teljesítményével kapcsolatban — közelebb kerülve a saját ügyfélszolgálati csatornáik megbízhatóságához, meghatározott üzemidő- és válaszidő-elvárásokkal, nem pedig a lazán érvényesített „megfelelő erőfeszítés” szabvánnyal, amely a PSD2 megvalósításának egyes részeit jellemezte (a MoFo elemzése a PSD3/PSR fejleményeiről).

Azon kereskedők számára, akik bankon keresztüli fizetést (pay-by-bank) vagy más számláról-számlára típusú checkout opciókat kínálnak vagy terveznek, ez két szempontból lényeges:

• Kevesebb sikertelen vagy időtúllépéssel megszakadt jóváhagyási kísérlet kevesebb elhagyott kosarat jelenthet az átutalás-alapú fizetési módoknál, amelyek korábban részben az interfész megbízhatósága miatt teljesítettek rosszabbul a befejezési arányban, mint a kártyák.
• Ha kockázati döntésekhez számlainformációs szolgáltatásokat használ — a számlatulajdon ellenőrzésére vagy egyenlegellenőrzésre nagy értékű megrendelések szállítása előtt —, ezek az adatfolyamok konzisztensebbé válhatnak, amelyekre munkafolyamatokat lehet építeni, helyette annak, hogy újrapróbálkozási logikát és tartalékkezelést kelljen köréjük építeni.

Ez semmiképp nem szünteti meg annak szükségességét, hogy a szabályok életbe lépése után teszteljen az integrációját a valódi banki működéssel szemben. Azt azonban jelenti, hogy az alapmegbízhatóság, amivel szemben tesztel, javulni fog.

Ez az a rész, amit a legtöbb jogi összefoglaló kihagy. Íme, mi mozdul meg az Ön oldalán.

A PSP- és acquirer-szerződések. Vizsgálja át a meglévő pénzforgalmi szolgáltatási szerződéseiben a felelősség-elosztási záradékokat. A PSD2-korszakból származó szerződésekben a felelősségi megfogalmazás gyakran a „jogosulatlan tranzakció” régi, szűkebb definícióját és a régi SCA-mentességi szabályokat feltételezte. Amint a PSR felelősségi rendelkezései alkalmazandóvá válnak, a nem frissített szerződések olyan szabványokra hivatkozhatnak, amelyek már nem egyeznek a jogszabállyal — ez pontosan akkor okoz bizonytalanságot, amikor a legnagyobb szüksége van a tisztaságra: egy vita közben. Kérdezze meg közvetlenül a PSP-jét, hogy a standard kereskedői feltételeik frissülnek-e a PSR felelősség-elosztásának megfelelően, és kérjen írásos választ, ne feltételezze, hogy ez már kezelve van.

• A checkout folyamat. Három konkrét dolgot érdemes ellenőrizni:
• Erősítse meg, hogy az elszámolási számlájához tartozó jogi név megegyezik a webáruháza márkanevével, hogy elkerülje a szükségtelen VoP-eltérési figyelmeztetéseket az átutalás-alapú fizetési módoknál.
• Győződjön meg arról, hogy az SCA-hitelesítési folyamata (3DS vagy azzal egyenértékű megoldás) fokozatosan és megfelelően kezeli a hibákat — ha egy ügyfél a vásárlást azért hagyja abba, mert egy hitelesítési lépés technikailag meghibásodott, nem pedig azért, mert elutasította azt, ez pontosan az a forgatókönyv, amelyet az új felelősségi szabályok célba vesznek, és nem szeretné a rossz oldalon állni, amikor egy vitát felülvizsgálnak.
• Ha bankon keresztüli fizetést vagy más számláról-számlára típusú opciókat kínál, tervezze meg a befejezési arányok újrateszteszelését, amint az új API-teljesítményi kötelezettségek életbe lépnek — a megbízhatósági feltételezések, amelyekre a tartalék-logikáját építette, már nem feltétlenül a szűk keresztmetszetet jelentik.

• A vitakezelési folyamat. A csalási vagy chargeback-vita kimenetét meghatározó bizonyíték típusa változik. Ahol a PSD2-korszak vitái gyakran azon dőltek el, hogy az SCA-t egyáltalán alkalmazták-e, a PSR-korszak vitái egyre inkább azon fognak eldőlni, hogy hogyan alkalmazták, lefutott-e egy VoP-ellenőrzés és milyen eredményt adott, és milyen gyorsan escaláltak egy csalásbejelentést. Ez azt jelenti:
• Az ügyfélszolgálati csapatnak hozzáférnie kell a hitelesítési eredménynaplókhoz, nem csak a tranzakciós státuszhoz, amikor válaszol egy vitára.
• A bizonyítékbenyújtási dokumentációját frissíteni kell, hogy a VoP egyezés/nem-egyezés eredményeket standard mezőként tartalmazza, amint ez az adat megjelenik a tranzakciós nyilvántartásaiban.
• A gyanús csalásbejelentések PSP-hez történő escalálására vonatkozó belső SLA-kat szigorítani kell, mivel a késés önmagában felelősségi tényezővé válik, nem pedig egy semleges adminisztratív lépés.

A PSD2-ről a PSR-re való átállás kevésbé arról szól, hogy a semmiből új kötelezettségek jelennek meg, inkább arról, hogy a meglévő hiányosságok záródnak be.

Azok a kereskedők, akik a csalási felelősséget, az SCA-t és a vitabizonyítékokat úgy kezelték, mint „amit a helyi bank éppen mond”, azt fogják tapasztalni, hogy ez a válasz nem tartja tovább magát, amint ugyanaz a rendeletszöveg minden tagállamban alkalmazandóvá válik. A feladat adminisztratív — szerződések, checkout-szövegek és bizonyíték-sablonok frissítése —, de ezt az általános alkalmazás előtt kell megtenni, nem azután, hogy az első, az új szabályok szerinti vita felfedi a hiányosságot.

Ehhez semmi sem igényli a checkout teljes újraépítését. Azt igényli, hogy a PSP-szerződését, a bejegyzett számlaadatait és a vitabizonyíték-sablonjait élő dokumentumként kezelje, amelyeknek konkrét ütemezés szerinti felülvizsgálatra van szükségük — ez az alábbi checklist célja.

A pontos általános alkalmazási dátum attól függ, mikor jelenik meg a végleges szöveg az Európai Unió Hivatalos Lapjában, de a sorrend rögzített. Kezelje ezt inkább munkaütemtervként, mint fix határidőként, és erősítse meg a dátumokat, amint a Hivatalos Lapban a közzétételt megerősítik.

• 2026 negyedik negyedévéig — A Hivatalos Lap közzétételét várhatóan 2026 június–júliusában teszik meg. A közzététel után számolja ki a saját, pontos 21 hónapos általános alkalmazási dátumát, és jelölje be a megfelelőségi naptárában. A PSP-szerződések felülvizsgálatát már most kezdje el, ne várja meg a határidőt.
• 2027 folyamán — Erősítse meg a PSP-je tervét a kereskedői feltételek frissítésére a PSR felelősség-elosztásának megfelelően. Auditálja az elszámolási számlájához bejegyzett jogi nevet a checkout márkanevéhez képest. Térjen fel, mely checkout folyamataiban használ SCA-t, és dokumentálja a jelenlegi mentességi logikát, hogy összevethesse a végleges PSR-követelményekkel.
• 2028 elején — Tesztelje végig a vitabizonyítási folyamatát: az ügyfélszolgálati csapata valóban le tudja kérni egy tranzakcióhoz az SCA-eredményt és a VoP-egyezési adatot igény esetén, vagy ehhez fejlesztői jegy szükséges? Javítsa ki ezt a hiányosságot, mielőtt egy valós vita tesztelné.
• Az általános alkalmazásnál (becsült 2028 március–április) — Erősítse meg, hogy a frissített PSP-szerződéseket aláírták, a checkout szövege tükrözi a kedvezményezett-név követelményeket, és a vitakezelési dokumentációja tartalmazza az új bizonyítási mezőket. Az általános alkalmazás dátumát ne induló pontnak, hanem olyan időpontnak tekintse, amikorra mindennek fentiek közül már működnie kell.

A Cost+ éppen azért működik IC++ (Interchange Plus Plus) árazás alapján, mert úgy gondoljuk, hogy a kereskedők jobb döntéseket hoznak, ha egy fizetés összetevői — interchange, scheme fee és a mi árrésünk — láthatók, nem pedig összekeverve jelennek meg. Ugyanez az elv érvényes a szabályozási változásokra is: minél korábban látja, mi változik valójában a felelősségi és bizonyítási követelményekben, annál kevésbé lesz zavaró az átállás. Ha szeretné átbeszélni, hogyan illeszkedik a jelenlegi checkout- és vitakezelési beállítása a PSR ütemtervéhez, vegye fel a kapcsolatot csapatunkkal, vagy — amíg a szerződéseket felülvizsgálja — ellenőrizze a jelenlegi díjstruktúráját a weboldalunkon közzétett alacsony kockázatú árazáshoz képest.