Swish Schweden: Mobile Zahlungen

1) Was ist Swish

Swish ist das nationale schwedische mobile A2A-Zahlungssystem (Betreiber Getswish AB) mit sofortigen 24/7. Der Nutzer bestätigt die Transaktionen über die BankID (SCA). P2P-Szenarien (pro Telefon), Business- P2M (online und offline), Spenden und Auszahlungen werden unterstützt.

• Adressierung über Telefonnummer (oder Merchant-Nummer/QR), ohne IBAN in UX.
• Sofortige Gutschrift auf das Bankkonto des Empfängers; Finalität der Banküberweisung.
• Geringe Reibung: App2App/QR, Bestätigung in BankID.
• Breite Bankabdeckung und hohe Popularität im Einzelhandel/Online.

2) Rollen und Produkte

Getswish (Schema) - Regeln, Kataloge und Marke.
Teilnehmende Banken - veröffentlichen/verbinden Swish, wenden Limits und Fraud an.
PSPs/Acquirer - verbinden Merchants (Swish Handel/Swish Företag), bieten APIs/SDKs, Berichte, settlement.

• Swish P2P - Transfers zwischen Privatpersonen.
• Swish Företag - Akzeptieren Sie Zahlungen offline (Schaufenster/POS).
• Swish Handel (Swish for e-commerce) ist ein Online-Checkout (QR/App2App/Link).
• Swish Donations - Kurznummern/Alias für Spenden.
• Swish Payouts/Disbursements - Massenzahlungen (über Bank/PSP).

3) Zahlungsströme

3. 1 P2P (push)

1. Der Absender wählt den Kontakt am Telefon aus → gibt den Betrag/die Nachricht ein.
2. Bestätigt in BankID (Face/Touch/Code).
3. Der Empfänger sieht sofort das Guthaben auf dem Konto und die Benachrichtigung in der App.

3. 2 P2M: e-commerce (Swish Handel)

• App2App/Deeplink: Auf dem Checkout öffnen wir die Swish/BankID-App → Bestätigung → Rückkehr zum Händler.
• QR per order: Es wird ein dynamischer QR generiert (Summe, orderId, Händlerreferenz); Der Kunde scannt mit der Swish-Kamera → bestätigt die BankID.

3. 3 POS/offline (Företag)

Dynamischer QR an der Kasse oder statische Swish-Nummer (manueller Betrag).
Bestätigung in BankID; Scheck - beim Händler und in der App des Kunden.

3. 4 Request-to-Rau/Rechnungen

Merchant sendet einen Zahlungslink/eine Zahlungsanfrage (per E-Mail/SMS/Messenger); Kunde bestätigt in BankID.

3. 5 Auszahlungen (Payouts)

Das Unternehmen sendet dem Kunden eine Geldüberweisung an eine Telefonnummer über die Bank/PSP; Anti-Fraud und Ausgangslimits werden angewendet.

4) Status und Timings

Typischer Status: „initiated“ → „pending“ → „success “/„ failed “/„ canceled “/„ expired“.
Bei einem Web-Checkout kann es zu Verzögerungen bei der Antwort der App/BankID kommen → Halten Sie Timeouts und Statuswiederholungen (Polling + Webhooks) bereit.
Settlement für den Händler ist ein Echtzeit-Bankkredit/in den nächstgelegenen Betriebsschlitz, abhängig von der Bank/PSP (für die Berichterstattung machen Sie noch einen Tagesrückruf).

5) Grenzen und Risikorichtlinien

• Per-transaction, per-day/24h; manchmal wöchentlich/monatlich.
• Neuer Empfänger/neuer Merchant - niedrigere Schwellenwerte/Verschlusszeit.
• Kanalgrenzen: P2P, E-Commerce (App2App/QR), POS, Payouts.
• Velocity/Device/Geo-Regeln und Risiko-Scoring auf Seiten der Bank.

6) Wirtschaft und Kommissionen

Die Kosten für den Händler sind in der Regel niedriger als die klassische Karts-MDR, aber die Bedingungen hängen von der Bank/PSP ab (fix/niedriger Prozentsatz, QR/SDK/Berichtsgebühr).
Legen Sie die Kosten für 'pending/expired' Support, Dispute, Recon und SLA Monitoring fest.

7) Retouren und Dispute (ODR)

Chargeback wie in den Karten fehlt. Return ist eine separate Kredittransaktion vom Händler zum Kunden (partielle Refunds werden unterstützt).
Die Fristen sind Bankfristen (in der Regel T + 0/T + 1).
Dispute - nach den Verfahren der Bank/PSP: Speichern Sie die Protokolle der Bestellung, Bestätigung der Erbringung der Dienstleistung/Lieferung, Übereinstimmung der Kundendaten.

8) Sicherheit und Compliance

