Wir haben PrestaShop 9.2s nativen One Page Checkout getestet: was funktioniert, was nicht, und wann Sie mehr brauchen

Getestet im Juli 2026 mit PrestaShop 9.2.0 Beta 1.

PrestaShop 9.2 bringt einen nativen One Page Checkout mit. Für jeden, der einen Shop betreibt, wird damit aus einer alten Annahme eine echte Frage: Wenn der Checkout jetzt eingebaut ist, brauchen Sie dann überhaupt noch ein Checkout-Modul?

Wir wollten das nicht aus den Release Notes beantworten. Also haben wir die 9.2 Beta in einem sauberen Container installiert, den nativen One Page Checkout aktiviert und den kompletten Ablauf mit einem gesteuerten Browser durchlaufen. Protokolliert wurde jede Seitennavigation, jedes Skript, jeder XHR- und Dokument-Request (statische Assets wie Bilder und Schriften blieben außen vor) samt Zeitmessung. Dieser Beitrag zeigt, was die Messgeräte tatsächlich gesagt haben.

Das Wichtigste vorweg: er ist besser, als wir erwartet hatten. Wir sind mit einem konkreten Verdacht hineingegangen, nämlich dass das Eingeben einer Adresse klammheimlich Seitenneuladen erzwingt und das Ganze nur dem Namen nach "one page" ist. Dieser Verdacht war falsch, und wir sagen das zuerst, weil es genau das war, was wir am ehesten zu finden erwartet hatten.

Fehlerfrei ist er nicht, aber die Schwachstellen sind kleiner, als wir zuerst berichtet haben. Zwei unserer ursprünglichen Befunde stellten sich als Fehler in unserem eigenen Testskript heraus, und wir ziehen sie unten zurück, statt sie stehen zu lassen. Übrig bleiben ein doppelter Request, fehlende Formularattribute, ein Layoutproblem auf dem Handy und eine bewusste Designentscheidung, die etwas wegnimmt, das der alte Checkout konnte.

Zuerst das Wichtigste: unser Interessenkonflikt

Wir verkaufen PrestaShop-Checkout-Module. Ein nativer Checkout im Core ist für uns kommerziell gesehen Konkurrenz. Lesen Sie alles, was wir dazu sagen, also mit diesem Wissen.

So sind wir damit umgegangen, damit Sie unsere Arbeit prüfen können, statt unseren Motiven vertrauen zu müssen. Jede Aussage unten ist eine Zahl, die wir aufgezeichnet haben, oder ein Screenshot, den wir gemacht haben, auf einer Installation, die jeder aus einem öffentlichen Docker-Image nachbauen kann. Wo wir einen Fehler erwartet und keinen gefunden haben, sagen wir das. Wo unsere erste Einschätzung falsch war, haben wir sie korrigiert, statt die für uns schmeichelhaftere Version stehen zu lassen: Wir dachten zunächst, dem neuen Checkout fehlten Rabattcodes, und das stimmt nicht. Die Einrichtungsschritte, die genauen Versionen und alles, was wir nicht testen konnten, sind aufgeführt. Wenn sich eine Messung bei Ihnen nicht reproduzieren lässt, sagen Sie uns Bescheid, dann gehen wir dem nach.

Was genau wir getestet haben

Jede Zahl unten stammt aus dieser Umgebung. Wenn sich etwas bei Ihnen nicht reproduzieren lässt, kann das an Ihrer Version liegen, an Ihrer Konfiguration oder an unserer Methode, und wir hören lieber davon als nicht.

Zwei Hinweise zur Einrichtung gehören zur Ehrlichkeit dazu. Erstens hatte die Standardinstallation keinen Carrier, der das eigene Land des Shops bedient, weil Großbritannien in der Zone "Europa (nicht EU)" liegt und die Beispiel-Carrier nur zwei andere Zonen abdecken. Wir haben die Carrier dieser Zone zugewiesen, was normale Händlerkonfiguration ist und kein Checkout-Problem. Zweitens stammen die Zeiten aus einem lokalen Netzwerk. Betrachten Sie sie als Vergleich zwischen den beiden Checkouts auf identischer Hardware, nicht als Werte, die Ihr Shop reproduzieren wird.

Was der native 9.2 OPC tatsächlich ist

Er kommt als Modul, ps_onepagecheckout, enthalten im 9.2-Paket. Zwei Details, die wir bei der Installation bestätigt haben, sollten Sie kennen, bevor Sie irgendetwas planen:

• Er ist standardmäßig aus. Nach einer sauberen 9.2-Installation ist das Modul vorhanden und aktiviert, aber die Einstellung PS_ONE_PAGE_CHECKOUT_ENABLED steht auf 0. Sie aktivieren ihn unter Design > Checkout im Backoffice und können jederzeit zum klassischen vierseitigen Checkout zurückwechseln.
• Es heißt 9.2 oder gar nicht. Das Modul deklariert ps_versions_compliancy mit einem Minimum von 9.2.0. Ein Shop auf 1.7, 8.x, 9.0 oder 9.1 kann es nicht installieren.

