Apple VAS, short for Value Added Services, is the NFC protocol an iPhone or Apple Watch uses to present a wallet pass to a contactless reader. Where a payment tap transmits card credentials, a VAS tap transmits the pass's payload, typically a member identifier, encrypted for the merchant's reader.
The exchange starts before the tap. A VAS-capable reader polls with Enhanced Contactless Polling, a signal that tells nearby Apple devices which merchant is asking and what it accepts. That is what makes auto-presentment work: the phone recognizes the merchant from the polling frame, finds the matching pass, and has it ready as the device reaches the field, with no unlock or app in the way. Once the phone is in the field, the reader selects the VAS applet and identifies itself with a merchant ID, a hash derived from the pass's pass type identifier. If a pass in the wallet matches, the phone returns its payload encrypted for that merchant: the pass data, a timestamp and a random one-time ECDH P-256 key are combined with the merchant's public key to derive the key the payload is encrypted under. Two consequences matter in practice. Only a reader holding the corresponding private key can decrypt the member identifier, and because the ephemeral key and timestamp change on every tap, no two taps produce the same ciphertext, so a captured payload cannot be replayed. A reader without the right key gets nothing, which is why a VAS setup always involves exchanging keys between the wallet platform and the reader or terminal provider.
For the member, nothing new is asked. Holding the phone to the reader brings up the relevant pass automatically, and on capable payment terminals the loyalty identification and the payment can happen in the same single tap. That is the experience that makes NFC identification feel invisible: no app to open, no barcode to find, no extra step at the till.
Making it work has four requirements. The Apple Developer Account that holds the pass type identifier needs Apple's VAS entitlement, which Apple grants once it has reviewed the use case. The pass must be NFC-enabled, which means the PKPass carries an NFC payload and an encryption key. The reader or payment terminal must support VAS and hold the matching key. And the merchant's point of sale must know what to do with the identifier it receives, usually looking up the member and applying the program's logic.
The entitlement is the requirement most programs meet last, because it is the one Apple reviews. Stell is a VAS Provider and prepares the request with the merchant, describing the program in the terms Apple assesses.
VAS is Apple's protocol; the Android counterpart is Google Smart Tap, and a well-configured reader handles both in the same tap target. QR and barcode remain equally first-class on hardware without NFC reading, so a program never depends on one route: the hardware at the till decides the path, not the platform.