SEPA Request-to-Pay: der Empfänger fragt, der Zahler zahlt

Diese Unterscheidung entscheidet jede weitere Designfrage. SRTP transportiert eine Anforderung und eine Antwort. Die Zahlung danach läuft über eine SEPA-Überweisung, meist die Echtzeitvariante, und dort sitzen Geld und Endgültigkeit. Nimmt der Kunde eine SRTP-Nachricht an und die Überweisung scheitert, war die Anforderung korrekt zugestellt und die Rechnung bleibt offen.

Deshalb passt das Verfahren so gut zu Echtzeitüberweisung in Europa. Die Anforderung bringt dem Empfänger die Rechnungsdaten und die Gewissheit, dass der Richtige sie gesehen hat, die Echtzeitüberweisung bringt das Geld in zehn Sekunden mit Bestätigung. Zusammen leisten sie das, was eine Kartenzahlung im Checkout leistet, über Bankkonten, und das behandelt Account-to-Account-Zahlung.

Das EPC veröffentlicht das SRTP-Regelwerk und daneben die Implementation Guidelines und eine API-Spezifikation. Die Trennung zählt für Entwickler: Das Regelwerk sagt, was die Teilnehmer einander schulden und was die Nachrichten bedeuten, die Guidelines sagen, wie ein Feld genau gefüllt wird, die API-Spezifikation sagt, wie der Aufruf aussieht. Wer nur das Regelwerk liest, baut etwas, das nicht interoperabel ist.

Das Verfahren beschreibt vier Rollen. Empfänger und Zahler sind die Unternehmen oder Personen mit der Rechnung dazwischen. Jeder hat einen SRTP-Dienstleister, der seine Daten in das Verfahrensformat bringt und mit dem anderen Dienstleister austauscht. Ein Online-Händler gibt seinem Dienstleister Käufername, IBAN, Betrag und Artikel, dieser baut die Anforderung im Format des Regelwerks, und der Dienstleister des Käufers stellt sie in dessen App zu.

SRTP-Dienstleister kann jedes Unternehmen werden, das die technische Infrastruktur betreibt und die Verfahrensregeln anerkennt, wie PayTechLaw anmerkt, was Banken und Zahlungsinstitute begünstigt, aber nicht exklusiv stellt. Die Anforderung erreicht den Zahler dort, wo er schon ist: in der Banking-App, per Push, per E-Mail oder über einen Messenger. Diese Wahl liegt beim Dienstleister, und sie entscheidet, ob der Kunde die Anforderung rechtzeitig zur Fälligkeit sieht.

Die zwei Fälle sehen in der Praxis anders aus. Im Online-Checkout kommt die Anforderung sofort: Der Käufer wählt die Methode, die Anforderung erreicht die Banking-App in Sekunden, der Käufer gibt sie mit der Authentifizierung frei, die seine Bank ohnehin verlangt, und die Echtzeitüberweisung ist durch, bevor die Seite neu lädt. Gegenüber der Karte gewinnt der Händler Kosten und spart das Chargeback, verliert aber den Weg über die Kartenreklamation.

Auf der Rechnung ist die Anforderung terminiert, und das ist der interessantere Fall für deutsche Unternehmen. Eine SRTP-Nachricht kann ein Fälligkeitsdatum tragen, der Kunde bekommt sie mit der Rechnung und zahlt am Fälligkeitstag. Die Referenz reist mit der Zahlung, der Abgleich ist also kein Zuordnungsproblem mehr. E-Commerce-Zahlungen in Deutschland behandelt die Checkout-Seite, Treasury im Unternehmen die Rechnungsseite.

Eine SEPA-Lastschrift zieht. Der Empfänger hält ein Mandat, löst den Einzug aus, und das Geld verlässt das Konto des Zahlers, ob der aufpasst oder nicht. SRTP schiebt. Der Empfänger kann nur fragen, und jede Zahlung braucht die Freigabe des Zahlers, also kein Mandat zum Einholen, Aufbewahren und Nachweisen.

