SIPS ATOS notifications et...

Bonjour,

Récemment j'ai fait passer le site d'un client de PHP 5.2.17 en 5.3.13 par l'hébergeur. S'il n'y a pas eu de dysfonctionnements particuliers sur le site lui-même, j'ai constaté quelques soucis sur le moyen de paiement SIPS d'ATOS.
En effet le fait de changer de version PHP chez Infomaniak a fait passer le système de 32bits en 64bits, il a donc fallu que je remplace les binaires ATOS par les versions 64 bits. Je ne étais pas rendu compte immédiatement de ce changement et je me demandais pourquoi le paiement par carte bancaire SIPS ne fonctionnait plus (Mercanet).

De même, comme Infomaniak ne supporte pas les fonctions exec() présentes dans les scripts du plugin ATOS, j'avais précédemment dû les modifier pour pouvoir exécuter les binaires via un script Perl CGI, et cela fonctionnait très bien. Depuis le passage en PHP 5.3.13 et plateforme 64bits j'ai dû faire quelques modifs dans ces scripts Perl, sans conséquences.

Néanmoins après divers tests infructueux (avant de comprendre l'histoire du 64 bits et déceler le problème dans mes scripts Perl), et lorsque tout s'est mis à refonctionner normalement, j'ai constaté en effectuant un achat sur le site que je recevais bien la notification de commande créée mais pas celle du paiement confirmée (le statut de commande étant resté sur "créée").

Je suppose évidemment que si je passe la commande sur "confirmée" je recevrais l'émail, mais la question est : Pourquoi le statut de commande n'est-il pas passé sur "confirmée" alors que j'ai eu à l'écran la récap de la transaction ?

• id marchand,
• n° transaction,
• n° autorisation,
• certificat transaction,
• montant,
• etc.

Si vous avez une piste, merci d'avance.

Autre point, en début d'analyse j'ai remarqué qu'un fichier atos.php s'était glissé à la racine du site en question et il contient les lignes suivantes:
$_GET='com_hikashop';
$_GET='component';
$_GET='checkout';
$_GET='notify';
$_GET='atos';
$_GET='fr';
$_REQUEST='com_hikashop';
$_REQUEST='component';
$_REQUEST='checkout';
$_REQUEST='notify';
$_REQUEST='atos';
$_REQUEST='fr';
include('index.php');

La présence de ce fichier est-elle normal à la racine du site ?

Ayant un doute (n'ayant pas trouvé d'infos à ce sujet), je l'ai supprimé. Est-ce que cela peut avoir un rapport avec mon premier problème ?

Merci, a+.

OK Nicolas et merci d'être passé par là.

Si je comprends bien, le fait de supprimer ce fichier n'a pas eu d'incidence sur la validation du paiement par la banque, mais a empêché la validation de la transaction dans Hikashop et n'a pas passé la commande en "confirmée" ?

Donc si c'est bien ça, si je remets ce fichier à la racine tout doit re-fonctionner à nouveau ?

Question subsidiaire : à quel moment ce fichier s'est-il créé à la racine ? (je n'y avais fait attention avant)

Merci Nicolas.

Bonjour,

Question : est-ce qu'il y a dans Hikashop un outil de tracking permettant de voir l'activité des acheteurs. bref un système de logs qui pourrait m'aider à analyser le parcours d'un visiteur connecté sur le site.

Pourquoi ? et bien même si mes notifications d'émails semblent refonctionner (j'avais supprimé le fichier atos.php situé à la racine du site), j'ai eu récemment 2 visiteurs qui ont rempli leur panier, la commande a été créée avec un mode de paiement CB ATOS, puis plus rien cette commande est toujours en statut "créée".

N'ayant pas la visu sur les transactions ATOS, je voulais m'assurer qu'il ne s'agissait pas encore d'un problème de notification. D'ou ma demande de logs éventuels.

Évidemment je suppose que si le client se déconnecte ou ferme la page avant d'aller au bout de la transaction, celle-ci reste en "créée". C'est peut-être le cas.

Merci d'avance des éventuelles infos que vous pourriez avoir à ce sujet.

A+

Bonjour Nicolas,

D'abord je ne parlais pas de Paypal mais de SIPS d'ATOS. Ensuite je ne veux pas suivre les logs du paiement mais juste savoir quelles pages, et surtout la dernière page visitée par l'acheteur.
Tout ça pour essayer de savoir :

• si quelque chose a planté sur une page,
• si c'est une sortie volontaire (le client quitte le site),
• si c'est un abandon (vidage panier manuel par le client).

Alors cela n'est pas forcément du pur Hikashop, plutôt du Joomla, et donc y a t'il un outil que vous me conseilleriez pour suivre pas à pas un acte d'achat sur Hikashop ?

A+

Ça veut dire quoi ?

La commande est créée lorsque on a validé certaines étapes jusqu'à la confirmation du contenu du panier, et là le panier est vidé, n'est-ce pas ?
Si à ce moment le client ferme le navigateur avant la page de paiement ATOS (ou sur cette page), est-ce que la commande passe en statut "annulée" ou reste en "créée" ?
Si non que devient la commande ?
Si oui je ne vois pas ce qui a pu se passer, je n'ai pas eu encore de retour du propriétaire du site pour savoir s'il a une trace bancaire.

Merci Nicolas, c'est ce que je voulais entendre et j'en déduit que si le propriétaire du site n'a pas de trace bancaire, c'est ce qui a dû se passer.
Par contre là au niveau des logs Hikashop on n'a aucune trace n'est-ce pas ?
A partir du moment où on redirige le client vers la page de paiement serait-il possible d'enregistrer cet évènement dans les logs Hikashop ?
Et si oui, y aurait-il un moyen, après un certain délai d'inactivité ou de non retour d'info de la part de la plateforme de paiement d'inscrire un abandon dans les logs ?

OK Nicolas.

La commande passe bien en "créée" après validation du panier, dernière étape du passage en caisse. C'est bien là que l'évènement est inscrit dans les logs (première ligne log dans le détail commande), quelque soit le moyen de paiement (chèque ou CB).

Pour le reste(annulation commande après inactivité) il faudrait que j'ai une version commerciale, mais j'y pense... .

A+