Attaque de phishing du checkout Shopify : Que s'est-il passé et comment vérifier votre boutique

L’attaque de phishing du checkout Shopify est une campagne, signalée pour la première fois le 10 octobre 2026, au cours de laquelle des applications storefront tierces ont été détournées pour charger du code envoyant les acheteurs qui cliquaient sur Checkout vers une fausse page de paiement. Cette fausse page capturait leurs coordonnées bancaires, puis les transférait vers le véritable checkout de la boutique.

Statut, vérifié le 19 octobre 2026 : De nouvelles activités ont été signalées pas plus tard que le 18 octobre. Swym a déclaré dans une FAQ qu’une activité non autorisée ayant débuté à 21:17 UTC a utilisé l’accès de l’application Wishlist Plus pour ajouter des scripts sur certaines boutiques, l’éditeur a donc désactivé l’application pour tous les marchands et révoqué ses identifiants Shopify. Swym a depuis retiré cette FAQ, et sa page de statut indique toujours un incident en cours. Les fiches de l’App Store pour Hulk Product Options, Swym Wishlist Plus, Selleasy, Boost AI Search & Filter et Privy indiquent toutes “actuellement indisponible”. Boost et Privy n’ont pas fait de lien entre l’indisponibilité de leur fiche et cette campagne.¹²³

Points clés

• Depuis au moins le 10 octobre 2026, certains acheteurs ayant cliqué sur Checkout ont vu un faux checkout qui envoyait les détails de leur carte à un attaquant, puis les redirigeait vers le vrai checkout.
• HulkApps, Selleasy et Swym ont confirmé qu’une partie non autorisée a modifié ce que leurs applications chargeaient sur certains storefronts. Aucun n’a publié l’origine exacte de la faille.
• Aucune source n’indique que le checkout ou les systèmes de Shopify ont été compromis. Le code s’exécutait sur les pages du storefront, avant que le checkout ne se charge.
• Lors de la première vague, le code est arrivé à l’intérieur des paramètres des applications, et non dans les fichiers du thème, donc une simple recherche dans le code l’aurait manqué. Le test du checkout en direct est la vérification qui compte.
• Chaque application qui charge du code sur votre storefront est du code que quelqu’un d’autre peut modifier. Supprimer celles dont vous n’avez pas besoin réduit durablement ce risque.

Pourquoi vous pouvez nous faire confiance

Jacques a plus de 15 ans d’expérience en développement, et nous avons passé plus de quatre ans à travailler dans les thèmes Shopify pour des centaines de marchands. Nous construisons Fudge, l’opérateur IA pour les boutiques Shopify, avec une note de 4.9 sur le Shopify App Store. Il lit le véritable code du thème d’une boutique et peut tester un storefront en direct dans un vrai navigateur.

Ceci n’est pas un rapport d’investigation. Chaque affirmation ci-dessous est liée à une déclaration de l’éditeur, à la documentation de Shopify ou au développeur qui a découvert l’attaque, et nous le précisons lorsqu’une affirmation repose sur le signalement d’une seule personne.

Que s’est-il passé lors de l’attaque de phishing du checkout Shopify ?

Le développeur Roman Zipp l’a découverte par accident le 10 octobre. Il achetait sur la boutique Shopify d’un vendeur de claviers, a cliqué sur Checkout, et son gestionnaire de mots de passe a essayé de remplir les mauvais champs sur une page qui ressemblait au checkout de Shopify. La barre d’adresse affichait un domaine qu’il ne connaissait pas.⁴

Il a répété l’opération dans une fenêtre de navigation privée avec des coordonnées de test. Le formulaire les a envoyées au serveur de l’attaquant, qui a répondu par un numéro d’enregistrement, puis la page l’a redirigé vers le véritable checkout de la boutique.⁴

Il a remonté la piste du code jusqu’à Hulk Product Options et l’a signalé. Sa chronologie montre que le détournement a disparu de cette boutique 16 minutes après que Shopify l’a escaladé en interne. Dans les jours qui ont suivi, des marchands n’ayant jamais installé d’application HulkApps ont signalé le même faux checkout, et Selleasy ainsi que Swym ont confirmé des incidents de leur côté.⁴⁵⁶⁷

