Non-contact transaction correction system and method

Abstract

A method is disclosed. A method includes a second user device operated by a second user prompting a first user to interact a portable device of the first user with the second user device in a transaction, and then receiving interaction data including credentials or tokens from the portable device in a contactless communication. The method also includes determining that the transaction cannot be completed without further interaction of the first user, and providing at least one alternative transaction option to the first user in response to determining that the transaction cannot be completed. The method also includes receiving, from the first user, a selection of an alternative transaction option from the at least one alternative transaction option, and processing the transaction in accordance with the selected alternative transaction option.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is a PCT application and claims the priority benefit of U.S. Provisional Application No. 63 / 410,055, filed on September 26, 2022, the entire disclosure of which is incorporated herein by reference for all purposes. Background Art

[0003] User devices (e.g., mobile devices) are sometimes used as a point - of - sale (POS) terminal for a merchant. However, contactless transactions may be rejected for several reasons (e.g., exceeding transaction limits, requiring an offline PIN, geographical restrictions, etc.). A rejected transaction may need to be restarted by the merchant or a new transaction may need to be initiated to attempt the transaction in another way. Restarting a failed transaction requires additional time and effort and consumes additional computing resources.

[0004] Even if the initial contactless transaction cannot be successfully completed, new and improved ways can solve this problem and allow the user to continue the transaction without initiating a new transaction.

[0005] Embodiments of the present disclosure, individually and collectively, solve this problem and other problems. Summary of the Invention

[0006] One embodiment of the present invention includes a method. The method includes: prompting, by a second user device operated by a second user, a first user to interact a portable device of the first user with the second user device in a transaction; receiving, by the second user device, a credential or token from the portable device in a contactless communication; determining, by the first user device, that the transaction cannot be completed without further interaction of the first user; and in response to determining that the transaction cannot be completed, providing, by the second user device, at least one alternative transaction option for the first user; receiving, by the second user device, a selection of an alternative transaction option from the at least one alternative transaction option from the first user; and processing the transaction by the second user device according to the selected alternative transaction option.

[0007] Another embodiment of the present invention includes a second user device, which includes: a processor; and a non - transitory computer - readable medium, the non - transitory computer - readable medium including code executable by the processor for performing operations, the operations including: prompting a first user to interact a portable device of the first user with the second user device in a transaction; receiving a credential or token from the portable device in a contactless communication; determining that the transaction cannot be completed without further interaction of the first user; in response to determining that the transaction cannot be completed; providing at least one alternative transaction option for the first user; receiving a selection of an alternative transaction option from the at least one alternative transaction option from the first user; and processing the transaction according to the selected alternative transaction option.

[0008] Another embodiment of the present invention includes a method that includes: after a first user causes a portable device to interact with a second user device operated by a second user in a contactless communication, in a transaction between the second user and the first user, receiving, by an interaction processing server, a payload from the second user device, the payload including payload information and transaction information, the payload information including a credential or a token; determining, by the interaction processing server, whether the payload information is available to complete the transaction; determining, by the interaction processing server, that the payload information is not available to complete the transaction; and transmitting, by the interaction processing server, a response message to the second user device, wherein the second user device provides an option for the first user to complete the transaction. In some embodiments, the option includes generating a QR code encoding the transaction information, which can be scanned by a first user device operated by the first user to complete the transaction. In some embodiments, the option includes transmitting a link to the first user device, which can be used by the first user to complete the transaction.

[0009] These and other embodiments are described in detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 Shows a transaction processing system in an embodiment of the present invention.

[0011] Figure 2 Shows a first user device according to an embodiment of the present invention.

[0012] Figure 3 Shows a second user device according to an embodiment of the present invention.

[0013] Figure 4 Shows an interaction processing server according to an embodiment of the present invention.

[0014] Figure 5A Shows a method for successful contactless transactions with a second user device.

[0015] Figure 5B Shows a method for completing a transaction according to a first option.

[0016] Figure 5C Shows a method for completing a transaction according to a second option.

[0017] Figures 6A - 6B Shows data flows according to other embodiments.

[0018] Figures 7A - 7B Shows an example user interface according to an embodiment. DETAILED DESCRIPTION

[0019] Before discussing embodiments of the present disclosure, some terms may be described in further detail.

[0020] A "user" may include an individual. In some embodiments, a user may 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. In some examples, a user may be a resource provider, merchant, seller, or service provider.

[0021] An "authorizing entity" may be an entity that authorizes a request. Examples of authorizing entities may be an issuer, a government agency, a document repository, an access administrator, etc. An "issuer" may generally refer to a commercial entity (such as a bank) that maintains a user's account. An issuer may also issue payment credentials stored on a user device such as a cellular phone, smart card, tablet computer, or laptop computer to a customer.

[0022] A "user device" may be any suitable device with which a user may interact (e.g., a payment card or a mobile phone). A user device may take any suitable form such as a cellular phone, PDA, personal computer (PC), tablet computer, etc. In some embodiments where the user device is a mobile device, the mobile device may include a display, memory, processor, computer-readable medium, and any other suitable components.

[0023] A "mobile device" (sometimes referred to as a mobile communication device) may include any suitable electronic device that a user may transport and operate, and which may also provide the ability to communicate remotely with a network. A mobile communication device may communicate using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or a similar network), Wi-Fi, Bluetooth, low-power Bluetooth (BLE), Wi-Max, or any other communication medium that may provide access to a network (e.g., the Internet or a private network). Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, wearable devices (e.g., watches), vehicles such as smart cars, electric vehicles, cars, and motorcycles, personal music players, handheld dedicated readers, etc. A mobile device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device remotely accesses a network by tethering to another device (i.e., using the other device as a modem), the two devices used together may be considered a single mobile device).

[0024] A "voucher" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authorization. A voucher can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used for confirmation. Examples of vouchers include value vouchers, identification cards, authentication documents, access cards, passwords, and other login information, etc.

[0025] A "payment voucher" can include any suitable information associated with an account (e.g., a payment account and / or a payment device associated with the account). Such information can be directly related to the account or can be derived from information associated with the account. Examples of account information can include the PAN (primary account number or "account number"), username, expiration date, and verification values such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0026] A "token" can be an alternative value for a voucher. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens, such as payment tokens, data that can be used to access a secure system or location, etc.

