Accueil/Blog/Apple & Google Wallet
Apple & Google Wallet

Comment marche une carte de fidélité dans Apple Wallet et Google Wallet

Le client scanne un QR, la carte arrive dans Wallet, sans rien installer. Côté commerce, ça demande un certificat Apple et une solution qui pousse les mises à jour. Voici comment ça tient debout, et où sont les limites.

· 6 min de lecture

Ce que voit le client

Le client scanne un QR code à la caisse, ou clique sur un lien dans un SMS ou un mail. Une page s'ouvre avec un bouton Ajouter à Apple Wallet ou Enregistrer dans Google Wallet. Il appuie. La carte se range dans l'app Wallet déjà présente sur son téléphone. Pas de téléchargement, pas de compte à créer, pas de mot de passe.

C'est le point qui change tout par rapport à une app maison. Apple Wallet et Google Wallet sont installés d'origine sur l'iPhone et sur la plupart des Android. Le client ne franchit pas la barrière de l'App Store ou du Play Store, qui fait abandonner la grande majorité des gens. La carte vit à côté de sa carte d'embarquement et de ses billets de concert, dans un endroit qu'il ouvre déjà.

Ensuite, à chaque passage, le commerçant scanne le code-barres ou le QR affiché sur la carte pour créditer un point ou un tampon. Sur certains terminaux compatibles NFC, le client peut aussi approcher son téléphone, mais le scan d'un code reste le mode le plus répandu et le moins cher à mettre en place.

Ce qui se passe côté commerçant

Une carte Wallet n'est pas un simple visuel. C'est un fichier signé cryptographiquement. Apple appelle ce format le .pkpass, et il doit être signé avec un certificat lié à un identifiant précis, le Pass Type ID, délivré depuis un compte développeur Apple. Sans cette signature valide, l'iPhone refuse purement et simplement d'ajouter la carte. Google fonctionne sur un principe proche, avec une API et un compte émetteur côté Google Cloud.

C'est là que se trouve le vrai travail, et la raison pour laquelle un commerçant ne fabrique pas ça lui-même. Il faut gérer le certificat Apple, le renouveler avant qu'il expire, signer chaque carte, héberger les pages d'ajout, et surtout tenir un serveur qui reste joignable pour les mises à jour. Un boulanger ou un coiffeur n'a aucune envie de toucher à un compte développeur Apple. Il passe par une solution qui opère toute cette mécanique pour lui.

Concrètement, voici ce que la solution prend en charge à sa place :

  • Le certificat Pass Type ID Apple et le compte émetteur Google, avec leur renouvellement
  • La génération et la signature de chaque carte aux deux formats
  • Les pages et liens d'ajout, et le QR à afficher en boutique
  • Le serveur qui pousse les mises à jour quand un point est ajouté

La mise à jour automatique, le vrai intérêt

Une carte papier est figée le jour où on l'imprime. Une carte Wallet, non. Quand le commerçant ajoute un tampon, le nouveau total apparaît sur le téléphone du client sans qu'il fasse quoi que ce soit. Côté Apple, le serveur envoie une notification via APNs, le service de push d'Apple, et Wallet va chercher la version à jour. Côté Google, c'est le serveur de la solution qui met à jour l'objet du client via l'API.

Ça ouvre des choses qu'une carte cartonnée ne fera jamais. Le solde se met à jour en direct. Le commerçant peut changer une offre sur toutes les cartes en circulation en même temps. Et il peut déclencher une notification quand le client repasse près de la boutique, ou quand sa carte est presque pleine. À utiliser avec mesure : ces messages atterrissent sur l'écran verrouillé, et trop de notifications poussent juste le client à supprimer la carte.

iPhone, Android, et les deux limites à connaître

Une bonne solution génère les deux formats à partir du même programme. Le client iPhone reçoit un .pkpass dans Apple Wallet, le client Android enregistre la carte dans Google Wallet, et le commerçant ne gère qu'un seul programme de fidélité derrière.

Maintenant, les limites, parce qu'elles existent. D'abord, le client a besoin d'un smartphone assez récent et de l'app Wallet active. Une personne avec un vieux téléphone, ou qui a désinstallé Google Wallet, ne pourra pas ajouter la carte ; pour ce public, mieux vaut garder une option de repli. Ensuite, vous dépendez d'une solution tierce : le certificat Apple, le serveur de mises à jour et les données vivent chez le prestataire, et si vous changez d'outil, la migration des cartes existantes demande de la préparation.

Stampz, par exemple, est une de ces solutions : elle détient le certificat, génère les cartes aux deux formats et pousse les mises à jour, pour un commerce de proximité qui veut une carte de fidélité dans Wallet sans toucher au code.

Questions fréquentes

Le client doit-il installer une application ?
Non. Apple Wallet et Google Wallet sont déjà sur le téléphone. Le client scanne un QR ou clique un lien, appuie sur Ajouter, et la carte se range dans Wallet. Aucun téléchargement ni création de compte.
Pourquoi ne puis-je pas créer ces cartes moi-même ?
Apple exige que chaque carte soit signée avec un certificat Pass Type ID rattaché à un compte développeur, et impose un serveur joignable pour les mises à jour. Google demande un compte émetteur et son API. Gérer et opérer tout ça n'a pas de sens pour un commerce ; une solution tierce le fait à votre place.
Le tampon se met-il à jour tout seul sur le téléphone du client ?
Oui. Quand vous créditez un point, le serveur pousse la nouvelle version. Sur iPhone, Apple passe par ses notifications APNs ; sur Android, c'est l'API Google. Le client voit son total monter sans rien faire.
À lire aussi

Lancez votre carte de fidélité

Dans Apple Wallet et Google Wallet, prête en 10 minutes. Sans app, sans matériel, sans engagement.

Créer ma carte gratuitement