Der vollständige Leitfaden zur Implementierung von Hyvä Checkout

Hyvä Checkout ist das Produkt mit dem höchsten ROI in der Hyvä-Produktlinie. Die Abschlussrate beim mobilen Checkout steigt um 8–15% in den Builds, die wir gemessen haben. Die JavaScript-Datenlast beim Checkout sinkt um ~70%. Der visuelle + UX-Vorteil ist offensichtlich für jeden, der den Standard-Checkout von Magento auf einem Mittelklasse-Android-Gerät ausprobiert hat.

Aber die Implementierung ist nuancierter, als das Marketing es darstellt. Dies ist der End-to-End-Leitfaden, was hinein gehört, was Sie aufhält und der realistische Zeitrahmen.

Was Hyvä Checkout tatsächlich ist

Ein einseitiger Alpine.js-Checkout, der den Standard-Checkout von Magento (Knockout + RequireJS) ersetzt. Das PHP-Backend (Versandkosten, Zahlungsabwicklung, Steuerberechnung, Bestellaufgabe) ändert sich nicht. Nur die Rendering-Schicht ändert sich.

Installierbar auf zwei Arten:

• Auf Hyvä Theme, am häufigsten; der Shop ist bereits Hyvä, der Checkout folgt.
• Als Checkout-Insel auf Luma, der Rest der Seite bleibt auf Luma, nur die Checkout-Seite wird Hyvä-gerendert.

Beide Varianten funktionieren. Die erste ist einfacher, da das Styling-System bereits vorhanden ist.

Vorbereitungen: Was Sie vor Woche 1 benötigen

1. Hyvä Checkout-Lizenz, direkt von Hyvä Themes abgerechnet, ~£1,000–£3,000 pro Domain.
2. Aktueller Bestand an Zahlungs-, Versand- und Betrugsmodulen, Anbieter + Version + Lizenzstatus für jedes.
3. Liste aller benutzerdefinierten Checkout-Felder, Geschenknachricht, Lieferanweisungen, Mehrwertsteuernummer, B2B-Felder.
4. Eine Testbestellbasis, erfassen Sie jetzt die aktuelle Abschlussrate für mobile Bestellungen, damit Sie den Anstieg nach dem Start messen können.

Die Vorbereitungen sind eine 3–5-tägige Übung. Vor dem Kickoff abgeschlossen, damit Woche 1 für den Aufbau und nicht für die Verwaltung genutzt wird.

Woche für Woche Implementierung

Eigenständiger Hyvä Checkout-Bau (insgesamt 2–5 Wochen)

Woche 1, Installation + Basis-Styling

• Hyvä Checkout-Paket installiert (composer require hyva-themes/magento2-default-theme-checkout oder Äquivalent für Ihre Lizenz)
• Marken-System Tailwind-Konfiguration auf die Checkout-Vorlagen angewendet
• Adressformulare, Zahlungsmethoden-Auswahl, Versandmethoden-Auswahl werden alle unter Hyvä gerendert
• Warenkorb-Zusammenfassungsblock auf der rechten Seite (oder welches Layout Sie lizenziert haben)

Woche 2, Zahlungs- + Versandintegration

• Jede aktive Zahlungsmethode für Hyvä Checkout neu gestaltet
• Versanddienstleister-Integrationen neu gestaltet, wo nötig
• Steuer- + Mehrwertsteuerberechnungslogik in den entsprechenden Rechtsordnungen überprüft
• Gespeicherte Karten / gespeicherte Adressen / Gast-Checkout-Workflows getestet

Woche 3, Betrug + Komplexitätsschicht

• Betrugs-/Risiko-Module (Signifyd, Riskified usw.) Integration übernommen
• Benutzerdefinierte Checkout-Felder hinzugefügt (Geschenknachricht, Lieferanweisungen, B2B-Felder)
• Bestellaufgabe-Workflow end-to-end mit echten Testbestellungen getestet
• Schema.org Order + InvoiceableOrder strukturierte Daten erhalten

Woche 4, Leistung + Barrierefreiheit

• Lighthouse-Mobil-Audit auf der Checkout-Seite, 90+ als Ausstiegskriterium
• Barrierefreiheitsprüfung, Tastaturnavigation, Screenreader, ARIA-Labels
• Cross-Browser-QA auf iOS Safari, Android Chrome, Desktop

Woche 5, UAT + Übergang

• Vorab-UAT mit echten Bestellungen auf der Staging-Seite
• Basisrate für die Konversionsrate vor dem Übergang erfasst, um messbare Vergleiche zu ermöglichen
• Übergang am Sonntag außerhalb der Hauptzeiten, 30–60 Minuten Wartungsfenster
• 72 Stunden nach dem Start Monitoring mit Echtzeitüberwachung der Abschlussrate

