Betrugserkennung im Magento 2 Checkout: Fraud Prevention richtig umsetzen

1. Warum Betrugserkennung erst im Checkout wirklich greift

Viele Magento-Projekte behandeln Betrugserkennung als nachgelagertes Problem: Man wartet auf die Rückbuchung, storniert dann manuell und hofft, dass der nächste Fall seltener wird. Das ist teuer, weil zu diesem Zeitpunkt Ware bereits das Lager verlassen hat und die Zahlung meist schon verbucht ist. Effektive Fraud Prevention setzt genau am Checkout an, bevor eine Bestellung den Status "verarbeitet" erreicht, und bewertet dort verfügbare Signale, während noch Handlungsspielraum besteht.

Der entscheidende Unterschied zu generischen Fraud-Filtern liegt darin, dass Magento zur Checkout-Zeit bereits eine ganze Reihe kontextreicher Daten besitzt: Kundenhistorie, Zahlungsart, Adressdaten, Warenkorb-Wert und die Reihenfolge vorheriger Bestellversuche. Eine eigene Betrugserkennung, die diese Daten direkt im Order-Placement-Flow auswertet, ist günstiger zu betreiben als ein nachträglicher Abgleich mit einer externen Blacklist und lässt sich präzise auf das eigene Sortiment und die eigene Kundenstruktur zuschneiden.

Wichtig ist dabei die Trennung zweier Verantwortlichkeiten: Ein Scoring-Mechanismus bewertet das Risiko einer Bestellung, eine separate Entscheidungslogik legt fest, was mit diesem Score passiert. Diese Trennung erlaubt es, im Laufe der Zeit Schwellenwerte anzupassen, ohne die eigentliche Signalerhebung anzufassen, und macht die gesamte Fraud-Prevention-Pipeline testbar und nachvollziehbar.

2. Konkrete Fraud-Signale zur Checkout-Zeit

Die Grundlage jeder Betrugserkennung ist eine überschaubare Menge konkreter, messbarer Signale statt eines diffusen "Bauchgefühls". Ein Abgleich von Rechnungs- und Lieferadresse ist das einfachste Signal: Weichen Land, Postleitzahl-Region oder sogar der Name deutlich voneinander ab, steigt das Risiko einer Kartenbetrugs-Transaktion messbar. Ergänzend zählt die Velocity, also wie viele Bestellungen dieselbe Kundenkennung, IP-Adresse oder E-Mail-Domain innerhalb eines kurzen Zeitfensters auslöst. Drei Bestellungen von derselben IP in fünf Minuten mit unterschiedlichen Kreditkarten sind ein klassisches Testing-Muster für gestohlene Kartendaten.

Ein weiteres starkes Signal ist die hochwertige Erstbestellung als Gast: Ein neuer, nicht eingeloggter Kunde, der ohne Bestellhistorie einen ungewöhnlich hohen Warenkorb kauft und Express-Versand wählt, weicht statistisch vom normalen Kaufverhalten ab. Ähnlich aussagekräftig ist der Vergleich von BIN-Land (Bank Identification Number der Kreditkarte) und Versandland: Eine amerikanische Karte, die an eine Adresse in Osteuropa versendet werden soll, ist zwar nicht automatisch betrügerisch, aber ein Signal, das in eine Risikobewertung einfließen muss. Wegwerf-E-Mail-Domains aus bekannten Listen temporärer Anbieter sind ein zusätzlicher, leicht prüfbarer Indikator, ebenso wie mehrere fehlgeschlagene Zahlungsversuche in kurzer Folge, die auf systematisches Durchprobieren gestohlener Kartennummern hindeuten.

Keines dieser Signale allein rechtfertigt eine automatische Ablehnung. Erst die Kombination mehrerer Signale in einem gewichteten Score liefert eine belastbare Grundlage für Fraud Prevention, die zwischen tatsächlich riskanten und lediglich ungewöhnlichen, aber legitimen Bestellungen unterscheidet.

3. RiskScoringInterface: Ein Service Contract für Risk-Scoring

Damit die Betrugserkennung nicht als verstreute Bedingungslogik in Observer-Klassen landet, definieren wir sie als eigenen Service Contract. Das Interface RiskScoringInterface nimmt eine Order-Entität entgegen und liefert ein Result-Objekt mit numerischem Score und den ausgelösten Signalen zurück. Die konkrete Implementierung sammelt die einzelnen Signal-Checks, gewichtet sie und aggregiert das Ergebnis, ohne dass der Aufrufer die interne Berechnungslogik kennen muss.

