Sofort/Klarna: pay-by-bank

1) Was ist Sofort/Klarna Pay-by-Bank

Sofort (jetzt Klarna Pay Now/Pay-by-Bank) ist ein A2A-Tool, mit dem ein Käufer eine Bestellung direkt von seinem Bankkonto über eine Online-Bank/Mobile-App bezahlen kann. Der Stream basiert typischerweise auf einem SCA-Bestätigungs- issuer-redirect/App2App (PSD2), und der Merchant erhält eine Online-Autorisierung (Erfolg) und dann einen Bankkredit aus den Berichten/Berechnungen des Anbieters.

• Niedrige Kosten im Vergleich zu Kartons MDR.
• Online-Status (Erfolg/Misserfolg) fast sofort, während die Gutschrift nicht immer sofort ist (normalerweise T + 1/T + 2).
• Breite Geographie in der EU/EWR (Deutschland/Österreich besonders stark), Unterstützung von Dutzenden von Emissionsbanken.
• Das Minimum der Zahlungsdetails beim Käufer ist die Wahl der Bank und die Bestätigung.

2) Rollen und Teilnehmer

Klarna/Sofort (Schema/Anbieter): Routing zu Banken, Status, Berichte, Berechnungen, Retouren.
Issuer (Zahlerbank): SCA, Abbuchungsbestätigung, Limits/Fraud.
Händler PSP/Acquirer: Merchant-Verbindung, API/SDK, Webhooks und Recon.
Händler: Zahlungseinleitung, Status-/Retourenabwicklung, Abgleich.

3) Zahlungsströme: Redirect und App2App

3. 1 Classic redirect

1. Checkout-Händler → die Wahl „Pay by bank (Sofort/Klarna)“.
2. Liste der Banken → Weiterleitung an die Online-Bank (oder die Hosted-Seite des Anbieters) → SCA.
3. Die Bank bestätigt die Zahlung → die Rückgabe auf mertschanta mit dem Status (success/failed/canceled/pending).
4. Merchant zeichnet die Bestellung als „bezahlt/erwartet“ auf, wartet auf Webhook/Immatrikulationsbericht.

3. 2 App2App / Mobile

Auf mobilen Geräten öffnet der Merchant die Banking-App von deeplink/intent → Bestätigung → Rückgabe gemäß dem obigen Schema.
Umsatz höher, Reibung niedriger; Halten Sie Fallback auf Web-Umleitung.

3. 3 Request-to-Pay/Embedded Optionen

Bei einer Reihe von Banken ist die Anfrage-to-pay/PIS über die Schnittstellen des Anbieters verfügbar (der Käufer erhält eine Anfrage in der Bank-App).
Embedded-Widgets von PSP vereinfachen die Liste der Banken, Fehler und Status.

4) Limits und Verhalten der Banken

• Per-Transaktion, per-Tag/Woche bei der Bank des Zahlers.
• Neue Empfänger/Merchants - reduzierte Schwellenwerte, Verschlusszeiten möglich.
• Channel (Mobile/Web), Velocity-Regeln, Geo-/Device-Signale.
• In einzelnen Ländern/Banken sind - je nach Bank - Schwellenwerte für SCA-Ausnahmen (RA, TRA) möglich.

5) Status und Einschreibung (Authorization vs settlement)

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Pending ist mit verzögerter Bestätigung oder asynchroner Überprüfung möglich.
Siedlung: Der tatsächliche Kredit kommt aus den Berichten des Anbieters (normalerweise T + 1/T + 2 Bankarbeitstage; je nach Land/Bank/Clearingsystem).
Verwenden Sie für kritische Dienste das Modell „Autorisierung ⇒ bedingte Ausführung“, bevor Sie die Einschreibung bestätigen.

6) Retouren, Teilretouren und Dispute

Chargeback (wie in den Karten) fehlt. Retouren sind neue Kreditgeschäfte über den Anbieter an den Zahler.
Partielle Refunds werden unterstützt.
Die Fristen für die Gutschrift der Rückerstattung sind Banküberweisung (T + 1/T + 2).
Die Dispute/Reklamationen erfolgen nach dem ODR-Verfahren des Anbieters + über die Bank des Zahlers; Vorbereitung von Auftragsprotokollen, Proof-of-Delivery/Dienstleistungen.

7) Kommissionen und Wirtschaft

Normalerweise fix/niedriger Prozentsatz mit Transaktion + Plattformfunktionsgebühr (gehostete Checkout, Berichte, ODR).
Berücksichtigen Sie die Supportkosten (pending/expiries), Risikovorfälle und Transaktionskosten von recon.

8) Abstimmung und Berichterstattung (Reconciliation)

Speichern Sie' paymentId/transactionId 'des Anbieters,' orderId', Bank-issuer, Zeitstempel, Status.
Aktivieren Sie Webhooks über Statusänderungen und tägliches Auto-Recon.
Kombinieren Sie Online-Events (Erfolg/Pending) mit Finanzberichten (Gutschriften/Retouren/Korrekturen).
Bewahren Sie die UTR/Bankreferenz aus dem Bericht für jede Transaktion auf.

