Zum Hauptinhalt springen
Der Abschnitt checkout umfasst alles, was den Bestellprozess in der Storefront steuert: von der einfachen Gast- oder Schnellbestellung über eigene Eingabefelder bis zur Rundung von Zwischensummen. Er ermöglicht zudem eine schnelle Artikelerfassung per Artikelnummer, prüft bei Bedarf Warenkorbinhalte gegen Regeln (z. B. Pflichtzubehör), verwaltet Versandarten inklusive Preislogik und bindet Paketverfolgung an.

checkout* - Grundstruktur

Nachfolgend der Grundaufbau des Knotens checkout

Parameterübersicht

checkout.checkout - Bestellablauf

Dieser Abschnitt bündelt die Einstellungen für den Checkout. Hier wird festgelegt, wie der Bestellprozess abläuft, welche Zusatzfelder angezeigt werden und wie beispielsweise Versandoptionen standardmäßig gewählt werden. Zudem lassen sich Regeln für Gutschein-Berechnungen, länderspezifische Versandfreiheit und optional für die Paketverfolgung definieren.

Beispielkonfiguration checkout.checkout

Parameterübersicht

Prioritätslogik für defaults: Wenn mehrere Quellen (z.B. Benutzerauswahl oder Kundenpräferenzen) einen Wert für ein Feld in defaults liefern, gilt folgende Rangfolge der Priorisierung:
  1. Aktive Benutzerauswahl in der aktuellen Sitzung - wird niemals automatisch überschrieben.
  2. Gespeicherte Kundenpräferenzen eines eingeloggten Kunden (sofern unterstützt).
  3. Händler-Konfiguration - die hier definierten defaults-Werte.
  4. System-Fallback - z.B. automatische Auswahl bei nur einer verfügbaren Option oder erste gültige Option nach Sortierung (siehe autoSelectSingleOption).
Neuauswahl, wenn eine gewählte Art nachträglich ungültig wird:Die Prioritätslogik oben gilt für die Erstauswahl. Wird dagegen eine bereits getroffene, aber inzwischen ungültige Auswahl behandelt - etwa weil der Kunde das Lieferland wechselt und die gewählte Versandart dort nicht angeboten wird -, steuert prevSelectionInvalidAutoSelect, wie der Shop reagiert (siehe Tabelle oben). autoSelectSingleOption bleibt dabei in allen Modi als Rückfallebene aktiv.
Hinweis zum Rundungsverhalten bei positionsbasierter Gutschein-Berechnung:
Wenn „voucherAppliesPerItem” auf „true” gesetzt ist und ein prozentualer Gutschein mit einem konfigurierten Maximalbetrag verwendet wird, kann der gewährte Rabatt diesen Maximalbetrag um bis zu 0,01 € überschreiten. Grund dafür ist, dass der Rabatt pro Position einzeln gerundet wird und die Summe dieser Rundungen minimal vom erwarteten Gesamtbetrag abweichen kann.

checkout.voucher - Einstellungen für Gutscheine

In diesem Abschnitt werden die Einstellungen für die Verwendung von Gutscheinen im Bestellprozess gebündelt. Hier wird unter anderem festgelegt, wie viele Gutscheine ein Kunde gleichzeitig einlösen kann und wie Rabattbeträge bei prozentualen Gutscheinen rechnerisch gerundet werden.

Beispielkonfiguration checkout.voucher :

Parameterübersicht

checkout.directOrder - Onlinebestellschein

Ermöglicht eine schnelle Erfassung von Artikeln per Artikelnummer - beispielsweise für große oder wiederkehrende Bestellungen. Festgelegt wird, welche Spalten pro Zeile sichtbar sind (z.B. Artikelnummer, Menge). Auf Wunsch merkt sich das System die zuletzt verwendete Zeilenanzahl über saveCountInSession.

Beispielkonfiguration checkout.directOrder

Parameterübersicht

checkout.productDependency - Produktabhängigkeiten

Dieser Abschnitt legt fest, wann bestimmte Schritte oder Optionen im Checkout erlaubt sind. Er prüft dazu die Inhalte des Warenkorbs - etwa Eigenschaften wie Größe, Farbe oder ob ein Zusatzfeld ausgefüllt ist - und kann bei Nichterfüllung einen Hinweis anzeigen oder die Aktion sperren. Typische Einsatzfälle sind beispielsweise Pflichtzubehör oder das Verhindern verbotener Kombinationen im Checkout.

Beispielkonfiguration checkout.productDependency

Auswertungslogik

