URGENT : SIPS retour commande payée ne marche plus

Bonjour

Je suis face à un immense problème.
Le retour de confirmation banque n'est plus pris en compte quand le paiement est ok.
Bizarrement le statut change qd c'est en erreur CB.
J'ai essayé de changer le statut confirmé par un autre, de réinstaller le certificat, le response, le request. Rien ne change.
Je génère une 30aine de commandes par jour. HELP !

Bonjour Nicolas

Non les options sont bien configurées. rien n'a été touché et ça marchait parfaitement jusqu'à présent.
Est ce le log dont vous avez besoin ?

DEBUG MODE

Pathfile
Reading pathfile (/home/nom_site/www/media/com_hikashop/pathfile) OK
D_LOGO (/media/com_hikashop/l/)
F_DEFAULT (/home/nom_site/www/media/com_hikashop/pc.x)
F_PARAM (/home/nom_site/www/media/com_hikashop/pc)
F_CERTIFICATE (/home/nom_site/www/media/com_hikashop/b/ct)

System
Reading F_DEFAULT (/home/nom_site/www/media/com_hikashop/pc.x) OK
Reading F_PARAM (/home/nom_site/www/media/com_hikashop/pc.005008583680796) OK
Reading F_CERTIFICATE (/home/nom_site/www/media/com_hikashop/b/ct.fr.005008583680796) OK
Version du certificat = 20/03/2014 (SOGENACTIF)

CALL URL
paiement.sogenactif.com:443/cgis-payment...tif/prod/callpayment

