Was tun, wenn der BigCommerce-Checkout 2026 in Safari den Warenkorb verliert?

Prüfen Sie zuerst, ob Storefront und Checkout nach den Vorgaben Ihrer BigCommerce-Implementierung zusammenpassen; verfolgen Sie danach Warenkorb und Kundensitzung bis zu dem Übergabepunkt, an dem ein Zustand verloren geht. Diese Woche sollten Sie den Ablauf mit derselben Produktseite und demselben Kontostatus in echtem macOS Safari und einem weiteren unterstützten Browser vergleichen.

Dieser Leitfaden ist für Sie, wenn Sie einen BigCommerce-Shop betreiben und Kundinnen oder Kunden nach dem Wechsel zum Checkout einen leeren Warenkorb melden. Er hilft Ihnen auch, wenn Sie als operative Ansprechperson einen reproduzierbaren Test vorbereiten oder als technische Unterstützung die Übergabe zwischen einer Headless-Storefront und dem gehosteten Checkout untersuchen.

Browservergleich: Safari-Abweichungen mit gleichen Bedingungen prüfen

Bevor Sie Storefront-Code oder Checkout-Einstellungen ändern, prüfen Sie, ob sich der Fehler unter kontrollierten Bedingungen auf Safari beschränkt. Ein einzelner fehlgeschlagener Versuch zeigt weder, dass Safari die Ursache ist, noch bestätigt ein erfolgreicher Versuch den gesamten Ablauf.

Safari-Wiederholung unter gleichen Bedingungen

Führen Sie den Ablauf erneut mit derselben Produktseite, derselben Checkout-Route und demselben Kontostatus aus. Notieren Sie, ob Sie als Gast oder als angemeldeter Kunde testen. Halten Sie außerdem fest, ob Sie sich während des Ablaufs anmelden, abmelden oder zu einer Kontoseite wechseln.

Vergleichen Sie anschließend dieselben Schritte in einem weiteren unterstützten Browser. Ändern Sie dabei nicht gleichzeitig Produkt, Storefront, Konto und Checkout-Link. Sonst lässt sich hinterher nicht mehr erkennen, welcher Unterschied mit dem Ergebnis zusammenhängt.

Notieren Sie für jeden Durchlauf:

• Die Adresse der Storefront vor dem Wechsel.
• Die Adresse des Checkouts nach dem Wechsel.
• Ob das Produkt auf der Produktseite und im Warenkorb sichtbar ist.
• An welchem Übergang der Warenkorb erstmals leer erscheint.
• Ob Anmeldung, Kundendaten oder Fehlermeldungen anders ausfallen.

WebKit beschreibt den Schutz vor websiteübergreifendem Tracking als Bestandteil des Browserverhaltens. Das ist ein möglicher Hintergrund, wenn eine Implementierung von websiteübergreifendem Speicher oder Sitzungskontext abhängt. Die Dokumentation zur Tracking Prevention von WebKit belegt jedoch nicht, dass diese Funktion in Ihrem Shop den Fehler verursacht. Verwenden Sie den Hinweis deshalb als Prüfrichtung, nicht als Diagnose.

Ändern Sie nicht vorsorglich die Datenschutzeinstellungen Ihrer Kundschaft und behandeln Sie eine abgeschaltete Schutzfunktion nicht als dauerhafte Reparatur. Wenn ein Fehler nur unter einer bestimmten Browserkonfiguration verschwindet, kann weiterhin eine fehlerhafte Übergabe vorliegen.

Warenkorbverlauf: Den ersten Verlustpunkt festhalten

Wenn der Browservergleich einen Unterschied zeigt, verfolgen Sie den Warenkorb entlang des tatsächlichen Ablaufs. „Der Checkout funktioniert nicht“ ist als Fehlerbeschreibung zu ungenau: Ein Produkt kann bereits beim Hinzufügen fehlen, erst beim Öffnen des Warenkorbs verschwinden oder beim Wechsel zum Checkout nicht mitgegeben werden.

Die Übergaben getrennt prüfen

