Utilisation d'un système de paiement électronique

Le logiciel Open Food Network Demandes de nouvelle fonctionnalité
1

Quel système de paiement utiliser en France ?

  • Les options

  • Cartes bancaires du commerçant
    Cette option implique que le commerçant dispose d’un contrat avec la banque et saisisse ses informations permettant le versement direct sur son compte
    Cette option ne semble pas adaptée à notre cas et obligerait à supporter différents systèmes.

  • Paypal
    Solution unique pour l’ensemble des commerçants qui impose à celui-ci d’ouvrir un compte
    Frais importants (3,4% + 0,25€ par transaction si <=2 500,00€ mensuel, 2% et 0,25€/transaction entre 2 500 et 10 000€ mensuels)

  • Mangopay
    Les fonds transitent de la CB du client vers un e-wallet du client dans Mangopay, puis de e-wallet client au e-wallet commerçant puis du e-wallet commerçant au compte bancaire du commerçant.
    La création des e-wallets client et commerçant est transparente pour eux, mais doit être gérée par nous (OpenFoodFrance) lors de la création du client et lors de la création du commerçant dans le système.
    Les frais sont plus réduits que paypal : 1,8% + 0,18€ par transaction entre la CB Visa/Mastercard et le-wallet du client, pas de frais pour le commerçant.
    Cette solution semble la plus adaptée pour nous.

Détails d’une solution avec Mangopay

La création des e-wallet est simple et peut être gérée “à la volée” au moment où on le veut : création du compte ou transaction d’achat.

Par contre, les données nécessaires au fonctionnement du e-wallet dépendent du montant des transactions. En effet dans le cadre de la sécurisation des opérations bancaires et de la lutte contre le blanchiment, les données permettant d’identifier le propriétaire du e-wallet sont plus important dès que le montant dépasse 2 500€ par an pour un client et 1 000€ par an pour un commerçant. En dehors du nom, la nationalité, la date de naissance et le lieu de résidence sont nécessaires. Un commerçant doit être identifié en tant que tel. Au delà de ce montant, il faut fournir des copies de documents officiels (carte d’identité, passeport, KBIS, …).

En termes de sécurité, on peut considérer que les données bancaires ne seront pas stockées dans nos systèms mais seulement chez Mangopay. Il faudra vérifier qu’aucun fichier de trace ne contiendra ces informations, mais c’est réalisable. Mangopay disposant d’une certification PCI-DSS est autorisé à stocker les données bancaires de façon sécurisée.

Modalités de fonctionnement

  • Pour le client

Lorsque qu’un client valide son panier d’achat, si l’option Paiement par CB a été choisi et si il n’y a pas d’ID Mangopay associé au client, la page de paiement demande au client de saisir et valider les informations nécessaires pour Mangopay (option simple, montant annuel inférieur à 2 500€). Ces informations sont utilisées pour créer un e-wallet chez Mangopay, et en cas de succès, la page de paiement Mangopay est affichée et l’ID du e-wallet est associé dans le système avec le client (données complémentaires).

Un contrôle complémentaire avant et après paiement permet de détecter si le client s’approche du montant de 2 500€. Si c’est le cas, il est informé qu’il ne pourra plus passer de commandes sans fournir les informations complémentaires et les documents. Il peut compléter les infos et télécharger les documents s’il le souhaite.

:arrow_right: l’ensemble de ces changements peuvent être faits dans OpenFoodNetwork (commun à toutes les instances), cela représente une charge de travail mais c’est jouable. Je dirai 5 jours max pour quelqu’un qui connaît Ruby on Rails et l’architecture d’OFN. Mangopay dispose d’une interface Ruby.

  • Pour le commerçant

Compte-tenu de la faiblesse du montant nécessitant des données complémentaires (1 000€), il me semble nécessaire de la demander dès la création du compte. C’est possible, dans des modalités similaires à celles du client mais probablement un peu plus complexes car il faut que cela s’intégre dans Spree. Ceci va poser des pb de compatibilité de version.

2 opérations complémentaires sont nécessaires:

  1. Matérialiser la fin de la transaction pour que les fonds soient transférés du e-wallet client au e-wallet commerçant. L’interface d’OFN permet de gérer pour chaque commande sont statut. Lors du passage de shipment_date de “en attente” ou “Prêt” à “Expédié”, les fonds sont débloqués par un appel à Mangopay pour transferer entre les 2 e-wallets.

  2. Transférer les fonds vers le compte bancaire du commerçant

