Article 30

Shopify, PrestaShop ou WooCommerce en Israël : passerelles de paiement locales et ventes invisibles pour Meta et Google

Par Dan Elbaz14 min de lecture

Votre boutique enregistre 120 commandes cette semaine. Meta en voit 70. Le gestionnaire de publicités affiche un ROAS de 2,1 là où la réalité avoisine 3,6. Sur la foi de ce chiffre, vous coupez une campagne rentable, et vous en gardez une qui l’est moins.

Le coupable, bien souvent, n’est ni Meta ni votre agence. C’est le chemin qu’emprunte l’acheteur au moment de payer. En Israël, ce chemin passe presque toujours par une passerelle de paiement locale, et c’est là que les ventes se perdent.

Voici pourquoi le problème est plus fréquent en Israël, comment le diagnostiquer en trente minutes, et comment le corriger sur Shopify, PrestaShop et WooCommerce.

Pourquoi le problème touche particulièrement les boutiques israéliennes

Pas de Shopify Payments en Israël

Shopify Payments, la solution de paiement intégrée de Shopify, n’est pas disponible en Israël : le pays ne figure pas dans la liste officielle des pays pris en charge. Les boutiques israéliennes passent donc par des prestataires tiers : Cardcom, Tranzila, Grow (anciennement Meshulam), PayPlus, Allpay, entre autres.

Ces prestataires répondent aux attentes locales. Ils gèrent les paiements en plusieurs fois (tashlumim), jusqu’à douze échéances chez certains, ainsi que Bit, l’application de paiement la plus répandue du pays, et Apple Pay. Ils sont indispensables pour convertir un acheteur israélien. Les applications de paiement ne servent d’ailleurs plus seulement entre particuliers : selon une enquête menée en octobre 2023 et citée par la Banque d’Israël, 42 % des sommes transférées via ces applications allaient à des entreprises, en paiement de biens ou de services. Un tunnel d’achat qui les ignore perd des ventes, un suivi qui les ignore perd des données.

Mais chaque intégration a sa propre logique technique. Et c’est cette logique qui détermine si l’achat sera vu, ou non, par vos outils de mesure.

Le moment critique : le retour vers votre site

Dans une configuration classique, l’acheteur quitte votre site pour payer sur une page hébergée par la passerelle, ou dans un cadre intégré (iframe). Une fois le paiement validé, il doit revenir sur votre page de confirmation. C’est au chargement de cette page que le pixel Meta, la balise Google Ads et GA4 enregistrent l’achat.

Si l’acheteur ne revient pas, l’achat existe dans votre back-office, mais pas dans vos outils publicitaires. Or, il existe beaucoup de raisons de ne pas revenir :

  • il ferme l’onglet dès que la banque confirme le paiement,

  • l’authentification bancaire ouvre une autre fenêtre ou une autre application,

  • sur mobile, le paiement par Bit fait basculer vers l’application, puis le retour s’effectue dans un autre navigateur,

  • la redirection de la passerelle est mal configurée, ou pointe vers une page sans balises,

  • un bloqueur de publicités ou un refus de cookies empêche les balises de se déclencher

Chacune de ces pertes est invisible. Leur somme ne l’est pas.

Les symptômes à reconnaître

Symptôme Cause probable Où vérifier
Moins d’achats dans Meta ou Google Ads que dans le back-office Retour vers la page de confirmation non atteint, balises bloquées Comparaison back-office / Gestionnaire d’événements / Google Ads
Achats comptés deux fois Page de confirmation rechargée, pixel et Conversions API non dédupliqués Gestionnaire d’événements Meta, diagnostic de déduplication
Ventes attribuées au domaine de la passerelle dans GA4 Domaine de paiement non exclu des sites référents GA4, rapport d’acquisition du trafic
Valeur d’achat incohérente Montant d’une échéance transmis au lieu du total, TVA ou devise mal gérées Détail des événements d’achat
Achats attribués au trafic direct Session interrompue par la passerelle, perte des paramètres de campagne GA4, chemins de conversion

Un seul de ces symptômes suffit à fausser vos arbitrages. Deux ou trois ensemble, et vos rapports publicitaires racontent une autre histoire que votre compte en banque.

Le diagnostic en trente minutes