Architektonisch macht er das, was die offizielle Ankündigung im PrestaShop-Build-Blog beschreibt. Er hängt seinen eigenen Checkout-Prozess über einen Core-Hook ein, statt den Order-Controller zu überschreiben, und ersetzt die vier Step-Klassen durch einen einzigen kombinierten Schritt. Login und Kontoerstellung wurden bewusst aus dem Checkout auf eigene Seiten verlagert. Das Design vor dem Release haben wir in was Händler und Entwickler über den nativen 9.2 OPC wissen sollten behandelt. Dieser Beitrag ersetzt die Vermutungen von damals durch Messungen.

Der Benchmark

Der native 9.2 One Page Checkout mit ausgefüllter Adresse. Versandart, Zahlart, AGB und der Bezahlen-Button liegen alle auf demselben Bildschirm, und die Übersicht rechts aktualisiert sich live.

Gleicher Shop, gleiches Produkt, gleiche Adressdaten, gleiche Carrier, jeweils in einem frischen Warenkorb. Die beiden Abläufe waren gleichwertig, aber nicht Aktion für Aktion identisch, weil die beiden Checkouts nicht dieselben Aktionen anbieten. "Vollständige Seitenladevorgänge" zählt Hauptframe-Navigationen vom Öffnen des Checkouts bis zur Bestellbestätigung.

Derselbe Shop mit ausgeschaltetem One Page Checkout. Drei der vier Schritte sind nicht erreichbar, bis der darüberliegende abgeschlossen ist, und jeder abgeschlossene Schritt kostet einen vollständigen Seitenaufbau.

Bewerten Sie diesen Tausch ehrlich, und achten Sie auf die Stichprobengröße. Das sind fünf Durchläufe in einem lokalen Netzwerk, also rein beschreibend zu verstehen. Besonders der Unterschied beim ersten Bildaufbau liegt innerhalb der Streuung zwischen den Durchläufen (One Page Checkout 152 bis 180 ms, klassisch 148 bis 188 ms), und wir würden ihn nicht als echten Unterschied bezeichnen. Der Abstand bei DOMContentLoaded und die Byte-Zahlen waren dagegen über alle Durchläufe hinweg konstant. Der One Page Checkout braucht etwa 50 ms länger bis DOMContentLoaded und bringt rund 28 KB mehr JavaScript mit, weil er Kontaktdaten, Adresse, Versand, Zahlung und Übersicht in einem Dokument rendert statt Schritt für Schritt. Dafür fallen drei vollständige Seitenladevorgänge weg. Auf jeder realen Verbindung schlagen drei eingesparte Server-Roundtrips 50 ms lokale Renderzeit deutlich.

Wo die Adress-Hypothese gestorben ist

Das war genau das, was wir aufdecken wollten, deshalb hier die rohe Aufschlüsselung pro Aktion. Jede einzelne wurde mit dem Netzwerkprotokoll des Browsers aufgezeichnet.

Eine Adresse hinzuzufügen lädt die Seite nicht neu. Eine zu bearbeiten lädt die Seite nicht neu. Das Land zu wechseln lädt die Seite nicht neu, sondern baut das Adressformular per AJAX neu auf, weil sich Pflichtfelder und Steuerverhalten ändern. Der Wechsel der Versandart aktualisierte die Bestellsumme live, von 19,12 EUR auf 26,12 EUR, ganz ohne Navigation.

Die Aktualisierungslogik ist außerdem sorgfältiger, als wir angenommen hatten. Das Bearbeiten der Straße, was keinen Versandpreis ändern kann, löste genau einen Entwurfs-Speicherrequest aus und sonst nichts. Versandarten und Zahlungsoptionen wurden nur dann neu geladen, wenn sich etwas geändert hatte, das sie wirklich betrifft, etwa das Land oder die vervollständigte Adresse. Das ist sinnvolles Verhalten, mit einer Einschränkung: Unsere Beispiel-Carrier hatten Pauschalpreise, eine Änderung der Postleitzahl konnte den Preis also gar nicht beeinflussen. Ein Carrier, der nach Postleitzahl kalkuliert, bräuchte einen eigenen Test, denn hier erzeugten sowohl eine Straßenänderung als auch eine PLZ-Änderung nur einen Entwurfs-Speichervorgang.

Was er gut macht

Das korrekt anzuerkennen ist wichtig, denn genau das werden Händler spüren.

