PrestaShop Checkout: proces, moduł ps_checkout i najlepsze alternatywy

Czym jest PrestaShop Checkout?

Jeśli kiedykolwiek wyszukiwałeś frazę "prestashop checkout", prawdopodobnie zauważyłeś, że termin ten oznacza dwie zupełnie różne rzeczy w zależności od kontekstu. Może on oznaczać proces realizacji zamówienia wbudowany w każdy sklep PrestaShop — wieloetapowy przepływ, przez który przechodzą klienci, aby sfinalizować zakup — lub może odnosić się do modułu PrestaShop Checkout (ps_checkout), konkretnego rozwiązania płatniczego opracowanego przez PrestaShop SA we współpracy z PayPal.

Ten artykuł obejmuje oba zagadnienia. Przeprowadzimy Cię przez sposób działania domyślnego procesu realizacji zamówienia PrestaShop, wyjaśnimy, co faktycznie robi (i czego nie robi) moduł ps_checkout, przyjrzymy się opcjom personalizacji, porównamy najpopularniejsze alternatywy oraz omówimy bezpieczeństwo checkoutu w PrestaShop, zgodność z PCI i sposoby mierzenia wydajności procesu zakupowego — abyś mógł podjąć świadomą decyzję dla swojego sklepu.

Jak działa proces realizacji zamówienia w PrestaShop

Domyślny wieloetapowy przepływ

Każdy sklep PrestaShop jest wyposażony we wbudowany przepływ realizacji zamówienia. Jest to wieloetapowy proces rozłożony na oddzielne ładowania stron. Klient przechodzi przez pięć odrębnych etapów:

1. Przegląd koszyka — klient sprawdza produkty, ilości i sumy przed kontynuowaniem
2. Dane osobowe — logowanie, tworzenie konta lub zakupy jako gość
3. Adres — wprowadzenie lub wybór adresu dostawy i adresu na fakturę
4. Dostawa — wybór przewoźnika na podstawie adresu dostawy oraz wagi/wymiarów koszyka
5. Płatność — wybór metody płatności i potwierdzenie zamówienia

Po dokonaniu płatności klient trafia na stronę potwierdzenia. To jest podstawowe doświadczenie zakupowe, które każdy szablon musi implementować i stanowi fundament, na którym budowane są wszystkie moduły płatności, moduły wysyłki i personalizacje procesu zamówienia.

PrestaShop 1.7 Checkout vs. PrestaShop 8/9 Checkout

Chociaż ogólny przepływ realizacji zamówienia pozostał spójny w różnych wersjach, istnieją istotne różnice między wersją 1.7 a nowoczesnymi wydaniami 8.x/9.x:

• Architektura szablonu — PrestaShop 1.7 wprowadził szablon Classic z mocno opartym na JavaScript procesem zakupowym wykorzystującym AJAX do walidacji każdego kroku. PrestaShop 8 i 9 kontynuują ten wzorzec, ale z opcją szablonu Hummingbird, który zastępuje jQuery bardziej nowoczesnym stosem frontendowym.
• Zmiany hooków płatności — W wersji 1.7 hook paymentOptions zastąpił starsze hooki displayPayment i displayPaymentEU z wersji 1.6. PrestaShop 8 i 9 wymuszają to — starsze hooki płatności już nie działają, więc każdy moduł nadal używający displayPayment nie pojawi się w procesie zakupowym.
• Migracja na Symfony — PrestaShop 8 przeniósł więcej elementów back office na Symfony, a wersja 9 kontynuuje tę migrację. Kontroler front-office procesu zakupowego (OrderController) nadal działa na starszym frameworku, ale strony zarządzania zamówieniami w back office są już oparte na Symfony.
• Nagłówki bezpieczeństwa — PrestaShop 8+ jest dostarczany z bardziej restrykcyjnymi domyślnymi nagłówkami Content Security Policy, które mogą blokować zewnętrzny JavaScript od dostawców płatności. Jest to częsta przyczyna problemów z "pustym formularzem płatności" po aktualizacji.
• Wymagania dotyczące wersji PHP — PrestaShop 9 wymaga PHP 8.1+, co oznacza, że moduły płatności używające przestarzałych funkcji PHP mogą przestać działać podczas aktualizacji.

Kontroler procesu zamówienia: OrderController

Pod maską proces zakupowy jest obsługiwany przez klasę OrderController (znajdującą się w controllers/front/OrderController.php). Ten kontroler orkiestruje cały przepływ — ładuje koszyk, waliduje każdy krok, uruchamia hooki i renderuje szablon procesu zamówienia.

Kluczowe metody, o których warto wiedzieć podczas debugowania lub programowania:

• initContent() — konfiguruje proces zamówienia, ładuje podsumowanie koszyka i określa, który krok wyświetlić
• checkoutProcess — obiekt CheckoutProcess, który przechowuje łańcuch kroków zamówienia (dane osobowe, adres, dostawa, płatność)
• getCheckoutSession() — zwraca dane sesji śledzące, które kroki zostały ukończone

Każdy krok jest zaimplementowany jako oddzielna klasa (np. CheckoutAddressesStep, CheckoutDeliveryStep, CheckoutPaymentStep), która dziedziczy po AbstractCheckoutStep. Ta modułowa architektura oznacza, że moduły mogą nadpisywać lub rozszerzać poszczególne kroki bez konieczności zastępowania całego przepływu zamówienia.

Co dzieje się na każdym etapie

Za każdym krokiem PrestaShop uruchamia logikę walidacji i odpala hooki, których moduły mogą używać do rozszerzania procesu:

• Walidacja adresu — PrestaShop sprawdza wymagane pola, waliduje kombinację kraj/region i weryfikuje, czy adres spełnia skonfigurowany format. Reguły podatkowe są przeliczane na podstawie kraju dostawy.
• Wybór przewoźnika — dostępni przewoźnicy są filtrowani według strefy adresu dostawy, wagi koszyka, wymiarów produktów oraz wszelkich skonfigurowanych ograniczeń przewoźników. Koszty wysyłki są obliczane w czasie rzeczywistym. Hook actionCarrierProcess pozwala modułom interweniować na tym etapie.
• Renderowanie płatności — każdy aktywny moduł płatności rejestruje się poprzez hook paymentOptions. PrestaShop renderuje dostępne metody płatności w kolejności skonfigurowanej w back office.
• Walidacja zamówienia — gdy klient potwierdzi, PrestaShop waliduje całe zamówienie poprzez actionValidateOrder, przetwarza płatność, zmniejsza stan magazynowy, wysyła e-maile potwierdzające i tworzy rekord zamówienia.

Ta oparta na hookach architektura jest tym, co czyni proces zamówienia tak rozszerzalnym — ale oznacza również, że źle napisane moduły mogą ze sobą kolidować, powodując błędy, które sprzedawcy często mają trudności ze zdiagnozowaniem.

Wydajność PrestaShop Checkout: co powoduje spowolnienie

Wolny proces zakupowy bezpośrednio wpływa na konwersje. Każda dodatkowa sekunda ładowania zwiększa szansę, że klient porzuci koszyk. Najczęstsze wąskie gardła wydajności to:

• Zbyt wiele modułów podpiętych pod checkout — każdy moduł zarejestrowany na hookach procesu zamówienia (displayPayment, displayBeforeCarrier, actionCarrierProcess itp.) dodaje czas wykonania. Widzieliśmy sklepy z 15+ modułami uruchamianymi podczas checkoutu, dodającymi 2-3 sekundy przetwarzania.
• Zewnętrzne wywołania API — obliczanie stawek wysyłki w czasie rzeczywistym (API UPS, FedEx, DHL), usługi obliczania podatków (TaxJar, Avalara) i API weryfikacji adresów dodają opóźnienia sieciowe. Jeśli którakolwiek z tych usług jest wolna lub niedostępna, cały checkout się zawiesza.
• Niezoptymalizowane obliczenia przewoźników — sklepy z dziesiątkami przewoźników i złożonymi regułami stref/wag wymuszają na PrestaShop wykonywanie rozbudowanych zapytań do bazy danych na etapie dostawy. Konsolidacja przewoźników i uproszczenie konfiguracji stref może znacząco skrócić czas ładowania tego kroku.
• Ewaluacja reguł koszyka — jeśli masz setki aktywnych reguł koszyka, PrestaShop musi ocenić każdą z nich względem bieżącego koszyka na każdym etapie procesu zamówienia. Okresowe czyszczenie wygasłych lub nieużywanych reguł koszyka pomaga.
• Brakujące indeksy bazy danych — tabele ps_cart_rule, ps_cart_rule_combination i ps_specific_price mogą się znacznie rozrastać w aktywnych sklepach. Zapewnienie odpowiednich indeksów na tych tabelach zapobiega wolnym zapytaniom podczas procesu zamówienia.
• Brak OPcache lub cachowania obiektów — PHP OPcache powinien być zawsze włączony na produkcji. Redis lub Memcached do cachowania sesji i obiektów dodatkowo redukuje czasy odpowiedzi procesu zamówienia.

Aby zdiagnozować problemy z szybkością procesu zamówienia, włącz profiler debugowania PrestaShop (_PS_DEBUG_PROFILING_ w config/defines.inc.php) i sprawdź, które hooki i moduły zużywają najwięcej czasu podczas ładowania strony checkoutu.

Najczęstsze błędy PrestaShop Checkout i jak je naprawić

Oto najczęściej spotykane błędy procesu zamówienia w PrestaShop:

"Brak dostępnej metody płatności" — To najczęściej wyszukiwany błąd. Oznacza, że żaden moduł płatności nie zwrócił opcji przez hook paymentOptions. Najczęstsze przyczyny:

• Moduł płatności nie jest skonfigurowany dla waluty lub kraju klienta
• Ograniczenia modułu płatności w Płatność > Preferencje wykluczają bieżącego przewoźnika, kraj lub grupę klientów
• Moduł płatności ma błąd PHP i cicho przestaje działać — sprawdź logi PrestaShop w var/logs/
• W PrestaShop 8+ nagłówek Content Security Policy blokuje JavaScript modułu, uniemożliwiając jego renderowanie

"Wystąpił błąd podczas przetwarzania zamówienia" — Ten generyczny komunikat może mieć dziesiątki przyczyn. Zacznij od sprawdzenia:

• Logów błędów PrestaShop i logu błędów PHP w poszukiwaniu rzeczywistego wyjątku
• Czy bramka płatności zwróciła konkretny kod błędu (sprawdź logi transakcji modułu płatności)
• Dostępności magazynowej — jeśli produkt skończył się w magazynie między koszykiem a płatnością, tworzenie zamówienia się nie powiedzie
• Konfliktów reguł koszyka — nieprawidłowy lub wygasły kod rabatowy w koszyku może spowodować niepowodzenie walidacji na ostatnim etapie

Opróżnianie koszyka podczas checkoutu — Klienci zgłaszają, że ich koszyk staje się pusty po przejściu na stronę procesu zamówienia. Jest to prawie zawsze problem z ciasteczkami lub sesją:

• Błędna konfiguracja SSL — koszyk jest przechowywany w ciasteczku sesji, które nie przenosi się między HTTP a HTTPS
• Niezgodność domen — jeśli URL sklepu i domena SSL nie pasują dokładnie, ciasteczka nie są współdzielone
• Pełne miejsce na sesje — jeśli sesje są przechowywane na dysku, a partycja jest pełna, nowe sesje nie mogą być tworzone
• Moduł wywołujący Context::getContext()->cart = new Cart() podczas hooka checkout, przypadkowo resetujący koszyk

