Nativer One Page Checkout in PrestaShop 9.2: was er kann und wann Sie mehr brauchen

So funktioniert er

• Er ist ein separates Modul. Der Checkout wird mit 9.2 als ps_onepagecheckout ausgeliefert und kann unabhängig von PrestaShop selbst aktualisiert werden. Prüfen Sie daher in Ihrem Shop sowohl die Core-Version als auch die Modulversion.
• Er ist aus, bis Sie ihn aktivieren. Eine frische 9.2-Installation behält den klassischen Checkout in vier Schritten. Das einseitige Layout wählen Sie unter Design > Checkout und können jederzeit zurückwechseln.
• Er braucht 9.2. Das Modul gibt PrestaShop 9.2.0 als Mindestversion an. Shops auf 1.7, 8, 9.0 oder 9.1 können es nicht installieren.
• Er klinkt sich in den Core ein, statt ihn zu umgehen. Das Modul liefert seinen eigenen Checkout-Prozess über den Hook actionCheckoutBuildProcess, statt den Bestell-Controller zu überschreiben, und ersetzt die vier Schrittklassen (persönliche Daten, Adressen, Versand, Zahlung) durch einen einzigen kombinierten Schritt.
• Die Seite aktualisiert sich abschnittsweise. Ein Gastkunde wird angelegt, sobald E-Mail und erforderliche Einwilligungen gültig sind, das Adressformular wird neu aufgebaut, wenn sich das Land ändert, und Versanddienste und Zahlungsoptionen aktualisieren sich, während die Adresse vervollständigt wird. Die Zahlungsoptionen kommen weiterhin aus der Standard-Ermittlung von Zahlungsoptionen in PrestaShop.
• Anmeldung und Registrierung liegen auf eigenen Seiten. Im klassischen Checkout kann ein Käufer beim Bestellen ein Passwort festlegen und ein Konto anlegen. Der One Page Checkout verlinkt stattdessen auf die separaten Anmelde- und Registrierungsseiten. Gastkäufer merken davon nichts; ein Shop, der auf Kontoregistrierungen im Moment des Kaufs setzt, schon.

Das Modul liegt noch unter Version 1.0, und seine README rät weiterhin vom Einsatz in Live-Shops ab. Release 0.6.6 brachte einen displayExpressCheckout-Hook über dem Checkout-Formular, Postleitzahlprüfung für Gäste und eine länderspezifische Reihenfolge der Adressfelder. Lesen Sie die Release Notes der Version, die Sie einsetzen wollen.

Bevor Sie ihn aktivieren

• Theme. Die Ankündigung von PrestaShop sagt, dass der Checkout für Hummingbird-basierte Themes gebaut ist. Classic wird standardmäßig nicht unterstützt, und Sie müssen eventuell einige Templates des Moduls überschreiben.
• Zahlungs- und Versandmodule. Bestehende Hooks bleiben erhalten, viele Module erscheinen also ohne Änderungen. Da aber jetzt alles auf einem Bildschirm dargestellt und abschnittsweise aktualisiert wird, testen Sie jedes Zahlungs- und Versandmodul auf einer Staging-Kopie, besonders Versanddienste mit Preisen nach Postleitzahl und Zahlungsmodule, die ihr eigenes Markup rendern.
• Die Zahlung kann die Seite weiterhin verlassen. Ein einseitiges Formular entfernt die Schritte vor der Zahlung. Eine Kartenprüfung mit 3D Secure, eine gehostete Zahlungsseite oder eine Bankbestätigung kann den Käufer trotzdem woandershin und wieder zurück führen.
• Gutscheincodes. Das Gutscheinfeld erscheint erst, wenn Ihr Shop mindestens eine Warenkorbregel hat, weil PrestaShop die gesamte Warenkorbregel-Funktion abschaltet, wenn es keine gibt. Ein leeres Feld in einem Testshop ist kein Fehler.
• Ein anderes Checkout-Modul. Ist bereits ein Ersatz für den Checkout aktiv, lesen Sie zuerst dessen Anleitung zum Wechsel und seine Abhängigkeiten. Legen Sie nicht zwei Checkout-Ersatzlösungen übereinander, ohne geprüft zu haben, dass sie nebeneinander funktionieren.
• Individueller Checkout-Code. Bitten Sie Ihren Entwickler aufzulisten, was Checkout-Templates, Felder, Zahlungsauswahl oder Versandauswahl verändert, einschließlich Skripten, die an das alte Schritt-Markup gebunden sind, und Auswahlfeldern für Abholstationen. Eine Codesuche zeigt, was zu prüfen ist; ein übereinstimmender Hook- oder Dateiname ist kein Beweis für einen Konflikt.

Entscheiden Sie anhand Ihrer bestehenden Einrichtung: Halten Sie die genauen PrestaShop- und PHP-Versionen fest, Theme und Theme-Version, die Versionen der Zahlungs- und Versandmodule, individuelle Checkout-Regeln und angebundene Systeme. Probieren Sie die Änderung zuerst auf einer Staging-Kopie aus. Sichern Sie Dateien und Datenbank, geben Sie mit dem aktuellen Checkout eine Referenzbestellung auf und stellen Sie dann das Layout um, ohne gleichzeitig andere Theme- oder Zahlungsänderungen vorzunehmen. Wiederholen Sie dieselben Bestellungen und vergleichen Sie die entstandenen Datensätze, nicht Screenshots:

• Ein Gast und ein wiederkehrender Kunde, auf Smartphone und Desktop, einschließlich einer separaten Rechnungsadresse, sofern Sie eine verwenden.
• Ein Warenkorb mit Gutschein oder Versandaktion: Geben Sie eine Adresse ein, wählen Sie einen Versanddienst und wechseln Sie dann in ein anderes Land, in das Sie verkaufen. Versand, Steuern, Aktion und Zahlungsauswahl müssen sich alle vor der Zahlung neu berechnen.
• Erfolgreiche, abgelehnte und abgebrochene Zahlungen, 3D Secure und eine Zahlung, die bestätigt wird, nachdem der Käufer den Browser geschlossen hat, jeweils mit den Testwerkzeugen des Anbieters.
• Die entstandene Bestellung, Zahlungsreferenz, Bestätigungs-E-Mail und Bestandsänderung sowie jeder angebundene Export an Versandabwicklung oder Buchhaltung. Nutzen Sie Express-Buttons, testen Sie jeden aktivierten Einstiegspunkt separat, einschließlich Produktvarianten, Mengen und eines bestehenden Warenkorbs.
• Pflichtfelder für Geschäftskunden und Zahlungsregeln nach Kundengruppe, als eigene Fälle: Eine erfolgreiche Gastbestellung deckt sie nicht ab.

Stoppen Sie die Einführung, wenn die Summe auf dem Bildschirm von dem Betrag abweicht, der an den Zahlungsanbieter gesendet oder in der Bestellung erfasst wird. Verwenden Sie Test-Zugangsdaten für Zahlungen, leiten Sie E-Mails aus Staging in ein Testpostfach und deaktivieren Sie Live-Exporte an Versandabwicklung und Buchhaltung.

Erstellen Sie vor der Live-Umstellung ein frisches Datei- und Datenbank-Backup, halten Sie die aktuelle Konfiguration fest und bestätigen Sie das auf Staging getestete Rollback-Verfahren. Das Zurückschalten ist eine einzige Einstellung, macht aber keine Zahlungen rückgängig. Sichern Sie Bestellungen und Anbietertransaktionen seit dem Backup und gleichen Sie sie ab, bevor Sie eine Datenbankwiederherstellung in Betracht ziehen. Vergleichen Sie nach der Live-Umstellung abgeschlossene Bestellungen, Zahlungsfehler und Supportanfragen mit Ihren Ausgangswerten bei vergleichbarem Traffic und vergleichbaren Angeboten, getrennt für Mobilgeräte und Desktop. Definieren Sie einen Checkout-Start in beiden Layouts gleich. Ein einseitiges Layout bringt keine garantierte Conversion-Steigerung.

Reicht Ihnen der native Checkout?

Er ist eine gute Standardwahl, wenn Sie auf 9.2 sind, Hummingbird oder ein auf Hummingbird basierendes Child-Theme nutzen und einen Standard-B2C-Checkout haben: einige Versanddienste, gängige Zahlungsarten und Gastbestellungen als Normalfall. Testen Sie ihn in diesem Fall auf Staging, bevor Sie ein Modul kaufen. Setzen Sie ihn erst live ein, wenn die gewählte Version als produktionsreif dokumentiert ist und Ihre vereinbarten Bestellszenarien besteht.

Schauen Sie sich weiter um, wenn Sie eine Anforderung benennen können, die er nicht erfüllt, zum Beispiel wenn:

• Ihr Shop auf PrestaShop 1.6 bis 9.1 läuft und ein Upgrade nicht bald geplant ist;
• Sie Wallet-Buttons auf Produkt- und Warenkorbseiten möchten, nicht nur im Checkout. Das native Modul gibt Zahlungsmodulen einen Platz für Express-Buttons, stellt sie aber nicht selbst bereit;
• Käufer beim Bestellen ein Konto anlegen sollen;
• Sie auf individuelle Checkout-Felder, B2B-Regeln oder Zahlungseinschränkungen nach Kundengruppe angewiesen sind. Schreiben Sie diese Regeln zuerst auf (wer auf Rechnung kaufen darf, wo eine Einkaufsreferenz erscheinen muss, wie ein angenommenes Angebot zur Bestellung wird), und prüfen Sie dann vor dem Wechsel, ob die Module, die sie bereitstellen, im einseitigen Ablauf funktionieren.

Sollten Sie darauf warten?

• Bereits auf 9.2: Der Code ist verfügbar, doch die Warnung in der README bleibt ein Grund, mit dem Live-Einsatz zu warten. Lassen Sie angesichts des Status unter 1.0 und der README-Warnung Ihren funktionierenden Checkout live, bis eine von Ihnen getestete Version Ihre Bestellungen auf Staging besteht.
• Auf 9.0 oder 9.1: Der native Checkout kommt mit dem Update auf 9.2. Planen Sie dieses Update nach seinen eigenen Kriterien (Theme, Module, PHP) und testen Sie den Checkout dabei mit. Funktioniert Ihr aktueller Checkout, ist es vernünftig, auf dieses Update zu warten.
• Auf 1.6, 1.7 oder 8: Der Weg zu 9.2 braucht einen Migrationsplan auf Grundlage Ihrer bestehenden Module, Integrationen, Ihres Themes und Ihrer Daten. Bei älteren oder stark angepassten Shops ist der übliche sichere Weg ein sauberer 9.2-Shop auf Staging, eine geprobte Datenmigration und eine geplante Umstellung; die Checkliste zur Migration auf PrestaShop 9 führt Sie hindurch. Wechseln Sie die Hauptversion nicht allein wegen eines Checkout-Layouts.
• Sie verlieren jetzt Bestellungen: Warten Sie nicht. Ein reproduzierbarer Zahlungsfehler oder ein bekannter Abbruchpunkt braucht heute eine Diagnose, und ein neues Layout behebt keinen Zahlungsfehler.

Wissen Sie nicht, wo Käufer abspringen, prüft das PrestaShop B2C Conversion & Revenue Audit den Kaufweg Ihrer Endkunden und liefert einen priorisierten Maßnahmenplan, ohne etwas zu installieren oder zu ändern.

Checkout Revolution bietet auch unter PrestaShop 1.6 bis 9.1 einen einseitigen Checkout und ein Express-Checkout-Modal, einschließlich Feld- und Zahlungsregeln nach Kundengruppe und Land sowie angenommener Geschäftsangebote, die zu Bestellungen werden. Express Checkout ergänzt neben Ihrem bestehenden Checkout ein Stripe-Kauffenster (Karten, Wallets und lokale Zahlungsarten) auf Produktseiten, in Listen oder im Warenkorb und bietet einen optionalen einseitigen Checkout, der Ihre anderen Zahlungs- und Versandmodule einbezieht. Die weiteren Optionen vergleichen wir in unserem Checkout-Leitfaden.

Haben Sie sich für ein Modul entschieden, installiert und konfiguriert der PrestaShop Module Installation & Configuration Service ein bestehendes Modul und prüft den betroffenen Ablauf, mit dokumentierten Schritten zur Rücknahme.