• Es ist wirklich ein Bildschirm. Kontaktdaten, Lieferadresse, Versandart, Zahlung, Bestellübersicht und der Bezahlen-Button liegen beim ersten Aufbau alle in einem einzigen Formular. Es gibt keine Schrittsperren und nichts, was hinter einem "Weiter"-Button verborgen wäre.
• Die Wartezustände erklären sich selbst. Bevor die Adresse vollständig ist, bleiben die Versand- und Zahlungsblöcke nicht einfach leer. Sie sagen "Vervollständigen Sie oben Ihre Lieferadresse, um Ihre Versandoptionen zu sehen" und listen dann genau auf, was fehlt: "Noch benötigt: Vorname, Nachname, Adresse, Stadt, PLZ". Das ist ungewöhnlich klarer Mikrotext für einen Standard-Checkout.
• Inline-Validierung stoppt falsche Daten ohne Neuladen. Mit Frankreich als Land (das ein PLZ-Format definiert) markierte die Eingabe ABC das Feld als ungültig, zeigte "Ungültige Postleitzahl, sollte aussehen wie "NNNNN"", ersetzte die Versandliste durch "Bitte korrigieren Sie die markierten Adressfelder" und verweigerte das Absenden. Ein Klick auf Bezahlen erzeugte null Netzwerkanfragen und setzte den Fokus zurück ins Formular. Nichts ging verloren, nichts wurde neu geladen. In einem separaten Test, in dem wir ein Pflichtfeld für die Stadt geleert hatten, fokussierte der Browser beim Absenden genau dieses Feld.
• Der Bezahlen-Button bleibt ehrlich. Er bleibt deaktiviert, solange eine erforderliche Einwilligung offen ist, was wir bei einem wiederkehrenden Kunden aufgezeichnet haben, dessen Versand und Zahlung bereits feststanden, dessen AGB-Häkchen aber fehlte, und er zeigt die aktuelle Summe direkt auf sich. Ein vollständiger Bereitschaftsindikator ist er nicht: Mit geleertem Pflichtfeld Stadt blieb er aktiv, und der Browser statt des Checkouts verhinderte das Absenden ("Bezahlen 19,12 EUR", danach "Bezahlen 26,12 EUR", nachdem wir den kostenpflichtigen Carrier gewählt hatten).
• Gespeicherte Adressen werden verwaltet, ohne die Seite zu verlassen. Für eingeloggte Kunden bietet die Adressliste "Andere Lieferadresse verwenden" an, und sowohl das als auch das Bearbeitungsmenü pro Adresse öffnen ein Modal auf demselben Bildschirm. Adressen mitten im Checkout anzulegen oder zu ändern führt nie von der Seite weg.
• Gutscheincodes werden unterstützt und rechnen live neu. Die Übersicht enthält ein Akkordeon "Gutscheincode" mit einem Feld "Fügen Sie hier Ihren Gutschein ein". Das Einlösen eines Codes berechnete Rabatt, Versandarten und Zahlungsoptionen per AJAX neu, ganz ohne Seitenneuladen. Eines sollten Sie wissen: Das Feld erscheint erst, wenn im Shop mindestens eine Warenkorbregel existiert, denn PrestaShop schaltet die ganze Funktion ab, solange es keine gibt.
• Wiederkehrende Kunden bekommen einen wirklich schnellen Weg. Mit Login und gespeicherter Adresse stand das Checkout-Formular nach 193 ms, und die Adressliste, beide Versandarten und alle drei Zahlarten waren Sekundenbruchteile später per AJAX aufgelöst, ohne eine einzige Interaktion. Der Abschluss der Bestellung erforderte zwei Aktionen: AGB anhaken, Bezahlen klicken. Das E-Mail-Feld verschwindet für eingeloggte Kunden vollständig, genau wie in der Ankündigung beschrieben.
• Das Mobil-Layout hält stand. Bei 375 px gab es keinerlei horizontales Überlaufen (Dokumentbreite 375 px, Viewport 375 px), und der First Contentful Paint lag bei 152 ms. Die Versandzeilen und die AGB-Zeile haben große antippbare Labels (351x136 px und 327x48 px).

Eine ungültige französische Postleitzahl. Das Feld wird inline markiert, die Versandliste wird durch eine Korrekturaufforderung ersetzt, und ein Klick auf Bezahlen erzeugte überhaupt keine Netzwerkanfragen.

Eingeloggte Kunden sehen ihre gespeicherten Adressen als auswählbare Karten, mit einem Menü je Adresse und der Möglichkeit, eine neue anzulegen.

Eine Adresse hinzuzufügen öffnet ein Modal über dem Checkout. Die Seite dahinter wird nie neu geladen, und nichts bereits Eingegebenes geht verloren.

Auch die Bestellbestätigung wurde überarbeitet und wirkt spürbar aufgeräumter als die bisherige.

Die Schwachstellen, die wir tatsächlich gemessen haben

Das sind Dinge, die wir belegen können, keine Eindrücke.

1. Der Endpunkt für Zahlarten wird doppelt abgerufen

Jedes Mal, wenn die Adresse aufgelöst wird, fragt der Checkout seine Zahlungsoptionen zweimal mit byte-identischer URL ab:

GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17
GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17

Wir haben das sechsmal in vier unabhängigen Browser-Sitzungen aufgezeichnet: bei der ersten Adresseingabe und einem Länderwechsel im Gastdurchlauf, im Mobil-Durchlauf, in einem Durchlauf mit ungültiger Postleitzahl sowie bei einem ersten und einem wiederholten Checkout eines eingeloggten Kunden. Der wiederholte Checkout ist der aussagekräftigste Fall, weil er bei einem einfachen Seitenaufruf ganz ohne skriptgesteuerte Interaktion auftritt. Es ist ein doppelter Request, nicht zwei verschiedene Zustände. In einem Shop, in dem Zahlungsmodule pro Rendering echte Arbeit leisten (Gebührenberechnung, Verfügbarkeitsregeln, entfernte Aufrufe), ist das verschwendete Serverzeit auf der conversion-kritischsten Seite überhaupt. Genau so etwas hat ein 0.6.2-Modul noch aufzuräumen.