Błędy walidacji adresu — Klienci nie mogą przejść dalej niż krok adresowy. Sprawdź:

• Wymagane pola adresowe w Międzynarodowe > Lokalizacje > Kraje — niektóre kraje wymagają województwa/regionu, którego klient nie wybrał
• Ciąg formatu adresu dla kraju dostawy — nieprawidłowy format może spowodować, że walidacja odrzuci prawidłowe adresy
• Regex walidacji kodu pocztowego — PrestaShop waliduje kody pocztowe względem wzorców specyficznych dla kraju, a te mogą być błędne lub zbyt restrykcyjne dla niektórych regionów

Problemy z przekierowaniem 3DS — Po uwierzytelnieniu 3D Secure klient nie wraca do sklepu lub trafia na stronę błędu. Dzieje się tak, gdy:

• URL powrotny skonfigurowany w module płatności używa HTTP zamiast HTTPS
• Sesja wygasła podczas weryfikacji 3DS (klient potrzebował zbyt dużo czasu)
• URL webhooka/callbacku modułu płatności jest nieosiągalny z serwerów dostawcy płatności (firewall, nieprawidłowy URL)
• Konfiguracje wielodomenowe, w których URL powrotny 3DS wskazuje na inną domenę niż ta, na której klient robi zakupy

Reguły koszyka i warstwa rabatów

Jedną z najbardziej złożonych części każdego procesu zamówienia w PrestaShop jest sposób, w jaki stosowane są rabaty. Reguły koszyka (vouchery, kody promocyjne, automatyczne rabaty) oraz ceny szczegółowe na poziomie katalogu wchodzą ze sobą w interakcję podczas procesu zamówienia, a wyniki mogą być mylące.

• Reguły koszyka są ewaluowane według priorytetu. Niektóre dotyczą całego koszyka, inne konkretnych produktów lub kategorii. Mogą oferować rabaty procentowe, kwoty stałe lub darmową wysyłkę.
• Ceny szczegółowe (ustawiane per produkt w katalogu) są stosowane przed regułami koszyka, co oznacza, że produkt już objęty promocją może nie kwalifikować się do pewnych promocji.
• Ograniczenia łączenia — PrestaShop pozwala oznaczać reguły koszyka jako niełączalne, ale logika dotycząca tego, która reguła "wygrywa", nie zawsze jest intuicyjna, zwłaszcza w sklepach wielowalutowych.

Reguły koszyka z darmową wysyłką i interakcja z przewoźnikami

Reguły koszyka z darmową wysyłką są jedną z najbardziej niezrozumianych funkcji checkoutu. Reguła koszyka z "darmową wysyłką" nie oznacza, że wszyscy przewoźnicy stają się darmowi. Oto jak to naprawdę działa:

• Jeśli reguła koszyka nie jest ograniczona do konkretnych przewoźników, darmowa wysyłka jest stosowana do tego przewoźnika, którego klient wybierze
• Jeśli reguła koszyka jest ograniczona do konkretnych przewoźników, tylko ci przewoźnicy wyświetlają się jako darmowi — inni przewoźnicy nadal pokazują swoją normalną cenę
• Ograniczenia krajów i stref reguły koszyka również mają zastosowanie — reguła "darmowa wysyłka w Niemczech" nie sprawi, że wysyłka będzie darmowa dla adresu dostawy we Francji
• Gdy wiele reguł koszyka oferuje darmową wysyłkę, stosowana jest pierwsza prawidłowa (według priorytetu). Pozostałe są nadal "wykorzystane" z perspektywy klienta, ale nie kumulują dodatkowych korzyści.

Problem priorytetu i łączenia

Priorytet reguł koszyka określa kolejność ewaluacji i ma większe znaczenie, niż większość sprzedawców sobie zdaje sprawę. Rozważmy ten przykład:

• Reguła A (priorytet 1): 20% rabatu na cały koszyk, niełączalna
• Reguła B (priorytet 2): Darmowa wysyłka dla zamówień powyżej 50 EUR

Ponieważ Reguła A jest niełączalna i ma wyższy priorytet, Reguła B nie zostanie zastosowana — mimo że darmowa wysyłka wydaje się odrębną korzyścią. Klient otrzymuje 20% rabatu, ale płaci za wysyłkę. Aby to naprawić, trzeba albo uczynić Regułę A łączalną, albo wbudować darmową wysyłkę w samą Regułę A.

Inny częsty scenariusz: klient wprowadza voucher na 10 EUR, ale koszyk ma również automatyczny rabat 15%. Jeśli automatyczny rabat jest niełączalny i ma wyższy priorytet, voucher zostaje odrzucony — a klient widzi mylący komunikat "ten voucher jest nieprawidłowy" bez wyjaśnienia dlaczego.

Dlaczego reguły koszyka z "minimalną kwotą" mylą sprzedawców

Pole "minimalna kwota" w regułach koszyka sprawdza sumę koszyka przed lub po innych rabatach w zależności od konfiguracji — i tu właśnie powstaje zamieszanie. Jeśli ustawisz minimum na 100 EUR, a klient ma koszyk o wartości 110 EUR, ale poprzednia reguła koszyka już obniżyła go do 95 EUR, sprawdzenie minimum może zakończyć się niepowodzeniem. Ponadto "minimalna kwota" może być skonfigurowana tak, aby uwzględniać lub wykluczać podatki i wysyłkę, co prowadzi do różnych progów w zależności od lokalizacji klienta i wybranego przewoźnika. Zawsze testuj reguły minimalnych kwot z realnymi scenariuszami koszyka w różnych krajach przed ich wdrożeniem.

Zakupy jako gość vs. tworzenie konta

