Checkout Revolution 3.0: One-Page Checkout von Grund auf neu gebaut

Wir haben Checkout Revolution von Grund auf neu gebaut — kein Feature-Bump auf alter Codebasis, sondern eine frische Architektur. Kurzfassung: Das frühere express-checkout-Modul und das breitere checkout-Modul wurden zusammengeführt, der gesamte Ablauf lebt jetzt in einem einzigen Modal auf Basis von Stripes Payment Intents API und läuft von PrestaShop 1.6 bis 9. Dieser Beitrag ist die ehrliche Engineering-Geschichte: was sich geändert hat, warum es sich geändert hat und was das für Ihren Shop bedeutet. Wenn Sie noch prüfen, ob ein one-page checkout überhaupt der richtige Schritt ist, starten Sie mit one-page checkout for PrestaShop und kommen Sie zurück.

Warum neu bauen statt flicken

Das ursprüngliche Modul entstand nach PrestaShop-1.6-Mustern und wurde dann für 1.7, 8.x und 9.x angepasst. Jede Anpassung legte weitere Bedingungen über alte Entscheidungen — AJAX, Formularvalidierung, Payment-Wechsel. Irgendwann kostet das Arbeiten um die alte Struktur mehr als ihr Ersatz. An diesem Punkt waren wir, also haben wir ersetzt.

Wir haben auch unser separates express-checkout-Modul integriert. Zwei überlappende checkout-Produkte bedeuteten zwei Payment-Integrationen, zwei Warenkorb-Pipelines und zwei Stellen, an denen eine Stripe-API-Änderung etwas brechen kann. Jetzt gibt es ein Modul, eine Cart-Pipeline und einen Satz Front Controller für PrestaShop-Versionen. Was heißt das für Sie? Weniger bewegliche Teile bei Upgrades und eine Konfiguration statt zwei.

Was „rebuilt“ tatsächlich geändert hat

Ein Modal statt einer Seitenfolge

PrestaShops Standard-checkout zeigt sich Schritt für Schritt: persönliche Daten, Adresse, Lieferung, Zahlung. Checkout Revolution ersetzt diese Sequenz durch ein einziges Modal: Registrierung oder Gastdaten, Adresse, Versandauswahl und Zahlung in einer Oberfläche, erreichbar von Produktseite, Warenkorb oder jeder Shopseite. Der Kunde verlässt nie den Kontext, in dem er gerade kaufen wollte. Den nativen Ablauf erklären wir in PrestaShop native one-page checkout.

Auf Stripe Payment Intents gebaut

Die Zahlungsschicht basiert auf Stripes Payment Intents API statt auf dem älteren Charge-Flow. Das war der längste Teil des Neubaus, weil er exakt stimmen muss: 3D Secure / Strong Customer Authentication, asynchrone Zahlungsbestätigung und regionale Methoden, die erst nach Verlassen der Seite abschließen. Für Händler bedeutet das digitale Wallets (Apple Pay, Google Pay), Karten mit gespeicherter Wiederverwendung, Banküberweisungen und Buy Now Pay Later über eine Stripe-Verbindung statt einzelner Module pro Anbieter.

Adresseingabe mit weniger Reibung

Adressformulare sind der langweiligste Teil jedes checkout, also greifen wir dort an:

• Google Places autocomplete — Straße tippen, Rest der Adresse kommt aus dem Vorschlag.
• EU VAT validation via VIES — B2B-Kunden geben eine VAT-Nummer ein, die gegen VIES geprüft wird, damit innergemeinschaftliche Nummern direkt korrekt greifen.
• Guest checkout als Standardpfad, mit optionalem Speichern und Kontoerstellung nach der Bestellung. Der Kunde hängt nie vor einer Registrierungswand. Warum das zählt, steht in guest checkout vs account creation.

Social Login, wo es hilft

Wiederkehrende Kunden können sich mit Google, Facebook, Apple oder Microsoft anmelden, statt ein Shop-Passwort zu suchen — nützlich für Käufer, die vor acht Monaten einmal bestellt haben. Es ist optional und standardmäßig aus.

