Salesforce Commerce Cloud (SFCC)
Ajoutez les boutons « Ajouter à Wallet » Apple Wallet et Google Wallet à une boutique Salesforce Commerce Cloud à l’aide d’une cartridge, de la signature HMAC côté serveur et du SDK cinto de The Wallet Crew.
Cette intégration explique comment ajouter un bouton unique « Add to Wallet » à une vitrine Salesforce Commerce Cloud. Les emplacements courants sont Mon compte zone (carte de fidélité ou d’adhésion) et les pages authentifiées où un identifiant stable est disponible (par exemple une liste de cartes-cadeaux). Les pages de click & collect peuvent aussi convenir lorsqu’une carte de retrait est utilisée comme jeton de scan en magasin.
Un identifiant stable disponible dans la session client est signé côté serveur, puis transmis au SDK cinto de The Wallet Crew comme identifiant externe. Cela rend l’échange d’identifiants inviolable et évite d’exposer des secrets dans le code de la vitrine.
Concepts SFCC utilisés dans cette intégration
Le code de la vitrine Salesforce Commerce Cloud est empaqueté et déployé sous forme de cartridges. Un cartridge peut ajouter des contrôleurs, des scripts, des modèles et des métadonnées de configuration, puis être intégré à un site en l’ajoutant au chemin des cartridges.
Ce guide suppose qu’un cartridge dédié est créé pour l’intégration The Wallet Crew, généralement nommé comme int_TheWalletCrew. Le cartridge est ensuite référencé par :
l’application de vitrine (SFRA ou SiteGenesis)
configuration de Business Manager (préférences de site et, éventuellement, objets personnalisés)
Cartridge
Un cartridge est l’unité de déploiement dans SFCC. L’ordre des cartridges compte car SFCC résout les modèles et les scripts en parcourant le chemin des cartridges de gauche à droite.
SFRA vs SiteGenesis
Les deux architectures peuvent prendre en charge l’intégration :
SFRA: contrôleurs et modèles ISML. Le bouton est généralement ajouté dans un modèle de compte ou dans un remote include.
SiteGenesis: pipelines (hérités) et modèles ISML. Le bouton est généralement ajouté dans une page de compte rendue par pipeline.
Le modèle de sécurité reste identique. Le HMAC est calculé côté serveur et jamais en JavaScript du navigateur.
Comment ça marche
Le SDK cinto de The Wallet Crew affiche le bon CTA selon l’appareil.
Sur iOS, le bouton télécharge une carte Apple Wallet. Sur Android, il ouvre Google Wallet. Sur ordinateur, le SDK redirige vers une page de carte hébergée qui peut être scannée ou ouverte sur mobile.
Dans cette configuration SFCC, la carte est récupérée à l’aide de :
un type de carte (exemple :
user)un identifiant SFCC stable envoyé en tant qu’ identifiant externe (exemple :
sfcc.customerNo)un HMAC signature qui prouve que l’identifiant a été émis par le backend de la marque
Le HMAC doit être calculé côté serveur. Il ne doit pas être généré dans le navigateur.
Prérequis
Un modèle de carte et une émission de carte déjà configurés dans The Wallet Crew.
L’identifiant de locataire The Wallet Crew est disponible (utilisé par l’URL du script SDK).
Un identifiant stable disponible sur les pages authentifiées, tel que :
SFCC
CustomerNo(typique pour les cartes de fidélité)(typique pour les cartes de retrait click & collect)
(lorsque les cartes-cadeaux sont stockées dans SFCC ou dans un système connecté)
Le nom de la clé d’identifiant externe convenu lors de l’intégration (exemple :
sfcc.customerNo).
Implémentez l’intégration sous forme de cartridge
Le schéma typique est le suivant :
Lire l’identifiant dans le code côté serveur de SFCC.
Calculer un HMAC avec le secret du locataire.
Rendre un conteneur cinto dans le modèle ISML avec identifiant + HMAC.
Charger le SDK cinto depuis
sdk.neostore.cloud.
Ajouter le cartridge au chemin des cartridges
Après avoir déployé le cartridge d’intégration sur l’instance, ajoutez-le au chemin des cartridges du site dans Business Manager. Le cartridge doit être placé avant avant le cartridge de base de la vitrine afin que les substitutions se résolvent correctement.
Stockez la configuration du locataire sous forme de préférences de site
Les valeurs et secrets du locataire doivent rester côté serveur. Dans SFCC, cela se fait généralement avec préférences de site personnalisées.
Au minimum, ces valeurs sont généralement requises.
Le secret HMAC ne doit pas être stocké dans les modèles, les contenus ou toute configuration côté client.
Calculer le HMAC côté serveur
Les scripts côté serveur de SFCC peuvent calculer un HMAC SHA-256 à l’aide du secret du locataire et de la valeur exacte de l’identifiant.
Choix d’implémentation courants :
un script d’aide exposé par le cartridge, utilisé par les contrôleurs de compte
un modèle décorateur qui enrichit le modèle de vue avec
identifiantetidentifierHmac
Le cache doit être géré avec précaution. Les pages spécifiques à un client ne doivent pas partager de HTML mis en cache entre clients lorsque l’identifiant est intégré au balisage.
Rendre le bouton « Add to Wallet » en ISML
Le SDK cinto s’appuie sur :
un script chargeur du SDK faisant référence à l’identifiant du locataire
un élément conteneur marqué comme bouton « Add to Wallet »
un
passTypeune paire clé/valeur d’identifiant externe plus le HMAC côté serveur
Le cartridge d’intégration fournit généralement un fragment ISML pouvant être inclus là où c’est nécessaire (tableau de bord du compte, liste de cartes-cadeaux, page de click & collect).
Conventions des identifiants externes (casse + échappement)
Le SDK cinto peut récupérer une carte à partir d’un identifiant externe :
passType(exemple :user)externalIdentifier.key(exemple :sfcc.customerNo)externalIdentifier.value(exemple :00012345)externalIdentifier.hmac(HMAC-SHA256 de la valeur)
Convention de nommage recommandée pour les clés
L’option la plus stable consiste à éviter les majuscules/minuscules mixtes dans les clés d’identifiant.
Les clés sont généralement :
préfixées par un espace de noms comme
sfcc.en minuscules
en utilisant
_comme séparateur lorsque nécessaire
Exemples :
sfcc.customer_nosfcc.pickup_refsfcc.gift_card_id
Si une clé à casse mixte doit être utilisée dans des attributs HTML
Les navigateurs traitent les noms d’attributs HTML comme étant en minuscules. cinto prend en charge une règle d’échappement pour les caractères majuscules dans data-neostore-externalIdentifiers-... attributs :
Préfixez un caractère majuscule avec
_dans le nom de l’attribut.y2.customer_Idest interprété commey2.customerId.
Appliqué aux exemples SFCC :
Clé d’identifiant dans The Wallet Crew :
sfcc.customerNoClé d’identifiant dans les attributs HTML :
sfcc.customer_No
Cela n’affecte que le nom de l’attribut, pas la valeur signée.
Implémentation de référence SFRA à copier/coller (contrôleur + fragment ISML)
Cette implémentation de référence utilise :
les préférences de site pour stocker la configuration du locataire
un un helper HMAC côté serveur
un un contrôleur d’inclusion distante qui rend un fragment ISML
Elle est conçue pour être collée dans un cartridge dédié (exemple : int_TheWalletCrew) et appelée depuis une page de compte.
Arborescence des fichiers du cartridge
cartridge/scripts/TheWalletCrew/hmac.jscartridge/controllers/TheWalletCrew.jscartridge/templates/default/TheWalletCrew/addToWalletButton.isml
1) Helper HMAC (cartridge/scripts/TheWalletCrew/hmac.js)
2) Contrôleur (cartridge/controllers/TheWalletCrew.js)
Ce contrôleur rend un widget qu’il est sûr d’inclure comme inclusion distante.
3) Fragment ISML (cartridge/templates/default/TheWalletCrew/addToWalletButton.isml)
Le chargeur de script doit être inclus une seule fois par page. Lorsque plusieurs boutons sont rendus sur la même page, déplacez le chargeur dans un fragment de pied de page partagé et conservez uniquement le <div data-neostore-addToWalletButton ...> le balisage dans le modèle du widget.
4) Inclure le widget dans un modèle de compte
Dans SFRA, les inclusions distantes sont couramment utilisées pour éviter d’encombrer le contrôleur principal et pour garder le cache explicite.
Politique de sécurité du contenu (CSP)
Certaines vitrines SFCC appliquent une politique de sécurité du contenu qui bloque par défaut les scripts tiers. Si le script du SDK est bloqué, l’ajout à la liste d’autorisation de https://sdk.neostore.cloud pour script-src est requis.
Dans les projets SFRA, la CSP est souvent gérée via des middlewares et des en-têtes de réponse. Le changement doit suivre la stratégie CSP existante du projet (mode rapport uniquement vs application forcée).
Valider le résultat
La validation couvre généralement le rendu de la plateforme et l’installation de la carte.
Sur Safari iOS, le CTA doit afficher Ajouter à Apple Wallet.
Sur Chrome Android, le CTA doit afficher Ajouter à Google Wallet.
Sur ordinateur, le CTA doit rediriger vers une page de carte hébergée.
Après l’installation, la carte doit être visible dans Apple Wallet ou Google Wallet.
Dépannage
Le bouton ne s’affiche pas
Les causes courantes sont un script SDK bloqué (CSP) ou un balisage manquant. La page rendue doit contenir le chargeur du SDK et l’élément conteneur cinto.
Cliquer sur le bouton provoque une erreur
Cela signifie généralement que l’identifiant externe ou le HMAC ne correspond pas à ce que The Wallet Crew attend. Vérifiez :
que le nom de la clé d’identifiant externe correspond à celui configuré pour SFCC (exemple :
sfcc.customerNo)que la valeur de l’identifiant correspond exactement à celle signée côté serveur (sans suppression d’espaces, mise en forme ni changement de type)
que le HMAC a été calculé avec le bon secret du locataire
Le bouton s’affiche pour le mauvais client
Cela indique généralement un cache HTML partagé entre sessions. Assurez-vous que :
les pages spécifiques à un client ne sont pas mises en cache au niveau de la page
les inclusions distantes utilisées pour les widgets de compte ne sont pas mises en cache d’un client à l’autre
toute couche CDN respecte les cookies de session pour les pages authentifiées
FAQ
Mis à jour

