Vorwort

"ePayment" meint zunächst "elektronischer Zahlungsverkehr". Konkreter wird hier die Einbindung von Zahlungsmöglichkeiten in Online-Dienstleistungen der öffentlichen Hand beschrieben. Also die Möglichkeit für Bürgerinnen und Bürger, z.B. Gebühren für eine Kfz-Zulassung direkt im Online-Dienst zu bezahlen. Und die Möglichkeit für die Verwaltung, diese Zahlungen entgegenzunehmen und möglichst automatisiert zu verbuchen.

In diesem Dokument werden dazu Grundbegriffe und -strukturen erläutert, sowie auf weiterführende Dokumentationen verwiesen. Außerdem werden auch (laufende) Veränderungen erläutert.

Und nicht zuletzt: Spezielle Anforderungen und rechtliche Vorgaben - z.B. im Datenschutz - erforderten und erfordern häufig eigene Lösungen für ePayment im öffentlichen Dienst. Durch die föderale und kommunale Struktur sind zudem parallel unterschiedliche Lösungen gewachsen. Hier sollen nun sukzessive Standards für eine Vereinheitlichung sorgen. Auch dies soll hier stichwortartig aufgeführt werden, wo es praktische Relevanz hat und dem Verständnis dient.

Rahmenbedingungen für ePayment im öffentlichen Dienst

ePayment soll in Online-Dienstleistungen der öffentlichen Hand integriert werden, die jeweils in der Verantwortung des Bundes, der (Bundes-)Länder oder von Kommunen liegen. Für die Aufgaben bei Dataport ist zumeist die Landes- oder Kommunalebene relevant. Je nach eben genannter Verantwortlichkeit bestehen auch entsprechende Entscheidungsrechte für die Ausgestaltung der Zahlungsvorgänge und verbundener Tätigkeiten. Auf dieser Grundlage ist in den letzten Jahren und Jahrzehnten eine teils heterogene Landschaft von Lösungen gewachsen, die sich bei der Einführung von ePayment z.T. als Herausforderung präsentieren.

Demgegenüber stehen Bemühungen der Vereinheitlichung und Standardisierung – z.b. über den IT-Planungsrat, die FITKO und die KoSIT. So entstanden beispielsweise die Beschlüsse über die Standards „XBezahldienste“ oder „XFinanz“. Ebenso gibt es Ansätze zur gemeinsamen Nutzung von Lösungen – z.b. nach „EfA“ („Einer für alle“).

Beispiele

Eine Kommune kann beispielsweise selber entscheiden, welche HKR-Softwareanbieter sie beauftragt oder wie sie Buchungsnummern vergibt. (Zum Verständnis: "HKR" wird auch gern als "SAP des öffentlichen Dienstes" bezeichnet.). Ganz wichtig und praxisrelevant ist auch die Möglichkeit, bestimmte Gebühren festzulegen. So kann ein und die selbe Gebühr bei verschiedenen Kommunen nach unterschiedlichen Vorstellungen festgelegt werden. Eine Kommune könnte z.B. für Kurtaxe Familien- oder Feiertagsrabatte beschließen. Kommunen können Ihre Aufgaben auch unterschiedlich organisieren – z.B. Verwaltungsdienstleistung durch andere Kommunen erfüllen lassen. 

Auch die Länder haben Verwaltungsdienstleistungen durch unterschiedliche Anbieter digitalisieren lassen und auch teils unterschiedliche Paymentplattformen beauftragt.  Hinzu kommt, dass selbstverständlich auch Online-Dienstleistungen rechtliche Vorgaben – z.B. bezüglich Aufbewahrungsfristen – einzuhalten haben, die teils noch aus vor-Digitalisierungszeiten stammen.

Soll eine Online-Dienstleistung mit Payment, die eine Kommune hat realisieren lassen, von einer anderen Kommune eingesetzt werden (nach EfA-Prinzip), so kann es z.B. passieren, dass unterschiedliche Zahlungsarten genutzt werden sollen, die Gebührenstruktur unterschiedlich ist oder in der Abrechnung Probleme entstehen, weil die Kommunen unterschiedliche HKR-Anbieter beauftragt haben, die nicht die selbe Schnittstelle oder Standards unterstützen. Das heißt, dass die oben erwähnten kommunalen Verantwortlichkeiten unmittelbaren Einfluss auf die Umsetzung und Umsetzungsgeschwindigkeit von ePayment haben, weil jeweils Anpassungen notwendig werden.

Beteiligte Systeme

ePayBL

