Store enrollment

How a BAX is enrolled with Nexi Engage so that Viking terminals can look up members: Option 1 (decided 2 Sep 2026), REKOM’s one-BAX-per-terminal setup, and the token key REKOM owns.

Agreed 2 Sep 2026 (Option 1). OnlinePOS adds an “Integrations” tab in Backoffice terminal setup with a “Nexi Engage Store ID” field. REKOM fills it with the BAX ID. The OnlinePOS terminal runs store enrollment (registerstore, BAXI action 114) for all terminal IDs (TIDs) of that terminal setup at every terminal startup.

In OnlinePOS’s own words (2 Sep 2026): “Vi laver en tab under terminalopsætning, der hedder ‘Integrationer’. Her kan man indtaste ‘Nexi Engage Store id’.” This is the solution REKOM wants, and nothing below changes it. The field sits on the terminal setup, so there is one Store ID per terminal setup, which in REKOM’s layout is one per BAX (see Enrollment follows the BAX). The sections on the BAX layout and the token key only describe how they fit into it.

Why enrollment exists

Viking terminals on Windows reach Nexi Engage through Nexi’s DAM. DAM only answers lookups for stores that are enrolled. Softpay on Android calls the Nexi Engage backend directly and needs no enrollment (Nexi, 31 Aug 2026). Enrollment is therefore a Windows-only, per-BAX setup step.

Decisions

Point	Decision	Agreed
Store ID value	storeId = the BAX ID directly, with no prefix for environment or operator. One BAX corresponds to one OnlinePOS terminal setup.	31 Aug 2026 (REKOM, confirmed by Nexi that storeId is free text bound one-to-one to a BAX)
Where it lives	A “Nexi Engage Store ID” field on the terminal setup in OnlinePOS Backoffice, entered manually by REKOM.	2 Sep 2026
Who enrolls	The OnlinePOS terminal itself, at every startup, for all TIDs on that setup. Chosen because it is the least complex option: nothing to schedule, nothing to remember when a BAX is added or a terminal replaced, and a repeat call is harmless.	2 Sep 2026
Repeated enrollment	Harmless. A second registerstore for the same store returns error 212 “Store already registered”, which the terminal ignores.	27 and 31 Aug 2026 (Nexi)
BAX layout	REKOM runs one BAX per terminal (Nexi’s “Model B” below). Model A, one BAX shared by several terminals, is not REKOM’s setup. A venue therefore has several BAX IDs, each enrolled as its own Nexi store. Enrollment follows the BAX ID, never the physical terminal.	Oct 2026 (Nexi diagrams; REKOM’s setup)
Token key	Enrollment needs a token key. REKOM owns it and obtains it from the Nexi Engage API; enrollment still goes through the terminal via the ECR.	Oct 2026 (Nexi), see The token key
Lookup	BAXI action 193 (getasset) with cardref only. No token on terminals.	Implicit in the thread; documented on Nexi’s Viking quick start

Enrollment follows the BAX, never the terminal

REKOM runs Model B: one BAX per terminal. Model A, one BAX shared by several terminals, is not REKOM’s setup; Nexi’s diagram of it is shown below for contrast only. A venue with three terminals has three BAX IDs, three “Nexi Engage Store ID” fields and three enrollments. That is the normal case, not an exception, and nothing in the integration assumes one BAX per venue. The agreed Option 1 fits this directly: the Store ID field sits on the terminal setup, and one terminal setup is one BAX.

Nexi’s two diagrams are reproduced as received, in Danish: butik = store, ét bax-id pr. terminal (samme butik) = one BAX ID per terminal in the same store, ét bax-id pr. butik (delt af flere terminaler) = one BAX ID per store shared by several terminals.

✅ REKOM's setup. Nexi, Model B: one BAX ID per terminal in the same store. Each BAX ID needs its own store enrollment (its own token key), in practice one per terminal. Enrollment always follows the BAX ID, never the physical terminal.

❌ Not REKOM's setup, shown for contrast. Nexi, Model A: one BAX ID per store, shared by several terminals. Store enrollment (token key) is per BAX ID, so all terminals under the same BAX ID would share one enrollment in DAM.

Situation	Effect
Venue with several terminals	One BAX ID, one Store ID field and one enrollment per terminal.
Replacing a terminal under the same BAX	No action. Enrollment follows the BAX; the new terminal re-registers at startup and gets error 212, which it ignores.
Moving a terminal to another BAX	The other BAX needs its own enrollment, which happens at the next startup under Option 1.
Several terminals sharing one BAX (Model A; not REKOM’s setup, should it ever occur)	Same design. Each terminal registers at startup; the first call enrolls the store, the rest get error 212.
Attributing an order to a venue	The order carries the OnlinePOS venue ID as well as the BAX and terminal IDs. REKOM maps BAX IDs to venues many-to-one; the BAX never has to be unique per venue.

Alternatives that were not chosen

Not chosen. The options below were on the table between 17 Aug and 2 Sep 2026 and were rejected when Option 1 was agreed. They are kept here, with the reason, so that nobody re-proposes them without knowing why they were dropped. None of them is part of the design.

Alternative	What it would have meant	Why it was not chosen
❌ Option 2 — REKOM enrolls through an HQ terminal; OnlinePOS does nothing	REKOM would run registerstore for every BAX from a central terminal, and OnlinePOS would assume stores are already enrolled.	More complexity for no gain: a separate enrollment step per BAX, owned by a different party from the one operating the terminals, and nothing self-heals when a BAX is added or a terminal replaced. Letting every terminal enroll at every boot is simpler, and a repeat call is harmless (error 212). Rejected 2 Sep 2026.
❌ Manual enrollment by Nexi, per store	Nexi staff add the BAX and terminal IDs plus store name in DAM and in the Nexi Engage database, and activate tokens in Baxbis, for every store (around 20 manual steps).	Manual work for every new BAX, dependent on Nexi’s availability. Nexi’s own assessment on 20 Aug 2026 was that it is “in no way optimal” and invites ongoing errors. Rejected 2 Sep 2026.
❌ Composite store ID with operator and environment prefix	A storeId built from an operator code, the BAX ID and the environment.	Dropped the same day it was proposed (31 Aug 2026). One BAX is already one terminal setup and one environment, so the prefix added nothing; the plain BAX ID is used.
⏸ REKOM-owned enrollment through a DAM API	A new Nexi API letting the REKOM backend enroll stores without any terminal.	Parked, not rejected. Nexi estimated about two months of work; REKOM chose not to wait for it (31 Aug 2026). It may return for non-terminal channels; it is not part of Phase 1 or 2.

Flow

Operational notes

• Test environments: test BAX IDs used by OnlinePOS test venues must be registered as Nexi test stores, and they map to the REKOM staging host.
• One BAX per terminal (Model B) is REKOM’s standing setup. No consolidation to one BAX per venue is planned (this closes REKOM-internal point R2). Whatever BAX a terminal setup uses is the value in the field.
• Replacing a terminal does not change the BAX, so nothing changes in Backoffice.

The token key

Agreed (Nexi, Oct 2026). Store enrollment needs a token key. REKOM owns the token key and obtains it from the Nexi Engage API. Enrollment still has to go through the terminal via the ECR (OnlinePOS): the ECR enrolls the store with the key, the terminal sends the enrollment request to DAM, DAM forwards it to Nexi Engage, and “store enrolled OK” travels back the same way. In operation OnlinePOS only performs member lookups.

Nexi's enrollment sequence. The REKOM backend fetches the token key from Nexi Engage and passes it on; the ECR (OnlinePOS) enrolls the store with the key through the terminal and DAM. Note at the bottom: REKOM owns the token key; enrollment must still go through the terminal via the ECR; OnlinePOS only does member lookup in operation.

What Nexi’s own documentation adds. Nexi’s public Viking quick start describes store registration as a one-time process in two steps, matching the diagram above: the store token is issued per store ID by the Nexi Engage API to the holder of the Nexi credentials, which is REKOM, and the terminal then registers the store through Baxi with that token. Nexi also operates a separate test DAM environment for this. The page says nothing about the token’s validity, whether it can be reused, or what a repeated registration returns, which is why point 1 below is still open.

Proposed — for OnlinePOS confirmation. How the key reaches the ECR under Option 1: REKOM fetches one token key per BAX from Nexi Engage and enters it next to the Store ID in the Backoffice Integrations tab (a “Nexi Engage token key” field; name directional). The terminal uses both at startup. No REKOM call sits in the terminal boot path. This replaces REKOM’s earlier proposal that the OnlinePOS backend fetches the key itself.

Still open — OnlinePOS + Nexi (ON2).

1. Is the key one-time or reusable? If one-time, the every-startup registerstore must skip once the store is enrolled, or treat error 212 as success without a key.
2. Confirm the Backoffice field as the hand-over, rather than an API call from REKOM to OnlinePOS.
3. Endpoint, credentials and test environment for the token-key API (from Nexi’s documentation, N2).

A DAM API that would let the REKOM backend enroll stores without a terminal was estimated by Nexi at roughly two months of work and is parked (31 Aug 2026).