Chronologie

Comment fonctionnait la fausse redirection du checkout ?

Les attaquants n’ont jamais touché au checkout de Shopify. Ils ont détourné le clic qui y mène.

Les applications insèrent du code sur votre storefront via les app embeds, que Shopify injecte juste avant la balise de fermeture </head> ou </body> de chaque page.¹¹ Le checkout est un monde à part : les applications qui l’étendent s’exécutent dans une sandbox isolée, sans accès à la page de paiement ni aux coordonnées bancaires.¹² Nous couvrons cette sandbox dans notre guide sur l’extensibilité du checkout Shopify.

Le code s’exécutait donc sur la page produit et le panier, attendait un clic sur Checkout, et envoyait l’acheteur ailleurs avant que le checkout de Shopify ne puisse se charger.

Route 1 : le code caché dans les paramètres de l’application

De nombreuses applications de storefront intègrent un petit script qui, à chaque chargement de page, demande aux serveurs de l’éditeur les paramètres de cette boutique. Dans la première vague, ces paramètres étaient le payload.

• HulkApps : le script de l’application provenait du CDN de Shopify et était sain. Zipp a trouvé environ 22,7 Ko de JavaScript supplémentaire dans un champ de code personnalisé des paramètres téléchargés depuis l’API de HulkApps.⁴
• Selleasy : l’avis envoyé aux marchands indique qu’une personne externe s’est introduite dans un outil interne de Selleasy et a planté un script dans les paramètres Selleasy de plusieurs boutiques.⁵
• Swym (14 octobre) : Swym décrit une modification non autorisée de la configuration de l’application. Le développeur Dan Sutherland, qui a enquêté sur une boutique touchée, signale que la chaîne de l’attaque se trouvait à la place du texte du bouton “Ajouter à la Wishlist”.⁷¹³
• Qikify (juillet) : du code a été planté dans les champs HTML personnalisables des paramètres de l’application, et Qikify affirme que rien n’a été écrit dans les thèmes des marchands.⁸

Une recherche dans le code du thème n’aurait trouvé aucun de ces éléments. Le code résidait sur les serveurs de l’éditeur et n’apparaissait que dans le navigateur de l’acheteur.

Route 2 : utiliser l’accès de l’application à la boutique

L’incident de Swym du 18 octobre est différent. Swym indique que l’activité a utilisé le propre accès de l’application Wishlist Plus aux boutiques des marchands, et non les comptes employés des marchands, pour ajouter des scripts tentant de rediriger les acheteurs. Swym conseille aux marchands de vérifier leurs fichiers de thème à la recherche de modifications apportées par l’application Swym et d’y chercher le terme checkout-guard.¹

Cela rend une recherche dans le thème utile. Nous expliquons comment faire ci-dessous.

Ce que faisait le code dans le navigateur de l’acheteur

D’après le code capturé par Zipp :⁴

1. Il écoutait le clic ou l’appui sur Checkout.
2. Il chargeait un faux checkout sur un domaine externe.
3. Les données de la carte partaient vers le serveur de l’attaquant.
4. L’acheteur était redirigé vers le véritable checkout pour payer à nouveau, de sorte que la commande passait tout de même.
5. Il définissait __ctf_shim_handoff_done_v1 dans le session storage pour ne pas se déclencher deux fois pour le même acheteur.

HulkApps ajoute que la redirection a échoué lors de certaines visites et que certains navigateurs l’ont bloquée.⁹ En somme, un propriétaire de boutique testant son propre checkout pouvait facilement ne rien remarquer.

Domaines identifiés à ce jour

Ne les visitez pas. Chacun est écrit avec des crochets pour ne pas être cliquable.

Comment les attaquants se sont-ils introduits ?

Personne ne s’est exprimé publiquement. HulkApps parle d’un “exploit”. Selleasy mentionne un outil interne. Swym décrit une modification non autorisée, puis l’utilisation de l’accès de l’application.⁹⁵¹

Zipp énumère quatre possibilités pour le cas HulkApps et n’en a confirmé aucune : le compte HulkApps d’un marchand, le compte d’un employé de HulkApps, HulkApps lui-même, ou une autre application altérant la configuration.⁴