[0027] A "payment token" can include an identifier of a payment account, which is an alternative to the account identifier, such as the primary account number (PAN) and / or the expiration date. For example, a token can include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the PAN "4147 0900 00001234". In some embodiments, the token can be "in a reserved format" and can have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token can be used in place of the PAN to initiate, authorize, process, or settle a payment transaction, or to represent the original voucher in other systems where the original voucher would typically be provided. In some embodiments, the token value can be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally feasible. Additionally, in some embodiments, the token format can be configured to allow the entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0028] "Tokenization" is the process of replacing sensitive data with substitute data. For example, a real credential (e.g., a primary account number (PAN)) can be tokenized by replacing the real account identifier with a substitute number that can be associated with the real credential. Additionally, tokenization can be applied to any other information so that the implicit information is replaced with a token. "Token exchange" or "detokenization" can be the process of restoring the data that was replaced during tokenization. For example, token exchange can include replacing a payment token with the primary account number (PAN) associated with the payment token. Additionally, detokenization or token exchange can be applied to any other information to retrieve the replaced information from the token. In some embodiments, token exchange can be implemented via a transaction message (such as an ISO message), an application programming interface (API), or another type of web interface (e.g., a web request).

[0029] A "token service computer" can include a system that services tokens. In some embodiments, the token service computer can assist in requesting, determining (e.g., generating), and / or issuing tokens, and maintaining the established mapping of tokens to primary account numbers (PANs) in a repository (e.g., a token vault). In some embodiments, the token service computer can establish a token assurance level for a given token to indicate the confidence level of the binding of the token to the PAN. The token service computer can include a token vault that stores the generated tokens or communicate with the token vault. The token service computer can support token processing of payment transactions submitted using tokens by detokenizing the tokens to obtain the actual PAN.

[0030] A "token domain" can indicate the area and / or environment in which a token can be used. Examples of token domains can 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 to uniquely identify where a token can be used. A set of parameters (i.e., token domain restriction controls) can be established by the token service computer as part of token issuance, which can allow for the enforcement of proper token use in payment transactions. For example, the token domain restriction controls can limit the use of a token in a specific presentation mode (such as a contactless or e-commerce presentation mode). In some embodiments, the token domain restriction controls can limit the use of a token at a specific merchant that can be uniquely identified. One exemplary token domain restriction control may require verification of the existence of a token ciphertext that is unique for a given transaction. In some embodiments, the token domain can be associated with the token requester.

[0031] A "token expiration date" can indicate the expiration date / time of a token. The token expiration date can be passed between entities in the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date can be a numerical value (e.g., a 4-digit numerical value). In some embodiments, the token expiration date can be expressed as a duration measured from the time of issuance.

[0032] An "authorization request message" can be a message that requests permission to interact. For example, an authorization request message can include an electronic message sent to a payment processing network and / or the issuer of a payment card to request authorization for a transaction. According to some embodiments, the authorization request message can conform to (International Organization for Standardization) ISO 8583, which is a standard for a system for exchanging electronic transaction information associated with payments made by consumers using a payment device or payment account. The authorization request message can include an issuer account identifier that can be associated with the payment device or payment account. The authorization request message can 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), expiration date, etc. The authorization request message can also include "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant identifier, merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction.

[0033] An "authorization response message" can be an electronic message reply to an authorization request message. In some embodiments, the authorization response message can be generated by an issuing financial institution or a payment processing network. By way of example only, the authorization response message can include one or more of the following status indicators: Approved - the transaction is approved; Declined - the transaction is not approved; or Call Center - more information is pending and the merchant must call a toll-free authorization telephone number. The authorization response message can also include an authorization code, which can be a code returned by a credit card issuing bank to an access device (e.g., a POS device) of a merchant in response to an authorization request message in an electronic message (either directly or through a payment processing network) indicating that the transaction is approved. The code can serve as evidence of authorization.

[0034] A "server computer" can include a powerful computer or a computer cluster. For example, the server computer can be a mainframe, a small computer cluster, or a group of servers that work as a unit. In one example, the server computer can be a database server coupled to a web server. The server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and assemblages to service requests from one or more client computers.

[0035] A "portable device" can be any suitable device that is portable. Examples of portable devices include mobile phones, wearable devices, keychains, etc. In some cases, the portable device can be a payment device.

[0036] "Payment device" can include any suitable device that can be used to conduct financial transactions (such as providing payment vouchers to merchants). The payment device can be a software object, a hardware object, or a physical object. As an example of a physical object, the payment device can include a substrate (such as a paper card or a plastic card), and information printed, embossed, encoded, or otherwise included on or near the surface of the object. The hardware object can relate to circuitry (such as a permanent voltage value), while the software object can relate to non-permanent data stored on the device. The payment device can be associated with a value such as a monetary value, a discount, or a store credit, and the payment device can be associated with an entity such as a bank, a merchant, a payment processing network, or an individual. The payment device can be used to conduct payment transactions. Suitable payment devices can be handheld and compact so that they can fit into a user's wallet and / or pocket (for example, they can be pocket-sized). Exemplary payment devices can include smart cards, magnetic stripe cards, keychain devices (such as Speedpass available from Exxon-Mobil Corporation) TM ), etc. Other examples of mobile communication devices include pagers, payment cards, security cards, access cards, smart media, transponders, etc. If the payment device is in the form of a debit card, a credit card, or a smart card, the payment device can also optionally have features such as a magnetic stripe. Such devices can operate in contact or non-contact modes. In some embodiments, a mobile communication device can act as a payment device (for example, the mobile communication device can store and be capable of sending payment vouchers for transactions).

[0037] "Application" can be computer code or other data stored on a computer-readable medium (such as a memory element or a security element), which can be executed by a processor to complete a task.

[0038] When the user does not have a contactless portable device or the contactless portable device cannot be used for a transaction, embodiments can provide the user with different options for performing the transaction.

[0039] Figure 1 FIG. 100 shows a transaction processing system according to an embodiment of the present invention.

[0040] Transaction processing system 100 may include a first user 102 operating a portable device 104 (such as a payment card) and a first user device 106 (such as a first mobile phone). The system 100 may include a second user 110 operating a second user device 108, which may communicate with an application server 112. The second user device 108 may communicate with the application server 112, an interaction processing server 114, and the first user device 106. The interaction processing server may also communicate with a transfer computer 116, a processing computer 118, and an authorization entity computer 120. The first user device 106 may also communicate with the processing computer 118. For simplicity of illustration, Figure 1 a specific number of components are shown. However, it should be understood that embodiments of the present invention may include more than one of each component. Additionally, some embodiments of the present invention may include fewer or more components than Figure 1 all of the components shown. Figure 1 The links between the various components shown in

[0041] at least Figure 1 messages between the devices shown may be transmitted using a secure communication protocol, such as but not limited to: File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583), etc. Although Figure 1 not shown, the various components of the transaction processing system 100 may be connected or interact with each other via a telecommunications network or via short-range communication. For example, a telecommunications network may include any network capable of sending information between two entities and may be capable of using any suitable communication protocol or mechanism (such as, cellular network, TCP / IP, Wi-Fi, radio waves, etc.). The communication network may include any one and / or combination of the following: direct interconnection; the Internet; local area network (LAN); metropolitan area network (MAN); Operations on the Internet as Nodes in the Internet (OMNI); secure custom connection; wide area network (WAN); wireless network (e.g., using protocols such as but not limited to Wireless Application Protocol (WAP), i-mode, etc.); etc. The communication network may use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channel may include a secure communication channel, which may be established in any known manner, such as by using mutual authentication and session keys, and establishing a Secure Sockets Layer (SSL) session.

[0042] Short-range communication, such as short-range communication between any combination of the portable device 104, the first user device 106, and the second user device 108, may include, for example, Bluetooth TM, any suitable mechanism such as Near Field Communication (NFC), radio waves, or infrared. As further explained below, the transaction processing system can be used to advantageously provide an alternative information flow or transaction flow when contactless payments using a portable device cannot be processed automatically or semi-automatically, which can avoid additional input from the second user to re-initiate or create a new transaction.

[0043] The first user 102 can operate the portable device 104 to initiate a transaction or be part of a transaction flow at the second user device 108. The second user device 108 can be associated with or operated by the second user 110 and interact with the application server 112. For example, the second user device 108 can include an application and can be configured to communicate with the application server 112 in relation to services, goods, access, payment requests, or other information.

[0044] The second user device 108 can be a mobile device that may not be able to make electrical contact with the chip or other electrical contact points of the portable device 104. In some embodiments, the second user device 108 may also not be able to accept a secret (e.g., PIN or password) from the first user 102, which may make it necessary to enter the secret on an alternative device such as the first user device 106. In some examples, the second user device 108 may contain software associated with a processing network or an authorizing entity that prevents it from accepting a secret from the first user 102 due to security or other issues.

[0045] The first user device 106 can be a mobile device operated by the first user. The first user device can include one or more applications related to the second user device, a payment processing provider, or an authorizing entity.

[0046] The portable device 104 can be, for example, a contactless payment card associated with the first user 102. The portable device 108 can be configured to communicate with the second user device 108 and can provide interaction data to the second user device 108 via a short-range communication channel (e.g., Bluetooth, Bluetooth Low Energy (BLE), Near Field Communication (NFC), etc.).

[0047] The interaction processing server 114 can determine whether the interaction between the portable device and the second user device can be used to complete a transaction.

[0048] The transfer computer 116 can be associated with the acquirer or potentially the issuer of the second user's account. The acquirer can issue and manage, for example, a financial account associated with the second user account identifier.

[0049] The processing computer 118 can be associated with a payment processing network. The payment processing network can include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network can include VisaNet TM . Such as VisaNet TM 's payment processing network is capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet TM Specifically includes the Visa Integrated Payments (VIP) system for processing authorization requests and the Base II system for performing clearing and settlement services. In addition, the payment processing network can use any suitable wired or wireless telecommunications network, including the Internet.

[0050] In some embodiments, the processing computer 118 can store tokens of multiple users in a token database (not shown), for example, via a registration process. For example, one or more tokens of each user can be stored in the token database based on device identifiers and / or account identifiers (e.g., Primary Account Number (PAN)) associated with the user during the enrollment or registration process.

[0051] In some embodiments, the authorization entity computer 120 can be associated with an issuer. The issuer can be any bank that can issue and maintain financial accounts for users (e.g., the first user 102).

[0052] Figure 2 A block diagram of the first user device 106 according to an embodiment is shown. An exemplary first user device 106 can include a processor 204. The processor 204 can be coupled to a memory 202, a communication interface 206, an input element 210, an output element 212, and a computer-readable medium 208. The second user device 106 can also have a program that can allow it to interact with the second user 110 and / or the application server 112 to initiate a transaction, record the result of the transaction, and display information related to the transaction to the second user 110 or the first user 102.

[0053] The memory 202 can be used to store data and code. The memory 202 can be coupled to the processor 204 internally or externally (e.g., cloud-based data storage device), and can include any combination of volatile and / or non-volatile memory such as RAM, DRAM, ROM, flash memory, or any other suitable memory device. For example, the memory 202 can store interaction data, application data, etc.

[0054] The one or more input elements 210 can include any suitable device capable of inputting data into the first user device 106. Examples of input elements 210 include buttons, touchscreens, touchpads, microphones, cameras, etc.

[0055] One or more output components 212 may include any suitable device capable of outputting data. Examples of output components 212 may include a display screen, a speaker, and a data sending device. For example, the output component 212 may include a display screen capable of displaying a response value to a user of the first user device 106.

[0056] The computer-readable medium 208 may include a number of software applications and / or software modules. Examples of such modules may include a first resource provider application 208A, a second resource provider application 208B, a processing module 208C, a communication module 208D, and a contactless application 208E. The first resource provider application 208A and the second resource provider application 208B may be a first merchant application and a second merchant application. The processing module 208C in combination with the processor 204 may enable the first user device 106 to process data for a transaction. It may include a QR code application that can read and process a QR code or similarly displayed code (e.g., MaxiCode, MS Tag, Blipper, Data Matrix) to initiate or advance a transaction flow or interaction. It may also include a network payment handler that can allow for continued processing of a transaction session with a second user in the event that an initial transaction attempt is unsuccessful. The communication module 208B and the processor 204 may perform processing on the first user device 106 to communicate with external entities. The contactless application 208E may be an application that facilitates a "tap to pay" mechanism, such as tapping a portable device against the first user device 106 to obtain a credential or token from the portable device.

[0057] The first user device 106 may be capable of reading a machine-readable code, such as a QR TM code. For example, the user 102 may use a camera or scanning device in the first user device 106 to scan a QR TM code associated with a transaction displayed on the display of the second user device 108. The QR TM code may include information about the transaction with the second user device 108 (e.g., resource provider identifier, transaction amount, etc.). The first user device 104 may also allow the first user 102 to provide a payment credential for the transaction using a link to a resource provider website (e.g., a merchant website).

[0058] In some embodiments, the first user device 106 may decode a machine-readable code obtained from the second user device and may display to the first user 102 the transaction details encoded by the machine-readable code. Thereafter, the first user device 106 may prompt the first user 102 to provide a credential or token for a transaction such as a payment transaction.

[0059] The computer-readable medium 208 may include code executable by the processor 204 for performing steps associated with the methods and processes described herein.

