Klient zapłacił, ale zamówienie ma status „wstrzymane" - analiza

Klient dzwoni albo pisze: „zapłaciłem, mam potwierdzenie z banku, a w sklepie dalej widzę, że zamówienie jest wstrzymane”. Ty patrzysz w panel i faktycznie – zamówienie wisi ze statusem Wstrzymane, a pieniądze u operatora są. To jeden z najbardziej stresujących błędów w sklepie, bo dotyka bezpośrednio zaufania kupującego i twojego cash flow.

Dobra wiadomość: przyczyn jest skończona liczba i da się je przejść po kolei. Poniżej ścieżka diagnostyczna, która w większości przypadków doprowadza do sprawcy w kilkanaście minut.

Szybka ścieżka – jeśli masz mało czasu

Otwórz zamówienie i przeczytaj notatki zamówienia. Jeśli nie ma tam wpisu od bramki płatniczej, powiadomienie od operatora nigdy nie dotarło.
Sprawdź w panelu operatora, czy transakcja ma status zakończona, a nie „rozpoczęta” lub „oczekująca”.
Sprawdź adres powiadomienia (IPN / webhook) w panelu operatora – czy zgadza się z aktualną domeną, protokołem i wersją z „www” lub bez.
Sprawdź, czy zapora (WAF, wtyczka bezpieczeństwa, ModSecurity, tryb konserwacji) nie blokuje żądań POST od operatora.
Sprawdź WooCommerce → Status → Zaplanowane działania – jeśli kolejka jest zapchana, to nie płatności są problemem, tylko cron.

A teraz to samo, tylko z wyjaśnieniem, dlaczego każdy z tych kroków ma sens.

Co właściwie oznacza status „wstrzymane”

W WooCommerce status Wstrzymane (technicznie wc-on-hold) znaczy jedno: zamówienie jest przyjęte, stan magazynowy został zdjęty, ale sklep nie ma potwierdzenia, że pieniądze wpłynęły. To nie jest błąd sam w sobie. To stan oczekiwania.

Warto odróżnić trzy podobne statusy, bo mylenie ich prowadzi do złej diagnozy:

Status	Co oznacza	Czy zdejmuje stan magazynowy
Oczekujące na płatność	Klient złożył zamówienie, ale nie rozpoczął albo nie dokończył płatności	Nie
Wstrzymane	Sklep czeka na potwierdzenie wpłaty	Tak
W trakcie realizacji	Płatność potwierdzona, zamówienie do wysyłki	Tak
Nieudane	Płatność odrzucona lub przerwana błędem	Nie

Kluczowy wniosek: skoro „wstrzymane” już zdjęło towar z magazynu, to ręczna zmiana statusu na „w trakcie realizacji” nie zdejmie go po raz drugi. WooCommerce pilnuje tego wewnętrznym znacznikiem. Jeśli mimo to widzisz rozjazdy w stanach, to osobny temat i opisaliśmy go w tekście o stanach magazynowych, które się nie zgadzają.

Zanim zaczniesz – ustal skalę

Trzy pytania, które oszczędzą ci godziny szukania w złym miejscu:

Jedno zamówienie czy wszystkie? Jedno wskazuje na konkretną transakcję albo metodę płatności. Wszystkie od pewnej godziny wskazują na konfigurację, aktualizację albo zaporę.
Od kiedy? Sprawdź datę pierwszego problematycznego zamówienia, a potem sprawdź, co się wtedy działo: aktualizacja wtyczki, zmiana hostingu, przedłużenie certyfikatu, włączenie Cloudflare, migracja domeny.
Która metoda płatności? Jeśli tylko jedna z kilku – problem jest po stronie tej konkretnej integracji, a nie sklepu jako całości.

Filtr statusu na liście zamówień plus sortowanie po dacie odpowiada na wszystkie trzy pytania w dwie minuty.

Krok 1. Przeczytaj notatki zamówienia

To najważniejsze źródło informacji w całym procesie i najczęściej pomijane. Otwórz zamówienie i spójrz na prawą kolumnę: Notatki zamówienia.

Szukasz wpisów systemowych od bramki płatniczej. Możliwe scenariusze:

Brak jakiegokolwiek wpisu od bramki – powiadomienie od operatora nigdy nie dotarło do sklepu. Idź do kroku 4 i 5.
Wpis typu „rozpoczęto płatność”, „przekierowano do operatora” i nic dalej – klient wyszedł do bramki, ale sklep nie dostał odpowiedzi zwrotnej. To ten sam trop.
Wpis o błędzie weryfikacji podpisu, niezgodnej sumie kontrolnej, błędnym kluczu – powiadomienie dotarło, ale sklep je odrzucił. Idź do kroku 6.
Wpis o niezgodnej kwocie lub walucie – operator potwierdził inną kwotę niż zamówienie. Idź do kroku 7.
Wpis „płatność zatwierdzona, oczekuje na pobranie środków” – to autoryzacja bez obciążenia. Zobacz sekcję o przypadkach szczególnych.
Wpis o zmianie statusu przez użytkownika lub inną wtyczkę – ktoś albo coś przestawiło status po fakcie. Idź do kroku 9.

Uzupełniająco włącz dzienniki w ustawieniach samej bramki (większość wtyczek płatności ma opcję „tryb debugowania” albo „zapisuj dzienniki”) i zajrzyj do WooCommerce → Status → Dzienniki. Zobaczysz tam surową treść komunikatów od operatora.

Krok 2. Ustal, jaką metodą klient zapłacił

Rozgałęzienie, od którego zależy wszystko dalej.

Przelew bankowy / przelew tradycyjny (BACS)

Jeśli w zamówieniu widnieje „przelew bankowy”, to status „wstrzymane” jest prawidłowy i oczekiwany. WooCommerce nie ma dostępu do twojego konta bankowego i nie ma jak wiedzieć, że wpłata przyszła. Nic się nie zepsuło – po prostu ten proces wymaga ręcznego księgowania albo integracji z bankiem lub systemem księgowym.

Jeśli takich zamówień masz dużo, to nie jest to problem techniczny, tylko procesowy. Rozwiązania: automatyczne pobieranie wyciągów przez integrację księgową, wtyczka do parsowania wyciągów albo po prostu ustalona pora dnia na księgowanie.

Bramka płatnicza (BLIK, karta, szybki przelew, portfel)

Tu status „wstrzymane” po opłaconej transakcji to realna usterka. Idź dalej.

Płatność przy odbiorze

Część konfiguracji ustawia takie zamówienia na „wstrzymane” celowo, do momentu potwierdzenia. Sprawdź ustawienia metody – jeśli to zamierzone, nie ma czego naprawiać.

Krok 3. Zajrzyj do panelu operatora płatności

Zaloguj się do panelu operatora (PayU, Przelewy24, Tpay, Autopay, imoje, Stripe, PayPal – zależnie od tego, czego używasz) i znajdź transakcję po numerze zamówienia lub kwocie.

Interesuje cię dokładny status transakcji, nie sam fakt jej istnienia:

Zakończona / opłacona / rozliczona – pieniądze są u operatora, a sklep o tym nie wie. Problem leży w komunikacji zwrotnej. Krok 4.
Rozpoczęta / oczekująca / w trakcie – operator też jeszcze nie ma potwierdzenia z banku. Zdarza się przy przelewach z niektórych banków i przy odroczonych płatnościach. Poczekaj i sprawdź ponownie.
Do weryfikacji / wstrzymana przez system antyfraudowy – transakcja czeka na decyzję operatora. Sklep zachowuje się poprawnie.
Brak transakcji – klient mógł zapłacić za inne zamówienie (np. ponowił zakup i stare zostało puste) albo wykonał przelew ręcznie. Sprawdź, czy w sklepie nie ma bliźniaczego zamówienia z tą samą kwotą i adresem.

Ten krok rozstrzyga, po czyjej stronie szukać dalej. Jeśli operator pokazuje „zakończona”, a sklep „wstrzymane”, masz klasyczny problem z powiadomieniem zwrotnym.

Krok 4. Sprawdź adres powiadomienia (IPN / webhook)

Mechanika jest prosta. Po udanej płatności operator wysyła na wskazany adres twojego sklepu żądanie serwerowe („zamówienie 1042 opłacone, kwota 249 zł, podpis: …”). Wtyczka to odbiera, weryfikuje i zmienia status. Klient wraca do sklepu osobno, przeglądarką – to dwa niezależne kanały. Dlatego klient może zobaczyć „dziękujemy za zakup”, a status i tak zostaje niezmieniony.

W panelu operatora znajdź pole nazywane różnie: adres powiadomień, URL raportów, notify URL, webhook endpoint, IPN. Sprawdź po kolei:

Protokół – czy jest https://, a nie http://. Przekierowanie z http na https gubi treść żądania POST.
Wersja domeny – z „www” czy bez. Musi być identyczna z tą, na której faktycznie działa sklep. Tu też przekierowanie zabija żądanie.
Aktualność domeny – po migracji ze starej domeny lub z adresu testowego adres powiadomień bardzo często zostaje stary. To jedna z najczęstszych przyczyn.
Ścieżka – dokładny format podaje dokumentacja twojej wtyczki płatności. Najczęściej wygląda jak https://twojsklep.pl/?wc-api=nazwa_bramki albo https://twojsklep.pl/wc-api/nazwa_bramki/.

