Planned interaction using a password

Abstract

A method includes a network processing computer receiving an authorization request message including a token and a password during an interaction between a resource provider and a user. The network processing computer determines user credentials associated with the token. Then, the network processing computer determines a plan identifier based on the authorization request message. The network processing computer provides the plan identifier to an authorization entity computer.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of the filing date of U.S. Provisional Application No. 62 / 948,073, filed on December 13, 2019, and the U.S. Provisional Application is incorporated herein by reference in its entirety for all purposes. Background of the Invention

[0003] A plan is an option for handling an interaction such as paying for goods or services. For example, during a plan, payments can be made at fixed intervals. A plan can be provided by a resource provider to a user. In other use cases, other entities can provide a plan to the user.

[0004] During an interaction, if a plan is to be selected and implemented, additional messaging is required to transfer plan information between computers in the interaction system. Additionally, usually, the available plans can be notified to the user after the interaction data for authorization is submitted by the resource provider computer. For example, a network processing computer can receive an authorization request message from the resource provider computer that includes interaction data for authorizing the interaction. Then, the network processing computer can contact the user to ask if the user wants to select a plan, thus slowing down the processing of the interaction due to messaging and waiting for user input.

[0005] Embodiments of the present disclosure, alone and in combination, solve this and other problems. Summary of the Invention

[0006] One embodiment relates to a method, including: receiving, by a network processing computer, an authorization request message including a token and a password during an interaction between a resource provider and a user; determining, by the network processing computer, user credentials associated with the token; determining, by the network processing computer, a plan identifier based on the authorization request message; and providing, by the network processing computer, the plan identifier or plan information associated with the plan identifier to an authorization entity computer. The authorization entity computer can determine whether to authorize the interaction.

[0007] Another embodiment relates to a network processing computer, including: a processor; and a computer - readable medium coupled to the processor, the computer - readable medium including code executable by the processor for implementing a method, the method including: receiving an authorization request message including a token and a password during an interaction between a resource provider and a user; determining user credentials associated with the token; determining a plan identifier based on the authorization request message; and providing the plan identifier or plan information associated with the plan identifier to an authorization entity computer. The authorization entity computer can determine whether to authorize the interaction.

[0008] Another embodiment relates to a method, comprising: receiving, by a user device, one or more plans from a service provider computer during an interaction between a user of the user device and a resource provider of a resource provider computer; receiving, by the user device, a selection of a plan from among the one or more plans from the user; determining, by the user device, a plan identifier based on the selected plan; obtaining, by the user device, a token; and providing, by the user device, the plan identifier and the token to the resource provider computer.

[0009] Additional details regarding embodiments of the present disclosure can be found in the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A block diagram showing an installment processing system according to an embodiment.

[0011] Figure 2 A block diagram showing components of a network processing computer according to an embodiment.

[0012] Figure 3 A flowchart showing a pre - interaction setup process according to an embodiment.

[0013] Figure 4 A block diagram showing a user plan interface according to an embodiment.

[0014] Figure 5 A flowchart showing a plan and interaction processing method according to an embodiment.

[0015] Figure 6 A flowchart showing an alternative plan and interaction processing method according to an embodiment.

[0016] Figures 7A-7B A block diagram showing a user interface during interaction processing according to an embodiment.

[0017] Figure 8 A schematic diagram showing post - interaction installment processing according to some embodiments. DETAILED DESCRIPTION

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

[0019] A "user" may include an individual or a machine that operates something. 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, an account holder, or a consumer.

[0020] A "user device" can be a device operated by a user. Examples of user devices can include mobile phones, smartphones, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, vehicles such as cars, thin client devices, tablet PCs, etc. Additionally, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. The user device can include one or more processors capable of processing user input. The user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that a user can operate, and the electronic device can also provide the ability to communicate remotely with a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or a similar network), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network such as the Internet or a private network.

[0021] A "credential" can include any evidence of authority, right, or entitlement to privilege. For example, an access credential can include permission to access certain tangible or intangible assets such as a building or a file. In another example, a payment credential can include any suitable information associated with and / or identifying 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 related to the account. Examples of account information can include an "account identifier" such as a primary account number or "account number" (PAN), a token, a sub-token, a gift card number or code, a prepaid card number or code, a user name, an expiration date, a card verification value (CVV), a dynamic card verification value (dCW), a card verification value 2 (CVV2), a card verification code 3 (CVC3), etc. An example of a PAN is a 16-digit number such as "4147 0900 0000 1234". In some embodiments, a credential can be considered sensitive information. A credential associated with a user can be a "user credential".

[0022] 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. A payment token can include an account identifier that serves as an alternative to account data (such as an account number). For example, a token can include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For instance, the token "4900 0000 0000 0001" can be used in place of the PAN "4147 0000 1234". In some embodiments, a token can be "in a reserved format" and can have a numeric format consistent with the account identifiers used in existing transaction processing network computers. In some embodiments, a token can be used in place of an account number to initiate, authorize, process, or settle a transaction, or to represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value can be generated such that the original account number or other account identifier cannot be computationally derived from the token value. Additionally, in some embodiments, the token format can be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0023] An "interaction" can be a mutual action, effect, or influence. An interaction can be, for example, an exchange or transaction between two or more parties. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user's request to access secure data, a secure web page, a secure location, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment.

[0024] An "application programming interface" or "API" can include software that specifies how the components of a system should interact. An API can include a set of routines, protocols, and tools on which software applications can be built. An API can be used for web-based systems, operating systems, database systems, computer hardware, or software libraries, and can include specifications for routines, data structures, object classes, variables, and / or remote calls.

[0025] A "plan" can include a proposal to do something or achieve something. A plan can include one or more actions, events, or methods that are proposed to occur in the future. A plan can include the intention to execute the actions, events, or methods. A plan can include any suitable type of plan, such as an installment plan (e.g., a payment plan), a data plan, a digital or physical asset transfer plan, and / or any other action, event, or method that can be planned to undertake or achieve a goal. A plan can be related to an interaction. In some embodiments, a plan can change an interaction in a specific predefined way (e.g., an installment plan can divide the total transaction amount into multiple payments).

[0026] “Installment plan / installments plan” can be a scheme for dividing things based on installment payments over two or more events. For example, the event can be the payment of a portion of the total amount, and the installment period can be one month (e.g., for monthly payments). In some cases, the installment plan can be associated with a new, unique credit limit. In some cases, the installment plan can be associated with a specific payment instrument, such as a debit card or a credit card. In some cases, the card can be a card specifically issued for installment payments (“installment card”). Alternatively, the card can be the user's credit card for which installment payments have been temporarily or permanently enabled, along with typical functions such as debit or traditional credit payment processing.

[0027] “Plan identifier” can include a character sequence for identifying or referring to a plan such as an installment plan. The plan identifier can be associated with a specific plan. For example, a first plan identifier can identify and be associated with a first plan, while a second plan identifier can identify and be associated with a second plan. The plan identifier can include alphanumeric characters that can refer to the plan. For example, the plan identifier can be “001” or “Plan 1”, which can refer to the first plan. As another example, the plan identifier can be “GX834KL”, which can refer to the plan.

