> 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/guides-enrolment/enrolment/via-email.md).
# Via Email
Deliver Apple Wallet and Google Wallet passes by email using signed or token-based links that keep personal data out of the URL.
## Send “Add to Wallet” links by email
Email is the simplest way to reach existing customers and get them into Apple Wallet or Google Wallet. It works well for loyalty and membership cards because customers already trust this channel, and the call-to-action can be placed in journeys a brand already runs (welcome, purchase confirmation, service emails).
The key is to keep links secure. A wallet link is a bearer action. Anyone who gets the URL can try to open it. Use signed URLs or tokens, and avoid personal data in query parameters.
Real-world examples
* A retail brand sends “Your loyalty card is ready” after newsletter sign-up.
* A ticketing operator sends a “Save your ticket” email right after purchase.
* A luxury brand sends “Add your client card” after an in-store visit, with consent capture.
### What is needed before starting
A [pass template](/configure/advanced-configuration/wallet/template-configuration/how-to-create-a-template.md) and an issuance flow are required, plus a way to identify the customer. In most setups, The Wallet Crew resolves a pass either from an internal `passId` or from an external identifier coming from the brand CRM.
A sender identity that customers trust, and that mailbox providers accept, is also required. Configure this once, including the sending domain setup, then reuse it across all journeys.
{% hint style="info" %}
When sending from a brand-owned domain, set up SPF/DKIM and a DMARC policy. This improves deliverability and reduces phishing risk.
{% endhint %}
### Choose the right email flow
There are two common flows. Pick one based on whether the customer already exists in the brand database.
#### Flow A — Customer exists: direct download
Use this when the customer already has a loyalty account (or any stable identifier) and a one-tap install is the goal. The email contains a secure URL that opens The Wallet Crew pass page and lets the customer save the pass.
To prevent ID enumeration, do not expose predictable identifiers like a loyalty number without a signature or token. This follows the same principle as signed Add to Wallet links described in [Wallet card security](/configure/advanced-configuration/wallet/wallet-card-security.md).
**Example: signed direct-download link (HMAC)**
For customers who already exist in the CRM, and who can safely be referenced with an internal identifier, a link can resolve directly to their pass.
Example:
`https://app.neostore.cloud/{tenantId}/pass?id.y2.customerId={customerId}&id.y2.customerId.hmac={hmac256(customerId,tenantSecret)}`
Keep the `tenantSecret` server-side. Anyone who has it can generate valid links.
#### Flow B — Customer does not exist: enrolment first
Use this when the email list is larger than the loyalty base, or when missing data or consent must be collected before issuing a pass. The link sends the customer to an enrolment form, then The Wallet Crew issues the pass at the end of the form journey.
Start here: [Enrolment form](/guides-enrolment/enrolment/enrolment-form.md).
{% hint style="warning" %}
Avoid putting PII in the URL (email, first name, last name). Use a token generated by the brand backend and validated by the form.
{% endhint %}
**Example: customer not in the CRM (pre-fill form)**
If the customer is not in the CRM yet, the enrolment flow can capture missing data and then push it to the CRM. Some brands choose to pre-fill the form using query parameters from their email campaign tool.
Example (not recommended):
`https://app.neostore.cloud/{tenantId}/mobile?email=jane.doe@example.com&firstName=Jane&lastName=DOE`
{% hint style="danger" %}
This URL is **not signed**. Anyone can edit the query parameters. Avoid this setup in production.
{% endhint %}
**Recommended: token-based enrolment link (no PII in the URL)**
Use a token to secure the link. This avoids exposing personal data in the URL and reduces tampering risk.
In practice, a token is generated from The Wallet Crew (API or back-office), stored in the emailing audience, then injected into the CTA URL.
Example:
`https://app.neostore.cloud/{tenantId}/mobile?neo.authToken={neostore-JWT}`
**How to include The Wallet Crew links in an emailing tool**
One of The Wallet Crew’s partner connectors (for example Actito or Klaviyo) can be used, or the brand’s own platform (Mailchimp, Salesforce Marketing Cloud, Brevo/Sendinblue, etc.).
{% stepper %}
{% step %}
#### Generate the token
Generate the token with The Wallet Crew API, or generate it manually from The Wallet Crew back-office.
Use a stable input (typically a customer ID or an email), then keep the token opaque in the campaign tool.
{% endstep %}
{% step %}
#### Store the token in the audience
Store the token in the emailing database as a custom attribute, so it can be merged into the CTA URL.
{% endstep %}
{% step %}
#### Build the CTA URL
Use a button like “Add to Wallet” and point it to a tokenized URL:
`https://app.neostore.cloud/{tenantId}/mobile?neo.authToken={{profile.neostoreJwt}}`
Replace `{{profile.neostoreJwt}}` with the tool’s merge tag syntax.
{% endstep %}
{% endstepper %}
### Add the CTA to the emails
In practice, the link sits behind a button such as “Add to Wallet”. This can be done in the marketing tool (campaign templates) or in transactional emails sent by The Wallet Crew.
#### CTA examples
Check that the button is high-contrast and sits above the fold on mobile.
When several CTAs are present, check that the wallet CTA stays visually distinct.
### Keep links secure (recommended rules)
Signed links and tokens prevent tampering and reduce pass enumeration risk. They also keep personal data out of URLs that can be logged by proxies, mailbox scanners, or analytics tools.
Use these rules:
* Prefer an **opaque identifier** (`passId`) whenever possible.
* When an **external identifier** must be used, protect it with **HMAC**, a **shared secret token**, or a **JWT**.
* Keep token lifetimes short for email campaigns. Treat the link as a password.
* Assume emails can be forwarded. If forwarding must not work, add an email challenge or another verification step in the journey.
If a deeper security review is needed, cover HMAC, shared secret tokens, and JWT as part of the link design. [Wallet card security](/configure/advanced-configuration/wallet/wallet-card-security.md) is the source of truth. For broader organizational controls, see the [Security insurance plan](/policies/privacy-and-security/security-insurance-plan.md).
### Segment sends and measure adoption
Email works best when customers who already installed the pass are excluded. Segment on “pass installed” status whenever possible, then only target customers who are still not installed.
If install status must be synced back into the CRM, use the available event and integration flows.
Installs can also be tagged for attribution. For distribution via web pages, see how tagging works with `neo.src` on [On your website](/guides-enrolment/enrolment/on-your-website.md).
### Supported tools and connectors
Emails can be sent from a brand’s own email platform, with The Wallet Crew links embedded in the templates. The Wallet Crew can also be configured to send transactional emails as part of enrolment and verification journeys.
See: [Connectors](/guides-enrolment/enrolment/via-email/connectors.md).
## FAQ
Can we run marketing campaigns with these links?
Yes. Use the marketing platform to send the campaign, and embed a secure The Wallet Crew link behind the CTA.
If The Wallet Crew sends emails for enrolment and verification journeys, configure the sender identity and domain setup first.
Should a customer email or name be included in the URL?
Avoid it. URLs are often logged and scanned. Use a token and let The Wallet Crew (or the brand backend) resolve the customer server-side.
What happens if a customer forwards the email?
If the link is a bearer token, the forwarded recipient can try to open it. If that must be prevented, use a short-lived token and add a verification step (email challenge) before issuing or revealing the pass.
How do we avoid emailing customers who already installed the pass?
Segment the audience on install status, then target only “not installed” profiles. If the data must flow back into the CRM, use the installation status events in the integration setup.
Where should this live: email, website, or mobile app?
Use email when a customer address is already available and a low-effort conversion path is the goal.
Use web when the pass is installed from a logged-in area or checkout: [On your website](/guides-enrolment/enrolment/on-your-website.md).
Use a native app when one exists and the fastest UX is the goal: [On your mobile app](/guides-enrolment/enrolment/on-your-mobile-app.md).
---
# 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/guides-enrolment/enrolment/via-email.md?ask=&goal=
```
`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.
