Votre page WordPress répond, mais une extension, une API ou le paiement WooCommerce affiche soudainement WordPress erreur 402. Commencez par vérifier la réponse complète, l’URL appelée et la couche qui produit le code. Le statut 402 Payment Required n’est pas une panne générale de WordPress. Il signale le plus souvent un service externe qui réclame un paiement, un quota, un abonnement ou une action de facturation. La solution consiste donc à identifier l’émetteur, contrôler la clé API et le compte associé, puis retester une requête minimale avant de modifier le thème ou la base de données.

Ce code est rare sur un site classique. Il devient toutefois très concret avec une passerelle de paiement, un service d’images, une API d’IA, un CDN ou un pare-feu applicatif. Une erreur affichée dans l’administration ne signifie pas forcément que le visiteur voit la même chose.

Que signifie une WordPress erreur 402 ?

Le code HTTP 402 correspond à la raison Payment Required. Il a été réservé par la spécification HTTP pour des scénarios de paiement, mais son usage reste limité et n’est pas défini par un mécanisme universel. Chaque service peut donc ajouter son propre message, son propre format JSON et ses propres règles de facturation.

Dans WordPress, le cœur ne renvoie généralement pas 402 pour une simple page publique. Le code peut venir d’une extension qui appelle un service distant, d’une API REST située devant WordPress, d’un hébergeur, d’un CDN ou d’une passerelle WooCommerce. Le premier travail consiste à ne pas confondre le lieu où l’erreur est visible avec le lieu où elle est née.

Relevez quatre éléments avant toute correction : le statut, le type de contenu, le serveur indiqué par les en-têtes et le corps de la réponse. Un JSON contenant quota, billing ou subscription oriente vers un fournisseur. Une page HTML de blocage oriente plutôt vers un proxy, un WAF ou une interface d’hébergement.

Lire la réponse HTTP sans exposer un secret

Testez l’URL qui échoue avec une requête limitée. Ne copiez jamais une clé complète, un cookie ou un jeton dans un ticket. Le but est de récupérer les en-têtes et quelques lignes du corps, pas de reproduire une transaction réelle.

curl -sS -D /tmp/headers.txt -o /tmp/body.txt 
  --max-time 20 
  'https://exemple.fr/wp-json/'

printf 'Statut et en-têtes :n'
grep -iE '^(HTTP/|content-type:|server:|www-authenticate:|retry-after:|x-request-id:)' /tmp/headers.txt
printf 'nCorps limité :n'
head -c 1000 /tmp/body.txt

Pour une page d’administration, reproduisez l’action depuis l’onglet Réseau du navigateur. Notez la méthode HTTP, la route et le moment exact. Si la réponse 402 apparaît uniquement sur une requête distante, la page WordPress est probablement saine. Si elle apparaît sur la page entière, contrôlez le reverse proxy et les règles de sécurité avant de toucher aux extensions.

Vérifier le service externe et sa facturation

Une API peut retourner 402 quand le compte n’a plus de crédit, quand une période d’essai est terminée ou quand un abonnement est suspendu. Ouvrez le tableau de bord officiel du service, pas un lien reçu dans un message. Contrôlez le statut du compte, la carte ou le moyen de paiement, la devise, la facture la plus récente et le projet auquel la clé appartient.

Ne régénérez pas immédiatement la clé. Une nouvelle clé ne réactive pas un compte impayé et peut casser plusieurs environnements. Commencez par comparer le projet configuré dans WordPress avec celui qui possède réellement le quota. Les erreurs de compte sont fréquentes après une migration ou un changement d’agence.

# Exemple de contrôle local, sans afficher la valeur du secret
printenv | grep -E '^(API|SERVICE|STRIPE|OPENAI|GOOGLE)_' | sed 's/=.*$/=<masqué>/'

# Chercher seulement le nom de la variable dans la configuration
grep -RInE 'API_KEY|SECRET_KEY|CLIENT_ID' wp-config.php .env 2>/dev/null

Cette commande sert à repérer une configuration, pas à imprimer les secrets. Après un diagnostic, retirez les variables temporaires de l’historique du shell et vérifiez que le fichier .env n’est pas accessible depuis le web.

Diagnostiquer une extension WordPress

Les extensions de statistiques, d’optimisation d’images, de traduction, d’IA et de sécurité interrogent souvent des services payants. Une extension peut afficher 402 dans un avis d’administration alors que le site public fonctionne. Notez le nom de l’extension et l’heure d’apparition, puis consultez son journal et sa documentation officielle.

Si vous avez encore accès à l’administration, utilisez le mode dépannage pour votre session uniquement. Désactivez temporairement le composant suspect, puis reproduisez une seule action. Si le 402 disparaît, réactivez les autres extensions et vérifiez la licence ou la clé de l’extension fautive. Une désactivation globale sans sauvegarde rend le diagnostic plus difficile.

Sans accès à wp-admin, WP CLI permet de faire un test contrôlé. Remplacez le nom par le slug réel. Conservez la liste des extensions actives afin de pouvoir revenir à l’état initial.

wp plugin list --status=active --fields=name,status,version
wp plugin deactivate extension-suspecte --skip-plugins --skip-themes
wp plugin activate extension-suspecte --skip-plugins --skip-themes

Si le code continue d’apparaître avec l’extension désactivée, le fournisseur peut être appelé par le thème, une tâche planifiée ou un mu plugin. Vérifiez les journaux PHP et la liste des tâches cron. Ne supprimez pas le dossier avant d’avoir identifié l’appel.

Cas WooCommerce et passerelles de paiement

WooCommerce peut afficher une erreur de paiement qui ressemble à un 402, mais la réponse vient souvent de la passerelle choisie. Le client peut voir un message générique tandis que le journal de la passerelle contient la raison exacte. Dans WooCommerce, ouvrez WooCommerce, État, Journaux, sélectionnez le journal correspondant à la date et recherchez l’identifiant de transaction sans publier de données bancaires.

Contrôlez le mode test ou production, la devise, le montant minimum, l’adresse de facturation et la correspondance entre le compte marchand et les clés. Une clé de test utilisée avec un compte de production peut provoquer une réponse de facturation ou d’autorisation. Vérifiez aussi l’horloge du serveur et l’URL de retour, car certaines passerelles refusent une requête signée hors délai.

# Vérification non destructive de l’environnement WordPress
wp option get woocommerce_currency
wp option get woocommerce_store_address
wp cron event list --fields=hook,next_run_gmt --format=table | grep -iE 'payment|subscription|webhook'

Ne testez pas un paiement réel en boucle. Utilisez le mode test du fournisseur et une commande de faible valeur seulement si sa documentation l’autorise. Après correction, vérifiez une commande réussie, une commande refusée et la réception du webhook. Un 402 ne doit pas être transformé en succès côté boutique.

Quand le code vient d’un CDN, d’un WAF ou d’un proxy

Un service de protection peut renvoyer 402 pour une limite de plan, une fonctionnalité désactivée ou un dépassement de quota. Dans ce cas, WordPress ne reçoit aucune requête. Comparez les en-têtes d’une page qui fonctionne et de l’URL qui échoue. Un identifiant comme cf-ray, un nom de fournisseur ou une page de blocage est un indice utile.

Contrôlez les règles de cache. Une réponse 402 ne doit pas être mise en cache comme une page normale, car elle pourrait être servie à tous les visiteurs après un incident ponctuel. Purgez seulement la route concernée et retestez avec une requête unique. Pour une API, vérifiez aussi les limites par minute et les en-têtes Retry-After.

curl -sS -D - -o /dev/null 
  -H 'Cache-Control: no-cache' 
  -H 'Accept: application/json' 
  'https://exemple.fr/wp-json/route-externe'

# Comparer le code sans répéter la requête en rafale
curl -sS -o /dev/null -w 'HTTP %{http_code}n' 
  --max-time 20 'https://exemple.fr/route-a-tester'

Ne désactivez pas complètement le WAF pour contourner un quota commercial. Demandez au fournisseur la règle exacte, l’identifiant de requête et la période concernée. Si le problème vient du plan, le correctif est commercial ou architectural, pas une modification de .htaccess.