9) UX-Praktiken

Verzeichnis der Banken: Füllen Sie die letzte Auswahl vor, sortieren Sie nach Popularität/Bank des Geräts.
Mobile-first: Bieten Sie App2App, Fallback - Web-Umleitung.
Fehler und Wiederholung: Lassen Sie uns klare Gründe (Limit, SCA-Ausfall, Timeout), Wiederholungsknopf und Alternativen nennen.
Idempotenz: 'orderId' + Idempotenz-Schlüssel für sichere Wiederholungen.
Quittung: Betrag, Datum/Uhrzeit, 'transactionId', Bank, Kanal (App2App/Redirect).

10) Wiederkehrende Abschreibungen und Mandate

Der klassische Sofort ist ein Ein-Aus. Für wiederkehrende Modelle wird ein Bündel verwendet: die erste Zahlung A2A → e-mandate/SEPA DD/Open Banking PIS für die Zukunft.
Verwalten Sie Mandate (Limit, Häufigkeit, Benachrichtigungen), speichern Sie Akzeptanzprotokolle.

11) Compliance, Sicherheit, Daten

PSD2/SCA: Bestätigung in der Bank, Gerätebindung, Betrugsbekämpfung der Bank.
PII-Minimierung: Speichern Sie nur die erforderlichen Attribute; PII verschlüsseln; HMAC-Signaturen von Web-Hooks.
DSGVO/Logs: Einwilligungen, Recht auf Löschung, Prüfung von Änderungen.

12) Hochrisikovertikalen (einschließlich iGaming)

Die Verfügbarkeit von Pay-by-Bank für einige Kategorien ist durch den Anbieter/die Banken nach internen Richtlinien und lokalem Recht begrenzt.
Erwarten Sie reduzierte Limits, zusätzliche CUS/Finmonitoring, mögliche Hold' s.
Halten Sie alternative Schienen (Karten, SEPA, Open Banking A2A, Gutscheine) und Verkehrssegmentierung.

13) Merchant Integration: Optionen

1. Hosted/Embedded от PSP/Klarna

Schnellstart: Bank-Auswahl-Widget, Status, Fehler, Webhooks „out of the box“.

2. Server-to-Server + redirect/App2App

Mehr Kontrolle: eigene Seite der Banken, feine Fehlerbehandlung, eigener QR/Deep Link.

3. Rechnungen/Request-to-Pay

Senden Sie eine Zahlungsanforderung (E-Mail/SMS/Link), bequem für B2B/Dienstleistungen.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotenz und Tabelle dedupe nach 'orderId'.
• Retrays exponentiell Status zu erhalten, dead-letter für instabile Antworten.
• Verzeichnisse: Banken/Länder, Limits/Fehlercodes, SLA-Metriken nach issuer 'am.

14) Architektur „Sofort/Klarna Gateway“

API-Schicht (REST/GraphQL) für die Kasse.
Ereigniswarteschlangen: Status-Events → Abrechnung/CRM/Analysen.
Observability: Bank-/Kanalkonvertierung, „pending→success/expired“, Latenz, SCA-Ausfall.
Sicherheit: Tresor für Geheimnisse, IP-allowlist-Anbieter, Anti-Replay-Token, strikte Redirect-URI-Validierung.

15) Checkliste Ausgabe in prod

1. Wählen Sie einen PSP/Klarna/Sofort-Kanal mit der gewünschten Bankgeographie.
2. Implementieren Sie' createPayment'+ Bankauswahl + redirect/App2App mit fallback.
3. Verbinden Sie Webhooks, Idempotenz, Timeouts und Statuswiederholung.
4. Richten Sie Recon (täglich + voll) ein, speichern Sie UTR/Fin-Referenzen.
5. Aktivieren Sie partial/full refunds und ODR-Reglement im Sapport.
6. Bereiten Sie UX-Fehler-/Limitszenarien und alternative Methoden vor.
7. Testen Sie mobile Banken (iOS/Android) und die wichtigsten issuer's in den Zielländern.
8. Führen Sie ein Limit-Verzeichnis und eine Incident Status-Seite.

Landmark-Karte

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Siedlung: häufiger T + 1/T + 2; Planen Sie eine „bedingte Erfüllung“ vor dem Darlehen.
Limits: per-txn/day/week bei issuer'a; für neue Empfänger - unten.
Recurrent: via e-mandate/SEPA DD/Open Banking.

Zusammenfassung

Für die Konvertierung - App2App/Embedded, für die Nachhaltigkeit - klare Webhooks + Recon.
Trennen Sie Online-Bestätigung und tatsächliche Gutschrift (T + 1/T + 2) in der Geschäftslogik.
Fixieren Sie keine starren Beträge: Bank-/Ländergrenzen + regelmäßige Aktualisierung.
Verwenden Sie für Abonnements die erste A2A-Zahlung → ein Mandat mit verständlicher UX-Verwaltung und Limits.