Constructor Property Promotion macht die Implementierung kompakt: Jeder einzelne Signal-Checker (Adress-Abgleich, Velocity-Check, BIN-Länder-Check) wird als eigene, injizierbare Klasse implementiert und über den Konstruktor der Scoring-Klasse zusammengeführt. Das hält jeden Checker einzeln testbar und erlaubt, neue Signale hinzuzufügen, ohne bestehende Checks zu verändern, ein direktes Ergebnis des Single-Responsibility-Prinzips angewendet auf Fraud Detection.

<?php

declare(strict_types=1);

namespace Mironsoft\FraudPrevention\Api;

use Magento\Sales\Api\Data\OrderInterface;
use Mironsoft\FraudPrevention\Api\Data\RiskScoreResultInterface;

/**
 * Service Contract for order-level fraud risk scoring.
 */
interface RiskScoringInterface
{
    /**
     * Evaluate a placed order and return an aggregated risk score.
     *
     * @param OrderInterface $order
     * @return RiskScoreResultInterface
     */
    public function evaluate(OrderInterface $order): RiskScoreResultInterface;
}

<?php

declare(strict_types=1);

namespace Mironsoft\FraudPrevention\Model;

use Magento\Sales\Api\Data\OrderInterface;
use Mironsoft\FraudPrevention\Api\Data\RiskScoreResultInterface;
use Mironsoft\FraudPrevention\Api\Data\RiskScoreResultInterfaceFactory;
use Mironsoft\FraudPrevention\Api\RiskScoringInterface;
use Mironsoft\FraudPrevention\Model\Signal\SignalCheckerInterface;

/**
 * Aggregates individual fraud signal checkers into one weighted risk score.
 */
class RiskScoringService implements RiskScoringInterface
{
    /**
     * @param SignalCheckerInterface[] $signalCheckers Injected via di.xml as virtual type array
     * @param RiskScoreResultInterfaceFactory $resultFactory
     * @param int $holdThreshold Score at or above which an order should be held
     */
    public function __construct(
        private readonly array $signalCheckers,
        private readonly RiskScoreResultInterfaceFactory $resultFactory,
        private readonly int $holdThreshold = 60
    ) {
    }

    /**
     * Evaluate a placed order and return an aggregated risk score.
     *
     * @param OrderInterface $order
     * @return RiskScoreResultInterface
     */
    public function evaluate(OrderInterface $order): RiskScoreResultInterface
    {
        $totalScore = 0;
        $triggeredSignals = [];

        foreach ($this->signalCheckers as $checker) {
            $signalResult = $checker->check($order);
            if ($signalResult->isTriggered()) {
                $totalScore += $signalResult->getWeight();
                $triggeredSignals[] = $signalResult->getCode();
            }
        }

        /** @var RiskScoreResultInterface $result */
        $result = $this->resultFactory->create([
            'score' => $totalScore,
            'signals' => $triggeredSignals,
            'shouldHold' => $totalScore >= $this->holdThreshold,
        ]);

        return $result;
    }
}

4. Order Hold statt Blockieren: Plugin auf OrderManagementInterface

Ein harter Checkout-Abbruch bei jedem Verdachtssignal ist aus UX-Sicht schädlich: Legitime Kunden, deren Bestellung nur zufällig ein Signal auslöst, springen ab und der Umsatz geht verloren. Der bessere Weg ist, die Bestellung zunächst regulär entgegenzunehmen, sie aber in den Status Order::STATE_HOLDED zu versetzen, sodass sie im Fulfillment-Prozess pausiert und für eine manuelle Prüfung im Backend markiert wird. Der Kunde erhält seine Bestellbestätigung, die tatsächliche Auslieferung wartet auf Freigabe.

Technisch realisieren wir das über ein Plugin auf OrderManagementInterface::place statt über eine Preference, damit andere Module denselben Erweiterungspunkt weiterhin nutzen können. Der Plugin ruft nach dem eigentlichen Platzieren der Bestellung den RiskScoringInterface-Service auf und hält die Order, wenn der Score den konfigurierten Schwellenwert überschreitet. Wichtig: Der Hold passiert nach erfolgreichem Place, nicht davor, damit Zahlungsvorgang und Bestandsreservierung unangetastet bleiben und nur der Fulfillment-Workflow pausiert wird.

<?php

declare(strict_types=1);

namespace Mironsoft\FraudPrevention\Plugin;

use Magento\Sales\Api\Data\OrderInterface;
use Magento\Sales\Api\OrderManagementInterface;
use Magento\Sales\Api\OrderRepositoryInterface;
use Magento\Sales\Model\Order;
use Mironsoft\FraudPrevention\Api\RiskScoringInterface;
use Mironsoft\FraudPrevention\Model\FraudSignalLogRepositoryInterface;
use Psr\Log\LoggerInterface;

/**
 * Holds suspicious orders for manual review instead of blocking checkout outright.
 */
class HoldSuspiciousOrderPlugin
{
    /**
     * @param RiskScoringInterface $riskScoring
     * @param OrderRepositoryInterface $orderRepository
     * @param FraudSignalLogRepositoryInterface $fraudSignalLogRepository
     * @param LoggerInterface $logger
     */
    public function __construct(
        private readonly RiskScoringInterface $riskScoring,
        private readonly OrderRepositoryInterface $orderRepository,
        private readonly FraudSignalLogRepositoryInterface $fraudSignalLogRepository,
        private readonly LoggerInterface $logger
    ) {
    }

    /**
     * Score the order after placement and hold it when the risk score is too high.
     *
     * @param OrderManagementInterface $subject
     * @param OrderInterface $result
     * @return OrderInterface
     */
    public function afterPlace(OrderManagementInterface $subject, OrderInterface $result): OrderInterface
    {
        $scoreResult = $this->riskScoring->evaluate($result);
        $this->fraudSignalLogRepository->logScore((int) $result->getEntityId(), $scoreResult);

        if ($scoreResult->shouldHold() && $result instanceof Order) {
            $result->hold();
            $this->orderRepository->save($result);
            $this->logger->info(sprintf(
                'Order #%s held for fraud review, score %d, signals: %s',
                $result->getIncrementId(),
                $scoreResult->getScore(),
                implode(',', $scoreResult->getSignals())
            ));
        }

        return $result;
    }
}

5. Registrierung in di.xml und Prioritäten im Plugin-Chain

Die Registrierung des Plugins erfolgt klassisch in di.xml, gebunden an Magento\Sales\Api\OrderManagementInterface. Ein aussagekräftiger sortOrder ist hier relevant, weil in produktiven Shops häufig weitere Plugins auf derselben Methode arbeiten, etwa für Lagerreservierung oder E-Mail-Versand. Der Fraud-Check sollte nach diesen Kernprozessen laufen, damit ein Hold niemals mit der eigentlichen Bestellabwicklung kollidiert.

Zusätzlich binden wir die Signal-Checker als virtuellen Typ mit Array-Injection ein. Das erlaubt, neue Signal-Checker rein deklarativ über di.xml zu ergänzen, ohne die RiskScoringService-Klasse anzufassen, eine direkte Umsetzung des Open-Closed-Prinzips für Betrugserkennung-Regeln.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">

    <!-- Register the order hold plugin on the place() method -->
    <type name="Magento\Sales\Api\OrderManagementInterface">
        <plugin name="mironsoft_fraudprevention_hold_suspicious_order"
                type="Mironsoft\FraudPrevention\Plugin\HoldSuspiciousOrderPlugin"
                sortOrder="500"/>
    </type>

    <!-- Virtual type: array of individually injectable signal checkers -->
    <type name="Mironsoft\FraudPrevention\Model\RiskScoringService">
        <arguments>
            <argument name="signalCheckers" xsi:type="array">
                <item name="address_mismatch" xsi:type="object">Mironsoft\FraudPrevention\Model\Signal\AddressMismatchChecker</item>
                <item name="order_velocity" xsi:type="object">Mironsoft\FraudPrevention\Model\Signal\OrderVelocityChecker</item>
                <item name="high_value_guest" xsi:type="object">Mironsoft\FraudPrevention\Model\Signal\HighValueGuestChecker</item>
                <item name="bin_country_mismatch" xsi:type="object">Mironsoft\FraudPrevention\Model\Signal\BinCountryMismatchChecker</item>
                <item name="disposable_email" xsi:type="object">Mironsoft\FraudPrevention\Model\Signal\DisposableEmailChecker</item>
                <item name="failed_payment_attempts" xsi:type="object">Mironsoft\FraudPrevention\Model\Signal\FailedPaymentAttemptsChecker</item>
            </argument>
            <argument name="holdThreshold" xsi:type="number">60</argument>
        </arguments>
    </type>

    <preference for="Mironsoft\FraudPrevention\Api\RiskScoringInterface"
                type="Mironsoft\FraudPrevention\Model\RiskScoringService"/>
