When you’re using Fingerprint Identification to recognize return visitors, it’s generally a good idea to only request visitor identification when you need it, such as when someone clicks the login button or makes a purchase. While Fingerprint’s response time for an identification request is usually just a few hundred milliseconds, the timing doesn’t always line up with what your visitors are doing.

Imagine someone using a password manager that instantly fills in credentials and submits the form as soon as they land on your login page. That form could be ready to send before you get a response from Fingerprint with identification details. Or perhaps a user clicks a link to make a purchase, but that link takes them to another page or even a different website entirely. Waiting for visitor identification risks slowing them down, possibly leading to abandoned carts or missed conversions. And don’t forget the bots! They’re definitely not going to wait around for your identification request to finish before spamming your forms with junk or trying to takeover accounts.

So how do you handle these speedy interactions while still getting the critical device intelligence you need to stop fraud? Luckily, there are a few strategies that can help align these time-sensitive actions with Fingerprint’s visitor identification.

Overview of the Fingerprint identification flow

To handle visitor identification timing effectively, it’s important to first understand how Fingerprint Identification works.

Visitor identification starts by loading the Fingerprint client agent, followed by a request to identify the visitor’s browser or device. For an optimized setup, the client agent should be loaded right away, ideally on page load. Identification requests are then only triggered when necessary. This approach makes sure the client agent is ready when needed and reduces the potential for replay attacks.

When the identification request is made, the client agent gathers browser and device details and sends them to Fingerprint for analysis. The response includes a visitor ID and a request ID referencing that specific identification event. At this point, you have a few options to get the full event details and Smart Signals.

The simplest method is to send the request ID to your backend and use it to request the event details from the Fingerprint Server API. Alternatively, you can configure Fingerprint to use webhooks, sending event details directly to your own API endpoint.

Another option is to use sealed client results, where encrypted event details are included in the initial identification response and can be decrypted on your backend, bypassing the need for an additional request with the Fingerprint Server API.

Strategies for identification timing

Now that you have an understanding of the steps to identify visitors with Fingerprint, let’s take a look at how you can manage identification timing successfully.

Determining the best method for identification will depend on your specific use case. When choosing a strategy, it’s important to find the right balance between preventing fraud and reducing friction. The following methods can help you maintain security without disrupting legitimate user flow.

Delay form processing

One way to deal with automated submissions is to allow the form to be “submitted” immediately but delay the actual processing until the visitor identification response is received. This approach creates a seamless experience for the user, as the form appears to process normally while the site quietly waits for the necessary identification data.

To avoid blocking the form for too long, you can implement a timeout that allows the form to be submitted without identification if the process takes too long. The default timeout is 10 seconds (10000 milliseconds), and you can adjust this within the function used to make the identification request. For example:

const fp = await fpPromise;
const result = await { timeout: 5000 }); // 5 seconds

While waiting for the identification request to complete, other checks, like verifying login credentials, can still take place without navigating away from the current page. Once the identification request is complete, the form can proceed as usual. If the timeout is reached before the identification is returned, the form continues to process without the identification data.

The advantage of this method is that it provides a smooth experience for users, including those using password managers, since the form doesn’t appear blocked from input. However, implementing this method may require more complex logic, as handling the delayed submission and potential timeouts introduces more moving parts.

Identify the visitor earlier

Another approach to managing timing is to trigger visitor identification earlier, rather than waiting for a specific action like form submission. By doing this, you reduce the risk of misaligned timing, especially in cases where forms are submitted almost instantly on page load, such as with password managers or bots.

The timing of the identification pre-request will depend on the page and use case. You might choose to make the request as soon as the client agent is loaded or wait for other indicators that the user is about to take an action, such as filling in form fields or hovering over a button. Pre-requesting identification in advance ensures that the process is already underway — or even complete — by the time the critical action takes place. For example, you could add an event listener for when a form input changes:

const inputElement = document.getElementById('myInput');

inputElement.addEventListener('input', function () {
  fp.get()
});

However, it’s important to consider that a gap between requesting identification and using the results may provide and opportunity for malicious behavior, such as replay attacks. Additionally, triggering identification for every visitor, even when they haven’t taken a significant action, can lead to unnecessary billable API calls.

If this method is appropriate for your use case, it can also be combined with strategies like waiting for the identification request to complete before processing or disabling actions (like form submission) until identification is done. But you need to weigh this against the potential friction it could add to the user experience.

Proceed without identification

Another strategy is to proceed with an action without waiting for the Fingerprint identification request to complete. In this approach, webhooks are enabled, and the identification request is made using a linked ID to associate the identification data with the action. Linked IDs are custom data points that allow you to link specific information to an identification event. When making the identification request, linkedId can be passed as a parameter. For example:

const actionId = 3936532456;
fp.get({ linkedId: actionId });

To retrieve the identification event details, you must configure Fingerprint to use webhooks, so the event data is sent directly to your own API endpoint once it’s complete. You can then use the linkedId property to filter the data you have received and find the associated identification event.

Since you’re not waiting for a request ID on the frontend, the entire process happens asynchronously in the background, ensuring a smooth, fast user experience with no delays. However, there is a risk that the client agent may not have time to send the browser details to Fingerprint before the user navigates away from the page. This method works well when visitor identification isn’t critical and speed is the priority, but it’s less suitable for scenarios where fraud prevention is crucial.

Additional configuration considerations

When handling visitor identification timing, it’s essential to analyze your traffic patterns. Review activity data to determine how many visitors are performing automated actions, such as through password managers or bots, and pinpoint areas where speed is crucial, like during purchase flows.

Tailor your timing strategies based on these insights. While a default timeout of 10 seconds is a solid starting point, you may want to reduce it to as little as 2 seconds depending on your traffic and use case. Adjust these settings based on the frequency of automated submissions versus human actions to maintain the right balance between security and speed.

Ensure fast user actions while staying secure

Effectively managing automated submissions from password managers and bots or other time-sensitive actions requires a careful balance between security and user experience. Ensuring that Fingerprint’s identification process has time to complete without causing delays is crucial for maintaining fraud prevention while keeping your visitors happy.

By tailoring your approach — whether by delaying actions, identifying visitors early, or proceeding without waiting — you can align your security needs with a smooth, seamless user experience.

If you want more information or need help optimizing your setup for visitor identification, don’t hesitate to contact our support team for personalized assistance.