Guter Checkout in der Praxis: Lektionen aus Projekten in den Niederlanden, der Schweiz und der Türkei

Notizen zu Hyvä Checkout-Projekten auf Magento 2-Shops in den Niederlanden, der Schweiz und der Türkei

Die Kasse ist die eine Seite in einem Magento-Shop, wo jede langsame Sekunde und jeder Fehler direkt Geld kostet. Ich habe Hyvä Checkout in Magento 2-Shops in den Niederlanden, der Schweiz und der Türkei implementiert, und ich habe auch an Shops gearbeitet, die ein Hyvä-Frontend mit dem Luma-Checkout im Hintergrund betreiben. Beide Setups können funktionieren. Sie scheitern auf unterschiedliche Weise.

Dieser Artikel behandelt, was Hyvä Checkout tatsächlich verändert, wie sich die Integrationen, die normalerweise ein Projekt bestimmen (PostNL, DHL und die Zahlungsanbieter), verhalten, wie ich einen Migrationsprozess vom Luma-Checkout angehe und wann es klüger ist, Luma beizubehalten.

Was ist Hyvä Checkout?

Hyvä Checkout ist ein separates Produkt vom Hyvä-Theme. Das Theme ersetzt das Luma-Frontend von Magento. Der Checkout ersetzt den standardmäßigen Checkout von Magento: die große Knockout.js- und RequireJS-Anwendung, die jeder Luma-Shop mitliefert.

Es basiert auf Magewire, einer Livewire-ähnlichen Komponentenebene für Magento. Jedes Element des Checkouts (Adresse, Versandmethoden, Zahlungsmethoden, Gesamtsummen) ist eine PHP-Komponente, die auf dem Server gerendert wird, mit Alpine.js für die kleinen interaktiven Teile. Wenn ein Kunde eine Versandmethode auswählt, wird die Komponente auf dem Server aktualisiert und sendet das geänderte HTML zurück. Es gibt keine große clientseitige Anwendung, die geladen, initialisiert und synchron gehalten werden muss.

Seit November 2025 ist das Hyvä-Theme selbst kostenlos und Open Source. Hyvä Checkout hat weiterhin eine kommerzielle Lizenz: Zum Zeitpunkt des Schreibens liegt der Preis bei etwa 1.000 € pro Magento-Installation, einschließlich des ersten Jahres an Updates, oder es ist Teil des Hyvä Commerce-Abonnements. Überprüfen Sie hyva.io für die aktuellen Preise, bevor Sie Ihr Budget planen.

Hyvä Checkout vs das Luma Checkout-Fallback

Ein Hyvä-Shop muss nicht Hyvä Checkout verwenden. Das Fallback-Modul (hyva-themes/magento2-luma-checkout) schaltet das Hyvä-Theme auf der Checkout-Seite aus und lädt dort den standardmäßigen Luma-Checkout mit RequireJS, Knockout und den Luma-Stilen. Alles, was in einem Luma-Shop funktioniert, funktioniert dort ebenfalls.

	Hyvä Checkout	Luma Checkout-Fallback
Rendering	Server-seitige Komponenten (Magewire) mit Alpine.js	Client-seitige Knockout.js-Anwendung über RequireJS
JavaScript an der Kasse	Klein	Der vollständige Luma-Checkout-Stack
Aussehen und Bedienung	Dasselbe Tailwind-Designsystem wie der Onlineshop	Separate Luma-Styling, getrennt gehalten
Anpassen	PHP-Komponenten und -Vorlagen	Knockout UI-Komponenten, Mixins, Layout-XML
Drittanbieter-Module	Benötigen Sie eine Hyvä Checkout-Integration	Luma-kompatible Module funktionieren wie sie sind
Lizenz	Kommerziell	Kostenlos, mit dem Thema

Die Vorteile, die tatsächlich sichtbar werden

1. Ein leichterer Checkout auf Mobilgeräten

Der Luma-Checkout lädt Dutzende von JavaScript-Dateien, bevor ein Kunde eine Adresse eingeben kann. Auf Mittelklasse-Handys ist das der Punkt, an dem der Checkout langsam wirkt: Verzögerungen bei den Taps, Felder, die springen, während die Seite initialisiert. Hyvä Checkout rendert das Formular auf dem Server und liefert deutlich weniger JavaScript. Man sieht es an der Interaktionsreaktionsfähigkeit (INP) im Checkout und daran, wie schnell das erste Feld nutzbar ist.

