Sofort/Klarna: płatny przez bank

1) Co to jest Sofort/Klarna Pay-by-Bank

Sofort (obecnie Klarna Pay Now/Pay-by-Bank) jest narzędziem A2A, które pozwala kupującemu zapłacić za zamówienie bezpośrednio z ich rachunku bankowego za pośrednictwem internetowego banku/aplikacji mobilnej. Strumień jest zazwyczaj zbudowany na issuer-redirect/App2App potwierdzającym SCA (PSD2), a handlowiec otrzymuje autoryzację online (sukces), a następnie kredyt bankowy na podstawie raportów/obliczeń dostawcy.

• Niski koszt w stosunku do MDR kart.
• Status online (sukces/porażka) prawie natychmiast, podczas gdy zasilanie środków nie zawsze jest natychmiastowe (zwykle T + 1/T + 2).
• Szeroka geografia w UE/EOG (Niemcy/Austria jest szczególnie silna), wsparcie dla dziesiątek banków emitujących.
• Minimalne szczegóły płatności od kupującego - wybór i potwierdzenie banku.

2) Role i uczestnicy

Klarna/Sofort (system/dostawca): routing do banków, statusy, raporty, rozliczenia, zwroty.
Emitent (bank płatnika): SCA, potwierdzenie umorzenia, limity/przeciwdziałanie oszustwom.
Handlowiec PSP/Acquirer: połączenie handlowca, API/SDK, haki internetowe i recon.

Handlowiec - Inicjowanie płatności, status procesu/zwroty, uzgodnienie

3) Przepływy płatnicze: przekierowanie i App2App

3. 1 Klasyczne przekierowanie

1. Handlowiec realizacji transakcji → wybierz „Zapłać przez bank (Sofort/Klarna)”.
2. Lista banków → przekieruj do banku internetowego (lub na stronę hostingu dostawcy) → SCA.
3. Bank potwierdza płatność → powrót do handlowca ze statusem (sukces/nieudany/anulowany/oczekujący).
4. Zlecenie ewidencji handlowców jako „płatne/oczekujące”, czeka na raport z rejestracji.

3. 2 App2App/Telefon komórkowy

Na urządzeniach mobilnych handlowiec otwiera aplikację bankową przez deeplink/intent → potwierdzenie → zwrot zgodnie z powyższym systemem.
Konwersja jest wyższa, tarcie jest niższe; utrzymać awaryjny na przekierowaniu sieci.

3. 3 Opcje żądania zapłaty/wbudowane

Niektóre banki posiadają żądanie zapłaty/PIS dostępne za pośrednictwem interfejsów dostawcy (kupujący otrzymuje żądanie od banku aplikacji).
Wbudowane widgety z PSP upraszczają listę banków, błędów i statusów.

4) Ograniczenia i zachowanie banków

• Na transakcję, na dzień/tydzień w banku płatnika.
• Nowi odbiorcy/handlowcy - możliwe są obniżone progi, szybkość migawki.
• Kanał (mobilny/internetowy), zasady prędkości, sygnały geo/urządzenia.
• W poszczególnych krajach/bankach możliwe są progowe wyjątki SCA (RA, TRA) - w zależności od banku.

5) Autoryzacja vs rozrachunek

Status online: „sukces”, „oczekujący”, „nieudany”, „anulowany”, „wygasł”.
Czas oczekiwania jest możliwy, gdy nastąpi opóźnienie potwierdzenia lub kontrola asynchroniczna.
Rozliczenie: faktyczna pożyczka pochodzi z raportów dostawcy (zwykle T + 1/T + 2 dni bankowe; zależy od kraju/banku/systemu rozliczeniowego).
W przypadku usług krytycznych do momentu potwierdzenia rejestracji należy użyć modelu wykonania warunkowego.

6) Zwroty, częściowe zwroty i spory

Brak obciążenia zwrotnego (jak w kartach). Zwrot to nowa transakcja kredytowa dokonywana przez dostawcę na rzecz płatnika.
Częściowe zwroty są wspierane.
Warunki kredytu zwrotnego - bank (T + 1/T + 2).
Spory/reklamacje przechodzą przez procedurę dostawcy + ODR przez bank płatnika; przygotować dzienniki zamówienia, dowód dostawy/usługi.

7) Komisje i ekonomia

Zazwyczaj stały/niski procent z transakcją + płatność za funkcje platformy (obsługiwana realizacja transakcji, raporty, ODR).
Weź pod uwagę koszty wsparcia (oczekujące/wygasające), incydenty związane z ryzykiem i koszty wycofania transakcji.

8) Pojednanie i sprawozdawczość

Zapisz 'pa Id/ Id' dostawcy, ' Id', wydający bank, znaczniki czasowe, statusy.
Włącz haki internetowe o zmianach statusu i codziennym auto-recon.
Połączenie zdarzeń internetowych (sukces/oczekiwanie) ze sprawozdaniami finansowymi (kredyty/zwroty/korekty).
Zapisz odniesienie UTR/bank z raportu dla każdej transakcji.