[0028] “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, venue and residential operators, etc. “Merchant” can generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0029] “Resource provider computer” can be a computer operated by a resource provider. Suitable computers can include access devices, backend server computers, and combinations of the above.

[0030] “Acquirer” can generally be a business entity (e.g., a commercial bank) that has a business relationship with a specific merchant or another entity. Some entities can perform both the issuer function and the acquirer function. Some embodiments can cover such a single entity issuer - acquirer. The acquirer can operate an acquirer computer, which can also be an instance of a “transmission computer”.

[0031] An "authorizing entity" can be an entity that authorizes requests. Examples of authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. An authorizing entity can operate an "authorizing computer" or an "authorizing entity computer". An "issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. The issuer can also issue payment credentials stored on a user device to a consumer, or in some embodiments to a portable device, such as a cellular phone, smart card, tablet computer, or laptop computer.

[0032] "Interaction data" can include any suitable information associated with the interaction between an access device and a user device. Interaction data can include any suitable data associated with an interaction (e.g., a purchase transaction). In some embodiments, interaction data can include any suitable combination of the following: identification data associated with the access device (e.g., one or more identifiers of the access device), identification information associated with the user device (e.g., one or more identifiers associated with the user device), an interaction value (e.g., a transaction amount, such as a pre-authorization amount of a transaction and / or a purchase price), payment data (e.g., a payment account identifier associated with a payment account), one or more locations each associated with the access device and / or the user device, or any suitable information. Examples of payment data can include a primary account number or "account number" (PAN), user name, expiration date, card verification value (CVV), dynamic card verification value (dCVV), card verification value 2 (CVV2), CVC3 card verification value, etc. CVV2 is generally understood to be a static verification value associated with a payment device. The CVV2 value is typically visible to the user (e.g., the consumer), while the CVV and dCVV values are typically embedded in memory or an authorization request message and are not easily known to the user (although they are known to the issuer and the payment processor). Payment data can be any information that identifies or is associated with a payment account. Payment data can be provided to effect a payment from the payment account. Payment data can also include a user name, expiration date, gift card number or code, and any other suitable information. Interaction data can relate to ticket information for an event, data for accessing a building, transit ticket information, passwords, biometrics, or other credentials for accessing secure data, etc.

[0033] "Authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization for a transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, which is a standard for systems that exchange electronic transaction information 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 a 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, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, user name, expiration date, and so on. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquirer 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.

[0034] "Authorization response message" can be a message in response to an authorization request. In some cases, the authorization response message can be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. By way of example only, the authorization response message may 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 may also include an authorization code, which can be a code returned by a credit card issuing bank to an access device (such as a POS device) of a merchant in response to an authorization request message in an electronic message (either directly or through a transaction processing computer) indicating approval of the transaction. The code can serve as evidence of authorization.

[0035] "Virtual account" can be an account associated with a user and is virtual. A virtual account can be a payment account that can be used to process transactions. For example, a virtual account can be an account involved in credit or debit value processing. In some instances, a virtual account can be a prepaid account, or can be generated for the purpose of storing prepaid value in preparation for processing future transactions. In some instances, a virtual account number can be used to identify a virtual account.

[0036] "Password" can include a piece of obscure text, such as encrypted text. The password can be formed by encrypting input data with an encryption key (such as a symmetric encryption key). In some embodiments, the password is reversible such that the same symmetric key can be used to obtain the input used to form the password to perform the decryption process. In some embodiments, if the input data is encrypted with the private key of a public / private key pair, the password can also be a digital signature. The digital signature can be verified with the public key of the public / private key pair. In some embodiments, the password can include a dCVV (dynamic card verification value).

[0037] "Processor" can include a device for processing something. In some embodiments, the processor can include any suitable one or more data computing devices. The processor can include one or more microprocessors working together to achieve the desired function. The processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for executing user- and / or system-generated requests. The CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0038] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transitory computer-readable media that stores instructions executable by the processor to implement the desired method. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can operate using any suitable electrical, optical, and / or magnetic operating modes.

[0039] "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 working as a unit. In one instance, 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 compilations to service requests from one or more client computers.

[0040] Embodiments of the present disclosure include a network computer capable of receiving an authorization request message including a token and a password during an interaction between a resource provider and a user. The network processing computer may determine user credentials associated with the token. The network processing computer may then determine an installment plan identifier based on the authorization request message. The network processing computer may then provide the installment plan identifier to an authorization entity computer. The authorization entity computer may then determine whether to authorize the interaction. In some embodiments, the installment plan identifier or plan information (e.g., name, terms and conditions, etc.) may be sent to the authorization entity computer via a communication separate from the authorization process. For example, the plan identifier or plan information may be sent to the authorization entity computer via an API. In other embodiments, the plan identifier or plan information associated with the plan identifier is sent to the authorization entity computer in a modified authorization request message that includes the plan identifier or plan information.

[0041] In some embodiments, the authorization entity computer may set a plan (e.g., an installment plan, a data plan, etc.) for the user. In other embodiments, the authorization entity computer may set a plan together with the network processing computer. The network processing computer may generate a plan identifier for each plan received by the authorization entity computer and assign the plan identifier. In addition, each plan may be associated with plan metadata (e.g., data related to the plan). The plan metadata may be an instance of the plan information. The plan metadata may include, for example, the length of the plan, the increment number of the plan, the amount of each increment (e.g., information about interest rate or any fees), the expiration date of the plan, the minimum amount of the plan, the location requirements of the plan, etc. The network processing computer may provide the plan identifier and the plan metadata to a service provider computer. The service provider computer may store the plan identifier and the plan metadata on the user device and / or store them at the service provider computer. Then, during the interaction and when a specific plan is selected for the interaction, the user device may generate a password (e.g., a token authentication verification value (TAVV)) based on the plan identifier associated with the plan selected by the user. The user device may provide the password together with the token to the network processing computer via the resource provider computer in the authorization request message. The network processing computer may determine the plan identifier from the password, which allows the network processing computer to determine which plan the user has selected. In some embodiments, this does not expand the size of the authorization request message to include additional data.

[0042] In other embodiments, the network processing computer may assign a plan identifier to each plan for which the user is eligible. The network processing computer may provide the plan identifier to the service provider computer. For example, a user may be associated with (e.g., eligible for) five different plans. The network processing computer may provide the plan identifiers for the five plans to the service provider computer. The network processing computer may also provide the plan metadata for each plan to the service provider computer. The service provider computer may then store the plan identifier and the associated metadata on the user device. During an interaction, after the user selects a plan, the user device may determine the plan identifier associated with the plan selected by the user. The user device may provide the plan identifier in a password that will be sent in an authorization request message to the network processing computer. The user device may then provide a token associated with the user credentials to the resource provider computer, which may generate an authorization request message for the interaction and provide the authorization request message to the network processing computer. The network processing computer may then determine the plan identifier of the plan selected by the user from the password. As noted above, the plan identifier or plan information associated with the plan identifier may be provided to the authorization entity computer via an API or via the authorization request message.

[0043] Figure 1 FIG. 1 shows a system 100 in accordance with an embodiment of the present disclosure. System 100 includes a user device 102, a resource provider computer 104, a service provider computer 106, a network processing computer 108, an authorization entity computer 110, and a transport computer. The user device 102 may be operatively communicable with the resource provider computer 104 and the service provider computer 106. The resource provider computer 104 may be operatively communicable with the service provider computer 106, the network processing computer 108, and the transport computer 112. The network processing computer 108 may be operatively communicable with the service provider computer 106, the authorization entity computer 110, and the transport computer 112.

[0044] For simplicity of illustration, Figure 1 a certain 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.

[0045] Messages between components of system 100 can be sent 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. The communication network can include any one and / or combination of the following: direct interconnection; Internet; Local Area Network (LAN); Metropolitan Area Network (MAN); Operational Mission as Nodes on 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 can use any suitable communication protocol to generate one or more secure communication channels. In some instances, the communication channel can include a secure communication channel, which can be established in any known manner, such as by using mutual authentication and session keys, and establishing a Secure Sockets Layer (SSL) session.

[0046] User device 102 can be any suitable device operated by a user. For example, in some embodiments, user device 102 can be a mobile device. User device 102 can be configured to receive schedule information (e.g., installment plan information) from, for example, service provider computer 106. User device 102 can be configured to receive input from the user regarding the selection of a plan. User device 102 can also be configured to send an indication of accepting the plan to network processing computer 108. User device 102 can further be configured to initiate an interaction with the resource provider of resource provider computer 104 (e.g., via service provider computer 106).

[0047] Service provider computer 106 can receive data from user device 102 or other suitable devices operated by the user, and can perform interactions, such as transactions. Service provider computer 106 can also receive data from network processing computer. Service provider computer 106 can receive information about plan options and display such information to the user. In some embodiments, service provider computer 106 can facilitate the preparation and sending of messages such as authorization request messages for interactions.

[0048] In some embodiments, service provider computer 106 can be associated with an application program (e.g., service provider application program) stored on user device 102. The service provider application program can be configured to perform operations locally on the user device, which can be described herein as being performed by service provider computer 106.

[0049] The resource provider computer 104 may be associated with a resource providing entity. The resource provider computer 104 may receive, send, and analyze messages, such as authorization request messages, authorization response messages, and messages regarding a plan. The resource provider computer 104 may generate a settlement request for funds requested for the provided resources. The resource provider computer 104 may transmit an authorization request message to the transfer computer 112 during the interaction.

[0050] In some embodiments, the transfer computer 112 may be associated with the resource provider computer 104 and may manage authorization requests on behalf of the resource provider computer 104. In some embodiments, the transfer computer 112 may be operated by an acquirer. The transfer computer 112 may manage the installment function of the resource provider (e.g., by interacting with an API exposed on behalf of the resource provider computer 104 by the network processing computer 108).

[0051] The authorization entity computer 110 may be a system associated with an issuer or entity (e.g., a bank) that has a business relationship with the network processing computer 108 or other entities. The authorization entity computer 110 may determine whether to authorize an interaction associated with the interaction. The authorization entity computer 110 may receive, send, and analyze payment messages, such as authorization request messages and authorization response messages.

[0052] The network processing computer 108 may be positioned between the transfer computer 112 and the authorization entity computer 110. The network processing computer 108 may include a data processing subsystem, network, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. For example, the network processing computer 108 may include a server (e.g., via an external communication interface) coupled to a network interface, and an information database. The network processing computer 108 may be or be part of a transaction processing network. The network processing computer 108 may expose a set of APIs to other entities to provide installment services. The network processing computer 108 may manage access to such APIs (e.g., by managing keys and issuing keys to entities to control access rights). The network processing computer 108 may use any suitable wired or wireless network, including the Internet. Further description of the components and functionality of the network processing computer 108 is provided below with respect to Figure 2 the components and functionality of the network processing computer 108 are further described.

[0053] Figure 2A block diagram of a network processing computer 200 according to an embodiment is shown. The exemplary network processing computer 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The computer-readable medium 208 may include a plurality of modules, the plurality of modules including a communication module 208A, a plan eligibility module 208B, and a plan processing module 208C.

[0054] The memory 202 may be used to store data and code. The memory 202 may be coupled to the processor 204 internally or externally (e.g., a cloud-based data storage device), and may include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device). The memory 202 may store any suitable data described herein.

[0055] The computer-readable medium 208 may include code executable by the processor 204 for performing a method, the method including: receiving, by the network processing computer, an authorization request message including a token and a password during an interaction between a resource provider and a user; determining, by the network processing computer, user credentials associated with the token; determining, by the network processing computer, a plan identifier based on the authorization request message; and providing, by the network processing computer, the plan identifier or plan information associated with the plan identifier to an authorization entity computer.

[0056] In some embodiments, the network processing computer 200 may include any suitable number of modules. For example, the network processing computer 200 may include a communication module 208A, the communication module may include code that enables the processor 204 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities. When the network processing computer 200 receives an electronic message via the network interface 206, the electronic message may be passed to the communication module 208A. The communication module 208A may, together with the processor 204, identify and parse relevant data based on the specific messaging protocol used in the system. Then, the communication module 208A may, together with the processor 204, send any received information to an appropriate module within the network processing computer 200 (e.g., via a system bus, etc.). The communication module 208A may also receive information from one or more modules in the network processing computer 200, and comply with the transmission protocol to generate an electronic message in an appropriate data format such that the message can be sent to one or more entities within the system 100. Then, the electronic message may be passed to the network interface 206 for transmission.

[0057] The network processing computer 200 may further include a plan eligibility module 208B, which may include code that causes the processor 204 to determine whether a particular user, account, or transaction is eligible for one or more installment plans. The plan eligibility module 208B may include code configured to analyze interaction data and / or user data (which may include account data) in conjunction with the processor 204 to make such eligibility determinations. The plan eligibility module 208B may, together with the processor 204, determine whether a user is eligible for one or more plans based on information associated with the user and one or more requirements associated with each plan.

[0058] The network processing computer 200 may further include a plan processing module 208C, which may include code that causes the processor 204 to manage transaction processing across multiple installments. The plan processing module 208C may, together with the processor 204, determine the current step of the plan and the remaining steps of the plan (e.g., the current installment and the remaining installments). The plan processing module 208C may, together with the processor 204, manage the performance of such plan steps (e.g., the settlement of installments).

[0059] The network processing computer 200 may further include a plan eligibility module 208B, which may include code that causes the processor 204 to determine whether a particular user, account, or transaction is eligible for one or more installment plans. The plan eligibility module 208B may include code configured to analyze interaction data and / or user data (which may include account data) in conjunction with the processor 204 to make such eligibility determinations. The plan eligibility module 208B may, together with the processor 204, determine whether a user is eligible for one or more plans based on information associated with the user and one or more requirements associated with each plan.

[0060] In some embodiments, the network processing computer 200 may manage and expose a set of APIs. By way of illustration, the APIs may include a load API, an eligibility check API, a convert-to-installment API, and a scheduler API.

