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

Jak działa pierwsza diagnostyka bramki płatności w sklepie

Kiedy klient pisze, że nie może zapłacić, masz dosłownie kilkanaście minut, żeby uratować zamówienie. Zamiast panikować, przejdź przez te pięć kroków po kolei – w tej kolejności rozwiązuję 9 na 10 zgłoszeń od klientów prowadzących sklepy na WooCommerce i PrestaShop.

1. Sprawdź status operatora – wejdź na status.payu.com, p24status.pl albo status.tpay.com. Jeśli świeci się czerwone, problem jest po stronie bramki, nie Twojej. W tym wypadku komunikat dla klientów na stronie głównej i czekanie to jedyne, co możesz zrobić.

2. Zrób testowy zakup za 1 zł – włącz tryb incognito, dodaj produkt, przejdź do checkoutu i spróbuj zapłacić. Notuj, w którym momencie pojawia się błąd: na stronie koszyka, przy przekierowaniu do bramki, po powrocie ze strony banku.

3. Sprawdź certyfikat SSL – w przeglądarce kliknij kłódkę przy adresie sklepu. Jeśli widzisz ostrzeżenie albo data ważności minęła, to jest Twój winowajca. Bramki płatności blokują transakcje z nieważnym SSL.

4. Otwórz konsolę dewelopera (F12 → Console). Czerwone komunikaty typu Mixed Content, CORS error albo Failed to load resource zdradzają konkretne pliki, które blokują checkout.

5. Zajrzyj do logów sklepu – w WooCommerce: WooCommerce → Status → Logi. Wybierz log z dzisiaj z prefiksem nazwy bramki (np. payu, p24). Tam znajdziesz dokładny komunikat błędu, który dostała Twoja wtyczka.

Te pięć kroków zajmuje 10 minut, a oszczędza godziny zgadywania. Jeśli na którymkolwiek się zatniesz, warto mieć pod ręką kontakt do programisty – więcej o typowych awariach piszę w wpisie problemy z BLIK w sklepie oraz problemy z PayU – diagnostyka.

Klient zapłacił, ale zamówienie wisi w oczekujących – problem z webhookiem

To absolutny klasyk i pewnie najczęstsze zgłoszenie, jakie dostaję. Klient wraca z bramki z komunikatem płatność zaakceptowana, ale w panelu sklepu zamówienie wciąż ma status oczekuje na płatność. Pieniądze są na koncie operatora, a Twój sklep o tym nie wie. Powód: webhook (czyli IPN – Instant Payment Notification) nie dotarł albo serwer odpowiedział kodem innym niż HTTP 200.

Jak działa webhook w praktyce. Po zaksięgowaniu płatności bramka wysyła HTTP POST na ustalony adres w Twoim sklepie (np. /wc-api/WC_Gateway_PayU). Twój sklep musi odpowiedzieć kodem 200 OK – wtedy operator wie, że dostałeś informację. Jeśli odpowiada 404, 403, 500 albo timeout, status zamówienia nie zmienia się.

Najczęstsze przyczyny błędu webhooka:

