Natywny One Page Checkout w PrestaShop 9.2: co robi i kiedy potrzebujesz więcej

Jak działa

• To osobny moduł. Checkout jest dostarczany z 9.2 jako ps_onepagecheckout i może być aktualizowany niezależnie od samego PrestaShop, więc sprawdź w swoim sklepie zarówno wersję rdzenia, jak i wersję modułu.
• Jest wyłączony, dopóki go nie włączysz. Świeża instalacja 9.2 zachowuje klasyczny checkout w czterech krokach. Układ jednostronicowy wybierasz w Design > Checkout i możesz w każdej chwili wrócić.
• Wymaga 9.2. Moduł deklaruje PrestaShop 9.2.0 jako minimum. Sklepy na 1.7, 8, 9.0 lub 9.1 nie mogą go zainstalować.
• Podłącza się do rdzenia, a nie go omija. Moduł dostarcza własny proces checkoutu przez hook actionCheckoutBuildProcess, zamiast nadpisywać kontroler zamówienia, i zastępuje cztery klasy kroków (dane osobowe, adresy, dostawa, płatność) jednym połączonym krokiem.
• Strona odświeża się sekcjami. Klient-gość jest tworzony, gdy e-mail i wymagane zgody są poprawne, formularz adresu przebudowuje się po zmianie kraju, a przewoźnicy i opcje płatności odświeżają się w miarę uzupełniania adresu. Opcje płatności nadal pochodzą ze standardowego mechanizmu wykrywania opcji płatności w PrestaShop.
• Logowanie i rejestracja mają własne strony. Klasyczny checkout pozwala kupującemu ustawić hasło i założyć konto w trakcie zamawiania. One Page Checkout zamiast tego linkuje do osobnych stron logowania i rejestracji. Kupujący jako goście tego nie zauważą; sklep, który liczy na zakładanie kont w momencie zakupu, owszem.

Moduł ma wciąż wersję poniżej 1.0, a jego README nadal ostrzega przed używaniem go w sklepach produkcyjnych. Wydanie 0.6.6 dodało hook displayExpressCheckout nad formularzem checkoutu, walidację kodu pocztowego dla gości i kolejność pól adresu zależną od kraju. Przeczytaj informacje o wydaniu wersji, którą planujesz uruchomić.

Zanim go włączysz

• Motyw. Ogłoszenie PrestaShop mówi, że checkout jest zbudowany dla motywów opartych na Hummingbird. Classic nie jest domyślnie obsługiwany i może być konieczne nadpisanie części szablonów modułu.
• Moduły płatności i przewoźników. Istniejące hooki zostają zachowane, więc wiele modułów pojawia się bez zmian. Ale wszystko renderuje się teraz na jednym ekranie i odświeża sekcjami, więc przetestuj każdy moduł płatności i przewoźnika na testowej kopii sklepu, zwłaszcza przewoźników wyceniających według kodu pocztowego i moduły płatności renderujące własne znaczniki.
• Płatność wciąż może opuścić stronę. Jednostronicowy formularz usuwa kroki przed płatnością. Weryfikacja karty z 3D Secure, hostowana strona płatności czy potwierdzenie w banku nadal mogą przenieść kupującego gdzie indziej i z powrotem.
• Kody rabatowe. Pole kuponu pojawia się dopiero, gdy twój sklep ma co najmniej jedną regułę koszyka, bo PrestaShop wyłącza całą funkcję reguł koszyka, gdy nie ma żadnej. Puste pole w sklepie testowym to nie błąd.
• Inny moduł checkoutu. Jeśli działa już moduł zastępujący checkout, najpierw przeczytaj jego instrukcje przełączania i zależności. Nie nakładaj na siebie dwóch zamienników checkoutu, dopóki nie potwierdzisz, że mogą działać razem.
• Własny kod checkoutu. Poproś programistę o listę tego, co zmienia szablony checkoutu, pola, wybór płatności lub przewoźnika, w tym skryptów powiązanych ze starymi znacznikami kroków i wyborem punktów odbioru. Przeszukanie kodu pokazuje, co sprawdzić; pasujący hook lub nazwa pliku nie dowodzą konfliktu.

Decyduj w odniesieniu do swojej obecnej konfiguracji: zapisz dokładne wersje PrestaShop i PHP, motyw i jego wersję, wersje modułów płatności i przewoźników, własne reguły checkoutu i podłączone systemy. Najpierw wypróbuj zmianę na testowej kopii sklepu. Wykonaj kopię zapasową plików i bazy danych, złóż zamówienie bazowe w obecnym checkoucie, a następnie przełącz układ bez jednoczesnych innych zmian motywu czy płatności. Powtórz te same zamówienia i porównaj powstałe rekordy, a nie zrzuty ekranu:

• Gość i powracający klient, na telefonie i komputerze, w tym z osobnym adresem do faktury, jeśli z niego korzystasz.
• Koszyk z kuponem lub promocją na dostawę: wpisz adres, wybierz przewoźnika, a następnie zmień kraj na inny, do którego sprzedajesz. Dostawa, podatek, promocja i opcje płatności muszą się przeliczyć przed płatnością.
• Płatności udane, odrzucone i anulowane, 3D Secure oraz płatność potwierdzona po zamknięciu przeglądarki przez kupującego, z użyciem narzędzi testowych operatora.
• Powstałe zamówienie, identyfikator płatności, e-mail z potwierdzeniem i zmiana stanu magazynowego oraz każdy podłączony eksport do realizacji lub księgowości. Jeśli korzystasz z przycisków ekspresowych, przetestuj osobno każdy włączony punkt wejścia, w tym kombinacje produktów, ilości i istniejący koszyk.
• Wymagane pola dla klientów firmowych i reguły płatności dla grup klientów jako osobne przypadki: udane zamówienie gościa ich nie obejmuje.

