EP3113099A1 - Payment container, creation method, processing method, devices and programs therefor - Google Patents

Abstract

The invention relates to a method for creating a payment data structure, called the payment container. The invention also relates to the use of such a payment container by a processing server. the creation process is implemented by a mobile communication terminal, said payment container comprising at least one datum representative of a user's bank identifier, said method comprising: selecting (C20), by a user and via a human-machine interface, at least one attribute of said container; obtaining (C30), by the communication terminal, at least one datum representative of the user's bank card; - the validation (C40) by the user of the creation of the payment container; the transmission (C50) by said communication terminal of said payment container to a payment container processing server.

Description

1. Domain

The present technique relates to the problem of payment. More particularly, the invention relates to the problem of payment by bank card. In Europe, the bank card is the most used means of payment. It is used both physically to make payments to merchants; It is also used to make payments online. However, she is also subject to fraud.

2. Prior Art

A bank card makes it possible to make purchases according to two different types of processes: "card present" purchases are made when the user physically presents his bank card to a merchant, who has a physical payment terminal. In this configuration, depending on the countries, legislation and payment terminals available, the user (the buyer) can use either a smart card (also called a smartcard) or a magnetic stripe card (c). for example in the United States), or a contactless card. There are also multimodal maps that include the three previously mentioned technologies. "Card Not Present" (CNP) purchases are also possible using a credit card. These are mainly online purchases and also by phone that are made using a computer, tablet, smartphone or phone. To make this type of purchase, the user makes an entry, or communicates visual data of his card: card number, date of validity, name of the holder, visual cryptogram. This data is transmitted, via a communication network, to one or more servers, so that the payment can be made.

The difference between these two types of payment is major. As much as it is easy to use a bank card in "present card" mode, it is tedious to have to enter his credit card data into forms of web pages. Thus, many people store their credit card data within a file to make payment transactions simpler. Solutions make it possible to manage this data in a centralized manner (for example DashLane ™). These software solutions, installed on the communication device (computer or tablet) of the user, can automatically enter, in the fields provided for this purpose, the data that was previously entered in the software. However, on the one hand, it makes it necessary to enter this data into third-party software, which must first be installed on the user's communication device; on the other hand, this solution requires to trust the publisher of this software for the conservation of these data. Online solutions also exist: they do not have to install software on user communication device, but they still need to trust a publisher (eg Google ™) for the retention of this data . This confidence has been greatly altered in recent years. Moreover, this solution for preserving credit card data within the communication device may be problematic in the event of theft or loss of the communication device.

Another solution called "Card-on-File", allows storage of credit card data directly to the merchant. The merchant keeps, within its software infrastructure, the credit card data. This simplifies the payment process since once the user has logged in, it is just necessary to accept the payment or order for the payment to be effective. This solution, however, is not advantageous because it requires to have confidence in all online merchants likely to have the credit card data of the user (in this case, we must above all have confidence in the infrastructure of these traders, and trust that they are protected against theft and usurpation). This solution is also not definitive because when the card expires (for example when it comes to its expiry date), it is necessary to update all banking data on the websites or organization from which a "Card-on-File" solution has been implemented (eg credit, insurance, etc.). Finally, the main problem of the "Card-on-File" technique is ultimately to give his credit card data without insurance of their destination or end use.

In general, credit card fraud is mainly carried out for online payments. However, the loss or theft of a bank card is an event that can have significant repercussions for those involved: withdrawal of cash (especially if the theft of the card was accompanied by the theft of the PIN accompanying the one here), online payments.

To palliate 3. Summary

The present technique does not have these disadvantages of the prior art. More particularly, the present technique relates to a transactional data processing method in a secure manner that provides a high level of usability for consumers. With this technique, payment can be made safely with a low level of fraud; In addition, the proposed solution is simple for the user and does not slow down the payment.

More particularly, in a first aspect, there is disclosed a method for creating a payment data structure, called a payment container, a creation method implemented by a mobile communication terminal, said payment container comprising at least one data item. representative of a bank identifier of a user.

• la sélection, par un utilisateur et par l'intermédiaire d'une interface homme-machine, d'au moins un attribut dudit conteneur ;
• l'obtention, par le terminal de communication, d'au moins une donnée représentative de la carte bancaire de l'utilisateur ;
• la validation, par l'utilisateur de la création du conteneur de paiement ;
• la transmission, par ledit terminal de communication, dudit conteneur de paiement à un serveur de traitement de conteneur de paiement.

According to the present technique, the method comprises:

• selecting, by a user and via a human-machine interface, at least one attribute of said container;
• obtaining, by the communication terminal, at least one datum representative of the user's bank card;
• validation by the user of the creation of the payment container;
• transmitting, by said communication terminal, said payment container to a payment container processing server.

Thus, the user can define in a simple and secure way, a sum of money that he can subsequently use to make a payment, without the user needing to use his credit card.

• une étape de transmission, à ladite carte bancaire, par l'intermédiaire d'une interface de transmission de données sans contact, d'une requête d'obtention de données, sous la forme d'un signal ;
• une étape de réception d'une réponse à ladite requête, sou la forme d'un signal modulé ;
• une étape de décodage dudit signal modulé délivrant ladite au moins une donnée.

According to a particular embodiment, said step of obtaining by the payment terminal, minus a datum representative of the user's bank card comprises:

• a step of transmitting, to said bank card, via a contactless data transmission interface, a request for obtaining data, in the form of a signal;
• a step of receiving a response to said request, in the form of a modulated signal;
• a step of decoding said modulated signal delivering said at least one datum.

Thus, the user does not even need to enter the data of his bank card; It is enough for him to affix this one on his communication terminal.

• une étape d'activation d'un dispositif de prise de vue du terminal de communication ;
• une étape d'obtention, à l'aide du dispositif de prise de vue, d'une image de la carte bancaire ;
• une étape de mise en oeuvre d'un module de reconnaissance de caractères, à partir de l'image de la carte bancaire, délivrant ladite au moins une donnée.

According to a particular embodiment, said step of obtaining by the payment terminal, minus a datum representative of the user's bank card comprises:

• a step of activating a device for shooting the communication terminal;
• a step of obtaining, with the aid of the shooting device, an image of the bank card;
• a step of implementing a character recognition module, from the image of the bank card, delivering said at least one data.

Thus, the user does not even need to enter the data of his bank card; It is enough for him to take this one in photo using his communication terminal.

According to a particular characteristic, the method further comprises a step of determining, by said communication terminal, a value representative of a transmission attribute of said payment container.

According to one particular characteristic, the method furthermore comprises, when the value representative of the transmission attribute of said payment container is positive, a step of determining, by said communication terminal, a value representative of a debit attribute. of said payment container.

