Jedna z bardziej niebezpiecznych usterek sklepu wygląda tak: klient widzi udaną płatność w banku, operator ma transakcję jako opłaconą, ale WooCommerce pozostawia zamówienie w statusie oczekującym. Administrator może wtedy omyłkowo poprosić klienta o ponowną zapłatę albo nie wysłać towaru.
Szybka odpowiedź
Nie zmieniaj masowo statusów. Najpierw porównaj identyfikator zamówienia, identyfikator transakcji u operatora, notatki zamówienia i log bramki. Jeśli operator potwierdził płatność, a sklep jej nie odebrał, sprawdź webhook/callback oraz dostępność endpointu z internetu.
Jak powinien działać proces?
Klient rozpoczyna płatność, operator przetwarza transakcję, a sklep otrzymuje niezależne potwierdzenie serwer-serwer. Na jego podstawie bramka wywołuje logikę WooCommerce, która aktualizuje status. Samo przekierowanie klienta na stronę „Dziękujemy” nie powinno być jedynym źródłem prawdy o płatności.
1. Sprawdź notatki zamówienia
W WooCommerce notatki często zawierają komunikat bramki, zmianę statusu lub identyfikator transakcji. To najprostsze miejsce startu.
2. Panel operatora
Otwórz konkretną transakcję. Sprawdź kwotę, status, identyfikatory i czas. Upewnij się, że transakcja rzeczywiście została rozliczona, a nie tylko zainicjowana.
3. Webhook lub callback
Sprawdź, czy operator dotarł do endpointu sklepu. Błąd 403, 404, 500 albo timeout może przerwać aktualizację. WAF, Cloudflare, wtyczka bezpieczeństwa lub reguła serwera może omyłkowo blokować legalne żądania bramki.
4. Logi bramki płatniczej
Włącz diagnostykę zgodnie z dokumentacją danego operatora. Nie publikuj logów zawierających dane wrażliwe.
5. Konflikt lub aktualizacja
Jeżeli problem zaczął się po aktualizacji bramki, WooCommerce albo PHP, odtwórz go na stagingu i sprawdź zgodność wersji.
6. Status „oczekujące” a „wstrzymane”
Nie traktuj wszystkich statusów jak synonimów. WooCommerce rozróżnia etapy procesu, a konkretna bramka może używać ich w określony sposób.
7. Co zrobić z klientem?
Jeśli płatność jest potwierdzona u operatora, nie proś o ponowne płacenie. Zweryfikuj zamówienie i obsłuż je zgodnie z procedurą firmy, jednocześnie naprawiając integrację.
Jak zapobiegać?
Monitoruj błędy webhooków, wykonuj okresowe testy płatności i po aktualizacjach przechodź pełną ścieżkę checkoutu.
Bezpieczna kolejność diagnostyki
Przy problemie WooCommerce płatność pobrana zamówienie oczekuje najłatwiej stracić czas przez zmienianie kilku rzeczy naraz. Zanim cokolwiek naprawisz, zapisz objaw, godzinę wystąpienia i ostatnie zmiany. Następnie sprawdź logi oraz stan usług, których dotyczy błąd.
Dobra kolejność wygląda tak:
- potwierdź objaw na konkretnym URL-u lub zamówieniu,
- sprawdź logi i komunikaty systemowe,
- ustal ostatnią zmianę,
- wykonaj kopię przed ingerencją,
- zmień jeden element,
- ponownie wykonaj ten sam test,
- po naprawie sprawdź pozostałe funkcje strony.
Czego nie robić?
Nie czyść bazy, nie resetuj haseł i nie aktualizuj wszystkiego „na wszelki wypadek”, jeżeli nie ma ku temu przesłanek. Takie działania niszczą ślady i zwiększają liczbę niewiadomych. Jeżeli serwis generuje sprzedaż, szybki rollback często jest lepszy niż długa naprawa prowadzona bezpośrednio na produkcji.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
HeatLogic może przeanalizować rozjechane statusy płatności, webhooki i logi operatora oraz przygotować test transakcji po naprawie.
Najczęściej zadawane pytania
Czy mogę ręcznie zmienić status na realizacja?
Jeżeli płatność została niezależnie potwierdzona u operatora, można obsłużyć zamówienie zgodnie z procedurą. Równolegle trzeba znaleźć przyczynę braku automatycznej aktualizacji.
Czy problem może powodować firewall?
Tak. Webhook bramki może być blokowany przez WAF, reguły bezpieczeństwa lub problem z dostępnością endpointu.
Czy przekierowanie klienta potwierdza płatność?
Nie powinno być jedynym potwierdzeniem. Bramki wykorzystują serwerowe mechanizmy callback/webhook.
Gdzie szukać informacji o błędzie?
W notatkach zamówienia, logach wtyczki płatniczej, logach serwera i panelu operatora.