Begin with the interaction
| Your use | Start with | Define before choosing |
|---|---|---|
| Phone opens digital content | An NFC tag and a prepared NDEF record | Destination URL, target phones, memory needs and write/lock policy |
| Event entry or guest access | The platform’s exact credential specification | IC, protocol, reader commands, data format and provisioning |
| Existing door or locker system | Written requirements from the system provider | Supported credential family, application, keys and permissions |
A tag does not supply the event platform, door controller or marketing website. Identify who operates that system and who is responsible for credentials. The same wristband material can contain different RFID assemblies; appearance is not a compatibility test.
Frequency narrows the choice
Our printed fabric configuration uses 13.56 MHz HF options. NFC phone interaction sits within compatible HF technologies, but not every 13.56 MHz credential supports the same commands, data layout or phone behaviour. Frequency is only one part of the specification.
If an existing system specifies a different frequency or credential family, keep that requirement. Do not substitute an HF chip simply because it fits the artwork or tag housing. Begin with the system provider’s supported specification and then select a suitable wristband assembly.
Understand the relevant IC families
| IC option | Useful distinction | Selection check |
|---|---|---|
| NTAG213 | 144 bytes of user memory | Check the encoded NDEF record fits |
| NTAG215 | 504 bytes of user memory | Choose for the actual data size, not extra security |
| NTAG216 | 888 bytes of user memory | Extra space does not establish platform compatibility |
| MIFARE DESFire EV3 | Managed applications and authenticated data access | Confirm application, keys, reader and provisioning requirements |
NXP specifies NTAG213/215/216 as NFC Forum Type 2 tag ICs using ISO/IEC 14443 Type A. The figures above are IC user memory; the full capacity is not a promise of usable URL length because an encoded record has overhead. These are chip properties, not a read-range or wristband performance guarantee.
DESFire EV3 follows a different application and command model. A reader supporting a basic Type A exchange does not automatically support the application you plan to use. Its security features only become useful when the reader, application and key-management workflow are configured correctly.
Separate printing, encoding and provisioning
- Printing puts a logo, number or code on the product. It does not write the chip.
- Encoding writes a defined payload. For a phone link, that commonly means an NDEF URL record.
- Provisioning prepares a managed credential: applications, access permissions and keys as required by the platform.
- Mapping connects a visible number or participant record to an electronic identifier. Specify the association and verification method.
A URL can point to a registration or payment website, but that does not make the tag a secure payment credential or the wristband a payment system. Test the actual phone journey before making a tag read-only; writing and locking policies can affect whether later changes are possible.
Test the complete credential
- Obtain the system provider’s exact IC, protocol, memory/application and data requirements. Record the reader model and relevant software version.
- Agree who supplies content, encodes credentials and manages any required keys. Keep confidential key material outside artwork and general project briefs.
- Evaluate a sample using the intended chip, antenna, wristband construction and encoding on the actual reader or target phones.
- Check successful and rejected reads, expected wearing orientation and the operating environment. Define acceptance with the platform team before a wider rollout.
A supported chip name is a starting point, not evidence of a tested assembly. Antenna, installation, firmware and credential configuration can change the outcome. Keep the approved combination recorded so substitutions are reviewed rather than assumed equivalent.
Bring the system requirements
Include your intended interaction, product format, quantity, chip requirement and encoding owner in the brief. For an existing system, attach its public credential specification or reader details. For a phone interaction, provide the destination and target devices. If you do not know the IC yet, state the use and involve your system provider instead of selecting a chip at random.
Sources & scope
The references below support the technical and process distinctions in this guide. Supplier constructions and IC properties do not establish BandWove product performance or system compatibility.
References checked October 30, 2026.