Integracja InPost z PrestaShop 9 rzadko wywala się na samym API. Znacznie częściej problemem jest brak tokenu, nieuzupełnione dane organizacji, nieprzygotowany hosting albo decyzje podejmowane dopiero w dniu wdrożenia. Poniżej znajdziesz część organizacyjną: kolejność działań, listę kontrolną i błędy, które generują najwięcej straconych godzin. Kontekst wersji, wybór wariantu integracji i samą konfigurację modułu opisujemy w pozostałych sekcjach artykułu. Punktem wyjścia dla wszystkich tematów PrestaShop jest nasz hub PrestaShop.
PrestaShop 9 to nie kosmetyczna zmiana numerka w stopce. To inny stos technologiczny: PHP 8.1–8.3, MySQL 8.0 lub MariaDB 10.6+, architektura oparta na Symfony i przebudowany panel administracyjny. Moduł, który działał w 1.6 czy 1.7, w PS9 najczęściej nie wystartuje — nie dlatego, że InPost coś zmienił, ale dlatego, że zmienił się rdzeń.
Zanim cokolwiek kupisz, sprawdź trzy rzeczy:
override/ i pliki .tpl w stylu Smarty 3 to sygnał, że moduł hakuje rdzeń. Każdy override to potencjalny konflikt przy następnej aktualizacji sklepu.Objawy niezgodności są powtarzalne: biały ekran albo HTTP 500 dokładnie na kroku dostawy w checkoucie, a w logach PHP wpisy typu Call to undefined method lub Too few arguments to function. Nie szukaj wtedy problemu w tokenie InPost — błąd jest w kodzie modułu. Zanim zgłosisz to do supportu, włącz pełne logowanie błędów i zrób zrzut treści wyjątku, bo samo „nie działa” wydłuża wymianę maili o kilka dni.
Przed wdrożeniem na produkcji postaw kopię sklepu na subdomenie testowej z identyczną wersją PHP i MySQL. Argument „u mnie na XAMPP działa” nic nie wnosi. Pozostałe tematy PrestaShop, w tym konfigurację modułu i wybór wariantu integracji, zbieramy w hubie PrestaShop. Wymagania techniczne samej platformy opisuje dokumentacja dla deweloperów PrestaShop.
Nie ma jednego właściwego sposobu na InPost w PS9. Są trzy drogi i wybór zależy od skali sklepu, nie od mody.
1. Oficjalny moduł InPost oparty na ShipX. Sensowny start dla sklepów do kilkudziesięciu paczek dziennie. Dostajesz gotowe metody dostawy (Paczkomaty 24/7, kurier, nadanie w punkcie), generowanie etykiet i podstawowe statusy przesyłek. Koszt: trzeba skonfigurować metody dostawy, gabaryty i cenniki zgodne z twoją umową z InPost. Typowa pułapka: domyślne gabaryty są za małe dla twoich produktów i wychodzi to dopiero przy pierwszej reklamacji.
2. Bezpośrednie ShipX API (REST + token). Wybierasz to, gdy potrzebujesz własnej logiki: masowego generowania etykiet, mapowania statusów przesyłki na statusy zamówienia, integracji z ERP lub WMS, automatycznego nadawania po zmianie statusu płatności. Więcej pracy na starcie, ale brak sufitu, gdy proces się rozrośnie. Osobno opisujemy, jak pogodzić to z wydajnością sklepu — zobacz Paczkomaty w PrestaShop: wdrożenie bez utraty szybkości.
3. Własny moduł pod PS9. Piszemy go tam, gdzie kolejna płatna wtyczka nie wystarczy: gabaryty liczone automatycznie z wymiarów produktów w koszyku, wiele magazynów z różnymi adresami nadania, indywidualne reguły darmowej dostawy zależne od wagi i strefy. To również jedyna sensowna droga, gdy masz nietypowe produkty i żaden gotowy moduł nie potrafi wyliczyć wymiaru przesyłki.
Decyzję podejmij przed rozmową z wykonawcą — inaczej kupisz wtyczkę, którą za pół roku i tak trzeba będzie zastąpić.
| Paczki/dzień | Kanały sprzedaży | Automatyzacja statusów | Rekomendacja |
|---|---|---|---|
| do ok. 30 | jeden sklep | niepotrzebna | oficjalny moduł InPost (ShipX) |
| 30–150 | sklep + marketplace | podstawowa, ręczne korekty | oficjalny moduł plus własne mapowanie statusów |
| 150+ | kilka kanałów | pełna, integracja z ERP | bezpośrednie ShipX API |
| dowolna | wiele magazynów, nietypowe gabaryty | pełna | własny moduł pisany pod PS9 |
Większość opóźnień nie wynika z kodu, tylko z braku dostępów. Zanim ktokolwiek dotknie modułu, powinieneś mieć konto biznesowe InPost (nie prywatne), wygenerowany token API i uzupełnione dane organizacji.
| Wymaganie | Jak sprawdzić | Co się dzieje, gdy brakuje |
|---|---|---|
| PHP 8.1–8.3 | phpinfo() lub panel hostingu | moduł nie startuje, biały ekran |
| MySQL 8.0 / MariaDB 10.6+ | SELECT VERSION() w bazie | problemy z zapytaniami i migracjami tabel |
| cURL z TLS 1.2+ | curl --version oraz test połączenia z API | brak komunikacji z ShipX, błąd połączenia |
| Wychodzące połączenia na port 443 | test wykonany z serwera, nie z komputera | etykiety nie generują się wcale |
| memory_limit min. 256 MB | phpinfo() | przerwane generowanie etykiet przy większej liczbie zamówień |
| Poprawny czas systemowy (NTP) | polecenie date w konsoli serwera | losowe błędy autoryzacji tokenu |
Kolejność działań ma znaczenie, bo moduł InPost zapisuje dane dopiero przy pierwszym zamówieniu — braki wychodzą po fakcie, już po opłaceniu zamówienia przez klienta.
displayCarrierExtraContent (miejsce na wybór paczkomatu pod listą przewoźników), actionCarrierProcess oraz actionValidateOrder (zapis punktu i weryfikacja przy składaniu zamówienia). Jeśli displayCarrierExtraContent nie jest zarejestrowany, dostawa się pokaże, ale klient nie wskaże punktu. Po każdej zmianie wyczyść cache (Zaawansowane → Wydajność).Punkt wyjścia dla pozostałych tematów: wdrożenia i konfiguracja PrestaShop. Nazwy hooków i strukturę modułów sprawdzisz też w dokumentacji dla deweloperów PrestaShop.
| Metoda w sklepie | Typ przewoźnika | Reguła cennika | Uwaga wdrożeniowa |
|---|---|---|---|
| Paczkomat 24/7 | InPost Paczkomat | stawka stała lub progi kwotowe | wymaga wyboru punktu w checkoucie |
| Kurier | InPost Kurier | progi wagowe + strefa PL | wymaga poprawnego adresu i telefonu |
| Kurier w weekend | InPost Kurier weekend | osobna stawka | włącz tylko, jeśli realnie nadajesz w piątek |
| Paczkomat za pobraniem | InPost Paczkomat + płatność COD | osobna stawka i limit kwotowy | limit musi być zgodny z limitem InPost |
Geowidget to skrypt JS plus kontener div, w który wstrzykuje się mapa punktów. Najczęstszy błąd to wklejenie go do szablonu globalnego (sekcja head, header.tpl), przez co ładuje się na stronie głównej, w kategorii i na karcie produktu — czyli tam, gdzie nikt paczkomatu nie wybiera. Koszt: dodatkowa domena zewnętrzna (DNS i TLS), sam skrypt, lista punktów oraz listenery mapy obciążające wątek główny.
Lazy loading. Widget inicjalizuj dopiero w kroku dostawy: po kliknięciu „Wybierz paczkomat” albo gdy kontener wejdzie w viewport (Intersection Observer). Sam skrypt wczytuj dynamicznie, nie w head. Zysku nie szacuj — mierz w PageSpeed Insights oraz w Search Console → Core Web Vitals, na realnym adresie koszyka i produktu.
Alternatywa dla ciężkiego widgetu. Pobierz listę punktów z API InPost raz na dobę, zapisz lokalnie (JSON w cache lub bazie) i pokaż własny modal z wyszukiwaniem po kodzie pocztowym lub mieście. Na stronie ładujesz wtedy kilkanaście–kilkadziesiąt kB JS. Trade-off: sam pilnujesz aktualności punktów, w tym czasowo zamkniętych.
Zapamiętywanie wyboru. Wybrany paczkomat zapisz w sesji i przy koszyku (id_cart). Klient wraca z płatności — punkt jest już ustawiony i nie wybiera go drugi raz. Przy zmianie zawartości koszyka waliduj, czy punkt nadal przyjmie paczkę w danym gabarycie. Progi wydajności znajdziesz w Core Web Vitals w Google Search Central oraz w web.dev – Web Vitals. Rozwinięcie tematu wydajności: paczkomaty w PrestaShop bez utraty szybkości.
| Metryka | Cel dla 75. percentyla | Co najczęściej zawala wynik |
|---|---|---|
| LCP | ≤ 2,5 s | widget i mapa ładowane na każdej stronie sklepu |
| INP | ≤ 200 ms | listenery mapy, ciężki modal bez optymalizacji |
| CLS | ≤ 0,1 | kontener bez zarezerwowanej wysokości, mapa doskakująca po wczytaniu |
Etykiety. Z listy zamówień w panelu PrestaShop generujesz etykietę PDF jednym kliknięciem, także zbiorczo. Plik zapisuje się po stronie serwera w katalogu wskazanym w konfiguracji modułu — sprawdź, gdzie dokładnie w Twojej wersji, i upewnij się, że katalog ma prawa zapisu oraz wchodzi do backupu. Etykiety pobierane ręcznie z Panelu Menedżera Paczek znikają z procesu w dniu, w którym zamówienia obsługuje ktoś inny.
Webhooki. Powiadomienia z ShipX mapuj na statusy zamówienia. Zasady: idempotencja (to samo zdarzenie może przyjść dwa razy), log każdego wywołania i odpowiedź w około sekundę — wysyłkę maila czy generowanie faktury przenieś do kolejki. Webhook blokujący się na 10 s kończy się powtórzeniami i bałaganem w statusach.
Tracking. Numer przesyłki zapisz przy zamówieniu i wstaw do szablonu maila ze statusem wysyłki oraz do szablonu zamówienia klienta w motywie (order-detail.twig). Kliknij go na telefonie przed wdrożeniem — bez tego klienci dzwonią na infolinię.
Zwroty. Etykieta zwrotna i paczkomat zwrotny domykają proces. Pamiętaj o obowiązkach informacyjnych z ustawy o prawach konsumenta: poinformowanie o 14 dniach na odstąpienie, wzór formularza i wskazanie, kto ponosi koszt zwrotu. Brak informacji o koszcie zwrotu oznacza, że nie przerzucisz go na konsumenta. Wytyczne UOKiK warto raz przeczytać i wdrożyć w regulaminie.
Sytuacje wyjątkowe. Brak miejsca w paczkomacie: InPost przekierowuje przesyłkę do innego punktu — klient musi dostać o tym maila, inaczej uzna, że paczka zniknęła. Zwrot do nadawcy: ustal, czy wysyłasz ponownie, kto płaci za drugą wysyłkę i jak wygląda zwrot pieniędzy. Jeśli wolisz oddać ten zakres na zewnątrz, sprawdź, jak organizujemy wdrożenia PrestaShop i ile to kosztuje.
| Zdarzenie po stronie InPost | Status w PrestaShop | Akcja po stronie sklepu |
|---|---|---|
| Przesyłka utworzona | W realizacji | zapis pliku etykiety, brak maila do klienta |
| Odebrana od nadawcy | Wysłane | mail z numerem trackingowym |
| Gotowa do odbioru | Do odbioru w paczkomacie | mail lub SMS z kodem odbioru |
| Dostarczona | Zrealizowane | zamknięcie zamówienia |
| Zwrot do nadawcy | Zwrócone do sklepu | kontakt z klientem i decyzja o ponownej wysyłce |
Te pięć pułapek odpowiada za większość straconych godzin przy wdrożeniu InPost w PrestaShop 9. Każda ma konkretny objaw i miejsce, w którym się ją diagnozuje — jeszcze przed produkcją.
/override/ nadpisujące klasy core (Cart.php, Order.php, Carrier.php). Sprawdź listę override'ów w panelu (Zaawansowane → Informacje) oraz zgodność modułu w config.xml. Moduł bez wersji na PS9 wymienia się na nowy, nie „łata” na produkcji. Cykl życia modułów opisuje dokumentacja dla deweloperów PrestaShop.Deprecated: Creation of dynamic property oraz komunikaty o przekazaniu null do parametru, który null nie dopuszcza. Szukaj w var/logs/ i logach PHP-FPM. Rozróżnienie jest proste: Deprecated i Warning nie zatrzymują wykonania, ale przy display_errors=On potrafią rozbić nagłówki i odpowiedź JSON; Fatal error i Uncaught Error to 500 i pusta strona. Deprecations zerujesz przed produkcją, bo PS9 chodzi na PHP 8.1+.var/cache/prod i smarty/compile, 4) na końcu cache CDN i przeglądarki. Odwrotna kolejność to klasyczne „zmiany nie widać” i pół dnia debugowania widma.slow_query_log. Listę punktów cache'uj na 15–60 minut i pobieraj dopiero po wybraniu metody — praktykę opisujemy w Paczkomaty w PrestaShop: wdrożenie bez utraty szybkości.| Pułapka | Objaw | Gdzie diagnozować |
|---|---|---|
| Override'y z PS 1.7 | 500 po aktualizacji, błędy koszyka | katalog /override/, Zaawansowane → Informacje, config.xml modułu |
| Deprecations PHP 8.1+ | Zapisy Deprecated/Warning w logach, rzadziej 500 | var/logs/, logi PHP-FPM, error_log |
| Cache i kompilacja szablonów | Zmiany nie widać, stary wygląd kroku dostawy | Zaawansowane → Wydajność, var/cache/prod |
| Zapytania N+1 w kroku dostawy | TTFB 1,5–3 s przy renderowaniu listy punktów | profiler, slow_query_log, licznik zapytań |
| Błędy API bez obsługi | Pusta lista punktów albo 500 dla klienta | logi modułu, odpowiedzi ShipX (401, timeout) |
Testy akceptacyjne to nie „przeklikanie” sklepu. To zestaw scenariuszy, po których pierwsze realne zamówienie przechodzi bez telefonu do klienta. Całość robisz na stagingu: kopia plików i bazy, przechwycone maile (MailHog albo skrzynka testowa), osobny token InPost lub sandbox ShipX.
Minimum to pięć scenariuszy: paczkomat, kurier, pobranie, zwrot i zamówienie z produktem bez wagi. Ostatni przypadek wywraca najwięcej wdrożeń — moduł podstawia domyślnie 0 kg, przez co metoda dostawy znika albo cena jest zaniżona. Ustaw wagę domyślną w katalogu albo wymuś uzupełnienie pola przy produkcie.
Po przejściu scenariuszy sprawdź komunikację: mail potwierdzający zamówienie, mail „wysłano” z numerem trackingowym, klikalny link do śledzenia oraz zgodność statusu po obu stronach — w koncie klienta (Moje zamówienia) i w panelu sprzedawcy. Przetestuj też ścieżki błędów: wygasły token, odłączony webhook, brak odpowiedzi API.
Wydajność mierz przed integracją i po niej, na tym samym środowisku. Interesuje cię krok dostawy, nie strona główna. Progi wg Core Web Vitals: LCP ≤ 2,5 s, INP ≤ 200 ms. Jeśli przed integracją krok dostawy miał LCP 1,8 s i 12 zapytań, a po ma 3,4 s i 60 zapytań — nie wdrażasz, tylko naprawiasz. Wyniki zapisz, żeby mieć punkt odniesienia po kolejnych aktualizacjach.
Nie testuj na produkcji „na chwilę”. Zamówienie testowe zostaje w bazie, generuje prawdziwą etykietę i miesza w statystykach oraz w rozliczeniach z InPost. Jeśli nie masz stagingu, potraktuj jego przygotowanie jako część projektu — to standardowy element wdrożenia PrestaShop dla firmy.
| Scenariusz | Co sprawdzić | Oczekiwany rezultat |
|---|---|---|
| Paczkomat | Wybór punktu, waga i gabaryt, etykieta | Etykieta generuje się, tracking wraca do zamówienia |
| Kurier | Adres, godzina dostawy, sposób nadania | Zamówienie z poprawną metodą i etykietą kurierską |
| Pobranie (COD) | Kwota pobrania zgodna z kwotą zamówienia | Status płatności i przesyłki spójne po obu stronach |
| Zwrot | Etykieta zwrotna, statusy, mail do klienta | Zwrot widoczny w panelu i w historii zamówienia klienta |
| Produkt bez wagi | Waga 0 kg i dostępność metody dostawy | Metoda nie znika albo pojawia się jasny komunikat, waga uzupełniona |
Nie ma jednej ceny wdrożenia InPost w PrestaShop 9, bo zakres różni się kilkukrotnie. Poniżej widełki w godzinach — po audycie zwykle się zawężają. Godziny mnożysz przez stawkę wykonawcy, więc dwie oferty z identycznym zakresem potrafią różnić się o połowę.
Skąd bierze się różnica w tabeli: oficjalny moduł InPost konfiguruje się kilkoma ustawieniami (klucze API, metoda dostawy, mapa punktów) i to zwykle 6–12 godzin z testami. Moduł własny lub mocno dostosowany oznacza mapowanie statusów zamówień na statusy przesyłek, dodatkowe pola w zamówieniu, walidację kodu punktu i często integrację z ERP — stąd 40–120 godzin.
Koszt podnoszą cztery rzeczy. Automatyzacja etykiet i drukarki, działająca bez otwierania panelu InPost. Obsługa wielu magazynów z regułami przydziału. Niestandardowe reguły dostawy (darmowa dostawa od kwoty tylko dla paczkomatów, wykluczenia produktów ponadgabarytowych). I przenoszenie sklepu na nową wersję — to osobny temat, opisany w migracji sklepu PrestaShop.
Po starcie wdrożenie się nie kończy. W zakres opieki warto wpisać: monitorowanie webhooków (czy przychodzą, jakie mają opóźnienia, czy retry działa), aktualizacje PrestaShop 9 i modułu InPost, reagowanie na zmiany w API InPost (nowe wersje endpointów, zmiany w autoryzacji tokenem, limity zapytań), backup i plan wycofania przed każdą aktualizacją. Ustal SLA na piśmie: czas reakcji na zgłoszenie zwykłe (np. 1 dzień roboczy) i krytyczne (np. 4 h), kto odbiera zgłoszenia i co jest poza zakresem. Orientacyjne widełki i organizację wyceniamy w cenie wdrożenia PrestaShop w Szczecinie.
| Zakres | Orientacyjnie godzin | Co podnosi zakres |
|---|---|---|
| Oficjalny moduł InPost: konfiguracja, metody dostawy, testy | 6–12 h | nietypowe reguły dostawy, kilka stref wysyłki |
| Moduł własny/dostosowany: mapowanie statusów, pola zamówienia, ERP | 40–120 h | integracja ERP, WMS, faktury, walidacje |
| Automatyzacja etykiet i drukarki | 8–16 h | kilka formatów etykiet, oznaczenia produktów |
| Wiele magazynów | 10–30 h | reguły przydziału, osobne umowy z InPost |
| Migracja z innej platformy | osobny projekt | liczba produktów, klientów, historii zamówień |
Wgranie do PrestaShop 9 modułu pisanego pod 1.6 lub 1.7, bo „kiedyś działał”. Stara architektura i pliki .tpl w stylu Smarty 3 nie mają prawa wystartować na Symfony.
Jak wykryć: Biały ekran lub błąd 500 dokładnie na kroku dostawy w checkoutcie. W logach PHP wpisy typu „Call to undefined method” albo błędy ładowania szablonu.
Jak naprawić: Przed zakupem sprawdź deklarację kompatybilności z PS9 i datę ostatniej aktualizacji modułu. Jeśli w paczce modułu widzisz katalog override i pliki .tpl, traktuj to jako sygnał ostrzegawczy. Niezgodny moduł wymień, a nie „latasz” na produkcji.
Mylenie tokenu sandbox z tokenem produkcyjnym ShipX. Efekt: testowe zamówienia tworzą prawdziwe przesyłki albo integracja zwraca 401.
Jak wykryć: Pierwsze zlecenie testowe pojawia się w prawdziwym Panelu Menedżera Paczek albo moduł nie łączy się z API mimo poprawnie wklejonego tokenu.
Jak naprawić: Trzymaj dwa osobne tokeny i dwa osobne wpisy konfiguracji. Przełączanie na produkcję rób świadomie, jako ostatni krok, po zamówieniu testowym na sandboxie.
Brak wpisanej wagi i wymiarów w katalogu produktów. System nie zgaduje — podstawia gabaryt domyślny.
Jak wykryć: Porównaj cenę etykiety z kwotą, której się spodziewałeś. Jeśli przy lekkich produktach wychodzi wyższa, winny jest gabaryt domyślny.
Jak naprawić: Uzupełnij wagę i wymiary dla produktów o największym udziale w sprzedaży i ustaw świadomie gabaryt domyślny jako fallback dla reszty. Sprawdź, czy najcięższy produkt mieści się w obsługiwanych gabarytach.
Przygotowanie konta, tokenu i uprawnień dopiero w dniu wdrożenia. Wtedy okazuje się, że brakuje dostępu do panelu, a serwer nie jest na whiteliście.
Jak wykryć: Wdrożenie stoi, bo nikt nie ma uprawnień menedżera, a połączenia wychodzące z serwera są odrzucane.
Jak naprawić: Zrób to z wyprzedzeniem: dostęp do Panelu Menedżera Paczek, wygenerowany token, potwierdzone dane organizacji i dodane IP serwera. To najczęstsze źródło opóźnień.
Jedna metoda dostawy InPost dla wszystkiego, zamiast osobnych metod dla Paczkomatu, Kuriera, Kuriera w weekend i przesyłki za pobraniem.
Jak wykryć: Klient wybiera Paczkomat, a przy płatności za pobraniem nie ma jasnej reguły, czy i do jakiej kwoty jest ona dostępna.
Jak naprawić: Przyjmij zasadę: jedna metoda = jedna reguła cennika i jedna reguła płatności. Dopiero wtedy da się sensownie powiązać COD z limitem kwotowym InPost.
Testowanie bezpośrednio na produkcji, bez zamówienia testowego i bez planu powrotu do poprzedniej konfiguracji.
Jak wykryć: Pierwsza realna paczka wychodzi z błędnym adresem nadawcy lub bez etykiety, a nikt nie wie, jak cofnąć zmiany.
Jak naprawić: Zrób zamówienie testowe end-to-end: etykieta, zmiana statusu, e-mail do klienta. Zapisz, jak wycofać konfigurację, jeśli po przełączeniu tokenu coś się wysypie.
Wdrożenie InPost w PrestaShop 9 wygrywa się na przygotowaniu, nie na samym kliknięciu „instaluj”. Konto biznesowe, dwa osobne tokeny (sandbox i produkcja), potwierdzone dane organizacji, zgodny hosting i przemyślana mapa metod dostawy — to sześć rzeczy, które decydują o tym, czy wdrożenie zajmie dzień, czy dwa tygodnie. Moduł niezgodny z PS9 nie naprawi się sam, a brak wagi w katalogu cicho zawyży koszty wysyłki. Zacznij od listy kontrolnej powyżej i przejdź ją w całości, zanim przełączysz token na produkcyjny.
W większości przypadków nie. PrestaShop 9 stoi na nowej architekturze Symfony i przebudowanym panelu administracyjnym, a moduły z 1.6 i 1.7 opierały się na innych mechanizmach. Objaw to biały ekran lub 500 na kroku dostawy oraz błędy „Call to undefined method” w logach PHP.
Token generuje się w Panelu Menedżera Paczek InPost. Dokładna ścieżka kliknięcia zmienia się między wersjami panelu, dlatego potwierdź ją w aktualnej dokumentacji InPost zamiast opierać się na starym poradniku z internetu. Token zapisz poza repozytorium — w menedżerze haseł lub zmiennych środowiskowych.
Innymi adresami endpointów i innym tokenem. Sandbox służy do testów — zlecenia nie trafiają do realnej sieci logistycznej. Jeśli pomylisz tokeny, pierwsze testowe zamówienie utworzy prawdziwą przesyłkę, którą trzeba będzie anulować.
Moduł nie zgaduje — podstawi gabaryt domyślny, który ustawisz w konfiguracji. Zwykle oznacza to zawyżony koszt nadania przy lekkich produktach albo błąd przy bardzo ciężkich. Dlatego ustaw gabaryt domyślny świadomie i uzupełnij dane dla produktów o największym udziale w sprzedaży.
Tyle, ile realnie oferujesz, ale każda jako osobna metoda: Paczkomat, Kurier, Kurier w weekend, Paczkomat za pobraniem. Jedna metoda to jedna reguła cennika i jedna reguła płatności. Wrzucenie wszystkiego do jednej metody kończy się tym, że pobranie jest dostępne tam, gdzie nie powinno być.
Sprawdź wersję PHP (8.1–8.3), wersję bazy (MySQL 8 lub MariaDB 10.6+), dostępność rozszerzenia cURL z TLS 1.2+ i brak blokad na połączenia wychodzące po porcie 443. Najlepiej zweryfikować to na kopii sklepu, zanim cokolwiek zmienisz na produkcji.
Nie zakładaj tego z góry. InPost ma limit kwotowy dla przesyłek za pobraniem, a jego wysokość i warunki potrafią się zmieniać. Sprawdź aktualny regulamin i powiąż metodę COD z konkretną metodą dostawy oraz regułą kwotową w PrestaShop.
Jeśli wolisz, żeby ktoś przejął konfigurację i sprawdził środowisko przed wdrożeniem, napisz do nas — powiemy wprost, co da się zrobić na Twoim hostingu, a co wymaga zmiany. Punktem wyjścia dla pozostałych tematów PrestaShop jest nasz hub PrestaShop.