Swish Szwecja: płatności mobilne

1) Co to jest Swish

Swish jest krajowym szwedzkim systemem płatności mobilnych A2A (operator Getswish AB) z 24/7 natychmiastowymi transferami. Użytkownik potwierdza transakcje za pośrednictwem BankID (SCA). Obsługiwane są scenariusze P2P (na telefon), P2M biznesowe (online i offline), darowizny i płatności.

• Adresowanie numerem telefonu (lub numerem handlowca/QR), bez IBAN w UX.
• Błyskawiczny kredyt na rachunek bankowy odbiorcy; ostateczność przelewu bankowego.
• Niskie tarcie: App2App/QR, potwierdzenie w BankID.
• Szeroki zasięg bankowy i wysoka popularność w handlu detalicznym/online.

2) Role i produkty

Getswish (schemat) - zasady, katalogi i marki.
Uczestniczące banki - wystawiają/łączą Swish, stosują limity i zwalczają oszustwa.
PSP/nabywcy - połączyć handlowców (Swish Handel/Swish Företag), dostarczyć API/SDK, raporty, rozliczenie.

• Swish P2P - transfery między osobami.
• Swish Företag - akceptuj płatności offline (showcase/POS).
• Swish Handel (Swish dla e-commerce) - realizacja transakcji online (QR/App2App/Link).
• Swish Donations - krótkie numery/pseudonimy dla darowizn.
• Swish Payouts/Wypłaty - masowe wypłaty (za pośrednictwem banku/PSP).

3) Przepływy płatnicze

3. 1 P2P (push)

1. Nadawca wybiera kontakt telefoniczny → wpisuje kwotę/wiadomość.
2. Potwierdza w BankID (Face/Touch/code).
3. Odbiorca natychmiast widzi kredyt na koncie i powiadomienie w aplikacji.

3. 2 P2M: handel elektroniczny (Swish Trade)

• App2App/Deeplink: przy wymeldowaniu otwórz wniosek Swish/BankID → potwierdzenie → powrót do handlowca.
• QR na zamówienie: wygenerowany jest dynamiczny QR (suma, α Id, odniesienie handlowca); klient skanuje z aparatem Swish → potwierdza z BankID.

3. 3 POS/offline (Företag)

Dynamiczny QR przy realizacji transakcji lub statyczny numer Swish (kwota ręczna).
Potwierdzenie w BankID; sprawdź - u handlowca i w aplikacji klienta.

3. 4 Żądanie do Rau/Faktury

Handlowiec wysyła link/żądanie płatności (w wiadomości e-mail/SMS/messenger); klient potwierdza w BankID.

3. 5 Wypłaty

Firma wysyła klientowi przelew pieniężny na numer telefonu za pośrednictwem banku/PSP; stosuje się limity zwalczania nadużyć finansowych i wychodzących.

4) Statusy i terminy

Typowe statusy są 'zainicjowane' → 'w oczekiwaniu' → 'sukces '/' nieudany '/' anulowany '/' wygasł'.
W przypadku sprawdzenia strony internetowej może dojść do opóźnień w odpowiedzi aplikacji/BankID → utrzymać harmonogram i powtórzenie stanu (sondaż + haki internetowe).
Rozrachunek dla handlowca - kredyt bankowy w czasie rzeczywistym/do najbliższego przydziału czasu na start lub lądowanie w zależności od banku/dostawcy usług płatniczych (do zgłaszania, wykonaj dzienny wywiad i tak).

5) Limity i polityka ryzyka

• Na transakcję, dziennie/24h; czasami co tydzień/miesiąc.
• Nowy odbiornik/nowy handlowiec - obniżone progi/prędkość migawki.
• Limity kanałów: P2P, e-commerce (App2App/QR), POS, wypłaty.
• Prędkość/urządzenie/geo-zasady i ocena ryzyka po stronie banku.

6) Ekonomia i prowizje

Koszt dla handlowca jest zwykle niższy niż klasyczny MDR karty, ale warunki zależą od banku/PSP (fix/niskie odsetki, opłata za QR/SDK/raporty).
Opłata za „oczekujące/wygasłe” wsparcie, spory, recon i monitorowanie SLA.

7) Zwroty i spory (ODR)

Brak obciążenia zwrotnego, jak w kartach. Zwrot - osobna transakcja kredytowa od handlowca do klienta (obsługiwane są częściowe zwroty).
Warunki - bank (zwykle T + 0/T + 1).
Spory - zgodnie z procedurami banku/PSP: przechowywanie dzienników zamówienia, potwierdzenie obsługi/dostawy, zgodność danych klienta.

8) Bezpieczeństwo i zgodność

SCA za pośrednictwem BankID, powiązanie urządzenia, sprawdzanie SIM/urządzenia przez bank.
Minimalizacja PII: przechowywać tylko niezbędne atrybuty (telefon/referencje), szyfrować PII; dostęp - zgodnie z zasadą najmniejszych przywilejów.
Haki internetowe: HMAC/nonce, ochrona przed powtórzeniem, znaczniki czasu i dedup zdarzeń.
Zgodność z Finansinspektionen PSD2/GDPR i lokalnymi wymaganiami.

9) Integracja handlowców

Opcje

1. Hosted/Embedded by PSP - szybki start, App2App/QR poza pudełkiem, statusy i błędy.
2. Server-to-Server + App2App/QR - natywny UX, dynamiczny QR na zamówienie, głębokie przetwarzanie błędów/powtórzeń.
3. Pay-by-Link/Faktura - wysłanie linku/żądania; wygodne dla usług i B2B.

• API: Płatność, zwrot, płatność (jeśli jest dostępna od PSP), hak internetowy, uzgodnienie.
• Idempotencja (klucz ' Id' +), przekładnie wykładnicze, dedup zdarzeń.
• Recon: dzienny auto-recon + okresowy pełny zwiad; Przechowywać UTR/referencje bankowe
• Deski rozdzielcze SLA: konwersja, „w oczekiwaniu → sukces/wygasła”, opóźnienie przed zapisaniem.

10) Pojednanie i sprawozdawczość

Dziennik: "Id/ Id" dostawcy, " Id', kanał (App2App/QR/Link/POS), numer odbiorcy, status, kwota/waluta, znacznik czasu, UTR.
Z PSP/banku: rejestry kredytów/zwrotów/korekt, późne aktualizacje stanu.
Należy dodać wpisy dotyczące anomalii i anomalii (podwójne odpisy, wiszące „oczekujące”).

11) Wzory UX

Mobile-first: App2App auto-offer; na pulpicie - duży dynamiczny QR z zegarem.
Przejrzyste błędy: limit, awaria BankID, timeout; bezpieczny powtórzenie i alternatywa (card/SEPA/A2A innego dostawcy).
Odbiór: ilość, czas, ' Id', kanał, UTR, kontakty wsparcia.
Czas akcji dla skryptu QR/żądań i odzyskiwania wygaśnięcia.

12) Powtarzanie i mandaty

Podstawowy Swish - jednorazowy z SCA. W przypadku subskrypcji używany jest pakiet: pierwsza płatność Swish → e-mandat/Autogiro/Open-Banking PIS dla dalszych obciążeń (limit/częstotliwość/powiadomienia, ekran zarządzania biletami).

13) Piony wysokiego ryzyka (w tym iGaming)

Dostępność kanałów i limity zależą od polityki banku/PSP i prawa lokalnego.
Spodziewaj się obniżonych progów, przedłużonego KYC i możliwych uchwytów.
Planuj alternatywne szyny (karty, SEPA, inne PIS) i inteligentne trasy przez ryzyko/bank/kanał.

14) architektura „Swish Gateway”

warstwa API (REST/GraphQL) do kasy i koparki.
Kolejki wydarzeń: zdarzenia stanu → rozliczenie/CRM/analityka.
Bezpieczeństwo: skarbiec dla tajemnic, IP-permlist PSP, ścisłe przekierowanie-walidacja URI, żetony anty-replay.
Obserwowalność: konwersja kanału (App2App/QR/POS/Link), ułamek 'oczekujących → wygasł', czas do rozliczenia/zwrotu.

15) Lista kontrolna wyjściowa

1. Podłącz PSP/bank ze Swish Handel/Företag; uzgodnić ceny/SLA i kanały (App2App/QR/POS/Link).
2. Implementacja QR/App2App dynamicznych ", ekranów błędów/limitów" Czeka płatność "+.
3. Podłącz haki internetowe, idempotencję, retrai i event dedup.
4. Skonfigurować recon (dziennie + pełny), UTR/fin referencje przechowywania.
5. Włącz częściowe/pełne refundacje i procedury ODR.
6. Uruchom deski rozdzielcze SLA i wpisy do statusów konwersji/opóźnienia/zawieszenia.
7. Przeprowadzanie testów e2e z głównymi bankami/urządzeniami, POS (w stosownych przypadkach).

Karta referencyjna limitu

Per-txn/24h/7d: przechowywać w konfiguracji i sprawdzać przed rozpoczęciem.
Nowi odbiorcy/handlowcy: obniżone progi/prędkość migawki.
Kanały: oddzielne limity dla P2P, e-commerce (App2App/QR), POS, wypłaty.
Prędkość/ryzyko: Bank może delikatnie odchylić/spowolnić operacje.

Wznów streszczenie

Dla online - App2App + dynamiczny QR, dla offline - QR/POS (Företag), dla transferów - P2P do telefonu.
Oddzielne potwierdzenie online i ostateczny kredyt w logice biznesowej; zbudować wokół webhooks + recon i częściowe zwroty.
Nie ustalaj kwot: utrzymuj konfiguracje limitów przez banki/kanały z regularną aktualizacją.
Dla abonamentów, pierwszy pakiet Swish → bilet z przejrzystym zarządzaniem i powiadomieniami.