Czym jest PrestaShop PL — i czego naprawdę szukasz pod tym hasłem

PrestaShop to otwarte oprogramowanie sklepu internetowego rozwijane przez PrestaShop SA z siedzibą we Francji. Rdzeń jest wydawany na licencji OSL 3.0, więc sama instalacja jest darmowa. Płacisz za wdrożenie, hosting, moduły i utrzymanie — nie za pobranie paczki. To rozróżnienie warto mieć z tyłu głowy od pierwszej minuty projektu, bo najczęstsze rozczarowanie brzmi: „myślałem, że PrestaShop jest darmowy”.

Druga rzecz organizacyjna: nie ma oficjalnego serwisu „prestashop.pl” prowadzonego przez wydawcę oprogramowania. Polska wersja to pakiet językowy i zestaw ustawień lokalizacyjnych dołączony do standardowej paczki z prestashop.com — tłumaczenie interfejsu, polskie statusy zamówień, formaty daty i waluty. Jeśli trafiłeś na stronę sugerującą, że jest oficjalnym polskim centrum pobierania, sprawdź, kto ją prowadzi, zanim wgrasz stamtąd pliki na serwer.

Trzecia rzecz: wersje. Realne gałęzie to 8.x (traktowana jako linia o dłuższym wsparciu) i 9.x. Status wsparcia konkretnej wersji sprawdzisz w dokumentacji PrestaShop dla deweloperów — zanotuj numer wersji, datę wydania i informację, czy gałąź jest jeszcze wspierana. Od tego zależy, czy moduły płatności i kurierów będą dostawać aktualizacje przez najbliższe dwa lata.

Co masz na myśli, wpisując „prestashop pl”	Gdzie szukać w tym artykule
Polska wersja językowa sklepu	Sekcja o lokalizacji: pakiet językowy, PLN, VAT, numeracja faktur
Polskie integracje: płatności i kurierzy	Sekcja o bramkach płatności: BLIK, Przelewy24, PayU, Autopay
Wsparcie i wdrożenie po polsku	Sekcja o organizacji projektu i pytaniach przed podpisaniem umowy

Jeśli szukasz szerszego kontekstu — co robimy przy wdrożeniach, migracjach i utrzymaniu — zajrzyj na stronę naszego huba o PrestaShop.

Polska lokalizacja w PrestaShop: co jest w paczce, a co ustawiasz ręcznie

Pakiet językowy instalujesz z back office w sekcji International > Localization. To dopiero początek, bo tłumaczenia frontu, back office i szablonów maili transakcyjnych ustawiasz osobno. Najczęstszy błąd przy starcie: sklep po polsku, a potwierdzenie zamówienia leci do klienta po angielsku. Sprawdź to, zanim wyślesz pierwszy mail z produkcji.

Waluta domyślna to PLN, format ceny z przecinkiem i spacją jako separatorem tysięcy. Zaokrąglanie przetestuj na dwóch przypadkach: produkt za 9,99 zł z rabatem 15% (9,99 × 0,85 = 8,4915) oraz koszyk z rabatem procentowym na całość. Sprawdź, czy zaokrąglenie idzie na pozycji, czy na sumie — w drugim przypadku suma pozycji może się nie zgodzić z kwotą do zapłaty o grosz, co potem wraca jako reklamacja.

VAT: stawki 23%, 8%, 5% i 0%, ceny brutto widoczne w katalogu i na fakturze. Zrób test zamówienia z dwiema stawkami (np. 5% i 23%) i porównaj koszyk z fakturą. Strefa czasowa Europe/Warsaw — przy serwerze ustawionym na UTC zamówienie złożone o 00:30 wpadnie z datą poprzedniego dnia, co psuje numerację faktur i raporty dzienne. Format adresu z kodem 00-000, waga w kilogramach (tak liczą kurierzy), jednostka miary zgodna z tym, co realnie sprzedajesz.

Numeracja faktur: prefiks (np. FV/2025/), ciągłość bez dziur, dane sprzedawcy, NIP i rachunek bankowy. Uwaga na styczeń — zmiana prefiksu zwykle zeruje licznik.