Quelles applications Shopify étaient concernées ?

Il n’y a aucune preuve qu’un de ces éditeurs ait écrit le code malveillant. HulkApps, Selleasy, Swym et Qikify déclarent que les attaquants ont utilisé leurs applications pour le diffuser.

Hulk Product Options a-t-il été piraté ? Ce que dit HulkApps

Selon HulkApps, un exploit a glissé des configurations non autorisées dans Hulk Product Options le 10 octobre, dans le cadre d’une attaque plus large visant plusieurs applications Shopify. HulkApps retrace chaque redirection liée à ses applications à un seul endroit, l’extension de thème Hulk Product Options. Shopify a désactivé cette extension par précaution avant de la restaurer plus tard.⁹

L’entreprise a engagé une société de sécurité indépendante, renforcé l’authentification et informé les marchands qu’ils n’avaient pas besoin de désinstaller l’application. La fiche indiquait toujours qu’elle était indisponible le 19 octobre.⁹³

Selleasy (Logbase)

Logbase qualifie la journée du 13 octobre d’attaque délibérée et planifiée qui a injecté un script dans certaines des boutiques desservies par Selleasy. Ils n’ont trouvé aucune preuve de faille de leur backend ou base de données, et déclarent que Shopify a confirmé la suppression du code le jour même.⁶

Son avis aux marchands concernés ajoute la fenêtre horaire, de 07:47 à 15:00 UTC, et indique qu’ils ont verrouillé le paramètre Custom JS afin qu’aucun outil ou API ne puisse le modifier.⁵

Swym Wishlist Plus (Swym)

Swym a publié deux incidents :

1. 14 octobre : un changement de configuration a fait charger un script sur certains storefronts, qui a pu envoyer les acheteurs vers un faux checkout. Swym a renouvelé ses clés d’API et ajouté des règles de nettoyage. Ils demandent aux marchands de signaler tout ce qu’ils ont observé entre 10:06 et 16:32 UTC.⁷
2. 18 octobre : de nouvelles activités ont utilisé l’accès de l’application pour ajouter des scripts à certaines boutiques. Swym a désactivé l’application pour tous les marchands, révoqué ses identifiants Shopify, et déclare ne pas pouvoir encore confirmer ni infirmer un quelconque impact sur les acheteurs.¹

Swym a publié les détails du 18 octobre dans une FAQ le 19 octobre et l’a retirée plus tard le même jour. Sa page de statut décrit toujours un incident en cours et, à 15:30 UTC le 19 octobre, indiquait que Swym se préparait à déployer des mesures d’atténuation.¹²

Non confirmé : Boost AI Search & Filter et Privy

Aucun de ces deux éditeurs n’a lié ses problèmes à cette campagne, et une fiche indisponible ne prouve pas qu’une application a été compromise. Les deux fiches étaient indisponibles le 19 octobre.³

• Boost : sa page de statut indique que son extension d’application de thème a été désactivée pour toutes les boutiques le 17 octobre et que Shopify l’a réactivée le lendemain. Elle décrit un incident affectant les fonctionnalités de l’application et ne mentionne pas la sécurité.¹⁴ Un membre sur le fil de la Communauté Shopify affirme que la même redirection est apparue le 17 octobre sur une boutique sur laquelle il travaille, via l’application Boost.⁵
• Privy : sa page de statut signale une interruption de ses affichages sur site du 17 au 18 octobre, sans mentionner la sécurité.¹⁵ Un commentateur sur le post de Zipp cite Privy comme étant la source sur ses boutiques.⁴

Plus tôt : l’incident de Qikify en juillet

L’avis publié par Qikify couvre le 22 juillet 2026, date à laquelle certains checkouts de ses applications Sticky Add to Cart et Mega Menu ont été détournés vers une page frauduleuse via les champs de paramètres des applications. Qikify a réinitialisé l’authentification sur l’ensemble de ses applications le 29 juillet, et les deux étaient de retour sur l’App Store le 21 août.⁸