Vous n’avez pas besoin d’un audit complet pour savoir si vous êtes concerné. Ce test suffit.

  1. Exportez vos commandes des sept derniers jours depuis le back-office : nombre et chiffre d’affaires, hors commandes annulées

  2. Relevez les achats enregistrés sur la même période dans le Gestionnaire d’événements de Meta, dans Google Ads (par date de conversion) et dans GA4

  3. Calculez un taux de capture pour chaque outil : achats enregistrés divisés par commandes réelles

  4. Passez une vraie commande test avec chaque moyen de paiement (carte, paiement en plusieurs fois, Bit, Apple Pay), sur mobile et sur ordinateur, et vérifiez en direct l’arrivée des événements

  5. Ouvrez le rapport d’acquisition de GA4 et cherchez les domaines de vos prestataires de paiement parmi les sources de trafic

Voici à quoi peut ressembler le résultat, sur un exemple fictif :

Source Achats enregistrés Taux de capture
Back-office (référence) 120 100 %
GA4 95 79 %
Google Ads 88 73 %
Meta (pixel seul) 70 58 %

Un écart de quelques pourcents est normal : refus de cookies, bloqueurs, fenêtres d’attribution. Un taux de capture inférieur à 80 % signale en revanche un problème structurel. Et un taux qui varie fortement d’une semaine à l’autre signale une configuration fragile.

Shopify : ce qui a changé en août 2026

Shopify a fixé au 26 août 2026 la date limite de mise à niveau des pages « Merci » et « État de la commande ». Les boutiques qui ne l’avaient pas fait ont été mises à niveau automatiquement. Conséquence directe : les anciens scripts collés dans les « scripts supplémentaires » de ces pages ne s’exécutent plus. Si votre suivi des achats reposait sur eux, il s’est peut-être arrêté sans bruit.

Ce qu’il faut faire :

  • Vérifiez vos achats depuis fin août 2026. Une chute brutale du nombre d’achats dans Meta ou Google Ads, sans baisse des ventes, trahit un suivi cassé

  • Passez par les événements clients de Shopify (pixels personnalisés et applications), qui remplacent les scripts supplémentaires

  • Activez le partage de données côté serveur dans l’application Facebook et Instagram de Shopify. Les niveaux « Amélioré » et « Maximum » utilisent la Conversions API : l’achat est transmis de serveur à serveur, sans dépendre du navigateur de l’acheteur

  • Utilisez l’application Google officielle pour Google Ads et GA4, plutôt que des balises ajoutées à la main

Avec une passerelle israélienne intégrée comme application de paiement Shopify, l’acheteur revient en principe sur la page de confirmation de Shopify. Le risque vient surtout des configurations anciennes, des scripts ajoutés à la main et des intégrations qui renvoient vers une page externe.

WooCommerce et PrestaShop : fiabiliser le retour, puis s’en affranchir

Sur WooCommerce et PrestaShop, chaque passerelle s’installe sous forme d’extension ou de module. La qualité de l’intégration varie beaucoup d’un prestataire à l’autre, et d’une version à l’autre.

Première étape : fiabiliser le retour

  • Vérifiez que l’URL de retour après paiement réussi pointe bien vers votre page de confirmation de commande, avec l’identifiant de la commande

  • Testez chaque moyen de paiement : carte, échéances, Bit. Le comportement diffère parfois

  • Assurez-vous que la page de confirmation ne déclenche l’achat qu’une seule fois, même si l’acheteur la recharge

Deuxième étape : envoyer l’achat depuis le serveur

La solution la plus robuste ne dépend plus du retour de l’acheteur. Quand la passerelle confirme le paiement à votre boutique (par une notification serveur), la commande passe au statut « payée ». C’est à ce moment que votre serveur doit envoyer l’événement d’achat à Meta, via la Conversions API, et à Google.

Plusieurs voies existent : l’extension officielle de Meta pour WooCommerce, qui intègre la Conversions API, les modules dédiés pour PrestaShop, ou un serveur de balisage (Google Tag Manager côté serveur) qui centralise l’envoi vers toutes les plateformes.

Troisième étape : dédupliquer

