Natywna jednostronicowa finalizacja zamówienia w PrestaShop 9.2: co powinni wiedzieć sprzedawcy i deweloperzy

Ostatnia aktualizacja: czerwiec 2026.

Aktualizacja, maj 2026: PrestaShop poinformował partnerów, że natywny moduł jednostronicowej finalizacji zamówienia (OPC) jest planowany dla PrestaShop 9.2, a oficjalne wydanie 9.2 jest obecnie przewidywane na drugą połowę 2026 roku. Po raz pierwszy prawdziwa jednostronicowa finalizacja zamówienia ma zostać wbudowana w samą platformę, zamiast być dokładana przez moduł albo przebudowę motywu.

To dobra wiadomość dla całego ekosystemu. Finalizacja zamówienia od dawna była tym obszarem, w którym sprzedawcy korzystający z PrestaShop sięgali po moduł zewnętrzny, indywidualne prace nad motywem albo jedno i drugie. Ale pytanie „czy natywne OPC nadchodzi?” nie jest dobrym punktem wyjścia do planowania. Przydatne pytania są bardziej konkretne: co publiczny kod faktycznie robi dzisiaj, jakie ma ograniczenia i co sprzedawca albo deweloper modułów powinien zmienić już teraz właśnie z tego powodu? Ten wpis odpowiada na nie na podstawie źródeł, nie marketingowej mapy drogowej.

Jeśli chcesz zobaczyć szerszy obraz tego, jak dziś wdrożyć jednostronicową finalizację zamówienia w PrestaShop wszystkimi dostępnymi drogami, zacznij od artykułu jednostronicowa finalizacja zamówienia dla PrestaShop oraz szerszego przewodnika po optymalizacji finalizacji zamówienia. Ten artykuł celowo ma węższy zakres: dotyczy konkretnie natywnego rozwiązania budowanego dla wersji 9.2.

Wersja skrócona

Natywne OPC to realna praca inżynieryjna, a nie tylko punkt w planie rozwoju. Do rdzenia PrestaShop scalono pull request (#40796), który dodaje flagę funkcji OPC, a sam moduł jest udostępniany jako osobne publiczne repozytorium, ps_onepagecheckout. Są więc dwa ruchome elementy: punkt integracji/kontrakt w rdzeniu (hook actionCheckoutBuildProcess) oraz moduł, który z niego korzysta.

Jest jednak haczyk: repozytorium modułu opisuje obecnie projekt jako intensywnie rozwijany. To najważniejszy fakt planistyczny w całym tym tekście. Sprzedawcy powinni traktować natywne OPC w 9.2 jako coś, co warto obserwować i testować na środowisku stagingowym. Nie jako stabilną funkcję, na którą można czekać, zostawiając na produkcji wadliwą finalizację zamówienia. Deweloperzy powinni wstrzymać się z twardymi założeniami dotyczącymi kompatybilności, dopóki kontrakty techniczne się nie ustabilizują.

Czym natywna finalizacja zamówienia różni się od dzisiejszej domyślnej wersji

Dzisiejsza domyślna finalizacja zamówienia, oparta na tej samej architekturze w PrestaShop 1.7, 8.x oraz 9.0–9.1. Już działa pod jednym adresem URL przez kontroler order, ale odsłania się krok po kroku. Każdy krok ma własną klasę: CheckoutPersonalInformationStep, CheckoutAddressesStep, CheckoutDeliveryStep oraz CheckoutPaymentStep. Krok pozostaje zwinięty, dopóki poprzedni nie zostanie ukończony. Jedna strona, cztery bramki. W artykule natywna jednostronicowa finalizacja zamówienia w PrestaShop (OPC) wyjaśnialiśmy, dlaczego te bramki powodują utratę zamówień.

Natywny moduł dla wersji 9.2 zastępuje tę sekwencję kroków jednym połączonym krokiem. Zamiast kolejno rozwijanych sekcji: dane osobowe, adresy, dostawa i płatność, klient widzi finalizację zamówienia jako jeden ekran. Co kluczowe, dzieje się to wewnątrz własnego procesu finalizacji zamówienia PrestaShop, a nie jako osobna aplikacja front-endowa, i właśnie dlatego opisane niżej pytania o kompatybilność naprawdę mają znaczenie.

Co publiczny kod faktycznie robi

W obecnym module ps_onepagecheckout widać kilka konkretnych możliwości. To elementy, które sprzedawca albo deweloper powinien rozumieć, zanim wyrobi sobie opinię:

• Wstrzyknięcie procesu finalizacji zamówienia. Moduł rejestruje hook actionCheckoutBuildProcess, czyli podstawowy kontrakt rdzenia dla wstrzykiwania procesu finalizacji zamówienia. Ten hook pozwala modułowi dostarczyć własny proces finalizacji w miejsce domyślnego procesu krokowego, czysto, bez nadpisywania kontrolera zamówienia.
• Jeden krok finalizacji zamówienia. Zamiast czterech klas kroków implementacja buduje jeden połączony krok jednostronicowy. To jest faktyczny mechanizm stojący za „jedną stroną”, nie ukrywanie kroków CSS-em, lecz inna definicja procesu.
• Inicjalizacja gościa przez AJAX. Istnieje endpoint AJAX, który może utworzyć lub ponownie użyć klienta-gościa, gdy adres e-mail i wymagane zgody są poprawne, a następnie przypisać tego klienta do koszyka przed ostatecznym złożeniem zamówienia.
• Odświeżanie formularza adresowego przez AJAX. Drugi endpoint AJAX przebudowuje formularz adresowy, gdy musi się on zmienić, na przykład po wybraniu przez klienta innego kraju, co może zmienić wymagane pola i sposób naliczania podatków.
• Standardowe wykrywanie opcji płatności. Finalizacja zamówienia nadal korzysta ze standardowego mechanizmu opcji płatności PrestaShop, więc istniejące moduły płatności pozostają częścią procesu, zamiast być omijane.

Ten ostatni punkt daje architektoniczne uspokojenie. Natywne OPC utrzymuje finalizację zamówienia wewnątrz PrestaShop, zamiast rozdzielać ją do samodzielnej aplikacji. Ceną jest to, że prace nad kompatybilnością naprawdę mają znaczenie: moduły płatności, moduły przewoźników, hooki finalizacji zamówienia i szablony motywu spotykają się teraz na tym samym ekranie w tym samym czasie.

Możliwości i ograniczenia: czym natywne OPC jest, a czym nie jest

Najczęstsze nieporozumienie polega na założeniu, że „jednostronicowa finalizacja zamówienia” oznacza „w pełni AJAX-ową finalizację bez przekierowań, płatność jak Apple Pay”. Tak nie jest. Oto uczciwy zakres, punkt po punkcie.

Konkretnie w płatnościach: moduł płatności nadal może przekierować klienta do bramki, hostowanej strony płatności, kroku 3D Secure, procesu portfela albo strony potwierdzenia w banku. To normalne w e-commerce i nie jest wadą. Jednostronicowa finalizacja zamówienia zmniejsza tarcie przed płatnością; nie zastępuje przekierowania płatniczego. Przekształcenie samej płatności w akcję jednym dotknięciem to inna funkcja, ekspresowa finalizacja zamówienia/portfele, omówiona w artykule ekspresowa finalizacja zamówienia.

Obsługa zakupów jako gość (dlaczego nudne szczegóły mają znaczenie)

Obsługa gościa to miejsce, w którym jednostronicowa finalizacja zamówienia po cichu działa dobrze albo się rozpada, bo wszystko dzieje się teraz w jednym cyklu życia ekranu, a nie w uporządkowanej sekwencji stron. Obecny kod dobrze obsługuje kilka takich przypadków brzegowych:

• Jeśli zakupy jako gość są wyłączone, endpoint inicjalizacji gościa nie tworzy klienta-gościa po cichu.
• Jeśli koszyk należy już do zarejestrowanego, zalogowanego klienta, handler nie nadpisuje tej własności.
• Jeśli klient-gość już istnieje, kod próbuje ponownie użyć albo zaktualizować ten kontekst gościa, zamiast bezrefleksyjnie tworzyć duplikaty.
• Rzeczywiste dane adresowe nadal są walidowane i zapisywane jako część przepływu formularza, pojedyncza strona nie pomija walidacji.

Nic z tego nie jest efektowne, ale to dokładnie ta warstwa techniczna decyduje, czy koszyki, adresy, klienci i moduły płatności pozostają spójne na produkcji. To, czy zakupy jako gość są w ogóle właściwym domyślnym wyborem dla Twojego sklepu, jest decyzją biznesową opartą na zaskakująco czytelnych danych, zobacz zakupy jako gość a zakładanie konta.

Termin migracji: kiedy naprawdę warto przejść?

To decyzja, którą większość wpisów pomija. Powinny ją kształtować trzy realia czasowe:

• 9.2 pojawi się najwcześniej w drugiej połowie 2026 roku, a „planowane” nie znaczy „wydane”. Traktuj tę datę jako orientacyjną.
• Moduł jest teraz intensywnie rozwijany, więc nawet po premierze 9.2 prawdopodobnie pojawi się okres stabilizacji w realnych sklepach, zanim będzie można bezpiecznie używać go w krytycznej dla przychodów finalizacji zamówienia.
• Większość sklepów długo nie będzie działać na 9.2. Wiele produkcyjnych sklepów pozostanie na 1.7, 8.x, 9.0 albo 9.1 jeszcze długo po wydaniu 9.2, bo aktualizacje dotykające finalizacji zamówienia należą dokładnie do tych, które sprzedawcy odkładają.

Po złożeniu tych faktów wniosek jest prosty: natywne OPC jest powodem, by się przygotować, a nie powodem, by zostawić nieszczelną finalizację zamówienia bez zmian. Jeśli Twoja finalizacja zamówienia dziś słabo konwertuje, czekanie przez jeden lub kilka cykli wydań samo w sobie kosztuje utracone zamówienia. Jeśli nie masz pewności, czy to właśnie finalizacja zamówienia jest źródłem strat, najpierw postaw diagnozę. Dobrym punktem startu są dlaczego strona finalizacji zamówienia traci sprzedaż oraz szersze omówienie powodów porzucania koszyków.

Co zwykli sprzedawcy powinni zrobić teraz

W obecnych sklepach jednostronicowa finalizacja zamówienia pozostaje decyzją modułową, dopóki natywne OPC nie będzie stabilne na docelowej wersji.

Jeśli Twoja finalizacja zamówienia jest obecnie słaba, nie spędzaj miesięcy na czekaniu. Rozsądny plan, który nic nie kosztuje w kontekście zakładu o natywne OPC:

• Utrzymuj obecną finalizację zamówienia stabilną i szybką.
• Unikaj niestandardowych nadpisań rdzenia w kontrolerze zamówienia, utrudniają każdą przyszłą migrację finalizacji zamówienia.
• Aktualizuj moduły płatności i przewoźników, aby były gotowe na to, czego będzie wymagał nowy kontrakt.
• Testuj natywne OPC na kopii stagingowej od razu, gdy PrestaShop opublikuje wersję możliwą do przetestowania.
• Nie zakładaj, że każda poprawka motywu albo personalizacja finalizacji zamówienia przetrwa migrację bez zmian.

Jeśli chcesz uzyskać korzyści konwersyjne z jednostronicowej finalizacji zamówienia na swojej obecnej wersji, zamiast czekać, właściwą drogą jest moduł. Nasz moduł Checkout Revolution zamienia krokową natywną finalizację zamówienia w prawdziwy jednostronicowy proces w PrestaShop od 1.6 do 9, konfigurowany z panelu administracyjnego, bez zmian w rdzeniu i bez chirurgii w motywie, więc przetrwa aktualizacje. Co konkretnie to daje? Wszystkie sekcje na jednym ekranie, sumę aktualizowaną na żywo po wpisaniu adresu, zakupy jako gość jako domyślną ścieżkę oraz walidację inline, która wychwytuje błędny e-mail już podczas pisania. Przebudowaliśmy go od podstaw dokładnie do tego zadania. Historia jest opisana w Checkout Revolution 3.0, a jeśli porównujesz opcje, warto zestawić ją z naszym przeglądem modułów procesu finalizacji zamówienia i alternatyw.

Co powinni przygotować deweloperzy modułów i motywów

Deweloperzy powinni śledzić to uważniej niż sprzedawcy, ponieważ jednostronicowa finalizacja zamówienia zmienia gdzie i kiedy dane są dostępne. Zmiany adresu, odświeżanie przewoźników, akceptacja regulaminu, błędy walidacji, sumy koszyka, opcje płatności i pola niestandardowe mogą teraz pojawić się w tym samym cyklu życia ekranu, zamiast na osobnych stronach kroków.

Pierwsze rzeczy, które warto przetestować, gdy pojawi się używalny pakiet:

• Renderowanie i walidacja opcji płatności w kontekście jednej strony.
• Reakcje modułów przewoźników na zmiany adresu na żywo (klasyczne miejsce, w którym założenia procesu krokowego potrafią się wysypać).
• Każdy hook finalizacji zamówienia, który zakłada istnienie oddzielnych kroków.
• Niestandardowe pola adresu i pola B2B.
• Nadpisania szablonów finalizacji zamówienia w motywie.
• Obsługa błędów po nieudanej płatności albo nieudanej walidacji adresu.
• Finalizacja zamówienia jako gość i finalizacja po zalogowaniu, testowane osobno.

Szybki sposób na ocenę dzisiejszej ekspozycji to przeszukanie motywu i modułów pod kątem hooków oraz szablonów finalizacji zamówienia, których dotykają, na przykład wyszukanie actionCheckoutBuildProcess, paymentOptions i hooków procesu przewoźnika w katalogach modules oraz themes, a także wszelkich nadpisań checkout/_partials, payment.tpl, shipping.tpl lub address-form.tpl. To powie Ci, co przetestować ponownie, gdy stabilne natywne OPC będzie dostępne. Jest to lista kontrolna dla stagingu, a nie gwarancja kompatybilności.

rg -n "actionCheckoutBuildProcess|paymentOptions|PaymentOptionsFinder|displayPaymentReturn" modules themes
find themes \( -path "*/checkout/_partials/*" -o -name "payment.tpl" -o -name "shipping.tpl" -o -name "address-form.tpl" \) -print

Nasze podejście

Natywne OPC sprawia, że PrestaShop staje się bardziej konkurencyjny od razu po instalacji, i warto patrzeć na to z ostrożnym optymizmem. Realistyczny scenariusz nie brzmi „natywne OPC zabije moduły finalizacji zamówienia”. Bardziej prawdopodobne jest to, że PrestaShop otrzyma lepszą domyślną finalizację zamówienia, a wyspecjalizowane moduły nadal będą rozwiązywać zaawansowane potrzeby, których domyślne rozwiązanie nie obejmie: ekspresową finalizację/portfele, procesy B2B, niestandardowe reguły płatności, złożony UX, starsze wersje PrestaShop oraz przepływy specyficzne dla danego sprzedawcy. Nawet perfekcyjna finalizacja zamówienia traci część koszyków, dlatego e-maile o porzuconych koszykach i szersze strategie ograniczania porzuceń koszyka pozostają ważne niezależnie od tego, z jakiej finalizacji korzystasz.

Na razie traktuj natywne OPC w PrestaShop 9.2 jako coś, do czego warto się przygotować i co trzeba przetestować na stagingu. Nie jako coś, na co można ślepo czekać, gdy zamówienia uciekają z finalizacji, którą masz dzisiaj.

FAQ

Czy natywna jednostronicowa finalizacja zamówienia w PrestaShop 9.2 została już faktycznie wydana?

Nie. W połowie 2026 roku jest w aktywnym rozwoju, flaga funkcji OPC została scalona z rdzeniem (PR #40796), a moduł ps_onepagecheckout istnieje publicznie, ale jego własne repozytorium opisuje go jako intensywnie rozwijany. Wydanie 9.2 jest obecnie planowane na drugą połowę 2026 roku, a „planowane” nie znaczy „wydane”. Traktuj tę datę jako orientacyjną i testuj na stagingu, gdy pojawi się używalna wersja, zamiast czekać z niedziałającą finalizacją zamówienia na produkcji.

Czy moje obecne moduły płatności i przewoźników będą działać z natywnym OPC?

Z założenia powinny, natywne OPC korzysta ze standardowego wykrywania opcji płatności PrestaShop, więc istniejące moduły płatności pozostają częścią procesu, zamiast być omijane. Haczyk polega na tym, że wszystko spotyka się teraz na jednym ekranie naraz, dlatego moduły przewoźników reagujące na zmiany adresu na żywo i moduły płatności renderowane w kontekście jednej strony to dokładnie te miejsca, w których założenia procesu krokowego mogą się złamać. Zaplanuj ponowne testy na stagingu, zamiast zakładać, że wszystko przejdzie bez zmian.

Czy natywna jednostronicowa finalizacja zamówienia oznacza płatność jednym dotknięciem bez przekierowań?

Nie, i to jest najczęstsze nieporozumienie. Natywne OPC łączy cztery bramki przed płatnością w jeden ekran, ale moduł płatności nadal może przekierować klienta do bramki, hostowanej strony, kroku 3D Secure albo potwierdzenia bankowego. To normalne zachowanie e-commerce, nie wada. Zamiana samej płatności w akcję jednym dotknięciem to inna funkcja, ekspresowa finalizacja zamówienia/portfele, opisana w artykule ekspresowa finalizacja zamówienia.

Używam PrestaShop 1.7 albo 8.x, czy dostanę natywne OPC?

Nie bez aktualizacji. Natywne OPC jest budowane dla wersji 9.2, więc sklepy na 1.7, 8.x, 9.0 albo 9.1 nie otrzymają go, dopóki nie przejdą na to wydanie, a aktualizacje dotykające finalizacji zamówienia należą dokładnie do tych, które większość sprzedawców odkłada. Jeśli chcesz mieć jednostronicową finalizację zamówienia na obecnej wersji już teraz, właściwą drogą jest moduł, taki jak Checkout Revolution, który działa na PrestaShop od 1.6 do 9.

Jako deweloper, jakiej jednej rzeczy powinienem dziś unikać?

Unikaj niestandardowych nadpisań rdzenia w kontrolerze zamówienia. To zmiany, które najczęściej utrudniają późniejszą migrację finalizacji zamówienia, ponieważ natywne OPC wstrzykuje swój proces przez hook actionCheckoutBuildProcess, a nie przez kontroler. Trzymanie własnych modyfikacji w modułach i hookach, oraz przeszukanie motywu i modułów pod kątem hooków oraz szablonów finalizacji zamówienia, których dotykają, znacznie lepiej przygotuje Cię na moment, gdy pojawi się stabilna wersja.