US20110225094A1 - System and method including dynamic verification value - Google Patents
System and method including dynamic verification value Download PDFInfo
- Publication number
- US20110225094A1 US20110225094A1 US13/038,181 US201113038181A US2011225094A1 US 20110225094 A1 US20110225094 A1 US 20110225094A1 US 201113038181 A US201113038181 A US 201113038181A US 2011225094 A1 US2011225094 A1 US 2011225094A1
- Authority
- US
- United States
- Prior art keywords
- account
- dynamic
- verification value
- attribute
- account attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
Definitions
- a user may use a credit card to purchase an item at a merchant or enter his account information into a payment page of a merchant's website.
- the merchant then generates an authorization request message using a POS (point of sale) terminal when the user is present at the merchant location.
- the merchant website may generate an authorization request message for card-not-present (CNP) transactions.
- CNP card-not-present
- Embodiments of the invention address these and other problems, individually and collectively.
- Embodiments of the invention disclosed herein include systems and methods for generating dynamic verification values for use in the electronic payment transactions.
- One embodiment of the invention is directed to a method comprising receiving an account identifier (e.g., an account number) and an account attribute (e.g., an expiration date) associated with an account such as a credit card account.
- the method also includes generating a dynamic account attribute (e.g., a dynamic expiration date) from the account attribute associated with the account, and generating a dynamic verification value (e.g., a dCVV or dynamic card verification value) using the account identifier and the dynamic account attribute.
- the generation of the dynamic verification value may include concatenating the account identifier and the dynamic account attribute.
- the dynamic verification value and, optionally, the dynamic account attribute can then be used to authenticate the account or a portable consumer device associated with the account.
- Another embodiment of the invention is directed to a method comprising using the concatenated account identifier and the dynamic account attribute as an input into an algorithm that encrypts the concatenated account identifier and the dynamic account attribute using a Master Derivation Key (MDK). The algorithm then generates a Unique Derived Key (UDK).
- MDK Master Derivation Key
- UDK Unique Derived Key
- Another embodiment of the invention is directed to a method comprising sending an account identifier and an account attribute associated with an account to a server computer, receiving a dynamic verification value and a dynamic account attribute, and sending the dynamic verification value and the dynamic account attribute to a second server computer.
- the second server computer uses the dynamic verification value and the dynamic account attribute for authentication.
- Another embodiment if the invention is directed to a method including using the dynamic verification value and the dynamic account attribute in an authorization request message.
- FIG. 1 shows a system according to an embodiment of the invention.
- FIG. 2 shows a user communication device according to an embodiment of the invention.
- FIG. 3 illustrates a flowchart that shows the steps involved in generating a dynamic verification value, according to an embodiment of the invention.
- FIG. 4 illustrates a flowchart that shows the steps involved in concatenating an account identifier with a dynamic expiration date, according to an embodiment of the invention.
- FIG. 5 shows the process of generating a dynamic verification value, according to an embodiment of the invention.
- FIG. 6 illustrates a diagram that shows an example of a portable consumer device and a payment page of a merchant website, according to an embodiment of the invention.
- FIG. 7 shows a block diagram of a computer apparatus according to an embodiment of the invention.
- additional security data may be used during the processing of electronic payment transactions.
- Such data can be generated by an external source and introduced into the transaction process at any point, and then verified by a processing entity or the issuer of the debit or credit card to make sure that the transaction has originated from an authorized source.
- One embodiment of the invention is directed to a method comprising receiving, by a server computer associated with a payment processing network and from a user computer, an account number and an account attribute such as an expiration date associated with an account such as a credit card account.
- the expiration date and the account number may further be associated with a credit card or other portable consumer device.
- the method also includes generating, by the server computer, a dynamic account attribute such as a dynamic expiration date from the account attribute associated with the account.
- the server computer may also generate a dynamic verification value such as a dCVV or dynamic card verification value using the account identifier and the dynamic account attribute.
- the dynamic verification value and, optionally, the dynamic account attribute can then be used to authenticate the account or a portable consumer device associated with the account.
- the dCVV value and the dynamic expiration date can be entered onto a web page on a merchant's Web site. This data can then be transmitted in an authorization request message from the merchant's website to a payment processing network that is located between many issuers and acquirers.
- the server computer associated with the payment processing network may then receive the dCVV value and the dynamic expiration date. It may then independently generate the dCVV and the dynamic expiration date and compare it to the dCVV and the dynamic expiration date received from the merchant's website. If they match, then the transaction may then be considered to be authentic.
- An indication of the authenticity of the transaction (e.g., in the form of an authentication score) may then be passed in the authorization request message to the issuer of the account.
- the issuer of the account may then decide whether or not to authorize the transaction, and may then send an authorization response message back to the merchant website. It may indicate whether or not the issuer approved of the transaction. Then, at the end of the day, a clearing and settlement process can take place.
- account identifier can refer to an identifier for an account. It may comprise any suitable number of characters (e.g., numbers and/or letters) suitable for identifying an account.
- an account identifier may be a Primary Account Number (PAN) of a credit or debit card.
- PAN Primary Account Number
- the Primary Account Number (PAN) may include numbers and/or letters and may be in any length.
- Other examples of account identifiers may include a name of the account holder, an address associated with the account, a phone number associated with an account, a password associated with the account, etc.
- account attribute can refer to any data that does not change frequently and is relatively static. It may be associated with a portable consumer device such as a payment card. If they change at all, account attributes typically do not change more than once per year. Examples of account attributes may include, without limitation, an expiration date for payment card, an account holder's name, a service code, and a CVV2 or CVV value. In some embodiments, the account attribute includes data that is stored or present on a payment card (e.g., an expiration date or CVV value).
- an “authorization request message” may be a message that includes an issuer account identifier.
- the issuer account identifier may be a payment card account identifier associated with a payment card.
- the authorization request message may request that an issuer of the payment card authorize a transaction.
- An authorization request message according to an embodiment of the invention may comply with ISO 8583, which is a standard for systems that exchange electronic transactions made by cardholders using payment cards.
- an authorization request message may include, among other data, an account identifier, one or more account attributes, an amount of the transaction (which may be any type and form of a medium of exchange such a money or points), and identification of a merchant (e.g., a merchant verification value or a merchant ID).
- an authorization request message is generated by a server computer (if the transaction is an e-commerce transaction) or a Point of Sale (POS) device (if the transaction is a brick and mortar type transaction) and is sent to an issuer via a payment processing network and an acquirer.
- a server computer if the transaction is an e-commerce transaction
- POS Point of Sale
- user communication device can refer to an electronic device capable of communication with other electronic devices.
- user communication device may be a desktop computer, laptop computer, netbook computer, tablet computer (e.g. iPad), mobile phone, verification token (described in detail later) and any other electronic device that can be coupled to another electronic device either wirelessly or via a direct connection.
- dynamic verification value can refer to a value that can be used to verify that a transaction (and in some cases a portable consumer device used to conduct a transaction) is authentic. It may be a numeric or alpha-numeric value that is generated by an algorithm (e.g. encryption algorithm) that uses account data such as account identifier and account attribute as inputs.
- algorithm e.g. encryption algorithm
- a “server computer” is typically a powerful computer or cluster of computers.
- the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit.
- the server computer may be a database server coupled to a web server.
- Embodiments of the invention disclosed herein include systems and methods for dynamically generating a verification value and for utilizing it to verify that a transaction originates from an authorized source and that a portable consumer device (e.g., debit or credit card) or other means used to conduct the transaction is authentic.
- a portable consumer device e.g., debit or credit card
- Embodiments of the present invention are able to maintain or improve existing user experiences, minimize the adverse impacts on merchant processes/systems, leverage existing network data transport mechanisms, utilize existing issuer validation infrastructure, support multiple forms of implementation, and maintain consistency with broader authentication strategies.
- FIG. 1 shows a block diagram illustrating the components of a system according to an embodiment of the invention.
- FIG. 1 shows a user 110 and a portable consumer device 112 that the user 110 may use to conduct a payment or other type of transaction.
- the user 110 may also operate a mobile device 118 , a user computer 120 , and a verification token 122 .
- the user 120 may contact a merchant website 130 run on a server computer 131 .
- the IP Gateway may include an IP Gateway server computer 153 while the payment processing network 150 may include a payment processing network server computer 155 .
- the IP gateway server computer 153 may include a computer readable medium 154 , a processor 155 , and a generation module 151 .
- the payment processing network server computer 155 may include a data processor 156 , and a comparison module 158 .
- a database 159 may be operatively coupled to the server computer 155 .
- the user 110 can use the portable consumer device 112 , the mobile device 118 , and the user computer 120 .
- the user 110 interacts with the merchant website 130 using the user computer 120 and/or mobile device 118 .
- the mobile device 118 , the verification token 122 and the user computer 120 are capable of communicating with the IP Gateway 152 for requesting and receiving a dynamic verification value (this process will be described in detail later).
- the merchant website 130 is in communication with the acquirer 140 .
- the acquirer 140 is in communication with the issuer 160 through the payment processing network 150 .
- the payment processing network 150 is in communication with the IP Gateway 152 .
- the IP Gateway 152 has access to the payment processing network server computer 155 .
- the user 110 can be an individual or organization such as a business that is capable of purchasing goods or services or making any suitable payment transaction with the merchant website 130 .
- the portable consumer device 112 can be any suitable device that can be used to conduct a payment transaction, and may be in any suitable form.
- suitable portable consumer devices 112 can be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). They may include smart cards, magnetic stripe cards, keychain devices (such as the SpeedpassTM commercially available from Exxon-Mobil Corp.), etc.
- Other examples of portable consumer devices 112 include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, and the like.
- the portable consumer device 112 may be associated with an account of user 110 such as a bank account.
- Portable consumer device 112 may include a contactless element 114 that includes a processor (not shown), an antenna (not shown), computer readable media (not shown), and one or more applications stored on the computer readable media that operate in concert to allow the portable consumer device 112 to wirelessly send its stored card data to a wireless reader.
- the contactless element 114 provides Near Field Communication (NFC) capability for the portable consumer device 112 such that when the portable consumer device 112 is in close proximity of a wireless reader, the wireless reader powers the contactless element 114 and collects the card data.
- NFC Near Field Communication
- the mobile device 118 may be in any suitable form.
- suitable mobile device 118 can be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized).
- Some examples of the mobile device 118 include desktop or laptop computers, cellular phones, personal digital assistants (PDAs), pagers, and the like.
- the mobile device 118 and the portable consumer device 112 can be embodied in the same device.
- the user computer 120 may be a personal computer, phone, or a laptop computer.
- the user computer 120 may run an operating system such as Microsoft WindowsTM and may have a suitable browser such as Internet ExplorerTM.
- the verification token 122 can be an electronic device configured to be coupled to, or can be present within, the user computer 120 and can be capable of wirelessly receiving card data from the portable consumer device 112 . Elements of the verification token 122 and their operation will be described later with reference to FIG. 2 .
- the merchant website 130 may be in the form of a website hosted by one or more server computers (e.g. server computer 131 ).
- the user 110 is capable of communicating with the merchant website 130 using the user computer 120 and/or mobile device 118 .
- the acquirer 140 can be any suitable entity that has an account with a merchant associated with the merchant website 130 .
- the issuer 160 may also be the acquirer 140 .
- the payment processing network 150 can be a network of suitable entities that have information related to an account associated with the portable consumer device 112 .
- This information includes data associated with the account on the portable consumer device 112 such as profile information, data, and other suitable information.
- data may be stored in one or more databases such as the database 159 and may be accessible by one or more server computers such as the server computer 155 .
- the payment processing network 150 may have or operate a server computer and may include a database (e.g. the server computer 155 and the database 159 ).
- the database may include any hardware, software, firmware, or combination of the preceding for storing and facilitating retrieval of information. Also, the database may use any of a variety of data structures, arrangements, and compilations to store and facilitate retrieval of information.
- the server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers.
- Server computer may comprises one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
- the payment processing network 150 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services.
- An exemplary payment processing network 150 may include VisaNetTM. Networks that include VisaNetTM are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNetTM, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.
- the payment processing network 150 may use any suitable wired or wireless network, including the Internet.
- the IP Gateway 152 can refer to an entity that includes one or more servers such as IP Gateway server computer 153 .
- the IP Gateway 152 may also include one or more databases (not shown), and have access to issuer data, transaction data and user data. This data may be used to authenticate portable consumer devices.
- the IP Gateway 152 also generates and delivers notifications and alert messages to various delivery channels.
- the IP Gateway 152 may be part of the payment processing network 150 or may be a separate entity in communication with payment processing network 150 .
- the databases 159 may be server computers that are capable of storing data and responding to queries from client computers.
- the database 159 may also be in the form of stand-alone hard drives connected to one or more server computers that retrieve the data from the database 159 as result of queries from client computers.
- a “computer readable medium” or “computer readable storage medium” is typically a storage medium such a hard disk or any suitable type of data storage medium capable of storing data such as program codes.
- the comparison module 158 can be a software program stored on the computer readable medium, and run by the processor 156 , that monitors the stream of data in an electronic payment transaction and compare various types of data in the electronic payment transaction such as the dynamic verification value with the same type of data supplied by the IP Gateway 152 or any other entity to make sure the data that are part of the electronic payment transactions are accurate and are originated from an authorized source.
- the generation module 151 can be software program stored on the computer readable medium 154 and run by the processor 155 that generates a dynamic verification value.
- the generation module 151 may also be embodied as a Hardware Security Module (HSM) that generates a dynamic verification value.
- HSM Hardware Security Module
- the issuer 160 can be any suitable entity that may open and maintain an account associated with the portable consumer device 112 for the user 110 .
- Some examples of issuers may be a bank, a business entity such as a retail store, or a governmental entity.
- the issuer 160 may also issue the portable consumer device 112 associated with the account to the user 110 .
- FIG. 2 is a block diagram illustrating various components of the verification token 122 according to one embodiment.
- the embodiment illustrated in FIG. 2 is a USB device that includes a USB connectivity module 230 , a secure element 220 (e.g., a smart card chip), a wireless/contactless reader 210 capable of reading card data (payment data) from a portable consumer device, a built in memory 240 , a self-installing driver 250 , a form fill application 260 , a terminal application 270 , and a heartbeat application 280 .
- the verification token 122 may also have other features such as a keyboard buffer capability and a unique serial number associated with the verification token.
- the verification token 122 has no footprint on the user computer 120 with internet connectivity when it is plugged in.
- the various components and modules on the verification token 122 can be used to implement methods according to embodiments of the invention.
- FIG. 2 illustrates a verification token 122 as something similar to a USB stick
- the verification token 122 may come in other forms.
- it may be piece of hardware or other module installed in a computer, consumer device, or other device.
- the verification token may be housed in a computer and need not be a device that is physically separated from the computer.
- the user 110 may take his portable consumer device 112 and may interact with the verification token 122 .
- the portable consumer device 112 may be a contactless payment card, and the contactless payment card can be placed near the verification token.
- Information such as the Primary Account Number (PAN) as well as the expiration date may then pass from the portable consumer device 112 , to the verification token 122 , to the user computer 120 , and to the IP Gateway 152 .
- the IP Gateway 152 may then receive this information, and this may cause the IP Gateway 152 to generate a dynamic verification value.
- PAN Primary Account Number
- a dynamic verification value may be generated by the generation module 151 in the server computer 153 of the IP Gateway 152 and delivered to a user communication device such as the user computer 120 /verification token 122 combination, and the mobile device 118 .
- the user communication device that receives the dynamic verification value may be utilized in the process of performing an electronic payment transaction (this process will be described in detail below).
- a dynamic verification value may be received by a user communication device (e.g., the mobile device 118 ) and the user 110 may manually enter the dynamic verification value in a payment page of a website.
- the IP Gateway server computer 153 may also send the dynamic verification value to the payment processing network server computer 155 in the payment processing network 150 .
- the payment processing network 150 may also contact the IP Gateway 152 to receive the dynamic verification value at any time.
- a program in the payment processing network server computer 155 associates the dynamic verification value with a corresponding account number associated with the user 110 .
- the account number of the user 110 may be issued by the issuer 160 .
- the payment processing network 150 may independently generate the dynamic verification value based on the data received in an authorization request message and may then compare the generated dynamic verification value the one that was accompanied by the authorization request message.
- the dynamic verification value is entered in the payment page of the merchant website 130 either automatically via the verification token 122 or manually by the user 110 .
- the merchant website 130 receives transaction details including name and address of the user 110 , the account identifier and account attributes, and the payment amount, it then generates an authorization request message which is sent to the acquirer 140 .
- the acquirer 140 forwards the authorization request message to the payment processing network 150 .
- the payment processing network 150 Upon receipt of the authorization request message, the payment processing network 150 compares the dynamic verification value included in the authorization request message, with the dynamic verification value that was received from the IP Gateway 152 (more specifically, the IP Gateway server computer 153 ) or the dynamic verification value that the payment processing network 150 independently generates. This is done via the comparison module 158 which runs on the payment processing network server computer 155 .
- the server computer 155 in the payment processing network 150 determines whether the dynamic verification value that was included in the authorization request message matches with the copy that was provided by the IP Gateway 152 or that was generated independently from data that are provided in the authorization request message. In one embodiment, the payment processing network 150 then forwards the authorization request message to the issuer 160 along with an indicator that specifies whether there was a match between the dynamic verification values. In one embodiment, if the dynamic verification values do not match, payment processing network 150 may decline the transaction on behalf of the issuer 160 . The issuer 160 or the payment processing network 150 can then generate an authorization response message which indicates whether the transaction is approved or declined. The authorization response message is forwarded to the acquirer 140 and then to the merchant 130 .
- the user 110 may receive a verification token 122 such as the one illustrated in FIG. 2 from his or her financial institution (issuer 160 , for example).
- a user may receive a verification token 122 from another entity on behalf of a financial institution.
- the user 110 can then connect the verification token 122 to the USB port of his user computer (user computer 120 , for example).
- the verification token 122 is then powered by the user computer, and it is recognized as a valid device.
- the verification token 122 can also self-install via the self-installing driver 250 (shown in FIG. 2 ), and then ping the user computer 120 to check for internet connectivity.
- the verification token 122 can then automatically attempt to establish a background SSL session to the IP Gateway 152 through a predefined IP address, using the user computer 120 , so that it can be used as a part of an authentication process.
- a terminal application 270 and heartbeat application 280 may be used to establish and maintain this connection. If the session connection is successfully established, the verification token 122 identifies itself to the IP Gateway 152 by providing its unique serial number and/or IP address.
- Card data i.e. account data
- the verification token 122 encrypts the card data and sends them to the IP Gateway 152 via the previously established SSL session described above.
- the IP Gateway 152 receives the encrypted data, the authenticity of the information is validated by validating the account number associated with the portable consumer device 112 .
- the IP Gateway 152 generates a dynamic verification value based on a predetermined algorithm, and sends the dynamic verification value to the verification token 122 .
- the dynamic verification value is automatically form-filled in the payment page of the merchant website 130 by the form-fill application 260 shown in FIG. 2 .
- the merchant website 130 When the dynamic verification value is submitted to the merchant website 130 , the merchant website 130 then generates an authorization request message which is sent to the acquirer 140 .
- Acquirer 140 passes the authorization request to the payment processing network 150 .
- Payment processing network 150 compares the dynamic verification value that is in the authorization request message from the acquirer 140 (which is received from the merchant website 130 ) to the dynamic verification value that is received from the IP Gateway 152 or the dynamic verification value that was independently generated by the payment processing network 150 . This is performed by the comparison module 158 . If they match, the payment processing network 150 sends the authorization request message to the issuer 160 .
- the issuer 160 generates an authorization response message which indicates whether the transaction is approved or declined.
- the authorization response message is sent to the payment processing network 150 which then sends it to the acquirer 140 .
- the acquirer 140 informs the merchant associated with the merchant website 130 about the result.
- the user 110 requests and receives the dynamic verification value using the mobile device 118 .
- the user 110 then initiates a request by sending an SMS from the mobile device 118 to the IP Gateway 152 .
- the IP Gateway 152 receives the request, the phone number and the Primary Account Number (PAN) associated with the mobile device 118 are identified.
- the IP Gateway 152 validates the account number associated with the portable consumer device 112 and phone number of the mobile device 118 .
- the IP Gateway 152 generates a dynamic verification value, based on a predetermined algorithm, which is sent to the mobile device 118 .
- the mobile device may receive the dynamic verification value via SMS or through application that communicates with the IP Gateway server computer 153 .
- the generated dynamic verification value is also sent to the payment processing network 150 .
- the mobile device 118 may also have a form-fill application that automatically form-fills the dynamic verification value into a payment page of a web site accessed via the mobile device 118 .
- the dynamic verification value may be generated from the account identifier (e.g. a Primary Account Number (PAN)), and one or more account attributes (e.g. an expiration date).
- FIGS. 3-5 illustrate the process of generating the dynamic verification value according to an embodiment of the invention.
- the IP Gateway 152 receives an account identifier (e.g. the Primary Account Number (PAN)) and an account attribute (e.g. the expiration date) associated with the portable consumer device 112 of the user 110 from the verification token 122 or the mobile device 118 .
- PAN Primary Account Number
- an account attribute e.g. the expiration date
- the IP Gateway 152 verifies that the account identifier and the account attributes such as the expiration date are valid. This step which is not shown in the flowchart of the FIG. 3 , may be performed by the payment processing network 150 at the time of receiving an authorization request message.
- step S 302 the IP Gateway 152 generates a dynamic expiration date from the expiration date associated with the portable consumer device 112 .
- the account identifier e.g. the Primary Account Number (PAN)
- PAN Primary Account Number
- step S 401 an example of an account identifier in the form of a 16-digit Primary Account Number (PAN) and an account attribute in the form of the expiration date are shown.
- step S 401 the Primary Account Number (PAN) and an expiration date associated with a portable consumer device are obtained.
- step S 402 a dynamic expiration date is generated from the expiration date, and at step S 403 the dynamic expiration date is concatenated with the Primary Account Number (PAN).
- the dynamic expiration date may be generated via an algorithm that accepts the expiration date as an input and uses a predetermined formula to generate a dynamic expiration date.
- step S 304 the concatenated account identifier (e.g. Primary Account Number (PAN)) and the dynamic account attribute (e.g. dynamic expiration date) are inputted into a key derivation algorithm.
- step S 305 a Unique Derived Key (UDK) that is obtained from the key derivation algorithm is inputted into another algorithm that generates a dynamic verification value. The dynamic verification value is then provided to the verification token 122 or the mobile device 118 .
- PAN Primary Account Number
- UDK Unique Derived Key
- the data string 501 which may be formed by concatenation of the account identifier (e.g. the Primary Account Number (PAN)) and the dynamic account attribute (e.g. dynamic expiration date) can be altered (i.e. encrypted) to form a Unique Derived Key (UDK) 504 .
- the data string 501 is inputted into a data encryption algorithm 503 (also referred to as the key derivation algorithm) such as DES or triple-DES, for example.
- the Master Derivation Key (MDK) 502 is then used to encrypt the data string 501 .
- the value resulting from the encryption algorithm 503 is the Unique Derived Key (UDK) 504 .
- the data string 501 may be formed from concatenation of more than two types of account data.
- data string 501 may be formed by concatenating the Primary Account Number (PAN), a sequence number which changes with each transaction and the dynamic expiration date. Utilization of more account data to form the data string 501 results in a more complex and secure Unique Derived Key (UDK) 504 .
- PAN Primary Account Number
- ULK Unique Derived Key
- the data encryption algorithm 503 may not be able to accepts an input that is larger than a pre-determined number of bits/bytes. In such embodiments, the data string 501 may be truncated as needed. In some other embodiments, the data encryption algorithm may expect an input that is larger than a pre-determined bits/bytes. In such embodiments, the data string 501 may be padded with zeros at either end.
- the Unique Derived Key (UDK) 504 and a data encryption algorithm 506 can be used to alter (i.e. encrypt) a second data string (e.g. data string 505 “input X”).
- the data encryption algorithm 506 may be the same type of algorithm as the data encryption algorithm 503 or may be any other suitable encryption algorithm.
- Data string 505 may be the same as data string 501 or may be any other suitable data string.
- data string 505 may be the account identifier (i.e. Primary Account Number (PAN)) of the portable consumer device of the user.
- PAN Primary Account Number
- the data string 505 is then encrypted via Unique Derived Key (UDK) 504 to form the data string 507 (i.e., output X′).
- the resulting data string 507 is then altered via the algorithm 508 to form a dynamic verification value 509 .
- the algorithm 508 may be any suitable algorithm and may perform a suitable alteration process on the resulting data string 509 .
- the algorithm 508 may take the last 32 bits of data (i.e. 4 digits) from the data string 507 as the dynamic verification value.
- FIG. 6 shows the portable consumer device 600 and the payment page 601 .
- the payment page 601 is a payment page of a website from which the user 110 whishes to purchase goods or services.
- the payment page 601 may be accessed by using user computer 120 .
- the user 110 is directed to the payment page 601 to provide the information needed to perform a payment transaction.
- the information in fields 602 - 610 are automatically form-filled via verification token 122 .
- these information include: first name 602 , last name 603 , street address 604 , city 605 , state 606 , zip code 607 , account number 608 , expiration date 609 and card verification value (CVV2) 610 .
- FIG. 6 also shows two additional fields 611 and 612 which will be described in detail later.
- the portable consumer device 600 may be embodied as data stored on a user communication device such as a mobile device.
- a mobile device may contain an application that stores the account number, expiration date, security code and any other data needed to perform a payment transaction.
- the mobile device may be capable of Near Field Communication (NFC) with the verification token 122 . Therefore, the example of the portable consumer device 600 shown in FIG. 6 as a credit/debit card is not intended to be limiting.
- NFC Near Field Communication
- the user 110 can bring his portable consumer device (e.g. portable consumer device 600 ) in close proximity of the verification token 122 and the verification token 122 receives the account data including an account identifier (e.g. Primary Account Number (PAN)) and an account attribute (e.g. expiration date) from the portable consumer device of the user 110 and sends the account identifier and the account attribute, among other account data, to the IP Gateway server computer 153 and requests a dynamic verification value.
- PAN Primary Account Number
- an account attribute e.g. expiration date
- the generation module 151 of the IP Gateway server computer 153 then generates a dynamic verification value and a dynamic expiration date which are sent from the IP Gateway server computer 153 to the verification token 122 .
- the dynamic verification value and the dynamic expiration date can be form-filled and/or included in the payment information in payment page 601 in several ways which will now be described in detail.
- the payment page 601 may include a dynamic expiration date field 611 and the dynamic verification value (dCVV2) field 612 which will be form-filled with the dynamic expiration date and the dynamic verification value respectively.
- dCVV2 dynamic verification value
- the user 110 will be able to see that fields 611 and 612 are form-filled.
- the user 110 may not see the fields 611 and 612 shown inside the dotted square in payment page 601 .
- the fields 611 and 612 are hidden fields which will be form-filled in the background. This is advantageous because fraudsters cannot determine that these fields exist and such data are used in the payment transaction.
- the CVV2 field 610 and/or expiration date field 609 may be form-filled with fake values (i.e. values different from what is displayed on the portable consumer device 600 ).
- the fields 611 and 612 may or may not be hidden fields. Using fake values is advantageous, because the fraudsters cannot determine whether the fake values shown in the fields 610 or 609 are really used or not.
- the dynamic expiration date field 611 and the dynamic verification value (dCVV2) field 612 may be visible, and in addition the CVV2 field 610 may be form-filled with a fake number. However, when the data are sent to the merchant website 130 , the correct CVV2 value may be used instead of the fake value.
- the Merchant website 130 receives the data from the payment page 601 and generates an authorization request message.
- the authorization request message will include the dynamic expiration date and the dynamic verification value. As discussed before, the authorization request message may also include the actual expiration date and CVV2 or fake expiration date and/or CVV2.
- the authorization request message will be sent to the payment processing network 150 through acquirer 140 .
- the payment processing network 150 may regenerate the dynamic verification value and the dynamic expiration date via the same method used by the IP Gateway 152 and using the comparison module 158 compare the regenerated values with the ones included in the authorization request message.
- the payment processing network 150 may receive the dynamic verification value and the dynamic expiration date from the IP Gateway 152 .
- the comparison module 158 of the payment processing network 150 may compare the values that received from the IP Gateway 152 with the ones that are accompanied with the authorization request message.
- the payment processing network 150 Upon verification of the dynamic verification value and the dynamic expiration date, the payment processing network 150 sends the authorization request message to the issuer 160 .
- the embodiments of the invention have many advantageous. Inclusion of the dynamic verification value and the dynamic expiration date in the payment data used to generate an authorization request message is advantageous in that it is hard for fraudsters gain access to such data or to be able to generate the same values. Moreover, making the dynamic verification value and the dynamic expiration date invisible in a payment page is advantageous because fraudsters will not know that such data are used in a payment transaction. Furthermore, replacing the CVV2 field and/or the expiration date with fake values makes it harder for the fraudsters to accurately determine how such fake values are obtained and if they are actually used in a payment transaction.
- FIG. 7 The various participants and elements of the system shown in FIG. 1 may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in FIG. 1 may use any suitable number of subsystems to facilitate the functions described herein. Examples of such subsystems or components are shown in FIG. 7 .
- the subsystems shown in FIG. 7 are interconnected via a system bus 775 . Additional subsystems such as a printer 774 , keyboard 778 , fixed disk 779 (or other memory comprising computer readable media), monitor 776 , which is coupled to display adapter 782 , and others are shown.
- Peripherals and input/output (I/O) devices which couple to I/O controller 771 , can be connected to the computer system by any number of means known in the art, such as serial port 777 .
- serial port 777 or external interface 781 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner.
- the interconnection via system bus allows the central processor 773 to communicate with each subsystem and to control the execution of instructions from system memory 772 or the fixed disk 779 , as well as the exchange of information between subsystems.
- the system memory 772 and/or the fixed disk 779 may embody a computer readable medium.
- the software components or functions described in this application may be implemented as software code to be executed by one or more processors using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques.
- the software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
- the present invention can be implemented in the form of control logic in software or hardware or a combination of both.
- the control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.
- any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
System and methods for generating a dynamic verification value for electronic payment transactions are disclosed. An account identifier and an account attribute associated with an account of a user are received at a server computer. A dynamic account attribute is created and concatenated with the account identifier. The concatenated account identifier and the dynamic account attribute are then used to generate a dynamic verification value. The dynamic verification value and the dynamic account attribute are then sent to a user communication device and used for authentication in a payment transaction.
Description
- This application is a non-provisional application of and claims priority to U.S. Provisional Application No. 61/312,196, filed on Mar. 9, 2010, the entire disclosure of which is incorporated herein by reference for all purposes.
- There is a need for more secure data transfer when paying for goods and services using payment cards such as debit and credit cards.
- In a typical payment transaction, a user may use a credit card to purchase an item at a merchant or enter his account information into a payment page of a merchant's website. The merchant then generates an authorization request message using a POS (point of sale) terminal when the user is present at the merchant location. Alternatively, for an online transaction, the merchant website may generate an authorization request message for card-not-present (CNP) transactions. In either instance, the authorization request message is passed to the issuer of the credit card, and the issuer may approve or deny the request to authorize the transaction.
- There are a variety of methods by which fraudsters attempt to obtain account information of users for conducting fraudulent transactions. Such transactions are susceptible to “man in the middle” attacks whereby an unauthorized person intercepts information between the merchant and the issuer.
- Embodiments of the invention address these and other problems, individually and collectively.
- Embodiments of the invention disclosed herein include systems and methods for generating dynamic verification values for use in the electronic payment transactions.
- One embodiment of the invention is directed to a method comprising receiving an account identifier (e.g., an account number) and an account attribute (e.g., an expiration date) associated with an account such as a credit card account. The method also includes generating a dynamic account attribute (e.g., a dynamic expiration date) from the account attribute associated with the account, and generating a dynamic verification value (e.g., a dCVV or dynamic card verification value) using the account identifier and the dynamic account attribute. In some embodiments, the generation of the dynamic verification value may include concatenating the account identifier and the dynamic account attribute. The dynamic verification value and, optionally, the dynamic account attribute, can then be used to authenticate the account or a portable consumer device associated with the account.
- Another embodiment of the invention is directed to a method comprising using the concatenated account identifier and the dynamic account attribute as an input into an algorithm that encrypts the concatenated account identifier and the dynamic account attribute using a Master Derivation Key (MDK). The algorithm then generates a Unique Derived Key (UDK).
- Another embodiment of the invention is directed to a method comprising sending an account identifier and an account attribute associated with an account to a server computer, receiving a dynamic verification value and a dynamic account attribute, and sending the dynamic verification value and the dynamic account attribute to a second server computer. The second server computer uses the dynamic verification value and the dynamic account attribute for authentication.
- Another embodiment if the invention is directed to a method including using the dynamic verification value and the dynamic account attribute in an authorization request message.
- These and other embodiments of the invention are described in further detail below.
-
FIG. 1 shows a system according to an embodiment of the invention. -
FIG. 2 shows a user communication device according to an embodiment of the invention. -
FIG. 3 illustrates a flowchart that shows the steps involved in generating a dynamic verification value, according to an embodiment of the invention. -
FIG. 4 illustrates a flowchart that shows the steps involved in concatenating an account identifier with a dynamic expiration date, according to an embodiment of the invention. -
FIG. 5 shows the process of generating a dynamic verification value, according to an embodiment of the invention. -
FIG. 6 illustrates a diagram that shows an example of a portable consumer device and a payment page of a merchant website, according to an embodiment of the invention. -
FIG. 7 shows a block diagram of a computer apparatus according to an embodiment of the invention. - In order to provide more security for electronic transactions, additional security data may be used during the processing of electronic payment transactions. Such data can be generated by an external source and introduced into the transaction process at any point, and then verified by a processing entity or the issuer of the debit or credit card to make sure that the transaction has originated from an authorized source.
- One embodiment of the invention is directed to a method comprising receiving, by a server computer associated with a payment processing network and from a user computer, an account number and an account attribute such as an expiration date associated with an account such as a credit card account. The expiration date and the account number may further be associated with a credit card or other portable consumer device. The method also includes generating, by the server computer, a dynamic account attribute such as a dynamic expiration date from the account attribute associated with the account. In the method, the server computer may also generate a dynamic verification value such as a dCVV or dynamic card verification value using the account identifier and the dynamic account attribute.
- The dynamic verification value and, optionally, the dynamic account attribute, can then be used to authenticate the account or a portable consumer device associated with the account. For example, in some embodiments, the dCVV value and the dynamic expiration date can be entered onto a web page on a merchant's Web site. This data can then be transmitted in an authorization request message from the merchant's website to a payment processing network that is located between many issuers and acquirers. The server computer associated with the payment processing network may then receive the dCVV value and the dynamic expiration date. It may then independently generate the dCVV and the dynamic expiration date and compare it to the dCVV and the dynamic expiration date received from the merchant's website. If they match, then the transaction may then be considered to be authentic.
- An indication of the authenticity of the transaction (e.g., in the form of an authentication score) may then be passed in the authorization request message to the issuer of the account. The issuer of the account may then decide whether or not to authorize the transaction, and may then send an authorization response message back to the merchant website. It may indicate whether or not the issuer approved of the transaction. Then, at the end of the day, a clearing and settlement process can take place.
- Prior to discussing specific embodiments of the invention, a number of terms may be discussed in further detail.
- As used herein, “account identifier” can refer to an identifier for an account. It may comprise any suitable number of characters (e.g., numbers and/or letters) suitable for identifying an account. For example, an account identifier may be a Primary Account Number (PAN) of a credit or debit card. The Primary Account Number (PAN) may include numbers and/or letters and may be in any length. Other examples of account identifiers may include a name of the account holder, an address associated with the account, a phone number associated with an account, a password associated with the account, etc.
- As used herein, “account attribute” can refer to any data that does not change frequently and is relatively static. It may be associated with a portable consumer device such as a payment card. If they change at all, account attributes typically do not change more than once per year. Examples of account attributes may include, without limitation, an expiration date for payment card, an account holder's name, a service code, and a CVV2 or CVV value. In some embodiments, the account attribute includes data that is stored or present on a payment card (e.g., an expiration date or CVV value).
- As used herein, an “authorization request message” may be a message that includes an issuer account identifier. The issuer account identifier may be a payment card account identifier associated with a payment card. The authorization request message may request that an issuer of the payment card authorize a transaction. An authorization request message according to an embodiment of the invention may comply with ISO 8583, which is a standard for systems that exchange electronic transactions made by cardholders using payment cards. In embodiments of the invention, an authorization request message may include, among other data, an account identifier, one or more account attributes, an amount of the transaction (which may be any type and form of a medium of exchange such a money or points), and identification of a merchant (e.g., a merchant verification value or a merchant ID). Typically, an authorization request message is generated by a server computer (if the transaction is an e-commerce transaction) or a Point of Sale (POS) device (if the transaction is a brick and mortar type transaction) and is sent to an issuer via a payment processing network and an acquirer.
- As used herein, “user communication device” can refer to an electronic device capable of communication with other electronic devices. For example, user communication device may be a desktop computer, laptop computer, netbook computer, tablet computer (e.g. iPad), mobile phone, verification token (described in detail later) and any other electronic device that can be coupled to another electronic device either wirelessly or via a direct connection.
- As used herein “dynamic verification value” (e.g., a dynamic device verification value, a dynamic card verification value, and a dCVV2 value) can refer to a value that can be used to verify that a transaction (and in some cases a portable consumer device used to conduct a transaction) is authentic. It may be a numeric or alpha-numeric value that is generated by an algorithm (e.g. encryption algorithm) that uses account data such as account identifier and account attribute as inputs.
- As used herein, a “server computer” is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a web server.
- Embodiments of the invention disclosed herein include systems and methods for dynamically generating a verification value and for utilizing it to verify that a transaction originates from an authorized source and that a portable consumer device (e.g., debit or credit card) or other means used to conduct the transaction is authentic.
- Embodiments of the present invention are able to maintain or improve existing user experiences, minimize the adverse impacts on merchant processes/systems, leverage existing network data transport mechanisms, utilize existing issuer validation infrastructure, support multiple forms of implementation, and maintain consistency with broader authentication strategies.
- Further details regarding dynamic verification values can be found in U.S. patent application Ser. No. 12/712,148, filed on Feb. 24, 2010, U.S. non-provisional application Ser. No. 12/939,963 filed on Nov. 4, 2010, and U.S. non-provisional application Ser. No. 12/878,947, filed on Sep. 9, 2010 which are herein incorporated by reference in their entirety for all purposes.
-
FIG. 1 shows a block diagram illustrating the components of a system according to an embodiment of the invention.FIG. 1 shows auser 110 and aportable consumer device 112 that theuser 110 may use to conduct a payment or other type of transaction. Theuser 110 may also operate amobile device 118, a user computer 120, and averification token 122. When purchasing a good or service from the Internet, the user 120 may contact amerchant website 130 run on aserver computer 131. - Further elements of the system may include an
acquirer 140, apayment processing network 150, anIP Gateway 152, and anissuer 160. The IP Gateway may include an IPGateway server computer 153 while thepayment processing network 150 may include a payment processingnetwork server computer 155. The IPgateway server computer 153 may include a computerreadable medium 154, aprocessor 155, and ageneration module 151. The payment processingnetwork server computer 155 may include adata processor 156, and acomparison module 158. Adatabase 159 may be operatively coupled to theserver computer 155. - As noted above, the
user 110 can use theportable consumer device 112, themobile device 118, and the user computer 120. Theuser 110 interacts with themerchant website 130 using the user computer 120 and/ormobile device 118. Themobile device 118, theverification token 122 and the user computer 120 are capable of communicating with theIP Gateway 152 for requesting and receiving a dynamic verification value (this process will be described in detail later). Themerchant website 130 is in communication with theacquirer 140. Theacquirer 140 is in communication with theissuer 160 through thepayment processing network 150. Thepayment processing network 150 is in communication with theIP Gateway 152. TheIP Gateway 152 has access to the payment processingnetwork server computer 155. - The
user 110 can be an individual or organization such as a business that is capable of purchasing goods or services or making any suitable payment transaction with themerchant website 130. - The
portable consumer device 112 can be any suitable device that can be used to conduct a payment transaction, and may be in any suitable form. For example, suitableportable consumer devices 112 can be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). They may include smart cards, magnetic stripe cards, keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. Other examples ofportable consumer devices 112 include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, and the like. In some cases, theportable consumer device 112 may be associated with an account ofuser 110 such as a bank account. -
Portable consumer device 112 may include acontactless element 114 that includes a processor (not shown), an antenna (not shown), computer readable media (not shown), and one or more applications stored on the computer readable media that operate in concert to allow theportable consumer device 112 to wirelessly send its stored card data to a wireless reader. Thecontactless element 114 provides Near Field Communication (NFC) capability for theportable consumer device 112 such that when theportable consumer device 112 is in close proximity of a wireless reader, the wireless reader powers thecontactless element 114 and collects the card data. - The
mobile device 118 may be in any suitable form. For example, suitablemobile device 118 can be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). Some examples of themobile device 118 include desktop or laptop computers, cellular phones, personal digital assistants (PDAs), pagers, and the like. In some embodiments, themobile device 118 and theportable consumer device 112 can be embodied in the same device. - The user computer 120 may be a personal computer, phone, or a laptop computer. The user computer 120 may run an operating system such as Microsoft Windows™ and may have a suitable browser such as Internet Explorer™.
- The
verification token 122 can be an electronic device configured to be coupled to, or can be present within, the user computer 120 and can be capable of wirelessly receiving card data from theportable consumer device 112. Elements of theverification token 122 and their operation will be described later with reference toFIG. 2 . - The
merchant website 130 may be in the form of a website hosted by one or more server computers (e.g. server computer 131). Theuser 110 is capable of communicating with themerchant website 130 using the user computer 120 and/ormobile device 118. - The
acquirer 140 can be any suitable entity that has an account with a merchant associated with themerchant website 130. In some embodiments, theissuer 160 may also be theacquirer 140. - The
payment processing network 150 can be a network of suitable entities that have information related to an account associated with theportable consumer device 112. This information includes data associated with the account on theportable consumer device 112 such as profile information, data, and other suitable information. Such data may be stored in one or more databases such as thedatabase 159 and may be accessible by one or more server computers such as theserver computer 155. - The
payment processing network 150 may have or operate a server computer and may include a database (e.g. theserver computer 155 and the database 159). The database may include any hardware, software, firmware, or combination of the preceding for storing and facilitating retrieval of information. Also, the database may use any of a variety of data structures, arrangements, and compilations to store and facilitate retrieval of information. The server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. Server computer may comprises one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. - The
payment processing network 150 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplarypayment processing network 150 may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. Thepayment processing network 150 may use any suitable wired or wireless network, including the Internet. - The
IP Gateway 152 can refer to an entity that includes one or more servers such as IPGateway server computer 153. TheIP Gateway 152 may also include one or more databases (not shown), and have access to issuer data, transaction data and user data. This data may be used to authenticate portable consumer devices. TheIP Gateway 152 also generates and delivers notifications and alert messages to various delivery channels. TheIP Gateway 152 may be part of thepayment processing network 150 or may be a separate entity in communication withpayment processing network 150. - The
databases 159 may be server computers that are capable of storing data and responding to queries from client computers. Thedatabase 159 may also be in the form of stand-alone hard drives connected to one or more server computers that retrieve the data from thedatabase 159 as result of queries from client computers. - As used herein a “computer readable medium” or “computer readable storage medium” is typically a storage medium such a hard disk or any suitable type of data storage medium capable of storing data such as program codes.
- The
comparison module 158 can be a software program stored on the computer readable medium, and run by theprocessor 156, that monitors the stream of data in an electronic payment transaction and compare various types of data in the electronic payment transaction such as the dynamic verification value with the same type of data supplied by theIP Gateway 152 or any other entity to make sure the data that are part of the electronic payment transactions are accurate and are originated from an authorized source. - The
generation module 151 can be software program stored on the computerreadable medium 154 and run by theprocessor 155 that generates a dynamic verification value. Thegeneration module 151 may also be embodied as a Hardware Security Module (HSM) that generates a dynamic verification value. - The
issuer 160 can be any suitable entity that may open and maintain an account associated with theportable consumer device 112 for theuser 110. Some examples of issuers may be a bank, a business entity such as a retail store, or a governmental entity. In many cases, theissuer 160 may also issue theportable consumer device 112 associated with the account to theuser 110. -
FIG. 2 is a block diagram illustrating various components of theverification token 122 according to one embodiment. - The embodiment illustrated in
FIG. 2 is a USB device that includes a USB connectivity module 230, a secure element 220 (e.g., a smart card chip), a wireless/contactless reader 210 capable of reading card data (payment data) from a portable consumer device, a built inmemory 240, a self-installingdriver 250, aform fill application 260, aterminal application 270, and aheartbeat application 280. Theverification token 122 may also have other features such as a keyboard buffer capability and a unique serial number associated with the verification token. Theverification token 122 has no footprint on the user computer 120 with internet connectivity when it is plugged in. The various components and modules on theverification token 122 can be used to implement methods according to embodiments of the invention. - Although
FIG. 2 illustrates averification token 122 as something similar to a USB stick, theverification token 122 may come in other forms. For example, it may be piece of hardware or other module installed in a computer, consumer device, or other device. For example, in other embodiments, the verification token may be housed in a computer and need not be a device that is physically separated from the computer. - In a typical transaction process, the
user 110 may take hisportable consumer device 112 and may interact with theverification token 122. For example, theportable consumer device 112 may be a contactless payment card, and the contactless payment card can be placed near the verification token. Information such as the Primary Account Number (PAN) as well as the expiration date may then pass from theportable consumer device 112, to theverification token 122, to the user computer 120, and to theIP Gateway 152. TheIP Gateway 152 may then receive this information, and this may cause theIP Gateway 152 to generate a dynamic verification value. - In the embodiments of the invention, a dynamic verification value may be generated by the
generation module 151 in theserver computer 153 of theIP Gateway 152 and delivered to a user communication device such as the user computer 120/verification token 122 combination, and themobile device 118. In some embodiments, the user communication device that receives the dynamic verification value may be utilized in the process of performing an electronic payment transaction (this process will be described in detail below). In some embodiments, a dynamic verification value may be received by a user communication device (e.g., the mobile device 118) and theuser 110 may manually enter the dynamic verification value in a payment page of a website. - Before or after sending the dynamic verification value to a user communication device, the IP
Gateway server computer 153 may also send the dynamic verification value to the payment processingnetwork server computer 155 in thepayment processing network 150. In one embodiment, thepayment processing network 150 may also contact theIP Gateway 152 to receive the dynamic verification value at any time. A program in the payment processingnetwork server computer 155 associates the dynamic verification value with a corresponding account number associated with theuser 110. The account number of theuser 110 may be issued by theissuer 160. In some embodiments, which will be described in detail later, thepayment processing network 150 may independently generate the dynamic verification value based on the data received in an authorization request message and may then compare the generated dynamic verification value the one that was accompanied by the authorization request message. - When the
user 110 purchases goods or services from themerchant website 130 using the user computer 120, the dynamic verification value is entered in the payment page of themerchant website 130 either automatically via theverification token 122 or manually by theuser 110. After themerchant website 130 receives transaction details including name and address of theuser 110, the account identifier and account attributes, and the payment amount, it then generates an authorization request message which is sent to theacquirer 140. Theacquirer 140 forwards the authorization request message to thepayment processing network 150. - Upon receipt of the authorization request message, the
payment processing network 150 compares the dynamic verification value included in the authorization request message, with the dynamic verification value that was received from the IP Gateway 152 (more specifically, the IP Gateway server computer 153) or the dynamic verification value that thepayment processing network 150 independently generates. This is done via thecomparison module 158 which runs on the payment processingnetwork server computer 155. - The
server computer 155 in thepayment processing network 150 then determines whether the dynamic verification value that was included in the authorization request message matches with the copy that was provided by theIP Gateway 152 or that was generated independently from data that are provided in the authorization request message. In one embodiment, thepayment processing network 150 then forwards the authorization request message to theissuer 160 along with an indicator that specifies whether there was a match between the dynamic verification values. In one embodiment, if the dynamic verification values do not match,payment processing network 150 may decline the transaction on behalf of theissuer 160. Theissuer 160 or thepayment processing network 150 can then generate an authorization response message which indicates whether the transaction is approved or declined. The authorization response message is forwarded to theacquirer 140 and then to themerchant 130. - Two specific embodiments in which the
user 110 may use a user communication device to request and receive a dynamic verification value will now be described. It will be understood by those skilled in the art that other ways may be used to request, receive and use the dynamic verification value to conduct an electronic payment transaction. - Referring to
FIG. 1 , in an embodiment of the invention, theuser 110 may receive averification token 122 such as the one illustrated inFIG. 2 from his or her financial institution (issuer 160, for example). Alternatively, a user may receive averification token 122 from another entity on behalf of a financial institution. - The
user 110 can then connect theverification token 122 to the USB port of his user computer (user computer 120, for example). Theverification token 122 is then powered by the user computer, and it is recognized as a valid device. Theverification token 122 can also self-install via the self-installing driver 250 (shown inFIG. 2 ), and then ping the user computer 120 to check for internet connectivity. - If Internet connectivity is available, the
verification token 122 can then automatically attempt to establish a background SSL session to theIP Gateway 152 through a predefined IP address, using the user computer 120, so that it can be used as a part of an authentication process. Aterminal application 270 andheartbeat application 280 may be used to establish and maintain this connection. If the session connection is successfully established, theverification token 122 identifies itself to theIP Gateway 152 by providing its unique serial number and/or IP address. - When the
user 110 is ready to submit his/her payment information to themerchant website 130, he/she holds theportable consumer device 112 in close proximity of theverification token 122. Card data (i.e. account data) associated with theportable consumer device 112 are received by theverification token 122 from thecontactless element 114 of theportable consumer device 112. Theverification token 122 encrypts the card data and sends them to theIP Gateway 152 via the previously established SSL session described above. When theIP Gateway 152 receives the encrypted data, the authenticity of the information is validated by validating the account number associated with theportable consumer device 112. TheIP Gateway 152 generates a dynamic verification value based on a predetermined algorithm, and sends the dynamic verification value to theverification token 122. The dynamic verification value is automatically form-filled in the payment page of themerchant website 130 by the form-fill application 260 shown inFIG. 2 . - When the dynamic verification value is submitted to the
merchant website 130, themerchant website 130 then generates an authorization request message which is sent to theacquirer 140.Acquirer 140 passes the authorization request to thepayment processing network 150.Payment processing network 150 compares the dynamic verification value that is in the authorization request message from the acquirer 140 (which is received from the merchant website 130) to the dynamic verification value that is received from theIP Gateway 152 or the dynamic verification value that was independently generated by thepayment processing network 150. This is performed by thecomparison module 158. If they match, thepayment processing network 150 sends the authorization request message to theissuer 160. Theissuer 160 generates an authorization response message which indicates whether the transaction is approved or declined. The authorization response message is sent to thepayment processing network 150 which then sends it to theacquirer 140. Theacquirer 140 informs the merchant associated with themerchant website 130 about the result. - In another embodiment, the
user 110 requests and receives the dynamic verification value using themobile device 118. Theuser 110 then initiates a request by sending an SMS from themobile device 118 to theIP Gateway 152. When theIP Gateway 152 receives the request, the phone number and the Primary Account Number (PAN) associated with themobile device 118 are identified. TheIP Gateway 152 then validates the account number associated with theportable consumer device 112 and phone number of themobile device 118. TheIP Gateway 152 generates a dynamic verification value, based on a predetermined algorithm, which is sent to themobile device 118. The mobile device may receive the dynamic verification value via SMS or through application that communicates with the IPGateway server computer 153. The generated dynamic verification value is also sent to thepayment processing network 150. Then,user 110 enters the dynamic verification value at the payment page of themerchant website 130 along with the payment information to purchase goods or services. Themobile device 118 may also have a form-fill application that automatically form-fills the dynamic verification value into a payment page of a web site accessed via themobile device 118. - Generation of a Dynamic Verification Value
- A method of the generating a dynamic verification value will now be described with reference to the Figures. In the embodiments of the invention, the dynamic verification value may be generated from the account identifier (e.g. a Primary Account Number (PAN)), and one or more account attributes (e.g. an expiration date).
FIGS. 3-5 illustrate the process of generating the dynamic verification value according to an embodiment of the invention. As shown inFIG. 3 , in step S301 theIP Gateway 152 receives an account identifier (e.g. the Primary Account Number (PAN)) and an account attribute (e.g. the expiration date) associated with theportable consumer device 112 of theuser 110 from theverification token 122 or themobile device 118. - Optionally, the
IP Gateway 152 verifies that the account identifier and the account attributes such as the expiration date are valid. This step which is not shown in the flowchart of theFIG. 3 , may be performed by thepayment processing network 150 at the time of receiving an authorization request message. - In step S302, the
IP Gateway 152 generates a dynamic expiration date from the expiration date associated with theportable consumer device 112. In step S303, the account identifier (e.g. the Primary Account Number (PAN)) is concatenated with an account attribute (e.g. the expiration date). - This process is further illustrated in the flowchart of
FIG. 4 . InFIG. 4 , an example of an account identifier in the form of a 16-digit Primary Account Number (PAN) and an account attribute in the form of the expiration date are shown. In step S401 the Primary Account Number (PAN) and an expiration date associated with a portable consumer device are obtained. At step S402 a dynamic expiration date is generated from the expiration date, and at step S403 the dynamic expiration date is concatenated with the Primary Account Number (PAN). In some embodiments, the dynamic expiration date may be generated via an algorithm that accepts the expiration date as an input and uses a predetermined formula to generate a dynamic expiration date. - Referring back to
FIG. 3 , at step S304 the concatenated account identifier (e.g. Primary Account Number (PAN)) and the dynamic account attribute (e.g. dynamic expiration date) are inputted into a key derivation algorithm. In step S305, a Unique Derived Key (UDK) that is obtained from the key derivation algorithm is inputted into another algorithm that generates a dynamic verification value. The dynamic verification value is then provided to theverification token 122 or themobile device 118. - The process described in steps S304 and S305 in
FIG. 3 will now be described in detail with reference toFIG. 5 . As shown inFIG. 5 , thedata string 501 which may be formed by concatenation of the account identifier (e.g. the Primary Account Number (PAN)) and the dynamic account attribute (e.g. dynamic expiration date) can be altered (i.e. encrypted) to form a Unique Derived Key (UDK) 504. In this process, which is referred to as the key derivation process, thedata string 501 is inputted into a data encryption algorithm 503 (also referred to as the key derivation algorithm) such as DES or triple-DES, for example. The Master Derivation Key (MDK) 502 is then used to encrypt thedata string 501. The value resulting from theencryption algorithm 503 is the Unique Derived Key (UDK) 504. - In some embodiments, the
data string 501 may be formed from concatenation of more than two types of account data. For example,data string 501 may be formed by concatenating the Primary Account Number (PAN), a sequence number which changes with each transaction and the dynamic expiration date. Utilization of more account data to form thedata string 501 results in a more complex and secure Unique Derived Key (UDK) 504. Although concatenation of an account identifier and an account attribute are described in detail, embodiments of the invention are not limited to concatenation and such data elements can merely be used as inputs to form a dynamic verification value. - In some embodiments, the
data encryption algorithm 503 may not be able to accepts an input that is larger than a pre-determined number of bits/bytes. In such embodiments, thedata string 501 may be truncated as needed. In some other embodiments, the data encryption algorithm may expect an input that is larger than a pre-determined bits/bytes. In such embodiments, thedata string 501 may be padded with zeros at either end. - The Unique Derived Key (UDK) 504 and a
data encryption algorithm 506 can be used to alter (i.e. encrypt) a second data string (e.g. data string 505 “input X”). Thedata encryption algorithm 506 may be the same type of algorithm as thedata encryption algorithm 503 or may be any other suitable encryption algorithm.Data string 505 may be the same asdata string 501 or may be any other suitable data string. In one example,data string 505 may be the account identifier (i.e. Primary Account Number (PAN)) of the portable consumer device of the user. Thedata string 505 is then encrypted via Unique Derived Key (UDK) 504 to form the data string 507 (i.e., output X′). The resultingdata string 507 is then altered via thealgorithm 508 to form adynamic verification value 509. - The
algorithm 508 may be any suitable algorithm and may perform a suitable alteration process on the resultingdata string 509. For example, thealgorithm 508 may take the last 32 bits of data (i.e. 4 digits) from thedata string 507 as the dynamic verification value. - Performing a Payment Transaction
- The method of performing a payment transaction will now be described with reference to the figures.
FIG. 6 shows theportable consumer device 600 and thepayment page 601. - The
payment page 601 is a payment page of a website from which theuser 110 whishes to purchase goods or services. Thepayment page 601 may be accessed by using user computer 120. After choosing the goods or services, theuser 110 is directed to thepayment page 601 to provide the information needed to perform a payment transaction. In a typical payment transaction, the information in fields 602-610 are automatically form-filled viaverification token 122. As shown inFIG. 6 , these information include:first name 602,last name 603,street address 604,city 605,state 606,zip code 607,account number 608,expiration date 609 and card verification value (CVV2) 610.FIG. 6 also shows twoadditional fields - The
portable consumer device 600 may be embodied as data stored on a user communication device such as a mobile device. For example, a mobile device may contain an application that stores the account number, expiration date, security code and any other data needed to perform a payment transaction. Furthermore, the mobile device may be capable of Near Field Communication (NFC) with theverification token 122. Therefore, the example of theportable consumer device 600 shown inFIG. 6 as a credit/debit card is not intended to be limiting. - As described before, the
user 110 can bring his portable consumer device (e.g. portable consumer device 600) in close proximity of theverification token 122 and theverification token 122 receives the account data including an account identifier (e.g. Primary Account Number (PAN)) and an account attribute (e.g. expiration date) from the portable consumer device of theuser 110 and sends the account identifier and the account attribute, among other account data, to the IPGateway server computer 153 and requests a dynamic verification value. - As described above, the
generation module 151 of the IPGateway server computer 153 then generates a dynamic verification value and a dynamic expiration date which are sent from the IPGateway server computer 153 to theverification token 122. - At this point, the dynamic verification value and the dynamic expiration date can be form-filled and/or included in the payment information in
payment page 601 in several ways which will now be described in detail. - In some embodiments, In addition to the
expiration date field 609 and theCVV2 field 610, thepayment page 601 may include a dynamicexpiration date field 611 and the dynamic verification value (dCVV2)field 612 which will be form-filled with the dynamic expiration date and the dynamic verification value respectively. In such embodiments, theuser 110 will be able to see thatfields - In some embodiments, the
user 110 may not see thefields payment page 601. In such embodiments, thefields - In some embodiments, the
CVV2 field 610 and/orexpiration date field 609 may be form-filled with fake values (i.e. values different from what is displayed on the portable consumer device 600). In such embodiments, thefields fields - In one example, the dynamic
expiration date field 611 and the dynamic verification value (dCVV2)field 612 may be visible, and in addition theCVV2 field 610 may be form-filled with a fake number. However, when the data are sent to themerchant website 130, the correct CVV2 value may be used instead of the fake value. - In this example, even if a fraudster can determine the data that are form-filled in the
payment page 601, he is not aware that in the background, other values may be actually sent to themerchant website 130. Therefore, the fraudster will not be able to perform an unauthorized payment transaction. - When the
user 110 clicks on the submit or “Make Payment” button on thepayment page 601, the data that are form-filled in thepayment page 601 including the fields that may not be visible, are sent to themerchant website 130. -
Merchant website 130 receives the data from thepayment page 601 and generates an authorization request message. The authorization request message will include the dynamic expiration date and the dynamic verification value. As discussed before, the authorization request message may also include the actual expiration date and CVV2 or fake expiration date and/or CVV2. - The authorization request message will be sent to the
payment processing network 150 throughacquirer 140. Thepayment processing network 150 may regenerate the dynamic verification value and the dynamic expiration date via the same method used by theIP Gateway 152 and using thecomparison module 158 compare the regenerated values with the ones included in the authorization request message. - In some embodiments, the
payment processing network 150 may receive the dynamic verification value and the dynamic expiration date from theIP Gateway 152. In such embodiments, thecomparison module 158 of thepayment processing network 150 may compare the values that received from theIP Gateway 152 with the ones that are accompanied with the authorization request message. - Upon verification of the dynamic verification value and the dynamic expiration date, the
payment processing network 150 sends the authorization request message to theissuer 160. - It can be appreciated that the embodiments of the invention have many advantageous. Inclusion of the dynamic verification value and the dynamic expiration date in the payment data used to generate an authorization request message is advantageous in that it is hard for fraudsters gain access to such data or to be able to generate the same values. Moreover, making the dynamic verification value and the dynamic expiration date invisible in a payment page is advantageous because fraudsters will not know that such data are used in a payment transaction. Furthermore, replacing the CVV2 field and/or the expiration date with fake values makes it harder for the fraudsters to accurately determine how such fake values are obtained and if they are actually used in a payment transaction.
- The various participants and elements of the system shown in
FIG. 1 may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements inFIG. 1 may use any suitable number of subsystems to facilitate the functions described herein. Examples of such subsystems or components are shown inFIG. 7 . The subsystems shown inFIG. 7 are interconnected via asystem bus 775. Additional subsystems such as aprinter 774,keyboard 778, fixed disk 779 (or other memory comprising computer readable media), monitor 776, which is coupled todisplay adapter 782, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 771, can be connected to the computer system by any number of means known in the art, such asserial port 777. For example,serial port 777 orexternal interface 781 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows thecentral processor 773 to communicate with each subsystem and to control the execution of instructions fromsystem memory 772 or the fixeddisk 779, as well as the exchange of information between subsystems. Thesystem memory 772 and/or the fixeddisk 779 may embody a computer readable medium. - The software components or functions described in this application may be implemented as software code to be executed by one or more processors using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
- The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.
- In embodiments, any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.
- Any recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
- The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
Claims (20)
1. A computer apparatus comprising:
a computer readable medium;
a processor coupled to the computer readable medium; wherein the processor is configured to execute program code stored on the computer readable medium to implement a method comprising:
receiving an account identifier and an account attribute associated with an account;
generating a dynamic account attribute from the account attribute associated with the account;
generating a dynamic verification value using the account identifier and the dynamic account attribute; and
providing the dynamic verification value and the dynamic account attribute to a verification token, wherein the dynamic verification value and the dynamic account attribute are used for authentication.
2. The system of claim 1 , wherein the account identifier is a Primary Account Number (PAN) associated with the account, and wherein generating the dynamic verification value comprises concatenating the account identifier and the account attribute.
3. The system of claim 2 , wherein the Primary Account Number (PAN) is associated with a portable consumer device.
4. The system of claim 1 , where in the account attribute is an expiration date associated with a portable consumer device.
5. The system of claim 1 , wherein the account attribute is selected from any one of a birthday and personal identification number of a user associated with the account.
6. The system of claim 1 , wherein the account identifier and the dynamic account attribute are used as input for an algorithm that encrypts the concatenated account identifier and the dynamic account attribute using a Master Derivation Key (MDK).
7. The system of claim 1 , wherein the account identifier and the dynamic account attribute are used as an input for an algorithm that generates a Unique Derived Key (UDK).
8. The system of claim 7 , wherein the Unique Derived Key (UDK) is used for generating a dynamic verification value.
9. A method comprising:
receiving an account identifier and an account attribute associated with an account;
generating a dynamic account attribute from the account attribute associated with the account;
generating a dynamic verification value using the account identifier and the dynamic account attribute; and
providing the dynamic verification value and the dynamic account attribute to a verification token, wherein the dynamic verification value and the dynamic account attribute are used for authentication.
10. The method of claim 9 , wherein the account identifier is a Primary Account Number (PAN) associated with the account, and wherein generating the dynamic verification value comprises concatenating the account identifier and the account attribute.
11. The method of claim 10 , wherein the Primary Account Number (PAN) is associated with a portable consumer device.
12. The method of claim 9 , wherein the account attribute is an expiration date associated with a portable consumer device.
13. The method of claim 9 , wherein the account identifier and the dynamic account attribute are used as input for an algorithm that encrypts the concatenated account identifier and the dynamic account attribute using a Master Derivation Key (MDK).
14. The method of claim 9 , wherein the account identifier and the dynamic account attribute are used as an input for an algorithm that generates a Unique Derived Key (UDK).
15. The method of claim 14 , wherein the Unique Derived Key (UDK) is used for generating a dynamic verification value.
16. A method comprising:
sending an account identifier and an account attribute associated with an account to a first server computer.
receiving a dynamic verification value and a dynamic account attribute; and
sending the dynamic verification value and the dynamic account attribute to a second server computer, wherein the second server computer uses the dynamic verification value an the dynamic account attribute for authentication.
17. The method of claim 16 , wherein the dynamic verification value and the dynamic account attribute are automatically form-filled into a payment page of a website automatically.
18. The method of claim 16 , wherein the dynamic verification value and the dynamic account attribute are used to generate an authorization request message.
19. The method of claim 16 , wherein the account identifier is a Primary Account Number (PAN) associated with the account.
20. The method of claim 16 , wherein the account attribute is an expiration date associated with a portable consumer device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/038,181 US20110225094A1 (en) | 2010-03-09 | 2011-03-01 | System and method including dynamic verification value |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US31219610P | 2010-03-09 | 2010-03-09 | |
US13/038,181 US20110225094A1 (en) | 2010-03-09 | 2011-03-01 | System and method including dynamic verification value |
Publications (1)
Publication Number | Publication Date |
---|---|
US20110225094A1 true US20110225094A1 (en) | 2011-09-15 |
Family
ID=44560862
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/038,268 Active 2034-01-07 US10430794B2 (en) | 2010-03-09 | 2011-03-01 | System and method including customized linkage rules in payment transactions |
US13/038,181 Abandoned US20110225094A1 (en) | 2010-03-09 | 2011-03-01 | System and method including dynamic verification value |
US16/550,575 Active 2031-08-17 US11232455B2 (en) | 2010-03-09 | 2019-08-26 | System and method including customized linkage rules in payment transactions |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/038,268 Active 2034-01-07 US10430794B2 (en) | 2010-03-09 | 2011-03-01 | System and method including customized linkage rules in payment transactions |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/550,575 Active 2031-08-17 US11232455B2 (en) | 2010-03-09 | 2019-08-26 | System and method including customized linkage rules in payment transactions |
Country Status (4)
Country | Link |
---|---|
US (3) | US10430794B2 (en) |
AU (1) | AU2011224755A1 (en) |
CA (1) | CA2792364A1 (en) |
WO (2) | WO2011112394A2 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120072296A1 (en) * | 2010-09-22 | 2012-03-22 | James Sinton | Methods and systems for initiating a financial transaction by a cardholder device |
US20120221466A1 (en) * | 2011-02-28 | 2012-08-30 | Thomas Finley Look | Method for improved financial transactions |
US20130110658A1 (en) * | 2011-05-05 | 2013-05-02 | Transaction Network Services, Inc. | Systems and methods for enabling mobile payments |
US20130282581A1 (en) * | 2012-04-18 | 2013-10-24 | Infosys Limited | Mobile device-based cardless financial transactions |
US20140067675A1 (en) * | 2012-09-06 | 2014-03-06 | American Express Travel Related Services Company, Inc. | Authentication using dynamic codes |
US20140330727A1 (en) * | 2011-10-12 | 2014-11-06 | Technology Business Management Limited | ID Authentication |
US20150142570A1 (en) * | 2011-07-28 | 2015-05-21 | Iii Holdings 1, Llc | Systems and methods for generating and using a digital pass |
US20170116609A1 (en) * | 2015-10-27 | 2017-04-27 | Ingenico Group | Method for securing transactional data processing, corresponding terminal and computer program |
US20200167767A1 (en) * | 2018-11-28 | 2020-05-28 | Mastercard International Incorporated | Security and authentication of interaction data |
CN112585638A (en) * | 2018-08-17 | 2021-03-30 | 维萨国际服务协会 | Techniques for secure transfer of sensitive data |
US20210117967A1 (en) * | 2019-10-18 | 2021-04-22 | Mastercard International Incorporated | Authentication for secure transactions in a multi-server environment |
US11080692B2 (en) * | 2016-04-12 | 2021-08-03 | Visa Europe Limited | System for performing a validity check of a user device |
US11232455B2 (en) | 2010-03-09 | 2022-01-25 | Visa International Service Association | System and method including customized linkage rules in payment transactions |
US20220270086A1 (en) * | 2013-05-15 | 2022-08-25 | Visa International Service Association | Mobile Tokenization Hub Using Dynamic Identity Information |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8433288B2 (en) * | 2011-09-13 | 2013-04-30 | Bank Of America Corporation | Multilevel authentication |
US9204298B2 (en) | 2011-09-13 | 2015-12-01 | Bank Of America Corporation | Multilevel authentication |
US9203819B2 (en) * | 2012-01-18 | 2015-12-01 | OneID Inc. | Methods and systems for pairing devices |
US11080700B2 (en) | 2015-01-19 | 2021-08-03 | Royal Bank Of Canada | Secure processing of electronic payments |
US11210648B2 (en) | 2012-10-17 | 2021-12-28 | Royal Bank Of Canada | Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments |
CA2830260C (en) * | 2012-10-17 | 2021-10-12 | Royal Bank Of Canada | Virtualization and secure processing of data |
US11080701B2 (en) | 2015-07-02 | 2021-08-03 | Royal Bank Of Canada | Secure processing of electronic payments |
US20150081545A1 (en) * | 2013-09-18 | 2015-03-19 | Greg Gissler | Secure payment by mobile phone |
WO2015124968A1 (en) * | 2014-02-21 | 2015-08-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Traffic steering in a wlan based on transit power control |
US10176542B2 (en) * | 2014-03-24 | 2019-01-08 | Mastercard International Incorporated | Systems and methods for identity validation and verification |
US10373153B2 (en) * | 2014-07-03 | 2019-08-06 | Mastercard International Incorporated | Method and system for maintaining privacy and compliance in the use of account reissuance data |
CN107004190A (en) | 2014-10-10 | 2017-08-01 | 加拿大皇家银行 | System for handling electronic transaction |
US9680816B2 (en) * | 2014-10-14 | 2017-06-13 | Cisco Technology, Inc. | Attesting authenticity of infrastructure modules |
US11354651B2 (en) | 2015-01-19 | 2022-06-07 | Royal Bank Of Canada | System and method for location-based token transaction processing |
US11599879B2 (en) | 2015-07-02 | 2023-03-07 | Royal Bank Of Canada | Processing of electronic transactions |
US9633659B1 (en) * | 2016-01-20 | 2017-04-25 | Motorola Mobility Llc | Method and apparatus for voice enrolling an electronic computing device |
CN107451136A (en) * | 2016-05-30 | 2017-12-08 | 阿里巴巴集团控股有限公司 | Verification of data method and device |
US11131976B2 (en) * | 2016-07-12 | 2021-09-28 | Tencent Technology (Shenzhen) Company Limited | Device control system, method and apparatus, and gateways |
GB2599057B (en) * | 2017-02-03 | 2022-09-21 | Worldpay Ltd | Terminal for conducting electronic transactions |
US10935425B2 (en) * | 2017-07-18 | 2021-03-02 | Shimadzu Corporation | Spectroscopic detector |
US20190114598A1 (en) * | 2017-10-18 | 2019-04-18 | Mastercard International Incorporated | Payment network as a platform |
US10972481B2 (en) * | 2018-06-07 | 2021-04-06 | Sap Se | Web application session security |
US10992759B2 (en) | 2018-06-07 | 2021-04-27 | Sap Se | Web application session security with protected session identifiers |
CN109711847B (en) * | 2018-12-26 | 2020-05-15 | 巽腾(广东)科技有限公司 | Near field information authentication method and device, electronic equipment and computer storage medium |
US11030293B2 (en) * | 2018-12-31 | 2021-06-08 | Beijing Didi Infinity Technology And Development Co., Ltd. | Method and system for configurable device fingerprinting |
US11263643B2 (en) * | 2019-08-27 | 2022-03-01 | Coupang Corp. | Computer-implemented method for detecting fraudulent transactions using locality sensitive hashing and locality outlier factor algorithms |
Citations (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030126094A1 (en) * | 2001-07-11 | 2003-07-03 | Fisher Douglas C. | Persistent dynamic payment service |
US6609113B1 (en) * | 1999-05-03 | 2003-08-19 | The Chase Manhattan Bank | Method and system for processing internet payments using the electronic funds transfer network |
US20040073688A1 (en) * | 2002-09-30 | 2004-04-15 | Sampson Scott E. | Electronic payment validation using Transaction Authorization Tokens |
US20050043997A1 (en) * | 2003-08-18 | 2005-02-24 | Sahota Jagdeep Singh | Method and system for generating a dynamic verification value |
US20060229978A1 (en) * | 2005-04-05 | 2006-10-12 | Dxstorm.Com Inc. | Electronic balance checking and credit approval system for use in conducting electronic transactions |
US20070294182A1 (en) * | 2006-06-19 | 2007-12-20 | Ayman Hammad | Track data encryption |
US20080029593A1 (en) * | 2003-08-18 | 2008-02-07 | Ayman Hammad | Method and System for Generating a Dynamic Verification Value |
US20080054079A1 (en) * | 2005-05-09 | 2008-03-06 | Mullen Jeffrey D | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US20080288405A1 (en) * | 2007-05-20 | 2008-11-20 | Michael Sasha John | Systems and Methods for Automatic and Transparent Client Authentication and Online Transaction Verification |
US20090150269A1 (en) * | 1999-11-05 | 2009-06-11 | American Express Travel Related Services Company, Inc. | Systems and Methods for Approval of an Allocation |
US20090210712A1 (en) * | 2008-02-19 | 2009-08-20 | Nicolas Fort | Method for server-side detection of man-in-the-middle attacks |
US7584153B2 (en) * | 2004-03-15 | 2009-09-01 | Qsecure, Inc. | Financial transactions with dynamic card verification values |
US20090255987A1 (en) * | 2008-04-14 | 2009-10-15 | Avenida Diagonal 477, S.L. | Method of authorising a transaction between a computer and a remote server and communications system, with improved security |
US20090271211A1 (en) * | 2008-04-29 | 2009-10-29 | Ayman Hammad | Device including user exclusive data tag |
US20090313168A1 (en) * | 2008-06-16 | 2009-12-17 | Visa U.S.A. Inc. | System and Method for Authorizing Financial Transactions with Online Merchants |
US20090319430A1 (en) * | 2008-06-24 | 2009-12-24 | Patrick Faith | Mobile phone including dynamic verification value |
US20100027786A1 (en) * | 2008-02-14 | 2010-02-04 | Patrick Faith | Dynamic encryption authentication |
US20100088752A1 (en) * | 2008-10-03 | 2010-04-08 | Vikram Nagulakonda | Identifier Binding for Automated Web Processing |
US7720756B2 (en) * | 2000-01-25 | 2010-05-18 | Kavounas Gregory T | Methods, devices and bank computers for consumers using communicators to wire funds to sellers and vending machines |
US20100133335A1 (en) * | 2008-11-28 | 2010-06-03 | Hazem Abdel Maguid | System and method for mobile payment |
US20100293382A1 (en) * | 2009-05-15 | 2010-11-18 | Ayman Hammad | Verification of portable consumer devices |
US20100299267A1 (en) * | 2009-05-20 | 2010-11-25 | Patrick Faith | Device including encrypted data for expiration date and verification value creation |
US20100318783A1 (en) * | 2009-06-10 | 2010-12-16 | Ashwin Raj | Service activation using algorithmically defined key |
US7877325B2 (en) * | 1999-11-05 | 2011-01-25 | American Express Travel Related Services Company, Inc. | Systems and methods for settling an allocation of an amount between transaction accounts |
US8121945B2 (en) * | 2006-07-06 | 2012-02-21 | Firethorn Mobile, Inc. | Methods and systems for payment method selection by a payee in a mobile environment |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5724423A (en) * | 1995-09-18 | 1998-03-03 | Telefonaktiebolaget Lm Ericsson | Method and apparatus for user authentication |
US7707120B2 (en) | 2002-04-17 | 2010-04-27 | Visa International Service Association | Mobile account authentication service |
KR101140223B1 (en) * | 2005-08-19 | 2012-04-26 | 주식회사 비즈모델라인 | Device for Processing a Payment |
US7814787B2 (en) | 2006-09-20 | 2010-10-19 | Itt Manufacturing Enterprises, Inc. | Combined oil level or condition sensor and sight oil level gage |
US20090106148A1 (en) * | 2007-10-17 | 2009-04-23 | Christian Prada | Pre-paid financial system |
US8099368B2 (en) * | 2008-11-08 | 2012-01-17 | Fonwallet Transaction Solutions, Inc. | Intermediary service and method for processing financial transaction data with mobile device confirmation |
WO2011112394A2 (en) | 2010-03-09 | 2011-09-15 | Visa International Service Association | System and method including dynamic verification value |
US8364594B2 (en) | 2010-03-09 | 2013-01-29 | Visa International Service Association | System and method including security parameters used for generation of verification value |
-
2011
- 2011-03-01 WO PCT/US2011/026747 patent/WO2011112394A2/en active Application Filing
- 2011-03-01 AU AU2011224755A patent/AU2011224755A1/en not_active Abandoned
- 2011-03-01 US US13/038,268 patent/US10430794B2/en active Active
- 2011-03-01 CA CA2792364A patent/CA2792364A1/en not_active Abandoned
- 2011-03-01 US US13/038,181 patent/US20110225094A1/en not_active Abandoned
- 2011-03-01 WO PCT/US2011/026757 patent/WO2011112396A2/en active Application Filing
-
2019
- 2019-08-26 US US16/550,575 patent/US11232455B2/en active Active
Patent Citations (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6609113B1 (en) * | 1999-05-03 | 2003-08-19 | The Chase Manhattan Bank | Method and system for processing internet payments using the electronic funds transfer network |
US7877325B2 (en) * | 1999-11-05 | 2011-01-25 | American Express Travel Related Services Company, Inc. | Systems and methods for settling an allocation of an amount between transaction accounts |
US20090150269A1 (en) * | 1999-11-05 | 2009-06-11 | American Express Travel Related Services Company, Inc. | Systems and Methods for Approval of an Allocation |
US7899744B2 (en) * | 1999-11-05 | 2011-03-01 | American Express Travel Related Services Company, Inc. | Systems and methods for approval of an allocation |
US7720756B2 (en) * | 2000-01-25 | 2010-05-18 | Kavounas Gregory T | Methods, devices and bank computers for consumers using communicators to wire funds to sellers and vending machines |
US20030126094A1 (en) * | 2001-07-11 | 2003-07-03 | Fisher Douglas C. | Persistent dynamic payment service |
US20040073688A1 (en) * | 2002-09-30 | 2004-04-15 | Sampson Scott E. | Electronic payment validation using Transaction Authorization Tokens |
US20080029593A1 (en) * | 2003-08-18 | 2008-02-07 | Ayman Hammad | Method and System for Generating a Dynamic Verification Value |
US7761374B2 (en) * | 2003-08-18 | 2010-07-20 | Visa International Service Association | Method and system for generating a dynamic verification value |
US20050043997A1 (en) * | 2003-08-18 | 2005-02-24 | Sahota Jagdeep Singh | Method and system for generating a dynamic verification value |
US7584153B2 (en) * | 2004-03-15 | 2009-09-01 | Qsecure, Inc. | Financial transactions with dynamic card verification values |
US20060229978A1 (en) * | 2005-04-05 | 2006-10-12 | Dxstorm.Com Inc. | Electronic balance checking and credit approval system for use in conducting electronic transactions |
US20080054079A1 (en) * | 2005-05-09 | 2008-03-06 | Mullen Jeffrey D | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US20080065555A1 (en) * | 2005-05-09 | 2008-03-13 | Mullen Jeffrey D | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US20080040276A1 (en) * | 2006-06-19 | 2008-02-14 | Ayman Hammad | Transaction Authentication Using Network |
US7810165B2 (en) * | 2006-06-19 | 2010-10-05 | Visa U.S.A. Inc. | Portable consumer device configured to generate dynamic authentication data |
US20080034221A1 (en) * | 2006-06-19 | 2008-02-07 | Ayman Hammad | Portable consumer device configured to generate dynamic authentication data |
US20070294182A1 (en) * | 2006-06-19 | 2007-12-20 | Ayman Hammad | Track data encryption |
US8121945B2 (en) * | 2006-07-06 | 2012-02-21 | Firethorn Mobile, Inc. | Methods and systems for payment method selection by a payee in a mobile environment |
US20080288405A1 (en) * | 2007-05-20 | 2008-11-20 | Michael Sasha John | Systems and Methods for Automatic and Transparent Client Authentication and Online Transaction Verification |
US20100027786A1 (en) * | 2008-02-14 | 2010-02-04 | Patrick Faith | Dynamic encryption authentication |
US20090210712A1 (en) * | 2008-02-19 | 2009-08-20 | Nicolas Fort | Method for server-side detection of man-in-the-middle attacks |
US20090255987A1 (en) * | 2008-04-14 | 2009-10-15 | Avenida Diagonal 477, S.L. | Method of authorising a transaction between a computer and a remote server and communications system, with improved security |
US20090271211A1 (en) * | 2008-04-29 | 2009-10-29 | Ayman Hammad | Device including user exclusive data tag |
US20090313168A1 (en) * | 2008-06-16 | 2009-12-17 | Visa U.S.A. Inc. | System and Method for Authorizing Financial Transactions with Online Merchants |
US20090319430A1 (en) * | 2008-06-24 | 2009-12-24 | Patrick Faith | Mobile phone including dynamic verification value |
US20090319784A1 (en) * | 2008-06-24 | 2009-12-24 | Patrick Faith | Dynamic verification value system and method |
US20100088752A1 (en) * | 2008-10-03 | 2010-04-08 | Vikram Nagulakonda | Identifier Binding for Automated Web Processing |
US20100133335A1 (en) * | 2008-11-28 | 2010-06-03 | Hazem Abdel Maguid | System and method for mobile payment |
US20100293382A1 (en) * | 2009-05-15 | 2010-11-18 | Ayman Hammad | Verification of portable consumer devices |
US20100299267A1 (en) * | 2009-05-20 | 2010-11-25 | Patrick Faith | Device including encrypted data for expiration date and verification value creation |
US20100318783A1 (en) * | 2009-06-10 | 2010-12-16 | Ashwin Raj | Service activation using algorithmically defined key |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11232455B2 (en) | 2010-03-09 | 2022-01-25 | Visa International Service Association | System and method including customized linkage rules in payment transactions |
US9805348B2 (en) * | 2010-09-22 | 2017-10-31 | Mastercard International Incorporated | Methods and systems for initiating a financial transaction by a cardholder device |
US11379807B2 (en) * | 2010-09-22 | 2022-07-05 | Mastercard International Incorporated | Methods and systems for initiating a financial transaction by a cardholder device |
US20180053166A1 (en) * | 2010-09-22 | 2018-02-22 | Mastercard International Incorporated | Methods and systems for initiating a financial transaction by a cardholder device |
US20120072296A1 (en) * | 2010-09-22 | 2012-03-22 | James Sinton | Methods and systems for initiating a financial transaction by a cardholder device |
US20120221466A1 (en) * | 2011-02-28 | 2012-08-30 | Thomas Finley Look | Method for improved financial transactions |
US20130110658A1 (en) * | 2011-05-05 | 2013-05-02 | Transaction Network Services, Inc. | Systems and methods for enabling mobile payments |
US20150142570A1 (en) * | 2011-07-28 | 2015-05-21 | Iii Holdings 1, Llc | Systems and methods for generating and using a digital pass |
US9916582B2 (en) * | 2011-07-28 | 2018-03-13 | Iii Holdings 1, Llc | Systems and methods for generating and using a digital pass |
US20140330727A1 (en) * | 2011-10-12 | 2014-11-06 | Technology Business Management Limited | ID Authentication |
US9805364B2 (en) * | 2011-10-12 | 2017-10-31 | Technology Business Management Limited | ID authentication |
US20130282581A1 (en) * | 2012-04-18 | 2013-10-24 | Infosys Limited | Mobile device-based cardless financial transactions |
US20140067675A1 (en) * | 2012-09-06 | 2014-03-06 | American Express Travel Related Services Company, Inc. | Authentication using dynamic codes |
US20220270086A1 (en) * | 2013-05-15 | 2022-08-25 | Visa International Service Association | Mobile Tokenization Hub Using Dynamic Identity Information |
US11861607B2 (en) * | 2013-05-15 | 2024-01-02 | Visa International Service Association | Mobile tokenization hub using dynamic identity information |
EP3163487A1 (en) * | 2015-10-27 | 2017-05-03 | Ingenico Group | Method, terminal, and computer program for securing the processing of transactional data |
US20170116609A1 (en) * | 2015-10-27 | 2017-04-27 | Ingenico Group | Method for securing transactional data processing, corresponding terminal and computer program |
US11625713B2 (en) * | 2015-10-27 | 2023-04-11 | Banks And Acquirers International Holding | Method for securing transactional data processing, corresponding terminal and computer program |
FR3042894A1 (en) * | 2015-10-27 | 2017-04-28 | Ingenico Group | METHOD FOR SECURING TRANSACTION DATA PROCESSING, TERMINAL AND CORRESPONDING COMPUTER PROGRAM |
US11720889B2 (en) | 2016-04-12 | 2023-08-08 | Visa Europe Limited | System for performing a validity check of a user device |
US11080692B2 (en) * | 2016-04-12 | 2021-08-03 | Visa Europe Limited | System for performing a validity check of a user device |
CN112585638A (en) * | 2018-08-17 | 2021-03-30 | 维萨国际服务协会 | Techniques for secure transfer of sensitive data |
US20210326866A1 (en) * | 2018-08-17 | 2021-10-21 | Visa International Service Association | Techniques For Securely Communicating Sensitive Data |
US20200167767A1 (en) * | 2018-11-28 | 2020-05-28 | Mastercard International Incorporated | Security and authentication of interaction data |
US20210117967A1 (en) * | 2019-10-18 | 2021-04-22 | Mastercard International Incorporated | Authentication for secure transactions in a multi-server environment |
US11734683B2 (en) * | 2019-10-18 | 2023-08-22 | Mastercard International Incorporated | Authentication for secure transactions in a multi-server environment |
Also Published As
Publication number | Publication date |
---|---|
US11232455B2 (en) | 2022-01-25 |
WO2011112396A2 (en) | 2011-09-15 |
WO2011112396A3 (en) | 2012-01-12 |
WO2011112394A2 (en) | 2011-09-15 |
CA2792364A1 (en) | 2011-09-15 |
US10430794B2 (en) | 2019-10-01 |
WO2011112394A3 (en) | 2012-01-05 |
US20190378138A1 (en) | 2019-12-12 |
US20110225090A1 (en) | 2011-09-15 |
AU2011224755A1 (en) | 2012-09-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11232455B2 (en) | System and method including customized linkage rules in payment transactions | |
US11107053B2 (en) | System and method for securely validating transactions | |
US10313321B2 (en) | Tokenization of co-network accounts | |
US8364594B2 (en) | System and method including security parameters used for generation of verification value | |
AU2016245988B2 (en) | Browser integration with cryptogram | |
US10909539B2 (en) | Enhancements to transaction processing in a secure environment using a merchant computer | |
EP3910908A1 (en) | Unique code for token verification | |
CN115187242A (en) | Unique token authentication verification value | |
AU2015204913A1 (en) | Encrypted payment transactions | |
CA3016858C (en) | Tokenization of co-network accounts | |
US20210326866A1 (en) | Techniques For Securely Communicating Sensitive Data | |
EP4416669A1 (en) | Efficient and protected data transfer system and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VISA INTERNATIONAL SERVICE ASSOCIATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HAMMAD, AYMAN;REEL/FRAME:025890/0356 Effective date: 20110222 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |