High-volume ERPNext merchants lose real margin to card fraud and chargebacks, and ERPNext core gives you nothing to fight it. Payment Entry and the Payment Gateway integrations record that a transaction happened, but there is no risk score, no velocity check, no BIN or geo rule, no blocklist, and no way to force a step-up challenge before authorization. When fraud slips through you find out weeks later as a chargeback, and by then the goods have shipped and the acquirer is debiting your account. Merchants end up bolting on spreadsheets, manual eyeballing of orders, or an expensive external fraud SaaS that has no idea what a Sales Order or Customer actually looks like in your system.

We build a proper Frappe app — a dedicated fraud-prevention module with its own DocTypes (Risk Assessment, Fraud Rule, Velocity Counter, Blocklist Entry, Chargeback Case, 3DS Session) that lives inside your bench and speaks native ERPNext. A configurable rules engine evaluates each incoming payment against velocity limits (transactions or amount per card, email, IP, or device over a rolling window), BIN and issuer-country checks, geo/IP mismatch, email and device blocklists, and amount thresholds. Each rule contributes to a weighted risk score, and the resulting Risk Assessment decides an action: approve, decline, or route to a manual review queue for an analyst. Device fingerprinting hooks capture a client-side signal on your web checkout and attach it to the assessment so the same device can be tracked across orders.

Technically it wires into ERPNext through hooks.py doc events (for example a before_submit/on_submit handler on Payment Entry and Sales Order) and whitelisted server-side methods exposed over the Frappe REST API, so your storefront or headless checkout can request a risk decision before it authorizes the charge. For payments that need a challenge, the 3-D Secure 2 orchestration layer initiates a step-up flow with the gateway (3DS2 authentication request, ACS challenge, and result verification), records the liability-shift outcome on the 3DS Session, and only lets the payment proceed on a successful authentication. Scheduler events (via scheduler_events) roll velocity counters, expire stale sessions, and reconcile chargeback webhooks; server scripts and client scripts handle tenant-specific logic; and role profiles plus permission rules keep the review queue and blocklist restricted to your fraud/finance team. The whole thing runs on Frappe/ERPNext v15 and v16.

Because this is build-to-order, nothing is auto-shipped. We start with a scoping call to map your gateways, checkout stack, chargeback history, and risk tolerance, then confirm scope in writing. From confirmed scope, typical delivery is 2–4 weeks: we build on a staging bench, run UAT with your team against real order patterns, tune rule weights and thresholds with you, then deploy to production with a rollback plan. You receive the full source, the git repository, documentation, and a post-go-live support window — you own the version we build for you.