PrestaShop obsługuje zakupy jako gość od razu po instalacji, pozwalając klientom składać zamówienia bez tworzenia pełnego konta. To znacząco redukuje tarcie — badania konsekwentnie pokazują, że wymuszanie tworzenia konta jest jedną z głównych przyczyn porzucania koszyków. Możesz włączyć lub wyłączyć zakupy jako gość w Parametry sklepu > Ustawienia klientów. Ten temat omawiamy szczegółowo w naszym poradniku dotyczącym zakupów jako gość, uwzględniając kompromisy między współczynnikiem konwersji a zbieraniem danych klientów.

Moduł PrestaShop Checkout (ps_checkout)

Czym jest ps_checkout?

Moduł PrestaShop Checkout — technicznie nazywany ps_checkout — to darmowy moduł płatności opracowany wspólnie przez PrestaShop SA i PayPal. Jest preinstalowany w nowych instalacjach PrestaShop od wersji 1.7.5.

Oto kluczowe rozróżnienie, które myli wielu sprzedawców: ps_checkout to moduł płatności, nie sam przepływ procesu zamówienia. Nie zmienia on kroków procesu zamówienia, układu strony ani kolejności, w jakiej zbierane są informacje. Obsługuje wyłącznie krok płatności — dając Twoim klientom więcej sposobów płacenia. Podstawowy proces zamówienia opisany powyżej pozostaje dokładnie taki sam.

Co oferuje

Na papierze ps_checkout zapewnia solidny zestaw funkcji płatności:

• Płatności kartą — Visa, Mastercard i American Express przez pola płatności hostowane przez PayPal osadzone w Twoim checkoucie
• Portfel PayPal — klienci płacą saldem PayPal lub podłączonym kontem bankowym
• Apple Pay i Google Pay — obsługa portfeli mobilnych (gdzie dostępne)
• Lokalne metody płatności — iDEAL, Bancontact, BLIK i inne w zależności od rynku
• Zapłać później / Zapłać w 3-4 ratach — opcje kup teraz, zapłać później obsługiwane przez PayPal
• 3D Secure 2 — obowiązkowe silne uwierzytelnianie klienta dla transakcji w UE
• 20+ walut — obsługa wielu walut przez sieć PayPal

Jak na darmowy moduł, to hojna lista funkcji. Pełną dokumentację możesz przejrzeć na repozytorium GitHub ps_checkout.

Szczegóły opłat transakcyjnych

Chociaż sam ps_checkout jest darmowy, płacisz standardowe opłaty transakcyjne PayPal od każdego zamówienia. Stan na 2026 rok — oto czego możesz się spodziewać:

Pamiętaj, że stawki te mogą się różnić w zależności od poziomu Twojego konta PayPal i miesięcznego wolumenu. Sprzedawcy z dużym wolumenem mogą kwalifikować się do obniżonych stawek w ramach programu stawek handlowych PayPal.

ps_checkout vs. Stripe vs. Mollie: porównanie PrestaShop Checkout

Aby pomóc Ci ocenić Twoje opcje, oto porównanie side-by-side trzech najpopularniejszych rozwiązań płatniczych:

Jak zainstalować i skonfigurować ps_checkout

Konfiguracja ps_checkout: zainstaluj moduł (preinstalowany w nowych sklepach, w przeciwnym razie pobierz z Addons), połącz swoje konto PrestaShop Addons, podłącz konto PayPal Business poprzez kreator wdrożeniowy (konta osobiste nie są obsługiwane), skonfiguruj oferowane metody płatności, upewnij się, że ustawienia zaokrągleń/walut odpowiadają oczekiwaniom PayPal i przetestuj w trybie sandbox przed uruchomieniem produkcyjnym.

Jak odinstalować ps_checkout

Aby usunąć ps_checkout: przejdź do Moduły > Menedżer modułów, wyszukaj "ps_checkout" i wybierz Wyłącz jako pierwszy krok (bezpieczne — zatrzymuje wyświetlanie bez usuwania danych). Aby całkowicie usunąć, wybierz Odinstaluj, a następnie opcjonalnie usuń modules/ps_checkout/. Ważne: upewnij się, że inny moduł płatności jest skonfigurowany wcześniej, w przeciwnym razie checkout wyświetli "Brak dostępnej metody płatności."

Architektura pośrednika PayPal

To tutaj sprawa staje się bardziej złożona. W przeciwieństwie do bezpośredniej integracji Stripe lub Adyen, gdzie płatności trafiają wprost na Twoje konto handlowe, ps_checkout kieruje transakcje przez pośredniczące konto handlowe PayPal platformy PrestaShop SA. PrestaShop SA działa jako facylitator.

Co to oznacza w praktyce:

• Musisz połączyć swoje konto PayPal business przez przepływ wdrożeniowy PrestaShop — nie bezpośrednio z PayPal
• Terminy rozliczeń i dostępność środków zależą zarówno od polityki PayPal, jak i konfiguracji platformy PrestaShop SA
• Obsługa chargebacków przechodzi przez dodatkową warstwę, co spowalnia rozwiązywanie sporów
• Masz mniejszą widoczność surowych danych transakcyjnych w porównaniu z bezpośrednią integracją bramki

Ta architektura nie jest z natury zła — tak działają modele wielu facylitatorów płatności (Shopify Payments działa podobnie). Ale warto to zrozumieć zanim się zdecydujesz, zwłaszcza jeśli Twój sklep przetwarza duże wolumeny lub działa w branżach regulowanych.

Znane ograniczenia

Na podstawie opinii społeczności, zgłoszeń na GitHub i naszych własnych testów, oto najczęściej raportowane problemy z ps_checkout:

• Kompatybilność z szablonami — moduł działa najlepiej z szablonem Classic. Niestandardowe szablony, zwłaszcza mocno zmodyfikowane, często doświadczają problemów z renderowaniem hostowanych pól płatności.
• Nieskończony spinner — dobrze znany problem, w którym formularz płatności nigdy nie kończy się ładować, zwykle spowodowany konfliktami JavaScript z innymi modułami lub nagłówkami Content Security Policy blokującymi skrypty PayPal.
• Generyczne komunikaty błędów 3DS — gdy uwierzytelnianie 3D Secure się nie powiedzie, komunikat błędu wyświetlany klientom jest często niepomocny, prowadząc do porzuconych zakupów, które mogłyby zostać odzyskane przy jaśniejszym komunikacie.
• Brak dedykowanego wsparcia — wsparcie jest obsługiwane przez fora społecznościowe i zgłoszenia GitHub, a nie przez bezpośredni kanał wsparcia, co może być frustrujące dla sprzedawców doświadczających awarii płatności.
• Ryzyko aktualizacji — główne aktualizacje wersji historycznie wprowadzały przełomowe zmiany. Moduł rozwija się szybko, co jest pozytywne dla funkcjonalności, ale ryzykowne dla stabilności.

Żadne z tych ograniczeń nie jest samo w sobie dyskwalifikujące, ale razem oznaczają, że powinieneś dokładnie przetestować przed uruchomieniem produkcyjnym — i zawsze testuj aktualizacje modułu najpierw w środowisku testowym.

Kiedy ps_checkout ma sens

Pomimo ograniczeń ps_checkout jest solidnym wyborem w określonych scenariuszach:

• Nowe sklepy — dopiero zaczynasz i musisz szybko przyjmować płatności bez kosztów początkowych
• Sklepy jednorynkowe — sprzedajesz głównie w jednym kraju i nie potrzebujesz złożonego wielowalutowego rozliczania
• Sprzedawcy oszczędni — zerowy koszt modułu, brak opłat miesięcznych i model płatności za transakcję przez PayPal
• Proste katalogi — standardowe produkty bez subskrypcji, przedsprzedaży lub złożonych przepływów płatności

Personalizacja PrestaShop Checkout

Co możesz zmienić bez modułów?

Przed zainstalowaniem jakichkolwiek modułów firm trzecich istnieje kilka sposobów na personalizację procesu zamówienia przy użyciu wbudowanych narzędzi:

• Szablony motywu — edytuj szablony Smarty procesu zamówienia w swoim motywie, aby zmienić układ, kolejność pól lub dodać własną treść między krokami
• Stylowanie CSS — dostosuj kolory, odstępy, rozmiary przycisków i typografię, aby dopasować do swojej marki bez ingerencji w funkcjonalność
• Konfiguracja przewoźników — zmień sposób prezentacji opcji wysyłki, dostosowując nazwy przewoźników, opisy, szacowane czasy dostawy i kolejność wyświetlania
• Kolejność modułów płatności — zmień kolejność wyświetlania metod płatności w back office w Płatność > Preferencje
• Wymagane pola — dostosuj, które pola klienta i adresu są obowiązkowe w konfiguracji Klienci > Adresy

Te zmiany to bezpieczne personalizacje na poziomie szablonu, które przetrwają aktualizacje PrestaShop, pod warunkiem, że używasz szablonu potomnego. Aby dowiedzieć się więcej o optymalizacji checkoutu bez dodawania złożoności, zobacz nasz poradnik optymalizacji procesu zamówienia.

Własne pola w procesie zamówienia

Wielu sprzedawców potrzebuje dodatkowych informacji podczas procesu zamówienia PrestaShop, których domyślna instalacja nie zbiera. Typowe przykłady to: numer telefonu komórkowego do powiadomień SMS o dostawie, nazwa firmy i numer VAT dla przepływów B2B, instrukcje dostawy (kody do bramy, "zostawić u sąsiada") oraz własne numery referencyjne zamówień (numery zamówień zakupu).

PrestaShop obsługuje dodawanie własnych pól do formularza adresu przez back office (Klienci > Adresy), ale opcje są ograniczone. Dla bardziej złożonych wymagań możesz albo bezpośrednio modyfikować szablony procesu zamówienia i przetwarzać dane za pomocą własnego modułu podpiętego do actionValidateOrder, albo użyć modułu pól checkoutu firm trzecich z marketplace Addons.

Tłumaczenie i lokalizacja procesu zamówienia

Jeśli sprzedajesz międzynarodowo, przetłumaczenie procesu zamówienia PrestaShop jest kluczowe. Nieprzetłumaczone etykiety i komunikaty błędów bezpośrednio powodują porzucanie — klient, który nie może zrozumieć kroku płatności, nie dokończy zamówienia.

Kluczowe zadania lokalizacyjne:

• Etykiety kroków zamówienia — tłumaczone przez Międzynarodowe > Tłumaczenia. Wybierz "Tłumaczenia front office" i swój szablon, aby znaleźć ciągi związane z procesem zamówienia.
• Tekst modułu płatności — każdy moduł płatności ma własne pliki tłumaczeń, oddzielne od tłumaczeń rdzenia.
• Komunikaty błędów — błędy walidacji typu "Proszę wprowadzić prawidłowy adres" są często pomijane podczas tłumaczenia.
• Regulamin — pole wyboru "Zgadzam się z regulaminem" linkuje do strony CMS, która musi być przetłumaczona na każdy język.
• Etykiety formularza adresu — PrestaShop używa formatów adresów specyficznych dla kraju. Upewnij się, że etykiety odpowiadają lokalizacji klienta.

Częsty błąd: zainstalowanie pakietu językowego nie tłumaczy ciągów specyficznych dla modułu. Jeśli checkout wyświetla angielskie nazwy metod płatności w polskim sklepie, przetłumacz moduł płatności osobno.

One Page Checkout

Najpopularniejszą personalizacją procesu zamówienia jest konsolidacja wszystkich kroków na jednej stronie. Zamiast przechodzić przez pięć oddzielnych ekranów, klient widzi pola adresu, wysyłki i płatności naraz — wypełnia je i finalizuje zakup bez przeładowywania strony.