Le post de Zipp mentionne également un cas en août chez Hextom. Hextom n’a publié aucun avis et nous n’avons pas pu le vérifier.

Shopify a-t-il été piraté ? Ce qu’a dit Shopify

Aucune publication à ce jour ne l’affirme. Ni Shopify ni aucune déclaration d’éditeur ne décrivent une compromission des systèmes propres de Shopify.

Shopify n’a publié aucun post ni mise à jour de changelog concernant cette campagne en date du 19 octobre. Un porte-parole a déclaré à iTnews : “Quand une application n’est pas à la hauteur, nous agissons.” Shopify précise que cela peut signifier le retrait de l’application, et dans ces cas, il demande au développeur de l’application de contacter directement les marchands concernés.¹⁰ Sa page de politique des Partenaires liste également des options plus strictes, notamment le retrait d’une application des boutiques des marchands et la coupure de son accès API.¹⁶

Shopify a agi sur des signalements individuels. Une marchande australienne touchée via Selleasy a été conseillée de garder sa boutique fermée pendant que Shopify enquêtait, et a déclaré le 19 octobre à iTnews que Shopify l’avait autorisée à rouvrir.¹⁰⁵

Comment vérifier si votre boutique est touchée par la fausse redirection du checkout ?

Dupliquez votre thème en ligne avant de modifier quoi que ce soit (Boutique en ligne, menu … sur votre thème, Dupliquer). Ensuite, suivez ces étapes dans l’ordre.

1. Faites le test du checkout en cinq minutes

C’est le contrôle qui aurait repéré la première vague.

• Ouvrez une nouvelle fenêtre de navigation privée. Elle démarre avec un stockage de navigateur vide, ce qui compte doublement : le script se déclenchait une fois par session, et un développeur rapporte que les paramètres de Swym restaient en cache dans le navigateur, ce qui pouvait maintenir le payload actif même après la désactivation de l’application.¹³
• Ajoutez un produit au panier et utilisez le bouton Checkout standard plutôt qu’une option expresse comme Shop Pay ou PayPal.
• Lisez la barre d’adresse au moment où la page du checkout apparaît. Le checkout de Shopify s’exécute sur votre propre domaine, ou sur votre adresse myshopify.com si vous n’en avez pas connecté un. Shopify l’y a déplacé en 2017.¹⁷ Tout autre domaine à ce stade est un signal d’alarme. N’entrez pas de coordonnées bancaires. Traitez-le comme un incident.
• Fermez la fenêtre, ouvrez-en une nouvelle, et recommencez depuis le tiroir du panier. Qikify indique que sa redirection Sticky Add to Cart se déclenchait lorsque les acheteurs cliquaient sur Checkout depuis le tiroir du panier.⁸
• Répétez l’opération une fois de plus sur votre téléphone.

Les pages de carte de votre fournisseur de paiement ou de votre banque, comme 3-D Secure, peuvent apparaître plus tard dans le checkout. Le signal d’alarme est un domaine différent au moment où la page de checkout se charge initialement.

2. Trouvez toutes les applications pouvant exécuter du code sur vos pages

• Paramètres > Applications liste vos applications installées.¹⁸ Notez Hulk Product Options, Swym Wishlist Plus et Selleasy (incidents confirmés), et si vous utilisez Boost AI Search & Filter ou Privy. Ouvrez n’importe quelle application pour voir sa carte Extensions, qui montre ce qui est actif et où.¹⁸
• Boutique en ligne > Modifier le thème, puis l’icône App embeds dans la barre latérale, affiche chaque embed qui est activé.¹⁹ Chacun d’eux peut charger du code sur chaque page.

3. Cherchez les marqueurs connus dans votre thème

Allez dans Boutique en ligne, ouvrez le menu … de votre thème publié et choisissez Modifier le code. Le bouton de recherche dans la barre latérale gauche effectue une recherche dans tous les fichiers du thème.²⁰ Pour une visite guidée de l’éditeur, voir comment modifier votre thème Shopify.

Cherchez :

• Chaque domaine du tableau ci-dessus, sans les crochets (par exemple biliing.top)
• checkout-guard, que Swym demande aux marchands de rechercher¹
• __ctf_, le préfixe des clés de stockage trouvées par Zipp⁴