9) Praktyki UX

Katalog banków: wstępnie wypełnić ostatni wybór, sortować według popularności/urządzenia banku.
Mobile-first: oferta App2App, fallback - przekierowanie stron internetowych.
Błędy i ponowna próba: podaj wyraźne powody (limit, awaria SCA, timeout), przycisk powtórnej próby i alternatywy.
Idempotencja: klucz idempotencji do bezpiecznych powtórzeń.
Paragon: kwota, data/godzina, ' Id', bank, kanał (App2App/przekierowanie).

10) Powtarzające się umorzenia i mandaty

Klasyczny Sofort - jednorazowy. W przypadku modeli cyklicznych stosuje się kilka: pierwszą płatnością jest A2A → e-mandat/SEPA DD/Open Banking PIS na przyszłość.
Zarządzanie mandatami (limit, częstotliwość, powiadomienia), przechowywanie dzienników akceptacji.

11) Zgodność, bezpieczeństwo, dane

PSD2/SCA: potwierdzenie w banku, wiążące urządzenie, bank zwalczania nadużyć finansowych.
Minimalizacja PII: przechowywać tylko niezbędne atrybuty; szyfrować PII; Podpisy haków internetowych haków HMAC.
RODO/Dzienniki: zgody, prawo do usunięcia, zmiany audytu.

12) Piony wysokiego ryzyka (w tym iGaming)

Dostępność Pay-by-Bank dla niektórych kategorii jest ograniczona przez dostawcę/banki zgodnie z polityką wewnętrzną i prawem lokalnym.
Oczekiwać obniżonych limitów, dodatkowe CUS/monitoring finansowy, możliwe posiadania.
Zachowaj alternatywne szyny (karty, SEPA, otwarta bankowość A2A, bony) i segmentację ruchu.

13) Integracja handlowców: Opcje

1. Hosted/Embedded ой PSP/Klarna

Szybki start: widget wyboru banku, statusy, błędy, haki z pudełka.

2. Serwer-serwer + redirect/App2App

Więcej kontroli: własna strona banków, drobne przetwarzanie błędów, własne QR/Deep Link.

3. Żądanie zapłaty

Wysyłanie żądania płatności (e-mail/SMS/link), wygodne dla B2B/services.

• Мндкоинта: „Płatność”, „Status”, „zwrot”, „webhook”, „reconcile”.
• Tablica idempotencji i dedupe 'Id'.
• Retrai wykładniczo dla statusów, martwy list dla niestabilnych odpowiedzi.
• Katalogi: banki/kraje, limity/kody błędów, wskaźniki SLA przez emitentów.

14) Architektura Sofort/Klarna Gateway

warstwa API (REST/GraphQL) dla kasy.
Kolejki wydarzeń: zdarzenia stanu → rozliczenie/CRM/analityka.
Obserwowalność: konwersja banku/kanału, „oczekujące → sukces/wygasły”, opóźnienie, awaria SCA.
Bezpieczeństwo: skarbiec dla tajemnic, dostawca IP-permlist, żetony anty-replay, ścisła weryfikacja przekierowania-URI.

15) Lista kontrolna wyjściowa

1. Wybierz kanał PSP/Klarna/Sofort z pożądaną geografią banku.
2. Zaimplementuj wybór bankowy + redirect/App2App z opcją awaryjną.
3. Podłącz haki internetowe, idempotencję, timeouts i powtórzenie stanu.
4. Skonfigurować recon (dziennie + pełny), UTR/fin referencje przechowywania.
5. Włącz częściowe/pełne zwroty i ODR w wsparciu.
6. Przygotuj scenariusze awarii/ograniczenia UX i alternatywne metody.
7. Testowanie banków mobilnych (iOS/Android) i głównych emitentów w krajach docelowych.
8. Utrzymuj stronę przewodnika limitu i stanu zdarzenia.

Karta orientacyjna

Статса: „sukces”, „oczekujący”, „nieudany”, „anulowany”, „wygasł”.
Rozrachunek: częściej T + 1/T + 2; zaplanować „wykonanie warunkowe” przed kredytem.
Limity: per-txn/day/week at issuer'a; dla nowych odbiorców - poniżej.
Powtórzenie: poprzez e-mandat/SEPA DD/Open Banking.

Podsumowanie

Do konwersji - App2App/Embedded, dla stabilności - przezroczyste haki + zwiad.
Oddzielne potwierdzenie online i rzeczywisty kredyt (T + 1/T + 2) w logice biznesowej.
Nie ustalaj twardych kwot: limit konfiguracji według banku/kraju + regularne aktualizacje.
W przypadku subskrypcji użyj pierwszego mandatu płatności A2A →, z wyraźnym zarządzaniem UX i limitami.