PrestaShop : boutique non vérifiée (accounts-api/connect-error), causes et solutions

Votre boutique PrestaShop reste « Non vérifiée » et affiche l’erreur accounts-api/connect-error ? La vérification se passe en deux sens : votre boutique contacte l’API PrestaShop Accounts, puis cette API rappelle votre boutique pour contrôler une « preuve ». Si l’un des deux sens est bloqué (pare-feu, WAF, proxy, adresse IP mal réputée), la vérification échoue. Cet article explique comment le vérifier en quelques commandes, quelles sont les causes connues et que demander à votre hébergeur.

Il s’appuie sur un cas réel que nous avons diagnostiqué sur l’une de nos boutiques (PrestaShop 9.2.0, module PrestaShop Account 8.0.20, la dernière version à ce jour) et sur les rapports publics du dépôt GitHub du module.

Mise à jour du 26 octobre 2026 : problème résolu. Dans notre cas, la cause était une des trois adresses IP de PrestaShop, 104.199.32.134, bloquée par le pare-feu ModSecurity de l’hébergeur (PlanetHoster) à cause d’une inscription sur la liste de réputation « Malware Expert ». Après l’intervention de l’hébergeur (levée du blocage et demande de délistage), la vérification a réussi. Le détail, avec les adresses IP concernées et le message à envoyer au support, est dans la section Le dénouement chez PlanetHoster.

À quoi ressemble le problème

Dans le back-office, ouvrez Modules > Gestionnaire de modules > PrestaShop Account > Configurer. Le bloc « Informations sur la boutique » affiche le statut Non vérifié, puis le message suivant : « Échec de la vérification de la boutique : le serveur de la boutique a renvoyé une erreur lors de la tentative d’accès à l’API Accounts. »

Le même blocage apparaît dans d’autres modules qui dépendent de PrestaShop Account. Dans PrestaShop Checkout (paiement PayPal), la section « Verify your store » (« Vérifiez votre boutique ») affiche « Store verification failed » avec le même code. Des commerçants le signalent aussi avec PrestaShop Social (Facebook et Instagram) et lors de la connexion à la place de marché de modules.

Concrètement, tant que la boutique n’est pas vérifiée, la configuration de ces modules peut rester incomplète. Le catalogue, les commandes et le reste de la boutique continuent en revanche de fonctionner.

Comment fonctionne la vérification

La vérification n’est pas un simple « ping » : la boutique doit prouver qu’elle est bien joignable depuis Internet à l’adresse déclarée. Voici les trois étapes, telles que le module les exécute dans la version 8.0.20.

1. La boutique contacte l’API. Le module génère une « preuve » aléatoire, l’enregistre dans la configuration, puis envoie une requête POST à accounts-api.distribution.prestashop.net/v1/shop-identities/{id}/verify, avec les adresses du front-office et du back-office. Le module n’attend la réponse que 10 secondes.
2. L’API rappelle la boutique. Depuis ses propres serveurs, l’API appelle l’adresse /module/ps_accounts/apiV2ShopProof de votre boutique, avec un en-tête X-PrestaShop-Authorization qui contient un jeton signé.
3. La boutique répond. Si la preuve correspond, la boutique passe au statut « Vérifié ».

Deux conséquences importantes pour le diagnostic :

• Un blocage peut se produire dans les deux sens. Votre serveur doit pouvoir sortir vers l’API (étape 1), et les serveurs de PrestaShop doivent pouvoir entrer chez vous (étape 2).
• Le message d’erreur ne dit pas lequel. Si l’étape 2 est bloquée, l’API attend en vain et finit par ne pas répondre à l’étape 1 : vous voyez alors une erreur de connexion, alors que la sortie fonctionne parfaitement.

Après deux échecs de suite, le module active en plus un coupe-circuit : il cesse de contacter l’API pendant 30 secondes (valeurs par défaut de la version 8.0.20) et affiche immédiatement « Circuit Breaker Open ». Ce message est une conséquence, pas une cause : attendez une minute entre deux essais pour que le test soit réel.

Diagnostic en 6 étapes

Remplacez votre-boutique.com par votre domaine. Les commandes se lancent depuis n’importe quel terminal, sauf indication contraire.

Étape 1 : consulter le bilan de santé du module

Le module expose une page publique qui résume son état :