Request sent to the Payment Server
API_VERSION (P615)
CERTIFICATE_DATE (20140320)
CERTIFICATE_EXPIRED ()
CERTIFICATE_VERSION ()
CERTIFICATE_TYPE ()
BROWSER_TYPE ()
MERCHANT_ID (005008583680796)
MERCHANT_COUNTRY (fr)
AMOUNT (1000)
TRANSACTION_ID (115201)
CURRENCY (978)
TRANSMISSION_DATE (20151204105201)
PAYMENT_MEANS (CB,2,VISA,2,MASTERCARD,2)
HEADER_FLAG (yes)
LANGUAGE (fr)
RETURN_URL (http://nom_site.fr/success.php)
CANCEL_URL (http://nom_site.fr/atos.php)
AUTO_RESPONSE_URL (http://nom_site.fr/atos.php)
RETURN_LOGO ()
CANCEL_LOGO ()
SUBMIT_LOGO ()
LOGO ()
LOGO2 ()
ADVERT ()
CARD_LIST ()
TRANSACTION_CONDITION ()
ORDER_VALIDITY ()
MERCHANT_LANGUAGE ()
BGCOLOR ()
TEXTCOLOR ()
TEXTFONT ()
BACKGROUND ()
RECEIPT ()
CADDIE (YToxMTp7czo3OiJhZGRyZXNzIjtzOjIyOiI1IHJ1ZSBFdXJ5YWxlIERlaGF5bmluIjtzOjg6ImFkZHJlc3MyIjtzOjA6IiI7czo4OiJsYXN0bmFtZSI7czo2OiJMYXJydWUiO3M6NzoiY291bnRyeSI7TjtzOjExOiJwb3N0YWxfY29kZSI7czo1OiI3NTAxOSI7czo0OiJjaXR5IjtzOjU6IlBBUklTIjtzOjU6InN0YXRlIjtiOjA7czoxMjoicGhvbmVfbnVtYmVyIjtiOjA7czo1OiJ0aXRsZSI7czoxOiJNIjtzOjk6ImZpcnN0bmFtZSI7czo4OiJKw6lyw7RtZSI7czo2OiJjYWRkaWUiO2k6MTQyMzt9)
CUSTOMER_ID (859)
CUSTOMER_EMAIL (This email address is being protected from spambots. You need JavaScript enabled to view it.)
DATA ()
RETURN_CONTEXT ()
TEMPLATE ()
CUSTOMER_IP_ADDRESS ()
ORDER_ID (1423)
CAPTURE_DAY ()
CAPTURE_MODE (AUTHOR_CAPTURE)
STATEMENT_REFERENCE ()
CUSTOMER_PHONE ()
CONFIRM_TEMPLATE ()
BLOCK_ALIGN (center)
BLOCK_ORDER (1,2,3,4,5,6,7,
TARGET ()

HTML FORM built successfully
Vous utilisez le formulaire sécurisé standard SSL, choisissez une carte ci-dessous :

SoumettreSoumettreSoumettre


END DEBUG MODE

merci Nicolas.
voici

Erreur lors de l'appel de l'API\nMessage d'erreur:
API ERROR
Error get DATA response parameter (wrong length)

Bonjour Nicolas

aesecure a été installé il y'a quelques jours par Christophe Avonture.
Il vient de regarder de son côté et m'écrit
Je suis occupé à analyser votre fichier log du 9 décembre, correspondant à votre propre commande

Dans les logs, je vois une erreur 500 pour cette ligne : xyz.com/administrator/index.php?option=c...report&task=edit&cid []=12

Cela correspond à ce message d'erreur :
Unknown column 'prod.product_id' in 'where clause' SQL=SELECT *, SUM( case when o.order_currency_id = '1' then o.order_full_price when o.order_currency_id = '2' then o.order_full_price/1.083 end ) AS Total, COUNT(o.order_id) AS order_number FROM o1egi_hikashop_order as o LEFT JOIN o1egi_hikashop_user as a ON o.order_user_id=a.user_id LEFT JOIN o1egi_users as u ON u.id=a.user_cms_id WHERE a.user_partner_activated=0 AND o.order_status IN ('created','confirmed','shipped') AND prod.product_id IN ('93','590') AND a.user_id IS NOT NULL AND o.order_type='sale' GROUP BY a.user_id ORDER BY order_number DESC LIMIT 7

Il serait bon de mentionner ce message à l'équipe française de Hikashop car c'est une erreur dans leur logiciel.

Je continue à essayer de trouver...

(sans avoir l'URL précise de retour de la banque, c'est chercher une aiguille dans une botte de foin)

Avez-vous déjà essayé de renommer le fichier .htaccess à la racine de votre site en, p.ex., old.htaccess puis de faire une commande histoire de s'assurer que dans ce cas-là cela fonctionne ? Ainsi, on pourrait alors vraiment mettre en cause la programmation dudit fichier.

Nous nous sommes joint ensuite au téléphone et avons essayé plusieurs paiements réels en modifiant htacces et ovhconfig.
Ca n'a pas marché.

Christophe a conclu que
A mon niveau, je ne connais pas HikaShop. C'est en analysant le log des accès Apache que j'ai vu une ligne en erreur 500 (erreur serveur) et que j'ai pu voir l'URL qui est utilisée. Cette URL est celle que j'ai donnée dans mon précédent email xyz.com/administrator/index.php?option=c...report&task=edit&cid []=12.. Si c'est celle pour voir le statut d'une commande, c'est ici que ça se situe.

(Selon moi, c'est une erreur au niveau de la base de données et de la table hikashop_order mais à Nicolas, développeur d'Hikashop, de confirmer)

En message privé je t'ai laissé les logins de connexions ftp et administration Joomla, pourrais-tu m'aider ?
On devient vraiment dingues.

Merci par avance.

Je vous donne la réponse de christophe et mon mail.
Pouvez-vous m'aider ? Je n'y comprends rien et ça bloque une grande part de mon activité.
Je suis évidemment prêt à vous dédommager comme il se doit.

Désolé mais non, aeSecure ne bloque pas les fichiers atop.php ou success.php. Il suffit d’accéder à http://votresite/atop.php pour le vérifier.

Et, dans le cas d’un éventuel blocage, un, le log des accès bloqués d’aeSecure le mentionnerait et, deux, le log apache des accès le mentionnerait aussi (avec un code d’erreur 403 – Access denied) et ni 1 ni 2 n’est présent sur votre site.

En outre, si aeSecure aurait bloqué l’instruction, le fait d’avoir renommé .htaccess comme vous l’avez fait samedi matin aurait résolu le problème et ce n’est pas ce qui s’est produit : vous avez renommé le fichier .htaccess (et donc l’éventuel blocage) et l’erreur était encore là.

Dernier point : aeSecure bloque une requête et, en aucun cas, n’aurait eu une influence telle que l’erreur « Error get DATA response parameter » comme indiquée dans votre précédent email.

Rien de tout ça…

Désolé mais non, aeSecure n’y est pour rien.

Concernant votre problème : cela concerne donc le retour entre la banque et HikaShop. La banque envoie une requête vers votre site et HikaShop reçoit cette requête pour faire passer la commande en statut Confirmé si j’ai bien compris. Et là, si j’ai bien compris, je ne comprends alors pas la réponse de l’équipe HikaShop (première phrase).

Navré mais comme je le mentionnais, je n’ai pas la moindre piste pour présumer que l’URL de la banque est bloquée puisque je ne trouve aucune trace dans vos logs de cette URL-là.

Bonne soirée.

Christophe

De : xx
Envoyé le :lundi 14 décembre 2015 22:40
À : Christophe Avonture
Objet :Re: aeSecure - Cleaning -

Bonsoir Christophe

Je me permets à nouveau de vous solliciter.
Concernant la requête en erreur, hikashop me dit qu’il en est rien.
Comme je vous l’ai dit, on a mis Hikashop en mise à jour 2.6.0 vendredi dernier. J’espère donc que l’erreur ne « pourrit » plus les logs.
Y a t’il une chance pour que les fichiers atos.php et success.php en racine ait été bloqués par aesecure ou est ce exclu ?
Je vous copie colle leur réponse.
Excusez-moi de vous déranger une nouvelle fois.
Jérôme
Bonjour,

Malheureusement, il n'en n'est rien.

Une notification de paiement n'ai aucunement dans le backend d'HikaShop ; c'est tout simplement impossible dans Joomla puisqu'il faut être identifié en tant qu'administrateur.
L'erreur dans le controller "report" vient d'un rapport ayant une erreur de configuration. Puisqu'il se trouve dans la zone "report" et non "dashboard", c'est probablement un rapport qui n'est plus utilisé et qui devrait être supprimé.
De plus cela me fait également pensé à une vieille erreur qui a été corrigée.
CF :
Je doute qu'une mise à jour d'HikaShop solutionne le problème mais si vous avez une ancienne version, ça peut toujours être utile d'essayer.

Les retours d'atos sont:
atos.php
success.php
qui se trouve à la racine.
Le plugin est un très vieux plugin qui n'utilise pas le nouveau système de paiement d'HikaShop.
De part les restrictions (d'un autre temps) du système ATOS ; nous avons l'obligation de mettre un fichier à la racine puisque il n'est pas possible pour le système de géré le moindre paramètre dans les urls de retour.

Cordialement,[/i]

Bonsoir

Comme rapporté par must_de_cartier ci-dessus, je n'ai rien en ma possession (aucune URL, aucun log, aucun code d'erreur, ...) qui puisse laisser à supposer que la requête retour de la banque ait pu être bloquée par mon logiciel aeSecure alors que toutes URLs bloquées est mentionnée dans un log des accès refusés.

De même le log Apache des accès ne mentionne aucun code 403 (access denied) qui aurait été retourné par aeSecure pour l'URL retour de la banque.

Je dois avouer que je ne connais pas du tout HikaShop (hormis de non) et donc je ne sais pas comment fonctionne ce retour-là.

Ce soir, j'ai proposé à must_de_cartier de 1. réinstaller Joomla (écraser les fichiers distants par une nouvelle version des fichiers issus du zip de Joomla) et 2. réinstaller HikaShop. Autant essayer cette piste-là.

Bonne soirée.

Christophe,
Développeur d'aeSecure

J'ai réinstallé selon les conseils de Christophe Joomla et Hikashop en dernière version. Procédé à un paiement réel.
Même chose : pas de notification de retour de la banque.

Bien sûr ! Pas de souci.

J'espère qu'une solution sera trouvée....

Personnellement j'aurai proposé une réinstallation de HikaShop mais elle a déjà été tentée.
Peut-être une réinstallation de Joomla (juste récupérer les fichiers de Joomla et écraser ceux présent sur votre site).

Je me permets de vous relancer.
Pas de piste pour une solution ?

Merci Jérôme de votre réponse
oui success et atos sont appelés
[17/Dec/2015:13:30:57 +0100] "POST /success.php HTTP/1.1" 302 26 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9"
[17/Dec/2015:13:30:57 +0100] "GET /index.php?option=com_hikashop&ctrl=checkout&task=after_end&Itemid=423 HTTP/1.1" 200 5070 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9"

[17/Dec/2015:13:30:25 +0100] "POST /atos.php HTTP/1.1" 403 650 "-" "-"

Quels sont les logs et fichiers (et où ils se trouvent) qu'il faut je vous prie ?

Le log que m'a indiqué Nicolas "Fichier de log pour les paiements" indique en mode DEBUG

Erreur lors de l'appel de l'API\nMessage d'erreur:
API ERROR
Error get DATA response parameter (wrong length)


Erreur lors de l'appel de l'API\nMessage d'erreur:
API ERROR
Error get DATA response parameter (wrong length)

must_de_cartier wrote:

Je n'ai pas dans les logs de l'hébergeur de ligne bank_response. Mais je ne pense pas que ce soit là car j'ai repris les logs de novembre et je n'ai pas ça non plus.

J'ai vraiment pas du être clair.
C'est bien ça le problème
Un paiement en erreur a un retour

Historique
Type	Statut de commande	Raison	Utilisateur / IP	Date	Informations
payment	Erreur CB	Notification automatique de paiement reçue	testj / 195.68.33.110	2015-12-03 10:41	Commande abandonnée par l'acheteur
creation	créée	Commande créée	testj / 195.68.33.110	2015-12-03 10:41

Historique
Type	Statut de commande	Raison	Utilisateur / IP	Date	Informations
creation	créée	Commande créée	testj / 195.68.33.110	2015-12-03 10:39

Historique
Type	Statut de commande	Raison	Utilisateur / IP	Date	Informations
modification	envoyée		Why8Not / 195.68.33.110	2015-12-01 16:03	
payment	confirmée	Notification automatique de paiement reçue	10.18.86.15	2015-11-19 21:20	Id de la transaction: 221738
creation	créée	Commande créée	fgc / 78.238.154.108	2015-11-19 21:17