Device binding vs browser fingerprinting: proving a payment came from the cardholder's phone

Any fraud control that puts the cardholder in the loop depends on one question: is this really the cardholder's device? There are two broad ways to answer it, and they are not equally strong.

Browser fingerprinting: an educated guess

Fingerprinting builds a profile from what a browser reveals: screen size, fonts, time zone, graphics details and many more attributes. Combined, they are often distinctive enough to recognise a returning visitor.

It is useful as one signal among many. But it is probabilistic, it drifts when the browser updates, and the attributes can be observed and replayed by a determined attacker. A fingerprint says a device looks familiar. It can't prove possession.

Device binding: a cryptographic fact

Modern phones carry secure hardware that can generate a private key which never leaves the chip. When the issuer's app enrols, it asks the chip for a new key and sends only the public half to the server.

From then on, the phone proves it is the same phone by signing a fresh challenge with that key. No signature, no approval. A stolen password can't produce one, and neither can a new SIM card, because the key is tied to the physical device, not to the phone number.

Attestation: is the app real?

A key in secure hardware is only as trustworthy as the app asking for it. Platform attestation closes that gap. Apple's App Attest and Google's Play Integrity let the server check that the request came from the genuine app on a genuine device, not from a modified build or an emulator.

What this means for issuers

• Use hardware-bound keys for anything that approves money moving. Use fingerprinting, if at all, as a supporting signal.
• Verify attestation at enrolment, and treat rooted or emulated devices as a reduced-trust signal rather than an automatic block.
• Require a fresh signature for every approval, bound to that payment, so it can't be replayed.
• Treat a missing signal as no signal. A cardholder who hasn't enrolled shouldn't be declined for it.

This is how 0Fraud binds approvals: every answer from the cardholder is a signature made inside the phone's secure chip, verified on our side before any payment is let through.