woocommercecheckoutdatabasetroubleshooting

WooCommerce-Fehler ‚Submission not found in the database‘ beheben

13. August 20268 min Lesezeit·ShopMonitor Team

Der Kunde klickt auf „Bestellung abschicken“. Das Zahlungs-Gateway antwortet. Dann meldet WooCommerce: „The submission was not found in the database“ oder schreibt einen ähnlichen „fault code … not found in the database“-Eintrag ins Log. Der Warenkorb sah normal aus, die Zahlung ist vielleicht sogar durch. Doch der Bestelldatensatz fehlt oder ist unvollständig. Hier erfährst du, was hinter dem Fehler steckt, welche fünf Ursachen du zuerst prüfen solltest und wie du ihn systematisch eingrenzt.

Was dieser Fehler wirklich bedeutet

Für WooCommerce sind „Checkout abgeschickt“ und „Bestellung in MySQL gespeichert“ nicht derselbe Moment. Der Browser oder ein Gateway-Callback fragt oft nach einer Bestellung, Session oder Store-API-Submission-ID, die bereits in der Datenbank liegen sollte. Bleibt diese Suche leer, erscheint ein Fehler wie „submission not found“ statt einer verständlichen Bitte zum erneuten Versuch.

Zwei Schichten kollidieren:

Session-Ebene: Warenkorb-Hash, Kundensitzung, Checkout-Nonces und temporäre Store-API-Entwürfe.
Datenbank-Ebene: Die Zeile in wp_posts oder wp_wc_orders samt zugehöriger Meta-Daten für die Bestellung.

Am häufigsten taucht der Fehler beim Absenden des Checkouts auf, auf der Bestellbestätigungsseite oder wenn ein Gateway-Webhook beziehungsweise eine Rückkehr-URL eine Bestellung abfragt, die noch nicht gespeichert wurde oder nie gespeichert werden konnte. Der klassische Shortcode-Checkout und der Checkout-Block mit Store API hängen beide an dieser Übergabe. Nur die verwendeten Zwischen-IDs unterscheiden sich. Suche im Log nach „not found in the database“, „submission was not found“ und Gateway-Fehlern, nicht nur nach dem exakten Wortlaut aus einem Support-Ticket.

Wenn du den gesamten Kaufpfad debuggen willst, kombiniere diesen Guide mit so testest du deinen WooCommerce-Checkout, damit du den Fehler gezielt reproduzieren kannst, statt auf die nächste Kundenmail zu warten.

Häufigste Ursachen

Die Meldung ist nur das Symptom. Prüfe zuerst diese fünf Ursachen. Weiterleitende Gateways und aggressives Seiten-Caching sind häufige Auslöser. Eine echte MySQL-Korruption ist dagegen selten.

1. Der Gateway-Callback kommt vor dem Speichern der Bestellung

Weiterleitungen oder Webhooks von PayPal, manchen Stripe-Konfigurationen und Banküberweisungen mit Rückkehr-URL können deine Website erreichen, während WooCommerce die Bestellung noch speichert. Der Callback sucht die Bestell-ID oder den Schlüssel, findet nichts und protokolliert einen Datenbankfehler. Ein Hinweis darauf ist eine Zahlung beim Gateway ohne passende Bestellung in WooCommerce. Langsame PHP-Worker und eine ausgelastete MySQL-Datenbank können das Zeitfenster vergrößern.

2. Caching liefert veraltete Checkout- oder Bestellseiten

Seiten-Caches und CDNs lieben HTML. Checkout und Bestellbestätigungsseiten dürfen jedoch nicht im Cache landen. Erhält ein Kunde eine alte Seite mit abgelaufener Session oder Nonce, wird das Formular trotzdem abgeschickt. Der Server findet dann aber keine gültige Sitzung oder keinen Entwurf. Das sieht wie ein Datenbankfehler aus, obwohl MySQL oft völlig in Ordnung ist. Eigene Checkout-URLs, übersetzte Slugs und „Cache Everything“-Regeln am Netzwerkrand sind typische Gründe, warum automatische Ausnahmen nach einer Migration oder einem Redesign nicht mehr greifen.

