Draft FreePay Pre Prod Jan 2011

Ma Finalité

Ma capacité de production

Traduction

La version française est la source primaire pour toutes les traductions. Pour les non francophone ou les non anglophones, il existe des outils de traductions comme Google translate (http://translate.google.com/) pour lire des documents dans votre langue.

Ma méthode

J’ai écris ma propre méthode de développement à partir de plusieurs bestsellers sur le
développement personnel dont :
– The 7 Habits of Highly Effective People de Steven Covey
– Getting to Yes: Negotiating Agreement Without Giving In – Fisher, Ury, Patton

– Je connais ce que je veux [vouloir] accomplir (futur). Je sais qui je suis [être] et ce que
j’ai [avoir]. (passé) Je fais [faire,construire] tout ce qui est nécessaire pour obtenir ce que
je veux. (présent)
– “Je peux définir ma finalité. Comme la causalité s’applique, et que ma finalité est la cause première / racine de toutes mes actions, mes conséquences sont dirigés vers ma finalité.”
– “Qui je veux être, détermine ce que je vais faire. Ce que je fais, détermine qui je suis.“
– “J’achève mon potentiel en changeant mon attitude face aux circonstances.”

Source : Ma Méthode de Développement Personnel – Yann Geffrotin (Fichier joint à ce projet)

Distinction

Ses Principes

– Liberté, Citoyenneté, Responsabilité, Égalité, Solidarité,

Ses Valeurs

Autonomie, Conformité, Sécurité.

Ses Qualités

– Ouvert, Réglementé, Prévisible, Non discriminatoire

Le paradigme de la finalité

Je pense que le succès d’un système de paiement n’est pas combien il prend par transaction mais combien il donne à ses utilisateurs (stratégie gagnant – gagnant) Je pense que le système de paiement qui donnera le plus à ses utilisateurs sera certainement celui qui sera à même de conquérir le marché. (théorie de la banque libre)

La transformation et la conformité avec le paradigme existant

  • Plusieurs personnes m’ont demandé de crée un système de paiement gratuit compatible avec une banque permettant de faire des transactions avec de la vrai monnaie.
  • Le paradigme existant des solutions de paiement n’est pas même de pourvoir à cette demande. Je pense que prendre une commission c’est une relation gagnant-perdant.
  • J’ai donc crée ce système. Premièrement, je pense que retirer progressivement les barrières qui entravent les échanges permet une meilleure liberté (réf Traité instituant la Communauté européenne, 1957) et secondement, permet d’établir une concurrence pure et parfaite.

Ma finalité personnelle

“Je veux améliorer ma santé et mon bien être et je veux réduire toutes les causes de ma mortalité chaque jour.” Yann GEFFROTIN

Ma Position personnelle

Je veux un système de paiement gratuit et rémunéré pour ses utilisateurs ayant une relation de dépendance avec un, ou de préférence plusieurs, conglomérat financier. (international de préférence)

Justification de la stratégie

Les Avantages de plusieurs conglomérats financiers comme fournisseurs :
– sécurité : protection contre le risque systémique
– pérennité : s’assurer de la continuité de l’API dans le temps.

Cible Marketing

Cible Utilisateur

Ce logiciel est été mis en oeuvre en ciblant principalement les utilisateurs de la banque utilisé parlant français ou anglais et ayant un minimum de compétences en finance. L’objectif n’étant pas de ce limiter à cette catégorie mais de pouvoir toucher le plus grand nombre d’ utilisateurs.

Cible Organisation

  • La plateforme de paiement ne prend pas de pourcentage sur les transactions qu’elle permet. En ce sens, une organisation qui l’utiliserait pourrait être du type organisation à but non lucratif.
  • Les entreprises à but lucratif voulant mettre en place une plateforme de paiement.

Cible Développeur

Les personnes ciblé pour le téléchargement et l’installation du logiciel sont les programmeurs (développeur web PHP / MySQL de préférence).

Ma production

Identifier les parties potentielles

Identifier les potentiels clients

Potentiels Sites de ecommerce

eBay, PriceMinister, Amazon, Cdiscount, la FNAC, La Redoute, 3 Suisses, voyage sncf, Carrefour, Pixmania, Spartoo, Mistergooddeal, RueDuCommerce…

Source : FEVAD : Le classement des sites de e-commerce 2010

Identifier les Fournisseurs potentiels

Potentiel fournisseur Banque

Financial conglomerates with head of group in the EU/EEA : Erste Bank, GRAWE, Wüstenrot, Universal Life Group, Ceska pojistovna, Cespo, Petr Kellner, PPF Group, Alm. Brand, Danske Bank, OP Bank Group, Sampo, ABN AMRO France, Banque Postale, Banques Populaires, BNP Paribas, Caisses d’Epargne, Credit Agricole, Credit Mutuel, Societe Generale, Allianz, DEBEKA Group, DZ Bank Gruppe, Inter Group, Munich Re, Wüstenrot und Württembergische, OTP, Bank of Ireland, Irish Life and Permanent, Gruppo Banca Intesa, Gruppo Carige, Holmo, Mediolanum, Monte Paschi Siena, San Paolo-IMI, Unicredito, Delta Lloyd, Eureko, ING, Rabo-Interpolis, Robein,SNS-Reaal, VVAA, DnB-NOR, Jernbane-personalets, Sparebank1, Storebrand, Terra Group, Agrupacion Mutua/Bankpyme, Banco Bilbao Vizcaya Argentaria, Banco Santander Central Hispano, Caja Madrid, Caja Tarrassa, La Caixa, Länsförsäkringar, Nordea, Resurs, SalusAnsvar, SEB, Skandia, Svenska Handelsbanken, Abbey, Barclays, Cooperative Group, HBOS, Hermes, HSBC, Julian Hodge Bank Group, Liverpool Victoria, Lloyds TSB, Old Mutual, Provident Financial, Prudential, Royal Bank of Scotland, Standard Life…

Source :

Potentiel fournisseurs de matériel informatique

Acer, Apple , Asus, BenQ, Dell, Fujitsu, Hewlett-Packard, Compaq, Hitachi, IBM, Lenovo, LG, Olivetti, Sun Microsystems, Panasonic, Samsung Electronics, Sony Corp…

Source : http://en.wikipedia.org/wiki/List_of_computer_system_manufacturers

Potentiel fournisseurs de logiciels

PHP, MySQL, Zend

Potentiels Logiciels de ecommerce

Zen-Cart, VirtueMart, PrestaShop, osCommerce, Shopify, PHPCart, PHPShop, AGORACart…

Source : http://en.wikipedia.org/wiki/List_of_free_and_open_source_eCommerce_software

Potentiel fournisseurs de formations et de certifications

Anaska : http://www.anaska.com/

Potentiel fournisseur d’hébergement
Potentiel fournisseurs de compétences
Potentiel fournisseurs en sécurité

Identifier les potentiels partenariats

Identifier les potentiels investisseurs
Identifier les potentiels entrepreneurs
Identifier les potentiels affiliés
Identifier les potentiels promoteurs
Identifier les potentiels Partenaires
  • Les vendeurs : à définir
  • Les distributeurs de logiciels : à définir
  • Les revendeurs : http://www.softreseller.com/
  • Les intégrateurs : à définir

Identifier les intérêts des parties

5 parties : Les Consommateurs, Les Fournisseurs, Les Concurrents, Les Partenaires et Soi-même.

1. Les intérêts des Consommateurs

1.1 Les intérêts des sites de ecommerce
  • Les sites de ecommerce sont intéressé par prendre des commissions en fixe ou en variable.
  • Les sites de ecommerce sont intéressé par vendre des biens et des services en ligne à leur clients.
  • Les sites de ecommerce sont intéressé par accroître leur volume de leurs ventes (issu de l’augmentation du volume de transactions) via le passage pour leur client et eux même par des banques et des PSP (tout deux accessible via des API).
  • Les sites de ecommerce sont intéressé par rapatrier leur argent auprès de leur banques.
1.2 Les intérêts des plateforme de trading
  • Les plateforme de trading sont intéressé par la définition d’un business model.
  • Les plateforme de trading sont intéressé par gagner de la monnaie (via des commissions par transactions, des frais d’entrée, des frais d’installations, des frais de maintenance, des retro-commissions sur la publicité…)
  • Les plateforme de trading sont intéressé par la réduction de coût de leur plateforme logicielle, et la réduction du temps de développement informatique.
  • Les plateforme de trading sont intéressé par un accès sur d’autres plateformes de trading pour gagner plus de monnaie.
  • Les plateforme de trading sont intéressé par un accès auprès de leur fournisseurs (banque et PSP) via un ou plusieurs API.
1.3 Les intérêts des utilisateurs finaux
  • Les utilisateurs finaux sont soit des particuliers soit des entreprises qui sont intéressé par déplacer leur argent chez des PSP et/ou chez des sites de ecommerce.
  • Les utilisateurs sont intéressé par des primes de parrainages.
  • Les utilisateurs sont intéressé par le déplacement de leur monnaie entre leur banque, leur PSP, leur marchand et leur plateforme de trading. (placements auprès de leur banque, remplissage de leur porte monnaie éléctronique, obtenir des biens ou des services de l’ecommerçant, faire fructifier rapidement leur monnaie auprès des plateformes de trading)
  • Les utilisateurs sont intéressé par la baisse du taux par transaction du PSP.
  • Les utilisateurs sont intéressé par consommer des services.
  • Les utilisateurs sont intéressé par ne pas avoir à se déplacer physiquement pour acheter une marchandise.

2. Les intérêts des Fournisseurs

2.1 Les intérêts des banques
  • Les banques sont intéressé par obtenir de la monnaie de leur client. (sites de ecommerce, plateforme de trading, PSP, client finaux)
  • Les banques sont intéressé par renforcer leur business model. (orientation)
  • Les banques sont intéressé par améliorer leur expertise via leur société mère. (connaissance)
  • Les banques sont intéressé par consolider leur finance via un conglomérat financier. (le pouvoir)
  • Les banques sont intéressé par consolider leur positions sur le marché (le pouvoir)
  • Les banques sont intéressé par augmenter la taille du réseau de partenaires. (la sécurité)
  • Les banques sont intéressé par avoir l’infrastructure nécessaire à leur réussite. (support matériel et humain)
  • Les banques sont intéressé par augmenter leur nombre de clients, la taille des comptes de leur clients et le volume de transactions entrantes.
  • Les banques sont intéressé par prendre des commissions sur les intérêts de chaque compte.
  • Les banques sont intéressé par la vente de services auprès de leur client ( de type banque/assurance).
  • Les banques sont intéressé par le backlinking et la présence de sa marque sur internet. Cela peut se faire via des contraintes sur l’intégration visuelle de ses logos relatif à la page d’accueil, au différents mode de paiements et aux options supplémentaires.
2.2 Les intérêts des sociétés de services en logiciels
  • Les sociétés de services en logiciels sont intéressé par être payé.
2.3 Les intérêts des intégrateurs
  • Les intégrateurs sont intéressé par être payé.

3. Les intérêts des PSP

3.1 Les intérêts des partenaires
  • Les partenaires sont intéressé par le business modèle du PSP et le logiciel. Les partenaires sont intéressé par la stratégie gagnant-gagnant avec les parties.
  • Les partenaires sont intéressé par se regrouper pour avoir plus de pouvoir. (groupe d’intérêts économique permettant une réduction de coûts et une augmentation du profit global)
  • Les partenaires sont intéressé par la spécialisation sur une branche.
  • Les partenaires sont intéressé par leur propres commissions via l’affiliation.
  • Les partenaires sont intéressé par l’augmentation de leur traffic utilisateurs. (via la publicité)
3.2 Les intérêts des concurrents
  • Les concurrents sont intéressé par gagner plus de monnaie.
  • Les PSP ont un avantage concurrentiel supérieur puisqu’ils bénéficient de leur propre expertise en plus de l’accès à la mienne. (comprend l’accès à tout le capital intellectuel et donc aussi aux mesures de sécurité)
3.3 Les intérêts pour Soi même
  • Les PSP sont intéressé par l’augmentation de son chiffre d’affaire.
  • Les PSP sont intéressé par la création d’une dépendance avec un plusieurs conglomérats financiers. (fournisseur bancaire) Les messages financiers sont géré par un système de messagerie électronique (confirmation) par les banques (via une API) qui permet d’importer de la monnaie auprès du PSP.
  • Les PSP sont intéressé par l’augmentation de son nombre de clients, de fournisseurs et de partenaires. Les principaux clients des PSP sont les marchands et les plateforme de trading qui leur permet d’accroître leur volume de transactions et les montants via les utilisateurs qui les utilisent. Ceci se fait par l’augmentation de leur nombre de clients qui est proportionnel à l’accès de leur système d’informations : l’API (Application Programming Interface) qui permet à quiconque d’automatiser les paiements.
  • Les PSP sont intéressé par une amélioration de sa visibilité sur le web. Les PSP sont intéressé à ce que leur logo soit visible chez leur clients. Cela se fait par la création d’un guide d’intégration visuel pour les clients. (contraintes d’intégrations visuelles)
  • La plateforme de trading est une couche logiciel au dessus du PSP. La conception et l’évolution de ce produit informatique peut être en partie externalisé auprès d’une ou plusieurs personnes qui s’occupe d’un logiciel libre de plateforme de trading ce qui permettrait de réduire les coûts et le temps de développement.

Les stratégies pour faire du business

Il existe 3 stratégies possibles pour 1 personne : Gagnant – Pas de deal – Perdant. (Ce qui fait 9 combinaisons pour 2 personnes)

Cas pratique

Stratégie Gagnant – Gagnant : Cela m’intéresse. Cela intéresse l’autre partie.
Stratégie Gagnant – Pas de deal : Cela m’intéresse. Cela n’ intéresse pas l’autre partie.
Stratégie Gagnant – Perdant : Cela m’intéresse. Cela n’ intéresse pas l’autre partie.

Stratégie Pas de deal – Gagnant : Cela ne m’intéresse pas. Cela intéresse l’autre partie.
Stratégie Pas de deal – Pas de deal : Cela ne m’intéresse pas. Cela n’ intéresse pas l’autre partie.
Stratégie Pas de deal – Perdant : Cela ne m’intéresse pas. Cela n’ intéresse pas l’autre partie.

Stratégie Perdant – Gagnant : Cela ne m’intéresse pas. Cela intéresse l’autre partie.
Stratégie Perdant – Pas de deal : Cela ne m’intéresse pas. Cela n’ intéresse pas l’autre partie.
Stratégie Perdant – Perdant : Cela ne m’intéresse pas. Cela n’ intéresse pas l’autre partie.

Résultats

– 5 situations sont intéressante pour 1 des 2 parties.
– Seulement 1 situation est intéressante pour les 2 parties.
– La seule solution qui me semble la plus judicieuse est donc : La stratégie gagnant-gagnant.

Ma Stratégie gagnant – gagnant

Recettes : Comment la société va-t-elle devenir profitable ?

  • En admettant que le système parvient à lever entre 10 à 100 millions d’utilisateurs, ayant chacun entre 10 et 100 euros sur leur compte. La monnaie est stocké auprès de la banque. Le taux directeur de la banque centrale européenne (BCE) est situé entre environ 1% et 3.75%. Les comptes sont rémunérés au taux en vigueur.
  • De même, les utilisateurs peuvent faire des dons.
  • Et l’organisation peut vendre du service autour de son logiciel.

Source : ECB: European Central Bank > Statistics > Monetary operations > Key interest rates (http://www.ecb.int/stats/monetary/rates/html/index.en.html)

Dépenses

  • Les gains servent à financer le paiement du/des développeurs et le green hosting (serveur avec une démarche développement durable). S’il en reste, il est soit capitalisé, soit redistribué de manière équitable (proportionnel au compte) pour la totalité des membres.
  • Le prix d’un ingénieur financier étant estimé à environ 35 à 55 KE.

Économies

La Formule : prix d’un conglomérat * nombre de conglomérats financiers * multiplié par le nombre de plate-forme installé = économie totale réalisé

Les Données chiffrés :

– 75 conglomérats financiers listés.

– Définition d’un conglomérat financier : minimum 6 Milliards d’ Euros.
Cas pratique :
– optimiste : 75 conglomérats financiers * 8 Milliards * 10 plate-formes = 6000 milliards d’ Euros
– pessimiste : 5 conglomérats financiers * 6 Milliards * 1 plate-forme = 30 milliards d’ Euros

Cela représente une économie de 30 milliards d’euros minimum.

Résultats

Produits :

  • RB Optimiste : 100 millions E (utilisateurs) * 100 E (solde) * 0,0375 (taux de 3.75 % de la BCE par an) = 375 millions d’ Euros.
  • RB Pessimiste : 10 millions E (utilisateurs) * 10 E (solde) * 0,01(taux de 1% de la BCE par an) = 1 million d’Euros

Charges :

(Coût salariaux) :

  • CS Optimiste : 35 000 (coût d’un ingénieur à l’année) * 5 personnes = 175 000 Euros par an.
  • CS Pessimiste : 55 000 (coût d’un ingénieur à l’année) * 10 personnes = 550 000 Euros par an.

Résultat net :

  • RN optimiste : Produit – Charges = 374 825 000 Euros
  • RN pessimiste : Produit – Charges = 450 000 Euros

Objectifs SMART du PSP

Je fais uniquement ce qui est nécessaire. (le minimum pour changer de paradigme)

Faire un projet pilote (fonctionnel, gratuit dans sa mise en place et dans son utilisation, légal, disponible (7/7j, 24/24h) et reposant sur une situation gagnant-gagnant) d’une plateforme de paiement internationale à partir d’une API bancaire et de Paybook.

Mes critères

  • relation entre banque et PSP (API) :
    • Importer de l’argent (paiement, confirmation),
    • exporter de l’argent (paiement, confirmation)
  • PSP (système de paiement) :
    • solde,
    • paiement entre utilisateurs,
    • historique
  • relation entre PSP et ecommerce (API) :
    • paiement,
    • confirmation

Réalisé

A réaliser

Mon Existant

Ma capacité de production

L’offre des parties

1. L’offre des Consommateurs

  • Les clients finaux ont à offrir de l’argent.
  • Les e commerçant ont à offrir des biens et des services.
  • Les plateformes de trading ont à offrir des services financiers.

2. L’offre des Fournisseurs

Offre fournisseur Banque
  • Les banques ont à offrir un service de stockage de la monnaie, des services financiers, une documentation sur l’utilisation de leur produit, des contrats et un accès à leur API.
Offre Fournisseur Informatique
  • Formation / Certifications : Les formateurs peuvent offrir des services de formation et de certifications.
  • Matériels : Les fournisseurs en informatique peuvent offrir du matériel informatique.
  • Logiciels : Les sociétés de services en logiciels ont à offrir leur expertise technique.
  • Hébergement : Les hébergeur peuvent offrir de l’espace disque illimités, de la bande passante illimité et des domaines illimités, une documentation sur l’utilisation de leur produit et leur logo pour intégration.
  • Intégration : Les intégrateurs ont à offrir leur savoir faire en intégration bancaire et e-commerce.

3. L’offre des PSP

  • Les PSP ont à offrir des services financiers, une documentation et un accès à leur API.
  • Les PSP ont à offrir des Certifications.
  • Les PSP peuvent remplir un fichier PAD pour les revendeurs. Les PSP peuvent se référencer eux-même chez les revendeurs.
  • Les PSP peuvent remplir une liste de partenaires agrée sur leur propre site.

Explication sur le fonctionnement

Le PSP (API côté fournisseur) fonctionne comme un site marchand. Il vend la traçabilité virtuelle de la monnaie contre de la monnaie.

Le PSP (API côté client) fonctionne comme une banque et donc comme un intermédiaire financier (proxy) de la transaction. Le client détient un compte dans le compte global de la banque.

La banque, le PSP et le client s’imbrique comme un puzzle. L’API fournisseur étant le mirroir de l’API client.

Justification bancaire

Pourquoi une relation avec une banque

La division des rôles : Le logiciel peut être vu comme un plugin qui interagit avec le logiciel principal (l’institution financière) pour lui apporter une nouvelle fonctionnalité. Le logiciel est un système ouvert qui envoie des informations à l’intérieur (historique) et à l’extérieur (ordre).

– L’institution financière transforme les capitaux entrant en monnaie électronique, fais les paiements et fais les conversion de chèques.
– Le logiciel permet de passer des ordres de paiement, d’échanger des ordres de paiement et permet de faire des demandes de paiement.

Dépendance : Le PSP est dépendant de/des l’institution financière(s) qui permet de faire les paiements (Relation 1 à plusieurs).

Indépendance
: Chaque organisation qui met en place le PSP est autonome des autres organisations.

Le Choix de la banque

On ne devrait pas effectuer un transfert d’argent (une transaction) avant d’avoir vérifié que l’on peut en sauvegarder la trace. Car sinon, la personne sera déçue d’avoir payé sans obtenir sa contrepartie.

Au vu de l’évolution rapide des systèmes de paiements, il est préférable que l’API gère les versions afin que les anciennes versions fonctionnent toujours.

La problématique de sécurité a aussi été un critère décisif.

L’API de la banque a été choisi car elle respecte ces contraintes.

Justification Économique

Le logiciel permet la circulation de la monnaie entre les acteurs économiques.

Justification Monétaire

Il n’y a pas de monnaie échangé dans le système de paiement. La monnaie est uniquement stocké dans la banque. Le système ne s’occupe pas de l’aspect création monétaire.

Justification sur les aspects législatif et réglementaire

Autorités financières compétentes

– Autorité de Contrôle Prudentiel (France) : http://www.banque-france.fr/acp/index.htm
– La Commission bancaire et de l’Autorité de Contrôle des Assurances et des Mutuelles (ACAM) : http://www.acam-france.fr/

Justification législative

Je pense que mon système est légal car j’ai fais des recherches en ce sens avant de le mettre à disposition de tous.

Je considère qu’il va dans le sens des principes de l’union européenne. (http://europa.eu/scadplus/european_convention/objectives_fr.htm) . J’ai joint dans le dossier « support » > « docs » les documents de référence concernant le contexte législatif, juridique et réglementaire qui pourrait s’y rapporter.

Le site internet de la commission européenne est très instructif sur cette question. (http://ec.europa.eu/internal_market/top_layer/index_24_fr.htm ) Rubrique : Commission européenne >Marché Intérieur > Le marché unique des services > Services financiers. Je ne suis pas complètement d’accord sur le choix de cette rubrique puisque la plateforme de trading offre un service gratuit (sans contrepartie) et ne gère pas d’argent (uniquement la confirmation que l’argent a été transféré).

Fonds d’investissements > Investissements alternatifs : il existe un Projet de Directive relative aux gérants de fonds dits ‹ alternatifs ›. Ce projet de directive peut encore être changé, et, la version finale ne va pas forcément s’appliquer à ce cas très précis. http://ec.europa.eu/internal_market/investment/alternative_investments_fr.htm

Services de paiement > Monnaie électronique : La plateforme de trading ne crée pas de monnaie. Donc, cela ne concerne que le PSP. http://ec.europa.eu/internal_market/payments/emoney/index_fr.htm

Services de paiement > e-Facturation : c’est PSP qui gère la facturation (il peut le désactiver) Uniquement une copie est gardé à des fins d’archive par la plateforme de trading (ou rien suivant le paramétrage) http://ec.europa.eu/internal_market/payments/einvoicing/index_fr.htm

Conglomérats financiers : Selon la taille du système de trading et sa structure, il peut entrer ou ne pas entrer dans cette catégorie. C’est au choix du/des entrepreneurs selon les opportunités de fusion / acquisitions. http://ec.europa.eu/internal_market/financialconglomerates/index_fr.htm

Commerce électronique : Cela dépend de ce qui est fait par les clients en contrepartie de l’argent envoyé. http://ec.europa.eu/internal_market/e-commerce/directive_fr.htm

Notes et références

  • Friedrich August von Hayek – Denationalisation of money (1976) (obtient le prix nobel d’économie en 1974)
  • Jean Gustave Courcelle Seneuil – La Banque libre, exposé des fonctions du commerce de banque et de son application à l’agriculture
  • Jeffrey M. Herbener – Ludwig Von Mises on the gold standard and free banking
  • Randall kroszner – Free Banking The Scottish Experience as a Model for Emerging Economies
  • Smith, Vera C – The Rationale of Central Banking and the Free Banking Alternative
  • Walter Bagehot – Lombard Street A Description of the Money market

Mon Copyright

Mon droit d’auteur est garanti par la Licence publique générale GNU. http://www.gnu.org/licenses/gpl.html

International

Mes créations sont protégés internationalement par la Convention de Berne pour la protection
des oeuvres littéraires et artistiques (géré actuellement par l’ Organisation mondiale de la
propriété intellectuelle (OMPI), organisme spécialisé au sein de l’ONU). (source :
http://www.wipo.int/treaties/fr/ip/berne/trtdocs_wo001.html )

Européen

Mes créations sont protégés au niveau Européen par la Directive 91/250/CEE du Conseil, du 14
mai 1991, concernant la protection juridique des programmes d’ordinateur. (http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:FR:HTML )

Clause de non responsabilité

L’utilisation de la présente application à valeur d’acceptation de la clause de non responsabilité
suivante : L’auteur décline toute responsabilité quant aux conséquences pouvant résulter de
l’utilisation de cette application.

Script fourni sans aucune garantie.

Me contacter

En tant que développeur, je recherche toujours un moyen de produire plus et à moindre coût. Ma motivation se base sur le fait que le logiciel fonctionne et qu’il est utile. Bien que je sois d’accord pour dire que le type de communication le plus efficient est le face à face, je reconnais aussi que je ne suis pas toujours disponible et donc, j’ai mis en place une documentation écrite. Dans le cadre d’une politique de transparence, j’ai aussi mis mon cv en pièce jointe afin de pouvoir renseigner qui le souhaite sur mon identité et mes aptitudes professionnelles (ce qui laisse plusieurs moyens de me contacter). Sa lecture est facultative.

De plus, je suis ouvert à toute suggestion permettant d’améliorer le logiciel. S’il y a des bogues, pour que je puisse les corriger, il faut que j’en ai connaissance précise. D’après mon expérience, pour améliorer un système, il faut que les utilisateurs puissent contacter l’auteur car l’amélioration de la plateforme se fait grâce aux boucles de rétroaction positive à l’initiative des utilisateurs. Ce retour servira de base à l’architecture de la prochaine version (qui contiendra l’existant + les corrections).

Enfin, si vous avez un problème de nature financière relatif à votre compte bancaire (le fournisseur), vous pouvez vous adresser au service clientèle de la banque.

Ma production

Télécharger le Logiciel

Le logiciel se base sur une politique de transparence et de développement durable. La licence
choisie est la GNU GPL. C’est un logiciel libre. De ce fait, il a été mis à disposition gratuitement
sur SourceForge.net pour être téléchargé et installé sur des serveurs en ligne.

à faire

Existant technologique

– La banque : à définir
– Green hosting with unlimited webspace and unlimited bandwith

http://www.hostgator.com/

http://www.greengeeks.com/

http://www.supergreenhosting.com/

http://www.fatcow.com/

– FreePay (relation entre banque et PSP, système de paiement : solde, paiement entre utilisateurs, historique) http://freepay.sourceforge.net/
– PayBook (relation entre banque et PSP, relation entre PSP et ecommerce ) http://paybook.sourceforge.net/

Pré-requis

Pour l’Utilisateur :
– Le seul matériel nécessaire est un pc, un système d’exploitation, une connexion à Internet et un navigateur web. Il n’y a rien à télécharger pour les utilisateurs.
– Multi-Plateforme : fonctionne sous Windows ou Linux avec Internet Explorer ou Firefox.
– La formation est gratuite. Elle constitue la documentation.

Pour le Développeur :
– Conçu en XHTML, CSS, JavaScript, PHP et SQL (CRUD).
– Nécessite un MySQL, phpMyAdmin, POP3 pour les mails, FTP et un navigateur web.
– A été testé et fonctionne avec Apache (>= 1.3.33), Mysql (>= 4.1.9), PHP (>= 4.3.10) avec l’extension cURL installé et PhpMyAdmin(>= 2.6.1).

L’architecture

Comme c’est un projet web, l’interface homme-machine est basé sur une architecture est de type client/serveur. Et, le serveur à une architecture en 3 tiers (base de données, traitements, présentation). L’architecture est en trois tiers (donnée, business logic et présentation). L’architecture se base sur le projet PayBook. Pour approfondir, la documentation de paybook est à votre disposition.

Le code source est en français. Les commentaires du code source sont en français aussi. Sauf pour les standards financiers qui sont en anglais. Le projet s’oriente vers une internationalisation (I18N).

Toutes les images sont dans un dossier spécifique (/images).
Tout les CSS (Feuilles de style en cascade) sont dans un dossier spécifique (/style).
Tout ce qui a attrait au support utilisateur est dans le dossier /support.

La documentation est dans le dossier /support/docs.

Tout ce qui concerne l’internationalisation est dans le dossier nommé « services/i18n ».

La programmation est de type procédurale : les méthodes sont appelés dans un ordre spécifique.

La partie visible est composé de la page principale, de l’historique et de la documentation.

L’existence d’une demande de paiement peut se vérifier via l’historique.

La disponibilité d’une demande de paiement peut se vérifier en appliquant le filtre avec le numéro ISIN en paramètre.

Les vues

L’architecture des vues est commune à FreePay (header et footer en commun sur toutes les pages).

Le Menu : Accueil, Historique des échanges, Paiement en ligne, Historique des transactions, Mes demandes de paiement, Contact, Documentation

Les contrôleurs

Ce sont les même que ceux de FreePay. PHP et Javascript pour le côté serveur et client
respectivement.

Les transactions qui n’aboutissent pas au bout d’1 journée sont classé comme ayant échoué.
(status à -2).

Les étapes du processus de paiement

Pour un utilisateur

1. L’utilisateur a crée son compte chez le PSP, l’a approvisionné, a surclassé son compte et récupéré les informations d’API.

2. L’utilisateur crée un compte. (Lien  sur la première page en haut à droite.)

3. L’utilisateur va sur la page d’achat et sélectionne un identifiant de marchandise. L’ordre d’achat est sauvegardé et accessible via le menu du même nom. Il récapitule l’état de la transaction (En cours / En attente, Échoue / Annulé ou Fini).

4. L’utilisateur est redirigé sur le PSP. Elle fait tout les étapes nécessaire au paiement. Et est retourné sur la plateforme de ecommerce automatiquement.

5. L’argent a été transféré par le PSP. La transaction en attente « pending » passe à « done » grâce au numéro de transaction récupéré du PSP. A chaque transaction, l’argent est sauvegardé dans les comptes de l’institution financière. En cas de crise (comme une indisponibilité de la plateforme de ecommerce), l’argent, lui, est toujours disponible.

6. L’utilisateur peut consulter ses achat de marchandise.Puis :
– Le vendeur reçoit une notification par email du FSX l’informant de l’achat d’une marchandise et de la réception de l’argent. (+ émetteur + argent + devise)
– L’acheteur reçoit une notification par email de l’institution financière. (+ argent + devise +
indicatif produit)
Le solde du compte de l’utilisateur est supérieur à ce qu’il était auparavant sans l’utilisation de la présente application. Ce qu’il fallait démontrer.
Chaque utilisateur peut répéter le processus autant de fois qu’il le veut sans restrictions.

7. L’utilisateur de déconnecte de la plateforme de ecommerce et du PSP.

Pour un développeur

à faire

Basiquement, il y a 3 fonctions (mis dans des fichiers du même nom) :
– SetExpressCheckout : Définir les informations pour le paiement

– GetExpressCheckout : Obtenir des informations sur l’acheteur
– DoExpressCheckoutPayment : Exécute le paiement et Obtenir confirmation de l’exécution du paiement

1. L’acheteur sélectionne une commande. Les informations du formulaire (montant + devise + langue) ainsi que les informations du vendeur (API_username, API_password, API_signature) sont injectés dans le SetExpressCheckout à destination de la plateforme de paiement (en cURL).

2. Le ACK du SetExpressCheckout est un succès ou un échec.

3. Si le ACK du SetExpressCheckout est un succès, l’acheteur est redirigé vers la plateforme de paiement (en spécifiant le Token du ACK dans l’url) via une redirection HTTP (JavaScript ou html). L’acheteur se logue et confirme sa commande. (L’acheteur paye sur le PSP)

4. L’acheteur est ensuite redirigé (grâce à une adresse de retour fourni dans le SetExpressCheckout) sur la plateforme de ecommerce. L’ url fournit par le PSP contient un token et le PayerID.

5. Le token peut servir à récupérer les informations de la transactions définie dans le SetExpressCheckout. Les informations sont ensuite injecté dans un GetExpressCheckout,

6. puis dans un DoExpressCheckoutPayment.

7. Si le ACK du DoExpressCheckoutPayment est un succès, les traitements du vendeur s’exécutent.

Les status / états d’une transaction : 2 : validé (Processed), 1 : test , 0 : en attente (Pending), -1 : annulé (Cancelled), -2 : Échoué (Failed ), -3 : Retour arrière (Chargeback)

Optionnel :
– Enregistrer les réponses du PSP dans un table. (KISS : Keep it Simple, Stupid)
– Pour changer la devise : définir le CURRENCYCODE dans SetExpressCheckout et DoExpressCheckoutPayment
– La langue locale est définie uniquement dans le SetExpressCheckout. (AU,DE,FR,GB,IT,ES,JP,US accepté par le PSP)

Le script ne prend en compte que les champs obligatoires par mesure de simplification. Pour ce qui est des champs facultatifs : se référer à la documentation officielle.

La base de donnée

Une table pour l’inscription des clients.

à faire

Sécurité

Sessions : Les utilisateurs authentifiés peuvent accéder aux pages. Ceux non authentifié sont prié de le faire via une redirection d’ url.

Authentification : Les données de l’utilisateur sont vérifiés auprès du PSP avant de leur donner leur autorisation. Je déconseille fortement d’utiliser le même mot de passe que sur PayPal. (à cause du Phishing) Les mots de passe des utilisateurs sont cryptés en md5 dans la base de données. Lors d’un changement des informations de l’utilisateur, une autorisation est demandé auprès du PSP pour validation. (Sécurité des données)

Filtrage des données externes : Il existe une validation des données entrantes (GET et POST). Les fichiers concernés sont : le formulaire d’inscription, le formulaire de connexion, le formulaire de modification des préférences, le formulaire de modification d’achat lors d’une commande, tout les moteurs de recherche internes, et enfin, le formulaire de contact. Les services (du PSP) sont aussi filtrés.

L’application a été testé avec CAL9000 (OWASP) pour être protégé contre certaines attaques de type Cross Site Scripting (XSS). Ce type d’attaque figure dans le Top 10 des vulnérabilités 2007 selon l’Open Web Application Security Project (OWASP).

Optimisation

Web Performance Best Practices :
– Optimize images
– Serve resources from a consistent URL
– Avoid CSS expressions
– Combine external CSS
– Specify image dimensions
– Minimize redirects
– Put CSS in the document head
– Use efficient CSS selectors

Standards

Respect des standards du W3C : a été validé XHTML 1.0 transitionnel et CSS 2.0 sous Mozilla Firefox, Internet Explorer et Safari.

Test Unitaire

Les comptes de tests sont ouvert à l’initiative des clients. Des fonds de test sont donné gratuitement par le PSP.

Passer la séries de tests suivantes : Nécessite minimum 2 utilisateurs. (Alice et Bob)
Préparatifs : Noter la situation financière existante des utilisateurs : « Solde en Euro » pour chacun d’eux.

Effectuer un achat et pour les 3 cas (inférieur, égal, supérieur), vérifier :
– Le solde de l’acheteur (Alice) a t-il diminué ?
– Le solde du récepteur (Bob) a t-il augmenté ?
– Le récepteur (Bob) a t-il été notifié par email ?

Installation du logiciel

1. Acheter un nom de domaine (maplateformedetradingdexemple.com) chez un Registrar.

2. Obtenir un hébergement contenant un espace suffisant (environ : 60 Mo) et une bande passante suffisante (plusieurs Giga) en fonction du nombre d’utilisateur prévu. (et POP3, FTP et MySQL inclus)

3. Dé-compacter les fichiers précédemment téléchargé. (procédure ci-dessus)

4. Modifier le fichier ‘scripts sql tables & champs.sql’ :
– remplacer email dans la table freepay_titre
– remplacer les informations client dans la table freepay_client

5. Créer une base de données « paybook » (sans les doubles quotes) dans votre panneau
d’administration (généralement à l’URL http://maplateformedetradingdexemple.com/phpmyadmin/)
– Créer un utilisateur et lui donner les droits d’accès à la base de données en lecture et écriture. (si ce n’est pas déjà fait automatiquement).

6. Cliquer sur l’onglet SQL, copier-coller les données du fichier ‘scripts sql tables & champs.sql’ dans le champ de saisie et cliquer sur Exécuter. Aucun message d’erreur ne doit s’afficher.

7. Modifier les valeurs par défaut par celles qui ont été fournies par l’hébergeur dans le fichier ‘params.php’ (sans les simple quotes) hôte, utilisateur, mot de passe,base de données.

8. Sur le serveur web, copier-coller la source modifié (avec les paramètres par défauts) en 7z et zip. Créer aussi un dossier /paybook/ . Importer les fichiers via un FTP (ex fireFTP, une extension de Firefox) avec les paramètres de l’hébergeur (‘params.php’) dans le répertoire précédemment crée.

9. Lancer dans le navigateur http://maplateformedetradingdexemple.com/paybook/. La page d’index doit s’afficher sans message d’erreurs. Les sources (7z et zip) doivent pouvoir être téléchargeable à partir d’un onglet ‘documentation’ ou ‘téléchargement’.

10. Référencer votre site sur les moteurs de recherche (ex : http://www.google.com/addurl/?continue=/addurl)

11. Générer un sitemap XML, et le mettre à la racine (ex : http://www.xml-sitemaps.com/ )

12. Optimiser votre site (ex: avec Google Webmaster Tools https://www.google.com/webmasters/tools )

Mon Passage de mon existant à ma finalité

Ma capacité de production

Comment satisfaire les intérêts des parties en offrant une relation gagnant-gagnant

1. La satisfaction des intérêts des Consommateurs

1.1 La satisfaction des intérêts des sites de ecommerce
  • Les e – commerçants sont content car la monnaie économisé par les clients finaux sur chaque transaction peut être réinvesti en bien et en service.
  • Cela permet de réduire les coûts de développement pour les sites de ecommerce.
  • Cela peut permettre d’accroître la visibilité des ecommerçants.
  • Cela peut permettre d’accroître la sécurité des ecommerçants.
1.2 La satisfaction des intérêts des plateformes de trading
  • Les plateforme de trading sont content car la monnaie économisé par les clients finaux sur chaque transaction peut être réinvesti en bien et en service.
  • Cela permet de réduire les coûts de développement pour les plateformes de trading.
  • Cela peut permettre d’accroître la visibilité des plateformes de trading.
  • Cela peut permettre d’accroître la sécurité des plateformes de trading.
1.3 La satisfaction des intérêts des utilisateurs finaux
  • Les clients sont satisfait parce qu’ils gagnent de l’argent chaque année et qu’ils économisent de la monnaie et de l’énergie à chaque transaction.
  • Les transactions sont gratuites et le solde du PSP de chaque utilisateur est rémunéré chaque année.
  • C’est gagnant pour l’utilisateur. C’est gagnant pour le PSP. C’est une relation gagnant-gagnant.
  • Les client finaux sont content car la monnaie économisé sur chaque transaction peut être réinvesti en bien et en service.
  • Cela permet de réduire les coûts de développement pour les utilisateurs finaux.
  • Cela peut permettre d’accroître la sécurité des utilisateurs finaux.

2. La satisfaction des intérêts des Fournisseurs

  • Le PSP a besoin de ses fournisseurs pour vivre. Donc, il reverse une partie de ses gains à ses fournisseurs. C’est donc gagnant pour les fournisseurs du PSP.
  • Cela peut permettre d’accroître la sécurité des fournisseurs.
2.1 La satisfaction des intérêts des banques
  • Cela permet d’employer et de payer les banques.
  • Cela permet de réduire les coûts de développement pour les banques.
  • Cela permet de satisfaire les fournisseurs car le capital s’accumule. Cela permet de donner de la visibilité à la banque, via sa marque de fabrique.
  • Les banques sont content car la monnaie économisé sur chaque transaction peut être réinvesti en épargne.
  • Cela peut permettre d’accroître la visibilité des banques.
  • Cela peut permettre d’accroître la sécurité des banques.
2.2 La satisfaction des intérêts des sociétés de services en logiciels
  • Cela peut permettre d’employer et de payer les sociétés de services en logiciels.
  • Cela peut permettre d’accroître la visibilité des sociétés de services en logiciels.
  • Cela peut permettre d’accroître la sécurité des sociétés de services en logiciels.
2.3 La satisfaction des intérêts des intégrateurs
  • Cela peut permettre d’employer et de payer les intégrateurs bancaire et d’ ecommerce.
  • Cela peut permettre de certifier les intégrateurs.
  • Cela peut permettre d’accroître la visibilité des intégrateurs.
  • Cela peut permettre d’accroître la sécurité des intégrateurs.

3. La satisfaction des intérêts des PSP

3.1 La satisfaction des intérêts des partenaires
  • Cela peut permettre d’accroître la visibilité des partenaires.
  • Cela peut permettre d’accroître la sécurité des partenaires.

Les partenaires ayant le même business modèle :

  • Les partenaires du PSP ont le même business modèle donc c’est gagnant pour eux aussi.
  • Cela peut permettre de satisfaire ses partenaires car ils ont accès au business plan et à tout le code (puisqu’ils ont le même business modèle.)
  • Cela peut permettre de satisfaire ses partenaires car la monnaie peut être investi dans la publicité ce qui permet au PSP d’augmenter son nombre d’utilisateurs.
  • Cela peut permettre de réduire les coûts de développement pour les partenaires.

Les partenaires n’ayant pas le même business modèle :

  • Les revendeurs bénéficie du trafic inhérent au PSP. Le trafic permet l’augmentation de leur revenu (via la publicité).
3.2 La satisfaction des intérêts des concurrents
  • Pour mes concurrents, cela permet une augmentation massive des utilisateurs et une injection massive de capitaux.
  • Le solde de chaque compte augmente tout les ans, donc le % de prélèvement augmente aussi tout en étant transparent pour l’utilisateur ex 2% de 100E fait 2E alors que 2% de 102E fait plus (2,04E)
  • Cela peut permettre de réduire les coûts de développement des concurrents.
  • Cela peut permettre d’accroître la visibilité des concurrents.
  • Cela peut permettre d’accroître la sécurité des concurrents.
3.3 La satisfaction des intérêts pour Soi même

Du point de vue sociétal :

  • Cela accroît le trafic utilisateurs (attiré par le gain) ce qui augmente d’autant plus l’argent dans les caisses. Une partie de l’argent sert pour la maintenance, l’autre pour la recherche et le développement dans d’autres domaines.
  • La monnaie du PSP, stocké dans les banques, est rémunéré au taux en vigueur : augmentant encore plus la monnaie dans les caisses.
  • Cela permet de réduire le temps et les coûts de développement. Cela peut permettre de payer d’autres personnes (l’équipe de développement).
  • Cela peut permettre d’accroître la visibilité de mon organisation. L’augmentation du nombre d’utilisateurs permet d’investir dans la publicité qui elle-même apporte de nouveaux utilisateurs.
  • Cela peut permettre d’accroître la sécurité de mon organisation.

Du point de vue personnel :

  • Cela peut permettre de se payer.
  • Cela peut permettre d’augmenter ma capacité de production.
  • Cela peut permettre d’accroître ma propre visibilité.
  • Cela peut permettre d’accroître ma propre sécurité.

L’ancien business modèle des PSP

Les prestataires de services de paiement (PSP) ont un business model qui fonctionne par les commissions (partie fixe et variable) sur les transactions de leur clients (environ 2%). Pour que leur profit augmente, ils veulent augmenter leur volume de transactions et à ce que les clients envoient de plus grosse somme.

Ma production

Pre requis

Validation technique de l’ institution financière

1. Il faut pouvoir créer un compte.

2. Approvisionnement : L’utilisateur peut approvisionner son compte avec différents moyens de
paiement (chèque, carte de crédit, transfert bancaire etc) et en retirer.

3. Il faut avoir un minimum de fonds sur son compte (solde à minimum 1 euros). (il faut aussi
prendre en compte les frais de l’institution financière)

Facultatif (mais vivement recommandé) : Agrément financier : L’institution financière doit être
agréé par au moins une autorité de régulation.

Séparation des tests et du réel : Les transferts entre client normaux et client de test sont interdits.

Validation du PSP

1. Il faut pouvoir passer un ordre sur le PSP et arriver sur la banque. (POST ou GET)

2. B2B, B2C,C2B & C2C : Il faut que les paiements fonctionne dans les 2 sens (marchand-
marchand tout en étant accessible client-client, marchand-client et client-marchand), brièvement permettre le P2P. Le droit de rétractation dépend du statu des personnes effectuant les transactions ensemble et, cela est défini sur le site de la banque.

Autrement dit, le remboursement doit être possible à la fois supérieur, inférieur ou égal.

2 bis. (optionnel : mais c’est mieux de le faire) Il faut pouvoir activer l’automatisation des
processus. (en xml)

3. XML : Il faut que le site source (marchand / PSP) puisse obtenir une trace de la transaction de la part de la banque. (xml envoyé et enregistrable dans la base de donnée dans des tables sql)