credit_card Funktionsbaustein: Ein- und Auszahlungfeedback

Eigenschaft	Wert
Kennung	DArch-FBS-EAZ
Hauptfähigkeit	E-Government
Geschäftsfähigkeit	E-Gov-Basisdienste
Version	0.1 (17.02.2026)
GovStack-Bezug	Payment Building Block

summarize 1 Management Summaryfeedback

Der Baustein „Ein- und Auszahlung" umfasst Funktionalitäten zur Abwicklung von Zahlungen von der Verwaltung an Bürgerinnen und Bürger oder andere externe Entitäten (Auszahlungen) sowie von diesen an die Verwaltung (Einzahlungen). Für letzteres bietet er eine Schnittstelle, um kostenpflichtige Bestellungen oder Beantragungen von Behördenleistungen durch Kunden (Bürgerinnen, Bürger und Unternehmen) einer Zahlung zuzuführen.

Integriert in die behördliche Fachanwendung oder ggf. in deren Warenkorb erlaubt der Basisdienst, Verwaltungsgebühren oder bereitgestellte Waren direkt online zu bezahlen und verwaltungsseitig haushaltskonform direkt zu vereinnahmen. Auf der Auszahlungsseite bietet der Baustein Funktionalitäten, um Transferleistungen an Zahlungsempfänger direkt oder mittels eines Gutscheinsystems zu übertragen.

description 2 Beschreibungfeedback

2.1 Systemkontextfeedback

Der Baustein „Ein- und Auszahlung" ermöglicht es, digitale Finanzzahlungen zu verfolgen, auszuwerten, zu initiieren, zu validieren, zu verarbeiten, zu protokollieren, zu vergleichen und mit dem Budget abzugleichen. Er stellt Interoperabilität sicher, indem er Schnittstellen zu verschiedenen externen Anwendungen bietet, die Zahlungsdienste benötigen, um Transaktionen in ihren eigenen Arbeitsabläufen auszulösen.

Der Baustein besteht aus Komponenten, die verschiedene Anwendungsfälle auf allgemeine Weise unterstützen:

• Government to Person (G2P) – Auszahlungen an Bürger:innen
• Person to Government (P2G) – Einzahlungen von Bürger:innen
• Government to Business (G2B) – Auszahlungen an Unternehmen
• Business to Government (B2G) – Einzahlungen von Unternehmen

menu_book 3 Terminologiefeedback

Begriff	Erläuterung
Gutschein	Nachweis, der den Inhaber zu einem Rabatt berechtigt oder gegen Waren/Dienstleistungen eingetauscht werden kann
Kunde	Bürgerinnen und Bürger sowie Unternehmen und andere externe juristische Personen
Massenzahlung	Zahlung von einem einzigen Zahler an mehrere Zahlungsempfänger
Transaktion	Der gesamte Austausch, der eine Ein- oder Auszahlung umfasst
Finanzdienstleister	Unternehmen, das zur Bereitstellung von Transaktionskonten zugelassen ist
Zahlungsempfänger	Empfänger von Geldern bei einer Zahlungstransaktion

settings 4 Kernfunktionalitätenfeedback

4.1 Frontendintegrationfeedback

Der Baustein ermöglicht die nahtlose Einbettung von Zahlungsfunktionen in Portale, Fachverfahren und mobile Anwendungen. Er stellt UI‑Komponenten, Redirect‑Flows oder API‑basierte Checkout‑Prozesse bereit, über die Bürgerinnen, Bürger oder Unternehmen Zahlungen sicher auslösen können. Er unterstützt Mehrkanal‑Fähigkeit (Web, App, Self‑Service‑Terminals) und sorgt für konsistente Nutzerführung.

4.2 Zahlungsanforderungfeedback

Der Baustein erzeugt standardisierte Zahlungsanforderungen (Payment Requests) für Gebühren, Abgaben oder sonstige Forderungen. Er beinhaltet Betrag, Fälligkeit, Verwendungszweck, Haushaltsstelle, Referenzkennzeichen und erlaubte Zahlungsmethoden. Er unterstützt einmalige, wiederkehrende und dynamische Zahlungsanforderungen (z. B. nach Antragseingang).

