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/22—Payment schemes or models
  • G06Q20/229—Hierarchy of users of accounts
• • 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/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
• • 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/401—Transaction verification
  • G06Q20/4014—Identity check for transactions
• • 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
• • 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
  • G06Q2220/00—Business processing using cryptography

Definitions

• the invention lies in the field of technologies used for the implementation of payment services, and in particular of digital currency, mobile payment, prepaid payment, card or non-card services.
• the invention relates more particularly to the management of authorization of access by a third party to such a payment system associated with a holder user, in order to carry out payment transactions.
• Such payment services are for example and without limitation:
• An online payment and / or money transfer service system An online payment and / or money transfer service system.
• Such payment services can be associated with a bank account of the user, or based on a prepaid account, or else associated with a means of payment associated with a bank account of the user (for example a card, or a account of a service provider, for example a mobile communications operator).
• a means of payment associated with a bank account of the user for example a card, or a account of a service provider, for example a mobile communications operator.
• the providers of these payment services require that before carrying out a payment transaction ordered by the user authenticated with the payment service, the balance of the user's account with payment service is not negative or else a payment method associated with a user's bank account is associated with the user's payment service account. In other words, the user must either transfer from money to their payment service account or else associate a payment method associated with a bank account, in order to be able to carry out a payment transaction via the payment service account.
• the types of payment services mentioned above allow one-off payment transactions to be carried out.
• the operating mode of these payment services is not suitable for setting up other services such as direct debit, surety, credit, etc., because it is not possible to anticipate a balance of an account of a user of such a payment service, at a fixed date in the future. Indeed, the account could no longer be funded, or even closed.
• the use of this type of payment services by users therefore poses a problem of third-party trust vis-à-vis these users ....
• the identity of a user associated with a payment service account is unique.
• the invention improves the state of the art. For this purpose, it relates to a method for managing an authorization to access a payment service provided to a user, called the executive user.
• the method is implemented by a processor of a management device, and comprises:
• the invention thus allows a holder user to assign to one or more delegated users an authorization to access a payment service provided to him.
• the owner of the payment service is a user with authentication data allowing him to authenticate with the payment service provider and access the payment service.
• the payment service can be a mobile payment service based on a prepaid account, or else an online payment service associated with a payment method of the holder user, for example a bank card, or associated with a account authenticated with a service provider, for example a communications network operator.
• the invention makes it possible to extend the range of services offered by this type of payment service to users of payment services, in particular mobile or online, and to their entourage, while guaranteeing the identification constraints required vis-à-vis. with regard to the regulations in force, a control of the transactions carried out and an increased level of security.
• the employee user can delegate access rights to the payment service with which he is authenticated in order to allow delegated users to carry out payment transactions.
• the security of the authentication data of the holder user is guaranteed because the latter does not provide his identifier and secret code to third parties.
• a user delegated to an authorization to access the payment service of the holder user has temporary access data (identifier and code) generated and provided by the management device and associated with this delegated user.
• Temporary access data is transmitted to the delegated user, or to another beneficiary user, in the event that the delegated user is not the originator of the payment transactions to be carried out via the payment service provided. to the condominium user.
• the method of managing a access authorization defined above is used to delegate access rights to the account of the holder user.
• the request further comprises an indication of a type of access authorization and at least one parameter associated with said type of access authorization.
• the holder user gives access to a payment service provided to him or to his account for a given type of authorization. For example, access can be given for one type of transaction only, such as a direct debit authorization, joint surety, ...
• the type of authorization is associated with parameters allowing the management device or a server to control the use of the payment service or the account made by the delegated user.
• parameters are the authorized amount, the frequency of a payment, the validity period of the authorization, ....
• the management method further comprises, prior to the transmission of said temporary data:
• the creation of the access authorization is confirmed by the holder user by sending his confidential code.
• the management device can thus verify the authenticity of the request to initialize an access authorization received.
• the generation of temporary data comprises:
• the public identifier is generated from the identifier of the holder user and an encryption key. This same key is also used to generate the confidential code associated with the generated public identifier.
• the generated confidential code is not stored by the management device. This confidential code is sent to the delegated user.
• the management device or a server can decode a received confidential code, using the encryption key and verify whether the delegated user or the other user is properly authorized to access the payment service of the derivative user.
• the management method comprises beforehand:
• this particular embodiment of the invention is advantageous in the case where the delegated user wishes theoxy user to stand surety for him.
• the delegated user can ask several first users to stand surety for him.
• the delegated user sends as many requests to initialize an access authorization as there are users to whom he wishes to ask to stand surety for him.
• the management device when the management device receives at least one other request for initialization of at least one access authorization, coming from a terminal of another holder user, and intended to allow said delegated user to access said payment service of said other holder user, said request comprising at least the identifier of said delegated user and an identifier of said other holder user, the method further comprises:
• This particular embodiment of the invention makes it possible to create an aggregated account for the delegated user from several payment services or accounts of employee users who have authorized him access to the payment service which respectively provided them.
• the management method further comprises:
• the invention also relates to a device for managing an authorization to access a payment service provided to a holder user, comprising a memory and a processor configured to: receive, from a terminal of said holder user, a request initialization of at least one access authorization, said access authorization being intended to allow at least one delegated user to access said payment service provided to said holder user, said request comprising at least one identifier of said delegated user and an identifier of said holder user, generating temporary access data to the payment service associated with said delegated user, said temporary data comprising a public identifier associated with said delegated user, and a confidential code associated with said public identifier, transmitted to at least one terminal of the delegated user or of another user said data t emporaries.
• the aforementioned management device is included in a server.
• the invention also relates to a computer program comprising instructions for implementing the above management method according to any one of the particular embodiments described above, when said program is executed by a processor.
• the management method can be implemented in various ways, in particular in wired form or in software form.
• 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. desirable shape.
• the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
• the aforementioned recording media can be any entity or device capable of storing the program.
• the medium may include a storage means, such as a memory.
• the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
• the programs according to the invention can in particular be downloaded from an Internet type network.
• the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the management method in question.
• FIG. IA illustrates an example of an environment for implementing the invention according to a particular embodiment of the invention
• FIG. IB illustrates an example of an environment for implementing the invention according to another particular embodiment of the invention
• FIG. 2A illustrates the steps of the method for managing an authorization to access a payment service provided to a user according to a particular embodiment of the invention
• FIG. 2B illustrates the steps of the method of managing an authorization to access a payment service provided to a user according to another particular embodiment of the invention
• FIG. 3 A illustrates other steps of the method for managing an authorization to access a payment service provided to a user according to a particular embodiment of the invention
• FIG. 3B illustrates other steps of the method for managing an authorization to access a payment service provided to a user according to another particular embodiment of the invention
• FIG. 4 illustrates an example of a management device according to a particular embodiment of the invention.
• the invention proposes a method for managing authorizations for access to a payment service provided to a user, also called the holder user hereinafter, to allow third parties (delegated users, beneficiary users) to carry out payment transactions via the payment service provided to the derivative user.
• the invention makes it possible to widen the range of services offered to payment system users, and in particular to payment systems based on a prepaid account, by guaranteeing the constraints of identification, control of transactions and a level of security. security equivalent to conventional banking transaction mechanisms.
• the management method described below offers a secure mechanism for setting up a delegation of access rights to a payment service used by a holder user allowing third parties to carry out transactions using the payment service provided to the user. 'titular user while respecting certain constraints and using an identifier and a secret code different from that of theoxy user.
• the mechanism is thus secure and the transactions carried out are traceable. In other words, the identity of the third party requesting the completion of the transaction is authenticated before the transaction is executed.
• the management method described below makes it possible to set up a delegation of payment rights. access to the account of the holder user.
• FIG. 1A An example of an implementation environment of the invention according to a particular embodiment of the invention is described below in relation with FIG. 1A.
• the environment of FIG. 1A comprises a terminal TPI of a holder user P1.
• the holder user PI has authenticated access to a payment service provider, for example a mobile payment service.
• the payment service is based on the use of an account created for each holder user with the service provider, for example, a prepaid account.
• the payment service can operate without requiring the creation of an account.
• an authenticated holder user of the payment service associates with his authentication data with the payment service, a means of payment associated with a bank account or with an account of another service provider (for example an operator). communications).
• the environment includes, for example, one or more payment server (s) SP of the payment service provider.
• the payment server SP receives and executes payment orders and responds to account balance consultation requests.
• an account balance consultation request may correspond to a query of a balance availability or of a ceiling authorized by the means of payment which has been associated with the data. authentication of the holder user with the payment service.
• the entity user here PI
• the environment also includes a delegate user DI provided, for example, with a TD1 terminal.
• the delegate user DI does not necessarily have an authenticated account with the payment service provider.
• this user DI receives, for example on his terminal TD1, provisional access data to the payment service or to the account of the user P1.
• provisional data include in particular a public alias and an associated secret code. to this public alias.
• the environment also includes a beneficiary user B1, provided with a terminal TB1.
• the beneficiary user has authentication data with a provider of payment service, which may be identical or different from the payment service provider with which the holder user PI has authentication data, and an authenticated account as appropriate.
• the beneficiary user B1 is able to receive a payment ordered by the delegated user DI and paid via the payment service provided to the holder user PL When the payment service is associated with an authenticated account, this payment is paid via the account of the holder user, otherwise via the means of payment associated with the authentication data of the holder user.
• the beneficiary user B1 can check the solvency of the account of the holder user Pl.
• the beneficiary user B1 is identical to the delegate user DI.
• the environment also includes a SERV management device, managed by the payment service provider providing the payment service to the holder user P1.
• This SERV server implements the authorization to access the payment service.
• the entity user P1 by the generation and management of public aliases, the generation of associated secret codes and their securing and the management of the specific constraints set for the use of the aliases generated.
• the SERV management device is included in the server SP of the payment service provider.
• the SERV server responds to requests:
• From a delegated user to request the execution of a transaction by providing G received public alias and the associated temporary secret code.
• the server checks that the conditions of use (thresholds, amount, date, etc.) comply with the conditions set during the implementation of the access authorization, From a beneficiary user: when this user is a user other than a delegated user, to request the execution of a payment / transaction request at maturity by providing the public alias received.
• the implementation of an authorization to access the payment service provided to the holder user PI can be carried out via the terminals TPI, TD1 and TB1 of the various users in play, for example via a dedicated application provided by the service provider.
• payment service for the holder user PL Such an application comprises in particular, for the holder, a form for declaring a third party and entering credentials for delegated users.
• the application when entering for the initialization of an access authorization, can allow the holder user to specify a type of delegation, such as direct debit, deposit, payment card, etc., as well as specific constraints of use such as duration, frequency, maximum amount allocated ...
• the application also includes, for the beneficiary or the delegatee, one or more forms allowing the entry of an alias instead of the current identification (for example MSISDN) and the secret code associated with this alias, as well as an interface making it possible to request the execution of a payment order or a balance consultation to check an available balance.
• the terminals TPI, TB1 and TD1 communicate with the server SERV via a communication network RES.
• the PI holder user can authorize access to his payment service to several Dl delegate users,
• the same delegate user D1 can be authorized by several holder users PI, P2, ..., PN, to use their payment service.
• FIG. 1B illustrates an example of implementation of such a particular embodiment of the invention.
• the environment of FIG. IB comprises for example, in addition to the elements already presented in relation to FIG. IA, a number N of derivative users PI to PN respectively provided with a terminal TPi, i ranging from 1 to N, N being an integer greater than 1.
• the delegate user DI receives authorization to use the payment service or the account of each of the holder users PI, .. PN.
• the authorizations received by the delegate user DI on each of the accounts of the holder users PI, ..., PN are aggregated into an aggregated account allowing a beneficiary user B1, for example equipped with a terminal TB1 , to request the execution of a transaction on the aggregated account from the accounts ofoxy users PI, ..., PN.
• FIG. 2A illustrates the steps of the method of managing an authorization to access a payment service provided to a user according to a particular embodiment of the invention. The method is described here in the case where the payment service is associated with an account.
• the holder user PI requests the establishment of a debit authorization for the benefit of the delegate user DI.
• this involves authorizing a service provider to request the execution of a payment due (invoice) to the account of the holder user Pl.
• the holder user P1 sends, via his terminal TPI, a request to initialize an access authorization.
• a request comprises in particular an identifier of the delegate user DI and the identifier of the holder user Pl.
• the holder user Pl indicates the type of authorization requested, here direct debit authorization, and defines optional parameters associated with the type of authorization. For example, the holder user Pl indicates a maximum amount per execution request, a frequency or authorization of an execution of a payment order per unit of time, a period of validity of the authorization, a maximum amount allocated authorization, etc ....
• the identifier of the delegated user DI provided is an identifier authenticated with the payment service provider with which the principal user P1 is also authenticated.
• the delegated user has an account authenticated with this operator.
• the server On receipt of the request, during a step E210, the server generates temporary account access data associated with the delegate user D1.
• the server generates an alias or also called a public identifier, from the identifier of the holder user PL This alias is associated with the delegate user D1.
• the server encodes, using a server-specific key, selected from a list of available keys, the authenticated identifier of the holder user PI to produce a public alias in a target format depending on the type of authorization.
• the server sends the terminal of the holder user PI, a request for confirmation of the access authorization initialization request.
• the holder user PI confirms his request during a step E230, by sending the server a confirmation message comprising the confidential code (secret code) of the holder user PL
• the server then generates a temporary secret code associated with the alias generated during step E210.
• the server encodes, using the selected key, the secret code of the holder user PI to produce a new secret code of the same size associated with this alias in the form of 4 digits for example.
• the temporary data associated with the delegated user can be of the following form: for the alias: an 8-digit code (in the case of a classic identifier) or a 16-digit code (in the case of 'an identifier corresponding to a “corporate” card identifier - corporate in French -), and for the temporary secret code: 4 digits.
• the server then records the data associated with this authorization: identifier of the holder user PI alias (public identifier) temporary generated, index of the key used for encoding, the use parameters defined by the derivative user Pl.
• the server never records the secret code of the holder user PI in clear, nor the temporary secret code generated, but retains a means of decrypting it on the fly during the execution of a transaction. from the data received (alias + associated temporary secret code).
• the server then broadcasts, via the network RES, to the delegated user DI and the holder user PI, G generated alias, corresponding here for a debit authorization, to an aggregation of the generated alias and the provisional secret code.
• the public alias is sent by the server, via the RES network, to the holder user PI who is responsible for transmitting it to the beneficiary user, via the RES network or any other suitable communication network.
• the generated temporary secret code is sent directly by the server by a secure means to the delegated user.
• the implementation of the authorization to access the account of the PI holder user results in the issuance of an authorization ticket (combination of the associated alias to the delegate user DI and the temporary secret code), not taken from the account of the holder user PL In other words, the sum is always available for the holder user Pl.
• the delegated user DI wishing to make a payment to the account of the holder user P1, during a step E270, the delegated user DI enters his identifiers on the application of his terminal TD1: the public identifier (alias ) received, the provisional secret code received, the amount of the payment.
• the public identifier alias
• the server obtains the encryption key used from the key index which has been stored with the public identifier received. It then obtains the identifier and the confidential code of the derivative user, by decoding the public identifier and the temporary secret code received from the obtained encryption key.
• the server checks the conditions of use associated with the public alias: validity, amount, payment frequency, etc. If the conditions are valid, during a step E291, the server transmits an execution order for payment of the amount for the benefit of the delegated user D1, via the account of the holder user PL For this, the server SERV transfers the payment request to a payment transaction server SP, with the secret code and the decoded identifier of the holder user PI and requests the execution of the payment on behalf of the user holder PI of the account.
• the payment transaction server SP transfers the sum of the account of the holder user PI to the account of the delegate holder Dl.
• the user who owns the account is notified and receives a request for validation of the transaction (not shown in FIG. 3A).
• step E290 When the conditions verified in step E290 are not valid, the transaction, here a direct debit, is rejected.
• the server notifies the delegate user Dl and the holder user PL
• a beneficiary / delegated user can check the solvency of a holder user, for example before making a direct debit request.
• the beneficiary user enters the temporary data received including the alias and the temporary secret code.
• the server receives this request and extracts the ID of the holder user and his secret code.
• the server requests an account and balance verification on behalf of the holder user and transfers the result in an OK / KO form to the beneficiary / delegate user, via the RES network.
• FIG. 2B illustrates steps of the method for managing an authorization to access an account of a user according to another particular embodiment of the invention.
• a delegated user Dl requests an access authorization from several principal users Pi, i ranging from 1 to N.
• an entrepreneur (delegated user Dl) asks investors (users Pi holders) to make a certain amount available to help them develop their business. Investors undertake to provide him with all or part of this sum which will not be withdrawn from their account, nor even blocked, but the sum appears to be virtually available on the entrepreneur's account with the payment service provider.
• the setting up of the authorizations on the accounts of the derivative users is done in a manner similar to that described in relation to FIG. 2A.
• the terminal TD1 of the delegate user DI sends the server SERV a request for initializing an authorization to access the account of the holder user Pi, the request comprising the identifier of the delegated user Dl, the identifier of the holder user Pi and a payment transaction amount.
• the server SERV sends to the terminal of the holder user Pi, a message informing the holder user Pi of the request sent by the delegate user D1 indicating the identifier of the delegate user Dl, and the payment transaction amount.
• steps E200i, E210i, E220i, E230i, E240i and E250L are carried out. These steps are identical to steps E200, E210, E220, E230, E240 and E250 described in relation to FIG. 2A.
• the server SERV creates an aggregated account for the delegated user Dl from the aliases generated from each holder user Pi, and the associated temporary confidential codes.
• This aggregated account then comprises a new alias corresponding to the concatenation of the aliases of each holder user Pi and a temporary secret code generated from the associated temporary confidential codes.
• This aggregated account also includes a key index concatenation and distribution rules for executing a payment through the aggregated account.
• the server stores the temporary data of the aggregated account for each type of delegation requested by the delegated user Dl.
• the SERV server therefore initiates the two types of authorization with the temporary data of the aggregated account. Then, the SERV server broadcasts the temporary data.
• the server SERV transmits to the terminal of the delegated user Dl, a concatenation of the new alias and temporary secret code of the aggregated account.
• the terminal of the delegated user Dl transmits these data, during a step E330, to the beneficiary user B1, via the RES network or any other suitable network.
• the server SERV transmits to the terminal of the delegated user Dl the new alias of the aggregated account. It then transmits, during a step E341, via a secure means, the temporary secret code of the aggregated account to the terminal of the delegated user Dl.
• the entrepreneur For the deposit or security deposit, at the request of a service provider (beneficiary user Bl), the entrepreneur (delegated user Dl) will provide a guarantee on the basis of the deposit for the supply / G use of a good or a service.
• the service provider receives a direct debit authorization code (alias and temporary secret code) on the aggregated account allowing it to check the status of the accounts. surety or to execute a payment according to the conditions provided.
• a direct debit authorization code alias and temporary secret code
• the entrepreneur uses the company's account for his activity and if he exceeds the limit available on his own account, he has the option of using the cash reserve made available to him by the surety (Pi holder users).
• the system then distributes the request for the use of the reserve to one or more guarantors.
• a surety refuses, the requested sum is distributed among the other sureties. If a surety account is not sufficiently funded, the request is rejected for this account and the requested amount is distributed among the other sureties. If all guarantors agree, the money is transferred directly from the surety's accounts to the beneficiary's account. The money is not paid directly into the account of the entrepreneur.
• the beneficiary B1 wishes to consult the balance of the aggregated account. To do this, during a step E350, it transmits to the server SERV via its terminal TB1 a request for the status of surety, indicating G public alias and the provisional secret code which have been communicated to it. During a step E351, the server SERV extracts from G alias and the provisional secret code, the key indexes used to generate the provisional confidential codes and the public identifiers of each holder user Pi.
• the server SERV decodes the identifier of the holder user Pi and his secret code and during a step E353i, the server checks with a server SB of the payment service provider the account balance of the holder user Pi.
• the server SERV sends back to the terminal of the beneficiary user B1 the status of the deposit for each holder user Pi.
• the server SERV aggregates the surety statuses of all the derivative users questioned and provides the beneficiary user B1 with the overall status of the surety provided by the delegated user D1, for example by verifying that the total sum available on all the accounts of the derivative users is greater than or equal to the amount required in the initial request transmitted during step E350.
• the delegated user Dl wishes to use his cash reserve to make a payment for the benefit of the beneficiary user B1.
• the delegated user Dl transmits to the server SERV via his terminal TD1 a request for payment indicating G public alias and the provisional secret code communicated to him, as well as the amount of the payment.
• the server SERV extracts from G alias and the provisional secret code, the key indexes used to generate the provisional confidential codes and the public identifiers of each holder user Pi.
• the server SERY decodes the identifier of the holder user Pi and his secret code and during a step E363i, the server checks that the conditions relating to the delegation authorization put in place are valid. If this is the case, during a step E364i, the server SERV transmits to the server SP a payment execution order for part of the amount requested by the delegated user D1. During a step E365Î, the server SP triggers the execution of payment from the account of the holder user Pi to the account of the beneficiary B 1.
• the beneficiary user B1 wishes to apply the deposit which has been provided to him and request the realization of the payment of the deposit. For this, during a step E370, the beneficiary user B1 transmits to the server SERV via his terminal TB1 a payment request indicating G public alias and the provisional secret code communicated to him, as well as the amount of the payment. The server then proceeds as for example C2 described above.
• step E365i the server SP triggers the execution of the payment from the account of the holder user Pi to the account of the beneficiary B1.
• FIG. 4 illustrates an example of a SERV management device according to a particular embodiment of the invention.
• the management device SERV has the conventional architecture of a computer, and in particular comprises a memory MEM, a processing unit UT, equipped for example with a processor PROC, and controlled. by the computer program PG stored in memory MEM.
• the computer program PG includes instructions for implementing the steps of the authorization management method which is described above, when the program is executed by the processor PROC.
• the code instructions of the computer program PG are for example loaded into a memory before being executed by the processor PROC.
• the processor PROC of the processing unit UT notably implements the steps of the method for managing an authorization according to any one of the particular embodiments described in relation to FIGS. 2A, 2B, 3 A, 3B according to FIGS. PG computer program instructions.
• the management device SERV also comprises a communication module COM allowing the management device to establish communications, via a communications network, for example a fixed or mobile data network.
• a communications network for example a fixed or mobile data network.
• the management device SERV is included in a server, for example a server of a payment service provider.

Landscapes

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

Applications Claiming Priority (2)

Publications (1)

Family

ID=70613949

Family Applications (1)

Country Status (4)

Family Cites Families (9)

• 2019
  • 2019-12-19 FR FR1914842A patent/FR3105513A1/fr active Pending
• 2020
  • 2020-11-26 EP EP20821056.7A patent/EP4078495A1/de active Pending
  • 2020-11-26 WO PCT/FR2020/052177 patent/WO2021123527A1/fr unknown
  • 2020-11-26 US US17/786,492 patent/US20230009823A1/en active Pending

Also Published As

Similar Documents

Legal Events