Chercher uniquement .top vous inondera de correspondances CSS et JavaScript inoffensives.

Une recherche vierge couvre uniquement le thème. Le code qui arrive dans les paramètres d’une application n’y apparaît jamais.

4. Optionnel : regardez dans les DevTools du navigateur

Si vous connaissez les Chrome DevTools, ouvrez-les pendant un checkout de test. Cherchez les clés __ctf_ sous Application > Session storage. Dans l’onglet Network, vérifiez chaque domaine que contactent vos pages produit et panier, et assurez-vous de connaître le propriétaire de chacun.

5. Écoutez vos clients

Parce que la fausse page renvoyait les acheteurs vers le vrai checkout, les commandes peuvent sembler tout à fait normales. Les signaux viennent plutôt des clients : un email du support concernant une page de paiement à l’aspect étrange, ou un signalement de fraude à la carte peu après avoir commandé chez vous.

Fudge peut-il vérifier ma boutique pour cette redirection ?

En partie. Fudge peut exécuter le test de checkout en direct qui aurait détecté la première vague, et chercher les marqueurs du 18 octobre dans votre thème. Il ne peut pas voir les serveurs des éditeurs ni prouver qu’aucune carte n’a été dérobée.

Ce que Fudge peut vérifier

• Le test en direct, dans un vrai navigateur. Fudge ouvre votre boutique en ligne, ajoute un produit, clique sur Commander depuis la page panier et le tiroir du panier, et enregistre chaque page sur laquelle il atterrit, chaque domaine que la page contacte, et ce que ces requêtes renvoient. C’est là que le code caché dans les paramètres de l’application apparaît. C’est la même fonctionnalité qui se trouve derrière notre parcours du flux de paiement.
• La recherche de thème. Fudge peut chercher dans chaque fichier de votre thème publié les domaines et marqueurs ci-dessus, et lister les app embeds qui sont activés. Voir notre investigation du code de thème.
• Un test sur un brouillon. Il peut désactiver un embed suspect dans une copie brouillon de votre thème pour le tester. Si vous avez déjà vu une redirection, n’attendez pas de faire un brouillon : désactivez l’embed sur votre thème publié dès maintenant.

Ce qu’une vérification Fudge ne peut pas prouver

• Il ne peut pas lister vos applications installées ni lire les paramètres à l’intérieur de l’admin propre à une application.
• Il ne peut pas voir les serveurs des éditeurs ou leurs logs, ni vous dire si une carte a été capturée.
• Il s’exécute depuis un navigateur cloud situé à un endroit précis. Personne ne sait si ce code évitait les navigateurs automatisés ou certains pays, et il échouait déjà lors de certaines visites.
• Il ne peut pas gérer la réponse à votre place : le Support Shopify, votre processeur de paiement et vos clients.

Ainsi, le résultat honnête d’une vérification sans anomalie est : aucune redirection ou marqueur connu n’a été vu lors de ce test, à ce moment précis. Ce n’est pas : votre boutique n’a jamais été touchée.

Prompt : demander à Fudge de lancer la vérification

Copiez ceci dans Fudge :

Run a read-only security check of my published Shopify store for the October 2026 checkout phishing redirect. Do not edit, draft or publish anything. Do not type payment details, and do not submit any form on a page outside my store’s domain.

1. On my published store, use a separate browser agent for each run so each one starts with empty storage. At mobile and desktop sizes, open a product page, add it to the cart, and click the main Checkout button, once from the cart page and once from the cart drawer. Report every URL the browser lands on, and tell me straight away if it leaves my store’s domain or myshopify.com address before the checkout page loads.
2. List every outside domain that loads scripts or receives requests on the product and cart pages, grouped by the app or service it belongs to. Flag any domain ending in .top and any response that contains a redirect.
3. Check session storage and local storage for keys starting with __ctf_ and, if you can tell, which script set them.
4. Search every file in my published theme for biliing.top, checkout-confirm.top, order-confirm.top, account-confirm.top, billing-confirm.top, checkout-guard, checkout-secure.top and __ctf_, plus any script that sends shoppers to another domain when they click Checkout.
5. List the app embeds switched on in my published theme and the app behind each one.