3. Das Speichern in der Datenbank schlägt fehl

Wenn INSERT oder UPDATE für Bestellungen in ein Timeout läuft, der Speicher voll ist oder eine InnoDB-Tabelle gesperrt bleibt, sieht der Kunde womöglich nur einen Ladeindikator oder wird zum Gateway weitergeleitet. Der Callback sucht später nach einer Bestellung, die nie gespeichert wurde. Prüfe Hosting-Metriken sowie MySQL-Slow- und Error-Logs, wenn sich die Fehler häufen. Eine überlastete Hosting-Umgebung kann das Speichern von Bestellungen beeinträchtigen.

4. Ein Plugin-Konflikt überschreibt den Bestellablauf

Editoren für Checkout-Felder, Plugins für eigene Bestellstatus, B2B-Preisschichten und aggressive Sicherheits-Plugins können in die Checkout-Verarbeitung eingreifen und das Anlegen einer Bestellung abbrechen oder verändern. Nach einem nächtlichen Plugin- oder WooCommerce-Update kann ein lange stabiler Shop plötzlich Einreichungen verlieren. Isoliere Konflikte zuerst in der Staging-Umgebung, bevor du die Datenbank verdächtigst. Behalte auch Checkout-Hooks, Store-API-Routen und Firewalls im Blick, die POST-Anfragen mit Zahlungs-Tokens blockieren.

5. Die Session läuft ab, bevor der Kunde bezahlt

Ein Kunde öffnet den WooCommerce-Checkout, lässt sich ablenken und bezahlt erst später. Die WooCommerce-Session und der zugehörige Entwurf können dann abgelaufen sein. Die Zahlung kann beim Gateway trotzdem durchgehen, doch dein Shop hat keine passende Einreichung mehr. Die Fehlermeldung bleibt gleich, die Ursache ist eine andere. Langsame Versand-APIs und mehrstufige Checkouts erhöhen das Risiko. Eine längere Session-Laufzeit reduziert Reibung, behebt aber weder ein Timing-Problem noch fehlende Cache-Ausnahmen.

Animiertes Diagramm: Der Zahlungs-Callback überholt das Speichern der Bestellung. Die Session fragt die Datenbank nach einem Datensatz, der noch nicht vorhanden ist.

Den Fehler Schritt für Schritt beheben

Arbeite die Punkte von oben nach unten ab. Eine Schema-Reparatur kommt erst infrage, wenn Caches, Isolationstests und Hosting-Logs wirklich auf einen defekten Speicherpfad hindeuten.

1Alle Caches leeren

Leere WP Rocket, LiteSpeed, W3 Total Cache oder deinen eigenen Cache-Stack. Leere außerdem den Objekt-Cache bei Redis oder Memcached, den Server-Cache im Hosting-Panel und Cloudflare oder ein anderes CDN. Teste den Checkout danach in einem frischen Inkognito-Fenster. Verschwindet der Fehler sofort, waren wahrscheinlich eine alte Session oder eine alte Seite die Ursache. Schritt 2 verhindert den nächsten Rückfall. Bleibt der Fehler nach dem vollständigen Leeren bestehen, brauchst du Cache-Ausnahmen oder eine tiefere Diagnose.

2Caching für Warenkorb, Checkout und Bestellseiten deaktivieren

Schließe /cart, /checkout und /order-received sowie übersetzte Pfade wie /kasse/ und /warenkorb/ vom Seiten-Cache aus. CDN-Regeln wie „Cache Everything“ müssen WooCommerce-Cookies berücksichtigen und diese Seiten vom Cache ausnehmen. Leere die Caches danach noch einmal und prüfe, ob sich der HTML-Inhalt zwischen zwei anonymen Seitenaufrufen unterscheidet.

