Internationaler Checkout in Hyvä: 4 Layouts, die wir gebaut haben

Ein Checkout, der in einem Land gut funktioniert, kann sich im nächsten falsch anfühlen. Adressformate unterscheiden sich, Kunden erwarten andere Zahlungsarten, und manche Märkte brauchen Felder, die andere nie anzeigen.

Als wir unseren Hyvä-Demo-Shop mit englischer und deutscher Store View gebaut haben, wollten wir einen Checkout, der mehrere Länder aus einer Codebasis bedienen kann. Herausgekommen sind vier Layout-Varianten. Dieser Beitrag erklärt, was wir gebaut haben, warum und was wir dabei gelernt haben. Außerdem zeigt er, wie sich das in die Checkout-Optionen einfügt, die wir Kunden anbieten.

Die Checkout-Optionen in Hyvä

Hyvä ersetzt das Luma-Frontend, und der Standard-Checkout von Luma basiert auf genau dem KnockoutJS- und RequireJS-Stack, den Hyvä entfernt. Ein Hyvä-Shop braucht daher eine Checkout-Strategie.

• Hyvä Checkout ist der offizielle Checkout des Hyvä-Teams, gebaut auf Magewire. Er rendert auf dem Server und aktualisiert Teile der Seite ohne schweres JavaScript-Framework.
• Ein Luma-basierter Checkout, etwa eine bewährte One-Page-Checkout-Extension, kann neben einem Hyvä-Theme laufen. Das ist eine sichere Wahl, wenn ein Zahlungsmodul noch nicht Hyvä-fähig ist.
• Ein individuelles Layout auf Basis eines Hyvä-Checkouts, und genau das sind unsere eigenen Templates.

Diese Optionen haben wir ausführlich verglichen in Lohnt sich Hyvä Checkout. In diesem Beitrag konzentrieren wir uns auf das Layout und die internationalen Details.

Die vier Layouts, die wir gebaut haben

Im Demo-Shop ist der internationale Checkout ein einziges Formular mit vier Layouts. Die Blöcke bleiben in jedem Layout gleich. Es ändern sich nur das CSS-Grid und welche Blöcke jeder Schritt anzeigt.

Mehrere Layouts in einem Shop ermöglichten es uns, dieselben Produkte, Zahlungsarten und Store Views in unterschiedlichen Abläufen zu testen. Außerdem hat sich gezeigt, dass das Layout selten der schwierigste Teil ist.

Adressen unterscheiden sich stärker als gedacht

Magento weiß bereits viel über Länder, und ein guter internationaler Checkout nutzt dieses Wissen, statt dagegen anzukämpfen.

• Postleitzahlen. Manche Länder verwenden überhaupt keine Postleitzahlen. In Magento können Sie die Postleitzahl pro Land unter Stores > Configuration > General > Country Options als optional markieren.
• Regionen und Bundesstaaten. Manche Länder benötigen einen Bundesstaat oder eine Provinz, die meisten europäischen Länder nicht. Magento steuert das pro Land, und der Checkout sollte dieser Einstellung folgen.
• Adresszeilen. Die Hausnummer steht in manchen Ländern vor dem Straßennamen, in anderen danach. Klare Feldbezeichnungen helfen mehr als cleveres Parsing.
• Firma und USt-IdNr. Geschäftskunden in der EU erwarten oft, eine USt-IdNr. eingeben zu können. Wird dieses Feld nur angezeigt, wenn ein Firmenname eingetragen ist, bleibt das Formular für alle anderen kurz.

Auch die Reihenfolge der Felder zählt. Steht das Land an erster Stelle, kann sich der Rest des Formulars anpassen, bevor der Kunde zu tippen beginnt.

Zahlung und Versand pro Markt

Kunden vertrauen den Zahlungsarten, die sie bereits nutzen. Karte und PayPal sind in ganz Europa verbreitet, doch viele Märkte haben starke lokale Zahlungsarten, und manche Kunden brechen ab, wenn ihre fehlt.

In Magento lassen sich Zahlungsarten auf bestimmte Länder beschränken, und unsere Checkouts berücksichtigen diese Einstellungen. Wir testen jede Zahlungsart durchgängig in jedem Markt, in dem sie aktiv ist – einschließlich der Rückkehr vom Zahlungsanbieter zur Bestellbestätigungsseite.

Der Versand verdient dieselbe Sorgfalt. Tarife, Lieferzeitangaben und Versanddienstleister sollten zum gewählten Land passen, und die Summen müssen sich in dem Moment aktualisieren, in dem sich die Adresse ändert.

