FP FINGERPRINT

Fraud detection guide

Use fingerprint.dev as a durable signal in your fraud system. It helps connect repeated attempts when a visitor changes account details, email addresses, IPs, or browser state.

  1. Call /identify before risky actions such as signup, login, checkout, payout, password reset, or promo redemption.
  2. Store visitor_id, confidence, request context, and your own event ID.
  3. Query your risk history for previous events tied to the same visitor_id.
  4. Use the match and confidence as one input in your existing risk decision.
  5. Step up, queue review, or block according to your own policy.

Browser integration

import { identify } from "fingerprint.dev";

let result = await identify({
  apiKey: "fp_live_...",
});

await fetch("/risk/events", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({
    visitor_id: result.visitor_id,
    confidence: result.confidence,
    action: "checkout",
    cart_total: 12900,
  }),
});

If visitor_id is null, continue with your existing risk checks. A missing visitor ID should not cause an allow or deny decision on its own.

Server decision shape

let priorEvents = await riskStore.findByVisitorId(result.visitor_id);

let riskScore = scoreCheckout({
  accountId,
  cartTotal,
  visitorId: result.visitor_id,
  confidence: result.confidence,
  priorEvents,
});

if (riskScore >= 80) {
  return queueManualReview();
}

if (riskScore >= 50) {
  return requireStepUp();
}

return approveCheckout();

Keep fingerprint.dev out of the final authority path. Your account, payment, abuse, and review systems should make the final decision.

Useful joins

  • visitor_id to previous chargebacks or refund abuse.
  • visitor_id to many new accounts in a short window.
  • visitor_id to repeated failed logins or password resets.
  • visitor_id to promo-code or trial abuse.