Encart fidélité dans le panier
Le widget "Panier" d'Enkore affiche dans le panier la meilleure récompense que le consommateur peut obtenir avec son solde de points, et lui permet de l'échanger sans quitter le tunnel d'achat.
Objectif du widget
Le widget panier poursuit quatre objectifs :
- Rappeler l'existence du programme au moment décisif : le consommateur voit son avantage fidélité juste avant de payer, là où il compare encore le montant de sa commande.
- Informer qu'une récompense est disponible maintenant : l'encart met en avant la récompense la plus intéressante que le solde de points permet déjà d'obtenir, plutôt qu'un rappel abstrait du programme.
- Permettre l'échange immédiat : le consommateur convertit ses points en code de réduction en deux clics et l'utilise dans le panier qu'il est en train de valider.
- Renforcer l'univers du programme : icône, couleur de fond, arrondi, texte et CSS personnalisé permettent d'aligner l'encart sur l'identité de la marque.
Deux modes d'intégration sont possibles : l'intégration par script javascript, où Enkore fournit le rendu complet de l'encart, et l'intégration par API, où la boutique construit son propre affichage à partir des endpoints de l'API.
Intégration à l'aide du script
Le widget est un bundle JavaScript autonome, chargé par une balise <script>. Il cherche dans la page l'élément d'ancrage, s'y monte, et lit dans le HTML les informations que le back-end de la boutique a ajoutées.
Ce que le back-end doit exposer dans le HTML
| Élément | Rôle | Obligatoire |
|---|---|---|
<div id="enkore-cart-root"></div> | Point de montage du widget | Oui |
<div id="enkore-loyalty-hash" hidden>…</div> | HMAC-SHA512 du client, en innerText | Oui pour un client connecté |
<div id="enkore-loyalty-id" hidden>…</div> | Identifiant du client dans la plateforme e-commerce (externalId), en innerText | Oui pour un client connecté |
<div id="enkore-language" hidden data-enkore-language-iso="fr"></div> | Code ISO de la langue de la page | Non |
Quelques précisions :
- Le hash et l'
externalIdvont de pair. Ils identifient le client auprès de l'API sans session ni cookie. Le hash est calculé côté serveur à partir de la référence du store et de sa clé API — voir la page Authentification par hash. La clé API ne doit jamais être exposée au navigateur. - Client non connecté : les deux éléments sont laissés vides (ou absents). Le widget affiche alors le texte "non connecté" configuré au back-office — une invitation à se connecter pour vérifier ses points — sans solde ni possibilité d'échange.
- Langue : le widget choisit sa langue dans l'ordre suivant — langue de la page (
data-enkore-language-iso), puis langue par défaut du store configurée au back-office, puis français. Les langues gérées sontfr,en,es,de,it,nl,pl; un code régional (fr-FR) est ramené à sa langue (fr), etgb— l'iso_codesous lequel PrestaShop installe l'anglais britannique — est traité commeen. - Domaine : contrairement aux autres widgets, celui-ci n'accepte pas d'élément de domaine dans la page — il utilise toujours le domaine du navigateur (
protocol + hostname). Le panier doit donc être servi sur le domaine déclaré chez Enkore.
Exemple de page
<!-- Identification du client, rendue côté serveur -->
<div id="enkore-loyalty-hash" hidden>708e3f96061caf0af6…</div>
<div id="enkore-loyalty-id" hidden>8924</div>
<!-- Facultatif -->
<div id="enkore-language" hidden data-enkore-language-iso="fr"></div>
<!-- Point de montage -->
<div id="enkore-cart-root"></div>
<!-- Chargement du widget -->
<script async defer src="https://cart-widget.enkore.io/enkore-cart-default-1-0.js"></script>
Les rafraîchissements AJAX du panier
Un panier se re-rend en permanence sans rechargement de page : changement de quantité, de transporteur, application d'un code promo. Sur la plupart des plateformes, ces rafraîchissements ré-injectent le bloc HTML du panier, et donc la balise <script> du widget.
Le widget est conçu pour cela et n'attend rien de particulier de la boutique :
- à chaque ré-exécution, il démonte son rendu précédent et supprime les encarts devenus orphelins, de sorte qu'un seul encart reste affiché ;
- la configuration, le solde et la liste des récompenses déjà chargés sont conservés en mémoire pour la durée de la page : les rafraîchissements successifs ne rappellent pas l'API ;
- ce cache est invalidé après un échange de points, afin d'afficher immédiatement le nouveau solde.
Comportements pris en charge par le script
- L'emplacement de l'encart est piloté par le back-office : le widget s'insère juste après l'élément désigné par le sélecteur CSS configuré (
cssSelector). - Le CSS personnalisé défini au back-office est injecté dans le
<head>sous forme de balise<style id="enkore-custom-css">. - Une seule récompense est mise en avant : parmi celles que le solde du client permet déjà d'obtenir, celle de plus grande valeur. Si aucune n'est accessible, l'encart ne s'affiche pas du tout pour un client connecté.
- Le texte dépend de l'état du client (connecté ou non) et accepte la variable
{{reward_value}}, remplacée par la valeur de la récompense mise en avant (50 €,10 %). - L'échange se fait en deux temps : une modale de confirmation, qui rappelle le montant minimum d'achat de la récompense, puis une modale affichant le code de réduction à copier. Le solde est rechargé à sa fermeture.
Aucun appel HTTP n'est à écrire : le script contacte l'API lui-même, avec les mêmes endpoints que ceux listés ci-dessous.
Intégration par API
Une boutique qui souhaite construire son propre affichage appelle directement les endpoints de l'API. Chaque endpoint est décrit — paramètres, schémas de réponse, exemples de code — dans la référence d'API.
Au chargement du panier
| Endpoint | Rôle | Authentification |
|---|---|---|
GET /store/widget/cart | Configuration visuelle et textuelle de l'encart telle que définie au back-office (sélecteur CSS, textes connecté et non connecté, couleur, arrondi, icône, CSS personnalisé, traductions) | domain |
GET /point/user-history/{externalId} | Solde de points du client, à comparer au coût des récompenses | domain + hash |
GET /reward/list | Récompenses de la boutique, leur valeur, le nombre de points requis et le montant minimum d'achat | domain |
Les deux derniers appels n'ont de sens que pour un client identifié : sans solde, aucune récompense ne peut être déclarée accessible.
L'appel de configuration n'a d'intérêt que si l'on souhaite piloter l'apparence et l'emplacement de l'encart depuis le back-office Enkore. Une intégration entièrement maîtrisée côté boutique peut s'en passer.
Sur action du consommateur
| Endpoint | Rôle | Authentification |
|---|---|---|
POST /reward/claim/{externalId} | Échange les points du client contre la récompense choisie et retourne le code de réduction à afficher | domain + hash |
Après un échange, le solde est à recharger : il a été débité du coût de la récompense.
Authentification
Les endpoints qui opèrent au nom d'un client (hash) exigent les paramètres domain, externalId et hash — voir Authentification par hash. Les autres n'ont besoin que du paramètre domain et sont publics.
Quelle intégration choisir ?
Par défaut, l'intégration par script. Elle demande moins de travail : il suffit d'exposer quelques éléments dans le HTML et de charger le script. Elle donne accès à la configuration de l'encart depuis le back-office Enkore — y compris son emplacement dans le panier — prend en charge les rafraîchissements AJAX du panier, et la boutique profite automatiquement des mises à jour du widget — corrections, nouvelles langues, nouveaux réglages — sans redéploiement de son côté.
L'intégration par API est réservée aux boutiques qui veulent un contrôle total de l'affichage : intégration profonde dans un design system, tunnel d'achat sur mesure, framework front spécifique. En contrepartie, tout le rendu et son évolution — y compris le choix de la récompense mise en avant et le parcours d'échange — restent à la charge de la boutique.