An NFC application may detect a tag and still fail to find the asset it belongs to. The reader's tag identifier, an NDEF message and the asset number in a maintenance database are different values with different owners. A useful purchase test follows the exact bytes returned by the intended device and software into the asset record, including what happens when a tag is replaced.
Decide which value opens the asset record
A tag-discovery ID is a low-level value made available when a tag is detected. An NDEF message is application data that a suitable tag may carry. The asset number is the business key maintained by the organization. The application can use a suitable, stable tag ID as a lookup key, or it can read an approved payload and resolve that value instead. Neither path makes the chip ID automatically equal to the asset number.
The Android Tag.getId() reference says the returned byte array may represent a stable UID, a random ID that changes on discovery, or no ID; its size and format depend on the tag technology. The NXP MIFARE UID application note, Rev. 4.1 of 5 July 2018, discusses random IDs and mixed UID lengths for the MIFARE products within its scope. These statements are reasons to identify the exact tag and configuration, not claims about every HF/NFC tag or any AIDC GO model.
If the observed ID is random or absent for the selected tag and access path, a persistent asset lookup cannot simply use that observation as a stable key. The project needs a documented alternative, such as an approved application payload or a chip-specific authenticated read, and must test it on the actual tag and application. Reading a tag ID also does not prove that the person holding it is authorized to access an asset record.
Preserve the complete bytes and the display rule
Record the raw byte sequence, its byte length, the API and version that returned it, and the rule used to display it. A hexadecimal string should retain leading zeroes. A reader that shows bytes in a different order or drops an initial zero can make one physical tag appear to have a different key in two systems. Do not reverse, pad or truncate values until the device interface and database contract explicitly define that transformation.
When migrating from a short-ID application, test both old and new tag lengths. NXP's note describes the integration problem of a reader capable of a longer UID while the background system accepts only four bytes. A successful RF read does not prove that the database has stored or compared the complete value. The HF RFID and NFC compatibility guide covers the separate protocol and data-access decision.
See how a shortened key can select the wrong asset
Consider an editorial example, not a read from real tags. Asset PUMP-014 is associated with raw seven-byte ID 04 A1 1B 2C 3D 7E 90. Asset PUMP-209 is associated with 04 F0 55 66 3D 7E 90. The complete byte sequences differ, but a legacy import that stores only the last three bytes gives both the key 3D 7E 90.
On a later scan, that truncated key could return the wrong pump or an ambiguous result. The correction is not to choose the first matching record. Preserve all seven observed bytes under the documented interface rule, detect duplicate normalized keys before activating the mapping, and show an exception when a read resolves to zero or more than one asset. These invented values illustrate the data problem; they do not assert that a named tag family or reader produces them.
The same test should include an ID beginning with 00, an ID of another supported length, and a read with no usable ID. Compare the application's stored bytes with its visible display and with the database lookup key. A text-only comparison is insufficient if two systems disagree on byte order or leading zeroes.
Keep replacement history on the asset, not on the tag
Suppose a damaged label on PUMP-014 is replaced. The asset master record remains PUMP-014; the authorized operator records why the old tag is retired, which new tag is attached, who approved the change and when the new association becomes active. The application must prevent the old observed key from silently resolving as an active tag after replacement, according to the project's retention and exception rules.
If the old tag cannot be read, use the controlled asset number, physical marking, work order or another approved source to confirm which asset is being relabelled. Read the new tag, check its complete value or approved payload against the intended asset record, and repeat the lookup in the target application. A successful read proves detection, not that the physical tag was attached to the correct asset. The damaged RFID tag replacement guide covers the broader approval and audit trail; this guide focuses on the NFC identifier-to-record key.
Separate lookup from access approval
Lookup asks, “Which record does this observed value refer to?” Authorization asks, “May this user and application see or change that record?” A stable UID can be a convenient index in a bounded system but is not, by itself, proof of the tag's authenticity or the operator's permission. Protected data access, where required, needs its own chip-specific security and application design. The NFC encoding and write-protection guide addresses a different task: preparing and controlling data written to the tag.
For acceptance, show the intended asset for a known tag, no asset for an unregistered tag, an explicit exception for a duplicate key, and the approved asset after a documented replacement. Test with the actual tag part, device configuration, Android and application builds, and database mapping rule. Keep the observed bytes and lookup result in the test record without treating a displayed value as a universal identifier format.
Bring the matching contract to the device discussion
The buyer should provide the exact tag part and technology, sample tags in each relevant configuration, the required read operation, the expected byte format or payload, database key length, replacement authority and access-control responsibility. The handheld terminal range is a starting point for device form-factor review, not evidence of HF/NFC support on a particular model. Use Integration Support to discuss which model-specific documentation and interface evidence are available for the shortlisted configuration.