Verificate
Asked to verify?Talk to us
Menu

Verify new customers on their own phone.

Your signup page shows a code. They scan it, photograph their ID, take a selfie and read out a sentence that appears only when they press record. Checks settle the clear cases, and anything in doubt goes to a person on your team.

Read the docsTalk to us

For any online business that has to know who is signing up: marketplaces, payments, rentals, gaming, telecom.

signup.acme.example

AcmeStep 2 of 3

Verify your identity to finish opening your account.

verificate.me
  1. Code on the signup page42 s. Until the phone opens it
  2. Reading and consent23 s. On the phone
  3. Identity document38 s. Front and back
  4. Selfie12 s. A still, and frames around it
  5. Video statement21 s. A sentence shown at that moment
  6. Checks8 s. Read, compare, listen
  7. ApprovedAt 2:24, and your server is told

One verification, laid out as the stretches of time it is made of. This one is an example. Every stretch of a real session is timed on the server and kept with it, and the review desk draws each session like this.

Ask for the evidence you need, in the order you need it.

A session is a list of steps. Choose from five, set how each one works, and the customer sees only what you asked for.

  • Identity document

    A passport, identity card, driving licence or residence permit, photographed front and back with the camera. You choose the kinds, and the countries of issue, that you accept.

  • Proof of address

    A utility, phone or bank bill, a letter from a government office, or a lease, no older than you allow. The one step where a file already on the phone can be uploaded instead.

  • Selfie

    A still photo, and a few frames taken around it that show whether anything moved. Or ask for head turns: three, in an order chosen at that moment.

  • Selfie with a document

    The customer holds their identity document next to their face. Or say in your own words what to hold up, such as a signed form or a card you issued.

  • Video statement

    The customer reads a sentence aloud on camera. It is made up when they press record and valid for a minute, so a recording made earlier cannot contain it. Wording that your rules prescribe works too, with random digits added to the end.

The request behind the example aboveSent by your server to POST /v1/sessions. The answer holds the link, the code and a secret for the widget.
{
  "reference": "signup-8841",
  "requirements": [
    {
      "type": "id_document",
      "accept": ["id_card", "passport"]
    },
    { "type": "selfie" },
    { "type": "video_statement" }
  ],
  "expected": {
    "first_name": "Jane",
    "last_name": "Doe"
  },
  "max_completion_seconds": 900
}

No single check is enough. So there are many.

No detector can reliably tell a generated face from a real one, and Verificate does not pretend to have one. It gathers signals that are each hard to fake, and sends every doubt to a person.

Signs that it is a person, and that it is now

The camera only
Pictures and video are taken on the page. A file made earlier cannot be chosen.
A sentence nobody knew
It appears when recording starts, and is valid for a minute.
Movement
Frames around the selfie show a living face moving a little. A print does not.
Lips and sound
In the recording, the mouth moves when there is speech.
Screens
A photo of a display shows the pattern of its pixels.
Where a file came from
Content credentials, the software that edited it, a PDF changed after it was made.
The same picture twice
A picture already used in another session is noticed.
The device and the pace
A browser driven by a program, a camera that is not a real one, steps done faster than a person can act.

What the documents have to agree with

The machine readable zone of the card in the example. Its marked check digits, for the card number, the date of birth, the expiry date and the whole zone, are worked out again by code and compared with what is printed on the card.
  • The kind of document, who issued it, and that it is in date.
  • The face on it, against the selfie and the video.
  • Signs that it was altered, or that it is a photo of a screen or of a copy.
  • The same name on every document, even when one prints it in another script.
  • What you already knew: the name, date of birth, address and document number.

39 kinds of check in all. Each keeps its result, its score, its reasons and a sentence a reviewer can read. Every check, one by one

Rules decide what is plain. People decide the rest.

Every check reports what it found. Your thresholds turn that into one of four outcomes, and your server hears which by webhook.

Everything is sent

The checks run

  1. Approved

    Every check passed above its threshold.

  2. Asked to try again

    A problem the customer can fix, such as a blurred photo or a sentence that was not said. They redo that step on the same link, as many times as you allow.

  3. Held for a reviewer

    Any suspicion, any score between two thresholds, any check that could not run. A person at your review desk decides.

  4. Rejected

    Only for a plain fact that is still true after the tries you allow, such as an expired document.

