Skip to main content

​
Systems

The REKOM backend is a single service from OnlinePOS’s point of view, reachable at https://loyalty.xeniamoments.com (production) and https://loyalty-staging.xeniamoments.com (test). Both hosts are TBC until DNS is live; see Configuration and security.

​
Context diagram

​
Two integration surfaces

Purpose: recognise the card and return a loyalty ID to the POS.
  • On Windows, the POS drives the Viking terminal through BAXI. The lookup is BAXI action 193 (getasset) carrying only the cardref; no token is distributed to terminals. Lookups only work once the store (BAX) is enrolled with Nexi Engage, which the terminal does with action 114 (registerstore) at every startup. See Store enrollment.
  • On Android, Softpay calls the Nexi Engage backend directly. No enrollment is needed (Nexi, 31 Aug 2026).
This surface is live from Phase 1. OnlinePOS never creates members in Nexi Engage (agreed 12 Aug 2026); enrolling guests and their cards is REKOM’s.

​
Design principles

These are the properties the rest of the document is derived from.
  1. One payment motion. The guest taps to pay once. Behind that single tap the terminal reads the card, Nexi Engage recognises the member, and the basket goes to the REKOM backend. Then one of two things happens, and the guest notices neither:
    • the sale proceeds straight on with the original amount (no member, no benefit, or no answer in time), or
    • the amount is adjusted down with the loyalty discounts before it is authorised.
    Either way the guest approves exactly one amount, the final one, and is never asked to tap again, confirm anything or choose anything. There is no pre-authorisation on the original amount, no correction afterwards and no second approval (agreed, V1 §11; BAXI prepurchase used as today, 6 Oct 2026). Whether BAXI’s timing on Windows gives the POS this window is open point ON1.
  2. No interaction during the call. The basket call is a pure calculation. Any choice the guest makes (vouchers, upsell) happens before payment intent, in REKOM’s own channels (REKOM, 31 Aug 2026; accepted 4 Sep 2026).
  3. The returned basket is the truth. The REKOM backend is the source of truth for all discount calculation, including what happens to discounts already on the basket; OnlinePOS validates schema and arithmetic only (agreed 7 Oct 2026).
  4. Fail open. If the REKOM backend does not answer in time, the sale completes normally with the original basket. Only the order’s loyalty status is set to failed; the sale itself is not failed. Loyalty never blocks a sale (agreed 4 Sep 2026).
  5. Immutable transactions. A finalised transaction is never changed. Loyalty metadata is written only while the basket is sent and received (agreed 17 Aug 2026).
  6. Separate books. OnlinePOS’s audit trail is unchanged; loyalty and discount reporting are REKOM’s, fed by the REST sync (agreed 7 Oct 2026).