Devkollektiv kollektiv.dev

Module Magento

Magento Verfügbar

Checkout-Blacklist

Sperrt Bestellungen anhand von E-Mail-Domains und Namensfragmenten — im Checkout und noch einmal beim Bestellabschluss.

Wegwerfadressen, immer derselbe Fantasiename, Bestellungen mit spitzen Klammern im Vornamen: Wer solche Bestellungen von Hand aussortiert, macht das jeden Tag aufs Neue. Das Modul erledigt es an der Stelle, an der es billiger ist — bevor die Bestellung entsteht.

Gepflegt werden zwei Listen. Die eine sperrt E-Mail-Domains, auf Wunsch samt Subdomains: Steht „example.com" drin, ist mit der Option auch „mail.example.com" gesperrt. Die andere sperrt Namensfragmente — literale Teilstrings, keine regulären Ausdrücke. Damit lassen sich sowohl ganze Namen als auch einzelne Sonderzeichen blockieren, die in einem echten Namen nie vorkommen.

Greift eine Regel, liefert Magento für diesen Warenkorb schlicht keine Zahlungsarten mehr aus. Das ist die freundliche Hälfte. Die verbindliche sitzt tiefer: Auch das Setzen einer Zahlungsart und die Übernahme des Warenkorbs in eine Bestellung sind abgesichert. Wer den Checkout umgeht und direkt über REST oder GraphQL bestellt, kommt genauso wenig durch.

Bestellungen aus dem Backend bleiben bewusst unangetastet — wenn dein Team eine Bestellung von Hand anlegt, gibt es dafür einen Grund. Und protokolliert wird nichts: weder E-Mail-Adressen noch Namen landen im Log.

Funktionen

  • Sperrliste für E-Mail-Domains, wahlweise inklusive Subdomains
  • Sperrliste für Namensfragmente und einzelne Zeichen — literal, ohne reguläre Ausdrücke
  • Prüfung gegen Vor-, Mittel- und Nachname, Prefix und Suffix sowie den zusammengesetzten Namen aus Rechnungs- und Lieferadresse
  • Groß-/Kleinschreibung wird ignoriert; Domains dürfen mit oder ohne führendes @ notiert werden
  • Dreifache Absicherung: Zahlartenliste, Zahlartenauswahl und Bestellabschluss
  • Wirkt auch bei Bestellungen über REST und GraphQL, nicht nur im Storefront-Checkout
  • Backend-Bestellungen werden bewusst nicht blockiert
  • Eigene Fehlermeldung für den Fall, dass jemand die Sperre direkt zu umgehen versucht
  • Kein Logging von E-Mail-Adressen oder Namen
  • Einstellbar bis auf Store-View-Ebene, mit eigener ACL-Ressource

Voraussetzungen

  • Magento Open Source 2.4.8
  • PHP 8.2 oder neuer
  • Keine Core-Änderungen, keine zusätzlichen Datenbanktabellen

Häufige Fragen

Reicht es nicht, die Bestellung hinterher zu stornieren?
Funktioniert, kostet aber jedes Mal Arbeitszeit — und bei Zahlarten mit sofortiger Buchung zusätzlich eine Rückabwicklung. Der Aufwand fällt weg, wenn die Bestellung gar nicht erst entsteht.
Kann jemand die Sperre umgehen, indem er den Checkout überspringt?
Nein. Die ausgeblendeten Zahlungsarten sind nur die sichtbare Ebene. Geprüft wird zusätzlich beim Setzen der Zahlungsart und bei der Übernahme des Warenkorbs in eine Bestellung — beides serverseitig und unabhängig davon, ob die Anfrage aus dem Checkout, aus REST oder aus GraphQL kommt.
Sind die Namensfragmente reguläre Ausdrücke?
Nein, bewusst nicht. Es sind literale Teilstrings, verglichen ohne Rücksicht auf Groß- und Kleinschreibung. Das ist die Entscheidung gegen ein Muster, das im Backend versehentlich halbe Kundenlisten aussperrt — und dafür, dass jeder im Team die Liste pflegen kann.
Werden ganze E-Mail-Adressen gesperrt?
Nein, geprüft wird ausschließlich die Domain. Eine einzelne Adresse zu sperren bringt bei Wegwerfdiensten wenig, weil die nächste Adresse eine Sekunde später existiert. Wer trotzdem eine bestimmte Person aussperren will, arbeitet über die Namensliste.
Warum werden Backend-Bestellungen nicht blockiert?
Weil jemand aus deinem Team sie angelegt hat. Wenn eine Bestellung telefonisch aufgenommen wird und die Adresse zufällig auf einer gesperrten Domain liegt, soll die Sperre nicht im Weg stehen. Sie richtet sich gegen automatisierte und mutwillige Bestellungen, nicht gegen den Innendienst.
Kann es passieren, dass Zahlungsarten kurz sichtbar sind, obwohl gesperrt ist?
Bei einem rein virtuellen Warenkorb einer Gastbestellung ja: Magento kann die Zahlungsarten schon anzeigen, bevor E-Mail und Rechnungsname am Warenkorb gespeichert sind. Sobald die Daten serverseitig vorliegen, greift die Filterung. Der Bestellabschluss selbst wird unabhängig davon immer blockiert.

Änderungen

  • Version 1.0.0 08.09.2026

    • Erste Veröffentlichung