This documentation is currently under development. Certain sections are not yet complete and will be added shortly.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Exemples concrets
  • 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é.

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.

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.

Liste de vérification de préparation à la migration

Utilisez cette liste comme liste de validation avant de toucher aux cartes de production.

Prévoyez au moins un cycle pilote. La plupart des retards proviennent des exports, des approbations et de la planification de la bascule.

Prévoyez au moins un cycle pilote. La plupart des retards proviennent des exports, des approbations et de la planification de la bascule.

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

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.

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

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

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.

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.

1

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.

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

2

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)

3

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

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.

4

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.

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.

5

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.

6

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.

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

Les clients doivent-ils réinstaller leur carte ?

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.

Pourquoi avons-nous besoin du jeton d’authentification Apple ?

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.

Pouvons-nous migrer des cartes Google Wallet entre des comptes émetteurs ?

Pas sur place.

Les cartes Google Wallet sont liées au compte émetteur. Si l’émetteur change, prévoyez un flux de réémission.

Comment savoir si la bascule Apple a fonctionné ?

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.

Que se passe-t-il si nous ne pouvons pas conserver le même Apple Carte Type ID ?

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.

Que se passe-t-il si notre fournisseur actuel ne peut pas envoyer la « mise à jour finale » Apple ?

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.

Devons-nous modifier les codes-barres ou la logique d’utilisation ?

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.

Que devons-nous communiquer aux clients pendant la migration ?

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.