Confirmation of Payee and Face ID: Two Checks Before the Money Moves

Two things can go wrong the instant before a payment sends. You might be paying the wrong person — a mistyped recipient, or a scammer who swapped in their own details. Or someone who isn't you might be holding your unlocked phone. KibiPay's wallet puts a check in front of each risk: Confirmation of Payee answers "am I paying who I think I am?", and a biometric gate answers "is it really me?" Both fire before money moves.

Confirmation of Payee: paying the right person

Account details are unforgiving — an account number is just digits, and digits don't tell you whose account it is. Confirmation of Payee (CoP) closes that gap by checking the name against the account before you send. In the wallet, when you're about to pay a scanned payee, the app calls POST /v1/directory/confirm with the recipient and the name, and the directory answers with one of three verdicts:

• match — the name matches the account. The UI shows a "Verified" pill and you can proceed with confidence.
• close-match — nearly right, perhaps a middle name or a typo. Shown as a "Close" pill so you can eyeball it and decide.
• no-match — the name doesn't belong to that account. This is the important one.

On a no-match, the wallet doesn't just warn — it blocks the send outright, with a plain message: the payee name doesn't match, so nothing was sent. That's the whole value of CoP as an anti-fraud control: the classic "please pay this new account" invoice-redirection scam relies on you sending to an account whose name you never checked. Refusing to send on a name mismatch turns that scam from a silent success into a hard stop.

The biometric gate: confirming it's you

CoP protects the recipient; the biometric gate protects the payer. Before a payment goes out, the wallet calls a biometric check backed by the device's Face ID or fingerprint hardware. The gate is careful about what's actually available: it checks that the device has biometric hardware and that the user has enrolled a face or fingerprint, then prompts for authentication with a passcode fallback offered as a backstop. The prompt is explicit — "Confirm payment" — so the biometric isn't a vague unlock but a specific act of authorizing this transfer.

Crucially, this runs both at app unlock and again before every single payment. Unlocking the app once isn't treated as blanket authority to spend; each payment re-asks for a face or a fingerprint. That means a phone left unlocked on a table can't be used to drain a wallet — the money still won't move without the owner physically present to authorize it.

Two questions, two answers

It's worth appreciating that these are genuinely different checks answering different questions, and you need both. Confirmation of Payee could pass — you're definitely paying the right person — while the person holding the phone isn't you. The biometric gate could pass — it's definitely you — while you're about to pay a fraudster's account because you never checked the name. Only by running both do you get the full guarantee: the right person is paying, and they're paying who they intend to. Stacking an identity check and a destination check is exactly the kind of defense-in-depth that consequential actions deserve, and building them into the phone-first wallet flow means they're automatic, not optional.

Designed to fail in the safe direction

Both checks are built so that the cautious outcome is the default. Confirmation of Payee doesn't merely surface a warning on a name mismatch and leave the decision to a distracted user — a no-match actively blocks the send, turning "are you sure?" into "not sent." That matters because the scams CoP defends against, like invoice-redirection fraud, succeed precisely when a user clicks through a warning they didn't read. The biometric gate is re-run before every payment rather than trusting a single unlock, so authority to spend is never granted in bulk. Together they embody a simple principle for consequential actions: make the safe path the path of least resistance. A user who does nothing unusual sails through — a matched name and a glance at the camera — while the two situations that actually cause losses, paying the wrong account and someone else spending your money, each hit a hard stop. Building those stops into the flow rather than bolting them on as optional confirmations is what makes them effective, because the protection a user has to remember to enable is the protection they won't have when it matters.