Plans, usage and billing
How tiers, included volume, overage credit and the subscription gate work — and why a working key can start answering 402.
Last updated: 2026-09-12
Every verification session your integration starts is checked against the subscription behind the API key that started it. This page describes what that check looks at, so that a 402 is something you can diagnose rather than something that happens to you.
Tiers
There are four tiers, ordered:
| Tier | What it is |
|---|---|
| Community | Free. Development and evaluation. It carries no verification entitlement, so it cannot start production sessions. |
| Starter | The entry paid tier. Entitled to the electronic-identity layer. |
| Standard | Adds the age-estimation layer as an entitlement, plus custom branding and an SLA. |
| Scale | Adds the document layer as an entitlement, plus webhooks and white-labelling. |
Each paid tier comes with a monthly price, a monthly allowance of included verifications, and a per-verification rate for anything beyond that allowance. The current numbers are published in the pricing section of the eIDAS Pro site; the allowance, the usage against it and the credit balance for your account are on the billing page of your merchant dashboard. Read them there rather than copying them into your own code, since those are the figures your account is actually billed against.
Which layers a tier entitles is a separate question from which layers exist as a working verification path today. See layered verification.
Webhooks are a Scale-tier feature: registering or updating one on a lower tier is refused.
What counts as a verification
Usage is metered when a session reaches a determinate verdict, not when it is created. So:
- A session that passes is metered.
- A session that runs and does not pass — a shopper who is below the threshold — is also metered. The check ran and produced an answer; that answer is the product.
- A session the shopper abandons, one that expires unused, one the identity provider could not decide, and one that failed because the provider was unreachable are not metered.
Metering happens after the verdict, so it never blocks or delays a result.
Included volume, then credit
Within your monthly allowance, verifications draw down that allowance. Once usage reaches the allowance, further verifications are overages, and each one is charged against a prepaid credit balance rather than added to an invoice.
That balance is topped up from the billing page of your dashboard. A top-up is a one-off payment of at least €5 and at most €10,000, and the credit sits on the account until it is used — for as long as the subscription is live. It does not survive a cancellation; see changing plan.
An empty credit balance stops verification, it does not queue it
Once the allowance is used up, a session can only start if the credit balance covers at least one overage charge. If it does not, POST /api/verification/init answers 402 and no session is created. There is no overdraft and nothing is billed after the fact — so on a busy month, a top-up is the thing standing between your checkout and a hard stop.
The three ways a valid key gets a 402
This is the case worth understanding before you meet it: the key is genuine, the integration is unchanged, and yesterday it worked. Authentication succeeded — a bad key answers 401, never 402. What failed is the subscription gate, and the code in the error envelope says which one:
code | What happened | What clears it |
|---|---|---|
NO_SUBSCRIPTION | There is no subscription attached to the account behind this key. | Subscribe, or point the integration at a key belonging to an account that has. |
SUBSCRIPTION_INACTIVE | A subscription exists but is not active — cancelled, paused, or past due. | Settle or resume it from the dashboard. A failed card renewal is the usual cause of the overnight version. |
QUOTA_EXHAUSTED | The monthly allowance is used up and the credit balance will not cover one more overage. | Top up the credit balance, or move to a tier with a larger allowance. |
All three are HTTP 402. Branch on code, not on the status alone and not on the human-readable message — see errors and status codes.
A 403 with LAYER_NOT_ENTITLED is the neighbouring case: the subscription is active and in good standing, but the tier does not entitle the verification layer the request needs. That is an upgrade, not a payment problem.
The 503 that looks like a billing problem and is not
503 with BILLING_UNAVAILABLE means the subscription could not be looked up at that moment. Your key is fine and your account is fine.
It is deliberately not a 402, because reporting "payment required" to a paying merchant on the strength of a timed-out lookup is a false statement about their account — and integrations act on it, usually by showing the shopper something alarming. Treat it as retryable, and do not surface it as a billing message.
Changing plan
A first subscription is bought from the pricing section of the eIDAS Pro site. After that, every change is self-service from the billing page of your dashboard.
Upgrades take effect immediately. Your allowance and entitled layers change from that moment, and Stripe adds a prorated charge for the remainder of the period to your next invoice — nothing is taken from your card at the time you confirm. An upgrade does not retroactively re-price verifications already metered in the current period.
Downgrades take effect at your next renewal. Nothing changes on the day you schedule one: you keep the allowance and the rate you have already paid for until the period ends, and the lower price applies from the following invoice. Because the change is deferred, the dashboard shows it as scheduled until the renewal applies it.
A downgrade out of Scale disables your webhooks
Webhooks are a Scale-tier feature. When a downgrade out of Scale takes effect at the renewal, every webhook on the account is disabled — not deleted. Your configuration survives and can be re-enabled if you return to Scale, but deliveries stop at that boundary, so a Scale integration that depends on them needs a plan before the renewal date rather than after it.
Cancellation takes effect at the end of the current billing period, and is reversible until then. Your subscription stays active and verifications keep working for the remainder of the period you have paid for; nothing further is charged. Reinstate it from the billing page any time before that date and nothing is lost.
Once the cancellation takes effect, POST /api/verification/init answers 402 with NO_SUBSCRIPTION and your integration stops gating — see the three ways a valid key gets a 402.
Unspent credit does not survive a cancellation
Prepaid credit sits on the account while a subscription is active, but it does not carry past the end of the period in which the subscription is cancelled, and it is not refunded. If you hold a balance you intend to use, spend it before that date.
Watching usage before it bites
The dashboard reports verifications used against the allowance and the current credit balance. The two failure modes worth alerting on are the ones with no warning attached: a renewal that silently goes past due, and an allowance that runs out mid-month with an empty credit balance. Both present to your checkout as a 402 on the very next session, so it is cheaper to watch the numbers than to discover them.