Can You Add That Card to Apple Wallet? The Eight Barcode Formats iOS 27 Supports

iOS 27 reached the public on 28 September 2026, and one of its Wallet changes is the kind of thing people had been asking for since Wallet existed: you can point the camera at a physical loyalty, membership or library card and save it as a pass. No issuer involvement, no app, no plastic in your pocket.

Whether it works on your card comes down to something almost none of the coverage names. A Wallet pass does not store a photo of your card. It stores the card number, plus an instruction telling iOS which kind of barcode to draw around it. Wallet can draw eight kinds. If your card uses a ninth, there is nothing for Wallet to redraw, and the feature will not help you however many times you try.

This article gives the exact list, taken from Apple developer documentation rather than from a feature round-up, explains what happens on an older iPhone, and covers what to do with the cards that are not on the list.

The Eight Formats a Wallet Pass Can Display

Apple documents the pass barcode in a structure called Pass.Barcodes. Its wording is unambiguous: Wallet supports QR, PDF 417, Aztec, Code 128, Code 39, Codabar, EAN 13 and Interleaved 2 of 5 (ITF). That is the whole set. Each one has a constant name a pass developer writes into the file, and each has a minimum iOS version.

Note the constant for the last one. ITF is written PKBarcodeFormatI2of5, after the symbology full name rather than its usual abbreviation — a detail worth knowing if you are writing a pass by hand and wondering why PKBarcodeFormatITF is rejected.

Why the Four New Ones Are the Interesting Part

Before iOS 27, a pass could carry a QR code, two aviation and rail formats, and Code 128. That set is fine for anything issued digitally, and it is why airline and rail passes have worked in Wallet for years. It is a poor match for the plastic in an actual wallet.

The physical cards people most want to digitise are old. A library card is very often Codabar, a symbology from 1972 that survives because library circulation systems were built around it and never had a reason to change. Gym, club and leisure-centre cards lean on Code 39, which encodes letters as well as digits and needs no check digit. Those two formats are exactly what was missing, and adding them is what turns Wallet from somewhere boarding passes live into somewhere your membership cards live.

EAN-13 and ITF are a different motivation. Both are retail and logistics symbologies, and some loyalty programmes simply reuse a 13-digit product-style number for membership. If you want the full picture of which symbology does what, our guide to barcode types covers the families and what each is for.

What Happens on an iPhone That Is Not on iOS 27

A pass does not carry one barcode. It carries an array of them, in priority order, and Apple is explicit about how iOS picks: PassKit displays the first supported barcode in the array. That is the fallback mechanism, and the documentation gives the exact case that matters here — if a pass provides EAN 13 and QR, the EAN 13 renders on iOS 27 and later, and the QR code renders on anything earlier.

The practical consequence for a pass issuer is a rule: if you use one of the four new formats, put an older format after it. The practical consequence for you as a user is subtler. A pass that someone built carelessly — one new-format barcode and no fallback — will show no barcode at all on an iPhone still on iOS 26. If you share a pass with someone and they report a blank space where the code should be, that is the likely cause, and it is the pass that is wrong, not their phone.

There is a second version question underneath the Wallet one. Scanning a card in to create a pass is reported to require an Apple Intelligence capable iPhone, which is a narrower set of devices than the set that can run iOS 27 at all. Apple does not document that requirement in the pass format reference, so treat it as what the early reporting says rather than as a specification: if Create a Pass is missing on a phone that is definitely on iOS 27, hardware is the first thing to suspect.

The Formats Wallet Cannot Draw

Eight supported symbologies means a good many unsupported ones, and several are common on cards people carry.

The UPC-A row needs a caveat, because it is the one place where a clean answer is tempting and wrong. A UPC-A number is twelve digits; an EAN-13 number is thirteen. Adding a leading zero to a UPC-A number produces a valid EAN-13 number for the same item, and most retail scanners handle that transparently. But that conversion is a decision the pass issuer makes when building the pass, not something you can do from the Wallet interface, and whether a particular till accepts the result depends on its configuration. If you want to see how the two numbering systems relate, the GTIN converter shows the same identifier in each form.

How to Find Out Which Format Your Card Uses

You cannot tell from the number. You can very often tell from the symbol, because the families look different, and failing that you can simply scan it and have the scanner report the format it found.

• By eye. Codabar and Code 39 both look like plain linear barcodes, but Code 39 prints an asterisk-like start and stop pattern and frequently has letters in its human-readable line, while Codabar starts and ends with a letter from A to D that is usually not printed at all. A 13-digit number in two groups under a symbol with long guard bars dropping below the bottom edge is EAN-13. Our barcode format identifier walks you through the shape questions and ranks the likely symbologies, and tells you whether iOS and Android can decode each one.
• By scanning it. Faster and conclusive. A scanner that requests every symbology reports which one it matched, along with the decoded text. This is the one case where the built-in camera app is no help at all: it acts on QR codes and ignores linear barcodes completely, which is a deliberate limitation of the app rather than of the phone. We cover what each platform can and cannot decode in what barcodes your phone can scan.

Three Limits of Create a Pass Worth Knowing Before You Rely on It

The feature does what it says. It is the expectations around it that cause trouble.

