hello,

bon, je dois installer un paiement securise sur un site client via l'api de la banque pop. j'ai commence aujourd'hui et deja j'ai des problemes !

1- je n'arrive pas a configurer mon url de retour, le bouton "annulation - retour a la boutique" sur la page ou on saisit le num de la carte et la date

2- idem sur la page de confirmation du paiement pour le retour sur le site marchand

j'ai bien etudie leur doc pourtant et tout a l'air de coller, mais il me dit que le path du fichier n'est pas bon ! pourtant, il est bien bon, j'ai essaye en absolu et en relatif mais rien n'y fait

pour info, mon prob est dans le fichier call_response.php au niveau du $path_bin. meme en utilisant la meme url que pour call_request.php ca va pas :@ alors que les 2 fichiers cibles sont ds le meme repertoire ! un truc de malade.

si qqu'un connait, je veux bien de l'aide

enfin ce soir !!! paske demain matin je choppe la hotline

Tu as un fichier du style parcom.XXXXXXXXXX ? C'est là-dedans que y'a les url de retour.

PS : Le problème ne peux pas venir de call_response, c'est call_request qui lance le formulaire (via le script request)

Enfin je dis ça, mais pas pour la banque pop, mais je suppose c'est assez semblable :

Pour lance le paiement :
- appeller call_request.php
- call_request va lancer le script cgi request, avec les paramètres qui vont bien dont pathfile
- pathfile contient les chemin absolu vers les certificats
- dans le fichier de conf qui va avec le certificat, il y a les url de retour (AUTO_RESPONSE_URL,CANCEL_URL et RETURN_URL)

Le 22 mars 2005 - 21 h 31, Erel69 a écrit : Tu as un fichier du style parcom.XXXXXXXXXX ? C'est là-dedans que y'a les url de retour. PS : Le problème ne peux pas venir de call_response, c'est call_request qui lance le formulaire (via le script request) Enfin je dis ça, mais pas pour la banque pop, mais je suppose c'est assez semblable : Pour lance le paiement : - appeller call_request.php - call_request va lancer le script cgi request, avec les paramètres qui vont bien dont pathfile - pathfile contient les chemin absolu vers les certificats - dans le fichier de conf qui va avec le certificat, il y a les url de retour (AUTO_RESPONSE_URL,CANCEL_URL et RETURN_URL)

hello erel,

merci de ta reponse.

alors voila, j'ai bien entendu le fichier parm.xxxxxx, c'est celui que j'ai edite comme indique dans la doc.
voila ce que j'ai mis :
ADVERT!http://www.le_site.com/v2/img/commande/logo_mayo_commande.jpg!
CANCEL_URL!http://www.le_site.com/v2/cyberplus/sample/call_response.php!
RETURN_URL!http://www.le-site.com/v2/cyberplus/sample/call_response.php!

deja, le logo ne s'affiche pas mais peut etre est ce parce que je suis en phase demo, je sais pas trop... en tout cas, sur mes pages de paiement, je n'ai pas le logo mais l'espece de gif bidon d'origine. le fichier est pourtant present sur le serveur car je l'utilise aussi pour les envois de mail de confirmation de commande.

ensuite pour les CANCEL_URL et RETURN_URL, ils disent de mettre le chemin vers call_reponse.php ce que j'ai fait comme tu peux le voir.

donc disons que du cote de ce fichier, je pense que ca colle, peux tu eventuellement confirmer ??


concernant le cheminement, oui, j'ai bien compris que l'appel a faire etait vers call_request.php, je l'ai fait et ca fonctionne car j'ai bien les logos des cartes et j'arrive bien sur l'etape suivante a savoir la saisie des codes de la cb. par contre, ici lorsque je veux faire annulation et retour boutique, ca foire, j'ai edite la page et l'url dans la balise form est :"http://" !!!!!!!! docn forcement, ca chie et ca ne renvoit nulle part. idem si le paiement est accepte, le retour boutique ne se fait pas car l'url la aussi est "http://".
je nage un peu...


dernierement, pour la compatibilite des solutions, presque tous utilisent sips atos, donc je pense qu'on a bien la meme base

ah oui, pour l'histoire du call_response, j'ai essaye de l'appeler, uniquement pour verifier que le response etait accessible. ben pas moyen, j'ai le msg d'erreur suivant :

erreur appel response
executable response non trouve ../bin/response

pourtant l'executable est bien au bon endroit, j'ai utilise la meme syntaxe que pour request dans call_request.php. ds call_request, ca marche, pas ds call_response :@
j'ai aussi mis les droits en execution.

Pour le logo, c'est normal, il doit être sur le seveur de la banque, pas sur le tien.

Sinon, tu as essayé un chemin absolu pour response ?

Le 22 mars 2005 - 22 h 52, Erel69 a écrit : Sinon, tu as essayé un chemin absolu pour response ?

oui j'ai essaye, ca foire aussi en plus de ca, je suis en semi-mutualise chez lost-oasis, ce qui veut dire que je ne sais pas vraiment quelle est la racine a prendre en compte : le rep de base de mon site ou la racine de mon acces.
j'ai un truc de la forme :
/web-toto.com/htdocs/v2/toto.html

jve essayer de faire des tests sur call_request qui fonctionne actuellement en relatif aussi.

voila les tests que je fais dans call_request.php sur le path... en temps reel !!!

avec ../bin/request : marche (call request est ds un rep de meme niveau nomme sample)
avec http://www.site.com/v2/cyberplus/bin/request : marche pas
avec /v2/cyberplus/bin/request : marche pas
avec /data/www/com/l/o/site.com/www/htdocs/v2/cyberplus/bin/request : marche mais meme erreur ensuite si j'appelle directement call_response, il dit ne pas trouver l'exe, mais le test repond aussi ca sur erreur, genre quand tu specifie pas de params a call_response, donc ca veut rien dire

je continue...

Pour connaitre le chemin :

echo $_SERVER['SCRIPT_FILENAME'];

Sinon, c'est normal que ca marche pas d'appeller request par http.

Tu as essayé de mettre response et request dans cgi-bin ou un truc du genre ? Généralement les serveurs mutualisés ont un repertoire ou mettre ce genre de script.

Tu fais comment ton appel au script ?

j'ai pas de rep cgi-bin, je l'ai mis dans un rep cyberplus/bin et ca pose pas de souci, tout s'execute bien.

je l'appelle par : http://www.site.com/v2/cyberplus/sample/call_request.php

derriere apparemment il se demerde pour joindre l'exe request qui est dans bin...

oula je crois que g ptet trouve...

yes ca fonctionne suite au prochain probleme !

merci de ton aide

Et c'était quoi le problème ?

un chemin bidon pour call_response donc j'avais pas la reponse du serveur.
tout est rentre dans l'ordre, le template est pret, il ne me manque que le certif que je devrais recevoir demain pour passer en pre-prod.

merci en tt cas

Et en pre-prod, t'as une CB virtuelle pour les tests ?

Le 24 mars 2005 - 09 h 36, iraysyvalo a écrit : Et en pre-prod, t'as une CB virtuelle pour les tests ?

j'ai recu le code de cryptage a midi, j'ai pas encore eu le temps de passer en pre prod. je pense faire ca ce soir ou demain. d'apres ce que j'ai lu, je devrais avoir des numeros de carte bidon avec un seuil d'achat de 100€. mais sous quelle forme ??? je te dirai ca bientot

Le 24 mars 2005 - 09 h 36, iraysyvalo a écrit : Et en pre-prod, t'as une CB virtuelle pour les tests ?

vla la reponse ! non, j'ai pas de cb virtuelle, ca marche avec une cb classique mais aucune debit n'est fait

Ok .. verifies bien sur ton prochain releve quand meme .. au cas ou

Salut les gras

Pour la banque pop, je sais aps comment c'est, mais pour avoir installer un module de paiement sécurisé avec le CIC, en effet il te file des cartes de test avec lesquelles tu peux vérifier les retour, en choisissant notamment au moment de prendre la carte test si tu veux un retour positif ou négatif, donc normalement,de ce côté la, ton compte perso est à l'abris.

Par contre, en pré-prod, je crois que c'est normaliser à tous, si tu prends en CB de test la tienne, ce te retirera pas physiquement le montant, mais pour les cartes ayant un solde par semaine ou mois limité (comme mwa), ben ca fait comme si t'avais bien retiré cette somme, donc prenez garde a pas faire de grosse somme en test, genre des 0.15€ de test, ca le fait bien...

Voila, je sais aps si mon expérience vous servira, mais sait-on jamais?

@+

ca doit dependre des banques. je passe en prod demain ou apres demain

Ben, t'as qu'a verifier le retour et le delai de remboursement en meme temps