• l'activation, sur le terminal de communication de l'utilisateur d'un module de gestion de conteneur de paiement ;
• la sélection, au sein de ce module, d'un mode de fonctionnement dit de création de conteneur.

According to a particular characteristic, the creation method characterized in that it comprises, prior to the selection of a container parameter,

• enabling the user's communication terminal to activate a payment container management module;
• the selection within this module of a so-called container creation mode of operation.

According to a particular characteristic, the activation of the management module is accompanied by the authentication of said user to which said communication terminal and said payment card belong.

• date de validité du conteneur de paiement ;
• durée de validité du conteneur de paiement ;
• montant du conteneur de paiement ;
• catégorie de bénéficiaire du conteneur de paiement ;
• bénéficiaire du conteneur de paiement.

According to a particular embodiment, the selection, by a user and via a human-machine interface, of at least one attribute of said container comprises the selection of at least one attribute value for at least one following parameters:

• date of validity of the payment container;
• period of validity of the payment container;
• amount of the payment container;
• category of beneficiary of the payment container;
• beneficiary of the payment container.

In another embodiment, the technique also relates to a device for creating a payment data structure, called a payment container, said payment container comprising at least one datum representative of a bank identifier of a user.

• la sélection, par un utilisateur et par l'intermédiaire d'une interface homme-machine, d'au moins un attribut dudit conteneur ;
• l'obtention, par le terminal de communication, d'au moins une donnée représentative de la carte bancaire de l'utilisateur ;
• la validation, par l'utilisateur de la création du conteneur de paiement ;
• la transmission, par ledit terminal de communication, dudit conteneur de paiement à un serveur de traitement de conteneur de paiement.
  Un tel module peut se présenter sous une forma matérielle ou logicielle. Dans une forme matérielle, un tel module prend par exemple la forme d'un processeur sécurisé spécialement configuré pour mettre en oeuvre la technique proposée.

Such a device comprising at least one module configured to allow:

• selecting, by a user and via a human-machine interface, at least one attribute of said container;
• obtaining, by the communication terminal, at least one datum representative of the user's bank card;
• validation by the user of the creation of the payment container;
• transmitting, by said communication terminal, said payment container to a payment container processing server.
  Such a module can be in a hardware or software forma. In a hardware form, such a module takes for example the form of a secure processor specially configured to implement the proposed technique.

• réception des données en provenance du terminal de paiement, comprenant l'identifiant du conteneur de paiement ;
• obtention d'un identifiant de commerçant, éventuellement accompagné d'un code de catégorie de marchand lorsque celui-ci n'est pas fourni par le commerçant ;
• en fonction de l'identifiant du conteneur de paiement, détermination d'un identifiant d'un établissement bancaire auquel le conteneur de paiement est attaché ;
• en fonction de l'identifiant bancaire du conteneur de paiement, obtention d'une autorisation de paiement ; et
• lorsque l'autorisation de paiement délivrée, une étape de transmission, au terminal du commerçant, d'une donnée représentative de l'acceptation de la transaction.

According to a second aspect, there is also disclosed a method of processing, by a processing server, a payment data structure, said payment container, said payment container being used with a payment server. merchant by a user having a communication terminal linked to said payment container, characterized in that it comprises the following steps:

• receiving the data from the payment terminal, including the identifier of the payment container;
• obtaining a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant;
• according to the identifier of the payment container, determining an identifier of a banking establishment to which the payment container is attached;
• according to the bank identifier of the payment container, obtaining a payment authorization; and
• when the payment authorization issued, a step of transmitting, to the merchant terminal, data representative of the acceptance of the transaction.

Thus, a payment can be implemented, using a payment container, without requiring the intervention of a credit card used to create this payment container.

• lorsque l'établissement bancaire du conteneur de paiement est le même que l'établissement bancaire du serveur de traitement :
• obtention des attributs du conteneur ;
• vérification du solde restant au sein le conteneur de paiement ;
• lorsque le solde restant au sein du conteneur de paiement est supérieur au montant de la transaction :
  • vérification qu'aucun des attributs du conteneur de paiement n'est en contradiction avec les données de la transaction ;
  • lorsqu'aucun des attributs de paiement n'est violé, délivrance de l'autorisation de paiement ;
  • soustraction un montant de la transaction du solde restant au sein du conteneur de paiement ;
  • lorsque le solde restant au sein du conteneur de paiement est inférieur au montant de la transaction, transmission d'une absence d'autorisation ;

According to a particular embodiment, said step of obtaining a payment authorization comprises the following steps:

• when the banking establishment of the payment container is the same as the banking establishment of the processing server:
• obtaining the attributes of the container;
• checking the remaining balance within the payment container;
• when the balance remaining in the payment container is greater than the amount of the transaction:
  • verification that none of the attributes of the payment container are in contradiction with the data of the transaction;
  • when none of the payment attributes are violated, issue of the payment authorization;
  • subtracting a transaction amount from the remaining balance within the payment container;
  • when the remaining balance within the payment container is less than the transaction amount, transmission of a no authorization;

• lorsque l'établissement bancaire du conteneur de paiement est différent de l'établissement bancaire du serveur de traitement :
  • identification du serveur de traitement auquel les données de transaction doivent être transmises ;
  • transmission des données de de transaction à ce serveur de traitement ;
  • réception de l'autorisation ou du refus de paiement.

According to a particular embodiment, said step of obtaining a payment authorization comprises the following steps:

• when the payment container bank is different from the processing server bank:
  • identification of the processing server to which the transaction data is to be transmitted;
  • transmitting the transaction data to this processing server;
  • receipt of authorization or refusal of payment.

• réception des données en provenance du terminal de paiement, comprenant l'identifiant du conteneur de paiement ;
• obtention d'un identifiant de commerçant, éventuellement accompagné d'un code de catégorie de marchand lorsque celui-ci n'est pas fourni par le commerçant ;
• en fonction de l'identifiant du conteneur de paiement, détermination d'un identifiant d'un établissement bancaire auquel le conteneur de paiement est attaché ;
• en fonction de l'identifiant bancaire du conteneur de paiement, obtention d'une autorisation de paiement ; et
• lorsque l'autorisation de paiement délivrée, une étape de transmission, au terminal du commerçant, d'une donnée représentative de l'acceptation de la transaction ;

The technique also relates to a processing server of a payment data structure, called a payment container, said payment container being used by a merchant by a user having a payment terminal. communication related to said payment container. Such a server comprises means of:

• receiving the data from the payment terminal, including the identifier of the payment container;
• obtaining a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant;
• according to the identifier of the payment container, determining an identifier of a banking establishment to which the payment container is attached;
• according to the bank identifier of the payment container, obtaining a payment authorization; and
• when the payment authorization issued, a step of transmitting, to the merchant terminal, data representative of the acceptance of the transaction;

