Carte Bleu Systempay

[louba 8]

Suite à l'installation du module systempay sur la boutique www.animalins.fr la banque me retourne cette erreur. Pouvez vous me dire s'il y a un problème de paramètrage du module ? Merci.

message de la banque:
Un formulaire de paiement a été posté par votre site marchand le 14 octobre 2014 à 04:21:46 UTC depuis l'IP 88.165.60.138 avec l'identifiant de transaction 604670. Dans ce formulaire, la date de transaction est spécifiée au 14 octobre 2014 à 06:21:07 UTC.

Le formulaire de paiement reçu par notre plateforme n'a pas été rejeté, cependant vous recevez ce message car la différence entre l'heure UTC de notre plateforme et l'heure UTC définie dans votre formulaire de paiement est trop importante.

Les causes de cet avertissement peuvent être multiples :
 

• votre serveur n'est pas à l'heure,
• vous ne postez pas l'heure de transaction dans le bon format : format 12H au lieu du format 24H,
• vous postez l'heure dans le mauvais fuseau horaire, nous nous attendons à une valeur UTC (Temps universel coordonné).

[Simon développeur PEEL 0]

Bonjour,

Nous avons fait une modification dans le code du module en 2012 suite au recommandation de systempay. Il faut remplacer la fonction "date("YmdHis",time())" par la fonction "gmdate("YmdHis",time())" pour le calcul de la variable trans_date envoyée à la plateforme de paiement.
=> Vous pouvez faire cette modification dans le fichier functions.php, fonction calculTransDate.

[louba 8]

Ok merci c'est fait.

[louba 8]

Aujourd'hui, on me signale que suite à la modification l'administrateur du site n'est plus prévenu du règlement www.animalins.fr. Faut-il modifier autre chose ?

[Simon développeur PEEL 0]

Bonjour,

 

L'email d'alerte de commande est envoyé lors de la mise à jour automatique du statut de paiement en réglé pour les moyens de paiements direct. L'administrateur doit recevoir une copie de l'email qui est envoyé au client à ce moment.

=> Les statuts de commandes sont-elles mise à jour automatiquement ?

[louba 8]

Oui l'administrateur reçoit une copie de la commande mais c'est le règlement CB systempay qui n'est plus signalé suite à la modification. Est-ce que c'est sur le même document confirmation de commande ? Je crois avoir un spécifique en 2012 suite à migration en 6.31 topic 4308 modif dans fin_commande pour avertir dans tous les cas l'administrateur:

case 'check': et case 'transfer':

Est ce que cela peut jouer?

[Simon développeur PEEL 0]

Bonjour,

 

Oui l'administrateur reçoit une copie de la commande mais c'est le règlement CB systempay qui n'est plus signalé suite à la modification

La modification du format de la date et la mise à jour du statut de paiement sont deux sujets bien séparés. Cette modification ne peux pas influer sur l'envoi des emails de notification de commande.

 

Est-ce que c'est sur le même document confirmation de commande ?

Comme je vous disais dans mon messages précédent la confirmation de commande est envoyé lors du changement de statut de paiement de la commande qui est effectué automatiquement via le fichier modules/systempay/ipn.php.

=> Les statuts de commandes sont-elles mise à jour automatiquement ?

 

Je crois avoir un spécifique en 2012 suite à migration en 6.31 topic 4308 modif dans fin_commande pour avertir dans tous les cas l'administrateur:

case 'check': et case 'transfer':

Est ce que cela peut jouer?

Les modifications faites pour les autres moyens de paiements ne sont pas exécutées, c'est le code dans case 'systempay': de la fonction get_payment_form est utilisé.

[louba 8]

Ou je vois si les statuts de commandes sont mis à jour automatiquement ?

Cela fonctionnait avant la modification du système de date dans systempay il y a donc un autre facteur qui entre en jeux ?

 

PS: Confirmation de l'administrateur "Ne reçoit aucun message de commande" suite à la modification de date. 

[Simon développeur PEEL 0]

