Solution
Authenticated is not authorized.
Getting the payer in is not the same as them agreeing to this payment. What they saw on the approval screen is what their device signed, released by their own fingerprint or face.
The problem
Authentication settles who got in, not what they agreed to.
Every authentication step can complete correctly and the payment can still be one the customer never meant to make. The record afterwards says a person was authenticated; it does not say what they were shown, or what they agreed to send where.
Strong authentication at login
Phishing-resistant for the login itself, and then a session authorizes every payment after it. Nothing in that session is attached to any particular payment.
A confirmation screen in the app
Drawn by the same software that builds the instruction, from a second copy of the same values. That the two agree is a convention of the code rather than a check anything performs.
How it works
A step inside the flow you already run.
It sits between composing the instruction and submitting it. Your business logic does not move.
Your backend composes the instruction
Payee, amount and currency are what the approval will be made for, rather than decoration around a generic prompt.
The payer sees it on a surface you do not draw
The approval screen is rendered by the SDK, not by the application asking for the approval, and your application cannot change what it says once your backend has sealed it.
What they saw is what the device signs
Their fingerprint or face releases the signature, in the secure hardware of their own phone, and the approval carries the payment it was made for.
What the approval carries
The payment, not a pointer to it.
What holds on every path is that the payer's device signed what the payer was shown. What travels with the approval afterwards depends on whether you disclose the terms or keep them private, and the page says which is which rather than claiming both.
The same object, not two copies
Where your system discloses the terms, the payee and the amount on the screen are the payee and the amount inside the approval. There is no second copy of either for the two to differ over.
Or the terms never leave the phone
Where you keep them private, the approval still covers them without disclosing them. The page does not claim we verify a payee we were never sent.
Released by the person, in hardware
The signing key is held in Android's StrongBox or the TEE, or in the iOS Secure Enclave, and it will not sign until the payer releases it.
The boundary of the guarantee
Where this stops.
Stated here rather than discovered later, and the first one is the biggest.
A coached payer still approves
Someone persuaded to make the payment themselves will approve it, and the approval will be valid. Four scam categories are roughly 85% of UK authorised-push-payment losses in the UK Finance Half-Year Fraud Report 2025, and none of them is an authentication problem.
What changes is the record, not the outcome
You can show what the customer was displayed and what they approved, which is what a reimbursement determination turns on. That is a different thing from stopping the payment, and this page does not confuse the two.
It does not replace your fraud engine
Your models keep scoring. What they gain is a signal they cannot produce today: that the customer did approve this one, or that they did not. Scores route decisions; records settle questions.
See it on your own flow.
Your app, your call, our SDK.