Transformez les tickets de caisse en points de fidélité avec Hashting

Vous pouvez désormais configurer un parcours cashback basé sur les tickets de caisse / preuve d'achat, propulsé par notre partenaire Hashting : un membre dépose un ticket via une campagne Qualifio, Hashting effectue l'OCR et valide le ticket, et le résultat est renvoyé au membre dans le portail — avec attribution automatique des points une fois le ticket accepté.

Cet article explique comment les différentes briques s'articulent, comment configurer ce parcours pour un client, ce que signifient les statuts de ticket, et comment diagnostiquer un ticket qui ne se met pas à jour.

Qu'est-ce qui change ?

Cette fonctionnalité s'appuie sur trois briques déjà existantes dans la plateforme — rien de spécifique aux tickets n'a été codé en dur :

• Une Interaction — un enregistrement générique du profil loyalty, utilisé pour afficher à un membre le statut courant et l'historique d'un événement se produisant hors de Qualifio (ici, un ticket). Elle est affichée via un template de détail Handlebars dans un widget Interaction du portail.
• Un incoming event — le point d'entrée générique + mapping JSONata déjà utilisé par Qualifio pour recevoir le webhook de n'importe quel partenaire. Pour Hashting, un premier mapping alimente la règle de gain (le côté points), et un second mapping (le « JSONata d'interaction ») écrit l'enregistrement Interaction affiché au membre.
• Une intégration Hashting Cashback sur la campagne — la campagne qui collecte l'image du ticket la transmet à Hashting, et une push rule sur cette campagne maintient le lien avec le parcours.

Comme cette fonctionnalité repose sur les mécanismes génériques Interaction + incoming event, elle ne se limite pas à Hashting — le même schéma fonctionne pour tout partenaire renvoyant un statut de manière asynchrone.

Comment un ticket passe-t-il du dépôt à l'attribution de points ?

1. Le membre ouvre le portail et clique sur Déposer un ticket, ce qui ouvre la campagne Qualifio intégrée, pré-remplie avec son prénom, nom et email.
2. Il dépose l'image du ticket (mappée sur le champ invoice de la campagne) et valide.
3. La campagne transmet la soumission à Hashting via la push rule « Hashting Cashback Flow ».
4. Hashting rappelle l'incoming event au fur et à mesure du traitement du ticket — d'abord avec un statut Pending, puis un statut final Accepted (avec le détail des articles et le montant) ou Refused (avec un motif).
5. Chaque rappel est mappé deux fois : le JSONata de mapping d'événement alimente la règle de gain, et le JSONata d'interaction met à jour l'enregistrement Interaction affiché dans le portail.
6. Une fois le ticket Accepted, la règle de gain (configurée pour se déclencher sur cet événement, en utilisant le Montant total TTC) attribue les points.

Interaction, incoming event et Transaction : quelle différence ?

Ces trois notions se côtoient dans ce parcours, voici donc un récapitulatif rapide :

Un incoming event peut exister sans interaction active (points uniquement, sans affichage de statut) ; une Interaction dépend en revanche toujours d'un incoming event pour être alimentée.

Comment configurer le parcours Hashting Cashback pour un client ?

Notre équipe interne Professional Services prend en charge la configuration technique (étapes 1 à 6 ci-dessous). Si vous êtes intéressés par ce service, merci de contacter l'équipe Professional Services (integrations@qualifio.com) pour la mise en place.

1. Créer l'Interaction (type « Store receipt »), avec le template de détail Handlebars standard — il affiche le statut courant, le motif de refus le cas échéant, le détail des montants, un lien vers le ticket, et l'historique des statuts.
2. Créer l'incoming event : le relier à l'intégration Hashting et à cette Interaction, définir l'authentification (actuellement un token en paramètre de requête), et régler Source = Ecommerce / Action = Purchase. Ajouter les deux mappings JSONata — le mapping de gain et le mapping d'interaction (Qualifio fournit le snippet standard d'interaction ; il n'est pas exposé au client).
3. Abonner le webhook côté Hashting — un appel API ponctuel enregistrant l'URL de votre incoming event comme callback pour cashback_entry_status_update_with_data.
4. Créer une intégration Hashting Cashback dans le module campagne.
5. Construire la campagne qui transmet à Hashting, en mappant firstname, lastname, email, et le dépôt du ticket sur le champ invoice.
6. Activer la push rule « Hashting Cashback Flow » sur cette campagne.
7. Ajouter les widgets au portail : un widget Campagne intégrant la campagne de dépôt, et un widget Interaction pointant vers l'Interaction ticket.
8. Créer la règle de gain qui attribue des points lorsqu'un ticket est accepté, en utilisant le Montant total TTC comme montant attribué.

Tarification :

• Frais technologiques d'activation de la fonctionnalité : 2 000 €
• Frais de mise en place côté Qualifio : 3 000 €

Que signifient les statuts de ticket ?

• Pending — le ticket a été soumis et Hashting n'a pas encore renvoyé de résultat définitif.
• Accepted — Hashting a validé le ticket et renvoyé le détail des articles et le montant. C'est aussi à ce moment que la règle de gain attribue les points.
• Refused — Hashting a refusé le ticket. Lorsque Hashting fournit un motif, celui-ci est affiché directement dans le titre et l'historique de l'Interaction — pas besoin de le chercher ailleurs.

Pourquoi un ticket reste-t-il bloqué sur « Pending », ou ne rapporte-t-il pas de points ?

À vérifier, dans l'ordre :

• L'abonnement webhook côté Hashting pointe vers la bonne URL et le bon token d'incoming event — une URL périmée ou mal saisie signifie que Hashting n'a rien à rappeler.
• La push rule (« Hashting Cashback Flow ») est active sur la campagne — si elle est désactivée, l'image du ticket n'atteint jamais Hashting.
• Le JSONata d'interaction renvoie toujours les clés requises externalId, label, status et data — un mapping cassé n'actualise rien, mais ne bloque ni ne déclenche à tort l'attribution de points, puisque le chemin des points est verrouillé dans le code, pas dans le mapping.
• La règle de gain est active et lit correctement le montant du payload Accepted (Montant total TTC).
• Le traitement côté Hashting — si ni le détail des articles ni un statut rejected n'ont encore été renvoyés, le ticket reste légitimement en Pending jusqu'à ce que Hashting termine son examen.

Peut-on réutiliser ce mécanisme pour un autre partenaire ou un autre type d'événement ?

Oui. Rien dans la configuration Interaction ou incoming event n'est spécifique à Hashting — le même schéma (incoming event + JSONata d'interaction + widget Interaction) s'applique à tout partenaire qui renvoie un statut de manière asynchrone à un processus visible par le membre.

Pour toute autre question à ce sujet, n'hésitez pas à contacter notre équipe Support ici.