curl -s "https://votre-boutique.com/index.php?fc=module&module=ps_accounts&controller=apiV2ShopHealthCheck"

Vous obtenez un document JSON. Vérifiez ces champs :

Si tout est au vert, comme dans notre cas, le problème ne vient ni du module, ni de PHP, ni de votre compte : il vient du réseau. Passez à l’étape 2.

Étape 2 : tester la sortie vers l’API

Depuis le serveur de la boutique (en SSH) :

curl -sI https://accounts.distribution.prestashop.net | head -1
curl -s -o /dev/null -w "%{http_code}\n" https://accounts-api.distribution.prestashop.net

La première commande doit répondre 200. La seconde répond 404 : c’est normal, la racine de l’API ne sert aucune page, mais cela prouve que la connexion et le certificat fonctionnent. Un délai dépassé, une réinitialisation de connexion ou une erreur de certificat indiquent au contraire un blocage sortant.

Testez aussi depuis PHP via le web, pas seulement en ligne de commande : certains hébergements appliquent des règles différentes aux deux. Le bilan de santé de l’étape 1 le fait déjà : son champ accountsApiConnectivity est calculé par la boutique elle-même, pendant une requête web.

Étape 3 : tester l’entrée, c’est-à-dire l’appel de retour

Appelez vous-même l’adresse que l’API doit joindre :

curl -s -w "\n%{http_code}\n" "https://votre-boutique.com/module/ps_accounts/apiV2ShopProof"

Réponse attendue : {"error":true,"message":"Authorization header is required."} avec le code 401. C’est le bon résultat : l’adresse répond, elle refuse seulement l’appel sans jeton.

Ajoutez ensuite l’en-tête exact que le module attend. Attention : ce n’est pas Authorization, mais X-PrestaShop-Authorization :

curl -s -H "X-PrestaShop-Authorization: Bearer test" "https://votre-boutique.com/module/ps_accounts/apiV2ShopProof"

Réponse attendue : {"error":true,"message":"Invalid token"}. Cela prouve que l’en-tête arrive bien jusqu’à PHP. Si vous obtenez de nouveau « Authorization header is required », un serveur intermédiaire (proxy inverse, règle .htaccess ou Nginx) supprime l’en-tête.

Ces tests réussissent depuis votre connexion, mais ils ne prouvent pas que les serveurs de PrestaShop passent : un pare-feu peut les bloquer eux seuls. C’est l’objet de l’étape 5.

Étape 4 : lire le journal du module

Le module écrit dans var/logs/, dans un fichier du type ps_accounts-2026-10-24 :

grep -E "Curl error|Circuit Breaker|Unauthorized|Authorization" var/logs/ps_accounts-*

Attention : les lignes d’erreur détaillées contiennent le jeton d’autorisation de votre boutique. Ne les copiez jamais telles quelles dans un forum, un ticket public ou un dépôt GitHub. Ne conservez que le message d’erreur et l’heure.

Étape 5 : vérifier si l’appel de retour arrive

C’est l’étape qui tranche. Pendant que vous cliquez sur « Vérifier », regardez le journal d’accès de votre serveur (panneau de l’hébergeur ou access.log) et cherchez une requête sur apiV2ShopProof.

• Elle apparaît avec un code 200 ou 401 : l’appel arrive, le problème est ailleurs (jeton, horloge, version du module).
• Elle n’apparaît jamais : l’appel est arrêté avant d’atteindre votre boutique, par un pare-feu réseau, un WAF ou un filtre de l’hébergeur.

Si votre hébergement ne donne pas accès aux journaux, vous pouvez ajouter temporairement un petit script PHP en pré-chargement (auto_prepend_file) qui note l’heure et l’adresse des requêtes reçues, sans aucun contenu. C’est la méthode que nous avons utilisée. Prenez une sauvegarde du .htaccess avant, et retirez le script juste après le test.

Étape 6 : exclure un blocage de ressources PHP

Dernier piège, plus rare : si l’hébergement n’autorise qu’un seul processus PHP à la fois, la boutique ne peut pas répondre à l’appel de retour pendant qu’elle attend la réponse de l’API. Les deux se bloquent mutuellement. Pour le vérifier, déposez temporairement ce fichier sur un site du même compte :

<?php sleep(4); echo "ok";

Lancez ensuite huit appels en parallèle. S’ils se terminent tous en environ 4 secondes, le serveur traite bien plusieurs requêtes en même temps. S’ils s’enchaînent (environ 32 secondes en tout), vous avez une limite de processus à faire relever. Supprimez le fichier après le test.

Les causes connues et leurs solutions

Les adresses des serveurs de PrestaShop

Dans une discussion publique de 2025 sur GitHub, un développeur de PrestaShop indique que leurs serveurs appellent la boutique depuis trois adresses (Google Cloud) : 104.199.32.134, 23.251.142.64 et 34.78.238.154. Il précise, dans une autre discussion de 2026, que ces adresses servent aux appels entrants vers votre boutique : les autoriser n’aide donc pas si c’est votre propre sortie qui est bloquée.

Ce que nous avons constaté en pratique (octobre 2026). Ces trois adresses sont bien celles qui appellent la boutique, mais une seule peut être bloquée alors que les deux autres passent. Chez PlanetHoster, seule 104.199.32.134 était refusée (403 de LiteSpeed). Si vous demandez une autorisation, donnez donc les trois adresses et demandez à l’hébergeur de contrôler chacune d’elles :

• 104.199.32.134 : bloquée chez nous (liste de réputation « Malware Expert » de ModSecurity) ;
• 23.251.142.64 : non bloquée ;
• 34.78.238.154 : non bloquée.

Une autorisation partielle ne suffit pas : l’appel de PrestaShop peut partir d’une adresse ou d’une autre, la vérification échoue tant qu’une seule reste bloquée.

Ces adresses peuvent évoluer. Confirmez-les auprès du support PrestaShop avant de modifier un pare-feu et, si votre pare-feu le permet, limitez l’autorisation à l’adresse apiV2ShopProof plutôt qu’à tout le site.

Notre cas : un hébergement mutualisé avec LiteSpeed

Voici ce que nous avons constaté sur une boutique PrestaShop 9.2.0, hébergée chez PlanetHoster (offre N0C, serveur LiteSpeed, PHP 8.3), avec le module PrestaShop Account 8.0.20.

• Le bilan de santé était entièrement vert : boutique liée, jetons valides, API joignable, horloges synchronisées.
• La sortie fonctionnait : la connexion à l’API s’établissait en quelques millisecondes depuis le serveur, y compris depuis PHP via le web.
• L’adresse de retour répondait correctement : 401 sans jeton, « Invalid token » avec un faux jeton dans le bon en-tête. Le .htaccess ne contenait aucune règle de blocage et aucun module de sécurité n’était installé.
• Le serveur gérait huit requêtes PHP en parallèle sans attente.
• En relançant la vérification avec 60 secondes d’attente au lieu de 10, l’API a fini par répondre au bout de 15 secondes avec une erreur 504 (Gateway Timeout) : c’est son propre appel vers la boutique qui expirait.
• Un journal temporaire des requêtes reçues, activé pendant deux vérifications, n’a enregistré aucun appel de l’API. L’appel de retour n’atteint donc jamais PHP.

Conclusion de ce diagnostic : tout ce qui dépend de la boutique est correct, et l’appel de retour est arrêté en amont, probablement par un filtre au niveau du réseau de l’hébergeur. Nous ne pouvons pas le prouver sans les journaux du pare-feu, que seul l’hébergeur possède.

Ce cas n’est pas isolé. Une discussion ouverte sur le dépôt du module décrit exactement les mêmes symptômes sur le même type d’hébergement (PlanetHoster N0C avec LiteSpeed), et un second commerçant hébergé au même endroit confirme le même délai de 10 secondes sur /verify. Dans les deux cas, désactiver le pare-feu applicatif n’a rien changé. La discussion était encore ouverte, sans réponse de PrestaShop, à la date de publication.

Le dénouement chez PlanetHoster

Voici la chronologie, pour que vous puissiez reproduire la démarche sur votre hébergement.

