GH GambleHub

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.

Wymagane elementy oparcia:
  • 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

💡 Rzeczywiste progi/ETA zależą od banku/PSP/kanału.

Статса: „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'.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.