Other aspects of the present technique are also disclosed herein.

According to a preferred implementation, the various steps of the methods according to the proposed technique are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the technique. proposed and being designed to control the execution of the different process steps.

Accordingly, the proposed technique is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.

This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.

The proposed technique is also aimed at a data carrier readable by a data processor, and including instructions of a program as mentioned above.

The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a diskette (floppy disc) or a disk hard.

On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the proposed technique can be downloaded in particular on an Internet type network.

Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

According to one embodiment, the proposed technique is implemented by means of software and / or hardware components. In this context, the term "module" may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.

A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, bus communication cards, input / output electronic cards, user interfaces, etc.).

In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc.

Each component of the previously described system naturally implements its own software modules.

The various embodiments mentioned above are combinable with each other for the implementation of the proposed technique.

4. Figures

• la figure 1 présente un conteneur de paiement selon la présente technique ;
• la figure 2 décrit les étapes mises en oeuvre pour créer un conteneur de paiement.
• la figure 3 les étapes mises en oeuvre, côté serveur, pour utiliser un conteneur de paiement.
• la figure 4 décrit brièvement l'architecture physique d'un dispositif de création et d'utilisation de conteneur de paiement.
• la figure 5 décrit brièvement l'architecture physique du serveur de traitement.

Other characteristics and advantages of the proposed technique will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and nonlimiting example, and the appended drawings, among which:

• the figure 1 presents a payment container according to the present technique;
• the figure 2 describes the steps implemented to create a payment container.
• the figure 3 the steps implemented, server side, to use a payment container.
• the figure 4 briefly describes the physical architecture of a device for creating and using a payment container.
• the figure 5 briefly describes the physical architecture of the processing server.

5. Description