1. 24 octobre 2026. Nous écrivons au support PlanetHoster avec l’adresse appelée, l’heure exacte de deux vérifications (14h40 UTC) et les trois adresses IP de PrestaShop. Le journal de notre boutique ne montrait alors aucun appel de PrestaShop.
2. 25 octobre. Le support autorise « l’adresse de vérification de PrestaShop ». Nous relançons la vérification : toujours en échec. Le module affiche cette fois le code store-identity/incorrect-http-code, et son journal contient la réponse que PrestaShop a reçue de notre boutique : 403 Forbidden, avec la page d’erreur de LiteSpeed, sur GET //index.php?fc=module&module=ps_accounts&controller=apiV2ShopProof (agent « PrestaShop-Account/2.14.0 »). Le même appel fait depuis notre connexion répondait 401, donc le blocage dépendait de l’adresse de l’appelant. Nous renvoyons au support les trois adresses et demandons laquelle des règles déclenche le 403.
3. Réponse de l’hébergeur. Après vérification des trois adresses, seule 104.199.32.134 était bloquée par leur système ModSecurity, parce qu’elle figurait sur la liste de réputation de Malware Expert. Les deux autres n’étaient pas bloquées. PlanetHoster dépose une demande de délistage auprès de Malware Expert.
4. 26 octobre. Nous relançons « Verify » : la vérification réussit et PrestaShop Checkout passe à l’étape suivante (connexion à PayPal).

Ce qu’il faut retenir :

• Une autorisation « d’une adresse » ne règle rien si une autre des trois reste bloquée : faites contrôler les trois.
• Le journal du module (étape 4) vous donne la réponse reçue par PrestaShop. Un 403 avec la page de LiteSpeed ou d’Apache indique un filtre du serveur, pas un problème de PrestaShop.
• L’hébergeur n’a pas modifié la boutique : il a levé le blocage de l’adresse (autorisation et demande de délistage). Aucune modification du module ou du .htaccess n’a été nécessaire.
• La demande de retrait de la liste de réputation est faite par l’hébergeur auprès de l’organisme concerné. Chez nous, la vérification a réussi le lendemain de sa réponse, sans autre modification.

Que demander à votre hébergeur ou au support PrestaShop

Un ticket précis est traité beaucoup plus vite qu’un « ma boutique ne se vérifie pas ». Voici un modèle à adapter :

Bonjour, le module PrestaShop Account ne peut pas vérifier ma boutique votre-boutique.com (erreur accounts-api/connect-error). Pendant la vérification, les serveurs de PrestaShop doivent appeler https://votre-boutique.com/module/ps_accounts/apiV2ShopProof. J’ai testé le 24/10/2026 à 14h40 UTC : aucune requête n’atteint mon serveur. Merci de vérifier dans vos journaux (pare-feu, ModSecurity, Imunify, BitNinja ou équivalent) si ces appels sont bloqués ou ralentis, et de les autoriser pour mon compte.

Si l’appel de PrestaShop reçoit un 403, voici une version plus précise, qui nous a permis d’obtenir la réponse :

Bonjour, la vérification de ma boutique votre-boutique.com par PrestaShop échoue avec un 403 de votre serveur sur GET /index.php?fc=module&module=ps_accounts&controller=apiV2ShopProof (agent « PrestaShop-Account/2.14.0 »), alors que la même adresse répond normalement depuis ailleurs. Pouvez-vous contrôler, dans ModSecurity, votre pare-feu et vos listes de réputation, chacune de ces trois adresses de PrestaShop : 104.199.32.134, 23.251.142.64 et 34.78.238.154 ? Merci d’autoriser celles qui sont bloquées, de m’indiquer la règle ou la liste concernée et de me prévenir quand c’est fait.

Joignez la date et l’heure exactes de vos tests (avec le fuseau horaire) et le résultat des étapes 1 à 5. Au support PrestaShop, ajoutez l’identifiant de requête (valeur X-Request-ID) d’un appel à /verify et l’identifiant de boutique (la partie {id} de l’adresse /v1/shop-identities/{id}/verify). Vous les trouvez tous deux dans le journal du module (étape 4). Ce ne sont pas des secrets, contrairement au jeton qui se trouve sur la même ligne : ne recopiez que ces deux valeurs.

Les erreurs à éviter

