Wszystko poniżej sprawdziłem na testowym sklepie: WooCommerce 11.2.1, wtyczka WooCommerce Stripe Gateway 11.1.1, polski panel, kasa w blokach i konto Stripe w trybie testowym. Trzy zamówienia: jedno opłacone normalnie, jedno, którego „klient” nie zatwierdził w banku, i jedno opłacone przy wyłączonym webhooku. Godziny i statusy są z tych zamówień, nie z dokumentacji.
/ Krok 1
Jak włączyć BLIK w WooCommerce przez Stripe?
Potrzebujesz konta Stripe i wtyczki WooCommerce Stripe Gateway z katalogu WordPressa. Osobnej umowy z polskim operatorem płatności nie ma — BLIK jest jedną z metod płatności Stripe. Ogólnie o BLIK-u w Stripe, prowizjach i zwrotach pisałem w artykule o płatnościach BLIK przez Stripe; tu skupiam się na samym WooCommerce.
- Połącz wtyczkę z kontem Stripe w WooCommerce → Ustawienia → Płatności → Stripe. Zacznij w trybie testowym.
- W zakładce „Payment Methods” zaznacz BLIK i zapisz.
- Sprawdź walutę sklepu: WooCommerce → Ustawienia → Ogólne, musi być złoty polski (PLN).
- W panelu Stripe sprawdź, że istnieje webhook na adres Twojego sklepu — o tym, dlaczego to najważniejszy punkt, w sekcji piątej.
Jedna pułapka, na którą trafiłem przy konfiguracji: po zapisaniu kluczy wtyczka przepisała do Stripe swoją listę metod płatności (karta i Link) i BLIK się wyłączył, choć wcześniej był włączony. Po każdej zmianie połączenia ze Stripe wróć do listy metod i sprawdź, czy BLIK nadal jest zaznaczony.
/ Diagnoza
„BLIK is enabled - it requires store currency to be PLN” — co znaczy ten błąd?
Dokładnie to, co mówi: BLIK jest włączony, a waluta sklepu nie jest ustawiona na złotówki. BLIK obsługuje wyłącznie PLN, więc przy euro czy dolarach w kasie się nie pokaże — po cichu, bez żadnego komunikatu dla klienta.
Dwie rzeczy, które utrudniają diagnozę. Po pierwsze, komunikat nie pojawia się na stronie ustawień Stripe — tam przy BLIK-u widać tylko żółtą etykietę „Requires currency”. Kto szuka problemu w ustawieniach płatności, pełnego komunikatu tam nie znajdzie. Po drugie, jest po angielsku, więc wiele osób wpisuje go w wyszukiwarkę dosłownie.
Rozwiązanie: ustaw walutę sklepu na PLN. Jeśli sklep sprzedaje w innej walucie, BLIK-a nie da się tam użyć i lepiej go wyłączyć, żeby komunikat nie wisiał w kokpicie.
/ Kasa
Co klient widzi w kasie przy płatności BLIK?
Po wybraniu BLIK-a w kasie pojawia się pole na sześciocyfrowy kod. Klient wpisuje kod z aplikacji banku, klika przycisk zamówienia, a potem zatwierdza płatność w aplikacji. Według dokumentacji Stripe kod jest ważny 2 minuty, a na zatwierdzenie płatności klient ma 60 sekund.
Tu jest pierwsza rzecz do poprawienia przed startem: „BLIK Code” i „After submitting your order, please authorize the payment in your mobile banking application.” zostają po angielsku. Polskie tłumaczenie wtyczki obejmuje w chwili pisania 178 tekstów i tych wśród nich nie ma. W polskim sklepie to wygląda na niedokończoną stronę płatności — dokładnie w momencie, w którym klient decyduje, czy zaufać.
Teksty trzeba przetłumaczyć wtyczką do tłumaczeń albo w kodzie, a potem sprawdzić na prawdziwej kasie. Część tekstów kasy w blokach siedzi w plikach JavaScript, nie w PHP, i tłumaczenie, które działa w panelu, nie zawsze dociera na kasę.
/ Pułapka
Dlaczego klient widzi „Dziękujemy”, zanim zapłaci?
To najważniejsze, co pokazał test. Po kliknięciu przycisku zamówienia kasa przez kilka sekund pokazuje kręcące się kółko, a potem przekierowuje na stronę „Zamówienie otrzymane” — zanim bank potwierdzi płatność.
Przy udanej płatności różnica była niewielka: klient był na stronie z podziękowaniem około 10 sekund, zanim Stripe potwierdził płatność. Przy płatności, której klient nie zatwierdził w aplikacji, wyglądało to tak:
W tym samym czasie w panelu zamówienie miało status „Oczekujące na płatność”. Po około 40 sekundach Stripe zgłosił, że klient nie zatwierdził płatności w wyznaczonym czasie, i zamówienie przeszło na „Nieudane”. Klient dostał maila, że zamówienie się nie powiodło, a sklep — osobne powiadomienie. Komunikat „Niestety Twoje zamówienie nie może być zrealizowane…” z przyciskiem „Zapłać” klient zobaczył dopiero po odświeżeniu strony.
Wniosek dla sklepu: strona z podziękowaniem nie jest dowodem zapłaty. Dowodem jest status „W trakcie realizacji”. Wszystko, co dzieje się automatycznie — wysyłka produktu cyfrowego, dostęp do kursu, faktura, wiadomość do magazynu — powinno ruszać po zmianie statusu na „W trakcie realizacji”, nie po złożeniu zamówienia. Warto też zmienić tekst strony z podziękowaniem tak, żeby nie obiecywał realizacji, dopóki klient nie zatwierdzi płatności w banku.
/ Webhook
Co się dzieje, gdy webhook nie działa?
Webhook to powiadomienie, które Stripe wysyła do sklepu, gdy coś stanie się z płatnością. Wtyczka zakłada go sama: w panelu Stripe, w zakładce Webhooks w sekcji Workbench, powinien być endpoint z adresem Twojego sklepu zakończonym na ?wc-api=wc_stripe i statusem „Active”.
Żeby sprawdzić, jak ważny jest ten element, wyłączyłem webhook i złożyłem zamówienie z udaną płatnością. Stripe pobrał 79 zł, a w panelu Stripe płatność miała status „Succeeded”:
A w sklepie zamówienie zostało „Oczekujące na płatność”. Bez maila do klienta, bez powiadomienia o nowym zamówieniu, bez startu realizacji. Panel Stripe też nie alarmował: przy wyłączonym endpoincie licznik nieudanych dostaw pokazywał zero, bo zdarzenia w ogóle nie zostały wysłane.
Ratunek: sprzątanie nieopłaconych zamówień
Sytuację ratuje mechanizm, o którym mało kto wie. WooCommerce co jakiś czas anuluje zamówienia z kasy, które nie zostały opłacone w czasie ustawionym w WooCommerce → Ustawienia → Produkty → Magazyn, w polu „Wstrzymuj stan magazynowy (w minutach)” — domyślnie 60 minut. Wtyczka Stripe wtrąca się w ten moment: zanim zamówienie zostanie anulowane, pyta Stripe o płatność, a jeśli ta się udała, oznacza zamówienie jako opłacone i wysyła zaległe maile.
Dwa „ale”. Po pierwsze, klient i sklep czekają na to do godziny, a klient przez ten czas nie ma żadnego potwierdzenia, że zapłacił. Po drugie, ten mechanizm w ogóle się nie uruchamia, jeśli w sklepie wyłączone jest zarządzanie stanem magazynowym albo pole czasu wstrzymania jest puste — tak wynika z kodu WooCommerce. To częste w sklepach z usługami i produktami cyfrowymi, które nie liczą stanów. Wtedy zamówienie opłacone przy niedziałającym webhooku zostaje „oczekujące” na zawsze.
W prawdziwym sklepie webhook przestaje działać z prozaicznych powodów: przeniesienie sklepu na nowy adres albo z wersji testowej na produkcyjną, zmiana kluczy API, wtyczka bezpieczeństwa albo zapora blokująca zapytania ze Stripe. Po każdej takiej zmianie zrób jedno testowe zamówienie i sprawdź, czy przeszło na „W trakcie realizacji”.
Jeśli trafisz na zamówienie „oczekujące”, a klient twierdzi, że zapłacił: znajdź płatność w panelu Stripe (w opisie jest numer zamówienia) i napraw webhook. Jeśli sklep nie zarządza stanem magazynowym, status takiego zamówienia trzeba zmienić ręcznie.
/ Test
Jak przetestować BLIK w WooCommerce bez prawdziwych pieniędzy?
W trybie testowym Stripe każdy sześciocyfrowy kod, na przykład 123456, daje udaną płatność. Nieudane scenariusze wywołuje się adresem e-mail klienta w zamówieniu — Stripe opisuje je w dokumentacji BLIK-a:
customer_declined@…— klient odrzuca płatność (odpowiedź po ok. 8 sekundach);customer_timeout@…— klient nie zatwierdza płatności w ciągu 60 sekund;- są też warianty na błędny i wygasły kod, brak środków i odmowę banku.
Przejdź przez trzy scenariusze: udaną płatność, odmowę i brak zatwierdzenia. Za każdym razem sprawdź trzy rzeczy: co widzi klient, jaki status ma zamówienie po minucie i jakie maile wyszły. Dopiero to pokazuje, jak sklep zachowuje się, gdy coś pójdzie nie tak — a przy BLIK-u, gdzie klient ma minutę na telefon, idzie nie tak regularnie.
/ Podsumowanie
Lista kontrolna przed włączeniem BLIK-a w sklepie
- Waluta sklepu: PLN.
- BLIK zaznaczony we wtyczce i widoczny w kasie — sprawdzone po każdej zmianie połączenia ze Stripe.
- Teksty pola BLIK przetłumaczone i sprawdzone na prawdziwej kasie.
- Webhook w panelu Stripe: adres sklepu, status „Active”.
- Automatyczne działania (wysyłka, dostęp, faktura) podpięte pod status „W trakcie realizacji”, nie pod złożenie zamówienia.
- Testowe zamówienia: udane, odrzucone i bez zatwierdzenia — z kontrolą statusu i maili.
- Raz w tygodniu: przegląd zamówień „Oczekujące na płatność” starszych niż godzina.
Więcej o tym, co w sklepie warto zautomatyzować, a co psuje się po cichu, piszę w artykule o automatyzacji sklepu WooCommerce.
/ Dalej
Kiedy warto to zlecić
Włączenie BLIK-a to kilka kliknięć. Czas zajmuje to, co wyszło w teście: przetłumaczenie kasy, sprawdzenie webhooka po każdej przeprowadzce sklepu, podpięcie wysyłki pod właściwy status i regularne zaglądanie do zamówień, które utknęły. To jest stała część opieki nad sklepem WooCommerce, którą prowadzę — z zakupem testowym po każdej aktualizacji WooCommerce i cotygodniową kontrolą, czy webhooki i bramka płatności odpowiadają.
