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.

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.

Exemples concrets

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

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.

1

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.

2

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

3

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.

4

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.

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
• Migration depuis The Wallet Crew : Exporter les cartes depuis The Wallet Crew vers un autre fournisseur

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

Les clients doivent-ils réinstaller leur carte pendant une migration ?

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.

De quelles données avons-nous généralement besoin de l’ancien fournisseur ?

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

Combien de temps prend généralement une migration ?

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.

Qui doit être impliqué ?

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.