| name | sfcc-fraud-prevention |
| description | Layered fraud prevention playbook for Salesforce B2C Commerce developers. Use this when adding fraud signals, designing a risk scoring approach, integrating third-party tools, or hardening checkout/login against bot-driven abuse. |
SFCC Fraud Prevention (Developer Playbook)
Fraud prevention in SFCC is a system, not a single feature. This skill focuses on practical developer responsibilities:
- Detectable signals you can implement
- Where to enforce checks
- How to store state safely
- How to avoid performance and quota pitfalls
Quick Checklist
[ ] Start at the edge: eCDN rules (block obvious bad traffic)
[ ] Enforce payment checks (AVS/CVV/3DS where available)
[ ] Add server-side validation (never trust the client)
[ ] Add velocity + behavior checks using minimal state
[ ] Ensure retention + purge jobs for any temporary state objects
[ ] Log decisions carefully (no PII leakage)
Threat Taxonomy (Why It Matters to Code)
Common families you’ll see in data:
- Card-not-present fraud
- Account takeover (credential stuffing)
- “Friendly fraud” / chargebacks
- Bot-driven attacks (card testing, inventory hoarding)
Your job is to translate these into signals you can observe and validate.
Actionable Signals (Implementation-Friendly)
| Signal type | Examples |
|---|
| Data mismatches | IP geolocation vs billing/shipping country; name/address anomalies |
| Velocity patterns | many attempts from same IP/email/device; repeated failures then success |
| Order characteristics | unusually large order; high-risk SKUs; rush shipping |
| Identity indicators | disposable email; gibberish names; repeated address reuse |
Layered Defense Architecture
1) Edge controls (before app servers)
- Use eCDN custom rules to block/limit known abusive traffic patterns.
- Rate-limit endpoints that are common bot targets (login, add-to-cart, checkout).
2) Platform + processor basics
- Enable/enforce payment gateway features like AVS and CVV checks.
- Prefer adding friction only when risk is elevated.
3) Server-side rules and scoring
Where to implement depends on architecture:
- SFRA: controller middleware + fraud detection script points
- Headless: keep hook logic minimal; consider custom endpoints for heavier checks
A practical approach:
- Compute a numeric risk score from signals (0–100)
- Block above a threshold; challenge (CAPTCHA/step-up) in mid-range; allow below threshold
State Storage (Don’t Create a Quota Time Bomb)
If you store historical signals:
- Use a minimal schema (counts + timestamps), not raw event logs
- Define retention policy and a purge job from day one
If you must store per-session state:
- Prefer session privacy storage for small values
Logging & Observability
- Log risk decisions with correlation IDs and redacted values
- Avoid writing PII into shared logs
See also: sfcc-logging and sfcc-security.
When to Buy Instead of Build
Third-party fraud tools can be the correct choice when:
- You need global intelligence across merchants
- You need chargeback guarantees
- You are being hit by sophisticated bot abuse
Build custom logic when:
- You need business-specific heuristics
- You have clear signals + small scope
- You can commit to continuous tuning (false positives are costly)
References
- Rhino Inquisitor: A Developer’s Guide to Combating Fraud on SFCC
- Salesforce: Bot management guidance (high-level responsibility model)
