Checkout Revolution 3.0: jednostronicowa finalizacja zakupu przebudowana od podstaw
Przebudowaliśmy Checkout Revolution od podstaw. To nie jest dopisanie kilku funkcji do starej bazy kodu, ale świeża architektura. W skrócie: poprzedni moduł ekspresowej finalizacji zakupu i szerszy moduł obsługi finalizacji zamówienia zostały połączone w jeden, cały proces działa teraz w jednym modalu opartym na Stripe Payment Intents API i obsługuje PrestaShop od wersji 1.6 do 9. Ten wpis to szczera inżynierska historia, co naprawdę się zmieniło, dlaczego się zmieniło i co to oznacza dla Twojego sklepu. Jeśli nadal zastanawiasz się, czy finalizacja zakupu na jednej stronie w ogóle ma sens, zacznij od artykułu jednostronicowa finalizacja zakupu dla PrestaShop, a potem wróć tutaj.
Dlaczego przebudowa, a nie kolejne łatanie
Pierwotny moduł powstał według wzorców PrestaShop 1.6, a później był stopniowo dostosowywany do 1.7, 8.x i 9.x. Każda adaptacja dokładała następny warunek do poprzednich, obsługa AJAX, walidacja formularzy i przełączanie metod płatności nadal niosły w sobie decyzje podjęte dla wersji platformy, która ma już wiele lat. W pewnym momencie koszt pracy wokół starej struktury przewyższa koszt jej zastąpienia. Doszliśmy do tego punktu, więc ją zastąpiliśmy.
Włączyliśmy też do tego modułu nasz osobny moduł ekspresowej finalizacji zakupu. Utrzymywanie dwóch nakładających się produktów do obsługi finalizacji zamówienia oznaczało dwa zestawy integracji płatniczych, dwa koszyki i dwa miejsca, w których zmiana w Stripe API mogła coś popsuć. Teraz jest jeden moduł, jeden przepływ koszyka i jeden zestaw kontrolerów sklepowych do utrzymania zgodności między kolejnymi wydaniami PrestaShop. Co to oznacza dla Ciebie? Mniej ruchomych elementów, które mogą wejść w konflikt podczas aktualizacji, i jedno miejsce konfiguracji zamiast dwóch.
Co w praktyce zmieniło „przebudowanie”
Jeden modal zamiast sekwencji stron
Domyślna finalizacja zakupu w PrestaShop. Nawet w 1.7 i nowszych wersjach, gdzie działa pod jednym adresem URL, odsłania się etapami: dane osobowe, potem adresy, następnie dostawa i płatność, a każda sekcja rozwija się dopiero po ukończeniu poprzedniej. (Dokładnie omawiamy, jak działa ten natywny przepływ oraz stojące za nim kontroler order i klasy kroków, w artykule natywna jednostronicowa finalizacja zakupu w PrestaShop.) Checkout Revolution zastępuje tę sekwencję jednym modalem: rejestracja lub dane gościa, adres, wybór dostawy i płatność znajdują się na jednym ekranie, dostępnym ze strony produktu, koszyka albo dowolnej strony sklepu. Klient nie musi odchodzić od tego, co właśnie oglądał, żeby zapłacić.
Oparte na Stripe Payment Intents
Warstwa płatności jest oparta na Stripe Payment Intents API, a nie na starszym przepływie bazującym na obciążeniach. To ta część przebudowy zajęła najwięcej czasu, bo właśnie ona musi działać bezbłędnie, obsługuje 3D Secure / Strong Customer Authentication, asynchroniczne potwierdzanie płatności oraz regionalne metody, które rozliczają się już po opuszczeniu strony przez klienta. Po stronie sprzedawcy oznacza to obsługę portfeli cyfrowych (Apple Pay, Google Pay), kart z możliwością ponownego użycia zapisanej karty przez powracających kupujących, przelewów bankowych oraz płatności „kup teraz, zapłać później”, szeroki zestaw metod przez jedno połączenie ze Stripe, zamiast osobnego modułu dla każdego dostawcy.
Wpisywanie adresu, które mniej przeszkadza
Formularze adresowe są najbardziej żmudną częścią każdej finalizacji zakupu, dlatego przebudowa uderza bezpośrednio w ten problem:
- Autouzupełnianie Google Places, klient zaczyna wpisywać ulicę, a reszta adresu uzupełnia się z podpowiedzi, zamiast ręcznego przechodzenia przez pięć pól.
- Walidacja unijnego numeru VAT przez VIES, klienci B2B podają numer VAT, a moduł sprawdza go w usłudze VIES Komisji Europejskiej, dzięki czemu prawidłowy numer wewnątrzwspólnotowy zostaje poprawnie zastosowany już przy wpisywaniu, zamiast po cichu zawieść później.
- Zakup jako gość jako domyślna ścieżka, z opcją zapisania danych i utworzenia konta po złożeniu zamówienia, klient nigdy nie trafia na blokadę w postaci obowiązkowej rejestracji. Dane pokazujące, dlaczego to ważne, omawiamy w artykule zakup jako gość kontra tworzenie konta.
Logowanie społecznościowe tam, gdzie pomaga
Powracający klienci mogą zalogować się przez Google, Facebooka, Apple albo Microsoft, zamiast przypominać sobie hasło do sklepu, przydatne dla kupującego, który złożył jedno zamówienie osiem miesięcy temu i nie pamięta, że kiedykolwiek zakładał konto. Funkcja jest opcjonalna i domyślnie wyłączona; włącz ją tylko wtedy, gdy pasuje do Twoich odbiorców.
Przeliczanie i walidacja na żywo
Ponieważ wszystko mieści się w jednym modalu, suma zamówienia przelicza się w trakcie działań klienta: wybór kraju aktualizuje opcje dostawy, wybranie przewoźnika zmienia kwotę końcową, a wpisany voucher jest weryfikowany w czasie rzeczywistym względem reguł koszyka, zamiast dopiero po przeładowaniu strony. Ta natychmiastowość odróżnia finalizację zakupu, która reaguje sprawnie, od takiej, która przypomina wysłanie formularza i czekanie z nadzieją.
Jak wypada obok natywnej finalizacji zakupu PrestaShop
Uczciwe pytanie przy każdym module finalizacji zakupu brzmi: dlaczego nie użyć po prostu tego, co dostarcza PrestaShop? Szczera odpowiedź zależy od Twojej wersji i od tego, jak długo możesz czekać.
| Podejście | Co otrzymujesz | Haczyk |
|---|---|---|
| Natywna finalizacja zakupu krok po kroku (PS 1.7–9.1) | Jeden URL, cztery kolejne kroki, zerowy koszt, część rdzenia | Nadal działa etapami; zmiana opcji dostawy oznacza ponowne otwarcie zakończonego kroku |
| Natywna jednostronicowa finalizacja zakupu (PrestaShop 9.2, w trakcie rozwoju) | Prawdziwy przepływ na jednej stronie, bezpłatny w ramach platformy | Jeszcze niewydany, planowany na wydanie 9.2 i wymagający aktualizacji do tej wersji |
| Checkout Revolution | Ekspresowa finalizacja zakupu w jednym modalu dla 1.6–9, portfele Stripe/BNPL, Google Places, VIES, logowanie społecznościowe | Moduł licencjonowany; część płatnicza koncentruje się na Stripe |
To, że PrestaShop buduje natywną jednostronicową finalizację zakupu w wersji 9.2, jest naprawdę dobrą wiadomością dla całego ekosystemu. Funkcja jest w trakcie rozwoju, nie została jeszcze wydana, a to, co obecnie zawiera publiczny kod, omawiamy w artykule natywna jednostronicowa finalizacja zakupu w PrestaShop 9.2. Moduł istnieje dla sklepów, które nie mogą albo nie chcą czekać na to wydanie, działają na starszej wersji, która nigdy tej funkcji nie dostanie, albo potrzebują portfeli Stripe i elementów B2B, których rdzeń nie będzie dostarczał. Jeśli rozważasz szersze kompromisy między finalizacją zakupu krok po kroku a jednym ekranem, omawiamy je w naszym przewodniku po optymalizacji finalizacji zakupu w PrestaShop, a pytanie „moduł czy alternatywy” rozkładamy w artykule moduły procesu finalizacji zakupu i alternatywy.
Zgodność i aktualizacja
Checkout Revolution obsługuje PrestaShop od 1.6 do 9. Wykrywa wersję sklepu i dostosowuje integrację, w 1.7.7+ podpina się pod panel zamówienia w administracji ery Symfony (displayAdminOrderSide), a w starszych sklepach wraca do klasycznego hooka (displayAdminOrderLeft). Dzięki czemu ten sam moduł działa poprawnie zarówno w sklepie na 1.6, jak i w aktualnym sklepie 9.x, bez wybierania osobnej paczki.
Takie dopasowywanie hooków do wersji to detal, który decyduje, czy moduł przetrwa aktualizację PrestaShop, czy po cichu przestanie się renderować. W praktyce oznacza to wybór hooka podczas instalacji na podstawie działającej wersji, zamiast wpisywania jednego na sztywno:
// Register the admin-order panel on the hook the running PS version exposes.
$adminOrderHook = version_compare(_PS_VERSION_, '1.7.7', '>=')
? 'displayAdminOrderSide' // Symfony-era order page (1.7.7+, 8.x, 9.x)
: 'displayAdminOrderLeft'; // legacy order page (1.6–1.7.6)
$this->registerHook($adminOrderHook);Sednem nie są dwie nazwy hooków, chodzi o to, że moduł odczytuje _PS_VERSION_ i się dostosowuje, więc nigdy nie musisz ręcznie dobierać paczki do swojej platformy. Ta sama zasada przechodzi przez kontrolery sklepowe i szablony.
Jeśli używałeś poprzedniego modułu ekspresowej finalizacji zakupu, pamiętaj, że został wycofany i połączony z tym modułem; prefiksy tabel bazy danych są teraz ujednolicone pod mprcheckoutrevolution_. Dotychczasowi użytkownicy Checkout Revolution aktualizują moduł standardowym procesem aktualizacji, a konfiguracja zostaje zachowana. Wygląd finalizacji zakupu się zmienia. Nowy projekt jest czystszy, ale ustawienia są nadzbiorem tego, co udostępniała starsza wersja, więc niczego nie trzeba konfigurować od zera.
Czego celowo nie robi
Uczciwe określenie zakresu jest ważniejsze niż lista funkcji. Funkcje płatności ekspresowych Checkout Revolution opierają się na Stripe: bez Stripe korzyści z portfeli cyfrowych i BNPL nie będą mieć zastosowania, ale jednostronicowy proces, finalizacja zakupu z domyślną opcją gościa i narzędzia adresowe pozostają niezależne od bramki płatniczej. Sam z siebie nie odzyskuje też koszyków porzuconych przed dojściem do finalizacji zakupu; to osobne zadanie dla sekwencji e-maili, zobacz e-maile o porzuconych koszykach i automatyzację, która je wysyła. I żadna finalizacja zakupu, choćby najlepsza, nie naprawi głębszego problemu z konwersją na wcześniejszym etapie lejka; jeśli nie wiesz, gdzie tracisz klientów, najpierw zdiagnozuj to z pomocą artykułu dlaczego Twoja strona finalizacji zakupu traci sprzedaż.
Zmierz to we własnym sklepie
Nie podamy Ci jednej liczby wzrostu konwersji, bo uczciwa wartość zależy w całości od tego, jak trudny jest obecny proces finalizacji zakupu, sklep z obowiązkową rejestracją i natywnym przepływem w czterech krokach ma znacznie więcej do zyskania niż sklep, który już działa lekko. Dlatego zmierz to samodzielnie. Przed przełączeniem zanotuj w analityce cztery liczby: współczynnik konwersji z koszyka do zamówienia, współczynnik porzuceń podczas finalizacji zakupu, średni czas ukończenia finalizacji zamówienia oraz konwersję mobile kontra desktop. Po włączeniu przepływu w jednym modalu porównaj te same cztery wskaźniki przez co najmniej 30 dni i kilkaset zamówień, to wystarczająca skala, żeby odróżnić realny trend od tygodniowego szumu. Szerszy plan ograniczania porzuceń w całym lejku znajdziesz w artykule ograniczanie porzucania koszyków w PrestaShop.
Na tym polega przebudowa: jeden moduł zamiast dwóch, jeden modal zamiast sekwencji kroków, warstwa płatności Stripe obsługująca metody, po które klienci naprawdę sięgają na telefonie, i to samo zachowanie od PrestaShop 1.6 do 9. Zasada się nie zmieniła, mniej bramek, mniej pisania, suma uczciwa od pierwszego ekranu. Architektura pod spodem wreszcie do niej dorosła.
FAQ
Korzystam już ze starego Checkout Revolution, czy aktualizacja zepsuje moją konfigurację?
Nie. Istniejące instalacje Checkout Revolution aktualizują się standardowym procesem aktualizacji modułu, a konfiguracja zostaje zachowana. Nowe ustawienia są nadzbiorem starych, więc niczego nie trzeba ustawiać od zera, ale wygląd finalizacji zakupu zmienia się na czystszy, nowy projekt, dlatego obejrzyj go na kopii testowej przed wdrożeniem na produkcję, żeby wygląd nie był zaskoczeniem.
Używałem waszego osobnego modułu ekspresowej finalizacji zakupu. Co się z nim stanie?
Został wycofany i połączony z Checkout Revolution. Ekspresowa finalizacja zakupu jest teraz częścią tego jednego modułu, a nie drugim produktem. Tabele bazy danych są ujednolicone pod prefiksem mprcheckoutrevolution_. Uruchamianie dwóch nakładających się modułów finalizacji zakupu powodowało konflikty przy aktualizacjach i dublowanie integracji płatniczych, a właśnie to usuwa połączenie.
Czy muszę używać Stripe?
Funkcje portfeli cyfrowych, zapisanych kart i płatności „kup teraz, zapłać później” są zbudowane na Stripe Payment Intents API, więc te konkretne korzyści wymagają połączenia ze Stripe. Jeśli Twój sklep działa wyłącznie na dostawcy bez ścieżki przez Stripe, część dotycząca ekspresowych płatności nie będzie miała zastosowania, a moduł może nie być właściwym wyborem, wolimy powiedzieć to jasno, niż obiecywać za dużo. Przepływ na jednej stronie, zakup jako gość i narzędzia adresowe nie zależą od tego, która bramka się renderuje, ale główne metody płatności już tak.
Działa na PrestaShop od 1.6 do 9, czy wybieram inną paczkę dla swojej wersji?
Nie. To jeden moduł, który podczas instalacji odczytuje wersję PrestaShop i się dostosowuje, na przykład wybiera displayAdminOrderSide w 1.7.7+ oraz klasyczne displayAdminOrderLeft w starszych sklepach. Instalujesz tę samą paczkę niezależnie od tego, czy używasz 1.6, czy aktualnego wydania 9.x.
PrestaShop 9.2 dostanie natywną jednostronicową finalizację zakupu, czy po prostu na nią poczekać?
To zależy od Twojej wersji i harmonogramu. Natywne OPC jest rozwijane dla 9.2, ale nie zostało jeszcze wydane, a do korzystania będzie potrzebny okres stabilizacji oraz aktualizacja do 9.2. Jeśli Twoja finalizacja zakupu słabo konwertuje już dziś i jesteś na 1.6–9.1, czekanie przez jeden lub więcej cykli wydań samo w sobie oznacza koszt w utraconych zamówieniach. Uczciwy zakres natywnej implementacji omawiamy w artykule natywna jednostronicowa finalizacja zakupu w PrestaShop 9.2, żeby można było zdecydować na podstawie faktów, a nie samej roadmapy.