Szybki test: wywołaj ten adres i sprawdź, co odpowiada serwer.

curl -I "https://twojsklep.pl/?wc-api=nazwa_bramki"

Interpretacja odpowiedzi:

200 – punkt końcowy żyje, szukaj dalej w kroku 6.
301 / 302 – jest przekierowanie i najpewniej to twój problem. Popraw adres w panelu operatora na docelowy.
403 – coś blokuje. Krok 5.
404 – zły adres albo rozsypane bezpośrednie odnośniki. Wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany” bez zmieniania niczego. To odbudowuje reguły przepisywania.
503 / strona konserwacji – sklep jest w trybie konserwacji albo za hasłem. Operator dostaje to samo.

Krok 5. Sprawdź, co blokuje powiadomienie

Adres jest poprawny, a powiadomienia nadal nie ma? Najczęstsi winowajcy, w kolejności prawdopodobieństwa:

Zapora aplikacyjna (WAF) – Cloudflare, zapora hostingu, wtyczka bezpieczeństwa. Zajrzyj do dziennika zdarzeń zapory i poszukaj zablokowanych żądań z czasu płatności. Rozwiązanie: dodaj adresy IP operatora do listy dozwolonych. Operatorzy publikują je w dokumentacji technicznej.
ModSecurity na serwerze – reguły potrafią odrzucać żądania POST z nietypowym nagłówkiem lub bez przeglądarkowego user agenta. Hosting może wyłączyć konkretną regułę dla tej ścieżki. Poproś o dziennik ModSecurity z konkretną datą i godziną.
Ochrona hasłem lub tryb konserwacji – klasyk po pracach na sklepie. Wtyczka „coming soon” zostaje włączona i nikt tego nie zauważa, bo zalogowany administrator widzi normalną stronę.
Blokada REST API – część wtyczek bezpieczeństwa wyłącza REST API „dla niezalogowanych”. Nowsze integracje płatności z tego korzystają.
Pamięć podręczna – jeśli punkt końcowy płatności trafił do cache, operator dostaje zapisaną odpowiedź, a kod wtyczki w ogóle się nie wykonuje. Dodaj wykluczenie dla adresów z wc-api.
Blokada ruchu zagranicznego lub botów – część operatorów wysyła powiadomienia z zagranicznych centrów danych.
Certyfikat SSL lub stara wersja TLS – jeśli certyfikat wygasł albo serwer obsługuje tylko przestarzałe protokoły, operator nie nawiąże połączenia. Sprawdź datę ważności certyfikatu, zwłaszcza jeśli problem zaczął się z dnia na dzień.

Wskazówka praktyczna: poproś operatora o dziennik prób wysłania powiadomienia dla konkretnej transakcji. Prawie każdy udostępnia to w panelu lub przez wsparcie. Zobaczysz wtedy kod odpowiedzi, którą dostał twój serwer – i to od razu wskazuje winowajcę.

Krok 6. Klucze, podpisy i tryb testowy

Powiadomienie dociera, ale sklep je odrzuca. Notatki zamówienia pokazują wtedy komunikat o błędnym podpisie lub braku autoryzacji. Sprawdź:

Tryb testowy kontra produkcyjny – klasyczna pułapka po wdrożeniu. Wtyczka pracuje na kluczach testowych, a klienci płacą prawdziwie (albo odwrotnie). Sprawdź przełącznik trybu i to, czy klucze pochodzą z właściwego środowiska.
Klucz lub sól po zmianie w panelu operatora – jeśli ktoś wygenerował nowy klucz i nie zaktualizował go w sklepie, podpisy przestaną się zgadzać.
Identyfikator punktu płatności – przy kilku sklepach lub kilku punktach sprzedaży u jednego operatora łatwo podpiąć nie ten identyfikator.
Czas serwera – część integracji weryfikuje znacznik czasu z określoną tolerancją. Rozjechany zegar serwera powoduje odrzucanie poprawnych powiadomień. Sprawdź czas serwera u hostingodawcy.

Krok 7. Ustawienia statusu w samej bramce

Zanim zaczniesz podejrzewać awarię, sprawdź konfigurację. Wiele wtyczek płatności ma ustawienie „status zamówienia po udanej płatności”. Jeśli ktoś ustawił tam „wstrzymane” zamiast „w trakcie realizacji”, wszystko działa dokładnie tak, jak zostało skonfigurowane.

