Retour de paramètres POST impossibles depuis système epayment
Forum Programmation : Retour de paramètres POST impossibles depuis système epayment
Bonjour à tous,
J'espère écrire au bon endroit.. Voila je suis bloqué par un truc.
Introduction:
J'ai mis en place un système de paiements électronique pour un site. l'hébergeur du site est infomaniak (seveur Apache) et le système de paiement est yellowpay (poste suisse). Je travaille en php.
Le problème:
En effectuant mes tests j'ai cela comme résultat: la redirection en cas d'annulation, d'erreur ou de paiement réussi fonctionne.
MAIS des paramètres devraient être renvoyés en cas de réussite à la page vers laquelle le client est redirigé en cas de réussite, ce qui n'est pas le cas. J'ai demandé aux personnes chargées du système de epayment et ils m'ont répondu que les parmètres ne passaient pas à cause d'une erreur 401. J'ai vérifié et l'url de la page de retour est la même que l'url qui reçoit les paramètres donc cela ne devrait poser aucun problème....
Je ne sais plus que faire puisque je ne sais pas quelle peut être la raison du problème. J'ai besoin de récupérer les infos sur le client après la réussite du paiement pour pouvoir lui envoyer sa commande à l'adresse email qu'il a chez yellowpay.
Quelqu'un pourrait-il m'indiquer ce que je peux modifier ou peut-être faire modifier...
Merci d'avance à celui qui me répondra...
Es-tu sûr de ne rien recevoir du tout en POST OU ne réussis-tu pas à récupérer ce qui est posté ?
Un petit
<?php
|
et une surveillance des en-têtes sur ta page de résultats (par exemple l'extension LiveHTTPHeaders sous Firefox) pourrait déjà te permettre d'en avoir le coeur net.
Quant à l'erreur 401 sous Apache, elle est en générale due à des problèmes d'authentification, ce qui pour le coup, si c'est avéré, signifierait un problème en amont de celui que tu évoques.
Répondre à romainb_idn@idn
Hello,
Merci pour ta réponse. Il semble y avoir plusieurs problèmes. Un des problèmes qui a été résolu par infomaniak c'est le "bloquage" d'envoi des paramètres. Par conséquent je n'ai plus d'erreur 401 Ouf! une de moins.
Par contre je ne peux toujours pas obtenir le contenu des variables et, pire, elles n'existent pas...
J'ai enfin reçu une réponse de yellowpay qui pourrait peut-être m'aider à résoudre le problème:
Yellowpay demande 2 URL :
- Une qui correspond à la page qui s'affiche chez le client une fois le paiement effectué
- Une seconde qui reçoit les paramètres de retour (nom, email, etc du client).
Dans mon architecture les 2 pages sont les mêmes. En effet, la page de retour qui s'affiche chez le client est également chargée d'envoyer la commande sous forme de mail au client et au commerçant. Du coup je me demande si l'application de Yellowpay ne charge pas la page de paramètre et la page de retour en même temps ce qui expliquerait la perte de mes paramètres...
Penses-tu que cela puisse être possible ou je divague complétement (ce qui ne m'étonnerait guère ;-) )
Répondre à zoomy
C'est fortement possible si le système est prévu pour fonctionner avec deux pages distinctes (parce qu'en général on évite d'avoir sur la même page l'enregistrement, et la page d'envoi client pour éviter tout problème de sécurité ou de doublons etc)... Mais bon après je ne connais pas cette solution d'e-paiement mais je te conseille fortement de suivre le modèle d'architecture qu'ils préconisent
Répondre à romainb_idn@idn
Hello,
Ma saga n'est pas terminée. J'ai un truc surper space qui se produit. J'ai donc 2 pages distinctes désormais. 1 pour retour client et une qui enregistre la commande et envoie un mail avec la commande...
J'ai toujours un problème avec les paramètres de retour... Je test avec isset si la variable existe et il semble que l'application trouve que oui car execute l'embranchement isset=oui mais la variable ne contient rien :-(...
Sais-tu de quoi cela peut provenir. La poste(Yellowpay) indique que le retour des paramètres est asynchrone (je sais pas ce que cela signifie). Sais-tu ce qu'il faut faire ? moi je test si une variable existe pour déterminer si c'est effectué. La poste écrit cela concernant le retour des paramètres asynchrone, je cite:
------
2.2.2 URL de retour «Effectué»
Cette URL de retour est appelée lorsque le masque de paiement est fermé après une autorisation effectuée. Le cybercommerçant n’a pas le droit d’utiliser le retour après une autorisation effectuée pour déclencher la fin du processus de commande côté shop. Pour être sûr que l’autorisation a eu lieu avec succès, le cybercommerçant doit se servir du retour des paramètres (voir le chapitre 2.3). Une autorisation peut être effectuée sans appel préalable de l’URL de retour correspondante, par exemple lorsque l’acheteur en ligne ne ferme pas le masque de paiement ou lorsque des problèmes apparaissent au moment de l’appel des URL de retour...
Si un paiement peut être autorisé avec succès, PostFinance enverra au cybercommerçant des paramètres à l’adresse de destination primaire pour la réception du retour des paramètres (URL ou e-mail), en fonction des données de base mémorisées du shop. Cette transmission revêt la forme d’une communication de serveur à serveur invisible pour l’acheteur en ligne. Les données relatives au paiement pourront ainsi être traitées directement dans le shop online du cybercommerçant. Un retour des paramètres ne pourra jamais avoir lieu si l’autorisation n’a pas été effectuée. Se déroulant de façon asynchrone par rapport au processus de paiement proprement dit, le retour des paramètres est déclenché dès que l’autorisation a été effectuée, que l’acheteur en ligne ferme ou pas le masque de paiement. Si la remise a échoué, yellowpay répétera la transmission des paramètres encore trois fois à des intervalles d’une minute. Après quatre tentatives de remise infructueuses, le retour des paramètres sera envoyé à l’adresse de destination secondaire pour la réception des paramètres retournés (e-mail ou URL). Pour être sûr que l’autorisation a eu lieu avec succès, le cybercommerçant doit se servir du retour des paramètres et non de l’appel des URL de retour pour déclencher la fin du processus de commande côté shop. Une autorisation peut être effectuée sans appel préalable de l’URL de retour correspondante, par exemple lorsque l’acheteur en ligne ne ferme pas le masque de paiement ou lorsque des problèmes apparaissent au moment de l’appel des URL de retour
------
Je te remercie d'avance pour ton aide
Message édité par zoomy le 15-01-2007 à 11:17:38
Répondre à zoomy
Il y a 2742 utilisateurs connus et inconnus. Pour voir la liste des connectés connus, cliquez ici.
