Problemy z PayU w sklepie internetowym – diagnoza i rozwiązania 2026

PayU w 2026 roku nadal jest numerem jeden wśród operatorów płatności dla polskich sklepów. Udział rynkowy w kategorii bramek online oscyluje wokół 45–55%, Przelewy24 trzyma drugie miejsce, Tpay rośnie w segmencie MŚP, a Stripe zyskuje tam, gdzie liczy się międzynarodowa sprzedaż i subskrypcje.

Kto najczęściej wybiera PayU? Duże i średnie sklepy WooCommerce, PrestaShop oraz platformy SaaS typu IdoSell, Shoper czy Shoplo. Powód jest prozaiczny: gotowa, aktywnie rozwijana wtyczka dla WooCommerce, sensowne stawki przy wyższych obrotach, szybkie uruchomienie oraz szeroka oferta metod płatności (karty, BLIK, przelewy pay-by-link, raty, Google Pay, Apple Pay).

PayU kontra konkurencja w pigułce:

Jeżeli dopiero zaczynasz i wahasz się między operatorami, zajrzyj do porównania rozwiązań PayU oraz zestawienia PayU kontra Przelewy24. A jeśli potrzebujesz kompleksowego doradztwa – skontaktuj się z nami, pomożemy dobrać bramkę pod model biznesowy.

Klient klika Zapłać, spodziewa się ekranu PayU, a zamiast tego widzi białą stronę, błąd 500 albo komunikat Invalid request. To klasyk, który w 9 na 10 przypadków wynika z błędnej konfiguracji, nie z awarii operatora.

Lista kontrolna od najbardziej do najmniej prawdopodobnej przyczyny:

1. Zły merchant ID lub POS ID – najczęściej ktoś przeklejał dane z sandboxa do produkcji albo odwrotnie. Sprawdź w panelu PayU, którego środowiska używa sklep.
2. Błędny Second Key (MD5) – ten klucz służy do podpisywania zapytań. Jeżeli się nie zgadza, PayU odrzuca żądanie na wejściu.
3. Niepoprawny Client ID / Client Secret OAuth (API v4) – brak tokenu to brak transakcji.
4. Tryb sandbox vs production – wtyczka wysyła zapytania na `secure.snd.payu.com`, a konfiguracja jest produkcyjna (albo odwrotnie).
5. Brak SSL / problem z certyfikatem – PayU wymaga HTTPS dla notyfikacji i redirectów. Wygasły Let's Encrypt potrafi zabić bramkę z dnia na dzień.
6. Błędny continueUrl / notifyUrl – literówka albo stary URL po migracji domeny.
7. Konflikty JavaScript w checkoutcie – wtyczki typu cache, lazy-load albo popupy blokujące redirect.

Jak to sprawdzić szybko? Włącz debug log we wtyczce PayU (w WooCommerce w WooCommerce → Płatności → PayU → Dziennik debugowania), spróbuj złożyć zamówienie testowe i otwórz `wp-content/uploads/wc-logs/` – tam zobaczysz surowe requesty i responsy. Jeśli widzisz HTTP 401, to autoryzacja. HTTP 400 – zła struktura requestu. 403 – przeważnie SSL albo IP whitelist.

Więcej o samej konfiguracji krok po kroku znajdziesz w przewodniku PayU w WooCommerce oraz w artykule o problemach z bramkami płatności.

To drugi najczęstszy scenariusz i zarazem najbardziej frustrujący. Klient widzi potwierdzenie płatności, pieniądze schodzą z konta, a w panelu sklepu zamówienie dalej wisi jako oczekujące lub nieopłacone. Problem prawie zawsze leży w notyfikacjach IPN (Instant Payment Notification) – czyli w komunikacji serwer-serwer, którą PayU wysyła do sklepu po zaksięgowaniu wpłaty.

Co może pójść nie tak:

• Endpoint notyfikacji (notifyUrl) zwraca kod inny niż HTTP 200. PayU wymaga dokładnie 200 OK w ciągu kilkunastu sekund.
• Firewall albo Cloudflare blokuje adresy IP PayU (głównie przy agresywnych regułach WAF).
• Podpis notyfikacji jest walidowany błędnym Second Key – wtyczka odrzuca notyfikację, ale panel PayU pokazuje sukces.
• Błąd PHP w hooku zamówienia (np. fatal error w innej wtyczce) rzuca 500 i PayU rezygnuje po kilku retry.
• Przekierowanie z HTTP na HTTPS, które psuje body requestu POST.
• Zbyt długie przetwarzanie po stronie sklepu (> 10 s) – timeout.

Jak zdiagnozować:

1. W panelu PayU wejdź w Transakcje → konkretna transakcja → Historia notyfikacji. Zobaczysz każdą próbę i kod odpowiedzi.
2. Równolegle sprawdź logi Nginx/Apache sklepu (`access.log` i `error.log`) – szukaj requestów POST na endpoint notyfikacji.
3. Jeśli w logach sklepu nie ma ruchu, a PayU pokazuje timeout – problem z siecią/firewallem.
4. Jeśli w logach są 500 – masz błąd PHP. Włącz WP_DEBUG_LOG.
5. Jeśli są 200 ale zamówienie nie zmienia statusu – walidacja podpisu. Sprawdź Second Key.

W praktyce na hostingach takich jak CyberFolks konfiguracja PayU działa out-of-the-box, bez kombinacji z mod_security. Na tanich, ograniczonych hostach trzeba często prosić supportu o whitelistowanie IP bramki. Zobacz też troubleshooting webhooków w e-commerce.

Klient próbuje zapłacić, wpisuje dane karty, widzi komunikat Transakcja odrzucona. Przyczyn jest kilka i nie wszystkie są po stronie PayU.

Po stronie wystawcy karty (bank):

• Niewystarczające środki na rachunku.
• Wygasła karta albo zablokowany CVV.
• Limity dzienne lub miesięczne.
• Brak aktywnej usługi płatności internetowych (karty debetowe często wymagają ręcznej aktywacji).
• Karta zgłoszona jako skradziona lub zastrzeżona.

Po stronie 3D Secure:

• Klient nie potwierdził transakcji w aplikacji bankowej w 5 minut.
• Przeglądarka blokuje popup z kodem SMS/push.
• Wygasł challenge – trzeba spróbować jeszcze raz.

Po stronie PayU (antyfraud):

• Transakcja wpadła w regułę odrzucająca – np. pierwszy zakup z nowego IP na wysoką kwotę, zbyt wiele prób z tej samej karty w krótkim czasie, niezgodność krajów IP/billing.
• Karta z kraju spoza listy obsługiwanej.
• Blokada BIN (niektóre karty prepaid albo wirtualne).

Po stronie sklepu:

• Niepełne lub błędne dane klienta (brak kraju, zły format kodu pocztowego).
• Duplikat orderId – PayU odrzuca transakcję o identyfikatorze, który już istnieje.

Jak pomóc klientowi? Zaproponuj inną metodę – BLIK albo przelew tradycyjny – i sprawdź w panelu PayU konkretny kod błędu. Jeśli widzisz masowo `ERROR_VALUE_MISSING`, problem jest w danych przekazywanych z checkoutu. Jeśli dominuje `SECURE_ERROR`, masz problem z 3DS. Więcej o samej mechanice 3DS w tekście o problemach z 3D Secure w płatnościach online.

Troubleshooting PayU wygląda inaczej w zależności od silnika sklepu. W każdym są te same warstwy (konfiguracja, komunikacja, webhooki), ale narzędzia diagnostyczne i typowe potknięcia są inne.

WooCommerce (oficjalna wtyczka PayU):

• Logi w `wp-content/uploads/wc-logs/payu-*.log`.
• Konfiguracja w WooCommerce → Ustawienia → Płatności → PayU.
• Webhooki pod URLem typu `/?wc-api=payu_notification`.
• Najczęstszy problem: konflikt z wtyczkami cache (WP Rocket, LiteSpeed) – endpoint notyfikacji musi być wykluczony z cache.
• Debug: wtyczka Query Monitor + log PayU.

PrestaShop (moduł PayU):

• Logi w panelu PrestaShopa, Improve → International → Localization → Logs oraz w `var/logs/`.
• Webhooki pod `/modules/payu/notify.php` lub nowszym routingiem.
• Najczęstszy problem: cache Smarty + moduł PayU – po zmianie ustawień trzeba wyczyścić cache ręcznie.
• Wersja modułu vs wersja PrestaShopa – PS 8.x wymaga aktualnego modułu, starsze wersje nie są wspierane.

Shopify:

• Tutaj uwaga – PayU nie jest natywnie wspierane przez Shopify jako gateway z pełnym checkout flow. Shopify w Polsce używa głównie Shopify Payments (kart), a PayU podpina się często jako alternatywna metoda przez Shopify Payments Alternative lub przez zewnętrzny link (np. PayU Link to Pay).
• Jeśli prowadzisz Shopify w Polsce i chcesz pełnego BLIK + rat PayU, rozważ migrację na WooCommerce lub PrestaShop – tam integracja jest pełna i tańsza.

Jeśli myślisz o zmianie platformy, przeczytaj porównanie WooCommerce vs Shopify oraz porównanie WooCommerce vs PrestaShop.