Für einen Aufbau auf einem bestehenden Hyvä Theme beträgt der Zeitrahmen typischerweise 2–3 Wochen. Für einen Checkout-nur-auf-Luma-Bau 3–5 Wochen, da die Integrationspunkte nicht standardisiert sind.

Zahlungsgateways, was funktioniert, was nicht

Von Anbietern unterstützte Hyvä Checkout-Integrationen ab 2026:

Gateway	Hyvä Checkout Unterstützung
Stripe	Anbieterbereitgestellt
Adyen	Anbieterbereitgestellt
Klarna	Anbieterbereitgestellt
PayPal	Anbieterbereitgestellt
Worldpay	Anbieterbereitgestellt
Braintree	Anbieterbereitgestellt
Mollie	Anbieterbereitgestellt
Authorize.Net	Benutzerdefinierte Integration erforderlich
Sage Pay	Benutzerdefinierte Integration erforderlich
Die meisten regionalen UK-Gateways	Benutzerdefiniert, normalerweise 1–2 Wochen Aufbau

Für Gateways ohne Anbieterintegration ist ein benutzerdefiniertes Hyvä Checkout-Zahlungsmethodenmodul typischerweise ein 1–2-wöchiges Stück Arbeit. Wir haben diese für ein halbes Dutzend Nischen-Gateways erstellt; das Muster ist gut erprobt.

Versand + Betrug, der unterdiskutierte Teil

Versanddienstleister-Integrationen funktionieren normalerweise ohne viel Aufwand, da die meisten serverseitige Preisberechnungen sind, die die Benutzeroberfläche nicht berühren. Die Ausnahme sind Preisberechnungstools beim Checkout, die UI im Versandmethodenblock rendern (Live-Preisanzeige, Lieferdatumsauswahl, Abholorte). Jedes dieser Tools benötigt eine Hyvä-Neugestaltung, 1–2 Tage pro Integration.

Betrugsmodule (Signifyd, Riskified, Kount, ClearSale) haben normalerweise einen Frontend-Hook, der während der Bestellaufgabe ausgelöst wird. Der Hook selbst funktioniert auf Hyvä; die sichtbare UI (z. B. ein 3DS-Herausforderungs-iframe) muss möglicherweise neu gestaltet werden, abhängig von der Integrationsmethode des Anbieters. Planen Sie 1 Woche für Betrugsintegrationstests über echte Bestellungen ein.

B2B Checkout, die zusätzlichen Oberflächen

B2B Magento (und Adobe Commerce B2B) hat Oberflächen über den Standard-B2C-Checkout hinaus:

• Erfassung der Bestellnummer
• Multi-Account-Bestellungen (eine Bestellung im Namen eines anderen Unternehmenskontakts aufgeben)
• Umwandlung von verhandelten Angeboten (ein bestehendes Angebot in eine Bestellung umwandeln)
• Genehmigungsworkflow (Bestellungen über einem Schwellenwert benötigen die Genehmigung des Managers)
• Preisgestaltung nach Kundensegment anzeigen
• Schnelles Hinzufügen zur Anforderungsliste

Jede dieser Funktionen ist eine separate Hyvä-Vorlage + Workflow. B2B Hyvä Checkout fügt 2–4 Wochen im Vergleich zu B2C Hyvä Checkout hinzu, und der QA-Zyklus ist deutlich länger, da Sie echte B2B-Test-Szenarien benötigen (Multi-User, Multi-Company usw.).

Was schiefgeht, in grober Reihenfolge

Nach ~15 Hyvä Checkout-Bauten sind die häufigsten Fehlerpunkte:

1. 3DS-Zahlungsherausforderungen. Das 3D Secure iframe / Popup verhält sich unter Hyvä anders als unter Luma, da sich die umgebende JavaScript-Umgebung ändert. Planen Sie spezifische 3DS-Test-Szenarien in UAT ein, eine echte Karte von einer echten Bank, nicht nur Sandbox.

2. Adyen + Klarna koexistieren. Beide Anbieter haben aggressive Frontend-JS, die die DOM um den Zahlungsmethodenwähler steuern möchten. Wenn beide vorhanden sind, treten Konflikte auf, die bei jeweils nur einem nicht auftreten. Testen Sie die Kombination explizit.

3. Benutzerdefinierte Versandkostenrechner. Alles, was live UI im Versandmethodenblock rendert (Lieferdatumsauswahl, Abholung, Live-Kurierpreise), benötigt normalerweise eine Hyvä-Neugestaltung, die der Anbieter nicht bereitgestellt hat.

