CARD-NOT-PRESENT TRANSACTIONS WITH CARDHOLDER-CHOSEN CVV

Abstract

A cardholder enters (305) payment information and a freely-selected transaction CVV in a merchant system (20). A payment system (30) receives (400) a request from the merchant system including the transaction CVV and transaction information, and sends (405) a transaction authorization request to a cardholder device (13). The transaction information are displayed (310) on the cardholder device and invites the cardholder to enter the transaction CVV for confirmation purpose. In response, the cardholder enters (315) a confirmation CVV. The payment system approves (240, 415) the transaction when the transaction and confirmation CVVs are the same. As a result, the CVV can have a short life and be changed at each transaction, thereby increasing the security of the transactions. Also, PCI certification constraints on servers are reduced since no issuer master key is required for the CVVs. Lastly, the cardholder has more control on the transaction validation.

Claims

1. A method of performing a card-not-present transaction, the method comprising 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 refusing (240, 415) the transaction based on the first and second CVVs.

2. The method of claim 1, wherein the first CVV is entered by the cardholder in the merchant system (20) and the second CVV is entered by the cardholder on the cardholder device (13) or selected by the cardholder from a list of CVVs displayed on the cardholder device or confirmed by the cardholder when displayed on the cardholder device.

3. The method of claim 1, wherein receiving (410) the transaction authorization response is responsive to sending (405) a transaction authorization request to the cardholder device (13).

4. The method of claim 3, wherein sending (405) the transaction authorization request is responsive to receiving (400) a request for a transaction from the merchant system, the request for the transaction including the first CVV and the transaction information.

5. The method of claim 1, wherein the transaction is approved (240, 415) when the second CVV equals an expected value based on the first CVV.

6. The method of claim 1, wherein the transaction authorization response is received together with a first digital signature thereof computed (234) based on a card-based payment token (133) stored on the cardholder device (13).

7. The method of claim 6, wherein approving or refusing (240, 415) the transaction includes computing (241) a second digital signature based on the first CVV and a locally-generated card-based payment token for the cardholder, and comparing (242) the first and second digital signatures.

8. The method of claim 1, wherein the transaction is refused if the first CVV is the same as one CVV used during one of last transactions.

9. A method of performing a card-not-present transaction, the method comprising: entering (305) a first CVV in a merchant system (20) connected to a payment system (30), to initiate a transaction, entering (315) an user transaction confirmation on a cardholder device (13) connected to the payment system (30), the user transaction confirmation being based on a second CVV, and receiving (325) through the merchant system an approval or refusal of the transaction depending on the first and second CVV.

10. The method of claim 9, wherein entering the user transaction confirmation includes entering the second CVV on the cardholder device (13) or selecting the second CVV from a list of CVVs displayed on the cardholder device or confirming a CVV displayed on the cardholder device as the second CVV.

11. The method of claim 9, wherein entering (315) the user transaction confirmation is responsive to a transaction authorization request from the payment system that displays information of the transaction on the cardholder device.

12. The method of claim 9, wherein the second CVV equals an expected value based on the first CVV to receive an approval of the transaction.

13. The method of claim 9, further comprising previously displaying (300) card-based payment token information on a screen of the cardholder device (13), wherein the first CVV is entered (305) in the merchant system (20) together with the displayed card-based payment token information.

14. A payment system (30) processing a card-not-present 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 refuse the transaction based on the first and second CVVs.

15. 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 in the merchant system (20) to initiate a transaction, the cardholder device (13) is configured for the cardholder to enter an 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 refusal of the transaction depending on the first and second CVV.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0045] FIG. 1 illustrates a transaction system in which embodiments of the present invention can be implemented,

[0046] FIG. 2 illustrates exemplary message exchanges to implement embodiments of the present invention,

[0047] FIG. 3 illustrates, using a flowchart, exemplary steps to implement the present invention at a cardholder side, and

[0048] FIG. 4 illustrates, using a flowchart, exemplary steps to implement the present invention at a payment system side.

DETAILED DESCRIPTION OF THE INVENTION

[0049] The invention applies to financial transactions and more particularly to card-not-present transactions, an example of which is the purchase of one or more products on a web site. The card used for the payment is not swiped or its chip is not read. The consumer needs to input information of the payment card, such as a PAN, an expiry date and a card verification value known as CVV or CVC or CSC. Here below, reference is made to CVV to designate any type of card verification value. An authorization process is then run in the payment system or infrastructure underlying to the merchant system to check the transaction, the payment information and the cardholder account balance for instance. An authorization (or refusal) is then issued that validates the purchase, the purchase amount being transferred from the cardholder bank account to the merchant bank account in the payment system.

[0050] Although reference below is made to online transactions (over Internet), other card-not-present transactions may be contemplated in the context of the present invention, provided that a CVV is entered in addition to payment card information (e.g. PAN and expiry date). These include for instance mail-order transactions by mail or fax, or transactions over the telephone.

[0051] FIG. 1 illustrates a system 1 to implement a card-not-present transaction according to embodiments of the invention.

[0052] The system 1 comprises a cardholder environment or system 10, a merchant environment, infrastructure or system 20 and a payment environment, infrastructure or system 30.

[0053] The cardholder system 10 comprises a payment card 11 of the cardholder, an access device 12 to access the merchant system 20 and a cardholder personal device 13. The payment card 11 may be of any type, with or without magnetic stripe, with or without a secured chip. It may be provided as a physical medium or in an electronic form. The payment card 11 usually includes cardholder name, a PAN and an expiry date, for instance all printed or embossed on the physical card. Some payment cards are further provided with an attached CVV, for instance they include a CVV printed on their front or back. The CVV may be a three-digit code (for instance for Visa and Mastercard cards—registered trademarks) or be a four-digit code (for instance for American Express—registered trademark). Of course, any number of digits may be contemplated within the scope of the present invention. Some payment cards do not have any CVV printed thereon.

[0054] The payment card 11 may be tokenized into the cardholder personal device 13. It means that part or all of the card information (typically PAN) is converted into numeric code or codes (typically token PAN) also known as “token”. The token, referenced 133 in the Figure, can be used, as an alternative of the real card information, for a transaction payment: the token PAN then substitutes the real PAN therefore securing the payment card. To perform tokenization, the cardholder may register its personal device 13 to its bank (reference 32 discussed below), thereby allowing this bank to directly exchange messages with the cardholder. Of course, in a variant, the cardholder may merely connect to the bank using the bank application 132 (e.g. using login and password access).

[0055] The access device 12 may be any system to access the merchant system 20: a web browser, a telephone, a fax, a mail, etc. Preferably, it includes a computer with a web browser allowing access to a merchant website. The computer may be the cardholder personal device 13 (for instance a smartphone implementing a web browser) or be a separate computer.

[0056] The cardholder personal device 13 is preferably a portable device, such as a mobile or smart phone, a tablet, a laptop, a personal organizer, etc. It includes I/O interfaces 130 (e.g. keyboard and screen), applications such as a web browser 131 if the device operates as the access device 12 and a bank application, e.g. a wallet software application or “electronic wallet” or “e-wallet” 132, to implement mechanisms of the present invention. The e-wallet 132 stores the card-based payment token 133.

[0057] The merchant system 20 is basically one or more conventional merchant servers 21 that hosts a merchant website with payment and transaction functionalities to purchase products. Any communication network, e.g. mobile network or Internet, can be used to connect the access device 12 to the server or servers of the merchant system 20.

[0058] The merchant servers 21, and more precisely the one or those handling the transaction functionalities, are connected to the payment system 30 through any type of communication network, typically the Internet. The merchant servers can be implemented by the merchant itself and/or by third parties providing the merchant with sell and payment functionalities.

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

[0060] To initiate the transaction, the customer inputs the information of its payment card on a payment form, thereby triggering a transaction authorization process between the merchant servers 21 and the payment system 30. According to embodiments of the invention, the customer (normally the cardholder) provides, enters or types, in addition to the card information, a CVV. Advantageously, the CVV is 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 may be implemented even if the payment card 11 has a CVV printed on it. This allows the cardholder to have a better control on the CVV-based securing of the transaction. This also allows the cardholder to keep using its payment card even if the CVV has been hacked (in this case, the printed CVV may have been deactivated at the cardholder bank so that the present invention is implemented each time the card is used).

[0061] Only when an authorization response approving the transaction is received from the payment system 30, the merchant servers 21 can inform the customer that its purchase is validated, meaning the transaction is approved.

[0062] The payment system 30 handles the transaction authorization process, thus performs necessary message exchanges between the merchant bank (or “acquiring bank” or transaction receiving server) 31 and the cardholder bank (or “issuer bank”) 32. The payment system 30 usually relies on a greater number of equipment items (e.g. payment gateways, servers, . . . ). For ease of illustration, only the merchant bank and the cardholder bank are shown as separate servers.

[0063] The bank servers are able to exchange messages in order to conduct the authorization process of an underlying transaction, the merchant bank 31 ultimately providing the merchant system 20 with the approval or refusal of the underlying transaction. In this process, the cardholder bank 32 usually checks the transaction information and checks whether the cardholder (identified based on the PAN) is authorized to perform the transaction (with respect to the transaction amount and the bank account balance for instance).