Live-Neuberechnung und Validierung

Weil alles in einem Modal liegt, aktualisiert sich die Summe während der Eingabe: Land wählen, Versandoptionen ändern sich; Carrier wählen, Summe folgt; Gutschein eingeben, Warenkorbregeln validieren in Echtzeit. Das fühlt sich responsiv an, statt wie ein Formular, das man abschickt und hofft.

Wie es neben PrestaShops nativem checkout steht

Die faire Frage für jedes checkout-Modul lautet: Warum nicht nutzen, was PrestaShop liefert? Die Antwort hängt von Version und Wartebereitschaft ab.

Dass PrestaShop einen nativen one-page checkout in 9.2 baut, ist gut für das Ökosystem — wir beschreiben ihn in PrestaShop 9.2 native one-page checkout. Das Modul ist für Shops, die nicht warten können oder wollen, eine ältere Version fahren oder Stripe-Wallet- und B2B-Teile brauchen, die der Core nicht ausliefert. Breitere Trade-offs stehen in unserem PrestaShop checkout optimization guide, die Modul-vs.-Alternativen-Frage in checkout process modules and alternatives.

Kompatibilität und Upgrade

Checkout Revolution zielt auf PrestaShop 1.6 bis 9. Es erkennt Ihre Version und passt die Integration an — auf 1.7.7+ nutzt es den Symfony-Admin-Order-Hook (displayAdminOrderSide), auf älteren Shops den Legacy-Hook (displayAdminOrderLeft). Dasselbe Modul verhält sich also auf 1.6 und 9.x korrekt, ohne dass Sie einen Build wählen.

Wenn Sie das frühere express-checkout-Modul nutzten: Es ist deprecated und in dieses Modul gemerged; Tabellenpräfixe sind jetzt unter mprcheckoutrevolution_ vereinheitlicht. Bestehende Checkout-Revolution-Nutzer aktualisieren über den normalen Modulprozess; Konfiguration bleibt erhalten. Das Aussehen ändert sich, die Einstellungen sind aber eine Obermenge der alten Version.

Was es bewusst nicht tut

Ehrlichkeit zum Scope ist wichtiger als Featurelisten. Checkout Revolution ist ein Stripe-zentrierter express checkout. Wenn Ihr Shop vollständig über einen Payment-Anbieter ohne Stripe-Pfad läuft, greifen Wallet- und BNPL-Vorteile nicht. Es holt auch nicht automatisch Warenkörbe zurück, die vor dem checkout abbrechen; das ist Aufgabe einer E-Mail-Sequenz — siehe abandoned-cart emails und die Automation dahinter. Und kein checkout löst ein tieferes Conversion-Problem upstream; diagnostizieren Sie Lecks zuerst mit why your checkout page is losing you sales.

Messen Sie es im eigenen Shop

Wir geben keine pauschale Conversion-Uplift-Zahl, weil sie davon abhängt, wie schlecht Ihr aktueller checkout ist. Ein Shop mit Pflichtregistrierung und Vier-Schritt-Ablauf gewinnt mehr als ein bereits schlanker. Messen Sie selbst: vor dem Wechsel Cart-to-order-Conversion, checkout-Abbruchrate, durchschnittliche checkout-Dauer und Mobile-vs.-Desktop-Conversion notieren. Nach Aktivierung des Single-Modal-Flows dieselben vier Werte über mindestens 30 Tage und einige hundert Bestellungen vergleichen. Für den breiteren Funnel lesen Sie reducing cart abandonment in PrestaShop.

Das ist der Neubau: ein Modul statt zwei, ein Modal statt einer Schrittfolge, eine Stripe-Zahlungsschicht für die Methoden, die Kunden am Handy nutzen, und gleiches Verhalten von PrestaShop 1.6 bis 9. Das Prinzip bleibt: weniger Tore, weniger Tippen, eine ehrliche Summe ab dem ersten Screen. Die Architektur darunter passt endlich dazu.