</config>

6. Audit-Trail: Fraud-Signal-Scores per db_schema.xml protokollieren

Ohne Protokollierung bleibt jede Fraud Prevention-Entscheidung eine Blackbox: Ein Support-Mitarbeiter, der eine gehaltene Bestellung freigeben soll, braucht nachvollziehbare Gründe, nicht nur einen Status. Deshalb legen wir eine eigene Entität an, die pro Order den berechneten Score, die ausgelösten Signale und den Zeitpunkt der Bewertung speichert. Diese Tabelle wird deklarativ über db_schema.xml definiert, keine Install-Skripte, keine manuellen SQL-Migrationen.

Der Audit-Trail dient zwei Zwecken: Er macht die Betrugserkennung für das Support-Team nachvollziehbar und liefert gleichzeitig die Datenbasis, um Schwellenwerte im Laufe der Zeit zu kalibrieren. Wer regelmäßig auswertet, wie viele gehaltene Bestellungen im Review tatsächlich als Betrug bestätigt wurden, kann den holdThreshold datenbasiert justieren, statt ihn nach Bauchgefühl zu verändern.

<?xml version="1.0"?>
<schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Setup/Declaration/Schema/etc/schema.xsd">

    <table name="mironsoft_fraud_signal_log" resource="default" engine="innodb"
           comment="Fraud signal score audit log per order">
        <column xsi:type="int" name="entity_id" padding="10" unsigned="true" nullable="false"
                identity="true" comment="Entity ID"/>
        <column xsi:type="int" name="order_id" padding="10" unsigned="true" nullable="false"
                comment="Sales Order ID"/>
        <column xsi:type="smallint" name="risk_score" unsigned="true" nullable="false" default="0"
                comment="Aggregated risk score"/>
        <column xsi:type="varchar" name="triggered_signals" nullable="true" length="512"
                comment="Comma-separated list of triggered signal codes"/>
        <column xsi:type="smallint" name="was_held" unsigned="true" nullable="false" default="0"
                comment="1 if the order was put on hold"/>
        <column xsi:type="timestamp" name="created_at" on_update="false" nullable="false"
                default="CURRENT_TIMESTAMP" comment="Evaluation timestamp"/>
        <constraint xsi:type="primary" referenceId="PRIMARY">
            <column name="entity_id"/>
        </constraint>
        <constraint xsi:type="foreign" referenceId="MIRONSOFT_FRAUD_SIGNAL_LOG_ORDER_ID_SALES_ORDER_ENTITY_ID"
                    table="mironsoft_fraud_signal_log" column="order_id"
                    referenceTable="sales_order" referenceColumn="entity_id" onDelete="CASCADE"/>
        <index referenceId="MIRONSOFT_FRAUD_SIGNAL_LOG_ORDER_ID" indexType="btree">
            <column name="order_id"/>
        </index>
    </table>
</schema>

7. Externe Fraud-Prevention-Dienste anbinden

Eigene Signal-Checker decken die naheliegenden Fälle ab, stoßen aber bei komplexeren Mustern an Grenzen, etwa Device-Fingerprinting über mehrere Shops hinweg oder globale Betrugsdatenbanken. Hier ergänzen spezialisierte Anbieter wie Signifyd, Riskified oder ClearSale die eigene Betrugserkennung sinnvoll. Das übliche Integrationsmuster: Nach dem Order-Place wird die Bestellung samt relevanter Metadaten an die API des Anbieters übertragen, der intern ein eigenes Machine-Learning-Modell auswertet.

