Wir haben Checkout Revolution von Grund auf neu gebaut, kein Funktionsupdate auf der alten Codebasis, sondern eine frische Architektur. Die Kurzfassung: Das bisherige Express-Kassenmodul und das breitere Kassenmodul wurden zu einem Modul zusammengeführt, der gesamte Ablauf läuft jetzt in einem einzigen Modal auf Basis der Stripe Payment Intents API, und das Ganze funktioniert von PrestaShop 1.6 bis 9. Dieser Beitrag ist der ehrliche Blick aus der Entwicklung: was sich tatsächlich geändert hat, warum es sich geändert hat und was das für Ihren Shop bedeutet. Wenn Sie noch abwägen, ob eine One-Page-Kasse überhaupt der richtige Schritt ist, beginnen Sie mit One-Page-Kasse für PrestaShop und kommen Sie danach hierher zurück.
Warum neu bauen statt flicken
Das ursprüngliche Modul wurde für die Muster von PrestaShop 1.6 geschrieben und anschließend schrittweise an 1.7, 8.x und 9.x angepasst. Jede Anpassung legte eine weitere Bedingung auf die vorherige, AJAX-Verarbeitung, Formularvalidierung und Wechsel der Zahlungsmethode trugen alle noch Entscheidungen mit sich, die für eine inzwischen Jahre alte Plattformversion getroffen wurden. Irgendwann übersteigen die Kosten, um die alte Struktur herumzuarbeiten, die Kosten, sie zu ersetzen. Diesen Punkt hatten wir erreicht, also haben wir sie ersetzt.
Außerdem haben wir unser separates Express-Kassenmodul in dieses Modul integriert. Zwei sich überschneidende Kassenprodukte zu pflegen bedeutete zwei Sätze an Zahlungsintegrationen, zwei Warenkörbe und zwei Stellen, an denen eine Änderung der Stripe API etwas beschädigen konnte. Jetzt gibt es ein Modul, eine Warenkorb-Pipeline und einen Satz Front-Controller, die über PrestaShop-Versionen hinweg kompatibel gehalten werden. Was bedeutet das für Sie? Weniger bewegliche Teile, die bei einem Upgrade kollidieren können, und eine Konfiguration an einer Stelle statt an zwei.
Was „neu gebaut“ tatsächlich verändert hat
Ein Modal statt einer Seitenabfolge
Die Standardkasse von PrestaShop, selbst in 1.7 und neuer, wo sie unter einer einzigen URL liegt, öffnet sich Schritt für Schritt: persönliche Daten, dann Adressen, dann Lieferung, dann Zahlung, wobei jeder Abschnitt erst sichtbar wird, wenn der vorherige abgeschlossen ist. (Wie dieser native Ablauf genau funktioniert, einschließlich des order-Controllers und der dahinterliegenden Schrittklassen, erläutern wir in Native One-Page-Kasse in PrestaShop.) Checkout Revolution ersetzt diese Abfolge durch ein einziges Modal: Registrierung oder Gastdaten, Adresse, Versandauswahl und Zahlung auf einer Oberfläche, erreichbar von einer Produktseite, aus dem Warenkorb oder von jeder beliebigen Shopseite. Der Kunde verlässt zum Bezahlen nie das, was er gerade betrachtet hat.
Auf Stripe Payment Intents aufgebaut
Die Zahlungsebene basiert auf der Stripe Payment Intents API statt auf dem älteren Charge-basierten Ablauf. Das war der Teil des Neubaus, der am längsten gedauert hat, weil er exakt stimmen muss. Hier werden 3D Secure / Strong Customer Authentication, asynchrone Zahlungsbestätigung und regionale Zahlungsmethoden verarbeitet, die erst abgeschlossen werden, nachdem der Kunde die Seite verlassen hat. Für Händler bedeutet das Unterstützung für digitale Wallets (Apple Pay, Google Pay), Karten mit Wiederverwendung gespeicherter Kartendaten für wiederkehrende Käufer, Banküberweisungen und Buy Now Pay Later, also eine breite Auswahl an Methoden über eine einzige Stripe-Verbindung statt über ein separates Modul je Anbieter.
Adresseingabe mit weniger Reibung
Adressformulare gehören zu den mühsamsten Teilen jeder Kasse, deshalb geht der Neubau sie direkt an:
- Google Places autocomplete, beginnen Sie mit der Eingabe einer Straße, und der Rest der Adresse wird aus dem Vorschlag ergänzt, statt fünf Felder von Hand durchzutippen.
- EU-USt-IdNr.-Prüfung über VIES. B2B-Kunden geben eine Umsatzsteuer-Identifikationsnummer ein, die gegen den VIES-Dienst der Europäischen Kommission geprüft wird. Eine gültige innergemeinschaftliche Nummer wird dadurch direkt bei der Eingabe korrekt berücksichtigt, statt später still zu scheitern.
- Gastbestellung als Standardweg, mit der optionalen Möglichkeit, Daten zu speichern und nach der Bestellung ein Konto anzulegen. Der Kunde wird nie hinter einer Registrierungswand ausgebremst. Die Daten dazu, warum das wichtig ist, finden Sie in Gastbestellung vs. Kontoerstellung.
Social Login, wo er hilft
Wiederkehrende Kunden können sich mit Google, Facebook, Apple oder Microsoft anmelden, statt sich an ein Shop-Passwort zu erinnern, hilfreich für Käufer, die vor acht Monaten einmal bestellt haben und nicht mehr wissen, dass sie überhaupt ein Konto angelegt hatten. Die Funktion ist optional und standardmäßig deaktiviert; aktivieren Sie sie nur, wenn sie zu Ihrer Zielgruppe passt.
Live-Neuberechnung und Validierung
Da alles in einem Modal stattfindet, wird die laufende Summe neu berechnet, sobald der Kunde etwas ändert: Land auswählen und die Versandoptionen aktualisieren sich, Versanddienstleister wählen und die Summe passt sich an, Gutschein eingeben und er wird in Echtzeit gegen Ihre Warenkorbregeln geprüft statt erst nach einem Neuladen der Seite. Diese Unmittelbarkeit macht den Unterschied zwischen einer Kasse, die reaktionsschnell wirkt, und einer, die sich wie ein Formular anfühlt, das man abschickt und dann hofft.
Wie sie neben der nativen PrestaShop-Kasse steht
Eine berechtigte Frage bei jedem Kassenmodul lautet: Warum nicht einfach das nutzen, was PrestaShop mitliefert? Die ehrliche Antwort hängt von Ihrer Version und Ihrer Bereitschaft zu warten ab.
| Ansatz | Was Sie bekommen | Der Haken |
|---|---|---|
| Native Schritt-für-Schritt-Kasse (PS 1.7–9.1) | Eine URL, vier aufeinanderfolgende Schritte, keine Zusatzkosten, im Core enthalten | Weiterhin Schritt für Schritt gesperrt; eine Lieferoption zu ändern bedeutet, einen abgeschlossenen Schritt erneut zu öffnen |
| Native One-Page-Kasse (PrestaShop 9.2, in Entwicklung) | Ein echter Ablauf auf einer Seite, kostenlos mit der Plattform | Noch nicht ausgeliefert, für das 9.2-Release geplant und nur nach Upgrade nutzbar |
| Checkout Revolution | Express-Kasse im Einzelmodal für 1.6–9, Stripe-Wallets/BNPL, Google Places, VIES, Social Login | Ein lizenziertes Modul; die Zahlungsseite ist Stripe-zentriert |
Dass PrestaShop eine native One-Page-Kasse in 9.2 einbaut, ist wirklich gut für das Ökosystem. Sie befindet sich in Entwicklung, ist noch nicht veröffentlicht, und wir zeigen in Native One-Page-Kasse in PrestaShop 9.2, was der öffentliche Code heute enthält. Das Modul ist für Shops gedacht, die auf dieses Release nicht warten können oder wollen, eine ältere Version betreiben, die es nie erhalten wird, oder die Stripe-Wallet- und B2B-Bausteine möchten, die der Core nicht mitliefern wird. Wenn Sie die grundsätzlichen Kompromisse zwischen Schritt-für-Schritt-Kasse und Ein-Seiten-Kasse abwägen, behandelt das unser Leitfaden zur PrestaShop-Kassenoptimierung; die Frage Modul versus Alternativen erklären wir in Kassenprozess-Module und Alternativen.
Kompatibilität und Upgrade
Checkout Revolution zielt auf PrestaShop 1.6 bis 9. Es erkennt Ihre Version und passt die Integration an, ab 1.7.7 hängt es sich in das Admin-Bestellpanel der Symfony-Ära ein (displayAdminOrderSide), in älteren Shops fällt es auf den Legacy-Hook zurück (displayAdminOrderLeft), damit sich dasselbe Modul in einem 1.6-Shop und in einem aktuellen 9.x-Shop korrekt verhält, ohne dass Sie einen eigenen Build auswählen müssen.
Dieses versionsadaptive Hooking ist genau die Art Detail, die darüber entscheidet, ob ein Modul ein PrestaShop-Upgrade übersteht oder still aufhört zu rendern. In der Praxis bedeutet das, den Hook bei der Installation aus der laufenden Version zu wählen, statt einen fest zu kodieren:
// Register the admin-order panel on the hook the running PS version exposes.
$adminOrderHook = version_compare(_PS_VERSION_, '1.7.7', '>=')
? 'displayAdminOrderSide' // Symfony-era order page (1.7.7+, 8.x, 9.x)
: 'displayAdminOrderLeft'; // legacy order page (1.6–1.7.6)
$this->registerHook($adminOrderHook);Entscheidend sind nicht die beiden Hook-Namen, sondern dass das Modul _PS_VERSION_ liest und sich anpasst, sodass Sie nie von Hand einen Build passend zu Ihrer Plattform wählen müssen. Dasselbe Prinzip zieht sich durch die Front-Controller und Templates.
Wenn Sie das bisherige Express-Kassenmodul verwendet haben, beachten Sie bitte: Es wurde eingestellt und in dieses Modul integriert; die Präfixe der Datenbanktabellen sind jetzt einheitlich unter mprcheckoutrevolution_ zusammengeführt. Bestehende Nutzer von Checkout Revolution aktualisieren über den normalen Modul-Update-Prozess, die Konfiguration bleibt erhalten. Das Erscheinungsbild der Kasse ändert sich. Das neue Design ist aufgeräumter, aber die Einstellungen sind eine Obermenge dessen, was die ältere Version bot. Es muss also nichts von Grund auf neu konfiguriert werden.
Was es bewusst nicht tut
Ehrlichkeit beim Umfang ist wichtiger als eine lange Funktionsliste. Die Express-Zahlungsfunktionen von Checkout Revolution sind auf Stripe ausgerichtet: Ohne Stripe entfallen die Wallet- und BNPL-Vorteile, aber der einseitige Ablauf, die auf Gastbestellungen ausgerichtete Kasse und die Adresswerkzeuge bleiben unabhängig vom Zahlungsanbieter. Außerdem gewinnt es für sich genommen keine Warenkörbe zurück, die vor Erreichen der Kasse abgebrochen werden; das ist eine andere Aufgabe, die über eine E-Mail-Sequenz gelöst wird, siehe E-Mails bei abgebrochenen Warenkörben und die Automatisierung, die sie ausführt. Und keine Kasse, so gut sie auch ist, behebt ein tieferliegendes Conversion-Problem weiter oben im Funnel; wenn Sie nicht sicher sind, wo Ihr Leck liegt, diagnostizieren Sie es zuerst mit Warum Ihre Kassenseite Verkäufe kostet.
Messen Sie es in Ihrem eigenen Shop
Wir geben Ihnen keine pauschale Zahl für den Conversion-Uplift, denn die ehrliche Zahl hängt vollständig davon ab, wie holprig Ihre aktuelle Kasse ist, ein Shop mit erzwungener Registrierung und einem nativen Vier-Schritt-Ablauf hat deutlich mehr zu gewinnen als einer, der bereits schlank ist. Messen Sie es also selbst. Bevor Sie umstellen, erfassen Sie vier Kennzahlen aus Ihren Analytics: Warenkorb-zu-Bestellung-Conversion-Rate, Abbruchrate in der Kasse, durchschnittliche Zeit bis zum Abschluss der Bestellung und Conversion nach Mobilgerät versus Desktop. Nach Aktivierung des Einzelmodal-Ablaufs vergleichen Sie dieselben vier Werte über mindestens 30 Tage und einige hundert Bestellungen, genug Volumen, um einen echten Trend vom wöchentlichen Rauschen zu trennen. Für das umfassendere Vorgehen zur Verringerung von Abbrüchen über den gesamten Funnel hinweg lesen Sie Warenkorbabbrüche in PrestaShop reduzieren.
Das ist der Neubau: ein Modul statt zwei, ein Modal statt einer Schrittfolge, eine Stripe-Zahlungsebene, die die Methoden abdeckt, nach denen Kunden auf dem Smartphone tatsächlich greifen, und dasselbe Verhalten von PrestaShop 1.6 bis 9. Das Prinzip hat sich nicht geändert, weniger Hürden, weniger Tipparbeit, eine Summe, die ab dem ersten Bildschirm ehrlich ist. Die Architektur darunter ist es endlich auch.
FAQ
Ich nutze bereits die alte Checkout Revolution, zerstört das Update meine Konfiguration?
Nein. Bestehende Installationen von Checkout Revolution werden über den normalen Modul-Update-Prozess aktualisiert, und Ihre Konfiguration bleibt erhalten. Die neuen Einstellungen sind eine Obermenge der alten, also muss nichts von Grund auf neu eingerichtet werden, aber das Erscheinungsbild der Kasse wechselt zum aufgeräumteren neuen Design. Prüfen Sie es deshalb in einer Staging-Kopie, bevor Sie live gehen, damit die Optik keine Überraschung ist.
Ich habe Ihr separates Express-Kassenmodul verwendet. Was passiert damit?
Es wurde eingestellt und in Checkout Revolution integriert. Die Express-Kasse ist jetzt Teil dieses einen Moduls, kein zweites Produkt mehr. Die Datenbanktabellen sind unter dem Präfix mprcheckoutrevolution_ vereinheitlicht. Zwei sich überschneidende Kassenmodule parallel zu betreiben war eine Quelle für Upgrade-Konflikte und doppelte Zahlungsintegrationen; genau das beseitigt die Zusammenführung.
Muss ich Stripe verwenden?
Die Wallet-, gespeicherte-Karten- und Buy-Now-Pay-Later-Funktionen basieren auf der Stripe Payment Intents API, daher benötigen diese konkreten Vorteile eine Stripe-Verbindung. Wenn Ihr Shop vollständig über einen Anbieter ohne Stripe-Pfad läuft, greift die Express-Zahlungsseite nicht, und das Modul ist möglicherweise nicht die richtige Lösung, das sagen wir lieber klar, statt es zu überverkaufen. Der One-Page-Ablauf, die Gastbestellung als Standard und die Adresswerkzeuge hängen nicht davon ab, welches Gateway rendert; die zentralen Zahlungsmethoden jedoch schon.
Es läuft auf PrestaShop 1.6 bis 9. Muss ich für meine Version einen anderen Build auswählen?
Nein. Es ist ein Modul, das Ihre PrestaShop-Version bei der Installation liest und sich anpasst, zum Beispiel mit displayAdminOrderSide ab 1.7.7+ und dem Legacy-displayAdminOrderLeft in älteren Shops. Sie installieren dasselbe Paket, egal ob Sie auf 1.6 oder einer aktuellen 9.x-Version sind.
PrestaShop 9.2 bekommt eine native One-Page-Kasse, sollte ich einfach darauf warten?
Das hängt von Ihrer Version und Ihrem Zeitplan ab. Native OPC ist für 9.2 in Entwicklung, noch nicht ausgeliefert, und sie braucht eine Stabilisierungsphase sowie ein Upgrade auf 9.2, bevor Sie sie nutzen können. Wenn Ihre Kasse heute schlecht konvertiert und Sie auf 1.6–9.1 sind, kostet das Warten über einen oder mehrere Release-Zyklen selbst verlorene Bestellungen. Den ehrlichen Umfang des nativen Builds erläutern wir in Native One-Page-Kasse in PrestaShop 9.2, damit Sie anhand echter Fakten statt anhand der Roadmap entscheiden können.