Finalizacja zakupów w PrestaShop: konfiguracja, płatności i diagnoza

Jak byśmy do tego podeszli

To, która zmiana pomoże, zależy od istniejącego sklepu: jego wydania PrestaShop, motywu, modułów płatności i przewoźników, własnego kodu zamówień oraz integracji magazynowych, księgowych lub dostawy, które otrzymują jego zamówienia. Ustal, jakie dane klientów, adresów i zamówień otrzymuje każda z tych integracji. Prześledzilibyśmy nieudany zakup od koszyka do potwierdzenia zamówienia na tej konkretnej kombinacji, jako nowy odwiedzający i jako powracający klient. Porównaj każde ograniczenie z regułą, którą sklep zamierzał stosować, zanim uznasz je za błąd, a następnie najpierw napraw potwierdzone błędy konfiguracji lub integracji. Zmieniaj układ, gdy dowody wskazują na mylące pola lub nawigację; zmieniaj integrację płatności, gdy brakuje wymaganej metody lub operacji płatniczej.

Przy zmianach konfiguracji finalizacji zakupów i modułów: odtwórz problem na kopii testowej sklepu odizolowanej od prawdziwych płatności, e-maili do klientów i realizacji zamówień; zmieniaj jedną warstwę naraz; przećwicz spisane scenariusze zakupowe; a następnie przełącz w zaplanowanym czasie, mając kopię zapasową plików i bazy danych, przetestowaną drogę powrotu i plan uzgodnienia zamówień złożonych w międzyczasie. Proces zakupowy, który już spełnia potrzeby, pozostaje bez zmian. Jeśli prace nad finalizacją zakupów są częścią szerszej przebudowy sklepu, zwykle bezpieczną ścieżką jest czysty sklep docelowy na środowisku testowym, przećwiczona migracja wymaganych danych sklepu i zaplanowane przełączenie po przetestowaniu modułów i integracji.

Jeśli przyczyna utraconych zamówień jest niejasna, PrestaShop B2C Conversion & Revenue Audit bada wyszukiwanie produktów, koszyk, finalizację zakupów, płatność i potwierdzenie, zaczynając od telefonu, i dostarcza uszeregowany plan poprawek bez instalowania czy zmieniania czegokolwiek; wdrożenie jest osobną usługą.

Poznaj proces finalizacji zakupów

W PrestaShop 1.7.8 i 9.1 kontroler zamówienia buduje cztery logiczne kroki: dane osobowe, adresy, dostawę i płatność. Koszyk zawierający tylko produkty wirtualne pomija dostawę. Przegląd koszyka i potwierdzenie zamówienia są osobnymi częściami ścieżki. Jeden URL finalizacji nadal może obejmować kilka kroków, żądań i przekazań do płatności.

Powracający klient może mieć już zapisane dane. Motyw lub moduł zakupowy może zmieniać prezentację. Policz przejścia między dokumentami i żądania w tle w przeglądarce, zanim opiszesz sklep jako proces cztero- lub pięciostronicowy.

PrestaShop 9.2 zawiera natywny moduł ps_onepagecheckout. Trzeba go włączyć i skonfigurować, zanim ujednolicony proces zakupowy stanie się aktywny. Zakupy wieloetapowe pozostają dostępne. Aktualna dokumentacja natywnego procesu zakupowego wyjaśnia integrację.

Traktuj osobno cztery wybory: układ procesu zakupowego, integrację płatności, konto u dostawcy, które za nią stoi, oraz sposób pomiaru ścieżki.

Zanim zastosujesz jakiekolwiek instrukcje, zapisz zainstalowane wydanie PrestaShop, wersję PHP, motyw oraz wersje modułu finalizacji zakupów i modułu płatności, a następnie sprawdź, co obsługują te konkretne wydania. Oceniaj natywne opcje finalizacji zakupów i moduły zewnętrzne razem; stara mapa drogowa nie jest instrukcją konfiguracji.

Dopasuj objaw do następnego działania

Zanim cokolwiek zmienisz

1. Spróbuj dokonać tego samego zakupu na telefonie jako nowy odwiedzający i jako powracający klient. Zanotuj, gdzie trzeba ponownie wprowadzać dane lub gdzie błąd sprawia, że następny krok jest niejasny.
2. Oddziel nawigację od nierozstrzygniętych decyzji. Późno pokazana opłata za dostawę, nieodpowiedni przewoźnik lub brak metody płatności wymagają osobnej poprawki, nawet na jednej stronie.
3. Napisz jeden scenariusz odbioru dla danej przeszkody: typ klienta, koszyk, miejsce dostawy, metoda płatności i oczekiwany wynik. Użyj go do porównania obecnego procesu zakupowego z każdą proponowaną alternatywą.

Na przykład opcja płatności może pojawiać się dla krajowego klienta detalicznego, ale znikać, gdy kupujący wybierze inny kraj, zaloguje się na konto firmowe lub wybierze konkretnego przewoźnika. Porównaj ten kontekst koszyka z zamierzonymi regułami płatności, zanim obwinisz układ. Metoda włączona w panelu dostawcy może być nadal niedostępna przez zainstalowaną integrację.

Jeśli integracja korzysta z obu, powrót przeglądarki z uwierzytelnienia w banku i powiadomienie serwerowe od dostawcy są osobnymi ścieżkami dowodowymi. Niedziałająca strona powrotu nie dowodzi, że płatność się nie udała, a brak strony potwierdzenia nie dowodzi, że zamówienie nie istnieje. Porównaj status, kwotę, walutę i identyfikator u dostawcy z rekordem w sklepie; płatności autoryzowane, oczekujące, pobrane i zakończone mogą wymagać różnej obsługi.

Przydatne zgłoszenie do wsparcia zawiera koszyk, typ i grupę klienta, rynek i walutę, urządzenie, czas błędu ze strefą czasową, identyfikator koszyka lub zamówienia, zanonimizowany identyfikator transakcji u dostawcy, kroki odtworzenia i dokładny komunikat. Poproś programistę o zestawienie dowodów z przeglądarki i serwera. Przed udostępnieniem logów lub zrzutów ekranu usuń dane dostępowe, dane płatnicze i zbędne dane klientów.

Wybierz ścieżkę zakupową po określeniu luki

Zachowaj zainstalowany natywny proces, jeśli spełnia wymagania, i zachowaj istniejącą integrację płatności, jeśli zapewnia potrzebne metody i obsługę zamówień. Nie kupuj modułu dlatego, że jego nazwa brzmi szybciej: jedna strona nadal może zawierać każdą wymaganą decyzję, a portfel może ograniczyć wpisywanie danych bez rozwiązania kwestii dostawy czy opcji produktu.

