Check that a photo shows your customer. IDfier compares it with the photo on their verified ID and sends you a yes or no and a score. The ID photo never leaves IDfier.
Asking customers to upload a passport to prove a photo is theirs is slow, risky and more data than you need. IDfier answers the question and keeps the ID.
IDfier compares the photos and sends you the answer. You never receive the photo on the customer's ID.
A photo check can ask for the comparison alone: no name, no email, no date of birth. Just yes or no, and a score.
The customer sees your photo next to their ID photo in the IDfier app, and approves before anything is checked.
One request with the photo, one result to read. The same API as Login with IDfier, on the web and in apps.
Both compare against the photo on the customer's verified ID, and both need the customer's approval in the IDfier app.
You have a photo, from a selfie at sign-up, a profile or a handover. IDfier tells you whether it shows the customer.
You need a picture of the customer that you can trust. IDfier shares one that matched their ID when they added it.
Behind every answer is an ID document IDfier verified with a liveness check, the same verification that protects people meeting through IDfier.
Bilpool asks IDfier
POST /business/auth/request
{
"photo": "data:image/jpeg;base64,…",
"scopes": ["photoMatch"]
}Here is exactly what moves, and what doesn't.
Typical examples. Always check the rules that apply to collecting and comparing photos in your market.
Check that a seller's profile photo is really them before they list.
Confirm the person picking up the keys is the one who booked.
Show profile pictures that are known to match a verified ID.
Let the owner back in by matching a new selfie with the photo on file.
Tie a ticket or a badge photo to the verified person who holds it.
Check that the person on the shift is the one you onboarded.
Send the photo with scopes: ["photoMatch"] when you create a login request, and read photoMatch and photoMatchScore on your server. For a verified profile picture, add the profilePicture scope. The guide, code samples and API reference are at developers.idfier.com.
Add a verified name, email or an age check to the same request, and let customers sign in with a verified identity instead of a password.
For a photo check: whether the photo shows the customer (true or false), a score from 0 to 100, and an anonymous id for that customer. Nothing else, unless you also ask for other fields and the customer approves them. You never receive the customer's ID photo.
It is stored encrypted only until the customer answers, at most five minutes, and then deleted, whether they approve or decline.
From a score of 80. You also get the score itself, so you can apply a stricter or looser rule if your use case needs one.
That the person who approved in IDfier, whose ID document was verified with a liveness check, looks like the person in your photo. Your photo itself is not checked for liveness, so treat it as a photo match, not as proof that someone is in front of a camera right now.
Customers who verified without an ID document, for example with Swedish BankID only, have no ID photo to compare with. The check is then left out of the result, and you can treat it as not verified.
With the profilePicture scope you receive the picture on the customer's IDfier profile, which IDfier checked against their ID photo when they added it, plus that result and score. The customer chooses which of their verified pictures to share.
Yes: comparing faces is processing of biometric data. The customer gives explicit consent in the IDfier app for every check, only the result leaves IDfier, and your photo is deleted after the answer. Talk to our team about the data processing agreement for your use case.