Dieser Tausch ist das ganze Argument. Die Lastschrift gibt einem Abo-Geschäft planbares Geld und ein Rückgaberisiko von acht Wochen. SRTP gibt es kein Rückgaberisiko, weil der Zahler jede Zahlung freigab, und eine Einzugsquote, die davon abhängt, dass Kunden antworten. Für wiederkehrende, schwankende Beträge heißt die Open-Banking-Antwort Variable Recurring Payments, die dazwischen liegt.

Eine Anforderung zu senden kostet nichts, und darin steckt das Sicherheitsproblem hinter dem Komfort. Das Verfahren garantiert, dass eine Nachricht im richtigen Format ankam, nicht dass der Absender der Lieferant ist, für den er sich ausgibt. Lieferanten-Impersonation ist das zu erwartende Muster: eine Anforderung, die wie die gewohnte Rechnung aussieht, mit anderer IBAN dahinter.

Wer Anforderungen empfängt, braucht also dieselbe Disziplin wie bei Rechnungen per E-Mail. Das Lieferantenkonto gegen den eigenen Stamm prüfen, eine geänderte IBAN als Vorgang mit Rückruf auf bekannter Nummer behandeln und die Anforderung gegen die Bestellung abgleichen, bevor jemand freigibt. Betrugsprävention behandelt die Kontrollen, die Empfängerüberprüfung fängt den Fall, in dem der Name nicht mehr zum Konto passt.

Das EPC führt das Register der SRTP-Teilnehmer, und die Verbreitung lief langsamer als von den Erfindern gehofft. Das Henne-Ei-Problem ist strukturell: Ein Händler bietet keine Methode an, die wenige Kundenbanken empfangen können, und eine Bank baut keinen Empfang für Anforderungen, die kein Händler sendet. Wero und die European Payments Initiative arbeiten von der Verbraucherseite an derselben Lücke, siehe Wero in Deutschland.

Eine Bank auf Zahlerseite muss Anforderungen empfangen, sie in der App verständlich zeigen, dem Kunden Annahme, Ablehnung oder einen späteren Termin erlauben und die Annahme an die eigene Zahlungsauslösung hängen. Ein Dienstleister auf Empfängerseite muss die Daten prüfen, die Statusantworten verarbeiten und dem Händler sagen, was passierte. Beide brauchen die Erreichbarkeitsdaten des Verfahrens, dasselbe Routing-Problem, das die Empfängerüberprüfung mit einem Verzeichnis löst.

SEPA Request-to-Pay ist ein EPC-Verfahren, bei dem ein Zahlungsempfänger eine strukturierte Zahlungsanforderung an einen Zahler sendet, der sie in seiner Banking-App annimmt oder ablehnt. Das Verfahren trägt Anforderungen bis 100.000 Euro und bewegt selbst kein Geld: Die Zahlung nach einer Annahme ist eine eigene SEPA-Überweisung.

Nein. SRTP ist eine Nachrichtenschicht vor der Zahlung. Ein Kunde, der eine Anforderung annimmt, gibt danach eine Überweisung frei, und diese Überweisung ist die Zahlung. Ein Händler mit SRTP im Checkout bietet also eine Kontozahlung mit angehängter Anforderung, und die Abwicklungsregeln kommen von der Überweisung, nicht von SRTP.

Nein. Eine SRTP-Nachricht trägt die Daten zum Zahlen, und das deutsche und europäische Steuerrecht verlangt auf einer Rechnung mehr. Die Anforderung läuft also neben der Rechnung, nicht an ihrer Stelle, und wer den Rechnungslauf sparen will, muss die Rechnungspflichten weiterhin eigenständig erfüllen. Spätere Versionen des Verfahrens sollen Teil- und Ratenzahlungen tragen, was den Umfang einer einzelnen Anforderung erweitert.