Features Portfolio-Ansicht Für Agenturen Blog Preise FAQ Anmelden Kostenlos testen
← Alle Beiträge

Mollie in Shopware 6: „Payment exists, but the wrong mode is used“ – warum der Fehler jede Minute im Log steht

Mollie in Shopware 6: „Payment exists, but the wrong mode is used“ – warum der Fehler jede Minute im Log steht

Im Mollie-Log eines Kundenshops standen über 50.000 Einträge mit derselben Meldung. Der Checkout lief, Zahlungen kamen an, niemand hatte etwas bemerkt. Am Ende waren es genau zwei Transaktionen, beide aus einer Zeit, in der der Verkaufskanal noch im Testmodus lief. Das Mollie-Plugin hat sie jede Minute erneut bei Mollie nachgefragt, und Mollie hat jede Minute dieselbe Antwort gegeben.

Die Fehlermeldung

Pro Durchlauf tauchen zwei Zeilen im mollie-Channel auf, erst die Antwort der API, dann die Meldung des Status-Abgleichs:

mollie.ERROR: There was an error from Mollies API
{"title":"Not Found","error":"Payment tr_XXXXXXXXXX exists, but the wrong mode is used. Try switching live / test API keys.","field":"no field"}
{"file":"/var/www/shop/custom/plugins/MolliePayments/shopware/Component/Mollie/Gateway/ExceptionTrait.php","line":22,"class":"Mollie\\Shopware\\Component\\Mollie\\Gateway\\MollieGateway","function":"convertException","pluginVersion":"5.3.0"}

mollie.ERROR: Failed to update status for transaction
{"transactionId":"018f2c3d4e5f6a7b8c9d0e1f2a3b4c5d","error":"Error in field . Not Found: Payment tr_XXXXXXXXXX exists, but the wrong mode is used. Try switching live / test API keys. "}
{"file":"/var/www/shop/custom/plugins/MolliePayments/shopware/Component/StatusUpdate/UpdateStatusAction.php","line":42,"class":"Mollie\\Shopware\\Component\\StatusUpdate\\UpdateStatusAction","function":"execute"}

Wichtig für die Diagnose: Es sind immer dieselben tr_-IDs und dieselben transactionIds. Wenn du in deinem Log nur zwei oder drei verschiedene IDs findest, egal wie viele Zeilen es sind, bist du hier richtig.

Was dahintersteckt

Mollie trennt Test- und Live-Daten strikt. Laut Mollie-Doku zum Testen sind alle Zahlungen, die im Testmodus angelegt werden, vollständig von den Live-Daten isoliert. Welcher Modus gilt, entscheidet der API-Key: Jedes Website-Profil hat einen Test- und einen Live-Key (Mollie-Doku zur Authentifizierung). Fragst du eine Testzahlung mit dem Live-Key ab, findet Mollie sie zwar, liefert aber 404 Not Found mit genau diesem Hinweis.

Dass das nicht einmal passiert, sondern im Minutentakt, liegt am Plugin. Das Mollie-Plugin bringt (zumindest in Version 5.3.0, in der wir den Fehler gesehen haben) einen Scheduled Task mollie.status.update mit, der alle 60 Sekunden läuft. Im Quellcode (UpdateStatusAction.php auf GitHub) sieht man, was er tut: Er holt sich Transaktionen, die noch auf „In Bearbeitung“ oder „Unbestätigt“ stehen, Mollie-Daten tragen und deren Bestellung zwischen fünf Minuten und 101 Tagen alt ist. Für jede davon ruft er intern den Webhook-Ablauf auf, also eine Statusabfrage bei Mollie.

Eine Testbestellung, die nie bezahlt oder abgebrochen wurde, bleibt auf „In Bearbeitung“ stehen. Wird der Verkaufskanal danach auf live umgestellt, fragt der Task sie mit dem Live-Key ab. Mollie lehnt ab, der Task loggt den Fehler, der Status ändert sich nicht, und eine Minute später geht es von vorn los. Bis die Bestellung aus dem 101-Tage-Fenster fällt.

Typische Auslöser:

  • Testbestellungen kurz vor dem Go-live, danach Testmodus aus
  • eine Staging-Datenbank, die mitsamt Testbestellungen in die Produktion kopiert wurde
  • ein Verkaufskanal, für den der Testmodus in der Plugin-Konfiguration anders steht als gedacht

Prüfen, ob es wirklich das ist

Erst die IDs zählen. Bei vielen verschiedenen tr_-IDs hast du ein anderes Problem, etwa falsche API-Keys für den ganzen Kanal, und dann scheitern auch neue Zahlungen.

grep -h "wrong mode is used" var/log/mollie*.log \
  | grep -o 'tr_[A-Za-z0-9]*' | sort | uniq -c | sort -rn

Dann die Shopware-Transaktion aus dem Feld transactionId nachschlagen. Die ID im Log ist hexadezimal, in der Datenbank liegt sie binär:

SELECT o.order_number,
       o.order_date_time,
       sms.technical_name AS payment_state
FROM order_transaction ot
JOIN `order` o
  ON o.id = ot.order_id AND o.version_id = ot.order_version_id
JOIN state_machine_state sms
  ON sms.id = ot.state_id
WHERE ot.id = UNHEX('018f2c3d4e5f6a7b8c9d0e1f2a3b4c5d')
  AND ot.version_id = UNHEX('0fa91ce3e96a4bc2be4bd9ce752c3425');

Steht dort in_progress oder unconfirmed und ist das Bestelldatum älter als der Zeitpunkt, an dem ihr live gegangen seid, ist der Fall klar. Zur Gegenprobe im Mollie-Dashboard auf den Testmodus umschalten und nach der tr_-ID suchen. Sie taucht dort auf, im Live-Modus nicht.

Die Lösung

Die eigentliche Korrektur ist unspektakulär: Die betroffenen Transaktionen müssen aus dem Status „In Bearbeitung“ raus. Sobald sie einen Endstatus haben, findet der Task sie nicht mehr.

  1. Bestellung in der Administration öffnen (Bestellnummer aus der Abfrage oben).
  2. Im Testmodus des Mollie-Dashboards nachsehen, was mit der Zahlung passiert ist. Bei Testbestellungen ist die Antwort fast immer: nichts, sie ist offen oder abgelaufen.
  3. Den Zahlungsstatus in Shopware von Hand auf „Abgebrochen“ setzen und die Testbestellung gleich mit stornieren.

Ab dem nächsten Lauf von mollie.status.update verschwinden die Einträge. Gegenprobe nach ein paar Minuten:

tail -n 200 var/log/mollie*.log | grep -c "wrong mode is used"

Ohne Eingriff hört der Fehler übrigens auch auf, nämlich wenn die Bestellung älter als 101 Tage ist. Das ist kein Fix, sondern drei Monate Lograuschen, in denen echte Mollie-Fehler untergehen.

Plugin-Update hilft nur teilweise

Im betroffenen Shop lief Plugin-Version 5.3.0. Laut Changelog hat Mollie danach zwei Dinge am Abgleich geändert:

  • 5.5.0: „Der Abgleich offener Zahlungen mit Mollie ist nun abgeschaltet und in der Auftragsverwaltung pro Verkaufskanal aktivierbar.“
  • 5.6.0: „Der Abgleich offener Zahlungen mit Mollie bleibt nach einem Fehler nicht mehr dauerhaft stehen.“

Nach einem Update auf 5.5.0 oder neuer ist der Minutentakt also erst einmal weg, weil der Abgleich standardmäßig aus ist. Die alten Testtransaktionen hängen aber weiter auf „In Bearbeitung“. Schaltest du den Abgleich für den Verkaufskanal wieder ein, ist der Fehler sofort zurück. Die Status-Korrektur oben brauchst du deshalb in jedem Fall.

Wenn das nicht hilft

Wenn die Meldung bei neuen Bestellungen auftaucht, nicht nur bei alten, ist die Konfiguration selbst falsch. Dann stimmt im betroffenen Verkaufskanal entweder der Testmodus-Schalter nicht oder einer der beiden Keys gehört zu einem anderen Mollie-Profil. Die Plugin-Konfiguration ist pro Verkaufskanal überschreibbar, und genau dort verstecken sich gern abweichende Werte. Also jeden Kanal einzeln öffnen, nicht nur „Alle Verkaufskanäle“.

Dieselbe Meldung kann außerdem beim Erstatten oder Versand-Melden aus der Administration kommen, wenn die Bestellung im anderen Modus angelegt wurde. Auch dann ist die Ursache dieselbe: Bestellung und Key passen nicht zusammen. Eine Testzahlung lässt sich mit dem Live-Key nicht erstatten.

Ob dein Shop gerade so eine Schleife im Log hat, siehst du nur, wenn jemand die Fehlerzahlen über die Zeit betrachtet. 50.000 identische Zeilen fallen in keiner Datei auf, als Kurve schon. ShopSignal zählt Fehler und Warnungen deiner Shopware-Shops, macht die Logs durchsuchbar und meldet sich über eigene Alarmregeln, wenn die Fehlerrate plötzlich steigt.