Shopware 6 Checkout bricht mit HTTP 500 ab – jede Sekunde kostet Umsatz

Was sehen Shopbetreiber?

Kundinnen und Kunden gelangen bis zur Zahlungsauswahl, doch nach dem Klick auf 'Jetzt kaufen' erscheint eine weisse Seite, ein generisches 'Oops! Ein Fehler ist aufgetreten' oder ein nackter HTTP 500. Im Backend tauchen Bestellungen sporadisch oder gar nicht auf. Im Browser-Log sieht man typischerweise einen POST auf /checkout/order, der mit Status 500 zurückkommt.

Business-Impact: Was kostet dieser Fehler?

Ein defekter Checkout ist der teuerste Bug im E-Commerce. Bei einem mittelgrossen Schweizer Shop mit 200 Bestellungen pro Tag und 180 CHF Warenkorbwert entgehen pro Stunde Ausfallzeit rund 1'500 CHF Umsatz – plus Werbekosten für Klicks, die nie konvertieren. Dazu kommt der langfristige Schaden: Nutzer, die einmal in Ihrem Checkout scheitern, kommen statistisch nur zu 18% zurück. Google bemerkt erhöhte Bounce-Raten über Core Web Vitals und straft die Sichtbarkeit ab.

Technische Ursachen-Analyse

Was passiert technisch im Hintergrund?

Die Ursache liegt fast nie im Shopware-Core, sondern in der Interaktion zwischen Plugins, App-Server und Datenbank. Typische Auslöser sind: ein Drittanbieter-Plugin (Payment, ERP-Schnittstelle, Custom Cart Processor) wirft eine unbehandelte Exception im Cart::process()-Hook; der Symfony-Container ist nach einem Update nicht neu kompiliert (var/cache veraltet); fehlende oder falsche APP_SECRET / APP_URL in der .env; MariaDB schlägt mit Lock-Timeouts bei der Tabelle 'order' fehl; oder der Webserver (nginx/Apache + PHP-FPM) hat zu niedrige memory_limit / max_execution_time Werte. Im var/log/prod-*.log finden sich die exakten Stacktraces – nur liest sie kaum jemand systematisch.

Die LeadForge-Lösung

Unser systematischer Express-Fix-Prozess

Wir starten mit einem strukturierten Triage-Prozess: Direktzugriff via SSH auf den Server, Live-Analyse der Shopware-Logfiles (var/log/), nginx- oder Apache-Errorlogs, PHP-FPM-Slowlog und MariaDB-Slow-Queries parallel. Innerhalb von 60 Minuten identifizieren wir den schuldigen Plugin- oder Konfigurations-Layer. Dann deaktivieren wir gezielt einzelne Plugins via CLI (bin/console plugin:deactivate), kompilieren den Container neu (bin/console cache:clear, theme:compile) und verifizieren den Checkout mit einer Testbestellung. Sie erhalten am Ende ein schriftliches Root-Cause-Protokoll – für Sie und Ihren bisherigen Dienstleister.