Dlaczego sklep internetowy nie zapisuje zamówień? To pytanie potrafi zmrozić krew w żyłach każdego właściciela e-commerce, bo brak zapisanych transakcji oznacza utratę przychodu i zaufania klientów. Na szczęście w większości przypadków źródło problemu da się szybko zidentyfikować i naprawić — pod warunkiem, że podejdziemy do tematu metodycznie i bez pochopnych zmian na żywym organizmie.

Dlaczego sklep internetowy nie zapisuje zamówień?

Najczęściej zawodzi komunikacja, sesje użytkownika, baza danych albo integracje płatności.

Z perspektywy technicznej zamówienie powstaje w kilku krokach: klient dodaje produkty do koszyka, przechodzi przez checkout, system waliduje dane, rezerwuje płatność i zapisuje rekord w bazie. Jeśli na którymkolwiek etapie coś się „urwało”, efekt bywa ten sam — brak nowego zamówienia w panelu. Najczęstsze scenariusze to:

• przerwana lub nieudana komunikacja z bramką płatności (brak zwrotnego potwierdzenia),
• utracona sesja klienta lub błędnie skonfigurowany cache,
• błąd bazy danych albo zbyt surowe reguły zabezpieczeń,
• konflikt wtyczek/modułów po aktualizacji,
• przeciążenie serwera i time-outy w trakcie zapisu.

Kluczem jest szybkie potwierdzenie, czy zamówienie faktycznie się nie zapisało, czy np. utknęło w statusie „oczekujące”, „nieudane” lub pojawiło się… w logach bramki płatności zamiast w panelu sklepu.

Szybka diagnostyka: od czego zacząć

Oddziel objawy od przyczyn i potwierdź, gdzie pęka ścieżka zamówienia.

Zanim zaczniesz grzebać w konfiguracji, przeprowadź krótką kontrolę:

• Sprawdź rejestry zamówień we wszystkich statusach (w tym „oczekujące”, „anulowane”, „nieudane”).
• Zrób testowe zamówienie metodą płatności „za pobraniem” lub „przelew tradycyjny”. Jeśli takie zamówienie się zapisze, to problem dotyczy najpewniej integracji płatności online.
• Przejrzyj logi systemu i bramek płatności. Logi to Twoja czarna skrzynka — szukaj błędów 4xx/5xx, time-outów, komunikatów „invalid signature”, „webhook failed”.
• Wyłącz na chwilę agresywne cache’owanie stron koszyka i checkoutu. Pełno-stronicowy cache w tych miejscach to prosta droga do utraty sesji.
• Spróbuj w trybie incognito i na innym urządzeniu. Czasem winny jest dodatek przeglądarki albo blokada cookies.

Jeśli masz środowisko testowe (staging), odtwórz problem tam. Dzięki temu nie będziesz ryzykować utraty realnych zamówień podczas diagnostyki.

Najczęstsze problemy po stronie aplikacji

Gdy oprogramowanie sklepu się „gryzie”, zamówienia lądują w nicości.

Błędne integracje bramek płatności (webhooki, IPN, notyfikacje)

Brama płatności potwierdza transakcję, ale sklep jej „nie słyszy”.

• Adres zwrotnej notyfikacji (webhook) jest błędny, zablokowany lub cache’owany.
• Niezgodny klucz/sekret powoduje odrzucenie podpisu żądania.
• Serwer zwraca 403/404/500, więc bramka nigdy nie „domyka” zamówienia.
• Podwójne lub spóźnione notyfikacje aktualizują status w niewłaściwy sposób.

Co zrobić:

• Zweryfikuj adresy webhooków w panelu bramki i w sklepie.
• Sprawdź dzienniki prób dostarczenia notyfikacji — szukaj kodów 2xx.
• Przetestuj transakcje w sandboxie i porównaj treść żądań z dokumentacją.

Konflikt wtyczek, modułów lub motywu

Niewinna aktualizacja potrafi przerwać krytyczny hook zapisu zamówienia.

• Dwie wtyczki modyfikują checkout i nadpisują sobie pola lub walidację.
• Motyw blokuje skrypty checkoutu albo dołącza niekompatybilną wersję JS.
• Niestandardowe funkcje podpinają się do akcji „before/after order save” i zwracają błędy.

Co zrobić:

• Dezaktywuj wszystko poza silnikiem sklepu i bramką płatności.
• Przełącz motyw na domyślny, zrób testowe zamówienie.
• Włącz tryb debugowania i przejrzyj stack trace w momencie zapisu.

Sesje, cookies i cache

Koszyk znika, checkout się „odświeża”, a zamówienia nie powstają.

• Pełno-stronicowy cache obejmuje koszyk/checkout.
• Cookies z identyfikatorem sesji są blokowane przez politykę zgód (CMP) lub przeglądarkę.
• Błąd w konfiguracji Redis/Memcached uniemożliwia odczyt sesji.
• CDN/Proxy miesza cache między użytkownikami.

Co zrobić:

• Wyklucz z cache: /cart, /checkout, /my-account, endpointy AJAX i webhooki.
• Upewnij się, że pliki cookies nie są blokowane przed wyrażeniem zgody na śledzenie (różnica między „niezbędne” a „marketingowe”).
• Sprawdź poprawność klucza i prefiksów w object cache.

Błędy bazy danych i migracje

Rekord zamówienia nie zapisuje się przez konflikt schematu lub ograniczenia.

• Uszkodzone tabele, brak auto_increment, błąd przekodowania znaków.
• Niezakończona migracja (np. przejście na nowe magazynowanie zamówień).
• Deadlock lub blokada transakcji przy dużym obciążeniu.

Co zrobić:

• Uruchom naprawę/optimizację tabel i sprawdź engine (preferuj InnoDB).
• Zajrzyj do logów bazodanowych, wypatruj „deadlock”, „duplicate key”.
• Wykonaj backup, a potem napraw migracje zgodnie z dokumentacją platformy.

Kolejki zadań i CRON

Zamówienie czeka na zadanie w tle, które nigdy się nie uruchamia.

• Scheduler (np. Action Scheduler w WooCommerce, CRON w Magento/PrestaShop) jest wyłączony lub nieosiągalny.
• Zadania „pending” piętrzą się i blokują przetwarzanie kolejnych.

Co zrobić:

• Sprawdź status harmonogramu zadań, uruchom ręcznie zaległe joby.
• Skonfiguruj prawdziwy CRON na serwerze, a nie tylko pseudo-cron z ruchem użytkowników.

Limity zasobów i błędy PHP

Proces zapisu zamówienia kończy się fatal error lub time-outem.

• Za niski memory_limit, max_execution_time.
• Zbyt mało workerów PHP-FPM, długie czasy odpowiedzi.

Co zrobić:

• Zwiększ memory_limit (np. do 512M) i timeouty.
• Monitoruj błędy 500 i „Allowed memory size exhausted”.

Problemy serwerowe i infrastrukturalne

Firewall, CDN lub WAF potrafią po cichu popsuć zamówienia.

WAF/ModSecurity i reguły bezpieczeństwa

Bezpieczeństwo blokuje to, co powinno przejść.

• Blokada endpointów checkoutu lub webhooków jako „podejrzanych”.
• Reguły OWASP wycinają parametry POST.

Działania:

• Przejrzyj logi WAF, wyklucz konkretne ścieżki (checkout, webhooki) z ostrych reguł.
• Dodaj allowlistę dla adresów IP bramek płatności.

CDN i proxy (np. Cloudflare)

Cache „wszystkiego” łamie checkout, a firewalle blokują notyfikacje.

• Włączony tryb Cache Everything na całej domenie.
• Blokady Bot Fight/Rate Limiting na webhookach.

Działania:

• Reguły stron: no-cache dla koszyka, checkoutu, panelu klienta i API.
• Upewnij się, że webhooki otrzymują odpowiedź 200 i nie są „challenge’owane”.

SSL i przekierowania

Niezgodności protokołu i pętle przekierowań zrywają sesję.

• Mieszana treść, źle wymuszone HTTPS, konflikt HSTS.
• Podwójne przekierowania www/non-www.

Działania:

• Stosuj spójne reguły HTTPS i jedną kanoniczną domenę.
• Sprawdź, czy cookies mają poprawne flagi Secure/SameSite.

Plan naprawczy: krok po kroku

Działaj metodycznie: najpierw diagnoza, potem precyzyjna korekta.

1. Włącz logowanie i debug:

   • Logi aplikacji, serwera, bramki płatności.
   • Oznacz testowe zamówienia, aby łatwo je wyłapać.