Gehen Sie die Kundenreise in dieser Reihenfolge durch und halten Sie an jedem Punkt den sichtbaren Zustand fest:

1. Fügen Sie ein bestimmtes Produkt über die Storefront hinzu und prüfen Sie, ob eine Bestätigung erscheint.
2. Öffnen Sie den Warenkorb über die übliche Navigation des Shops. Kontrollieren Sie, ob Produkt und ausgewählte Varianten angezeigt werden.
3. Starten Sie den Checkout so, wie Kundinnen und Kunden es tun: über den regulären Warenkorbknopf oder den vorgesehenen Link.
4. Prüfen Sie die Zieladresse und den Inhalt der Checkout-Seite. Vergleichen Sie, ob das Produkt dort noch vorhanden ist.
5. Wiederholen Sie den Ablauf mit einem direkten oder gespeicherten Checkout-Link nur dann, wenn dieser Link im tatsächlichen Kundenprozess verwendet wird. Ein Link zu einem anderen oder veralteten Warenkorb kann einen abweichenden Zustand aufrufen.

Die BigCommerce-Referenz zum Erstellen eines Warenkorbs beschreibt, wie ein Warenkorb über die entsprechende Schnittstelle angelegt wird. Für die Fehleranalyse bedeutet das: Prüfen Sie, ob die Storefront tatsächlich einen Warenkorb erzeugt und ob der Checkout auf genau diesen Zustand verweist. Ein erfolgreicher Aufruf einer Seite allein beweist nicht, dass der richtige Warenkorb übergeben wurde.

Bei einem Headless-Aufbau ist die Storefront nicht automatisch gleichbedeutend mit dem Checkout. BigCommerce erläutert in der Anleitung zum Headless-Checkout-Ablauf die beteiligten Schritte der Integration. Verwenden Sie diese Dokumentation, um den eigenen Ablauf zuzuordnen; leiten Sie daraus nicht ab, dass jeder Shop dieselbe technische Umsetzung verwendet.

Den Befund anhand der ersten leeren Stelle einordnen

• Schon nach dem Hinzufügen fehlt das Produkt: Prüfen Sie zuerst die Aktion in der Storefront und ob die Warenkorberstellung beziehungsweise -aktualisierung funktioniert.
• Im Storefront-Warenkorb ist das Produkt vorhanden, im Checkout aber nicht: Untersuchen Sie den Übergabepunkt, die Checkout-URL und die Zuordnung des Warenkorbs.
• Der Checkout-Link öffnet einen anderen Zustand: Prüfen Sie, ob der Link für denselben Warenkorb und denselben Kundenablauf erzeugt wurde.
• Nur ein einzelner Testlauf weicht ab: Wiederholen Sie ihn, bevor Sie eine Konfigurationsänderung als Lösung festhalten.

Diese Einordnung trennt einen Fehler beim Aufbau des Warenkorbs von einem Verlust während der Übergabe. Sie verhindert auch, dass ein funktionierender Seitenaufruf fälschlich als Nachweis für einen funktionierenden Warenkorb gewertet wird.

Storefront und Checkout: Domainübergang nach Implementierung kontrollieren

Klären Sie vor einer Domainänderung, ob Ihr Shop eine gehostete Storefront, eine Headless-Storefront oder einen eingebetteten Checkout verwendet. Die Anforderungen unterscheiden sich nach Implementierung. Übertragen Sie daher nicht die Domainregel eines bestimmten BigCommerce-Ablaufs pauschal auf jeden Shop.

Domains und Checkout-Art erfassen

Notieren Sie die tatsächlich verwendeten Hostnamen der Storefront und des Checkouts. Achten Sie dabei auf Weiterleitungen: Die sichtbare Adresse beim ersten Klick muss nicht die Adresse sein, auf der der Checkout schließlich geladen wird. Halten Sie außerdem fest, ob der Checkout in die Storefront eingebettet oder als eigene Seite geöffnet wird.