Checkout Revolution umieszcza dane kontaktowe, adres, dostawę, płatność, kupony i podsumowanie zamówienia na jednej stronie, w jednej, dwóch lub trzech kolumnach, z wybraną przez Ciebie kolejnością sekcji oraz wyborem, które pola są wyświetlane lub wymagane. Pojawiają się w nim Twoi dotychczasowi przewoźnicy i metody płatności, powracający klient nie wpisuje ponownie adresu, reguły płatności mogą zależeć od sklepu, języka, grupy klientów, kraju, urządzenia i wartości zamówienia, a zaakceptowana oferta klienta biznesowego może stać się zamówieniem bez ponownego wprowadzania danych. Zawiera też okno szybkiego zakupu na stronach produktów, listach i w koszyku.

Express Checkout łączy adres, dostawę, płatność i potwierdzenie w jednym oknie na stronach produktów, listach lub w koszyku. Płatności obsługuje Stripe, bez opłaty miesięcznej i z prowizją od transakcji, dla kart, portfeli i metod lokalnych; porównaj te warunki osobno od tego, czy ścieżka zakupu pasuje do sklepu. Wybierasz miejsca przycisków, wymagane pola adresu i dostępność płatności według grupy odbiorców, kraju i waluty. Ceny dostawy aktualizują się na bieżąco, wykluczone kombinacje płatności i przewoźnika są odrzucane, a pełne lub częściowe zwroty wykonuje się z ekranu zamówienia. Opcjonalna finalizacja zakupów na jednej stronie obejmuje Twoje pozostałe moduły płatności i wysyłki.

W obu przypadkach płatność ukończona po zamknięciu przeglądarki nadal staje się zamówieniem. Żaden z opisów produktów nie obiecuje zapisanych kart ani nie wymienia konkretnego portfela, takiego jak Apple Pay czy Google Pay, więc przed zakupem potwierdź każde takie wymaganie dla danego wydania i swojego konta płatności. Żadna z nazw produktów nie przesądza o zgodności z Twoim własnym kodem: uwzględnij w wymaganiu nadpisania procesu zakupowego, dodatkowe pola, integracje magazynowe lub księgowe i reguły B2B.

Jeśli wybór wymaga testów, PrestaShop Module Selection & Fit Assessment porównuje dla jednego wymagania natywne ustawienia, posiadane produkty, dostawców i rozwój na zamówienie, testuje kandydatów na kontrolowanej kopii sklepu oraz obejmuje konfigurację, dostosowanie wizualne i wdrożenie wybranego gotowego modułu; licencje są płatne dodatkowo, a rozwój na zamówienie wycenia się osobno. Jeśli masz już wybrany moduł, PrestaShop Module Installation & Configuration Service instaluje i konfiguruje jeden istniejący moduł w uzgodnionym zakresie i sprawdza dotkniętą ścieżkę; licencje, dodatkowe moduły i prace programistyczne są płatne osobno.

Wybierz zakupy wieloetapowe, na jednej stronie lub osadzone

PrestaShop 1.6 miał ustawienie typu procesu zamówienia. Przebudowany proces 1.7 nie używał tego starego przełącznika. W 1.7, 8 i 9.0/9.1 alternatywny pełny układ zakupowy wymaga odpowiedniego modułu lub własnej implementacji. PrestaShop 9.2 dostarcza natywne OPC, więc oceń tę dostępną opcję przed zleceniem zamiennika.

Natywne OPC nie ogranicza się kategorycznie do Hummingbird. Motywy pochodne Classic i własne mogą integrować się z jego kontraktem szablonów i JavaScript. Postępuj zgodnie z poradnikiem zgodności motywów i przetestuj zainstalowany zestaw.

Złożone zamówienia firmowe, produkty regulowane, personalizacja i kilka opcji wysyłki mogą wymagać przemyślanego grupowania. Proste zamówienia mogą pasować do widoku ujednoliconego. Przy produkcie o wysokiej wartości, takim jak zegarek za 2000 €, zadbaj o czytelny końcowy przegląd. Wybierz układ na podstawie wymagań dotyczących zamówień i testów użyteczności: sensownym celem jest mniej zbędnych kroków przy wciąż widocznym do sprawdzenia poprawnym zamówieniu, a nie mniejsza liczba stron.

Checkout Revolution realizuje finalizację zakupów na jednej stronie oraz procesy ekspresowe i w oknie modalnym; zobacz pomoc Checkout Revolution. Sprawdź podsumowanie zamówienia i przyciski zatwierdzania na szerokościach komputera i telefonu.

Unikanie edycji kodu PrestaShop może ograniczyć utrzymanie, ale nie gwarantuje przyszłej zgodności. Przechowuj zmiany motywu potomnego w kontroli wersji i testuj aktualizacje z modułami przewoźników i płatności.

Mierz zdarzenia i diagnozuj porzucenia

Zapisuj przejścia z koszyka do finalizacji zakupów, ukończenie finalizacji, nieudane płatności, czas ukończenia i wartość zamówienia. Określ, czy ukończenie oznacza utworzenie zamówienia, czy potwierdzenie płatności. Stosuj tę samą definicję przez całe porównanie i rejestruj według niej ścieżki zwykłe, ekspresowe i z przekierowaniem, aby portfel lub okno modalne nie wypadły z sum. Gdy wolumen na to pozwala, dziel wyniki według urządzenia, typu klienta, kraju i metody płatności.

To zdarzenia e-commerce Google, a nie po jednym zdarzeniu na każdy natywny krok interfejsu. Aby odróżnić rezygnację przy danych osobowych od rezygnacji przy adresie, rejestruj jawne wyświetlenia kroków, przesłania, wyniki walidacji i zdarzenia ukończenia. Nie wysyłaj do analityki imion, nazwisk, adresów e-mail, adresów ani danych płatności.

Sprawdź każde zdarzenie w przeglądarce i narzędziach debugowania analityki, w tym przesłanie danych wysyłki i płatności, koszyki wirtualne i ponowienia. Dla integracji Google Analytics GA4 skorzystaj z pomocy modułu.

Używaj opinii klientów, maskowanych nagrań sesji zgodnych z uzyskaną zgodą i błędów przeglądarki, aby badać spadki. Wyjście na etapie dostawy może dotyczyć kosztu, niedostępnych przewoźników, terminu dostawy lub usterki technicznej. Miejsce w lejku nie dowodzi motywu kupującego. Ustalaj priorytety potwierdzonych błędów i możliwości według objętego ruchu, kosztu i oczekiwanego wpływu.

Ankiety o przyczynach porzuceń mogą podsuwać pytania. Nie mierzą Twojego lejka PrestaShop ani nie przewidują wzrostu po zmianie, a uniwersalny cel ukończenia czy okres zwrotu nie istnieje: porównuj z własnym punktem odniesienia. Wybierz schemat porównania i wielkość próby na podstawie punktu odniesienia, efektu, który musisz wykryć, i zmienności ruchu. Kontroluj promocje, sezonowość i strukturę ruchu. Popularność portfela bez zmiany łącznej konwersji nie dowodzi kanibalizacji.

