WO2017011887A1

WO2017011887A1 - Token generation method upon joining a payment service, payment terminal and method for joining a payment service

Info

Publication number: WO2017011887A1
Application number: PCT/BR2016/050138
Authority: WO
Inventors: Plinio CARDOSO DA COSTA PATRÃO; Solange SOARIS PERALLES
Original assignee: Cielo S.A.
Priority date: 2015-07-17
Filing date: 2016-06-17
Publication date: 2017-01-26
Also published as: AR105345A1; BR102015017170A2

Abstract

The present invention relates to a method for joining a payment service which comprises the following steps: a user (1) makes a payment using a payment card at a payment terminal (2) connected to an acquirer (3) by a secure network; the payment terminal (2) issues to the user (1) a proposal to join the extended payment service; the user (1) transmits a user identifier to the payment terminal (2); and the payment terminal (2) transmits to the acquirer (3) the user identifier and sensitive data of the payment card of the user (1) over the secure network. The present invention further relates to a token generation method upon joining a payment service, comprising the above-mentioned steps of the method for joining a payment service, as well as the following steps: the acquirer (3) transmits said sensitive data of the payment card to a token service provider (6); the user (1) issues a token request via a communication terminal (7); the token service provider (6) generates a token and stores in a mapping table of a token vault an exchange of communications between the generated token and the sensitive data of the payment card; and the token is transmitted to the communication terminal (7).

Description

Invention Patent Report for "Token Generation Process for Payment Service Membership, Payment Termination, and Payment Service Membership Process".

[001] The present invention relates to methods utilizing devices to increase the security level of payment methods involving the use of a token. A token is an electronic key that replaces sensitive information such as a payment card number to protect that information.

[002] An example of a whiteboard involving the use of tokens is the process in which a user's payment card number is replaced with a token to protect it. The card number is called a Prirnary Account Number (PAN). ) as part of payment card financial transactions and can be used for direct payment of purchases, for example at payment terminals. The PAN is replaced by a token which is a distinct and restricted string and therefore can be sent over a channel with security less than one payment terminus. If a malicious person intercepts the token, they will not be aware of the PAN that is protected in this way.

[003] With the token, the malicious person cannot discover the PAN because the correspondence between the PAN and the token is stored on a secure server. When the user communicates his token to a merchant, the merchant in turn communicates the token to an accredited payment network that has access to said secure server and consequently has access to the PAN from the token, thus allowing the transaction to be authorized.

[004] Such payment processes involving the use of tokens are, for example, documented by the well-known means of payment company EMVCo in its tokenization standard. EMVCo is also responsible for the El standard ("Europay Mastercard and Visa"), which is the international security standard for smart payment cards, ie chip. Description of the prior art

[005] Implementation of a payment process involving the use of a token requires the user to subscribe to an appropriate service and the issuance of the token, which will be linked to a payment card number on a secure server.

Such implementations exist in the state of the art. For example, there are processes in which a user joins a token service on an Internet site or an application on their mobile phone. The user then takes a digital photo of their payment card and signs that photo on that site or in the app. In other processes, the user manually enters their payment card number on the site or application. The site or application then communicates the payment card PAN thus obtained to a token system.

There are other solutions where a reading of the user's magnetic card or payment card chip is performed on a cashier's reader in a store. This reading allows you to communicate the payment card PAN to a token system.

[008] The common point of these state-of-the-art processes is that PAN travels on unsafe networks and where it can be intercepted before a token is issued.

Brief Description of the Invention

The object of the present invention is to improve known processes and devices.

[0010] The objectives of the invention are achieved by a payment service membership token generation process which includes the steps of: a user completing a payment with a payment card at a payment terminal connected to an acquirer through a secure network; payment term issues to the user a proposal to join the amplified payment service; the user communicates to the payment terminal at least one user identifier; the payment terminal communicates to the acquirer the user identifier and user payment card sensitive data through the network safe; the acquirer communicates said sensitive payment card data to a token service provider; The user issues a token request through an end! of communication; the token service provider generates a token and stores in a token vault mapping table a correspondence between the generated token and said sensitive payment card data; and the token is communicated to said communication terminal.

[001 1] Note that the user's sensitive payment card data comprises at least one of the PAN, the payment card's expiration date, the cardholder's name and the payment card security code. of user.

