WO2022136236A1 - Procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire - Google Patents

Procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire Download PDF

Info

Publication number
WO2022136236A1
WO2022136236A1 PCT/EP2021/086728 EP2021086728W WO2022136236A1 WO 2022136236 A1 WO2022136236 A1 WO 2022136236A1 EP 2021086728 W EP2021086728 W EP 2021086728W WO 2022136236 A1 WO2022136236 A1 WO 2022136236A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
beneficiary
bank
server
holder
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2021/086728
Other languages
English (en)
Inventor
Denis LENGELLÉ
Frédéric ZENOU
Frederic Dao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SAS
Original Assignee
Thales DIS France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales DIS France SAS filed Critical Thales DIS France SAS
Publication of WO2022136236A1 publication Critical patent/WO2022136236A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/229—Hierarchy of users of accounts
    • G06Q20/2295—Parent-child type, e.g. where parent has control on child rights
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/387—Payment using discounts or coupons
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates

Definitions

  • the invention relates to a method for creating a payment instrument for the benefit of a third party beneficiary.
  • the invention relates to a new service for digitizing payment cards.
  • the disadvantages of the gift card are the time required to do the above operations, limits on the number of merchants accepting the gift card, limitations in its use, possible loss or partial use of the gift card and therefore a loss of money for the donor. Furthermore, a transfer of money from account to bank account is not instantaneous, and a child (the receiver) may not have an account and simply have a mobile phone or a connected object;
  • Digital gift cards are used by online merchant sites on the internet. However, they must be purchased by the donor. Money may be lost if the card is not used. The scheme implemented is not linked to the holder's bank account.
  • tokenization can be used to secure payment data (PAN, expiry date, etc.),
  • tokenization refers to a process consisting in replacing bank data (number of cards, etc. confidential or sensitive by j etable data called “j eton” (token in English). This solution reassures the cardholder, especially when paying on the Internet or by NEC.
  • This principle of data security consists of separating the information from the token code that covers it. To present a satisfactory level of security, a token must be irreversible and generated randomly.
  • a calculation of the token can be made from random numbers calculated by software or by cryptographic devices.
  • the return of the original data is referred to as “de-tokenization” and is only authorized during clearly identified processes and limited to certain applications, processes or users.
  • Tokenization makes it possible to secure sensitive transaction data, reducing the exposure of sensitive data to the risk of fraud.
  • tokenized critical data is deemed to be desensitized and can be stored or processed without risk. In the event of fraud, these tokens cannot be used in a system that does not have access to detokenization (case of an interoperating open system such as a system using EMVCo standard tokens).
  • the generation of payment tokens is the similar known process which also consists of replacing the traditional bank card number with a unique digital identifier for online, mobile and connected device transactions.
  • EMVco As a global standards body oversees EMV (Visa, MasterCard and American Express) specifications.
  • EMVCo the global standards body that oversees EMV specifications to ensure interoperability and acceptance
  • EMVCo has since capitalized on this framework using input from EMVCo members and the industry to improve the availability and adoption of tokens around the world.
  • EMVCo has extended its scope to develop token generation specifications and released the initial version of this specification in March 2014.
  • US10380596(B1) describes steps for receiving a request to create a gift token representative of a gift recipient and gift limitations of a first computing device.
  • the method also includes a step of generating a symbolic PAN associated with a gift account and transmitting the symbolic PAN and gift limitations to a second computing device.
  • the method includes detecting a transaction authorization request representative of an attempted transaction at a merchant POS device based on monitoring transaction authorization data from a plurality of merchant POS devices.
  • the invention aims to solve the aforementioned drawbacks or objectives.
  • the objective of the invention is to propose a digitization of a card (or other payment instrument, which may for example be an HCE token or a token stored in a digital wallet in a communicating device) for a beneficiary (or receiver) of a gift (for example, a person who wants to make a pecuniary gift to his child, or a friend) .
  • the invention proposes a digitized card service which makes it possible to use the bank account of the initiator (the donor or issuer or applicant) of the financial gift (or of a payment right).
  • the invention may consist, according to a preferred embodiment, in generating a payment instrument in the form of tokens (secure token or electronic certificate of sensitive data), for the benefit of third parties, using the bank payment data of a bank account holder.
  • tokens secure token or electronic certificate of sensitive data
  • the invention can make use of an existing infrastructure, operating according to standardized “tokenization” schemes for the generation and use of “tokens”.
  • the subject of the invention is a process for the creation of a payment instrument for the benefit of a third-party beneficiary, said process comprising the following steps: request or request for the creation of a digital payment instrument from a banking server of a bank account or bank card holder, using a first banking application of a communication device of the holder, transmission to a communication device of the beneficiary comprising a second banking application, by said banking server, of enrollment data, said enrollment data comprising an identifier of said bank card and an authentication certificate for the enrollment data; enrollment of the beneficiary (B) with an enrollment server and/or secure token server, by communicating said enrollment data using a second communication device, said enrollment server and/or server token being configured to generate from said enrollment data, a secure transaction token or request it from the token server;
  • the method is distinguished in that the beneficiary is a third party distinct from the account holder with a second communication device distinct from that of the account holder, and in that said request for creation of the payment instrument comprises a communication from at least one contact address of said beneficiary.
  • the invention has the advantage of allowing any bank to manage the tokenization itself in an autonomous manner. And, from an EMVco specification point of view, this management is completely transparent.
  • the invention also has the advantage of being based on an ecosystem defined by the EMVCo standard concerning tokenization.
  • the invention can therefore apply de-facto to several banks which would adopt the method of the invention while complying with the same EMVco specification.
  • the request or request may include information related to the holder's bank account or to a holder's bank card;
  • the information linked to the holder's bank account or bank card can be tokenized information (token ID or j eton ID) representing the bank card number;
  • the request or request may include information limiting the amount authorized for the payment instrument and/or an indication of the uniqueness or plurality of the use of the payment instrument and/or information relating to merchants permitted;
  • the method may include a step of authentication of the holder on the banking application to access a service, application or function for creating said payment instrument for the benefit of a beneficiary;
  • the method may include a step of transmitting to the third party an activation code or an invitation to return to obtain said enrollment data;
  • - Said activation code may include an OTP to be verified by the banking server to communicate the enrollment data to the third party, in the event of successful verification;
  • the authentication certificate may include an OTP to communicate the enrollment data to the third party beneficiary;
  • the holder's banking application and/or the beneficiary's application may include or constitute an application and/or a third-party digital wallet separate from the bank and may include a digital bank card in the form of token-ID A;
  • - Beneficiary's banking application may include or constitute a third-party digital wallet application separate from the bank and includes a digital bank card in the form of token-ID B .
  • Another object of the invention is a system for creating a payment instrument for the benefit of a third-party beneficiary corresponding to the above method. It can be distinguished in that the provisioned token is associated with the holder's bank account, and usable by said beneficiary, separate from the holder, via said second communication device, separate from the first communication device, and in that said creation request of the payment instrument includes a communication of at least one contact address of said beneficiary.
  • the system can also have as obj and a corresponding TR and/or TSP server, having the function of de-tokenizing the token received, in particular following or during a payment transaction, in order to find or associate an identifier of the bank card (physical and/or virtual) and/or a bank account of the holder, on which the debit operation relating to the payment transactions carried out by the beneficiary will be carried out.
  • This operation can be carried out in cooperation with the bank (banking server) of the holder.
  • the invention also relates to a payment instrument created for the benefit of a third-party beneficiary, said instrument being stored in a second communication device of the beneficiary and being associated with a bank account and/or a physical or virtual bank card. ' a holder of a bank account and/or holder of a physical or virtual bank card, separate from the beneficiary.
  • FIG. 1 illustrates steps of a method and a system for creating a payment instrument, in accordance with a preferred embodiment or embodiment of the invention
  • FIG. 4 illustrates steps of a method and a system for creating a payment instrument, in accordance with an additional mode of implementation or embodiment of the invention in which applications and a supplier server 54 are used of a third-party digital wallet distinct from that of the bank.
  • FIG. 1 is illustrated a preferred example of the system (or hardware architecture) 20 of the invention as well as the preferred steps (1 to 13) of a method in accordance with the invention making use of this system.
  • the invention in this mode or preferred example, implements two types of main actors:
  • a person T or physical entity called indifferently thereafter, issuer, applicant, initiator or holder of a bank account (the latter possibly also being the holder of a physical or virtual bank card) who wishes to procure a payment instrument secure 25 (or token B identified by "token-ID B") (with predefined donation or gift limits) to a third-party beneficiary B (someone or an entity) natural person hereinafter interchangeably referred to as recipient, beneficiary or third party beneficiary B;
  • the person B or entity called the recipient is the one who receives the payment instrument (or means) (25, token B identified by token-ID B) from the applicant T .
  • the system 20 of the invention comprises, on the applicant or holder T side, a banking software application 22 (described below);
  • This application can preferably use a software development kit (SDK, 23) here in the example, for mobile telephone software application 21 (alternatively software application 22 for another intelligent communicating device).
  • SDK software development kit
  • the application 22 can be hosted or executed in any first intelligent communication device 21 (computer, tablet, wearable object such as a communicating watch, etc.) of the holder T, able to communicate via various telecommunication networks.
  • the first device 21 can be configured to connect and exchange, preferably automatically (in particular during an activation of request 1 by a holder T), with a banking server 24 and/or equivalent (TSP server, TR, server electronic wallet provider) described later.
  • This authentication of the applicant T can be carried out in particular on his communicating device 21, for example by PIN code, secret code or biometric fingerprint to access a pecuniary or financial donation function (gift, transfer of financial capacity to a third party) via a financial payment instrument such as a digital card and/or digital or digital transaction token.
  • This authentication step can be considered as an effective ID&V authentication of the applicant with his bank ( ID&V authentication can be a method of identification and verification with the holder's bank or an intermediate server of a supplier linked or separate digital wallet or independent of the bank) and can be achieved through strong authentication based on at least two factors.
  • the application 22 can be provided by a server of the holder's bank or alternatively provided by a digital wallet provider.
  • the application 22 can be configured to communicate with a dedicated interface server of the application 22 , for the function of creating a payment instrument , dedicated server procured or made available by this electronic wallet provider ( place of the bank server).
  • the dedicated server (not represented in this figure 1) can itself communicate or cooperate with the bank's server and/or with the TSP server, 44 .
  • the banking application 22 may also include an HCE function (English acronym for Host Card Emulation) for digitizing/digitizing the card (originator's card) in the device 21 of the initiator and/or 31 of the third party, and the card emulated can be used as a payment instrument inside a frame ( or limitation) predefined by the initiator (such as Maximum authorized amount: Max, a limit of merchants, authorized merchant sites or any other limitation).
  • HCE function English acronym for Host Card Emulation
  • the banking application 22 can be configured to establish and/or carry out communication with a server requesting a token TR, 34 (or secure token) and a server or computing entity 24 in the background of the Bank.
  • the banking application 22 is capable of providing a means 27 or information to the bank (or server) 24 to identify the card to be digitized.
  • This means 27 can be any element or information tokenized or not, token-ID A, card number encrypted or not, identifier of the holder, bank account number encrypted or not, IBAN, Swift code, making it possible to link a request 1 of the applicant T to a bank account or a PAN bank card number.
  • token-ID A card number encrypted or not
  • identifier of the holder identifier of the holder
  • bank account number encrypted or not IBAN
  • Swift code making it possible to link a request 1 of the applicant T to a bank account or a PAN bank card number.
  • the banking application 32 may be identical or similar to the application 22.
  • the application 32 may be an application from a (controlled) electronic wallet provider, provided or not by the holder's bank T or by a third party such as Apple pay TM, Google pay TM 'X...pay .
  • the system 20 also includes a bank server 24 (or an entity, system or computer interface that may be in the background of the Bank) which offers the following hardware characteristics or functions:
  • the banking server 24 may have an application programming interface (API) configured to be able to receive and/or process requests 1 from the initiator (or holder T of the bank account and/or digitized card) in order to to create the payment instrument 25, token B;
  • API application programming interface
  • the bank server can be configured to be able to find (or associate) the holder's bank account and/or the holder's physical or digitized card T from information 27 , via a token A and/or its token identifier ID A ( secure information in the form of a token, insignificant outside the system 20 and equivalent to or making it possible to find a digitized card).
  • the information 27 can be any information making it possible to subsequently debit the bank account of the holder T, such as for example a bank card number (PANs or ID tokens).
  • These queries 1 can include as a parameter:
  • a maximum authorized payment amount 28 (if applicable, other limitations which may also include a limitation as to authorized or prohibited merchants)
  • a contact address 26 (or information making it possible to find a contact address of the beneficiary in a server cooperating with the bank, or a telephone number, email); There may also be an indication of a communication channel (WEB, cloud, mobile phone network%) to contact beneficiary B,
  • PAN card number ancronym for Primacy account number in English
  • token-ID a token identifier linked to a card of the initiator T (the latter possibly being virtual or physical).
  • the banking computer entity 24 can preferably be configured to generate an OTP (Single-use number, also called first authentication code, or activation code 15), and associate it with a transaction relating to a request 1 for creating a payment instrument (or token) 25 from the initiator T.
  • OTP Single-use number
  • activation code 15 a single-use number
  • the token 25 can also be illustrated in the figures by its token-ID identifier, B.
  • the activation code 15 can be any information, secret code, encrypted or not, making it possible to make a link between the receipt of the acceptance by the beneficiary and the payment instrument to be created, as requested by the account holder and physical or virtual digital bank card (without associated physical card) .
  • This code 15 can be in the preferred form of an OTP.
  • This code 15 can be created (step 4) upon receipt of request 1 by the request reception server 1 (here server 24) and can be sent (step or communication 5) to the beneficiary at the contact address provided, in particular in the context of an invitation (step or communication 5) to accept the said instrument or financial gift.
  • the banking computer entity (or server) 24 can be configured to generate 28i all the parameters required to initiate card digitization (PAN/Expiry date, cryptogram, etc.). Generation 28i may include encryption of card information 28 to be digitized/digitized.
  • an intermediate server 54 (FIG. 4) of the digital wallet provider can replace banking IT entity 24.
  • the beneficiary B uses the invitation 5 to create a payment instrument 25, he can ask the banking IT entity 24 to receive the card information (27, 28) or 28i.
  • the banking computer entity (or banking server) 24 or the service application 30 (within the server 24) can authenticate the acceptance request 7 using the OTP 29 (or other activation code 15, then he can (step 8 fig.l) compose the card information, encrypt it 28i and transmit it (step 9, fig. 1) to the banking application 32 of beneficiary B in his communication device 31.
  • the banking IT entity 24 or the service application 30 can be configured to enroll new users or third-party beneficiaries B.
  • the entity banking IT can offer lighter enrollment (or less restrictive in terms of security) than for the initiator (Holder T);
  • Service application 30 may be configured to communicate with banking application 32 in beneficiary B's device;
  • TSP Tokenization platform
  • the system 20 can implement, in the example, also a platform (TSP, 44) for generating tokens (digital token, digitized card).
  • TSP platform
  • tokens digital token, digitized card
  • the tokenization platform TSP, 44 can receive an enrollment request 11 for a new digital card.
  • This enrollment request 11 can come from a token requesting computer server (TR), which can constitute an interface of the tokenization platform TSP, accessible by the device 31, via an implementation of the application 32.
  • TR token requesting computer server
  • the enrollment request 10 may have been sent previously by the mobile application 32 of the receiver or beneficiary B containing the information 27, 28, 28i of the card of the initiator (or holder T).
  • the request 29 may preferably include an authentication token 29.
  • the authentication token 29 makes it possible to make the link between the bank and the TR/TSP servers (34, 44 or 54) which can be independent of the bank.
  • a secure mechanism or system for example PKI (Public Key infrastructure in English) can be established between the server of the bank 24 and these servers 34 and/or 44 and/or 54.
  • a shared secret or a public/private key can be placed in place or between server 24 and servers 34, 44 and/or 54.
  • This secure exchange system allows the server TR, 34 and/or server 44 or 54 to verify the authenticity of the information, in particular to verify the certificate or authentication token 29 associated with the enrollment request (or the creation of a register or correspondence table in the server 34 and/or 44 and/or 54).
  • This certificate can be issued by the bank as a trusted authority or used by the bank but coming from another authority.
  • the issuer of the holder's physical (or virtual) card may, once the token (B, 25) (payment instrument) for the beneficiary has been issued with limitations, check that payment requests initiated with this token B comply with the rules of use imposed on the token, (B, 25) in particular that the total of payments does not exceed the initial Max limit amount of the gift card.
  • An alternative may be synchronization between the bank and the system 20 (outside the bank), for example the server TSP, 44 for an update of the amount used for this token-ID B, 25 gift card delegate.
  • the server TSP may be able to verify alone or in cooperation with the bank, the limitations imposed on the holder T.
  • a token requester (digital card) TR 34 associated with the server TSP, 44.
  • this requestor TR, 34 can be included, constitute or form part of the bank server 24; This can simplify or reduce the number of stakeholders or entities or infrastructure. It can be part of or associated with the TSP server.
  • the server (or token requester) TR, 34 can process or transfer, (here in the example, to the TSP server, 44), the enrollment request 11 for the new card, received (via the communication 10) from the mobile application 32 and containing the card information 27, 28 of the initiator T as well as an authentication token 29, initially created by the bank server 24, attesting to the authenticity of the digitization request and/or associate enrollment 10, 11.
  • the enrollment request (or creation of an account or a register in a digital correspondence table with the servers TR and/or TSP (or server 54) for the beneficiary) 10 can include the information 27, 28 indicated of the card, in addition to any information usually required known to those skilled in the art, to correctly provision a token in a communication device, such as for example technical capacities or characteristics of the device.
  • the request or instruction 11 for creating token B can be sent to the tokenization server TSP, 44.
  • the TSP tokenization platform or the issuing bank can be responsible for one or the other or both together in cooperation, to verify the rules of use defined with reference 28. It can for example be to consolidate the amounts used by the digital card B, 25 (identified by Token-ID B), received by the recipient and therefore verify that the limits are not reached during a payment authorization requested with the identifier "token-ID B" of the token B.
  • An initiator wants to give (or transfer payment capacities) to his child (beneficiary receiver B) to enable him to use them in particular in payment transactions.
  • the examples allow at least to give a right to use at least part (or even all) of the funds of the bank account of the holder 1, while controlling this right, thanks to a means of payment token B, 25 (with the identifier "token-ID B".
  • the holder T has the possibility of using his bank card (physical or virtual) with the bank identification number (PAN), 27 and with some restrictions 28 on the total amount available (a maximum amount authorized established) in accordance with the following steps 100 to 150:
  • the initiator T authenticates himself on the banking application 22 of his mobile telephone 21, (in particular via strong authentication, based on something he possesses, something he knows as a secret code, password and/or something that characterizes it as his biometric fingerprint); then,
  • step 110 he prepares a request, with his banking software application 22, which is transmitted to his bank's server 24 with an instruction (request 1) to send his child B a digital gift card 25, 28i directly linked to his bank card or PAN card number, 27 (then linked to his bank account) . He sends the request 1 to the bank server 24 with a means of contact 26 to contact their child (e.g. email, telephone number, any contact address, etc.);
  • the banking server 24 receives the request 1, begins with the service application 30, the creation of the gift card (token 25, card information 28i) and exchanges with the banking application 32 of the child (beneficiary B) by sending him an invitation 5, 7, 9;
  • the child B receives and processes 6 the invitation 5 to receive a payment instrument from the bank 24 and begins, using his mobile 31, a request (steps 7) to digitize the card of the father PAN, 27 with associated restrictions 28.
  • the bank (bank server) 24, via the service application 30, provides the beneficiary B with all the card information 28i (preferably with an authentication token 29) required to validate and create a token 25 allowing the associated card to be digitized. (27bis not shown associated with a bank account and/or bank card identifier 27);
  • step 140 the banking software application of the device 31 of the child 32 exchanges with the token requester TR, 34 in order to create the token using all the card information and authentication data received from the banking server. ;
  • the banking software application 32 of the child receives 13 the token 25 (Token B with its identifier "token-ID B". This allows it to be able to use the digital card to pay according to the restrictions 28 contained in the token 25 (Maximum amount allowed 28) .
  • the child wants to make a payment, he can use the token 25 like a conventional payment token, he launches the bank application 22, chooses his means of payment, he can present his biometric data to unlock access to token 25 for a payment. This can create a generation of a cryptogram that will be used for payment.
  • the card-issuing bank and the TSP platform can synchronize to verify that the maximum authorized amount 28 is not exceeded by the accumulation of payments made with the token 25 by the child.
  • the holder is certain that no money will be lost if it is not used.
  • the holder's account is not debited without use;
  • the invention ensures the ability to send a means of payment to anyone who has a mobile phone or other communicating device anywhere and instantly.
  • the invention allows a new process involving a holder, a receiver and two communicating devices with a delegation of secure payment capacity and being approved by all the parties involved (Holder, beneficiary, etc.) by including rules of use.
  • a second generic example of implementing the minimum steps of the invention and using the system 20 can be the following (steps 200-240):
  • the method includes sending a request to create a digital payment instrument 25 for third-party beneficiary B (separate from a bank account holder T), with at least information 28i comprising at at least a physical or virtual bank card identifier (PAN, token-ID) or any information linked to this account and a contact address of the third party;
  • PAN physical or virtual bank card identifier
  • the transmission of the request can be carried out using or via the holder's communicating device 21 comprising a dedicated software application 22 and able to exchange with a bank server 24 of the holder's bank T accessible online (or alternatively an interface server of the application, preferably controlled by the bank and/or a supplier of the application 22 and/or 32 or digital wallet provider);
  • the method comprises a transmission (identical to step or communication 9, fig. 1) to the device 21 of the third-party beneficiary, of information 28i (PAN, or Token-ID, limits of use, etc. .) and an authentication certificate 29 of the banking server 24 associated with this information or with this transmission 9;
  • information 28i PAN, or Token-ID, limits of use, etc. .
  • an enrollment of the payment instrument 25 of the third-party beneficiary is carried out with a server configured for this purpose (TR, 34; TR/TSP , 44, or even included in the bank 24) from said information 28i and said authentication certificate 29;
  • the method performs a provisioning of the secure token 25 associated with the payment instrument, in the communication device 31 of the third-party beneficiary B;
  • the beneficiary B can make a payment using the digital transaction token 25 (and/or payment instrument) within the Max limits predefined by the holder T (this limit can be cumulative or for unique according to the defined criteria) .
  • the phases of authentication on the holder's device can be optional.
  • the transfer 5 of the invitation is however preferable and can be done in another form ... (QR Code, 8)
  • steps 10-13 can be carried out between the device 31 of the beneficiary B and the bank server 24.
  • the invention provides a less bank-oriented solution in the sense that the proposed solution is not specific to the bank. Thanks to the invention, the bank can manage the tokenization itself autonomously. And, from an EMVco specification point of view, it's totally transparent. It can receive payment instrument creation requests 1, control them by processing them and have the creation of token B finalized with TSP and/or TR servers. The use of tokens and detokenization and possible interactions required with the bank can also take place with the TSP and/or TR servers less under the complete control of the bank.
  • the invention is based on an ecosystem defined by EMVCo concerning tokenization.
  • the management of the token can preferably be carried out by a TSP server (Token Service Provider in English) within a framework governed and maintained by the EMVco specifications and not the banks.
  • TSP server Token Service Provider in English
  • the invention can apply de-facto to several banks which would adopt the solution of the invention while complying with the same EMVco specification.
  • the invention may have the advantage of informing the cardholder in real time during the tokenization of the card.
  • the invention can provide a solution with the steps below:
  • the holder makes a request to create a tokenized gift card 25 for a beneficiary B, specifying the beneficiary contact information (email or telephone number);
  • the solution starts tokenization on the beneficiary's device, (Token 25 created and provisioned on the beneficiary's device but not activated (use for payment not possible);
  • the method can inform the holder T (directly between devices or via the bank's server) that the beneficiary B has accepted the gift card offer;
  • the method may provide for a confirmation request given by the holder (which may include an ID&V authentication mechanism) to finalize the gift card creation request);
  • the beneficiary's token 25 can be activated in the system 20.
  • the ID&V authentication steps can be executed by the bank before step 1 by strong authentication or in particular at step 8 for ID and confirmation.
  • ID&V authentication notably allows the bank to verify that the issuer T of request 1 is indeed the owner T of the account or bank card and that he is indeed authorized to make request 1 to create the instrument of payment.
  • This last step C has the advantage of adding security, the holder can check that the right beneficiary is being addressed.
  • Step C may include, alternatively or cumulatively, an exchange between the beneficiary and the sender through a dedicated channel (SMS, email, social network account, MSN, WhatsApp, etc.), to allow the sender T to verify that the beneficiary is the right person.
  • SMS SMS
  • email social network account
  • MSN mobile phone
  • WhatsApp WhatsApp
  • FIG. 4 is illustrated an embodiment of a system 20A in which the banking application 22 and/or 32 comprises or constitutes a third-party digital wallet application distinct from the bank (such as Apple pay TM or Samsung pay TM
  • the application 22 (or 32) comprises a digital bank card in the form of a token-ID;
  • the bank's server 24 can be replaced by a server from a digital wallet provider separate from that of the bank. It may be controlled by a third party entity separate from the bank.
  • TR/TSP may or may not include or constitute a single entity or computer server.
  • This scheme can be adapted to include a third player consisting of a digital wallet provider (such as Apple-pay TM or Samsung-pay TM).
  • the holder T comprises in one device 21 an application 22t of a digital application provider or of a third-party digital wallet with a tokenized bank card number (token A identified by its identifier: token-ID A).
  • the method comprises step 1 of payment instrument creation request which is identical or similar to that of FIG.
  • the account identifier or bank card of the holder T is an ID-A token (token which was created beforehand by the Holder T on his device 21 and which is identified by the identifier “token-ID A”) representing the bank card number of a physical or virtual bank card in the form of a token.
  • this request or request 1 to create a digital payment instrument reaches a server 54 interface of a digital wallet provider of a third party entity (separate or independent of the bank 24).
  • the server interfaces between the bank's server and the 22t application or the cardholder's device
  • step la the request 1 is transmitted (la) to the server TR and / or TSP identical or similar to that of Figure 1.
  • the third-party entity server 54 must direct the request 1 to the correct server TSP associated with the server 54 (indication in the request 1).
  • the server 54 can store information on payment limitations, provide payment consolidations (payment accumulation) and checks for other limitations such as (list of authorized merchants).
  • this server 34, 44 (TR and/or TSP) in turn transmits request 1 to server 24 of the bank.
  • step 2 the bank server stores request 1.
  • step 3a the bank server 24 can return an approving acknowledgment (OK) or requires ID&V authentication of the holder.
  • This message is transmitted 3b to the application 22t via the server TR and/or TSP.
  • step 3C and 8 the holder can confirm his initial request 1 and carry out optional ID&V authentication, preferably directly with the bank server.
  • Steps 4-7, 8a are identical or similar to those 4-7, 8a of Figure 1. However, steps 5, 7 or 9 can be executed on behalf of the bank by the server 54 of the third-party entity digital wallet provider.
  • the enrollment request step 10 can be performed contrary to Figure 1 via the server 54 of the entity third party which transmits it 10a to the server with the server TR and/or TSP 34, 44;
  • the provisioning step 13 of the token B, identified by its identifier "token-ID B" in the device of the beneficiary B can be carried out via the communication 13a from the server 54 of the third party entity.
  • the holder 's banking application 22 and / or the beneficiary 's application 32 can comprise or constitute a third - party digital wallet application 22t and / or 32t distinct from the bank and the application 22t can comprise a digital bank card in the form of a token identified by its identifier “token-ID A” or simply “ID A”.
  • the banking application 32 of the beneficiary B can include or constitute a third-party digital wallet application 32t distinct from the bank and include a digital bank card, in the form of a token identified by its token-ID identifier B provided in step 13a .
  • the system includes in the beneficiary's device a token identified by its identifier token-ID (B) or “ID B”, associated with the bank account or physical or virtual bank card of the holder T.
  • a token identified by its identifier token-ID (B) or “ID B” associated with the bank account or physical or virtual bank card of the holder T.
  • a TSP server or digital wallet and/or digital card provider server can include an electronic correspondence table or equivalent, associating ID tokens B of a set of beneficiaries with a set of holders T.
  • these tokens issued or used via beneficiary devices are processed in these dedicated servers, in relation with account holders bank or card physical or virtual (each physical or virtual card being linked or associated with a digital card), distinct from user beneficiaries for payment transactions. These beneficiaries may not have a current bank account.
  • the invention makes it possible to obtain, in each example or mode described previously, a payment instrument 25, Token, token identified by its identifier "ID B” or “token-ID B", created for the benefit of a third-party beneficiary (B).
  • This instrument (25, token B) is stored in a second communication device 31 of the beneficiary B and being associated with a bank account and/or a physical or virtual bank card of a bank account holder and/or card holder physical or virtual bank, digital separate from the beneficiary.
  • the beneficiary's device 31 includes or can display a bank card on the screen of the device (for example a mobile telephone), a graphic representation of the bank card of the holder's bank.
  • the displayed representation may include the holder's name. The latter may, where appropriate, be preceded by a statement “by delegation (or equivalent) of the “name” of the holder).
  • the graphic representation may also include full or partial indications of the PAN number and/or the card's expiry date; On the back can be a number (cryptogram).
  • This bank card is associated with a bank account of the holder. This represented bank card is in no way a bank card belonging to the beneficiary or user of the device, who may not have one at all. If applicable, the application may display limitations, or an accumulation of payments or a cash gift balance.
  • the application can allow a display of the parameters of use of the gift card such as, for example, the authorized merchants, a period of validity, a geographical area of use.
  • the beneficiary is informed very easily of the attributes associated with the gift card and can easily consult and know where he is in the balance or payment credit.
  • token B may have been provisioned at the same time as token B.
  • An electronic file comprising attributes of the card, and/or limitations may have been added to token B during its creation (12) and in the communication 13, then upon receipt in the device, these attributes and/or limitations can be extracted or interpreted by the application 32 to make them accessible or readable by the beneficiary on his device.
  • an alert and warning can be issued directly by the application or by one of the servers 34, 44, 54.
  • the second device 31 may have an identifier (for example IMEI and/or a telephone number distinct from that of the holder).
  • the beneficiary's contact address (email, telephone number, etc.) stored in the system 20, 20A is distinct from that of the holder of the account to be debited or of the bank card used.
  • the provisioning of the token B by a provisioning server 44 can be carried out in particular via any communication channel, in particular the mobile telephone network via OTA, via the Internet, or another network.
  • the contact data of the beneficiary (or of the device 31) for the provisioning could have been transmitted by the device 31, in particular by the application 32 automatically, at least in part during the enrollment step 10 of each example described previously.

Landscapes

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

Abstract

L'invention concerne un procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire, ledit procédé comprenant les étapes suivantes : - demande (1) de création d'un instrument de paiement digital (25) auprès d'un serveur bancaire (24) d'un titulaire (T) de compte bancaire (PAN, 27) ou de carte bancaire, à l'aide d'une première application bancaire (22) d'un dispositif de communication (21) du titulaire (T), - transmission (5) à un dispositif de communication (31) du bénéficiaire (B) comprenant une seconde application bancaire (32), par ledit serveur bancaire (24), de données (28) d'enrôlement, lesdites données d'enrôlement comprenant un identifiant de ladite carte bancaire (PAN, 27) et un certificat d'authentification (29) des données d'enrôlement; - enrôlement du bénéficiaire (B) auprès d'un serveur d'enrôlement et/ou de jeton (TR, TR/TSP, 34) en communicant lesdites données d'enrôlement à l'aide d'un second dispositif de communication (31), ledit serveur d'enrôlement et/ou de jeton (TR, TR/TSP) étant configuré pour générer à partir desdites données d'enrôlement, un jeton sécurisé de transaction (25) ou le requérir auprès du serveur (TR, 44) de jeton sécurisé; - provisionnement du jeton sécurisé (25), dans ledit second dispositif de communication du bénéficiaire, caractérisé en ce que le bénéficiaire (B) est un tiers distinct du titulaire (T) de compte avec un second dispositif de communication (31) distinct de celui (21) du titulaire de compte, et en ce que ladite requête (1) de création de l'instrument de paiement (25) comprend une communication d'au moins une adresse (26) de contact dudit bénéficiaire (B).

Description

PROCÉDÉ POUR LA CRÉATION D'UN INSTRUMENT DE PAIEMENT AU
PROFIT D'UN TIERS BÉNÉFICIAIRE
Domaine de l'invention.
L'invention concerne un procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire.
Elle concerne en particulier le domaine des cartes de paiement digitales, des cartes cadeaux.
L' invention concerne un nouveau service pour digitaliser des cartes de paiement.
Ob j ectif .
Aujourd'hui, les inventeurs se sont posés la question de savoir comment un émetteur, initiateur, demandeur ou donateur pourrait transmettre aisément et rapidement un élément, instrument ou moyen de paiement à quelqu'un qui n'est pas physiquement joignable mais qui possède dispositif de communication et un réseau de communication (ex. un téléphone mobile et une connexion internet...) .
Art antérieur
On connaît les cartes cadeaux qu'un émetteur, initiateur, demandeur ou donateur peut acheter et l'envoyer ou les donner physiquement à un receveur. Cependant, les inconvénients de la carte cadeau sont le temps requis pour faire les opérations ci-dessus, des limites quant au nombre de marchands acceptant la carte cadeau, des limites dans son utilisation, une perte possible ou une utilisation partielle de la carte cadeau et par conséquent une perte d' argent pour le donateur. Par ailleurs, un transfert d'argent de compte à compte bancaire n'est pas instantané, et un enfant (le récepteur) ) peut ne pas avoir de compte et avoir simplement un téléphone portable ou un objet connecté ;
Le recours au don en espèce, exclut d'avoir un récepteur distant, le chèque de voyage, western union exige de se déplacer pour recevoir le don donc ce n' est pas instantané ;
On connaît le principe de la digitalisation de cartes de paiement de l'émetteur de carte (banque) dans un mobile du récepteur (Banque HCE ou Apple pay, Samsung pay...) . Cependant, les principaux inconvénients sont, (1) le compte de paiement est toujours celui du demandeur et il n'y a pas de limitation dans le montant ; (2) Pendant l'opération de digitalisation, il y a généralement un mécanisme OTP qui implique le téléphone du demandeur pendant l' opération
Les cartes cadeaux digitales sont utilisées par des sites marchands en ligne sur internet. Toutefois, elles doivent être achetées par le donateur. De l'argent peut être perdu si la carte n'est pas utilisée. Le schéma mis en œuvre n'est pas lié au compte bancaire du titulaire.
On connaît également le principe de la « tokenisation » consistant à remplacer des données sensibles (bancaires, santé, identification, d'accès) par des données moins sensibles sécurisées et jetables dénommées "jeton" (token en langage anglo-saxon) .
Dans le domaine des transactions de paiement sur Internet, la « tokenisation » peut être utilisée pour la sécurisation de données de paiement (PAN, date d'expiration,...) ,
En monétique ou domaine de sécurisation de données informatiques, la « tokenisation » désigne un procédé consistant à remplacer des données bancaires (numéro de cartes , ...) confidentielles ou sensibles par des données j etables appelées "j eton" ( token en anglais ) . Cette solution permet de rassurer le porteur , notamment en paiement sur Internet ou en NEC .
Ce principe de sécurisation des données consiste à séparer l' information du code token qui la recouvre . Pour présenter un niveau de sécurité satisfaisant , un token doit être irréversible et généré de manière aléatoire .
Un calcul du token peut s ' effectuer à partir d' aléas calculés par un logiciel ou par des dispositifs cryptographiques . La restitution de la donnée originale est désignée par « dé-tokenisation » et n' est autorisée qu' au cours de procédés clairement identifiés et limitée à certaines applications , procédés ou utilisateurs .
La tokenisation permet de sécuriser les données sensibles de transactions , réduire l' exposition des données sensibles à des risques de fraudes .
Une fois tokenisées , les données critiques sont réputées désensibilisées et peuvent être mémorisées ou traitées sans risques . En cas de fraude , ces tokens ne peuvent pas être utilisés dans un système qui n' aurait pas accès à la détokenisation ( cas d' un système ouvert interopérant comme un système utilisant des tokens au standard EMVCo ) .
Concernant le domaine des paiements , la génération de tokens de paiement est le processus connu similaire qui consiste aussi à remplacer le numéro de carte bancaire traditionnel par un identifiant numérique unique pour les transactions en ligne , sur mobile et sur appareils connectés .
Il existe un standard EMVCo dans le domaine bancaire , pour définir un système ouvert et interopérant pour la génération (tokenisation) et l'utilisation des « tokens ». EMVco en tant qu' organisme mondial de standardisation supervise les spécifications EMV (Visa, MasterCard et American Express) .
En octobre 2013, Visa, MasterCard et American Express ont proposé une nouvelle norme pour les paiements numériques . EMVCo (l'organisme mondial de standardisation qui supervise les spécifications EMV afin d'assurer l'interopérabilité et l'acceptation) a depuis capitalisé sur ce cadre à l'aide des informations fournies par les membres d' EMVCo et du secteur afin d'améliorer la disponibilité et l'adoption des tokens à travers le monde. EMVCo a étendu son champ d'action pour développer des spécifications de génération des tokens et a publié la version initiale de cette spécification en mars 2014.
Le document US10380596 (Bl) décrit des étapes de réception d'une demande de création d'un jeton cadeau représentatif d'un destinataire du cadeau et des limitations du cadeau d'un premier dispositif informatique. Le procédé comprend également une étape de génération d'un PAN symbolique associé à un compte cadeau et la transmission du PAN symbolique et des limitations de cadeau à un second appareil informatique .
Le procédé comprend la détection d'une demande d' autorisation de transaction représentative d' une tentative de transaction sur un périphérique POS marchand basée sur la surveillance des données d' autorisation de transaction provenant d'une pluralité d'appareils POS marchands.
Problème technique / Objectifs.
L'invention vise à résoudre les inconvénients ou objectifs précités . L'objectif de l'invention est de proposer une digitalisation d'une carte (ou autre instrument de paiement, pouvant être par exemple un token HCE ou un token stocké dans un portefeuille digital (digital wallet en anglais) dans un dispositif communicant) pour un bénéficiaire (ou receveur) de cadeau (par exemple, une personne qui veut faire un cadeau pécunier à son enfant, ou un ami) .
Résumé de l'invention.
L' invention propose un service de carte digitalisée qui permet d'utiliser le compte bancaire de l'initiateur (le donateur ou émetteur ou demandeur) du cadeau pécunier (ou d'un droit de paiement) .
L' invention peut consister, selon un mode préféré de réalisation, à faire générer un instrument de paiement sous forme de tokens (jeton sécurisé ou certificat électronique de données sensibles) , au profit de tiers, en utilisant les données de paiement bancaire d' un titulaire de compte bancaire .
Avantageusement, l'invention peut faire usage d'une infrastructure existante, fonctionnant selon des schémas standardisés de « tokenisation » pour la génération et d'utilisation de « tokens ».
A cet effet, l'invention a pour objet un procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire, ledit procédé comprenant les étapes suivantes: demande ou requête de création d' un instrument de paiement digital auprès d'un serveur bancaire d'un titulaire de compte bancaire ou de carte bancaire, à l'aide d'une première application bancaire d'un dispositif de communication du titulaire, transmission à un dispositif de communication du bénéficiaire comprenant une seconde application bancaire, par ledit serveur bancaire, de données d'enrôlement, lesdites données d' enrôlement comprenant un identifiant de ladite carte bancaire et un certificat d'authentification des données d'enrôlement; enrôlement du bénéficiaire (B) auprès d'un serveur d'enrôlement et /ou serveur de jeton sécurisé, en communicant lesdites données d'enrôlement à l'aide d'un second dispositif de communication, ledit serveur d'enrôlement et/ou serveur de jeton étant configuré pour générer à partir desdites données d'enrôlement, un jeton sécurisé de transaction ou le requérir auprès du serveur de jeton ;
- provisionnement du jeton sécurisé, dans ledit second dispositif de communication du bénéficiaire ;
Le procédé se distingue en ce que le bénéficiaire est un tiers distinct du titulaire de compte avec un second dispositif de communication distinct de celui du titulaire de compte, et en ce que ladite requête de création de l' instrument de paiement comprend une communication d' au moins une adresse de contact dudit bénéficiaire.
Ainsi, l'invention a l'avantage de permettre à toute banque de gérer elle-même la tokenisation de manière autonome. Et, d'un point de vue des spécifications EMVco, cette gestion est totalement transparente .
L' invention a aussi l' avantage de reposer sur un écosystème définit par le standard EMVCo concernant la tokenisation. La gestion du token peut être, de préférence, effectuée par un serveur TSP (=Token Service Provider) dans un cadre régi et maintenu par les spécifications EMVco et non les banques. L' invention peut donc s ' appliquer de-facto à plusieurs banques qui adopteraient le procédé de l ' invention tout en étant conforme à une même spécification EMVco .
Selon d' autres caractéristiques ou étapes du procédé :
- La demande ou requête peut comprendre une information liée au compte bancaire du titulaire ou à une carte bancaire du titulaire ;
- L' information liée au compte bancaire ou carte bancaire du titulaire peut être une information tokenisée ( token ID ou j eton ID) représentant le numéro de carte bancaire ;
- La demande ou requête peut comprendre une information de limitation du montant autorisé pour l' instrument de paiement et/ou une indication de l ' unicité ou pluralité de l' usage de l' instrument de paiement ou et/ou information relatives à des commerçants autorisés ;
- Le procédé peut comprendre une étape d' authentification du titulaire sur l ' application bancaire pour accéder à un service , application ou fonction de création dudit instrument de paiement au profit d' un bénéficiaire ;
- Le procédé peut comprendre une étape de transmission au tiers d' un code d' activation ou d' une invitation à retourner pour obtenir lesdites données d' enrôlement ;
- Ledit code d' activation peut comprendre un OTP à vérifier par le serveur bancaire pour communiquer les données d' enrôlement au tiers , en cas de succès de la vérification ;
- Le certificat d' authentification peut comprendre un OTP pour communiquer les données d' enrôlement au tiers bénéficiaire ;
- L' application bancaire du titulaire et/ou l' application du bénéficiaire peut comprendre ou constituer une application et/ou de portefeuille digital de tiers distinct de la banque et peut comprendre une carte bancaire digitale sous forme de token-ID A ;
- L' application bancaire du bénéficiaire peut comprendre ou constituer une application de portefeuille digital de tiers distinct de la banque et comprend une carte bancaire digitale sous forme de token-ID B .
L' invention a également pour obj et , un système pour la création d' un instrument de paiement au profit d' un tiers bénéficiaire correspondant au procédé ci-dessus . Il peut se distinguer en ce que le token provisionné est associé au compte bancaire du titulaire , et utilisable par ledit bénéficiaire , distinct du titulaire , via ledit second dispositif de communication, distinct du premier dispositif de communication, et en ce que ladite requête de création de l' instrument de paiement comprend une communication d' au moins une adresse de contact dudit bénéficiaire .
Le système peut aussi avoir pour obj et un serveur TR et/ ou TSP correspondant , ayant pour fonction de dé-tokeniser le token reçu, notamment suite ou lors d' une transaction de paiement , afin de retrouver ou associer un identifiant de la carte bancaire (physique et/ ou virtuelle ) et/ou un compte bancaire du titulaire , sur lequel se fera l' opération de débit relatif aux transactions de paiement effectuées par le bénéficiaire .
Cette opération peut s ' effectuer en coopération avec la banque ( serveur de bancaire ) du titulaire .
L' invention a également pour obj et un instrument de paiement créé au profit d' un tiers bénéficiaire , ledit instrument étant mémorisé dans un second dispositif de communication du bénéficiaire et étant associé à un compte bancaire et/ou une carte bancaire physique ou virtuelle d' un titulaire de compte bancaire et/ou titulaire de carte bancaire physique ou virtuelle , digitale distinct du bénéficiaire .
Descriptif des figures : La figure 1 illustre des étapes d'un procédé et un système de création d'un instrument de paiement, conformes à un mode préféré de mise en œuvre ou de réalisation 1' invention ;
- La figure 2 illustre des étapes d'un exemple du procédé de 1' invention .
- La figure 3 illustre des étapes génériques du procédé de 1' invention .
- La figure 4 illustre des étapes d'un procédé et un système de création d'un instrument de paiement, conformes à un mode supplémentaire de mise en œuvre ou de réalisation l' invention dans lequel on utilise des applications et un serveur 54 de fournisseur de portefeuille digital de tiers distinct de celui de la banque.
Description .
D'une manière générale, des références identiques ou similaires d'une figure à l'autre représentent un élément identique ou similaire.
A la figure 1 est illustrée un exemple préféré du système (ou architecture matérielle) 20 de l'invention ainsi que des étapes préférées (1 à 13) d'un procédé conforme à l'invention faisant usage de ce système.
L'invention dans ce mode ou exemple préféré, met en œuvre deux types d' acteurs principaux :
- Une personne T (ou entité physique) appelée indifféremment par la suite, émetteur, demandeur, initiateur ou titulaire de compte bancaire (ce dernier pouvant être de préférence également titulaire d'une carte bancaire physique ou virtuelle) qui souhaite procurer un instrument de paiement sécurisé 25 (ou token B identifié par « token-ID B ») (avec des limites de don ou cadeau prédéfinies) à un tiers bénéficiaire B (quelqu'un ou une entité) personne physique appelée ci-après indifféremment par la suite receveur, bénéficiaire ou tiers bénéficiaire B;
La personne B ou entité appelée receveur (ou tiers bénéficiaire B) est celle qui reçoit l'instrument (ou le moyen) de paiement (25, token B identifié par token-ID B) du demandeur T .
Sur la figure 1, le système 20 de l'invention comprend, du côté demandeur ou titulaire T, une application logicielle bancaire 22 (décrite ci-dessous) ; Cette application peut utiliser de préférence un kit de développement de logiciel (SDK, 23) ici dans l'exemple, pour application logicielle de téléphone mobile 21 (alternativement application logicielle 22 pour autre dispositif communicant intelligent) .
L'application 22 peut être hébergée ou exécutée dans tout premier dispositif intelligent de communication 21 (ordinateur, tablette, objet à porter tel qu'une montre communicante...) du titulaire T, pouvant communiquer via des réseaux de télécommunication divers. En particulier, le premier dispositif 21 peut être configuré pour connecter et échanger, de préférence automatiquement (notamment lors d'une activation de requête 1 par un titulaire T) , avec un serveur bancaire 24 et/ou équivalent (serveur TSP, TR, serveur de fournisseur de portefeuille électronique) décrit ultérieurement .
- L'application logicielle bancaire 22.
Elle peut être, de préférence (mais aussi facultativement) configurée pour proposer les caractéristiques ou fonctions suivantes :
- une fonction d'authentification du demandeur (titulaire T) , avant de transmettre une requête 1 de digitalisation de carte (ou de création d'un instrument de paiement digital 25 , token B ) . Cette authentification du demandeur T ( facultative ) peut être notamment effectuée sur son dispositif communicant 21 , par exemple par code PIN, code secret ou empreinte biométrie pour accéder à une fonction de donation pécuniaire ou financière ( cadeau, transfert de capacité financière à un tiers ) via un instrument financier de paiement telle qu' une carte digitale et/ou token digital ou numérique de transaction .
Cette étape d' authentification peut être considérée comme une authentification ID&V efficace du demandeur auprès de sa banque ( L' authentification ID&V peut être une méthode d' identification et de vérification auprès de la banque du titulaire ou d' un serveur intermédiaire d' un fournisseur de portefeuille digital lié ou distinct ou indépendant de la banque ) et peut être réalisée grâce à une authentification forte basé sur au moins deux facteurs .
L' application 22 peut être procurée par un serveur de la banque du titulaire ou alternativement fournie par un fournisseur de portefeuille électronique ( digital wallet provider en anglais ) . L' application 22 peut être configurée pour communiquer avec un serveur dédié d' interface de l' application 22 , pour la fonction de création d' un instrument de paiement , serveur dédié procuré ou mis à disposition par ce fournisseur de portefeuille électronique ( à la place du serveur de la banque ) . Le serveur dédié ( non représenté sur cette figure 1 ) peut lui-même communiquer ou coopérer avec le serveur de la banque et /ou avec le serveur TSP , 44 .
L' application bancaire 22 peut comprendre également une fonction HCE (Acronyme anglais de Host Card Emulation) de digitalisation / numérisation de carte ( carte de l' initiateur ) dans le dispositif 21 de l' initiateur et/ou 31 du tiers , et la carte émulée peut être utilisée comme instrument de paiement à l ' intérieur d' un cadre ( ou limitation) prédéfini par l' initiateur (tel que Montant maximum autorisé : Max, une limite des commerçants, sites marchands autorisés ou tout autre limitation) .
L'application bancaire 22 peut être configurée pour établir et/ou effectuer une communication avec un serveur requêteur de token TR, 34 (ou de jeton sécurisé) et un serveur ou entité informatique 24 en arrière-plan de la Banque.
L'application bancaire 22 est capable de fournir un moyen 27 ou information à la banque (ou serveur) 24 pour identifier la carte à digitaliser.
Ce moyen 27 peut être tout élément ou toute information tokenisée ou pas, token-ID A, numéro de carte chiffrée ou non, identifiant du titulaire, numéro de compte bancaire chiffrée ou pas, IBAN, Swift code, permettant de lier une requête 1 du demandeur T à un compte bancaire ou à un numéro de carte bancaire PAN. On verra ultérieurement que d'autres informations 26 (adresse de contact) , et le cas échéant des limitations 28, sont transmises pour la création de l'instrument de paiement 25, token B, au profit d'un tiers bénéficiaire B.
- Le second dispositif 31 du tiers bénéficiaire B.
Il est distinct de celui du titulaire. Il peut comprendre tout ou partie des fonctions et/ou applications logicielles et/ou matérielles du premier dispositif 21. L'application bancaire 32 peut être identique ou similaire à l' application 22.
L'application 32 (comme 22) peut être une application d'un fournisseur de portefeuille électronique (contrôlé) , fournie ou pas par la banque du titulaire T ou par un tiers comme Apple pay ™, Google pay ™' X...pay.
Serveur Bancaire 24. Le système 20 comprend également un serveur bancaire 24 ( ou une entité , système ou interface informatique pouvant être en arrière-plan de la Banque ) qui propose les caractéristiques matérielles ou fonctions suivantes :
Une fonction facultative mais préférée d' authentification de l' initiateur ou titulaire T notamment lors de la réception de la requête de création de l' instrument de paiement ou pour permettre l' utilisation de la fonction correspondante d' authentification dans le dispositif du titulaire T ; (pour réaliser l' authentification ID&V)
- Le serveur bancaire 24 peut présenter une interface de programmation d ' application (API ) configurée pour être en mesure de recevoir et/ou traiter des requêtes 1 de l ' initiateur ( ou titulaire T du compte bancaire et/ou de carte digitalisée ) afin de créer l' instrument de paiement 25 , token B ;
Le serveur bancaire peut être configuré pour pouvoir retrouver ( ou associer ) le compte bancaire du titulaire et/ou la carte physique ou digitalisée du titulaire T à partir d' une information 27 , via un token A et/ou son identifiant token ID A ( information sécurisée sous forme de token, insignifiante en dehors du système 20 et équivalente à ou permettant de retrouver une carte digitalisée ) . L' information 27 peut être toute information permettant de débiter ultérieurement le compte bancaire du titulaire T , comme par exemple un numéro de carte bancaire ( PANs ou des tokens ID) .
Ces requêtes 1 peuvent comprennent comme paramètre :
- Facultativement , un montant de paiement maximum autorisé 28 , ( le cas échéant , d' autres limitations qui peuvent comprendre également une limitation quant aux commerçants autorisés ou interdits ) Une adresse de contact 26 (ou information permettant de retrouver une adresse de contact du bénéficiaire dans un serveur coopérant avec la banque, ou un numéro de téléphone, courriel) ; Il peut aussi y avoir une indication d'un canal de communication (WEB, nuage, réseau de téléphonie mobile...) pour contacter le bénéficiaire B,
Une information de compte bancaire ou information de carte de paiement identifiée par un numéro de carte PAN (acronyme de Primacy account number en anglais) de l'initiateur, (cette carte pouvant être virtuelle ou physique) , reliée au compte bancaire du titulaire, ou un identifiant de token (token-ID) relié à une carte de l'initiateur T (cette dernière pouvant être virtuelle ou physique) .
L'entité informatique bancaire 24 peut être de préférence configurée pour générer un OTP (Numéro à usage unique, appelé aussi premier code d'authentification, ou bien code d'activation 15) , et l'associer à une transaction relative à une requête 1 de création d'un instrument de paiement (ou token) 25 provenant de l'initiateur T. Le token 25 peut être aussi illustré sur les figures par son identifiant token-ID, B.
Le code d' activation 15 peut être toute information, code secret, chiffré ou pas permettant de faire un lien entre la réception de l' acceptation par le bénéficiaire et l'instrument de paiement à créer, tel que demandé par le titulaire de compte et de carte bancaire physique ou digitale virtuelle (sans carte physique associée) . Ce code 15 peut être sous formé préféré un OTP.
Ce code 15 peut être créé (étape 4) à la réception de la requête 1 par le serveur de réception de requête 1 (ici serveur 24) et peut être envoyé (étape ou communication 5) au bénéficiaire à l'adresse de contact renseigné, notamment dans le cadre d'une invitation (étape ou communication 5) à accepter ledit instrument ou cadeau financier.
L'entité informatique bancaire (ou serveur) 24 peut être configurée pour générer 28i tous les paramètres requis pour initier une digitalisation de carte (PAN / Date d'expiration, cryptogramme...) . La génération 28i peut comprendre un chiffrement des informations 28 de carte à digitaliser / numériser.
Dans le cas de l'utilisation d'un identifiant token-ID A, (provenant d'un fournisseur de portefeuille digital) , pour identifier la carte digitale ou virtuelle de l'initiateur T, un serveur intermédiaire 54 (fig. 4) du fournisseur de portefeuille digital peut remplacer l'entité informatique bancaire 24.
Dès que le bénéficiaire B utilise l'invitation 5 pour créer un instrument de paiement 25, il peut demander à l'entité informatique bancaire 24 de recevoir les informations de la carte (27, 28) ou 28i.
L'entité informatique bancaire (ou serveur bancaire) 24 ou l'application de service 30 (au sein du serveur 24) , peut authentifier la requête 7 d'acceptation grâce à l'OTP 29 (ou autre code d'activation 15, puis il peut (étape 8 fig.l) composer les informations de la carte, les chiffrer 28i et les transmettre (étape 9, fig. 1) à l'application bancaire 32 du bénéficiaire B dans son dispositif de communication 31.
L'entité informatique bancaire 24 ou l'application de service 30 peut être configurée pour enrôler de nouveaux utilisateurs ou des tiers bénéficiaires B. Pour ces derniers nouveaux utilisateurs ou tiers bénéficiaires B, l'entité informatique bancaire peut proposer un enrôlement plus léger (ou moins contraignant en terme de sécurité) que pour l'initiateur (Titulaire T) ;
L'application de service 30 peut être configurée pour communiquer avec l' application bancaire 32 dans le dispositif du bénéficiaire B;
- Une plateforme de Tokenisation (TSP, 44) .
Le système 20 peut mettre en œuvre, dans l'exemple, également une plateforme (TSP, 44) de génération de Token (Jeton digital, carte digitalisée) .
La plateforme de tokenisation TSP, 44 peut recevoir une requête d'enrôlement 11 pour une nouvelle carte digitale. Cette requête d'enrôlement 11 peut provenir d'un serveur informatique (TR) requêteur de token, pouvant constituer une interface de la plateforme de tokenisation TSP, accessible par le dispositif 31, via une mise en œuvre de l'application 32.
La requête d' enrôlement 10 peut avoir été émise précédemment par l' application mobile 32 du récepteur ou bénéficiaire B en contenant les informations 27, 28, 28i de la carte de l'initiateur (ou titulaire T) . La requête 29 peut comprendre de préférence un token 29 d'authentification.
Le token d'authentification 29 permet de faire le lien entre la banque et les serveurs TR/TSP (34, 44 ou 54) qui peuvent être indépendants de la banque.
Un mécanisme ou système sécurisé par exemple PKI (Public Key infrastructure en anglais) peut être établi entre le serveur de la banque 24 et ces serveurs 34 et/ou 44 et/ou 54. Un secret partagé ou une clé publique / privée peut être mise en place ou entre le serveur 24 et les serveurs 34, 44 et/ou 54. Ce système d'échange sécurisé permet au serveur TR, 34 et/ou serveur 44 ou 54 de vérifier l'authenticité des informations, notamment vérifier le certificat ou token d'authentification 29 associé à la demande d'enrôlement (ou de création d'un registre ou tableau de correspondance dans le serveur 34 et/ou 44 et/ou 54) . Ce certificat peut être émis par la banque comme autorité de confiance ou utilisé par la banque mais provenant d'une autorité autre.
L'émetteur de carte physique (ou virtuelle du titulaire) (Banque et/ou fournisseur de portefeuille digital (digital wallet) , peut, une fois que le token (B, 25) (instrument de paiement) pour le bénéficiaire a été délivré avec des limitations, vérifier que les demandes de paiement initiés avec ce token B, respecte les règles d'usage imposées du token, (B, 25) notamment que le total des paiements n'excède pas le montant limite initial Max de la carte cadeau.
Une alternative peut être une synchronisation entre la banque et le système 20 (hors banque) par exemple le serveur TSP, 44 pour une mise à jour du montant utilisé pour ce token-ID B, 25 délégué carte cadeau. Le serveur TSP peut être capable de vérifier seul ou en coopération avec la banque, les limitations imposées du titulaire T.
- Un requêteur de jeton (carte digitale) TR, 34 associé au serveur TSP, 44.
Dans une variante de mise en œuvre de l'invention ou de réalisation du système 20, ce requêteur TR, 34 peut être compris, constituer ou faire partie du serveur bancaire 24; Ce qui peut simplifier ou réduire le nombre d' intervenants ou d'entités ou infrastructure. Il peut faire partie du ou être associer au serveur TSP. Le serveur (ou requêteur de token) TR, 34 peut traiter ou transférer, (ici dans l'exemple, au serveur TSP, 44) , la requête d'enrôlement 11 de la nouvelle carte, reçue (via la communication 10) de l'application mobile 32 et contenant l'information de carte 27, 28 de l'initiateur T ainsi qu'un jeton d'authentification 29, créé initialement par le serveur bancaire 24, attestant de l'authenticité de la requête de digitalisation et/ou enrôlement associé 10, 11.
La requête d'enrôlement (ou de création d'un compte ou d'un registre dans une table numérique de correspondance auprès des serveurs TR et /ou TSP (ou serveur 54) pour le bénéficiaire) 10 peut comprendre les informations 27, 28 indiquées de la carte, en plus de toute information habituellement requise connu de l'homme de l'art, pour provisionner correctement un token dans un dispositif de communication, telles que par exemple des capacités techniques ou caractéristiques du dispositif.
Une fois l'enrôlement effectué, la requête ou instruction 11 de création de token B peut être envoyée au serveur de tokenisation TSP, 44.
La plateforme de tokenisation TSP ou la banque émettrice peut être chargées l'une ou l'autre ou bien les deux ensemble en coopération, de vérifier les règles d'usage définies avec la référence 28. Elle peut par être par exemple consolider les montants utilisés par la carte digitale B, 25 (identifiée par Token-ID B) , reçue par le destinataire et donc vérifier que les limites ne soient pas atteintes lors d' une autorisation de paiement sollicitée avec l'identifiant « token-ID B » du token B.
Un exemple concret de mise en œuvre des étapes de l'invention et d'utilisation du système est présenté ci- après . Un initiateur (père T) veut donner (ou transférer des capacités de paiement) à son enfant (récepteur bénéficiaire B) pour lui permettre de les utiliser notamment dans des transactions de paiement. Il veut notamment donner un moyen de paiement avec des limitations. Il peut grâce à 1' invention donner un accès contrôlé à son propre moyen de paiement (carte) .
Sans vraiment déplacer des fonds, de l'argent, les exemples permettent pour le moins de donner un droit d' utiliser au moins une partie (voire la totalité) des fonds du compte bancaire du titulaire 1, tout en contrôlant ce droit, grâce à un moyen de paiement token B, 25 (avec comme identifiant « token-ID B ».
Grâce à l'invention, le titulaire T a la possibilité d'utiliser sa carte bancaire (physique ou virtuelle) avec le numéro d'identification bancaire (PAN) , 27 et avec quelques restrictions 28 sur le montant global disponible (un montant maximal autorisé établi) conformément aux étapes 100 à 150 suivantes :
A l'étape 100, l'initiateur T s'authentifie sur l'application bancaire 22 de son téléphone mobile 21, (notamment via une authentification forte, se basant sur quelque chose qu'il possède, quelque chose qu'il connaît comme un code secret, mot de passe et/ou quelque chose qu'il le caractérise comme son empreinte biométrique) ; puis,
A l'étape 110, il prépare une requête, avec son application logicielle bancaire 22, qui est transmise au serveur de sa banque 24 avec une instruction (requête 1) pour envoyer à son enfant B, une carte cadeau digitale 25, 28i liée directement à sa carte bancaire ou numéro de carte PAN, 27 (puis lié à son compte bancaire) . Il envoie la requête 1 au serveur bancaire 24 avec un moyen de contact 26 pour contacter son enfant (ex. courriel, numéro de téléphone, adresse de contact quelconque...) ;
- A l'étape 120, le serveur bancaire 24 reçoit la requête 1, débute avec l'application de service 30, la création de la carte cadeau (token 25, information de carte 28i) et échange avec l'application bancaire 32 de l'enfant (bénéficiaire B) en lui transmettant une invitation 5, 7, 9;
- A l'étape 130, l'enfant B reçoit et traite 6 l'invitation 5 à recevoir un instrument de paiement de la banque 24 et débute à l'aide de son mobile 31, une demande (étapes 7) de digitalisation de la carte du père PAN, 27 avec des restrictions associées 28.
La banque (serveur bancaire) 24, via l'application de service 30, procure au bénéficiaire B toutes les informations cartes 28i (de préférence avec un token d'authentification 29) requises pour valider et créer un jeton 25 permettant de digitaliser la carte associée (27bis non illustrée associée à un identifiant de compte bancaire et/ou de carte bancaire 27) ;
A l'étape 140, l'application logicielle bancaire du dispositif 31 de l'enfant 32 échange avec le requêteur de jeton TR, 34 afin de créer le jeton grâce à toutes les informations de la carte et données d' authentification reçues du serveur bancaire ;
- A l'étape 150, l'application logicielle bancaire 32 de l'enfant (bénéficiaire B) reçoit 13 le jeton 25 (Token B avec son identifiant "token-ID B". Ce qui lui permet de pouvoir utiliser la carte digitale pour payer conformément aux restrictions 28 contenues dans le jeton 25 (Montant maximum autorisé 28) .
Lorsque l'enfant veut réaliser un paiement, il peut utiliser le jeton 25 comme un token de paiement classique, il lance l'application de la banque 22, choisit son moyen de paiement, il peut présenter ses données biométriques pour débloquer l'accès au jeton 25 pour un paiement. Cela peut créer une génération d'un cryptogramme qui sera utilisé pour le paiement .
La banque émettrice de la carte et la plateforme TSP peuvent se synchroniser pour vérifier que le montant maximum autorisé 28 ne soit pas dépassé par le cumul des paiements faits avec le token 25 par l'enfant.
L' invention présente les avantages ci-après :
- Pour le cas d'usage carte cadeau, le titulaire est certain qu'aucun argent ne sera perdu si elle n'est pas utilisée. Le compte du titulaire n'est pas débité sans utilisation;
L' invention assure la capacité d' envoyer un moyen de paiement à quiconque possède un téléphone portable, ou autre dispositif communicant partout et instantanément.
L' invention permet un nouveau procédé impliquant un titulaire, un receveur et deux dispositifs communicants avec une délégation de capacité de paiement sécurisée et étant approuvée par toutes les parties impliquées (Titulaire, bénéficiaire, ...) en incluant des règles d'utilisation.
Un second exemple générique de mise en œuvre des étapes minimales de l'invention et d'utilisation du système 20 peut être le suivant (étapes 200- 240) :
A l'étape 200, le procédé comporte l'émission d'une requête de création d'un instrument de paiement digital 25 pour tiers bénéficiaire B (distinct d'un titulaire de compte bancaire T) , avec au moins des informations 28i comprenant au moins un identifiant de carte bancaire physique ou virtuelle (PAN, token-ID) ou toute information liée à ce compte et une adresse de contact du tiers ;
L'émission de la requête (ou instruction) peut s'effectuer à l'aide ou via le dispositif 21 communicant du titulaire comprenant une application logicielle dédiée 22 et pouvant échanger avec un serveur bancaire 24 de la banque du titulaire T accessible en ligne (ou alternativement un serveur interface de l'application, de préférence contrôlé par la banque et/ou un fournisseur de l'application 22 et/ou 32 ou fournisseur de portefeuilles digitaux) ;
A l'étape 210, le procédé comprend une transmission (identique à l'étape ou communication 9, fig. 1) au dispositif 21 du tiers bénéficiaire, d'informations 28i (PAN, ou Token-ID, limites d'utilisation...) et un certificat d'authentification 29 du serveur bancaire 24 associé à ces informations ou à cette transmission 9;
- A l'étape 220, selon le procédé de cet exemple générique (ou simplifié) , un enrôlement de l'instrument de paiement 25 du tiers bénéficiaire est effectué auprès d'un serveur configuré à cet effet (TR, 34 ; TR/TSP, 44, voire compris dans la banque 24) à partir desdites informations 28i et ledit certificat d'authentification 29 ;
- A l'étape 230, le procédé effectue un provisionnement du jeton sécurisé 25 associé à l'instrument de paiement, dans le dispositif 31 de communication du tiers bénéficiaire B;
- A l'étape 240, le bénéficiaire B peut réaliser un paiement à l'aide du token 25 digital de transaction (et/ou instrument de paiement) dans les limites Max prédéfinies par le titulaire T (cette limite pouvant être cumulative ou à usage unique suivant les critères définies) .
Ainsi, les phases d'authentification sur le dispositif du titulaire, la phase d'invitation 5, les phases 6 de réception et 7 d'acceptation peuvent être facultatives.
Le transfert 5 de l' invitation est toutefois préférable et peut être fait sous une autre forme ... (QR Code, ...)
De même, si le serveur bancaire 24 peut offrir lui-même un service des serveurs TR et/ou TSP : les étapes 10-13 peuvent être effectuées entre le dispositif 31 du bénéficiaire B et le serveur bancaire 24.
Des différences ou avantages ci-dessous de l'invention par rapport à l'art antérieur notamment US10380596 (Bl) en introduction, peuvent être précisées ci-après .
L' invention propose une solution moins orientée banque au sens où la solution proposée n' est pas spécifique à la banque. Grâce à l'invention, la banque peut gérer elle-même la tokenisation de manière autonome. Et, d'un point de vue des spécifications EMVco, c'est totalement transparent. Elle peut recevoir les requêtes 1 de création d' instrument de paiement, les contrôler en les traitant et faire finaliser la création de token B avec des serveurs TSP et/ou TR. L'utilisation des tokens et détokenisation et interactions éventuelles requises avec la banque peut s'effectuer également avec les serveurs TSP et/ou TR moins sous le contrôle complet de la banque .
L' invention repose sur un écosystème définit par EMVCo concernant la tokenization. La gestion du token peut être, de préférence, effectuée par un serveur TSP (Token Service Provider en anglais) dans un cadre régi et maintenu par les spécifications EMVco et non les banques .
Donc, l'invention peut s'appliquer de-facto à plusieurs banques qui adopteraient la solution de l' invention tout en étant conforme à une même spécification EMVco.
Facultativement en variante (non illustrée) , l'invention peut présenter l' avantage d' informer le titulaire de carte en temps réel lors de la tokenization de la carte. A cet effet, l'invention peut prévoir une solution avec les étapes ci-dessous :
- Le titulaire fait une demande de création de carte cadeau tokenisée 25 pour un bénéficiaire B en précisant les informations de contact du bénéficiaire (mail ou numéro de téléphone ) ;
Le destinataire / bénéficiaire B accepte la « carte cadeau »
- La solution démarre la tokenisation sur le dispositif du bénéficiaire, (Token 25 créé et provisionné sur le dispositif du bénéficiaire mais non activé (utilisation pour paiement pas possible) ;
En parallèle (étape C non illustrée) , le procédé (ou solution) peut informer le titulaire T (directement entre dispositifs ou via le serveur de la banque) que le bénéficiaire B a accepté l' offre de carte cadeau ; Le procédé peut prévoir une demande de confirmation donnée par le titulaire (pouvant inclure un mécanisme d'authentification ID&V) pour finaliser la demande de création de carte cadeau) ; Une fois la demande de création confirmée, le token 25 du bénéficiaire peut être activé dans le système 20.
Les étapes d'authentification ID&V peuvent être exécutées par la banque avant l'étape 1 par une authentification forte ou notamment à l'étape 8 pour ID et la confirmation.
L'authentification ID&V permet notamment à la banque de vérifier que l' émetteur T de la requête 1 est bien le propriétaire T du compte ou de la carte bancaire et qu' il bien est habilité à effectuer la requête 1 de création de l'instrument de paiement.
Cette dernière étape C, a l'avantage de rajouter de la sécurité, le titulaire peut vérifier qu'on s'adresse au bon bénéficiaire .
L'étape C peut comprendre alternativement ou cumulativement, un échange entre le bénéficiaire et l'émetteur à travers un canal dédié (SMS, email, compte de réseau sociaux, MSN, WhatsApp...) , pour permettre à l' émetteur T de vérifier que le bénéficiaire est la bonne personne. A la figure 4 est illustré un mode de réalisation d' un système 20A dans lequel l' application bancaire 22 et/ou 32 comprend ou constitue une application de portefeuille digital de tiers distinct de la banque ( tel que Apple pay ™ ou Samsung pay ™ . L' application 22 ( ou 32 ) comprend une carte bancaire digitale sous forme de token-ID ;
Le serveur de la banque 24 , peut être remplacé par un serveur d' un fournisseur de portefeuille digital distinct de celui de la banque . Il peut être contrôlé par une entité tierce distincte de la banque .
Ce modèle proposé peut comprendre au moins deux parties principales selon un schéma serveur TR/TSP / banque émettrice de la carte bancaire ( TR/TSP pouvant comprendre ou constituer ou non, une seule et même entité ou serveur informatique . Ce schéma peut être adapté pour comprendre un troisième acteur constitué par un fournisseur de portefeuille digital ( tel Apple-pay ™ ou Samsung-pay ™) .
Ce système 20A fonctionne comme ci-après .
Le titulaire T comprend dans on dispositif 21 une application 22t de fournisseur d' application digitale ou de portefeuille digital de tiers avec un numéro de carte bancaire tokenisé ( token A identifié par son identifiant : token-ID A) .
Le procédé comprend l ' étape 1 de demande de création d' instrument de paiement qui est identique ou similaire à celle de la figure 1 . Ici l' identifiant de compte ou carte bancaire du titulaire T est un token ID - A ( token qui a été créé au préalable par le Titulaire T sur son dispositif 21 et qui est identifié par l ' identifiant « token-ID A » ) représentant le numéro de carte bancaire d' une carte bancaire physique ou virtuelle sous forme de token . Cependant cette requête ou demande 1 de création d' un instrument de paiement digital parvient à un serveur 54 interface d'un fournisseur de portefeuille digital d'une entité tierce (distincte ou indépendante de la banque 24) . Le serveur s' interface entre le serveur de la banque et l'application 22t ou le dispositif du titulaire
- Puis à l'étape la, la requête 1 est transmise (la) au serveur TR et/ou TSP identique ou similaire à celui de la figure 1. Le serveur d'entité tierce 54 doit aiguiller la demande 1 vers le bon serveur TSP associé au serveur 54 (indication dans la requête 1) . Le serveur 54 peut stocker des informations sur les limitations de paiement, assurer des consolidations de paiement (cumul de paiement) et des vérifications d'autres limitations telles que (liste de marchands autorisés) .
Enfin, ce le serveur 34, 44 (TR et/ou TSP) transmet à son tour la requête 1 au serveur 24 de la banque.
- A l'étape 2, le serveur de banque mémorise la requête 1.
A L'étape 3a puis 3b, le serveur de banque 24 peut retourner un accusé réception approbatif (OK) ou exige une authentification ID&V du titulaire. Ce message est transmis 3b à l'application 22t via le serveur TR et/ou TSP.
- A l'étape 3C et 8, le titulaire peut confirmer sa demande initiale 1 et effectuer une authentification ID&V optionnel de préférence directement avec le serveur de banque.
- Les étapes 4-7, 8a sont identiques ou similaires à celles 4-7, 8a de la figure 1. Toutefois, les étapes 5, 7 ou 9 peuvent être exécutées au nom de la banque par le serveur 54 de l'entité tierce fournisseur de portefeuille digital.
- L'étape de demande d'enrôlement 10 peut s'effectuer à l'inverse de la figure 1 via le serveur 54 de l'entité tierce qui le transmet 10a au serveur auprès du serveur TR et /ou TSP 34 , 44 ;
- L' étape de provisionnement 13 du token B, identifié par son identifiant « token-ID B » dans le dispositif du bénéficiaire B peut s ' effectuer via la communication 13a depuis le serveur 54 de l ' entité tierce .
Ainsi , dans cet exemple , l' application bancaire 22 du titulaire et/ou l' application 32 du bénéficiaire peut comprendre ou constituer une application 22t et/ou 32t de portefeuille digital de tiers distinct de la banque et l' application 22t peut comprendre une carte bancaire digitale sous forme de token identifié par son identifiant « token-ID A » ou simplement « ID A » .
De même , l ' application bancaire 32 du bénéficiaire B peut comprendre ou constituer une application 32t de portefeuille digital de tiers distinct de la banque et comprendre une carte bancaire digitale , sous forme de token identifié par son identifiant token-ID B provisionné en étape 13a .
Ainsi le système comprend dans le dispositif du bénéficiaire un token identifié par son identifiant token-ID ( B ) ou « ID B », associé au compte bancaire ou carte bancaire physique ou virtuelle du titulaire T .
De même , un serveur TSP ou serveur de fournisseur de portefeuille digital et/ou de carte digitale peut comprendre une table de correspondance électronique ou équivalant , associant des tokens-ID B d' un ensemble de bénéficiaires à un ensemble de titulaires T .
Lors d' opération de dé-tokenisation de ces tokens dans des serveurs 44 , ces tokens issus ou utilisés via des dispositifs de bénéficiaires , par exemple sur des terminaux de paiement POS , sont traités dans ces serveurs dédiés , en relation avec des titulaires de compte bancaire ou de carte physique ou virtuelle (chaque carte physique ou virtuelle étant reliée ou associée à une carte digitale) , distincts des bénéficiaires utilisateurs pour des transactions de paiement. Ces bénéficiaires peuvent d'ailleurs ne pas avoir de compte bancaire courant.
Ainsi, l'invention permet d'obtenir dans chaque exemple ou mode décrit précédemment, un instrument de paiement 25, Token, token identifié par son identifiant « ID B » ou « token-ID B », créé au profit d'un tiers bénéficiaire (B) . Cet instrument (25, token B) est mémorisé dans un second dispositif de de communication 31 du bénéficiaire B et étant associé à un compte bancaire et/ou une carte bancaire physique ou virtuelle d' un titulaire de compte bancaire et/ou titulaire de carte bancaire physique ou virtuelle, digitale distinct du bénéficiaire.
En utilisation, au cours d' un paiement par exemple sans contact sur un terminal POS ou simplement en sélectionnant dans l'application 32, l'instrument de paiement 25, token B, le dispositif 31 du bénéficiaire comprend ou peut afficher une carte bancaire sur l' écran du dispositif (par exemple un téléphone mobile) , une représentation graphique de carte bancaire de la banque du titulaire. La représentation affichée peut comprendre le nom du titulaire. Cette dernière peut le cas échéant être précédé d' une mention « par délégation (ou équivalent) du « nom » du titulaire) . La représentation graphique peut également comprendre des indications totale ou partielle du numéro PAN et/ou de la date limite de la carte; Au verso peut se trouver un nombre (cryptogramme) . Cette carte bancaire est associée à un compte bancaire du titulaire. Cette carte bancaire représentée n' est en aucun cas une carte bancaire appartenant au bénéficiaire ou utilisateur du dispositif, qui peut ne pas en avoir du tout. Le cas échéant, l'application peut afficher des limitations, ou un cumul des paiements ou un solde du cadeau pécunier.
L'application peut permettre un affichage des paramètres d'utilisation de la carte cadeau comme par exemple, les commerçants autorisés, une période de validité, une zone géographique d'utilisation.
Ainsi, le bénéficiaire est informé très facilement des attributs associés à la carte cadeau et peut facilement consulter et savoir où il en est dans le solde ou crédit de paiement .
Ces limitations peuvent avoir été provisionnées en même temps que le token B. Un fichier électronique comprenant des attributs de la carte, et/ou limitations peut avoir été ajouté au token B au cours de sa création (12) et dans la communication 13, puis à réception dans le dispositif ces attributs et/ou limitations peuvent être extraits ou interprétés par l'application 32 pour les rendre accessibles ou lisibles par le bénéficiaire sur son dispositif.
En cas de détection par le dispositif d'un POS de marchand non autorisé, une alerte et avertissement peut être émise directement par l'application ou par un des serveurs 34, 44, 54.
Le second dispositif 31 peut posséder un identifiant (par exemple IMEI et/ou un numéro de téléphone distinct de celui du titulaire) . L'adresse de contact du bénéficiaire (courriel, numéro de téléphone...) mémorisé dans le système 20, 20A est distincte de celle du titulaire du compte à débiter ou de carte bancaire utilisée.
Le provisionnement du token B par un serveur de provisionnement 44 peut être effectué notamment via tout canal de communication notamment le réseau de téléphonie mobile via OTA, par le réseau internet, ou autre réseau.
Les données de contact du bénéficiaire (ou du dispositif 31) pour le provisionnement ont pu être transmises par le dispositif 31, notamment par l'application 32 automatiquement, au moins en partie au cours de l'étape d'enrôlement 10 de chaque exemple décrit précédemment.

Claims

REVENDICATIONS
1. Procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire, ledit procédé comprenant les étapes suivantes : demande (1) de création d'un instrument de paiement digital (25) auprès d'un serveur bancaire (24) d'un titulaire (T) de compte bancaire (PAN, 27) ou de carte bancaire, à l'aide d'une première application bancaire (22) d'un dispositif de communication (21) du titulaire (T) ,
- transmission (5) à un dispositif de communication (31) du bénéficiaire (B) comprenant une seconde application bancaire (32) , par ledit serveur bancaire (24) , de données (28) d'enrôlement, lesdites données d'enrôlement comprenant un identifiant de ladite carte bancaire (PAN, 27) et un certificat d'authentification (29) des données d'enrôlement; enrôlement du bénéficiaire (B) auprès d'un serveur d'enrôlement et/ou serveur de jeton (TR, TR/TSP, 34) en communicant lesdites données d'enrôlement à l'aide d'un second dispositif de communication (31) , ledit serveur d'enrôlement et/ou serveur de jeton (TR, TR/TSP) étant configuré pour générer à partir desdites données d'enrôlement, un jeton sécurisé de transaction (25) ou le requérir auprès d'un serveur (TR, 44) de jeton sécurisé ;
- provisionnement du jeton sécurisé (25) , dans ledit second dispositif de communication du bénéficiaire, caractérisé en ce que le bénéficiaire (B) est un tiers distinct du titulaire (T) de compte avec un second dispositif de communication (31) distinct de celui (21) du titulaire de compte, et en ce que ladite requête (1) de création de l'instrument de paiement (25) comprend une communication d'au moins une adresse (26) de contact dudit bénéficiaire (B) .
2. Procédé selon la revendication précédente, caractérisé en ce que la demande (1) comprend une information (PAN) liée au compte bancaire du titulaire ou à une carte bancaire du titulaire physique ou virtuelle ou un token identifié par token ID A.
3. Procédé selon la revendication précédente, caractérisé en ce que l' information liée au compte bancaire ou carte bancaire du titulaire est une information tokenisée (token- ID A) représentant le numéro de carte bancaire PAN.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la demande (1) comprend une information de limitation du montant autorisé pour l'instrument de paiement et/ou indication de l'unicité ou pluralité de l'usage de l'instrument de paiement ou et/ou information de commerçants autorisés.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce qu' il comprend une étape d'authentification du titulaire sur l'application bancaire (22) pour accéder à un service, application ou fonction de création dudit instrument de paiement (25) au profit d'un bénéficiaire B.
6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu' il comprend une étape de transmission (5) au tiers d'un code d'activation (15) ou d'une invitation (14) à retourner pour obtenir lesdites données d'enrôlement (28) .
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit code d'activation (15) comprend un OTP à vérifier par le serveur bancaire pour communiquer les données d'enrôlement (28) au tiers, en cas de succès de la vérification.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit certificat d'authentification (29) comprend un OTP pour communiquer les données d'enrôlement au tiers bénéficiaire.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce l'application bancaire 22 du titulaire et/ou l'application (32) du bénéficiaire comprend ou constitue une application 22t et/ou 32t de portefeuille digital de tiers distinct de la banque et comprend une carte bancaire digitale sous forme de token identifié par token- ID A, ledit token-ID (A) étant associé au compte bancaire du titulaire T .
10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce l'application bancaire (32) du bénéficiaire comprend ou constitue une application (32t) de portefeuille digital de tiers distinct de la banque et comprend une carte bancaire digitale sous forme de token (B identifié par token-ID (B) , ledit token-ID (B) étant associé au compte bancaire ou carte digitale du titulaire T.
11. Système pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire, ledit système étant configuré pour: demander (1) une création d'un instrument de paiement digital (25) auprès d'un serveur bancaire (24) d'un titulaire (T) de compte bancaire (PAN, 27) ou de carte bancaire, à l'aide d'une première application bancaire (22) d'un dispositif de communication (21) du titulaire (T) , - transmettre (5) à un dispositif de communication (31) du bénéficiaire (B) comprenant une seconde application bancaire (32) , par ledit serveur bancaire (24) , de données (28) d'enrôlement, lesdites données d'enrôlement comprenant un identifiant de ladite carte bancaire (PAN, 27) et un certificat d'authentification (29) des données d'enrôlement; enrôler ledit bénéficiaire (B) auprès d'un serveur d'enrôlement et/ou serveur de jeton (TR, TR/TSP, 34) en communicant lesdites données d'enrôlement à l'aide d'un second dispositif de communication (31) , ledit serveur d'enrôlement et/ou serveur de jeton (TR, TR/TSP) étant configuré (s) pour générer à partir desdites données d'enrôlement, un jeton sécurisé de transaction (25) ou le requérir auprès d'un serveur (TR, 44) de jeton sécurisé ; - provisionner du jeton sécurisé (25) , dans ledit second dispositif de communication du bénéficiaire, caractérisé en ce que ledit token (25) est associé au compte bancaire du titulaire (T) , et utilisable par ledit bénéficiaire, distinct du titulaire (T) , via ledit second dispositif de communication (31) , distinct du premier dispositif de communication (21) , et en ce que ladite requête (1) de création de l'instrument de paiement (25) comprend une communication d'au moins une adresse (26) de contact dudit bénéficiaire (B) .
12. Instrument de paiement créé au profit d'un tiers bénéficiaire (B) , ledit instrument (25, token B) étant mémorisé dans un second dispositif de communication (31) du bénéficiaire (B) et étant associé à un compte bancaire et/ou une carte bancaire physique (PAN) ou virtuelle d'un titulaire (T) de compte bancaire et/ou titulaire (T) de carte bancaire physique ou virtuelle, digitale distinct du bénéficiaire (B) .
PCT/EP2021/086728 2020-12-21 2021-12-20 Procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire Ceased WO2022136236A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP20306639.4 2020-12-21
EP20306639.4A EP4016427A1 (fr) 2020-12-21 2020-12-21 Procede pour la creation d'un instrument de paiement au profit d'un tiers beneficiaire

Publications (1)

Publication Number Publication Date
WO2022136236A1 true WO2022136236A1 (fr) 2022-06-30

Family

ID=74844644

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/086728 Ceased WO2022136236A1 (fr) 2020-12-21 2021-12-20 Procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire

Country Status (2)

Country Link
EP (1) EP4016427A1 (fr)
WO (1) WO2022136236A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230419300A1 (en) * 2022-06-28 2023-12-28 Entrust Corporation Integrated digital and physical card issuance processes

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110218868A1 (en) * 2010-03-08 2011-09-08 Firethorn Holdings, Llc System and method for determining appropriate redemption presentations for a virtual token associated with a stored value account
US20150032625A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating risk using token assurance data
US10380596B1 (en) 2018-06-21 2019-08-13 Capital One Services, Llc Systems for providing and processing pre-authorized customizable gift tokens
US20190356489A1 (en) * 2018-05-18 2019-11-21 Visa International Service Association Method and system for access token processing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110218868A1 (en) * 2010-03-08 2011-09-08 Firethorn Holdings, Llc System and method for determining appropriate redemption presentations for a virtual token associated with a stored value account
US20150032625A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating risk using token assurance data
US20190356489A1 (en) * 2018-05-18 2019-11-21 Visa International Service Association Method and system for access token processing
US10380596B1 (en) 2018-06-21 2019-08-13 Capital One Services, Llc Systems for providing and processing pre-authorized customizable gift tokens
US20190392444A1 (en) * 2018-06-21 2019-12-26 Capital One Services, Llc Systems For Providing and Processing Pre-Authorized Customizable Gift Tokens

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230419300A1 (en) * 2022-06-28 2023-12-28 Entrust Corporation Integrated digital and physical card issuance processes

Also Published As

Publication number Publication date
EP4016427A1 (fr) 2022-06-22

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP2873045B1 (fr) Entite electronique securisee pour l'autorisation d'une transaction
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
EP3163487A1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
JP2020537247A (ja) ピアツーピア移転を実行するシステム及び方法
WO2022136236A1 (fr) Procédé pour la création d'un instrument de paiement au profit d'un tiers bénéficiaire
CA3144301C (fr) Transactions de paiement securisees
US20240370846A1 (en) Secure payment transactions
CA3161325A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
FR2932296A1 (fr) Procedes et dispositif pour entites electroniques pour l'echange et l'utilisation de droits
FR3023640A1 (fr) Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants.
CA2946145C (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
US11397940B2 (en) Secure payment transactions
WO2022254002A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant.
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
FR3008516A1 (fr) Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.
FR2963975A1 (fr) Systeme de paiement en ligne
FR2994006A1 (fr) Procede et dispositif pour conduire une transaction aupres d'un distributeur automatique

Legal Events

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

Ref document number: 21843622

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21843622

Country of ref document: EP

Kind code of ref document: A1