Use Case: Checkout & Payment Fraud
Using email risk as one signal in a checkout or payment flow — not a replacement for dedicated payment fraud tooling.
Recommended configuration
| Setting | Recommendation |
|---|---|
| context | "payment" — applies no signal-weight adjustment (the generic weighting already reflects the base risk model), but sets a clear semantic intent in your logs and analytics |
| mode | "full" is worth the latency here — a checkout flow already has some inherent latency tolerance, and SMTP confirmation is the strongest deliverability signal available |
| Pattern | Blocking, since a fraudulent checkout is expensive to unwind after the fact |
This is one signal, not a fraud system
Email risk scoring evaluates the address, not the transaction, the card, the shipping details, or the device. It's meant to sit alongside dedicated payment fraud tooling (card verification, AVS/CVV checks, device fingerprinting) as one additional input — a low-risk email doesn't clear a transaction on its own, and a medium-risk email shouldn't necessarily block one either. Weight it according to how much your specific fraud model already covers.
What to combine it with
- Payment processor risk scores (card network data, velocity checks) — usually a stronger direct fraud signal than email alone
- Billing/shipping address mismatch detection
- Account age and order history, if the customer has an existing account