PrestaShop 9.2 dodaje natywny One Page Checkout w wersji beta, czekać czy działać?

Aktualizacja z maja 2026: PrestaShop potwierdził już partnerom, że natywna jednostronicowa kasa zostanie wydana jako moduł rdzenia w PrestaShop 9.2, a sama wersja 9.2 jest obecnie planowana na drugą połowę 2026 roku. Opisaliśmy to ogłoszenie w krótszym wpisie newsowym: natywny One Page Checkout w PrestaShop 9.2.

Tworzymy moduły kasy od czasów PrestaShop 1.6, a przy okazji w pewnym momencie przebudowaliśmy też kasę od zera mniej więcej w połowie sklepów naszych klientów. Dlatego gdy zespół rdzenia PrestaShop ogłosił natywną jednostronicową kasę podczas Live Update 30 lipca 2025, uważnie się temu przyjrzeliśmy. Właściwe prace ruszyły na początku 2026 roku, a pierwsza flaga funkcji trafiła do rdzenia kilka tygodni później.

To jest strona, którą wysyłamy sprzedawcom pytającym nas: „Czy czekać na natywny OPC, czy naprawić kasę już teraz?”. Sprzedajemy Checkout Revolution, więc nie jesteśmy neutralni. Ale sami też prowadzimy sklepy i wolimy, żebyś przeczytał uczciwe porównanie, niż kupił coś, czego nie potrzebujesz.

Trzy wyszukiwania dotyczące kasy, które brzmią podobnie, ale oznaczają trzy różne problemy

Zanim ktokolwiek zacznie cokolwiek porównywać, trzeba rozdzielić te trzy pojęcia. Widzimy, jak mieszają się w zgłoszeniach do wsparcia praktycznie co tydzień.

Natywny OPC PrestaShop to przyszły układ kasy w rdzeniu, nie istnieje jeszcze w stabilnym wydaniu. Checkout Revolution to nasz pełny zamiennik kasy w formie jednostronicowego procesu składania zamówienia dla sprzedawców, którzy nie mogą czekać. Express Checkout to osobny, lżejszy moduł, który dodaje przyciski Apple Pay / Google Pay / PayPal na stronach produktu i koszyka bez ingerowania w istniejącą kasę. To nie są te same produkty, a poniższa tabela porównawcza istnieje dlatego, że ludzie regularnie kupują nie ten moduł, którego naprawdę potrzebują.

Co PrestaShop faktycznie powiedział

Live Update z lipca 2025 potwierdził, że natywny OPC znajduje się w planie rozwoju. Raport Core Monthly z lutego 2026 potwierdził rozpoczęcie prac, a pierwsza flaga funkcji trafiła do pull requestu #40796.

Jeśli czytać PR-y i znaczniki milestone zamiast marketingowych sformułowań, publiczny kod mówi dziś mniej więcej tyle:

• Docelowe wydanie: PrestaShop 9.2 (otwarte PR-y mają milestone 9.2.0, nie 9.1).
• Motyw: widoczne prace są powiązane z nowoczesnym stosem kasy w 9.x. Czy motywy classic lub niestandardowe dostaną czystą ścieżkę aktualizacji, dowiemy się dopiero z informacji o wydaniu 9.2.
• Architektura: hybrydowa. AJAX do inicjalizacji gościa i odświeżania formularza adresowego; moduły płatności nadal mogą przekierowywać lub korzystać z bramek hostowanych, tak jak robią to dziś.
• Proces gościa: obecny kod podpina prawidłowego klienta-gościa do koszyka przed wysłaniem formularza, co ma sens. Finalny UX nie jest jeszcze zamknięty.
• Tryb awaryjny: istniejąca wieloetapowa kasa pozostaje dostępna jako opcja.
• Wpływ na moduły: autorzy modułów będą musieli dostosować wszystko, co podpina się pod proces składania zamówienia. Zespół rdzenia mówił o tym jasno.

