Signing in tells you an account holder returned. Verification tells you something you can act on — grant access, apply a discount, permit a regulated activity, or satisfy an obligation to check.
Three things you can prove
- Identity — that a user is who they claim to be, established by photographing a government-issued identity document and, usually, a selfie.
- Affiliation — that they belong to a group which earns access or a price: a student, an NHS or other healthcare worker, a teacher, a serving or former member of the armed forces, a first responder, or a member of a particular organisation.
- Age — that they are over a required threshold, without you having to store their date of birth.
Where to find it
Architect Panel → Security → User Verification. The screen has three parts: checks awaiting manual review, the providers that do the checking, and the verification types you offer to users.
Two things to configure, not one
What can be verified and who verifies it vary independently, so they are separate:
- A verification type is something you offer — "Student", "Healthcare Worker", "General ID Check". This is what users see.
- A verification provider is a configured service that performs checks.
Because a type only points at a provider, you can move Student from one provider to another by changing a single setting — with no loss of the checks already recorded.
Worked Examples
- Retailer: student discount verified free of charge against university e-mail domains.
- Regulated marketplace: ID document check before a seller can list, plus an age check for restricted categories.
- NHS supplier: healthcare-worker pricing verified against nhs.net and trust domains.
- Professional body: ID verification at membership application, renewed every two years.