# « Coupon code already applied » : l’erreur qui bloque un panier

> Un client ne parvient plus à valider sa commande à cause d'un message de coupon fantôme qui persiste en session, alors qu'aucun code n'apparaît dans le panier affiché.

- Auteur : WordPress Développement
- Publié le : 2023-09-16
- Mis à jour le : 2023-09-16
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/coupon-code-already-applied-erreur-panier-woocommerce/

## L’essentiel

- Le message provient d'une donnée de session obsolète, pas d'un bug d'affichage
- wc_get_notices() peut révéler des notices fantômes accumulées
- Vider le panier ne suffit pas toujours, il faut vider la session

« Coupon code already applied » : ce message s'affiche en rouge au-dessus du tunnel de commande, alors même que le panier visible à l'écran ne contient aucun coupon appliqué. Le client tente de resaisir un code, obtient à nouveau le même message, retire tout code du champ prévu à cet effet, et se retrouve bloqué malgré tout. Ce scénario, remonté par plusieurs boutiques ayant mis en place un système de coupons personnalisés, cache une cause plus subtile qu'un simple bug d'affichage.

La confusion vient du fait que WooCommerce stocke l'état des coupons appliqués non pas uniquement dans le panier visible, mais également dans la session PHP du visiteur, via l'objet `WC_Session`. Un coupon peut donc rester « appliqué » du point de vue de la session, sans plus apparaître dans le résumé du panier affiché à l'écran, notamment après une modification manuelle du panier via du code personnalisé.

## Symptôme : un blocage qui résiste au vidage du panier

Vider entièrement le panier via l'action « Vider le panier » ne suffit pas toujours à faire disparaître le message. C'est le signe le plus révélateur que le problème ne se situe pas dans le contenu du panier lui-même, mais dans les données de session associées, qui persistent indépendamment du contenu réellement affiché.

## Diagnostic : inspecter la session, pas le panier

La fonction `WC()->session->get( 'applied_coupons' )` permet de lister, depuis un simple hook de débogage temporaire, les codes que WooCommerce considère comme actuellement appliqués pour la session en cours. Sur les cas observés, cette liste contenait un code retiré par un script personnalisé de gestion de promotions, mais retiré uniquement du panier — via `WC()->cart->remove_coupon()` — sans que la session ait été explicitement synchronisée derrière.

```
add_action( 'wp_footer', function () {
    if ( current_user_can( 'manage_options' ) ) {
        error_log( print_r( WC()->session->get( 'applied_coupons' ), true ) );
    }
} );
```

> L'essentiel à retenir : Le message provient d'une donnée de session obsolète, pas d'un bug d'affichage ; wc_get_notices() peut révéler des notices fantômes accumulées ; Vider le panier ne suffit pas toujours, il faut vider la session

Dans le cas remonté, un développement personnalisé retirait automatiquement certains coupons devenus invalides (promotion expirée entre-temps) via une boucle appelant `remove_coupon()`, mais une exception silencieuse dans cette boucle — provoquée par un code de coupon contenant un caractère non attendu — interrompait le traitement avant la fin, laissant la session dans un état incohérent par rapport au panier réellement affiché.

### Une autre cause fréquente : le cache de page

Sur les boutiques utilisant un cache de page agressif, une variante du même symptôme apparaît quand une page de panier mise en cache est servie à un visiteur alors que sa session contient un coupon expiré depuis. Le contenu HTML affiché ne reflète alors plus l'état réel de la session, ce qui accentue encore la confusion du client face au message d'erreur.

## Le correctif : forcer la synchronisation

Le correctif définitif consiste à s'assurer que toute suppression de coupon passe systématiquement par le panier ET force la sauvegarde immédiate de la session, plutôt que de laisser WooCommerce la persister à la fin du cycle de requête habituel.

```
WC()->cart->remove_coupon( $code_coupon );
WC()->cart->calculate_totals();
WC()->session->set( 'applied_coupons', WC()->cart->get_applied_coupons() );
WC()->session->save_data();
```

Pour un client déjà bloqué en production, la solution immédiate la plus fiable reste de lui faire vider les cookies du site (ce qui régénère une session neuve côté serveur), en attendant que le correctif définitif soit déployé.

- Vérifier `WC()->session->get( 'applied_coupons' )` avant de conclure à un bug d'affichage.
- Toute suppression programmatique de coupon doit forcer une sauvegarde explicite de session.
- Exclure la page panier et paiement de tout cache de page agressif.

## Prévention

Ce type d'incident se prévient en encadrant systématiquement d'un bloc `try/catch` toute boucle qui manipule des coupons par programmation, afin qu'une exception isolée sur un code invalide n'interrompe jamais silencieusement le reste du traitement, laissant la session dans un état incohérent que seul le client découvre, bien après le déploiement du code fautif.