Ábyrg verslunFyrirtækiAldursskírteiniVefþjónustaAlgengar spurningar
Vefþjónusta

Verification

Check that a customer meets an age requirement with one of three methods: a wallet pass, the customer's electronic ID (eID), or an employee who checked the customer's ID in person.

Overview

Every verification is a single request, POST /api/v1/verifications. The method field in the JSON body selects the flow (pass, manual or eid) and decides which other fields the body takes.

  • pass and manual resolve immediately. The response contains the result.
  • eid starts a pending request. You get back an id and poll GET /api/v1/verifications/{id} until the customer has answered in their eID app or on their phone.

GET /api/v1/verifications/{id} also takes a transactionId from a pass or manual verification and returns its result.

Every response carries livemode: true on a live tenant, false on a test tenant. See Test mode for the test Pass Tokens and eID identifiers.

Who can call it

Both verification endpoints take one of two tokens, and the token must carry the transactions:write scope:

  • Service client: a token from the client_credentials grant, sent as Authorization: Bearer <token>. See Authentication.
  • Linked device: a DPoP-bound token from the OAuth device flow, sent as Authorization: DPoP <token> together with a DPoP proof header. See Device authentication.

Dashboard user tokens are rejected with 403.

Choosing a method

methodUse whenResolves
passThe customer shows a wallet pass (QR or NFC). You send the Pass Token read from it.Immediately
eidThe customer has no pass but can sign in with eID in the eID app or on their phone's SIM.After polling
manualAn employee checked the customer's physical ID and confirms it.Immediately

Request shape

All three methods share requiredAge (an integer from 0 to 150), posReference (optional, 1 to 20 characters, your own receipt or basket reference) and deviceId (optional). Only service clients use deviceId: it attributes the transaction to an active device of origin api in your tenant. A linked device is always recorded as itself, and any deviceId it sends is ignored.

// method: "pass"
{ "method": "pass", "passData": "22V6MKRDAVZDP0Q9K0ACD7DSB5JAKZ5R1G86M60YKWPH0G2RHQJZS", "requiredAge": 20 }

// method: "manual"
{ "method": "manual", "employeeId": "kpwzv8tj1f5vhpvnra1dgwtamapfjw2g", "requiredAge": 20 }

// method: "eid"
{ "method": "eid", "identifier": "7771234", "loginType": "sim", "requiredAge": 20 }

Results and transactions

A verification that ran returns HTTP 200 with result set to pass or fail. A failed age check is a 200 with "result": "fail", not an error. HTTP error codes mean the request itself was refused. See Errors.

Most verifications record a transaction, whatever the result, and the response gives its transactionId. These cases record none:

  • a passData value that is not a Pass Token (reason: "invalid")
  • a pass verification refused with 429 by the rate limit
  • an eID request that ends rejected or timeout
  • any request refused with a 4xx or 5xx error (validation, auth, an unknown employee or device)

Recorded transactions can be read back through the Transactions API.

Verification methods

Pass verification

Send the single-use Pass Token read from the customer's wallet pass. Rate limited.

"method": "pass"

eID verification

Start a request, show the code to the customer, then poll GET /api/v1/verifications/{id}.

"method": "eid"

Manual verification

Look up the employee by their 6-digit access code, then record their confirmation.

"method": "manual"