Skip to main content

SEPA Request-to-Pay

SEPA-Regelwerk für Zahlungsaufforderungen

SEPA Request-to-Pay


Weitere Informationen:

Externe Webseiten:

Externe Dokumente:


Ein Request-to-Pay (RTP) ist eine Messaging-Funktionalität. Es handelt sich nicht um ein Zahlungsmittel oder ein Zahlungsinstrument, sondern um eine Möglichkeit, eine Zahlungsinitiierung anzufordern.

Aus der Übertragungsperspektive ist ein RTP kanalunabhängig. Der Zahlungsempfänger kann via seinem RTP-Dienstleistungsanbieter, welcher direkt oder indirekt mit dem Zahler verbunden sein muss, über jeden gesicherten Kanal den RTP an den Zahler übertragen. Der Zahler selber kann ein RTP direkt vom Zahlungsempfänger über verschiedene Umgebungen wie z.B. Proximity-Technologien, Messaging-Anwendungen, dedizierte APIs usw. empfangen.

SEPA Request-to-Pay Scheme Rulebook

SEPA RTP Rulebook

Rulebook

SEPA Request-to-Pay Scheme Rulebook

SEPA Request-to-Pay Implementation Guidelines

SEPA RTP Implementation Guidelines

Implementation Guidelines

SEPA Request-to-Pay Implementation Guidelines

Abb. 1: SEPA Request-to-Pay Standard

Ein Request-to-Pay kann als Ergänzung zum Zahlungsprozess betrachtet werden, da er den End-to-End-Prozess unterstützt und zwischen einer zugrunde liegenden kommerziellen Transaktion und der Zahlung selbst liegt. Beispielsweise können beim Kauf von Waren und Dienstleistungen, unabhängig von der Vielfalt und Komplexität der beteiligten kommerziellen Prozesse, die folgenden Grundkomponenten unterschieden werden:

Abb. 2: Fokus von Request-to-Pay

  1. Vorbereitungsphase, in der die zugrunde liegende Transaktion, für die eine Zahlung fällig ist, festgelegt wird. (Dieser Teil liegt ausserhalb des SRTP-Schemas).
  2. Erstellung und Vorlage des RTP an den Zahler.
  3. Annahme oder Ablehnung des RTP. Der Kunde (Zahler) kann den RTP annehmen - und diese Annahme kann eine sofortige oder zukünftige Zahlung folgen - oder verweigert werden.
  4. Zahlungsprozess, beginnend mit der Initiierung der Zahlung und der Auswahl/Bestätigung des Zahlungsinstruments, gefolgt von der Ausführung der Zahlung nach der Authentifizierung des Kunden, soweit erforderlich. (Dieser Teil liegt ausserhalb des SRTP-Schemas).

Rollen und Informationsfluss eines Request-to-Pay

Akteure eines Request-to-Pay

Zu den vier Arten von Akteuren, die an dem Schema beteiligt sind, gehören:
AkteurRolle
Zahlungsempfänger

Der Initiator eines RTP-Prozesses und in der Regel der Empfänger der im resultierenden Zahlungsstrom übertragenen Gelder. Ist dieser Rolle der Begünstigter bei der Zahlungsabwicklung.

Zahler

Er repräsentiert die Partei, an die sich der RTP wendet, und den Auftraggeber der im resultierenden Zahlungsfluss transferierten Gelder. Ein Zahler sollte immer die Möglichkeit haben, sich vom RTP-Service abzumelden.

RTP-Service Provider
des Zahlungsempfängers

Der RTP-Service Provider des Zahlungsempfängers muss sich dem RTP-Schema angeschlossen haben und ist normalerweise ein PSP. Da aber ein RTP Teil von End-to-End-Handelsprozessen sein kann, können auch andere, nicht-PSP-Unternehmen diese Rolle übernehmen. So können beispielsweise auch E-Rechnung oder E-Commerce Service Provider RTP-Service Provider des Zahlungsempfängers sein.

