FR3095066A1 - 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 - Google Patents
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 Download PDFInfo
- Publication number
- FR3095066A1 FR3095066A1 FR1903875A FR1903875A FR3095066A1 FR 3095066 A1 FR3095066 A1 FR 3095066A1 FR 1903875 A FR1903875 A FR 1903875A FR 1903875 A FR1903875 A FR 1903875A FR 3095066 A1 FR3095066 A1 FR 3095066A1
- Authority
- FR
- France
- Prior art keywords
- payment
- bank
- user
- processing module
- mod
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000012545 processing Methods 0.000 title claims abstract description 55
- 230000000694 effects Effects 0.000 claims abstract description 29
- 230000008901 benefit Effects 0.000 claims abstract description 11
- 230000004044 response Effects 0.000 claims abstract description 6
- 238000013475 authorization Methods 0.000 claims description 17
- 238000000034 method Methods 0.000 claims description 8
- 238000004891 communication Methods 0.000 claims description 4
- 238000004590 computer program Methods 0.000 claims description 2
- 229920000168 Microcrystalline cellulose Polymers 0.000 description 5
- 208000017763 cutaneous neuroendocrine carcinoma Diseases 0.000 description 5
- 235000019813 microcrystalline cellulose Nutrition 0.000 description 5
- 238000011144 upstream manufacturing Methods 0.000 description 4
- VFYUVMGJOFRPRT-UHFFFAOYSA-N (1-$l^{1}-oxidanyl-2,2,6,6-tetramethylpiperidin-4-yl)-dimethyl-nonylazanium Chemical compound CCCCCCCCC[N+](C)(C)C1CC(C)(C)N([O])C(C)(C)C1 VFYUVMGJOFRPRT-UHFFFAOYSA-N 0.000 description 3
- 101100494447 Arabidopsis thaliana CAT9 gene Proteins 0.000 description 3
- 101100494773 Caenorhabditis elegans ctl-2 gene Proteins 0.000 description 3
- 101100112369 Fasciola hepatica Cat-1 gene Proteins 0.000 description 3
- 101100005271 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) cat-1 gene Proteins 0.000 description 3
- 102100029272 5-demethoxyubiquinone hydroxylase, mitochondrial Human genes 0.000 description 2
- 101100219344 Arabidopsis thaliana CAT7 gene Proteins 0.000 description 2
- 101150013917 CAT8 gene Proteins 0.000 description 2
- 102100035959 Cationic amino acid transporter 2 Human genes 0.000 description 2
- 102100021391 Cationic amino acid transporter 3 Human genes 0.000 description 2
- 102100021392 Cationic amino acid transporter 4 Human genes 0.000 description 2
- 101710195194 Cationic amino acid transporter 4 Proteins 0.000 description 2
- LFQSCWFLJHTTHZ-UHFFFAOYSA-N Ethanol Chemical compound CCO LFQSCWFLJHTTHZ-UHFFFAOYSA-N 0.000 description 2
- 101000770593 Homo sapiens 5-demethoxyubiquinone hydroxylase, mitochondrial Proteins 0.000 description 2
- 108091006231 SLC7A2 Proteins 0.000 description 2
- 108091006230 SLC7A3 Proteins 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 235000019506 cigar Nutrition 0.000 description 2
- 230000002596 correlated effect Effects 0.000 description 2
- 239000002537 cosmetic Substances 0.000 description 2
- 235000013410 fast food Nutrition 0.000 description 2
- 239000000446 fuel Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 235000014101 wine Nutrition 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
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
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
Abrégé] 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. Figure pour l’abrégé : Figure 1
Description
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.
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.
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.
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é.
La présente invention remédie à ces inconvénients.
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.
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.
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.
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, …).
Selon un mode de réalisation de l’invention, le code d’activité du commerçant est basé sur le MCC (Merchant Category code).
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.
En pratique, le module de traitement dorsal et le module de traitement bancaire comprennent des serveurs en architecture REDIS.
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 REDISpour 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 lemodule de traitementbancairevia un réseau de communication.
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.
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 :
décrit schématiquement les étapes principales du contrôle parental conforme à l’invention ;
décrit en détail les composants du système de traitement côté décideur ;
représente schématiquement une liste d’autorisations /interdictions d’un décideur ; et
représente schématiquement une liste complémentaire d’autorisations/interdictions d’un décideur.
En référence aux 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.
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).
En pratique, le décideur DEC contrôle/autorise/approuve l’utilisation monétaire au profit de l’utilisateur UTI à différents niveaux.
Le premier niveau de contrôle consiste en l’activation ou non d’un moyen de paiement CARD en ligne.
Le second niveau de contrôle consiste en l’établissement de règles d’utilisation du moyen de paiement CARD.
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.
Les règles d’utilisation du moyen de paiement CARD peuvent être les suivantes :
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.
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.
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é.
La présente invention remédie à ces inconvénients.
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.
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.
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.
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, …).
Selon un mode de réalisation de l’invention, le code d’activité du commerçant est basé sur le MCC (Merchant Category code).
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.
En pratique, le module de traitement dorsal et le module de traitement bancaire comprennent des serveurs en architecture REDIS.
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 REDISpour 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 lemodule de traitementbancairevia un réseau de communication.
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.
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 :
En référence aux
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).
En pratique, le décideur DEC contrôle/autorise/approuve l’utilisation monétaire au profit de l’utilisateur UTI à différents niveaux.
Le premier niveau de contrôle consiste en l’activation ou non d’un moyen de paiement CARD en ligne.
Le second niveau de contrôle consiste en l’établissement de règles d’utilisation du moyen de paiement CARD.
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.
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.
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.
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, …).
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.
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.
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).
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 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.
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
Jeux: 5816
Culture: 5815, 5818,4899,
Applications (Google & Apple store): 5817
Crédits téléphone/internet: 4813,4814,4816;
CAT5 Loisirs (cinéma, sports, salles de jeux) : 7832, 7911,7922, 7929, 7932, 7933, 7941, 7991, 7992, 7993, 7994, 7996, 7997, 7998,7999, 7032, 7033, 7829, 7833,7841 ; et
CAT6 Restaurants & Fast-food : 5811,5812, 5814
CAT7 Voyage (compagnies aériennes, hôtel) : [3000 ; 3299], [3500-3999]
CAT8 Mobilité (VTC, Vélib’, Cityscoot) : 4121, 7311
CAT9 Carburant : 5541, 5542
On fait à nouveau référence auxfigures 1 et 2.
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.
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.
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 bancairefrontal 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.
En référence auxfigures 1 et 2, on va maintenant illustrer les étapes de fonctionnement du contrôle parental conformes à l’invention.
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.
L’interdiction/autorisation de transaction de paiement comprend au moins un code d’activité du commerçant MCC lié à la transaction de paiement.
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
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.
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.
La requête de paiement comprend au moins le code d’activité du commerçant lié à la transaction de paiement.
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.
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.
Selon l’étape E5, le code ainsi extrait est comparé à ceux de la liste des transactions de paiement interdites/autorisées.
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é.
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)
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.
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 « 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.
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.
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.
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).
Cette liste de MCC est bloquée pour tous les utilisateurs.
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.
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.
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).
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.
Ces catégories peuvent être constituées de sous-catégories.
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.
Cela donne la possibilité au parent de disposer d’un niveau de granularité plus avancé dans la gestion des autorisations.
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 et [Fig 4].
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.
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.
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.
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, …).
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.
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.
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).
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
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
Jeux: 5816
Culture: 5815, 5818,4899,
Applications (Google & Apple store): 5817
Crédits téléphone/internet: 4813,4814,4816;
CAT5 Loisirs (cinéma, sports, salles de jeux) : 7832, 7911,7922, 7929, 7932, 7933, 7941, 7991, 7992, 7993, 7994, 7996, 7997, 7998,7999, 7032, 7033, 7829, 7833,7841 ; et
CAT6 Restaurants & Fast-food : 5811,5812, 5814
CAT7 Voyage (compagnies aériennes, hôtel) : [3000 ; 3299], [3500-3999]
CAT8 Mobilité (VTC, Vélib’, Cityscoot) : 4121, 7311
CAT9 Carburant : 5541, 5542
On fait à nouveau référence auxfigures 1 et 2.
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.
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.
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 bancairefrontal 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.
En référence auxfigures 1 et 2, on va maintenant illustrer les étapes de fonctionnement du contrôle parental conformes à l’invention.
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.
L’interdiction/autorisation de transaction de paiement comprend au moins un code d’activité du commerçant MCC lié à la transaction de paiement.
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
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.
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.
La requête de paiement comprend au moins le code d’activité du commerçant lié à la transaction de paiement.
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.
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.
Selon l’étape E5, le code ainsi extrait est comparé à ceux de la liste des transactions de paiement interdites/autorisées.
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é.
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)
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.
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 « 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.
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.
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.
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).
Cette liste de MCC est bloquée pour tous les utilisateurs.
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.
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.
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).
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.
Ces catégories peuvent être constituées de sous-catégories.
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.
Cela donne la possibilité au parent de disposer d’un niveau de granularité plus avancé dans la gestion des autorisations.
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
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.
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 (6)
- 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. - 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).
- 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 à 2, 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. - Système de traitement selon la revendication 3, caractérisé en ce que le module de traitement dorsal (MOD_DEC) et le module de traitement bancaire (MOD_BANK) comprennent des serveurs en architecture REDIS.
- Système de traitement selon la revendication 3, 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 lemodule de traitementbancaire (MAR_BANK) via un réseau de communication (RES).
- Programme d'ordinateur comprenant des instructions qui conduisent le système de traitement selon l’une des revendications 3 à 5, à exécuter les étapes du procédé selon l’une des revendications 1 ou 2.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| 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 |
| 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 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| 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 |
| FR1903875 | 2019-04-11 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3095066A1 true FR3095066A1 (fr) | 2020-10-16 |
| FR3095066B1 FR3095066B1 (fr) | 2021-07-09 |
Family
ID=68281510
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1903875A Expired - Fee Related 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 |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3095066B1 (fr) |
| WO (1) | WO2020208262A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2606987A (en) * | 2021-03-16 | 2022-11-30 | Mastercard International Inc | A selective transaction authorisation method and system |
Citations (5)
| 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 |
-
2019
- 2019-04-11 FR FR1903875A patent/FR3095066B1/fr not_active Expired - Fee Related
-
2020
- 2020-04-14 WO PCT/EP2020/060472 patent/WO2020208262A1/fr active Application Filing
Patent Citations (5)
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020208262A1 (fr) | 2020-10-15 |
| FR3095066B1 (fr) | 2021-07-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7412797B2 (ja) | ビデオストリーミング再生システム及び方法 | |
| US20020099648A1 (en) | Method of reducing fraud in credit card and other E-business | |
| US8175926B1 (en) | Event and services inventory management system | |
| US20130268413A1 (en) | Methods and Systems for Exchanging Stored Value Using a Mobile Communication Device | |
| FR2811787A1 (fr) | Methode pour valider un paiement electronique avec une carte de credit | |
| WO2017023757A1 (fr) | Procédés et systèmes permettant de fournir une entité ayant la capacité de commander des comportements et des capacités des comptes de l'entité et/ou des transactions de comptes par utilisateur | |
| US20170318015A1 (en) | Interlinking cross platform authorization and processing | |
| EP2074569A2 (fr) | Procédé et systèmes de paiement | |
| EP1940116A2 (fr) | Procédé et système pour effectuer des transactions à partir d'appareils électroniques portables connectables à un réseau de communication, et appareil électronique portable associé | |
| US20210117941A1 (en) | Application program interface for conversion of stored value cards | |
| FR3095066A1 (fr) | 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 | |
| Możdżyński | The conceptions of new payment methods based on revised payment services directive (PSD2) | |
| US20170221067A1 (en) | Secure electronic transaction | |
| CN111833187A (zh) | 一种基于流动性的一键式金融产品交易方法、装置和系统 | |
| KR101603158B1 (ko) | 쇼셜 네트워크 서비스 기반 기념일 선물 추천 및 분할 결제 방법 | |
| US20150363776A1 (en) | System and Method for Managing a Payment Transaction | |
| US20130024216A1 (en) | Apparatus and method for expedited event access | |
| JP2019149027A (ja) | 顔認証技術による自動割り勘決済システム | |
| Hutabarat et al. | Consumer Protection Against Buying and Selling Transactions of Mobile Legends Diamonds on Instagram Platform | |
| FR2823882A1 (fr) | Procede et systeme de validation de paiement | |
| CN110073388A (zh) | 安全支付的方法和系统 | |
| Da Silva et al. | Mozambican e-commerce online consumer profile in Pemba | |
| WO2023247737A1 (fr) | Methode et systeme d'assistance d'echanges controles de donnees | |
| US20110289007A1 (en) | Negotiable sensitive user data management method and system | |
| Sutherland | Merger Control in the Age of Digital Markets |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20201016 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| ST | Notification of lapse |
Effective date: 20231205 |