GH GambleHub

Bizum Hiszpania: natychmiastowe transfery

1) Kontekst bizum i pozycjonowanie

Bizum to hiszpański interbank instant transfer i system płatności wbudowany w aplikacje lokalnych banków. Działa 24/7, obejmuje P2P (na numer telefonu), P2M (e-commerce/płatność offline), a także darowizny/darowizny i faktury. Potwierdzenie odbywa się w aplikacji bankowej (SCA/PSD2), środki przesuwają się wzdłuż szyn bankowych z natychmiastową autoryzacją i szybkim kredytowaniem.

Kluczowe właściwości:
  • Adresowanie telefonu (alias), brak IBAN w UX.
  • Natychmiastowy i ostateczny przelew (brak obciążenia zwrotnego w kartach).
  • P2M: płatność na stronie, w aplikacji, offline (kod QR/Bizum).
  • Żądanie zapłaty: „żądanie zapłaty” do kontaktów lub klientów.

2) Członkowie i role

Plan bizum/przełącznik międzybankowy - zasady, routing, katalogi uczestników.
Wydawanie banków - aplikacje mobilne, SCA, zwalczanie nadużyć finansowych i ograniczenia.
PSP/nabywcy - połączenie handlowców z Bizum P2M, API/SDK, raportowanie i obliczenia.
Handlowiec - inicjuje płatność/żądanie, przetwarza statusy, utrzymuje zwroty i uzgodnienia.
Płatnik/odbiorca - potwierdza transakcje w aplikacji bankowej.

3) Tryby i scenariusze użytkownika

3. 1 P2P „na telefon”

Nadawca wybiera kontakt (numer telefonu) → wpisuje kwotę → potwierdza w swojej aplikacji bankowej → odbiorca widzi kredyt błyskawiczny na koncie.
Dla nowych odbiorców obniżone progi/dodać. kontrole.

3. 2 P2M (płatność na rzecz handlowca)

E-commerce: przy realizacji transakcji wprowadź numer telefonu Bizum lub otwórz aplikację bankową deeplink; potwierdzenie - push/SCA.
Offline/QR: dynamiczny QR na zamówienie (kwota + Id), skanowanie w aplikacji bankowej → potwierdzenie → status online do handlowca.
Kod bizum: handlowiec może pokazać krótki kod/alias do zapłaty w punkcie sprzedaży.

3. 3 Żądanie zapłaty

Handlowiec składa wniosek o płatność (kwota/cel/okres ważności) → klient potwierdza w swoim wniosku bankowym → środki są zapisywane jako regularny przelew Bizum.

3. 4 Depozyty i rachunki do zapłaty

Obsługiwane krótkie kody/pseudonimy na cele charytatywne i użytkowe/małe płatności.

4) Statusy

„zakończony” → „oczekujący” → „sukces ”/„ nieudany ”/„ anulowany ”/„ wygasł”.
W przypadku wniosków - dodatkowe państwa „wymagane ”/„ wygasły”.

5) Limity i polityka ryzyka

Nie ma jednego sufitu „super-circuit”: banki i/lub PSP określone limity, często w zależności od poziomu KYC, historii i kanału.

Na transakcję, dziennie/24h, czasami tygodniowo/miesięcznie.
Nowy odbiorca/handlowiec - obniżone progi, prędkość migawki lub potwierdzenie.
Kanał/skrypt: oddzielne limity dla P2P, P2M (web/app/QR), Request-to-Pay.
Prędkość/urządzenie/geo-zasady po stronie banku.

💡 Praktyka: Nie koronuj numerów. Przechowywanie katalogu limitów przez bank/kanał i aktualizacja; w interfejsie użytkownika należy podać zrozumiały powód odmowy („limit bankowy/kanałowy”) oraz alternatywy (kontrola dzielona, inna metoda).

6) Ekonomia i prowizje

Dla handlowca Bizum jest zwykle tańsze niż MDR karty, ale warunki zależą od PSP/banku.
Planowanie kosztów integracji/SDK, przetwarzania „oczekujących/wygasłych”, wsparcia/ODR i zwiadu.

7) Zwroty i spory

Brak obciążenia zwrotnego (jak w kartach) dla A2A. Zwrot - nowa transakcja kredytowa od handlowca do płatnika (obsługiwane są częściowe zwroty).
Warunki - bank (często T + 0/T + 1).
Spory/skargi - za pośrednictwem PSP i procedur bankowych; Przygotuj dzienniki zamówień, potwierdzenia i komunikację z klientami.