2. Wyklucz cache ze ścieżek krytycznych:

   • Cart, checkout, my account, endpointy AJAX i webhooki.
   • Sprawdź politykę cookies i zgodność z CMP.

3. Test płatności offline:

   • Jeśli zamówienie się zapisuje, skup się na integracjach płatności.

4. Weryfikacja bramki płatności:

   • Adresy i podpisy webhooków, statusy dostarczenia (2xx).
   • Test sandbox i porównanie payloadu z dokumentacją.

5. Minimalna konfiguracja:

   • Dezaktywuj zbędne wtyczki/moduły, przełącz motyw na domyślny.
   • Ponów test zamówienia.

6. Sprawdzenie bazy danych:

   • Naprawa/optimizacja tabel, kontrola migracji i indeksów.
   • Analiza deadlocków i autoincrement.

7. Kolejki i CRON:

   • Uruchom zaległe zadania, skonfiguruj prawdziwy CRON.

8. Limity i wydajność:

   • Podnieś memory_limit, timeouty, workerów FPM.
   • Usuń wąskie gardła według logów.

9. WAF/CDN:

   • Wyklucz krytyczne ścieżki z blokad i cache.
   • Allowlista IP dostawców płatności.

10. Testy końcowe i monitoring:

    • E2E test płatności cyklicznie (np. co godzinę w stagingu).
    • Alerty, gdy brak zamówień lub błąd webhooka > X minut.

Prewencja: jak nie dopuścić do powtórki

Stabilny proces to efekt nawyków, nie jednorazowej naprawy.

• Utrzymuj środowisko staging i wdrażaj zmiany partiami.
• Miej procedurę szybkiego wycofania aktualizacji.
• Dodaj monitoring zamówień i webhooków (alert, gdy dłużej niż 15–30 min brak nowych transakcji w godzinach ruchu).
• Regularne kopie zapasowe i test odtwarzania.
• Dokumentuj integracje i punkty krytyczne (checkout, płatności, kolejki).

Częste pytania i pułapki

Kilka krótkich odpowiedzi na problemy, które wracają najczęściej.

• Czy brak płatności zawsze oznacza brak zamówienia?

  • Nie. W wielu platformach zamówienie tworzy się w statusie „oczekujące” przed płatnością. Sprawdź wszystkie statusy oraz historię notyfikacji bramki.

• Zamówienia są w bazie, ale nie widzę ich w panelu.

  • To może być problem indeksów, filtrów w panelu, konflikt ról uprawnień albo zmiana sposobu przechowywania zamówień po aktualizacji. Przejrzyj logi i porównaj widoki/indeksy.

• Polityka cookies blokuje checkout?

  • Jeśli narzędzie zgód traktuje cookies sesyjne jako „marketingowe”, checkout straci stan koszyka. Zadbaj, by cookies niezbędne były zawsze dozwolone.

• Czy CDN zawsze szkodzi checkoutowi?

  • Nie, pod warunkiem że poprawnie wykluczysz ścieżki dynamiczne i API oraz nie włączysz „Cache Everything” dla całej domeny.

• Klient zapłacił, a zamówienia brak.

  • Sprawdź webhooki. Najprawdopodobniej potwierdzenie płatności nie dotarło lub zostało odrzucone. W razie potrzeby możesz ręcznie powiązać transakcję z zamówieniem i wysłać potwierdzenie.

Podsumowanie: co najczęściej rozwiązuje problem najszybciej

Wykluczenie cache na checkout, naprawa webhooków i sprawny CRON to złota trójka.

W praktyce najwięcej kłopotów robią: agresywne cache’owanie ścieżek koszyka/checkoutu, zablokowane lub źle skonfigurowane notyfikacje z bramek płatności oraz niesprawne kolejki zadań. Gdy dołożysz do tego niedobory zasobów i sporadyczne konflikty wtyczek, masz pełen obraz, dlaczego zamówienia potrafią „wyparować”.

Dobra wiadomość? To wszystko da się dobrze ułożzyć. Zacznij od logów i prostych testów, wyizoluj problem, napraw jeden element naraz i wdrażaj drobne zmiany ze stagingu. A potem włącz monitoring, żeby następnym razem dowiedzieć się o kłopocie, zanim zadzwoni klient.