Fraud Detection
Same as the admin Fraud Detection page — this entry covers the front-end / runtime side of fraud rule enforcement.

For the admin page reference (live signals, rules, flagged users tabs), see Admin → Fraud Detection.
How rules execute
Every bid is run through every enabled rule before it's accepted.
Bid attempt
↓
Run each enabled rule:
├── bid_rate_limit
├── ip_velocity
├── account_age
├── chargeback_history
├── email_verification
├── ssl_required
├── 2fa_required (if applicable)
├── captcha (if threshold tripped)
└── custom rules (via wkafw_fraud_rules filter)
↓
Aggregate severity:
├── No matches → bid proceeds
├── Soft match (severity = low) → bid proceeds, logged
├── Hard match (severity = high) → bid rejected
└── Auto-block triggered → user added to Blocked Users
Severity levels
| Severity | Default action |
|---|---|
info | Log only — for analytics |
low | Allow + flag the user (admin reviews later) |
medium | Show CAPTCHA, then allow |
high | Reject the bid |
critical | Reject + auto-block the user |
Configurable per rule.
Built-in rules
Bid rate limit
| Setting | Default |
|---|---|
wkafw_bid_rate_limit | 10 (per minute per user) |
| Severity at threshold | medium (CAPTCHA) |
| Severity at 2× threshold | high (reject) |
| Severity at 5× threshold | critical (auto-block) |
IP velocity
| Setting | Default |
|---|---|
| Distinct users / hour from same IP | 5 |
| IP block list | (empty) |
| IP allow list | (empty) |
The plugin also auto-tracks repeated failed bids from same IP to identify scraping / scanning behavior.
Account age
| Setting | Default |
|---|---|
| Min account age for bidding | 0 hrs |
| Min account age for high-value bids | 24 hrs |
| High-value threshold | 1000 |
Newly-created accounts (< the threshold) are restricted from bidding above the high-value amount.
Chargeback history
| Setting | Default |
|---|---|
| Block after N chargebacks | 1 |
| Memory window | 365 days |
Reads chargeback events from WC orders meta. Severity: critical (immediate block).
Email verification
| Setting | Default |
|---|---|
wkafw_require_email_verify | no |
If yes, users without verified email cannot bid. Verification flow:
- User signs up
- Plugin sends verification email
- User clicks link → email verified
- Bidding unlocked
SSL required
| Setting | Default |
|---|---|
wkafw_require_ssl | no |
If yes, bids over HTTP are rejected. The plugin shows an admin notice if your site isn't HTTPS but this is enabled.
Soft-fail vs hard-fail UX
| Outcome | UI shown |
|---|---|
| Soft-fail (logged) | Bid succeeds; admin sees a flag in Live Signals |
| Hard-fail (rejected) | Generic error: "Cannot place bid — please try again" (never reveals which rule fired) |
| User blocked | "Account suspended. Contact support." |
| CAPTCHA challenge | CAPTCHA modal; on success bid proceeds |
Reasons are deliberately vague to avoid leaking rule logic to attackers.
IP utilities
The plugin includes helpers:
Compliance / legal
Fraud rules contain user-identifying data:
- Logged events stored encrypted at rest if your DB supports it
- Retention: configurable (default 365 days)
- GDPR exporter includes flag history
- Auto-block decisions logged to Audit Log for due-process review
Performance
Each rule adds 1–5 ms to bid validation:
- Most rules are simple SQL lookups (cached)
- IP geolocation only runs once per session, cached
- CAPTCHA verification adds ~50 ms (provider call)
For high-throughput sites, prefer a smaller rule set with high precision over many rules with low precision.
Reporting
Reports → Fraud tracks:
- Daily flag count by rule
- Rule precision (cleared / total flags)
- Auto-block rate
- Top flagged users
- IP heatmap
Use this to tune thresholds.