• A pass made this way is static. It holds the number your card holds. It does not know your points balance, it does not refresh, and it will not reflect anything the issuer changes. That is a consequence of how the pass is built rather than a bug, and it is the same static-versus-dynamic distinction we cover for static and dynamic QR codes.
• A card with no barcode cannot become a pass. If the credential lives on a magnetic stripe or an NFC chip with nothing scannable printed on the card, there is no payload to capture. Wallet is redrawing a barcode, not reading a chip — the difference between optical codes and NFC is exactly why. Where a card carries both, the chip is usually the one the reader wants, and the printed code is a fallback.
• A rotating code will break. Some membership and ticketing credentials deliberately change their code every minute or so, precisely to stop them being copied or screenshotted. Capture one into a static pass and you have captured a code that has already expired.

The Pass Field That Saves You at the Till

Apple documentation for the barcode structure includes a field called altText, described as the text to display near the barcode, for example a human-readable version of the barcode data in case the barcode does not scan. It is optional, and it is not shown on watchOS.

That field exists because barcodes on screens do fail, and more often than barcodes on card stock. If you are building a pass, fill it in. If you are using one, it is the thing that lets a cashier key your number in by hand when the scanner refuses. We go into why a display is harder to scan than a printed card, and what to try at the counter, in why a barcode on your phone screen will not always scan.

One more technical field is worth a mention because it causes a specific class of silent failure. messageEncoding takes an IANA character set name, and Apple own example is iso-8859-1. The older Wallet developer guide is blunt about why: barcode scanners and software typically use ISO 8859-1 or Windows-1252, and Unicode is poorly supported by most systems. A membership number with an accented character or a non-Latin character in it can therefore encode in a way a till will not read back correctly. The same trap exists in QR codes, and our character encoding checker shows which characters survive which encoding.

A Worked Example: A Library Card

Say your library card prints a 14-digit number and no letters, in a plain linear barcode with no guard bars dropping below the symbol, and no start or stop characters printed in the human-readable line.

1. Fourteen digits rules out EAN-13 (thirteen) and UPC-A (twelve).
2. No letters in the number does not rule out Code 39 or Code 128, both of which can carry digits only.
3. A scan reports Codabar, and shows the decoded value with a leading A and a trailing B that the card does not print.
4. Codabar is on Wallet list as of iOS 27, so this card can become a pass — and before iOS 27 it could not have. Those unprinted start and stop characters are normal for Codabar and are part of the payload the scanner returns.

That last step is the one people trip over. Seeing characters in the decoded output that are not printed on the card looks like tampering and almost never is. The same thing happens on gift cards, where issuers routinely wrap the card number in a programme prefix or a trailing check character — a point we make at length in the gift card barcode checker.

Frequently Asked Questions

Which barcode formats does Apple Wallet support?

Eight. Apple documentation for Pass.Barcodes lists QR, PDF 417, Aztec, Code 128, Code 39, Codabar, EAN 13 and Interleaved 2 of 5 (ITF). The first four have been available since iOS 9; Code 39, Codabar, EAN 13 and ITF were added in iOS 27.

Can I add any loyalty card to Apple Wallet in iOS 27?

Only one that carries a barcode or QR code in one of those eight symbologies. A card whose only credential is a magnetic stripe or an NFC chip has no payload for Wallet to capture, and a card in an unsupported symbology such as UPC-E or Code 93 has nothing Wallet can redraw. Identify the symbology first and the answer follows.

Why is my Apple Wallet pass showing no barcode?

The most likely cause on an older iPhone is a pass built with only one of the four iOS 27 formats and no fallback. Apple recommends providing several barcodes in priority order precisely for this, and iOS displays the first one it supports. If the array contains nothing supported, nothing is drawn. Updating iOS fixes it where the device allows; otherwise the pass issuer has to add a fallback.

Does a Wallet pass store a picture of my card?

No. It stores the payload — the number or string your card encodes — plus a format instruction, and iOS redraws the barcode from that. This is why the symbology matters so much, and also why a pass usually scans better than a photo of the same card: it is a freshly rendered symbol at the right size for the display, not a scaled-down bitmap.

Is a library card really Codabar?

Very often, yes. Codabar dates from the early 1970s and persists in library circulation, blood banking and photo processing because the systems built around it work and replacing them was never worth it. It is not a universal rule — plenty of modern library systems issue Code 128 or QR — so check your own card rather than assuming.

Why does the decoded number have extra characters the card does not print?

Because the human-readable line is artwork and the payload is data, and nothing requires them to be identical. Codabar always carries a start and stop character from A to D that is typically not printed. Code 39 traditionally delimits with asterisks. Issuers add prefixes and check characters. Extra characters around the number you expect are routine; a completely different number is not.

Will a pass I made from a physical card still work if the issuer changes my number?

No. A pass created by scanning a card is static: it holds the value it captured and has no channel back to the issuer. If your number is reissued, the pass is stale and you need to recreate it. Passes delivered by an issuer can update themselves; ones you make from plastic cannot.

Does Android have an equivalent of Create a Pass?

Not as a comparable built-in feature at the time of writing. Google Wallet accepts passes issued by a programme, and some retailers support adding a loyalty card by number, but scanning an arbitrary piece of plastic into a self-made pass is not a general Android capability in the way iOS 27 presents it. Keeping the card scanned and stored in a scanner app, with the number to hand, is the cross-platform answer.