Subskrypcja miała odnowić się automatycznie, klient czeka na dostęp albo wysyłkę, a w WooCommerce pojawia się błąd. Albo jeszcze gorzej: nie pojawia się nic i trudno stwierdzić, czy system w ogóle próbował pobrać pieniądze. Nieudane odnowienie subskrypcji WooCommerce nie ma jednej magicznej przyczyny. Problem może siedzieć w karcie, tokenie płatniczym, bramce, kolejce zadań albo WP-Cronie.

Dlatego nie zaczynaj od nerwowego klikania „ponów płatność”. Najpierw ustal, na którym etapie proces się zatrzymał: czy powstało zamówienie odnowieniowe, czy płatność została odrzucona, czy może zaplanowane zadanie wisi w kolejce. Poniżej masz prostą checklistę: subskrypcja, zamówienie, notatki, logi, Scheduled Actions, WP-Cron i konfiguracja bramki. Bez grzebania na ślepo i bez robienia z klienta sponsora podwójnego obciążenia.

Zanim klikniesz „ponów płatność” — ustal, co właściwie się zepsuło

Pierwszy krok jest banalny, ale często pomijany: sprawdź konkretną subskrypcję i zobacz, czy powstało powiązane zamówienie odnowieniowe. To rozdziela dwa zupełnie różne scenariusze.

Dwa różne scenariusze: brak renewal order albo odrzucona płatność

Jeżeli zamówienia odnowieniowego nie ma, problem może dotyczyć zaplanowanego zadania, WP-Cronu albo Action Schedulera. System mógł nie utworzyć renewal order w oczekiwanym czasie. Wtedy szukanie winy wyłącznie w bramce płatności przypomina sprawdzanie hamulców w samochodzie, który w ogóle nie wyjechał z garażu.

Jeżeli zamówienie istnieje, ale ma status błędu lub oczekiwania, kierunek jest inny: notatki zamówienia, logi bramki, metoda płatności i zapisany token. Zanim uruchomisz jakiekolwiek ponowienie, sprawdź też, czy za ten sam okres nie ma już udanej płatności albo drugiego zamówienia. To najprostszy sposób, żeby nie obciążyć klienta dwa razy.

Checklist: subskrypcja, zamówienie i Order Notes

Zacznij od numeru konkretnej subskrypcji, a potem przejdź do powiązanego zamówienia odnowieniowego. W samej subskrypcji sprawdź przypisaną metodę płatności oraz zapisany token płatniczy. Token jest potrzebny, aby bramka mogła wykorzystać zapisaną metodę przy automatycznym odnowieniu. Jeżeli go brakuje albo jest nieważny, płatność może się nie udać mimo tego, że metoda nadal wygląda na skonfigurowaną.

Następnie zajrzyj do Order Notes, czyli notatek zamówienia. Tam często widać komunikat bramki albo informację o próbie pobrania środków. Warto również sprawdzić logi WooCommerce oraz logi używanej bramki. Nie przeglądaj całego sklepu bez punktu zaczepienia. Jeden konkretny numer subskrypcji i jedno renewal order dają znacznie więcej niż chaotyczne klikanie po panelu.

Co może oznaczać komunikat błędu

Treść błędu może wskazywać na odrzuconą kartę, brak wystarczających środków, decyzję banku, błąd bramki albo problem z tokenem. Może też sugerować, że nie wykonało się zaplanowane zadanie. Nie traktuj jednak każdego komunikatu jak diagnozy na 100 procent. Nazwy błędów i dostępne opcje zależą od bramki, wersji rozszerzeń oraz konfiguracji sklepu.

Do dalszej analizy przekazuj tylko niezbędne informacje: komunikat błędu i identyfikator zamówienia. Nie wysyłaj tokenów płatniczych, kluczy API, danych kart ani pełnych logów zawierających dane klientów.

Scheduled Actions i Action Scheduler — gdzie kolejka utknęła