[0060] The communication interface 206 may include one or more devices and software that may allow the first user device 106 to communicate with an external computer or device. The communication interface 206 may enable the first user device 106 to transfer data to another device (e.g., a resource provider device, a resource provider server, a portable device, a device, a computer, and / or a server of a processing system, etc.) and transfer data from another device. Some examples of the communication interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Wireless protocols enabled by the communication interface 206 may include Wi-Fi TM . Data transferred via the communication interface 206 may be in the form of a signal, which may be an electrical signal, an electromagnetic signal, an optical signal, or any other signal that can be received by an external communication interface (collectively referred to as "electronic signals" or "electronic messages"). These electronic messages that may include data or instructions may be provided between the communication interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as a wire or cable, an optical fiber, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium. The communication interface 206 may be associated with or operate in conjunction with a communication API 208D.

[0061] The processing module 208C may be utilized by one or more resource provider applications 208A and 208B installed on the first user device 106 or the second user device 108 to process data.

[0062] In some embodiments, the processing module 208C may include a kernel-on-device (KoD) service. The KoD service may include a contactless entry point, a contactless kernel, a cardholder verification method (CVM) module, a payment card data encryption module, and / or other software modules that may be used for interactions (e.g., contactless payment transactions).

[0063] Figure 3Disclosed is a block diagram of a second user device 108 according to an embodiment. An exemplary second user device 108 may include a processor 304. The processor 304 may be coupled to a memory 302, a communication interface 306, an input element 310, an output element 312, and a computer-readable medium 308. The second user device 108 may also be unable to perform certain actions with respect to the payment card or the portable device 104, such as being physically and electrically communicatively coupled to the circuitry or integrated chip of the portable device 104.

[0064] The processor 304, the memory 302, the communication interface 306, the input element 310, the output element 312, and the computer-readable medium 308 may be similar to the processor 204, the memory 202, the communication interface 306, the input element 210, the output element 212, and the computer-readable medium 208 described above with reference to Figure 2 The various components described with respect to Figure 3 The various components described may be coupled or related to each other similar to the descriptions provided above with reference to Figure 2 The various components described may be coupled or related to each other similar to the descriptions provided above with reference to

[0065] The computer-readable medium 308 may include a number of software applications and / or software modules. Examples of such modules may include a QR code module 308A, a processing module 308B, and a communication module 308C. The computer-readable medium 308 may also include code executable by the processor 304 to perform a method, the method including: prompting a first user to interact a first user's portable device with a second user device in a transaction; receiving, in a non-contact communication, interaction data including a credential or a token from the portable device; determining that the transaction cannot be completed without further interaction by the first user; in response to determining that the transaction cannot be completed, providing the first user with at least one alternative transaction option; receiving from the first user a selection of an alternative transaction option from the at least one alternative transaction option; and processing the transaction according to the selected alternative transaction option.

[0066] Figure 4 Shown are some components of an interaction processing server 114 according to an embodiment. The interaction processing server 114 may include a processor 402 coupled to a network interface 404, a transaction rules database 406, a resource provider account database 408, a user account database 410, and a computer-readable medium 412.

[0067] The computer-readable medium 412 may include code executable by the processor 402 for implementing a method using embodiments of the present invention. For example, the computer-readable medium 412 may include code executable by the processor 402 to perform operations including: after a first user causes a contactless portable device to interact with a second user device operated by a second user, in a transaction between the second user and the first user, receiving, by an interaction processing server, a payload from the second user device, the payload including payload information and transaction information, the payload information including a credential or a token; determining, by the interaction processing server, whether the payload information is available to complete the transaction; determining, by the interaction processing server, that the payload information is not available to complete the transaction; and transmitting, by the interaction processing server, a response message to the second user device, wherein the second user device provides options for the first user to complete the transaction.

[0068] The computer-readable medium 412 may include a verification module 412A, an authorization processing module 412B, and a processing option module 412C.

[0069] The rules database 406 may contain a set of rules for determining whether a transaction can be completed based on interaction data obtained from the portable device. The transaction rules database 406 may contain logic or rules implementing any of the behaviors described herein, including but not limited to: (i) a requirement that the portable device 104 must be in physical and electrical contact with the second user device, (ii) requirements related to the total value of the transaction, (iii) the cumulative value of transactions over a period of time (e.g., the monetary value over hours, days, or weeks), (iv) the number of contactless or tap payment transactions attempted over a period of time, (v) the geographical location of the portable device at the time of the attempted transaction, (vi) the geographical location of the issuer of the portable device 104, (vii) a geographical match or mismatch related to the portable device 104, the first user device 106, and the second user device 108, or other geographical location information. The transaction rules database may also contain criteria for the types of transactions allowed from the first user device 106, which may correct disallowed transactions. This information may be provided to the second user device 108 from the interaction processing server 114 via an indication embedding this information. For example, the indication may be that the transaction cannot be completed without additional information from the first user (e.g., entering his or her payment information, or providing a PIN on the first user device 106).

[0070] In other examples, the authorizing entity may set conditions regarding the processing of a transaction based on the interaction and additional requirements. For a transaction to be successfully processed. For example, the authorizing entity associated with the credential or token provided from the portable device 104 may require the first user to enter a secret, password, PIN, or may require physical or electrical contact between the portable device and the second user device.

[0071] Although not shown in Figure 4 the interactive processing server may also include an authentication database that can store one or more of voice, password, passphrase, personal identification number (PIN), password, face identification, etc. In some embodiments, the authentication data may be stored in the authentication database 406 when the user registers. In some embodiments, the authentication data in the authentication database may be linked to the corresponding device identifier and / or user account identifier.

[0072] The resource provider account database 408 may be configured to store information associated with multiple resource accounts and their account identifiers.

[0073] The user account database 410 may be configured to store information associated with multiple user accounts and their account identifiers and user information (e.g., phone number, etc.).

[0074] The verification module 412A may include code executable by the processor 402 for verifying the data in the payload from the second user device to determine whether the data therein can be used to complete the transaction. The verification module 412A and the processor 402 may use the rules in the rule database 406 and apply them to the information in the payload to determine whether the transaction can be successfully completed.

[0075] The authorization processing module 412B and the processor 402 may generate and transmit an authorization request message and receive and process the authorization response message of the transaction.

[0076] The processing option module 412C may include options for completing the transaction in case the initial attempt to complete the transaction is unsuccessful. The options may be processes available to ensure the type of second user device, credential, token, or portable device initially used to conduct the transaction is completed.

[0077] Figure 5A Figure 501 is shown, which shows the "tap to pay" process, where the first user 102 taps their portable device 104 against the second user device 108 to conduct a payment transaction, and the payment transaction is successfully completed. Before step S502, the first user 102 may wish to make a payment to the second user 110 in the transaction. For example, the transaction may be a payment transaction for a resource or may be a person-to-person fund transfer transaction. The second user device 108 may display the transaction amount of the transaction, and this amount may be shown to the first user 102. An example of this scenario is shown in Figure 7A the user interface 710 in

