Phases and activation

Phase 1 (member lookup) and Phase 2 (loyalty basket), and how activation per venue and per module decides what runs.

Two phases

Two phases were agreed on 14 Aug 2026; Phase 2 requires Phase 1.

1. Phase 1 — Member recognition

   • Nexi Engage lookup during card payment on Windows (BAXI, Viking) and Android (Softpay).
   • The loyalty ID returned by the lookup is stored on the order as a tag, the same pattern OnlinePOS uses for the Nightpay ID (agreed 17 Aug 2026).
   • No call to the REKOM backend. Nothing changes in pricing, receipts or payment.
   • Store enrollment per terminal setup (Option 1, 2 Sep 2026), see Store enrollment.
   • REKOM reads the loyalty ID from transactions through the REST API (if exposed; see open points) and can thereby attribute spend to members before any discounting exists.
2. Phase 2 — Loyalty basket

   • For venues with the REKOM module active, the OnlinePOS backend sends the basket plus loyalty ID plus calculation GUID to the REKOM backend synchronously and replaces the basket with the response.
   • Discounts print as note lines; the receipt footer may carry order-level text.
   • One post-sale event per calculation to the REKOM backend.
   • GUID exposed on the order as a meta attribute via the REST API.

Activation matrix

Activation is configured per customer/venue and per module in OnlinePOS (agreed 17 Aug 2026; “loyalty partner active that has registered the relevant webhooks” in the 4 Sep spec).

Nexi Engage module	REKOM module	What happens at card payment
off	off	Normal card payment. Order loyalty status not_applicable.
on	off	Lookup runs; loyalty ID stored on the order if found. No basket call. Status not_applicable.
on	on	Lookup runs. If a loyalty ID is found, the basket call runs and the returned basket is used. If not, status member_not_found and the sale continues.
off	on	Invalid configuration: the REKOM module needs a loyalty ID to act on. OnlinePOS should prevent or ignore this combination.

The REKOM module is activated per venue on both sides: OnlinePOS enables the module and the webhook configuration; REKOM maps the OnlinePOS venue ID to a programme and environment. A basket call for a venue REKOM has not mapped is answered with 422 venue_not_configured, which the POS treats like any other failure (original basket, status failed).

What staff see

Staff see the normal card-payment button and nothing else. Whether the lookup runs and whether the loyalty calculation runs is an OnlinePOS setup detail, not a choice at the till (agreed 3 Sep 2026). There is no separate “loyalty” button, no prompt and no extra step for staff or guest.

Rollout

• Phase 1 can go live per venue as soon as the venue’s BAX IDs are entered in Backoffice and the terminals have enrolled.
• Phase 2 is switched on per venue after the venue and its BAX number(s) are mapped in the REKOM backend. No per-venue discount campaign is needed; loyalty discounts carry the predefined discount code (see Basket rules → Discount code).
• Test venues on OnlinePOS’s side map to the REKOM staging host; production venues to the production host. The two never cross.