Bizum Spanien: Sofortüberweisungen

1) Bizum Kontext und Positionierung

Bizum ist ein spanisches Interbank-System für Sofortüberweisungen und Zahlungen, das in die Anwendungen lokaler Banken integriert ist. Arbeitet 24/7, deckt P2P (pro Telefonnummer), P2M (Zahlung in E-Commerce/Offline) sowie Spenden/Spenden und Rechnungen ab. Die Bestätigung erfolgt in der Banking-App (SCA/PSD2), die Gelder bewegen sich auf Bankschienen mit sofortiger Autorisierung und schneller Gutschrift.

• Adressierung per Telefon (alias), ohne IBAN in UX.
• Sofortigkeit und Finalität der Überweisung (Chargeback wie in den Karten fehlt).
• P2M: Zahlung auf der Website, in der App, offline (QR/Bizum-Code).
• Request-to-Pay: „Geldanforderung“ an Kontakte oder Kunden.

2) Teilnehmer und Rollen

Bizum-Schema/Interbank-Switch - Regeln, Routing, Teilnehmerverzeichnisse.
Die Emissionsbanken sind mobile Apps, SCAs, Betrugsbekämpfung und Limits.
PSP/Acquirer - Verbinden Sie den Händler mit Bizum P2M, API/SDK, Reporting und Berechnungen.
Merchant - Initiiert eine Zahlung/Anfrage, verarbeitet Status, führt Retouren und Abstimmungen durch.
Zahler/Empfänger - Bestätigt Transaktionen in der Bank-App.

3) Modi und benutzerdefinierte Skripte

3. 1 P2P „pro Telefon“

Der Absender wählt den Kontakt (Telefonnummer) aus → gibt den Betrag ein → bestätigt in seiner Banking-App → der Empfänger sieht das Sofortguthaben auf dem Konto.
Für neue Empfänger sind reduzierte Schwellenwerte/dop möglich. Überprüfungen.

3. 2 P2M (Zahlung an den Händler)

E-Commerce: An der Kasse wird die Bizum-Telefonnummer eingegeben oder die Banking-App per Deeplink geöffnet; Bestätigung - Push/SCA.
Offline/QR: Dynamischer QR per Order (Betrag + OrderId), Scannen in der Banking-App → Bestätigung → Online-Status des Merchants.
Bizum-Code: Der Merchant kann einen kurzen Code/Alias für die Zahlung am Point of Sale anzeigen.

3. 3 Request-to-Pay/Rechnungen

Der Merchant erstellt eine Zahlungsaufforderung (Betrag/Verwendungszweck/Ablaufdatum) → der Kunde bestätigt in seiner Banking-App → die Gelder werden als reguläre Bizum-Überweisung gutgeschrieben.

3. 4 Zu zahlende Spenden und Rechnungen

Short Codes/Alias für wohltätige Zwecke und Utility/Small Payments werden unterstützt.

4) Status

„initiated“ → „pending“ → „success “/„ failed “/„ canceled “/„ expired“.
Für Abfragen sind die zusätzlichen Zustände' requested '/' expired'.

5) Grenzen und Risikorichtlinien

Es gibt keine einzige „Super-Circuit“ -Obergrenze: Banken und/oder PSPs setzen Grenzen, oft abhängig von KYC-Level, Geschichte und Kanal.

Per-Transaktion, per-day/24h, manchmal wöchentlich/monatlich.
Neuer Empfänger/Merchant - reduzierte Schwellenwerte, Verschlusszeit oder Bestätigung.
Kanal/Skript: Separate Limits für P2P, P2M (Web/App/QR), Request-to-Pay.
Velocity/Device/Geo-Regeln auf der Seite der Bank.

6) Wirtschaft und Kommissionen

Für einen Händler ist Bizum in der Regel billiger als ein Karts-MDR, aber die Bedingungen hängen von der PSP/Bank ab.
Planen Sie die Kosten für Integration/SDK, 'pending/expired' Verarbeitung, Support/ODR und recon.

7) Retouren und Dispute

Chargeback (wie in den Karten) fehlt für A2A. Return - Neue Kredittransaktion vom Händler zum Zahler (partielle Refunds werden unterstützt).
Die Fristen sind Bankfristen (oft T + 0/T + 1).
Dispute/Beschwerden - durch PSP-Verfahren und Bank; Vorbereitung von Bestellprotokollen, Bestätigungen und Kommunikation mit dem Kunden.

8) Sicherheit und Compliance

PSD2/SCA in der Banking-App: PIN/Biometrie, Gerätebindung, risikobasierte Authentifizierung bei der Bank.
PII-Minimierung: Speichern Sie nur die erforderlichen Attribute (Telefon/Refs), verschlüsseln Sie PII, beschränken Sie den Zugriff.
Webhooks: HMAC/Nonce, Replay-Schutz, Audit-Log und Retrai.