2. Weniger stille Fehler

Die meisten Checkout-Fehler, die ich in Luma-Shops behoben habe, waren für den Shop-Besitzer unsichtbar: eine JavaScript-Abhängigkeit, die in einer bestimmten Situation nicht geladen wurde, ein Mixin aus einem Modul, das ein anderes überschreibt, eine Versandmethode, die für angemeldete Kunden verschwunden ist. In einem dieser Fälle führte die Behebung einer einzigen JavaScript-Abhängigkeit zu einem Anstieg der abgeschlossenen Checkouts um 11 % (die Geschichte ist in meinem Artikel über Magento Conversion-Optimierung zu finden). Mit serverseitig gerenderten Komponenten gibt es im Browser deutlich weniger bewegliche Teile, sodass es weniger dieser Fehler zu finden gibt.

3. Änderungen werden günstig

Ein Feld hinzufügen, Schritte neu anordnen, ein Lieferversprechen neben einer Versandmethode anzeigen: Das bedeutet in Luma Knockout-Vorlagen, UI-Komponenten und Mixins sowie einen Entwickler, der sich gut damit auskennt. Im Hyvä Checkout ist es eine PHP-Komponente und eine Vorlage. Kleine Verbesserungen im Checkout hören auf, Projekte zu sein.

4. Ein Designsystem

Mit dem Fallback ist der Checkout eine Luma-Insel innerhalb eines Hyvä-Shops: unterschiedliche CSS, unterschiedliche Komponenten, zwei Stellen, um einen Button zu ändern. Hyvä Checkout verwendet dasselbe Tailwind-Designsystem wie der Rest des Shops, sodass es aussieht und sich verhält wie der Shop, aus dem der Kunde gerade gekommen ist.

5. Ihre eigenen Schritte und Layout

Hyvä Default ist ein mehrstufiger Checkout, und die Schritte sowie deren Inhalte sind in Layout-Dateien definiert, die Sie ändern können, einschließlich eines Ein-Seiten-Flows. Welche Variante besser konvertiert, hängt von Ihren Kunden ab, und Sie können es testen, anstatt zu raten.

Gute Checkout-Integration: PostNL, DHL und Zahlungsanbieter

In der Praxis entscheiden die Integrationen über das Projekt, nicht der Checkout selbst. Vor jeder Schätzung liste ich jedes Modul auf, das den Checkout berührt, und überprüfe jedes einzelne gegen Hyvä’s öffentlichen Integrations-Tracker und den eigenen Hyvä-Support des Anbieters.

PostNL

PostNL veröffentlicht ein Hyvä Checkout-Kompatibilitätsmodul (postnl/module-hyva-checkout), das auf seiner regulären Magento 2-Erweiterung basiert. Es bringt Abholpunkte und die Auswahl des Lieferdatums in Hyvä Checkout. Zwei Dinge, die ich bei jedem Projekt überprüfe: die Versionspaarung zwischen den beiden Modulen, da das Kompatibilitätsmodul eine aktuelle PostNL-Erweiterung erfordert, und wie sich die Lieferoptionen aktualisieren, wenn sich die Postleitzahl ändert, denn dort bemerken die Kunden Verzögerungen.

DHL

Für DHL Paket gibt es ein Begleitmodul (dhlparcel/magento2-plugin-hyva) für die DHL Paket Versanderweiterung, mit dem ServicePoint-Locator und in den Niederlanden mit Lieferzeitfenstern. Es ist neu (erstmals veröffentlicht im Januar 2026), daher teste ich es gegen die genau verwendeten Versionen, anstatt anzunehmen, dass es funktioniert. Wenn Sie über Sendcloud versenden, benötigen die DHL-Servicepunkte die separate Hyvä-Kompatibilitätsbrücke von Sendcloud. Andere DHL-Integrationen sind separate Produkte mit eigener Hyvä-Unterstützung oder keiner.

Zahlungsanbieter

