Menu

Guide

HPOS et plugins de paiement : ce qui change

Mis à jour le

Réponse courte

HPOS (High-Performance Order Storage) range les commandes WooCommerce dans des tables dédiées au lieu des tables d’articles de WordPress. Un plugin de paiement reste compatible à deux conditions. D’abord, il lit et écrit les commandes uniquement par l’API de WooCommerce : wc_get_order() et les méthodes de l’objet commande. Il ne passe jamais par les fonctions de « post meta » ni par des requêtes SQL directes. Ensuite, il déclare sa compatibilité. Avant d’activer HPOS, vérifiez que chaque plugin qui touche aux commandes est déclaré compatible, puis testez un paiement complet, notification comprise.

Ce que change HPOS

Historiquement, une commande WooCommerce était un article WordPress (type shop_order) et ses données étaient des « post meta ». Beaucoup de plugins les lisaient donc avec get_post_meta() ou les écrivaient avec update_post_meta().

Avec HPOS, les commandes vivent dans leurs propres tables (dont wp_wc_orders et wp_wc_orders_meta, avec le préfixe wp_ par défaut). Un plugin qui continue d’utiliser les fonctions de post meta risque de lire ou d’écrire au mauvais endroit : WooCommerce ne voit pas la donnée là où il la cherche.

Pour un plugin de paiement, l’enjeu est concret. Il écrit dans la commande à des moments critiques : la tentative de paiement, le numéro de transaction, le changement de statut à la réception de la notification bancaire. Une écriture perdue peut laisser une commande payée en « En attente de paiement ».

Ce qu’un plugin de paiement doit faire

1. Passer uniquement par l’API de commande

La règle est simple :

  • autorisé : wc_get_order() et les méthodes de l’objet commande (get_meta, update_meta_data, add_order_note, update_status, payment_complete, save) ;
  • interdit : get_post_meta, update_post_meta, add_post_meta, delete_post_meta, get_post, les requêtes SQL directes sur wp_postmeta ou wp_wc_orders_meta.

Ces méthodes fonctionnent de la même façon avec HPOS et avec l’ancien stockage. Le même code sert donc aux deux.

2. Déclarer la compatibilité

Le plugin déclare la fonctionnalité custom_order_tables sur le crochet before_woocommerce_init, avec FeaturesUtil::declare_compatibility(). Sans cette déclaration, WooCommerce considère le plugin comme incompatible et peut empêcher l’activation de HPOS.

3. Recharger la commande avant d’écrire

Ce point ne vient pas de HPOS, mais il concerne les mêmes écritures dans la commande. Un autre plugin (un plugin de point relais, par exemple) peut modifier la commande entre le départ du client vers la page de paiement de la banque et la réception de la notification. Si le plugin de paiement enregistre un objet commande chargé trop tôt, il peut écraser ces modifications. La parade : recharger la commande juste avant d’écrire. Un verrou par commande évite en plus que deux notifications de la banque soient traitées en même temps. La commande est rechargée une fois ce verrou pris.

Vérifications pas à pas

  1. Listez les plugins qui touchent aux commandes : paiement, livraison et point relais, facturation, exports, CRM.
  2. Contrôlez leur déclaration. Dans l’administration, allez dans WooCommerce, Réglages, Avancé, Fonctionnalités. WooCommerce y indique si des extensions actives sont incompatibles avec le stockage des commandes choisi.
  3. Faites un test sur une copie du site, jamais directement en production.
  4. Passez un paiement complet en mode test, avec la plateforme de test de votre banque. Vérifiez que la commande change de statut après la notification serveur à serveur, pas seulement au retour du client.
  5. Ouvrez la commande dans l’administration. Vérifiez le statut, le numéro de transaction, les notes de commande, l’adresse de livraison et le point relais.
  6. Rejouez le test avec l’autre mode de stockage si vous devez pouvoir revenir en arrière.

Pièges fréquents

Un accès direct aux post meta caché dans un coin du code. Il suffit d’un seul appel oublié, par exemple dans le traitement de la notification, pour qu’une donnée soit lue au mauvais endroit. Une recherche des fonctions interdites dans le code, ou une règle d’analyse statique, permet de repérer cet appel avant la mise en production.

Un test fait seulement avec la synchronisation activée. Quand WooCommerce synchronise les deux stockages, un plugin incompatible peut sembler fonctionner. Testez plutôt, sur votre copie de site, en HPOS puis en mode posts, synchronisation désactivée, en vérifiant le mode réellement actif.

Le point relais perdu après paiement. Ce n’est pas toujours une question de HPOS, mais cela survient au même endroit : l’écriture de la commande à la réception de la notification. Voir point relais écrasé après paiement.

La commande reste « En attente de paiement ». Avant d’accuser HPOS, vérifiez que la notification de la banque arrive bien et qu’elle est acceptée. Voir commande en attente après un paiement Up2pay.

Ce que fait Relqor

Relqor Up2pay (V1 terminée, pas encore publiée) :

  • déclaration custom_order_tables : livrée et testée ;
  • tests d’intégration : chaque test concerné tourne HPOS activé, puis désactivé ;
  • tests en navigateur réel : deux boutiques, une en HPOS, une en stockage historique ;
  • contrôle automatique des accès directs aux post meta : oui (test statique par recherche textuelle).

Relqor Sips (V1 terminée, pas encore publiée) :

  • déclaration custom_order_tables : livrée et testée ;
  • tests d’intégration : suite complète en HPOS puis en stockage historique, synchronisation désactivée, mode réellement actif vérifié ;
  • tests en navigateur réel : non précisé dans ses documents ;
  • contrôle automatique des accès directs aux post meta : oui (test statique).

Pour Up2pay et pour Sips, la suite complète a été exécutée en HPOS et en stockage historique ; les versions testées seront publiées sur la page Compatibilité testée à la sortie des plugins. Le test « livraison et point relais identiques avant et après paiement » fait partie des tests exécutés dans les deux modes.

En résumé

Les plugins Relqor pour Up2pay et Sips n’accèdent aux commandes que par l’API de WooCommerce. Ils déclarent custom_order_tables. Ils prennent un verrou par commande, puis rechargent la commande avant d’écrire. Ils ne touchent ni à l’adresse de livraison ni aux données de point relais. Les plugins Up2pay et Sips ne sont pas encore publiés sur WordPress.org. Les résultats des tests automatisés, HPOS activé et désactivé, sont destinés à la page Compatibilité testée. Pour l’accès aux commandes et les tests en HPOS et en posts, voir la documentation livraison et point relais Up2pay et livraison et point relais Sips. Pour la configuration, voir installation et réglages Up2pay et installation et réglages Sips.

Pour votre banque, voir les pages Up2pay e‑Transactions, Mercanet, Sherlock’s et Sogenactif.