Approving card payments without biometrics, still signed by the phone

Some cardholders never set up biometrics. Some turn them off. Some can't use them on the day: gloves, an injury, a scan that won't take. If approving a payment requires biometrics, every one of those cardholders becomes a false decline and a support call.

So 0Fraud accepts the device passcode as well. The hard part is doing that without giving up the one thing that makes an in-app approval trustworthy: proof that it came from the cardholder's own phone.

Two keys, each with one way in

When a phone enrols, the SDK creates two keys inside the phone's secure hardware: the Secure Enclave on iPhone, StrongBox or the hardware-backed Keystore on Android. The first key can only be unlocked with biometrics. The second can be unlocked with biometrics or the device passcode.

Neither key ever leaves the chip. Every approval is a signature, made inside the chip, over that one payment's challenge. 0Fraud verifies the signature against the key the phone says it used. Because the hardware itself enforces how each key unlocks, an app can't claim biometrics when the cardholder typed a passcode.

The operating system asks, not us

The passcode prompt is the phone's own. Neither 0Fraud nor the issuer's app ever sees the digits. All we receive is the signature and which key produced it.

The issuer stays in control

• Passcode approval is on by default, so no cardholder is locked out.
• An issuer can switch a card programme to biometrics only.
• Every approval records which method was used, so a risk team can see the mix and act on it.
• A cardholder can always say no. A decline is accepted however the phone was unlocked.

The trade-off, stated plainly

A passcode is weaker than biometrics against someone who has watched the cardholder unlock their phone. That is why the choice belongs to the issuer, card by card, and why the method is recorded on every approval rather than hidden.