4.3 Zahlungsorchestrierungfeedback

Der Baustein steuert den gesamten Zahlungsprozess von der Initiierung bis zur Bestätigung. Er koordiniert Interaktionen zwischen Fachverfahren, Zahlungsdienstleistern (PSP), Banken, Haushalts‑/ERP‑Systemen und dem Postfach/Benachrichtigungssystem. Er sichert Transaktionskonsistenz, Wiederholbarkeit, Fehlerbehandlung und Statusmanagement.

4.4 Zahlungsroutingfeedback

Der Baustein wählt automatisch den passenden Zahlungsweg basierend auf Regeln wie: Zahlungsmethode, Gebührenart, Verwaltungsebene, PSP‑Verfügbarkeit, Kostenoptimierung oder rechtlichen Vorgaben. Er ermöglicht Multi‑PSP‑Betrieb, Fallback‑Routing und Lastverteilung.

4.5 Gutscheinmanagementfeedback

Der Baustein unterstützt digitale Gutscheine, Fördercodes oder Berechtigungstoken, die als Zahlungsmittel oder Teilzahlung eingesetzt werden können. Er beinhaltet Erstellung, Einlösung, Verfall, Missbrauchserkennung und Abrechnung. Er entspricht dem GovStack‑Modul „Voucher Management“.

4.6 Prozessmonitoringfeedback

Der Baustein bietet Echtzeit‑Überwachung aller Zahlungsprozesse: Status, Durchlaufzeiten, Fehler, Abbrüche, PSP‑Antwortzeiten. Er stellt Dashboards, Audit‑Logs und Warnmeldungen bereit. Er ermöglicht Compliance‑Monitoring (z. B. Haushaltsrecht, Kassenrecht, Zahlungsdiensterichtlinie).

4.7 Zahlungsmethodenadapterfeedback

Der Baustein stellt standardisierte Adapter für verschiedene Zahlungsarten bereit, z. B.: SEPA‑Überweisung, SEPA‑Lastschrift, Kreditkarte, PayPal, giropay, paydirekt, Apple/Google Pay, eRechnung, Instant Payment. Er abstrahiert PSP‑Spezifika und sorgt für Interoperabilität und Austauschbarkeit der Anbieter.

4.8 Zahlungsfreigabefeedback

Der Baustein unterstützt manuelle oder automatisierte Freigabeprozesse für Auszahlungen oder sensible Transaktionen. Er beinhaltet Vier‑Augen‑Prinzip, Rollen‑ und Berechtigungsmodelle, Limitprüfungen und Haushaltsvorgaben. Er integriert mit ERP‑/Haushaltssystemen und internen Kontrollsystemen.

4.9 Zahlungsnachweisefeedback

Der Baustein erzeugt und verwaltet digitale Zahlungsbestätigungen, Quittungen, eBelege und Buchungsnachweise. Er stellt sie Fachverfahren, Bürger:innen oder Unternehmen über APIs oder Postfach bereit. Er unterstützt Archivierung, Revisionssicherheit und Haushaltsabgleich.

4.10 Zahlungsgatewayfeedback

Das Zahlungsgateway ermöglicht die Interoperabilität zwischen verschiedenen digitalen Finanzdienstleistern (FSPs).

4.11 Massenzahlungenfeedback

Der Baustein ermöglicht automatisierte Auszahlungen in großer Stückzahl, z. B. für Förderprogramme, Erstattungen, Sozialleistungen oder Rückzahlungen. Er unterstützt Batch‑Verarbeitung, Sammelüberweisungen, Statusrückmeldungen und Fehlerhandling. Er bindet Haushalts‑ und ERP‑Systeme für Mittelbindung und Buchung ein.

shield 5 Querschnittsanforderungenfeedback

