Loading

Connecting a Provider

A provider does the actual checking. Five are supported, and each declares what it is capable of.

Where to find it

Architect Panel → Security:

  • User Verification — the console — providers, types, checks and their history

The five

  • Entrust / Onfido — identity and age.
  • Stripe Identity — identity and age.
  • SheerID — affiliation and age.
  • GoCertify — affiliation.
  • Internal (E-mail Domain Check) — affiliation, performed by the platform itself with no external service.

Capabilities are declared

Each provider records what it can verify, so a type can only be pointed at a provider able to do that kind of check. This prevents the configuration that looks correct and fails on the first real attempt.

Start with the internal check

For affiliation, the internal e-mail domain check is free, involves no external service, no contract and no personal data leaving the platform. Where it answers your question — and for NHS, academic and many corporate affiliations it does — use it.

Bring in an external provider when the domain check genuinely cannot cover your population.

Each provider declares its own settings

Rather than a generic credential form, every provider publishes the fields it actually needs, so the prompts match that provider's own documentation. Credentials are stored encrypted.

Sandbox mode

Providers that offer a test environment can be run in sandbox. Use it. Commission the whole flow — request, redirect, outcome, group award, expiry — against test data before a real user is asked for a document.

Getting this wrong in production means a real person has submitted a passport into a broken flow, which is not a mistake you can quietly retry.

Use service credentials

Register the connection under an account belonging to the organisation, not to an individual. Verification credentials permit checks that cost money and process identity documents; they should not depend on one person's login and should be revocable without disrupting them.

Commissioning checklist

  1. Enable the provider and enter its credentials.
  2. Turn on sandbox.
  3. Point one verification type at it.
  4. Run a check end to end as a test user.
  5. Confirm the outcome, the evidence summary, the expiry and any group award.
  6. Run a deliberate failure and confirm the failure reason is recorded.
  7. Only then switch off sandbox.

Test the failure path too

Most commissioning tests only prove the happy path. The failure path is what your support team will actually deal with, and it is worth knowing what a user sees when a check does not succeed.

Worked example

An organisation enables SheerID in sandbox, points the Student type at it, and runs six test checks — four expected to pass and two to fail. The failures confirm that the reason is recorded and the user is given a sensible message. Sandbox is switched off a week later, after the group award and expiry have been verified.

Recommendations

  • Try the internal domain check first for affiliation.
  • Commission in sandbox, always.
  • Test the failure path, not just success.
  • Use organisational credentials, never a person's.