2. Keine Autofill-Hinweise in irgendeinem Adressfeld

Wir haben jedes Feld im Lieferadressblock geprüft. Kein einziges trägt ein autocomplete-Attribut, und kein einziges ein inputmode:

Adress-Autofill in Browser und Smartphone stützt sich auf genau diese Tokens (given-name, address-line1, postal-code und so weiter). Ohne sie funktioniert ausgerechnet das, was auf dem Handy am meisten Tipparbeit spart, nur unzuverlässig, was einen Checkout untergräbt, dessen erklärtes Ziel weniger mobile Reibung ist. Dass es ein Versehen und keine Entscheidung ist, wissen wir, weil die 9.2-Registrierungsseite im selben Theme die Tokens korrekt setzt: email, given-name, family-name, new-password und tel-national. Das Adressformular im Checkout, das sie am nötigsten hätte, hat keine. Immerhin nutzt das Telefonfeld type="tel", damit stimmt zumindest diese Tastatur.

3. Sie können beim Bestellen kein Konto anlegen, und das ist ein Rückschritt

Login und Registrierung wurden bewusst aus dem Checkout verlagert, was die Ankündigung klar so sagt. Was das in der Praxis bedeutet, lohnt eine genaue Beschreibung, denn es ist ein Rückschritt gegenüber dem Checkout, den es ersetzt.

Wir haben beide Checkouts im selben Shop verglichen. Der klassische vierstufige Checkout rendert ein echtes <input type="password" name="password"> innerhalb des Checkouts, ein Käufer kann also beim Bestellen ein Konto anlegen, und sein "Anmelden" ist ein Tab auf derselben Seite. Der One Page Checkout hat nirgendwo ein Passwortfeld, und beide Bedienelemente sind gewöhnliche Links, die wegführen:

Ein Kunde, der kaufen und ein Konto behalten möchte, muss also den Checkout verlassen, sich auf einer separaten Seite registrieren und zurückkommen. Für einen gast-orientierten Checkout ist das eine schlüssige Entscheidung, und Gastkäufern fällt es nie auf. Für einen Shop, der auf Kontoanmeldungen im Kaufmoment angewiesen ist, nimmt es etwas weg, das der alte Checkout konnte. Es bedeutet außerdem, dass genau der Moment, in dem ein Kunde am motiviertesten ist, sich zu registrieren, nämlich direkt nach der Kaufentscheidung, der eine Moment ist, in dem der Checkout es nicht zulässt.

4. Der Bezahlen-Button liegt auf dem Handy weit unten

Der One Page Checkout bei 375 px. Das Layout hält ohne horizontales Überlaufen stand, aber der gesamte Checkout ist eine einzige hohe Spalte.

Alles auf einen Bildschirm zu legen macht diesen Bildschirm hoch. In einem 375-px-Viewport sitzt der Bezahlen-Button 3337 px weit unten, und er ist nicht klebend: seine berechnete Position ist static, ohne fixierten oder klebenden Vorfahren. Auch ein wiederkehrender Kunde mit gespeicherter Adresse muss am gesamten Formular vorbeiscrollen, um ihn zu erreichen. Eine klebende Übersicht oder Bezahlleiste ist die übliche Antwort darauf, und die gibt es noch nicht.

5. Es ist ein Modul vor 1.0, und sein eigenes README sagt das auch

Kein Mangel, aber die wichtigste Planungstatsache auf dieser Seite. Das getestete Beta-Paket bündelt Modulversion 0.6.2, während upstream wenige Tage vor unserem Test bereits 0.6.5 getaggt hatte. Behandeln Sie konkrete Versionsnummern also als bewegliches Ziel. Und PrestaShops eigene Beta-Ankündigung ist unmissverständlich: "Diese Beta-Version ist Vorabsoftware. Es ist möglich, dass Sie auf Probleme stoßen. Verwenden Sie sie nicht in Ihrem Produktionsshop!" Außerdem können Sie eine Beta über den normalen Update-Weg weder auf den Release Candidate noch auf stabil aktualisieren.

Das Repository des Moduls ist noch deutlicher. Das README von PrestaShop/ps_onepagecheckout sagt: "Dieses Modul befindet sich in intensiver Entwicklung. Es ist nicht produktionsreif und sollte nicht in Live-Umgebungen eingesetzt werden." Zum Zeitpunkt des Schreibens gibt es eine überschaubare Zahl offener Issues, und zwei davon decken sich exakt mit Dingen, auf die wir unabhängig gestoßen sind: #94 meldet doppelte Feld-IDs zwischen dem versteckten Adress-Modal und dem Inline-Adressformular, weshalb dieselbe #field-postcode-ID in der von uns geprüften Seite mehrfach vorkommt, und #102 beschreibt, dass der Stapel an Einwilligungs-Checkboxen den schwersten Block auf den ersten Bildschirm legt, also genau die Reibung, die wir unten beschreiben. #132 betrifft das Adressformular, das die länderspezifische Feldreihenfolge ignoriert, und #105 ist eine offene Anfrage, einen Express-Checkout-Vertrag bereitzustellen. Letzteres ist wichtig, wenn Sie über Wallet- oder Express-Zahlarten verkaufen, denn die Schnittstelle, an der diese andocken würden, wird noch entworfen.