Für einen BigCommerce Embedded Checkout stellt BigCommerce eigene Informationen zu Einrichtung und Verwendung bereit. Prüfen Sie die Übersicht zum Embedded Checkout und die zugehörige Anleitung zum Einrichten eines Embedded Checkout. Diese Unterlagen helfen Ihnen, die Anforderungen dieser konkreten Integration zu kontrollieren. Sie sind keine allgemeine Aussage über sämtliche Checkout-Arten.

Für Catalyst beschreibt BigCommerce gesonderte Anforderungen in den Dokumenten zu Checkout-Domains. Die Dokumentation weist darauf hin, dass eine Domainabweichung bei diesem Ablauf dazu führen kann, dass Safari oder andere Browser den Kundenkontext beziehungsweise den Warenkorb nicht fortführen. Prüfen Sie daher die Vorgaben für genau die von Ihnen eingesetzte Storefront und vergleichen Sie sie mit den tatsächlichen Hostnamen.

Ein vereinfachtes Bild des Ablaufs:

Storefront-Domain → Warenkorb und Kundenzustand → Checkout-Domain → Kunden- und Bestellabschluss

Wenn der Fehler an einer Grenze auftritt, untersuchen Sie die Übergabe an dieser Grenze. Ändern Sie nicht mehrere Domains gleichzeitig, ohne die Folgen für Weiterleitungen, eingebettete Inhalte und Kundenabläufe zu prüfen.

Ein abweichender Hostname ist ein wichtiger Befund, aber nicht automatisch die alleinige Ursache. BigCommerce dokumentiert Anforderungen für bestimmte Umsetzungen; ob sie auf Ihren Shop zutreffen, hängt davon ab, wie Storefront und Checkout tatsächlich verbunden sind.

Typische Headless-Übergaben abgleichen

Bei BigCommerce Headless Checkout sollten Sie nicht nur die sichtbaren Seiten vergleichen. Prüfen Sie, wie die Storefront den Warenkorb erstellt, wie der Checkout aufgerufen wird und welcher Kundenkontext beim Wechsel erhalten bleiben soll. Die BigCommerce-Dokumentation zur Sitzungssynchronisierung in Catalyst erläutert den Sitzungsabgleich für diese Umgebung.

Nutzen Sie diese Unterlagen nicht als Beleg dafür, dass jede Headless-Implementierung dieselbe Sitzungssynchronisierung benötigt oder dieselben Einstellungen verwendet. Stimmen Sie die Prüfung mit der Architektur Ihres Shops ab. Wenn Sie einen selbst entwickelten Frontend-Ablauf verwenden, dokumentieren Sie insbesondere, an welcher Stelle die Checkout-Adresse erzeugt wird und welche Sitzung dabei erwartet wird.

Kundensitzung: Gast- und Anmeldeablauf getrennt untersuchen

Ein leerer Warenkorb und eine verlorene Anmeldung können gemeinsam auftreten, sind aber nicht dasselbe Symptom. Prüfen Sie daher den Gastablauf getrennt vom Ablauf angemeldeter Kunden und halten Sie fest, wann sich der Kontostatus ändert.

Gast und angemeldete Kunden vergleichen

Starten Sie zunächst einen Test ohne Anmeldung. Notieren Sie, ob der Warenkorb bis zur Checkout-Seite erhalten bleibt. Führen Sie danach einen separaten Durchlauf mit einem Testkonto aus. Wenn möglich, wechseln Sie während der Reproduktion nicht zwischen Konten; dadurch lässt sich die Ursache leichter eingrenzen.

Prüfen Sie bei angemeldeten Tests besonders:

• Ob die Anmeldung vor oder nach dem Hinzufügen des Produkts stattfindet.
• Ob ein Wechsel zur Kontoseite oder eine Weiterleitung erfolgt.
• Ob der Checkout denselben Kundenkontext wie die Storefront zeigt.
• Ob der Warenkorb beim Abmelden, erneuten Anmelden oder Zurückkehren zur Storefront verändert wird.

