The ATR (Answer T o R eset) from the card only indicates which card format, protocol and checksums of this data. See ATR Parsing Online
Now you know which card you should use the appropriate one (RS232 / RS485 / ZPL II / APDU - A pplication Smartrotocol D ata U nit smart card, as defined in ISO / IEC 7816-4) to obtain a UID (depending on whether it is a cascade of 1, 2 or 3, see ACG HF Multi ISO RFID Reader v1.0 p. 50 aka Omnikey5553 RS232) - for 14443 it has a length of up to 14 bytes, occupying the first two blocks in the first 16-byte sector (sector 0) and has built-in checksums. (See ISO14443 Protocols or NXP Semiconductors MF1ICS50 Specifications p. 8).
For 15693, RS232 / RS485 commands return the full 16-byte UID to (S) elect (Omnikey5553 RS232 and USB), but only the last 8 bytes (0xFF 0xCA 0x00 0x00 0x00 on Omnikey5022) will be returned to the APDU, despite being standard, since for a 15693 card, the card only answers 8 bytes at a time. For 14443 you can read a sector at a time (32 bytes of 4 blocks of 8 bytes each, enter the sector before reading / writing for S50), but for 15693 you can read or write only a block of 8 bytes at a time, and has other data in the returned buffer. You must encode whether you are blocking data at 32 or 8. This uses the standard SCardTransmit smart card protocol for the Windows API. Since the diagnostic application returned 16 bytes, this is the UID of the card. In addition, some 15693 addictions use a 14443 inverted key to obfuscate and prevent modification, while others hold a firmware that performs checks β either on a PC or on the card itself.
In all cases, this is not related to what is printed on the card β we use CODE128C barcodes printed on EV1 plastic cards that contain a GUID, which then refers to the corresponding UID in the database for transactions. Others (e.g. Wiegand, etc.) Print other data, such as area codes, key sets, etc.
Additional problems arise when trying to write data to 15693 - make sure that you complete your data on the 4 char interface, otherwise you will have problems with the previous data when you try to write a null "0x00" on top of an existing character in the block - so the code for the belt, braces and a piece of string after updating / writing to the card to make sure the data as needed. If the entire block is null, there is no problem, because the data is written as a 4-character block. DO NOT RUN the card user area unnecessarily, as they are NAND based and have a final record. (After recording, read the card again to make sure that the recorded data is recorded!)
The UID must be unique within the card set, but it also depends on the order of the number of cards, so the serial number was doubled (cascade number), and as soon as you have to moderate the trust in the UID from the Apple phone, since it violates the U in the UID - it can be configured to emulate a different UID.
NDEF is another aspect of cards to understand - it is well explained in the NFC NDEF standards, just be careful with the OTP and LOCK 14443 areas as they are unidirectional only once.
You can always use an Android phone with NFC and the TagData app for verification.