Płatności i dostawa to elementy, z którymi klient sklepu ma bezpośredni kontakt na każdym zamówieniu — ich poprawna konfiguracja bezpośrednio wpływa na to, czy klient dokończy zakup.

Objaw

Zgłoszenia dotyczą konfiguracji nowych metod płatności i dostawy przy uruchamianiu sklepu, a także problemów w już działających sklepach — płatności nie księgują się automatycznie, etykiety kurierskie nie generują się poprawnie, albo klienci zgłaszają problemy przy finalizacji zamówienia.

Możliwe przyczyny

Niepełna konfiguracja bramki płatności — brak powiązania statusu płatności ze statusem zamówienia.
Błędne dane w integracji z kurierem, uniemożliwiające generowanie listów przewozowych.
Nieaktualne klucze API operatora płatności lub kuriera po zmianie po ich stronie.
Brak testowej transakcji przed uruchomieniem produkcyjnym, przez co błąd wykrywa dopiero pierwszy klient.

Co robimy

Konfigurowane są bramki płatności — PayU, Przelewy24, Tpay, Stripe, PayPal i inne — wraz z automatycznym powiązaniem statusu wpłaty ze statusem zamówienia. Wdrażane są formy dostawy z integracją kurierów (InPost, DPD, DHL, GLS, Poczta Polska) oraz brokerów logistycznych (Apaczka, Sendit, Furgonetka), z automatycznym generowaniem listów przewozowych. Przed uruchomieniem wykonywana jest testowa transakcja przechodząca przez cały proces — od zamówienia, przez płatność, po wygenerowanie etykiety kurierskiej.

Ile to trwa

Konfiguracja podstawowego zestawu płatności i dostaw to zwykle jeden do dwóch dni pracy, zależnie od liczby integrowanych operatorów.

Co można zrobić samemu, zanim przyjedzie serwisant

Warto założyć konta u wybranych operatorów płatności i kurierów z wyprzedzeniem — proces weryfikacji takiego konta po stronie operatora bywa dłuższy niż sama konfiguracja techniczna w sklepie.

Czego nie robić: nie warto uruchamiać sklepu produkcyjnie bez wykonania choćby jednej pełnej, testowej transakcji — to jedyny sposób, żeby upewnić się, że cały proces faktycznie działa od początku do końca.

Warunki

Konfiguracja płatności i dostaw wyceniana jest indywidualnie, zależnie od liczby integrowanych operatorów.

Warianty problemów z płatnościami online w sklepie internetowym

Nieprawidłowości w działaniu bramek płatności mogą przybierać zróżnicowane formy w zależności od używanego silnika sklepu oraz wybranego operatora transakcji. Poniżej przedstawiono najczęściej występujące sytuacje problemowe.

Brak automatycznej zmiany statusu zamówienia po wpłacie — klient finalizuje transakcję w banku lub za pomocą kodu BLIK (polski standard płatności mobilnych), środki zostają pobrane z jego rachunku, jednak w panelu administracyjnym sklepu zamówienie stale widnieje jako oczekujące na płatność lub anulowane. Przyczyną jest najczęściej brak poprawnej komunikacji asynchronicznej za pomocą webhooków (mechanizmu automatycznego przesyłania powiadomień HTTP między serwerem płatności a sklepem) lub błędnie skonfigurowany adres powiadomień IPN (Instant Payment Notification, czyli powiadomienia o statusie transakcji wysyłanego bezpośrednio przez bramkę).

Pętla przekierowań lub błąd powrotu do sklepu — po zatwierdzeniu wpłaty na stronie pośrednika klient nie zostaje poprawnie przekierowany na stronę z podziękowaniem za zakup (tzw. return URL, czyli adres docelowy powrotu po udanej transakcji), lecz trafia na pustą stronę koszyka, błąd 404 (brak strony) lub pętlę logowania. Wynika to zazwyczaj z problemów z obsługą sesji użytkownika w przeglądarce, konfliktów pamięci podręcznej serwera (cache) lub nieprawidłowo zdefiniowanych reguł w pliku konfiguracyjnym serwera www.

Odrzucanie transakcji kartowych i zagranicznych — klienci próbujący zapłacić kartą debetową lub kredytową otrzymują ogólny komunikat o błędzie autoryzacji. Źródłem usterki bywa brak wdrożenia protokołu 3D Secure 2.0 (standardu dwuskładnikowego uwierzytelniania płatności kartą wymaganego przez unijne dyrektywy bankowe), niepoprawna konfiguracja obsługi wielu walut w sklepie lub brak aktywacji kanałów kartowych na koncie sprzedawcy u operatora.

Błąd sumy kontrolnej lub niezgodność sygnatury — system płatności odrzuca zapytanie ze sklepu na samym początku procesu zakupu z komunikatem o błędzie podpisu cyfrowego (signature mismatch). Dzieje się tak, gdy klucz prywatny (Secret Key) wpisany w ustawieniach modułu sklepu różni się od klucza wygenerowanego w panelu operatora lub gdy silnik sklepu generuje inny algorytm szyfrowania danych niż oczekiwany przez bramkę.

Trudności przy integracji metod dostawy i kurierów

Prawidłowe wdrożenie modułów logistycznych wymaga synchronizacji danych adresowych, wymiarów paczek oraz parametrów technicznych API (Application Programming Interface, czyli interfejsu programistycznego łączącego sklep z serwerem przewoźnika). W praktyce pojawiają się następujące komplikacje.

Błędy walidacji danych adresowych — moduł kurierski odrzuca próbę wygenerowania listu przewozowego, gdy formularz zamówienia przepuścił brak numeru budynku, niepoprawny format kodu pocztowego lub brak numeru telefonu komórkowego. Systemy kurierskie wymagają rygorystycznego formatu danych, dlatego formularz koszyka musi posiadać walidację w czasie rzeczywistym.

Problemy z mapami punktów odbioru i automatów paczkowych — widget mapy służący do wyboru maszyny paczkowej lub punktu odbioru nie wyświetla się, zawiesza stronę zamówienia lub nie przekazuje wybranego kodu punktu do bazy danych zamówienia. Przyczyną bywają konflikty skryptów JavaScript w szablonie sklepu, brak ważnego klucza map dostawcy lub blokady wynikające z restrykcyjnych nagłówków bezpieczeństwa serwera.

Niezgodność wagowo-gabarytowa przesyłek — automatyczne tworzenie przesyłek zawodzi w momencie, gdy produkty w koszyku nie mają przypisanych parametrów wagowych lub wymiarów. Przewoźnicy wymagają zdefiniowania gabarytów (np. gabaryt A, B lub C w przypadku automatów paczkowych), a brak tych parametrów w katalogu produktów wymusza ręczne uzupełnianie danych przy każdym zamówieniu.

Rozbieżność między wygenerowaniem etykiety a zleceniem odbioru — automatyczne utworzenie etykiety w formacie PDF (Portable Document Format) nie zawsze oznacza wysłanie zlecenia podjazdu kuriera po odbiór paczek z magazynu. Brak konfiguracji automatycznego tworzenia protokołów przekazania (tzw. manifestu odbioru) prowadzi do opóźnień w przekazywaniu przesyłek do sortowni.

Błędy popełniane podczas samodzielnych prób konfiguracji

Wielu właścicieli sklepów podejmuje próby samodzielnego wdrażania modułów płatności i wysyłek, co przy braku doświadczenia technicznego prowadzi do typowych usterek paraliżujących sprzedaż.

Mieszanie środowiska testowego z produkcyjnym — najczęstszym błędem jest pozostawienie aktywnych kluczy ze środowiska testowego (tzw. sandbox, czyli symulatora transakcji służącego programistom do weryfikacji połączenia) po uruchomieniu sklepu dla klientów. W takim stanie żadna realna płatność nie może zostać zrealizowana, a klienci otrzymują błędy autoryzacji.

