> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/get-started/readme/key-concepts.md).

# Key concepts

The Wallet Crew is built around a small set of concepts that appear throughout the platform. Understanding them once makes every other page faster to navigate.

{% hint style="info" %}
Payment cards such as Apple Pay and Google Pay are out of scope here. The Wallet Crew manages wallet passes such as loyalty cards, tickets, offers, and gift cards — not payment instruments.
{% endhint %}

<details>

<summary><strong>Real-world examples</strong></summary>

* A retail Brand may run one tenant, one loyalty template, and millions of customer passes.
* A ticketing Brand may use one ticket template per event family, then issue one pass per attendee.
* An international group may keep one tenant per country when teams, credentials, and data must stay separate.

</details>

## Tenant

A tenant is the isolated workspace for one Brand or wallet program inside The Wallet Crew. Everything configured there lives inside that tenant: wallet designs, passes, data, and team access.

A simple way to think about it is a private building, not a shared open space. What exists in one tenant does not mix with another tenant.

Most Brands have one tenant. Some groups run several tenants when separate brands, countries, or programs must stay independent, with their own Apple and Google credentials, their own data, and their own teams.

{% hint style="info" %}
A tenant is not a folder or a sub-account inside a shared workspace. Each tenant is a fully isolated environment. There is no cross-tenant data access by design.
{% endhint %}

## Pass template

A pass template is the model for one kind of wallet pass. It defines which wallet platform is targeted, how the pass looks, which fields appear, which barcode format is used, and how personalisation works.

The easiest analogy is a blueprint. The template defines the rules once, then The Wallet Crew reuses those rules every time a new pass is created from it.

A template is not a pass. It does not belong to one customer. It is the reusable definition behind many passes.

One Brand can use several templates at the same time. A loyalty card, a gift card, and an event ticket each usually need their own template.

## Pass

A pass is one wallet card, ticket, or voucher issued to one customer. It is created from a template and linked to Brand systems, such as a CRM, loyalty engine, POS, or ticketing platform.

If the template is the blueprint, the pass is the finished item in the customer’s wallet. One template can create thousands or millions of individual passes.

Passes move through a lifecycle:

* **Created** — the pass exists on the platform.
* **Installed** — the customer added it to Apple Wallet or Google Wallet.
* **Updated** — the pass content changed, such as a points balance, status, or message.
* **Uninstalled** — the customer removed it from the wallet.

Created and installed are two different moments. A pass can exist before a customer saves it to the wallet.

The Wallet Crew does not store customer personal data by default. Passes are usually linked through stable identifiers, such as a CRM ID or loyalty number, while core customer data stays in Brand systems.

## Environment

Environments separate testing from live operations. In practice, The Wallet Crew provides **QA** for testing and **production** for real customers.

QA is the rehearsal stage. Production is the live stage. QA mirrors production closely so testing reflects real conditions before launch.

These environments are fully isolated. A pass created in QA never appears in production, and production credentials or live data are not shared into QA.

Configuration can be copied between environments when needed. A third environment, **dev**, exists for internal engineering use only and is not accessible to customers.

## What comes next

* To understand what the platform can track after issuance, see [Monitoring](https://docs.thewalletcrew.io/guides-monitoring/).
* To start configuring a first template, see [Card design (colors, images, and fields)](/configure/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields.md).
* For a deeper technical model, start with [Structure](/developers-guides/pass-architecture/structure.md) and the [Developers](https://docs.thewalletcrew.io/developers-guides/) area.

## FAQ

<details>

<summary><strong>Can one template create many passes?</strong></summary>

Yes. That is the normal model. A template is reused to issue many individual passes that share the same structure and design.

</details>

<details>

<summary><strong>Can the same customer have several passes?</strong></summary>

Yes. One customer may hold several passes from the same Brand, such as one loyalty card and several event tickets. Each pass still remains its own record.

</details>

<details>

<summary><strong>Why keep QA and production separate?</strong></summary>

Separation reduces risk. Teams can test designs, links, and data flows in QA without affecting live customers or live credentials.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.thewalletcrew.io/get-started/readme/key-concepts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