SCA über BankID, Gerätebindung, SIM/Geräteprüfung durch die Bank.
PII-Minimierung: nur notwendige Attribute (Telefon/Referenzen) speichern, PII verschlüsseln; Zugang nach dem Prinzip der geringsten Privilegien.
Webhooks: HMAC/Nonce, Replay-Schutz, Zeitstempel und Event-Dedup.
Erfüllung der PSD2/GDPR und lokalen Anforderungen von Finansinspektionen.

9) Merchant-Integration

Varianten

1. Hosted/Embedded von PSP - schneller Start, App2App/QR aus der Box, Status und Fehler.
2. Server-to-Server + App2App/QR - eigene UX, dynamische QR-per-Order, tiefe Fehler-/Wiederholungsverarbeitung.
3. Pay-by-Link/Rechnung - Senden Sie einen Link/Anfrage; bequem für Dienstleistungen und B2B.

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

10) Abstimmung und Berichterstattung

Loggen: 'paymentId/transactionId' des Anbieters, 'orderId', Kanal (App2App/QR/Link/POS), Empfängernummer, Status, Betrag/Währung, Zeitstempel, UTR.
Von PSP/Bank: Einschreibungs-/Rückgabe-/Korrekturregister, späte Statusaktualisierungen.
Schalten Sie Alerts für Fehlzündungen und Anomalien ein (doppelte Abschreibungen, hängend „pending“).

11) UX-Muster

Mobile-first: Auto-Angebot App2App; auf dem Desktop gibt es einen großen dynamischen QR mit Timer.
Transparente Fehler: Limit, BankID-Fehler, Timeout; sichere Wiederholung und Alternative (Karte/SEPA/A2A eines anderen Anbieters).
Quittung: Betrag, Zeit, 'transactionId', Kanal, UTR, Saport Kontakte.
Aktivitäts-Timer für QR/Anfragen und Wiederherstellungsszenario nach Ablauf.

12) Recurrent und Mandate

Basic Swish ist ein One-Off mit SCA. Für Abonnements wird ein Bündel verwendet: die erste Zahlung von Swish → e-mandate/Autogiro/Open-Banking PIS für weitere Abschreibungen (Limit/Periodizität/Benachrichtigungen, Mandatsverwaltungsbildschirm).

13) Hochrisikovertikale (einschließlich iGaming)

Die Verfügbarkeit von Kanälen und Limits hängt von den Richtlinien der Bank/PSP und dem lokalen Recht ab.
Erwarten Sie reduzierte Schwellenwerte, erweiterte KYC und mögliche Halter.
Planen Sie alternative Schienen (Karten, SEPA, andere PIS) und Smart-Routing nach Risiko/Bank/Kanal.

14) „Swish Gateway“ Architektur

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: Kanalkonvertierung (App2App/QR/POS/Link), Anteil 'pending→expired', Zeit bis zur Einstellung/Rückgabe.

15) Checkliste Ausgabe in prod

1. Verbinden Sie die PSP/Bank mit Swish Handel/Företag; Vereinbaren Sie Tarife/SLAs und Kanäle (App2App/QR/POS/Link).
2. Implementieren Sie' createPayment'+ dynamische QR/App2App, Fehler-/Grenzbildschirme.
3. Verbinden Sie Webhooks, Idempotenz, Retrays und Event-Dedup.
4. Richten Sie Recon (täglich + voll) ein, speichern Sie UTR/Fin-Referenzen.
5. Aktivieren Sie partielle/vollständige Refund- und ODR-Verfahren.
6. Führen Sie SLA-Dashboards und Konversions-/Latenz-/Hängestatusalerts aus.
7. Führen Sie e2e-Tests mit den wichtigsten Banken/Geräten, POS (falls relevant) durch.

Landmark-Karte nach Limits

Per-txn/24h/7d: Speichern Sie in config und überprüfen Sie vor dem Start.
Neue Empfänger/Händler: niedrigere Schwellenwerte/Verschlusszeit.
Kanäle: separate Limits für P2P, E-Commerce (App2App/QR), POS, Payouts.
Velocity/Risiko: Die Betrugsbekämpfung der Bank kann Transaktionen sanft ablehnen/verlangsamen.

Zusammenfassung

Für Online - App2App + Dynamic QR, für Offline - QR/POS (Företag), für Transfers - P2P auf das Telefon.
Trennen Sie die Online-Bestätigung und die endgültige Gutschrift in der Geschäftslogik; bauen um webhooks + recon und partielle refunds.
Legen Sie keine Beträge fest: Unterstützen Sie Config Limits über Banken/Kanäle mit regelmäßiger Aktualisierung.
Für Abonnements - Bündel erste Swish → Mandat mit transparenter Verwaltung und Benachrichtigungen.