Rien n’oblige de faire l’opération pour chaque commande. Le commerçant peut le faire pour la totalité de son e-wallet. Le faire dans OFN nécessiterait d’ajouter un menu d’administration supplémentaire, accessible uniquement aux entreprises, permettant de réaliser l’opération.

:arrow_right: La quantité de changements semble nettement plus important. Il faut se poser la question de savoir si on le fait pour les commerçants dans OFN ou via une application externe mais qui devrait fonctionner en SSO avec OFN.

2

@christian merci de lancer la discussion!

Je crois qu’il ne faut pas oublier un point essentiel d’Open Food Network: la subsidiarité.
Ce principe signifie que les décisions doivent être prise au niveau le plus local possible. Appliquée au système de paiement, cela signifie que le manager de hub doit être capable de choisir le système de paiement qu’il souhaite utiliser, et nous ne souhaitons en imposer aucun, mais offrir par défaut les options les plus courantes / adaptées, et être prêts à ajouter des options sur demande (et éventuellement dans ce cas budget par le demandeur).

Pour laisser la liberté de choix et en même simplifier la vie des managers de hubs qui n’ont pas de préférence, ma recommandation serait de propose plusieurs options courantes et de négocier une offre pour les managers de hubs intéressés avec le prestataire qui nous semble le plus intéressant.

Plus en détail, il me semble important d’offrir au moins 1 (ou 2) choix dans chaque catégorie de paiement:

  • carte bancaire : cette option doit absolument pouvoir être disponible, c’est l’option de base proposé par Stripe par exemple, ou Mastercard. Sur Stripe, voir le taux, c’est pas cher: https://stripe.com/fr/pricing. Dans ce cas le hub est un intermédiaire, collecte les paiements et paie ses fournisseurs de façon classique. Ce paiement sera particulièrement adapté dans le cas d’un hub de type “drive” associé à une boutique qui reçoit une facture mensuelle de ses fournisseurs par exemple.

  • Paypal : Semble intévitable de le proposer aujourd’hui, très utilisé. De plus l’API est déjà intégrée, la solution est déjà offerte et utilisée par certains hubs en Australie. Je ne comprends pas quand tu dis “solution uniquement pour l’ensemble des commerçants”, ce n’est pas vrai, on peut offrir Paypal comme une option parmi plusieurs, c’est déjà le cas…

  • paiement non intégré à la plateforme: pour qu’un hub puisse proposer à ses membres/clients un paiement par chèque / carte bleu (iZettle ou terminal de paiement classique) / espèce à la livraison / virement bancaire direct

  • e-wallet : type Mangopay, que tu décris ici. Présente l’intérêt de simplifier le management d’un hub, le manager de hub n’ayant pas besoin de reçcevoir les paiement puis de payer les fournisseurs, les paiements étant directement dirigés vers le e-wallet de chaque producteur. Aussi permet au hub de ne pas être considéré comme intermédiaire de commerce mais comme apporteur d’affaire.

