Doppelte Bestellungen und doppelte Abbuchung in PrestaShop: Ursachen und Vermeidung

Der Kunde hat einmal bezahlt. In Ihrem Back Office gibt es zwei Bestellungen aus demselben Warenkorb, jede mit eigener Rechnung und abgebuchtem Bestand. Oder es gibt nur eine Bestellung, aber zweimal mit dem Status „Zahlung angenommen“ und zwei nummerierten Rechnungen. Einzeln betrachtet wirken beide Bestellungen korrekt; deshalb bleibt dieses Problem unbemerkt, bis Sie die Bank abgleichen oder der Kunde reklamiert.

Woher die Duplikate kommen

1. Zwei Benachrichtigungen des Zahlungsanbieters gleichzeitig

Das ist die häufigste und am wenigsten sichtbare Ursache. Viele Zahlungsanbieter melden die Zahlung auf zwei Wegen: die Server-zu-Server-Benachrichtigung (Webhook, IPN, Online-Benachrichtigung) und die Rückkehr des Kunden in den Shop. Kommen beide fast gleichzeitig an, fragt jede „Gibt es schon eine Bestellung für diesen Warenkorb?“, beide erhalten „nein“, weil noch keine sie angelegt hat, und jede legt ihre eigene an. Eine klassische Race Condition.

2. Wiederholte Webhooks

Antwortet Ihr Server langsam oder gibt einen Fehler zurück, sendet der Zahlungsanbieter die Benachrichtigung erneut. Prüft das Zahlungsmodul nicht, ob es sie bereits verarbeitet hat, wiederholen sich Bestellung oder Status.

3. Doppelklick oder Neuladen

Der Kunde klickt zweimal auf „Bezahlen“ oder lädt die Bestätigungsseite neu. Bei Methoden ohne Weiterleitung (Überweisung, Nachnahme) kann das genügen, um zwei Bestellungen anzulegen.

4. Das Back Office

Ein Mitarbeiter ändert den Status einer Bestellung, die Seite braucht lange, und er klickt noch einmal. Der Status wird zweimal angewendet, und wenn dieser Status eine Rechnung erzeugt, entstehen zwei.

5. Module, die auf dasselbe Ereignis reagieren

Zwei Module, die auf die Statusänderung hören, und eines davon ändert ihn erneut, oder ein ERP, das einen bereits angewendeten Status noch einmal sendet.

Wie Sie es in Ihrer Historie erkennen

1. Warenkörbe mit mehr als einer Bestellung. In PrestaShop sollte ein Warenkorb nur eine Bestellung ergeben (außer bei nach Versanddienstleister aufgeteilten Bestellungen, die sich eine Referenz teilen). Eine Abfrage, die Bestellungen nach id_cart gruppiert und die zählt, die mehr als eine haben, ist der erste Filter.
2. Wiederholte Status. Bestellungen, die denselben Zahlungsstatus zweimal in ihrem Verlauf haben.
3. Doppelte Rechnungen für dieselbe Bestellung.
4. Abbuchungen gegenüber Bestellungen. Vergleichen Sie die in jeder Bestellung erfassten Zahlungen mit dem, was der Zahlungsanbieter sagt. Zwei Bestellungen und eine Abbuchung sind ein Problem bei Bestand und Rechnungsstellung; zwei Bestellungen und zwei Abbuchungen sind zu viel kassiertes Geld, das erstattet werden muss.

Wie Sie sie bereinigen, ohne es schlimmer zu machen

