PSD3 und PSR: Was Händler wirklich ändern müssen

Unter PSD2 wurden die Alltagsregeln zum Verhalten – Rückerstattungsfristen, Betrugshaftung, Beschwerdebearbeitung – durch eine Richtlinie festgelegt. Richtlinien gelten nicht unmittelbar. Jeder der 27 Mitgliedstaaten musste PSD2 in nationales Recht umsetzen, und jeder tat dies mit eigenem Zeitplan, eigenen Lücken und eigener lokaler Auslegung. Ein Händler, der in fünf EU-Ländern aktiv war, agierte de facto unter fünf leicht unterschiedlichen Regelwerken, auch wenn alle vorgaben, "dieselbe" Richtlinie umzusetzen.

Das neue Paket teilt die Arbeit anders auf. PSD3 bleibt eine Richtlinie und deckt hauptsächlich Zulassung, Aufsicht und Marktzugang für Zahlungsinstitute ab – das betrifft eher den regulatorischen Status Ihres PSP als Ihren Checkout. Die Verhaltensregeln, die Händler tatsächlich betreffen – Betrugshaftung, Rückerstattungspflichten, Authentifizierungsanforderungen, Beschwerdebearbeitung – wandern in die PSR, eine Verordnung. Verordnungen gelten unmittelbar und identisch in jedem Mitgliedstaat, ohne nationalen Umsetzungsschritt und ohne Raum für lokale Eigenheiten bei der Ausarbeitung.