[0061] The network interface 206 may include an interface that may allow the network processing computer 200 to communicate with external computers. The network interface 206 may enable the network processing computer 200 to transfer data to another device (e.g., an authorization entity computer, a resource provider computer, a service provider computer, etc.) and transfer data back from another device. Some examples of the network 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, and so on. The wireless protocols enabled by the network interface 206 may include Wi-Fi TMData transmitted via network 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, which may include data or instructions, may be provided between network 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 wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0062] Embodiments may use the systems and devices described herein to at least establish, manage, and / or implement installment plans. Figures 3-8 Some examples of such methods are described.

[0063] Although Figure 2 a block diagram of network processing computer 200 is shown, software functionality may alternatively or additionally exist in an authorized entity computer.

[0064] Figure 3 A flowchart of a pre-interaction setup process according to an embodiment is shown. Figure 3 The method shown in will be described in the context of setting up a plan-capable context in user device 308 prior to an interaction. Figure 3 The method of may be performed by network processing computer 302, service provider computer 304, and user device 308.

[0065] Prior to step 310, network processing computer 302 or an authorized entity computer (e.g., an issuer computer) (not shown) may determine that the user is eligible for a plan that the user was previously ineligible for. Network processing computer 302 or an authorized entity computer may determine user eligibility in any suitable manner. Additionally, different plans may have different eligibility requirements. For example, network processing computer 302 or an authorized entity computer may determine whether a user is eligible based on the user's interaction history, fraud probability, a comprehensive score associated with the user (e.g., a credit score, etc.), age, location, affiliation with a resource provider (e.g., a rewards member, an account holder, etc.), employer, etc.

[0066] In step 310, the network processing computer 302 (or the authorized entity computer) may notify the service provider computer 304 of a planned eligibility change of an existing token stored by the service provider computer 304. For example, a first user may be associated with a first token stored by the service provider computer 304. Previously, the first user may not have been eligible for a particular plan (e.g., an installment plan) implemented during the interaction. The network processing computer 302 (or the authorized entity computer) may notify the service provider computer 304 of the eligibility change. For example, the network processing computer 302 (or the authorized entity computer) may provide an eligibility change message that includes an indication of the eligibility change and data that may be associated with the user (e.g., a user identifier, a user device identifier, a token associated with the user, a PAN reference identifier, etc.).

[0067] In step 320, upon receiving the eligibility change notification or at any suitable time point thereafter, the service provider computer 304 may provide an API call (or other suitable communication type) to the network processing computer 302 (or the authorized entity computer) to obtain a plan identifier. For example, the service provider computer 304 may generate a plan request message and provide the plan request message to the network processing computer 302. The service provider computer 304 may further pass a token, a PAN reference identifier, or other suitable user identifier to the network processing computer 302 such that the network processing computer 302 can provide the relevant plan identifier.

[0068] In step 330, after receiving the plan request message from the service provider computer 304, the network processing computer 302 may obtain user credentials associated with the received token or PAN reference identifier. For example, the network processing computer 302 may obtain user credentials associated with the received token by providing the token in a user credential request message to a token provider computer. The token provider computer may include a database of stored tokens and associated user credentials. The token provider computer may retrieve the user credentials associated with the stored token that matches the received token. The token provider computer then provides the user credentials to the network processing computer 302.

[0069] In step 340, after obtaining the user credentials, the network processing computer 302 (or the authorization entity computer) may obtain the eligible plan identifiers associated with the user. For example, the network processing computer 302 (or the authorization entity computer) may retrieve one or more plan identifiers stored in the plan database in association with the user credentials. The network processing computer 302 (or the authorization entity computer) may obtain any number of eligible plan identifiers from the plan database. For example, a user may be eligible for three different plans. The network processing computer 302 (or the authorization entity computer) may retrieve the three plan identifiers for the three different plans that the user is eligible for.

[0070] In some embodiments, before obtaining the eligible plan identifiers, the network processing computer 302, the service provider computer 304, or the authorization entity computer may perform an eligibility check to verify the user's eligibility for one or more plans. Each plan may have a plan identifier that identifies the plan. For example, the plan identifier for the first plan may be "Plan 1". In some embodiments, the plan identifier may be generated by the entity providing the plan (e.g., by the authorization entity of the authorization entity computer that provides the plan to the user of the user device 308). In some embodiments, the plan identifier may describe the plan. For example, the plan identifier may be "Six-Month Plan ABC".

[0071] In some embodiments, a user may be eligible for multiple plans. For example, a user may be eligible for three plans. The network processing computer 302 may obtain the eligible plan identifiers for the three plans based on the user credentials.

[0072] In step 370, the network processing computer 302 may provide a plan response message to the service provider computer 304. The plan response message may include one or more plan identifiers. In some embodiments, the plan response message may also include a token and / or a PAN reference identifier.

[0073] The network processing computer 302 may also send plan metadata in the plan response message. The plan metadata may include any suitable data associated with the plans available to the user. For example, the plan metadata may include the plan length, the plan amount, the plan expiration date, interest charge information, etc.

[0074] In step 380, after receiving the plan response message, the service provider computer 304 may provide at least the plan identifiers to the user device 308. In some embodiments, the service provider computer 304 may provide the plan response message to the user device 308. In some embodiments, the service provider computer 304 may store the plan response message and / or the data included therein.

[0075] In step 390, the user device 308 may display the data included in the planned response message. For example, as Figure 4 shown. The user device 308 may display eligible plans in the application of the user device and / or the settings of the user device. During the interaction, the user may select a plan shown on the user device 308 for interaction. In some embodiments, the user device 308 may display a list of plans to the user.

[0076] Figure 4 A block diagram showing a user plan interface according to an embodiment. Figure 4 Shows a first user interface 410 and a second user interface 420. The first user interface 410 may allow the user to view plans in the settings of the user device. The second user interface 420 may allow the user to view plans in the applications installed on the user device.

[0077] The first user interface 410 includes an illustration of user credentials 412 that the user can use for interaction when implementing the plan. To increase security, the user credentials may be hidden. For example, the hidden user credentials may be "****1234". In some embodiments, the first user interface 410 may include a token or PAN reference identifier to supplement or replace the user credentials 412.

[0078] The first user interface 410 may include an available plans button 414. When selected by the user, the available plans button 414 may provide a list of plans that the user is eligible for.

[0079] The second user interface 420 includes an illustration of user credentials 422 that the user can use for interaction when implementing the plan. The user credentials 422 may be hidden user credentials. For example, the hidden user credentials may be "****1234".

[0080] The second user interface 420 includes a plan implementation option 424. The plan implementation option 424 may be a switch, button, link, etc. that allows the user to select to implement the selected plan. For example, the plan implementation option 424 in the second user interface 420 shows an installment plan with an option to divide a payment of $648.00 into monthly payments of $108.00 for 6 months.

[0081] The second user interface 420 includes a list of hidden user credentials between which the user can make a selection. For example, the user may be associated with three different user credentials (e.g., three different payment accounts). The user can select which hidden user credential to use for interaction. In some embodiments, when the user selects a user credential, the user credentials 422 may be updated to reflect the selected credential.

[0082] Figure 5A flowchart showing a planning and interaction processing method according to an embodiment. Figure 5 The method may be performed by the user device 502, the resource provider computer 504, the service provider computer 506, the transmission computer 508, the network processing computer 510, and the authorization entity computer 512 during an interaction between a user of the user device 502 and a resource provider (e.g., a merchant) of the resource provider computer 504.

