Basket rules

Scope of changes in Phase 2

Agreed scope, unchanged from Version 1 §7 (28 Aug / 4 Sep 2026). Phase 2 keeps every operation Version 1 allowed; nothing has been removed. Where a row says “REKOM practice”, it describes how REKOM intends to use the operation, not a restriction on it.

Operation	Phase 2	How it is expressed (directional names)
Amount discount on a line	Allowed	`lineDiscountType: "amount"`, `lineDiscountAmount`, text, discount code
Percentage discount on a line	Allowed	`lineDiscountType: "percent"`, `lineDiscountPercent`, computed `lineDiscountAmount`, text, discount code
Update a line’s price	Allowed	`overrideUnitPrice` on the line. REKOM practice: express a member price as an amount discount with text “Member price” instead, so the benefit shows up as loyalty discount data on the receipt and in POS
Add product lines	Allowed; the product must exist on the venue	New line with `addedByLoyalty: true`, `productId`, `quantity`, `unitPrice`
Remove product lines	Allowed	Line omitted from the returned `lines`
Split a line	Allowed	Two or more lines with `splitFromLineId` set to the original `lineId`; quantities add up to the original. REKOM practice: a partial-quantity benefit (“1 of 3 free”) as an amount discount on the whole line, so no split is needed
Order-level discount, amount or percent	Allowed; REKOM supplies the split onto lines (3 Sep 2026)	Entry in `orderDiscounts` with text and discount code, plus `orderDiscountAllocation` on each eligible line. Shown at the bottom of the receipt; see below
Existing discounts on the basket (staff discount, price discount on a product, order discount)	REKOM decides: keep, or swap for a larger loyalty discount	Existing-discount fields changed or cleared on the returned line; see Existing discounts
VAT, product receipt text	Not touched	Echoed as received

Directional. Field names, enum values, headers and JSON structures on this page show which information is exchanged, not the final names. None of them has been aligned with OnlinePOS yet. REKOM will adopt whatever OnlinePOS has by default for the order object and its webhooks, and does not require any of these specific names.

Line model (directional)

The request body is OnlinePOS’s own basket object, exactly as OnlinePOS has it, including the discounts already on it. REKOM modifies that object per its loyalty model and returns it; OnlinePOS applies what comes back. The tables below are REKOM’s illustration of the information in that object, grouped by who sets it.

Set by OnlinePOS (input)

Identity and quantity fields are echoed verbatim on every line REKOM keeps. The existing-discount fields are input: REKOM may change or clear them when it swaps in a loyalty discount.

Field	Type	Notes
`lineId`	string	Unique within the basket
`productId`	string	Venue-level product id, as in the REST transaction API (`product_id`)
`productMasterId`	string, optional	Cross-venue master id (`product_master_id`)
`productGroupId`	string, optional	Product group
`ean`	string, optional	`product_ean`
`name`	string	Receipt text, informational only
`quantity`	number	Units on the line
`unitPrice`	integer	Minor units, before any discount
`originalLinePrice`	integer	`quantity × unitPrice`
`parentLineId`	string, optional	For option / modifier lines that belong to a parent product
`noDiscount`	boolean, mandatory	`true` when the product may not legally be discounted (e.g. cigarettes). Mirrors the product’s `no_discount` setting. REKOM needs it to split order-level discounts correctly (3 Sep 2026)
`noPercentageDiscount`	boolean, mandatory	Product may not receive percentage discounts. Mirrors `no_percentage_discount`
`existingLineDiscountType`	`none` / `amount` / `percent`	Discount already on the line before the call (staff discount, product price discount). REKOM may keep it or swap it for a loyalty discount
`existingLineDiscountAmount`	integer	Minor units
`existingLineDiscountPercent`	number, optional	When type is `percent`
`existingLineDiscountText`	string, optional
`existingLineDiscountCampaignId`	string, optional
`orderDiscountAllocation[]`	array	Share of each existing order discount allocated to this line: `orderDiscountId`, `orderDiscountAllocationAmount`. REKOM may keep, change or remove these and appends allocations for order discounts it adds

Set by REKOM (only on `applied`)

Field	Type	Notes
`lineDiscountType`	`none` / `amount` / `percent`	`none` on lines REKOM leaves untouched
`lineDiscountPercent`	number	Required when type is `percent`; two decimals
`lineDiscountAmount`	integer	Minor units; always present (0 when `none`)
`lineDiscountText`	string, ≤ 40 chars	Printed on the note line, e.g. “Member price”, “Members: 2 for 1”
`showLineDiscountText`	boolean	Whether the note line is printed
`lineDiscountCode`	string	Required when type is not `none`; the predefined catch-all loyalty discount code, see Discount code
`overrideUnitPrice`	integer, optional	New unit price when REKOM updates a line’s price
`addedByLoyalty`	boolean	`true` on lines REKOM added; the product must exist on the venue
`splitFromLineId`	string, optional	On lines produced by splitting an original line
`orderDiscountAllocation[]`	array	Existing allocations kept, changed or removed per REKOM’s rules; loyalty allocations appended
`orderLinePrice`	integer	Final revenue value of the line, see identities below

Arithmetic identities

For every line:

linePrice      = quantity × (overrideUnitPrice if set, otherwise unitPrice)
orderLinePrice = linePrice
               − existingLineDiscountAmount
               − lineDiscountAmount
               − Σ orderDiscountAllocationAmount
orderLinePrice ≥ 0

For the basket:

totals.total                = Σ orderLinePrice over the returned lines
totals.orderDiscountTotal   = Σ over all lines of Σ orderDiscountAllocationAmount
for each orderDiscountId:     Σ orderDiscountAllocationAmount = that order discount's amount
totals.loyaltyDiscountTotal = Σ lineDiscountAmount + Σ amount of the order discounts REKOM added
totals.total                ≥ 0

Lines the REKOM backend does not change are returned exactly as received, with lineDiscountType: "none" and lineDiscountAmount: 0. A response with status applied changes the basket in at least one way (a discount, a price update, an added, removed or split line); if the calculation changes nothing, the response is unchanged.

Order-level discounts and the legal-discount flag

Agreed 3 Sep 2026 (Google Doc comments on V1 §8). Order-level discounts are allowed, and REKOM does the splitting onto lines. OnlinePOS’s answer: to register revenue correctly, all order discounts have to be split on the separate lines, and because some products, cigarettes for example, are not legally allowed to be discounted, the partner must do that split correctly. OnlinePOS places order discounts visually at the bottom of the receipt, as it already does for discount campaigns.

For REKOM to do that split correctly, OnlinePOS has to tell it per line whether the product may legally be discounted. That is what the two flags are for, and why they are mandatory on every line. The names are directional; the information is what is required, under whatever name OnlinePOS already has for it.

Rule	Detail	Status
`noDiscount`	Mandatory on every line. `true` when the product may not legally be discounted; mirrors the product’s `no_discount` setting in OnlinePOS. A request without the field is rejected with `400 invalid_request`.	Required by REKOM (follows from 3 Sep 2026)
`noPercentageDiscount`	Mandatory on every line; mirrors `no_percentage_discount`.	Required by REKOM
Order discount entry	REKOM adds an entry to `orderDiscounts` with `type`, `amount` (and `percent`), `text` and the discount code. Order discounts already present are kept, changed or removed per REKOM’s rules (see below).	Agreed (V1 §8 structure)
Splitting rule	The amount is spread over the eligible lines only (`noDiscount: false`), in proportion to `linePrice`, rounded per line with the remainder placed on the largest eligible line so the allocations add up to the amount. Excluded lines get no allocation.	Proposed
Receipt	The order discount is shown at the bottom of the receipt (3 Sep 2026; free-text field, informational, 7 Oct 2026). Its revenue effect is carried by the per-line allocations, which OnlinePOS validates.	Agreed
Open	Whether other legal restrictions exist that the product flag does not cover, and that option lines carry the flag too.	Open point O12

Discount code

Agreed, follow-up after 7 Oct 2026. Loyalty discounts carry no campaign ID. Every loyalty discount instead carries a predefined, semantic string that identifies the catch-all third-party-loyalty discount type in POS (lineDiscountCode on lines, discountCode on order discounts). This is the “general system campaign for third-party loyalty” variant of the 6 Oct 2026 assumption: no per-venue campaign is created, and nothing is provisioned through the REST API.

Rule	Detail
Fields	`lineDiscountCode`, required on every line where `lineDiscountType` is not `none`; `discountCode` on every order discount REKOM adds. Absent otherwise
Value	One predefined string for the whole integration, defined by OnlinePOS. REKOM proposes `loyalty` until OnlinePOS names it (open point O2).
Scope	The same code for amount and percentage discounts: the discount type carries the arithmetic, the code carries the “this is loyalty” meaning
POS side	Maps the code to its built-in loyalty discount type for the note line, receipt reproduction and its own discount categorisation
Validation	OnlinePOS rejects a response whose code is not the agreed string (`failureReason: invalid_response`)
Reporting	OnlinePOS sees one discount type; the breakdown per benefit lives in REKOM, joined on the calculation GUID

Staff discounts that already exist on a line or order keep their campaign reference (existingLineDiscountCampaignId, orderDiscounts[].campaignId); that is OnlinePOS’s existing discount system and is untouched.

Receipt rules

Agreed 17 Aug, 3 Sep and 6 Oct 2026.

A loyalty line discount prints as a note line directly under the product, with the discount text and the monetary value shown separately. The product’s own receipt text is never changed.
No new print layouts. Note lines use the existing mechanism.
A discount is dedicated POS discount data, never a free-text product with price zero (3 Sep 2026).
Order-level discounts are shown at the bottom of the receipt, as OnlinePOS does for discount campaigns (3 Sep 2026), through a free-text field that is informational and not part of reporting (7 Oct 2026). REKOM may fill receiptFooterText (≤ 200 characters) for this, e.g. “Members 10 %: −13,00 kr.”
memberLabel (≤ 40 characters, e.g. “REKOM Member”) may be shown on the receipt header or footer if OnlinePOS has a place for it; otherwise ignored.
Nothing from the response is shown on the customer display or to staff before payment beyond the updated basket total, since the call runs during the payment motion.

Rounding

Proposed — for OnlinePOS confirmation.

The REKOM backend computes every amount. For a percentage discount on a line:

lineDiscountAmount = round_half_up(linePrice × lineDiscountPercent / 100)

Rounding happens once per line, in minor units; order-discount allocations are rounded the same way, with the remainder on the largest eligible line. OnlinePOS does not recompute percentages; it validates the identities above using the integer amounts in the response. This avoids one-øre disagreements between the two systems.

Existing discounts: REKOM decides what is swapped

REKOM logic. The basket OnlinePOS sends includes the discounts already on it: a staff discount, a price discount on a specific product, an order discount. The REKOM backend decides, per line, what stays and what is swapped. If the loyalty programme unlocks a larger discount than the one already there, the guest gets the loyalty discount instead when the basket comes back; otherwise the existing discount stays and REKOM adds nothing. This logic is strictly REKOM’s. OnlinePOS simply receives the returned basket and applies it, which follows from the 7 Oct 2026 agreement that the returned basket is authoritative.

Consequences:

A returned line may carry a different existing discount than it was sent with, or none, because REKOM swapped it out. OnlinePOS’s validation therefore checks arithmetic and product identity, not that discount fields are unchanged.
A swapped-out staff discount no longer prints; the loyalty note line prints in its place. Nothing is printed twice for the same line.
Whether a benefit stacks on top of an existing discount or replaces it is a REKOM rule per benefit, not a POS setting. REKOM’s default is replace-if-larger.
The same applies to order discounts already on the basket: REKOM may keep, change or remove them and re-allocate accordingly.
If every eligible line already carries a better discount, the response is unchanged with reason all_lines_excluded.

Open — OnlinePOS to confirm (O4). OnlinePOS’s 6 Oct 2026 assumption said REKOM follows POS’s existing rules for combining discounts. REKOM’s reading is that the returned basket is applied as-is, including a replaced or removed staff discount, and that no POS-side combination rule is involved. OnlinePOS to confirm.

Flags

Flag	REKOM behaviour
`noDiscount: true`	Line is never discounted, never gets an order-discount allocation and never has its price lowered. Mandatory; mirrors the product’s `no_discount` setting (3 Sep 2026).
`noPercentageDiscount: true`	Percentage benefits are either converted to an amount benefit on this line or skipped, depending on the benefit. Mandatory; mirrors `no_percentage_discount`.
`parentLineId` set	Option lines inherit the parent’s eligibility; a benefit on the parent does not automatically extend to options unless the benefit says so.

Validation in OnlinePOS

OnlinePOS validates the returned basket for (V1 §9, unchanged):

Correct schema and the same calculationId as the request.
Every productId exists on the venue, including added and split lines.
Identity and quantity fields (lineId, productId, quantity, unitPrice, the flags) are unchanged on every line REKOM kept; split lines’ quantities add up to the original line. Discount fields may differ, because REKOM may have swapped an existing discount.
lineDiscountCode / discountCode equals the agreed catch-all loyalty discount code wherever a loyalty discount is set.
No loyalty discount, allocation or price reduction on a noDiscount line; no percentage discount on a noPercentageDiscount line.
The sum of orderDiscountAllocationAmount per orderDiscountId equals the stated order discount.
The per-line and basket identities above hold; all amounts are integers ≥ 0; the basket total equals the sum of orderLinePrice; total ≥ 0.

OnlinePOS does not validate REKOM’s business logic. A basket that fails validation is rejected: the original basket is used, the order’s loyalty status is set to failed (the sale itself completes), and the sale event carries failureReason: invalid_response.

Overview

Architecture

Reference

Scope of changes in Phase 2

Line model (directional)

Set by OnlinePOS (input)

Set by REKOM (only on `applied`)

Arithmetic identities

Order-level discounts and the legal-discount flag

Discount code

Receipt rules

Rounding

Existing discounts: REKOM decides what is swapped

Flags

Validation in OnlinePOS

​Scope of changes in Phase 2

​Line model (directional)

​Set by OnlinePOS (input)

​Set by REKOM (only on applied)

​Arithmetic identities

​Order-level discounts and the legal-discount flag

​Discount code

​Receipt rules

​Rounding

​Existing discounts: REKOM decides what is swapped

​Flags

​Validation in OnlinePOS

Scope of changes in Phase 2

Line model (directional)

Set by OnlinePOS (input)

Set by REKOM (only on `applied`)

Arithmetic identities

Order-level discounts and the legal-discount flag

Discount code

Receipt rules

Rounding

Existing discounts: REKOM decides what is swapped

Flags

Validation in OnlinePOS