Wenn der Gastablauf funktioniert, die Anmeldung aber verloren geht, untersuchen Sie den Sitzungsübergang und die Kontoroute. Wenn beide Abläufe an derselben Stelle den Warenkorb verlieren, liegt der erste Prüfpunkt eher bei der Warenkorb- oder Checkout-Übergabe. Das sind Hinweise zur Eingrenzung, keine endgültige Fehlerursache.

Die Dokumentation zur Sitzungssynchronisierung in Catalyst ist für die dort beschriebene Umgebung relevant. Verwenden Sie sie, um die Übergabe zwischen Storefront und Checkout zu verstehen. Ein erfolgreicher Anmeldetest deckt jedoch nicht automatisch andere Kontostände, Browserzustände oder Kundenwege ab.

Wenn Sie einen Fehlerbericht an Ihr Entwicklungsteam weitergeben, beschreiben Sie den Ablauf in Alltagssprache und fügen Sie die technische Beobachtung hinzu: „Als Gast bleibt das Produkt sichtbar; nach der Anmeldung und dem Wechsel zur Checkout-Seite ist der Warenkorb leer.“ Diese Aussage ist nützlicher als „Safari verliert manchmal den Warenkorb“, weil sie eine konkrete Stelle für die nächste Prüfung benennt.

End-to-End-Ergebnis: Checkout-Aufruf und Bestellung getrennt bewerten

Prüfen Sie den Ablauf nicht nur anhand der geöffneten Checkout-Seite. Trennen Sie, ob der Warenkorb erhalten bleibt, ob der Checkout lädt, ob Kundeninformationen bestehen bleiben und ob ein Testauftrag den erwarteten Status erreicht. Ein sichtbarer Seitenwechsel belegt weder eine erfolgreiche Zahlung noch eine abgeschlossene Bestellung.

Verwenden Sie einen von BigCommerce beziehungsweise Ihrem Zahlungsanbieter vorgesehenen Testablauf. Halten Sie fest, welche Testumgebung Sie verwendet haben und welcher Bestellstatus danach sichtbar ist. Ändern Sie während desselben Tests nicht zugleich die Domain, den Browser und die Checkout-Konfiguration. Sonst können Sie ein erfolgreiches Ergebnis keiner einzelnen Änderung zuordnen.

Sichern Sie nachvollziehbare Belege, ohne personenbezogene Daten offenzulegen:

• Bildschirmaufnahmen der relevanten Seiten mit ausgeblendeten Namen, E-Mail-Adressen und Zahlungsinformationen.
• Storefront- und Checkout-Hostnamen sowie die verwendete Checkout-Art.
• Den ersten Schritt, an dem der Warenkorb leer erscheint.
• Den Kontostatus und die Browserumgebung des Testlaufs.
• Den sichtbaren Status des Testauftrags, soweit dieser für die Prüfung benötigt wird.

Beachten Sie bei Aufzeichnungen und Weitergabe die Datenschutzvorgaben Ihres Unternehmens und die Anforderungen der DSGVO. Teilen Sie keine echten Kundendaten in Supportanfragen oder internen Bildschirmaufnahmen, wenn anonymisierte Testdaten für die Diagnose ausreichen.

Entscheidungshilfe: Den nächsten Prüfschritt anhand des Befunds wählen

Arbeiten Sie diese Entscheidungsliste der Reihe nach ab. Markieren Sie den ersten zutreffenden Befund und führen Sie zunächst nur den zugehörigen Prüfpfad aus. So vermeiden Sie, dass mehrere gleichzeitige Änderungen die Ursache verdecken.