Wenn eine Zahlungs-Extension Hyvä nicht unterstützt, entscheidet das Extension-Audit über den Weg. Sie können sie portieren, eine Alternative suchen oder vorerst einen Luma-basierten Checkout verwenden. Unser Beitrag über Extensions ohne Hyvä-Kompatibilitätsmodul behandelt diese Optionen.

Übersetzungen und Store Views

Unser Demo-Shop betreibt eine englische und eine deutsche Store View mit einem Sprachumschalter per Flagge. Store-View-spezifische Übersetzungen waren einer der Stolpersteine, auf die wir gestoßen sind.

Checkout-Texte stammen aus mehreren Quellen gleichzeitig: dem Theme, dem Checkout-Modul, Zahlungsmodulen, E-Mail-Templates und der Bestellbestätigungsseite. Ein an einer Stelle übersetzter String kann an anderer Stelle trotzdem auf Englisch erscheinen.

Unsere Regel: vor dem Launch in jeder Store View eine vollständige Testbestellung aufgeben. Wir lesen jede Bezeichnung, jede Fehlermeldung und jede E-Mail in der jeweiligen Sprache – nicht nur die Hauptschritte.

Security-Header im Checkout

Magento verwendet eine Content Security Policy, um zu steuern, welche Skripte und Frames eine Seite laden darf. Im Checkout ist das am wichtigsten, denn Zahlungsanbieter laden eigene Skripte und iframes.

CSP-Regeln im Hyvä Checkout waren ein weiterer Stolperstein auf unserer Liste. Ein Zahlungs-Widget, das auf einer Testseite funktioniert, kann im Checkout unbemerkt ausfallen, wenn seine Domain nicht freigegeben ist.

Hinterlegen Sie die benötigten Domains in einem Modul in der Datei csp_whitelist.xml und testen Sie jede Zahlungsart bei geöffneter Browser-Konsole. Ein blockiertes Skript taucht dort auf, lange bevor ein Kunde es meldet.

Die Bestellbestätigungsseite gehört zum Checkout

Jedes Checkout-Template, das wir anbieten, enthält eine individuelle Bestellbestätigungsseite. Die Bestellung ist aufgegeben, doch der Kunde ist noch ganz bei der Sache.

Eine gute Bestellbestätigungsseite bestätigt die Bestellung klar, erklärt die nächsten Schritte und bietet an, aus einer Gastbestellung ein Kundenkonto zu machen. Außerdem wird hier das Kauf-Tracking ausgelöst – deshalb testen wir sie so sorgfältig wie den Zahlungsschritt.

Testbestellungen aus dem Weg räumen

Vier Layouts in zwei Sprachen zu testen, erzeugt viele Bestellungen. Im Demo-Shop bereinigt ein nächtlicher Job die Testbestellungen automatisch, damit Berichte und Lagerbestände realistisch bleiben.

In einem Live-Shop würden Sie keine Bestellungen löschen, doch das Prinzip gilt weiterhin. Nutzen Sie für Checkout-Tests eine Staging-Kopie und schalten Sie dort den E-Mail-Versand ab, damit Testkunden nie etwas erhalten.

FAQ

Welches Checkout-Layout konvertiert am besten?

Eine allgemeingültige Antwort gibt es nicht, denn es hängt von Warenkorbgröße, Zielgruppe und Markt ab. Wir starten mit dem Layout, das zum Shop und zu den Produkten passt, und vergleichen nach dem Launch Varianten anhand echter Daten.

Kann ein Shop pro Land unterschiedliche Checkout-Layouts verwenden?

Der Checkout folgt der Store View, daher können verschiedene Store Views unterschiedliche Einstellungen und Inhalte nutzen. Ob sich ein eigenes Layout pro Land den zusätzlichen Testaufwand lohnt, ist eine geschäftliche Entscheidung, die wir mit jedem Kunden besprechen.

Brauchen wir Hyvä Checkout, um ein Hyvä-Theme zu verwenden?

Nein. Ein Hyvä-Theme funktioniert mit Hyvä Checkout, mit einem Luma-basierten Checkout oder mit einem individuellen Checkout. Die richtige Wahl hängt vor allem von Ihren Zahlungs- und Versand-Extensions ab.

Sie planen einen Hyvä-Checkout für mehrere Märkte? Sehen Sie sich alle unsere Hyvä-Checkout-Optionen, oder kontaktieren Sie uns , um über Ihre Länder und Zahlungsarten zu sprechen.