[0083] In step 520, the user may choose to initiate an interaction with the resource provider. For example, the user may initiate a payment transaction with the resource provider of the resource provider computer 504. For example, the user may select an "Add to Cart" button on the user device 502, where the "Add to Cart" button is displayed on a resource provider web page provided by the resource provider computer 504.

[0084] In step 522, after the user chooses to initiate the interaction, the resource provider computer 504 may check whether the use of the service provider computer 506 is supported. In some embodiments, the service provider computer 506 may provide a digital wallet to the user device 502. In this case, the resource provider computer 504 may determine whether the current interaction supports the digital wallet of the service provider computer 506. The resource provider computer 504 may check whether the user has added a card to the digital wallet. In some embodiments, the resource provider computer 504 may check with the service provider computer 506 whether one or more plans are available for the user.

[0085] In step 524, if the resource provider computer 504 determines that the service provider computer 506 is supported in the current interaction, the resource provider computer 504 may then display an option for the user to choose whether to use the service provider computer 506.

[0086] In some embodiments, if the resource provider computer 504 receives an indication from the service provider computer 506 that one or more plans are available, the resource provider computer 504 may display a planned interaction button. For example, the user may see a message such as "Plans Available", "Installment Payments Available", etc. The buttons and messages described herein may be presented via any suitable user interface.

[0087] In step 526, the user may choose to continue using or not using the service provider computer 506. The user device 502 may provide the resource provider computer 504 with a choice of whether to use the service provider computer 506. If the user chooses to use the service provider computer 506 during the interaction, the process may proceed to step 528.

[0088] In step 528, after receiving a user's selection of a service provider computer 506 using an option (e.g., a digital wallet button), the resource provider computer 504 may send an interaction request message to the relevant service provider computer 506. For example, the user device 502 may provide information about the service provider computer 506 along with the selection of using the service provider computer 506 to the resource provider computer 504, such that the resource provider computer 504 can determine the service provider computer 506 associated with the user. The interaction request message may request the plans for which the user is eligible.

[0089] In step 530, after receiving the interaction request message, the service provider computer 506 may check, via the stored plan metadata, whether the user performing the interaction or the interaction itself is eligible for one or more plans. For example, the service provider computer 506 may have previously received the plan metadata for two different plans for which the user is eligible (e.g., as Figure 3 described). The service provider computer 506 may also store a plan identifier associated with each plan.

[0090] In step 532, if the user of the user device 502 is eligible for the plan of the current interaction, the service provider computer 506 may provide a message to the resource provider computer 504 that includes at least the eligible plan metadata and the associated plan identifier. In some embodiments, the service provider computer 506 may provide other suitable information to the resource provider computer 504, such as a token associated with the user's user credentials.

[0091] In step 534, after receiving the eligible plan metadata and the plan identifier, the resource provider computer 504 may display an interaction table (e.g., on a web page) to the user on the user device 502 that includes at least the available plans. In some embodiments, the interaction table may also include terms and conditions, interaction data, shipping data, etc. For example, the user device 502 may receive one or more plans from the service provider computer via the resource provider computer during the interaction.

[0092] In step 536, the user may select any suitable button provided on the web page, e.g., a checkout or payment button. The user device 502 may receive from the user a selection of a plan from one or more plans. For example, the user device 502 may present a list of available plans to the user for selection and then receive an input via a touch screen indicating the selection of one plan.

[0093] In some embodiments, at step 538, the user may be prompted to authenticate themselves. For example, the user may be prompted to verify a password, biometric, two-factor authentication code, or any other suitable information known to or received from the user. The user device 502 may authenticate the user in any suitable manner known to those skilled in the art. In some embodiments, the user may be prompted to authenticate themselves before step 536, step 526, step 520, or any other suitable step.

[0094] At step 540, the user device 502 may generate a password (e.g., TAVV) using the plan identifier associated with the selected plan. If no installment plan is selected, the password may be generated without a plan identifier associated with the selected plan. In some embodiments, the user device 502 may also generate the password using the merchant's public key. Alternatively, a symmetric key generated or stored within the user device 502 may be used to generate the password.

[0095] In addition to the selected plan identifier, additional data may be used to generate the password. For example, the password may be generated based on the resource provider identifier, the interaction amount, a counter, a timestamp, and / or any other suitable data associated with the interaction. In some embodiments, the password may be a dynamic, one-time use code for each interaction accompanied by a token. For example, the password may be TAVV, which is a 20-byte base-64 encoded binary value.

[0096] In some embodiments, step 540 may be performed by a service provider application installed on the user device 502. For example, the service provider application on the user device 502 may use the plan identifier associated with the selected plan to generate the password. In other embodiments, the user device 502 may request the service provider computer 506 to generate the password and provide the password to the resource provider computer 504.

[0097] At step 542, after generating the password, the user device 502 may provide the token and the password to the resource provider computer 504. In some embodiments, if the user device 502 requests the service provider computer 506 to generate the password, at step 542, the service provider computer 506 may provide the token and the password to the resource provider computer 504.

[0098] In step 544, after receiving the token and password, the resource provider computer 504 may generate an authorization request message that includes the token, password, and interaction data. The interaction data may be data associated with the interaction. The interaction data may include the transaction amount. In some embodiments, the interaction data may indicate different entities that are parties to the interaction and the value or information being exchanged. The interaction data may include the interaction amount, information associated with the sender (e.g., token or account information, alias, device identifier, contact address, etc.), information associated with the recipient (e.g., token or account information, alias, device identifier, contact address, etc.), a one-time value (e.g., random value, nonce, timestamp, counter, etc.), and / or any other suitable information. An example of the interaction data may be transaction data.

[0099] In step 546, after generating the authorization request message, the resource provider computer 504 provides the authorization request message to the transport computer 508.

[0100] In step 548, after receiving the authorization request message from the resource provider computer 504, the transport computer 508 provides the authorization request message to the network processing computer 510.

[0101] In step 550, after receiving the authorization request message, the network processing computer 510 may detokenize the token to obtain user credentials (e.g., PAN or other suitable credentials associated with the user). For example, the network processing computer 510 may obtain the user credentials associated with the received token by providing a user credential request message that includes the token to a token provider computer (not shown). The token provider computer may include a database of stored tokens and associated user credentials. After receiving the user credential request message, the token provider computer may retrieve the user credentials associated with the stored token that matches the token. The token provider computer then provides the user credentials to the network processing computer 510.

[0102] In step 552, after obtaining the user credentials, the network processing computer 510 may determine the plan identifier based on the password. The network processing computer 510 may obtain the plan identifier from the password because the password was previously generated using the plan identifier. For example, in some embodiments, the network processing computer 510 may decrypt the password. The network processing computer 510 may use asymmetric or symmetric cryptography techniques to decrypt the password. For example, the user device 510 may use an assigned or generated symmetric key to create the password. The network processing computer 510 may also store the same symmetric key. After receiving the password, the network processing computer 510 may use the symmetric key to decrypt the password to obtain the data encrypted into the password by the user device 502. In some embodiments, the user device 510 may determine a derived key (e.g., a session key) based on predetermined data elements (e.g., user device identifier, network processing computer public key, etc.). The user device 510 may use the derived key to create the password. Then, once the network processing computer 510 receives the password, the network processing computer 510 may determine the derived key based on the predetermined data elements. Then, the network processing computer 510 may use the derived key to decrypt the password. In some embodiments, the network processing computer 510 and the user device 510 may use the Diffie-Hellman key exchange algorithm process to create the password key.