Bestellbestätigungs-URLs niemals im Seiten-Cache speichern.
wc-ajax=* und Store-API-Checkout-Routen vom Edge-Cache ausschließen.
JavaScript-Minimierung und verzögertes Laden während des Tests vorübergehend deaktivieren.

3WooCommerce-Status auf Datenbankwarnungen prüfen

Öffne WooCommerce → Status → Systemstatus. Notiere veraltete oder fehlende Tabellen und fehlgeschlagene geplante Aktionen. Wenn WooCommerce dazu auffordert, aktualisiere die Datenbank unter Status → Tools. Prüfe Status → Logs auf schwerwiegende Fehler sowie das Gateway-Log rund um den Fehlerzeitpunkt. Eine Belastung ohne passende WooCommerce-Bestellung ist ein starkes Indiz für ein Timing- oder Speicherproblem.

4Mit Standard-Theme und deaktivierten Plugins testen

Wechsle in der Staging-Umgebung oder im Health-Check-Problembehandlungsmodus zu Storefront oder einem Standard-Theme. Lass nur WooCommerce und das Zahlungs-Gateway aktiv. Lege eine Testbestellung an. Verschwindet der Fehler, aktiviere die Plugins schrittweise in Gruppen wieder, bis der Verursacher auftaucht. Rolle das Plugin zurück oder ersetze es. Bearbeite konfliktträchtige Checkout-Hooks nicht direkt im Live-Shop.

5Hosting-Logs auf MySQL-Timeouts prüfen

Suche beim Hoster oder im Hosting-Panel nach PHP-Fehlern und MySQL-Meldungen aus demselben Zeitraum wie die Kundenfehler: „Lock wait timeout“, „MySQL server has gone away“, „Disk full“ oder „max_connections“. Behebe zuerst das Infrastrukturproblem. Mit Plugins zu jonglieren repariert keine Datenbank, die Bestellungen unter Last nicht speichern kann.

So verhinderst du den Rückfall

Caches einmal zu leeren ist keine Strategie. Diese drei Gewohnheiten machen den Checkout robuster:

Korrektes Caching für WooCommerce

Behandle Warenkorb, Checkout, Mein Konto und Bestellbestätigung als Bereiche, die nie gecacht werden dürfen. Das gilt auch für eigene Checkout-URLs aus Page-Buildern. Prüfe die Ausnahmen nach jeder Änderung am Caching-Plugin oder an CDN-Regeln erneut. Veraltete Nonces und Sessions gehen oft mit diesem Datenbankfehler einher. Dieselbe Ausnahmeliste verhindert beide Arten stiller Checkout-Ausfälle. Führe nach jeder Caching-Änderung sofort einen ausgeloggten Testkauf aus.

Regelmäßige Datenbankchecks

Prüfe wöchentlich freien Speicherplatz, Slow-Query-Logs und Fehler im WooCommerce Action Scheduler. Bestätige nach größeren WooCommerce-Updates im Systemstatus den Zustand der WooCommerce-Datenbank. Prüfe auch hängende geplante Aktionen.

Den gesamten Ablauf regelmäßig prüfen

Führe nach jedem Fix einen vollständigen Testkauf durch, nicht nur einen Seitenaufruf. Unser Guide zu Monitoring von WordPress-Formularausfällen erklärt, warum Stichproben nächtliche Ausfälle übersehen. Prüfe auch die Bestellbestätigung. Eine gespeicherte Bestellung ohne E-Mail ist ein anderer stiller Fehler, dazu mehr in WooCommerce-Bestellbestätigung wird nicht gesendet.

Das eigentliche Problem: Der Fehler passiert nachts

ShopMonitor erkennt einen WooCommerce-Datenbankfehler am Checkout