Checks that have not finished after twenty minutes hand the session to a reviewer. Nobody is left waiting on a pipeline that has stopped.

What raised a suspicion is never shown to the customer. Telling a fraudster what gave them away helps them the next time.

Your reviewers see what the checks saw.

Sessions held for review wait at the desk, longest first. A reviewer sees the pictures, what was read from them, each check's finding in plain words, and how long every step took. Then they approve, reject, or ask the customer to try again.

  • Three roles

    Viewers see the queue and the figures, but no files and no personal data. Reviewers decide. Administrators manage keys, people, webhooks and erasure.

  • Single sign-on

    Reviewers sign in with their Google or Microsoft work account, and each has the role you give them.

  • Every look is recorded

    Opening a file or a customer's details writes to the audit log before anything is shown.

In your colours, and in their language.

The capture page and the widget carry your name, logo and colour. Customers choose English, Hebrew or Spanish on their phone, and the widget on your signup page follows the language they choose. Another language, French for one, is a translation away.

The widget as two products would show it, in English and in Spanish. It weighs 12 KB, needs no framework, and keeps its styles to itself.

Careful with what it is given.

Identity documents and faces are among the most sensitive things a company can hold. Verificate shows them to as few people as possible, and erases them when their time is up.

How Verificate handles data

Encrypted on the way and at rest.
Connections to the service use TLS, and every file and record is stored encrypted with AES-256.
Secrets are hashed or sealed.
API keys and link secrets are kept only as hashes. Webhook secrets are sealed with AES-256-GCM.
Face measurements are never stored.
They exist in memory for the length of one comparison, and are gone after it.
The link's secret never reaches a log.
It sits after the # in the address, which browsers do not send to servers.
Files are never public.
Every read is checked, and recorded before a byte is sent.
Every session has an end date.
Its files and personal data are erased on that day, sooner where the customer's country asks for it, or at once on request.
Files can stay in the European Union.
The choice is made company by company.
Consent is on record.
The version of the wording, the language, and the time.

One call, one script, one webhook.

Your server creates the session, your signup page shows it, and your server hears the decision. Test keys run the whole thing with outcomes you choose.

  1. Create a session

    From your server, with your API key. Say what you need, and what you already know about the customer.

    curl https://api.verificate.io/v1/sessions \
  -H "Authorization: Bearer $VERIFICATE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "requirements": [{ "type": "id_document" }, { "type": "selfie" }] }'

  2. Show the code

    Give the session's link and client secret to the widget on your signup page. It shows the code, then follows along.

    <div id="verify"></div>

<script src="https://api.verificate.io/sdk/v1/verificate.js"></script>
<script>
  Verificate.mount("#verify", { clientSecret, url });
</script>

  3. Hear the decision

    A signed webhook tells your server how the session ended. The verify function is in the API reference.

    // The signature covers the body as it arrived, so take it raw.
const raw = express.raw({ type: "application/json" });

app.post("/hooks/verificate", raw, (req, res) => {
  const body = req.body.toString("utf8");
  const signature = req.get("Verificate-Signature") ?? "";
  if (!verify(secret, body, signature)) return res.sendStatus(400);
  res.sendStatus(204);
  handle(JSON.parse(body)); // session.approved, rejected or needs_review
});
Test keys
Sessions made with a vk_test_ key take the same steps and send the same events. A mock decides them as you ask.
A 12 KB widget
No framework, its styles kept to itself, and no exceptions needed in a strict content security policy.
Webhooks that arrive
Signed, tried nine times over about eleven hours, and sent again from the desk when you ask.
Safe to repeat
With an idempotency key, a request sent twice gets the first one's answer.

API referenceThe widget

Were you asked to verify your identity?

A company you are signing up with uses Verificate. Here is what happens on your phone, what happens to your pictures, and how to get help.

What to expect

Try every outcome before a real customer does.

Test keys run the whole flow, from the code on your signup page to the webhook on your server, and cost nothing. A live document and selfie cost $0.75, with a $25 monthly minimum.

Ask for test keysSee pricing