Zitat (s. https://www.epaybl.de/): "ePayBL ist eine Plattform zur Integration von Zahlverfahren, wie Kreditkartenzahlungen, PayPal und Giropay in elektronische Geschäftsprozesse öffentlicher Verwaltungen. So werden Parktickets, Urkunden und Bußgelder schnell und unkompliziert elektronisch zahlbar.".

"ePayBL" steht dabei für "EPayment Bund Länder". Das bedeutet, dass die Plattform von 11 Bundesländern und dem Bund beauftragt wird. Die konkrete Steuerung übernimmt dabei das Gremium "EG" (Entwicklergemeinschaft), die halbjährlich tagt (Umlaufbeschlüsse   ) und über   entscheidet.

Die ePayBL ist eine Server-Software, die seit 2005 entwickelt wird und auf Basis von Apache Tomcat   arbeitet. Die (Weiter-)Entwicklung der ePayBL wird alle vier Jahre ausgeschrieben und erfolgt seit über 10 Jahren (Stand Frühjahr 2024) durch die Firma dResearch. Die Weiterentwicklung erfolgt in den sog. "Linien" 2.x, 3.x und der kommenden ePayBL 4.x, die seit 2019 entwickelt und für 2025 oder 2026 erwartet wird. dResearch betreibt die Software jedoch nicht, sondern dies geschieht bei den entsprechenden Ländern bzw. ihren Dienstleistern wie Dataport oder SID . Es gibt also nicht "einen" ePayBL-Server, sondern es werden verschiedene Versionen an verschiedenen Stellen betrieben. Dataport betreibt zur Zeit (Stand Frühjahr 2024) eine Instanz der Linie 3.x für Schleswig-Holstein, die zusätzlich von einigen Kommunen von Sachsen-Anhalt genutzt wird. Einige von Dataport betreute Kommunen werden aber auch auf Servern des SID betreut. Alle von Dataport betreuten Mandanten sollen im Laufe des Jahres 2024 auf eine neue "Mehrländer-"Instanz (ebenfalls Linie 3.x) bei Dataport umziehen.

Begrifflichkeiten

Arten des ePayments

Prepayment

Prepayment ("Vorauszahlung") wird eingesetzt, wenn die Zahlungshöhe bei der Nutzung des Online-Dienstes bereits feststeht. Also wenn es sich z.B. um eine fixe Gebühr handelt oder Gebührenstaffelungen aufgrund von Eingaben bei der Nutzung direkt ermittelt werden können. Prepayment ist die am häufigsten und auch bevorzugt eingesetzte Zahlungsart.

Vorgehen

Für die Auslösung des Zahlungsprozesses müssen durch einen Online-Dienst drei Fragebereiche geklärt werden:

Höhe der Zahlung

Die Höhe der Zahlung muss durch den Online-Dienst ermittelt werden. Es gibt zur Zeit kein zentrales System, aus dem Zahlungshöhen abgefragt werden können. Theoretisch könnte im "Zufi-Service 2.0" zumindest eine Fix-Gebühr hinterlegt werden. Es wird aber davon abgeraten, dies zu nutzen, da dies nie vorgesehen war und nicht garantiert werden kann, dass dieses Feature weiter zur Verfügung steht. In der Praxis werden die Zahlungshöhen zur Zeit auf unterschiedliche Arten von den Online-Diensten selber in jeweils eigenen Strukturen abgelegt.

Ermittlung des Empfängers

Der "Plattformdienst Zufi-Service 2.0" (früher gelegentlich "Jesaja" genannt) dient der Ermittlung des Empfängers.

Input: Leica-ID und ARS 

Output: Mandatennummer und Bewirtschafternummer, Haushaltsstelle und Objektnummer 

Aufruf des Zahlungssystems / Schnittstelle

Zentral für die Abwicklung von ePayment für Online-Dienste ist die Plattform "ePayBL". Online-Dienste von Dataport können das vorgeschaltete interne System "PDPayment" nutzen. Dieses bietet eine Zertifikatsverwaltung und erweiterte Logging-Möglichkeiten. Die Daten werden von PDPayment an die ePayBL weitergeleitet, die von externen (nicht-Dataport-) Online-Diensten direkt angesprochen wird.

Probleme

Post-Payment

Beim Post-Payment ("Nachzahlung") erfolgt die Bezahlung separat, nachdem die Nutzung eines Online-Dienstes abgeschlossen und die Bestellung ausgelöst wurde. Dies wird z.b. genutzt, wenn ein Bürger Scans eines Grundbuchamt-Dokuments bestellt, die Länge des Dokuments nicht elektronisch vorliegt und die Gebühr sich nach der Anzahl der Seiten richtet. 

Post-Payment hat nichts mit dem Bezahlangebot der Deutschen Post "Post-Pay" zu tun.

Vorgehen

Nach Eingabe der Kosten durch den Sachbearbeiter erhält der Bürger einen Link auf die Bezahlseite. Das weitere Vorgehen entspricht der Nutzung der Bezahlseite im Prepayment  

Probleme

Es gibt derzeit kein Tool, um den Preis einer Post-Payment-Dienstleistung nach deren Ermittlung einzugeben. (Wie funktioniert dies denn dann aktuell )