##Quelques remarques sur Mangopay et les systèmes de e-wallet.

  • Tout d’abord, regarde aussi Stripe pour comparer, ils ont la même offre :slightly_smiling:

  • Ca me paraît bien de demander les infos au producteur à la création du compte. Par contre attention,** légalement tu ne peux pas transférer l’argent au producteur avant que la livraison ait eu lieu**, et le statut shipment “prêt à expédier” ne correspond pas à cela! De plus il peut y avoir des ajustements de commande à la livraison (pour gérer un hub depuis 4 mois maintenant, je peux témoigner que ça arrive à chaque cycle de vente!) Donc le manager de hub va faire des ajustements au dernier moment, lors de la livraison (par exemple, le producteur X n’est pas venu, je retire les produits des commandes correspondantes).
    Du coup il me semblerait plus adapté que le manager de hub, à l’issue de sa vente, quand il a finit tous les ajustements, appuie sur un bouton “valider le cycle de vente et envoyer les paiement”. A intégrer du coup.

  • Je crois qu’il y a un autre élément important à intégrer dans notre cas: la gestion de “entreprise fees”. En effet, dans notre cas, les redirections des montants vers les bon e-wallet se feront sur le base de “qui est le fournisseur du produit” dans le cas des producteurs, mais pour le hub et l’instance, la modalité de versement sur les e-wallet reste à définir (prendre en compte les impacts juridiques).

  • option 1: sur la base des “entreprise fees”, on intègre dans la plateforme un autre type d’entreprise fee spécifique correspondant au reversement à l’'instance Open Food France, et cette entrée sert de base au reversement sur le e-wallet d’Open Food France (facturation directe par prélèvement à la source). Idem pour les commissions prises par le hub, et visibles sous forme d’entreprise fees. Problème: légalement il faut savoir qui Open Food France facture: le manager de hub (qui utilise OFFrance pour apporter des affaires au producteur)? Les producteurs (qui utilisent OFFrance pour faire de la vente directe groupée et rémunèrent l’apporteur d’affaire = manager de hub)? Dans le second cas le système doit aussi produire une facture du manager de hub vers chaque producteur dans ce cas.
  • option 2: les paiements du manager de hub et d’Open Food France ne sont pas intégrés, et se réalisent sous forme de facturation mensuelle par le manager de hub aux producteurs d’une part, et par Open Food France soit aux producteurs soit au manager de hub d’autre part.
  • Bref, tout ça doit être étudié de près d’un point de vue légal…

  • Concernant la** limite de 2500€**, peut-on “customiser” le message envoyé aux clients? Ce serait bien d’expliquer du coup au client pourquoi on va lui demander sa carte d’identité, et rédiger un message sympathique qui provoque la compréhension, pour éviter de perdre des clients :wink:

  • Et pour finir, je crois que cette discussion devrait être créée et discutée à l’échelle globale, sur le community forum OFN global, car la mise en place de Mangopay ou autre système de e-wallet est aussi souhaité par l’Angleterre par exemple, et les modalités d’intégration (ex: bouton pour valider le cycle de vente et envoyer les paiement) doivent être discutées à l’échelle internationale pour qu’on se mettre d’accord avant intégration. Dis-moi @christian si tu peux lancer cette discussion ou si tu veux que je m’en charge.

3

@Myriam, je pense qu’il faut séparer 2 threads:

  • la discussion théorique : je te laisse la remonter au niveau global
  • la discussion sur les priorités opérationnelles pour la france : nous, les développeurs, on a besoin de savoir sur quoi on bosse. Je comprends que le sujet n’est pas mûr. Laissons tomber tant qu’on n’a pas une orientation claire.

2 points complémentaires:

  • on devrait toujours essayer de parler en termes de Use Case (ce qu’il y a à faire), ça permet de se rendre compte de la complexité de ce qu’on demande
  • les phrases commencent sous la forme : En tant que …
  • exemple : en tant que plateforme, je veux offrir au moins 3 options de paiements différentes : xxx, yyy, zzzz
  • toujours penser en terme de MVP : minimum viable product - le minimum de ce qu’il faut avoir pour que ce soit vendable. On peut ensuite ajouter des fonctionnalités, mais l’objectif c’est d’avoir le minimum utile. Si le MVP est trop gros, il faut se poser des questions.
4

Pour info pour suivie de ce point, une discussion a été ouverte sur le forum de la communauté internationale: http://community.openfoodnetwork.org/t/how-to-offer-mangopay-as-a-payment-method-to-hubs/535

5

@gnollet est-ce que tu sais si l’intégration d’un nouveau système de paiement dans la plateforme est simple techniquement? Par exemple l’API Stripe, est-ce simple à lier pour qu’elle s’affiche dans les options de système de paiement? D’ailleurs est-ce qu’on peut retirer PinPayments de la liste, c’est valable qu’en Australie.

6

@Myriam, je ne sais pas, c’est @nicolas qui pourras te répondre.
Pour retirer ou désactiver un mode de paiement, je ne sais pas non plus. Si on retire PinPayments, il faut aussi retirer les autres modes qui ne servent pas comme Bogus.

7

@Myriam @gnollet Hello, non je ne sais pas non plus. Par contre je vais me renseigner avec l’equipe de dev Aus pour voir comment on fait…

8

@nicolas dans ce cas tu peux aussi leur demander pour Bogus, il me semble que c’est une option qui sert pour des tests, elle n’apparaît pas sur les comptes users il me semble, juste sur les compte admin. Mais ce serait bien de savoir :slightly_smiling: Et on pourrait documenter sur le forum community, je n’ai rien trouvé là-dessus :wink:

9

Je “déterre” un peu le sujet pour faire une mise à jour :

aujourd’hui la plateforme intègre Stripe et Paypal.

Nous avons étudier l’intégration de solutions comme Ingénico et Limonetik, mais leur intégration demande un coût de dévelppement qui n’a pas pu être priorisé pour le moment.