Brak aktywnego i poprawnie wdrożonego certyfikatu SSL — certyfikat SSL (Secure Sockets Layer, protokół zapewniający szyfrowanie danych przesyłanych między przeglądarką a serwerem) jest bezwzględnym wymogiem operatorów płatności. Samodzielne włączenie certyfikatu bez wymuszenia przekierowania całego ruchu na bezpieczny protokół HTTPS oraz bez eliminacji zjawiska tzw. mixed content (wczytywania części zasobów strony przez niezabezpieczony protokół HTTP) skutkuje blokowaniem komunikacji przez serwery pośredników płatności.

Blokowanie powiadomień przez zapory serwerowe — zainstalowanie wtyczek bezpieczeństwa lub włączenie zapory WAF (Web Application Firewall, systemu filtrującego i blokującego podejrzany ruch sieciowy) na serwerze hostingowym może prowadzić do omyłkowego uznania zapytań wysyłanych przez serwery operatorów płatności za próby ataku. W rezultacie serwer sklepu zwraca błąd 403 Forbidden, a status zamówienia nigdy nie ulega zmianie na opłacone.

Pominięcie testów w scenariuszach negatywnych — weryfikacja ogranicza się zazwyczaj do jednej udanej transakcji. Nie sprawdza się sytuacji, w których klient anuluje płatność, zamyka okno przeglądarki w trakcie autoryzacji lub gdy transakcja zostanie odrzucona przez bank z powodu braku środków. Brak konfiguracji tych ścieżek powoduje, że produkty mogą zostać bezpodstawnie zablokowane w stanach magazynowych.

Rozróżnienie problemów sklepu od awarii zewnętrznych operatorów

Gdy w sklepie dochodzi do zatrzymania procesu zakupowego, kluczowe jest sprawne zdiagnozowanie, czy źródło problemu leży w oprogramowaniu sklepu, czy po stronie infrastruktury zewnętrznej firmy.

Objawy leżące po stronie sklepu internetowego:

Błędy składni w kodzie szablonu lub konflikt wtyczek blokujący wyświetlanie metod płatności w koszyku.
Brak uprawnień do zapisu plików tymczasowych na serwerze hostingowym, uniemożliwiający zapisanie pobranej etykiety kurierskiej.
Nieprawidłowo ustawione reguły w plikach systemowych blokujące odbiór powiadomień webhook.
Przestarzała wersja wtyczki integracyjnej nieobsługująca aktualnych wymogów technologicznych operatora.

Objawy leżące po stronie operatora lub banku:

Prace konserwacyjne w systemie bankowości elektronicznej konkretnego banku, uniemożliwiające zalogowanie się klienta do banku.
Przekroczenie limitów zapytań do interfejsu API kuriera (tzw. rate limiting, czyli ograniczenie liczby dozwolonych zapytań w jednostce czasu).
Brak ukończonej weryfikacji tożsamości firmy lub konta bankowego (procedura KYC — Know Your Customer, czyli weryfikacja prawno-finansowa przedsiębiorcy przez instytucję płatniczą).
Wyczerpanie salda przedpłaconego (pre-paid) na koncie u brokera kurierskiego, co automatycznie blokuje generowanie nowych listów przewozowych.

Procedura profesjonalnego wdrażania metod płatności i dostaw

Prawidłowe uruchomienie modułów transakcyjnych i wysyłkowych w sklepie internetowym przebiega według usystematyzowanego schematu technicznego.

1. Weryfikacja kont operatorskich i kluczy autoryzacyjnych — sprawdzenie statusu kont w panelach PayU, Przelewy24, Tpay, Stripe, InPost, DPD czy brokerów wysyłkowych. Pobranie produkcyjnych identyfikatorów punktu płatności (POS ID), kluczy API oraz kluczy szyfrujących.

2. Instalacja i konfiguracja oficjalnych modułów integracyjnych — wdrożenie aktualnych i certyfikowanych wtyczek dla danego silnika e-commerce. Ustawienie właściwych adresów URL dla powiadomień zwrotnych oraz zdefiniowanie zachowania sklepu w przypadku udanej, odrzuconej lub anulowanej transakcji.

3. Konfiguracja matrycy metod dostawy i płatności — powiązanie poszczególnych form wysyłki z odpowiadającymi im kanałami płatności. Wyłączenie możliwości wyboru płatności przy odbiorze (za pobraniem) dla metod dostawy, które tego nie obsługują, oraz zdefiniowanie progów darmowej dostawy i stawek zależnych od wagi koszyka.

