# Start with The Wallet Crew

Start with the main entry points for The Wallet Crew. Learn wallet fundamentals, understand the platform, then move into the right guide.

The Wallet Crew is a wallet pass platform that connects existing business systems — CRM, POS, loyalty engines, ticketing platforms — to Apple Wallet and Google Wallet. It handles pass design, distribution, and lifecycle updates without creating a new data silo. Customer data stays in your source systems; The Wallet Crew reads from them and delivers the wallet experience on top.

### Find what matters

The Wallet Crew documentation covers Apple Wallet and Google Wallet passes from strategy to operations. Start with the guided entry points below to find the right topic, product area, or implementation path faster.

<button type="button" class="button primary" data-action="ask" data-icon="gitbook-assistant">Ask a question…</button>

### Start here

This page is the fastest way to navigate the platform and the documentation. Use the two entry points below to understand wallet basics first, or to get a product overview before moving into a specific workflow.

{% columns %}
{% column %}

<p align="center"><a href="/pages/FNO2cJwShFXSz3nOAjYv"><img src="/files/IbPrt0L3ewz2y6yhjjTZ" alt="Overview illustration of wallet fundamentals across Apple Wallet and Google Wallet pass usage."></a></p>

#### [Learn wallet fundamentals →](/get-started/readme/wallet-fundamentals)

Understand what a pass is, how customers install it, and the core Apple and Google Wallet concepts.
{% endcolumn %}

{% column %}
[![Overview illustration of The Wallet Crew platform across pass design, distribution, and operations.](/files/gcQLuQcV3COGHe7TZn6q)](/get-started/readme/understand-platform)

#### [Understand the platform →](/get-started/readme/understand-platform)

Get the one-page overview of The Wallet Crew, the main use cases, and the core product model.
{% endcolumn %}
{% endcolumns %}

### Browse by topic

Browse by topic when the goal is already clear. Each section groups the core documentation for pass design, enrolment, lifecycle automation, scanning, security, configuration, integrations, monitoring, and developer workflows.

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="image">Cover image</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>Design</h4><p>Create pass layouts, assets, and branding rules for Apple Wallet and Google Wallet.</p></td><td><a href="/files/73OldG7RXTN9FvzZban9">/files/73OldG7RXTN9FvzZban9</a></td><td><a href="/spaces/96iMF0cPuLTC7ZRnUWG9">/spaces/96iMF0cPuLTC7ZRnUWG9</a></td></tr><tr><td><h4>Enrolment</h4><p>Set up pass distribution flows and save-to-wallet entry points across channels.</p></td><td><a href="/files/D0kysijcrZuL1yTjHLdD">/files/D0kysijcrZuL1yTjHLdD</a></td><td><a href="/spaces/lFokgwgJiwLXu7G8MVSJ">/spaces/lFokgwgJiwLXu7G8MVSJ</a></td></tr><tr><td><h4>Animate</h4><p>Drive engagement with updates, triggers, and pass lifecycle events.</p></td><td><a href="/files/36yV02UOnTch5fFYD95k">/files/36yV02UOnTch5fFYD95k</a></td><td><a href="/spaces/97ZAXMtqOjhvBBCfpmcE">/spaces/97ZAXMtqOjhvBBCfpmcE</a></td></tr><tr><td><h4>Scan</h4><p>Validate passes at the point of entry or service with reliable scan flows.</p></td><td><a href="/files/P6kRF2D6eM2UTMV3WOCD">/files/P6kRF2D6eM2UTMV3WOCD</a></td><td><a href="/spaces/iqBD4M0nHFMaFeKR75p9">/spaces/iqBD4M0nHFMaFeKR75p9</a></td></tr><tr><td><h4>Security</h4><p>Protect pass data, control access, and reduce fraud risks across workflows.</p></td><td><a href="/files/Qpi8N8jaGlccVpzbwqc7">/files/Qpi8N8jaGlccVpzbwqc7</a></td><td><a href="/spaces/DHEsGlkdBtbDsjoWOBvA">/spaces/DHEsGlkdBtbDsjoWOBvA</a></td></tr><tr><td><h4>Developers</h4><p>Integrate APIs, automate pass operations, and build custom wallet experiences.</p></td><td><a href="/files/v5AwT1r4mZB5Sc0gJ599">/files/v5AwT1r4mZB5Sc0gJ599</a></td><td><a href="/spaces/OnaDC4sjKAx53j0QV843">/spaces/OnaDC4sjKAx53j0QV843</a></td></tr><tr><td><h4>Configuration</h4><p>Manage workspace settings, product options, and operational defaults.</p></td><td><a href="/files/s9rxAemSbsPmCa9nDuc4">/files/s9rxAemSbsPmCa9nDuc4</a></td><td><a href="/spaces/DJrf9G0l7ArnvuwEH0a8">/spaces/DJrf9G0l7ArnvuwEH0a8</a></td></tr><tr><td><h4>Monitor</h4><p>Track delivery, usage, and platform health to operate passes at scale.</p></td><td><a href="/files/qeCd1j4A7qZzaR0fnNtw">/files/qeCd1j4A7qZzaR0fnNtw</a></td><td><a href="/spaces/EsokFUBfsbM9mlwavmMB">/spaces/EsokFUBfsbM9mlwavmMB</a></td></tr><tr><td><h4>Connectors</h4><p>Connect The Wallet Crew with external systems and data sources.</p></td><td><a href="/files/ER2ZcyBdz9K7vJcCTNFX">/files/ER2ZcyBdz9K7vJcCTNFX</a></td><td><a href="/spaces/lP7d71aYydav6e0pRkxc">/spaces/lP7d71aYydav6e0pRkxc</a></td></tr></tbody></table>


# Learn wallet fundamentals

Understand Apple Wallet and Google Wallet basics, plus the pass types you can configure in The Wallet Crew.

<div data-with-frame="true"><figure><img src="/files/8ch9RqPMAjjRqaU6OlXZ" alt="Overview of wallet fundamentals across Apple Wallet and Google Wallet."><figcaption><p>Wallet fundamentals start with the same principle on both platforms: one pass stays easy to save, easy to find, and easy to present.</p></figcaption></figure></div>

Mobile wallets like Apple Wallet and Google Wallet are no longer just digital folders for coupons. They’ve become central to how people organize the essentials of daily life. Customers add passes to their wallet because it keeps the most-used items (loyalty cards, tickets, offers, and more) at their fingertips without digging through emails, apps, or physical cards. Having a pass in the wallet means instant access when it matters: at checkout, at the gate, or at an event entrance, making each experience smoother and faster for customers.

Beyond simple passes, mobile wallets securely store customers’ **bank cards**, enabling contactless payments from a phone or smartwatch, which makes wallet apps a daily habit for purchases, travel, and access. Adding branded passes, such as a rewards card, concert ticket, or store offer, fits naturally into that routine, keeping the Brand visible each time customers open their wallet. Wallets also act as a **single, always-available hub** for personal credentials, where tickets, membership cards, boarding passes, and other passes live side by side, and this frequent, practical usage increases the likelihood that customers keep and engage with the passes a Brand provides, driving repeat interactions and deeper loyalty over time.

### One place for daily credentials

The Apple Wallet app and the Google Wallet app group items customers need in the moment. That includes coupons, loyalty cards, membership cards, event tickets, and more. Customers do not have to search emails or install an app.

<div data-with-frame="true"><figure><img src="/files/e75a9adf7cdd13b6aed313fc20908fedaf1b1086" alt="Apple Wallet and Google Wallet shown as the two main mobile wallet apps used by customers on iOS and Android."><figcaption><p>Mobile wallets are where customers keep their pass day to day.</p></figcaption></figure></div>

### Instant access at checkout or entry

Most Apple Wallet passes and Google Wallet passes are redeemed with a barcode or QR code. Some use NFC when compatible scanning hardware is available. Customers open the pass and present it in seconds.

### Always up to date

A pass is not a static PDF. An Apple Wallet pass and a Google Wallet pass can refresh over time. This matters when points change, balances decrease, or ticket details update.

Updates are part of the core lifecycle. For update mechanisms and delivery constraints, see [Push notifications](broken://spaces/97ZAXMtqOjhvBBCfpmcE/pages/9WXsRf2uAS4iw3Fiv7el). For identifiers and data model basics, see [Structure](/developers-guides/pass-architecture/structure).

## Pass types you can configure in The Wallet Crew

The Wallet Crew lets Brands create templates for several **Apple Wallet pass** and **Google Wallet pass** types. Each pass type comes with Apple and Google constraints. The template then defines layout, fields, images, and barcode.

When the template choice is unclear, [Pass types and templates](/guides-design/design/readme-1) helps narrow down the right starting point. When the pass type is already known, the relevant section below is the right entry point. Configuration then happens in the Template Designer.

{% hint style="info" %}
Wallet apps can store payment cards for contactless payments (Apple Pay / Google Pay). The Wallet Crew covers wallet passes (loyalty, tickets, offers, gift cards), not payment cards.
{% endhint %}

### Loyalty card

A loyalty card is a loyalty program **Apple Wallet pass** / **Google Wallet pass**. It rewards customers for coming back. It also makes the loyalty program feel tangible.

* **Best for:** points, stamps, tiered membership, and account identification at POS.
* **Key fields:** member ID, barcode/QR, points balance, tier/status, and key links.
* **Typical redemption:** scan at checkout to identify the customer, then update points/tier.

For the Brand, the goal is retention. Brands reward customers who purchase repeatedly. Brands can offer points, discounts, gifts, and other benefits. A loyalty card can also be an entry point to a customer account. This helps centralize data and personalize experiences.

For customers, the value is immediate. They can see their loyalty status and rewards. They do not need to remember a card number or bring plastic.

When the loyalty card is added to Apple Wallet or Google Wallet, it becomes easier to use. Customers can open the wallet app and select the card in seconds. They do not miss reward opportunities because points and perks stay visible on the pass.

<details>

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

* Retail: points balance and tier (Silver/Gold) updated after each purchase.
* QSR: stamp card (buy 8, get 1 free) with progress displayed on the pass.
* Beauty: member ID used at checkout, plus birthday reward shown as a field.

</details>

More details: [Loyalty Card Template Configuration](/guides-design/design/loyalty-card-template-configuration).

### Event ticket

An event ticket is an access-control **Apple Wallet pass** / **Google Wallet pass**. It is built for fast scanning at the entrance. It also makes it easy for attendees to find the right ticket.

* **Best for:** events with controlled entry and a “scan at gate” workflow.
* **Key fields:** event name, date/time, venue, seat/section, gate, barcode/QR.
* **Typical redemption:** scan at the entrance to validate entry and prevent duplicates.

For organizers, dematerializing tickets reduces loss and fraud risks. It speeds up entry because staff can scan a QR or barcode. It also supports last-minute changes. The same installed ticket can be updated when seat, gate, or schedule changes.

For attendees, adding a ticket to wallet is simple. They can add it from an email link, directly from a ticketing website, or by scanning a QR code on-site. At the venue, the ticket is ready to present in a few taps.

<details>

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

* Concert: seat info + QR scanned at the gate, with “doors open” time on the pass.
* Museum: timed entry ticket, where the date/time changes after reschedule.
* Festival: multi-day pass, with the same pass updated each day with new info.

</details>

More details: [Event ticket](/guides-design/design/event-ticket).

### Gift card

A gift card is a stored-value **Apple Wallet pass** / **Google Wallet pass**. It is meant to be redeemed over time. The key requirement is keeping the balance accurate after each redemption, top-up, or refund.

* **Best for:** stored value that decreases over time (balance use, top-ups, refunds).
* **Key fields:** card number, balance + currency, barcode/QR (or NFC), expiry date.
* **Typical redemption:** scan at checkout, apply partial or full amount, then update balance.

For Brands, gift cards generate revenue upfront. Customers often spend more than the card value. Gift cards are also frequently given to someone else. That makes them a strong acquisition channel for new customers.

For customers, a wallet gift card is easier to keep and use. The pass can display the current balance and a scannable barcode or QR code. It also reduces “lost card” scenarios because the gift card stays on the phone.

<details>

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

* Retail: gift card issued with €100, then balance updated after each redemption.
* Hospitality: voucher sold online, used in multiple partial payments on-site.
* Customer care: goodwill credit added as a top-up, then spent over time.

</details>

More details: [Gift card](/guides-design/design/gift-card).

### Offer

An offer is a coupon-style **Apple Wallet pass** / **Google Wallet pass**. It is used for discounts and time-bound incentives. Offers are often redeemed once, then become invalid.

* **Best for:** discounts, promo codes, and short campaigns with clear expiry rules.
* **Key fields:** offer title, expiry date, conditions, barcode/QR or promo code.
* **Typical redemption:** scan in-store or enter the code online, then mark as redeemed.

For Brands, offers are a practical way to drive traffic and conversion. They can also support segmentation. Different offers can be issued to different audiences. An offer can also be stopped or expired without requiring a reinstall.

For customers, wallet offers are easy to retrieve at checkout. The pass can display the expiry date and conditions clearly. It can also present a scannable barcode or a code to enter online.

<details>

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

* Retail: “-20% this weekend” coupon with an expiry date and single-use barcode.
* E-commerce: promo code shown on the pass, redeemed in checkout.
* CRM: win-back offer sent to inactive customers, then marked as redeemed in POS.

</details>

More details: [Offer](/guides-design/design/offer).

### Generic

Generic is the most flexible **Apple Wallet pass** / **Google Wallet pass** type. It fits use cases that do not match a dedicated template. It is a good fit for credentials that must be shown or scanned.

* **Best for:** membership cards, staff badges, warranty cards, pickup credentials, and “other”.
* **Key fields:** a stable identifier, barcode/QR, status, key facts, and support links.
* **Typical redemption:** visual check or scan, depending on the operational workflow.

For Brands, Generic helps when a custom layout is needed. Fields and display order are fully configurable. This is useful for membership cards that are not loyalty programs, staff passes, partner badges, warranty cards, or pickup credentials.

For customers, a Generic pass works like any other pass. It is easy to add, easy to find, and easy to present. It can also be updated when details change.

<details>

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

* Staff badge: employee name + role + QR for door access.
* Warranty card: product serial number + purchase date + support link.
* Click & collect: pickup credential with order ID + barcode for retrieval.

</details>

More details: [Generic](/guides-design/design/generic).

## FAQ

<details>

<summary><strong>Do customers need a mobile app to add a pass?</strong></summary>

No. Customers can add a pass from a Brand website or email. QR codes also work in-store or on-site. If a mobile app exists, an in-app flow can be added later.

</details>

<details>

<summary><strong>Do passes work offline?</strong></summary>

Usually yes for the moment of use. The barcode/QR and the visible fields are stored on the phone. Updates still require connectivity at some point to sync.

</details>

<details>

<summary><strong>What’s the difference between an Offer and a Gift card?</strong></summary>

Offers are for discounts and coupons. Gift cards are for stored value and balance updates. If the value can go down over time, it is almost always a Gift card.

</details>

<details>

<summary><strong>Can a pass be updated after it’s installed?</strong></summary>

Yes. This is one of the main advantages of mobile wallets. The Wallet Crew updates the same installed pass, so customers don’t need to re-add it.

</details>

<details>

<summary><strong>Can multiple pass types be used in one project?</strong></summary>

Yes. Many Brands start with one pass type (often loyalty) and add others later. Pass types can share the same distribution channels and operational setup.

</details>


# Key concepts

Understand the key concepts behind The Wallet Crew: tenant, pass template, pass, and environment.

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).
* For a deeper technical model, start with [Structure](/developers-guides/pass-architecture/structure) 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>


# Understand the platform

One-page overview of The Wallet Crew platform: what it is, what it does, and how teams use it.

<div data-with-frame="true"><figure><img src="/files/8w41WwRUpcqi86onfEVA" alt="Overview of The Wallet Crew platform for wallet pass design, distribution, and lifecycle operations."><figcaption><p>The Wallet Crew connects pass design, distribution, and lifecycle operations in one platform.</p></figcaption></figure></div>

The Wallet Crew is a white-label platform to **create, distribute, and operate wallet passes**. Brands use it for **loyalty cards, coupons, gift cards, tickets, and membership cards** in **Apple Wallet** and **Google Wallet**. Customers save the pass once, then the same pass stays **up to date over time**.

TWC acts as a bridge between existing business systems and wallet providers — it does not create a new data silo. Customer profiles, loyalty records, tickets, and transactions remain in their source systems. TWC reads from them, transforms the data into wallet-compatible content, and delivers updates when those records change.

TWC is not a self-service-only tool. Expertise and integration design are part of the engagement — each deployment is shaped around specific data models and business processes, with The Wallet Crew team involved throughout.

### What problems it solves

Most wallet projects start with the same friction. Customers need something scannable at checkout or entry. App installs stay low. Plastic cards add cost and logistics.

The Wallet Crew ships pass distribution through web, email, or QR. It then keeps that same installed pass accurate with updates over time. This creates one operating layer across Apple and Google while still following each provider’s rules.

Wallet is also not a “marketing-only” channel. A pass is a **digital credential** that customers can present in the moment, even with poor connectivity. Notifications can help, but the core value is simple: the pass remains available, scannable, and current.

### Who it’s for

The Wallet Crew is designed for business and technical teams. It supports deep configuration when needed, without forcing every stakeholder into the same level of detail.

Marketing and CRM teams get an owned surface on the phone that customers actually keep. Content can be refreshed through pass updates and, when relevant, wallet notifications.

Delivery, product, and operations teams ship faster because a launch does not depend on app adoption. IT, data, and security teams get a connected layer that links passes to CRM, loyalty engine, POS, and ticketing systems, with privacy-first setups by default.

### How it works (high level)

The Wallet Crew follows a simple lifecycle. A team designs a template, distributes an “Add to Wallet” entry point, then pushes updates over time.

1. **Design**: pick a pass type and configure branding, fields, and barcode/QR. Start with [Card design (colors, images, and fields)](/configure/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields).
2. **Connect data**: link each pass to source systems using stable identifiers, so CRM and POS remain the source of truth. See [Structure](/developers-guides/pass-architecture/structure).
3. **Distribute**: ship pass installation from owned channels. Most deployments start with [On your website](/guides-enrolment/enrolment/on-your-website) and [Via Email](/guides-enrolment/enrolment/via-email).
4. **Operate and engage**: update passes, trigger notifications, and measure adoption over time. Start with [Push notifications](broken://spaces/97ZAXMtqOjhvBBCfpmcE/pages/9WXsRf2uAS4iw3Fiv7el).

### Key capabilities

#### Wallet is reach, not only notifications

A wallet pass is a persistent object on the customer’s phone. It is easy to retrieve and show at the point of sale, at entry gates, or during customer service interactions. This makes wallet a practical channel for operations, not only for campaigns.

Notifications are optional and depend on use case and provider rules. In many programs, the main outcome is simply higher usage because the pass is quick to access and hard to lose.

#### Pass templates for Apple Wallet and Google Wallet

Templates are configured once, and The Wallet Crew generates the right Apple and Google payloads.

Most Brands start with a core set of templates, then expand over time. A common baseline includes [Loyalty Card Template Configuration](/guides-design/design/loyalty-card-template-configuration), [Offer](/guides-design/design/offer), [Gift card](/guides-design/design/gift-card), [Event ticket](/guides-design/design/event-ticket), and [Generic](/guides-design/design/generic).

For multi-language programs, labels and content can be translated per template. See [How to translate a template](/configure/advanced-configuration/wallet/template-configuration/how-to-translate-a-template).

#### Distribution without forcing a mobile app

Customers can add a pass without a mobile app, which is usually the biggest adoption lever. Most deployments start with web and email, then expand to QR codes in-store or on-site.

Common distribution entry points include [On your website](/guides-enrolment/enrolment/on-your-website), [Via Email](/guides-enrolment/enrolment/via-email), and, when an app exists, [On your mobile app](/guides-enrolment/enrolment/readme-1).

#### Updates, notifications, and location-based experiences

Wallet passes are meant to evolve, so the same installed pass can change after it’s saved.

Typical update scenarios include points and tier refresh after purchase, coupon state changes after redemption, gift card balance updates, and ticket changes.

Start with [Push notifications](broken://spaces/97ZAXMtqOjhvBBCfpmcE/pages/9WXsRf2uAS4iw3Fiv7el), then see [Geolocated Notifications](/guides-animation/engage-and-animate/geolocated-notifications).

Even without notifications, updates still matter. They keep the pass trustworthy by keeping balances, tiers, validity, and ticket states accurate when the customer opens the pass.

#### Integrations and APIs

The Wallet Crew sits between distribution channels and source systems.

Teams integrate through built-in connectors, including CRM, POS, and marketing automation tools. The API can also be used for issuance, updates, and lookups. Start with [API reference](https://docs.thewalletcrew.io/api-reference/).

#### Operations and in-store/on-site usage

Operating wallet at scale needs targeting and reliable redemption. Metadata can be attached to passes for segmentation, then used to target by store, country, tier, or channel. See [Structure](/developers-guides/pass-architecture/structure).

When staff tooling is needed, operators can use [Pass Scanner](/guides-scan/scan/pass-scanner) to scan and validate passes.

### What it is (and is not)

The Wallet Crew is a platform dedicated to managing the entire lifecycle of wallet passes. It enables you to design, distribute, and update passes while connecting seamlessly to your existing channels and data systems.

It is not a payment solution, all payment transactions continue to operate within Apple Pay and Google Pay. It also does not replace your existing business systems such as CRM, loyalty platforms, POS, or ticketing tools. Those systems remain your source of truth; The Wallet Crew simply extends their data into the wallet experience.

### Privacy and security

The Wallet Crew follows a **privacy-first approach**. Many deployments avoid storing personal data and store **external identifiers** instead. Those identifiers let The Wallet Crew fetch data and render the pass.

For distribution security, see [Wallet card security](/configure/advanced-configuration/wallet/wallet-card-security). It covers signed links, HMAC/JWT, and ID enumeration risks.

### FAQ

<details>

<summary><strong>Do customers need to install a mobile app?</strong></summary>

No. Most Brands start without an app, and customers add passes from web pages, email, or QR codes. When an app exists, an in-app flow can be added later. See [On your mobile app](/guides-enrolment/enrolment/readme-1).

</details>

<details>

<summary><strong>Can Brand-owned Apple and Google issuer accounts be used?</strong></summary>

Yes. Apple and Google require Brand-owned issuer credentials in production, and The Wallet Crew issues passes under the Brand identity.

Start with [Apple & Google wallet](/configure/advanced-configuration/wallet/apple-and-google-wallet).

</details>

<details>

<summary><strong>How do pass updates work after installation?</strong></summary>

Pass data is updated from source systems, and The Wallet Crew pushes the change to Apple and Google. Start with [Push notifications](broken://spaces/97ZAXMtqOjhvBBCfpmcE/pages/9WXsRf2uAS4iw3Fiv7el). It explains triggers and what customers see.

</details>

<details>

<summary><strong>Do you store personal data?</strong></summary>

It depends on the deployment. Many deployments store only identifiers and operational metadata, while the CRM remains the source of truth for PII.

For the data model, see [Structure](/developers-guides/pass-architecture/structure).

</details>

<details>

<summary><strong>Can we scan and validate passes in-store or at event entry?</strong></summary>

Yes. Passes can be scanned using barcode or QR readers. For a dedicated operator experience, use [Pass Scanner](/guides-scan/scan/pass-scanner).

</details>


# Implementation roadmap

Typical sequence to launch a wallet program with The Wallet Crew, from contract signature to go-live, with a lot-based delivery approach.

This roadmap describes the typical sequence to launch a wallet program with The Wallet Crew. It starts at contract signature and ends at go‑live, with an agile delivery approach and small, testable increments.

<details>

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

* A retail Brand launches a loyalty card and focuses first on POS scanning, then adds CRM campaigns.
* A venue integrates ticketing first to ensure entry works, then adds post-event engagement.
* A Brand replaces plastic membership cards with a digital pass, using a phased rollout per region.
* A Brand starts with a single “core” template, then adds seasonal or event-specific templates.

</details>

## Roadmap overview

Most wallet projects succeed when operations lead the design. The pass must work at the point of sale or at the gate before it becomes a marketing channel. The Wallet Crew therefore prioritizes early validation of the end‑to‑end chain: source systems → pass data → distribution → wallet installation → redemption.

The sequence below is the default. Some steps can overlap. The lot-based delivery approach stays the same: ship small increments, validate quickly on real devices, then expand scope.

## Project phases (contract → go-live)

{% stepper %}
{% step %}

#### 1) Contract and kickoff

This phase aligns on scope, stakeholders, and constraints. It sets the working cadence and defines what “done” means for the first release.

Typical outputs include a project calendar, a list of owners, and a first go‑live target.
{% endstep %}

{% step %}

#### 2) Requirements collection (atelier)

The Wallet Crew runs a dedicated atelier to capture Brand needs and constraints. It is a working session, not a presentation. The goal is to converge on a first “minimal viable” wallet experience.

The atelier usually covers pass use case, distribution channels, redemption/scanning constraints, required data fields, consent/GDPR expectations, and reporting needs.
{% endstep %}

{% step %}

#### 3) Technical setup (tenant + wallets + custom domain)

This phase makes the platform ready for secure testing and future production issuance.

It typically includes:

* Tenant provisioning (staging and, when relevant, production).
* Apple Wallet configuration (certificates, push keys, signing identity).
* Google Wallet configuration (issuer account access, service account / API credentials).
* Custom domain setup for branded links and hosted pages, when required.

Related docs:

* Wallet provider setup: [Apple & Google wallet](/configure/advanced-configuration/wallet/wallet-card-security)
* Apple certificates: [Apple Wallet certificates](/configure/advanced-configuration/wallet/apple-and-google-wallet/apple-wallet-certificates)
* Google issuer setup: [Google Wallet account](/configure/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account)
* Custom domain: [Custom domain](/configure/advanced-configuration/platform/custom-domain)
  {% endstep %}

{% step %}

#### 4) IT architecture definition (system-of-record and data ownership)

This phase defines where The Wallet Crew sits in the overall IT landscape. It also clarifies which systems remain the source of truth for each data element displayed on the pass.

The key decision is the data flow: what triggers pass creation, how updates are computed, and how identifiers link a pass to Brand systems over time.

Related docs:

* Data model and identifiers: [Structure](/developers-guides/pass-architecture/structure)
  {% endstep %}

{% step %}

#### 5) Project definition and lot-based delivery (agile increments)

This phase turns the scope into shippable lots. Each lot should be testable without future work. This reduces go‑live risk and avoids “big bang” rollouts.

A common breakdown is:

* Lot 1: one template + one distribution channel + one redemption path.
* Lot 2: updates lifecycle (field refresh, status changes, deactivation rules).
* Lot 3: segmentation, analytics, and operational tooling.
* Lot 4: marketing automation, notifications, and personalization at scale.
  {% endstep %}

{% step %}

#### 6) User experience flow (install → present → update)

This phase defines the customer journey and the operational journey. It includes entry points (“Add to Wallet”), install screens, fallback flows (desktop → QR), and how the pass is retrieved later.

Distribution choices typically map to these docs:

* [Enrolment form](/guides-enrolment/enrolment/enrolment-form)
* [On your website](/guides-enrolment/enrolment/on-your-website)
* [Via Email](/guides-enrolment/enrolment/via-email)
* [On your mobile app](/guides-enrolment/enrolment/readme-1)
  {% endstep %}

{% step %}

#### 7) Pass configuration (templates + fields + barcode)

This phase translates the UX and data model into a pass template configuration for Apple Wallet and Google Wallet. It covers branding assets, field layout, links, and barcode/QR payload.

Template configuration lives under:

* [Template configuration](/configure/advanced-configuration/wallet/template-configuration)
* Design reference: [Card design (colors, images, and fields)](/configure/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields)
  {% endstep %}

{% step %}

#### 8) Connect core tools first (ticketing, POS, CRM/loyalty)

The Wallet Crew recommends connecting the core operational systems before adding marketing layers. Wallet is a credential. It must work reliably where the pass is used.

This phase usually delivers:

* A working creation/update feed from core systems.
* A stable identifier strategy (membership number, ticket ID, gift card code, …).
* A validated redemption flow in real conditions (scanner, POS, entry gate).

Once this is stable, marketing automation can be added without risking operations.
{% endstep %}

{% step %}

#### 9) Add marketing and engagement (optional, after core validation)

This phase adds lifecycle engagement such as wallet notifications, geolocation, and marketing automation connectors. It is easier to iterate once core issuance and redemption are stable.

Entry points:

* Notifications: [Push notifications](broken://spaces/97ZAXMtqOjhvBBCfpmcE/pages/9WXsRf2uAS4iw3Fiv7el)
* Location triggers: [Geolocated Notifications](/guides-animation/engage-and-animate/geolocated-notifications)
* Marketing connectors: [Marketing automation](/connectors/marketing-automation)
  {% endstep %}

{% step %}

#### 10) Go-live and operations

This phase completes production readiness: monitoring, support runbooks, and controlled rollout. It also defines how changes are shipped after go‑live (template updates, field additions, new lots).

Typical validation includes a production pilot, real-device checks on iOS and Android, and scanning tests in representative environments.
{% endstep %}
{% endstepper %}

## Common deliverables (what “done” looks like)

At go‑live, the minimal expected package usually includes one pass template, one distribution flow, and one operational redemption flow. It also includes a clear update strategy, so the pass remains trustworthy after installation.

As the program scales, deliverables expand to additional templates, segmentation, reporting, and optional engagement features.

## FAQ

<details>

<summary><strong>Can the project start before Apple/Google accounts are fully approved?</strong></summary>

Yes, in most cases. Requirements, UX definition, and template design can start immediately. Wallet provider approvals and credentials must be completed before production issuance.

</details>

<details>

<summary><strong>Why does The Wallet Crew recommend connecting core systems before marketing tools?</strong></summary>

Because wallet is used in operational moments. If POS or ticketing redemption is unstable, marketing amplification increases support load. Once core issuance, updates, and redemption are reliable, marketing automation and notifications can be added safely.

</details>

<details>

<summary><strong>Can the scope be limited to a single template for the first release?</strong></summary>

Yes. A single template is often the best first lot. It keeps the data model and governance simple, and it enables faster validation on devices and in stores/venues.

</details>

<details>

<summary><strong>Is a custom domain mandatory?</strong></summary>

No. A custom domain is recommended when branded links and brand-aligned hosted pages are required. Some projects start without it, then add it before go‑live.

</details>

<details>

<summary><strong>What typically causes delays?</strong></summary>

Delays usually come from external dependencies: wallet provider approvals, DNS changes for custom domains, security reviews, and clarifying data ownership between systems. Keeping lots small reduces the impact of these delays.

</details>


# Find your starting point

Choose the right The Wallet Crew entry pages based on role, goal, and level of detail.

Different teams use The Wallet Crew for different reasons. Some need the product model first. Others need data flows, launch sequence, or technical reference. This page points each role to the right first pages.

#### **Marketing & CRM**

Marketing and CRM teams usually arrive asking how the platform works and what it actually does.

The useful first model is simple: design a pass, distribute it, then keep it current after installation. [Understand the platform](/get-started/readme/understand-platform) gives that lifecycle in one page. [Learn wallet fundamentals](/get-started/readme/wallet-fundamentals) explains how passes behave in Apple Wallet and Google Wallet. When the goal shifts to acquisition and conversion, [Enrolment](https://docs.thewalletcrew.io/guides-enrolment/) is the right hub for website, email, and in-app entry points.

#### **IT / Data / Security**

IT, data, and security teams usually arrive asking how data is synced and which system owns what.

The main question is usually data flow, not only integration. The Wallet Crew often stores identifiers and operational metadata, while core systems stay the source of truth. Start with [Understand the platform](/get-started/readme/understand-platform), especially the “How it works” section, to place the platform in the stack. Then move to [Structure](/developers-guides/pass-architecture/structure) for identifiers, ownership, and pass architecture, and use [Connectors](https://docs.thewalletcrew.io/connectors/) to review supported integration patterns.

#### **Developer**

Developers usually arrive asking where the technical reference starts and how authentication works.

The shortest route is the [Developers](https://docs.thewalletcrew.io/developers-guides/) area, which groups pass architecture and API key setup. The [API reference](https://docs.thewalletcrew.io/api-reference/) is the next stop for endpoints, payloads, and response shapes. Use [Connectors](https://docs.thewalletcrew.io/connectors/) when the project depends on an existing integration instead of a custom flow.

#### **Project manager**

Project managers usually arrive asking how The Wallet Crew fits into the existing stack and what happens first.

The fastest orientation starts with the [Implementation Roadmap](/get-started/readme/implementation-roadmap), which lays out the common launch sequence from kickoff to go-live. It shows when data ownership, distribution, and operational validation should be decided. [Understand the platform](/get-started/readme/understand-platform) explains where The Wallet Crew sits between source systems and wallet channels. [Connectors](https://docs.thewalletcrew.io/connectors/) helps map the project against existing CRM, POS, ticketing, and marketing tools.

#### **Stakeholder / Executive**

Stakeholders and executives usually arrive asking whether the platform is documented clearly enough to support a decision.

The quickest confidence check starts with [Understand the platform](/get-started/readme/understand-platform). It gives a short, factual view of the product model, scope, and operating principles. [Implementation Roadmap](/get-started/readme/implementation-roadmap) shows that delivery follows a defined sequence, with clear phases and validation points. Together, those pages show how The Wallet Crew fits into a real programme without going into technical detail.


# Guides

Browse The Wallet Crew guides for Apple Wallet and Google Wallet pass design, configuration, distribution, geolocated engagement, monitoring, and scan validation.

The Wallet Crew guides cover the full lifecycle of an Apple Wallet and Google Wallet program. They help Brands move from pass design and configuration to distribution, geolocated engagement, monitoring, and scan validation.

<details>

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

* A retail Brand configures a loyalty card, publishes an enrolment form, then triggers geolocated notifications near stores.
* A ticketing Brand configures wallet credentials, distributes tickets by email, then validates entry with real-time scans.
* A gift card program synchronizes balances, monitors pass activity, and keeps the same installed pass current over time.

</details>

### Browse the core guides

Each guide below covers one operational area. Start with Configuration when the wallet project is still being set up. Start with Design or Enrolment when the technical foundation already exists.

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><h4><i class="fa-paintbrush" style="color:$primary;">:paintbrush:</i></h4></td><td><h4>Design</h4></td><td>Define how the pass looks and behaves in Apple Wallet and Google Wallet. Structure the layout, branding, fields, links, and barcode without moving core business data out of existing systems.</td><td><a href="/spaces/96iMF0cPuLTC7ZRnUWG9">/spaces/96iMF0cPuLTC7ZRnUWG9</a></td><td><a href="/files/qdIqE5TBBPY4EdPrF2PP">/files/qdIqE5TBBPY4EdPrF2PP</a></td></tr><tr><td><h4><i class="fa-gear" style="color:$primary;">:gear:</i></h4></td><td><h4>Configuration</h4></td><td>Prepare the wallet foundation before launch. Configure issuer accounts, certificates, custom domains, template settings, and operational defaults for secure production use.</td><td><a href="/spaces/DJrf9G0l7ArnvuwEH0a8">/spaces/DJrf9G0l7ArnvuwEH0a8</a></td><td><a href="/files/s9rxAemSbsPmCa9nDuc4">/files/s9rxAemSbsPmCa9nDuc4</a></td></tr><tr><td><h4><i class="fa-layer-plus" style="color:$primary;">:layer-plus:</i></h4></td><td><h4>Enrolment</h4></td><td>Control how customers add a pass to their phone. Compare hosted forms, website embeds, email flows, QR codes, and in-app entry points to improve conversion and data quality.</td><td><a href="/spaces/lFokgwgJiwLXu7G8MVSJ">/spaces/lFokgwgJiwLXu7G8MVSJ</a></td><td><a href="/files/cZKS1reW7O3wVarjo9zU">/files/cZKS1reW7O3wVarjo9zU</a></td></tr></tbody></table>

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><h4><i class="fa-bell-ring" style="color:$primary;">:bell-ring:</i></h4></td><td><h4>Engage &#x26; animate</h4></td><td>Keep the installed pass useful after it is saved. Use pass updates, push notifications, geolocated alerts near stores or venues, and privilege logic tied to time, balance, or counters.</td><td><a href="/spaces/97ZAXMtqOjhvBBCfpmcE">/spaces/97ZAXMtqOjhvBBCfpmcE</a></td><td><a href="/files/Sl5PoYQ2k0d6X4fhFwq1">/files/Sl5PoYQ2k0d6X4fhFwq1</a></td></tr><tr><td><h4><i class="fa-chart-line" style="color:$primary;">:chart-line:</i></h4></td><td><h4>Monitoring</h4></td><td>Track what happens after issuance. Review installation status, pass activity, privilege usage, and synchronization signals needed to operate wallet programs at scale.</td><td><a href="/spaces/EsokFUBfsbM9mlwavmMB">/spaces/EsokFUBfsbM9mlwavmMB</a></td><td><a href="/files/qCOJ673uQWwaBH2rpMJ1">/files/qCOJ673uQWwaBH2rpMJ1</a></td></tr><tr><td><h4><i class="fa-barcode-read" style="color:$primary;">:barcode-read:</i></h4></td><td><h4>Scan &#x26; validate</h4></td><td>Validate passes at a gate, POS, counter, or service desk. Use real-time scans to read the pass, display the right privileges, and prevent duplicate or invalid redemption.</td><td><a href="/spaces/iqBD4M0nHFMaFeKR75p9">/spaces/iqBD4M0nHFMaFeKR75p9</a></td><td><a href="/files/P0nzScB9jPYqm12wYMmw">/files/P0nzScB9jPYqm12wYMmw</a></td></tr></tbody></table>

### How to use this page

This page works as the shortest route into the operational guides. It is useful when the goal is already known, such as configuring Apple Wallet certificates, launching an Add to Wallet flow, enabling location-based notifications, or validating passes in store or at event entry.

### FAQ

<details>

<summary><strong>Where should a new wallet project start?</strong></summary>

Most projects start with Configuration, then move to Design and Enrolment. That sequence reduces launch risk because wallet credentials, domains, and provider access are validated before distribution starts.

</details>

<details>

<summary><strong>Which guide covers location-based wallet experiences?</strong></summary>

Use Engage & animate for geolocated notifications and other post-install triggers. That area also covers push notifications and privilege logic that changes over time.

</details>

<details>

<summary><strong>Which guide covers in-store or event validation?</strong></summary>

Use Scan & validate when the pass must be checked at a door, POS, counter, or service point. That guide covers staff-facing scan flows and real-time redemption control.

</details>


# Commencez avec The Wallet Crew

Commencez par les principaux points d’entrée pour The Wallet Crew. Apprenez les bases du Wallet, comprenez la plateforme, puis passez au guide adapté.

The Wallet Crew est une plateforme de Carte Wallet qui connecte les systèmes métier existants — CRM, POS, moteurs de fidélité, plateformes de billetterie — à Apple Wallet et Google Wallet. Elle gère la conception des Cartes, leur distribution et les mises à jour du cycle de vie sans créer de nouveau silo de données. Les données clients restent dans vos systèmes sources ; The Wallet Crew les lit et fournit l’expérience Wallet par-dessus.

### Trouvez ce qui compte

La documentation de The Wallet Crew couvre les Cartes Apple Wallet et Google Wallet, de la stratégie aux opérations. Commencez par les points d’entrée guidés ci-dessous pour trouver plus rapidement le bon sujet, la bonne zone produit ou le bon parcours d’implémentation.

<button type="button" class="button primary" data-action="ask" data-icon="gitbook-assistant">Posez une question…</button>

### Commencez ici

Cette page est le moyen le plus rapide de naviguer dans la plateforme et la documentation. Utilisez les deux points d’entrée ci-dessous pour comprendre d’abord les bases de Wallet, ou pour obtenir une vue d’ensemble du produit avant de passer à un workflow spécifique.

{% columns %}
{% column %}

<p align="center"><a href="/pages/3d1c334e80e6382b505d8448cf9a01f5dd9838d7"><img src="/files/90a057049110afb8816767b0ae9f7fc387d91b7a" alt="Overview illustration of wallet fundamentals across Apple Wallet and Google Wallet pass usage."></a></p>

#### [Découvrez les fondamentaux de Wallet →](/fr/commencer/readme/wallet-fundamentals)

Comprenez ce qu’est une Carte, comment les clients l’installent et les concepts clés d’Apple Wallet et de Google Wallet.
{% endcolumn %}

{% column %}
[![Overview illustration of The Wallet Crew platform across pass design, distribution, and operations.](/files/f9377250de49a8f2ff3f88e6e54a9a38ac6bd769)](/fr/commencer/readme/understand-platform)

#### [Comprenez la plateforme →](/fr/commencer/readme/understand-platform)

Obtenez une vue d’ensemble en une page de The Wallet Crew, des principaux cas d’usage et du modèle produit de base.
{% endcolumn %}
{% endcolumns %}

### Parcourir par sujet

Parcourez par sujet lorsque l’objectif est déjà clair. Chaque section regroupe la documentation essentielle pour la conception des Cartes, l’inscription, l’automatisation du cycle de vie, le scan, la sécurité, la configuration, les intégrations, la supervision et les workflows développeur.

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>Conception</h4><p>Créez des mises en page de Carte, des ressources et des règles de branding pour Apple Wallet et Google Wallet.</p></td><td><a href="/files/9da8cf2970d4f77af7d30678abac249d5c800001">/files/9da8cf2970d4f77af7d30678abac249d5c800001</a></td><td><a href="/spaces/btz6OMHsNnnX0xBSGfeC">/spaces/btz6OMHsNnnX0xBSGfeC</a></td></tr><tr><td><h4>Inscription</h4><p>Configurez les flux de distribution de Cartes et les points d’entrée d’ajout à Wallet sur tous les canaux.</p></td><td><a href="/files/c3d3c6d3d56d5fa56d2aa9150903795c6a53c818">/files/c3d3c6d3d56d5fa56d2aa9150903795c6a53c818</a></td><td><a href="/spaces/TnKXdNj1C0405YbXHuEc">/spaces/TnKXdNj1C0405YbXHuEc</a></td></tr><tr><td><h4>Animer</h4><p>Stimulez l’engagement grâce aux mises à jour, aux déclencheurs et aux événements du cycle de vie des Cartes.</p></td><td><a href="/files/71738d8892ca6b9e7cf52773ca56d9e2c39e3526">/files/71738d8892ca6b9e7cf52773ca56d9e2c39e3526</a></td><td><a href="/spaces/NjHWxT38jWDRFOJxAqh7">/spaces/NjHWxT38jWDRFOJxAqh7</a></td></tr><tr><td><h4>Scanner</h4><p>Validez les Cartes au point d’entrée ou de service avec des flux de scan fiables.</p></td><td><a href="/files/9b14ada2f51f5259977997f29b418f83082a298d">/files/9b14ada2f51f5259977997f29b418f83082a298d</a></td><td><a href="/spaces/tzVqaO4Hrfq8Lp1hoB7T">/spaces/tzVqaO4Hrfq8Lp1hoB7T</a></td></tr><tr><td><h4>Sécurité</h4><p>Protégez les données des Cartes, contrôlez l’accès et réduisez les risques de fraude dans tous les workflows.</p></td><td><a href="/files/ccbcd016be9ccfefd0d85a1c7909dbc88f82160a">/files/ccbcd016be9ccfefd0d85a1c7909dbc88f82160a</a></td><td><a href="/spaces/b30DZMJ4lUbUgmqyBkbU">/spaces/b30DZMJ4lUbUgmqyBkbU</a></td></tr><tr><td><h4>Développeurs</h4><p>Intégrez des API, automatisez les opérations sur les Cartes et créez des expériences Wallet personnalisées.</p></td><td><a href="/files/8b170baaa06604aaffa377481c41f67f301e0455">/files/8b170baaa06604aaffa377481c41f67f301e0455</a></td><td><a href="/spaces/zNJzFw8gHYhYAsmbma1R">/spaces/zNJzFw8gHYhYAsmbma1R</a></td></tr><tr><td><h4>Configuration</h4><p>Gérez les paramètres de l’espace de travail, les options produit et les valeurs opérationnelles par défaut.</p></td><td><a href="/files/eaf546cac378f6c9fdb82b857d5b8bc81e072a7c">/files/eaf546cac378f6c9fdb82b857d5b8bc81e072a7c</a></td><td><a href="/spaces/sJ7p9Pg5u1DmoR0sonQl">/spaces/sJ7p9Pg5u1DmoR0sonQl</a></td></tr><tr><td><h4>Surveiller</h4><p>Suivez la livraison, l’utilisation et l’état de la plateforme pour exploiter les Cartes à grande échelle.</p></td><td><a href="/files/63b3b93b5bbde7c58810fb946916c3a9c6b66091">/files/63b3b93b5bbde7c58810fb946916c3a9c6b66091</a></td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG">/spaces/tJnneV8b22BGeGPcyzLG</a></td></tr><tr><td><h4>Connecteurs</h4><p>Connectez The Wallet Crew à des systèmes externes et à des sources de données.</p></td><td><a href="/files/0543075b7fd7b38db8c74cf7218ed5ef7df2480a">/files/0543075b7fd7b38db8c74cf7218ed5ef7df2480a</a></td><td><a href="/spaces/LWFiW6qOcSKMuuh67RUZ">/spaces/LWFiW6qOcSKMuuh67RUZ</a></td></tr></tbody></table>


# Apprendre les fondamentaux de Wallet

Comprenez les bases d’Apple Wallet et Google Wallet, ainsi que les types de Carte que vous pouvez configurer dans The Wallet Crew.

<div data-with-frame="true"><figure><img src="/files/518f5d2f940ab995120bc9121319e882f636de74" alt="Overview of wallet fundamentals across Apple Wallet and Google Wallet."><figcaption><p>Les fondamentaux du Wallet commencent avec le même principe sur les deux plateformes : une Carte reste facile à enregistrer, facile à retrouver et facile à présenter.</p></figcaption></figure></div>

Les Wallets mobiles comme Apple Wallet et Google Wallet ne sont plus de simples dossiers numériques pour les coupons. Ils sont devenus centraux dans la façon dont les gens organisent les essentiels de la vie quotidienne. Les clients ajoutent des Cartes à leur Wallet parce que cela garde les éléments les plus utilisés (cartes de fidélité, billets, offres, et plus encore) à portée de main, sans avoir à fouiller dans leurs e-mails, leurs applications ou leurs cartes physiques. Avoir une Carte dans le Wallet signifie un accès instantané quand cela compte : au moment du paiement, à l'entrée ou à l'accès à un événement, ce qui rend chaque expérience plus fluide et plus rapide pour les clients.

Au-delà des Cartes simples, les Wallets mobiles stockent en toute sécurité les **cartes bancaires**, permettant les paiements sans contact depuis un téléphone ou une montre connectée, ce qui fait des applications Wallet une habitude quotidienne pour les achats, les déplacements et l'accès. Ajouter des Cartes de marque, comme une carte de récompenses, un billet de concert ou une offre en magasin, s'intègre naturellement à cette routine, en gardant la marque visible chaque fois que les clients ouvrent leur Wallet. Les Wallets servent aussi de **hub unique, toujours disponible** pour les identifiants personnels, où les billets, cartes d'adhésion, cartes d'embarquement et autres Cartes cohabitent côte à côte, et cette utilisation fréquente et pratique augmente la probabilité que les clients conservent et utilisent les Cartes fournies par une marque, favorisant des interactions répétées et une fidélité plus profonde dans le temps.

### Un seul endroit pour les identifiants du quotidien

L'application Apple Wallet et l'application Google Wallet regroupent les éléments dont les clients ont besoin sur le moment. Cela inclut les coupons, cartes de fidélité, cartes d'adhésion, billets d'événement et plus encore. Les clients n'ont pas besoin de chercher dans leurs e-mails ni d'installer une application.

<div data-with-frame="true"><figure><img src="/files/9ce0fdc08813fc0097c2254f6175ea672cf10204" alt="Apple Wallet and Google Wallet shown as the two main mobile wallet apps used by customers on iOS and Android."><figcaption><p>Les Wallets mobiles sont l'endroit où les clients conservent leur Carte au quotidien.</p></figcaption></figure></div>

### Accès instantané au moment du paiement ou de l'entrée

La plupart des Cartes Apple Wallet et des Cartes Google Wallet sont validées avec un code-barres ou un QR code. Certaines utilisent le NFC lorsque du matériel de scan compatible est disponible. Les clients ouvrent la Carte et la présentent en quelques secondes.

### Toujours à jour

Une Carte n'est pas un PDF statique. Une Carte Apple Wallet et une Carte Google Wallet peuvent se mettre à jour au fil du temps. C'est important lorsque les points changent, que les soldes diminuent ou que les détails du billet sont mis à jour.

Les mises à jour font partie du cycle de vie principal. Pour les mécanismes de mise à jour et les contraintes de livraison, voir [les notifications push](broken://spaces/NjHWxT38jWDRFOJxAqh7/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe). Pour les identifiants et les bases du modèle de données, voir [Structure](/developers-guides/fr/pass-architecture/structure).

## Les types de Carte que vous pouvez configurer dans The Wallet Crew

The Wallet Crew permet aux marques de créer des modèles pour plusieurs **types de Carte Apple Wallet** et **types de Carte Google Wallet** types. Chaque type de Carte est assorti de contraintes Apple et Google. Le modèle définit ensuite la mise en page, les champs, les images et le code-barres.

Quand le choix du modèle n'est pas clair, [Types de Carte et modèles](/guides-design/fr/conception/readme-1) aide à déterminer le bon point de départ. Lorsque le type de Carte est déjà connu, la section pertinente ci-dessous est le bon point d'entrée. La configuration se fait ensuite dans le Template Designer.

{% hint style="info" %}
Les applications Wallet peuvent stocker des cartes de paiement pour les paiements sans contact (Apple Pay / Google Pay). The Wallet Crew couvre les Cartes Wallet (fidélité, billets, offres, cartes-cadeaux), pas les cartes de paiement.
{% endhint %}

### Carte de fidélité

Une Carte de fidélité est un programme de fidélité **types de Carte Apple Wallet** / **types de Carte Google Wallet**. Elle récompense les clients qui reviennent. Elle rend aussi le programme de fidélité plus concret.

* **Idéal pour :** les points, les tampons, l'adhésion par paliers et l'identification du compte au POS.
* **Champs clés :** identifiant membre, code-barres/QR, solde de points, niveau/statut et liens clés.
* **Utilisation typique :** scanner au moment du paiement pour identifier le client, puis mettre à jour les points/le niveau.

Pour la marque, l'objectif est la fidélisation. Les marques récompensent les clients qui achètent régulièrement. Elles peuvent proposer des points, des remises, des cadeaux et d'autres avantages. Une Carte de fidélité peut aussi être un point d'entrée vers un compte client. Cela aide à centraliser les données et à personnaliser les expériences.

Pour les clients, la valeur est immédiate. Ils peuvent voir leur statut de fidélité et leurs récompenses. Ils n'ont pas besoin de se souvenir d'un numéro de carte ni d'emporter une carte plastique.

Lorsque la Carte de fidélité est ajoutée à Apple Wallet ou Google Wallet, elle devient plus facile à utiliser. Les clients peuvent ouvrir l'application Wallet et sélectionner la Carte en quelques secondes. Ils ne manquent pas les opportunités de récompense parce que les points et avantages restent visibles sur la Carte.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Commerce de détail : solde de points et niveau (Argent/Or) mis à jour après chaque achat.
* Restauration rapide : Carte à tampons (achetez-en 8, obtenez-en 1 gratuitement) avec la progression affichée sur la Carte.
* Beauté : identifiant membre utilisé au moment du paiement, avec l'avantage anniversaire affiché comme champ.

</details>

Plus de détails : [Configuration du modèle de Carte de fidélité](/guides-design/fr/conception/loyalty-card-template-configuration).

### Billet d'événement

Un billet d'événement est un contrôle d'accès **types de Carte Apple Wallet** / **types de Carte Google Wallet**. Il est conçu pour un scan rapide à l'entrée. Il permet aussi aux participants de trouver facilement le bon billet.

* **Idéal pour :** événements avec entrée contrôlée et flux de travail « scan à l'entrée ».
* **Champs clés :** nom de l'événement, date/heure, lieu, siège/section, entrée, code-barres/QR.
* **Utilisation typique :** scanner à l'entrée pour valider l'entrée et éviter les doublons.

Dématérialiser les billets réduit les risques de perte et de fraude. Cela accélère l'entrée car le personnel peut scanner un QR code ou un code-barres. Cela prend aussi en charge les changements de dernière minute. Le même billet installé peut être mis à jour lorsque le siège, l'entrée ou l'horaire changent.

Pour les participants, ajouter un billet au Wallet est simple. Ils peuvent l'ajouter via un lien dans un e-mail, directement depuis un site de billetterie ou en scannant un QR code sur place. Sur le lieu de l'événement, le billet est prêt à être présenté en quelques gestes.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Concert : informations sur la place + QR scanné à l'entrée, avec l'heure d'ouverture des portes sur la Carte.
* Musée : billet à horaire fixe, où la date/heure change après reprogrammation.
* Festival : Carte multi-jours, avec la même Carte mise à jour chaque jour avec de nouvelles informations.

</details>

Plus de détails : [Billet d'événement](/guides-design/fr/conception/event-ticket).

### Carte cadeau

Une Carte cadeau est une valeur stockée **types de Carte Apple Wallet** / **types de Carte Google Wallet**. Elle est conçue pour être utilisée au fil du temps. L'exigence clé est de garder le solde exact après chaque utilisation, rechargement ou remboursement.

* **Idéal pour :** valeur stockée qui diminue au fil du temps (utilisation du solde, rechargements, remboursements).
* **Champs clés :** numéro de carte, solde + devise, code-barres/QR (ou NFC), date d'expiration.
* **Utilisation typique :** scanner au moment du paiement, appliquer un montant partiel ou total, puis mettre à jour le solde.

Pour les marques, les cartes cadeaux génèrent du chiffre d'affaires à l'avance. Les clients dépensent souvent plus que la valeur de la carte. Les cartes cadeaux sont aussi fréquemment offertes à quelqu'un d'autre. Cela en fait un excellent canal d'acquisition pour de nouveaux clients.

Pour les clients, une Carte cadeau dans le Wallet est plus facile à conserver et à utiliser. La Carte peut afficher le solde actuel et un code-barres ou QR code scannable. Elle réduit aussi les situations de « carte perdue » puisque la carte cadeau reste sur le téléphone.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Commerce de détail : Carte cadeau émise avec 100 €, puis solde mis à jour après chaque utilisation.
* Hôtellerie-restauration : bon vendu en ligne, utilisé en plusieurs paiements partiels sur place.
* Service client : avoir de courtoisie ajouté comme rechargement, puis dépensé au fil du temps.

</details>

Plus de détails : [Carte cadeau](/guides-design/fr/conception/gift-card).

### Offre

Une offre est une Carte de type coupon **types de Carte Apple Wallet** / **types de Carte Google Wallet**. Elle est utilisée pour les remises et les incitations limitées dans le temps. Les offres sont souvent utilisées une seule fois, puis deviennent invalides.

* **Idéal pour :** remises, codes promo et campagnes courtes avec des règles d'expiration claires.
* **Champs clés :** titre de l'offre, date d'expiration, conditions, code-barres/QR ou code promo.
* **Utilisation typique :** scanner en magasin ou saisir le code en ligne, puis marquer comme utilisée.

Pour les marques, les offres sont un moyen pratique de générer du trafic et des conversions. Elles peuvent aussi prendre en charge la segmentation. Différentes offres peuvent être émises pour différents publics. Une offre peut aussi être arrêtée ou expirée sans nécessiter une réinstallation.

Pour les clients, les offres Wallet sont faciles à retrouver au moment du paiement. La Carte peut afficher clairement la date d'expiration et les conditions. Elle peut aussi présenter un code-barres scannable ou un code à saisir en ligne.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Commerce de détail : coupon « -20 % ce week-end » avec date d'expiration et code-barres à usage unique.
* E-commerce : code promo affiché sur la Carte, utilisé au moment du paiement.
* CRM : offre de reconquête envoyée aux clients inactifs, puis marquée comme utilisée dans le POS.

</details>

Plus de détails : [Offre](/guides-design/fr/conception/offer).

### Générique

Générique est le type le plus flexible **types de Carte Apple Wallet** / **types de Carte Google Wallet** . Il convient aux cas d'utilisation qui ne correspondent à aucun modèle dédié. C'est un bon choix pour les justificatifs qui doivent être présentés ou scannés.

* **Idéal pour :** cartes d'adhésion, badges du personnel, cartes de garantie, justificatifs de retrait et « autres ».
* **Champs clés :** un identifiant stable, un code-barres/QR, un statut, des informations clés et des liens d'assistance.
* **Utilisation typique :** contrôle visuel ou scan, selon le flux opérationnel.

Pour les marques, Générique est utile lorsqu'une mise en page personnalisée est nécessaire. Les champs et l'ordre d'affichage sont entièrement configurables. C'est utile pour les cartes d'adhésion qui ne sont pas des programmes de fidélité, les Cartes du personnel, les badges partenaires, les cartes de garantie ou les justificatifs de retrait.

Pour les clients, une Carte Générique fonctionne comme n'importe quelle autre Carte. Elle est facile à ajouter, facile à retrouver et facile à présenter. Elle peut aussi être mise à jour lorsque les informations changent.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Badge du personnel : nom de l'employé + rôle + QR pour l'accès aux portes.
* Carte de garantie : numéro de série du produit + date d'achat + lien d'assistance.
* Click & collect : justificatif de retrait avec ID de commande + code-barres pour le retrait.

</details>

Plus de détails : [Générique](/guides-design/fr/conception/generic).

## FAQ

<details>

<summary><strong>Les clients ont-ils besoin d'une application mobile pour ajouter une Carte ?</strong></summary>

Non. Les clients peuvent ajouter une Carte depuis le site web d'une marque ou depuis un e-mail. Les QR codes fonctionnent aussi en magasin ou sur site. Si une application mobile existe, un parcours in-app pourra être ajouté plus tard.

</details>

<details>

<summary><strong>Les Cartes fonctionnent-elles hors ligne ?</strong></summary>

En général oui au moment de l'utilisation. Le code-barres/QR et les champs visibles sont stockés sur le téléphone. Les mises à jour nécessitent tout de même une connexion à un moment donné pour se synchroniser.

</details>

<details>

<summary><strong>Quelle est la différence entre une Offre et une Carte cadeau ?</strong></summary>

Les offres servent aux remises et aux coupons. Les cartes cadeaux servent à la valeur stockée et aux mises à jour de solde. Si la valeur peut diminuer avec le temps, c'est presque toujours une Carte cadeau.

</details>

<details>

<summary><strong>Une Carte peut-elle être mise à jour après son installation ?</strong></summary>

Oui. C'est l'un des principaux avantages des Wallets mobiles. The Wallet Crew met à jour la même Carte installée, donc les clients n'ont pas besoin de la rajouter.

</details>

<details>

<summary><strong>Peut-on utiliser plusieurs types de Cartes dans un seul projet ?</strong></summary>

Oui. Beaucoup de marques commencent avec un seul type de Carte (souvent la fidélité) et en ajoutent d'autres plus tard. Les types de Cartes peuvent partager les mêmes canaux de distribution et la même configuration opérationnelle.

</details>


# Concepts clés

Comprenez les concepts clés derrière The Wallet Crew : locataire, modèle de Carte, Carte et environnement.

The Wallet Crew repose sur un petit ensemble de concepts qui apparaissent tout au long de la plateforme. Les comprendre une fois rend la navigation sur toutes les autres pages plus rapide.

{% hint style="info" %}
Les cartes de paiement comme Apple Pay et Google Pay ne relèvent pas du périmètre ici. The Wallet Crew gère des cartes Wallet comme les cartes de fidélité, les billets, les offres et les cartes-cadeaux — pas des instruments de paiement.
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de distribution peut utiliser un seul tenant, un seul modèle de fidélité et des millions de cartes clients.
* Une marque de billetterie peut utiliser un modèle de billet par famille d’événements, puis émettre une carte par participant.
* Un groupe international peut conserver un tenant par pays lorsque les équipes, les identifiants et les données doivent rester séparés.

</details>

## Tenant

Un tenant est l’espace de travail isolé pour une marque ou un programme Wallet au sein de The Wallet Crew. Tout ce qui y est configuré vit dans ce tenant : les designs Wallet, les cartes, les données et l’accès de l’équipe.

Une façon simple de l’imaginer est un bâtiment privé, et non un espace ouvert partagé. Ce qui existe dans un tenant ne se mélange pas avec un autre tenant.

La plupart des marques ont un seul tenant. Certains groupes gèrent plusieurs tenants lorsque des marques, des pays ou des programmes distincts doivent rester indépendants, avec leurs propres identifiants Apple et Google, leurs propres données et leurs propres équipes.

{% hint style="info" %}
Un tenant n’est pas un dossier ni un sous-compte dans un espace de travail partagé. Chaque tenant est un environnement entièrement isolé. Aucun accès croisé aux données entre tenants n’existe par conception.
{% endhint %}

## Modèle de Carte

Un modèle de Carte est le modèle d’une catégorie de carte Wallet. Il définit quelle plateforme Wallet est ciblée, à quoi ressemble la Carte, quels champs apparaissent, quel format de code-barres est utilisé et comment fonctionne la personnalisation.

L’analogie la plus simple est un plan. Le modèle définit les règles une fois, puis The Wallet Crew réutilise ces règles chaque fois qu’une nouvelle Carte est créée à partir de celui-ci.

Un modèle n’est pas une Carte. Il n’appartient pas à un seul client. C’est la définition réutilisable derrière de nombreuses Cartes.

Une marque peut utiliser plusieurs modèles en même temps. Une carte de fidélité, une carte-cadeau et un billet d’événement nécessitent généralement chacun leur propre modèle.

## Carte

Une Carte est une carte Wallet, un billet ou un bon émis à un client. Elle est créée à partir d’un modèle et reliée aux systèmes de la marque, comme un CRM, un moteur de fidélité, un POS ou une plateforme de billetterie.

Si le modèle est le plan, la Carte est l’élément fini dans le portefeuille du client. Un seul modèle peut créer des milliers ou des millions de Cartes individuelles.

Les Cartes passent par un cycle de vie :

* **Créée** — la Carte existe sur la plateforme.
* **Installée** — le client l’a ajoutée à Apple Wallet ou Google Wallet.
* **Mise à jour** — le contenu de la Carte a changé, comme un solde de points, un statut ou un message.
* **Désinstallée** — le client l’a retirée du portefeuille.

Créée et installée sont deux moments distincts. Une Carte peut exister avant qu’un client l’enregistre dans le Wallet.

The Wallet Crew ne stocke pas les données personnelles des clients par défaut. Les Cartes sont généralement liées par des identifiants stables, comme un ID CRM ou un numéro de fidélité, tandis que les données clients essentielles restent dans les systèmes de la marque.

## Environnement

Les environnements séparent les tests des opérations en direct. En pratique, The Wallet Crew fournit **QA** pour les tests et **production** pour les vrais clients.

QA est la phase de répétition. La production est la phase en direct. QA reproduit de très près la production afin que les tests reflètent les conditions réelles avant le lancement.

Ces environnements sont entièrement isolés. Une Carte créée dans QA n’apparaît jamais en production, et les identifiants de production ou les données en direct ne sont pas partagés avec QA.

La configuration peut être copiée entre les environnements si nécessaire. Un troisième environnement, **dev**, existe uniquement pour un usage d’ingénierie interne et n’est pas accessible aux clients.

## Et ensuite

* Pour comprendre ce que la plateforme peut suivre après l’émission, voir [Surveillance](https://docs.thewalletcrew.io/guides-monitoring/fr/).
* Pour commencer à configurer un premier modèle, voir [Conception de la carte (couleurs, images et champs)](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields).
* Pour un modèle technique plus approfondi, commencez par [Structure](/developers-guides/fr/pass-architecture/structure) et la [Développeurs](https://docs.thewalletcrew.io/developers-guides/fr/) section.

## FAQ

<details>

<summary><strong>Un seul modèle peut-il créer de nombreuses Cartes ?</strong></summary>

Oui. C’est le modèle normal. Un modèle est réutilisé pour émettre de nombreuses Cartes individuelles qui partagent la même structure et le même design.

</details>

<details>

<summary><strong>Un même client peut-il avoir plusieurs Cartes ?</strong></summary>

Oui. Un client peut détenir plusieurs Cartes de la même marque, comme une carte de fidélité et plusieurs billets d’événement. Chaque Carte reste néanmoins son propre enregistrement.

</details>

<details>

<summary><strong>Pourquoi garder QA et la production séparés ?</strong></summary>

La séparation réduit les risques. Les équipes peuvent tester les designs, les liens et les flux de données dans QA sans affecter les clients en direct ni les identifiants en production.

</details>


# Comprendre la plateforme

Présentation d’une page de la plateforme The Wallet Crew : ce qu’elle est, ce qu’elle fait et comment les équipes l’utilisent.

<div data-with-frame="true"><figure><img src="/files/78abbc7f1ee31ce43fe00f3f86cd3fd8a6637d8f" alt="Overview of The Wallet Crew platform for wallet pass design, distribution, and lifecycle operations."><figcaption><p>The Wallet Crew réunit la conception des cartes, leur distribution et les opérations de cycle de vie sur une seule plateforme.</p></figcaption></figure></div>

The Wallet Crew est une plateforme en marque blanche pour **créer, distribuer et gérer des cartes Wallet**. Les marques l’utilisent pour **les cartes de fidélité, les coupons, les cartes-cadeaux, les billets et les cartes d’adhésion** dans **Apple Wallet** et **Google Wallet**. Les clients enregistrent la Carte une seule fois, puis la même Carte reste **à jour au fil du temps**.

TWC agit comme un pont entre les systèmes d’entreprise existants et les fournisseurs de Wallet — il ne crée pas de nouveau silo de données. Les profils clients, les dossiers de fidélité, les billets et les transactions restent dans leurs systèmes sources. TWC les lit, transforme les données en contenu compatible Wallet et envoie des mises à jour lorsque ces enregistrements changent.

TWC n’est pas un outil en libre-service uniquement. L’expertise et la conception de l’intégration font partie de l’accompagnement — chaque déploiement est conçu autour de modèles de données et de processus métier spécifiques, avec l’équipe The Wallet Crew impliquée tout au long du projet.

### Quels problèmes cela résout

La plupart des projets Wallet commencent avec les mêmes frictions. Les clients ont besoin de quelque chose de scannable à la caisse ou à l’entrée. Les installations d’apps restent faibles. Les cartes plastiques ajoutent des coûts et de la logistique.

The Wallet Crew distribue les cartes via le web, l’e-mail ou un QR code. Il maintient ensuite cette même carte installée à jour grâce à des mises à jour au fil du temps. Cela crée une couche opérationnelle unique sur Apple et Google tout en respectant les règles de chaque fournisseur.

Wallet n’est pas non plus un canal « uniquement marketing ». Une Carte est une **justificatif numérique** que les clients peuvent présenter au moment voulu, même avec une connectivité faible. Les notifications peuvent aider, mais la valeur essentielle est simple : la Carte reste disponible, scannable et à jour.

### À qui cela s’adresse

The Wallet Crew est conçu pour les équipes métier et techniques. Il prend en charge une configuration avancée lorsque c’est nécessaire, sans forcer chaque partie prenante à entrer dans le même niveau de détail.

Les équipes marketing et CRM obtiennent un espace propriétaire sur le téléphone que les clients conservent réellement. Le contenu peut être actualisé grâce aux mises à jour des Cartes et, le cas échéant, aux notifications Wallet.

Les équipes livraison, produit et opérations lancent plus vite, car un lancement ne dépend pas de l’adoption d’une app. Les équipes IT, data et sécurité obtiennent une couche connectée qui relie les Cartes au CRM, au moteur de fidélité, au POS et aux systèmes de billetterie, avec des configurations axées sur la confidentialité par défaut.

### Comment cela fonctionne (vue d’ensemble)

The Wallet Crew suit un cycle de vie simple. Une équipe conçoit un modèle, diffuse un point d’entrée « Ajouter à Wallet », puis envoie des mises à jour au fil du temps.

1. **Conception**: choisissez un type de Carte et configurez l’image de marque, les champs et le code-barres/QR. Commencez par [Conception de la carte (couleurs, images et champs)](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields).
2. **Connecter les données**: reliez chaque Carte aux systèmes sources à l’aide d’identifiants stables, afin que le CRM et le POS restent la source de vérité. Voir [Structure](/developers-guides/fr/pass-architecture/structure).
3. **Distribuer**: déployez l’installation de la Carte via des canaux propriétaires. La plupart des déploiements commencent par [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website) et [Par e-mail](/guides-enrolment/fr/inscription/via-email).
4. **Exploiter et engager**: mettez à jour les Cartes, déclenchez des notifications et mesurez l’adoption au fil du temps. Commencez par [Notifications push](broken://spaces/NjHWxT38jWDRFOJxAqh7/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe).

### Fonctionnalités clés

#### Wallet, c’est de la portée, pas seulement des notifications

Une carte Wallet est un objet persistant sur le téléphone du client. Elle est facile à retrouver et à présenter au point de vente, aux portiques d’entrée ou lors des interactions avec le service client. Cela fait de Wallet un canal pratique pour les opérations, et pas seulement pour les campagnes.

Les notifications sont facultatives et dépendent du cas d’usage ainsi que des règles du fournisseur. Dans de nombreux programmes, le principal résultat est simplement une utilisation plus élevée, car la Carte est rapide à ouvrir et difficile à perdre.

#### Modèles de cartes pour Apple Wallet et Google Wallet

Les modèles sont configurés une seule fois, et The Wallet Crew génère les charges utiles Apple et Google appropriées.

La plupart des marques commencent avec un ensemble de modèles de base, puis s’étendent au fil du temps. Une base courante comprend [Configuration du modèle de Carte de fidélité](/guides-design/fr/conception/loyalty-card-template-configuration), [Offre](/guides-design/fr/conception/offer), [Carte-cadeau](/guides-design/fr/conception/gift-card), [Billet d’événement](/guides-design/fr/conception/event-ticket), et [Générique](/guides-design/fr/conception/generic).

Pour les programmes multilingues, les libellés et le contenu peuvent être traduits par modèle. Voir [Comment traduire un modèle](/configure/fr/advanced-configuration/wallet/template-configuration/how-to-translate-a-template).

#### Distribution sans imposer d’application mobile

Les clients peuvent ajouter une Carte sans application mobile, ce qui est généralement le principal levier d’adoption. La plupart des déploiements commencent par le web et l’e-mail, puis s’étendent aux codes QR en magasin ou sur site.

Les points d’entrée de distribution courants incluent [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website), [Par e-mail](/guides-enrolment/fr/inscription/via-email), et, lorsqu’une application existe, [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1).

#### Mises à jour, notifications et expériences géolocalisées

Les cartes Wallet sont conçues pour évoluer, de sorte que la même carte installée peut changer après son enregistrement.

Les scénarios de mise à jour typiques incluent l’actualisation des points et du niveau après achat, les changements d’état des coupons après utilisation, les mises à jour du solde des cartes-cadeaux et les modifications de billets.

Commencez par [Notifications push](broken://spaces/NjHWxT38jWDRFOJxAqh7/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe), puis consultez [Notifications géolocalisées](/guides-animation/fr/engagement-et-animation/geolocated-notifications).

Même sans notifications, les mises à jour restent importantes. Elles rendent la Carte fiable en maintenant les soldes, les niveaux, la validité et l’état des billets à jour lorsque le client ouvre la Carte.

#### Intégrations et API

The Wallet Crew se situe entre les canaux de distribution et les systèmes sources.

Les équipes s’intègrent via des connecteurs natifs, notamment des outils CRM, POS et d’automatisation marketing. L’API peut aussi être utilisée pour l’émission, les mises à jour et les consultations. Commencez par [référence API](https://docs.thewalletcrew.io/api-reference/).

#### Opérations et utilisation en magasin/sur site

Gérer Wallet à grande échelle nécessite un ciblage et une validation fiable. Des métadonnées peuvent être associées aux Cartes pour la segmentation, puis utilisées pour cibler par magasin, pays, niveau ou canal. Voir [Structure](/developers-guides/fr/pass-architecture/structure).

Lorsque des outils pour le personnel sont nécessaires, les opérateurs peuvent utiliser [Carte Scanner](/guides-scan/fr/scanner/pass-scanner) pour scanner et valider les Cartes.

### Ce que c’est (et ce que ce n’est pas)

The Wallet Crew est une plateforme dédiée à la gestion de l’ensemble du cycle de vie des cartes Wallet. Elle vous permet de concevoir, distribuer et mettre à jour les Cartes tout en se connectant de manière fluide à vos canaux et systèmes de données existants.

Ce n’est pas une solution de paiement ; toutes les transactions de paiement continuent de s’effectuer dans Apple Pay et Google Pay. Elle ne remplace pas non plus vos systèmes métier existants tels que le CRM, les plateformes de fidélité, le POS ou les outils de billetterie. Ces systèmes restent votre source de vérité ; The Wallet Crew se contente d’étendre leurs données dans l’expérience Wallet.

### Confidentialité et sécurité

The Wallet Crew suit une **approche axée sur la confidentialité**. De nombreux déploiements évitent de stocker des données personnelles et stockent **des identifiants externes** à la place. Ces identifiants permettent à The Wallet Crew de récupérer les données et d’afficher la Carte.

Pour la sécurité de la distribution, voir [Sécurité des cartes Wallet](/configure/fr/advanced-configuration/wallet/wallet-card-security). Elle couvre les liens signés, HMAC/JWT et les risques d’énumération d’identifiants.

### FAQ

<details>

<summary><strong>Les clients doivent-ils installer une application mobile ?</strong></summary>

Non. La plupart des marques commencent sans application, et les clients ajoutent des Cartes depuis des pages web, des e-mails ou des codes QR. Lorsqu’une application existe, un parcours in-app peut être ajouté plus tard. Voir [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1).

</details>

<details>

<summary><strong>Peut-on utiliser des comptes émetteurs Apple et Google détenus par la marque ?</strong></summary>

Oui. Apple et Google exigent des identifiants d’émetteur détenus par la marque en production, et The Wallet Crew émet les Cartes sous l’identité de la marque.

Commencez par [Wallet Apple et Google](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet).

</details>

<details>

<summary><strong>Comment fonctionnent les mises à jour de Carte après l’installation ?</strong></summary>

Les données de la Carte sont mises à jour depuis les systèmes sources, et The Wallet Crew transmet la modification à Apple et Google. Commencez par [Notifications push](broken://spaces/NjHWxT38jWDRFOJxAqh7/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe). Elle explique les déclencheurs et ce que voient les clients.

</details>

<details>

<summary><strong>Stockez-vous des données personnelles ?</strong></summary>

Cela dépend du déploiement. De nombreux déploiements stockent uniquement des identifiants et des métadonnées opérationnelles, tandis que le CRM reste la source de vérité pour les données personnelles identifiables.

Pour le modèle de données, voir [Structure](/developers-guides/fr/pass-architecture/structure).

</details>

<details>

<summary><strong>Peut-on scanner et valider des Cartes en magasin ou à l’entrée d’un événement ?</strong></summary>

Oui. Les Cartes peuvent être scannées à l’aide de lecteurs de codes-barres ou de QR codes. Pour une expérience opérateur dédiée, utilisez [Carte Scanner](/guides-scan/fr/scanner/pass-scanner).

</details>


# Feuille de route de mise en œuvre

Séquence typique pour lancer un programme Wallet avec The Wallet Crew, de la signature du contrat à la mise en ligne, avec une approche de livraison par lot.

Cette feuille de route décrit la séquence typique pour lancer un programme Wallet avec The Wallet Crew. Elle commence à la signature du contrat et se termine à la mise en production, avec une approche de livraison agile et de petits incréments testables.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de distribution lance une Carte de fidélité et se concentre d’abord sur le scan en POS, puis ajoute des campagnes CRM.
* Un lieu intègre d’abord la billetterie pour s’assurer que l’entrée fonctionne, puis ajoute l’engagement post-événement.
* Une marque remplace les cartes d’adhésion en plastique par une Carte numérique, avec un déploiement par phases par région.
* Une marque commence avec un seul modèle « core », puis ajoute des modèles saisonniers ou spécifiques à un événement.

</details>

## Aperçu de la feuille de route

La plupart des projets Wallet réussissent lorsque les opérations pilotent la conception. La Carte doit fonctionner au point de vente ou à l’entrée avant de devenir un canal marketing. The Wallet Crew privilégie donc la validation précoce de la chaîne de bout en bout : systèmes sources → données de la Carte → distribution → installation du Wallet → utilisation.

La séquence ci-dessous est la séquence par défaut. Certaines étapes peuvent se chevaucher. L’approche de livraison par lots reste la même : livrer de petits incréments, valider rapidement sur des appareils réels, puis élargir le périmètre.

## Phases du projet (contrat → mise en production)

{% stepper %}
{% step %}

#### 1) Contrat et lancement

Cette phase aligne le périmètre, les parties prenantes et les contraintes. Elle fixe le rythme de travail et définit ce que signifie « terminé » pour la première version.

Les livrables typiques incluent un calendrier projet, une liste de responsables et une première cible de mise en production.
{% endstep %}

{% step %}

#### 2) Recueil des besoins (atelier)

The Wallet Crew anime un atelier dédié pour recueillir les besoins et contraintes de la marque. C’est une session de travail, pas une présentation. L’objectif est de converger vers une première expérience Wallet « minimale viable ».

L’atelier couvre généralement le cas d’usage de la Carte, les canaux de distribution, les contraintes de validation/scan, les champs de données requis, les attentes en matière de consentement/RGPD et les besoins de reporting.
{% endstep %}

{% step %}

#### 3) Configuration technique (tenant + Wallets + domaine personnalisé)

Cette phase prépare la plateforme à des tests sécurisés et à l’émission future en production.

Elle comprend généralement :

* Provisionnement du tenant (staging et, le cas échéant, production).
* Configuration d’Apple Wallet (certificats, clés push, identité de signature).
* Configuration de Google Wallet (accès au compte émetteur, compte de service / identifiants API).
* Configuration d’un domaine personnalisé pour les liens de marque et les pages hébergées, lorsque nécessaire.

Docs associés :

* Configuration du fournisseur Wallet : [Apple & Google Wallet](/configure/fr/advanced-configuration/wallet/wallet-card-security)
* Certificats Apple : [Certificats Apple Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/apple-wallet-certificates)
* Configuration de l’émetteur Google : [Compte Google Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account)
* Domaine personnalisé : [Domaine personnalisé](/configure/fr/advanced-configuration/platform/custom-domain)
  {% endstep %}

{% step %}

#### 4) Définition de l’architecture IT (système de référence et propriété des données)

Cette phase définit la place de The Wallet Crew dans le paysage IT global. Elle précise aussi quels systèmes restent la source de vérité pour chaque élément de données affiché sur la Carte.

La décision clé concerne le flux de données : ce qui déclenche la création de la Carte, la manière dont les mises à jour sont calculées et la façon dont les identifiants relient une Carte aux systèmes de la marque dans le temps.

Docs associés :

* Modèle de données et identifiants : [Structure](/developers-guides/fr/pass-architecture/structure)
  {% endstep %}

{% step %}

#### 5) Définition du projet et livraison par lots (incréments agiles)

Cette phase transforme le périmètre en lots livrables. Chaque lot doit pouvoir être testé sans travail ultérieur. Cela réduit le risque de mise en production et évite les déploiements « big bang ».

Une découpe courante est la suivante :

* Lot 1 : un modèle + un canal de distribution + un parcours de validation.
* Lot 2 : cycle de vie des mises à jour (rafraîchissement des champs, changements de statut, règles de désactivation).
* Lot 3 : segmentation, analytique et outils opérationnels.
* Lot 4 : automatisation marketing, notifications et personnalisation à l’échelle.
  {% endstep %}

{% step %}

#### 6) Parcours utilisateur (installation → présentation → mise à jour)

Cette phase définit le parcours client et le parcours opérationnel. Elle inclut les points d’entrée (« Ajouter au Wallet »), les écrans d’installation, les parcours de repli (ordinateur → QR), et la manière dont la Carte est récupérée ultérieurement.

Les choix de distribution se rattachent généralement à ces documents :

* [Formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form)
* [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website)
* [Par e-mail](/guides-enrolment/fr/inscription/via-email)
* [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1)
  {% endstep %}

{% step %}

#### 7) Configuration de la Carte (modèles + champs + code-barres)

Cette phase transforme l’UX et le modèle de données en une configuration de modèle de Carte pour Apple Wallet et Google Wallet. Elle couvre les éléments de marque, la disposition des champs, les liens et la charge utile du code-barres/QR.

La configuration des modèles se trouve sous :

* [Configuration des modèles](/configure/fr/advanced-configuration/wallet/template-configuration)
* Référence de conception : [Conception de la Carte (couleurs, images et champs)](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields)
  {% endstep %}

{% step %}

#### 8) Connecter d’abord les outils cœur (billetterie, POS, CRM/fidélité)

The Wallet Crew recommande de connecter d’abord les systèmes opérationnels cœur avant d’ajouter des couches marketing. Wallet est un justificatif. Il doit fonctionner de manière fiable là où la Carte est utilisée.

Cette phase livre généralement :

* Un flux opérationnel de création/mise à jour provenant des systèmes cœur.
* Une stratégie d’identifiants stable (numéro d’adhérent, ID de billet, code de carte cadeau, …).
* Un parcours de validation validé en conditions réelles (scanner, POS, portique d’entrée).

Une fois cela stabilisé, l’automatisation marketing peut être ajoutée sans mettre les opérations en risque.
{% endstep %}

{% step %}

#### 9) Ajouter le marketing et l’engagement (optionnel, après validation du cœur)

Cette phase ajoute des mécanismes d’engagement du cycle de vie tels que les notifications Wallet, la géolocalisation et les connecteurs d’automatisation marketing. Il est plus simple d’itérer une fois que l’émission et la validation cœur sont stables.

Points d’entrée :

* Notifications : [Notifications push](broken://spaces/NjHWxT38jWDRFOJxAqh7/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe)
* Déclencheurs de localisation : [Notifications géolocalisées](/guides-animation/fr/engagement-et-animation/geolocated-notifications)
* Connecteurs marketing : [Automatisation marketing](/connectors/fr/marketing-automation)
  {% endstep %}

{% step %}

#### 10) Mise en production et opérations

Cette phase achève la préparation à la production : supervision, procédures d’exploitation et déploiement contrôlé. Elle définit aussi comment les changements sont livrés après la mise en production (mises à jour de modèles, ajout de champs, nouveaux lots).

La validation typique comprend un pilote en production, des vérifications sur appareils réels sous iOS et Android, ainsi que des tests de scan dans des environnements représentatifs.
{% endstep %}
{% endstepper %}

## Livrables courants (à quoi ressemble le « terminé »)

À la mise en production, le package minimal attendu comprend généralement un modèle de Carte, un flux de distribution et un flux de validation opérationnelle. Il inclut aussi une stratégie de mise à jour claire, afin que la Carte reste fiable après l’installation.

À mesure que le programme monte en puissance, les livrables s’étendent à des modèles supplémentaires, à la segmentation, au reporting et à des fonctionnalités d’engagement optionnelles.

## FAQ

<details>

<summary><strong>Le projet peut-il démarrer avant que les comptes Apple/Google soient entièrement approuvés ?</strong></summary>

Oui, dans la plupart des cas. Le recueil des besoins, la définition de l’UX et la conception des modèles peuvent commencer immédiatement. Les approbations du fournisseur Wallet et les identifiants doivent être finalisés avant l’émission en production.

</details>

<details>

<summary><strong>Pourquoi The Wallet Crew recommande-t-elle de connecter les systèmes cœur avant les outils marketing ?</strong></summary>

Parce que Wallet est utilisé dans des moments opérationnels. Si la validation en caisse (POS) ou la billetterie n’est pas stable, la diffusion marketing augmente la charge de support. Une fois que l’émission, les mises à jour et la validation cœur sont fiables, l’automatisation marketing et les notifications peuvent être ajoutées en toute sécurité.

</details>

<details>

<summary><strong>Le périmètre peut-il être limité à un seul modèle pour la première version ?</strong></summary>

Oui. Un seul modèle constitue souvent le meilleur premier lot. Il simplifie le modèle de données et la gouvernance, et permet une validation plus rapide sur les appareils et dans les magasins/lieux.

</details>

<details>

<summary><strong>Un domaine personnalisé est-il obligatoire ?</strong></summary>

Non. Un domaine personnalisé est recommandé lorsque des liens de marque et des pages hébergées alignées sur la marque sont nécessaires. Certains projets commencent sans, puis l’ajoutent avant la mise en production.

</details>

<details>

<summary><strong>Qu’est-ce qui cause généralement des retards ?</strong></summary>

Les retards proviennent généralement de dépendances externes : approbations du fournisseur Wallet, modifications DNS pour les domaines personnalisés, revues de sécurité et clarification de la propriété des données entre systèmes. Le fait de garder des lots petits réduit l’impact de ces retards.

</details>


# Trouvez votre point de départ

Choisissez les bonnes pages d’entrée The Wallet Crew selon le rôle, l’objectif et le niveau de détail.

Différentes équipes utilisent The Wallet Crew pour des raisons différentes. Certaines ont d'abord besoin du modèle produit. D'autres ont besoin des flux de données, de la séquence de lancement ou de la documentation technique. Cette page oriente chaque rôle vers les bonnes premières pages.

#### **Marketing et CRM**

Les équipes marketing et CRM arrivent généralement en se demandant comment la plateforme fonctionne et ce qu'elle fait réellement.

Le premier modèle utile est simple : concevoir une Carte, la distribuer, puis la maintenir à jour après l'installation. [Comprendre la plateforme](/fr/commencer/readme/understand-platform) présente ce cycle de vie sur une seule page. [Apprendre les fondamentaux de Wallet](/fr/commencer/readme/wallet-fundamentals) explique comment les Cartes se comportent dans Apple Wallet et Google Wallet. Lorsque l'objectif passe à l'acquisition et à la conversion, [Inscription](https://docs.thewalletcrew.io/guides-enrolment/fr/) est le bon hub pour les points d'entrée du site web, des e-mails et de l'application.

#### **Informatique / Données / Sécurité**

Les équipes IT, données et sécurité arrivent généralement en demandant comment les données sont synchronisées et quel système possède quoi.

La question principale porte généralement sur le flux de données, pas seulement sur l'intégration. The Wallet Crew stocke souvent les identifiants et les métadonnées opérationnelles, tandis que les systèmes centraux restent la source de vérité. Commencez par [Comprendre la plateforme](/fr/commencer/readme/understand-platform), en particulier la section « Comment ça marche », pour situer la plateforme dans la pile. Puis passez à [Structure](/developers-guides/fr/pass-architecture/structure) pour les identifiants, la propriété et l'architecture des Cartes, et utilisez [Connecteurs](https://docs.thewalletcrew.io/connectors/fr/) pour examiner les modèles d'intégration pris en charge.

#### **Développeur**

Les développeurs arrivent généralement en se demandant où commencer la référence technique et comment fonctionne l'authentification.

Le chemin le plus court est la [Développeurs](https://docs.thewalletcrew.io/developers-guides/fr/) section, qui regroupe l'architecture des Cartes et la configuration des clés API. La [référence API](https://docs.thewalletcrew.io/api-reference/) est l'étape suivante pour les points de terminaison, les charges utiles et les structures de réponse. Utilisez [Connecteurs](https://docs.thewalletcrew.io/connectors/fr/) lorsque le projet repose sur une intégration existante plutôt que sur un flux personnalisé.

#### **Chef de projet**

Les chefs de projet arrivent généralement en se demandant comment The Wallet Crew s'intègre à la pile existante et ce qui se passe en premier.

La prise en main la plus rapide commence par la [Roadmap de mise en œuvre](/fr/commencer/readme/implementation-roadmap), qui présente la séquence de lancement habituelle, du kickoff au passage en production. Elle montre à quel moment la propriété des données, la distribution et la validation opérationnelle doivent être décidées. [Comprendre la plateforme](/fr/commencer/readme/understand-platform) explique où se situe The Wallet Crew entre les systèmes sources et les canaux Wallet. [Connecteurs](https://docs.thewalletcrew.io/connectors/fr/) aide à cartographier le projet par rapport aux outils CRM, POS, de billetterie et marketing existants.

#### **Parties prenantes / Direction**

Les parties prenantes et les cadres dirigeants arrivent généralement en se demandant si la plateforme est suffisamment bien documentée pour appuyer une décision.

Le contrôle de confiance le plus rapide commence par [Comprendre la plateforme](/fr/commencer/readme/understand-platform). Il donne une vue courte et factuelle du modèle produit, du périmètre et des principes de fonctionnement. [Roadmap de mise en œuvre](/fr/commencer/readme/implementation-roadmap) montre que la livraison suit une séquence définie, avec des phases et des points de validation clairs. Ensemble, ces pages montrent comment The Wallet Crew s'intègre dans un véritable programme sans entrer dans les détails techniques.


# Guides

Parcourez les guides The Wallet Crew pour la conception de Carte Apple Wallet et Google Wallet, la configuration, la distribution, l’engagement géolocalisé, le suivi et la validation des scans.

Les guides Wallet Crew couvrent tout le cycle de vie d'un programme Apple Wallet et Google Wallet. Ils aident les marques à passer de la conception de la Carte et de la configuration à la distribution, à l'engagement géolocalisé, au suivi et à la validation par scan.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de distribution configure une carte de fidélité, publie un formulaire d'inscription, puis déclenche des notifications géolocalisées à proximité des magasins.
* Une marque de billetterie configure des identifiants Wallet, distribue les billets par e-mail, puis valide l'entrée grâce à des scans en temps réel.
* Un programme de cartes-cadeaux synchronise les soldes, surveille l'activité de la Carte et maintient la même Carte installée à jour au fil du temps.

</details>

### Parcourez les guides principaux

Chaque guide ci-dessous couvre un domaine opérationnel. Commencez par Configuration lorsque le projet Wallet est encore en cours de mise en place. Commencez par Design ou Inscription lorsque la base technique existe déjà.

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><h4><i class="fa-paintbrush" style="color:$primary;">:paintbrush:</i></h4></td><td><h4>Conception</h4></td><td>Définissez l'apparence et le comportement de la Carte dans Apple Wallet et Google Wallet. Structurez la mise en page, l'image de marque, les champs, les liens et le code-barres sans déplacer les données métier essentielles hors des systèmes existants.</td><td><a href="/spaces/btz6OMHsNnnX0xBSGfeC">/spaces/btz6OMHsNnnX0xBSGfeC</a></td><td><a href="/files/5d484533b2c8941243aa2328702cdda1f2c5d27e">/files/5d484533b2c8941243aa2328702cdda1f2c5d27e</a></td></tr><tr><td><h4><i class="fa-gear" style="color:$primary;">:gear:</i></h4></td><td><h4>Configuration</h4></td><td>Préparez l'infrastructure Wallet avant le lancement. Configurez les comptes émetteurs, les certificats, les domaines personnalisés, les paramètres de modèle et les valeurs opérationnelles par défaut pour une utilisation sécurisée en production.</td><td><a href="/spaces/sJ7p9Pg5u1DmoR0sonQl">/spaces/sJ7p9Pg5u1DmoR0sonQl</a></td><td><a href="/files/eaf546cac378f6c9fdb82b857d5b8bc81e072a7c">/files/eaf546cac378f6c9fdb82b857d5b8bc81e072a7c</a></td></tr><tr><td><h4><i class="fa-layer-plus" style="color:$primary;">:layer-plus:</i></h4></td><td><h4>Inscription</h4></td><td>Contrôlez la manière dont les clients ajoutent une Carte à leur téléphone. Comparez les formulaires hébergés, les intégrations sur site web, les flux e-mail, les codes QR et les points d'entrée dans l'application afin d'améliorer la conversion et la qualité des données.</td><td><a href="/spaces/TnKXdNj1C0405YbXHuEc">/spaces/TnKXdNj1C0405YbXHuEc</a></td><td><a href="/files/077492a9292e7fcb2f1fc5a7602f5198351ff692">/files/077492a9292e7fcb2f1fc5a7602f5198351ff692</a></td></tr></tbody></table>

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><h4><i class="fa-bell-ring" style="color:$primary;">:bell-ring:</i></h4></td><td><h4>Engager &#x26; animer</h4></td><td>Gardez la Carte installée utile après son ajout. Utilisez les mises à jour de Carte, les notifications push, les alertes géolocalisées à proximité des magasins ou des lieux, et une logique de privilèges liée au temps, au solde ou aux compteurs.</td><td><a href="/spaces/NjHWxT38jWDRFOJxAqh7">/spaces/NjHWxT38jWDRFOJxAqh7</a></td><td><a href="/files/3769909c8be35673603a0724fb5dbc9e7571bd9e">/files/3769909c8be35673603a0724fb5dbc9e7571bd9e</a></td></tr><tr><td><h4><i class="fa-chart-line" style="color:$primary;">:chart-line:</i></h4></td><td><h4>Suivi</h4></td><td>Suivez ce qui se passe après l'émission. Examinez l'état d'installation, l'activité de la Carte, l'utilisation des privilèges et les signaux de synchronisation nécessaires pour exploiter des programmes Wallet à grande échelle.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG">/spaces/tJnneV8b22BGeGPcyzLG</a></td><td><a href="/files/c23f996003b5a4df19ad60b7210802888bd79510">/files/c23f996003b5a4df19ad60b7210802888bd79510</a></td></tr><tr><td><h4><i class="fa-barcode-read" style="color:$primary;">:barcode-read:</i></h4></td><td><h4>Scanner &#x26; valider</h4></td><td>Validez les Cartes à un portique, en point de vente, au comptoir ou au guichet de service. Utilisez des scans en temps réel pour lire la Carte, afficher les bons privilèges et empêcher les remises en double ou invalides.</td><td><a href="/spaces/tzVqaO4Hrfq8Lp1hoB7T">/spaces/tzVqaO4Hrfq8Lp1hoB7T</a></td><td><a href="/files/f5efeccde2f4648f3f7f15a96201378305c78add">/files/f5efeccde2f4648f3f7f15a96201378305c78add</a></td></tr></tbody></table>

### Comment utiliser cette page

Cette page sert de raccourci vers les guides opérationnels. Elle est utile lorsque l'objectif est déjà connu, par exemple configurer des certificats Apple Wallet, lancer un flux Ajouter au Wallet, activer des notifications basées sur la localisation ou valider des Cartes en magasin ou à l'entrée d'un événement.

### FAQ

<details>

<summary><strong>Par où doit commencer un nouveau projet Wallet ?</strong></summary>

La plupart des projets commencent par Configuration, puis passent à Design et à Inscription. Cette séquence réduit le risque de lancement, car les identifiants Wallet, les domaines et l'accès au fournisseur sont validés avant le début de la distribution.

</details>

<details>

<summary><strong>Quel guide couvre les expériences Wallet basées sur la localisation ?</strong></summary>

Utilisez Engager & animer pour les notifications géolocalisées et les autres déclencheurs après installation. Cette section couvre également les notifications push et la logique de privilèges qui évolue au fil du temps.

</details>

<details>

<summary><strong>Quel guide couvre la validation en magasin ou lors d'événements ?</strong></summary>

Utilisez Scanner & valider lorsque la Carte doit être contrôlée à une entrée, en point de vente, au comptoir ou au point de service. Ce guide couvre les flux de scan destinés au personnel et le contrôle des utilisations en temps réel.

</details>


# Guides de conception

Cinq sections couvrant l'ensemble du cycle de vie d'un programme de Carte Wallet, rédigées pour les personnes qui le gèrent au quotidien.

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="image">Image de couverture</th></tr></thead><tbody><tr><td><h4><i class="fa-house-crack" style="color:$primary;">:house-crack:</i></h4></td><td><h3>Général</h3></td><td><p>Comprenez comment les types de Carte et les modèles de fidélité fonctionnent ensemble. Le point de départ avant de configurer n'importe quelle Carte dans The Wallet Crew.</p><p><br></p></td><td><a href="/pages/db0dbdd975d4b86d48c5bc6f348346d0eaab5bb3">/pages/db0dbdd975d4b86d48c5bc6f348346d0eaab5bb3</a></td><td><a href="/files/859afc9b4e44522d7d948b587494126a8d5e90ac">/files/859afc9b4e44522d7d948b587494126a8d5e90ac</a></td></tr><tr><td><h4><i class="fa-user-group-crown" style="color:$primary;">:user-group-crown:</i></h4></td><td><h3>Carte de fidélité</h3></td><td>Configurez un modèle de Carte de fidélité : identifiant membre, niveau, points, code-barres. Conçu pour les programmes qui évoluent tout au long du cycle de vie client.</td><td><a href="/pages/30bc8e05fec05a22eee18d2be47b7caf525ecf39">/pages/30bc8e05fec05a22eee18d2be47b7caf525ecf39</a></td><td><a href="/files/ddcf6e225bb395ded551d74f0ac04396dc47c508">/files/ddcf6e225bb395ded551d74f0ac04396dc47c508</a></td></tr><tr><td><h4><i class="fa-tickets-perforated" style="color:$primary;">:tickets-perforated:</i></h4></td><td><h3>Billet d'événement</h3></td><td>Configurez une Carte de billet d'événement : lieu, date, siège, porte d'embarquement et code-barres scannable. Prend en charge les mises à jour en temps réel en cas de changement d'horaire.</td><td><a href="/pages/031225adc0ca969ca23df899648a0ba80dbf4494">/pages/031225adc0ca969ca23df899648a0ba80dbf4494</a></td><td><a href="/files/3070742e3e80ae3ccc8419def0b4eee84f51f7ae">/files/3070742e3e80ae3ccc8419def0b4eee84f51f7ae</a></td></tr></tbody></table>

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="image">Image de couverture</th></tr></thead><tbody><tr><td><h4><i class="fa-hand-holding-heart" style="color:$primary;">:hand-holding-heart:</i></h4></td><td><h3>Carte-cadeau</h3></td><td>Configurez une Carte de coupon ou de promotion à durée limitée : date d'expiration, conditions et code de remboursement. Généralement à usage unique, avec des mises à jour de statut lors de l'utilisation.</td><td><a href="/pages/cec13ac78aa37ef4bbd5f8b4f08c8ac22627e040">/pages/cec13ac78aa37ef4bbd5f8b4f08c8ac22627e040</a></td><td><a href="/files/859afc9b4e44522d7d948b587494126a8d5e90ac">/files/859afc9b4e44522d7d948b587494126a8d5e90ac</a></td></tr><tr><td><h4><i class="fa-tags" style="color:$primary;">:tags:</i></h4></td><td><h3>Offre</h3></td><td>Configurez une Carte de coupon ou de promotion à durée limitée : date d'expiration, conditions et code de remboursement. Généralement à usage unique, avec des mises à jour de statut lors de l'utilisation.</td><td><a href="/pages/f7cb09431befe411a4a9d3f581af10ca89784fdf">/pages/f7cb09431befe411a4a9d3f581af10ca89784fdf</a></td><td><a href="/files/4d7d827b9799c103aebd86642f0573b0daae0a36">/files/4d7d827b9799c103aebd86642f0573b0daae0a36</a></td></tr><tr><td><i class="fa-draw-circle" style="color:$tint;">:draw-circle:</i></td><td><h3>Générique</h3></td><td><p>Une Carte flexible pour les cas qui ne correspondent pas aux types standard : badges du personnel, cartes d'adhésion, cartes de garantie ou justificatifs de retrait.</p><p><br></p></td><td><a href="/pages/d43723d340b301c108b49d8a595452a902390f1a">/pages/d43723d340b301c108b49d8a595452a902390f1a</a></td><td><a href="/files/8b8b07978ce52876f0925b81e72ffc3c06109abd">/files/8b8b07978ce52876f0925b81e72ffc3c06109abd</a></td></tr></tbody></table>

#### **Conception**

Chaque Carte Wallet commence par un choix : quel type de Carte convient à votre cas d'utilisation et comment doit-il être configuré ? La section Conception passe en revue les éléments de base disponibles dans The Wallet Crew, des concepts fondamentaux aux modèles prêts à l'emploi pour les scénarios courants.

**Types de Carte et modèles** est le point de départ — il explique comment les types et les modèles fonctionnent ensemble avant que vous ne configuriez quoi que ce soit. De là, des guides dédiés couvrent chaque grand type de Carte : **Carte de fidélité** les modèles gèrent l'identifiant membre, le niveau, les points et le code-barres pour les programmes qui évoluent tout au long du cycle de vie d'un client. **Billet d'événement** les modèles gèrent les informations de lieu, de date, de siège et de porte, avec prise en charge des mises à jour en temps réel lorsque les horaires changent. **Carte-cadeau** et **Offre** les modèles couvrent les promotions à durée limitée avec dates d'expiration, conditions de remboursement et mises à jour de statut une fois utilisées. Pour tout le reste — badges du personnel, cartes d'adhésion, cartes de garantie, justificatifs de retrait — le **Générique** type de Carte offre une structure flexible qui s'adapte aux cas non standard.

Ensemble, ces guides vous donnent la boîte à outils complète pour concevoir une Carte qui correspond à votre modèle économique, que vous construisiez des programmes de fidélité, de la billetterie ou des cas d'utilisation ponctuels.


# Types de Carte et modèles

Comprenez les modèles de Carte et choisissez le bon type de Carte Apple Wallet et Google Wallet pour chaque cas d’usage.

Un modèle définit la structure et la conception d'une carte Wallet. Il contrôle la mise en page, les libellés, les images et les points de données qui apparaissent sur la carte.

Dans The Wallet Crew, chaque modèle part d'un **type de carte**. Le type de carte définit la forme de base et les contraintes requises par Apple Wallet et Google Wallet. Le modèle applique ensuite la personnalisation de marque et les règles de mappage par-dessus.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Fidélité en magasin : une carte de fidélité affiche l'ID membre, le niveau, les points et un code-barres.
* Cartes cadeaux : une carte à valeur stockée affiche le solde actuel et se met à jour après chaque utilisation.
* Coupons : une carte d'offre affiche une date d'expiration et un code scannable, puis est utilisée.
* Événements et visites : une carte d'événement affiche le lieu et l'heure, et prend en charge un scan rapide à l'entrée.
* Adhésion et services : une carte générique prend en charge les badges du personnel, les cartes de garantie ou les justificatifs de retrait.

</details>

## Modèle

Un modèle est la couche de configuration appliquée par-dessus un type de carte Apple Wallet / Google Wallet. C'est là que la personnalisation de marque et le mappage des champs sont définis une fois, puis réutilisés pour toutes les cartes émises.

#### Ce qu'un modèle contrôle

Un modèle contrôle l'apparence de la carte et la façon dont les données sont présentées :

* Conception visuelle (couleurs, logos, images).
* Disposition des champs (champs recto, champs verso, messages).
* Libellés, ordre et mise en forme (y compris les traductions).
* Configuration du code-barres/QR et sa valeur affichée.
* Contraintes propres au fournisseur (Apple vs Google).

#### Ce qu'un modèle ne contrôle pas

Un modèle n'est pas la source de vérité pour l'état métier. La validité, les soldes, les droits et les règles d'utilisation restent dans les systèmes amont (CRM, moteur de fidélité, POS, billetterie, e-commerce ou backend).

The Wallet Crew génère et met à jour la carte Wallet à partir de ces données source de vérité. Cela permet à la carte de rester cohérente avec les opérations, tout en bénéficiant de l'expérience Wallet (accès hors ligne, présentation native à l'appareil et mises à jour).

#### Pourquoi un modèle est nécessaire

Apple Wallet et Google Wallet n'affichent pas des données arbitraires. Ils affichent une carte qui suit un modèle prédéfini. Un modèle est la manière pratique de garder ce modèle stable dans le temps.

Les modèles permettent de :

* Définir un schéma stable (quels champs existent et ce qu'ils signifient).
* Décider ce qui apparaît au recto et au verso.
* Conserver une cohérence de marque sur les cartes émises.
* Valider tôt les contraintes (champs obligatoires, formats pris en charge, tailles d'image).

### Choisir le bon type de carte

The Wallet Crew prend en charge plusieurs types de cartes. Le bon choix dépend du flux de travail opérationnel et des données qui doivent rester à jour.

#### Carte de fidélité

Utilisez une carte de fidélité lorsque la carte représente une relation client continue et doit être mise à jour au fil du temps.

Le contenu typique comprend un identifiant membre, le niveau/statut, les points ou tampons, et des liens d'assistance. L'échange se fait généralement via un code-barres/QR scanné au point de vente, suivi d'une mise à jour des points ou du niveau.

Plus de détails : [Configuration du modèle de carte de fidélité](/guides-design/fr/conception/loyalty-card-template-configuration).

#### Billet d'événement

Utilisez un billet d'événement lorsque le flux principal est un contrôle d'accès avec un scan rapide à l'entrée.

Le contenu typique comprend le nom de l'événement, le lieu, la date/l'heure, le siège/la section, la porte d'entrée et un code-barres/QR. Les mises à jour sont utiles pour les changements d'horaire, les changements de siège ou les messages opérationnels.

Plus de détails : [Billet d'événement](/guides-design/fr/conception/event-ticket).

#### Carte cadeau

Utilisez une carte cadeau lorsque la carte représente une valeur stockée qui doit diminuer ou augmenter au fil du temps.

Le contenu typique comprend un identifiant de carte, le solde et la devise, la date d'expiration le cas échéant, et un code-barres/QR pour utilisation (ou NFC lorsque pris en charge). Les mises à jour du solde après utilisation constituent l'exigence principale.

Plus de détails : [Carte cadeau](/guides-design/fr/conception/gift-card).

#### Offre

Utilisez une offre pour des coupons ou promotions limités dans le temps, généralement utilisés une seule fois.

Le contenu typique comprend un titre d'offre, une date d'expiration, des conditions et un code d'échange (code-barres/QR ou code promo). L'offre peut être mise à jour pour refléter l'état d'utilisation.

Plus de détails : [Offre](/guides-design/fr/conception/offer).

#### Générique

Utilisez une carte générique lorsqu'aucun type de carte dédié ne correspond au cas d'usage, mais qu'un justificatif scannable ou présentable reste nécessaire.

Les cas courants incluent les cartes d'adhésion qui ne sont pas des programmes de fidélité, les badges du personnel, les cartes de garantie, les réservations de service ou les justificatifs de retrait.

Plus de détails : [Générique](/guides-design/fr/conception/generic).

### Quand plusieurs modèles ont du sens

La plupart des projets commencent avec un modèle par type de carte. Plusieurs modèles sont utiles lorsque les cartes nécessitent des mises en page différentes, des contraintes différentes ou des règles de contenu différentes.

Les raisons courantes incluent :

* Plusieurs marques, programmes ou unités commerciales sous un même tenant.
* Différents produits avec une densité d'information différente (standard vs VIP, basique vs premium).
* Différents textes juridiques ou contacts de support client selon le programme.
* Différentes langues nécessitant des libellés et une structure de contenu différentes.
* Différentes stratégies de code-barres ou contextes de scan (POS vs contrôle d'accès).

### Étapes suivantes

La création et la conception d'un modèle sont généralement réalisées une seule fois, puis affinées grâce aux retours opérationnels réels.

* Commencez par [Comment créer un modèle](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/how-to-create-a-template).
* Pour les règles de mise en page et les exigences en matière d'assets, utilisez [Conception de carte (couleurs, images et champs)](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/card-design-colors-images-and-fields).
* Pour les programmes multilingues, utilisez [Comment traduire un modèle](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/how-to-translate-a-template).

## FAQ

<details>

<summary><strong>Quelle est la différence entre un type de carte, un modèle et une carte ?</strong></summary>

Le type de carte est le modèle de base requis par Apple Wallet et Google Wallet (fidélité, offre, carte cadeau, billet d'événement, générique).

Un modèle est une instance configurée de ce type de carte dans The Wallet Crew. Il définit la personnalisation de marque, les champs et les règles de mappage.

Une carte est l'objet individuel installé par un client. Elle utilise un seul modèle à la fois et peut être mise à jour tout au long de son cycle de vie.

</details>

<details>

<summary><strong>Une carte peut-elle être mise à jour après l'installation ?</strong></summary>

Oui. Les mises à jour sont une fonctionnalité essentielle du portefeuille. The Wallet Crew met à jour la même carte installée, donc les clients n'ont pas besoin de la rajouter.

</details>

<details>

<summary><strong>Un seul modèle suffit-il pour tout un programme ?</strong></summary>

Souvent oui. Un modèle par type de carte est une base courante. Plusieurs modèles sont utiles lorsque différentes mises en page ou règles de contenu sont nécessaires.

</details>

<details>

<summary><strong>Un modèle décide-t-il si une carte est valide ?</strong></summary>

Non. La validité et l'état métier restent dans les systèmes source. Le modèle contrôle la façon dont cet état est affiché dans Apple Wallet et Google Wallet.

</details>


# Configuration du modèle de carte de fidélité

Pour améliorer l’expérience de vos clients, personnalisez votre carte de fidélité avec les modèles Apple et Google. Personnalisez les couleurs, les images et bien plus encore avec The Wallet Crew.

Que vous soyez un nouveau client qui doit créer le modèle des cartes qui seront distribuées à vos clients, ou un expert de The Wallet Crew qui doit mettre à jour un modèle existant, cet article vous aidera à naviguer vers notre concepteur de modèles. L'objectif est de configurer un modèle de carte qui reflétera l'identité de votre marque, affichera les bonnes informations à vos clients et garantira une expérience fluide sur Apple Wallet et Google Wallet.

## Architecture

Apple et Google ont leurs propres modèles de carte de fidélité, comme vous pouvez le voir ci-dessous.

{% tabs %}
{% tab title="Apple" %}

<figure><img src="/files/77cdae8f8a32483fcc3803bea24a2e06746a80f7" alt="Architecture - Apple"><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Google" %}

<figure><img src="/files/1e0541815b50003c5ea76c937d80c82bbcea5159" alt="Architecture - Google"><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

<table data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-cover data-type="image">Image de couverture</th></tr></thead><tbody><tr><td align="center">Carte Apple</td><td data-object-fit="contain" data-alt="Apple example loyalty card "><a href="/files/78b1edcad7df10c6dbc51e97d18554461f1a9fc0">/files/78b1edcad7df10c6dbc51e97d18554461f1a9fc0</a></td></tr><tr><td align="center">Carte Apple</td><td data-object-fit="contain" data-alt="Apple example loyalty card "><a href="/files/9a1ed089947c883b0090d8dcde287a98ecf451a7">/files/9a1ed089947c883b0090d8dcde287a98ecf451a7</a></td></tr><tr><td align="center">Carte Apple</td><td data-object-fit="contain" data-alt="Apple example loyalty card "><a href="/files/101a00c02de140ea08ddad8e9872da91f92c84b3">/files/101a00c02de140ea08ddad8e9872da91f92c84b3</a></td></tr></tbody></table>

<table data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-cover data-type="image">Image de couverture</th></tr></thead><tbody><tr><td align="center">Carte Google</td><td data-object-fit="contain"><a href="/files/d7193e03f2c0ec90aa839320e4c12974b53132e7">/files/d7193e03f2c0ec90aa839320e4c12974b53132e7</a></td></tr><tr><td align="center">Carte Google</td><td data-object-fit="contain"><a href="/files/d8db6fac247408bf2c2643317aba4ef2b876812a">/files/d8db6fac247408bf2c2643317aba4ef2b876812a</a></td></tr><tr><td align="center">Carte Google</td><td data-object-fit="contain"><a href="/files/3b3403b7040bf5f9c1d5d7cc1566bdbe0fc6a854">/files/3b3403b7040bf5f9c1d5d7cc1566bdbe0fc6a854</a></td></tr></tbody></table>

{% hint style="info" %}
**Si vous voulez aller plus loin, retrouvez tous les détails des deux versions :**
{% endhint %}

**Apple :**

{% embed url="<https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/Creating.html>" %}

**Android :**

{% embed url="<https://developers.google.com/wallet/retail/loyalty-cards/resources/template>" %}

### Comment le configurer sur The Wallet Crew

Avec The Wallet Crew, vous avez accès à un **concepteur de modèles** qui vous permet de **personnaliser les cartes de fidélité** que vous distribuerez à vos clients. Voyons en détail comment personnaliser chaque section !

## Apple

**Regardons les différentes sections du concepteur de modèles Apple.**

### Section générale

Dans la section générale, vous avez deux champs obligatoires à remplir :

* **Description** : une brève description de la carte, qui apparaîtra au verso de la carte
* **Nom de l'organisation** : le nom de votre entreprise ou de votre marque

Vous avez également la possibilité d'ajouter un texte à côté de votre logo, **activer le partage de la carte** si vous souhaitez que vos clients puissent la partager ou non avec d'autres personnes, la fonctionnalité « void » pour les coupons, ainsi qu'une date de validité et une date d'expiration utilisées pour les billets d'événement.

Vous pouvez également **définir la distance** à partir d'une latitude et d'une longitude pertinentes afin que la carte soit pertinente, pour **les notifications de géorepérage.**

<figure><img src="/files/9e391d77d8a0e6c938cb4f079552f7c9288e92f6" alt="Template designer general section"><figcaption><p>La section où vous pouvez personnaliser les informations générales</p></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** compatible avec votre logiciel de point de vente. La valeur du code-barres correspond aux **identifiants** qui vous permettront d'identifier la carte avec votre terminal en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si celui-ci ne peut pas être scanné.

<figure><img src="/files/33a2a2ef9d57a687bc8612308144f74299969e41" alt="Template designer barcode"><figcaption><p>La section où vous pouvez personnaliser vos préférences de code-barres</p></figcaption></figure>

### Couleurs et images

Pour changer la couleur de fond de votre carte, il suffit de **d'ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, importez-la depuis votre appareil.

### Champs d'en-tête

Cette section est particulièrement importante dans la version Apple, car les cartes sont **empilées les unes sur les autres**. Seul l'en-tête de la carte reste visible. Il est donc important que cette section attire l'attention et incite à cliquer sur la carte, notamment en affichant les informations les plus importantes, comme les points de fidélité ou d'autres informations pertinentes.

<figure><img src="/files/30e7db98e93e27361facf84b579b8c04a44ce900" alt="Template designer header fields"><figcaption><p>La section où vous pouvez personnaliser les champs d'en-tête</p></figcaption></figure>

### Champs de face

Les champs de face sont les champs utilisés pour **afficher des informations sur le recto de la carte**, sous l'image de bande. Le libellé que vous choisirez est le même pour chaque utilisateur (par langue), mais vous pouvez personnaliser la valeur pour afficher le nom du client ou le nombre de points.

<figure><img src="/files/761e09cdb8aa0b1892ed003e126e46647b3b22b9" alt="Template designer front fields"><figcaption><p>La section où vous pouvez personnaliser les champs de face</p></figcaption></figure>

{% hint style="warning" %}
**Pour personnaliser les champs de face, veuillez vous référer à votre équipe technique afin de savoir quelle valeur dynamique vous devez saisir.**
{% endhint %}

### Champs de verso

Cette section, située au verso de la carte de fidélité, comprend plusieurs informations utiles pour le client :

* Fonctionnement du programme de fidélité
* Récompenses disponibles
* Reçus
* Offres et messages personnalisés
* La possibilité d'ajouter des liens, tels que l'emplacement de leur magasin préféré, un lien pour mettre à jour leur compte et leurs préférences, l'accès aux conditions générales, etc.

<figure><img src="/files/048e2ac2ceb22af46256a39b4e9f7077143616d7" alt="Template designer backfields"><figcaption><p>La section où vous pouvez personnaliser les champs de verso</p></figcaption></figure>

### Autres sections

Sur Apple, vous avez également trois autres sections :

* **Emplacements** : Utilisé pour les notifications de géorepérage.
* **Balises** : Utilisé également pour les notifications de géorepérage.
* **Identifiant du magasin associé** : Vous pouvez lier votre application si elle se trouve sur l'App Store
* **NFC** : Une fonctionnalité qui permet aux clients d'échanger du contenu numérique et de connecter des appareils électroniques par simple contact.

{% hint style="warning" %}
**Veuillez contacter votre représentant The Wallet Crew pour activer ces fonctionnalités**
{% endhint %}

{% hint style="danger" %}
**Une fois que vous avez effectué quelques modifications, n'oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

***

## Google

**Le concepteur de modèles Google est légèrement différent de celui d'Apple.**

{% hint style="warning" %}
**Voici quelques éléments à savoir avant de configurer votre modèle Google :**
{% endhint %}

1. Certains champs, comme « issue » et « nom du programme », sont **obligatoires**
2. Google préconfigure les champs en fonction de leur usage prévu, il vaut donc mieux ne pas saisir le nom du client dans le champ des points de fidélité, par exemple, même si c'est ainsi que vous souhaiteriez qu'il apparaisse sur la carte
3. Les valeurs dynamiques (par ex. {{firstName}}) doivent être **placées dans des champs dynamiques dédiés**. Les champs « Label » sont destinés au texte statique uniquement.

**Jetons un coup d'œil aux différentes sections.**

### Section générale

Dans la section générale, vous avez trois **champs obligatoires** à remplir :

* **Émetteur**: le nom de la marque ou de l'entreprise qui émet la carte
* **Nom du programme**: il apparaît sur le recto de la carte, il peut s'agir par exemple du nom de votre programme de fidélité
* **État**: l'état de votre carte (active, expirée, terminée, inactive)

<figure><img src="/files/4732cb2d962ce8e9446722b6fc88f7c71e36a6ec" alt="Google template designer general section"><figcaption><p>La section où vous pouvez personnaliser les informations générales</p></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** compatible avec votre logiciel de point de vente. La valeur du code-barres correspond aux **identifiants** qui vous permettront d'identifier la carte avec votre terminal en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si celui-ci ne peut pas être scanné.

<figure><img src="/files/eb04f89ac096b0af6e589348644ea405ac2c55d3" alt="Google template designer Barcode"><figcaption><p>La section où vous pouvez personnaliser le code-barres</p></figcaption></figure>

### Plusieurs appareils et titulaires

Lorsque vous configurez un modèle, vous devez décider **si le client peut partager sa carte ou non**. Concernant Google, vous avez trois options :

* **Plusieurs titulaires**: cela signifie que le client peut partager sa carte avec n'importe qui
* **Un utilisateur, tous les appareils**: un client, mais avec plusieurs appareils (une montre par exemple)
* **Un utilisateur, un appareil**

<figure><img src="/files/6f173778d896c5018aa949c5c28294d434f07b18" alt="Google template designer multiple holders"><figcaption><p>La section où vous pouvez décider si un client peut partager sa carte ou non</p></figcaption></figure>

### Couleurs et images

Pour changer la couleur de fond de votre carte, il suffit de **d'ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, importez-la depuis votre appareil.

<figure><img src="/files/17e76d2f5bd5e11c77ed20ae48af415bdf935c86" alt="Google template designer images and colors"><figcaption><p>La section où vous pouvez personnaliser les couleurs et les images</p></figcaption></figure>

### Compte

La section Compte est l'endroit où vous pouvez saisir le **nom du client** et son **identifiant**.

<figure><img src="/files/49961e13eda8b6eb7bc30c8f59f5bc11c6585e68" alt="Google template designer account section"><figcaption><p>La section où vous pouvez configurer les noms et les identifiants de vos clients</p></figcaption></figure>

{% hint style="warning" %}
**Veuillez noter qu'il s'agit d'un champ facultatif et que vous ne pouvez pas mettre de valeur dynamique dans le champ libellé.**
{% endhint %}

### Liens supplémentaires

Cela apparaît au verso de la carte, vous pouvez y mettre le **lien d'un magasin ou de votre site web**!

<figure><img src="/files/cdb11002556555d459014ca659521300f39c29c6" alt="Google template designer additional links"><figcaption><p>La section où vous pouvez ajouter des liens supplémentaires</p></figcaption></figure>

### Points de fidélité, récompenses et niveaux de récompenses

Ces champs servent à configurer les **points de fidélité**, ainsi que les **récompenses** ou **niveaux de récompenses** (statut du programme de fidélité par exemple).

<figure><img src="/files/9dfcea3700cc41d375c6cb8b5bab4368783e13ad" alt="Google template designer points" width="375"><figcaption><p>La section où vous pouvez configurer les points et les récompenses de la carte</p></figcaption></figure>

### Messages

Cette section, située au verso de la carte de fidélité, comprend plusieurs **informations utiles** pour le client :

* Fonctionnement du programme de fidélité
* Récompenses disponibles
* La possibilité d'ajouter des liens, tels que l'emplacement de leur magasin préféré, un lien pour mettre à jour leur compte et leurs préférences, l'accès aux conditions générales, etc.

<figure><img src="/files/80c6c1dd238ec5218ce059e1f2558eeefdf825fc" alt="Google template designer messages"><figcaption><p>La section où vous pouvez personnaliser les champs de verso de la carte</p></figcaption></figure>

### Opportunités à valeur ajoutée

Cette section vous permet d'ajouter une **petite section en bas de la carte de fidélité**. Elle sert à afficher des offres ou des actualités.

<figure><img src="/files/9355f8cb3b76257b76e6b02ac0db7160b4a72316" alt="Google template designer added value opportunities"><figcaption><p>La section où vous pouvez personnaliser la section en bas de la carte</p></figcaption></figure>

{% hint style="danger" %}
**Une fois que vous avez effectué quelques modifications, n'oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

## FAQ

<details>

<summary><strong>Dois-je enregistrer ma configuration et mettre à jour toutes les cartes ?</strong></summary>

Une fois que vous avez terminé de modifier votre modèle, vous avez **deux options :**

* Enregistrer votre configuration sans déployer de mise à jour sur toutes les cartes : c'est la meilleure option si vous avez beaucoup de cartes. Vous pouvez enregistrer votre configuration et décider de planifier une mise à jour pendant la nuit afin d'éviter l'impact d'une mise à jour massive.
* Enregistrer votre configuration et déployer une mise à jour : c'est la meilleure option si vous faites des tests ou si vous avez quelques cartes dans votre environnement.

</details>

<details>

<summary><strong>Comment modifier la configuration pour une autre langue ?</strong></summary>

Vous avez la possibilité de modifier le design de la carte pour chaque langue. Si vous cliquez sur « général » dans le menu, vous pouvez ajouter une langue. Elle apparaîtra alors dans le concepteur de modèles et vous pourrez la modifier.

</details>


# Billet d'événement

Offrez un accès fluide aux événements avec des billets Apple et Google Wallet. Personnalisez vos Cartes avec votre image de marque, vos visuels et des informations événementielles en temps réel grâce à The Wallet Crew.

Que vous soyez un nouveau client qui doit créer le modèle des billets qui seront distribués à vos participants, ou un maître de The Wallet Crew qui doit mettre à jour un modèle existant, cet article vous aidera à naviguer dans notre concepteur de modèles. L’objectif est de configurer un modèle de billet qui reflète l’identité de votre marque, affiche clairement les informations essentielles de l’événement et garantisse une expérience fluide et sécurisée sur Apple Wallet et Google Wallet.

## Architecture

Apple et Google ont leurs propres modèles de billets, comme vous pouvez le voir ci-dessous.

{% tabs %}
{% tab title="Apple" %}

<figure><img src="/files/28ec2cca093155cc4e81f2d75edd13c88b5dc706" alt="Architecture - Apple"><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Google" %}

<figure><img src="/files/893697add5dca6cf079db4201b91ebfe11b19461" alt="Architecture - Google"><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

<table data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-cover data-type="image">Image de couverture</th></tr></thead><tbody><tr><td align="center">Billet Apple</td><td data-object-fit="contain"><a href="/files/d630e2b0c48116f305e40e39592b58e0e6891dd9">/files/d630e2b0c48116f305e40e39592b58e0e6891dd9</a></td></tr><tr><td align="center">Billet Apple</td><td data-object-fit="contain"><a href="/files/ea9315353c908da7dc4938c59f005b1d3dcea8d7">/files/ea9315353c908da7dc4938c59f005b1d3dcea8d7</a></td></tr><tr><td align="center">Billet Apple</td><td data-object-fit="contain"><a href="/files/34c46e8c49fe9ed522f0feeaf6e313d74ab02ac3">/files/34c46e8c49fe9ed522f0feeaf6e313d74ab02ac3</a></td></tr><tr><td align="center">Billet Google</td><td></td></tr><tr><td align="center">Billet Google</td><td></td></tr><tr><td align="center">Billet Google</td><td data-object-fit="contain"><a href="/files/88ed15aabdd3afa906ef8cad6809896cde9b4d15">/files/88ed15aabdd3afa906ef8cad6809896cde9b4d15</a></td></tr></tbody></table>

{% hint style="info" %}
**Si vous souhaitez aller plus loin, retrouvez tous les détails des deux versions :**
{% endhint %}

**Apple :**

{% embed url="<https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/Creating.html>" %}

**Google :**

{% embed url="<https://developers.google.com/wallet/tickets/events/resources/template?hl=fr>" %}

### Comment le configurer dans The Wallet Crew

Avec The Wallet Crew, vous avez accès à un **concepteur de modèles** qui vous permet de **personnaliser les billets de l’événement** que vous distribuerez à vos clients. Voyons en détail comment personnaliser chaque section !

## Apple

**Examinons les différentes sections du concepteur de modèles Apple.**

### Section générale

Dans la section générale, vous avez deux champs obligatoires à renseigner :

* **Description** : une brève description de la carte, qui apparaîtra au dos de la carte
* **Nom de l’organisation** : le nom de votre entreprise ou de votre marque

Vous avez également la possibilité d’ajouter un texte à côté de votre logo, **activer le partage du billet** si vous souhaitez que vos clients puissent le partager ou non avec d’autres personnes, la fonctionnalité « void » pour les coupons, une date de validité et une date d’expiration utilisées pour les billets d’événement.

Vous pouvez également **définir la distance** à partir d’une latitude et d’une longitude pertinentes auxquelles la carte est rattachée, pour **les notifications de géorepérage.**

<figure><img src="/files/266776e6c93f79fe558917884fef7b2165d9fe8b" alt="Event ticket - General section Apple"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** qui est compatible avec votre matériel de contrôle. La valeur du code-barres correspond aux **identifiants** qui vous permettront d’identifier le billet de l’événement avec votre terminal de contrôle à l’entrée. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si le code-barres ne peut pas être scanné.

<figure><img src="/files/8bbab12f1d285f9bbf6ca58b57cccbbb60890b07" alt="Event ticket - Barcode Apple"><figcaption></figcaption></figure>

### Couleurs et images

Pour modifier la couleur de fond de votre billet, il vous suffit de **ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, téléversez-la depuis votre appareil.

### Champs d’en-tête <a href="#header-fields" id="header-fields"></a>

Cette section est particulièrement importante dans la version Apple, car les billets sont **empilés les uns sur les autres**. Seul l’en-tête du billet reste visible. Il est donc important que cette section attire l’attention et donne envie de cliquer sur la carte, notamment en affichant les informations les plus importantes, comme la date ou d’autres informations pertinentes.

<figure><img src="/files/e1bafb8543d3812680b73a9d9e38fbdbd1872872" alt="Event ticket - Header fields Apple"><figcaption></figcaption></figure>

### Champs recto

Les champs recto sont les champs utilisés pour **afficher des informations sur le recto du billet**, sous l’image de la bande. Le libellé que vous choisirez sera le même pour chaque utilisateur (par langue), mais vous pouvez personnaliser la valeur pour afficher le nom de l’événement ou le siège du client.

<figure><img src="/files/46989840323520ed0312a33132f71adb07fa2fb8" alt="Event ticket - Front field Apple"><figcaption></figcaption></figure>

{% hint style="warning" %}
**Pour personnaliser les champs recto, veuillez vous référer à votre équipe technique afin de déterminer quelle valeur dynamique vous devez renseigner.**
{% endhint %}

### Champs verso <a href="#backfields" id="backfields"></a>

Cette section, située au dos du billet d’événement, comprend plusieurs informations utiles pour le client :

* Comment se rendre à l’événement
* Informations concernant l’entrée
* Reçus
* La possibilité d’ajouter des liens, tels qu’un lien pour écouter les artistes, accéder aux conditions générales, etc.

<figure><img src="/files/0cad52ecb460e9e3025d8172732d33bb9951996e" alt="Event ticket - Backfields Apple"><figcaption></figcaption></figure>

### Autres sections

Sur Apple, vous avez également quatre autres sections :

* **Emplacements** : utilisé pour les notifications de géorepérage.
* **Balises** : également utilisé pour les notifications de géorepérage.
* **Identifiant de l’App Store associé** : vous pouvez lier votre application si elle est disponible sur l’App Store
* **NFC** : une fonctionnalité qui permet aux clients d’échanger du contenu numérique et de connecter des appareils électroniques d’un simple contact.

{% hint style="warning" %}
**Veuillez contacter votre interlocuteur The Wallet Crew pour activer ces fonctionnalités**
{% endhint %}

{% hint style="danger" %}
**Une fois vos modifications effectuées, n’oubliez pas de cliquer sur « save » en haut de votre écran !/**
{% endhint %}

***

## Google

**Le concepteur de modèles Google est un peu différent de celui d’Apple.**

{% hint style="warning" %}
**Voici quelques éléments à connaître avant de configurer votre modèle Google :**
{% endhint %}

1. Certains champs tels que « émission » et « nom du programme » sont **obligatoires**
2. Google préconfigure les champs en fonction de leurs valeurs prévues, il est donc préférable de ne pas saisir le nom du client dans le nom de l’événement, par exemple, même si c’est ainsi que vous souhaiteriez qu’il apparaisse sur la carte
3. Les valeurs dynamiques (par ex. {{firstName}}) doivent être **placées dans des champs dynamiques dédiés**. Les champs « Label » sont destinés au texte statique uniquement.

**Examinons les différentes sections.**

### Section générale

Dans la section générale, vous avez trois **champs obligatoires** à renseigner :

* **Émetteur**: le nom de la marque ou de l’entreprise qui émet le billet
* **Nom de l’événement**: il apparaît sur le recto de la carte, il peut s’agir du nom de votre événement
* **État**: l’état de votre billet (actif, expiré, terminé, inactif)

<figure><img src="/files/393c3bc2abeae9eb8436d43e0b5a8b7a8bd2f086" alt="Event ticket - Google general"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** qui est compatible avec votre matériel de contrôle. La valeur du code-barres correspond aux **identifiants** qui vous permettront d’identifier le billet de l’événement avec votre terminal de contrôle à l’entrée. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si le code-barres ne peut pas être scanné.

<figure><img src="/files/0bb5c4a683582e301e8b758fa69ad0a67ce1edc1" alt="Event ticket - Barcode Google"><figcaption></figcaption></figure>

### Sécurité

Lorsque vous configurez un modèle, vous devez décider **si le client peut partager sa carte ou non**. Concernant Google, vous avez trois options :

* **Plusieurs détenteurs**: cela signifie que le client peut partager sa carte avec n’importe qui
* **Un utilisateur, tous les appareils**: un client, mais avec plusieurs appareils (une montre, par exemple)
* **Un utilisateur, un appareil**

<figure><img src="/files/0a19603ea622513325b050ee86c2d01e7fb589fb" alt="One user one device"><figcaption></figcaption></figure>

### Couleurs et images

Pour modifier la couleur de fond de votre billet, il vous suffit de **ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, téléversez-la depuis votre appareil.

<figure><img src="/files/0ac631037a0f8bf1c49b743f477242b0902bfcd0" alt="Event ticket - Colors and Images Google"><figcaption></figcaption></figure>

### Lieu

Une section pour renseigner les détails du lieu où se déroulera l’événement !

<figure><img src="/files/ef56feed0df611ccb0d6a13d4e2367b8614ed965" alt="Event ticket - venue Google"><figcaption></figcaption></figure>

### Placement

Vous pouvez définir la porte, la rangée, le siège et la section du billet de votre client. Chaque champ est facultatif.

{% hint style="warning" %}
**Pour personnaliser les champs de placement, veuillez vous référer à votre équipe technique afin de déterminer quelle valeur dynamique vous devez renseigner.**
{% endhint %}

<figure><img src="/files/3ec24caa53a641aeabf4d6cfc242abc3687c0ee4" alt="Event ticket - Placement Google"><figcaption></figcaption></figure>

### Confirmation

Dans le modèle Google, vous pouvez également définir et afficher un code de confirmation s’il est requis pour votre événement. Il s’agit d’un champ facultatif ; si vous n’avez aucun code de confirmation, vous pouvez sélectionner « Non spécifié ».

<figure><img src="/files/5959fa23478f1e7a0b179e972f5cd5e03a9a1b0b" alt="Event ticket - Confirmation Google"><figcaption></figcaption></figure>

### Liens supplémentaires, Smart tap et intervalle de temps valide

Vous pouvez décider d’ajouter **des liens supplémentaires** au billet du client, par exemple le lien du site web de l’événement !

De plus, vous pouvez également configurer la **fonctionnalité Smart tap** qui permet à votre client de simplement **valider son billet** en approchant son appareil de votre terminal matériel compatible.

Enfin, la section Intervalle de temps valide vous permet de **définir une date de début et une date de fin** pour votre événement !

<figure><img src="/files/59604a17dba731b3f4febc6bdafdf7b34d943626" alt="Event ticket - Smart tap Google"><figcaption></figcaption></figure>

### Messages

Cette section, située au dos du billet d’événement, comprend plusieurs informations utiles pour le client :

* Comment se rendre à l’événement
* Informations concernant l’entrée
* Reçus
* La possibilité d’ajouter des liens, tels qu’un lien pour écouter les artistes, accéder aux conditions générales, etc.

<figure><img src="/files/a08b41226c981bab0f1ab19351319a6b15824ca4" alt="Event ticket - Backfields Google"><figcaption></figcaption></figure>

### Opportunités à valeur ajoutée

Cette section vous permet d’ajouter une **petite section en bas du billet**. Elle est utilisée pour afficher des offres ou des actualités.

<figure><img src="/files/acde4ff3785723267c2e6357d697231d5ea03ab8" alt="Event ticket - Value Added Opportunity Google"><figcaption></figcaption></figure>

### Autres sections

Sur Google, vous avez également quatre autres sections :

* **Valeur faciale** : le prix du billet
* **Liens d’application** : utilisé pour ajouter un lien vers une application
* **Page d’accueil** : utilisé pour ajouter le lien du site web de l’événement
* **Emplacements** : utilisé pour les notifications de géorepérage

{% hint style="danger" %}
**Une fois vos modifications effectuées, n’oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

## FAQ

<details>

<summary><strong>Dois-je enregistrer ma configuration et mettre à jour toutes les cartes en même temps ?</strong></summary>

Une fois que vous avez terminé de modifier votre modèle, vous avez **deux options :**

* Enregistrer votre configuration sans déployer de mise à jour sur toutes les cartes : c’est la meilleure option si vous avez beaucoup de cartes. Vous pouvez enregistrer votre configuration et décider de planifier une mise à jour pendant la nuit afin d’éviter l’impact d’une mise à jour massive.
* Enregistrer votre configuration et déployer une mise à jour : c’est la meilleure option si vous effectuez des tests ou si vous avez quelques cartes dans votre environnement.

</details>

<details>

<summary><strong>Comment modifier la configuration pour une autre langue ?</strong></summary>

Vous avez la possibilité de modifier le design de la carte pour chaque langue. Si vous cliquez sur « général » dans le menu, vous pouvez ajouter une langue. Elle apparaîtra alors dans le concepteur de modèles et vous pourrez la modifier.

</details>


# Carte cadeau

Configurez un modèle de Carte cadeau pour Apple Wallet et Google Wallet. Affichez la valeur stockée, prenez en charge l’utilisation du code-barres/NFC et maintenez le solde à jour.

Que vous soyez un nouveau client souhaitant créer le modèle de cartes-cadeaux que vous distribuerez à vos clients, ou un expert Wallet Crew souhaitant mettre à jour un modèle existant, cet article vous guidera à travers notre concepteur de modèles. L’objectif est de configurer un modèle de carte-cadeau qui reflète l’identité de votre marque, affiche les bonnes informations à vos clients et garantit une expérience fluide sur Apple Wallet et Google Wallet.

Utilisez une **Carte cadeau** Carte lorsque la Carte représente **une valeur stockée**. Ce modèle est conçu pour l’affichage du solde et les mises à jour du solde.

Cas typiques :

* Solde initial à l’émission
* Rachats partiels qui diminuent le solde
* Rechargements et remboursements qui mettent à jour la même Carte

Si votre Carte est un coupon de réduction (et non une valeur stockée), utilisez [Offre](/guides-design/fr/conception/offer) à la place.

### Architecture

Apple et Google disposent chacun de leurs propres modèles de cartes-cadeaux, comme vous pouvez le voir ci-dessous.

{% tabs %}
{% tab title="Apple" %}

<figure><img src="/files/f8a4e41a66f50a2367a0acbcd60368cdfe85eb2f" alt="Apple gift card template"><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Google" %}

<figure><img src="/files/4cb9d16cafe72ce1802689e8d1f6de714c7e6af0" alt="Google gift card template"><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

{% hint style="info" %}
**Si vous voulez aller plus loin, retrouvez tous les détails des deux versions :**
{% endhint %}

**Apple :**

{% embed url="<https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/Creating.html>" %}

**Google :**

{% embed url="<https://developers.google.com/wallet/retail/gift-cards/resources/template?hl=fr>" %}

### Comment le configurer sur The Wallet Crew

Avec The Wallet Crew, vous avez accès à un **concepteur de modèles** qui vous permet de **personnaliser les cartes-cadeaux** que vous distribuerez à vos clients. Voyons en détail comment personnaliser chaque section.

## Apple

**Examinons les différentes sections du concepteur de modèles Apple.**

### Section générale

Dans la section générale, vous avez deux champs obligatoires à remplir :

* **Description**  : une brève description de la carte-cadeau, qui apparaîtra au dos de la carte
* **Nom de l’organisation**  : le nom de votre entreprise ou de votre marque

Vous avez également la possibilité d’ajouter un texte à côté de votre logo, **activer le partage de la carte-cadeau** si vous souhaitez que vos clients puissent la partager ou non avec d’autres personnes, la « fonction d’invalidation » pour les coupons, une date de validité et une date d’expiration utilisées pour les billets d’événement.

Vous pouvez également **définir la distance** à partir d’une latitude et d’une longitude pertinentes auxquelles la Carte est pertinente, pour **les notifications de géorepérage.**

<figure><img src="/files/6bbb9faaa7cc07e2b06b0f9ec1312299886b6383" alt="Gift card - general section Apple"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** qui est compatible avec votre logiciel de point de vente. La valeur du code-barres correspond aux **identifiants** qui vous permettront d’identifier la carte avec votre terminal en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si celui-ci ne peut pas être scanné.

<figure><img src="/files/33a27f16e0701788a83e50567c71b864784e19d2" alt="Gift card - barcode Apple"><figcaption></figcaption></figure>

### Couleurs et images

Pour modifier la couleur d’arrière-plan de votre carte, il suffit de **ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, téléversez-la depuis votre appareil.

<figure><img src="/files/6a3f1d8361f77cbc2e42ed2768b99c167d17bdeb" alt="gift card - colors and images Apple"><figcaption></figcaption></figure>

### Champs d’en-tête

Cette section est particulièrement importante dans la version Apple, car les cartes sont **empilées les unes sur les autres**. Seul l’en-tête de la carte reste visible. Il est donc important que cette section attire le regard et encourage à cliquer sur la carte, notamment en affichant les informations les plus importantes comme le montant disponible.

<figure><img src="/files/5fca6bf2e9ec415b50dbf54fec3eaba035a968da" alt="gift card - header fields Apple"><figcaption></figcaption></figure>

### Champs du recto

Les champs du recto sont les champs utilisés pour **afficher des informations sur le recto de la carte** , sous l’image de bandeau. L’étiquette que vous choisirez est la même pour chaque utilisateur (par langue), mais vous pouvez personnaliser la valeur à afficher, par exemple la date d’expiration de la carte.

<figure><img src="/files/6a2efbdf43cccc090cf0ec41a531cfad7a5b056e" alt="display information in the recto of the card"><figcaption></figcaption></figure>

{% hint style="warning" %}
**Pour personnaliser les champs du recto, veuillez vous référer à votre équipe technique afin de savoir quelle valeur dynamique vous devez indiquer.**
{% endhint %}

#### Champs du verso <a href="#backfields" id="backfields"></a>

Cette section, située au dos de la carte de fidélité, inclut plusieurs informations utiles pour le client :

* La date d’expiration de la carte-cadeau
* Le montant
* Reçus
* Messages personnalisés
* Liens, tels que les conditions générales, etc.

<figure><img src="/files/7273a5250a51450a4ec0809be5ebe2f3258eb04b" alt="gift card - backfields Apple"><figcaption></figcaption></figure>

### Autres sections

Sur Apple, vous avez également trois autres sections :

* **Emplacements** : utilisés pour les notifications de géorepérage.
* **Balises** : également utilisées pour les notifications de géorepérage.
* **Identifiant du magasin associé** : vous pouvez lier votre application si elle se trouve sur l’Apple Store
* **NFC** : une fonctionnalité qui permet aux clients d’échanger du contenu numérique et de connecter des appareils électroniques d’un simple contact.

{% hint style="warning" %}
**Veuillez contacter votre représentant The Wallet Crew pour activer ces fonctionnalités**
{% endhint %}

{% hint style="danger" %}
**Une fois vos modifications effectuées, n’oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

***

## Google

**Le concepteur de modèles Google est un peu différent de celui d’Apple.**

{% hint style="warning" %}
**Voici quelques éléments à connaître avant de configurer votre modèle Google :**
{% endhint %}

1. Certains champs tels que l’émetteur et le nom du programme sont **obligatoires**
2. Google préconfigure les champs en fonction de leur valeur prévue, alors conservez le solde dans les champs dédiés au solde/à la valeur
3. Les valeurs dynamiques (par exemple, {{balance}}) doivent être **placées dans les champs dynamiques dédiés**. Les champs « Label » sont destinés uniquement au texte statique.

**Examinons les différentes sections.**

### Section générale

Dans la section générale, vous avez trois **champs obligatoires** à remplir :

* **Émetteur** : le nom de la marque ou de l’entreprise qui émet la Carte
* **Nom du programme** : il apparaît sur le recto de la Carte, il peut s’agir par exemple du nom de votre programme de fidélité
* **Numéro de carte** : le numéro de la carte-cadeau

<figure><img src="/files/781afcd289cc7f973172a3e299107393c325147a" alt="gift card - general section Google"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** qui est compatible avec votre logiciel de point de vente. La valeur du code-barres correspond aux **identifiants** qui vous permettront d’identifier la carte avec votre terminal en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si celui-ci ne peut pas être scanné.

<figure><img src="/files/46f3946d9b9b48c2185f81dbfa11a7f53283a384" alt="gift card - barcode Google"><figcaption></figcaption></figure>

### Sécurité

Lorsque vous configurez un modèle, vous devez décider **si le client peut partager sa Carte ou non**. Concernant Google, vous avez trois options :

* **Plusieurs détenteurs** : cela signifie que le client peut partager sa Carte avec n’importe qui
* **Un utilisateur, tous les appareils** : un client, mais avec plusieurs appareils (une montre par exemple)
* **Un utilisateur, un appareil**

<figure><img src="/files/b924bb7768f519afce1930aa1a3f4380300c8004" alt="gift card - security Google"><figcaption></figcaption></figure>

### Couleurs et images

Pour modifier la couleur d’arrière-plan de votre carte, il suffit de **ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, téléversez-la depuis votre appareil.

<figure><img src="/files/5c01c1fc2af469521df28cdacdf2eea7d2a412aa" alt="gift card - colors and images Google"><figcaption></figcaption></figure>

### Solde et code PIN

Dans cette section, vous devez saisir la valeur dynamique du montant de la carte-cadeau et la devise, car ce sont des champs obligatoires. Vous pouvez également configurer une étiquette PIN et un PIN si nécessaire.

<figure><img src="/files/d54a46e194352d1f1f6ce9cc0a1b612f121d06d8" alt="gift card - balance and pin Google"><figcaption></figcaption></figure>

### Liens supplémentaires, Smart Tap et intervalle de validité

Vous pouvez décider d’ajouter **des liens supplémentaires** à la carte-cadeau du client, par exemple le lien de votre site web !

De plus, vous pouvez également configurer la **fonction Smart Tap** qui permet à votre client de simplement **valider sa carte-cadeau** en approchant son appareil de votre terminal compatible.

Enfin, la section d’intervalle de validité vous permet de **définir quand une carte-cadeau peut être utilisée !**

<figure><img src="/files/074a1bb280dc7424d71e350d021dc15c0949b965" alt="gift card - smart tap Google" width="375"><figcaption></figcaption></figure>

### Messages

Cette section, située au dos de la carte-cadeau, inclut plusieurs informations utiles pour le client :

* La date d’expiration de la carte-cadeau
* Le montant
* Reçus
* Messages personnalisés
* Liens, tels que les conditions générales, etc.

<figure><img src="/files/671ab94bbef1ced1d222c923335f94f9de6a36a9" alt="gift card - messages Google"><figcaption></figcaption></figure>

### Opportunités à valeur ajoutée

Cette section vous permet d’ajouter une **petite section en bas de la carte-cadeau**. Elle est utilisée pour afficher des offres ou des actualités.

### Autres sections

Sur Google, vous avez également quatre autres sections :

* **Liens d’application** : utilisés pour ajouter un lien vers une application
* **Page d’accueil** : utilisée pour ajouter le lien du site web de l’événement
* **Emplacements** : utilisé pour les notifications de géorepérage

{% hint style="danger" %}
**Une fois vos modifications effectuées, n’oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

### Étapes suivantes

* Pour les consignes de conception, commencez par [Conception de la carte](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields).
* Pour distribuer la Carte, utilisez [Distribution (SDK)](/connectors/fr/ticketing/aparte).


# Offre

Configurez un modèle de Carte d’offre pour Apple Wallet et Google Wallet. Utilisez-le pour des coupons et des remises à durée limitée.

## À quoi servent les offres ?

Les offres sont conçues pour diffuser des incitations promotionnelles à vos clients dans un format simple et numérique. Elles vous aident à générer du trafic, à augmenter les conversions et à lancer des campagnes à durée limitée directement dans les portefeuilles mobiles. Une offre peut servir à promouvoir une réduction, mettre en avant un événement spécial, récompenser des segments spécifiques de clients ou soutenir des campagnes saisonnières.

Que vous soyez un nouveau client souhaitant créer un modèle pour la carte que vous distribuerez à vos clients, ou un expert Wallet Crew souhaitant mettre à jour un modèle existant, cet article vous guidera pas à pas dans notre Template Designer. L'objectif est de configurer un modèle d'offre qui reflète l'identité de votre marque, affiche les bonnes informations à vos clients et garantit une expérience fluide sur Apple Wallet et Google Wallet.

Utilisez une **Offre** carte d'offre lorsque la carte est un **coupon**. C'est le format le plus adapté aux réductions ponctuelles ou limitées dans le temps.

Schémas courants :

* Un code-barres ou un code utilisé en caisse ou au moment du paiement
* Une date d'expiration et des contraintes d'utilisation
* Messages de campagne diffusés pendant la durée de l'offre

Si la carte représente une valeur stockée, utilisez [Carte cadeau](/guides-design/fr/conception/gift-card) à la place.

### Architecture

Apple et Google ont leurs propres modèles d'offre.

{% tabs %}
{% tab title="Apple" %}

<figure><img src="/files/eafb0e6fe20c735b4bdfe53d966af5fe1fde6bfc" alt="The Wallet Crew offer - Apple architecture"><figcaption><p>Concepteur de modèle d'offre (Apple)</p></figcaption></figure>
{% endtab %}

{% tab title="Google" %}

<figure><img src="/files/dadaed5be51631ef2100faba57562aba2b925dd0" alt="The Wallet Crew Offers - Google architecture"><figcaption><p>Concepteur de modèle d'offre (Google)</p></figcaption></figure>
{% endtab %}
{% endtabs %}

{% hint style="info" %}
**Si vous voulez aller plus loin, retrouvez tous les détails des deux versions :**
{% endhint %}

**Apple**

{% embed url="<https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/Creating.html>" %}

**Google**

{% embed url="<https://developers.google.com/wallet/retail/offers/resources/template>" %}

### Comment le configurer sur The Wallet Crew

Avec The Wallet Crew, vous avez accès à un concepteur de modèles qui vous permet de personnaliser les cartes d'offre que vous distribuerez à vos clients. Voyons en détail comment personnaliser chaque section !

## Apple

**Examinons les différentes sections du concepteur de modèle Apple.**

### Section générale

Dans la section générale, vous avez deux champs obligatoires à remplir :

* **Description** : une brève description de la carte, qui apparaîtra au dos de la carte
* **Nom de l'organisation** : le nom de votre entreprise ou de votre marque

Vous avez également la possibilité d'ajouter un texte à côté de votre logo, **activer le partage de la carte** si vous souhaitez que vos clients puissent la partager ou non avec d'autres personnes, et la **fonction « annulation » pour les coupons**.

Vous pouvez également **définir la distance** à partir d'une latitude et d'une longitude pertinentes auxquelles la carte d'offre est pertinente, pour **les notifications de géorepérage.**

<figure><img src="/files/d63ccedaab4a368e7e105de57adc7bb7c88f89e1" alt="The Wallet Crew Offers - General Apple"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** compatible avec votre matériel de contrôle. La valeur du code-barres correspond aux **identifiants** qui vous permettront d'identifier l'offre en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si celui-ci ne peut pas être scanné.

<figure><img src="/files/4926686100c8e1d2eaa77269cc9cb00d7bbc4f63" alt="The Wallet Crew Offers - Barcode Apple"><figcaption></figcaption></figure>

### Couleurs et images

Pour changer la couleur de fond de votre carte d'offre, il suffit de **ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, téléchargez-la depuis votre appareil.

### Champs d'en-tête <a href="#header-fields" id="header-fields"></a>

Cette section est particulièrement importante dans la version Apple, car les offres sont **empilées les unes sur les autres**. Seul l'en-tête de la carte d'offre reste visible. Il est donc important que cette section attire l'attention et incite à cliquer sur la carte, notamment en affichant les informations les plus importantes, comme le montant restant.

<figure><img src="/files/875403015dd07ee18dade3fd15cee4c8186a8d32" alt="The Wallet Crew Offers - Header field Apple"><figcaption></figcaption></figure>

### Champs de recto

Les champs de recto sont les champs utilisés pour **afficher des informations sur le recto de l'offre**, sous l'image bandeau. L'intitulé que vous choisirez sera le même pour chaque utilisateur (par langue), mais vous pouvez personnaliser la valeur pour afficher par exemple la date d'expiration.

<figure><img src="/files/6a8272d19fd78dc839fb94e5be7e2fbef2f87cad" alt="The Wallet Crew Offers - Front fields Apple"><figcaption></figcaption></figure>

{% hint style="warning" icon="wand-magic-sparkles" %}
**Pour personnaliser les champs de recto, veuillez vous référer à votre équipe technique afin de déterminer quelle valeur dynamique vous devez renseigner.**
{% endhint %}

#### Champs de verso <a href="#backfields" id="backfields"></a>

Cette section, située au dos de la carte d'offre, comprend plusieurs informations utiles pour le client :

* Date d'expiration
* Informations sur la marque
* Reçus
* La possibilité d'ajouter des liens, comme un lien vers un site web

<figure><img src="/files/57031fe871099397ec857fcfa007e1392507c879" alt="The Wallet Crew Offers - Backfields Apple"><figcaption></figcaption></figure>

### Autres sections

Sur Apple, vous avez également quatre autres sections :

* **Emplacements** : utilisés pour les notifications de géorepérage.
* **Balises** : également utilisées pour les notifications de géorepérage.
* **Identifiant du magasin associé** : vous pouvez associer votre application si elle se trouve sur l'Apple Store
* **NFC** : une fonctionnalité qui permet aux clients d'échanger du contenu numérique et de connecter des appareils électroniques d'un simple contact.

{% hint style="warning" %}
**Veuillez contacter votre interlocuteur The Wallet Crew pour activer ces fonctionnalités**
{% endhint %}

{% hint style="danger" %}
**Une fois vos modifications effectuées, n'oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

## Google

**Le concepteur de modèle Google est un peu différent de celui d'Apple.**

{% hint style="warning" %}
**Voici quelques éléments à connaître avant de configurer votre modèle Google :**
{% endhint %}

1. Certains champs tels que « Redemption Channel » et « Provider » sont **obligatoires**
2. Google préconfigure les champs en fonction de leur valeur prévue
3. Les valeurs dynamiques (par ex. {{firstName}}) doivent être **placées dans des champs dynamiques dédiés**. Les champs « Label » sont destinés uniquement au texte statique.

**Examinons les différentes sections.**

### Section générale

Dans la section générale, vous avez trois **champs obligatoires** à remplir :

* **Émetteur**: le nom de la marque ou de l'entreprise qui émet l'offre
* **Général**: le titre de l'offre, comme « 20 % de réduction sur n'importe quel t-shirt. »
* **État :** l'état de votre carte (active, expirée, terminée, inactive)
* **Fournisseur :** le fournisseur de l'offre (soit le nom de l'agrégateur, soit celui du commerçant).
* **Canal d'utilisation :** en magasin, en ligne, les deux ou non spécifié

<figure><img src="/files/4713d9d952a0713a3a523e710b9b6fe0c4355236" alt="The Wallet Crew offers - General Google"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** compatible avec votre matériel de contrôle. La valeur du code-barres correspond aux **identifiants** qui vous permettront d'identifier l'offre en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si celui-ci ne peut pas être scanné.

<figure><img src="/files/6c01466a04e5e6c68de6cf0a3e095afa58024938" alt="The Wallet Crew Offers - Barcode Google"><figcaption></figcaption></figure>

### Sécurité

Lorsque vous configurez un modèle, vous devez décider **si le client peut partager sa carte ou non**. Pour Google, vous avez trois options :

* **Plusieurs détenteurs**: cela signifie que le client peut partager sa carte avec n'importe qui
* **Un utilisateur, tous les appareils**: un seul client, mais sur plusieurs appareils (une montre, par exemple)
* **Un utilisateur, un appareil**

<figure><img src="/files/2079a9f29d830a6f2dc16b7f2a65bca8823a892d" alt="The Wallet Crew Offers - Security Google"><figcaption></figcaption></figure>

### Couleurs et images

Pour changer la couleur de fond de votre offre, il suffit de **ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, téléchargez-la depuis votre appareil.

<figure><img src="/files/fe1a9f76d290219995d99cebf0e89309e461de55" alt="The Wallet Crew Offers - Colors and images Google"><figcaption></figcaption></figure>

#### Liens supplémentaires, Smart tap et intervalle de validité <a href="#additional-links-smart-tap-and-valid-time-interval" id="additional-links-smart-tap-and-valid-time-interval"></a>

Vous pouvez décider d'ajouter **des liens supplémentaires** à l'offre du client, par exemple le lien du site web de l'événement !

De plus, vous pouvez également configurer la **fonctionnalité Smart tap** qui permet à votre client de simplement **valider leur offre** en présentant leur appareil sur votre terminal matériel compatible.

Enfin, la section Intervalle de validité vous permet de **définir une date de début et une date de fin** pour votre offre !

<figure><img src="/files/32c2decc2efcb9d322ee11d1ff542676ddf70010" alt="The Wallet Crew Offers - Smart tap Google"><figcaption></figcaption></figure>

### Messages

Cette section, située au dos de la carte d'offre, peut inclure plusieurs informations utiles pour le client :

* Date d'expiration
* Informations sur la marque
* Reçus
* La possibilité d'ajouter des liens, comme un lien vers un site web

<figure><img src="/files/b5fc1e9811292ab0b8ba8dfaa92cf374b83667bd" alt="The Wallet Crew Offers - Messages Google"><figcaption></figcaption></figure>

### Opportunités à valeur ajoutée

Cette section vous permet d'ajouter une **petite section en bas de l'offre**. Elle sert à afficher des offres ou des actualités.

<figure><img src="/files/915881a3b6ac0155eeec136b1cbc0191d62f6a32" alt="The Wallet Crew offers - Value added opportunities"><figcaption></figcaption></figure>

### Autres sections

Sur Google, vous avez également quatre autres sections :

* **Valeur faciale** : le prix de l'offre
* **Liens d'application** : utilisé pour ajouter un lien vers une application
* **Page d'accueil** : utilisé pour ajouter le lien du site web de l'événement
* **Emplacements** : utilisé pour les notifications de géorepérage

{% hint style="danger" %}
**Une fois vos modifications effectuées, n'oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

#### FAQ

<details>

<summary><strong>Quand faut-il utiliser « Face Value » sur une offre ?</strong></summary>

Utilisez-le lorsque vous souhaitez que Google Wallet affiche un montant monétaire dans l'offre.

Assurez-vous qu'il soit cohérent avec ce que votre client verra au moment du paiement (devise, décimales et formulation dans le titre de l'offre).

</details>

<details>

<summary><strong>Les liens d'application nécessitent-ils une application mobile ?</strong></summary>

Oui. Les liens d'application servent à rediriger les clients vers votre application Android (ou vers une page que vous contrôlez, selon votre configuration).

Si vous n'avez pas d'application, laissez cette section vide et utilisez plutôt des liens standards dans la carte.

</details>

<details>

<summary><strong>Que se passe-t-il si nous définissons des emplacements ?</strong></summary>

Les emplacements peuvent aider à faire apparaître la carte lorsque les clients se trouvent à proximité d'un lieu précis, et ils peuvent prendre en charge des interactions basées sur la localisation.

Commencez d'abord par un petit nombre d'emplacements de magasin. Validez l'expérience sur de vrais appareils avant un déploiement dans tous les magasins.

</details>

### Étapes suivantes

* Pour les recommandations de conception, commencez par [Conception de carte](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields).
* Pour distribuer la carte, utilisez [Distribution (SDK](/connectors/fr/ticketing/aparte)).


# Générique

Configurez un modèle de Carte générique pour Apple Wallet et Google Wallet. Utilisez-le pour des cartes d’adhésion flexibles, des Cartes utilitaires et des mises en page personnalisées.

La carte générique est le type de carte le plus flexible disponible. Elle est conçue pour des cas d’utilisation qui ne s’intègrent pas naturellement dans l’un des modèles dédiés, comme les cartes de fidélité, les cartes cadeaux, les offres ou les billets. Si votre carte ne correspond pas à une catégorie prédéfinie mais doit tout de même être distribuée via Apple Wallet ou Google Wallet, le modèle générique est probablement le bon choix.

Utilisez une carte générique lorsque vous avez besoin d’une mise en page flexible qui ne correspond pas à un modèle dédié (fidélité, carte cadeau, offre, billet).

**Cas d’utilisation typiques :**

* Cartes d’adhésion qui ne relèvent pas de programmes de fidélité
* Badges de partenaires ou de personnel
* Cartes utilitaires (carte de garantie, carte de retrait, carte de service)
* Bons qui ne sont pas des remises (article gratuit, avantage, droit)

Si vous n’êtes pas sûr, partez de [Types de Carte et modèles](/guides-design/fr/conception/readme-1) et choisissez **Générique** uniquement en solution de repli.

### Architecture (Apple vs Google)

Apple et Google fournissent chacun leur propre structure de modèle générique.

{% tabs %}
{% tab title="Apple" %}

<figure><img src="/files/e83b4e5f3be8f484ff00b9b24ae991e8ca84bc2c" alt="The Wallet Crew generic - Architecture Apple"><figcaption><p>Modèle de carte générique Apple</p></figcaption></figure>
{% endtab %}

{% tab title="Google" %}

<figure><img src="/files/0a83bfb0ccaf5617a0c82dce69aa57e00f8dce75" alt="The Wallet Crew generic - Architecture Google"><figcaption><p>Modèle de carte générique Google</p></figcaption></figure>
{% endtab %}
{% endtabs %}

{% hint style="info" %}
**Si vous voulez aller plus loin, retrouvez tous les détails des deux versions :**
{% endhint %}

**Apple**

{% embed url="<https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/Creating.html>" %}

**Google**

{% embed url="<https://developers.google.com/wallet/reference/rest/v1/genericclass>" %}

### Comment le configurer sur The Wallet Crew

Avec The Wallet Crew, vous avez accès à un concepteur de modèles qui vous permet de personnaliser les cartes génériques que vous distribuerez à vos clients. Voyons en détail comment personnaliser chaque section !

## Apple

**Regardons les différentes sections du concepteur de modèles Apple.**

### Section générale

Dans la section générale, vous avez deux champs obligatoires à remplir :

* **Description** : une brève description de la carte, qui apparaîtra au verso de la carte
* **Nom de l'organisation** : le nom de votre entreprise ou de votre marque

Vous avez également la possibilité d'ajouter un texte à côté de votre logo, **activez le partage du billet** si vous souhaitez que vos clients puissent le partager ou non avec d’autres personnes, et la **la fonctionnalité d’invalidation de la carte**.

Vous pouvez également **définir la distance** à partir d'une latitude et d'une longitude pertinentes afin que la carte soit pertinente, pour **les notifications de géorepérage.**

<figure><img src="/files/6153e31bde425deb19367cc9c1c7b3ea0f368c0d" alt="The Wallet Crew Generic - Apple general"><figcaption></figcaption></figure>

### Code-barres

Choisissez le **type de code-barres** qui est compatible avec votre matériel de contrôle. La valeur du code-barres correspond à **identifiants** qui vous permettra d’identifier la carte en magasin. Enfin, le texte alternatif peut être utilisé pour afficher les données du code-barres si le code-barres ne peut pas être scanné.

<figure><img src="/files/76355328ca9bf3801f93198bbb67ca411a3d5d6d" alt="The Wallet Crew generic - Barcode Apple"><figcaption></figcaption></figure>

### Couleurs et images

Pour changer la couleur de fond de votre carte, il suffit de **d'ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, importez-la depuis votre appareil.

### Champs d'en-tête <a href="#header-fields" id="header-fields"></a>

Cette section est particulièrement importante dans la version Apple, car les offres sont **empilées les unes sur les autres**. Seul l’en-tête de la carte d’offre reste visible. Il est donc important que cette section attire l’attention et incite à cliquer sur la carte, notamment en affichant les informations les plus importantes telles que le nom du client.

<figure><img src="/files/4855fa2fd85caa1fc51aebcdef1e6a67f9077762" alt="The Wallet Crew Generic - Header fields Apple"><figcaption></figcaption></figure>

### Champs de face

Les champs de face sont les champs utilisés pour **afficher des informations au recto de la carte**, sous l’image de bande. L’intitulé que vous choisirez est le même pour chaque utilisateur (par langue), mais vous pouvez personnaliser la valeur pour afficher par exemple la date d’expiration.

<figure><img src="/files/f2deaa699e0f3b431135c0543a44d0b64fd73d1c" alt="The Wallet Crew generic - Front fields Apple"><figcaption></figcaption></figure>

{% hint style="warning" %}
**Pour personnaliser les champs de face, veuillez vous référer à votre équipe technique afin de savoir quelle valeur dynamique vous devez saisir.**
{% endhint %}

### **Champs de verso**

Cette section, située au verso de la carte, inclut plusieurs informations utiles pour le client :

* Date d'expiration
* Informations concernant la marque
* Reçus
* La possibilité d’ajouter des liens, comme un lien vers un site web

<figure><img src="/files/d6a5a082efb9fcdb708142b6eb50cf3c386687f1" alt="The Wallet Crew generic - Backfields Apple"><figcaption></figcaption></figure>

### Autres sections

Sur Apple, vous avez également quatre autres sections :

* **Emplacements** : Utilisé pour les notifications de géorepérage.
* **Balises** : Utilisé également pour les notifications de géorepérage.
* **Identifiant du magasin associé** : Vous pouvez lier votre application si elle se trouve sur l'App Store
* **NFC** : Une fonctionnalité qui permet aux clients d'échanger du contenu numérique et de connecter des appareils électroniques par simple contact.

{% hint style="warning" %}
**Veuillez contacter votre représentant The Wallet Crew pour activer ces fonctionnalités**
{% endhint %}

{% hint style="danger" %}
**Une fois que vous avez effectué quelques modifications, n'oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

## Google

**Le concepteur de modèles Google est légèrement différent de celui d'Apple.**

{% hint style="warning" %}
**Voici quelques éléments à savoir avant de configurer votre modèle Google :**
{% endhint %}

1. Certains champs tels que « Général » et « En-tête » sont **obligatoires**
2. Google préconfigure les champs en fonction de leurs valeurs prévues
3. Les valeurs dynamiques (par ex. {{firstName}}) doivent être **placées dans des champs dynamiques dédiés**. Les champs « Label » sont destinés au texte statique uniquement.

**Jetons un coup d'œil aux différentes sections.**

### Section générale

Dans la section générale, vous avez trois **champs obligatoires** à remplir :

* **Général** : le titre de la carte.
* **En-tête :** l’en-tête de la carte
* **Sous-en-tête :** le sous-en-tête de la carte, comme l’emplacement où cette carte peut être utilisée
* **État :** l’état de l’objet.

<figure><img src="/files/6ce11e604a04092f274ddf9267ff8db7dac008af" alt="The Wallet Crew generic - General Google"><figcaption></figcaption></figure>

### Sécurité

Lorsque vous configurez un modèle, vous devez décider **si le client peut partager sa carte ou non**. Concernant Google, vous avez trois options :

* **Plusieurs titulaires**: cela signifie que le client peut partager sa carte avec n'importe qui
* **Un utilisateur, tous les appareils**: un client, mais avec plusieurs appareils (une montre par exemple)
* **Un utilisateur, un appareil**

<figure><img src="/files/ea37c0d166efea819b61d6b8f3fd1395aba62ca0" alt="The Wallet Crew generic - Security Google"><figcaption></figcaption></figure>

### Couleurs et images

Pour changer la couleur de fond de votre carte, il suffit de **d'ajouter le code couleur dans les champs** prévus à cet effet. Pour ajouter une image, importez-la depuis votre appareil.

<figure><img src="/files/655d18b6c6d0348e10e098599dde3d9f3f48ad2b" alt="The Wallet Crew Generic - Colors and images Google"><figcaption></figcaption></figure>

#### Liens supplémentaires, Smart Tap et intervalle de temps valide <a href="#additional-links-smart-tap-and-valid-time-interval" id="additional-links-smart-tap-and-valid-time-interval"></a>

Vous pouvez décider d’ajouter **des liens supplémentaires** à la carte du client, par exemple le lien du site web de l’événement !

De plus, vous devez configurer la **fonctionnalité Smart Tap** qui permet à votre client de simplement **valider sa carte** en approchant leur appareil de votre terminal matériel compatible.

Enfin, la section Intervalle de temps valide vous permet de **définir une date de début et une date de fin** pour votre carte !

### Opportunités à valeur ajoutée

Cette section vous permet d'ajouter une **petite section en bas de la carte**. Elle sert à afficher des offres ou des actualités.

<figure><img src="/files/37a9071ac5b0010050164d6a7d1861ab406ed912" alt="The Wallet Crew Generic - Value added opportunities Google"><figcaption></figcaption></figure>

### Autres sections

Sur Google, vous avez également quatre autres sections :

* **Liens d’application**  : utilisé pour ajouter un lien vers une application
* **Page d’accueil**  : utilisé pour ajouter le lien du site web de l’événement
* **Emplacements**  : utilisé pour les notifications de géorepérage

{% hint style="danger" %}
**Une fois que vous avez effectué quelques modifications, n'oubliez pas de cliquer sur « enregistrer » en haut de votre écran !**
{% endhint %}

### Étapes suivantes

* Pour les recommandations de conception, commencez par [Conception de carte](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields).
* Pour distribuer la carte, utilisez [Distribution (SDK)](/connectors/fr/ticketing/aparte).


# Guides d’inscription

Choisissez et concevez le bon canal d’inscription et de distribution de Carte.

L'inscription définit comment un client obtient l'installation d'une carte Apple Wallet ou d'une carte Google Wallet. Pour la plupart des projets, l'inscription est un sujet clé. Elle nécessite une analyse et une conception.

L'inscription n'est pas seulement un mécanisme de वितरण. C'est le système qui relie l'acquisition, la résolution d'identité, la collecte de données et l'installation de la carte.

Chaque choix de conception effectué lors de l'inscription a des effets en aval. Il peut améliorer la conversion, renforcer la qualité des données, réduire les doublons et rendre la réinstallation fiable après un changement d'appareil. Avec le temps, ces détails déterminent si un programme Wallet devient une habitude ou reste une installation ponctuelle.

<details>

<summary><strong>Exemples concrets</strong></summary>

* **Acquisition de fidélité en magasin :** un code QR ouvre un formulaire d'inscription et émet une carte de fidélité.
* **Accès à la carte cadeau après l'achat :** une page de compte affiche « Ajouter à Wallet » pour installer la carte cadeau.
* **Programme d'adhésion :** un lien e-mail permet aux clients de réinstaller une carte de membre après un changement d'appareil.
* **Billetterie d'événements :** une page après l'achat ou un écran dans l'application déclenche l'installation du billet.

</details>

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3>Formulaire d'inscription</h3></td><td><a href="/files/6f515cdcd482e21df97ce28c12b0a75a15a52a08">/files/6f515cdcd482e21df97ce28c12b0a75a15a52a08</a></td><td><a href="/pages/a86fc1d93c86289202b592d4a68ed898cdf3e95f">/pages/a86fc1d93c86289202b592d4a68ed898cdf3e95f</a></td></tr><tr><td><h3>Intégration au site web</h3></td><td><a href="/files/271bc72ef15fa0597d15feb1b8384648ffb156cc">/files/271bc72ef15fa0597d15feb1b8384648ffb156cc</a></td><td><a href="/pages/5534d0b648e2c7b8893d01f22a5e203897c27848">/pages/5534d0b648e2c7b8893d01f22a5e203897c27848</a></td></tr><tr><td><h3>Distribution par e-mail</h3></td><td><a href="/files/6fb2b9af09253c335d4e76352762d7b2e478b7d9">/files/6fb2b9af09253c335d4e76352762d7b2e478b7d9</a></td><td><a href="/pages/77da4bfb084a727011695679af882fd6e1b9e514">/pages/77da4bfb084a727011695679af882fd6e1b9e514</a></td></tr><tr><td><h3>Intégration à l'application mobile</h3></td><td><a href="/files/317ce9ccfa42d8f62b189bb135c5751277ea7575">/files/317ce9ccfa42d8f62b189bb135c5751277ea7575</a></td><td><a href="/pages/2fdd33bfcbbbfac8e6564d10e059f88b656c9886">/pages/2fdd33bfcbbbfac8e6564d10e059f88b656c9886</a></td></tr><tr><td><h3>Pages de téléchargement</h3></td><td></td><td><a href="/pages/ec0de3fca09f6217dd9d1ed75758b47614b320a8">/pages/ec0de3fca09f6217dd9d1ed75758b47614b320a8</a></td></tr></tbody></table>

## Canaux d'inscription

The Wallet Crew propose plusieurs façons de s'inscrire au meilleur moment du parcours client.

En pratique, l'inscription correspond à l'endroit où « Ajouter à Wallet » est exposé, par exemple via un code QR, un bouton du site web, un lien e-mail ou une action dans l'application.

En pratique, le « meilleur moment » désigne généralement un moment où l'intention est forte et où l'identité est facile à résoudre. Pour la fidélité et l'adhésion, ce moment est souvent l'action d'adhésion. Pour les billets et les cartes cadeaux, ce moment est souvent une zone authentifiée ou un écran après l'achat.

Les pages ci-dessus couvrent les principaux canaux d'inscription et de distribution pris en charge par The Wallet Crew.

Certains projets nécessitent une intégration plus poussée pour conserver l'inscription entièrement intégrée aux flux web ou applicatifs existants. Dans ces cas, le SDK The Wallet Crew peut être utilisé sur un site web ou dans une application mobile native, selon l'architecture choisie.

Les pages de téléchargement prennent en charge la distribution après qu'une carte existe déjà. Elles affichent les actions Wallet pour une carte ou une liste de cartes. Elles ne collectent pas de données d'inscription ni de consentement. Voir [Pages de téléchargement](/guides-enrolment/fr/inscription/pages-de-telechargement).

## Autres modèles pris en charge

Certains projets nécessitent des modèles d'inscription supplémentaires. Le plus courant est **l'inscription en masse**. Elle est utilisée lorsqu'une Brand dispose déjà d'une liste de clients ou de membres et souhaite émettre des cartes à grande échelle, par exemple lors d'une migration, pour des membres saisonniers ou pour des programmes d'entreprise.

L'inscription en masse peut être déclenchée depuis le back-office (import CSV ou Excel). Elle peut aussi être automatisée via API ou via une intégration basée sur des fichiers, comme SFTP, selon le périmètre du projet. Pour les projets de migration, voir [Migration de Carte](https://docs.thewalletcrew.io/configuration/wallet/import-and-export/pass-migration).

Le résultat de l'inscription en masse est généralement un **lien de carte** par client. La Brand peut distribuer ce lien via ses propres canaux. L'envoi de bout en bout peut également être confié à The Wallet Crew, lorsque nécessaire.

L'inscription en masse sépare la génération des cartes de leur distribution. Cela rend les déploiements flexibles à grande échelle. Si les cartes doivent être remises en dehors de The Wallet Crew, voir [Exporter les cartes de TWC vers un autre fournisseur](https://docs.thewalletcrew.io/configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider).

## Pourquoi la conception de l'inscription est importante

L'inscription fait partie de l'expérience produit. Elle définit la « porte d'entrée » d'un programme Wallet. Elle définit aussi les règles pour identifier un client et décider quelle carte doit être installée.

#### Commencer par le moment de valeur

La bonne conception commence généralement au moment où la carte devient utile. Le canal choisi doit correspondre à ce moment.

* Acquisition en magasin → QR + formulaire d'inscription
* Achat authentifié ou accès au compte → intégration web ou intégration à l'application native
* Remise d'une carte existante → page de téléchargement
* Migration ou amorçage d'un programme existant → inscription en masse
* Réinstallation ou changement d'appareil → distribution par e-mail comme solution de secours robuste

Les moments de renouvellement et de réinstallation doivent être traités comme des flux de premier ordre. Ils favorisent l'adoption à long terme et réduisent la charge de support.

#### Choisir tôt une stratégie d'identité

La conception de l'identité est la contrainte suivante. Une clé de correspondance est nécessaire pour éviter les doublons et garantir que la bonne carte est renvoyée. L'e-mail est courant, mais il n'est pas toujours stable. Le numéro de téléphone, le numéro de membre, l'ID de commande du billet ou un identifiant CRM peuvent être de meilleures clés selon le programme.

Lorsque l'inscription repose sur un formulaire, la résolution d'identité et les vérifications d'éligibilité sont souvent mises en œuvre via [l'authentification sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) et [les règles de validation](/guides-enrolment/fr/inscription/enrolment-form/validation-rules).

#### Limiter au minimum la collecte de données

La collecte de données doit rester minimale lors de l'inscription. Les champs qui ne sont pas nécessaires à l'émission peuvent être collectés plus tard. Cela améliore généralement le taux de complétion tout en maintenant une qualité de données élevée.

Lorsque le consentement est recueilli lors de l'inscription, alignez le libellé du consentement et son stockage avec la politique de confidentialité de la Brand, les [politiques de confidentialité et de sécurité](https://docs.thewalletcrew.io/policies/privacy-and-security) et le modèle d'accord de traitement des données [Modèle d'accord de traitement des données](https://docs.thewalletcrew.io/policies/privacy-and-security/data-processing-agreement-model).

## Approche recommandée

La plupart des projets convergent vers une approche simple : un canal principal, plus un canal de secours.

Le canal principal doit correspondre à l'endroit où le programme « vit » pour les clients. La fidélité et l'adhésion vivent souvent en magasin ou lors de l'acquisition par campagne, ce qui fait du QR → formulaire une valeur par défaut solide. Les billets et les cartes cadeaux vivent souvent dans des environnements authentifiés, ce qui fait de la distribution par site web ou par application une valeur par défaut solide.

Le canal de secours est généralement la distribution par e-mail, car elle est résiliente sur tous les appareils et toutes les plateformes. C'est aussi un excellent moyen de réinstaller une carte lorsqu'elle a été supprimée ou lorsqu'un client change de téléphone.

## FAQ

<details>

<summary><strong>Y a-t-il une différence entre l'inscription et la distribution ?</strong></summary>

Dans cette documentation, il n'y en a pas.

Les deux termes renvoient au même sujet : choisir le point d'entrée (QR, web, e-mail, application), résoudre l'identité si nécessaire, et offrir l'expérience d'installation Apple Wallet / Google Wallet.

</details>

<details>

<summary><strong>Quel canal fonctionne le mieux pour les cartes de fidélité et de membre ?</strong></summary>

Un formulaire d'inscription est généralement le meilleur point de départ.

Il prend en charge la collecte de données, les règles d'éligibilité et l'identité. Il prend également en charge l'acquisition par QR en magasin et les flux assistés par le personnel.

</details>

<details>

<summary><strong>Quel canal fonctionne le mieux pour les billets et les cartes cadeaux ?</strong></summary>

Une interface de site web connectée ou une interface intégrée dans l'application est souvent la voie la plus simple.

Elle évite de recueillir à nouveau des données et utilise le contexte du compte existant pour résoudre l'identité.

</details>

<details>

<summary><strong>Pourquoi conserver la distribution par e-mail si un site web ou une application existe ?</strong></summary>

L'e-mail est un excellent canal de secours pour le bureau et pour les changements d'appareil.

Il réduit aussi la charge de support, car il crée un parcours de réinstallation en libre-service.

</details>

<details>

<summary><strong>Que signifie « inscription en masse » en pratique ?</strong></summary>

L'inscription en masse consiste à émettre des cartes pour une liste existante de clients ou de membres.

Elle est généralement utilisée pour les migrations, l'amorçage d'une base de fidélité, les adhésions d'entreprise ou les programmes saisonniers. Elle produit généralement un lien de carte par client, puis la distribution s'effectue soit via les canaux de la Brand, soit via un envoi délégué opéré par The Wallet Crew.

</details>


# Formulaire d’inscription

Configurez un formulaire d’inscription pour collecter les données client, appliquer les règles et émettre des Cartes Apple Wallet et Google Wallet.

Un formulaire d'inscription est la page web que les clients utilisent pour rejoindre un programme et enregistrer une carte. C'est aussi le moment clé de conversion où un client passe de l'intérêt à la possession, par exemple après avoir scanné un code QR, cliqué sur un lien d'e-mail ou appuyé sur un CTA.

Dans The Wallet Crew, le formulaire d'inscription est la « porte d'entrée » de l'expérience Apple Wallet et Google Wallet de la marque. Il collecte les données requises, applique les règles de la marque, capture les consentements requis, puis émet la carte avec la bonne expérience « Add to Wallet ». Lorsqu'un client soumet le formulaire, TWC crée un profil client — équivalent à un compte de fidélité — et émet immédiatement la carte Wallet.

<figure><img src="/files/6f515cdcd482e21df97ce28c12b0a75a15a52a08" alt="Example enrolment form used to collect customer data before pass issuance"><figcaption><p>Exemple de formulaire d'inscription utilisé pour collecter les données client avant l'émission de la carte.</p></figcaption></figure>

Dans The Wallet Crew, un formulaire d'inscription peut fonctionner pour les nouveaux clients et les clients existants. Si un client est déjà connu, le formulaire peut l'identifier tôt et éviter de poser les mêmes questions à nouveau.

<details>

<summary><strong>Exemples réels</strong></summary>

* Une marque de distribution place un code QR à la caisse pour inscrire les clients au programme de fidélité.
* Un organisateur d'événements utilise un formulaire court pour émettre une carte d'adhésion avant les préventes.
* Une marque de luxe envoie un lien e-mail après une visite en magasin pour créer un profil client.
* Une solution de billetterie intègre une étape de formulaire pour capturer les données manquantes avant d'émettre une carte.

</details>

## De l'acquisition à Wallet

Un formulaire d'inscription se situe entre le canal d'acquisition de la marque et le modèle de carte. Les clients y accèdent depuis un code QR, un site web, un e-mail, une application mobile ou un flux POS. The Wallet Crew crée ou met ensuite à jour les informations de la carte Wallet et génère l'expérience « Add to Wallet » appropriée.

Les performances d'inscription dépendent fortement du timing. Le même formulaire peut être diffusé à des moments à forte intention, comme des codes QR en magasin, des e-mails post-achat, des liens profonds dans une application mobile, des intégrations POS ou des relances de clienteling.

Pour obtenir plus d'informations sur les autres canaux de diffusion, voir :

* [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website)
* [Via e-mail](/guides-enrolment/fr/inscription/via-email)
* [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1)

## À quoi ressemble l'expérience

La plupart des formulaires d'inscription sont conçus pour être complétés en moins d'une minute sur mobile. Cela compte dans la vie réelle. De nombreux clients s'inscrivent en restant debout dans un magasin, en marchant ou en passant d'une application à l'autre.

### Flux typique

Les écrans exacts dépendent de la configuration, mais la logique reste la même.

1. Le client ouvre le formulaire depuis un lien ou un code QR.
2. Le formulaire identifie éventuellement le client en amont (connexion sociale ou enregistrement par e-mail).
3. Le client remplit les champs manquants et accepte les consentements si nécessaire.
4. The Wallet Crew crée ou met à jour le profil client.
5. La carte est émise et le client l'enregistre dans Apple Wallet ou Google Wallet.

{% hint style="info" %}
Le « minimum viable d'inscription » convertit généralement le mieux. Collectez uniquement ce qui est nécessaire pour émettre la carte et rester en conformité. Les profils pourront être enrichis plus tard.
{% endhint %}

## Configurer pour la performance

Un formulaire d'inscription combine des choix UX et des règles de données. L'objectif est de supprimer les frictions sans diminuer la qualité des données.

### Champs, données et validation

Chaque champ supplémentaire augmente le risque d'abandon. Les champs ne doivent être ajoutés que s'ils produisent un résultat commercial clair. Les exemples typiques sont une adresse e-mail ou un numéro de téléphone.

Les règles de validation protègent la qualité des données. Elles réduisent également les coûts de support par la suite. Pour plus d'informations sur les règles prises en charge comme `obligatoire`, `minLength`, `maxLength`, `email`, et `téléphone`, voir [Règles de validation](/guides-enrolment/fr/inscription/enrolment-form/validation-rules).

### Identité de marque et design

Les clients doivent faire confiance instantanément à la page. Le formulaire doit afficher le logo et les couleurs de la marque. Le texte doit correspondre à la voix de la marque. Le CTA principal doit être visible sans faire défiler.

Pour obtenir plus d'informations sur ce qui peut être personnalisé (logo, couleurs, typographie, image d'en-tête, palette claire/sombre), voir [Design](/guides-enrolment/fr/inscription/enrolment-form/design).

### Identifier les clients existants

Si le client existe déjà, le meilleur formulaire est celui qui ne repose pas les questions. The Wallet Crew prend en charge deux modèles courants.

La connexion sociale offre un flux d'identification en un tap sur mobile. Elle réduit les fautes de frappe. Elle réduit généralement les doublons. Pour plus d'informations, voir [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in).

L'enregistrement par e-mail ajoute une étape centrée sur l'e-mail. Il permet de détecter rapidement les clients existants. Il peut également ajouter une étape de sécurité si la vérification par e-mail est requise. Pour le flux de configuration, voir [Activer l'enregistrement par e-mail sur les formulaires d'inscription](https://docs.thewalletcrew.io/configuration/enrolment-form/enable-email-check-in-on-enrolment-forms).

{% hint style="warning" %}
L'identification n'est pas le consentement. Le consentement marketing doit être recueilli explicitement et séparément.
{% endhint %}

### Contexte en magasin avec redirections et magasins

De nombreuses marques utilisent le même formulaire d'inscription dans tous les magasins. Elles souhaitent tout de même un suivi et une personnalisation au niveau du magasin. C'est là que les redirections aident.

Une redirection est une URL courte et gérée qui peut ajouter des paramètres tels que `storeId`, la langue ou la source de la campagne. Le code QR obtenu peut être imprimé et déployé en magasin. Voir [Redirections](/guides-enrolment/fr/inscription/enrolment-form/redirect).

Les données de magasin sont la liste de référence derrière `storeId`. Elles sont utiles lorsqu'un nom de magasin ou une adresse doivent être affichés dans le parcours ou sur la carte. Voir [Magasins](/guides-enrolment/fr/inscription/enrolment-form/stores).

## Qualité des données

La qualité des données est un résultat principal de la conception de l'inscription. Elle a un impact sur la résolution d'identité, la segmentation, la personnalisation et le reporting. Elle réduit également l'effort opérationnel par la suite, surtout lorsque les données client sont synchronisées avec un CRM.

Des données de haute qualité proviennent généralement d'une combinaison de formulaires courts, d'une intention claire et de règles strictes au moment de la capture.

### Pourquoi l'inscription est un moment clé pour la qualité des données

L'inscription a lieu lorsque l'intention est forte. C'est alors que les clients sont les plus susceptibles de fournir des identifiants exacts. L'auto-inscription aide aussi, car les clients savent comment écrire leurs propres données personnelles. L'autocomplétion mobile réduit l'effort de saisie et les fautes de frappe courantes, surtout pour les noms, les e-mails et les numéros de téléphone.

Le même moment peut générer des données de faible qualité lorsque le formulaire est trop long ou peu clair. L'abandon augmente, et les entrées de type espace réservé deviennent plus courantes.

### Ce qui améliore la qualité des données

Le levier le plus puissant consiste à collecter moins de données, mais à mieux les valider. Les champs obligatoires doivent être limités aux véritables identifiants nécessaires à la création du profil et à l'émission de la carte. Les champs facultatifs doivent rester facultatifs, l'enrichissement intervenant plus tard via l'engagement.

La validation doit être stricte et cohérente sur tous les canaux. C'est là que commencent la plupart des doublons. Pour plus d'informations sur les règles prises en charge comme `obligatoire`, `minLength`, `maxLength`, `email`, et `téléphone`, voir [Règles de validation](/guides-enrolment/fr/inscription/enrolment-form/validation-rules).

Les modèles d'identification améliorent également la qualité des données. La connexion sociale réduit la saisie et tend à réduire les doublons. L'enregistrement par e-mail aide à détecter plus tôt les clients existants et évite de recréer des profils pour les clients connus.

## Confidentialité, conformité RGPD et CCPA

Les formulaires d'inscription collectent des données personnelles. Ils doivent être traités comme des surfaces d'identité de niveau production, avec la même rigueur que tout autre point d'entrée d'identité.

The Wallet Crew est déployé dans le monde entier. Les exigences régionales varient selon le marché, le secteur et le cas d'usage. La plateforme prend en charge une capture structurée du consentement conçue pour s'aligner sur le RGPD (Union européenne), le CCPA (Californie) et des cadres régionaux de confidentialité similaires. La [Confidentialité et sécurité](https://docs.thewalletcrew.io/policies/privacy-and-security) section regroupe les politiques pertinentes. Le [modèle d'Accord de traitement des données](https://docs.thewalletcrew.io/policies/privacy-and-security/data-processing-agreement-model) fournit la référence formelle du cadre de confidentialité. Pour les questions opérationnelles courantes, voir la [FAQ sur la protection des données](https://docs.thewalletcrew.io/policies/privacy-and-security/data-protection-faq). The Wallet Crew propose également un service de DPO pour aider les marques à opérationnaliser les exigences de confidentialité et à maintenir des pratiques de consentement cohérentes entre les régions.

### L'auto-inscription renforce la conformité

L'auto-inscription renforce la transparence parce que les clients voient exactement quelles données sont collectées et pourquoi. Le texte du consentement est lu directement et dans son contexte. Les informations peuvent être fournies en privé, ce qui est particulièrement important en magasin, où des informations personnelles seraient autrement partagées à voix haute.

L'auto-inscription améliore également la qualité des données. L'autocomplétion mobile réduit l'effort de saisie et les fautes de frappe. Les clients saisissent généralement les données personnelles plus précisément que la collecte assistée par un employé, en particulier pour les noms, les e-mails et les numéros de téléphone.

Cela réduit l'ambiguïté, renforce la résolution d'identité et améliore la défendabilité lors des audits, tout en gardant l'expérience d'inscription rapide sur mobile.

### Consentement explicite et non ambigu

Le consentement marketing doit rester séparé de l'identification. Le texte du consentement doit être clair, lisible sur mobile et collecté sous forme d'opt-in explicite. Les cases pré-cochées doivent être évitées. Un lien visible vers la politique de confidentialité de la marque doit se trouver à côté du champ de consentement.

Pour les notifications Wallet et les modèles de consentement, alignez le formulaire d'inscription sur la politique de confidentialité de la marque et sur les exigences régionales de consentement.

Pour mettre à jour vous-même le libellé du consentement, voir [Localiser le texte du formulaire et le libellé du consentement](/configure/fr/advanced-configuration/enrolment-form#localize-form-text-and-consent-wording) dans la référence de configuration du formulaire d'inscription.

### Collecter moins, mais mieux collecter

La minimisation des données améliore à la fois la conformité et la performance. Un petit ensemble d'identifiants de haute qualité, validés strictement au moment de la capture, est plus facile à justifier juridiquement et plus facile à utiliser opérationnellement. Pour obtenir des conseils pratiques sur l'amélioration de la qualité de la capture, voir [Qualité des données](#data-quality).

## Pourquoi l'inscription compte

L'inscription n'est pas seulement une étape avant l'émission de la carte. C'est là que l'identité, le consentement, l'attribution et le contexte du magasin peuvent être capturés alors que l'intention est forte.

L'optimisation de ce moment améliore généralement la conversion vers Wallet, réduit les doublons et renforce la posture de conformité.

## FAQ

<details>

<summary><strong>Un formulaire d'inscription est-il la même chose qu'un formulaire d'enregistrement ?</strong></summary>

Oui, en pratique.

Dans la documentation The Wallet Crew, les deux termes sont utilisés. « Formulaire d'inscription » est le terme le plus large. Il couvre l'enregistrement, l'identification, la mise à jour du profil et l'émission de la carte en un seul parcours.

</details>

<details>

<summary><strong>Un seul formulaire peut-il fonctionner à la fois pour les nouveaux clients et les clients existants ?</strong></summary>

Oui.

La connexion sociale ou l'enregistrement par e-mail peut identifier les clients existants tôt. Le formulaire peut alors ignorer les champs déjà connus et se concentrer sur l'étape d'installation de la carte.

</details>

<details>

<summary><strong>Quel est le meilleur canal pour l'inscription : code QR, e-mail, site web ou application ?</strong></summary>

Choisissez en fonction de l'endroit où se trouvent déjà les clients.

Les codes QR fonctionnent le mieux lorsque le moment se produit en magasin. L'e-mail fonctionne le mieux lorsqu'une adresse existe déjà. Un site web ou une application mobile fonctionnent le mieux lorsque le client est déjà connecté et que l'identité peut être résolue sans étapes supplémentaires.

</details>

<details>

<summary><strong>Faut-il rendre tous les champs obligatoires pour garder des données propres ?</strong></summary>

Non.

Trop de champs obligatoires augmentent l'abandon et produisent souvent de fausses données. Seuls les véritables identifiants doivent être obligatoires. Ils doivent être validés strictement. Le reste peut être collecté plus tard.

</details>

<details>

<summary><strong>Avons-nous besoin de la connexion sociale si nous utilisons déjà l'e-mail ?</strong></summary>

Pas toujours, mais cela aide souvent.

La connexion sociale réduit la saisie et les fautes de frappe dans les e-mails sur mobile. Elle peut également améliorer la correspondance lorsque l'e-mail est utilisé comme clé primaire. Un repli par e-mail est généralement conservé pour les clients qui ne veulent pas utiliser un fournisseur.

</details>

<details>

<summary><strong>L'identification remplace-t-elle le consentement marketing ?</strong></summary>

Non.

L'identification prouve qui est le client. Le consentement marketing donne l'autorisation d'envoyer des messages marketing. Les garder séparés améliore la conformité et évite toute ambiguïté lors des audits.

</details>


# Connexion sociale

Permettez aux utilisateurs de s’authentifier sur les formulaires d’inscription avec Apple, Google, LINE ou Facebook. Utilisez l’e-mail vérifié par le fournisseur pour créer ou récupérer un profil client.

Connexion sociale (aussi appelée **connexion sociale**) permet aux utilisateurs de s'authentifier sur les formulaires d'inscription. Elle prend en charge **Connexion avec Apple**, **Google Sign-In**, **LINE Login**, et **Facebook Login**.

Elle fonctionne bien pour les parcours mobiles sur **iOS et Android**. Elle identifie les clients tôt dans le parcours. Elle évite la création de mots de passe. Elle réduit les doublons causés par des e-mails mal saisis.

<figure><img src="/files/c8519a9de3cef41f5c01cb27c8b173f9bdbb393f" alt="Enrolment form screen showing social sign-in buttons above the form fields"><figcaption><p>Placez les boutons des fournisseurs au-dessus des champs du formulaire pour encourager la connexion en un tap.</p></figcaption></figure>

{% hint style="info" %}
Cette page couvre **le fonctionnement de la connexion sociale** dans The Wallet Crew (UX, correspondance, attentes en matière de données).

Elle ne **pas** couvre pas la configuration de la console du fournisseur. Utilisez ces guides de configuration :

* [Configuration de la connexion Apple](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/apple-sign-in)
* [Configuration de la connexion Google](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/google-sign-in)
* [Configuration de la connexion LINE](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/line-sign-in)
* [Configuration de la connexion Facebook](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/facebook-sign-in)
  {% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* **Inscription par QR en magasin :** Les clients scannent un QR et s'inscrivent en un tap.
* **Inscription d'un membre déjà inscrit :** Faites correspondre le profil et ignorez les champs déjà connus.

</details>

### Ce que cela fait

La connexion sociale ajoute une **étape d'identité fournie par le fournisseur** à un formulaire d'inscription. The Wallet Crew l'utilise pour **résoudre l'identité d'un client tôt**. Ce contexte client change le comportement du formulaire.

L'utilisateur appuie sur un bouton de fournisseur. Le fournisseur authentifie l'utilisateur. Il renvoie une charge utile d'identité. The Wallet Crew en extrait les attributs exploitables. The Wallet Crew applique ensuite vos règles de correspondance.

Un seul formulaire peut prendre en charge les nouveaux utilisateurs et les utilisateurs déjà inscrits. Si une correspondance est trouvée, The Wallet Crew charge le profil. L'utilisateur continue comme client connu. Si aucune correspondance n'est trouvée, l'utilisateur continue comme nouveau. Un profil est créé lors de l'envoi.

Un seul formulaire peut prendre en charge plusieurs connexions sociales en même temps (Apple, Google, Line, Facebook)

### Ce que cette page ne couvre pas

La configuration du fournisseur est volontairement exclue de cette page.

Cette page **pas** inclut :

* des captures d'écran des consoles Apple/Google/LINE/Facebook et une configuration pas à pas
* des IDs client, des IDs de service, des clés, des secrets, des URL de redirection ou des listes d'autorisation de domaines
* le dépannage des erreurs spécifiques au fournisseur (`origin_mismatch`, configuration de l'e-mail de relais Apple, etc.)

Utilisez pour cela les guides de configuration du fournisseur liés ci-dessus.

### Avantages

* Inscription plus rapide avec moins de champs saisis.
* Correspondance plus fiable grâce à l'e-mail vérifié par le fournisseur.
* Moins de doublons causés par des fautes de frappe dans les e-mails.
* De meilleurs taux de complétion sur mobile et dans les parcours QR (moins de friction).
* Un seul parcours d'inscription pour les nouveaux utilisateurs et les utilisateurs déjà inscrits.

#### Schémas UX (inscription rapide, faible friction)

La connexion sociale fonctionne mieux lorsque le formulaire est conçu autour d'elle. Placez les boutons des fournisseurs **au-dessus** des champs du formulaire. Faites-en le chemin d'entrée par défaut sur mobile.

Après la connexion, masquez le champ e-mail. Ou rendez-le en lecture seule. Gardez une solution de repli comme « Continuer avec l'e-mail ». Ignorez les champs que vous avez déjà pour les utilisateurs correspondants. Gardez le parcours du nouvel utilisateur court et ciblé.

{% hint style="warning" %}
« Masquer mon e-mail » d'Apple peut renvoyer un e-mail de relais. Évitez des formulations comme « nous avons trouvé votre e-mail personnel ». Les noms peuvent être absents. Ne bloquez pas l'envoi en l'absence du prénom/nom.
{% endhint %}

#### Vitesse et efficacité de l'inscription (quoi optimiser)

Optimisez pour un parcours qui se termine en quelques secondes. Supposez que l'utilisateur est dans une file d'attente. Ne demandez que ce dont vous avez vraiment besoin à l'inscription.

Privilégiez le profilage progressif après l'inscription. Utilisez la connexion sociale pour capturer la clé de correspondance. Gardez les consentements explicites mais courts. Éloignez les longs textes juridiques du chemin critique. Rendez les erreurs spécifiques et exploitables.

Pour les parcours QR en magasin, supposez une mauvaise connectivité. Évitez les allers-retours réseau supplémentaires. N'ajoutez que les vérifications qui réduisent une fraude réelle.

#### Considérations de sécurité

La connexion sociale est un fort **signal d'identité**. Ce n'est pas une sécurité de compte complète. Traitez-la comme la preuve que l'utilisateur contrôle un compte fournisseur.

Vous bénéficiez des contrôles du fournisseur comme la confiance de l'appareil et la MFA. Vous obtenez généralement un e-mail vérifié. Vous avez toujours besoin d'une règle pour **la propriété du compte** dans votre CRM. Vous n'obtenez pas non plus de liaison automatique entre fournisseurs.

### Activation

Vous activez la connexion sociale à deux endroits :

1. Configurez le fournisseur (Apple / Google / LINE / Facebook).
2. Activez le bouton du fournisseur sur le formulaire d'inscription.

La configuration du fournisseur est une configuration unique par fournisseur. Utilisez ces guides :

<table data-card-size="large" data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-target data-type="content-ref">Guide de configuration</th><th data-hidden data-card-cover data-type="image">Aperçu</th></tr></thead><tbody><tr><td align="center"><strong>Google</strong></td><td><a href="/spaces/TnKXdNj1C0405YbXHuEc/pages/38f3021c1dc3aeaa7bdc538d1a551773c2910cb6">/spaces/TnKXdNj1C0405YbXHuEc/pages/38f3021c1dc3aeaa7bdc538d1a551773c2910cb6</a></td><td><a href="/files/f67b257d39d3db34fcc0bc2c0606145bb58d65e8">/files/f67b257d39d3db34fcc0bc2c0606145bb58d65e8</a></td></tr><tr><td align="center"><strong>Apple</strong></td><td><a href="/spaces/TnKXdNj1C0405YbXHuEc/pages/9bf3ea8f025335d58853d2e2f726dca227354fa6">/spaces/TnKXdNj1C0405YbXHuEc/pages/9bf3ea8f025335d58853d2e2f726dca227354fa6</a></td><td><a href="/files/fe1e415d2b108e5a90200224ec90c9c597d519a2">/files/fe1e415d2b108e5a90200224ec90c9c597d519a2</a></td></tr><tr><td align="center"><strong>LINE</strong></td><td><a href="/spaces/TnKXdNj1C0405YbXHuEc/pages/795be5ea5321bb463fbfce71c86e82c1001066d4">/spaces/TnKXdNj1C0405YbXHuEc/pages/795be5ea5321bb463fbfce71c86e82c1001066d4</a></td><td><a href="/files/0d9ff474d584b21d1f31ebb366b31c179733b536">/files/0d9ff474d584b21d1f31ebb366b31c179733b536</a></td></tr><tr><td align="center"><strong>Facebook</strong></td><td><a href="/spaces/TnKXdNj1C0405YbXHuEc/pages/7b56efcd06e809bb65df88e7d43a23cefcad26c1">/spaces/TnKXdNj1C0405YbXHuEc/pages/7b56efcd06e809bb65df88e7d43a23cefcad26c1</a></td><td><a href="/files/7ee1cd52ee8b9d3b04489124cbe2a46f7b181cf8">/files/7ee1cd52ee8b9d3b04489124cbe2a46f7b181cf8</a></td></tr></tbody></table>

Une fois le fournisseur configuré, activez-le sur le formulaire d'inscription souhaité. Voir [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form) pour les paramètres du formulaire.

#### Considérations géographiques et de marché (quels fournisseurs proposer)

Le choix du fournisseur est souvent régional. Proposez les boutons que vos clients utilisent déjà.

Se connecter avec Apple est un choix par défaut solide sur les marchés dominés par iOS. Google Sign-In est un choix par défaut solide sur les marchés dominés par Android. Google peut être restreint là où ses services sont limités. LINE Login est particulièrement pertinent au Japon, à Taïwan et en Thaïlande.

Si vous opérez dans plusieurs pays, restez simple. Utilisez **des formulaires d'inscription distincts par région**. N'activez que les fournisseurs pertinents sur chaque formulaire. Cela évite de dérouter les utilisateurs avec des boutons inutilisés.

#### Les données que vous obtenez

Vous pouvez vous attendre à **e-mail** de chaque fournisseur. Le prénom et le nom dépendent du fournisseur. Considérez les noms comme facultatifs.

Concevez vos règles de correspondance comme si vous ne receviez que l'e-mail au fil du temps. Apple ne peut renvoyer les noms qu'une seule fois. Apple peut aussi renvoyer des e-mails de relais. Voir [Configuration de la connexion Apple](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/apple-sign-in) pour ces comportements.

{% hint style="info" %}
Facebook ne renvoie pas toujours un e-mail. Certains comptes n'ont pas d'e-mail exploitable, et certaines configurations ne le demandent pas. Gardez une solution de repli comme « Continuer avec l'e-mail ».
{% endhint %}

### FAQ

<details>

<summary><strong>Le même utilisateur peut-il se connecter avec différents fournisseurs ?</strong></summary>

Oui, mais le résultat dépend de ce que vous utilisez comme clé de correspondance. La plupart des configurations se basent sur l'e-mail.

Si Apple et Google renvoient le **même e-mail**, ils aboutissent au même profil. S'ils renvoient des e-mails différents, vous pouvez créer des doublons. Cela arrive souvent avec les e-mails de relais Apple, les e-mails professionnels contre personnels, ou des utilisateurs qui modifient les paramètres du fournisseur.

Évitez les doublons en liant les identités dans votre CRM. Stockez l'identifiant du fournisseur (par exemple, le sujet du fournisseur) associé au client lorsque vous le pouvez. Utilisez un deuxième identifiant pour la correspondance lorsque l'e-mail n'est pas stable. Les choix courants sont l'ID de fidélité, le téléphone ou un code à usage unique.

</details>

<details>

<summary><strong>Avons-nous toujours besoin de la vérification de l'e-mail ?</strong></summary>

En général non, car le fournisseur vérifie l'e-mail.

Conservez la vérification de l'e-mail lorsque vous avez besoin d'une étape d'assurance supplémentaire. Les cas courants sont les comptes à forte valeur et les programmes réglementés. Un autre schéma courant est la vérification renforcée uniquement lorsque le risque est élevé. Exemple : connexion sociale pour l'inscription, puis vérification OTP avant les modifications du compte ou l'utilisation des récompenses.

</details>

<details>

<summary><strong>Comment devons-nous gérer « Masquer mon e-mail » d'Apple ?</strong></summary>

Traitez les e-mails de relais Apple comme des e-mails valides. Ils peuvent toujours recevoir des messages. Ne supposez pas qu'ils correspondent à l'e-mail de votre CRM.

Si vous avez déjà des clients dans un autre système, évitez la correspondance « e-mail uniquement » pour les audiences très Apple. Ajoutez un deuxième identifiant dans le parcours. Utilisez un numéro d'adhérent, un numéro de téléphone ou un code à usage unique. Vous pouvez aussi laisser l'utilisateur confirmer un identifiant connu après la connexion avant de charger un profil existant.

</details>

<details>

<summary><strong>Que se passe-t-il si l'utilisateur annule la connexion sociale ou si le fournisseur échoue ?</strong></summary>

L'utilisateur reste non authentifié. Le formulaire doit revenir à votre parcours d'entrée alternatif. Une solution de repli courante est « Continuer avec l'e-mail ».

Gardez le message d'erreur spécifique. Utilisez un libellé comme « La connexion a été annulée » ou « La connexion a échoué ». Évitez les messages ambigus comme « Une erreur s'est produite ». Si vous constatez des échecs fréquents, vérifiez les paramètres des cookies tiers, les bloqueurs de fenêtres contextuelles et les origines de redirection autorisées configurées chez le fournisseur.

</details>

<details>

<summary><strong>Pouvons-nous limiter les fournisseurs affichés (par pays ou par appareil) ?</strong></summary>

Oui. Gardez le jeu de boutons minimal pour chaque audience. Proposez les fournisseurs que vos utilisateurs utilisent déjà sur ce marché.

Si vous opérez dans plusieurs pays, utilisez des formulaires d'inscription distincts par région. N'activez que les fournisseurs pertinents sur chaque formulaire. Si vous voulez une UX spécifique à l'appareil, mettez Apple en avant sur iOS et Google en avant sur Android, tout en proposant un parcours de repli pour les utilisateurs qui ne veulent pas utiliser la connexion sociale.

</details>


# Configuration de la connexion Google

Configurez Google Sign-In (ID client OAuth 2.0) et connectez-le à la connexion sociale de The Wallet Crew.

Utilisez ceci lorsque vous souhaitez activer le **Google** bouton dans un formulaire d’inscription.

Commencez par [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) pour comprendre le parcours utilisateur. Puis revenez ici pour la configuration du fournisseur.

<div data-with-frame="true"><figure><img src="/files/f67b257d39d3db34fcc0bc2c0606145bb58d65e8" alt="Google-Social-Sign-In-Example" width="375"><figcaption><p>Connectez-vous avec Google dans un exemple de formulaire d'inscription</p></figcaption></figure></div>

### Vue d’ensemble

#### Ce que vous allez configurer

* Un **ID client OAuth 2.0 Google**.
* **Origines JavaScript autorisées** pour les domaines de votre formulaire d'inscription.
* L'ID client stocké dans **L’équipe Wallet** la console d'administration.

#### Prérequis

* Accès au compte de votre marque. **Console Google Cloud** projet.
* Autorisation de créer **des ID client OAuth 2.0**.
* La liste des domaines sur lesquels vos formulaires d’inscription seront déployés (prod + staging + dev + personnalisés).

### Configurer Se connecter avec Google

{% stepper %}
{% step %}

#### **Ouvrir les identifiants**

Ouvrez la Console Google Cloud **Identifiants** page :

<p align="center"><a href="https://console.developers.google.com/apis/credentials" class="button secondary" data-icon="chevrons-right">Page des identifiants Google</a></p>
{% endstep %}

{% step %}

#### **Créez un client OAuth pour application Web**

1. Cliquez `Créer des identifiants` → `ID client OAuth`.
2. Choisissez le type d'application : `Application Web`.
3. Donnez un nom. Exemple : `connexion neostore`.
   {% endstep %}

{% step %}

#### **Configurer les origines**

Ajoutez **Origines JavaScript autorisées** pour chaque domaine que vous utiliserez.

* `https://app.neostore.cloud`
* `https://app-qa.neostore.cloud`
* `https://app-dev.neostore.cloud`
* Tout **domaine personnalisé** que vous utilisez pour les formulaires d'inscription (ajoutez l'origine exacte).

Laissez **URI de redirection autorisés** vide.

![Paramètres du client OAuth Google](/files/2d92613d9c76e7a900a256dde973eda2f4be599b)

![Paramètres de connexion sociale Google de Wallet Crew](/files/12888ad871d2c4acd86ca0860b3dc69fe7ec6ce3)
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Google Sign-In pour le web utilise le **ID client**. Vous pouvez le coller sans risque dans la console d'administration.

Ne partagez aucun Google **secret client**. Vous ne devriez pas en avoir besoin pour ce flux.
{% endhint %}

### Configurez Google dans Wallet Crew

1. Ouvrez **Connexions sociales → Google** dans la console d'administration.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/social/google" class="button secondary" data-icon="chevrons-right">Connexions sociales -> Google</a></p>

<div data-with-frame="true"><figure><img src="/files/e5c36830ba6ad0759fcf751b20e51706b578dc25" alt="The Wallet Crew - Google Social Sign In configuration" width="563"><figcaption><p>Configuration de connexion sociale Google de Wallet Crew</p></figcaption></figure></div>

2. Collez l’ **ID client** depuis Google.
3. Enregistrez.

### Activez Google sur votre formulaire d'inscription

Activez le fournisseur dans les paramètres du formulaire d’inscription.

Allez dans `configuration avancée -> Layout` Ouvrez la mise en page sur laquelle vous souhaitez activer la connexion sociale et ajoutez ces lignes

```yaml
signinOptions:
  providers:
    - type: android
      displayProps:
        isMobile: true
        isAndroid: true
```

Pour plus d’informations, voir [Formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form).

### FAQ

<details>

<summary><strong>Avons-nous besoin d'un secret client Google ?</strong></summary>

Non. Cette configuration utilise le **ID client Google** uniquement.

Si vous voyez un secret client dans la Console Google Cloud, ne le collez nulle part dans Wallet Crew.

</details>

<details>

<summary><strong>Faut-il configurer « URI de redirection autorisés » dans Google ?</strong></summary>

Non. Laissez **URI de redirection autorisés** vide pour ce flux.

Si vous ajoutez des URI de redirection, cela n’aide généralement pas. Cela peut aussi compliquer le débogage plus tard.

</details>

<details>

<summary><strong>Que faut-il exactement ajouter en tant qu’« origine JavaScript autorisée » ?</strong></summary>

Ajoutez l’ **origine uniquement**: `scheme://host` (et le port si vous en utilisez un).

Exemples :

* ✅ `https://app.neostore.cloud`
* ✅ `https://brand.example.com`
* ❌ `https://app.neostore.cloud/molia/mobile` (les chemins ne sont pas autorisés)

</details>

<details>

<summary><strong>Nous utilisons un domaine personnalisé. Que devons-nous faire ?</strong></summary>

Ajoutez votre domaine personnalisé en tant qu’ **origine JavaScript autorisée** dans la Console Google Cloud.

Utilisez le domaine exact que les utilisateurs voient dans le navigateur. Exemple : `https://wallet.brand.com`.

</details>

<details>

<summary><strong>Pourquoi répertorions-nous les origines de prod, QA et dev ?</strong></summary>

Google valide l'origine au moment de l'exécution.

Si un utilisateur accède à QA mais que seule la prod est configurée, Google rejette la connexion.

</details>

<details>

<summary><strong>Où activons-nous le bouton Google dans le parcours utilisateur ?</strong></summary>

La configuration du fournisseur ne suffit pas. Vous devez également activer Google sur le formulaire d'inscription.

Voir [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) et [Formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form).

</details>


# Configuration de la connexion Apple

Configurez Sign in with Apple et connectez-la à la connexion sociale de The Wallet Crew.

Utilisez ceci lorsque vous souhaitez activer le **Apple** bouton dans un formulaire d’inscription.

Commencez par [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) pour comprendre le parcours utilisateur. Puis revenez ici pour la configuration du fournisseur.

<figure><img src="/files/fe1e415d2b108e5a90200224ec90c9c597d519a2" alt="Apple-Social-Sign-In-Example" width="375"><figcaption><p>Exemple de connexion avec Apple dans un formulaire d’inscription</p></figcaption></figure>

### Vue d’ensemble

Utilisez cette page pour configurer **Connexion avec Apple** (connexion avec Apple ID) pour **L’équipe Wallet** les formulaires d’inscription.

Vous configurerez Apple à deux endroits :

1. **Apple Developer**: App ID + Service ID + domaines + URL de retour.
2. **l’administration de Wallet**: collez votre Apple **Service ID**.

#### Terminologie (Apple)

Ces termes sont utilisés dans Apple Developer et dans les configurations OAuth.

* **App ID**: identifie votre application. Utilise un **Bundle ID** comme `com.brand.app`.
* **Service ID**: identifie une intégration de connexion web. C’est ce que vous collez dans l’administration de Wallet.
* **Domaines et sous-domaines**: où le formulaire d’inscription est hébergé.
* **URL de retour**: URL de rappel OAuth / OpenID Connect utilisées après la connexion Apple.

#### Prérequis

* Accès au compte de votre marque. **Apple Developer** compte.
* Autorisation de gérer **les identifiants** et **les Service IDs**.
* La liste des domaines sur lesquels vos formulaires d’inscription seront déployés (prod + staging + dev + personnalisés).

#### Remarques sur le comportement d’Apple

La connexion avec Apple présente quelques comportements qui ont un impact sur votre parcours d’inscription et vos règles de correspondance.

Lors de **la première connexion** avec un compte Apple donné, Apple peut fournir **le prénom**, **le nom**, et **l’e-mail**. Lors **des connexions suivantes**, Apple renvoie généralement **uniquement l’e-mail**. Concevez vos formulaires comme si vous ne disposiez à long terme que de l’e-mail.

{% hint style="warning" %}
Les utilisateurs Apple peuvent activer **Hide My Email**. Dans ce cas, Apple renvoie une adresse relais au lieu de l’e-mail réel de l’utilisateur.

Cet e-mail relais peut créer des doublons si votre CRM attend un autre identifiant. Si vous envoyez des e-mails aux clients, vous devrez peut-être aussi prendre en charge la livraison aux adresses relais Apple.
{% endhint %}

Référence Apple : [Communiquer à l’aide du service de relais de messagerie privée](https://developer.apple.com/documentation/signinwithapple/communicating-using-the-private-email-relay-service/).

### Configurer la connexion avec Apple

{% stepper %}
{% step %}

#### **Ouvrez Identifiants**

1. Connectez-vous au compte Apple Developer.

<p align="center"><a href="https://developer.apple.com/account" class="button secondary" data-icon="chevrons-right">Compte développeur</a></p>

2. Accédez à `Certificats, identifiants et profils` → `les identifiants`.
   {% endstep %}

{% step %}

#### **Créer (ou réutiliser) un App ID**

1. Cliquez `+` et sélectionnez `App IDs`.

![Cliquez sur +](/files/045ebb2c6c09204b0735528fa1b04e52cdfe4534) ![Sélectionnez App ID](/files/c9bfb84a86450329f1bd51df006a9543c47b6b02)

> Si vous avez déjà un App ID pour le même domaine ou la même application, vous pouvez peut-être le réutiliser. Cela peut débloquer des scénarios avancés. En cas de doute, demandez à l’équipe Wallet.

2. Sélectionnez le `App` type.
3. Remplissez le formulaire avec :
   1. **Description**: un nom explicite pour votre projet
   2. **Bundle ID**: utilisez la valeur fournie par l’équipe Wallet (exemple : `cloud.neostore.molia.app`)
   3. **Fonctionnalités**: activez `Connexion avec Apple`

<div><figure><img src="/files/54bc06024230848f7242ec795db1c66f17f19454" alt="Description and Bundle ID" width="520"><figcaption></figcaption></figure> <figure><img src="/files/a74e1379a1f201c2d01881a02f95b5369532cb6d" alt="Capabilities" width="563"><figcaption></figcaption></figure></div>

4. Validez le formulaire et cliquez sur `Enregistrer`.

<figure><img src="/files/249e5d82b0d5ab84d74768805b98283a4dee00fa" alt="Create (or reuse) an App ID"><figcaption></figcaption></figure>
{% endstep %}

{% step %}

#### **Créer (ou réutiliser) un Service ID**

Vous avez besoin d’un **Service ID** pour la connexion avec Apple sur le web.

1. Dans la liste des identifiants, changez le filtre sur `les Service IDs`.
2. Cliquez `+` et sélectionnez `les Service IDs`.

<div><figure><img src="/files/045ebb2c6c09204b0735528fa1b04e52cdfe4534" alt="Click on +" width="420"><figcaption><p>Cliquez sur +</p></figcaption></figure> <figure><img src="/files/5332f1ba534dff0e78aa6e1f87005c3d4df90b37" alt="Service ID" width="563"><figcaption><p>Service ID</p></figcaption></figure></div>

3. Remplissez le formulaire avec :
   1. **Description**: un nom explicite pour votre service
   2. **Identifiant**: utilisez la valeur fournie par l’équipe Wallet (exemple : `cloud.neostore.molia.service`)

<figure><img src="/files/750505b3a397f5496d8fa39b64acda6eeefc16ae" alt="Identifier"><figcaption></figcaption></figure>

4. Validez le formulaire et cliquez sur `Enregistrer`.

{% hint style="info" %}
L’ **identifiant Service ID** est la valeur que vous collerez dans l’administration de Wallet.
{% endhint %}
{% endstep %}

{% step %}

#### **Configurer la connexion avec Apple (domaines + URL de retour)**

1. Dans la liste des identifiants, sélectionnez le Service ID que vous venez de créer.
2. Activer `Connexion avec Apple` et cliquez sur `Configurer`.

<figure><img src="/files/1c2d2f462c484059e9b7d3ed8f43d2aaa1acf4c7" alt="Configure Sign in with Apple (domains + return URLs)"><figcaption></figcaption></figure>

3. Remplissez le formulaire avec :
   1. **App ID principal**: l’App ID que vous avez créé précédemment (exemple : `cloud.neostore.molia.app`)
   2. **Domaines et sous-domaines**: ajoutez tous les domaines qui hébergeront vos formulaires d’inscription (prod + staging + dev + personnalisés)
   3. **URL de retour**: ajoutez les URL de rappel OAuth pour chaque environnement

<figure><img src="/files/6b9afc06f87a31b47082d5a0508203c155d376c7" alt="Return URLs"><figcaption></figcaption></figure>

4. Validez le formulaire et cliquez sur **Continuer**.

{% hint style="warning" %}
Apple est très strict ici. Utilisez les valeurs exactes.

Si vous n’êtes pas sûr du format de l’URL de rappel, demandez à l’équipe Wallet.
{% endhint %}
{% endstep %}

{% step %}

#### Configurer les domaines de communication par e-mail

Cette étape est requise si votre application envoie des e-mails aux utilisateurs qui ont choisi **Hide My Email** lors de la connexion avec Apple.

Apple génère une adresse relais comme :

> <randomstring@privaterelay.appleid.com>

Vous devez enregistrer votre domaine d’envoi, sinon Apple rejettera ces e-mails. Traitez les adresses relais comme des adresses e-mail normales dans votre backend.

{% hint style="info" %}
Cette étape est requise si vous envoyez des e-mails aux utilisateurs qui ont choisi **Hide My Email**.

Apple renvoie une **adresse e-mail relais**. Traitez-la comme une vraie boîte aux lettres.
{% endhint %}

**Ouvrez la section Services**

* Dans **Certificats, identifiants et profils**, cliquez sur **Services** dans le menu de gauche.
* Cliquez **Connexion avec Apple pour la communication par e-mail**.
* Cliquez **Configurer**.

<figure><img src="/files/d7ebfcd25fc79db544405021c66de34d1a94eed4" alt="Configure"><figcaption></figcaption></figure>

* Sous **Sources d’e-mail**, cliquez sur le **+** bouton pour ajouter une nouvelle source d’e-mail.

<figure><img src="/files/09ceeefe98a14aa0a1bf9cedf528357e0168dc9f" alt="Email Sources"><figcaption></figcaption></figure>

**Remplissez le formulaire avec :**

* **Domaines et sous-domaines** :\
  Ajoutez le ou les domaines depuis lesquels vous envoyez des e-mails.\
  Exemple :

  ```
  myapp.com
  mail.myapp.com
  ```
* **Adresses e-mail** :\
  Ajoutez la ou les adresses e-mail d’envoi utilisées par votre application.\
  Exemple :

```
noreply@myapp.com
support@myapp.com
```

<figure><img src="/files/f85e422c591aafda4853e8a892d11b529179bcfa" alt="Fill the form with"><figcaption></figcaption></figure>

* Cliquez **Suivant** et terminez la validation (vérification SPF/DKIM si nécessaire).
  {% endstep %}
  {% endstepper %}

### Configurer Apple dans Wallet

1. Dans la console d’administration de Wallet, ouvrez :

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/social/apple" class="button secondary" data-icon="chevrons-right">Connexion sociale → Apple</a></p>

<div data-with-frame="true"><figure><img src="/files/0f34f55ed00b0d4019cafcbaa95d26c49f92ab3a" alt="The Wallet Crew - Apple Social Sign In configuration" width="563"><figcaption><p>Configuration de la connexion sociale Apple de Wallet</p></figcaption></figure></div>

2. Remplissez le **Service ID** avec l’identifiant utilisé lors de la création du Service ID (exemple : `cloud.neostore.molia.service`).
3. Enregistrez.

{% hint style="info" %}
Collez l’ **Service ID** identifiant.

Ne collez pas le nom de l’App ID ni le Bundle ID.
{% endhint %}

### Activez Apple sur votre formulaire d’inscription

Activez le fournisseur dans les paramètres du formulaire d’inscription.

Allez dans `configuration avancée -> Layout`. Ouvrez la mise en page pour activer la connexion sociale et ajoutez ces lignes :

```yaml
signinOptions:
  providers:
    - type: apple
      displayProps:
        isMobile: true
        isIOS: true
```

Pour plus d’informations, voir [Formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form).

### FAQ

<details>

<summary>Quels domaines dois-je ajouter dans Apple Developer ?</summary>

Ajoutez tous les domaines pouvant héberger le formulaire d’inscription.

Incluez prod, staging, dev et tout domaine personnalisé.

</details>

<details>

<summary>Que dois-je mettre dans « Return URLs » ?</summary>

Ajoutez l’URL de rappel pour chaque environnement et chaque domaine de formulaire.

Conservez-les exactement. Le schéma, le chemin et le slash final doivent correspondre.

</details>

<details>

<summary>Pourquoi n’obtiens-je l’e-mail de l’utilisateur qu’après la première connexion ?</summary>

Apple ne renvoie les champs de nom qu’au premier consentement.

Lors des connexions suivantes, Apple renvoie généralement uniquement l’e-mail.

</details>

<details>

<summary>Qu’est-ce que « Hide My Email » et qu’est-ce que cela change ?</summary>

Apple peut renvoyer une adresse e-mail relais au lieu de l’e-mail réel de l’utilisateur.

Cela peut créer des doublons si vous associez les utilisateurs uniquement par e-mail.

Référence Apple : [Communiquer à l’aide du service de relais de messagerie privée](https://developer.apple.com/documentation/signinwithapple/communicating-using-the-private-email-relay-service/){target="\_blank"}.

</details>

<details>

<summary>Quelle valeur dois-je coller dans l’administration de Wallet : Bundle ID, App ID ou Service ID ?</summary>

Collez l’ **Service ID**.

Exemple : `cloud.thewalletcrew.molia.service`.

</details>


# Configuration de la connexion LINE

Configurez LINE Login et connectez-le à la connexion sociale de The Wallet Crew.

Utilisez ceci lorsque vous souhaitez activer le **LINE** bouton dans un formulaire d'inscription.

Commencez par [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) pour comprendre le parcours utilisateur. Revenez ensuite ici pour la configuration du fournisseur.

<div data-with-frame="true"><figure><img src="/files/0d9ff474d584b21d1f31ebb366b31c179733b536" alt="Line-Social-Sign-In-Example" width="375"><figcaption><p>Connectez-vous avec LINE dans un exemple de formulaire d'inscription</p></figcaption></figure></div>

### Vue d'ensemble

#### Ce que vous allez configurer

* Un **Canal LINE** avec le produit LINE Login activé.
* **URI de redirection OAuth autorisées** et **domaines valides** pour votre formulaire d'inscription.
* L'App ID stocké dans **The Wallet Crew** la console d'administration.

#### Prérequis

* Accès à votre **Console LINE Developers**.
* Autorisation de créer et de gérer **des canaux**.
* La liste des domaines sur lesquels vos formulaires d'inscription s'exécuteront (prod + staging + dev + personnalisé).

### Créer le canal LINE

{% stepper %}
{% step %}

#### **Créer un fournisseur et un canal**

Allez dans la console LINE Developers

<p align="center"><a href="https://developers.line.biz/console" class="button secondary" data-icon="chevrons-right">Console développeur LINE</a></p>

1. Sélectionnez ou créez un **fournisseur**
2. Cliquez sur **Créer un nouveau canal**
   {% endstep %}

{% step %}

#### **Sélectionnez LINE Login**

![Sélectionnez LINE Login](/files/9ced4e17ab80a34744f9ced87fa802f32c3d97e3)

1. Choisissez **LINE Login**
2. Sélectionnez le type d'application : **Application web**
3. Renseignez les informations requises
4. Créez le canal
   {% endstep %}

{% step %}

#### **Activez l'autorisation d'e-mail (OpenID Connect)**

Ouvrez les paramètres de votre canal :

![Activez l'autorisation d'e-mail (OpenID Connect)](/files/03bf0ffb2a9d328dec2b9d54cdb79b8532b2325e)

1. Allez dans la **OpenID Connect** section
2. Activez **Autorisation d'adresse e-mail**

Cette étape est requise si votre parcours d'inscription dépend de l'e-mail.
{% endstep %}

{% step %}

#### **Configurer les URL de rappel**

Dans l' **LINE Login** onglet :

Ajoutez une URL de rappel pour chaque environnement :

```http
https://app.neostore.cloud/auth/callback/line
https://app-qa.neostore.cloud/auth/callback/line
https://app-dev.neostore.cloud/auth/callback/line
https://<your-custom-domain>/auth/callback/line
```

Important :

* L'URL complète doit correspondre exactement
* Inclure `/auth/callback/line`
* Ajoutez les domaines prod + QA + dev + personnalisés

Enregistrez vos modifications.
{% endstep %}

{% step %}

### Publiez votre canal

Dans le coin supérieur gauche, cliquez sur **Développement**.

<figure><img src="/files/0cfa8fef3ca9cb93fffbd6f39a31477a4600542c" alt=""><figcaption></figcaption></figure>

Puis cliquez sur **Publier** pour rendre le canal disponible en production.
{% endstep %}
{% endstepper %}

### Configurer LINE dans The Wallet Crew

Dans le backoffice de The Wallet Crew, ouvrez la page de configuration LINE.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/social/line" class="button secondary" data-icon="chevrons-right">Connexion sociale -> Line</a></p>

<div data-with-frame="true"><figure><img src="/files/34546918d8c0eac0029e0308005708f883146f90" alt="The Wallet Crew - Line configuration screen" width="563"><figcaption><p>Écran de configuration Line</p></figcaption></figure></div>

Copiez les valeurs de la console LINE Developers dans The Wallet Crew.

Après l'enregistrement, laissez cette page ouverte pour une vérification rapide :

* Le canal LINE doit être le même que celui utilisé pour les URL de rappel.
* La valeur enregistrée `clientId` doit correspondre au **ID du canal** exactement.

{% hint style="info" %}
Vous pouvez trouver ces valeurs dans :

Console LINE Developers → Votre canal → **Paramètres de base**
{% endhint %}

### Activez LINE sur votre formulaire d'inscription

Activez le fournisseur dans les paramètres du formulaire d'inscription.

Allez dans `configuration avancée -> Layout`. Ouvrez la mise en page pour activer la connexion sociale et ajoutez ces lignes :

<pre class="language-yaml"><code class="lang-yaml"><strong>signinOptions:
</strong>  providers:
    - type: line
</code></pre>

Pour plus d'informations, consultez [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form).

### FAQ

<details>

<summary>Quel type de canal LINE dois-je créer pour cette configuration ?</summary>

Créez un **LINE Login** canal de type application **Application web**.

C'est le type de canal qui prend en charge le flux de rappel OAuth utilisé par les formulaires d'inscription.

</details>

<details>

<summary>Dois-je activer « Autorisation d'adresse e-mail » dans OpenID Connect ?</summary>

Activez-la si votre parcours d'inscription nécessite un e-mail.

Sans elle, LINE peut ne pas renvoyer d'e-mail pour l'utilisateur.

</details>

<details>

<summary>Quelles URL de rappel dois-je ajouter ?</summary>

Ajoutez une URL de rappel par environnement.

L'URL doit correspondre exactement et doit inclure `/auth/callback/line`.

Utilisez les modèles indiqués ci-dessus pour la prod, la QA, le dev et tout domaine personnalisé.

</details>

<details>

<summary>Où puis-je trouver le LINE <code>clientId</code> ?</summary>

Dans la console LINE Developers :

**Votre canal → Paramètres de base**.

Copiez le **ID du canal** dans `authentication.clientId`.

</details>

<details>

<summary>Comment afficher concrètement le bouton LINE sur le formulaire d'inscription ?</summary>

Activez le fournisseur dans vos **paramètres du formulaire d'inscription**.

Si vous gérez les boutons via le YAML de mise en page, ajoutez `- type: line` sous `signinOptions.providers`.

</details>


# Configuration de la connexion Facebook

Configurez Facebook Login pour les formulaires d’inscription : créez une application Facebook, définissez les URI de redirection et les domaines autorisés, puis ajoutez l’ID de l’application dans la console d’administration de The Wallet Crew.

Utilisez ceci lorsque vous souhaitez activer le **Facebook** bouton dans un formulaire d’inscription.

Commencez par [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) pour comprendre le parcours utilisateur. Puis revenez ici pour la configuration du fournisseur.

<div data-with-frame="true"><figure><img src="/files/7ee1cd52ee8b9d3b04489124cbe2a46f7b181cf8" alt="FB-Social-Sign-In-Example" width="375"><figcaption><p>Connecter avec Facebook dans un exemple de formulaire d’inscription</p></figcaption></figure></div>

### Vue d’ensemble

#### Ce que vous allez configurer

* Un **Application Facebook** avec le produit Facebook Login activé.
* **URI de redirection OAuth autorisées** et **domaines valides** pour votre formulaire d'inscription.
* L'App ID stocké dans **L’équipe Wallet** la console d'administration.

#### Prérequis

* L’accès à votre marque **Meta for Developers** compte.
* L’autorisation de créer ou de gérer **Applications Facebook**.
* La liste des domaines sur lesquels vos formulaires d’inscription seront déployés (prod + staging + dev + personnalisés).

### Créez l’application Facebook

{% stepper %}
{% step %}

#### **Ouvrez le portail des développeurs Meta**

Accédez au tableau de bord des applications de Meta for Developers :

<p align="center"><a href="https://developers.facebook.com/apps" class="button secondary" data-icon="chevrons-right">Tableau de bord des applications Meta</a></p>
{% endstep %}

{% step %}

#### **Créer une nouvelle application**

1. Cliquez `Créer l’application`.
2. Sélectionnez le cas d’utilisation : `Authentifier et demander des données aux utilisateurs` (ou `Consommateur` selon la version de votre tableau de bord Meta).
3. Donnez un nom. Exemple : `connexion neostore`.
4. Terminez l’assistant de création de l’application et confirmez votre compte développeur si vous y êtes invité.
   {% endstep %}

{% step %}

#### **Ajoutez le produit Facebook Login**

1. Dans le tableau de bord de votre application, recherchez la **Ajouter un produit** section.
2. Cliquez `Configurer` sur **Facebook Login pour les entreprises** (ou **Facebook Login**).
3. Choisissez `Web` comme plateforme.
4. Saisissez l’URL de votre site Web (par ex. `https://app.neostore.cloud`) puis enregistrez.
   {% endstep %}

{% step %}

#### **Configurez les domaines autorisés et les URI de redirection**

Accédez à **Connexion Facebook → Paramètres** dans la barre latérale gauche et configurez les éléments suivants :

**URI de redirection OAuth valides** — ajoutez un URI par environnement :

* `https://app.neostore.cloud`
* `https://app-qa.neostore.cloud`
* `https://app-dev.neostore.cloud`
* Tout **domaine personnalisé** que vous utilisez pour les formulaires d'inscription (ajoutez l'origine exacte).

**Domaines autorisés pour le SDK JavaScript** — ajoutez la même liste d’origines (schéma + hôte uniquement, sans chemins).

Enregistrez vos modifications.

> **Remarque :** Contrairement à Google, Facebook exige que l’URI de redirection et la liste des domaines autorisés soient toutes deux renseignées.
> {% endstep %}

{% step %}

#### **Passez l’application en mode En ligne**

1. Dans la barre supérieure du tableau de bord de l’application, basculez l’application de **Développement** à **En ligne**.
2. Si on vous y invite, fournissez une **URL de la politique de confidentialité** — c’est exigé par Meta avant la mise en ligne.

> En mode Développement, seuls les utilisateurs répertoriés comme testeurs ou développeurs de l’application peuvent se connecter. Passez en mode En ligne afin que tous les utilisateurs puissent s’authentifier.
> {% endstep %}
> {% endstepper %}

> **Info :** La connexion Facebook pour le web utilise uniquement le **App ID**. Il est sûr de le coller dans la console d’administration.

### Ajoutez l’ID de l’application dans The Wallet Crew

1. Ouvrez **Connexions sociales → Facebook** dans la console d'administration.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/social/facebook" class="button secondary" data-icon="chevrons-right">Connexions sociales -> Facebook</a></p>

<div data-with-frame="true"><figure><img src="/files/e19c11f4f70799103dd46844a19edeac763ad1dc" alt="The Wallet Crew - Facebook Social Sign In configuration" width="563"><figcaption><p>Configuration de la connexion sociale Facebook de The Wallet Crew</p></figcaption></figure></div>

2. Collez l’ **App ID** depuis Meta for Developers.
3. Collez le **secret d’application** depuis Meta for Developers.
4. Enregistrez.

### Activez Facebook sur votre formulaire d’inscription

Activez le fournisseur dans les paramètres du formulaire d’inscription.

Allez dans `configuration avancée -> Layout` Ouvrez la mise en page sur laquelle vous souhaitez activer la connexion sociale et ajoutez ces lignes

<pre class="language-yaml"><code class="lang-yaml"><strong>signinOptions:
</strong>  providers:
    - type : facebook
</code></pre>

Pour plus d’informations, voir [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form).

### FAQ

<details>

<summary><strong>Avons-nous besoin d’un secret d’application Facebook ?</strong></summary>

Non. Cette configuration utilise le **App ID** uniquement.

Si vous voyez un secret d’application dans Meta for Developers, ne le collez nulle part dans Wallet Crew.

</details>

<details>

<summary><strong>Devrions-nous configurer « URI de redirection autorisées » dans Facebook ?</strong></summary>

Oui — contrairement à Google, Facebook **exige** que les URI de redirection OAuth valides soient explicitement répertoriées.

Ajoutez chaque origine d’environnement sous **Connexion Facebook → Paramètres → URI de redirection OAuth valides**.

</details>

<details>

<summary><strong>Que faut-il exactement ajouter comme domaine autorisé ?</strong></summary>

Ajoutez l’ **origine uniquement**: `scheme://host` (et le port si vous en utilisez un non standard).

Exemples :

* ✅ `https://app.neostore.cloud`
* ✅ `https://brand.example.com`
* ❌ `https://app.neostore.cloud/molia/mobile` (les chemins ne sont pas autorisés)

</details>

<details>

<summary><strong>Nous utilisons un domaine personnalisé. Que devons-nous faire ?</strong></summary>

Ajoutez votre domaine personnalisé à la fois à **URI de redirection OAuth valides** et **Domaines autorisés pour le SDK JavaScript** dans les paramètres de Connexion Facebook.

Utilisez le domaine exact que les utilisateurs voient dans le navigateur. Exemple : `https://wallet.brand.com`.

</details>

<details>

<summary><strong>Pourquoi répertorions-nous les origines de prod, QA et dev ?</strong></summary>

Facebook valide l’origine à l’exécution.

Si un utilisateur arrive en QA alors que seule la prod est configurée, Facebook rejette la connexion.

</details>

<details>

<summary><strong>Où active-t-on le bouton Facebook dans le parcours utilisateur ?</strong></summary>

La configuration du fournisseur ne suffit pas. Vous devez également activer Facebook sur le formulaire d’inscription.

Voir [Connexion sociale](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in) et [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form).

</details>


# Design

Personnalisez les formulaires d’inscription avec les logos de marque, les couleurs, la typographie, les sous-titres et les images d’en-tête.

## Concevoir le formulaire d'inscription de Wallet Crew

#### Capacités de conception du formulaire d'inscription de Wallet Crew

Le formulaire d'inscription de Wallet Crew est conçu dans un esprit de flexibilité et de personnalisation, en s'appuyant sur le système de thématisation Material-UI (MUI). Ci-dessous figurent les éléments de conception et leurs options de personnalisation.

**Système de thématisation Material-UI**

L'application exploite le système de thématisation Material-UI, permettant une personnalisation complète. Pour plus de détails, consultez la [Documentation de thématisation MUI](https://mui.com/customization/theming/).

#### Logo

Le logo peut être personnalisé pour représenter l'identité de votre marque. Assurez-vous que le logo s'intègre bien dans la mise en page du formulaire d'inscription et conserve sa visibilité sur différents appareils.

#### Couleurs

La palette de couleurs est un aspect crucial de la conception du formulaire d'inscription. Les images suivantes illustrent les options de couleurs :

![Couleurs](/files/fc138d98d6514ea423b86e42347035d11d5c2c7b)

![Couleurs (2)](/files/ceafe410d7af57fa4f7ebfdb29086fd4ca69847b)

Ces palettes de couleurs peuvent être adaptées pour correspondre à la palette de votre marque à l'aide du système de thématisation MUI.

#### Typographie

Les paramètres typographiques sont configurables afin de garantir la cohérence avec l'identité visuelle de votre marque. L'image suivante illustre les options typographiques :

![Typographie](/files/6b65752c3e85ae33a86dbb7da08e88e4080d22e4)

Ajustez les polices, les tailles et les graisses via le système de thématisation MUI afin de respecter les directives de votre marque.

#### Sous-titre

Le sous-titre est un champ de texte facultatif dans lequel vous pouvez proposer une incitation ou un appel à l'action pour encourager les utilisateurs à s'inscrire. Exemples :

* Obtenez 10 % de réduction
* Recevez des nouvelles de \[tenant name]
* Inscrivez-vous maintenant !

Ce champ doit être concis et percutant afin d'encourager l'inscription des utilisateurs.

#### Image d'en-tête

L'image d'en-tête améliore l'attrait visuel du formulaire d'inscription. Cette image peut être spécifiée de deux façons :

1. Comme URL : `HeaderImageConfiguration.Url`
2. Comme un `HeaderImageConfiguration` objet

L'image est affichée à l'aide des propriétés CSS suivantes :

* `background-size: cover`
* `height: 200px`

La largeur est responsive, s'ajustant à la largeur de l'écran de l'appareil avec une largeur minimale de 280px et environ 400px sur les smartphones modernes. Des styles supplémentaires peuvent être appliqués à l'aide de la `HeaderImageConfiguration.AdditionalStyles` propriété.

#### Palette de thème

Le formulaire d'inscription prend en charge les thèmes sombres et clairs. Choisissez le thème qui correspond le mieux à l'apparence de votre marque.

En personnalisant ces éléments, vous pouvez créer un formulaire d'inscription visuellement attrayant et cohérent avec l'identité de votre marque. Pour aller plus loin dans la personnalisation, consultez la [Documentation de thématisation MUI](https://mui.com/customization/theming/).


# Règles de validation

Configurez les règles de validation du formulaire d’inscription pour les contrôles de champ obligatoire, de format et de correspondance.

Les règles de validation protègent la qualité des données au moment de la capture. Elles empêchent les valeurs incomplètes ou mal formatées d’entrer dans les profils clients et les systèmes en aval.

Choisissez les règles en fonction de l’objectif de chaque champ. Une validation stricte est utile pour les identifiants. Les champs d’enrichissement facultatifs doivent rester faciles à compléter.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un programme de fidélité exige une adresse e-mail et vérifie son format avant l’inscription.
* Un formulaire de billetterie limite une référence de réservation à la longueur de caractères attendue.
* Un formulaire d’adhésion compare l’e-mail de confirmation avec le champ e-mail d’origine.

</details>

### Comment fonctionne la validation

La validation est configurée au niveau de chaque champ individuel. Chaque règle vérifie si une valeur répond aux exigences de données avant l’envoi du formulaire.

Utilisez un petit nombre de règles adaptées à l’objectif du champ. Des formulaires trop restrictifs peuvent augmenter les abandons et générer du travail de support.

### Règles de validation disponibles

#### Obligatoire

* Indique si le champ doit être renseigné.
* Pour les cases à cocher et les interrupteurs, cela signifie que la case doit être cochée.

#### `minLength`

* Définit le **nombre minimum de caractères** requis pour la valeur d’un champ.
* Utile pour des champs comme les noms ou les numéros d’identification.

#### `maxLength`

* Définit le **nombre maximum de caractères** autorisé dans le champ.
* Aide à empêcher les saisies excessivement longues qui pourraient perturber la mise en page ou le stockage.

#### `email`

* Combine deux niveaux de validation :
  1. **Vérification par expression régulière**: utilise l’expression régulière par défaut suivante pour valider le format :

     ```js
     /^[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?$/
     ```

     Cette expression régulière peut être **remplacée** par une expression personnalisée si nécessaire.
  2. **Vérification du domaine via DNS**: Wallet Crew vérifie que le domaine de l’e-mail accepte les messages en vérifiant la présence de **enregistrements MX**.

#### `phone`

* Valide les numéros de téléphone à l’aide du composant [react-phone-number-input](https://catamphetamine.gitlab.io/react-phone-number-input/) .
* Cette validation s’appuie sur la bibliothèque internationale de Google pour la validation des numéros de téléphone.
* Veille à ce que les numéros soient correctement formatés et que les indicatifs de pays soient reconnus.

#### `expression`

* Permet aux administrateurs de définir une **expression régulière personnalisée** pour valider le champ.
* Option flexible pour imposer des données au format spécifique (par ex. codes postaux, identifiants).

#### `égalité`

* Compare la valeur du champ à :
  * La valeur d’un autre champ (par ex. « Confirmer le mot de passe »)
  * Une valeur constante statique
* Garantit la cohérence et la correspondance lorsque cela est nécessaire.

### Configurer efficacement les règles

Commencez avec le minimum nécessaire pour identifier un client et émettre une Carte. Ajoutez d’autres règles uniquement lorsqu’elles améliorent un résultat opérationnel ou de conformité.

* Utilisez `obligatoire` uniquement pour les informations nécessaires lors de l’inscription.
* Utilisez `email` et `phone` pour les identifiants de contact client.
* Utilisez `égalité` pour les champs de confirmation, comme les adresses e-mail répétées.
* Testez les expressions régulières personnalisées avec des valeurs attendues et invalides avant la publication.

{% hint style="warning" %}
Personnalisez l’expression e-mail par défaut uniquement lorsqu’il existe une exigence documentée. Une expression trop restrictive peut rejeter des adresses e-mail clients valides.
{% endhint %}

### Validez le formulaire avant publication

Soumettez le formulaire avec des valeurs représentatives valides et invalides. Confirmez que les champs obligatoires bloquent les envois vides, que les règles de format affichent des erreurs claires et que les champs d’égalité rejettent les valeurs non concordantes.

Vérifiez également le résultat sur mobile et sur ordinateur. La plupart des parcours d’inscription commencent sur un téléphone après un scan de code QR ou un clic sur un lien de campagne.

### FAQ

<details>

<summary><strong>Quels champs doivent être obligatoires ?</strong></summary>

Rendez obligatoires uniquement les champs nécessaires pour identifier le client, émettre la Carte ou répondre à une exigence de conformité documentée. Les champs facultatifs peuvent être collectés plus tard.

</details>

<details>

<summary><strong>Quand faut-il utiliser une règle d’expression ?</strong></summary>

Utilisez une règle d’expression lorsqu’un identifiant métier nécessite un format spécifique que les règles standard ne couvrent pas. Testez l’expression avec des exemples valides et invalides avant la publication.

</details>

<details>

<summary><strong>Une adresse e-mail peut-elle être confirmée ?</strong></summary>

Oui. Ajoutez un deuxième champ e-mail et appliquez la `égalité` règle pour le comparer au champ d’origine.

</details>

<details>

<summary><strong>Pourquoi une adresse e-mail pourtant valide échoue-t-elle à la validation ?</strong></summary>

La règle e-mail vérifie à la fois le format de l’adresse et si le domaine accepte les messages via des enregistrements MX. Confirmez que le domaine est correctement orthographié et qu’il dispose d’enregistrements de messagerie valides.

</details>


# Cloudflare Turnstile

Renforcez la sécurité de l’inscription avec Cloudflare Turnstile pour vérifier le trafic humain.

Cloudflare Turnstile peut être activé pour réduire les inscriptions automatisées et les abus par script. Lorsqu’il est activé, le formulaire d’inscription inclut une vérification Turnstile et valide côté serveur le jeton obtenu.

L’implémentation reste en grande partie invisible. Turnstile s’exécute en arrière-plan et ne devient interactif que lorsque Cloudflare exige une vérification supplémentaire.

{% hint style="warning" %}
La détection des bots ne peut pas être exacte à 100 %. Turnstile fournit une mitigation de base contre les bots, pas une garantie. L’automatisation assistée par l’IA et les services avec intervention humaine rendent les abus de plus en plus difficiles à contrôler entièrement. La documentation Cloudflare décrit ici l’approche de Turnstile : [Documentation Cloudflare Turnstile](https://developers.cloudflare.com/turnstile/).
{% endhint %}

<div data-with-frame="true"><figure><img src="/files/cbdcebd157a573e56adfb23454e500e8a075e7d3" alt="Turnstile challenge displayed as a modal during enrolment" width="375"><figcaption><p>Vérification supplémentaire requise</p></figcaption></figure></div>

## Comment ça marche

1. Lorsque le formulaire d’inscription se charge, Turnstile s’exécute en arrière-plan.
2. Lorsque le formulaire est soumis, Turnstile peut demander une vérification interactive.
3. The Wallet Crew valide le jeton Turnstile côté serveur avant d’accepter l’inscription.

## Configuration

La configuration nécessite un widget Turnstile dans Cloudflare ainsi que les clés du widget. The Wallet Crew utilise la **clé du site** et **clé secrète** pour valider les soumissions d’inscription.

{% stepper %}
{% step %}

### Créer et configurer un widget Turnstile dans Cloudflare

Créez un widget Turnstile dans le tableau de bord Cloudflare. Cloudflare fournit une **clé du site** (publique) et une **clé secrète** (privée) pour chaque widget.

* Guide de configuration officiel : [Cloudflare Turnstile « Commencer »](https://developers.cloudflare.com/turnstile/get-started/)
* Point d’entrée du tableau de bord Cloudflare : [dash.cloudflare.com](https://dash.cloudflare.com/) (puis ouvrez **Turnstile**)

**La configuration par défaut est généralement suffisante. Veuillez consulter votre équipe informatique pour tout ajustement supplémentaire.**
{% endstep %}

{% step %}

### Récupérer la clé du site et la clé secrète

Dans Cloudflare, ouvrez la configuration du widget et copiez :

* **clé du site**
* **clé secrète**

Ces valeurs sont requises dans le Back Office de The Wallet Crew.
{% endstep %}

{% step %}

### Activer Turnstile dans The Wallet Crew

Demandez à l’équipe The Wallet Crew d’activer l’extension Cloudflare Turnstile pour le locataire.

Puis ouvrez la page des paramètres du Back Office et collez les clés :

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/security/turnstile" class="button secondary" data-icon="chevrons-right">Paramètres Turnstile</a></p>

<div data-with-frame="true"><figure><img src="/files/8a6ac5f96d4d14f865b0364fef05da6af2884add" alt="Turnstile settings in the Back Office." width="563"><figcaption><p>Paramètres Turnstile dans le Back Office.</p></figcaption></figure></div>
{% endstep %}
{% endstepper %}

## Notes

Turnstile est généralement invisible car il s’exécute en arrière-plan. Une vérification interactive n’est affichée que lorsque Cloudflare considère la session comme plus risquée.

La validation du jeton est toujours effectuée côté serveur par The Wallet Crew lorsque l’extension est activée.

### Limites et attentes

Turnstile améliore la protection de base, mais il ne « résout pas le problème des bots ». Les abus automatisés évoluent rapidement et s’appuient souvent sur des outils assistés par l’IA, des proxys résidentiels et des services avec intervention humaine. Cela rend irréaliste une détection parfaite des bots pour la plupart des flux publics d’inscription.

Cloudflare présente Turnstile comme une alternative sans friction aux CAPTCHA, et non comme une garantie que chaque bot sera bloqué. Combinez Turnstile avec d’autres contrôles lorsque l’inscription est critique pour l’activité.

Documentation officielle : [Documentation Cloudflare Turnstile](https://developers.cloudflare.com/turnstile/)

### Cookie de challenge

Après une vérification Turnstile réussie, l’application peut définir un cookie de sécurité à durée de vie courte. Cela conserve l’état de protection contre les bots entre les requêtes et réduit les défis Turnstile répétés pendant la même session d’inscription.

Comment ce cookie fonctionne :

1. L’utilisateur soumet le formulaire d’inscription avec un jeton Turnstile valide.
2. Le serveur valide ce jeton auprès de Cloudflare.
3. Si la validation réussit, le serveur émet un cookie de preuve signé.
4. Lors des prochaines requêtes liées à l’inscription, le serveur vérifie ce cookie.
5. Si le cookie est encore valide, le serveur peut ignorer un nouveau défi Turnstile pendant cette courte période.

Ce comportement est configurable dans le Back Office :

* La validité du cookie est définie en secondes, la valeur courante est de 600 secondes (10 minutes)&#x20;
* Lorsqu’il est désactivé, le serveur n’émet pas ce cookie et une vérification Turnstile est requise pour chaque parcours de soumission.

#### Exigence légale : cookie de sécurité

Ce cookie doit être listé dans la politique de cookies (souvent sous « strictement nécessaires » / « cookies de sécurité »).

* Nom du cookie : `neo.<tenantId>.turnstile-proof` où `<tenantId>` est l’identifiant de votre locataire wallet crew
* Objectif : conserver l’état de protection contre les bots entre les requêtes et éviter les défis Turnstile répétés
* Catégorie : cookie de sécurité (généralement considéré comme strictement nécessaire)
* Durée de vie : configurable (secondes). Mettre à 0 pour désactiver.
* Portée : soumission du formulaire d’inscription
* Attributs techniques :
  * `HttpOnly`
  * `Secure`
  * `SameSite=Lax`
  * `Path=/`

Ce cookie est utilisé uniquement pour la sécurité et la prévention de la fraude, et non pour l’analyse ou le marketing.

## FAQ

<details>

<summary>Turnstile affiche-t-il toujours un défi de type CAPTCHA ?</summary>

Non. Turnstile se termine souvent en arrière-plan. Un widget interactif n’est affiché que lorsque Cloudflare exige une vérification supplémentaire.

</details>

<details>

<summary>Turnstile suffit-il à bloquer complètement les bots ?</summary>

Non. Turnstile fournit une mitigation de base contre les bots, mais il n’est pas parfait. Les abus modernes peuvent utiliser l’automatisation assistée par l’IA, des réseaux de proxy et des résolutions avec intervention humaine.

La documentation officielle de Cloudflare couvre l’objectif et le comportement de Turnstile : [Documentation Cloudflare Turnstile](https://developers.cloudflare.com/turnstile/).

</details>

<details>

<summary>Quelles clés sont nécessaires de la part de Cloudflare ?</summary>

The Wallet Crew nécessite le widget Turnstile **clé du site** et **clé secrète**.

Cloudflare explique ici comment créer un widget et récupérer ces valeurs : [Turnstile « Commencer »](https://developers.cloudflare.com/turnstile/get-started/).

</details>

<details>

<summary>Que se passe-t-il si le jeton Turnstile est manquant ou invalide ?</summary>

Lorsque l’extension est activée, la soumission d’inscription n’est acceptée que lorsqu’un jeton Turnstile valide est reçu et correctement vérifié côté serveur. Les jetons invalides, expirés ou manquants sont considérés comme des soumissions non légitimes.

</details>

<details>

<summary>Comment tester que Turnstile est correctement configuré ?</summary>

Une validation rapide consiste à soumettre le formulaire d’inscription depuis une session de navigateur normale et à vérifier qu’il se termine sans friction. Une deuxième validation consiste à ouvrir le même flux dans un contexte plus strict (navigation privée, cookies tiers désactivés, VPN ou outils d’automatisation) et à vérifier que Turnstile se comporte toujours comme prévu.

Cloudflare documente les schémas de test recommandés et les étapes d’intégration dans le guide de configuration : [Turnstile « Commencer »](https://developers.cloudflare.com/turnstile/get-started/).

</details>

<details>

<summary>Quel domaine doit être configuré sur le widget Cloudflare ?</summary>

Ajoutez le **domaine personnalisé** qui héberge le formulaire d’inscription.

Cela se configure dans les paramètres du widget Turnstile dans Cloudflare. Le guide de configuration de Cloudflare couvre les détails de configuration du widget : [Turnstile « Commencer »](https://developers.cloudflare.com/turnstile/get-started/).

</details>


# Redirections

Créez des URL gérées et des codes QR pour des parcours d’inscription spécifiques au magasin.

Les redirections créent une URL courte et gérée pour un formulaire d'inscription. Elles ajoutent du contexte, comme un magasin, un vendeur, une langue ou une source de campagne, sans dupliquer le formulaire.

Cette approche maintient la cohérence des liens de diffusion et rend la performance mesurable sur plusieurs emplacements et campagnes.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de vente au détail imprime un code QR par magasin. Chaque code ajoute le bon `storeId`.
* Une équipe de clienteling utilise un code vendeur pour attribuer les inscriptions à chaque conseiller.
* Un code QR de campagne définit `neo.src` pour séparer les scans d'événements du trafic e-mail.

</details>

### Planifier la redirection

Définissez le formulaire d'inscription et le contexte transmis par le lien avant de créer une redirection. Une redirection doit répondre à un seul cas d'utilisation de diffusion clair.

Pour chaque redirection, confirmez ces détails :

* **Destination :** la mise en page du formulaire d'inscription qui s'ouvre.
* **Libellé :** un nom opérationnel clair, comme `Paris-Rivoli-été-2026`.
* **Paramètres :** le contexte ajouté lorsque le lien est ouvert.

Utilisez `storeId` lorsque le parcours doit identifier un magasin. La valeur doit correspondre à l'identifiant dans [Magasins](/guides-enrolment/fr/inscription/enrolment-form/stores).

Les paramètres d'assistance courants sont :

* `associateId` pour l'attribution au vendeur.
* `neo.lg` pour la langue d'affichage.
* `neo.src` pour la source de diffusion.

### Créer une redirection

Créez des redirections manuellement lorsque le contexte de diffusion est unique ou nécessite une validation avant publication.

{% stepper %}
{% step %}

#### Ouvrir les redirections

Dans la console d'administration, ouvrez **Formulaires → Redirections**. Sélectionnez **Ajouter**.

<figure><img src="/files/edeec9395ed4ccfa180319c385a5b22031342210" alt="The Wallet Crew administration console navigation"><figcaption><p>Ouvrez la section Redirections depuis le menu Formulaires.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Sélectionnez la destination

Dans **Mise en page**, sélectionnez la mise en page du formulaire d'inscription qui doit s'ouvrir. Dans **Libellé**, saisissez un nom qui identifie l'emplacement ou la campagne.
{% endstep %}

{% step %}

#### Ajoutez le contexte

Sélectionnez **Ajouter un paramètre** et ajoutez la clé et la valeur requises. Pour l'acheminement par magasin, utilisez `storeId` et l'identifiant de données du magasin correspondant.

Ajoutez `associatId`, `neo.lg`, ou `neo.src` uniquement lorsque le parcours a besoin d'une attribution au vendeur, d'une substitution de langue ou d'un suivi de source.
{% endstep %}

{% step %}

#### Enregistrer et vérifier

Enregistrez la redirection. Ouvrez une fois le lien généré et confirmez que le formulaire et le contexte attendus se chargent.
{% endstep %}
{% endstepper %}

### Importer des redirections en masse

L'importation en masse prend en charge les grands réseaux de magasins et les modèles de campagne répétés. Elle réduit le travail manuel et maintient la cohérence des noms de redirection.

Préparez un fichier Excel avec ces colonnes :

* `Mise en page`
* `Libellé`
* `StoreId`

Retour à **Formulaires → Redirections** et importez le fichier. Vérifiez un échantillon de redirections importées avant de distribuer leurs codes QR.

### Valider et distribuer

La validation évite une attribution incorrecte au magasin et des parcours d'inscription interrompus. Testez chaque redirection avec une configuration de formulaire connue avant de l'imprimer ou de la publier.

#### Aperçu du code QR

Sélectionnez le menu à trois points à côté d'une redirection, puis sélectionnez **Afficher**. Confirmez que l'aperçu inclut les bons paramètres et ouvre le formulaire prévu.

#### Télécharger les codes QR

Sélectionnez **Télécharger** pour exporter les codes QR sous forme de fichier ZIP. L'export contient des versions `.png` et `.svg` pour une utilisation numérique et imprimée.

#### Surveiller l'activité des redirections

Sélectionnez **Afficher les statistiques** depuis le menu à trois points. Choisissez une plage de dates pour examiner le volume de scans, comparer les magasins et évaluer les performances de la campagne.

#### Supprimer une redirection

Supprimez une redirection lorsque son parcours d'inscription, son magasin ou sa campagne n'est plus actif, par exemple lorsqu'un magasin physique ferme.

{% stepper %}
{% step %}
**Ouvrir les redirections**

Dans la console d'administration, ouvrez **Formulaires → Redirections**.
{% endstep %}

{% step %}
**Supprimer la redirection**

Sélectionnez le menu à trois points à côté de la redirection, puis sélectionnez **Supprimer**. Confirmez la suppression.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
La suppression d'une redirection invalide son code QR et son lien générés. Mettez à jour ou retirez tous les codes QR et liens imprimés ou distribués qui pointent vers une redirection supprimée afin d'éviter des parcours d'inscription interrompus.
{% endhint %}

### FAQ

<details>

<summary><strong>Quand faut-il utiliser une redirection ?</strong></summary>

Utilisez une redirection lorsqu'un formulaire d'inscription a besoin d'un contexte spécifique au mode de diffusion. Les codes QR de magasin, les liens vendeur, les liens spécifiques à une langue et les liens de campagne suivis sont des usages courants.

</details>

<details>

<summary><strong>Plusieurs redirections peuvent-elles utiliser le même formulaire d'inscription ?</strong></summary>

Oui. Chaque redirection peut ouvrir le même formulaire tout en ajoutant différents paramètres. Cela permet d'utiliser un formulaire partagé pour plusieurs magasins ou campagnes.

</details>

<details>

<summary><strong>Comment les codes QR de magasin doivent-ils être validés ?</strong></summary>

Scannez un échantillon des codes QR générés avant l'impression. Confirmez que chaque lien ouvre le bon formulaire et contient le `storeId`.

</details>

<details>

<summary><strong>Quel format de code QR faut-il utiliser ?</strong></summary>

Utilisez `.svg` pour les supports imprimés, car il s'adapte sans perte de qualité. Utilisez `.png` pour les canaux numériques qui nécessitent une image matricielle.

</details>

<details>

<summary><strong>Une redirection peut-elle être désactivée temporairement ?</strong></summary>

Non. Les redirections ne peuvent pas être désactivées. Supprimez la redirection lorsqu'elle n'est plus nécessaire, puis mettez à jour ou supprimez tous les codes QR et liens qui y renvoient.

</details>

<details>

<summary><strong>Un identifiant de redirection supprimé peut-il être réutilisé ?</strong></summary>

Non. Les identifiants de redirection sont générés automatiquement et ne peuvent pas être sélectionnés. Une fois supprimé, un identifiant de redirection ne peut pas être réutilisé.

</details>


# Magasins

Créez et importez des données de localisation des magasins pour les parcours d’inscription et les expériences de Carte Wallet.

Les données de boutique créent une référence partagée pour chaque emplacement physique. Elles attribuent à chaque boutique un identifiant unique et des détails d’emplacement qui peuvent être utilisés dans les parcours d’inscription, les redirections et les configurations Wallet Carte.

Utilisez les données de boutique lorsqu’un programme fonctionne sur plusieurs emplacements. Cela maintient un contexte de localisation cohérent et évite d’ajouter manuellement les mêmes informations de boutique à chaque parcours.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de distribution ajoute un `storeId` à chaque code QR en magasin pour le reporting des inscriptions au niveau de l’emplacement.
* Un organisateur d’événements stocke les détails du lieu pour la distribution des billets et le support client.
* Une marque de luxe relie un parcours de clienteling à la boutique où le client s’est inscrit.

</details>

### Pourquoi les données de boutique sont importantes

Les données de boutique relient un parcours Wallet numérique à un emplacement physique. Cela prend en charge une attribution précise, des expériences client localisées et un reporting opérationnel fiable.

Le `storeId` est la valeur clé. Il doit rester stable, car les redirections et d’autres configurations l’utilisent pour identifier l’emplacement.

### Créer une boutique

Créez des boutiques individuellement lors de l’ouverture d’un nouvel emplacement ou de la gestion d’un petit réseau de boutiques.

{% stepper %}
{% step %}

#### Ouvrir les données de boutique

Dans la console d’administration, ouvrez **Intégration → Données → Boutique**.

<figure><img src="/files/e5853a36cfa2844badfddcc43c726d953427b0b6" alt="Store data section in The Wallet Crew administration console"><figcaption><p>Ouvrez la section Boutique pour gérer les données d’emplacement.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Ajouter une boutique

Sélectionnez **Ajouter un nouveau** pour ouvrir le formulaire de données de boutique.
{% endstep %}

{% step %}

#### Saisissez les détails de la boutique

Ajoutez les informations de boutique requises :

* **`storeId`** — un identifiant unique et stable pour l’emplacement.
* **Nom** — le nom de la boutique ou du lieu.
* **Adresse** — l’adresse de l’emplacement.

<figure><img src="/files/f7ff93486a3a69cf48f4c24cbb07808590476757" alt="Store data form with fields for store ID, name, and address"><figcaption><p>Utilisez un identifiant de boutique unique et des détails d’emplacement reconnaissables.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Enregistrez et vérifiez

Sélectionnez **Enregistrer**, puis confirmez que la nouvelle boutique apparaît dans la liste des boutiques.

<figure><img src="/files/d586036f40dad895ead7202473b6ff2dc10b3cb7" alt="Saved store data record in The Wallet Crew administration console"><figcaption><p>Vérifiez l’enregistrement sauvegardé avant d’utiliser son identifiant de boutique dans une redirection.</p></figcaption></figure>
{% endstep %}
{% endstepper %}

### Importer plusieurs boutiques

Utilisez une importation Excel lors de l’ajout ou de la mise à jour de nombreux emplacements. Incluez les mêmes champs de base que pour la création manuelle : `storeId`, le nom et l’adresse.

Des données supplémentaires spécifiques à la boutique peuvent également être incluses si nécessaire, comme un code de billet. Conservez des noms de colonnes et des valeurs d’identifiant cohérents d’une importation à l’autre.

<figure><img src="/files/4668b42494e081585e65e81bb6c65e386a6344b6" alt="Excel import interface for several store data records"><figcaption><p>Importez les données de boutique en masse afin de gérer efficacement un vaste réseau d’emplacements.</p></figcaption></figure>

### Utilisez les identifiants de boutique dans les parcours d’inscription

Les identifiants de boutique relient les données d’emplacement aux canaux de distribution. Par exemple, un [Redirection](/guides-enrolment/fr/inscription/enrolment-form/redirect) peut ajouter `storeId` à une URL de formulaire d’inscription.

Avant de publier un code QR ou un lien spécifique à une boutique, confirmez que son `storeId` correspond à un enregistrement de boutique existant. Cela évite l’absence de contexte d’emplacement et les rapports inexacts.

### FAQ

<details>

<summary><strong>Qu’est-ce qui fait un bon identifiant de boutique ?</strong></summary>

Utilisez, si possible, une valeur unique et stable provenant d’un système métier existant. Évitez les valeurs susceptibles de changer lorsque le nom d’une boutique, l’adresse ou l’équipe locale change.

</details>

<details>

<summary><strong>Un seul formulaire d’inscription peut-il prendre en charge plusieurs boutiques ?</strong></summary>

Oui. Utilisez le même formulaire avec des redirections séparées. Chaque redirection peut ajouter le `storeId` pour son emplacement.

</details>

<details>

<summary><strong>Les boutiques doivent-elles être créées manuellement ou via import ?</strong></summary>

Créez des boutiques individuelles manuellement pour des modifications ponctuelles. Utilisez l’import Excel pour un nouveau réseau de boutiques ou pour des mises à jour répétées sur plusieurs emplacements.

</details>

<details>

<summary><strong>Que faut-il vérifier après l’importation des boutiques ?</strong></summary>

Vérifiez un échantillon d’enregistrements. Confirmez que chaque identifiant de boutique est unique et que son nom et son adresse correspondent à l’emplacement prévu.

</details>


# Pages de téléchargement

Configurez des pages de téléchargement hébergées qui permettent aux clients d’enregistrer une ou plusieurs Cartes Apple Wallet et Google Wallet.

Les pages de téléchargement sont des pages de distribution de cartes hébergées. Elles permettent aux clients d’enregistrer des cartes Apple Wallet ou Google Wallet sans remplir de formulaire d’inscription.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un e-mail de fidélité renvoie vers une seule carte client existante.
* Une confirmation de réservation affiche chaque billet d’une même commande.
* Une zone de compte répertorie les cartes et billets actifs d’un client.

</details>

### Quand utiliser une page de téléchargement

Utilisez une page de téléchargement lorsque la carte existe déjà. L’URL de distribution résout la carte, puis affiche l’action Wallet pertinente.

Utilisez un [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form) lorsque l’inscription, les vérifications d’identité ou la collecte du consentement doivent avoir lieu en premier.

Utilisez [Sur votre site Web](/guides-enrolment/fr/inscription/on-your-website) pour intégrer un bouton Ajouter à Wallet dans une expérience Web existante. Utilisez [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1) pour un parcours d’application native.

### Configurer une page de téléchargement

Configurez les pages de téléchargement dans **Wallet → Pages de téléchargement**. Chaque page nécessite un slug d’URL unique et un type de page.

Utilisez des slugs distincts pour des parcours de distribution distincts. Par exemple, utilisez `fidélité` pour les cartes et `billets` pour les cartes d’événement.

#### Choisissez le type de page

| Type de page    | Clé de configuration | À utiliser lorsque                                     |
| --------------- | -------------------- | ------------------------------------------------------ |
| Carte unique    | `carte`              | Une seule URL de distribution résout une carte.        |
| Liste de cartes | `passList`           | Une seule URL de distribution résout plusieurs cartes. |

Une page à carte unique affiche les actions Wallet pour la carte résolue. Une page à liste de cartes permet aux clients de sélectionner les cartes correspondantes.

#### Configurer une page à carte unique

Utilisez une `carte` page lorsque l’URL résout exactement une carte.

| Propriété           | Par défaut | Objectif                                                                                              |
| ------------------- | ---------- | ----------------------------------------------------------------------------------------------------- |
| `autoDownloadPass`  | `false`    | Télécharge automatiquement le fichier de carte. Cela convient aux parcours de liens profonds mobiles. |
| `passCreation.flow` | —          | S’exécute lorsqu’aucune carte n’existe. Le flux doit contenir un `Carte` élément.                     |

Sans `passCreation.flow`, une carte manquante génère une erreur.

#### Configurer une page à liste de cartes

Utilisez une `passList` page lorsque l’URL peut résoudre plusieurs cartes. Une réservation avec plusieurs billets est un exemple courant.

| Propriété                | Par défaut | Objectif                                                          |
| ------------------------ | ---------- | ----------------------------------------------------------------- |
| `allowDownloadAllPasses` | `true`     | Affiche une action pour télécharger chaque carte résolue.         |
| `showInactivePasses`     | `false`    | Répertorie les cartes inactives sans autoriser le téléchargement. |

#### Appliquer les paramètres partagés

Les deux types de page prennent en charge ces paramètres.

| Propriété                        | Objectif                                                                                |
| -------------------------------- | --------------------------------------------------------------------------------------- |
| `headerImage`                    | Affiche une image en haut de la page. Utilisez une URL absolue ou un `/public/` chemin. |
| `theme`                          | Remplace le thème de la page.                                                           |
| `internationalization.resources` | Définit des ressources de chaînes traduites, comme `/locales/fields`.                   |
| `errorLayoutName`                | Envoie les erreurs irrécupérables vers un autre slug de page.                           |
| `requireValidRedirectId`         | N’accepte qu’une redirection de plateforme connue lorsqu’il est défini sur `true`.      |

{% hint style="info" %}
Définissez `requireValidRedirectId` à `true` lorsque les redirections de plateforme approuvées doivent contrôler l’accès. Sa valeur par défaut est `false`.
{% endhint %}

### Construire une URL de distribution

Une URL de distribution ouvre une page de téléchargement hébergée. Les clients utilisent cette page pour enregistrer une carte dans Apple Wallet ou Google Wallet.

Utilisez des URL de distribution dans les e-mails, les messages SMS, les codes QR et les pages d’atterrissage de campagne. Choisissez la méthode de recherche en fonction des données disponibles lors de la génération du lien.

Choisissez la méthode de recherche avant de construire l’URL. Déterminez d’abord si le lien résout une carte connue ou un enregistrement client. Évaluez ensuite si l’identifiant est opaque, prévisible ou sensible. Enfin, confirmez où l’URL est générée et quel connecteur la traite.

Utilisez un ID de carte lorsque l’ID de carte attribué par la plateforme est déjà disponible. Utilisez un ID externe lorsqu’un identifiant détenu par l’entreprise doit résoudre une carte ou une liste de cartes. Utilisez un jeton d’authentification lorsqu’un backend crée un lien sécurisé et spécifique au destinataire.

Chaque URL de distribution a cette structure de base :

`https://{host}/{tenant}/{layout}?{lookup parameter}`

* **`{host}`** est un domaine personnalisé ou `app.neostore.cloud`.
* **`{tenant}`** est l’identifiant du tenant.
* **`{layout}`** est le slug de page de téléchargement configuré.
* **`{lookup parameter}`** identifie la carte ou le client.

La mise en page contrôle la page après la découverte de la carte. Elle peut afficher une carte, une liste de cartes ou un parcours d’inscription.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un e-mail de fidélité résout une carte client avec un identifiant CRM signé.
* Un code QR ouvre chaque billet lié à un identifiant de réservation.
* Un lien de campagne utilise un jeton d’authentification pour chaque destinataire.

</details>

{% tabs %}
{% tab title="ID de carte" %}
Utilisez un ID de carte lorsque l’ID de carte attribué par la plateforme est déjà disponible. Cette valeur opaque identifie une carte connue. Elle n’a pas besoin de signature.

Cela convient aux communications client après la création de la carte. Stockez l’ID de carte lors de la création de la carte. Ajoutez-le ensuite à l’URL de distribution.
{% endtab %}

{% tab title="ID externe" %}
Utilisez un ID externe lorsqu’un identifiant stable détenu par l’entreprise est disponible. La clé d’identifiant est libre. Les clés courantes incluent `y2.customerId`, `comarch.customerId`, et `shopify.orderId`.

Utilisez la même clé et la même valeur que celles stockées sur la carte. La méthode de sécurité dépend de l’identifiant et du connecteur. Un ID externe peut être protégé par une signature HMAC ou en incluant un secret dans l’URL de distribution.

Pour une recherche protégée par HMAC, ajoutez la signature au paramètre correspondant `.hmac`  :

`id.y2.customerId={customerId}&id.y2.customerId.hmac={hmac}`

Utilisez HMAC-SHA256 avec le secret du tenant. Les secrets du tenant sont disponibles dans **Paramètres → Clés API et secrets**. Deux secrets rotatifs sont acceptés. Cela prend en charge la rotation des secrets sans interruption de distribution.

{% hint style="warning" %}
N’exposez pas un identifiant prévisible sans protection. Les numéros de client et de carte de fidélité peuvent être énumérés pour accéder à d’autres cartes.
{% endhint %}
{% endtab %}

{% tab title="Jeton d’authentification" %}
Utilisez un jeton d’authentification lorsqu’un backend crée un lien signé pour chaque destinataire. Le jeton identifie le client avant l’ouverture de la page de téléchargement.

Générez le JWT sur un serveur avec l’API de jetons. La clé API nécessite le `AuthenticationToken.Write` scope. La réponse renvoie un JWT par jeu de revendications. Ajoutez ce JWT comme paramètre de `neo.authToken` URL de distribution.

Les jetons sont valides pendant 10 ans par défaut. Définissez `validityDuration` pour raccourcir cette période. Par exemple, `1.00:00:00` crée une période de validité d’un jour.

{% hint style="warning" %}
Générez les jetons uniquement sur un serveur. N’exposez jamais une clé API ni la logique de génération de jetons dans le code du navigateur ou les modèles d’e-mail.
{% endhint %}
{% endtab %}
{% endtabs %}

#### Ajouter le suivi de campagne

Ajoutez `neo.src` pour enregistrer comment un client a atteint la page de téléchargement. Son format est `tags|medium|origin`.

* **tags** sont des catégories séparées par des virgules, comme `email-campaign,loyalty`.
* **medium** est un canal, comme `email`, `sms`, ou `qr`.
* **origin** est la source de référence. L’en-tête HTTP `Referer` est utilisé lorsqu’il est omis.

Par exemple, un e-mail de fidélité peut utiliser `neo.src=email-campaign,loyalty|email|crm`.

### Valider le flux de distribution

Testez chaque page avec une URL de distribution qui cible des données connues.

1. Confirmez qu’une page à carte unique affiche la carte attendue.
2. Confirmez qu’une page à liste de cartes renvoie chaque carte attendue.
3. Confirmez que les cartes inactives suivent le paramètre d’affichage choisi.
4. Confirmez qu’un identifiant ou une signature modifiés ne résolvent pas de carte.

### Choisissez le bon canal de distribution

Les pages de téléchargement hébergent l’expérience de distribution de cartes. Les autres canaux contrôlent l’endroit où cette expérience commence.

* [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form) — capturez les données avant d’émettre une carte.
* [Sur votre site Web](/guides-enrolment/fr/inscription/on-your-website) — ajoutez des actions Wallet à un site Web existant.
* [Via e-mail](/guides-enrolment/fr/inscription/via-email) — envoyez des liens de carte sécurisés aux clients existants.
* [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1) — lancez l’installation native de Wallet depuis une application.

### FAQ

<details>

<summary><strong>Quand une page à liste de cartes doit-elle être utilisée ?</strong></summary>

Utilisez une `passList` page lorsqu’une seule URL de distribution peut résoudre plusieurs cartes. Les confirmations de réservation et les zones de compte sont des exemples courants.

</details>

<details>

<summary><strong>Une marque peut-elle utiliser plusieurs pages de téléchargement ?</strong></summary>

Oui. Plusieurs pages peuvent utiliser le même type. Donnez à chaque page un slug distinct pour son parcours de distribution.

</details>

<details>

<summary><strong>Une page de téléchargement peut-elle enregistrer un client ?</strong></summary>

Non. Utilisez un [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form) lorsque l’identité du client doit être collectée avant l’émission de la carte.

</details>

<details>

<summary><strong>Quelle méthode de recherche doit être utilisée ?</strong></summary>

Utilisez un ID de carte lorsque la carte exacte est connue. Utilisez un identifiant externe signé pour les identifiants métier stables. Utilisez un jeton d’authentification lorsqu’un backend crée un lien sécurisé par destinataire.

</details>

<details>

<summary><strong>Les identifiants externes doivent-ils être signés ?</strong></summary>

Signez les identifiants prévisibles avec HMAC-SHA256. Les ID de carte opaques attribués par la plateforme ne nécessitent pas de signature.

</details>


# Sur votre site web

Intégrez un bouton « Ajouter à Wallet » sur votre site web avec le SDK cinto de The Wallet Crew (détection Apple/Google + solution de secours sur ordinateur).

**cinto** est le SDK JavaScript de The Wallet Crew pour intégrer des boutons Add to Wallet sur n'importe quelle page web. Utilisez-le pour placer un **Add to Wallet** bouton sur n'importe quel site web — le SDK détecte l'appareil et affiche automatiquement le bon appel à l'action.

Sur iOS, il affiche **Ajouter à Apple Wallet**. Sur Android, il affiche **Ajouter à Google Wallet**. Sur ordinateur, il peut rediriger vers une page de carte hébergée ou prendre en charge une solution de repli basée sur un QR code.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une page de compte fidélité affiche un bouton pour la carte du client connecté.
* Une section de cartes-cadeaux affiche un bouton par carte-cadeau active.
* Une page de billetterie affiche un bouton par billet, pas un bouton par commande.

</details>

<figure><img src="/files/8afcc3e12768ffb23b7213e089cc854009315fa6" alt="Add to Wallet button embedded on a website with device-specific rendering."><figcaption><p>La même intégration adapte le bouton à iOS, Android et aux ordinateurs.</p></figcaption></figure>

## Comment fonctionne l'intégration sur le site web

L'intégration est simple. Une page charge le SDK cinto, puis affiche un bouton qui résout une carte.

Cette carte peut être résolue de deux façons :

* avec un `passId`
* avec `externalIdentifiers` et un HMAC facultatif

### Chaque carte doit être unique

Ce point est crucial. Une carte Wallet est **pas** une ressource partagée.

Chaque carte doit représenter un client, une carte, un billet ou une instance de droit d'accès. Le bouton affiché sur une page doit résoudre uniquement la carte correspondant au contexte actuel.

Par exemple :

* une page de carte de fidélité doit résoudre la carte du client actuel
* une liste de billets doit résoudre une carte distincte par billet
* une liste de cartes-cadeaux doit résoudre une carte distincte par carte-cadeau

{% hint style="warning" %}
N'utilisez jamais la même valeur d'identifiant statique pour chaque client. Si le même `customerId`, l'identifiant de billet ou la valeur de recherche de carte est codé en dur pour tous les visiteurs, la même carte peut être renvoyée à tout le monde.
{% endhint %}

Lorsque `externalIdentifiers` sont utilisés, la valeur de l'identifiant doit être suffisamment unique pour résoudre **exactement une carte**. Si une recherche renvoie plusieurs cartes, la stratégie d'identifiant n'est pas assez spécifique pour une distribution sur site web.

### Ce qui change selon l'appareil

Le SDK affiche automatiquement le comportement approprié :

* **iOS :** télécharge la carte Apple Wallet
* **Android :** ouvre le flux d'enregistrement Google Wallet
* **Ordinateur :** redirige vers une page de carte hébergée

Ce comportement par défaut peut être remplacé si nécessaire avec `platform`.

#### Exemple de rendu

**iOS**

<img src="/files/b176e29707d45b3fd06d8d9a0b1c80285cbeccf0" alt="Bouton Ajouter à Apple Wallet affiché sur iPhone." width="250">

**Android**

<img src="/files/157c4811417ed857842d7aa7a9519031dd9d66fd" alt="Bouton Ajouter à Google Wallet affiché sur Android." width="250">

**Ordinateur**

<img src="/files/e7146c77b8f98aa5aac7daaccdc3b75f8fbf2732" alt="Rendu de secours sur ordinateur pour Add to Wallet." width="250">

Le mode de secours sur ordinateur ouvre une page de carte hébergée telle que :

![Page de carte hébergée utilisée comme solution de secours sur ordinateur pour la distribution sur site web.](/files/4aa61a8db57108876a766b0ca2c28d81736b3456)

{% hint style="info" %}
Le comportement sur ordinateur peut être personnalisé pour afficher un code QR au lieu d'un bouton standard.
{% endhint %}

## Choisissez comment le bouton résout la carte

Le principal choix d'implémentation est la méthode de résolution de la carte.

Utilisez `passId` lorsque le backend connaît déjà la carte exacte. Utilisez `externalIdentifiers` lorsque le site web a accès à un identifiant métier stable et que la carte doit être résolue dynamiquement.

### Commencez avec `tenantId` et `environment`

Deux valeurs du SDK sont particulièrement importantes :

* `tenantId`
* `environment`

`tenantId` est requis. C'est le nom du tenant dans le système The Wallet Crew. Dans les exemples de cette page, `molia` est le `tenantId`.

`environment` est l'URL de base publique utilisée par le SDK.

Utilisez ces valeurs comme suit :

* **Production :** `https://<customDomain>` le générique `https://app.neostore.cloud` peut aussi être utilisé lorsqu'aucun domaine personnalisé n'a été configuré
* **Test / QA :** `https://app-qa.neostore.cloud`

{% hint style="info" %}
Si `environment` est omis, le SDK utilise `https://app.neostore.cloud`. Ce comportement par défaut est valide pour la production.
{% endhint %}

### Option 1 — Résoudre avec `passId`

C'est l'option la plus simple. Elle fonctionne mieux lorsque le backend connaît déjà la carte exacte à afficher.

{% tabs %}
{% tab title="JavaScript vanilla" %}

```html
<script type="text/javascript">
(function (n, e, o) {
var s=n.createElement("script");s.src="https://sdk.neostore.cloud/scripts/"+e+"/cinto@1";s.async=1;
s.onload=function(){neostore.cinto.initialize(e,o)};n.body.appendChild(s);
})(document, "molia", {});
</script>

<div data-neostore-addToWalletButton data-neostore-passId="KlnqcxVLA9pS4ol5"></div>
```

{% endtab %}

{% tab title="module npm" %}

```bash
npm install @neostore/cinto
```

```jsx
import { AddToWalletButton } from "@neostore/cinto";

const btn = new AddToWalletButton("molia", {
    language: "fr",
    passId: "KlnqcxVLA9pS4ol5",
});

btn.render(document.getElementById("btn"));
```

{% endtab %}
{% endtabs %}

### Option 2 — Résoudre avec `externalIdentifiers`

Cette option est utile lorsque la page connaît un identifiant métier stable, comme un identifiant de fidélité, un identifiant CRM ou un identifiant de billet, mais ne connaît pas encore le `passId` encore.

L'identifiant doit appartenir au client ou à l'objet actuel. Il ne doit pas s'agir d'une constante partagée.

Lorsque HMAC est utilisé, la signature doit être calculée côté serveur avec l'un des secrets The Wallet Crew.

Par exemple, pour un `customerId` de `SC103010` et un secret de `I1M8emrrJSns4Hnuibbm45eWfLQMosPGKSp1JzKsCrXeWmhjE8lZhxC2tfSRX5IJ`, la valeur HMAC est :

`8c5a9ebdd9b4ac8d2307cc34192f0faed441ef724c043162f0618784173d4d93`

Outil de référence : [CyberChef](https://gchq.github.io/CyberChef/#recipe=HMAC\({'option':'UTF8','string':'I1M8emrrJSns4Hnuibbm45eWfLQMosPGKSp1JzKsCrXeWmhjE8lZhxC2tfSRX5IJ'},'SHA256'\)\&input=U0MxMDMwMTA)

{% hint style="warning" %}
Le secret HMAC doit rester côté serveur. Il ne doit jamais être exposé dans le code du navigateur.
{% endhint %}

#### Attributs de données

```html
<script type="text/javascript">
(function (n, e, o) {
var s=n.createElement("script");s.src="https://sdk.neostore.cloud/scripts/"+e+"/cinto@1";s.async=1;
s.onload=function(){neostore.cinto.initialize(e,o)};n.body.appendChild(s);
})(document, "molia", { language: "fr" });
</script>

<div data-neostore-addToWalletButton
     data-neostore-passType="user"
     data-neostore-externalIdentifiers-y2.customer_Id-value="SC103010"
     data-neostore-externalIdentifiers-y2.customer_Id-hmac="cbbcfc5xxxxx"
 ></div>
```

#### Utilisation du composant

```jsx
import { AddToWalletButton } from "@neostore/cinto";

const btn = new AddToWalletButton("molia", {
    language: "fr",
    passType: "user",
    externalIdentifiers: {
        "y2.customerId": {
            value: "SC103010",
            hmac: "cbbcfc5xxxxx",
        },
    },
});

btn.render(document.getElementById("btn"));
```

#### Casse des clés d'identifiant en HTML

Les navigateurs mettent les noms d'attributs HTML en minuscules. Pour préserver une majuscule dans une clé d'identifiant, préfixez le caractère avec `_` dans le nom de l'attribut.

Exemple :

* `y2.customer_Id` devient `y2.customerId`

Cette règle n'affecte que le nom de l'attribut HTML. Elle ne modifie pas la valeur signée.

## Comportement et options courants

### Détection de la plateforme

Lorsque `data-neostore-addToWalletButton` est utilisé, le composant sélectionne automatiquement la bonne plateforme :

* `desktop`
* `apple`
* `google`

Pour forcer une plateforme, définissez `data-neostore-platform="desktop"` ou utilisez l' `platform` option dans le composant.

### Détection de la langue

Le SDK utilise la langue du navigateur par défaut. Si la langue locale n'est pas disponible, il revient à l'anglais.

Pour forcer une langue :

* attributs de données : `data-neostore-language="fr"`
* option du composant : `language: "fr"`

Exemple de JavaScript vanilla

```html
<script type="text/javascript">
(function (n, e, o) {
var s=n.createElement("script");s.src="https://sdk.neostore.cloud/scripts/"+e+"/cinto@1";s.async=1;
s.onload=function(){neostore.cinto.initialize(e,o)};n.body.appendChild(s);
})(document, "molia", { language: "fr" });
</script>

<div data-neostore-addToWalletButton data-neostore-passId="KlnqcxVLA9pS4ol5"></div>
```

### Options complètes

Voici la liste complète des options disponibles.

```typescript
export interface Options {
    /**
     * URL de base publique de l'environnement.
     * Utilisez "https://app-qa.neostore.cloud" pour les tests.
     * Utilisez "https://app.neostore.cloud" pour la production.
     * Un domaine personnalisé du tenant peut aussi être utilisé.
     * @default: "https://app.neostore.cloud"
     */
    environment: string;
    /**
     * Nom du tenant dans le système The Wallet Crew.
     * Cette valeur est requise.
     * Exemple : "molia"
     */
    tenantId: string;
    /**
     * Nom de la mise en page de carte vers laquelle rediriger l'utilisateur lorsqu'il est sur ordinateur
     * @default: undefined // la mise en page de carte par défaut du modèle de carte sera utilisée
     */
    passLayoutName: string;
    /**
     * Code langue ISO 639 à utiliser pour afficher le bouton. Lorsqu'il est omis, la langue sera détectée automatiquement selon les paramètres du navigateur.
     * Si la valeur ne correspond à aucune option disponible, les paramètres du navigateur seront utilisés ; sinon, l'anglais sera utilisé.
     * @default: undefined
     */
    language?: string;
    /**
     * Identifiant de la carte à afficher ou promesse associée
     */
    passId: string;
    /**
     * Plateforme à utiliser pour afficher le bouton. Lorsqu'elle est omise, la plateforme sera détectée automatiquement à partir du user agent.
     * Les valeurs possibles sont : "apple", "google" ou "desktop"
     *
     * @default: undefined
     **/
    platform?: Platform;
    /**
     * Identifiants externes à utiliser pour obtenir le passId
     */
    externalIdentifiers?: Record<string, { value: string; hmac?: string }>;
    /**
     * Type de carte à utiliser pour obtenir le passId
     * Requis lorsque externalIdentifiers est défini
     */
    passType?: string;
    
    /**
     * Source utilisée à des fins d'analyse
     */
    source?: {
        /**
         * Liste de tags à associer à ce téléchargement. utm_source et utm_campaign seront automatiquement ajoutés à cette liste
         */
        tags?: Array<string>;
        /**
         * support à associer à ce téléchargement. utm_medium sera utilisé si aucune valeur n'est spécifiée
         */
        medium?: string;
        /**
         * origine à associer à ce téléchargement. l'URL actuelle (sans la requête) sera utilisée si aucune valeur n'est spécifiée
         */
        origin?: string;
    };

    /**
     * Fonction de rappel appelée lorsque le bouton est cliqué
     */
    onClick?: (e: MouseEvent, data: { options: Partial<Options>; platform: Platform }) => void;

    /**
     * Fonction de rappel lorsqu'une erreur se produit
     *
     */
    onError?: (error: string) => void;
}

```

### Style

La structure rendue est :

* un conteneur fourni par le site web
  * un lien avec sélecteur `.neostore-link`
    * une image avec des sélecteurs `.neostore-img` et `.neostore-link-{{ platform }}`

Sur ordinateur, le bouton peut être entièrement personnalisé. Le résultat clé est l’URL de la carte hébergée, donc le bouton par défaut peut être remplacé par un CTA personnalisé ou un flux de code QR.

Sur mobile, le bouton doit suivre les consignes de conception d’Apple et de Google. L’élément de marque, le libellé, l’espacement et la présentation globale doivent rester conformes aux exigences de chaque fournisseur.

Les éléments de bouton Apple et Google suivent les consignes de chaque fournisseur :

* [Consigne Apple](https://developer.apple.com/wallet/add-to-apple-wallet-guidelines/)
* [Consigne Google](https://developers.google.com/wallet/generic/resources/brand-guidelines)

## Personnalisation du bureau

Sur ordinateur, le résultat le plus important est l’URL de la Carte hébergée. Cette URL peut être utilisée pour afficher un code QR à la place du bouton de redirection par défaut.

```html
<script src="https://cdn.rawgit.com/davidshimjs/qrcodejs/gh-pages/qrcode.min.js"></script>

<div id="qrcode"></div>
<script type="module">
    import { AddToWalletButton } from "https://sdk.neostore.cloud/scripts/molia/cinto@1/cinto.mjs";

    const button = new AddToWalletButton("molia", {
        passId: "KlnqcxVLA9pS4ol5"
    });

    const url = await button.getPassPageUrl();
    new QRCode(document.getElementById("qrcode"), url);
</script>
```

## Ajouter des informations d'analyse

Le bouton peut envoyer trois valeurs source qui seront visibles dans le `Carte:Installé` l'événement, le tableau de bord et l'API Insights.

* `balises`: liste des balises source. `utm_source` et `utm_campaign` sont ajoutés automatiquement.
* `moyen`: libellé de canal tel que `e-commerce` ou `compte`.
* `origine`: URL de la page source. Par défaut, l'URL de la page actuelle est utilisée sans paramètres de requête.

Toutes les valeurs sont facultatives.

```html
<div data-neostore-addToWalletButton
     data-neostore-src-tags="tag1,tag2"
     data-neostore-src-medium="e-commerce"
     data-neostore-src-origin="originA"
 ></div>
```

## Récupérer `passId` lorsque la carte existe déjà

Lorsque la carte existe déjà, le backend du site web peut d’abord la rechercher, puis afficher le bouton avec la valeur renvoyée `passId`.

{% stepper %}
{% step %}

### Créer une clé API

Créez une clé API dans la console d’administration avec `tenant.carte:read`.

Voir :[ Clé API](https://docs.thewalletcrew.io/api-reference/)
{% endstep %}

{% step %}

### Interroger le point de terminaison des cartes

Utilisez la clé d’identifiant configurée pour rechercher la carte.

Exemple :

```bash
curl --globoff -X GET \
  'https://app.neostore.cloud/api/<tenantId>/passes?pageIndex=0&pageSize=10&filter[0].field=identifiers.y2.customerId&filter[0].operator=equals&filter[0].value=04101234' \
  -H 'accept: application/json' \
  -H 'X-API-KEY: <apiKey>'
```

Résultat attendu :

```json
[
  {
    "id": "KlnqcxVLAxxxxxx",
    "passType": "user",
    "identifiers": {
      "y2.customerId": "04101234"
    }
  }
]
```

{% endstep %}

{% step %}

### Valider l’unicité

La recherche doit renvoyer une seule Carte.

Si aucune Carte n’est renvoyée, la Carte n’existe pas encore. Si plusieurs Cartes sont renvoyées, l’identifiant n’est pas assez unique pour la distribution sur le site web.
{% endstep %}

{% step %}

### Rendre le bouton avec `passId`

Une fois le `id` est connu, utilisez-le comme `passId` dans le bouton du site web.
{% endstep %}
{% endstepper %}

## Exemple d’intégration tierce

<details>

<summary><strong>Exemple d’enveloppe React</strong></summary>

```tsx
import { AddToWalletButton } from "@neostore/cinto";

const CintoMobileAddToWallet = React.forwardRef<
    HTMLButtonElement,
    BoxProps & {
        passId?: string;
    }
>(({ passId, ...props }, buttonRef) => {
    const localRef = useRef<HTMLButtonElement>(null);
    buttonRef = buttonRef || localRef;

    const ctaRef = useRef<HTMLDivElement>(null);
    const cintoButtonRef = useRef<AddToWalletButton>();

    useEffect(() => {
        cintoButtonRef.current = passId
            ? new AddToWalletButton(tenantId, {
                  passId,
              })
            : undefined;
        ctaRef.current && cintoButtonRef.current?.render(ctaRef.current);
        if (passId && cintoButtonRef.current) {
            cintoButtonRef.current?.perform();
        }
    }, [passId, tenantId]);

    return (
        <Box {...props}>
            <div ref={ctaRef} />
        </Box>
    );
});

export default CintoMobileAddToWallet;
```

</details>

## FAQ

<details>

<summary><strong>Le même bouton doit-il être réutilisé pour tous les clients ?</strong></summary>

Non. Le composant visuel peut être réutilisé, mais la Carte résolue doit changer selon le client, le billet ou le contexte de la carte-cadeau actuel.

</details>

<details>

<summary><strong>Faut-il utiliser `passId` ou `externalIdentifiers` ?</strong></summary>

Utilisez `passId` lorsque le backend connaît déjà la carte exacte. Utilisez `externalIdentifiers` lorsque la page dispose d’un identifiant stable et que la Carte doit être résolue dynamiquement.

</details>

<details>

<summary><strong>Plusieurs boutons peuvent-ils être rendus sur la même page ?</strong></summary>

Oui. C’est courant pour les listes de billets et de cartes-cadeaux. Chargez le SDK une seule fois, puis rendez un bouton par Carte.

</details>

<details>

<summary><strong>L’ordinateur de bureau peut-il afficher un code QR au lieu d’une redirection standard ?</strong></summary>

Oui. L’URL de Carte hébergée peut être utilisée pour afficher un code QR ou un autre CTA spécifique au bureau.

</details>

<details>

<summary><strong>Quand faut-il utiliser plutôt une intégration d’application native ?</strong></summary>

Utilisez une intégration native lorsque le flux Wallet démarre dans une application iOS ou Android. Pour ce modèle, voir [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1).

</details>


# Via e-mail

Envoyez le lien The Wallet Crew par e-mail pour inscrire les clients dans le portefeuille mobile

## Envoyez par e-mail des liens « Ajouter à Wallet »

L’e-mail est le moyen le plus simple de joindre les clients existants et de les amener dans Apple Wallet ou Google Wallet. Cela fonctionne bien pour les cartes de fidélité et d’adhésion, car les clients font déjà confiance à ce canal, et vous pouvez placer l’appel à l’action dans les parcours que vous utilisez déjà (bienvenue, confirmation d’achat, e-mails de service).

L’essentiel est de sécuriser les liens. Un lien Wallet est une action au porteur. Quiconque obtient l’URL peut essayer de l’ouvrir. Utilisez des URL signées ou des jetons, et évitez les données personnelles dans les paramètres de requête.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de distribution envoie « Votre carte de fidélité est prête » après l’inscription à la newsletter.
* Un opérateur de billetterie envoie un e-mail « Enregistrez votre billet » juste après l’achat.
* Une marque de luxe envoie « Ajouter votre carte client » après une visite en magasin, avec recueil du consentement.

</details>

### Ce dont vous avez besoin avant de commencer

Vous avez besoin d’un [modèle de Carte](https://docs.thewalletcrew.io/configuration/wallet/template-configuration/how-to-create-a-template) et un flux d’émission, ainsi qu’un moyen d’identifier le client. Dans la plupart des configurations, The Wallet Crew résout une Carte soit à partir d’un identifiant interne `carteId` ou à partir d’un identifiant externe provenant de votre CRM.

Vous avez aussi besoin d’une identité d’expéditeur à laquelle les clients font confiance et que les fournisseurs de boîtes aux lettres acceptent. Configurez cela une fois, y compris la configuration du domaine d’envoi, puis réutilisez-le dans tous les parcours.

{% hint style="info" %}
Si vous prévoyez d’envoyer depuis votre propre domaine, configurez SPF/DKIM et une politique DMARC. Cela améliore la délivrabilité et réduit le risque d’hameçonnage.
{% endhint %}

### Choisissez le bon flux d’e-mails

Il existe deux flux courants. Choisissez-en un selon que le client existe déjà dans votre base de données.

#### Flux A — Le client existe : téléchargement direct

Utilisez ceci lorsque le client a déjà un compte de fidélité (ou tout autre identifiant stable) et que vous souhaitez une installation en un seul toucher. L’e-mail contient une URL sécurisée qui ouvre la page de Carte The Wallet Crew et permet au client d’enregistrer la Carte.

Pour empêcher l’énumération d’identifiants, n’exposez pas des identifiants prévisibles comme un numéro de fidélité sans signature ni jeton. Cela suit le même principe que les liens Ajouter à Wallet signés décrits dans [Sécurité de la carte Wallet](https://docs.thewalletcrew.io/configuration/wallet/wallet-card-security).

**Exemple : lien de téléchargement direct signé (HMAC)**

Pour les clients qui existent déjà dans votre CRM (et que vous pouvez référencer en toute sécurité avec un identifiant interne), vous pouvez envoyer un lien qui renvoie directement à leur Carte.

Exemple :

`https://app.neostore.cloud/{tenantId}/pass?id.y2.customerId={customerId}&id.y2.customerId.hmac={hmac256(customerId,tenantSecret)}`

Gardez le `secret du locataire` côté serveur. Toute personne qui le possède peut générer des liens valides.

#### Flux B — Le client n’existe pas : inscription d’abord

Utilisez ceci lorsque votre liste d’e-mails est plus large que votre base de fidélité, ou lorsque vous avez besoin de données manquantes ou du consentement avant d’émettre une Carte. Le lien dirige le client vers un formulaire d’inscription, puis l’équipe Wallet délivre la Carte à la fin du parcours du formulaire.

Commencez ici : [Formulaire d'inscription](/guides-enrolment/fr/inscription/enrolment-form).

{% hint style="warning" %}
Évitez de mettre des données personnelles identifiables (PII) dans l'URL (e-mail, prénom, nom). Utilisez un jeton généré par votre backend et que votre formulaire peut valider.
{% endhint %}

**Exemple : client absent de votre CRM (préremplir le formulaire)**

Si le client ne se trouve pas encore dans votre CRM, vous pouvez utiliser le parcours d'inscription pour collecter les données manquantes, puis les envoyer à votre CRM. Certaines marques choisissent de préremplir le formulaire à l'aide de paramètres de requête provenant de leur outil de campagne e-mail.

Exemple (déconseillé) :

`https://app.neostore.cloud/{tenantId}/mobile?email=cyril@neostore.cloud&firstName=Cyril&lastName=DURAND`

{% hint style="danger" %}
Cette URL est **non signée**. N'importe qui peut modifier les paramètres de requête. Évitez cette configuration en production.
{% endhint %}

**Recommandé : lien d’inscription basé sur un jeton (aucune donnée personnelle dans l’URL)**

Utilisez un jeton pour sécuriser le lien. Cela évite d’exposer des données personnelles dans l’URL et réduit les risques de falsification.

En pratique, vous générez un jeton depuis The Wallet Crew (API ou back-office), vous le stockez dans votre audience d’e-mailing, puis vous l’insérez dans l’URL du CTA.

Exemple :

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

**Comment inclure les liens The Wallet Crew dans votre outil d’e-mailing**

Vous pouvez utiliser l’un des connecteurs partenaires de The Wallet Crew (par exemple Actito ou Klaviyo) ou votre propre plateforme (Mailchimp, Salesforce Marketing Cloud, Brevo/Sendinblue, etc.).

{% stepper %}
{% step %}

#### Générez le jeton

Générez le jeton avec l’API The Wallet Crew, ou générez-le manuellement depuis le back-office The Wallet Crew.

Utilisez une entrée stable (généralement un identifiant client ou une adresse e-mail), puis conservez le jeton opaque dans votre outil de campagne.
{% endstep %}

{% step %}

#### Stockez le jeton dans votre audience

Stockez le jeton dans votre base de données d’e-mailing en tant qu’attribut personnalisé, afin de pouvoir le fusionner dans l’URL du CTA.
{% endstep %}

{% step %}

#### Construisez l’URL du CTA

Utilisez un bouton comme « Ajouter à Wallet » et faites-le pointer vers une URL tokenisée :

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

Remplacez `{{profile.neostoreJwt}}` par la syntaxe de balises de fusion de votre outil.
{% endstep %}
{% endstepper %}

### Ajoutez le CTA à vos e-mails

En pratique, vous intégrez un lien derrière un bouton tel que « Ajouter à Wallet ». Vous pouvez le faire dans votre outil marketing (modèles de campagne) ou dans des e-mails transactionnels envoyés par The Wallet Crew.

#### Exemples de CTA

![Exemple de CTA e-mail : bouton « Ajouter à Wallet » dans un e-mail à l’identité de marque](/files/6b6e115004c8278dbeaf38109f937dadb6e3b57d)

*Utilisez un bouton très contrasté et gardez-le visible sans défilement sur mobile.*

![Exemple de CTA e-mail : lien « Ajouter à Wallet » présenté comme une action secondaire](/files/6b0de8a423d095f58dc7d01c854eb946e90275ab)

*Si vous avez plusieurs CTA, gardez le CTA Wallet visuellement distinct.*

### Gardez les liens sécurisés (règles recommandées)

Les liens signés et les jetons empêchent la falsification et réduisent le risque d’énumération de la Carte. Ils maintiennent également les données personnelles hors des URL qui peuvent être journalisées par des proxys, des scanners de boîtes mail ou des outils d’analyse.

Appliquez ces règles :

* Privilégiez un **identifiant opaque** (`carteId`) lorsque c’est possible.
* Lorsque vous devez utiliser un **identifiant externe**, protégez-le avec **HMAC**, un **jeton secret partagé**, ou un **JWT**.
* Conservez des durées de vie de jeton courtes pour les campagnes e-mail. Considérez le lien comme un mot de passe.
* Supposez que les e-mails peuvent être transférés. Si le transfert ne doit pas fonctionner, ajoutez une vérification par e-mail ou une autre étape de vérification dans le parcours.

Si un examen de sécurité plus approfondi est nécessaire, abordez HMAC, les jetons secrets partagés et JWT dans le cadre de la conception du lien. [Sécurité de la carte Wallet](https://docs.thewalletcrew.io/configuration/wallet/wallet-card-security) est la source de vérité. Pour des contrôles organisationnels plus larges, consultez le [plan d’assurance sécurité](https://docs.thewalletcrew.io/policies/privacy-and-security/security-insurance-plan).

### Segmentez vos envois et mesurez l’adoption

L’e-mail fonctionne mieux lorsque vous n’inondez pas de messages les clients qui ont déjà installé la Carte. Segmentez selon le statut « Carte installée » lorsque c’est possible, puis ciblez uniquement les clients qui ne l’ont pas encore installée.

Si le statut d’installation doit être synchronisé vers le CRM, utilisez les flux d’événements et d’intégration disponibles.

Vous pouvez également marquer les installations pour l’attribution. Si vous distribuez via des pages web, voyez comment le marquage fonctionne avec `neo.src` sur [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website).

### Outils et connecteurs pris en charge

Vous pouvez envoyer des e-mails depuis votre propre plateforme d’e-mailing et intégrer des liens Wallet Crew dans vos modèles. Vous pouvez également configurer The Wallet Crew pour envoyer des e-mails transactionnels dans le cadre des parcours d’inscription et de vérification.

Voir : [Connecteurs](/guides-enrolment/fr/inscription/via-email/connectors).

## FAQ

<details>

<summary><strong>Pouvons-nous lancer des campagnes marketing avec ces liens ?</strong></summary>

Oui. Utilisez votre plateforme marketing pour envoyer la campagne et intégrez un lien Wallet Crew sécurisé derrière votre CTA.

Si The Wallet Crew envoie des e-mails pour les parcours d’inscription et de vérification, configurez d’abord l’identité de l’expéditeur et la configuration du domaine.

</details>

<details>

<summary><strong>Dois-je inclure l’e-mail ou le nom du client dans l’URL ?</strong></summary>

Évitez-le. Les URL sont souvent journalisées et analysées. Utilisez un jeton et laissez The Wallet Crew (ou votre backend) résoudre le client côté serveur.

</details>

<details>

<summary><strong>Que se passe-t-il si un client transfère l’e-mail ?</strong></summary>

Si le lien est un jeton au porteur, le destinataire transféré peut essayer de l’ouvrir. Si vous devez empêcher cela, utilisez un jeton à courte durée de vie et ajoutez une étape de vérification (défi par e-mail) avant d’émettre ou de révéler la Carte.

</details>

<details>

<summary><strong>Comment éviter d’envoyer des e-mails aux clients qui ont déjà installé la Carte ?</strong></summary>

Segmentez votre audience selon l’état d’installation, puis ciblez uniquement les profils « non installés ». Si les données doivent remonter dans le CRM, utilisez les événements de statut d’installation dans la configuration de l’intégration.

</details>

<details>

<summary><strong>Où cela doit-il se trouver : e-mail, site web ou application mobile ?</strong></summary>

Utilisez l’e-mail lorsque vous disposez déjà d’une adresse client et que vous voulez un parcours de conversion à faible effort.

Utilisez le web lorsque la Carte est installée depuis une zone connectée ou le tunnel de paiement : [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website).

Utilisez l’application native lorsque vous avez une application et que vous voulez l’UX la plus rapide : [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1).

</details>


# Connecteurs

Connectez des fournisseurs d’e-mail et des plateformes marketing pour envoyer des liens Wallet sécurisés.

Utilisez cette documentation lorsque vous souhaitez envoyer des e-mails depuis vos propres outils, tout en utilisant dans vos modèles des liens sécurisés The Wallet Crew.

Si vous souhaitez que The Wallet Crew envoie des e-mails transactionnels (inscription, vérification, livraison de Carte), commencez par [Fournisseur d'e-mails](https://github.com/TheWalletCrew/docs/blob/main/guides/documentation/connectors/email-provider/README.md).

### Connecteurs d'e-mails transactionnels (The Wallet Crew envoie)

* [SendGrid](https://github.com/TheWalletCrew/docs/blob/main/guides/documentation/connectors/email-provider/sendgrid.md)
* [Mailchimp](https://github.com/TheWalletCrew/docs/blob/main/guides/documentation/connectors/email-provider/mailchimp.md) (Transactionnel / Mandrill)
* [Salesforce Marketing Cloud](https://github.com/TheWalletCrew/docs/blob/main/guides/connect/email-provider/salesforce-marketing-cloud.md)
* [Adobe Marketing Cloud](https://github.com/TheWalletCrew/docs/blob/main/guides/connect/email-provider/adobe-marketing-cloud.md)

### Outils marketing (vous envoyez, vous intégrez des liens)

Ces intégrations sont généralement utilisées pour orchestrer des parcours et la personnalisation. Vous gardez un contrôle total sur la délivrabilité et les performances des campagnes, et vous placez les liens The Wallet Crew derrière vos CTA.

* [Actito](https://github.com/TheWalletCrew/docs/blob/main/guides/integrate/marketing-automation/actito.md)
* [Klaviyo](https://github.com/TheWalletCrew/docs/blob/main/guides/connect/marketing-automation/klaviyo/README.md)


# Dans votre application mobile

Ajouter « Ajouter à Wallet » dans une application native à l’aide de charges utiles côté serveur pour Apple Wallet et Google Wallet.

Facilitez l’installation de Cartes Wallet directement depuis votre application mobile. Au lieu de rediriger les utilisateurs ailleurs, votre application garde le contrôle de l’identité, des droits et des données, tandis que Wallet offre un accès instantané aux Cartes hors ligne, les affiche au bon moment et les met à jour en temps réel. L’installation dans l’application garantit une expérience rapide et pratique que les utilisateurs peuvent présenter en magasin ou lors d’un événement sans avoir à rouvrir votre application.

<figure><img src="/files/317ce9ccfa42d8f62b189bb135c5751277ea7575" alt="Mobile App Add To Wallet SDK integration"><figcaption></figcaption></figure>

## Ajouter à Wallet depuis votre application mobile

Sur Apple Wallet comme sur Google Wallet, le flux est cohérent. Votre application détecte si la Carte est déjà installée, affiche le bon bouton « Ajouter à Wallet », et lance le flux d’enregistrement système lorsque c’est nécessaire.

{% hint style="info" %}
Votre application ne peut pas forcer l’installation. L’utilisateur doit toujours confirmer dans l’interface système.
{% endhint %}

### L’application native et Wallet sont complémentaires

Un Wallet ne remplace pas votre application native. Ils répondent à des besoins différents et fonctionnent mieux ensemble. Wallet se concentre sur la présentation et la praticité. Il offre un accès rapide, une utilisation hors ligne et un stockage au niveau du système d’exploitation. Il peut également afficher les Cartes au bon moment (écran verrouillé, heure, localisation).

Votre application gère les comptes, l’authentification, les paramètres et l’ensemble des fonctionnalités. The Wallet Crew est l’endroit où les Cartes sont créées, actualisées et révoquées.

### Pourquoi inclure « Add to Wallet » dans votre application

Ajouter le bouton réduit les frictions aux points de contact réels. Les utilisateurs installent la Carte en une seule pression, puis la présentent sans rouvrir l’application. Cela compte quand la file est longue et que le réseau est faible.

Wallet garde aussi la Carte accessible pendant des mois, et elle peut le rester même si l’application est désinstallée plus tard. Côté analytique, vous pouvez mesurer l’adoption et la performance des emplacements en étiquetant les installations avec `neo.src`.

<details>

<summary>Exemples concrets</summary>

Voici des exemples de ce qu’une Carte peut débloquer une fois qu’elle est dans Wallet :

* Adhésion : « Livraison gratuite » sur chaque commande en ligne.
* Commerce de détail : « 10 % de réduction sur tous les achats » pendant toute la saison.
* Billetterie événementielle : « Entrée coupe-file » disponible pour cet événement.
* Billetterie événementielle : « Surclassement de siège » appliqué automatiquement lorsqu’il est disponible.
* Service : « Assistance prioritaire » disponible pour chaque demande de ticket.

</details>

### Flux type de bout en bout

Les détails de la plateforme diffèrent, mais le flux produit reste le même. L’utilisateur se connecte, appuie sur le bouton et votre application appelle votre backend. Votre backend récupère la bonne Carte depuis The Wallet Crew et renvoie une charge utile d’installation adaptée à l’appareil (Apple `.pkpass` ou un JWT Google). L’application ouvre ensuite l’interface native d’enregistrement du Wallet, et vous suivez les installations via les événements de Wallet Crew.

{% @mermaid/diagram content="sequenceDiagram autonumber actor User participant App as Application mobile participant Backend as Votre backend participant TWC as backend de The Wallet Crew participant Wallet as Apple/Google Wallet (interface système)"

```
User->>App: Appuyer sur « Ajouter à Wallet »
App->>Backend: Demander la charge utile d’installation (contexte utilisateur + appareil)

Backend->>TWC: Résoudre passId (recherche par identifiant externe)
TWC-->>Backend: passId

Backend->>TWC: Récupérer la charge utile d’installation (passId + appareil + neo.src)
TWC-->>Backend: Apple .pkpass OU JWT Google

Backend-->>App: Retourner la charge utile d’installation
App->>Wallet: Lancer le flux d’enregistrement système
Wallet-->>User: Aperçu + confirmation
User->>Wallet: Confirmer l’installation

Wallet->>TWC: Enregistrer l’installation (callback du fournisseur)
TWC-->>Backend: (Facultatif) événement Carte:Installed (webhook)" %}
```

{% hint style="warning" %}
N’appelez jamais les API de The Wallet Crew depuis le client mobile avec une clé API. Conservez les secrets uniquement sur votre backend.
{% endhint %}

### Apple Wallet contre Google Wallet

Votre application mobile utilise l’interface native du Wallet, mais elle ne communique jamais directement avec The Wallet Crew au moyen d’une clé API. Votre backend est le seul composant qui appelle **le backend de The Wallet Crew** pour résoudre `passId` et générer la charge utile d’installation.

{% tabs %}
{% tab title="Apple Wallet (iOS)" %}
Apple Wallet utilise un **lot de Cartes signé**.

Votre backend demande une charge utile d’installation Apple au backend de The Wallet Crew. Il renvoie un `.pkpass`.

Votre application iOS télécharge le `.pkpass` et le présente avec PassKit. iOS affiche la feuille d’aperçu standard, et l’utilisateur confirme l’installation. La Carte est ensuite stockée localement sur l’appareil.

Utilisez le libellé « Add to Apple Wallet ».
{% endtab %}

{% tab title="Google Wallet (Android)" %}
Google Wallet utilise **des objets liés au cloud**.

Votre backend demande une charge utile d’installation Google au backend de The Wallet Crew. Il renvoie une charge utile d’enregistrement, généralement un JWT, pour le flux d’enregistrement de Google Wallet.

Votre application Android lance l’interface d’enregistrement Google. L’utilisateur confirme l’installation. La Carte est liée au compte Google de l’utilisateur et peut se synchroniser entre les appareils.

Utilisez le libellé « Add to Google Wallet ».
{% endtab %}
{% endtabs %}

## Comment l’implémenter

Votre tenant doit être prêt pour Apple Wallet et/ou Google Wallet, et vous devez déjà disposer d’un [modèle](https://docs.thewalletcrew.io/configuration/wallet/template-configuration/how-to-create-a-template) et un flux d’émission. Vous avez aussi besoin d’un backend que votre application peut appeler, car les secrets et la recherche de Cartes doivent rester côté serveur.

#### Architecture de haut niveau

À haut niveau, votre backend résout un identifiant stable en un passId `passId`, puis appelle les API de The Wallet Crew à l’aide de `X-API-KEY`. Votre application ne reçoit que la charge utile d’installation spécifique au fournisseur et installe la Carte à l’aide des API natives du Wallet.

#### Étape par étape

{% stepper %}
{% step %}

### Créez une clé API (backend uniquement)

Créez une clé API dans la console d’administration.\
Appliquez le principe du moindre privilège.\
Conservez-la uniquement sur le backend.

Vous l’enverrez sous la forme :

`X-API-KEY: <your_api_key>`
{% endstep %}

{% step %}

### Résolvez le passId sur votre backend

Utilisez votre propre identifiant stable.\
Exemples : identifiant de fidélité, identifiant client, identifiant de billet.

Appelez le point de terminaison de liste des Cartes avec un filtre.

Exemple (recherche par `identifiers.ur.customerId`):

```bash
curl --globoff -X GET \\
  'https://app.neostore.cloud/api/<tenantId>/passes?pageIndex=0&pageSize=10&filter[0].field=identifiers.ur.customerId&filter[0].operator=equals&filter[0].value=<customerId>' \\
  -H 'accept: application/json' \\
  -H 'X-API-KEY: <your_api_key>'
```

Adaptez `filter[0].field` à votre propre clé d’identifiant.\
Les clés typiques ressemblent à `identifiers.<namespace>.<name>`.

Vous obtiendrez un tableau JSON contenant la Carte `id`.\
C’est `id` l’ `passId` id que vous utiliserez ensuite.
{% endstep %}

{% step %}

### Générez une « charge utile d’installation » spécifique au fournisseur

Une fois que vous avez `passId`, demandez la charge utile pour l’appareil cible. Apple renvoie un `.pkpass` fichier téléchargeable, et Google renvoie un jeton JWT. Un modèle de point de terminaison typique ressemble à ceci :

`GET https://app.neostore.cloud/api/<tenantId>/passes/<passId>?device=<apple|google>&neo.src=<tracking>`

{% hint style="info" %}
`neo.src` est utilisé pour le suivi et l’attribution.\
Format : `<medium>|<tag1>,<tag2>|<originUrl>`.
{% endhint %}
{% endstep %}

{% step %}

### Installez la Carte depuis l’application

Utilisez les SDK natifs du Wallet. Sur iOS, téléchargez le `.pkpass` et présentez l’interface « Add to Apple Wallet ». Sur Android, transmettez le JWT au flux d’enregistrement de Google Wallet.

Docs du fournisseur :

{% embed url="<https://developer.apple.com/documentation/passkit/pkaddpassbutton/>" %}

{% embed url="<https://developers.google.com/wallet/retail/loyalty-cards/android>" %}
{% endstep %}

{% step %}

### Suivez les installations et gérez les réinstallations

Utilisez les événements de Wallet Crew pour mesurer l’adoption et les sources. En pratique, vous associez à chaque emplacement dans l’application `neo.src` (profil, paiement, onboarding) et vous abonnez à `Carte:Installed` les événements (webhook) ou interrogez l’adoption via Insights.
{% endstep %}
{% endstepper %}

## FAQ

<details>

<summary>Puis-je mettre la clé API dans l’application mobile ?</summary>

Non. Traitez les clés API comme des mots de passe. Placez les appels API derrière votre backend.

</details>

<details>

<summary>L’application peut-elle appeler directement le point de terminaison « charge utile d’installation » ?</summary>

Oui, si vous utilisez seulement un `passId` et que vous **n’** utilisez pas de clé API. C’est généralement sûr parce que `passId` est opaque et impossible à deviner.

Ne **pas** implémentez la recherche de Carte (par identifiant client) côté client.

</details>

<details>

<summary>Dois-je utiliser les flux Wallet natifs ou le SDK du site web dans une application mobile ?</summary>

Dans une application mobile, privilégiez **les flux natifs de Wallet**. Ils offrent la meilleure UX et le moins de friction. Ils évitent également les redirections web.

Utilisez le **SDK du site web** lorsque vous distribuez depuis des pages web, ou lorsque vous avez besoin d’un QR de secours sur ordinateur.

Voir : [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website)

</details>

<details>

<summary>Comment dois-je intégrer « Add to Wallet » dans une application Flutter ?</summary>

Ce modèle fonctionne bien dans Flutter. Conservez la recherche de Cartes et la génération de la charge utile sur votre backend, puis déclenchez les flux natifs d’enregistrement Wallet iOS/Android depuis Flutter.

</details>

<details>

<summary>Comment dois-je intégrer « Add to Wallet » dans une application React Native ?</summary>

Utilisez des modules natifs ou une bibliothèque Wallet maintenue, puis lancez le flux d’enregistrement natif sur chaque plateforme. Un bon point de départ pratique est : <https://habr.com/en/articles/858858/>

</details>

<details>

<summary>Apple contre Google : que reçois-je ?</summary>

Apple Wallet renvoie un `.pkpass` fichier. Google Wallet renvoie un JWT. Votre backend doit choisir la bonne charge utile pour chaque appareil.

</details>

<details>

<summary>Et si la Carte n’existe pas encore ?</summary>

Créez-la d’abord, puis relancez le même flux pour récupérer la `passId` et la charge utile d’installation.

</details>


# Guides d'engagement et d'animation

Une Carte qui reste simplement dans un Wallet est une occasion manquée. Les outils Engage & animate transforment chaque Carte en point de contact actif — en récompensant la fidélité, en mettant en avant des offres opportunes et en atteignant les clients exa

## Animation & engagement : étape par étape

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4><i class="fa-location-crosshairs" style="color:$primary;">:location-crosshairs:</i></h4></td><td><h3>Notifications géolocalisées</h3></td><td><p>Afficher un message contextuel à proximité d’un lieu lorsqu’un client est à proximité, pour des rappels, des informations sur site ou des alertes de magasin/d’établissement.</p><p><br></p></td><td><a href="/files/2e952cebc18b0cd5d4043623349235852be29cca">/files/2e952cebc18b0cd5d4043623349235852be29cca</a></td><td><a href="/pages/153a09e859248337a7f4e8eb8ef310f36b1414db">/pages/153a09e859248337a7f4e8eb8ef310f36b1414db</a></td></tr><tr><td><h4><i class="fa-arrows-from-line" style="color:$primary;">:arrows-from-line:</i></h4></td><td><h3>Privilège &#x26; animation</h3></td><td>Gérer la manière dont les avantages client, les récompenses et les privilèges de Carte sont activés et mis en avant dans Apple Wallet et Google Wallet.</td><td><a href="/files/db277c7a3a7696ab871ac6fd0a7c8497e781ba02">/files/db277c7a3a7696ab871ac6fd0a7c8497e781ba02</a></td><td><a href="/pages/4398f1f9dbfb322d10e914afe51b7b1401c4eb06">/pages/4398f1f9dbfb322d10e914afe51b7b1401c4eb06</a></td></tr><tr><td><h4><i class="fa-exclamation" style="color:$primary;">:exclamation:</i></h4></td><td><h3>Notifications push</h3></td><td>Comparez les notifications push d’Apple Wallet et de Google Wallet : déclencheurs, limites et cas d’usage courants avec The Wallet Crew.</td><td><a href="/files/8d96b76ee680406e2502ad68eabe9bf9a7c0d252">/files/8d96b76ee680406e2502ad68eabe9bf9a7c0d252</a></td><td><a href="/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe">/pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe</a></td></tr></tbody></table>

**Les privilèges et les activations vous permettent de transformer une Carte statique en un outil d’engagement vivant.** Un privilège est un avantage attaché à une Carte individuelle — une remise, un article gratuit, une récompense déverrouillable, un compteur de tampons — qui peut être ajouté, mis à jour ou supprimé à tout moment sans rééditer la Carte. Quatre types de comportement couvrent pratiquement tous les scénarios de fidélité ou de campagne : OneTime (utilisable une seule fois), Unlimited (toujours disponible tant qu’il est valide), MultiUse (un nombre limité d’utilisations) et Unlockable (dévoilé une fois qu’une condition ou un seuil de progression est atteint). Chaque Carte peut comporter jusqu’à cinq privilèges à la fois, avec des règles de priorité qui résolvent automatiquement tout conflit.

**Les privilèges peuvent provenir de n’importe où dans votre pile.** Ils sont générés en interne par des activations, envoyés de l’extérieur via des connecteurs marketing comme Salesforce Marketing Cloud ou Bloomreach, ou créés et mis à jour directement via l’API. Chaque privilège possède sa propre apparence (image, couleurs), son contenu (titre, description), ses liens d’appel à l’action et un historique de valeur basé sur les mouvements — ce qui facilite le suivi des soldes, de la progression ou des codes de redemption au fil du temps. Des billets d’événements avec accès afterparty déverrouillable, aux cartes de fidélité avec remises par paliers, en passant par les cartes-cadeaux avec soldes utilisables et les cartes d’adhésion avec quotas mensuels, les privilèges s’adaptent à n’importe quel cas d’usage réel tout en laissant la Carte principale intacte.

**Les notifications push complètent la boucle d’engagement**, avec une diffusion native en temps réel sur Apple Wallet et Google Wallet. Les notifications Apple sont liées aux mises à jour de la Carte et apparaissent directement sur l’écran de verrouillage avec le contenu complet du message ; Google Wallet offre une messagerie plus flexible, à la demande — y compris des liens cliquables et des blocs de contenu riches « Value-Added » — dans la limite de 3 par jour. Les notifications peuvent être déclenchées par la géolocalisation, des dates planifiées ou des événements provenant de systèmes connectés (CRM, POS, billetterie), offrant aux marques un moyen unique et unifié de tenir les clients informés et engagés directement depuis leur Wallet.


# Notifications géolocalisées

Affichez un message de Carte lorsqu'un client se trouve à proximité d'un emplacement configuré (magasin ou lieu).

Les notifications géolocalisées affichent un message contextuel à proximité d’un lieu. Apple Wallet ou Google Wallet peuvent l’afficher lorsqu’un client se trouve à proximité. Utilisez-le pour des rappels (« n’oubliez pas votre carte ») et des informations sur place (« la porte d’accès a changé »).

<figure><img src="/files/424a471693d49f232f49e1adc12fe28a2f1489e3" alt=""><figcaption></figcaption></figure>

Cela fonctionne pour **les magasins et tout type de lieu**. Exemples typiques de lieux : stades, salles de concert, théâtres et pop-ups.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Rappelez aux membres du programme de fidélité de scanner leur carte en caisse.
* Afficher un rappel de bon uniquement si un bon est disponible.
* Annoncez l’ouverture d’un magasin aux clients à proximité de ce lieu.
* Rappelez aux détenteurs de billets les informations de porte d’accès lorsqu’ils approchent du lieu.
* Afficher un message « votre billet est prêt » près de l’entrée du lieu.

</details>

{% hint style="info" %}
Les notifications géolocalisées n’apparaissent que si le client active les fonctions de localisation pour son application Wallet.

Sur iOS : **Réglages → Confidentialité et sécurité → Services de localisation → Wallet**.

Sur Android : vérifiez les autorisations Google Wallet sur votre appareil **Paramètres** (la localisation doit être autorisée).
{% endhint %}

## Comment ça fonctionne

Les cartes Wallet peuvent stocker un petit ensemble de lieux de « pertinence ». Le téléphone compare la position de l’appareil à ces lieux. Lorsque le client entre dans le rayon configuré, l’application Wallet peut afficher la carte et son message.

The Wallet Crew configure ces lieux sur la carte en fonction de votre jeu de données de localisation. La plupart des marques utilisent les adresses des magasins. Pour les lieux, vous modélisez généralement le lieu comme un enregistrement « magasin » afin qu’il puisse être géolocalisé de la même manière.

### Ce que les clients verront (varie selon la plateforme)

{% tabs %}
{% tab title="Apple Wallet (iOS)" %}
iOS peut afficher une suggestion sur l’écran de verrouillage lorsque le client se trouve à proximité de l’un des lieux configurés. La suggestion peut inclure le message que vous avez configuré.
{% endtab %}

{% tab title="Google Wallet (Android)" %}
Android peut afficher une expérience de « carte à proximité » lorsque le client se trouve près de l’un des lieux configurés. L’interface exacte dépend de la version d’Android et du fabricant de l’appareil.
{% endtab %}
{% endtabs %}

### Limites à prendre en compte

Les limites de la plateforme suivantes s’appliquent :

* Jusqu’à **10 coordonnées GPS** par carte.
* Jusqu’à **rayon de 300 m** par coordonnée.

L’affichage du message est contrôlé par le système d’exploitation. En pratique, le message peut rester visible tant que le client reste dans la zone.

### Géolocalisation vs « notifications push »

Les notifications géolocalisées ne sont pas « envoyées » à un moment précis par The Wallet Crew. Elles sont déclenchées par le téléphone du client lorsqu’il détecte une proximité.

Si vous avez besoin d’un message déclenché par le serveur, utilisez plutôt les notifications Wallet standard. Commencez par [Notifications push](broken://pages/1ec223daf5676ffa67fcbfcf223c905689b40dbe).

## Prérequis

Vous devez configurer les lieux (adresses) dans The Wallet Crew. La plateforme utilise ces adresses pour calculer les coordonnées GPS.

Les lieux sont gérés via le **jeu de données Stores** . Vous pouvez l’utiliser pour les magasins de détail et pour les lieux. Exemple : créez une entrée de magasin pour `Stadium - Gate A` ou `Salle de concert - Entrée principale`.

Si vous n’avez pas encore configuré de lieux, commencez par [jeu de données Stores](https://docs.thewalletcrew.io/guides-enrolment).

<div data-with-frame="true"><figure><img src="/files/d42389eae5e22f13a153df5e62ec7d8549bb6f76" alt="The Wallet Crew back office showing store and address configuration"><figcaption><p>Les adresses servent à calculer les coordonnées GPS (magasins ou lieux).</p></figcaption></figure></div>

## Configurez le message dans The Wallet Crew

Configurez le message directement sur le modèle de carte. Utilisez Liquid si vous avez besoin de personnalisation.

{% stepper %}
{% step %}

#### Ouvrez les paramètres de notification d’un modèle

Accédez à **Modèles**. Ouvrez le modèle **menu Plus d’options** puis sélectionnez **Notifications**.
{% endstep %}

{% step %}

#### Rédigez le message (onglet Notification géolocalisée)

Ouvrez l’onglet **Notification géolocalisée** . Rédigez votre message. Ajoutez des variables Liquid si nécessaire.

Restez concis. Visez **≤ 140 caractères** pour éviter le tronquage.
{% endstep %}

{% step %}

#### Configurez les traductions (facultatif)

Si votre modèle est traduit, mettez à jour le message de notification géolocalisée pour chaque langue.
{% endstep %}

{% step %}

#### Enregistrez et testez

Cliquez sur **Envoyer la notification** pour enregistrer. Testez ensuite avec un appareil près d’un lieu configuré.

Validez à la fois le comportement de localisation et le rendu Liquid.
{% endstep %}
{% endstepper %}

<div data-with-frame="true"><figure><img src="/files/3f2f5c5c1648e18b3a1b1e69466ce201430f447d" alt="Notification configuration screen showing the Geo notification tab"><figcaption><p>Les messages de notification géolocalisée sont configurés par modèle et peuvent être traduits.</p></figcaption></figure></div>

## Comment The Wallet Crew sélectionne les lieux par client

La logique de sélection des lieux dépend de votre cas d’usage. Les programmes de fidélité reposent généralement sur la logique du « magasin principal ». Les billets d’événement reposent généralement sur le lieu que vous attribuez à la carte.

Pour une configuration de type commerce de détail, les notifications géolocalisées sont généralement calculées pour :

* le **magasin principal**.
* du client **9 lieux les plus proches** de ce magasin principal (ou de l’adresse du client).

Cela maintient la carte dans la limite de 10 lieux tout en couvrant les lieux proches.

## Mises à jour automatiques des coordonnées des lieux

Lorsque vous effectuez une mise à jour de carte via The Wallet Crew, les coordonnées des lieux peuvent être recalculées :

* Si le magasin principal du client change, la liste des « lieux les plus proches » est recalculée.
* Si l’adresse du client change, la liste des « lieux les plus proches » est recalculée.
* Si vous ajoutez de nouveaux magasins (avec une adresse), ils peuvent devenir éligibles comme « lieux les plus proches ».

Cela aligne les déclencheurs de localisation sur vos données de localisation les plus récentes.

## Exemples Liquid pour les messages de notification géolocalisée

Utilisez Liquid pour afficher un message uniquement aux clients concernés. Les entrées typiques sont les identifiants de magasin, les données de profil client et la disponibilité de bons.

{% code title="Exemple 1 — afficher un rappel de bon uniquement si un bon existe" %}

```liquid
{%- if y2.bons.loyaltyCertificates.size > 0 -%}
Votre bon de fidélité de 20 € est disponible. Utilisez-le aujourd’hui en magasin.
{%- else -%}
N’oubliez pas de scanner votre carte de fidélité en caisse.
{%- endif -%}
```

{% endcode %}

{% code title="Exemple 2 — message spécifique au magasin" %}

```liquid
{%- if storeId == "013" -%}
Ce magasin est définitivement fermé. Rendez-vous dans nos autres magasins à proximité.
{%- else -%}
Bon retour parmi nous. Votre magasin est à proximité. Venez découvrir nos dernières nouveautés.
{%- endif -%}
```

{% endcode %}

## FAQ

<details>

<summary><strong>Peut-on suivre combien de clients ont reçu le message géolocalisé ?</strong></summary>

Non. Ce n’est pas un message que The Wallet Crew envoie activement à un moment donné. C’est le téléphone du client qui le déclenche localement lorsqu’il s’approche des coordonnées configurées.

</details>

<details>

<summary><strong>Sait-on si le client se trouve à l’intérieur du magasin ou du lieu ?</strong></summary>

Non. Les déclencheurs de géolocalisation n’envoient pas d’événements « entré » ou « en magasin » vers The Wallet Crew.

</details>

<details>

<summary><strong>Pourquoi la notification géolocalisée n’est-elle pas apparue sur un iPhone ?</strong></summary>

Commencez par les réglages iOS. Le client doit autoriser l’accès à la localisation pour Wallet dans **Réglages → Confidentialité et sécurité → Services de localisation → Wallet**.

Validez ensuite les données de la carte. La carte doit inclure des coordonnées de localisation. Le client doit être suffisamment proche du rayon configuré.

</details>

<details>

<summary><strong>Pourquoi la notification géolocalisée n’est-elle pas apparue sur Android (Google Wallet) ?</strong></summary>

Commencez par les paramètres Android. L’utilisateur doit autoriser les fonctions de localisation pour Google Wallet (et ne pas les restreindre via les paramètres de confidentialité du système).

Validez ensuite les données de la carte. La carte doit inclure des lieux, et le client doit être suffisamment proche pour les déclencher.

</details>

<details>

<summary><strong>Quel est le délai entre deux notifications géolocalisées ?</strong></summary>

Le système d’exploitation affiche généralement le message lorsque le client entre dans la zone configurée. Il peut disparaître lorsqu’ils en sortent. Il peut réapparaître la prochaine fois qu’ils y entrent.

Référence Apple : [Afficher une carte sur l’écran de verrouillage](https://developer.apple.com/documentation/walletpasses/showing-a-pass-on-the-lock-screen).

</details>

<details>

<summary><strong>Comment les 10 lieux sont-ils sélectionnés pour un client ?</strong></summary>

Chaque client a un magasin principal. The Wallet Crew sélectionne les 9 lieux les plus proches de ce magasin principal, pour un total de 10.

</details>

<details>

<summary><strong>Est-ce la même chose que les notifications basées sur des balises ?</strong></summary>

Non. Les balises utilisent Bluetooth (identifiants iBeacon). Les notifications géolocalisées utilisent des coordonnées GPS.

Apple Wallet prend aussi en charge les déclencheurs de balises. Si vous prévoyez de les utiliser, vérifiez d’abord vos appareils cibles et les contraintes matérielles des magasins.

</details>


# Privilège et activation

Le privilège et l'activation couvrent la manière dont les avantages spécifiques à un client sont reflétés sur une Carte, et comment ces avantages passent de « disponibles » à « actifs ».

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4><i class="fa-gift" style="color:$primary;">:gift:</i></h4></td><td><h3>Privilège</h3></td><td>Définissez les avantages client sur chaque Carte, des remises aux niveaux, soldes, avantages et récompenses échangeables.</td><td><a href="/files/8ac1c230d33d17de52c8f529dd8fcb68ee897669">/files/8ac1c230d33d17de52c8f529dd8fcb68ee897669</a></td><td><a href="/pages/bf4b5db1856c102e5c951585210c931d2cfc1706">/pages/bf4b5db1856c102e5c951585210c931d2cfc1706</a></td></tr><tr><td><h4><i class="fa-bolt" style="color:$primary;">:bolt:</i></h4></td><td><h3>Activation</h3></td><td>Déclenchez les privilèges à grande échelle à l’aide de segments, de calendriers ou d’événements, puis mettez à jour automatiquement et instantanément les Cartes éligibles.</td><td><a href="/files/1bdca2d8f7d8717048a78dec8ec8abf251731e21">/files/1bdca2d8f7d8717048a78dec8ec8abf251731e21</a></td><td><a href="/pages/e3e312c9eda6125174d237a616088175b8fef12f">/pages/e3e312c9eda6125174d237a616088175b8fef12f</a></td></tr></tbody></table>

**Privilège** se concentre sur ce qu’une Carte *affiche*: niveaux, statuts, remises, soldes de points ou avantages spéciaux liés au profil d’un client. Il s’agit de la couche de données — la manière dont les informations sur les privilèges sont calculées, stockées et présentées sous forme de champs visibles sur la Carte, et dont elles se mettent à jour au fil du temps à mesure que le statut d’un client évolue (par exemple, en passant de Silver à Gold).

**Activation** se concentre sur *le déclenchement* de ces privilèges : le mécanisme qui transforme un avantage stocké en quelque chose que le client peut réellement utiliser, que ce soit via une action manuelle, une mise à jour de la Carte via l’API ou une condition basée sur une règle (seuil d’achat, date, événement). Cela couvre probablement aussi la manière dont l’état d’activation est reflété sur la Carte (badges, champs ou indicateurs visuels).

Ensemble, ces deux pages expliquent la boucle : un privilège est défini et stocké, puis activé et reflété sur la Carte — comblant ainsi l’écart entre les données client du backend et ce qui apparaît dans Apple Wallet ou Google Wallet.


# Privilège

Définissez et gérez les privilèges de Carte (avantages) dans The Wallet Crew : types, sources de création, règles de priorité et état d'utilisation basé sur les déplacements.

A **privilège** Un privilège est un avantage rattaché à une seule carte numérique. Il définit ce que le détenteur peut faire, réclamer ou débloquer. Les privilèges sont distincts de la carte elle-même. Vous pouvez les ajouter, les mettre à jour ou les supprimer sans réémettre la carte.

### Pourquoi les privilèges sont importants

Les privilèges sont importants car ils transforment une simple carte en un puissant outil d'engagement et de fidélisation. Une carte seule donne l'accès, mais un privilège donne aux clients une raison de s'intéresser, d'interagir et de revenir. C'est la différence entre un billet standard et une expérience qui paraît personnelle, gratifiante et mémorable.

Ils sont importants pour le marketing car ils créent des occasions de ravir les clients, de générer des revenus incrémentaux et d'encourager des comportements bénéfiques pour la marque. En proposant des extras comme des remises, des articles gratuits ou des avantages exclusifs, les privilèges rendent chaque interaction plus précieuse et renforcent la relation entre le client et la marque.

Enfin, les privilèges apportent de la flexibilité et de la créativité aux campagnes. Les marques peuvent créer des combinaisons d'avantages uniques, cibler différents segments de clientèle ou ajouter des récompenses à durée limitée, le tout sans modifier la carte principale. Cela facilite l'innovation, les tests d'idées et la création de moments qui transforment un accès ordinaire en expériences significatives.

### Comment fonctionnent les privilèges

Les privilèges ont un type comportemental :

* **Une seule fois**: à utiliser une seule fois, puis il disparaît.
* **Illimité**: toujours disponible tant qu'il est valide.
* **Multi-utilisation**: nombre d'utilisations limité.
* **Déblocable**: n'apparaît qu'une fois la progression terminée ou les conditions remplies.

Cela correspond directement à des avantages concrets. Boisson gratuite, remise de 10 %, 5 entrées, récompenses à débloquer en fonction des dépenses.

### Comment les privilèges sont ajoutés à une carte

Les privilèges sont créés de différentes façons. Ils peuvent être générés **en interne** par la plateforme via [activations](/guides-animation/fr/engagement-et-animation/privilege-and-activation/activation). Ils peuvent aussi être créés **à l'externe** via des connecteurs comme [SFMC](https://docs.thewalletcrew.io/configuration) ou [Bloomreach](https://docs.thewalletcrew.io/configuration) ou directement via [API](https://docs.thewalletcrew.io/api-reference).

Une carte peut contenir jusqu'à **5 privilèges** en même temps. En cas de conflit, on utilise **la priorité**, puis **la mise à jour la plus récente** comme critère de départage.

## Définition du privilège

Un privilège est un objet structuré. Il regroupe les métadonnées, l'apparence, le contenu, les liens et la valeur/le statut.

### Propriétés générales

| Propriété             | Description                                                                                                                                                                                  |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `privilegeId`         | Identifiant unique du privilège. Généré automatiquement par le système.                                                                                                                      |
| `la priorité`         | Entier utilisé pour résoudre les conflits lorsque plusieurs privilèges modifient la même propriété. La valeur la plus élevée l'emporte. En cas d'égalité, la dernière mise à jour l'emporte. |
| `type`                | L'un des `Une seule fois`, `Illimité`, `Multi-utilisation`, `Déblocable`.                                                                                                                    |
| `tags`                | Liste d'étiquettes utilisées pour le reporting.                                                                                                                                              |
| `origin.generator`    | *(facultatif)* Nom du processus générant le privilège. Utilisez `interne` pour les activations de la plateforme.                                                                             |
| `origin.activationId` | *(facultatif)* Identifiant du processus générateur. Exemple : identifiant d'activation interne, ou un `journeyId` (SFMC).                                                                    |
| `origin.externalId`   | *(facultatif)* Identifiant unique de ce privilège dans un système externe.                                                                                                                   |
| `deletionDate`        | Date à laquelle le privilège sera supprimé du système. Une fois supprimé, il n'affecte plus le rendu de la carte.                                                                            |

{% hint style="info" %}
Gardez des priorités simples. Utilisez une plage réduite comme `0–100`.
{% endhint %}

### Type

La plateforme prend en charge quatre types de privilèges. Chaque type définit comment et quand un privilège peut être utilisé.

<div data-with-frame="true"><figure><img src="/files/d5f164dd4f7f4fa4f4c9304a5694f096b8442b65" alt="4 different type of privileges"><figcaption></figcaption></figure></div>

{% tabs %}
{% tab title="Une seule fois" %}
A **Une seule fois** le privilège peut être utilisé **une seule fois**. Une fois utilisé, il est consommé et ne peut plus être utilisé.

{% hint style="success" %}
**Cas d'utilisation concrets**

* Café : bon « Espresso gratuit », à utiliser une seule fois.
* Événement : entrée au salon VIP pour un participant, 1 seul scan.
* Commerce : code « 15 $ de réduction sur votre prochaine commande », utilisable une seule fois.
  {% endhint %}
  {% endtab %}

{% tab title="Illimité" %}
Un **Illimité** le privilège peut être utilisé **autant de fois que nécessaire** tant qu'il est valide. Il n'est jamais consommé.

{% hint style="success" %}
**Cas d'utilisation concrets**

* Adhésion : « Livraison gratuite » sur chaque commande en ligne.
* Commerce : « 10 % de réduction sur tous les achats » pendant toute la saison.
* Service : « assistance prioritaire » disponible pour chaque ticket soumis.
  {% endhint %}
  {% endtab %}

{% tab title="Multi-utilisation" %}
A **Multi-utilisation** le privilège peut être utilisé un **nombre limité de fois**. Chaque utilisation réduit le nombre restant jusqu'à ce que le privilège soit consommé.

{% hint style="success" %}
**Cas d'utilisation concrets**

* Salle de sport : pack « 10 entrées », chaque enregistrement en consomme 1.
* Lieu : « 3 cartes invité », chaque scan d'invité en consomme 1.
* Lavage auto : « 5 lavages », chaque lavage en consomme 1.
  {% endhint %}
  {% endtab %}

{% tab title="Déblocable" %}
Un **Déblocable** le privilège devient disponible **une fois la progression terminée**. Il reste verrouillé jusqu'à ce que les étapes requises soient effectuées.

{% hint style="success" %}
**Cas d'utilisation concrets**

* Restaurant : « Achetez 10 pizzas, obtenez-en 1 gratuite » (la progression débloque la récompense).
* Café : « Collectez 8 tampons, obtenez-en 1 gratuit » (chaque achat fait progresser le compteur).
* Formation : « Terminez 3 modules, débloquez un bon d'examen » (progression issue des événements du LMS).
  {% endhint %}
  {% endtab %}
  {% endtabs %}

### Apparence

| Propriété         | Description                                                                                                                                        |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `mainImage`       | *(facultatif, localisable)* Image principale du privilège. Utilisez-la pour expliquer visuellement l'avantage. Gardez-la lisible en petite taille. |
| `thumbnail`       | *(facultatif, localisable)* Petite image pour les interfaces compactes. Utilisez un pictogramme simple ou un visuel de type logo.                  |
| `backgroundColor` | *(facultatif)* Remplacement de la couleur d'arrière-plan pour les éléments d'interface du privilège (lorsque pris en charge).                      |
| `foregroundColor` | *(facultatif)* Remplacement de la couleur de premier plan/du texte pour les éléments d'interface du privilège (lorsque pris en charge).            |

{% hint style="info" %}
Les images sont automatiquement redimensionnées pour respecter les contraintes d'Apple Wallet et de Google Wallet. Utilisez une image large. Taille recommandée : `1200px × 400px`.
{% endhint %}

{% tabs fullWidth="false" %}
{% tab title="Apple Wallet" %}
Remplacera l'image principale de la carte.

Si la propriété contient des valeurs localisées, la langue du téléphone sélectionne la version localisée. Si aucune version localisée n'existe, `par défaut` est utilisée.

<div data-with-frame="true"><figure><img src="/files/6eae83512c851f515dca8917658f5d4a1194b85e" alt="Example of pass privilege appearance for apple wallet"><figcaption></figcaption></figure></div>

{% hint style="info" %}
Les billets d'événement au style affiche peuvent associer les images différemment selon votre modèle. Si vous avez besoin d'un mappage exact des emplacements, vérifiez la configuration de votre modèle de carte.
{% endhint %}

{% hint style="warning" %}
`thumbnail` n'est pas disponible pour Apple.
{% endhint %}
{% endtab %}

{% tab title="Google Wallet" %}
Affiché comme visuel du privilège lorsque le modèle de carte le prend en charge.

Google Wallet utilise une seule image non localisée. Seule la valeur par défaut de `mainImage` / `thumbnail` est utilisée, quelle que soit la langue du téléphone. Les images localisées par langue ne sont pas prises en charge sur Google aujourd'hui en raison d'une contrainte de webhook Google. Si des images localisées sont définies pour Apple et qu'une image par défaut existe dans le même privilège, Google utilise l'image par défaut.

{% hint style="info" %}
Il n'est pas nécessaire d'avoir un privilège séparé par langue pour Google. Placez les images localisées et une image par défaut dans le même privilège. Apple choisit l'image localisée selon la langue, tandis que Google, ainsi que toute langue Apple sans version localisée, revient à la valeur par défaut.
{% endhint %}
{% endtab %}

{% tab title="Aperçu de la carte" %}
Affiché comme image principale du privilège dans l'interface d'aperçu.

L'interface d'aperçu affiche le privilège `mainImage`. Lorsque des valeurs localisées existent, l'aperçu suit la même règle qu'Apple. Il affiche l'image de la langue sélectionnée et revient à la valeur par défaut lorsqu'aucune version localisée n'existe.
{% endtab %}

{% tab title="Vérification Crew" %}
{% hint style="danger" %}
TODO — confirmer avec le produit si Crew check affiche l'image du privilège et, le cas échéant, s'il utilise la valeur localisée ou la valeur par défaut.
{% endhint %}
{% endtab %}
{% endtabs %}

{% hint style="warning" %}
Un privilège n'est pas ciblé sur un appareil. Chaque privilège appliqué est ajouté à la carte pour Apple et Google. L'application de deux privilèges, par exemple un « localisé » et un « générique », entraîne l'affichage des deux sur chaque carte, et leurs descriptions s'empilent au dos. Utilisez un seul privilège par campagne, en combinant les images localisées et par défaut.
{% endhint %}

### Contenu

| Propriété     | Description                                                                                                                            |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `titre`       | *(facultatif, localisable)* Libellé court du privilège. Exemple : `Accès au salon VIP`, `-10%`, `Boisson gratuite`.                    |
| `description` | *(facultatif, localisable)* Texte d'appui pour les utilisateurs et les opérateurs. Utilisez-le pour les conditions et les contraintes. |

{% tabs %}
{% tab title="Apple Wallet" %}
{% hint style="danger" %}
TODO
{% endhint %}
{% endtab %}

{% tab title="Google Wallet" %}
{% hint style="danger" %}
TODO
{% endhint %}
{% endtab %}

{% tab title="Aperçu de la carte" %}
{% hint style="danger" %}
TODO
{% endhint %}
{% endtab %}

{% tab title="Vérification Crew" %}
{% hint style="danger" %}
TODO
{% endhint %}
{% endtab %}
{% endtabs %}

### Liens

| Propriété          | Description                                                                                                         |
| ------------------ | ------------------------------------------------------------------------------------------------------------------- |
| `legalInformation` | *(facultatif, localisable)* Conditions générales liées au privilège. Il s'agit généralement d'un libellé + une URL. |
| `callToAction`     | *(facultatif, localisable)* Action principale du privilège. Il s'agit généralement d'un libellé + une URL.          |

{% hint style="info" %}
Les liens sont généralement modélisés sous la forme `{ "label": "...", "url": "https://..." }`. Le rendu exact dépend du modèle de carte.
{% endhint %}

{% tabs %}
{% tab title="Apple Wallet" %}
Affiché comme action principale du privilège lorsque pris en charge.
{% endtab %}

{% tab title="Google Wallet" %}
Affiché comme action principale du privilège lorsque pris en charge.
{% endtab %}

{% tab title="Aperçu de la carte" %}
Affiché comme bouton principal.
{% endtab %}

{% tab title="Vérification Crew" %}
Affiché comme bouton d'action pour les opérateurs.
{% endtab %}
{% endtabs %}

### Données

Utilisez **data** lorsque le privilège contient un solde échangeable, une progression ou un code.

| Propriété    | Type         | Description                                             |
| ------------ | ------------ | ------------------------------------------------------- |
| `valeur`     | `décimal`    | Valeur calculée. Somme de tous les `movements[].value`. |
| `mouvements` | `movement[]` | Liste des mouvements de valeur (crédits/débits).        |
| `contenu`    | `chaîne`     | Valeur libre. Exemple : code promotionnel.              |

{% hint style="info" %}
La logique d'utilisation est appliquée par le système consommateur (POS, scanners, applications). La plateforme stocke les mouvements et calcule `movementValue`.
{% endhint %}

#### Mouvement

| Propriété    | Type               | Description                                                                                                   |
| ------------ | ------------------ | ------------------------------------------------------------------------------------------------------------- |
| `movementId` | identifiant unique | Généré par la plateforme.                                                                                     |
| `date`       | `date et heure`    | Date à laquelle ce mouvement a eu lieu.                                                                       |
| `remarques`  | `chaîne`           | Remarque libre (audit/débogage).                                                                              |
| `valeur`     | `décimal`          | Peut être négatif lorsque le privilège est utilisé. Peut être fractionnaire pour la progression (Déblocable). |

{% hint style="info" %}
Votre application doit vérifier `movementValue` avant d'utiliser le privilège. Évitez les utilisations concurrentes sur la même carte/le même privilège.
{% endhint %}

#### Exemples

{% tabs %}
{% tab title="Une seule fois" %}
**Cas d'utilisation**

* Concert : « 1 boisson de bienvenue gratuite » pour les billets VIP.
* Commerce : « 1 emballage cadeau gratuit » à l'achat suivant.
* Musée : « 1 entrée pour une visite guidée » pour une date précise.

Chronologie des mouvements (exemple : boisson de bienvenue VIP) :

<table data-full-width="false"><thead><tr><th width="148">date</th><th width="97">valeur</th><th>remarques</th><th>total</th></tr></thead><tbody><tr><td><code>2025-01-12</code></td><td><code>1</code></td><td>privilège appliqué</td><td><code>1</code></td></tr><tr><td><code>2025-01-15</code></td><td><code>-1</code></td><td>privilège utilisé</td><td><code>0</code></td></tr><tr><td><code>2025-01-15</code></td><td><code>1</code></td><td>annulation</td><td><code>1</code></td></tr></tbody></table>
{% endtab %}

{% tab title="Illimité" %}
**Cas d'utilisation**

* Palier de fidélité : « 10 % de réduction » à chaque fois, tant que le palier est actif.
* Compagnie aérienne : « 1 bagage enregistré gratuit » sur chaque segment de vol.
* Abonnement : « accès illimité » au contenu premium.

Pour les privilèges illimités, les mouvements sont souvent omis car rien n'est « consommé ».\
Si vous stockez quand même des mouvements pour l'audit (facultatif), cela peut ressembler à ceci :

<table data-full-width="false"><thead><tr><th width="148">date</th><th width="97">valeur</th><th>remarques</th><th>total</th></tr></thead><tbody><tr><td><code>2025-01-12</code></td><td><code>-1</code></td><td>privilège utilisé</td><td><code>-1</code></td></tr><tr><td><code>2025-01-15</code></td><td><code>-2</code></td><td>privilège utilisé deux fois</td><td><code>-3</code></td></tr></tbody></table>
{% endtab %}

{% tab title="Multi-utilisation" %}
**Cas d'utilisation**

* Salle de sport : pack prépayé « 10 entrées ».
* Festival : « 5 jetons boisson » liés à la carte.
* Parking : pack « 20 sorties » pour une carte de parking d'entreprise.

Chronologie des mouvements (exemple : pack salle de sport 10 entrées) :

<table data-full-width="false"><thead><tr><th width="148">date</th><th width="97">valeur</th><th>remarques</th><th>total</th></tr></thead><tbody><tr><td><code>2025-01-12</code></td><td><code>10</code></td><td>achat de la carte 10 entrées</td><td><code>10</code></td></tr><tr><td><code>2025-01-15</code></td><td><code>-1</code></td><td>consommation de 1 entrée</td><td><code>9</code></td></tr><tr><td><code>2025-01-17</code></td><td><code>-4</code></td><td>consommation de 4 entrées (avec des amis)</td><td><code>5</code></td></tr><tr><td><code>2025-01-17</code></td><td><code>1</code></td><td>1 entrée offerte</td><td><code>6</code></td></tr></tbody></table>
{% endtab %}

{% tab title="Déblocable" %}
**Cas d'utilisation**

* Restaurant : achetez 10 pizzas, débloquez 1 pizza gratuite.
* Café : collectez 8 tampons, débloquez 1 boisson gratuite.
* Commerce : dépensez 200 € en un mois, débloquez un bon de 20 €.

Chronologie des mouvements (exemple : achetez 10 pizzas, débloquez-en 1 gratuite) :

<table data-full-width="false"><thead><tr><th width="148">date</th><th width="97">valeur</th><th>remarques</th><th>total</th></tr></thead><tbody><tr><td><code>2025-01-12</code></td><td><code>0.2</code></td><td>achat de 2 pizzas</td><td><code>0.2</code></td></tr><tr><td><code>2025-01-15</code></td><td><code>0.5</code></td><td>achat de 5 pizzas</td><td><code>0.7</code></td></tr><tr><td><code>2025-01-17</code></td><td><code>0.4</code></td><td>achat de 4 pizzas</td><td><code>1.1</code></td></tr><tr><td><code>2025-01-17</code></td><td><code>-1</code></td><td>utilisation d'1 pizza</td><td><code>0.1</code></td></tr></tbody></table>
{% endtab %}
{% endtabs %}

## Cas d'utilisation réel

Utilisez des privilèges lorsque vous avez besoin **d'avantages avec état** sur une carte. L'application native de portefeuille affichera automatiquement les informations du privilège. Pour une meilleure expérience, il est également possible d'utiliser notre [Crew Check](https://docs.thewalletcrew.io/guides-scan) application pour scanner les cartes, lister et utiliser les privilèges.

### Billet d'événement

Transformez un billet statique en support de campagne vivant. Conservez une carte pour l'entrée, puis ajoutez des avantages au fil du déroulement de l'événement. Utilisez **Une seule fois** pour les avantages à réclamation unique (entrée au salon VIP, accès coupe-file, boisson de bienvenue), **Multi-utilisation** pour les packs de jetons (jetons boisson, crédits vestiaire), et **Déblocable** pour les avantages qui apparaissent après progression.

Exemple : tout le monde entre avec la même carte, mais un **Déblocable** privilège « Accès after-party » apparaît après le troisième scan. Un **Multi-utilisation** privilège « 5 jetons boisson » est ajouté à l'ouverture des portes et décrémenté au bar.

### Carte de fidélité

Lancez des promotions et des avantages de palier sans modifier la carte. Laissez le CRM, la CDP ou le POS mettre à jour les avantages au fur et à mesure que les clients progressent.

Utilisez **Illimité** pour les droits permanents (réductions de palier, livraison gratuite, assistance prioritaire). Utilisez **Déblocable** pour les déclencheurs liés aux dépenses, **Multi-utilisation** pour les compteurs (tampons, entrées), et **Une seule fois** pour les récompenses à usage unique (anniversaire, récupération).

Exemple : offrez aux clients VIP un **Illimité** privilège « 15 % de réduction » avec un **la priorité** supérieur à celui des remises de campagne. Lorsque le client dépense 200 € en un mois, votre CDP ajoute un **Déblocable** privilège « bon de 20 € », et le POS l'utilise une seule fois.

### Carte cadeau

Utilisez des privilèges lorsque la carte a besoin de **valeur utilisable**, **un code**, ou les deux.

Stockez un solde sous forme de **Multi-utilisation** et décrémentez-le au moyen de mouvements à chaque dépense. Stockez un code promotionnel sous forme de **Une seule fois** et consommez-le dès la première utilisation.

Exemple : démarrez une carte cadeau à `+50`. Un achat de 12 € ajoute un `-12` mouvement et laisse `38`. Une promotion de fin d'année ajoute un `+10` mouvement de rechargement. Si cet achat est remboursé, ajoutez un `+12` mouvement d'annulation plutôt que de modifier l'historique.

L'utilisation est imposée par votre POS ou votre caisse. La plateforme stocke l'état et les mouvements à des fins de reporting.

### Adhésion

Utilisez une carte comme support d'adhésion avec des droits évolutifs.

Utilisez **Illimité** pour l'accès continu, **Multi-utilisation** pour les quotas mensuels, **Une seule fois** pour les réclamations uniques, et **Déblocable** pour les récompenses d'étape.

Exemple : une carte de coworking a **Illimité** « accès premium » plus **Multi-utilisation** « 5 cartes journalières » qui se réinitialisent chaque mois. Une fois l'intégration terminée, un **Déblocable** privilège « session 1:1 » devient utilisable dans le parcours de réservation.

## FAQ

<details>

<summary>Combien de privilèges une carte peut-elle avoir en même temps ?</summary>

Vous pouvez attacher jusqu'à 5 privilèges à une seule carte en même temps. Si vous avez besoin de plus d'avantages, regroupez-les en moins de privilèges ou alternez-les dans le temps.

</details>

<details>

<summary>Que se passe-t-il lorsque plusieurs privilèges entrent en conflit ?</summary>

Lorsque plusieurs privilèges tentent de modifier la même propriété, la priorité détermine le gagnant. Si les priorités sont égales, le privilège mis à jour le plus récemment l'emporte.

</details>

<details>

<summary>Dois-je réémettre la carte lorsqu'un privilège change ?</summary>

Non. Les privilèges sont distincts des données principales de la carte. Vous pouvez ajouter, mettre à jour ou supprimer un privilège sans réémettre la carte.

</details>

<details>

<summary>Que deviennent les privilèges lorsqu'une carte est désinstallée puis réinstallée ?</summary>

La désinstallation ou la réinstallation d'une carte ne modifie pas ses privilèges. Les privilèges restent attachés à la carte sur les serveurs de The Wallet Crew.

</details>

<details>

<summary>D'où viennent les privilèges ?</summary>

Vous pouvez créer des privilèges en interne à l'aide d'activations, ou à l'externe via des connecteurs (par exemple SFMC ou Bloomreach). Vous pouvez également les créer et les mettre à jour directement via l'API.

</details>

<details>

<summary>Comment l'état d'utilisation est-il stocké pour les privilèges MultiUse et OneTime ?</summary>

Utilisez des mouvements pour suivre les crédits et les débits. La plateforme stocke l'historique des mouvements et calcule le `valeur`, mais votre système consommateur (POS, scanners, application) applique les règles d'utilisation.

</details>

<details>

<summary>Puis-je « annuler » une utilisation ?</summary>

Oui, si votre processus le permet. Au lieu de modifier l'historique, ajoutez un nouveau mouvement qui compense le débit précédent (un crédit d'annulation) afin que la piste d'audit reste intacte.

</details>

<details>

<summary>Que fait <code>deletionDate</code> ?</summary>

Cela planifie la suppression du privilège du système. Après la suppression, il n'affecte plus le rendu de la carte et ne doit plus être pris en compte lors des scans et de l'utilisation.

</details>


# Activation

Une activation applique un privilège (et éventuellement une notification) à de nombreuses Cartes. Utilisez les activations pour les campagnes et les déploiements planifiés.

### Ce que contient une activation

1. **Segmentation**: quelles Cartes sont ciblées.
2. **Déclencheur**: quand l’activation s’exécute.
3. **Configuration**: ce qui est appliqué (privilège + notification facultative).

### En quoi elle diffère d’un privilège

Un [Privilège](/guides-animation/fr/engagement-et-animation/privilege-and-activation/privilege) est l’objet stocké sur une Carte. Une activation est le « mécanisme par lot » qui crée ou met à jour des privilèges à grande échelle.

### Modèle d’exécution (vue d’ensemble)

* Lorsque le déclencheur se déclenche, la plateforme résout le segment en identifiants de Cartes.
* La plateforme applique le privilège configuré à chaque Carte.
* Chaque Carte mise à jour est envoyée à Apple/Google via le pipeline de mise à jour habituel.

{% hint style="info" %}
Utilisez une activation lorsque vous avez besoin d’une logique reproductible. Utilisez l’API de privilège lorsque vous ciblez une seule Carte.
{% endhint %}


# Automatisation


# Notifications push

Comparez les notifications push d'Apple Wallet et de Google Wallet : déclencheurs, limites et cas d'utilisation courants avec The Wallet Crew.

Les notifications Wallet aident à diffuser des informations au bon moment dans un canal familier. Apple Wallet et Google Wallet ne fonctionnent pas de la même manière, donc la stratégie de déclenchement est importante. *Les notifications Apple Wallet nécessitent une mise à jour de Carte. Google Wallet peut notifier à partir d’un message.*

![Schéma comparant les notifications push dans Apple Wallet et Google Wallet](/spaces/NjHWxT38jWDRFOJxAqh7/files/38f2399001561a4e50f1d07e0ead240a3bce91ca)

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un membre de programme de fidélité reçoit une mise à jour de points après un achat.
* Le solde d’une carte cadeau est actualisé après un échange en magasin.
* Un détenteur de billet est alerté d’un changement de porte d’embarquement ou d’une mise à jour d’horaire.

</details>

## Comment fonctionnent les notifications push

### Apple Wallet

Les notifications Apple Wallet sont déclenchées uniquement lorsqu’une Carte est mise à jour. Un champ, un code QR ou une localisation peut changer. Les notifications apparaissent sur l’écran verrouillé ou dans le centre de notifications. Le dernier message apparaît au dos de la Carte.

Apple prend également en charge la présentation automatique de la Carte en fonction de la géolocalisation, des dates ou des événements.

### Google Wallet

Google Wallet peut envoyer des notifications sans mise à jour de Carte. La notification avertit le client qu’un message a été ajouté à la Carte.

Google Wallet peut afficher le message uniquement dans les détails de la Carte. Il peut aussi afficher le message et générer une notification.

## Mettre à jour les informations de la Carte et déclencher des alertes

The Wallet Crew gère les Cartes Apple Wallet et Google Wallet via une API unifiée. Les systèmes CRM, de billetterie et de point de vente connectés peuvent mettre à jour les données de la Carte en temps réel.

Les mises à jour courantes incluent :

* Solde restant de la carte cadeau.
* Date d’expiration du coupon ou du billet.
* Contenu promotionnel sur une Carte.

Une mise à jour de Carte se synchronise avec Apple Wallet et Google Wallet. Les règles de la plateforme déterminent si elle génère une notification.

![Exemple d’une mise à jour de Carte déclenchant une notification](/spaces/NjHWxT38jWDRFOJxAqh7/files/f7fe63e6b3dd5d07f2fc81a667c7001e568be351)

## Types de notifications

### Notifications basées sur la géolocalisation

Apple Wallet utilise les coordonnées GPS pour détecter quand un client entre ou sort d’une zone définie. Google Wallet s’appuie sur les informations de localisation associées au compte Google. Cela peut faire apparaître une Carte à proximité d’un magasin ou d’un lieu.

![Exemple de notification basée sur la localisation près d’un magasin](/spaces/NjHWxT38jWDRFOJxAqh7/files/60d9443436a2060b0f5a81a7ea699bb511c81aa9)

### Notifications basées sur la date ou le calendrier

Les marques peuvent configurer des rappels autour de la validité de la Carte ou d’une date d’événement.

![Exemple de notification de rappel planifié pour une Carte](/spaces/NjHWxT38jWDRFOJxAqh7/files/52583e5f79a393d53b4d1628e9871b0d868b58a8)

### Notifications déclenchées par un événement

The Wallet Crew peut réagir aux événements provenant des systèmes CRM, de point de vente et de billetterie. Les achats, l’accumulation de points ou les annulations peuvent mettre à jour une Carte et déclencher une notification.

![Notifications déclenchées par des événements pilotées par des systèmes connectés](/spaces/NjHWxT38jWDRFOJxAqh7/files/951a76a2f4104e0714316d94e57d447891b5333c)

### Balises Beacon

Les balises Beacon utilisent Bluetooth pour détecter les appareils à proximité. Cette fonctionnalité n’est disponible qu’avec Apple Wallet.

![Exemple de notification basée sur une balise Bluetooth Beacon (Apple Wallet)](/spaces/NjHWxT38jWDRFOJxAqh7/files/cbbb92ac9282cad7fe7b95f5b16d05f3186bc602)

## Limites

### Apple Wallet

Les notifications peuvent apparaître sur l’écran verrouillé de l’iPhone, dans le centre de notifications et sur Apple Watch lorsqu’elle est activée.

À partir d’iOS 18, jusqu’à trois lignes sont affichées. Gardez les messages sous 140 caractères pour réduire la troncature. Apple Watch affiche généralement une ou deux lignes.

### Google Wallet

Google Wallet applique les restrictions suivantes :

* Les clients doivent activer les notifications de Carte.
* Les liens du message doivent être liés à la Carte.
* Un maximum de trois messages peut déclencher une notification push sur 24 heures.
* Google Wallet contrôle la notification sur l’écran verrouillé.

Google peut limiter la diffusion lorsqu’elle détecte du spam. Plus d’informations sont disponibles dans [les considérations de Google lors de l’envoi de messages](https://developers.google.com/wallet/retail/offers/use-cases/trigger-push-notifications#some-considerations-when-sending-messages-with-notifications-to-users).

## Principales différences

### Déclenchement des notifications

Apple Wallet nécessite une mise à jour de Carte. Google Wallet peut notifier à partir d’un message, indépendamment d’une mise à jour de Carte.

### Contenu de la notification

Apple Wallet peut afficher le contenu du message sur l’écran verrouillé. Google Wallet avertit généralement les clients qu’un message a été ajouté. Les clients ouvrent ensuite la Carte pour le lire.

![Exemple montrant les différences de contenu des notifications entre Apple Wallet et Google Wallet](/spaces/NjHWxT38jWDRFOJxAqh7/files/c4890e39edb4b6719aefd68b1af74557b994c748)

### Opportunités à valeur ajoutée

Google Wallet peut ajouter un titre, une description, une image et un lien cliquable à l’intérieur de la Carte. Apple Wallet ne prend pas en charge ce modèle d’interaction.

![Exemple d’opportunités à valeur ajoutée de Google Wallet (image + lien)](/spaces/NjHWxT38jWDRFOJxAqh7/files/9d8d72330831072660e0b4936b5fa7d692ce0f0b)

## L’API unifiée de The Wallet Crew

The Wallet Crew centralise les mises à jour de Carte pour les deux plateformes. Cela crée une logique métier cohérente tout en respectant les règles de diffusion de chaque Wallet.

![Illustration de l’utilisation d’une seule API pour gérer Apple Wallet et Google Wallet](/spaces/NjHWxT38jWDRFOJxAqh7/files/36cd0065ceb9532c85ae3857b92ef9f8d73bd0fa)

## FAQ

<details>

<summary><strong>Le texte de la notification peut-il être personnalisé dans Google Wallet ?</strong></summary>

Pas de la même manière qu’avec Apple Wallet. Google Wallet avertit généralement les clients qu’un message a été ajouté. Ils ouvrent ensuite la Carte pour lire le contenu.

</details>

<details>

<summary><strong>Pourquoi un client n’a-t-il pas reçu de notification Wallet ?</strong></summary>

Vérifiez d’abord les paramètres de l’appareil. Les notifications peuvent être désactivées globalement ou pour une Carte spécifique. Puis validez le déclencheur de la plateforme.

</details>

<details>

<summary><strong>Quelles sont les limites d’envoi de Google Wallet ?</strong></summary>

Google Wallet limite les messages déclencheurs de notifications push à trois par période de 24 heures pour chaque Carte.

</details>

<details>

<summary><strong>Les notifications Wallet doivent-elles être considérées comme du marketing ?</strong></summary>

Cela dépend de l’objectif du message. Les messages de service sont généralement transactionnels. Les promotions relèvent du marketing. Voir [Consentements et conformité au RGPD](broken://spaces/NjHWxT38jWDRFOJxAqh7/pages/9f345a2ec17ae5b6ea255be57135cfa8461b16f8).

</details>


# Comment envoyer des notifications push à Apple et Google Wallet

## Comment envoyer des notifications push

Les notifications push sont disponibles pour les cartes Apple Wallet et Google Wallet. Sur Apple Wallet, le message de notification peut être personnalisé. Sur Google Wallet, la notification est gérée par Google Wallet et son texte ne peut pas être personnalisé.

### Étapes pour envoyer des notifications push

#### 1. Accédez à la section Engagement

Sélectionnez la **Engagement** section pour configurer les notifications push.

#### 2. Sélectionnez Automatisations

Cliquez sur **Ajouter une nouvelle** dans le coin supérieur droit.

<figure><img src="/files/55daa2fa3e6869eb2f109d207f1225272a5bc246" alt=""><figcaption></figcaption></figure>

Sélectionnez **Envoyer une notification** puis cliquez sur **Suivant.**

<figure><img src="/files/5099af00bedd285926052f1e33e227033aae0b87" alt=""><figcaption></figcaption></figure>

#### 3. Composez la notification

Attribuez à la notification un **nom** et **choisissez quand vous souhaitez l'envoyer.**

Vous pouvez choisir entre différentes possibilités :

* **Maintenant** : la notification est envoyée immédiatement, une fois la configuration terminée.
* **Planifié** : choisissez une date planifiée pour envoyer la notification.
* **Récurrence** : choisissez la récurrence de la notification (chaque jour, semaine, mois).
* **Date relative**: sélectionnez un **champ de métadonnées DateTime**. Envoyez la notification avant ou après cette date, en utilisant un décalage ou une heure spécifique.
* **Événement**: sélectionnez un événement et son occurrence. L'automatisation peut s'exécuter une fois pour chaque Carte ou seulement lors de sa première installation. Un délai peut également être ajouté après l'événement.

<figure><img src="/files/41f91eeac1e214bcb95a7fc82422453a77cd616d" alt=""><figcaption></figcaption></figure>

Sélectionnez **Suivant** après avoir choisi le nom et l'heure d'envoi.

#### 4. Sélectionnez l'audience

Vous pouvez choisir l'audience en sélectionnant un filtre qui estimera immédiatement l'audience de la notification.

Vous pouvez ajouter différents types de filtres en cliquant sur le bouton « ajouter un filtre » :

* **Statut d'installation** : envoyez à toutes les personnes qui ont installé leur Carte ou uniquement aux cartes Apple ou Google.
* **Modèle**: envoyez la notification à un modèle spécifique. Précisez le modèle à cibler.
* **Métadonnées**: filtrez selon une valeur de métadonnée spécifique.
* **Identifiants** : filtrez selon un identifiant spécifique.

Si vous choisissez différents filtres, ils seront tous définis automatiquement avec une règle « et ». Cette règle et ne peut pas être modifiée.

<figure><img src="/files/06ebe0350e0100ffa3b258f3a63edbdfd26d9692" alt=""><figcaption></figcaption></figure>

Cliquez sur le bouton jaune **Estimer** pour voir le nombre de cartes ciblées.

#### 5. Configurez le contenu du message

Si vous gérez plusieurs langues, vous pouvez activer le bouton « activer les traductions » pour mettre à jour chaque version linguistique.

![](/files/2b934ee2ff81531544a137ae6d9f6e38130007a9)

Une fois la traduction activée, à droite, vous pouvez sélectionner la langue pour configurer les deux.

<figure><img src="/files/95fdf4b624dd06e45094cb268dbf8181bc05e8c2" alt=""><figcaption></figcaption></figure>

Sur Apple, le contenu de la notification s'affiche sur l'écran de verrouillage. Sur Google, ce contenu n'est pas affiché. À la place, l'application Wallet affiche une notification indiquant « Nouveau message ».

Vous pouvez voir un aperçu des écrans Apple et Google en cliquant dans le coin supérieur droit.

Les notifications sont affichées par défaut pendant sept jours. Les destinataires peuvent les consulter au dos de leur Carte pendant cette période.

Pour modifier cette durée, allez dans Wallet > Modèle > Édition > Général > Configuration avancée, puis mettez à jour la durée.

#### 5. Configurez le débit

Le débit est configuré par défaut, mais vous pouvez le modifier.

Lorsque vous envoyez des notifications à un large public, assurez-vous que le débit d'envoi permet à chaque destinataire de recevoir la notification avant un événement précis (ex. : début du spectacle).&#x20;

Cliquez sur Suivant, puis vous pourrez vérifier le résumé et enregistrer la configuration de votre notification.&#x20;

### Vérifier les notifications envoyées à une Carte spécifique

Chaque Carte possède un **Notifications** onglet dans sa vue détaillée. Accédez-y depuis **Wallet → Cartes → \[sélectionnez une Carte] → Notifications**

L'onglet affiche une chronologie complète des notifications envoyées à cette Carte, y compris :

* Horodatage de chaque notification.
* Badge d'état de livraison, tel que **Notification envoyée**.
* Appareil cible : Apple ou Google.
* Contenu du message envoyé.
* Versions localisées, telles que `FR-FR`.

Utilisez cet onglet pour confirmer qu'une Carte spécifique a reçu une notification. Il aide également à enquêter sur les signalements de notifications manquantes.

{% hint style="info" %}
La synchronisation peut prendre jusqu'à 5 minutes après l'envoi d'une notification avant qu'elle n'apparaisse dans l'onglet Historique.
{% endhint %}


# Consentements et conformité au RGPD

Notifications Wallet mobiles : transactionnelles, marketing et consentement RGPD.

Les Wallet mobiles peuvent afficher des notifications contextuelles et déclenchées par des campagnes. Comme certains messages relèvent du marketing, le consentement doit être correctement géré.

Cette page explique la différence entre les notifications transactionnelles et marketing ainsi que les contrôles nécessaires à la conformité au RGPD. Pour les mécanismes de livraison, voir [Notifications push](/guides-animation/fr/engagement-et-animation/automatisation/notifications-push).

## Notifications transactionnelles vs marketing

{% tabs %}
{% tab title="Transactionnel" %}
Les notifications transactionnelles découlent directement d’un contrat ou de l’adhésion à un programme de fidélité. Elles doivent être nécessaires à la fourniture du service. L’exécution du contrat les couvre généralement, donc l’opt-in marketing n’est pas requis.

<details>

<summary><strong>Exemples concrets</strong></summary>

* « Vous avez gagné 50 points. »
* « Votre concert commence demain à 20 h. »
* « Il vous reste 3 entrées. »

</details>
{% endtab %}

{% tab title="Marketing" %}
Les notifications marketing font la promotion d’un produit ou d’un service sans lien direct avec un contrat existant. Il s’agit de prospection commerciale et elles nécessitent généralement un opt-in marketing explicite.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Mettre à jour un champ promotionnel de carte pour annoncer une offre.
* Envoyer un message Google Wallet au sujet d’une nouvelle collection.

</details>
{% endtab %}
{% endtabs %}

{% hint style="warning" %}
Un prospect qui télécharge une carte sans s’inscrire n’est pas couvert par l’exécution du contrat. Toute notification proactive constitue une démarche marketing.
{% endhint %}

### Base juridique

Une base légale est requise pour les notifications Wallet. Les notifications transactionnelles s’appuient généralement sur l’exécution du contrat au titre de l’article 6(1)(b) du RGPD. Elles doivent rester nécessaires à la fourniture du service.

Les notifications marketing s’appuient généralement sur le consentement au titre des articles 6(1)(a) et 7 du RGPD. Le consentement doit être libre, spécifique, éclairé et univoque. Conservez la preuve du consentement et facilitez le retrait.

### Collecter le consentement

Collectez le consentement marketing avant d’envoyer des notifications promotionnelles. L’inscription est un point de collecte courant. Le consentement peut aussi être recueilli sur une page d’accueil de téléchargement de carte, sur un site Web ou dans une application.

Conservez les choix de service et de marketing séparés. Stockez-les sous forme d’indicateurs indépendants. Ne regroupez pas les deux finalités dans une seule case à cocher « notifications Wallet ».

### Politique de confidentialité et mentions légales

Les informations de confidentialité doivent expliquer qu’une carte Wallet peut générer des notifications. Elles doivent indiquer les déclencheurs, distinguer les messages de service et promotionnels, décrire les finalités du traitement et expliquer les contrôles offerts aux clients.

Mentionnez les principaux déclencheurs et la fréquence attendue. Présentez l’information de façon facile à parcourir.

## Bonnes pratiques

1. **Classez chaque notification.** Déterminez s’il s’agit d’une notification transactionnelle ou marketing.
2. **Séparez les indicateurs de consentement.** Maintenez des choix de service et de marketing indépendants.
3. **Filtrez les envois marketing.** Envoyez des promotions uniquement aux clients ayant accepté.
4. **Conservez la preuve du consentement.** Stockez l’horodatage, la source et la version de l’avis de confidentialité.
5. **Facilitez le désabonnement.** Fournissez un lien de gestion des préférences.
6. **Testez l’intégralité du parcours.** Validez la capture, les mises à jour, les notifications et la synchronisation du désabonnement.

## Paramètres de notification Wallet

Les clients contrôlent les notifications globalement et par carte. Ils peuvent désactiver les mises à jour automatiques, les notifications push et l’affichage contextuel pour une carte individuelle.

### Apple Wallet

Les notifications Apple Wallet sont déclenchées par les mises à jour de carte. Tout changement de champ visible peut déclencher une notification. Les modifications typiques incluent les points, le niveau ou les rappels d’événements.

Pour le contenu promotionnel, réservez un champ de carte dédié. Mettez à jour uniquement ce champ pour le texte marketing.

### Google Wallet

Google Wallet peut envoyer des notifications via les mises à jour de carte ou son API de notifications. Cela permet une messagerie plus flexible, mais la fréquence doit rester maîtrisée.

## Comment The Wallet Crew aide

The Wallet Crew prend en charge des stratégies de notification tenant compte du consentement. Les marques peuvent séparer les finalités, segmenter selon le statut du consentement et activer des campagnes de manière conditionnelle.

The Wallet Crew agit en tant que sous-traitant pour les services de notification Wallet. La marque reste responsable de la base légale, de la collecte et du stockage du consentement, des mentions de confidentialité et des droits des personnes concernées.

{% hint style="warning" icon="scale-balanced" %}
Le consentement marketing doit être recueilli via les mécanismes de consentement propres à la marque. The Wallet Crew ne le recueille pas au nom de la marque.
{% endhint %}

## FAQ

<details>

<summary><strong>L’opt-in marketing est-il requis pour les mises à jour de points ou de solde ?</strong></summary>

Les mises à jour de points, de soldes, de niveaux et autres informations de statut similaires sont généralement transactionnelles lorsqu’elles sont nécessaires à la fourniture du service. Conservez les choix de service et de marketing séparés.

</details>

<details>

<summary><strong>Peut-on envoyer des messages purement marketing via Apple Wallet ?</strong></summary>

Oui, mais un opt-in explicite est requis. Apple Wallet ne dispose pas d’une API push autonome. Une mise à jour de carte, idéalement vers un champ promotionnel dédié, déclenche la notification.

</details>

<details>

<summary><strong>La demande de notification d’Apple ou Google compte-t-elle comme un consentement marketing ?</strong></summary>

Non. Cette demande ne contrôle que la livraison au niveau de l’appareil. Le consentement marketing doit être recueilli séparément via les parcours propres à la marque.

</details>

<details>

<summary><strong>Quelle preuve du consentement faut-il conserver ?</strong></summary>

Conservez l’horodatage, le canal de collecte, le texte affiché et la version applicable de l’avis de confidentialité. Conservez les retraits avec la même rigueur.

</details>

<details>

<summary><strong>Pourquoi une notification Wallet ne s’est-elle pas affichée ?</strong></summary>

Vérifiez d’abord les paramètres globaux et par carte de l’appareil. Ensuite, validez le déclencheur de la plateforme. Apple Wallet a besoin d’une mise à jour visible de la carte. Google Wallet dépend de la méthode de déclenchement choisie.

</details>


# Guides de surveillance

Guides pour l’analytique du Wallet, les définitions des KPI, les exportations d’événements, la synchronisation externe et les requêtes de l’API Insights.

Les guides de surveillance expliquent comment l’activité Wallet est mesurée dans The Wallet Crew, comment les performances sont rapportées et comment des cartes individuelles peuvent être étudiées lorsqu’un dossier nécessite un examen au niveau de l’enregistrement.

<table data-view="cards"><thead><tr><th>Titre</th><th>Description</th><th data-card-target data-type="content-ref">Cible</th></tr></thead><tbody><tr><td><i class="fa-chart-mixed">:chart-mixed:</i> <strong>Statistiques</strong></td><td>Comprenez en un coup d’œil la création de cartes, les installations, les suppressions, la répartition du Wallet et les performances de la source.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f">/spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f</a></td></tr><tr><td><i class="fa-list">:list:</i> <strong>Liste des cartes</strong></td><td>Trouvez rapidement une carte par identifiant, modèle, métadonnées ou date, puis ouvrez sa page de détails.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/dfbd8ca5c62fd76678bda9b047ee74af073dd2a3">/spaces/tJnneV8b22BGeGPcyzLG/pages/dfbd8ca5c62fd76678bda9b047ee74af073dd2a3</a></td></tr><tr><td><i class="fa-id-card">:id-card:</i> <strong>Détails de la carte</strong></td><td>Examinez une carte dans son intégralité, y compris ses identifiants, son état, ses métadonnées et son historique enregistré.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/e03d5e4d1e15e11268b8a92d94d478cb7d15deff">/spaces/tJnneV8b22BGeGPcyzLG/pages/e03d5e4d1e15e11268b8a92d94d478cb7d15deff</a></td></tr><tr><td><i class="fa-gauge-max">:gauge-max:</i> <strong>Définitions des KPI</strong></td><td>Définissez les indicateurs utilisés dans le tableau de bord Statistiques et interprétez-les de manière cohérente dans le temps.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/ad6290e900fbecfca8a4e0d58c3ffb56e7d0c936">/spaces/tJnneV8b22BGeGPcyzLG/pages/ad6290e900fbecfca8a4e0d58c3ffb56e7d0c936</a></td></tr><tr><td><i class="fa-radar">:radar:</i> <strong>Ce que The Wallet Crew suit</strong></td><td>Comprenez quels événements Wallet The Wallet Crew suit, comment les installations sont comptabilisées et où Apple et Google fixent des limites.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/6e1da444286e39a272e5f64512d97bf489121c5e">/spaces/tJnneV8b22BGeGPcyzLG/pages/6e1da444286e39a272e5f64512d97bf489121c5e</a></td></tr><tr><td><i class="fa-chart-simple-horizontal">:chart-simple-horizontal:</i> <strong>Rapport</strong></td><td>Exportez les événements Wallet au niveau de la carte pour l’analyse des campagnes, la révision au niveau de l’enregistrement et les rapports externes.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/61b02f8a93dabb62df2da806d4904fee0b9622c3">/spaces/tJnneV8b22BGeGPcyzLG/pages/61b02f8a93dabb62df2da806d4904fee0b9622c3</a></td></tr><tr><td><i class="fa-plug">:plug:</i> <strong>Envoyez les événements Wallet à vos outils</strong></td><td>Transférez en temps réel les événements d’installation, de désinstallation, de scan et de notification vers les outils CRM, CDP, BI et d’entrepôt de données.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/fa2610bb0e3d7843449c5fad6c5d4a912fb8c51c">/spaces/tJnneV8b22BGeGPcyzLG/pages/fa2610bb0e3d7843449c5fad6c5d4a912fb8c51c</a></td></tr><tr><td><i class="fa-gear-api">:gear-api:</i> <strong>Interrogez vos données — API Insights</strong></td><td>Interrogez programmatiquement les événements Wallet avec l’API Insights pour les tableaux de bord, les rapports automatisés et les workflows BI.</td><td><a href="/spaces/tJnneV8b22BGeGPcyzLG/pages/7db03f8ff912c2b652ddec57660acf48ade138fe">/spaces/tJnneV8b22BGeGPcyzLG/pages/7db03f8ff912c2b652ddec57660acf48ade138fe</a></td></tr></tbody></table>

Commencez par **Statistiques** pour une vue d’ensemble visuelle. Utilisez **Liste des cartes** et **Détails de la carte** pour une enquête au niveau de l’enregistrement lorsqu’une carte doit être trouvée, vérifiée ou escaladée.

Utilisez **Définitions des KPI** et **Ce que The Wallet Crew suit** pour comprendre comment les indicateurs sont calculés, comment les installations sont comptabilisées et où les limites de la plateforme s’appliquent.

Utilisez **Rapport** pour des exportations au niveau de l’enregistrement. Lorsque les données des événements Wallet doivent quitter The Wallet Crew en continu ou alimenter d’autres systèmes, utilisez **Envoyez les événements Wallet à vos outils** et **Interrogez vos données — API Insights**. Le premier guide couvre la livraison en temps réel et les schémas de synchronisation. Le second couvre l’interrogation programmatique pour les tableaux de bord, les workflows BI et les rapports automatisés.


# Tableaux de bord d’analytique

Comprenez les performances du Wallet, de l’inscription et des liens dans la section Analytique.

Le Wallet Crew comprend trois tableaux de bord dans la **Analytics** section de la console d'administration. Chaque tableau de bord couvre une étape différente du cycle de vie du programme Wallet.

Tous les tableaux de bord incluent un sélecteur de plage de dates. Il est défini par défaut sur **30 derniers jours**. Le **Wallets** tableau de bord prend également en charge le filtrage et l'export CSV.

<details>

<summary><strong>Exemples réels</strong></summary>

* Une marque de distribution compare les sauvegardes dans le Wallet par canal d'acquisition après le lancement d'une campagne.
* Un organisateur d'événements suit l'activité du formulaire d'inscription avant la mise en vente des billets.
* Une équipe en magasin identifie quels codes QR génèrent le plus de sauvegardes dans le Wallet.

</details>

## Wallets

**Emplacement :** **Analytics** → **Wallets**

Le **Wallets** tableau de bord fournit une vue en direct d'un programme Wallet. Il suit l'émission, l'adoption, les retraits, la performance des sources et la répartition des Wallets pendant la période sélectionnée.

Utilisez-le pour évaluer l'impact d'une campagne, repérer des changements inattendus et comparer les résultats par source, modèle ou métadonnées de carte.

### KPI

Les tuiles KPI séparent l'émission, l'adoption et l'attrition. Chaque tuile compare les résultats avec la période équivalente précédente.

* **Cartes créées** — Nombre total d'enregistrements de cartes créés pendant la période. La création ne confirme pas l'adoption du Wallet.
* **Cartes installées** — Cartes enregistrées dans Apple Wallet ou Google Wallet pendant la période. Cela mesure l'adoption.
* **Cartes désinstallées** — Cartes supprimées de chaque appareil où elles étaient installées. Cela mesure l'attrition.

Comparez **Cartes créées** et **Cartes installées** pour comprendre [le taux d'activation](/guides-monitoring/fr/monitor/definitions-des-kpi). Le taux est calculé comme suit : `Cartes installées ÷ Cartes créées`.

{% hint style="info" %}
Cartes créées ≠ Cartes installées. Une carte créée n'est pas nécessairement enregistrée dans un Wallet.
{% endhint %}

### Graphiques

**Évolution des installations** montre le volume quotidien d'installations. Utilisez-le pour identifier les changements après des envois, des lancements ou des campagnes en magasin.

**Répartition des cartes** répartit les installations entre Apple Wallet et Google Wallet. La répartition des Wallets aide à planifier des actions spécifiques au Wallet. Google Wallet limite les envois à trois mises à jour par carte toutes les 24 heures.

### Répartition par source

Le tableau de répartition compare les canaux et les dimensions de carte qui génèrent des sauvegardes dans le Wallet. Son sélecteur de regroupement est défini par défaut sur **Medium**, ce qui correspond à `source.medium`.

#### Options de regroupement

Les regroupements par source incluent :

* **Medium** — Des canaux de distribution, tels que `email-crm`, `ecomm`, ou `trigger-crm`.
* **Tag** — Des tags de campagne ou de segment associés à la source d'installation.
* **URL** et **Hôte** — La page ou le domaine exact contenant le **Ajouter au Wallet** bouton.

Tout champ de métadonnées de carte peut également regrouper les résultats. Par exemple, utilisez `storeId` ou `storeName` pour comparer des magasins, des régions, des partenaires ou des segments.

#### Colonnes du tableau

Les regroupements par source affichent la valeur source et **Cartes installées**. Les regroupements par métadonnées affichent la valeur de métadonnées, **Cartes créées**, **Cartes installées**, et [**taux d'activation**](/guides-monitoring/fr/monitor/definitions-des-kpi).

#### Filtres et exportation

Utilisez **Ajouter un filtre** pour vous concentrer sur un modèle ou une valeur de métadonnées. **Exporter** télécharge la vue actuelle du tableau sous forme de fichier CSV.

### Plage de dates

Le sélecteur de dates contrôle chaque tuile, graphique et tableau du tableau de bord. Les variations en pourcentage utilisent la période équivalente immédiatement précédente. Par exemple, une sélection de sept jours est comparée aux sept jours précédents.

## Inscriptions

**Emplacement :** **Analytics** → **Inscriptions**

Les métriques d'inscription suivent l'activité des profils clients générée par les formulaires d'inscription. Utilisez ce tableau de bord pour surveiller la création et les mises à jour des profils pendant la période sélectionnée.

### KPI

* **Client créé ou mis à jour** — Nombre total d'opérations de création ou de mise à jour de profils.
* **Client créé** — Nouveaux profils clients créés.
* **Client mis à jour** — Mises à jour des profils clients existants.

### Graphique

**Inscription des clients au fil du temps** montre l'activité des profils clients sur la période sélectionnée.

## Liens

**Emplacement :** **Analytics** → **Liens**

Les métriques de liens suivent l'utilisation des codes QR et des liens de redirection. Utilisez ce tableau de bord pour mesurer les performances de distribution en magasin ou sur site.

### KPI

* **Codes QR scannés** — Nombre total de scans pendant la période sélectionnée.

### Graphique

**Codes QR scannés au fil du temps** montre l'activité de scan sur la période sélectionnée.

### Tableau de répartition

Le tableau de répartition montre quels liens individuels ou codes QR ont généré le plus de scans. Il comprend les colonnes suivantes :

* **Clé** — L'identifiant du lien.
* **Nombre** — Le nombre total de scans.

## FAQ

<details>

<summary>Quelle plage de dates s'applique à un tableau de bord ?</summary>

Le sélecteur de plage de dates contrôle l'ensemble du tableau de bord. Il est défini par défaut sur **30 derniers jours**. Sur **Wallets**, l'export utilise la vue actuelle du tableau.

</details>

<details>

<summary>Comment Wallets peut-il se concentrer sur un modèle de carte ?</summary>

Dans **Analytics** → **Wallets**, sélectionnez **Ajouter un filtre** et restreignez le tableau de bord au modèle requis.

</details>

<details>

<summary>Quel tableau de bord mesure la performance des codes QR ?</summary>

Utilisez **Analytics** → **Liens**. Le tableau de bord affiche le nombre total de scans, l'activité de scan dans le temps et les résultats par clé de lien.

</details>

<details>

<summary>Pourquoi les Cartes créées sont-elles souvent plus nombreuses que les Cartes installées ?</summary>

La création mesure l'émission. L'installation mesure l'adoption. Une carte peut être émise sans être enregistrée dans un Wallet.

</details>

<details>

<summary>Pourquoi les Cartes désinstallées peuvent-elles rester faibles lorsque des suppressions ont lieu ?</summary>

La métrique ne compte une carte que lorsque chaque installation active a été supprimée. Une carte encore installée sur un autre appareil n'est pas comptabilisée.

</details>


# Liste des Cartes

Trouvez rapidement une Carte par identifiant, modèle, métadonnées ou date, puis ouvrez sa page de détails.

La liste des Cartes affiche toutes les Cartes d’un programme. Utilisez-la pour trouver une Carte à l’aide de n’importe quel identifiant, filtrer par modèle ou par date, et ouvrir la page de détail de la Carte pour afficher l’historique complet de cette Carte.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un agent du support recherche un numéro de fidélité pour répondre à une demande client.
* Un responsable des opérations filtre par modèle et par date de création pour vérifier un problème de lot.
* Un administrateur de programme ouvre une Carte pour vérifier son état actuel et son historique.

</details>

## Comment ouvrir la liste des Cartes

La liste des Cartes est le point de départ pour trouver et vérifier une Carte. Elle regroupe toutes les Cartes disponibles du compte dans une seule vue.

{% stepper %}
{% step %}

### Ouvrez le back-office

Connectez-vous au back-office de The Wallet Crew.
{% endstep %}

{% step %}

### Accédez à **Wallet > Cartes**

La liste charge toutes les Cartes disponibles. Par défaut, les mises à jour les plus récentes apparaissent en premier.
{% endstep %}
{% endstepper %}

## Trouver une Carte

Les contrôles de recherche et de filtre en haut de la liste réduisent rapidement l’ensemble des résultats. Commencez par l’identifiant déjà disponible dans le dossier client, puis ajoutez des filtres de modèle ou de date si nécessaire.

**Filtres disponibles :**

* **ID de la Carte** — l’identifiant interne de la plateforme pour la Carte.
* **ID externe** — tout identifiant externe lié à la Carte, comme un ID client CRM, un numéro de fidélité ou une référence de réservation. C’est la méthode la plus courante pour les équipes support afin de localiser la Carte d’un client spécifique.
* **Modèle de Carte** — restreint la liste aux Cartes créées à partir d’un seul modèle.
* **Champs de métadonnées** — filtre selon n’importe quel champ de métadonnées défini sur les Cartes, tel que `storeId` ou `programmeId`. Ces champs dépendent de la configuration du programme et peuvent varier d’un programme à l’autre.
* **Date de création** — affiche uniquement les Cartes créées sur une plage de dates.
* **Dernière mise à jour** — affiche uniquement les Cartes mises à jour sur une plage de dates.

{% hint style="info" %}
Pour trouver une Carte pour un client spécifique, filtrez par **ID externe** en utilisant l’identifiant envoyé lors de la création de la Carte — par exemple, un ID CRM, un numéro de fidélité ou une référence de réservation.
{% endhint %}

## Colonnes

Les colonnes par défaut offrent une vue opérationnelle rapide de chaque Carte.

| Colonne               | Ce qu’elle affiche                                                 |
| --------------------- | ------------------------------------------------------------------ |
| ID de la Carte        | L’identifiant interne de la plateforme                             |
| Date de création      | Quand l’enregistrement de la Carte a été créé                      |
| Dernière mise à jour  | Quand la Carte a été modifiée ou mise à jour pour la dernière fois |
| Modèle                | À partir de quel modèle de Carte la Carte a été créée              |
| ID externe            | Les identifiants externes liés à cette Carte                       |
| Statut d’installation | Indique si la Carte est actuellement installée dans un Wallet      |

Utilisez le sélecteur de colonnes pour ajouter ou supprimer des colonnes. Les champs de métadonnées sont disponibles comme colonnes supplémentaires, et la disposition sélectionnée est enregistrée dans le navigateur.

## Ouvrir une Carte

Cliquez sur n’importe quelle ligne de la liste pour ouvrir la page de détail de la Carte correspondante.

Pour savoir ce qui peut être consulté une fois la Carte ouverte, voir [Détails de la Carte](/guides-monitoring/fr/monitor/details-de-la-carte).

## FAQ

<details>

<summary>Quel filtre faut-il utiliser en premier pour un dossier client ?</summary>

**ID externe** est généralement le point de départ le plus rapide. Il correspond à l’identifiant envoyé depuis le système source lors de la création de la Carte.

</details>

<details>

<summary>Pourquoi le filtrage par ID externe affiche-t-il plusieurs lignes pour le même identifiant ?</summary>

Le back-office affiche toutes les Cartes créées avec cet ID externe. Un ID externe ne garantit pas une correspondance un-à-un avec une Carte.

Plusieurs lignes résultent généralement d’inscriptions de test ou d’appels API répétés. Pour identifier la Carte active, vérifiez la **Statut d’installation** colonne, puis comparez la plus récente **Dernière mise à jour** valeur.

Pour le modèle technique derrière les identifiants externes et la récupération des données, voir [Données de Carte et synchronisation](/developers-guides/fr/pass-architecture/pass-data-and-sync).

</details>

<details>

<summary>Pourquoi les filtres de métadonnées diffèrent-ils d’un programme à l’autre ?</summary>

Les champs de métadonnées proviennent de la configuration de Carte de chaque programme. Un programme peut utiliser `storeId`, tandis qu’un autre peut utiliser `eventId` ou `membershipTier`.

</details>

<details>

<summary>Pourquoi les colonnes visibles sont-elles différentes dans un autre navigateur ?</summary>

La configuration des colonnes est enregistrée dans le navigateur local. Un autre navigateur ou appareil peut afficher une disposition enregistrée différente.

</details>


# Détails de la Carte

Consultez une Carte dans son intégralité, y compris ses identifiants, son état, ses métadonnées et son historique enregistré.

Pour trouver une Carte spécifique, consultez [Liste des Cartes](/guides-monitoring/fr/monitor/liste-des-cartes).

La page de détail de la Carte offre une vue complète d'une Carte — son état actuel, les données qu'elle contient, son historique de notifications et son journal complet des événements. Elle permet également de déclencher une mise à jour de la Carte ou d'envoyer une notification directement depuis cette page.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un agent du support vérifie si la Carte d'un client est toujours installée et renvoie le code QR.
* Un responsable des opérations consulte l'historique des événements après une mise à jour push.
* Un administrateur de programme vérifie les métadonnées et l'historique des notifications avant d'escalader un dossier.

</details>

## Les quatre onglets

La page de détail est organisée en quatre onglets. Chaque onglet répond à une question opérationnelle différente.

### Général

L' **Général** onglet affiche l'état actuel de la Carte. C'est l'endroit le plus rapide pour confirmer les principaux détails opérationnels.

L'onglet comprend :

* **Modèle** — à partir de quel modèle de Carte cette Carte a été créée.
* **Titre / Sous-titre** — les valeurs actuellement affichées dans les champs d'en-tête de la Carte.
* **Date de création** — quand l'enregistrement de la Carte a été créé sur la plateforme.
* **Dernière mise à jour** — quand la Carte a été modifiée pour la dernière fois.
* **État d'installation** — indique si la Carte est installée dans Apple Wallet, Google Wallet, les deux ou aucun des deux. L'état d'installation sur Apple et sur Google apparaît séparément.
* **Installations actives** — le nombre de Wallets où la Carte est actuellement installée. Pour Apple, cela compte les appareils individuels, y compris l'Apple Watch. Pour Google, cela compte les comptes Google.

{% hint style="info" %}
Le nombre d'installations actives de `0` signifie que la Carte a été retirée de tous les Wallets. L'enregistrement de la Carte existe toujours sur la plateforme — il n'a pas été supprimé.
{% endhint %}

### Données

L' **Données** L'onglet affiche toutes les données associées à la Carte. C'est utile lorsque le contenu visible de la Carte doit être vérifié par rapport à l'enregistrement sous-jacent.

Les données sont regroupées en trois catégories :

* **Données supplémentaires** — informations stockées directement dans l'enregistrement de la Carte. Ces valeurs sont généralement définies lorsque la Carte est créée ou mise à jour.
* **Données externes** — informations récupérées à partir des systèmes sources connectés. Cela montre les données les plus récentes disponibles lorsque la Carte a été actualisée pour la dernière fois.
* **Métadonnées** — champs supplémentaires attachés à la Carte, comme `storeId`, `programmeId`, ou tout champ personnalisé utilisé pour le filtrage et les rapports.

### Notifications

L' **Notifications** L'onglet répertorie chaque notification push envoyée à cette Carte. Utilisez-le pour confirmer quel message a été envoyé et quand il l'a été.

Chaque ligne affiche :

* **Date** — quand la notification a été envoyée.
* **Message** — le contenu de la notification qui a été envoyé.
* **Type d'appareil** — Apple ou Google.

{% hint style="info" %}
La confirmation de livraison n'est pas disponible. Apple et Google n'exposent pas si une notification a été reçue par l'appareil.
{% endhint %}

### Historique

L' **Historique** L'onglet affiche le journal complet des événements pour cette Carte. Utilisez-le pour comprendre ce qui s'est passé, dans quel ordre et avec quelles données enregistrées.

Tous les événements de la plateforme pour cette Carte sont répertoriés, notamment :

| Événement                  | Ce que cela signifie                                        |
| -------------------------- | ----------------------------------------------------------- |
| Carte:Créée                | L'enregistrement de la Carte a été créé sur la plateforme   |
| Carte:Installée            | Un client a ajouté la Carte à Apple Wallet ou Google Wallet |
| Carte:Désinstallée         | Un client a retiré la Carte de son Wallet                   |
| Carte:Actualisée           | Les données de la Carte ont été modifiées                   |
| Carte:Mise à jour envoyée  | Une mise à jour push a été livrée à un appareil             |
| Carte:Scannée              | Le code-barres de la Carte a été scanné sur un lecteur      |
| Carte:Notification envoyée | Une notification push a été envoyée à cette Carte           |

Chaque ligne d'événement affiche l'horodatage de l'événement et toutes les données enregistrées avec l'événement.

L'historique est complet. Tous les événements sont affichés sans limite de durée.

Pour l'export en masse sur de nombreuses Cartes, utilisez [Rapport](/guides-monitoring/fr/monitor/report).

## Actions

Trois actions sont disponibles en haut de la page de détail de la Carte. Ces actions aident à résoudre les cas courants de support et d'exploitation sans quitter la page.

### Mise à jour push

**Mise à jour push** actualise la Carte à l'aide des dernières données disponibles. Elle met toujours à jour l'enregistrement de la Carte sur The Wallet Crew.

Une notification de confirmation apparaît lorsque la mise à jour est mise en file d'attente.

#### Comportement des notifications push

Une mise à jour de Carte a deux effets distincts : une mise à jour du back-end et une notification sur l'appareil.

Le back-end met toujours à jour la Carte, qu'elle soit installée ou non. Les identifiants de Carte, les métadonnées et les horodatages sont mis à jour et stockés sur The Wallet Crew.

Une notification sur l'appareil est envoyée uniquement lorsque la Carte est actuellement installée dans Apple Wallet ou Google Wallet. Aucune notification sur l'appareil n'est envoyée lorsque la Carte est désinstallée.

Les mises à jour du back-end sont conservées. Si la Carte est réinstallée plus tard, le Wallet reçoit la dernière version stockée sur The Wallet Crew.

Utilisez [les événements Carte:Installée et Carte:Désinstallée](/developers-guides/fr/integration-guides/wallet/pass-lifecycle#wallet-removal) pour suivre l'installation et la suppression du Wallet.

### Envoyer une notification

**Envoyer une notification** envoie une notification push à tous les appareils où cette Carte est installée. Utilisez-la pour alerter le client, par exemple pour l'informer d'un changement de solde ou d'une nouvelle offre.

Cette action ne reconstruit pas le contenu de la Carte.

### Afficher le code QR

**Afficher le code QR** affiche le code QR d'ajout au Wallet de la Carte. Utilisez-le pour renvoyer le lien d'installation à un client, par exemple sous forme de capture d'écran ou par e-mail.

## FAQ

<details>

<summary>Quand faut-il vérifier en premier l'onglet Général ?</summary>

Commencez par **Général** lorsqu'il s'agit de confirmer si la Carte existe, quel modèle elle utilise, quand elle a été modifiée pour la dernière fois et si elle est toujours installée.

</details>

<details>

<summary>Quelle est la différence entre Données et Historique ?</summary>

**Données** affiche les valeurs actuelles associées à la Carte. **Historique** affiche la séquence d'événements qui sont arrivés à cette Carte au fil du temps.

</details>

<details>

<summary>Quand faut-il utiliser Rapport plutôt que Détails de la Carte ?</summary>

Utilisez **Détails de la Carte** pour une enquête sur une seule Carte. Utilisez [Rapport](/guides-monitoring/fr/monitor/report) lorsque des données d'événements sont nécessaires en masse sur de nombreuses Cartes.

</details>

<details>

<summary>Puis-je utiliser les mises à jour échouées pour détecter les Cartes désinstallées ?</summary>

Non. Les mises à jour n'échouent jamais parce qu'une Carte est désinstallée. La mise à jour du back-end réussit toujours. La notification sur l'appareil dépend d'une installation active dans Apple Wallet ou Google Wallet.

Utilisez [les événements Carte:Installée et Carte:Désinstallée](/developers-guides/fr/integration-guides/wallet/pass-lifecycle#wallet-removal) pour suivre la suppression du Wallet.

</details>


# Définitions des KPI

Définissez les métriques utilisées dans le tableau de bord Statistiques et comment les interpréter au fil du temps.

Cette page définit chaque métrique utilisée dans le tableau de bord des statistiques afin que les données puissent être interprétées avec précision et comparées dans le temps.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une équipe marketing compare **Cartes créées** et **taux d’activation** après une campagne e-mail pour voir si la distribution a atteint efficacement les Wallets.
* Une équipe opérations examine **Cartes désinstallées** et **taux d’attrition** après une vague d’expirations saisonnières pour comprendre si le renouvellement fonctionne.
* Une équipe croissance vérifie les installations par **Support**, **Étiquette**, et **Hôte** pour identifier quels points d’entrée génèrent le plus d’adoption du Wallet.

</details>

## Métriques principales

Les métriques ci-dessous sont les principaux points de référence utilisés dans le [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) tableau de bord. Le tableau récapitulatif facilite la recherche rapide, tandis que les définitions ci-dessous expliquent comment interpréter chaque nombre dans son contexte.

| Métrique                                                                                                    | Formule                                                                                              | Où la trouver                                                                                                                                                              |
| ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Cartes créées](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)        | `COUNT(Carte:Created)` dans la période sélectionnée                                                  | [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) vignettes récapitulatives                                              |
| [Cartes installées](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)    | `COUNT(Carte:Installed)` dans la période sélectionnée                                                | [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) vignettes récapitulatives                                              |
| [Cartes désinstallées](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) | `COUNT` des cartes dont le nombre d’installations actives a atteint `0` dans la période sélectionnée | [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) vignettes récapitulatives                                              |
| [taux d’activation](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)    | `(Cartes installées ÷ Cartes créées) × 100`                                                          | [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) tableau de répartition                                                 |
| [taux d’attrition](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)     | `(Cartes désinstallées ÷ installations actives au début de la période) × 100`                        | Utilisé comme métrique d’interprétation avec [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) vignettes récapitulatives |

### [Cartes créées](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**Cartes créées** correspond au nombre total d’enregistrements de cartes créés sur la plateforme pendant la période sélectionnée.

La formule est `COUNT` de `Carte:Created` événements sur la période.

Cette métrique mesure le volume de distribution. Comparez-la à **Cartes installées** pour comprendre quelle part des cartes émises a atteint un Wallet.

### [Cartes installées](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**Cartes installées** correspond au nombre de cartes ajoutées dans Apple Wallet ou Google Wallet pendant la période sélectionnée.

La formule est `COUNT` de `Carte:Installed` événements sur la période.

Sur Apple, cela compte par appareil. Sur Google, cela compte par compte. Pour le modèle de suivi complet, voir [Ce que The Wallet Crew suit](/guides-monitoring/fr/monitor/ce-que-the-wallet-crew-suit).

C’est le principal signal d’engagement. Une carte dans un Wallet peut recevoir des notifications, être scannée et offrir une valeur continue.

### [Cartes désinstallées](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**Cartes désinstallées** correspond au nombre de cartes totalement supprimées de tous les Wallets pendant la période sélectionnée.

La formule est `COUNT` de cartes dont le nombre d’installations actives a atteint `0` pendant la période.

Retirer une carte d’un appareil ne compte pas comme une désinstallation si elle reste présente sur un autre appareil.

C’est le principal signal d’attrition. Suivez-le avec **Cartes installées** pour comprendre l’évolution nette de la base Wallet.

### [taux d’activation](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**taux d’activation** correspond à la part des cartes créées qui ont été installées au moins une fois.

La formule est `(Cartes installées ÷ Cartes créées) × 100`.

Exemple : `23 500 installées ÷ 28 400 créées = taux d’activation de 82,7 %`.

Cette métrique mesure l’efficacité de la distribution. Un taux faible signifie que des cartes sont créées mais n’atteignent pas les Wallets. Examinez le canal de distribution et les frictions dans le **Ajouter à Wallet** flux.

La distribution par e-mail génère généralement `20–40 %`. La distribution contextuelle in-app peut dépasser `70%`.

### [taux d’attrition](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**taux d’attrition** correspond à la part des détenteurs actifs de cartes qui ont retiré leur carte pendant la période.

La formule est `(Cartes désinstallées ÷ installations actives au début de la période) × 100`.

Un taux d’attrition élevé suit souvent une campagne au contenu non pertinent, ou l’expiration d’une carte sans renouvellement. Analysez les pics par rapport au calendrier des campagnes.

## Métriques de répartition par source

Ces métriques expliquent d’où proviennent les cartes installées. Elles aident à comparer les canaux, les campagnes et les points d’entrée au niveau des pages dans [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f).

### [Cartes installées par support](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**Cartes installées par support** regroupe les installations par canal de distribution.

Utilisez ceci pour comparer des canaux comme l’e-mail, le commerce électronique ou la distribution en magasin. `Non spécifié` signifie que la carte a été installée sans source suivie, par exemple via un transfert d’appareil ou un partage.

### [Cartes installées par tag](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**Cartes installées par tag** regroupe les installations par campagne ou par tag de segment.

Utilisez ceci pour comparer les variantes de campagne, les audiences ou les distributions spécifiques à un partenaire. Les tags sont définis lors de la génération du lien de distribution.

### [Cartes installées par URL / hôte](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f)

**Cartes installées par URL / hôte** regroupe les installations par l’URL de la page ou le domaine où le **Ajouter à Wallet** bouton s’affichait.

Utilisez ceci pour comparer les pages d’atterrissage, les parcours e-commerce et les domaines. Cela aide à identifier quels points d’entrée favorisent le plus efficacement l’adoption du Wallet.

## Comprendre l’indicateur de variation en %

Chaque tuile KPI compare la période sélectionnée à la période précédente équivalente. Une **30 derniers jours** vue est comparée aux 30 jours précédents.

* Flèche verte vers le haut = amélioration par rapport à la période précédente
* Flèche rouge vers le bas = baisse par rapport à la période précédente

Pour **Cartes désinstallées**, une augmentation s’affiche en rouge car davantage d’attrition est un résultat moins favorable.

## FAQ

<details>

<summary>Pourquoi les Cartes installées peuvent-elles être plus élevées que prévu dans Apple Wallet ?</summary>

Apple compte les installations par appareil. Une même personne peut générer plus d’une installation en ajoutant une carte sur plusieurs appareils ou en changeant de téléphone.

</details>

<details>

<summary>Pourquoi les Cartes désinstallées ne correspondent-elles pas toujours aux simples événements de suppression ?</summary>

Une carte est comptabilisée comme désinstallée uniquement lorsque son nombre d’installations actives atteint zéro. Si elle existe encore sur un autre appareil, elle n’est pas encore totalement désinstallée.

</details>

<details>

<summary>Que signifie généralement un faible taux d’activation ?</summary>

Cela signifie généralement que des cartes sont émises, mais que suffisamment de personnes n’achèvent pas le **Ajouter à Wallet** étape. Les premières zones à examiner sont la qualité du canal, la visibilité et les frictions dans le parcours d’installation.

</details>


# Ce que The Wallet Crew suit

Comprenez quels événements Wallet The Wallet Crew suit, comment les installations sont comptabilisées et où Apple et Google fixent les limites.

The Wallet Crew suit l’activité des Cartes grâce aux événements générés à chaque moment significatif du cycle de vie de la Carte. Cette page explique ce qui est suivi, comment fonctionne le comptage des installations et ce qui ne peut pas être suivi, ainsi que les règles des plateformes Apple et Google à l’origine de ces limites.

Cela facilite la configuration des rapports, l’alignement des attentes entre les équipes et la décision des signaux qui peuvent être utilisés pour l’analyse des campagnes ou le suivi opérationnel.

<details>

<summary><strong>Exemples concrets du monde réel</strong></summary>

* Une équipe marketing vérifie si les installations de Wallet peuvent être rattachées à l’e-mail, au e-commerce ou au trafic en magasin.
* Une équipe opérationnelle confirme si une Carte supprimée d’un appareil est considérée comme complètement désinstallée ou encore active ailleurs.
* Une équipe CRM vérifie quels signaux de Wallet peuvent être synchronisés automatiquement et lesquels n’existent pas sur Apple ou Google.

</details>

## Ce que The Wallet Crew suit

The Wallet Crew enregistre les événements du cycle de vie que les plateformes de Wallet exposent et que le flux de Carte peut générer de manière fiable. Certains événements décrivent la Carte elle-même, tandis que d’autres décrivent ce qui s’est passé sur un Wallet ou un appareil.

### Création de Carte

Un enregistrement de Carte est créé dans The Wallet Crew lorsqu’une Carte est émise. Cela peut se produire via l’API, après la création du compte, lorsqu’une maquette de Carte est affichée ou via un connecteur.

Une Carte créée existe dans la plateforme même si personne ne l’a encore ajoutée à un Wallet. La création montre l’émission. Elle ne confirme pas l’adoption.

### Installation de Carte

La plateforme suit lorsqu’une Carte est ajoutée à un Wallet. Le comptage des installations fonctionne différemment dans Apple Wallet et Google Wallet, car chaque fournisseur définit l’installation à sa manière.

* **Apple Wallet** suit chaque appareil individuellement. Ajouter la même Carte à un iPhone et à une Apple Watch compte pour deux installations. Le passage à un nouveau téléphone crée également une nouvelle installation.
* **Google Wallet** suit l’installation par compte Google. Plusieurs appareils Android connectés au même compte comptent pour une seule installation.

Deux compteurs existent pour chaque Carte :

* **Installations actives** — diminue lorsque la Carte est retirée d’un Wallet
* **Installations totales** — cumulatives et ne diminuent jamais

Ces compteurs servent à des fins différentes. Les installations actives montrent combien de présences valides dans Wallet existent encore. Les installations totales montrent combien de fois la Carte a déjà été installée.

### Source d’installation

Lorsqu’un client appuie sur un **Ajouter à Wallet** bouton, The Wallet Crew capture le contexte source de cette action. Cela aide à relier l’adoption de Wallet à la campagne ou à la page qui l’a déclenchée.

* **Média** — le canal de distribution, comme l’e-mail, le e-commerce ou le magasin
* **Étiquette** — étiquettes personnalisées de campagne ou de segment
* **URL** — la page exacte où le bouton était affiché
* **Hôte** — le domaine de cette page

Les données source ne sont pas disponibles lorsqu’une Carte est installée via un transfert d’appareil, un partage de téléphone ou d’autres mécanismes au niveau du système. Dans ces cas, la plateforme de Wallet termine l’installation sans renvoyer le contexte d’acquisition d’origine.

### Suppression de Carte

The Wallet Crew suit lorsqu’une Carte est retirée d’un Wallet. Chaque suppression diminue le nombre d’installations actives.

Lorsque le nombre d’installations actives atteint zéro, la Carte est complètement désinstallée. Cela compte pour l’analyse du churn, car une Carte retirée d’un appareil peut encore rester active sur un autre.

### Mises à jour envoyées

Chaque mise à jour push livrée à un appareil est enregistrée. Cela permet de consulter l’activité des mises à jour dans le temps et de comprendre à quelle fréquence le contenu de la Carte est actualisé.

### Scans

Chaque scan de code-barres est enregistré, y compris les données scannées et le type de scan. Cela rend l’historique des scans utile pour l’utilisation en caisse et la vérification opérationnelle.

### Notifications push envoyées

Chaque notification push envoyée à un appareil est enregistrée, y compris son contenu et le fournisseur de Wallet. Cela confirme que la notification a été envoyée via la plateforme.

## Ce qui ne peut pas être suivi

{% hint style="warning" %}
Il s’agit de décisions de confidentialité prises par Apple et Google pour protéger les clients, et non de limitations de The Wallet Crew. Chaque plateforme de Wallet fait face aux mêmes contraintes.
{% endhint %}

Certains signaux semblent naturellement attendus, mais les fournisseurs de Wallet ne les exposent pas. Lorsque la plateforme ne reçoit pas les données, elle ne peut pas les signaler ensuite.

| Ce à quoi on pourrait s’attendre            | Pourquoi ce n’est pas disponible                                                                                                                           |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Ouvertures ou vues de Carte                 | Apple et Google n’indiquent pas si un client a consulté une Carte. Il n’existe pas d’équivalent du taux d’ouverture d’un e-mail pour les Cartes de Wallet. |
| Taux de clic sur les notifications push     | La livraison peut être confirmée. Le fait que le client ait appuyé sur la notification n’est indiqué par aucune des deux plateformes.                      |
| Activations déclenchées par géolocalisation | Les déclencheurs de localisation se déclenchent sur l’appareil. L’appareil ne renvoie pas d’information à l’émetteur lorsque cela se produit.              |
| Comptage par appareil sur Google            | Google suit l’installation par compte. Trois appareils Android sur un seul compte comptent toujours pour une seule installation.                           |

## État de la Carte — annulée et expirée

The Wallet Crew n’impose pas de modèle d’état fixe aux Cartes. L’état de la Carte provient des données source et est mappé par le moteur de modèles vers les attributs de Wallet Apple et Google qui contrôlent l’affichage et le comportement.

| Ce qui doit être exprimé           | Apple                                                          | Google                                                                               |
| ---------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| La Carte est utilisée ou consommée | `voided: true` — apparaît grisée dans Apple Wallet             | `state: COMPLETED` ou `INACTIVE` — passe dans la **Expiré** section                  |
| La Carte a expiré avec le temps    | `expirationDate` — retirée des Cartes actives après cette date | `validTimeInterval` — passe automatiquement à l’état expiré à la fin de l’intervalle |

Lorsque les données source changent, The Wallet Crew met à jour la Carte et pousse automatiquement la modification vers l’appareil. Cela maintient l’état du Wallet aligné sur l’état métier sans intervention manuelle.

## Utiliser ces données

Les événements de Wallet suivis sont utiles dans les flux de travail marketing, opérationnels et CRM. Ils aident les équipes à agir sur de vrais signaux du cycle de vie plutôt que sur des hypothèses.

* Déclencher une mise à jour CRM lorsqu’une Carte est installée pour la première fois afin de confirmer l’adhésion à Wallet
* Identifier les clients qui ont désinstallé leur Carte comme signal de churn
* Attribuer les installations au canal source avec **Média** et **Étiquette**
* Utiliser les événements de scan pour confirmer l’utilisation au point de vente

Pour une utilisation en aval, voir [Interrogez vos données — API Insights](/guides-monitoring/fr/monitor/interrogez-vos-donnees-api-insights) pour des requêtes programmatiques et [Envoyer les événements de Wallet vers vos outils](/guides-monitoring/fr/monitor/sync-pass-installation-status-to-your-crm) pour une diffusion en temps réel.

## FAQ

<details>

<summary>Pourquoi une personne peut-elle générer plus d’une installation ?</summary>

Dans Apple Wallet, l’installation est comptée par appareil. La même personne peut installer une Carte sur un iPhone et une Apple Watch, ou générer une nouvelle installation après avoir changé de téléphone.

</details>

<details>

<summary>Pourquoi une Carte n’est-elle pas comptée comme désinstallée après une seule suppression ?</summary>

Une Carte n’est comptée comme désinstallée que lorsque son nombre d’installations actives atteint zéro. Si elle existe encore sur un autre appareil ou dans un autre contexte de Wallet, elle reste active.

</details>

<details>

<summary>Pourquoi la source d’installation est-elle parfois manquante ?</summary>

Les données source sont capturées lorsque l’installation démarre depuis un **Ajouter à Wallet** bouton suivi. Elles ne sont pas disponibles pour le transfert d’appareil, le partage de téléphone ou d’autres chemins d’installation au niveau du système.

</details>

<details>

<summary>The Wallet Crew peut-il suivre si une Carte a été ouverte ou consultée ?</summary>

Non. Apple et Google ne renvoient pas aux émetteurs les ouvertures ou vues de Carte. Il s’agit d’une règle de confidentialité de la plateforme de Wallet, pas d’une limitation de The Wallet Crew.

</details>


# Rapport

Exporter les événements Wallet au niveau de la Carte pour l’analyse des campagnes, l’enrichissement CRM et les rapports externes.

Le **Rapport** La page de rapport exporte les données d’événements au niveau de la carte, y compris les installations, les mises à jour, les suppressions, les scans et les notifications, filtrées par plage de dates et attributs de la carte. C’est la vue idéale lorsque les enregistrements sous-jacents comptent davantage que les totaux.

Utilisez cette page pour analyser en détail les performances des campagnes, enrichir les enregistrements CRM avec l’activité Wallet, ou alimenter des outils de reporting externes avec les données Wallet. Pour les tendances agrégées et les résumés KPI, utilisez [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f).

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une équipe marketing exporte les événements d’installation après l’envoi d’une campagne pour comparer les performances des canaux par `Support` ou `Étiquette`.
* Une équipe opérationnelle exporte les événements de désinstallation pour identifier les clients qui ne conservent plus la carte dans leur Wallet.
* Une équipe BI exporte les événements de scan pour étudier les schémas d’utilisation par lieu, magasin ou plage horaire.

</details>

## Quelles données peuvent être exportées

Le **Rapport** La page exporte une ligne par événement. Cela la rend utile pour l’analyse détaillée, le rapprochement et le traitement en aval.

Les types d’événements suivants sont disponibles à l’export :

* **Carte:Created** — lorsqu’un enregistrement de carte a été créé
* **Carte:Installed** — lorsqu’une carte a été ajoutée à Apple Wallet ou Google Wallet, y compris des détails sur la source d’installation tels que **Support**, **Étiquette**, **URL**, et **Hôte**
* **Carte:Uninstalled** — lorsqu’une carte a été retirée de tous les portefeuilles
* **Carte:Updated** — lorsque les données de la carte ont changé
* **Carte:UpdateSent** — lorsqu’une mise à jour push a été envoyée à un appareil
* **Carte:Scanned** — lorsqu’un code-barres de carte a été scanné
* **Carte:NotificationSent** — lorsqu’une notification push a été envoyée

Chaque export se concentre sur l’historique des événements plutôt que sur des totaux récapitulatifs. Cela permet de retracer ce qui s’est passé, quand cela s’est passé et quelle carte a été concernée.

Pour connaître la signification et les limites de chaque événement suivi, voir [Ce que The Wallet Crew suit](/guides-monitoring/fr/monitor/ce-que-the-wallet-crew-suit).

## Comment exporter

Le processus d’export est conçu pour un filtrage rapide et des rapports reproductibles. Commencez par la période, puis restreignez le périmètre aux événements et aux enregistrements de carte qui comptent.

{% stepper %}
{% step %}

### Sélectionnez une plage de dates

Choisissez la période à analyser. La plage sélectionnée détermine quels événements sont inclus dans le fichier.
{% endstep %}

{% step %}

### Choisissez les types d’événements

Sélectionnez les types d’événements à inclure dans l’export. Cela permet de concentrer le fichier sur l’activité nécessaire à la tâche.
{% endstep %}

{% step %}

### Appliquer des filtres

Filtrez par modèle ou par valeur de champ de métadonnées de carte. Cela aide à isoler une campagne, une famille de cartes, une région, un groupe de magasins ou tout autre segment suivi dans les données de carte.
{% endstep %}

{% step %}

### Exporter le fichier

Cliquez sur **Exporter** pour télécharger la sélection actuelle sous forme de fichier CSV. Le fichier peut ensuite être ouvert dans des outils tableur ou chargé dans des workflows CRM et BI.
{% endstep %}
{% endstepper %}

## Utilisation des données exportées

Les exports sont particulièrement utiles lorsqu’une équipe doit travailler au niveau des enregistrements. Ils prennent en charge le suivi opérationnel, l’examen des campagnes et l’analyse externe sans s’appuyer uniquement sur des tableaux de bord agrégés.

### Synchronisation CRM

Exportez les événements d’installation et faites-les correspondre à un identifiant stable de carte. Cela permet d’enrichir les fiches contacts avec le statut d’opt-in Wallet ou d’installation.

### Attribution des campagnes

Filtrez les événements d’installation par **Support** ou **Étiquette** pour comparer quels canaux ont généré le plus d’installations pour une campagne. Cela aide à relier l’adoption Wallet à la source qui l’a générée.

### Détection du churn

Exportez les événements de désinstallation pour identifier les clients qui ont retiré leur carte. Cela peut soutenir l’analyse du churn, les actions de reconquête ou les ajustements du parcours.

### Analyse des scans

Exportez les événements de scan pour analyser les schémas d’utilisation par lieu ou par heure de la journée. C’est utile lorsque l’objectif est de comprendre non seulement l’adoption, mais aussi l’utilisation réelle de la carte.

## Quand utiliser Rapport plutôt que Statistiques

**Rapport** est la vue détaillée. Elle exporte les lignes individuelles derrière l’activité Wallet.

**Statistiques** est la vue récapitulative. Elle affiche les tendances, les totaux et l’évolution des KPI pour un suivi plus rapide. Utilisez [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) lorsque l’objectif est d’examiner les performances du programme en un coup d’œil.


# Envoyer les événements Wallet vers vos outils

Envoyez les événements d’installation, de désinstallation, de scan et de notification du Wallet vers des outils CRM, CDP, BI et d’entrepôt de données avec des webhooks, des connecteurs personnalisés, l’API Carte ou l’API Insights.

The Wallet Crew ne verrouille pas les données dans la plateforme. Chaque événement émis dans un programme Wallet peut être envoyé vers un CRM, un CDP, un outil BI ou un entrepôt de données. Quatre voies d’intégration couvrent la plupart des besoins : **webhooks**, un **connecteur personnalisé**, l’ **API Carte** et l’ **API Insights**.

{% hint style="info" %}
Vos données de Wallet vous appartiennent. The Wallet Crew émet chaque événement de Carte en temps réel — vous décidez où il va et ce que vous en faites.
{% endhint %}

<details>

<summary><strong>Exemples concrets du monde réel</strong></summary>

* Une équipe CRM ou CDP envoie `Carte:Installed` des événements dans Braze ou Salesforce pour déclencher des parcours d’intégration après l’adoption du Wallet.
* Une équipe BI diffuse les événements Wallet vers BigQuery ou Snowflake, puis utilise l’API Insights pour suivre les installations hebdomadaires par `Média`, `Étiquette`, ou `Hôte`.
* Une équipe e-commerce conserve en temps réel l’état des installations dans sa pile avec des webhooks, puis utilise un backfill quotidien via l’API Carte pour corriger les écarts après des interruptions.

</details>

### Ce que signifie le « statut d’installation »

Le statut d’installation est un signal de cycle de vie émis lorsqu’un utilisateur ajoute ou supprime une Carte. Il couvre les installations et suppressions sur Apple Wallet et Google Wallet, et chaque Wallet peut changer d’état indépendamment.

C’est important car l’état d’installation dépend du Wallet. Le même client peut installer une Carte sur Apple Wallet, Google Wallet ou les deux, et chaque événement de suppression doit être interprété dans ce contexte.

{% hint style="info" %}
Assurez-vous que chaque Carte inclut un identifiant externe stable, comme `customerId` ou `email`. Cet identifiant est utilisé pour rapprocher les événements avec les enregistrements du reste de la pile.
{% endhint %}

### Choisissez la bonne méthode de synchronisation

Si vous voulez des mises à jour en temps réel, utilisez **webhooks** ou un **connecteur personnalisé**.

Si vous préférez des tâches batch ou des backfills, utilisez l’ **API Carte**.

Si vous avez surtout besoin de comptages et de tendances, utilisez **API Insights**.

### Commencez par l’API Insights pour une analyse agrégée

S’il n’est pas nécessaire de synchroniser par client et que l’objectif est d’interroger les tendances et les données agrégées, commencez par l’ **API Insights**API Insights. C’est la voie la plus rapide vers des questions comme « combien de Cartes ont été installées cette semaine par canal ? »

Utilisez Insights lorsque les comptages, les tendances et l’analyse groupée comptent plus que les mises à jour au niveau des enregistrements. Interrogez des événements tels que `Carte:Installed` et `Carte:Uninstalled` avec KQL.

Étape suivante : configurez l’authentification et lancez une première requête.

Voir [API Insights](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/insights-api.md).

Pour l’analyse agrégée au sein de The Wallet Crew, comparez [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) et [Rapport](/guides-monitoring/fr/monitor/report).

### Décidez quoi synchroniser dans vos outils

Commencez par définir la « vérité » que la pile doit stocker. La plupart des équipes conservent à la fois un statut simple et quelques horodatages dans le CRM ou le CDP.

Vous voulez généralement un champ global, plus des champs par Wallet. Cela vous permet de segmenter sans perdre le détail.

Champs courants :

* `walletStatus`: `aucun`, `apple`, `google`, `les deux`
* `appleWalletInstalledAt`: horodatage, facultatif
* `googleWalletInstalledAt`: horodatage, facultatif
* `walletLastChangedAt`: horodatage
* `walletLastEvent`: installée ou désinstallée

{% hint style="warning" %}
Traitez les événements comme **une livraison au moins une fois**. Attendez-vous à des doublons et à une livraison hors ordre.
{% endhint %}

### Rapprochez les événements des enregistrements de votre pile

Votre synchronisation a besoin d’une clé de jointure. Utilisez un identifiant externe stable stocké sur la Carte.

De bons identifiants sont `customerId`, `accountId`, ou un e-mail normalisé. Évitez les identifiants susceptibles de changer fréquemment.

Lorsqu’un événement arrive, rattachez-le à un seul enregistrement dans la pile. Puis mettez à jour les indicateurs par Wallet et le statut global conservé dans la pile.

### Comprenez les cas limites

L’installation dépend du Wallet. Un seul client peut installer sur Apple Wallet et Google Wallet.

La désinstallation dépend elle aussi du Wallet. Une désinstallation sur Apple n’implique pas une désinstallation sur Google.

Certains clients réinstallent rapidement. Utilisez les horodatages pour éviter les oscillations de statut dans les outils en aval.

### Option 1 — Webhooks (temps réel, effort minimal)

Les webhooks envoient les événements vers votre point de terminaison au fur et à mesure qu’ils se produisent. Abonnez-vous à `Carte:Installed` et `Carte:Uninstalled`.

Étape suivante : configurez votre point de terminaison webhook et validez les signatures.

Voir [Recevez l’événement The Wallet Crew via webhook](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/webhook.md).

### Option 2 — Connecteur personnalisé (temps réel, charge utile personnalisée)

Utilisez un connecteur personnalisé lorsque la charge utile par défaut du webhook ne suffit pas.

C’est le bon choix pour des structures de charge utile personnalisées. C’est aussi utile pour une authentification personnalisée (clé API, OAuth) ou une logique supplémentaire.

La logique typique comprend le routage, l’enrichissement, la limitation de débit et les nouvelles tentatives.

Étape suivante : implémentez `OnCarteInstalled` et `OnCarteUninstalled`.

Voir [Connecteur personnalisé pour appeler l’API lorsque le statut d’installation de la Carte change](https://github.com/TheWalletCrew/docs/blob/main/guides/connect/custom-connector/installation-changed-extensibility.md).

### Option 3 — API Carte (synchronisation batch + backfills)

Utilisez l’API Carte lorsque vous souhaitez synchroniser périodiquement l’état d’installation.

C’est aussi le meilleur choix pour reconstruire l’état dans les outils en aval après une indisponibilité.

Commencez par la référence de l’API. Recherchez les points de terminaison de liste de Cartes pouvant être filtrés par statut d’installation.

#### Schéma de backfill qui fonctionne bien

Exécutez une tâche planifiée qui recalcule le statut de référence à partir de l’API Carte. La plupart des équipes l’exécutent quotidiennement.

Utilisez vos événements en temps réel pour la rapidité. Utilisez le backfill pour la cohérence.

Si la pile et les Cartes ne concordent pas, fiez-vous à l’API Carte. Puis corrigez l’enregistrement en aval et continuez.

### Un flux de travail pragmatique de bout en bout

{% stepper %}
{% step %}

### 1) Ajoutez un identifiant stable à chaque Carte

Choisissez un identifiant. Utilisez le même champ sur chaque Carte.
{% endstep %}

{% step %}

### 2) Envoyez les événements en temps réel à votre pile

Utilisez les webhooks pour la plupart des configurations. Utilisez un connecteur personnalisé si vous avez besoin d’une charge utile différente.
{% endstep %}

{% step %}

### 3) Mettez à jour les champs et les segments dans vos outils

Mettez à jour les indicateurs par Wallet et les horodatages. Recalculez le global `walletStatus`.
{% endstep %}

{% step %}

### 4) Effectuez des backfills régulièrement

Planifiez une tâche API Carte. Utilisez-la pour corriger les écarts et couvrir les interruptions.
{% endstep %}

{% step %}

### 5) Suivez l’adoption avec Insights

Utilisez Insights pour les tendances et la surveillance. Vérifiez que les installations et désinstallations correspondent aux attentes.
{% endstep %}
{% endstepper %}

### Dépannage

Si vous ne voyez pas d’événements, commencez par valider la signature. Vérifiez ensuite la disponibilité du point de terminaison et la gestion des nouvelles tentatives.

Si vous voyez des doublons, ajoutez de l’idempotence dans le chemin d’écriture en aval. Utilisez l’horodatage le plus récent comme critère de départage.

Si vous ne parvenez pas à associer les événements aux clients, il manque un identifiant. Ajoutez-le aux données de la Carte, puis lancez un backfill pour réparer l’historique.

### FAQ

<details>

<summary>Quelle option faut-il utiliser en premier ?</summary>

Commencez par le **API Insights** lorsque seules les tendances agrégées comptent. Commencez par **webhooks** lorsque les événements doivent atteindre un CRM, un CDP ou un outil d’automatisation en temps réel. Ajoutez le **API Carte** lorsqu’un backfill fiable est également nécessaire.

</details>

<details>

<summary>Pourquoi les événements en temps réel et un backfill par lots sont-ils souvent utilisés ensemble ?</summary>

La livraison en temps réel maintient les parcours, les alertes et les segments à jour. Un backfill planifié via l’API Carte corrige les écarts causés par les relances, les interruptions ou les défaillances temporaires en aval.

</details>

<details>

<summary>Pourquoi un identifiant stable est-il obligatoire ?</summary>

Les événements Wallet ne sont utiles en aval que lorsqu’ils peuvent être associés au bon enregistrement. Un identifiant stable, tel que `customerId` ou un e-mail normalisé, rend le rapprochement fiable entre les webhooks, les connecteurs et les tâches batch.

</details>

<details>

<summary>Le même client peut-il apparaître comme installé sur Apple et Google ?</summary>

Oui. L’installation dépend du Wallet. Le même client peut détenir la même Carte dans Apple Wallet et Google Wallet, donc les modèles en aval doivent conserver des champs par Wallet ainsi qu’un statut global.

</details>


# Interrogez vos données — API Insights

Interrogez programmatiquement les événements Wallet avec l’API Insights pour des tableaux de bord personnalisés, des rapports automatisés et des workflows BI.

Le [tableau de bord des statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) affiche visuellement les données du portefeuille. Le **API Insights** donne un accès programmatique à ces mêmes données, afin que les équipes puissent créer des tableaux de bord personnalisés, alimenter des outils de BI, lancer des analyses ad hoc ou automatiser le reporting.

{% hint style="info" %}
Aucun code n’est requis pour exporter les données. Le [Rapport](/guides-monitoring/fr/monitor/report) la page permet aux équipes d’exporter les données d’événements en CSV depuis le back office.
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une équipe marketing compare le volume d’installations par `Medium` après une campagne CRM.
* Une équipe opérations suit les scans par magasin et surveille les tendances de désinstallation par programme.
* Une équipe BI importe les événements du portefeuille dans Tableau, Looker ou Power BI pour des rapports hebdomadaires.

</details>

## Qu’est-ce que l’API Insights ?

L’API Insights est une interface de requête pour les événements du portefeuille stockés sur la plateforme The Wallet Crew. Chaque événement suivi peut être interrogé, y compris les créations de Carte, les installations, les désinstallations, les scans, les notifications et les mises à jour. C’est le bon choix lorsque le tableau de bord du back office ne suffit pas, par exemple pour des plages de dates personnalisées, des regroupements personnalisés, l’ingestion BI ou des rapports automatisés.

## Ce que vous pouvez interroger

L’API Insights couvre les mêmes événements opérationnels utilisés pour le suivi et le reporting. Chaque événement répond à une question métier différente.

| Événement                | Ce qu’il capture                                                                                                                    | Exemple de question à laquelle vous pouvez répondre                           |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| `Carte:Created`          | Quand un enregistrement de Carte a été créé                                                                                         | Combien de cartes ont été émises ce mois-ci par magasin ?                     |
| `Carte:Installed`        | Lorsqu’un Carte a été ajouté à Apple Wallet ou Google Wallet, avec des données sources telles que `Medium`, `Tag`, `URL`, et `Host` | Quelle campagne e-mail a généré le plus d’installations la semaine dernière ? |
| `Carte:Uninstalled`      | Lorsqu’une Carte a été entièrement supprimée de tous les portefeuilles                                                              | Quel est le taux de désinstallation par programme ?                           |
| `Carte:Updated`          | Lorsque les données de la Carte ont été modifiées                                                                                   | Combien de cartes ont été mises à jour après la dernière campagne ?           |
| `Carte:UpdateSent`       | Lorsqu’une mise à jour push a été envoyée à un appareil                                                                             | Les mises à jour atteignent-elles les appareils de manière fiable ?           |
| `Carte:Scanned`          | Lorsqu’un code-barres de Carte a été scanné                                                                                         | Combien de scans par jour ont eu lieu dans chaque emplacement ?               |
| `Carte:NotificationSent` | Lorsqu’une notification push a été envoyée                                                                                          | Combien de notifications ont été envoyées par programme ce mois-ci ?          |

## Filtres disponibles

Toutes les requêtes prennent en charge le filtrage par plage de dates, modèle de carte, type d’événement et source d’installation. Les filtres de source incluent `Medium`, `Tag`, `URL`, et `Host`.

Tout champ de métadonnées de Carte peut également être utilisé comme filtre. Cela inclut des champs métier tels que `storeId`, `programmeId`, la région ou toute métadonnée personnalisée stockée sur la Carte.

## Son lien avec le tableau de bord des statistiques

{% hint style="info" %}
Le **Statistiques** le tableau de bord est construit sur l’API Insights. Tout ce qui est visible dans le tableau de bord peut aussi être interrogé directement via l’API, avec davantage de flexibilité sur les regroupements, les filtres et les plages de dates.
{% endhint %}

Pour une vue sans code des mêmes données, utilisez la [tableau de bord des statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f). Pour envoyer des événements vers des outils externes en temps réel, consultez [Envoyer les événements du portefeuille vers vos outils](/guides-monitoring/fr/monitor/sync-pass-installation-status-to-your-crm).

## Prise en main

La façon la plus rapide est de s’authentifier, d’examiner les endpoints disponibles et d’exécuter une première requête d’agrégation.

{% stepper %}
{% step %}

### 1. Authentifiez-vous

Utilisez la clé API dans le `X-API-KEY` en-tête.

```http
X-API-KEY: <API_KEY>
```

{% endstep %}

{% step %}

### 2. Explorez les endpoints disponibles

Utilisez la [référence de l’API Insights](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/insights-api.md) pour examiner les endpoints, les paramètres et les structures de réponse.
{% endstep %}

{% step %}

### 3. Commencez par une requête simple

Commencez par un décompte des `Carte:Installed` événements sur les 30 derniers jours. Regroupez le résultat par `Medium` pour voir quelle source d’acquisition a généré le plus d’ajouts au portefeuille pendant la période.

Cette première requête permet de valider rapidement que l’authentification fonctionne et que les données source sont disponibles sur le programme.
{% endstep %}
{% endstepper %}

## Cas d’usage courants

La plupart des équipes commencent par un besoin de reporting récurrent, puis approfondissent l’analyse. Le même flux d’événements peut prendre en charge à la fois le suivi opérationnel et les workflows BI.

* Alimentez Tableau, Looker ou Power BI avec les comptes d’installations et de désinstallations.
* Automatisez un rapport hebdomadaire des performances du programme par magasin ou région.
* Construisez un entonnoir d’activation personnalisé en corrélant `Carte:Created` avec `Carte:Installed`.
* Interrogez les événements de scan pour construire une vue analytique des redemptions.
* Validez la diffusion de la campagne en comparant `Carte:NotificationSent` avec les pics d’installation.

## FAQ

<details>

<summary>Quand faut-il utiliser l’API Insights plutôt que Statistiques ?</summary>

Utilisez **Statistiques** pour une lecture visuelle rapide des performances du programme. Utilisez la **API Insights** lorsque des filtres personnalisés, des regroupements personnalisés, l’ingestion BI ou des rapports automatisés sont nécessaires.

</details>

<details>

<summary>L’API Insights expose-t-elle les mêmes données que le tableau de bord ?</summary>

Oui. Le tableau de bord des statistiques est construit sur les mêmes données d’événements. L’API apporte davantage de flexibilité pour la forme des requêtes, la plage temporelle et l’utilisation en aval.

</details>

<details>

<summary>Du code est-il nécessaire pour accéder aux données d’événements du wallet ?</summary>

Non. La [Rapport](/guides-monitoring/fr/monitor/report) page prend en charge l’export CSV depuis le back office. L’API Insights est utile lorsqu’un workflow programmable est nécessaire.

</details>


# Guides de scan

Chaque carte finit tôt ou tard par devoir être vérifiée — à la caisse, à l’entrée ou à un comptoir d’échange. Les outils Scan & validate expliquent comment lire et agir sur les cartes Wallet dans le monde réel, avec des conseils

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3>Scanner et valider</h3></td><td>Lisez les codes-barres, les codes QR et les pass NFC au moment du paiement, à l'entrée ou aux points d'utilisation — choisissez le bon matériel et validez les pass de manière fiable.</td><td><a href="/files/abca42349cc59a091d30142fdea30b2ed5a3652f">/files/abca42349cc59a091d30142fdea30b2ed5a3652f</a></td><td><a href="/pages/8f07bc3e8da28b0d08f5477e7f306d76b94ed3d7">/pages/8f07bc3e8da28b0d08f5477e7f306d76b94ed3d7</a></td></tr><tr><td><h3>Lecteur</h3></td><td>Choisissez le bon lecteur pour les pass Wallet : imageurs 2D vs lecteurs laser, codes 1D vs 2D, et une checklist pratique pour être prêt pour la production.</td><td><a href="/files/918a1c9e3c66c2bb416e824c2841b5f6c9b8270c">/files/918a1c9e3c66c2bb416e824c2841b5f6c9b8270c</a></td><td><a href="/pages/a67a3897ed9976c6b5dfbaf5fde152fe48f84072">/pages/a67a3897ed9976c6b5dfbaf5fde152fe48f84072</a></td></tr></tbody></table>

Le défi principal est simple : les pass Wallet s'affichent sur l'écran d'un téléphone, et tous les lecteurs ne lisent pas bien les écrans. **Lecteur** passe en revue l'aspect pratique de tout cela — pourquoi les imageurs 2D sont généralement le meilleur choix par rapport aux lecteurs laser, la différence entre les codes-barres 1D (identifiants rapides et compacts) et les codes 2D comme les QR (plus de données, plus adaptés à courte distance et sous des angles inhabituels), ainsi qu'une checklist de sélection couvrant la prise en charge des symbologies, la luminosité de l'écran, les écrans fissurés et les tests de débit en conditions réelles.

Que vous validiez un scan de fidélité au POS, contrôliez des billets à l'entrée d'un événement ou utilisiez une carte-cadeau, bien choisir le matériel et la logique de lecture dès le départ évite de coûteux problèmes de taux de lecture une fois en production.


# Scanner de cartes

Scanner de cartes permet au personnel de scanner les cartes Apple Wallet et Google Wallet afin de consulter et de gérer les privilèges en temps réel dans des environnements à accès contrôlé.

Carte Scanner est une application mobile conçue pour permettre au personnel de scanner une carte, consulter tous les privilèges associés et les consommer. Elle fonctionne sur les appareils iOS et Android, et bien que la numérisation NFC soit prévue à l'avenir, la version actuelle repose sur la lecture de codes-barres et de codes QR via la caméra. Carte Scanner n'est pas destiné à un usage public ; il a été conçu pour des environnements à accès contrôlé tels que des événements, des salons ou des locaux internes d'entreprise.

\
L'application est strictement en ligne. Chaque scan nécessite une connexion réseau afin de garantir que la vérification de la carte et la consommation des privilèges soient toujours effectuées en temps réel. Le fonctionnement hors ligne n'est pas pris en charge, ce qui élimine le risque d'utilisation en double et garantit que toute consommation de privilèges est immédiatement visible pour le système backend.

{% embed url="<https://www.youtube.com/watch?v=bzlGOpzjKfI>" %}

## Cartes et privilèges

Carte Scanner fonctionne avec des cartes Wallet stockées dans Apple Wallet ou Google Wallet. Chaque carte contient un identifiant unique lié à un ou plusieurs privilèges. Ces privilèges peuvent être à usage unique, à usages multiples avec compteurs, limités dans le temps ou conditionnels. Carte Scanner ne définit pas lui-même les privilèges, mais les affiche et permet aux opérateurs de les consommer conformément aux règles définies dans le backend. Pour une explication détaillée des types de privilèges, les administrateurs peuvent se référer à [Privilège](https://github.com/TheWalletCrew/docs/tree/main/guides/documentation/privilege-and-activation/privilege.md).

\
Une fois la carte scannée, l'application envoie son identifiant au backend pour vérification. Le backend valide la carte, vérifie son état et renvoie la liste des privilèges.\
\
Les opérateurs peuvent ensuite consommer des privilèges :

* Les privilèges à usage unique sont désactivés après utilisation.
* Les privilèges à usages multiples sont décrémentés après chaque utilisation.

{% hint style="warning" %}
La consommation d'un privilège est irréversible.

Carte Scanner n'affiche pas de demande de confirmation.

Carte Scanner n'utilise pas de codes PIN ni d'approbations supplémentaires.
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* **Événements**: le personnel scanne un billet VIP pour vérifier l'accès au salon, les bons pour boissons ou les privilèges de file rapide.
* **Hôtellerie**: les équipes de salon vérifient les avantages liés à la chambre, tels que l'accès au petit-déjeuner ou les boissons de bienvenue.
* **Accès d'entreprise**: le personnel de réception scanne les cartes d'employé ou d'invité pour valider les droits d'accès au site.
* **Clubs d'adhésion**: le personnel de l'accueil vérifie les entrées restantes, les cartes d'invité ou les avantages à durée limitée.

</details>

## Installer Carte Scanner

Carte Scanner fonctionne sur **iOS** et **Android**.

L'application est publiée sur l'App Store d'Apple et Google Play.

TestFlight (iOS) et la distribution APK (Android) peuvent toujours être utilisés pour les tests internes, les déploiements progressifs ou les appareils gérés.

<details>

<summary><strong>iOS (App Store)</strong></summary>

**Exigences**

* Connexion Internet active

**Installer**

1. Ouvrez l' **App Store**.
2. Recherchez **The Wallet Crew - Scanner (**[**Lien vers l'App Store**](https://apps.apple.com/app/the-wallet-crew-scanner/id6758636841)**)**.
3. Appuyez sur **Obtenir** / **Installer**.
4. Ouvrez Carte Scanner depuis l'écran d'accueil.

</details>

<details>

<summary><strong>Android (APK)</strong></summary>

**Exigences**

* Connexion Internet active

**Installer**

1. Obtenez le lien de téléchargement APK auprès de votre administrateur.
2. Appuyez sur le lien pour télécharger l'APK.
3. Ouvrez le fichier téléchargé depuis les notifications ou les téléchargements.
4. Si cela vous y invite, autorisez votre navigateur ou votre gestionnaire de fichiers à **installer des applications inconnues**.
5. Ouvrez à nouveau l'APK.
6. Appuyez sur **Installer**.
7. Appuyez sur **Ouvrir**.

{% hint style="warning" %}
Installez Carte Scanner uniquement depuis une fiche officielle de l'App Store ou via un lien fourni par The Wallet Crew.

Ne téléchargez jamais l'APK depuis des sites tiers.
{% endhint %}

</details>

#### Après l'installation

1. Ouvrez l'application. Vous verrez l'écran du scanner.
2. Scannez le code QR de connexion fourni par votre administrateur. Ce code QR est créé et géré depuis [Gérer les appareils](/guides-scan/fr/scanner/pass-scanner/manage-devices).
3. Commencez à scanner des cartes.

## Authentification et fonctionnement

Carte Scanner utilise **l'authentification basée sur un code QR**. Un opérateur scanne un code QR de connexion, que le backend valide avant d'émettre un jeton de session. Une fois authentifié, l'opérateur peut scanner des cartes et gérer les privilèges. Tous les opérateurs ont le même niveau d'accès, sans rôle ni autorisations supplémentaires requises.

Comme l'application est exclusivement en ligne, une connectivité réseau fiable est essentielle. Les appareils doivent être gérés, surveillés et sécurisés pour maintenir l'intégrité du système. Les journaux du backend offrent une visibilité sur les résultats des scans, les opérations de consommation et toute erreur, ce qui permet aux administrateurs de suivre l'utilisation et de résoudre efficacement les problèmes.

## Marque blanche et sécurité

Carte Scanner est conçu pour prendre en charge un déploiement en marque blanche. Les organisations peuvent personnaliser le nom de l'application, les icônes, les couleurs, les logos et les écrans de démarrage sans modifier le comportement sécurisé ni les fonctionnalités de l'application. Il est ainsi facile d'intégrer l'application à la charte graphique et aux workflows opérationnels existants d'une organisation.

\
Du point de vue de la sécurité, Carte Scanner minimise les risques en conservant toute la logique sensible sur le backend. Les opérations de consommation sont vérifiées côté serveur pour prévenir la fraude, et les jetons d'authentification ont une courte durée de vie. Les appareils doivent être considérés comme gérés et contrôlés, afin que seul le personnel autorisé puisse scanner des cartes et consommer des privilèges.

## FAQ

<details>

<summary>Carte Scanner peut-il être utilisé hors ligne ?</summary>

Non. Carte Scanner est **exclusivement en ligne**.

Chaque scan nécessite une connexion réseau.

</details>

<details>

<summary>Comment Carte Scanner est-il installé ?</summary>

Installez Carte Scanner sur les appareils du personnel (iOS et Android).

Carte Scanner n'est pas destiné à une distribution publique.

La plupart des équipes l'installent depuis l'App Store d'Apple et Google Play.

Si un autre canal d'installation est nécessaire (TestFlight ou APK), contactez The Wallet Crew.

</details>

<details>

<summary>Quel est le protocole de connexion ?</summary>

Carte Scanner utilise **l'authentification basée sur un code QR**.

Un opérateur scanne un code QR de connexion.

Le backend le valide et émet un **jeton de session**.

</details>

<details>

<summary>Carte Scanner prend-il en charge la marque blanche ?</summary>

Oui. Vous pouvez personnaliser le nom de l'application, l'icône, les couleurs, les logos et l'écran de démarrage.

L'image de marque ne modifie pas le modèle de sécurité.

</details>

<details>

<summary>Le scan d'une carte est-il réversible ?</summary>

Le scan d'une carte est **en lecture seule**.

Il récupère l'état de la carte et la liste actuelle des privilèges.

Ce qui **n'est pas réversible** est la consommation d'un privilège.

Une fois consommé, il est enregistré côté serveur immédiatement.

Cela ne peut pas être annulé depuis Carte Scanner.

</details>


# Gérer les appareils

Gérez les appareils autorisés à se connecter à Scanner de cartes, distribuez leurs codes QR de connexion en toute sécurité et révoquez ou faites pivoter l’accès lorsque nécessaire.

La page Devices contrôle quels téléphones sont autorisés à se connecter à Carte Scanner. Chaque entrée d'appareil représente une installation de scanner et des identifiants de connexion. Cette page permet aux administrateurs de créer de nouveaux appareils, de partager le code QR de connexion et de révoquer ou faire tourner l'accès lorsqu'un téléphone change de main.

Le code QR de l'appareil doit être traité comme un mot de passe. Toute personne ayant accès à ce code QR peut connecter un appareil à Carte Scanner. La gestion des appareils est donc à la fois un sujet opérationnel et un sujet de sécurité.

{% hint style="warning" %}
Le code QR de l'appareil est un identifiant. Il ne doit être partagé que par des canaux de confiance et uniquement avec le membre du personnel ou le superviseur responsable de cet appareil.
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* **Opérations d'événement :** chaque superviseur de porte reçoit un code QR d'appareil dédié pour un téléphone géré.
* **Accès au commerce de détail ou au salon :** chaque téléphone de comptoir possède sa propre entrée d'appareil, ce qui facilite la révocation de l'accès sans affecter le reste de l'équipe.
* **Personnel temporaire :** un appareil peut être activé pour une campagne ou une journée d'événement, puis désactivé immédiatement après le service.
* **Téléphone perdu ou remplacé :** la connexion peut être réinitialisée afin d'invalider le code QR précédent et d'en émettre un nouveau.

</details>

## Comment fonctionne la gestion des appareils

Carte Scanner utilise une connexion par code QR. Lorsqu'un appareil est créé, The Wallet Crew génère un code QR lié à cet enregistrement d'appareil. Le téléphone scanne ce code QR depuis l'application Carte Scanner pour établir sa connexion.

L'utilisation d'une entrée d'appareil par téléphone physique est le modèle le plus sûr. Elle permet une révocation précise, facilite les audits et évite de partager un identifiant entre plusieurs opérateurs. Elle aide aussi les équipes opérationnelles à identifier quel téléphone doit être désactivé ou réinitialisé lorsqu'un incident survient.

### Ajouter un nouvel appareil

L'ajout d'un appareil crée un nouvel identifiant de connexion pour Carte Scanner. Cela doit être fait pour chaque téléphone qui scannera des cartes en production.

{% stepper %}
{% step %}

#### Créer l'entrée de l'appareil

Depuis la page Devices, sélectionnez **Nouveau** pour créer un appareil.
{% endstep %}

{% step %}

#### Saisissez les détails de l'appareil

Ajoutez un nom clair. Une description facultative peut être utilisée pour identifier l'emplacement, l'équipe ou la fonction du téléphone. Les nouveaux appareils sont activés par défaut.
{% endstep %}

{% step %}

#### Enregistrer et capturer le code QR

Une fois l'appareil créé, le code QR de connexion devient disponible. Ce code QR est l'identifiant utilisé par l'application Carte Scanner pour connecter le téléphone.
{% endstep %}
{% endstepper %}

L'utilisation d'une convention de nommage aide à garder la flotte lisible. Par exemple, une marque peut utiliser un code magasin, un numéro de porte ou un rôle tel que `Paris-Flagship-Checkout-1` ou `VIP-Gate-A`.

### Partager le code QR de l'appareil en toute sécurité

Le code QR de l'appareil doit être partagé avec précaution car il donne accès à Carte Scanner. Dans de nombreux déploiements, l'approche la plus sûre consiste à l'afficher localement à l'opérateur pendant la configuration plutôt que de l'envoyer par des canaux internes larges.

Si le code QR est transféré par e-mail, chat ou capture d'écran, l'accès n'est plus contrôlé par la seule possession du téléphone. Cela augmente le risque de connexion non autorisée. En cas de doute, réinitialisez la connexion et émettez un nouveau code QR.

Le code QR ne peut être consulté que lors de la création de l'appareil. Cela rend le moment de la configuration initiale important. Il doit être capturé et transmis via un processus de confiance.

### Désactiver, activer ou supprimer un appareil

Les changements d'état de l'appareil permettent aux administrateurs de contrôler qui peut se connecter sans recréer toute la flotte. La bonne action dépend du fait que l'accès doit être suspendu, rétabli plus tard ou supprimé définitivement.

**Désactiver un appareil** lorsque l'accès doit s'arrêter temporairement. C'est utile pour les opérations saisonnières, le personnel temporaire, les téléphones perdus qui pourraient être retrouvés, ou tout doute de sécurité à court terme. Un appareil désactivé peut être réactivé plus tard.

**Activer un appareil** lorsqu'un téléphone précédemment désactivé est autorisé à reprendre du service.

**Supprimer un appareil** lorsqu'il n'est plus nécessaire et ne doit pas revenir, par exemple après une mise hors service définitive. Si un appareil peut être réutilisé plus tard, la désactivation est généralement plus sûre que la suppression.

### Réinitialiser une connexion d'appareil

La réinitialisation de la connexion fait tourner l'identifiant d'un appareil existant. Un nouveau code QR est généré et l'ancien cesse de fonctionner immédiatement.

Cette action est utile lorsque le code QR a pu être exposé, lorsque le téléphone est remplacé ou lorsque la configuration doit être effectuée à nouveau dans des conditions contrôlées. Réinitialiser la connexion est souvent le moyen le plus rapide de rétablir la confiance sans supprimer puis recréer l'appareil.

### Recommandations opérationnelles

La gestion des appareils fonctionne au mieux lorsque chaque téléphone possède son propre enregistrement clairement nommé et que chaque identifiant est traité comme une information à distribution courte et à haut niveau de confiance. Cela permet de cibler la révocation et d'éviter toute confusion opérationnelle pendant les périodes de forte activité.

Pour la plupart des projets, les pratiques suivantes réduisent la charge de support et le risque de sécurité :

* Créer un appareil par téléphone physique.
* Utiliser des noms qui identifient clairement l'emplacement ou le rôle.
* Désactiver les appareils inutilisés dès la fin d'un service, d'un événement ou d'une campagne.
* Réinitialiser immédiatement la connexion si un code QR a été partagé trop largement.
* Privilégier la désactivation à la suppression lorsque l'appareil peut reprendre du service.

## FAQ

<details>

<summary><strong>Plusieurs téléphones doivent-ils partager le même appareil ?</strong></summary>

Non. Un appareil par téléphone est le modèle recommandé. Il garde le contrôle d'accès précis et rend l'enquête ou la révocation beaucoup plus faciles.

</details>

<details>

<summary><strong>Que se passe-t-il après une réinitialisation de connexion ?</strong></summary>

Le code QR précédent devient immédiatement invalide. Un nouveau code QR le remplace pour le même enregistrement d'appareil.

</details>

<details>

<summary><strong>Quand faut-il désactiver un appareil plutôt que le supprimer ?</strong></summary>

Désactivez un appareil lorsque l'accès doit s'arrêter temporairement ou lorsque le téléphone peut revenir plus tard. Ne supprimez un appareil que lorsqu'il n'est plus du tout nécessaire.

</details>

<details>

<summary><strong>Pourquoi le code QR est-il considéré comme sensible ?</strong></summary>

Le code QR est l'identifiant de connexion de Carte Scanner. Toute personne qui le reçoit peut être en mesure d'authentifier un appareil, il doit donc être traité avec le même soin qu'un mot de passe.

</details>

<details>

<summary><strong>Quelle est la meilleure réponse si un code QR a été partagé via un canal non sécurisé ?</strong></summary>

Réinitialisez immédiatement la connexion. Cela invalide le code QR précédent et rétablit le contrôle avec un nouvel identifiant généré.

</details>


# Lecteur

Sélectionnez un matériel de scanner qui lit de manière fiable les codes-barres et les codes QR des cartes Apple Wallet et Google Wallet.

## Scannez les Carte Wallet avec des lecteurs de codes-barres et de codes QR

Les Carte à code-barres et QR sont conçues pour être présentées sur l'écran d'un téléphone. L'expérience de scan dépend du matériel du scanner, de sa configuration et des conditions sur site.

Les contraintes matérielles déterminent souvent le choix entre la lecture de codes-barres/QR et le NFC. Un aperçu plus large de la compatibilité est disponible dans [Matériel](/connectors/fr/hardware).

<details>

<summary><strong>Exemples concrets</strong></summary>

* Fidélité en magasin : un scanner 2D lit un code QR depuis un téléphone à la caisse.
* Entrée à un événement : des scanners portables lisent des codes QR à l'entrée, par rafales.
* Utilisation d'une carte-cadeau : un scanner de comptoir lit un code-barres, puis applique la valeur.
* Boutiques éphémères : le smartphone d'un membre du personnel valide les Carte à l'aide d'une application de numérisation basée sur la caméra.

</details>

### Type de scanner recommandé pour les écrans de téléphone

Les scanners d'imagerie 2D (imagers 2D) sont généralement le bon choix pour les projets Wallet. Ils capturent le code sous forme d'image, ce qui rend la lecture depuis des écrans fiable.

Les scanners laser peuvent bien fonctionner sur des codes-barres 1D imprimés. Ils sont souvent moins performants sur les écrans de téléphone, car la lecture dépend de la lumière réfléchie. Les écrans modernes et le verre de protection ont tendance à réduire cette réflexion.

{% hint style="info" %}
La plupart des imagers 2D prennent en charge de nombreuses symbologies 1D et 2D. La prise en charge varie selon le modèle et la licence. Les spécifications matérielles doivent être vérifiées par rapport aux formats de codes-barres utilisés dans les modèles de Carte.
{% endhint %}

### Codes 1D vs 2D (pourquoi c'est important pour les scanners)

<figure><img src="/files/fb5749b6c819c92f659c7f6bc3dff44e5c7e172e" alt="Comparison between a 1D barcode (linear bars) and a 2D barcode (matrix code such as QR)."><figcaption><p>Les codes 1D sont linéaires. Les codes 2D sont matriciels.</p></figcaption></figure>

#### Codes-barres 1D (linéaires)

Les codes-barres 1D sont constitués de barres parallèles, souvent avec un numéro lisible par l'humain en dessous. Ils contiennent généralement de courts identifiants.

Ils peuvent être rapides à scanner à distance. Ils ont aussi tendance à être moins coûteux à prendre en charge au niveau matériel.

#### Codes-barres 2D (matriciels)

Les codes-barres 2D stockent des données dans une grille. Le code QR et Data Matrix sont des exemples courants. Ils peuvent stocker davantage de données et sont largement utilisés pour les billets.

Ils se scannent bien à courte portée et dans plusieurs orientations, ce qui améliore le débit dans les environnements bondés.

### Liste de vérification pratique pour le choix

Le choix du scanner doit être validé tôt. Cela réduit le risque de déploiement et évite les problèmes tardifs de taux de lecture.

Les vérifications clés qui comptent généralement en production :

* Confirmez que « lit depuis **les écrans mobiles**» est explicitement pris en charge.
* Privilégiez **les imagers 2D** pour des besoins mixtes 1D/2D et une lecture fiable sur écran.
* Confirmez que les symbologies prises en charge correspondent à celles utilisées (QR, Data Matrix, Code 128, PDF417, etc.).
* Testez avec des appareils iOS et Android, à faible comme à forte luminosité.
* Testez avec des conditions courantes des téléphones : film de protection d'écran, verre fissuré et atténuation liée à une batterie faible.
* Validez le débit dans des conditions réalistes (file d'attente, distance de scan, habitudes du personnel).

### FAQ

<details>

<summary><strong>La lecture de codes-barres nécessite-t-elle un matériel compatible NFC ?</strong></summary>

Non. La lecture de codes-barres et de codes QR utilise une lecture optique (scanner ou caméra).

Le NFC est une couche matérielle et protocolaire différente. Davantage de contexte est disponible dans [Matériel](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/019c7d1f11089667ce6bd3c6a5fb6968db22fef2).

</details>

<details>

<summary><strong>Un écran de téléphone peut-il être scanné avec un scanner laser 1D ?</strong></summary>

Parfois, mais ce n'est pas une base fiable pour la production. De nombreux scanners laser 1D ont du mal sur les écrans de téléphone en raison de la réflexion et des technologies d'écran.

Les imagers 2D sont le choix par défaut courant pour les déploiements Wallet, car ils sont conçus pour lire à partir d'écrans.

</details>

<details>

<summary><strong>Le code QR doit-il être privilégié par rapport à un code-barres 1D pour les Carte Wallet ?</strong></summary>

Les codes QR sont largement pris en charge par les imagers 2D et fonctionnent bien sur les écrans.

Le bon choix dépend des contraintes opérationnelles et de l'infrastructure existante. Lorsque des codes-barres 1D sont requis, l'utilisation d'imagers 2D permet malgré tout de conserver une lecture fiable sur les écrans de téléphone.

</details>


# crew-check


# COMMENT CONFIGURER

La documentation de The Wallet Crew est organisée autour de trois domaines principaux. Chaque section couvre une partie distincte du flux de configuration et d'exploitation.

Avant de créer des cartes ou de connecter des systèmes externes, un certain nombre de paramètres doivent être définis au niveau de la plateforme. La section Configuration couvre tout ce qui est nécessaire pour rendre The Wallet Crew opérationnel pour une marque : de la configuration initiale du compte à la conception visuelle des modèles Wallet, en passant par les identifiants techniques requis pour émettre des cartes via Apple Wallet et Google Wallet sous l’identité propre de la marque.

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3>Plateforme</h3></td><td><a href="/files/b06554f19347b23ba38b3f1bb439d95eae094a20">/files/b06554f19347b23ba38b3f1bb439d95eae094a20</a></td><td><a href="/pages/4523a0e1ce93a217285c6734d1e038da8923b169">/pages/4523a0e1ce93a217285c6734d1e038da8923b169</a></td></tr><tr><td><h3>Wallet</h3></td><td><a href="/files/895802de62f53ac0591526ea42ef4ad7fa5dfd7f">/files/895802de62f53ac0591526ea42ef4ad7fa5dfd7f</a></td><td><a href="/pages/4a349abb39fa0325658ec575f9fd849062b0bf1f">/pages/4a349abb39fa0325658ec575f9fd849062b0bf1f</a></td></tr><tr><td><h3>Formulaire d'inscription</h3></td><td><a href="/files/0f8a75a03dbdbf92c5de03dcab3239a3f6f8b744">/files/0f8a75a03dbdbf92c5de03dcab3239a3f6f8b744</a></td><td><a href="/pages/ed0a1aaece645ad04b8427140a9c72bace955842">/pages/ed0a1aaece645ad04b8427140a9c72bace955842</a></td></tr></tbody></table>

**Paramètres de la plateforme** sont le point de départ. C'est ici que le tenant est initialisé — des paramètres généraux tels que le titre de l'application, les langues prises en charge et le favicon affiché sur les pages hébergées. L'accès des utilisateurs et l'authentification multifacteur y sont configurés, ainsi que les clés API utilisées pour authentifier les requêtes backend vers les API de The Wallet Crew. Les marques qui souhaitent héberger des pages d'inscription et de téléchargement sur leur propre domaine trouveront également dans cette section la configuration du domaine personnalisé.

**Paramètres Wallet** couvrent les identifiants que Apple et Google exigent pour émettre des cartes. Chaque plateforme a son propre mécanisme d'authentification : Apple Wallet s'appuie sur des certificats et des identifiants de notifications push gérés via le compte Apple Developer, tandis que Google Wallet nécessite un accès à la Google Pay & Wallet Console et des identifiants API dédiés. Les deux doivent être configurés avant que toute carte puisse être créée ou distribuée.

**Configuration des modèles** définit la structure et l'apparence des cartes elles-mêmes — disposition des champs, couleurs, images et contenu dynamique via le moteur de templating DotLiquid. Les modèles peuvent être traduits en plusieurs langues et dupliqués ou importés d'un tenant à l'autre.


# Formulaire d'inscription

Les formulaires d'inscription hébergés prennent en charge des flux sécurisés de création et de récupération de Carte. Cette section couvre l'identification du client, le contrôle d'accès et le comportement du formulaire utilisé avant la livraison du Wallet.

## Configuration de l'inscription client

L'inscription client capture l'identité avant l'émission d'une Carte. Utilisez-la lorsqu'un compte CRM ou POS doit d'abord être créé ou mis à jour. Elle prend en charge l'inscription sur le site web et l'inscription en magasin par code QR.

### Options de connexion (`signinOptions`)

`signinOptions` contrôle la manière dont les clients récurrents sont détectés et gérés. Elle peut vérifier l'existence d'une session ou orienter vers un parcours de connexion mobile en fonction de la détection de l'appareil.

### Options de finalisation (`completeOptions`)

`completeOptions` est une liste ordonnée d'actions effectuées après une inscription réussie. Chaque action a un `type`.

| Type               | Ce qu'il fait                                                                                                                            |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `AddToWallet`      | Présente des boutons Ajouter au Wallet. Prend en charge `autoDownloadPass` et un formulaire post-téléchargement facultatif.              |
| `Redirection`      | Redirige vers une URI fixe. Elle prend en charge des variables Liquid, telles que `{{['id.y2.customerId']}}`, dans l'URL de destination. |
| `RedirectToPass`   | Redirige vers une mise en page nommée de téléchargement de Carte pour un téléchargement immédiat de Carte.                               |
| `Réinitialisation` | Réinitialise le formulaire après un délai configuré en secondes. Utilisez ceci pour des bornes en magasin partagées.                     |

### Localiser le texte du formulaire et le libellé du consentement

Tout le texte destiné aux clients sur le formulaire d'inscription - libellés des champs, instructions et texte de consentement/d'adhésion - est stocké dans des fichiers de localisation par locataire. Accédez-y depuis **Paramètres** → **Inscription** → **Fichiers de localisation**.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/enrolment/localization-files" class="button secondary" data-icon="angles-right">Ouvrir les fichiers de localisation</a></p>

La plupart des locataires ont un `champs` fichier de paramètres régionaux (`locales/fields`), qui régit les libellés des champs du formulaire d'inscription et le texte de consentement/d'adhésion. Modifiez-le en ligne depuis l'écran Fichiers de localisation, de la même manière que les champs du modèle de Carte sont traduits (voir [Comment traduire un modèle](/configure/fr/advanced-configuration/wallet/template-configuration/how-to-translate-a-template)).

Mettez à jour la formulation pour chaque langue active configurée sur le locataire. Une modification apportée à un fichier de paramètres régionaux ne se propage pas automatiquement aux autres langues.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>Activer l'enregistrement par e-mail sur les formulaires d'inscription</h4></td><td>Flux d'inscription hébergés sécurisés, vérifiez les clients existants par e-mail, ajoutez une vérification facultative et réduisez les comptes en double avant la création, la récupération de Carte ou le téléchargement vers le Wallet sur l'ensemble des campagnes.</td><td><a href="/files/db4f23152a881d21fa7088b677b46b262f286f05">/files/db4f23152a881d21fa7088b677b46b262f286f05</a></td><td><a href="/pages/02db62930557a28a2f162763478401302556ef32">/pages/02db62930557a28a2f162763478401302556ef32</a></td></tr></tbody></table>

La section Formulaire d'inscription couvre la configuration avancée de l'expérience d'inscription. Lorsqu'un client soumet son adresse e-mail, TWC peut vérifier automatiquement s'il existe déjà dans le système. Si c'est le cas, une étape de vérification facultative — comme un code à usage unique ou un lien magique — sécurise l'accès avant l'émission de la Carte. Sinon, le formulaire collecte les informations restantes et crée un nouvel enregistrement. Cela évite les doublons et maintient la cohérence de votre base de données clients, sans nécessiter de développement supplémentaire de votre côté.


# Activer l'enregistrement par e-mail sur les formulaires d'inscription

Vérifiez si un client existe déjà à partir de son e-mail, puis sécurisez l'accès avec une vérification facultative.

Si vous décidez un jour d’arrêter d’utiliser The Wallet Crew, vous pouvez le faire à tout moment. Cette page explique comment migrer sans interrompre les mises à jour de Carte pour les clients.

C’est aussi pourquoi nous demandons aux marques d’utiliser leurs propres comptes Apple et Google Wallet. Cela vous maintient comme émetteur officiel. Cela évite aussi le verrouillage fournisseur.

Vos données clients vous appartiennent. Vous restez le responsable du traitement. En pratique, votre source de vérité reste dans votre CRM et vos systèmes internes.

Pour changer de fournisseur, vous exportez les identifiants opérationnels des Cartes depuis The Wallet Crew. Vous les transmettez à votre nouveau fournisseur afin qu’il puisse prendre le relais des mises à jour.

{% hint style="info" %}
Si vous envisagez de partir à cause d’un blocage, prévenez-nous tôt. Nous pouvons souvent le résoudre sans qu’une migration soit nécessaire.
{% endhint %}

Apple Wallet et Google Wallet ne fonctionnent pas de la même manière. Les Cartes Apple récupèrent les mises à jour depuis un `webServiceURL`. Les Cartes Google sont liées à un compte émetteur Google Wallet.

## Ce que vous devez prévoir (Apple vs Google)

### Apple Wallet

Les Cartes Apple installées sur les appareils continuent d’appeler le `webServiceURL` intégré dans la carte.

Pour passer à un nouveau fournisseur, vous devez :

1. Exporter chaque Carte **numéro de série** et **jeton d’authentification**.
2. Mettre à jour le `webServiceURL` vers le point de terminaison de votre nouveau fournisseur.
3. Déclenchez une mise à jour afin que les appareils téléchargent une version de Carte pointant vers le nouveau fournisseur.

### Google Wallet

Les Cartes Google Wallet sont liées à un **compte émetteur Google Wallet**.

Vous ne pouvez pas « transférer » les Cartes vers un autre compte émetteur. Votre nouveau fournisseur doit soit :

* opérer sous le **même** compte émetteur, ou
* réémettre les Cartes sous un nouveau compte émetteur (nouveaux liens d’enregistrement, nouveaux objets).

## Étape par étape

{% stepper %}
{% step %}

### Exporter les données des Cartes depuis The Wallet Crew

Ouvrez la liste des Cartes dans la console d’administration :

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passes/" class="button secondary" data-icon="chevrons-right">Console d’administration The Wallet Crew - Liste des Cartes</a></p>

Exportez la liste complète.

Assurez-vous que l’export inclut au minimum :

* Apple : **numéro de série** et **jeton d’authentification**
* Google : **ID de ressource** (ou ID d’objet)
* Vos identifiants externes (afin que le nouveau fournisseur puisse rattacher les Cartes aux clients)
  {% endstep %}

{% step %}

### Remettez l’export à votre nouveau fournisseur

Envoyez le fichier exporté à votre nouveau fournisseur. Il en a besoin pour l’associer aux Cartes existantes.

Pour Apple, ils importeront généralement le numéro de série + le jeton d’authentification afin de pouvoir signer et fournir les mises à jour.

Pour Google, ils utiliseront généralement les ID de ressource pour mettre à jour les objets existants.
{% endstep %}

{% step %}

### Basculez les Cartes Apple vers le nouveau point de terminaison de mise à jour

Convenez du nouveau point de terminaison de service web Apple Wallet avec votre nouveau fournisseur.

Demandez ensuite à l’équipe The Wallet Crew de :

1. configurer la cible `webServiceURL` pour votre tenant, et
2. lancer une « mise à jour poussée » en masse afin que les Cartes installées récupèrent la nouvelle URL.

{% hint style="warning" %}
Si vous changez le `webServiceURL` sans point de terminaison fonctionnel chez le nouveau fournisseur, les Cartes Apple peuvent cesser de se mettre à jour.

Prévoyez une courte fenêtre de validation et testez d’abord sur un petit échantillon.
{% endhint %}
{% endstep %}

{% step %}

### Valider la migration

Choisissez 2 à 3 Cartes de test (Apple et Google).

Demandez au nouveau fournisseur de :

* mettre à jour un champ visible (exemple : solde de points, statut ou porte d’événement)
* confirmer que la mise à jour est visible sur les appareils en quelques minutes

Pour Apple, confirmez aussi que les mises à jour fonctionnent toujours après la réinstallation de la Carte.
{% endstep %}
{% endstepper %}

## FAQ

<details>

<summary><strong>Les utilisateurs finaux doivent-ils réinstaller leur Carte ?</strong></summary>

En général, non.

Si vous basculez Apple `webServiceURL` correctement, les Cartes existantes continuent de se mettre à jour sans réinstallation.

Pour Google, si vous conservez le même compte émetteur et les mêmes ID d’objet, les utilisateurs conservent généralement la même Carte.

</details>

<details>

<summary><strong>Peut-on déplacer les Cartes Google Wallet vers un autre compte émetteur ?</strong></summary>

Pas sur place.

Les cartes Google Wallet sont liées au compte émetteur. Si l’émetteur change, prévoyez un flux de réémission.

</details>

<details>

<summary><strong>Quelles sont les données minimales que nous devons exporter ?</strong></summary>

Pour Apple, vous avez besoin du numéro de série et du jeton d’authentification.

Pour Google, vous avez besoin de l’ID de ressource.

Les identifiants externes sont fortement recommandés. Ils permettent au nouveau fournisseur de conserver l’association Carte-client.

</details>


# Plateforme

La documentation de The Wallet Crew est organisée autour de quatre domaines principaux. Chaque section couvre une partie distincte du flux de configuration et d'exploitation.

La section Platform couvre les paramètres fondamentaux qui s’appliquent à l’ensemble du compte. Ce sont les paramètres à configurer en premier — avant de créer des Cartes, de connecter des systèmes ou d’inviter des membres de l’équipe.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>Général</h4></td><td>Gérez les paramètres de vos tenants, les membres de votre équipe et la configuration principale depuis une seule interface.</td><td><a href="/files/5445a4de3185b4a1e2af16ae3c6de6b197f1a50a">/files/5445a4de3185b4a1e2af16ae3c6de6b197f1a50a</a></td><td><a href="/pages/4ca9724ace837fcc110d5708335e5cd0cc1b0706">/pages/4ca9724ace837fcc110d5708335e5cd0cc1b0706</a></td></tr><tr><td><h4>Accès des utilisateurs</h4></td><td>Invitez des membres de l’équipe, attribuez des rôles et contrôlez qui peut consulter, modifier ou gérer votre plateforme.</td><td><a href="/files/0170ee8eab24983af595ccc770872821f09b6fa6">/files/0170ee8eab24983af595ccc770872821f09b6fa6</a></td><td><a href="/pages/e127f5d418d550226d668aa786213b2628ce5b05">/pages/e127f5d418d550226d668aa786213b2628ce5b05</a></td></tr><tr><td><h4>Clé API</h4></td><td>Générez, définissez la portée et révoquez des clés API en toute sécurité pour les environnements de production et de préproduction.</td><td><a href="/files/2cef69ea59f75bdcd650e82a4768755d31042cdf">/files/2cef69ea59f75bdcd650e82a4768755d31042cdf</a></td><td><a href="/pages/c406c9454803724012f54102f856d7dae5cd03a9">/pages/c406c9454803724012f54102f856d7dae5cd03a9</a></td></tr><tr><td><h4>Domaine personnalisé</h4></td><td>Connectez votre propre domaine, configurez votre enregistrement CNAME et laissez TWC gérer automatiquement le SSL.</td><td><a href="/files/24c5b2cfc809e6e0dbe9482e04741c107d460277">/files/24c5b2cfc809e6e0dbe9482e04741c107d460277</a></td><td><a href="/pages/e8788aa2e520d6a4c2d08101974e73e5bdfee7eb">/pages/e8788aa2e520d6a4c2d08101974e73e5bdfee7eb</a></td></tr></tbody></table>

**Paramètres généraux** définissent l’identité de base du compte : le titre de l’application, la favicon affichée sur les pages hébergées et les langues disponibles pour l’inscription et les pages de téléchargement de Carte. Ces paramètres sont visibles par les utilisateurs finaux et doivent refléter l’identité de la marque dès le premier jour.

**Accès des utilisateurs** contrôle qui peut se connecter au back-office et avec quel niveau d’autorisations. C’est ici que le compte administrateur est créé, que les membres de l’équipe sont invités et que l’authentification multifacteur (MFA) est activée. Le fait de bien définir les accès dès le départ réduit les risques de sécurité et évite toute confusion lorsque plusieurs personnes travaillent sur le même compte.

**les clés API** sont requises pour toute intégration backend. Chaque clé est associée au compte et doit être incluse dans chaque requête API envoyée à The Wallet Crew. Les clés peuvent être créées, renouvelées et révoquées depuis cette section. Toute personne configurant une intégration technique aura besoin d’au moins une clé API active avant d’effectuer son premier appel.

**Domaine personnalisé** permet aux marques de remplacer les URL hébergées par défaut de The Wallet Crew par leur propre domaine — pour les formulaires d’inscription, les pages de téléchargement de Carte et les parcours Wallet liés au compte. C’est autant une décision de branding qu’une décision technique : les utilisateurs finaux voient le domaine de la marque tout au long de l’expérience, et non une URL tierce.

Ces quatre paramètres sont indépendants les uns des autres et peuvent être configurés dans n’importe quel ordre. Cela dit, il est recommandé de commencer par les paramètres généraux et l’accès des utilisateurs, car ils influencent le comportement du reste de la plateforme pour toute l’équipe.


# Général

Une fois votre tenant créé, vous pouvez commencer à configurer The Wallet Crew.

La configuration de base vous permet de définir :

### Titre de l’application

* **Titre de l’application :** Ce texte sera utilisé comme titre de la page web et comme nom de l’application lorsque la PWA est active. Si aucun titre n’est spécifié, le nom du tenant sera utilisé.

### Favicon

* **Favicon :** L’icône qui sera utilisée pour les pages web de The Wallet Crew, y compris les pages permettant de créer ou de partager des cartes avec vos clients.

![Favicon](/files/ba7d1f0e6bdbaa2fa87630b9167df4a991476d7b)

### Localisations

* **Localisations :** Indiquez les langues que vous souhaitez déployer. Ces langues seront disponibles pour les traductions sur diverses pages d’accueil de The Wallet Crew utilisées pour l’inscription ou le téléchargement de cartes, ainsi que pour les informations affichées sur les cartes disponibles dans les Wallets.

#### **Ajouter une langue**

* **Pour ajouter une langue :**
  1. Saisissez les 2 lettres ISO correspondant à la langue.
  2. Cliquez sur l’icône « + ».

![Localisations](/files/078dddf33d399779e5ed3f294e8e1066d74c978e)

Vous pouvez cliquer sur l’icône à côté des 2 lettres ISO pour choisir la langue par défaut.

### Enregistrer les modifications

* Une fois toutes les configurations définies, veillez à cliquer sur le bouton « Save » en haut de la page pour appliquer vos modifications.

Ce guide offre un aperçu de base de la configuration de votre tenant Wallet Crew. Pour des configurations et des fonctionnalités plus avancées, reportez-vous à la documentation des paramètres avancés de The Wallet Crew.


# Webhooks

Recevez des notifications HTTP en temps réel pour les événements dans The Wallet Crew.

Les webhooks permettent aux systèmes de recevoir des notifications HTTP en temps réel chaque fois qu’un événement se produit dans l’équipe Wallet. L’enregistrement des webhooks se fait en libre-service via **Paramètres → Général → Webhooks** dans la console d’administration. Aucune appel API n’est requis pour créer ou gérer des webhooks.

## Gérez les webhooks depuis la console

Ouvrir **Paramètres → Général → Webhooks**. La liste affiche tous les webhooks enregistrés, y compris **Description**, **Point de terminaison**, **Événements**, et **Activé** état.

Pour créer ou modifier un webhook, ouvrez son formulaire de modification. Le formulaire contient les champs suivants :

* **ID** — Généré automatiquement et en lecture seule. Utilisez cette valeur pour référencer le webhook via l’API.
* **Secret** — La clé de signature HMAC utilisée pour vérifier les livraisons. Un bouton afficher/masquer contrôle la visibilité. Stockez cette valeur côté serveur et ne l’exposez jamais dans le code client.
* **Activé** — Met en pause ou reprend la livraison sans supprimer le webhook.
* **Description** — Un libellé utilisé comme référence.
* **Point de terminaison** — L’URL HTTPS qui reçoit `POST` les requêtes.
* **Événements** — Une ou plusieurs souscriptions d’événements. Utilisez **Ajouter un événement** et **Supprimer un événement** pour gérer la liste.

## Syntaxe du filtre d’événements

Chaque **Événements** entrée est une chaîne. Trois formes sont prises en charge :

| Syntaxe         | Signification                                            |
| --------------- | -------------------------------------------------------- |
| `*`             | S’abonner à tous les événements.                         |
| `Carte:*`       | S’abonner à tous les événements de la `Carte` catégorie. |
| `Carte:Created` | S’abonner à un événement spécifique.                     |

Les jokers et les événements explicites peuvent être combinés dans le même webhook. Par exemple :

* `["Customer:*", "Carte:Created"]`
* `["Carte:*", "Redirect:Redirected"]`

## Validation de la signature

Chaque livraison inclut le `x-neostore-signature` en-tête. Validez-le côté serveur avec le webhook **Secret**. Voir le [guide du développeur des webhooks](https://docs.thewalletcrew.io/developers-guides/integration-guides/webhooks) pour le modèle de validation complet et la référence de charge utile des événements.

{% hint style="warning" %}
Validez toujours `x-neostore-signature` sur chaque requête entrante. Ne vous fiez pas uniquement aux listes d’autorisation d’adresses IP réseau.
{% endhint %}


# Accès utilisateur

Créez un compte administrateur et gérez les utilisateurs du back-office.

L’accès à la console d’administration suit deux parcours. Le premier est utilisé pendant l’intégration : une personne crée un compte, puis The Wallet Crew accorde l’accès au locataire. Le second est utilisé après l’intégration : un administrateur du locataire ajoute et gère d’autres utilisateurs back-office directement depuis la console d’administration.

{% hint style="info" %}
Si la connexion fonctionne mais qu’aucun locataire n’apparaît, l’accès n’a pas encore été accordé.
{% endhint %}

### Créer un compte administrateur

Pour un premier accès à un locataire, commencez par créer un compte personnel dans le portail d’administration. Cela crée le compte de connexion, mais n’accorde pas à lui seul l’accès au locataire.

{% stepper %}
{% step %}

#### Ouvrir le portail d’administration

Ouvrir <https://admin.thewalletcrew.io/>. C’est ici que vous vous inscrivez et vous connectez à la console d’administration.
{% endstep %}

{% step %}

#### S’inscrire

Lancez le parcours d’inscription et choisissez la méthode préférée. Une fois le compte créé, The Wallet Crew peut accorder le premier accès au locataire.

<figure><img src="/files/e7dc1caba4f8032817333d10cf00f15a717d454e" alt="Admin portal sign-up screen with Google, Microsoft, and email sign-in options"><figcaption><p>Créez le premier compte back-office depuis la page d’inscription du portail d’administration.</p></figcaption></figure>
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Utilisez votre adresse e-mail professionnelle. Cela accélère l’attribution des accès.
{% endhint %}

### Obtenir l’accès à un locataire

Pour le premier administrateur d’un locataire, l’accès est généralement accordé par The Wallet Crew pendant l’intégration. Une fois qu’un locataire a déjà un administrateur, cet administrateur peut accorder l’accès à d’autres utilisateurs sans passer par le support.

<details>

<summary>Exemples concrets</summary>

* Un contact de la marque crée un compte pendant l’intégration. The Wallet Crew accorde le premier accès au locataire.
* Un administrateur du locataire ajoute ensuite des collègues depuis l’ **onglet Utilisateurs** .

</details>

#### Gérer les utilisateurs back-office

Une fois qu’un administrateur du locataire a accès, les utilisateurs back-office peuvent être gérés depuis **Paramètres → Contrôle d’accès → Utilisateurs**. Le **Rôles** onglet à côté sert à consulter les rôles disponibles.

L’onglet **onglet Utilisateurs** affiche un tableau avec **E-mail**, **Nom**, **Rôle**, **Statut**, et **Dernière connexion**. Les utilisateurs actifs apparaissent avec un **Actif** badge dans la **Statut** colonne. Le **+ Ajouter un nouveau** ouvre le formulaire utilisateur, et le menu de chaque ligne propose **Modifier** et **Supprimer** actions.

<figure><img src="/files/ef04724e6daaa6265fa74e601dc9c2e4d11e2307" alt="Users list in Access control showing email, name, role, status, and last login"><figcaption><p>La page Utilisateurs centralise la création des utilisateurs, l’attribution des rôles et la vérification des accès.</p></figcaption></figure>

{% stepper %}
{% step %}

#### Ouvrir Utilisateurs

Ouvrir **Paramètres → Contrôle d’accès → Utilisateurs**.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/access/users-and-roles/users" class="button secondary" data-icon="chevrons-right">Ouvrir Utilisateurs dans la console d’administration</a></p>
{% endstep %}

{% step %}

#### Ajouter un nouvel utilisateur

Cliquez sur **+ Ajouter un nouveau**.
{% endstep %}

{% step %}

#### Renseignez les détails de l’utilisateur

Renseignez **E-mail**, **Nom**, et **Rôle**, puis cliquez sur **Enregistrer** dans le coin supérieur droit.

Le formulaire affiche également un **ID utilisateur** en lecture seule, généré par le système.
{% endstep %}
{% endstepper %}

Pour modifier un utilisateur, ouvrez le **...** menu sur la ligne de l’utilisateur, cliquez sur **Modifier**, mettez à jour les champs, puis cliquez sur **Enregistrer**.

Pour supprimer un utilisateur, ouvrez le **...** menu et cliquez sur **Supprimer**. Cela supprime l’accès au locataire, mais n’efface pas le compte de connexion de la personne.

### FAQ

<details>

<summary>Je peux me connecter, mais je ne vois aucun locataire. Que se passe-t-il ?</summary>

Le compte existe, mais aucun accès à un locataire ne lui a encore été accordé. Pour le premier accès, contactez The Wallet Crew pendant l’intégration. Si le locataire dispose déjà d’un administrateur, cet administrateur peut accorder l’accès depuis [Gérer les utilisateurs back-office](#manage-back-office-users).

</details>

<details>

<summary>Un administrateur du locataire peut-il ajouter un autre utilisateur ?</summary>

Oui. Un administrateur du locataire peut ouvrir **Paramètres → Contrôle d’accès → Utilisateurs**, cliquer sur **+ Ajouter un nouveau**, renseigner les détails de l’utilisateur et enregistrer.

</details>

<details>

<summary>Je peux accéder à un locataire, mais je ne vois pas Paramètres. Pourquoi ?</summary>

Le compte a accès au locataire, mais pas avec des droits d’administrateur. Demandez à un administrateur du locataire de vérifier le rôle attribué.

</details>

<details>

<summary>L’inscription crée-t-elle automatiquement un locataire ?</summary>

Non. L’inscription crée uniquement le compte. L’accès à un locataire est accordé séparément.

</details>

<details>

<summary>Puis-je accéder à plusieurs locataires avec le même compte ?</summary>

Oui. Le même compte peut se voir accorder l’accès à plusieurs locataires. Le rôle attribué peut différer d’un locataire à l’autre.

</details>

<details>

<summary>Dois-je utiliser mon adresse e-mail professionnelle ou personnelle ?</summary>

Utilisez une adresse e-mail professionnelle dès que possible. Cela facilite l’intégration et la gestion des accès.

</details>

<details>

<summary>J’ai choisi la mauvaise méthode de connexion (Google vs Microsoft vs e-mail). Puis-je la changer plus tard ?</summary>

Évitez de vous réinscrire avec une méthode différente, car cela peut créer une seconde identité. Si vous devez changer de méthode, contactez le support de The Wallet Crew afin que l’accès puisse être réattribué en toute sécurité.

</details>


# Clés API et secrets

Gérez les trois types d'identifiants utilisés pour authentifier les appels API, les intégrations SDK et les connexions des connecteurs.

Les clés API authentifient les appels serveur à serveur vers les API de The Wallet Crew. Les clés API sont limitées au locataire. Une clé ne fonctionne que pour un seul locataire. Les intégrations couvrant plusieurs locataires nécessitent une clé par locataire.

Les clés API peuvent également être limitées à certaines portées. Le principe du moindre privilège réduit les risques et limite le rayon d’impact.

<details>

<summary>Exemples concrets</summary>

* Un job CRM de marque met à jour les points de fidélité chaque nuit, puis déclenche les mises à jour des cartes.
* Un middleware d’intégration émet de nouvelles cartes après un événement de paiement e-commerce.
* Un pipeline de données récupère le statut d’installation des cartes et l’envoie à l’analytique.

</details>

## Avant de commencer

* Un compte administrateur ayant accès à **Paramètres** est requis.
* L’utilisation prévue et le système propriétaire sont identifiés (service, job, connecteur).
* Les portées minimales requises sont indiquées. Chaque point de terminaison de l’API documente ses portées requises, et la console d’administration liste les portées disponibles au moment de la création de la clé.

{% hint style="warning" %}
Ne publiez jamais une clé API dans une application mobile ou dans du JavaScript côté front-end. Traitez-la comme un mot de passe.
{% endhint %}

### Créer une clé API

{% stepper %}
{% step %}

#### Ouvrir les clés API

1. Connectez-vous à la console d'administration.
2. Accédez à **Paramètres → Sécurité → Clés API**.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/security/apiKeys" class="button secondary" data-icon="chevrons-right">The Wallet Crew - Clés API</a></p>
{% endstep %}

{% step %}

#### Ajouter une nouvelle clé

1. Cliquez sur **Ajouter**.
2. Attribuez un nom clair.
   * Exemple : `crm-sync-prod` ou `nightly-Carte-update`.
3. Sélectionnez les portées dont vous avez besoin.
4. Cliquez sur **Enregistrer**.
   {% endstep %}

{% step %}

#### Copiez et stockez la clé

La valeur de la clé n’est affichée qu’une seule fois, juste après sa création. Une fois la boîte de dialogue fermée, la valeur ne peut pas être récupérée.

La clé doit être stockée dans un gestionnaire de secrets. L’accès en lecture doit être limité au plus petit ensemble de services et d’opérateurs nécessaire pour exécuter l’intégration.
{% endstep %}
{% endstepper %}

### Utilisez la clé dans les requêtes API

Envoyez la clé dans l’ `X-API-KEY` en-tête.

Exemple d’en-tête :

`X-API-KEY : <votre_clé_api>`

La liste complète des points de terminaison et les formats de requête/réponse sont disponibles dans la [référence de l’API](https://docs.thewalletcrew.io/api-reference/).

#### Valider rapidement l’accès

Les échecs d’authentification et d’autorisation se ressemblent, mais nécessitent des correctifs différents. Un flux de validation rapide aide à isoler le problème tôt.

Exécutez une requête à faible impact `GET` requête qui correspond aux étendues sélectionnées. Un `401 Non autorisé` la réponse indique généralement une clé manquante, invalide ou révoquée. Une `403 Interdit` la réponse indique généralement une clé valide avec des étendues insuffisantes.

### Gérer, faire pivoter, révoquer

* **Faire pivoter** les clés régulièrement.
  * Créez une nouvelle clé.
  * Déployez-la sur vos services.
  * Révoquez l’ancienne clé après un court chevauchement.
* **Révoquer** révoquez les clés immédiatement si elles sont divulguées.
* Conservez des clés séparées pour chaque environnement et chaque intégration.

### Dépannage

* **401 Non autorisé**
  * Manquante ou invalide `X-API-KEY` en-tête.
  * La clé a été révoquée.
* **403 Interdit**
  * La clé est valide mais il manque le scope requis.

### FAQ

<details>

<summary>Une clé API peut-elle être utilisée pour plusieurs locataires ?</summary>

Non. Les clés API sont limitées à un locataire. Chaque locataire nécessite sa propre clé, même lorsque la même intégration s’exécute sur plusieurs locataires.

</details>

<details>

<summary>Une clé API peut-elle être récupérée ultérieurement si elle n’a pas été copiée ?</summary>

Les clés API sont conçues pour n’être affichées qu’une seule fois lors de leur création. Si la valeur est perdue, la solution la plus sûre consiste à révoquer l’ancienne clé et à en créer une nouvelle.

</details>

<details>

<summary>Quelle est la meilleure façon de nommer les clés API ?</summary>

Un nom doit identifier le système propriétaire et l’environnement. Des noms comme `crm-sync-prod` ou `data-export-staging` rendent la rotation et la réponse aux incidents beaucoup plus rapides.

</details>

<details>

<summary>Comment faire pivoter les clés sans interruption de service ?</summary>

Créez une nouvelle clé et déployez-la d’abord. Laissez les deux clés actives pendant une courte période de chevauchement. Révoquez l’ancienne clé une fois que les journaux confirment que la nouvelle clé est utilisée partout.

</details>

<details>

<summary>Où se trouve la référence des scopes ?</summary>

Chaque point de terminaison API documente les scopes requis dans sa propre documentation.

La console d’administration reste l’endroit où les scopes disponibles peuvent être consultés et sélectionnés lors de la création ou de la modification d’une clé.

</details>

## Secrets généraux

Les secrets généraux sont des identifiants nommés utilisés par les intégrations SDK. Créez un secret général lorsqu’une intégration SDK nécessite un secret partagé qui n’est pas une clé API.

### Créer un secret général

1. Accédez à **Paramètres → Contrôle d’accès → Clés et secrets API**.
2. Ouvrez le **Secrets généraux** .
3. Cliquez sur **Ajouter** et attribuez au secret un nom explicite.
4. Copiez la valeur immédiatement. Elle n’est affichée qu’une seule fois.

Stockez la valeur dans le gestionnaire de secrets de l’intégration. Traitez-la avec les mêmes précautions qu’une clé API.

## Secrets d’application

Les secrets d’application sont des identifiants que les connecteurs utilisent pour s’authentifier auprès de systèmes externes. Parmi les exemples figurent des mots de passe et des jetons d’accès pour un CRM, un terminal de point de vente ou une plateforme marketing.

La plupart des connecteurs gèrent les secrets d’application via leur propre interface de configuration. Des modifications directes dans cet onglet sont rarement nécessaires. Le flux de configuration du connecteur s’en charge.

### Afficher ou mettre à jour manuellement un secret d’application

1. Accédez à **Paramètres → Contrôle d’accès → Clés et secrets API**.
2. Ouvrez le **Secrets d’application** .
3. Sélectionnez le secret à modifier.

{% hint style="info" %}
Lors de la configuration d’un connecteur, utilisez son interface de configuration plutôt que de modifier directement les secrets d’application. L’interface du connecteur guide la configuration et valide les identifiants.
{% endhint %}


# Domaine personnalisé

Utilisez un domaine détenu par la marque pour les pages hébergées de The Wallet Crew, telles que l'inscription, le téléchargement de la Carte et les parcours Wallet liés au compte.

Un domaine personnalisé aligne les pages hébergées The Wallet Crew avec l’identité de marque. Il réduit également le risque de phishing et renforce la confiance lorsque les clients ouvrent les parcours d’inscription ou de téléchargement de Carte.

Par défaut, The Wallet Crew sert les pages hébergées sur un domaine The Wallet Crew tel que `https://app.neostore.cloud/<tenantId>/<layout>`. Un domaine personnalisé remplace ce point d’entrée public par un domaine appartenant à la marque, tel que `https://wallet.example.com`.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un commerçant utilise `wallet.brand.com` pour l’inscription au programme de fidélité et la récupération de la carte.
* Un organisateur d’événements utilise `tickets.brand.com` pour le téléchargement du billet Wallet après achat.
* Une marque utilise `registration.brand.com` pour maintenir le parcours web aligné avec l’identité de son expéditeur d’e-mails.

</details>

## Pourquoi utiliser un domaine personnalisé

L’objectif principal est la confiance. Une URL de marque est plus facile à reconnaître qu’un domaine de plateforme partagé. Cela améliore généralement la conversion sur les parcours sensibles tels que l’inscription, la connexion et le téléchargement de Carte.

Cela améliore aussi la posture de sécurité. Un sous-domaine dédié rend l’usurpation plus facile à détecter et isole le trafic lié au Wallet du site principal.

### Avant de commencer

Choisissez le domaine public qui hébergera le parcours. Un sous-domaine dédié est recommandé, par exemple `wallet.example.com` ou `registration.example.com`.

La marque doit également avoir accès à sa zone DNS. Toutes les modifications DNS y sont effectuées.

{% hint style="info" %}
Cette page couvre uniquement le domaine web hébergé.

Les domaines d’expéditeur d’e-mails sont configurés séparément. Pour la livraison d’e-mails, voir [Fournisseur d’e-mails](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/5ddad57765f228b39ce623583385b6ad8a760927) et [SendGrid](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/b233ea6967a944bb31c49efad487b677c087886f).
{% endhint %}

### Comment fonctionne la configuration

Les domaines personnalisés pour les pages hébergées The Wallet Crew sont gérés via Cloudflare. The Wallet Crew prépare la configuration côté Cloudflare et fournit les enregistrements DNS exacts à publier. La marque ajoute ces enregistrements chez son fournisseur DNS.

Après la réussite de la première validation, des enregistrements supplémentaires peuvent être nécessaires pour la vérification de la propriété du domaine et l’émission du certificat. The Wallet Crew gère le cycle de vie du certificat hébergé via Cloudflare une fois la validation DNS terminée.

### Configurer le domaine personnalisé

{% stepper %}
{% step %}

#### Sélectionner le domaine public

Choisissez le domaine ou le sous-domaine qui sera exposé aux clients.

Exemples :

* `wallet.example.com`
* `registration.example.com`
* `tickets.example.com`

Dans la plupart des cas, un sous-domaine dédié est l’option la plus sûre. Il évite les conflits avec un site existant et isole le trafic du Wallet.
{% endstep %}

{% step %}

#### Demander l’activation auprès de The Wallet Crew

Partagez le domaine choisi avec The Wallet Crew.

À ce stade, The Wallet Crew prépare la configuration hébergée et renvoie les enregistrements DNS nécessaires à la validation et au routage.
{% endstep %}

{% step %}

#### Publier les enregistrements DNS

Ajoutez les enregistrements exactement tels que fournis par The Wallet Crew dans la zone DNS de la marque.

Le premier ensemble comprend généralement :

* un enregistrement de routage pour que le domaine pointe vers les pages hébergées The Wallet Crew
* un ou plusieurs enregistrements TXT pour la propriété du domaine ou la validation du certificat

Les noms et valeurs exacts dépendent du tenant. Ils ne doivent pas être devinés ni réutilisés depuis un autre environnement.
{% endstep %}

{% step %}

#### Terminer la phase de validation

Une fois les premiers enregistrements visibles dans le DNS, The Wallet Crew valide le domaine.

Si des enregistrements supplémentaires sont nécessaires, The Wallet Crew les partage. Ajoutez ces enregistrements, puis attendez la fin de la validation finale.
{% endstep %}

{% step %}

#### Tester le parcours de bout en bout

Avant la mise en production, ouvrez l’URL finale et validez le parcours complet :

* la page se résout sur le domaine personnalisé
* HTTPS est valide
* la mise en page prévue se charge correctement
* les flux d’inscription, de connexion ou de téléchargement de Carte fonctionnent toujours comme prévu

Si le domaine personnalisé est utilisé avec la connexion sociale, mettez également à jour les origines autorisées ou la configuration de rappel dans le fournisseur d’identité.
{% endstep %}
{% endstepper %}

### Exemples d’enregistrements DNS

Les enregistrements exacts varient selon le tenant et l’état de l’infrastructure. L’exemple ci-dessous est anonymisé et ne montre que le schéma habituel.

| Type  | Nom d’hôte                                    | Valeur                                                           | Objectif                                             |
| ----- | --------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------- |
| CNAME | registration.example.com                      | app.neostore.cloud                                               | Redirige le trafic client vers les pages hébergées   |
| TXT   | asuid.registration.example.com                | 621ECF9549EAE65BA089A426C8142E089EF4C6916FB9AB9F21C111F30D85E816 | Validation de la propriété du domaine                |
| TXT   | \_acme-challenge.registration.example.com     | 7xLnjbponxeyiXkNsdIdrheyHHGouoFmfOXVvO9OAf8                      | Validation du certificat                             |
| TXT   | \_cf-custom-hostname.registration.example.com | cdea2f9a-2a68-48ed-a83d-88403213a690                             | Validation supplémentaire du nom d’hôte personnalisé |

### Valider avant la mise en production

Utilisez cette liste de contrôle avant d’exposer le domaine publiquement :

* Le DNS résout vers la cible attendue.
* HTTPS est actif sur l’URL finale.
* La page hébergée s’affiche avec la marque et la langue attendues.
* Tout fournisseur d’identité lié a été mis à jour avec le nouveau domaine.
* Les équipes internes utilisent le domaine personnalisé dans les campagnes, les QR codes et les scripts d’assistance.

### Pièges fréquents

La plupart des problèmes proviennent du DNS ou d’autres systèmes qui pointent encore vers l’ancien domaine.

* **Utiliser le domaine racine au lieu d’un sous-domaine dédié** peut créer des conflits avec le site principal.
* **Publier uniquement le CNAME** ne suffit généralement pas. Des enregistrements TXT de validation sont souvent nécessaires aussi.
* **Tester trop tôt** peut produire de faux négatifs tant que le DNS se propage encore.
* **Oublier les listes d’autorisation OAuth** peut casser la connexion Google, Apple ou Facebook sur le nouveau domaine.
* **Mélanger la configuration du domaine web et du domaine d’expéditeur d’e-mails** crée de la confusion. Il s’agit de choix de marque liés, mais de configurations techniques distinctes.

## FAQ

<details>

<summary><strong>Un domaine personnalisé doit-il être un sous-domaine ?</strong></summary>

Non. Un sous-domaine est fortement recommandé pour faire respecter l’autorité de la marque.

Il est plus facile à isoler, plus sûr à exploiter et moins susceptible d’entrer en conflit avec un site web ou une configuration de messagerie existants.

</details>

<details>

<summary><strong>La marque doit-elle fournir son propre certificat SSL ?</strong></summary>

Non.

La marque gère les enregistrements DNS. The Wallet Crew gère le cycle de vie du certificat hébergé une fois la validation du domaine réussie.

</details>

<details>

<summary><strong>Pourquoi plusieurs enregistrements TXT peuvent-ils être nécessaires ?</strong></summary>

Différents composants de la plateforme peuvent exiger différentes étapes de validation.

Un enregistrement peut prouver la propriété du domaine. Un autre peut valider l’émission du certificat. Un troisième peut valider la configuration du nom d’hôte personnalisé.

</details>

<details>

<summary><strong>La marque peut-elle utiliser des enregistrements DNS Cloudflare Proxied ?</strong></summary>

Oui.

The Wallet Crew prend en charge **Proxied** mode, souvent appelé proxy orange-cloud ou proxy orange-to-orange. Cela permet à la marque de conserver ses propres règles Cloudflare de sécurité, de routage et de trafic devant les pages hébergées The Wallet Crew, en plus des contrôles de sécurité déjà gérés par The Wallet Crew.

</details>

<details>

<summary><strong>Le même domaine peut-il aussi être utilisé pour l’envoi d’e-mails ?</strong></summary>

Le même espace de noms de marque peut être réutilisé, mais l’hébergement web et l’envoi d’e-mails sont des configurations séparées.

Par exemple, une marque peut utiliser `registration.example.com` pour les pages hébergées et `no-reply@registration.example.com` pour les e-mails transactionnels. Les enregistrements DNS et le processus de validation restent différents.

</details>

<details>

<summary><strong>Combien de temps prend la configuration ?</strong></summary>

Le délai dépend surtout de la propagation DNS et de la rapidité avec laquelle les enregistrements requis sont ajoutés.

La séquence pratique est simple : recevoir les enregistrements, les publier, attendre la validation, puis effectuer un test de bout en bout.

</details>

<details>

<summary><strong>Quoi d’autre doit être mis à jour après le passage à un domaine personnalisé ?</strong></summary>

Tout système qui valide l’origine publique doit être examiné.

Les exemples courants incluent les fournisseurs de connexion sociale, les listes d’autorisation de redirection, les campagnes de QR codes, les modèles d’e-mails et la documentation d’assistance qui fait encore référence au domaine par défaut The Wallet Crew.

</details>

<details>

<summary><strong>Que se passe-t-il si le sous-domaine sélectionné pointe déjà vers autre chose ?</strong></summary>

Ce sous-domaine ne peut pas pointer vers deux cibles différentes en même temps.

S’il est déjà utilisé par un autre service, déplacez d’abord ce service ou choisissez un autre sous-domaine dédié pour The Wallet Crew.

</details>


# Données et intégrations

Gérez les données de référence du programme Wallet, y compris les emplacements des magasins et des lieux pour les notifications géolocalisées.

## Données et intégrations

Données et intégrations gère les jeux de données de référence utilisés dans les programmes Wallet.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>Magasins</h4></td><td>Gérez les emplacements physiques pour les notifications de Carte Wallet géolocalisées.</td><td></td><td><a href="/pages/74540ae1599ba0ec6504bfa46748df23f71e43f1">/pages/74540ae1599ba0ec6504bfa46748df23f71e43f1</a></td></tr></tbody></table>

**Magasins** est un registre d’emplacements physiques, notamment des magasins, des lieux et des boutiques éphémères. Chaque enregistrement contient un nom, un identifiant stable et des coordonnées GPS. L’équipe Wallet utilise ces coordonnées pour les déclencheurs de localisation de Carte Wallet et les messages à proximité.


# Magasins

Gérez les emplacements physiques des magasins et des lieux pour les notifications de cartes Apple Wallet et Google Wallet géolocalisées.

## Gérer les magasins pour les notifications géolocalisées de Carte Wallet

Stores est le registre des emplacements physiques d'un programme Wallet. Il prend en charge les magasins de détail, les lieux, les pop-ups et d'autres sites basés sur une adresse.

L'équipe Wallet intègre des emplacements configurés dans les Cartes Wallet. Un téléphone peut ensuite afficher un message contextuel lorsqu'un client se trouve à proximité.

{% hint style="info" %}
Les magasins sont un prérequis pour les notifications géolocalisées. Au moins un magasin doit exister et être géocodé avant que des déclencheurs de localisation puissent être configurés sur un modèle de Carte.

Configurez les notifications géolocalisées sur le modèle de Carte après avoir géocodé un magasin.
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un détaillant peut ajouter le magasin préféré d'un client à une Carte de fidélité.
* Un organisateur d'événements peut ajouter un lieu à un billet d'événement.
* Une marque peut ajouter des emplacements de pop-up de campagne à une Carte Wallet.

</details>

### Champs de localisation du magasin

| Champ                    | Description                                                                                                                                                                           |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ID**                   | Un identifiant unique pour cet emplacement. Lecture seule après la création. Associé aux données client, comme un code de magasin habituel provenant d'un point de vente ou d'un CRM. |
| **Nom du magasin**       | Un libellé lisible par l'humain pour la gestion interne. Non affiché aux utilisateurs finaux.                                                                                         |
| **Adresse**              | Adresse postale. Utilisée pour géocoder automatiquement les coordonnées.                                                                                                              |
| **Latitude / Longitude** | Coordonnées GPS. Renseignées automatiquement avec **Rechercher**, ou saisies manuellement.                                                                                            |

### Créer et géocoder un magasin

Créez un enregistrement de magasin avant de configurer un déclencheur de localisation. Utilisez un ID stable afin que l'enregistrement puisse être associé aux données source.

{% stepper %}
{% step %}
**Accédez à Données et intégrations → Stores**

Ouvrez la page Stores depuis la navigation de gauche.
{% endstep %}

{% step %}
**Cliquez sur Ajouter**

Le formulaire de modification s'ouvre.
{% endstep %}

{% step %}
**Renseignez l'ID et le nom du magasin**

Utilisez un ID stable issu du système source, comme un code de magasin POS ou un ID d'emplacement CRM. L'ID ne peut pas être modifié après la création.
{% endstep %}

{% step %}
**Saisissez l'adresse et géocodez-la**

Saisissez l'adresse dans **Adresse**, puis cliquez sur **Rechercher**. La plateforme résout les coordonnées GPS et place un repère sur la carte. Vérifiez la position du repère avant d'enregistrer.

Si l'emplacement résolu est incorrect, ajustez la latitude et la longitude manuellement. Cela peut se produire pour de grands lieux.
{% endstep %}

{% step %}
**Enregistrer**

Cliquez sur **Enregistrer**. Le magasin est maintenant disponible pour la configuration géolocalisée.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Le **ID** est permanent. Utilisez une valeur stable et reconnaissable provenant des systèmes existants. Les modèles de Carte et la logique Liquid se réfèrent à cet ID, par exemple pour attribuer le magasin habituel d'un client.
{% endhint %}

### Importer des emplacements de magasins en masse

Utilisez **Importer** pour les longues listes d'emplacements. Utilisez **Exporter** d'abord pour télécharger un modèle CSV au format attendu.

### Modifier ou supprimer un emplacement de magasin

Cliquez sur une ligne pour modifier son nom, son adresse ou ses coordonnées. Utilisez **Supprimer** pour supprimer un magasin.

{% hint style="info" %}
La suppression d'un magasin le retire des futurs calculs de localisation. Les Cartes émises conservent ses coordonnées jusqu'à leur prochaine mise à jour.
{% endhint %}

Lorsqu'un magasin ferme définitivement, supprimez également son [lien de redirection ou code QR associé](/guides-enrolment/fr/inscription/enrolment-form/redirect) afin d'empêcher les clients de scanner un code qui ne mène plus à un parcours d'inscription actif.

### Limites de géolocalisation pour les Cartes Wallet

Apple Wallet et Google Wallet imposent les limites de géolocalisation suivantes :

| Limite                                  | Valeur |
| --------------------------------------- | ------ |
| Nombre maximal de coordonnées par Carte | 10     |
| Rayon maximal par coordonnée            | 300 m  |

L'équipe Wallet sélectionne les magasins à intégrer dans chaque Carte, en fonction de la configuration. Les programmes de vente au détail intègrent souvent le magasin habituel d'un client et les neuf emplacements les plus proches.

### Questions fréquentes sur les magasins et la géolocalisation

<details>

<summary><strong>Stores peut-il être utilisé pour des lieux d'événements ?</strong></summary>

Oui. Tout emplacement basé sur une adresse peut être un enregistrement de magasin. Cela inclut les stades, les salles de concert, les centres de conférence et les sites pop-up. Le registre s'appelle « Stores », mais ses enregistrements ne se limitent pas aux emplacements de vente au détail.

</details>

<details>

<summary><strong>Que se passe-t-il lorsqu'une adresse de magasin change ?</strong></summary>

La modification d'une adresse et un nouveau géocodage mettent à jour les coordonnées du registre. Les nouvelles coordonnées s'appliquent lors de la prochaine mise à jour de la Carte. Les Cartes émises conservent les coordonnées précédentes jusque-là.

</details>

<details>

<summary><strong>Les coordonnées sont-elles requises pour chaque magasin ?</strong></summary>

Seuls les magasins avec latitude et longitude peuvent être intégrés dans une Carte. Les enregistrements sans coordonnées restent valides, mais ne peuvent pas déclencher la géolocalisation.

</details>


# Wallet

La section Wallet couvre tout ce qui concerne la manière dont les cartes sont configurées, conçues, sécurisées et migrées. Ces paramètres sont spécifiques à chaque marque — chacun d’eux influence directement ce que voient les utilisateurs finaux et le comportement des cartes dans Apple Wallet et Google Wallet.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>Apple et Google Wallet</h4></td><td>Connectez votre compte Apple Developer et la console Google Pay &#x26; Wallet à TWC.</td><td><a href="/files/5445a4de3185b4a1e2af16ae3c6de6b197f1a50a">/files/5445a4de3185b4a1e2af16ae3c6de6b197f1a50a</a></td><td><a href="/pages/9f016bb435dc77ed31e8ca3a01c8df477aec0c28">/pages/9f016bb435dc77ed31e8ca3a01c8df477aec0c28</a></td></tr><tr><td><h4>Configuration du modèle</h4></td><td>Créez et personnalisez vos modèles de cartes Wallet : couleurs, logos, mise en page des champs, prise en charge multilingue.</td><td><a href="/files/0170ee8eab24983af595ccc770872821f09b6fa6">/files/0170ee8eab24983af595ccc770872821f09b6fa6</a></td><td><a href="/pages/98c94e3ccc4e7820d8b9f7c521c0d912aaa2b0c6">/pages/98c94e3ccc4e7820d8b9f7c521c0d912aaa2b0c6</a></td></tr><tr><td><h4>Sécurité des cartes Wallet</h4></td><td>Conforme au RGPD et au CCPA, résidence des données dans l’UE, chiffrement de bout en bout, isolation stricte par locataire.</td><td><a href="/files/2cef69ea59f75bdcd650e82a4768755d31042cdf">/files/2cef69ea59f75bdcd650e82a4768755d31042cdf</a></td><td><a href="/pages/0d1e8f241c3850dd2df78c9a8e8aed1a0b443867">/pages/0d1e8f241c3850dd2df78c9a8e8aed1a0b443867</a></td></tr><tr><td><h4>Importation et exportation</h4></td><td>Migrez les cartes actives d’un autre fournisseur, mettez à jour les données des cartes via des fichiers plats ou exportez les cartes vers un nouveau fournisseur.</td><td><a href="/files/24c5b2cfc809e6e0dbe9482e04741c107d460277">/files/24c5b2cfc809e6e0dbe9482e04741c107d460277</a></td><td><a href="/pages/3339a2685b82c0712a37bdee5617f06ebb2f7e3d">/pages/3339a2685b82c0712a37bdee5617f06ebb2f7e3d</a></td></tr></tbody></table>

**Apple et Google Wallet** Les identifiants définissent quelle entité émet les cartes sur chaque plateforme. Plutôt que d’utiliser des identités partagées ou par défaut de la plateforme, TWC exige que les marques connectent leur propre compte Apple Developer et Google Pay & Wallet Console. Cela garantit que les cartes sont distribuées au nom de la marque, avec un contrôle total sur les certificats, les jetons de notification push et les identifiants API. Ces identifiants sont un prérequis pour toute émission de cartes.

**Configuration du modèle** C’est là que l’identité visuelle et structurelle de chaque type de carte est définie. Les modèles contrôlent les couleurs, les logos, les images, les libellés et valeurs des champs, les informations supplémentaires et les liens — pour Apple Wallet et Google Wallet. Le contenu dynamique est géré via Liquid (DotLiquid), ce qui permet aux valeurs des champs de s’adapter à chaque carte sans intervention d’un développeur. Les modèles peuvent également être traduits en plusieurs langues, avec traduction champ par champ ou export et import en masse via Excel.

**Sécurité des cartes Wallet** documente la posture de sécurité et de conformité de la plateforme. Les cartes et les données personnelles associées sont stockées exclusivement dans l’Union européenne, chiffrées au repos et en transit, et isolées par locataire. La plateforme est conforme au RGPD et au CCPA. Les liens de distribution sont signés cryptographiquement pour empêcher toute falsification. Cette section constitue la référence principale pour les questionnaires de sécurité et les examens de conformité.

**Importation et exportation** couvre les scénarios où les cartes doivent être déplacées — soit vers The Wallet Crew, soit hors de The Wallet Crew. Les cartes existantes d’un autre fournisseur peuvent être migrées vers TWC sans qu’il soit nécessaire pour les utilisateurs finaux de réinstaller quoi que ce soit. Les données des cartes peuvent également être mises à jour en masse via des fichiers plats téléversés par SFTP. Lors d’un changement de fournisseur, TWC prend en charge l’exportation des cartes avec les contraintes propres à chaque plateforme.

Ces quatre domaines sont indépendants, mais fonctionnent ensemble. Commencer par renseigner les identifiants Apple & Google Wallet est l’étape de départ recommandée — sans eux, aucune carte ne peut être émise, quelle que soit la configuration des modèles ou des paramètres de sécurité.


# Apple Wallet et Google Wallet

Configurez Apple Wallet et Google Wallet en toute sécurité, avec des identifiants détenus par la marque pour la conformité.

The Wallet Crew génère des cartes pour Apple Wallet et Google Wallet au nom de Brand. Apple et Google appliquent des règles strictes en matière d’identité de l’émetteur, de signature et de traitement des données. Cette configuration est essentielle pour la conformité et la sécurité. Brand doit utiliser des comptes d’émetteur Apple et Google appartenant à Brand ainsi que les identifiants associés.

Brand configure et contrôle les comptes et les identifiants nécessaires pour émettre des cartes (certificats, clés, identifiants d’émetteur et approbations). The Wallet Crew utilise les valeurs fournies par Brand pour signer et gérer les cartes en toute sécurité. Cela maintient Brand comme émetteur officiel et réduit le risque lié aux identifiants. The Wallet Crew agit en tant que fournisseur technique.

En pratique, les équipes juridiques et informatiques de Brand gèrent la configuration du « côté émetteur ». Cela inclut la propriété des comptes, les identifiants d’émetteur, les identifiants de signature et les approbations du fournisseur. Brand peut faire tourner ou révoquer les identifiants à tout moment. The Wallet Crew ne doit pas être le propriétaire à long terme des identifiants d’émetteur.

{% hint style="warning" %}
Cette configuration permet à Brand de garder le contrôle de l’identité de l’émetteur et des données des cartes. Elle renforce aussi la sécurité en évitant que des clés de signature et des comptes de fournisseur soient détenus par un tiers, et en permettant à Brand d’assurer la rotation et la révocation des identifiants.
{% endhint %}

Les équipes sécurité de Brand peuvent consulter le modèle de sécurité de la plateforme dans [Sécurité de la carte Wallet](/configure/fr/advanced-configuration/wallet/wallet-card-security).

### Ce qui se passe pendant le processus d’onboarding

* Brand effectue la configuration requise d’Apple et de Google sous les comptes de Brand.
* Brand partage les identifiants et les accès requis dans la console d’administration.
* The Wallet Crew vérifie que la configuration correspond aux exigences d’Apple et de Google.
* The Wallet Crew confirme que tout est prêt pour la génération et les tests des cartes.

### Plus d’informations

Utilisez les guides de configuration spécifiques à la plateforme ci-dessous

* Apple : créez et gérez les certificats et les clés de notification push : [Certificats Apple Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/apple-wallet-certificates)
* Google : configurez le compte d’émetteur et les identifiants requis : [Compte Google Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account)

### FAQ

<details>

<summary><strong>Une marque peut-elle être mise en ligne avec seulement Apple Wallet ou seulement Google Wallet ?</strong></summary>

**Non**. Brand doit configurer à la fois Apple Wallet et Google Wallet avant la mise en ligne, afin que le programme couvre dès le premier jour les utilisateurs iOS et Android.

</details>

<details>

<summary><strong>The Wallet Crew peut-elle configurer Apple/Google pour une marque (accès délégué) ?</strong></summary>

**Oui**. Brand peut accorder un accès administrateur temporaire dans les portails du fournisseur, déléguer la configuration à The Wallet Crew, puis supprimer l’accès administrateur après validation. Brand reste propriétaire des comptes et des identifiants.

</details>

<details>

<summary><strong>Combien de temps prend la configuration ?</strong></summary>

Cela dépend de la taille de l’organisation et du fait que Brand possède déjà les comptes Apple et Google. La configuration prend environ **15 minutes à 1 heure** par fournisseur de Wallet.

</details>

<details>

<summary><strong>Une marque peut-elle faire tourner ou révoquer les identifiants ? Qu’arrive-t-il aux cartes existantes ?</strong></summary>

**Oui**. Brand peut faire tourner ou révoquer les identifiants à tout moment. Si les identifiants sont révoqués, l’émission et les mises à jour peuvent s’arrêter jusqu’à leur remplacement, et les cartes installées peuvent cesser de se mettre à jour.

</details>

<details>

<summary><strong>Brand doit-elle configurer à la fois la préproduction et la production ?</strong></summary>

**Non**. Brand peut commencer par configurer un seul environnement. The Wallet Crew peut répliquer les changements de configuration à la demande.

</details>

<details>

<summary><strong>Brand a-t-elle besoin de toutes les informations avant de commencer le projet ?</strong></summary>

**Non**. The Wallet Crew peut fournir des identifiants de test pour configurer et mettre en place la plateforme pendant que l’équipe Brand termine la configuration.

Ces identifiants **ne peuvent pas être utilisés en production**. Ils sont réservés aux tests uniquement.

</details>


# Certificats Apple Wallet

Configurez votre compte Apple Developer pour distribuer des cartes Wallet numériques via la plateforme The Wallet Crew. Ce guide couvre la création de certificats, la configuration des notifications push et la gestion des identifiants

Pour émettre des cartes Apple Wallet qui affichent la marque de votre entreprise et reçoivent des mises à jour en temps réel, vous devez mettre en place des certificats et des identifiants de notifications push via le programme Apple Developer.

<figure><img src="/files/7aed495868afecf0dad83af49a42fa01d3587904" alt="The brand requests a Pass Type Certificate and an APNs key from Apple and delegates The Wallet Crew to issue the passes."><figcaption></figcaption></figure>

Vous voulez le « pourquoi » avant le « comment » ? Commencez par [Wallet Apple et Google](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet).

## Avant de commencer

### Ce que vous accomplirez

* Créez un ID de type de Carte qui identifie votre organisation comme l’émetteur des cartes
* Générez et configurez les certificats qui signent vos cartes Wallet
* Configurez le service Apple Push Notification (APNs) pour les mises à jour de cartes en temps réel
* Connectez les identifiants de votre compte Apple Developer à la plateforme The Wallet Crew

### Prérequis

* Adhésion active au programme Apple Developer (99 $/an pour les organisations)
* Accès administrateur à votre compte Apple Developer
* Autorisation de créer des certificats et des clés d’authentification
* Accès à la console d’administration de The Wallet Crew

### Exigences d’inscription au programme Apple Developer

Avant de commencer cette configuration, assurez-vous que votre organisation s’est inscrite au programme Apple Developer en tant que **Organisation** (et non en tant que particulier). Cette inscription nécessite :

* **numéro D-U-N-S** de Dun & Bradstreet pour la vérification de l’entreprise. Apple l’envoie généralement par e-mail avec l’objet `Votre numéro D-U-N-S est inclus.` de `Apple Developer <developer@email.apple.com>`
* **Adresse e-mail professionnelle** associée au domaine de votre entreprise (évitez les comptes Gmail/Yahoo personnels)
* **Site web publiquement accessible** reflétant l’identité juridique de votre entreprise
* **Pouvoir de signature légal** en tant que propriétaire, dirigeant ou employé autorisé à signer les accords d’Apple

Si vous ne vous êtes pas encore inscrit, rendez-vous sur la page d’inscription au programme Apple Developer pour commencer le processus. Une inscription en tant qu’organisation (plutôt qu’en tant que particulier) garantit que le nom de votre entreprise apparaît sur les cartes Wallet et permet la gestion du compte par plusieurs utilisateurs.

<p align="center"><a href="https://developer.apple.com/programs/enroll/" class="button secondary" data-icon="chevrons-right">Page d’inscription au programme Apple Developer</a></p>

## Lancement

### Choisissez un mode de configuration

* **Option 1 — délégation de compte :** Accordez à The Wallet Crew un accès administrateur pour configurer l’intégration. C’est l’option la plus rapide.
* **Option 2 — configuration autonome :** Gérez l’ensemble de la configuration au sein de l’organisation. Cela permet de conserver un contrôle d’accès strict et nécessite une bonne connaissance d’Apple Developer.

Les deux options offrent les mêmes fonctionnalités. La délégation de compte réduit la charge de mise en œuvre. La configuration autonome conserve un contrôle interne complet.

### Option 1 — délégation de compte

Cette approche permet à l’équipe The Wallet Crew de gérer toute la configuration technique pendant que vous conservez la propriété de votre compte Apple Developer. Vous accorderez un accès administrateur temporaire, et nous configurerons les certificats, les clés et les identifiants conformément aux bonnes pratiques d’Apple.

#### Accorder l’accès administrateur

Accédez à Utilisateurs d’App Store Connect et connectez-vous avec les identifiants de votre compte Apple Developer.

<p align="center"><a href="https://appstoreconnect.apple.com/access/users" class="button secondary" data-icon="chevrons-right">Utilisateur Apple Store Connect</a></p>

Cliquez sur le **bouton Ajouter (+)** pour inviter un nouvel utilisateur. Saisissez `contact@neostore.cloud` comme adresse e-mail et attribuez le **Administrateur** rôle. Ce niveau d’autorisation permet à l’équipe The Wallet Crew de créer des ID de type de Carte, de générer des certificats, de configurer des clés de notification push et d’effectuer toutes les étapes de configuration nécessaires.

<div data-with-frame="true"><figure><img src="/files/972423eececef03104b31c489827bcdc70e668e0" alt="App Store Connect users page showing how to invite a new admin user" width="375"><figcaption><p>Page des utilisateurs d’App Store Connect montrant comment inviter un nouvel utilisateur administrateur</p></figcaption></figure></div>

L’équipe Wallet Crew recevra une notification d’invitation et procédera à la création de la Carte Type ID, à la génération des certificats et à la configuration d’APNs. Nous vous informerons lorsque la configuration sera terminée et vous fournirons la documentation de toutes les ressources créées. Vous pouvez révoquer cet accès administrateur après avoir confirmé que l’émission et les mises à jour des Cartes Wallet fonctionnent correctement.

**Ce qui se passe ensuite :** Après que vous avez accordé l'accès, nous créons votre Carte Type ID (formaté comme `Carte.com.thewalletcrew.{tenantId}`), générer le certificat de signature, configurer les notifications push et tout téléverser dans votre locataire. Cela prend généralement 1 à 3 jours ouvrables. Nous vous confirmerons par e-mail et partagerons un bref résumé de ce qui a été créé.

### Option 2 — configuration par vous-même

Vous gérez l’ensemble de la configuration dans votre compte Apple Developer et la console d’administration de The Wallet Crew. Cette option nécessite une familiarité avec l’infrastructure des certificats d’Apple, mais maintient un contrôle d’accès interne strict.

#### Comprendre les composants

Avant de continuer, il est utile de comprendre ce que vous créez :

Votre **ID de type de Carte** est l'identifiant de l'émetteur (par exemple `Carte.com.thewalletcrew.{tenantId}`). Le **CSR** est un fichier de demande généré dans The Wallet Crew qu'Apple utilise pour créer votre certificat. Le **certificat de signature** est ce qui signe cryptographiquement chaque Carte. Le **clé d'authentification APNs** est ce qui nous permet de déclencher des mises à jour pour les Carte déjà installées sur les appareils.

Suivez ces étapes pour configurer votre programme d’adhésion Apple pour The Wallet Crew.

{% stepper %}
{% step %}
**Connectez-vous et ouvrez Identifiants**

1. Connectez-vous à la console du programme développeur Apple :

<p align="center"><a href="https://developer.apple.com/account" class="button secondary" data-icon="chevrons-right">Console du programme développeur Apple</a></p>

2. Allez dans Certificates, IDs & Profiles > Identifiers
   {% endstep %}

{% step %}
**Créez un ID de type Carte**

1. Cliquez sur le bouton + et sélectionnez les IDs de type Carte, puis cliquez sur Continuer.
2. Remplissez le formulaire. Définissez la description sur `carte d’adhésion`. Définissez l’identifiant sur la valeur affichée dans The Wallet Crew sous `identifiant de type de Carte`.

   <p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/apple/edit" class="button secondary" data-icon="chevrons-right">L’équipe Wallet</a></p>

La valeur doit suivre le modèle `Carte.com.thewalletcrew.{tenantId}` où `{tenantId}` est votre identifiant de marque.

{% hint style="danger" %}
Considérez l’identifiant de type de Carte comme permanent. Une fois que vous avez émis des Cartes, le modifier casse généralement les mises à jour et peut imposer une réémission complète.
{% endhint %}

Copiez cette valeur exacte et collez-la dans le champ d’identifiant du Portail des développeurs Apple.

<div data-with-frame="true"><figure><img src="/files/f4dcb3b8b95d87b1dd6e43aefcbb9df34f5c411e" alt="The Wallet Crew console showing the Pass Type Identifier value to copy into Apple Developer Portal"><figcaption><p>La console The Wallet Crew affichant la valeur de l’identifiant de type de Carte à copier dans le Portail des développeurs Apple</p></figcaption></figure></div>

{% hint style="warning" %}
Si vous devez modifier cet identifiant pour une raison quelconque, cliquez sur l’icône de verrouillage à côté du champ dans la console The Wallet Crew et coordonnez la modification avec votre point de contact chez The Wallet Crew afin d’assurer une synchronisation correcte. Ne le faites jamais sans l’accord de votre point de contact chez The Wallet Crew.
{% endhint %}

Cliquez **Continuer** pour examiner vos paramètres, puis cliquez **Enregistrer** pour créer l'ID de type de Carte.
{% endstep %}

{% step %}
**Accédez aux détails de l'ID de type de Carte**

Après avoir enregistré votre ID de type de Carte, vous reviendrez à la liste des identifiants. Repérez et cliquez sur l'ID de type de Carte que vous venez de créer pour ouvrir sa page de détails.

<div data-with-frame="true"><figure><img src="/files/b50c01173144cd8ee719c332ee8e75c8323fe0da" alt="Apple Developer Portal identifiers list showing the created Pass Type ID"><figcaption><p>Liste des identifiants du portail Apple Developer montrant l'ID de type de Carte créé</p></figcaption></figure></div>

Sur la page de détails de l'ID de type de Carte, cliquez sur le **Créer un certificat** bouton. Cela ouvrira le flux de création de certificat d'Apple

<div align="center" data-with-frame="true"><img src="/files/3f816645a185c6038af1269ca936f85da637931f" alt="détails de l&#x27;ID de type Carte du portail développeur Apple affichant le bouton Créer un certificat"></div>

Laissez cet onglet de navigateur ouvert et basculez vers l'onglet de la console d'administration The Wallet Crew. Si vous ne l'avez pas ouvert, accédez à The Wallet Crew Apple Configuration.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/apple/edit" class="button secondary" data-icon="chevrons-right">La configuration Apple de The Wallet Crew</a></p>
{% endstep %}

{% step %}
**Générer une demande de signature de certificat (CSR)**

Dans la console The Wallet Crew, repérez le **Demande de signature de certificat (CSR)** section et cliquez sur **Générer CSR**. Le système créera un fichier de demande de signature cryptographique. Une fois la génération terminée, cliquez sur **Télécharger le CSR** pour enregistrer le fichier sur votre ordinateur. Le nom du fichier sera similaire à `Carte.cloud.thewalletcrew.{yourbrand}.csr`.

<div><figure><img src="/files/7e341328c5cf308e9abce62e851990b3cfc3c92b" alt="The Wallet Crew Apple configuration showing the Generate CSR action"><figcaption><p>La configuration Apple de Wallet Crew montrant l'action Générer le CSR</p></figcaption></figure> <figure><img src="/files/48cf3668a723cbb4b5fbba21f3630812874c7a3d" alt="The Wallet Crew Apple configuration showing the Download CSR action"><figcaption><p>La configuration Apple de Wallet Crew montrant l'action Télécharger le CSR</p></figcaption></figure></div>
{% endstep %}

{% step %}
**Téléverser le CSR vers Apple et télécharger le certificat**

Retournez à l’onglet du navigateur du portail Apple Developer où le formulaire de création du certificat est en attente. Laissez le **Nom du certificat** champ vide, donc Apple le génère automatiquement, puis téléversez le `.csr` fichier que vous avez téléchargé depuis The Wallet Crew.

Cliquez **Continuer** pour traiter le CSR. Apple générera votre certificat de signature en utilisant les informations cryptographiques du CSR de Wallet Crew.

<div><figure><img src="/files/1f5e0d481ebbfd25790157b4bc490570a55127ed" alt="Apple Developer Portal certificate creation form showing CSR upload"><figcaption><p>Formulaire de création de certificat du portail Apple Developer affichant l’importation du CSR</p></figcaption></figure> <figure><img src="/files/a4bd9a17893e101523f9dacaf67b687d7b3fda44" alt="Apple Developer Portal certificate download screen for the generated pass certificate"><figcaption><p>Écran de téléchargement du certificat du portail Apple Developer pour le certificat Carte généré</p></figcaption></figure></div>

Sur la page de confirmation, cliquez **Télécharger** pour enregistrer le fichier de certificat (nommé `Carte.cer`) vers votre ordinateur. Ce fichier de certificat est l'identifiant cryptographique qui signera tous les passes Wallet émis par votre organisation.
{% endstep %}

{% step %}
**Téléchargez le certificat à l'équipe Wallet**

Revenez à la page de configuration Apple de Wallet Crew. Repérez la **Téléversement du certificat** section.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/apple/edit" class="button secondary" data-icon="chevrons-right">La page de configuration Apple de Wallet Crew</a></p>

Cliquez **Choisir un fichier** et sélectionnez le `Carte.cer` fichier de certificat que vous avez téléchargé depuis Apple. Le système Wallet Crew vérifiera que le certificat correspond à votre CSR et qu'il est correctement configuré.

Vérifiez les informations du certificat affichées (date d’expiration, détails de l’émetteur) et cliquez sur **Appliquer le certificat** pour terminer le téléversement. Le certificat est désormais actif et sera utilisé pour signer tous les pass Wallet que vous créez.

<div data-with-frame="true"><figure><img src="/files/996128dafb0d0a3f749e768747f2a39d8b8dc23c" alt="The Wallet Crew Apple configuration showing certificate upload and Apply Certificate"><figcaption><p>La configuration Apple de Wallet Crew montrant le téléversement du certificat et Appliquer le certificat</p></figcaption></figure></div>
{% endstep %}

{% step %}
**Créer une clé d’authentification APNs dans Apple**

Le service de notifications Push Apple (APNs) permet des mises à jour en temps réel des cartes Wallet après leur installation sur les appareils des utilisateurs. Lorsque vous mettez à jour le solde d’une carte, modifiez les détails d’un événement ou tout contenu de carte, APNs notifie l’appareil de l’utilisateur afin de télécharger la dernière version.

Accédez à la page des clés Apple Developer et cliquez sur le **bouton +** pour créer une nouvelle clé.

<p align="center"><a href="https://developer.apple.com/account/resources/authkeys/list" class="button secondary" data-icon="chevrons-right">page des clés Apple Developer</a></p>

Complétez le formulaire d’enregistrement de la clé : nommez la clé (par exemple « Wallet Push Notifications »), activez **le service de notifications Push Apple (APNs)**, puis cliquez sur **Configurer** à côté d'APNs pour choisir l'environnement.

Dans la boîte de dialogue de configuration APNs, sélectionnez **Production** environnement (pas Sandbox). L'environnement de production est requis pour que les cartes Wallet reçoivent des mises à jour en utilisation réelle. Cliquez **Enregistrer** pour confirmer ce paramètre.

<div data-with-frame="true"><figure><img src="/files/6e19d0a6f5f5f4e365754b6729d7d34754314125" alt="Apple Developer Portal key registration form with APNs enabled"><figcaption><p>Formulaire d'enregistrement de clé du portail Apple Developer avec APNs activé</p></figcaption></figure></div>

Cliquez **Continuer** pour vérifier la configuration de votre clé, puis cliquez sur **Enregistrer** pour créer la clé. Apple affichera votre ID de clé ; c'est une information critique dont vous aurez besoin à l'étape suivante, alors copiez-la dans un endroit sûr.

Cliquez **Télécharger** pour enregistrer votre fichier de clé d'authentification (nommé `AuthKey_XXXXXXXXXX.p8`).

**Important :** Apple ne vous permet de télécharger ce fichier qu'une seule fois. Si vous le perdez, vous devrez révoquer cette clé et en créer une nouvelle. Conservez le fichier téléchargé `.p8` en lieu sûr — traitez-le comme un mot de passe.
{% endstep %}

{% step %}
**Téléverser la clé APNs vers The Wallet Crew**

Accédez à la page de configuration APNs de The Wallet Crew.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/apple/editApn" class="button secondary" data-icon="chevrons-right">Page de configuration APNs de The Wallet Crew</a></p>

Remplissez le formulaire de configuration APNs : collez la **ID de clé** que vous avez copiée depuis Apple (10 caractères) et téléversez le `AuthKey_XXXXXXXXXX.p8` fichier que vous avez téléchargé.

Cliquez **Enregistrer** ou **Appliquer** pour téléverser les identifiants APNs. La plateforme The Wallet Crew validera la clé et configurera les notifications push pour votre locataire.

<div data-with-frame="true"><figure><img src="/files/6d19eedc1f3446a16cffd00bcc4cd371f54fea6d" alt="The Wallet Crew APNs configuration showing Key ID and .p8 file upload"><figcaption><p>Configuration APNs de The Wallet Crew montrant l'ID de clé et le téléversement du fichier .p8</p></figcaption></figure></div>

**Configuration terminée :** Votre intégration Apple Wallet est maintenant entièrement configurée. Vous pouvez créer des cartes Wallet, et elles seront signées avec votre certificat et capables de recevoir des mises à jour en temps réel via APNs.
{% endstep %}
{% endstepper %}

## Renouvellement du certificat

Les certificats Apple Wallet expirent chaque année et doivent être renouvelés pour continuer à émettre des cartes. Apple enverra des e-mails de rappel avant l'expiration, mais vous devriez renouveler proactivement les certificats au moins deux semaines avant la date d'expiration afin d'éviter toute interruption de service.

{% hint style="info" %}
**Calendrier :** Le renouvellement du certificat prend environ 15 minutes. Les cartes existantes continuent de fonctionner pendant le renouvellement, sans temps d'arrêt.
{% endhint %}

{% stepper %}
{% step %}
**Lancer le renouvellement du certificat dans Apple**

Accédez au compte Apple Developer et connectez-vous. Sélectionnez **Certificats, ID et profils** dans la navigation de gauche, puis cliquez sur **Certificats**.

<p align="center"><a href="https://developer.apple.com/account" class="button secondary" data-icon="chevrons-right">Compte Apple Developer</a></p>

Cliquez sur le **bouton +** pour créer un nouveau certificat. Sélectionnez **Certificat d'ID de type de Carte** dans la liste des types de certificats, puis cliquez sur **Continuer**.
{% endstep %}

{% step %}
**Générer le CSR dans The Wallet Crew**

1. Ouvrez la console d'administration The Wallet Crew et cliquez sur **Générer CSR**. Même si vous disposez d'un fichier CSR précédent, vous devez en générer un nouveau pour le renouvellement.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/apple/edit" class="button secondary" data-icon="chevrons-right">Console d'administration The Wallet Crew - configuration Apple</a></p>

2. Cliquez **Générer CSR** pour créer une nouvelle demande de signature de certificat. Une fois la génération terminée, cliquez sur **Télécharger le CSR** pour enregistrer le fichier. Le nom de fichier sera similaire à `Carte.cloud.thewalletcrew.{yourbrand}.csr`.

<div><figure><img src="/files/7e341328c5cf308e9abce62e851990b3cfc3c92b" alt="The Wallet Crew Apple configuration showing Generate CSR for renewal"><figcaption><p>Configuration Apple de The Wallet Crew montrant Générer le CSR pour le renouvellement</p></figcaption></figure> <figure><img src="/files/48cf3668a723cbb4b5fbba21f3630812874c7a3d" alt="The Wallet Crew Apple configuration showing Download CSR for renewal"><figcaption><p>Configuration Apple de The Wallet Crew montrant Télécharger le CSR pour le renouvellement</p></figcaption></figure></div>
{% endstep %}

{% step %}
**Téléchargez le CSR sur Apple et téléchargez le certificat renouvelé**

Retournez au portail Apple Developer. Dans le flux de création de certificat, téléchargez le nouveau fichier CSR que vous venez de télécharger depuis The Wallet Crew.

Cliquez **Continuer** pour générer le certificat renouvelé, puis cliquez sur **Télécharger** pour enregistrer le nouveau `Carte.cer` fichier.

<div><img src="/files/1f5e0d481ebbfd25790157b4bc490570a55127ed" alt="Formulaire de création de certificat du portail Apple Developer montrant le téléversement du CSR (renouvellement)"> <img src="/files/d338f0c5cdbf3a940b1ddccec84ce6ea014881e4" alt="Écran de confirmation du portail Apple Developer pour le certificat de carte renouvelé"> <figure><img src="/files/a4bd9a17893e101523f9dacaf67b687d7b3fda44" alt="Apple Developer Portal download screen for the renewed pass certificate"><figcaption><p>Écran de téléchargement du portail Apple Developer pour le certificat de carte renouvelé</p></figcaption></figure></div>
{% endstep %}

{% step %}
**Téléchargez le certificat renouvelé sur The Wallet Crew**

Accédez à la page de configuration Apple de The Wallet Crew. Téléchargez le certificat renouvelé `Carte.cer` fichier de certificat.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/apple/edit" class="button secondary" data-icon="chevrons-right">La configuration Apple de The Wallet Crew</a></p>

Vérifiez la nouvelle date d’expiration pour confirmer qu’elle a été prolongée d’une année supplémentaire, puis cliquez sur **Appliquer le certificat**.

**Renouvellement terminé :** Votre certificat est renouvelé pour une année supplémentaire. Toutes les cartes existantes continuent de fonctionner sans interruption, et les nouvelles cartes seront signées avec le certificat renouvelé.

<div data-with-frame="true"><figure><img src="/files/996128dafb0d0a3f749e768747f2a39d8b8dc23c" alt="The Wallet Crew Apple configuration showing upload of the renewed certificate and Apply Certificate"><figcaption><p>Configuration Apple de The Wallet Crew montrant le téléchargement du certificat renouvelé et Appliquer le certificat</p></figcaption></figure></div>
{% endstep %}
{% endstepper %}

## Résoudre les problèmes de renouvellement de certificat

### Plusieurs certificats dans Apple Developer

Deux certificats pour le même ID de type de Carte sont attendus lors du renouvellement. Le certificat existant reste actif pendant qu’Apple ajoute le certificat renouvelé.

The Wallet Crew utilise automatiquement le certificat actif le plus récent. L’ancien certificat expire naturellement et ne nécessite pas de révocation.

Ne révoquez pas l’ancien certificat tant qu’il reste valide. La révocation peut brièvement interrompre l’émission de cartes avant que le certificat renouvelé ne soit propagé.

Après l’expiration de l’ancien certificat, il peut être supprimé dans Apple Developer. Sa suppression n’affecte pas la plateforme The Wallet Crew.

### Le téléchargement du CSR affiche un ancien fichier

Pendant le renouvellement, l’écran de téléchargement du CSR dans la console d’administration peut afficher une liste déroulante de fichiers antérieurs. Cela se produit lorsque la session du navigateur met en cache les fichiers précédemment sélectionnés.

Sélectionnez **Télécharger un nouveau fichier** ou **Parcourir** à côté de la liste déroulante. Le lien peut paraître visuellement atténué, mais il accepte toujours un nouveau fichier CSR.

Si le lien n’est pas disponible, ouvrez la page dans une fenêtre privée ou de navigation incognito. Cela démarre une nouvelle session de navigateur. Si le problème persiste, contactez l’assistance The Wallet Crew avec une capture d’écran. L’équipe peut télécharger directement le certificat renouvelé sur le tenant.

### Le renouvellement n’affecte pas la production

{% hint style="warning" %}
Le renouvellement d’un certificat dans l’environnement de préproduction ne met pas à jour la production. Téléchargez le certificat renouvelé séparément dans le tenant de production.
{% endhint %}

## FAQ

<details>

<summary><strong>Qu’est-ce qu’un ID de type de Carte et pourquoi en ai-je besoin ?</strong></summary>

Un ID de type de Carte est votre identifiant d’émetteur dans l’écosystème Apple (par exemple `Carte.com.thewalletcrew.{tenantId}`). Il indique à Apple et aux appareils iOS quelle organisation est autorisée à émettre et à signer des cartes, c’est pourquoi il est requis pour tout déploiement Apple Wallet. La plupart des marques utilisent un ID de type de Carte pour tous leurs types de cartes.

</details>

<details>

<summary><strong>Quelle est la différence entre un CSR, un certificat et une clé APNs ?</strong></summary>

Le CSR est un fichier de demande généré dans The Wallet Crew que vous téléchargez sur Apple. Apple l’utilise pour générer votre certificat de signature, qui est l’identifiant utilisé pour signer chaque carte. La clé APNs est distincte. Elle permet à The Wallet Crew de s’authentifier auprès du service Apple Push Notification afin de déclencher des mises à jour pour les cartes déjà installées sur les appareils.

</details>

<details>

<summary><strong>Pourquoi ai-je besoin d’un certificat (.cer) et d’une clé APNs (.p8) ?</strong></summary>

Apple Wallet divise la « confiance » en deux éléments. Le `.cer` certificat signe vos cartes afin que les appareils puissent vérifier que la carte est authentique et n’a pas été altérée. La `.p8` clé APNs authentifie le canal push, afin qu’Apple accepte les notifications de mise à jour pour vos cartes et que les appareils sachent qu’ils doivent s’actualiser.

</details>

<details>

<summary><strong>Combien de temps prend l’inscription à l’Apple Developer Program ?</strong></summary>

Pour les organisations, Apple approuve généralement l’inscription sous 2 à 5 jours ouvrés. Apple demande parfois une vérification supplémentaire concernant le numéro D‑U‑N‑S ou l’identité de l’entreprise. Le numéro D‑U‑N‑S est généralement envoyé par e-mail avec l’objet `Votre numéro D-U-N-S est inclus.` de `Apple Developer <developer@email.apple.com>`. Une fois l’approbation obtenue, la configuration du certificat Wallet prend généralement environ 1 à 2 heures.

</details>

<details>

<summary><strong>Puis-je utiliser un compte Apple Developer individuel au lieu d’un compte d’organisation ?</strong></summary>

Techniquement, oui, mais c’est rarement une bonne idée. Les comptes individuels affichent un nom personnel sur les cartes et ne prennent pas en charge les mêmes flux de travail d’équipe. La plupart des entreprises devraient s’inscrire en tant qu’organisation (même prix de 99 $/an).

</details>

<details>

<summary><strong>Que se passe-t-il si mon certificat expire ?</strong></summary>

Si le certificat expire, l’émission et la mise à jour des cartes peuvent échouer. Les cartes déjà installées peuvent toujours s’afficher, mais elles ne recevront pas les mises à jour de manière fiable. Renouvelez au moins deux semaines avant l’expiration ; Apple envoie généralement des rappels environ 30 jours avant.

</details>

<details>

<summary><strong>Dois-je renouveler la clé d’authentification APNs ?</strong></summary>

Non. Les clés APNs n’expirent pas, vous ne les renouvelez donc pas. Normalement, vous ne renouvelez que le certificat d’ID de type de Carte chaque année. Si vous révoquez la clé APNs dans le portail Apple, vous devez en créer une nouvelle et la télécharger sur The Wallet Crew.

</details>

<details>

<summary><strong>Puis-je révoquer l’accès délégué après la configuration initiale ?</strong></summary>

Oui. Une fois que tout est configuré, vous pouvez supprimer l’utilisateur administrateur délégué d’App Store Connect et l’intégration continuera de fonctionner. La délégation n’est nécessaire que pour la configuration initiale et elle est facultative pour les renouvellements.

</details>

<details>

<summary><strong>Que faire si je ne trouve pas mon identifiant de type de Carte dans la console The Wallet Crew ?</strong></summary>

Vous le trouverez sur la page de configuration Apple sous **Identifiant de type de Carte**. S’il est vide ou génère une erreur, contactez votre interlocuteur chez The Wallet Crew. Votre tenant peut nécessiter une petite étape de configuration avant que la configuration Apple ne soit disponible.

</details>

<details>

<summary><strong>Pourquoi dois-je utiliser l’environnement APNs « production » et non « sandbox » ?</strong></summary>

Apple Wallet utilise l’environnement APNs de production, même pour les tests. Sandbox est destiné au développement d’applications iOS, pas aux cartes. Si vous configurez sandbox par erreur, les mises à jour push ne fonctionneront pas de manière fiable.

</details>

<details>

<summary><strong>Comment savoir si ma configuration fonctionne correctement ?</strong></summary>

Créez une carte de test dans The Wallet Crew et ajoutez-la à un iPhone. Si elle s’installe et affiche le nom de votre organisation, la signature fonctionne. Modifiez ensuite un champ simple (comme un solde ou un texte) et vérifiez que la carte installée s’actualise en quelques secondes.

</details>

<details>

<summary><strong>Que dois-je faire du fichier de clé APNs .p8 après le téléchargement ?</strong></summary>

Conservez le `.p8` fichier comme un mot de passe, idéalement dans un gestionnaire de mots de passe ou un stockage sécurisé de documents. Vous pourriez en avoir besoin plus tard pour des audits, une reconfiguration ou si Apple vous demande de vérifier votre configuration APNs. Ne l’ajoutez pas au contrôle de version et ne l’envoyez pas par e-mail non chiffré.

</details>

<details>

<summary><strong>Puis-je utiliser le même compte Apple Developer pour plusieurs marques ?</strong></summary>

Oui, mais chaque marque doit utiliser son propre ID de type de Carte. Un compte Apple Developer peut héberger plusieurs ID de type de Carte, chacun avec son propre certificat. Dans The Wallet Crew, chaque tenant correspond à sa propre configuration Apple.

</details>

<details>

<summary><strong>Nous avons déjà des cartes existantes. Comment migrer vers The Wallet Crew ?</strong></summary>

Il s’agit d’une **migration** de cartes actives, et non d’un « renouvellement » normal.

Pour Apple, la contrainte principale est l’identité de l’émetteur. En pratique, vous conservez le **même ID de type de Carte**, exportez les données techniques des cartes existantes (comme le numéro de série + le jeton d’authentification), puis redirigez les mises à jour vers The Wallet Crew.

Suivez le guide dédié : [Migrer les cartes vers The Wallet Crew](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/move-passes-to-the-wallet-crew).

Si vous quittez The Wallet Crew, utilisez : [Exporter les cartes de The Wallet Crew vers un autre fournisseur](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider).

</details>


# Compte Google Wallet

Configurez l'accès à Google Pay & Wallet Console et les identifiants de l'API Google Wallet afin que The Wallet Crew puisse émettre des cartes sous votre marque.

Configurez votre intégration Google Wallet en utilisant soit un accès délégué (recommandé pour une configuration plus rapide), soit une configuration gérée par vous-même. Ce guide couvre la création du compte, l'activation des API et la gestion des identifiants pour déployer des Cartes de portefeuille numérique via la plateforme The Wallet Crew.

## Aperçu

Pour distribuer des cartes numériques via Google Wallet, votre organisation doit faire approuver un compte émetteur dans Google Pay & Wallet Console et configurer un projet Google Cloud pour l'accès à l'API. Google approuve les émetteurs manuellement, donc prévoyez **3 à 5 jours ouvrés** pour l'approbation, plus **15 à 60 minutes** pour la configuration technique.

**Principaux éléments à configurer**

* Un compte émetteur dans Google Pay & Wallet Console (approbation requise)
* Un projet Google Cloud avec accès à l'API Google Wallet

Vous créerez les services Google principaux sous votre marque (projet Google Cloud + approbation Google Pay & Wallet Console). Ensuite, vous déléguerez soit la configuration restante à The Wallet Crew, soit vous la complèterez vous-même et collerez les valeurs requises dans The Wallet Crew.

Vous voulez le « pourquoi » avant le « comment » ? Commencez par [Wallet Apple et Google](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet).

#### Prérequis

* Compte Google Workspace ou Gmail avec privilèges d'administrateur
* Informations sur l'entreprise pour la vérification du marchand Google Pay
* Autorisation de créer des comptes de service dans Google Cloud

## Configuration du projet Google Cloud

Accédez à la Console Google Cloud et connectez-vous avec le compte Google de votre entreprise.

<p align="center"><a href="https://console.cloud.google.com/iam-admin/" class="button secondary" data-icon="chevrons-right">Console Google Cloud</a></p>

Créez un nouveau projet en utilisant la convention de nommage `thewalletcrew-<brandName>` où `<brandName>` correspond à l'identifiant de votre organisation ou de votre marque. Par exemple : `thewalletcrew-acmecorp` ou `thewalletcrew-retailstore`. Cette convention de nommage aide à identifier d'un coup d'œil l'objectif du projet.

### Délégation de compte

Cette approche permet à l'équipe The Wallet Crew de gérer la configuration technique tandis que vous conservez la propriété de tous les comptes et identifiants. Vous accorderez un accès temporaire, et nous configurerons tout selon les bonnes pratiques.

Dans la section IAM & Admin, sélectionnez **IAM** dans le menu de navigation de gauche. Cliquez sur le **Accorder l'accès** bouton et ajoutez `contact@neostore.cloud` en tant que propriétaire du projet. Ce niveau d'autorisation permet à l'équipe The Wallet Crew de créer des comptes de service, d'activer les API et de configurer toutes les ressources nécessaires. Vous pouvez révoquer cet accès une fois la configuration initiale terminée.

<div data-with-frame="true"><figure><img src="/files/5cf0d0dd2e1e984bd02d15ebd60af72b68fa26d5" alt="Google Cloud IAM page showing the Grant access action" width="375"><figcaption><p>Google Cloud IAM : accorder l'accès au projet</p></figcaption></figure></div>

Ainsi, les Cartes Google Wallet sont émises sous l'identité de votre organisation, et non celle de The Wallet Crew. Le projet que vous créez ici établit cette identité organisationnelle dans les systèmes de Google.

### Configuration par vous-même

Vous gérez l'ensemble de la configuration dans vos propres comptes Google Cloud et Google Pay.

Pour accéder à la Google Pay & Wallet Console, vous devez [vous inscrire](https://support.google.com/pay/merchants/contact/instore_merchants). Après avoir soumis le formulaire, l'équipe d'assistance vous contactera pour valider votre cas d'utilisation et activer votre compte émetteur.

{% stepper %}
{% step %}
**Créer un compte de service**

1. Accédez à la page des identifiants.

<p align="center"><a href="https://console.developers.google.com/apis/credentials" class="button secondary" data-icon="chevrons-right">Google Cloud - page des identifiants</a></p>

2. Vérifiez que le projet actuel est `thewalletcrew-<brandName>`
3. Cliquez sur **Créer des identifiants → Compte de service**.

<div data-with-frame="true"><figure><img src="/files/e134e872d14eacaddbe1f318dcbc36f10d564669" alt="Google Cloud: Create credentials → Service account" width="375"><figcaption><p>Créer un nouveau compte de service</p></figcaption></figure></div>

4. Remplissez le formulaire :

* Nom du compte de service : `TheWalletCrew`
* ID du compte de service : conservez la valeur générée automatiquement

<figure><img src="/files/5b6a1c7b109519068c59ed1804d6ecdd64095882" alt="Google Cloud service account details form (name and ID)" width="375"><figcaption><p>Nom et ID du compte de service</p></figcaption></figure>

5. Cliquez sur **Terminé** pour terminer la création du compte de service.

Notez l'adresse e-mail générée pour le compte de service. Exemple : `thewalletcrew@thewalletcrew-123456.iam.gserviceaccount.com`. Vous en aurez besoin plus tard dans la Google Pay & Wallet Console.
{% endstep %}

{% step %}
**Créer et télécharger une clé JSON**

1. Ouvrez le compte de service que vous venez de créer. Puis accédez à l'onglet **Clés** onglet.

<div><figure><img src="/files/2e773c1526398050f11476fafba66a8d1cf030e5" alt="Google Cloud service account: Keys tab"><figcaption><p>Ouvrez l'onglet Clés</p></figcaption></figure> <figure><img src="/files/d73e445b2e033bf4068391932e84fa1c818b95f5" alt="Google Cloud service account keys page showing the Add key action"><figcaption><p>Créez une nouvelle clé</p></figcaption></figure></div>

2. Cliquez sur **Ajouter une clé → Créer une nouvelle clé**.

<div data-with-frame="true"><figure><img src="/files/32cc81d12884929dbc9d7263d7eb4b6925f72906" alt="Google Cloud: Add key → Create new key" width="375"><figcaption><p>Commencez à créer une clé JSON</p></figcaption></figure></div>

3. Choisissez **JSON** et cliquez sur **Créer**.

<figure><img src="/files/a86d3474a5f7f37183112ea67b03d9a8b649c32e" alt="Google Cloud: select JSON as the key type" width="375"><figcaption><p>Sélectionnez le type de clé JSON</p></figcaption></figure>

4. Enregistrez le fichier généré dans un emplacement sécurisé. Vous le téléverserez plus tard dans la console d'administration The Wallet Crew.

{% hint style="warning" %}
Traitez ce fichier JSON comme un mot de passe.
{% endhint %}
{% endstep %}

{% step %}
**Activer l'API Google Wallet**

Rendez-vous sur la page de l'API Google Wallet et activez l'accès à l'API.

<p align="center"><a href="https://console.cloud.google.com/apis/library/walletobjects.googleapis.com" class="button secondary" data-icon="chevrons-right">API Google Wallet</a></p>

<div data-with-frame="true"><figure><img src="/files/f278a83abfb85e136db3f477e1fdf6a671a2ce11" alt="Google Cloud API Library: enable Google Wallet API (walletobjects.googleapis.com)" width="375"><figcaption><p>Activer <code>walletobjects.googleapis.com</code></p></figcaption></figure></div>
{% endstep %}
{% endstepper %}

## Configuration de Google Pay & Wallet Console

Accédez à la Google Pay & Wallet Console et connectez-vous avec le compte Google de votre entreprise.

<p align="center"><a href="https://pay.google.com/gp/m/issuer/list" class="button secondary" data-icon="chevrons-right">Google Pay &#x26; Wallet Console</a></p>

### Délégation de compte

Accédez à la section Utilisateurs. Ajoutez `contact@neostore.cloud` avec **Administrateur** autorisation. Cela permet à l'équipe The Wallet Crew de configurer les paramètres de votre émetteur et de terminer l'intégration.

<div data-with-frame="true"><figure><img src="/files/86e46b79f7f217d15d8d15c6b1385dd7edfd7ad7" alt="Google Pay &#x26; Wallet Console Users page showing user access management" width="375"><figcaption><p>Ajoutez un utilisateur avec <strong>Administrateur</strong> accès</p></figcaption></figure></div>

L'équipe The Wallet Crew recevra une notification de votre autorisation d'accès et procédera à la création du compte de service, à l'activation de l'API et à la configuration des identifiants. Nous vous informerons lorsque la configuration sera terminée et vous fournirons vos identifiants pour les conserver en lieu sûr.

### Configuration par vous-même

{% stepper %}
{% step %}
**Invitez le compte de service**

1. Accédez à la section Utilisateurs.

<div data-with-frame="true"><figure><img src="/files/f21e3fb30db7fcdb04628ef0445c87dbe5ffe02a" alt="Google Pay &#x26; Wallet Console navigation highlighting Users" width="375"><figcaption><p>Ouvrez la section Utilisateurs</p></figcaption></figure></div>

2. Cliquez sur **Inviter un utilisateur**.

Remplissez le formulaire avec les informations suivantes :

* Adresse e-mail : celle notée à l'étape 1.4
* Niveau d'accès : **Développeur**

<div><figure><img src="/files/85d9bb4dd0b973c6cdf1bb76229f9189d93e639b" alt="Google Pay &#x26; Wallet Console: Invite a user dialog"><figcaption><p>Invitez l'adresse e-mail du compte de service</p></figcaption></figure> <figure><img src="/files/95fbbc6caabdf6db3c4eb389f8200412a12cb476" alt="Google Pay &#x26; Wallet Console: select Developer access level"><figcaption><p>Choisissez le <strong>Développeur</strong> rôle</p></figcaption></figure></div>

Puis cliquez sur **Inviter**.

<div data-with-frame="true"><figure><img src="/files/caf47a06a82414f803667b26e71e8833c6b2ebb3" alt="Google Pay &#x26; Wallet Console: Invite button to send the user invitation" width="375"><figcaption><p>Envoyez l'invitation</p></figcaption></figure></div>
{% endstep %}

{% step %}
**Compléter les informations de l'établissement**

1. Cliquez sur **Détails de l'établissement** et vérifiez que toutes les informations sont renseignées et approuvées.

<div data-with-frame="true"><figure><img src="/files/ee5c4bdbc6b630cfce3d74a699308287dd663694" alt="Google Pay &#x26; Wallet Console: establishment details page" width="375"><figcaption><p>Confirmez que les détails de l'établissement sont approuvés</p></figcaption></figure></div>

2. Cliquez sur **API Google Wallet**.

<figure><img src="/files/fb9d470060364d4b4c6002a803b1eb915b49c946" alt="Google Pay &#x26; Wallet Console: Google Wallet API page showing the issuerId value" width="375"><figcaption><p>Copiez le <code>issuerId</code></p></figcaption></figure>

Notez le `issuerId`. Vous en aurez besoin dans la console d'administration The Wallet Crew.
{% endstep %}
{% endstepper %}

## Configurez The Wallet Crew

Si vous configurez vous-même, retournez dans la console d'administration The Wallet Crew et ouvrez Wallet > Configuration > Google.

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passTypes/configuration/google" class="button secondary" data-icon="wallet">Wallet > Configuration > Google</a></p>

Remplissez le formulaire avec :

* la clé JSON du compte de service que vous avez téléchargée précédemment
* le `issuerId` provenant de la Google Pay & Wallet Console

<figure><img src="/files/b14ca5fa5b3a0f2dcf25cd7ceb30b3a554f7ed3a" alt="The Wallet Crew admin console: Google Wallet configuration form for issuerId and service account JSON key"><figcaption><p>Collez <code>issuerId</code> et téléversez la clé JSON</p></figcaption></figure>

#### Demander un accès public (uniquement si nécessaire)

Si, après un test avec une Carte Google, vous obtenez l'erreur suivante :

<div data-with-frame="true"><figure><img src="/files/6c9b9a3ccfc83183ca32690991881c38e8ed3b64" alt="Google Wallet error message asking to request public access" width="297"><figcaption><p>Erreur lorsque l'accès public est requis</p></figcaption></figure></div>

Revenez à l'API Google Wallet :

<div data-with-frame="true"><figure><img src="/files/e0da35739f99380ba2d24b8f19d59cc0e2900f10" alt="Google Cloud: Google Wallet API console for requesting public access" width="375"><figcaption><p>Demander un accès public à Google</p></figcaption></figure></div>

Ensuite, demandez un accès public. Vous pouvez utiliser l'un de ces modèles.

<details>

<summary><strong>Modèle d'e-mail — utilisation d'une carte de fidélité</strong></summary>

> Bonjour,
>
> Nous aimerions utiliser l'API Google Wallet pour générer des cartes de fidélité en magasin. Le client peut scanner un code QR (exemple : xxxx), puis créer ou retrouver son compte et ajouter une carte de fidélité à son Wallet.
>
> Nous travaillons avec The Wallet Crew pour cela.
>
> Cordialement,

</details>

<details>

<summary><strong>Modèle d'e-mail — utilisation pour un événement</strong></summary>

> Bonjour,
>
> Nous aimerions utiliser l'API Google Wallet pour générer des billets d'événement. Le client recevra un e-mail avec un lien de téléchargement et ajoutera ses billets à son Wallet. Nous afficherons également un bouton « Ajouter à Wallet » sur notre site Web après l'achat des billets.
>
> Nous travaillons avec The Wallet Crew pour cela.
>
> Cordialement,

</details>

## FAQ

<details>

<summary><strong>Combien de temps prend l'approbation de Google ?</strong></summary>

Google approuve manuellement l'accès des émetteurs. Prévoyez **3 à 5 jours ouvrés** pour l'approbation. Puis prévoyez **15 à 60 minutes** pour la configuration technique (compte de service, activation de l'API et configuration de l'émetteur).

</details>

<details>

<summary><strong>Que devons-nous configurer dans la console d'administration The Wallet Crew ?</strong></summary>

Vous avez besoin de deux éléments : une **clé JSON du compte de service** provenant de Google Cloud (compte de service → **Clés**) et votre **`issuerId`** provenant de la **Google Pay & Wallet Console** (section API Google Wallet). Une fois que vous les avez collés/téléversés dans Wallet > Configuration > Google, The Wallet Crew peut s'authentifier et émettre des Cartes sous votre émetteur.

</details>

<details>

<summary><strong>Avons-nous besoin d'un projet Google Cloud dédié ?</strong></summary>

Oui. Un projet dédié isole la configuration de Wallet des autres charges de travail cloud. Il facilite aussi grandement la revue des accès, la facturation et l'audit.

</details>

<details>

<summary><strong>À quoi sert le « compte de service » ?</strong></summary>

Le compte de service est l'identité machine utilisée pour appeler les API Google Wallet de serveur à serveur. Ce n'est pas un utilisateur humain. The Wallet Crew utilise la clé JSON du compte de service pour authentifier ces appels d'API.

</details>

<details>

<summary><strong>Comment devons-nous stocker la clé JSON du compte de service ?</strong></summary>

Traitez la clé JSON comme un mot de passe. Téléversez-la à The Wallet Crew via la console d'administration, puis stockez-la uniquement dans votre gestionnaire de secrets (ou supprimez-la si vous n'avez pas besoin d'en conserver une copie). Évitez de la partager par chat ou par e-mail, et faites-la pivoter immédiatement si elle a été exposée.

</details>

<details>

<summary><strong>Pourquoi devons-nous inviter un utilisateur/compte de service dans Google Pay &#x26; Wallet Console ?</strong></summary>

Google Pay & Wallet Console contrôle qui peut gérer votre émetteur. Si le compte de service n'est pas invité, les appels à l'API Google Wallet échoueront même si le projet Cloud est correctement configuré. Dans une configuration autonome, invitez le **compte de service** en tant qu'utilisateur avec le **Développeur** rôle.

</details>

<details>

<summary><strong>Que fait réellement « Activer l'API Google Wallet » ?</strong></summary>

Cela active le point de terminaison de l'API Google Wallet (`walletobjects.googleapis.com`) dans votre projet Cloud. Sans cela, les requêtes échoueront avec des erreurs d'autorisation telles que « API not enabled ».

</details>

<details>

<summary><strong>Nous obtenons une erreur demandant un « accès public ». Qu'est-ce que cela signifie ?</strong></summary>

Certains émetteurs ont besoin d'une étape d'approbation supplémentaire de Google avant de pouvoir distribuer des Cartes à grande échelle. Cela apparaît souvent lorsque vous passez des tests à une distribution en conditions réelles. Utilisez les modèles d'e-mail de ce guide pour demander un accès public à Google.

</details>

<details>

<summary><strong>Pouvons-nous révoquer l'accès délégué après la mise en production ?</strong></summary>

**Oui**. Une fois que vous avez validé que l'émission et les mises à jour de Cartes fonctionnent de bout en bout, révoquez l'accès délégué aux deux endroits : supprimez The Wallet Crew de votre **Google Cloud** projet IAM, et supprimez l'utilisateur de la **Google Pay & Wallet Console** liste Utilisateurs. Faites-le uniquement après avoir effectué de véritables enregistrements et au moins une mise à jour réussie, afin de ne pas casser la production par inadvertance.

</details>

<details>

<summary><strong>Faut-il renouveler la configuration chaque année ?</strong></summary>

Généralement **non**. Cette configuration n'est pas quelque chose que l'on « renouvelle » selon un calendrier.

Ne refaites la configuration dans The Wallet Crew que si quelque chose a changé du côté de Google, par exemple :

* Vous **avez fait pivoter ou remplacé** la clé JSON du compte de service.
* La clé a été **révoquée/désactivée**, ou vous pensez qu'elle a été exposée.
* Vous êtes passé à un **projet Cloud différent** ou **issuerId**.
* les autorisations IAM / Console ont été modifiées et l'émission a cessé de fonctionner.

Si rien n'a changé et que les Cartes s'émettent/se mettent toujours à jour correctement, laissez tel quel.

</details>

<details>

<summary><strong>Nous avons déjà des Cartes existantes. Comment migrer vers The Wallet Crew ?</strong></summary>

Il s'agit d'une **migration** de Cartes en production, et non d'une simple « reconfiguration ».

Chez Google, vos Cartes sont liées à un **compte émetteur Google Pay & Wallet Console**. Vous ne pouvez pas transférer des Cartes en production vers un autre émetteur. Prévoyez de conserver le même émetteur et de déplacer la configuration opérationnelle (identifiants + données des Cartes) vers The Wallet Crew.

Suivez le guide dédié : [Déplacer les Cartes vers The Wallet Crew](broken://pages/6b85ec1ec6de65ecc22ab84f9c3c48ae4fb30780).

</details>


# Configuration du modèle


# Comment créer un modèle

Personnalisez l'apparence et la mise en page de votre carte Wallet : couleurs, logos/images, disposition des champs, informations supplémentaires et liens pour Apple Wallet et Google Wallet.

## Aperçu

Créer un modèle de Carte est simple et rapide. Pour ce faire, rendez-vous dans la section Modèle sous l’onglet Wallet et cliquez sur « Créer un nouveau modèle »

<figure><img src="/files/613e83bad7e515c9c67fd516a72667fe5ffb7469" alt="How to create a template"><figcaption></figcaption></figure>

Vous aurez plusieurs possibilités pour créer votre modèle.

<figure><img src="/files/9241fba93e5c710b09505fcf398327b6306b3003" alt="How to create a template (2)"><figcaption></figcaption></figure>

### Dupliquer un modèle

Si vous cliquez sur « dupliquer », vous pourrez créer un nouveau modèle basé sur un modèle existant. Sa configuration sera récupérée, seul le nom sera différent. Vous pourrez ensuite modifier votre nouveau modèle.

Tout d’abord, choisissez dans la liste le modèle existant que vous souhaitez dupliquer, puis cliquez sur « ok ».

<figure><img src="/files/78953f43362f36964f8f933d9981faf410ad6182" alt="Duplicate a template"><figcaption></figcaption></figure>

Choisissez un nouveau nom pour créer un nouveau modèle basé sur celui que vous avez sélectionné dans la liste, puis cliquez sur « confirmer le modèle ».

<figure><img src="/files/fc03e559906d5597150b44914b38dc46a41fcacc" alt="Duplicate a template (2)"><figcaption></figcaption></figure>

{% hint style="warning" %}
**Si vous décidez de conserver le même nom, vous écraserez le modèle existant que vous avez sélectionné et les Cartes liées seront mises à jour lors de leur prochaine mise à jour. Si c’est ce que vous souhaitez faire, cliquez sur « Je confirme l’écrasement ».**
{% endhint %}

<figure><img src="/files/98a5848e9081d28f3e2c99f48fe6c8c1fc4acaec" alt="If you decide to keep the same name you will overwrite the existing template you selected and linked passes will update on their next update. If this is what you want to do, click on I confirm overwrite."><figcaption></figcaption></figure>

### Importer un fichier de modèle

Vous pouvez également créer un nouveau modèle en important la configuration d’un modèle existant. Par exemple, si vous avez travaillé sur un modèle dans votre environnement de préproduction et devez le placer dans votre environnement de production, vous pouvez exporter la configuration de votre modèle en préproduction pour l’importer en production. **⚠️ Cela ne fonctionne qu’avec un fichier de modèle provenant de The Wallet Crew.**

Vous devez d’abord sélectionner le modèle que vous souhaitez exporter, cliquer sur les trois points à droite du modèle, puis exporter la configuration. Vous verrez qu’un fichier pttwc a été téléchargé.

<figure><img src="/files/964e9ba6c6830a3f1a6c240f35d713bd3a9a2e4f" alt="Import a template file"><figcaption></figcaption></figure>

Revenez à la création d’un modèle en cliquant sur « Créer un nouveau modèle » et choisissez « Importer ».

<figure><img src="/files/0b24e4d24faeffff58fb61f888cf9a7d1a398128" alt="Import a template file (2)"><figcaption></figcaption></figure>

Cliquez sur « Téléverser (template.pttwc) » et sélectionnez le fichier pttwc que vous venez de télécharger.

<figure><img src="/files/7aecf4b756f5d8ea9864f2e860ebcb2c277a6bfe" alt="Import a template file (3)"><figcaption></figcaption></figure>

Choisissez un nouveau nom pour créer un nouveau modèle basé sur le fichier que vous avez importé, puis cliquez sur « confirmer le modèle ».

<figure><img src="/files/9129229c90b2094db5a86ef138ae4017f0371892" alt="Import a template file (4)"><figcaption></figcaption></figure>

**⚠️ Si vous décidez de choisir un nom de modèle déjà présent dans votre liste de modèles, vous écraserez le modèle déjà existant et les Cartes liées seront mises à jour lors de leur prochaine mise à jour. Si c’est ce que vous souhaitez faire, cliquez sur « Je confirme l’écrasement ».**

<figure><img src="/files/6b1068c6a34e759df249461ee79f2373eed4c63c" alt="⚠️ If you decide to choose a template name already existing on your template list, you will overwrite the template already existing and linked passes will update on their next update. If this is what you want to do, click on I confirm overwrite."><figcaption></figcaption></figure>

### Utiliser un modèle prédéfini

The Wallet Crew a créé et centralisé une bibliothèque de modèles que vous pouvez utiliser pour créer vos nouveaux modèles en fonction de votre cas d’usage. Si vous utilisez l’un des modèles prédéfinis, votre nouveau modèle aura la même configuration que le modèle prédéfini (couleurs, images, champs) et vous pourrez conserver la configuration ou modifier certains éléments. Pour accéder à cette bibliothèque, après avoir cliqué sur « Créer un nouveau modèle », sélectionnez « Utiliser un modèle prédéfini ».

<figure><img src="/files/e215512492e3b6ea53e2d61dafc9a0356de8ab4d" alt="Use a pre-built template"><figcaption></figcaption></figure>

Vous avez le choix entre des modèles de carte client, billet d’événement, générique, cartes cadeaux et offres. Utilisez [Type de Carte](https://docs.thewalletcrew.io/guides-design/fr/) pour choisir le point de départ adapté à votre cas d’usage.

Avant de sélectionner le modèle prédéfini que vous souhaitez utiliser, vous pouvez voir à quoi ressemblent les versions Apple et Google.

<figure><img src="/files/7349d635adbfd03534c7e1d721ab4f2ac6d0844f" alt="Use a pre-built template (2)"><figcaption></figcaption></figure>

Une fois votre choix fait, sélectionnez votre modèle prédéfini en cliquant sur « Utiliser ce modèle ».

<figure><img src="/files/3cee9dfc7cb95d5ba20fdfde13d2ca5808492ea5" alt="Use a pre-built template (3)"><figcaption></figcaption></figure>

Choisissez un nouveau nom pour créer un nouveau modèle basé sur le modèle prédéfini, puis cliquez sur « confirmer le modèle ».

<figure><img src="/files/00920ccccd8b756378ea67491c7abc6d9053a369" alt="Use a pre-built template (4)"><figcaption></figcaption></figure>

**⚠️ Si vous décidez de choisir un nom de modèle déjà présent dans votre liste de modèles, vous écraserez le modèle déjà existant et les Cartes liées seront mises à jour lors de leur prochaine mise à jour. Si c’est ce que vous souhaitez faire, cliquez sur « Je confirme l’écrasement ».**

<figure><img src="/files/6b1068c6a34e759df249461ee79f2373eed4c63c" alt="⚠️ If you decide to choose a template name already existing on your template list, you will overwrite the template already existing and linked passes will update on their next update. If this is what you want to do, click on I confirm overwrite. (2)"><figcaption></figcaption></figure>

### Commencer avec l’IA

The Wallet Crew vous offre la possibilité d’utiliser un concepteur de modèles IA pour trouver de l’inspiration et des idées avant de créer votre nouveau modèle. Voici quelques points à savoir avant d’utiliser cet outil :

* Cet outil est en version bêta, ce qui signifie qu’il est tout nouveau et peut contenir des erreurs
* Vous avez besoin d’un compte Google pour accéder à cette fonctionnalité
* Le modèle que vous créez dans le concepteur de modèles ne peut pas être exporté et importé dans The Wallet Crew
* Le concepteur de modèles est pour l’instant uniquement en français

Si vous souhaitez l’utiliser, une fois que vous avez cliqué sur « Créer un nouveau modèle », sélectionnez « Commencer avec l’IA ».

<figure><img src="/files/0f988068403fa931672d0855fc65da6c8de5e9a2" alt="Start with AI"><figcaption></figcaption></figure>

### Et ensuite ?

Votre nouveau modèle est maintenant créé ! Pour le modifier, retrouvez votre modèle récemment créé dans la liste des modèles. Pour accéder à la version Apple, cliquez sur le logo correspondant.

Depuis cette interface, vous pourrez personnaliser la carte de fidélité selon vos besoins :

* Logo et couleurs de votre entreprise
* Nom du client
* Champs principaux et secondaires
* Informations des champs au verso
* Code-barres pour l’identification en caisse
* Bande

**Et bien plus encore.**

<figure><img src="/files/eb10c6e8bd17f430ceeca79d4161da3a01c94b21" alt="And much more."><figcaption></figcaption></figure>

Pour personnaliser la version Android, il suffit de basculer en cliquant sur « Google ». Vous pourrez, tout comme avec la version Apple, personnaliser les champs et le design de votre modèle de Carte selon vos envies.

<figure><img src="/files/764a6033ed8027ef93e5750e83dc1568f90ec1d5" alt="What&#x27;s next"><figcaption></figcaption></figure>

Pour en savoir plus sur la configuration d’un modèle, commencez par [Type de Carte](https://docs.thewalletcrew.io/guides-design/fr/).


# Conception des cartes (couleurs, images et champs)

Personnalisez l'apparence et la mise en page de votre carte Wallet : couleurs, logos/images, disposition des champs, informations supplémentaires et liens pour Apple Wallet et Google Wallet.

## Conception de carte

Créez une carte pour vos clients afin de simplifier leur expérience en magasin et de l’harmoniser avec l’identité de votre marque.

### **Conception graphique**

Dans la section « Conception graphique », vous pouvez personnaliser les images sur la carte et sa couleur, ce qui permet à la carte de se rapprocher au maximum de la charte graphique de l'entreprise.

#### **Couleur de la carte**

Pour ajuster la couleur de la carte :

1. Appuyez sur la case du code couleur et sélectionnez la couleur souhaitée pour l'arrière-plan de la carte ;

![Couleur de la carte](/files/061cbaae98d0a0fee8ef00514f3b1cc1ed6c271f)

2. Si nécessaire, modifiez les couleurs de l'en-tête et du texte sur la carte en déplaçant les curseurs vers la droite et en suivant les mêmes étapes pour la sélection des couleurs (uniquement pour les cartes dans Apple Wallet) ;

![Couleur de la carte (2)](/files/caa61f253fded574a46a0ff64e97168a429af728)

3. Vérifiez la couleur sur les cartes situées à droite de l'interface.

![Couleur de la carte (3)](/files/f3761b3f957a33f69af35b410f3ca6cd13697c21)

❗ Veuillez noter : si vous avez une couleur de marque d'entreprise, saisissez son code dans la zone à côté de la case colorée. Cela vous aidera à obtenir la couleur exacte. Veuillez noter que la couleur de la carte peut être uniquement une couleur unie.

![Couleur de la carte (4)](/files/a2265960e04308208cd9bc32ba175ebd7a20d4a2)

#### **Images sur la carte**

Deux images peuvent être placées sur la carte en même temps : le logo de l'entreprise et l'image centrale.

![Images sur la carte](/files/4836702991ea5087db154358ad7bb8d0375e0e69)

**Carte Apple Wallet**

1. Téléversez votre logo dans la section appropriée. Le format de fichier recommandé est PNG (avec fond transparent), 480 x 150 px ;2.

Téléversez votre image centrale dans la section appropriée. Format PNG recommandé, 1125 x 432 px.

**Carte Google Wallet**

1. Téléversez votre logo dans la section appropriée. De préférence au format PNG (avec la même couleur de fond que la couleur de la carte), taille minimale 820 x 820 px ;2. Téléversez l'image centrale dans la section appropriée. Format PNG recommandé, 1032 x 336 px.

❗ Veuillez noter : vous pouvez agrandir et déplacer les zones d'image à l'aide de la souris pour les sélectionner plus précisément.

#### **Disposition des champs**

Dans la section « Disposition des champs », vous pouvez sélectionner les informations qui seront affichées sur la carte de vos clients. Pour ajouter des champs à la carte : 1. Sélectionnez des champs dans la liste déroulante ; 2. Vérifiez la disposition des champs sur les cartes situées à droite de l'interface ; 3. Cliquez sur Enregistrer.

Les champs sur la carte afficheront les informations provenant des variables que vous avez créées et présenteront les informations pertinentes pour le client. Les informations à l'intérieur des champs sont mises à jour automatiquement.

#### **Informations supplémentaires**

Dans la section « Informations supplémentaires », vous pouvez ajouter toutes les informations nécessaires pour le client, telles que :

* Promotions et actualités de l'entreprise ;
* Conditions générales du programme de fidélité ;
* Contacts de l'entreprise ;
* Historique d'achats ;
* Autres informations qu'il est important pour vous d'afficher.

![Informations supplémentaires](/files/5b4ae2738dafebe24cc7da0431f58a5bac0b24b1)

Pour ajouter un nouveau champ d'information, cliquez sur le bouton « + Ajouter un champ » et saisissez son nom et sa description dans les champs qui apparaissent. Pour que le champ affiche des informations mises à jour, ajoutez une variable. Vous pouvez modifier les champs, changer leur emplacement et les supprimer en cliquant sur le bouton « Masquer ».

#### **Liens**

Dans la section « Liens », vous pouvez laisser des liens qui permettront à vos clients de communiquer avec vous et d'accéder aux sites web en un clic.

Par exemple :

* Site web de l'entreprise ;
* Suivi de commande ;
* Rendez-vous en ligne ;
* Informations sur les magasins
* Autres liens importants à partager.

![Liens](/files/6f4e01c7a7dccfc40582f4e7e4e775de698884e7)


# Comment traduire un modèle

## **Importance des cartes multilingues**

Dans les univers du commerce de détail ou de l'événementiel, il est crucial de proposer des cartes dans différentes langues afin de répondre à une clientèle de plus en plus internationale. Proposer une Carte multilingue permet aussi d'éviter toute mauvaise interprétation, ce qui est particulièrement essentiel lors d'événements.

### **Étapes pour gérer les traductions d'un modèle de Carte**

Allez dans « Paramètres », puis dans « Général ».

![Étapes pour gérer les traductions d'un modèle de Carte](/files/7af35c3922e692c88603a9cdf26f9f1c3889ce08)

Dans la section d'internationalisation, vous avez la possibilité d'ajouter les langues de votre choix. Par exemple, pour ajouter l'espagnol, saisissez simplement le code ISO de la langue, qui est « es ». Cliquez ensuite sur la petite croix pour confirmer avant d'enregistrer.

**Vous pouvez trouver le code ISO d'une langue** [**juste ici**](https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes)**{target="\_blank"}.**

![Vous pouvez trouver le code ISO d'une langue](/files/be651af0ead42e2458778aa05690113e993e8446)

Vous pouvez ajouter autant de langues que vous le souhaitez.

![Étapes pour gérer les traductions d'un modèle de Carte (2)](/files/fe1a376bf6432f7cdccb502d111c6d249401a4ae)

Pour définir une langue par défaut, cliquez simplement sur la langue choisie. N'oubliez pas de cliquer sur « enregistrer » en haut de l'écran.

![Étapes pour gérer les traductions d'un modèle de Carte (3)](/files/537cdf5cc228afd669f5a3f93cf7ea3d91df0552)

Maintenant, dans le menu des modèles, sélectionnez votre modèle. Vous trouverez les langues nouvellement ajoutées. Cliquez sur l'une d'elles pour prévisualiser la carte.

![Maintenant, dans le menu des modèles, sélectionnez votre modèle. Vous trouverez les langues nouvellement ajoutées. Cliquez sur o](/files/99b0e789b8304f82a329f96851ba3136eaca6a90)

Pour traduire un champ, cliquez sur cette petite icône :

![Pour traduire un champ, cliquez sur cette petite icône](/files/22515f742581674665fa577793278b93e38af6c7)

Vous aurez la possibilité de traduire en fonction des langues.

![Vous aurez la possibilité de traduire en fonction des langues](/files/6de8b5ab4a8ddb12cfd9a8ea4ddf87d745581d09)

⚠️ **Vous ne pouvez traduire qu'un champ qui comporte l'icône de traduction.**

### **Étapes pour la traduction en masse**

Si vous avez plusieurs langues et que vous ne voulez pas perdre de temps à traduire les champs un par un dans l'éditeur de modèle, vous pouvez les modifier en masse ! Pour cela, vous devez aller dans la section « Locales », dans le menu « Outils ».

![Étapes pour la traduction en masse](/files/3bafbf4b5becf3bb9f15c0e13a5a953e9a01ce35)

Choisissez le modèle de Carte que vous souhaitez traduire, cliquez sur les trois points à droite, puis sur « modifier en masse ».

![Étapes pour la traduction en masse (2)](/files/64502dcfdc7ca09129b088fb0222df15bec72f69)

Depuis cette interface, vous pouvez traduire tous les champs.

![Étapes pour la traduction en masse (3)](/files/f7a8b12bd7561e2007759447932df30c4f28e1fa)

Les champs surlignés en orange indiquent qu'ils n'ont pas encore été traduits. Il suffit de traduire les champs dans la langue correspondante avant d'enregistrer.

![Étapes pour la traduction en masse (4)](/files/9bb40bfcdc2a5dc577e4a2571bc714d86ebd486e)

Vous pouvez exporter le fichier au format Excel pour une manipulation plus facile.

![Étapes pour la traduction en masse (5)](/files/e7914090362e71310fb9ba855a3444e2d1356103)

Une fois la modification de votre fichier Excel terminée, vous pouvez l'importer sur The Wallet Crew.

![Une fois la modification de votre fichier Excel terminée, vous pouvez l'importer sur The Wallet Crew](/files/a205cd3a26995dfe47229010b5d78f1a393768eb)


# Sécurité des cartes Wallet

Sécurité des cartes Apple Wallet et Google Wallet chez The Wallet Crew (WaaS) : RGPD/CCPA, résidence des données dans l'UE, chiffrement, isolement des locataires et liens « Add to Wallet » signés.

## Sécurité des cartes Apple Wallet et Google Wallet

The Wallet Crew est une plateforme Wallet as a Service (WaaS) en marque blanche. Nous aidons les marques à émettre des cartes sécurisées **cartes de portefeuille mobile** et **cartes de portefeuille**. Ces cartes fonctionnent dans **Apple Wallet** et **Google Wallet**.

Les cas d’usage courants incluent les cartes de fidélité, les cartes-cadeaux, les coupons et les billets.

Cette page couvre la sécurité de bout en bout des cartes Wallet :

* confidentialité et conformité (GDPR, CCPA)
* hébergement dans l’UE et résidence des données
* chiffrement en transit et au repos
* authentification des API, limitation du débit et protection contre les abus
* distribution sécurisée des cartes (e-mail, web, QR, NFC)
* flux de mise à jour d’Apple Wallet et Google Wallet

## Conformité et protection des données (GDPR, CCPA)

La sécurité et la confidentialité sont intégrées à la plateforme. The Wallet Crew s’aligne sur les exigences du GDPR et du CCPA.

Les données personnelles identifiables (PII) ne sont pas stockées par défaut. Lorsque le traitement des PII est nécessaire, il est piloté par votre configuration et votre cas d’usage.

Notre infrastructure fonctionne sur Microsoft Azure en Europe. Cela prend en charge les exigences de résidence des données dans l’UE pour de nombreuses organisations.

#### Références

* Nous maintenons un Plan d’assurance sécurité (SIP) documenté. Il couvre les contrôles de sécurité et la gestion des risques. Lisez-le ici : [Plan d’assurance sécurité (SIP)](/policies/fr/privacy-and-security/security-insurance-plan).
* Nous fournissons également un modèle d’Accord de traitement des données (DPA). Il définit les responsabilités en matière de conformité. Lisez-le ici : [modèle d’Accord de traitement des données](/policies/fr/privacy-and-security/data-processing-agreement-model).
* Pour des détails pratiques sur la confidentialité, voir : [FAQ sur la protection des données](/policies/fr/privacy-and-security/data-protection-faq).
* Pour la collecte du consentement et les preuves, voir : [Consentements et conformité GDPR](/configure/fr/advanced-configuration/wallet/wallet-card-security).

## Architecture de sécurité

The Wallet Crew est une plateforme multi-locataire avec une isolation stricte des locataires. Les données et les opérations sont séparées entre les marques. La limitation du débit par locataire réduit les abus et les risques de voisinage bruyant.

L’authentification des API prend en charge **OAuth 2.0** et **les clés API**. L’accès back-office utilise **Auth0** pour la gestion des identités et des accès.

Les services internes s’exécutent dans un **Azure Virtual Network**dédié. Ce réseau n’est pas accessible publiquement. Le trafic public est acheminé via **Cloudflare**. Cloudflare fournit un CDN, **WAF**, une protection DDoS et une limitation du débit.

Nous prenons en charge **les domaines personnalisés** pour la distribution des cartes. Les marques peuvent utiliser un sous-domaine sur leur propre domaine. Les certificats TLS sont gérés par défaut via Cloudflare. Les marques peuvent également apporter leur propre certificat et leur configuration DNS.

Toutes les communications utilisent TLS 1.2 ou TLS 1.3. Les données au repos sont stockées dans Azure Cosmos DB et chiffrées par Azure. Les données analytiques sont stockées dans Azure Data Explorer et chiffrées par Azure. Voir [Insights API](https://docs.thewalletcrew.io/api-reference/) pour les modèles d’accès aux usages et aux analyses.

Le trafic de service à service au sein du réseau virtuel est également chiffré avec TLS.

Pour les détails d’hébergement, voir [Infrastructure](/developers-guides/fr/pass-architecture/infrastructure).

## Sécurité de la distribution des cartes Wallet (liens, e-mail, QR, NFC)

The Wallet Crew prend en charge la distribution sécurisée des cartes aux utilisateurs finaux. Tous les canaux imposent HTTPS et utilisent des paramètres signés. Cela empêche la falsification, le rejeu et l’accès non autorisé.

Chaque carte de notre système est associée à deux types d’identifiants :

* **Identifiant interne**: Un UUID opaque et non séquentiel généré par The Wallet Crew. Il est unique et impossible à deviner. Il est sûr pour une récupération directe.
* **Identifiant externe**: Fourni par vos systèmes. Les exemples incluent les numéros de fidélité, les numéros de billets et les identifiants de cartes-cadeaux. Ces valeurs sont souvent séquentielles ou prévisibles. Les identifiants prévisibles doivent être protégés pour empêcher les attaques d’énumération (IDOR).

Pour sécuriser la récupération basée sur des identifiants externes, nous prenons en charge plusieurs mécanismes. Ils sont conçus pour empêcher les attaques d’énumération et de rejeu.

* Signature HMAC-SHA256\
  Calculez un HMAC avec SHA-256 et un secret partagé spécifique au locataire. Votre système signe l’identifiant externe. The Wallet Crew vérifie la signature avant d’autoriser l’accès.
* Jeton de secret partagé\
  Générez un jeton à l’aide d’un secret partagé avec The Wallet Crew. Envoyez le jeton avec l’identifiant. Notre API le valide avant de renvoyer toute donnée de carte.
* JWT (JSON Web Token)\
  Utilisez un JWT signé qui inclut l’identifiant externe comme revendication. Signez avec HMAC ou avec une paire de clés asymétriques (RSA/ECDSA). The Wallet Crew valide la signature, l’expiration et les revendications.

Ces contrôles s’appliquent à la récupération via API et aux liens de distribution. Cela inclut les e-mails, les codes QR et les tags NFC. Les identifiants dans les URL ne servent à rien sans un jeton valide.

Les cartes peuvent être distribuées par e-mail à l’aide de liens sécurisés « Add to Wallet ». Les flux d’e-mail s’intègrent aux principaux outils d’automatisation marketing. Voir [Via e-mail](/guides-enrolment/fr/inscription/via-email) et [Intégrations](https://www.thewalletcrew.com/en/integrations).

Pour la distribution web, nous fournissons un SDK pour un bouton « Add to Wallet ». Le SDK sécurise le flux du navigateur vers la plateforme. Voir [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website).

Nous fournissons également des formulaires d’inscription sécurisés. Ils peuvent ajouter des étapes de vérification avant l’accès à la carte. Voir [Conception du formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form).

Vous pouvez également intégrer des liens sécurisés dans des points de contact physiques. Utilisez des codes QR sur des flyers ou des tags NFC sur des cartes en plastique. Ces liens sont signés et peuvent être à usage unique ou limités dans le temps. Nous proposons également une application web qui affiche des codes QR temporaires. Contactez le support pour choisir la configuration adaptée à votre cas d’usage.

## Flux de données du portefeuille mobile et confidentialité

The Wallet Crew est conçu pour minimiser le stockage des données personnelles identifiables (PII). Les PII ne sont pas conservées par défaut.

Pour des raisons de performance, certains connecteurs peuvent utiliser un cache temporaire facultatif. La durée de cache habituelle est inférieure à 15 minutes. Les données du cache peuvent être supprimées via l’API The Wallet Crew. Les demandes de suppression de données peuvent également être traitées par notre équipe de support.

Notre architecture garantit que les opérations sensibles s’effectuent dans des périmètres sécurisés.

![Schéma des flux de données](/files/885df7b79620aecf84eb4f0a9539c59896946528)

## Flux de communication d’Apple Wallet et Google Wallet

La communication avec les fournisseurs de cartes diffère entre Apple et Google.

* Apple Wallet\
  Les cartes sont installées sur l’appareil de l’utilisateur. Elles ne sont pas stockées par défaut sur les serveurs Apple. Les mises à jour sont déclenchées via le service Apple Push Notification (APNs). APNs indique à l’appareil de récupérer la carte mise à jour de manière asynchrone. Les cartes peuvent se synchroniser via iCloud, mais nous n’avons pas accès au contenu d’iCloud.

  ![Flux Apple Wallet](/files/83af660e0bb2e2296b34a31c816aeaea136e224e)
* Google Wallet\
  Les cartes sont stockées dans le compte Google de l’utilisateur. Les mises à jour sont gérées via l’API Google Wallet à l’aide d’identifiants OAuth. La livraison sur l’appareil et l’actualisation sont gérées par Google.

  ![Flux Google Wallet](/files/8282c57574d3ee7ba056e2d5dae52af504bf86d2)

## Sécurité des API (authentification, limitation du débit, journaux d’audit)

Nos API sont protégées par une limitation du débit par locataire. Des contrôles supplémentaires atténuent le bruteforce et les abus de jetons.

Les journaux d’audit sont disponibles sur demande pour la conformité et l’analyse médico-légale. Les signaux d’utilisation de la plateforme sont disponibles via la[ Insights API](/developers-guides/fr/integration-guides/insights-api).

## Surveillance et réponse aux incidents

Nous utilisons Azure Application Insights pour la surveillance et la détection d’anomalies. Les alertes sont automatisées et réglées pour détecter des schémas suspects.

Nous maintenons un processus de réponse aux incidents et un plan de reprise d’activité.

## Atténuation des risques

Nous imposons HTTPS et des URL signées sur tous les canaux de distribution. Les codes QR et les tags NFC peuvent être configurés comme temporaires ou à usage unique. L’isolation des locataires et la limitation du débit réduisent encore les abus et les accès non autorisés.

## FAQ rapide sur la sécurité

<details>

<summary>The Wallet Crew stocke-t-elle des données personnelles (PII) ?</summary>

Par défaut, non. The Wallet Crew est conçu pour que les PII ne soient pas conservées. Certains connecteurs peuvent utiliser un cache facultatif de courte durée.

</details>

<details>

<summary>Les cartes Apple Wallet sont-elles stockées sur les serveurs Apple ?</summary>

Les cartes Apple Wallet sont installées sur l’appareil de l’utilisateur. Les mises à jour sont déclenchées via APNs. The Wallet Crew ne peut pas accéder au contenu des cartes stockées dans iCloud.

</details>

<details>

<summary>Comment les liens « Add to Wallet » sont-ils sécurisés ?</summary>

Tous les liens de distribution utilisent HTTPS. Les liens sont signés et validés côté serveur. Nous prenons en charge HMAC-SHA256, les jetons à secret partagé et JWT. Cela empêche la falsification et l’énumération des cartes.

</details>

<details>

<summary>Comment The Wallet Crew empêche-t-il les abus sur vos API ?</summary>

Nous utilisons une limitation du débit par locataire et des protections supplémentaires contre les abus. Nous surveillons les anomalies et maintenons un processus de réponse aux incidents. Des journaux d’audit peuvent être fournis sur demande.

</details>


# Importation et exportation

## Importez vos Cartes dans The Wallet Crew

The Wallet Crew propose un puissant outil d’importation qui vous permet d’importer en masse ou de mettre à jour des Cartes à l’aide de fichiers XLSX. Ce guide vous accompagnera tout au long du processus et expliquera les points importants à prendre en compte.

### Aperçu

L’outil d’importation prend en charge :

* Création en masse de nouvelles Cartes
* Mise à jour des Cartes existantes
* Gestion de différents types de Carte
* Gestion des identifiants de Carte et des données supplémentaires
* Suivi de la progression et rapports d’erreurs

### Avant de commencer

1. **Format du fichier**: Préparez votre fichier XLSX en tenant compte des éléments suivants :
   * Les noms de colonnes doivent être clairs et ne pas contenir de caractères spéciaux
   * Les données doivent être correctement formatées selon les types attendus
   * Le fichier doit contenir toutes les informations nécessaires sur les Cartes
2. **Colonnes requises**:
   * `id` (facultatif) : s’il est présent, il est utilisé pour identifier les Cartes existantes
   * `passType` (facultatif) : le type de Carte. Si aucun n’est spécifié, vous devrez sélectionner un type par défaut
   * Les autres colonnes seront traitées comme des données supplémentaires
3. **Validation des données**:
   * Les adresses e-mail doivent être correctement formatées
   * Les numéros de téléphone doivent suivre les formats standard
   * Les dates doivent être dans un format cohérent

### Processus d’importation

#### Étape 1 : accéder à l’outil d’importation

1. Accédez à la section **Cartes** dans votre compte Wallet Crew
2. Cliquez sur le **Importer des Cartes** bouton
3. Sélectionnez votre fichier XLSX\
   ![Passes List](/files/ba4ef1f44845c30a8a84c8fad3f214644cc545e1)

#### Étape 2 : configurer les paramètres d’importation

La fenêtre modale d’importation vous montrera deux paramètres importants :

1. **Colonne discriminante**:
   * Si votre fichier contient une `id` colonne, elle sera sélectionnée automatiquement
   * Sinon, choisissez une colonne qui identifie de manière unique chaque Carte
   * Cette colonne sera utilisée pour déterminer si une Carte doit être créée ou mise à jour
2. **Type de Carte par défaut**:
   * Sélectionnez le type de Carte par défaut pour les Cartes qui n’en spécifient pas
   * Ceci est requis si votre fichier n’inclut pas de `passType` colonne

#### Étape 3 : vérifier et importer

1. Vérifiez le nombre total de Cartes à importer
2. Vérifiez que les paramètres de la colonne discriminante et du type de Carte sont corrects
3. Cliquez sur **Importer** pour lancer le processus\
   ![Import Modal](/files/9d6919bb895a9d3ef1ff0883912873db7e60929c)

#### Étape 4 : surveiller la progression

Pendant l’importation :

* Une barre de progression affiche l’état actuel
* Vous pouvez voir le nombre de Cartes créées et mises à jour
* Toutes les erreurs sont affichées en temps réel
* Vous pouvez annuler l’importation à tout moment\
  ![Import Progress](/files/8e844e1bae2c2fa5d86623d5e0ccc905a91f4079)

### Remarques importantes

1. **Traitement par lot**:
   * Les Cartes sont importées par lots de 16 pour des performances optimales
   * Le processus continue même si certaines Cartes échouent à l’importation
2. **Gestion des erreurs**:
   * Les formats de données invalides sont signalés
   * Les champs obligatoires manquants sont mis en évidence
   * Vous pouvez examiner les erreurs et apporter des corrections
3. **Annulation**:
   * Vous pouvez annuler l’importation à tout moment
   * La fenêtre du navigateur doit rester ouverte pendant le processus
4. **Traitement des données**:
   * Les valeurs vides sont converties en `null`
   * Les colonnes spéciales (id, secret, creationDate, etc.) sont exclues des données supplémentaires
   * Les champs de métadonnées sont traités séparément

### Après l’importation

1. La page se rafraîchira automatiquement pour afficher les Cartes mises à jour une fois que vous aurez fermé la fenêtre modale
2. Vous pouvez consulter le rapport d’importation indiquant :
   * Nombre de Cartes créées
   * Nombre de Cartes mises à jour
   * Toutes les erreurs survenues

### Bonnes pratiques

1. **Préparation des données**:
   * Nettoyez vos données avant l’importation
   * Utilisez un formatage cohérent
   * Validez les adresses e-mail et les numéros de téléphone
2. **Structure du fichier**:
   * Gardez des noms de colonnes simples et clairs
   * Utilisez des formats de date standard
   * Incluez tous les champs obligatoires
3. **Imports volumineux**:
   * Pour les fichiers volumineux, envisagez de les diviser en lots plus petits
   * Surveillez la progression et vérifiez les erreurs
   * Laissez la fenêtre du navigateur ouverte pendant l’importation

### Dépannage

Si vous rencontrez des problèmes :

1. Consultez le rapport d’erreurs pour identifier les problèmes spécifiques
2. Vérifiez le format de votre fichier et vos données
3. Assurez-vous que tous les champs obligatoires sont présents
4. Essayez d’importer un lot plus petit pour tester


# Mettre à jour la Carte à l'aide de fichiers plats

The Wallet Crew peut mettre à jour des cartes Apple Wallet et Google Wallet existantes à partir d’un fichier CSV. C’est utile pour les mises à jour en masse et pour les systèmes hérités qui ne peuvent exporter que des fichiers plats.

{% hint style="warning" %}
Les imports SFTP sont une fonctionnalité optionnelle. Demandez à The Wallet Crew d’activer SFTP sur votre tenant avant de mettre en œuvre ce flux.

Considérez les imports SFTP comme une **solution de dernier recours**. Évitez ce flux sauf si vous n’avez aucune autre option (par exemple, un système hérité qui ne peut exporter que des fichiers plats).

Pour la plupart des projets, l’API est l’approche recommandée. Elle est plus facile à automatiser, plus facile à surveiller et se met à jour en temps réel.

Si vous préférez une intégration en temps réel, utilisez plutôt le flux de mise à jour via l’API. Voir [Broken mention](broken://pages/7bc855a760c8626e5d57afe837e12d5a1e71c84a).
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un programme de cartes-cadeaux recalcule le solde toutes les heures. Une exportation de fichier plat met à jour `additionalData.balance` pour toutes les cartes actives.
* Une équipe d’automatisation marketing exporte un CSV pour préparer une campagne push. Chaque ligne met à jour `additionalData.notification_content` avant l’envoi des notifications.
* Un système de billetterie exporte les changements de dernière minute (porte, siège ou horaire). Une mise à jour CSV en masse maintient les billets exacts juste avant l’ouverture des portes.
* Une chaîne de salles de sport exporte chaque nuit le statut d’adhésion (actif, gelé, expiré). Le lendemain, les membres voient le bon statut à l’enregistrement.
* Une équipe support corrige un identifiant erroné à grande échelle en téléversant un fichier de correction ponctuel.

</details>

<div data-with-frame="true"><figure><img src="/files/88c3844c568c58695f616d831d9ef53e3a8c7997" alt="Diagram showing a CSV file uploaded to SFTP, then processed by The Wallet Crew to update passes."><figcaption><p>Les imports de fichiers plats vous permettent de mettre à jour de nombreuses cartes en une seule opération.</p></figcaption></figure></div>

## Vue d’ensemble du processus

1. Téléversez votre fichier CSV sur le serveur SFTP fourni.
2. The Wallet Crew détecte automatiquement les nouveaux fichiers et les traite immédiatement.
3. Une fois traité, le fichier est déplacé vers `.processed/` ou `.error/`.
4. Chaque ligne est interprétée comme une instruction de mise à jour pour une seule carte.
5. Les cartes sont mises en file d’attente pour mise à jour et traitées de manière asynchrone.

## Format de fichier

Les fichiers téléversés doivent être valides [RFC 4180](https://www.ietf.org/rfc/rfc4180.txt){target="\_blank"} fichiers CSV conformes.

* **Séparateurs**: soit `,` ou `;`
* **Ligne d’en-tête**: Obligatoire. Doit contenir les noms de colonnes.
* **Encodage**: UTF-8 recommandé
* **Analyseur**: The Wallet Crew utilise [CsvHelper](https://joshclose.github.io/CsvHelper/){target="\_blank"} avec les options par défaut

Chaque ligne de données cible une seule carte et peut inclure plusieurs mises à jour de ses champs, de additionalData ou des métadonnées.

## Nom de fichier

Il n’existe aucune exigence stricte pour le nom du fichier. Cependant, pour une meilleure organisation et traçabilité, nous recommandons la convention de nommage suivante :

```
<source>-cartes-<YYYYMMDD>-<HHMMSS>.csv
```

Exemples :

```
crm-cartes-20250801-083000.csv 
loyalty-cartes-20250731-235959.csv
```

Remarques :

* L’extension du fichier doit être `.csv`.
* Évitez d’utiliser des caractères spéciaux (espaces, #, %, &, etc.) dans les noms de fichier
* Si vous utilisez un script ou une intégration pour générer des fichiers, l’adoption d’un schéma de nommage basé sur un horodatage aide à éviter les doublons et facilite le débogage.
* Si le fichier est volumineux, The Wallet Crew surveille brièvement sa taille afin de s’assurer qu’il est entièrement écrit avant le traitement.

## Référence de colonne

### Colonnes d’identifiant de Carte

Pour sélectionner la Carte cible, utilisez l’une des colonnes suivantes :

* `id`: identifiant interne de Carte The Wallet Crew
* `id.<externalId>`: nom de l’identifiant externe (tel que configuré dans votre tenant)\
  Exemple : `id.y2.customerId`

Au moins une colonne d’identifiant doit être présente dans chaque ligne.

### Colonnes de données supplémentaires

Pour mettre à jour les données supplémentaires sur la carte, utilisez la syntaxe suivante :

* `additionalData.<key>`: Met à jour la clé dans le dictionnaire additionalData de la carte `additionalData` dictionnaire\
  Exemple : `additionalData.notification_content`

Plusieurs clés additionalData peuvent être mises à jour dans une seule ligne.

### Modèle de Carte

Pour basculer la carte vers un autre modèle, incluez :

* `passType`: le nom du nouveau modèle (tel que défini dans The Wallet Crew)

Si elle est omise ou vide, la carte conservera son modèle actuel.

### Actualisation des métadonnées

Pour déclencher un recalcul des métadonnées internes (p. ex. codes-barres, expiration, champs d’affichage) :

* `updateMetadata`: définir sur `true` pour déclencher la mise à jour des métadonnées

### Identifiants externes

Pour mettre à jour un identifiant externe, utilisez la syntaxe suivante :

* `identifiers.<idName>`: Met à jour l’identifiant nommé `idName`\
  Exemple : `identifiers.y2.customerId`

## Accès SFTP

Téléversez vos fichiers CSV vers le point de terminaison SFTP de votre environnement :

* **QA**: `triglav-qa.walletcrew.net` (port `22`)
* **Production**: `triglav.walletcrew.net` (port `22`)

Contactez le support The Wallet Crew pour demander vos identifiants SFTP.

## Exemples

### Exemple 1 : Mise à jour du contenu de notification et de l’URL de l’offre

```csv
id;additionalData.notification_content;additionalData.offer_url
Gk440DNzvfZcDmlA;Joyeux Noël Alice !;https://acme.com/xmas1
HKlhrhrEXx2ZASYs;Joyeux Noël Bob !;https://acme.com/xmas1
```

### Exemple 2 : Mise à jour par identifiant externe avec informations de fidélité

```csv
id.y2.customerId;additionalData.notification_content
00100123;Profitez de 30 % de réduction sur votre prochain achat
04503295;Merci pour votre achat ! Plus que 10 points avant d’échanger un bon de 10 €
02319202;Merci pour votre achat ! Plus que 120 points avant d’échanger un bon de 10 €
```

### Exemple 3 : Changer le modèle de Carte et forcer l’actualisation des métadonnées

```csv
id;passType;updateMetadata
gH67xKlPzLZ99xa2;vip_template;true
dAk21jvUZYx39q77;standard_template;true
```

### Exemple 4 : Mettre à jour l’id externe y2.customerId et forcer l’actualisation des métadonnées

```csv
id.y2.customerId;identifiers.y2.customerId;passType;updateMetadata
04503295;1010013295;;true
04503296;1010013296;;true
```

## Extensibilité et mappage personnalisé

The Wallet Crew prend en charge des transformations de fichiers personnalisées à l’aide de scripts d’import.

Cela vous permet de :

* Adapter votre format d’export existant (p. ex. depuis un CRM ou un système de point de vente)
* Mapper les anciens noms de colonnes vers des clés compatibles avec The Wallet Crew
* Injecter des valeurs dynamiques (p. ex. la date actuelle, les points calculés)
* Enrichir les données avec des recherches dans des sources externes

Pour personnaliser le processus d’import, vous pouvez créer un `import.custom.js` fichier dans le `scripts/` dossier de la configuration avancée.

Si vous avez le fichier CSV suivant :

```csv
id.y2.customerId,neo_notification_content,neo_offer_title,neo_offer_body
abc12345,"Salut Arthur !","Votre offre de 20 %","20 % de réduction sur votre prochain achat"
```

Vous pouvez utiliser le script suivant :

```js
/**
 * Transforme une ligne CSV en objet de type UpdatePassInformation.
 *
 * @param {Object<string, string>} row - La ligne CSV, sous forme de dictionnaire associant les noms de colonnes aux valeurs.
 * @returns {Object} Informations de ligne transformées.
 * @returns {Object<string, string>} return.Identifiers - Identifiants pour cette ligne (p. ex. ID client).
 * @returns {string|null} return.PassType - Le type de Carte, ou null s’il n’est pas présent.
 * @returns {Object<string, string>} return.AdditionalData - Données supplémentaires facultatives issues des colonnes préfixées.
 */
function transform(row){
  const identifiers = {
      "id.y2.customerId" : row["id.y2.customerId"]
  };

  const passType = row.passType || null; 

  const properties = [
    "notification_content",
    "offer_title", 
    "offer_body"
   ];

  let additionalData = {};
  for(const property of properties){
    if(row["neo_" + property] !== undefined){
      additionalData[property] = row["neo_" + property].toString(); 
    }
  }

  return {
    Identifiers : identifiers, 
    PassType: passType,
    AdditionalData : additionalData
  }
}

/**
 * Méthode facultative pour renvoyer un débit personnalisé pour un fichier d’import donné.
 *
 * @param {string} fileName - Le nom du fichier d’import.
 * @returns {number|null} Remplacement du débit, ou null pour utiliser la valeur par défaut.
 */
function getThroughput(fileName) {
  // Exemple : renvoyer null pour utiliser la valeur par défaut
  return null;
}

export default function(context) {
  context.register('runtime.import.updatePasses.rowTransformer', {
    Transform: transform, 
    GetThroughput: getThroughput
  });
}
```

Contactez notre équipe si vous avez besoin d’aide pour implémenter une logique de mappage personnalisée pour vos imports.

## Conseils et bonnes pratiques

* Assurez-vous que les identifiants sont exacts pour éviter que des lignes soient ignorées.
* Testez toujours votre format de fichier en QA avant de le téléverser en production.
* Utilisez un encodage cohérent (UTF-8) pour éviter les problèmes d’analyse avec les caractères spéciaux.

## FAQ

<details>

<summary><strong>Créez-vous de nouvelles cartes, ou mettez-vous seulement à jour celles qui existent déjà ?</strong></summary>

Ce flux met à jour des cartes existantes. Chaque ligne doit cibler une carte en utilisant `id` ou une colonne d’identifiant externe comme `id.y2.customerId`.

</details>

<details>

<summary><strong>Que se passe-t-il si une ligne contient à la fois <code>id</code> et <code>id.&#x3C;externalId></code>?</strong></summary>

Utilisez un identifiant par ligne si possible. Si vous en incluez plusieurs, assurez-vous qu’ils pointent tous vers la même carte. Cela évite toute ambiguïté et facilite le dépannage.

</details>

<details>

<summary><strong>Puis-je mettre à jour plusieurs <code>additionalData</code> clés dans une seule ligne ?</strong></summary>

Oui. Ajoutez une colonne par clé, en utilisant `additionalData.<key>`. La ligne mettra à jour toutes les clés fournies en une seule mise à jour de carte.

</details>


# Migration des Cartes

Utilisez la migration de cartes lorsque vous souhaitez changer le système qui **gère** vos cartes, tout en gardant les cartes déjà installées fonctionnelles pour les clients.

Une migration est un changement « en coulisses ». Les clients conservent la même carte dans Apple Wallet ou Google Wallet. Votre objectif est la continuité : la carte reste valide et les mises à jour continuent de fonctionner.

{% hint style="success" %}
Dans la plupart des cas, vous pouvez migrer sans impact pour les clients.

Si vous planifiez la transition et effectuez d’abord des tests, les clients conservent la même carte et elle continue de se mettre à jour.
{% endhint %}

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de vente au détail migre ses cartes de fidélité en milieu de saison sans demander aux clients de les réinstaller.
* Un organisateur de spectacle change de prestataire de billetterie après un pilote.
* Une marque regroupe plusieurs fournisseurs de cartes sur une plateforme unique.

</details>

## Que les clients doivent-ils vivre ?

Lorsqu’une migration est correctement effectuée, les clients ne réinstallent rien. Ils conservent la même carte sur leur appareil et peuvent continuer à l’utiliser comme d’habitude.

En pratique, cela signifie que le code-barres ou le QR code utilisé en magasin ou à l’entrée reste identique. La carte continue aussi de recevoir des mises à jour (par exemple : points, niveau, solde, siège, porte ou validité).

La plupart des migrations incluent un court pilote. Vous validez le flux avec un petit lot, puis vous basculez les cartes restantes.

### Plan de migration type

Les étapes exactes dépendent de la direction (vers ou depuis The Wallet Crew) et des contraintes de la plateforme. Le flux ci-dessous reste globalement valable dans la plupart des projets.

{% stepper %}
{% step %}

### 1) Confirmez ce que « en place » signifie pour votre configuration

Confirmez quelle identité d’émetteur Apple signe vos cartes, et quel compte émetteur Google Wallet les détient. C’est ce qui détermine si les clients peuvent conserver la même carte, ou si vous devez prévoir un flux de réémission.
{% endstep %}

{% step %}

### 2) Exportez les identifiants techniques des cartes

Vous avez besoin des identifiants qui permettent au nouveau système de se rattacher aux cartes existantes (par exemple les numéros de série Apple + les jetons d’authentification, ou les ID de ressource / ID d’objet Google).
{% endstep %}

{% step %}

### 3) Mappez les champs et lancez un lot pilote

Commencez par un petit lot. Mettez à jour un champ visible et validez-le sur de vrais appareils. Gardez le pilote simple afin de pouvoir itérer rapidement.
{% endstep %}

{% step %}

### 4) Basculez, puis surveillez

Exécutez le plan de bascule, puis surveillez les mises à jour et l’utilisation pendant quelques jours. Conservez une option de retour arrière si votre ancien fournisseur le permet.
{% endstep %}
{% endstepper %}

### Coordination et calendrier

Une migration nécessite une coordination entre plusieurs parties. Il s’agit généralement de votre fournisseur actuel et de The Wallet Crew, avec votre propre équipe impliquée lorsque vous gérez les comptes émetteurs et les certificats.

Le travail est rarement « difficile » d’un point de vue technique. La majeure partie du temps est consacrée à l’alignement sur le format d’export, le mappage des champs, les validations de sécurité et le plan de bascule. Prévoyez quelques semaines pour un projet typique. Les délais varient selon le fournisseur et les cycles d’approbation.

### Choisissez votre parcours

* Migration **vers** The Wallet Crew : [Migrer les cartes vers The Wallet Crew](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/move-passes-to-the-wallet-crew)
* Migration **depuis** The Wallet Crew : [Exporter les cartes depuis The Wallet Crew vers un autre fournisseur](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider)

### Contraintes clés (Apple vs Google)

Apple Wallet et Google Wallet ont des règles différentes. Ces règles expliquent pourquoi les migrations nécessitent de la coordination et pourquoi un lot de test est important.

#### Apple Wallet

Les migrations Apple Wallet dépendent de l’identité d’émetteur utilisée pour signer les cartes. Elles dépendent aussi de l’« adresse » de mise à jour intégrée dans la carte (`webServiceURL`), car les appareils interrogent cette URL pour récupérer les mises à jour.

Si vous pouvez conserver la même identité d’émetteur et rediriger correctement `webServiceURL`, les clients peuvent généralement conserver la même carte installée.

#### Google Wallet

Les migrations Google Wallet dépendent du compte émetteur qui détient les cartes. Si le compte émetteur change, vous devez généralement réémettre les cartes (ce qui implique un nouveau flux d’enregistrement pour les clients).

Si vous conservez le même compte émetteur et les mêmes ID d’objet, les clients peuvent généralement conserver la même carte.

### FAQ

<details>

<summary><strong>Les clients doivent-ils réinstaller leur carte pendant une migration ?</strong></summary>

Généralement non. Si vous migrez « en place » (même identité d’émetteur Apple, et Google sous le même compte émetteur), les clients conservent la même carte et elle continue de se mettre à jour.

</details>

<details>

<summary><strong>De quelles données avons-nous généralement besoin de l’ancien fournisseur ?</strong></summary>

Vous avez généralement besoin d’identifiants techniques qui permettent à un nouveau système de se rattacher à la carte existante.

* Pour Apple, il s’agit généralement du numéro de série et du jeton d’authentification.
* Pour Google, il s’agit généralement de l’ID de ressource (ID d’objet).

</details>

<details>

<summary><strong>Combien de temps prend généralement une migration ?</strong></summary>

Prévoyez quelques semaines. La majeure partie du temps est consacrée à la coordination, pas à l’implémentation. Vous avez besoin de temps pour l’export, le mappage et un petit lot de test.

</details>

<details>

<summary><strong>Qui doit être impliqué ?</strong></summary>

Vous avez besoin de votre fournisseur actuel et de The Wallet Crew. Si vous gérez les comptes émetteurs et les certificats, votre équipe est également impliquée.

</details>


# Déplacer les Cartes vers The Wallet Crew

Migrez les cartes actives Apple Wallet et Google Wallet d'un autre fournisseur vers The Wallet Crew sans obliger les clients à les réinstaller.

Utilisez ce guide lorsque vous souhaitez migrer **déjà installées** des cartes Apple Wallet et Google Wallet d’un autre fournisseur vers The Wallet Crew.

L’objectif est d’assurer la continuité pour les clients. Lorsque la migration est effectuée correctement, ils conservent la même carte sur leur appareil, ne réinstallent rien, et votre flux de codes-barres et d’utilisation reste inchangé.

L’essentiel du travail relève de la coordination, et non de l’implémentation. Vous alignez les identifiants de l’émetteur, exportez les identifiants techniques reliant chaque carte à son enregistrement Apple/Google existant, validez avec un petit pilote, puis effectuez une bascule contrôlée.

Si vous avez besoin du flux inverse, consultez [Exporter les cartes depuis The Wallet Crew vers un autre fournisseur](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider).

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque décide de changer de fournisseur de cartes Wallet, mais souhaite que les clients conservent leurs cartes installées.
* Une marque remplace une configuration Wallet interne par The Wallet Crew afin de bénéficier d’une couche opérationnelle plus fiable.
* Une marque change de système sous-jacent (CRM, fidélité, billetterie, POS) et doit transférer les cartes actives en toute sécurité.

</details>

## Avant de commencer

La plupart des migrations réussissent ou échouent selon les contraintes des plateformes et selon la personne qui contrôle les identifiants de l’émetteur.

Si vous souhaitez obtenir des informations sur les identifiants et les données de carte, consultez [Structure.](/developers-guides/fr/pass-architecture/structure)

### Configurez votre projet The Wallet Crew avant la migration

Vous ne pouvez pas démarrer une migration avant que votre projet The Wallet Crew ne fonctionne déjà de bout en bout.

La migration ne consiste pas à « recréer des cartes ». Elle consiste à importer les identifiants qui permettent à The Wallet Crew de prendre en charge les mises à jour des cartes déjà installées sur les appareils. Si votre projet n’est pas configuré, les cartes importées existeront, mais elles ne se mettront pas à jour de manière fiable après la bascule.

Avant d’importer quoi que ce soit, assurez-vous que :

* Vous avez connecté les fournisseurs de Wallet et pouvez signer/détenir des cartes (Apple Carte Type ID et certificats, accès au compte émetteur Google Wallet).
* Vous avez décidé quels **identifiants externes** vous utiliserez pour relier les cartes à vos systèmes (ID client, ID de billet, numéro d’adhérent, ID de commande, ...). Ils doivent être stables dans le temps.
* Vous pouvez calculer le contenu des cartes à partir de votre source de référence (intégration API, processus basé sur des fichiers ou processus opérationnel).
* Vous pouvez exécuter un cycle de vie complet sur des cartes de test : émettre, mettre à jour un champ visible et vérifier la mise à jour sur un appareil réel.

<details>

<summary>Liste de vérification de préparation à la migration</summary>

Utilisez cette liste comme liste de validation avant de toucher aux cartes de production.

* [ ] Vous savez quel Apple Carte Type ID signe les cartes existantes.
* [ ] Vous disposez des identifiants Apple nécessaires pour conserver la même identité d’émetteur.
* [ ] Vous connaissez le Google Wallet `issuerId` qui possède les cartes existantes.
* [ ] Vous avez accès à ce compte émetteur dans la Google Pay & Wallet Console.
* [ ] Votre fournisseur actuel peut exporter une ligne par carte avec les identifiants requis.
* [ ] Votre fournisseur actuel peut envoyer une « mise à jour finale » Apple (voir l’étape de bascule).
* [ ] Vous disposez d’un lot pilote de 2 à 3 cartes réelles par plateforme.
* [ ] Vous disposez d’un plan de retour arrière pour Apple (s’il est pris en charge par l’ancien fournisseur).

{% hint style="info" %}
Prévoyez au moins un cycle pilote. La plupart des retards proviennent des exports, des approbations et de la planification de la bascule.
{% endhint %}

</details>

{% hint style="info" %}
Prévoyez au moins un cycle pilote. La plupart des retards proviennent des exports, des approbations et de la planification de la bascule.
{% endhint %}

### Ce que vous importez : les identifiants de carte (plateforme + externes)

Vous ne recréez pas de cartes lors d’une migration. Vous importez les identifiants afin que The Wallet Crew puisse mettre à jour les cartes qui sont **déjà installées** sur les appareils.

Vous importez deux types d’identifiants :

* **Identifiants de plateforme**. Ils pointent vers l’enregistrement de carte Apple/Google existant.
  * Apple : `serialNumber` + `authenticationToken`
  * Google : objet **ID de ressource** (souvent appelé ID d’objet)
* **Identifiants externes**. Ils relient une carte à vos propres systèmes.
  * Exemples : ID client, ID de billet, numéro d’adhérent, ID de commande

Les identifiants de plateforme permettent à The Wallet Crew de mettre à jour la même carte sur l’appareil. Les identifiants externes vous permettent d’associer la carte au bon enregistrement client et de garantir des mises à jour correctes après la bascule.

Une même carte peut avoir plusieurs identifiants externes. Cela est utile lorsque vous rapprochez des données entre plusieurs systèmes.

### Déterminez si vous pouvez migrer « sur place »

Apple et Google n’autorisent pas les mêmes modèles de migration.

#### Apple Wallet (la migration sur place est généralement possible)

Vous pouvez généralement migrer sans réinstallation si vous conservez la même identité d’émetteur Apple (même Carte Type ID / identité de signature) et redirigez le point de terminaison de mise à jour de la carte (`webServiceURL`).

Cela exige généralement que votre fournisseur actuel envoie au moins une « mise à jour finale » aux cartes installées. Cette mise à jour intègre The Wallet Crew `webServiceURL` afin que les appareils commencent à appeler The Wallet Crew pour les futures mises à jour.

#### Google Wallet (uniquement si vous conservez le même compte émetteur)

Les cartes Google Wallet sont liées à un compte émetteur Google Pay & Wallet Console (`issuerId`).

Si les cartes existantes ont été créées sous un compte émetteur que vous ne contrôlez pas, vous ne pouvez pas les transférer sur place. Vous devez prévoir un flux de réémission (nouveaux liens d’enregistrement, nouveaux objets).

{% hint style="warning" %}
Pour Google Wallet, planifiez la migration autour de votre compte émetteur.

Si votre fournisseur actuel a émis des cartes sous un compte émetteur que vous ne contrôlez pas, prévoyez un flux de réémission.
{% endhint %}

### Ce dont vous avez besoin de la part de votre fournisseur actuel

Demandez une ligne d’export par carte. Vous l’utiliserez pour associer The Wallet Crew à la carte *existante* installée.

Au minimum, obtenez :

* **Apple Wallet**: `serialNumber` et `authenticationToken`
* **Google Wallet**: objet **ID de ressource** (souvent appelé « ID de ressource » ou « ID d’objet »)
* Un identifiant client stable (e-mail, ID client, ID de billet). C’est ainsi que vous associez les cartes aux clients.

{% hint style="info" %}
Si votre fournisseur actuel peut également partager l’Apple Carte Type ID et le Google `issuerId`, cela accélère la vérification d’éligibilité.
{% endhint %}

## Étapes de migration

### Vue d’ensemble de la séquence (ce qui se passe de bout en bout)

Ces diagrammes présentent les points de contrôle nécessaires à une bascule propre. L’idée clé est simple : vous importez des identifiants dans The Wallet Crew, puis vous vous assurez que les appareils commencent à récupérer les mises à jour depuis The Wallet Crew.

{% tabs %}
{% tab title="Apple Wallet" %}
La migration Apple sur place fonctionne généralement si vous conservez le même Carte Type ID et que votre fournisseur actuel peut envoyer une « mise à jour finale » qui modifie la carte `webServiceURL` vers The Wallet Crew.

```mermaid
sequenceDiagram
  autonumber
  participant Brand as Systèmes de la marque
  participant Old as Ancien fournisseur
  participant TWC as The Wallet Crew
  participant Device as Appareil du client (Apple Wallet)

  Brand->>Old: Demander l’export (serialNumber, authenticationToken, ID externes)
  Old-->>Brand: Fichier / flux d’export
  Brand->>TWC: Importer les identifiants

  Brand->>Old: Demander une « mise à jour finale » définissant webServiceURL = The Wallet Crew
  Old->>Device: Envoyer une notification de mise à jour
  Device->>Old: Récupérer le package de carte mis à jour
  Old-->>Device: Carte mise à jour avec le nouveau webServiceURL

  Brand->>TWC: Mettre à jour les données de la carte après la bascule
  TWC->>Device: Envoyer une notification de mise à jour
  Device->>TWC: Récupérer le package de carte mis à jour
  TWC-->>Device: Contenu de carte mis à jour
```

{% endtab %}

{% tab title="Google Wallet" %}
La migration Google sur place fonctionne uniquement si les cartes existantes appartiennent à un `issuerId` que vous contrôlez. Dans ce cas, The Wallet Crew met à jour les mêmes ID de ressources d’objet.

```mermaid
sequenceDiagram
  autonumber
  participant Brand as Systèmes de la marque
  participant Old as Ancien fournisseur
  participant TWC as The Wallet Crew
  participant Google as Google Wallet
  participant Device as Appareil du client (Google Wallet)

  Brand->>Old: Demander l’export (ID de ressource d’objet, ID externes)
  Old-->>Brand: Fichier / flux d’export
  Brand->>TWC: Importer les identifiants (ID de ressources)

  Brand->>TWC: Mettre à jour les données de la carte après la bascule
  TWC->>Google: Mettre à jour l’objet existant (même issuerId)
  Google-->>Device: Le client voit le contenu de la carte mis à jour après la synchronisation
```

{% endtab %}
{% endtabs %}

{% stepper %}
{% step %}

### Configurer les identifiants de l’émetteur The Wallet Crew

Vous avez besoin que The Wallet Crew s’authentifie comme le même « émetteur » que les cartes existantes.

* Pour Apple, utilisez le même Carte Type ID que votre fournisseur actuel dans la mesure du possible. Configurez ensuite les certificats.\
  Suivez : [Certificats Apple Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/apple-wallet-certificates).
* Pour Google, confirmez quel compte émetteur Google Wallet possède les cartes existantes. Vous avez besoin d’accéder à ce compte émetteur.\
  Suivez : [Compte Google Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account).
  {% endstep %}

{% step %}

### Exportez les identifiants techniques des cartes depuis votre fournisseur actuel

Demandez à votre fournisseur actuel une ligne d’export par carte.

Au minimum, exportez :

* Apple : **numéro de série** et **jeton d’authentification**
* Google : **ID de ressource** (ou ID d’objet)
* Vos identifiants externes (afin d’associer chaque carte au bon client)
  {% endstep %}

{% step %}

### Importez ces cartes dans The Wallet Crew

Importez les identifiants exportés dans The Wallet Crew afin que chaque enregistrement de carte puisse être lié à ses identifiants Apple/Google existants.

Commencez par [Importation et exportation](/configure/fr/advanced-configuration/wallet/import-and-export). Si vous avez besoin d’un flux de mise à jour en masse basé sur des fichiers, consultez [Mettre à jour une carte à l’aide de fichiers plats](/configure/fr/advanced-configuration/wallet/import-and-export/update-pass-using-flat-files).

{% hint style="info" %}
Les imports de migration nécessitent souvent des colonnes supplémentaires (jeton d’authentification Apple, ID de ressource Google).

Si vous ne savez pas comment mapper ces champs dans votre tenant, demandez à l’équipe The Wallet Crew de confirmer le format de fichier attendu.
{% endhint %}
{% endstep %}

{% step %}

### Effectuez la bascule : redirigez les mises à jour des cartes Apple vers The Wallet Crew

Les cartes Apple Wallet récupèrent les mises à jour depuis le `webServiceURL` intégré dans la carte.

Pour migrer sans réinstallation, votre fournisseur actuel doit mettre à jour `webServiceURL` sur les cartes existantes et déclencher une mise à jour afin que les appareils téléchargent la nouvelle version de la carte.

{% hint style="warning" %}
N’arrêtez pas le service web Apple de votre ancien fournisseur avant d’avoir validé la bascule sur des appareils réels.

Si l’ancien point de terminaison cesse de répondre avant que les appareils reçoivent la « mise à jour finale », les cartes peuvent cesser de se mettre à jour.
{% endhint %}

Demandez à votre ancien fournisseur de mettre à jour en masse toutes les cartes existantes afin que leur `webServiceURL` corresponde à The Wallet Crew `webServiceURL` :

> `https://api-passd.neostore.cloud/api/<tenantId>/passes/apple`

remplacez `<tenantId>` par votre tenantId, confirmez la valeur auprès de l’équipe d’assistance The Wallet Crew.
{% endstep %}

{% step %}

### Validez sur un petit échantillon

Choisissez 2 à 3 cartes sur chaque plateforme.

Mettez à jour un champ visible via The Wallet Crew. Vérifiez ensuite qu’il se met à jour sur les appareils.

Si vous devez accélérer le rafraîchissement pendant les tests, lancez une mise à jour push depuis The Wallet Crew. Cela est utile sur les deux plateformes : les appareils Apple récupèrent le package de carte mis à jour, et les utilisateurs Google voient l’objet mis à jour plus tôt.
{% endstep %}

{% step %}

### Surveillez après la bascule

Surveillez les mises à jour et l’utilisation pendant quelques jours. Conservez une option de retour arrière si votre fournisseur précédent la prend en charge.

Pour Apple, le retour arrière signifie généralement rediriger `webServiceURL` à nouveau et déclencher une mise à jour. N’essayez pas ceci à moins de disposer d’un point de terminaison confirmé et fonctionnel chez l’ancien fournisseur.
{% endstep %}
{% endstepper %}

## Pièges fréquents

Les échecs Apple et Google se présentent différemment. Ces vérifications permettent de détecter la plupart des problèmes rapidement.

### Apple Wallet

Si les clients signalent que les cartes cessent de se mettre à jour après la bascule, il s’agit généralement de l’un des cas suivants :

* Le `webServiceURL` n’a pas été mis à jour sur les cartes installées.
* L’ancien fournisseur a mis à jour `webServiceURL` mais n’a pas déclenché de mise à jour push.
* Les identifiants Apple de The Wallet Crew ne correspondent pas à l’identité de la carte d’origine (Carte Type ID / certificat).

### Google Wallet

Si les mises à jour échouent sur Google, il s’agit généralement de l’un des cas suivants :

* Les cartes existantes appartiennent à un autre `issuerId`.
* L’« ID de ressource » exporté ne correspond pas aux ID d’objet mis à jour.
* Les autorisations de la Google Pay & Wallet Console ne permettent pas les mises à jour à partir des identifiants The Wallet Crew.

## FAQ

<details>

<summary><strong>Les clients doivent-ils réinstaller leur carte ?</strong></summary>

En général, non.

Si vous redirigez correctement le `webServiceURL` Apple, les cartes existantes continuent de se mettre à jour sur place.

Pour Google, si vous conservez le même compte émetteur et les mêmes ID de ressources, les utilisateurs conservent généralement la même carte.

</details>

<details>

<summary><strong>Pourquoi avons-nous besoin du jeton d’authentification Apple ?</strong></summary>

Apple utilise le jeton d’authentification pour authentifier les demandes de mise à jour pour un numéro de série donné.

Sans lui, un nouveau fournisseur ne peut pas fournir de manière fiable des mises à jour à la même carte installée.

</details>

<details>

<summary><strong>Pouvons-nous migrer des cartes Google Wallet entre des comptes émetteurs ?</strong></summary>

Pas sur place.

Les cartes Google Wallet sont liées au compte émetteur. Si l’émetteur change, prévoyez un flux de réémission.

</details>

<details>

<summary><strong>Comment savoir si la bascule Apple a fonctionné ?</strong></summary>

Mettez à jour un champ visible dans The Wallet Crew et confirmez le changement sur un appareil réel. Si vous le pouvez, confirmez également que la carte installée appelle le point de terminaison The Wallet Crew en vérifiant les journaux du serveur ou en demandant à l’assistance The Wallet Crew de confirmer le trafic.

</details>

<details>

<summary><strong>Que se passe-t-il si nous ne pouvons pas conserver le même Apple Carte Type ID ?</strong></summary>

Prévoyez une réémission.

Si l’identité d’émetteur Apple change, les clients doivent généralement ajouter une nouvelle carte. Effectuez un déploiement contrôlé et conservez l’ancienne carte valide pendant une période de transition lorsque cela est possible.

</details>

<details>

<summary><strong>Que se passe-t-il si notre fournisseur actuel ne peut pas envoyer la « mise à jour finale » Apple ?</strong></summary>

Vous ne pourrez peut-être pas migrer les cartes Apple sur place.

Sans mise à jour finale, les cartes installées continuent d’appeler l’ancien `webServiceURL`. Dans ce cas, vous devez soit maintenir l’ancien point de terminaison actif, soit prévoir un flux de réémission.

</details>

<details>

<summary><strong>Devons-nous modifier les codes-barres ou la logique d’utilisation ?</strong></summary>

Pas nécessairement.

Si vous conservez les mêmes identifiants de carte et générez la même charge utile de code-barres, votre flux de scan en magasin ou au portique peut rester inchangé. Validez-le explicitement pendant le pilote en scannant les cartes migrées dans des conditions réelles.

</details>

<details>

<summary><strong>Que devons-nous communiquer aux clients pendant la migration ?</strong></summary>

Si la migration est effectuée sur place, vous n’avez généralement rien à communiquer. Les clients conservent la même carte et elle continue de se mettre à jour.

Si vous devez réémettre des cartes, communiquez clairement et suffisamment tôt le nouveau flux « Ajouter à Wallet ». Restez concis et concentrez-vous sur ce que les clients doivent faire.

</details>


# Exporter les Cartes de TWC vers un autre fournisseur

Exportez vos cartes Apple Wallet et Google Wallet afin qu'un nouveau fournisseur puisse prendre en charge les mises à jour, avec des contraintes claires pour chaque plateforme.

Si vous décidez un jour d’arrêter d’utiliser The Wallet Crew, vous pouvez le faire à tout moment. Cette page explique comment migrer sans interrompre les mises à jour de Carte pour les clients.

C’est aussi pourquoi nous demandons aux marques d’utiliser leurs propres comptes Apple et Google Wallet. Cela vous maintient comme émetteur officiel. Cela évite aussi le verrouillage fournisseur.

Vos données clients vous appartiennent. Vous restez le responsable du traitement des données. En pratique, votre source de vérité reste dans votre CRM et vos systèmes internes.

Pour changer de fournisseur, vous exportez les identifiants opérationnels des Cartes depuis The Wallet Crew. Vous les remettez à votre nouveau fournisseur afin qu’il puisse reprendre les mises à jour.

{% hint style="info" %}
Si vous envisagez de partir à cause d’un blocage, prévenez-nous tôt. Nous pouvons souvent le résoudre sans nécessiter de migration.
{% endhint %}

Apple Wallet et Google Wallet ne fonctionnent pas de la même façon. Les Cartes Apple récupèrent les mises à jour depuis un `webServiceURL`. Les Cartes Google sont liées à un compte émetteur Google Wallet.

## Ce que vous devez prévoir (Apple vs Google)

### Apple Wallet

Les Cartes Apple installées sur les appareils continuent d’appeler le `webServiceURL` intégré dans la carte.

Pour passer à un nouveau fournisseur, vous devez :

1. Exporter chaque Carte **numéro de série** et **jeton d’authentification**.
2. Mettre à jour le `webServiceURL` vers le point de terminaison de votre nouveau fournisseur.
3. Déclenchez une mise à jour afin que les appareils téléchargent une version de Carte pointant vers le nouveau fournisseur.

### Google Wallet

Les Cartes Google Wallet sont liées à un **compte émetteur Google Wallet**.

Vous ne pouvez pas « transférer » les Cartes vers un autre compte émetteur. Votre nouveau fournisseur doit soit :

* opérer sous le **même** compte émetteur, ou
* réémettre les Cartes sous un nouveau compte émetteur (nouveaux liens d’enregistrement, nouveaux objets).

## Étape par étape

{% stepper %}
{% step %}

### Exporter les données des Cartes depuis The Wallet Crew

Ouvrez la liste des Cartes dans la console d’administration :

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passes/" class="button secondary" data-icon="chevrons-right">Console d’administration The Wallet Crew - Liste des Cartes</a></p>

Exportez la liste complète.

Assurez-vous que l’export inclut au minimum :

* Apple : **numéro de série** et **jeton d’authentification**
* Google : **ID de ressource** (ou ID d’objet)
* Vos identifiants externes (afin que le nouveau fournisseur puisse rattacher les Cartes aux clients)
  {% endstep %}

{% step %}

### Remettez l’export à votre nouveau fournisseur

Envoyez le fichier exporté à votre nouveau fournisseur. Ils en ont besoin pour le rattacher aux Cartes existantes.

Pour Apple, ils importeront généralement le numéro de série + le jeton d’authentification afin de pouvoir signer et diffuser les mises à jour.

Pour Google, ils utiliseront généralement les IDs de ressource pour mettre à jour les objets existants.
{% endstep %}

{% step %}

### Basculer les Cartes Apple vers le nouveau point de terminaison de mise à jour

Convenez du nouveau point de terminaison de service web Apple Wallet avec votre nouveau fournisseur.

Demandez ensuite à l’équipe The Wallet Crew de :

1. configurer la cible `webServiceURL` pour votre tenant, et
2. lancer une « mise à jour poussée » en masse afin que les Cartes installées récupèrent la nouvelle URL.

{% hint style="warning" %}
Si vous changez le `webServiceURL` sans point de terminaison fonctionnel chez le nouveau fournisseur, les Cartes Apple risquent de ne plus se mettre à jour.

Prévoyez une courte fenêtre de validation et testez d’abord sur un petit échantillon.
{% endhint %}
{% endstep %}

{% step %}

### Valider la migration

Choisissez 2 à 3 Cartes de test (Apple et Google).

Demandez au nouveau fournisseur de :

* mettre à jour un champ visible (exemple : solde de points, statut ou porte d’accès à un événement)
* confirmer que la mise à jour est visible sur les appareils en quelques minutes

Pour Apple, confirmez aussi que les mises à jour fonctionnent toujours après réinstallation de la Carte.
{% endstep %}
{% endstepper %}

## FAQ

<details>

<summary><strong>Les utilisateurs finaux doivent-ils réinstaller leur Carte ?</strong></summary>

En général, non.

Si vous basculez côté Apple `webServiceURL` correctement, les Cartes existantes continuent de se mettre à jour sans réinstallation.

Pour Google, si vous conservez le même compte émetteur et les mêmes IDs d’objet, les utilisateurs gardent généralement la même Carte.

</details>

<details>

<summary><strong>Peut-on déplacer les Cartes Google Wallet vers un autre compte émetteur ?</strong></summary>

Pas sur place.

Les cartes Google Wallet sont liées au compte émetteur. Si l’émetteur change, prévoyez un flux de réémission.

</details>

<details>

<summary><strong>Quelles sont les données minimales que nous devons exporter ?</strong></summary>

Pour Apple, vous avez besoin du numéro de série et du jeton d’authentification.

Pour Google, vous avez besoin de l’ID de ressource.

Les identifiants externes sont fortement recommandés. Ils permettent au nouveau fournisseur de conserver la correspondance entre les Cartes et les clients.

</details>


# Configuration avancée

Configuration avancée du locataire pour les utilisateurs avancés : gérez les fichiers YAML, les sauvegardes \`.fctwc\`, l'historique d'audit et les comparaisons de configuration avec l'assistance de The Wallet Crew Support.

La configuration avancée offre aux utilisateurs avancés un accès à la configuration YAML du tenant The Wallet Crew. Chaque tenant dispose d’un ensemble de fichiers YAML qui définissent sa configuration complète.

Les secrets ne sont pas stockés dans ces fichiers. The Wallet Crew stocke les secrets dans un Key Vault dédié.

Le **Configuration avancée** L’éditeur est destiné aux utilisateurs avancés. Il fournit un accès contrôlé pour les exceptions guidées par le support, les sauvegardes complètes de configuration, les importations et la revue des changements.

{% hint style="warning" %}
N’utilisez pas cet éditeur sauf si l’équipe de support The Wallet Crew vous demande une modification précise. La plupart des paramètres disposent d’écrans dédiés qui mettent à jour les fichiers sous-jacents en toute sécurité.
{% endhint %}

<details>

<summary>Exemples concrets</summary>

* L’équipe de support The Wallet Crew fournit un ajustement de configuration pour une exigence exceptionnelle de connecteur.
* Un utilisateur avancé exporte une `.fctwc` sauvegarde avant une mise à jour de configuration guidée par le support.
* Une équipe compare la configuration de préproduction et de production avant une mise en production approuvée.

</details>

### Ouvrir l’éditeur de configuration avancée

Ouvrez l’éditeur de configuration avancée du tenant depuis **Paramètres** → **Configuration avancée**.

Utilisez l’éditeur uniquement après avoir reçu des instructions de l’équipe de support The Wallet Crew. Ne modifiez aucun fichier de configuration sans ces instructions. Un fichier peut affecter plusieurs fonctionnalités de la plateforme.

### Exporter ou importer une configuration complète du tenant

L’éditeur peut exporter la configuration complète du tenant sous forme de sauvegarde. Le fichier exporté utilise l’ `.fctwc` extension, ce qui signifie **Configuration complète The Wallet Crew**.

Un `.fctwc` fichier est une archive ZIP contenant tous les fichiers de configuration du tenant. Conservez les exportations en lieu sûr, car elles peuvent contenir des détails de configuration.

Utilisez l’importation pour restaurer ou transférer une configuration de tenant précédemment exportée :

1. Exportez la configuration actuelle avant d’apporter des modifications.
2. Sélectionnez le `.fctwc` fichier à importer.
3. Vérifiez la configuration importée, puis validez son effet dans les écrans d’administration concernés.

{% hint style="info" %}
Une importation restaure uniquement les fichiers de configuration. Les secrets restent gérés séparément dans le Key Vault dédié.
{% endhint %}

### Examiner les modifications de configuration du tenant

L’historique d’audit de configuration enregistre les modifications de configuration du tenant. Ouvrez **Paramètres** → **Surveillance** → **Audit** pour les examiner.

L’historique affiche quatre colonnes :

* **Horodatage** — quand la modification a eu lieu.
* **Nom du fichier** — le fichier de configuration qui a changé.
* **Auteur** — la personne qui a effectué la modification.
* **Modifications du fichier** — la modification enregistrée.

Chaque entrée fournit deux actions de comparaison :

* **Comparer avec la version précédente** affiche la version sélectionnée par rapport à la version précédente.
* **Comparer avec la version actuelle** affiche la version sélectionnée par rapport à la configuration active.

### Comparer les configurations du tenant

Ouvrez **Paramètres** → **Outils** → **Comparaison de configuration** pour comparer les configurations du tenant sans les modifier.

Cette vue peut comparer des configurations entre environnements. Elle peut également comparer des tenants lorsque l’accès inclut plus d’un tenant. Sélectionnez une date pour comparer la configuration active avec une version précédente.

Utilisez les comparaisons avant d’importer une sauvegarde ou d’appliquer une modification manuelle exceptionnelle. Cela permet d’identifier rapidement les différences involontaires.

### Référence du fichier de configuration

Chaque fichier de configuration dispose d’une page de référence dédiée. Ces pages décrivent la finalité du fichier, le schéma YAML pris en charge et les contraintes de configuration.

### FAQ

<details>

<summary>Quand faut-il utiliser l’éditeur de configuration avancée ?</summary>

Utilisez-le uniquement lorsque l’équipe de support The Wallet Crew demande une modification précise. Les fonctionnalités standard de la plateforme doivent être configurées via leurs écrans d’administration dédiés.

</details>

<details>

<summary>Une exportation de configuration complète inclut-elle les secrets ?</summary>

Non. Les secrets sont stockés séparément dans le Key Vault dédié et ne sont pas inclus dans `.fctwc` les exportations.

</details>

<details>

<summary>Les configurations peuvent-elles être comparées entre tenants ?</summary>

Oui, lorsque le compte a accès à plus d’un tenant. La vue de comparaison prend également en charge les comparaisons par environnement et par date.

</details>


# Vue d’ensemble

Les connecteurs sont des accélérateurs d’intégration qui aident à relier The Wallet Crew aux systèmes clients existants — CRM, POS, automatisation marketing, billetterie, commerce électronique et matériel. Ce ne sont pas des solutions prêtes à l’emploi. Chaque client possède des modèles de données, des règles métier et des processus opérationnels spécifiques qui influencent la conception et le déploiement de l’intégration.

Un connecteur peut inclure une logique de synchronisation intégrée, des outils de configuration, la prise en charge de l’échange de fichiers, de la documentation et des निर्देश d’intégration. Le système du client reste la source de vérité — TWC ne possède pas et ne duplique pas les données métier. Il lit les systèmes sources, transforme les données en contenu compatible avec Wallet, puis réinjecte les analyses Wallet dans l’écosystème du client.

## Si votre logiciel n’est pas répertorié

Vous pouvez tout de même intégrer The Wallet Crew même lorsqu’aucun connecteur natif n’existe.

Utilisez cette séquence :

1. Commencez par le modèle d’intégration et identifiez où se trouvent vos données sources.
2. Déterminez si un connecteur intégré suffit ou si un connecteur personnalisé est nécessaire.
3. Mettez en œuvre le scriptage à l’exécution uniquement pour les parties qui sont réellement spécifiques à votre pile.

### Modèle d’intégration principal

Le modèle d’intégration reste le même pour tous les projets :

1. Votre système reste la source de vérité pour les données métier.
2. TWC stocke les identifiants et les données opérationnelles destinées à Wallet.
3. TWC lit et transforme les données sources en charges utiles pour Apple Wallet et Google Wallet.
4. Les événements du cycle de vie de la Carte et les analyses peuvent être renvoyés vers vos systèmes.

Ce modèle évite la duplication des données tout en maintenant les expériences Wallet à jour.

### Choisissez votre parcours d’intégration

| Situation                                                                                                                                                                      | Parcours recommandé                                                                                                                                                                                                                                            |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Votre logiciel dispose déjà d’un connecteur documenté                                                                                                                          | Utilisez la page du connecteur dans cette section                                                                                                                                                                                                              |
| Votre logiciel n’a pas de connecteur, mais vos API et événements sont disponibles                                                                                              | Utilisez [Connecteur personnalisé](/connectors/fr/custom-connector)                                                                                                                                                                                            |
| Votre intégration nécessite principalement un comportement à l’exécution (hooks de remplissage des données, hooks d’installation/désinstallation, envoi de scripts par e-mail) | Commencez par [Connecteur personnalisé](/connectors/fr/custom-connector) et poursuivez dans [Guide des connecteurs personnalisés pour développeurs](https://github.com/TheWalletCrew/docs/tree/main/developers/guides/integration-guides/custom-connectors.md) |

### Responsabilités

| Domaine de responsabilité            | Système client / partenaire                                           | The Wallet Crew                                                              |
| ------------------------------------ | --------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Propriété des données métier         | Possède les enregistrements CRM/POS/billetterie/commerce électronique | Ne remplace pas les systèmes sources                                         |
| Stratégie d’identifiants             | Définit des identifiants stables partagés entre les systèmes          | Utilise les identifiants pour résoudre et mettre à jour les données de Carte |
| Génération des charges utiles Wallet | Fournit les champs sources et les règles métier                       | Mappe les données vers les formats de Wallet Apple/Google                    |
| Livraison et mises à jour des Cartes | Déclenche les événements sources et les entrées de changement         | Orchestre les mises à jour Wallet et le cycle de vie des Cartes              |
| Scriptage d’intégration optionnel    | Met en œuvre une logique API/événement spécifique au projet           | Fournit des hooks d’exécution et le contexte d’exécution                     |

Les cartes ci-dessous couvrent chaque famille de connecteurs.

## Connecteurs CRM, fidélité et billetterie

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Image de couverture</th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>CRM et fidélité</h4></td><td>Connectez les systèmes CRM et de fidélité aux Cartes Apple Wallet et Google Wallet.</td><td><a href="/files/12849ad05ca86573fbba93751b9ce4ffe7f5a83c">/files/12849ad05ca86573fbba93751b9ce4ffe7f5a83c</a></td><td><a href="https://github.com/TheWalletCrew/docs/tree/main/connectors/README%20(1).md">https://github.com/TheWalletCrew/docs/tree/main/connectors/README%20(1).md</a></td></tr><tr><td><h4>Connecteur personnalisé</h4></td><td>Créez une intégration personnalisée lorsqu’un connecteur prêt à l’emploi n’est pas disponible.</td><td><a href="/files/25658acd960653b1aac247aff8280d3bbc88a47e">/files/25658acd960653b1aac247aff8280d3bbc88a47e</a></td><td><a href="/pages/dc3d9dfc13f94497c6651114a69624315cdfcff5">/pages/dc3d9dfc13f94497c6651114a69624315cdfcff5</a></td></tr><tr><td><h4>Commerce électronique</h4></td><td>Connectez les parcours de la boutique en ligne à la distribution des Cartes Wallet et à leur utilisation en magasin.</td><td><a href="/files/3d09d60a373b5c4845dc1c2c0afd4c546aca7248">/files/3d09d60a373b5c4845dc1c2c0afd4c546aca7248</a></td><td><a href="/pages/a03cc4f4b0b186d7d4caeb3755ba311ce2432e7a">/pages/a03cc4f4b0b186d7d4caeb3755ba311ce2432e7a</a></td></tr><tr><td><h4>Fournisseur d’e-mail</h4></td><td>Configurez la manière dont The Wallet Crew envoie les e-mails transactionnels Wallet.</td><td><a href="/files/374d5e494627a9f4c54162f7bacc6674211ebf61">/files/374d5e494627a9f4c54162f7bacc6674211ebf61</a></td><td><a href="/pages/538055b4431b6a312cf6008aa8e1db434703aa1d">/pages/538055b4431b6a312cf6008aa8e1db434703aa1d</a></td></tr><tr><td><h4>Matériel</h4></td><td>Vérifiez la compatibilité matérielle pour la validation des Cartes par code-barres, QR et NFC.</td><td><a href="/files/8fbe6da97b04ca110dc074b6a0033ecde214e33f">/files/8fbe6da97b04ca110dc074b6a0033ecde214e33f</a></td><td><a href="/pages/7e39f51665d30f04f421cf721405683d7b9cb14f">/pages/7e39f51665d30f04f421cf721405683d7b9cb14f</a></td></tr><tr><td><h4>Automatisation marketing</h4></td><td>Connectez les campagnes du cycle de vie et les mises à jour des Cartes Wallet dans les outils existants.</td><td><a href="/files/ef752306e51b13d8740e1edf346e3fdcb9dca2b0">/files/ef752306e51b13d8740e1edf346e3fdcb9dca2b0</a></td><td><a href="/pages/4486ec88ecf405325bf337ad10a3c53857378336">/pages/4486ec88ecf405325bf337ad10a3c53857378336</a></td></tr><tr><td><h4>POS</h4></td><td>Connectez les systèmes de point de vente aux Cartes Wallet pour l’identification et l’utilisation.</td><td><a href="/files/1e0f3b2ad14dfb6c5a71affbf87de2c1287e0313">/files/1e0f3b2ad14dfb6c5a71affbf87de2c1287e0313</a></td><td><a href="/pages/f89593e95cbbd8f314da77288efc0eb669c0f180">/pages/f89593e95cbbd8f314da77288efc0eb669c0f180</a></td></tr><tr><td><h4>Billetterie</h4></td><td>Distribuez et mettez à jour les billets d’événement dans Apple Wallet et Google Wallet.</td><td><a href="/files/29516a061a1b3de23188a4ac9d44f8d333455a7c">/files/29516a061a1b3de23188a4ac9d44f8d333455a7c</a></td><td><a href="/pages/af9a70b13a7fc52eb161ddf0623289e2cbbf38bf">/pages/af9a70b13a7fc52eb161ddf0623289e2cbbf38bf</a></td></tr></tbody></table>


# Fournisseur d’e-mails

Choisissez la manière dont The Wallet Crew envoie des e-mails transactionnels via SendGrid, un fournisseur pris en charge, ou un connecteur d’e-mail personnalisé.

L’équipe Wallet peut envoyer des e-mails transactionnels dans le cadre de votre parcours client. Ces e-mails sont envoyés **au nom de votre marque**, afin que les clients reconnaissent l’expéditeur et fassent confiance au message.

Cela est important pour la conversion et la sécurité. Un expéditeur de marque et authentifié réduit le risque d’hameçonnage. Cela renforce aussi la confiance lorsque les clients cliquent sur un lien « Ajouter au Wallet ».

<figure><img src="/files/e99f437c5e0a37a93bc5a6092a49f0101f586a84" alt="Example transactional email containing an Add to Wallet link"><figcaption><p>Les e-mails transactionnels peuvent distribuer une Carte ou prendre en charge les flux d’inscription et de vérification.</p></figcaption></figure>

## Quels e-mails l’équipe Wallet peut envoyer

L’envoi des e-mails dépend du parcours que vous activez. Les exemples courants incluent la distribution de Carte et les flux d’inscription.

* Un lien pour télécharger une carte de fidélité client dans Apple et Google Wallet.
* Un e-mail d’inscription lorsqu’un client s’inscrit via un formulaire.
* Un e-mail de défi pour authentifier un client (code de vérification ou lien).
* Un e-mail de confirmation après inscription ou vérification.

## Pourquoi vous devriez configurer l’identité de l’expéditeur

Lorsque vos e-mails utilisent une identité d’expéditeur qui correspond à votre marque, les clients sont moins susceptibles de se méfier du message. Lorsque l’expéditeur est correctement authentifié (SPF, DKIM, DMARC), les fournisseurs de boîtes mail sont moins susceptibles de signaler l’e-mail comme une usurpation.

En pratique, cela améliore la délivrabilité et réduit les possibilités d’hameçonnage autour des liens « télécharger votre Carte ».

{% hint style="info" %}
Si vous voulez que les clients voient `no-reply@yourbrand.com` (ou `no-reply@wallet.yourbrand.com`), prévoyez SPF/DKIM et une politique DMARC. C’est ce que les fournisseurs de boîtes mail utilisent pour valider l’expéditeur.
{% endhint %}

## Choisissez votre stratégie de fournisseur d’e-mail

L’équipe Wallet utilise **SendGrid** par défaut. Vous pouvez conserver ce choix par défaut, passer à un autre fournisseur pris en charge ou brancher votre propre passerelle.

### Par défaut : SendGrid

C’est l’option la plus rapide. Elle couvre la plupart des cas d’usage. Voir [SendGrid](/connectors/fr/email-provider/sendgrid) pour les modes pris en charge et la configuration.

Même avec SendGrid, utilisez un domaine d’envoi personnalisé qui correspond à la marque. Confirmez les enregistrements SPF, DKIM et DMARC requis pendant l’implémentation.

### Connecteurs intégrés

Utilisez ceci lorsque votre marque dispose déjà d’un fournisseur, de modèles, de rapports ou de processus de conformité en place.

Connecteurs intégrés pris en charge :

* [Adobe Marketing Cloud](/connectors/fr/email-provider/adobe-marketing-cloud)
* [Mailchimp](/connectors/fr/email-provider/mailchimp)
* [Salesforce Marketing Cloud](/connectors/fr/email-provider/salesforce-marketing-cloud)
* [SendGrid](/connectors/fr/email-provider/sendgrid)

### Connecteur personnalisé

Utilisez ceci lorsque vous avez besoin d’un fournisseur non pris en charge par les connecteurs intégrés, lorsque vous devez passer par un relais de messagerie interne, ou lorsque vous souhaitez contrôler entièrement l’envoi depuis votre backend.

L’équipe Wallet génère toujours le contenu de l’e-mail. Votre implémentation est responsable de l’appel final « send » et de son cycle de vie de livraison.

* [Extensibilité d’EmailSender](/connectors/fr/custom-connector/emailsender-extensibility)

### Fournisseurs d’e-mail non répertoriés

Un fournisseur non répertorié n’empêche pas la livraison des e-mails Wallet. L’équipe Wallet et le partenaire fournisseur peuvent définir conjointement un connecteur standard lorsque l’intégration peut prendre en charge plusieurs marques.

Pour un fournisseur spécifique à un seul locataire, utilisez un connecteur personnalisé. Le scripting du locataire appelle l’API du fournisseur ou le relais interne via [Extensibilité d’EmailSender](/connectors/fr/custom-connector/emailsender-extensibility).

## Où se trouve la configuration

Le fournisseur d’e-mail actif est sélectionné dans `/server/emails.yml` dans la configuration avancée. Chaque page de connecteur vous indique exactement quelles valeurs définir pour son type de fournisseur.

## FAQ

<details>

<summary><strong>S’agit-il d’e-mails marketing ?</strong></summary>

Non. Il s’agit d’e-mails transactionnels liés à un parcours client, comme des liens de téléchargement de Carte ou des messages de vérification.

Si vous voulez des campagnes marketing, utilisez vos outils marketing. Puis intégrez les liens de l’équipe Wallet dans leurs modèles.

</details>

<details>

<summary><strong>L’équipe Wallet peut-elle envoyer depuis notre domaine ?</strong></summary>

Oui, à condition que le domaine d’expéditeur soit correctement authentifié. Pour SendGrid, cela signifie généralement configurer SPF/DKIM et une politique DMARC pour le domaine (ou sous-domaine) que vous utilisez comme expéditeur.

</details>

<details>

<summary><strong>Quelle est la façon la plus rapide de réduire le risque d’hameçonnage ?</strong></summary>

Utilisez un domaine d’envoi aligné sur votre marque et appliquez DMARC. Évitez les domaines d’expéditeur génériques que les clients ne reconnaissent pas.

</details>

<details>

<summary><strong>Quand devons-nous utiliser l’extensibilité d’EmailSender ?</strong></summary>

Utilisez-la lorsque vous avez besoin d’un fournisseur non pris en charge par les connecteurs, lorsque vous devez acheminer via une passerelle de messagerie interne, ou lorsque vous souhaitez centraliser la logique d’envoi dans vos propres systèmes.

</details>

<details>

<summary><strong>Et si notre fournisseur d’e-mails n’est pas répertorié ?</strong></summary>

L’équipe Wallet et le partenaire fournisseur peuvent définir le périmètre d’un connecteur standard. Un fournisseur spécifique à un locataire peut également utiliser un connecteur personnalisé avec le scripting du locataire et l’API du fournisseur.

</details>


# Adobe Marketing Cloud

Envoyez les e-mails transactionnels de The Wallet Crew via Adobe Journey Optimizer, Adobe Campaign ou Marketo Engage à l’aide du fournisseur d’e-mails scripté.

Utilisez cette intégration lorsque vous voulez que The Wallet Crew envoie **des e-mails transactionnels** via un **produit marketing Adobe** que votre Brand utilise déjà.

« Adobe Marketing Cloud » n’est pas un seul produit d’e-mail. L’envoi d’e-mails dépend de ce que vous utilisez dans Adobe :

* [Adobe Journey Optimizer (AJO)](/connectors/fr/email-provider/adobe-marketing-cloud/adobe-journey-optimizer) pour les parcours déclenchés par API et les envois en quasi temps réel.
* [Adobe Campaign Transactional Messaging](/connectors/fr/email-provider/adobe-marketing-cloud/adobe-campaign-transactional-messaging) pour les événements de messagerie transactionnelle dans les piles Adobe héritées.
* [Marketo Engage (Transactional Email API)](/connectors/fr/email-provider/adobe-marketing-cloud/marketo-engage-transactional-email-api) pour les envois d’e-mails transactionnels liés aux modèles Marketo.

C’est un **connecteur basé sur des scripts.** The Wallet Crew génère quand même le contenu de l’e-mail si vous le souhaitez. Votre script délègue ensuite la livraison finale à Adobe.

Vous pouvez utiliser deux modèles de livraison :

* **The Wallet Crew génère le HTML**, et Adobe l’envoie.
* **Adobe génère le modèle**, et The Wallet Crew n’envoie que les variables.

L’architecture reste la même dans tous les cas.

* Une Brand de distribution utilise AJO pour l’orchestration, le consentement et le reporting. The Wallet Crew fournit le HTML final.
* Une Brand dispose déjà de Adobe Campaign Transactional Messaging en production. Elle y conserve la gouvernance et le reporting.
* Une équipe utilise Marketo Engage pour l’automatisation marketing et souhaite que les envois transactionnels soient visibles dans les journaux d’activité Marketo.
* Une équipe de sécurité exige que tous les e-mails sortants passent par une seule plateforme auditée. Le fournisseur de script applique cette règle.

## Avant de commencer

Vous devez implémenter l’interface de script décrite dans [Extensibilité d’EmailSender](/connectors/fr/custom-connector/emailsender-extensibility). Cette page se concentre sur ce qui change lorsque le « fournisseur derrière le script » est Adobe.

Vous aurez également besoin d’accéder à votre produit Adobe pour créer et publier tout ce qui est nécessaire à l’envoi d’e-mails (campagne, événement ou modèle). The Wallet Crew ne peut pas créer ces objets pour vous.

{% hint style="info" %}
Si vous envoyez déjà des e-mails depuis Adobe et que vous souhaitez seulement intégrer des liens « Ajouter au Wallet », vous n’avez pas besoin de cette page. Utilisez vos modèles Adobe et placez les liens The Wallet Crew derrière vos CTA. Voir [Inscription > Par e-mail](https://github.com/TheWalletCrew/docs/tree/main/enroll/via-email/README.md) pour cette approche.
{% endhint %}

## Choisissez votre produit Adobe

Chaque produit Adobe possède sa propre API, ses propres ressources et son propre modèle de gouvernance. Choisissez celui que votre organisation utilise déjà.

* [Adobe Journey Optimizer (AJO)](/connectors/fr/email-provider/adobe-marketing-cloud/adobe-journey-optimizer) est le choix habituel lorsque vous disposez de parcours déclenchés par API.
* [Adobe Campaign Transactional Messaging](/connectors/fr/email-provider/adobe-marketing-cloud/adobe-campaign-transactional-messaging) convient aux piles Adobe Campaign héritées avec événements transactionnels.
* [Marketo Engage (Transactional Email API)](/connectors/fr/email-provider/adobe-marketing-cloud/marketo-engage-transactional-email-api) est un bon choix lorsque vous voulez que les envois et l’activité soient suivis dans Marketo.

{% hint style="warning" %}
Choisissez une seule stratégie de rendu. Évitez de dupliquer le templating à la fois dans The Wallet Crew et dans Adobe.
{% endhint %}

## Activez le fournisseur d’e-mails scriptable dans The Wallet Crew

C’est l’interrupteur qui fait appeler à The Wallet Crew votre `SendEmail` implémentation.

{% stepper %}
{% step %}

#### Implémentez `runtime.scriptable.emailEngine.SendEmail`

Commencez à partir de [Extensibilité d’EmailSender](/connectors/fr/custom-connector/emailsender-extensibility) et ajoutez votre code de livraison Adobe à l’intérieur de `SendEmail`.

Assurez-vous que votre script peut accéder aux identifiants Adobe en toute sécurité. N’intégrez pas les secrets en dur dans le script.
{% endstep %}

{% step %}

#### Mettre à jour `/server/emails.yml`

Ouvrez l’éditeur de configuration avancée, puis créez ou modifiez `/server/emails.yml`.

Définissez le type de fournisseur sur `script`. Conservez `ressources` pointant vers votre répertoire de modèles d’e-mails.

{% code title="/server/emails.yml" %}

```yaml
fournisseur :
  type : script
ressources :
  - /locales/emails/
```

{% endcode %}
{% endstep %}

{% step %}

#### Déclenchez un e-mail transactionnel et vérifiez dans Adobe

Déclenchez un e-mail réel (lien de téléchargement de la Carte, e-mail de vérification ou e-mail d’inscription).

Vérifiez qu’Adobe reçoit l’appel et que le message est accepté. Puis validez la distribution dans les en-têtes de boîte aux lettres si nécessaire (SPF/DKIM/DMARC).
{% endstep %}
{% endstepper %}

## Stratégie de modèle et de culture

The Wallet Crew peut générer les modèles localement via `buildEmail`. Adobe peut également générer les modèles de son côté, selon le produit.

Choisissez l’un de ces modèles et conservez-le de manière cohérente :

* **The Wallet Crew possède le HTML.** Vous envoyez le rendu `Objet` et `Body` à Adobe.
* **Adobe possède le HTML.** Vous n’envoyez que les variables, et Adobe choisit le modèle.

Le choix de la culture reste de votre responsabilité. La plateforme fournit un `cultures` tableau. Les stratégies courantes consistent à sélectionner la première culture, à associer une culture à un asset Adobe spécifique, ou à revenir à une valeur par défaut.

## Notes de sécurité et de confidentialité

Considérez cette intégration comme une connexion serveur à serveur.

* Conservez tous les identifiants Adobe côté serveur. Ne les exposez jamais aux clients.
* Privilégiez des jetons d’accès à courte durée de vie. Faites régulièrement tourner les secrets client.
* Évitez de journaliser les corps complets des e-mails rendus. Le contenu des e-mails peut contenir des données personnelles.
* Journalisez plutôt des identifiants stables (nom du modèle, id de campagne/événement Adobe et id de corrélation).

## Dépannage

Si les e-mails cessent d’être envoyés, isolez le problème dans cet ordre :

* Confirmez `/server/emails.yml` est un YAML valide et enregistré dans le bon tenant.
* Confirmez que votre script enregistre `runtime.scriptable.emailEngine` et exporte `SendEmail`.
* Confirmez que l’authentification Adobe fonctionne (génération du jeton et scopes).
* Confirmez que l’asset Adobe est publié et appelable (campagne/parcours/événement/modèle).
* Vérifiez dans les journaux Adobe les requêtes rejetées (champs manquants, schéma non مطابق, limites de débit).

## FAQ

<details>

<summary><strong>Quelle option devons-nous choisir ?</strong></summary>

Choisissez le produit que votre organisation utilise déjà et gouverne pour les e-mails transactionnels. Si Adobe Journey Optimizer est disponible pour les envois déclenchés par API, c’est généralement le choix le plus pérenne.

</details>

<details>

<summary><strong>Peut-on changer plus tard ?</strong></summary>

Oui. Le rendu est séparé de la livraison. Si vous conservez vos modèles dans The Wallet Crew, changer le produit Adobe en aval devient surtout une modification de script.

</details>

<details>

<summary><strong>Avons-nous besoin qu’Adobe héberge les modèles ?</strong></summary>

Pas nécessairement. Vous pouvez envoyer du HTML entièrement rendu depuis The Wallet Crew, ou déléguer le rendu à Adobe. Choisissez une seule stratégie pour éviter les incohérences.

</details>

<details>

<summary><strong>Avons-nous besoin de cette intégration si nous envoyons déjà des e-mails depuis Adobe ?</strong></summary>

Pas toujours. Si votre Brand envoie déjà l’e-mail depuis Adobe et que vous souhaitez seulement ajouter des liens « Ajouter au Wallet », conservez l’e-mail entièrement dans Adobe. Intégrez ensuite les liens The Wallet Crew derrière vos CTA. Voir [Inscription > Par e-mail](https://github.com/TheWalletCrew/docs/tree/main/enroll/via-email/README.md) pour cette approche.

Utilisez le fournisseur de script uniquement lorsque vous voulez que The Wallet Crew déclenche l’envoi transactionnel et délègue la livraison finale à Adobe.

</details>

<details>

<summary><strong>Devons-nous envoyer le HTML rendu ou seulement les variables ?</strong></summary>

Envoyez le HTML rendu lorsque vous voulez que The Wallet Crew soit la source de vérité pour le contenu et les traductions des e-mails. N’envoyez que les variables lorsque votre équipe e-mail a besoin d’un contrôle total du modèle et du workflow de validation dans Adobe.

Évitez de mélanger les deux modèles selon les parcours. Cela crée des différences difficiles à déboguer entre les e-mails.

</details>

<details>

<summary><strong>Peut-on utiliser plusieurs produits Adobe en même temps ?</strong></summary>

Techniquement oui, car votre script peut router les envois comme vous le souhaitez. En pratique, choisissez un produit par tenant lorsque c’est possible. Cela rend la gouvernance, le reporting et le dépannage plus clairs.

</details>


# Adobe Journey Optimizer

Envoyez les e-mails transactionnels de Wallet Crew via Adobe Journey Optimizer (AJO) à l’aide du fournisseur d’e-mails scripté.

Utilisez cette option lorsque vous avez **Adobe Journey Optimizer (AJO)** et que vous souhaitez **des envois déclenchés par API** qui s’intègrent à une orchestration de parcours moderne.

Avant d’aller plus loin, assurez-vous de comprendre le fonctionnement du fournisseur de scripts dans The Wallet Crew. Commencez par [Adobe Marketing Cloud](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/737aad8a9ea4e25206e969b3a67043e1768501b9) et le prérequis [Extensibilité d’EmailSender](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/8ea1b38b76adae2347e104627493d1baa1373856).

### Quand utiliser cette option

Vous choisissez généralement AJO lorsque vous souhaitez des envois quasi en temps réel et que votre équipe marketing gère déjà des parcours dans AJO.

### Configuration requise dans Adobe

Créez un parcours ou une campagne déclenchés par API pouvant accepter un appel d’exécution. Configurez ensuite l’action e-mail.

Au minimum, convenez de ce que votre script envoie à AJO.

* **HTML entièrement rendu** de l’équipe Wallet Crew (`Objet`, `Body`).
* Ou **uniquement les variables de contexte**, avec le modèle géré dans AJO.

{% hint style="warning" %}
Choisissez une seule stratégie de rendu. Évitez de dupliquer le templating à la fois dans The Wallet Crew et dans Adobe.
{% endhint %}

### Notes d’implémentation (OAuth + déclencheur)

AJO utilise Adobe IMS pour OAuth2 (identifiants client). Votre script demande généralement un jeton d’accès, puis appelle le point de terminaison d’exécution AJO pour votre campagne ou votre parcours.

{% hint style="info" %}
Les points de terminaison Adobe et la forme des charges utiles dépendent de la configuration de votre organisation, de la région et de la fonctionnalité AJO que vous utilisez (parcours ou campagne). Considérez l’extrait ci-dessous comme une structure de base et adaptez-le à la documentation officielle d’Adobe pour votre version du produit.
{% endhint %}

Enregistrez ces valeurs en tant que secrets avant de tester :

* `adobe-clientId`
* `adobe-clientSecret`
* `adobe-orgId`
* `adobe-sandboxName`
* `adobe-ajo-triggerUrl` (URL complète de déclenchement AJO)
* `adobe-scope` (facultatif, selon votre configuration Adobe)

{% code title="Exemple Adobe Journey Optimizer (implémentation de SendEmail)" %}

```javascript
import { getSecret } from "neo/secrets";

const CUSTOM_DOMAIN = "wallet.brand.com";
const TENANTID = "brand";

// Adobe IMS (identifiants client OAuth2)
// Votre environnement d'exécution fournit un `fetch` personnalisé qui peut effectuer des flux d'identifiants client OAuth.
const IMS_TOKEN_URL = "https://ims-na1.adobelogin.com/ims/token/v3";

/**
 * @typedef {Object} EmailData
 * @property {string} Subject - Ligne d'objet rendue.
 * @property {string} Body - Contenu du corps rendu.
 */

/**
 * Envoyer un e-mail en utilisant le nom de modèle et les données fournis.
 * L'appelant fournit les cultures prises en charge et un rappel
 * pour construire le contenu de l'e-mail rendu.
 *
 * @param {string} recipient - Adresse e-mail cible.
 * @param {string} emailTemplate - Nom du modèle à générer.
 * @param {Object.<string, any>} data - Données du modèle transmises au script.
 * @param {string[]} cultures - Noms de culture disponibles provenant du fournisseur de cultures.
 * @param {(templateName: string) => Promise<EmailData>} buildEmail
 * Fonction de rappel qui renvoie le contenu final de l'e-mail rendu.
 *
 * @returns {Promise<void>}
 */
async function sendEmail(recipient, emailTemplate, data, cultures, buildEmail) {
  const email = recipient;
  const countryCode = data["country"] || "fr";
  const language = `${cultures[0]?.toLowerCase()?.substring(0, 2) || "fr"}_${countryCode.toLowerCase()}`;
  const customerId = data["id.customerId"];

  if (!customerId) {
    throw new Error('Champ "id.customerId" manquant dans les données de l'e-mail.');
  }

  // URL sur laquelle le client doit cliquer pour télécharger sa Carte.
  // Vous pouvez modifier le chemin pour l'adapter à votre structure de distribution.
  const url = `https://${CUSTOM_DOMAIN}/${TENANTID}/Carte?id.customerId=${encodeURIComponent(customerId)}`;

  // Facultatif : conserver le rendu de The Wallet Crew disponible.
  // Si votre modèle AJO est entièrement géré dans Adobe, vous pouvez supprimer ceci.
  const rendered = await buildEmail(emailTemplate);

  // La configuration AJO doit être fournie sous forme de secrets.
  // Utilisez une URL complète pour éviter de coder en dur des chemins spécifiques au produit dans ce script.
  // Exemple (selon la configuration) : "https://platform.adobe.io/journey/execute/<CAMPAIGN_OR_JOURNEY_ID>"
  const ajoTriggerUrl = await getSecret("adobe-ajo-triggerUrl");
  const orgId = await getSecret("adobe-orgId");
  const sandboxName = await getSecret("adobe-sandboxName");
  const clientId = await getSecret("adobe-clientId");
  const clientSecret = await getSecret("adobe-clientSecret");

  // Gardez le scope configurable. Différentes configurations Adobe nécessitent des scopes différents.
  // Exemples de valeurs observées dans la nature : "openid,AdobeID"
  let scope = "openid,AdobeID";
  try {
    scope = (await getSecret("adobe-scope")) || scope;
  } catch (e) {
    // Secret facultatif. Conservez le scope par défaut.
  }

  // Votre `fetch` d'exécution gère les identifiants client OAuth et joint le jeton.
  // Cela évite d'appeler IMS manuellement puis de transmettre le jeton Bearer.
  const result = await fetch(ajoTriggerUrl, {
    Method: "POST",
    Authentication: {
      mode: "OAuth2.0",
      grantType: "clientCredentials",
      sendCredentialsAsFormParams: true,
      accessTokenUrl: IMS_TOKEN_URL,
      clientId,
      clientSecret,
      scope,
    },
    Headers: {
      "x-api-key": clientId,
      "x-gw-ims-org-id": orgId,
      "x-sandbox-name": sandboxName,
      "Content-Type": "application/json",
    },
    Body: JSON.stringify({
      // La structure exacte du payload doit correspondre à votre configuration de campagne/parcours déclenché par l'API AJO.
      // Gardez ce contrat stable entre votre script et votre ressource AJO.
      recipient: {
        email,
        language,
      },
      context: {
        // Variable minimale pour un modèle géré par Adobe :
        url,

        // Variables facultatives si vous souhaitez réutiliser le rendu de l'équipe Wallet dans Adobe :
        subject: rendered.Subject,
        body: rendered.Body,

        // Métadonnées utiles pour le routage / le débogage :
        template: emailTemplate,
        customerId,
      },
    }),
    ThrowOnError: false,
  });

  if (result.StatusCode < 200 || result.StatusCode >= 300) {
    throw new Error(`AJO trigger call failed (${result.StatusCode}): ${result.ResponseText}`);
  }
}

export default function (context) {
  context.register("runtime.scriptable.emailEngine", {
    SendEmail: sendEmail,
  });
}
```

{% endcode %}

### Ce qu'il faut valider

// Déclenchez un véritable e-mail transactionnel, puis validez ces points :

* AJO reçoit l'appel d'exécution et l'accepte.
* L'action e-mail AJO a accès aux champs de contexte que vous envoyez.
* Si vous transmettez du HTML, l'e-mail final s'affiche correctement dans les clients courants.

### FAQ

<details>

<summary><strong>Avons-nous besoin d'un « parcours déclenché par API » dans AJO ?</strong></summary>

Oui. Votre script a besoin d'un élément AJO publié pouvant être déclenché par un appel API. Le type exact d'élément (parcours ou campagne) dépend de ce qu'utilise votre organisation Adobe.

</details>

<details>

<summary><strong>AJO peut-il envoyer un e-mail créé par l'équipe Wallet ?</strong></summary>

Oui. Une pratique courante consiste à appeler `buildEmail()` dans votre script, puis Carte `objet` et `corps` comme contexte à AJO. Votre action e-mail AJO doit être configurée pour utiliser ces champs.

</details>

<details>

<summary><strong>Comment testons-nous sans envoyer d’e-mails à de vrais clients ?</strong></summary>

Utilisez un sandbox AJO si vous en avez un. Sinon, limitez les tests aux adresses internes et créez un parcours/campagne « test » dédié. Conservez le contrat de charge utile identique à la production pour éviter les ruptures de schéma de dernière minute.

</details>

<details>

<summary><strong>Pourquoi avons-nous besoin d’autant d’en-têtes Adobe ?</strong></summary>

Les passerelles AJO nécessitent généralement des en-têtes d’organisation, de sandbox et de clé API pour le routage et l’autorisation. L’ensemble exact peut varier selon la configuration et la région Adobe, alors considérez la documentation officielle d’Adobe comme source de référence pour votre environnement.

</details>


# Messagerie transactionnelle Adobe Campaign

Envoyez les e-mails transactionnels de Wallet Crew via Adobe Campaign Transactional Messaging à l’aide du fournisseur d’e-mails scripté.

Utilisez cette option lorsque votre organisation exécute **Adobe Campaign** et utilise déjà **la messagerie transactionnelle** pour les envois de production.

Avant d’aller plus loin, assurez-vous de comprendre comment fonctionne le fournisseur de script dans The Wallet Crew. Commencez par [Adobe Marketing Cloud](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/737aad8a9ea4e25206e969b3a67043e1768501b9) et le prérequis [Extensibilité d’EmailSender](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/8ea1b38b76adae2347e104627493d1baa1373856).

### Quand utiliser ceci

C’est un bon choix si vous disposez déjà de la gouvernance Adobe Campaign, des rapports et d’événements transactionnels préexistants.

### Configuration requise dans Adobe

Créez et publiez un **Événement de message transactionnel**.

Décidez ensuite si Adobe Campaign utilisera le HTML rendu par The Wallet Crew ou construira l’e-mail final à l’aide des modèles et variables Adobe Campaign.

Vous avez également besoin d’une méthode d’authentification sécurisée côté serveur prise en charge par votre déploiement Adobe Campaign. Elle repose souvent sur Adobe I/O ou IMS.

### Notes d’implémentation (appel d’événement)

Votre script rend généralement l’e-mail (si The Wallet Crew contrôle le HTML), puis appelle le point de terminaison de l’événement transactionnel avec le destinataire et le contexte.

Stockez ces valeurs en tant que secrets avant de tester :

* `adobe-clientId`
* `adobe-clientSecret`
* `adobe-campaign-transactionalUrl` (URL complète de l’Événement de message transactionnel)
* `adobe-orgId` (facultatif, selon votre configuration Campaign)
* `adobe-scope` (facultatif, selon votre configuration Adobe)

{% code title="Exemple Adobe Campaign (implémentation SendEmail)" %}

```javascript
import { getSecret } from "neo/secrets";

const CUSTOM_DOMAIN = "wallet.brand.com";
const TENANTID = "brand";

// Adobe IMS (identifiants client OAuth2)
const IMS_TOKEN_URL = "https://ims-na1.adobelogin.com/ims/token/v3";

async function getOptionalSecret(name, fallback) {
  try {
    return (await getSecret(name)) || fallback;
  } catch (e) {
    return fallback;
  }
}

/**
 * @typedef {Object} EmailData
 * @property {string} Sujet
 * @property {string} Corps
 */

async function sendEmail(recipient, emailTemplate, data, cultures, buildEmail) {
  const email = recipient;
  const countryCode = data["country"] || "fr";
  const language = `${cultures[0]?.toLowerCase()?.substring(0, 2) || "fr"}_${countryCode.toLowerCase()}`;
  const customerId = data["id.customerId"];

  if (!customerId) {
    throw new Error('Missing "id.customerId" in email data.');
  }

  const url = `https://${CUSTOM_DOMAIN}/${TENANTID}/carte?id.customerId=${encodeURIComponent(customerId)}`;

  // Conservez la disponibilité du rendu de The Wallet Crew.
  // Si Adobe Campaign possède le modèle, vous pouvez supprimer ceci et n’envoyer que des variables.
  const rendered = await buildEmail(emailTemplate);

  const transactionalUrl = await getSecret("adobe-campaign-transactionalUrl");

  const clientId = await getSecret("adobe-clientId");
  const clientSecret = await getSecret("adobe-clientSecret");
  const scope = await getOptionalSecret("adobe-scope", "openid,AdobeID");

  // Facultatif. Certaines configurations nécessitent des en-têtes d’ID d’organisation, d’autres non.
  const orgId = await getOptionalSecret("adobe-orgId", null);

  const headers = {
    "x-api-key": clientId,
    "Content-Type": "application/json",
  };
  if (orgId) headers["x-gw-ims-org-id"] = orgId;

  const result = await fetch(transactionalUrl, {
    Method: "POST",
    Authentication: {
      mode: "OAuth2.0",
      grantType: "clientCredentials",
      sendCredentialsAsFormParams: true,
      accessTokenUrl: IMS_TOKEN_URL,
      clientId,
      clientSecret,
      scope,
    },
    Headers: headers,
    Body: JSON.stringify({
      // La charge utile doit correspondre à la définition de votre Événement de message transactionnel.
      email,
      ctx: {
        url,
        language,

        // Facultatif si vous voulez qu’Campaign utilise le rendu de The Wallet Crew :
        subject: rendered.Subject,
        body: rendered.Body,

        // Métadonnées utiles :
        template: emailTemplate,
        customerId,
      },
    }),
    ThrowOnError: false,
  });

  if (result.StatusCode < 200 || result.StatusCode >= 300) {
    throw new Error(`L’appel Adobe Campaign a échoué (${result.StatusCode}) : ${result.ResponseText}`);
  }
}

export default function (context) {
  context.register("runtime.scriptable.emailEngine", {
    SendEmail: sendEmail,
  });
}
```

{% endcode %}

### Ce qu'il faut valider

Déclenchez un véritable e-mail transactionnel, puis validez ces points :

* Votre Événement de message transactionnel est publié et appelable.
* Le schéma de charge utile correspond à la définition de l’événement.
* Adobe Campaign accepte la requête et traite le message.

### FAQ

<details>

<summary><strong>Avons-nous besoin d’un Événement de message transactionnel ?</strong></summary>

Oui. Votre script doit appeler un point de terminaison d’Événement de messagerie transactionnelle publié. Cet événement définit le schéma de charge utile attendu et les variables disponibles dans votre modèle Adobe Campaign.

</details>

<details>

<summary><strong>Adobe Campaign peut-il rendre l’e-mail au lieu de The Wallet Crew ?</strong></summary>

Oui. Dans cette configuration, votre script n’envoie que les variables (par exemple, l’URL de téléchargement de la carte et les métadonnées client). Adobe Campaign possède le HTML, l’objet et les traductions.

</details>

<details>

<summary><strong>Quelle méthode d’authentification devons-nous utiliser ?</strong></summary>

Cela dépend de votre déploiement Adobe Campaign et de la manière dont votre organisation Adobe gère l’accès serveur à serveur. Cette page présente une approche basée sur IMS car elle est courante, mais vous devez aligner la méthode d’authentification finale avec votre équipe d’administration Adobe et la documentation officielle d’Adobe pour votre environnement.

</details>

<details>

<summary><strong>Quelle est la raison la plus courante du rejet d’une requête ?</strong></summary>

Incompatibilité de schéma. La définition de l’événement est stricte. Si les champs de votre charge utile ne correspondent pas à la structure attendue par l’événement, Campaign rejettera ou ignorera des champs, et les modèles afficheront des valeurs vides.

</details>


# Marketo Engage (Transactional Email API)

Envoyez les e-mails transactionnels de Wallet Crew via Marketo Engage à l’aide du fournisseur d’e-mails scripté.

Utilisez cette option lorsque votre organisation utilise **Marketo Engage** et souhaite que les envois transactionnels soient suivis dans les journaux d’activité de Marketo.

Avant d’aller plus loin, assurez-vous de comprendre le fonctionnement du fournisseur de scripts dans The Wallet Crew. Commencez par [Adobe Marketing Cloud](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/737aad8a9ea4e25206e969b3a67043e1768501b9) et le prérequis [Extensibilité d’EmailSender](broken://spaces/rH9XqI2enbyJTGPIB8BO/pages/8ea1b38b76adae2347e104627493d1baa1373856).

### Quand utiliser cette option

Il s’agit souvent du modèle REST le plus simple, mais il suppose que vous gérez et approuvez le modèle d’e-mail dans Marketo.

### Configuration requise dans Marketo

Créez l’élément d’e-mail que vous souhaitez envoyer et faites-le approuver. Les règles d’approbation varient selon la configuration de Marketo.

Décidez ensuite comment vous mappez la sortie de The Wallet Crew :

* Utilisez des jetons ou des variables Marketo pour injecter `Objet` et `Body`.
* Ou conservez l’objet et le corps dans Marketo et ne transmettez que des données contextuelles.

### Notes d’implémentation (jeton + envoi)

Les instances Marketo sont spécifiques à une région. Votre script demande généralement un jeton d’accès Marketo, puis appelle le point de terminaison d’envoi transactionnel pour l’élément d’e-mail choisi.

Enregistrez ces valeurs en tant que secrets avant de tester :

* `marketo-baseUrl` (exemple : `https://123-ABC-456.mktorest.com`)
* `marketo-clientId`
* `marketo-clientSecret`
* `marketo-emailId` (l’identifiant de l’élément d’e-mail Marketo que vous envoyez)

{% hint style="info" %}
Les points de terminaison du jeton OAuth Marketo peuvent légèrement varier selon l’instance et la configuration. Si votre point de terminaison de jeton Marketo nécessite des paramètres de requête ou une méthode HTTP spécifique, adaptez les paramètres d’authentification en conséquence.
{% endhint %}

{% code title="Exemple Marketo Engage (implémentation SendEmail)" %}

```javascript
import { getSecret } from "neo/secrets";

const CUSTOM_DOMAIN = "wallet.brand.com";
const TENANTID = "brand";

async function sendEmail(recipient, emailTemplate, data, cultures, buildEmail) {
  const email = recipient;
  const countryCode = data["country"] || "fr";
  const language = `${cultures[0]?.toLowerCase()?.substring(0, 2) || "fr"}_${countryCode.toLowerCase()}`;
  const customerId = data["id.customerId"];

  if (!customerId) {
    throw new Error('Champ "id.customerId" manquant dans les données de l'e-mail.');
  }

  const url = `https://${CUSTOM_DOMAIN}/${TENANTID}/Carte?id.customerId=${encodeURIComponent(customerId)}`;
  const rendered = await buildEmail(emailTemplate);

  const baseUrl = await getSecret("marketo-baseUrl");
  const clientId = await getSecret("marketo-clientId");
  const clientSecret = await getSecret("marketo-clientSecret");
  const marketoEmailId = await getSecret("marketo-emailId");

  const sendUrl = `${baseUrl}/rest/v1/email/${encodeURIComponent(marketoEmailId)}/send.json`;

  // Votre `fetch` d'exécution gère les identifiants client OAuth et joint le jeton.
  const result = await fetch(sendUrl, {
    Method: "POST",
    Authentication: {
      mode: "OAuth2.0",
      grantType: "clientCredentials",
      sendCredentialsAsFormParams: true,
      accessTokenUrl: `${baseUrl}/identity/oauth/token`,
      clientId,
      clientSecret,
    },
    Headers: {
      "Content-Type": "application/json",
    },
    Body: JSON.stringify({
      input: [
        {
          email,
          variables: [
            { name: "url", value: url },
            { name: "language", value: language },
            { name: "subject", value: rendered.Subject },
            { name: "body", value: rendered.Body },
            { name: "customerId", value: customerId },
            { name: "template", value: emailTemplate },
          ],
        },
      ],
    }),
    ThrowOnError: false,
  });

  if (result.StatusCode < 200 || result.StatusCode >= 300) {
    throw new Error(`L'appel d'envoi Marketo a échoué (${result.StatusCode}) : ${result.ResponseText}`);
  }
}

export default function (context) {
  context.register("runtime.scriptable.emailEngine", {
    SendEmail: sendEmail,
  });
}
```

{% endcode %}

{% hint style="info" %}
Marketo exige que l’élément d’e-mail existe (et souvent qu’il soit approuvé) avant de pouvoir être utilisé pour les envois.
{% endhint %}

### Ce qu'il faut valider

// Déclenchez un véritable e-mail transactionnel, puis validez ces points :

* L’élément d’e-mail existe et est approuvé.
* Marketo accepte l’appel d’envoi.
* Les variables correspondent à ce qu’attend votre modèle Marketo.

### FAQ

<details>

<summary><strong>Doit-on créer le modèle d’e-mail dans Marketo ?</strong></summary>

Oui. Marketo exige un élément d’e-mail existant pour les envois transactionnels, et de nombreuses configurations exigent que l’élément soit approuvé. Votre script peut toujours transmettre des variables, mais Marketo a besoin de l’élément conteneur.

</details>

<details>

<summary><strong>The Wallet Crew peut-il toujours générer le HTML ?</strong></summary>

Oui. Vous pouvez appeler `buildEmail()` et transmettre `objet` et `corps` comme variables. Votre e-mail Marketo doit être conçu pour injecter ces variables aux bons endroits.

</details>

<details>

<summary><strong>Quelle est la façon la plus rapide de dépanner ?</strong></summary>

Vérifiez d’abord que l’élément est approuvé, puis consultez le corps de la réponse de l’API Marketo pour un code d’erreur spécifique. Si l’appel API réussit mais que l’e-mail s’affiche mal, vérifiez que votre modèle Marketo attend les mêmes noms de variables que ceux que vous envoyez.

</details>

<details>

<summary><strong>Peut-on utiliser différentes instances Marketo selon l’environnement ?</strong></summary>

Oui. Configurez différents secrets et points de terminaison par locataire (staging vs production). Conservez une nomenclature de variables cohérente entre les environnements afin d’éviter la dérive du modèle.

</details>


# Mailchimp

Configurez The Wallet Crew pour envoyer des e-mails transactionnels via Mailchimp Transactional (Mandrill).

The Wallet Crew peut envoyer des e-mails transactionnels via Mailchimp Transactional (Mandrill). Cela couvre des messages tels que les liens de téléchargement de Carte, les e-mails de vérification, etc.

Par défaut, The Wallet Crew utilise **son propre compte SendGrid**. Vous pouvez passer à **votre propre compte Mailchimp Transactional** lorsque vous souhaitez centraliser l’activité e-mail dans Mandrill, ou lorsque vous vous appuyez déjà sur Mandrill pour le suivi de la délivrabilité.

Cette configuration est limitée à l’envoi transactionnel. Elle n’intègre pas les fonctionnalités Mailchimp Marketing comme les audiences ou les campagnes.

Si vous ne savez pas quelle option choisir, commencez par [Fournisseur d’e-mails](/connectors/fr/email-provider).

## Configurez votre propre compte Mailchimp Transactional (Mandrill)

Avant de mettre à jour la configuration de The Wallet Crew, assurez-vous que Mandrill peut authentifier votre identité d’expéditeur. En pratique, cela signifie disposer d’un compte Mailchimp Transactional, générer une clé API Transactional et valider le domaine d’expéditeur ou l’adresse e-mail que vous souhaitez utiliser.

{% stepper %}
{% step %}
**Décidez du domaine d’expéditeur que vous souhaitez utiliser**

Préférez un sous-domaine dédié tel que `wallet.yourbrand.com` ou `registration.yourbrand.com`. Cela permet de garder l’authentification e-mail isolée des autres systèmes de messagerie.

{% hint style="info" %}
L’utilisation d’un sous-domaine dédié réduit l’exposition et améliore la sécurité grâce à une meilleure isolation. Nous recommandons d’utiliser le même domaine personnalisé que votre application lorsque cela a du sens pour votre configuration.
{% endhint %}
{% endstep %}

{% step %}
**Créez une clé API Transactional**

Créez une clé API dans Mailchimp Transactional (Mandrill), car The Wallet Crew l’utilise pour appeler les API d’envoi de Mandrill en votre nom.

<div data-with-frame="true"><figure><img src="/files/9f1c26248977109516fc8f4e254ebb50e6871051" alt="API configuration in Mailchimp Transactional." width="375"><figcaption><p>Configuration de l’API dans Mailchimp Transactional.</p></figcaption></figure></div>

Suivez ce guide : [Générez votre clé API](https://mailchimp.com/developer/transactional/guides/quick-start/#generate-your-api-key).
{% endstep %}

{% step %}
**Mettre à jour `/server/emails.yml`**

Ouvrez l’éditeur de configuration avancée :

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/configuration" class="button secondary" data-icon="chevrons-right">Console d’administration - Configuration avancée</a></p>

Ensuite, créez ou modifiez `/server/emails.yml`:

{% code title="/server/emails.yml" %}

```yaml
provider:
  type: mailchimp
  apiKey: md-xxxx
  from:
    email: support@yourbrand.com
    name: Support de votre marque
resources:
  - /locales/emails/
```

{% endcode %}

Remplacez `md-xxxx` par votre clé API Mandrill. Définissez ensuite les valeurs `from` sur une identité d’expéditeur acceptée par Mandrill.

{% hint style="warning" %}
Traitez votre clé API Mandrill comme un mot de passe.

Ne la collez pas dans des tickets ou des captures d’écran.
{% endhint %}
{% endstep %}

{% step %}
**Enregistrez et testez**

Enregistrez le fichier dans la console d’administration pour appliquer le changement de fournisseur. Déclenchez un seul e-mail transactionnel à partir de votre flux habituel, puis confirmez la livraison dans les journaux d’activité de Mailchimp Transactional.
{% endstep %}
{% endstepper %}

## Dépannage

La plupart des problèmes proviennent de l’utilisation du mauvais type de clé ou d’un envoi depuis une identité non vérifiée. Si l’envoi d’e-mails échoue ou que rien ne semble changer, commencez par ces vérifications :

* **Mailchimp Marketing vs Transactional**: vous devez utiliser une **Transactional (Mandrill)** clé.
* **401/403 depuis Mailchimp**: vérifiez la clé et que Transactional est activé.
* **E-mails non distribués**: vérifiez votre domaine/adresse e-mail d’expéditeur dans Mailchimp Transactional.
* **Rien ne change après modification**: confirmez que vous avez modifié `/server/emails.yml` dans le bon tenant et que vous l’avez enregistré.

## FAQ

<details>

<summary><strong>Est-ce la même chose que « e-mails marketing Mailchimp » ?</strong></summary>

**Non**. Cette intégration utilise uniquement **Mailchimp Transactional (Mandrill)** pour envoyer des messages transactionnels.

</details>

<details>

<summary><strong>Ai-je besoin d’un module complémentaire Mailchimp payant ?</strong></summary>

En général oui, car Transactional (Mandrill) est un produit distinct des forfaits Mailchimp Marketing standard.

</details>

<details>

<summary><strong>Où configurer Mailchimp dans The Wallet Crew ?</strong></summary>

Modifiez `/server/emails.yml` dans l’éditeur de configuration avancée.

</details>

<details>

<summary><strong>Devons-nous authentifier notre domaine dans Mailchimp Transactional ?</strong></summary>

**Oui**. Vérifiez l’identité d’expéditeur que vous utilisez pour `from.email` dans Mailchimp Transactional. Si vous envoyez depuis un domaine, configurez l’authentification (SPF/DKIM) et ajoutez un enregistrement DMARC pour ce domaine ou sous-domaine.

</details>

<details>

<summary><strong>Puis-je conserver SendGrid en staging et Mailchimp en production ?</strong></summary>

Oui, mais ce n’est pas recommandé.

Chaque tenant a sa propre configuration, vous pouvez donc choisir différents fournisseurs par environnement. En pratique, utiliser différents fournisseurs rend le dépannage plus difficile. Cela augmente aussi le risque de différences spécifiques au fournisseur entre le staging et la production (authentification de l’expéditeur, comportement de délivrabilité, journaux d’activité et limites de débit).

Si vous avez besoin d’un environnement de test sûr, préférez utiliser le **même fournisseur** dans les deux environnements. Utilisez un sous-domaine d’expéditeur différent (par exemple `staging.wallet.yourbrand.com`) et envoyez uniquement vers des adresses internes.

</details>

<details>

<summary><strong>Quel est le moyen le plus rapide de valider ma configuration ?</strong></summary>

Enregistrer `/server/emails.yml`, déclenchez un seul e-mail, puis vérifiez l’événement dans les journaux d’activité de Mailchimp Transactional.

</details>


# Salesforce Marketing Cloud

Configurez The Wallet Crew pour envoyer des e-mails transactionnels via Salesforce Marketing Cloud.

Utilisez ce connecteur lorsque vous souhaitez que The Wallet Crew envoie **des e-mails transactionnels** via **Salesforce Marketing Cloud**, tandis que Salesforce Marketing Cloud reste l’endroit où votre marque gère les ressources d’e-mails, le suivi et les rapports.

Cette intégration utilise le **fournisseur d’e-mails script**. The Wallet Crew déclenche l’envoi. Votre script transmet l’événement à Salesforce Marketing Cloud.

## Fonctionnement

The Wallet Crew appelle votre implémentation de `runtime.scriptable.emailEngine.SendEmail`. Votre script appelle ensuite l’API REST de Salesforce Marketing Cloud pour déclencher un événement (en utilisant un `EventDefinitionKey`). Salesforce Marketing Cloud utilise cette charge utile d’événement pour générer et envoyer l’e-mail.

Ce modèle évite de dupliquer les modèles. Salesforce Marketing Cloud possède le modèle. The Wallet Crew envoie uniquement les variables dont Salesforce Marketing Cloud a besoin, comme l’URL de téléchargement de la Carte et le libellé de CTA localisé.

Si vous n’avez pas encore configuré le fournisseur script, commencez par [Extensibilité d’EmailSender](/connectors/fr/custom-connector/emailsender-extensibility).

## Avant de commencer

Vous avez besoin de trois éléments :

* Un Salesforce Marketing Cloud **Package installé** pouvant appeler des API REST (ID client + secret client).
* Une ressource Salesforce Marketing Cloud qui peut être **déclenchée par l’API**, exposant un `EventDefinitionKey`.
* Un identifiant stable dans votre charge utile d’e-mail Wallet Crew (exemple : `id.customerId`) pour générer l’URL de la Carte.

## Configuration requise dans Salesforce Marketing Cloud

Dans Salesforce Marketing Cloud, créez un point d’entrée déclenché par API et le contenu d’e-mail associé.

1. Créez un **Package installé** et conservez le **Client Id** et **Client Secret**.
2. Créez la ressource d’envoi que vous souhaitez déclencher (généralement un événement d’entrée de parcours ou un événement API), puis copiez son `EventDefinitionKey`.
3. Assurez-vous que votre modèle d’e-mail Salesforce Marketing Cloud attend les mêmes noms de variables que vous enverrez dans `Data`.

{% hint style="info" %}
La configuration de Salesforce Marketing Cloud varie selon la configuration du compte et l’ensemble de fonctionnalités. Conservez un contrat de charge utile stable : les noms de champ dans `Data` doivent correspondre à ce que votre ressource Salesforce Marketing Cloud attend.
{% endhint %}

## Activez Salesforce Marketing Cloud dans The Wallet Crew

Définissez le fournisseur sur `script` afin que The Wallet Crew appelle votre `SendEmail` implémentation.

{% code title="/server/emails.yml" %}

```yaml
fournisseur :
  type : script
ressources :
  - /locales/emails/
```

{% endcode %}

### Exemple de script (déclencher un événement Salesforce Marketing Cloud)

Cet exemple déclenche un événement Salesforce Marketing Cloud en utilisant le point de terminaison REST `interaction/v1/events`. Il envoie un titre localisé, un libellé de CTA localisé et une URL de la Carte Wallet Crew construite à partir d’un identifiant client.

{% hint style="warning" %}
Cette implémentation délègue le rendu à Salesforce Marketing Cloud. L'équipe Wallet `buildEmail()` le callback n'est volontairement pas utilisé.
{% endhint %}

{% code title="Exemple Salesforce Marketing Cloud (implémentation SendEmail)" %}

```javascript
const CUSTOM_DOMAIN = "wallet.brand.com";
const TENANTID = "brand";
const SMFC_DOMAIN = "xxx";

/**
 * @typedef {Object} EmailData
 * @property {string} Subject - Ligne d'objet rendue.
 * @property {string} Body - Contenu du corps rendu.
 */

/**
 * Envoyer un e-mail en utilisant le nom de modèle et les données fournis.
 * L'appelant fournit les cultures prises en charge et un rappel
 * pour construire le contenu de l'e-mail rendu.
 *
 * @param {string} recipient - Adresse e-mail cible.
 * @param {string} emailTemplate - Nom du modèle à générer.
 * @param {Object.<string, any>} data - Données du modèle transmises au script.
 * @param {string[]} cultures - Noms de culture disponibles provenant du fournisseur de cultures.
 * @param {(templateName: string) => Promise<EmailData>} buildEmail
 * Fonction de rappel qui renvoie le contenu final de l'e-mail rendu.
 *
 * @returns {Promise<void>}
 */
async function sendEmail(recipient, emailTemplate, data, cultures, buildEmail){

  const customerId = data["id.customerId"];
  const url = `https://${CUSTOM_DOMAIN}/${TENANTID}/Carte?id.customerId=${customerId}`;  

  const locales = {
    "en": {
      title: "🎉 Votre compte est prêt – Ajoutez votre Carte au Wallet !",
      label: "Ajouter au Wallet"
    },
    "fr": {
      title: "🎉 Votre compte est prêt – Ajoutez votre Carte au Wallet !",
      label: "Ajouter au Wallet"
    }
  };

  const locale = locales[cultures[0]];

  const response = await fetch(`https://${SMFC_DOMAIN}.rest.marketingcloudapis.com/interaction/v1/events`,  {
    Méthode : "POST", 
    Authentification : {
        mode : 'OAuth2.0', 
        grantType : 'clientCredentials',
        accessTokenUrl : `https://${SMFC_DOMAIN}.auth.marketingcloudapis.com/v2/token`, 
        sendCredentialsAsFormParams: true,
        clientId: await getSecret('SFMC-CLIENTID'), 
        clientSecret : await getSecret('SFMC-CLIENTSECRET')
    }, 
    Headers: {
      "Content-Type": "application/json",
    },
    Body: {
      "ContactKey": recipient,
      "EventDefinitionKey": "confirmationCompteNeostore",
      "Data": {
          "SubscriberKey": recipient,
          "EmailAddress": recipient,
          "Title": locale.title,
          "Url": url,
          "LabelCTA": locale.label,
      }
    }
  });
  const responseData = JSON.parse(response.ResponseText); 
  if(!responseData?.eventInstanceId){
    throw new Error(`erreur lors de l'envoi du statut de l'e-mail personnalisé : ${response.StatusCode} - contenu : ${response.ResponseText}`)
  }
}

export default function(context) {
  context.register('runtime.scriptable.emailEngine', {
    SendEmail: sendEmail 
  })
}
```

{% endcode %}

### Ce qu'il faut valider

Déclenchez un véritable e-mail transactionnel, puis validez de bout en bout :

* Wallet Crew appelle votre script sans erreurs.
* L'appel à l'API Salesforce Marketing Cloud renvoie un `eventInstanceId`.
* Salesforce Marketing Cloud rend l'e-mail avec `Titre`, `URL`, et `LabelCTA`.
* Le CTA ouvre l'URL de Wallet Crew et la carte peut être installée.

## Dépannage

Si l'envoi échoue, isolez le problème dans cet ordre :

* **L'authentification OAuth échoue (401/403)**: l'ID client/secret est incorrect, révoqué, ou le package installé n'a pas accès à l'API.
* **Aucun `eventInstanceId`**: le `EventDefinitionKey` est invalide, non publié, ou le schéma du payload est rejeté.
* **Variables vides dans l'e-mail**: le modèle Salesforce Marketing Cloud attend des noms de champs différents de ceux que vous envoyez dans `Data`.
* **Langue incorrecte**: `cultures[0]` ne correspond pas à votre mappage de paramètres régionaux. Ajoutez un repli (par exemple : définir par défaut sur `en`).

## FAQ

<details>

<summary><strong>Qui possède le HTML de l'e-mail, Salesforce Marketing Cloud ou Wallet Crew ?</strong></summary>

Salesforce Marketing Cloud possède le HTML dans ce modèle. Wallet Crew n'envoie que des variables (titre, libellé du CTA, URL) afin que votre équipe marketing puisse faire évoluer le modèle sans déployer de modifications Wallet Crew.

</details>

<details>

<summary><strong>Peut-on toujours utiliser les modèles Wallet Crew et <code>buildEmail()</code>?</strong></summary>

Oui, mais cela devient une stratégie différente. Dans ce modèle, Wallet Crew rend `Objet` et `Body`, et Salesforce Marketing Cloud est utilisé uniquement comme passerelle de diffusion. Si vous souhaitez cela, alignez l'asset Salesforce Marketing Cloud pour accepter le HTML rendu et éviter le double templating.

</details>

<details>

<summary><strong>Où stockons-nous les identifiants SFMC ?</strong></summary>

Stockez-les en tant que secrets du tenant et chargez-les à l'exécution (comme dans l'exemple avec `getSecret('SFMC-CLIENTID')` et `getSecret('SFMC-CLIENTSECRET')`). Ne codez pas les identifiants en dur dans les scripts.

</details>

<details>

<summary><strong>Que devons-nous utiliser comme <code>ContactKey</code>?</strong></summary>

Utilisez un identifiant de contact Salesforce Marketing Cloud stable. De nombreuses marques utilisent l'adresse e-mail, mais vous pouvez aussi utiliser un identifiant CRM si cela correspond à votre stratégie de clé de contact Salesforce Marketing Cloud. Gardez-le cohérent avec la manière dont votre Journey/asset résout les destinataires.

</details>


# SendGrid

Configurez la manière dont The Wallet Crew envoie des e-mails transactionnels avec SendGrid.

Le Wallet Crew peut envoyer des e-mails transactionnels via SendGrid. Cela couvre des messages comme les liens de téléchargement de Carte, les e-mails de vérification, etc.

Par défaut, The Wallet Crew utilise **son propre compte SendGrid**. Vous pouvez passer à **votre propre compte SendGrid** lorsque vous avez besoin d’un contrôle total sur la délivrabilité, la réputation et la facturation.

Si vous ne savez pas quelle option choisir, commencez par [Fournisseur d’e-mails](/connectors/fr/email-provider).

### Option 1 : Utiliser le compte SendGrid du Wallet Crew

C’est l’option la plus simple, et c’est celle par défaut. Vous n’avez pas besoin de créer un compte SendGrid ni de gérer des clés API. Le Wallet Crew s’occupe de tout.

Si vous voulez que les clients voient votre marque dans leur boîte de réception, activez un **domaine d’envoi personnalisé**. Cela améliore la délivrabilité. Cela réduit aussi les risques d’usurpation et de phishing.

{% hint style="info" %}
Lorsque vous utilisez le compte SendGrid du Wallet Crew, Le Wallet Crew doit activer le domaine d’envoi personnalisé de son côté. Vous devrez quand même ajouter des enregistrements DNS (SPF/DKIM, et idéalement DMARC) sur votre domaine.
{% endhint %}

{% stepper %}
{% step %}

#### Décidez du domaine d’expéditeur que vous souhaitez utiliser

Préférez un sous-domaine dédié tel que `wallet.yourbrand.com` ou `registration.yourbrand.com`. Cela permet de garder l’authentification e-mail isolée des autres systèmes de messagerie.

{% hint style="info" %}
Déléguer un sous-domaine dédié réduit votre surface d’attaque et améliore la sécurité en isolant le trafic lié à Carte. Nous recommandons d’utiliser le même domaine personnalisé que votre application.
{% endhint %}
{% endstep %}

{% step %}

#### Demandez au support d’activer votre domaine d’envoi

Contactez le support du Wallet Crew avec le sous-domaine que vous souhaitez utiliser. L’équipe fournira les enregistrements DNS à ajouter et activera le domaine dans SendGrid.
{% endstep %}

{% step %}

#### Configurer le DNS (SPF, DKIM, DMARC)

Ajoutez les enregistrements DNS fournis par Le Wallet Crew, puis attendez la propagation du DNS.

Pour le processus général et pour comprendre pourquoi c’est important, voir [Configuration du domaine personnalisé](https://github.com/TheWalletCrew/docs/tree/main/configure/platform/configuring-custom-domain.md).
{% endstep %}

{% step %}

#### Tester un envoi réel

Déclenchez un e-mail transactionnel et confirmez :

* l’e-mail est bien distribué (non bloqué ou mis en quarantaine)
* l’expéditeur visible correspond au domaine que vous avez prévu
* SPF/DKIM passent (vérifiez dans les en-têtes de votre boîte mail si nécessaire)
  {% endstep %}
  {% endstepper %}

### Option 2 : Utiliser votre propre compte SendGrid

{% stepper %}
{% step %}

#### Créer une clé API SendGrid

Dans SendGrid, allez dans `Paramètres` → `Clés API`. Créez une clé API avec les **autorisations d’envoi de mails** .
{% endstep %}

{% step %}

#### Mettre à jour `/server/emails.yml`

Ouvrez l’éditeur de configuration avancée :

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/settings/configuration" class="button secondary">Administration du Wallet Crew - Configuration avancée</a></p>

Ensuite, créez ou modifiez `/server/emails.yml`.

{% code title="/server/emails.yml" %}

```yaml
fournisseur :
  type : sendgrid
  apiKey : YOUR_SENDGRID_API_KEY
  from:
    email : no-reply@yourbrand.com
    name : Your Brand
ressources :
  - /locales/emails/
```

{% endcode %}

Utilisez un `from.email` appartenant à un domaine que vous authentifiez dans SendGrid.

{% hint style="warning" %}
Traitez votre clé API SendGrid comme un mot de passe.

Ne la collez pas dans des tickets ou des captures d’écran.
{% endhint %}
{% endstep %}

{% step %}

#### Configurer l’authentification de l’expéditeur dans SendGrid

Authentifiez votre domaine d’envoi dans SendGrid en utilisant le flux standard « Authentification de domaine ». Cela configure SPF et DKIM. Ajoutez un enregistrement DMARC pour votre domaine d’envoi si nécessaire. Cela améliore la délivrabilité et réduit le risque d’usurpation.
{% endstep %}

{% step %}

#### Enregistrez et testez

Enregistrez le fichier. Déclenchez un seul e-mail transactionnel. Vérifiez l’événement dans vos journaux d’activité SendGrid.
{% endstep %}
{% endstepper %}

## Dépannage

* Si SendGrid renvoie **401** ou **403**, votre clé API est invalide ou ne dispose pas des autorisations nécessaires.
* Si l’adresse « from » est rejetée, votre domaine n’est pas authentifié. Vérifiez d’abord SPF et DKIM.
* Si les e-mails finissent dans les spams, revérifiez l’authentification, la stratégie DMARC et la réputation de l’expéditeur.
* Si rien ne change après modification, confirmez que vous avez enregistré le bon fichier de locataire. Le fichier doit être `/server/emails.yml`.

## FAQ

<details>

<summary><strong>Où puis-je configurer SendGrid dans Le Wallet Crew ?</strong></summary>

Modifiez `/server/emails.yml` dans l’éditeur de configuration avancée.

</details>

<details>

<summary><strong>Pouvons-nous conserver le compte SendGrid du Wallet Crew au lieu d’utiliser le nôtre ?</strong></summary>

**Oui**. Le Wallet Crew utilise par défaut sa propre configuration SendGrid.

Si vous le conservez, vous pouvez quand même envoyer depuis un domaine que vous contrôlez. Demandez au support d’activer un domaine d’envoi personnalisé, puis configurez SPF/DKIM et DMARC sur votre DNS.

</details>

<details>

<summary><strong>Faut-il authentifier notre domaine dans SendGrid ?</strong></summary>

**Oui**. Activez l’authentification de domaine SendGrid (SPF/DKIM). Ajoutez aussi un enregistrement DMARC pour le domaine ou sous-domaine que vous utilisez pour `from.email`.

</details>

<details>

<summary><strong>Pouvons-nous utiliser différents comptes SendGrid par environnement ?</strong></summary>

Oui. Chaque locataire a sa propre configuration. Vous pouvez utiliser différentes clés API par locataire.

</details>

<details>

<summary><strong>Quel est le moyen le plus rapide de valider l’intégration ?</strong></summary>

Enregistrer `/server/emails.yml`, déclenchez un seul e-mail transactionnel, puis vérifiez-le dans votre flux d’activité SendGrid.

</details>


# Point de vente (POS)

Connectez les systèmes POS à The Wallet Crew afin que les cartes Wallet puissent être identifiées, validées et mises à jour depuis les parcours de paiement et d’utilisation.

Les systèmes POS sont la source opérationnelle des événements d’encaissement et de rédemption. L’équipe Wallet relie ces systèmes à Apple Wallet et Google Wallet afin que les cartes restent utilisables au moment de la transaction.

Cela compte, car le wallet n’est pas seulement un canal de distribution. Au point de vente, la carte doit être lisible, reconnue et alignée sur les dernières règles métier.

## Comment fonctionnent les intégrations POS

Dans une intégration POS :

1. Le POS reste la source de vérité pour les données de transaction et de rédemption.
2. L’équipe Wallet fait correspondre les identifiants et les données de carte à des charges utiles compatibles avec Wallet.
3. Les mises à jour Wallet reflètent les changements d’état qui comptent au moment de l’encaissement ou après la rédemption.

Cela conserve la logique opérationnelle dans les systèmes existants tout en rendant les cartes Wallet fiables en magasin.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un commerçant scanne une carte de fidélité à la caisse, puis actualise le solde de points.
* L’utilisation d’une carte-cadeau modifie immédiatement le solde de la carte après le paiement.
* Un comptoir de service valide une carte d’adhésion avant d’appliquer ses avantages.

</details>

### Ce que couvrent généralement les intégrations POS

Les intégrations POS typiques incluent :

* l’identification de la carte à la caisse ou au comptoir de service
* les événements d’utilisation et les mises à jour d’état après utilisation
* la synchronisation facultative des soldes, de l’éligibilité ou des compteurs d’utilisation

### Connecteurs POS disponibles

Les guides de connecteurs disponibles couvrent les plateformes POS suivantes :

* [Adyen](/connectors/fr/pos/adyen)
* [Cegid](/connectors/fr/pos/cegid)
* [Newstore](/connectors/fr/pos/newstore)
* [Openbravo](/connectors/fr/pos/openbravo)
* [Shopify POS](/connectors/fr/pos/shopify-pos)
* [Square](/connectors/fr/pos/square)
* [TCPOS](/connectors/fr/pos/tcpos)

Chaque guide documente la configuration spécifique à la plateforme et les comportements pris en charge.

### Systèmes POS non répertoriés

Un POS non répertorié peut devenir un connecteur standard. L’équipe Wallet et le partenaire POS définissent conjointement cette option lorsque l’intégration peut prendre en charge plusieurs marques.

Pour un POS spécifique à un locataire, utilisez un [connecteur personnalisé](/connectors/fr/custom-connector). Le scripting du locataire peut appeler des API privées et appliquer des règles de mappage propriétaires. Définissez l’identifiant, le contrat d’API, le modèle de déclenchement et le responsable opérationnel avant l’implémentation.

### Responsabilités

| Zone de responsabilité                               | Système POS ou partenaire                                                      | Wallet Crew                                                                |
| ---------------------------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| Source de vérité des transactions et des rédemptions | Possède les enregistrements opérationnels et les règles de validation métier   | Ne remplace pas la logique métier du POS                                   |
| Gouvernance des identifiants                         | Définit des identifiants stables utilisés au moment du scan ou de la recherche | Utilise les identifiants pour résoudre et mettre à jour les cartes         |
| Cycle de vie des charges utiles Wallet               | Fournit des entrées d’événements et de données                                 | Génère et met à jour les charges utiles pour Apple Wallet et Google Wallet |
| Logique personnalisée facultative                    | Met en œuvre des flux propriétaires spécifiques au POS                         | Fournit des hooks d’exécution et l’orchestration du Wallet                 |

### FAQ

<details>

<summary><strong>Le POS reste-t-il la source de vérité ?</strong></summary>

Oui. L’équipe Wallet étend les données POS aux expériences Wallet, mais la logique de transaction et l’autorité de rédemption restent dans la pile POS.

</details>

<details>

<summary><strong>Pouvons-nous intégrer si notre POS n’est pas documenté ici ?</strong></summary>

Oui. L’équipe Wallet et le partenaire POS peuvent définir un connecteur standard. Pour des flux spécifiques au projet, utilisez un [connecteur personnalisé](/connectors/fr/custom-connector).

</details>

<details>

<summary><strong>Que faut-il valider avant un déploiement POS ?</strong></summary>

Validez l’identifiant de la carte, le parcours de scan, l’autorité de rédemption et le déclencheur de mise à jour de la carte. Testez le flux avec le matériel de scan de production avant le déploiement.

</details>

<details>

<summary><strong>Que faut-il décider en premier dans un projet POS ?</strong></summary>

Commencez par la stratégie d’identifiants, la responsabilité du flux de rédemption et les déclencheurs de mise à jour. Ces trois décisions définissent la majeure partie de la structure de l’implémentation.

</details>


# Adyen

## Afficher un code QR sur un terminal Adyen

Vous pouvez configurer un terminal Adyen pour afficher un code QR en suivant ces étapes

#### Exemple

<div data-with-frame="true"><figure><img src="/files/c4c8a8bfb90eeb0b5b3b0afb705518bc9c03d641" alt="Example" width="375"><figcaption></figcaption></figure></div>

### Prérequis

* Assurez-vous d’avoir accès à la [espace client Adyen](https://ca-live.adyen.com/ca/ca/overview/default.shtml).
* Obtenez l’image du code QR spécifique à votre magasin depuis la console d’administration The Wallet Crew (détails ci-dessous).

### Étapes pour configurer le code QR sur le terminal Adyen

1. **Connectez-vous à l’espace client Adyen**\
   Accédez à votre compte Adyen en utilisant le lien suivant :\
   [espace client Adyen](https://ca-live.adyen.com/ca/ca/overview/default.shtml){target="\_blank"}.
2. **Accédez aux paramètres du terminal**
   * Accédez à la **`Paiements en personne`** section.
   * Sélectionner **`Paramètres du terminal`** dans le menu.
   * Puis **`Personnalisation`** menu
3. **Téléchargez le code QR depuis The Wallet Crew**
   * Pour obtenir le code QR spécifique à votre magasin, accédez à la console d’administration The Wallet Crew ici :\
     [Redirections - Console d’administration The Wallet Crew](https://admin.thewalletcrew.io/tenant/~/tools/redirects)
   * Téléchargez l’image du code QR et enregistrez-la dans un emplacement accessible.
4. **Téléversez l’image du code QR**
   * Repérez la **`Logo`** section dans les paramètres du terminal.
   * Téléversez l’image du code QR.

{% hint style="info" %}
Les exigences de taille pour l’image du code QR dépendent du modèle de terminal spécifique. Reportez-vous à la documentation Adyen pour connaître les dimensions exactes.
{% endhint %}

<figure><img src="/files/b520c4ec580a5d56afea86cb65c8e43169bd0e02" alt="The size requirements for the QR code image depend on the specific terminal model. Refer to the Adye"><figcaption></figcaption></figure>

## Comment configurer les terminaux Adyen pour les notifications de carte de fidélité Apple Wallet à l’aide de la technologie Beacon

À l’aide de **la technologie Beacon** ([pour en savoir plus dans la documentation d’Apple](https://developer.apple.com/ibeacon/)), vous pouvez configurer les terminaux Adyen pour envoyer des notifications aux iPhone à proximité avec une carte de fidélité Apple Wallet lorsqu’ils se trouvent à portée (par ex., 50 cm). Voici comment le configurer.

#### Amélioration des notifications de carte de fidélité avec Adyen et Apple Wallet

Les terminaux Adyen équipés de la technologie beacon permettent d’interagir de manière fluide avec les clients en envoyant en temps réel des notifications à leurs cartes de fidélité Apple Wallet. Cette intégration est un outil puissant pour les entreprises afin d’améliorer l’expérience client et de stimuler l’engagement dans le programme de fidélité.

**Principaux avantages :**

* **Engagement en temps réel :** Informez les clients des avantages fidélité ou des offres promotionnelles lorsqu’ils s’approchent du terminal.
* **Intégration transparente :** Fonctionne directement avec Apple Wallet et les terminaux Adyen.
* **Notifications personnalisables :** Adaptez les messages au ton et au contexte de votre marque.

#### Exemple

<figure><img src="/files/ed6890117de70de74d35275dcb2425b311cc577c" alt="Example (2)"><figcaption></figcaption></figure>

### Étapes pour configurer la technologie Beacon

**1. Connectez-vous à l’espace client Adyen**

* Accédez à votre compte Adyen : [espace client Adyen](https://ca-live.adyen.com/ca/ca/overview/default.shtml){target="\_blank"}.

**2. Activez les balises dans les paramètres du terminal Adyen**

* Accédez à la **`Paiements en personne`** section.
* Sélectionner **`Paramètres du terminal`** puis accédez à l’onglet **`Connectivité`** .
* Dans la **`Beacon`** section :
  * **Activer les balises** en basculant l’option.
  * Spécifiez un **UUID**. Vous pouvez en générer un nouveau avec le bouton de réinitialisation de neostore ou en utiliser un existant à partir d’une configuration de balise existante.
  * Définissez l' **Majeur** et **Mineur** valeurs (tout nombre entre 0 et 65535).

<figure><img src="/files/434e5fdd584cd7bd9a5885e620528816bf79cf2e" alt="Major"><figcaption></figcaption></figure>

**3. Configurez les paramètres Beacon dans The Wallet Crew**

* Connectez-vous à la [Console d’administration The Wallet Crew](https://admin.neostore.cloud/tenant/~/passTypes).
* Modifiez un **Modèle**:
  * Ouvrez **`Apple`** .
  * Accédez à la **`Beacon`** section.
  * Saisissez les mêmes **UUID**, **Majeur**, et **Mineur** valeurs configurées dans la console d’administration Adyen.
  * Spécifiez un **Libellé**. C’est le texte qui s’affichera dans la notification iPhone.

<figure><img src="/files/c71ba37edd490007e84461ee4d65dbbaa7cf2238" alt="Label"><figcaption></figcaption></figure>

**4. Testez la configuration Beacon**

Lorsqu’un iPhone se trouve à portée (environ 50 cm) du terminal Adyen configuré, une notification devrait apparaître en affichant le texte du libellé.

> **Conseil de pro :** Si la notification n’apparaît pas comme prévu, assurez-vous que les paramètres de balise sont cohérents entre les configurations Adyen et The Wallet Crew. Utilisez un environnement de test pour affiner les configurations avant le déploiement en production.

### Optimisation des notifications pour les cartes de fidélité Apple Wallet

* **Personnalisez votre message :** Assurez-vous que le texte de la notification trouve un écho auprès de votre audience. Utilisez des accroches promotionnelles ou des récompenses de fidélité pour encourager l’engagement.
* **Exploitez les analyses :** Utilisez les outils de reporting d’Adyen pour suivre l’engagement et affiner les stratégies en fonction des interactions des clients.
* **Restez à jour :** Mettez régulièrement à jour vos paramètres de balise afin qu’ils reflètent les campagnes saisonnières ou les évolutions de l’entreprise.

### Notes supplémentaires

* La plage de test et la compatibilité peuvent varier selon l’environnement et le modèle d’iPhone. Ajustez les paramètres si nécessaire.
* Reportez-vous à [la documentation d’Apple sur la technologie Beacon](https://developer.apple.com/ibeacon/) pour la personnalisation avancée et le dépannage.

En utilisant les terminaux Adyen avec les cartes de fidélité Apple Wallet et la technologie beacon, les entreprises peuvent offrir des expériences client inégalées, favoriser les visites répétées et accroître la participation au programme de fidélité.


# Cegid


# Livestore

Ce guide explique comment activer l' **formulaire client externe** extension dans **Cegid Retail Live Store**.

Une fois activé, LiveStore ouvre un formulaire d'inscription hébergé par The Wallet Crew lorsque le personnel crée ou modifie un client. Après soumission, le personnel est redirigé vers la page de détails du client LiveStore. Vous pouvez également activer un mode code QR afin que les clients puissent terminer l'inscription sur leur propre téléphone.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Un vendeur crée un nouveau client fidélité dans Live Store. Le formulaire The Wallet Crew collecte les données et crée le client dans Cegid Y2.
* Un vendeur modifie un client existant. Le formulaire The Wallet Crew met à jour le client dans Cegid Y2, puis revient à la page de détails du client.
* Un magasin utilise une tablette à l'entrée. Un client scanne un code QR et termine l'inscription dans un parcours en libre-service.

</details>

### Prérequis

Vous devez avoir accès pour configurer à la fois Live Store et The Wallet Crew.

Du côté de Cegid, vous devez avoir l'autorisation de modifier **newpossettings** au **global**, **country**, ou **store** niveau.

Du côté de The Wallet Crew, votre locataire doit avoir le connecteur **Cegid Retail Y2 connector** configuré et fonctionnel.

* Si vous n'avez pas encore connecté Y2, commencez par [Connect with Cegid Retail Y2](/connectors/fr/pos/cegid/connect-with-cegid-retail-y2).
* Si vous devez vérifier quels champs client sont synchronisés, consultez [Cegid Retail Y2 fields mapping](/connectors/fr/pos/cegid/cegid-retail-y2-fields-mapping).

### Configuration

{% stepper %}
{% step %}

#### Créer une clé API dans The Wallet Crew

Créez une clé API que Live Store utilisera pour appeler les points de terminaison de The Wallet Crew.

1. Ouvrez la page de gestion des clés API

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/apiKeys" class="button secondary" data-icon="chevrons-right">gestion des clés API</a><br></p>

2. Créez une nouvelle clé API avec le périmètre `tenant.y2.listener`.
3. Copiez la valeur générée et stockez-la dans votre gestionnaire de secrets.

Vous l'utiliserez comme `X-API-KEY` en-tête dans la configuration de LiveStore.
{% endstep %}

{% step %}

#### Configurer The Wallet Crew (runtime)

Cette extension nécessite une configuration spécifique à LiveStore dans le runtime de votre locataire.

Mettez à jour votre configuration du runtime :

1. Dans la configuration avancée, dans le fichier `security.yml`, ajoutez un challenger de compte de type `livestore`.
2. Mettez à jour votre flux d'inscription pour ajouter un `livestore` élément de flux.
3. Créer `server/livestore.yml`:

```yaml
layout: mobile_ls
useTabletMode: false
provider: y2
customerRedirectLayout: mobile_livestore
```

4. Créez ou mettez à jour les deux layouts référencés (`mobile_ls` et `mobile_livestore`).
   {% endstep %}

{% step %}

#### Configurer Live Store (newpossettings)

Ouvrez l'administration newpossettings dans votre environnement Live Store :

* Test : `https://<your-tenant>-test-retail-ondemand.cegid.cloud/Y2/newpossettings/`
* Prod : `https://<your-tenant>-retail-ondemand.cegid.cloud/Y2/newpossettings/`

Configurez l'extension au **global**, **country**, ou **store** niveau. Elle n'est pas disponible au niveau de la caisse.

<div data-with-frame="true"><figure><img src="/files/bdf3fad0018d5ad837bc45f8dc463e0de5fcb4c7" alt="Cegid newpossettings scope selection showing Global, Country, and Store level configuration."><figcaption><p>Choisissez le périmètre dans lequel l'extension s'applique (global, country ou store).</p></figcaption></figure></div>

Définissez l' `LiveStore_Connector_ExternalCustomerForm` avec les valeurs de votre locataire :

{% tabs %}
{% tab title="Production" %}

```yaml
apiEndpoint: https://app.neostore.cloud/api/<YOUR_TENANTID>/external/livestore/session
endpoint: https://app.neostore.cloud/api/<YOUR_TENANTID>/external/livestore
headerName: X-API-KEY
headerValue: <YOUR_API_KEY>
```

{% hint style="info" %}
N'oubliez pas de remplacer \<YOUR\_TENANTID> et \<YOUR\_API\_KEY> par la valeur associée
{% endhint %}

{% hint style="info" %}
Si vous avez configuré un domaine personnalisé, remplacez app.neostore.cloud par votre domaine personnalisé
{% endhint %}
{% endtab %}

{% tab title="Préproduction" %}

```yaml
active: true
apiEndpoint: https://app-qa.neostore.cloud/api/<YOUR_TENANTID>/external/livestore/session
endpoint: https://app-qa.neostore.cloud/api/<YOUR_TENANTID>/external/livestore
headerName: X-API-KEY
headerValue: <YOUR_API_KEY>
```

{% hint style="info" %}
N'oubliez pas de remplacer \<YOUR\_TENANTID> et \<YOUR\_API\_KEY> par la valeur associée
{% endhint %}
{% endtab %}
{% endtabs %}

Si vous devez cibler un magasin spécifique, définissez l'extension au niveau du magasin et ajoutez `storeId`:

```yaml
endpoint: https://app.neostore.cloud/api/<tenantId>/external/livestore?storeId=<storeId>
```

{% endstep %}

{% step %}

#### Valider le flux

Validez d'abord dans un environnement de test.

1. Dans Live Store, ouvrez l'écran de création ou de modification du client.
2. Confirmez que Live Store redirige vers le formulaire d'inscription.
3. Soumettez le formulaire avec des données de test.
4. Confirmez que vous êtes redirigé vers la page de détails du client Live Store.

Si vous obtenez une erreur d'autorisation, revérifiez la `X-API-KEY` valeur de l'en-tête et le périmètre de la clé API.
{% endstep %}
{% endstepper %}

### Optionnel : afficher un code QR pour l'inscription en libre-service

Utilisez cette option lorsqu'un magasin utilise une tablette et souhaite que les clients poursuivent sur leur propre téléphone.

Activez le mode tablette dans `server/livestore.yml` et pointez le layout de redirection vers un layout adapté aux mobiles :

```yaml
layout: pos
useTabletMode: true
provider: y2
customerRedirectLayout: mobile
```

### FAQ

<details>

<summary><strong>Où dois-je configurer l'extension dans Live Store ?</strong></summary>

Utilisez **newpossettings**. Configurez-la au **global**, **country**, ou **store** niveau. Live Store ne prend pas en charge cette extension au niveau de la caisse.

</details>

<details>

<summary><strong>Quelle URL dois-je utiliser pour <code>point de terminaison</code> et <code>apiEndpoint</code>?</strong></summary>

Utilisez l'activité personnalisée `https://app.neostore.cloud/api/<tenantId>/external/livestore` de base et remplacez `<tenantId>` par votre ID de locataire dans The Wallet Crew.

Si votre projet utilise un environnement différent (préproduction, QA ou un domaine personnalisé), utilisez l'URL de base fournie par The Wallet Crew lors de la configuration.

</details>

<details>

<summary><strong>Puis-je réutiliser la même clé API pour le test et la production ?</strong></summary>

Évitez-le. Utilisez des clés API distinctes pour chaque environnement. Faites pivoter les clés si vous pensez qu'elles ont été exposées.

</details>

<details>

<summary><strong>Live Store redirige, mais j'aboutis sur une page d'erreur. Que dois-je vérifier ?</strong></summary>

Commencez par les bases. Confirmez que l' `point de terminaison` URL est accessible depuis le réseau Live Store. Confirmez que l' `X-API-KEY` en-tête est présent et correct. Puis confirmez que le connecteur Cegid Retail Y2 est activé dans The Wallet Crew et qu'il peut atteindre vos services Y2.

</details>




---

[Next Page](/llms-full.txt/1)