Dane są jednoznaczne: one page checkout zmniejsza współczynnik porzuceń, usuwając tarcie wynikające z wielu kroków. Mniej kliknięć, mniej szans na odejście klienta. Benchmarki branżowe pokazują, że implementacje one page checkout zazwyczaj poprawiają współczynniki konwersji o 10-20% w porównaniu z przepływami wieloetapowymi. Największe zyski pochodzą od użytkowników mobilnych, gdzie każde ładowanie strony przy wolnym połączeniu grozi utratą klienta. Szczegółowo omawiamy liczby i podejście w naszym artykule o one page checkout.

Z perspektywy UX one page checkout oznacza: wszystkie pola formularza widoczne natychmiast, natychmiastowe aktualizacje kosztów wysyłki przez AJAX, walidacja inline (błędy pojawiają się podczas wpisywania), brak potrzeby wskaźnika postępu oraz podsumowanie zamówienia widoczne przez cały czas. Te zmiany łącznie redukują obciążenie poznawcze i utrzymują koncentrację klientów na finalizacji zakupu.

Aktualnie PrestaShop nie zawiera natywnego one page checkout — wieloetapowy przepływ to wszystko, co dostajesz od razu po instalacji. To się zmieni w PrestaShop 9.2, który wprowadzi opcjonalny natywny OPC dla sklepów działających na szablonie Hummingbird v2. Do tego czasu moduły firm trzecich są jedynym sposobem na uzyskanie tej funkcjonalności.

Express Checkout

Express checkout idzie o krok dalej: zamiast usprawniać stronę procesu zamówienia, pozwala klientom całkowicie ją pominąć. Przyciski zakupu obsługiwane przez Apple Pay, Google Pay lub PayPal pojawiają się bezpośrednio na stronach produktów i w koszyku. Klient uwierzytelnia się swoim portfelem, który dostarcza adres wysyłki i dane płatności jednym dotknięciem — bez formularzy, bez kroków.

To szczególnie skuteczne na urządzeniach mobilnych, gdzie wpisywanie adresów na małych ekranach jest poważnym zabójcą konwersji. Wzorce express checkout i implementację szczegółowo omawiamy w naszym artykule o express checkout.

Embedded i modal checkout

Mniej popularnym, ale rosnącym wzorcem jest embedded checkout — gdzie formularz płatności pojawia się w nakładce modalnej lub inline na bieżącej stronie bez nawigacji do oddzielnego URL checkoutu. To utrzymuje klienta w kontekście zakupowym podczas zbierania danych płatności, redukując psychologiczny dystans między "chcę to" a "kupiłem to". Stripe Payment Element i doświadczenie in-context PayPal wspierają to podejście.

Alternatywy dla PrestaShop Checkout

Jeśli ps_checkout nie spełnia Twoich potrzeb, istnieje kilka dojrzałych alternatyw do obsługi płatności w Twoim przepływie zamówień PrestaShop.

Stripe

Stripe Payment Element to jedna z najbardziej przyjaznych dla programistów integracji płatniczych. Kluczowe zalety:

• Bezpośrednie konto handlowe — płatności trafiają na Twoje konto Stripe bez pośrednika
• 135+ walut z automatycznym przeliczaniem
• Apple Pay, Google Pay, Link (portfel zapisanych kart Stripe) i 40+ lokalnych metod płatności
• Kompleksowe API z doskonałą dokumentacją
• Wbudowana ochrona przed oszustwami przez Stripe Radar

Najlepszy dla: sklepów międzynarodowych, technicznie zaawansowanych sprzedawców, sklepów chcących pełnej kontroli nad danymi płatności i doświadczeniem klienta.

Mollie

Mollie jest dominującym dostawcą płatności dla europejskiego e-commerce, z szczególnie silną adopcją w Holandii, Belgii, Niemczech i Francji. Wyróżniki:

• Przejrzyste ceny za transakcję bez opłat miesięcznych
• Natywna obsługa iDEAL, Bancontact, SOFORT, EPS, Giropay i KBC/CBC
• Solidny moduł PrestaShop utrzymywany bezpośrednio przez Mollie
• Łatwe wdrożenie z szybkim zatwierdzeniem konta

Najlepszy dla: sklepów skupionych na UE, szczególnie sprzedających w krajach Benelux lub regionie DACH, gdzie lokalne metody płatności dominują.

Adyen

Adyen to opcja klasy enterprise dla sklepów o dużym wolumenie. Używany przez firmy takie jak Booking.com i eBay, oferuje 250+ metod płatności z inteligentnym routingiem, zaawansowanym wykrywaniem oszustw (RevenueProtect) i bezpośrednim acquiringiem — Adyen jest zarówno procesorem, jak i acquirerem, redukując pośredników.

Kompromisem jest złożoność i koszt. Adyen wymaga niestandardowej integracji, ma minimalne wolumeny przetwarzania i pobiera miesięczne opłaty platformowe. Nie jest praktyczny dla małych sklepów, ale dla sprzedawców przetwarzających ponad 50 000 EUR miesięcznie, poprawione współczynniki autoryzacji często uzasadniają inwestycję.

Amazon Pay

Amazon Pay pozwala klientom finalizować zamówienie za pomocą istniejącego konta Amazon — adres, metoda płatności i wszystko inne. Zakupy jednym kliknięciem z zapisanych danych Amazon, silne zaufanie do marki i ochrona kupującego A-to-Z Guarantee czynią go skuteczną drugorzędną opcją płatności obok kart i PayPal. Moduł PrestaShop jest dostępny na marketplace Addons.

Samodzielny moduł PayPal