6. Drei Pflicht-Einwilligungen stehen zwischen Kunde und Optionen

In einer Standardinstallation von 9.2 trifft ein Erstkäufer als Gast auf drei Pflichthäkchen: Datenschutz, die eigene Box des DSGVO-Moduls und die AGB. Für Gäste sperren die ersten beiden die Versand- und Zahlungsoptionen, die hinter einer Meldung "Bitte akzeptieren Sie die erforderlichen Bedingungen" bleiben, bis sie gesetzt sind. Für wiederkehrende Kunden ist es milder, dort haben wir gemessen, wie sich die Optionen normal auflösten, während nur das AGB-Häkchen fehlte, das dann den Bezahlen-Button sperrt und nicht die Optionen. Dieser Stapel ist Ihre Shop-Konfiguration und nicht die Schuld des Checkouts, und er ist entfernbar, aber genau das bekommt ein Erstkäufer bei einer frischen 9.2-Installation zu sehen. PrestaShop hat dazu ein offenes Issue, #102.

Eine Korrektur: zwei zurückgezogene Befunde

Eine frühere Fassung dieses Artikels enthielt zwei weitere Befunde. Beide waren falsch, und beide lagen an uns und nicht am Checkout. Wir lassen das hier stehen, statt es stillschweigend zu löschen.

Wir hatten berichtet, dass das Einlösen eines Rabattcodes die Versandart des Kunden zurücksetzt, und getrennt davon, dass der Checkout eine Versandart und Summe anzeigen kann, während der gespeicherte Warenkorb etwas anderes enthält. Beides kam aus demselben Fehler: Unser Skript wählte die Versandart programmatisch aus, statt sie anzuklicken, sodass die Auswahl den Server nie erreichte und jede spätere Darstellung schlicht die Server-Wahrheit zeigte.

Geklärt hat es der Test, eine echte Bestellung abzuschließen und danach die Datenbankzeile zu lesen, statt dem Bildschirm zu vertrauen:

Wird wie von einem Menschen geklickt, passt die Bestellung jedes Mal zum Bildschirm, mit und ohne Gutschein. Rabattcodes funktionieren korrekt: Das Feld erscheint, sobald der Shop tatsächlich eine Warenkorbregel hat, und das Einlösen berechnet Rabatt, Versandarten und Zahlungsoptionen per AJAX neu, ohne Neuladen. Wir hätten keine dieser Behauptungen veröffentlichen dürfen, und wir halten die Korrektur fest, weil ein Benchmark, dem man nicht zutraut, sich selbst zu korrigieren, das Lesen nicht wert ist.

Was wir nicht testen konnten

Das klar zu benennen ist der Unterschied zwischen einem Benchmark und einer Meinung.

• Echte Zahlungs-Gateways. Wir haben nur mit Offline-Methoden getestet. Ein Karten-Gateway, ein Wallet-Ablauf oder ein 3D-Secure-Schritt bringt jeweils eine eigene Übergabe mit, die eine Weiterleitung, ein Popup oder ein eingebettetes Frame sein kann. Die letzte von uns gemessene Navigation war die Übergabe des Scheck-Moduls an seine Validierungsseite.
• Das Classic-Theme. Wir haben auf hummingbird getestet, dem Theme, das 9.2 installiert. Die offizielle Ankündigung warnt, dass Classic-Themes standardmäßig nicht unterstützt werden und Sie "möglicherweise einige Templates des One-Page-Checkout-Moduls überschreiben müssen, damit es funktioniert". Wir haben keine sauber migrierte Classic-Theme-Installation abgeschlossen, deshalb zitieren wir dazu PrestaShop und nicht unser eigenes Ergebnis.
• Last und Parallelität. Messungen mit einem einzelnen Browser in einem lokalen Netzwerk. Nichts hier sagt aus, wie sich die zusätzlichen AJAX-Endpunkte unter echtem Traffic verhalten.
• Checkout-Module von Drittanbietern. Wir haben nicht getestet, wie bestehende Versand-, Gebühren- oder Upsell-Module im One-Page-Ablauf rendern. Das ist der wichtigste Punkt, den Sie auf Ihrer eigenen Staging-Kopie prüfen sollten.

Bauen Sie es selbst nach

Nichts davon ist viel wert, wenn Sie es nicht nachprüfen können. Der komplette Prüfstand ist ein öffentliches Image und etwa zehn Minuten Einrichtung. Das ist eine gekürzte Fassung der von uns genutzten Compose-Datei (ergänzen Sie die üblichen MYSQL_* und die dazu passenden DB_*-Zugangsdaten, und richten Sie die Domain auf Ihre Umgebung):