Zaplanowane akcje znajdziesz w panelu WordPressa pod adresem WooCommerce > Status > Scheduled Actions. To właśnie tam można sprawdzić zadania wykonywane w tle, w tym te związane z odnowieniami subskrypcji. Zobaczysz ich status, datę, grupę, a przy błędach także informacje z logów.

Wyszukuj po numerze subskrypcji, nazwie hooka, dacie albo grupie. Sprawdź, czy akcja jest oczekująca, zakończona, opóźniona czy oznaczona błędem. Jeżeli zadanie odnowienia utknęło, masz konkretny ślad, a nie tylko ogólne „WooCommerce nie działa”. Możesz też zobaczyć logi nieudanych akcji, a w niektórych sytuacjach ręcznie uruchomić akcję oczekującą.

Jak nie zgubić się w kolejce zadań

Pracuj od konkretu. Zacznij od identyfikatora subskrypcji albo zamówienia odnowieniowego i porównaj status akcji z notatkami zamówienia oraz logami WooCommerce. Sama obecność akcji w kolejce nie oznacza, że płatność została pobrana. Nie oznacza też automatycznie, że można ją bezpiecznie uruchomić ponownie.

Przed ręcznym uruchomieniem oczekującej akcji sprawdź historię zamówień i płatności za ten sam okres. Nie usuwaj zamówień ani logów przed zebraniem informacji. Czasem właśnie ten pozornie nudny wpis pozwala ustalić, czy problem dotyczy harmonogramu, czy dopiero kolejnego etapu, czyli obsługi płatności.

WP-Cron kontra bramka płatności — jak odróżnić te dwa problemy

Jeżeli zamówienie odnowieniowe nie powstało albo zaplanowana akcja jest opóźniona, sprawdź WP-Cron i Action Scheduler. WP-Cron uruchamia zadania przy żądaniach odwiedzających stronę. Przy małym ruchu zadania mogą więc wykonać się później, niż zakłada właściciel sklepu. Action Scheduler domyślnie korzysta z WP-Cronu, choć można skonfigurować serwerowy cron, żeby ograniczyć zależność od ruchu na stronie.

Jeżeli renewal order istnieje, a w jego notatkach pojawia się odmowa banku, problem z kartą, tokenem albo komunikatem API, przejdź do analizy bramki i zapisanej metody płatności. To praktyczny schemat, nie żelazna reguła. Błąd integracji może wystąpić także po utworzeniu akcji i zamówienia.

Szybki schemat: gdzie prowadzą ślady

• Brak renewal order: sprawdź WP-Cron, Action Scheduler i status zaplanowanych akcji.
• Renewal order z odmową: sprawdź notatki zamówienia, logi bramki, kartę i token.
• Opóźniona akcja: sprawdź, czy kolejka działa i czy zadanie nie czeka na wykonanie.
• Powtarzalny błąd: zweryfikuj integrację bramki oraz ewentualny konflikt wtyczek lub kodu.

Przed zmianą konfiguracji WP-Cronu, Action Schedulera albo bramki wykonaj kopię zapasową. Jeżeli sklep obsługuje aktywne płatności, zmianę najpierw przetestuj w środowisku testowym, jeśli takie środowisko jest dostępne.

Token płatniczy, karta i wyłączona wtyczka bramki

Nieudane odnowienie może wynikać z rzeczy leżącej po stronie klienta: wygasłej lub odrzuconej karty albo niewystarczających środków. Powodem może być też brakujący lub nieważny token płatniczy. W takiej sytuacji klient może potrzebować ponownie zapisać metodę płatności, a przy problemie z kartą — zaktualizować jej dane, o ile konfiguracja sklepu na to pozwala.

Sprawdź również, czy wtyczka bramki nie została całkowicie wyłączona. To nie to samo co wyłączenie samej metody płatności w ustawieniach. Całkowite wyłączenie wtyczki może sprawić, że subskrypcje korzystające z tej bramki przejdą na ręczne odnowienia.