[0103] In some embodiments, the network processing computer 510 may verify the password by comparing the data obtained when decrypting the password with the previously stored data. For example, the user device identifier may be included in the password by the user device 502. The network processing computer 510 may obtain the user device identifier after decrypting the password. The network processing computer 510 may compare the user device identifier with the user device identifier previously stored in the database (e.g., stored during registration).

[0104] After determining the plan identifier of the plan selected by the user, the network processing computer 510 may directly provide the plan identifier or plan information associated with the plan identifier (e.g., plan name, plan details, etc.) to the authorization entity computer 512 in a separate communication outside of the authorization process. For example, the plan identifier or plan information may be provided to the authorization entity computer 512 via an API. The user credentials and / or tokens may also be passed to the authorization entity computer 512 via the API to help identify the user who selected the plan. If the plan identifier and / or plan information are sent from the network processing computer 510 to the authorization entity computer 512 outside of the authorization process, the authorization request message sent to the authorization entity will not have the plan identifier or plan information.

[0105] In some embodiments, the network processing computer 510 may modify the authorization request message. For example, the network processing computer 510 may replace the token in the authorization request message with user credentials. If the plan identifier is not sent to the authorization entity computer 512 outside of the authorization process, the network processing computer 510 may also insert the plan identifier into the authorization request message. The modified authorization request message may then include user credentials, a password, a plan identifier, and interaction data. In some embodiments, the network processing computer 510 may also insert the password verification result into the authorization request message.

[0106] In step 558, after modifying the authorization request message, the network processing computer 510 may provide the modified authorization request message to the authorization entity computer 512. In some embodiments, as noted above, in addition to or instead of including the plan identifier in the authorization request message, the network processing computer 510 may send the plan identifier or plan information associated with the plan identifier to the authorization entity computer 512 via an API call (e.g., a plan acceptance API) or via some other suitable communication type.

[0107] In step 560, after receiving the authorization request message, the authorization entity computer 512 may determine whether to authorize the interaction. Sometimes, the authorization entity computer 512 may also implement a plan associated with the plan identifier and / or plan information. The authorization entity computer 512 may determine whether to authorize the interaction based on any suitable data known to the authorization entity computer 512 (e.g., interaction data, fraud data, user data, etc.). The authorization entity computer 512 may generate an indication of whether the interaction is authorized. For example, if the authorization entity computer 512 determines to authorize the interaction, the authorization entity computer 512 may generate an indication that the interaction is authorized. If the authorization entity computer 512 determines not to authorize the interaction, the authorization entity computer 512 may generate an indication that the interaction is not authorized. The authorization entity computer 512 may also generate an indication of whether the selected plan is authorized.

[0108] In step 562, after determining whether to authorize the interaction, the authorization entity computer 512 may generate an authorization response message in response to the authorization request message. The authorization response message may include an indication of whether the interaction is authorized. The authorization response message may also include user credentials and a plan identifier. In some embodiments, the authorization response message may include an indication of whether the selected plan is authorized.

[0109] In step 564, the authorization entity computer 512 may provide the authorization response message to the network processing computer 510.

[0110] In step 566, after receiving the authorization response message from the authorization entity computer 512, the network management computer 510 may modify the authorization response message to include a token. For example, the network processing computer 510 may replace the user credentials in the authorization response message with a token. In some embodiments, the network processing computer 510 may obtain the token from a token provider computer. For example, the network processing computer 510 may provide a token request message including user credentials to the token provider computer. After receiving the token request message, the token provider computer may determine the token associated with the user credentials (e.g., in a token and user credentials database). The token provider computer may provide a token response message including the token to the network processing computer 510. Then, the network processing computer 510 may modify the authorization response message to include the token.

[0111] In step 568, after including the token in the authorization response message, the network processing computer 510 may provide the authorization response message to the transport computer 508.

[0112] In step 570, after receiving the authorization response message from the network processing computer 510, the transport computer 508 may provide the authorization response message to the resource provider computer 504.

[0113] In step 572, after receiving the authorization response message, the resource provider computer 504 may provide the authorization response message to the user device 502. For example, the resource provider computer 504 may provide a web page indicating whether the interaction and schedule are authorized to the user device 502.

[0114] At the end of the day or at any other suitable time period, a clearing and settlement process may occur between the transport computer 508, the network processing computer 510, and the authorization entity computer 512.

[0115] Figure 6 A flowchart showing an alternative schedule and interaction processing method according to an embodiment. Figure 6 The method may be performed by the user device 602, the resource provider computer 604, the service provider computer 606, the transport computer 608, the network processing computer 610, and the authorization entity computer 612 during an interaction between a user of the user device 602 and a resource provider of the resource provider computer 604. In some embodiments, the steps performed by the service provider computer 606 may be performed by a service provider application stored on the user device 602. Figures 7A-7B A block diagram showing a user interface during interaction processing according to an embodiment. Reference will be made to Figure 6 the method described Figures 7A-7B in the user interface shown.

[0116] Steps 620 - 638 may be similar to steps 520 - 538 and will not be repeated in their entirety here. For example, during steps 620 - 638, a user of user device 602 may initiate an interaction with resource provider computer 604 to obtain a resource. The user may use user device 602 to select interaction options presented on a web page provided by resource provider computer 604. For example, Figure 7A the first user interface 702 and the second user interface 704 include interaction options (e.g., buttons) on a resource provider-hosted web page. The web page shown in the first user interface 702 may be a resource (e.g., espresso machine) web page. The web page shown in the second user interface 704 may be a "shopping cart" web page, which may indicate which resources (e.g., espresso machines) the user has selected. The user may select to add a resource to the shopping cart on the first user interface 702 and then select to perform the interaction on the second user interface 704. Additionally, the second user interface 704 may allow the user to select between different interaction options. For example, the second user interface 704 includes a "checkout" option and a "purchase using service provider computer" option, which respectively allow the user to perform the interaction and perform the interaction using the service provider computer.

[0117] Return reference Figure 6 , resource provider computer 604 may receive an indication that the user has selected to perform the interaction (e.g., the user may select "purchase using service provider computer"). Resource provider computer 604 may send an interaction request message to the relevant service provider computer 606.

[0118] At step 632, service provider computer 606 may respond to resource provider computer 604 with an interaction response message that includes a plan identifier and plan metadata. The interaction response message may include any suitable information about the interaction and the plans available to the user. For example, in some embodiments, the interaction response message may include purchase line items and totals, billing and shipping information, contact information, installment information, etc.

