sprzedaż biletów PSP checkout polska specyfika

23:55 — anatomia polskiego szczytu sprzedaży biletów

Dlaczego polscy kibice i fani kupują bilety dokładnie o 23:55 i jak to niszczy standardowe systemy checkout.

Digital clock showing 23:55 with abstract ticket sales spike visualization

Jeśli sprzedajesz bilety na cokolwiek popularnego w Polsce — koncert, mecz, nocne show w klubie — prawdopodobnie już wiesz, jak wygląda 23:55. Licznik odlicza, telefony się nagrzewają, a Twój checkout albo przeżywa ten moment, albo nie. Nie ma pośrodka.

Ten artykuł rozkłada godzinę 23:55 na czynniki pierwsze: skąd pochodzi, dlaczego polscy kupujący tak bardzo ją lubią, i co konkretnie dzieje się po stronie infrastruktury, gdy kilkaset osób nacisnęło „Kup" dokładnie w tej samej sekundzie.

Skąd się wzięło 23:55?

Polska ma specyficzną kulturę sprzedaży biletów, której nie zobaczysz w tej formie ani w Niemczech, ani we Francji. Promotorzy od lat otwierali sprzedaż o północy — bo to „nowy dzień", bo budowało napięcie, bo nocna premiera biletów wpisuje się w estetykę clubbingu i koncertów. Z czasem 00:00 zrobiło się zbyt okrągłe i łatwe do przewidzenia przez boty, więc naturalny drift zepchnął godzinę otwarcia do 23:55. Kupujący nauczyli się reagować z wyprzedzeniem, a promotorzy nauczyli się, że 23:55 to sygnał, który mobilizuje fanów bardziej niż popołudniowa premiera.

Dziś 23:55 to de facto niepisany standard w pewnych segmentach polskiego rynku eventowego — przede wszystkim muzyka elektroniczna, standup, mecze Ekstraklasy przy wzmożonym popycie. Fani ustawiają alarmy. Dosłownie.

Anatomia ataku na checkout

Wyobraź sobie event na 800 osób w Warszawie. Bilety w cenie 89–149 zł. Promotor otwiera sprzedaż o 23:55. Co się dzieje w ciągu pierwszych 60 sekund:

  • Sekundy 0–5: pierwsze 50–80 użytkowników trafia na stronę checkout jednocześnie. Sesje inicjują się, koszyki się otwierają.
  • Sekundy 5–15: inicjowane są żądania płatności. Większość wybiera Blik — użytkownik otwiera aplikację bankową, generuje 6-cyfrowy PIN.
  • Sekundy 15–30: PSP (dostawca płatności) musi teraz przetworzyć dziesiątki równoległych autoryzacji Blik. Każda autoryzacja to osobny request do banku z timeoutem 120 sekund — ale przy przeciążeniu PSP timeout może nastąpić wcześniej po stronie merchantu.
  • Sekundy 30–60: jeśli jeden PSP nie odpowiada w założonym czasie, kupujący widzi błąd. Część opuszcza koszyk. Część próbuje ponownie — co generuje duplikaty transakcji i dalej obciąża system.

Problem nie leży w samym Bliku ani w bankach. Leży w tym, że standardowe single-PSP checkouty są projektowane dla rozkładów normalnych ruchu — nie dla impulsu 10× w ciągu 30 sekund.

Dlaczego standardowe rozwiązania się tu sypią

Większość popularnych integracji płatniczych działa na zasadzie: jeden dostawca, jeden kanał, request po requeście. Gdy PSP jest zdrowy i ruch jest równomierny, działa świetnie. Problem pojawia się przy szczytowej sprzedaży, gdzie mamy trzy nakładające się czynniki:

Po pierwsze, Blik ma określony limit jednoczesnych autoryzacji po stronie każdego banku-wydawcy. Nie jest to limit platformy Blik jako takiej, ale wynika z architektury bankowych systemów autoryzacyjnych. Przy bardzo dużym evencie możesz trafić w ten sufit, szczególnie jeśli Twoja baza fanów jest skupiona geograficznie i bankuje u tych samych 2-3 największych banków.

Po drugie, PSP timeout. Gdy dostawca płatności jest przeciążony, odpowiedź na autoryzację może się opóźnić. Merchant SDK (czy to PayU, DotPay, czy Stripe) ma własny skonfigurowany timeout — często 10–30 sekund. Jeśli bank odpowie po 35 sekundach, transakcja jest anulowana po stronie merchantu, mimo że po stronie banku mogła zostać zarezerwowana. Kupujący nie wie, czy zapłacił. Ty też nie wiesz na pewno.

Po trzecie, brak fallbacku. Jeśli cały checkout oparty jest na jednym PSP i ten PSP zwalnia, nie ma żadnej automatycznej ścieżki alternatywnej. Użytkownik z Apple Pay w portfelu i tak ląduje na ekranie błędu, bo backend nie ma instrukcji „spróbuj innym dostawcą".

Nie mówimy, że jeden PSP to zły wybór na co dzień

Nie twierdzimy, że integracja z jednym dostawcą jest wadliwa dla normalnej sprzedaży. Dla eventu na 100 osób bez szczytowej premiery — działa doskonale. Problem jest specyficzny: polski promotor popularnego eventu, premiera o 23:55, krótkie okno sprzedażowe. To kombinacja, dla której single-PSP nie został zaprojektowany.

Skalowanie po stronie serwera — co faktycznie pomaga

Pytanie o skalowanie pojawia się zawsze, ale odpowiedź często mija się z sednem problemu. Możesz mieć 40 serwerów aplikacyjnych i nadal mieć problem z checkoutem o 23:55 — bo wąskie gardło nie jest w Twojej aplikacji, lecz w zewnętrznym PSP albo w sieci bankowej.

Co faktycznie działa:

Równoległy routing płatności — jednoczesne przekazanie transakcji do więcej niż jednego PSP z logiką pierwszeństwa. Jeśli PSP A odpowiada wolno, odpowiedź PSP B jest użyta. Kupujący nie widzi żadnej różnicy, bo całość trwa poniżej jego percepcji opóźnienia.

Wirtualna kolejka przy wejściu (queue throttling) — zamiast przepuszczać wszystkich naraz do checkout, utrzymujesz krótką kolejkę na poziomie inicjacji sesji. Kupujący widzi komunikat „Czekasz na miejsce w kolejce" zamiast błędu płatności. Psychologicznie — o wiele lepszy doświadczenie. Technicznie — znacznie mniejsze obciążenie PSP w sekundzie zero.

Idempotentność transakcji — każda próba płatności musi mieć unikalny idempotency key, żeby ponowne kliknięcie „Zapłać" przez zdenerwowanego kupującego nie skutkowało podwójnym obciążeniem. To wymóg higieny przy każdej integracji, ale przy 23:55 staje się krytyczny.

Zarządzanie komunikacją kupującego podczas szczytu

Jeden z niedocenianych aspektów szczytowej sprzedaży to nie technologia, lecz komunikacja. Kupujący, który dostaje suchy komunikat „Błąd płatności — spróbuj ponownie", zazwyczaj próbuje ponownie trzy razy z rzędu, generując potrójne obciążenie PSP. Kupujący, który dostaje komunikat „Twoja płatność jest przetwarzana, proszę czekać", czeka.

Warto też zadbać o stan biletów w czasie rzeczywistym. Jeśli event ma 800 miejsc i 600 z nich zostało zarezerwowanych w pierwszych 2 minutach, wyświetlenie liczby pozostałych biletów działa mobilizująco — i zmniejsza odsetek porzuconych koszyków, bo kupujący wie, że warto doczekać odpowiedzi systemu.

Premiera o 23:55 to prawdopodobnie najważniejsze kilka minut Twojego eventu z perspektywy infrastruktury. Dobrze zaprojektowany checkout sprawia, że te minuty są nudne — i o to właśnie chodzi.