Raty są jednym z największych dźwigni konwersji w kategoriach RTV/AGD, meble, sport, elektronika. PayU oferuje dwa produkty: PayU Raty 0% (klasyczne raty konsumenckie, bez odsetek dla kupującego, koszt finansowania po stronie sklepu) oraz PayU Później (BNPL, płatność odroczona 30 dni albo rozłożenie na 3 raty).

Konfiguracja – co musi się zgadzać:

• Minimalna kwota zamówienia dla rat: zwykle 100–300 PLN (zależnie od promocji).
• Maksymalna kwota: do 20 000 PLN dla rat 0%, dla BNPL niższa.
• Kategoria sklepu – nie wszystkie branże są dopuszczone (np. usługi finansowe, farmaceutyki, dorosłe).
• Aktywna umowa ratalna w panelu PayU – raty nie działają domyślnie, trzeba je włączyć i zaakceptować warunki.

Typowe problemy:

1. Widget rat nie pojawia się na karcie produktu – brak aktywnej usługi albo zła integracja frontowa. Sprawdź w panelu PayU → Produkty → Raty.
2. Klient kończy wniosek, ale zamówienie zostaje w oczekujących – proces ratalny trwa nawet do 48h, status zmienia się dopiero po decyzji kredytowej.
3. Wniosek odrzucony – klient nie przeszedł scoringu. Zaproponuj mu inną formę (karta, BLIK).
4. Brak widgetu mimo włączonej usługi – literówka w kluczu konfiguracji albo konflikt z lazyload obrazków.

W WooCommerce widget rat wkleja się zwykle przez shortcode `[payu_installments]` albo automatycznie przez hook wtyczki. Jeśli go nie widzisz, sprawdź czy theme nie nadpisuje template'u `single-product.php`. Dobry hosting pod WooCommerce – np. CyberFolks – zapewnia wystarczająco szybki TTFB, żeby widget zdążył się załadować przed interakcją użytkownika.

Jeśli utrzymujesz własną integrację z PayU (a nie oficjalną wtyczkę), prędzej czy później spotkasz pytanie: v2, v2_1 czy v4? PayU w ostatnich latach konsekwentnie popycha klientów w stronę REST API v4 i stopniowo deprecjonuje starsze wersje.

Kluczowe różnice:

Typowe problemy przy migracji:

• Hardcodowane adresy `secure.payu.com` bez `/api/v2_1` – 404.
• Brak refresh OAuth tokenu – token żyje 12 godzin, trzeba odświeżać.
• Dane osobowe w zamówieniu – v4 jest bardziej restrykcyjne (wymaga email, first/last name).
• Notyfikacje w v4 mają inną strukturę JSON i inny sposób walidacji (openpayu-signature w nagłówku).
• Kwoty – v4 operuje na groszach (integer), v2 na string z groszami.

Deprecation timeline: PayU od 2024 roku zapowiada odejście od v2, ale realne wyłączenie rozkłada się etapami. Jeśli masz integrację na v2, zaplanuj migrację w 2026 – nowe funkcje (recurring, instant refunds, pełne 3DS 2.0) są już tylko w v4.

Jeśli nie masz developerów in-house, zleć migrację profesjonalistom. Zepsuty checkout kosztuje szybciej, niż myślisz – pojedynczy dzień awarii w dużym sklepie to kilkadziesiąt tysięcy PLN. Dobrym punktem startu jest też skontaktowanie się z nami – zrobimy audyt integracji i wskażemy, co migrować w pierwszej kolejności.

Zwroty w PayU obsługuje się dwiema drogami: przez panel (ręcznie) albo przez API (programowo). Wybór zależy od skali – do kilkunastu zwrotów dziennie panel wystarczy, przy większej liczbie warto zautomatyzować.

Zwrot przez panel PayU:

1. Transakcje → znajdź zamówienie → Zwróć.
2. Wybierz pełny albo częściowy.
3. Podaj kwotę i opcjonalny komentarz.
4. Zatwierdź – środki wracają na kartę/konto klienta w 1–5 dni roboczych.

Zwrot przez API v4:

• Endpoint: `POST /api/v2_1/orders/{orderId}/refunds`
• Body JSON z kwotą w groszach i opisem.
• Odpowiedź zawiera `refundId` i status (`FINALIZED`, `PENDING`, `CANCELED`).
• Notyfikacja o zakończeniu przychodzi na standardowy notifyUrl.

Typowe problemy:

• Zwrot niemożliwy po 180 dniach – PayU ma limit, ale dla transakcji starszych można kontaktować się z BOK operatora.
• BLIK – zwrot wraca na konto bankowe, z którego zainicjowano BLIK.
• Raty – zwrot częściowy na ratach jest bardziej złożony, skraca harmonogram lub zmniejsza raty.
• Prowizja – PayU przy zwrocie zwykle zwraca prowizję (do sprawdzenia w umowie – część modeli prowizja jest bezzwrotna).

