How to Integrate Digital Fraud Prevention

This guide explains how to connect DFP to your website: add the JavaScript script to your pages, configure DFP response decryption on the backend, and add DFP to your business logic.

1. Choose the Domain Your Website Will Use to Call the DFP API

During the integration, you add the script to the required pages of your website. This script sends requests to the DFP API. It can call the API through:

  • The standard address https://fp.strictera.com/fp/. It works by default; no configuration is required.

  • Your subdomain. In this case, we allocate an IP address for you, and you configure an A record for your subdomain to point to that IP address.

If you want to use your own subdomain, let us know. Otherwise, proceed to step 2.

The examples below use the standard API address: https://fp.strictera.com/fp/.

2. Get a Token and Secret Key

We will provide two values:

  • CUSTOMER-TOKEN: a token for loading the JavaScript library and calling the API;

  • SECRET-KEY: a secret key, provided in Hex format, that your backend uses to decrypt the payload.

Store SECRET-KEY only on the backend. Do not add it to page code or send it to the user’s browser.

3. Add the Script to Your Website

Add the DFP JavaScript library to the pages where you want to check the client environment and signals of bot activity:

<script src="https://fp.strictera.com/fp/v1/<CUSTOMER-TOKEN>/fp.js"></script>

After the script loads, the StricteraFP class becomes available on the page. You use it to call DFP from page code.

If you need to understand how the script works, contact technical support and we will explain it in detail.

The script is obfuscated using anti-LLM techniques, so answers from AI tools during reverse engineering may be inaccurate or misleading. In addition, uploading the script to ChatGPT, Claude, Grok, or another AI service may result in your account being blocked by that service.

4. Create a StricteraFP Instance

In steps 4–11, you configure the client-side code: create a StricteraFP instance, set options, start data collection, pass additional parameters, receive the DFP result, and send it to the backend.

Example of complete client-side code:

const fp = new StricteraFP(
  "https://fp.strictera.com/fp/",
  "<CUSTOMER-TOKEN>",
  { prework: true, maxRetries: 3 }
);
await fp.initSP();
await fp.run();
const dfpOptions = { customData: JSON.stringify({ event: "login_attempt" }) };
const result = await fp.get(dfpOptions);
await fetch("/api/dfp/check", {
  method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(result)
});

Create a StricteraFP object and pass the DFP API address and your token to it:

const fp = new StricteraFP(
  "https://fp.strictera.com/fp/",
  "<CUSTOMER-TOKEN>"
);

If you use your own subdomain, specify it instead of the standard address:

const fp = new StricteraFP(
  "https://fp-check.example.com/fp/",
  "<CUSTOMER-TOKEN>"
);

5. Optionally Configure Library Behavior

The minimum recommendation is to enable prework. DFP works faster with it, and the option has no drawbacks.

When creating StricteraFP, you can pass a third argument: an options object. These options control how the library collects data and what it does if an API request fails.

const fp = new StricteraFP(
  "https://fp.strictera.com/fp/",
  "<CUSTOMER-TOKEN>",
  { prework: true, maxRetries: 3, fullScan: false }
);

Three options are available:

Option What it does

prework

Starts some data-collection methods in advance, while StricteraFP is initialized. When you call get(), the library has less work to do because some operations have already been completed. As a result, DFP works faster.

maxRetries

Sets how many times an API request may be retried if the first attempt fails.

fullScan

Enables additional data-collection methods. For example:

  • reliable detection that the user has opened the current browser tab;

  • additional checks for detecting popular automation tools.

You can request the full list of methods from our engineers. These methods can make the analysis more accurate but significantly slow down the script. They are disabled by default. If you want to enable them, agree on this with our engineers.

6. Add Library Initialization

Add the initSP() call so the library receives configuration from the Strictera server:

await fp.initSP();

If you do not call initSP() explicitly, the library initializes when get() is called. A separate call makes the integration more predictable because you know when the library is ready.

7. Add Data Collection

Add the run() call so the script collects client environment parameters:

await fp.run();

If you do not call run() explicitly, collection happens inside get().

Start collecting client environment data as early as possible, for example when the page opens. Send it to the DFP API at the moment of the target action, such as signing in, submitting a form, or confirming an operation. This gives you a faster DFP response and improves its accuracy. You configure sending data in step 10.