9) Merchant-Integration

Varianten

1. Hosted/Embedded von PSP - Schnellstart: Bizum-Formulare, Status, Fehler aus der Box.
2. Server-to-Server + App2App/QR - eigene UX, dynamische QR-per-Order, tiefe Fehlerbehandlung.
3. Pay-by-Link/Request-to-Pay - Konto per Link (E-Mail/SMS/Messenger), Bestätigung bei der Bank.

• API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
• Idempotenz ('orderId' + Schlüssel), exponentielle Retrays, Dedup von Ereignissen.
• Recon: täglicher Auto-Recon + periodischer Full-Recon; Speicherung von UTR/fin-Referenzen.
• SLA-Dashboards: Konvertierung, „pending→success/expired“, Latenz vor der Einschreibung.

10) Abstimmung und Berichterstattung

Loggen: 'paymentId/transactionId', 'orderId', Channel (P2P/P2M/QR/App2App/Request), Bank des Zahlers, Status, Betrag/Währung, Timestamp, UTR/Banking Link.
Von PSP: Register für Einschreibungen/Retouren/Korrekturen, späte Statusaktualisierungen.

11) UX-Muster

Mobile-first: für Mobile - App2App; für Desktop - Dynamic QR.
Transparente Fehler: Limit, Timeout, SCA-Ausfall; sichere Wiederholung + Alternative (Karte/SEPA/andere A2A).
Quittung: Betrag, Zeit, 'transactionId', Kanal, UTR, Support-Kontakte.
Ablaufdatum der Anfrage/QR: Zeigen Sie den Timer und das Wiederherstellungsszenario an.

12) Recurrent und Mandate

Basic Bizum - One-off mit SCA. Für Abonnements verwenden Sie ein Bündel: die erste Zahlung von Bizum → e-mandate/SEPA DD/Open-Banking für nachfolgende Abbuchungen (Limit/Periodizität/Benachrichtigungen, Mandatsverwaltungsbildschirm).

13) Hochrisikovertikale (einschließlich iGaming)

Die Verfügbarkeit/Grenzen hängen von der Bank-/PSP-Politik und dem lokalen Recht ab.
Erwarten Sie niedrigere Schwellen, verstärkt durch KYC, mögliche Halter.
Planen Sie alternative Schienen (Karten, SEPA, andere PIS) und Smart-Routing nach Risiko.

14) Architektur „Bizum Gateway“

API-Layer (REST/GraphQL) für Kasse und Backophis.
Ereigniswarteschlangen: Status-Events → Abrechnung/CRM/Analysen.
Sicherheit: Tresor für Geheimnisse, IP-allowlist PSP, strikte Validierung von redirect-URIs, Anti-Replay-Token.
Observability: Metriken nach Kanal (App2App/QR/Request), 'pending→success/expired', Zeit bis zur Einstellung.

15) Checkliste Ausgabe in prod

1. Unterschreiben Sie den Bizum-Kanal bei der PSP/Bank; Kanäle auswählen (App2App/QR/Request).
2. Implementieren Sie' createPayment '/' requestToPay', dynamische QR, Fehler/Limits Bildschirme.
3. Verbinden Sie Webhooks, Idempotenz, Retrays und Event-Dedup.
4. Richten Sie Recon (täglich + voll) ein, speichern Sie UTR/Fin-Referenzen.
5. Unterstützen Sie partielle/vollständige Refund- und ODR-Verfahren.
6. Führen Sie SLA-Dashboards und Konversions-/Latenzalarme aus.
7. Führen Sie e2e-Tests mit den wichtigsten Banken/Geräten durch.

Landmark-Karte nach Limits

Per-txn/24h/7d: in config aufbewahren, vor dem Start prüfen.
Neue Empfänger/Händler: niedrigere Schwellenwerte/Verschlusszeit.
Kanäle: Separate Limits für P2P, P2M (Web/App/QR), Request-to-Pay.
Velocity/Risiko: Die Betrugsbekämpfung der Bank kann Transaktionen sanft ablehnen/verlangsamen.

Zusammenfassung

Für Online - App2App + Dynamic QR, für Offline - QR/Code Bizum, für Transfers - P2P nach Nummer.
Trennen Sie die Online-Bestätigung und die endgültige Gutschrift in der Logik; bauen um webhooks + recon und partielle refunds.
Legen Sie keine Beträge fest: Halten Sie Limits über Banken/Kanäle hinweg ein und aktualisieren Sie sie regelmäßig.
Für Abonnements - Bündel erste Bizum → Mandat mit transparenter Verwaltung und Benachrichtigungen.