[0078] At step S502, the first user 102 may interact (e.g., tap) their portable device 104 with the second user device 108. The portable device 104 may be a payment card, such as a credit card, which may interact with the second user device 108 via non-contact communication. The portable device 104 may transfer a payload including payment credentials or payment tokens from the portable device 104 to the second user device 108 via a short-range communication protocol such as NFC or Bluetooth TM and so on.

[0079] At step S504, the second user device 108 may transmit another payload and payload information to the interaction processing server 114, which may be remotely located relative to the second user device 108. In addition to the credentials or tokens received from the portable device 104, the payload information may also contain information related to the transaction (e.g., the transaction amount and an identifier of the second user or the second user device 108).

[0080] After receiving the payload, the interaction processing server 114 may determine whether the transaction should continue based at least on the data in the payload. Various rules may be applied during the determination process. For example, the rule may be that a transaction made with a debit card requires a PIN to continue, and only certain mobile phones are secure enough to process PIN transactions. The interaction processing server 114 may determine whether the second user device 108 meets this rule. Additionally, the interaction processing server 114 may evaluate whether the interaction between the portable device 104 and the second user device 108 is otherwise effective, and whether the received payload has sufficient information for the interaction processing server 114 to process the transaction. If the interaction processing server 114 determines that the transaction may continue, it may generate an authorization request message that includes at least the transaction amount, an identifier of the second user of the second user device, and the credentials or tokens.

[0081] At step S506, the interaction processing 114 server may transmit the authorization request message to the transfer computer 116.

[0082] At step S508, the transfer computer 116 may transmit the authorization request message to the processing computer 118.

[0083] At step S510, the processing computer 118 may analyze a voucher or a token. If a token exists, the processing computer 118 may de-tokenize the token to obtain the voucher associated with the token. The processing computer 118 may have or communicate with a token library or a token database that stores the mapping between tokens and vouchers (e.g., primary account numbers). Then, the processing computer 118 may replace the token with the voucher in the authorization request message. Once the voucher is obtained, the processing computer 118 may determine the authorization entity computer 120 by analyzing the voucher or other data. The processing computer 118 may then transmit the authorization request message to the authorization entity computer 120.

[0084] At step S512, the authorization entity computer 120 may determine whether the transaction is authorized. The determination may be based on whether the first user 102 has sufficient credit or funds in the account associated with the voucher. It may also be based on the authorization entity computer 120 determining that the transaction has a low likelihood of fraud. The authorization entity computer 120 may then generate an authorization response message including the authorization result. The authorization response message may include the voucher, the transaction ID, the timestamp, the identifier of the second user 110 or the second user device 108, an approval or rejection indicator, etc. After generating the authorization response message, it is transmitted to the processing computer 118.

[0085] In step S514, if the original authorization request message included a token instead of a voucher, the processing computer 118 may replace the voucher in the authorization response message with the token. Then the authorization response message may be sent to the transfer computer 116. The transfer computer 116 may optionally provide the authorization response message to the application server 112 associated with the second user application on the second user device 108.

[0086] In step S516, the transfer computer 116 may route the authorization response message to the interactive processing server 114.

[0087] In step S518, the interactive processing server 114 or the application server 112 may send a confirmation message to the second user device 108. Then, the second user device 108 may display the confirmation message to the second user 110.

[0088] At the end of the day or any other appropriate time period, a clearing and settlement process may occur between the transfer computer 116, the processing computer 118, and the authorization entity computer 120.

[0089] Figure 5BIllustrates a transaction process 502 according to an embodiment of the present invention. In this example transaction process 502, the interaction processing server 114 may determine that a transaction cannot be completed using the contactless portable device and the second user device 108. It may then automatically provide options for the first user and the second user 102 to complete the transaction in a different manner without abandoning the transaction.

[0090] At step S522, the first user 102 may interact (e.g., tap) their portable device 104 on the second user device 108. The portable device 104 may be a payment card, such as a credit card, which may interact with the second user device 108 via contactless communication. The portable device 104 may transfer a payload including payment credentials or payment tokens from the portable device 104 to the second user device 108 via a short-range communication protocol such as NFC or Bluetooth TM etc. An example of a screen that may be presented on the second user device 108 may be Figure 7A the user interface 710 in

[0091] At step S524, the second user device 108 may transmit another payload and payload information to the interaction processing server 114, which may be remotely located with respect to the second user device 108. In addition to the credentials or tokens received from the portable device 104, the payload information may also contain information related to the transaction (e.g., the transaction amount and an identifier of the second user or the second user device 108).

[0092] After receiving the payload, at step S526, the interaction processing server 114 may determine whether the transaction should continue based at least on the data in the payload. As described above, various rules may be applied in the determination. For example, the rule may be that a transaction made with a debit card requires a PIN to continue, and only certain mobile phones are secure enough to handle PIN transactions. The interaction processing server 114 may determine whether the second user device 108 meets this rule. Additionally, the interaction processing server 114 may evaluate whether the interaction between the portable device 104 and the second user device 108 is otherwise effective, and whether the received payload has sufficient information for the interaction processing server 114 to process the transaction.

[0093] Other rules that the interaction processing server 114 may apply may include whether the transaction amount of the current transaction is below a threshold amount that permits contactless payment, whether the second user device 108 has sufficient security features to securely conduct the transaction, and so on. In some cases, historical data associated with the user account associated with the portable device 104 or the first user 102 may be used to determine whether the transaction can be completed. For example, speed limits (e.g., the maximum number or cumulative amount of transactions within a predetermined time period) may be applied to transactions conducted using the portable device 104. Such rules and constraints may be provided to the interaction processing server 114 by an authorizing entity that issues a credential or token for conducting the transaction.

[0094] In step S528, the interaction processing server 114 may generate a response message and transmit it to the second user device 108. The response message may include an indication that the current transaction cannot be completed between the portable device 104 and the second user device 108 and that additional action on behalf of the first user 102 is required to complete the transaction. The response message may also optionally provide one or more options that may be used to complete the transaction, provided that those options have not already been programmed into the second user device 108. In some embodiments, the presented options may have been previously evaluated by the interaction processing server 114, and the interaction processing server 114 may have determined that the presented options (e.g., in the form of selectable buttons) are available for successfully completing the transaction. In a first example option, a machine-readable code such as a QR code, for example, may be used to complete the transaction, and the machine-readable code may be generated by the second user device 108. The machine-readable code may be scanned by the first user device 106, which may complete the transaction. In a second example option, the first user 102 may select a button on the second user device 108 to send a link to the first user device 106. The link may direct the first user device 106 to an application server 112 associated with an application on the second user device 108. Then, the first user 102 may use the first user device 106 to complete the transaction. In a third example option, the first user 102 may be prompted to use a different portable device 104 to complete the transaction.