ID	Anforderung	Klassifikation
QA-EAZ-01	Externe Identifikation, Registrierung und Anmeldeprozesse	Erforderlich / Unveränderlich
QA-EAZ-02	Registrierungsanforderungen	Empfohlen
QA-EAZ-03	Überprüfung der Compliance	Optional
QA-EAZ-04	Gesetzliche und operative Anforderungen	Erforderlich / Unveränderlich
QA-EAZ-05	Echtzeit‑Antwortzeiten	Empfohlen
QA-EAZ-06	Validierung	Erforderlich / Unveränderlich
QA-EAZ-07	Autorisierung	Empfohlen
QA-EAZ-08	Anspruchsprüfung / Berechtigungsprüfung	Empfohlen
QA-EAZ-09	Verfügbarkeit des Budgets	Erforderlich / Unveränderlich
QA-EAZ-10	Berechnung von Zahlungen	Optional
QA-EAZ-11	Zahlungssysteme	Erforderlich / Unveränderlich
QA-EAZ-12	Abwicklung	Erforderlich / Unveränderlich

5.1 Externe Identifikation, Registrierung und Anmeldeprozessefeedback

Der Baustein geht davon aus, dass Identifikation, Registrierung und Anmeldung vollständig in externen Systemen erfolgen. Diese Systeme müssen den regulierten Zahlungs‑ und Bankvorgaben der jeweiligen Rechtsordnung entsprechen.

5.2 Registrierungsanforderungenfeedback

Ein Zahlungssystem oder ‑schema eines Landes kann verlangen, dass alle beteiligten Zahler oder Zahlungsempfänger (z. B. Kliniken, Ministerien, Einzelpersonen) bei einem regulierten Bank‑ oder Nichtbankinstitut registriert sind, bevor sie den Baustein nutzen dürfen.

5.3 Überprüfung der Compliancefeedback

Im Kontext von Zentralbank‑Digitalwährungen (CBDC) oder Zentralbankkonten für Privatpersonen wird angenommen, dass alle regulatorischen Bedingungen extern geprüft wurden sowie Zahler und Zahlungsempfänger gemäß den Regeln des jeweiligen Systems korrekt registriert sind.

5.4 Gesetzliche und operative Anforderungenfeedback

Der Baustein setzt voraus, dass gesetzliche/operative Anforderungen wie: Know Your Customer (KYC), Anti‑Money‑Laundering (AML) und Counter‑Terrorist‑Financing (CTF) bereits durch ein externes System erfüllt und innerhalb angemessener Zeit übermittelt wurden.

5.5 Echtzeit‑Antwortzeitenfeedback

Die zugrunde liegende Infrastruktur sollte Transaktionen so unterstützen, dass sie innerhalb einer vordefinierten maximalen Zeitspanne in Echtzeit beantwortet werden können.

5.6 Validierungfeedback

Der Baustein sollte in der Lage sein, über externe Systeme u. a. Folgendes zu validieren: Kontostatus; Konto‑ oder Routing‑Informationen; Zahlungsbestätigungen; unterschiedliche Fehlerbedingungen.

5.7 Autorisierungfeedback

In bestimmten Betriebsmodi prüft der Baustein Freigaben oder Zuweisungen des Haushaltssystems HKR, um sicherzustellen, dass ausreichende Mittel zur Verfügung stehen.

5.8 Anspruchsprüfung / Berechtigungsprüfungfeedback

Die Überprüfung, ob ein Begünstigter anspruchsberechtigt ist, soll üblicherweise in einem anderen Baustein stattfinden.

5.9 Verfügbarkeit des Budgetsfeedback

Vor der Erstellung eines Gutscheins (Voucher) muss geprüft werden, ob ausreichend Budget vorhanden ist.

5.10 Berechnung von Zahlungenfeedback

Die Berechnung von Zahlungen kann von vielen Attributen abhängen, die durch ein spezifisches Programm definiert werden.

5.11 Zahlungssystemefeedback

Der Baustein setzt voraus, dass es im Markt funktionsfähige Zahlungssysteme gibt – unabhängig davon, ob sie öffentlich, teilöffentlich oder privat / kommerziell betrieben werden.

5.12 Abwicklung (Settlement)feedback

Die Zahlungsabwicklung (ob brutto oder netto) selbst muss außerhalb des Bausteins erfolgen.

checklist 6 Funktionale Anforderungenfeedback