Mollie, Adyen, Buckaroo, MultiSafepay, Pay., PayPal, Stripe, Klarna und Worldline erscheinen alle auf Hyväs Liste der Zahlungsintegrationen, sodass die meisten niederländischen und westeuropäischen Geschäfte abgedeckt sind, iDEAL eingeschlossen über ihren Zahlungsanbieter. Jede Integration ist ein separates Modul neben der eigenen Erweiterung des Anbieters, mit eigenen Versionsanforderungen.

Was unterscheidet die Niederlande, die Schweiz und die Türkei?

• Niederlande. iDEAL ist die Zahlungsmethode, die zuerst getestet werden sollte. Die Adresseneingabe sollte die Postleitzahl plus Hausnummer-Suche verwenden; Postcode.nl hat Hyvä Checkout-Integrationen. Kunden erwarten PostNL-Abholstellen und einen Liefertermin.
• Schweiz. Kunden erwarten TWINT und PostFinance, normalerweise über einen Schweizer Zahlungsanbieter wie Datatrans, Saferpay oder Wallee. Zum Zeitpunkt des Schreibens stehen diese nicht auf der Liste von Hyvä, daher sollten Sie zuerst beim Anbieter nachfragen und gegebenenfalls ein benutzerdefiniertes Magewire-Zahlungskomponente einplanen. Mehrere Sprachen und CHF-Preise in einer Installation müssen ebenfalls pro Store-Ansicht getestet werden.
• Türkei. Kartenzahlungen erfolgen über lokale Gateways mit 3D Secure-Weiterleitungen und Ratenzahlungsoptionen (taksit) pro Karte. Lokale Gateways stehen auch nicht auf der Liste von Hyvä, daher planen Sie eine Zahlungs-Komponente, die die Weiterleitung zurück zum Shop verarbeitet und die Ratenzahlungsübersicht korrekt anzeigt.

Wie migriere ich vom Luma-Checkout zum Hyvä-Checkout

1. Inventar. Jedes Modul, das den Checkout berührt: Versand, Zahlung, Adressvalidierung, benutzerdefinierte Felder, B2B-Felder wie USt-IdNr. oder Bestellnummer, Geschenkoptionen, Tracking-Skripte.
2. Klassifizieren. Jedes Modul funktioniert entweder nativ, hat eine Hyvä Checkout-Integration oder muss entwickelt werden. Die dritte Gruppe legt das Budget und den Zeitrahmen fest.
3. Tracking neu aufbauen. Datenlayer-Pushes von Luma-Checkout-Skripten funktionieren nicht im Hyvä Checkout. Die GA4-Ereignisse begin_checkout, add_shipping_info, add_payment_info und purchase müssen erneut implementiert und mit den Bestelldaten abgeglichen werden. Es ist auch der richtige Zeitpunkt, um das Kaufereignis serverseitig zu senden.
4. Testen Sie echte Geldflüsse in der Staging-Umgebung. Jede Zahlungsmethode im Sandbox-Modus, fehlgeschlagene und stornierte Zahlungen, die Weiterleitung zurück von 3D Secure und jede Versandmethode für jedes Land, in das Sie versenden.
5. Wechsel pro Store-Ansicht. Der aktive Checkout wird in der Konfiguration pro Website oder Store-Ansicht ausgewählt, sodass Sie einen Markt zuerst verschieben, den Luma-Checkout bei den anderen beibehalten und vergleichen können.
6. Vier Wochen messen vor der nächsten Änderung.

Wann der Luma-Checkout immer noch die richtige Wahl ist

Hyvä Checkout ist mein Standard für neue Hyvä-Projekte, aber nicht jedes Mal. Ich behalte den Luma-Checkout, wenn:

• ein Zahlungs- oder Versandmodul, von dem das Unternehmen abhängt, hat keine Hyvä Checkout-Integration, und der Aufbau eines solchen passt noch nicht ins Budget;
• der Shop verlässt sich auf eine stark angepasste One-Step-Checkout-Erweiterung, die den Betriebs- und Supportteams gut bekannt ist;
• Das Startdatum ist festgelegt und der Storefront ist der größere Gewinn: Zuerst den Hyvä Storefront ausliefern und den Checkout in einer zweiten Phase verschieben.

Ein Hyvä-Storefront mit einem Luma-Checkout ist eine gültige Konfiguration, aber der Warenkorb wird zum Übergabepunkt zwischen zwei Frontends. Ich habe über diese Grenze in einer Fallstudie zu einem Hyvä-Storefront mit einem Luma-Checkout geschrieben.

