In order to create a NFC passes like this sample pass, the following resources and configuration are required:
- An Apple Developer account that has been approved to issue NFC Pass Type Idntifier Certificartes - you can request NFC activation from the Apple Developer Portal (login required).
- An Apple NFC Pass Type Identifier Certificate.
- A terminal or other hardware capable of reading Apple VAS and Google SmartTap Passes, together with compatible Point of Sale or other software to process the pass payload.
Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines. You should provide as much detail as possible in your request and we recommend that you also follow up with your regional Apple Worldwide Developer Relations Manager a few days after submission.
Uploading your certificate
Both Apple Wallet and Google Pay passes will automatically have NFC support and will be encrypted with the same ECDSA key.
NFC Frequently Asked Questions
Can I issue a pass with a plain text payload?
Yes for Apple Pay, but only if you have developer mode enabled and have selected
NFC Pass Key Optional from the developer menu.
Why can't I read a pass with my NFC reader or NFC app?
Both Apple VAS (Value Added Services) and Google SmartTap use proprietary protocols to communicate data between the phone and the terminal. A regular NFC tag reader or NFC tag reading application cannot read an NFC pass.
Where can I get hardware that supports Apple VAS or Google SmartTap?
ID TECH are one of the leaders with almost their entire range supporting both Apple VAS and Google SmartTap. Ingenico, Verifone, and a number of other EMV terminal manufacturers have models that support one of both of the protocols.
Why do I need software or an integration to process the payload?
When you read an NFC pass, you are simply getting the data stored in the payload. This is restricted to a relatively small amount of just 64 characters. What happens next is rarely the same between two implementations. The payload could be a loyalty card number, a coupon or offer SKU, or a sporting event ticket or season pass. It is up to your implementation to know what to do with the payload, and how (if necessary) to respond after the NFC pass has been read. For example, with a coupon, you may wish to void the coupon after it has been used, whereas for loyalty, you may want to use the number to apply points and perhaps offer some coupons based on what has just been purchased, for a sporting event, you may wish to automatically grant access through a gate or turnstile. Currently there are very few systems on the market that automate these types of cases, and so it is often up to you (or your development partner) to implement this logic wherever NFC cards are being read.