Jump to content

iorek

Members
  • Posts

    727
  • Joined

  • Last visited

Everything posted by iorek

  1. pour garantir le paiement, il faut une authentification 3D-secure avec transfert de garantie. Pourquoi transfert de garantie? parce qu'un paiement avec une carte non enrôlée dans certains cas (la plupart du temps cartes commerciales hors Europe), même si votre transaction s'est déroulée dans un contexte 3DS, vous n'avez pas de garantie de paiement. Vous êtes donc celui qui prenez le risque en cas de contestation. Dans le cas présent Payplug ne garantit rien car il n'est qu'un tuyau vers un établissement de paiement qui lui même répercute les règles de garantie de paiement de BNPP. Et si votre paiement s'est exécuté sans 3DS et comme vous n'avez pas annulé ou remboursé ce paiement douteux, votre compte LEMON WAY (et pas Payplug) vous répercute les frais de rejets. Votre "banque" c'est Lemon Way. pas Payplug.
  2. ce qu'il faut comprendre c'est que systempay attend 35 secondes (et votre acheteur aussi attend le résultat du paiement) au bout de 35 secondes, temps très long pour l'acheteur, systempay dit: j'en ai marre d'attendre. j'arrête d'attendre et j'informe le marchand que son script est très lent. mais cela n'arrête pas le script sur ps. script qui ira au bout ou pas. pour trouver qui est lent? les logs des modules tiers.
  3. le client ne reçoit jamais de systempay un e-mail disant qu'un nouvel essai sera fait dans 5 mn. vous ne connaissez pas systempay pour écrire cela.
  4. la documentation est faite pour un enfant de 10 ans qui sait lire. j'ai du mal à comprendre comment on peut ecrire que c'est compliqué. et en plus le support systempay a encore la gentilesse de faire les installations gratuitement pour ceux qui sont perdus.
  5. ps vous a installé une version qui date de juin 2014 développée par systempay pour ps1.4. dommage.
  6. ce message veut juste dire que l'exécution du script qui transforme le panier en commande dure plus de 35 secondes. vous avez donc un module tiers qui prend trop de temps et ralentit tout. il faut trouver lequel mais ce n'est pas systempay. il n'a que peu de travail à faire avant d'enchaîner sur les autres modules.
  7. la doc du module détaille l'ipn en large et en travers car cette erreur de paramétrage est la plus fréquente. et il est demandé de valider l'ipn sans retourner à la boutique en fermant son navigateur à la fin du paiement il faut tjs tester avant de mettre en place la redirection automatique.
  8. La Corse n'est pas un pays. du moins pas encore. Donc Systempay attend le code pays de l'internaute, de son adresse de livraison Et ce code sert aux contrôles de risques et à d'autres choses encore. C'est la raison pour laquelle il est basé sur une table iso internationale. Donc Systempay a besoin de recevoir FR pour la Corse. Si PS impose un code pays distinct pour une zone qui n'est pas un pays, peut être que le contournement est la seule solution. P.S: aucun message d'erreur généré par le module n'est superflu.
  9. La plateforme de paiement en ligne Payzen propose une solution de paiement sur internet et aussi depuis un Prestashop consultable sur tablette ou smartphone une connexion avec un mpos (SPM20 de SPire) qui permet vous permet de faire des paiement EMV. tous les paiements sont ensuite visibles dans un seul back-office marchand. Solution agréée par le Gie Carte bancaire. Le module ecommerce pour PS est gratuit (du coup pas dispo sur le store) et le module Ps pour le mpos sera disponible dans quelques jours.
  10. il faut toujours un contrat VAD. spplus est le nom de l'offre qui s'appuie sur un contrat VAD. on dit d'ailleurs plutôt un contrat VADS, S comme sécurisé
  11. paylib c'est du paiement en accédant à son Wallet en entrant e-mail ou téléphone et son mot de passe. mais ensuite c'est du paiement carte en choisissant la carte dans son Wallet. on ne peut pas dire que c'est du paiement par téléphone. quant à Paypal, jamais vu.
  12. donc votre conseiller à mon avis s'est trompé. il faut lui demander un contrat vad (spplus étant le nom de l'offre)
  13. si vous avez reçu une carte c'est que vous avez ouvert un contrat pour accepter les cartes sur un terminal de paiement. il n'y a pas de carte commerçant en vad.
  14. version de ps? version du module? au retour il y a normalement un contrôle entre le montant du panier à l'aller et au retour. le message d'erreur indique qu'ils sont différents. le panier aller est il en phase avec le panier retour?
  15. la solution la plus simple que je vois est basée sur un mpos (mobile payment) votre client consulte votre site Prestashop sur une tablette Android ou IOS (solution mpos uniquement dans cet environnement) Derrière le bouton Payer, Ps appelle un module développé par Payzen pour dialoguer avec le mpos (en réalité 1 ligne de code dans les faits derrière le bouton payer pour appeler la bonne application) le mpos est connecté en bluetooth à la tablette. le paiement accepté met à jour PS, crée la commande comme pour un paiement ecommerce. coût du mpos: moins de 150€. Solution EMV comme un TPE physique avec code confidentiel coût additionnel: une tablette Android ou IOS pour consulter votre site un module gratuit pour Prestashop pour gérer l'application derrière le bouton payer. un abonnement Payzen pour gérer les paiements depuis le mpos (payzen gérant aussi les paiements ecommerce et offrant un back-office unique pour suivre paiement physique et paiement ecommerce) Disponibilité: Février 2016 sur les stores IOS et Android. pas besoin de 15K€
  16. trop drole l'option serenity. le module est gratuit. la sérénité serait qu'ils se servent du dernier module gratuit. au lieu de vendre l'installation d'un module datant de juin 2014.
  17. çà comme vous dites c'est le module officiel, à jour et gratuit. ensuite ce que fait ps avec le cloud, c'est leur histoire.
  18. super. ps va vous installer un module vieux de 18 mois et inutile.
  19. avant d'acheter interroger PS LE module officiel et gratuit n'intègre pas la chaine de sécurité demandée par Ps cloud.
  20. le module gratuit sur Ps cloud sera bloqué. ps cloud impose les modules payants Ce qui en soi n'est pas anormal. il faut bien payer le service. je vous conseille d'acheter le vieux et de leur demander d'installer le nouveau. C'est le plus rationnel et raisonnable. Pourquoi tjs en vente? il faut demander à PS. C'est un vieux module développé par Systempay mais comme PS a blacklisté le module Payzen (clone de Systempay) car module pas assez cher, on ne collabore plus pour leur fournir les mises à jour. le module du store est en version 1.2.8 quand le module officiel est en version 1.7.0. C'est bien sûr Systempay qui a développé les 2. Un publié le 10/12, l'autre publié en Juin ou Juillet 2014.
  21. le cloud impose d'acheter les modules. celui du store est vieux, tres vieux même, mais il doit encore fonctionner. l'officiel développé par systempay est gratuit et à jour, mais on ne joue plus à le mettre à jour sur le store. vous pouvez tjs demander à ps de vous installer l'officiel. celui du store date d'au moins 18 mois. il n'y a pas de carte à fournir au moment de l'installation. vous confondez avec un contrat monetique pour tpe physique.
  22. une erreur 500 est un bug applicatif. le module de paiement est rarement en cause. il est un point d'entrée pour transformer le panier en commande. ensuite ps appelle en sequence des modules de facturation, de transport, de stock, de mail, etc. autant de modules qui peuvent si bugges ou mal paramétrer générer un html 500. analysez vous même les logs ps et apache pour trouver le module en erreur. rarement vu ovh faire le bon diag sur ce sujet. l'erreur effectivement ne vient pas d'eux mais de votre ps. le paiment est tjs accusé mais quasiment jamais responsable.
  23. Bonjour, Il est certain que comprendre PCI-DSS n’est pas une mince affaire. En premier lieu, il ne faut pas non plus en faire une montagne car il n’existe pas UNE certification PCI-DSS mais différents niveaux à respecter. Selon le niveau, la procédure peut être triviale ou extrêmement complexe. Pour commencer, dois-je me conformer à PCI-DSS ? Allons voir ce document en Français : Page 5 : La norme PCI DSS s’applique à toutes les entités impliquées dans le traitement des cartes de paiement, notamment les commerçants, les entreprises de traitement, acquéreurs, émetteurs et prestataires de services, ainsi qu’à toutes les autres entités qui stockent, traitent ou transmettent des données du titulaire (CHD) et/ou des données d’identification sensibles (SAD). Les 12 clauses de la norme PCI DSS sont détaillées ci-dessous. Mon interprétation est donc, que ce ne sont pas uniquement les données sensibles (numéro de carte) qui semblent concernées mais les données du porteur également (email pour le ticket par exemple). Il est vrai que ce pourrait être sujet à interprétation, c’est probablement pour cela que dans cette version ils identifient explicitement les commerçants comme concernés. J’ai donc le sentiment qu’il n’y a plus réellement d’interprétation possible avec cette formule qui il est vrai diffère de celles auparavant véhiculées. OK, je dois donc me conformer à PCI-DSS, mais comment faire en sorte que ce ne soit pas un sacerdoce ? Avec PCI-DSS 3, c’est réellement plus clair. Le résumé est ici et pour faire vite, je dois me conformer à : SAQ A : Le site marchand est complètement géré par un prestataire PCI-compliant, OU Le site marchand intègre un paiement via redirection ou via iFrame vers un service de paiement. SAQ A-EP : Le site marchand intègre une API depuis le navigateur client à destination d’un service de paiement sans passer par les serveurs du marchand, OU Le site marchand intègre un paiement via redirection ou via iFrame vers un service de paiement MAIS certains éléments de ces pages ont pour origine le site marchand (CSS, JS…). SAQ D-Merchant : Quand le marchand ne satisfait ni SAQ A ou SAQ A-EP, OU Le marchand enregistre des données de carte, OU La page de paiement est gérée par le marchand. Ensuite, pour voir ce qu’il faut faire pour satisfaire ces exigences, rendez-vous ici mais notez que le premier niveau SAQ A reste relativement simple à mettre en œuvre : https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_SAQ_A_rev1-1.pdf. Mon interprétation est donc, j'utilise Prestashop avec un module réalisant une intégration d'un fournisseur de paiement en respectant SAQ A, je dois juste remplir ce formulaire.
  24. la conversion du panier en commande si fait soit via le retour boutique, soit via l'url de notification (IPN) Si vous êtes en retour automatique à la boutique et que vous n'avez pas codé l'ipn vous pouvez avoir ce problème. Car la mise à jour doit se faire via l'IPN. Merci de contacter le support Payzen en donnant votre numéro de boutique et les numéros de transaction concernées. Personne ne pourra vous aider sur ce forum avec aussi peu d'éléments.
×
×
  • Create New...

Important Information

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