Inspecter la REST API et les appels programmés

Une erreur 402 sur /wp-json/ doit être comparée à une route publique et à la route précise qui échoue. Utilisez un compte de test et des identifiants dédiés. Une extension peut appeler une API externe depuis une tâche cron, puis remonter son échec dans une requête REST de l’administration.

curl -i -sS --max-time 20 'https://exemple.fr/wp-json/'
curl -i -sS --max-time 20 'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'
wp cron event list --format=table

Si la racine REST répond 200 et qu’une route d’extension répond 402, le cœur WordPress n’est pas la cause principale. Si toutes les routes sont bloquées par le même fournisseur, vérifiez le proxy, le WAF et le plan d’hébergement. Pour comparer les autres statuts, consultez notre guide sur WordPress erreur 401 et notre méthode de diagnostic de WordPress erreur 422.

Éviter les faux correctifs et les fuites de secrets

Vider tous les caches, réinstaller WordPress ou augmenter la mémoire PHP ne résout pas un abonnement expiré. De même, publier une clé API dans un forum pour demander de l’aide transforme un incident banal en incident de sécurité. Masquez les valeurs sensibles et partagez seulement le nom du fournisseur, le code, l’heure et l’identifiant de requête.

Si une clé a été exposée, révoquez-la depuis le tableau de bord officiel, recherchez son usage dans les journaux et remplacez-la dans un emplacement hors dépôt. Contrôlez ensuite les permissions du fichier et l’absence de copie dans une sauvegarde publique. Un 402 peut être un symptôme de facturation, mais le diagnostic doit préserver les comptes et les données.

Checklist de résolution d’une WordPress erreur 402

Commencez par répondre à ces questions : quelle URL renvoie 402 ? Quel composant l’affiche ? Le corps est-il un JSON du fournisseur ou une page HTML ? Le statut apparaît-il pour les visiteurs ou seulement dans l’administration ? Le compte est-il actif et le quota disponible ? Le site utilise-t-il le bon environnement, les bonnes clés et la bonne devise ? Un CDN ou un WAF modifie-t-il la réponse ?

Après le correctif, testez sans rafale. Vérifiez la page publique, l’action d’administration, l’appel API et, si nécessaire, un paiement test. Contrôlez les journaux et le cache. Notez la cause dans la documentation du site afin que la prochaine migration ne réintroduise pas une ancienne clé ou un ancien projet.

FAQ sur WordPress erreur 402

WordPress erreur 402 signifie-t-elle que mon hébergement est impayé ?

Pas forcément. Le code peut venir d’une API, d’une extension, d’une passerelle de paiement, d’un CDN ou d’un WAF. La réponse complète et les en-têtes indiquent généralement l’émetteur réel.

Comment corriger une erreur 402 WooCommerce ?

Consultez le journal de la passerelle, vérifiez le mode test, la devise, le compte marchand, les clés et la facture. Reproduisez ensuite une commande avec le mécanisme de test officiel, sans multiplier les paiements réels.

Le code 402 vient-il toujours d’une API externe ?

Non. Il peut être généré par un proxy, un pare-feu, un CDN ou une extension locale. Une page HTML de blocage et un identifiant de fournisseur orientent vers une couche située devant WordPress.

Faut-il désactiver le WAF pour supprimer une erreur 402 ?

Non. Identifiez la règle, le quota ou le plan concerné. Une exception limitée ou une correction du compte est plus sûre qu’une désactivation générale.

Quelle différence entre 402 et 401 ?

Le 401 concerne principalement une authentification absente ou invalide. Le 402 est réservé à un besoin de paiement, de crédit ou de souscription, mais son interprétation dépend du service qui l’émet.

Sources et références

WP Admin Lab
· Chef de la rédaction

La rédaction de WP Admin Lab réunit des praticiens WordPress, sécurité et développement web. Nous publions des guides testés en conditions réelles, vérifiés en production et régulièrement mis à jour, sans jargon inutile. Chaque procédure est relue avant publication.

mastodon