• Löschen Sie keine Bestellungen. Die Nachvollziehbarkeit geht verloren, und wenn es eine Rechnung gab, brechen Sie die Nummerierung. Stornieren Sie die überzählige.
• Eine nummerierte Rechnung wird nicht zurückgezogen: Sie wird mit einer Rechnungskorrektur aufgehoben, wie es die spanische Rechnungsverordnung verlangt (Real Decreto 1619/2012, Artikel 15).
• Buchen Sie den Bestand der überzähligen Bestellung zurück und prüfen Sie, dass er nicht schon zurückgebucht wurde.
• Gab es zwei Abbuchungen, entscheidet ein Mensch über die Erstattung, und sie erfolgt über den Zahlungsanbieter.
• Fassen Sie bereits versendete Bestellungen nicht an, ohne sie einzeln zu prüfen.

Wie Sie es verhindern

1. Sperre pro Warenkorb beim Anlegen der Bestellung. Die zweite Benachrichtigung muss warten, bis die erste fertig ist, und beim Eintritt sehen, dass die Bestellung bereits existiert. Das ist die grundlegende Lösung für die Race Condition.
2. Idempotenz bei den Webhooks: die Kennung jeder verarbeiteten Benachrichtigung speichern und bereits Erledigtes nicht wiederholen.
3. Dem Zahlungsanbieter schnell antworten: Braucht der Webhook lange, wiederholt der Anbieter. Was langsam ist (E-Mails, ERP), besser danach.
4. Den Bezahl-Button beim Klicken deaktivieren, ebenso in den Statusformularen des Back Office.
5. Ein einziger Weg, der die Bestellung anlegt, pro Zahlungsanbieter, sofern das Modul es erlaubt.
6. Überwachung: Ein Hinweis in dem Moment, in dem ein Duplikat entsteht, ist mehr wert, als es Monate später zu finden.

Was Sie nicht tun sollten

• Den Kern von PrestaShop oder das Zahlungsmodul ändern, um es zu „reparieren“: Das nächste Update macht es rückgängig.
• Die Server-Benachrichtigung deaktivieren und sich ganz auf die Rückkehr des Kunden verlassen: Schließt er den Tab, wird die Bestellung nicht angelegt.
• Im Stapel bereinigen, ohne vorherigen Probelauf.

Checkliste

1. Suchen Sie in der gesamten Historie nach Warenkörben mit mehr als einer Bestellung.
2. Ordnen Sie ein: eine Abbuchung und zwei Bestellungen oder zwei Abbuchungen.
3. Stornieren Sie Überzählige, buchen Sie den Bestand zurück und stellen Sie wo nötig Rechnungskorrekturen aus.
4. Prüfen Sie, wie jeder Zahlungsanbieter benachrichtigt und ob seine Webhooks wiederholt werden.
5. Setzen Sie eine Sperre beim Anlegen der Bestellung und bei der Statusänderung.
6. Aktivieren Sie Benachrichtigungen, um es noch am selben Tag zu erfahren.

Die Umsetzung in PrestaShop

RKR Order Guard setzt eine MySQL-Sperre, bevor der Controller des Zahlungsmoduls irgendetwas lädt, sodass die zweite Benachrichtigung wartet und die Bestellung bereits angelegt vorfindet; außerdem sperrt es die Bestellung während der Statusänderung, damit keine zwei Rechnungen entstehen, und verhindert das doppelte Absenden des Statusformulars im Back Office. Ohne Overrides. Unter Bestellungen → Doppelte Bestellungen prüft es die gesamte Historie und ordnet jeden Warenkorb ein: eine Abbuchung und zwei Bestellungen (storniert die überzählige und bucht den Bestand zurück), zwei Abbuchungen (über die Erstattung entscheidet ein Mensch) oder unbestimmt (listet ihn nur auf). Es erlaubt eine Simulation vor der Ausführung, löscht nie Bestellungen, stellt keine Erstattungen aus und fasst keine Bestellungen mit versendetem Paket oder bereits nummerierten Rechnungen an, und läuft die Wartezeit der Sperre ab, geht der Verkauf weiter. RKR Sentinel, das diesen Artikel begleitet, meldet per Telegram Zahlungen ohne Bestellung, nicht übereinstimmende Beträge und hängende Bestellungen.