Another object of the invention is a payment terminal including a payment card reader and a screen, which is capable of implementing a token generation process for joining a payment service comprising the above steps. The payment terminal further comprises: a material security module providing hardware encryption; a membership module for an amplified payment service capable of displaying on the screen a proposal for membership of said service.

[0013] The invention ensures the security of the original card data, including PAN, from the beginning of the process until the issuance of the token. The situation in which the user has just made a payment at a secure payment terminal is taken advantage of to issue a proposal to join the amplified payment service. The fact that the user has made an authorized payment with the payment term means that the user inserted his or her card at the end! payment, entered your password, and the responsible issuer recognized your details and validated your password.

At this point in the process, the user who has just used the payment terminal is authenticated by the most secure verification that can be found in regular stores, ie a payment terminal according to payment industry standards. The payment terminal is wired or wirelessly connected to the acquirer through a secure network. With the duly authenticated user, the proposed membership of the amplified payment service benefits from the best security available without the need for additional security measures.

According to a preferred feature, it ends! The payment method complies with the PCI DSS (Payment Card Industry Standards Data Security Standards) standard administered by the Payment Card Industry Security Standards Councii organization, which is the standard required to ensure the safe operation of a payment term and your resistance to fraud.

[0017] According to another favorite feature, the ends! The payment method is capable of making payments according to the EMV (Europay Mastercard and Visa) standard. The EMV standard is nowadays the most widely used standard in the world for payment card transactions such as debit or credit cards equipped with chip. The EMV standard is managed by the EMVCo organization and defines the interaction at the physical, electrical and logical levels of data and application management between chip cards and card readers for financial transactions.

[0018] Generally speaking, the token requirement performed by the user can then be done at any ends! even at an insecure communication terminal, such as an Internet-connected personal computer, a smartphone-type mobile phone, or a tabiet where an application has been downloaded and installed.

In the present invention, process security is maximized due to the fact that during the token request, the user's PAN, or any sensitive information, is not processed by the termination of communication. In fact, throughout the process, the user's PAN number, as well as any other sensitive information, does not travel on insecure networks or devices.

According to a preferred feature, the payment terminal includes a hardware encryption processor. This implies that the payment term includes a physical encryption unit equipped with a unique processor for encryption functions, allowing you to achieve an optimal level of security.

Preferred features which may complement the process according to the invention are set forth below. The process may include one of these characteristics or a set of these combined characteristics.

The process of generating token for payment service membership may further comprise the following steps: the user presents the token to a merchant to effect payment of an amount; the merchant communicates the token to the acquirer; the acquirer communicates the token to the token service provider; the token service provider de-tokenizes and communicates to the acquirer said sensitive payment card data; and the acquirer makes said payment of an amount.

Alternatively, the token generation process for joining a payment service may further comprise the following steps: the user presents the token to a merchant for payment of an amount; the merchant communicates the token to the token service provider; the token service provider de-tokenizes and communicates to the acquirer said sensitive payment card data; and the acquirer makes said payment of an amount.

It should be noted that the merchant may be an online store or a physical store.

In addition, during the step in which the token is communicated to said payment terminal, the token service provider may communicate the token to the acquirer and the acquirer in turn communicates the token to said terminator. of communication.

[0026] In an alternative embodiment, the user identifier includes the user's telephone number.

The process of generating a payment service token may further comprise the additional step of the payment service user get instructions on your phone to download an application that enables this phone to act as that communication terminal,

Additionally, the process may include the additional step of the user receiving on their telephone a communication request from their email address.

It is further noted that in the process of generating a payment service token, after the step in which the payment terminal communicates to the acquirer the user identifier and the user's sensitive payment card data, the Payment terminal can communicate to the user an authentication. In addition, during the step in which the user issues a token request through a communication terminal, the user can authenticate with said authentication.

It is noteworthy that, in the process of generating a payment service token, during the step in which the user issues a token request through a communication terminal, the token request may be issued with of the acquirer.

Alternatively, the token may be stored at the communication terminal as an NFC identifier, as a barcode, or in the form of a string.

In the process of generating a payment service token during the step in which the user finalizes a payment with a payment card at a payment terminal, payment can be made according to the EMV standard or According to PC standard! s s.

[0033] In the process of generating a payment service token, the acquirer may also be the token service provider.