8) Bezpieczeństwo i zgodność

PSD2/SCA w aplikacji bankowej: PIN/biometria, powiązanie urządzeń, uwierzytelnianie oparte na ryzyku z bankiem.
Minimalizacja PII: przechowywać tylko niezbędne atrybuty (telefon/refs), szyfrować PII, ograniczyć dostęp.
Haki internetowe: HMAC/nonce, ochrona przed powtórzeniem, audyt i dziennik retray.

9) Integracja handlowców

Opcje

1. Hosted/Embedded by PSP - szybki start: formularze Bizum, statusy, błędy poza pudełkiem.
2. Server-to-Server + App2App/QR - natywny UX, dynamiczny QR na zamówienie, głęboka obsługa błędów.
3. Pay-by-Link/Request-to-Pay - konto przez link (e-mail/SMS/messenger), potwierdzenie w banku.

Wymagane elementy oparcia:
  • Interfejs API: Płatność, płatność, zwrot pieniędzy, hak internetowy, uzgodnienie.
  • Idempotencja (klucz ' Id' +), przekładnie wykładnicze, dedup zdarzeń.
  • Recon: dzienny auto-recon + okresowy pełny zwiad; przechowywanie odniesień do UTR/fin.
  • Deski rozdzielcze SLA: konwersja, „w oczekiwaniu → sukces/wygasła”, opóźnienie przed zapisaniem.

10) Pojednanie i sprawozdawczość

Dziennik: 'Id/ Id',' Id', kanał (P2P/P2M/QR/App2App/Request), bank płatnika, status, kwota/waluta, znacznik czasu, UTR/link bankowy.
Z PSP: rejestry zapisów/zwrotów/korekt, późne aktualizacje stanu.

11) Wzory UX

Mobile-first: dla telefonów komórkowych - App2App; dla pulpitu - dynamiczny QR.
Przejrzyste błędy: limit, timeout, awaria SCA; bezpieczny powtórzenie + alternatywa (karta/SEPA/inne A2A).
Odbiór: ilość, czas, ' Id', kanał, UTR, kontakty wsparcia.
Okres ważności żądania/QR: Pokaż czasomierz i skrypt odzyskiwania.

12) Powtarzanie i mandaty

Basic Bizum - jednorazowy z SCA. W przypadku subskrypcji stosuje się pakiet: pierwsza płatność Bizum → e-mandat/SEPA DD/Open-Banking dla kolejnych odpisów (limit/częstotliwość/powiadomienia, ekran zarządzania mandatem).

13) Piony wysokiego ryzyka (w tym iGaming)

Dostępność/limity zależą od polityki banku/PSP i prawa lokalnego.
Oczekiwać obniżonych progów, wzmocniony KYC, możliwe uchwyty.
Planowanie alternatywnych szyn (mapy, SEPA, inne PIS) i inteligentne trasy według ryzyka.

14) Architektura Bizum 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ść: mierniki według kanału (App2App/QR/Request), 'w oczekiwaniu → sukces/wygasł', czas do rozliczenia.

15) Lista kontrolna wyjściowa

1. Subskrybuj kanał Bizum z PSP/Bank; wybierz kanały (App2App/QR/Request).
2. Implementacja ekranów dynamicznych QR, błędów/limitów.
3. Podłącz haki internetowe, idempotencję, retrai i event dedup.
4. Skonfigurować recon (dziennie + pełny), UTR/fin referencje przechowywania.
5. Wsparcie częściowych/pełnych refundacji i procedur ODR.
6. Uruchom deski rozdzielcze SLA i alerty konwersji/opóźnienia.
7. Przeprowadzanie testów e2e z głównymi bankami/urządzeniami.


Karta referencyjna limitu

💡 Rzeczywiste progi są ustalane przez banki/dostawców usług płatniczych i różnią się w zależności od scenariusza.

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


Wznów streszczenie

Dla online - App2App + dynamiczny QR, dla offline - kod QR/Bizum, dla transferów - P2P według numeru.
Oddzielne potwierdzenie online i ostateczny kredyt w logice; zbudować wokół webhooks + recon i częściowe zwroty.
Nie ustalaj kwot: utrzymuj konfiguracje limitu przez bank/kanał i regularnie aktualizuj.
Dla subskrypcji, pierwszy pakiet Bizum → bilet z przejrzystym zarządzaniem i powiadomieniami.

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.