Pass fields are the labeled slots that carry a pass's text. In Apple Wallet every field is a key with a label and a value, and pass.json places it in one of five areas. Header fields sit at the top next to the logo and stay visible when passes are stacked, which makes them the place for the one thing a member must see at a glance. Primary fields are the large value in the body: a points balance, a tier, a seat. Secondary and auxiliary fields fill the rows beneath with supporting detail. Back fields are the reverse of the pass, with room for longer text such as terms, contact details and program rules.
The pass style decides how those areas are drawn. A store card gives the primary field a strip image behind it; an event ticket may run as a full-bleed poster; a generic pass offers a thumbnail. The number of fields each area holds is limited, and the wallet truncates rather than wraps, so a pass is designed around what fits, not what could be said.
Fields carry more than text. A numeric field can declare a number, currency or date style and the wallet formats the raw value for the member's locale. A field's change message turns an update into a lock screen notification. Semantic tags tell the system what a value means. For a loyalty program, the fields that matter are the ones that change: the points balance, the stamp count, the tier, each updated live rather than reprinted.
Google Wallet organizes the same information differently. A loyalty object has fixed fields for the program's essentials, such as points and account name, and adds text, image and link modules for everything else. A platform that issues to both wallets maps one pass design onto both layouts, so the merchant works with one set of fields and the wallets render what they can.