• W panelu operatora ustawiony zły URL (zostawiony adres ze stagingu, brak https://)
• Cloudflare albo WAF blokuje requesty z IP operatora
• Plugin cache (LiteSpeed, WP Rocket) cache'uje endpoint webhooka
• Wygasły SSL – operator nie wyśle requesta na cert z błędem
• Plik .htaccess blokuje POST requesty na konkretne ścieżki
• Mod_security na hostingu odrzuca payload z polskimi znakami

Co zrobić. W panelu operatora znajdź sekcję Logi powiadomień / Notyfikacje. Tam zobaczysz, czy webhook był wysłany i jaki kod odpowiedzi dostał operator. Jeśli widzisz 200 OK, problem jest w logice sklepu. Jeśli inny kod – problem na serwerze. Pełny przewodnik konfiguracji znajdziesz w konfiguracji Przelewy24 w WooCommerce oraz integracji PayU z WooCommerce. Jeśli masz dziesiątki zamówień w zawieszeniu, zadzwoń pod +48 604 939 140 – ratujemy takie sytuacje w 1-2 godziny.

Klient nie jest przekierowywany do bramki – błędy SSL, mixed content i JS

Drugi częsty scenariusz: klient klika Zamawiam i płacę, strona ładuje się chwilę i… nic. Albo wyrzuca go z powrotem do koszyka. Albo pokazuje białą stronę. Znaczy to, że JavaScript checkoutu się wywalił, albo serwer zwrócił błąd zanim klient w ogóle dotarł do bramki.

Mixed content (HTTPS vs HTTP). Twój sklep ma SSL, ale któryś skrypt albo obrazek ładuje się po HTTP. Nowoczesne przeglądarki blokują takie requesty – i checkout pada. Najczęściej winowajcami są stare wtyczki, niezaktualizowany szablon, hardcodowane URL-e w bazie. Sprawdź konsolę przeglądarki (F12) – czerwone ostrzeżenia z słowem Mixed Content wskazują dokładnie który plik.

Konflikty JavaScript. Niedawno aktualizowałeś wtyczkę slidera, popupów albo czata? Nowy skrypt może rzucać błąd, który blokuje wszystkie inne. Wyłącz wtyczki po kolei (zaczynając od najnowszych) i testuj checkout. To zwykle prowadzi do winowajcy w 5-10 minut.

Mod_security i WAF. Hosting może blokować requesty z konkretnymi parametrami. Symptom: 403 Forbidden przy próbie zapłaty. Rozwiązanie: napisz do supportu hostingu z nagłówkiem User-Agent klienta i dokładnym czasem zdarzenia – poproś o whitelistowanie reguł.

Wtyczki cache i optymalizacji. WP Rocket, LiteSpeed Cache, W3 Total Cache potrafią agresywnie minifikować JS i łamać skrypty bramek. W ustawieniach wykluczaj plik z nazwą operatora (payu, p24, tpay, stripe) z minifikacji i lazy loadingu.

Więcej o ustawianiu cache pod sklep w wpisie bramki płatności w WooCommerce – konfiguracja oraz w BLIK w WooCommerce.

Błędy 3D Secure i Strong Customer Authentication – co poszło nie tak

Od czasu wdrożenia PSD2 w 2021 roku każda transakcja kartą powyżej 30 EUR wymaga silnego uwierzytelnienia (SCA) – zwykle przez 3D Secure. Klient po podaniu danych karty dostaje SMS, push w aplikacji bankowej albo musi potwierdzić w aplikacji. I tutaj zdarza się większość odrzuconych płatności kartą.

Typowe scenariusze błędów 3DS w 2026:

• Klient nie dostał SMS-a (problem operatora telekomunikacyjnego, nie Twój)
• Bank wymaga aplikacji mobilnej, której klient nie zainstalował (ING Mobile, Santander Mobile)
• Timeout na stronie potwierdzenia 3DS – klient za długo szukał telefonu
• Karta wystawiona za granicą – niektóre zagraniczne banki nie obsługują polskiego 3DS
• Karta przedpłacona/wirtualna bez aktywnego SCA
• Klient kliknął anuluj zamiast potwierdź na ekranie banku

Co możesz zrobić jako sklep. Niewiele bezpośrednio – 3DS to interakcja klient-bank. Ale możesz:

1. Pokazać na thank you page komunikat: jeśli płatność nie przeszła, sprawdź SMS lub aplikację banku
2. Włączyć alternatywne metody (BLIK, Apple Pay, Google Pay) – mają wyższą skuteczność niż karta
3. W panelu bramki włączyć tryb frictionless dla małych kwot (poniżej 30 EUR – zwolnienie z SCA)
4. Pisać klientowi w mailu z odzyskiwaniem porzuconego koszyka konkretną instrukcję, jak dokończyć

Jeśli odsetek nieudanych transakcji 3DS przekracza 15%, to sygnał, że warto zmienić bramkę albo dodać alternatywę. Porównanie zdolności konwersyjnych poszczególnych operatorów w Stripe vs PayU – który lepszy oraz problemy z Przelewy24.

BLIK, Apple Pay, Google Pay nie wyświetlają się – jak włączyć

BLIK to dziś najpopularniejsza metoda płatności w polskim e-commerce – według danych Polskiego Standardu Płatności w 2026 odpowiada za ponad 50% płatności online. Apple Pay i Google Pay rosną razem ze sprzedażą na mobile. Jeśli ich nie pokazujesz w checkoucie, tracisz konwersję. A tracisz, jeśli:

BLIK się nie pokazuje:

• Nie aktywowałeś go w panelu operatora (osobny checkbox, czasem osobna umowa)
• Wyłączony w ustawieniach wtyczki w sklepie (Status → Logi może pokazać dlaczego)
• Limit transakcyjny niższy niż wartość koszyka klienta (BLIK ma dzienny limit 1000-3000 zł)
• Klient korzysta z banku, który nie obsługuje BLIK Online (rzadkie, ale się zdarza)

Apple Pay nie pokazuje się klientowi:

• Domena nie zweryfikowana w panelu Apple (potrzebny plik apple-developer-merchantid-domain-association)
• Klient używa innej przeglądarki niż Safari (Apple Pay działa tylko w Safari na iOS/macOS)
• Brak aktywnej karty w aplikacji Wallet
• Twoja bramka nie ma podpisanej umowy z Apple (nie każdy operator obsługuje Apple Pay w Polsce)

Google Pay nie wyświetla się:

• Klient ma starszą wersję Chrome lub Androida bez Google Pay API
• Brak konfiguracji merchant ID w panelu bramki
• W ustawieniach wtyczki wyłączony Google Pay button

Test: otwórz checkout na iPhonie w Safari (Apple Pay) i w Chrome na Androidzie (Google Pay) – każda metoda powinna pokazać natywny przycisk. Jeśli nie pokazuje się, sprawdź logi i konfigurację merchant w panelu operatora. Pełna instrukcja w problemach z BLIK – troubleshooting.

Bramka odrzuca transakcje – limity, antyfraud i geo-blocking

Czasem wszystko działa technicznie, ale konkretne transakcje są odrzucane. To celowe działanie systemów antyfraudowych operatora – mają chronić Ciebie i klienta przed nadużyciami. Ale czasem są zbyt restrykcyjne i blokują uczciwe zakupy.

Najczęstsze powody odrzuceń:

• Velocity check – ten sam IP/karta próbuje płacić więcej niż 3 razy w 5 minut → blokada na 24h
• Geo-blocking – klient z IP zagranicznego, polska karta, wysoka kwota → automatyczne odrzucenie
• CVV mismatch – błędny kod CVV trzy razy z rzędu blokuje kartę
• Risk score – kombinacja sygnałów (nowy klient, drogi produkt, nietypowy kraj IP) podbija ryzyko
• Niezgodność danych – inny adres rozliczeniowy niż w banku karty
• Karta na czarnej liście – wcześniej była użyta do oszustwa u innego sprzedawcy

Co możesz zrobić:

1. W panelu bramki sprawdź sekcję Transakcje odrzucone – znajdziesz powód (response code od banku)
2. Skontaktuj się z opiekunem operatora i poproś o weryfikację reguł antyfraudowych
3. Dla stałych klientów B2B zwróć się o białą listę IP i kart (whitelist)
4. Dla testów wewnętrznych firmy korzystaj z trybu sandbox, nie produkcyjnego

Pamiętaj, że im niższy limit, tym mniej fraudu, ale i mniej sprzedaży – to balans, który ustawiasz razem z opiekunem konta. W większości przypadków domyślne ustawienia są w porządku, problem pojawia się dopiero przy nietypowych zamówieniach (drogie B2B, sprzedaż za granicę, subskrypcje).

Prowizje, refundy i chargebacki – gdzie najczęściej coś idzie nie tak

Zwroty pieniędzy klientom to drugi najczęstszy ból głowy po awariach checkoutu. Brzmi banalnie – klikasz Zwróć w panelu i gotowe – ale w praktyce zdarzają się sytuacje, które kosztują nerwy i pieniądze.

Reversal vs Refund. To dwie różne operacje. Reversal (anulowanie) dotyczy transakcji, która jeszcze nie została zaksięgowana – tego samego dnia. Refund (zwrot) dotyczy już zaksięgowanej transakcji – środki wracają w 1-5 dni roboczych. Klienci często nie rozumieją tej różnicy i piszą, że zwrot trwa za długo.

Częściowy zwrot. Klient kupił trzy produkty, oddaje jeden – musisz zwrócić tylko część. Większość bramek to obsługuje, ale w panelu trzeba wpisać dokładną kwotę (z VAT, z kosztem dostawy lub bez). Łatwo o pomyłkę – polecam zawsze przeliczać dwa razy.

Chargebacki. Klient po zakupie kwestionuje transakcję w banku – bank odbiera Ci pieniądze i obciąża karą (zwykle 100-300 zł niezależnie od kwoty). Najczęstsze powody: niedostarczona przesyłka, produkt niezgodny z opisem, fraud (skradziona karta). Masz zwykle 7-14 dni na odpowiedź z dowodami (numer śledzenia, korespondencja, zdjęcia produktu).

Prowizje – uważaj na ukryte koszty. Operatorzy reklamują niskie stawki (1,2%, 1,5%), ale do tego dochodzą:

• Opłata za wypłatę (1-5 zł od każdej)
• Opłata miesięczna abonamentowa (0-200 zł)
• Wyższe stawki dla kart Amex i zagranicznych (do 3,5%)
• Opłata za chargeback (100-300 zł)
• Opłata za sandbox testowy w niektórych planach

Zanim podpiszesz umowę, przelicz koszt na realnym wolumenie miesięcznym. Tabela porównawcza w sekcji Wybór bramki niżej.

Wybór bramki dla polskiego sklepu – porównanie 2026

W Polsce w 2026 roku liczy się głównie czterech graczy: Przelewy24, PayU, Tpay i Stripe. Każdy ma inne mocne strony. Poniżej porównanie najważniejszych parametrów.

Co wybrać dla małego sklepu (do 50 transakcji miesięcznie): Przelewy24. Najszybsza aktywacja, darmowy moduł WooCommerce, stabilne BLIK, polska obsługa. Brak miesięcznego abonamentu.

Dla sklepu rosnącego (50-500 transakcji): PayU. Lepsze warunki dla wyższego wolumenu, zaawansowany antyfraud, dobre raportowanie. Możliwość negocjacji prowizji od 200 transakcji miesięcznie.

Dla sklepu z subskrypcjami i SaaS: Tpay lub Stripe. Tpay ma dobrą obsługę cyklicznych płatności kartą w polskim środowisku, Stripe oferuje najlepsze API jeśli masz developera.

Dla sprzedaży za granicę: Stripe. Obsługa 135+ walut, lokalne metody płatności w UE i USA, wbudowana obsługa VAT MOSS. Kosztuje więcej, ale skaluje się globalnie.

Pełne porównania w Stripe vs PayU – który wybrać, Przelewy24 vs PayU oraz problemach z PayU – kiedy zmienić bramkę.

Integracja z WooCommerce, Shopify i PrestaShop – kluczowe różnice

Każda platforma ma swoje pułapki integracyjne. Wiem, bo wdrażałem już kilkadziesiąt sklepów na każdej z trzech – problemy są przewidywalne, ale różne.

WooCommerce. Najbardziej elastyczny, ale wymaga uważnego pilnowania aktualizacji. Każdy operator ma oficjalną wtyczkę (PayU dla WooCommerce, Przelewy24 dla WooCommerce, Tpay Payments). Instalacja trwa 15 minut, ale konfiguracja webhooków często wymaga ręcznego ustawienia URL w panelu operatora i sprawdzenia w WooCommerce → Status → Logi czy notyfikacje dochodzą. Najczęstszy problem: aktualizacja WooCommerce psuje kompatybilność z wtyczką operatora – zawsze rób backup przed update.

Shopify. Najprostsza integracja – w App Store dodajesz aplikację Przelewy24/PayU jednym kliknięciem. Ale Shopify pobiera dodatkową opłatę 2% od każdej transakcji, jeśli używasz zewnętrznej bramki (zamiast Shopify Payments, które w Polsce nie jest dostępne dla wszystkich). Dla małego sklepu może to podwoić koszty płatności. Zaleta: Shopify sam zarządza SSL i aktualizacjami – mniej rzeczy może się zepsuć.

PrestaShop. Pomiędzy WooCommerce a Shopify pod względem złożoności. Moduły operatorów płatne (50-300 zł jednorazowo) lub darmowe (gorszej jakości). Aktualizacje samego PrestaShop bywają bolesne – moduły płatności po update głównej wersji często wymagają reinstalacji. Zaleta: szybsze checkouty niż WooCommerce na średnim hostingu.

Sandbox – nie pomijaj. Każda z platform pozwala testować bramkę w trybie sandbox. PayU ma dedykowane dane testowe (karta 4012 0010 3714 1112), Przelewy24 podobnie. Zrób minimum 5 testowych zamówień przed włączeniem produkcji: zakup udany, anulowany, częściowy zwrot, pełny zwrot, sytuacja z 3DS. To 30 minut, które oszczędzają tygodnie problemów.

Jak uniknąć 90% problemów z płatnościami – best practices

Większość awarii bramek to nie nagłe katastrofy, tylko skutek zaniedbania kilku rutynowych spraw. Wprowadź te nawyki, a Twój checkout będzie działał miesiącami bez interwencji.

1. Testowy zakup raz w tygodniu. Co poniedziałek rano: incognito, dodaj produkt za 1 zł, zapłać, sprawdź czy zamówienie zmieniło status na opłacone. Wykryjesz problem zanim zrobi to klient.

2. Monitoring uptime checkoutu. Narzędzia jak UptimeRobot albo BetterStack potrafią pingować konkretne URL co 5 minut i alarmować mailem/SMS-em. Konfiguracja: monitoruj /checkout, /thank-you i endpoint webhooka.

3. Aktualizacje na stagingu, nie na produkcji. Zawsze testuj nową wersję wtyczki płatności na kopii sklepu (subdomena staging), nie od razu na produkcji. CyberFolks i większość lepszych hostingów (NIE nazwa.pl, NIE home.pl) oferuje staging w jednym kliknięciu.

4. Backupy automatyczne codzienne. Jeśli aktualizacja zepsuje checkout, chcesz móc cofnąć w 5 minut. UpdraftPlus, Duplicator albo backup hostingowy – byle codzienny i przechowywany przez 30 dni.

5. Auto-renew SSL z monitoringiem. Let's Encrypt odnawia się sam co 90 dni, ale czasem coś pęka. Ustaw alert mailowy 14 dni przed wygaśnięciem certyfikatu – większość paneli (CloudPanel, cPanel) ma to wbudowane.

6. Logi włączone i przeglądane raz w miesiącu. WooCommerce → Status → Logi. Filtruj po nazwie bramki. Czerwone błędy w logach to często wczesne ostrzeżenie przed awarią.

7. Plan B – druga bramka. Trzymaj jako backup drugą skonfigurowaną bramkę (np. Tpay obok Przelewy24). Jeśli główna padnie, w 2 minuty przełączasz w panelu i klienci dalej kupują.

8. Dokumentacja kontaktów awaryjnych. Trzymaj w jednym pliku: numery do supportu operatorów, login do paneli, kontakt do programisty. Kiedy padnie o 22:00 w niedzielę, nie chcesz tego szukać.

Wdrożenie tych ośmiu zasad zajmuje pół dnia, a oszczędza dziesiątki godzin gaszenia pożarów. Jeśli wolisz, żeby ktoś to zrobił za Ciebie razem z migracją sklepu na bezpieczny hosting, zadzwoń pod +48 604 939 140 albo zobacz ofertę sklepów internetowych KC Mobile. Konfigurujemy bramki, monitoring i backupy w pakiecie.

Wiele z tych problemów można rozwiązać samodzielnie – ale gdy brakuje czasu, narzędzi lub utknąłeś na etapie diagnozy, warto zlecić pracę zespołowi który robi to codziennie. W KC Mobile zajmujemy się tym od lat.

Zobacz powiązane usługi i materiały:

• sklep internetowy na WooCommerce
• pozycjonowanie sklepu z meblami
• poradnik Magento dla sklepów
• jak zacząć dropshipping
• PayU vs Przelewy24

Jeśli opis w tym wpisie nie dotyczy dokładnie Twojej sytuacji, napisz do nas – odpowiadamy w ciągu 24 godzin roboczych.