Shopify va durcir l’accès à son endpoint de dépôt des cartes bancaires. À partir du 15 octobre 2026, les applications qui déposent des données de carte via le point /sessions devront présenter un certificat client mTLS (mutual Transport Layer Security) délivré par Shopify. Le sujet concerne surtout les marchands avec une application maison, une stack paiement spécifique ou un intégrateur qui manipule des méthodes de paiement dans l’Admin API (Application Programming Interface) GraphQL.
Notre position est claire : à prioriser si votre boutique a du développement paiement spécifique, à ignorer si votre checkout Shopify standard ne collecte jamais de données carte hors flux natif. Le risque n’est pas marketing. Une app non mise à jour peut perdre sa capacité à créer ou modifier des méthodes de paiement carte après la date d’application.
15 octobre 2026 : une échéance courte pour les apps qui touchent aux cartes
Le changement vise le dépôt préalable des données carte avant les mutations customerPaymentMethodCreditCardCreate et customerPaymentMethodCreditCardUpdate. Shopify ajoute une authentification forte entre l’app et son endpoint sensible. mTLS vérifie aussi le client qui appelle le service, pas seulement le serveur appelé.
Un marchand doit surtout identifier qui, dans son écosystème, envoie encore ce type de requête : app privée, connecteur abonnement, outil de compte client, intégration de paiement récurrent ou développement d’agence. La mauvaise réponse consiste à supposer que Shopify gère tout automatiquement.
Apps d’abonnement et cartes enregistrées : le vrai périmètre à vérifier
Cette annonce ne justifie pas une refonte du checkout. Elle justifie un inventaire technique ciblé. Une marque Shopify Plus avec abonnement, espace client avancé et reprise de carte enregistrée peut demander à son développeur de vérifier en deux heures si l’app appelle le card-deposit endpoint, si un certificat Shopify est nécessaire et quelle version d’API est utilisée.
La mesure utile n’est pas le nombre d’apps installées, mais le nombre de flux qui écrivent ou mettent à jour une carte. Si aucun flux n’existe, le sujet sort de la roadmap. Si un seul flux existe, il mérite un ticket daté, avec test sur environnement de développement avant septembre.
Un ticket sécurité vaut mieux qu’un incident checkout
Les marchands doivent traiter cette mise à jour comme une dette de conformité technique. Le bon arbitrage consiste à ajouter une vérification au prochain sprint, puis à demander une preuve simple : appel de dépôt carte testé avec certificat, logs propres et absence d’erreur sur création ou modification de méthode de paiement.
Nous pensons que les boutiques concernées doivent prioriser maintenant, car le coût d’un contrôle est faible et l’incident potentiel touche le paiement. Les autres peuvent documenter le non-sujet et passer à des chantiers plus proches du chiffre d’affaires.
