Every unidentified purchase was a step someone skipped.
Loyalty programs do not leak at signup. They leak at the till, one visit at a time, whenever identifying takes an extra step and the queue is moving. NFC identification removes the step: the tap that pays also identifies.
From a ceremony to a gesture.
Everything on the left is a place to lose the identification. The right is what remains.
- Open the appphone out, attention gone
- Wait for it to loadthe queue is moving
- Sign in againlogged out, password forgotten
- Find the member codethree taps deep
- Turn up the brightnessscanner glare
- Hold it to the scannera second gesture
- Or recite a phone numberout loud, at the till
Seven chances to lose the visit, at the exact moment the queue is least patient.
The payment tap the customer was making anyway. Apple VAS on iPhone and Apple Watch, Google Smart Tap on Android, and the member is known before the receipt prints.
And where a lane has a scanner instead of an NFC reader, the same pass shows a QR code or barcode: one swipe, no app, identified just as completely.
A member cannot forget to do something they were doing anyway. That is the whole argument: identification stops being a behavior you ask for and becomes a property of paying. Apple lists Stell among the certified pass providers for loyalty passes in Apple Wallet.
Built for exactly this handover.
Apple VAS and Google Smart Tap were designed for this exchange. Nothing is broadcast, the payload is an encrypted member token rather than a profile, and nobody without your keys can read it.
Encrypted payload
Only a terminal holding the matching key can read the pass. A random reader in the street learns nothing.
One-time key exchange
Your terminals and your passes share a configured key pair. Stell sets it up with your payment provider once.
Token, not a profile
The tap hands over an encrypted member token, never the member's profile. Stell resolves it to your member ID and posts it to your systems.
Start where your hardware is. Grow from there.
You do not need an NFC-ready fleet to start fixing the leak. The pass carries both routes from day one.
Launch on the scanners you own
A Stell pass can carry a QR code or barcode that reads at the till, on handhelds and at self-checkout. Identification works on day one, everywhere at once, with zero new hardware.
Enable tap where the terminals allow it
Modern terminals support Apple VAS and Google Smart Tap as a capability to enable. Stell is an Apple VAS Provider, requests the entitlement for your Apple Developer Account with you, and manages the one-time key exchange with your payment provider.
Extend lane by lane
Light up tap location by location, on your terminals or with standalone readers. The passes already in customers' wallets simply start tapping; nothing is reissued and nothing migrates.
One piece of that has a review step in it: NFC-enabled passes need Apple’s VAS entitlement on the developer account holding your pass type identifier, granted once Apple has reviewed the use case. Stell is a VAS Provider: we prepare that request with you and stay in the exchange until it lands. Because we start it early and the QR route needs none of it, the entitlement sits inside the rollout rather than in front of it.
What teams ask about the tap.
- Do our terminals support this?
- Modern payment terminals from major providers increasingly support Apple VAS and Google Smart Tap, but it is a capability to enable, not a default. Your payment provider can confirm what your fleet supports, and Stell has had that conversation before. Adyen terminals read Stell passes during payment today, and as an Adyen partner we can make the introduction if a terminal switch is on the table.
- What does the customer have to do?
- Nothing new. They tap to pay the way they already do; identification is a property of the tap, not an extra step. No app to open, no code to show, no phone number to recite.
- What about tills without NFC readers?
- A Stell pass can also carry a barcode in the format your scanners expect: QR, PDF417, Aztec or Code 128, plus EAN-13, Code 39, Codabar and Interleaved 2 of 5 on Google Wallet and iOS 27. Any retail scanner reads it, including handhelds and self-checkout, and a scanned pass identifies the member just as completely as a tapped one. Most chains run both, lane by lane.
- Is the tap secure?
- Yes, by design. The payload is encrypted so only a terminal holding the matching key can read it, and Apple Wallet can require Face ID or Touch ID before the pass is handed over. Apple derives the encryption key per tap from your public key, a timestamp and a random one-time ECDH P-256 key, so no two taps produce the same payload and a recorded one cannot be replayed. The tap carries a member token, not a customer profile.
- Does the tap still work if the backend is unreachable?
- Yes. The pass lives on the phone and the reader validates it locally with the configured key, so identification does not depend on a round trip to Stell. Passes already in wallets keep scanning and tapping through backend downtime; updates queue and apply when the connection returns.
- What setup is needed on our side?
- Four things: Apple's VAS entitlement on the Apple Developer Account that holds your pass type identifier, terminals that have the protocols enabled, a certified pass, and a one-time key exchange between Stell and your payment provider. Stell is an Apple VAS Provider, so the entitlement request is one we prepare and run with you, and the keys are ours to manage. The one part that is genuinely yours is describing the use case, and it is a conversation, not a project.
- What is the Apple VAS entitlement, and how long does approval take?
- NFC-enabled passes require an entitlement Apple applies to an Apple Developer Account. Apple grants it once it has reviewed the use case, so the request explains what the program is, where members tap, and what the pass identifies. As a VAS Provider, Stell prepares the request with you and handles the conversation with Apple through to a decision. Apple reviews every request to keep NFC passes a trusted experience on iPhone, so we start the request early, well before launch. In the meantime the same pass identifies members by QR or barcode, so a program can go live before the entitlement lands and gain tap afterwards without reissuing anything.
Bring your reader model.
The answer to whether this works at your till should be a demonstration, not a diagram. Forty-five minutes with a specialist: your terminals, your POS, a live tap. Tell us the use case and we will tell you what the Apple entitlement request looks like for it.