FR3115625A1 - Card not present transactions with a card verification value chosen by the cardholder - Google Patents

Abstract

A cardholder inputs (305), into a merchant system (20), payment information and a freely chosen transaction CVV. A payment system (30) receives (400) a request from the merchant, including the CVV and transaction information, and sends (405) an authorization request to a cardholder device (13). The transaction information is displayed (310) on the device and prompts the cardholder to enter the CVV as confirmation. The holder enters (315) a confirmation CVV. The system approves (240, 415) the transaction when the CVVs are identical. The CVV can be short-lived and changed with each transaction, increasing transaction security. Server PCI certification constraints are also reduced. Finally, the holder has more control over the validation of the transaction. Figure for abstract: Fig.2

Description

Card not present transactions with a CVV chosen by the cardholder

This application concerns card-not-present transactions.

Financial transactions based on payment cards, such as credit and debit cards, present certain security problems. In order to perform a card transaction using, for example, a credit card, a user's cardholder must provide a primary account number (PAN) and a card verification value, called Card Verification Value ("Card Verification Value", CVV or CV2), Card Verification Code ("Card Verification Code", CVC) or Card Security Code ("Card Security Code", CSC). As described herein, the terms CVV, CVC, and CSC may be used interchangeably.

A Card Verification Value (CVV) is usually printed on the front or back of the payment card, usually in human-readable characters. This can be a three-digit or four-digit value.

The CVV is used to verify that the customer has the card in their possession when making the transaction. This is therefore strictly confidential information. For example, when the transaction is a "card not present" transaction, i.e. when the payment card cannot be swiped or its chip cannot be read, as in the case of an online or telephone transaction, the printed CVV code can be keyed in or provided orally to confirm that the customer making the transaction is in possession of the payment card , or, at least, that he knows the card verification code.

Today, additional security mechanisms have been developed to secure the transaction. In particular, the cardholder's bank that receives a transaction request from a merchant system (or merchant's bank) may ask the cardholder to confirm the transaction. This can be done using a cardholder device that has a cardholder bank application. In response to a confirmation from the cardholder, the cardholder's bank then authorizes the transaction to the merchant system. However, these mechanisms have drawbacks, such as making the transaction process more complex by implementing a redirection from the merchant website to the banking service to confirm the transaction.

Card-not-present transactions have certain security vulnerabilities. As the PAN and/or CVV are provided in human-readable character form, and are either typed or entered into a printed or faxed purchase order, or provided orally, they generally cannot be cryptographically protected, by example, coded. This makes it easy for malicious parties to retrieve card information and reuse it for fraudulent transactions.

Dynamic CVV was developed to overcome some of these flaws. A new CVV is dynamically generated at a determined time recurrence, based on an issuer master key. This solution however is not fully satisfactory as it requires PCI certification of the server or servers due to the use of a master key.

New techniques to reduce fraudulent transactions in existing payment infrastructures would be welcome. New techniques to give the cardholder more control over the CVV would also be welcome. New techniques to reduce PCI certification constraints would also be welcome. More generally, the security of transactions without the presence of the card is sought.

To overcome some of the aforementioned concerns, the inventor envisions allowing the cardholder to freely set their CVV, through a confirmation mechanism that an attacker does not have access to and which ensures that the cardholder is always in possession elements of accreditation (“credentials” in Anglo-Saxon language) of the payment card (which is equivalent to being in possession of the payment card itself).

Thus, the CVV can have a short lifespan and be changed with each transaction, which increases transaction security. Similarly, PCI certification constraints on the server are reduced since no issuer master key is required for CVV. Finally, the cardholder has more control over the validation of the transaction.

In this context, the invention first provides a method for carrying out a transaction without the presence of the card, the method comprising, at the level of a payment system:

receiving a first card verification value, CVV, with transaction information from a merchant system,

receiving, from a cardholder device, a transaction authorization response that is based on a second CVV. The cardholder's device is a personal device of the cardholder, therefore distinct from the merchant system, which is associated with the payment card used for the transaction. In particular, a smartphone with a banking application or an electronic wallet can be used, and

approval or rejection of the transaction based on the first and second CVV. Approving the transaction is synonymous with authorizing, allowing or validating the transaction.

Correlatively, at the cardholder, a method for carrying out a transaction without the presence of the card comprises:

the entry of a first CVV into a merchant system connected to a payment system, to initiate a transaction,

entering a transaction confirmation by the user on a cardholder device connected to the payment system, the transaction confirmation by the user being based on a second CVV, and

