WO2020208262A1 - Contrôle parental mis en œuvre dans un systeme de traitement d'une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur - Google Patents

Contrôle parental mis en œuvre dans un systeme de traitement d'une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur Download PDF

Info

Publication number
WO2020208262A1
WO2020208262A1 PCT/EP2020/060472 EP2020060472W WO2020208262A1 WO 2020208262 A1 WO2020208262 A1 WO 2020208262A1 EP 2020060472 W EP2020060472 W EP 2020060472W WO 2020208262 A1 WO2020208262 A1 WO 2020208262A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
bank
user
processing module
mod
Prior art date
Application number
PCT/EP2020/060472
Other languages
English (en)
Inventor
Diana BRONDEL
Papa Birame SENE
Madiara GASSAMA
Original Assignee
Xaalys Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Xaalys Sas filed Critical Xaalys Sas
Publication of WO2020208262A1 publication Critical patent/WO2020208262A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/229—Hierarchy of users of accounts
    • G06Q20/2295—Parent-child type, e.g. where parent has control on child rights

Definitions

  • the present invention relates to parental control implemented in a system for processing a transaction associated with a payment card held by a user subject to a decision maker.
  • the present invention overcomes these drawbacks.
  • the invention relates to a parental control method implemented in a system for processing a transaction associated with a payment card held by a user subject to a decision maker.
  • the processing system comprises:
  • the implementation of parental control is flexible and not very restrictive compared to the prior art. Indeed, the list of prohibited / authorized transactions is created beforehand by “purchase categories” upstream of the purchase by the decision maker. As a result, the purchase is authorized or rejected without waiting for the effective approval of the decision maker. In addition, the decision maker controls the user's purchases by “purchase category”, upstream of the purchase, and without the user's constraint on the decision-maker. Finally, parental control based on the activity codes of traders technically guarantees that the authorization of the purchase relates to a category of purchases authorized by the decision-maker.
  • the Applicant has observed that the technical guarantee of parental control is based on rules previously established by the decision-maker and which are correlated with the identification of the type of business questioned by the means of payment during the 'purchase. Indeed, during the purchase, the activity code called MCC (Merchant Category code) of the trade is compared according to the invention, with a list making it possible to establish the category (s) of goods or services offered by trade, this category then itself being compared to a list of authorized / prohibited categories created upstream by the decision-maker, and allowing to refuse / accept payment by this specific payment medium (such as bank card, mobile, etc. .).
  • MCC Merchant Category code
  • the merchant's activity code is based on the MCC (Merchant Category code).
  • the invention also relates to a processing system for implementing the method of controlling a transaction associated with a payment card held by a user subject to a decision maker according to the invention, the system of treatment including:
  • the back-end processing module and the bank processing module include servers in REDIS architecture.
  • the back-end processing module further comprises a queue manager used with the REDIS server to receive authorization / prohibition requests in order to schedule them, store them in a database. data, then send them in an orderly manner by an engine to the bank processing module via a communication network.
  • the invention further relates to a computer program comprising instructions which lead the processing system according to the invention to execute the steps of the method according to the invention.
  • FIG. 1 schematically describes the main steps of parental control according to the invention
  • FIG. 1 [017] [Fig 2] describes in detail the components of the decision-maker side processing system
  • FIG 4 schematically represents a complementary list of authorizations / prohibitions of a decision-maker.
  • FIG. 1 With reference to [Fig 1] and [Fig 2], there is shown a system for processing a bank transaction associated with a CARD payment card held by a UTI user subject to a DEC decision maker.
  • Parental control is built around a software platform allowing the management of the use of a CARD payment method for the benefit of a user (for example a child) subject to a decision maker (for example a parent. ).
  • the DEC decision-maker controls / authorizes / approves the monetary use for the benefit of the UTI user at different levels.
  • the first level of control consists of the activation or not of an online CARD payment method.
  • the second level of control consists of establishing rules for using the CARD payment method.
  • a third level of control consists of whether or not the DEC decision maker authorizes the unlocking of a secure amount of money (pot) from the platform, and cannot be used without specific authorization from the decision-maker, the beneficiary then being subject to the approval of the decision-maker as to the purpose of the purchase for which the secured sum is intended.
  • the MCC Merchant Category code
  • the MCC Merchant Category code
  • this category is then itself compared to an authorized / prohibited category list created upstream by the decision-maker, and making it possible to refuse / accept payment by this specific payment medium (such as bank card, mobile, ).
  • the MCC merchant category is a code made up of 4 numeric characters. It allows you to list a service, sector of activity or product of a merchant. From this code, the nature of the products sold by the merchant can be linked to a class of products which may or may not be the subject of special authorization.
  • Parental control is here associated with a payment service mainly geared towards minors, in which the default blockings of certain MCC codes and others, left to the choice of each decision-maker (parent) because they do not '' it is not a question of taking the place of the parent but more of equipping them which allows them to provide reassurance to parents, cards issued in the name and placed in the hands of users (children) can only be used at merchants listed in advance.
  • the MCC codes which are the subject of a special authorization are illustrated with reference to [Fig. 3] and [Fig. 4], These MCCs organized by "family" can be blocked BLO and unblocked DEBC by individualized CAT block in CAT1 to CAT9.
  • the decision maker DEC moves the CURS cursor of each CAT block from the blocked BLO position to the unlocked DEBC position and vice versa according to his will with regard to the user.
  • the CAT blocks correspond to:
  • - Digital CAT4 o Games 5816 o Culture: 5815, 5818,4899, o Applications (Google & Apple store): 5817 o Phone / internet credits: 4813,4814,4816; - CAT5 Loisirs (cinema, sports, game rooms): 7832, 791 1, 7922, 7929, 7932, 7933, 7941, 7991, 7992, 7993, 7994, 7996, 7997, 7998,7999, 7032, 7033, 7829, 7833.7841; and
  • the software platform comprises an architecture with two branches, one on the decision-maker side (backbone) materialized by a back-end processing module MOD_DEC and the other banking side (front-end) materialized by a MAR_BANK banking server , and a MOD_MAR front-end processing module.
  • a backbone decision-maker side
  • MOD_DEC decision-maker side
  • front-end banking side
  • MOD_MAR front-end processing module a MOD_MAR front-end processing module.
  • Such an architecture allows the control or limitation of monetary / banking movements for the benefit of the user from a specific intermediary virtual banking institution MARK_BANK to the platform to a third party entity such as commerce, e-commerce and other MAR.
  • the banking module (front-end) MAR_BANK and the back-end module MOD_DEC each comprise REDIS-type data servers, containing the different configurations of authorizations / prohibitions emanating from the decision-maker.
  • These SER_DEC data servers and bank servers have the particularity of being mirrored, that is to say that the data contained in the SER_DEC back-end server is stored identically and in real time in the MAR_BANK front-end server.
  • a queue manager of the BULL type is used with the back-end server SER_DEC (scalable key-value database management system) to receive authorization / prohibition requests, schedule them, store them in a database BDD data, then send them in an orderly manner via an ENG_DEC motor to the front banking module MAR_BANK via a RES communication network.
  • SER_DEC scalable key-value database management system
  • step E1 the back-end processing module MOD_DEC (in practice a SER_DEC server, FIG. 2) receives from the decision-maker DEC a list of prohibitions / payment transaction authorizations to the detriment / benefit of the UTI user of the CARD payment card.
  • the payment transaction prohibition / authorization includes at least one MCC merchant activity code linked to the payment transaction.
  • the back-end server SER_DEC receives the choices made by the decision-maker and creates a corresponding list of payment transactions prohibited / authorized by the decision-maker to the detriment / benefit of the UTI user of the CARD card accompanied by the associated activity codes MCC, and
  • step S3 the back-end server SER_DEC sends in real time via the ENG_DEC engine and the RES communication network the list of prohibited / authorized payment transactions thus created to a (front) bank server MARK_BANK.
  • step E2 in response to a payment transaction request from the UTI user to a MOD-MAR payment terminal of a MAR merchant using the credit card. payment of the user CARD, the front-end processing module MOD_MAR of the terminal will send (according to step E3, FIG. 1) a payment request intended for the banking server MAR BANK.
  • the payment request comprises at least the activity code of the merchant linked to the payment transaction.
  • the MAR_BANK bank processing module dynamically stores in memory the list of prohibited / authorized payment transactions for the user of the payment card, along with the associated activity codes.
  • step E4 the MAR_BANK banking processing module receives the payment request in order to instantly extract the activity code of the merchant linked to the purchase.
  • step E5 the code thus extracted is compared with those of the list of prohibited / authorized payment transactions.
  • step E6 in the event of a positive comparison, the payment is refused for the user of the payment card, otherwise in the event of a negative comparison, the payment is authorized.
  • V 1 X; P: OK If (V 1 X; P: OK) and the payment transaction is authorized (if the other limits are respected, i.e. daily expenditure limit)
  • the platform's authorizations and permissions control and management system offers the decision-maker (for example, parent) the ability to define purchasing rules, based on the category and field of activity of a merchant.
  • MCC codes Manufacturing Category Code
  • the parental control system allows a parent to activate / deactivate categories / types of merchants in real time according to their wishes.
  • Authorization management is carried out by creating and assigning to users (children) blacklists which identify all the MCC codes which are prohibited for the user (for example, child) by the decision maker (for example, parent) in this case.
  • the decision maker can configure the child's card by authorizing / prohibiting specific categories of activities.
  • the categories identified and available are: Fashion CAT1, Cosmetics CAT2, Digital CAT3, Leisure CAT4, Restaurants CAT5, Fast-food CAT6, Travel CAT7, Mobility CAT8, Fuel, CAT9.
  • These categories can be made up of subcategories.
  • This new blacklist (and / or the version updated by the change of a parameter) is saved in the BDD database then made available to the banking service provider MAR_BANK so that the latter can take into account the new specific configuration elements. from the menu.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Child & Adolescent Psychology (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Contrôle parental d'une transaction associée à une carte de paiement (CARD) détenue par un utilisateur (UTI) assujetti à un décideur (DEC). Le système de traitement comprend un module de traitement dorsal (MOD_DEC) apte : -à recevoir en provenance du décideur (DEC) une liste de transactions de paiement interdites/autorisées au détriment/profit de l'utilisateur (UTI) de la carte de paiement, chaque transaction de paiement comprenant un code d'activité du commerçant lié à la transaction de paiement; et -à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un serveur bancaire (MOD_BANK); - un module de traitement frontal (MOD_MAR) propre : -en réponse à une demande de transaction de l'utilisateur auprès d'un terminal d'un commerçant de la carte de paiement de l'utilisateur; à émettre une requête à destination du module de traitement bancaire (MOD_BANK), ladite requête comprenant au moins le code d'activité du commerçant lié à la transaction de paiement; - un module de traitement bancaire (MOD_BANK) propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l'utilisateur de la carte; -à recevoir la requête de paiement afin d'en extraire instantanément le code d'activité du commerçant lié à l'achat; -à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites; et -en cas de comparaison positive à interdire en temps réel le paiement pour l'utilisateur de la carte de paiement -en cas de comparaison négative à autoriser le paiement.

Description

Description
Titre de l'invention : Contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur
[001 ] |La présente invention concerne un contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur.
[002] Elle trouve une application générale dans le commerce électronique et plus particulièrement dans les services de paiement destinés aux mineurs/ adolescents afin de favoriser leur autonomie, et leur éducation financière.
[003] On connaît déjà des plateformes de commerce électronique qui permettent à un parent (décideur) de valider une demande d’achat émanant d’un adolescent (utilisateur) sur la base des détails associés à la demande d’achat.
[004] Par exemple, dans le document WO 2017/027533 A1 (GREENLIGHT ME, INC.) l’adolescent saisit les détails d’un article qu’il souhaite acheter. La plateforme notifie le parent de l’achat souhaité et attend son approbation avant d’autoriser la transaction. Une telle plateforme de commerce électronique offre un contrôle parental organisé autour de notifications envoyées systématiquement au décideur à chaque demande d’achat de l’utilisateur. La mise en œuvre du contrôle parental est relativement lourde car elle exige ici l’approbation de l’achat par le décideur sur la base d’une demande très détaillée de l’achat selon : la date, le montant, et la nature de l’achat. De plus, le contrôle parental ne garantit pas techniquement le fait qu’une fois la demande d’achat approuvée par le décideur, l’utilisateur va effectivement acheter le bien considéré.
[005] La présente invention remédie à ces inconvénients. [006] L’invention porte sur un procédé de contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur.
[007] Selon une définition générale de l’invention, le système de traitement comprend :
-un module de traitement dorsal apte :
-à recevoir en provenance du décideur une liste de transactions de paiement interdites/autorisées au détriment/profit de l’utilisateur de la carte de paiement, chaque transaction de paiement comprenant un code d’activité du commerçant lié à la transaction de paiement ; et
-à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un module de traitement bancaire ;
-un module de traitement frontal propre :
-en réponse à une demande de transaction de paiement de l’utilisateur auprès d’un terminal de paiement d’un commerçant à l’aide de la carte de paiement de l’utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire, ladite requête de paiement comprenant au moins le code d’activité du commerçant lié à la transaction de paiement ;
-le module de traitement bancaire étant propre,
-à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l’utilisateur de la carte de paiement ;
-à recevoir la requête de paiement afin d’en extraire instantanément le code d’activité du commerçant lié à l’achat ;
-à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites/autorisées ; et
-en cas de comparaison positive à interdire en temps réel le paiement pour l’utilisateur de la carte de paiement sinon -en cas de comparaison négative à autoriser le paiement. [008] Grâce à l’invention, la mise en œuvre du contrôle parental est souple et peu contraignante par rapport à l’art antérieur. En effet, la liste des transactions interdites/autorisées est créée au préalable par « catégories d’achat » en amont de l’achat par le décideur. Il en résulte que l’achat est autorisé ou rejeté sans attendre l’approbation effective du décideur. De plus le décideur maîtrise les achats de l’utilisateur par « catégorie d’achats », en amont de l’achat, et sans contrainte de l’utilisateur sur le décideur. Enfin, le contrôle parental fondé sur les codes d’activité des commerçants garantit techniquement que l’autorisation de l’achat porte bien sur une catégorie d’achats autorisée par le décideur.
[009] De façon surprenante, le Demandeur a observé que la garantie technique du contrôle parental s’appuie sur des règles préalablement établies par le décideur et qui sont corrélées avec l’identification du type de commerce interrogé par le moyen de paiement lors de l’achat. En effet, lors de l’achat, le code d’activité appelé MCC (Merchant Category code) du commerce est comparé selon l’invention, à une liste permettant d’établir la/les catégorie(s) de biens ou services proposés par le commerce, cette catégorie étant alors elle- même comparée à une liste de catégories autorisées/interdites créée en amont par le décideur, et permettant de refuser/accepter le paiement par ce médium de paiement spécifique (de type carte bancaire, mobile, ... ).
[010] Selon un mode de réalisation de l’invention, le code d’activité du commerçant est basé sur le MCC (Merchant Category code).
[01 1 ] L’invention porte aussi sur un système de traitement pour la mise en œuvre du procédé de contrôle d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur conforme à l’invention, le système de traitement comprenant :
-un module de traitement dorsal apte :
-à recevoir en provenance du décideur une liste de transactions de paiement interdites/autorisées au détriment/profit de l’utilisateur de la carte de paiement, chaque transaction de paiement comprenant un code d’activité du commerçant lié à la transaction de paiement ; et
-à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un module de traitement bancaire ;
-un module de traitement frontal propre :
-en réponse à une demande de transaction de paiement de l’utilisateur auprès d’un terminal de paiement d’un commerçant à l’aide de la carte de paiement de l’utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire, ladite requête de paiement comprenant au moins le code d’activité du commerçant lié à la transaction de paiement ;
-le module de traitement bancaire étant propre,
-à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l’utilisateur de la carte de paiement ;
-à recevoir la requête de paiement afin d’en extraire instantanément le code d’activité du commerçant lié à l’achat ;
-à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites ; et
-en cas de comparaison positive à interdire en temps réel le paiement pour l’utilisateur de la carte de paiement sinon -en cas de comparaison négative à autoriser le paiement.
[012] En pratique, le module de traitement dorsal et le module de traitement bancaire comprennent des serveurs en architecture REDIS.
[013] Selon un mode de réalisation de l’invention, le module de traitement dorsal comprend en outre un gestionnaire de queues utilisé avec le serveur REDIS pour recevoir les demandes d’autorisation/interdiction afin de les ordonnancer, les stocker dans une base de données, puis de les envoyer de manière ordonnée par un moteur vers le module de traitement bancaire via un réseau de communication. [014] L’invention porte en outre sur un programme d'ordinateur comprenant des instructions qui conduisent le système de traitement conforme à l’invention, à exécuter les étapes du procédé selon l’invention.
[015] D'autres caractéristiques et avantages de l’invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels :
[016] [Fig 1] décrit schématiquement les étapes principales du contrôle parental conforme à l’invention ;
[017] [Fig 2] décrit en détail les composants du système de traitement côté décideur ;
[018] [Fig 3] représente schématiquement une liste d’autorisations
/interdictions d’un décideur ; et
[019] [Fig 4] représente schématiquement une liste complémentaire d’autorisations/interdictions d’un décideur.
[020] En référence aux [Fig 1] et [Fig 2], on a représenté un système de traitement d’une transaction bancaire associée à une carte de paiement CARD détenue par un utilisateur UTI assujetti à un décideur DEC.
[021 ] Le contrôle parental s’articule autour d’une plateforme logicielle permettant la gestion de l’utilisation d’un moyen de paiement CARD au profit d’un utilisateur (par exemple un enfant) assujetti à un décideur (par exemple un parent).
[022] En pratique, le décideur DEC contrôle/autorise/approuve l’utilisation monétaire au profit de l’utilisateur UTI à différents niveaux.
[023] Le premier niveau de contrôle consiste en l’activation ou non d’un moyen de paiement CARD en ligne.
[024] Le second niveau de contrôle consiste en l’établissement de règles d’utilisation du moyen de paiement CARD.
[025] Un troisième niveau de contrôle consiste en ce que le décideur DEC autorise ou non le déverrouillage d’une quantité d’argent sécurisée (cagnotte) depuis la plateforme, et non utilisable sauf autorisation spécifique du décideur, le bénéficiaire étant alors soumis à l’approbation du décideur quant au but de l’achat auquel la somme sécurisée est destinée.
[026] Les règles d’utilisation du moyen de paiement CARD peuvent être les suivantes :
1 ) -la fixation d’un seuil de dépenses sur un délai donné ;
2) -Minima et maxima de retrait ;
3) -catégories d’achats/commerces validées ou non (interdites/ autorisées) par le décideur.
[027] De façon surprenante, le Demandeur a observé que les règles préalablement établies par le décideur peuvent être corrélées avec l’identification du type de commerce interrogé par le moyen de paiement lors de l’achat.
[028] Comme on le décrira plus en détail ci-après lors de l’achat, le MCC (Merchant Category code) du commerce à payer est comparé à une liste permettant d’établir la/les catégorie(s) de biens ou services proposés par le commerce, cette catégorie étant alors elle-même comparée à une liste de catégorie autorisée/interdite créée en amont par le décideur, et permettant de refuser/accepter le paiement par ce médium de paiement spécifique (de type carte bancaire, mobile, ... ).
[029] En pratique, la catégorie de marchands MCC est un code composé de 4 caractères numériques. Il permet de répertorier un service, secteur d'activité ou produit d’un commerçant. À partir de ce code, la nature des produits vendus par le marchand peut être rattachée à une classe de produits qui peut faire l’objet d’une autorisation particulière ou non.
[030] Le contrôle parental est ici associé à un service de paiement principalement tourné vers les mineurs, dans lequel des blocages par défaut de certains codes MCC et d’autres, laissés au choix de chaque décideur (parent) parce qu’il ne s’agit pas de se substituer au parent mais davantage de l’outiller ce qui permet de fournir des éléments de réassurance aux parents, les cartes émises au nom et mises entre les mains des utilisateurs (enfants) ne pouvant être utilisées que chez des commerçants référencés au préalable.
[031 ] En pratique, les MCC bloqués par défaut sur toutes les Cartes CARD émises et en circulation sont les suivants : 5813 (Alcool et bars) 5921 (Vins & Liqueur) 5933 (Prêteur sur gage) 5993 (Boutiques de cigares) 7273 (Dating) 7800, 7801 , 7802 (Loteries & Casino) 7995 (Paris en ligne), [3300- 3499] :
3351 , 3352, 3353, 3354, 3355, 3357, 3359, 3360,3361 , 3362, 3364, 3366,
3368, 3370, 3374, 3376, 3380, 3381 , 3385, 3386, 3387, 3388, 3389, 3390,
3391 , 3393, 3394, 3395,3396, 3398, 3400, 3405, 3409, 3412 (Loueurs de voiture).
[032] En revanche, les codes MCC faisant l’objet d’une autorisation particulière (laissée à la main de chaque décideur sont illustrés en référence aux [Fig. 3] et [Fig. 4], Ces MCC organisés par « famille » peuvent être bloqués BLO et débloqués DEBC par bloc CAT individualisés en CAT1 à CAT9. Le décideur DEC déplace le curseur CURS de chaque bloc CAT de la position bloquée BLO à la position débloquée DEBC et vice versa selon sa volonté à l’égard de l’utilisateur.
[033] A titre d’exemple non limitatif, les blocs CAT correspondent à :
- CAT1 Mode : 5611 , 5621 , 5631 , 5641 , 5651 , 5655, 5661 , 5681 , 5691 , 5697, 5698, 5699, 7631 , 5094, 5137, 5139, 5931 , 5941 ,5944,5948, 5949, 7296 ;
- CAT2 Cosmétique : 5977,7230 ;
- CAT3 Hi-Tech :5732, 5734,4812, 5072, 5045, 5044, 5065, 5251 , 5946, 7622,7379, 7372 ;
- CAT4 Numérique o Jeux: 5816 o Culture: 5815, 5818,4899, o Applications (Google & Apple store): 5817 o Crédits téléphone/internet: 4813,4814,4816; - CAT5 Loisirs (cinéma, sports, salles de jeux) : 7832, 791 1 ,7922, 7929, 7932, 7933, 7941 , 7991 , 7992, 7993, 7994, 7996, 7997, 7998,7999, 7032, 7033, 7829, 7833,7841 ; et
- CAT6 Restaurants & Fast-food : 581 1 ,5812, 5814
- CAT7 Voyage (compagnies aériennes, hôtel) : [3000 ; 3299], [3500-3999]
- CAT8 Mobilité (VTC, Vélib’, Cityscoot) : 4121 , 731 1
- CAT9 Carburant : 5541 , 5542
[034] On fait à nouveau référence aux figures 1 et 2.
[035] D’une manière structurelle, la plateforme logicielle comporte une architecture à deux branches, l’une côté décideur (dorsal) matérialisé par un module de traitement dorsal MOD_DEC et l’autre côté bancaire (frontal) matérialisé par un serveur bancaire MAR_BANK, et un module de traitement frontal MOD_MAR. Une telle architecture permet le contrôle ou la limitation de mouvements monétaires/bancaires au profit de l’utilisateur à partir d’un établissement virtuel bancaire intermédiaire spécifique MARK_BANK à la plateforme vers une entité tierce de type commerce, e-commerce et autres MAR.
[036] De manière fonctionnelle, le module bancaire (frontal) MAR_BANK et le module dorsal MOD_DEC comprennent chacun des serveurs de données de type REDIS, contenant les différentes configurations d’autorisations/interdictions émanant du décideur. Ces serveurs de données SER_DEC et les serveurs bancaires ont la particularité d’être en miroir, c’est- à-dire que les données contenues dans le serveur dorsal SER_DEC sont stockées à l’identique et en temps réel dans le serveur frontal MAR_BANK.
[037] Afin d’assurer la consistance des données, ainsi qu’un fonctionnement en temps réel avec la prise en compte de multiples demandes de modification simultanées émanant des décideurs, un gestionnaire de queues de type BULL est utilisé avec le serveur dorsal SER_DEC (système de gestion de base de données clef-valeur scalable) pour recevoir les demandes d’autorisation/interdiction, les ordonnancer, les stocker dans une base de données BDD, puis de les envoyer de manière ordonnée via un moteur ENG_DEC vers le module bancaire frontal MAR_BANK via un réseau de communication RES. Une telle gestion permet d’éviter de bloquer la plateforme dans des transactions synchrones, qui baisseraient les performances de la plateforme, mais aussi d’éviter toute perte de données durant des transactions multiples.
[038] En référence aux figures 1 et 2, on va maintenant illustrer les étapes de fonctionnement du contrôle parental conformes à l’invention.
[039] Selon l’étape E1 (figure 1) ou selon l’étape S1 (figure 2), le module de traitement dorsal MOD_DEC (en pratique un serveur SER_DEC, figure 2) reçoit en provenance du décideur DEC une liste d’interdictions/autorisations de transaction de paiement au détriment/profit de l’utilisateur UTI de la carte de paiement CARD.
[040] L’interdiction/autorisation de transaction de paiement comprend au moins un code d’activité du commerçant MCC lié à la transaction de paiement.
[041 ] Le serveur dorsal SER_DEC reçoit les choix effectués par le décideur et crée en correspondance une liste de transactions de paiement interdites/autorisées par le décideur au détriment/profit de l’utilisateur UTI de la carte CARD accompagnées des codes d’activité associés MCC, et
[042] Selon l’étape S3 (figure 2) le serveur dorsal SER_DEC envoie en temps réel via le moteur ENG_DEC et le réseau de communication RES la liste de transactions de paiement interdites/autorisées ainsi créée à un serveur bancaire (frontal) MARK_BANK.
[043] Selon l’étape E2 (figure 1), en réponse à une demande de transaction de paiement de l’utilisateur UTI auprès d’un terminal de paiement MOD-MAR d’un commerçant MAR à l’aide de la carte de paiement de l’utilisateur CARD, le module de traitement frontal MOD_MAR du terminal va émettre (selon l’étape E3, figure 1 ) une requête de paiement à destination du serveur bancaire MAR BANK. [044] La requête de paiement comprend au moins le code d’activité du commerçant lié à la transaction de paiement.
[045] Le module de traitement bancaire MAR_BANK stocke dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l’utilisateur de la carte de paiement accompagnées des codes d’activité associés.
[046] Selon l’étape E4, le module de traitement bancaire MAR_BANK reçoit la requête de paiement afin d’en extraire instantanément le code d’activité du commerçant lié à l’achat.
[047] Selon l’étape E5, le code ainsi extrait est comparé à ceux de la liste des transactions de paiement interdites/autorisées.
[048] Selon l’étape E6, en cas de comparaison positive, le paiement est refusé pour l’utilisateur de la carte de paiement sinon en cas de comparaison négative, le paiement est autorisé.
[049] Par exemple, si X est un code MCC bloqué par le décideur (parent) dans sa tour de Contrôle parental (Figures 3 et 4) ; P le moyen de paiement de l’utilisateur (enfant) ; et V, le terminal de paiement/vente à distance composé de plusieurs MCC sur lequel l’utilisateur (enfant) essaie d’effectuer une opération alors :
- Si (V contient X ; P ¹ 0) et l’opération de paiement est rejetée ;
- Si (V ¹ X ; P : OK) et l’opération de paiement est autorisée (si les autres plafonds sont respectés, i.e. plafond de dépenses quotidiennes)
47. Le système de contrôle et de gestion des autorisations et permissions de la plateforme offre la possibilité au décideur (par exemple, parent) de définir des règles d’achats, basées sur la catégorie et le domaine d’activité d’un marchand.
[048] Comme déjà décrit, la particularité technique du contrôle parental réside ici dans le fait que ces restrictions sont construites en se basant sur les codes MCC (Merchant Category Code). Il s’agit d’un code utilisé lors d’une « il
transaction de paiement ou de retrait réalisée avec une carte bancaire pour indiquer le type d’activité du commerçant à l’origine d’une opération.
[049] Le dispositif de contrôle parental permet à un parent d’activer/désactiver en temps réel des catégories/types de marchands en fonction de ses souhaits.
[050] La gestion des autorisations est effectuée en créant et en affectant aux utilisateurs (enfant) des listes noires (Blacklists) qui recensent l’ensemble des codes MCC qui sont interdits pour l’utilisateur (par exemple, enfant) par le décideur (par exemple, parent) dans ce cas d’espèce.
[051 ] Par défaut, tous les comptes utilisateurs enfants ont une Blacklist qui leur est affectée et qui interdit un ensemble de « types d’activités » non accepté pour la clientèle mineure (Alcool et bars - Vins & Liqueur - Prêteur sur gage - Boutiques de cigares - Dating - Loteries & Casino - Paris en ligne, Voyages).
[052] Cette liste de MCC est bloquée pour tous les utilisateurs.
[053] Le décideur peut procéder à la configuration de la carte de l’enfant en autorisant/interdisant des catégories d’activités particulières.
[054] Cela entraîne la création d’une blacklist personnalisée aux autorisations particulières (en plus des restrictions communes par défaut) qui sera affectée particulièrement à la carte de son enfant.
[055] La gestion des autorisations de paiement par MCC passe plusieurs étapes débutant par la catégorisation des MCC par types de domaines pertinents afin de faciliter la compréhension par le prescripteur (par exemple, parent).
[056] Par exemple, les catégories identifiées et disponibles sont : Mode CAT1 , Cosmétique CAT2, Numérique CAT3, Loisirs CAT4, Restaurants CAT5, Fast-food CAT6, Voyage CAT7, Mobilité CAT8, Carburant, CAT9.
[057] Ces catégories peuvent être constituées de sous-catégories. [058] C’est par exemple le cas de la catégorie Numérique qui comporte les sous-catégories suivantes : Jeux, Culture, Applications (Google & Apple store), Crédits téléphone/internet.
[059] Cela donne la possibilité au parent de disposer d’un niveau de granularité plus avancé dans la gestion des autorisations.
[060] Le parent a accès, au niveau de son interface utilisateur « cockpit », à un ensemble d’options qu’il peut activer/désactiver afin de permettre les achats dans ces types de commerce spécifiques. Cet écran est visible dans l’interface applicative décrite en référence aux [Fig 3] et [Fig 4].
[061 ] Lorsque le parent apporte des modifications au niveau des autorisations, celles-ci sont automatiquement, et de manière instantanée, sauvegardées et prises en compte au niveau de la configuration de la carte de paiement.
[062] Cela se fait par la création instantanée d’une nouvelle blacklist pour l’enfant (s’il n’en a pas déjà une). Cette nouvelle blacklist (et/ou la version mise à jour par le changement d’un paramètre) est sauvegardée dans la base de données BDD puis mise à disposition du prestataire bancaire MAR_BANK afin que ce dernier puisse prendre en compte les nouveaux éléments de paramétrage spécifique de la carte.

Claims

Revendications
[Revendication 1 ] | Procédé de contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement (CARD) détenue par un utilisateur (UTI) assujetti à un décideur (DEC), caractérisé en ce que le système de traitement comprend :
-un module de traitement dorsal (MOD_DEC) apte
-à recevoir en provenance du décideur (DEC) une liste de transactions de paiement interdites/autorisées au détriment/profit de l’utilisateur (UTI) de la carte de paiement, chaque transaction de paiement comprenant un code d’activité du commerçant lié à la transaction de paiement ; et
-à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un module de traitement bancaire (MOD_BANK).
-un module de traitement frontal (MOD_MAR) propre :
-en réponse à une demande de transaction de paiement de l’utilisateur auprès d’un terminal de paiement d’un commerçant à l’aide de la carte de paiement de l’utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire (MOD_BANK), ladite requête de paiement comprenant au moins le code d’activité du commerçant lié à la transaction de paiement ;
-le module de traitement bancaire (MOD_BANK) étant propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l’utilisateur de la carte de paiement ;
-à recevoir la requête de paiement afin d’en extraire instantanément le code d’activité du commerçant lié à l’achat ;
-à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites/autorisées ; et
-en cas de comparaison positive à interdire en temps réel le paiement pour l’utilisateur de la carte de paiement sinon ;
-en cas de comparaison négative à autoriser le paiement.
[Revendication 2] Procédé selon la revendication 1 , caractérisé en ce que le code d’activité du commerçant est basé sur le MCC (Merchant Category code).
[Revendication 3] Procédé selon la revendication 1 ou la revendication 2 dans lequel des règles préalablement établies par le décideur (DEC) sont corrélées avec le code d’activité du commerçant transmis par le module de traitement bancaire (MOD_BANK) lors de l’achat.
[Revendication 4] Système de traitement pour la mise en œuvre du procédé de contrôle d’une transaction associée à une carte de paiement (CARD) détenue par un utilisateur (UTI) assujetti à un décideur (DEC) selon l’une des revendications 1 à 3, caractérisé en ce que le système de traitement comprend :
-un module de traitement dorsal (MOD_DEC) apte
-à recevoir en provenance du décideur (DEC) une liste de transactions de paiement interdites/autorisées au détriment/profit de l’utilisateur (UTI) de la carte de paiement, chaque transaction de paiement comprenant un code d’activité du commerçant lié à la transaction de paiement ; et -à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un module de traitement bancaire (MOD_BANK).
-un module de traitement frontal (MOD_MAR) propre :
-en réponse à une demande de transaction de paiement de l’utilisateur auprès d’un terminal de paiement d’un commerçant à l’aide de la carte de paiement de l’utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire (MOD_BANK), ladite requête de paiement comprenant au moins le code d’activité du commerçant lié à la transaction de paiement ;
-le module de traitement bancaire (MOD_BANK) étant propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l’utilisateur de la carte de paiement ;
-à recevoir la requête de paiement afin d’en extraire instantanément le code d’activité du commerçant lié à l’achat ; -à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites/autorisées ; et
-en cas de comparaison positive à interdire en temps réel le paiement pour l’utilisateur de la carte de paiement sinon -en cas de comparaison négative à autoriser le paiement.
[Revendication 5] Système de traitement selon la revendication 4, caractérisé en ce que le module de traitement dorsal (MOD_DEC) et le module de traitement bancaire (MOD_BANK) comprennent des serveurs respectifs (SER_DEC) et (MAR_BANK) en architecture REDIS.
[Revendication 6] Système de traitement selon la revendication 4, caractérisé en ce que le module de traitement dorsal (MOD_DEC) comprend en outre un gestionnaire de queues utilisé avec le serveur REDIS (RED_DEC) pour recevoir les demandes d’autorisation/interdiction afin de les ordonnancer, les stocker dans une base de données (BDD), puis de les envoyer de manière ordonnée par un moteur (ENG_DEC) vers le module de traitement bancaire (MAR_BANK) via un réseau de communication (RES).
[Revendication 7] Système de traitement selon la revendication 5 dans lequel les données contenues dans le serveur dorsal (SER_DEC) sont stockées à l’identique et en temps réel dans le serveur frontal (MAR_BANK).
[Revendication 8] Programme d'ordinateur comprenant des instructions qui conduisent le système de traitement selon l’une des revendications 4 à 7, à exécuter les étapes du procédé selon l’une des revendications 1 à 3.
PCT/EP2020/060472 2019-04-11 2020-04-14 Contrôle parental mis en œuvre dans un systeme de traitement d'une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur WO2020208262A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR1903875 2019-04-11
FR1903875A FR3095066B1 (fr) 2019-04-11 2019-04-11 Contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur

Publications (1)

Publication Number Publication Date
WO2020208262A1 true WO2020208262A1 (fr) 2020-10-15

Family

ID=68281510

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/060472 WO2020208262A1 (fr) 2019-04-11 2020-04-14 Contrôle parental mis en œuvre dans un systeme de traitement d'une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur

Country Status (2)

Country Link
FR (1) FR3095066B1 (fr)
WO (1) WO2020208262A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022197392A1 (fr) * 2021-03-16 2022-09-22 Mastercard International Incorporated Procédé et système d'autorisation de transaction sélective

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030036998A1 (en) * 2001-04-05 2003-02-20 Alliston R. Michael Method and system for detecting incorrect merchant code used with payment card transaction
US20110078042A1 (en) * 2009-09-29 2011-03-31 Ebay Inc. System and method for facilitating electronic commerce with controlled spending over a network
WO2017027533A1 (fr) 2015-08-10 2017-02-16 GreenLight Me, Inc. Plateforme d'approbation de paiement
US9741026B1 (en) * 2014-09-30 2017-08-22 Square, Inc. Payment by use of identifier
US9881305B1 (en) * 2014-05-06 2018-01-30 Square, Inc. Context-based restrictions on payment cards

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030036998A1 (en) * 2001-04-05 2003-02-20 Alliston R. Michael Method and system for detecting incorrect merchant code used with payment card transaction
US20110078042A1 (en) * 2009-09-29 2011-03-31 Ebay Inc. System and method for facilitating electronic commerce with controlled spending over a network
US9881305B1 (en) * 2014-05-06 2018-01-30 Square, Inc. Context-based restrictions on payment cards
US9741026B1 (en) * 2014-09-30 2017-08-22 Square, Inc. Payment by use of identifier
WO2017027533A1 (fr) 2015-08-10 2017-02-16 GreenLight Me, Inc. Plateforme d'approbation de paiement

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Redis - Wikipedia", 9 April 2019 (2019-04-09), pages 1 - 7, XP055697653, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Redis&oldid=891723788> [retrieved on 20200522] *
LEEA TAEYOUNG ET AL: "Abnormal Payment Transaction Detection Scheme Based on Scalable Architecture and Redis Cluster", 2018 INTERNATIONAL CONFERENCE ON PLATFORM TECHNOLOGY AND SERVICE (PLATCON), IEEE, 29 January 2018 (2018-01-29), pages 1 - 6, XP033408542, DOI: 10.1109/PLATCON.2018.8472732 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022197392A1 (fr) * 2021-03-16 2022-09-22 Mastercard International Incorporated Procédé et système d'autorisation de transaction sélective

Also Published As

Publication number Publication date
FR3095066B1 (fr) 2021-07-09
FR3095066A1 (fr) 2020-10-16

Similar Documents

Publication Publication Date Title
US7082416B2 (en) Method of using prepaid cash card for making purchases on the world wide web
US9495703B1 (en) Automatic budgeting system
US20020099648A1 (en) Method of reducing fraud in credit card and other E-business
FR2811787A1 (fr) Methode pour valider un paiement electronique avec une carte de credit
WO1996032701A1 (fr) Procede de paiement electronique permettant d&#39;effectuer des transactions liees a l&#39;achat de biens sur un reseau informatique
US11928654B2 (en) Application program interface for conversion of stored value cards
WO2002075679A2 (fr) Systeme et procede de paiement anonyme
EP1299838A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
US20020069139A1 (en) Method of conducting transactions using a distributed computer network such as the internet
WO2020208262A1 (fr) Contrôle parental mis en œuvre dans un systeme de traitement d&#39;une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur
Możdżyński The conceptions of new payment methods based on revised payment services directive (PSD2)
NO315727B1 (no) Betalingskort og tilhörende fremgangsmåte
CN111833187A (zh) 一种基于流动性的一键式金融产品交易方法、装置和系统
WO2015195815A1 (fr) Système et procédé pour gérer une transaction de paiement
US20130024218A1 (en) Apparatus and method for expedited event access
FR2823882A1 (fr) Procede et systeme de validation de paiement
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d&#39;information bancaire sur le reseau public et quasi-public
CN110073388A (zh) 安全支付的方法和系统
EP1301910B1 (fr) Procede pour securiser une transaction via un reseau de telecommunication, et systeme de mise en oeuvre du procede
AU729758B3 (en) Electronic commerce system and method
Sutherland Merger control in the age of digital markets
WO2023247737A1 (fr) Methode et systeme d&#39;assistance d&#39;echanges controles de donnees
Murray Breaking Benjamin: Security Threats in Mobile Payment Applications
TR2021020879A2 (tr) Bi̇r eşleni̇k kart kullanim si̇stemi̇
FR2792088A1 (fr) Procede de paiement securise et dispositif pour la mise en oeuvre d&#39;un tel procede

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20723013

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20723013

Country of ref document: EP

Kind code of ref document: A1