Was vor und nach der Messung zu beachten ist

Hyvä Checkout ist ein Mittel, kein Ergebnis. Vor dem Wechsel zeichne ich eine Basislinie auf, und vier Wochen danach vergleiche ich die gleichen Zahlen:

• Abschluss des Checkout-Schritts, von begin_checkout bis purchase, nach Gerät.
• Zahlungserfolgsquote pro Methode, einschließlich fehlgeschlagener und stornierter Zahlungen.
• INP und LCP beim Checkout für mobile Besucher, basierend auf Felddaten und nicht nur auf Lighthouse (siehe den Core Web Vitals Leitfaden).
• JavaScript-Fehler an der Kasse.
• Support-E-Mails und Tickets zu Bestellungen, die nicht erfolgreich waren.

Für den Kontext: Das Baymard Institute gibt die durchschnittliche dokumentierte Warenkorbabbruchrate mit etwa 70% an, und 18% der US-Einkäufer geben an, dass sie eine Bestellung abgebrochen haben, weil der Checkout zu lang oder kompliziert war. Ein schneller Checkout, der für jeden Kunden funktioniert, löst nicht alles, aber er ist der Teil, den Sie kontrollieren können.

Hyvä Checkout-Checkliste

1. Jedes Checkout-Modul wurde aufgelistet und mit dem Hyvä-Integrations-Tracker abgeglichen.
2. PostNL, DHL und andere Versandmodul-Varianten, die von ihren Hyvä-Modulen unterstützt werden.
3. Jede Zahlungsmethode, die im Sandbox getestet wurde: Erfolg, Misserfolg, Stornierung, 3D Secure.
4. Adresseneingabe, die zum Markt passt, wie z.B. Postleitzahlensuche in den Niederlanden.
5. GA4 Checkout-Ereignisse neu aufgebaut und mit echten Bestellungen abgeglichen.
6. Eine Basislinie, die vor dem Schalter aufgezeichnet wurde.
7. Rollout pro Store-Ansicht, wobei der Luma-Checkout als Fallback beibehalten wird, bis die Zahlen stabil sind.

Häufig gestellte Fragen

Ist Hyvä Checkout kostenlos?

Nein. Das Hyvä-Theme ist seit November 2025 kostenlos und Open Source, aber Hyvä Checkout hat eine separate kommerzielle Lizenz. Ein Hyvä-Shop kann stattdessen den kostenlosen Luma-Checkout-Fallback verwenden.

Funktioniert Hyvä Checkout mit PostNL und DHL?

Ja, über Kompatibilitätsmodule: postnl/module-hyva-checkout für PostNL und dhlparcel/magento2-plugin-hyva für DHL Parcel. Beide basieren auf der regulären Magento-Erweiterung des Versanddienstleisters und benötigen passende Versionen.

Kann ich das Hyvä-Theme mit dem Luma-Checkout verwenden?

Ja. Das Fallback-Modul lädt den standardmäßigen Luma-Checkout auf der Checkout-Route. Es ist eine gültige erste Phase, aber dann verwalten Sie zwei Frontends: den Hyvä-Shop und den Luma-Checkout. Das Gegenteil existiert ebenfalls: Der Hyvä-Checkout kann in einem Shop betrieben werden, der weiterhin das Luma-Theme verwendet.

Wie lange dauert eine Hyvä Checkout-Migration?

Es hängt von den Integrationen ab, nicht vom Checkout. Wenn jedes Zahlungs- und Versandmodul bereits eine Hyvä Checkout-Integration hat, ist es eine Frage von Wochen; jedes Modul, das gebaut werden muss, kommt dazu.

Abschließende Gedanken

Hyvä Checkout macht die wichtigste Seite eines Magento-Shops leichter, einfacher zu ändern und schwerer zu beschädigen. Die Arbeit liegt in den Integrationen: PostNL, DHL, den Zahlungsanbietern und den Marktdetails, die zwischen den Niederlanden, der Schweiz und der Türkei variieren.

Wenn Sie den Umzug planen, beginnen Sie mit dem Luma zu Hyvä Migrationsleitfaden, oder lassen Sie mich zuerst Ihren Checkout ansehen: sehen Sie sich meine Magento und Hyvä Arbeiten oder das Checkout-Konvertierungs-Audit an.