VerifyYou confirms that a real, unique, live human is on the other end, in seconds, without ever showing you their face, asking for a government ID, or touching any personal data. You get a clear trust signal, and you make the call. This guide walks your team through the dashboard: how to set up your human checks, watch what is happening, and support your own users.
Here is the thing we want you to know first. You do not collect a government ID, you do not store a pile of personal data, and there is no photo of anyone's face sitting in your account. VerifyYou confirms that a real, unique, live human is on the other end of an action on your site, and it does that in seconds without ever handing you an image. You get a clear trust signal back, and you decide what to do with it. This dashboard is where your team sets up those checks, watches what is happening, and supports your own users.
It helps to be plain about what we prove. We confirm a live, unique human. We do not confirm the name. That is on purpose. You hold far less sensitive data and still get a confident read on who is real before you let them through.
What a human check actually does
A human check is the step you put in front of an action, and it asks two quiet questions. The first is liveness, which confirms a real person is present right now, not a photo, a recording, or a deepfake. The second is uniqueness, which confirms this is one human with one account, so the same person cannot register twice under different names. When someone returns later, they prove both again against the record we already hold, so returning users move through quickly instead of verifying from scratch. The first check does the real work. After that, we recognize them automatically.
You see a signal, never a face
We hold each person's identity as a face hash, which is a one-way number, not a name attached to a picture. No one can recover the original face from it. It is useless to anyone who copies it, and that includes us, so there is nothing sensitive sitting in your dashboard. What reaches you is the signal and the data around it, never the image. Your team works from that signal plus everything you already know about your own customers, the same way you weigh any access decision.
You decide
We run the platform, and you own the outcome. The check gives you a trust signal, and you decide who gets through, because it is your user and your product. When a real person cannot get through, you can step in and clear them yourself from the dashboard, with no engineering involvement from us. That whole loop stays with you: someone could not get through, you look, and you decide. We explain exactly how it works in Support, your way and The override.
What this dashboard is for
You will do three jobs here. You will set up your checks, choosing how each one behaves and where it appears. You will watch activity, seeing how people move through a check and what is happening across your account. And you will support your own users, finding any one of them fast and guiding them through when they need help. Every new account starts in sandbox so you can test freely, and you switch to production when you are ready to go live.
The rest of this guide covers all of it one piece at a time. New here? Start with Get started in your first session. If you are looking for something specific, Search and the activity log and The user detail view are where most support work begins. We are happy to walk through any of this live if that is easier. Just let us know.
There is nothing heavy to set up first. We do not ask for a government ID, we do not collect personal information, and we do not store a photo of the person. The face becomes a one-way number, called a face hash, and the original face cannot be rebuilt from it. You accept an invite, you land in your dashboard, and in about twenty minutes you will have tried the human check yourself and pointed it at a real action on your site. The steps below run start to finish. You can stop after one decision, or work through every setting, whichever suits you.
The check gives you a trust signal. It confirms a live, unique human, not a name or an identity. You decide what to do with that signal.
1. Accept your invite and sign in
You will get an invite by email, and accepting it takes you straight into your dashboard. Sign-in is handled for you, so there is nothing to set up before you can look around.
2. Land in the dashboard, in sandbox
Every account starts in sandbox, which is simply your space to test the integration without touching anything live. The first thing you see is the Dashboard, your home screen, with your account details, a few helpful links, and a clear route into your first integration. You may notice some sample data here so the screen is not empty. Once real checks start flowing, this is where you read your activity at a glance. For the deeper view, with the funnel, drop-off, and volume, open Logs and metrics.
3. Your first verification is already set up
You do not open to a blank page, because we have created your first verification for you. Your company name is filled in, and a redirect already points back to your site. It usually defaults from your email domain, so it works without any setup. You will find it waiting under Flows and verifications, ready to run or ready to edit.
4. Try the human check yourself
Before you do anything else, try the check the way your users will. You can scan the QR code, open the verification link, or send it to your phone or a teammate. You will see the whole flow, in your brand. It confirms a live, unique human in a few seconds. This step is optional, but it is the quickest way to understand exactly what you are shipping before you ship it.
5. Set your preferences
Now you make the check yours. You choose your account method, decide whether to require sign-in or let guests through, set how often returning users redo the check, and confirm where they land afterward. Sensible defaults are already in place, so none of this blocks you, and you can adjust as much or as little as you like. Verification settings covers the full set of controls when you want them.
6. Put the check in front of an action
There are two ways to go live, and you can pick whichever fits your team:
No-code: add the verification link or QR code, and that is the whole integration.
With code: the API is small, and your Integration page gives you copy-paste instructions already filled in with your own details, so your first call runs in seconds.
When everything looks right, you switch your instance from sandbox to production. Your sandbox test data stays separate from your live data, so going live starts clean and the numbers you read from your first day are accurate.
A flow is one human check. It is the check you put in front of an action on your site, so a live, unique person clears it before they continue. There is no government ID to upload, no PII for you to collect, and no photo stored anywhere. The check works from liveness and uniqueness, not from a photo. Some people call a flow a verification. The two words mean the same thing, so use whichever you prefer.
You can run several flows at once. Each one guards a different action and carries its own settings, so the check that protects a survey can be lighter or stricter than the check that protects a checkout. You decide what each moment on your site is worth, and the flow does the checking.
A flow tells you that a live, unique human cleared the check. It does not confirm who that person is by name. It is a trust signal, and you decide what to do with it.
Your first flow is ready
You do not start from a blank page. Every new account comes with a flow already set up for you. When you open Flows, it is waiting there with your company name and a redirect filled in, so you can try the check right away or start shaping it to fit.
How a flow gates an action
Each flow gives you a verification link and a matching QR code. You place either one in front of whatever you want to gate, whether that is access to your site, a survey, a task, or a checkout. The person reaches the check, proves in seconds that they are a live and unique human, and then moves on to wherever you send them next.
You decide how often the link appears, and that choice sets how often a check actually runs. You can show it once at the start, or bring it back at the points that matter most to you. You guard the action, and the flow handles the proof.
Where flows live
All of your flows sit in the Flows area of the dashboard. From there you can see every flow you have running in one place, create a new flow for a new action you want to gate, or open an existing flow to edit it. Editing opens a settings panel, with an Advanced section for when you want finer control. Every flow you create comes with its own link and QR code, ready to place wherever you need it.
Before the controls, here is what matters most. A human check never asks your users for a government ID, and we never collect or hand you the usual personal data you would otherwise have to store. There is no photo kept anywhere. We hold only a one-way face hash, which is a number, and the original face cannot be recovered from it. That makes it useless to anyone who copies it, including us. When you open the settings on a flow, you are not deciding how much sensitive data to gather. You are deciding how the check behaves, what little it asks for, and how often it runs.
Here is the simple way to think about it. We confirm a live, unique human on the other end, and you pick the signals and the strictness that fit the action you are guarding. Every flow ships with sensible defaults, so a new check works the moment you place it. You open these controls only when one flow needs something tighter or lighter than the rest.
Where to find them
Settings live on the flow itself. Open Flows, click the verification you want to change, and open the Advanced section, where the finer controls sit. A global configuration applies across all of your flows, so you can set your house rules once and have every check follow them. You can then open any single flow and override a setting just for that one. The override stays local to that flow and leaves the rest alone.
Account method
Here you choose what identifier a user gives: email only, phone only, or either one. We recommend asking for at least one, and we suggest email, because it ties a verification back to your own records. When someone reaches out for help later, that identifier is how your team finds them and acts. You can read how that lookup works in Search and the activity log.
A phone number is also useful for a returning person. It works a bit like a credential they keep, so they do not have to introduce themselves from the start every time. The work is in the first visit. After that, you are recognizing continuity, not verifying identity from zero.
Sign-in, guest, or members only
This setting decides who is allowed through the check. You can require sign-in, so everyone has a persistent member account. You can allow guests for a lighter, anonymous pass. Or you can restrict to one or the other (members only, with no guests at all).
One thing is worth knowing before you choose. Member accounts are what make support, search, and moderation possible, because a member is someone you can look up, review, and act on. A guest leaves nothing behind to search for, so a guest-only flow gives up those tools. If support and overrides matter for the action you are guarding, and for most actions they do, require a member account. The detail view your team works in is covered in The user detail view, and the moderation itself in The override.
Reverification frequency
You set how often a returning user redoes the check, per flow, based on what that link is guarding. A high-stakes action can ask every time, while a lighter one can ask far less often. That is your call.
One point is easy to misread, so let me be clear about it. A valid session can let a returning user skip the login step, but it never lets them skip the actual proof. They still pass liveness and uniqueness every time, matching one to one against the face hash from their first visit. We never carry the human check on a cookie. The session carries only the convenience of not logging in again.
Redirect URL
Set where the user lands once the check is done, and point it at the page or action the flow is protecting. Your first flow usually has this prefilled from your email domain, so it already points back to you, but you can change it on any flow whenever you like.
When you need to step in
Most checks resolve on their own, but every now and then a real person cannot get through and reaches out. Your team handles that from the Activity Log: search by the phone number they gave, open the user, choose Override Trust, and change the result by hand. You are working from the full per-user data set there, so you have what you need to make the call, and there is no seat limit on who can do it. Everyone on your team can be in there. For a single-user account, an override is always a deliberate manual step, never something the system does on its own.
It helps to know how a denied result reaches you in the first place. When a check is denied, where it goes depends on the state of the system. If you have set a support link, the person is routed there. So set that support link on your flow and route to it rather than the fallback, so anyone who could not get through lands somewhere your team is watching.
The human check is the moment a real person proves they are real on your site, and it should feel like part of your product. There is no government ID to upload, no PII for you to hold, and no photo stored anywhere, so the only thing to set is how the check looks. That is what branding is for. You add your logo and set your look, and the check carries your name and your style the whole way through.
Set your brand
In your dashboard, you upload your logo and set your brand. The check picks up your look, so the experience feels native to your site and the person on the other end sees you, not us. This is your check, in your brand.
Set it once, and it carries
Branding is a company-wide setting. You set it once and it applies everywhere. Every human check you put in front of an action shows the same logo and the same look, so the experience stays consistent wherever you use it. Any new flow you add later picks up your brand on its own, with nothing to set again. For how flows fit together, see Flows and verifications.
There is no government ID here, no stored personal data, and no photo of anyone. What you get instead is the full read on one person, opened straight from your Activity Log. That is everything your team needs when a user reaches out and you have to make a call.
Every verification event a user generates lands in your Activity Log. Open one of those events and you see that person's detail view. Your support and audit teams work in this page every day, because it brings a user's whole history into one place and gives you the record behind any decision you make. To get here, you search the Activity Log by phone and open the user. We walk through that in Search and the activity log.
What a single user shows you
Open a user and you see the complete picture, organized so you can read it quickly.
Identity and status. Their VerifyYou user ID, phone number, location (city and country), member status, and current trust score.
Verification history. Each flow they went through, the result (verified or denied), the platform and browser they used, their first and last verified timestamps, and their total verification count.
Liveness and uniqueness signals. Whether liveness passed, the confidence score against its threshold, whether the face matched the one they enrolled, the face-uniqueness collision count, and their recent liveness attempts.
Devices. Device ID, type, platform, browser, when each was last seen, how many devices you know for this person, and any new-device events.
Network and technical signals. Client IP, geo (city and country), user agent, accept-language, TLS version and JA3/JA4 fingerprints, origin and referer, and client-hint headers.
Trust snapshot. A composite score from 0 to 100, the attributes we have (location, age, gender where present), activity (first verified, last seen), known devices, partner count, and plain-language signals like "liveness confirmed on first check", "no uniqueness collisions", "consistent device history", or "new device added".
That is the complete picture you would use to admit or deny any individual, and none of it is a face or a photo. The face is stored only as a face hash, a one-way number. The original photo cannot be rebuilt from it, so it is useless to anyone who copies it, including us. You read the signals and that hash, and you still know what you need to know: this is a live, unique human. We confirm that they are real, not that they are who their name says. The decision is yours.
Acting from here
When a check denied someone you believe is legitimate, this is also where you fix it. From a user's detail view you open Override Trust and change the result, and you make that call with all of the above in front of you. The full steps, including requiring re-verification for someone you previously approved, are covered in The override.
Members, not guests
You can look up and act on member accounts only, meaning users who verified with account-based credentials like a phone number. A guest is anonymous and leaves nothing to search for, so there is no detail view to open and nothing to override. If support matters for the action a flow guards, require a member account, which you set in Verification settings.
When someone contacts you because a check didn't pass, you don't need a government ID, a copy of their personal data, or a stored photo to help them. You need the phone number they gave you. That one identifier links a person who emails you to a real record in here. The activity log is where you make that link. It is the running record of every verification event on your account, and it is where your team searches for a person, opens them, and decides what to do.
A support request stays simple. Someone contacts your team, gives you their phone number, you find them, you open them, and you make a call. The activity log is the screen that holds all of this in one place.
Every event lands here
As checks run, the activity log fills in on its own. You get a live, time-ordered feed of what is happening: a verification that completed, a result that came back denied, a re-verification, a new device on a known account, and so on. Read it from top to bottom to see the pattern of your traffic, or go straight to one person.
Find a user
The fastest way in is to search. Open the activity log, search by the phone number the user gave you, and open them from the results. That takes you to their detail view, which is the full picture of who they are and how their checks have gone. It is also where you act when someone needs help. When you decide to let someone through, you do it right there with Override Trust. Override Trust lets you change the result for that one user and, if it is the safer call, require them to verify again.
Search works on member accounts, which are the users who verified with an account-based credential like a phone number or an email. That is why an identifier matters. Anonymous guests do not carry an identifier you can search, so they will not appear in a lookup. If you want every support request to be findable, require an account method on the flow. You can read about that in Verification settings.
When a user needs help, the person they want to reach is you, inside your product. That is the whole idea. You run support for your own users in your own voice, we run the platform underneath, and the dashboard gives your team what it needs to find a person and make the call. The user never has to work out who to email or what went wrong, because the system already knows where the question belongs and sends them there.
The system routes the user, so they don't have to guess
A user reaches the outcome screen without getting through for one of two reasons, and each one goes to a different place.
If the check errored or never returned a result (the page didn't load, the camera failed, the server didn't respond, or no decision came back), that is on our side. It routes to us and our help docs. We would rather fix our own problems than send them to you.
If the check ran and returned a denial, that is a decision only you can change. It routes to your support. You are the one who can read the full picture and decide to admit someone, so the appeal comes straight to you.
Both links sit on the check itself, because that is the one surface that knows which company the user came from. Our help docs stay generic on purpose. They cover how the check works, how to troubleshoot, and a note to contact the company that sent the user here. They never carry your link, which keeps the two paths separate.
Set your support link
You set your support email or link once in the dashboard, and it applies across every flow, so there is nothing to repeat per check. Send us the email or link you want users to reach when they want to appeal a denial, and we will set it for you. Genuine technical problems with the check still come to us, so the only cases that reach your team are the ones you can decide.
Here is the part worth underlining. If you have not set a link yet, the copy still tells the user to contact the company that sent them, by name. We are never the default fallback for your users, so the path always leads back to you.
One real person, versus everyone at once
These two cases feel similar, but you handle them very differently, and it helps to know which is which.
A single real person the check denied is always a manual call. You open them, read the signals, and decide to let them through yourself. We never admit someone automatically just because they were denied, because that would turn the product into a self-serve bypass a bad actor could trigger on purpose. So for individual cases, the loop is simple. The person couldn't get through, you take a look, and you decide. It stays fully in your hands.
A wide outage, meaning we are down and nobody can verify at all, is a question of continuity, not fraud. You decide ahead of time what your site does in that window, whether that is blocking everyone or letting people through. If you let them through, everyone who comes in during the outage is marked provisional and has to pass liveness and uniqueness for real on their next visit. We never waive the check, we only postpone it.
Making the call, with the user in front of you
Once a user reaches your team, the dashboard does the rest. Look the person up in the Activity Log by phone, open them, and you land on their full record, the complete per-user picture you would use to make an admit or deny call on any individual. From there, if you decide to let them through, you change the result on the spot with Override Trust.
To be clear, we never tell you who to approve. It is your user and your call. We give you the signals and the tools, you decide where the line sits, and seats are unlimited, so everyone who needs to make these calls can. The check confirms a live, unique human, not a name, so the final decision is always yours. Happy to walk through any of this live if it helps.
Sometimes a real person cannot get through a check, even though you know they are legitimate. They reach out, your team takes a look, and you decide to let them in. That whole loop, where they couldn't get through, you check, and you decide, stays with you. It runs from your dashboard, with no engineering work from us. The check gives you a trust signal. The override gives you the final say.
This is a real responsibility, so we have written this article plainly. Read it the way your reviewers will use it.
Two things you can do
An override is your call on your user, and it works in both directions. You can approve someone the check denied, so a person who couldn't get through can proceed with your company. You can also require re-verification for someone you approved before, when something about their standing makes you want a fresh look. Same place, same action, whichever way the decision needs to go.
The path
Everything you need lives in the Activity Log. Every verification event lands there, and that is where you find any individual user. Search the user by phone, open them, and you will see the full detail view. It shows their identity and status, their verification history with the result of each check (verified or denied), the liveness and uniqueness signals behind that result, their devices and network signals, and a trust snapshot scored from 0 to 100 with plain notes like "liveness confirmed on first check" or "new device added." That is the complete picture you would use to make an admit or deny call on any individual. For what each part means, see The user detail view, and for the search side of it, see Search and the activity log.
When you are ready to act, choose Override Trust from that user's detail view and change the result. So end to end, the path is short: open the Activity Log, search by phone, open the user, and choose Override Trust.
It's scoped to you
An override only changes that user's standing with your company. It does not change how they stand across VerifyYou or with anyone else in our network. You are making a call about your user on your platform, and that is exactly as far as it reaches.
A few more things to know. Overrides work on member accounts only, the ones with account-based credentials. To act on someone, you first have to find them, and a guest leaves nothing to look up. If you want support and overrides available for a flow, require a member account in Verification settings. Seats are unlimited too, so put your whole support or CS team in the dashboard to work these cases. There is no cap.
Where the override fits, and where it doesn't
Two situations look similar but are different, so we keep them apart.
The first is a single legitimate person the check denied. That is always a manual override, the kind described above, never an automatic pass. We keep it manual on purpose. If denied users could admit themselves, the check would become a bypass that a bad actor could trigger on purpose. So the decision stays a deliberate one you make with the full picture in front of you.
The second is an outage, when VerifyYou is briefly down and nobody can verify. That is a continuity question, not a fraud one, and you configure it ahead of time. You choose whether, during an outage, your site blocks everyone or lets people through. If you let them through, everyone who comes in is marked provisional and has to pass liveness and uniqueness for real on their next visit. We never waive the check. We postpone it. For how users reach you in the first place, and how that routing works, see Support, your way.
Supporting users responsibly
You are reading a trust signal and a one-way face hash, never a photo. The face hash is a number, and the original cannot be recovered from it, so this is privacy working as designed. It also means the call is genuinely yours, made with your own context on top of the signal. We never tell you who to approve. Decide the way you would for any access decision: read the signal, add what you know about the user and the situation, and follow your own policy on when to extend access. Because your reviewers cannot see images, be deliberate rather than approving everyone who asks. Support is a real point of trust, and the override is a real control.
Write down your override policy
Decide in advance when your team should override and when they should not, and put it in writing so every reviewer makes the same call.
Our override policy
Override when:
Don't override when:
Escalate to (name or team):
Keep this somewhere your support staff can reach, and revisit it as you learn what works for your users. We are happy to walk through any of this live if it helps.
Two views show you what is happening across your traffic, and neither one stores a photo. The Activity Log is the session-level record, where every verification event is saved. Insights is the summary: the funnel, the drop-off, and the volume across everything moving through VerifyYou. Both show you signals and a one-way face hash (a number, never a face), so you hold less sensitive data and still see exactly what is happening.
Here is a simple way to keep them apart. The Activity Log answers "what happened to this one person." Insights answers "how is the whole thing trending." You use one or the other depending on the question you are asking.
VerifyYou gives you a trust signal. You decide what to do with it.
The activity log, every event in one place
VerifyYou saves every verification event in the Activity Log, so you have a running, auditable record of your traffic. That includes a verification that came back verified, a denial, a re-verification, or a new device. Each entry is one moment in one person's history, and the log is where they all collect.
You can use it three ways. To confirm your integration is set up correctly, run a check, find the event in the Activity Log, and see exactly what came back. To trace a single session when you need the detail behind a result, open the event and read the result the way your integration received it. To keep an audit trail, you can rely on every event being recorded, so you can review any decision later with the full context still in front of you.
When someone contacts you and you need their full history rather than one event, search them by phone here and open them. That takes you to the per-user detail view, covered in The user detail view, and the search itself is covered in Search and the activity log. From that view you also have the override path: if a result needs correcting, you can change it directly and pick the new result yourself.
Insights, the funnel and the trend
Insights is your high-level read on all of your traffic. The verification funnel shows how people move through a check: the ones who start, where some stop along the way, and the ones who get through. So drop-off is easy to see instead of buried in individual events. Next to the funnel, you also see the shape of your verification volume and your user base over time, which is the live view of everything moving through VerifyYou.
Open this page when you want the trend without reading every entry. When a single number raises a question, go back to the Activity Log for the session-level detail, or open a user for the full picture in The user detail view.
Sandbox and production stay separate
While you are still testing, your instance runs in sandbox, and those test events stay separate from your production data. They never mix into your live Activity Log or your live Insights. When you switch to production, your real traffic flows in on its own, so the numbers you read are always your real numbers. For more on making that switch, see Get started in your first session.
One last note on what the signal means. VerifyYou confirms a live, unique human, not the person's name. You decide how to use that.
There's nothing complicated to set up here. There's no government ID to collect, no PII to store, and no photo to keep, so going live is mostly a matter of choosing how you want to place the check. There are two ways to put a human check in front of an action on your site. One needs no code at all, and one uses our small API. Both reach a working check quickly, so pick whichever fits your team. Most companies start no-code to see the check live in their own brand, then move to the API when they want it embedded deeper in a product flow.
Every flow gives you a verification link and a matching QR code. To go live, you place that link or code in front of whatever you want to gate, whether that's a page, a survey, a task, or a checkout. The check opens, the person proves they're a live, unique human, and they continue to wherever you send them next. There's nothing to build and nothing to deploy. And because you decide how often the link appears, you also decide how often a check is enforced.
With code
The API is small. You start a check by initializing a verification, read the result back (verified or denied), and act on it. That's the whole shape of it.
You don't have to work it out from a blank page. The Integration page in your dashboard gives you copy-paste instructions, already filled in with your own account details. You copy the snippet, add your auth token, and your first call runs from your terminal in seconds. From there, you add the check to your flow at the points that matter to you. Keep the Integration page open as you go, since it carries the exact calls for your account, so you're never guessing.
Going live
You build and test everything in sandbox mode first. Once the check behaves the way you want, you switch your instance from sandbox to production to go live. Your test attempts stay separate from your real traffic, so the numbers you read after launch are the real ones. You can see this reflected in Logs and metrics.
A few of our words have a specific meaning, so here is a plain reference for the terms you will see across the dashboard and the rest of this guide. One idea sits under all of them. We prove there is a live, unique human on the other end, and we do not prove the name. There is no government ID, no PII for you to store, and no photo kept anywhere, and everything below is built around that.
Human check
The check you put in front of an action on your site. It confirms a real, unique, live human in seconds and hands you back a result, so a genuine person clears it before they continue. Some people say "verification" instead, and it means the same thing. For how to set one up and place it, see Flows and verifications.
Liveness
Proof that a live person is present in the moment, not a photo, a recording, or a deepfake. It is one of the two things every human check confirms.
Uniqueness
Proof that this is one human with one account, so the same person cannot sign up twice. Liveness and uniqueness together are what a human check confirms, and a returning user proves both again against the face we already hold.
Face hash
This is how we hold a person's identity. We turn the face into a one-way number and store that number, never a name attached to a picture. The original face cannot be recovered from it, so what we keep is useless to anyone who copies it, including us. A returning user can still prove they are the same human with a one-to-one match. You read signals from it and never see a face. In the data, you will see this described as a face hash, or as a liveness and uniqueness signal.
Trust signal
The result a check hands back, verified or denied. That is the read you act on. You get the signal, you make the call, and the user stays yours.
Trust score
A single number from 0 to 100 that combines what we know about a user: their attributes, their activity, their known devices, and plain-language notes like "liveness confirmed on first check" or "new device added". It sits on the user's detail view as a quick read on where they stand with you. For the full picture behind it, see The user detail view.
Session
One verification attempt, from start to result. Sessions land in your Activity log, where you can open any one of them to see the data behind it.
Member vs guest
A member keeps an account-based credential with you, an email and/or a phone, so you can look them up, read their history, and act on their result. A guest goes through anonymously and leaves nothing to search for. Support, search, and the override all need a user you can find, so member accounts are what make those tools work. Require one on any flow where support matters. See Verification settings.
Sandbox vs production
Sandbox is the testing mode every new instance starts in, your space to set things up safely. Production is live. The two never mix, so your test data stays out of your real numbers. There is more on the switch in Get started in your first session.
Flow
A configured human check, set up for a specific action you want to gate. You can run several at once, each with its own settings and its own link and QR code, so the check guarding a survey can differ from the one guarding a checkout. See Flows and verifications.
Override Trust
The action you take to change a result by hand. The path is the same every time. Open the Activity log, search the user by phone, open them, and choose Override Trust to change the result. From there you can approve a user a check denied, or require re-verification for a user you had previously approved. It is your call on your user, made with the full data in front of you, and it touches only their standing with your company. See The override.
Provisional
A temporary status we use for continuity, not for fraud. If you have set your site to let people through during a VerifyYou outage, everyone who comes in then is stamped provisional and has to pass liveness and uniqueness for real on their next visit. We never waive the check, we just postpone it. There is more on outage behavior in Support, your way.
Redirect
The page or action a user lands on once a check completes. You point it at whatever the flow guards, and you set it per flow.
These are the questions companies ask us most, with short answers, and each one points back to the fuller article if you want the detail. The best way to use this page is to read it once so you know where each answer lives, then come back when a specific question comes up.
Before any of the rest, here is one line worth keeping: we prove there is a live, unique human on the other side of the check. We do not prove the name, we do not ask for a government ID, and we do not collect or store PII to do it. Everything below follows from that.
Do we ever see our users' faces or photos?
No, and that is by design. There is no stored photo, and nothing for you (or anyone who breached you) to look at, because the face lives only as a face hash. A face hash is a one-way number: the original cannot be recovered from it, so it is useless to anyone who copies it, including us. What reaches your dashboard is a trust signal and the result of the check, verified or denied, which is the thing you act on. So you get everything you need to make a decision about a user, and you never get a picture of them. The user detail view walks through exactly what that signal looks like up close.
Can we run our own support?
Yes, and most companies do. You set your support link once in the dashboard, and then your team handles your users with the same tools we use: search, the user detail view, and the override. The loop where a user could not get through, you check, and you decide is fully in your hands, with no engineering work from us. Support, your way covers the setup, and it is the article to read closely if support is your main question.
What happens when someone cannot get through a check, but you are sure they are legitimate?
You override it, and the path is short. Go to Search and the activity log, search the user by their phone number, open them, choose Override Trust, and change the result. You see the full picture when you do: the liveness and uniqueness signals, their device and verification history, and the whole trust snapshot. So it is a real decision with real context rather than a guess. That is always a manual call by you, never an automatic pass, and there is a clear reason for that: if a denied user could let themselves in, the check would just become a way around itself that a fraudster could trigger on purpose. The override has the step by step.
Who handles support, you or us?
It splits by what the system already knows, so your user never has to work out the cause themselves. If the check errored or never returned a result, meaning the page did not load, the camera failed, a server error happened, or no decision came back, that is our side, and it routes to us and our help docs. If the check ran and returned a denial, that is a decision only you can override, so it routes to your support. Both links sit on the check itself, which is the one surface that knows which company the user came from. The only thing we ask is that you send us your support email or link, and we set it for you. Support, your way lays out the full routing.
Can one person make several accounts?
No, and that is the uniqueness check at work. Every verification confirms that one human maps to one account, and when a user returns they re-prove liveness and uniqueness against their existing face hash, a one-to-one match. So the same person cannot open a second account, and a returning user reads as continuity rather than a fresh identity, because the work happens on the first check. Flows and verifications explains how the check runs.
Should we ask for email or phone?
Either works, and you can ask for both. The thing to think about is which identifier your team will actually use to find someone later, because that is what you search on. We lean toward phone, since that is how you look a user up in Search and the activity log, but pick whatever your support team already has on file. You set this in Verification settings.
Should we allow guests or require members?
It comes down to whether you need to look people up afterward. If your team needs to find a user, override a result, or support them, require member accounts, because those are the account-based credentials you can search and act on. Guests are fine for a lighter action where you do not need that record, but you cannot look up an anonymous guest, so search and override will not reach them. Verification settings is where you choose.
If we override a user, does it change them anywhere else?
No. An override is your call on your user, and it only changes how that person stands with you. It does not touch how they stand with VerifyYou or with any other company on the network, so the decision is yours and it stays inside your business. There is more on the scope in The override.
How many people on our team can do this? Is there a seat limit?
No limit. Seats are unlimited, so you can give your whole CS or support team access to work moderation without thinking about a cap. Support, your way and The override are the two articles your team will use most.
What is the difference between sandbox and production?
Sandbox is for testing your integration, with test data kept fully separate from real activity. Production is live, with real users and real results. New accounts start in sandbox, and you switch to production when you are ready to go live. You can watch both in Logs and metrics, and the walkthrough is in Get started in your first session.
What happens if VerifyYou ever goes down?
You decide ahead of time, because this is a continuity question, not a fraud one. You configure whether, during an outage, your site blocks everyone or lets people through. If you let them through, everyone who comes in is stamped provisional and has to pass liveness and uniqueness for real on their next visit, so we never waive the check, we just postpone it. You set this behavior in Support, your way.
If a question here does not quite fit your situation, just reply and we will help, and I am always happy to walk through any of this live.