RTP-Service Provider
des Zahlers

Der RTP-Service Provider des Zahlers muss sich dem RTP-Schema angeschlossen haben und ist in der Regel ein PSP. Aber auch andere Nicht-PSP-Unternehmen können diese Rolle übernehmen. So können beispielsweise auch E-Rechnung oder E-Commerce Service Provider RTP-Service Provider des Zahlers sein.

Informationsfluss eines Request-to-Pay

Das untenstehende Diagramm veranschaulicht die RTP-Meldungsflüsse für ein generisches Ökosystem mit vier Akteuren. Der abgebildete Anwendungsfall deckt verschieden Use Cases ab:

  • Physischer oder Online-Einzelhandel
  • Person-to-Person (P2P)
  • E-Invoice Presentment and Payment (EIPP) Transaktionen (z.B. auf Business-to-Customer (B2C), Business-to-Business (B2B) und Business-to-Government (B2G) Ebene).

Bei diesem Modell verwenden sowohl der Zahlungsempfänger als auch der Zahlungspflichtige ihren eigenen RTP-Service Provider.

Der Zahlungsempfänger kann RTPs über Routing-Service Provider an die erreichbaren Zahler senden. In jedem Fall muss die Kennung des Zahlers und des RTP-Service Provider des Zahlers dem Zahlungsempfänger oder dem RTP-Service Provider des Zahlungsempfängers (vor der Ausstellung eines RTP) bekannt sein, damit der RTP-Service Provider des Zahlungsempfängers den RTP an den RTP-Service Provider des Zahlers weiterleiten kann.

Der Einfachheit halber und ausserhalb des Geltungsbereichs des RTP-Schemas werden die Zahlungsflüsse in der folgenden Abbildung nicht dargestellt. Es ist zu beachten, dass in einem komplexeren Szenario die PSPs des Zahlungsempfängers und/oder Zahlers andere Einheiten als die RTP-Dienstanbieter sein könnten.

Request-to-Pay

Abb. 3: Akteure und Informationsfluss Request-to-Pay (RTP)

Die Schritte im Diagramm können wie folgt beschrieben werden:

  1. Identifikation des Zahlers: Eine erste Interaktion ermöglicht die Kommunikation der Kennung des Zahlers und der Kennung des RTP-Service Providers des Zahlers (Hinweis: Die Identifizierung und Authentifizierung werden zwischen dem Zahler/Zahlungsempfänger und seinen jeweiligen RTP-Dienstanbietern vereinbart).
  2. RTP an den RTP-Dienstanbieter des Zahlungsempfängers: Das RTP wird vom Zahlungsempfänger an den RTP-Service Provider des Zahlungsempfängers gesendet. Es enthält alle RTP-Kerndaten, einschliesslich der Kennung des Zahlers.
  3. RTP an den RTP-Service-Provider des Zahlers: Das RTP wird über das Netzwerk des RTP-Service Provider gesendet.
  4. RTP-Präsentation an den Zahler: Das RTP wird dem Einzahler auf dem vereinbarten Kanal oder Gerät (z.B. Smartphone, Webbrowser usw.) präsentiert.
  5. Statusbericht: Die Annahme/Verweigerung des RTP durch den Zahler wird über die Inter-RTP-Service-Provider-Infrastruktur an den Zahlungsempfänger zurückgesendet.

Fahrplan und Weiterentwicklung des SEPA RTP-Schemas

Mögliche Themen, die in einer zukünftigen Version des Regelwerks für das Schema behandelt werden sollen, sind u.a.

  • Zahlungsgarantie
  • Ratenzahlungen
  • Vorautorisierung von Zahlungen
  • Zahlungsinitiierung in der PSP-Anwendung des Zahlers
  • die Möglichkeit, eine URL anzugeben
  • Freie Wahl der Währung