Problemy z bramkami płatności w sklepie - diagnoza i rozwiązania 2026

Zacznij od istniejącego przykładu błędu. Ustal, czy dotyczy jednego banku, jednej metody, konkretnego produktu czy wszystkich zamówień. Zanotuj czas ze strefą czasową, numer zamówienia, identyfikator operatora i ostatnią zmianę konfiguracji. Nie potrzebujesz do tego hasła klienta ani pełnych danych jego karty.

Sprawdź oficjalny komunikat operatora, jeśli informuje o incydencie. Brak takiego komunikatu nie wyklucza problemu konkretnego konta. Nie wybieraj przyczyny tylko na podstawie nazwy błędu.

Przy podejrzeniu zapłaty wstrzymaj realizację wyłącznie tych zamówień, których stan wymaga wyjaśnienia. Ograniczenie innych metod lub całej sprzedaży zależy od zasięgu problemu. Nie odsyłaj klienta automatycznie do kolejnej płatności.

Sprawdź, czy metoda jest włączona zarówno w module, jak i na właściwym koncie operatora. Następnie porównaj warunki koszyka: walutę, kraj, metodę dostawy, wartość oraz typ produktu. Integracja płatności online w sklepie może celowo ukrywać rozwiązanie, które nie pasuje do danego zamówienia.

Zanotuj producenta i wersję wtyczki oraz rodzaj kasy. Zgodność klasycznego checkoutu nie oznacza automatycznie zgodności Blocks. Po zmianie szablonu sprawdź, czy problem występuje także na odizolowanej kopii z bazową konfiguracją. Nie wyłączaj kolejno wszystkich wtyczek w sklepie obsługującym klientów.

Dla portfeli znaczenie ma również środowisko kupującego. Apple opisuje obsługę płatności przez skanowanie kodu także w innych przeglądarkach i na PC, przy spełnieniu warunków urządzenia oraz sprzedawcy. Dlatego twierdzenie, że Apple Pay działa wyłącznie w Safari, jest zbyt wąskie. Źródło: instrukcja Apple Pay.

Po poprawce wróć do tego samego koszyka i urządzenia. Samo pojawienie się ikony jeszcze nie kończy testu: trzeba sprawdzić rozpoczęcie płatności i jej późniejszy stan.

Jeżeli metoda jest widoczna, ale kliknięcie nie prowadzi dalej, sprawdź pierwszy błąd w konsoli przeglądarki i odpowiedź żądania uruchamiającego płatność. Zestaw czas tego zdarzenia z logiem serwera. Ważne jest, czy transakcja zdążyła powstać u operatora.

Błąd JavaScript może zatrzymać formularz jeszcze przed komunikacją z bramką. Odmowa żądania może z kolei wynikać z danych środowiska, konfiguracji konta lub konkretnej reguły zabezpieczeń. W P24 trzeba rozróżnić autoryzację wychodzącego IP serwera od odbioru późniejszego powiadomienia. Szczegóły zawiera instrukcja Przelewy24 w WooCommerce.

Jeżeli log wskazuje blokadę zapory, ustal dokładne żądanie i regułę. Nie wyłączaj globalnie WAF ani całej ochrony sklepu. Wyjątek powinien mieć uzasadnienie i możliwie wąski zakres, uzgodniony z administratorem.

Błąd 500 nie dowodzi zbyt małej pamięci PHP. Zwiększenie limitu bez odczytania przyczyny może jedynie ukryć objaw. Poprawkę sprawdź na kopii i wróć do pierwotnego scenariusza, aby potwierdzić, że problem rzeczywiście ustąpił.

Otwórz właściwe konto operatora i odszukaj transakcję powiązaną z zamówieniem. Porównaj identyfikator, kwotę, walutę oraz stan płatności. Potwierdzenie od klienta pomaga znaleźć zdarzenie, lecz nie zastępuje rozliczenia po stronie operatora.

PayU opisuje 4 stany cyklu: PENDING, WAITING_FOR_CONFIRMATION, COMPLETED i CANCELED. Odpowiedź HTTP 200 potwierdza odbiór powiadomienia; jego podpis i treść nadal wymagają prawidłowej obsługi. Źródło: cykl płatności PayU. Tych nazw nie należy automatycznie przypisywać innym bramkom.

W P24 powrót użytkownika jest niezależny od powiadomienia, a protokół wymaga weryfikacji transakcji. Opisuje ją dokumentacja Przelewy24. Przy prawidłowym module obsługuje to integracja, nie administrator ręcznie wywołujący API.

Powiadomienia mogą się powtarzać lub przychodzić w innej kolejności. Stripe zaznacza: "Stripe doesn't guarantee the delivery of events in the order that they're generated." Źródło: dokumentacja webhooków Stripe. Dwa wpisy powiadomienia nie dowodzą dwóch pobrań. Sprawdź rzeczywiste transakcje, zanim zlecisz zwrot lub poprosisz klienta o ponowną zapłatę.

Odmowa płatności nie zawsze jest awarią sklepu. Odczytaj kod i opis zwrócony przez operatora, a następnie ustal, czy dotyczy danych transakcji, uwierzytelnienia czy decyzji banku. Nie proś klienta o przesłanie kodu SMS, kodu BLIK lub danych logowania.

