Imagine: You just launched a limited-time flash sale, and orders are rolling in fast — but so are a bunch of fraudulent ones. Chargebacks start to add up, and your fraud team is left struggling to sort genuine purchases from suspicious activity. It’s frustrating, time-consuming, and a reminder that fraudsters never miss an opportunity.
The good news is you don’t have to let them win. This guide provides a step-by-step playbook for outsmarting fraudsters using Fingerprint device intelligence. Whether you’re new to the payment fraud battle or boosting your existing defenses, Fingerprint is your secret weapon to not just spot fraud, but also shut it down before it happens.
We’ll explore common forms of payment fraud, help you map out your Fingerprint implementation plan, and walk you through technical steps for tackling real-world fraud scenarios. Suspicious purchases? Covered. Sketchy account activity? Thwarted. Bots trying to exploit your checkout? Blocked. Fraud might be relentless, but with this guide, you’ll be ready to give it the fight it deserves.
Common forms of payment fraud
Payment fraud comes in all shapes and sizes, and fraudsters are always looking for new ways to cause trouble. Knowing their tricks is the first step to spotting weak spots in your payment processes and putting the right tools in place to catch suspicious activity. Before we dive into how Fingerprint’s device intelligence can help you fight back, let’s break down some of the most common types of payment fraud that it can address:
Credit card testing & cracking
Using automated tools or bots, fraudsters test stolen or fabricated credit card details with small, low-value transactions to see if the card is valid. Once they hit the jackpot, the card is used for bigger fraudulent purchases or gets sold on the dark web to other criminals.
Chargeback fraud
One form of chargeback fraud is known as "friendly fraud," when customers dispute legitimate charges with their bank, claiming they didn’t authorize the purchase. The other type of chargeback fraud is when a bad actor uses stolen credit card details to make a purchase, and the legitimate cardholder (rightfully) disputes the transaction. Both scenarios result in lost revenue, in addition to the cost of the goods or services purchased. Even worse, too many chargebacks can damage your reputation with payment processing providers and increase your payment processing fees.
New account fraud
Fraudsters create fake accounts using stolen identities, fabricated information, or bots to exploit offers meant for legitimate users. These accounts are often used to claim referral bonuses, abuse free trials, or stack loyalty rewards. This behavior drains your revenue and undermines the purpose of your marketing campaigns, reducing their value for real customers.
Promo abuse
Even without creating new accounts, fraudsters can hide their identity to claim discounts or use coupon codes repeatedly. They may use bots or other tactics to bypass restrictions, exploiting promotions and exclusive offers meant to be used once. This type of abuse also impacts your bottom line and diminishes the effectiveness of your promotions.
Account takeover
While more commonly associated with account fraud, account takeover can also target payment systems. Once inside, fraudsters use stored payment methods to make unauthorized purchases, leaving your customers frustrated and your business on the hook.
Introduction to Fingerprint
Fingerprint is a device intelligence platform that identifies online devices visiting your site or mobile app, delivering real-time insights into their behavior. By analyzing browser and device attributes, Fingerprint generates a unique visitor identifier for each browser or device, maintaining consistent recognition even if cookies are cleared or device details change. Fingerprint Smart Signals offer additional insights into suspicious activities, such as VPN usage, browser tampering, or bot behavior.
With Fingerprint’s highly accurate device intelligence, businesses can reliably recognize returning users and suspicious characteristics. This enables companies to spot irregularities tied to fraudulent transactions, such as bot activity, new account fraud, or friendly fraud. By catching these tactics early, businesses can detect and block fraudulent transactions, protect their revenue, and maintain customer trust.
How Fingerprint tackles payment fraud
Getting a clearer picture of the devices interacting with your platform is key to fighting payment fraud. Let’s take a closer look at how Fingerprint’s device intelligence can help you protect your payments and keep fraudsters out.
Detecting bots
Fraudsters often deploy bots to automate their schemes, from testing stolen credit cards to exploiting promotions. Fingerprint Smart Signals include real-time bot detection, allowing you to identify when automated tools are at work. For example, bots used for card testing typically run rapid, low-value transactions to validate stolen details. With Fingerprint, you can detect and block this activity as it happens, preventing automated fraud across your platform.
Linking anonymous transactions
Anonymous guest transactions make it easy for customers to complete purchases quickly, but they also create opportunities for fraudsters to operate anonymously. Fingerprint’s highly accurate visitor IDs allow you to link guest transactions back to the browser or device that initiated them. This means you can detect patterns such as the same device making multiple purchases in a short period or other unusual payment behaviors. By identifying these trends, you can flag repeat offenders, recognize abusive activity, and block even anonymous fraudsters.
Winning chargeback disputes
Chargebacks are costly, frustrating, and can take time to resolve. Fingerprint’s highly accurate visitor identifiers allow you to link transactions to the specific browser or device used to make them, creating a clear audit trail. By comparing the device involved in a disputed transaction to those from past legitimate purchases, you can provide concrete evidence to challenge false claims and recover lost revenue. Visa and Mastercard even list device identification as a recommended data point in their chargeback resolution guides.
Stopping new account fraud
Fraudsters often try to game the system by creating fake accounts to claim signup bonuses, referral rewards, and other perks meant for genuine new customers. With Fingerprint’s highly accurate visitor identifiers, you can link multiple accounts back to the same device, even if the fraudster clears cookies or uses a VPN to appear like a new user. This makes it possible to detect multiple account creations from a single device, flag suspicious activity, and block these scams.
Protecting promotions
Promotions are great for driving customer engagement, but they’re also a magnet for fraudsters looking to exploit your offers. Fraudsters might use bots to grab exclusive deals or repeatedly claim the same discount codes, costing your business revenue and limiting availability for legitimate customers. Fingerprint’s device intelligence helps identify when the same browser or device is being used to abuse promotions, allowing you to block fraudsters.
Preventing account takeovers
Stored payment methods are a convenient feature for customers, but they also can make accounts a prime target for fraudsters. In account takeover attacks, fraudsters gain access to a customer’s account. From there, they can exploit stored payment details to make unauthorized purchases. Fingerprint’s highly accurate visitor IDs help you detect suspicious activity, such as logins from unfamiliar devices or unusual browser characteristics. By identifying these differences in real time, you can block unauthorized transactions and protect accounts.
Planning your implementation
Fingerprint integrates easily into your existing setup, with visitor identification and device signals accessible through APIs and libraries for popular frameworks and languages. This flexibility allows you to tailor Fingerprint to address your specific payment fraud challenges.
Since every app and site has unique needs, it’s essential to define the problem you’re solving before diving into implementation. Fingerprint provides the data, but how you use it depends on your goals. Start by observing your users — what behaviors seem typical, and what stands out as unusual? Next, evaluate your platform for potential target areas like guest checkouts, promotion redemption, or high chargeback rates.
If you don’t have the data you need yet, you can start by passively collecting visitor information with Fingerprint. Simply install the client agent, and the Fingerprint dashboard will display data to help you spot trends and patterns. These insights can guide you in refining your fraud prevention strategy before fully integrating Fingerprint into your processes. Additionally, Fingerprint’s Suspect Score highlights globally unusual behavior, making it easier to identify risky visitors without too much setup.
A little planning upfront ensures that Fingerprint works seamlessly with your platform and delivers the results you need. Here are some topics to consider to create a solid implementation plan that aligns with your goals and makes the most of Fingerprint.
Determine how to use Fingerprint
To stop payment fraud, you first need to figure out which parts of your site are most at risk. We recommend focusing on pages like your checkout, payment forms, and promo sign-ups since these are the places fraudsters love to target.
Next, decide how often you’ll use Fingerprint to check for suspicious activity. If you’re dealing with a lot of guest checkouts or high-value purchases, you might want to check every transaction in real time. For lower-risk sites, it could make sense to only check during high-value purchases. Each identification API call counts toward your monthly quota, so use them where they matter most.
Ask yourself:
- Where are the biggest risks for payment fraud on my site?
- What kinds of transactions or actions need the most protection?
- How often should I request Fingerprint visitor identification?
Get to know how your users behave
Next, consider how your users normally interact with your site. For example, is it common for one device to make multiple transactions in a row or for users to buy from different devices? Knowing what’s typical helps you know when to flag suspicious activity.
Think about your customers’ device characteristics, too. Do your users tend to use tools like VPNs or private browsing settings? Are there certain locations that your users usually browse from? The key is to understand your users’ usual patterns so you can recognize risky or suspicious behavior.
Ask yourself:
- How do my users typically make purchases or interact with the site?
- What behaviors should I treat as normal, and what should raise suspicion?
- How can I use data to improve my fraud prevention over time?
Set thresholds for suspicious behavior
Once you’ve got a handle on how your users interact with your site and where the risks are, it’s time to define what’s suspicious. This means setting clear thresholds for behaviors that should raise a red flag.
For example, if most users make purchases from one or two devices, you might flag a third or fourth device as suspicious, especially if the transaction value is high. You can also watch for patterns like a single device making an unusually high number of transactions in a short time — a common tactic for fraudsters.
Other triggers might include VPN usage, browser tampering, or logins from unexpected locations. For instance, if jailbroken devices are rare among your users, detecting one could be a sign something’s off. Setting these thresholds helps you strike the right balance between catching fraud and keeping things smooth for legitimate customers.
Ask yourself:
- How many purchases within a set time period from one device is normal?
- What’s the typical number of devices associated with a single user?
- Which behaviors or signals should flag a purchase as suspicious?
Define responses to suspicious payment activity
Once you’ve identified what counts as suspicious, the next step is deciding how to respond. Potential actions can range anywhere from blocking transactions outright to flagging them for review, requiring additional verification steps, or even limiting account functionality temporarily. The key is to have a clear, tiered plan for handling risky activity based on how serious the threat appears to be.
For example, if a device suddenly makes an unusually high number of purchases in a short time, you might hold those transactions for manual review or require the user to verify their identity with a one-time passcode (OTP). If you detect a bot attempting credit card testing or accessing your checkout page, you can block those actions entirely to prevent further abuse.
Key questions:
- What actions should you take when suspicious payment activity is detected?
- How should the severity of the detected threat determine the response?
- What steps can you take to verify transactions without disrupting legitimate users?
Map out your installation and API usage
To integrate Fingerprint and start tackling payment fraud, you’ll need to set up the tools that work best for your platform. For websites, install the JavaScript agent directly into your client-side code. If you’re working on mobile apps, we’ve got you covered with SDKs for both native and cross-platform frameworks. Fingerprint works by gathering device and browser attributes from the client side and sending them to Fingerprint for processing and identification.
Once your client-side code is set up, choose how to securely send Fingerprint results to your server. Server-side data from Fingerprint gives you detailed information about the identified visitor, such as whether the visitor is a bot, using a tampered browser, operating in incognito mode, etc. You have three options to access this data:
- Server API: Make requests directly from your backend or use one of the backend SDKs. This option is great for systems that can securely store and access secret keys.
- Webhooks: Set up an endpoint on your server to receive identification data from Fingerprint in real time. Webhooks are perfect if you want to store a complete historical record of events for deeper analysis.
- Sealed Client Results: This option provides an encrypted front-end response payload from the JavaScript agent. It contains the same data as the
/eventsServer API but is securely delivered without requiring additional backend integration. This option is the fastest as you get all the details in the initial identification response.
Choose an ad blocker evasion strategy
To make sure you can identify every visitor, including those using ad blockers, you’ll need to set up an ad blocker evasion strategy. One effective approach is creating a custom subdomain that routes requests to Fingerprint’s infrastructure, reducing the chance of requests being blocked.
You can also use cloud proxy integrations for popular services like Cloudflare, Akamai, or CloudFront. These proxies send identification requests through your domain, making them less likely to be flagged by ad blockers. For a step-by-step guide, check out our full documentation on protecting the JavaScript agent from ad blockers.
Consider other system integration and data management needs
To maximize Fingerprint’s impact on preventing payment fraud, it’s crucial to consider how its data will fit into your other existing systems and workflows. Are there tools or processes within your infrastructure that could benefit from Fingerprint data? For instance, integrating Fingerprint with your Web Application Firewall (WAF) can enhance your ability to block malicious activity, such as bot-driven credit card testing. Similarly, connecting Fingerprint to your chargeback dispute system can provide device-level evidence to strengthen your case against false claims.
Next, think about how you’ll store and access Fingerprint’s identification data. Will you use your current databases, or do you need to update your infrastructure to support it? Decide how you’ll monitor and analyze this data — whether through dashboards, automated alerts, or reporting tools. These tools can help you to spot trends, monitor activity, and continuously refine your fraud prevention strategy.
Define specific metrics, such as the number of fraudulent transactions detected or the success rate of chargeback disputes, to measure Fingerprint’s effectiveness. Establish a baseline, then regularly review and adjust your strategy based on these benchmarks to ensure you get the most value from the insights.
Key questions:
- How will Fingerprint data integrate with my existing systems, like WAFs or chargeback dispute tools?
- Do I need to make changes to my infrastructure to store and access this data effectively?
- How will I monitor and analyze Fingerprint data to detect trends and refine my fraud prevention efforts?
Additional considerations: Ensuring GDPR compliance & creating a fallback plan
By now, you’ve covered most of the key elements for implementing Fingerprint to combat payment fraud, but there are a few final details to think about.
First, make sure your use of Fingerprint complies with GDPR and other relevant regulations. Under GDPR, using Fingerprint for fraud prevention is considered a “legitimate interest,” meaning explicit user consent may not be required for browser or device identification. However, it’s still important to evaluate your specific regulatory obligations and ensure proper consent mechanisms are in place where necessary. Additionally, choose the appropriate region and data retention settings to comply with data residency laws and protect user privacy while meeting legal requirements.
Second, consider what to do if Fingerprint cannot generate a visitor identifier. Although rare, especially when the JavaScript agent is properly protected, issues like timeouts, rate limits, or other technical challenges can occasionally arise. In these cases, having a fallback plan is important. For example, you could require additional verification for transactions where a visitor identifier isn’t available. This ensures your payment fraud prevention remains effective at all times.
Key questions:
- What consent mechanisms do I need to implement to collect and process user data?
- Have I chosen the right region and data retention policies for Fingerprint data processing?
- How will I handle transactions if Fingerprint cannot generate a visitor identifier?
Implementation steps for stopping payment fraud
Now that you’ve carefully mapped out your plan, you’re ready to implement Fingerprint to combat payment fraud on your platform. With a solid understanding of your users, well-defined thresholds and responses, and a clear strategy for integrating Fingerprint into your infrastructure, you'll be set up for success.
To set the stage for these steps, let’s look at an example: Acme Co., a mid-sized European e-commerce company that sells consumer technology goods, has decided to strengthen its payment fraud prevention strategy. Acme operates a website where customers make purchases and manage their orders without requiring accounts. After going through the planning process outlined earlier, Acme has decided on the following logic and actions:
- Bots will be blocked automatically. Any visitor identified as a bot, such as those running card-testing schemes, will not be allowed to check out.
- Failed payments will lead to a temporary block. Visitors with more than five failed payment attempts in the last 24 hours will be blocked from making transactions.
- Visitors with too many purchases will need verification. If a visitor makes more than three purchases within 30 minutes, they’ll need to verify their identity with an OTP.
- Promotion abusers will be stopped. Visitors trying to use the same coupon code more than once won’t be able to complete their transaction.
- Too many new accounts will be blocked. Visitors creating more than three accounts in 24 hours won’t be able to register any more accounts.
- Unrecognized devices will require extra verification. If a login attempt comes from a device that hasn’t been used with the account before, the user will be prompted to verify their identity with an OTP.
These rules allow Acme to leverage Fingerprint’s insights to detect and stop payment fraud while maintaining a smooth experience for genuine customers. As we go through the implementation steps, we’ll refer back to Acme’s decisions to illustrate how these concepts can be applied in practice.
Step 0: Gather your API keys
Fingerprint offers two types of API keys: a public key for client-side identification and a secret key for secure server-side operations. Make sure to never include your secret key in client-side code or anywhere it could be publicly accessible. To retrieve these keys, log into the Fingerprint dashboard and click on API Keys. You’ll find your keys listed there, or you can generate new ones if needed.
Step 1: Install the JavaScript agent
The first step in integrating Fingerprint is to make an identification request using the client agent. Whether you’re working with modern frontend frameworks like Angular or React, or developing a mobile application, you can choose from a range of Fingerprint libraries tailored to your needs.
Acme is adding Fingerprint to its website. To get started, install the Fingerprint agent loader via NPM. In this example, we’ll use the general-purpose JavaScript library, which is compatible with a variety of module bundlers:
npm i @fingerprintjs/fingerprintjs-proWhen using Fingerprint to prevent payment fraud, the agent should be added to critical pages like your checkout or payment forms. To maximize effectiveness, initialize the agent as early as possible. You can decide when to trigger the actual identification request — either immediately on page load or when a specific action takes place. For instance, Acme chose to trigger the identification request when the “Place Order” button is clicked, ensuring the visitor ID is up-to-date for verifying transactions.
import * as FingerprintJS from "@fingerprintjs/fingerprintjs-pro";
const fpPromise = FingerprintJS.load({
region: "eu",
apiKey: "PUBLIC_API_KEY",
endpoint: "https://fp.acme.com",
scriptUrlPattern: "https://fp.acme.com/web/v<version>/<apiKey>/loader_v<loaderVersion>.js"
});
async function placeOrder(orderDetails) {
// Get the visitor ID when you need it.
const fp = await fpPromise;
const result = await fp.get();
const { requestId } = result;
// ... additional order logic
}In this setup, Acme uses the region parameter with the load method to set their region to the EU, ensuring compliance with regional requirements as they serve customers in Europe. Additionally, they’ve specified both the endpoint and scriptUrlPattern parameters to route identification requests through a custom subdomain, minimizing the risk of ad blockers interference. The endpoint parameter defines where the agent will send identification requests, and the scriptUrlPattern specifies the URL pattern for downloading the latest agent loader code. For more details, see the load function reference.
Within the placeOrder function, the identification request is made using fp.get(), which returns an object containing a requestId and a visitorId. The requestId is unique to each identification and changes with every request, while the visitorId remains consistent for the same browser or device. By retrieving the visitorId during the checkout process, Acme can link orders to specific devices, helping detect and prevent payment fraud.
Step 2: Send the identification data to the server
Now that you have made the identification request, you can send the requestId to your server. There, you can verify the authenticity of the identification request, analyze additional characteristics of the visitor, and decide on the appropriate actions to take.
import * as FingerprintJS from "@fingerprintjs/fingerprintjs-pro";
const fpPromise = FingerprintJS.load({
region: "eu",
apiKey: "PUBLIC_API_KEY",
endpoint: "https://fp.acme.com",
scriptUrlPattern:
"https://fp.acme.com/web/v<version>/<apiKey>/loader_v<loaderVersion>.js",
});
async function placeOrder(orderDetails) {
// Get the visitor ID when you need it.
const fp = await fpPromise;
const result = await fp.get();
const { requestId } = result;
// Include the visitor ID in the order details.
const orderPayload = {
...orderDetails,
requestId: result.requestId,
};
const requestOptions = {
method: "POST",
body: JSON.stringify(orderPayload),
headers: {
"Content-Type": "application/json",
Accept: "application/json",
},
};
// Send the order payload to your server.
const response = await fetch("/api/place-order", requestOptions);
// ... additional order logic
}
Step 3: Confirm the validity of the identification result
Acme has decided to use the Server API to request additional details about identified visitors. Before using the request ID, you need to check that it’s valid and hasn’t been tampered or reused in a replay attack. This check is done on the server.
First, install the Fingerprint Server API library. In this example, we’re using the Node SDK, but you can also call the Server API directly.
npm install @fingerprintjs/fingerprintjs-pro-server-apiYou’ll then need to initialize the Fingerprint Server API client, specifying your secret API key and region:
import {
FingerprintJsServerApiClient,
Region,
} from "@fingerprintjs/fingerprintjs-pro-server-api";
async function validateFingerprintResult(requestId, request) {
const client = new FingerprintJsServerApiClient({
apiKey: "SECRET_API_KEY",
region: Region.EU,
});Next, retrieve the identification event using the requestId sent from the client. This event contains the data needed to validate the identification request:
const identificationEvent = await client.getEvent(requestId);
const identification = identificationEvent.products?.identification?.data;We can now check if the identification event is too old. If the event is more than 3 seconds old, it’s flagged as a potential replay attack:
// Identification event must not be more than 3 seconds old
if (Date.now() - Number(new Date(identification.time)) > 3000) {
return {
success: false,
error: "Old identification request, potential replay attack.",
};
}You can also verify that the IP address from the identification matches the client’s IP address. This step helps to detect potential spoofing attacks:
// This is an example of obtaining the client's IP address.
// In most cases, it's a good idea to look for the right-most
// external IP address in the list to prevent spoofing.
if (request.headers["x-forwarded-for"].split(",")[0] !== identification.ip) {
return {
success: false,
error:
"Identification IP does not match request IP, potential spoofing attack.",
};
}Next, the code checks that the request originated from a known and trusted domain. This ensures that the visitor data is coming from a legitimate source, specifically Acme’s website:
const ourOrigin = "https://acme.com";
const visitorDataOrigin = new URL(identification.url).origin;
// Confirm that the request is from our origin.
if (
visitorDataOrigin !== ourOrigin ||
request.headers["origin"] !== ourOrigin
) {
return {
success: false,
error:
"Visit origin does not match request origin, potential spoofing attack.",
};
}
return { success: true, data: identificationEvent };
}
If all checks pass, the function returns the full identification event data, confirming that the request is legitimate. This process ensures that Acme can trust the visitor ID and proceed with any sensitive actions.
Step 4: Block bots from making purchases
In this step, we’ll create a new function to handle suspicious device activity, specifically targeting bots attempting to make fraudulent purchases. Any visitor identified as a bot will be immediately blocked from proceeding with the checkout process, preventing card cracking and unauthorized transactions, and protecting Acme’s platform from automated fraud. Fingerprint’s bot detection signal returns either bad for malicious bots, good for known legitimate bots like search engines, and notDetected when no bot activity is detected.
function checkDeviceSignals(identificationEvent) {
// Prevent bots from making purchases.
if (identificationEvent.products?.botd?.data?.bot?.result !== "notDetected") {
return {
success: false,
error: "Bot detected, purchase is blocked.",
};
}
return { success: true };
}You can add to this function by including additional checks based on Fingerprint's Smart Signals, tailored to your specific user base and definitions of suspicious characteristics. For example, you might include checks for browser tampering, VPN usage, or other behaviors that are uncommon or potentially risky for your platform.
Step 5: Stop visitors with repeated failed payment attempts
Next, we’ll create a function to check failed payment attempts and enforce a temporary block for devices exceeding the 5 failed payments in the last 24 hours. This rule helps protect Acme’s platform from potential card testing and other forms of payment fraud.
async function checkFailedPayments(visitorId) {
const now = Date.now();
const oneDayAgo = now - 24 * 60 * 60 * 1000;
// Count the number of failed attempts in the last 24 hours
const [rows] = await db.execute(
`SELECT COUNT(*) AS recent_failed_attempts
FROM payment_attempts
WHERE outcome = 'payment_failed' AND visitor_id = ? AND timestamp > ?`,
[visitorId, oneDayAgo]
);
const recentAttempts = rows[0]?.recent_failed_attempts || 0;
if (recentAttempts >= 5) {
return {
success: false,
error: "Too many failed payment attempts.",
};
}
return { success: true };
}Make sure to update your database whenever a payment attempt is made and include the outcome so you can refer to it in this function.
// Insert a new row into the payment_attempts table with visitor details and outcome
await db.execute(
"INSERT INTO payment_attempts (visitor_id, outcome, timestamp) VALUES (?, ?, ?)",
[visitorId, outcome, Date.now()]
);Step 6: Verify visitors with too many quick purchases
Up next, we’ll create a function to monitor purchase activity and flag visitors who make an unusual number of purchases within a short time frame. If a visitor completes more than three purchases within 30 minutes, their transactions will be flagged for additional verification. This step helps detect potential fraud, such as bots or malicious users attempting to abuse your platform.
async function checkPurchaseFrequency(visitorId) {
const now = Date.now();
const thirtyMinutesAgo = now - 30 * 60 * 1000;
// Count the number of purchases made by the visitor in the last 30 minutes.
const [rows] = await db.execute(
"SELECT COUNT(*) AS recent_purchases FROM purchases WHERE visitor_id = ? AND timestamp > ?",
[visitorId, thirtyMinutesAgo]
);
const recentPurchases = rows[0]?.recent_purchases || 0;
if (recentPurchases >= 3) {
return {
success: false,
error: "Too many purchases in a short period. Verification is required.",
action: "sendOTP", // Trigger your specified action for verification.
};
}
return { success: true };
}Whenever a purchase is made, log the purchase details along with the visitor ID to monitor activity, even for anonymous visitors.
// Insert a new row into the purchases table with visitor ID and other purchase details
await db.execute(
"INSERT INTO purchases (visitor_id, purchase_id, timestamp) VALUES (?, ?, ?)",
[visitorId, purchaseId, Date.now()]
);Step 7: Block promotion abusers
To prevent promotion abuse, this next function tracks and blocks repeated coupon usage by the same visitor. Visitors who try to reuse a coupon code will be stopped from completing their transaction, ensuring that discounts are used as intended and not exploited.
async function checkCouponUsage(visitorId, couponCode) {
// Query the database to check if the visitor has already used this coupon code.
const [rows] = await db.execute(
"SELECT COUNT(*) AS usage_count FROM coupon_usage WHERE visitor_id = ? AND coupon_code = ?",
[visitorId, couponCode]
);
const usageCount = rows[0]?.usage_count || 0;
if (usageCount > 0) {
return {
success: false,
error: "Coupon code has already been used. Transaction cannot proceed.",
};
}
return { success: true };
}After a coupon is successfully used for the first time, be sure to log the usage so it can be referenced later to verify any future attempts to reuse it.
// Insert a new row into the coupon_usage table with visitor ID and coupon details
await db.execute(
"INSERT INTO coupon_usage (visitor_id, coupon_code, timestamp) VALUES (?, ?, ?)",
[visitorId, couponCode, Date.now()]
);Step 8: Block visitors creating too many new accounts
To prevent abuse from visitors creating excessive accounts, this function tracks account creation activity and blocks visitors who attempt to register more than three accounts within a 24-hour period. This helps stop fraudulent behavior such as exploiting referral programs or signup bonuses while protecting the integrity of your platform.
async function checkAccountCreation(visitorId) {
const now = Date.now();
const oneDayAgo = now - 24 * 60 * 60 * 1000;
// Count the number of accounts created by the visitor in the last 24 hours.
const [rows] = await db.execute(
"SELECT COUNT(*) AS account_count FROM accounts WHERE visitor_id = ? AND created_at > ?",
[visitorId, oneDayAgo]
);
const accountCount = rows[0]?.account_count || 0;
if (accountCount >= 3) {
return {
success: false,
error: "Too many accounts created.",
};
}
return { success: true };
}Again, this function depends on the logging of the visitor ID alongside account information.
// Insert a new row with visitor ID and other account details into the accounts table.
await db.execute(
"INSERT INTO accounts (account_id, visitor_id, created_at) VALUES (?, ?, ?)",
[accountId, visitorId, Date.now()]
);Step 9: Require extra verification for unrecognized devices
To prevent accounts being taken over, this function detects login attempts from unrecognized devices and prompts users to verify their identity with an OTP. This prevents unauthorized access and ensures that only legitimate users can log in and make purchases, even if their credentials are compromised. If the device is recognized, the visitor gets a hassle-free login experience.
async function checkDeviceForLogin(accountId, visitorId) {
// Check if the device is already associated with the account.
const [rows] = await db.execute(
"SELECT COUNT(*) AS device_count FROM account_devices WHERE account_id = ? AND visitor_id = ?",
[accountId, visitorId]
);
const deviceCount = rows[0]?.device_count || 0;
if (deviceCount === 0) {
// If the device is not recognized, require OTP verification.
return {
success: false,
error: "Unrecognized device. Please verify your identity with a one-time passcode.",
action: "sendOTP",
};
}
// If the device is recognized, allow the login to proceed
return { success: true };
}When the device is verified, make sure to register it as a known device for the account.
// Log the device as recognized for the account
await db.execute(
"INSERT INTO account_devices (account_id, visitor_id, timestamp) VALUES (?, ?, ?)",
[accountId, visitorId, Date.now()]
);With the completion of these implementation steps, you’ve successfully integrated Fingerprint device intelligence and robust logic to protect your business from common forms of payment fraud.
See Fingerprint in action
Throughout this guide, we’ve outlined methods to detect and address suspicious activities, such as blocking bots, flagging repeated failed payments, preventing coupon abuse, and verifying identities for high-risk actions.
To see some of these techniques in action, explore our live demos, including ones for coupon fraud and card testing. These demos showcase practical applications of the concepts covered in this guide, such as tracking suspicious coupon usage and detecting patterns of fraudulent payment attempts.
The full source code for these demos is available on GitHub, giving you the tools to explore, customize, and integrate similar logic into your own platform.
Final thoughts for payment fraud detection & prevention
In this guide, we’ve covered how to use Fingerprint to protect your platform from payment fraud. From setting up the JavaScript agent and verifying visitor IDs to tracking failed payments, blocking bots, and stopping promo abuse, you now have a strong system to keep transactions safe while making things easy for real users.
If you have questions about detecting or stopping payment fraud, feel free to reach out — we’re here to help!
