Case study

NFC membership check-in at the counter — Sunmi V2S, retail chain

A retail chain wanted membership check-in at the counter without a separate card reader. An NTAG213-based loyalty card read through the Sunmi V2S's built-in NFC SDK ties into checkout and prints a loyalty line on the receipt.

A retail chain running Sunmi V2S handheld POS units at the counter wanted to add membership check-in — tap a card, apply the customer's loyalty tier, print a line on the receipt confirming points earned — without bolting on a separate USB or Bluetooth NFC reader. The V2S already has NFC hardware built in; the ask was to use what was already in the device rather than add another peripheral to manage, charge, and eventually lose.

The existing checkout flow was cash-register-simple: ring up items, take payment, print receipt. Membership was tracked on a separate spreadsheet-adjacent system that staff checked manually by asking for a phone number, which slowed down the line and depended on staff remembering to ask.

The problem

The Sunmi V2S's built-in NFC reads NTAG213 cards fine at the hardware level, but the built-in SDK's read callback runs on its own thread and needed to be threaded correctly into an existing checkout Activity without blocking the UI or, worse, letting a stray tap during an unrelated screen (like a manager settings menu) get misread as a loyalty check-in. The checkout app hadn't been built with an NFC listener in mind, so most of the integration work was about scoping when the reader was actually listening, not the read itself.

The second problem was tying a bare NFC UID to a loyalty tier without standing up new backend infrastructure — the client didn't want a new server, they wanted the existing lightweight loyalty database (already reachable from the POS over the store's local network) to gain one new lookup path.

Hardware used

Architecture

NFC listening is scoped to the checkout screen's active state only — registered in onResume, unregistered in onPause — so a tap anywhere outside an active checkout (settings, end-of-day reports) is simply not read at all rather than needing to be filtered after the fact.

Copy[Checkout screen active] --onResume--> [NFC listener registered]
        |
        v
   [Card tap] --UID read (NTAG213)-->
        |
        v
 [Local loyalty DB lookup by UID] --LAN, existing service-->
        |
        +--> known member  -> apply tier discount, print loyalty line
        +--> unknown UID   -> prompt staff: "not registered, enroll?"
        |
        v
[Checkout screen inactive] --onPause--> [NFC listener unregistered]

A tap during active checkout reads the card UID and looks it up against the existing loyalty database over the store's LAN — no new backend, just a new query path into a system that already existed. A known UID applies the customer's tier and the receipt gets an extra printed line via the Sunmi Printer SDK confirming points earned. An unknown UID prompts staff to offer enrollment rather than failing silently, since a card that doesn't resolve is very often a new customer, not an error.

What was tricky

The lifecycle scoping sounds obvious in hindsight but wasn't the first design — the initial version registered the NFC listener at Application level for simplicity, and it worked fine in testing and then produced a handful of confusing false check-ins in the pilot store, where staff would tap their own badge (also an NFC-readable card, for an unrelated door-access system) near the POS during a shift-change conversation and it would register as a customer loyalty tap. Scoping the listener strictly to the active checkout screen state fixed it, but finding the actual cause took longer than fixing it — the badge taps were incidental and didn't correlate cleanly with any single action in the logs at first.

The other real constraint was print timing: the loyalty line needed to appear on the same physical receipt as the transaction, which meant the NFC lookup had to complete before the print job fired, not after. Under a slow LAN moment the lookup could lag behind the cashier hitting "print," so the print step now waits on the loyalty lookup with a short timeout and falls back to printing without the loyalty line (rather than blocking checkout) if the lookup doesn't return in time.

Result

Membership check-in now happens as part of the existing tap-and-pay motion, adding well under a second to an average transaction, with no separate reader hardware. In the pilot store, the false-tap issue was fully resolved after the lifecycle fix, and staff-reported "asking for a phone number" checkout friction dropped to near zero since the tap itself surfaces membership status without a verbal exchange.