the receipt, through the merchant system, of an approval or rejection of the transaction based on the first and second CVVs.

Therefore, when completing a transaction, a customer enters a freely selectable first CVV with card-based payment or transaction information (e.g. tokenized PAN, expiration date, …). The payment system may request a transaction authorization from the card issuer, which is transmitted to a cardholder device. The transaction information can then be displayed to the cardholder, prompting them to validate or not the transaction. The cardholder may enter an expected (second) CVV based on the first CVV, e.g., the same CVV, to authorize the transaction, or confirm a displayed CVV, or select a CVV from displayed CVVs. The payment system that receives such a response to the transaction authorization request can determine, based on the entered CVV and the confirmation CVV, whether to allow or deny the transaction.

The present invention also provides a payment system processing a card-not-present transaction, the payment system comprising:

a transaction receiving server configured to receive a first card verification value, CVV, with transaction information from a merchant system,

an authorization server configured to receive, from a cardholder device, a transaction authorization response that is based on a second CVV, and to approve or deny the transaction based on the first and second CVV.

Correspondingly, a cardholder system comprises a device for accessing a merchant system and a cardholder device connected to a payment system. The access device can be a simple web browser allowing access to a merchant website.

The access device is configured for a cardholder to enter a first CVV into the merchant system to initiate a transaction.

The cardholder device is configured for the cardholder to enter a user transaction confirmation, wherein the user transaction confirmation is based on a second CVV.

And the access device receives, through the merchant system, an approval or denial of the transaction based on the first and second CVVs.

Optional features of embodiments of the invention are defined in the appended claims. Some of these characteristics are explained below with reference to a process, while they can be transposed into device characteristics.

In some embodiments, the first CVV is entered by the cardholder into the merchant system and the second CVV is entered by the cardholder at the cardholder's device or is selected by the cardholder from a list of CVV displayed on the cardholder's device or is confirmed by the cardholder when displayed on the cardholder's device. Preferably, the first CVV is freely selected by the cardholder, it being understood that the second CVV must be a confirmation of the first. The selection can be made from a predefined range of values, typically [0, 10 ⁿ -1], where n is the number of digits in the CVV.

In other embodiments, receipt of the transaction authorization response is in response to sending a transaction authorization request to the cardholder device. Therefore, the transaction confirmation by entering/selection/confirmation of the second CVV can take place in the classic transaction authorization process, in which the cardholder's device is further solicited via the transaction authorization request. . The transaction authorization request preferably includes the transaction information (to be displayed to the customer) to allow the cardholder to validate the transaction with sufficient knowledge of it.

In specific embodiments, the sending of the transaction authorization request is in response to receiving a transaction request from the merchant system, the transaction request including the first CVV and the transaction information.

In some embodiments, the transaction is approved when the second CVV equals an expected value based on the first CVV. In particular, the first and second CVV can be the same, which means that the expected value is the first CVV. Indeed, as the cardholder can freely choose the CVV for the transaction, the validation of the latter is done preferably when the confirmation CVV (the second), entered during the transaction authorization process, is the same. than the original CVV. Alternatively, the expected value may be a reference value, the result of a secret operation (known to the cardholder and the payment system) on the first known CVV. For example, the reference value can be the result of adding the first CVV and a personal and/or secret value (for example the year of birth).

In certain embodiments, the transaction authorization response is received with a first digital signature thereof, calculated on the basis of a card payment token (for example, credential elements dedicated to the digital signature ) stored on the cardholder's device. A card payment token typically results from the tokenization of a payment card that secures the payment information (PAN and expiration date) in the cardholder's device. Signing the response increases the security of the authorization process.

In specific embodiments, approving or denying the transaction includes calculating a second digital signature based on the first CVV and a locally generated card payment token (using the same tokenization process ) for the cardholder, and comparing the first and second digital signatures.

In some embodiments, the transaction is declined if the first CVV is the same as a CVV used in one of the last transactions (usually in one of the last N previous transactions for the cardholder, where N is an integer).

From the cardholder's perspective, in some embodiments, entering the transaction confirmation by the user includes entering the second CVV on the cardholder's device or selecting the second CVV from a list of CVVs displayed on the cardholder's device or confirmation of a CVV displayed on the cardholder's device (e.g. the first CVV is displayed for confirmation, or various CVVs comprising the first CVV or an equivalent reference CVV are displayed in succession, pending user confirmation when the correct CVV is displayed) as the second CVV.

