« Le paiement ne marche plus » peut désigner plusieurs incidents. Tous les clients sont bloqués, une seule banque refuse, la commande est créée deux fois ou le paiement réussit mais le stock ne bouge pas. La première étape consiste à préciser le symptôme sans multiplier les essais en production.
Vérifiez d'abord le statut chez le prestataire de paiement. Une page d'erreur dans la boutique ne prouve pas que la transaction bancaire a échoué.
01 — Premiers gestes
Limiter l'impact sans détruire les traces
Notez l'heure de début, les moyens de paiement concernés et les changements récents : mise à jour de module, certificat, clé API, règle de sécurité, cache ou version PHP. Prévenez le service client avec une consigne simple pour éviter les doubles remboursements et les nouvelles tentatives manuelles.
Si toutes les ventes sont bloquées, proposer temporairement un autre moyen de paiement peut réduire la perte. Ne désactivez pas au hasard les extensions et ne videz pas tous les journaux. Sauvegardez la configuration, la base et les logs avant d'intervenir. Les preuves les plus utiles disparaissent souvent après une rotation automatique ou un nouvel essai.
- Heure exacte et référence de la tentative.
- Montant, devise et appareil utilisé.
- Statut de la commande dans WooCommerce ou PrestaShop.
- Statut de la transaction côté prestataire.
- Message visible par le client, sans collecter ses données bancaires.
- Dernière modification technique connue.
02 — Flux
Une commande traverse plusieurs confirmations
La boutique crée un panier puis prépare une intention de paiement. Le client peut être redirigé ou afficher un formulaire hébergé. Sa banque demande éventuellement une authentification forte. Le prestataire renvoie ensuite le navigateur vers la boutique, mais il envoie aussi une notification serveur à serveur : le webhook.
Ce webhook est souvent la confirmation la plus fiable. Le client peut fermer l'onglet avant le retour, perdre sa connexion ou rafraîchir la page. La boutique doit pouvoir recevoir l'événement, vérifier sa signature et associer la transaction à la bonne commande. Elle met alors à jour le statut, déclenche l'e-mail et le stock une seule fois.
Retour navigateur
Utile pour l'expérience client, mais interrompu si l'onglet se ferme ou si le réseau coupe.
Webhook
Notification entre serveurs qui confirme un événement et doit être authentifiée puis journalisée.
Rapprochement
Comparaison périodique des commandes et transactions pour retrouver les statuts incohérents.
03 — Enquête
Croiser quatre sources avant de modifier le code
Consultez la commande, les journaux du module, les événements du prestataire et les logs du serveur web ou de l'application. Cherchez le même identifiant de transaction. Un code HTTP 401 indique souvent une authentification, un 404 une mauvaise URL de webhook, un 500 une erreur côté boutique et un délai dépassé un traitement trop lent ou indisponible.
Vérifiez aussi l'heure et le fuseau. Deux journaux peuvent sembler contradictoires alors qu'ils utilisent UTC et Europe/Paris. Masquez les secrets, jetons et données personnelles avant de transmettre une capture à un intervenant. Aucun diagnostic légitime ne demande le numéro complet ou le cryptogramme de la carte du client.
04 — Causes
Les pannes les plus fréquentes ne sont pas toutes bancaires
- Clé ou secret expiré : changement d'environnement, rotation de clé ou compte marchand mal configuré.
- Webhook bloqué : pare-feu, maintenance, DNS, certificat ou règle de sécurité refuse la notification.
- Module incompatible : mise à jour du CMS, du thème, du paiement ou de PHP modifie un comportement attendu.
- Cache sur le tunnel : panier, session, nonce ou page de retour sont servis avec un état obsolète.
- Montant incohérent : arrondi, taxe, remise, devise ou frais de livraison diffèrent entre les deux systèmes.
- Traitement non idempotent : un webhook répété crée deux commandes, deux factures ou deux mouvements de stock.
Intervention e-commerce à Toulouse
Vos paiements échouent ou les commandes restent dans le mauvais statut ?
Je peux reconstituer le parcours, analyser les journaux WooCommerce, PrestaShop et du prestataire, corriger le module ou l'intégration puis tester le flux complet. J'interviens à Toulouse, dans le Grand Sud et à distance en France.
- Diagnostic ciblé de l'incident
- Correction du module, webhook ou serveur
- Rapprochement commandes et transactions
- Tests sandbox et surveillance après mise en ligne
En situation bloquante, transmettez l'heure, une référence de commande et les changements récents : jamais les données complètes d'une carte.
Faire diagnostiquer mon paiementUne page dédiée permet aussi de demander une intervention sur un bug de paiement WooCommerce.
05 — Recette
Tester plus qu'un paiement réussi
- Utiliser l'environnement sandbox
Tester succès, refus, authentification, abandon et reprise avec les moyens fournis par le prestataire.
- Contrôler les effets métier
Statut, stock, facture, e-mail, export ERP et compte client doivent évoluer une seule fois.
- Répéter le webhook
La notification doublée doit être reconnue sans reproduire les conséquences.
- Simuler une interruption
Vérifier que l'erreur alerte, se rejoue et ne laisse pas une commande payée invisible.
- Surveiller après déploiement
Comparer pendant quelques jours taux d'acceptation, erreurs techniques et commandes sans transaction associée.
06 — Prévention
Détecter une panne avant les premiers messages clients
La supervision peut vérifier qu'un paiement de test atteint régulièrement l'étape attendue, sans effectuer de transaction réelle. Elle surveille aussi les réponses des webhooks, l'expiration du certificat, la file d'événements et la proportion de commandes bloquées dans un statut intermédiaire.
Le taux de refus bancaire varie naturellement et ne signifie pas toujours une panne. Comparez-le à son niveau habituel par moyen de paiement, appareil et pays, sans enregistrer de données interdites. Une hausse brutale des erreurs techniques, des délais ou des retours HTTP 500 mérite en revanche une alerte immédiate.
Avant chaque mise à jour du CMS, de PHP, du thème ou du module, rejouez une recette courte sur préproduction. Documentez les clés utilisées par environnement et la procédure de rotation. Ces habitudes réduisent le temps de diagnostic, car elles fournissent une référence saine et une chronologie claire lorsque l'incident survient.