Klient zapłacił przez PayU albo Przelewy24, środki są widoczne po stronie operatora, ale WooCommerce nadal pokazuje „Oczekujące na płatność”? To jeden z tych problemów, które potrafią szybko wprowadzić chaos w obsłudze sklepu: klient uważa zamówienie za opłacone, a magazyn lub administrator widzi je jako niezapłacone.
W takiej sytuacji nie zaczynam od ręcznej zmiany statusu. Najpierw sprawdzam, czy operator płatności wysłał do sklepu notyfikację o udanej transakcji i czy WordPress prawidłowo ją odebrał oraz przetworzył.
Bardzo często problemem nie jest sama płatność. Problem pojawia się kilka sekund później – na komunikacji PayU / Przelewy24 → serwer sklepu → WooCommerce.
Udana płatność u operatora nie gwarantuje jeszcze, że WooCommerce odebrał jej potwierdzenie.
PayU i Przelewy24 wysyłają do sklepu serwerową notyfikację o wyniku transakcji.
Cloudflare, WAF albo wtyczka bezpieczeństwa mogą zablokować przychodzące żądanie.
Notatki zamówienia i logi bramki często pokazują, na którym etapie proces się zatrzymał.
Po udanej płatności produkt fizyczny zwykle powinien trafić do statusu W trakcie realizacji.
Nie ustawiam automatycznie zamówień jako „Zrealizowane” tylko dlatego, że klient zapłacił.
Najpierw sprawdź, czy status naprawdę jest nieprawidłowy
To ważne, ponieważ właściciele sklepów często oczekują, że po udanej płatności WooCommerce automatycznie ustawi zamówienie jako „Zrealizowane”.
Przy typowym zamówieniu zawierającym produkty fizyczne prawidłowy status po zaksięgowaniu płatności to najczęściej:
Oczekujące na płatność
↓
płatność potwierdzona
↓
W trakcie realizacji
↓
wysyłka / realizacja zamówienia
↓
ZrealizowaneStatus „W trakcie realizacji” oznacza więc, że pieniądze zostały potwierdzone i sklep czeka na wykonanie kolejnego kroku – np. spakowanie oraz wysłanie produktu.
Dopiero po realizacji zamówienia zmieniam je na „Zrealizowane”.
Przy produktach fizycznych to normalny status po poprawnym zaksięgowaniu płatności.
Jeżeli operator potwierdza płatność, a WooCommerce nadal jej nie widzi, zaczynam analizę notyfikacji.
Jak naprawdę wygląda zmiana statusu po płatności online?
W uproszczeniu proces składa się z kilku osobnych elementów.
Bank lub BLIK potwierdzają transakcję po stronie operatora.
PayU lub P24 zmienia status transakcji w swoim systemie.
Operator wysyła żądanie serwer-serwer do WordPressa.
Wtyczka płatności oznacza zamówienie jako opłacone.
Problem może więc wystąpić nawet wtedy, gdy etap 1 i 2 zakończyły się całkowicie prawidłowo.
Powrót klienta do sklepu to nie to samo co webhook
To jedna z najważniejszych rzeczy przy diagnozowaniu PayU i Przelewy24.
Po płatności klient może zostać przekierowany z operatora z powrotem na stronę sklepu – najczęściej na stronę podziękowania za zamówienie.
Nie oznacza to jednak, że przeglądarka klienta powinna odpowiadać za potwierdzenie transakcji w WooCommerce.
Potwierdzenie powinno dotrzeć również niezależnym kanałem serwer-serwer.
Służy przede wszystkim do przekierowania klienta z operatora płatności z powrotem do sklepu.
Komunikacja pomiędzy serwerem operatora a sklepem, która pozwala potwierdzić wynik transakcji.
Dzięki temu status może zostać poprawnie zaktualizowany również wtedy, gdy klient zamknie kartę przeglądarki natychmiast po zapłaceniu.
1. Sprawdź notatki konkretnego zamówienia
To najprostszy punkt startowy.
Otwieram:
WooCommerce
→ Zamówienia
→ konkretne zamówienie
→ Notatki zamówieniaWtyczki płatności często zapisują tam informacje dotyczące przebiegu transakcji.
Szukam m.in. informacji o:
- utworzeniu płatności,
- przekierowaniu do operatora,
- identyfikatorze transakcji,
- odebraniu potwierdzenia,
- zmianie statusu płatności,
- błędzie weryfikacji.
Jeżeli log kończy się na utworzeniu płatności i później nie ma żadnego śladu potwierdzenia, webhook lub notyfikacja stają się jednym z głównych podejrzanych.
2. Sprawdź logi PayU lub Przelewy24 w WooCommerce
W zależności od wersji używanej wtyczki i konfiguracji, integracja może zapisywać własne logi w systemie WooCommerce.
Sprawdzam:
WooCommerce
→ Status
→ LogiNastępnie szukam źródła logów powiązanego z PayU, Przelewy24 albo używaną bramką płatniczą.
Szczególnie interesują mnie wpisy pojawiające się dokładnie w momencie testowej transakcji.
3. PayU – sprawdź, czy notyfikacja dochodzi do sklepu
W PayU status zamówienia w sklepie jest aktualizowany na podstawie notyfikacji wysyłanej przez system płatności.
Sklep powinien odebrać takie żądanie i odpowiedzieć prawidłowym kodem HTTP.
PayU
↓
POST z notyfikacją
↓
endpoint sklepu
↓
WooCommerce / wtyczka PayU
↓
HTTP 200 OKJeżeli zamiast odpowiedzi 200 operator otrzyma np. 403 albo 500, status w WooCommerce może pozostać nieaktualny.
W panelu PayU warto sprawdzić raport związany z transakcją i odpowiedź zwróconą przez sklep.
4. Cloudflare może blokować webhook PayU
To bardzo praktyczny przypadek.
Jeśli strona znajduje się za Cloudflare, reguły bezpieczeństwa mogą uznać żądanie PayU za podejrzane i zatrzymać je, zanim w ogóle dotrze do WordPressa.
Wtedy operator może otrzymać odpowiedź w rodzaju:
HTTP 403 Forbiddenalbo inny komunikat związany z filtrowaniem ruchu.
Sprawdzam wtedy przede wszystkim:
- Security Events w Cloudflare,
- reguły WAF,
- blokady adresów IP,
- blokowanie User-Agent,
- niestandardowe reguły firewall.
Jeżeli potwierdzę, że konkretna prawidłowa notyfikacja jest blokowana, przygotowuję możliwie wąski wyjątek dla właściwego ruchu zamiast zdejmować ochronę całego sklepu.
5. Sprawdź Wordfence, WP Cerber i inne zabezpieczenia
Cloudflare nie jest jedynym filtrem po drodze.
Żądanie może dotrzeć do hostingu, ale zostać zablokowane przez wtyczkę bezpieczeństwa zainstalowaną w WordPressie.
Szczególnie podejrzane są sytuacje, gdy problem rozpoczął się po zmianie konfiguracji zabezpieczeń, wdrożeniu blokowania botów albo ograniczeniu dostępu do REST API i endpointów WordPressa.
6. Czy sklep jest chroniony hasłem?
Dotyczy to szczególnie sklepów testowych, nowych wdrożeń i środowisk stagingowych.
Jeśli cała strona jest chroniona przez HTTP Basic Auth, zewnętrzny operator płatności może nie być w stanie dostać się do adresu notyfikacji.
Administrator może normalnie testować sklep w przeglądarce, bo wcześniej podał login i hasło. Serwer PayU lub P24 tych danych nie posiada, więc jego callback kończy się błędem 401.
7. Przelewy24 – sprawdź urlStatus i weryfikację transakcji
W Przelewy24 po poprawnie wykonanej płatności system wysyła
notyfikację na adres przekazany podczas rejestracji transakcji
jako urlStatus.
To osobny proces od przekierowania klienta na:
urlReturnPo odebraniu informacji o płatności system sklepu powinien również wykonać weryfikację transakcji.
Przelewy24
↓
udana płatność
↓
notyfikacja na urlStatus
↓
weryfikacja transakcji
↓
aktualizacja zamówienia WooCommerceJeżeli callback nie dociera albo weryfikacja nie przechodzi, klient może mieć opłaconą transakcję, podczas gdy sklep nadal nie przejdzie prawidłowo do kolejnego statusu.
8. Sprawdź dane konfiguracyjne PayU lub Przelewy24
Nie każdy przypadek jest czystym problemem z webhookiem.
Po migracji strony, zmianie konta operatora albo przejściu z sandboxa na produkcję sprawdzam również:
- identyfikator punktu płatności,
- POS ID lub merchant ID,
- klucze API,
- CRC / klucz konfiguracyjny wymagany przez integrację,
- tryb testowy vs produkcyjny,
- walutę i konfigurację konta.
Część integracji może pozwolić na rozpoczęcie płatności, ale późniejsza weryfikacja nie zakończy się poprawnie, jeżeli konfiguracja jest niespójna.
9. Zmiana domeny lub HTTP → HTTPS może zepsuć callback
Jeżeli problem pojawił się po migracji sklepu albo wdrożeniu SSL, sprawdzam adresy generowane przez WordPressa.
Typowe problemy to:
- stary adres domeny zapisany w konfiguracji,
- HTTP zamiast HTTPS,
- www vs non-www,
- łańcuch kilku przekierowań,
- przekierowanie callbacku na stronę logowania lub homepage.
Endpoint techniczny powinien odpowiadać dokładnie tak, jak oczekuje tego integracja płatnicza.
10. Nie cachuj endpointów płatności
Cache jest bardzo dobry dla stron produktów, kategorii czy wpisów blogowych. Callback płatności jest jednak dynamicznym żądaniem technicznym.
Jeżeli CDN albo cache zacznie ingerować w endpoint używany do obsługi potwierdzeń płatności, może doprowadzić do bardzo trudnych do odtworzenia błędów.
Dlatego przy problemach sprawdzam:
- page cache,
- Cloudflare Cache Rules,
- cache na poziomie hostingu,
- niestandardowe reguły dla URL-i WooCommerce,
- optymalizacje REST API i AJAX.
11. Co oznaczają kody 401, 403, 404 i 500?
| Kod | Co może oznaczać? | Gdzie sprawdzam? |
|---|---|---|
| 401 | Endpoint wymaga autoryzacji albo sklep jest chroniony hasłem. | Basic Auth, hosting, zabezpieczenia. |
| 403 | Żądanie zostało zabronione przez firewall lub regułę bezpieczeństwa. | Cloudflare, WAF, security plugin. |
| 404 | Operator trafia pod adres, którego WordPress nie obsługuje. | URL, permalink, konfiguracja wtyczki. |
| 500 | WordPress lub PHP wywołały błąd podczas obsługi callbacku. | Log PHP, WooCommerce Logs, debug.log. |
| 200 | Endpoint odpowiedział poprawnie na poziomie HTTP. | Dalej sprawdzam logikę weryfikacji i status zamówienia. |
12. Przy błędzie 500 sprawdź log PHP
Jeżeli notyfikacja dochodzi do WordPressa, ale obsługa callbacku kończy się błędem serwera, potrzebuję prawdziwego komunikatu PHP.
Mogę wtedy tymczasowo uruchomić logowanie:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Następnie odtwarzam płatność i sprawdzam:
/wp-content/debug.logJeżeli callback powoduje konflikt PHP, błąd kompatybilności albo wyjątek w kodzie wtyczki, log może wskazać konkretny plik oraz linię odpowiedzialną za przerwanie procesu.
13. Sprawdź wersję wtyczki PayU lub Przelewy24
WooCommerce regularnie się zmienia. Dotyczy to m.in. checkoutu, przechowywania zamówień, bloków oraz API.
Dlatego przy problemie, który pojawił się po aktualizacji, sprawdzam zgodność:
- WordPressa,
- WooCommerce,
- PHP,
- wtyczki PayU lub Przelewy24,
- dodatkowych wtyczek checkoutu.
Nie oznacza to, że aktualizuję wszystko jednocześnie bez kopii zapasowej. Najpierw sprawdzam changelog, stan strony i moment, od którego problem zaczął występować.
14. Nie myl webhooka bramki płatniczej z webhookami WooCommerce
W WooCommerce istnieje osobna sekcja webhooków, które można tworzyć np. dla zmiany zamówienia czy produktu.
To jednak nie oznacza, że callback PayU lub Przelewy24 musi być widoczny właśnie tam.
Wtyczki płatnicze często rejestrują własny endpoint i samodzielnie obsługują przychodzące notyfikacje.
Jeżeli oficjalna wtyczka płatności konfiguruje callback automatycznie, dodatkowy webhook nie naprawi problemu i może tylko utrudnić diagnozę.
15. Czy można po prostu ręcznie zmienić status zamówienia?
Technicznie tak, ale traktuję to jako rozwiązanie pojedynczego zamówienia, a nie naprawę integracji.
Jeżeli operator rzeczywiście potwierdza, że środki zostały poprawnie zaksięgowane, administrator może po weryfikacji obsłużyć zamówienie ręcznie.
Jeżeli jednak problem występuje przy kolejnych transakcjach, trzeba znaleźć przyczynę.
W przeciwnym razie bardzo łatwo o sytuację, w której:
- opłacone zamówienie zostanie przeoczone,
- klient nie dostanie właściwych wiadomości transakcyjnych,
- stan magazynowy nie zachowa się zgodnie z oczekiwaniem,
- automatyzacje sklepu nie zostaną uruchomione,
- obsługa będzie musiała codziennie porównywać sklep z panelem operatora.
Jak diagnozuję problem krok po kroku?
Sprawdzam status transakcji u operatora
Najpierw potwierdzam, że płatność rzeczywiście została zaakceptowana przez PayU lub Przelewy24.
Sprawdzam status i notatki WooCommerce
Szukam ostatniej informacji zapisanej przez wtyczkę płatności i sprawdzam, czy sklep kiedykolwiek odebrał potwierdzenie.
Sprawdzam logi bramki
Porównuję godzinę płatności z logami WooCommerce i komunikatami dotyczącymi konkretnej transakcji.
Sprawdzam odpowiedź endpointu
Szukam 200, 401, 403, 404 albo 500 i na tej podstawie wybieram dalszy kierunek diagnozy.
Analizuję Cloudflare, WAF i zabezpieczenia
Jeżeli żądanie jest blokowane, ustalam która reguła zatrzymuje poprawną komunikację operatora ze sklepem.
Sprawdzam konfigurację i wersję modułu
Weryfikuję dane API, środowisko testowe/produkcyjne, zgodność WooCommerce, WordPressa i PHP.
Wykonuję nową płatność testową
Nie kończę diagnozy na tym, że „ustawienie wygląda dobrze”. Robię nową transakcję od początku i sprawdzam, czy cały proces aktualizacji statusu rzeczywiście działa.
Dlaczego ten błąd jest groźniejszy niż wygląda?
Technicznie klient zapłacił, więc można uznać, że najważniejsza część sprzedaży już się wydarzyła. Z perspektywy sklepu problem dopiero się jednak zaczyna.
Status zamówienia jest często wykorzystywany przez:
- pracowników kompletujących zamówienia,
- systemy magazynowe,
- integracje kurierskie,
- automatyczne faktury,
- systemy ERP,
- e-maile transakcyjne,
- zewnętrzne automatyzacje.
Jeden niedziałający callback może więc wpływać nie tylko na kolumnę „Status” w panelu, ale na cały dalszy proces realizacji.
Dlatego podczas tworzenia sklepów WooCommerce zawsze traktuję płatność jako pełny proces: od kliknięcia „Kupuję i płacę”, przez komunikację z operatorem, aż po prawidłową aktualizację zamówienia i dalszą obsługę klienta.
PayU lub Przelewy24 pokazuje płatność jako udaną, ale WooCommerce tego nie widzi?
Mogę sprawdzić notatki zamówienia, logi PayU lub Przelewy24, callbacki, odpowiedzi HTTP, Cloudflare, zabezpieczenia, konfigurację API oraz zgodność modułu z WooCommerce. Dzięki temu znajdziemy miejsce, w którym proces płatności przestaje być prawidłowo synchronizowany ze sklepem.
WooCommerce nie zmienia statusu po płatności – najczęstsze pytania
Dlaczego WooCommerce nadal pokazuje „Oczekujące na płatność”, mimo że klient zapłacił?
Jedną z częstych przyczyn jest brak poprawnie odebranej notyfikacji od operatora płatności. Sprawdzam status transakcji w PayU lub Przelewy24, notatki zamówienia, logi bramki i odpowiedź endpointu sklepu.
Jaki status powinno mieć opłacone zamówienie WooCommerce?
Przy typowym zamówieniu z produktem fizycznym po udanej płatności oczekuję zwykle statusu „W trakcie realizacji”. Status „Zrealizowane” oznacza zazwyczaj, że zamówienie zostało już wykonane lub wysłane.
Czy wejście klienta na stronę „Dziękujemy” potwierdza płatność?
Nie traktuję samego przekierowania klienta jako wystarczającego potwierdzenia. PayU i Przelewy24 wykorzystują również niezależne notyfikacje serwer-serwer informujące sklep o wyniku transakcji.
Czy Cloudflare może blokować potwierdzenie płatności PayU?
Tak. Reguły Cloudflare lub innego WAF mogą zablokować przychodzące żądanie operatora. Przy takim problemie sprawdzam zdarzenia bezpieczeństwa i kod odpowiedzi HTTP, szczególnie błędy 403.
Co oznacza błąd 500 przy webhooku PayU lub Przelewy24?
Oznacza, że serwer nie był w stanie poprawnie obsłużyć żądania. Sprawdzam wtedy logi PHP, WooCommerce i wtyczki płatniczej, ponieważ przyczyną może być konflikt lub błąd wykonywanego kodu.
Czy mogę ręcznie zmienić zamówienie na „W trakcie realizacji”?
Po niezależnym potwierdzeniu, że płatność rzeczywiście została zaksięgowana, można obsłużyć pojedyncze zamówienie ręcznie. Nie jest to jednak naprawa integracji, jeśli problem występuje przy kolejnych płatnościach.
Gdzie znaleźć logi PayU i Przelewy24 w WooCommerce?
W zależności od używanego modułu logi mogą być dostępne w WooCommerce → Status → Logi. Sprawdzam również notatki konkretnego zamówienia oraz informacje dostępne w panelu operatora płatności.
Czy aktualizacja WooCommerce może spowodować problem z płatnościami?
Może ujawnić problem kompatybilności ze starszą wersją modułu płatniczego albo innym elementem checkoutu. Dlatego sprawdzam wersje WooCommerce, WordPressa, PHP i oficjalnej wtyczki operatora.
Kamil Sudoł – freelancer WordPress & SEO. Od 2015 roku tworzę i rozwijam strony internetowe oraz sklepy WooCommerce, a także zajmuję się SEO i widocznością firm w Google. Na blogu publikuję praktyczne materiały dotyczące WordPressa, SEO, UX i marketingu internetowego.
