Brevet FR2821190A1 — publié le 20020823

PROCÉDÉ POUR LA GESTION DE BONS ÉLECTRONIQUES La présente invention concerne le domaine de gestion des transactions de type non bancaires. Elle se rapporte plus particulièrement au domaine de l'émission, de la gestion et du recouvrement d'effet de commerces tels que des bons ou des chèques cadeaux, des bons de remise, et plus généralement de certificats donnant lieu à un avantage commercial, sous une forme dématérialisée, au moins dans une partie du cycle d'exploitation. On connaît dans l'état de la technique le brevet PCT WO0051052 décrivant un système électronique de traitement de certificats à valeurs enregistrées dans lequel une unité de traitement de certificats délivre des certificats à valeurs enregistrées à des consommateurs en association à un cybermarchand, et rachète les certificats à un consommateur les ayant reçus en tant que valeur reçue pour des produits ou des services du marchand. Cette unité de traitement des certificats émet un certificat virtuel, graphique, à valeur enregistrée, au nom du marchand. L'unité de traitement de certificats-cadeaux à valeurs enregistrées interagit logiquement et exclusivement avec le marchand, et le marchand commande l'interaction avec le consommateur. Les marchands peuvent se servir d'un certificat de promotions pour envoyer un fichier d'adresses électroniques de consommateurs et la quantité ou la valeur de chaque certificat à l'unité de traitement des certificats-cadeaux à valeurs enregistrées. Cette dernière crée, charge et émet les certificats de promotions par courrier électronique. Un consommateur qui reçoit un certificat de promotion peut l'utiliser dans la boutique virtuelle du marchand en échange de biens et de services. Le brevet PCT WO0016227 concerne un système de certificats électroniques de remise qui distribue des certificats électroniques de remise sous forme de documents de courrier électronique comportant des hyperliens déclenchant automatiquement le processus de remboursement. Quand un bénéficiaire de certificat de remise sélectionne un tel hyperlien, l'ordinateur du bénéficiaire transmet automatiquement un code de demande au site web du commerçant, et le site répond en créditant automatiquement le compte personnel du bénéficiaire du montant indiqué par le certificat de remise. Quand le bénéficiaire fait ultérieurement un achat sur le site web du commerçant, le solde du compte du bénéficiaire est automatiquement déduit du prix d'achat. Le brevet PCT W09957670 concerne un système de traitement de données émettant des certificats électroniques par des réseaux"en ligne"d'ordinateurs personnels, de télévisions ou d'autres dispositifs équipés de moniteurs vidéo ou de téléphones. Chaque certificat électronique comporte des données de transaction et des données d'identification, et peut être imprimé sur un dispositif d'impression lie à un dispositif d'entrée personnel de consommateur, ou stocké électroniquement dans une base de données désignée jusqu'à une date d'expiration spécifiée. Le certificat peut être utilisé à des fins diverses, notamment comme coupon pour obtenir un rabais sur un produit ou un service, comme preuve de cadeau ou de prix, comme preuve de réservation, ou comme preuve de paiement. Des consommateurs accèdent au système de traitement de données en ligne, parcourent les options et font leurs sélections. Le système de traitement de données fournit des rapports concernant les certificats sélectionnés et leur utilisation après sélection. Les émetteurs de certificats ont également accès en ligne au système de traitement de données et peuvent former ou revoir des offres, et fournir diverses instructions ayant trait aux certificats, notamment des limitations quant au nombre total de certificats à émettre, et au nombre de certificats à émettre pour chaque consommateur individuel. Le brevet PCT W09705555 décrit un système de traitement de données délivrant des certificats électroniques comportant des données de transaction et des données d'identification. Il peut être imprimé sur un dispositif d'impression relié au dispositif d'entrée individuel du consommateur, ou bien être mémorisé dans une base de données jusqu'à une date d'expiration spécifiée. Ce certificat peut servir à des fins diverses. Il peut notamment servir de coupon pour un rabais sur un produit ou un service, de preuve de cadeau ou de récompense, de preuve de réservation ou de preuve de paiement. Les consommateurs accèdent en direct au système de traitement de données, explorent les diverses possibilités de choix et font leurs sélections. Le système de traitement de données fournit des rapports sur les certificats sélectionnés et leur utilisation après sélection. Les émetteurs de certificats ont eux aussi accès en direct au système de traitement de données. Ils peuvent créer des offres ou les réviser. Ils peuvent en outre produire diverses instructions concernant les certificats, notamment des limitations quant au nombre de certificats devant être émis au total et à chaque consommateur. Le brevet WO0051052 se rapporte à un système électronique de traitement de certificats à valeurs enregistrées dans lequel une unité de traitement de certificats délivre des certificats à valeurs enregistrées à des consommateurs en association à un cyber-marchand, et rachète les certificats à un consommateur les ayant reçus en tant que valeur reçue pour des produits ou des services du marchand. Cette unité de traitement des certificats émet un certificat virtuel, graphique, à valeur enregistrée, au nom du marchand. L'unité de traitement de certificats-cadeaux à valeurs enregistrées interagit logiquement et exclusivement avec le marchand, et le marchand commande l'interaction avec le consommateur. Les marchands peuvent se servir d'un certificat de promotions pour envoyer un fichier d'adresses électroniques de consommateurs et la quantité ou la valeur de chaque certificat à l'unité de traitement des certificatscadeaux à valeurs enregistrées. Cette dernière crée, charge et émet les certificats de promotions par courrier électronique. Un consommateur qui reçoit un certificat de promotion peut l'utiliser dans la boutique virtuelle du marchand en échange de biens et de services. Le but de la présente invention est de proposer une solution améliorée, permettant de conserver l'anonymat du porteur du bon électronique, et permettant d'organiser de façon souple la distribution des bons, en faisant intervenir ou non divers intermédiaires, sans pour autant changer la procédure de fabrication, d'émission et de compensation des bons. Le procédé et l'architecture selon l'invention permettent à partir d'un Extranet et de plusieurs interfaces programmatiques sécurisées mise à la disposition des émetteurs de créer, détruire, émettre, utiliser et suivre des bons d'achat de toutes sortes valables aussi bien dans des magasins virtuels (commerce électronique) que dans des magasins physiques pourvu qu'ils soient connectés à un Intranet. Il permet également une exploitation sur Internet. Selon son acception la plus générale, l'invention concerne un procédé pour la gestion de bons électroniques [bons d'achat, bons de remise, chèques cadeaux, bons de réduction, coupons promotionnels] comportant une étape fabrication d'un bon numérique comportant un identifiant unique vérifiable, une étape d'émission dudit bon numérique consistant à enregistrer dans la table d'un serveur l'identifiant du bon et la désignation de l'avantage associé audit bon, et à transmettre l'identifiant dudit bon à un utilisateur, et une étape de consommation dudit bon consistant à vérifier la validité dudit bon, à accorder l'avantage associé audit bon et à déclarer la consommation dudit bon par un marqueur dans ladite table du serveur, caractérisé en ce que l'étape d'émission de bons comporte une opération d'identification d'un émetteur de bons préalablement enregistrés par le serveur central, une opération de préparation d'une commande consistant à définir la nature et la quantité des bons à émettre, et à créer dans une mémoire du serveur une table d'enregistrement des bons créés en réponse à une requête de l'émetteur de bons identifié, et à transmettre à ce dernier un fichier signé par le serveur central avec la clé publique de l'émetteur de bons, ledit fichier contenant les identifiants créés à sa demande, et en ce que l'étape de contrôle de validité du bon est indépendante de l'identité du porteur, et en ce que la nature de l'avantage est mémorisé dans la table du serveur sous la forme d'une fonction. Avantageusement, l'étape d'enregistrement d'un émetteur consiste à fabriquer un identifiant unique de l'émetteur à enregistrer dans une table du serveur ledit identifiant, l'identification de l'émetteur, et des informations relatives aux droits d'émission accordés audit émetteur et un mot de passe pour l'accès dudit l'émetteur aux fonctionnalités du serveur. Selon une variante, l'étape d'enregistrement d'un émetteur comporte en outre une opération de transmission par l'émetteur d'un fichier numérique contenant l'identité des marchands susceptible d'accepter les bons émis, et d'enregistrement desdites identité dans ladite table. Selon un mode de réalisation particulier, il comporte une étape d'inscription d'un intermédiaire [par exemple un serveur de paiement électronique] consiste à établir une liaison sécurisée entre un poste d'un intermédiaire et le serveur central, à créer une table dans une mémoire du serveur central pour l'enregistrement d'un identifiant unique de l'intermédiaire et d'une liste des marchands transmis par ledit intermédiaire et à transmettre à l'intermédiaire un moyen d'accès à l'espace d'administration. Selon une autre variante, l'invention concerne un procédé comportant une étape d'inscription d'un marchand [par exemple un opérateur d'un site de commerce électronique] consistant à enregistrer dans une base de données du serveur central un identifiant unique du marchand, une liste des marchands affiliés, une liste des intermédiaires autorisés, et une étape de fourniture par le serveur central d'un moyen d'accès à l'espace d'administration. De préférence, le procédé comporte une étape de modélisation d'un bon comportant une première opération de vérification de l'habilitation de l'émetteur de la requête au regard des données numériques enregistrées dans les tables des intermédiaires, émetteurs et marchands, à établir une liaison sécurisée et à transmettre un formulaire pour la définition des spécificités des bons à fabriquer, et à définir les paramètres définissant l'avantage octroyé à chaque bon. Selon un mode de réalisation préféré, l'opération de définition des spécificités du bon consiste à sélectionner une forme graphique parmi une bibliothèque de formes. L'opération de définition des spécificités du bon consiste selon une variante à construire une forme graphique à l'aide d'un outil graphique permettant de dessiner et proposant une bibliothèque d'images Selon une première variante d'utilisation, le détenteur d'un bon l'utilise par la saisie de son identifiant dans un formulaire numérique transmis par le marchand, ce formulaire comprenant des moyens pour assurer une liaison entre le poste utilisateur et le serveur central, et pour la transmission d'un formulaire numérique comprenant ledit identifiant d'un bon et un identifiant du marchand et/ou de la commande en cours, le serveur central procédant à une vérification de l'authenticité de l'identifiant du bon et le cas échéant procédant au calcul du résultat de la fonction associée au bon appliquée aux informations relatives à la commande, le serveur procédant ensuite à un appel du marchand pour lui transmettre une page cachée comportant un moyen de validation de l'achat, ladite validation étant transmise au poste utilisateur sous la forme d'un formulaire comprenant des moyens pour la réalisation d'un éventuel paiement complémentaire et pour l'acquittement par l'utilisateur de la transaction par l'envoi au serveur d'un message produisant la consommation du bon. Selon une autre variante, le marchand transmet au client une page HTML contenant une rubrique de saisie d'un identifiant d'un bon, l'utilisateur transmettant sous une session sécurisée un identifiant au marchand qui procède à la vérification de la validité dudit bon auprès du serveur par l'établissement d'une session sécurisée, et transmettant à l'utilisateur une information relative à l'avantage accordé, le client procédant ensuite à la confirmation de la commande auprès du marchand qui procède à l'acquittement auprès du serveur. La présente invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation qui suit, se référant aux dessins annexés où : la figure 1 représente un exemple d'architecture la figure 2 représente le diagramme des flux concernant l'enregistrement d'un émetteur ; La figure 3 représente une variante du diagramme pour un enregistrement non connecté ; La figure 4 représente un diagramme des données pour l'enregistrement en ligne d'un intermédiaire ; La figure 5 représente une variante pour l'enregistrement d'un intermédiaire non connecté ; La figure 6 représente le diagramme des flux pour l'enregistrement en ligne d'un marchand La figure 7 représente une variante de réalisation non connectée ; La figure 8 représente le schéma de modélisation d'un bon, La figure 9 représente le modèle logique d'un bon ; La figure 10 représente le diagramme des flux pour l'émission d'un bon d'achat ; La figure 11 représente un diagramme des flux pour la réservation de bons ; La figure 12 représente un diagramme des flux pour l'émission de bons ; La figure 13 représente un diagramme des flux pour l'annulation de bons ; La figure 14 représente un diagramme des flux pour le verrouillage de bons ; La figure 15 représente un diagramme des flux pour la gestion d'une campagne de bons La figure 16 représente un diagramme des flux pour le blocage de bons ; La figure 17 représente un diagramme des flux pour le déblocage de bons ; La figure 18 représente un diagramme des flux pour le suivi en ligne de bons ; La figure 19 représente un diagramme des flux pour le blocage en ligne de bons ; La figure 20 représente un diagramme des flux pour le déblocage en ligne de bons ; La figure 21 représente le schéma de l'intégration entrante de l'API chez le marchand intermédiaire ; La figure 22 représente le schéma de l'intégration sortante de l'API chez le marchand intermédiaire ; - La figure 23 représente le schéma de l'intégration entrante de l'API chez l'intermédiaire non marchand La figure 24 représente le schéma de l'intégration sortante de l'API chez l'intermédiaire non marchand - La figure 25 représente le schéma utilisation à travers l'Extranet. Terminologie : On entendra au sens du présent brevet par : API : Interface programmatique sécurisée mise à la disposition des émetteurs, des marchands et des intermédiaires du serveur central afin de gérer et de suivre tous types de bons d'achats. Bénéficiaire : Personne physique, morale ou système informatique bénéficiant in fine des bons d'achat. Bon d'achat : Désigne toutes les applications de bons de valeur émis par un émetteur vers un destinataire et utilisables dans un environnement clos regroupant un ou plusieurs marchands. Les applications de bons de valeur comprennent, et sans que cela ne revête de caractère limitatif, les bons de réduction, avoirs, coupons, chèques cadeaux, chèques culture, chèques vacances, chèques voyage, chèques santé, chèques services, tickets restaurant, portemonnaies virtuels, cartes de paiement virtuelles, portemonnaies pour enfants, compte points de fidélité. Campagne : Série de bons d'achat ayant les mêmes caractéristiques et émis au même moment. Destinataire : Personne physique, morale ou système informatique destinataire d'un bon d'achat. Emetteur : Personne physique, morale, collectivités ou système informatique utilisant les services du serveur afin d'émettre des bons d'achat électroniques ou non. Extranet : Application Internet sécurisée mise à la disposition des émetteurs, des marchands et des intermédiaires du serveur afin de gérer et de suivre tous types de bons d'achats. HTML : Langage de description de page Hyper text mark-up language HTTP : Hyper text transfer protocol Intermédiaire : Système informatique ou électronique permettant la médiation entre les services et les bénéficiaires de bons d'achat. Marchand : Personne physique, morale ou système informatique chez qui les bénéficiaires de bon d'achat utilisent leurs bons. Modèle : Représentation graphique et logique d'un bon d'achat sous une forme XML. Partenaire : Emetteur, Marchand ou Intermédiaire. Règle de consommation : Fonction continue ou discrète permettant à l'application de résoudre la validité d'un bon d'achat ainsi que de calculer le bénéfice apporté par un bon d'achat à un bénéficiaire (ie : le montant de la réduction). SSL : Secured socket layer URL : Uniform resource locator XML : Extended mark-up language L'invention concerne une application mettant en jeu un certain nombre de processus entre les différents partenaires : les émetteurs de bons d'achat, les destinataires de bons d'achat, les marchands chez qui les bons d'achat peuvent être utilisés, et les intermédiaires qui tiennent lieu de médiateur entre les marchands et le serveur de gestion des bons lors de la transaction de paiement. Les émetteurs ont accès à l'Extranet ainsi qu'à des API Internet et Intranet afin de gérer, émettre et suivre des bons d'achat. Les destinataires sont transparents pour l'application et sont en fait les interlocuteurs directs des émetteurs. Ils reçoivent des bons d'achat et peuvent les verrouiller à l'aide d'une URL fournie aux différents émetteurs. Les intermédiaires intègrent l'API Internet ou Intranet afin de permettre l'utilisation des bons d'achat par des clients finaux. Les marchands ont accès à l'Extranet ainsi qu'à des API Internet et Intranet afin de mettre en oeuvre l'utilisation d'un bon d'achat. Dans l'exemple représenté en figure 1, l'émetteur accède à l'Extranet, l'intermédiaire est le serveur électronique de paiement du site de commerce électronique tandis que le marchand est le site de commerce électronique ou le magasin virtuel qui intègre une API au sein de son extranet. La figure 2 représente un schéma de l'opération d'enregistrement d'un émetteur. Un émetteur potentiel de bon d'achat (ie : un vendeur de chèques cadeaux) se connecte au site Internet du serveur et envoi par l'intermédiaire d'un formulaire HTTP une requête pour un contact commercial. L'application génère automatiquement un mail à destination des forces commerciales contenant les informations données par l'émetteur sur le site Internet du serveur. Un contact commercial est établi et découle sur une proposition commerciale et un contrat. Une fois le contrat approuvé et signé par les parties, le serveur enregistre dans sa base de données les informations commerciales relatives à l'émetteur : Identification de l'émetteur, Types de bons d'achat autorisé à émettre, Tarifs négociés, Liste des marchands avec lesquels l'émetteur à signé des contrats pour la compensation des bons qu'il émet. Conditions particulières relatives à ces contrats (ie : limitation en terme de produits, dates de validité, etc). Le serveur génère alors un identifiant partenaire, un identifiant administrateur de l'Extranet ainsi que le mot de passe associé. Ces informations sont transmises sous le couvert de la confidentialité à l'émetteur. La figure 3 représente une variante du diagramme pour un enregistrement non connecté. Un contact commercial classique entre le serveur et un émetteur de bon d'achat (ie : un vendeur de chèques cadeaux) découle sur une proposition commerciale et un contrat. Une fois le contrat approuvé et signé par les parties, le serveur enregistre dans sa base de données les informations commerciales relatives à l'émetteur : Identification de l'émetteur, Types de bons d'achat autorisé à émettre, Tarifs négociés, Liste des marchands avec lesquels l'émetteur à signé des contrats pour la compensation des bons qu'il émet. - Conditions particulières relatives à ces contrats (ie : limitation en terme de produits, dates de validité, etc). Le serveur génère alors un identifiant partenaire, un identifiant administrateur de l'Extranet ainsi que le mot de passe associé. Ces informations sont transmises sous le couvert de la confidentialité à l'émetteur. La figure 4 représente un diagramme des données pour l'enregistrement en ligne d'un intermédiaire. Un intermédiaire potentiel (ie : un serveur de paiement électronique) se connecte au site Internet du serveur et envoie par l'intermédiaire d'un formulaire HTTP une requête pour un contact commercial. L'application génère automatiquement un mail à destination des forces commerciales contenant les informations données par l'intermédiaire sur le site Internet. Un contact commercial est établi et découle sur une proposition commerciale et un contrat. Une fois le contrat approuvé et signé par les parties, le serveur enregistre dans sa base de données les informations commerciales relatives à l'intermédiaire : Identification de l'intermédiaire, Tarifs négociés, Liste des marchands pour lesquels l'Intermédiaire s'occupe de la médiation avec le serveur. - Conditions particulières relatives à ces contrats (ie : limitation en terme de produits, dates de validité, etc). Le serveur génère alors un identifiant partenaire, un identifiant administrateur de l'Extranet ainsi que le mot de passe associé. Ces informations sont transmises sous le couvert de la confidentialité à l'intermédiaire. La figure 5 représente une variante pour l'enregistrement d'un intermédiaire non connecté. Un contact commercial classique entre le serveur et un intermédiaire (ie : un serveur de paiement électronique) découle sur une proposition commerciale et un contrat. Une fois le contrat approuvé et signé par les parties, le serveur enregistre dans sa base de données les informations commerciales relatives à l'intermédiaire : Identification de l'intermédiaire, Tarifs négociés, Liste des marchands pour lesquels l'Intermédiaire s'occupe de la médiation avec le serveur. Conditions particulières relatives à ces contrats (ie : limitation en terme de produits, dates de validité, etc). Le serveur génère alors un identifiant partenaire, un identifiant administrateur de l'Extranet ainsi que le mot de passe associé. Ces informations sont transmises sous le couvert de la confidentialité à l'intermédiaire. La figure 6 représente le diagramme des flux pour l'enregistrement en ligne d'un marchand. Un marchand potentiel (ie : un site de commerce électronique) se connecte au site Internet de et envoie par l'intermédiaire d'un formulaire HTTP une requête pour un contact commercial. L'application génère automatiquement un mail à destination des forces commerciales contenant les informations données par le marchand sur le site Internet du serveur. Un contact commercial est établi et découle sur une proposition commerciale et un contrat. Une fois le contrat approuvé et signé par les parties, le serveur enregistre dans sa base de données les informations commerciales relatives au marchand : Identification du marchand, Tarifs négociés, Types de bons d'achat autorisé à compenser, Liste des émetteurs avec lesquels le marchand à signé des contrats pour la compensation des bons qu'ils émettent. Liste des intermédiaires que le marchand désire utiliser afin de s'occuper de la médiation avec le serveur. - Conditions particulières relatives à ces contrats (ie : limitation en terme de produits, dates de validité, etc). Le serveur génère alors un identifiant partenaire, un identifiant administrateur de l'Extranet ainsi que le mot de passe associé. Ces informations sont transmises sous le couvert de la confidentialité au marchand. La figure 7 représente une variante de réalisation non connectée. Un contact commercial classique entre le serveur et un marchand (ie : un site de commerce électronique) découle sur une proposition commerciale et un contrat. Un contact commercial est établi et découle sur une proposition commerciale et un contrat. Une fois le contrat approuvé et signé par les parties, le serveur enregistre dans sa base de données les informations commerciales relatives au marchand : Identification du marchand, Tarifs négociés, Types de bons d'achat autorisés à compenser, Liste des émetteurs avec lesquels le marchand à signé des contrats pour la compensation des bons qu'ils émettent. Liste des intermédiaires que le marchand désire utiliser afin de s'occuper de la médiation avec du serveur. - Conditions particulières relatives à ces contrats (ie : limitation en terme de produits, dates de validité, etc). Le serveur génère alors un identifiant partenaire, un identifiant administrateur de l'Extranet ainsi que le mot de passe associé. Ces informations sont transmises sous le couvert de la confidentialité au marchand. La figure 8 représente le schéma de modélisation d'un bon. Un émetteur de bon d'achat se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est modélisation , l'application donne accès à l'application Extranet de modélisation de bon d'achat. L'émetteur peut créer un modèle de bon d'achat grâce à un Applet permettant : De définir les caractéristiques du bon d'achat : définition d'un nom, du type du bon d'achat et des contrats marchands auxquels ils se rapportent. De définir le graphisme du bon d'achat : définition au sens Java du terme (classe GRAPHICS) d'un fond, ajout d'images et de textes, leurs positions, taille, couleurs, styles et formats respectifs). De définir la logique du bon d'achat : définition de la règle de consommation suivant la logique représenté en figure 9. Une règle de consommation est une fonction définie par N règles contenant chacune X conditions. Une règle est remplie si ses X conditions sont remplies. Si une règle est remplie, elle donne droit à un montant de réduction en valeur fixe ou en pourcentage ou en points. Si plusieurs règles sont remplies, la plus avantageuse pour le bénéficiaire est considérée. L'Applet se charge aussi de transformer le modèle de bon d'achats dans le format XML afin de le transférer au back office du serveur. L'annexe 1 représente un modèle de bon, et l'annexe 2 représente un exemple de message XML. L'application vérifie les informations fournies et enregistre le modèle dans la base de données afin de finaliser le processus de création d'un modèle par Extranet. Seules les caractéristiques et la logique du modèle sont indispensables afin de générer un modèle de bon d'achat. Une règle de consommation peut aussi ne pas contenir du tout de condition d'utilisation, mais doit impérativement comporter un montant. Dans une deuxième déclinaison : L'émetteur peut choisir dans une seconde option de se connecter avec un niveau de sécurité plus élevé grâce à l'utilisation de certificats client SSL mettant en oeuvre une identification forte entre l'application back office et le serveur client ou le client en tant que tel. Cette identification se fait par l'intermédiaire de certificats hébergés sur le serveur client ou sur des cartes à puce. Utilisation de modèles externes Dans le cas de l'utilisation de modèles externes distribués par exemple sous une forme papier propre à l'émetteur, un modèle à minima de bon d'achat doit être construit afin de prendre en compte uniquement les caractéristiques et la logique du modèle. Le processus à suivre est alors le même que dans le cas précédant. La figure 10 représente le diagramme des flux pour l'émission d'un bon d'achat. Cas standard : Un émetteur de bon d'achat se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est émission de bon ou émission de campagne , l'application donne accès à l'application Extranet d'émission de bon d'achat. L'émetteur peut émettre des bons d'achats ou des campagnes de bons d'achat grâce à l'Extranet permettant de : Choisir d'émettre des bons simples (nombre faible de bons d'achat d'un même type) ou des campagnes (grand nombre de bons d'achat d'un même type). - Définir le type des bons ou des campagnes émis en choisissant un modèle de bon d'achat précédemment défini selon les procédures ci- dessus. - Définir le nombre de bons d'achat à émettre. - Définir les dates de validités de ces bons ou campagnes. Le back office vérifie les informations fournies et décode le modèle XML utilisé. Le back office construit la représentation graphique du bon d'achat (. GIF, JPEG, etc) à partir de la représentation XML du modèle. Le back office construit la représentation logique du bon d'achat à partir de la représentation XML du modèle. Le back office génère les identifiant sécurisés uniques (à partir d'un stock de numéros de série uniques prégénérés et équirépartis) de chacun des bons d'achat, crée les bons d'achats en temps réel dans la base de données ou crée les campagnes en différé dans la base de données. Le back office renvoie à l'émetteur un fichier contenant la liste des numéros sécurisés uniques de chacun des bons d'achat ainsi que la représentation graphique du modèle utilisé. Dans une deuxième déclinaison : L'émetteur peut demander dans une seconde option au serveur d'envoyer par message électronique à sa place les bons d'achat émis. Dans ces conditions l'émetteur doit fournir les informations supplémentaires suivantes : La date de l'envoi, - La liste des destinataires des bons d'achat soit sous la forme d'un formulaire HTTP s'il n'y a qu'un seul destinataire ; soit sous la forme d'un message électronique avec un fichier-texte attaché contenant la liste d'adresses de messagerie électronique dans le cas de plusieurs destinataires (cas classique de campagne). Le back office se charge alors d'émettre tous les mails vers les différents destinataires. Ces mails contiennent une représentation graphique du bon d'achat et son numéro sécurisé unique. Dans une troisième déclinaison : L'émetteur peut demander dans une troisième option au serveur d'envoyer par lettre à sa place les bons d'achat émis. Dans ces conditions l'émetteur doit fournir les informations supplémentaires suivantes : La date de l'envoi, La liste des destinataires des bons d'achat soit sous la forme d'un formulaire HTTP s'il n'y à qu'un seul destinataire ; soit sous la forme d'un message électronique avec un fichier texte attaché contenant la liste d'adresses postales dans le cas de plusieurs destinataires (cas classique de campagne). Le back office se charge alors d'émettre toutes les lettres vers les différents destinataires. Ces lettres contiennent une représentation graphique du bon d'achat et son numéro sécurisé unique. Dans une quatrième déclinaison : L'émetteur peut demander dans une quatrième option à d'envoyer par message électronique à sa place les bons d'achat émis sur une liste ciblée de prospects. Dans ces conditions l'émetteur doit fournir les informations supplémentaires suivantes : La date de l'envoi, La liste des profils prospects ciblés. Le back office se charge alors d'émettre tous les messages électroniques vers les différents destinataires. Ces mails contiennent une représentation graphique du bon d'achat et son numéro sécurisé unique. Dans une cinquième déclinaison : L'émetteur peut demander dans une cinquième option au serveur d'envoyer par lettre à sa place les bons d'achat émis sur une liste ciblée de prospects. Dans ces conditions l'émetteur doit fournir les informations supplémentaires suivantes : La date de l'envoi, La liste des profils prospects ciblés. Le back office se charge alors d'émettre toutes les lettres vers les différents destinataires. Ces lettres contiennent une représentation graphique du bon d'achat et son numéro sécurisé unique. Dans une sixième déclinaison : L'émetteur peut choisir dans une sixième option de se connecter avec un niveau de sécurité plus élevé de par l'utilisation de certificats client SSL mettant en oeuvre une identification forte entre l'application back office et le serveur client ou le client en tant que tel. Cette identification se fait par l'intermédiaire de certificats hébergés sur le serveur client ou sur des carte à puce. Dans une septième déclinaison : L'émetteur peut choisir dans une septième option, de générer des campagnes de bons d'achat ayant tous le même numéro sécurisé afin de faciliter les distributions papier. Ce numéro possédera au choix un nombre limité ou infini d'utilisations. Dans une seconde déclinaison de l'émission de bons d'achat, l'émetteur utilise l'API Internet afin de générer des ordres : De réservation de bons d'achat ou de campagnes, D'émission de bons d'achat ou de campagnes, D'annulation de bons d'achat ou de campagnes. La figure 11 représente un diagramme des flux pour la réservation de bons. Un émetteur de bon d'achat se connecte au back office à l'aide de l'API en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiants et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est émission de bon ou émission de campagne , l'application donne accès aux fonctionnalités de l'API d'émission de bon d'achat (réponse OK). L'émetteur peut réserver des bons d'achats ou des campagnes de bons d'achat grâce à l'API permettant de : Choisir de réserver des bons simples (nombre faible de bons d'achat d'un même type) ou des campagnes (grand nombre de bons d'achat d'un même type). Définir le type des bons ou des campagnes réservés en choisissant un modèle de bon d'achat précédemment défini selon les procédures ci-dessus. - Définir le nombre de bons d'achat à réserver. - Définir les dates de validités de ces bons ou campagnes. Le back office vérifie les informations fournies et décode le modèle XML utilisé. Le back office construit la représentation graphique du bon d'achat (. GIF, JPEG, etc) à partir de la représentation XML du modèle. Le back office construit la représentation logique du bon d'achat à partir de la représentation XML du modèle. Le back office génère les identifiant sécurisés uniques (à partir d'un stock de numéros de série uniques prégénérés et équirépartis) pour chacun des bons d'achat, crée les bons d'achats en temps réel dans la base de données ou crée les campagnes en différé dans la base de données. Le back office répond à l'émetteur la liste des numéros réservés. La figure 12 représente un diagramme des flux pour l'émission de bons Un émetteur de bon d'achat se connecte au back office à l'aide de l'API en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est émission de bon ou émission de campagne , l'application donne accès aux fonctionnalités de l'API d'émission de bon d'achat (réponse OK). L'émetteur peut émettre des bons d'achats ou des campagnes de bon d'achat grâce à l'API permettant d'émettre un bon d'achat ou une campagne précédemment réservé. Le back office vérifie les informations fournies et met à jour la base de données. Le back office répond à l'émetteur la liste des numéros émis. La figure 13 représente un diagramme des flux pour l'annulation de bons. Un émetteur de bon d'achat se connecte au back office à l'aide de l'API en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est émission de bon ou émission de campagne , l'application donne accès aux fonctionnalités de l'API d'émission de bon d'achat (réponse OK). L'émetteur peut annuler des bons d'achats ou des campagnes de bons d'achat grâce à l'API permettant d'annuler un bon d'achat ou une campagne précédemment réservé. Le back office vérifie les informations fournies et met à jour la base de données. Le back office répond à l'émetteur la liste des numéros annulés. Emission à travers un Intranet magasin Dans une troisième déclinaison de l'émission de bons d'achat, l'émetteur utilise différentes API fournies par le serveur pour se connecter avec des EAI Intranet du marché afin de générer des ordres : . De réservation de bons d'achat ou de campagnes, D'emission de bons d'achat ou de campagnes, D'annulation de bons d'achat ou de campagnes. Le processus à suivre est alors le même que dans le cas précédant. Utilisation de nomenclature d'émission externes Dans une quatrième déclinaison de l'émission de bons d'achat, l'émetteur utilise l'Extranet, l'API Internet ou les différentes API Intranet afin de gérer l'émission de bons d'achat dont les numéros uniques lui sont propres. Le processus est alors le même que dans les cas précédents sauf que l'émetteur doit fournir en sus lors de la réservation ou de l'émission une liste de numéros de bons d'achat uniques en ce qui le concerne. La figure 14 représente un diagramme des flux pour le verrouillage de bons. Dans une déclinaison le destinataire d'un bon d'achat ou tout autre personne ayant en sa possession un bon d'achat peut choisir de verrouiller l'utilisation d'un bon d'achat par un mot de passe. L'émetteur doit fournir une URL mise en oeuvre par le serveur au destinataire du bon émis. Le destinataire se connecte à cette URL, entre son numéro de bon ainsi qu'un mot de passe permettant de verrouiller l'utilisation de ce bon d'achat (voir les déclinaisons des processus d'utilisation d'un bon d'achat). o Suivi d'un bon d'achat Suivi en ligne par l'Extranet L'émetteur, le marchand ou l'intermédiaire utilisent l'Extranet afin de : * Obtenir l'état d'un bon d'achat ou d'une campagne. * Bloquer l'utilisation d'un bon d'achat ou d'une campagne. 'Débloquer l'utilisation d'un bon d'achat ou d'une campagne. La figure 15 représente un diagramme des flux pour la gestion d'une campagne de bons ; Un émetteur de bon d'achat, un marchand ou un intermédiaire se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. L'émetteur peut suivre ses bons d'achats ou ses campagnes de bons d'achat, l'intermédiaire ou le marchand peuvent suivre leurs bons d'achats grâce à l'Extranet permettant de : 'Choisir un bon d'achat ou une campagne de bons d'achat à détailler. 'Utiliser des critères de choix afin de sélectionner un bon d'achat ou une campagne. Le back office vérifie les informations fournies et décode soit le modèle XML utilisé, soit le modèle de données du bon d'achat ou de la campagne. Le back office construit la représentation graphique du bon d'achat ou de la campagne (. GIF, JPEG, etc) à partir de la représentation XML du modèle. Le back office construit la représentation logique du bon d'achat ou de la campagne à partir de la base de données. Le back office construit les caractéristiques du bon d'achat ou de la campagne à partir de la base de données. La figure 16 représente un diagramme des flux pour le blocage de bons Un émetteur de bon d'achat se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. L'émetteur peut bloquer ses bons d'achats ou ses campagnes de bons d'achat grâce à l'Extranet permettant de : * Choisir un bon d'achat ou une campagne de bons d'achat à bloquer. * Utiliser des critères de choix afin de sélectionner un bon d'achat ou une campagne. Le back office vérifie les informations fournies et met à jour la base de données. La figure 17 représente un diagramme des flux pour le déblocage de bons Un émetteur de bon d'achat se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. L'émetteur peut débloquer ses bons d'achats ou ses campagnes de bons d'achat grâce à l'Extranet permettant de : Choisir un bon d'achat ou une campagne de bons d'achat à débloquer. Utiliser des critères de choix afin de sélectionner un bon d'achat ou une campagne. Le back office vérifie les informations fournies et met à jour la base de données. Dans une deuxième déclinaison : L'émetteur, le marchand ou l'intermédiaire peuvent choisir dans une deuxième option de se connecter avec un niveau de sécurité plus élevé de par l'utilisation de certificats client SSL mettant en oeuvre une identification forte entre l'application back office et le serveur client ou le client en tant que tel. Cette identification se fait par l'intermédiaire de certificats hébergés sur le serveur client ou sur des cartes à puce. Suivi en ligne par l'API L'émetteur, le marchand ou l'intermédiaire utilisent l'API Internet afin de : obtenir l'état d'un bon d'achat ou d'une campagne. Bloquer l'utilisation d'un bon d'achat ou d'une campagne. Débloquer lutilisation d'un bon d'achat ou d'une campagne. La figure 18 représente un diagramme des flux pour le suivi en ligne de bons. Un émetteur de bon d'achat, un marchand ou un intermédiaire se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiants et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. * L'émetteur peut suivre ses bons d'achats ou ses campagnes de bons d'achat, l'intermédiaire ou le marchand peuvent suivre leurs bons d'achats grâce à l'Extranet permettant de : * Choisir un bon d'achat ou une campagne de bons d'achat à détailler. 'Utiliser des critères de choix afin de sélectionner un bon d'achat ou une campagne. Le back office vérifie les informations fournies et décode soit le modèle XML utilisé, soit le modèle de données du bon d'achat ou de la campagne. Le back office construit la représentation graphique du bon d'achat ou de la campagne (. GIF, JPEG, etc) à partir de la représentation XML du modèle. Le back office construit la représentation logique du bon d'achat ou de la campagne à partir de la base de données. Le back office construit les caractéristiques du bon d'achat ou de la campagne à partir de la base de données. Un émetteur de bon d'achat se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiants et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. L'émetteur peut bloquer ses bons d'achats ou ses campagnes de bons d'achat grâce à l'Extranet permettant de : * Choisir un bon d'achat ou une campagne de bons d'achat à bloquer. * Utiliser des critères de choix afin de sélectionner un bon d'achat ou une campagne. Le back office vérifie les informations fournies et met à jour la base de données. La figure 19 représente un diagramme des flux pour le blocage en ligne de bons Un émetteur de bon d'achat se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. L'émetteur peut débloquer ses bons d'achats ou ses campagnes de bons d'achat grâce à l'Extranet permettant de : * Choisir un bon d'achat ou une campagne de bons d'achat à débloquer. * Utiliser des critères de choix afin de sélectionner un bon d'achat ou une campagne. Le back office vérifie les informations fournies et met à jour la base de données. La figure 20 représente un diagramme des flux pour le déblocage en ligne de bons Suivi à travers un Intranet magasin Dans une troisième déclinaison du suivi de bons d'achat, l'émetteur, le marchand ou l'intermédiaire utilise différentes API fournies par le serveur pour se connecter avec des EAI Intranet du marché afin de générer des ordres : De suivi de bons d'achat ou de campagnes, De blocage de bons d'achat ou de campagnes, De déblocage de bons d'achat ou de campagnes. Le processus à suivre est alors le même que dans le cas précédant. Rapports de suivi périodiques, cas standard : Régulièrement ou à la demande, le back office fournit un certain nombre de rapports aux différents partenaires. Ces rapports sont envoyés par mails aux personnes en charge du suivi des bons d'achat et campagnes. L'application de génération de rapports différés permet pour chaque partenaire de : * Donner des informations sur les bons d'achat et certificats créés depuis le dernier rapport, 'Donner les bons d'achat utilisés depuis le dernier rapport ainsi que le montant de la réduction accordé et le montant total de la transaction. L'identifiant de la commande, celui du marchand, de l'émetteur et de l'intermédiaire et éventuellement celui du client sont fournis. 4 champs sont mis à la disposition des partenaires afin que le serveur leur fournisse des informations personnalisées à définir à l'avance. Utilisation d'un bon d'achat Utilisation en ligne par l'API L'API en ligne permet à un client final d'utiliser ses bons d'achat sur un site de commerce électronique. Le serveur met en oeuvre une API Internet permettant au différents intermédiaires (marchands ou non) de s'intégrer avec l'application back office. Cette API permet de construire, lire, encoder et décoder les paramètres HTTP nécessaires à l'interrogation de l'application back office ainsi qu'à la lecture des réponses qu'elle fournit. Quatre procédures principales sont à prendre en compte lors de l'intégration d'un intermédiaire avec le back office à travers l'API Internet : * Le calcul de la réduction offerte par un bon d'achat et son authentification, 'La confirmation de l'utilisation d'un bon d'achat, 'L'acquisition de l'identifiant de la transaction chez l'intermédiaire (numéro de commande, numéro de la transaction bancaire, etc), * La confirmation de la consommation finale du bon d'achat après paiement. Ces procédures peuvent être soit lancées indépendamment les unes des autres, soit être regroupées avant l'interrogation du back office. Il existe quatre principales déclinaisons de l'intégration de l'API Internet : L'intégration entrante de l'API en ligne chez le marchand qui joue le rôle d'intermédiaire, L'intégration sortante de l'API en ligne chez le marchand qui joue le rôle d'intermédiaire, L'intégration entrante de l'API en ligne chez un intermédiaire non marchand (type serveur de paiement électronique), L'intégration sortante de l'API en ligne chez un intermédiaire non marchand (type serveur de paiement électronique). L'intégration entrante n'effectue aucune requête sortante à partir du site de commerce électronique ou du site de l'intermédiaire tandis que l'intégration sortante effectue uniquement des requêtes sortantes afin de contacter la plateforme. Les déclinaisons de l'intégration entrante et sortante peuvent être mélangées afin que certaines requêtes soient sortantes et d'autres entrantes sur une même plateforme marchande. Il est aussi à noter que si nécessaire les différentes procédures (calcul, confirmation, acquisition du numéro de commande et consommation) peuvent être fusionnées si nécessaires. La figure 21 représente le schéma de l'intégration entrante de l'API chez le marchand intermédiaire. Lors de la première étape, le client final finalise son achat sur le site marchand. En général cela se traduit par l'affichage du panier et du prix de la transaction. Ensuite, le serveur marchand en charge d'afficher le panier du client final doit pouvoir aussi : 'Générer le message XML nécessaire au back office pour effectuer la procédure de calcul et d'autorisation. 'Générer le code HTML nécessaire à la saisie éventuelle d'un numéro de bon d'achat et optionnellement du mot de passe associé. Ces informations seront nécessaires pour lancer les procédures de calcul et autorisation. * vérifier si un précédant appel d'une procédure de calcul au back office n'a pas eu lieu (vérification des paramètres HTTP par exemple). * Dans le cas où un précédant appel aurait eu lieu, décoder le message XML et vérifier le code retour (succès ou échec). * En cas d'échec, générer le code HTML nécessaire à l'affichage de la raison de l'erreur. 'En cas de succès, générer le message XML nécessaire au back office pour effectuer la procédure de confirmation. En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction ainsi qu'à la validation de l'utilisation du bon qui déclenche la procédure de confirmation. Le client final peut au choix : * Entrer un numéro de bon d'achat ainsi que le mot de passe éventuellement associé et demander le calcul de la réduction et l'authentification de ce bon d'achat. * Valider sa commande qui peut éventuellement déjà inclure une réduction précédemment calculée, et demander le paiement. Le numéro de bon d'achat et son éventuel mot de passe sont transmis au back office en SSL. Le back office : Lit les paramètres HTTP reçus. Décode le paramètre correspondant au message XML. Vérifie la cohérence des informations reçues avec la base de données. Calcul la réduction en utilisant la fonction associé au bon d'achat (règle de consommation). Met en place une session sécurisée (génération d'un numéro de session). Construit la réponse XML. Lit les paramètres propriétaires du marchand et les utilise afin de générer l'URL de réponse. Construit le code HTML nécessaire à la redirection du résultat vers le serveur marchand. Cette page invisible est la page précédemment générée par le back office afin d'appeler le serveur marchand et de lui retransmettre son cookie et ses paramètres de façon transparente tout en lui fournissant le résultat du calcul et de l'authentification. Le back office : * Lit les paramètres HTTP reçus. * Décode le paramètre correspondant au message XML. * Vérifie le numéro de session afin de l'authentifier. * Met à jour la base de données afin de bloquer le bon jusqu'à la réception de la requête de confirmation de la consommation (OK ou KO). * Construit la réponse XML. * Lit les paramètres propriétaires du marchand et les utilise afin de générer l'URL de réponse. "Construit le code HTML nécessaire à la redirection du résultat vers le serveur marchand. Cette page invisible est la page précédemment générée par le back office afin d'appeler le serveur marchand et de lui retransmettre son cookie et ses paramètres de façon transparente tout en lui fournissant le résultat de la confirmation. Le serveur marchand en charge d'afficher la commande du client final et de demander le paiement doit pouvoir aussi : 'Vérifier si un précédant appel d'une procédure de confirmation au back office n'a pas eu lieu (vérification des paramètres HTTP par exemple). * Dans le cas où un précédant appel aurait eu lieu, décoder le message XML et vérifier le code retour (succès ou échec). * En cas de succès, générer le message XML nécessaire au back office pour effectuer la procédure d'acquisition de numéro de commande. En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction ainsi qu'au transfert du numéro de la commande. Le client déclenche le paiement. Cette page HTML envoie aussi de façon transparente le paramètre XML nécessaire au back office afin d'acquérir le numéro de commande. Le back office : 'Lit les paramètres HTTP reçus. * Décode le paramètre correspondant au message XML. 'Vérifie le numéro de session afin de l'authentifier. * Met à jour la base de données avec le numéro de commande. * Met à jour la base de données afin de préparer la procédure de consommation (procédure déportée à l'origine du back office et à destination du serveur marchand). * Le serveur électronique de paiement effectue une procédure de paiement classique. La procédure déportée de consommation est déclenchée quelques minutes après la procédure confirmation. Elle permet d'interroger le serveur marchand et de lui demander le résultat du paiement complémentaire si nécessaire. Le back office : * Vérifie le temps passé depuis l'acquisition du numéro de commande. * Si ce temps est supérieur à un seuil, il vérifie le nombre d'essais effectués pour ce numéro de commande. 'Si ce nombre d'essais est supérieur à un seuil, l'état du bon d'achat concerné est remis à son état initial d'avant utilisation. 'S'il est inférieur, il construit le paramètre XML nécessaire à la confirmation de la consommation auprès du site marchand. * Appel HTTP du site marchand avec les paramètres précédemment calculés. Le serveur marchand en charge de la réception des informations de paiement (ou tout autre serveur marchand) doit pouvoir aussi : Recevoir la requête HTTP de consommation du back office. 'Lire les paramètre HTTP. * Décoder le message XML de confirmation de consommation. * Récupérer de sa base de données les informations de paiement relatives au paiement complémentaire concernant le numéro de commande relatif à la requête. * Générer le paramètre XML nécessaire à l'envoie de la réponse au back office. * Renvoyer le résultat sous forme d'une redirection HTTP.. Le back office : Lit les paramètre HTTP. Décoder le paramètre XML de réponse à une procédure de consommation. Met à jour l'état du bon dans la base de données à consommé ou partiellement consommé si OK ou remet l'état à son état initial d'avant utilisation si KO. La figure 22 représente le schéma de l'intégration sortante de l'API chez le marchand intermédiaire Le client final finalise son achat sur le site marchand. En général cela se traduit par l'affichage du panier et du prix de la transaction. 'Le serveur marchand en charge d'afficher le panier doit pouvoir aussi : 'Générer le code HTML nécessaire à la saisie éventuelle d'un numéro de bon d'achat et optionnellement du mot de passe associé. Ces informations seront nécessaires pour lancer les procédures de calcul et autorisation. 'Le client final peut au choix : * Entrer un numéro de bon d'achat ainsi que le mot de passe éventuellement associé et demander la calcul de la réduction et l'authentification de ce bon d'achat. ' Valider sa commande qui peut éventuellement déjà inclure une réduction précédemment calculée, et demander le paiement. Le numéro de bon d'achat et son éventuel mot de passe sont transmis au serveur marchand en SSL Le serveur marchand en charge d'afficher le panier avec la réduction du client final doit pouvoir aussi : e Générer le message XML nécessaire au back office pour effectuer la procédure de calcul et d'autorisation. # Appeler le back office afin de mettre en oeuvre la procédure de calcul et d'autorisation. 'Décoder le message XML et vérifier le code retour (succès ou échec). 'En cas d'échec, générer le code HTML nécessaire à l'affichage de la raison de l'erreur. * En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction. * Générer le code HTML nécessaire à la saisie éventuelle d'un numéro de bon d'achat et optionnellement du mot de passe associé.- Ces informations seront nécessaires pour lancer les procédures de calcul et autorisation. Le numéro de bon d'achat et son éventuel mot de passe sont transmis au back office en SSL. Le back office : Lit les paramètres HTTP reçus. Décode le paramètre correspondant au message XML. 'Vérifie la cohérence des informations reçues avec la base de données. * Calcul la réduction en utilisant la fonction associé au bon d'achat (règle de consommation). * Met en place une session sécurisée (génération d'un numéro de session). * Construit la réponse XML. * Lit les paramètres propriétaires du marchand et les utilise afin de générer l'URL de réponse. . Répond au serveur marchand en redirigeant l'appel HTTP. Le serveur marchand en charge d'afficher la commande du client final et de demander le paiement doit pouvoir aussi : Générer le message XML nécessaire au back office pour effectuer la procédure de confirmation. * Appeler le back office afin de mettre en oeuvre la procédure de confirmation. * Décoder le message XML et vérifier le code retour (succès ou échec). "En cas d'échec, générer le code HTML nécessaire à l'affichage de la raison de l'erreur. 'En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction. * En cas de succès, générer le message XML nécessaire au back office pour effectuer la procédure d'acquisition de numéro de commande. * Appeler le back office afin de mettre en oeuvre la procédure d'acquisition du numéro de commande. Le back office : 'Lit les paramètres HTTP reçus. # Décode le paramètre correspondant au message XML. 'Vérifie le numéro de session afin de l'authentifier. * Met à jour la base de données afin de bloquer le bon jusqu'à la réception de la requête de confirmation de la consommation (OK ou KO). * Construit la réponse XML. 'Lit les paramètres propriétaires du marchand et les utilise afin de générer l'URL de réponse. * Répond au serveur marchand en redirigeant l'appel HTTP. Le back office : 'Lit les paramètres HTTP reçus. * Décode le paramètre correspondant au message XML. 'Vérifier le numéro de session afin de l'authentifier. * Met à jour la base de données avec le numéro de commande. * Met à jour la base de données afin de préparer la procédure de consommation (procédure déportée à l'origine du back office et à destination du serveur marchand). * Répond classiquement au serveur marchand (réponse OK http). Le client déclenche le paiement. Le serveur électronique de paiement effectue une procédure de paiement classique. Le serveur marchand en charge de la réception des informations de paiement (ou tout autre serveur marchand) doit pouvoir aussi : . Récupérer de sa base de données les informations de paiement relatives au paiement complémentaire concernant le numéro de commande relatif à la transaction. "Générer le paramètre XML nécessaire à l'envoie de la requête au back office. * Envoyer la requête au serveur sous forme d'une URL HTTP. Le back office : # Lit les paramètre HTTP. # Décode le paramètre XML de la procédure de consommation. * Met à jour l'état du bon dans la base de données à consommé ou partiellement consommé si OK ou remet l'état à son état initial d'avant utilisation si KO. La figure 23 représente le schéma de l'intégration entrante de l'API chez l'intermédiaire non marchand Le client final finalise son achat sur le site marchand, reçoit un facture électronique et demande le paiement électronique du montant de sa facture de façon habituelle. Le serveur de paiement électronique reçoit le client final de façon habituelle afin de lui présenter les différents modes de paiement parmi lesquels le bon d'achat. Le client final sélectionne le mode de paiement bon d'achat . * Le serveur de paiement doit : 'Générer le message XML nécessaire au back office pour effectuer la procédure de calcul et d'autorisation. # Générer le code HTML nécessaire à la saisie éventuelle d'un numéro de bon d'achat et optionnellement du mot de passe associé. Ces informations seront nécessaires pour lancer les procédures de calcul et autorisation. * Vérifier si un précédant appel d'une procédure de calcul au back office n'a pas eu lieu (vérification des paramètres HTTP par exemple). 'Dans le cas où un précédant appel aurait eu lieu, décoder le message XML et vérifier le code retour (succès ou échec). * En cas d'échec, générer le code HTML nécessaire à l'affichage de la raison de l'erreur. * En cas de succès, générer le message XML nécessaire au back office pour effectuer la procédure de confirmation. * En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction ainsi qu'à la validation de l'utilisation du bon qui déclenche la procédure de confirmation. * Le client final peut au choix : 'Entrer un numéro de bon d'achat ainsi que le mot de passe éventuellement associé et demander la calcul de la réduction et l'authentification de ce bon d'achat. "Valider son paiement qui peut éventuellement déjà inclure une réduction précédemment calculée, et demander le paiement complémentaire. Le numéro de bon d'achat et son éventuel mot de passe sont transmis au back office en SSL. Le back office : e Lit les paramètres HTTP reçus. Décode le paramètre correspondant au message XML. a Vérifie la cohérence des informations reçues avec la base de données. . Calcul la réduction en utilisant la fonction associé au bon d'achat (règle de consommation). . Met en place une session sécurisée (génération d'un numéro de session). a Construit la réponse XML. 'Lit les paramètres propriétaires du serveur de paiement et les utilise afin de générer l'URL de réponse. 'Construit le code HTML nécessaire à la redirection du résultat vers le serveur de paiement. Cette page invisible est la page précédemment générée par le back office afin d'appeler le serveur de paiement et de lui retransmettre son cookie et ses paramètres de façon transparente tout en lui fournissant le résultat du calcul et de l'authentification. Le back office : 'Lit les paramètres HTTP reçus. 'Décode le paramètre correspondant au message XML. * Vérifie le numéro de session afin de l'authentifier. * Met à jour la base de données afin de bloquer le bon jusqu'à la réception de la requête de confirmation de la consommation (OK ou KO). * Construit la réponse XML. * Lit les paramètres propriétaires du serveur de paiementet les utilise afin de générer l'URL de réponse. * Construit le code HTML nécessaire à la redirection du résultat vers le serveur de paiement. Cette page invisible est la page précédemment générée par le back office afin d'appeler le serveur de paiement et de lui retransmettre son cookie et ses paramètres de façon transparente tout en lui fournissant le résultat de la confirmation. Le serveur de paiement en charge d'afficher le mode de paiement complémentaire doit aussi : * Vérifier si un précédant appel d'une procédure de confirmation au back office n'a pas eu lieu (vérification des paramètres HTTP par exemple). 'Dans le cas où un précédant appel aurait eu lieu, décoder le message XML et vérifier le code retour (succès ou échec). "En cas de succès, générer le message XML nécessaire au back office pour effectuer la procédure d'acquisition de numéro de transaction. En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction ainsi qu'au transfert du numéro de transaction. Le client déclenche le paiement complémentaire. Cette page HTML envoie aussi de façon transparente le paramètre XML nécessaire au back office afin d'acquérir le numéro de transaction. Le back office : * Lit les paramètres HTTP reçus. * Décode le paramètre correspondant au message XML. * Vérifie le numéro de session afin de l'authentifier. * Met à jour la base de données avec le numéro de transaction. Met à jour la base de données afin de préparer la procédure de consommation (procédure déportée à l'origine du back office et à destination du serveur de paiement). Le serveur électronique de paiement effectue une procédure de paiement classique pour le paiement complémentaire. La procédure déportée de consommation est déclenchée quelques minutes après la procédure confirmation. Elle permet d'interroger le serveur de paiement et de lui demander le résultat du paiement complémentaire si nécessaire. Le back office : * Vérifie le temps passé depuis l'acquisition du numéro de commande. "Si ce temps est supérieur à un seuil, il vérifie le nombre d'essais effectués pour ce numéro de transaction. 'Si ce nombre d'essais est supérieur à un seuil, l'état du bon d'achat concerné est remis à son état initial d'avant utilisation. 'S'il est inférieur, il construit le paramètre XML nécessaire à la confirmation de la consommation auprès du serveur de paiement électronique. * Appel HTTP du serveur de paiement avec les paramètres précédemment calculés. Le serveur de paiement doit pouvoir aussi : . Recevoir la requête HTTP de consommation du back office. * Lire les paramètre HTTP. * Décoder le message XML de confirmation de consommation. 'Récupérer de sa base de données les informations de paiement relatives au paiement complémentaire concernant le numéro de commande relatif à la requête. * Générer le paramètre XML nécessaire à l'envoie de la réponse au back office. * Renvoyer le résultat sous forme d'une redirection HTTP.. Le back office : Lit les paramètre HTTP. Décode le paramètre XML de réponse à une procédure de consommation. Met à jour l'état du bon dans la base de données à consommé ou partiellement consommé si OK ou remet l'état à son état initial d'avant utilisation si KO. La figure 24 représente le schéma de l'intégration sortante de l'API chez l'intermédiaire non marchand Le client final finalise son achat sur le site marchand, reçoit un facture électronique et demande le paiement électronique du montant de sa facture de façon habituelle. Le serveur de paiement électronique reçoit le client final de façon habituelle afin de lui présenter les différents modes de paiement parmi lesquels le bon d'achat. Le client final sélectionne le mode de paiement bon d'achat . Le serveur de paiement doit : générer le code HTML nécessaire à la saisie éventuelle d'un numéro de bon d'achat et optionnellement du mot de passe associé. Ces informations seront nécessaires pour lancer les procédures de calcul et autorisation. Le client final peut au choix : Entrer un numéro de bon d'achat ainsi que le mot de passe éventuellement associé et demander la calcul de la réduction et l'authentification de ce bon d'achat. Valider sa commande qui peut éventuellement déjà inclure une réduction précédemment calculée, et demander le paiement complémentaire. Le numéro de bon d'achat et son éventuel mot de passe sont transmis au serveur de paiementen SSL Le serveur de paiement en charge d'afficher le prix avec la réduction du client final doit pouvoir aussi : * Générer le message XML nécessaire au back office pour effectuer la procédure de calcul et d'autorisation. "Appeler le back office afin de mettre en oeuvre la procédure de calcul et d'autorisation. * Décoder le message XML et vérifier le code retour (succès ou échec). 'En cas d'échec, générer le code HTML nécessaire à l'affichage de la raison de l'erreur. * En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction. * Générer le code HTML nécessaire à la saisie éventuelle d'un numéro de bon d'achat et optionnellement du mot de passe associé. Ces informations seront nécessaires pour lancer les procédures de calcul et autorisation. Le numéro de bon d'achat et son éventuel mot de passe sont transmis au back office en SSL. Le back office : Lit les paramètres HTTP reçus. Décode le paramètre correspondant au message XML. * Vérifie la cohérence des informations reçues avec la base de données. 'Calcul la réduction en utilisant la fonction associé au bon d'achat (règle de consommation). * Met en place une session sécurisée (génération d'un numéro de session). * Construit la réponse XML. Lit les paramètres propriétaires du serveur de paiement et les utilise afin de générer l'URL de réponse. # Répond au serveur de paiement en redirigeant l'appel HTTP. Le serveur de paiement en charge de demander le paiement complémentaire doit pouvoir aussi : 'Générer le message XML nécessaire au back office pour effectuer la procédure de confirmation. * Appeler le back office afin de mettre en oeuvre la procédure de confirmation. * Décoder le message XML et vérifier le code retour (succès ou échec). * En cas d'échec, générer le code HTML nécessaire à l'affichage de la raison de l'erreur. * En cas de succès, générer le code HTML nécessaire à l'affichage le montant de la réduction. "En cas de succès, générer le message XML nécessaire au back office pour effectuer la procédure d'acquisition de numéro de transaction. Appeler le back office afin de mettre en oeuvre la procédure d'acquisition du numéro de transaction. Le back office : Lit les paramètres HTTP reçus. Décoder le paramètre correspondant au message XML. * Vérifie le numéro de session afin de l'authentifier. * Met à jour la base de données afin de bloquer le bon jusqu'à la réception de la requête de confirmation de la consommation (OK ou KO). Construit la réponse XML. Lit les paramètres propriétaires du serveur de paiement et les utilise afin de générer l'URL de réponse. # Répond au serveur de paiement en redirigeant l'appel HTTP. Le back office : Lit les paramètres HTTP reçus. Décode le paramètre correspondant au message XML. 'Vérifie le numéro de session afin de l'authentifier. 'Met à jour la base de données avec le numéro de commande. # Met à jour la base de données afin de préparer la procédure de consommation (procédure déportée à l'origine du back office et à destination du serveur marchand). # Répond classiquement au serveur de paiement (réponse OK HTTP). Le client déclenche le paiement complémentaire si nécessaire. Le serveur électronique de paiement effectue une procédure de paiement classique pour le paiement complémentaire. Le serveur de paiement doit pouvoir aussi : 'Récupérer de sa base de données les informations de paiement relatives au paiement complémentaire concernant le numéro de transaction. 'Générer le paramètre XML nécessaire à l'envoie de la requête au back office. 'Envoyer la requête sous forme d'une URL HTTP. Le back office : * Lit les paramètre HTTP. * Décode le paramètre XML de la procédure de consommation. Met à jour l'état du bon dans la base de données à consommé ou partiellement consommé si OK ou remet l'état à son état initial d'avant utilisation si KO. Dans une deuxième déclinaison, un marchand se connecte à l'Extranet suivant le protocole HTTP sécurisé SSL en utilisant son identifiant partenaire ainsi qu'un identifiant utilisateur et un mot de passe associé. L'application vérifie la validité des identifiant et du mot de passe dans la base de données ainsi que le profil de l'utilisateur (suivi, modélisation, émission de bons ou de campagnes, administrateur). Dans le cas ou les identifiants et le mot de passe sont corrects et que le profil de l'utilisateur est suivi , l'application donne accès à l'application Extranet de suivi de bon d'achat. Le marchand peut forcer l'utilisation d'un bon d'achat grâce à l'Extranet permettant de : Choisir un bon d'achat à utiliser et éventuellement un mot de passe de verrouillage. * Saisir un numéro de commande. * Saisir le montant de la transaction. * Sélectionner la devise de la transaction. Cette transaction à lieu sous SSL. Le back office vérifie les informations saisies ainsi que la validité du bon d'achat (existence dans la base de données, dates de validité, validité du marchand, validité du mot de passe éventuel) et retourne la règle de consommation relative au bon d'achat utilisé. Le marchand est alors en charge de vérifier la bonne utilisation des règles de consommation avant de forcer l'utilisation du bon d'achat en question grâce à l'Extranet. Le back office met alors à jour la base de données. Dans une deuxième déclinaison : Le marchand peut choisir dans une deuxième option de se connecter avec un niveau de sécurité plus élevé de part l'utilisation de certificats client SSL mettant en oeuvre une identification forte entre l'application back office et le serveur client ou le client en tant que tel. Cette identification se fait par l'intermédiaire de certificats hébergés sur le serveur client ou sur des carte à puce. Utilisation à travers un Intranet magasin Dans une troisième déclinaison de l'utilisation de bons d'achat, le marchand utilise différentes API fournies par le serveur pour se connecter avec des EAI Intranet du marché afin de générer des ordres : 'D'autorisation de bons d'achat, * De calcul d'une réduction associée à un bon d'achat, * De consommation de bons d'achat, * De remboursement de bons d'achat. Le processus à suivre est alors le même que dans le cas de l'intégration de l'API Internet sortante chez un intermédiaire non marchand. Facturation d'un bon d'achat Factures périodiques Cas standard : Régulièrement ou à la demande, le back office fournit des factures aux émetteurs. Ces factures sont envoyées par mails aux personnes en charge des relations financières. Les factures sont aussi envoyées par pli postal dans un second temps sous un format classique. L'application de génération de factures différées permet pour chaque émetteur de : * Donner des informations sur les bons d'achat et certificats créés depuis la dernière facture, * Donner une information consolidée sur la facture globale par contrat. "Donner les bons d'achat utilisés depuis la dernière facture ainsi que le montant de la réduction accordé et le montant total de la transaction. L'identifiant de la commande, celui du marchand, de l'émetteur et de l'intermédiaire et éventuellement celui du client sont fournis. 4 champs sont mis à la disposition des partenaires afin que le serveur leur fournissent des informations personnalisées à définir à l'avance. 'Donner une information consolidée sur la facture globale par marchand. * Donner une information consolidée sur la facture globale. Authentification d'un utilisateur de l'extranet La figure 25 représente l'utilisation à travers l'Extranet. Les marchands, émetteurs et intermédiaires doivent s'enregistrer auprès du serveur afin d'avoir accès à l'Extranet. Cet enregistrement est effectué de façon classique : Un contrat est établi entre le serveur et le partenaire, Le serveur crée la partenaire dans la base de données, Le serveur fournit un identifiant au partenaire, Le serveur fournit un identifiant et un mot de passe administrateur au partenaire, Le serveur fournit une clé client SSL privée au partenaire, Le serveur crypte toutes les informations sensibles en SSL et authentifie le partenaire notamment grâce à sa clé client SSL. L'identifiant partenaire, l'identifiant administrateur et le mot de passe sont utilisés afin d'identifier un utilisateur de l'extranet. Un administrateur peut créer des utilisateurs ayant tous les profils excepté le profil administrateur. Toutes les données échangées sur l'extranet sont cryptées en SSL 128 bits. L'authentification de l'utilisateur est aussi renforcée par l'utilisation d'une clé cliente SSL agrée soit sur disque, sur carte à puce ou sur bouchon. Toutes les clés clientes SSL mettent en oeuvre des mécanismes d'authentification agréés par l'état Français sur 512 ou 1024 bits. Intégrité de la session extranet Tout au long d'une connexion Extranet, des informations de session sont véhiculées afin de vérifier constamment le profil des utilisateurs ayant accès aux différentes pages de l'Extranet. Lors de la connexion, les informations sur l'utilisateur sont vérifiées dans la base de données et placées sous une forme cryptée dans la session Internet. Ces informations sont véhiculées et vérifiées à chaque nouvelle requête http par la back office avant de rendre le service attendu. Authentification des bons d'achat Lors de l'utilisation d'un bon d'achat sur un site marchand ou chez un intermédiaire, le bon d'achat utilisé doit être authentifié de façon certaine. Quand un bon d'achat ou une campagne est créé, le back office génère pour chaque bon un numéro privé qui l'identifie de façon unique. L'algorithme utilisé pour générer ce numéro est sécurisé et garantie la non falsification. Lors de l'utilisation du bon d'achat, son identifiant passé en SSL au back office est vérifié dans la base de données. Cryptage des bons d'achat lors de leur utilisation Lors de l'utilisation d'un bon d'achat sur un site marchand ou chez un intermédiaire, le bon d'achat utilisé ainsi que son éventuel mot de passe doivent être protégés contre les interceptions. Les numéros de bon d'achat ainsi que le mot de passe sont transmis en SSL 128 bits à l'application et une session est ouverte pour protéger les transfert des informations tout au long de la transaction. Identification du marchand lors de l'utilisation d'un bon d'achat Lors de l'utilisation d'un bon d'achat sur un site marchand ou chez un intermédiaire, le marchand doit être identifié de façon certaine. Lors de la signature du contrat, le serveur fournit au marchand ou à l'intermédiaire sa clé privée ainsi que la clé publique du serveur afin de sécuriser les échanges effectués à travers l'API. L'algorithme suivant est utilisé afin d'identifier de façon certaine le marchand. L'algorithme mis en oeuvre afin de crypter les informations chez le marchand ou l'intermédiaire est le suivant : Mécanisme de cryptage : Soit : M le message à crypter et à envoyer au serveur, * Kprm la clé privée du marchand ou de l'intermédiaire, 'Kp la clé publique de du serveur. Le mécanisme de cryptage est le suivant : . Génération de la clé symétrique de cryptage du message Kg à l'aide de l'algorithme symétrique DES-EDE3 : . Ks Cryptage du message M avec Ks à l'aide de l'algorithme symétrique DES-EDE3/ECB/PKCS&num;5 : # EKs (M) # Encodage du message crypté EKS (M) avec un algorithme Base64 afin de générer un message pouvant être transmis par HTTP : # Base64 (EKs (M) ) # Signature du message M avec la clé privée du marchand ou de l'intermédiaire Kpr~m à l'aide de l'algorithme de signature SHA-1/RSA/PKCS&num;1 : # SKpr~m (M) # Encodage de la signature SKpr~m (M) avec un algorithme Base64 afin de générer un message pouvant être transmis par HTTP : . Base64 (S, (M)) Cryptage de la clé symétrique Kg avec la clé publique de Du serveur key Kpp à l'aide de l'algorithme asymétrique RSA/ECB/PKCS&num;7 : . EKpuy (Ks) Encodage de la clé symétrique cryptée EKPU p (Ks) avec un algorithme Base64 afin de générer un message pouvant être transmis par HTTP : # Base64(EKpu~p(Ks)) # Identification du serveur lors de l'utilisation d'un bon d'achat Lors de l'utilisation d'un bon d'achat sur un site marchand ou chez un intermédiaire, le marchand doit identifier de façon certaine Le serveur. Lors de la signature du contrat, Le serveur fournit au marchand ou à l'intermédiaire sa clé privée ainsi que la clé publique du serveur afin de sécuriser les échanges effectués à travers l'API. L'algorithme suivant est utilisé afin d'identifier de façon certaine le serveur : L'algorithme mis en oeuvre afin de décrypter les informations chez le marchand ou l'intermédiaire est le suivant : Mécanisme de décryptage : Soit : e E le message encodé reçu de Le serveur en Base64, 'S la signature encodée du message reçue de Le serveur en Base64, * K la clé de cryptage encodée du message reçue de Le serveur en Base64. Le mécanisme de décryptage est le suivant : # Décode la clé de cryptage encodée K avec un algorithme Base64 afin de lire le message transmis par HTTP : # Base64-1 (K) * Décrypte la clé de cryptage décodée Base64-1 (K) avec la clé privée du marchand ou de l'intermédiaire Kpr~m à l'aide de l'algorithme asymétrique RSA/ECB/PKCS&num;7 : K, Décoder le message encodé E avec un algorithme Base64 afin de lire le message transmis par HTTP # Base64-1 (E) * Décrypte le message décodé Base64-1 (E) avec la clé Kg à l'aide de l'algorithme symétrique DES- EDE3/ECB/PKCS&num;5 : M e Décode la signature encodée du message S avec un algorithme Base64 afin de lire le message transmis par HTTP : # Base64-1 (S) Décrypte et vérifie la signature décodée du message Base64-1 (S) avec la clé publique Le serveur Kpup à l'aide de l'algorithme de signature SHA-1/RSA/PKCS&num;1 : # Vrai/Faux Intégrité de la session lors de l'utilisation d'un bon d'achat Lors de l'utilisation d'un bon d'achat sur un site marchand ou chez un intermédiaire, la session correspondant à toute la transaction de paiement à l'aide du bon d'achat doit être intègre. Lorsque le back office reçoit une requête relative à une procédure de calcul, il effectue un certain nombre de vérifications et renvoie une réponse ainsi qu'un numéro de session. Ce numéro est systématiquement renvoyé par les serveurs marchands ou de l'intermédiaire à chaque nouvelle requête vers le back office. Ce numéro permet de vérifier l'intégrité de la session tout au long de la transaction. Annexe 1 ] > Annexe 2 le message XML suivant représentera un modèle de bon d'achat classique : This is the title This is the text Sample date Sample hash number This is the rule text drawn Discount amount Discount currency price numeric is higher than 500 REVENDICATIONS 1-Procédé pour la gestion de bons électroniques [par exemple bons d'achat, bons de remise, chèques cadeaux, bons de réduction, coupons promotionnels, carte prépayée, porte-monnaie électronique, ticket restaurants comportant une étape de fabrication d'un bon numérique comportant un identifiant unique vérifiable, une étape d'émission dudit bon numérique consistant à enregistrer dans la table d'un serveur l'identifiant du bon et la désignation de l'avantage associé audit bon, et à transmettre l'identifiant dudit bon à un utilisateur, et une étape de consommation dudit bon consistant à vérifier la validité dudit bon, à accorder l'avantage associé audit bon et à déclarer la consommation dudit bon par un marqueur dans ladite table du serveur, caractérisé en ce que l'étape d'émission de bons comporte une opération d'identification d'un émetteur de bons préalablement enregistrés par le serveur central, une opération de préparation d'une commande consistant à définir la nature et la quantité des bons à émettre, et à créer dans une mémoire du serveur une table d'enregistrement des bons créés en réponse à une requête de l'émetteur de bons identifié, et à transmettre à ce dernier un fichier signé par le serveur central avec la clé publique de l'émetteur de bons, ledit fichier contenant les identifiants créés à sa demande, et en ce que l'étape de contrôle de validité du bon est indépendante de l'identité du porteur, et en ce que la nature de l'avantage est mémorisé dans la table du serveur sous la forme d'une fonction. 2-Procédé pour la gestion de bons électroniques selon la revendication 1, caractérisé en ce que l'étape d'enregistrement d'un émetteur consiste à fabriquer un identifiant unique de l'émetteur à enregistrer dans une table du serveur ledit identifiant, l'identification de l'émetteur, et des informations relatives aux droits d'émission accordés audit émetteur et un mot de passe pour l'accès dudit l'émetteur aux fonctionnalités du serveur. 3-Procédé pour la gestion de bons électroniques selon la revendication 2, caractérisé en ce que l'étape d'enregistrement d'un émetteur comporte en outre une opération de transmission par l'émetteur d'un formulaire numérique contenant l'identité des marchands susceptible d'accepter les bons émis, et d'enregistrement desdites identité dans ladite table. 4-Procédé pour la gestion de bons électroniques selon la revendication 1, caractérisé en ce qu'il comporte une étape d'inscription d'un intermédiaire [par exemple un serveur de paiement électronique] consiste à établir une liaison sécurisée entre un poste d'un intermédiaire et le serveur central, à créer une table dans une mémoire du serveur central pour l'enregistrement d'un identifiant unique de l'intermédiaire et d'une liste des marchands transmis par ledit intermédiaire et à transmettre à l'intermédiaire un moyen d'accès à l'espace d'administration. 5-Procédé pour la gestion de bons électroniques selon la revendication 1, caractérisé en ce qu'il comporte une étape d'inscription d'un marchand [par exemple un opérateur d'un site de commerce électronique] consistant à enregistrer dans une base de données du serveur central un identifiant unique du marchand, une liste des marchands affiliés, une liste des intermédiaires autorisés, et une étape de fourniture par le serveur central d'un moyen d'accès à l'espace d'administration. 6-Procédé pour la gestion de bons électroniques selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de modélisation d'un bon comportant une première opération de vérification de l'habilitation de l'émetteur de la requête au regard des données numériques enregistrées dans les tables des intermédiaires, émetteurs et marchands, à établir une liaison sécurisé et à transmettre un formulaire pour la définition des spécificités des bons à fabriquer, et à définir les paramètres définissant l'avantage octroyé à chaque bon. 7-Procédé pour la gestion de bons électroniques selon la revendication 6, caractérisé en ce que l'opération de définition des spécificités du bon consiste à sélectionner une forme graphique parmi une bibliothèque de formes. 8-Procédé pour la gestion de bons électroniques selon la revendication 6, caractérisé en ce que l'opération de définition des spécificités du bon consiste à construire une forme graphique à l'aide d'un outil graphique permettant de dessiner et proposant une bibliothèque d'images 9-Procédé pour la gestion de bons électroniques selon l'une quelconque des revendications précédentes, caractérisé en ce que le détenteur d'un bon l'utilise par la saisie de son identifiant dans un formulaire numérique transmis par l'intermédiaire (marchand ou serveur de paiement), ce formulaire comprenant des moyens pour assurer une liaison entre le poste utilisateur et le serveur central, et pour la transmission d'un fichier numérique comprenant ledit identifiant d'un bon et un identifiant de l'intermédiaire et/ou de la commande en cours, le serveur central procédant à une vérification de l'authenticité de l'identifiant du bon et le cas échéant procédant au calcul du résultat de la fonction associée au bon appliquée aux informations relatives à la commande, le serveur procédant ensuite à un appel du marchand pour lui transmettre une page cachée comportant un moyen de validation de l'achat, ladite validation étant transmise au poste utilisateur sous la forme d'un fichier comprenant des moyens pour la réalisation d'un éventuel paiement complémentaire et pour l'acquittement par l'utilisateur de la transaction par l'envoi au serveur d'un message produisant la consommation du bon. 10-Procédé pour la gestion de bons électroniques selon l'une quelconque des 1 à 8 précédentes, caractérisé en ce que le marchand transmette au client une page HTML contenant une rubrique de saisie d'un identifiant d'un bon, l'utilisateur transmettant sous une session sécurisée un identifiant à l'intermédiaire (marchand ou serveur de paiement) qui procède à la vérification de la validité dudit bon auprès du serveur par l'établissement d'une session sécurisée, et transmettant à l'utilisateur une information relative à l'avantage accordé, le client procédant ensuite à la confirmation de la commande auprès du marchand qui procède à l'acquittement auprès du serveur. 11-Procédé pour la gestion de bons électroniques selon l'une quelconque des revendications précédentes, caractérisé en ce que les numéros de bon d'achat ainsi que le mot de passe sont transmis en mode sécurisé à l'application sur le poste utilisateur, et en ce qu'une session est ouverte pour protéger les transferts des informations tout au long de la transaction. 12-Procédé pour la gestion de bons électroniques selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur génère pour chaque bon créé un numéro privé qui l'identifie de façon unique, enregistrée dans une mémoire protégée, et en ce que le serveur procède, lors de l'utilisation du bon d'achat, à une vérification de l'identifiant transmis par comparaison avec celui enregistré dans la base de données de ladite mémoire. 13-Procédé pour la gestion de bons électroniques selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape d'inscription est suivie par une opération de transmission au marchand ou à l'intermédiaire de sa clé privée ainsi que la clé publique du serveur afin de sécuriser les échanges effectués à travers le logiciel d'application installé sur l'équipement informatique du marchand ou de l'intermédiaire. 14-Procédé pour la gestion de bons électroniques selon l'une quelconque des revendications précédentes, caractérisé en ce que il comporte une étape d'authentification d'un utilisateur de l'extranet consistant à enregistrer lors de l'étape d'inscription du partenaire les informations d'identifications dudit partenaire, à créer un identifiant unique et à le transmettre audit partenaire, à enregistrer dans la mémoire du serveur un mot de passe du partenaire, une opération de transmission d'une clé client SSL privée au partenaire, et à procéder au chiffrement d'une partie au moins des informations échangées entre le serveur et le partenaire et à l'authentification du partenaire avec sa clé privée SSL.