Google Pay and Mastercard have started rolling out biometric-enabled payments in India using the Consumer Device Cardholder Verification Method (CDCVM). Shoppers confirm a purchase with a fingerprint or face scan, and the biometric data stays locked inside the phone.
Why CDCVM matters now
CDCVM moves the “who you are” check onto the device. Only a cryptographically signed, single-use payment token leaves the phone, so the biometric never traverses the internet.
How the flow works under the hood
- Feature extraction – The sensor (fingerprint reader or camera) feeds raw data into a Secure Enclave or Trusted Execution Environment (TEE). These isolated zones process the input without exposing it to the operating system.
- Local comparison – The device stores an encrypted template of the user’s biometric. The Secure Enclave compares the live capture against this template, never sending the raw image or feature vector elsewhere.
- Hardware attestation – When the match succeeds, the enclave signs the transaction with a private key that never leaves the hardware. The attestation proves a verified biometric was used, without revealing the biometric itself.
- Token generation – The signed attestation combines with a token-service to produce a one-time token. The token, not the biometric, travels to the merchant and then to the issuing bank for settlement.
The merchant and the bank only see the signed token. All biometric data remains in the device’s protected memory.
Pitfalls developers must avoid
- Sending biometric vectors – Transmitting raw fingerprint or facial data creates a permanent exposure. A fingerprint can’t be changed if a database is breached.
- Replay attacks – Numeric representations of biometrics can be captured and resent to spoof a sensor if they travel over the network.
- Regulatory headaches – Many jurisdictions treat biometric data as highly sensitive personal information, imposing strict storage, consent and breach-notification rules.
Treat the biometric as a local key that unlocks cryptographic operations; never ship it as payload.
A concrete implementation checklist
- Use platform-provided biometric APIs that keep capture and processing inside the device’s TEE.
- Store the biometric template encrypted with a key managed by the Secure Enclave; never write it to the file system.
- Request hardware attestation after a successful match.
- Integrate with a tokenization service that consumes the attestation and issues a single-use token. Include the signed attestation but no biometric data in the token request.
- Validate the token on the server side using the issuer’s public key. Reject any token lacking a valid attestation signature.
- Test edge cases such as sensor failures, false rejects, and device swaps. The flow should fall back to a PIN or password without exposing biometric data.
Takeaway
When biometric verification stays inside the phone’s secure hardware and merely signs a one-time token, users keep their fingerprints or facial data private, and merchants reduce exposure to sensitive personal information. For developers, the rule is simple: let the biometric unlock the cryptographic key, never let it leave the device.