• ☐ Pakiet PL zainstalowany: front, back office, maile
• ☐ PLN jako waluta domyślna, format z przecinkiem
• ☐ Zaokrąglanie sprawdzone na 9,99 zł i na rabacie procentowym
• ☐ Stawki VAT 23/8/5/0 i ceny brutto w katalogu
• ☐ Strefa czasowa Europe/Warsaw
• ☐ Format adresu z kodem 00-000, waga w kg
• ☐ Numeracja faktur: prefiks, ciągłość, dane sprzedawcy
• ☐ NIP i rachunek bankowy na dokumencie

Polskie płatności: Przelewy24, PayU, BLIK, Autopay — co sprawdzić przed instalacją

BLIK nie jest osobnym modułem. To kanał wewnątrz bramki — Przelewy24, PayU albo Autopay. Konsekwencja praktyczna: nie szukasz „modułu BLIK” do PrestaShop, tylko włączasz kanał w panelu bramki i pilnujesz, żeby moduł przekazywał listę metod dynamicznie. Jeśli ma zaszyty na sztywno zestaw opcji, BLIK się nie pojawi, mimo że w panelu jest aktywny.

Zgodność sprawdź w trzech wymiarach naraz: wersja modułu ↔ PrestaShop 8.x/9.x ↔ PHP 8.1/8.2. Changelog modułu to pierwsze miejsce, w którym widać, czy wydawca testował go na Twojej wersji. Drugi sygnał: hook. Moduł korzystający z hooka paymentOptions jest pisany pod nowsze wersje; jeśli w kodzie widzisz stary hook payment, to najprawdopodobniej kod z czasów 1.6/1.7. Bywa, że działa, ale nie obsłuży nowego interfejsu wyboru metody. Punkt odniesienia: dokumentacja dla deweloperów PrestaShop.

Asynchroniczne potwierdzenia to najczęstsze źródło ręcznej pracy po starcie. Gdy webhook nie dojdzie, pieniądze są na koncie, a zamówienie siedzi w statusie „oczekiwanie na płatność”. Wykrywanie: raz dziennie porównaj raport z bramki z listą zamówień w tym statusie. Druga pułapka: zwroty i zwroty częściowe przez API bramki. Sprawdź, czy moduł je obsługuje, zanim włączysz sprzedaż — inaczej każdy zwrot robisz dwa razy: w panelu bramki i ręcznie w PrestaShop.

Zanim uruchomisz produkcję: test w sandboxie z 3DS/SCA, prowizja i czas księgowania na Twoim wolumenie, jeden test płatności i zwrotu end-to-end. Płatności wiążą się też z pomiarem — jeśli transakcje nie dochodzą do GA4, zajrzyj do tekstu o tym, dlaczego w GA4 brakuje transakcji ze sklepu PrestaShop.

Kurierzy i logistyka: InPost, DPD, DHL w polskim sklepie

Etykietę generuje sklep albo panel kuriera — wybór robisz raz i od niego zależy, ile pracy zostaje w back office. Poniżej konfiguracja, po której paczki wychodzą bez ręcznego kopiowania numerów przesyłek. Kolejność prac nad całością wdrożenia opisujemy w tekście o organizacji wdrożenia PrestaShop, terminach i kosztach.

• InPost ShipX API. W module podajesz organization_id i token z panelu ShipX. Zacznij od środowiska sandbox, potem przełącz na produkcję. Dla paczkomatów dochodzi Geowidget z mapą punktów — wymaga własnego klucza. Listy paczkomatów nie wklejaj statycznie do bazy, bo zmienia się co kilka tygodni. Etykieta PDF generuje się z poziomu zamówienia i powinna zapisywać się przy nim jako plik.
• DPD WebAPI i DHL24. W DPD potrzebujesz loginu, hasła i numeru master FID. W DHL24 — danych konta i numeru SAP. Oba API zwracają numer przesyłki i identyfikator wydruku. Te dwa pola muszą trafić do zamówienia i do maila z potwierdzeniem nadania. Jeśli pracownik wkleja numer ręcznie w pole „komentarz”, integracja nie jest domknięta.
• Pobranie (COD). Działa, gdy masz podpisaną umowę na pobranie i kwota nie przekracza limitu u operatora. Kurier odrzuci przesyłkę przy braku umowy, przy przekroczeniu limitu wartości i przy nadaniu poza obsługiwaną strefą. Paczkomat w standardzie pobrania nie obsługuje — sprawdź cennik InPost, zanim pokażesz tę opcję w koszyku.
• Mapowanie statusów. Zdarzenia z API („przyjęta”, „w drodze”, „doręczona”, „zwrot”) mapujesz na statusy zamówienia. Mail „zamówienie zrealizowane” ustaw dopiero na doręczenie. Jeden błąd w mapowaniu oznacza tysiące maili wysłanych o złej porze.
• Próg darmowej dostawy. Liczony tylko od wartości koszyka nie widzi wagi gabarytowej (30 kg, obwód powyżej 250 cm) ani liczby paczek — zapłacisz dwa razy za jedno zamówienie.