Automatyczne odnowienia zależą od integracji bramki

Aktywna metoda płatności nie oznacza automatycznie, że każda kolejna rata zostanie pobrana bez udziału klienta. WooCommerce rozróżnia automatyczne i ręczne odnowienia, a obsługa automatycznych płatności zależy od integracji konkretnej wtyczki bramki z WooCommerce Subscriptions. Różne bramki mogą obsługiwać ten proces w różny sposób.

Jeśli problem dotyczy wielu subskrypcji, tokenów albo pojawił się po aktualizacji, nie rób masowych ręcznych ponowień. Bezpieczniej zaangażować osobę techniczną albo support dostawcy bramki.

Automatyczne retry i ręczne ponowienie — to nie to samo

WooCommerce Subscriptions ma osobny system automatycznych ponowień nieudanych płatności, czyli retry. Nie myl go z ręcznym kliknięciem akcji ponowienia. System retry jest domyślnie wyłączony. Jego ustawienia znajdziesz w WooCommerce > Settings > Subscriptions, w sekcji Payment recovery. Działa jednak tylko dla określonych konfiguracji i nie każdej bramki.

Ręczne ponowienie może być dostępne jako Retry Renewal Payment. Warunki zależą między innymi od statusu zamówienia, dodatniej kwoty, ustawionej metody płatności oraz tego, czy bramka obsługuje wymagany sposób ponowienia. Jeżeli konfiguracja na to pozwala, klient może również opłacić nieudane zamówienie z poziomu swojego konta.

Kiedy przycisk ponowienia może się nie pojawić

Brak przycisku nie musi oznaczać błędu panelu. Najpierw sprawdź status zamówienia odnowieniowego, jego kwotę i przypisaną metodę płatności. Następnie zweryfikuj, czy bramka pozwala na taki sposób ponowienia oraz czy nie ma już zapisanej historii retry.

Przed ręcznym retry sprawdź notatki, historię płatności i to, czy klient nie został już obciążony. Nie uruchamiaj kilku prób równocześnie. Ręczne ponowienie nie jest magicznym przyciskiem „napraw wszystko”, tylko kolejnym krokiem, który ma sens dopiero po ustaleniu, co wydarzyło się wcześniej.

Czego nie robić, żeby nie narobić większego bałaganu

Największy błąd to działanie na skróty. Nie ponawiaj płatności bez sprawdzenia, czy nie istnieje już udane obciążenie albo inne zamówienie odnowieniowe za ten sam okres. Nie zmieniaj ręcznie statusu subskrypcji ani danych w bazie tylko po to, żeby przywrócić pole Next Payment. Nie usuwaj zamówień i logów przed ich zabezpieczeniem oraz analizą.

Przed zmianami wykonaj kopię zapasową. Przy aktywnych płatnościach zaplanuj test, jeśli masz środowisko testowe. I jeszcze jedno: nie przekazuj nikomu pełnych logów z danymi klientów, kluczy API ani tokenów płatniczych. Do diagnozy zwykle wystarczy komunikat i identyfikator zamówienia.

Kiedy skończyć samodzielne sprawdzanie

Jeśli ten sam błąd dotyczy wielu subskrypcji, powtarza się po aktualizacji albo wiąże się z tokenami i automatycznymi odnowieniami, czas przekazać sprawę osobie technicznej lub supportowi bramki. Dokumentacja opisuje mechanizm ogólny, ale bez danych z konkretnego sklepu nie da się uczciwie wskazać jednej przyczyny.

Najpierw ustal więc, czy nie powstało zamówienie odnowieniowe, czy powstało, ale płatność została odrzucona. Potem sprawdź konkretną subskrypcję, Order Notes, logi, Scheduled Actions, WP-Cron i integrację bramki. Dopiero na tej podstawie wybierz ręczne retry, aktualizację metody płatności albo dalszą analizę techniczną. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.