As stated above, the purpose of this is to simplify payment transactions in particular situations. The technique aims to answer a problem of payment or transfer of money. The proposed technique is particularly applicable to the use (payment, transfer) of a certain amount of money without having to use his bank card. The technique is based in particular on the implementation of a payment container, which includes a certain amount of information to make a payment in a simple and fast manner. The described technique also relates to the payment processing performed with the payment container. These processes are mainly performed with a transaction processing server, also called a processing server. Such a processing server may, depending on the embodiments and operating conditions, be a bank server (ie a server of a banking institution). It can also be an intermediary server (for example a hub that organizes and processes all the transactions of a group of merchants and / or merchants, or it can be an intermediary server. , which is the link between banking servers belonging to different banking institutions.

5.1. Payment Container

The payment container is a data structure, which can optionally be encrypted (and thus secure) and contains a certain amount of information relating to a sum of money. The payment container can be defined as an envelope containing a certain amount of money associated with a bank card of a specific bank account (in this case, the bank account of the user who creates the payment container). The figure 1 illustrates a payment container (PC).

Depending on the implementations and operational implementations, this sum of money (MNY) comes with a number of attributes: attributes are "public" (AttrPub) and others are private (AttrPriv) . Among the possible public attributes, there is notably at least one temporal data (TPS), which can be a duration of use or a expiry date, a maximum amount (MAX), a beneficiary (BEN) and / or a category of beneficiary (CBEN), the location of use (LOCU). Other data, for security and regulatory purposes, are private (AttrPriv): such as the date (DAT) to which the container is created, the location (approximate or not) (LOCC) of this creation, can be included. Private attributes help to ensure non-repudiation of the payment container. They also help to guard against fraud. A certain number of private attributes are inserted by the processing server itself, during the validation by the terminal. These private attributes are not editable by users.

• la date de validité détermine une date limite d'utilisation du conteneur de paiement ; au-delà de cette date, le conteneur n'est plus utilisable ; la date limite est sensiblement égale, en terme de fonction à la durée limite : une fois passée la durée limite, le conteneur n'est plus utilisable ;
• le montant maximum ne détermine pas le montant du conteneur. Le montant maximum détermine la somme maximum d'argent pour laquelle le conteneur peut être utilisé à chaque fois ; par exemple, un conteneur peut contenir une somme de 100 € et le montant maximum peut être fixé à 20 €. Dès lors, une transaction utilisant ce conteneur sera limitée à un montant maximum de 20 € ;
• la catégorie de bénéficiaire détermine le type de commerçant avec lequel le conteneur peut être utilisé. Par exemple, l'utilisateur peut choisir de limiter l'utilisation du conteneur à des commerces de type « alimentaires » en excluant les commerces de vente de tabac ; cet aspect est explicité en détail ci-après ;
• le bénéficiaire détermine un commerçant en particulier avec lequel le conteneur peut être utilisé ; cet aspect est explicité en détail ci-après ;
• la localisation d'utilisation définit une sphère géographique au sein de laquelle le conteneur peut être utilisé (ville, région, pays, etc.) ;

Each attribute of the payment container has a specific function:

• the validity date determines a deadline for using the payment container; beyond this date, the container is no longer usable; the deadline is substantially equal, in terms of function to the time limit: once past the time limit, the container is no longer usable;
• the maximum amount does not determine the amount of the container. The maximum amount determines the maximum sum of money for which the container can be used each time; for example, a container may contain a sum of € 100 and the maximum amount may be € 20. Therefore, a transaction using this container will be limited to a maximum amount of € 20;
• the beneficiary category determines the type of merchant with whom the container can be used. For example, the user may choose to limit the use of the container to "food" type businesses, excluding tobacco sales businesses; this aspect is explained in detail below;
• the recipient determines a particular trader with whom the container can be used; this aspect is explained in detail below;
• the usage location defines a geographical sphere within which the container can be used (city, region, country, etc.);

With regard to the beneficiary, or category of beneficiary, it is offered the possibility to the user, to determine the type of purchase allowed with the container. The user thus has the possibility of restricting the use of the container. Thus, even if an ill-intentioned individual would be able to obtain the user's communication terminal and would succeed in launching a payment transaction with a container, the verification of the beneficiary or the beneficiary category of the container makes it possible to ensure that the ill-intentioned individual does not may not use the container as he wishes. This blocking of the payment container is made possible by comparing the MCC (merchant category code) defined for this merchant with a list of MCC authorized by the creator of the payment container.

As for the beneficiary, the principle is the same as before: instead of selecting one or more MCCs, the user selects one or more merchant IDs with which he wishes the container is usable.

Once the payment container is created (see below), it is transmitted to the processing server for registration. It is considered that a processing server has sufficient security measures for the payment container to be stored in the server in decrypted form. However, it is also possible that the payment container is not transmitted to a processing server but directly to another communication terminal of another user. In this case, it is transmitted in an encrypted form.

A payment container may also include an overflow attribute, the use of which may be limited (for example not for transmission and not for immediate debit): the override attribute is used to define an override percentage allowed, the amount of the container, for the maximum amount allowed. Such an attribute makes it possible to set a maximum amount range without being too strict on the amount itself.

It should be noted that the payment container according to the present technique is not a wallet, such as for example the Google ™ or Paypal ™ portfolios. Indeed, these portfolios do not include the attributes that are defined for a payment container. In particular, they do not have an amount allocated, nor a duration of use or a category of beneficiary. These portfolios simply link an account number or a credit card number, a user within a banking institution, and a mobile communication terminal.

It is also noted that the payment container is not a pre-authorization of debit. Indeed, the processing server, which keeps the payment container, does not immediately debit the user's account when creating or receiving this container. It also does not make a reservation of money: this means that there is no subtraction on the authorization amount of the customer's credit card (as is the case, for example, for establishment of a deposit by credit card). If the container is not in use (for example because the container usage time is exceeded before any use) then no debit is made to the account of the customer and no subtraction is made on the overall amount of authorization of the card. In a pre-authorization, on the contrary, although no amount of money is debited at the time of the pre-authorization, a subtraction is made from the payment limit of the bank card. Such subtraction is not without many problems for cardholders because it can cause the blocking of the card even if no payment is actually made. In addition, a payment authorization can only be made (by a real payment) by the merchant who has made this pre-authorization, and not by any merchant, unlike the payment container.

In a specific embodiment, the payment container can be debited immediately from the user's bank account. Such a situation may occur when the payment container is transmitted to a third party for use by a person who is not the creator of the payment container. When the user performs the creation of a payment container for a third party, the creator can value a specific attribute, called transmission attribute, indicating that the container is not intended for him. The third party to whom the attribute is intended is not necessarily known at the time of creation of the payment container. When the transmission attribute is set to "true", this opens the possibility of valuing a sub attribute (a dependent attribute) called the debit attribute. The debit attribute is used to indicate either that the payment container is to be debited immediately (attribute valued at "true"), or that the payment container should not be subject to a debit. immediate debit (attribute valued at "false").

When an immediate debit is required, the amount of the payment container is debited from the user's bank account, by the implementation of an "EMV" type credit card transaction. For the user creator of the payment container, it is a conventional credit card transaction.

When no immediate debit is required, the account of the user is debited according to several parameters that are explained later.

5.2. Creating a payment container 5.2.1. Creating a container on a communication terminal

It will be recalled that one of the problems that the payment container tries to answer is to enable users of smart communication terminals (of the smartphone type) to have at all times a simple and secure means of payment which replaces the bank card. Many users are worried about losing or stealing their card. The payment container offers such a possibility. It is also necessary that the payment container meets a number of other requirements, particularly in terms of ease of creation. This method is described in relation to the figure 2

The inventors thus had the idea of implementing a method based on the use of an intelligent communication terminal of the smartphone (TC) type, this terminal being equipped on the one hand with a contactless reading interface ( NFC) or equipped with a camera (CAM) and secondly a payment container creation module (MCPC). According to the embodiments, such a module can be a dedicated module, a wallet module or a banking module (the user's banking module, available on its communication terminal). An advantage of using a bank module is that such a module is generally well secured. Therefore, insofar as the payment container is intimately linked to the user's bank card and / or bank account, it seems simple (and legitimate) that the cardholder's bank module is, in a particular operation, used to create the payment containers.

• l'activation, (C10) sur le terminal de communication de l'utilisateur du module ;
• la sélection, (C10-1) au sein de ce module, d'un mode de fonctionnement dit de création de conteneur ;
• la sélection et/ou saisie (C20), par l'utilisateur, des attributs du conteneur (date ou durée de validité, montant du conteneur, bénéficiaire et/ou catégorie de bénéficiaire) ;
• la valorisation (éventuelle) de l'attribut de transmission ; par défaut, l'attribut de transmission prend la valeur « faux », et dans le cas où cet attribut est positionné à « vrai », la valorisation d'un identifiant d'un destinataire ;
• la valorisation (éventuelle) de l'attribut de débit; par défaut, l'attribut de débit prend la valeur « faux » ;
• l'obtention (C30) d'un donnée de carte bancaire (par exemple l'apposition, sur le terminal de communication, de la carte bancaire de l'utilisateur ; alternativement à l'apposition de la carte (cas du NFC), l'appareil photo du terminal de communication peut être utilisé pour prendre un cliché de la carte bancaire de l'utilisateur et effectuer une reconnaissance de caractères) ;
• la validation (C40), par l'utilisateur de la création du conteneur de paiement; cela passe par exemple par l'appui sur un bouton de validation.
• la transmission (C50), du conteneur de paiement à un serveur de traitement (SRVT).

Creating a payment container includes:

• activation, (C10) on the communication terminal of the user of the module;
• selecting (C10-1) within this module a so-called container creation mode of operation;
• the selection and / or input (C20) by the user of the attributes of the container (date or duration of validity, amount of container, beneficiary and / or category of beneficiary);
• the valuation (if any) of the transmission attribute; by default, the transmission attribute takes the value "false", and in the case where this attribute is set to "true", the valuation of an identifier of a recipient;
• the valuation (if any) of the debit attribute; by default, the debit attribute is set to "false";
• obtaining (C30) a credit card data item (for example, affixing the user's bank card to the communication terminal, alternatively to affixing the card (in the case of the NFC), communication terminal camera can be used to take a snapshot of the user's bank card and perform character recognition);
• the validation (C40) by the user of the creation of the payment container; this happens for example by pressing a validation button.
• the transmission (C50) of the payment container to a processing server (SRVT).

5.2.2. Processing, by the processing server, of the container created by the communication terminal

• la réception du conteneur de paiement, comprenant une étape de déchiffrage, avec une ou plusieurs clés en possession du serveur de traitement ;
• l'attribution d'un identifiant servant à identifier le conteneur de manière unique ;
• la retransmission de cet identifiant au terminal de communication de l'utilisateur créateur ;
• le stockage, dans une structure de données adaptée, de ce conteneur.
• Le traitement du conteneur, comprenant notamment, en cas de positionnement de l'attribut de débit à « vrai », une étape de débit du montant du conteneur.

Once created on the user's communication terminal, the payment container is transmitted, in a secure form, to the processing server. The processing server implements a processing method which comprises:

• receiving the payment container, comprising a decryption step, with one or more keys in the possession of the processing server;
• assigning an identifier for uniquely identifying the container;
• retransmitting this identifier to the communication terminal of the creator user;
• storing, in a suitable data structure, this container.
• The treatment of the container, including in particular, in case of positioning of the flow attribute to "true", a step of debiting the amount of the container.

The payment container is then ready to be used, either by the communication terminal which has created it or by another channel.

5.2.3. Transmission, by the processing server, to a recipient, of the container created by the communication terminal.

The processing of the payment container may also comprise a step of transmission of the payment container, by the processing server (for example the banking server), to a receiving entity (for example another processing server or a banking server). The step of transmitting the payment container occurs when the payment container is intended to be used by another person. The processing server is then in charge of searching for this other person. This is done using the "recipient" attribute, which includes an identifier of the user to whom the payment container is intended. This identifier can take several forms, two of which are specified below. The identifier is used by the processing server either directly to carry out a transmission of the payment container to the recipient (the simplest case corresponding to a known recipient of the processing server) or indirectly to obtain additional data making it possible to carry out a transmission. the payment container.

In a first alternative, the identifier of the recipient is a bank identifier, known to the communication terminal that performs the creation of the payment container. This bank identifier may for example be the bank identifier corresponding to a recipient close to the user (a parent, a child, etc.). The bank identifier can be in the form of a simple account number (in which case the creator of the container and the recipient share the same bank). The bank identifier can also be a BIC or an IBAN (when the creator and the recipient do not share the same bank).

Therefore, in this first alternative, the processing server performs either moving the container (ie the assignment of the container to another account) when the creator and recipient are managed by the same bank, or the transmission of the container. payment to a server of the recipient's bank.

In a second alternative, the identifier is a piece of data representative of a contact of the user's communication terminal: the identifier is obtained after the selection, by the user, of a recipient in the contact list. From then on, the identifier can be a mobile phone number, an email address, an instant messaging identifier, etc.

• création d'un message d'information ; le message contient une adresse à laquelle le destinataire doit se connecter (par exemple une URL) ; l'adresse comprend un identifiant de transmission qui est par exemple le résultat d'une fonction de hachage dont les paramètres sont l'identifiant du destinataire et un identifiant du conteneur de paiement ;
• transmission du message d'information vers le destinataire en utilisant l'identifiant du conteneur de paiement (par exemple le message est un courrier électronique lorsque l'identifiant est une adresse de courrier électronique, le massage est un SMS ou un MMS lorsque l'identifiant est un numéro de téléphone mobile, etc.) ;

Therefore, in this second alternative, the processing server performs at least the following actions:

• creating an information message; the message contains an address to which the recipient must connect (for example a URL); the address comprises a transmission identifier which is for example the result of a hash function whose parameters are the identifier of the recipient and an identifier of the payment container;
• transmission of the information message to the recipient using the identifier of the payment container (for example the message is an email when the identifier is an email address, the massage is an SMS or an MMS when the identifier is a mobile phone number, etc.);

On receipt of this message, the recipient connects to the address it contains and performs the steps necessary for the transmission of the payment container. To ensure the security of the exchange, the steps involve security processes including dual identification processes and encryption processes. In a complementary manner, identification deletion processes can also be implemented.

5.2.4. Transmission by the communication terminal of the container created by the communication terminal to a recipient

The processing of the payment container may also include a step of transmitting the payment container, by the communication terminal itself, to the communication terminal of the recipient user.

• le terminal de communication de l'utilisateur créateur est approché du terminal de communication du destinataire ; éventuellement, cette étape est précédée du lancement, du processus par un bouton de validation ;
• le terminal de communication de l'utilisateur créateur émet une requête, par exemple une requête NFC ou Bluetooth, à destination du terminal de l'utilisateur destinataire ;
• le terminal de l'utilisateur destinataire répond à cette requête en transmettant un identifiant « destinataire » (c'est par exemple un identifiant du module bancaire installé sur le terminal de communication du destinataire, que l'utilisateur destinataire peut par exemple prendre le soin de lancer, ou bien qui se lance automatiquement) ;
• l'identifiant « destinataire » est inséré dans le conteneur de paiement, dans l'attribut « destinataire » ;
• le conteneur de paiement est chiffré puis transmis, par NFC ou Bluetooth, au terminal du destinataire.

To do this, when the user has validated a payment container including a transmission attribute set to "true", the selection of the recipient offers the possibility of selecting a so-called "local" transmission. The local transmission is to transfer locally, to a second communication terminal located nearby, the payment container. This second communication terminal is that of the recipient. The process is as follows:

• the communication terminal of the creator user is approached from the recipient's communication terminal; possibly, this step is preceded by the launch of the process by a validation button;
• the communication terminal of the creator user sends a request, for example an NFC or Bluetooth request, to the terminal of the destination user;
• the terminal of the recipient user responds to this request by transmitting a "recipient" identifier (it is for example an identifier of the bank module installed on the recipient's communication terminal, that the recipient user can for example take care of launch, or that will launch automatically);
• the "recipient" identifier is inserted in the payment container, in the "recipient"attribute;
• the payment container is encrypted and transmitted by NFC or Bluetooth to the recipient's terminal.

This transmission is followed or preceded by a transmission to the processing server of the payment container so that the processing server can also process it. Incidentally, the payment container also includes data representative of the processing server, so that the communication terminal of the recipient can be able to locate the container. Indeed, this transmission to the recipient's terminal is completed by an exchange of data at the processing server or servers, as described above.

5.3. Using a payment container.

Depending on the data it contains, the embodiments and the operational conditions, the payment container can then be used to make payments to merchants. It can also be used to make payments online.

• l'activation, sur le terminal de communication de l'utilisateur, d'un module ; il peut s'agir d'un module bancaire (i.e. le module de la banque auprès de laquelle le conteneur de paiement est enregistrée), ou d'un module de type portefeuille (de l'anglais « wallet ») ;
• la sélection, au sein de ce module, d'un mode de fonctionnement dit de paiement sans contact ;
• éventuellement, la sélection d'un conteneur de paiement à utiliser (lorsque plusieurs conteneurs peuvent être utilisés) ;
• la présentation du terminal de communication devant le lecteur sans contact du terminal de paiement du commerçant ; lors de cette présentation, le terminal de paiement détecte l'utilisation du conteneur de paiement et met en oeuvre, en lien avec le serveur de traitement auquel il est connecté, un processus de paiement qui est explicité ci-après (processus de traitement mis en oeuvre par le serveur).

The use of a payment container at a merchant includes:

• activating a module on the user's communication terminal; it can be a banking module (ie the module of the bank from which the payment container is registered), or a wallet type module (of the English "wallet");
• the selection, within this module, of a mode of operation called contactless payment;
• optionally, the selection of a payment container to be used (when multiple containers can be used);
• presentation of the communication terminal in front of the contactless reader of the merchant's payment terminal; during this presentation, the payment terminal detects the use of the payment container and implements, in connection with the processing server to which it is connected, a payment process which is explained below (processing process implemented). implemented by the server).

Thus, the use of a payment container at a merchant is a simple operation, which does not require any particular effort on the part of the user. Indeed, instead of having to introduce his credit card, it is sufficient to affix his communication terminal on the payment terminal. Instead of entering a PIN, he just needs to enter a password in the payment container management module (for example the bank module).

• l'activation, sur le terminal de communication de l'utilisateur, d'un module ; il peut s'agir d'un module bancaire (i.e. le module de la banque auprès de laquelle le conteneur de paiement est enregistrée), ou d'un module de type portefeuille (de l'anglais « wallet ») ;
• la sélection, au sein de ce module, d'un mode de fonctionnement dit de paiement en ligne ;
• éventuellement, la sélection d'un conteneur de paiement à utiliser (lorsque plusieurs conteneurs peuvent être utilisés) ;
• la génération, par le module, d'une donnée de paiement ;
• la saisie, au sein d'une zone de saisie donnée du site web (zone de saisie spécifique, lié au type de paiement par conteneur de paiement), de la donnée de paiement fournie par le module; postérieurement à cette saisie, le marchand met en oeuvre, en lien avec le serveur de traitement auquel il est connecté, un processus de paiement qui est explicité ci-après.

Using a payment container for an online payment includes:

• activating a module on the user's communication terminal; it can be a banking module (ie the module of the bank from which the payment container is registered), or a wallet type module (of the English "wallet");
• the selection, within this module, of a mode of operation called online payment;
• optionally, the selection of a payment container to be used (when multiple containers can be used);
• generating, by the module, a payment data item;
• the entry, within a given input area of the website (specific input area, related to the type of payment by payment container), of the payment data provided by the module; after this seizure, the merchant implements, in connection with the processing server to which it is connected, a payment process which is explained below.

Thus, the use of an online payment container is a simple operation, which does not require more effort on the part of the user. Indeed, instead of entering credit card data, the user enters a data representative of a payment container.

The benefits of using a payment container are numerous. Indeed, the user does not need to use his bank card; users are very cautious, so for example can leave their bank card in a safe place and be sure that it can not be lost or stolen. A typical use case of a payment container is that of a user who does not wish to bother with his credit card, for example during an afternoon at the beach, lest we he steals it and creates a container on his communication terminal. He created this container for a day, with an amount of 20 € for example. If the user then wants to make a purchase on the beach, for example a drink, he can then use his communication terminal to pay for this purchase. Another advantage is that in case of loss of the communication terminal, the maximum amount that can be used by a malicious person is limited to the amount of the container. Furthermore, it should be borne in mind that the smartphone-type communication terminals are geolocatable. Indeed, more and more manufacturers and service providers integrate directly into the smartphone technologies to find it if it were lost or stolen. This means that even in case of loss, the user is likely to find his phone.

Another case of use of the payment container is that of a transfer of money between two users. When a user wishes to transmit a sum of money to another, he creates, on his communication terminal, a payment container of the sum he wishes to transmit. It values the transmission attribute to "true" and the flow attribute to "true" or "false" according to the will of the user. It validates the creation of the payment container.

This is transmitted to the processing server which detects that the container must be transferred and must be immediately debited. The processing server then identifies the recipient (which can in this case be valued in the "recipient" attribute, for example by using a telephone number or another identifier, as was previously presented). Using this identifier, the processing server informs the user recipient receives a transfer of money via a payment container, then implements the method of transmission, by the processing server, to a recipient, the container created by the communication terminal .

5.4. Processing a payment container from a processing server.

First of all, the case of the processing of a payment container by a processing server when a payment transaction is carried out using a payment container at a merchant. It is assumed, as a prerequisite, that the payment terminal is able to accept a payment via a container. As a general rule, this involves a software upgrade of the payment terminal (the vast majority of terminals have contactless payment modules, so a change of payment terminal is not necessary).

At the time of payment, the user indicates to the merchant that he wishes to settle with a payment container. The merchant activates the terminal so that he can receive this type of payment then the user implements the method described above. When he presents the communication terminal in front of the payment terminal, the communication terminal transmits, to the payment terminal, the identifier of the payment container. The data exchanges between the payment terminal and the communication terminal are for example made using the ISO / IEC 14443-4: 2008 exchange standard. The identifier of the payment container is for example transmitted using this standard. Once this identifier has been obtained, the payment terminal implements a payment transaction in relation to the processing server to which it is connected. The data transmitted to the processing server are substantially identical to the data transmitted for payment by credit card excluding the PAN of the credit card, which is replaced by the identifier of the payment container. Furthermore, the merchant terminal may also include, in the transmitted data, a data representative of its merchant category code ( MCC ). If this data is not included in the data transmitted by the payment terminal, it is searched by the processing server.

• réception (T01) des données en provenance du terminal de paiement, comprenant l'identifiant du conteneur de paiement ;
• obtention (T02) d'un identifiant de commerçant, éventuellement accompagné d'un code de catégorie de marchand lorsque celui-ci n'est pas fourni par le commerçant ;
• en fonction de l'identifiant du conteneur de paiement, détermination (T03) d'un identifiant d'un établissement bancaire auquel le conteneur de paiement est attaché ;
• en fonction de l'identifiant bancaire du conteneur de paiement, obtention (T04) d'une autorisation de paiement ; et
• lorsque l'autorisation de paiement délivrée, une étape de transmission (T05), au terminal du commerçant, d'une donnée représentative de l'acceptation de la transaction ;
• lorsque l'autorisation de paiement est négative, une étape de transmission (T06), au terminal du commerçant, d'une donnée représentative d'un refus de la transaction.

On the side of the banking server, the treatment process is as follows:

• receiving (T01) data from the payment terminal, including the identifier of the payment container;
• obtaining (T02) a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant;
• according to the identifier of the payment container, determining (T03) an identifier of a banking establishment to which the payment container is attached;
• according to the bank identifier of the payment container, obtaining (T04) a payment authorization; and
• when the payment authorization issued, a transmission step (T05) at the merchant's terminal, a data representative of the acceptance of the transaction;
• when the payment authorization is negative, a transmission step (T06) at the merchant terminal of a data representative of a refusal of the transaction.

• lorsque l'établissement bancaire du conteneur de paiement est le même que l'établissement bancaire du serveur de traitement (T041) :
  • obtention (T0411) des attributs du conteneur ;
  • vérification (T0412) du solde restant au sein le conteneur de paiement ;
  • lorsque le solde restant au sein du conteneur de paiement est supérieur au montant de la transaction (T0413) :
    • vérification (T0414) qu'aucun des attributs du conteneur de paiement n'est en contradiction avec les données de la transaction (montant maximum, catégorie de commerçant autorisée, etc.) ;
    • lorsqu'aucun (T0415) des attributs de paiement n'est violé, délivrance de l'autorisation de paiement ;
    • soustraction (T0416) un montant de la transaction du solde restant au sein du conteneur de paiement ;
  • lorsque le solde restant au sein du conteneur de paiement est inférieur au montant de la transaction (T0417), transmission d'une absence d'autorisation ;
• lorsque l'établissement bancaire du conteneur de paiement est différent de l'établissement bancaire du serveur de traitement (T042) :
  • identification (T0421) du serveur de traitement auquel les données de transaction doivent être transmises ;
  • transmission (T0422) des données de de transaction à ce serveur de traitement ;
  • réception (T0423) de l'autorisation ou du refus de paiement.

Thus, from the point of view of the merchant, the transaction takes place in the same way as a transaction carried out by credit card. As previously explained, the authorization of payment is obtained according to the identifier of the banking establishment:

• when the payment container bank is the same as the processing server bank (T041):
  • obtaining (T0411) attributes of the container;
  • checking (T0412) the remaining balance within the payment container;
  • when the balance remaining in the payment container is greater than the transaction amount (T0413):
    • verification (T0414) that none of the attributes of the payment container are in contradiction with the transaction data (maximum amount, authorized merchant category, etc.);
    • when none (T0415) of the payment attributes are violated, issue of the payment authorization;
    • subtracting (T0416) a transaction amount from the remaining balance within the payment container;
  • when the remaining balance within the payment container is less than the transaction amount (T0417), transmission of a no authorization;
• when the payment container bank is different from the processing server bank (T042):
  • identification (T0421) of the processing server to which the transaction data is to be transmitted;
  • transmitting (T0422) transaction data to that processing server;
  • receipt (T0423) of authorization or refusal of payment.

The steps implemented by the processing server receiving transaction data are substantially identical to those described above.

5.5. Other ways of using a payment container.

The following are other modes of use of a payment container in accordance with the present technique. These other modes of use tend to suppress the use of a communication terminal for use.

According to a first variant, the use of the payment container by the user is carried out via a biometric authentication at the merchant. At first the user creates a payment container, this payment container can be limited geographically, temporally or by its amount (as explained above). Then the user goes to a merchant. At the time of payment, the user indicates that he wishes to make a payment by payment container and that he wishes to authenticate by biometrics.

1. (a) en faisant composer à l'utilisateur un code PIN de 4 chiffres : on alors divise par 10000 l'effort de comparaison ;
2. (b) en faisant entrer au marchand sur le terminal de paiement une information « Le client est un homme » ou « Le client est une femme » : on divise alors par deux l'effort de comparaison ;
3. (c) en supposant que l'utilisateur a sur lui son terminal de communication mobile on peut limiter la comparaison aux seules empreintes des titulaires de téléphones mobiles se trouvant à proximité du terminal de paiement du commerçant ;
4. (d) en requérant, de la part de l'utilisateur, la saisie des initiales (première lettre du nom, première lettre du prénom), afin de limiter les efforts de comparaison dans la base de donnée ; Cette information permet de diviser l'effort de comparaison par 26²=676 si on suppose que la distribution des premières lettres des noms et prénoms est uniforme. En pratique, ceci n'est pas nécessairement le cas, mais la réduction est tout de même importante.

The user submits to a biometric identification (typically, a fingerprint reading), which triggers the payment. The system faces a technical difficulty: when the number of users increases, the identification of the holder at the merchant becomes tedious (because processing times are longer) and also source of errors. Indeed, the entity that performs the biometric comparison (a server for example) must compare the impression collected at the store to all those in the database. Thus, on the server side, it is proposed to accelerate this comparison by several techniques:

1. (a) by dialing the user a PIN code of 4 digits: then divide by 10000 the comparison effort;
2. (b) by sending the merchant to the payment terminal an information "The customer is a man" or "The customer is a woman": the comparison effort is then divided by two;
3. (c) Assuming that the user has his mobile communication terminal on him, the comparison can be limited to the fingerprints of the mobile phone holders located near the merchant's payment terminal;
4. (d) by requiring the user to enter the initials (first letter of the name, first letter of the first name), in order to limit comparison efforts in the database; This information makes it possible to divide the effort of comparison by 26 ² = 676 if one supposes that the distribution of the first letters of the surnames and given names is uniform. In in practice, this is not necessarily the case, but the reduction is still important.

Such a use supposes a possible modification of the process of creation of the payment container, so that it includes a new attribute, related to the fingerprint of the creator. The fingerprint, as such, can either already be available on the communication terminal or be prerecorded at the processing server.

According to a second variant, the payment container, created using a communication terminal, can be used by two different people: in this case, either the creator and another person of his choice either they are two different people from the creator. Therefore, the recipient attribute can include an identification of several people. The use of the container is then made exclusively on the account of the creator (no transmission possible). In the case of biometric double authentication (as proposed in the previous variant), two representative fingerprint data are used in place of one.

Of course, the number of users is not limited to two.

Such use implies a possible modification of the process of creation of the payment container, so that it includes a new attribute, linked to the fingerprints of the creator and the authorized person. The fingerprint, as such, can either already be available on the communication terminal or be prerecorded at the processing server.

According to a third variant, the payment container may be recurrent. This means that the payment container includes a periodicity attribute, allowing the processing server to create a new payment container, autonomously, by making a copy of a current payment container. This use is for example interesting during the regular use of a good or service, without the need to use his credit card to do so. Take, for example, the case of an employee who has lunch every lunchtime at work. The processing server created, every day, from Monday to Friday, so that the user can make his purchase without using his credit card.

According to a fourth variant, the use of the payment container is monitored by the processing server so that it can implement anti-fraud measures. When a payment container, for example periodic, is used in a different way (for example in terms of location or range of amount) of the creator's habits, a confirmation of payment may be required from the user or even a blocking of the container may be implemented by the processing server.

5.6. Implementing devices.

We describe, in relation to the figure 4 , a device for creating and using a payment container comprising means for executing the previously described methods.

For example, the processing device comprises a memory 41 constituted by a buffer memory, a processing unit 42, equipped for example with a microprocessor, and driven by the computer program 43, implementing the steps necessary for creation of a payment container on the one hand and their use on the other hand.

At initialization, the code instructions of the computer program 43 are for example loaded into a memory before being executed by the processor of the processing unit 42. The processing unit 42 receives as input for example a set of initial lexemes or existing dictionary data. The microprocessor of the processing unit 42 implements the steps of the method, according to the instructions of the computer program 43 to allow access to the good or the service.

For this, the processing device comprises, in addition to the buffer memory 41, means for obtaining information external to the device, such as a set of data accessible in base; these means may be in the form of an access module to a communication network such as a network card. The device also comprises processing means, these data for delivering data for selecting or entering payment container attributes; these processing means comprise for example a processor specialized in this task; the device also comprises one or more means for accessing one or more databases, such as contact databases and / or bank account databases and / or bank card databases. The device also comprises a non-contact reading module and / or a shooting module such as a camera.

These means can be controlled by the processor of the processing unit 42 according to the computer program 43.

We describe, in relation to the figure 5 , a payment container processing device comprising means for executing the previously described methods, relating to the creation of a payment container or the treatment of the use of a payment container by a user.

For example, the verification device comprises a memory 51 constituted by a buffer memory, a processing unit 52, equipped for example with a microprocessor, and driven by the computer program 53, implementing necessary for the implementation performs verification functions.

At initialization, the code instructions of the computer program 53 are for example loaded into a memory before being executed by the processor of the processing unit 52. The processing unit 52 receives as input, for example, a request to create or use a payment container. The microprocessor of the processing unit 52 implements the steps of the creation method, according to the instructions of the computer program 53 to allow the creation or use of such a container

For this, the device comprises, in addition to the buffer memory 51, adapted processing means; these means can be in the form of a processor or a set of secure resources to secure the creation and processing of payment container. The device also comprises cryptographic processing means; these processing means comprise for example a dedicated encryption processor and encryption keys, such as session keys derived from an initial key.

These means can be controlled by the processor of the processing unit 52 according to the computer program 53.

Claims (15)

A method of creating a payment data structure, called a payment container, a creation method implemented by a mobile communication terminal, said payment container comprising at least one datum representative of a user's bank identifier,
said method comprising: the selection (C20), by a user and via a human-machine interface, of at least one attribute of said container, said selection comprising the selection of at least one attribute value for at least one following parameters: - category of beneficiary of the payment container; - beneficiary of the payment container. obtaining (C30), by the communication terminal, at least one datum representative of the user's bank card; - the validation (C40) by the user of the creation of the payment container; the transmission (C50) by said communication terminal of said payment container to a payment container processing server. Method according to claim 1, characterized in that said step of obtaining (C30) by the payment terminal, minus a datum representative of the user's bank card comprises: a step of transmitting, to said bank card, via a contactless data transmission interface, a request for obtaining data, in the form of a signal; a step of receiving a response to said request, in the form of a modulated signal; a step of decoding said modulated signal delivering said at least one datum. Method according to claim 1, characterized in that said step of obtaining (C30) by the payment terminal, minus a datum representative of the user's bank card comprises: a step of activating a device for shooting the communication terminal; - A step of obtaining, with the aid of the shooting device, an image of the bank card; a step of implementing a character recognition module, starting from the image of the bank card, delivering said at least one piece of data. A creation method according to claim 1, characterized in that it further comprises a step of determining, by said communication terminal, a value representative of a transmission attribute of said payment container. A method of creation according to claim 4, characterized in that when the value representative of the transmission attribute of said payment container is positive, the method further comprises a step of determining, by said communication terminal, a representative value a debit attribute of said payment container. Creation method according to claim 1, characterized in that it comprises, prior to the selection of a container parameter, activation (C10) on the user's communication terminal of a payment container management module; - Selection (C10-1), within this module, a so-called container creation mode of operation. Creation method according to claim 6, characterized in that the activation of the management module is accompanied by the authentication of said user to which said communication terminal and said payment card belong. Method according to Claim 1, characterized in that the selection, by a user and via a man-machine interface, of at least one attribute of said container comprises the selection of at least one attribute value for at least one of the following parameters: - date of validity of the payment container; - period of validity of the payment container; - amount of the payment container. Device for creating a payment data structure, said payment container, said payment container comprising at least one datum representative of a user's bank identifier,
said device comprising at least one module configured to allow: the selection (C20), by a user and via a human-machine interface, of at least one attribute of said container, said selection comprising the selection of at least one attribute value for at least one following parameters: - category of beneficiary of the payment container; - recipient of the payment container; obtaining (C30), by the communication terminal, at least one datum representative of the user's bank card; - the validation (C40) by the user of the creation of the payment container; the transmission (C50) by said communication terminal of said payment container to a payment container processing server. Method of processing, by a processing server, a payment data structure, called a payment container, previously created according to a creation method according to one of claims 1 to 8, said payment container being the subject of a a use with a merchant by a user having a communication terminal linked to said payment container, characterized in that it comprises the following steps: - receiving (T01) data from the payment terminal, including the identifier of the payment container; - obtaining (T02) a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining (T03) an identifier of a banking establishment to which the payment container is attached; according to the banking identifier of the payment container, obtaining (T04) a payment authorization, said step of obtaining a payment authorization comprising a verification step that said merchant identifier and / or code merchant category are part of the attribute values of the following parameters of said payment container: - payment container beneficiary category, for said merchant category code; beneficiary of the payment container, for said merchant identifier; and when the payment authorization issued, a transmission step (T05) at the merchant's terminal, of a data representative of the acceptance of the transaction; Processing method according to claim 10, characterized in that said step of obtaining (T04) a payment authorization comprises the following steps: - when the bank of the payment container is the same as the banking establishment of the processing server (T041): - obtaining (T0411) attributes of the container; - checking (T0412) of the remaining balance within the payment container; - when the remaining balance within the payment container is greater than the transaction amount (T0413): - verification (T0414) that none of the attributes of the payment container are in contradiction with the data of the transaction (maximum amount, etc.); - when no (T0415) payment attributes are violated, issuing the payment authorization; subtracting (T0416) a transaction amount from the remaining balance within the payment container; - when the remaining balance within the payment container is less than the transaction amount (T0417), transmission of an absence of authorization; Processing method according to claim 11, characterized in that said step of obtaining (T04) a payment authorization comprises the following steps: - when the payment container bank is different from the processing server bank (T042): - identification (T0421) of the processing server to which the transaction data is to be transmitted; - transmitting (T0422) transaction data to this processing server; - receipt (T0423) of authorization or refusal of payment. Processing server of a payment data structure, said payment container, previously created according to a device according to claim 9, said payment container being used with a merchant by a user with a communication terminal linked to said payment container, server characterized in that it comprises means of: - receiving (T01) data from the payment terminal, including the identifier of the payment container; - obtaining (T02) a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining (T03) an identifier of a banking establishment to which the payment container is attached; - depending on the bank identifier of the payment container, obtaining (T04) a payment authorization, said obtaining a payment authorization including the verification that said merchant ID and / or merchant category code are part of attribute values of the following parameters of said payment container: - payment container beneficiary category, for said merchant category code; beneficiary of the payment container, for said merchant identifier; and when the payment authorization issued, transmission (T05) to the merchant terminal, a data representative of the acceptance of the transaction; Computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, characterized in that it comprises code instructions of program for executing a creation method according to claim 1, when executed on a processor. Computer program product downloadable from a communication network and / or stored on a computer-readable and / or executable medium by a microprocessor, characterized in that it comprises program code instructions for the execution of a method processing device according to claim 10, of a payment container according to claim 14 when executed on a processor.

Images