[PS 1.7.6.5] - Pas de moyen de paiement

[kiwifraise]

Bonjour,
Après avoir installé le module en version 5.1 (via l'interface de PS), configuré le module, mis le certificat de la banque, déplacé les répertoires "sensibles" hors accès public, me voilà confronté à un problème assez important :

• Dans la page de checkout, j'ai le message "Malheureusment, aucun moyen de paiement disponible".
• Les restrictions de pays, de groupes de clients, géolocalisation, et préférences de paiement ont bien été vérifiées.
• Après avoir vérifié les logs PHP (aucune erreur visible)

J'ai plongé dans le fichier tggatos.php, et notamment la fonction canProcess (qui s'occupe d'indiquer à PS si le module peut proposer une méthode de paiement).
En ligne 421 :
$last_tid = (int)Db::getInstance(TRUE)->getValue('SELECT max(transaction_id) as valueFROM'.$this->getTable(self::TABLE_TRANSACTION_TODAY).'WHEREdate = \''.date('Y-m-d').'\'', FALSE);
une vérification du dernier ID de transaction (par rapport au max) est faite.
SAUF que :
L'installation du module s'est bien passée, je n'avais pas eu d'erreur.
Mais la table transaction_today n'existait pas.
Par conséquent, PS plantait en silence, car la table n'existant pas, la fonction retournait FALSE immédiatement, ce qui rendait le module non dispo.
Cela n'explique pas pourquoi les autres moyens de paiement étaient aussi bypassés, mais en créant cette table manuellement (avec la définition en ligne 338), tout s'est mis à fonctionner.
Voilà, si ça peut aider...
:)

[kiwifraise]

En revanche, dans le BO, section "Modes de paiement", bien que le module soit actif, j'ai toujours ceci

[TrogloGeek]

La table transaction_today a-t-elle bien été créée en MyISAM et non en InnoDB ? InnoDB ne supporte pas l'auto incrément sur une clé composite...
Et les autres modules disparaissaient parce que la requête génère une exception et qu'il ne doit pas y avoir de try/catch au sein de l'itération sur les modules.

[TrogloGeek]

En revanche, dans le BO, section "Modes de paiement", bien que le module soit actif, j'ai toujours ceci

Peut-être votre IP est-elle géolocalisée hors du système solaire ?

[kiwifraise]

La table transaction_today a-t-elle bien été créée en MyISAM et non en InnoDB ? InnoDB ne supporte pas l'auto incrément sur une clé composite...
Et les autres modules disparaissaient parce que la requête génère une exception et qu'il ne doit pas y avoir de try/catch au sein de l'itération sur les modules.

À l'installation elle semble n'avoir pas été créée du tout par install(), ce qui est étrange car je n'ai eu aucune erreur d'installation. J'ai créé la table en MyISAM.

Ceci dit, le module ne fonctionne toujours pas.
J'ai une exception qui se déclenche au retour du paiement.
J'ai essayé de faire le force return, de vider le panier coté admin, ça revient à la boutique mais ça mouline à "processing payment" (j'ai lu que c'était une histoire de devise dans PS, et l'appel Ajax revient en erreur 500).
Là, j'ai pas le temps d'investiguer plus dans le code (car il faut se farcir à chaque fois un paiement test complet), mais apparement le module n'arrive pas à récupérer le panier utilisé.
Etant donné que c'est pour un client, je vais me farcir le module à 200€ HT de LCL car le temps passe et je dois avoir un truc qui fonctionne...

Merci encore pout ton temps, ton module fonctionne bien sur une autre installation de PS (en 1.6) :)

[TrogloGeek]

L'exception vient du fait qu'après décodage de la réponse serveur le module a assigné la valeur "fr" au numéro de panier... Il y a donc un mic-mac entre les champs retournés par le binaire response et ceux attendus par le module.

Soit il s'agit d'une réponse "courte" (réponse d'annulation et réponse de retour forcé) et le module ne l'a pas identifié comme tel, soit les binaires utilisés ne retournent pas les champs attendus dans l'ordre attendu et il faut ajuster les champs statiques $fields et $shortResponseUnavailableFields pour que cela corresponde aux binaires utilisés.

https://github.com/TrogloGeek/prestashop-tggatos-module/blob/5.1.0/tggatos.php#L2652

[kiwifraise]

Merci pour ta réponse. :)
Sais-tu par hasard comment fonctionne response ? C'est tout de même assez difficile de débugger ça sans se farcir un test en conditions réelles (enfin démo) d'A/R de paiement.
Je jouerai bien avec Postman, mais j'ai aucune doc sur ce qu'attends response.

[TrogloGeek]

Désolé cette semaine je suis en formation sur le développement de drivers linux et j'ai complètement oublié de répondre hier soir. Je n'ai pas le droit de diffuser les documents mais la documentation des binaires est disponible auprès de la banque qui a fourni le binaire (d'ailleurs selon la version SIPS il y a des différences donc autant aller chercher le bon document !).
Le document en question est en général appelé "Guide du programmeur API Plug-in".

Le binaire s'appelle de la manière suivante:
response message=<message> pathfile=<chemin>
où <message> est la réponse bancaire à décoder, et <chemin> est le chemin du fichier pathfile (généré par le module dans le dossier des paramètres).
Le binaire retourne alors si tout se passe bien sur la sortie standard une liste de valeurs séparées et encadrées par des points d'exclamation, avec le nom et l'ordre des champs indiqué dans la doc.

Les messages de réponses bancaires non décodés reçus sont normalement disponible dans les logs du modules (s'il ne plante pas avant de logger...) pour pouvoir justement faire des tests et vérifications manuels.