What counts as variable data, how to specify a numbering range that survives a reorder, and the three ways the printed number can relate to the chip.
Most of a card run is identical. The part that is not identical is where the cost, the lead time and the reprints live.
Variable data is anything that changes from one card to the next: a number, a name, a barcode, a QR code, the data written into the chip. Each of those is a separate production step with its own rules, and a specification that says only with numbering leaves four decisions unmade.
Those four decisions are cheap to make in an email and expensive to make after a run. A reprint on variable data is never partial: if the numbering format is wrong or the symbol does not scan, every card in the batch has the same defect, because that is what variable data being automated means. It is the one part of a card order where a five minute conversation genuinely prevents a five figure mistake.
This guide sets out what to specify and why, for whoever is assembling the brief: a trade printer, a distributor, an integrator or a programme owner.
On a single card you can have four things that vary, and they are laid down by four different machines at four different moments.
A numbering request usually arrives as a range. A range on its own is not a specification.
Say how many digits and whether they are zero padded. A run from 1 to 20,000 printed as 00001 looks deliberate. The same run printed as 1, 2, 3 and then 19999 looks like a mistake, and it breaks any system that sorts the number as text.
Rarely at 1. Most programmes start a second order where the first one stopped, which means the factory needs the last number used, not just the quantity. This is one of the things worth keeping in a specification record rather than in an email thread.
A check digit catches a mistyped number at the desk. If your system expects one, say which algorithm, because a number with a check digit calculated a different way is worse than no check digit at all.
Position, typeface, size and colour all belong in the same sentence. A number set in a light weight at six point on a dark background is technically correct and unusable at a desk, and a number placed where a thumb naturally rests wears off first. If the number will be read aloud over a phone, grouping the digits makes a measurable difference to how often it is read back correctly.
The sentence that prevents a reprint
Six digits, zero padded, starting at 020001, no check digit, printed bottom left on the front in black. That is a specification. From 20,001 upwards is a hope.
Two things decide whether a symbol scans: the symbology and the quiet zone. Neither is visible in a design review.
A linear barcode needs clear space either side, and a two dimensional code needs a clear border all round. Artwork that runs a coloured block right up to the symbol makes it unreadable, and this is by far the most common cause of a card that scans on the proof and fails at the desk.
A scanner reads contrast. Dark on light works. A mid blue symbol on a mid grey background does not, however good it looks. On a wooden card the grain reduces contrast further, so a symbol usually needs a printed light patch under it.
For a QR code what matters is the size of the smallest square, not the size of the whole symbol. A phone will read a small code with generous modules and fail on a larger one crammed with a long URL.
A QR code printed on a card is permanent for the life of the card, and the thing it points at is not. A URL that moves, a campaign that ends or a domain that is not renewed turns every card in circulation into a dead link. Where the destination might change, point the code at a short stable address you control and redirect from there, so the card outlives the campaign rather than the other way round.
This is the decision people forget to make, and it changes the production route rather than the artwork.
Option 03 is what most programmes actually want: a clean human readable number on the card, a UID in the chip, and a file that maps one to the other. That file is the same UID list that comes with an encoded order, with one extra column.
One detail decides whether that file is useful or not: the order of the rows. A mapping file that follows the physical order the cards were produced in, and cartons packed in that same order, means a desk can issue cards sequentially and the records match without anybody scanning anything. A file in a different order from the cards is technically complete and operationally useless. Say which you need, and it costs nothing.
Personalising with a name or a photograph is a different process again, closer to card printing than to card manufacturing, and it has a practical consequence: it is done on finished stock. A programme that issues named cards usually buys blank printed stock in volume and personalises locally as people join. Say at the quote which of the two you are doing, because it changes what leaves our line.
There is a data protection dimension worth naming. Sending a list of real names, photographs or membership records to a factory means sending personal data across a border, with whatever that implies for your own obligations. A programme that personalises locally avoids the question entirely, which is a reason to prefer it beyond the operational ones. Where names do have to be sent, send the minimum: the fields that get printed, and nothing else.
Everything in this article fits in one paragraph of a purchase order.
Then ask for one thing back before the run: a proof of the first, a middle and the last card, with the real data on them rather than placeholders. Placeholder proofs hide exactly the errors variable data produces, which are the ones that appear at the ends of a range rather than in the middle.
We manufacture for the trade and do not sell to your customers. Variable data, chip encoding, barcodes, QR and magnetic stripe encoding are all run on the same floor as the printing and the lamination, on PVC and recycled PVC, on wood and on key fobs.
Minimum order is 500 units, standard production thirteen calendar days from artwork approval to dispatch, and quotes come back the same working day. What else a factory needs in order to quote is in the guide to specifying a card order.
Yes, either by printing the UID itself or by mapping your own sequence to each UID in a list. The second is almost always the better answer, because a UID is not something a person can read back accurately.
Not on a normal run. It is a separate step on the line rather than a separate job. What does change the lead time is a data file that arrives late or in a format that has to be reworked.
Yes, from a supplied list. For a programme where people join continuously, it is usually better to hold blank printed stock and personalise locally.
Yes, with a printed light patch underneath it. Straight onto bare grain, the contrast is not reliable enough to promise.
A CSV with a header row, one row per card, in the order the cards should be produced. Say what each column is and how it is encoded, and the job runs without a single clarifying email.
On PVC, on wood and on moulded fobs, yes. Engraving is the durable option and it is single colour by nature, which makes it the right choice where the number has to stay readable for the life of the credential.
They can, and it is a useful pattern where some readers are phones and some are RFID. It has to be asked for explicitly, because it means the encoding step and the printing step read from the same record rather than running independently.
Ask this before the order, because two answers exist and they have different consequences. Either the number is reprinted so the delivered range is complete with no gaps, or the card is discarded and the range has a gap. A system that expects a contiguous range needs the first; a system that reconciles against a delivered list is fine with the second.
Send the reader or lock model, the quantity and the date you need them. That is enough for us to answer.
Talk to us