# Via Email

## 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 you can place the call-to-action in journeys you already run (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.

<details>

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

* 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.

</details>

### What you need before you start

You need a pass template and an issuance flow, 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 your CRM.

You also need a sender identity that customers trust, and that mailbox providers accept. Configure this once, then reuse it across all journeys. See [Email provider](https://docs.thewalletcrew.io/connect/email-provider) and [Configuring Custom Domain](https://docs.thewalletcrew.io/configure/platform/configuring-custom-domain).

{% hint style="info" %}
If you plan to send from your own 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 your database.

#### Flow A — Customer exists: direct download

Use this when the customer already has a loyalty account (or any stable identifier) and you want a one-tap install. 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 is the same principle as “signed Add to Wallet links” described in [Wallet card security](https://docs.thewalletcrew.io/configure/wallet/wallet-card-security).

**Example: signed direct-download link (HMAC)**

For customers who already exist in your CRM (and you can safely reference them with an internal identifier), you can send a link that directly resolves 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 your email list is larger than your loyalty base, or when you need missing data or consent 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](https://docs.thewalletcrew.io/enroll/enrolment-form).

{% hint style="warning" %}
Avoid putting PII in the URL (email, first name, last name). Use a token that your backend generates and your form can validate.
{% endhint %}

**Example: customer not in your CRM (pre-fill form)**

If the customer is not in your CRM yet, you can use the enrolment flow to capture missing data and then push it to your 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=cyril@neostore.cloud&firstName=Cyril&lastName=DURAND`

{% 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, you generate a token from The Wallet Crew (API or back-office), store it in your emailing audience, then inject it into the CTA URL.

Example:

`https://app.neostore.cloud/{tenantId}/mobile?neo.authToken={neostore-JWT}`

**How to include The Wallet Crew links in your emailing tool**

You can use one of The Wallet Crew’s partner connectors (for example Actito or Klaviyo) or your 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 your campaign tool.
{% endstep %}

{% step %}

#### Store the token in your audience

Store the token in your emailing database as a custom attribute, so you can merge it 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 your tool’s merge tag syntax.
{% endstep %}
{% endstepper %}

### Add the CTA to your emails

In practice, you embed a link behind a button such as “Add to Wallet”. You can do this in your marketing tool (campaign templates) or in transactional emails sent by The Wallet Crew.

#### CTA examples

![Email CTA example: “Add to Wallet” button inside a branded email](https://3566051324-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWLc8AHXW4tdrAXUBfrYF%2Fuploads%2Fgit-blob-ad2122f1b90dda593a9f1707888028bc9500c42a%2Freadme_1_3.png?alt=media)

*Use a high-contrast button and keep it above the fold on mobile.*

![Email CTA example: “Add to Wallet” link presented as a secondary action](https://3566051324-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWLc8AHXW4tdrAXUBfrYF%2Fuploads%2Fgit-blob-b078e29e393b89694c005d73471a9522dc606f40%2Freadme_2_3.png?alt=media)

*If you have multiple CTAs, keep the wallet CTA 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`) when you can.
* When you must use an **external identifier**, 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 you need the deep dive on supported mechanisms (HMAC, shared secret token, JWT), use [Wallet card security](https://docs.thewalletcrew.io/configure/wallet/wallet-card-security) as your source of truth.

### Segment your sends and measure adoption

Email works best when you don’t spam customers who already installed the pass. Segment on “pass installed” status when you can, then only target customers who are still not installed.

If you need to sync install status back into your CRM, see [Sync pass installation status to your CRM](https://docs.thewalletcrew.io/monitor/wallet-and-privileges/sync-pass-installation-status-to-your-crm).

You can also tag installs for attribution. If you’re distributing via web pages, see how tagging works with `neo.src` on [On your website](https://docs.thewalletcrew.io/enroll/on-your-website).

### Supported tools and connectors

You can send emails from your own email platform and embed Wallet Crew links in templates. You can also configure The Wallet Crew to send transactional emails as part of enrolment and verification journeys.

See: [Connectors](https://docs.thewalletcrew.io/enroll/via-email/connectors).

## FAQ

<details>

<summary><strong>Can we run marketing campaigns with these links?</strong></summary>

Yes. Use your marketing platform to send the campaign, and embed a secure Wallet Crew link behind your CTA.

If you want The Wallet Crew to send emails for enrolment and verification journeys, configure it first: [Email provider](https://docs.thewalletcrew.io/connect/email-provider).

</details>

<details>

<summary><strong>Should I include customer email or name in the URL?</strong></summary>

Avoid it. URLs are often logged and scanned. Use a token and let The Wallet Crew (or your backend) resolve the customer server-side.

</details>

<details>

<summary><strong>What happens if a customer forwards the email?</strong></summary>

If the link is a bearer token, the forwarded recipient can try to open it. If you must prevent that, use a short-lived token and add a verification step (email challenge) before issuing or revealing the pass.

</details>

<details>

<summary><strong>How do we avoid emailing customers who already installed the pass?</strong></summary>

Segment your audience on install status, then target only “not installed” profiles. If you need the data in your CRM, set up installation status sync: [Sync pass installation status to your CRM](https://docs.thewalletcrew.io/monitor/wallet-and-privileges/sync-pass-installation-status-to-your-crm).

</details>

<details>

<summary><strong>Where should this live: email, website, or mobile app?</strong></summary>

Use email when you already have a customer address and you want a low-effort conversion path.

Use web when the pass is installed from a logged-in area or checkout: [On your website](https://docs.thewalletcrew.io/enroll/on-your-website).

Use native app when you have an app and you want the fastest UX: [On your mobile app](https://docs.thewalletcrew.io/enroll/on-your-mobile-app).

</details>


---

# Agent Instructions: 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:

```
GET https://docs.thewalletcrew.io/enroll/via-email.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
