BLIK cykliczny w WooCommerce: jak wdrożyć płatności powtarzalne i subskrypcje

Płatności cykliczne w WooCommerce przez lata oznaczały w praktyce jedno: kartę. Klient podawał dane karty raz, a sklep co miesiąc pobierał opłatę. Problem w tym, że wielu Polaków nie chce zapisywać karty w sklepie, a część w ogóle nie płaci nią w internecie - płaci BLIK-iem. BLIK cykliczny (oficjalnie „Płatności Powtarzalne BLIK”) zamyka tę lukę. W tym wpisie opisuję, jak taka usługa działa, kiedy ma sens i jak wygląda wdrożenie w WooCommerce - na podstawie projektu, w którym sam ją budowałem.

Czym jest BLIK cykliczny i czym różni się od karty

BLIK cykliczny to zgoda, którą klient wyraża raz: wybiera BLIK w sklepie, wpisuje kod i potwierdza utworzenie płatności powtarzalnej w aplikacji swojego banku. Od tej chwili sklep może inicjować kolejne obciążenia na warunkach tej zgody - bez ponownego wpisywania kodu. Samo utworzenie zgody nie obciąża konta; pieniądze schodzą dopiero przy konkretnej transakcji zainicjowanej przez sprzedawcę.

Według dokumentacji BLIK usługa występuje w trzech modelach:

Model	Kwota i częstotliwość	Potwierdzenie każdej płatności	Typowe zastosowanie
A	stałe	nie	subskrypcja, abonament, stała darowizna
M	zmienne	tak, w aplikacji banku	rachunki, płatności etapowe
O	zmienne	nie	usługi rozliczane wg zużycia, płatności okazjonalne

Model O u niektórych operatorów jest dostępny tylko po dodatkowej akceptacji i ma limit kwoty pojedynczej transakcji - szczegóły trzeba sprawdzić u operatora.

Najważniejsze różnice względem karty:

• Nie ma daty ważności karty, więc znika problem wygasłych kart, który przy subskrypcjach kartowych regularnie powoduje nieudane odnowienia.
• Klient widzi zgodę w aplikacji banku i może ją tam w każdej chwili anulować - bez kontaktu ze sklepem.
• Nie każdy bank obsługuje usługę. Lista rośnie, ale wciąż nie obejmuje wszystkich banków, więc BLIK cykliczny powinien być dodatkową opcją, nie jedyną.
• Obciążenie bywa odroczone. Przy braku środków bank może przez pewien czas ponawiać autoryzację, zanim zwróci odmowę - wynik płatności nie zawsze jest natychmiastowy.

Kiedy warto

BLIK powtarzalny ma sens wszędzie tam, gdzie klient płaci regularnie podobną kwotę, a grupa docelowa chętniej używa telefonu niż karty:

• subskrypcje WooCommerce - pudełka subskrypcyjne, dostęp do treści, kursy z opłatą miesięczną,
• darowizny cykliczne - fundacje i organizacje, które budują bazę stałych darczyńców,
• abonamenty usługowe - serwis, opieka, członkostwo w klubie,
• płatności rozłożone w czasie, gdzie kwota może się zmieniać (model M).

Jeśli sprzedajesz jednorazowo, wystarczy zwykły BLIK. Cykliczny wnosi wartość dopiero wtedy, gdy chcesz pobierać pieniądze bez udziału klienta przy każdej płatności.

Co jest potrzebne

Operator płatności obsługujący BLIK powtarzalny. Z tego, co udało mi się potwierdzić w dokumentacjach, usługę opisują m.in. Tpay, Przelewy24 i PayU, a Autopay obsługuje ją u swoich partnerów. Zakres (modele, wymagania, dostępność we wtyczkach) różni się między operatorami i zmienia się w czasie - przed decyzją sprawdź aktualną dokumentację i zapytaj opiekuna handlowego.

Osobna aktywacja usługi. To nie jest przełącznik w panelu. Zwykle wymaga aneksu do umowy lub zgody operatora, a czasem przejścia procesu certyfikacji - BLIK ma własne wymagania, m.in. co do nazewnictwa metody i informowania klienta, że zakłada płatność powtarzalną.

WooCommerce Subscriptions albo inny mechanizm subskrypcji. Wtyczka zarządza harmonogramem odnowień, statusami subskrypcji i zamówieniami odnowieniowymi. Bramka płatności musi umieć te odnowienia obsłużyć - i tu jest haczyk: gotowe wtyczki operatorów często wspierają płatności cykliczne kartą, ale nie BLIK-iem. Wtedy trzeba dopisać własny moduł.

Dostęp do sandboxa operatora i serwer, który przyjmuje powiadomienia (webhooki) z zewnątrz - bez blokad po stronie firewalla czy wtyczek bezpieczeństwa.

Jak wygląda wdrożenie krok po kroku

1. Wybór modelu. Dla stałej subskrypcji lub stałej darowizny zwykle wystarczy model A. Modele M i O mają sens przy zmiennych kwotach.
2. Aktywacja u operatora. Aneks, konfiguracja w panelu, adresy powiadomień, dane dostępowe do API - osobno dla sandboxa i produkcji.
3. Pierwsza płatność z zakładaniem zgody. Klient wybiera BLIK cykliczny, wpisuje kod, potwierdza w aplikacji. Sklep wysyła do operatora parametry zgody (model, kwota, częstotliwość, okres ważności) i dostaje w odpowiedzi identyfikator, którym będzie się posługiwał przy kolejnych obciążeniach.
4. Zapisanie identyfikatora przy subskrypcji. Identyfikator zgody (alias) trzeba trwale powiązać z subskrypcją w WooCommerce, bo bez niego odnowienie nie ma czym obciążyć klienta.
5. Obsługa odnowień. Gdy WooCommerce Subscriptions tworzy zamówienie odnowieniowe, moduł wysyła żądanie obciążenia z użyciem zapisanego aliasu. Zamówienie zostaje w statusie oczekującym do czasu potwierdzenia od operatora.
6. Obsługa powiadomień. Webhook z wynikiem transakcji zmienia status zamówienia i subskrypcji. Osobne powiadomienia mogą dotyczyć samej zgody - np. jej usunięcia lub wygaśnięcia.
7. Komunikacja z klientem. Jasna informacja w checkoutcie, że to płatność powtarzalna, e-maile po udanym i nieudanym odnowieniu, instrukcja anulowania.
8. Testy i analityka. Testy wszystkich scenariuszy na sandboxie, a na koniec zdarzenia konwersji (np. GA4, Meta Pixel), żeby wiedzieć, ile zgód faktycznie powstaje.

Pułapki

Asynchroniczne potwierdzenia. Odpowiedź na żądanie obciążenia to zwykle tylko „przyjęto do realizacji”, a nie „zapłacono”. O wyniku decyduje webhook. Jeśli sklep oznaczy zamówienie jako opłacone na podstawie samej odpowiedzi API, prędzej czy później będziesz mieć aktywne subskrypcje bez wpłat. Webhook musi też weryfikować podpis, być odporny na duplikaty (to samo powiadomienie potrafi przyjść kilka razy) i na kolejność - powiadomienie może dotrzeć, zanim WooCommerce skończy zapisywać zamówienie.

Nieudane obciążenia i ponowienia. Brak środków, przekroczony limit, bank, który przestał obsługiwać usługę. Według dokumentacji BLIK bank przy braku środków może ponawiać autoryzację do 72 godzin, zanim zwróci odmowę - przez ten czas zamówienie wisi w stanie oczekującym. WooCommerce Subscriptions ma własną logikę ponowień, a operator swoją; trzeba je zgrać, żeby nie obciążać klienta dwa razy ani nie zawieszać subskrypcji, która za chwilę zostanie opłacona. U części operatorów nieudana transakcja nie jest ponawiana automatycznie - ponowienie musi zainicjować sklep.

Anulowanie w aplikacji banku. Klient może usunąć zgodę w aplikacji banku, nie zaglądając do sklepu. Jeśli moduł nie obsłuży powiadomienia o usunięciu aliasu, WooCommerce przy następnym odnowieniu spróbuje obciążyć nieistniejącą zgodę, a subskrypcja będzie wyglądać na aktywną. Analogicznie w drugą stronę: anulowanie subskrypcji w panelu WooCommerce powinno usuwać zgodę u operatora.