Dla ilustracji wzrost ukończenia z 30% do 31% jest względnym wzrostem o około 3,33%. Przychód zmienia się w tej samej proporcji tylko przy stałej liczbie rozpoczętych finalizacji i średniej wartości zamówienia. To obliczenie, nie prognoza.

Korzystaj z zapisów koszyków bez wymyślania lejka

PrestaShop trwale zapisuje koszyki. Sekcja Zamówienia > Koszyki pomaga je sprawdzać, ale wiersz koszyka nie dowodzi rozpoczęcia finalizacji zakupów. Wybierz właściwy prefiks tabel i ID sklepu. Poniższy przykład tylko do odczytu liczy niedawno utworzone, obecnie niepuste koszyki i podzbiór powiązany z obecnie ważnym zamówieniem.

SELECT COUNT(*) AS nonempty_carts,
       SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) AS carts_with_valid_order,
       ROUND(100.0 * SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) / NULLIF(COUNT(*), 0), 1) AS cohort_ratio_pct
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart);

To współczynnik kohortowy przejścia niepustego koszyka do obecnie ważnego zamówienia. Nie jest konwersją finalizacji zakupów. Nowsze koszyki miały mniej czasu na konwersję, oczekujące zamówienia mogą stać się ważne później, a jeden koszyk może utworzyć wiele zamówień. EXISTS zapobiega wielokrotnemu liczeniu koszyka.

Zdefiniuj porzucenie przez próg bezczynności i politykę zamówień. Ten drugi przykład używa 24 godzin bez aktualizacji koszyka jako przykładowego progu i wyklucza każdy koszyk z dowolnym zamówieniem, także nieopłaconym.

SELECT CASE
         WHEN c.id_carrier > 0 THEN '3 - carrier value stored'
         WHEN c.id_address_delivery > 0 THEN '2 - delivery address stored'
         ELSE '1 - neither value stored'
       END AS stored_state,
       COUNT(*) AS inactive_nonempty_carts
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 24 HOUR)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart)
  AND NOT EXISTS (SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart)
GROUP BY stored_state
ORDER BY stored_state;

Odczytuj etykiety etapów dosłownie. Zapisane adresy i przewoźnicy mogli zostać przywróceni lub przypisani automatycznie; to tylko heurystyki. Zapytanie nie rozróżni rozeznania, przerwania, ruchu botów ani nieudanego zakupu. Zastosuj udokumentowane wykluczenia botów i uzgodnij wyniki z danymi zdarzeń. Osobno śledź odzyskiwanie nieopłaconych zamówień, jeśli taki jest cel.

Skonfiguruj zakupy bez rejestracji i pola konta

1. Otwórz Parametry sklepu > Ustawienia zamówień i sprawdź Włącz zakupy bez rejestracji. W nowoczesnych wersjach odpowiada to PS_GUEST_CHECKOUT_ENABLED. Zapisz przez panel we właściwym kontekście sklepu.
2. Przetestuj nową sesję gościa i powracające konto. W natywnym procesie zakupowym zakupy bez rejestracji sprawiają, że hasło jest opcjonalne. Logowanie pozostaje dostępne.
3. Osobno sprawdź prośby o datę urodzenia, formy grzecznościowe i dodatkowe pola klienta. Tryb B2B steruje określonymi polami konta klienta; nie usuwa uniwersalnie pól firmy ani VAT z adresów.
4. Sprawdź format adresu, kod pocztowy i wymagania stanu lub regionu każdego kraju docelowego w Międzynarodowe > Lokalizacje > Kraje. Wymagania adresowe i przewoźników muszą odpowiadać realizacji zamówień.

Możesz sprawdzić wiersze konfiguracji bez ich zmiany:

SELECT id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name = 'PS_GUEST_CHECKOUT_ENABLED';

Adres e-mail zamówienia nie jest zgodą na marketing. Zaproponuj osobną, odpowiednią zgodę. Śledzenie zamówienia może używać natywnego procesu śledzenia zamówień przez gościa. Natywne przekształcenie gościa w zarejestrowanego klienta jest jawnym procesem; włączenie zakupów bez rejestracji nie instaluje automatycznej rejestracji po zakupie. Przetestuj obsługę e-maila istniejącego konta zamiast obiecywać zduplikowane konta lub automatyczne kierowanie wiadomości.

Konta mogą obsługiwać ograniczony dostęp B2B, zarządzanie usługami cyklicznymi i dane programu lojalnościowego. Decyduj na podstawie tych wymagań: przy sprzedaży konsumenckiej sprawdź, czy wymóg założenia konta nie tworzy zbędnej przeszkody; przy sprzedaży firmowej ustal, którzy kupujący muszą mieć zatwierdzone konta lub dane firmy. Zmiana dostawcy płatności nie rozstrzyga tych reguł dotyczących kont. Natywne pobieranie produktów wirtualnych może korzystać z chronionych linków dla gości; sprzedaż produktu do pobrania sama w sobie nie wymaga logowania na zarejestrowane konto.

Pozwól edytować adres dostawy i adres rozliczeniowy niezależnie. Proś o numer telefonu, jeśli wymaga go usługa dostawy. Zachowuj poprawne znaki międzynarodowe i wyjaśniaj błędy pól bez czyszczenia już wypełnionych pól. Zanim usuniesz wymagane pole, z którym klienci mają problem, ustal, dlaczego jest wymagane.

Testuj etykiety i komunikaty błędów w każdym języku sklepu, w tym komunikaty modułów płatności, pola adresowe właściwe dla kraju i podlinkowane warunki. Przetłumaczony motyw nie dowodzi, że każdy komunikat modułu lub dostawcy jest przetłumaczony: gdy francuska finalizacja zakupów pokazuje angielski błąd adresu, ustal, czy generuje go motyw, moduł czy dostawca, zanim zdecydujesz, gdzie go przetłumaczyć. Niewidoczne wymagane pole województwa lub niejasny błąd kodu pocztowego może zatrzymać zakup, zanim zacznie się płatność. Szerszą konfigurację językową opisuje poradnik tłumaczeń i sprzedaży międzynarodowej.

Szeroko zakrojone testy procesów zakupowych Baymard Institute pokazują, jak często sklepy pomijają oba te punkty: 98% witryn nie stosuje konkretnych komunikatów o błędach, a 62% nie eksponuje zakupu bez rejestracji jako najbardziej widocznej opcji. Badania UX Baymard dotyczące checkoutu wyjaśniają dowody stojące za tymi zaleceniami.

Pokaż koszty, oczekiwane terminy dostawy i warunki zwrotów

Pokazuj znane ceny, podatki i opłaty za dostawę wcześnie. Oznacz szacunek jako szacunek, gdy ostateczny adres lub przewoźnik nie są jeszcze znane. Skonfiguruj podatki, wyświetlanie cen dla grup klientów i przewoźników dla obsługiwanych miejsc docelowych; konfigurację przewoźników i koszty dostawy opisuje poradnik wysyłki. Wysyłka > Preferencje zapewnia progi darmowej wysyłki; komunikat o brakującej kwocie wymaga renderowania przez motyw lub moduł.

Na przykład kupujący oczekujący 40 € może zmienić zdanie, gdy suma wzrośnie do 49 €. Pokaż dodatkową opłatę i jej podstawę przed ostatecznym złożeniem zamówienia. Niższa cena i wcześniejsze wyjaśnienie rozwiązują różne problemy.

Podawaj realistyczne informacje o czasie przygotowania przesyłki przez przewoźnika i czasie transportu. Estimated Delivery Date dostarcza terminy wysyłki lub doręczenia; zobacz pomoc Estimated Delivery Date. Do kosztów wysyłki używaj osobno przetestowanego kalkulatora cen lub jasnej polityki cen dostawy.

Ułatw znajdowanie rzeczywistej polityki zwrotów i kontaktu na stronach produktu i koszyka. Przełącznik zwrotów towarów steruje procesem technicznym. Nie tworzy ani nie usuwa praw ustawowych i nie uzasadnia reklamowania 30-dniowych zwrotów, jeśli ich nie oferujesz. Sprawdź właściwe zasady odstąpienia i wyjątki.

Poznaj portfele ekspresowe i warunki wyświetlania przycisków

Portfele mogą dostarczać zapisane dane kontaktowe i tokenizowane dane płatnicze. Pełna integracja ekspresowa może zbierać adresy, oferować obsługiwane opcje wysyłki i aktualizować sumy w swoim procesie. Klient nadal może musieć potwierdzić dane, wybrać dostawę, zaakceptować warunki lub się uwierzytelnić. Płatność portfelem na ostatnim etapie nie omija automatycznie wcześniejszych formularzy.

Zakupy ekspresowe są ścieżką użytkownika, a nie wymogiem użycia Payment Request API przeglądarki. Integracje mogą używać interfejsów portfeli, SDK dostawcy, okien modalnych lub przekierowań. Mogą zbierać osobne dane rozliczeniowe i dostawy. Zachowaj zwykłą ścieżkę zakupową dla nieobsługiwanych przeglądarek, miejsc docelowych i wymagań zamówienia.

Przyciski mogą pojawiać się na stronach produktów, w koszykach, minikoszykach lub finalizacji, zależnie od integracji i renderowanych hooków. Przetestuj, czy ekspresowy zakup ze strony produktu opłaca wybraną pozycję, cały istniejący koszyk czy nowo utworzony koszyk. Mierz wartość koszyka i ukończenie zamiast zakładać, że Kup teraz obniża wartość zamówienia.

1. Potwierdź włączenie metody płatności dla Twojego konta sprzedawcy, kraju, waluty i kwoty koszyka.
2. Zarejestruj każdą odpowiednią nazwę hosta finalizacji zgodnie z wymaganiami operatora, w tym właściwe domeny osadzonych płatności.
3. Sprawdź HTTPS, certyfikaty, uprawnienia iframe oraz błędy konsoli i sieci przeglądarki.
4. Sprawdź aktualną macierz przeglądarek operatora i skonfigurowany portfel lub metodę płatności klienta.
5. Sprawdź ograniczenia modułu i obsługiwane miejsca wyświetlania. Możliwości dostawcy nie dowodzą, że moduł je obsługuje.

Obsługa przeglądarek zależy od portfela i integracji. Sprawdź macierz zakupów ekspresowych Stripe i wskazówki zakupowe Apple, aby poznać aktualne urządzenia i opcje autoryzacji.

Jeśli operator wymaga pliku powiązania, to sprawdza tylko dostępność:

curl -I https://example.com/.well-known/apple-developer-merchantid-domain-association

Pomyślna odpowiedź nie dowodzi rejestracji domeny ani dostępności portfela. Obsługiwana bramka płatności może już zapewniać przyciski ekspresowe; osobny moduł przyspieszający to inna opcja. Zobacz pomoc Express Checkout.

Scenariusz koszyka, który ujawnia błędne działanie

Kupujący ma już w koszyku filtr, wybiera na stronie produktu kombinację z wkładem i naciska przycisk zakupu ekspresowego. Twoja specyfikacja musi określać, czy ta akcja kupuje sam wkład, istniejący koszyk, czy oba po przejrzeniu. Pokaż zawartość przed płatnością i sprawdź, co zostaje w koszyku potem; etykieta przycisku nie przesądza o działaniu modułu.

Powtórz test z pozostawioną pustą wymaganą personalizacją, a następnie z wypełnioną: szybka ścieżka musi egzekwować te same wymagania produktu co główny proces zakupowy. Jeśli dla miejsca docelowego nie ma odpowiedniego przewoźnika, klient potrzebuje wyjaśnienia i możliwości zmiany adresu lub koszyka przed zapłatą.

Oddziel zapisane płatności od składania zamówienia jednym kliknięciem

Token płatności wielokrotnego użytku, znany klient, aktualny adres, możliwa do ustalenia dostawa, poprawny kontekst podatkowy i ważna zgoda mogą skrócić ponowny zakup. Przed obciążeniem sprawdź ponownie stany, ceny, dostawę i wymagane opcje. Pozostaw dane płatnicze u dostawcy i przechowuj tylko identyfikatory klienta oraz metody płatności dostawcy potrzebne integracji. Nie przechowuj surowych numerów kart ani CVV w PrestaShop.

Na przykład Anna ponownie zamawia kawę z zapisanym adresem i kartą. Jej kolejne zamówienie może wymagać niewielu danych, ale zmieniona cena wysyłki lub uwierzytelnienie w banku może dodać krok. Gdy wysyła kolejną paczkę na adres znajomej, dostępność dostawy i sumę trzeba sprawdzić ponownie. Przydatna szybka finalizacja zakupów pozwala jej poprawić adres lub ukończyć weryfikację w banku, a następnie pokazuje jasny wynik zamówienia; nie utrzymuje liczby kliknięć, po cichu używając starych informacji. Odwiedzający po raz pierwszy również może mieć skonfigurowany portfel, nawet gdy Twój sklep nie ma jeszcze rekordu tego klienta, więc oceniaj obie ścieżki według poprawności danych i ukończonego zakupu, a nie historii rejestracji.