Wstrzymaj wdrożenie, jeśli suma na ekranie różni się od kwoty wysłanej do operatora płatności lub zapisanej w zamówieniu. Używaj testowych danych dostępowych płatności, kieruj e-maile ze środowiska testowego do testowej skrzynki i wyłącz produkcyjne eksporty do realizacji i księgowości.

Przed przełączeniem produkcji wykonaj świeżą kopię zapasową plików i bazy danych, zapisz obecną konfigurację i potwierdź procedurę wycofania przetestowaną na środowisku testowym. Powrót to jedno ustawienie, ale nie cofa płatności. Zanim rozważysz odtworzenie bazy danych, zachowaj i uzgodnij zamówienia oraz transakcje u operatora przyjęte od wykonania kopii. Po przełączeniu produkcji porównaj ukończone zamówienia, nieudane płatności i zgłoszenia do obsługi z punktem odniesienia przy porównywalnym ruchu i ofertach, osobno dla telefonów i komputerów. Zachowaj tę samą definicję rozpoczęcia checkoutu w obu układach. Układ jednostronicowy nie gwarantuje wzrostu konwersji.

Czy natywny checkout ci wystarczy?

To dobry wybór domyślny, jeśli masz 9.2, używasz Hummingbird lub motywu potomnego opartego na Hummingbird i masz standardowy checkout B2C: kilku przewoźników, popularne metody płatności i zakupy bez rejestracji jako normę. W takim przypadku przetestuj go na środowisku testowym, zanim kupisz moduł. Uruchom go na produkcji dopiero wtedy, gdy wybrana wersja jest udokumentowana jako odpowiednia do użytku produkcyjnego i przechodzi twoje uzgodnione scenariusze zamówień.

Szukaj dalej, gdy potrafisz wskazać wymaganie, którego nie spełnia, na przykład jeśli:

• twój sklep działa na PrestaShop od 1.6 do 9.1, a aktualizacja nie jest planowana w najbliższym czasie;
• chcesz przycisków portfeli cyfrowych na stronach produktu i koszyka, a nie tylko w checkoucie. Natywny moduł daje modułom płatności miejsce na przyciski ekspresowe, ale sam ich nie dostarcza;
• chcesz, żeby kupujący zakładali konto w trakcie zamawiania;
• polegasz na własnych polach checkoutu, regułach B2B lub ograniczeniach płatności według grupy klientów. Najpierw spisz te reguły (kto może płacić na fakturę z odroczonym terminem, gdzie musi pojawić się numer zamówienia zakupu, jak zaakceptowana oferta staje się zamówieniem), a przed przełączeniem sprawdź, czy moduły, które je zapewniają, działają w procesie jednostronicowym.

Czy warto na niego czekać?

• Masz już 9.2: kod jest dostępny, ale ostrzeżenie w README pozostaje powodem, by poczekać z użyciem na produkcji. Biorąc pod uwagę status modułu poniżej 1.0 i ostrzeżenie w README, utrzymuj działający checkout na produkcji, dopóki przetestowana przez ciebie wersja nie przejdzie twoich zamówień na środowisku testowym.
• Masz 9.0 lub 9.1: natywny checkout pojawi się wraz z aktualizacją do 9.2. Zaplanuj tę aktualizację na podstawie jej własnych przesłanek (motyw, moduły, PHP) i przetestuj checkout w jej ramach. Jeśli obecny checkout działa, czekanie na tę aktualizację jest rozsądne.
• Masz 1.6, 1.7 lub 8: przejście na 9.2 wymaga planu migracji opartego na istniejących modułach, integracjach, motywie i danych. W przypadku starszych lub mocno dostosowanych sklepów zwykle bezpieczną ścieżką jest czysty sklep 9.2 na środowisku testowym, przećwiczona migracja danych i zaplanowane przełączenie; przeprowadzi cię przez to lista kontrolna migracji do PrestaShop 9. Nie zmieniaj wersji głównej wyłącznie dla układu checkoutu.
• Tracisz zamówienia teraz: nie czekaj. Odtwarzalny błąd płatności lub znany punkt porzuceń wymaga diagnozy już dziś, a nowy układ nie naprawi błędu płatności.

Jeśli nie wiesz, w którym miejscu kupujący rezygnują, PrestaShop B2C Conversion & Revenue Audit analizuje ścieżkę zakupu klienta detalicznego i daje uszeregowany plan poprawek, bez instalowania czy zmieniania czegokolwiek.

Checkout Revolution zapewnia checkout na jednej stronie i okno ekspresowego checkoutu także w PrestaShop od 1.6 do 9.1, w tym reguły pól i płatności według grupy klientów i kraju oraz zaakceptowane oferty dla firm, które stają się zamówieniami. Express Checkout dodaje okno zakupu Stripe (karty, portfele i metody lokalne) na stronach produktów, listach lub w koszyku obok istniejącego checkoutu i oferuje opcjonalny checkout na jednej stronie, który obejmuje twoje pozostałe moduły płatności i wysyłki. Szersze możliwości porównuje nasz poradnik checkoutu.

Gdy już wybierzesz moduł, PrestaShop Module Installation & Configuration Service instaluje i konfiguruje jeden istniejący moduł oraz sprawdza dotkniętą ścieżkę, z udokumentowanymi krokami wycofania zmian.