Jump to content

iorek

Members
  • Posts

    727
  • Joined

  • Last visited

Everything posted by iorek

  1. Vous avez la dernière version du module de paiement Systempay. Prestashop a apparemment mis en place un système qui vous invite à acheter la version du store, quand vous avez un module gratuit. C'est la même version que la gratuite à destination des utilisateurs de Prestashop Cloud et Prestabox qui doivent acheter leur module. Le numéro de version est différent car PS veut des numéros de versions de type n.n.n sans lettre. Systempay / Payzen ont mis sur le store une version 1.2.8 identique à la version 1.2f pour les clients soucieux d'avoir une installation accompagnée par PS ou clients des solutions Saas. P.s: On passe notre temps depuis 10 jours à répondre à cette question.
  2. Le module pour payzen est multi boutique de base il n' y a pas besoin de souscrire autant de boutiques payzen que de boutiques Prestashop . Le module Payzen gère très bien les multi-boutiques de PS avec une seule boutique au sens Payzen le commercial Payzen qui a raconté cela va se faire fouetter pour avoir raconté une telle bêtise
  3. lorsque vous rejouez l'url serveur depuis le back-office Systempay dit que cela a réussi parce que Ps ne renvoie aucune erreur HTML. Par contre le message lu sur le socket n'a rien de bon: Ce message n'est pas normal du tout: 38794= Statut de commande inconnu Donc effectivement, analysez les logs du serveur APACHE (et pas de Systempay) pour savoir quel module complémentaire cause l'erreur 500.
  4. systempay a sorti une version 5 de ses web services. la doc si elle n'est encore en ligne devrait l'être sous peu. de préférence essayez d'utiliser la version 5 des ws.
  5. tel que vous le décrivez, vous n'êtes pas forcément dans un motif de fraude. le client a déclaré à sa banque sa carte perdue et non volée. il n'a pas forcément réalisé que son numéro de carte était attachée à des échéances de paiement en n fois. appelez le et s'il est de bonne foi il vous donnera son nouveau numéro de carte. vous pourrez alors faire un paiement manuel. pour la fraude 3ds, les fraudeurs peuvent utiliser une méthode très simple (mais les banques sont moins naïves depuis). vous vous faites passer pour le titulaire du compte, vous appelez votre banquier et vous lui dites que avez changé de numéro de téléphone. il met à jour sa base avec le numéro du fraudeur qui reçoit les SMS. c'est simple. depuis les banquiers sont plus attentifs et ne changent plus sans vérifier le numéro de téléphone.
  6. Suffit d'aller sur le site de systempay pour vérifier que oui. Systempay et payzen ont été les premiers modules à être disponibles, supportés, documentés.
  7. allez-voir les logs APACHE vous trouvez la ligne en erreur et le module en question (transport, ebay, ...) générant l'erreur Le module de paiement est rarement en cause. Les modules tiers si mal paramétrés le sont le plus souvent.
  8. je ne pense pas que la cnil apprécierait. c'est un sujet très réglementé et surtout quasiment impossible à partager. et l'email n'est pas une solution. un fraudeur en change tous les jours, voire à chaque achat.
  9. En cette année 2014, le GIE Cartes bancaires impose aux plateformes de paiement sur Internet d'être agréées selon un cahier de certification défini par le GIE CB. Cet agrément porte essentiellement sur: les autorisation avec et sans 3D-secure les télécollectes bancaires les tickets générés à destination du porteur le contenu des pages de paiement (sérigraphie CB, logos VBV, Mastercard Secure code, ..) Près de 300 contrôles sont effectués et cette certification vous garantit que votre plateforme de paiement est conforme au protocole MPADS v5.2.3. Cette conformité vous garantit aussi que les demandes d'autorisation ne seront pas rejetées par l'émetteur pour données invalides (souvent cause du code retour autorisation 05) et que vos télécollectes sont conformes et transmettent correctement les données relatives à la garantie de paiement. pour en savoir plus : http://www.paycert.fr/Terminaux.html http://www.cartes-bancaires.com/spip.php?article128&lang=fr Cet agrément est obligatoire et ne peut être obtenu que si la plateforme est au préalable PCI-DSS. Une plateforme de paiement opérant en France doit obligatoirement : être PCI-DSS être Visa Merchant Agent Avoir un MPI 3DSecure agréé par Visa et Mastercard Etre agréé par le GIE CB Pensez-y en choisissant votre plateforme de paiement.
  10. Atos n'y est pour rien. Toutes les plateformes de paiement qui offre la facilité paiement en n fois sur CB fonctionne ainsi. La SG aurait du vous l'expliquer. Quand vous faites du paiement en n fois sans passer par un organisme de financement (Onet, Cetelem, Cofinoga), vous faites du paiement en n fois risque vendeur. C'est vous le préteur. Votre premier paiement s'il est 3DS avec une garantie de paiement vous est garanti. Les suivants dépendent de l'honnêteté de votre acheteur et de ses finances S'il n'a pas d'argent, s'il a résilié son compte, sa carte, etc... vous êtes alors dans le litige et devez gérer le recouvrement.
  11. Le module systempay / Payzen ne transforme pas le panier en commande si le paiement est refusé. C'est le fonctionnement par défaut de Ps de ne pas créer de commande refusée. Etrange de travailler ainsi.
  12. avant de mettre un patch sur une jambe de bois, il vaudrait mieux résoudre le problème de l'envoi de mail disant qu'une commande est faite alors que le paiement est refusé. Votre IPN ne devrait pas transformer le panier en commande. Le fonctionnement n'est pas normal de base.
  13. Une plateforme de paiement à ce jour pour couvrir les besoins les plus larges en FRANCE doit: proposer bien sûr l'acceptation CB, Visa, Mastercard, Maestro, Electron, e-cartebleue (c'est en général la base en mono devises ou multi-devise) proposer aussi le paiement paypal car cela permet d'avoir un seul back-office proposer les 3 wallets existants sur le marché français: Paylib, V.me, Masterpass proposer AMEX proposer DINERS proposer JCB (Japan Credit Bank) proposer l'acceptation de cartes cadeaux (Illicado, SVS, ..) avec complément par un autre moyen de paiement CB proposer le 3XCB cofinoga (solution de paiement en n fois associé à une carte cofinoga virtuelle) proposer l'acceptation des cartes Cofinoga avec les offres commerciales associées proposer l'acceptation des cartes Cetelem avec les offres commerciales associées proposer le paiement en n fois sur une carte CB via Cetelem (BNPP Personal Finance) proposer l"acceptation des chèques vacances dématérialisés (à partir de 2015) avec complément par CB proposer le paiement par SDD (avis de prélèvement) avec la gestion des mandats proposer le paiement UPOP (UnionPay Online payment) carte chinoise (bientôt dans Payzen) proposer ONEY banque accord On trouve tout ça dans Payzen avec une unique intégration.
  14. il y a plus simple: la plateforme de paiement gère le SDD comme elle gère le paiement carte. Payzen avec le module de paiement carte gère le paiement par avis de prélèvement avec la gestion de mandat, signature en ligne du mandat, mail de pré-notification, mail de notification, connexion au serveur EBICS de la banque pour envoyer les ordres. .
  15. Lyra network gère, développe, exploite, maintient, documente, ..) les 2 plateformes sous des marques différentes: Payzen et Systempay Mais c'est vrai aussi pour l'OSB à Tahiti, Innocard en Suisse, Payzen en Allemagne, Payzen au Brésil, et d'autres à venir.
  16. Le multi boutique est apparu avec la version 1.5 de ps. Il suffit de telecharger le bon module soit chez systempay, soit chez payzen. 100% identiques sauf l'url de la page de paiement.
  17. Systempay est la version de la plateforme de paiement vendue par les banques du groupe bpce. Payzen est la même plateforme technique et physique mais s' adresse aux marchands ayant un contrat hors bpce. (Bnpp, sg, lcl, cic, lbp, credit agricole, etc,...)
  18. Payzen propose le sdd dans ses abonnements. Sachez que le plus compliqué, c'est de mettre en place la connexion ebics avec votre banque. Connexion que votre banque facture.
  19. Il suffit d'annuler le paiement avant remise en banque. Apres remise en banque, il suffit de valider un remboursement avec votre banquier. Cela vous évitera les frais de rejets quand l'émetteur emettra un impayé. Dites vous bien que des qu'un paiement est autorisé et le paiement remis en banque, votre banque vous crédite le lendemain et gère la compensation avec l'émetteur. Plus tard car la fraude n'est avérée que quand le porteur la détecte, l'émetteur demande à l'acquéreur de le rembourser. L'acquéreur vous debite en suivant. Si le paiement est 3ds avec une authentification reussie, l'émetteur n'a pas le droit d'émettre un impayé. S' il le fait l'acquéreur lui fournit les logs 3ds, et l'emetteur se mange l'impayé. Par contre si la carte n'est pas enrôlée, et si elle ne fait pas partie des cas d'enrolements obligatoires, (cartes us business par exemple), alors prudence car vous n'etes jamais protégés. Impayé = perte.
  20. L'erreur apparait forcément sur le site mais pas à l'acheteur. Il faut comprendre qu'à la fin du paiement, toutes les plateformes doivent envoyer une notification au site marchand. Cette notification en anglais s'appelle IPN comme instant payment notification. Pour appeler cette notification, la plateforme de paiement appelle un script sur VOTRE serveur. Si ce script plante, la plateforme de paiement reçoit les erreurs d'exécution du script sur VOTRE serveur. Ce code est en partie celui de Payplug, mais aussi le code de tous les processus associés à la création d'une commande: création de la facture, transporteur, mise à jour du stock, discount, google analytics, envoi de mail à l'acheteur, etc.. Si une tâche est défaillante, on accuse le module de paiement, mais il n'est que celui qui reçoit tous les bugs des autres (et les siens s'il est buggé ) Donc effectivement la plateforme de paiement quand elle reçoit un code HTML 500 ou tout autre code HMTL (502, 503, ..) ou une impossibilité d'exécuter le script (url invalide) ou un time-out, elle est capable de vous dire: le script sur votre serveur ne s'est pas exécuté correctement. donc la commande n'est peut-être pas créée. Donc comme dit Oron, allez analyser les logs et trouvez le coupable. C'est basique quand on a les logs sous les yeux.
  21. 500 c'est un bug applicatif dans la majorite des cas. Analysez les logs et trouvez la ligne de code qui genere le fault 500. Vous aurez alors le module responsable. On accuse tjs le paiement car c'est le point d'entree pour transformer le panier en commande. Mais ce n'est qu'un tout petit bout du traitement.
  22. L'indice est donc simple: Lire la doc et faire un paiement sans retourner à la boutique.
  23. Pour chemisierfemme: Le module systempay est accompagné d'une belle documentation. La lire est un gage de reussite. Ovh n'y est pour rien. Par contre si vous suivez les indications du chapitre url serveur, vous réglerez votre probleme. Vous n'avez pas paramètrė l'url serveur. :-( Donc si votre acheteur ne revient pas à la boutique vous n'etes pas notifié. Merci de reprendre la documentation.
×
×
  • Create New...

Important Information

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