Le client a payé — vous avez vu la notification Stripe. Pourtant la commande reste « en attente de paiement » dans la boutique. Ou pire : elle apparaît deux fois, une payée et une en échec. Les paiements mal enregistrés, ce n'est pas qu'un bug technique : c'est du stock mal décrémenté, des colis non expédiés et une compta impossible à rapprocher.
On voit ce scénario chez des e-commerçants de la métropole lilloise dès qu'ils cumulent prestataire de paiement, plugin boutique et parfois marketplace. La bonne nouvelle : dans 80 % des cas, le problème vient de la communication entre le PSP et la boutique, pas du paiement lui-même. Voici comment diagnostiquer et corriger.
Symptômes : votre boutique et votre PSP ne sont plus d'accord
Avant que le SAV soit submergé, votre back-office envoie des signaux clairs. Les commandes restent marquées « non payées » alors que l'argent est visible sur Stripe, PayPlug ou Mollie. Vous voyez parfois des doublons pour une seule transaction bancaire, ou des statuts bloqués en « processing » indéfiniment après un 3-D Secure réussi. Les remboursements effectués côté PSP ne se reflètent pas dans la boutique, et la clôture mensuelle révèle des écarts entre le CA affiché et le relevé prestataire.
Les clients reçoivent parfois un email « paiement échoué » alors que leur carte a été débitée — le genre d'incident qui génère un appel le lundi matin. Dans le dashboard du prestataire, les webhooks en erreur confirment souvent le diagnostic en quelques minutes.
Un paiement capturé côté banque mais non reconnu côté boutique, c'est une commande qui ne part pas — et un client qui appelle le lundi matin.
Sur une boutique à 30 000 € de CA mensuel, 2 % de commandes mal statuées représentent 600 € de CA « fantôme » par mois, plus le temps SAV et la perte de confiance. Si vous observez plusieurs de ces signaux en même temps, traitez la couche paiement avant de chercher ailleurs.
Causes fréquentes derrière les enregistrements incorrects
La plupart des dysfonctionnements se regroupent autour de six familles de causes. Les identifier permet de prioriser les corrections sans tout remettre en question.
Webhooks mal configurés ou interrompus
L'URL de webhook change souvent après une migration, un changement de domaine ou une montée de version SSL. Un certificat expiré ou une redirection 301 peut casser la réponse du PSP. Pire : le webhook secret est régénéré côté Stripe ou PayPlug sans mise à jour dans le module boutique. Résultat : le paiement aboutit, le callback n'est jamais traité.
Mode test et live mélangés
Des clés API de test en production — ou l'inverse — créent des commandes fantômes ou des statuts incohérents. Une commande réelle qui passe sur l'environnement sandbox n'apparaît pas dans vos exports comptables live. Vérifiez l'étiquetage des clés dans le back-office et dans le fichier de configuration.
Plugins ou modules obsolètes
Un module WooCommerce Stripe non mis à jour après une montée de version WooCommerce peut ne plus interpréter les nouveaux statuts. Deux extensions de paiement qui interceptent le même événement provoquent des doublons ou des statuts contradictoires. Sur PrestaShop, un conflit entre module transporteur et module paiement sur le hook paymentConfirmation bloque parfois la validation.
3-D Secure et abandons de parcours
Le client valide le 3DS, ferme l'onglet avant le retour boutique. Le paiement est OK chez la banque, le callback boutique n'est jamais reçu. Si la commande est créée avant confirmation paiement, elle reste orpheline — stock réservé, statut incohérent.
Cache et optimisation agressive
Une page de remerciement ou un endpoint webhook mis en cache CDN peut renvoyer une réponse stale au PSP. Une bot protection (Cloudflare, etc.) qui bloque les IP du prestataire provoque des 4xx répétés dans les logs webhook. Ces cas sont fréquents sur hébergement mutualisé avec cache mal configuré.
En résumé : le problème vient rarement du PSP choisi — plutôt de la config, de l'hébergement et du moment où la commande est créée dans le flux.
Diagnostic : vérifier la chaîne paiement → boutique
Le diagnostic suit une chaîne logique en cinq étapes. Chaque étape confirme ou élimine une hypothèse.
Commencez par croiser PSP et back-office sur une commande problématique : ID transaction, montant, statut, date. Notez l'écart exact entre les deux systèmes. Consultez ensuite les webhooks dans Stripe, PayPlug, Mollie ou Shopify Payments — onglet webhooks ou logs. Cherchez les 4xx et 5xx des derniers jours : un webhook en échec répété explique souvent tout.
Passez une commande test avec une carte de test (PSP) ou un petit montant réel. Suivez le parcours complet : panier → paiement → retour → email → statut commande. Le statut doit passer à « payé » en moins de 30 secondes. Si ce délai est dépassé, vérifiez les logs serveur : erreurs PHP, timeout, memory limit au moment du callback. Les hébergements mutualisés cheap coupent parfois la requête webhook.
Enfin, auditez les extensions en staging : désactivez temporairement les plugins non essentiels au checkout et retestez. Un conflit classique : cache + paiement + tracking Facebook. Si le problème disparaît à la désactivation d'un module, vous tenez la cause.
Corrections : priorisation urgent / important / plus tard
Urgent — sous 24 à 48 h
Réparez l'URL webhook et le secret partagé, whiteliste les IP du PSP si un firewall les bloque, et traitez manuellement les commandes payées non validées en vous appuyant sur un export PSP. Si deux modules de paiement se marchent dessus, désactivez la double extension immédiatement.
Important — sous 2 semaines
Mettez à jour le module de paiement et la plateforme e-commerce. Implémentez une reconciliation automatique : un cron qui interroge le PSP et met à jour les commandes orphelines. Créez des alertes (email, Slack) sur webhook failed. Documentez le flux : création commande après confirmation paiement, pas avant.
Plus tard — fiabilisation
Envisagez un checkout hébergé (Stripe Checkout, Shopify Payments natif) pour réduire les callbacks custom. Ajoutez un monitoring continu type surveillance et monitoring site web. Formalisez une procédure de clôture : rapprochement PSP / boutique / compta chaque semaine.
Coûts indicatifs 2026 : correction webhook + config entre 400 et 1 200 € ; script de reconciliation + alertes entre 1 500 et 4 000 € ; refonte tunnel paiement entre 3 000 et 10 000 € selon plateforme.
Pour optimiser le parcours en amont, le guide paiements et checkout optimisé reste une base solide — un checkout propre réduit aussi les cas limites 3DS.
Prévention : ne plus perdre de paiement
La prévention repose sur une discipline simple : ne jamais modifier l'URL du site sans vérifier les webhooks PSP le jour même. Le staging est obligatoire pour tester le paiement avant mise en production. Une seule extension paiement active par prestataire, une reconciliation hebdomadaire (export PSP vs export commandes payées), et un hébergement adapté — e-commerce sur mutualisé basique = risque de timeout webhook.
Formez l'équipe à une procédure claire si un client signale « débité mais commande en attente » : vérifier le PSP, valider manuellement, expédier, corriger le webhook ensuite.
Les boutiques Shopify et les setups Stripe Checkout natifs ont moins de ce type de problème — le PSP et la plateforme sont plus intégrés. Sur WooCommerce et PrestaShop, la vigilance connecteur est plus élevée.
Impact comptable et relation client
Un paiement mal enregistré ne se limite pas au back-office. L'expédition retardée génère des avis négatifs. Une relance paiement à un client déjà débité provoque une crise de confiance. La TVA et le CA exportés vers la compta avec des trous imposent une reprise manuelle chez l'expert-comptable.
Si vous connectez déjà la boutique à Pennylane, Sage ou un export comptable, les erreurs de statut commande se propagent. Traitez la couche paiement avant de blâmer l'intégration comptable.
Checklist : paiement correctement enregistré à chaque commande
Validez ces points essentiels sur votre boutique :
- webhook PSP pointe vers l'URL HTTPS finale, sans redirection 301
- clés live et test séparées et correctement étiquetées
- module paiement à jour et compatible avec votre version e-commerce
- commande test : statut « payé » en moins de 30 secondes après validation 3DS
- logs webhook sans 4xx/5xx sur les 48 dernières heures
Sur WooCommerce, vérifiez aussi que le statut « processing » déclenche bien l'email confirmation et la décrémentation stock — signe que la chaîne post-paiement fonctionne. Une reconciliation PSP / boutique planifiée chaque semaine et un hébergement avec timeout suffisant (30 s minimum pour les callbacks) complètent la boucle.
Plateformes : où regarder en priorité
Shopify — les paiements natifs Shopify Payments limitent les erreurs webhook custom, mais les apps tierces (ERP, compta) peuvent mal interpréter les statuts. Vérifiez l'app, pas seulement le checkout.
WooCommerce — zone à haut risque : modules multiples, hébergement variable, callbacks PHP. Priorité absolue : module officiel du PSP, à jour.
PrestaShop — modules transporteur et paiement parfois en conflit sur le hook paymentConfirmation. Un seul module doit valider le statut commande payée.
FAQ
Le client est débité mais la commande est « en attente » : que faire ?
Vérifiez d'abord le PSP : la transaction est-elle « succeeded » ? Si oui, validez manuellement la commande et expédiez. Corrigez ensuite le webhook. Proposez un geste commercial si le délai a été long — c'est moins cher qu'un chargeback.
Faut-il créer la commande avant ou après le paiement ?
Après confirmation paiement, ou via un statut « pending payment » mis à jour par webhook. Créer une commande « réelle » avant paiement multiplie les fantômes et les stocks incorrects.
Stripe, PayPlug, Mollie : lequel pose le moins de problèmes de sync ?
Tous fonctionnent bien si le module est à jour et les webhooks OK. Stripe et PayPlug sont très documentés sur WooCommerce. Le problème vient rarement du PSP choisi — plutôt de la config et de l'hébergement.
Comment rapprocher boutique et PSP chaque mois ?
Exportez les transactions « succeeded » du mois côté PSP. Exportez les commandes « payées » côté boutique. Comparez par montant + date + email. Écart > 0,5 % : investiguer.
Les paiements en plusieurs fois (Alma, Klarna) compliquent-ils l'enregistrement ?
Oui, car le statut peut être « autorisé » puis « capturé » en différé. Vérifiez que votre module gère bien les statuts partiels et les remboursements proportionnels.
Et maintenant ?
Si vous avez des commandes payées non reconnues cette semaine, commencez par le dashboard webhook de votre PSP — c'est là que la vérité apparaît en dix minutes. Listez les échecs, corrigez l'URL ou le secret, retestez en commande réelle.
Apresta aide les e-commerçants de Lille et des Hauts-de-France à sécuriser tunnel de paiement, webhooks et rapprochements. On intervient sur WooCommerce, Shopify, PrestaShop et les intégrations comptables associées.