In some embodiments, entry of the transaction confirmation by the user is in response to a transaction authorization request by the payment system which displays the transaction information on the cardholder's device.

In other embodiments, the second CVV is equal to a reference value based on the first CVV, for example the first and second CVV are identical, to receive an approval of the transaction. Again, the first CVV can be freely selected by the cardholder.

In embodiments, the method further includes the cardholder's device sending a transaction authorization response, including the user's transaction confirmation (i.e. based on the second CVV), to the payment system. The transaction authorization response may be accompanied by a digital signature thereof calculated on the basis of a card payment token stored on the cardholder's device.

In some embodiments, the method further includes pre-displaying (i.e., before the first CVV is entered by the customer) card payment token information on a screen of the device of the cardholder, in which the first CVV is entered into the merchant system with the displayed card payment token information (i.e. in the same payment form or succession of forms for the same transaction). Such information usually includes a tokenized PAN and an expiration date. The first CVV and this information are therefore entered together, i.e. in the same payment form for the transaction or in the same succession of forms for the same transaction.

Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system, causes the system to perform any process as defined above.

At least part of the methods according to the invention can be implemented by computer. Accordingly, the present invention may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcodes, etc.), or an embodiment combining software and hardware aspects all of which may be collectively referred to herein as "circuit", "module" or "system". Additionally, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embedded in the medium.

Since the present invention may be implemented in software, the present invention may be embodied in computer readable code for delivery to a programmable device on any suitable medium. A tangible medium may include a storage medium such as a hard disk drive, magnetic tape device, or solid-state memory device and the like. A transient medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, for example a microwave or RF (radio frequency) signal.

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

There illustrates a transaction system in which the embodiments of the present invention can be implemented,

There illustrates exemplary message exchanges for implementing embodiments of the present invention,

There illustrates, using a flowchart, exemplary steps for implementing the present invention on a cardholder's side, and

There illustrates, using a flowchart, exemplary steps for implementing the present invention on the side of a payment system.

detailed description

The invention applies to financial transactions and more particularly to transactions without the presence of the card, such as the purchase of one or more products on a website. The card used for payment is not swiped or its chip is not read. The customer must enter payment card information, such as a PAN, an expiration date, and a card verification value called CVV or CVC or CSC. Below, CVV is referred to as any type of card verification value. An authorization process is then carried out in the payment system or the infrastructure underlying the merchant system, to verify the transaction, the payment information and the cardholder's account balance, for example. An authorization (or denial) is then issued to validate the purchase, the purchase amount being transferred from the cardholder's bank account to the merchant's bank account in the payment system.

Although reference is made below to online (Internet) transactions, other card-not-present transactions may be considered within the scope of the present invention, provided that a CVV is entered in addition to the payment card information (e.g. PAN and expiration date). These include in particular mail order sales transactions by email or fax, or telephone transactions.

There illustrates a system 1 making it possible to implement a transaction without the presence of the card according to embodiments of the invention.

System 1 includes a cardholder environment or system 10, a merchant environment, infrastructure or system 20 and a payment environment, infrastructure or system 30.

The cardholder system 10 includes a cardholder payment card 11, an access device 12 for accessing the merchant system 20 and a cardholder personal device 13.

Payment card 11 can be of any type, with or without magnetic stripe, with or without secure chip. It can be provided in the form of a physical medium or in electronic form. The payment card 11 usually includes a cardholder's name, a PAN and an expiration date, all of which are, for example, printed or embossed on the physical card. Some payment cards additionally have a CVV attached, for example they have a CVV printed on the front or back. The CVV can be a three-digit code (especially for Visa and Mastercard – registered trademarks) or can be a four-digit code (especially for American Express – registered trademark). Of course, any number of digits can be contemplated within the scope of the present invention. Some payment cards do not have a CVV printed on them.

The payment card 11 may be subject to tokenization in the cardholder's personal device 13. This means that some or all of the card information (usually a PAN) is converted into a digital code or codes (usually a tokenized PAN) also called a "token". The token, referenced 133 in the figure, can be used, as an alternative to real card information, for a transaction payment: the tokenized PAN then replaces the real PAN, thus securing the payment card. To perform the tokenization, the cardholder can register their personal device 13 with their bank (reference 32 discussed below), thereby allowing that bank to exchange messages directly with the cardholder. Of course, in a variant, the cardholder can simply connect to the bank using the banking application 132 (for example using login and password access).

