Johnny124
27 Oct 2010, 14:03
Bonjour,
J'utilise donc systempay de la banquepopulaire.
Voici mon souci :
2% des commandes n'apparaissent pas dans l'admin avec ce mode de paiement.
Autrement dit, j'ai donc bien le paiement dans l'outil de gestion de caisse, mais je n'ai pas la commande dans l'admin.
Je suis donc obligé de redemander le panier au client, ce qui fait un peu "tache".
J'ai appelé le support, on a vérifié ensemble les paramètres, et totu semble ok.
On me dit que c'est peut être parce que la sessions expire pendant que le client paye.
Quelqu'un a-t-il déjà eu ce problème?
Je voulais au moins être averti quand il y avait ce type de problème en modifiant le code de checkout_process_vads.php de la facon suivante :
Code d'origine :
Citation
// If payment gateway has been authentified, let it borrow the customer's session to confirm the order
if($mode=='' || $valid_signature){ //TODO : à terme, garder le test sur $mode ??
session_id($_POST['cust_id']);
}
// Then we launch the standard checkout_process
include 'checkout_process.php';
Code modifié :
Citation
// If payment gateway has been authentified, let it borrow the customer's session to confirm the order
if($mode=='' || $valid_signature){ //TODO : à terme, garder le test sur $mode ??
session_id($_POST['cust_id']);
} else {
Code pour envoyer un email et me prevenir
}
// Then we launch the standard checkout_process
include 'checkout_process.php';
Qu'ne pensez-vous?
Merci de votre aide.
J'ai le même soucis que toi, j'essaye de trouver une raison à cela mais cela semble réellement aléatoire. J'ai suivi une fausse piste à un moment donc, chou blanc pour l'instant.
Johnny124
7 Nov 2010, 20:21
Bon ca me rassure déjà que je sois pas le seul
Comment gères-tu ce problème pour l'instant? Contrôle de tous les paiements chaque jour?
As-tu contacté la hotline pour les informer du problème?
Merci de ta réponse.
Salut,
Pour l'instant j'ai installé un bricolage par mail. Aujourd'hui je n'ai pas eu de soucis mais hier oui. Je vais les appeler cette semaine, je ne vais pas supporter ca bien longtemps.
Johnny124
8 Nov 2010, 09:24
Ok alors tiens-moi au courant s'il te plait. Je ne vois pas comment résoudre ca
Quelle version de module de paiement sytempay as tu ?
La dernière est la 2.6b
Johnny124
9 Nov 2010, 17:07
J'ai la 2.5b.
Mais lorsque j'ai appelé la hotline, il m'ont dit que les changement de la 2.6b ne résoudrait pas mon problème
Tu es sur la 2.5 également?
Tu parles, j'avais la 2.0
Je viens d'installer la 2.6b. Au début aucune commande n'était validée. Après quelques essais, tout va bien en apparence. Je passe en PROD pour ce soir et je guette la faille. Peut être que mon problème ne va pas être résolu mais peut être que oui. J'ai trouvé une erreur dans la procédure d'install. Si je n'ai plus de soucis, je te dis ce que j'ai modifié, sinon ca ne sert à rien de changer quoi que ce soit chez toi pour l'instant.
oneill
12 Nov 2010, 22:55
Bon, c'est mieux mais y a encore du boulot
J'ai activé le retour automatique sur 5 sec avec message de ne toucher à rien et surtout de ne pas fermer la fenêtre car, je crois que c'est la que ca merde. Maintenant les gens doivent se rendre compte de je ne sais quoi car ils règlent 2 fois sans broncher ! J'annule bien sûr mais bon, mon bonheur n'est pas encore total.
Johnny124
13 Nov 2010, 15:45
Tu penses donc que c'est les clients qui n'attendent pas le retour automatique?
oneill
13 Nov 2010, 15:52
Je me trompe peut être, mais je crois que oui.
Johnny124
15 Nov 2010, 17:39
J'ai moi aussi mis sur 5 secondes contre 10 secondes avant.
Ce que je ne comprends pas si on suit ta piste, c'est pourquoi est-ce que nous serions les seuls à avoir ce problème alors que les autres devraient également l'avoir logiquement?
De plus, si on active pas le retour automatique, cela voudrait dire qu'aucune commande n'est validée?!
oneill
21 Nov 2010, 03:35
Je crois plutôt que ce système n'aime pas trop le traffic Dès qu'il y a plusieurs personnes parties payer en même temps, ca se mélange les pinceaux. Si quelqu'un avait une info sur ce qui valide la commande, ca m'aiderait. Mais déjà un truc qui récupère une ID de session avec session_id() plutôt qu'avec tep_session_id() et qui part avec une prédiction de numéro de commande, me fout les boules et en dit long quant à l'intégration faite pour Osc.... Je commence même à regretter Atos.
Je crois que le système de validation par comparaison de signature SHA est assez aléatoire. Je m'en suis rendu compte avec l'intégration de SoColissimo pour peu qu'on y inclus des données non fixes.. Bien sûr, on bons statisticiens, on vous répondra que 5 ou 6 % c'est pas grand chose mais comme il s'agit de notre pognon, faudra nous excuser d'être à cran.
Johnny124
21 Nov 2010, 14:31
+1
Peux-tu me dire en quoi consiste ton bricolage par mail dont tu parlais dans les premiers emails?
Merci à toi
oneill
21 Nov 2010, 18:07
Mes premiers réglages n'ont pas été des plus concluants, on dira (changement de version). J'en ai fait d'autres ce matin et depuis, aucun loupé.
J'en ai fait plusieurs qui ne vont pas te servir au moins pour le premier (enfin je crois). J'utilise YASU, un vieux système de réécriture d'url et j'avais eu des soucis il y a des années avec Atos à cause de lui. J'ai modifié le script de vads afin d'éviter d'utiliser les url réécrites pour les retour.
Ensuite, j'ai mis les bons termes sur des instruction php qui sont spécifiques et redéfinies dans Osc comme tep_session_id() au lieu session_id(). Mais, je ne suis pas sûr que ce soir aussi important que ca pouvait l'être sur Atos. Vads fait une comparaison de chaînes cryptés en SHA et peut ainsi être accolé (et non intégré à mon sens) à n'importe quoi ou presque.
Dans le module de paiement sur l'admin Osc, j'ai remplacé l'url de retour en cas de succès. J'avais pointé sur checkout_process comme le faisait Atos, peut être à tord. Je pointe désormais sur checkout_process_vads vu que c'est la que la signature est comparée avec celle en retour avant d'être redirigé vers checkout_process.php
De plus, car je crois encore à mon ancienne idée du client qui coupe sa fenêtre trop vite ou qui bloque, j'ai réglé mon module en activant le retour automatique vers ma boutique et les délais à 5 secondes en cas d'échec et 0 seconde en cas de succès ce qui évite purement et simplement l'affichage de la page qui m'inquiétait.
Et, comme je te disais, pas d'erreur depuis ce matin. J'attends de voir si ca va tenir ou pas.
Johnny124
21 Nov 2010, 18:19
Ok tiens moi au courant s'il te plait.
Et j'en ferai de même.
oneill
23 Nov 2010, 11:28
Depuis mes modifs, pas un seul loupé.
Johnny124
23 Nov 2010, 15:23
Donc si on récapitule :
1) Remplacement session_id() par tep_session_id() dans le code
2) Bien mettre le retour vers checkout_process_vads (pour moi ca c'est fait depuis le début)
3) Et enfin mettre à 0 de délai le retour vers la boutique
J'espère ne rien avoir oublié.
En tout cas pour moi, j'en ai pas eu depuis que j'ai mis 5 secondes
Donc j'attends de voir et si nécessaire je ferai tes modifications 1 et 3
Merci de ta collaboration en tout cas
oneill
23 Nov 2010, 16:07
Ça a refait cet après midi chez moi....
Par contre j'ai vu d'où ca pourrait venir. J'attends l'appel du technicien. Ca arrive quand plusieurs personnes règlent en même temps mais pas nécessairement sur cyberplus. Ca viendrait donc bien du n° order_id qui est une prédiction de n° de commande. J'ai survoler vite fait le fichier vads et ce p**** de order_id est comparé à l'arrivée.
Je te tiens au courant de toute façon.
oneill
24 Nov 2010, 20:19
Autre piste :
As tu activé dans ton admin Empêcher les sessions d'araignée ?
Si oui, regardes dans le fichier catalog/includes/spiders.txt si tu as un user agent du nom de java/ ?
Si oui, vires le !
On dirait la réponse automatique de la banque (du moins ca y ressemble terriblement.)
Adresse IP : 194.50.38.134
Host : domain2.lyra-online.com
inetnum: 194.50.38.0 - 194.50.38.255
netname: LYRA-NETWORK
descr: Lyra Network
descr: Toulouse
En tous les cas, ca c'est eux. Et Java/1.6.0_16 leur USER_AGENT
J'attends voir... Mais j'avais eu ce problème avec Atos.
Johnny124
24 Nov 2010, 20:32
Voici le contenu de mon fichier, pas de java à l'horizon :
Code
$Id: spiders.txt,v 1.2 2003/05/05 17:58:17 dgw_ Exp $
almaden.ibm.com
appie 1.1
architext
ask jeeves
asterias2.0
augurfind
baiduspider
bannana_bot
bdcindexer
crawler
crawler@fast
docomo
fast-webcrawler
fluffy the spider
frooglebot
geobot
googlebot
gulliver
henrythemiragorobot
ia_archiver
infoseek
kit_fireball
lachesis
lycos_spider
mantraagent
mercator
moget/1.0
muscatferret
nationaldirectory-webspider
naverrobot
ncsa beta
netresearchserver
ng/1.0
osis-project
polybot
pompos
scooter
seventwentyfour
sidewinder
sleek spider
slurp/si
slurp@inktomi.com
steeler/1.3
szukacz
t-h-u-n-d-e-r-s-t-o-n-e
teoma
turnitinbot
ultraseek
vagabondo
voilabot
w3c_validator
zao/0
zyborg/1.0
De plus, concernant le fait que plusieurs personnes achètent en même temps ne pose pas réellement de problème chez moi. Lorsque le paiement est validé, un nouveau numéro de commande est assigné si le numéro de commande est déjà pris. Par contre, dans l'outil de gestion de caisse, j'ai plusieurs client avec le même numéro de commande. Mais dans l'admin ils ont bien un nouveau numéro de commande
oneill
24 Nov 2010, 21:27
Rooooo j'y perd mon latin moi !
oneill
28 Nov 2010, 12:30
Je suis arrivé à reproduire l'erreur. Cela arrive si le client à bloqué l'usage des cookies sur son navigateur. Au retour, il perd sa session et la commande n'est pas validée mais la banque encaisse. Dans mes logs, j'ai retrouvé des appel à cookie_usage.php.
Peut être est-ce ca ? Y a t'il encore des paranos qui bloquent leurs cookies ? (Au moins 2% chez toi ?)
Pour ma part, plus un seul plantage depuis ma dernière intervention ici et pourtant, en ce moment, le bazar carbure.
Johnny124
29 Nov 2010, 15:15
Moi aussi je n'ai pas eu trop de problème avec systempay récemment.
J'interrogerai les clients à ce sujet (cookie désactivé) si l'erreur se reproduit, et je te tiendrai informé sur ce même post.
Toulousain
6 Jan 2011, 15:15
bonjour,
je tiens à préciser les modules de paiement maintenu par lyra network société qui a en charge la solution de paiement systempay pour la banque populaire et la solution PayZen pour toutes autres banques, met à disposition le module de paiement gratuitement pour oscommerce.
Ces modules sont disponibles sur
http://store.payzen.euou
https://systempay.cyberpluspaiement.com/htm...tributions.htmlle module de paiement en 1 fois est gratuit
le module de paiement en plusieurs est payant
Concernant le problème d'enregistrement de commande il faut s'assurer que vous avez bien renseigner dans l'outil de gestion de caisse l'url serveur. C'est l'url qui sera appelé dès que le paiement sera terminé en mode silencieux c'est à dire transparent pour l'internautes.
Le résultat de cet appel est enregistré dans l'outil de gestion de caisse=> cliquer sur le paiement et consulter l'onglet historique.
Vous ne devez pas avoir d'erreur si tel est le cas la commande est enregistrée dans le back office oscommerce.
Si vous avez des erreurs contacter le support au 08 11 363 364 pour les analyser.
Si vous décider d'activer le retour automatique pensez à valoriser les paramètres suivant:
délai 0
mode GET
URL de retour en cas de succès => checkout_process.php.
En espérant vous avoir aider
Merci
Le mode GET me pose des problèmes avec mon url rewriting.
J'ai un petit soucis avec la page d'arrivée en cas de succès pour le client : Il doit, normalement, arriver sur checkout_success mais il atterri dans son panier vide !
En fait la page success est appelée mais aussitôt après j'ai une demande de lyra-network qui appelle la page login sans n° de session dans l'url donc, ce qui l'envoi dans son panier par défaut, les pages du checkout_process étant interdites aux visiteurs non logués.
Maintenant que les fêtes sont passées, je vais m'y remettre et analyser ce qui se passe exactement. Je pointe certainement sur une mauvaise page (process au lieu de success)
flcflc
16 Feb 2011, 02:01
Je me suis retrouvé avec le même problème mais non pas sur 2% des commandes mais sur un pourcentage bcp plus élevé depuis 6 jours.
Or cela ne m'est JAMAIS arrivé en 5 ans d'utilisation de l'ancien système.
Je précise que rien n'a été changé sur le site et encore moins le module de paiement!
Première chose
Installation de Order check (on duplique la commande dans une table avant le paiement);
Si la commande est perdue, il est possible de l'ajouter en 1 clic.
ça ne règle pas le problème mais au moins on en a connaissance et l'on peut recopier la commande en 1 clic.
-URL serveur
ndd/checkout_process_vads.php
-url de retour
checkout_process.php
Pour des raisons de url rewrite je force les cookies.
Bon, je ne sais pas si ça va tenir mais au moins j'ai de nouveau des commandes test enregistrées dans mon osc!
Firefox OK
IE8 OK
Chrome OK
Safari OK
Encore un truc bien étrange et l'on vous assurera que rien n'a été changé au niveau des flux...
En tout cas j'ai rarement eu autant de paiement en double ces derniers temps.
Bertrandolivier
16 Apr 2011, 10:53
Citation (Johnny124 @ 15 Nov 2010, 17:39)
J'ai moi aussi mis sur 5 secondes contre 10 secondes avant.
Ce que je ne comprends pas si on suit ta piste, c'est pourquoi est-ce que nous serions les seuls à avoir ce problème alors que les autres devraient également l'avoir logiquement?
De plus, si on active pas le retour automatique, cela voudrait dire qu'aucune commande n'est validée?!
Bonjour,
Depuis un mois après mon transfert de ATOS à SYSTEMPAY, certaines commandes ne s'enregistrent pas.
Je les retrouves alors dans "Précommandes".
Où est-ce l'on modifie le temps de retour comme indiqué plus haut ?
Cordialement,
Bertrandolivier
19 Apr 2011, 09:34
Y'a t-il quelqu'un pour m'aider ?
Je n'arrive pas à trouver de solution à ces commandes qui ne s'enregistrent pas.
Lors de la confirmation du paiement, les commandes ne sont enregistrées que lorsque que le client clique sur "retour à la boutique".
Dans la config de SystemPay, j'ai bien indiqué checkout_process.php comme URL de retour de la boutique en mode production.
Cordialement,
Bertrandolivier
22 Apr 2011, 10:11
Apparemment, le problème n'est pas résolu.
Cela arrive lorsque le client ne clique pas sur "
retourner à la boutique" (voir image ci-dessous)
Où et comment régler le temps de retour automatique ?
Peut-être serait mieux de changer de message et remplacer par confirmation de votre commande ?
Bertrandolivier
22 Apr 2011, 11:07
Résolu ! Tout fonctionne bien.
La totalité des commandes sont enregistrées.
Merci pour votre aide !
Amicalement,
Johnny124
6 Mar 2012, 11:30
Bonjour,
Pour moi le problème persiste et c'est très enervant.
Cordialement.
Romain-Rom
23 Apr 2012, 08:39
Bonjour,
Le même problème pour notre boutique en plus global : aucune commande ne s'affiche dans le back office et le retour boutique foire a chaque fois...
pourtant nous avons validé toutes les Cartes lors des tests.
Le passage en mode production serait-il la clef de nos problèmes ? ou est-il impératif que tout soit fonctionnel lors de la phase de test ?
Notre problème se situe lors du retour boutique (vers checkout_process), on a l'impression que toutes les variables de la signature disparaissent et les références du client avec, seul le numéro de commande est visible sur la page de validation (checkout_success) et toute une série de bugs liés a des liens incorrects, ce qui rend le processus de paiement peu crédible et l'affichage carrément bordélique.
Nous avons essayé toutes les recommandations de ce topic car les erreurs nous semblent similaires.
Notre structure est très modifiée mais nous ne pensions pas avoir à modifier autant le code fournit par la banque...
Nous sommes sous osc 2.2 donc peut être que le module a été mis à jour pour des versions plus récentes d'oscommerce ?
(on en est déjà à une semaine de débugage donc si quelqu'un a une révélation, même des plus insignifiante , elle sera la bienvenue )
merci encore de votre aide (c'est grace a ce topic qu'on est arrivé a avancé...un peu)
Gnidhal
23 Apr 2012, 08:49
pas constaté ce genre de problème mais as-tu bien le retour vers checkout_process_vads.php ?
ce script vient s'interfacer avant le checkout_process original :
Code
<?php
################################################################################
#####################
#
# Module pour la plateforme de paiement Systempay
# Version : 2.6b (révision 25621)
# ########################
# Développé pour osCommerce
# Version : 2.2ms2
# Compatibilité plateforme : V1
# ########################
# Développé par Lyra Network
# http://www.lyra-network.com/
# 01/06/2011
# Contact : supportvad@lyra-network.com
#
################################################################################
#####################
/*
* This file is an access point for the payment gateway to validate an order.
*/
$certificat_test = '';
$certificat_prod = '';
$mode = '';
// Verify the payment gateway identity
$valid_signature = false;
$signature = $_POST['version']."+".$_POST['site_id']."+".$_POST['ctx_mode']."+".$_POST['trans_id']."+".$_POST['trans_date']."+"
.$_POST['validation_mode']."+".$_POST['capture_delay']."+".$_POST['payment_config']."+".$_POST['card_brand'] ."+".$_POST['card_number']."+"
.$_POST['amount']."+".$_POST['currency'] ."+".$_POST['auth_mode'] ."+".$_POST['auth_result'] ."+".$_POST['auth_number'] ."+"
.$_POST['warranty_result'] ."+".$_POST['payment_certificate'] ."+".$_POST['result'] ."+".$_POST['hash']."+";
if( ($mode == 'TEST' && $certificat_test != '')) {
$signature .= $certificat_test;
}
if($mode == 'PRODUCTION' && $certificat_prod != '') {
$signature .= $certificat_prod;
}
$signature = sha1($signature);
$valid_signature = ($signature == $_POST['signature']);
// If payment gateway has been authentified, let it borrow the customer's session to confirm the order
if($mode=='' || $valid_signature){ //TODO : à terme, garder le test sur $mode ??
session_id($_POST['cust_id']);
}
// Then we launch the standard checkout_process
include 'checkout_process.php';
?>
Après, un contact avec le support de Lyra-network me parait conseillé dans ton cas.
Romain-Rom
23 Apr 2012, 09:34
Nous avons déja essayé checkout_process_vads, en URL de retour en cas de succès ainsi que checkout_process.
Nous pouvons donc affirmer que le problème ne vient pas de l'URL mais de la signature.
Tout ce qui est envoyé en POST (dans la signature) fait buggé le processus, aucune valeur de POST n'est prise en compte.
Nous avons également contacté le support par téléphone mais ils n'ont pas su nous répondre étant donné le dégré de modification de notre oscommerce.
Gnidhal
23 Apr 2012, 10:23
bah alors il faut que tu analyses les valeurs POST de retour via checkout_process_vads (qui est impératif pour décoder les valeurs de retour)
un traceur espion en txt qui inscrit les contenu de POST dans un fichier est un bon moyen de comprendre ce qui se passe.
Comme tu le soulignes, ce sont tes modifications qui rendent la validation improbable. A toi de mettre en place les outils de débogage.
juju74
23 May 2012, 11:38
j'ai aussi ce même problème avec Spplus!
c'est quand le règlement est "en attente de remise" par la banque que ca coince!
Gnidhal
23 May 2012, 17:17
spPlus est déjà passé sur systemPay ?
je croyais que c'était prévu pour juillet seulement ?
spplus passe a systempay au 30 jiun 2012 officiellement!
pour ce qui est du bug des paniers:
forcer les cookies : oui
URL de retour en cas de succès
http://www.monsite.com/catalog/checkout_process.php et non checkout_success.php
pour le moment ca marche avec tout les navigateurs. (paiment validé, panier vidé ....)
par contre, dans leur tuto il indique pourtant : forcer les cookies sur false !
bonjour,
La migration de Spplus vers Systempay est largement entamée.
cela dépend des CE, mais il y a une date limite où la lumière s'arrête. donc il vaut mieux s'en occuper sans trop tarder.
certaines caisses ont déjà largement dépassé les 50% de migration. La lumière est coupée normalement le 30 septembre 2012.
Le support Systempay reste à l'écoute pour vous accompagner dans cette migration.
Je viens de faire la migration, alors en fait, c'est le même bazar qu'avant.
La commande n'est pas créée avant le paiement, donc en cas de problème on a un règlement d'un coté et pas de commande à mettre en face.
Dans le module, il y a même un truc que j'adore, très drôle :
il y a une fonction getIdOrder() qui va définir le numéro de commande qui sera envoyé à SystemPay.
Sauf que cette fonction compte le nombre d'enregistrement, et y ajoute 1.
1) - Si deux clients se présentent en même temps, si le deuxième valide sa commande avant que le premier ne soit revenu sur votre boutique (via checkout_process), les deux clients ont réalisé un paiement pour le même numéro de commande.
2) - Si un client ne fait pas le retour boutique pour quelque raison que ce soit, vous avez un paiement pour 0 commande.
Cas numéro 1, SystemPay ne connaît pas le numéro de commande de la deuxième commande, si l'URL Serveur doit faire une validation, elle tape à coté...
Cas numéro 2, c'est la même histoire qu'avec spplus.
J'ai modifié mon ancien module spplus inspiré du PaypalIPN et ça devrait régler les cas 1 et 2.
@+
Johnny124
10 Sep 2012, 09:14
Citation (juju74 @ 1 Jun 2012, 14:56)
spplus passe a systempay au 30 jiun 2012 officiellement!
pour ce qui est du bug des paniers:
forcer les cookies : oui
URL de retour en cas de succès
http://www.monsite.com/catalog/checkout_process.php et non checkout_success.php
pour le moment ca marche avec tout les navigateurs. (paiment validé, panier vidé ....)
par contre, dans leur tuto il indique pourtant : forcer les cookies sur false !
Que veux-tu dire par "le bug des paniers"?
Est-ce que tu fais référence au bug dont il est question dans le premier post?
Merci.
Citation (oneill @ 21 Nov 2010, 03:35)
Je crois plutôt que ce système n'aime pas trop le traffic Dès qu'il y a plusieurs personnes parties payer en même temps, ca se mélange les pinceaux.
Je ne t'avais pas lu, mais je confirme, ça relève de l'erreur d'analyse.
C'est un développement "MONOPOSTE".
mickael34
10 Sep 2012, 13:41
Citation (nito @ 9 Sep 2012, 13:39)
Je viens de faire la migration, alors en fait, c'est le même bazar qu'avant.
La commande n'est pas créée avant le paiement, donc en cas de problème on a un règlement d'un coté et pas de commande à mettre en face.
Dans le module, il y a même un truc que j'adore, très drôle :
il y a une fonction getIdOrder() qui va définir le numéro de commande qui sera envoyé à SystemPay.
Sauf que cette fonction compte le nombre d'enregistrement, et y ajoute 1.
1) - Si deux clients se présentent en même temps, si le deuxième valide sa commande avant que le premier ne soit revenu sur votre boutique (via checkout_process), les deux clients ont réalisé un paiement pour le même numéro de commande.
2) - Si un client ne fait pas le retour boutique pour quelque raison que ce soit, vous avez un paiement pour 0 commande.
Cas numéro 1, SystemPay ne connaît pas le numéro de commande de la deuxième commande, si l'URL Serveur doit faire une validation, elle tape à coté...
Cas numéro 2, c'est la même histoire qu'avec spplus.
J'ai modifié mon ancien module spplus inspiré du PaypalIPN et ça devrait régler les cas 1 et 2.
@+
Bonjour Nito,
Concernant le "Cas numéro 1" et le problème du même numéro de commande.
Pourrais-tu donner ta solution si elle marche car de notre côté même souci :
Si 2 clients en même temps sur la page de paiement --> même numéro de commande du côté de systePay --> pas de remontée de commande dans l'admin oscommerce pour la 2e commande malgré un paiement ok.
Merci
Citation (mickael34 @ 10 Sep 2012, 13:41)
Pourrais-tu donner ta solution si elle marche car de notre côté même souci...
Ben en fait dans la fonction vads->confirmation je fabrique la commande avec un status "Préparation" au lieu de "Attente" et j'enregistre $order_id en session.
Dans la fonction vads->process_button :
au lieu de $vads_api->set('order_id', $this->getIdOrder()); (fonction toute pourrite)
je fais : $vads_api->set('order_id', $_SESSION['order_id'])
C'est donc la bonne id qui part chez SystemPay. Il y a d'autres solutions comme supprimer l'auto increment et créer un système de numérotation façon dev base de données multi-poste.
Citation (Toulousain @ 6 Jan 2011, 15:15)
Concernant le problème d'enregistrement de commande il faut s'assurer que vous avez bien renseigner dans l'outil de gestion de caisse l'url serveur. C'est l'url qui sera appelé dès que le paiement sera terminé en mode silencieux c'est à dire transparent pour l'internautes.
C'est gentils, mais le problème n'est pas là. Le web c'est "multiposte" il arrive même parfois que plusieurs "clients" fassent la même action simultanément.
Johnny124
21 Sep 2012, 09:31
.
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez
cliquer ici.