# WooCommerce 8.0 : ce qui change pour les extensions de passerelle de paiement

> WooCommerce 8.0 fait évoluer plusieurs interfaces utilisées par les passerelles de paiement personnalisées. Classement par impact réel sur le code existant.

- Auteur : WordPress Développement
- Publié le : 2023-09-12
- Mis à jour le : 2023-09-12
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/woocommerce-8-passerelles-paiement-nouveautes/

## L’essentiel

- L'opt-in HPOS devient plus visible mais reste optionnel dans cette version
- Le bloc Paiement natif exige une classe de compatibilité pour les passerelles legacy
- Les hooks de statut de commande restent stables, sans rupture de compatibilité

WooCommerce 8.0, sorti en septembre 2023, ne bouleverse pas l'API des passerelles de paiement — mais trois évolutions méritent l'attention d'un mainteneur de passerelle personnalisée, classées ici par impact réel sur le code, pas par ordre d'apparition dans le changelog officiel.

Le point de départ de cette revue : une passerelle de paiement maison développée pour un client B2B, connectée à un prestataire de paiement différé propre au secteur du bâtiment, qu'il fallait faire cohabiter avec la version 8.0 sans régression sur le tunnel de commande.

## Impact élevé : la compatibilité avec le bloc Paiement natif

Le changement qui a nécessité le plus de travail concerne l'intégration au bloc Paiement (Checkout block), déjà disponible en tant que blocs mais dont l'adoption par défaut continue de progresser dans les thèmes récents. Une passerelle qui n'implémente que l'ancien formulaire de paiement classique (`WC_Payment_Gateway::payment_fields()`) continue de fonctionner sur le tunnel classique par shortcode, mais n'apparaît pas correctement sur un tunnel construit avec les blocs, sauf à enregistrer une classe de support dédiée héritant de `Automattic\WooCommerce\Blocks\Payments\Integrations\AbstractPaymentMethodType`.

```
class Ma_Passerelle_Blocks_Support extends AbstractPaymentMethodType {
    protected $name = 'ma_passerelle';

    public function initialize() {
        $this->settings = get_option( 'woocommerce_ma_passerelle_settings', array() );
    }

    public function is_active() {
        return ! empty( $this->settings['enabled'] ) && 'yes' === $this->settings['enabled'];
    }

    public function get_payment_method_script_handles() {
        return array( 'ma-passerelle-blocks-integration' );
    }
}
```

## Impact moyen : la visibilité renforcée de l'opt-in HPOS

> L'essentiel à retenir : L'opt-in HPOS devient plus visible mais reste optionnel dans cette version ; Le bloc Paiement natif exige une classe de compatibilité pour les passerelles legacy ; Les hooks de statut de commande restent stables, sans rupture de compatibilité

WooCommerce 8.0 n'active pas le stockage de commandes haute performance (HPOS) par défaut, mais rend son statut plus visible dans l'écran des fonctionnalités avancées, avec des messages de compatibilité affichés pour chaque extension active, y compris les passerelles de paiement. Une passerelle qui accède directement aux tables legacy (`wp_woocommerce_order_items` via des requêtes SQL directes, plutôt que via l'API `WC_Order`) se voit désormais signalée comme incompatible dans cet écran, même si HPOS n'est pas encore activé sur le site.

Pour une passerelle déjà construite sur `WC_Order::update_meta_data()` et `WC_Order::save()`, cette évolution n'a nécessité aucune modification — c'est précisément l'objectif de cette abstraction, conçue pour rester stable indépendamment du mode de stockage sous-jacent.

## Impact faible : les hooks de statut de commande

Les hooks utilisés couramment par les passerelles pour réagir à un changement de statut — `woocommerce_order_status_changed`, `woocommerce_payment_complete` — n'ont subi aucune modification de signature dans cette version. La passerelle testée n'a nécessité aucune adaptation sur cette partie du code, ce qui confirme la stabilité de cette API sur plusieurs versions majeures consécutives.

## Checklist de montée de version pour une passerelle

- Vérifier l'affichage de la passerelle sur un tunnel de commande construit avec les blocs, pas uniquement sur le tunnel classique.
- Confirmer l'absence de requête SQL directe sur les tables de commandes dans le code de la passerelle.
- Rejouer un scénario de paiement complet en environnement de recette avant la mise à jour en production.
- Consulter l'écran Fonctionnalités avancées pour identifier les avertissements de compatibilité spécifiques à la passerelle.

> Conseil maison : traitez chaque montée de version majeure de WooCommerce comme une occasion de vérifier la compatibilité avec le bloc Paiement, même si votre passerelle fonctionne encore sur le tunnel classique. C'est le point qui casse le plus souvent, silencieusement, sans erreur PHP.

## En résumé

WooCommerce 8.0 ne rompt aucune API de passerelle de paiement de façon brutale, mais accentue la pression pour supporter le bloc Paiement natif et pour abandonner tout accès direct aux tables de commandes legacy. Les nouveautés de l'interface d'administration destinées aux marchands, elles, n'ont aucun impact sur le code d'une passerelle et ne sont pas traitées ici.