Der entscheidende Architekturpunkt ist, dass die Antwort dieser Dienste in der Regel nicht synchron im Checkout-Request vorliegt. Anbieter wie Signifyd liefern eine erste Einschätzung oft innerhalb weniger Sekunden, eine finale Entscheidung aber teils erst nach mehreren Minuten, wenn zusätzliche Datenquellen ausgewertet wurden. Deshalb speichern wir zunächst eine vorläufige Order-Zuordnung über PaymentAdditionalInformation mit der externen Case-ID des Anbieters und warten auf den asynchronen Callback, statt den Checkout künstlich zu verzögern.

Diese Entkopplung ist zentral für gute UX: Der Kunde schließt den Checkout ganz normal ab, während im Hintergrund die externe Fraud Detection weiterläuft und das endgültige Ergebnis die Order erst später aktualisiert, entweder durch Freigabe oder durch zusätzlichen Hold zur manuellen Prüfung.

8. Webhook-Receiver für asynchrone Status-Callbacks

Der Webhook-Receiver ist ein regulärer Magento-Controller, der ausschließlich POST-Requests des externen Fraud-Dienstes entgegennimmt. Wichtig ist die Signaturprüfung: Jeder eingehende Callback muss anhand eines HMAC-Headers verifiziert werden, bevor die enthaltenen Daten die Order beeinflussen dürfen, sonst könnte ein Angreifer beliebige Bestellungen künstlich freigeben. Der Controller selbst enthält keine Scoring-Logik, er übersetzt lediglich die externe Antwort in einen internen Order-Status-Wechsel.

Nach erfolgreicher Signaturprüfung lädt der Controller die Order anhand der im Payload enthaltenen Case-ID, vergleicht den gemeldeten Status (etwa "approved", "declined" oder "under review") und aktualisiert Order-Status sowie den zuvor angelegten Fraud-Signal-Log-Eintrag entsprechend. Bei einer Ablehnung durch den externen Dienst bleibt die Order im Hold-Status und landet zusätzlich mit einer klaren Begründung in der Review-Queue des Support-Teams, statt automatisch storniert zu werden.

<?php

declare(strict_types=1);

namespace Mironsoft\FraudPrevention\Controller\Webhook;

use Magento\Framework\App\Action\HttpPostActionInterface;
use Magento\Framework\App\CsrfAwareActionInterface;
use Magento\Framework\App\RequestInterface;
use Magento\Framework\App\Request\InvalidRequestException;
use Magento\Framework\Controller\Result\JsonFactory;
use Magento\Framework\Controller\ResultInterface;
use Magento\Sales\Api\OrderRepositoryInterface;
use Mironsoft\FraudPrevention\Model\ExternalFraudCallbackValidatorInterface;
use Mironsoft\FraudPrevention\Model\FraudSignalLogRepositoryInterface;
use Psr\Log\LoggerInterface;

/**
 * Receives asynchronous fraud verdict callbacks from external providers (Signifyd, Riskified, ClearSale).
 */
class Callback implements HttpPostActionInterface, CsrfAwareActionInterface
{
    /**
     * @param RequestInterface $request
     * @param JsonFactory $resultJsonFactory
     * @param ExternalFraudCallbackValidatorInterface $callbackValidator
     * @param OrderRepositoryInterface $orderRepository
     * @param FraudSignalLogRepositoryInterface $fraudSignalLogRepository
     * @param LoggerInterface $logger
     */
    public function __construct(
        private readonly RequestInterface $request,
        private readonly JsonFactory $resultJsonFactory,
        private readonly ExternalFraudCallbackValidatorInterface $callbackValidator,
        private readonly OrderRepositoryInterface $orderRepository,
        private readonly FraudSignalLogRepositoryInterface $fraudSignalLogRepository,
        private readonly LoggerInterface $logger
    ) {
    }

    /**
     * Validate the incoming HMAC signature, load the referenced order and apply the verdict.
     *
     * @return ResultInterface
     */
    public function execute(): ResultInterface
    {
        $result = $this->resultJsonFactory->create();
        $rawBody = (string) $this->request->getContent();
        $signature = (string) $this->request->getHeader('X-Fraud-Signature');

        if (!$this->callbackValidator->isValid($rawBody, $signature)) {
            $this->logger->warning('Rejected fraud callback with invalid signature');
            return $result->setHttpResponseCode(401)->setData(['status' => 'invalid_signature']);
        }

        $payload = json_decode($rawBody, true);
        $order = $this->orderRepository->get((int) $payload['order_id']);
        $this->fraudSignalLogRepository->updateExternalVerdict(
            (int) $order->getEntityId(),
            (string) $payload['verdict'],
            (string) $payload['case_id']
        );

        return $result->setData(['status' => 'accepted']);
    }