Na moment pisania tego tekstu natywny OPC nie został wydany w żadnej stabilnej wersji. Jest za flagami funkcji i znajduje się w aktywnym rozwoju.

Dlaczego układ kasy naprawdę ma znaczenie

Baymard podaje średni poziom porzuceń koszyka na około 70%. Spora część to zwykłe oglądanie produktów, którego żadna kasa nie uratuje, ale według rozbicia Baymard 18% porzuceń wynika konkretnie z tego, że kasa jest zbyt długa albo zbyt skomplikowana. To właśnie ten obszar może ruszyć układ jednostronicowy.

Mechanizm jest prosty: wszystkie decyzje są przed klientem naraz, bez przeładowań między krokami, bez kręcącego się loadera między „wpisałem adres” a „jakie mam opcje dostawy”. Na desktopie z szybkim łączem oszczędność jest marginalna, sekunda albo dwie. Na mobilnym 4G, gdzie dziś znajduje się ponad połowa ruchu naszych klientów, pięcioetapowa kasa potrafi łatwo dobić do trzech-czterech minut skumulowanego oczekiwania. Jednostronicowy proces sprowadza to poniżej minuty.

Krótszy checkout może usunąć zbędne kroki, ale jego wpływ na porzucenia zależy od sklepu, klientów, metod płatności i kosztów dostawy. Porównaj liczbę ukończonych zamówień i porzuceń przed zmianą i po niej w porównywalnych warunkach, zamiast zakładać stałą poprawę procentową.

Tak nadal wygląda standardowa kasa PrestaShop.

Zrzuty ekranu z prawdziwego sklepu deweloperskiego na PS9, który prowadzimy: dane osobowe, adres, dostawa, płatność, osobne kroki. Natywny OPC jest interesujący dlatego, że zmienia tę strukturę, a nie dlatego, że zmienia sposób działania dostawców płatności pod spodem.

Jednostronicowa kasa pokazuje każdą decyzję w jednym widoku.

Przy porównaniu obok siebie praktyczna różnica jest oczywista: klient nie musi zatwierdzać jednego kroku, zanim dowie się, o co zapyta następny. Dlatego mówimy o jednostronicowej kasie jako o funkcji konwersyjnej, a nie kosmetycznej zmianie motywu.

Nasza uczciwa ocena natywnego OPC

Z PR-ów, raportów core monthly i Live Update wyłania się taki realistyczny obraz.

Gdzie natywny OPC prawdopodobnie będzie świetny

• Bezpłatny. Trafia do rdzenia. Bez licencji, bez subskrypcji, bez klucza per sklep. Dla wielu sklepów już samo to czyni go właściwą odpowiedzią.
• Tworzony przez zespół rdzenia. Będzie czysto osadzony w procesie zamówienia, systemie hooków i warstwie komponentów Hummingbird, bez potrzeby stosowania obejść.
• Utrzymywany razem z samym PrestaShop. Poprawki błędów i łatki bezpieczeństwa będą przychodzić z każdym wydaniem PS. Każdy, kto wspierał zewnętrzny moduł podczas migracji PS 1.7 → 8 → 9, wie, ile to jest warte.
• Nowoczesna architektura. Obecne prace używają AJAX-a tam, gdzie ma to znaczenie (inicjalizacja gościa, odświeżanie adresu), a przekierowania płatności / 3DS / bramki hostowane zostawiają w spokoju, co jest dobrą decyzją.
• Wcześniejsza identyfikacja gościa w procesie. Jeśli implementacja trafi do wydania w szkicowanym kształcie, nie będzie późnych niespodzianek w stylu „chwila, jednak popraw e-mail”, które obecna wieloetapowa kasa czasem nadal potrafi wyświetlić.

Jeśli zaczynasz świeży sklep na PrestaShop 9.2 z Hummingbird, standardową dostawą, standardowymi metodami płatności i bez wymagań B2B. Natywny OPC prawdopodobnie będzie właściwym narzędziem, i tak właśnie powiemy klientom, którzy nas o to zapytają.

Gdzie funkcja natywna w wersji v1 będzie po prostu funkcją natywną w wersji v1