Die Regelgruppen und Bedingungen werden nach einem festen Schema ausgewertet:
  • dependencyGroups sind ODER-verknüpft: Es genügt, wenn eine der Gruppen vollständig erfüllt ist.
  • dependencies innerhalb einer Gruppe sind UND-verknüpft: Innerhalb einer Gruppe müssen alle Bedingungen erfüllt sein.
  • Ob eine einzelne Bedingung als erfüllt gilt, steuert zusätzlich basketBehavior: Bei matchOnce muss mindestens eine Warenkorb-Position die Bedingung erfüllen, bei matchAll alle Positionen, bei denen das geprüfte Feld einen Wert liefert.
Im Beispiel oben gilt die Abhängigkeit also als erfüllt, wenn entweder die erste Gruppe zutrifft (eine Position mit der Farbe camel und eine Position mit leerem Freifeld engraving im Warenkorb) oder die zweite Gruppe (eine Position mit Größe S, M oder L).

Parameterübersicht

Prüfarten (type)

checkout.shippingMethod - Versandarten

Definiert verfügbare Versandarten und deren Verhalten im Checkout. Neben Aktivierung, Name und Bestellhinweisen lassen sich Preisstaffeln nach Gewicht (weightCost) und nach Warenkorb-Zwischensumme (basicCost) konfigurieren. Über Validierungen (validations) können Bedingungen wie zulässige Länder, nur physische Produkte oder weitere Regeln hinterlegt werden. Ergänzend sind Beschreibung, Bild/Icon und externer Link (z. B. Carrier-Info) möglich. Über das Feld group lässt sich eine Versandart zudem einer Versandarten-Gruppe zuordnen. So entstehen klar benannte, regelkonforme Versandoptionen mit transparenter Preislogik und optionalen Einschränkungen.

Beispielkonfiguration checkout.shippingMethod

Parameterübersicht

checkout.shippingMethodGroup - Versandarten-Gruppen

Definiert Gruppen, zu denen Versandarten zusammengefasst werden können (z. B. nach Anbieter oder Lieferart). Eine Versandart wird über ihr Feld group einer Gruppe zugeordnet. Je Gruppe lassen sich Name, Beschreibung, Bild und ein Link hinterlegen - etwa, um im Frontend mehrere Versandarten gebündelt und einheitlich darzustellen.

Beispielkonfiguration checkout.shippingMethodGroup

Parameterübersicht

Im Template werden die Gruppen über $wsConfig.shippingMethodGroups gelesen. Die einer Versandart zugewiesene Gruppe steht dort im Feld group der Versandart.

checkout.shipTrack - Paketverfolgung

Konfiguriert die Anbindung an Versanddienstleister zur Sendungsverfolgung. Hinterlegt werden Provider-Kennung und Zugangsdaten (API-User/Token) sowie ein Sprachcode für Provider-Antworten und Labeling. Auf Basis dieser Daten lassen sich Tracking-Links und Statusinformationen im Checkout bzw. im Kundenkonto bereitstellen und automatisiert in Benachrichtigungen verwenden.

Beispielkonfiguration checkout.shipTrack

Parameterübersicht

checkout.fieldErrorVisibility - Fehleranzeige

Legt fest, wann Fehlermeldungen im Checkout angezeigt werden, z.B. ob ein Hinweis auf ein fehlendes Pflichtfeld sofort erscheint, auch ohne dass der Kunde das Feld berührt hat, oder erst, wenn der Kunde auf “Kaufen” klickt.

Beispielkonfiguration checkout.fieldErrorVisibility

Parameterübersicht

Nach dem Klick auf “Kaufen” werden standardmäßig alle Fehler angezeigt, unabhängig von dieser Einstellung.Im Checkout gibt es grundsätzlich zwei Arten von Fehlern:
  • Fehler, die das System selbst erkennt (z.B. “Pflichtfeld leer”, “ungültige PLZ”):
    Diese werden über $wsCheckout.problems.* bereitgestellt und lassen sich vollständig über die show*BeforeSubmit-Parameter steuern.
  • Fehler, die der Server zurückmeldet (z.B. nach dem Klick auf “Kaufen”):
    Hier greifen die Einstellungen der show*BeforeSubmit-Parameter nur teilweise. Bei Kundendaten und Draft-Adressen steht $wsCheckout.problems.* nicht zur Verfügung, deshalb werden die Serverfehler dort stattdessen über die show*BeforeSubmit-Parameter gefiltert. In allen anderen Bereichen des Checkouts (z.B. bei der Zahlungsart) werden Serverfehler immer sofort angezeigt, unabhängig von der Konfiguration.