Kunden stoßen auf diesen Fehler, wenn du offline bist. Sie brechen den Kauf ab. Selten landet ein Support-Ticket mit Screenshot des Fehlercodes bei dir. Drei Tage später folgt vielleicht eine Ein-Stern-Bewertung oder die Bestellungen brechen plötzlich ein, ohne Stacktrace in Slack.

Manuelle Stichproben erfassen kein Timing-Problem, das nur auftritt, wenn das Gateway langsam ist und viel Traffic auf den Shop trifft. Plugin-Aktualisierungen und Änderungen an CDN-Regeln können solche Probleme zusätzlich auslösen.

ShopMonitor führt automatisierte Checkout- und Formulartests nach Zeitplan aus: Warenkorb füllen, absenden, Ergebnis prüfen. Künftig prüft es zusätzlich die Zustellung transaktionaler E-Mails. Fehlt die Einreichung in der Datenbank, erhältst du eine Benachrichtigung direkt beim fehlgeschlagenen Durchlauf, nicht erst mit einer Bewertung.

Hör auf, Umsatz an kaputte Checkouts zu verlieren

ShopMonitor testet täglich Checkout und Formulare. Künftig testet es zusätzlich die Zustellung transaktionaler E-Mails. Wenn etwas nicht funktioniert, wirst du sofort benachrichtigt. Keine Code-Änderungen. Keine Plugins. In fünf Minuten eingerichtet.

Für die Testphase ist keine Kreditkarte nötig.

Kostenlose 14-Tage-Testphase starten →

Häufig gestellte Fragen

WooCommerce oder ein Zahlungs-Callback sucht nach einer Bestellung, Session oder Store-API-Submission-ID, die in MySQL nicht vorhanden ist. Die Meldung für Kunden kann unterschiedlich aussehen. Im Log stehen oft ein Fehlercode oder „not found in the database“. Meist wurde die Bestellung nicht vollständig gespeichert, die Abfrage kam zu früh oder Session beziehungsweise Cache verweist auf einen abgelaufenen Datensatz.

Ja. Gecachtes HTML im Checkout oder auf der Bestellbestätigungsseite kann abgelaufene Sessions oder Nonces ausliefern. Das Formular erreicht den Server, aber eine passende gültige Einreichung fehlt. Das wirkt wie ein Datenbankfehler, obwohl die Tabellen gesund sind. Schließe Warenkorb, Checkout und Bestellseiten vom Seiten-Cache und von CDN-Regeln wie „Cache Everything“ aus.

Prüfe WooCommerce → Status → Systemstatus auf Tabellen- und Versionswarnungen. Aktualisiere die Datenbank bei Bedarf unter Status → Tools. Kontrolliere außerdem Status → Logs und das MySQL-Error-Log des Hosters auf Timeouts oder Speicherprobleme. Behebe Infrastrukturprobleme, bevor du Plugins verdächtigst.

Ja, das kann passieren. Eine Zahlung kann beim Gateway autorisiert sein, obwohl im Shop keine Bestellung vorliegt. Umgekehrt kann der Kaufvorgang scheitern, während die Zahlung wieder aufgehoben wird. Gleiche nach einem Vorfall die Gateway-Abrechnungen mit den WooCommerce-Bestellungen ab und überwache den Checkout kontinuierlich, damit der nächste Fehler innerhalb weniger Minuten auffällt.

Zuletzt aktualisiert: August 2026. Gilt für WooCommerce 8.x+ auf WordPress 6.5+. Reproduziere Probleme vor Änderungen am Live-Checkout-Caching immer in einer Staging-Umgebung.

Über den Autor

Verfasst vom Winning Solutions-Team, der Agentur hinter ShopMonitor. Das Winning Solutions-Team entwickelt ShopMonitor.

Loading…

Alle Artikel

Hör auf, Umsatz an kaputte Checkouts zu verlieren

Für die Testphase ist keine Kreditkarte nötig.