Bonjour,

La modification de la date n'a pas de lien avec avec la mise à jour des statuts de commande. Si vous n'avez modifié que le fichier functions.php comme indiqué dans mon message il n'y a aucun lien possible entre votre problème d'envoi d'email et cette modification. L'application de gmdate() a été faite sur le module en 2012, et nous n'avons pas de problème avec le module systempay déjà utilisé par de nombreux clients.

D'autres problèmes peuvent expliquer l'absence de récéption des emails: considéré comme spam, désactivation du template dans l'admin, dépassement de quotas de boite email, ou un autre problème lié à ce sujet.

 

 

Ou je vois si les statuts de commandes sont mis à jour automatiquement ?

Dans l'administration, si la commande passe en réglé automatiquement après le paiement, sans intervention de l'administrateur.

 

Si vous souhaitez que nous intervenions pour ce problème, vous pouvez prendre contact avec le service commercial au 01 75 43 67 97 pour établir un devis relatif à notre intervention spécifiquement sur votre site pour vous aider à solutionner le problème que vous rencontrez.

[louba 8]

j'ai ceci dans function ou j'ai juste remplacé "date" par "gmdate":

Faut-il aussi remplacer "$this->timestamp" par "time" ?

 

 

function calculTransDate()

{

// Date local format : AAAAMMJJHHMMSS

$temp = gmdate('YmdHis', $this->timestamp);

 

$this->trans_date = $temp;

return $this->trans_date;

}

 

 

et dans la liste des commandes "en attente de paiement" pour les règlements carte bleu.

 

Merci.

 

[Simon développeur PEEL 0]

bonjour,

 

Faut-il aussi remplacer "$this->timestamp" par "time" ?

La seul modification à apporter concerne gmdate.

 

et dans la liste des commandes "en attente de paiement" pour les règlements carte bleu.

Il y a donc un problème lié lors de la mise à jour automatique du statut de paiement. Vous pouvez vérifier la bonne configuration des urls de notification dans le back office systempay

[louba 8]

Effectivement tous les paiements CB depuis l'installation sont "en attente de paiement" le retour ne se fait pas. Je n'ai indiqué qu'une url dans le back office de systempay car dans la doc on me dit de ne pas remplir l'url de retour:

 

URL de retour

Cette URL est appelée lorsque l'internaute clique sur le bouton retour boutique à la fin du paiement. Attention vous ne devez pas vous baser sur cette URL pour analyser le retour de votre transaction, mais sur l'URL serveur. Si l'internaute ne clique pas et ferme son navigateur, cette URL n'est pas appelée.

URL de retour de la boutique en mode test:

 

 

URL de retour de la boutique en mode production:

 

 

Quel est cette URL et ou je l'indique ?

[Simon développeur PEEL 0]

Bonjour,

 

Vous avez reçu le module pour la version 6.3.1, le fichier readme de la version actuelle est plus complet. Ci dessous le texte qui concerne les urls :

 

    Configuration à faire dans le back office systempay (onglet configuration.):
    Onglet paramétrage>boutique>NOMDELABOUTIQUE. Rubrique URL de retour :
        URL de retour de la boutique en mode test: http://www.ndd.tld/
        URL de retour de la boutique en mode production: http://www.ndd.tld/
        
    Onglet paramétrage>paramètre de notification. Rubrique "Appel url serveur">Url serveur à la fin du paiement:
        Url à appeler en mode TEST* : http://www.ndd.tld/modules/systempay/ipn.php
        Url à appeler en mode PRODUCTION* : http://www.ndd.tld/modules/systempay/ipn.php
        Adresse(s) mail(s) à avertir en cas d'échec :  email de l'intégrateur

 

Le fichier qui met à jour automatiquement les statuts de paiement est modules/systempay/ipn.php, il faut remplir le champ "Appel url serveur" dans le back office systempay avec l'url de ce fichier.

[louba 8]

Après ces modifications je n'ai plus d"appel à la carte bleu du tout ?

Merci.

 

