NFC Business Card Programmes for Teams: Chips, URLs and Ownership

Staff roll-out or white-label resale

Two kinds of buyer run these programmes. A company issuing cards to its own people needs URLs it controls, a routine for joiners and leavers, and a way to see whether the cards are used. A reseller, agency or white-label brand sells cards under its own name with its own platform or app; it needs cards the platform can identify and activate, printed with its brand, and reorders that match the first run.

The chip and card can be identical in both cases; what differs is who controls the URLs, what goes into each chip and what you do with the file that comes back.

Check these options against your system →

Chip choice: a copyable link or a signed tap

For a programme, the chip question is less about memory than about what a copied card could do. An NTAG213, 215 or 216 card normally holds a static NDEF record that any phone can read and a writing app can put onto another tag; on a phone-tap card the chip's password can block overwriting, but not that reading. A copy of a contact card does no harm, since it opens the same public page. It matters when the card unlocks something: a member rate, a partner portal, event entry, or a premium tier a reseller sells.

For those cards, NTAG 424 DNA is available on request. Set up for Secure Dynamic Messaging, it turns the URL into a Secure Unique NFC (SUN) message whose counter and AES-CMAC code change on each new tap. Your server holds the key, recomputes the code and refuses a counter it has already accepted or that arrives out of order, so a clone can only replay messages the original produced (NXP NTAG 424 DNA data sheet, section 9.3). Two limits remain. Messages captured and never submitted can each still pass once if they reach the server before the genuine card is next tapped. And the verification server runs on your side or your integrator's, since we do not supply verification software or hosting; any key handling for personalisation is agreed separately before production. How SUN verification works lists the server checks.

Two other chip choices. Contact data stored on the chip, for offline use, usually needs NTAG215 or NTAG216, can only be changed by re-encoding the cards in hand, and needs an app on iPhone; the NFC business card page weighs it against a hosted page. And NTAG21x chips can mirror their UID and tap counter into the URL as it is read, which tells cards apart in your analytics without a different URL per card; ask for it in the enquiry, and note that the mirror is not cryptographic, so it identifies cards without proving them genuine.

Check these options against your system →

Stay independent of any profile platform

Many card sellers encode a URL that points at their own profile service. That works until the subscription lapses, the vendor changes plans or closes, or you want a different tool; then every card in circulation points somewhere you no longer control, and printing new cards is the only fix.

One level of indirection avoids that. Encode a short path on your company's domain with a per-card code, and let your web server forward each code to wherever that person's page lives today. Switch platform, redesign the page or send the code to a booking calendar for a campaign, and no card has to move. The redirect table is a small file or database owned by IT, marketing or your platform team.

The same holds for a reseller: encode your own domain rather than the app vendor's, and the cards remain yours if you rebuild the app or change card supplier. The chip holds a standard NDEF URI record, not a proprietary format, so phones open it without our software. The redirect and the destination pages run on your systems, and we can encode against a URL pattern before it goes live, so the cards are ready when the pages are.

Activating white-label stock

A reseller usually holds cards before it knows who will own them. The cleanest model encodes every card with its own code on the platform's domain and binds that code to a customer only when the card is claimed. Your platform generates the codes and sends them to us as a file; we encode and print from it.

Make the codes random rather than sequential. If card 1001 opens /c/1001, anyone can try 1002 and walk through your customers' pages; a random code cannot be stepped through the same way, and a code of reasonable length still leaves plenty of room on an NTAG213.

1. First tap: the code is unclaimed, so the platform shows a claim page. The customer signs in or creates an account, and the code is bound to it.
2. Later taps: the platform sees a bound code and forwards to that customer's page.
3. Support calls: the customer reads out the number printed on the card; the ID list and your code file turn it into the chip's UID and code, so support finds the record without the card in hand.
4. Lost or resold cards: unbind the code; the next tap lands on the claim page again, or on a notice that the card is retired.
5. Reorders: each batch continues the card numbering, with new random codes from a new file, so codes never repeat across batches.

Per-person encoding and the ID list

Per-person cards are made from one data file, so the name on the face and the code in the chip come from the same row. The encoding service page lists what to settle before encoding starts.

1. Send the file. One row per card: the printed fields (name, title or card number) and the code or full URL to encode. White-label stock can be card numbers and codes only, with no names.
2. Approve a proof and an encoded sample. Tap the sample, follow it through your redirect, and sign it off before the run and before the chips are locked.
3. Production. Each card is printed and encoded from its own row, and left writable, password-protected or locked as you chose.
4. Read-back and data report. Each card is read back after encoding, and the order ships with a data report.
5. ID list. For numbered cards, a file pairs every chip's UID with its printed number, in Excel, CSV or XML. Load it into your redirect table or platform so support can find any card by its number or by its UID.

Joiners, movers and leavers

The failure mode of most card programmes is not technical. Months after launch, some of the cards belong to people who have changed title, moved office or left, and nobody has a process for it. With an owned redirect the fixes are small:

• Joiner: allocate the next code, assign a card from stock and create the redirect. Cards can be pre-encoded with codes and handed out from a drawer, which is why a buffer of unassigned cards belongs in the first order.
• Mover: change the page behind the code; the card is untouched.
• Leaver: point the code to a team page, the person's successor or the company contact page. Do it in the same offboarding checklist that disables their email.
• Lost card: retire the code and issue a new one. Because the card only holds a code, nothing personal is exposed.

Measuring whether the cards are used

A card programme costs design time, cards and the people who run it, so someone will ask whether it worked. Measure at the redirect: taps per card per month, share of cards with zero taps, and what happens on the destination page (contact saved, meeting booked, form sent). Compare cohorts: sales versus support, one office versus another, a campaign month versus a normal one.

A redirect count cannot tell a tap of the physical card from someone re-opening a URL they saved earlier. Where that difference matters, for example when a tap earns a loyalty benefit, NTAG 424 DNA narrows it: each new tap brings a fresh code, and a re-opened URL brings one the server has already seen. A URL read with an app and saved unopened can still pass once, so treat a valid code as strong evidence of a tap rather than proof of a live one. For plain contact sharing the redirect count is enough.

What to test on the sample before the run

Test the programme, not only the card. An encoded sample is where a wrong redirect, a mismatched row or a lock set too early costs nothing to fix.

• Your recipients' phones: a current iPhone and two or three Android models; the URL should open without an app.
• The redirect: each code resolves to the right page, an unassigned code lands on a sensible fallback, and the tap shows up in your analytics.
• Print against chip: for a few cards, check that the printed name or number, the row in the ID list and the code the chip returns all agree.
• The QR fallback: it points to the same short URL, for phones whose NFC is off.
• NTAG 424 DNA: your server accepts a genuine tap and refuses a URL it has already accepted, before the whole batch is encoded.
• Lock state: the sample is written and protected exactly as the batch will be.

Samples, quotation and supply

We make the cards in our Shenzhen factory, producing RFID and NFC products since 2008: NFC business cards, metal NFC cards, wooden cards, plain NFC cards blank or encoded, and Google review cards. NTAG213, 215 and 216 are the usual chips, and NTAG 424 DNA is available when requested; chip, body and printing options are on each product page.

Standard samples cost nothing, so you can try the card on your own phones, and a sample pack lets you compare materials; a customised sample, printed or encoded for you, carries a setup fee. For standard products the usual lead time is two to three weeks; the schedule for a printed, encoded run is set in the quotation. MOQ and price depend on chip, body, printing and quantity and are quoted for your specification. A workable enquiry gets a reply and a quotation within one business day.

For reorders, keep the approved sample, the signed artwork proof and the chip specification as the reference for each run, so the tenth order matches the first.