Discussion :

[Yellu]

Bonjour,

J'ai la même problématique que SQUAL et ai mis en place une solution comme N1bus l'as proposé, dans la mesure ou je crée le commande et ses lignes avant le paiement.

J'envoi ensuite l'id de commande à la banque qui viens ensuite mettre à jour le status.

Néanmoins cette solution comporte un problème :

Lorsque j'envoi l'id de commande à la banque, si la personne à ouvert deux fenêtre avec la même session, l'un avec laquelle il va payer et l'autre avec laquelle il continue de naviguer.

Avec la première il envoi l'id de commande à la banque et règle une facture de 100€. Mais juste avant de payer il utilise la 2eme fenetre pour augmenter son panier et le faire atteindre une taille de 200€. La banque ayant déjà reçu son id commande ainsi que son montant, le personne va regler 100€ et le site va valider la commande qui sera au résultat pour 200€.

Il faudrait donc verrouiller la commande lorsque l'id commande a été envoyé à la banque, mais ceci empêche donc les modifications de paniers après avoir dis "je veux payer"...

Avez vous déjà rencontrer cette problématique ?

Merci d'avance

[N1bus]

Bonjour, il faut que tu verrouilles le caddie au moment du clique sur le type de paiement (call_request)

Si l'internaute clique sur le bouton "annuler retour à la boutique" , tu peux alors déverrouiller son caddie puisque tu le sais.
dans ta page de retour (call_response) tu as :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if($response_code == "17"){  // abandon par l'utilisateur

ici, tu sais que l'utilisateur est revenu pour éventuellement modifier sa commande. Tu peux donc déverrouiller le caddie.

[Yellu]

Bonjour,

Merci déjà d'avoir tranformer ma réponse en un sujet

Merci aussi pour votre réponse, mais qu'en est t'il de la personne utilisant le bouton précédent, plutot que le bouton retour à la boutique.

Je soupçonne d'ailleur de nombreux Internautes de naviguer de la sorte.

Le retour à la page de choix du paiement ne sera donc pas fait via le bouton "Retour à la boutiue" et il n'y aura pas la présence de la variable de réponse de la banque.

Néanmois il ne fait pas dévérouiller le caddie pour autant car il a pu conserver la fenêtre de paiement dans une autre fenêtre.

Merci d'avance,

[N1bus]

Normalement, si il fait précédent , il devrait retourner sur le call request, donc il reverrouille le caddie.

Sinon, tu peux aussi rajouter un champ id_transaction dans la table caddie et pour chaque objet tu mets le numero de la transaction courante (dans le call_request) avant l'affichage des cartes bancaires.

Si il a 5 fenetres ouvertes et qu'il s'amuse un peu ... au retour du paiement, tu ne récupères que les objets du caddie qui ont le numéro de la transaction courante (le numero de transaction est recupéré dans le call_response ou le call_autoresponse)

[Yellu]

Re-Bonjour,

Voila la solution que j'ai mis en oeuvre :

Je stock le caddie en Session.

Quand l'internaute arrive sur la page de choix du mode de paiement, je crée le commande qui correspond au caddie, et je donne l'ID_COMMANDE à SIPS.

Mon objet Caddie à la particularité lorsqu'on lui ajoute ou retire des éléments de vérifier si il est lier à une commande et si il vois qu'une commande existe, alors il se clone avec le même contenu mais sans commande rattachée.

Ainsi, si la personne fait marche arrière, une nouvelle commande sera de toute façon associé à chaque nouveau panier.

L'inconvénient est le "grillage" d'auto-increment, mais ce n'est pas trop un problème dans la mesure ou cet ID n'as aucune valeur comptable, le vrai facture_id est generée lors du "autoresponse".

Que pensez vous de ma solution ?

Votre solution de mettre le transaction_id (je présume => date('His')), ne m'as pas séduite et voici pourquoi :

Lorsque l'internaute arrive sur la page de choix du paiement, on affecte donc un transaction_id aux objets du caddie et on donne cet ID à SIPS.
Si avec une autre fenêtre l'internaute modifie la quantité d'un objet par exemple, qu'allez vous faire ?

- Modifier le transaction_id de cet objet : dans ce cas au retour de la commande, l'objet ne sera pas validé.

- Créer un nouvel objet avec un transaction_id différent : dans ce cas comment regrouperez vous les objets d'un même caddie si chaque objet à un transaction_id différent et cela va a l'encontre de l'idée d'affecter le transaction_id au moment du choix du paiement.

Je n'ai probablement pas saisi toute votre méthode, pourriez vous me dire si la mienne vous semble valable ou si je dois revoir ma copie

Merci à vous

[N1bus]

ça devient pas simple.

Voila mon idée :

Un visiteur commande 3 courgettes et deux poireaux.

Quand il arrive sur le call_request, on verrouille son caddie et on ajoute l'id de la transaction aux poireaux et aux courgettes.
A ce moment là il a bien 5 elements dans son caddie qui est locké.

Lorsqu'il est sur la passerelle de paiement :

1) Si il revient avec le bouton back : il retourne donc sur le call request : on a toujours son caddie verrouillé.

2) Si il revient avec le bouton abandon : il retourne sur le call_response : on peut delocker son caddie et il continue ses emplettes.

3) si il a une autre fenetre d'ouverte : meme si il incrémente un produit , il n'incrementera pas le caddie qui est locké car avant d'incrementer, il faut verifier que le caddie n'est pas locké (cqfd). donc quand il paiera , il paiera bien ce qu'il doit par rapport au caddie qui a été envoyé à la banque

après , je n'ai pas trop bien compris le cheminement ...