Secure remote interaction using portable transaction device

Abstract

An example communication device receives transaction data associated with an e-commerce transaction. The communication device provides the transaction data to a portable transaction device of a user through short-range wireless communication. The portable transaction device generates a cryptographic message based at least on the transaction data and credentials associated with an account. Receiving, by the communication device, a payload including at least the cryptographic message from the portable transaction device through the short-range wireless communication; and transmitting a token provisioning request message containing the cryptographic message to a token service computer. The communication device receives a token provisioning response message from the token service computer when a verification server verifies the cryptographic message, the token provisioning response message including a one-time use token associated with the credential; and transmitting the one-time use token to a resource provider computer to complete the e-commerce transaction.

Description

[0001] Cross-referencing related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 496,809, filed April 18, 2023, entitled "Secure Remote Interaction Using Portable Transaction Device," filed under 35 USC § 119(e), the disclosure of which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] In a typical e-commerce transaction where access to resources (e.g., goods or services, security data, etc.) is gained by remotely locating a resource provider's computer (e.g., via the Internet), the user will provide credentials (e.g., account information, etc.) on the resource provider's website to make payment for the transaction. However, the credentials provided on the website are easily compromised through hacking or social engineering.

[0004] Such e-commerce transactions, where users cannot physically present their payment device to store staff for verification, are often referred to as "cardless" transactions. Users will simply enter their account identifier in a field provided on the merchant's website.

[0005] On the other hand, for face-to-face transactions, users can present a user payment device, such as a card, to the client terminal to access resources. In this case, the user payment device typically carries additional security information (e.g., shared keys, cryptographic messages, etc.), which makes remote transactions more secure. Anyone without authorization would need to possess the user payment device to successfully impersonate an authorized user in a transaction.

[0006] However, conventional e-commerce transactions cannot benefit from additional security information (e.g., ciphertext) associated with the user's payment device. Furthermore, even in face-to-face transactions where this additional security information could be used, it is provided to resource providers, who can then reverse engineer it to obtain actual account credentials.

[0007] Furthermore, the standard processing messages used for cardless transactions do not allow the incorporation of ciphertext retrieved from the user's payment device. Modifying the standard processing messages for cardless transactions would have a significant impact on the infrastructure and ecosystem built to process these transactions.

[0008] The implementation examples address these and other problems. Summary of the Invention

[0009] The embodiments relate to token supply systems and methods.

[0010] Some embodiments provide a method performed by a communication device. The method includes receiving transaction data associated with a transaction performed by a user at a resource provider site from a resource provider computer operating a resource provider site. The method then includes providing the transaction data to a portable transaction device operated by the user via short-range wireless communication. The portable transaction device generates a ciphertext based at least on the transaction data and credentials associated with an account. The method further includes receiving a payload including at least the ciphertext from the portable transaction device via the short-range wireless communication. The communication device then transmits a token supply request message containing at least the ciphertext to a token service computer. The method includes receiving a token supply response message from the token service computer, the token supply response message containing a one-time use token associated with the credentials, while an authentication server verifies the ciphertext. The method further includes transmitting the one-time use token to the resource provider computer to complete the transaction at the resource provider site. The resource provider computer generates an authorization request message containing the one-time use token and transmits the authorization request message to an authorization entity computer for authorization.

[0011] Various embodiments provide a communication apparatus comprising a processor; and a non-transitory computer-readable medium containing code executable by the processor to perform steps including: receiving transaction data associated with a transaction performed by a user at a resource provider site from a resource provider computer operating a resource provider site; and providing the transaction data to a portable transaction device operated by the user via short-range wireless communication. The portable transaction device generates a ciphertext based at least on the transaction data and credentials associated with an account. The steps further include receiving a payload including at least the ciphertext from the portable transaction device via the short-range wireless communication; and transmitting a token supply request message containing at least the ciphertext to a token service computer. The steps also include receiving a token supply response message from the token service computer, the token supply response message containing a one-time token associated with the credentials, when a verification server verifies the ciphertext; and transmitting the one-time token to the resource provider computer to complete the transaction at the resource provider site. The resource provider computer generates an authorization request message containing the one-time token and transmits the authorization request message to an authorization entity computer for authorization.

[0012] Some embodiments provide a method performed by a token service computer. The method includes receiving a token supply request message from a communication device, the token supply request message including credentials associated with an account and a ciphertext generated at least based on transaction data associated with a transaction and the credentials associated with the account. The method further includes generating a one-time use token associated with the account while verifying the ciphertext using an authentication computer; and transmitting the one-time use token to the communication device. The method further includes receiving a detoxification request message including the one-time use token from a transaction processing network; and retrieving the credentials associated with the one-time use token while verifying the one-time use token. The method includes transmitting the credentials associated with the one-time use token to the transaction processing network, wherein the transaction is processed using the credentials.

[0013] These and other embodiments are described in further detail below. Attached Figure Description

[0014] Figure 1 Exemplary systems and flowcharts according to various embodiments are shown.

[0015] Figure 2 Exemplary system diagrams according to various embodiments are shown.

[0016] Figure 3 An exemplary token service computer according to various embodiments is shown.

[0017] Figure 4 Exemplary communication devices according to various embodiments are shown.

[0018] Figure 5 Exemplary portable transaction devices according to various embodiments are shown. Detailed Implementation

[0019] Before discussing the embodiments, some descriptions of certain terms may be helpful.

[0020] A “communication device” can include any suitable electronic device that can be operated by a user and that can also provide remote communication capabilities with a network. A “mobile communication device” can be an example of a “communication device” that can be easily transported. Examples of remote communication capabilities include the use of mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (such as the Internet or a private network). Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, etc. Other examples of mobile communication devices include wearable devices such as smartwatches, fitness trackers, anklets, rings, earrings, etc., and automobiles with remote communication capabilities. In some embodiments, a mobile communication device can act as a payment device (e.g., the mobile communication device can store and transmit payment credentials for transactions).

[0021] A "portable communication device" can be a portable device that can be transmitted and operated by a user, and may include one or more electronic components (e.g., integrated chips, etc.). A portable communication device according to an embodiment of the present invention can take any suitable form, including but not limited to mobile phones (e.g., smartphones, cellular phones, etc.), tablet computers, portable media players, personal digital assistant devices (PDAs), wearable communication devices (e.g., watches, bracelets, glasses, etc.), e-reader devices, laptop computers, netbooks, ultrabooks, etc. Portable communication devices can also take the form of vehicles equipped with communication capabilities (e.g., automobiles).

[0022] The portable communication device according to the embodiments can be configured to communicate with external entities (such as remote communication gateways) via long-range communication technologies and protocols. The portable communication device can also be configured to communicate with external entities, such as access devices, using any suitable short- or medium-range communication technologies, including Bluetooth (Classic and BLE-Low Power Bluetooth), NFC (Near Field Communication), IR (Infrared), Wi-Fi, etc.

[0023] "Portable device" can be a portable transaction device that can be used to conduct transactions. Portable devices can include storage technologies (e.g., electronic memory, magnetic stripe, etc.) for storing credentials or tokens associated with a user account. Portable devices can be any of the forms described above with respect to portable communication devices, or in the form of cards (e.g., integrated chip cards, magnetic stripe cards) or keychains. In some embodiments, the portable device and the portable communication device can be the same device and do not need to be separate devices. Specific examples of portable devices can include wearable devices, payment cards such as credit cards, debit cards, and prepaid cards, vehicles with telematics capabilities, etc.

[0024] A "payment device" can include any suitable device that can be used to conduct financial transactions, such as providing payment credentials to merchants. A payment device can be a software object, a hardware object, or a physical object. As an example of a physical object, a payment device may include a substrate (e.g., a paper or plastic card) and information printed, embossed, encoded, or otherwise included on or near the surface of the object. Hardware objects may involve circuitry (e.g., permanent voltage values), while software objects may involve non-permanent data stored on the device. A payment device may be associated with, for example, a monetary value, a discount, or a store credit value, and may be associated with an entity such as a bank, merchant, payment processing network, or individual. Suitable payment devices may be handheld and compact, allowing them to be placed in a user's wallet and / or pocket (e.g., pocket-sized). Exemplary payment devices may include smart cards, magnetic stripe cards, keychain devices (e.g., Speedpass™ available from ExxonMobil Corp.), etc. Other examples of payment devices include payment cards, smart media, transponders, etc. If the payment device is in the form of a debit card, credit card, or smart card, it may also optionally have features such as a magnetic stripe. Such devices can operate in contact or contactless modes.

[0025] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used as proof. Examples of credentials include value certificates, identification cards, authentication documents, access cards, passwords, and other login information.

[0026] A “payment credential” may include any suitable information associated with an account (e.g., the payment account and / or payment device associated with the account). Such information may be directly related to the account or may be derived from account-related information. Examples of account information may include PAN (primary account number or “account number”), username, expiry date, and verification values ​​such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0027] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0028] A "payment token" may include an identifier for a payment account, which is a substitute for an account identifier such as a primary account (PAN). For example, a payment token may include a series of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of the PAN "4147 0900 0000 1234". In some embodiments, the payment token may be "reserved format" and may have a numerical format conforming to account identifiers used in existing transaction processing networks (e.g., ISO 8583 Financial Transaction Message Format). In some embodiments, the payment token may be used in place of the PAN to initiate, authorize, settle, or resolve payment transactions, or to represent the original credentials in other systems where the original credentials are typically provided. In some embodiments, the payment token may be generated such that the recovery of the original PAN or other account identifier from the token value can be done without computation. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity that issued the token.

[0029] Tokenization is the process of replacing data with alternative data. For example, a payment account identifier (e.g., a master account number (PAN)) can be tokenized by replacing the master account identifier with a substitute number (e.g., a token) that can be associated with the payment account identifier. Additionally, tokenization can be applied to any other information that can be replaced with a substitute value (i.e., a token). Tokenization improves the efficiency and security of transactions.

[0030] A “token issuer,” “token provider,” or “token service system” can include a system that serves tokens. In some embodiments, a token service system may facilitate the requesting, determining (e.g., generating), and / or issuing of tokens, and maintaining the established token-to-PAN mapping in a repository (e.g., a token vault). In some embodiments, a token service system may establish a token security level for a given token to indicate the confidence level of the token’s association with the PAN. The token service system may include or communicate with a token vault storing generated tokens. By de-tokenizing tokens to obtain the actual PAN, the token service system may support token processing for payment transactions submitted using tokens. In some embodiments, a token service system may include only a tokenizing computer, or may include a tokenizing computer in combination with other computers such as a transaction processing network computer. Various entities in the tokenization ecosystem may assume the role of a token service provider. For example, a payment network and issuer or their agents may become a token service provider by implementing a token service according to embodiments of the present invention.