Laut juristischer Analyse der vereinbarten Texte ist dies eine bewusste Reaktion auf das Fragmentierungsproblem, das PSD2 geschaffen hat – die PSR soll Händlern und PSPs ein einheitliches Regelwerk geben statt 27 lokaler Varianten (Freshfields' Überblick zu den vereinbarten Texten). Für Händler bedeutet das: Die Compliance-Prüfung, die Sie für Ihre deutsche Gesellschaft durchführen, sollte, sobald die PSR gilt, dieselben Ergebnisse liefern wie die Prüfung für Ihre irische oder portugiesische Gesellschaft. Das ist eine echte Vereinfachung, bedeutet aber auch, dass es kein "der lokale Regulator sieht das locker" mehr als Ausweg gibt.

Die Haftungsregeln der PSD2 basierten auf einer recht engen Vorstellung einer "nicht autorisierten" Transaktion – einer, die der Kunde nicht genehmigt hat. Betrug hat sich seither weiterentwickelt. Social-Engineering-Betrug, bei dem sich ein Betrüger als Bankmitarbeiter ausgibt oder einen Kunden dazu bringt, eine Überweisung direkt zu autorisieren, erzeugt technisch eine "autorisierte" Transaktion nach dem alten Rahmenwerk – was dem Kunden (und in der Folge dem Händler, der auf diese Zahlung vertraut) historisch weniger Rückgriffsmöglichkeiten ließ.

Die PSR erweitert die Haftung in einigen für Händler relevanten Richtungen:

• Spoofing-basierter Betrug – bei dem sich ein Betrüger als Mitarbeiter oder Marke eines PSP ausgibt – verschiebt mehr Haftung auf die Zahlungsdienstleister, statt den Kunden den Verlust tragen zu lassen.
• Versäumnisse, Strong Customer Authentication (SCA) anzubieten oder korrekt anzuwenden, legen die Haftung auf die Partei in der Kette, die sie nicht ordnungsgemäß angewendet hat – dazu zählen Acquirer und, in manchen Abläufen, Händler, die die Authentifizierung umgehen.
• Langsame Bearbeitung von Betrugsmeldungen durch einen PSP kann selbst eine Haftung begründen, was Banken und PSPs zu schnellerer Bearbeitung von Betrugsmeldungen bewegen soll, statt jede Meldung als langwierige Untersuchung zu behandeln.

Für einen Händler bedeutet das praktisch: Betrugsstreitfälle werden zunehmend auf Nachweise dazu, was während der Authentifizierung passiert ist, hinauslaufen – nicht nur darauf, ob der Kunde behauptet, die Zahlung nicht autorisiert zu haben. Damit werden Ihre Authentifizierungsprotokolle und SCA-Ergebnisdaten Teil Ihrer Streitfall-Beweismittel, nicht nur ein Compliance-Datensatz, den Sie ablegen und vergessen.

Eine der konkretesten Änderungen für Checkout-Flows betrifft die Überprüfung, ob der Name auf einem Konto tatsächlich mit dem übereinstimmt, an wen der Zahler zu senden glaubt. Dies baut auf dem Verification-of-Payee-Mechanismus (VoP) auf, der bereits für Sofortüberweisungen nach der EU-Verordnung über Sofortzahlungen vorgeschrieben ist, und das neue Zahlungspaket erweitert diese Logik auf weitere Zahlungsdienste.

In der Praxis bedeutet VoP, dass die Bank des Zahlers den Namen des Kontoinhabers gegen die IBAN prüft, bevor eine Überweisung abgeschlossen wird, und eine Abweichung – "keine Übereinstimmung" oder "teilweise Übereinstimmung" – dem Zahler meldet, bevor er die Zahlung bestätigt. Das zielt gezielt auf Betrug mit autorisierten Überweisungen ab, bei dem ein Kunde dazu verleitet wird, Geld an ein Konto zu überweisen, das nicht dem entspricht, was er denkt.

Für Händler betrifft das jeden Ablauf, bei dem ein Kunde eine Banküberweisung an Sie initiiert – kontobasierte Zahlungsmethoden, über Open Banking initiierte Zahlungen oder jeden Checkout-Schritt, bei dem Sie Ihre eigenen Zahlungsempfängerdaten anzeigen, damit ein Kunde eine Überweisung ausführt:

• Der auf Ihrem Geschäftskonto registrierte rechtliche Name muss exakt mit dem Handelsnamen übereinstimmen, den Kunden auf Ihrer Checkout-Seite sehen, sonst sehen Kunden Warnungen über Abweichungen, die wie Betrugssignale wirken, auch wenn alles in Ordnung ist.
• Wenn Sie unter einem Handelsnamen agieren, der von Ihrem rechtlichen Firmennamen abweicht, ist jetzt der richtige Zeitpunkt, beide anzugleichen oder in Ihrem Checkout klar zu erklären, worin die Abweichung besteht, bevor ein Kunde mitten in der Zahlung auf eine VoP-Warnung stößt.
• Jede interne Dokumentation, die Ihre Auszahlungskontodaten für Abgleichszwecke aufführt, sollte mit dem tatsächlich bei Ihrer Bank registrierten Namen verglichen werden, denn ein veralteter Eintrag zeigt sich als Abweichung bei jedem Kunden, der eine überweisungsbasierte Methode nutzt.

Das ist ein Fall, in dem eine fünfminütige Verwaltungsprüfung – ob der registrierte Name Ihres Bankkontos mit Ihrem Shop-Branding übereinstimmt – eine Welle von Verwirrung bei Kunden verhindert, sobald VoP-ähnliche Prüfungen flächendeckend gelten.

PSD2 gab kontoführenden Banken zwei Optionen, um Kontodaten für Drittanbieter bereitzustellen: eine dedizierte API oder eine Fallback-Schnittstelle, die auf ihren bestehenden kundenseitigen Online-Banking-Bildschirmen aufbaut. In der Praxis waren Fallback-Schnittstellen oft langsamer, weniger zuverlässig und inkonsistent gepflegt, was Open-Banking-basierte Checkout-Flows – Pay-by-Bank-Optionen, Kontoinformationen für das Risikoscoring und ähnliche Funktionen – weniger verlässlich machte als Kartenzahlungen.

Der neue Rahmen verschärft das. Banken werden klareren, besser durchsetzbaren Pflichten hinsichtlich der Leistung ihrer dedizierten Schnittstellen unterliegen – näher an der Zuverlässigkeit ihrer eigenen kundenseitigen Kanäle, mit definierten Erwartungen an Verfügbarkeit und Antwortzeiten, statt des locker durchgesetzten "angemessene Bemühungen"-Standards, der Teile der PSD2-Umsetzung prägte (MoFos Analyse der PSD3/PSR-Entwicklungen).

Für Händler, die Pay-by-Bank oder andere kontobasierte Checkout-Optionen anbieten oder in Betracht ziehen, ist das in zweierlei Hinsicht relevant:

• Weniger fehlgeschlagene oder abgebrochene Autorisierungsversuche sollten weniger abgebrochene Warenkörbe bei überweisungsbasierten Zahlungsmethoden bedeuten, die historisch bei der Abschlussrate teilweise wegen der Schnittstellenzuverlässigkeit hinter Karten zurücklagen.
• Wenn Sie für Risikoentscheidungen auf Kontoinformationsdienste setzen – etwa zur Verifizierung der Kontoinhaberschaft oder zur Prüfung von Kontoständen vor dem Versand hochwertiger Bestellungen –, sollten diese Datenströme konsistenter werden, sodass Sie darauf Workflows aufbauen können, statt Retry-Logik und Fallback-Handling dafür bauen zu müssen.

Nichts davon macht Tests Ihrer Integration gegen das reale Bankverhalten überflüssig, sobald die Regeln gelten. Es bedeutet lediglich, dass die Basiszuverlässigkeit, gegen die Sie testen, sich verbessern sollte.

Das ist der Teil, der in den meisten juristischen Zusammenfassungen übersprungen wird. Hier ist, was sich auf Ihrer Seite des Tisches bewegt.

Ihre PSP- und Acquirer-Verträge. Prüfen Sie die Haftungsverteilungsklauseln in Ihren bestehenden Zahlungsdienstverträgen. Bei Verträgen aus der PSD2-Ära ging die Haftungssprache oft von der alten, engeren Definition der "nicht autorisierten Transaktion" und den alten SCA-Ausnahmeregeln aus. Sobald die Haftungsbestimmungen der PSR gelten, können nicht aktualisierte Verträge auf Standards verweisen, die nicht mehr mit dem Gesetz übereinstimmen – was genau dann Unklarheit schafft, wenn Sie Klarheit brauchen: mitten im Streitfall. Fragen Sie Ihren PSP direkt, ob dessen Standard-Händlerbedingungen aktualisiert werden, um die PSR-Haftungsverteilung abzubilden, und lassen Sie sich die Antwort schriftlich geben, statt anzunehmen, dass es geregelt ist.

• Ihr Checkout-Flow. Drei konkrete Punkte zur Überprüfung:
• Stellen Sie sicher, dass der mit Ihrem Auszahlungskonto verknüpfte rechtliche Name mit Ihrem Shop-Branding übereinstimmt, um unnötige VoP-Abweichungswarnungen bei überweisungsbasierten Zahlungsmethoden zu vermeiden.
• Sorgen Sie dafür, dass Ihr SCA-Challenge-Flow (3DS oder gleichwertig) sauber degradiert – ein Kunde, der einen Kauf abbricht, weil ein Authentifizierungsschritt technisch fehlgeschlagen ist und nicht, weil er ihn abgelehnt hat, ist genau das Szenario, das die neuen Haftungsregeln erfassen sollen, und Sie wollen bei der Prüfung eines Streitfalls nicht auf der falschen Seite stehen.
• Wenn Sie Pay-by-Bank oder andere kontobasierte Optionen anbieten, planen Sie, die Abschlussraten erneut zu testen, sobald die neuen API-Leistungspflichten gelten – die Zuverlässigkeitsannahmen, auf denen Ihre Fallback-Logik basiert, könnten nicht mehr die bindende Einschränkung sein.

• Ihr Streitfallprozess. Die Beweise, die über einen Betrugs- oder Chargeback-Streitfall entscheiden, verändern sich. Während Streitfälle aus der PSD2-Ära oft davon abhingen, ob SCA überhaupt angewendet wurde, werden Streitfälle in der PSR-Ära häufiger davon abhängen, wie sie angewendet wurde, ob eine VoP-Prüfung durchgeführt wurde und welches Ergebnis sie lieferte, und wie schnell eine Betrugsmeldung eskaliert wurde. Das bedeutet:
• Ihr Support-Team benötigt bei der Bearbeitung eines Streitfalls Zugriff auf Authentifizierungsergebnisprotokolle, nicht nur auf den Transaktionsstatus.
• Ihre Dokumentation zur Beweiseinreichung sollte aktualisiert werden, um VoP-Übereinstimmungs-/Nichtübereinstimmungsergebnisse als Standardfeld aufzunehmen, sobald diese Daten in Ihren Transaktionsaufzeichnungen vorliegen.
• Interne SLAs zur Eskalation vermuteter Betrugsmeldungen an Ihren PSP sollten sich verschärfen, da Verzögerung selbst zunehmend zu einem Haftungsfaktor wird und nicht mehr ein neutraler Verwaltungsschritt ist.

Der Übergang von PSD2 zur PSR betrifft weniger neue, aus dem Nichts auftauchende Pflichten als das Schließen bestehender Lücken.

Händler, die Betrugshaftung, SCA und Streitfallbeweise als "was die lokale Bank eben sagt" behandelt haben, werden feststellen, dass diese Antwort nicht mehr trägt, sobald derselbe Verordnungstext in jedem Mitgliedstaat gilt. Die Arbeit ist administrativ – Verträge, Checkout-Texte und Beweisvorlagen aktualisieren –, muss aber vor der allgemeinen Anwendung erfolgen, nicht erst, nachdem der erste Streitfall nach den neuen Regeln die Lücke offenlegt.

Nichts davon erfordert eine Neuaufstellung Ihres Checkouts. Es erfordert, dass Sie Ihren PSP-Vertrag, Ihre registrierten Kontodaten und Ihre Streitfall-Beweisvorlagen als lebende Dokumente behandeln, die nach einem bestimmten Zeitplan überprüft werden müssen – genau das ist der Zweck der folgenden Checkliste.

Das genaue Datum der allgemeinen Anwendung hängt davon ab, wann das Amtsblatt den endgültigen Text veröffentlicht, aber die Abfolge steht fest. Nutzen Sie dies als Arbeitszeitplan und nicht als festen Termin, und bestätigen Sie die Daten, sobald die Amtsblatt-Veröffentlichung bestätigt ist.

• Bis Q4 2026 – Die Veröffentlichung im Amtsblatt wird erwartet (Juni–Juli 2026). Berechnen Sie nach der Veröffentlichung Ihr verbindliches Datum der allgemeinen Anwendung (21 Monate danach) und tragen Sie es in Ihren Compliance-Kalender ein. Beginnen Sie jetzt mit der Überprüfung des PSP-Vertrags, statt auf die Frist zu warten.
• Im Laufe von 2027 – Klären Sie mit Ihrem PSP dessen Plan zur Aktualisierung der Händlerbedingungen im Hinblick auf die PSR-Haftungsverteilung. Prüfen Sie den registrierten rechtlichen Namen Ihres Auszahlungskontos gegen Ihr Checkout-Branding. Erfassen Sie, welche Ihrer Checkout-Flows SCA nutzen, und dokumentieren Sie die aktuelle Ausnahmelogik, damit Sie sie mit den endgültigen PSR-Anforderungen vergleichen können.
• Anfang 2028 – Testen Sie Ihren Streitfall-Beweisprozess von Anfang bis Ende: Kann Ihr Support-Team SCA-Ergebnis- und VoP-Übereinstimmungsdaten für eine Transaktion auf Anfrage tatsächlich abrufen, oder erfordert das ein Engineering-Ticket? Beheben Sie diese Lücke, bevor sie in einem laufenden Streitfall auf die Probe gestellt wird.
• Bei allgemeiner Anwendung (voraussichtlich März–April 2028) – Bestätigen Sie, dass aktualisierte PSP-Verträge unterzeichnet sind, dass Ihre Checkout-Texte etwaige Anforderungen zum Zahlungsempfängernamen widerspiegeln und dass Ihre Streitfalldokumentation die neuen Beweisfelder enthält. Betrachten Sie das Datum der allgemeinen Anwendung als den Zeitpunkt, zu dem all das bereits laufen sollte – nicht als den Zeitpunkt, zu dem Sie damit beginnen.

Cost+ setzt auf IC++ (Interchange Plus Plus)-Preisgestaltung, gerade weil wir glauben, dass Händler bessere Entscheidungen treffen, wenn die Bestandteile einer Zahlung – interchange, scheme fee und unser Aufschlag – sichtbar sind statt gebündelt. Dasselbe Prinzip gilt für regulatorische Veränderungen: Je früher Sie erkennen können, was sich bei Haftung und Beweisanforderungen tatsächlich verändert, desto weniger disruptiv wird der Übergang. Wenn Sie besprechen möchten, wie Ihr aktueller Checkout- und Streitfall-Aufbau sich zum PSR-Zeitplan verhält, kontaktieren Sie unser Team oder vergleichen Sie Ihre aktuelle Gebührenstruktur mit den veröffentlichten Low-Risk-Preisen auf unserer Website, während Sie Ihre Verträge prüfen.