Apple VAS and Google Smart Tap: How NFC Wallet Passes Actually Work
Apple VAS and Google Smart Tap sound like NFC tags, but they're something else entirely: certified, encrypted protocols for moving a Wallet pass from phone to terminal. Here's what's actually happening on each tap, why a regular reader can't just read one, and when a small business is better off skipping both for a plain NDEF tag.
What it is
Apple VAS and Google Smart Tap are the protocols behind the loyalty cards, tickets, and ID passes in Apple Wallet and Google Wallet. They're not NFC tags in any sense you're used to. Each is a proprietary, certified protocol that a terminal and a phone negotiate on every tap — built specifically to move pass data, not payment data, between a device and a reader.
That's a different job from how Apple Pay and Google Pay use NFC, even though VAS can ride alongside an Apple Pay transaction. Below: what's happening during the tap, where you'll run into it, and why a tag you wrote yourself behaves nothing like one of these passes.
How it actually works
A VAS tap starts with the terminal, not the phone. It sends a request for a pass, and if you're holding a matching one in Wallet, you authorize its use with Face ID, Touch ID, your passcode, or a double-click on an unlocked Apple Watch. Behind the scenes, the terminal and phone derive a one-time encryption key from a fresh ECDH P-256 key pair and the pass provider's public key — a new key on every tap, per Apple's own security documentation. Nothing about that is a static value sitting on a chip, waiting to be scanned.
Google Smart Tap works the same way at a conceptual level. Google describes it plainly as "a proprietary near-field communication protocol for conveying data between a mobile device and an NFC terminal," and a merchant has to be certified before any of it functions at all.
It helps to place both next to ideas you already know from NFCore. Host Card Emulation lets a phone pretend to be a card; VAS and Smart Tap sit a layer above that, defining what gets said once the radio link is open — the same multi-purpose tap idea the NFC Forum describes, where one tap triggers more than one backend action. That's why Apple and Google built their own protocols instead of extending NDEF: routing a tap to multiple services needs more machinery than a static data record can offer.
Where you'll see it
You'll run into "VAS Only" and "Payment and VAS" modes at retail counters that support Apple Wallet loyalty passes. Smart Tap shows up in transit, ticketing, and some Google Wallet retail integrations. Neither works just because a terminal already accepts Apple Pay or Google Pay — Apple is explicit that a business needs three separately certified pieces: a certified pass provider, a VAS-certified reader confirmed with the terminal vendor, and point-of-sale software built for the new modes.
That's a lot of certification for a tap-to-earn punch card. Which is exactly why plenty of small businesses skip VAS and Smart Tap and use a plain NDEF loyalty tag instead — no issuer backend, no certification, any phone reads it on the first tap.
Tips, gotchas, and a quick how-to with NFCore
The gotcha that trips up most people: even a VAS-certified reader can't read a pass from a merchant it isn't paired with. The payload is encrypted with that merchant's own key pair. One Apple developer on the official forums put it this way — the data "cannot be read even with Apple VAS compatible readers without one of these keys." A general-purpose NFC reader chip can carry out the raw radio handshake just fine, but it's still locked out by certification and encryption, not by anything missing in the silicon.
Point NFCore's Tag Inspector at an active VAS or Smart Tap terminal and you'll typically see the low-level ISO 14443 handshake, not the pass data. That's expected, not a bug. Where NFCore is genuinely useful is the other side of the fence: writing and inspecting your own NDEF tags for a loyalty program or check-in station, with none of the certification overhead VAS and Smart Tap require.
Frequently Asked Questions
Can my phone read someone else's Apple Wallet loyalty pass over NFC?
No. VAS pass data is encrypted with a key pair specific to the merchant who issued it, so even a certified VAS reader can't decode it without that merchant's key — a regular phone has no path to that key at all.
Is Google Smart Tap the same thing as Google Pay?
No. Smart Tap is the protocol Google Wallet uses to send non-payment pass data — loyalty, tickets, boarding passes — to a terminal. Google Pay transactions use a related but separate payment flow, and a terminal can support one without the other.
Does a VAS-certified terminal also work with NDEF tags?
Usually at the hardware level — most terminals run on standard ISO 14443 radios that can read plain NDEF tags too. But the software has to be configured to handle both, since VAS and NDEF decode in completely different ways.
Why would a small business skip VAS and Smart Tap and just use an NDEF tag?
Because VAS and Smart Tap each require separate certification across a pass provider, a reader, and POS software, while an NDEF tag works with any phone the moment you tap it — no certification, no backend, no authentication required.
The takeaway
VAS and Smart Tap are certified. They're encrypted. They authenticate every single tap — a different job entirely from the plain NDEF tags NFCore reads and writes every day. Setting up a loyalty program and don't want the certification paperwork? An NDEF tag gets you most of the experience with none of it.