    /**
     * Webhook endpoints are called server-to-server, CSRF validation is not applicable.
     *
     * @param RequestInterface $request
     * @return InvalidRequestException|null
     */
    public function createCsrfValidationException(RequestInterface $request): ?InvalidRequestException
    {
        return null;
    }

    /**
     * @param RequestInterface $request
     * @return bool
     */
    public function validateForCsrf(RequestInterface $request): ?bool
    {
        return true;
    }
}

9. False Positives vermeiden: Allow-Listing und Review-Queue

Die größte Gefahr jeder Betrugserkennung ist nicht der übersehene Betrugsfall, sondern der abgeschreckte legitime Kunde. Ein Stammkunde, der zum ersten Mal an eine abweichende Lieferadresse bestellt, etwa ein Geschenk an eine andere Person, sollte nicht automatisch denselben Score erhalten wie ein unbekannter Erstkäufer mit identischem Adress-Mismatch. Eine Allow-Liste für verifizierte, wiederkehrende Kunden reduziert das Gewicht einzelner Signale gezielt und verhindert, dass etablierte Kundenbeziehungen durch starre Regeln beschädigt werden.

Ebenso wichtig ist eine strukturierte Review-Queue im Backend statt einer reinen Statusanzeige: Gehaltene Bestellungen sollten mit den konkret ausgelösten Signalen, dem Score und einer Handlungsempfehlung angezeigt werden, damit das Support-Team in Sekunden statt Minuten entscheiden kann. Jede manuelle Entscheidung, ob eine gehaltene Order freigegeben oder storniert wird, sollte zurück in den Audit-Log fließen und langfristig als Trainingsgrundlage für die Kalibrierung der Gewichtungen dienen, ein Feedback-Loop, der die Treffgenauigkeit der Fraud Detection über die Zeit systematisch verbessert.

Zwei Metriken sollten dauerhaft überwacht werden: die False-Positive-Rate (freigegebene Bestellungen unter den gehaltenen) und die False-Negative-Rate (nachträglich bestätigte Betrugsfälle, die keinen Hold ausgelöst haben). Beide zusammen ergeben ein belastbares Bild, ob die aktuelle Konfiguration zu aggressiv oder zu nachlässig eingestellt ist.

Die folgende Tabelle stellt konkrete Signale ihrem typischen Risiko und der empfohlenen Reaktion gegenüber, als praktische Orientierung für die Kalibrierung eigener Schwellenwerte.

10. Zusammenfassung

Wirksame Betrugserkennung im Magento-2-Checkout entsteht nicht durch einen einzigen harten Filter, sondern durch das Zusammenspiel mehrerer sauber getrennter Bausteine: konkrete, messbare Fraud-Signale wie Adress-Mismatch, Bestell-Velocity, hochwertige Gast-Erstbestellungen, BIN-Länder-Abweichungen, Wegwerf-E-Mails und gehäufte Zahlungsfehlversuche; ein als Service Contract implementierter Risk-Scoring-Service mit Constructor Property Promotion; ein Plugin auf OrderManagementInterface::place, das verdächtige Bestellungen per Order::STATE_HOLDED für die manuelle Prüfung zurückhält statt den Checkout hart zu blockieren; ein per db_schema.xml deklariertes Audit-Log für Nachvollziehbarkeit und Kalibrierung.

Externe Fraud Prevention-Anbieter wie Signifyd, Riskified oder ClearSale ergänzen die eigene Logik dort, wo komplexere Mustererkennung nötig ist, über einen signaturgeprüften Webhook-Receiver mit asynchronem Status-Update. Der wichtigste Erfolgsfaktor über alle Bausteine hinweg ist die konsequente Vermeidung von False Positives durch Allow-Listing, eine strukturierte Review-Queue und einen Feedback-Loop, der die Gewichtung der Signale datenbasiert statt intuitiv nachjustiert.

11. FAQ: Betrugserkennung im Magento 2 Checkout