- Posts: 221
- Thank you received: 13
Une expérience de ClicToPay, solution bancaire tunisienne ?
- RG-Consultant
-
Topic Author
- Offline
Je ne suis pas encore au bout, mais ça approche.
Maintenant, le formulaire s'affiche bien et je peux vérifier avec une carte de test. La validation me ramène bien sur le site marchand.
Il me faut maintenant appeler l'adresse de vérification, ce qui va m'obliger à modifier le mot "register" par "getOrderStatus" dans l'adresse du serveur monétique définie dans les paramètres.
Elle est utilisée sous la forme
Je ne désespère plus !
PS : une fois revenu du formulaire chez ClicToPay, on ne passe pas par la fonction onPaymentNotification, que je laisse active ou non la ligne de redirection return $this->showPage('end'); en fin de fonction onAfterOrderConfirm et je ne comprends pas pourquoi.
L'adresse de retour est index.php?option=com_hikashop&ctrl=checkout&task=after_end
Si je définis l'adresse "notify", je passe directement de la validation de commande à l'accueil de la boutique, pas de formulaire ClicToPay
je précise que tous ces tests sont faits sur Hikashop Starter
PS suite : en créant une variable pour récupérer le $varspaymentUrl, l'adresse de demande de notification se crée bien
Please Log in or Create an account to join the conversation.
La fonction onAfterOrderConfirm est appelée à la fin du passage en caisse.
Si vous faites un redirect dans cette fonction, alors cela stoppe l'éxecution du code dans cette fonction et redirige vers l'URL que vous fournissez au redirect.
Donc il est normal que la ligne
D'après les éléments que vous avez fourni précédemment, c'est dans returnUrl que vous voulez fournir l'URL de notification pour que onPaymentNotification soit appelée au retour de la plateforme de paiement.
Je ne sais sais à quoi vous faites référence quand vous parlez de "register", "getOrderStatus" ou "paymentUrl". Ce sont de nouveaux termes dont vous n'aviez pas parlé jusqu'à présent. Veuillez comprendre que je n'ai pas la documentation de clictopay et le lien www.clictopay.com.tn/public_html/media/m...nuel-integration.pdf qui permet apparemment de la récupérée ne semble pas fonctionner de mon coté.
Je pense qu'il serait également intéressant que vous fournissiez le code des fonctions onAfterOrderConfirm et onPaymentNotification dans des balises [ code ] pour avoir une idée plus claire de la situation.
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Les variables dont j'ai parlé sont celles qui servent pour transmettre les informations au serveur. J'ai précédemment évoqué register et getOrderStatus en citant des parties du code pour WP que j'ai récupéré.
Le premier (register.do) est dans l'adresse initiale de connexion au serveur, le second (getOrderStatus.do) sert à demander l'état de la transaction.
J'ai essayé d'utiliser l'adresse de notification donnée dans le plugin exemple
En utilisant précisément cette adress au lieu de $this->pluginConfig[2] défini plus haut dans le code, j'accède enfin au paiement ClicToPay
Je n'ai pas non plus de documentation d'intégration, ce PDF sans aucun rapport avec les boutiques est la seule information qu'a transmise ClicToPay avec les infos d'accès au serveur, l'adresse du serveur de tests et les n° de CB de tests. Il semble que leur seul mode de fonctionnement prévu (en dehors de plugin tiers pour d'autres boutiques) est la création de formulaires sur leur site depuis l'administration du compte, leur validation, puis leur intégration un à un sur le site final. La seule documentation dont je dispose est le plugin WP dont j'ai parlé et qui me permet de savoir quelles variables passer et la réinterrogation du serveur pour la vérification de la transaction.
Dans la mesure où il faut ouvrir une URL avec les informations de commande, récupérer la réponse avec l'adresse "formUrl" qui, elle, ouvre le formulaire sur le site ClicToPay, cette première partie fonctionne en appelant cette formUrl par
L'URL de retour utilisée est
Y aurait-il une autre syntaxe pour que le retour se fasse sur la fonction onPaymentNotification ?
Ce qu'il me faut donc, c'est comprendre où récupérer le passage dans le code après la validation du paiement puisque je n'ai pas d'info montrant le passage dans onPaymentNotification.
Faudrait-il , au lieu de la redirection cURL dans cette fonction, la gérer dans une nouvelle fonction pour obtenir la valeur de formUrl dont le retour se ferait alors dans onAfterOrderConfirm ?
Pour savoir si on passe par onPaymentNotification, j'ai ajouté ce code d'insertion dans les logs
Please Log in or Create an account to join the conversation.
Je pense que ce qu'il vous faut, c'est changer la ligne:
Aussi, pour être sûr de savoir si vous passez dans onPaymentNotification faites plutôt ceci:
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Hélas, aucun passage dans onPaymentNotification.
L'adresse de retour générée est
Please Log in or Create an account to join the conversation.
Ah oui, je vois quel est le souci.
Cela vient de la ligne:
Le code devrait donc être:
Donc il faudrait plutôt faire:
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Avec ce code, on revient bien sur la fonction onPaymentNotification.
Mais après suppression de l'affichage du message et de "exit", la page est blanche.
J'espère que le code neutralisé que j'ai précédemment cité (// Check if the payment is successful or not and redirect to correct page) sera la solution pour récupérer la validation ou non de la transaction et utiliser le code par défaut pour mettre à jour la commande.
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Dans la procédure d'accès au serveur monétique, avant d'y passer je crée une variable "$check_url" contenant l'adresse de vérification du paiement auprès du serveur monétique (que je vois bien dans les logs, inscrite avant l'appel à la page du serveur).
J'ai précédemment défini en début de classe.
Mais dans la fonction onPaymentNotification j'ai mis ces instructionsvar $check_url = '';
$this->payment_params->debug présent dans la fonction de notification du plugin exemple est également vide ou null, sa tentative d'affichage plante la page, et "test" se retrouve dans les logs, pas en echo dans la page vide au retour . Le code qui a remplacé le précédent pour ce nouveau test est
echo ('test'. "\n");
$this->writeToLog('debug :');
$this->writeToLog($this->payment_params->debug);
Je ne comprends pas pourquoi toutes ces variables sont vidées.
Merci de me dire quelle est mon erreur !
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Pour résumer, déclaration de la variable en début de classe
08.15.21 08:38:30 - clictopay
empty
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
La question est donc comment rendre disponible pour onPaymentNotification cette variable "$check_url" qui est générée dans onAfterOrderConfirm et contient l'adresse à interroger pour connaître le succès ou l'échec du paiement et modifier le statut de la commande.
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Bien conseillé (un jour férié
Contrairement à ce que j'avais compris, ce n'est pas l'Id de commande Hikashop, mais "orderId" (la longue chaîne) renvoyé par le premier appel à l'URL du serveur et servant à accéder au formulaire qui est à utiliser lors de cette dernière étape.
Il reste donc à récupérer la variable "ErrorMessage" pour pouvoir confirmer ou annuler la commande.
Encore merci Nicolas pour vos conseils et votre patience ! Je vous recontacterai pour vous transmettre ce plugin pour vérifications et nettoyage.
Il me restera à faire des tests complémentaires après l'étape "statut".
Qui sait, peut-être oserai-je essayer un plugin Paymee ?
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Faudrait-il utiliser plutôt $this->pluginConfig[2] et $this->pluginConfig[2] (ou encore notify_url) ?
PS : l’adresse de la page qui s'ouvre avec un autre moyen de paiement est
index.php?option=com_hikashop&ctrl=checkout&task=confirm&Itemid=126
Please Log in or Create an account to join the conversation.
Oui, tout à fait. Il suffit de décommenter les lignes:
Ces lignes sont commentées car dans la plupart des intégrations, c'est le serveur de la plateforme de paiement qui contacte le onPaymentNotification et donc pas besoin de rediriger nulpart.
Mais là, c'est le retour client qui fait l'appel à onPaymentNotification et donc vous voulez ces lignes de redirection.
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Je reviens sur la page correcte en cas de paiement réussi.
Mais bizarrement, dans le module panier, le prix passe bien à zéro, avec la mention "gratuit", mais le contenu reste affiché même si je change de page. Il faut que je clique sur la croix de suppression du produitMessage
Merci d'avoir passé commande.
Vous pouvez maintenant accéder à votre commandeici.
Et en cas de paiement annulé par le serveur de paiement, je reviens maintenant à la page de passage en caisse et pas sur une page signalant que cette commande a été annulée (elle l'est bien dans la liste des commandes).
J'ai tenté d'utiliser un paiement PayPal Sandbox pour voir ce qui se passe en cas d'annulation, mais la Tunisie n'autorisant pas PayPal, ce mode de paiement n'apparaît pas dans la page de commande.
Please Log in or Create an account to join the conversation.
Dans l'option "clear cart after order is" de la configuration, vous pouvez sélectionner soit:
- confirmed, et dans ce cas le panier est vidé automatiquement durant la redirection sur l'URL "after_end", ou alors la commande est annulée et vous êtes rediriger sur le passage en caisse en cas d'envoi sur la "cancel URL". Dans ce second cas, je recommande d'ajouter un message à l'utilisateur pour lui expliqué le souci avant la redirection avec un $app->enqueueMessage('Il y a eu un pb');
- created, et dans ce cas le panier est vidé directement avant la redirection vers la plateforme de paiement et en cas d'annulation vous êtes redirigez sur l'URL de l'option "URL where to redirect when the cart is empty" de la configuration. Donc là aussi, je recommande de mettre un message avant la redirection.
Il n'y pas normal que vous ayez toujours votre panier. Si ça se trouve ce n'est pas le cas, mais plutôt que vous avez plusieurs paniers rattachés à votre utilisateur suite à vos nombreux tests et du coup le panier est vidé mais vous voyez le panier d'après.
Je vous recommande de refaire un test après avoir supprimé tous les paniers attachés à votre utilisateur.
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
Le multi-panier était en effet activé (par défaut ?), mais je n'en ai trouvé qu'un avec un montant nul. J'ai désactivé cette fonctionnalité avant de continuer mes tests.
Le paramétrage du vidage du panier est défini sur une commande "créée" depuis l'installation, je pense.
Le panier se vide au retour d'un paiement validé et de la confirmation de commande.
Lorsque le paiement a été annulé par ClicToPay, on revient sur la page de validation de commande, panier non vidé (dans les caractéristiques "$dbOrder", le statut est pourtant bien
L'alerte s'affiche bien telle que définie, avec le code de rejet renvoyé par ClicToPay :[order_status] => created
J'ai défini un retour vers la page principale, mais en cas de refus bancaire, c'est la page de passage en caisse qui est rouverte.Annonce
Le paiement n'a pas été validé pour la raison suivante : Payment is declined
Y aurait-il un autre paramètre en cause ? Sinon une instruction pour forcer ce vidage ?
Please Log in or Create an account to join the conversation.
Le panier est vidé automatiquement à la création de la commande si l'option de vidage du panier est configurée avec "créée". Donc je ne vois pas de raison que le panier soit toujours là au retour.
La seule raison que vous voyez un tel panier, c'est que vous avez plusieurs paniers assignés à votre utilisateur.
Désactiver l'option multi panier est une bonne idée, mais comme je disais dans mon précédent message, il faut supprimer les paniers rattachés à votre utilisateur. L'option désactivée évitera de créer de nouveau paniers mais elle n'empêchera pas que vous ayez déjà plusieurs panier affecté à votre utilisateur.
Donc je pense que vous avez toujours le même souci en fait.
Please Log in or Create an account to join the conversation.
- RG-Consultant
-
Topic Author
- Offline
- Posts: 221
- Thank you received: 13
C'est bien ce que j'ai fait : désactiver le mode multi-panier et supprimer celui qui restait
En fait c'est que j'aurais aussi voulu vider le panier en cas d'échec de paiement, dans la mesure où il n'y aura qu'une seule méthode : ClicToPay.
Mais j'ai bien compris le principe et l'ajout d'un message confirmera au client l'échec, car sur le formulaire ClicToPay, le message s'affiche trop vite.
Je vous ai envoyé le plugin par mail.
Ce serait bien que ClicToPay permette de créer un compte de tests pour vérifications, sans compte bancaire tunisien.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.