Passerelles concernées : Atos Sips
Problèmes rencontrés :
- Lors de l’installation du kit bancaire sur le serveur d’hébergement mutualisé LWS, les cgi request et response ne sont pas accessibles, par exemple sur /var/www/votre_compte/htdocs/cgi-bin/
- En activant le debug de la passerelle (et celui de pathfile) on constate que les URLs de retour de banque sont antislashées au niveau du caractère “?”, cela crée des erreurs au niveau de la banque lors des retours après paiement (retour du client et retour automatique de la banque)
Solutions :
- LWS n’autorise pas l’installation de nos propres CGI, il faut utiliser ceux qui sont installés dans votre compte sur le chemin suivant : /var/www/votre_compte/exec_dir/. Pour installer les CGI de LWS vous devez passer par l’administration de votre compte pour activer l’option correspondante.
- Les URLs étant affichées par le CGI request il n’est pas possible de corriger l’antislash généré par LWS. Une solution nécessite de modifier le code de la passerelle, dans woocommerce-gateway-atos.php il faut commenter la ligne $parm = escapeshellcmd($parm); en insérant deux slahs devant : //$parm = escapeshellcmd($parm);. Attention, cette manipulation sera à répéter à chacune des mises à jour de la passerelle. A notre connaissance LWS est le seul hébergeur à poser ce problème.
Passerelles concernées : Monetico
Problème rencontré : lors de vos tests de paiement vous obtenez une réponse de Monetico URL CGI2 NOT OK, alors même que vous savez que cette URL est bien enregistrée chez Monetico. De plus vous utilisez WeGlot pour traduire votre site.
Solution : vous devriez constater que la réponse envoyée par la passerelle à la banque se termine par <!–Not allowed–> (voir e-mail de Monetico après paiement), ce n’est pas normal, c’est WeGlot qui génère cette chaîne et fait échouer le retour. Ajoutez l’URL de retour CGI2 dans la liste des pages qui ne doivent pas être traduite pour résoudre votre problème. Pour rappel l’URL CGI à la forme http(s)://www.votre-site.fr/?wc-api=WC_Gateway_Monetico ou http(s)://www.votre-site.fr/?wc-api=WC_Gateway_Monetico_Nx (paiement fractionné).
Passerelles concernées : toutes
Problème rencontré : lorsque vous tentez d’activer votre licence, vous obtenez le message d’erreur suivant, La connexion au serveur de l’API de la clé de licence a échouée.
Solution : depuis l’abandon du protocole sécurisé TLS en version inférieure à 1.2, les serveurs d’OVH avec PHP en mode Legacy ne peuvent plus se connecter sur les sites en https. Si votre site est bien sur OVH, passez votre PHP en mode Stable, vous pourrez, entre autre, activer votre licence de passerelle.
Passerelle concernée : Paybox
Contexte : lorsque vous tentez d’effectuer un paiement vous obtenez le message bloquant suivant, “Erreur : aucun serveur n’a été trouvé“.
Explications : la passerelle de paiement teste deux serveurs Paybox pour s’assurer de leur disponibilité avant d’envoyer un paiement. En mai et juin 2018, le protocole SSL TLS 1.2 a été défini comme version minimale par l’ensemble des solutions bancaires. L’erreur est probablement liée au fait que votre hébergement n’est pas compatible avec cette version de TLS.
Solution : vous êtes certainement hébergé chez OVH et votre version de PHP doit être actuellement définie sur Legacy. Vous devez définir votre version de PHP sur Stable.
Notre support est fréquemment contacté pour un problème de retour de banque après paiement réussi.
La banque ne parvient pas joindre le site après le paiement, la commande ne peut pas être actualisée, les e-mails WooCommerce ne sont pas envoyés.
La source du problème peut être très diverse, je vais lister les sources identifiées.
Source du problème |
Solution |
| Le site n’est pas accessible à tous, mode maintenance efficace, htaccess, etc. | Rendez votre site accessible le temps de tester le paiement si le site n’est pas en production |
| Passerelle Monetico, vous n’avez pas envoyé l’URL retour CGI2 à Monetico ou vous ne l’avez pas faite actualiser suite à un changement (passage https, changement domaine, etc.). | Contactez Monetico (centrecom@e-i.com) pour leur communiquer l’URL retour CGI 2, elle est indiquée dans les réglages de votre passerelle. |
| Clouflare a blacklisté l’IP de la banque ! | Demandez la liste des IP à autoriser à votre banque pour l’ajouter en liste blanche sur Clouflare. |
| Une extension de sécurité bloque les appels distants (WordFence, iTheme Security, Sucuri, etc.). | Identifiez l’option qui va bien pour autoriser les appels distants ou au moins celui de la banque. |
| La banque rencontre une erreur SSL, par exemple SSL 104. | Il y a visiblement un problème dans la gestion du SSL sur votre site, Really Simple SSL pourrait résoudre ce problème. |
| Atos Sips, le cgi response remonte une erreur. | Vérifiez que le fichier n’est pas corrompu, qu’il est accessible, qu’il dispose de droits d’exécution. |
Identification de la source
Effectuer un appel distant sur l’URL retour de la banque permet assez souvent d’identifier la source du problème.
Voici le code que nous utilisons pour cela, il faut l’exécuter depuis un autre site que la boutique et idéalement un autre serveur (IP différente).
[pastacode lang=”php” manual=”%2F%2F%20Exemple%20pour%20Atos%20Sips%0A%24url%20%3D%20%22https%3A%2F%2Fwww.site-internet.com%2F%3Fwc-api%3DWC_Gateway_Atos%22%3B%0A%24curl_connection%20%3D%20curl_init()%3B%0Acurl_setopt(%24curl_connection%2CCURLOPT_URL%2C%24url)%3B%0Acurl_setopt(%24curl_connection%2CCURLOPT_POST%2Ccount(%24post_string))%3B%0Acurl_setopt(%24curl_connection%2C%20CURLOPT_POSTFIELDS%2C%20%24post_string)%3B%0Acurl_setopt(%24curl_connection%2C%20CURLOPT_RETURNTRANSFER%2C%20true)%3B%0Acurl_setopt(%24curl_connection%2C%20CURLOPT_HEADER%2C%20true)%3B%0A%24result%20%3D%20curl_exec(%24curl_connection)%3B%0Aecho%20%24result%3B” message=”” highlight=”” provider=”manual”/]Ce code renvoi l’entête de la page et son contenu. Le code retour doit être 200, ce qui indique que l’URL retour est accessible. Si le code est autre (301, 302, 403, etc.) il faut identifier le problème. Certains bloqueurs peuvent ce faire connaitre sur cette page (extension de sécurité, proxy). Un code 200 va vous conduire à la conclusion que le problème est spécifique au retour de la banque (erreur SSL, IP bancaire bannie, etc.).
[pastacode lang=”markup” manual=”HTTP%2F1.1%20200%20OK%20Date%3A%20Thu%2C%2007%20Jun%202018%2010%3A57%3A43%20GMT%20Server%3A%20Apache%20X-Powered-By%3A%20PHP%2F5.3.3%20Expires%3A%20Wed%2C%2011%20Jan%201984%2005%3A00%3A00%20GMT%20Cache-Control%3A%20no-cache%2C%20must-revalidate%2C%20max-age%3D0%20Content-Length%3A%200%20Content-Type%3A%20text%2Fhtml%3B%20charset%3DUTF-8″ message=”Exemple de résultat” highlight=”” provider=”manual”/]Les passerelles de paiement d’ABSOLUTE Web sont compatibles avec une installation multisites de WordPress.
Deux précisions :
1- Une licence 1 site est valable pour une URL. Dans le cadre d’une installation multisites en sous domaines ou sous dossiers vous ne pourrez activer la licence que sur le premier site du réseau. Il faut soit une licence 5 ou 25 sites, soit plusieurs licences pour les activer sur chaque site du réseau.
2- La passerelle ne doit pas être activée sur le réseau, vous devez l’activer site par site pour qu’une licence puisse être associée.
Produit concerné : toutes les passerelles
Contexte : le paiement est réussi sur le serveur bancaire mais le retour sur le site indique un paiement en échec. Vous utilisez Cloudflare.
Explications : il est possible que Cloudflare ai blacklisté une ou plusieurs adresses IP de votre banque ou que la vérification du navigateur à l’origine de l’appel soit un signal de blocage. La banque ne parvient donc plus à joindre la boutique après paiement et les commandes ne sont pas actualisées.
Solution : Si le blocage est identifié au niveau du firewall de Cloudflare, vous pouvez créer une règle de « Bypass » sur le point bloquant.
Exemple avec la passerelle Worldline Sips 2.0 dont l’URL de retour de banque est « /wc-api/wc_gateway_atos2 » (à adapter suivant la passerelle utilisée). Le blocage s’effectue lors de la vérification de l’intégrité du navigateur (la banque envoi une chaine vide tout simplement). C’est donc ce control précis qu’il faut outrepasser en sélectionnant « Bypass » et non « Allow » qui serait bloqué dans la foulée, puis en sélectionnant « Browser Integrity Check ».
A adapter en fonction de la raison du blocage du retour de banque :
Contexte : les passerelles de paiement bancaire interrompent le tracking des visiteurs car la saisie de la carte bancaire est réalisée sur le serveur de la banque. L’URL bancaire va donc générer un “referer” dans vos analyses et la campagne source ne sera pas correctement reliée à la commande payée sur votre site.
Solution : une solution, proposée par l’un de nos clients, consiste à effectuer des réglages dans le compte Google Analytics. Le premier réglage doit exclure le domaine référant bancaire, par exemple “sogenactif.com” pour le Société Générale. Il faut se rendre dans la colonne PROPRIÉTÉS, rubrique “Informations de suivi”, sous rubrique “Liste d’exclusion de sites référents”.
Ensuite il faut modifier dans la colonne VUE, “Modèles d’attribution” pour le définir sur “Première interaction”.
Ce client utilise l’extension de tracking WooCommerce suivante : http://www.tatvic.com/enhanced-ecommerce-google-analytics-plugin-woocommerce/
Produit concerné : passerelle Monetico
Contexte : le paiement est réussi sur le serveur bancaire mais l’URL retour CGI2 est NOT OK.
Explications :
- Vous devez avoir envoyé par e-mail (centrecom@e-i.com) l’URL retour CGI2 indiquée sur la page de réglage de la passerelle Monetico. Attendez la confirmation par Monetico pour effectuer vos tests.
- Si l’URL a bien été transmise, il faut vérifier l’URL CGI2 indiquée dans l’e-mail de Monetico qui est envoyé après un échec en mode TEST (Votre serveur nous a envoyé un accusé de réception invalide et le paiement a été validé.).
- Si l’URL CGI2 est la bonne, votre site bloque certainement les appels distants (mode maintenance, extension de sécurité [Wordfence, iThemeSecurity, …], htaccess, firewall, etc.). Identifiez le blocage.
Produits concernés : passerelle Atos 2.
Contexte : sur la page de paiement le bouton de redirection vers la banque est absent.
Résolution : commencez par activer le mode débug de WordPress en plaçant cette ligne dans votre fichier wp-config.php : define( ‘WP_DEBUG’, true );. Réactualisez la page de paiement, vous devriez voir apparaitre l’erreur à l’origine du problème. Si l’erreur affichée est “Fatal error: Uncaught exception ‘InvalidArgumentException’ with message ‘Uri is not valid’“, vérifiez votre traduction de order-received dans WooCommerce > Réglages > Commande. S’agissant d’une terminaison d’URL (endpoint), le texte ne doit contenir ni espace, ni caractères spéciaux, la traduction doit donc être commande-recue par exemple et surtout pas commande reçue.
Produit concerné : Monetico
Contexte : vous constatez que 3DSecure augmente vos abandons de panier et vous souhaiteriez le désactiver.
Résolution : consultez notre article dédié au sujet.
Produit concerné : passerelle Monetico.
Contexte : lors d’une tentative de remboursement depuis WooCommerce vous obtenez l’erreur “Commerçant non identifié”.
Explication : la fonction de re-crédit par requête informatique doit être activée sur votre contrat Monetico. Si vous ne l’avez pas coché lors de la signature du contrat, vous devez demander son activation auprès de Monetico. Sachez que l’adresse IP de votre serveur vous sera également demandée pour sécuriser les requêtes.
Produits concernés : toutes passerelles.
Contexte : après un paiement réussi sur le serveur de la banque vos commandes ne sont pas actualisées sur WooCommerce + message erreur de paiement. Vous avez iTheme Security d’installé sur le site.
Explication : la banque ne parvient pas à joindre le site après paiement. Très étonnement vous allez devoir décocher la case “Enable HackRepair.com’s blacklist feature” pour résoudre le problème. A croire que les IP bancaires sont blacklistées par ce site…
Produits concernés : passerelles Atos.
Contexte : votre site est en HTTPS mais pour fonctionner, votre url de retour de banque autoresponse doit être en http…
Explication : normalement si votre site est en http, son url de retour de banque doit être en http. De même si votre site est en https, l’url de retour de banque doit être en https. Mais… le protocole de l’url de retour de banque doit, selon Atos Sips contacté à ce sujet, correspondre à celui déclaré lors de la mise en place du contrat. Exemple : vous avez un site en http, vous mettez en place un contrat avec votre banque, vous déclarez votre site en http. Vous passez ensuite votre site en https sans faire remonter l’information à votre banque, l’url de retour ne devra pas être en https mais en http. Si par contre dès le départ le site est déclaré à la banque en https, l’url de retour devra être en https. Cette information n’étant pas détectable automatiquement, une option est nécessaire dans la passerelle de paiement pour forcer le http sur l’url de retour de banque pour les sites en https.
Attention, si vos pages http sont redirigées automatiquement vers le https (redirection 301 par exemple), le retour de banque ne fonctionnera toujours pas. Vous devrez dans ce cas, soit désactiver globalement la redirection, soit mettre une exception pour l’url de retour de banque (elle contient le paramètre wc-api), soit informer votre banque que votre site est en https (votre retour de banque devra alors l’être également).
Produits concernés : passerelles Atos Sips (paiement immédiat et en plusieurs fois).
Contexte : Infomaniak bloque des fonctionnalités de php ce qui rend la solution Atos Sips impossible à faire fonctionner sur ce type d’hébergement.
Résolution : ABSOLUTE Web a développé une alternative pour un premier blocage qui est la fonction exec() de php. Utilisez le FTP en ligne d’Infomaniak (https://admin2.infomaniak.com/ftp/) pour créer un dossier cgi-bin à la racine du site, le rendre exécutable, puis y copier le contenu des fichiers du dossier perl de la passerelle (atos_request.pl et atos_response.pl). Rendez ces fichiers également exécutables. Un second blocage concerne l’ouverture d’urls distantes avec get_file_contents(). Pour désactiver ce blocage, rendez-vous dans l’administration d’Infomaniak tel que précisé ici. Le reste de l’installation de l’API Atos Sips est classique, copie des binaires request et response et du dossier param sur le serveur.
A noter que dorénavant Infomaniak permet l’activation de la fonction exec() depuis le tableau de bord.
Produits concernés : toutes les passerelles.
Contexte : après une paiement réussi sur le serveur de la banque vous constatez au retour sur la boutique que la commande n’a pas été actualisée, elle reste en attente de paiement, un message d’erreur de paiement s’affiche sur la page de remerciement.
Résolution : après avoir vérifié que votre site est accessible, que l’url de retour de banque l’est également (vous pouvez la saisir dans un navigateur, elle contient le paramètre wc-api), vous devez vérifier que le firewall OVH n’est pas activé dans le fichier .ovhconfig situé à la racine de l’hébergement. Vous devez avoir http.firewall=none, dans le cas contraire OVH bloque les URLs distantes appelées par le protocole POST, ce qui est le cas des URLs de retour de banque. Si malgré cela le retour de banque n’actualise toujours pas votre commande, désactivez le firewall directement dans le panel d’administration d’OVH.
Produits concernés : les passerelles de paiement Paybox et Paybox Nx.
Contexte : lors de vos tests, Paybox ne parvient pas à joindre votre boutique après un paiement réussi (statut de commande inchangé, pas d’envoi d’email de commande). Lorsque vous revenez sur la boutique une page blanche s’affiche.
Résolution : l’url renvoyée par Paybox est très longue (près de 500 caractères), si vous utilisez l’extension iThemes Security, une option permet de limiter la longueur des urls acceptées sur le site. Vous devez désactiver cette option pour permettre à Paybox de fonctionner correctement.
Remarque : IThemes Security n’est certainement l’unique extension qui limite la longueur des urls, il se peut également que certains hébergeurs appliquent des limitations de ce type pour des questions de sécurité.
Produit concerné : la passerelle de paiement Atos Sips.
Contexte : votre site est hébergé chez Nuxit et vous ne parvenez pas à exécuter le cgi request d’Atos Sips.
Résolution : il faut s’assurer que le paramètre “Fonctions d’exécution” soit actif dans l’administration Nuxit. Il faut ensuite utiliser les cgi de Nuxit en supprimant dans les réglages de la passerelle les chemins vers ces cgi, vous ne devez donc renseigner que le nom des cgi “request” et “response” (sans chemin). Dernier point, le certificat doit être au format classique et non au format php.