Discussion :

[eric.pommereau]

Bonjour à tous,

D'abord un grand merci pour Thierry Godin alias N1BUS pour son article particulièrement bien fait sur la solution de paiement en ligne d'ATOS que j'ai eu l'occasion de mettre en oeuvre récemment (je passe en prod très prochainement).

Une petite question à ce propos.

Je souhaite passer des informations complementaires au moment de la requête (call_request.php). Le problème est que ce champ semble ne pas être "accessible en écriture" dans call_request. Quand je regarde le dictionnaire de données ce champ ne figure pas pour le fichier call_request mais est accessible en lecture (ils mettent : "fixé par la solution de paiement").

Dans le backoffice d'atos il y a pourtant bien deux champs complementary_info et complentary_code qui devraient permettre ce genre de chose.

Pour le moment je passe par le champ receipt_complement mais ça ne me plait pas...

Qu'en dites vous

@+

[N1bus]

Ben, merci

Les champs complementary_info et complentary_code sont renseignés par le serveur du systeme (ETransaction, webaffaires, etc...) : la banque

Dans la DOC, regarde le tableau "Les parametres de la réponse".
Je ne vois pas les champs complementary_info et complentary_code dans le tableau "les parametres de la requete" : c'est donc que tu ne peux pas les renseigner.

Tu peux mettre jusqu'à 2048 caractères dans le champ "caddie".
L'utilise-tu ? et te reste t'il de la place ?
Rien ne t'empeche de mettre des infos ici : tu récupères un tableau donc tu retrouveras tes infos au retour de la transaction en parcourant le tableau.

Sinon, tu as le champ return_context (256 caractères)

Pour les champs caddie et return_context : n'oublies pas
base64_encode(serialize($var)); à cause des caractères interdits

Le champ receipt_complement n'est pas prévu pour ce que tu veux faire :
C'est un texte qui apparait au retour de la transaction sur le ticket.

[eric.pommereau]

Bonjour Thierry,

Merci de ton aide... ça fait plaisir, en plus quand c'est le rédacteur "himself" qui prend la peine de répondre...

En fait dans le fichier excel que nous retourne la solution de paiement il y a effectivement un champ 'return_context', donc si je peux renseigner ce champ dans call_request c'est cool.

Je vais faire le test et je te tiens au courant.

Merci beaucoup.

@++

[eric.pommereau]

Tu peux mettre jusqu'à 2048 caractères dans le champ "caddie".
L'utilise-tu ? et te reste t'il de la place ?
Rien ne t'empeche de mettre des infos ici : tu récupères un tableau donc tu retrouveras tes infos au retour de la transaction en parcourant le tableau.

Oui j'utilise cette excellente astuce pour le caddie... je n'ai aucun souci pour récupérer mes informations après le paiement, de ce côté tout va bien.

Le problème est de passer certaines informations à la solution de paiement pour que des opérateurs puissent réutiliser ces informations en recevant le tableur généré par le backoffice du paiement en ligne... en l'occurence pour faire le lien entre des réservations et leur paiement.

Voilà

[N1bus]

Ok,

Sauf que le return_context du fichier xls sera en base64 sérialisé (donc illisible)

Il faut que tu envoies des infos en clair si tu veux pouvoir les lire au retour sans passer par php.

Tu remplaces tous les espaces et les caractères interdits par d'autres caractères (tiret, virgule, underscore, etc)

Eventuellement, tu peux essayer de passer le paramètre avec des guillemets simples : return_context='ta phrase ici'

(je n'ai pas testé)

Le problème est de passer certaines informations à la solution de paiement pour que des opérateurs puissent réutiliser ces informations en recevant le tableur généré par le backoffice du paiement en ligne... en l'occurence pour faire le lien entre des réservations et leur paiement.

Et si les opérateurs recoivent l'email en clair c'est pas mieux ?(ou faisable)

[eric.pommereau]

Sauf que le return_context du fichier xls sera en base64 sérialisé (donc illisible)

Il faut que tu envoies des infos en clair si tu veux pouvoir les lire au retour sans passer par php.

Tu remplaces tous les espaces et les caractères interdits par d'autres caractères (tiret, virgule, underscore, etc)

Oui j'affiche 2 identifiants le tout bien collé sans espaces...

Et si les opérateurs recoivent l'email en clair c'est pas mieux ?(ou faisable)

Ils reçoivent un mail également... avec le maximum d'informations, le fait d'ajouter les infos dans le fichier xls permet simplement de recouper plus facilement toutes les informations du processus de paiement.

[eric.pommereau]

Alors tout marche nickel, je vais aussi utiliser en + de ce champ (RETURN_CONTEXT) le champ ORDER_ID... c'est nickel.

Thierry : Encore un grand merci pour ton aide !!

@++

[N1bus]

Bon, ben c'est super.
Merci