[0095] The above first and second options may use the first user device 106 of the first user 102 rather than the second user device 108 to complete the transaction. One advantage of doing so is that the first user 102 may securely enter sensitive data therein, as it is held and operated by the first user 102. For example, entering a PIN into the first user device 106 is less likely to raise fewer security concerns than entering a PIN into the second user device 108 that is not held or owned by the first user 102. Thus, embodiments may improve transaction security by providing more secure payment options in situations where an initial attempt to conduct a payment transaction is deemed insecure.

[0096] Once the second user device 108 receives the response message, options for completing the transaction can be presented to the first user on the second user device 108. An example of the user interface is shown in Figure 7A 720 in. The first user 102 may decide to complete the transaction using the first example option with a QR code. In response to this selection, the second user device 108 may generate a QR code that includes the transaction amount and an identifier of the entity that will receive funds from the first user 102, as well as a transaction identifier. The identifier may be an account identifier of the second user 110's account and / or a device identifier of the second device 108 or a second user identifier of the second user 110 (which may be linked to the second user 110's account). An example of the user interface is shown in Figure 7A 730 in.

[0097] At step S530, the first user device 106 may use the camera in the first user device 106 to scan the QR code displayed on the second user device 108. The first user device 106 may use an application or software to decode the QR code to obtain the information in the QR code. Then, the first user device 106 may generate a transaction message that includes at least some of the information in the QR code (e.g., transaction amount, transaction identifier, second user device identifier, second user's account identifier, etc.) and a credential or token of the first user 102. In some embodiments, if this information is stored in the first user device 106, the credential or token may be obtained from the first user device. This may be the case if the first user device 106 is a mobile phone with a digital wallet. In another embodiment, the first user device 106 may receive the credential or token from the portable device 104 via a contactless communication such as NFC communication.

[0098] At step S532, the first user device 106 may send the transaction message to the processing computer 118.

[0099] In step S534, the processing computer 118 may then generate an appropriate transaction request message to complete the transaction and may transmit the message to the authorization entity computer 120 and / or the transfer computer 116 in steps S536 and S538. After the transfer computer S526 is notified of the authorization of the transaction, it may provide a notification to the application server in step S540, and the application server may in turn notify the second user device 108 in step S542.

[0100] In some embodiments, an AFT (Account Funding Transaction) message can be generated by the processing computer 118 and transmitted to the authorization entity computer 120 to debit the account of the first user 102. An OCT message can then be generated and sent to an entity (e.g., an acquirer or issuer) that operates the transfer computer 116 to credit the account of the second user 110.

[0101] An AFT (Account Funding Transaction) is a transaction designed to supply funds to another account, such as a credit, prepaid, debit, ATM, or online account. In some embodiments, an AFT message can be used to pay a service provider for sending funds to a recipient and result in a debit to the account of the sender. The amount debited can be the amount of the credit to be delivered to the recipient plus any fees charged by the service provider, such as a transfer fee or currency conversion fee (if applicable).

[0102] An AFT indicator can be used in authorization as well as clearing and settlement transactions, and there is authorization before the AFT indicator. Settlement can occur within two business days, or in a longer or shorter time than this. Neither the authorization nor the clearing transaction carries any financial information about the transfer recipient. In some embodiments, an AFT carries an account number or other identifier associated with the sender's payment account. An AFT message can also be accompanied by an indicator that allows the issuer of the sender to make an appropriate authorization decision. The indicator includes channel information, such as mail order / telephone order or the Internet, etc.

[0103] The following fields can be used for AFT and can be supported in messages as well as clearing and settlement transactions. Fields included in a traditional AFT message can include, but are not limited to, account number, processing code; merchant type; CAVV result code; mail order / telephone order / e-commerce indicator; mail / telephone / e-commerce indicator; transaction ID (XID); and so on.

[0104] An OCT (Original Credit Transaction) is typically a clearing and settlement credit transaction that is designed for commercial applications, such as commercial transfers or business-to-consumer reimbursements. In embodiments of the present invention, an OCT can be used to deliver funds to a recipient account. It can be separated from an AFT transaction and can occur after the AFT transaction. This timing can ensure the security of the funds paid before they are sent to the recipient.

[0105] The amount of an OCT can be the amount agreed upon by the sender and the service provider in a given currency. An OCT can carry the account number of the recipient without carrying information about the sender. A special indicator can identify an OCT for the recipient's issuing bank. Settlement can occur within two days, or in a longer or shorter time than this.

[0106] In other embodiments, the processing computer 118 may generate an authorization request message 118 that includes the transaction amount, an identifier of the second user or second user device, and a credential (or token). The authorization request message may then be transmitted to the authorization entity computer 120 for authorization.

[0107] The authorization entity computer 120 may then transmit an authorization response message to the transfer computer via the processing network computer 118, as described above with respect to the Figure 5A process in. After receiving the authorization response message, the processing computer 118 may transmit a notification of a successful transaction to the first user device 106.

[0108] At the end of the day or any other suitable time period, a clearing and settlement process may occur between the transfer computer 116, the processing computer 118, and the authorization entity computer 120.

[0109] Although in the above embodiments, the processing computer 118 receives a transaction message from the first user device 106 and the processing computer 118 generates an appropriate message to complete the transaction, in other embodiments, another entity such as the application server 112, the interactive processing server 114, the transfer computer 116, and the authorization entity computer 112 may receive a message with transaction information from the first user device 106 to complete the transaction.

[0110] Advantageously, in process flow 502, even if the initiation of the transaction is unsuccessful, the transaction between the first user and the second user is successfully completed. Embodiments may save a transaction that would otherwise be abandoned, thus saving computing resources.

[0111] Figure 5C Transaction flow 503 is shown, which illustrates an example process flow for the second option described above, which sends a link to the first user device 106 to complete a transaction that the interactive processing server determines cannot be completed by the portable device 104 and the second user device 108. The link may be a payment link that can be delivered to the first user device 106 in any suitable manner (e.g., text message or email).

[0112] In flow 503, with respect to the above Figure 5BSteps S522, S524, S526, and S528 are described and incorporated herein by reference. However, in the second option, the first user 102 selects the option of receiving a link, such as a payment link, to complete the transaction. The first user 102 can select a button on the second user device 108 to select this second option. The first user 102 can enter a phone number, email address, or other identifier to receive the link. Alternatively, the link can be encoded within a QR code, which can be scanned by the first user device 106. The first user device 106 can decode the QR code to obtain the link.

[0113] At step S550, the second user device 108 can send a message to the application server 112 with instructions for a link to be sent to the identifier entered by the first user 102. The identifier can be a phone number, and in response, the application server can send a text message including the link to the first user device 106 in step S552.

[0114] After receiving the link, the first user device 106 can display the link to the first user 102 (e.g., in a text message application). Then, the first user 102 can select the link and can be redirected to the application server 112. Once the first user device 106 communicates with the application server 112, the application server can generate a checkout page or other funds transfer page with information about the transaction and can request in step S554 that the first user 102 provide payment credentials or tokens to complete the transaction. As noted in other examples, the first user device 106 can then obtain the credentials or tokens from memory or can obtain the credentials or tokens from the portable device 104 and provide this information to the application server 112. The first user 102 can also manually enter the credentials or tokens into the first user device 106. An example of a user interface is shown in Figure 7B 740 therein. Then, the application server 112 can generate an authorization request message with the transaction amount and the credentials or tokens and can transmit it to the transfer computer 116.

[0115] At step S558, the transfer computer 116 can transmit the authorization request message to the processing computer 118.

[0116] At step S560, the processing computer 118 may analyze a voucher or a token. If there is a token, the processing computer 118 may de-tokenize the token to obtain the voucher associated with the token. The processing computer 118 may have or communicate with a token library or a token database that stores a mapping between the token and the voucher (e.g., the primary account number). Then, the processing computer 118 may replace the token in the authorization request message with the voucher. Once the voucher is obtained, the processing computer 118 may determine the authorization entity computer 120 by analyzing the voucher or other data. The processing computer 118 may then transmit the authorization request message to the authorization entity computer 120.

[0117] At step S562, the authorization entity computer 120 may determine whether the transaction is authorized. The determination may be based on whether the first user 102 has sufficient credit or funds in the account associated with the voucher. It may also be based on the authorization entity computer 120 determining that the transaction has a low likelihood of fraud. The authorization entity computer 120 may then generate an authorization response message including the authorization result. The authorization response message may include the voucher, the transaction ID, the timestamp, the identifier of the second user 110 or the second user device 108, an approval or rejection indicator, etc. After generating the authorization response message, it is transmitted to the processing computer 118.

[0118] In step S564, if the original authorization request message included a token instead of a voucher, the processing computer 118 may replace the voucher in the authorization response message with the token. Then the authorization response message may be sent to the transfer computer 116. The transfer computer 116 may optionally provide the authorization response message to the application server 112 associated with the second user application on the second user device 108.

[0119] In step S566, the transfer computer 116 may route the authorization response message to the application server 122.

[0120] In step S568, the application server 112 may send a confirmation message to the second user device 108. Then, the second user device 108 may display the confirmation message to the second user 110.

[0121] After receiving the authorization response message, the application server 112 (or other entity aware of the approved authorization response message) may transmit a notification of the successful transaction to the first user device 106.

[0122] Figure 6A and 6BA flowchart showing a transaction process for performing a payment transaction according to other embodiments. A first user 102 may choose to perform a payment transaction for goods and / or services with a second user 604. The second user 604 may use a Tap to Pay (TTP) seller application 106 in the second user device. The first user 602 may use a payment device (e.g., digital wallet, credit card, etc.) to perform a payment transaction with the second user 604 via the second user device. The second user device may be a mobile phone. During the payment transaction, the second user device of the second user 604 may communicate with a TTP kernel backend 608 to verify the payment device.

[0123] In step S602, the second user 604 may enter a transaction amount in the TTP application 606. In step S604, the TTP application 606 may display a Tap to Pay screen, where the first user 602 may perform a payment transaction by interacting the second user device (which has the TTP application 606) with a payment device that supports contactless payment. Payment devices that support contactless payment may include mobile wallets (e.g., Tap to Talk), contactless credit cards (e.g., Tap to Pay credit cards), etc. An exemplary Tap to Pay screen may be shown in Figure 7A screen 710. In some embodiments, the TTP application 606 may call a contactless kernel from the TTP kernel backend to prepare for a contactless payment transaction.

[0124] In step S605, the first user 602 may interact (e.g., via tapping) the payment device with the second user device having the TTP application 606. After tapping, the contactless payment device may send the payment credentials of the payment device to the TTP kernel backend 608. The payment credentials may include credit card number, name, expiration date, CVV, etc.

[0125] In step S606, the TTP kernel backend 608 may review the payment credentials after receiving them. The TTP kernel backend may determine that the transaction requires an offline PIN, or may receive a response from the issuer of the payment device that a contactless transaction is required. If the payment device has transaction restrictions, the issuer may also require a contactless transaction, further cardholder verification (CVM) of the first user 602, etc.

[0126] In some embodiments, the TTP kernel backend 608 may accept the payment device, send an authorization request to the issuer, and receive an authorization response for a successful payment transaction from the issuer. Then, the TTP kernel backend 608 may notify the TTP application 606 of the successful payment transaction, where the TTP application 606 may display the transaction approval status and ask the first user 602 if they want a receipt. If the first user 602 wants a receipt, the second user 604 may provide a receipt to the first user 602.

[0127] In step S608, the TTP kernel backend 608 can discard the payment transaction and pass the error message of the failed transaction back to the TTP application 606.

[0128] In step S610, after receiving the error message from the TTP kernel backend 608, the TTP application 606 can determine that the transaction cannot be processed. The TTP application 606 can display the error message and can provide alternative checkout options. The alternative checkout options can be options that allow the first user 602 to use a different payment device (e.g., digital wallet, contactless credit card, etc.), or to continue the payment transaction using a payment link or machine-readable code. An exemplary alternative payment screen can be shown in Figure 7A screen 720.

[0129] In step S612, the first user 602 can select an option among different alternative payment options. In step S614, the first user 602 can select the option of using a different payment device. After selecting to use a different payment device, the TTP application 606 can start a new contactless transaction using a tap-to-pay screen similar to Figure 7A screen 710. In step S616, the first user 602 can select the option of using a payment link to execute the payment transaction.

[0130] In some embodiments, the first user 602 may not have a payment device that can perform contactless transactions from the beginning. In this case, the second user 604 or the first user 602 can select alternative payment options from the start of the payment transaction in Figure 6B step S618. In step S620, the TTP application 606 can be directed to the alternative payment options that can be shown in Figure 7A screen 720. The first user 602 can select the option of using a payment link to execute the payment transaction similar to step S616.

[0131] In step S622, the first user device can display a payment link screen. The payment link screen can be shown in Figure 7A screen 730. The payment link can be transmitted to the first user's first user device, or can be embedded in a QR code, which can be scanned by the first user device to obtain the payment link.

[0132] In step S624, the first user 602 can select an option or method for receiving the link.

[0133] In step S626, the first user 602 can receive the payment link (i.e., the checkout page) and can start the checkout page. The checkout page screen can be in Figure 7Bshown in the screen 740. In step S628, the first user 602 may enter a payment voucher in the checkout page. Once the first user 602 finishes entering the payment voucher in the checkout page, the customer may select the option to send the payment voucher to the TTP kernel backend 608 (not shown). In some embodiments, a payment link may require a conditional authentication (e.g., 3D Secure) upgrade before sending the payment voucher (step S630). In step S632, the payment voucher may be sent to the TTP kernel backend 608, and the payment may be completed.

[0134] In step S634, the TTP application 606 may receive a notification of the completed transaction from the TTP kernel backend 608. The TTP application 606 may launch a transaction completion screen with the option to provide a receipt. The payment completion screen may be shown in Figure 7B the screen 750. In step S636, if the first user 602 selects to receive the receipt, the second user 604 may provide the receipt to the first user 602 via email or text message using the TTP seller application 606.

[0135] Embodiments of the present invention have several teaching advantages. As explained above, embodiments of the present invention can be used to complete transactions that could not be completed initially. Information initially generated by the second user device for the transaction is not lost and can be reused, enabling the transaction to be completed in a safe and efficient manner. Without embodiments of the present invention, transactions that could not be completed initially simply could not be completed. A new transaction would need to be initiated, unnecessarily consuming computing resources. In addition, embodiments of the present invention can automatically detect whether a transaction to be conducted is insecure and can provide more secure payment processing to complete transactions that might otherwise not be completed.

[0136] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored on a computer-readable medium as a series of instructions or commands for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as compact discs (CDs) or digital versatile discs (DVDs), flash memory, and the like. The computer-readable medium can be any combination of such storage devices or transmission devices.

[0137] Such programs can also be encoded and transmitted using carrier signals adapted for transmission via wired networks, optical networks, and / or wireless networks compliant with various protocols, including the Internet. Thus, a computer-readable medium according to an embodiment of the present invention can be created using data signals encoded with such programs. A computer-readable medium encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system) and can exist on or within different computer products in a system or network. A computer system can include a monitor, a printer, or other suitable display for providing any of the results mentioned herein to a user.