W przypadku 3D Secure nie istnieje prosta reguła, że mała kwota zawsze pomija uwierzytelnienie. Wyjątki mają warunki i bank może nadal wymagać dodatkowego potwierdzenia. Wyjaśnia to dokumentacja wyjątków SCA Stripe. Nie wyłączaj ochrony antyfraudowej w odpowiedzi na pojedynczą odmowę ani nie ustawiaj wymyślonych limitów blokady.

Zwykły kod BLIK ma 6 cyfr i jest ważny 2 minuty, zgodnie z FAQ BLIK. Nie jest to uniwersalny czas anulowania zamówienia lub zakończenia autoryzacji. Przed ponowieniem sprawdź stan rozpoczętej transakcji.

Jeżeli problem zależy od banku lub urządzenia, zapisz tę okoliczność bez zbierania zbędnych danych osobowych. Sposób obsługi kupującego i warianty metody opisuje poradnik płatności BLIK. Alternatywną metodę proponuj dopiero po wyjaśnieniu, czy poprzednia próba została opłacona.

W WooCommerce zmiana statusu na zwrócony nie wysyła automatycznie pieniędzy. Wspierana refundacja przez bramkę i zwrot wykonany ręcznie mają inny przebieg. Sprawdź wybraną akcję, jej wynik w notatkach oraz stan operacji w panelu operatora. Podstawę stanowi instrukcja zwrotów WooCommerce.

Jeżeli panel długo nie pokazuje wyniku, nie klikaj ponownie w ciemno. Zanotuj identyfikator operacji i wyjaśnij, czy pierwsza próba została przyjęta. Przy zwrocie częściowym kontroluj sumę wcześniej zwróconych kwot oraz to, które elementy zamówienia są objęte bieżącą operacją.

Spór kartowy jest odrębną procedurą. Korzystaj z instrukcji i terminów widocznych dla konkretnego zgłoszenia u operatora. Nie zakładaj jednego terminu odpowiedzi ani jednakowej opłaty dla wszystkich bramek i umów.

Status zamówienia również wymaga kontekstu. Opłacony produkt fizyczny może oczekiwać na realizację, więc sam brak stanu zakończonego nie oznacza awarii płatności. Zasady opisuje dokumentacja zamówień WooCommerce. Ręczna korekta danych ma odzwierciedlać ustalony stan operacji, a nie zastępować jego sprawdzenie.

Przygotuj krótki opis: objaw, moment wystąpienia, metoda płatności, wersja modułu, rodzaj checkoutu oraz identyfikatory pozwalające powiązać zdarzenia. Dołącz odpowiedni fragment logu po usunięciu tokenów, kluczy, danych karty i zbędnych danych klienta. Nie publikuj pełnego eksportu transakcji na forum.

Zwykłe otwarcie adresu webhooka w przeglądarce nie odtwarza powiadomienia operatora. Inny sposób żądania albo brak właściwych danych może dać odpowiedź, która nic nie mówi o działającym procesie. Również monitoring dostępności strony nie potwierdza autoryzacji płatności.

Poprawkę testuj na odizolowanej kopii ze środowiskiem sandbox, bez prawdziwych wysyłek i wiadomości do klientów. Zapisz stan przed zmianą, wykonaj jedną uzasadnioną korektę i sprawdź ten sam scenariusz. Następnie sprawdź sąsiednią, wcześniej działającą metodę.

Przy planowaniu wycofania zmiany uwzględnij zamówienia powstałe od wykonania kopii. Przywrócenie starej bazy może usunąć ich ślady, mimo że pieniądze zostały przyjęte. Plan odbioru integracji opisuje poradnik uruchamiania płatności.

Przerwij samodzielne próby, jeśli podejrzewasz drugie pobranie, nie zgadza się kwota lub klient, dane dostępowe mogły wyciec albo nie masz bezpiecznego sposobu testowania. Podobnie postąp, gdy nie możesz potwierdzić, czy zamówienie zostało opłacone. Najpierw ustal stan z operatorem i osobą odpowiedzialną za rozliczenia.

Hosting pomoże wyjaśnić błąd serwera lub zapory, producent modułu jego obsługę zdarzeń, a operator stan transakcji i konta. W zgłoszeniu opisz już sprawdzone fakty, żeby każda strona wiedziała, jaki fragment procesu wymaga analizy. Nie przekazuj wszystkim pełnych dostępów do płatności.

Po naprawie sprawdź sporne zamówienia, nie tylko nową próbę testową. Ustal, które wymagają realizacji, kontaktu z klientem lub wyjaśnienia zwrotu. Działający checkout nie rozwiązuje automatycznie wcześniejszych rozbieżności.

Dla PayU pomocna jest instrukcja konkretnego modułu. Jeśli potrzebujesz pomocy przy WordPressie, napisz do KC Mobile. Na początek wystarczą adres lub platforma oraz objaw; dodatkowe logi i dane techniczne ustalimy podczas diagnozy bez żądania sekretów w formularzu.

• Błędy w e-commerce: jak znaleźć przyczynę problemów w sklepie i je naprawić
• Jak ułatwić klientom zakupy i płatności w sklepie internetowym?
• go.przelewy24.pl - co to za strona i jak bezpiecznie sprawdzić płatność
• Błędy w rozliczaniu prowizji: kontrola danych, korekty i wypłaty