How to implement a fraud prevention API: integration guide for developers

The Office for National Statistics recorded 4.2 million fraud incidents in England and Wales in the year ending March 2025, a 31% increase on the previous year and the highest count since tracking began in 2017. The UK Home Office put the economic cost of that wave at £14.4 billion in the preceding year. When fraud is running at that volume, manual review is not a viable architecture. Every application that processes payments, onboards users, or grants access to financial services needs detection logic inside the code itself. This guide walks through what a fraud prevention API does, how to integrate one from sandbox to production, and how to choose between a full API and an SDK.

A fraud prevention API is a Representational State Transfer (REST) endpoint that accepts user, device, and transaction data, runs it through a real-time detection model, and returns a risk score with a recommended decision. Engineering teams embed it directly into onboarding and payment flows without building their own machine learning (ML) infrastructure.

What is a fraud prevention API?

Fraud prevention APIs have moved from back-office tooling to front-line infrastructure over the past two years. The reason is pace. The Association of Certified Fraud Examiners (ACFE) Top Fraud Trends 2025 report identifies generative AI as the primary driver of new fraud schemes, including phishing, business email compromise, account takeover, and impersonation attacks. A detection system operating on yesterday’s batch data cannot match that pace. Real-time scoring at the API layer is the architectural response.

These APIs typically plug into account creation, login, and payment initiation flows. Account creation surfaces synthetic identity patterns and document tampering signals. Login exposes device fingerprinting anomalies and behavioural shifts. Payment initiation brings velocity checks and transaction pattern scoring into play. A detailed breakdown of fraud types and the strategies used to address them is available in this fraud prevention strategies guide.

How does a fraud prevention API work?

A fraud prevention API evaluates each request by assembling signals across three categories and running them through a scoring model. The score is not binary. It sits on a continuous scale, and the API returns both the number and a recommended action based on configurable thresholds. Understanding how those signals combine is what lets you tune the integration to your risk appetite.

Identity signals cover the data the user submits, including name, date of birth, address, email, and document details. The API cross-references these against known-fraud databases, checks for synthetic identity markers, and scores document authenticity when document verification is active.

Device signals include IP address, device fingerprint, browser characteristics, and geolocation. The model looks for device-sharing patterns, Virtual Private Network (VPN) and proxy use, impossible-travel sequences, and device attributes associated with previous fraud events.

Behavioural signals capture how the user moves through your interface, including typing speed, mouse patterns, session duration, and navigation flow. Anomalies against the baseline for that user segment contribute to the overall score.

The API receives your POST request, runs all active signal checks in parallel, and returns a JavaScript Object Notation (JSON) response in under a second on most configurations. The response includes the numeric risk score, a decision field, and a breakdown of which signals contributed most to the score.

How do you integrate a fraud prevention API from sandbox to production?

Integration follows three phases. Authentication setup comes first, then request construction, and finally go-live validation. Each phase has a failure mode when steps are skipped. The order matters because problems in the authentication phase create compounding debugging problems in later phases, and a misconfigured request payload in the sandbox produces unreliable signal data in production.

Setting up authentication

Most fraud prevention APIs use OAuth 2.0 with client credentials. Your backend registers in the developer console, receives a client ID and secret, and exchanges those credentials for a bearer token via a POST to the token endpoint. That token goes in the Authorization header on every subsequent API call. Tokens typically expire after 15 to 20 minutes, so your implementation needs to check expiry and refresh proactively rather than waiting for a 401 response to trigger re-authentication. Expired tokens mid-session are the most common integration bug in early deployments. For a broader look at how API-based identity checks handle the same token lifecycle, the KYC API integration guide walks through the onboarding context in detail.

Structuring your first API request

The request body is a JSON object that includes the user data you want scored and the signal modules you want active. A minimal account-creation request sends identity fields and device context. Payment-flow requests add transaction data and velocity parameters. Start with the minimum viable payload in the sandbox, confirm the response shape, then add signal modules incrementally. Layering everything in at once makes debugging harder when a field is missing or misformatted. The sandbox environment runs the same scoring logic as production, so a clean sandbox test is a reliable indicator of integration behaviour under production load.

Moving from sandbox to production

Before promoting to production, run test cases across three scenarios. Clean users should score low, known fraud patterns should score high, and edge cases like users with thin identity histories reveal how the model handles sparse data. Most providers supply a test dataset for this. Confirm that your webhook listener or synchronous response handler logs full payloads rather than just the decision field. The signal breakdown is where post-launch tuning happens. Set your initial risk thresholds conservatively. Loosening a threshold that generates too many false positives is easier than explaining a fraud loss caused by one that was too permissive from day one.

What is the difference between a fraud prevention SDK and an API?

The SDK-vs.-API question comes up early in every fraud integration project, and the right answer depends on your stack and your timeline. A fraud prevention SDK is a pre-built library that bundles the API call with front-end capture components, including the document scanner, liveness check module, and device fingerprinting logic. You add the SDK to your mobile or web application and it handles data collection and transmission. A direct API integration provides the same detection capability but requires you to build or supply your own capture layer.

SDKs suit mobile-first products. If your primary onboarding surface is a native iOS or Android app, an SDK handles camera permissions, document framing, and biometric capture logic you would otherwise write from scratch. The trade-off is less control over the user experience and a dependency on the SDK release cycle for model updates.

APIs suit teams that already have a capture layer, or that need fraud checks as a backend service with no front-end component. A backend-only transaction scoring call or a payment screening check is cleaner through a direct API. APIs also work better when you need to score signals the SDK does not expose, or when the SDK update cadence is too slow for your deployment schedule.

How Shufti helps developers detect fraud at the integration layer

Fraud signals shift faster than annual SDK release cycles, and the gap between your detection model and current attack patterns is where losses accumulate. Shufti’s fraud prevention solution runs through a single REST API that covers identity, document, behavioural, and device signals in one call. The same endpoint handles synchronous responses and webhooks, so the integration pattern fits both real-time onboarding decisions and asynchronous payment review queues. Shufti’s fraud detection accuracy data shows a 99.3% true detection rate on confirmed fraud attempts, drawn from 280 million identity checks processed annually across 230 countries and territories. Developers can start in a full sandbox environment with realistic test datasets, validate the response shape against their own workflows, and promote to production without switching endpoints. Shufti’s User Risk Assessment builds persistent risk profiles that carry scoring context across sessions, which cuts false positives on returning users without reducing detection sensitivity on new ones. Both capabilities run on the same API key and base URL, so extending scope does not require a separate integration.

Fraud that runs at machine speed needs detection built to match it, and constructing that infrastructure from scratch is not a realistic use of engineering time. Shufti’s fraud detection API gives development teams a single integration point covering identity, behavioural, and device signals, with sandbox access available immediately.

Request a demo to test the API against your own use case and see the scoring output on real transaction patterns.