[0064] According to embodiments of the invention, the cardholder bank 32 in a transaction process sends a transaction authorization request to the cardholder device 13 to ask the cardholder for confirmation of the transaction and for providing or confirming the CVV entered when initiating the transaction. The confirmation of the transaction may merely results from the correct typing of the initial CVV by the cardholder on the cardholder device or by entering a CVV that should match a reference CVV based on the initial CVV.

[0065] This ensures the customer has access to the cardholder device, i.e. is in possession of credentials representing the payment card used.

[0066] The cardholder bank 32 may have control over the bank application 132 in such a way transaction details can be displayed to the cardholder with a view of performing the transaction confirmation.

[0067] FIGS. 2 to 4 illustrate methods of processing a card-not-present transaction according to embodiments of the invention.

[0068] FIG. 2 illustrate message exchanges between the entities shown in FIG. 1 to perform a transaction. FIGS. 3 and 4 illustrate general steps of the transaction performing method at respectively the consumer/cardholder environment 10 and the payment infrastructure 30, according to embodiments of the invention. The general steps of the method at the merchant system are conventional ones. Therefore, they are not shown for ease of illustration.

[0069] Initially (step 200), the payment card 11 of the cardholder is tokenized into the bank application (e-wallet) 132 of the cardholder personal device 13. This step is optional since the cardholder, as a consumer, has the choice of using either the card information printed or embossed on the card 11 or the tokenized information provided by the bank application 132 when performing a transaction with a merchant.

[0070] The tokenization provides a payment token made of a token PAN together with the expiry date in the e-wallet 132. Optionally, a set of credentials may be generated as additional data to the payment token. The credentials may include one or more (payment) keys, preferably dedicated to specific usages respectively. The credentials may be one-time credentials, time-constrained credentials in which case the personal device 13 may request new credentials when needed. The credentials may also be unlimited (in terms of use and time) and be diversified locally on the fly to provide specific credentials for specific usages.

[0071] At step 205, made of steps 206 to 209, the cardholder initiates a transaction with the merchant:

[0072] At step 206, the cardholder may for instance access a website of the merchant using the web browser 12, add some products in a shopping cart and access to a payment form displaying a total amount to pay.

[0073] At step 207, the cardholder retrieves its payment card information to enter them in the payment form. Without tokenization of the payment card 11, the cardholder reads the PAN embossed on its card 11, as well as the card expiry date. In case of card tokenization, the cardholder accesses the e-wallet 132 on its device 13 and solicits therein a new online payment. The e-wallet provides a digital display function which, when solicited for a new online payment, displays a digital token PAN and the expiry date to use for the online payment.

[0074] At step 208, the cardholder inputs the payment card information in the payment form of the merchant website. The payment card information are thus entered in the merchant system 20.

[0075] At step 209, the cardholder selects a card verification value, CVV, regardless of any CVV printed on the card, and inputs it in the payment form. The CVV is named “transaction CVV” below. It may be a 3-digit value, or a 4-digit value. Alternatively, it may comprise another number of digits.

[0076] The number of digits for the transaction CVV is known by the cardholder for instance as the number of digits of a CVV already printed on the card 11.

[0077] The cardholder may freely (thus pseudo-randomly) select 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 (in particular the cardholder bank 32) to know whether the present method is running (to send transaction authorization requests to the cardholder devices) or a conventional process is to be applied (predefined CVV checked at the bank side).

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

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

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

[0081] In yet other embodiments, the value of the PAN provided may indicate to the payment system 30 that a freely selected CVV is used. For instance, if the printed/embossed PAN is used, the printed CVV must be provided, while when a digital token PAN is used, the customer has to freely select its CVV.

[0082] The consumer/cardholder validates the payment form by clicking on an appropriate “pay” button. This validation sends all the payment information (PAN or token PAN, expiry date, transaction CVV) to the merchant server 21 (step 210).

[0083] The merchant server 21 initiates the transaction in a conventional manner (step 215): a request for transaction is sent to the merchant bank 31. The request includes transaction information such as the transaction amount, the transaction date and hour, the token PAN (or real PAN), the expiry date and the transaction CVV entered by the consumer, as well as a merchant identifier enabling to determine the merchant bank account. Other information may be added which are not of importance for the present invention.

