4 Kernfunktionalitätenfeedback
Der Baustein übernimmt die Zahlungsabwicklung und Orchestrierung. Dazu gehören:
- die Überprüfung von Nutzerdaten
- die Bestätigung der Daten des Zahlungsempfängers
- die Verifizierung des Zielkontos des Begünstigten
- die Berechnung von Gebühren
- die Verarbeitung automatisierter Massentransaktionen
Der Baustein ermöglicht es Verwaltungsprogrammen, Zahlungen über eine gemeinsame Zahlungsinfrastruktur an Konten verschiedener Anbieter zu leiten. Bürgerinnen und Bürger können so ihre bevorzugten Finanzdienstleister wählen oder den Anbieter wechseln, wenn sich ihre Situation ändert oder ein besserer Service verfügbar wird.
4.1 Zahlungsorchestrierungfeedback
Die Zahlungsorchestrierung (Payment Orchestration) stellt einen End-to-End-Workflow über verschiedene Teilsysteme hinweg bereit, ermöglicht asynchrone Verarbeitung und unterstützt unterschiedliche Zahlungsarten, Anwendungsfälle, Kontosysteme und Kanäle.
4.2 Gutscheinmanagementfeedback
Der Baustein stellt ein Gutscheinmanagement (Voucher Management) bereit, das für die Bereitstellung, Speicherung, Ausgabe, Aktivierung, Einlösung, Validierung, Sperrung, Entsperrung, Löschung und Auswertung von Gutscheinen verantwortlich ist.
4.3 Kontosuchefeedback
Die Kontosuche (Account Lookup Services) identifiziert den Finanzdienstleister (FSP), bei dem das Konto des Händlers, Agenten oder Zahlungsempfängers geführt wird. Er vereinfacht das Zahlungsrouting und verhindert, dass Zahlungsinformationen in einem Personenregister gespeichert werden müssen. Dadurch werden Privatsphäre und Vertraulichkeit geschützt.
4.4 Zahlungsanforderungfeedback
Der Baustein muss es Systemen ermöglichen, eine Zahlungsanforderung zu starten (Payment Request Initiation). Eine solche Anforderung kann extern von einem anderen Baustein kommen (z. B. Registrierung, Sozialleistungsregister, Lohn und Gehalt) oder intern aus dem Baustein selbst stammen.
4.5 Zahlungsgatewayfeedback
Der Baustein sollte ein Zahlungsgateway (Payment Gateway) bereitstellen, das die Interoperabilität zwischen verschiedenen digitalen Finanzdienstleistern (FSPs) ermöglicht.
4.6 Zahlungsportalfeedback
Der Baustein sollte ein Portal (Payment Portal) bereitstellen, über das Nutzer den gesamten Lebenszyklus von Zahlungen verwalten können, sowohl das Senden als auch das Empfangen.
4.7 Ereignisverwaltungfeedback
Der Baustein muss verschiedene Ereignisse unterstützen (Event Management), die bestimmte Aktionen auslösen, z. B.
- Ausstellung von Belegen bei erfolgreicher Zahlung
- Automatisierung von Zahlungen bei Massentransaktionen
- Weitergabe von Informationen an andere Bausteine
- Behandlung von Ausnahmefällen (z. B. Benutzer- oder Systemfehler)
4.8 Abstimmungfeedback
Der Baustein muss Funktionen bereitstellen, die sowohl interne als auch externe Abstimmungsdienste ermöglichen. Abstimmung (Reconciliation) bezeichnet im Zahlungsverkehr den Abgleich von Transaktionsdaten zwischen internen Systemen oder mit externen Partnern (z. B. Banken, Gateways, Zahlungsdienstleistern).
4.9 Stapelverarbeitungfeedback
Der Baustein sollte Dienste für die Stapelverarbeitung bereitstellen (Batch Processing).
4.10 Zeitsteuerungfeedback
Der Baustein sollte Planungsdienste (Scheduling Services) bereitstellen, um Aufgaben regelmäßig oder wiederholt auszuführen. Dies kann über den Scheduler-Baustein oder interne Timerfunktionen erfolgen.
4.11 Ereignisprotokollierungfeedback
Alle Komponenten sollten Anwendungs- und Transaktionsprotokolle (Event Logging) erzeugen, damit das System überwacht werden kann und Fehlerbehebung effizient möglich ist.
4.12 Audit-Protokollierungfeedback
Audit-Trails sind erforderlich, um die Integrität von Anfragen und darauf folgenden Aktionen sicherzustellen (Audit Logging). Ein Audit-Trail ist ein chronologischer Datensatz, der es ermöglicht, Abläufe und Ereignisse einer Transaktion von Anfang bis Ende nachzuvollziehen. Er muss definierte Anforderungen erfüllen.
4.13 Auswertungfeedback
Der Baustein sollte Berichtsservices (Reporting Services) bereitstellen, z. B. Dashboards oder Analyseberichte, die konfigurierbar sind.
4.14 Sicherheitsschichtfeedback
Der Baustein muss eine Sicherheitsschicht (Security Layer) bereitstellen, die den Schutz auf Transport- und Anwendungsebene gewährleistet. Sie stellt APIs für Verschlüsselung bei Übertragung und Speicherung sowie digitale Signaturen für API-Authentifizierung bereit.
4.15 Massenzahlungenfeedback
Der Baustein muss Massenzahlungen (Bulk Payment Service) unterstützen, z. B. für G2P- oder G2B-Auszahlungen.
4.16 Währungsunterstützungfeedback
Der Baustein unterstützt Systeme mit mehreren Währungen (Support for Multicurrency Payments). Jede Währung wird unabhängig und ohne Umrechnung verarbeitet. Das System, das die Zahlung initiiert (z. B. Register-Baustein bei G2P oder ein Rechnungssteller bei P2G), gibt die Währung an. Der Treasury-Bereich führt getrennte Konten und Finanzdaten pro Währung.