Stany zamówienia i ich identyfikatory opisuje dokumentacja deweloperska PrestaShop.

Zgodność i dokumenty: RODO, Omnibus, cookies, KSeF

Minimum prawne sprawdzisz w kilku miejscach sklepu i na kilku stronach. Nie chodzi o komplet dokumentów w szufladzie, ale o to, czy wdrożenie je faktycznie realizuje.

• Omnibus. Na karcie produktu, przy każdej obniżce, musi być najniższa cena z minimum 30 dni przed obniżką — zgodnie z wytycznymi UOKiK. W standardowym PrestaShop tego nie ma. Potrzebujesz modułu albo własnego hooka i tabeli historii cen zapisywanej przy każdej zmianie ceny. Pułapka: historia uruchomiona w dniu wdrożenia nie ma danych wstecz.
• RODO. Polityka prywatności, obowiązek informacyjny bezpośrednio przy formularzu (checkbox z linkiem, nie zaznaczony z góry), rejestr czynności przetwarzania. Do tego umowy powierzenia: hosting, dostawca mailingu, firma kurierska, biuro księgowe.
• Banner cookies. Żadna zgoda nie może być zaznaczona z góry. Osobna kategoria analityczna i osobna marketingowa — łączenie ich w jedno „akceptuję wszystko” jest najczęstszym błędem. Skrypt analityczny ładuj dopiero po zgodzie, inaczej banner jest deklaracją bez pokrycia.
• KSeF. Aktualny harmonogram sprawdzaj wyłącznie na stronach Ministerstwa Finansów (gov.pl) — terminy były przesuwane. Moduł faktur weryfikuj po trzech rzeczach: czy generuje XML w wymaganym formacie, czy obsługuje wysyłkę poza godzinami pracy systemu i czy prowadzi log wysyłek. Nie podajemy daty wdrożenia, bo za miesiąc może być inna.
• Regulamin. Wzorzec odstąpienia od umowy (14 dni) jako osobny załącznik oraz informacja o kosztach zwrotu. Jeśli poinformujesz klienta przed zakupem, koszt odesłania ponosi on. Jeśli nie — Ty.

Hosting i serwer pod PrestaShop w Polsce — parametry, nie slogany

Hosting porównuj po parametrach, nie po nazwie pakietu „Business” czy „E-commerce”. Poniżej wartości, które sprawdzisz w panelu i przez SSH.

• PHP 8.1/8.2. PrestaShop 8.x i 9.x wspierają te wersje. Sprawdzenie: php -v na serwerze lub wybór wersji per domena w panelu, a lista wspieranych gałęzi na php.net. Wymagania dla konkretnego wydania opisuje aktualizacja do PrestaShop 9.2 i wymagania PHP.
• Baza: MySQL 8.0 lub MariaDB 10.6+. Collation musi być spójne (utf8mb4) we wszystkich tabelach — mieszanka utf8 i utf8mb4 po migracji psuje polskie znaki i JOIN-y. Sprawdź też limit połączeń i wait_timeout.
• OPcache i cache obiektowy. OPcache z pamięcią 256 MB, do tego Redis lub Memcached jako cache obiektowy włączony w konfiguracji sklepu.
• HTTP/2, dysk NVMe. HTTP/1.1 przy 60–80 plikach na karcie produktu to dziś strata sekund.
• Punkt odniesienia: 5–10 tys. SKU. Minimum 2 vCPU i 4 GB RAM, baza na osobnym instancji. Na 1 vCPU i 2 GB panel działa, ale import 3 tys. produktów potrafi się wysypać.
• Lokalizacja w PL lub UE. Serwer poza EOG to dodatkowa podstawa prawna transferu — niepotrzebne ryzyko.
• Kopie dzienne z retencją 14–30 dni plus test odtworzenia raz na kwartał. Backup bez testu to nadzieja, nie zabezpieczenie.
• Pomiar TTFB i Core Web Vitals. Mierz tym samym narzędziem przed i po zmianie hostingu: minimum 10 pomiarów na ciepłym cache i mediana, nie pojedynczy wynik. Metryki polowe i laboratoryjne opisuje web.dev – Web Vitals.

Wsparcie i koszty: kiedy wystarczy dokumentacja, a kiedy potrzebny jest deweloper

Granicę da się wyznaczyć dość ostro. Wszystko, co robisz klikając w panelu, ogarniesz sam: instalacja, waluta, strefy podatkowe, języki, podstawowe metody płatności i dostawy z modułów dostępnych w Addons. Przy sensownej dokumentacji to kilka godzin pracy, głównie nad treściami, cennikami wysyłki i mailami transakcyjnymi.

Deweloper wchodzi wtedy, gdy pojawia się kod: moduł custom, migracja z innego sklepu, integracja z ERP lub systemem księgowym, nietypowe reguły rabatowe czy wysyłkowe. Nie dlatego, że „PrestaShop jest trudny”, tylko dlatego, że każda z tych rzeczy dotyka bazy danych albo API, a błąd w nich wychodzi dopiero przy realnym zamówieniu — często po dwóch tygodniach od startu.

Jak rozliczać? Proś o stawkę godzinową i szacunek godzin rozbity na etapy, nie o jedną cenę ryczałtem. Ryczałt bez rozbicia oznacza, że każda zmiana zakresu będzie negocjowana od zera, a Ty nie masz punktu odniesienia. Ustal też limit: co się dzieje, gdy szacunek zostanie przekroczony, kto płaci za nadgodziny i przy jakim progu dzwonicie do siebie. Stawki nie wklejam tu na sztywno, bo zależy m.in. od tego, czy praca idzie w godzinach biurowych, czy nocą przed premierą — poproś o nią wprost w wycenie i porównaj z liczbą godzin, nie z sumą na końcu.

SLA to nie „odpowiadamy szybko”. Potrzebujesz trzech liczb: czas reakcji (potwierdzenie zgłoszenia), czas rozwiązania dla błędów blokujących zamówienia i czas na drobne poprawki. Do tego kanały zgłoszeń (mail, telefon, ticket) i godziny pracy — czy zgłoszenie z soboty wchodzi do kolejki dopiero w poniedziałek. W utrzymaniu powinny być aktualizacje bezpieczeństwa, kopie zapasowe i monitoring dostępności; prace rozwojowe wycenia się osobno.

Praca bezpośrednio z deweloperem, bez pośrednika w postaci handlowca czy PM-a, skraca pętlę „zgłoszenie → diagnoza → poprawka”. Osoba, która pisała moduł, wie, gdzie szukać. Zamiast trzech maili z opisem problemu wystarczy jeden z numerem zamówienia. Jeśli rozważasz zmianę platformy, zobacz, jak wygląda migracja z PrestaShop do WooCommerce, a organizację całego projektu opisujemy przy okazji wdrożeń PrestaShop — terminów i kosztów.

Pułapki i szybki audyt: 30 minut, które oszczędzają tysiące

Zanim wyłączysz choćby jeden moduł na produkcji, zrób kopię i sprawdź, czy umiesz ją przywrócić. Poniższy audyt robi się w pół godziny i nie wymaga kontaktu z deweloperem.