services:
  prestashop:
    image: prestashop/prestashop:9.2.0-6.0-beta.1-classic-apache
    ports: ["8088:80"]
    environment:
      DB_SERVER: ps92-db
      PS_INSTALL_AUTO: 1
      PS_DEV_MODE: 0          # unbedingt AUS lassen, sonst sind alle Zeiten verfaelscht
      PS_DOMAIN: localhost:8088
  ps92-db:
    image: mysql:8.0

Dazu vier Dinge, die Ihnen sonst den Nachmittag kosten, weil sie uns unseren gekostet haben:

• Schalten Sie den Checkout ein. Er wird installiert, aber deaktiviert ausgeliefert. Design > Checkout, oder PS_ONE_PAGE_CHECKOUT_ENABLED auf 1 setzen.
• Geben Sie Ihren Carriern die richtige Zone. Eine Standardinstallation legt Großbritannien in "Europa (nicht EU)", während die Beispiel-Carrier nur zwei andere Zonen bedienen. Eine britische Adresse zeigt daher völlig zu Recht gar keine Versandarten. Das sind Beispieldaten, kein Checkout-Fehler, und wir hätten es beinahe als solchen gemeldet.
• Testen Sie die PLZ-Validierung mit Frankreich, nicht mit Großbritannien. PrestaShop liefert für GB ein leeres zip_code_format aus, jeder Unsinn geht also durch und der Checkout wirkt kaputt, obwohl er es nicht ist. Frankreich definiert NNNNN und validiert korrekt.
• Für den Gutschein-Test brauchen Sie mehr als den Standardshop. Der Kern-Benchmark lief mit den zwei Beispiel-Carriern, aber der Gutschein-Test braucht eine Versandart, deren Verlust auffällt: Wir haben Standard Delivery zu 4,90, Economy zu 6,90 (kostenlos ab 100) und Express 24h zu 12,90 angelegt, jeweils für alle Zonen, und dann eine Warenkorbregel über 10% mit dem Code TEST10 und ausgeschaltetem Gratisversand erstellt. Wählen Sie die teuerste Versandart, lösen Sie den Code ein, schließen Sie die Bestellung ab und vergleichen Sie die Versandart auf der fertigen Bestellung mit der, die Sie gewählt hatten. Ein Fallstrick: Das Gutscheinfeld ist unsichtbar, solange keine einzige Warenkorbregel existiert, weil PrestaShop PS_CART_RULE_FEATURE_ACTIVE in einem Shop ohne Regeln auf 0 setzt.

Für die Zählung der Seitenladevorgänge öffnen Sie das Netzwerk-Panel, filtern auf Doc und beobachten, wie viele Hauptframe-Navigationen zwischen dem Öffnen des Checkouts und der Bestätigungsseite anfallen. Für den doppelten Request filtern Sie auf paymentmethods.

Reicht Ihnen der native 9.2 OPC?

Auf Basis unserer Messungen hier die ehrliche Aufteilung.

Der native OPC reicht wirklich, wenn

• Sie ohnehin auf 9.2 wechseln und das hummingbird-Theme oder ein Child davon nutzen.
• Ihr Checkout ein Standardfall ist: ein paar Versandarten, übliche Zahlarten, keine eigenen Felder.
• Sie an Endkunden verkaufen und Gastbestellungen die Regel sind.
• Sie den vierstufigen Ablauf zusammengefasst und eine live aktualisierte Summe wollen, was er mit null Neuladen genau liefert.
• Sie bereit sind, auf das stabile 9.2-Release zu warten, bevor Sie ihn einschalten.

Für einen solchen Shop ist die Antwort einfach: Die Plattform deckt es jetzt ab, und Sie sollten kein Modul kaufen, um zu tun, was der Core tut. Wenn Ihr Checkout aktuell Bestellungen verliert und Sie wissen wollen, ob er überhaupt das Problem ist, beginnen Sie mit warum Ihre Checkout-Seite Umsatz kostet und den Gründen, warum Kunden vor dem Bezahlen abspringen.

Sie stoßen weiterhin an Grenzen, wenn

• Sie nicht auf 9.2 sind. Das ist der harte Punkt. Das Modul verweigert die Installation unterhalb von 9.2.0, und Upgrades, die den Checkout berühren, sind genau die, die Händler aufschieben. Ein Shop auf 1.7, 8.x, 9.0 oder 9.1 bekommt aus diesem Release nichts.
• Sie den Zahlschritt selbst auf einen Fingertipp bringen wollen. One Page Checkout beseitigt die Reibung vor der Zahlung. Er macht aus einem Gateway keinen Wallet-Button. Das ist eine andere Funktion, behandelt in Express Checkout und in ist One-Click-Checkout in PrestaShop möglich.
• Mobil den Großteil Ihres Umsatzes ausmacht und Sie eine klebende Bezahlleiste brauchen, oder Sie brauchen ein Adressformular, das mit dem Autofill des Handys zusammenarbeitet. Beides sind oben gemessene Lücken.
• Sie möchten, dass Kunden sich im Kaufmoment registrieren. Im Checkout gibt es kein Passwortfeld, Kontoerstellung bedeutet also, ihn zu verlassen.
• Sie Regeln brauchen wie "diese Zahlart nur zwischen Bestellwert X und Y". Solche bedingte Zahlungs- und Versandlogik ist nicht Teil des nativen Moduls.
• Sie eigene Checkout-Felder, B2B-Regeln, Upsells auf Bestellebene oder Lieferterminauswahl brauchen. Nichts davon liegt im Umfang des nativen Moduls.

Wo ein Modul weiterhin seinen Platz hat

Wir verkaufen Checkout-Module, behandeln Sie diesen Absatz also mit der angemessenen Skepsis und prüfen Sie ihn gegen die Tabelle oben. Die Lücken, die wir tatsächlich gemessen haben, sind schmaler als noch vor einem Jahr, und in einem Standard-9.2-Shop macht der native Checkout die Kernaufgabe jetzt gut.

Die eine Lücke, die keine Geschmacksfrage ist, ist die Versionsreichweite. Der native OPC beginnt bei 9.2, belegt durch die Kompatibilitätsdeklaration des Moduls selbst. Unser Checkout Revolution gibt es, um einen einseitigen Checkout auf die PrestaShop-Versionen zu bringen, die die meisten Live-Shops heute tatsächlich betreiben, ohne Eingriffe in den Core. Den genau unterstützten Versionsbereich finden Sie auf der Produktseite, und wir haben ihn noch nicht gegen 9.2 selbst zertifiziert. Die Geschichte dazu steht in Checkout Revolution 3.0. Wenn Sie dagegen den Zahlvorgang selbst verkürzen wollen statt das Formular darüber, ist das Express Checkout, und das bleibt relevant, egal welcher Checkout die Seite rendert. Wenn Sie die Wege gegeneinander abwägen, ordnen der Leitfaden zur Checkout-Optimierung und die Übersicht zu Checkout-Prozess und Alternativen das ein.

Wenn Sie auf 9.2 mit einem Standardkatalog und einem Standard-Checkout unterwegs sind, würden wir Ihnen sagen: Nehmen Sie den nativen. Das ist es, was die Messungen hergeben.

FAQ

Ist der One Page Checkout von PrestaShop 9.2 stabil genug für den Produktivbetrieb?

Noch nicht, und PrestaShop sagt das gleich zweimal. Die 9.2-Beta-Ankündigung nennt es Vorabsoftware und rät Händlern davon ab, sie in einem Produktionsshop einzusetzen, und das README des Moduls sagt: "Dieses Modul befindet sich in intensiver Entwicklung. Es ist nicht produktionsreif und sollte nicht in Live-Umgebungen eingesetzt werden." Das Checkout-Modul selbst steht bei Version 0.6.2. Jede von uns aufgegebene Bestellung entsprach dem, was der Checkout angezeigt hatte, aber ein Modul vor 1.0 auf einer Beta-Plattform gehört trotzdem auf Staging, bis 9.2 stabil ist. Außerdem können Sie von der Beta über den Standardweg weder auf den Release Candidate noch auf stabil aktualisieren, testen Sie also auf einer Wegwerfkopie.

Funktioniert er mit meinem Theme?

Er ist für hummingbird gebaut, das Theme, das das 9.2-Paket installiert und auf dem wir getestet haben, und dort lief er ohne jede Anpassung. PrestaShops eigene Ankündigung warnt, dass Classic-Themes standardmäßig nicht unterstützt werden und Sie möglicherweise einige Templates des Moduls überschreiben müssen, damit es funktioniert. Den Classic-Theme-Fall haben wir nicht selbst verifiziert, behandeln Sie Ihr Theme also als das Erste, was Sie auf Staging testen, insbesondere wenn es Checkout-Templates überschreibt.

Brauche ich noch ein Checkout-Modul?

Wenn Sie auf 9.2 sind, hummingbird oder ein Child-Theme nutzen und einen konventionellen Checkout haben, dann ehrlicherweise nein. Das native Modul fasst die vier Schritte auf einem Bildschirm zusammen, aktualisiert Summen live, validiert inline und schließt eine Bestellung für wiederkehrende Kunden in zwei Aktionen ab. Ein spezialisiertes Modul wollen Sie weiterhin für die Dinge, die es nach unseren Tests nicht kann: Betrieb auf PrestaShop 1.6 bis 9.1, Wallet-Zahlung per Fingertipp, eigene oder B2B-Checkout-Felder, Upsells auf Bestellebene und mobile Feinheiten wie eine klebende Bezahlleiste.

Wie aktiviere ich ihn?

Gehen Sie im Backoffice auf Design > Checkout und wählen Sie das One-Page-Checkout-Layout. Das Modul wird mit 9.2 installiert ausgeliefert, die Einstellung ist aber standardmäßig aus, eine frische Installation gibt Ihnen also den klassischen vierstufigen Checkout, bis Sie umschalten. Sie können jederzeit zurückwechseln, und in einem Multistore-Setup wird die Wahl pro Shop und nicht global getroffen.

Können Kunden im One Page Checkout Rabattcodes nutzen?

