Blik jest dziś czymś więcej niż metodą płatności — to dla wielu Polaków domyślny sposób wydawania pieniędzy. Według danych Polskiego Standardu Płatności (operator systemu Blik) liczba transakcji Blik rośnie rok do roku o ponad 30%, a Polska należy do najbardziej cashless-friendly rynków w regionie. Dla promotora eventowego oznacza to jedno: jeśli nie obsługujesz Blika, tracisz konwersję na kupujących, którzy w ogóle nie rozważają innej metody płatności.
Ale sam fakt „mam Blika w checkoucie" to dopiero punkt startowy. Pytanie brzmi: jak Blik działa pod spodem, jakie ma ograniczenia w scenariuszach wysokiego ruchu i jak go poprawnie zintegrować, żeby nie tracić transakcji w newralgicznych momentach sprzedaży.
Jak działa Blik — przepływ 6-cyfrowego kodu
Blik to system płatności oparty na tokenach jednorazowych. Kupujący otwiera aplikację swojego banku (ING, PKO BP, mBank, Santander i kilkanaście innych — wszystkie integrujące się ze standardem Blik), generuje 6-cyfrowy kod ważny 120 sekund i wpisuje go w pole checkout.
Po stronie technicznej flow wygląda następująco:
- Merchant przesyła kod Blik do PSP (np. PayU, DotPay, Stripe via Blik plugin), wraz z kwotą transakcji i identyfikatorem merchantu.
- PSP przesyła żądanie autoryzacji do systemu Blik.
- System Blik identyfikuje bank wydawcy kodu i przesyła żądanie autoryzacji do tego banku.
- Bank weryfikuje poprawność kodu, dostępne saldo i limity transakcyjne. Wysyła do systemu Blik odpowiedź autoryzacyjną.
- PSP otrzymuje odpowiedź i potwierdza merchantowi sukces lub odmowę.
- Merchant zwalnia bilet kupującemu.
Cały przepływ trwa zazwyczaj kilka sekund w normalnych warunkach. Kluczowe słowo: normalnych.
Dlaczego Blik ma znaczenie akurat dla sprzedaży biletów
Sprzedaż biletów różni się od typowego e-commerce pod kilkoma względami, które wprost przekładają się na zachowanie kupujących wobec metod płatności.
Bilet to zakup impulsowy z presją czasu. Kupujący wie, że popularny event się wyprzedaje. Nie chce tracić 30 sekund na wpisywanie numeru karty. Blik daje mu znany interfejs (aplikacja bankowa, którą otwiera kilka razy dziennie) i jeden prosty krok: wpisz 6 cyfr, potwierdź. Na mobile — gdzie dziś odbywa się duża część zakupów biletów — ten flow jest znacznie szybszy niż jakikolwiek formularz kartowy, nawet z autouzupełnianiem.
Po drugie, Blik nie wymaga od kupującego zakładania konta na Twojej platformie ani podawania danych karty nieznanemu merchantowi. To ważne dla nowego użytkownika, który trafia na Twoją sprzedaż po raz pierwszy przez link ze social mediów. Bariera wejścia jest minimalna.
PSP timeout i co się dzieje przy szczytowej sprzedaży
Przy scenariuszu szczytowej sprzedaży — powiedzmy premiera biletów o 23:55 na popularny festiwal — Blik ma specyficzne zachowanie, o którym warto wiedzieć zanim skonfigurujesz integrację.
Każde żądanie autoryzacji Blik ma timeout. Standard Blik zakłada, że kod jest ważny 120 sekund — ale timeouty po stronie PSP i merchantu mogą być krótsze. Jeśli skonfigurowany timeout requestu w Twoim checkout wynosi 15 sekund, a PSP jest przeciążony i odpowiada po 20 sekundach, transakcja zostanie anulowana po stronie merchantu. Kupujący zobaczy błąd.
Co gorsza: z perspektywy kupującego sytuacja jest niejednoznaczna. Wpisał kod, potwierdził w aplikacji bankowej, a system mówi „błąd". Czy pieniądze zostały pobrane? Czy bilet jest jego? W takiej sytuacji część kupujących dzwoni do organizatora, część próbuje kupić ponownie (ryzykując podwójne obciążenie), a część po prostu odpuszcza.
Nie mówimy, że Blik jest zawodny — bo nie jest. Mówimy, że standardowa single-PSP integracja Blika bez przemyślanego timeoutowania i obsługi błędów nie jest zaprojektowana na polskie szczyty sprzedażowe. To dwa różne stwierdzenia.
Routing Blika — jak to skonfigurować poprawnie
Przy dużym wolumenie warto rozważyć kilka zasad:
Priorytet Blik w kolejności metod płatności. Blik powinien być pierwszą opcją w interfejsie checkout, nie ukrytą wśród kilkunastu metod. Polscy kupujący szukają go wzrokiem — czas szukania to czas, w którym bilet może kupić ktoś inny.
Fallback na kartę lub BLIK-0 (Blik bez PIN). Jeśli Twój PSP obsługuje BLIK-0 (autoryzacja bez wpisywania kodu dla zaufanych merchantów w aplikacjach bankowych), warto aktywować tę ścieżkę dla powracających kupujących. Zmniejsza liczbę kroków do zera — jeden tap w aplikacji bankowej, transakcja gotowa.
Transparent error messaging. Gdy Blik zwraca błąd, komunikat dla kupującego powinien rozróżniać: kod wygasł (wygeneruj nowy), transakcja odrzucona przez bank (sprawdź saldo/limity), błąd techniczny po stronie systemu (spróbuj za chwilę). Generyczny „płatność nie powiodła się" prowadzi do chaosu i duplikatów.
Idempotentność. Każda próba płatności musi mieć unikalny identyfikator, by ponowne kliknięcie przez kupującego nie generowało drugiej transakcji. To wymóg formalny przy każdej integracji PSP w Polsce, ale szczególnie istotny przy Bliku, gdzie użytkownik może być zdezorientowany co do statusu poprzedniej próby.
Integratorzy — PayU, DotPay, Stripe
Blik jest dostępny przez kilka bramek płatniczych obecnych na polskim rynku. Każda ma nieco inne API, inną dokumentację i różny czas odpowiedzi w szczycie.
PayU to historycznie największy PSP obsługujący Blik w Polsce — głęboka integracja ze standardem, dostępna bezpośrednio przez API REST lub przez gotowe SDK. DotPay (część grupy eService) obsługuje Blik przez zbliżony interfejs; jest popularny wśród mniejszych merchantów. Stripe wprowadził Blik na rynek polski kilka lat temu i integruje go przez standardowy Payment Intents API — wygodnie dla deweloperów znających ekosystem Stripe, choć z pewnymi ograniczeniami w dostępnych funkcjach specyficznych dla polskiego rynku.
Dobra integracja Blika to nie tylko „działa" — to obsługa wszystkich stanów pośrednich, sensowne timeouty, logging statusów transakcji i komunikacja, która nie wpędza kupującego w panikę o 23:56, gdy system przetwarza jego płatność przez pełne 8 sekund.
