ZIVA
Details and data below have been genericized to respect confidentiality.
Reducing checkout friction for cardholders, merchants and issuing banks through passkey authentication
I designed the passkey enrollment and authentication experience for cardholders at checkout, a flow that connects them with the merchants they buy from and the banks that issue their cards. The flow was built, and it helped make the case for a pilot with issuing banks.
ROLE
Solo lead product designer
SCOPE
Mobile browser, end to end
PLATFORM
Fintech transaction and checkout authentication
TEAM
About 12: head of product, 2 PMs, 2 dev leads
TIMELINE
About 6 months
THE PROBLEM
Cardholders were being stopped at checkout
extra verification step whenever a cardholder’s bank challenged them at checkout
We worked with clients around the world, and our head of product and PMs saw the trend in our authentication analytics, which track transaction and authentication data from merchants and issuing banks across our portals. Globally, a large share of cardholders were being stepped up to a second verification method (OTP or biometric) at checkout, triggered by their bank’s fraud rules.
That friction was costing purchases: abandoned checkouts meant lost revenue for both merchants and banks. Issuer clients were seeing the same climb in their own portal views.
THE GOAL
WHO I WORKED WITH
I was the sole designer on a team of about 12. I worked most closely with our head of product and two PMs, who brought the challenge-rate data and the client feedback, and with two dev leads, who shaped what passkey detection could and couldn’t tell us in real time. My role was to turn that data and feedback into a defined design problem, then into a flow the whole team could build from.
THE PROCESS
The central decision: enroll cardholders before checkout, or after?
BEFORE CHECKOUT · REJECTED
A gate
The prompt lands while the shopper is still typing card details, so the security upgrade competes with the task they actually came to do.
AT AUTHENTICATION · CHOSEN
A value-add
Decoupled from the purchase. For a first-time enrollee, enrolling is that purchase’s authentication, so no extra verification step is added.
AFTER CONFIRMATION · RULED OUT EARLY
Too late
The purchase is already authenticated, and shoppers tend to leave once they see “Order confirmed,” even when the offer is useful.
Low-fidelity wireframes of the three timing options. The prompt is nearly the same; what changes is the moment it appears.
Why this moment
People already have a mental model for this. Apple and Google offer to save a passkey after you’ve done what you came to do, not before. Following that familiar pattern (Jakob’s Law: users expect your product to work like the ones they already use) meant the prompt felt like a normal next step rather than a new hurdle, and the primary task, paying, stayed uninterrupted.
The prompt appears during authentication, before the confirmation page, so cardholders see it while they’re still in the flow. Prompting after confirmation was ruled out early for that reason: once people see their order confirmed, they tend to disengage. “Maybe later” keeps it optional, so it never stands between them and finishing the purchase.
One less screen
Most of my iteration was subtraction: a shorter flow, with fewer screens, to reduce fatigue. The flow originally opened with a full screen explaining how passkeys work, down to private and public keys. I proposed removing it and folding the essentials into the enrollment prompt: what the cardholder can do, and that they approve with a fingerprint or face. The team agreed, and enrollment lost a step.
Every branch ends at confirmation
The second decision was to make every branch finish the purchase. Before handoff, I mapped where the flow could break and gave each case a planned outcome, so engineering wasn’t left to guess.
EDGE CASE
MY CHOICE
1. Passkey detection isn’t ready in time.
I made the fallback a complete path instead of an error state, with no visible “checking” screen. Whatever the answer, the cardholder finishes the purchase.
2. Device data doesn’t load.
The flow defaults to the standard OTP path, so the cardholder can still finish the purchase without waiting.
3. A passkey is found, but the device can’t verify them.
“Authenticate another way” stays visible on the approval screen, so they’re never stuck on a failed check.
4. The cardholder declines enrollment.
“Maybe later” ends the offer, not the purchase. They continue straight to a standard one-time code.
The decision tree: detection uncertainty, fallback routing and the enrollment prompt, mapped end to end.
THE SOLUTION
Three states, one coherent flow
Passkey enrollment during authentication, passkey as the checkout step on return visits, and a seamless fallback to OTP or biometric when a passkey isn’t available.
01 · ENROLL
The enrollment prompt
The result of the timing decision: enrollment as an upgrade, not a gate.
Benefit first. The headline says what the cardholder gets, approving payments quicker, not how passkeys work.
Familiar unlock. It names fingerprint, face or screen lock, so they know what approving will feel like.
Optional by design. “Maybe later” instead of “No” keeps the door open without blocking the purchase.
02 · RETURN
Authentication on return
Where that decision pays off: no OTP, no typing, just the device’s passkey.
Informed approval. The amount and merchant are named, so the cardholder knows exactly what they’re approving.
Same page. The device prompt opens over the checkout instead of sending them somewhere new.
A way out. “Authenticate another way” stays visible in case the device can’t verify them.
03 · FALLBACK
Fallback OTP flow
When the cardholder declines enrollment, the flow routes to standard OTP or biometric verification, never leaving them stuck.
Their choice of channel. The cardholder picks email, SMS or the bank’s app.
Same ending. It finishes at the same confirmation as every other path.
OUTCOME
What it led to
Built. I handed the flow off to engineering, and it was built.
Supported a pilot. The flows helped make the case for a pilot with issuing banks, which was approved.
Became a shared reference. The team went on to use a version of the decision tree.
The flow was built to surface exactly where users engaged or dropped off, and how that connected to downstream conversion and adoption.
Was the passkey prompt shown?
Proceeded or fell back?
Conversion
Adoption
My role ended before final numbers came in, so I don’t have results to share.
Adopting a new authentication habit tends to build gradually rather than all at once, which is part of why I’d want to test enrollment timing further rather than treat it as the final answer.
Industry benchmark: passkey authentication succeeds 93% of the time, compared with 63% for other methods like one-time codes.
Source: FIDO Alliance, Passkey Index, October 2025
REVISITING WITH AI
Cross-device continuity
The original flow treated passkey availability as binary: detected, or not. Revisiting it with AI-assisted exploration surfaced a gap. A cardholder could have a passkey on one device and show up on another where it simply isn’t available locally, not because they never enrolled, but because the device changed.
The fix extends the decision tree to three tiers, keeping cardholders out of OTP unless they genuinely have no passkey at all.
TIER 1
Passkey on the device
Straight to authentication.
TIER 2 · NEW
Passkey known elsewhere
A hybrid QR flow lets them continue from their phone instead of falling to OTP.
TIER 3
No passkey anywhere
OTP or biometric, as before.
Tier 2 concept, not shipped. The laptop has no passkey, so it shows a QR code instead of an OTP. The phone that holds the passkey scans it and approves the same amount and merchant.
RETROSPECTIVE
What I’d test next
Test enrollment timing against data
I chose the authentication step by reasoning about interruption and familiar patterns. I’d test it against real behavior before calling it final.
Measure the decline
“Maybe later” is an explicit signal. How many decline, and does re-offering on a later purchase change adoption?
Validate the cross-device tier
Confirm device switching is common enough, and QR fast enough, before building it.
Extend to desktop
The flow was designed for mobile browsers. I’d adapt it for desktop, where the biometric sheet and redirects behave differently.
FULL CASE STUDY
Want the full story?
The detailed case study covers the full flows and design rationale in more depth. I’m happy to share it, or to walk you through it on a call.
NEXT PROJECT
Issuer groups →
Issuer portal · Complex settings