Jump to content

iorek

Members
  • Posts

    727
  • Joined

  • Last visited

Everything posted by iorek

  1. Suite à l’envoi du dossier préalable pour la VAD, le technicien me demande si votre site marchand est conforme à la norme PCI DSS (norme des réseaux VISA et MASTERCARD garantissant la sécurisation du stockage des données sensibles, telles que n° cartes porteurs. Un certificat de conformité, validé par une société de sécurité certifiée PCI PO, devra nous être présenté cette demande n'a du sens que si le commerçant fait l'acquisition de la CB via son site. s'il délègue à la plate-forme de paiement ce travail, cette demande est totalement injustifiée. dans le cas où effectivement il fait l'acquisition sur son site et uniquement s'il devait stocker des données cartes il devrait effectivement être PCI-DSS et avoir une solution PA-DSS avec cryptage des cartes. le problème c'est que cela coûte une fortune et qu'il a peu d'acteurs qui font passer les audits. en fait en France il n'y a que Verizon (très cher!!!) ou alors des "étrangers" qui interviennent en France. (British Telecom, SRC, Vertigo, Trustwave, etc...) http://www2.visaeurope.com/documents/ais/Qualified_Forensic_Investigators_contact_list.pdf non seulement c'est cher mais en plus il faut payer un audit annuel et des scans d'intrusion suivant la taille du site (souvent le trimeste et il faut là encore payer) sont le plus souvent concernés par cette problèmatique des entreprises comme Amadeus, etc... le commerce moyen n'a absolument pas les moyens de payer une telle usine à gaz imposée par Visa et mastercard. A noter que pour être auditeur, il faut aussi payer visa et mastercard pour les agréments. ils sont très forts ces ricains. donc si le commerçant ne fait pas l'acquisition de la CB sur son site, la demande du Credit mutuel est injustifiée. à noter que tous les psp ne sont pas PCI-DSS mais opèrent tout de même! J'espère que cette réponse aide. pour en savoir plus https://www.pcisecuritystandards.org/
  2. pour rappel le module est gratuit. ce que fait payer la banque ce n'est pas le module, mais les frais de dossier. accessible gratuitement ici https://systempay.cyberpluspaiement.com/html/contributions.html
  3. l'ancien c'est atos que natixis ne vend plus. maintenant si tu veux payer 400 euros pour un vieux caramel, il est sur prestastore. mais est-ce utile de jeter l'argent pas les fenetres?
  4. sorry. je ne suis pas le banquier. je sais par contre que la BPLC ne fait rien payer sauf des commissions sur les paiements. les autres banques populaires ont des frais d'ouverture et d'abo mensuels. surement négociable suivant la "qualité" du client, mais je n'ai pas de conseil à donner. :-) bonne négo et bonne installation, mais cela ne devrait pas poser de problème.
  5. voici ce qu'en pense un des derniers internautes à l'avoir installé: mail reçu le 11 Mars Bonjour Ce module pour Prestashop est simplement parfait et la documentation très claires. Installation + configuration en 3 min et tout est opérationnel. Très bon module. Merci pour ce travail Noel
  6. il a atos et il a d'autres bien meilleurs... paypal, il ne faut pas avoir besoin d'eux car tout est organisé pour ne jamais pouvoir les appeler. message pour sna: la contribution vient avec une bonne doc. suffit de la lire et tout devient simple. https://systempay.cyberpluspaiement.com/html/contributions.html merci de telecharger cette version. elle intègre toutes les remarques remontées depuis le début de l'année.
  7. et combien de % pour paypal par transaction? surement plus qu'une banque! car de toute façon paypal remet ses transactions à la bnp et doit payer des commissions à la BNP. il n'y a pas que les ricains dans la vie.
  8. certaines banques populaires renvoient leur client vers BPLC pour aider les aider quand ils démarrent et ont peu de budget. donc c'est un bon choix. et c'est la même solution pour toutes les bpop: systempay
  9. ouah... je ne suis plus beginner. apprentice! effectivement j'apprends tous les jours. avec tjs autant de plaisir qu'à l'école. mais je pense être un peu expert sur les paiements. :-)
  10. banque populaire de champagne: d'abord rien n'est gratuit. développer une plate-forme de paiement fiable, respectant les normes coûte cher. donc il ne faut pas s'attendre à que les services soient gratuits tout le temps. La BPLC base sa stratégie sur un service de paiement sur internet gratuit mais asoscié à des commissions un plus elevées que la moyenne. pas de coût de mise en service (et c'est ce qui coûte le plus cher: contrat, saisie de contrat, assistance technique parce que vous ne lisez pas les docs, :-), support,etc..) pas de coût d'abonnement ou de coût à la transaction. c'est une formule intéresssante pour ceux qui démarre car systempay est simple à déployer (pas de prise de tête avec un cgi) car on maîtrise les coûts et c'est bien moins cher que paypal. bcp moins cher que paypal! d'autres banques populaires peuvent proposer des commissions plus faibles mais auront des coûts de mise en service (moins cher qu'un paybox ou un ogone), et des coûts d'abonnement mensuels (20 à 30 euros suivant les cas). il faut faire le tri entre tout cela, accepter que le banquier gagne un peu d'argent pour développer sa plate-forme (systempay est une rupture technologique par rapport à la concurrence, donc cela coûte), choisir sa plate-forme technique et ensuite développper son CA en s'appuyant sur un banquier expérimenté dans les paiements. et surtout accepter les ruptures technologiques. ce n'est pas parce qu'on a installé du CGI de paiement pendant 10 ans que c'est l'avenir. c'est totalement dépassé, lourd, limité en os, une faille de sécurité et une contrainte forte d'évolution. à l'étranger, il n'y a presque plus de CGI. En france on aime les dinosaures et les mammouths. ouvrez les yeux! juste un conseil.
  11. bonjour, d'abord ce n'est pas avec systempay. c'est plus général. quand on paye on saisit quoi? la cb la date le C VV à ce stade qu'est qui peut être contrôlé? la validité de la date (supérieure à date du jour et inféreure à 3 ans) le c vv non, juste 3 chiffres. la carte? à ce stade avec le bin on récupère 2 choses: la longueur max et min de la carte (toutes les cartes ne font pas 16) et l'algo de contrôle (clef de luhn s'il en existe une) donc le seul contrôle qui est fait immédiatement c'est cela. ensuite? soit le commerçant est enrôlé (c'est normalement obligatoire même si le commerçant peut demander à désactiver l'option) soit il ne l'est pas. s'il ne l'est pas, on enchaine sur une demande d'autorisation (date valide, c vv valide, internaute a de l'argent, ...ou prise d'empreinte dans le cas d'un paiement différé). ce qui revient au même puisqu'on veut valider la CB si le commerçant est enrôlé, on va chez Visa ou mastercard et on fait une interrogation avec la CB pour connaître l'url serveur de l'aCS de la banque. Là encore 2 cas: la carte n'est pas enrôlée. on revient à la page de paiement et on continue les contrôles. (une carte avec un numéro bidon valide sera dans ce cas non enrolée mais ne passera pas à l'autorisation. la carte est enrôlée auprès de visa ou mastercard et cet organisme nous renvoie l'url de l'acs. avec cette url d'acs on impose au navigateur de l'internaute de changer de site. on quitte la page de paiement (voir l'url qui change) l'intenaute doit alors saisir son identifiant ou répondre à une question (je sais, c'est la jungle entre les banques, pas homogène). 3 cas: l'acs non dispo: on continue le paieemnt et les contrôles (cela peut arriver!) mauvaise reponse ou pas de réponse: paiement abandonné bonne réponse: on continue les contrôles et on fait donc un auto. pourquoi on fait l'auto après? parce que l'authentiifcation 3DS renvoie des champs (cryptogrammes), qui vont être utilisés dans la demande d'autorisation. s'il fallait contrôler la date avant, on devrait faire une auto à 1 euro (prise d'empreinte) sans crypto 3DS, lancer l'authentifcation 3DS, puis revenir à l'auto avec les crypto 3DS. aucune banque ne fait 2 autos. tout le monde suite la rèlge dcrite ci-dessus. on identife pas le porteur. on identife le bin. ensuite avec le bin on va vers l'ACS. dès que les infos sont saisies, à partir du moment où on fait du 3DS, on ne peut valider que la séquence de la carte, pas les autres champs. ils le sont uniquement par l'auto. clair?
  12. Avant de faire l'authentification 3D la seule chose qui peut-être réellement contrôlé c'est la validité du format de la carte. à partir de son bin (soit les 6 premiers caractères) le bin permet de trouver la longueur maxi et mini de la carte le bin permet de savoir si le réseau est un réseau 3DS ensuite il faut faire en 3DS l'authentification. avant l'auto.
  13. encore une fois, les données bancaires comme une date fausse ne peuvent être contrôlées qu'au moment de l'autorisation. hors l'authenfication 3D est faite avant l'autorisation. si l'authenfication échoue, on n'ira pas jusqu'à l'autorisation. on ne fait pas l'autorisation avant l'authenfication.
  14. bonjour, suite à tous les retours et les aides des e-marchands, nous avons amélioré la contribution systempay pour prestashop: Elle est tjs gratuite (contrairement à d'autres) et tjs aussi facile à installer. même si certains demandent 80 euros. :-) elle est disponible sur l’URL https://systempay.cyberpluspaiement.com/ la nouvelle contribiution pour systempay du module Prestashop corrige les points suivants : - Les paramètres sont envoyés en POST et non en GET - Le retour à la boutique se fait désormais sur la page de confirmation de commande ou refus de commande et non plus sur l’historique commande du client. - Les traductions sont désormais compatibles avec le système de traduction de prestashop. - Suppression d’erreur Warning sur la liste des commandes. - La documentation inclus désormais un chapitre consacrée à l’URL serveur. Merci de lire le chapitre sur l'URL serveur car vous êtes nombreux à ne pas (tjs) comprendre un peu de lecture ne nuit pas à la compréhension. et évite de tjs poser les mêmes questions. Donc bonne lecture. à charger uniquement si vous aviez un des problèmes ci-dessus. et merci de continuer à remonter les problèmes éventuels pour les fixer.
  15. encore une fois il ne faut cpas onfondre authentification 3DS et autorisation le client n'est pas trompé dans ses coordonnées bancaires. il a été rerouté vers l'ACS de la banque dans le cadre des contrôles 3DS. il quitte le site de paiement (suffit de regarder l'url qui s'affiche dans le navigateur), va sur le site de sa banque (son ACS) et là, l'acs llui pose une question ou lui demande son code d'accès internet, ou etc....toutes les banques font un truc différent !pas cool j'en conviens). s'il ne répond pas ou ne répond pas correctement,la transaction est refusée car non AUTHENTIFIE (pas non AUTORISEE) même si la CB était correcte. cela n'a rien à voir. il n'a pas l'occasion de ressasir, puisue la banque considère que ce n'est pas lui. il ne répond à la question de l'ACS. la transaction est abandonnée sur authentifcation refusée, pas autorisée refusée. elle n'est jamais faite dans ce cas. on ne va jamais jusqu'à contrôler son compte ses règles sont valables pour toutes les banques qui exploitent un ACS et enrôlent les cartes Visa et mastercard. Donc bien comprendre ce qu'est une authentification (3DS) et une autorisation l'une précéde l'autre si le commerçant est enrôlé. si le commerçant ne veut pas de 3DS parce que les internautes acheteurs ne pigent rien, il doit demander à sa banque de le rendre inactif, mais n'a plus sa garantie de paiement 3DS.
  16. reponse 4970 1000 0000 0007 “Problème technique lors de l’authentification porteur” il ne faut pas confondre authentification 3D et autorisation. ce cas simule un appel à l'ACS de la banque qui échoue. Dans ce cas d'échec d'authentification 3DS, on continue avec une demande d'autorisation qui est acceptée. on a donc un paiement autorisée mais non identifiée 3D. tout à fait normal et simule le cas d'un ACS non disponible. il est donc normal que la transaction soit réalisée avec succès et que le paiement soit validé. si un tel cas se produit en production, la seule incidence est sur la garantie de paiement lié à 3D. en cas de fraude, la garantie 3D ne joue pas. 4970 1000 0000 0006 “Problème technique lors du calcul de la garantie de paiement” idem. on continue en autorisation. elle est acceptée par l'acquéreur (encore une fois en mode test)
  17. eric bonjour le contrôle sur le contenu du champ numéro de téléphone a été allegé. Il n'y a plus de problèmes sur la présence ou non de parenthèse. Ce point est résolu côté serveur. rien à changer côté contribution. Pour les guillemets dans l'adresse, une contribution est en cours de mise à jour pour traiter ce point. pour l'histoire du trans_id, en cours d'étude.
  18. merci eric pour ces remarques. nous allons les étudier et les prendre en compte.
  19. bonjour je n'ai pas fait attention à ce lien. Je regarderai comment cela a été implémenté. il n'y a rien de confidentiel à priori puisque c'est la page résultat du paiement et que l'internaute qui a payé est devant. pour plus d'info (attention lien en https) https://systempay.cyberpluspaiement.com et les contributions gratuites à l'adresse: https://systempay.cyberpluspaiement.com/html/contributions.html d'autres toujours gratuites sont en cours de développement. (Thelia, Peel, Toweb CS cart, ...), même si nous sommes sur le forum prestashop. - Petit rappel car nous avons quelques incompréhensions: Le dialogue entre prestashop et le gateway de paiement est basé sur un formulaire https. ce formulaire contient un champ ctx_mode égal à TEST en mode test et une clef de scellement calculé partir d'un certificat. Quand la banque vous dit que votre PV de recette a été validé et que vous pouvez passer en production, la banque vous envoie un certifcat de production. A ce stade, il faut tout de même finaliser la mise en production. En revenant sur la configuration du module pour mettre à jour le certifcat de production que vous venez de recevoir et aussi le mode (qui passe de TEST à PRODUCTION). sinon vous faites du test en production. Et les paiements sont refusés, puisque c'est un mode TEST. SystemPay est la marque commercialisée par Natixis Banque Populaire. Mais le gateway de paiement utilisé par SystemPay est aussi commercialisé pour les autres banques par Lyra Network. Et la contribution reste gratuite.
  20. bonjour la contribution systempay est gratuitement mise à disposition par la banque. bizarrement depuis ce week-end, plus acessible sur le site prestashop qui renvoie vers prestastore. et bizarrement, seules les contributions payantes sont en ligne! en plus des CGI, des CGI et encore des CGI! Natixis l'envoie de toute façon à l'ouverture du contrat. mais pas cool presta!
  21. bonjour, systempay permet effectivement de gerer plusieurs boutiques sous le même compte back-office. je ne crois pas que d'autres produits permettent cela. un contrat unique permet dans systempay de gérer plusieurs boutiques. par contre je ne connais pas les conditions financières associées (un seul prix quelque soit le nombre de boutique?) Ce qui compte c'est le SIRET car les boutiques doivent être rattachées au même SIRET (surtout à cause de 3D secure) pour ce faire, la banque doit créer 2 boutiques (ou plus) dans son back-office, donc 2 identifiants, donc 2 clefs de scellement. donc un formulaire à poster par boutique mais une consolidation unique dans le back-office banque avec des recherches possibles par boutique ou une vision globale. Simple comme un bonjour.
  22. pas tout à fait: le back-office c'est l'application qui permet de suivre les paiements effectués par les internautes. accessoirement de faire des paiements manuels (ex: par telephone), de valider des transactions si on préfère les déclencher manuellement après expédition par exemple, de rembourser un internaute, de dupliquer un paiement si nécessaire, de suivre ses remises en banque. c'est en résumé un outil de gestion à posteriori. Entre le site marchand et un gateway de paiment il faut échanger des paramètres. Le gateway est en charge de capturer la carte bancaire dans un environnemnt sécuriisé et aussi pci-dss pour respecter es normes propriétaires de visa et mastercard. pour que le gateway de paiement puisse capturer le paiement de l'internaute, il faut faire une redirection vers ce site en échangeant des paramètres. (identifiant, montant, devise, numero de commande, email, url de retour, etc...) Si nous mettonss de coté les WEBservices, 2 technologies existent: une histoique basée sur un CGI, programme développé par le gateway qui doit s'executer sur votre site marchand (ou être mutualisé par l'hébergeur). Ce n'est pas en soi une mauvaise solution, mais c'est lourd à installer. il faut déjà que cela soit dispoible pour votre système d'exploitaiton, sinon il faut un serveur physique ou virtuel dédié pour son exécution, il faut des droits d'exécution, de l'espace disque, des ports dédiés firewall pour certains, avec le risque de faille de sécurité car c'est du code étranger dans votre environnement. tous les prestataires historiques (atos, cybermut, sp+, ogone, payline, ..) sont des vieiilles technos. l'autre techno est plus simple et s'appuie sur https. juste un formulaire à remplir et à poster avec comme contrôle à l'arrivée sur le gateway (et au retour sur le site) une clef dite clef de scellement basée sur un algo SHA-1. (code fourni dans les exemples dans la plupart des langages). Dans ce cas, pas d'exécutable à installer, pas de droits à ouvirir. cela utiliser le port 443. donc configuration de base ouverte chez l'hébergeur. pas de mise à jour du programme CGI à faire si le gateway de paiement décide de le mettre à jour. si le formulaire évolue, il suffit d'ajouter les champs dans le form pour bénéficier de nouvelles fonctionnalités. Pas de galère d'operating system. Seuls Ogone et SytemPay utilisent ces technologies. Toutes les autres sont restés coincés par leur choix antérieur avec le CGI. Dans le cas de prestashop, la contribution gratuite permet de construire le FORM et de le poster dès lors que vous avez paramétré le module. 2 champs au départ: l'identiifiant de la boutique, et la clef. Ensuite changer le mode TEST par PRODUCTION dès que vous recevez votre clef de production. Dans le cas d'un hébergement OVH, pas besoin d'OVH et de ses 150 euros pour démarrer avec prestashop. car il n'y a pas de CGI à appeler. et le port 443 eest ouvert de base. En résumé, pour faire du paiement sur internet, il faut: 1) un back office. celui de systempay est basé effectivement sur des techos très modernes, rendant la navigation très simples et intuitives (fonctions sur clic droit, sur double clic) 2) une interface avec un gateway de paiement qui si elle est via un FORM est triviale à intégrer. moins d'une heure pour un expert PHP. une journée dans le pire des cas. conseil: ne pas rester coincé dans les choix CGI simplement parce qu'on l'a déjà fait. et que cela semble plus simple. c'est forcémenent plus lourd à maintenir et plus compliqué à diagnostiquer en cas de problème. avec un Form, vous savez ce que vous faites, vous savez quels droits vous avez, vous savez le faire évoluer à votre gré et non quand l'hébergeur vous impose une nouvelle version. Et quand le FORM vient avec le back-office le plus intutuif du marché, on ne doit pas s'en priver. Clair? P.S: le forum de prestashop considère que je suis un beginner, (lié au nombre de messages postés), mais je suis plutôt un expert du sujet.
  23. Mais comme OVH vous met à disposition un serveur virtuel pour héberger votre plateforme, vous pouvez aussi le faire vous même. Le dialogue est en https, donc pas de problème de firewall. juste un fORM à poster à developper avec le calcul d'un clef de scellement. La doc intègre le code de l'algo dans tous les langages ou presque. Donc très facile à développer pour sa propre plate-forme. surtout si elle inègre un produit open source type prestashop. suffit de l'installer sur son serveur virtuel et OVH n'a rien à faire ni à facturer. En fait ce qui a été fait par OVH c'est de mutualiser les CGI d'atos et du Credit mutuel pour ne pas en avoir partout. mais avec un form à poster, il n'y a plus de contraintes.
  24. bonjour En fait OVH n'a interfacé que Atos (toutes les solutions listées hors Cybermut s'appuient sur le vieux truc d'atos avec un cgi). A ce jour OVH n'a pas intégré la nouvelle plateforme SystemPay de Natixis. Même s'ils ne sont pas contents d'atos. Un certain nombre de grands hébergeurs l'ont déjà fait (cela prend un à 2 jours max pour le faire et pouvoir ensuite le proposer facilement à tous les clients Natixis), mais OVH n'a pas (encore?) fait le travail. Ce qui est dommage pour les clients qui voudraient bénéficier de SystemPay. Cette plateforme est très moderne et propose des fonctionnalités très avancées en terme de back-office. En résumé OVH facture sa partie de paramétrage indépendamment de la prestation bancaire. La banque facture son contrat avec abonnement à son système de paiement et commissions bancaires. Vous pouvez tjs demander à OVH d'interfacer SystemPay comme Oxatis, Powerboutique, etc... En plus sans CGI! Et OVH devrait pouvoir rapidement mutualiser ce petit développement.
  25. réponse pour OVH: OVH n'a pas de solution propre à ma connaissance. s'il a une offre en propre, comme il ne remplit pas les certifications pci-dss de visa et mastercard, il encourt une amende de 25 000 dollars de la part de mastercard, une fermeture du service de la part de visa. ils ne sont pas non plus certifiés 3D-secure. j'étais resté sur le fait qu'ovh intègre sips (dont il n'est pas content. mais quel hébergeur aime installer des CGI de partout quand on peut poster un FORM en https?). pour la banque populaire la solution systempay respecte toutes les contraintes demandées par visa et mastercard et a tous les agréments. (Verifed by Visa, Mastercard secure code, PCI-DSS, ..) il ne s'agit pas dans ce cas d'économie, mais de garantie de paiement. ce qui n'est pas pareil.
×
×
  • Create New...

Important Information

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