Gefälschte Bestellungen gehören zu den frustrierendsten Problemen, mit denen eine WooCommerce-Betreiberin konfrontiert sein kann. Bots, die hunderte betrügerische Bestellungen platzieren, Card-Testing-Angriffe, die Gateway-Gebühren verschlingen, und Phantomkund:innen, die Ihre Bestellliste überfluten. Wir haben kürzlich eine hartnäckige Welle gefälschter Bestellungen im Shop eines Kunden bekämpft — und gewonnen. Hier ist alles, was wir gelernt haben.
Das Problem: Bots, die nicht aufgeben
Unser Kunde, ein Händler für gewerbliche Ausrüstung, bemerkte ein Muster: Bestellungen aus unbekannten Quellen, oft über bestimmte Dollarbeträge, mit E-Mail-Adressen, die zu keiner echten Kundschaft passten. Die Bestellungen scheiterten entweder am Payment-Gateway (Card-Testing) oder gingen mit gestohlenen Kartendaten durch.
Die Standardinstallation von WooCommerce bietet fast keinen eingebauten Schutz dagegen. Payment-Gateways fangen einige schlechte Karten ab — aber dann haben Sie schon Gebühren bezahlt und Ihre Bestellliste ist ein Chaos.
Schicht 1: Bekannte Täter beim Checkout blockieren
Die erste und wirkungsvollste Schicht ist, bekannte Betrüger zu stoppen, bevor sie überhaupt bestellen können. Das bedeutet, Sperrlisten zu pflegen für:
- E-Mail-Adressen — konkrete Adressen oder Muster, die in Betrugsfällen aufgetaucht sind
- IP-Adressen — unterstützt einzelne IPs und CIDR-Bereiche (z. B.
192.168.1.0/24) - Telefonnummern — mit Wildcard-Unterstützung zum Sperren ganzer Vorwahlen
Diese Prüfungen laufen während der Checkout-Validierung von WooCommerce — die Bestellung wird mit einer allgemeinen Meldung „Sicherheitsbedenken“ abgelehnt, bevor überhaupt eine Zahlung versucht wird. Die Kundschaft erfährt nie, welche Prüfung gegriffen hat, was es Bots erschwert, sich anzupassen.
Schicht 2: Betrugsanalyse nach der Zahlung
Einige Prüfungen können nicht beim Checkout erfolgen, ohne False Positives auszulösen. Die wichtigste: unbekannte Bestellherkunft.
WooCommerce verfolgt per Attribution-Cookie, woher Bestellungen stammen. Bestellungen über den normalen Checkout-Flow werden mit einer Quelle versehen. Von Bots platzierte Bestellungen zeigen üblicherweise „unknown“, weil Bots das JavaScript, das dieses Cookie setzt, nicht ausführen.
Wichtige Lektion: Wir haben zunächst Bestellungen mit unbekannter Herkunft beim Checkout blockiert. Das führte sofort zu gesperrten legitimen Kund:innen — jede Person, die Safari mit ITP (Intelligent Tracking Prevention) verwendet, datenschutzorientierte Browser-Erweiterungen nutzt oder auf Sites mit aggressivem Caching unterwegs ist, verlor das Attribution-Cookie. Die Lösung: Herkunft nur nach der Zahlung prüfen und die Bestellung zur Überprüfung markieren, statt die Kundschaft ganz zu blockieren.
Die Post-Payment-Analyse prüft alles: Herkunft, verdächtige Beträge, Sperrlisten, Proxy-Erkennung und IP-Wiederholungsraten. Verdächtige Bestellungen werden automatisch in einen eigenen Status „Betrug — automatisch storniert“ verschoben und lösen eine E-Mail-Benachrichtigung an den Shop-Admin aus.
Schicht 3: Auch fehlgeschlagene Bestellungen erfassen
Etwas, das leicht übersehen wird: Card-Testing-Bestellungen von Bots scheitern immer am Payment-Gateway. Der Bot reicht gestohlene Kartennummern ein, um zu sehen, welche gültig sind. Das Gateway lehnt die meisten ab, und die Bestellung landet im Status „Failed“.
Das Problem? Fehlgeschlagene Bestellungen erreichen nie die Danke-Seite, also greift Ihre Post-Payment-Betrugsprüfung nie. Ihre Betrugsprüfung ist für diese Bestellungen völlig blind.
Die Lösung: Hooks auf die Status-Übergänge „Failed“ und „Cancelled“ — aber nur für Bestellungen, die über die Store-API kamen. Warum diese Unterscheidung? Legitime Kund:innen, deren Karte abgelehnt wird, versuchen es natürlich erneut, oft mehrfach von derselben IP. Wenn Sie jede fehlgeschlagene Bestellung analysieren, lösen diese Wiederholungen Ihre IP-Wiederholungserkennung aus, und plötzlich wird eine echte Person als Betrug markiert. Indem Sie die Analyse fehlgeschlagener Bestellungen auf Store-API-Bestellungen beschränken (die legitime Kund:innen im klassischen Checkout nie erzeugen), erwischen Sie die Bots, ohne echte Menschen wegen eines schlechten Kartentages zu bestrafen.
Schicht 4: Die REST-API härten
Das war die größte Lektion überhaupt. Modernes WooCommerce nutzt die Store-API für den Block-Checkout. Das ist ein öffentlicher REST-Endpunkt, der Bestellungen entgegennimmt — und Bots haben herausgefunden, dass sie direkt per POST darauf zugreifen und so Ihre Checkout-Seite komplett umgehen können.
Die Lösung: REST-API-Anfragen abfangen und unauthentifizierte Bestellversuche blockieren. Aber Sie müssen klug entscheiden, was Sie durchlassen:
- Admin-Nutzende mit WooCommerce-Management-Berechtigung — immer erlaubt
- WooCommerce-API-Key-Authentifizierung — für Drittanbieter-Integrationen
- OAuth/Bearer-Token-Authentifizierung — für Mobile Apps und externe Services
- Gültige Store-API-Nonce — so funktioniert der legitime Block-Checkout
Die Nonce-Falle
Das ist entscheidend und verdient einen eigenen Abschnitt. Als wir die REST-Härtung zum ersten Mal umsetzten, verifizierten wir Nonces strikt über die WordPress-Nonce-Prüfung. Dann wurden wir wegen Randfällen nervös und lockerten es auf eine reine Existenzprüfung — nur prüfen, dass ein Nonce-Header vorhanden ist, ohne ihn tatsächlich zu validieren.
Innerhalb weniger Stunden passten sich die Bots an. Sie begannen, Anfragen mit einem gefälschten Nonce-Header mit Zufallswerten zu senden. Unsere reine Existenzprüfung ließ sie einfach durch.
Lehre: Nonces immer strikt verifizieren. Der legitime Block-Checkout hat stets ein gültiges Nonce, weil das JavaScript von WooCommerce es bei jedem Seitenaufruf frisch generiert. Bots können Header fälschen, aber keine gültigen WordPress-Nonces — dafür müssten sie JavaScript auf Ihrer realen Site ausführen.
Schicht 5: Rate-Limiting pro IP
Selbst mit allem Bisherigen kann ein entschlossener Angreifer E-Mails und Details rotieren. Was sie nicht so leicht rotieren können, ist ihre IP-Adresse (oder zumindest ist ihr IP-Pool begrenzt). Bestellungen pro IP innerhalb eines konfigurierbaren Zeitfensters zu zählen, bietet ein weiteres Sicherheitsnetz.
Wenn dieselbe IP mehr als X Bestellungen innerhalb von Y Minuten aufgibt, werden alle weiteren Bestellungen von dieser IP markiert. Das erwischt das Feuerstoß-Muster von Card-Testing-Bots.
Handhabbar machen: Das Admin-Erlebnis
All das ist nutzlos, wenn die Shop-Administration nicht sehen kann, was passiert. Ein paar Dinge haben den Unterschied gemacht:
- Benutzerdefinierter Bestellstatus-Filter — Ein Tab „Betrug“ in der Bestellliste, gleich neben Bearbeitung, Abgeschlossen und Storniert. Ein Klick, und alle markierten Bestellungen sind sichtbar.
- E-Mail-Benachrichtigungen — Sofortige Meldung, wenn eine verdächtige Bestellung erkannt wird, mit Bestelldaten, Rechnungsangaben und den konkreten Betrugsindikatoren.
- Konfigurierbare Schalter — Jede Erkennungsregel lässt sich unabhängig ein- oder ausschalten. Die REST-Härtung hat einen eigenen Schalter. So können Sie die richtige Balance für Ihren Shop einstellen.
Was wir unterwegs falsch gemacht haben
Transparenz zählt. Hier sind die Fehler, die wir gemacht haben — damit Sie sie nicht machen müssen:
- Unbekannte Herkunft beim Checkout blockieren — Führte zu False Positives bei Safari-Nutzenden und Leuten mit Datenschutz-Erweiterungen. Auf Post-Payment-Prüfung umgestellt.
- Nonce-Verifizierung lockern — Bots nutzten die reine Existenzprüfung sofort aus. Kompromittieren Sie niemals die Nonce-Validierung.
- Annehmen, dass fehlgeschlagene Bestellungen nicht zählen — Card-Testing-Bots erzeugen hunderte Failed-Bestellungen, die für unsere Betrugsprüfung unsichtbar waren. Sie müssen fehlgeschlagene Bestellungen analysieren — aber selektiv (siehe nächster Punkt).
- Alle Failed-Bestellungen gleich analysieren — Unsere ursprüngliche Lösung wandte jede Betrugsprüfung auf jede Failed-Bestellung an. Das fing Bots, aber auch legitime Kund:innen, die nach einer abgelehnten Karte erneut versuchten. Mehrere Retries von derselben IP triggern das Rate-Limiting, und echte Kund:innen tauchten plötzlich in der „Top-Betrugs-E-Mails“-Auswertung auf. Die Lösung: Nur Failed-Bestellungen analysieren, die über die Store-API kamen — den Kanal, den Bots nutzen. Failed-Bestellungen vom klassischen Checkout bleiben unangetastet.
- HTML in Klartext-E-Mails — Die Preisformatierungsfunktionen von WooCommerce liefern HTML mit
<span>-Tags zurück. In einer Klartext-E-Mail ist das unlesbar. Entfernen Sie HTML immer, wenn Sie Klartext-Inhalte zusammenbauen.
Die Ergebnisse
Nach Einführung aller fünf Schichten ging der Shop von Dutzenden gefälschten Bestellungen pro Tag auf null zurück. Legitime Kund:innen waren nicht betroffen — die einzige Prüfung, die False Positives verursachen konnte (unbekannte Herkunft), läuft nach der Zahlung und markiert zur Überprüfung, statt zu blockieren.
Die Kernerkenntnis: Keine einzelne Prüfung reicht aus. Bots passen sich an. Was sie stoppt, ist eine gestaffelte Verteidigung — jede Schicht fängt, was die anderen übersehen. Sperrlisten stoppen bekannte Täter. Post-Payment-Analyse erwischt neue Muster. REST-Härtung blockiert den API-Missbrauch-Vektor. Rate-Limiting fängt hochvolumige automatisierte Angriffe. Zusammen ergeben sie ein Netz, durch das es sehr schwer zu schlüpfen ist.
Wollen Sie das auch für Ihren Shop?
Wir haben das als WordPress-Plugin namens WC Antifraud gebaut. Es ist Open-Source und auf GitHub verfügbar. Wenn Ihr WooCommerce-Shop mit gefälschten Bestellungen, Card-Testing-Angriffen oder Bot-Missbrauch zu kämpfen hat, könnte es genau das sein, was Sie brauchen.
Das Plugin deckt alle fünf oben beschriebenen Schichten ab, mit übersichtlicher Einstellungs-Oberfläche, E-Mail-Benachrichtigungen, Aktivitätsprotokoll und Reports-Dashboard. Es funktioniert mit dem klassischen Checkout ebenso wie mit dem neuen Block-Checkout und ist kompatibel mit HPOS (High-Performance Order Storage) von WooCommerce.
Schauen Sie es sich auf GitHub an — und wenn Sie Unterstützung bei der Einrichtung oder Anpassung für Ihren Shop brauchen, kontaktieren Sie uns.
