Fraud prevention and security
Device fingerprinting is the process of observing multiple hardware, software, browser, network, or behavior-related characteristics and combining them into a profile that may help recognize a device or session. Examples can include browser type, operating-system details, screen characteristics, language settings, IP-related context, and patterns in how a session behaves.
In a payment workflow, a fraud-prevention system may compare those signals with transaction details and prior activity to identify unusual patterns. A fingerprint is not the same as a physical fingerprint, a confirmed identity, or proof of fraud. It is usually a risk signal whose usefulness depends on the data collected, the system evaluating it, and the surrounding transaction context.
Some characteristics are visible in ordinary web requests, while others may be observed through code running in a browser or mobile application. The W3C describes passive fingerprinting as using characteristics already observable in requests and active fingerprinting as gathering additional characteristics through client-side activity. A system can combine several observations into an identifier, score, or group of related sessions.
The result is not necessarily permanent or unique. Browser updates, privacy settings, network changes, shared devices, remote desktops, and ordinary configuration changes can alter signals. Different people may also use similar devices, while one person may use several devices. For these reasons, merchants should not interpret a device match as confirmed identity or a device change as confirmed fraud.
A risk system may compare a current session with patterns previously associated with the same account, device profile, network context, or checkout flow. A meaningful difference can prompt additional review, but it does not explain why the difference occurred.
Repeated attempts that share device or network characteristics may be grouped for analysis. This can help a team see patterns that would be difficult to notice when reviewing each payment separately.
Device observations may be considered alongside authorization responses, transaction history, account behavior, delivery details, and other approved signals. Current provider documentation determines which signals are actually available and how they are used.
Device fingerprinting is probabilistic. A shared office computer, public network, privacy-focused browser, software update, travel pattern, assistive technology, or newly replaced phone can make legitimate activity look different. Attackers may also change or conceal characteristics. No single signal should be treated as a guarantee that a transaction is safe or fraudulent.
Merchants should understand the actions connected to a risk result. A low-confidence signal may be appropriate for monitoring, while a combination of stronger indicators may be routed for review under the provider's documented workflow. Broad automatic blocks can interrupt legitimate purchases, so teams should examine outcomes and escalation paths rather than assuming more data always produces a better decision.
The W3C recommends limiting fingerprinting surface and collecting only the detail necessary for a function. A merchant evaluating a service should review the provider's current product documentation and privacy disclosures, then align the configuration with the business's own privacy and security review. This page is educational and does not determine a merchant's specific obligations.
A derived profile based on observable characteristics associated with a browser, device, network, or session. It may help correlate activity but does not establish a person's identity by itself.
A measurement of a person's physical fingerprint. Device fingerprinting generally refers to technical characteristics, not the ridges on a person's finger or a biometric authentication result.
Some providers use the word fingerprint for a provider-generated identifier associated with a payment method. That is a separate concept with provider-specific behavior and should not be assumed to identify a browser or device.
Authentication uses defined factors or credentials to verify a claimant. NIST notes that risk-based signals are added controls rather than authenticators by themselves, so a device profile should not be described as replacing established authentication.
See how a business can reduce credit card fraud with layered operational and technical practices.
Learn what account testing fraud is and why patterns across attempts can matter.
Review guidance on how API keys should be stored without placing secrets in ordinary files or messages.
Explore more fraud prevention and security FAQs for merchant education.
Ask the payment or fraud-service provider for a current explanation of the device signals it collects, how those signals influence decisions, and what review controls are available. Document the business purpose, access, retention, customer-facing disclosure, and false-positive response before enabling or expanding collection.
Payments Max can help merchants organize payment-workflow questions and compare evaluation criteria. It does not guarantee fraud outcomes or replace a provider's technical documentation, a privacy review, or qualified professional guidance.
Privacy reminder: Never submit device identifiers, cardholder data, passwords, bank credentials, complete account numbers, or secret API keys through a general inquiry form.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US