[0031] A “token domain” can indicate the area and / or environment in which a token can be used. Instances of token domains may include, but are not limited to, payment channels (e.g., e-commerce, physical point-of-sale, etc.), POS input modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers that uniquely identify where the token is available. A set of parameters (i.e., token domain restriction controls) can be established by the token service provider as part of token issuance, which can allow the appropriate use of the token in payment transactions. For example, token domain restriction controls can restrict the use of the token to a specific presentation mode—e.g., contactless or e-commerce presentation mode. In some embodiments, token domain restriction controls can restrict the use of the token to a specific, uniquely identifiable merchant. An exemplary token domain restriction control may require verifying the existence of a token ciphertext unique to a given transaction. In some embodiments, the token domain may be associated with the token requester.

[0032] The "Token Expiry Date" specifies the expiry date / time of a token. The token expiry date can be passed between entities in the tokenized ecosystem during transaction processing to ensure interoperability. The token expiry date can be a numerical value (e.g., a 4-digit number). In some embodiments, the token expiry date can be represented as a duration measured from the time of issuance.

[0033] "User" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0034] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, site and residential operators, etc.

[0035] A “merchant” can typically be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0036] An “acquiring party” can typically be a business entity that has a business relationship with a particular merchant or other entity (e.g., a commercial bank). Some entities can perform both issuing and acquiring functions. Some embodiments may cover such a single entity as an issuing-acquiring party. The acquiring party operates an acquiring computer, which may also be broadly referred to as a “transfer computer.”

[0037] An "authorizing entity" can be an entity that authorizes a request. Instances of authorizing entities can be publishers, government agencies, document repositories, access administrators, etc.

[0038] "Issuer" can generally refer to a business entity that maintains a user's account (e.g., a bank). Issuers can also issue payment credentials to consumers that are stored on portable transaction devices such as cell phones, smart cards, tablets, or laptops.

[0039] An "access device" can be any suitable device that provides access to a remote system. Access devices can also be used to communicate with a merchant's computer, transaction processing computer, authentication computer, or any other suitable system. Access devices can typically be located anywhere suitable, such as at the merchant's location. Access devices can take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data from or associated with a mobile communication device or payment device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with payment devices and / or mobile devices. In some embodiments, a cellular phone, tablet computer, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.

[0040] An "authorization request message" can be an electronic message requesting authorization for a transaction. In some embodiments, the message is sent to the transaction processing computer and / or the issuer of the payment card to request authorization for the transaction. Authorization request messages according to some embodiments may conform to ISO 8583, a standard for systems exchanging information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction amount, merchant identifier, merchant location, acquiring bank identification number (BIN), card acceptor ID, information identifying the item being purchased, and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0041] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message reply to an authorization request message generated by the issuing financial institution or transaction processing computer. By way of example only, an authorization response message may include one or more of the following status indicators: Approved – the transaction is approved; Rejected – the transaction is not approved; or Call Center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., POS equipment) in response to the authorization request message in the electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0042] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one instance, a server computer can be a database server coupled to a web server. A server computer can contain one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0043] New consumer computing devices such as PCs, tablets, and smartphones are now equipped with Near Field Communication (NFC) hardware, which can be used to communicate with portable transaction devices such as contactless payment cards.

[0044] The new consumer computing devices also feature secure computing technologies such as secure elements, trusted execution environments, and trusted platform modules. This enables payment kernel software to run securely on consumer computing devices and allows it to encrypt payment credentials captured from contactless payment cards.

[0045] Remote e-commerce payment transactions are processed as cardless transactions. Embodiments provide techniques for identifying and reducing fraud in cardless transactions using improved technologies from consumer computing devices. The novel consumer computing device has hardware and software for capturing EMV (Europay-Mastercard-Visa) ciphertext from portable transaction devices (e.g., contactless EMV payment cards). Embodiments provide techniques for modifying the cardless transaction flow and sending messages to incorporate the captured EMV ciphertext without requiring substantial changes to the cardless payment infrastructure.

[0046] This embodiment provides a novel cardless authorization protocol and message sending process that secures cardless authorization using captured EMV ciphertext on a consumer computer device. Once the issuer verifies the transaction by checking the ciphertext, the issuer assumes responsibility for the transaction.

[0047] Examples include the use of one-time use tokens in remote e-commerce transactions, which are obtained based on the verification of a ciphertext generated by tapping a portable transaction device with a communication device (e.g., a portable communication device such as a mobile phone or laptop computer).

[0048] Touching a portable transaction device to a communication device allows the portable transaction device to generate an EMV ciphertext, which can then be verified by an authorized entity computer operated by the issuer to enhance security. Typically, cardless authorization request messages used in remote e-commerce transactions do not carry EMV ciphertexts, and changes to the cardless authorization request message protocol could impact payment infrastructure and the ecosystem.

[0049] In some routine scenarios, merchant-initiated 3-D Security (3DS) step-by-step authentication can be used to transmit EMV ciphertexts, which are generated by tapping a portable transaction device, such as a payment card, against a communication device. The EMV ciphertext is obtained by the merchant and passed from the merchant to the issuer in remote e-commerce transactions. However, to support this process, the issuer must upgrade its 3DS Access Control Server (ACS) to verify the EMV ciphertext. In the case of cardless authorization request messages routed through non-affiliated payment networks and 3DS services outside of specific ecosystems, the payment processing network (e.g., VisaNet™) has no control or visibility over the EMV ciphertext generated in a format specific to that payment processing network within the transaction.

