Templates

Templates define the look of every pass you issue: colors, logos, and layout. You design a template once, publish it, and issue any number of passes from it.

​

Creating a template

From Templates, use the create button. There are three starting points:

• Start blank: design from scratch.
• Duplicate existing: clone one of your templates.
• Browse Gallery: curated starting points by Passlet.

In the create dialog, pick a name and the wallets the template supports:

• Apple Wallet: a native Apple pass with images, web-service updates, and push refresh.
• Google Wallet: native Google publishing and Save to Wallet links.

At least one wallet is required; you can support both from one template.

​

Apple pass types

An Apple Wallet template has a pass type, chosen in the editor under Design → Pass Layout:

• Event Ticket: for admission passes. Offers two layouts, a full-bleed background image with an optional thumbnail, or a horizontal strip image. Fields span a header row, a primary field, and up to four secondary plus four auxiliary fields.
• Store Card / Loyalty: for loyalty cards, gift cards, and points cards. Uses a taller strip banner with the primary field (typically a balance or points total) displayed on it, and a single row of up to four fields below. To show a live balance, bind a variable to the primary field and update the pass whenever the balance changes; see Updating passes.
• Generic: for everything else, such as membership cards, access badges, and library cards. No feature image: the pass is your logo and colors with an optional thumbnail beside the primary field, then up to four secondary plus four auxiliary fields.

Switching the pass type before the first publish keeps your fields and variable bindings wherever the new type supports them. Fields that don’t fit (for example, auxiliary fields beyond a store card’s four-field row) are dropped, and images that the new type doesn’t use are left out of the published pass. Google Wallet passes are unaffected by the Apple pass type; they always use Google’s flexible card layout.

​

The poster design (iOS 27 and later)

A Generic template can ship a second, full-bleed design built around one large image. Turn it on with the Poster design (iOS 27+) switch under Design → Pass Layout. One pass, two designs. Both go into the same pass file. iOS 27 and later show the poster design; every older version shows the classic one. Holders never choose, and you never issue two passes. Your fields are shared. You write your content once. The poster design shows your logo, logo text and header fields at the top, then the primary field and one footer line on a frosted strip along the bottom edge, with the barcode above it; the classic design shows everything, including the secondary and auxiliary rows. Anything the poster front leaves out is still on the pass, on the detail view holders see when they tap it. Where one design needs different wording, a field can carry text of its own on the poster: see below. What the poster design adds. Two images of its own, under Images → Poster design:

• Poster artwork (upload 716 × 896, ratio 4:5): the full-bleed image the design is built around. Required before you can publish.
• Poster logo (upload 252 × 60, ratio 4.2:1): your logo, placed over the artwork at the top left.

Both sizes are the @2x uploads the editor recommends, so the pass looks sharp on every device; Apple renders them at 358 × 448 and 126 × 30 points. The strip along the bottom edge is that same artwork, blurred, so the pass background color does not change it. Plus a single Footer field, in the Fields tree: a value with no label, on the poster’s bottom line. Apple shows only the first one. Different text on one design. The two designs place your content very differently: the poster turns the primary field into a large title on the frosted strip and puts the header fields over the artwork. When wording that fits one does not fit the other, open the field and use Different on iOS 27+ next to its Label or Value. The input splits in two, Older versions above and iOS 27+ below, each starting from the text that was already there. Edit whichever half you want different; the other keeps working exactly as before, and a part you never split still reaches both designs when you edit it. Remove iOS 27+ text puts a part back to one text for both. Each half binds a variable like any other field, so the two designs can even draw from different variables. Fields the tree marks with an iOS 27+ chip are the ones carrying text of their own on the poster design. Only the fields both designs draw can differ: the header fields and the primary field. Logo text and the barcode look different on each design but Apple stores each of them once for the whole pass, so they always read the same. Translations work on the text itself, so a split field’s two versions each need their own entry under Translations. Use the iOS 27+ / Older versions switcher above the pass to check both designs while you work, and again on an issued pass’s preview. Switching is just a way of looking: it never changes what you publish. Turning the poster design off keeps every classic field, color and variable; the poster artwork, poster logo, footer field and any per-design text are removed. Unlike the pass type, the poster switch stays available after the template’s first publish, because a poster pass is still a Generic pass.

