Layered verification

The three-layer model, the two independent conditions a layer must satisfy to run, and which layers have a working path today.

Last updated: 2026-09-04

Age assurance can be done in more or less intrusive ways, and the differences matter to the shopper. The layered model exists so that a merchant's flow uses the least intrusive method that works, and never quietly escalates past it.

The three layers

Layers are ordered, and the order is the point:

Layer	What it is
1 — Electronic identity	Bank or government eID. The shopper authenticates somewhere they already have an account, and what comes back is a boolean, not a date of birth.
2 — Age estimation	Privacy-preserving facial age estimation. No identity document is involved.
3 — Document check	Document verification, as a last resort.

Layer 1 asks the shopper for the least and reveals the least. Each step down asks for more. A flow that starts at layer 1 and stops there is the intended shape; the lower layers exist for cases the first cannot serve at all.

Two conditions, both required

A layer runs only if both of the following are true:

Your tier entitles it. This is a billing property of your account.
Your policy enables it. Layer 1 is enabled whenever it is entitled. Layers 2 and 3 are off unless you explicitly turn them on.

Entitlement without the policy switch does nothing, and the switch without entitlement does nothing. That is deliberate: paying for a capability is not the same as consenting to use it on your shoppers, and a merchant who wants a provably eID-only flow should be able to have one no matter what their plan happens to include.

What each tier entitles

Tier	Entitled layers
Community	None. No layer is entitled, so no session can start.
Starter	Layer 1.
Standard	Layers 1 and 2.
Scale	Layers 1, 2 and 3.

See billing for what the tiers otherwise differ on.

What actually runs today

Layer 1 is the only layer with a verification path

Layers 2 and 3 exist today as an entitlement and policy model — the tier mapping above is real and enforced — but neither has an implemented verification path behind it. Your merchant dashboard shows both with their switches disabled and marked as coming soon, and starting a session evaluates layer 1 only, with both optional layers off.

The practical consequence is worth stating plainly: every eIDAS Pro verification, on every tier, is an electronic-identity check. There is no configuration in which a document or a face image is collected, because there is no code path that would do it. When the optional layers arrive, turning either on will be an explicit decision you make, not a default you inherit.

Separately, an electronic-identity check being the only layer does not mean one is available in your deployment. Which methods can serve layer 1 is a per-deployment question answered by GET /api/config → supportedMethods — see how a verification works.

Fail closed, never downgrade

The model refuses rather than substitutes. A shopper who cannot complete a permitted layer is turned away; they are not silently handed a more invasive check instead. An unrecognised layer is never permitted.

That applies to outcomes too. When the identity provider cannot reach a determinate answer, the session is rejected — not retried at a lower layer, and not treated as a pass.

The 403 you will meet

When a request needs a layer your tier does not entitle, the API answers:

{
  "error": {
    "message": "layer_not_entitled",
    "code": "LAYER_NOT_ENTITLED",
    "statusCode": 403
  }
}

Today the layer being checked is layer 1, so in practice a 403 LAYER_NOT_ENTITLED means the account is on the Community tier: the subscription is real and active, and no verification layer is included in it. The fix is an upgrade, not a payment. Contrast it with 402, which means the subscription itself is missing, inactive, or out of allowance — see billing — and with 401, which means the key never authenticated at all.