6.1 Zahlungsorchestrierungfeedback

Die Komponente Zahlungsorchestrierung (ZO) ist ein übergreifender Mechanismus, der mehrere Teilkomponenten oder Microservices verbindet.

6.2 Gutscheinmanagementfeedback

Das Gutscheinmanagement (Voucher Management) verwaltet u. a.: Pre‑Aktivierung, Speicherung, Aktivierung, Einlösung, Validierung, Sperrung, Entsperrung, Löschung und Reporting.

Hinweise:

• Die Ausgabe von Gutscheinen erfolgt durch einen anderen Baustein (z. B. Registrierung).
• Der Händler authentifiziert den Begünstigten und ruft das Einlöse‑API über USSD/App/Web auf.

6.3 Kontosuchdienstfeedback

Der Kontosuchdienst ordnet die eindeutige ID des Begünstigten dem gewünschten Zahlungskonto zu (z. B. Telefon, Personalausweis‑ID). Die Daten werden tokenisiert gespeichert. Je nach Land liegt die Verwaltung beim FSP oder der Regierung.

database 7 Datenstrukturenfeedback

Object	Beschreibung
Zahlungsanforderung (Payment Request)	Repräsentiert die Forderung der Verwaltung gegenüber Bürger:innen, Unternehmen oder anderen Entitäten.
Zahlung (Payment)	Das zentrale Objekt für die tatsächlich ausgeführte Transaktion.
Zahlungsstatus (Payment Status)	Standardisiertes Objekt zur Statuskommunikation zwischen Baustein, PSP und Fachverfahren.
Zahlungsmethode (Payment Method)	Beschreibt die Art der Zahlung, die für eine Transaktion verwendet wird: SEPA‑Überweisung, SEPA‑Lastschrift, Kreditkarte, PayPal, giropay, paydirekt, ...
Zahlungsauftrag / Auszahlungsauftrag (Payment Instruction / Payout Instruction)	Objekt zur Auslösung von Auszahlungen oder Erstattungen.
Massenzahlungsauftrag (Bulk Payment Batch)	Repräsentiert eine Sammlung von Auszahlungsaufträgen, die gemeinsam verarbeitet werden.
Gutschein / Fördercode (Voucher)	Objekt zur Verwaltung von digitalen Gutscheinen, Fördercodes oder Berechtigungstoken.
Zahlungsnachweis (Payment Receipt / Proof of Payment)	Revisionssicherer Beleg über eine erfolgte Zahlung.
Abgleichdatensatz (Reconciliation Record)	Objekt für den Abgleich zwischen Zahlung, PSP‑Daten und Haushalts-/ERP‑Systemen.
PSP‑Transaktionsobjekt (PSP Transaction)	Abstraktion der PSP‑spezifischen Transaktionsdaten.
Freigabeobjekt (Approval Record)	Objekt zur Abbildung von Freigabeprozessen (z. B. Vier‑Augen‑Prinzip).
Monitoring‑ und Auditobjekt (Audit Event / Process Event)	Repräsentiert Ereignisse im Zahlungsprozess für Monitoring, Compliance und Nachvollziehbarkeit.

api 8 Service-Schnittstellenfeedback

8.1 Schnittstellen für Fachverfahrenfeedback

Diese Schnittstellen ermöglichen es Fachverfahren, Zahlungen auszulösen, zu überwachen und Ergebnisse zu verarbeiten.

• Payment Request API: Erstellung, Aktualisierung und Stornierung von Zahlungsanforderungen. (entspricht ePayBL „Zahlungsanforderung“ und GovStack „Payment Initiation“)
• Payment Status API: Abruf von Zahlungsstatus, Transaktionshistorien, Fehlercodes, PSP‑Rückmeldungen.
• Refund / Auszahlung API: Auslösung von Auszahlungen, Erstattungen, Rücküberweisungen inkl. Freigabeprozessen.
• Mass Payment API: Batch‑Einreichung von Massenzahlungen (z. B. Förderprogramme, Erstattungen).
• Voucher API: Erstellung, Validierung und Einlösung von Gutscheinen/Fördercodes.
• Reconciliation API: Bereitstellung von Buchungsdaten, Zahlungsnachweisen, Abgleich mit Haushaltsstellen.