​

The template editor

The editor is a full-screen designer with a live preview per wallet (switch with the Apple / Google tabs in the top bar).

• Fields: header, primary, secondary, auxiliary, and back fields (Apple) or rows and modules (Google), with text styling and per-field bindings.
• Colors and images: background, foreground, and label colors, plus logos and artwork with cropping and retina uploads. On a template with two designs, uploads are grouped by the design they affect.
• Issuer name (Apple, under Design): the organization behind the pass. Apple Wallet shows it most prominently as the title of pass update notifications, and also next to the pass on the lock screen and in apps that preview the pass. Defaults to “Passlet”; set a fixed value or bind a variable. It can’t be left empty.
• Barcode: the scannable payload, bound to a variable like any other field. The Scanner properties decide which variable is the scan code used at the door: one of your own variables, or a Passlet-generated signed code computed for each pass.
• Links and back fields: content shown when the holder opens the pass details. For Apple Wallet, Back of pass fields hold links, terms, and support info; URLs and phone numbers in their values become tappable links, and labels and values bind variables like any other field, so back-field content can be filled in per pass. For Google Wallet, the Links section holds tappable links to web pages (https://), phone numbers (tel:), or email addresses (mailto:).
• Link button (Google, under Fields in the Misc. group): an optional button shown at the bottom of the pass that opens a web page. Set the URL (https://) and, if you like, a short button text; Google Wallet shows its own default label when you leave the text empty. Both the URL and the text can bind a variable, so each pass can point to its own page. Only web links are supported for now.
• Sharing (per wallet, under Sharing): whether the same pass can be held in many wallets. For Apple Wallet the toggle shows or hides the share action on the pass; anyone the holder shares it with can add it. New templates start with sharing off. For Google Wallet it controls whether any number of users can save the same pass, or only one user (the default): unless you allow multiple users, a published pass can only be saved by the first Google account that adds it.
• Localizations: translated field values (Apple).
• Expiration: an optional template-wide expiry for issued passes. Without one, passes never expire; redemption windows limit when passes can be scanned but never expire them.
• Redemption: when and how often passes can be scanned. See Redemption and scanning.

The top bar shows save state (“Unsaved changes”, “Saving…”, “Saved”), an Issues popover listing anything that blocks publishing, and provider setup status.

​

Variables and bindings

Variables are named placeholders filled in per pass at issue time. Define them in the editor with a type (text, integer, date/time, single choice, or multiple choice) plus an optional default and a preview value. Single and multiple choice variables also define the list of options a pass can hold, and need at least one option before the template can be saved. Bind variables into pass fields (or the barcode) and every issued pass renders its own values. A typical event ticket defines attendeeName, ticketType, and seat, binds them to the front fields, and lets the barcode encode the check-in payload. Multiple choice is the one type that cannot be bound to a pass field: its value is a list, used to select which redemption windows apply to a pass. See Redemption and scanning.

​

Draft vs. published

A template’s status is derived from its versions:

• Draft: no published version yet, or unpublished edits on top of one. Drafts can’t issue passes.
• Published: has a published version. Publish in the editor creates a new immutable version (v1, v2, and so on).

Issued passes stay pinned to the version they were issued from. Publishing a new version never changes existing passes; you upgrade them explicitly. See Updating passes.

​

Organizing templates

• The Templates library supports search, sort, a project filter, status chips (All / Published / Draft), and a table or gallery view.
• Move a template to a project; its passes move with it.
• Duplicate to iterate on a design without touching the original.
• Delete moves the template to Trash (Templates → Trash), from which it can be restored.