[0138] The above description is illustrative and not restrictive. Many variations of the present invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the present invention should not be determined by reference to the above description, but rather by reference to the pending claims, together with their full scope of equivalents.

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

[0140] As used in this Chinese text, unless expressly indicated to the contrary, the use of "a", "an", or "the" is intended to mean "at least one / kind".

Claims

1. A method, comprising: A second user device operated by a second user prompts a first user to interact the first user's portable device with the second user device in a transaction; The second user device receives interaction data including a credential or a token from the portable device in non-contact communication; The second user device determines that the transaction cannot be completed without further interaction of the first user; In response to determining that the transaction cannot be completed, the second user device provides at least one alternative transaction option for the first user; The second user device receives a selection of an alternative transaction option from the at least one alternative transaction option from the first user; And The second user device processes the transaction according to the selected alternative transaction option.

2. The method according to claim 1, wherein Processing the transaction according to the selected alternative transaction option includes: Displaying a QR code encoding transaction information, and then allowing the first user device to obtain an image of the QR code and process the transaction according to the transaction information and the credential or the token.

3. The method according to claim 2, wherein the portable device is a card.

4. The method according to claim 2, wherein the non-contact communication is NFC communication.

5. The method according to claim 2, wherein the first user device is a first mobile phone, the second user device is a second mobile phone, and the portable device is a card.