[Simon développeur PEEL 0]

Bonjour,

 

Après ces modifications je n'ai plus d"appel à la carte bleu du tout ?

C'est à dire?   La modification des "Appel url serveur" permet au serveur de la banque d'appeler le fichier de mise à jour de statut de paiement, et n'a pas d'autre incidence sur le fonctionnement du module.

[louba 8]

He bien je n'ai plus d'appel à la carte bleu alors que le paramètrage coté admin est ouvert. J'ai dans le back office systempay:

Configuration

url: http://www.animalins.fr/modules/systempay/ipn.php              est-ce que c'est bon ?

validation: automatique

 

et rien dans le retour (ce qui est préconisé dans la doc readme) je peux mettre: http://www.animalins.fr ?

 

coté règle de notification:

serveur à fin de paiement: http://www.animalins.fr/modules/systempay/ipn.php

et rien pour les 3 autres.

 

ou est l'erreur ?

 

j'ai interprété ndd comme nom de domaine (http://www.animalins) et tld comme estension (.fr)

 

Appel de systempay pour voir si blocage mais rien.

J'ai regénéré le module coté peel et le certificat de production coté systempay. On n'envoi toujours pas le formulaire de paiement ?

[Simon développeur PEEL 0]

Bonjour,

A partir de vos informations je ne vois pas ce qui peut expliquer le problème.
Comprendre le problème et vous apporter la solution nécessite de regarder dans le code et d'y passer un certain temps.
Dans ce contexte je vous invite à vous rapprocher de notre collaborateur M. Sébastien Pinot au 01 75 43 62 92. Il vous fera parvenir un devis pour notre intervention sur votre site Internet.

[louba 8]

Merci, je pense avoir résolu le problème je crois que le client à changé les codes des certificats. J'ai tout regénéré, réinstallé le module de zéro et suivi vos conseils et cela a l'air de fonctionner. 

[paulanna 20]

bonjour,

j'ai le même problème sur la version 7.04

la fonction calculTransDate

 

j'ai remplacé $temp = gmdate('YmdHis', $this->timestamp);

par

$temp = gmdate('YmdHis', time());

 

est-ce bon ?

[louba 8]

Oui, juste changer date par gmdate cela suffit.

[paulanna 20]

oui merci

mais sur ma version j'ai déjà gmdate

[Simon développeur PEEL 0]

Bonjour,

 

Il n'est pas nécessaire de modifier le calcul de date sur les versions récente du module comme votre version 7.0.4. Quel est le problème que vous rencontrez précisément?

[paulanna 20]

bonjour Simon

j'ai exactement le même message que Louba

 

 

cela devient un peu urgent pour le coup

[Simon développeur PEEL 0]

Bonjour,

 

Dans l'email envoyé par systempay il est indiqué :

 

Les causes de cet avertissement peuvent être multiples :

• votre serveur n'est pas à l'heure,
• vous ne postez pas l'heure de transaction dans le bon format : format 12H au lieu du format 24H,
• vous postez l'heure dans le mauvais fuseau horaire, nous nous attendons à une valeur UTC (Temps universel coordonné).

L'utilisation de gmdate permet de corriger le 3ème point : "vous postez l'heure dans le mauvais fuseau horaire, nous nous attendons à une valeur UTC (Temps universel coordonné).". Le format de l'heure est bien 24H (YmdHis, H correspond à l'heure, au format 24h, avec les zéros initiaux), donc je vous laisse voir avec votre hébergeur concernant la cause possible sur l'heure du serveur.

Pour information le module que vous utilisez est installé sur différents sites PEEL pour lesquels il n'y a pas ce problème.

[paulanna 20]

oui, ce module fonctionne très bien.

 

mais j'ai eu ce message 1 fois.

Aujourd'hui je n'ai plus d'erreur, tout semble rentrer dans l'ordre.

 

Ce qui me perturbe c'est que tu donnes la modif concernant gmdate.

Alors que ma version contient déjà le correctif que tu proposes.