For every finding, give the file or URL, what the code does, and how confident you are. End by listing what this check could not see.

Que faire si votre boutique est touchée ?

D’abord, limitez les dégâts

• Capturez les preuves. Faites une capture d’écran de la fausse page avec son adresse visible, copiez l’URL complète, et notez l’heure. Dans les DevTools, vous pouvez sauvegarder le log Network sous forme de fichier HAR. Les fichiers HAR peuvent contenir vos cookies de connexion, donc partagez-les uniquement avec le Support Shopify ou l’éditeur de l’application.
• Désactivez le code. Désactivez l’embed de l’application sous App embeds et enregistrez, ou désinstallez l’application.¹⁹ Désinstaller ne supprime pas toujours tout ce qu’une application a ajouté à votre thème, alors vérifiez aussi le thème.²¹ Notre guide sur comment supprimer le code restant d’une application détaille cette étape.
• Testez à nouveau dans une nouvelle fenêtre de navigation privée. Les paramètres en cache peuvent survivre à la désactivation de l’application.¹³

Ensuite, signalez-le

• L’éditeur de l’application : obtenez des informations par écrit : ce qui a été injecté, quand cela a été actif sur votre boutique, et leur déclaration publique.
• Le Support Shopify : envoyez vos preuves et préparez-vous à ce que Shopify vous suggère de fermer la boutique pendant son enquête, comme il l’a fait pour au moins un marchand.⁵
• Votre processeur de paiement : pour Shopify Payments, signalez-le dans votre ticket de Support. Pour toute autre passerelle, contactez-les directement. Les cartes peuvent avoir été copiées même sur les commandes qui se sont terminées normalement.
• Le domaine : Zipp a signalé les domaines qu’il a trouvés à Google Safe Browsing et URLhaus, ce qui aide les navigateurs à commencer à avertir les acheteurs.⁴

Puis, verrouillez les portes

• Changez votre mot de passe Shopify et votre mot de passe pour le tableau de bord de chaque éditeur d’application, et activez l’authentification en deux étapes.²²
• Sous Paramètres > Utilisateurs, filtrez sur Collaborateurs et supprimez tout accès partenaire dont vous n’avez pas besoin. Générer un nouveau code de demande de collaborateur invalide l’ancien.²³
• Passez en revue les applications et les outils d’IA qui ont accès à votre boutique, comme le suggère Zipp.⁴ Cela inclut Fudge.
• Demandez à un avocat et à votre processeur de paiement si vous devez informer les acheteurs ou les régulateurs. Swym renvoie les marchands aux lois sur la notification des violations et la protection des données, ainsi qu’à l’accord de leur processeur de paiement.⁷ Ceci n’est pas un conseil juridique.

Que dire aux clients qui posent la question : votre véritable checkout réside sur votre propre domaine. S’ils ont vu une adresse différente lors du paiement, ils doivent appeler l’émetteur de leur carte au sujet de la carte. Attendez avant de faire des promesses de remboursement tant que votre processeur de paiement n’a pas examiné votre dossier.

Comment réduire les risques liés aux applications storefront ?

Chaque application qui charge du code sur votre storefront est du code que quelqu’un d’autre peut modifier. Cela inclut les applications en qui vous avez confiance.

Lorsqu’une application récupère ses paramètres sur les serveurs de l’éditeur à chaque chargement de page, ce qui s’exécute sur votre boutique peut changer sans la moindre modification de votre thème. Rien ne s’affiche dans les fichiers ou l’historique de votre thème. Vous le découvrez lorsqu’un client le signale.

Shopify restreint la façon dont les applications chargent du code. Depuis le 1er octobre 2026, les applications ne peuvent plus créer de nouvelles balises de script, et Shopify cessera de charger les balises de script des storefronts le 1er mars 2027.²⁴ Cela laisse les app embeds comme la principale voie prise en charge, et vous pouvez les examiner depuis un seul panneau. Cela n’empêche pas un embed de récupérer du nouveau code auprès de son éditeur, et une application ayant accès au thème peut toujours modifier ses fichiers.

