Skip to main content

Overview

This tutorial covers how to use Fingerprint to strengthen chargeback dispute evidence by linking purchases to a visitor over time, even when a customer claims an unauthorized transaction. You’ll begin with a starter app that includes a simple event ticket storefront where you can make purchases, a personal order history view where you can simulate a chargeback, and a merchant/admin view where you can view purchase details. From there, you’ll add the JavaScript agent to identify each visitor and use server-side logic to link purchases together with a visitor identifier to prove a consistent pattern of legitimate activity tied to the same visitor. By the end, you’ll have a sample app that creates a browser-linked purchase history you can reference when a customer disputes a charge, claiming the purchase wasn’t made by them (AKA friendly fraud). This tutorial uses just plain JavaScript and a Node server with SQLite on the backend. For language- or framework-specific setups, see the quickstarts.
Estimated time: < 15 minutes

Prerequisites

Before you begin, make sure you have the following:
  • A copy of the starter repository (clone with Git or download as a ZIP)
  • Node.js (v20 or later) and npm installed
  • Your favorite code editor
  • Basic knowledge of JavaScript

1. Create a Fingerprint account and get your API keys

  1. Sign up for a free Fingerprint trial, or log in if you already have an account.
  2. After signing in, go to the API keys page in the dashboard.
  3. Save your public API key, which you’ll use to initialize the JavaScript agent.
  4. Create and securely store a secret API key for your server. Never expose it on the client side. You’ll use this key on the backend to retrieve full visitor information through the Fingerprint Server API.

2. Set up your project

  1. Clone or download the starter repository and open it in your editor:
Terminal
  1. This tutorial will be using the chargeback-dispute folder. The project is organized as follows:
public
admin.html - Admin dashboard
admin.js - Front-end logic for admin view
history.html - Order history and dispute simulator
history.js - Front-end logic for history view
index.html - Event ticket storefront
index.js - Front-end logic for browsing and purchases
server
db.js - SQLite database connection
purchases.js - Purchase and evidence logic
server.js - Serves static files and purchase endpoints
.env.example - Example environment variables
  1. Install dependencies:
Terminal
  1. Copy or rename .env.example to .env, then add your Fingerprint API keys:
Terminal
  1. Start the server:
Terminal
  1. Visit http://localhost:3000 to view the mock events storefront and make a few test purchases, then open your order history page to simulate a chargeback on one of them, and finally switch to the merchant view to inspect the disputed order where you’ll see only limited evidence to help you prove the purchase was actually appropriately authorized.

3. Add Fingerprint to the frontend

In this step, you’ll load the JavaScript agent when the page loads and trigger identification when the user clicks Complete purchase. The JavaScript agent returns both a visitor_id and an event_id. Instead of relying on the visitor_id from the browser, you’ll send the event_id to your server along with the purchase data. The server will then call the Fingerprint Events API to securely retrieve the full identification details, including Smart Signals you can use as evidence during chargeback disputes.
  1. At the top of public/index.js, load the JavaScript agent:
public/index.js
  1. Make sure to change region to match your workspace region (e.g., eu for Europe, ap for Asia, us for Global (default)).
  2. Near the bottom of public/index.js, the Complete purchase button already has an event handler for submitting the purchase details. Inside this handler, request visitor identification from Fingerprint using the get() method and include the returned event_id when sending the purchase to the server:
public/index.js
The get() method sends signals collected from the browser to Fingerprint servers, where they are analyzed to identify the visitor. The returned event_id acts as a reference to this specific identification event, which your server can later use to fetch the full visitor details. For lower latency in production, use Sealed Client Results to return full identification details as an encrypted payload from the get() method.

4. Receive and use the event ID to get visitor insights

Next, pass the eventId through to your server-side purchase logic, initialize the Fingerprint Node Server SDK, and fetch the full visitor identification event so you can access the trusted visitor ID and any additional Smart Signals you want to store for dispute evidence.
  1. In the backend, the server/server.js file already defines API routes for the app. The POST /api/purchases route passes the request body to the postPurchase function defined in server/purchases.js. Because the frontend now sends eventId in the payload, that value will be available in the body when postPurchase runs:
server/server.js
  1. The server/purchases.js file contains the logic for handling purchase submissions and chargebacks. Start by importing and initializing the Fingerprint Node Server SDK there, and load your environment variables with dotenv:
server/purchases.js
  1. Make sure to change region to match your workspace region (e.g., EU for Europe, AP for Asia, Global for Global (default)).
  2. Update your purchase handler function to extract eventId and use it to fetch the full identification event details from Fingerprint so you can log the visitor ID alongside each purchase:
server/purchases.js
Using the eventId, the getEvent method will retrieve the full data for the visitor identification event. The returned object will contain the visitor ID, IP address, device, and browser details, and Smart Signals like bot detection, browser tampering detection, VPN detection, and more. You can see a full example of the event structure and test it with your own device in the demo playground. For additional checks to ensure the validity of the data coming from your frontend, view how to protect from client-side tampering and replay attacks. Next, use the trusted visitor ID from the event object to link purchases together. Instead of relying only on an account email or IP address, you’ll associate each purchase with the visitor ID, so you can later show that the same visitor has a history of legitimate purchases when a chargeback happens. Note: The starter app includes a SQLite database with a table already created for you:
SQLite database tables
  1. First update the existing postPurchase function so it stores the visitorId alongside each new row in the purchases table.
server/purchases.js
  1. Update the getRelatedPurchases function so it looks up related orders based on both email and visitorId. This lets you see the full history for a visitor even if they change accounts.
server/purchases.js
  1. In the merchant/admin view (public/admin.js), update the following functions to include the visitorId when displaying and exporting the history related to a purchase:
public/admin.js
  1. Then in the admin.html file, uncomment the visitor ID header and template column:
public/admin.html
This gives the simulated evidence package additional information to help dispute friendly fraud chargebacks. Browser and device identifiers aren’t the only types of evidence a merchant can submit, but they provide a strong additional signal of continuity that card networks ask for during chargeback dispute reviews. You can expand the logic by including more factors, depending on the level of detail your business needs.
This is a minimal example showing how to use Fingerprint data to support chargeback disputes. In a real application, make sure to implement proper security practices, perform robust server-side validation, and follow your organization’s standards for storing and transmitting evidence related to payments and disputes.

6. Test your implementation

Now that everything is wired up, you can see how the visitor ID provides additional evidence for chargeback disputes.
  1. Start your server if it isn’t already running and open http://localhost:3000:
Terminal
  1. Make a few purchases from the main Events page. Each one will be logged with both your account email (you are logged in as jamie@example.com) and your visitor ID.
  2. Open your personal Order history page and simulate a chargeback on one of them.
  3. Switch to the Merchant view and view the purchase history related to the purchase with the chargeback. You’ll see your full purchase history including visitor ID, showing that the disputed purchase and the earlier successful purchases all originated from the same browser.

Next steps

You now have a basic chargeback dispute helper powered by Fingerprint. From here, you can enrich the dispute evidence even more with Smart Signals. To dive deeper, explore the other use case tutorials for more step-by-step examples. Check out these related resources: