RFID Card Encoding Service

What a factory card encoding service actually writes

'We can program those' is the easiest sentence in RFID sales to say and the hardest to prove at card 40,000. Proud Tek treats encoding as a dedicated production step with its own line, its own read-back gate and its own paper trail: the same controlled process writes a simple locked UID or a full DESFire application with diversified keys, and every format below is read-verified on 100% of cards before packing. If you want the underlying data model first, the RFID data encoding and memory guide is the primer; this page is the service.

• 100%Cards read-back verified
• 6Encoding families on the line
• 2008Direct factory since
• 3Audited ISO systems

• UID capture and database — the factory-assigned UID of every card is read and delivered as a CSV or Excel file mapping card number to UID, ready to import into your access or membership system.
• NDEF programming — URLs, vCards, Wi-Fi credentials, text and app-launch records written to NTAG 213, NTAG 215, NTAG 216 and NTAG 424 DNA in the NFC Forum NDEF format (Type 2 and Type 4), for tap-to-open experiences.
• MIFARE encoding — sector keys (Key A / Key B) and access-condition bytes on MIFARE Classic, and AES-128 keyed applications on MIFARE DESFire, for access control, transit, campus and loyalty programs.
• NTAG password and AUTH — a 32-bit password with AUTH0 lock on NTAG 213/215/216, and AES-128 SUN (Secure Unique NFC) configuration on NTAG 424 DNA so each tap returns a fresh cryptographic code for authentication.
• GS1 and EPC structures — SGTIN-96 and other EPC schemes written to the GS1 EPC Tag Data Standard for UHF retail-mandate cards, with EPC and access-password lock states set to spec.
• System and lock formats — HID iCLASS and prox formats plus hotel-lock encoding for VingCard, Salto, Dormakaba and Onity, matched to your deployed reader infrastructure so cards work on arrival.

The encoding capability menu — chip family, encoding type, key/lock service

The table is the fast way to see whether we cover your scheme. Each row pairs a chip family with the encoding type it carries, the key or lock service that protects it, and the data source we serialize it from. Chip names are the parts we stock and allocate directly; the full per-SKU list lives on the RFID cards pillar, and the security-grade families on the smart card page.

• NTAG 213 — 144 bytes of user memory (NFC Forum Type 2); NTAG 215 — 504 bytes; NTAG 216 — 888 bytes. We size the chip to the NDEF record you need to write, not the other way round.
• MIFARE Classic memory is split into sectors, each sealed by a sector trailer holding Key A, access bits and Key B; we write the exact sector map you specify (16-sector 1K or 40-sector 4K).
• MIFARE DESFire EV2/EV3 carries AES-128 keyed applications and files; we create the application directory and set file access rights so your credential app is cryptographically isolated from others on the card.
• NTAG 424 DNA writes an AES-128 SUN message: the tag mirrors a fresh, signed code into its URL on every tap, which your backend verifies — the basis for tap-to-verify brand protection.
• GS1 SGTIN-96 binds your company prefix, item reference and a per-card serial into a 96-bit EPC written to the GS1 EPC Tag Data Standard, the format UHF retail-mandate programs expect.

Serialization, variable data and print-to-chip matching

The hardest encoding jobs are the ones where the printed card and the chip data must agree: a badge whose printed number matches its sector record, a UHF card whose printed code matches its SGTIN-96 serial. Splitting print and encode across two facilities is how those drift apart and surface at the help desk. We run them as one matched traveler on the same floor, verified per card before packing; the card printing page owns the artwork side, this page owns the data.

• Variable data from your CSV, Excel or ERP export — each row mapped to one card's encoded fields (URL, credential, EPC serial), written in the shipping order you specify.
• Printed serial matched to chip data and verified per card, so a badge's printed number equals its encoded record and a UHF card's printed code equals its SGTIN-96 serial.
• Laser serialization and variable-data inkjet run in the same traveler as the encoding pass, so numbering can never drift out of sync with the data.
• One mapping-file deliverable ties it together: printed number, UID, encoded fields and EPC per card, as CSV, Excel or XML for a clean system import.
• Mixed personalization in a single batch — per-card printed name or photo combined with per-card encoded credentials, common for employee badge and student ID programs.

Key handling, security and QC proof

Encoding routinely touches the most sensitive material a card program owns: master keys, access credentials, member data. Handling is procedural, not ad hoc — the same controlled steps run for a boutique hotel's lock cards and a transit authority's fare cards. The checklist below is what your security and supplier-qualification teams verify, and every item is confirmable before you commit; the certifications page shows how to check the ISO registrations with the registrar.

• ✓100% read-back verification on every encoded card; any card whose written data does not match specification is automatically rejected and replaced.
• ✓Encoding database deliverable (CSV, Excel or XML) mapping each card's printed number or serial to its UID and encoded values, shipped with the order.
• ✓Key material received PGP-encrypted or via secure file transfer — never as a plain email attachment.
• ✓Air-gapped encoding stations: key sets are loaded onto isolated machines and never stored on networked systems.
• ✓Per-card key diversification for MIFARE Plus, MIFARE DESFire and NTAG 424 DNA so no two cards share a secret, with optional EPC and AUTH permalock applied only on written instruction.
• ✓Master keys securely deleted after production, or escrowed only on explicit instruction; NDAs and data-processing agreements signed as needed.
• ✓Functional testing on your specified reader or lock, and full batch traceability — date, operator, equipment and verification results retained seven years per ISO 9001.

The encode-lock-verify workflow

Every encoding job follows the same documented path, and each step leaves a record in the quality archive. Buyers who have been burned by a mis-encoded batch will recognise what it is built to prevent: a specification ambiguity discovered at card 40,000 instead of card one. The first-article gate exists precisely so a disagreement about byte order or lock behaviour surfaces before the volume run — the same discipline the hotel key card encoding guide and the DESFire EV1 vs EV2 vs EV3 comparison walk through for their formats.

• 3Accepted inputs (spec / CSV / sample)
• 1First-article approval gate
• 100%Read-back verified
• IncludedEncoding database

1. 1. Receive data

   You send an encoding spec, a CSV or ERP export, a key set (PGP-encrypted or via secure transfer), or a working sample card we read to reverse-engineer the format.

2. 2. Scheme lock

   We confirm the format interpretation in writing — byte order, sector map, AUTH and lock behaviour — and lock it on the production traveler with your data files attached.

3. 3. First article

   Initial cards are encoded and verified, and for access or hotel-lock formats tested on the actual reader or lock, so any disagreement surfaces before the run — not at card 40,000.

4. 4. Encode & lock

   The full run is encoded with 100% read-back; sector and AES keys are set, keys diversified per card, and EPC or AUTH permalock applied where your spec calls for it.

5. 5. Read-verify & deliver

   Every card is read back to confirm the written data matches specification, then ships with the encoding database and a functional test report on the lot.

FAQ