ID Card Printer Requirements: What to Specify Before You Buy

Most ID card printer enquiries start with a model number. The better ones start with a requirement.

If you work in procurement, IT, WHS or facilities, you are often asked to specify an ID system before anyone has seen a printer. Schools, universities, government agencies and large corporates all tend to document the requirement first, then go to market. Getting that document right matters more than the brand you eventually choose, because a printer bought against a vague specification almost always fails on something nobody wrote down.

This post covers what to include. If you are further along and want a model recommendation instead, our guide to choosing an ID card printer works through the decision, and you can browse the full ID card printer range at any time.

Start With the Card, Not the Printer

The card is the deliverable. The printer is only how you produce it. Specify the card properly and most of the printer requirements fall out of it automatically.

Write down what the card actually has to do:

• Visual identification, and whether a photo is required
• Door access or car park entry
• Cashless payment, canteen or bar accounts
• Library loans, print release or locker access
• Time and attendance, or site sign on
• Proof of qualification, membership or clearance

A staff photo ID that opens doors and releases print jobs is a completely different specification from a visitor badge that is printed once and binned at the end of the day. Both are ID cards. Almost nothing else about them is the same.

Volume: Specify the Peak, Not the Average

Volume is the figure most specifications get wrong, usually by stating an average when the real constraint is a peak.

Annual volume tells you the class of printer. Peak volume tells you whether it will cope. A university issuing 12,000 cards a year is not printing 1,000 a month. It is printing several thousand in orientation week and very few in June. A printer sized on the monthly average will hold up the queue when it matters.

State all of the following:

• Total cards per year
• Largest single batch, and the window it must be completed in
• Number of issuance points, and whether printing is centralised or distributed across sites
• Whether printing is unattended batch or over the counter instant issuance

That last point has physical consequences. Unattended batch runs need hopper and output capacity so the printer is not babysat. Instant issuance needs a printer small enough and quiet enough to sit at a counter in front of the person waiting for the card.

Single or Dual Sided: Decide Once

Dual sided printing is difficult to add later. On most models it cannot be retrofitted at all, which makes this decision effectively permanent at the point of purchase.

Ask whether the back of the card will ever need to carry terms and conditions, emergency contacts, a barcode, lost card instructions, WHS information or a return address. If the answer is anything other than a firm no, specify dual sided. The difference at purchase is far smaller than replacing a fleet of printers in two years because the policy changed.

Encoding: Confirm It With the Team That Owns the Readers

Encoding is where specifications most often come unstuck, because the requirement usually sits with a different team from the one writing the document.

If the card has to open a door, work with a print management system, or interact with any reader you already own, the encoding must match that existing hardware. Common requirements include MIFARE Classic 1K or 4K, MIFARE DESFire EV2 or EV3, 125kHz proximity, HID iCLASS, and magnetic stripe.

Before the specification goes out, confirm three things with whoever owns the access control system:

• What card technology the readers actually use, not what was installed originally
• Whether the card number is read from the chip UID or from an encoded sector
• Whether existing cards must keep working while new ones are rolled out

That third point catches organisations out regularly. For background on the card types themselves, see an introduction to MIFARE cards. For a worked example of UIDs being read into PaperCut, student databases and library systems, see our post on student ID card integration.

Software and Integration: The Requirement Most Often Left Out

Plenty of specifications describe a printer in detail and say nothing at all about how cardholder data reaches it. That gap is usually discovered after the purchase order has gone out.

State where the data comes from and what has to happen around it:

• Manual entry, a CSV export, or a live connection to an HR, student or membership system
• Who designs the card template, and whether it is locked so operators cannot alter it
• How photos are captured, stored and retrieved
• Whether card issuance must be logged for audit
• What happens when a card is reported lost, and how quickly it must be cancelled
• How many operators need access, and at which sites

If a card has to be created or revoked automatically when someone joins or leaves, say so in the document. That is an integration requirement rather than a printer feature, and it will change the shortlist significantly.

Card Life and Environment

Expected card life should be a stated number, not an assumption. A student card issued for a single academic year and a contractor card carried on a construction site for three years are different products with different failure modes.

Specify:

• How long a card must remain legible and functional
• The environment it lives in: office, outdoor, industrial, wet, dusty
• Whether cards are worn on a lanyard, clipped to clothing, or kept in a wallet
• Whether the printed surface needs additional protection or a security overlay

Where cards are handled constantly or exposed to weather, retransfer printing produces a more durable result than direct to card, because the image is protected under a transfer film rather than printed onto the card surface. The two methods are compared side by side in the buying guide.

Support, Warranty and Consumable Supply

Hardware specifications are easy to compare. Support is what determines whether the system still works in year three, and it is the section most often reduced to a single line.

Include:

• Warranty term, and whether it is return to base or on site
• Turnaround time for a failed printer, and whether a loan unit is available
• Where consumables are held and the typical delivery time
• Whether ribbons and cards for the specified model are stocked in Australia
• Who provides technical support, and whether they are trained on that hardware
• Expected consumable cost per card, so the running cost is visible alongside the purchase price

PPC has supplied ID systems in Australia since 1986 and has more than 7,000 printers in the field. We hold authorised dealer status with Zebra, Evolis, HID, Matica and Magicard, and support customers from offices in Brisbane, Sydney and Melbourne. Organisations including UNSW, Brisbane Airport, Qantas and TAFE Queensland run their card issuance on systems we supply and service.

ID Card Printer Requirements Checklist

Use this as the skeleton of the specification document. Every line should have an answer before you approach suppliers.

Before You Go to Market

Two points worth settling before the specification is issued.

The first is price. Purchase price alone is not a useful comparison, because the running cost of ribbons and cards usually exceeds it over the life of the system. Ask each supplier to quote the printer, the software and the consumable cost per card against your stated volume, so the figures can be compared on the same basis. We quote against the requirement for that reason rather than publishing a single price.

The second is that you do not have to write the document alone. We regularly help schools, universities, government agencies and corporate teams define requirements before they go to market, including confirming encoding compatibility with the access control readers already installed. There is no obligation to buy from us as a result, and it is far cheaper than discovering a compatibility problem after the order is placed.