[0050] A protocol is needed that allows payment networks to have control and visibility over EMV ciphertexts while still supporting routing to non-affiliated payment networks to meet compliance requirements. Issuers also need a solution that minimizes the impact on cardless authorization hosts.

[0051] The embodiment uses a token service provider to verify the EMV ciphertext generated by a tap between a portable transaction device and a communication device. Upon successful verification, a one-time-use token is generated, thereby mapping the PAN to future cardless authorization request messages.

[0052] Figure 1 Exemplary systems and flowcharts according to various embodiments are shown. Figure 1 Each entity in the system can operate one or more computers.

[0053] In step 1, user (cardholder, account holder) 100 can initiate the checkout process for an e-commerce transaction on a resource provider website 106 (e.g., a merchant website) displayed on a browser on communication device 104 (e.g., a user device). In some embodiments, resource provider website 106 may be provided in the form of an application (e.g., an app) on communication device 104. For example, user 100 can activate a visitor checkout element 106b on resource provider website 106.

[0054] At step 2, the resource provider website 106 can query the communication device 104 and detect its Near Field Communication (NFC) capability. For example, the resource provider website 106 can detect the presence of an NFC chip reader 108a coupled to the communication device 104 through its SDK component 106a. The communication device 104 can receive an inquiry signal from the resource provider website 106 regarding its NFC capability. In some embodiments, the NFC chip reader 108a may be an external device coupled to the communication device 104 (e.g., coupled to an I / O port of the communication device 104). Alternatively, the NFC chip reader 108a may be an integrated component of the communication device 104. Upon detecting the NFC capability of the communication device 104, the resource provider website 106 may prompt the user 100 to tap their portable transaction device 102 against their communication device 104 to continue the e-commerce transaction. For example, communication device 104 can receive prompts from resource provider website 106 to retrieve credentials associated with an account from a user's portable trading device, and can display a message on resource provider website 106 prompting the user to tap their portable trading device 102 against communication device 104.

[0055] At step 3, user 100 may present (e.g., tap) portable transaction device 102 to communication device 104. According to various embodiments, user communication device 104 receives transaction data associated with an e-commerce transaction from resource provider website 106. Transaction data may include one or more of the following: transaction amount, merchant identifier, and detailed information about the purchased service or product. When user 100 taps portable transaction device 102 against communication device 104 (e.g., when portable transaction device 102 and communication device 104 are in short-range wireless communication), communication device 104 can provide the transaction data to user-operated portable transaction device 102 via short-range wireless communication.

[0056] Portable transaction device 102 generates a payload (e.g., a data packet) based at least on transaction data and account-associated credentials. The payload includes EMV ciphertext generated in accordance with the EMV protocol. In some embodiments, the EMV ciphertext (e.g., “ciphertext”) can be generated by encrypting at least the transaction data associated with the transaction and the master account (PAN) or other account identifier. In some embodiments, transaction data may include the transaction amount generated by resource provider website 106. Transaction data may also include one or more of the following: merchant country code, merchant verification result, transaction currency code, transaction date, transaction type, unpredictable numbers, and transaction counter.

[0057] According to various embodiments, the portable transaction device 102 may include an integrated circuit (e.g., a chip) that generates ciphertext using an N application cryptographic master key. The application cryptographic master key can be used to generate a session key. The session key can be unique for each transaction. The chip then generates ciphertext (e.g., EMV ciphertext) using the session key and data by applying an encryption algorithm.

[0058] The payload may also include account-associated credentials (e.g., PAN), chip data, etc. The PAN, chip data, and EMV cryptographic text may be stored on the memory of the portable translation device 102. The communication device 104 receives the payload, including at least the cryptographic text, from the portable transaction device 102 via short-range wireless communication (e.g., NFC). For example, the communication device 104 may include an NFC antenna configured to communicate with the portable transaction device 102 to receive credentials from it. The communication device 104 receives the cryptographic text from the portable transaction device 102 via the NFC capabilities of both the communication device 104 and the portable transaction device 102.

