Responsibility split
What OnlinePOS does not do
- Calculate, combine or second-guess loyalty discounts. POS/mPOS calculate no discounts; they replace the basket with the one returned (6 Oct 2026). How loyalty interacts with discounts already on the basket is REKOM’s logic.
- Create or update members in Nexi Engage (12 Aug 2026).
- Change a finalised transaction, or expose endpoints that would (17 Aug 2026).
- Store REKOM-specific structures beyond what is needed to print the receipt and expose the GUID as a meta attribute (6–7 Oct 2026 and follow-up). Everything else is reconciled from REKOM’s side.
What the REKOM backend does not do
- Interact with the guest or staff during the basket call.
- Add a product that does not exist on the venue, or touch lines flagged
noDiscount(see Basket rules). - Return a discount without the predefined loyalty discount code.
- Touch VAT. VAT is OnlinePOS’s and is neither sent nor returned.
- Block a sale. Any failure on REKOM’s side results in the original basket.
Operating assumptions
These are the assumptions under which OnlinePOS scoped the work (6 Oct 2026) and
REKOM accepts them as constraints on the design:
the format of the basket object is defined by POS/mPOS and implemented by the
OnlinePOS backend; the returned basket is fully compatible with the POS’s existing
basket handling; POS’s existing discount system is not changed; no new print layouts.
The draft contract in the API reference is REKOM’s proposal for that object and is
expected to be adjusted by OnlinePOS where POS/mPOS constraints require.