WooCommerce nie przyjmuje zamówień – checklista diagnostyczna

Klient pisze, że „nie da się kupić”. Sklep otwiera się normalnie, produkty są na miejscu, a w panelu od kilku godzin nie przybyło ani jedno zamówienie. To najdroższa awaria, jaka może spotkać sklep, bo w przeciwieństwie do padniętej strony nie widać jej gołym okiem: sklep wygląda na sprawny i przez cały ten czas nie sprzedaje.

Ten poradnik prowadzi przez diagnozę w kolejności, w jakiej robi to ktoś, kto naprawia sklepy WooCommerce na co dzień: od ustalenia, gdzie urywa się zamówienie, przez bramkę płatności i kolejkę zadań, po rozliczenie zamówień z czasu awarii. Osobna sekcja tłumaczy, dlaczego typowy monitoring strony tej awarii nie zauważa.

Jeśli licznik już bije i wolisz od razu oddać to komuś, kto robi to zawodowo – +48 575 067 607.

Wykonaj po kolei i zapisuj wyniki – przy tej awarii najwięcej czasu traci się na powtarzanie tych samych sprawdzeń.

1. Złóż testowe zamówienie sam, w oknie prywatnym, jako niezalogowany klient. Dopiero to pokazuje, gdzie ścieżka się urywa – relacja klienta („nie działa”) nie zawęża niczego.
2. Sprawdź listę zamówień (WooCommerce → Zamówienia) z ostatnich godzin. Zamówienia w ogóle nie powstają czy powstają i stoją jako „oczekujące na płatność”? To dwie różne awarie.
3. Ustal, co zmieniło się w ostatnich 72 godzinach: aktualizacja WooCommerce, wtyczki płatności, motywu, wersji PHP, zmiana w panelu bramki, wygaśnięcie klucza API.
4. Otwórz konsolę przeglądarki na stronie kasy (F12 → Konsola i Sieć) i spróbuj złożyć zamówienie. Czerwone błędy JavaScript i żądania ?wc-ajax= z kodem 4xx lub 5xx wskazują winowajcę bez zgadywania.
5. Sprawdź metody płatności (WooCommerce → Ustawienia → Płatności): czy są włączone i czy bramka nie stoi w trybie testowym, w którym prawdziwe płatności nie przechodzą.
6. Zajrzyj do dzienników (WooCommerce → Status → Dzienniki) – źródła Twojej bramki oraz transactional-emails.
7. Sprawdź zaplanowane działania (WooCommerce → Status → Zaplanowane działania). Zaległości starsze niż doba znaczą, że kolejka zadań w tle stoi.
8. Wyczyść cache – wtyczki, hostingu i CDN – i sprawdź, czy strony Koszyk, Zamówienie i Zrealizowane zamówienie są z cache'owania wyłączone.
9. Zajrzyj do panelu bramki płatności. Czy transakcje z ostatnich godzin w ogóle do niej docierają? To rozstrzyga, czy problem jest przed płatnością, czy po niej.

Ścieżka zakupowa ma cztery etapy i awaria każdego wygląda dla klienta tak samo – „nie da się kupić”. Dla Ciebie to cztery różne listy podejrzanych.

Najszybszy sposób odróżnienia: czy powstał numer zamówienia. Jeśli tak, zamówienie zapisało się w bazie i awaria jest za tym punktem – w płatności albo w potwierdzeniu. Jeśli klient nigdy nie zobaczył numeru, przyczyna jest w koszyku albo w kasie.

Osobny przypadek: kasa zwraca błąd serwera zamiast strony. To nie jest problem konfiguracji, tylko awaria aplikacji – przyczyny i naprawę błędu 500 ({{URL_BLAD_500}}) opisaliśmy osobno. A jeśli wszystko zaczęło się dokładnie po aktualizacji, pierwszym ruchem jest cofnięcie zmiany, nie diagnoza kasy: WordPress przestał działać po aktualizacji ({{URL_TEMAT_1}}).

Test zrobiony byle jak potrafi „potwierdzić”, że wszystko działa, w sklepie, który od rana nie sprzedaje. Warunki:

1. Okno prywatne, wylogowany, bez rozszerzeń przeglądarki. Zalogowany administrator omija część cache'u i część reguł wtyczek.
2. Prawdziwa płatność, nie tryb testowy. Tryb testowy nie sprawdza tego, co najczęściej pada: produkcyjnych kluczy i kanału zwrotnego. Zrób ukryty produkt za złotówkę.
3. Doprowadź płatność do końca i wróć na stronę podziękowania. Powrót z bramki jest osobnym krokiem i osobno się psuje.
4. Sprawdź komplet: numer i status zamówienia, mail do klienta, mail do sklepu, transakcję w panelu bramki, zamówienie w systemie magazynowym i fakturę.
5. Zwróć płatność i odnotuj, że to była transakcja testowa.

Powtórz test na dwóch metodach płatności – to dwie różne ścieżki w kodzie i jedna potrafi działać, gdy druga leży. Zrób też jedno podejście na telefonie: część awarii kasy dotyczy wyłącznie urządzeń mobilnych, gdzie optymalizacja skryptów działa inaczej.

Integracja płatności ma trzy warstwy i awaria może siedzieć w dowolnej: wtyczka w sklepie, konfiguracja u operatora oraz kanał zwrotny (webhook, IPN), którym operator informuje sklep o zapłacie.

Najczęstsza pojedyncza przyczyna to rozjazd wersji po aktualizacji WooCommerce: duża aktualizacja bez równoczesnej aktualizacji wtyczki płatności potrafi wyłączyć płatności bez żadnego komunikatu. Jeśli aktualizowałeś WooCommerce w ciągu doby, zacznij tutaj.

Diagnozę robi się logiem: włącz logowanie w ustawieniach wtyczki płatności, złóż testowe zamówienie i przeczytaj wynik w WooCommerce → Status → Dzienniki. Log zapisuje wyłącznie nowe transakcje, więc bez testowego zamówienia będzie pusty.

Drugi sygnał, tani i pewny: notatki zamówienia. Brak choćby jednej notatki od bramki znaczy, że bramka nigdy nie odezwała się do sklepu – problem jest w komunikacji, nie w płatności.

Status „oczekujące na płatność” znaczy według dokumentacji WooCommerce dokładnie tyle: zamówienie zostało przyjęte, ale płatność nie została dokonana. Pod jednym statusem kryją się jednak dwie różne sytuacje:

• Klient nie zapłacił – porzucił stronę operatora, karta została odrzucona, rozmyślił się. Pewien odsetek takich zamówień ma każdy sklep i to jest normalne.
• Klient zapłacił, a sklep się o tym nie dowiedział – pieniądze są u operatora, kanał zwrotny nie zadziałał. To awaria kosztująca podwójnie: nie wysyłasz towaru, za który już Ci zapłacono.

Rozróżnia je jedno porównanie: lista transakcji u operatora zestawiona z listą zamówień w sklepie. Opłacona transakcja, której nie odpowiada zamówienie „przetwarzane”, to drugi przypadek.

Sygnałem ostrzegawczym jest nie sama liczba, tylko jej zmiana. Udział „oczekujących” w sprawnym sklepie jest w miarę stały, a jego skok to najwcześniejszy dowód, że kanał zwrotny padł – wcześniejszy niż pierwszy telefon od klienta.

Jest jeszcze jedna, myląca konsekwencja: zamówienie „oczekujące na płatność” nie wyzwala żadnego maila. Jeśli klient skarży się na brak potwierdzenia, a Ty nie dostałeś powiadomienia o zamówieniu – to niekoniecznie awaria poczty, tylko ten sam problem widziany z drugiej strony.

Awaria poczty ma dwa kierunki i drugi jest groźniejszy. Klient bez potwierdzenia zadzwoni. Ty bez powiadomienia o nowym zamówieniu nie zadzwonisz do nikogo – przez kilka dni nie zauważysz, że sprzedaż stanęła.

WooCommerce zapisuje każdą próbę wysłania wiadomości transakcyjnej: WooCommerce → Status → Dzienniki, źródło transactional-emails. Ten jeden ekran rozstrzyga w minutę, po której stronie leży problem:

Jeśli widnieje Sent, a wiadomości nie ma, sklep zrobił swoje i przyczyna jest w poczcie: brak SMTP, nieuwierzytelniony nadawca, adres spoza Twojej domeny, filtr po stronie odbiorcy. To osobny temat – rozpisaliśmy go przy okazji formularza, który nie wysyła wiadomości ({{URL_TEMAT_12}}), razem z konfiguracją SMTP i uwierzytelnianiem domeny.

WooCommerce przechowuje dziś zamówienia we własnych tabelach bazy (HPOS – wydajny magazyn zamówień), a nie w tabelach wpisów WordPressa. Wtyczka pisana pod stary sposób zapisu potrafi czytać puste dane albo zapisywać w miejsce, do którego sklep już nie zagląda.

Objaw jest podstępny, bo sklep sprzedaje: zamówienie powstaje i klient je opłaca, ale wtyczka wystawiająca fakturę, drukująca etykietę albo wysyłająca dane do magazynu go nie widzi – lub widzi je bez pól, które sama wcześniej zapisała.

Stan zgodności sprawdzisz w WooCommerce → Ustawienia → Zaawansowane → Funkcje; wymienione są tam wtyczki, które nie zadeklarowały zgodności. Jest tam też tryb zgodności synchronizujący zamówienia do starych tabel – przystań na czas naprawy, nie stan docelowy, bo każde zamówienie zapisuje się wtedy dwa razy.

Kasa nie pokaże metod płatności, jeśli wcześniej nie ustali metody dostawy. To najczęstsze źródło pomyłki w diagnozie: objaw wygląda na awarię płatności, a przyczyna siedzi w wysyłce. Typowe scenariusze:

• Strefa wysyłki bez metody dla kraju albo kodu pocztowego klienta. Klient z Warszawy kupi, klient z Rzeszowa nie – bo trafił w strefę, w której nikt nie dodał metody.
• Produkt bez wagi lub wymiarów przy metodzie liczącej po wadze. Jeden nowy produkt z pustymi polami wywraca kasę dla każdego koszyka, w którym się znajdzie.
• Wtyczka kurierska pytająca zewnętrzne API, które przestało odpowiadać. Kasa czeka do przekroczenia limitu czasu, a klient widzi ekran, który się nie kończy.
• Weryfikacja NIP albo podatku przez zewnętrzną usługę – gdy usługa milczy, walidacja nie przechodzi, a komunikat nic klientowi nie tłumaczy.
• Blokowa kasa i wtyczka wspierająca tylko klasyczny skrót. Pole albo metoda się nie renderuje. Przełączenie kasy na wariant klasyczny to obejście na wieczór, nie rozwiązanie.

Wspólny mianownik trzech z pięciu punktów: kasa zależy od usługi poza Twoim serwerem. Szybki test to tymczasowe włączenie prostej, ryczałtowej metody dostawy – jeśli kasa wtedy rusza, problem jest w wyliczaniu, nie w kasie.

Ta awaria nie zatrzymuje sprzedaży, więc nikt jej nie zgłasza. Sklep przyjmuje zamówienia, klienci płacą, tylko magazyn ich nie widzi i faktury się nie wystawiają – zauważasz to po dwóch dniach, przy paczkach, które nie wyszły. Trzy przyczyny pokrywają większość przypadków:

1. Klucz API albo token wygasł lub został zmieniony – po stronie sklepu albo usługi zewnętrznej.
2. Kolejka zadań w tle stoi. WooCommerce wykonuje synchronizacje przez Action Scheduler, a ten domyślnie opiera się na WP-Cron. WP-Cron nie jest prawdziwym harmonogramem – uruchamia się przy okazji ruchu na stronie, więc sklep bez odwiedzin przez kilka nocnych godzin nie wykonuje zadań na czas.
3. Zmiana magazynu zamówień, a integracja czytająca stare tabele – przypadek z poprzedniej sekcji.

Stan kolejki sprawdzisz w WooCommerce → Status → Zaplanowane działania. Pojedyncze zaległe zadania są normalne; starsze niż doba znaczą, że coś stoi.

Trwałe rozwiązanie to wyłączenie WP-Cron i uruchomienie harmonogramu po stronie serwera. W wp-config.php:

I zadanie cykliczne na serwerze (w panelu hostingu zwykle sekcja „Zadania cykliczne” albo „Cron”):

To najważniejsza część naprawy, bo dotyczy pieniędzy, które już wpłynęły. Kolejność:

1. Ustal okno awarii co do godziny – z logu bramki, pierwszego zgłoszenia albo momentu ostatniego poprawnego zamówienia.
2. Pobierz z panelu operatora listę transakcji z tego okna. To lista prawdy: pieniądze albo wpłynęły, albo nie.
3. Zestaw ją z zamówieniami w sklepie po numerze zamówienia i kwocie. Wyjdą trzy grupy:

• opłacone, zamówienie w statusie „przetwarzane” – nic nie robisz;
• opłacone, zamówienie „oczekujące” albo „nieudane” – ręcznie zmieniasz status i dopisujesz notatkę z identyfikatorem transakcji;
• opłacone, a zamówienia nie ma wcale (anulowane przez limit wstrzymania stanu magazynowego albo nigdy nie powstało) – kontakt z klientem i decyzja: zamówienie zakładane ręcznie albo zwrot pieniędzy.

1. Sprawdź stany magazynowe. Zamówienia „nieudane” i „anulowane” zwróciły towar na magazyn, więc po ręcznej korekcie statusów stany mogą się nie zgadzać.
2. Napisz do klientów z tego okna, zanim oni napiszą do Ciebie. Wiadomość wysłana z własnej inicjatywy ratuje zamówienie; odpowiedź na reklamację ratuje najwyżej opinię.

Wzór, który wystarczy uzupełnić:

Dzień dobry, w [data, godziny] nasz sklep miał awarię płatności. Zamówienie [numer] zostało opłacone, ale nie zapisało się poprawnie w naszym systemie – już to naprawiliśmy. Zamówienie jest w realizacji i wyśle się [termin], płatność została zaksięgowana i nie trzeba płacić ponownie. Przepraszamy za zamieszanie.

Jest jeszcze jedna grupa, której nie zobaczysz na żadnej liście: klienci, którzy chcieli kupić, nie mogli i poszli gdzie indziej. Nie ma po nich śladu nigdzie i to oni są głównym kosztem takiej awarii.

Typowy monitoring pyta o adres strony głównej i sprawdza kod odpowiedzi. Sklep, który nie przyjmuje zamówień, odpowiada 200 OK – strona główna renderuje się poprawnie, strona kasy zresztą też. Brak metody płatności w kasie jest treścią strony, nie jej statusem, więc monitoring dostępności nie ma tego jak zobaczyć.

Cztery awarie mieszczą się w całości w odpowiedzi „200 OK”: metoda płatności zniknęła z kasy po aktualizacji, kanał zwrotny bramki nie działa i zamówienia stoją jako „oczekujące”, wiadomości o zamówieniach nie wychodzą, kolejka zadań stoi i integracja nie dostaje zamówień. Wspólny mianownik: awaria siedzi w przepływie, nie w dostępności. Stąd różnica między monitoringiem strony a monitoringiem sprzedaży:

Dwa najtańsze mechanizmy z tej tabeli dają najwięcej: alarm, gdy przez określony czas nie wpłynie ani jedno zamówienie (próg ustawiasz na podstawie własnego rytmu sprzedaży) i alarm, gdy udział zamówień „oczekujących” przekroczy zwykły poziom. Pierwszy łapie każdą awarię ścieżki zakupowej niezależnie od przyczyny, drugi – awarię kanału zwrotnego, zanim zadzwoni pierwszy klient.

To różnica między monitoringiem uptime a monitoringiem kasy i płatności – i to drugie stoi w naszym pakiecie opieki nad sklepem WooCommerce, obok testów ścieżki zakupowej po każdej aktualizacji.

Większość przyczyn z tej listy usuwa się samodzielnie w kilkadziesiąt minut. Są jednak sytuacje, w których dalsze próby kosztują więcej niż pomoc:

• Od pierwszego zgłoszenia minęła godzina, a sklep dalej nie sprzedaje. Policz stawkę: średnia liczba zamówień na dobę podzielona przez dwadzieścia cztery, razy średnia marża. To cena każdej godziny eksperymentowania.
• Nie masz dostępu do panelu bramki płatności albo nie wiesz, kto go ma. Bez tego panelu nie sprawdzisz, czy pieniądze w ogóle wpłynęły.
• Trop prowadzi do kodu pisanego na zamówienie w motywie albo we wtyczce bez wsparcia autora. Wyłączenie go potrafi „naprawić” kasę i przy okazji wyłączyć wystawianie faktur.
• Trzeba rozliczyć zamówienia z okna awarii. To praca na cudzych pieniądzach, przy której pomyłka jest droższa niż sama awaria.
• Awaria wraca po każdej aktualizacji. To nie awaria, tylko dług techniczny – stare wtyczki płatności, motyw z własnymi zmianami w kasie, aktualizacje wchodzące od razu na sklep. Naprawianie skutku co miesiąc nie usuwa przyczyny, a każdy taki miesiąc ma cenę: policzyliśmy ją w tekście o kosztach utrzymania sklepu WooCommerce ({{URL_TEMAT_6}}).
• Widzisz ślady włamania – nieznane pliki, zmienione konta administratora, przekierowania pojawiające się tylko w kasie. Kasa jest pierwszym celem ataku, bo tam przechodzą płatności.

Do wyboru są dwie drogi. Jednorazowa naprawa: ktoś z dostępem do logów ustala przyczynę, przywraca sprzedaż i rozlicza zamówienia z okna awarii. Albo stała opieka, przy której aktualizacje wchodzą najpierw na kopię, ścieżka zakupowa jest testowana po każdej zmianie, a awaria kasy zostaje wykryta, zanim zauważy ją klient. Pakiety zaczynają się od 349 zł netto miesięcznie; wersja dla sklepów, z monitoringiem kasy i płatności, nazywa się Opieka Sklep.

Sklep, który nie przyjmuje zamówień, prawie nigdy nie jest „zepsuty” w całości. Zamówienie urywa się w jednym z czterech miejsc – koszyku, kasie, płatności albo potwierdzeniu – i cała diagnoza polega na ustaleniu, w którym. Najszybsza droga to własne zamówienie testowe doprowadzone do końca, a potem log bramki, lista „oczekujących” i kolejka zadań. Naprawa kończy się dopiero wtedy, gdy rozliczysz zamówienia z okna awarii: pieniądze, które wpłynęły, a nie mają swojego zamówienia, to najdroższa część całej sprawy.

Jeśli sklep stoi teraz albo ta sama awaria wraca po kolejnych aktualizacjach, zadzwoń: +48 575 067 607. Sprawdzimy logi bramki, przywrócimy sprzedaż i pokażemy, które zamówienia z czasu awarii trzeba rozliczyć ręcznie. Współpracę zaczynamy od przeglądu sklepu – wersje, wtyczki, kopie zapasowe, ścieżka zakupowa – bo bez tego stała opieka byłaby pilnowaniem stanu, którego nikt nie sprawdził. Awarię wyłączającą sprzedaż bierzemy poza kolejnością.

Źródła:

• Order Statuses – dokumentacja WooCommerce: https://woocommerce.com/document/managing-orders/order-statuses/
• Troubleshooting Orders – dokumentacja WooCommerce: https://woocommerce.com/document/managing-orders/troubleshooting-orders/
• Email troubleshooting – dokumentacja WooCommerce: https://woocommerce.com/document/email-faq/
• High-Performance Order Storage – dokumentacja WooCommerce: https://woocommerce.com/document/high-performance-order-storage/
• Cart and Checkout Blocks – dokumentacja WooCommerce: https://woocommerce.com/document/cart-checkout-blocks-status/
• Products Settings (Hold stock) – dokumentacja WooCommerce: https://woocommerce.com/document/configuring-woocommerce-settings/products/
• Scheduled actions – dokumentacja WooCommerce: https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/scheduled-actions/
• Action Scheduler FAQ: https://actionscheduler.org/faq/
• Hooking WP-Cron Into the System Task Scheduler – dokumentacja WordPress: https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/