Giropay Deutschland: Online-Banking

1) Kontext und Positionierung von giropay

giropay ist ein deutsches „Pay-by-Bank“ -A2A-Schema, bei dem der Käufer die Zahlung in seiner Internetbank/mobilen App der ausstellenden Bank bestätigt. Merchant erhält einen Online-Status und das Geld kommt per Bankkredit (in der Regel T + 0/T + 1 Werktage, abhängig von der Bank/PSP und der verwendeten Abrechnungsschiene). Die Zulassungskosten liegen unter dem typischen kartenbasierten MDR, der SCA wird vom Emittenten gemäß PSD2 durchgeführt.

• Issuer-redirect/App2App: Umleitung auf eine Bank oder Öffnen ihrer Anwendung.
• SCA und Gerätebindung: Bestätigung bei der Bank, Minimierung von Betrug.
• Umfangreiche Metadaten für den Abgleich: merchant reference/orderId, transactionId.
• Refund per Überweisung: Charjback wie in Karten gibt es nicht.

2) Rollen und Teilnehmer

Giropay-Schema - Regeln, Routing zu Banken.
Issuer (Zahlerbank) - Kundenauthentifizierung, Bestätigung, Limits/Betrugsbekämpfung.
PSP/Acquirer (CPSP) - Merchant-Verbindung, API/SDK, Webhooks, Berichte und Berechnungen.
Händler - Zahlungseinleitung, Status-/Retourenabwicklung, Abgleich.

3) Zahlungsströme

3. 1 Classic issuer-redirect (web)

1. Checkout Merchant → Auswahl giropay.
2. Liste der Banken → Umleitung an Online-Bank → SCA/Bestätigung.
3. Return to merchant site with status (success/pending/failed/canceled/expired).
4. Warten auf Webhook/Registry über den tatsächlichen Kredit (Siedlung).

3. 2 App2App (mobile)

Auf dem Telefon öffnet der Merchant die Banking-App per Deeplink/Intent → Bestätigung → Rückgabe.
Der Umsatz ist in der Regel höher; Fallback auf Web-Umleitung erforderlich.

3. 3 QR/Pay-by-Link

PSP kann einen dynamischen QR/Link mit Summe und Referenz geben (praktisch für Rechnungen/offline).
Der Benutzer scannt den Code und bestätigt in der Bank gemäß dem obigen Schema.

3. 4 „Erste Zahlung → Mandat“

Bei wiederkehrenden Abrechnungen wird giropay oft als erste Zahlung mit SCA und dann als SEPA-Lastschrift-/Open-Banking-Mandat für spätere Abbuchungen verwendet.

4) Status und Berechnungen (Authorization vs settlement)

Online-статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
„Pending“ bedeutet, dass die Bank/der Anbieter die Durchführung noch bestätigt oder ein Kredit ansteht.
Siedlung: tatsächliche Gutschrift auf PSP/Bank-Berichte (normalerweise T + 0/T + 1; in einigen Fällen länger).
Verwenden Sie für risikosensible Dienstleistungen das Modell „bedingte Erfüllung“ vor der bestätigten Einschreibung.

5) Retouren und Dispute

Es gibt keine Charjbacks. Retouren sind neue Kreditgeschäfte vom Händler an den Zahler (Teilretouren sind möglich).
Die Rückgabefristen sind Bank (T + 0/T + 1/T + 2, je nach Kanal).
Dispute/Beschwerden - über OS-Verfahren PSP und Bank des Zahlers; Vorbereitung von Auftragsprotokollen, Proof-of-Delivery/Dienstleistungen.

6) Grenzen und Risikorichtlinien

• Per-transaction, per-day/week у issuer’а.
• Neue Empfänger/Händler - reduzierte Schwellenwerte und/oder Verschlusszeiten.
• Kanal-/Velocity-Regeln, Geo-/Gerätesignale, Ausnahmen nach SCA (TRA/RA) liegen im Ermessen der Bank.

Praxis: Zahlen nicht hardcodieren. Führen Sie ein Verzeichnis der Limits nach Bank/Kanal, aktualisieren Sie es, zeigen Sie nachvollziehbare Ablehnungsgründe („Bank-/Kanallimit überschritten“) und schlagen Sie Alternativen vor (Scheck aufbrechen, andere Methode).

7) Kommissionen und Wirtschaft

Für giropay wird normalerweise ein Fix/Low-Prozentsatz an die PSP-Adresse angewendet; unterhalb der MDR-Karte.
Berücksichtigen Sie die Kosten für Pending/Expiries, ODR und Recon Support sowie die Hosted/Embedded Widgets und Reporting-Gebühren.

8) Abstimmung und Berichterstattung

