ID card design

Design the card and the pass, from one set of data

Card artwork and wallet passes are built in the browser and bound to your cardholder data, so one template produces a correct credential for every person on your roll — and a reprint two years later comes out identical to the card it replaces.

Book a consultation See the whole platform

A template, not a file

Most card designs live in a designer's file and get re-exported by hand whenever something changes. Here the design is a template: fields are bound to cardholder data, so the name, ID number, photograph, barcode and expiry are filled in per person at print time.

  • Front and back artwork with correct bleed for CR-80 card stock.
  • Bound fields — names, preferred names, ID numbers, department, campus, expiry.
  • Photographs placed and cropped consistently on every card.
  • Barcodes and QR codes, including the verification QR that proves the card is genuine.

Locked when it matters

When an order is submitted, the template version it used is locked. Later edits create a new version and leave submitted orders alone. That is what makes a card reprinted in two years match the one in somebody's wallet, and it is why a design change never quietly rewrites history.

  • Versioned designs, with orders pinned to the version approved at the time.
  • Locked versions are immutable — enforced in the database, not just the interface.
  • Separate wallet design for the digital form of the same credential.
  • Per-holder-type templates, so students, staff and contractors can look different.
Examples

What a finished design looks like

One credential has two faces to design: the printed card and the pass on a phone. They carry the same serial number and the same verification code, but they are not the same artwork — a piece of PVC and a lock screen have different jobs.

Printed card, front Organisation band, ICAO portrait, bound name and ID fields, and both a barcode for existing library or door systems and the verification QR code.
Printed card, back Magnetic stripe where the site encodes one, conditions of use, and the card serial and verification code in plain text for anyone checking by hand.
Apple Wallet Built from Apple's field slots — header, primary, secondary and auxiliary — so the pass looks native rather than like a picture of a card. The back of the pass carries the terms and the verification link.
Google Wallet Google presents rows rather than Apple's slots, so the same credential is laid out to Google's own conventions instead of being forced into Apple's shape.

Illustrative designs. The institution and cardholder shown are fictional, and the QR codes are decorative rather than scannable.

Designing the digital pass

A wallet pass is designed, not exported

The commonest mistake with digital ID is to render the printed card as an image and put that in the wallet. It looks wrong on every phone, the text is unreadable at a glance, and none of it updates. Apple and Google both define what a pass is made of, and the platform designs to that.

  1. Choose what goes in each slot

    Apple gives you a header, one primary field, and rows of secondary and auxiliary fields. You decide which cardholder data lands in each — typically the name as primary, ID number and department secondary, campus and expiry auxiliary.

  2. Set the labels in your own words

    Every field carries a label as well as a value. “Student ID”, “Staff number” or “Employee ID” is your wording, not ours, and it can differ per holder type.

  3. Lay out the Google rows

    Google Wallet does not use Apple's slots, so the same credential gets its own row list. Designing both means neither platform gets a pass that was clearly built for the other.

  4. Write the back and the terms

    The reverse of a pass holds the cardholder name, organisation, card serial, verification code and a link that opens the public verification page — plus your conditions of use.

  5. Preview, then issue

    The designer warns before anything reaches a phone — an empty primary slot, or a fixed-text field with no text that would silently vanish from the pass.

Because the pass is built from fields rather than baked into a picture, a change to a cardholder's department or expiry reaches the phone over the air. Nothing is reissued and nobody is asked to download anything again.

Common questions

Frequently asked

Can we keep our existing card design?

Almost always. Bring your current artwork and we will rebuild it as a bound template so it prints from your cardholder data. Most institutions take the opportunity to tidy the back of the card at the same time.

Can different groups have different cards?

Yes. Templates are assigned by holder type, so students, staff, postgraduates and contractors can each carry a distinguishable card while sharing the same issuance process.

What if we change the design mid-year?

Edit the template and a new version is created. Orders already submitted keep printing against the version they were approved with, so a batch cannot come out half-old and half-new.

Does the card carry a barcode or QR code?

Both are supported. Cards can carry a barcode for existing library or access systems, and a verification QR code that resolves to a public page confirming the card is genuine and current.

See it against your own process

Tell us how you issue cards today and we will show you what this looks like for your institution. No obligation, and no sales script.

Book a consultation