Ábyrg verslun

A test tenant runs every verification and enrollment flow on the production API without real IDs, real wallet passes or real eID.

Getting a test tenant

There is no separate sandbox. Ask support@abyrgverslun.is for a test tenant; Ábyrg Verslun flags it as a test tenant for you. You cannot turn test mode on or off yourself. Set up service clients, locations, devices and employees on it exactly as on a live tenant.

livemode

Every verification response (all three methods, polls and Idempotency-Key replays included), every Employee Enrollment response and every transaction carries livemode: false on a test tenant, true on a live one.

{
  "result": "pass",
  "transactionId": "k57...",
  "livemode": false
}

Refuse a sale on livemode: false in production. A test outcome proves nothing about a real customer. If your integration is not itself running as a test setup, treat livemode: false as a configuration error (someone entered test credentials), not as a verification result.

Test Pass Tokens

Send these as passData with "method": "pass". They have the Pass Token format (53 characters), so they pass any format check in your client. You can encode them in a QR code to test scanning.

passData	Outcome
2TESTPASS0000000000000000000000000000000000000000000Z	pass for any requiredAge up to 20 (attests 17, 18 and 20). Never consumed: reuse it as often as you like.
2TESTPASS1700000000000000000000000000000000000000000Z	attests only 17, so it fails at the default minimum age of 18 (requiredAge is raised to the tenant minimum) and passes only on a tenant whose minimum age is 17 or lower. The transaction records failReason "underage".
2TESTEXPRD000000000000000000000000000000000000000000Z	fail, reason "expired"
2TESTCNSMD000000000000000000000000000000000000000000Z	fail, reason "consumed"
2TESTNKNWN000000000000000000000000000000000000000000Z	fail, reason "unknown"
2TESTBAD00000000000000000000000000000000000000000000Z	fail, reason "invalid"; no transaction is recorded

On a test tenant every other Pass Token, including a real shopper's, reads as unknown and is never looked up or consumed. Rate limits apply as on a live tenant.

Test eID identifiers

Use these as the identifier of an eID verification (either form, with either loginType) or in an Employee Enrollment: the phone as the phoneNumber of method: "sim", the kennitala as the kennitala of method: "app". No phone is prompted: the start response carries code 0000 and the first poll returns the outcome. Spaces and hyphens are ignored. A successful test enrollment sets the employee's name to Test Person, the verified name.

Phone	Kennitala	Outcome
0000001	0000000001	success: an adult born 1990-01-01, so result "pass". Enrollment: enrolled as "Test Person".
0000004	0000000004	success: a person aged 16 today, so result "fail" at 17+. Enrollment: enrolled as "Test Person".
0000002	0000000002	status "rejected" (the person declined)
0000003	0000000003	status "timeout" (the person never answered)

On a test tenant any other identifier is refused with 400 Bad Request; the eID Provider is never called. An employee entered on the dashboard with a real kennitala cannot enroll with a test identifier (the kennitala does not match, so the enrollment is rejected with identity_mismatch on the first poll); employees created through the API can. The test person may enroll as any number of employees; on a live tenant one person is at most one employee. Manual verification on the dashboard takes a real kennitala, also on a test tenant, and is recorded as a test enrollment there.

On a live tenant

The test Pass Tokens are not valid Pass Tokens: they read as invalid and nothing is recorded.
The test eID identifiers are not real phone numbers or kennitölur: they go to the eID Provider like any other identifier and fail there.
When a test tenant goes live, employees enrolled with a test identifier are no longer enrolled and must enroll again with real eID, and pending test eID requests are closed as failed. An Idempotency-Key used in test mode is not replayed live.

What a test transaction is