Każde „1.0” funkcji w rdzeniu wychodzi w wąskim zakresie. To nie jest zarzut, tak wydawano pierwsze podejścia w każdym frameworku, z którym kiedykolwiek pracowaliśmy. Uczciwe ograniczenia, które warto uwzględnić w planie:

• Zgodność z motywami jest naprawdę niewiadomą. Publiczne prace są powiązane z nowoczesnym stosem kasy w 9.x. Czy Twój obecny motyw classic lub niestandardowy będzie wymagał nietrywialnej przebudowy, dowiemy się dopiero z finalnych not migracyjnych 9.2. Uwzględnij taką przebudowę w budżecie jako realną możliwość.
• To będzie tylko dla 9.2. Wszystko, co działa na 1.6, 1.7, 8.x, 9.0 albo 9.1, odpada. Jeśli nie aktualizujesz sklepu przed drugą połową 2026 roku, natywny OPC nie jest w tym roku opcją dla Ciebie.
• Brak szybkiej finalizacji zakupu. Natywny OPC to jednostronicowy formularz. Przyciski Apple Pay / Google Pay / PayPal na stronach produktów i w koszyku to zupełnie inna funkcja, patrz sekcja o Express Checkout niżej. Zespół rdzenia nie ogłosił jej jako części zakresu OPC.
• Opóźnienie ekosystemu modułów. Moduły płatności, moduły dostawy, personalizacje przewoźników, moduły kroków kasy. Wszystkie będą wymagały aktualizacji. Po dużej zmianie UX w rdzeniu zawsze istnieje okres przejściowy. Zaplanuj go.
• V1 obejmuje typową ścieżkę. Zarządzanie polami niestandardowymi, logika warunkowa („ukryj metodę dostawy X, jeśli klient jest w kraju Y”), zaawansowana walidacja, ograniczenia płatności w stylu B2B. To nie są funkcje pierwszego dnia w żadnej pierwszej generacji kasy w rdzeniu. Dojrzewają latami.

Jeśli utrzymujesz moduły albo niestandardowy motyw, najpierw uruchom te grepy

„Ładuje się” nie jest testem zgodności. Zanim zdecydujesz się na migrację do natywnego OPC, znajdź każde miejsce, w którym Twoje moduły albo motyw dotykają kasy. Tania wersja to dwa polecenia ripgrep:

rg -n "paymentOptions|displayPayment|actionValidateOrder|actionCarrierProcess|displayBeforeCarrier" modules themes
rg -n "checkout/_partials|order-confirmation|cart-summary|payment.tpl|shipping.tpl" themes modules

Każde trafienie to kandydat do awarii. Widzieliśmy moduły płatności, które przechodziły widoczny smoke test na nowej kasie, ale po cichu wykładały się przy prawdziwym zamówieniu, bo podpinały się pod stare znaczniki, nasłuchiwały starych zdarzeń JS albo polegały na nadpisaniu motywu, którego już nie ma. Zawsze uruchamiaj to najpierw na środowisku stagingowym, nigdy pierwszego dnia z nową kasą na sklepie produkcyjnym.

Co daje dziś dojrzały moduł kasy

To część, w której musimy uważać, bo Checkout Revolution jest nasz.

Co faktycznie dostajesz dziś z dojrzałego, produkcyjnego modułu kasy, używając Checkout Revolution jako punktu odniesienia, bo tego używamy w sklepach naszych klientów:

• Działa na każdej wersji PS, którą nadal wspieramy. Od 1.6 do 9.1, na każdym motywie, na którym go testowaliśmy. Twoja kasa przestaje zależeć od tego, którą wersję PrestaShop akurat zainstalowałeś.
• 30+ metod płatności w jednym module. Apple Pay, Google Pay, PayPal, Klarna, Afterpay, BLIK, Przelewy24, iDEAL, SEPA, Amazon Pay, Link by Stripe i długi ogon metod lokalnych. Jeden moduł do konfiguracji, nie trzydzieści.
• Szybka finalizacja zakupu w trzech miejscach. Przyciski Apple Pay i Google Pay na stronach produktu, w koszyku oraz w wysuwanym mini-koszyku, z uwierzytelnianiem biometrycznym. Klient nie musi w ogóle zobaczyć strony kasy.
• Dostawa w arkuszu Apple Pay / Google Pay. Gdy klient wybiera adres w interfejsie portfela, obliczamy stawki dostawy w czasie rzeczywistym i przekazujemy je z powrotem do arkusza. Bez „następnego kroku” dla dostawy.
• Automatyczne tworzenie adresu. Adresy z portfeli (Apple Pay, Google Pay) są zapisywane bezpośrednio na koncie klienta. Dla tych kupujących nie ma formularza adresowego.
• Funkcje B2B. Konta kredytowe, przepływy ofertowe / RFQ z wyjściem PDF, zarządzanie na poziomie firmy, ograniczenia metod płatności per grupa klientów.
• Analiza ryzyka. Integracja ze Stripe Radar do punktowej oceny transakcji.
• Odzyskiwanie koszyków. Śledzenie porzuconych koszyków synchronizowane webhookami, żeby odzyskiwać sprzedaż, a nie tylko ją liczyć.

To nie jest roadmapa. Działa dziś w sklepach, które sami prowadzimy (modernedusche.de, douchemoderne.fr, blackdeblacks.de), i obsługuje prawdziwe transakcje. Wolimy, żebyś to wiedział i podjął decyzję, niż żebyśmy udawali, że porównujemy rzeczy równorzędne.

Express Checkout: rzecz, którą natywny OPC nie jest

To rozróżnienie ginie w każdej rozmowie w stylu „czy czekać na natywny OPC?”. Jednostronicowa kasa i szybka finalizacja zakupu to nie ta sama funkcja.

Jednostronicowa kasa umieszcza pola adresu, dostawy i płatności na jednej stronie. Klient nadal wpisuje adres, wybiera metodę dostawy i podaje dane płatności. Jest szybciej niż w pięciu krokach, ale to nadal formularz.

Szybka finalizacja zakupu pomija formularz. Klient dotyka przycisku Apple Pay, Google Pay albo PayPal, uwierzytelnia się odciskiem palca lub Face ID, a adres / płatność / preferencja dostawy są pobierane bezpośrednio z jego cyfrowego portfela. Zakup od początku do końca, bez wpisywania ani jednego znaku. Na prawdziwych urządzeniach widzimy, że zamyka się to w trzech do pięciu sekund.

Checkout Revolution zawiera szybką finalizację zakupu w pełnym zamienniku kasy. Express Checkout to lżejszy, osobny moduł, jeśli chcesz tylko przyciski portfeli bez dotykania samej strony kasy. To różne produkty rozwiązujące różne problemy. To nie jest marketingowe hasło, tylko powód, dla którego zostawiliśmy je jako dwa osobne SKU.

Szybka finalizacja zakupu to zupełnie osobna dźwignia konwersji.

Prawdziwa strona produktu PrestaShop, przycisk szybkiej finalizacji obok Dodaj do koszyka. To nie jest „jednostronicowa kasa na stronie produktu”, to inny proces, w którym część klientów całkowicie omija formularz kasy.

• Strona produktu: dotknięcie Apple Pay, uwierzytelnienie Face ID, zamówienie złożone. Bez koszyka, bez kasy, bez formularzy.
• Strona koszyka: przyciski szybkiej finalizacji nad podsumowaniem. Dotknij, uwierzytelnij, gotowe.
• Mini-koszyk: wysuwany panel koszyka też ma przyciski szybkiej finalizacji, klient nie opuszcza strony, którą przeglądał.

Natywny OPC, według każdego publicznego artefaktu, który widzieliśmy, nie obejmuje niczego z tej listy. To lepszy formularz. Szybka finalizacja na stronach produktu i koszyka to funkcja na poziomie modułu i nie spodziewamy się, żeby trafiła do rdzenia w linii 9.x.

Macierz decyzyjna, natywny OPC, Checkout Revolution czy Express Checkout?

Kto powinien czekać, a kto działać teraz

Uczciwa odpowiedź zależy od tego, gdzie jesteś. Staramy się mówić klientom dokładnie to, zanim cokolwiek kupią.

Czekaj na natywny OPC, jeśli:

• Budujesz zupełnie nowy sklep i nie wystartujesz, dopóki PrestaShop 9.2 nie będzie stabilny
• Planujesz używać Hummingbird v2 od pierwszego dnia
• Twoja kasa jest naprawdę standardowa, podstawowa dostawa, popularne metody płatności, brak B2B
• Nie potrzebujesz szybkiej finalizacji zakupu na stronach produktów
• Możesz poczekać, aż moduły płatności, dostawy i kasy zostaną zaktualizowane pod nową strukturę

Jeśli większość z tych punktów jest prawdziwa, oszczędź pieniądze. Natywny OPC będzie dla Ciebie całkiem dobrym rozwiązaniem.

Działaj teraz, jeśli:

• Twój sklep działa i już dziś traci koszyki przez tarcie w kasie
• Jesteś na dowolnej wersji PS od 1.6 do 9.1, i prawdopodobnie nie zaktualizujesz jej w ciągu najbliższych sześciu miesięcy
• Używasz dowolnego motywu innego niż Hummingbird v2, classic, niestandardowego, z 1.7, 8.x
• Chcesz Apple Pay / Google Pay / PayPal na stronach produktu i koszyka
• Potrzebujesz szerokiego pokrycia metod płatności wykraczającego poza karty i PayPal
• Sprzedajesz B2B i potrzebujesz kont kredytowych, ofert albo ograniczeń płatności według grup klientów
• Konwersja ma znaczenie dla Twojego P&L w tym kwartale, nie w 2027 roku

Pragmatyczna ścieżka pośrodku

Dla większości działających sklepów, z którymi pracujemy, odpowiedź brzmi: użyj modułu teraz, oceń natywny OPC ponownie, gdy 9.2 faktycznie wyjdzie. Moduł kasy to nie małżeństwo. Jeśli natywny OPC w 9.2 czysto pokryje Twoje potrzeby, możesz się przełączyć. Czego nie warto robić, to zostawiać konwersji na stole przez sześć do dziewięciu miesięcy, czekając na funkcję, która jeszcze nie została wydana.

A nawet gdy natywny OPC będzie już dostępny, rzeczy, które nasz moduł robi ponad „formularz na jednej stronie” (szybka finalizacja zakupu, długi ogon metod płatności, procesy B2B, wsparcie między wersjami), nie znikną w momencie wydania 9.2.

Najważniejszy wniosek, prosto

Pojawienie się natywnego OPC w rdzeniu to naprawdę dobra rzecz dla PrestaShop. Podnosi bazowy poziom każdego sklepu, który inaczej nie zapłaciłby za moduł kasy, i to jest wygrana, której chcemy.

Ale kasa to strona, na której przy każdym zamówieniu zarabia się albo traci pieniądze, a „pracujemy nad tym na wydanie planowane na drugą połowę 2026 roku” nie jest planem dla sklepu, który już dziś traci koszyki. Jeśli obecna kasa kosztuje Cię sprzedaż, narzędzia do jej naprawy już istnieją, wspierają wersję PrestaShop, na której faktycznie działasz, i obejmują obszary, których żadna funkcja rdzenia w wersji v1 jeszcze nie dotknie. Taki jest kompromis, przedstawiony tak uczciwie, jak potrafimy.

FAQ

Kiedy natywna jednostronicowa kasa trafi do PrestaShop?

PrestaShop potwierdził partnerom, że natywny OPC zostanie wydany jako moduł rdzenia w PrestaShop 9.2, który jest obecnie planowany na drugą połowę 2026 roku. Na moment pisania tego tekstu nie został wydany w żadnej stabilnej wersji. Znajduje się za flagami funkcji i jest aktywnie rozwijany, a otwarte PR-y mają milestone 9.2.0, nie 9.1. Termin z roadmapy to plan, nie data wydania, więc traktuj okno w drugiej połowie 2026 roku jako ruchome.

Czekać na natywny OPC czy naprawić kasę już teraz?

Jeśli budujesz zupełnie nowy sklep, nie wystartujesz przed stabilnym 9.2, planujesz używać Hummingbird od pierwszego dnia, a Twoja kasa jest naprawdę standardowa, bez B2B i bez potrzeby przycisków szybkiej finalizacji, poczekaj i oszczędź pieniądze. Jeśli Twój sklep działa i już dziś traci koszyki przez tarcie w kasie, jesteś na dowolnej wersji od 1.6 do 9.1, używasz motywu classic albo niestandardowego, albo konwersja ma znaczenie dla Twojego P&L w tym kwartale, działaj teraz. Dla większości działających sklepów pragmatyczna odpowiedź brzmi: użyj modułu teraz i oceń natywny OPC ponownie, gdy 9.2 faktycznie wyjdzie. Moduł kasy to nie małżeństwo.

Czy natywny OPC będzie zawierał przyciski Apple Pay i Google Pay na stronach produktów?

Nie, nie według żadnego publicznego artefaktu, który widzieliśmy. Natywny OPC to jednostronicowy formularz, lepszy układ kasy. Szybka finalizacja zakupu (przyciski portfeli na stronach produktu i koszyka, które pozwalają klientowi całkowicie ominąć formularz) to osobna funkcja, której zespół rdzenia nie ogłosił jako części zakresu OPC, i nie spodziewamy się jej w linii 9.x. Jeśli chcesz przyciski szybkiej finalizacji, pozostaje to funkcją na poziomie modułu, samodzielny Express Checkout albo pakietowo w Checkout Revolution.

Czy natywny OPC zadziała z moim obecnym motywem?

Tego naprawdę nie wiadomo, dopóki nie pojawią się informacje o wydaniu 9.2. Publiczne prace są powiązane z nowoczesnym stosem kasy w 9.x, więc nikt nie może jeszcze obiecać, czy motyw classic albo niestandardowy dostanie czystą ścieżkę aktualizacji, czy będzie wymagał nietrywialnej przebudowy. Jeśli planujesz wokół tej funkcji, uwzględnij przebudowę jako możliwość zamiast zakładać instalację „drop-in”.

Jak sprawdzić, czy natywny OPC zepsuje moje moduły?

Nie polegaj na „ładuje się”. Przed migracją znajdź każde miejsce, w którym Twoje moduły albo motyw dotykają kasy, tania wersja to dwa polecenia ripgrep z sekcji wyżej, uruchomione na kopii stagingowej. Każde trafienie dla paymentOptions, actionValidateOrder, actionCarrierProcess albo nadpisania motywu checkout/_partials to kandydat do awarii. Widzieliśmy moduły płatności, które przechodziły widoczny smoke test na nowej kasie, ale po cichu wykładały się przy prawdziwym zamówieniu, bo podpinały się pod stare znaczniki albo nasłuchiwały starych zdarzeń JS. Nigdy nie testuj tego po raz pierwszy na sklepie produkcyjnym.

Powiązane materiały

• Checkout Revolution, nasz pełny moduł jednostronicowej kasy
• Express Checkout, przyciski portfeli bez zastępowania kasy
• Natywny One Page Checkout w PrestaShop 9.2. Co wersja 9.2 konkretnie oznacza dla sprzedawców i deweloperów
• Przewodnik po optymalizacji kasy PrestaShop, konkretne zmiany, które poprawiają współczynnik ukończenia zamówienia, gdy podejmujesz decyzję
• Dlaczego Twoja strona kasy traci sprzedaż, zdiagnozuj wyciek, zanim wybierzesz naprawę
• Noty wydania PrestaShop 9.1, zmiany w Hummingbird i obsłudze wielu przewoźników