Un client clique sur « Payer », son téléphone vibre pour lui demander de confirmer dans son application bancaire, puis la commande passe en « Traitement ». Pour l’acheteur, tout cela tient en quelques secondes et semble presque magique. Pour le serveur qui héberge la boutique, c’est une mécanique en plusieurs temps, avec des points de rupture bien identifiés qu’il vaut mieux connaître avant qu’un client mécontent n’écrive pour dire que sa carte a été débitée « pour rien ».
La SCA (authentification forte du client, imposée par la directive DSP2) et le protocole 3D Secure 2 qui la met en œuvre ne sont pas de simples options cochées dans un tableau de bord. Ils modifient en profondeur le cycle de vie d’une commande WooCommerce, et un développeur qui doit déboguer un paiement bloqué a tout intérêt à savoir exactement quel appel réseau se joue à quel moment.
Le rôle du navigateur n’est qu’apparent
Quand un client renseigne sa carte, le formulaire de paiement (généralement un élément Stripe ou un widget équivalent fourni par la passerelle) crée d’abord un objet côté prestataire, un PaymentIntent chez Stripe par exemple. Cet objet contient le montant, la devise et l’intention de paiement, mais aucune confirmation n’a encore eu lieu. WooCommerce, à ce stade, a déjà créé la commande côté base de données avec le statut pending (en attente de paiement).
Le navigateur du client sert ensuite d’intermédiaire visuel pour le défi d’authentification : une fenêtre modale s’ouvre, hébergée par la banque émettrice, qui demande une confirmation biométrique ou un code reçu par SMS. Mais ce navigateur n’est qu’un tuyau d’affichage. La décision réelle — le résultat de l’authentification — est produite par la banque et transmise directement au prestataire de paiement, pas au serveur WordPress qui a initié la demande.
Trois échanges serveur à connaître
Le premier échange a lieu quand le plugin de passerelle crée l’intention de paiement via une requête API sortante depuis WordPress. Le deuxième se produit quand le prestataire notifie le résultat du défi d’authentification à WooCommerce, presque toujours via un webhook asynchrone plutôt que par la redirection du navigateur (la redirection peut échouer si l’utilisateur ferme l’onglet). Le troisième est la confirmation finale de capture des fonds, qui peut arriver plusieurs secondes après l’affichage du message de succès à l’écran.
C’est ce découplage entre affichage et confirmation serveur qui explique certains tickets de support déroutants : un client voit « Merci pour votre commande » alors que, côté serveur, le webhook de confirmation n’est pas encore arrivé et que la commande reste techniquement en pending pendant quelques secondes à quelques minutes.
Où WooCommerce stocke l’état de l’authentification
Chaque tentative de paiement laisse une trace dans les métadonnées de la commande. Selon la passerelle, on retrouve des clés comme _stripe_intent_id ou des champs équivalents chez d’autres prestataires, accessibles via $order->get_meta(). C’est cette référence qui permet, lors du traitement du webhook, de retrouver la bonne commande WooCommerce sans dépendre d’un identifiant transmis par le navigateur, qui pourrait être absent si la session a expiré.
Un point souvent négligé : le hook woocommerce_order_status_changed ne se déclenche qu’après le traitement complet du webhook entrant, pas au moment de la création de l’intention. Un développeur qui accroche une action métier (envoi d’un e-mail de confirmation d’expédition anticipée, par exemple) sur un mauvais hook risque de la déclencher trop tôt, avant que le paiement ne soit réellement confirmé.
Le cas du défi abandonné
Si le client ferme la fenêtre de défi ou que sa banque ne répond pas dans le délai imparti, aucun webhook de succès n’arrivera. La commande WooCommerce reste alors en pending indéfiniment, sauf si une tâche planifiée annule les commandes non payées après un délai (fonctionnalité native de WooCommerce configurable dans les réglages de paiement, sous « Conserver les stocks »). C’est une source fréquente de confusion pour les équipes commerciales qui voient des commandes « fantômes » dans leur liste.
Ce qu’il faut vérifier en cas d’incident
- Le journal des webhooks entrants (souvent visible dans le tableau de bord du prestataire de paiement) pour confirmer qu’ils ont bien atteint votre serveur avec un code 200.
- Les métadonnées de la commande WooCommerce pour retrouver l’identifiant de l’intention de paiement et le comparer au statut réel côté prestataire.
- Le fichier de logs WooCommerce (menu WooCommerce > Statut > Journaux) où la plupart des passerelles sérieuses écrivent chaque étape de l’échange.
- La configuration du délai d’annulation automatique des commandes non payées, qui peut expliquer une commande annulée alors que le client jure avoir payé.
Sur les dossiers de support liés au paiement, je commence toujours par la même question : le webhook est-il arrivé ? Neuf fois sur dix, la réponse à cette seule question explique tout le reste.
En résumé
La SCA et le 3D Secure 2 ajoutent une étape d’authentification bancaire qui semble transparente pour l’acheteur mais qui repose, côté serveur, sur un échange asynchrone en plusieurs temps. Un développeur qui comprend cette mécanique — création de l’intention, défi d’authentification hors du contrôle du site, confirmation par webhook — gagne un temps précieux quand il faut expliquer pourquoi une commande reste bloquée, ou pire, pourquoi un client affirme avoir payé une commande qui n’existe pas encore côté serveur.