Ja. Die Bestellübersicht enthält ein Akkordeon "Gutscheincode" mit einem Eingabefeld, und das Einlösen berechnet Rabatt, Versandarten und Zahlungsoptionen per AJAX neu, ohne die Seite neu zu laden. Wir hatten ursprünglich berichtet, dass das Einlösen eines Codes die Versandart des Kunden zurücksetzt. Das war unser Testskript, das die Versandart programmatisch auswählte, statt sie anzuklicken, und wir haben die Behauptung zurückgezogen: Mit echten Klicks passte die fertige Bestellung jedes Mal zur gewählten Versandart, mit und ohne Gutschein. Die einzige echte Eigenheit ist, dass das Gutscheinfeld verborgen bleibt, bis der Shop mindestens eine Warenkorbregel hat, weil PrestaShop die Funktion sonst komplett deaktiviert.

Bedeutet One Page Checkout überhaupt keine Weiterleitungen?

Nein, und das ist das häufigste Missverständnis. Wir haben über den gesamten Ablauf zwei vollständige Seitenladevorgänge gemessen: das Öffnen des Checkouts und die Übergabe durch das Zahlungsmodul nach dem Absenden. Alles dazwischen, einschließlich Adresseingabe, Adressänderung, Länderwechsel, Wechsel der Versandart und Wahl der Zahlart, geschah ohne ein einziges Neuladen. Aber eine echte Zahlart kann weiterhin an eine gehostete Seite, eine 3D-Secure-Abfrage, ein Popup oder ein eingebettetes Frame übergeben. Wir haben nur die Übergabe des Offline-Scheck-Moduls gemessen, und ein solcher Schritt ist normales E-Commerce-Verhalten und kein Mangel des Checkouts.

Funktionieren meine bestehenden Zahlungs- und Versandmodule weiter?

Vom Konzept her sollten sie das, denn der native Checkout nutzt PrestaShops übliche Ermittlung der Zahlungsoptionen, statt sie zu umgehen, und unsere drei Offline-Zahlarten erschienen und funktionierten ohne Anpassung. Der Vorbehalt: Alles rendert jetzt gleichzeitig auf einem Bildschirm, und genau dort können Annahmen aus dem stufigen Ablauf brechen, etwa bei Versandmodulen, die auf Live-Adressänderungen reagieren, und bei Zahlungsmodulen, die in einem Einseiten-Kontext rendern. Beachten Sie außerdem, dass der Endpunkt für Zahlungsoptionen derzeit zweimal pro Adressänderung abgerufen wird, was relevant ist, wenn Ihre Zahlungsmodule bei jedem Rendering aufwendige Arbeit leisten.

Quellen und Testmethode

Primärquellen, alle öffentlich:

• Introducing One Page Checkout in PrestaShop 9.2, die offizielle Ankündigung im PrestaShop-Build-Blog.
• PrestaShop 9.2 Beta is open for feedback, mit der oben zitierten Vorab-Warnung.
• PrestaShop/ps_onepagecheckout auf GitHub, der Modulquelltext, sein README und die Liste offener Issues.

Methode. Eine saubere Installation von PrestaShop 9.2.0 Beta 1 aus dem offiziellen Docker-Image, hummingbird-Theme, Debug-Modus aus und warmer Produktions-Cache. Der Gastablauf, der Ablauf für wiederkehrende Kunden und der Vergleich mit dem klassischen vierstufigen Checkout wurden jeweils von einem gesteuerten Browser durchlaufen, der Navigationen, XHR-, Fetch- und Dokument-Requests protokollierte, ohne statische Assets, wobei Hauptframe-Navigationen getrennt von AJAX-Aufrufen gezählt wurden. Ladezeiten sind der Median aus fünf Durchläufen mit jeweils zuvor geleertem HTTP-Cache. Zwei Befunde einer früheren Fassung dieses Artikels wurden zurückgezogen, nachdem wir sie darauf zurückführen konnten, dass unser Skript die Versandart programmatisch auswählte statt sie anzuklicken; jede mit echten Klicks aufgegebene Bestellung entsprach der Checkout-Anzeige, geprüft an der Bestellzeile in der Datenbank. Automatisierte Aufnahmen nutzten CSS-Viewports von 1440 px und 375 px; veröffentlichte Bilder wurden für die Darstellung zugeschnitten oder skaliert, ihr Inhalt ist unretuschiert.

Datiert und vorläufig. Diese Messungen beschreiben PrestaShop 9.2.0 Beta 1 mit ps_onepagecheckout 0.6.2, getestet am 27. Juli 2026. Es handelt sich um Vorabsoftware in aktiver Entwicklung, die beschriebenen Fehler können also bis zum stabilen 9.2 längst behoben sein, und neue können auftauchen. Wir haben vor, genau diesen Benchmark beim Release Candidate und erneut bei der stabilen Version zu wiederholen und diesen Artikel mit den neuen Zahlen zu aktualisieren, statt die alten stillschweigend stehen zu lassen. Wenn Sie etwas anderes reproduzieren, sagen Sie uns Bescheid, dann korrigieren wir es.