traitement paiement atos

[michmuch51]

Salut le Hub,

j'en appelle aux expert e-commerce: je suis actuellement sur le point de changer de systême cb, en restant sur atos, et je souhaite savoir comment vous traitez vos paiements clients en cb:

1. Vaut il mieux que le client arrive sur une page que sur cette page la commande se créé et que seulement quand le client est passé par la banque le code retour nous dise comme ok, ou paiement refusé ou annulé par exemple et là on change le statut de la commande en fonction... en sachant en plus dans ce cas, que si le client une fois sur le serveur de la banque ne clique pas sur annulé ou valider son numero de cb, mais ferme simplement la page, est ce que le script retour de la banque est envoyé quand même?

2.ou vaut il mieux créer la commande sur un script en retour de paiement uniquement si ce dernier est accepté?

en sachant que sur les variables de retour atos pour le script automatique, les sessions du client n'étant pas conservées dans les variables, je ne vois pas comment voir le contenu de son panier.

mais en revanche sur la solution numéro 1, si la commande est créée avant le passage en banque, d'une part les numéros de commande ne pourront pas se suivre car certaines ne seront pas validées, et en plus ds le cadre d'un e-commerce où l'on décrémente le stock, si la commande n'est pas validée, il ne faut pas oublier de remettre le tout en stock.

je ne sais si j'ai été très clair enfin bon si vous vous êtes déjà penché sur un systême de paiement cb, vous êtes forcement passé par là...

Modifié 17 Février 2008 par michmuch51

[Anonymus]

Bon, pour te rassurer, dans le cas où l'internaute part à la banque pour valider son achat, et 'ne revient pas', la banque t'envoie tout de même un.. ping pour te donner l'état de la transaction. Donc, no soucis de ce coté là.

Pour savoir où tu en est, sinon, tu prend par principe le panier du client. Le client par à la banque ? Tu gardes son panier. Il revient de la banque ? Tu gardes encore son panier. Tu l'avertis tout simplement que tu attends la réponse de la banque (qui peut, parfois, tarder), et que tu l'avertiras par mail.

Lorsque tu as la réponse de la banque, alors là tu peux envoyer l'ens. > Mail au client, décrémenter le stock, etc..

Nicolas.

[michmuch51]

Merci Anonymus,

c'est ce que je pensais faire, mais le panier du client tu l'envoies à la banque sous forme de sessions alors? ou tu le mets dans une table provisoire au niveau de la bdd?

Je pensais plus passer par une table provisoire ds la bdd, car je ne vois pas trop comment envoyer le panier à la banque sous forme de sessions et surtout que la banque me le renvoi par la suite, je sais qu'une variable est réservée pour y mettre ce que je veux mais de là à envoyer le panier du client c'est un truc que je n'ai encore jamais fait, je vais me documenter un peu dessus si tu as une piste, n'hésite pas à me la donner

[Anonymus]

A priori, le mieux est de générer une clé unique, et d'envoyer cette clé à la banque.

A partir de cette clé, tu as ton id d'enregistrement dans la base, qui correspond à une table temporaire.

En aucun cas j'enverrais les données du panier à la banque en attendant qu'elle me les renvoies.

[iNCiTE Web]

Moi je procède ainsi :

- au moment où le client valide sa commande je génère la commande (avec id unique donc)

- il choisit son paiement, si CB on l'envoie vers la banque (avec id de commande-montant), si c'est par chèque on décrémente le stock et on met en attente

- on envoie un mail "attente de votre paiement"

- ensuite soit on récupère la réponse de la banque tout de suite (parce qu'il a cliqué "retour boutique"), soit on a le "auto-response" : si OK on décrémente le stock, on balance le mail de confirmation de paiement reçu, si refusé on indique qu'il faut choisir un autre moyen de paiement ou recommencer avec une autre carte (dans ce cas la commande reste en attente dans le compte client). La banque retourne aussi l'id qu'on avait transmis

A chaque étape, je change un code_etat dans la table des commandes pour savoir où on en est (attente paiement, paiement ok, emballage/expédition, livré)

[michmuch51]

impeccable merci pour votre aide,

je le fais finalement à la inciteWeb... je créé ma commande en bdd avt paiement et change le statut en update en fonction de la réponse de la banque

[AlainRoche]

Salut,

Solution1: tant que le client n'a pas payé, je ne crée pas de commande temporaire dans la bdd. Je fais transiter le caddie par la variable caddie que j'envoie à la banque (j'utilise atos aussi) et quand j'ai l'auto-response de la banque, je récupère le caddie que la banque me renvoie, et là je crée une commande. Ca permet d'éviter de se faire "spammer" par un robot qui créerait des commandes à l'infini, est-ce que ça arrive souvent?

Solution2: je crée une commande, je la marque comme 'en attente de paiement', et quand j'ai la réponse de la banque je la marque 'payée'.

Je ne sais pas en pratique ce qui est le mieux.

Dans le cas du 1, ça évite d'encombrer la bdd avec des commandes qui ne sont pas payées, et ça évite de devoir la purger de temps en temps, par contre ça requiert un peu plus de code.

Modifié 26 Février 2008 par AlainRoche