D’où vient ce message
C’est la traduction française officielle de la chaîne There was an error processing your order. Please check for any charges in your payment method and review your order history before placing the order again. Elle est définie dans includes/class-wc-frontend-scripts.php (méthode get_script_data(), paramètre i18n_checkout_error) et affichée par client/legacy/js/frontend/checkout.js. Elle existe depuis WooCommerce 8.9, ajoutée pour que les clients vérifient leur paiement au lieu de repasser commande.
Elle n’apparaît que sur le tunnel de commande classique (shortcode [woocommerce_checkout]). Le bloc Commande, qui passe par la Store API, affiche un autre texte : « Une erreur est survenue lors du placement de la commande… ».
Ce qu’il signifie techniquement
Au clic sur « Commander », le navigateur envoie le formulaire en AJAX vers /?wc-ajax=checkout. Le message s’affiche dans trois cas :
- le serveur répond par une erreur HTTP (500 après une erreur fatale, 403 d’un pare-feu, 502, 503 ou 504 après un délai dépassé) ;
- la réponse n’est pas un JSON lisible (page HTML, réponse vide) ;
- WooCommerce renvoie un échec sans aucun message, par exemple une passerelle qui refuse le paiement sans dire pourquoi.
Un nonce expiré ou une session perdue produisent leurs propres messages (« Nous n’avons pas pu traiter votre commande, veuillez essayer de nouveau. », « Désolé, votre session a expiré »). Un cache qui sert un nonce périmé n’explique donc pas cette phrase-là.
WooCommerce crée la commande avant d’appeler la passerelle : selon le moment de la panne, vous trouverez une commande en attente, une commande payée, ou rien.
Les causes documentées, de la plus fréquente à la plus rare
Classement tiré d’une quinzaine de fils du forum WordPress.org et de tickets GitHub de WooCommerce : une tendance, pas une statistique.
- Une erreur PHP fatale dans une extension. Exemples relevés : une
TypeErrordans WooCommerce Square (corrigée en 4.9.4), All in One SEO 4.9.6.1 qui plantait pendant la création de la commande, une extension de devis qui transmettait un statut vide. - L’envoi de l’e-mail de commande qui plante. Fonction
mail()absente du serveur, expéditeur vide, quota SMTP atteint, ou régression de WooCommerce 10.9.0 corrigée en juillet 2026. Cas le plus piégeux : l’e-mail part après le paiement, le client est donc débité alors qu’il voit une erreur. - Un problème de passerelle. Bug de WooCommerce PayPal Payments 2.9.4 sur la carte bancaire, échec renvoyé sans message, ou réponse trop lente : le serveur coupe la connexion alors que le paiement a abouti. C’est ce scénario qui a motivé la création du message.
- Une requête bloquée par un pare-feu. WooCommerce a documenté des erreurs 403 dues à des règles ModSecurity d’hébergeurs, déclenchées par les cookies de l’attribution de commande (activée par défaut depuis la 8.5). Sur le tunnel classique, un 403 affiche ce message.
Aucun cas documenté ne désigne HPOS comme cause directe : le seul lien relevé est une désynchronisation des tables qui aggravait la régression e-mail de la 10.9.0.
Diagnostiquer sans deviner
- Vérifiez l’état réel. WooCommerce > Commandes et tableau de bord de la passerelle, à l’heure de l’erreur. « En cours » avec une transaction : le paiement est passé. « En attente de paiement » sans transaction : rien n’a été débité.
- Lisez WooCommerce > État > Journaux. Trois sources comptent :
fatal-errors(erreurs fatales avec la pile d’appels),place-order-debug-xxxxxxxx(depuis la 9.9, WooCommerce trace chaque étape de la commande et efface ce journal quand tout s’est bien passé ; la dernière étape notée montre où le processus s’est arrêté), et le journal de la passerelle si sa journalisation est activée. - Activez le journal de WordPress dans
wp-config.php:define( 'WP_DEBUG', true );,define( 'WP_DEBUG_LOG', '/chemin/hors/web/debug.log' );,define( 'WP_DEBUG_DISPLAY', false );. Le chemin hors de la racine web évite unwp-content/debug.loglisible par tous. - Observez la requête. Onglet Réseau du navigateur, filtre
wc-ajax=checkout, commande test. JSON avec"result":"failure"et"messages":"": échec sans explication, souvent la passerelle. 500 : erreur fatale, voirfatal-errors. 403 avec une page HTML : pare-feu. 502 ou 504 après une longue attente : délai dépassé. Sur le bloc Commande, la requête équivalente est/wp-json/wc/store/v1/checkout. - Isolez la passerelle. Testez en virement ou chèque, puis avec la passerelle en mode test. Si l’erreur persiste hors ligne, regardez les e-mails et les extensions, puis faites un test de conflit (Storefront, WooCommerce seul) sur une préproduction.
Un snippet pour tracer chaque tentative de commande
WooCommerce ne fournit aucun hook pour intercepter la réponse d’échec envoyée au navigateur. Ce mu-plugin utilise woocommerce_before_checkout_process et woocommerce_checkout_order_processed (déclarés dans includes/class-wc-checkout.php), plus shutdown de WordPress, qui s’exécute aussi après une erreur fatale. Il ne touche ni au paiement ni au message : il écrit une ligne par tentative dans la source diagnostic-commande (durée, code HTTP, dernière erreur PHP, commande créée).
Fichier à créer : wp-content/mu-plugins/wc-diagnostic-commande.php
<?php
/**
* Plugin Name: Diagnostic des commandes WooCommerce (checkout classique)
* Description: Journalise chaque tentative de commande du checkout classique : durée, code HTTP, dernière erreur PHP, commande créée. À supprimer une fois la cause trouvée.
*/
defined( 'ABSPATH' ) || exit;
add_action( 'woocommerce_before_checkout_process', function () {
$debut = microtime( true );
$order_id = 0;
// Priorité 1 : on note l'ID avant qu'une autre extension ne plante sur ce même hook.
add_action(
'woocommerce_checkout_order_processed',
function ( $id ) use ( &$order_id ) {
$order_id = (int) $id;
},
1
);
// S'exécute aussi après une erreur fatale : le gestionnaire de WordPress ne coupe pas le script.
add_action(
'shutdown',
function () use ( $debut, &$order_id ) {
if ( ! function_exists( 'wc_get_logger' ) ) {
return;
}
$order = $order_id ? wc_get_order( $order_id ) : false;
$erreur = error_get_last();
$http = http_response_code();
$fatale = $erreur && in_array( $erreur['type'], array( E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR, E_RECOVERABLE_ERROR ), true );
$contexte = array(
'source' => 'diagnostic-commande',
'duree_s' => round( microtime( true ) - $debut, 2 ),
'http' => $http,
'commande' => $order ? $order->get_id() : null,
'statut' => $order ? $order->get_status() : null,
'passerelle' => $order ? $order->get_payment_method() : null,
'erreur_php' => $erreur,
);
$niveau = ( $fatale || ( $http && $http >= 400 ) ) ? 'error' : 'info';
wc_get_logger()->log( $niveau, 'Tentative de commande (checkout classique)', $contexte );
},
PHP_INT_MAX
);
} );
Lecture : une ligne error avec "statut":"processing" signifie que le client a été débité malgré l’erreur. Une durée anormalement longue pointe vers un délai dépassé. Aucune ligne pour une tentative : la requête n’a pas atteint WooCommerce, pensez au pare-feu. erreur_php peut contenir un simple avertissement sans rapport : croisez avec fatal-errors. Supprimez le fichier une fois la cause trouvée.
Ce qu’il ne faut pas faire
- Relancer la commande à l’aveugle. Si la panne survient après le paiement, chaque tentative crée une commande et un débit de plus : un ticket GitHub rapporte cinq commandes payées pour un seul achat. C’est exactement ce que le message demande d’éviter.
- Masquer ou adoucir le message. Il protège le client contre le double débit : corrigez la cause, pas le texte.
- Laisser l’affichage des erreurs actif en production. Les visiteurs les voient et elles peuvent casser la réponse JSON du checkout.
- Désactiver tout le pare-feu. Demandez à l’hébergeur l’identifiant de la règle fautive et une exception ciblée.
À surveiller : WooCommerce 11.4, en préparation, doit renvoyer vers la commande déjà payée quand un client resoumet le formulaire après une panne survenue après paiement. Au 6 novembre 2026, la version stable est la 11.2.2.
Sources
- Définition du message (class-wc-frontend-scripts.php, WooCommerce 11.2.2)
- Introduction du message en 8.9 (PR #45961) et ticket d’origine (#41527)
- Traitement de la commande classique (class-wc-checkout.php)
- Régression de l’e-mail de commande en 10.9.0 (#66143) et commandes payées en double (#42223)
- Erreurs 403 et pare-feu ModSecurity (WooCommerce Developer Blog)
- Redirection vers la commande déjà payée, prévue en 11.4 (PR #68749)