Hardware.

This page covers the physical side of member cards: who produces what, the stock to print on, what each carrier needs to work, and what to check before you approve a full run. The partner Card studio produces every file referenced here.

Who makes what

Reward Loyalty produces files. The physical media comes from a supplier, and which supplier depends on what your cards carry:

• You, with an office printer. The 10-up home sheet prints single-sided paper claim cards for a handout today. No supplier involved.
• A print shop. Prints and cuts the print-shop PDF into plastic or heavy stock. Right when your cards carry the QR, barcode, and number, and nothing has to be encoded.
• A card vendor. Produces PVC cards with variable data from the CSV, encodes magnetic stripes, and can supply and provision NFC inlays. Right when your cards carry a stripe or a tag, or when the run is large.

If you plan a stripe or NFC, say so when you ask for a quote. Both change the stock the vendor uses, and a stripe cannot be added to a card after printing.

Card stock

Print on standard CR80 PVC, the size and material of a bank card. The studio's print-shop PDF is at exact CR80 trim size with 3 mm bleed and crop marks, so a card printer or a print shop lays out and cuts the cards without rework. A card can carry any mix of the carriers below; you choose which ones your cards need.

The carriers

One code rides five carriers. Each has its own requirement on the plastic.

QR and barcode print quality

The QR code and the Code 128 barcode are read by optics, so print quality decides whether they scan:

• Print at full black on a light background, with quiet space around each code. The studio's layout reserves that space; ask the vendor not to crowd it with lamination marks or foil.
• Do not shrink a code so far that a scanner struggles, and keep it clear of the card's edge and any fold or emboss.
• Glossy lamination can throw reflections at a phone camera. A matte finish scans easier under shop lighting; if you order gloss, test a sample under your own lights.
• The printed code uses an unambiguous alphabet (no 0, 1, i, l, or o), so the human-readable number under it reads without confusion when someone types it.

Both the QR and the barcode encode the same code the studio issued, so a scanner reads either one to the same result.

Magnetic stripe

The magnetic stripe carries the code in a Track 1 wrapper. Two things live in two different places, and it helps to keep them straight:

• The layout marker. The magnetic-stripe band you toggle on in the studio design is a positioning marker. It reserves and places the stripe on the card art so the vendor lays the physical stripe and its encoding in the same spot. It carries no encodable data itself.
• The encodable value. The data to encode comes from the vendor CSV export, in the magstripe_track1 column. That value is the code in a Track 1 wrapper, %CODE?, uppercased. Hand this column to whoever encodes the stripe, and name the column in your order so the vendor does not guess.

At the counter a swipe reader acts as a keyboard wedge: it sends the swiped Track 1 data as keystrokes, and the recognizer normalizes it back to the code and resolves the member. Test one encoded sample on your own reader before the full run.

NFC tags

Each card can carry an NFC tag holding a single NDEF URL record: the card's claim URL. A phone that taps the tag opens that URL, the same /c/{code} link as the QR.

• Tag choice. Use an NTAG213 or better. The URL record fits an NTAG213 (144 bytes of user memory); a larger tag such as an NTAG215 or NTAG216 also works and leaves more room.
• Writing tags. The studio's NFC tag writer writes the claim URL to each tag in the browser, one tap at a time, on Chrome for Android (the one place Web NFC exists). Elsewhere, write the tags with a standard NFC-writing app using the claim URL, or have the vendor provision in bulk from the CSV's claim_url column. See the NFC tag writer in the studio.
• Know the limits. Each tag carries one card's URL, so tags are per-card work: writing them by phone suits dozens, and a vendor suits thousands. An iPhone reads NFC tags fine; it cannot write them from the browser.

Working with a card vendor

For a print run, hand a card vendor the studio outputs:

• The vendor CSV for variable-data printing. code and claim_url drive the per-card QR, barcode, and number; magstripe_track1 drives the stripe encoding. One row per card.
• The print-shop PDF when the vendor prints the card faces. Front and back, exact trim, 3 mm bleed, crop marks.

The CSV makes each card unique, so a vendor that prints variable data and encodes stripes or tags works from it. For NFC at scale, the same CSV's claim_url is the value to write to each tag.

What to check on the sample

Ask for one printed sample before the full run, and check it like a customer would use it:

• The QR scans at arm's length with a normal phone camera, under your shop's lighting.
• The printed number reads without effort, and matches the QR (scan it, then compare the code in the opened link).
• The dark modules sit on a clean white patch with visible space around them; nothing from the design, the lamination, or a foil edge crowds them.
• If the card has a stripe: swipe it at your own counter and watch the member resolve. Encoding mistakes surface here, not in the artwork.
• If the card has a tag: tap it with a phone and watch the claim page open.
• Front and back are the right way up relative to each other, and the trim did not clip the code zone.

Approve the sample, then release the run. The production checklist in the studio guide walks the whole route from test batch to full run.

Related topics

• Partner Card studio: the exports described here, and the print-run checklist
• Overview: the code and its carriers