• Moduły bez wsparcia PHP 8. W panelu idź do Moduły → Moduły i posortuj listę po dacie ostatniej aktualizacji. Wpis z 2019–2021 przy module płatności lub dostawy to sygnał alarmowy. Wejdź na serwer do katalogu modules/nazwa_modulu i otwórz config.xml — pole <compatibility> z wartością <max> pokazuje najwyższą wspieraną wersję PrestaShop. Do tego changelog i karta modułu w Addons. Brak jakiejkolwiek wzmianki o PHP 8 przy starym module zwykle znaczy, że nikt go nie testował. Struktura plików modułu jest opisana w dokumentacji deweloperskiej PrestaShop.
• Test na stagingu. Skopiuj bazę i katalog plików, podmień PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL w tabeli ps_configuration, wyłącz cache. Potem wyłączaj moduły po jednym i po każdym spróbuj złożyć zamówienie z płatnością w trybie testowym. Jeśli checkout pada dopiero po wyłączeniu modułu, to nie jest „niezależny” moduł, tylko element układanki.
• Zależności. Wyłączenie modułu płatności często zostawia pusty krok płatności, a modułu kuriera — brak metody dostawy, więc koszyk nie przejdzie dalej. Moduły rabatowe nadpisują reguły koszyka i potrafią zerować promocje.
• SEO techniczne. W Search Console → Indeksowanie → Strony sprawdź, czy w indeksie siedzą adresy koszyka z parametrem action=show, wyniki wyszukiwania i odsłony filtrów. Na stronie produktu i listingu zajrzyj w <head>: czy jest rel="canonical" i czy wskazuje na wersję bez parametrów. Brak canonicala przy filtrowanym listingu to proszenie się o duplikaty.

Jeśli planujesz skok na 9.x, zanim cokolwiek ruszysz, przejdź przez listę z tekstu PrestaShop 9.2 — co sprawdzić przed aktualizacją. Szerszy kontekst, łącznie z wariantami wdrożenia, znajdziesz w naszym wpisie o PrestaShop. Wynik audytu to lista modułów do wymiany i decyzja: aktualizujesz teraz czy po sezonie. Checklistę do odklikania znajdziesz na końcu artykułu.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Wersja PrestaShop i status wsparcia — Zapisz wersję i datę końca wsparcia danej gałęzi, zanim zaakceptujesz harmonogram wdrożenia.
• Wersja PHP na serwerze — Sprawdź, czy hosting oferuje PHP 8.1/8.2 i czy wszystkie moduły, których potrzebujesz, mają to potwierdzone w dokumentacji.
• Pakiet językowy PL — Zainstaluj w International > Localization osobno front, back office i szablony maili transakcyjnych — sam front to za mało.
• PLN, format ceny, zaokrąglanie — PLN jako waluta domyślna, cena z przecinkiem. Test: produkt za 9,99 zł plus rabat procentowy plus koszt wysyłki.
• VAT i ceny brutto — Sprawdź stawki 23%, 8%, 5% i 0%, oznaczenie cen brutto w katalogu oraz to, co trafia na fakturę.
• Strefa czasowa i formaty — Europe/Warsaw, adres z kodem 00-000, waga w kg, jednostka miary — sprawdź na jednym zamówieniu testowym.
• Numeracja faktur i dane sprzedawcy — Prefiks, ciągłość numeracji, NIP i rachunek bankowy. Wystaw dwie faktury pod rząd i sprawdź, czy numeracja nie ma luk.
• Kompatybilność modułu płatności — Wersja modułu vs PrestaShop 8.x/9.x vs PHP 8.1/8.2 — potwierdź w changelogu przed instalacją, nie po.
• BLIK jako kanał w bramce — Sprawdź w panelu operatora, czy BLIK jest włączony i czy moduł przekazuje informację o metodzie do zamówienia.
• Webhooki i statusy zamówień — Zasymuluj brak potwierdzenia z bramki. Ustal, kto i jak często sprawdza zamówienia „oczekujące na płatność”.
• Zwroty i częściowe zwroty — Przed włączeniem sprzedaży sprawdź, czy moduł obsługuje zwroty przez API bramki — także częściowe.
• 3DS/SCA, prowizje, czas księgowania — Zbierz stawki i terminy na piśmie, wykonaj test w sandboxie i jedną transakcję produkcyjną na symboliczną kwotę.
• Integracje kurierskie — InPost ShipX, DPD WebAPI, DHL24: etykieta PDF i numer przesyłki muszą trafiać do zamówienia bez kopiowania.
• Pomiar w GA4 — Po uruchomieniu płatności sprawdź, czy transakcje trafiają do GA4 — inaczej nie ocenisz, która bramka zarabia.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• PrestaShop – dokumentacja dla deweloperów
• web.dev – Core Web Vitals