> ## Documentation Index > Fetch the complete documentation index at: https://docs.loyalty.xeniamoments.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](#enrollment-follows-the-bax-never-the-terminal)). 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](#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](https://dev-engage.nexigroup.com/getting-started/viking.html) | ## 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. Nexi Model B, REKOM's setup: one BAX ID per terminal in the same store Nexi Model A, not REKOM's setup: one BAX ID per store shared by several terminals | 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 ```mermaid theme={null} sequenceDiagram participant K as REKOM participant NE as Nexi Engage API participant BO as OnlinePOS Backoffice participant T1 as Terminal (BAX 1) participant T2 as Terminal (BAX 2) participant D as Nexi DAM / Engage K->>NE: Get token key per BAX NE-->>K: Token key K->>BO: Integrations tab per terminal setup: Store ID = BAX ID (agreed), token key (hand-over proposed) Note over T1,T2: Every terminal startup T1->>D: registerstore(storeId = BAX 1) D-->>T1: Store registered successfully T2->>D: registerstore(storeId = BAX 2) D-->>T2: Store registered successfully Note over T1,T2: Next startup: registerstore again, error 212, ignored Note over T1,T2: Lookups (getasset) now work on both terminals ``` ## 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 sequence diagram: REKOM backend gets the token key from Nexi Engage, passes it to the ECR, which enrolls the store through the terminal and DAM **What Nexi's own documentation adds.** Nexi's public [Viking quick start](https://dev-engage.nexigroup.com/getting-started/viking.html) 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](/reference/open-points)).** 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](/reference/open-points)). 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). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.