Speichern Sie: 'paymentId/transactionId' des Anbieters, 'orderId', bank-issuer, Zeit, Kanal (Redirect/App2App/QR), Endstatus, Bankreferenz/UTR aus Fin-Reports.
Aktivieren Sie Webhooks zu Statusänderungen, täglichem Auto-Recon und periodischem Full-Recon (Einschreibungen/Retouren/Korrekturen).
Konfigurieren Sie die Alerts für Fehlsynchron- und SLA-Dashboards.

9) UX-Muster

Verzeichnis der Banken: Auto-Angebot/Suche, erinnern die letzte Bank.
Mobile first: Bieten Sie App2App an; fallback ist eine Web-Umleitung.
Fehler und Wiederholungen: klare Gründe (Limit, SCA-Ausfall, Timeout), Safe-Retry mit Idempotenz.
Quittung: Betrag, Datum/Uhrzeit, 'transactionId', Bank, Kanal, Link zum Sepport.

10) Wiederkehrende Abschreibungen

Verwenden Sie das Schema: erste Zahlung giropay → e-mandate (SEPA DD/Open Banking).
Im Mandat erfassen Sie das Limit per debit, die Periodizität, die Benachrichtigungen und die Verwaltung (pause/cancel).

11) Compliance und Sicherheit

PSD2/SCA wird in der Bank durchgeführt; Gerätebindung und Betrugsbekämpfung auf der issuer'a Seite.
DSGVO/PII-Minimierung: Nur notwendige Attribute speichern, PII verschlüsseln, Zugriff einschränken.
Webhooks: HMAC/nonce, replay protection, allowlist IP, audit log.

12) Sensible Vertikale (einschließlich iGaming)

Die Verfügbarkeit von giropay und die Limits hängen von den Richtlinien der PSP/Banken und dem lokalen Recht ab.
Erwarten Sie reduzierte Schwellenwerte, erweiterte KYC und mögliche Halter.
Planen Sie alternative Schienen (Karten, SEPA, andere Open-Banking-PIS), Smart-Routing nach Kundenprofil.

13) Merchant Integration: Optionen

1. Hosted/Embedded von PSP - Schnellstart, fertige Liste der Banken, Status, Fehler.
2. Server-to-Server + Redirect/App2App - bankeigene Auswahlseite, tiefe Fehlerbehandlung, eigener QR/Deep Link.
3. Rechnungen/Rau-by-Link/QR - praktisch für B2B/offline.

• API: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotenz (orderId + key), Retrays nach Exponenten, Dedup von Ereignissen.
• Verzeichnisse: Banken/Limits/Fehlercodes; SLA-Metriken nach issuer 'am.

14) „giropay Gateway“ Architektur

API-Layer (REST/GraphQL) für die Kasse.
Ereigniswarteschlangen: Status-Events → Abrechnung/CRM/Analysen.
Observability: Konversion über Banken/Kanäle, 'pending→success/expired', Latenz bis settlement.
Sicherheit: Tresor für Geheimnisse, IP-allowlist PSP, strikte Validierung von redirect-URIs, Anti-Replay-Token.

15) Checkliste Ausgabe in prod

1. Wählen Sie PSP/Kanal giropay (Hosted/Embedded/App2App/QR), vereinbaren Sie Tarife und SLAs.
2. Implementieren Sie' createPayment'+ Bankauswahl + Weiterleitung/Arr2Arr mit fallback.
3. Verbinden Sie Webhooks, Timeouts und Statuswiederholungen.
4. Richten Sie Recon (täglich + voll) ein, speichern Sie UTR/Fin-Referenzen.
5. Aktivieren Sie partial/full refunds und ODR-Vorschriften in sapport.
6. Bereiten Sie UX-Fehler-/Limitszenarien und alternative Methoden vor.
7. Decken Sie mobile Banken (iOS/Android) und die wichtigsten issuer's mit Tests ab.

Landmark-Karte

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Siedlung: häufiger T + 0/T + 1; Berücksichtigen Sie die bedingte Erfüllung vor dem Kredit.
Limits: per-txn/day/week bei issuer'a; für neue Empfänger - reduzierte Schwellenwerte.
Recurrent: via e-mandate/SEPA DD/Open Banking nach der ersten A2A-Zahlung.

Zusammenfassung

Wetten Sie auf Conversion- App2App/Embedded und dynamische QR/Pay-by-Link für Rechnungen/offline.
Trennen Sie Online-Bestätigung und tatsächliche Gutschrift in der Geschäftslogik.
Codieren Sie die Beträge nicht fest: Halten Sie Configy-Limits für Banken/Kanäle und aktualisieren Sie sie regelmäßig.
Bauen Sie einen Prozess um Webhooks + Recon, partielle Retouren und klare Verarbeitung von 'pending/expired' auf.