Changes from Version 1

Version 2 keeps the structure and most of the terminology of OnlinePOS’s original description, so that the two can be compared section by section. The changes below are either decisions made after V1 was written or REKOM proposals that resolve a gap in V1.

Model and flow

Area	Version 1 (28 Aug / 4 Sep 2026)	Version 2 (8 Oct 2026)	Status
Call model	Asynchronous: `basketId`, polling from POS, `LoyaltyBasketCallback` / `LoyaltyBasketCallbackCancel` from REKOM (28 Aug). Synchronous in the 4 Sep update.	Synchronous only. Checkout waits on the REKOM response; no callbacks, no polling, no `basketId`.	Agreed 4 Sep 2026
User interaction during the call	”REKOM runs its logic (optionally with user interaction)”.	None. All upsell and choices happen before payment intent; the call is a pure calculation.	Agreed 31 Aug / 4 Sep 2026
Correlation ID	`loyaltyDiscountReference` on the response (dropped 28 Aug).	POS/mPOS generate a GUID per basket calculation (`calculationId`), sent to REKOM and later exposed on the order as a meta attribute in the REST API.	Agreed 7 Oct 2026; meta attribute agreed after 7 Oct
”No change” outcome	Status `unchanged` existed, mechanism unspecified.	Explicit `unchanged` response with a `reason`; no lines returned.	Agreed 7 Oct 2026
Source of truth	OnlinePOS validates and may reject.	The basket REKOM returns is authoritative; OnlinePOS validates arithmetic and schema only.	Agreed 7 Oct 2026

Scope of basket changes

Area	Version 1	Version 2	Status
Line price override	Allowed.	Kept (`overrideUnitPrice`). REKOM practice: member prices as an amount discount with text “Member price”, so the benefit is visible as loyalty discount data.	Agreed scope kept; field name proposed
Add / remove / split lines	Allowed (product must exist on venue).	Kept, made explicit with `addedByLoyalty` and `splitFromLineId`. REKOM practice: partial-quantity benefits (“1 of 3 free”) as an amount discount on the line.	Agreed scope kept; field names proposed
Existing discounts on the basket	Sent as `existingLineDiscount*`, “informational”.	Input to REKOM’s logic: REKOM keeps them or swaps them for a larger loyalty discount; OnlinePOS applies the returned basket as-is.	REKOM logic; OnlinePOS to confirm (O4)
Order-level discounts	Allowed as a separate order discount with allocation to lines.	Kept. REKOM supplies the per-line allocation, skipping lines flagged `noDiscount` (3 Sep 2026); shown at the bottom of the receipt through the free-text field (7 Oct 2026).	Agreed
Discount identification	Not mentioned.	No campaign ID. Every REKOM discount carries a predefined, semantic discount code (`lineDiscountCode`) for the catch-all third-party-loyalty type; exact string to be confirmed.	6 Oct 2026 (campaign or generic type), resolved to the generic code after 7 Oct 2026
Receipt	Discount text as a separate line under the product.	Same, formalised as a note line; no new print layouts; product receipt text untouched; discount is dedicated POS discount data, never a free-text 0-price product.	Agreed 17 Aug, 3 Sep, 6 Oct 2026

Endpoints exposed by REKOM

Version 1	Version 2	Status
`loyaltyBasket`	`POST /v1/onlinepos/basket`	Same purpose, now synchronous
`loyaltySaleFinalization`	`POST /v1/onlinepos/sale` with `status` `applied` / `unchanged` / `member_not_found` / `failed`	Merged — proposed
`loyaltySaleCancellation`	`POST /v1/onlinepos/sale` with `status` `cancelled`	Merged — proposed
`loyaltyOfflineSale`	`POST /v1/onlinepos/sale` with `status` `failed`, `failureReason` `offline`	Merged — proposed
`LoyaltyBasketCallback`, `LoyaltyBasketCallbackCancel` (OnlinePOS side)	Removed with the asynchronous model.	Agreed 4 Sep 2026

The 4 Sep text said “the three webhooks” while listing four endpoints. Version 2 resolves this to two REKOM endpoints.

Naming and data

All Version 2 names in this section are directional: they show which information is exchanged. REKOM adopts OnlinePOS’s default names and structures.

Area	Version 1	Version 2	Status
Member identifier	`memberID` in prose, `loyaltyID` in the 4 Sep lookup example.	”loyalty ID” in prose, `loyaltyId` in examples. Opaque, no PII.	Directional name; follows OnlinePOS default
Money	Integers in the example (10000 − 2000 − 1000 = 7000), unit never stated.	Integer minor units (øre) plus ISO 4217 `currency`.	Proposed — OnlinePOS to confirm
Context on the request	`venue`.	`venueId`, `baxId` and `cashRegisterId` (all required, so REKOM can attribute every order to a venue and till), `terminalId`, `clerkNumber`, `channel`. Names mirror the REST transaction API so reconciliation is a join.	BAX and terminal identifiers agreed after 7 Oct 2026; names directional
Line fields	`lineId`, `productId`, prices, discounts, allocation.	Adds `quantity`, `unitPrice`, `productGroupId`, `productMasterId`, `ean`, `parentLineId`, `noDiscount`, `noPercentageDiscount`, existing-discount text/campaign, `totals`, `requestedAt`.	Information proposed; names directional
Loyalty metadata on the transaction	Rich metadata (status, per-line breakdown, error, memberID filter) in V1 §15.	GUID confirmed and exposed as a meta attribute on the order in the REST API; everything else reconciled from REKOM’s own records. Further meta attributes remain an open point.	Agreed 7 Oct 2026 and after / Open
Authentication	”Authentication” as part of webhook registration, unspecified.	HMAC-SHA256 request signatures (`OnlinePOS-Signature`), secret per environment; no scheduled rotation, REKOM swaps the secret itself with both secrets active during the overlap.	Proposed
Timeout and retries	”Up to three retries… within an agreed overall maximum timeout”, numbers open.	p95 ≤ 150 ms / p99 ≤ 250 ms target on REKOM’s side; POS timeout 500 ms per attempt, one connect-retry, hard cap 3 s.	Proposed

Store enrollment

Version 1 listed store enrollment with Nexi Engage as “currently not specced”; the 4 Sep update dropped the section. Version 2 documents the decision from the separate “Rekom | Nexi Engage integration” thread: Option 1 (2 Sep 2026) — OnlinePOS adds a “Nexi Engage Store ID” field in Backoffice terminal setup, REKOM fills it with the BAX ID, and the terminal runs registerstore at every startup. See Store enrollment.

Overview

Architecture

Reference

Model and flow

Scope of basket changes

Endpoints exposed by REKOM

Naming and data

Store enrollment

​Model and flow

​Scope of basket changes

​Endpoints exposed by REKOM

​Naming and data

​Store enrollment

Model and flow

Scope of basket changes

Endpoints exposed by REKOM

Naming and data

Store enrollment