[0084] The merchant bank 31 next forwards the request as a transaction authorization request to the cardholder bank 32. The transaction authorization request may be the same message as, or a message different (i.e. with different data fields) from, the request for transaction. The cardholder bank 32 can be identified by the merchant bank 31 thanks to the token PAN (or real PAN) indicated in the request for transaction. The transaction authorization request includes transaction information such as the token (or real) PAN, the expiry date, the transaction CVV and the transaction amount and date/hour. This is step 220 which is conventional and thus is not described with more details.

[0085] Upon receiving the request, the cardholder bank 32 identifies the cardholder bank account thanks to the token (or real) PAN and performs conventional checks (e.g. expiry date, bank account balance with respect to the transaction amount, and so on.). This is step 225.

[0086] At step 226, the cardholder bank 32 determines whether a user confirmation of the CVV is required, i.e. whether the consumer uses a CVV printed on the payment card 11 or not.

[0087] CVV confirmation 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 may also be the case if the transaction CVV provided in the transaction authorization request belongs to a dedicated range of value (e.g. [500-999] in the above example) or if the CVV has a predefined number of digits (e.g. a different number of digits compared to 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 provided PAN, e.g. if it is a token PAN.

[0088] If no user CVV confirmation is required, conventional processing (not shown) is performed, for instance acceptance or refusal of the transaction is sent back to the merchant bank 31 or a transaction confirmation is merely solicited to the cardholder in a conventional manner.

[0089] If a user confirmation is required for the transaction CVV, the cardholder bank 32 calls on the bank application 132 in the cardholder device 13 with a transaction authorization request. This is step 227 with the transaction authorization request sent to the cardholder personal device 13.

[0090] According to embodiments, the transaction authorization request does not comprise the transaction CVV. In variants, it includes the transaction CVV with a view of displaying it to the user (cardholder/consumer) for validation or selection.

[0091] The transaction authorization request identifies the transaction (e.g. identification of the merchant, total payment amount, transaction date and hour). It is interpreted by the bank application 132 (e-wallet) as a display command to display the transaction information on a screen of the cardholder device 13 in view of obtaining user transaction confirmation from the cardholder.

[0092] In some embodiments, the display command provides an input field for the cardholder to input or type or enter the transaction CVV used at step 209 for the transaction. This is for instance the case when the transaction authorization request does not comprises the transaction CVV.

[0093] In a variant to entering the transaction CVV, the consumer may be invited to enter a reference value or CVV that is based on the transaction CVV, for instance the addition of the transaction CVV with a secret value known by the cardholder bank 32 and the cardholder. As an example a transaction 4-digit CVV may be added to the birth year of the cardholder to obtain the reference CVV to be input by the cardholder.

[0094] The CVV expected from the cardholder, no matter the transaction or reference CVV, is referred to as the expected CVV.

[0095] 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. In a variant, the display command provides a display of the expected CVV for user confirmation only. This is for instance the case when the transaction authorization request includes the transaction CVV or the reference CVV if computed by the cardholder bank 32.

[0096] At step 230, the cardholder verifies the transaction information so displayed. He can confirm the transaction by inputting a CVV in the input field (named as “confirmation CVV”) or selecting one CVV from the selectable CVVs or merely visually confirming the displayed CVV, and pushing a “validation” button. The cardholder may also decline the transaction (e.g. if he is not the purchaser) by pushing a “refusal” button.

[0097] This action of the cardholder/consumer is a user transaction confirmation.

[0098] The pushing of either button triggers the sending (step 235) of a transaction authorization response to the cardholder bank 32. The response includes the confirmation CVV, if any, input or selected or confirmed at step 230.

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

[0100] This digital signature guarantees the transaction details (information) validated by the cardholder. This provides a layer of security against for instance a man in the middle wishing to modify the transaction amount between the various requests and response exchanged.

[0101] The signature is sent together with the transaction authorization response. In case a locally-diversified specific credential is used, an index or any other information (e.g. diversifier) may be included in the response for the cardholder bank to be able to locally regenerate the same specific credential (for signature check purpose).

[0102] At step 240, the cardholder bank 32 takes a transaction authorization decision based on the response so received, optionally with the digital signature.

[0103] This may include optional step 241 of verifying the digital signature attached to the received response.

[0104] To do so, the cardholder bank 32 may locally generate the same token with credentials as previously (step 200) done in the cardholder personal device 13 or merely retrieves the credential for digital signature from local memory if already generated or diversifies a credential using the index or diversifier specified in the received response, to obtain the diversified specific credential. This is possible since the bank 32 has knowledge of all the payment card information.

[0105] The same credentials are then used to locally generate another digital signature based on the expected (i.e. transaction or reference) CVV and the transaction information. For instance, a message similar to the received transaction authorization response is built but that comprises the transaction information and the expected CVV. The signature is then computed from this message. The locally-generated signature and the received signature are then compared one to each other. The transaction authorization response can be processed only when the two signatures are the same, meaning the response is trusted. It results that an approval of the transaction itself can be decided only if the two signatures are the same (signature verification is positive).

[0106] Next step 242 consists for the cardholder bank 32 to verify the confirmation CVV (received at step 235) with the expected CVV that 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.

[0107] In the decision, the cardholder bank 32 can also takes into account (step 243) the results of the conventional checks of step 225 (payment card still valid with respect to the expiry date and/or sufficient bank account balance with respect to the transaction amount, and so on.).

[0108] In some embodiments, the cardholder bank 32 may also check (step 244) that the CVV used (in case CVV check at step 242 is positive) is not the same as the ones used during the last N (integer) transactions for the same payment card 11. To that end, the cardholder bank 32 may record in a history memory all the CVVs involved in the transactions for the cardholder. Preferably, only the CVVs for an approved transaction are recorded. The transaction may be refused if the transaction CVV is the same as one CVV used during one previous transaction.

[0109] As 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 enough because it means that the confirmation CVV (through the received signature) equals the expected CVV (through the locally-generated signature).

[0110] Once the cardholder bank 32 has taken the transaction authorization decision, it sends a transaction authorization response to the merchant bank 31 (step 245) indicating the approval or the refusal of the underlying transaction. A unique identifier of the transaction may be tracked in all the messages exchanged in the system 1 to facilitate the management of the underlying transaction from among a multiple of simultaneous transactions.

[0111] The transaction decision (as specified in the response) is processed in a conventional manner by the merchant bank 31: the decision is forwarded to the merchant system (step 250) and in case of transaction approval, money transfer between the two banks is initiated and realized.

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

[0113] Some steps of the process can be made simultaneously or their order can be changed. For instance, the order of steps 241 to 244 does not really matter.

[0114] As shown in FIG. 3, the cardholder as a consumer wishing to perform a transaction first displays, at optional step 300, card-based payment token information on a screen of its cardholder device 13, such as a token PAN and a card expiry date.

[0115] Next, the cardholder enters, at step 305, payment information and a transaction CVV in the merchant system 20 connected to the payment system 30, to initiate the transaction via the merchant system. This may be done in a payment form in a web browser accessing a merchant web site.

[0116] As shown in FIG. 4, the payment system 30 (the merchant bank 31) thus receives at step 400 a request for a transaction from the merchant system 20, the request for the transaction including the transaction CVV and transaction information.

[0117] At step 405, the payment system 30 (the cardholder bank 32) sends a transaction authorization request to the cardholder personal device 13. The sending is responsive to the receiving of the request for transaction from the merchant system 20. Some message exchanges between the merchant bank and the cardholder bank drive the responsive process.

[0118] At step 310, the transaction authorization request is received by the cardholder device 13 triggering a display of the transaction information on the cardholder device 13 and inviting the cardholder to enter the expected CVV (transaction or reference CVV if applicable) for confirmation purpose or to select a CVV from amongst displayed selectable CVVs (including the expected CVV) or to visually confirm the displayed expected CVV.

[0119] At step 315, the cardholder enters a CVV or select a selectable CVV or confirm a displayed CVV, all referred to as a confirmation CVV, on the cardholder device 13 and confirms (or declines) the displayed transaction.

[0120] This generates and sends a transaction authorization response to the payment system, at step 320.

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

[0122] At step 415, the payment system 30 approves (accepts, authorizes, confirms, validates) or refuses (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 or when the confirmation CVV equals the reference CVV. Other criteria as described above can be used to approve or refuse the transaction, for instance the CVV compared to the CVVs used in previous transactions or the cardholder account balance.

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

[0124] At step 325, the cardholder, via the web browser or the like, receives through the merchant system the approval or refusal of the transaction.

[0125] The present invention, embodiments of which are described above, allows the security of on-line transactions to be improved. Indeed, the cardholder keeps control on the validation of any transaction involving its payment card. Furthermore, the CVVs are protected from fraudulent use since they have a short life, are generated for each new transaction and require confirmation by the cardholder himself

[0126] Additionally, the present invention does not modify the existing merchant systems and reuses the existing payment infrastructure by only adding a CVV confirmation module at the cardholder banks. Advantageously, by letting the cardholder choosing the CVVs without dynamic generation, PCI certification constraints on the servers managing the payment card are reduced.

[0127] Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

[0128] Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged, where appropriate.

[0129] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.