6. The method according to claim 1, wherein Processing the transaction according to the selected alternative transaction option includes: A process for providing a link to the first user device of the first user device, wherein the link directs the first user device to an application server that allows the first user to complete the transaction.

7. The method according to claim 1, wherein determining by the first user device that the transaction cannot be completed without further interaction of the first user is based on the requirement that a secret of the first user be input into the second device, but the second device cannot process the secret.

8. The method according to claim 1, wherein determining by the first user device that the transaction cannot be completed without further interaction of the first user is based on the requirement that an authorization entity associated with the credential or token requires the first user device to contact the second user device for the transaction, but the first user device and the second user device cannot physically and electrically contact each other.

9. The method according to claim 1, wherein determining that the transaction cannot be completed is based on the total value of the transaction.

10. The method according to claim 1, wherein determining by the second user equipment that the transaction cannot be completed without further interaction by the first user includes: Determining that the second user device is not secure enough to complete the transaction.

11. The method according to claim 10, wherein the at least one alternative transaction option is more secure than the transaction process with the second user device.

12. The method according to claim 1, further comprising: A payload is transmitted from the second user device to an interaction processing server, the payload including payload information and transaction information, the payload information including the credential or token, the interaction processing server determining that the transaction cannot be completed without further interaction from the first user, and generating a message indicating that the transaction cannot be completed without further interaction, and wherein the second user device determines that the transaction cannot be completed without further interaction after receiving the message.

13. The method according to claim 12, wherein the interaction processing server includes a rules database having rules for determining that the transaction cannot be completed without further interaction.

14. The method according to claim 1, wherein the second user device receives the token.

15. The method according to claim 1, wherein the second user device receives the credential.

16. The method according to claim 15, wherein the credential is an account identifier of an account of the first user.

17. A second user device, comprising: a processor; and a non-transitory computer-readable medium including code executable by the processor for performing operations including: prompting a first user to interact a portable device of the first user with the second user device in a transaction, receiving, in non-contact communication, interaction data including a credential or token from the portable device, determining that the transaction cannot be completed without further interaction from the first user, in response to determining that the transaction cannot be completed, providing at least one alternative transaction option for the first user, receiving from the first user a selection of an alternative transaction option from the at least one alternative transaction option, and processing the transaction according to the selected alternative transaction option.

18. A method, comprising: after a first user interacts a non-contact portable device with a second user device operated by a second user in a transaction between the second user and the first user, receiving, by an interaction processing server, a payload from the second user device, the payload including payload information and transaction information, the payload information including a credential or token; determining, by the interaction processing server, whether the payload information can be used to complete the transaction; determining, by the interaction processing server, that the payload information cannot be used to complete the transaction; and transmitting, by the interaction processing server, a response message to the second user device, wherein the second user device provides options for the first user to complete the transaction.

19. The method according to claim 18, wherein the option includes generating a QR code encoding the transaction information, the QR code being scannable by a first user device operated by the first user to complete the transaction.

20. The method according to claim 18, wherein the option includes transmitting a link to the first user device, the link being usable by the first user to complete the transaction.

Images