The access device 12 can be any system accessing the merchant system 20: a web browser, a telephone, a fax, a mail, etc. Preferably, it comprises a computer equipped with a web browser allowing access to a commercial website. The computer can be the personal device of the cardholder 13 (for example a smart phone equipped with a web browser) or can be a separate computer.

The cardholder's personal device 13 is preferably a portable device, such as a mobile or smart phone, tablet, laptop computer, personal organizer, etc. It comprises I/O (input/output) interfaces 130 (for example keyboard and screen), applications such as a web browser 131 if the device functions as an access device 12 and a banking application, for example a software application wallet or "electronic wallet" or "e-wallet" 132, to implement the mechanisms of the present invention. The e-wallet 132 stores the card payment token 133.

The merchant 20 system is essentially one or more classic merchant 21 servers that host a merchant website with payment and transaction functionality for the purchase of products. Any communication network, for example a mobile network or the Internet, can be used to connect the access device 12 to the server or servers of the merchant system 20.

The merchant servers 21, and more specifically the one or those that manage the transaction functionalities, are connected to the payment system 30 by any type of communication network, generally the Internet. Merchant servers can be implemented by the merchant itself and/or by third parties providing the merchant with sales and payment functionality.

A transaction is conventionally initiated in the merchant system 20 when a customer purchases products on the merchant website.