Rozpoznanie zalogowanego klienta to coś innego niż zgoda i techniczna możliwość ponownego użycia metody płatności. Wpis w książce adresowej lub wcześniejsze udane zamówienie nie oznaczają, że kolejne zamówienie można obciążyć, a zapisanie adresu nie zapisuje karty. Zapytaj dostawcę integracji, gdzie przechowywane są dane wielokrotnego użytku, jak klient je wybiera i jak może zmienić ten wybór.

Klient, który aktywnie kupuje, korzysta z procesu zapisanej płatności on-session. Off-session oznacza obciążenie inicjowane przez sprzedawcę pod nieobecność klienta. Nie oznaczaj interaktywnego obciążenia w procesie zakupowym jako off-session tylko po to, by uniknąć uwierzytelnienia. Obsługuj wymagane uwierzytelnienie i wyniki asynchroniczne zgodnie z integracją dostawcy i zapytaj dostawcę, jak obsługiwane są potwierdzenie przez klienta, zgoda na zapisaną płatność i wyzwanie uwierzytelniające.

1. Przelicz i sprawdź koszyk na serwerze.
2. Potwierdź autoryzację klienta przez obsługiwany proces dostawcy.
3. Zweryfikuj zaufany wynik płatności, kwotę, walutę i powiązanie koszyka.
4. Utwórz lub zaktualizuj zamówienie PrestaShop idempotentnie. Obsłuż zdublowane wywołania zwrotne i ponowienia.
5. Uzgodnij końcowy stan: opłacony, nieudany, oczekujący lub zwrócony.

Fragment tworzący PaymentIntent nie realizuje całego cyklu zamówienia. Metody offline też mogą uprościć składanie zamówienia bez tokenizacji karty, ale powstałe zamówienie nadal może być nieopłacone i wymagać uzgodnienia przelewu lub płatności przy odbiorze. Nie można zagwarantować dosłownej liczby dotknięć ani zakupu bez uwierzytelnienia.

Wybierz integracje płatności i rozwiązuj ich problemy

ps_checkout, PrestaShop Checkout, jest integracją płatności, a nie nazwą całego procesu zakupowego. Obsługuje opcje płatności, autoryzację i pobranie środków, transakcje oraz zwroty przez obsługiwaną integrację PayPal. Sprzedawca łączy konto PayPal Business. Przejrzyj warunki rozliczeń i wypłat dla połączonego konta sprzedawcy.

Dołączenie modułu zależy od dystrybucji i daty. Sprawdź zainstalowany moduł i obsługiwane wydanie. Korzystaj z oficjalnego repozytorium modułu dla dokumentacji oraz oficjalnego poradnika transakcji dla stanów płatności. Istnieją oficjalne ścieżki rozwiązywania problemów konta i wsparcia; stosuj opublikowane warunki.

Do instalacji, konfiguracji początkowej i usuwania używaj oficjalnej dokumentacji PrestaShop Checkout. Przed wyłączeniem dowolnego dostawcy potwierdź dostępność innej działającej ścieżki płatności.

Możesz ocenić Stripe, Mollie, PayPal, Adyen, Amazon Pay oraz dedykowane integracje płatności ratalnych, takie jak Klarna, Alma czy Clearpay/Afterpay, pod kątem swoich wymagań. Sprawdzaj konkretny moduł PrestaShop, a nie liczbę metod w całym katalogu dostawcy. Porównaj obsługę autoryzacji, zwroty, spory, rozliczenia, waluty, warunki kwalifikacji konta, płatności cykliczne, raportowanie i wsparcie. Wybór i obsługę metod dokładniej opisuje poradnik płatności.

Możliwe metody regionalne do zbadania to iDEAL dla Holandii, Bancontact dla Belgii, BLIK lub Przelewy24 dla Polski, SEPA lub płatności na fakturę dla Niemiec i Austrii, Cartes Bancaires lub raty dla Francji, Bizum dla Hiszpanii, Satispay lub MyBank dla Włoch i otwarta bankowość dla Wielkiej Brytanii. To przykłady do analizy, nie obietnice dostępności w module. Nie planuj nowych integracji wokół wycofanych samodzielnych SOFORT lub Giropay. Sprawdź aktualną dokumentację metod dostawcy.

Porównaj rzeczywiste opłaty dla swojego podmiotu prawnego, metody, pochodzenia karty, waluty, przewalutowania, nieudanych płatności, zwrotów i sporów. Darmowy moduł nadal może wiązać się z kosztami przetwarzania. Przelew bankowy pozwala uniknąć opłaty bramki kartowej, ale może generować opłaty bankowe i ręczne uzgadnianie. Sprawdź wpływ środków przed realizacją zamówienia; zobacz natywny moduł przelewu bankowego.

Dla każdej metody z opóźnionym rozliczeniem określ, kiedy zamówienie można zrealizować i kto potwierdza wpływ środków: potwierdzenie zamówienia nie jest dowodem, że płatność dotarła, więc uwzględnij tę pracę pracowników przy uzgadnianiu w swoim wyborze. Jeśli przyjmujesz przelewy na kilka rachunków lub w kilku walutach, Bank Transfer Accounts pokazuje klientom rachunek dla waluty ich zamówienia wraz z kwotą i numerem zamówienia na stronie potwierdzenia, w e-mailu z instrukcjami i na stronie szczegółów zamówienia; wpływ środków nadal potwierdzasz i zamówienie aktualizujesz samodzielnie.

Pytania do dostawcy płatności i dostawcy modułu

• Czy każda wymagana metoda jest dostępna dla naszego podmiotu prawnego, rynków klientów, walut i wydania modułu?
• Gdzie pracownicy znajdą identyfikatory transakcji, uzgodnią wypłaty i obsłużą pełne lub częściowe zwroty?
• Kto obsługuje błędy integracji, ograniczenia konta i spory płatnicze oraz jakich materiałów będzie potrzebować wsparcie?
• Gdzie po zmianie są obsługiwane i rejestrowane zwroty dla zamówień przyjętych przez poprzedni moduł?

Brak dostępnej metody płatności

1. Sprawdź aktywne moduły i ograniczenia Płatność > Preferencje dla waluty, kraju, grupy i przewoźnika.
2. Sprawdź dane dostępowe dostawcy, stan konta, limity kwot i tryb produkcyjny lub testowy.
3. Sprawdź faktycznie zwrócone opcje, logi PHP i błędy przeglądarki.
4. Sprawdź rzeczywiste nagłówki odpowiedzi, jeśli skrypty są blokowane. Nie zakładaj, że standardowy PrestaShop 8/9 ma uniwersalną politykę CSP procesu zakupowego powodującą błąd.

Nowoczesne integracje płatności powinny implementować paymentOptions. PrestaShop 1.7.8 i 9.1 odczytuje też ścieżki zgodności displayPaymentEU i advancedPaymentOptions. Samo wyszukanie starej nazwy hooka nie diagnozuje niewidoczności. Ograniczenia dostępności różnią się od kolejności: sprawdź pozycję paymentOptions w Wygląd > Pozycje oraz kolejność wewnątrz modułu płatności.