Posez trois questions pour chaque app embed

1. L’utilisons-nous toujours ? Si ce n’est pas le cas, désinstallez-la et nettoyez ce qu’elle a laissé derrière elle.
2. A-t-elle un paramètre Custom JavaScript ou Custom HTML ? Ouvrez-le et assurez-vous de reconnaître tout ce qu’il contient. Zipp a trouvé le payload de HulkApps dans un champ JavaScript personnalisé, Selleasy a verrouillé son paramètre Custom JS après l’attaque, et Qikify mentionne deux champs de contenu HTML.⁴⁵⁸
3. Votre thème pourrait-il faire ce travail lui-même ?

Déplacez ce que vous pouvez dans votre thème

Certaines des tâches effectuées par ces applications peuvent être intégrées directement dans votre thème. Le code natif réside dans vos fichiers de thème, ne change que lorsque quelqu’un les modifie, et tout développeur peut le lire. Il n’est pas immunisé : une application avec un accès au thème peut toujours le modifier, c’est pourquoi Swym demande aux marchands de vérifier leurs fichiers de thème. Mais une modification de celui-ci apparaît dans une recherche de code.

• Les options de produits telles que la gravure de texte, les notes cadeaux et les échantillons peuvent utiliser des variantes et des propriétés de ligne d’article. Les options qui modifient le prix nécessitent des variantes ou un produit d’ajout séparé. Notre guide de configurateur de produits couvre ces éléments de base.
• Les upsells et cross-sells du panier peuvent utiliser les recommandations de produits propres à Shopify dans une section panier. Voir comment ajouter des upsells dans le panier Shopify.
• Les offres groupées (bundles) peuvent souvent utiliser les bundles natifs de Shopify. Nous avons comparé les deux dans les bundles Shopify natifs face aux applications de bundles.

Certaines applications justifient leur présence. Une wishlist qui se synchronise entre les appareils ou une recherche sur un vaste catalogue nécessite généralement un backend. Gardez-les, désactivez tous les paramètres de code personnalisé que vous n’utilisez pas, et relancez le test de checkout après chaque mise à jour.

Avec Fudge, la méthode native commence par un prompt comme celui-ci (notre page sur les applications que Fudge remplace liste davantage de ces tâches) :

Hulk Product Options currently shows these options on my product pages: [engraving text, max 20 characters; gift wrap yes/no, +$5]. If they still render on my live product page, check them there too. Rebuild them as native theme code and save each choice as a line item property so it shows on the order. For options that change the price, explain the approaches and trade-offs before you build. Work in a draft theme so I can test it before I remove the app.

Fudge est également une application avec un accès à votre thème, donc les mêmes conseils s’appliquent à nous : n’accordez que l’accès que vous utilisez et passez-le en revue. Les modifications que vous demandez à Fudge vont dans un thème en brouillon, et aucune d’elles n’atteint votre boutique en ligne tant que vous ne les avez pas examinées et publiées dans l’éditeur de boutique Shopify.

La conformité PCI de Shopify couvre-t-elle cela ?

Shopify est certifié conforme PCI DSS de niveau 1.²⁵ Selon notre lecture, cette certification concerne la plateforme et le checkout de Shopify. Elle ne peut se porter garante de ce qu’un script tiers fait sur votre page produit avant que l’acheteur n’y arrive.

Le Conseil des Normes de Sécurité PCI (PCI SSC) a un nom pour ce type de schéma, le double-entry skimming (écrémage à double saisie) : un faux formulaire de paiement est présenté d’abord, et l’acheteur saisit à nouveau ses détails sur le vrai.²⁶ Ses exigences en matière de scripts pour les pages de paiement, 6.4.3 et 11.6.1, sont entrées en vigueur le 31 mars 2025, mais la FAQ du Conseil précise que le contrôle SAQ A associé vise les marchands qui intègrent un formulaire de paiement sur leurs propres pages, et non ceux qui redirigent les acheteurs vers la page d’un fournisseur.²⁷²⁸ La FAQ ne nomme pas Shopify, alors demandez à votre acquéreur comment un checkout hébergé par Shopify est classé pour votre boutique.

FAQ