How explainable fraud scoring actually works

Most fraud tools hand you a number between 0 and 100 and expect you to act on it. WooFraudGuard hands you the number and the reasons. Here is why that difference matters more than the number itself.

The problem with a black box

A machine-learning fraud model can be genuinely good at spotting fraud, and still be a bad fit for a small store. When it flags an order, you get a probability and nothing else. You cannot tell whether the order was flagged because the billing country and IP disagree, or because the customer used a prepaid card, or because the model has quietly learned that everyone from a particular postcode is suspicious.

That matters for three practical reasons. You cannot tune what you cannot see. You cannot explain a rejection to a customer who emails to ask why. And you cannot defend the decision to a payment provider, or to a regulator, if you are ever asked to.

Rules, weights, and a running total

WooFraudGuard scores each order by running a set of independent rules over it. Each rule looks at one thing, returns a verdict, and contributes a weighted number of points to the order’s total. The score is simply the sum, and every point in it is traceable to the rule that added it.

The rules cover the signals that actually correlate with chargebacks on a WooCommerce store: mismatches between billing and shipping addresses, the risk profile of the originating IP, disposable and suspicious email domains, unusual order velocity from one customer or one card, and the behavioural signals covered in our post on behavioural biometrics.

Because each rule is separate, each rule’s weight is yours to change. If address mismatches are normal for your store because you sell a lot of gifts, turn that weight down. If you have been burned by a particular pattern, turn it up. The scoring engine does not need retraining — it just adds up different numbers.

What the score actually does

A score on its own does nothing. Three thresholds decide what happens next:

• Review — the order is flagged for a human to look at. Checkout completes normally and the shopper sees nothing; you just get told about it.
• Hold — the order is created and set to on-hold, payment is not taken, and checkout stops with a message asking the shopper to wait for verification. You release it by moving the order to Processing.
• Cancel — the order is created and immediately cancelled, and the shopper is refused at checkout. Because the order still exists you can inspect it afterwards, or restore it if it was a false positive.

All three thresholds are yours to set, and the right values depend on your margins and your appetite for false positives. A store selling €15 accessories should tolerate far more risk than one shipping €2,000 laptops. Start permissive, watch what gets flagged for a few weeks, and tighten from evidence rather than from a default.

Reading a flagged order

Every scored order carries its full breakdown: which rules fired, what each one contributed, and what the rule saw. A flagged order reads like an explanation rather than a verdict — “billing and shipping countries differ”, “third order from this device in an hour” — so deciding whether to ship takes a few seconds of reading rather than a guess.

This is also what makes the tool safe to hand to someone who is not a fraud analyst. A member of your support team can look at a flagged order and reach a sensible decision, because the reasoning is in front of them.

Closing the loop

Scoring is only half the job. When a dispute is eventually raised, your gateway’s webhook records it against the order that caused it, adds a note to that order, and adds the buyer’s email and device to your blocklist. Nothing learns from that — no weight moves on its own — but the next order linked to that buyer starts from a far worse position, and you are left with a written record of exactly which rules fired on an order that really did go bad.

That is the honest version of a feedback loop, and the tuning stays yours. Rules that never fire on a real chargeback are candidates for a lower weight; rules that keep appearing on disputed orders deserve more. What the plugin owes you is the evidence to make that call, and its working shown every time.

Where to start

If you are setting this up for the first time, run in review-only mode for a couple of weeks before you let it cancel anything. You will learn more from watching what gets flagged on real orders than from any default configuration — and you will avoid the classic mistake of tuning thresholds on a staging site where every order comes from a loopback IP.