[0059] According to various embodiments, the communication device 104 can communicate with a communication device backend system (e.g., Figure 2The communication device 104 communicates with the backend system 208 shown, which can facilitate communication between the communication device 104 and a third-party entity (such as a token service provider 112). The ciphertext generated by the portable transaction device 102 is not shared with the resource provider website 106 and / or the resource provider computer 118. That is, the EMV ciphertext generated by the portable transaction device 102 bypasses the resource provider website 106 and / or the resource provider computer 118. According to various embodiments, the EMV ciphertext is not a payment credential that can be used to process e-commerce transactions.

[0060] In steps 4 and 5, communication device 104 may generate a token supply request message containing at least cryptographic text and transmit the token supply request message to token service provider computer 112. For example, communication device 104 may incorporate cryptographic text into the token supply request message. The token supply request message can be routed via the communication device backend system and the token management gateway 110 communicatively coupled to the token service provider computer 112 and the communication device 104 / communication device backend system. The token supply request message may include at least EMV cryptographic text and a request for the generation of a one-time token. The token supply request message may also include account-associated credentials (e.g., PAN) and chip data retrieved from portable transaction device 102.

[0061] At step 6, the token service provider 112 may transmit the credentials and ciphertext to the verification server 114. In some embodiments, if the token supply request does not include credentials associated with the account (e.g., a captured PAN), the token service provider 112 may retrieve credentials associated with the account (e.g., a PAN) based on the EMV ciphertext.

[0062] At step 7, the verification server 114 can verify the credentials and ciphertext using the shared key, and at step 8, returns a verification response message to the token service provider 112. The shared key may be the key used by the portable transaction device 102 to generate the ciphertext. In some embodiments, the shared key may be provided to the verification server 114 by the issuer 116 of the portable transaction device 102 (and the associated account). The verification response message verifies the ciphertext, thereby confirming that the credentials (e.g., a captured PAN) are associated with the account. According to various embodiments, each ciphertext may be unique for the associated transaction and may be designed to cryptographically demonstrate the validity of the portable transaction device 102 and ensure that transaction data perfectly matches the current (expected) transaction. The verification of the EMV ciphertext by the verification server 114 results in stronger verification compared to CVV / dCVV and PAN verification in conventional systems. Stronger verification leads to a reduction in fraudulent transactions.

[0063] In step 9, upon successful verification of the cryptographic text by the verification server 114, the token service provider 112 may communicate with the issuer 116 (e.g., the entity issuing the portable transaction device 102 and the associated account identified by the PAN) and generate a one-time use token upon receiving issuer approval from the issuer 116. The token service provider 112 may store mappings between one-time use tokens and one or more of the PAN and EMV cryptographic texts in a token vault. In some embodiments, the token service provider 112 may also generate the token cryptographic text and the one-time use token, and transmit both together to the communication device 104.

[0064] At steps 10 and 11, the token service provider 112 may return a token supply response message to the communication device 104, which includes at least a one-time use token, through the communication device backend system and / or the token management gateway 110. For example, the token supply response message may include a one-time use token (e.g., "token": "400012345678901234"), and optionally, may include a token ciphertext associated with the one-time use token (generated by the token service provider 112) (e.g., "token ciphertext": "MTIzNDU2Nzg5MDA5ODc2NTQzMjE=").

[0065] Communication device 104 receives a token supply response message containing a one-time use token (and optionally token cryptography) from a token service computer. At step 12, communication device 104 transmits the one-time use token (and optionally token cryptography) to resource provider computer 118 to complete the transaction on resource provider site 106. According to various embodiments, resource provider computer 118 generates an authorization request message (e.g., a cardless authorization request message) containing the one-time use token and transmits the authorization request message to an authorization entity computer (e.g., issuer 116) for authorization. In some embodiments, the authorization request message may include token cryptography and the one-time use token. The authorization request message can be routed to issuer 116 via acquirer 120 (at step 13) and transaction processing network 122 (at step 14).

[0066] Transaction processing network 122 may include a data processing subsystem, a network, and operations for supporting and delivering authorization services, exception handling services, and clearing and settlement services. An exemplary transaction processing network 122 may include VisaNet™. Transaction processing networks such as VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes a VIP system (Visa Integrated Payments System) for processing authorization requests and a Base II system for performing clearing and settlement services. Transaction processing network 122 may use any suitable wired or wireless network, including the Internet.

[0067] According to various embodiments, the token service provider 112 and the transaction processing network 122 may be managed by separate entities. In other embodiments, the token service provider 112 and the transaction processing network 122 may be managed by the same entity (e.g., VisaNet™). In such embodiments, the authorizing entity computer (e.g., issuer 116) may authorize transactions based at least on receiving instructions to verify the cryptographic text provided by the transaction processing network 122.

[0068] At step 15, the transaction processing network 122 may send the token to the token service provider 112 for detoxing. According to various embodiments, the one-time use token can only be detoxified by the token service provider computer 112. Therefore, even when the token service provider 112 and the transaction processing network 122 are managed by separate entities, the token service provider 112 will oversee all transactions using the one-time use token generated by the token service provider 112. For example, the token service provider 112 may be associated with a first transaction processing network. E-commerce transactions can be routed through a second transaction processing network. Upon receiving a one-time use token generated by the first transaction processing network, the second transaction processing network transmits the one-time use token to the token service provider associated with the first transaction processing network for detoxing, thereby notifying the first transaction processing network of the e-commerce transaction.

[0069] Token service provider 112 checks the token (e.g., expired for single use) and the token ciphertext (if present) to determine if the token has been used. Upon successful verification of the token and / or token ciphertext, token service provider 112 returns the PAN associated with the token to transaction processing network 122.

[0070] At step 16, the transaction processing network 122 may send a cardless authorization request message with a PAN to the issuer 116, the cardless authorization request message having an indicator indicating that the EMV ciphertext has been previously verified by the transaction processing network 122 (e.g., by a token service provider 112 managed by the same entity as the transaction processing network 122) and / or the verification server 114.

[0071] Upon receiving a cardless authorization request message with PAN and EMV cryptographic text verified by an indicator, the issuer 116 (via the authorization entity computer) can execute a risk algorithm to approve or reject the authorization request message with this new data without requiring changes to the cardless authorization host system.

[0072] At the end of the day or at any other suitable time, a clearing and settlement process is performed between the PSP / acquiring party 120, the transaction processing network 122, and the issuer 116.

[0073] Figure 2 Exemplary system diagrams according to various embodiments are shown. (As in conjunction with...) Figure 1 As discussed, when a user initiates the checkout of an e-commerce transaction on merchant website 204, merchant website 204 can detect the touch capability of communication device 202 via communication device 202. If touch functionality is supported, merchant website 204 prompts the user of communication device 202 to touch (e.g., display) a portable transaction device 206 (e.g., a payment card) with communication device 202 to provide payment information for the e-commerce transaction.

[0074] The user can tap the portable transaction device 206 against the communication device 202. The portable transaction device 206 can then generate a data packet including the PAN, chip data, and EMV cryptographic message following a predetermined EMV protocol. The data packet is captured by the communication device 202 and the communication device backend system 208 associated with the communication device 202. The EMV cryptographic message can be generated by encrypting at least the transaction data associated with the transaction and the PAN or other card identifier. In some embodiments, the transaction data may include the transaction amount generated by the merchant website 204.

[0075] Together, the communication device 202 and the communication device backend system 208 can send the captured PAN, chip data and EMV cryptographic text to the token service computer 210 in a one-time token supply request message.

[0076] The token service computer 210 sends the received PAN, chip data, and EMV cryptographic message to the authentication computer 212, enabling the authentication computer 212 to verify the cryptographic message using a shared key. Upon successful authentication by the authentication computer 212, the token service computer 210 generates a one-time use token, maps the one-time use token to the PAN, and returns the one-time use token to the communication device backend system 208 in a supply response message. Optionally, the one-time use token may have an associated token cryptographic message.

[0077] The communication device backend system 208 then sends the received one-time use token to the merchant website 204 via the communication device 202. The merchant website 204 sends the one-time use token to the merchant backend system 214 for payment processing. The merchant backend system 214 can then use the transaction processing network 218 selected by the merchant to send a cardless authorization request message including the one-time use token to a non-affiliated payment network via a payment service provider (e.g., acquirer) 216.

[0078] In embodiments where transaction processing network 218 is not attached to token service computer 210, transaction processing network 218 can identify that a one-time use token belongs to a different transaction processing network, for example, the token's BIN falls within the BIN range of different transaction processing networks. Then, transaction processing network 218 calls token service computer 210, which is attached to a different transaction processing network, to perform de-tokenization. Token service computer 210 performs verification checks on the token (e.g., checking if the one-time use has expired) and checks if the token ciphertext exists. Upon successful verification of the token and / or token ciphertext, token service computer 210 returns the PAN associated with the token to transaction processing network 218.

[0079] Transaction processing network 218 can then send a modified cardless authorization request message, including the PAN, to issuer 220. Upon receiving the modified cardless authorization request message including the PAN, issuer 220 processes the modified cardless authorization request message. At the end of the day or any other suitable time period, clearing and settlement processes are performed between PSP / acquiring party 216, different transaction processing networks, and issuer 220.

[0080] In this embodiment, all transactions involving a device tap are visible to the payment processing network attached to the token service computer that generates the one-time use token. The one-time use token can only be detoxified by the attached payment processing network. The embodiment can also accommodate merchant routing. Benefits for the issuer include minimizing the impact on cardless authorization hosts while allowing users to tap their cards against the communication device to obtain EMV ciphertext. The embodiment uses the one-time use token to map the tap to the device PAN and the ciphertext verification result in the remote e-commerce transaction.

[0081] Figure 3 Exemplary token service computers according to various embodiments are illustrated. Token service computer 300 may include processor 302, which may be coupled to computer-readable medium 304, data storage device 306, and network interface 308.

[0082] The computer-readable medium 304 may contain several software modules, including a tokenization module 304B, a token exchange module 304C, and a communication module 304D.

[0083] In this embodiment, the tokenization module 304B can use any suitable encryption algorithm to encrypt data to generate a one-time use token. Suitable data encryption algorithms may include DES, Triple DES, AES, etc. It can also store encryption keys that can be used with such encryption algorithms. The tokenization module 304B can use symmetric or asymmetric encryption techniques to encrypt and / or verify data. The keys that the tokenization module 304B can use can be securely stored in the data storage device 306.

[0084] The tokenization module 304B may also include code that causes the processor 302 to generate and provide a one-time use token. For example, the tokenization module 304B may contain logic that causes the processor 302 to generate a one-time use token and / or associate the one-time use token or cryptographic text with a set of user credentials.

[0085] The switching module 304C may include code that causes the processor 302 to detoxify the one-time use token (e.g., to determine the credentials or PAN corresponding to the one-time use token). For example, the switching module 304C may contain logic that causes the processor 302 to recognize the one-time use token at the data storage device 306 and retrieve a set of credentials (e.g., PAN) corresponding to the one-time use token from the data storage device 306.

[0086] The communication module 304D may include code that causes the processor 302 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities. For example, the communication module 304D may include code that causes the processor 302 to generate a verification request message, which will be transmitted to a verification server to verify the EMV ciphertext provided in the token request before generating a one-time use token. The token record can then be stored in a token record database, indicating that the token is associated with a user or a set of credentials.

[0087] Computer-readable medium 304 may contain code executable by processor 302 to perform operations including: receiving a token supply request message from a communication device, the token supply request message containing credentials associated with an account and a ciphertext generated at least based on transaction data associated with a transaction and the credentials associated with the account; generating a one-time token associated with the account when the ciphertext is verified using an authentication computer; transmitting the one-time token to the communication device; receiving a detoxification request message including the one-time token from a transaction processing network; retrieving the credentials associated with the one-time token when the one-time token is verified; and transmitting the credentials associated with the one-time token to the transaction processing network, wherein the transaction is processed using the credentials.

[0088] Data storage device 306 can store tokens and their associated credentials in a database (e.g., a token vault).

[0089] Figure 4 Exemplary communication devices according to various embodiments are shown. Communication device 400 may include device hardware 404 coupled to system memory 402.

[0090] Device hardware 404 may include a processor 406, a short-range antenna 414, a long-range antenna 416, an input element 410, a user interface 408, an output element 412 (which may be part of the user interface 408), and an NFC chip reader 418. Examples of input elements may include a microphone, a keypad, a touchscreen, a sensor, etc. Examples of output elements may include a speaker, a display screen, and a haptic device. Processor 406 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of communication device 400. Processor 406 may execute various programs in response to program code or computer-readable code stored in system memory 402, and may maintain multiple concurrently executing programs or processes.

[0091] The long-range antenna 416 may include one or more RF transceivers and / or connectors that can be used by the communication device 400 to communicate with other devices and / or connect to external networks. The user interface 408 may include any combination of input and output elements to allow a user to interact with the communication device 400 and invoke the functions of the communication device. The short-range antenna 414 may be configured to communicate with external entities via short-range communication media (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). For example, the short-range antenna 414 may be configured to communicate with a portable transaction device. The long-range antenna 416 may be configured to communicate over the air with remote base stations, remote servers (e.g., device backend computers or token service computers), and remote cellular or data networks.

[0092] System memory 402 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage media or combinations thereof. System memory 402 may store computer code that can be executed by processor 406 to perform any of the functions described herein.

[0093] System memory 402 may also store interactive application 402A (e.g., a web browser or merchant application), operating system 402B, and other components. Interactive application 402A may include instructions or code for initiating and conducting e-commerce transactions with external devices (such as a resource provider's computer). Interactive application 402A may be configured to display the resource provider's computer website on communication device 400.

[0094] System memory 402 may contain code executable by processor 406 to perform operations including: receiving transaction data associated with a transaction performed by a user at a resource provider site from a resource provider computer operating the resource provider site; providing the transaction data to a portable transaction device operated by the user via short-range wireless communication, wherein the portable transaction device generates a ciphertext based at least on the transaction data and credentials associated with the account; receiving a payload including at least the ciphertext from the portable transaction device via the short-range wireless communication; transmitting a token supply request message including at least the ciphertext to a token service computer; receiving a token supply response message from the token service computer, the token supply response message including a one-time token associated with the credentials, when the verification server verifies the ciphertext; and transmitting the one-time token to the resource provider computer to complete the transaction at the resource provider site, wherein the resource provider computer generates an authorization request message including the one-time token and transmits the authorization request message to an authorization entity computer for authorization.

[0095] Figure 5 Exemplary portable transaction devices according to various embodiments are illustrated. The exemplary portable transaction device may be in the form of a payment card. Portable transaction device 500 includes a substrate 500A, such as a plastic substrate. A contactless element 500B for interfacing with a data access or data transmission device may be located on or embedded within the user device substrate 500A. The contactless element 500B may include a chip and may include the ability to communicate and transmit data using near field communication (NFC) technology or other short-range communication technologies.

[0096] The portable transaction device 500 may also include a memory 500C, which may store user information such as account number, expiration date, and username. In some cases, the memory 500C may include a security element and / or may also store information such as access data. The information in the memory 500C may be transmitted by the portable transaction device 500 to another device using a contactless element 500B. For example, the contactless element 500B may receive transaction data from a communication device, generate a ciphertext based at least on the transaction data and the credentials stored in the memory 500C, and transmit the ciphertext to the communication device. The portable transaction device 500 may be assigned to a user by an authorized entity (such as an issuing bank). Information may also be printed or imprinted on a substrate 500A. The substrate 500A may also have a magnetic stripe 500D that can store duplicate and / or additional data.

[0097] The implementation offers several advantages. First, cardless transaction flows and message sending remain unaffected. Second, responsibility is transferred if the card ciphertext is verified during authentication. Third, step-by-step authentication using card ciphertext is frictionless compared to other mechanisms such as OTP. Furthermore, CVV step-by-step authentication used with card ciphertext does not require prior setup or registration (unlike biometric authentication).

[0098] Although the embodiments have been described in the context of cardless transactions with e-commerce merchants, they can also be applied to other contexts. For example, the embodiments can be used for person-to-person push payment transactions.

[0099] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language (e.g., Java, C++, or Perl) and employing techniques such as conventional or object-oriented methods. The software code can be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media (e.g., hard disk drive or floppy disk), or optical media (e.g., CD-ROM). Any such computer-readable medium can reside on or within a single computing device, and can exist on or within different computing devices within a system or network.

[0100] The above description is illustrative and not restrictive. Many variations of the embodiments will become apparent to those skilled in the art upon review of this disclosure. Therefore, the scope of the invention may be determined not with reference to the above description, but rather with reference to the pending claims and their full scope or equivalents.

[0101] Without departing from the scope of the invention, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0102] Unless explicitly indicated otherwise, the use of “a,” “an,” or “the” is intended to mean “one or more.”

[0103] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. They are not recognized as prior art.

Claims

1. A method comprising: receiving, by a communication device from a resource provider computer of a resource provider site, transaction data associated with a transaction conducted by a user at the resource provider site; providing, by the communication device to a portable transaction device operated by the user over short-range wireless communication, the transaction data, wherein the portable transaction device generates a cryptogram based at least on the transaction data and a credential associated with an account; receiving, by the communication device from the portable transaction device over the short-range wireless communication, a payload comprising at least the cryptogram; transmitting, by the communication device to a token service computer, a token provisioning request message including at least the cryptogram; receiving, by the communication device from the token service computer, a token provisioning response message including a single-use token associated with the credential upon verification of the cryptogram by a server; and transmitting, by the communication device to the resource provider computer, the single-use token to complete the transaction on the resource provider site, wherein the resource provider computer generates an authorization request message including the single-use token and transmits the authorization request message to an authorizing entity computer for authorization.

2. The method of claim 1, wherein the token provisioning response message further includes a token cryptogram, wherein the communication device transmits the token cryptogram along with the single-use token to the resource provider computer, wherein the authorization request message includes the token cryptogram along with the single-use token.

3. The method of claim 1, wherein the authorization request message is routed to the authorizing entity computer over a transaction processing network, and wherein the token service computer and the transaction processing network are managed by separate entities.

4. The method of claim 1, wherein the authorization request message is routed to the authorizing entity computer over a transaction processing network, and wherein the token service computer and the transaction processing network are managed by the same entity, and wherein the authorizing entity computer authorizes the transaction based at least on receiving an indication that the cryptogram provided by the transaction processing network was verified.

5. The method of claim 1, wherein the communication device receives the credential from the portable transaction device through near field communication (NFC) capabilities of the communication device and the portable transaction device.

6. The method of claim 5, further comprising: receiving, by the communication device from the resource provider computer, a prompt to retrieve the credential associated with the account from the portable transaction device, wherein the resource provider computer detects NFC capabilities of the communication device prior to transmitting the prompt.

7. The method of claim 1, wherein the payload further includes the credential associated with the account, and wherein the token provisioning request message further includes the credential associated with the account.

8. The method of claim 1, wherein the one-time use token is only capable of being de-tokenized by the token service computer.

9. A communication device, comprising: a processor; and a non-transitory computer-readable medium comprising code executable by the processor to implement steps comprising: receiving transaction data associated with a transaction conducted by a user at a resource provider computer of a resource provider site; providing the transaction data to a portable transaction device operated by the user through short-range wireless communication, wherein the portable transaction device generates a cryptogram based at least on the transaction data and a credential associated with an account; receiving a payload from the portable transaction device through the short-range wireless communication, the payload comprising at least the cryptogram; transmitting a token provisioning request message comprising at least the cryptogram to a token service computer; receiving a token provisioning response message from the token service computer upon verification of the cryptogram by a verification server, the token provisioning response message comprising a one-time use token associated with the credential; and transmitting the one-time use token to the resource provider computer to complete the transaction on the resource provider site, wherein the resource provider computer generates an authorization request message comprising the one-time use token and transmits the authorization request message to an authorizing entity computer for authorization.

10. The communication device of claim 9, wherein the steps further comprise: receiving a token cryptogram in the token provisioning response message; and transmitting the token cryptogram along with the one-time use token to the resource provider computer, wherein the authorization request message includes the token cryptogram along with the one-time use token.

11. The communication device of claim 9, further comprising: a near field communication (NFC) antenna configured to communicate with the portable transaction device to receive the credential from the portable transaction device.

12. The communication device of claim 11, wherein the steps further comprise: receiving an interrogation signal from the resource provider site regarding NFC capabilities of the communication device; and receiving a prompt from the resource provider computer through NFC to retrieve the credential associated with the account from the portable transaction device.

13. The communication device of claim 9, wherein the steps further comprise: receiving the credential associated with the account as part of the payload; and incorporating the credential associated with the account into the token provisioning request message.

14. The communication device of claim 9, wherein the one-time use token is only capable of being de-tokenized by the token service computer.

15. The communication device of claim 9, wherein the authorization request message is routed to the authorizing entity computer through a transaction processing network, and wherein the token service computer and the transaction processing network are managed by separate entities.

16. A method comprising: receiving, by a token service computer from a communication device, a token provisioning request message including a credential associated with an account and a cryptogram generated based at least on transaction data associated with a transaction and the credential associated with the account; generating, by the token service computer, a single-use token associated with the account upon verification of the cryptogram by a verification computer; transmitting, by the token service computer to the communication device, the single-use token; receiving, by the token service computer from a transaction processing network, a detokenization request message including the single-use token; retrieving, by the token service computer, the credential associated with the single-use token upon verification of the single-use token; and transmitting, by the token service computer to the transaction processing network, the credential associated with the single-use token, wherein the transaction is processed using the credential.

17. The method of claim 16, further comprising: transmitting, by the token service computer to the verification computer, the credential and the cryptogram; and receiving, by the token service computer from the verification computer, a verification response message, wherein the verification response message verifies the cryptogram, thereby attesting that the credential is associated with the account.

18. The method of claim 16, further comprising: generating, by the token service computer, a token cryptogram along with the single-use token, and transmitting, by the token service computer to the communication device, the token cryptogram along with the single-use token, wherein the communication device transmits the token cryptogram along with the single-use token to a resource provider computer to complete the transaction.

19. The method of claim 16, wherein the token service computer and the transaction processing network are managed by separate entities.

20. The method of claim 16, wherein the token service computer and the transaction processing network are managed by the same entity, and wherein the transaction is authorized based at least on an indication that the cryptogram is verified. ​

Images