Testy na sandboxie. Sandbox pozwala przećwiczyć ścieżkę szczęśliwą, ale nie zawsze odwzorowuje wszystkie zachowania banków - odroczone odmowy, usunięcie zgody z aplikacji, różnice między bankami. Przygotuj listę scenariuszy (udane odnowienie, odmowa, duplikat webhooka, anulowanie po obu stronach, zmiana kwoty) i po starcie produkcji przeprowadź kontrolowane transakcje na niskich kwotach.

Harmonogram w WordPressie. Odnowienia uruchamia harmonogram zadań WooCommerce, który zależy od ruchu na stronie lub poprawnie skonfigurowanego crona. Na stronie z małym ruchem bez prawdziwego crona odnowienia potrafią się opóźniać.

Przykład z praktyki: Korabiewice

Dla schroniska w Korabiewicach budowałem landing „Przyjaciele Korabek”. Cel kampanii był konkretny: 1000 stałych darczyńców wpłacających około 50 zł miesięcznie. Przy takim celu liczy się każdy procent osób, które nie porzucą formularza na etapie płatności.

Pierwsza wersja opierała się na płatnościach cyklicznych kartą: WooCommerce Subscriptions plus Tpay. To sprawdzony zestaw, ale przy kampanii skierowanej do szerokiego grona darczyńców sama karta to za mało - wiele osób w Polsce płaci w internecie głównie BLIK-iem. Dlatego dorobiłem BLIK cykliczny jako własny moduł WooCommerce, działający obok płatności kartą w tym samym mechanizmie subskrypcji. Całość działa na PHP 8.3, a zdarzenia z formularza trafiają do Meta Pixel i GA4, żeby fundacja widziała, które kampanie przynoszą stałych darczyńców.

Przy takim wdrożeniu sama pierwsza płatność to mniejsza część pracy. Większa to wszystko, co dzieje się później: obsługa powiadomień, statusy przy nieudanych obciążeniach i synchronizacja z anulowaniem po stronie banku - czyli pułapki opisane wyżej. Szczegóły projektu opisałem w case study Korabiewice.

Podsumowanie

BLIK cykliczny w WooCommerce to dziś realna alternatywa dla subskrypcji kartowych - szczególnie przy darowiznach i abonamentach, gdzie klienci nie chcą zapisywać karty. Wdrożenie wymaga jednak więcej niż instalacji wtyczki: osobnej aktywacji u operatora, dobrze zrobionej obsługi webhooków i przemyślanej logiki odnowień. Płatności cykliczne WooCommerce to też system, który trzeba potem pilnować - aktualizacje wtyczek, zmiany API operatora, monitoring nieudanych odnowień. Tym zajmuję się w ramach opieki nad stroną.

Jeśli dopiero wybierasz platformę, zajrzyj do porównania WooCommerce czy PrestaShop. A jeśli chcesz uruchomić subskrypcje lub BLIK powtarzalny w swoim sklepie - zobacz, jak pracuję przy sklepach internetowych.

Najczęstsze pytania

Czy BLIK cykliczny działa w każdym banku?

Nie. Usługę obsługuje coraz więcej banków, ale nie wszystkie. Aktualną listę podaje operator płatności i strony banków - warto zostawić klientom alternatywę, np. kartę.

Czy gotowa wtyczka operatora wystarczy do BLIK-a cyklicznego w WooCommerce?

Zależy od operatora i wersji wtyczki. Często wtyczki obsługują subskrypcje kartą, ale nie BLIK powtarzalny - wtedy potrzebny jest własny moduł integrujący API operatora z WooCommerce Subscriptions.

Co się dzieje, gdy klient anuluje płatność w aplikacji banku?

Zgoda przestaje działać, a operator może wysłać o tym powiadomienie. Sklep powinien je odebrać i zmienić status subskrypcji, inaczej kolejne odnowienie zakończy się błędem.

Czy klient musi potwierdzać każdą płatność?

W modelach A i O nie - obciążenia są automatyczne na warunkach zgody. W modelu M klient potwierdza każdą transakcję w aplikacji banku.