FR 3069083 A1 20190118 FR 1756634 A 20170712 Procédé pour augmenter la robustesse d'un paiement La présente invention concerne le domaine des transactions financières, en particulier celles réalisées au moyen de carte de paiement. Elle trouve notamment des applications dans le contrôle des transactions bancaires réalisées au moyen de carte bancaire, mais plus largement dans toute transaction réalisée au moyen de carte de paiement. En effet, lors des paiements réalisés par carte bancaire des erreurs dans les informations issues ou attachées au paiement peuvent apparaître. En effet, lors d'un paiement par carte bancaire via un terminal de paiement électronique, le système bancaire ainsi que le système informatique du vendeur attache à ce paiement des informations qui lui sont propres. Il arrive que ces informations puissent être erronées. Par exemple, il est possible que le montant attaché au paiement par le système bancaire et donc le montant effectivement prélevé sur le compte lié à la carte bancaire qui a effectué le paiement diffère du montant proposé par le vendeur pour un tel achat. Ainsi, l'acheteur peut se voir débiter des montants correspondant à des transactions erronées, à son détriment ou au détriment du vendeur. Le problème est d'autant plus important que les moyens de paiement se sont multipliés et s'appuient sur des systèmes et protocoles souvent moins robustes que ceux mis en oeuvre dans les systèmes de cartes bancaires. Il est donc nécessaire d'augmenter la robustesse des moyens de paiement. La présente invention vient améliorer la situation. Un premier aspect de l'invention concerne un procédé mis en oeuvre par un serveur informatique médiateur, de vérification d'un paiement en vue d'améliorer la robustesse dudit paiement, le paiement étant réalisé avec un moyen de paiement électronique d'un système de paiement comprenant un serveur bancaire, le procédé comprenant: 2 - importer, depuis le serveur bancaire, de premières données relatives au paiement, chaque première donnée étant d'un premier type prédéfini ; - importer, depuis un serveur vendeur, de deuxièmes données 5 relatives au paiement, chaque deuxième donnée étant d'un deuxième type prédéfini ; - sélectionner au moins un ensemble de types présents à la fois dans les premiers types prédéfinis et les deuxièmes types prédéfinis ; - sélectionner, parmi les premières et les deuxièmes données, celles 10 dont les types sont compris dans l'ensemble de types sélectionné; - vérifier si les premières données sélectionnées d'un type prédéfini sont égales aux deuxièmes données sélectionnées pour ce même type prédéfini, et - en cas de vérification négative, émettre une alerte. 15 Par premières données relatives au paiement on entend les données caractéristiques du paiement au regard du système de paiement. Ces données caractéristiques permettent notamment pour le système de paiement de distinguer les différents paiements réalisés via le système de paiement. Par exemple, lorsque le système de paiement est un système de paiement bancaire alors les premières 20 données peuvent être toutes ou partie des données échangées et/ou stockées par le système de paiement bancaire lors d'un paiement dans le cadre de la norme ISO 8583:1993 ou ISO 8583-1 :2003. Plus avantageusement les premières données sont les données produites par le système de paiement lors de la procédure d'autorisation. Par la suite, les premières données pourront être nommées données transaction 25 bancaire (DTB). Par deuxièmes données relatives au paiement on entend les données caractéristiques du paiement au regard du vendeur. Ces données caractéristiques permettent notamment pour le vendeur de distinguer les différents paiements réalisés via le système de paiement. Ainsi les deuxièmes données peuvent notamment être les données fournies par les dispositifs de paiement du vendeur, à savoir les terminaux 3 de paiement électronique (TPE), il peut également s'agir des données fournies plus généralement par le système informatique du vendeur et notamment des caisses enregistreuses. Par la suite, les deuxièmes données pourront être nommées données transaction vendeur (DTV). 5 Par type nous entendons les types de chacune des données qu'il s'agisse des premières ou des deuxièmes données. Ainsi, chaque paiement donne lieu à la production de données par le système de paiement et par le vendeur, chacune de ces données à un type prédéfini. Les types peuvent être par exemple le montant, la date, l'heure, l'identifiant de la carte, le numéro d'autorisation bancaire, identifiant du 10 vendeur, l'article, le montant de l'article. Par alerte on entend tout message ou signal destiné à permettre d'informer sur la survenue d'un évènement spécifique. On entend par serveur bancaire, tout serveur d'un système de paiement, ledit système de paiement servant à effectuer le paiement. Par moyen de paiement 15 électronique on entend le moyen d'identification permettant de réaliser un transfert financier via le système de paiement. Par vérification négative on entend l'absence d'égalité entre au moins l'une des premières données et l'une des deuxièmes données pour au moins un type de l'ensemble de types. 20 Ainsi, le serveur informatique médiateur ou plus simplement le serveur médiateur, permet de vérifier si les premières données et les deuxièmes données sont cohérentes. Par cohérence l'on entend que les premières et deuxièmes données sont égales pour certains types, et que cette égalité a lieu pour un nombre de types suffisamment grands et sur des types suffisamment sensibles pour détecter des 25 potentielles erreurs dans les premières et/ou deuxièmes données. Le procédé permet également d'avoir un niveau de certitude raisonnable sur le fait que les premières données et les deuxièmes données sont relatives au même paiement effectué au moyen du système de paiement. Le niveau de certitude 4 varie en fonction de l'ensemble de types sélectionné. Ainsi, plus le nombre de types de l'ensemble de types est important et plus le niveau de certitude est important, l'on va ainsi effectuer la vérification sur un plus grand nombre de données. De même plus les données propres à un type de l'ensemble de types permettent de distinguer à eux 5 seuls un paiement des autres paiements réalisés et plus l'ensemble de types permet d'obtenir un niveau de certitude élevé. En cas de premières et deuxièmes données cohérentes une alerte positive peut être émise. De plus, le procédé permet de réaliser la vérification par un serveur tiers, 10 à savoir le serveur médiateur. Ainsi, l'on réunit les premières et deuxièmes données sur ce serveur tiers plutôt que sur le serveur bancaire ou le serveur vendeur, qui devrait respectivement importer soit les deuxièmes données soit les premières données. Cela réduit les risques d'intrusions ou de hacking par le biais de l'importation des deuxièmes données sur le serveur bancaire. Cela réduit également 15 le risque d'importation de premières données sur un serveur vendeur, dont le vendeur n'a pas participé au paiement. De plus le serveur vendeur devrait gérer une quantité de données supplémentaires importantes. Le vendeur devrait également disposer de connexions et liaisons informatiques sécurisées. Ainsi, la sécurité des données en est améliorée sans modification de la structure, autre que celle permettant de mettre en 20 oeuvre le procédé. Selon un mode de réalisation, en cas de vérification positive, on réconcilie les premières données et les deuxièmes données. Par vérification positive on entend l'égalité, pour chaque type de l'ensemble de types, des premières données et des deuxièmes données de ce type. 25 Par réconciliation on entend le regroupement des DTV et DTB. Le groupe de données ainsi formé sera nommé données réconciliées (DR). Dans un mode de réalisation il est possible d'effectuer le regroupement des DTV et DTB en ne conservant qu'une seule donnée par type. Ainsi, en réconciliant les DTV avec les DTB les données réconciliées constituent des données plus aptes à faire l'objet de 5 vérification subséquente. En effet, dans la mesure où l'on ne réconcilie pas les DTV et les DTB, il est possible d'avoir des premières et secondes données différentes pour un même type rendent plus compliqués les vérifications subséquentes. Par exemple le montant du paiement des premières données peut être égal à la somme des 5 montants des produits achetés (deuxièmes données), sans que cette somme soit égale avec le montant du paiement des deuxièmes données. Ainsi, on évite des incohérences dans les vérifications subséquentes. Selon un mode de réalisation, en cas de vérification négative suite à la vérification, le procédé comprend en outre : 10 - la sélection d'un second ensemble de types présents à la fois dans les premiers types prédéfinis et les deuxièmes types prédéfinis ; - la sélection, parmi les premières et les deuxièmes données, de celles dont les types sont compris dans le second ensemble de types sélectionné ; 15 - une seconde vérification, pour vérifier si les premières données sélectionnées d'un type prédéfini sont égales respectivement aux deuxièmes données sélectionnées pour ce même type prédéfini, et - en cas de seconde vérification négative, émettre une alerte. L'ensemble de types est avantageusement sélectionné de manière à 20 diminuer le niveau de certitude sur le fait que les premières données et les deuxièmes données sont relatives au même paiement. Ainsi, la vérification supplémentaire permet de détecter les premières données et les deuxièmes données qui, malgré une erreur, sont relatives au même paiement. Selon un mode de réalisation, en cas de vérification positive de la 25 vérification ou de la seconde vérification, on effectue une vérification supplémentaire pour vérifier une correspondance entre des deuxièmes données de type non compris dans l'ensemble de types sélectionné avec lequel une vérification positive a été obtenue et toutes ou partie des premières données, selon un jeu de règles prédéterminé. 6 Ainsi cette vérification supplémentaire dépend de l'ensemble de types utilisé pour obtenir une vérification positive, à savoir l'ensemble de types ou le second ensemble pour lequel, pour chacun de ses types les premières et deuxièmes données de ce type sont égales. Ainsi, l'on vérifie que les données non vérifiées 5 parmi les deuxièmes données correspondent avec toutes ou partie des premières données. On évite ainsi des opérations de vérification inutiles ou superflues. Par jeu de règles prédéterminé on entend une ou plusieurs formules, relations ou équations appliquées sur certaines des premières et deuxièmes données. Par exemple, la somme des montants des articles qui ont fait l'objet du paiement, ce 10 qui est une somme de deuxièmes données, est comparée avec le montant du paiement, ce qui est une première donnée. Cela permet, une fois que l'on s'est assuré que les premières et deuxièmes données appartiennent au même paiement, d'effectuer une vérification en croisant des données de type différent. Le procédé permet ainsi de détecter des erreurs dans 15 les premières et/ou deuxièmes données avec un degré de certitude important. Ainsi, même si des premières et deuxièmes données de même types sont identiques mais erronées alors cette vérification supplémentaire pourra permettre de déceler cette erreur, en se basant sur des données d'autres types. Les deuxièmes données de type non compris dans l'ensemble de types 20 sélectionné avec lequel une vérification positive a été obtenue et les premières données peuvent également être les données réconciliées correspondantes aux premières et deuxièmes données auxquelles on applique le jeu de règles prédéterminé. Selon un mode de réalisation, en cas de vérification négative suite à la 25 vérification supplémentaire une alerte est émise. Par alerte on entend tout message ou signal destiné à permettre d'informer sur la survenue d'un évènement spécifique. Ainsi en cas de vérification négative, c'est-à-dire lorsqu'il y a une erreur 7 dans les premières et/ou deuxièmes données alors une alerte est émise. Celle-ci peut être envoyée au serveur bancaire ou au serveur vendeur, ou à toute autre entité, afin qu'une correction des données soit mise en oeuvre. Selon un mode de réalisation, en cas de vérification positive suite à la 5 vérification, à la seconde vérification ou à la vérification supplémentaire, une alerte positive peut être envoyée. Ainsi, l'alerte permet de notifier du bon déroulement du paiement. Cette alerte peut être réalisée par un signal émis par le serveur médiateur au serveur vendeur et/ou au serveur bancaire. Selon un mode de réalisation, l'importation des 10 deuxièmes données est réalisée au moyen d'une connexion sécurisée au serveur informatique médiateur. Ainsi, les transmissions entre le serveur médiateur et le serveur vendeur sont réalisées de manière sécurisée. Une authentification est ainsi nécessaire pour pouvoir effectuer une connexion au serveur médiateur ou à tout autre serveur 15 permettant l'importation des deuxièmes données. De ce fait l'intégrité des deuxièmes données importées sur le serveur médiateur est conservée au moins jusqu'à ce que les différentes vérifications ci-dessus soient réalisées. De même il est possible de prévoir la redondance de la transmission des deuxièmes données Ainsi, celles-ci sont émises voir transmises au moins deux fois, permettant de limiter les erreurs qui 20 surviendraient au cours de la transmission. On peut donc soit comparer les deux groupes de deuxièmes données entre eux, soit on peut avantageusement, réaliser les différentes vérifications (vérification, seconde vérification, vérification supplémentaire) sur chacun des deux groupes et conserver celui qui présente le moins d'erreurs ou qui ne présente pas d'erreur. 25 Un deuxième aspect de l'invention concerne un programme informatique comportant des instructions pour la mise en oeuvre des étapes du procédé ci-avant, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l'invention concerne un serveur informatique 8 médiateur, configuré pour communiquer avec un serveur bancaire et un serveur vendeur pour augmenter la robustesse d'un paiement réalisé avec un moyen de paiement électronique d'un système de paiement comprenant le serveur bancaire, ledit serveur informatique médiateur comprend un processeur configuré pour : 5 - importer, depuis le serveur bancaire, de premières données relatives au paiement, chaque première donnée étant d'un premier type prédéfini ; - importer, depuis un serveur vendeur, de deuxièmes données relatives au paiement, chaque deuxièmes donnée étant d'un 10 deuxième type prédéfini ; - sélectionner au moins un ensemble de types présents à la fois dans les premiers types prédéfinis et les deuxièmes types prédéfinis ; - sélectionner, parmi les premières et les deuxièmes données, celles dont les types sont compris dans l'ensemble de types sélectionné, 15 et - vérifier si les premières données sélectionnées d'un type prédéfini sont égales aux deuxièmes données sélectionnées pour ce même type prédéfini, - en cas de vérification négative, émettre une alerte. 20 D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - la figure 1 illustre un système permettant de mettre en oeuvre le procédé au sens de l'invention ; - la figure 2 est un diagramme illustrant les étapes d'un procédé selon un mode 25 de réalisation de l'invention ; - la figure 3 illustre de manière détaillée un serveur médiateur. La figure 1 illustre un système permettant de mettre en oeuvre le procédé au sens de l'invention. Pour effectuer un paiement d'une transaction via une carte bancaire 10 9 (ou plus généralement tous types de carte de paiement, exemple monéo ou monétique), via le terminal de paiement électronique (TPE) 11 du vendeur, la carte bancaire 10 de l'acheteur est authentifiée. En fonction des différentes technologies utilisées (paiement sans contact, ...), l'acheteur doit entrer un code PIN ou non. Une 5 fois le paiement effectué par carte bancaire des informations relatives à celui-ci sont enregistrées sur un serveur bancaire (S-Ban) 13, ces informations seront nommées premières données ou données de transaction bancaire (DTB). Les échanges entre le TPE 11 et S-Ban 13 se font via un réseau TCP/IP 12, en général le réseau internet. Des entités intermédiaires peuvent être disposées entre le TPE 11 et S-Ban 13, il 10 s'agit des entités classiques des systèmes bancaires dans le cadre de paiement par carte bancaire. Ces différentes entités ne sont pas représentées ici. Ces échanges se font suivant les standards propres aux transactions financières, par exemple la norme ISO 8583:1993 ou ISO 8583-1 :2003 et la norme « bulletin 14» du GIE des Cartes Bancaires. 15 Le procédé peut également être mis en oeuvre dans le cadre plus général de système de paiement et n'est pas restreint au système bancaire. Des informations liées à la transaction sont également enregistrées par le vendeur sur un serveur vendeur (S-Ven) 14, ces informations seront nommées deuxièmes données ou données transaction vendeur (DTV). Les échanges entre le 20 TPE 11 et le S-Ven 14 se font via un réseau qui peut être tout réseau privé du vendeur mais également le réseau internet. Des entités intermédiaires peuvent être disposées entre le TPE 11 et S-Ven 14, ces entités sont dépendantes du réseau utilisé par le vendeur et ne sont pas décrites ici. Les DTV sont transmises par S-Ven 14 au Serveur Médiateur ou Serveur 25 Informatique Médiateur (S-Med) 15 ou importées par le S-Med 15 du S-Ven 14. Le transfert des DTV sur le S-Med 15 peut se faire via un réseau de communication ordinaire, par exemple le réseau internet. Le transfert des DTV sur le S-Med 15 peut avantageusement se faire par des protocoles de transfert sécurisé, par exemple les protocoles SFTP ou FTPES. Ainsi, une authentification (login/mot de passe et/ou 30 certificat) est réalisée pour permettre la connexion du S-Ven 14 sur le S-Med 15. Les 10 DTV peuvent également faire l'objet d'un chiffrement. Le transfert des DTV entre le S-Ven 14 et le S-Med 15 peut avantageusement faire l'objet de tout procédé afin d'améliorer la robustesse de ce transfert, par exemple au moyen de redondance du transfert ou d'alertes en cas de non transmission, de format de données non respecté, 5 de données manquantes. De même les DTB sont transmises par S-Ban 13 au S-Med 15 ou importées par le S-Med 15 du S-Ban 13. Le transfert des DTB sur le S-Med 15 peut se faire via un réseau de communication ordinaire, par exemple un réseau de communication publique de type internet, avantageusement ce transfert peut se faire 10 par un réseau de communication privé ou un réseau de communication privé virtuel de type VPN. Le transfert des DTB sur le S-Med 15 peut avantageusement se faire par des protocoles de transfert sécurisé, par exemple les protocoles SFTP ou FTPES. Ainsi, une authentification (login/mot de passe et/ou certificat) est réalisée pour permettre la connexion du S-Ban 13 sur le S-Med 15. Les DTB peuvent également 15 faire l'objet d'un chiffrement. Le transfert des DTB entre le S-Ban 13 et le S-Med 15 peut avantageusement faire l'objet de tout procédé afin d'améliorer la robustesse de ce transfert, par exemple au moyen de redondance du transfert ou d'alertes en cas de non transmission, de format de données non respecté, de données manquantes. Les DTB et les DTV peuvent subir des modifications, suppressions ou 20 ajouts d'information lors de leur transmission entre le TPE et le S-Med. Toutefois, entre le S-Ban et le S-Med et entre le S-Ven 14 et le S-Med 15, les modifications ne doivent pas affecter les données qui vont être testées au risque d'altérer le résultat de la procédure d'amélioration de la robustesse du paiement. Un message ou signal d'alerte positive ou une alerte liée à une 25 vérification négative peut être émis par le S-Med 15 au S-Ven 14 et/ou S-Ban 13. Ces signaux ou messages peuvent être transférées par un réseau de communication ordinaire, par exemple un réseau de communication publique de type internet. Mais comme pour le transfert des DTB et DTV du S-Ban 13 et S-Ven 14 respectivement vers le S-Med ces transferts peuvent avantageusement être réalisés par un réseau de 30 communication privé ou un réseau de communication privé virtuel. Le transfert des 11 DTB sur le S-Med 15 peut avantageusement se faire par des protocoles de transfert sécurisé, par exemple les protocoles SFTP ou FTPES. Ainsi, une authentification (login/mot de passe et/ou certificat) est réalisée pour permettre la connexion du S-Ban 13 sur le S-Med 15. Les DTB peuvent également faire l'objet d'un chiffrement. 5 Le transfert des DTB entre le S-Ban 13 et le S-Med 15 peut avantageusement faire l'objet de tout procédé afin d'améliorer la robustesse de ce transfert, par exemple au moyen de redondance du transfert ou d'alertes en cas de non transmission, de format de données non respecté, de données manquantes. Il est d'autant plus important d'avoir une transmission robuste des 10 signaux de validation ou de suspension du paiement que ceux-ci peuvent automatiquement suspendre ou valider le paiement. Le S-Med 15 peut être composé de plusieurs serveurs, par exemple un serveur d'authentification, un serveur FTP, un serveur SGBD (par exemple un serveur MySQL), web (par exemple un serveur Apache), applicatif (par exemple un 15 serveur Tomcat). La figure 2 est un diagramme illustrant les étapes d'un procédé selon un mode de réalisation de l'invention. Le S-Ban 13 et S-Med 15 sont configurés pour transférer les DTB sur le 20 S-Med 15, comme indiqué précédemment, à une étape 21a. Chaque donnée des DTB est d'un type prédéfini, par exemple, ID, montant, date, numéro d'autorisation du paiement, acheteur, PAN (Primary Account Number), marchand. Le S-Ven 14 et S-Med 15 sont configurés pour transférer les DTV sur le S-Med 15, comme indiqué précédemment, a une étape 21b. Chaque donnée des DTV 25 est d'un type prédéfini, par exemple les types définis dans le cadre des données DTB, mais également les articles, la quantité d'article, le prix unitaire de chaque article, montant par ensemble d'article, taux TVA. A l'étape 22, un jeu de règles est sélectionné. A l'étape 22 un jeu de 12 règles consiste en un ensemble de types, par exemple montant, date, PAN (Primary Account Number) et marchand tel que pour chaque type de l'ensemble, DTV et DTB possèdent chacune au moins une donnée. Plusieurs ensembles de types peuvent être prédéfinis. 5 A l'étape 23a, les données des DTB correspondant aux types de l'ensemble sélectionné à l'étape 22, sont sélectionnées. De même, à l'étape 23b, les données des DTV correspondant aux types de l'ensemble sélectionné à l'étape 22, sont sélectionnées. A l'étape 24, pour chaque type de l'ensemble de types sélectionné à 10 l'étape 22, il est vérifié si les données de ce type parmi les données sélectionnées à l'étape 23a sont égales aux données de ce type parmi les données sélectionnées à l'étape 23b. En cas d'inégalité pour au moins un type de l'ensemble de types une alerte peut être émise à l'étape 25.2. Suite à l'émission de l'alerte ou du signal, un nouveau jeu de règles peut 15 être sélectionné. Le nouveau jeu de règle étant avantageusement différent du jeu de règles sélectionné à l'étape 22. Le nouveau jeu de règles peut être avantageusement moins strict, c'est-à-dire contenir moins de types et/ou des types pour lesquels les données de ces types sont susceptibles d'erreur, afin de détecter les DTB et les DTV qui, malgré une erreur, sont relatives au même paiement. Dans ce cas les étapes 23a, 20 23b et 24 sont répétées de manière identiques à ce qui a été préalablement décrit, mise à part que l'on utilise un nouveau jeu de règles sélectionné. Si à l'étape 24, pour chaque type de l'ensemble de types sélectionné à l'étape 22 ou plus généralement à la dernière itération de l'étape de sélection d'un nouveau jeu de règles, il y a égalité des données de ce type parmi les données 25 sélectionnées à l'étape 23a avec les données de ce type parmi les données sélectionnées à l'étape 23b, alors on réalise à l'étape 25.1 la réconciliation des DTV et des DTB. Par réconciliation on entend, le regroupement des DTV et DTB. Le groupe de données ainsi formé sera nommé données réconciliées (DR). Dans un mode de réalisation il est possible d'effectuer le regroupement 13 des DTV et DTB en ne conservant qu'une seule donnée par type.. Ainsi, lorsque pour un même type il existe une donnée de ce type parmi les DTV et une donnée de ce type parmi les DTB on ne conserve qu'une donnée de ce type. Lorsque ces données sont identiques, par exemple lorsque le type fait partie de l'ensemble de types qui a 5 fait l'objet du test de l'étape 24, alors on conserve indifféremment l'une ou l'autre des données. Lorsque ces données ne sont pas identiques on peut décider pour ce type de prioriser les données de certain type provenant des DTV par rapport au DTB ou inversement. Ainsi, la donnée priorisée est conservée au détriment de l'autre donnée de même type. 10 Dans une alternative si à l'étape 24 on obtient une vérification positive, S- Med 15 émet une alerte positive. Cette alerte peut être envoyée au S-Ban 13 et/ou SVen 14. A l'étape 26, on vérifie que les DTV de type non compris dans l'ensemble de types sélectionné à l'étape 22 ou plus généralement à la dernière 15 itération de l'étape de sélection d'un nouveau jeu de règles, et toutes ou partie des DTB, vérifie un jeu de règles prédéterminées. Par exemple, on peut vérifier que la somme de valeur de certaine DTV de types défini par le jeu de règles prédéterminé, et non compris dans l'ensemble de types utilisé pour valider l'étape 24, est égale à une valeur d'une DTB de type également défini par le jeu de règles prédéterminé. 20 Dans la mesure où la vérification est positive, S-Med 15 émet à l'étape 27.1 une alerte positive. Cette alerte peut être envoyée au S-Ban 13 et/ou S-Ven 14. Dans la mesure où la vérification est négative, S-Med 15 émet à l'étape 27.2 une alerte, celle-ci peut être similaire à celle émise à l'étape 25.2, à savoir une alerte mail, l'émission d'un ticket incident, l'émission d'un message à destination 25 d'un journal d'anomalies. Les alertes émises à l'étape 27.2 peuvent différer en fonction de l'erreur qui l'a engendrée. Par exemple, le jeu de règles prédéterminé peut comporter une alerte spécifique pour chacune de ses règles, permettant d'identifier les données erronées. De plus, les alertes spécifiques peuvent faire l'objet de différentes sortes 14 d'émission, avec des niveaux de gravité différents, des destinataires différents (S-yen et S-Ban, 5-yen, S-Ban, ...). Ainsi, les corrections à apporter peuvent être effectuées de manière efficace. La figure 3 illustre de manière détaillée un serveur médiateur. 5 Le S-Med 15 comprend une unité de stockage 33, par exemple une mémoire RAM et un processeur 32 qui peut exécuter le code d'instruction pour mettre en oeuvre au moins les étapes 21 à 27.1 et 27.2 telles que décrites ci-dessus. L'unité de stockage 33, selon des modes de réalisation de l'invention, peut enregistrer les jeux de règles qui peuvent être sélectionnées à l'étape 22 ou plus 10 généralement à toutes les itérations de l'étape de sélection d'un jeu de règles. De même, l'unité de stockage 33 peut également enregistrer le jeu de règles prédéterminé utilisé à l'étape 26. L'unité de stockage 33, permet d'enregistrer les DTV et DTB qui sont importées sur le S-Med 15, les données sélectionnées à l'étape 23a, les données sélectionnées à l'étape 23b, ainsi que les données réconciliées DR à 15 l'étape 25.1. Le S-Med 15 comprend en plus une première interface réseau 31 pour communiquer avec le S-Ban 13. Le S-Med 15 comprend également une seconde interface réseau 32 pour communiquer avec le S-Yen 14. 20 Bien entendu, l'invention n'est pas limitée aux modes de réalisation décrits précédemment et fournis uniquement à titre d'exemple. Elle englobe diverses modifications, formes alternatives et autres variantes que pourra envisager l'homme REVENDICATIONS1. Procédé mis en oeuvre par un serveur informatique médiateur, de vérification d'un paiement en vue d'améliorer la robustesse dudit paiement, le paiement étant réalisé avec un moyen de paiement électronique d'un système de paiement comprenant un serveur bancaire, le procédé comprenant: - importer (21a), depuis le serveur bancaire, de premières données relatives au paiement, chaque première donnée étant d'un premier type prédéfini ; - importer (2 lb), depuis un serveur vendeur, de deuxièmes données relatives au paiement, chaque deuxième donnée étant d'un deuxième type prédéfini ; - sélectionner (22) au moins un ensemble de types présents à la fois dans les premiers types prédéfinis et les deuxièmes types prédéfinis ; - sélectionner (23a, 23b), parmi les premières et les deuxièmes données, celles dont les types sont compris dans l'ensemble de types sélectionné ; - vérifier (24) si les premières données sélectionnées d'un type prédéfini sont égales aux deuxièmes données sélectionnées pour ce même type prédéfini, et - en cas de vérification négative, émettre une alerte (25.2). 2. Procédé selon la revendication 1 dans lequel, en cas de vérification positive, on réconcilie les premières données et les deuxièmes données. 3. Procédé selon l'une des revendications précédentes, dans lequel en cas de vérification positive de la vérification, on effectue une vérification supplémentaire pour vérifier une correspondance entre des deuxièmes 16 données de type non compris dans l'ensemble de types sélectionné et toutes ou partie des premières données, selon un jeu de règles prédéterminé. 4. Procédé selon l'une des revendications 1 et 2, dans lequel en cas de 5 vérification négative suite à la vérification, le procédé comprend en outre : - la sélection d'un second ensemble de types présents à la fois dans les premiers types prédéfinis et les deuxièmes types prédéfinis, - la sélection, parmi les premières et les deuxièmes données, de celles dont les types sont compris dans le second ensemble de 10 types sélectionné ; - une seconde vérification, pour vérifier si les premières données sélectionnées d'un type prédéfini sont égales respectivement aux deuxièmes données sélectionnées pour ce même type prédéfini, et - en cas de seconde vérification négative, émettre une alerte. 15 5. Procédé selon la revendication 4 dans lequel, en cas de vérification positive de la seconde vérification, on effectue une vérification supplémentaire pour vérifier une correspondance entre des deuxièmes données de type non 20 compris dans le second ensemble de types sélectionné et toutes ou partie des premières données, selon un jeu de règles prédéterminé. 6. Procédé selon l'une des revendications 3 et 5 dans lequel, en cas de vérification négative suite à la vérification supplémentaire une alerte est 25 émise. 7. Procédé selon l'une des revendications précédentes dans lequel, en cas de vérification positive suite à l'une des vérifications, une alerte positive est émise. 17 8. Procédé selon l'une des revendications précédentes dans lequel, l'importation des deuxièmes données est réalisée au moyen d'une connexion sécurisée au serveur informatique médiateur. 5 9. Procédé selon l'une des revendications précédentes dans lequel, les deuxièmes données sont transmises de manière redondante au serveur informatique médiateur. 10. Programme informatique comportant des instructions pour la mise en oeuvre 10 des étapes du procédé selon l'une des revendications précédentes, lorsque ces instructions sont exécutées par un processeur. 11. Serveur informatique médiateur, configuré pour communiquer avec un serveur bancaire et un serveur vendeur pour augmenter la robustesse d'un 15 paiement réalisé avec un moyen de paiement électronique d'un système de paiement comprenant le serveur bancaire, ledit serveur informatique médiateur comprend un processeur configuré pour : - importer, depuis le serveur bancaire, de premières données relatives au paiement, chaque première donnée étant d'un premier 20 type prédéfini ; - importer, depuis le serveur vendeur, de deuxièmes données relatives au paiement, chaque deuxièmes donnée étant d'un deuxième type prédéfini ; - sélectionner au moins un ensemble de types présents à la fois dans 25 les premiers types prédéfinis et les deuxièmes types prédéfinis ; - sélectionner, parmi les premières et les deuxièmes données, celles dont les types sont compris dans l'ensemble de types sélectionné, et - vérifier si les premières données sélectionnées d'un type prédéfini 30 sont égales aux deuxièmes données sélectionnées pour ce même type prédéfini, 18 - en cas de vérification négative, émettre une alerte.