W WooCommerce zwroty można wystawiać wprost z poziomu zamówienia (przycisk Zwrot). Wtyczka PayU wysyła request refund do API i aktualizuje status zamówienia po notyfikacji. Jeśli zwroty się zacinają – sprawdź ten sam endpoint notyfikacji, który obsługuje płatności.

Rejestracja w PayU to nie tylko założenie konta – to też proces KYC (Know Your Customer), czyli weryfikacji firmy. Dla standardowej jednoosobowej działalności trwa 1–3 dni robocze. Dla spółek z o.o. i większych podmiotów – do 7–10 dni, a z brakami w dokumentach potrafi się ciągnąć miesiąc.

Co jest wymagane (typowa lista):

1. NIP i REGON firmy.
2. Wypis z KRS (dla spółek) albo wpis do CEIDG (dla JDG).
3. Umowa spółki – dla spółek z o.o.
4. Dane beneficjenta rzeczywistego (UBO) – osoba z ponad 25% udziałów.
5. Dokument tożsamości osoby reprezentującej firmę (zwykle przez selfie + skan).
6. Numer rachunku bankowego firmy (nie prywatnego).
7. Adres URL sklepu + zgodność regulaminu z UE (polityka prywatności, RODO, regulamin sklepu, informacja o zwrotach).

Najczęstsze powody odrzucenia:

• Brak regulaminu sklepu lub niezgodny z prawem konsumenckim.
• Brak polityki prywatności albo cookies.
• URL sklepu prowadzi na stronę w budowie.
• Beneficjent rzeczywisty niezgłoszony do CRBR.
• Numer konta bankowego niepowiązany z firmą.
• Selfie nieczytelne albo bez dokumentu.

Jak przyspieszyć weryfikację:

• Przygotuj wszystkie skany w wysokiej rozdzielczości przed rozpoczęciem procesu.
• Upewnij się, że sklep jest online i ma wszystkie wymagane podstrony (regulamin, polityka prywatności, cookies, RODO).
• Jeśli sprzedajesz produkty regulowane (alkohol, suplementy, usługi finansowe) – dołącz od razu zezwolenia.
• Po złożeniu wniosku odpowiadaj na e-maile weryfikatora w ciągu 24h – opóźnienia z twojej strony blokują proces.

Jeśli twój sklep nie ma jeszcze wymaganych dokumentów prawnych, zajrzyj do przewodnika o regulaminie sklepu internetowego i RODO w e-commerce.

Klienci pytają o to regularnie: zacząłem na Przelewy24, czy opłaca się przejść na PayU (albo odwrotnie)? Odpowiedź zależy od trzech rzeczy: skali sprzedaży, struktury metod płatności i tego, czy planujesz raty.

Kiedy PayU wygrywa:

• Obroty powyżej 50 000 PLN/miesiąc – stawki negocjowalne w dół.
• Sprzedajesz w kategoriach, gdzie raty robią różnicę (RTV, meble, sport, rowery, biżuteria).
• Chcesz gotowej integracji z WooCommerce/PrestaShop bez developmentu.
• Zależy ci na Google Pay / Apple Pay out-of-the-box.
• Potrzebujesz rozbudowanego antyfraudu przy wysokich koszykach.

Kiedy Przelewy24 wygrywa:

• Mniejsza skala – prowizje przy niskich obrotach są konkurencyjne.
• Sklep niszowy (edukacja, fundacje, usługi B2B) – P24 ma elastyczniejszy onboarding.
• Minimalna liczba dostępnych metod wystarcza.
• Cenisz prostszy panel i bardziej bezpośredni kontakt z BOK.

Jak migrować bez bólu (plan w 5 krokach):

1. Załóż konto u nowego operatora i przejdź weryfikację przed odłączeniem starego.
2. Skonfiguruj wtyczkę na staging/test i przepuść 3–5 transakcji testowych (karta, BLIK, przelew).
3. Zaplanuj okno migracji poza godzinami szczytu (zwykle nocą).
4. Włącz obie bramki równolegle na 7–14 dni – stare zwroty idą przez starego operatora, nowe płatności przez nowego.
5. Po okresie przejściowym wyłącz starą bramkę i zarchiwizuj konto (nie zamykaj – mogą być jeszcze chargebacki).

Pełne porównanie operatorów znajdziesz w artykule PayU vs Przelewy24 oraz w porównaniu bramek płatności 2026. Zobacz też problemy z Przelewy24 i problemy z BLIK – przy migracji warto znać słabe punkty obu stron.

Checklist przed migracją:

Potrzebujesz pomocy przy migracji bramki albo integracji PayU od zera? Napisz do nas – zrobimy to pod klucz, z testami, backupem i bez utraconych transakcji.