Giropay Niemcy: bankowość online
1) kontekst giropay i pozycjonowanie
giropay - niemiecki system A2A „pay-by-bank”, w którym kupujący potwierdza płatność w swoim banku internetowym/aplikacji mobilnej banku wydającego. Handlowiec otrzymuje status online, a pieniądze pochodzą z kredytu bankowego (zwykle T + 0/T + 1 dni roboczych, w zależności od banku/PSP i kolei rozliczeniowej używane). Koszt odbioru jest niższy niż typowy MDR karty, SCA jest wykonywany w emitencie zgodnie z PSD2.
Kluczowe właściwości:- Issuer-redirect/App2App: przekieruj do banku lub otwórz jego aplikację.
- SCA i wiążące urządzenie: potwierdzenie z banku, minimalizacja oszustw.
- Bogate metadane do pojednania: odniesienie handlowca/ Id.
- Zwrot pieniędzy za pomocą przelewu: nie ma obciążenia zwrotnego jak w kartach.
2) Role i uczestnicy
System Giropay - zasady, trasy do banków.
Emitent (bank płatnika) - uwierzytelnianie klienta, potwierdzenie, ograniczenia/przeciwdziałanie oszustwom.
PSP/Acquirer (CPSP) - połączenie handlowców, API/SDK, haki internetowe, raporty i obliczenia.
Handlowiec - inicjacja płatności, przetwarzanie statusu/zwrotu, pojednanie.
3) Przepływy płatnicze
3. 1 Klasyczne przekierowanie emitenta (web)
1. Handlowiec realizacji transakcji → wybór giropay.
2. Lista banków → przekierowanie do banku online → SCA/potwierdzenie.
3. Powrót na stronę handlowca ze statusem (sukces/oczekujący/nieudany/anulowany/wygasł).
4. Czekanie na hak/rejestr na temat rzeczywistego kredytu (rozliczenie).
3. 2 App2App (mobilny)
W telefonie handlowiec otwiera aplikację bankową przez deeplink/intent → potwierdzenie → zwrot.
Konwersja jest zwykle wyższa; wymagany odpad do przekierowania sieci.
3. 3 QR/Pay by Link
PSP może dać dynamiczny QR/link z kwotą i odniesieniem (wygodne dla faktur/offline).
Użytkownik skanuje kod i potwierdza go bankowi zgodnie z powyższym schematem.
3. 4 „Pierwsza płatność → mandat”
W przypadku rozliczeń cyklicznych giropay jest często używany jako pierwsza płatność z SCA, a następnie - SEPA Direct Debit/open-banking mandat dla kolejnych odpisów.
4) Autoryzacja vs rozrachunek
Online-статса: „sukces”, „oczekujący”, „nieudany”, „anulowany”, „wygasł”.
„w oczekiwaniu” oznacza, że bank/dostawca nadal potwierdza transakcję lub oczekuje się pożyczki.
Rozrachunek: rzeczywisty kredyt na raportach PSP/bankowych (zwykle T + 0/T + 1; w niektórych przypadkach dłużej).
W przypadku usług wrażliwych na ryzyko należy stosować model „warunkowej wydajności” przed potwierdzoną rejestracją.
5) Zwroty i spory
Nie ma ładowarek. Zwrot jest nową transakcją kredytową od handlowca do płatnika (możliwe są częściowe zwroty).
Daty zwrotu - bank (T + 0/T + 1/T + 2, zależy od kanału).
Spory/reklamacje - za pośrednictwem procedur ODR PSP i banku płatnika; przygotować dzienniki zamówienia, dowód dostawy/usługi.
6) Limity i polityka ryzyka
Nie ma jednego pułapu „obwodu” - obowiązują limity zasad banku płatniczego i PSP:- Na transakcję, na dzień/tydzień „emitent”.
- Nowi odbiorcy/handlowcy - obniżone progi i/lub ekspozycja.
- Zasady kanału/prędkości, sygnały geo/urządzenia, wyjątki SCA (TRA/RA) - według uznania banku.
Praktyka: Nie koduj numerów. Zachowaj katalog limitów przez bank/kanał, zaktualizuj go, pokaż wyraźne przyczyny awarii („przekroczony limit bankowy/kanał”) i zaoferuj alternatywy (split check, inna metoda).
7) Komisje i ekonomia
W przypadku giropay do adresu PSP stosuje się zwykle fix/low percentage; poniżej mapy MDR.
Rozważenie wydatków na oczekujące/wygasające, ODR i wsparcie zwiadowcze, a także opłat za hostowane/wbudowane widżety i sprawozdawczość.
8) Pojednanie i sprawozdawczość
Przechowywanie: „Id/ Id” dostawcy, „Id”, bank emitenta, czas, kanał (przekierowanie/App2App/QR), status końcowy, bank reference/UTR z raportów fin.
Włącz haki internetowe o zmianach stanu, codziennym auto-recon i okresowym full-recon (kredyty/zwroty/korekty).
Ustaw desynchronizowane alerty i deski rozdzielcze SLA.
9) Wzory UX
Katalog banków: auto-hint/search, zapamiętanie ostatniego banku.
Mobile-first: oferta App2App; fallback - przekierowanie stron internetowych.
Błędy i powtórzenia: jasne powody (limit, awaria SCA, timeout), bezpieczne powtarzanie z idempotencją.
Paragon: kwota, data/godzina, ' Id', bank, kanał, łącze wsparcia.
10) Powtarzające się odpisy
Użyj systemu: pierwsza płatność giropay → e-mandat (SEPA DD/Open Banking).
W bilecie należy ustawić limit obciążenia, częstotliwość, powiadomienia i zarządzanie (pauza/anulowanie).
11) Zgodność i bezpieczeństwo
PSD2/SCA odbywa się w banku; urządzenie wiążące i zwalczające oszustwa po stronie emitenta.
Minimalizacja RODO/PII: przechowywać tylko niezbędne atrybuty, szyfrować PII, ograniczać dostęp.
Haki internetowe: HMAC/nonce, ochrona przed powtórzeniem, dopuszczalna lista IP, dziennik audytu.
12) Wrażliwe piony (w tym iGaming)
dostępność giropay i limity zależą od polityki PSP/banku 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 otwartej bankowości), inteligentne routing zgodnie z profilem klienta.
13) Integracja handlowców: Opcje
1. Hosted/Embedded z PSP - szybkie uruchomienie, gotowa lista banków, statusy, błędy.
2. Server-to-Server + Redirect/App2App - własna strona wyboru banku, głębokie przetwarzanie błędów, własne QR/Deep Link.
3. Faktury/Rau-by-Link/QR - wygodne dla B2B/offline.
- Interfejs API: Płatność "," Status "," zwrot "," hak internetowy "," reconcile ".
- Idempotencja (klucz Id +), przekładanie wykładnicze, dedup zdarzeń.
- Katalogi: banki/limity/kody błędów; Wskaźniki SLA przez emitentów.
14) architektura „giropay Gateway”
warstwa API (REST/GraphQL) dla kasy.
Kolejki wydarzeń: zdarzenia stanu → rozliczenie/CRM/analityka.
Obserwowalność: konwersja banku/kanału, „w oczekiwaniu → sukces/wygasł”, opóźnienie w rozliczeniu.
Bezpieczeństwo: skarbiec dla tajemnic, IP-permlist PSP, ścisłe przekierowanie-walidacja URI, żetony anty-replay.
15) Lista kontrolna wyjściowa
1. Wybierz kanał PSP/giropay (Hosted/Embedded/App2App/QR), uzgodnić taryfy i SLA.
2. Wprowadź 'Zapłata' + wybór banku + przekierowanie/Aplikacja 2 Aplikacja z awaryjnym.
3. Podłącz haki internetowe, timeouts i odzyskiwanie statusu.
4. Skonfigurować recon (dziennie + pełny), UTR/fin referencje przechowywania.
5. Włącz częściowe/pełne zwroty i ODR jako wsparcie.
6. Przygotuj scenariusze awarii/ograniczenia UX i alternatywne metody.
7. Obejmuje banki mobilne (iOS/Android) i głównych emitentów z testami.
Karta orientacyjna
Статса: „sukces”, „oczekujący”, „nieudany”, „anulowany”, „wygasł”.
Rozrachunek: częściej T + 0/T + 1; rozważyć warunkowe wyniki przed kredytem.
Limity: per-txn/day/week at issuer'a; dla nowych odbiorców - obniżone progi.
Powtórzenie: poprzez e-mandat/SEPA DD/Open Banking po pierwszej płatności A2A.
Podsumowanie
Postaw na App2App/Embedded konwersji i dynamiczne QR/Pay-by-Link dla faktur/offline.
Oddzielne potwierdzenie online i rzeczywisty kredyt w logice biznesowej.
Nie używać twardych kwot kodu: zachowywać konfiguracje limitu przez bank/kanał i regularnie aktualizować.
Zbuduj proces wokół haków webowych + recon, częściowych zwrotów i przezroczystej obsługi 'oczekujących/wygasłych'.