To initiate the transaction, the customer enters his payment card information on a payment form, thereby triggering a transaction authorization process between the merchant servers 21 and the payment system 30. According to the embodiments of the invention, the customer (normally the cardholder) provides, enters or types, in addition to the card information, a CVV. The CVV is advantageously freely selected by the customer/cardholder, any value between 0 and 999 for a 3-digit CVV or between 0 and 9999 for a 4-digit CVV. The free selection can be implemented even if the payment card 11 has a CVV printed on it. This allows the cardholder to have better control over securing the CVV-based transaction. It also allows the cardholder to continue using their payment card even if the CVV has been hacked (in which case the printed CVV may have been deactivated with the cardholder's bank so that the present invention is put into effect). implemented each time the card is used).

It is only when an authorization response approving the transaction is received from the payment system 30, that the merchant servers 21 can inform the customer that his purchase is validated, which means that the transaction is approved.

The payment system 30 manages the transaction authorization process, and therefore performs the necessary message exchanges between the merchant's bank (or "acquiring bank" or transaction receiving server) 31 and the cardholder's bank (or "issuing bank") 32. The payment system 30 usually relies on a greater number of equipment (eg payment gateways, servers, …). For ease of illustration, only Merchant Bank and Cardholder Bank are shown as separate servers.

The banking servers are able to exchange messages in order to proceed with the authorization process of an underlying transaction, with the merchant's bank 31 ultimately providing the merchant system 20 with approval or denial of the transaction. underlying. In this process, the cardholder's bank 32 usually verifies the transaction information and verifies whether the cardholder (identified on the basis of the PAN) is authorized to carry out the transaction (for example with regard to the amount of the transaction and bank account balance).

According to embodiments of the invention, the cardholder's bank 32, during a transaction process, sends a transaction authorization request to the cardholder's device 13 to request the cardholder to confirm the transaction and provide or confirm the CVV entered when initiating the transaction. Confirmation of the transaction may simply result from the cardholder correctly typing the initial CVV on the cardholder device or entering a CVV that must match a reference CVV, based on the initial CVV.

This ensures that the customer has access to the cardholder's device, i.e. that he is in possession of credentials representing the payment card used.

Cardholder's bank 32 may have control of banking application 132 such that transaction details may be displayed to the cardholder for transaction confirmation.

Figures 2-4 illustrate methods of processing a card-not-present transaction according to embodiments of the invention.

There illustrates exchanges of messages between the entities shown on the to complete a transaction. Figures 3 and 4 illustrate general steps of the method for carrying out the transaction, respectively in the customer/cardholder environment 10 and in the payment infrastructure 30, according to embodiments of the invention. The general steps of the process at the merchant system level are standard steps. Therefore, they are not shown for ease of illustration.

First (step 200), the cardholder's payment card 11 is subjected to tokenization in the banking application (e-wallet) 132 of the cardholder's personal device 13. This step is optional since the cardholder card, as a customer, has the choice of using either the card information printed or embossed on the card 11 or the tokenized information provided by the banking application 132 when performing a transaction with a merchant.

The tokenization provides a payment token consisting of a tokenized PAN with the expiry date in the e-wallet 132. Optionally, a set of credential elements can be generated as additional data to the payment token. Accreditation items may include one or more (payment) keys, preferably dedicated to respective specific uses. The credential items can be single-use credential items, time-limited credential items, in which case the personal device 13 can request new credential items if necessary. Credentials can also be unlimited (in terms of usage and time) and diversified locally on the fly to provide specific credentials for specific uses.

In step 205, consisting of steps 206 through 209, the cardholder initiates a transaction with the merchant:

At step 206, the cardholder can for example access a merchant website using the web browser 12, add a few products to a basket and access a payment form displaying a total amount to be paid.

At step 207, the cardholder retrieves their payment card information to enter into the payment form. Without tokenization of the payment card 11, the cardholder reads the PAN embossed on their card 11, as well as the expiration date of the card. In the event of tokenization of the card, the cardholder accesses the e-wallet 132 on his device 13 and requests a new online payment there. The e-wallet provides a digital display feature which, when requested for a new online payment, displays a digital tokenized PAN and expiration date to be used for the online payment.

At step 208, the cardholder enters the payment card information into the payment form of the merchant website. The payment card information is therefore entered into the merchant system 20.

At step 209, the cardholder selects a card verification value, CVV, independent of any CVV printed on the card, and enters it into the payment form. The CVV is referred to below as "transaction CVV". It can be a 3-digit value, or a 4-digit value. Alternatively, it may include another number of digits.

The number of digits for the transaction CVV is known to the cardholder, for example as the number of digits of a CVV already printed on the card 11.

The cardholder can freely select (therefore pseudo-randomly) the transaction CVV from the range of possible values: [0-999] for a 3-digit CVV, [0-9999] for a 4-digit value. In some embodiments, the transaction CVV must be different from a CVV already printed on the card (if any). This helps the payment system 30 (specifically the cardholder's bank 32) know if the present method is running (to send transaction authorization requests to the cardholder's devices) or if a classic process must be applied (predefined CVV checked on the bank side).

Alternatively, e-wallet 132 may randomly generate a (one-time-use) transaction CVV with the appropriate number of digits. The cardholder must then enter the generated transaction CVV.

In some embodiments, the transaction CVV is selected from a subset of a range of possible values. For example, for a three-digit value, the transaction CVV is selected in the range [500-999], allowing the payment system 30 to know when the present method is running (CVV equal or greater than to 500) or when a conventional process must be applied (CVV < 500).

In other embodiments, the transaction CVV may have a predefined number of digits to identify whether it is a freely chosen transaction CVV. For example, if a 3-digit CVV (in 4-digit variant or any number N of digits) is printed on the card, the cardholder freely chooses a 4-digit CVV (in 3-digit variant or any number different from N). This helps the payment system 30 know if the present process is running (if the CVV is 4 digits) or if a conventional process should be applied (if the CVV is 3 digits).

In yet other embodiments, the value of the PAN provided may indicate to the payment system 30 that a freely selected CVV is being used. For example, if the printed/embossed PAN is used, the printed CVV must be provided, while when a digital tokenized PAN is used, the customer must freely select their CVV.

The customer/cardholder validates the payment form by clicking on an appropriate "pay" button. This validation sends all the payment information (PAN or tokenized PAN, expiration date, transaction CVV) to the merchant server 21 (step 210).

The merchant server 21 initiates the transaction in a conventional manner (step 215): a transaction request is sent to the merchant's bank 31. The request includes transaction information such as the amount of the transaction, the date and time of the transaction, the tokenized PAN (or actual PAN), expiration date, and transaction CVV entered by the consumer, and a merchant ID to determine the merchant's bank account. Other information which is not relevant to the present invention may be added.

Merchant's bank 31 then forwards the request as a transaction authorization request to cardholder's bank 32. The transaction authorization request may be the same message as the transaction request or a different message than -ci (i.e. with different data fields). The cardholder's bank 32 can be identified by the merchant's bank 31 through the tokenized PAN (or real PAN) indicated in the transaction request. The transaction authorization request includes transaction information such as tokenized (or real) PAN, expiration date, transaction CVV, and transaction amount and date/time. This is step 220 which is classic, and is therefore not described in more detail.

Upon receipt of the request, the cardholder's bank 32 identifies the cardholder's bank account using the tokenized (or real) PAN and performs standard checks (e.g. expiration date, bank account balance as concerning the amount of the transaction, and so on.). This is step 225.

At step 226, cardholder's bank 32 determines whether user confirmation of CVV is required, i.e., whether the customer is using a CVV printed on payment card 11 or not.

Confirmation of the CVV may be required if the payment card 11 is provided to the cardholder without a printed CVV or if the printed CVV has been deactivated or declared as hacked. This can also be the case if the transaction CVV provided in the transaction authorization request is within a dedicated range of values (e.g. [500-999] in the example above) or if the CVV has a predefined number of digits (for example a number of digits different from the CVV printed on the card 11) or is different from a CVV printed on the payment card used. CVV confirmation may also be required depending on the PAN provided, for example if it is a tokenized PAN.

If no confirmation of CVV by the user is required, conventional processing (not shown) is carried out, notably the acceptance or refusal of the transaction is returned to the merchant's bank 31, or a transaction confirmation is simply requested from the cardholder in the conventional manner.

If user confirmation is required for the transaction CVV, cardholder's bank 32 invokes banking application 132 in cardholder's device 13 with a transaction authorization request. This is step 227 with the transaction authorization request sent to the cardholder's personal device 13.

According to embodiments, the transaction authorization request does not include a transaction CVV. In variants, it includes the transaction CVV in order to display it to the user (cardholder/customer) for validation or selection.

The transaction authorization request identifies the transaction (e.g. merchant identification, total payment amount, transaction date and time). It is interpreted by the banking application 132 (e-wallet) as a display command to display the transaction information on a screen of the cardholder's device 13 in order to obtain a user transaction confirmation from the cardholder. map.

In some embodiments, the display command provides an input field for the cardholder to type in or type in the transaction CVV used in step 209 for the transaction. This is the case, for example, when the transaction authorization request does not include a transaction CVV.

Alternatively to entering the transaction CVV, the customer may be prompted to enter a reference value or CVV which is based on the transaction CVV, for example by adding a secret value to the transaction CVV known to the cardholder's bank 32 and to the cardholder. For example, a 4-digit transaction CVV can be added to the cardholder's year of birth to obtain the reference CVV to be entered by the cardholder.

The expected CVV of the cardholder, regardless of the transaction or referral CVV, is referred to as the expected CVV.

In other embodiments, the display command provides selectable CVVs including the expected CVV and randomly generated CVVs, for the cardholder to select the correct expected CVV. Alternatively, the display command provides a display of the expected CVV for user confirmation only. This is the case, for example, when the transaction authorization request includes the transaction CVV or the reference CVV if it is calculated by the cardholder's bank 32.

At step 230, the cardholder verifies the transaction information thus displayed. He can confirm the transaction by entering a CVV in the input field (called "confirmation CVV"), or by selecting a CVV among the selectable CVVs, or simply by visually confirming the displayed CVV, and pressing a "validation" button ". The cardholder can also decline the transaction (for example if he is not the buyer) by pressing a "decline" button.

This cardholder/customer action is a user transaction confirmation.

Pressing either button triggers the sending (step 235) of a transaction authorization response to the cardholder's bank 32. The response includes the confirmation CVV, if any, entered or selected or confirmed at step 230.

In some embodiments, the transaction authorization response is digitally signed at optional step 234. The digital signature is performed based on a credential element of the payment token 133. A credential element at one-time or time-limited use for the digital signature is used, or a specific credential item is branched from a root credential item for the digital signature and then used.

This digital signature guarantees the transaction details (information) validated by the cardholder. This provides a layer of security, in particular against an intermediary person (“man in the middle” in Anglo-Saxon language) who would like to modify the amount of the transaction between the various requests and responses exchanged.

The signature is sent with the transaction authorization response. If using a locally diversified specific credential item, an index or other information (e.g. diversifier) can be included in the response so that the cardholder's bank is able to locally regenerate the same specific credential (for signature verification purposes).

At step 240, cardholder's bank 32 makes a transaction authorization decision based on the response so received, optionally with the digital signature.

This may include an optional step 241 consisting in verifying the digital signature attached to the response received.

To do this, the cardholder's bank 32 can locally generate the same token, with credential elements as was done previously (step 200) in the cardholder's personal device 13, or simply retrieve the credential element for digital signature from local memory if it has already been generated, or diversify a credential element using the index or diversifier specified in the received response, to obtain the credential element diversified specific accreditation. This is possible since the bank 32 is aware of all the payment card information.

The same credentials are then used to locally generate another digital signature based on the expected CVV (i.e. transaction or reference) and transaction information. For example, a message similar to the transaction's received authorization response is constructed, but which includes the transaction information and the expected CVV. The signature is then calculated from this message. The locally generated signature and the received signature are then compared to each other. The transaction authorization response can only be processed if the two signatures are identical, which means the response is trusted. It follows that an approval of the transaction itself can only be decided if the two signatures are the same (the verification of the signature is positive).

The next step 242 is for cardholder's bank 32 to verify the confirmation CVV (received at step 235) with the expected CVV which is based on the transaction CVV (received at step 220). The underlying transaction can be approved if the confirmation CVV and the expected CVV are the same.

In the decision, the bank of the cardholder 32 can also take into account (step 243) the results of the conventional verifications of step 225 (payment card still valid with regard to the expiration date and/or the balance of sufficient bank account for the amount of the transaction, and so on.).

In some embodiments, the cardholder's bank 32 may also verify (step 244) that the CVV used (in case the CVV check at step 242 is positive) is not the same as those used at course of the last N (integer) transactions for the same payment card 11. To this end, the cardholder's bank 32 may store in a history memory all the CVVs involved in the transactions for the cardholder. Preferably, only the CVVs of an approved transaction are recorded. The transaction may be declined if the transaction CVV is the same as a CVV used during a previous transaction.

Since the digital signature is optional, step 241 is optional. When a digital signature is implemented, step 242 may be optional. Indeed, a positive signature verification (step 241) is sufficient because it means that the confirmation CVV (by the received signature) is equal to the expected CVV (by the locally generated signature).

Once cardholder's bank 32 has made the transaction authorization decision, it sends a transaction authorization response to merchant's bank 31 (step 245) indicating approval or denial of the transaction under -lying. A unique identifier of the transaction can be tracked in all messages exchanged in the system 1 to facilitate the management of the underlying transaction among a multitude of simultaneous transactions.

The transaction decision (as specified in the response) is processed in the conventional manner by the merchant's bank 31: the decision is transmitted to the merchant system (step 250), and if the transaction is approved, the transfer of money between the two banks is initiated and realized.

The merchant server 21 then processes the decision in a still conventional manner, by displaying to the customer the result of the transaction in the web browser 12: purchase confirmed or transaction refused (step 255).

Some process steps can be done simultaneously or their order can be changed. Notably, the order of steps 241 through 244 doesn't really matter.

As shown in , the cardholder, as a customer wishing to complete a transaction, first displays, at optional step 300, card payment token information on a screen of his cardholder device 13, such as a tokenized PAN and a card expiration date.

Next, the cardholder enters, at step 305, payment information and a transaction CVV into the merchant system 20 connected to the payment system 30, to initiate the transaction through the merchant system. This can be done in a payment form in a web browser accessing a merchant website.

As shown in , the payment system 30 (the merchant's bank 31) therefore receives at step 400 a transaction request from the merchant system 20, the transaction request comprising the transaction CVV and the transaction information.

At step 405, payment system 30 (cardholder's bank 32) sends a transaction authorization request to cardholder's personal device 13. The send responds to receipt of the transaction request by from the merchant system 20. Certain message exchanges between the merchant's bank and the cardholder's bank drive the response process.

At step 310, the transaction authorization request is received by the cardholder device 13, which triggers a display of transaction information on the cardholder device 13 and prompts the cardholder to enter the Expected CVV (Trade or Reference CVV, as applicable) for confirmation purposes or to select a CVV from among the displayed selectable CVVs (including the expected CVV) or to visually confirm the displayed expected CVV.

At step 315, the cardholder enters a CVV or selects a selectable CVV or confirms a displayed CVV, all referred to as confirmation CVV, at cardholder device 13 and confirms (or declines) the displayed transaction.

The latter generates and sends a transaction authorization response to the payment system, at step 320.

At step 410, payment system 30 (cardholder's bank 32) receives the response to the transaction authorization request from cardholder's device 13. The response is based on the confirmation CVV and may optionally be accompanied by a digital signature as mentioned above.

At step 415, the payment system 30 approves (accepts, authorizes, confirms, validates) or denies (declines, rejects) the transaction based on the transaction and confirmation CVVs. In particular, the transaction is approved when the two CVVs are one and the same CVV or when the confirmation CVV is equal to the reference CVV. Other criteria as described above may be used to approve or deny the transaction, for example CVV compared to CVV used in previous transactions or cardholder account balance.

At step 420, the transaction authorization decision is sent to the merchant system 20.

At step 325, the cardholder, via the web browser or the like, receives via the merchant system the approval or rejection of the transaction.

The present invention, the embodiments of which are described above, makes it possible to improve the security of online transactions. Indeed, the cardholder retains control over the validation of any transaction involving his payment card. In addition, CVVs are protected against fraudulent use since they have a short lifespan, are generated for each new transaction and require confirmation by the cardholder himself.

Furthermore, the present invention does not modify the existing merchant systems and reuses the existing payment infrastructure by adding only a CVV confirmation module with the cardholders' banks. The advantage is that by letting the cardholder choose the CVVs without dynamic generation, the PCI certification constraints on the servers managing the payment card are reduced.

Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to these specific embodiments, and modifications, which are within the scope of the present invention. will be visible to a person skilled in the art.

Many other modifications and variations will become apparent to those skilled in the art by referring to the above illustrative embodiments, which are given by way of example only and are not intended to limit the scope of the invention, this being determined solely by the appended claims. In particular, the different characteristics of the different embodiments can be interchanged, if necessary.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "a" does not exclude a plurality. The mere fact that different features are cited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

Claims (15)

A method for performing a cardless transaction, the method comprising, at a payment system (30):
receiving (400) a first card verification value, CVV, with transaction information from a merchant system (20),
receiving (410), from a cardholder device (13), a transaction authorization response that is based on a second CVV, and
approving or denying (240, 415) the transaction based on the first and second CVVs. The method of claim 1, wherein the first CVV is entered by the cardholder into the merchant system (20) and the second CVV is entered by the cardholder at the cardholder device (13) or is selected by the cardholder in a list of CVVs displayed on the cardholder's device or is confirmed by the cardholder when displayed on the cardholder's device. The method of claim 1 or 2, wherein receiving (410) the transaction authorization response is in response to sending (405) a transaction authorization request to the cardholder device (13 ). The method of claim 3, wherein sending (405) the transaction authorization request is in response to receiving (400) a transaction request from the merchant system, the transaction request including the first CVV and transaction information. The method of one of claims 1 to 4, wherein the transaction is approved (240, 415) when the second CVV equals an expected value based on the first CVV. The method of one of claims 1 to 5, wherein the transaction authorization response is received with a first digital signature thereof, computed (234) based on a card payment token (133) stored on the cardholder device (13). The method of claim 6, wherein approving or denying (240, 415) the transaction includes calculating (241) a second digital signature based on the first CVV and a generated card payment token locally for the cardholder, and comparing (242) the first and second digital signatures. Method of one of claims 1 to 7, wherein the transaction is refused if the first CVV is the same as a CVV used during one of the last transactions. A method for performing a cardless transaction, the method comprising:
entering (305) a first CVV into a merchant system (20) connected to a payment system (30), to initiate a transaction,
entering (315) a user transaction confirmation at a cardholder device (13) connected to the payment system (30), the user transaction confirmation being based on a second CVV, And
receiving (325), via the merchant system, an approval or rejection of the transaction based on the first and second CVVs. The method of claim 9, wherein entering the transaction confirmation by the user comprises entering the second CVV at the cardholder's device (13) or selecting the second CVV from a list of CVVs displayed on the cardholder's device or confirming a CVV displayed on the cardholder's device as the second CVV. The method of claim 9 or 10, wherein the entry (315) of the transaction confirmation by the user is in response to a transaction authorization request by the payment system which displays the transaction information on the cardholder device. The method of one of claims 9 to 11, wherein the second CVV equals an expected value based on the first CVV to receive approval for the transaction. The method of one of claims 9 to 12, further comprising pre-displaying (300) card payment token information on a screen of the cardholder device (13), wherein the first CVV is entered (305) in the merchant system (20) with the displayed card payment token information. A payment system (30) that processes a cardless transaction, the payment system comprising:
a transaction receiving server (31) configured to receive a first card verification value, CVV, with transaction information from a merchant system (20),
an authorization server (32) configured to receive, from a cardholder device (13), a transaction authorization response that is based on a second CVV, and to approve or deny the transaction based on the first and second CVV. A cardholder system (10) comprising an access device (12) to a merchant system (20) and a cardholder device (13) connected to a payment system (30), wherein:
the access device (12) is configured for a cardholder to enter a first CVV into the merchant system (20) to initiate a transaction,
the cardholder device (13) is configured for the cardholder to enter a user transaction confirmation, the user transaction confirmation being based on a second CVV, and
the access device (12) receives, through the merchant system (20), an approval or denial of the transaction based on the first and second CVVs.