Si le navigateur et le serveur envoient tous deux l’achat, il faut éviter le double comptage. Meta déduplique les événements lorsque le pixel et la Conversions API partagent le même nom d’événement et le même identifiant d’événement, dans un délai de 48 heures, il conserve en général le premier reçu. Utilisez le numéro de commande comme identifiant : il est unique et disponible des deux côtés.

Côté Google Ads, transmettez l’identifiant de transaction avec chaque conversion d’achat. Google s’en sert pour écarter les doublons.

Renforcer la correspondance : les conversions améliorées

Envoyer l’achat ne suffit pas : encore faut-il que la plateforme le relie à la bonne personne, celle qui a vu ou cliqué l’annonce. Plus vous transmettez d’éléments d’identification, mieux la correspondance fonctionne.

Chez Google, les conversions améliorées complètent la balise d’achat avec des données saisies par l’acheteur, comme son adresse e-mail ou son numéro de téléphone. Ces données sont hachées avant l’envoi, puis comparées aux comptes Google connectés. Chez Meta, la Conversions API accepte les mêmes informations, également hachées, qui améliorent la qualité de correspondance des événements.

Sur une boutique israélienne, un détail compte : le format du numéro de téléphone. Transmettez-le au format international (972 suivi du numéro sans le zéro initial), sans quoi une part importante des correspondances échoue.

Les ventes qui ne passent jamais par votre site

En Israël, une part des ventes se conclut hors du tunnel classique : une commande prise sur WhatsApp et réglée par un lien de paiement, une vente par téléphone, un paiement Bit envoyé après échange. Ces ventes sont bien réelles, souvent déclenchées par vos publicités. Elles n’apparaissent pourtant dans aucun outil.

Pour les réintégrer :

  • Enregistrez-les dans votre back-office ou votre CRM, avec les coordonnées du client et la source déclarée

  • Envoyez-les à Meta via la Conversions API, sous forme d’événements hors ligne rattachés aux coordonnées hachées du client

  • Importez-les dans Google Ads comme conversions hors ligne, ou via les conversions améliorées pour les leads si le client avait d’abord rempli un formulaire

Un e-commerçant qui vend 20 % de son chiffre d’affaires sur WhatsApp et n’en déclare rien sous-estime mécaniquement la rentabilité de ses campagnes d’autant.

GA4 : empêcher la passerelle de s’attribuer vos ventes

Quand l’acheteur revient de la page de paiement, GA4 peut considérer qu’il arrive d’un nouveau site, celui de la passerelle. La vente est alors attribuée à « cardcom.co.il / referral » ou à un domaine équivalent, et vos campagnes perdent le crédit de leurs ventes.

La correction se fait en quelques minutes. Dans GA4 : Administration › Flux de données › votre flux web › Configurer les paramètres de la balise › Répertorier les sites référents indésirables. Ajoutez-y les domaines de vos prestataires de paiement, et ceux des pages d’authentification bancaire qui apparaissent dans vos rapports.

Une nuance, signalée par Google lui-même : la correction ne s’applique pas rétroactivement. Pour les utilisateurs déjà venus de ce domaine, le modèle d’attribution peut continuer, un temps, à lui accorder du crédit. Jugez l’effet sur plusieurs semaines.

Tashlumim, devise, TVA : envoyer la bonne valeur

Un achat bien compté, mais mal valorisé, fausse votre ROAS autant qu’un achat perdu.

  • Paiements en plusieurs fois. La valeur transmise doit être le montant total de la commande, et non celui de la première échéance. Vérifiez d’où votre intégration tire ce montant

  • Devise. Transmettez systématiquement le code de devise (ILS pour le shekel). Si vous vendez aussi en euros ou en dollars, chaque commande doit porter sa propre devise

  • TVA et livraison. Décidez une fois pour toutes si la valeur transmise inclut la TVA de 18 % et les frais de livraison, et appliquez la même règle partout. Sinon, le ROAS de Meta et celui de Google ne sont pas comparables

  • Annulations et remboursements. Une commande annulée reste comptée dans les plateformes. Google Ads permet d’ajuster ou de retirer une conversion, tenez au moins compte de votre taux d’annulation dans vos calculs

Vos clients français : la question du consentement

Si votre boutique israélienne vend aussi en France, une partie de vos visiteurs relève du droit européen. Pour eux, les balises publicitaires ne peuvent se déclencher qu’après consentement. Google exige d’ailleurs que les annonceurs transmettent des signaux de consentement pour les utilisateurs de l’Espace économique européen, via le mode consentement, s’ils veulent conserver la mesure et la personnalisation des annonces.

