Where verification flows lose people, and how to fix each step

Verification flows lose people at a handful of predictable moments: an opening screen that does not explain why they are being asked, the camera permission prompt, document capture (glare, blur, the wrong side), starting on a desktop that has no usable camera, and being asked to repeat the entire flow after one step failed. Each has a specific fix. A common mistake is treating drop-off as one number and redesigning the whole flow in response.

So measure first. Find the step where people stop, look at what that step asks of them, and change that step. Then measure again.

How do you find where people leave?

A single completion rate tells you there is a problem and nothing about where. You need abandonment per step, and a clear line between people who never opened the flow and people who opened it and walked away. Those are different problems: the first is about how you invite people, the second is about the flow itself.

Instrument four moments:

1. Invited but never opened. A delivery problem: the link went to spam, arrived at a bad time or looked like phishing.

2. Opened and left. A flow problem. Record the last step reached.

3. Returned later. Evidence that people want to finish but were interrupted; resumability matters.

4. Submitted. The flow has done its job; what happens next is about the result, not abandonment.

Compare steps against each other and against themselves after each change. Changing three steps at once leaves you guessing which one helped.

Which steps lose people, and what fixes each one?

The opening screen

People leave when they do not know who is asking, why, or how long it will take. A generic "Identity Verification" heading in a flow that appeared out of nowhere reads like a scam.

• Name your organisation and the reason in plain words: "To open your account, we need to confirm it's you. It takes a few minutes, and you will need your ID."

• Tell people what to have ready before they start, not halfway through.

• If your own app has already explained and asked for consent, avoid asking twice.

Contact codes

A one-time code to an email address or phone number is a cheap way to filter fake contact details before more expensive steps. It also adds a step and depends on message delivery. Use it where contact details matter to you, place it early, and make "resend" easy to find.

Choosing the ID

A long list of every document your provider supports makes people guess. Offer only the IDs your product accepts for their country, put the most common first, and say in one line what each needs: a number only, or a photo of the card.

Camera permission

A denied camera prompt is one of the hardest places to recover, because browsers and phones rarely let you ask again. Before the prompt, say why the camera is needed. If it is denied anyway, show how to switch it back on (on mobile, a button to open settings) and, for document capture, offer an upload from the gallery as an escape route.

Document capture

Glare on laminated cards, blur and the wrong side of the card are common reasons for a retake. Detect lighting problems live and tell people what to do ("Move away from the light", "Hold still"), rather than rejecting the photo after submission. Show which side is needed with a picture, not a sentence.

Liveness

People fail liveness when the instructions are unclear or the setting is wrong: a second face in the background, a dark room, a phone held too close. Clear, short prompts help, and so does pausing (rather than failing) when a second face appears and resuming when it leaves.

Starting on a desktop

Someone who opens a link on a laptop, finds the webcam unusable and has no easy way to move to their phone will often give up. Offer a QR code that lets them continue the verification on their phone.

Form fields people cannot answer

Every required field is a potential dead end. A clear example is a mandatory house number for someone who lives in an unnumbered compound. If some honest applicants cannot answer a question, make it optional, and let the rest of the evidence carry the decision.

Being sent back to the start

When a verification fails on one step (a dark selfie, a blurry document), asking the person to redo the entire flow punishes them for everything they got right. Send them back for the failed step only, with a sentence explaining what to do differently.

The wait after submitting

Results that arrive asynchronously are normal. What loses trust is a success screen that promises nothing, followed by silence. Say what happens next and how they will hear, then keep that promise.

A worked example

In an illustrative review, a lender's onboarding flow, examined step by step, shows that people who open the link on a laptop leave at the document step far more often than those on phones, and that most failures after submission are selfies taken in poor light. The team makes two changes, one at a time: first the desktop-to-phone QR hand-off, then a targeted redo that asks only for a new selfie with a line about lighting. Each change is measured against the previous week's per-step numbers before the next one ships. Nothing else in the flow changes.

The point of the example is the method, not the figures: two small, measured changes to the two steps the data pointed at.

How Myaza Trust helps you measure and fix drop-off

For measurement, session webhooks separate session.expired (a session nobody opened) from session.abandoned (opened and left without submitting), with session.resumed when someone comes back and verification.started at submit, all sharing one id. Before submission, the status endpoint reports an in-progress attempt with its current step and captured items, and hosted pages running inside a WebView or iframe post step events to your app. See the webhooks documentation.

For the fixes, the SDKs retry failed uploads automatically, show a camera-access screen with an Open Settings action on mobile and a gallery fallback for documents, pause liveness when a second face appears, and give live lighting guidance. Hosted links offer desktop visitors a continue-on-your-phone QR code. Consent and success copy are editable, and the consent screen can be switched off when your app has already asked. When a verification needs another attempt, you can send the applicant back for specific steps only, and the verification keeps its id. Because flows are workflows, you change a step by re-publishing, without an app release, which makes one-change-at-a-time testing practical.

A drop-off review checklist

• Measure per step, and separate never-opened from opened-and-left.

• Rewrite the opening screen to name who is asking, why, and what to have ready.

• Offer only the IDs you accept, with the common ones first.

• Explain the camera before the prompt, and give a recovery path after a denial.

• Guide capture live instead of rejecting after submission.

• Offer a phone hand-off to desktop visitors.

• Remove required fields some honest applicants cannot answer.

• Send failures back for the failed step only.

• Tell people what happens after they submit.

• Change one step at a time, and measure each change.