In addition, during the step in which the payment terminal issues to the user a proposal for membership of the amplified payment service, the payment terminal may display the written proposal in one web and proposes to the user to select an option of acceptance or a refusal option. [0035] The process of generating a payment service token may further comprise the additional step of the user selecting the acceptance option, this selection of the acceptance option being communicated to the acquirer,

In said process, the communication terminal may be a mobile communication device and the user may issue a token request through said application capable of communicating with the acquirer and installed on a mobile communication device.

The token may be restricted for exclusive use with said mobile communication device. In addition, the communication terminal may be a computer and the user may issue a token request by connecting to a buyer's internet site.

It is noteworthy that during the step in which the user issues a token request through a communication terminal, the user can also inform the type of application to be used, where the type of application informed by the user can be used as a parameter to set security limitations for the token.

Alternatively, the token service provider may generate a token based on at least one security limitation.

Said security limitation may, for example, restrict the use of the token for a particular merchant. In this sense, it should be noted that the limitation may restrict the use of the token for a particular amount or for a limited time or even linked to the communication terminal used to make its request. In addition, this limitation may condition the use of the token to enter a password.

Brief Description of the Figures

The invention is explained below by a description of a preferred embodiment, exemplified by the figures, in which:

Figure 1 schematically illustrates a token generation process for adhering to an amplified payment service according to the invention;

Figure 2 schematically illustrates an additional token payment transaction in accordance with the invention. Detailed Description of the Figures

[0042] Figure 1 represents a user 1 involved in a token generation process by joining an amplified payment service.

Firstly, user 1 makes a payment with a payment terminal 2. For example, the user can make purchases at any store and, at the cashier, opt for payment with a payment card which can be, for example , a debit or credit card.

The store accepting such payment cards must be equipped with payment terminals in accordance with payment industry standards to ensure the security of transactions. That is, payment terminal 2 must be protected against tampering and must integrate hardware-protected cryptographic means (HSM) providing strong encryption functions. For example, preferred payment term 2 is:

- as per PCI DSS standard; and

- Able to make payments according to EIV1V standard.

Payment terminal 2 can be a payment terminal available at merchant stores and can be either fixed or mobile.

[0046] The payment terminal is connected, via a wired or wireless network, to an acquirer 3 who is also referred to as a "payment authorizer" consisting of servers of a company responsible for the transmission and settlement of credit card transactions. payment. The role of this type of company, present in the market, is to receive payment requests issued by payment terminals 2 and to communicate with financial institutions and payment card brands via a payment network 4 to transmit the payment data in order to obtain authorization from the payment card issuing bank 5 transaction. This authorization allows the debit of user bank account 1 and payment to the merchant.

As usual, going to the cashier with your purchases, user 1 enters his payment card at payment terminal 2 and enters his password to make payment for purchases. [0048] The payment transaction involves the acquirer 3, the payment network 4, and the issuing bank 5. After this payment transaction is completed, user 1 and his payment card have been duly authenticated,

[0049] Payment term 2 then issues to user 1 a proposal to join an amplified payment service. The proposal is displayed on the payment terminal screen 2 and indicates that the user will thus be able to benefit from services such as a token service.

In the event that the user declines the proposal, the process ends at this stage and is therefore again a classic card payment transaction.

In the event that the user accepts the proposal on payment term 2 via the keypad or touch screen, payment terminal 2 prompts user 1 to communicate a user identifier. The user identifier is a string that uniquely identifies user 1. The user identifier preferably includes at least one number linked to user 1, such as an individual registration number generated by the public administration of the country concerned, a telephone number, or email from user 1, among others.

In the present embodiment, payment term 2 asks user 1 to enter an individual registration number and also their mobile phone number.

[0053] Payment term 2 will then complete the user registration by informing the acquirer 3 of the user identifier. In this example, the individual registration number and mobile number, along with the newly used payment card PAN, as well as the expiration date, cardholder name, and security code.

[0054] Please note that card sensitive data such as PAN, expiration date, cardholder name and security code are communicated to the acquirer 3 via a payment terminal 2 whose security maximum, as stated above, and your secure connection 3. The network structure that is usually used to make secure payments is used here to communicate sensitive card data with a high level of security.

Purchaser 3 will register User 1 as an affiliate to the Amplified Payment Service on their own servers. Acquirer 3 will also register user 1 with a token service provider 6 by communicating to him the user identifier and the user's sensitive card data.

