Pourquoi une app et non un plugin
Un plugin Shopware, c'est du PHP qui s'exécute dans la boutique ; une app, c'est un manifeste qui indique à Shopware quelles URL appeler. Pour le tracking des commandes, l'app suffit : Shopware envoie des webhooks signés pour les événements auxquels vous vous abonnez, et rien de Track ne s'exécute dans la boutique. integrations/shopware/manifest.xml est ce manifeste.
Enregistrement
Lors de app:install, Shopware appelle l'URL d'enregistrement de l'app avec shop-id, shop-url et un horodatage, signés dans l'en-tête shopware-app-signature avec le secret d'app du manifeste. Le collecteur vérifie la signature, répond par une preuve (HMAC-SHA256 sur l'identifiant de la boutique, son URL et le nom de l'app) et un secret de boutique, et Shopware confirme en envoyant des identifiants d'accès API à l'URL de confirmation. Track écarte délibérément ces identifiants : l'intégration ne fait que recevoir des webhooks et n'appelle jamais l'API de la boutique. Le secret que vous avez stocké dans la connexion sert à la fois de secret d'app et de secret de boutique, si bien que chaque webhook ultérieur est vérifié via shopware-shop-signature, le HMAC-SHA256 en hexadécimal du corps brut.
Quel événement devient quoi
| Événement Shopware | Événement Track |
|---|---|
state_enter.order_transaction.state.paid | purchase |
state_enter.order_transaction.state.refunded | refund (total de la commande) |
checkout.order.placed | purchase uniquement lorsque la connexion est réglée pour compter les commandes passées |
Par défaut, c'est la transaction payée qui est comptée, pas la commande passée. Dans les boutiques en prépaiement ou sur facture, une commande peut rester impayée pendant des jours, voire ne jamais être payée ; la compter à la passation gonfle le chiffre d'affaires et apprend la mauvaise chose aux plateformes publicitaires. Les boutiques où la passation est le moment significatif (paiement à la livraison, facturation B2B) basculent la connexion sur passée.
L'achat porte l'identifiant de commande, le numéro de commande comme identifiant de transaction, les montants total et net (la taxe étant leur différence), les frais de livraison, la devise, les lignes produits indexées par numéro de produit, ainsi que l'e-mail, le nom et la ville, le code postal et le pays de facturation du client comme données de correspondance brutes que le routeur hache. Les lignes de promotion et de livraison ne sont pas des produits et sont ignorées.
Devise
Les événements paid et refunded portent la commande avec son association de devise dans les versions actuelles de Shopware. Si une version l'omet, la devise de repli de la connexion s'applique ; à défaut de l'une comme de l'autre, l'événement est stocké sans devise et le moniteur des destinations signale le champ manquant au lieu de deviner.
Le snippet Storefront
Ajoutez le snippet standard dans le fichier base.html.twig de votre thème, dans le bloc base_head. Il couvre le Storefront et la page de fin de checkout, que Shopware rend lui-même, de sorte que l'achat navigateur — avec l'enregistrement de consentement et les identifiants de clic du visiteur — existe en parallèle du webhook. L'appariement par numéro de commande permet ensuite à l'achat serveur vérifié d'hériter de ce consentement ; sans achat navigateur, l'enregistrement serveur reste opérationnel et n'atteint aucune destination publicitaire.
Mise en place
- Site → Connexion boutique → Shopware 6 : domaine de la boutique, devise de repli, moment de l'achat ; stockez un secret (32 caractères aléatoires) ; copiez l'URL d'enregistrement.
- Placez le manifeste dans
custom/apps/TrackSite/manifest.xml, remplacez l'identifiant de tracking, le jeton de chemin et le secret, puis exécutezbin/console app:install --activate TrackSite. - Marquez la transaction d'une commande de test comme payée. La connexion signale l'enregistrement et le premier webhook ; le débogueur affiche l'achat shopware.
Limites
- Un second remboursement partiel sur la même commande est dédupliqué par numéro de commande ; le premier est enregistré.
- Les apps ne peuvent pas injecter elles-mêmes de scripts dans le Storefront ; le snippet est une modification du thème, documentée dans le README.
- Les commandes modifiées dans l'administration après paiement ne renvoient pas l'événement payée ; les corrections de valeur se font dans votre propre reporting, pas chez les fournisseurs.