Sprawdź też:

Ustawienia dla produktów wirtualnych i do pobrania – często mają osobną regułę.
Regułę dla płatności odroczonych i ratalnych.
Ustawienie „wymagaj ręcznej akceptacji zamówienia”.
Zgodność waluty sklepu z walutą punktu płatności – niezgodność potrafi zatrzymać zamówienie w połowie procesu.

Przy okazji warto przejrzeć całość konfiguracji według naszej instrukcji: jak skonfigurować płatności w WooCommerce.

Krok 8. Sprawdź Action Scheduler i cron

Część działań w WooCommerce nie wykonuje się natychmiast, tylko trafia do kolejki zadań. Jeśli kolejka stoi, statusy potrafią zamarzać, e-maile nie wychodzą, a synchronizacje nie działają.

Wejdź w WooCommerce → Status → Zaplanowane działania i spójrz na zakładkę „Oczekujące”. Jeśli widzisz tam setki zadań z datami z przeszłości, masz zepsuty harmonogram, a nie zepsute płatności.

Typowe przyczyny: wyłączony WP-Cron bez skonfigurowanego crona systemowego, zbyt niskie limity zasobów na hostingu współdzielonym, wtyczka blokująca wp-cron.php, albo po prostu sklep tak wolny, że zadania nie zdążają się wykonać. Ten ostatni przypadek rozbieramy w tekście o tym, dlaczego sklep WooCommerce działa wolno.

Ten sam mechanizm odpowiada za brak wiadomości do klientów – jeśli i to ci nie działa, zobacz ścieżkę gdy sklep nie wysyła maili z potwierdzeniem zamówienia.

Krok 9. Wtyczki, które same przestawiają status

Jeśli notatki zamówienia pokazują, że status był ustawiony na „w trakcie realizacji”, a potem wrócił na „wstrzymane”, to nie bramka jest problemem. Coś nadpisuje decyzję.

Podejrzani:

Integracje z systemami magazynowo-sprzedażowymi – dwukierunkowa synchronizacja potrafi cofać status, jeśli po drugiej stronie zamówienie ma inny stan.
Wtyczki do zarządzania statusami i automatyzacje – reguły typu „jeśli produkt X, ustaw wstrzymane” bywają zapomniane po latach.
Wtyczki antyfraudowe i weryfikacja adresu – celowo wstrzymują podejrzane zamówienia.
Własne fragmenty kodu w motywie potomnym – podpięte pod zdarzenia zmiany statusu.
Integracje z kurierami – część z nich zmienia status na etapie tworzenia przesyłki.

Metoda: wyłącz integracje po kolei na kopii testowej sklepu i wykonaj testową płatność na najmniejszą możliwą kwotę. Nie rób tego na produkcji w godzinach sprzedaży.

Przypadki szczególne, które wyglądają jak awaria

Autoryzacja bez pobrania środków

Niektóre bramki kartowe można ustawić w trybie autoryzacji: karta jest sprawdzona i kwota zablokowana, ale pieniądze nie są pobierane, dopóki sam tego nie zatwierdzisz. WooCommerce ustawia wtedy status „wstrzymane” i to jest zachowanie prawidłowe. Środki trzeba pobrać z poziomu zamówienia lub panelu operatora, zwykle w ciągu kilku dni, bo blokada wygasa.

Jeśli nie wiedziałeś, że masz włączony ten tryb – sprawdź ustawienia bramki. Zdarza się, że ktoś włączył go przy wdrożeniu „na chwilę”.

Płatności odroczone i ratalne

Kup teraz, zapłać później oraz raty mają własny cykl decyzyjny. Zamówienie potrafi wisieć, dopóki dostawca nie zakończy weryfikacji klienta. Notatki zamówienia zwykle to opisują.

Przelew elektroniczny przez portfel zagraniczny

Część metod rozlicza się z opóźnieniem liczonym w dniach i przez ten czas zamówienie ma prawo być wstrzymane. To nie usterka, tylko charakterystyka metody.

Klient zapłacił za inne zamówienie

Klasyka przy ponawianiu nieudanej płatności. Powstają dwa zamówienia: jedno opłacone, drugie wiszące. Sprawdź, czy pod tym samym adresem e-mail nie ma bliźniaka z tą samą kwotą. Puste zamówienie anuluj, żeby nie blokowało stanu magazynowego.

Co zrobić od razu, zanim znajdziesz przyczynę

Diagnostyka diagnostyką, ale klient czeka. Kolejność działań doraźnych:

Potwierdź płatność u operatora. Nigdy nie zmieniaj statusu tylko na podstawie zrzutu ekranu od klienta.
Zmień status ręcznie na „w trakcie realizacji”. Stan magazynowy nie zostanie zdjęty po raz drugi.
Dodaj notatkę do zamówienia z numerem transakcji i informacją, że status zmieniono ręcznie. Za miesiąc będziesz wdzięczny.
Wyślij klientowi wiadomość. W zamówieniu masz akcję ponownego wysłania powiadomienia. Krótka informacja, że płatność została zaksięgowana i paczka idzie, zamyka sprawę.
Przejrzyj pozostałe wstrzymane zamówienia z tego samego okresu. Jeśli problem był systemowy, jest ich więcej i część klientów jeszcze się nie odezwała.

To ostatnie jest ważniejsze, niż się wydaje. Milczący klient z nieopłaconym w jego oczach zamówieniem to klient, który już nie wróci. O tym, jak sklep buduje albo traci wiarygodność w takich momentach, pisaliśmy w tekście o budowaniu zaufania w sklepie internetowym.

Tabela szybkiej diagnozy

Objaw	Prawdopodobna przyczyna	Gdzie sprawdzić
Brak wpisu od bramki w notatkach	Powiadomienie nie dotarło	Adres IPN, zapora, tryb konserwacji
Wpis o błędnym podpisie	Złe klucze albo tryb testowy	Ustawienia bramki, panel operatora
Problem dotyczy tylko jednej metody	Konfiguracja tej integracji	Ustawienia konkretnej wtyczki
Problem zaczął się konkretnego dnia	Aktualizacja, migracja, certyfikat, zapora	Historia zmian, dzienniki serwera
Status wrócił z „w trakcie realizacji”	Wtyczka nadpisuje status	Integracje, automatyzacje
Nie działają też e-maile	Zatrzymana kolejka zadań	Zaplanowane działania, cron
Metoda to przelew bankowy	Zachowanie prawidłowe	Nic do naprawy, to proces ręczny

Jak nie wracać do tego problemu

Testowa płatność po każdej większej zmianie. Aktualizacja WooCommerce, zmiana motywu, migracja, nowy certyfikat, włączenie CDN – za każdym razem transakcja na najmniejszą kwotę i sprawdzenie, czy status przeskoczył sam.
Monitoring wstrzymanych zamówień. Powiadomienie, gdy zamówienie wisi w tym statusie dłużej niż na przykład dwie godziny, wykrywa problem zanim zrobi to klient.
Adresy IP operatora na stałej liście dozwolonych – i notatka w dokumentacji sklepu, żeby przy zmianie zapory nikt tego nie zgubił.
Środowisko testowe do aktualizacji wtyczek płatności. Nigdy nie aktualizuj bramki na żywym sklepie w piątek po południu.
Włączone dzienniki bramki na stałe. Kosztują tyle co nic, a przy awarii skracają diagnostykę z godzin do minut.
Spisana procedura na wypadek awarii płatności – kto sprawdza panel operatora, kto pisze do klientów, w jakiej kolejności.

Najczęstsze pytania

Czy zamówienie „wstrzymane” rezerwuje towar?

Tak. W przeciwieństwie do „oczekujące na płatność”, status wstrzymany zdejmuje stan magazynowy. Dlatego wiszące bez końca wstrzymane zamówienia realnie blokują sprzedaż.

Czy klient dostaje wiadomość o wstrzymaniu?

Domyślnie tak – WooCommerce ma osobne powiadomienie dla tego statusu. Jeśli twoi klienci go nie dostają, powiadomienie jest wyłączone albo sklep w ogóle nie wysyła poczty.

Czy ręczna zmiana statusu zdejmie towar drugi raz?

Nie. WooCommerce zapisuje w zamówieniu informację o tym, że stan został już zredukowany, i nie robi tego ponownie.

Czy mogę automatycznie anulować stare wstrzymane zamówienia?

Wbudowana opcja anulowania nieopłaconych zamówień dotyczy statusu „oczekujące na płatność”, a nie „wstrzymane”. Automatyczne czyszczenie wstrzymanych wymaga dodatkowego rozwiązania i trzeba je wprowadzać ostrożnie, bo część z tych zamówień może być realnie opłacona.

Ile czekać, zanim uznam to za awarię?

Przy szybkich przelewach i BLIK-u status powinien zmienić się w ciągu kilku minut. Jeśli po kwadransie nadal jest wstrzymany, a operator pokazuje transakcję zakończoną, zaczynaj diagnostykę.

Klient zapłacił, ale zamówienie ma status „wstrzymane” – analiza