• [ ] Das Produkt fehlt bereits in der Storefront. Prüfen Sie zuerst die Warenkorberstellung und das Verhalten der Storefront. Ändern Sie die Checkout-Domain noch nicht.
• [ ] Das Produkt ist im Storefront-Warenkorb vorhanden, fehlt aber nach dem Wechsel. Kontrollieren Sie die Zuordnung des Warenkorbs, den erzeugten Checkout-Link und die Anforderungen der verwendeten Checkout-Art.
• [ ] Nur der angemeldete Ablauf scheitert. Untersuchen Sie den Kontowechsel und die Sitzungssynchronisierung für Ihre konkrete Architektur; vergleichen Sie den Ablauf getrennt mit einem Gasttest.
• [ ] Derselbe Ablauf weicht nur in macOS Safari ab. Vergleichen Sie die tatsächlichen Domains und dokumentieren Sie den Browserzustand. Behandeln Sie WebKit-Schutzmaßnahmen als möglichen Kontext, nicht als hinreichenden Fehlernachweis.
• [ ] Der Fehler lässt sich nicht zuverlässig wiederholen. Sammeln Sie weitere vergleichbare Testläufe, statt eine Änderung als bestätigte Lösung zu melden.
• [ ] Der Checkout lädt, aber der Testauftrag erhält nicht den erwarteten Status. Untersuchen Sie Zahlungs- und Bestellablauf getrennt vom Warenkorbtransport.

Wenn mehrere Punkte zutreffen, beginnen Sie mit dem frühesten Fehler im Kundenablauf. Fehlt das Produkt bereits vor dem Checkout, ist die Checkout-Domain nicht der erste Prüfpunkt. Bleibt der Warenkorb bis zum Checkout erhalten und verschwindet erst nach einer Anmeldung, untersuchen Sie zuerst Sitzung und Kontowechsel. Diese Entscheidungsregel grenzt den zuständigen Bereich ein, ersetzt aber keine Prüfung Ihrer konkreten BigCommerce-Konfiguration.

macOS-Safari-Test bei fehlendem geeignetem Gerät vorbereiten

Ein Test in echtem macOS Safari ist sinnvoll, wenn Sie den Fehler mit einem reproduzierbaren Ablauf eingrenzen müssen und kein geeignetes Mac-Gerät verfügbar ist. Ein Remote-Mac kann Ihnen dafür eine echte macOS-Umgebung zugänglich machen. Er korrigiert aber weder eine ungeeignete Domainkonfiguration noch eine fehlerhafte Warenkorbzuordnung und garantiert keine erfolgreiche Zahlung.

Legen Sie vor der Nutzung fest, was Sie testen wollen: den Gastablauf, die Anmeldung, den Domainwechsel oder den gesamten Testauftrag. Klären Sie außerdem, ob Sie Safari selbst bedienen müssen, wie Sie den Bildschirmzugriff erhalten und welche Daten Sie im Test verwenden dürfen. Eine Remote-Umgebung ist nicht passend, wenn Ihr Test physische Geräte oder lokale Schnittstellen voraussetzt oder wenn Sie regelmäßig eine eigene, dauerhaft verfügbare Hardware benötigen.

Wenn Sie noch abwägen, ob eine gemietete Mac-Umgebung zu Ihrem Test passt, vergleichen Sie zunächst mietbare und eigene Mac-Umgebungen. Für die Vorbereitung und Abnahme können Sie außerdem die Anleitungen zu Remote-Mac-Tests heranziehen. Entscheidend ist, dass Sie vorab den Zugang, die benötigte Browserumgebung und den Umgang mit Testdaten prüfen.

Im Vergleich dazu kann ein lokaler Nicht-Mac-Rechner die echte macOS-Safari-Ausführung nicht ersetzen; ein Browser-Emulator bildet nicht zwingend dasselbe Verhalten ab; und eine Änderung der Datenschutzeinstellungen verschiebt das Problem möglicherweise nur. Wenn Sie lediglich vorübergehend reale Safari-Bedingungen reproduzieren müssen und keinen Mac zur Hand haben, kann ein gemieteter Remote-Mac von VpsKeep den Testzugang bereitstellen. Prüfen Sie vorab, ob Zugriffsart und Übergabebedingungen zu Ihrem konkreten Test passen. Für eine dauerhafte, intensive Nutzung oder Anforderungen an physische Anschlüsse ist ein eigener Mac gegebenenfalls die bessere Wahl. Details zu den verfügbaren Mietmöglichkeiten finden Sie bei den VpsKeep-Angeboten.