• Réinstaller ou réinitialiser le module en boucle. Chaque réinitialisation peut créer une nouvelle identité de boutique. Plusieurs rapports GitHub décrivent des identités en double ou orphelines, que seul le support peut résoudre.
• Désactiver durablement le pare-feu ou le WAF. Faites-le uniquement pour un test court, puis remettez-le.
• Modifier le code du module. Une mise à jour effacera vos changements, et un délai plus long ne résout pas un appel qui n’arrive jamais.
• Partager le journal complet. Il contient un jeton d’autorisation (voir l’étape 4).
• Chercher une panne de version. Dans notre cas, le module était déjà à jour. Mettez-le à jour, mais ne vous arrêtez pas là.

Questions fréquentes

Que signifie « accounts-api/connect-error » ?

Le module n’a pas obtenu de réponse de l’API PrestaShop Accounts pendant la vérification. Le nom de l’erreur parle de connexion, mais la cause peut aussi être l’appel de retour que l’API ne parvient pas à faire vers votre boutique.

Ma boutique fonctionne et vend normalement : pourquoi la vérification est-elle nécessaire ?

Elle conditionne la configuration de certains modules officiels, comme PrestaShop Checkout ou PrestaShop Social. La boutique elle-même, le catalogue et les commandes ne sont pas affectés, mais la configuration de ces modules peut rester bloquée.

Un problème de version du module peut-il l’expliquer ?

C’est possible, par exemple après une mise à jour qui change l’adresse de la boutique ou le format des jetons, mais ce n’était pas le cas ici. Installez la dernière version de PrestaShop Account (8.0.20 à la date de publication) et testez de nouveau avant de chercher ailleurs.

Faut-il autoriser les adresses IP de PrestaShop dans le pare-feu ?

Seulement si le journal d’accès montre que l’appel est bloqué (étape 5). Autorisez-les (si possible pour l’adresse apiV2ShopProof uniquement) après confirmation par le support PrestaShop, car la liste peut changer.

Le problème vient-il de mon hébergeur ?

Si votre bilan de santé est vert, que les tests des étapes 2 et 3 réussissent et qu’aucune requête n’arrive pendant la vérification, le blocage se situe très probablement sur le réseau de l’hébergeur ou chez PrestaShop. Seul l’hébergeur peut le confirmer avec ses journaux.

Combien de temps le module attend-il la réponse de l’API ?

10 secondes dans la version 8.0.20. Notre test avec 60 secondes d’attente montre que l’API répond en 504 après environ 15 secondes : allonger le délai ne règle donc pas le problème.

Comment savoir laquelle des adresses IP de PrestaShop est bloquée ?

Demandez à l’hébergeur de contrôler les trois adresses (104.199.32.134, 23.251.142.64 et 34.78.238.154) dans son pare-feu et dans la liste de réputation de ModSecurity. Chez nous, une seule des trois était refusée. De votre côté, vous ne pouvez pas le deviner : le journal du module indique seulement que PrestaShop a reçu un 403.

La vérification passe-t-elle immédiatement après l’autorisation ?

Il peut y avoir un délai le temps que l’hébergeur applique le changement. Si l’échec persiste, relancez la vérification après quelques heures, rechargez la page du module pour effacer l’ancien message d’erreur, puis relisez le journal (étape 4) : une nouvelle ligne datée de votre essai prouve que la requête est bien repartie.

Besoin d’aide pour débloquer votre boutique ?

Si la vérification bloque la configuration d’un module important pour votre activité, l’équipe Genisoft peut analyser votre configuration serveur, relire les journaux avec vous et préparer le dossier pour l’hébergeur ou le support PrestaShop. Consultez notre service de dépannage PrestaShop.

Pour aller plus loin

• Débogage PrestaShop 8 et 9 : activer et lire les erreurs
• Erreur 500 PrestaShop : causes et solutions dans l’ordre
• Vider le cache de PrestaShop 8 et 9 sans casser la boutique
• Avis PlanetHoster : hébergement web

Sources

• Dépôt GitHub du module, discussion n° 661 : « Shop verification fails with accounts-api/connect-error while outgoing connection to Accounts API works »
• Dépôt GitHub du module, discussion n° 564 : « Shop cannot be requested (timeout) », avec les adresses des serveurs de PrestaShop
• Dépôt GitHub du module, discussion n° 647 : blocage sortant et réputation d’adresse IP
• Dépôt GitHub du module, discussion n° 652 : identité de boutique orpheline
• Versions du module PrestaShop Account : github.com/PrestaShopCorp/ps_accounts/releases

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →