Human verification.
A short camera check that asks something a recording cannot answer, scored away from the device, returning a result your backend can act on.
Capture
A short check in the browser
Analysis
Server-side, never on the device
Delivery
A result your backend can trust
What comes back
Click on any stage to see what it covers
What your user actually does.
The check is something a customer has to get through on a phone, in a hurry, possibly annoyed. Most of the engineering is spent there rather than on the detection.
They agree first
The check opens by saying what it is about to do and asking permission. Nobody is recorded by surprise.
A few prompts, at random
Three or four short prompts, drawn fresh when the session opens. Nothing to install, nothing to upload, and no document needed unless you asked for one.
Under a minute
A typical check is over in well under a minute, including the guidance that helps somebody hold their camera somewhere useful.
Told what to fix
If the room is too dark or the camera too far away, the person is told while it is still fixable, rather than failed afterwards for it.
Three ways a check can fail. Only one of them is evidence of fraud.
A single score that collapses fraud, confusion and a bad webcam into one number cannot tell you what to do next. Ours keeps them apart, and says which one happened.
Evidence of fraud
The medium is wrong
Evidence that what is in front of the camera is not a live person in a room. This is the only class that adds a penalty of its own, because it is the only one that says anything about fraud.
Counted once
They did not do it
The person did not perform what was asked. The score already measures that directly, so it is not charged a second time as a risk factor. One mistake is counted once, not twice.
Not evidence of fraud
We could not measure
Our own measurement failed: too few usable frames, a bright window behind them, a poor connection. It is never counted as evidence of fraud. With too little to measure the check is usually not passed, and the result says that this is why.
The result names the cause, so you can send “we could not measure” to another attempt and “the medium is wrong” to a human. Most light and distance problems are caught earlier still: before the check starts, the person is told what to fix.
What lands on your server.
Nothing that decides the outcome runs on the user device, so the result is not something a determined user can influence. The webhook is the authoritative copy.
- A verdict: passed, or not passed
- A confidence score behind that verdict
- The risk factors that shaped it, named rather than hidden
- Your own reference, echoed back for reconciliation
- Delivered by signed webhook, to a server your user cannot reach
The document check is optional, and separate.
Run it beside a liveness check, or on its own, or not at all. It is priced on its own and metered on its own, so you are never charged for a check you did not ask for.
Caught before it is submitted
Framing, glare and focus are checked in the browser while the person can still do something about it, rather than after they have closed the tab.
A human queue behind it
Documents land in a review queue where a person decides, and every decision is recorded so an altered compliance record is detectable afterwards.
Kept only as long as agreed
Stored encrypted, on a published retention schedule, and on a period set to your obligations if our default does not match them.
Run one against your own code before you decide.
A test key runs the whole flow and lets you force a pass or a fail without a camera, so you can build both branches properly. It is never billed.
Ready to secure your platform?
Confirm a real person is on the other end, before the decision that depends on it. Create an account and run your first check in the sandbox, free.