> ## 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.

# Responsibilities

> Who owns what across OnlinePOS, Nexi Engage and the REKOM backend.

## Responsibility split

| Concern | OnlinePOS | Nexi Engage | REKOM backend |
| - | - | - | - |
| Card read and payment | POS/mPOS, BAXI / Softpay | Terminal, acquiring | — |
| Member recognition (card → loyalty ID) | Trigger lookup from the payment flow; store the loyalty ID on the order | Lookup (`getasset` / Softpay), card registry | Guest and card enrolment (never OnlinePOS, *12 Aug 2026*) |
| Store enrollment | "Nexi Engage Store ID" field in Backoffice; `registerstore` at startup | DAM, Engage store registry | Enter BAX ID per terminal setup (*2 Sep 2026*) |
| Per-venue activation | Module activation per customer/venue; webhook registration | — | Venue mapping and secrets per environment |
| Basket calculation | Send full basket + loyalty ID + GUID + BAX and terminal identifiers + per-line legal-discount flags; replace basket with the returned one; validate arithmetic | — | All loyalty and discount logic, including what happens to discounts already on the basket: keep, or swap for a larger loyalty discount (*6–7 Oct 2026*) |
| Discount representation | Existing discount system, discount campaigns, note lines, receipt footer text | — | Mark every discount with the predefined loyalty discount code, no campaign ID (*6 Oct 2026, resolved after 7 Oct*) |
| Fallback | Original basket on timeout/error; order's loyalty status `failed`, sale completes | — | Fast, deterministic responses; `unchanged` when nothing applies |
| Post-sale | Send one sale event per calculation; store GUID on the transaction | — | Record outcome; tolerate missing events |
| Audit trail | Unchanged (*7 Oct 2026*) | — | — |
| Loyalty and discount reporting | — | — | From own records + REST transaction sync (*7 Oct 2026*) |
| Receipt reproduction | Stores discount data needed to reprint (*3 Sep 2026*) | — | — |
| Support tooling | Order lookup by GUID via REST | — | Lookup by GUID / transaction ID in REKOM tooling |

## 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](/architecture/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

<Note>
  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.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.