Jeśli chcesz płatności PayPal bez warstwy pośrednika PrestaShop SA, możesz użyć samodzielnego modułu PayPal, który łączy się bezpośrednio z Twoim kontem PayPal business. Daje to:

• Bezpośrednią kontrolę nad kontem PayPal, rozliczeniami i zarządzaniem sporami
• To samo doświadczenie portfela PayPal, którego oczekują klienci
• Opcje Zapłać później konfigurowane przez własny panel PayPal

Najlepszy dla: sprzedawców, którzy chcą PayPal jako opcji płatności, ale preferują bezpośrednią relację z PayPal zamiast modelu pośrednictwa ps_checkout.

Checkout Revolution (od mypresta.rocks)

Pełna transparentność: to nasz moduł. Checkout Revolution łączy one page checkout i express checkout w jedno rozwiązanie oparte na Stripe. Umieszcza przyciski zakupu na stronach produktów, w koszyku i w procesie zamówienia — obsługując Apple Pay, Google Pay, PayPal, Link, karty i 30+ dodatkowych metod płatności przez Stripe Payment Element. Płatności trafiają bezpośrednio na Twoje konto Stripe bez żadnego pośrednika.

Zbudowaliśmy go, ponieważ widzieliśmy sprzedawców instalujących trzy lub cztery oddzielne moduły, aby uzyskać funkcjonalność, która powinna działać razem bezproblemowo. Nie jest to idealne rozwiązanie dla każdego sklepu, ale jeśli chcesz express checkout i nowoczesny stos płatności w jednym pakiecie, warto się temu przyjrzeć.

Alternatywy PrestaShop Checkout: szybkie porównanie

Bezpieczeństwo procesu zamówienia i zgodność z PCI

Bezpieczeństwo nie jest opcjonalne dla żadnego procesu zamówienia online — to wymóg prawny i biznesowy. Klienci powierzają Twojemu sklepowi swoje dane płatności, a każde naruszenie może skutkować karami finansowymi, postępowaniem prawnym i nieodwracalnymi szkodami dla marki.

Co PCI DSS oznacza dla sprzedawców PrestaShop

PCI DSS (Payment Card Industry Data Security Standard) to zbiór standardów bezpieczeństwa, które mają zastosowanie do każdej firmy akceptującej, przetwarzającej, przechowującej lub przesyłającej informacje o kartach kredytowych. Jako właściciel sklepu PrestaShop, Twój poziom zgodności PCI zależy od tego, jak Twój checkout obsługuje dane karty:

• SAQ A (najmniejsze obciążenie) — jeśli używasz hostowanych pól płatności lub przekierowań, gdzie dane karty nigdy nie dotykają Twojego serwera, kwalifikujesz się do najprostszego kwestionariusza samooceny. Tak jest w przypadku ps_checkout, Stripe Payment Element i hostowanego checkoutu Mollie.
• SAQ A-EP — jeśli Twoja strona checkoutu ładuje JavaScript od dostawcy płatności, który przechwytuje dane karty na Twojej stronie (mimo że są wysyłane bezpośrednio do dostawcy), podlegasz tej nieco bardziej wymagającej kategorii.
• SAQ D (największe obciążenie) — jeśli dane karty przechodzą przez Twój serwer w jakimkolwiek momencie (np. źle zbudowany niestandardowy formularz płatności, który POSTuje numery kart na Twój serwer przed przekazaniem ich dalej), stajesz przed pełną oceną PCI DSS. To jest niezwykle kosztowne i złożone — unikaj tego.

Praktyczny wniosek: zawsze używaj modułów płatności oferujących hostowane pola płatności lub hostowane strony checkoutu. To gwarantuje, że dane karty nigdy nie dotkną Twojego serwera i utrzymuje Cię w kategorii SAQ A.

Dlaczego hostowane pola płatności mają znaczenie

Hostowane pola płatności to iframy serwowane przez dostawcę płatności osadzone na Twojej stronie checkoutu. Pola numeru karty, daty ważności i CVV wyglądają jak część Twojego formularza, ale działają na domenie dostawcy — dane karty nigdy nie dotykają Twojego serwera. Wszyscy główni dostawcy (ps_checkout, Stripe, Mollie, Adyen) obsługują to podejście. Jeśli moduł płatności prosi Cię o tworzenie surowych pól HTML dla karty, unikaj go — to sygnał ostrzegawczy niezgodności z PCI.

SCA, 3DS2 i wymagania SSL

Regulacja Strong Customer Authentication (SCA) w UE wymaga 3D Secure 2 (3DS2) dla większości płatności kartą online. Twój moduł płatności musi obsługiwać 3DS2 — starsze moduły obsługujące tylko 3DS1 będą doświadczać coraz większej liczby niepowodzeń. 3DS2 dodaje krok uwierzytelniania bankowego do procesu zamówienia PrestaShop, co może zwiększyć porzucenia, dlatego wybierz dostawcę z wysokimi współczynnikami sukcesu 3DS2. Nieudane 3DS nie zawsze oznacza oszustwo — wyświetl jasny komunikat "spróbuj ponownie" zamiast generycznego błędu.

Każda strona checkoutu musi działać przez HTTPS. Bez ważnego certyfikatu SSL przeglądarki wyświetlają ostrzeżenia "Niezabezpieczone", dostawcy płatności odmawiają ładowania hostowanych pól, a Google obniża Twoje pozycje w rankingu. Darmowe certyfikaty Let's Encrypt są wystarczające. Po zainstalowaniu SSL zweryfikuj, że cały ruch HTTP jest przekierowywany na HTTPS — mieszana zawartość spowoduje nieprawidłowe działanie modułów płatności.

Mierzenie wydajności PrestaShop Checkout

Nie możesz poprawić tego, czego nie mierzysz. Zrozumienie wydajności Twojego checkoutu wymaga śledzenia odpowiednich metryk i wiedzy, jak wygląda "dobrze".

Kluczowe metryki

