Two technologies promise the same magic moment: a customer taps to pay, and the till knows who they are without anyone asking. One reads a loyalty pass from the wallet during the tap. The other recognizes the payment card itself and looks the member up from it. The first runs on Apple VAS and Google Smart Tap; the second runs on PAR, the Payment Account Reference. They get compared as if they were interchangeable, and they are not. This article explains what each actually does, and how to decide which role each should play in your program.
What VAS identification is
Apple VAS (Value Added Services) is the protocol an iPhone or Apple Watch uses to hand a wallet pass to an NFC reader; Google Smart Tap is the Android equivalent. A pass issued with NFC enabled carries an encrypted member identifier, and a terminal configured with the matching key reads it during the tap. On capable terminals this rides the payment tap itself: one gesture, and the point of sale receives both the payment and the member ID.
The identifier the terminal receives is a loyalty identifier: it points at a member who joined your program, agreed to its terms, and holds your pass in their wallet. Identification, enrollment status and consent arrive as one fact.
What PAR identification is
PAR is different in kind. The Payment Account Reference is an EMVCo-defined value that identifies a payment account across every form the card takes: the physical card, the same card in Apple Pay or Google Pay, and any tokenized version of it all resolve to one PAR. It exists so that systems can recognize "the same card" without ever handling the card number.
Card-linked loyalty builds on this: when a member enrolls, their card's PAR is associated with their profile. From then on, any payment with that card, in any of its forms, can be matched back to the member. The terminal does nothing loyalty-specific at all; recognition happens in the payment data after the tap.
That is PAR's charm and its constraint. The customer needs no pass and no phone, which makes it the lowest-friction recognition there is once it is set up. But everything depends on the card having been linked first, and on your acquirer exposing PAR consistently, which varies by scheme, market and provider.
| Dimension | VAS and Smart Tap | PAR |
|---|---|---|
| What is identified | The loyalty pass in the wallet | The payment account behind the card |
| When it happens | During the tap, at the terminal | After the tap, in the payment data |
| What the member holds | A pass with balance, tier and messaging | Nothing |
| Prerequisite | Pass installed, capable reader, keys configured | Card linked in advance, acquirer exposes PAR |
| Consent | Structural: the member added and can remove the pass | Separately obtained and engineered |
| Blind spot | Members who never added the pass | Cards nobody linked, and unsupported schemes |
| Coverage elsewhere | Same pass scans by QR or barcode at any scanner | Only where the linked card is used |
Where each one breaks
VAS breaks on hardware and holdouts. It needs terminals or standalone readers that speak the protocols with keys configured, and it only sees members who carry the pass. A member who pays without ever adding your pass is invisible to it. (Scanner tills and online orders are covered by the same pass over QR and barcode, so those are gaps in the tap, not in the pass.)
PAR breaks on linking and on meaning. It only recognizes cards someone explicitly enrolled, so a new card, a partner's card or a corporate card starts unknown. Coverage depends on your acquirer surfacing PAR reliably across schemes. And recognition is all it does: PAR tells you a known card paid. It does not tell the customer anything, show a balance, carry a reward, or open a channel to reach them. There is no surface. Recognition without a relationship is a database update, not a loyalty experience.
There is also a consent difference worth taking seriously. A pass in the wallet is an artifact the member chose to add and can see and remove; purchase tracking by card requires its own clearly obtained consent and careful handling, because nothing the customer holds reminds them it is happening.
Not rivals: a channel and a safety net
The comparison resolves once you stop treating these as competitors. They answer different questions.
VAS answers "how does the member carry the program?" The pass is a surface: it shows the balance, updates after every purchase, sends push messages, surfaces at the right time and place, and identifies the member in the payment tap. It is the relationship made visible.
PAR answers "what about the purchases the pass didn't see?" As a fallback, card linking is genuinely useful: the day the member pays with a physical card, or at a terminal lane without VAS enabled, the linked card still attributes the purchase. Programs live or die on identification rate, and PAR can close leaks that no front-of-wallet method catches.
A program built on PAR alone has recognition and nothing else. A program built on the pass, with card linking as backfill where your payment stack supports it, has both the relationship and the coverage.
The short version
- Apple VAS and Google Smart Tap read a loyalty pass from the wallet during the tap; PAR recognizes the payment card itself and matches it to an enrolled member afterward.
- VAS delivers identification, enrollment and a member-facing surface in one artifact; it needs capable terminals and a pass in the wallet.
- PAR is recognition only: low friction once a card is linked, but no balance, no messaging, no artifact the member holds, and coverage that depends on your acquirer.
- Consent is structural with a pass and must be separately engineered for card tracking.
- Build on the pass; use card linking, where available, to attribute the purchases the tap misses.
Stell issues the pass side of this: NFC-certified for Apple VAS and Google Smart Tap, with QR and barcode on the same pass for every till the tap doesn't reach. Book a demo and see identification work at a real terminal.
