Á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	pass at 17; fail at 18 or 20 (attests only 17). 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 as the phoneNumber of an Employee Enrollment. No phone is prompted: the start response carries code 0000 and the first poll returns the outcome. Spaces and hyphens are ignored.

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); 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.

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