Skip to main content
In store, the pass identifies the customer at your POS. Identification is local. The scan or tap hands your POS an identifier it resolves against your own systems, with no Stell call in the checkout path, so checkout keeps working even if everything else is down. Your systems stay the ledger: points and balances are computed where they always were.
The barcode carries the payload configured on your pass template, using placeholders such as {{customer.externalId}}, {{customer.emailAddress}}, or {{customer.mobileNumber}}, or set per pass with the API’s payload field. Left unset, it falls back to the pass id. Point it at the identifier your POS can resolve, usually externalId. See barcodes on pass templates for the template side.

​
After the sale

Push the new balance to the pass. Update pass with the new loyaltyState. Everything downstream of the scan or tap is identical for barcode and NFC. Optionally record the visit. Create transaction needs only passId and type. Everything else is optional, so send what your POS knows:
  • type: what happened to the pass, for example PURCHASE, REDEMPTION, or SCAN_ONLY.
  • channel (IN_STORE) and tapMode (SINGLE_TAP when pass and payment rode one tap, DOUBLE_TAP for separate taps, NONE without a terminal).
  • instrument: how the pass was presented. QR for a barcode scan, APPLE_VAS or GOOGLE_SMART_TAP for a tap.
  • status (APPROVED, DENIED, FAILED, or PENDING) with a statusReason when it explains a denial or failure.
  • pointsEarned, pointsSpent, and your reference (receipt number).
  • storeId and terminalId, if you track them.
  • payment: the payment side, with method (APPLE_PAY, CARD, VIPPS, and so on), amount, and PSP references.
  • additionalData: POS metadata such as register ID, line items, merchant category code, and raw POS or PSP data. See the request schema for the full list of accepted keys.
Recorded transactions appear in the portal’s Transaction Log. Staff can then investigate usage without leaving Stell.