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

# Dans votre application mobile

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.md)

</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>


---

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

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

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

```
GET https://docs.thewalletcrew.io/guides-enrolment/fr/inscription/readme-1.md?ask=<question>&goal=<endgoal>
```

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

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

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