Erreur d'URL de retour après paiement de commande

[L E O]

Bonjour,

 

Sur la configuration décrite ci-dessous, j'ai régulièrement le comportement suivant :

lorsqu'un client valide le paiement de sa commande, il se retrouve sur une autre boutique que celle où il a commandé et la commande est imputée à cette boutique. Ceci se produit quelque-soit le mode de paiement choisi.

 

Environnement :

• PrestaShop 1.6.1.1
• Multiboutique : 7 boutiques
• Catalogue partagé entre toutes les boutiques
• Clients partagés entre toutes les boutiques
• Modules de paiement :
  • Chèque v2.7.1 - par PrestaShop
  • Virement bancaire v1.1.1 - par PrestaShop
  • Devis v2.0 - par Cyril CHALAMON
  • PayPal v3.10.7 - par PrestaShop
  • Systempay v1.5.0 - par Lyra Network

Il y a manifestement une erreur de PrestaShop dans la gestion de l'URL de retour après paiement.

 

Merci pour votre aide pour corriger ou m'expliquer cette incohérence.

[doekia]

Le multishop ayant été développé à l'arrache voici ce qui se passe:

 

Le client commence un panier sur la boutique A

Il change ensuite de boutique en B, sont panier est récupéré mais l'id_shop du panier ne change pas.

Le client passe commande sur B, le moyen de paiment valide la commande (IPN) en  reconstruisant le contexte, dont le shop (ici A)

La commande sera donc accroché à la boutique A, même si le payement intervient en boutique B.

 

Le même genre de problème avec un multi-shop tld type langue où la langue defaut du shop provoque des crash si la shop de paiement n'a pas la langue de la shop de naissance du panier où la solution est pour 5 langues, 5x5 = 25x les tables *_lang. ça résoud les crashs pas le fait que la commande ne se crée pas dans la bonne shop

 

Si dans ton cas, tu ne partages ni commande, ni produit je pense même que tu vas rencontrer d'autres erreurs monumentales

[L E O]

Merci DOEKIA pour cette réponse peu rassurante.

 

Le site tourne depuis plus d'un an en multiboutique et nous avons corrigé la plupart des gros problèmes avec des rustines et des modules complémentaires.

Cependant, ce problème d'affectation de commande persiste et je ne sais pas comment le corriger.

Dans notre cas, le client ne change pas de boutique en cours de route, comme tu le décris dans ton post. Il reste toujours sur la même boutique pour passer sa commande.

Ce qui est vrai, c'est que les clients sont partagés entre les différentes boutiques. Ce choix a été fait initialement lors du passage en multiboutique. Le catalogue est également partagé entre les boutiques.

J'ai l'impression que cette erreur d’aiguillage se produit uniquement pour les clients qui ont déjà commandé dans 2 boutiques différentes.

Est-ce que PRESTASHOP aurait un patch pour corriger ce bug ?

Merci.

[doekia]

Ton analyse est conforme à mon scénario.

Non le client ne change pas de boutique en cours de route mais il y a toujours un panier dès que tu es connecté donc quand tu fini ta commande sur A, un panier vide y apparait et si maintenant tu vas sur B ce panier sera récupéré avec l'id_shop de A.

 

Sur un shop partageant tout (commande/client/stock/..) j'ai implanté des overrides sur Cart afin que updateQty et addCartRule forcent l'id du shop (et la language dans mon cas) du cart à celui du contexte quoiqu'il arrive. Dans le cas où tout n'est pas partagé intégralement je n'ai pas envisagé ce usecase donc je ne sais pas si ce remède ne serait pas pire que le mal

[L E O]

On est d'accord sur tout ... mais concrètement, je fais quoi maintenant. Mon client me tanne avec ça et je ne sais plus quoi lui répondre.

Il faut absolument que je trouve une solution technique pour corriger (contourner) ce bug !

Je peux donner toutes les infos nécessaires pour faire avancer le sujet.

Merci.

[doekia]

Ben tu es une agence ou tu attends que je t'écrive ton code

Edited May 11, 2016 by doekia (see edit history)

[L E O]

Ce n'est pas à Prestashop de corriger ça ?

Il me semble que c'est leur code à la base !