Fraud teams at e-commerce merchants face an expensive contradiction. Device fingerprinting is one of the most valuable signals in the risk stack, but the vendors who supply it charge enough to force hard choices about when and where to fire the call. The result: merchants skip device checks at exactly the moments that matter most.
Session resume is the clearest example. A returning user opens their browser, their cookie is still valid, and the site lets them back in without re-authenticating. No device call fires. The logic sounds reasonable: the user already cleared login, the device was trusted, why spend the money again? However, that reasoning assumes the session is still in the hands of the person who started it. Unfortunately, that’s not always the case.
Account marketplaces on the clearweb now routinely bundle session cookies alongside the standard PII payload: credentials, personal details, payment methods. Buyers inject those cookies into their own browsers and skip login entirely, landing inside a verified session on an unrecognized device. From the merchant's perspective, the transaction looks normal. The cookie is valid. The session is "authenticated." Browse, select, cart, checkout: same session, ostensibly the same user. The chargeback comes later.
This attack works because most device fingerprinting operates in isolation. Legacy device vendors collect dozens of signals (screen orientation, battery charge, OS language, canvas fingerprint) and return a device risk score. That score answers a narrow question: is this a real device, or is it spoofed? It does not answer who is behind the device, whether the identity elements in the transaction actually belong together, or whether the behavioral pattern matches the account's history. Those questions get routed to separate vendors: an identity provider here, an IP intelligence service there, a consortium model somewhere else. Each one adds latency, cost, and another integration to maintain.
The cumulative effect is a multivendor architecture where no single call sees the full picture. Device knows the hardware. Identity knows the person. IP knows the location. But none of them knows the relationship between the three, and the merchant's decisioning model is left to stitch the signals together after the fact, often with incomplete data because budget constraints forced a call to be skipped at some stage of the buyer journey.
This is the structural problem. It is not a device fingerprinting problem or an identity verification problem. It is an architecture problem: the fraud stack was built to answer narrow questions in silos, and the attack surface has moved to the seams between them.
What a unified call actually looks like
Pipl Trust takes a different approach.
Instead of answering one question per API call, it evaluates device, identity, IP, email, phone, and address signals together in a single request, then returns a Trust Score (0 to 1,000) alongside the granular signals and connectivity data that explain it. One call, one response, one integration.
The Trust Device SDK collects 100+ device and browser attributes across 12 categories (graphics, audio, hardware, platform, network, storage, and more) and resolves them into a persistent device identifier: the elephant_device. That identifier does not just fingerprint the hardware. It builds a history. When the same elephant_device appears at login and then again at purchase, Pipl Trust can measure continuity across the session, and that continuity raises the Trust Score by 100+ points compared to a purchase-only device signal. The device is not just "real." It is connected to a known identity, with a known history, on a known network.
Connectivity is where this compounds. For every pair of identity elements in the transaction (email and phone, phone and address, device and IP, name and email), Pipl Trust returns a connectivity score measuring how strongly those elements are historically linked in a graph of 5B+ identities and 28B+ cross-referenced data points. A legitimate customer's elements cluster tightly: their email, phone, address, and device have appeared together before, across years of data. A fraudster injecting a stolen cookie into a new browser triggers the opposite pattern: the device has no history with the account's identity elements, and the connectivity scores reflect it.
This is the session-resume problem solved at the architecture level. Even if the cookie is valid and the session appears authenticated, the device-to-identity connectivity is missing. The Trust Score drops. The decision rules flag the transaction for review or decline. No additional API call is needed because the device, identity, and connectivity evaluation already happened in the same request.
Calibration: the difference between a generic score and your score
Most device fingerprinting vendors return scores calibrated to a generalized fraud model. That model does not know your customer base. It does not know that your buyers skew mobile-heavy, or that your market serves a region where VPN usage is normal, or that your top customers routinely transact from shared household devices. Generic thresholds produce generic outcomes: more false positives on legitimate traffic, fewer catches on the fraud patterns specific to your business.
Pipl Trust's Score Calibration trains the model on each customer's own historical transaction data, both legitimate and fraudulent. The system selects which of the hundreds of available signals matter for that customer's specific fraud patterns, and the scores polarize: good transactions score high, fraud scores low. Calibrated customers have seen fraud detection improve by up to 73% (at the high-risk threshold) and false positives drop by up to 4.2 times, per company data. The Feedback API keeps the calibration current: every confirmed fraud or confirmed legitimate outcome feeds back into the model in near real time, so the score adapts as fraud patterns shift.
This is not a one-size-fits-all device score layered on top of a one-size-fits-all identity score. It is a single, calibrated risk assessment that considers device, identity, connectivity, and behavioral signals together, tuned to the merchant's own environment.
Fewer calls, more context, lower cost
The economics follow from the architecture. One API call that evaluates device, identity, IP, email, phone, and address replaces the 3, 4, or 5 separate vendor calls that a fragmented stack requires. Latency drops because the evaluation happens in one round trip. Cost drops because the merchant is not paying multiple vendors for overlapping signal coverage. And coverage improves because the call can fire at every stage of the buyer journey (signup, login, purchase) without the budget pressure that forces merchants to skip stages under a multivendor model.
Pipl Trust does not require merchants to rip out their existing risk engine. Our system plugs into the decisioning layer the merchant already operates, supplying a score and the reasoning behind it. The merchant keeps control of the decision. Pipl supplies the evidence.
The device question was never really about the device. It was about whether the person behind the device is who they claim to be, whether the identity elements in the transaction actually belong together, and whether the merchant's model has the signal depth to tell the difference. Answering those questions in a single call, calibrated to the merchant's own data, is how the economics and the security posture both improve at the same time.
Request a demo with our fraud prevention experts today to see these features in action, and learn how Pipl Trust with custom calibration and help you approve more buyers and increase your revenue.