Token service provider 6 may be in-house, belonging to acquirer 3, which then has dedicated servers for that function, or it may be a third-party service to a properly certified industry company that already provides Token In the event that Token Service Provider 6 is outsourced, communication between Token Service Provider 3 and Purchaser 3 is carried out over a secure network, meeting the financial transaction security standards. In this way, the security chain where the sensitive data from user card 1 travels remains intact and protected.

[1] User 1 thus terminates, upon payment, his / her membership of the amplified payment service and can exit the store with his or her purchases.

Token Service Provider 6 has user master record 1 which will allow the generation of a token for that user when required.

[0059] Later, user 1 may wish to use the enhanced payment service. For this, and in particular in order to obtain a token, the user may use a communication terminal 7. Various types of communication terminals may be used. Figure 1 illustrates two examples of such communication terminals 7: a mobile communication device 8 such as a smartphone-type mobile phone or a tablet, and a fixed computer 9 connected to the Internet. Any type of device can be used as a communication terminal 7. The preferred communication terminal type 7 in this embodiment is a smartphone or tablet mobile communication device 8 in which an application from the acquirer 3 has been installed. In this case, it is advantageous that after user registration 1 With payment terminal 2, the latter sends, on the phone that user 1 has registered, a message giving instructions to download an application from the acquirer 3 and / or provide additional information to your registration with the amplified payment service.

[0061] User 1 will identify himself on communication terminal 7, that is, on that application that user 1 downloaded, or on a website to which he has connected to the fixed computer 9. User 1 can identify himself at communication terminal 7 with the user identifier previously communicated to payment terminal 2. Alternatively, payment terminal 2 can communicate an authentication to user 1 during his registration described above, so that user 1 can identify himself secure at the end of communication 7 with this authentication.

In any case, once user 1 has been identified at payment end 7, it is possible to apply for the token. The user requests the token at communication terminal 7 and the latter communicates a token request to the acquirer 3 in sequence. User 1 then issues a token request through communication terminal 7.

[0063] Acquirer 3 then communicates the token request to token service provider 6. In an alternative, communication terminal 7 may communicate the token request directly to token service provider 6.

In any case, token service provider 6, receiving the token request, will generate a token and store in a token vault mapping table (called "token vauif) a match between the generated token and sensitive data on the user's card. The token can thus serve as a substitute for the sensitive data on the user's card. User 1, matching this token with this sensitive card data safely stored in the token vault.

The token is then communicated to the communication terminal 7, that is to the user 1. The token service provider 6 can communicate the generated token directly to the communication terminal 7.

Alternatively, token service provider 6 can communicate the token to acquirer 3, which in turn communicates the token to communication terminal 7. In this case, acquirer 3 can monitor user-generated tokens 1 for enhance security or offer additional token management services to the user 1.

The token is communicated to communication terminal 2 and stored or displayed in any form suitable for a token. For example, the token may be presented as a manually typed string, or a barcode, which would preferably be a two-dimensional barcode, to be displayed on a screen or to be printed.

If communication terminal 7 is a mobile communication device 8 such as a smartphone or tablet, the token may be stored for use in Near Field Communication (NFC) applications for use with compatible devices. .

[0069] User 1 thus has the token he requested. Note that during issuance of the token request, the system sets the security limitation that will be used for the required token. The system can optionally use as security parameter the type of application that will be used by the user, such as Internet, voice or data. The security limitation may include one or more of the following conditions:

- restrict token use for a particular merchant;

- restrict token usage to particular amount;

- restrict token usage for a limited time;

- restrict token usage to the device on which it is stored; or

- condition the use of the token to enter a password. [0070] These optional conditions provide an extra level of safety in token use by conditioning that use within limits set by the acquirer, the user, or the system.

In the case that the communication terminal is a mobile communication device 8, another example of security limitation is the restriction of token storage on a single mobile communication device 8 (e.g., the user's smartphone), preventing token storage on any other device.

Regardless of how to store the token, user 1 is thus able to make an amount payment with the token without disclosing the sensitive card data of the user, which is the main function of the token.

The complementary payment process with the token will now be described in relation to figure 2.

[0074] Figure 2 shows user 1 who has just received a token, and his communication terminal 7.

As soon as user 1 wants to make use of the token, for example when making purchases (goods or services) at a merchant 10 which may be in a physical store or an online store. At the moment of paying the amount corresponding to the purchases, user 1 will notify merchant 10 of his token.

Token communication to the merchant can be done in various ways, depending on the storage mode of the token by user 1 and the merchant's equipment 10, such as, for example:

the token stored as an NFC identifier in mobile communication device 8 is approximated to a merchant compatible device 10;

the barcode stored token, preferably two-dimensional, is displayed on the mobile communication device 8 and is scanned by the merchant 10;

the bar code stored token, preferably two-dimensional, is printed on a sheet of paper from the stationary computer 9 and is scanned by the merchant 10; - the token made available in the form of a string is typed on a trader's cash front keyboard 10;

- the merchant being an online store, the token in the form of a string is typed on the keyboard of the computer from which purchases are being made.

- The merchant being a virtual store for communication devices such as Smartphones and tablets can make use of the token stored on the device for making payments.

Trader 10 proceeds to continue with the token as a means of payment. Trader 10 communicates the token to the acquirer 3.

Acquirer 3, receiving the token, endeavors to perform the tokenization before proceeding with payment on the payment network. Alternatively, acquirer 3 can communicate the token directly to the payment network where de-tokenization can also be performed.

De-tokenization is an operation which consists in retrieving the original card data from the token that was generated to replace said original card data.

If buyer 3 is de-tokenizing, buyer 3 will communicate the token to the token service provider 8 which will refer to the token vault mapping table. If acquirer 3 is also token service provider 8, he himself will directly refer to the token vault mapping table.

[0081] The mapping table lookup allows identification of the user's sensitive card data corresponding to the token that user 1 communicated.

Once acquirer 3 has recovered the sensitive data from the user's card, he can proceed in the usual way with the payment transaction by communicating the sensitive data from the user's card to the payment network 4 in order to obtain authorization. of the issuing bank 5. [0083] Acquirer 3 then communicates the payment authorization to merchant 10, conceding the payment process,

Throughout the token generation process and the entire token payment process, the user's sensitive card data did not travel over insecure networks or devices. All unprotected communications were made with the token, which replaces the sensitive information on the user's card.

Having described a preferred embodiment example, it should be understood that the scope of the present invention encompasses other possible variations, being limited only by the content of the appended claims, including the possible equivalents thereof.

Claims

1 . Token generation process for joining a payment service, characterized by the fact that it included the following steps:

a user (1) finalizes a payment with a payment card at a payment terminal (2) connected to an acquirer (3) via a secure network;

the payment terminal (2) issues to the user (1) a proposal to join the amplified payment service;

the user (1) communicates to the payment terminal (2) at least one user identifier;

the payment terminal (2) communicates to the acquirer (3) the user identifier and sensitive user payment card data (1) over the secure network;

the acquirer (3) communicates said sensitive payment card data from the user (1) to a token service provider (6);

the user (1) issues a token request through a communication terminal (7);

the token service provider (6) generates a token and stores in a token vault mapping table a correspondence between the generated token and said sensitive user payment card data (1); and

the token is communicated to said communication termination (7).

Process according to claim 1, characterized in that said sensitive payment card details of the user (1) comprise at least one of the PAN, the expiration date of the payment card, the name of the cardholder card and the user's payment card security code (1).

Process according to claim 1 or 2, characterized by an additional token payment transaction comprising the following steps:

the user (1) presents the token to a merchant (10) to pay a fee; the merchant (10) communicates the token to the acquirer (3);

the acquirer (3) communicates the token to the token service provider (6); the token service provider (6) de-tokenizes and communicates to the acquirer (3) said sensitive user payment card data (1); and

the acquirer (3) makes said payment of an amount.

Process according to claim 1, characterized by an additional token payment transaction comprising the following steps: the user (1) presents the token to a merchant (10) to effect payment of an amount;

the merchant (10) communicates the token to the token service provider (6);

the token service provider (8) de-tokenizes and communicates to the acquirer (3) said sensitive user payment card data (1); and

the acquirer (3) makes said payment of an amount.

Process according to Claim 3 or 4, characterized in that the merchant (10) is an online store.

Process according to any one of claims 3 to 4, characterized in that the merchant (10) is a physical store.

Method according to any one of claims 1 to 8, characterized in that during the step in which the token is communicated to said communication terminal (7), the token service provider (6) communicates the Token to the acquirer (3) and the acquirer (3) in turn communicates the token to said communication terminal (7).

Method according to any one of Claims 1 to 7, characterized in that the user identifier includes the user's telephone number (1).

Process according to claim 8, characterized in that it includes the additional step of the user (1) receiving on his phone instructions to download an application capable of enabling that phone to act as said communication terminal (7) .

Process according to claim 8 or 9, characterized in that it includes the additional step of the user (1) receiving on his telephone a communication request from his e-mail address.

1 1. Process according to any one of claims 1 to 10, characterized in that:

after the step in which the payment terminator (2) communicates to the acquirer (3) the user identifier and user payment card sensitive data (1), the payment terminator (2) communicates to the user (1) a authentication; and

during the step in which user (1) issues a token request through a communication terminal (7), user (1) authenticates with said authentication.

Process according to any one of claims 1 to 11, characterized in that during the step in which the user (1) issues a token request via a communication terminal (7), the user ( 1) issues the token request to said acquirer (3).

Method according to any one of claims 1 to 12, characterized in that the token is stored at the communication terminal (7) as an NFC identifier.

Method according to any one of claims 1 to 12, characterized in that the token is stored in the communication terminal (7) as a barcode.

Method according to any one of claims 1 to 12, characterized in that the token is stored in the communication terminal (7) in the form of a string.

Process according to any one of claims 1 to 15, characterized in that during the step in which the user (1) finalizes a payment with a payment card at a payment terminal (2), the payment is performed according to the EMV standard.

Process according to claim 4, characterized in that the supplementary token payment transaction is carried out in accordance with the EMV standard.

Process according to any one of claims 1 to 17, characterized in that during the step in which the user (1) finalizes a payment with a payment card at a payment terminal (2), the payment is performed in accordance with the PCI DSS standard.

Method according to any one of claims 1 to 18, characterized in that the acquirer (3) is also the token service provider (6).

Process according to any one of claims 1 to 19, characterized in that during the step in which the payment terminal

(2) issues to the user (1) a proposal for joining the amplified payment service, the payment terminal (2) displays said written proposal on a screen and proposes to the user (1) to select an acceptance option or an decline option.

21 Process according to claim 20, characterized in that it includes the additional step of the user (1) selecting the acceptance option, this selection of the acceptance option being communicated to the acquirer.

(3).

Method according to any one of claims 11 to 21, characterized in that said communication terminal (7) is a mobile communication device (8) and the user issues a token request via said application. able to communicate with the purchaser (3) and installed on that mobile communication device (8).

Method according to claim 22, characterized in that the token is restricted for exclusive use with said mobile communication device (8).

Method according to any one of claims 1 to 21, characterized in that said communication terminal (7) is a computer (9) and the user (1) issues a token request connecting to an internet site. of the acquirer (3).

Process according to any one of Claims 1 to 22, characterized in that during the step in which the user (1) issues a Token request through a communication terminal (7), user (1) also informs the type of application that will be used.

Process according to Claim 25, characterized in that the type of user-informed application (1) can be used as a parameter to define security limitations for the token.

Method according to any one of claims 1 to 22, characterized in that the token service provider (6) generates a token based on at least one security limitation.

Process according to claim 26 or 27, characterized in that said limitation restricts the use of the token for a particular trader.

A method according to claim 26 or 27, wherein said limitation restricts the use of the token to a particular amount.

Process according to claim 26 or 27, characterized in that said limitation restricts the use of the token for a limited time.

31 Process according to claim 26 or 27, characterized in that said limitation conditions the use of the token to enter a password.

Payment terminal (2) including a payment card reader and a web, characterized in that it is capable of implementing the process as defined in any one of claims 1 to 31, and further comprising: a module security material providing hardware encryption; a membership module for an amplified payment service capable of displaying on the screen a proposal for membership of said service.

Payment terminal (2) according to claim 32, characterized in that it further includes a token reading device.

34. Process for joining a payment service, characterized by the fact that it includes the steps of:

a user (1) finalizes a payment with a payment card at a payment terminal (2) connected to an acquirer (3) through a secure network; the payment terminal (2) issues to the user (1) a proposal to join the amplified payment service;

the user (1) communicates to the payment terminal (2) at least one user identifier; and

the payment terminal (2) communicates to the acquirer (3) the user identifier and the PAN of the user payment card (1) through the secure network.