8. Optionally Pass Additional Context Through customData

Pass additional DFP request parameters in the dfpOptions object. You pass this object to the get() method later.

customData is an arbitrary string containing your data. DFP returns it unchanged in the payload as custom_data.

The customData string must not exceed 4,096 characters.

This string is not used to create fingerprints. It is only for your own service needs, so that you can configure business logic more easily. For example, you can pass an event type, form ID, scenario source, or any other context. This helps the backend understand which action the DFP result belongs to.

For example, the same user may open a sign-in page, submit a form, confirm a payment, or change a password. With customData, you link the DFP result to a specific event in your system.

const dfpOptions = {
  customData: JSON.stringify({ event: "login_attempt", form_id: "main_login" })
};

Do not pass passwords, payment data, authentication tokens, or other secrets in customData.

9. Optionally Pass customID

Use this field only after agreeing on it with our engineers.

customID is a persistent identifier of a user, account, or another object in your system. It lets you link this object to its user_id on the Strictera side.

customID must not exceed 128 characters.

How Strictera uses this link depends on your scenario. Agree with our engineers on customID processing, rules to implement on the Strictera side, and how the result appears in the DFP response. This configuration is customized for each client.

const dfpOptions = {
  customData: JSON.stringify({ event: "login_attempt" }),
  customID: "account_12345"
};

10. Send Collected Data to DFP and Get the Result

To get a DFP result, add one of two get() calls.

If you created dfpOptions in the previous steps, pass it to the method:

const result = await fp.get(dfpOptions);

If you do not pass customData or customID, call the method without arguments:

const result = await fp.get();

The method sends the collected data to Strictera and returns a response with an encrypted payload.

11. Send the DFP Response to Your Backend

Send the DFP response to your backend. Payload decryption, result verification, and decision-making must take place there.

await fetch("/api/dfp/check", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(result)
});

12. Decrypt the Payload on the Backend

To decrypt it:

  1. Decode SECRET-KEY from Hex into binary data.

  2. Decode iv, payload, and tag from Base64 into binary data.

  3. Decrypt payload with AES-256-GCM, using SECRET-KEY, iv, and tag.

  4. Interpret the decryption result as JSON.

Example of decryption in Node.js:

import * as crypto from "crypto";
const secretKey = Buffer.from("<SECRET-KEY>", "hex");
const iv = Buffer.from(input.iv, "base64");
const payload = Buffer.from(input.payload, "base64");
const tag = Buffer.from(input.tag, "base64");
const decipher = crypto.createDecipheriv("aes-256-gcm", secretKey, iv);
decipher.setAuthTag(tag);
const decrypted = Buffer.concat([decipher.update(payload), decipher.final()]);
const result = JSON.parse(decrypted.toString("utf8"));

For an example of a decrypted payload and a description of every field, see What DFP Response Fields Mean.

If you receive success: false, save request_id and send it to technical support.

13. Check Result Freshness

Your backend must compare timestamp with the current UTC time.

Do not accept responses that are more than a few seconds old. This protects your resource from replay attacks, where an attacker tries to pass an old DFP result as a new one.

If timestamp is fresh, processing can continue.

14. Process the Data in Your Business Logic

Use user_id, bot_score, incognito, vpn, hosting, bot_hosting, isp_active_subnet, engine, os, mobile, new_user, confidence_score, and custom_data in your service rules. For example, you can use them to check account sign-ins.

One possible rule detects suspicious sign-in attempts using user_id and bot_score. Your backend:

  1. receives user_id from the decrypted payload;

  2. checks whether this user_id is linked to the user’s account in your database;

  3. follows the normal sign-in flow if the link exists and bot_score is low;

  4. requests additional sign-in confirmation if user_id is new and bot_score is medium or high;

  5. stores user_id, the result of the additional check, and its link to the account for future sign-in attempts.

We have prepared guides for specific business scenarios:

15. Test the Integration

After configuration, test the integration on your resource:

  1. Open a page where the DFP script is connected.

  2. Perform the action for which you configured a check, for example sign in, submit a form, or confirm an operation.

  3. Make sure the browser received the DFP result and sent it to the backend.

  4. Make sure the backend decrypted the payload, checked timestamp, processed other response fields, and applied your rules.