4. Testy funkcjonalne w środowisku kontrolowanym — wykonanie serii próbnych zamówień weryfikujących zachowanie koszyka przy różnych kombinacjach produktów, adresów dostawy oraz form rozliczenia.

5. Testowa transakcja produkcyjna — realizacja rzeczywistej transakcji o minimalnej wartości pieniężnej, potwierdzenie automatycznej zmiany statusu zamówienia w panelu sklepu, wygenerowanie próbnego listu przewozowego oraz wykonanie zwrotu wpłaconych środków przez panel operatora.

Często zadawane pytania o płatności i dostawy w e-commerce

Dlaczego zamówienie ma status „oczekuje na płatność”, mimo że klient dokonał przelewu?

Taka sytuacja oznacza, że serwer płatności nie był w stanie powiadomić sklepu o zaksięgowaniu środków. Najczęstszym powodem jest błędny adres powiadomień (webhook URL) wpisany w panelu operatora, blokada ruchu przychodzącego przez zaporę sieciową serwera lub brak obsługi protokołu HTTPS. W takim wypadku konieczna jest analiza dziennika błędów (logów serwera) i ponowne skonfigurowanie punktu końcowego odbierającego dane.

Czy sklep internetowy może działać z płatnościami online bez certyfikatu SSL?

Nie jest to możliwe. Certyfikat SSL (protokół szyfrujący przesyłane informacje) jest technicznym warunkiem koniecznym do uruchomienia jakiejkolwiek bramki płatności online. Operatorzy płatności automatycznie odrzucają próby połączenia ze sklepów, które nie posiadają ważnego i poprawnie zainstalowanego certyfikatu szyfrującego całą domenę.

Czym różni się integracja bezpośrednia z kurierem od korzystania z brokera wysyłkowego?

Integracja bezpośrednia wymaga podpisania indywidualnej umowy z danym przewoźnikiem (np. InPost, DPD, DHL) i deklaracji określonego wolumenu paczek miesięcznie, co pozwala uzyskać indywidualne stawki. Integracja przez brokera logistycznego (np. Furgonetka, Apaczka) pozwala na korzystanie z usług wielu kurierów jednocześnie bez konieczności podpisywania osobnych umów z każdym z nich, co jest wygodnym rozwiązaniem dla nowych i mniejszych sklepów internetowych.

Co zrobić, gdy mapa wyboru automatów paczkowych nie ładuje się w koszyku?

Brak wyświetlania mapy punktów odbioru wynika przeważnie z konfliktu bibliotek JavaScript w kodzie szablonu sklepu lub zablokowania skryptów zewnętrznych przez politykę bezpieczeństwa przeglądarki (Content Security Policy). Rozwiązanie wymaga inspekcji konsoli błędów przeglądarki, wyeliminowania kolidujących skryptów i poprawnego załadowania zasobów modułu wysyłkowego.

Czy można zablokować płatność przy odbiorze dla wybranych produktów lub metod dostawy?

Tak, silniki e-commerce pozwalają na definiowanie reguł warunkowych. Możliwe jest ograniczenie form płatności tak, aby opcja zapłaty przy odbiorze (pobranie) była niedostępna dla przesyłek do maszyn paczkowych lub dla produktów wykonywanych na indywidualne zamówienie klienta.

Bezpieczne i stabilne środowisko transakcyjne dla sprzedaży internetowej

Poprawna konfiguracja procesów płatności i metod dostawy decyduje o sprawności operacyjnej każdego sklepu internetowego. Eliminacja błędów technicznych na etapie finalizacji koszyka bezpośrednio zapobiega porzucaniu zakupów przez klientów oraz automatyzuje codzienną obsługę zamówień i generowanie dokumentów przewozowych. W przypadku trudności z integracją bramek transakcyjnych lub modułów kurierskich realizowane są kompleksowe prace wdrożeniowe, konfiguracja połączeń API oraz audyt poprawności całej ścieżki zakupowej.

22 378 48 09

Konfiguracja płatności i dostaw w nowym sklepie