8.2 Frontend‑ und Portal‑Schnittstellenfeedback

Diese Schnittstellen dienen der Integration in Bürger‑ und Unternehmensportale sowie mobile Apps:

• Checkout‑Integration API / Redirect‑Flow: Startet den Zahlungsprozess über Web‑ oder App‑Oberflächen.
• Embedded UI Components (Widgets): Einbettbare Komponenten für Zahlungsübersichten, Quittungen, Statusanzeigen.
• Notification Callback API: Webhooks für Statusänderungen, Fehler, Bestätigungen.

8.3 Schnittstellen zu Zahlungsdienstleistern (PSP‑Integration Layer)feedback

Diese Schnittstellen abstrahieren PSP‑Spezifika und ermöglichen Austauschbarkeit:

• PSP Adapter API: Einheitliche Schnittstelle für PSP‑Anbindung (SEPA, Kreditkarte, PayPal, giropay, Instant Payment etc.).
• PSP Callback API: Entgegennahme von PSP‑Rückmeldungen (Success, Failure, Pending, Chargeback).
• Settlement & Clearing API: Daten für Abrechnung, Gebühren, PSP‑Reports.

GovStack‑Bezug: Payment Service Provider Integration.

8.4 Bank‑ und Finanzsystem‑Schnittstellenfeedback

Diese Schnittstellen bestehen zu Haushalts‑, ERP‑ und Kassenverfahren:

• ERP/Haushalt Integration API: Übergabe von Buchungsdaten, Haushaltsstellen, Mittelbindungen.
• Banking API (SEPA/EBICS/Instant Payment): Auslösung von Überweisungen, Lastschriften, Sammelaufträgen.
• Reconciliation Import API: Import von Kontoauszügen, Clearing‑Dateien, Zahlungsavisen.

ePayBL‑Bezug: Haushaltsabgleich, Rückmeldungen, Buchungsdaten.

8.5 Monitoring‑ und Audit‑Schnittstellenfeedback

Diese Schnittstellen unterstützen Betrieb, Compliance und Transparenz:

• Process Monitoring API: Zugriff auf Echtzeit‑Status, KPIs, Fehler, Durchlaufzeiten.
• Audit Log API: Revisionssichere Protokolle für Transaktionen, Freigaben, Änderungen.
• Reporting API: Statistiken, PSP‑Vergleiche, Budgetabgleiche.

GovStack‑Bezug: Payment Reporting & Reconciliation.

8.6 Sicherheits‑ und Identitätsschnittstellenfeedback

Diese Schnittstellen unterstützen Authentifizierung, Autorisierung und Freigaben:

• Identity & Access API: Integration mit EUDI‑Wallet, Unternehmenskonto, BundID, OIDC/OAuth2.
• Authorization API: Rollen‑ und Rechteprüfung, Freigabeprozesse (z. B. Vier‑Augen‑Prinzip).
• Signature / Non‑Repudiation API: Digitale Signaturen für Zahlungsfreigaben und Nachweise.

8.7 Interoperabilitäts‑ und Standardisierungsschnittstellenfeedback

Diese Schnittstellen sorgen für die föderale Wiederverwendbarkeit und Austauschbarkeit:

• Standardisierte Datenmodelle (JSON‑Schema / XÖV‑Profile): Einheitliche Zahlungsobjekte, Statuscodes, Fehlerstrukturen.
• Event‑Schnittstellen (Event Bus / Messaging): Publikation von Zahlungsereignissen für andere Bausteine (z. B. Postfach, Vorgangsbearbeitung).
• Compliance‑Schnittstellen: PSD2‑Konformität, Kassenrecht, Haushaltsrecht, eIDAS‑Regeln.

account_tree 9 Interne Workflowsfeedback

library_books 10 Weiterführende Informationen und Quellenfeedback

• GovStack Payment Building Block Specification
• GIB-Dienst „Zahlungsabwicklung"
• Architekturkonzept ePayBL (Bund-Länder-Lösung)