• Współczynnik ukończenia checkoutu — (ukończone zamówienia / sesje checkoutu) x 100. Twoja najważniejsza metryka procesu zamówienia PrestaShop.
• Współczynnik porzuceń checkoutu — procent klientów, którzy rozpoczynają checkout, ale go nie kończą. To izoluje problemy checkoutu od wizyt tylko przeglądających.
• Współczynnik rezygnacji na poszczególnych krokach — który krok traci najwięcej klientów? Jeśli 40% rezygnuje na etapie wysyłki, problem mogą stanowić opcje przewoźników.
• Czas ukończenia — dłuższe czasy korelują bezpośrednio z wyższym porzucaniem.
• Współczynnik błędów płatności — wysokie wskaźniki wskazują na problemy z konfiguracją 3DS lub zbyt agresywne reguły antyfraudowe.

Śledzenie za pomocą Google Analytics 4

Śledzenie rozszerzonego e-commerce GA4 to standardowy sposób mierzenia lejka procesu zamówienia PrestaShop. Zainstaluj moduł GA4, który odpala zdarzenia begin_checkout, add_shipping_info, add_payment_info i purchase. Następnie skonfiguruj raport lejkowy w GA4 > Eksploruj > Eksploracja lejkowa z krokami odpowiadającymi etapom Twojego checkoutu, aby wizualizować, gdzie klienci rezygnują.

Rozważ śledzenie po stronie serwera dla dokładniejszych danych — śledzenie JavaScript po stronie klienta jest blokowane przez ad blockery u 25-40% odwiedzających. Implementacja GA4 Measurement Protocol po stronie serwera (uruchamiana przez hooki PrestaShop przy tworzeniu zamówienia) rejestruje każde zamówienie niezależnie od blokad po stronie klienta.

Jak wygląda "dobry" współczynnik ukończenia

Benchmarki branżowe: średni to 45-55%, dobry to 55-65%, a doskonały to 65%+ (zazwyczaj osiągany przy one page checkout i opcjach express payment). Jeśli Twój współczynnik jest poniżej 40%, sprawdź, czy nie wymuszasz tworzenia konta, nie masz niespodziewanych kosztów wysyłki, ograniczonych opcji płatności lub błędów technicznych. Te benchmarki różnią się w zależności od branży — zakupy o wysokiej wartości naturalnie mają niższe współczynniki niż moda czy dobra konsumpcyjne.

Co nadchodzi: PrestaShop 9.2 i natywny One Page Checkout

PrestaShop ogłosił, że wersja 9.2 będzie zawierać natywną opcję one page checkout. To istotna zmiana — po raz pierwszy sprzedawcy będą mogli oferować przepływ zamówienia na jednej stronie bez modułów firm trzecich.

Ważne zastrzeżenia:

• Będzie działać tylko z szablonem Hummingbird v2 — sklepy na Classic lub innych szablonach nie będą miały dostępu
• Będzie opcjonalny, nie domyślny — wieloetapowy przepływ pozostanie dostępny
• Autorzy modułów będą musieli dostosować swoje moduły płatności i wysyłki do pracy w nowym przepływie
• Nie ma jeszcze potwierdzonej daty wydania, a wydania PrestaShop historycznie się opóźniały względem początkowych harmonogramów

Czy powinieneś na to czekać? To zależy od Twojego harmonogramu. Jeśli uruchamiasz nowy sklep dzisiaj, czekanie miesiącami (lub dłużej) na funkcję, która może wymagać pełnej migracji szablonu, jest niepraktyczne. Jeśli już używasz Hummingbird i planujesz przyszłą aktualizację, warto to śledzić. Szczegółowo omawiamy tę decyzję w naszym artykule o natywnych planach OPC PrestaShop.

Wybór odpowiedniego checkoutu dla Twojego sklepu

Nie istnieje jedna "najlepsza" konfiguracja PrestaShop checkout — zależy to od Twojego rynku, budżetu, komfortu technicznego i planów rozwoju. Oto praktyczne ramy:

• Dopiero zaczynasz, niski budżet — użyj domyślnego wieloetapowego checkoutu z ps_checkout. Jest darmowy, działa, a później możesz go zaktualizować.
• Ugruntowany sklep, wysoki współczynnik porzuceń — zainwestuj w moduł one page checkout. Wzrost konwersji zazwyczaj zwraca się w ciągu tygodni.
• Duży ruch mobilny — priorytetowo traktuj express checkout z płatnościami portfelowymi (Apple Pay, Google Pay). Klienci mobilni porzucają formularze znacznie częściej niż użytkownicy desktopowi.
• Sprzedaż w całej Europie — rozważ Mollie ze względu na lokalne metody płatności lub Stripe dla szerszego zasięgu międzynarodowego.
• Sklep o dużym wolumenie — przejdź na bezpośrednią integrację płatności (Stripe, Adyen), gdzie masz pełną kontrolę nad rozliczeniami, raportowaniem i zarządzaniem sporami. Model pośrednictwa ps_checkout dodaje złożoność na skalę.
• Enterprise z potrzebami omnichannel — oceń Adyen pod kątem ujednoliconych płatności online i w sklepie stacjonarnym przez jedną platformę.
• Chcesz wszystko w jednym module — przyjrzyj się rozwiązaniom łączącym optymalizację przepływu zamówienia z przetwarzaniem płatności, zamiast nakładać wiele modułów, które mogą ze sobą kolidować.

Cokolwiek wybierzesz, regularnie testuj swój PrestaShop checkout. Składaj zamówienia testowe na różnych urządzeniach, wypróbuj różne metody płatności, stosuj kody rabatowe i sprawdź, jak przepływ radzi sobie z błędami. Twój checkout to miejsce, gdzie generowany jest przychód — zasługuje na więcej uwagi, niż większość sprzedawców mu poświęca.