Une panne de paiement ne ressemble pas à un site « down ». L’accueil répond 200, les fiches aussi. Le client bloque au moment de payer : bouton absent, authentification qui ne s’ouvre pas, retour en erreur, ou commande qui reste en attente alors qu’il a été débité. Détecter cela demande de regarder le tunnel et les statuts, pas la page d’accueil.
Où la commande s’arrête
- Les clés live ont été remplacées par les clés de test lors d’un déploiement. Le formulaire s’affiche. Les cartes réelles sont refusées.
- Le script ou l’iframe du prestataire ne se charge pas. Contenu mixte, bloqueur, ou domaine du prestataire filtré. Le bouton n’apparaît pas.
- Le client paie, puis l’URL de retour (
order-received, merci, ou l’équivalent) répond 404 ou 500. Il croit que la commande a échoué. - Le webhook n’arrive pas ou la signature est rejetée. Le prestataire a encaissé. La commande WooCommerce reste
pendingouon-hold. - Le mode 3-D Secure ne s’ouvre pas. Une partie des cartes, souvent celles qui exigent une authentification, échoue. Les autres passent. Ce n’est pas « toutes les cartes ».
Une seule carte refusée pour provision insuffisante n’est pas une panne. Plusieurs échecs au même message, dans la même heure, en sont une.
Confirmer en dix minutes
- Listez les commandes de la dernière heure :
processing,pending,failed. Une chute des payées et une hausse d’un seul statut orientent la panne. - Ouvrez le journal de la passerelle et les livraisons de webhooks. Une série d’échecs de signature ou de délai nomme la cause.
- Passez une commande en mode test, puis vérifiez que les clés actives sont bien repassées en live.
- Contrôlez l’URL de commande et l’URL de retour avec un test d’URL : HTTPS, code 200, pas une page d’erreur.
- Dans le navigateur, au moment de payer, regardez si l’iframe est vide et si la console signale un script bloqué.
SiteGarde, en interrogeant l’URL de paiement depuis un autre réseau, voit un tunnel absent ou un mauvais code même quand votre session d’admin affiche encore la page. Le débit réel, lui, se confirme dans les journaux du prestataire.
| Constat | Lecture | Premier geste |
|---|---|---|
| Clés de test dans les réglages | Aucun encaissement réel | Remettre les clés live |
| Iframe vide | Script ou HTTPS | Corriger le mélange de contenus ou la clé publique |
| Retour client en 404 | Le paiement a pu avoir lieu | Réparer l’URL, puis rapprocher les paiements |
Webhooks en échec, commandes pending | Débit possible côté prestataire | Rétablir l’URL de notification et la signature |
| Un seul refus isolé | Carte ou authentification de ce client | Ne pas basculer de passerelle |
Comparez deux moyens de paiement si vous en avez plusieurs. Quand un seul échoue, la passerelle ou ses clés sont en cause. Quand tous échouent au même moment, regardez la page de commande, le certificat ou le cache. Notez l’heure du premier failed groupé : elle doit coller avec un déploiement, un certificat ou une coupure du prestataire, pas avec un simple client.
Ce qu’il ne faut pas faire
Ne changez pas de prestataire au premier refus de carte. Ne rejouez pas le webhook à la main sans vérifier la signature : vous pourriez marquer payée une commande qui ne l’est pas. Ne jugez pas la panne sur l’accueil. Après correction, une commande test doit passer de bout en bout et une commande réelle doit quitter pending grâce au webhook.
Le contrôle de cette URL rejoint la méthode pour tester si un site répond vraiment : code, certificat et contenu attendu du tunnel, depuis l’extérieur.