Testuj dynamiczną dostawę, rabaty i wymagania B2B

Zmiana kraju, kodu pocztowego, ilości lub produktu może zmienić przewoźników, podatki, dostępność płatności i sumę. Zachowuj nadal poprawne wybory, widocznie usuwaj nieprawidłowe i blokuj zatwierdzenie podczas przeliczania. Testuj rzeczywiste koszyki ciężkie, wirtualne, mieszane i wielopaczkowe.

Dla ilustracji produkt 0,5 kg plus produkt 25 kg daje 25,5 kg. Przekracza to hipotetyczny limit przewoźnika 20 kg, ale nie przekracza 30 kg. Inne wymiary, strefy i ograniczenia nadal mogą wykluczać przewoźnika. To przykładowe limity, nie opublikowane warunki przewoźników.

Reguły koszyka mają priorytety, zasady łączenia, ograniczenia klientów i produktów, daty oraz limity użycia. Niełącząca się reguła 20% i osobna reguła darmowej wysyłki wymagają przetestowanej konfiguracji zgodności. Kupon o stałej wartości 10 € może kolidować z automatyczną regułą 15%. Warunki kwalifikacji i działanie rabatu to różne ustawienia.

Kwota minimalna reguły koszyka korzysta z sum produktów z wybranymi ustawieniami podatku i waluty oraz z wysyłki, jeśli tak skonfigurowano. Obniżki cen konkretnych produktów już wpływają na te sumy. W PrestaShop 9.1 obliczenie odejmuje też odpowiednie prezenty z reguł już znajdujących się w koszyku. Przetestuj próg 100 € na kwalifikującym się koszyku i na koszyku tuż poniżej progu, z przecenionymi produktami, produktami w prezencie, przewalutowaniem oraz z wysyłką uwzględnioną i nieuwzględnioną.

Przećwicz też jeden przypadek łączony. Koszyk ma automatyczny rabat na produkt, klient wpisuje kupon i powinna zadziałać promocja na dostawę. Najpierw zapisz zamierzony wynik: które rabaty się łączą, którzy przewoźnicy się kwalifikują i jaka jest końcowa kwota do zapłaty. Powtórz po zmianie ilości, przewoźnika i kraju dostawy oraz porównaj widoczne podsumowanie, kwotę wysłaną do dostawcy i rekord zamówienia. Odrzucony kupon powinien zostawić jasne wyjaśnienie i działającą drogę do płatności.

Ograniczenia przewoźników reguły darmowej wysyłki muszą odpowiadać zamierzonym opcjom. Profiluj wolną ocenę reguł przed usuwaniem historycznych; daty wygaśnięcia już wpływają na kwalifikację. Zachowuj konfigurację według potrzeb operacyjnych.

Kompaktowy przycisk „Masz kod?” może ograniczyć nadmiar elementów, zachowując możliwość użycia kuponów. Stosowanie kodu promocyjnego musi używać przetestowanego procesu koszyka z obsługą tokenów. Sam URL addDiscount=1&discount_name=SUMMER10 nie zawsze wystarcza, zwłaszcza dla uwierzytelnionych klientów. Sprawdzaj kwalifikację na rzeczywistym koszyku.

Dla B2B określ osobne adresy rozliczeniowe i dostawy, dane firmy, numery zamówień zakupu, zatwierdzanie kont i uzgodnione terminy płatności. Ważny numer VAT jest tylko częścią rozliczenia transgranicznego VAT; warunki dostawy i dokumentacja również mają znaczenie. Odróżniaj niedostępność VIES od wyniku nieważnego. Sprawdź unijne wytyczne VAT transgranicznego.

Dodatkowe pola potrzebują pełnego cyklu życia: wyświetlenia, walidacji, zapisu i udostępnienia tam, gdzie są potrzebne w zamówieniach, eksportach lub fakturach. Numer zamówienia zakupu jest przydatny tylko wtedy, gdy jest walidowany, przechowywany z zamówieniem i widoczny dla pracowników lub eksportu, które go potrzebują; instrukcje dostawy muszą trafić do realizacji. Wyświetlenie pola w szablonie nie jest pełną implementacją. Rozszerzenia formularza klienta mogą używać additionalCustomerFormFields i validateCustomerFormFields; poradnik hooków i nadpisań wyjaśnia, jak moduły się do nich podłączają. Samo actionValidateOrder nie zrealizuje formularza.

Ten hook tworzenia zamówienia działa wewnątrz PaymentModule::validateOrder(), przed późniejszą obsługą statusu. Może działać dla zamówień oczekujących lub offline. Sprawdzaj status płatności i potwierdzenie w przeglądarce osobno od tego hooka. Do działań płatniczych, magazynowych i e-mailowych używaj odpowiednich wywołań zwrotnych dostawcy i obsługi statusów zamówienia.

Zapewnij wygodną ścieżkę na telefonach

Używaj analityki kategorii urządzeń z działającymi zdarzeniami zakupu. Starszy raport Przeglądarki i systemy operacyjne jest raportem zgodności, nie nowoczesnym lejkiem przychodów mobilnych. Intencja ruchu, struktura pozyskania, zakupy między urządzeniami i luki śledzenia również mogą wyjaśniać różnice urządzeń.

Classic pozostaje częsty w starszych i aktualizowanych sklepach. Hummingbird stał się domyślny dla nowych instalacji PrestaShop 9.1. Ani etykieta responsywności, ani nowy motyw nie gwarantują braku przepełnienia, wygodnych klawiatur czy dostępnych modułów.

• Używaj type="email" i autocomplete="email" dla e-maila oraz type="tel" z autocomplete="tel" dla telefonu.
• Dla kodów pocztowych używaj pól tekstowych. Dodawaj inputmode="numeric" tylko dla liczbowego formatu wybranego kraju. Formaty brytyjskie, holenderskie i kanadyjskie wymagają liter.
• Używaj odpowiednich tokenów autouzupełniania nazw i adresów. Sprawdzaj rzeczywiście wygenerowane pola. Nowoczesny formularz adresowy używa customer/_partials/address-form.tpl i wspólnego renderowania pól, a nie założonego pliku pól w szablonach częściowych finalizacji.
• Używaj dużych, oddalonych od siebie kontrolek i w pełni opisanych wierszy przewoźnika i płatności. Obszar od 44 do 48 pikseli CSS to praktyczna opcja projektowa; sprawdzaj rozmiar i odstępy na rzeczywistych urządzeniach.
• Zapewnij łatwy dostęp do aktualnej sumy i przeglądu zamówienia. Przyklejone przyciski zatwierdzania nie mogą zasłaniać warunków, błędów, czatu ani ustawień zgody.
• Zachowuj wpisane wartości, widoczny fokus i konkretne komunikaty błędów przy polach.

W pozostałej części mobilnego sklepu stosuj rozwijanie menu dotknięciem z linkami nadrzędnymi, wygodny panel filtrów, czytelne informacje o produktach i zamykane okna popup. Zachowuj ważną treść i dane strukturalne w wersji mobilnej. Używaj responsywnych rozmiarów obrazów i leniwego ładowania poniżej pierwszego ekranu bez opóźniania obrazu głównego.

Linki telefoniczne mogą pomóc na urządzeniach mobilnych i w obsługiwanych aplikacjach telefonicznych komputerów. Ostatnio oglądane produkty i przyklejone dodawanie do koszyka to opcje do przetestowania w zainstalowanym motywie lub module, a nie uniwersalne funkcje natywne. Porównuj wyjścia z kategorii, odkrywanie produktów i zakupy obok ukończenia finalizacji.

Profiluj żądania zakupowe na odizolowanej kopii testowej. Możliwe wąskie gardła to hooki modułów, zewnętrzne wywołania stawek, podatków i adresów, wybór przewoźników, reguły koszyka, zapytania bazy i praca skryptów. Używaj _PS_DEBUG_PROFILING_ tylko tam, gdzie wyniki debugowania są prywatne. Włączaj produkcyjne buforowanie i opcje zasobów dopiero po przetestowaniu wynikowego procesu płatności. Wyklucz spersonalizowane odpowiedzi koszyka, finalizacji i JSON ze współdzielonej pamięci całych stron/CDN.

Używaj aktualnych PageSpeed Insights/Lighthouse, Search Console i testów na rzeczywistych urządzeniach. Stary Google Mobile-Friendly Test został wycofany. Testuj warunki sieci komórkowej, obsługiwane telefony, autouzupełnianie włączone i wyłączone, zmiany kraju, każdą oferowaną metodę płatności, anulowanie uwierzytelnienia i ponowienia. Zwężone okno komputera nie testuje prawdziwej klawiatury ani portfela.

Przywracaj koszyki i badaj błędy ich aktualizacji

Zalogowani klienci mogą odzyskiwać użyteczne otwarte koszyki zgodnie z zachowaniem koszyka przy logowaniu w sklepie. Odzyskiwanie gościa opiera się głównie na pliku cookie przeglądarki identyfikującym koszyk. Usunięcie plików cookie, zmiana urządzenia lub sesje prywatne mogą zerwać to powiązanie, choć wiersz bazy nadal istnieje. Koszyki z zamówieniem nie są już otwartymi koszykami.

PS_COOKIE_LIFETIME_FO steruje czasem życia pliku cookie sklepu, nie retencją koszyka w bazie. Znajdź odpowiednie pole czasu życia cookie w administracji swojej wersji i potwierdź wartość we właściwym kontekście sklepu. Ustawienia cookie przenoszono między stronami administracji w różnych wersjach.

1. Odtwórz problem z konkretnym produktem, kombinacją, ilością, klientem i krajem oraz zanotuj nieudany URL i czas. Otwórz Console i Network w narzędziach przeglądarki.
2. Sprawdź żądanie i odpowiedź koszyka. Status 200 nadal może zawierać błąd aplikacji lub HTML zamiast oczekiwanego JSON. Status 500 wymaga logów PHP i serwera; 403 wymaga sprawdzenia tokenu, uprawnień, WAF i zabezpieczeń.
3. Odtwarzaj rzeczywiste żądanie przeglądarki tylko w bezpiecznym kontekście testowym z plikami cookie sesji i aktualnym tokenem. Wymyślony przykład curl ze statycznym tokenem nie jest wiarygodnym testem koszyka.
4. Wyczyść odpowiednie pamięci szablonów i zasobów w Zaawansowane > Wydajność. Tymczasowo wyłącz łączenie zasobów na środowisku testowym, jeśli połączony pakiet utrudnia diagnozę.
5. Sprawdź domenę cookie, HTTPS, zachowanie SameSite/Secure i ewentualne współdzielone przechowywanie sesji przy równoważeniu obciążenia. Zweryfikuj obsługę www i bez www.
6. Sprawdź hooki modułów związane z koszykiem i wyodrębnij konflikty na kopii testowej z kopią zapasową i planem wycofania zmian. Wyłączaj grupy modułów, a następnie zawęź do odpowiedzialnego modułu. Po zmianie ponownie przetestuj callbacki dostawców.

Traktuj ustalenia dotyczące domeny, ciasteczek i modułów jako tropy, dopóki błąd się nie odtworzy, a poprawka go nie usunie. Po poprawce wygeneruj ponownie lub wyczyść odpowiednią pamięć podręczną CDN lub zasobów. Współdzielona pamięć podręczna musi pomijać punkty końcowe koszyka właściwe dla klienta. Błąd JavaScript może zatrzymać dotknięty proces, ale jeden błąd nie dowodzi automatycznie, że przestały działać wszystkie skrypty na stronie.

Zabezpiecz płatności i odzyskuj pozostałe porzucone koszyki

Udostępniaj finalizację zakupów i zasoby dostawcy przez poprawny HTTPS. Sprawdź treści mieszane, adresy powrotu i osiągalność callbacków. Tam, gdzie to właściwe, preferuj pola hostowane przez dostawcę lub hostowaną stronę płatności i trzymaj surowe dane kart poza logami aplikacji i formularzami sklepu. Nie dodawaj własnego kodu, który przesyła surowe dane kart przez Twój sklep.

Zakres PCI zależy od całego wdrożenia. Hostowane iframe lub przekierowania same nie gwarantują kwalifikacji do SAQ A. Dla formularzy osadzonych obecne kryteria SAQ A obejmują potwierdzenie, że strona sprzedawcy nie jest podatna na ataki skryptowe. Potwierdź właściwą ocenę z podmiotem przyjmującym Twoją dokumentację zgodności. Stosuj wytyczne kwalifikacji PCI SSC; nie rozstrzygaj między SAQ A a A-EP na podstawie samej obecności JavaScript dostawcy.

Wymagania silnego uwierzytelniania klienta mają zwolnienia i transakcje poza zakresem. 3D Secure to mechanizm obsługiwany przez integracje kartowe, nie sam przepis. Część transakcji kończy się bez widocznego wyzwania; inne wymagają uwierzytelnienia. Testuj powodzenie, odmowę, anulowanie, przekroczenia czasu i powrót z zewnętrznej strony płatności.

Trwałość koszyka i e-maile przypominające to osobne funkcje. Natywne przechowywanie koszyka nie wysyła automatycznie przypomnień. Odzyskiwanie może zapewnić dedykowane narzędzie lub integracja marketingowa, z zachowaniem obowiązujących zasad komunikacji, zgody lub warunków soft opt-in. Zobacz pomoc Sales Revolution i pomoc Klaviyo Integration.

Przypomnienie może pomóc kupującemu, któremu przerwano lub który chciał więcej czasu. Może też sprowadzić go do tego samego nierozwiązanego błędu. Naprawiaj potwierdzone usterki zakupowe i osobno mierz odzyskiwanie. Przy ocenie zysku uwzględniaj opłaty za wiadomości, rabaty, realizację i koszty obsługi. Respektuj rezygnacje i nie zakładaj, że przypomnienie bez rabatu ma charakter wyłącznie transakcyjny.

Przećwicz ścieżkę zamówienia przed przełączeniem produkcji

Przy zmianach w finalizacji zakupów zachowaj punkt odniesienia z datą i godziną oraz drogę wycofania zmian. Zanim zastąpisz, wyłączysz lub odinstalujesz moduł finalizacji zakupów lub płatności, wykonaj kopię zapasową plików i bazy danych, pracuj na kopii testowej i przetestuj drogę powrotu. Odizoluj środowisko testowe od prawdziwych płatności, e-maili do klientów i realizacji zamówień. Postępuj zgodnie z instrukcją usuwania modułu i zachowaj rekordy oraz dostęp potrzebne do istniejących płatności i zwrotów; co zachować, opisuje poradnik usuwania modułów.

• Nowy klient: zakup jako gość, jeśli jest dostępny, a następnie zakup z rejestracją, na telefonie i komputerze. Sprawdź pola wymagane i osobne dane dostawy oraz rozliczenia.
• Powracający klient: wybór zapisanego adresu, zmiana adresu i każdy proces zapisanej płatności lub portfela, który potwierdził dostawca.
• Produkt i koszyk: kombinacja, wymagana personalizacja i koszyk z kilkoma pozycjami. Potwierdź, że okno zakupu ekspresowego kupuje zamierzoną zawartość.
• Dostawa i sumy: zmień kraj i przewoźnika w trakcie, zastosuj kupon i sprawdź końcowe kwoty podatku i dostawy dla każdego obsługiwanego kraju, waluty i grupy klientów.
• Płatność: powodzenie, odmowa, uwierzytelnienie ukończone i anulowane, opóźnione potwierdzenie, zamknięcie przeglądarki i powtórzone powiadomienie, z użyciem obsługiwanej procedury testowej dostawcy.
• Operacje: sumy, faktury, zmiany stanów magazynowych, e-maile potwierdzające, zwroty, rekordy dostawcy i eksporty do księgowości lub realizacji, w tym każda własna integracja.

Oceniaj każdy scenariusz według tych rekordów, a nie tylko ekranu potwierdzenia. Sprawdź, czy odrzucona płatność lub anulowane uwierzytelnienie pokazuje jasny wynik płatności, zachowuje zamierzony koszyk i pozwala ponowić próbę lub zmienić metodę bez niezamierzonego podwójnego obciążenia. Zapisz oczekiwany stan zamówienia i płatności dla każdej metody: oczekujący przelew i potwierdzona płatność kartą nie powinny mieć tych samych oczekiwań co do realizacji. Jawnie sprawdź zapobieganie duplikatom zamówień: odświeżenie lub ponowne otwarcie strony potwierdzenia nie może tworzyć niezamierzonego drugiego zamówienia ani obciążenia.

Poproś dostawcę o wyniki testów zamiast określeń szybkości

• Która ścieżka korzysta z Twoich obecnych modułów płatności, a która z własnej integracji płatności modułu? Które dokładnie wersje sprawdzono?
• Czy przycisk na stronie produktu kupuje wybraną pozycję, czy cały koszyk, i jak przeglądane są warianty, personalizacja i zmieniony adres?
• Które wymaganie zapisanej płatności lub portfela jest obsługiwane i co dzieje się po odrzuconym lub anulowanym uwierzytelnianiu?
• Jak pracownicy uzgadniają płatność ukończoną po zamknięciu przeglądarki i jak przywracają poprzedni proces zakupowy, jeśli kontrole po uruchomieniu zawiodą?

Poproś agencję o przekazanie wykazu wersji, uzgodnionych scenariuszy zakupowych, dowodów z testów, zapisanej konfiguracji i kroków wycofania zmian oraz o wskazanie, kto po uruchomieniu obsługuje opóźnione płatności, zwroty i monitoring.

Po uruchomieniu uzgadniaj nowe zamówienia z transakcjami u dostawcy. Jeśli konieczne będzie wycofanie, uwzględnij sprzedaż od wykonania kopii zapasowej, zanim odtworzysz bazę danych. Porównuj ukończone opłacone zamówienia, nieudane płatności i zgłoszenia do wsparcia według urządzenia i typu klienta z własnym punktem odniesienia.

Pytania właścicieli sklepów

Czy w PrestaShop możliwy jest zakup jednym kliknięciem?

Jedna akcja może złożyć zamówienie, gdy tożsamość, adres, dostawa i sposób płatności są już ustalone. Procesy zapisanej płatności wymagają obsługi ponownego użycia i zgody klienta; metoda offline może złożyć nieopłacone zamówienie bez zapisanych danych karty. Nawet wtedy zmieniony adres, niedostępny przewoźnik lub prośba banku o uwierzytelnienie dodają krok, więc opisuj proces zakupowy jako szybki, nie obiecując każdemu kupującemu tej samej liczby czynności.

Czy sklep z przewagą nowych klientów powinien dążyć do jednego kliknięcia?

Zacznij od zakupów bez rejestracji tam, gdzie to właściwe, wcześnie pokazanych sum i wygodnego formularza, a następnie przetestuj obsługiwany portfel. Skrót dla powracających klientów niewiele rozwiązuje z tego, z czym mierzą się kupujący po raz pierwszy.

Czy instalacja ps_checkout da nam finalizację zakupów na jednej stronie?

Nie. Dodaje opcje płatności oparte na PayPal do etapu płatności. W 9.2 kwestię układu rozwiązuje natywny moduł jednej strony; we wcześniejszych wydaniach moduł finalizacji zakupów lub prace na zamówienie.

Czy potrzebujemy zarówno Checkout Revolution, jak i Express Checkout?

Zwykle nie. Oba oferują okno zakupu na stronach produktów, listach i w koszyku i oba zamieniają płatność ukończoną po zamknięciu przeglądarki w zamówienie. Wybierz według tego, czy wymaganiem jest jedna strona z Twoimi dotychczasowymi przewoźnikami i metodami płatności, czy okno zakupu oparte na Stripe; żaden z opisów nie potwierdza, że oba działają razem, więc przed włączeniem obu przetestuj tę kombinację na środowisku testowym.