Guide

Point relais écrasé après paiement : causes et prévention

Mis à jour le 24 septembre 2026

Réponse courte

Quand le point relais choisi par le client disparaît ou change au moment où la commande est marquée comme payée, une cause possible est une sauvegarde faite à partir d’une copie périmée de la commande. Une extension charge la commande trop tôt. Une autre extension écrit ensuite le point relais. Puis la première enregistre sa copie, qui ne contient pas ce point relais. Une autre cause possible est une extension qui modifie elle-même les champs de livraison. Le diagnostic consiste à comparer la commande avant et après la notification de paiement, et à identifier l’extension qui écrit à ce moment-là.

Où est stocké le point relais

Dans WooCommerce, les informations de livraison d’une commande se trouvent à trois endroits :

les champs d’adresse de livraison (nom, adresse, code postal, ville, pays), séparés de l’adresse de facturation ;
des métadonnées de commande ajoutées par l’extension du transporteur : identifiant du point relais, nom, adresse du point, parfois des données au format JSON. Leur nom dépend de chaque extension ;
les lignes de livraison (le mode de livraison choisi), qui peuvent elles aussi porter des métadonnées de point relais, selon l’extension.

Pour un transporteur à point relais, l’adresse de livraison peut aussi être remplacée par celle du point choisi. Tout dépend de l’extension de livraison.

Le mécanisme : un objet commande périmé

Dans une boutique avec un paiement par redirection (Up2pay e‑Transactions, Mercanet, Sherlock’s, Sogenactif…), la commande est créée avant le paiement, puis le client part sur la page de paiement de la banque. Plus tard, la banque envoie une notification serveur à serveur, et l’extension de paiement met à jour la commande.

Entre ces deux moments, d’autres extensions peuvent écrire dans la commande : l’extension du transporteur, une extension de facturation, un outil d’expédition. Le risque apparaît quand une extension :

charge la commande en mémoire ;
laisse passer du temps ou d’autres traitements, pendant lesquels une autre extension écrit le point relais ;
enregistre sa copie, qui ne contient pas la valeur écrite entre-temps.

Selon la façon dont l’enregistrement est fait, la valeur récente peut être remplacée par l’ancienne. La sauvegarde d’un objet chargé trop tôt écrase alors la modification faite entre-temps.

Les autres causes possibles

Une extension qui écrit dans les champs de livraison : par exemple en recopiant l’adresse de facturation, ou en complétant des champs qu’elle croit vides.
Deux notifications traitées en même temps : si une extension de paiement ne verrouille pas la commande pendant le traitement, deux traitements parallèles peuvent chacun enregistrer une copie différente.
Une extension de livraison qui réécrit ses propres données : au changement de statut, par exemple, elle les recalcule à partir d’une information incomplète.

Ce sont des mécanismes possibles. Aucun n’est propre à une extension en particulier, et seul un test sur votre site permet de savoir lequel s’applique.

Diagnostic pas à pas

Faites ces essais sur une copie du site, en mode test de paiement.

Reproduisez le cas. Passez une commande avec un point relais et une adresse de livraison différente de l’adresse de facturation.
Relevez l’état avant paiement. Quand la page de paiement de la banque s’affiche, ne payez pas encore. Ouvrez la commande dans l’administration (WooCommerce → Commandes), dans un autre onglet, et notez l’adresse de livraison et le point relais. Si vous en avez la possibilité, exportez aussi les métadonnées de la commande et celles de ses lignes de livraison. Ensuite, payez avec une carte de test.
Relevez l’état après la notification. Une fois la commande passée en « En cours », comparez. Notez précisément ce qui a changé : l’adresse, le point relais, ou les deux.
Lisez les notes de la commande et les journaux WooCommerce (WooCommerce → État → Journaux) pour dater chaque étape : création, redirection, notification, changement de statut.
Désactivez toutes les autres extensions, sauf WooCommerce, l’extension de paiement et l’extension du transporteur. Répétez le test. Si le problème disparaît, réactivez-les une par une, en testant après chaque activation, pour trouver celle qui écrit dans la commande.
Testez l’extension de paiement seule avec le transporteur. Si le problème persiste avec seulement ces deux extensions, il se situe dans l’une d’elles ou dans leur interaction.
Testez les deux modes de stockage des commandes si votre site a été migré vers HPOS, car une extension peut se comporter différemment selon le mode.

Solution

Pour les commandes déjà touchées : retrouvez le point relais choisi par le client (dans l’e‑mail de confirmation de commande, dans l’interface du transporteur ou auprès du client lui-même) et corrigez la commande avant l’expédition.
Pour la cause : transmettez à l’éditeur de l’extension fautive un scénario reproductible. Une correction possible consiste à recharger la commande juste avant de l’enregistrer, et à ne modifier que les données dont l’extension est responsable.
En attendant : vérifiez chaque point relais avant de préparer une expédition.

Prévention

Testez le parcours complet avant chaque mise à jour d’une extension de paiement, de livraison ou de WooCommerce, avec une adresse de livraison différente et un point relais.
Comparez l’écran de commande avant et après paiement, et pas seulement le statut.
Limitez les extensions qui écrivent dans les commandes à celles dont vous avez besoin.
Préférez des extensions qui accèdent aux commandes par l’API de WooCommerce, ce qui est aussi une condition de la compatibilité avec HPOS (l’extension doit en plus la déclarer).

Ce que fait Relqor

Relqor développe des plugins de paiement indépendants, non affiliés aux banques. Ce problème fait partie des risques testés.

Up2pay e‑Transactions, V1 terminée mais pas encore publiée sur WordPress.org : le plugin ne lit ni n’écrit jamais les champs d’adresse de livraison. Il ne lit ni n’écrit aucune métadonnée en dehors des siennes (_relqor_*). Chaque enregistrement part d’une commande fraîchement rechargée, et la notification n’utilise jamais un objet chargé avant la prise du verrou de la commande. Des tests automatisés simulent trois transporteurs, avec des valeurs contenant des accents et du JSON. Ils vérifient que l’adresse de livraison et les métadonnées de point relais sont identiques octet pour octet avant et après paiement. Ils vérifient aussi qu’une métadonnée de point relais modifiée par une autre extension entre le passage de la commande et la notification est conservée.
Worldline Sips (Mercanet, Sherlock’s, Sogenactif), V1 terminée mais pas encore publiée sur WordPress.org : le plugin ne modifie ni les adresses, ni les lignes de livraison, ni les métadonnées de point relais, et recharge la commande après la prise du verrou. Des tests automatisés vérifient, en HPOS et en posts, qu’une adresse et une ligne de livraison portant les métadonnées de trois plugins de point relais simulés sont identiques avant et après paiement.

Pour aller plus loin : les pages Up2pay e‑Transactions, Mercanet, Sherlock’s et Sogenactif pour WooCommerce, et la documentation sur la livraison et le point relais pour Up2pay et pour Sips.