A scanner-led app for the worker at the station, with idempotent retries that settle once.

The worker's loop

Five steps, traced to the screen spec.

1. Step 01

   Scan customer QR

   The scanner package drives the camera; permission UX is part of the flow.

2. Step 02

   Purchase entry → review

   Amount, category, payment method, optional external reference. The Idempotency-Key is generated once and reused on retry.

3. Step 03

   Confirm → success

   Pending state shows the server-confirmation message only — never a success icon. Success shows the transaction reference and points awarded.

4. Step 04

   Voucher review → consume

   Final review before consume; the Idempotency-Key is generated once and reused on retry.

5. Step 05

   Recent activity

   Read-only, current session only. Activity does not survive a restart until a server endpoint exists.

What we built

14 screens, one assigned station, server-authoritative hand-offs.

14 screens catalogued in the design spec, one assigned station (no station picker), a live QR scanner, and an Idempotency-Key on every value-moving write. The worker app never calculates points, balances, eligibility, station authority or voucher validity — every value-moving decision goes through the backend.

Hand-off discipline

Three concrete examples.

• No customer balanceThe success screen never shows the customer’s full balance. Only server-returned values are surfaced.
• Masked identityThe worker sees only the server-returned masked customer identity and the eligibility result.
• No false successSuccess appears only after a confirmed 2xx response; the pending state shows the server-confirmation message, never a success icon.

POS integration planned

What is named as the next phase.

The worker app earns its value when it talks to a real POS. That work is deliberately scheduled rather than assumed done.

• POS hardware qualification — name, Android version, scanner interface, MDM policy.
• Vendor printer SDK integration.
• Real-device qualification against POS-class hardware.
• Production signing key — current build is debug-signed.
• Worker app distribution model — public versus managed.

Real visual proof

What the page can show today.

• • Home / Station HubTwo dominant actions: scan customer purchase, consume voucher.
  • Customer ScannerLive QR scanner. Permission UX is part of the flow.
  • Scanned CustomerMasked identity only. The server returns eligibility, never the customer's full balance.
  • Purchase Entry → ReviewIdempotency-Key generated once and reused on retry.
  • Purchase Confirming → SuccessPending shows the server-confirmation message only; success shows the transaction reference and points awarded.
  • Voucher ScannerSame QR scanner surface, route depends on scan result.
  • Voucher ReviewFinal review before consume; Idempotency-Key generated once and reused on retry.
  • Voucher Confirming → SuccessSame confirmation discipline as the purchase loop.
  • Recent ActivityRead-only, current session only. Server endpoint pending.
  • Access DeniedServer returns access-denied; the app surfaces it without leaking eligibility.

What this page cannot show

No production-station deployment or POS hardware qualification yet.

• No live POS hardware to point to.
• No production-distribution channel.
• No vendor SDK integration.

Other product studies

Move between the three products.

• Manager dashboard

  Stations, workers, customers, transactions, complaints and offers — role-based, Arabic and English.

  Dashboard is live and used internally; no live screenshots published.

  Read the manager dashboard study

• Customer app

  21 screens designed in Arabic-first RTL; five are still placeholders.

  Preparing for store release — no store listing yet.

  Read the customer app study

← Back to the Glitre Loyalty Platform overview