Jump to content

iorek

Members
  • Posts

    727
  • Joined

  • Last visited

Everything posted by iorek

  1. bonjour, le module fait directement du https en postant un formulaire. donc à partir du moment où le port 443 est ouvert, il n'y a rien à faire. et donc pas besoin de l'environnement mutualisé d'OVH puisqu'il n'y a pas de CGI. (donc pas de fees à payer à OVH pour accéder au CGI) et comme l'url serveur lors du retour en background appelle votre url et votre port, OVH ne bloque rien non plus. si tant est que votre port non limité à 80 ou 443 est ouvert.
  2. Remarque sur systempay: ce n'est pas l'url retour qui créé la commande, ni les paramètres de configuration du module. la doc du module explique qu'il faut coder l'URL SERVER dans le back-office marchand pour que le numéro de commande soit créé.. avez-vous codé correctement l'URL server dans votre back-office? le problème que vous décrivez n'existe pas avec Systempay, sauf si on ne suit pas documentation et si on ne code pas correctement son URL server. .
  3. petite remarque: avec systempay, (o payzen), lorsqu'on revient à la boutique, la langue qu'a utilisé l'internaute pour payer son panier est renvoyé à prestashop. on peut partir en français et avoir un payeur qui paye en allemand. cela permet si demandé de repositionner le payeur dans la langue de son paiement. on peut aussi très facilement restreindre ou élargir les langues proposées sur la page de paiement. par défaut il y a en 6, mais on peut aussi dire: je ne veux que le français et l'anglais. et tout cela avec un module gratuit. https://systempay.cyberpluspaiement.com/html/contributions.html
  4. spplus va s'appuyer prochainement sur systempay. le module de paiement sera gratuit.
  5. personne n'a daigné répondre? le support systempay a perdu presque une journée à vous aider à découvrir que plus de la moitié de vos modules étaient mal chargés. de temps en temps, c'est bien de faire son auto-critique. charger c'est bien. réfléchir c'est mieux.
  6. Précision: paiement en n fois qui serait une option du contrat bancaire? je suis désolé mais c'est faux. le paiement en n fois bancaire est juste une possibilité de créer à l'avance les n paiements du n fois. seul le premier est autorisé. les autres le seront quand ils seront présentés à la banque. et si cela foire, et bien à vous de courir après les sous. la banque n'a rien à voir dans cette option. la seule chose c'est qu'elle ne garantit rien sauf le premier qui est autorisé ou pré-autorisé à la création. et si votre paiement est 3D-secure, seul le premier paiement est 3DS, les autres ne le sont pas car ils correspondent à des transactions distinctes qui seront autorisés plus tard (sauf si l'écart entre la première et la dernière est inférieur à 6 jours, mais il y a peu d'intérêt à ce stade)
  7. ce n'est pas le module qui résoudra ce problème. la seule réelle façon d'avoir une traçabilité, c'est de faire un retour automatique à la boutique. donc on va dire qu'il faut que le module puisse revenir à la boutique automatiquement.
  8. pas bizarre! ce message est envoyé quand il est impossible d'appeler votre url serveur. ce qui n'est pas normal du tout. soit elle est bloquée par un htacces, soit le fichier n'existe pas car mal copié. dans tous les cas votre installation ou votre paramétrage est incorrect.
  9. appelez le support systempay directement cela ira plus vite que de vous poser des questions via ce forum. Dans tous les cas, vous avez touché à quelque chose bien que vous dites le contraire. l'informatique c'est binaire. rien ne se passe par l'opération du saint esprit. il y a tjs une explication rationnelle à un changement de comportement. et vous êtes le mieux placé pour savoir ce qui a été changé dans votre configuration.
  10. bonjour voici à quoi ressemble votre url serveur http://grenadineetsespetits.com/modules/vads/validation.php jusqu'au 2/08 (car entre le 2 et le 5, il n'y a pas de paiement), le comportement de l'url serveur me semble normal. au delà du 2/08, son comportement n'est plus le bon. glisser la souris sur la colonne info dans l'onglet "historique des évènements d'une transaction". vous verrez que son comportement change au delà du 2/08. donc demandez-vous ce que vous avez fait depuis le 2/08? ajout d'un nouveau module qui a altéré validation.php? ou la procédure appelée par validation.php? dans tous les cas, vous avez fait quelque chose. ce n'est pas un problème htacces, ce n'est pas un problème de non appel de l'url serveur, ce n'est pas un problème de paramétrage de systempay. vous avez modifié autre chose qui a eu un effet de bord sur le fonctionnement de l'url serveur à vous de trouver quoi.
  11. le module chèque ne fait de pas de redirection vers un autre site. donc on ne peut pas comparer. donc je repose la question: le bo est mis à jour par l'url serveur, donc c'est par là qu'il faut commencer. qu'avez vous changer depuis le 5 aout? que se passe-t-il lorsque vous essayez d'appeler l'url serveur depuis un navigateur? que se passe-t-il lorsque vous rejouez l'url depuis le back-office de systempay? dans le back-office de systempay, sur le détail d'une transaction dans l'onglet évènement que voyez-vous? répondez à ces questions et vous serez moins vague. dire que j'ai rien changé et que depuis le 5 aout cela ne fonctionne plus, n'aide pas bcp. un changement aussi brutal à une date précise est forcément lié à une modification de comportement.
  12. et on peut savoir si vous avez renseigné votre url serveur dans le back-office de systempay? ou encore si vous avez vérifié que vous n'aviez pas un htacces (erreur de débutant râleur) sur l'url serveur. vous êtes très vague pour qu'on puisse vous aider efficacement. lisez la doc! elle contient tout ce qui est utile, même pour les impatients. Le module systempay n'est pas incomplet et il est surtout opérationnel et utile.
  13. pour la logique, c'est prestashop qui doit répondre. c'est logique dans la mesure où si le paiement est refusé, il n'y a pas création de commande. mais on pourrait aussi avoir une commande créée avec un statut refusée. Magento fonctionne ainsi. pour la comptable, je pense qu'il y a moyen d'afficher le numéro de panier à côté du numéro de commande. à vous de personnaliser la vue dans prestashop. ce point est dans la doc car bcp se sont étonnés de ce point. mais les questions sont devenus rares, car heureusement la plupart lise la documentation du module de paiement systempay. :-)
  14. bonjour la réponse est très simple et il y a un paragraphe rien que pour cela dans la doc du module: mais apparemment vous ne l'avez pas lu. :-( Le numéro de commande est généré par Prestashop à la fin du paiement. la seule chose qui existe lorsqu'on appelle la page de paiement c'est le numéro de panier. donc il est impossible à Systempay de connaitre le numéro de commande. il n'existe pas avant de payer.
  15. bonjour voici par exemple ce qu'il srait possible avec Systempay: au fur et à mesure que vous enregistrez des clients sur un article vous demandez à systempay d'enregistrer leurs données carte. Cela s'appelle le paiement par identifiant. (attention il n'y a pas de plug-in par defaut pour prestashop pour cela, même si certains l'ont fait mais seuls). en retour le système vous renvoie un identifiant carte que vous devez associer à votre acheteur dans le groupe créé pour l'article. à la fin de la promotion, vous calculez le montant réel et envoyez à Systempay par ftp un fichier qui contient l'identifiant carte et le montant. vos clients sont débités. c'est aussi simple que cela. mais c'est à vous de soumettre la création des paiements via ce fichier.
  16. Même avec l'accord du client c'est totalement interdit de stocker des coordonnées bancaires sans être PCI-DSS. quel risque? très forte amende de Visa et Mastercard, rupture des contrats VAD. la fraude et surtout les vols de fichiers ont rendu très complexes les procédures de stockage.
  17. bonjour, d'abord un psp ne prend pas de commissions. il prend en général un abonnement mensuel incluant des paiements et ensuite il facture les paiements au delà du dépassement. la banque prend des commissions, un abonnement et un fee par paiement. ogone et paybox sont effectivement chers, en général au delà des forfaits bancaires qu'on trouve à 15 € TTC. à côté d'ogone, il y a Payzen, solution très moderne, plus connu sous le nom de systempay dans le groupe BPCE. mais il y a aussi Atos si vous voulez être indépendants de la banque (mais ils ne signent en direct que les gros) Payline de Monext-Arlea, mais là encore plutôt sur les gros. donc vous avez le choix entre Paybox, désormais sous bannière suédoise. Ogone sous bannière belge toujours sans gouvernement depuis 1 an et Payzen, bien français, bien moderne et surtout Toulousain. Allez le Stade, champion de France 2010-2011!
  18. sauf qu'il pourrait vendre ses prestations sans faire une copie du module. Le lien vers le site officiel serait suffisant. il n'est jamais sûr d'avoir la dernière version. et même si la version en ligne est bien faite, elle peut évoluer régulièrement.
  19. Non seulement nous sommes mandatés pour développer et supporter les modules, mais nous sommes aussi les développeurs et exploitants de la platefome Systempay elle-même. En partenariat avec le groupe BPCE. C'est plus simple. on a une vision sur les 2 bouts. donc on fournit un module dont nous connaissons les tenants et les aboutissants. nous avons récemment mis en ligne la version pour presta 1.4. toujours gratuitement en paiement single. donc effectivement nous avons une certaine légitimité pour proposer ce module et nous sommes donc tout aussi légitime aussi pour râler contre ceux qui s'approprient notre travail sans mettre en avant la paternité des modules. comme je l'ai dit plus haut, nous n'interdisons pas les services aux marchands. mais nous aimerions que des copies pirates ne se retrouvent pas aux 4 coins du net. J'avais déjà écrit au propriétaire du site domainblue, mais il n'a même pas eu le courage de me répondre. pas très clean! et ce n'est pas en postant des informations erronées sur 3DS et l'import des logos qu'il se rendra légitime. si au moins son site proposait systempay pour payer les prestations...il saurait un peu de quoi il parle. :-) mais comme il a son entreprise domicilié en Angleterre, il n'a pas de contrat VAD France. d'une façon générale nous avons très peu de support sur les 22 modules différents que nous proposons pour Systempay. Seul epages nous refuse encore l'intégration de notre plateforme de paiement. Elle est pourtant très moderne avec un back-ofifce commerçant haut de gamme. Nous avons fait l'effort (et parfois c'est un vrai effort pour Magento et ses 10 000 fichies par exemple) de comprendre les CMS, de développer les plug-ins, de les documenter, parfois de faire des vidéos de e-learnng. pour ne pas avoir d'appels au support. :-) et avoir des clients qui installent le module en quelques minutes. sans hésiter. sans souci. et nous avons plutôt bien réussi à ce jour car comme vous, la plupart des intégrateurs n'ont pas appelé. et une interface en https sans CGI antique (suivez mon regard..) c'est tellement moderne et facile à déployer sur tous les os. Nous ne ferons pas la chasse aux sorcières, mais nous ne voulons pas des modules aux 4 vents. Surtout quand on nous les "vole" sans autorisation. Qui plus est quand on a une domiciliation en anglererre avec un téléphone français. Le copyright cela existe encore!
  20. c'est effectivement le site de référence où nous mettons en ligne tous les modules pour systempay c'est aussi le site où les marchands peuvent s'incirire à une news letter pour être avisé en cas de mise à jour. il y a aussi store.payzen.eu où nous mettons les modules payzen qui est la version équivalente à systempay pour les clients des banques non Banque populaire caisse d'epargne. Payzen est une marque de Lyra Network. chacun à la droit de vendre ses prestations, mais nous faisons des efforts pour supporter gratuitement et mettre à jour les modules. si on en trouve partout (à commencer par celui de PIWI vendu sur Prestastore qui est loin d'être fonctionnel) le support gratuit un jour ne le sera plus. est-ce celà l'open source? un bordel désorganisé? pas notre conception.
  21. et pour donner des leçons vous pourriez au moins utiliser systempay sur votre site quand vos clients commandent. il n'y a même pas un moyen de paiement bancaire à part paypal. testez au moins les produits que vous mettez en ligne sans notre autorisation. :-)
  22. ah j'ai trouvé le petit malin qui recopie les modules de systempay dans son propre site (bluedomain) sans demander l'autorisation. et qui ne répond pas quand on lui dit qu'il aurait pu au moins demander l'autorisation et surtout rappeler l'origine du module sur son site. quand il y a un créateur qui offre des modules gratuits, c'est bien de ne pas masquer son copyright!! dans le back-office de systempay, on peut télécharger le logo de la boutique et pour les utilisateurs plus avancées (si on donne le droit), on peut intervenir sur les CSS et personnaliser les pages de paiement. mais on n'importe pas de logo 3DS et encore moins des softwares. c'est pas bien de "voler" les modules http://www.bluedomain.biz/fr/recherche?orderby=position&orderway=desc&search_query=systempay et de ne pas savoir comment cela fonctionne. :-( quand on veut vendre de l'assistance à la mise en oeuvre. surtout quand la doc vient avec une vidéo de e-learning pour ceux qui ne sauraient pas faire. http://media.lyra-network.com/natixis/Prestashop.html donc effectivement le site peut afficher qu'il est 3D-secure mais c'est la page de paiement de systempay qui décide seule si le logo est présent ou pas. En fonction de l'enrôlement du commerçant. merci au moins de rappeler l'origine du module sur votre site et de veiller à ce que vous livrez au moins la dernière version quand vous la "piquez" sur notre site de référence. https://systempay.cyberpluspaiement.com/html/contributions.html Chacun est libre de vendre ses propres prestations, mais pas de s'approprier des modules qui ne lui apparttiennent pas. sans en rappeler la source au moins sur la page de description (et pas au bout du processus) . chacun fait son biz comme il peut, mais pas en ignorant les droits de création. et nous n'avons rien contre des prestations externes d'installation. Encore faut-il savoir de quoi on parle. et ce post montre que vous avez des lacunes.
  23. je ne savais pas qu'il y avait disposition des logos à télécharger..surement joli mais pas dans l'interface bancaire. :-) les images montent automatiquement sur la page de paiement lors de la redirection quand le commerce est enrôlé auprès de visa et de mastercard. rien d'autre à faire.
  24. la raison est simple: il y a un délai d'environ une semaine entre la demande d'enrôlement de votre commerce et l'enrôlement effectif. ou alors il y a eu un problème et votre enrôlement n'est pas finalisé. mais effectivement il n'y a rien dans le module. c'est lorsque le client rentre sa carte que Systempay vérifie si votre boutique est enrôlée et dans ce cas enchaine sur le processus 3D-Secure.
  25. bonjour le back-office de Systempay vous donne une totale transparence sur les échecs 3DS. donc il est facile de mesure le taux en analysant les causes des échecs. ensuite, même si 3DS est encore mal perçu les taux d'échec diminuent chaque jour. je peux citer une grande enseigne où vous pouvez faire vos courses sur internet, 100% 3DS avec un taux largement inféirieur à 5% Certes, ce sont des habitués de l'intenet puisqu'ils y font leur courses alimentaires, mais c'est une tendance. ça baisse. ensuite, rien n'interdit de rappeler les quelques clients qui échouent. La video de priceminister ne date pas d'aujourd'hui. et ce sont ausis des sociétés qui ont développé leur propre module de contrôle de fraude. donc moins sensible à l'utilisation de 3DS. vous n'avez pas les mêmes outils qu'eux, donc 3DS peut s'avérer utile face à un public de moins en moins dérouté par un ACS. Sur Systempay, lui-même je confirme que c'est une solution moderne avec un back-office intuitif. Le module single est gratuit pour prestashop quelle que soit la version et le module pour la 1.4 a été fourni gratuitement et rapidement. (le module payant mis en ligne par prestashop n'est pas officiel) il s'installe en 3 minutes et par défaut demande à saisir 2/3 champs pour être opérationnel: n° de boutique et valeur du cerificat test et prod si vous avez demander la génération de la clef de production après signature de votre PV de recette. il faut juste penser à coder correctement l'url serveur (ou silencieuse) dans le back-office pour mettre à jour vos commandes lorsque le paiement est terminé (même sans retour boutique). pas de prise de tête avec un CGI type Atos Paybox. pas de prise de tête avec OVH qui impose un serveur CGI payant pour ATOS/Paybox. pas de prise de tête avec l'OS puisque tous deviennent supportés. on poste un formulaire en https entre le site marchand et la platefome de paiement. pas de prise de tête avec les hébergeurs qui ne veulent plus de CGI. pas de prise avec la maintenance du module: elle est aussi gratuite que le module. (on veut juste que si vous bidoullez prestashop et cassez le module que vous gérez vos bugs. :-)) sur les prix, je n'ai pas d'infos. ensuite sur les compétences, tous les banquiers ne peuvent pas être experts du produit. il faut donc les excuser aussi. ils sont avant tout des banquiiers, et pas tout le temps des spécialistes e-commerce.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More