4. Preisgestaltung spezifisch für Kundengruppen. Wenn Ihr Shop unterschiedlichen Preisen für angemeldete und Gastkunden anzeigt, wird diese Logik beim Checkout erneut angewendet. Randfall: Ein Kunde meldet sich während des Checkouts an und der Preisblock muss sich aktualisieren, ohne die gesamte Seite neu zu laden.

5. Steuerberechnung in den Zeilenpositionen. Einige Rechtsordnungen verlangen eine detaillierte Steueranzeige pro Zeile. Die Standard-Zeilenposition-Vorlage von Hyvä Checkout kann dies je nach Ihrer Magento-Steuerkonfiguration möglicherweise nicht handhaben. Überprüfen Sie dies, bevor Sie davon ausgehen, dass es funktioniert.

Leistung, was zu erwarten ist

Über unsere Hyvä Checkout-Bauten:

• Mobile Lighthouse-Leistung der Checkout-Seite: typischerweise 88–95
• LCP beim Checkout: normalerweise 1,5–2,5s bei 4G-Mobilgeräten (im Vergleich zu 4–7s beim Standard von Magento)
• TBT beim Checkout: normalerweise 100–400ms (im Vergleich zu 1500–4000ms beim Standard von Magento)
• JS-Datenlast beim Checkout: 400–700KB (im Vergleich zu 2–4MB beim Standard von Magento)

Die Reduzierung der JS-Datenlast ist der Grund für den Anstieg der Konversion. Auf einem Low-End-Android-Gerät kann die Parsing-Zeit allein für das JavaScript des Standard-Checkouts von Magento 3–5 Sekunden betragen. Hyvä Checkout reduziert dies auf unter eine Sekunde.

Konversionssteigerung, was wir tatsächlich sehen

Über Implementierungen, die wir gemessen haben:

• Abschlussrate beim mobilen Checkout: +8–15% typisch
• Abschlussrate beim Desktop-Checkout: +2–5% typisch (geringer, da Desktop nicht so JS-begrenzt war)
• Durchschnittlicher Bestellwert: flach, Hyvä Checkout ändert den Inhalt des Warenkorbs nicht, sondern nur die Reibung beim Abschluss
• Erstkäufer vs. wiederkehrende Käufer: größer bei Erstkäufern (langsamere Geräte, weniger Geduld für langsame Checkouts)

Diese Zahlen sind Aggregationen. Ihr Anstieg hängt von Ihrer Verkehrsmischung (mobil %, Gerätekategorie), der vorherigen Abschlussrate (höhere Baselines haben weniger Spielraum für Anstiege) und der Komplexität des benutzerdefinierten Flows ab.

Hyvä Checkout-Preise, die Lizenz + der Aufbau

• Hyvä Checkout-Lizenz: ~£1,000–£3,000 pro Domain, abgerechnet von Hyvä Themes
• Eigenständige Implementierung (auf Hyvä Theme): £8,000–£15,000, 2–3 Wochen
• Eigenständige Implementierung (auf Luma-Storefront): £10,000–£20,000, 3–5 Wochen
• Als Teil des vollständigen Hyvä Commerce-Baus: fügt 2–3 Wochen + £8–15k zum Theme-Bau hinzu

Kosten für Erweiterungen:

• Benutzerdefinierte Zahlungs-Gateway-Integration: £2k–£6k pro Gateway
• Benutzerdefinierte Betrugsmodul-Integration: £2k–£4k pro Modul
• Benutzerdefinierte Versandkostenrechner-Neugestaltung: £1k–£3k pro Rechner
• B2B-spezifische Oberflächen (Angebote, Multi-Account, Genehmigungen): £5k–£12k kombiniert

Sollten Sie auf Hyvä Checkout 1.4 warten?

Häufige Frage. Die ehrliche Antwort: Hyvä Checkout 1.3 ist produktionsbereit und die kommende Version 1.4 fügt inkrementelle Funktionen hinzu, anstatt grundlegende Probleme zu beheben. Verzögern Sie nicht die Migration zu einem hochrentablen Checkout, während Sie auf eine Punktversion warten.

Wenn 1.4 veröffentlicht wird, ist der Upgrade-Pfad einfach, composer update, Regressionstest, bereitstellen. Wir hatten noch nie ein Hyvä Checkout-Upgrade, das länger als einen Sprint gedauert hat.

Nächste Schritte

• Sehen Sie sich die Hyvä Checkout-Service-Seite für Service-Details an
• Lesen Sie Hyvä Commerce vs Hyvä Theme, um den Kontext der Suite zu verstehen
• Buchen Sie einen Scoping-Anruf für ein Festpreisangebot basierend auf Ihrer Liste von Zahlungs- + Versandmodulen
• Durchstöbern Sie den Hyvä Checkout-Glossar-Eintrag für das technische Primer