Une partie des achats français restera donc invisible, quoi que vous fassiez. C’est normal, et c’est précisément pour cela que les plateformes modélisent désormais une part des conversions. Dans votre diagnostic, séparez le taux de capture par pays : un écart plus important sur la France ne signale pas forcément une panne.

Qui doit faire quoi

Un problème de suivi se corrige rarement seul, parce qu’il se situe à la frontière de plusieurs métiers :

  • Le prestataire de paiement configure le retour vers votre site et les notifications de paiement

  • Le développeur ou l’intégrateur de votre boutique installe les extensions, la page de confirmation et l’envoi côté serveur

  • L’agence définit les événements, vérifie la déduplication, contrôle les taux de capture et exploite les données dans les campagnes

  • Vous arbitrez, et vous gardez la main sur les comptes

Le piège classique : chacun considère que le problème relève de l’autre. Désignez un responsable unique du suivi, avec un taux de capture cible et un contrôle hebdomadaire.

Ce que la correction change dans vos décisions

Réparer le suivi ne fait pas vendre davantage du jour au lendemain. Cela change en revanche la qualité de toutes vos décisions.

  • Les algorithmes apprennent mieux. Un ensemble de publicités Meta sort généralement de sa phase d’apprentissage après environ 50 événements d’optimisation en sept jours. Si vous n’en transmettez que 58 %, l’apprentissage dure presque deux fois plus longtemps

  • Les stratégies d’enchères deviennent accessibles. Le ROAS cible de Google demande au moins 15 conversions sur 30 jours pour les campagnes Search et Shopping. Des conversions perdues peuvent vous maintenir sous ce seuil

  • Vos arbitrages deviennent justes. Une campagne jugée non rentable l’était peut-être seulement dans le rapport. Avant de couper une campagne ou une créa sur la foi d’un mauvais ROAS, vérifiez toujours le taux de capture

Si vos rapports et votre back-office divergent, c’est le back-office qui a raison. Les rapports publicitaires ne sont qu’une estimation. Nous revenons sur ce décalage dans notre article consacré à l’attribution.

La checklist

  • La passerelle renvoie l’acheteur vers votre page de confirmation, pour chaque moyen de paiement

  • L’achat est envoyé côté serveur (Conversions API, Google), déclenché par le paiement confirmé

  • Le pixel et le serveur partagent le même identifiant d’événement : le numéro de commande

  • Google Ads reçoit l’identifiant de transaction

  • Les domaines de paiement figurent dans les sites référents indésirables de GA4

  • La valeur transmise est le total de la commande, avec la devise, selon une règle unique pour la TVA et la livraison

  • Sur Shopify, plus aucun suivi ne repose sur les anciens scripts supplémentaires

  • Le taux de capture est contrôlé chaque semaine, outil par outil

Questions fréquentes

Faut-il changer de passerelle de paiement ?

Rarement. La plupart des problèmes viennent de la configuration, pas du prestataire. Commencez par le diagnostic et par l’envoi côté serveur. Un changement de passerelle ne se justifie que si l’intégration disponible pour votre plateforme ne permet ni retour fiable ni notification de paiement exploitable.

L’envoi côté serveur suffit-il, sans pixel ?

Il vaut mieux combiner les deux. Meta recommande explicitement une configuration redondante, pixel et Conversions API ensemble, avec déduplication. Le navigateur apporte des signaux de navigation utiles, le serveur garantit que l’achat sera transmis.

En résumé

  • Shopify Payments n’existe pas en Israël : les boutiques passent par des passerelles locales, dont les intégrations sont inégales

  • Les ventes se perdent surtout au retour vers la page de confirmation

  • Le diagnostic prend trente minutes : back-office contre plateformes, commande test, rapport GA4

  • La correction durable passe par l’envoi côté serveur, avec déduplication par numéro de commande

  • Un suivi fiable ne vend pas plus à lui seul, mais il empêche de couper vos meilleures campagnes

Pour aller plus loin

Sources

CONTACT

Prêt à faire
décoller vos pubs ?

Discutons de votre projet et voyons comment nous pouvons vous aider.