[0119] In step 634, after receiving the interaction response message, the resource provider computer 604 may display the plan and / or interaction data (e.g., interaction table) to the user via the web page displayed on the user device 602. For example, the resource provider computer 604 may send the plan metadata, plan identifier, interaction data, and / or other data related to and / or received from the service provider computer 606 to the user device 602. The interaction table may include any data included in the payload received from the service provider computer 606. The user may, for example, review the interaction table. In addition, the user may choose to continue the interaction based on the received interaction table. For example, if the plan is an installment plan, the user may select an installment plan from the list of installment plans. As a schematic example, Figure 7A the third user interface 706 includes a resource provider web page presenting the available plans and interaction data.

[0120] In some embodiments, in step 638, the user may be prompted to authenticate themselves, similar to Figure 5 step 538. For example, the user may be prompted to verify a password, biometric, two-factor authentication code, or any other suitable information known to or received from the user.

[0121] In step 640, after receiving the user's selection of a plan from the user, the user device 602 may determine the plan identifier based on the selected plan. For example, each plan presented on the resource provider web page may be associated with a plan identifier. After selecting the plan to be utilized during the interaction, the user device 602 may obtain the plan identifier of the selected plan.

[0122] In step 642, after determining the plan identifier, the user device 602 may obtain a token. The token may be associated with the user's user credentials. The token may be stored by the service provider computer 606. In some embodiments, the user device 602 may request the token from the service provider computer 606. In other embodiments, a service provider application associated with the service provider computer 606 may be installed on the user device 602. The service provider application may securely store the token. The user device 602 may obtain the token from the service provider application.

[0123] In step 644, after determining the plan identifier and obtaining the token, the user device 602 may provide the plan identifier and the token to the network processing computer 610. In some embodiments, the user device 602 may also include interaction data and / or other data related to the interaction, the resource provider computer 604 (e.g., resource provider computer identifier), the service provider computer 606 (e.g., service provider computer identifier), etc.

[0124] In step 646, after receiving the plan identifier and the token, the network processing computer 610 may temporarily store the plan identifier associated with the token for the current interaction. The network processing computer 610 may store the selected plan identifier and / or any other suitable data associated with the interaction (e.g., interaction data) associated with the user (e.g., via a user identifier or token).

[0125] In step 648, after determining the plan identifier and obtaining the token, the user device 602 may provide the token to the resource provider computer 604. In some embodiments, the service provider computer 606 may perform step 646 before, after, or concurrently with the step 644. In some embodiments, the user device 602 may further generate a password for the interaction, as described herein. The password may or may not be generated based on the plan identifier. The user device 602 may provide the password along with the token to the resource provider computer 604. Figure 7B The fourth user interface 708 includes a notification to the user indicating that the resource provider computer 604 has processed the interaction and is ready to submit an authorization request message to the authorization entity computer 612. For example, the fourth user interface 708 includes a loading icon and a notification of "Submit Interaction".

[0126] In step 650, after receiving at least the token, the resource provider computer 604 may generate an authorization request message including the token. The authorization request message may further include interaction data and / or a password.

[0127] In step 652, after generating the authorization request message, the resource provider computer 604 may send the authorization request message to the transmission computer 608. Figure 7B The fifth user interface 710 includes a notification to the user indicating that the resource provider computer 604 has submitted the authorization request message to the authorization entity computer 612. For example, the fifth user interface 710 includes a loading icon and a notification of "Authorize Interaction".

[0128] In step 654, after receiving the authorization request message from the resource provider computer 604, the transmission computer 608 may provide the authorization request message to the network processing computer 610.

[0129] In step 656, after receiving the authorization request message, the network processing computer 610 may obtain user credentials associated with the token. For example, the network processing computer 610 may detokenize the token to determine the user credentials (e.g., PAN). In some embodiments, the network processing computer 610 may detokenize the token together with a token provider computer (not shown), as described in further detail herein.

[0130] In some embodiments, the network processing computer 610 may have previously determined the plan identifier during step 646 and stored the plan identifier identifying data (e.g., user identifier, user device identifier, token, etc.) associated with the user and / or user device 602. In this case, at step 658, the network processing computer 610 may retrieve the plan identifier from the memory (or database).

[0131] At step 660, after obtaining the plan identifier of the selected plan, the network processing computer 610 may modify the authorization request message to include the user credentials and the plan identifier or plan information associated with the plan identifier, as described above. Alternatively, the plan identifier and / or plan information associated with the plan identifier may be sent to the authorization entity computer outside of the authorization process (e.g., via an API).

[0132] At step 662, the network processing computer 610 may send the modified authorization request message to the authorization entity computer 612 for authorization. The network processing computer 610 may provide the modified authorization request message to the authorization entity computer 612 via any suitable communication channel.

[0133] Steps 664 - 676 are similar to steps 560 - 572 and will not be repeated in their entirety here. At step 676, after the resource provider computer 604 receives the authorization response message from the network processing computer 610 via the transport computer 608, the resource provider computer 604 may provide an indication of whether the interaction is authorized to the user via the web page accessed and displayed by the user device 602. For example, Figure 7B the sixth user interface 712 includes a web page indicating that the interaction is authorized.

[0134] Figure 8 A schematic diagram showing a technique 800 for post - interaction installment processing according to some embodiments. The network computer 810 (substantially similar to Figure 1 the network processing computer 108) may manage installment plan processing for entities such as a user 802 (e.g., via Figure 1 the user device 102), a resource provider computer 806 (substantially similar to Figure 1 the resource provider computer 104), a transport computer 808, and an authorization computer 812 (substantially similar to Figure 1 the authorization entity computer 110), etc.

[0135] In step 820A, the resource provider computer 806 may send a settlement request message to the transfer computer 808. The settlement request message may request funds for the total amount of the interaction. The settlement request message may also include additional data, such as interaction data (e.g., timestamp, transaction identifier, etc.) and / or installment plan identifier. In step 820B, the transfer computer 808 may send the settlement request message to the network computer 810.

[0136] The transfer computer 808 may receive the settlement request message and analyze the data therein (e.g., installment plan identifier). The transfer computer 808 may identify the installment plan associated with the settlement request. In step 820C, the transfer computer 808 may send the settlement request message to the authorization computer 812, and the settlement request message is received by the authorization computer in step 820D.

[0137] In response to receiving the settlement request message, the authorization computer 812 may analyze the settlement request message and determine to proceed with the settlement. In step 822A, the authorization computer 812 may send a settlement response message for the total amount to the network computer. In step 822B, the network computer 810 may send the settlement response message to the transfer computer 808. In step 822C, the transfer computer 808 may send the settlement response message to the resource provider computer 806. In step 822D, the resource provider computer 806 may receive the settlement response message. The settlement may be completed in full. For example, if the user 802 purchases a resource (e.g., a TV) that costs $699.00, the authorization computer 812 may settle with the network computer 810 and the transfer computer 808 for the same cost, i.e., $699.00.

[0138] In step 824, the network computer 810 (or the authorization computer 812) may set up an installment record. In some embodiments, the installment record may be a temporary account. The temporary account may be a virtual account (e.g., the virtual account may exist as a ledger for record-keeping purposes). Alternatively or additionally, the temporary account may be a prepaid account (e.g., the prepaid account may be loaded with funds and limited to the loaded funds). The installment record may be stored in the network computer 810 in association with the installment plan identifier and the associated interaction data. For example, the network computer may create a temporary account for the installment plan and an identifier for the created temporary account for the installment plan. The network computer may record information including the total amount of the installment plan / interaction to the temporary account associated with the account identifier. Thus, the installment record may be a temporary account with a starting balance of the total amount.

[0139] In step 826, the network computer 810 may process the installment payment. This may occur periodically according to certain conditions (e.g., receiving an API call from an authorization computer and / or determining that an installment payment time has occurred). In some embodiments, the installment payment time may be a specific time that has elapsed since the last installment payment and / or since the interaction (e.g., for monthly installment payments, when one month has elapsed since the day the transaction was authorized, the network computer 810 may determine that the installment payment time has occurred). In some embodiments, the installment payment time may be calculated based on an installment period (e.g., processing the monthly installment payment starts two weeks later to account for messaging and funds transfer times).

[0140] In step 828, the authorization computer 812 may process the installment payment and send a statement to the user 802. For example, based on the information received from the network computer 810, the authorization computer 812 may determine that the user 802 should be charged the full amount of the transaction, but bill the installment payment amount of $133 on the statement. The authorization computer 812 may prepare a statement with the installment payment amount and send the statement to the user 802. The user may receive and view the statement of the installment payment in step 830.

[0141] Embodiments of the present disclosure have many advantages. For example, the embodiments provide an effective way to indicate to a network processing computer that the current interaction is an interaction utilizing a plan and detailed information about the plan. Currently, the interactions between resource providers and users include various messages of a standard length. The embodiments provide a method in which additional information such as a plan identifier can be provided from a resource provider computer to a network processing computer without extending the length of the message or adding additional messages between entities. This is because the password is generated using the plan identifier of the selected plan.

[0142] In addition, during a typical interaction, if a plan is to be selected and implemented, the user is notified of the available plans after the resource provider computer submits interaction data for authorization. For example, the network processing computer receives an authorization request message from the resource provider computer that includes the interaction data for authorizing the interaction. Then, the network processing computer may contact the user to ask if the user wants to select a plan, thus slowing down the processing of the interaction due to messaging and waiting for the user input. The embodiments achieve sending fewer messages during the processing of the authorization request message, thereby reducing the time spent on authorizing the interaction.

[0143] Although the steps in the above flowcharts and process flows are shown or described in a specific order, it should be understood that embodiments of the present invention may include methods having steps in a different order. Additionally, steps may be omitted or added, and they may still be within the embodiments of the present invention.

[0144] Any software component or functionality 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 a hard disk drive or a floppy disk), or optical media (such as a compact disc (CD) or a digital versatile disc (DVD)), flash memory, and the like. The computer-readable medium can be any combination of such storage or transmission devices.

[0145] Such programs can also be encoded and transmitted using a carrier signal suitable for transmission via a wired network, optical network, and / or wireless network compliant with various protocols including the Internet. Thus, a computer-readable medium according to an embodiment of the present invention can be created using a data signal encoded with such a program. A computer-readable medium encoded with program code can be encapsulated 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 (such as a hard disk 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.

[0146] 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. Thus, the scope of the present invention should not be determined by reference to the above description, but should be determined by reference to the pending claims along with their full scope or equivalents.

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

[0148] As used herein, 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: During an interaction between a resource provider and a user using a user device by a network processing computer, and after the user device receives a plan identifier from a resource provider computer operated by the resource provider and generates a password by encrypting at least the plan identifier, receiving an authorization request message from the resource provider computer, the authorization request message including a transaction amount, a token, and the password encoding the plan identifier; Decrypting, by the network processing computer, the password to obtain the plan identifier; Detokenizing, by the network processing computer, the token to obtain a credential associated with the token; Providing, by the network processing computer, the plan identifier or plan information associated with the plan identifier to an authorization entity computer; And Sending, by the network processing computer, a modified authorization request message to the authorization entity computer, the modified authorization request message including the transaction amount and the credential, wherein the authorization entity computer authorizes the interaction based at least on the transaction amount.

2. The method according to claim 1, wherein providing the schedule identifier from the network processing computer to the authorization entity computer includes: Providing the plan identifier to the authorization entity computer via an API.

3. The method according to claim 1, wherein detokenizing comprises: Providing, by the network processing computer, the token to a token provider computer, wherein the token provider computer determines the credential associated with the token; And Receiving, by the network processing computer, the credential from the token provider computer.

4. The method according to claim 1, further comprising: Receiving, by the network processing computer, an authorization response message from the authorization entity computer, wherein the authorization response message includes an indication of whether the interaction is authorized.

5. The method according to claim 4, further comprising: Providing, by the network processing computer, the credential to a token provider computer, wherein the token provider computer determines the token associated with the credential; Receiving, by the network processing computer, the token from the token provider computer; Modifying, by the network processing computer, the authorization response message to include at least the indication of whether the interaction is authorized and the token; And Providing, by the network processing computer, the authorization response message to the resource provider computer associated with the resource provider.

6. A system, comprising: A user device, including a first processor and a first computer-readable medium, the first computer-readable medium including code executable by the first processor for performing a first operation, the first operation including: Receiving a plan identifier from a resource provider computer; and Generating a password by encrypting at least the plan identifier; and A network processing computer, including: A second processor; and A second computer-readable medium coupled to the second processor, the second computer-readable medium including code executable by the second processor for implementing a second operation, the second operation including: Receive an authorization request message including a transaction amount, a token, and the password encoding the program identifier from the resource provider computer operated by the resource provider; Decrypt the password to obtain the program identifier; Detokenize the token to obtain a credential associated with the token; Provide the program identifier or program information associated with the program identifier to the authorization entity computer; and Send a modified authorization request message to the authorization entity computer, the modified authorization request message including the transaction amount and the credential, wherein the authorization entity computer authorizes the authorization request message at least based on the transaction amount.

7. The system according to claim 6, wherein the network processing computer further includes a network interface coupled to the second processor.

8. The system according to claim 6, wherein the first operation further includes providing the password and the token to the resource provider computer, and wherein the resource provider computer provides the authorization request message to the network processing computer.

9. The system according to claim 6, wherein the network processing computer further includes on the second computer-readable medium: A communication module; And A program processing module.

10. The system according to claim 6, wherein the credential includes a PAN.

11. A method, comprising: Receiving, by a user device, one or more programs from a service provider computer via a resource provider computer during an interaction between a user of the user device and a resource provider of the resource provider computer; Receiving, by the user device, a selection of a program from the one or more programs from the user; Determining, by the user device, a program identifier based on the selected program; Obtaining, by the user device, a token; Generating, by the user device, a password by encrypting at least the program identifier using an encryption key; And Providing, by the user device, the program identifier in the encoded form in the password and the token to the resource provider computer, wherein the resource provider computer subsequently generates an authorization request message including a transaction amount, the password, and the token and subsequently provides the authorization request message to a network processing computer, the network processing computer detokenizes the token to obtain a credential associated with the token, decrypts the password using another encryption key to obtain the program identifier, and sends a modified authorization request message including the transaction amount and the credential to an authorization entity computer, the authorization entity computer authorizing the interaction at least based on the transaction amount.

Images