Skip to main content

​
Lookup

The lookup is part of the card payment itself. There is no separate tap.
The POS calls the Viking terminal through BAXI. The lookup is action 193 (getasset) with the card reference (cardref) only. The terminal reaches Nexi Engage through Nexi’s DAM, which requires the store (BAX) to be enrolled; see Store enrollment. No Nexi token is distributed to terminals.
The result is either a loyalty ID or “not found”. OnlinePOS stores the loyalty ID on the order (tag, Phase 1) and, when the REKOM module is active, includes it in the basket call.

​
The loyalty ID

Version 1 used memberID in prose and loyaltyID in the 4 Sep lookup example. Version 2 says “loyalty ID” in prose and writes loyaltyId in payload examples. The payload name is directional: REKOM adopts whatever OnlinePOS uses by default.

​
Not-found path

  • Lookup returns no member: OnlinePOS sets the order’s loyalty status to member_not_found and completes the sale with the original basket. No REKOM call is made.
  • Lookup fails technically (terminal offline, DAM unreachable): same as above from the guest’s point of view; the order’s loyalty status is member_not_found or failed depending on what OnlinePOS can distinguish. The lookup “fails in a controlled way without blocking payment” (V1 §14, carried over).
  • Lookup returns a loyalty ID the REKOM backend does not know: the REKOM backend answers 200 with status member_not_found. This can happen when a card was enrolled in Nexi Engage but the member was later deleted in REKOM.

​
Enrolling guests and cards

Enrolling a guest into the programme, and linking their payment card to their loyalty ID in Nexi Engage, is REKOM’s concern and happens in REKOM’s channels. It is out of scope for OnlinePOS. The channel REKOM uses (Nexi Engage API versus a terminal action) is a REKOM-internal decision and is listed in the open points for completeness only.