System, method, and computer program product for dynamically configuring installment-based transactions during authentication processing

Abstract

Systems, methods, and computer program products are provided for dynamically configuring installment-based transactions during processing. The system includes a processor configured to receive a first authentication request from a merchant system, the first authentication request associated with a transaction between a user and the merchant. The processor is also configured to determine eligibility for installment payment based on the first authentication request and generate a unique uniform resource locator (URL) associated with an installment selection interface. The unique URL is configured to permit access to the installment selection interface. The processor is further configured to transmit the unique URL to the merchant system and receive a user selection of an installment plan via the installment selection interface. The processor is further configured to generate a second authentication request and cause an issuer system to initiate an installment-based transaction, by transmitting the second authentication request to the issuer system.

Description

SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR DYNAMICALLY CONFIGURING INSTALLMENT-BASED TRANSACTIONS DURING AUTHENTICATION PROCESSINGCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 570,245 filed March 27, 2024, the disclosure of which is hereby incorporated by reference in its entirety.BACKGROUND1 . Technical Field

[0002] This disclosure relates generally to electronic transaction networks and, in non-limiting embodiments or aspects, to systems, methods, and computer program products for dynamically configuring installment-based transactions during authentication processing.2. Technical Considerations

[0003] A user may desire to initiate a transaction with a merchant in an electronic payment processing network, in which the transaction is configured as an installmenttype transaction (e.g., where a merchant account is initially credited for a full amount of a transaction by an issuer of a payment device of the user, but the user may pay for the full amount, reimbursing the issuer, in periodic installments). Installment-type transactions previously required pre-configuration of each merchant system in the network to enable each merchant to allow users to complete installment-type transactions. Because of this, for a plurality of merchants, a plurality of merchant systems must be pre-configured, which increases the memory used, system update time, points of potential installment error, and / or the like in the aggregate network. In such networks, if a merchant has not been previously configured for correct message formatting, message content, and data flow, the electronic payment processing network may not be functionally operable for installment payments when users transact with the non-configured merchant.

[0004] Accordingly, there is a need in the art to permit users to initiate transactions as installment-based transactions without pre-configuring merchant systems for integration with the installment-type transaction solution, and to configure transactionsas installment-based transactions dynamically during multi-domain authentication flow.SUMMARY

[0005] Accordingly, provided are improved systems, methods, and computer program products for dynamically configuring installment-based transactions during authentication processing.

[0006] According to non-limiting embodiments or aspects, provided is a system for dynamically configuring installment-based transactions during authentication processing. The system includes at least one processor. The at least one processor is configured to receive a first authentication request from a merchant system of a merchant. The first authentication request is associated with a transaction between a user and the merchant for a first amount. The at least one processor is also configured to determine eligibility for installment payment based on the first authentication request. The at least one processor is further configured to generate a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system. The unique URL is configured to permit access from a computing device of the user to the installment selection interface. The at least one processor is further configured to transmit the unique URL to the merchant system. The at least one processor is further configured to receive a user selection of an installment plan from the computing device via the installment selection interface. The at least one processor is further configured to generate a second authentication request identifying the user selection of the installment plan and including the first amount. The at least one processor is further configured to cause an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

[0007] In some non-limiting embodiments or aspects, the at least one processor may be further configured to, in response to receiving the first authentication request, transmit an issuer-side authentication request to the issuer system based on the transaction for the first amount. The at least one processor may be further configured to receive an issuer-side authentication response from the issuer system. The at least one processor may be further configured to, in response to receiving the issuer-side authentication response, determine the eligibility for installment payment. The at leastone processor may be further configured to, in response to determining that the transaction is eligible for installment payment, generate the unique URL.

[0008] In some non-limiting embodiments or aspects, the at least one processor may be further configured to, proximal to generating the unique URL, determine at least one optional installment plan based on the transaction and the first amount. The at least one processor may be further configured to display the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

[0009] In some non-limiting embodiments or aspects, each optional installment plan of the at least one optional installment plan may be associated with an interval period and an installment payment amount. The second authentication request may include data of the interval period and the installment payment amount associated with the user selection of the installment plan.

[0010] In some non-limiting embodiments or aspects, the at least one optional installment plan may include a plurality of optional installment plans. Each optional installment plan of the plurality of optional installment plans may be associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

[0011] In some non-limiting embodiments or aspects, the at least one processor may be further configured to temporarily store the unique URL in association with the at least one optional installment plan for a time period. The unique URL may be configured to automatically deactivate after the time period.

[0012] In some non-limiting embodiments or aspects, the at least one processor may be further configured to, in response to transmitting the second authentication request to the issuer system, deactivate the unique URL and clear the at least one optional installment plan from memory.

[0013] In some non-limiting embodiments or aspects, the at least one processor may be configured to, when determining the eligibility for the installment payment, retrieve an eligibility status from a stored record associated with a payment device of the user associated with the transaction. The at least one processor may be further configured to dynamically process a first plurality of transactions as installment-based transactions and a second plurality of transactions as one-time-payment transactions based on a plurality of eligibility statuses in a plurality of stored records.

[0014] In some non-limiting embodiments or aspects, the system may further include at least one issuer processor of the issuer system. The at least one issuer processor may be configured to, in response to receiving the second authentication request, initiate the installment-based transaction. The at least one issuer processor may be configured to, when initiating the installment-based transaction, generate a second authentication response associated with the installment-based transaction, transmit the second authentication response to the merchant system via the at least one processor, and receive an authorization request from the merchant system associated with the installment-based transaction.

[0015] In some non-limiting embodiments or aspects, the at least one issuer processor may be further configured to, in response to receiving the authorization request from the merchant system, transfer a first installment payment that is less than the first amount from a transaction account of the user to a transaction account of the merchant. The at least one issuer processor may be further configured to transmit a schedule of payments to the computing device based on at least one remaining installment payment of the installment-based transaction.

[0016] According to non-limiting embodiments or aspects, provided is a method for dynamically configuring installment-based transactions during authentication processing. The method includes receiving, with at least one processor, a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount. The method also includes determining, with at least one processor, eligibility for installment payment based on the first authentication request. The method further includes generating, with at least one processor, a unique URL associated with an installment selection interface hosted by a transaction processing system. The unique URL is configured to permit access from a computing device of the user to the installment selection interface. The method further includes transmitting, with at least one processor, the unique URL to the merchant system. The method further includes receiving, with at least one processor, a user selection of an installment plan from the computing device via the installment selection interface. The method further includes generating, with at least one processor, a second authentication request identifying the user selection of the installment plan and including the first amount. The method further includes causing, with at least one processor, an issuer system to initiate aninstallment-based transaction by transmitting the second authentication request to the issuer system.

[0017] In some non-limiting embodiments or aspects, the method may include, in response to receiving the first authentication request, transmitting, with at least one processor, an issuer-side authentication request to the issuer system based on the transaction for the first amount. The method may further include receiving, with at least one processor, an issuer-side authentication response from the issuer system. The method may further include, in response to receiving the issuer-side authentication response, determining, with at least one processor, the eligibility for installment payment. The method may further include, in response to determining that the transaction is eligible for installment payment, generating, with at least one processor, the unique URL.

[0018] In some non-limiting embodiments or aspects, the method may further include, proximal to generating the unique URL, determining, with at least one processor, at least one optional installment plan based on the transaction and the first amount. The method may further include displaying, with at least one processor, the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

[0019] In some non-limiting embodiments or aspects, each optional installment plan of the at least one optional installment plan may be associated with an interval period and an installment payment amount. The second authentication request may include data of the interval period and the installment payment amount associated with the user selection of the installment plan.

[0020] In some non-limiting embodiments or aspects, the at least one optional installment plan may include a plurality of optional installment plans. Each optional installment plan of the plurality of optional installment plans may be associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

[0021] According to non-limiting embodiments or aspects, provided is a computer program product for dynamically configuring installment-based transactions during authentication processing. The computer program product includes at least one non- transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to receive a first authentication request from a merchant system of a merchant, the first authenticationrequest associated with a transaction between a user and the merchant for a first amount. The program instructions also cause the at least one processor to determine eligibility for installment payment based on the first authentication request. The program instructions further cause the at least one processor to generate a unique URL associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface. The program instructions further cause the at least one processor to transmit the unique URL to the merchant system. The program instructions further cause the at least one processor to receive a user selection of an installment plan from the computing device via the installment selection interface. The program instructions further cause the at least one processor to generate a second authentication request identifying the user selection of the installment plan and including the first amount. The program instructions further cause the at least one processor to cause an issuer system to initiate an installmentbased transaction by transmitting the second authentication request to the issuer system.

[0022] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to, in response to receiving the first authentication request, transmit an issuer-side authentication request to the issuer system based on the transaction for the first amount. The program instructions may further cause the at least one processor to receive an issuer-side authentication response from the issuer system. The program instructions may further cause the at least one processor to, in response to receiving the issuer-side authentication response, determine the eligibility for installment payment. The program instructions may further cause the at least one processor to, in response to determining that the transaction is eligible for installment payment, generate the unique URL.

[0023] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to, proximal to generating the unique URL, determine at least one optional installment plan based on the transaction and the first amount. The program instructions may further cause the at least one processor to display the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

[0024] In some non-limiting embodiments or aspects, each optional installment plan of the at least one optional installment plan may be associated with an interval period and an installment payment amount. The second authentication request may include data of the interval period and the installment payment amount associated with the user selection of the installment plan.

[0025] In some non-limiting embodiments or aspects, the at least one optional installment plan may include a plurality of optional installment plans. Each optional installment plan of the plurality of optional installment plans may be associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

[0026] Further non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0027] Clause 1 : A system comprising: at least one processor configured to: receive a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount; determine eligibility for installment payment based on the first authentication request; generate a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface; transmit the unique URL to the merchant system; receive a user selection of an installment plan from the computing device via the installment selection interface; generate a second authentication request identifying the user selection of the installment plan and comprising the first amount; and cause an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

[0028] Clause 2: The system of clause 1 , wherein the at least one processor is further configured to: in response to receiving the first authentication request, transmit an issuer-side authentication request to the issuer system based on the transaction for the first amount; receive an issuer-side authentication response from the issuer system; in response to receiving the issuer-side authentication response, determine the eligibility for installment payment; and in response to determining that the transaction is eligible for installment payment, generate the unique URL.

[0029] Clause 3: The system of clause 1 or clause 2, wherein the at least one processor is further configured to: proximal to generating the unique URL, determineat least one optional installment plan based on the transaction and the first amount; and display the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

[0030] Clause 4: The system of any of clauses 1 -3, wherein each optional installment plan of the at least one optional installment plan is associated with an interval period and an installment payment amount, and wherein the second authentication request comprises data of the interval period and the installment payment amount associated with the user selection of the installment plan.

[0031] Clause 5: The system of any of clauses 1 -4, wherein the at least one optional installment plan comprises a plurality of optional installment plans, and wherein each optional installment plan of the plurality of optional installment plans is associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

[0032] Clause 6: The system of any of clauses 1 -5, wherein the at least one processor is further configured to temporarily store the unique URL in association with the at least one optional installment plan for a time period, and wherein the unique URL is configured to automatically deactivate after the time period.

[0033] Clause 7: The system of any of clauses 1 -6, wherein the at least one processor is further configured to, in response to transmitting the second authentication request to the issuer system, deactivate the unique URL and clear the at least one optional installment plan from memory.

[0034] Clause 8: The system of any of clauses 1 -7, wherein the at least one processor is configured to, when determining the eligibility for the installment payment, retrieve an eligibility status from a stored record associated with a payment device of the user associated with the transaction, and wherein the at least one processor is further configured to dynamically process a first plurality of transactions as installmentbased transactions and a second plurality of transactions as one-time-payment transactions based on a plurality of eligibility statuses in a plurality of stored records.

[0035] Clause 9: The system of any of clauses 1 -8, further comprising at least one issuer processor of the issuer system, the at least one issuer processor configured to, in response to receiving the second authentication request, initiate the installmentbased transaction, wherein the at least one issuer processor is configured to, when initiating the installment-based transaction: generate a second authenticationresponse associated with the installment-based transaction; transmit the second authentication response to the merchant system via the at least one processor; and receive an authorization request from the merchant system associated with the installment-based transaction.

[0036] Clause 10: The system of any of clauses 1 -9, wherein the at least one issuer processor is further configured to: in response to receiving the authorization request from the merchant system, transfer a first installment payment that is less than the first amount from a transaction account of the user to a transaction account of the merchant; and transmit a schedule of payments to the computing device based on at least one remaining installment payment of the installment-based transaction.

[0037] Clause 11 : A method comprising: receiving, with at least one processor, a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount; determining, with at least one processor, eligibility for installment payment based on the first authentication request; generating, with at least one processor, a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface; transmitting, with at least one processor, the unique URL to the merchant system; receiving, with at least one processor, a user selection of an installment plan from the computing device via the installment selection interface; generating, with at least one processor, a second authentication request identifying the user selection of the installment plan and comprising the first amount; and causing, with at least one processor, an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

[0038] Clause 12: The method of clause 11 , further comprising: in response to receiving the first authentication request, transmitting, with at least one processor, an issuer-side authentication request to the issuer system based on the transaction for the first amount; receiving, with at least one processor, an issuer-side authentication response from the issuer system; in response to receiving the issuer-side authentication response, determining, with at least one processor, the eligibility for installment payment; and in response to determining that the transaction is eligible for installment payment, generating, with at least one processor, the unique URL.

[0039] Clause 13: The method of clause 11 or clause 12, further comprising: proximal to generating the unique URL, determining, with at least one processor, at least one optional installment plan based on the transaction and the first amount; and displaying, with at least one processor, the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

[0040] Clause 14: The method of any of clauses 11 -13, wherein each optional installment plan of the at least one optional installment plan is associated with an interval period and an installment payment amount, and wherein the second authentication request comprises data of the interval period and the installment payment amount associated with the user selection of the installment plan.

[0041] Clause 15: The method of any of clauses 11 -14, wherein the at least one optional installment plan comprises a plurality of optional installment plans, and wherein each optional installment plan of the plurality of optional installment plans is associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

[0042] Clause 16: A computer program product, comprising at least one non- transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount; determine eligibility for installment payment based on the first authentication request; generate a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface; transmit the unique URL to the merchant system; receive a user selection of an installment plan from the computing device via the installment selection interface; generate a second authentication request identifying the user selection of the installment plan and comprising the first amount; and cause an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

[0043] Clause 17: The computer program product of clause 16, wherein the program instructions further cause the at least one processor to: in response to receiving the first authentication request, transmit an issuer-side authenticationrequest to the issuer system based on the transaction for the first amount; receive an issuer-side authentication response from the issuer system; in response to receiving the issuer-side authentication response, determine the eligibility for installment payment; and in response to determining that the transaction is eligible for installment payment, generate the unique URL

[0044] Clause 18: The computer program product of clause 16 or clause 17, wherein the program instructions further cause the at least one processor to: proximal to generating the unique URL, determine at least one optional installment plan based on the transaction and the first amount; and display the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

[0045] Clause 19: The computer program product of any of clauses 16-18, wherein each optional installment plan of the at least one optional installment plan is associated with an interval period and an installment payment amount, and wherein the second authentication request comprises data of the interval period and the installment payment amount associated with the user selection of the installment plan.

[0046] Clause 20: The computer program product of any of clauses 16-19, wherein the at least one optional installment plan comprises a plurality of optional installment plans, and wherein each optional installment plan of the plurality of optional installment plans is associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

[0047] These and other features and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the disclosed subject matter.BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Additional advantages and details are explained in greater detail below with reference to the non-limiting, exemplary embodiments that are illustrated in the accompanying schematic figures, in which:

[0049] FIG. 1 is a schematic diagram of a system for dynamically configuring installment-based transactions during authentication processing, according to some non-limiting embodiments or aspects;

[0050] FIG. 2 is a schematic diagram of example components of one or more devices of FIG. 1 , according to some non-limiting embodiments or aspects;

[0051] FIG. 3 is a flow diagram of a method for dynamically configuring installmentbased transactions during authentication processing, according to some non-limiting embodiments or aspects;

[0052] FIG. 4 is a flow diagram of a method for dynamically configuring installmentbased transactions during authentication processing, according to some non-limiting embodiments or aspects;

[0053] FIG. 5 is a schematic diagram of an electronic payment processing network, according to some non-limiting embodiments or aspects;

[0054] FIG. 6 is a flow diagram of a system and method for dynamically configuring installment-based transactions during authentication processing, according to some non-limiting embodiments or aspects; and

[0055] FIG. 7 is a flow diagram of a method for dynamically configuring installmentbased transactions during authentication processing, according to some non-limiting embodiments or aspects.DETAILED DESCRIPTION

[0056] For purposes of the description hereinafter, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and derivatives thereof shall relate to the embodiments as they are oriented in the drawing figures. However, it is to be understood that the present disclosure may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary and non-limiting embodiments or aspects of the disclosed subjectmatter. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.

[0057] Some non-limiting embodiments or aspects may be described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.

[0058] No aspect, component, element, structure, act, step, function, instruction, and / or the like used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more” and “at least one.” Furthermore, as used herein, the term “set” is intended to include one or more items {e.g., related items, unrelated items, a combination of related and unrelated items, and / or the like) and may be used interchangeably with “one or more” or “at least one.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based at least partially on” unless explicitly stated otherwise. In addition, reference to an action being “based on” a condition may refer to the action being “in response to” the condition. For example, the phrases “based on” and “in response to” may, in some non-limiting embodiments or aspects, refer to a condition for automatically triggering an action {e.g., a specific operation of an electronic device, such as a computing device, a processor, and / or the like).

[0059] As used herein, the term “communication” may refer to the reception, receipt, transmission, transfer, provision, and / or the like of data {e.g., information, signals, messages, instructions, commands, and / or the like). For one unit {e.g., a device, a system, a component of a device or system, combinations thereof, and / or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and / or transmit information to the other unit. This may refer to a direct or indirect connection {e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and / orrouted between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least one intermediary unit processes information received from the first unit and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet and / or the like) that includes data. It will be appreciated that numerous other arrangements are possible.

[0060] As used herein, the term “computing device” may refer to one or more electronic devices configured to process data. A computing device may, in some examples, include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and / or the like. A computing device may be a mobile device. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and / or the like), a personal digital assistant (PDA), and / or other like devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0061] As used herein, the term “server” may refer to or include one or more computing devices that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) directly or indirectly communicating in the network environment may constitute a “system.”

[0062] As used herein, the term “system” may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such, and / or the like). Reference to “a device,” “a server,” “a processor,” and / or the like, as used herein, may refer to a previously recited device, server, or processor that is recited as performing a previous step or function, a different device, server, or processor, and / or a combination of devices, servers, and / or processors. For example, as used in the specification and the claims, a first device, a first server, or a first processor that is recited as performinga first step or a first function may refer to the same or different device, server, or processor recited as performing a second step or a second function.

[0063] As used herein, the term “acquirer institution” may refer to an entity licensed and / or approved by a transaction service provider to originate transactions (e.g., payment transactions) using a payment device associated with the transaction service provider. The transactions the acquirer institution may originate may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), and / or the like). In some non-limiting embodiments or aspects, an acquirer institution may be a financial institution, such as a bank. As used herein, the term “acquirer system” may refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer executing one or more software applications.

[0064] As used herein, the term “account identifier” may include one or more primary account numbers (PANs), tokens, or other identifiers associated with a customer account. The term “token” may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN. Account identifiers may be alphanumeric or any combination of characters and / or symbols. Tokens may be associated with a PAN or other original account identifier in one or more data structures e.g., one or more databases, and / or the like) such that they may be used to conduct a transaction without directly using the original account identifier. In some examples, an original account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals or purposes.

[0065] As used herein, the terms “client” and “client device” may refer to one or more client-side devices or systems (e.g., remote from a transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). As an example, a “client device” may refer to one or more POS devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, one or more computing devices used by a payment device provider system, and / or the like. In some non-limiting embodiments or aspects, a client device may be an electronic device configured to communicate with one or more networks and initiate or facilitate transactions. For example, a client device may include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, and / or the like), PDAs, and / or the like. Moreover, a “client” may also refer to an entity (e.g., amerchant, an acquirer, and / or the like) that owns, utilizes, and / or operates a client device for initiating transactions (e.g., for initiating transactions with a transaction service provider).

[0066] As used herein, the terms “electronic wallet” and “electronic wallet application” refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device executing an electronic wallet application and may further include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An “electronic wallet provider” may include an entity that provides and / or maintains an electronic wallet for a customer, such as Google Pay®, Android Pay®, Apple Pay®, Samsung Pay®, and / or other like electronic payment systems. In some non-limiting examples, an issuer bank may be an electronic wallet provider.

[0067] As used herein, the term “issuer institution” may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide an account identifier, such as a PAN, to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and / or may be electronic and used for electronic payments. The term “issuer system” refers to one or more computer devices operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing a transaction.

[0068] As used herein, the term “merchant” may refer to an individual or entity that provides goods and / or services, or access to goods and / or services, to customers based on a transaction, such as a payment transaction. The term “merchant” or “merchant system” may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications.

[0069] As used herein, a “point-of-sale (POS) device” may refer to one or more devices, which may be used by a merchant to conduct a transaction (e.g., a payment transaction) and / or process a transaction. For example, a POS device may include one or more client devices. Additionally, or alternatively, a POS device may includeperipheral devices, card readers, scanning devices e.g., code scanners), Bluetooth® communication receivers, near-field communication (NFC) receivers, radio frequency identification (RFID) receivers, and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, and / or the like. As used herein, a “point- of-sale (ROS) system” may refer to one or more client devices and / or peripheral devices used by a merchant to conduct a transaction. For example, a PCS system may include one or more POS devices and / or other like devices that may be used to conduct a payment transaction. In some non-limiting embodiments or aspects, a POS system (e.g., a merchant POS system) may include one or more server computers programmed or configured to process online payment transactions through webpages, mobile applications, and / or the like.

[0070] As used herein, the term “payment device” may refer to an electronic payment device, a portable financial device, a payment card (e.g., a credit or debit card), a gift card, a smartcard, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a PDA, a pager, a security card, a computing device, an access card, a wireless terminal, a transponder, and / or the like. In some non-limiting embodiments or aspects, the payment device may include volatile or nonvolatile memory to store information (e.g., an account identifier, a name of the account holder, and / or the like).

[0071] As used herein, the term “transaction service provider” may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider may include a payment network such as Visa® or any other entity that processes transactions. The term “transaction processing system” may refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing server may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0072] The methods, systems, and computer program products described herein provide numerous technical advantages in systems for electronic transactionprocessing. First, by determining eligibility for installment payments based on a first authentication request that is received from a merchant system during a multi-domain authentication process flow (e.g., domains of user, merchant, acquirer, transaction processing system, and / or issuer), a transaction processing system is able to dynamically determine whether to invoke the installment-based transaction process, which reduces memory usage for invoking installment-based transactions for every transaction that is processed. For example, the installment payment process flow need not be invoked for every user before an issuer authenticates and / or confirms that the user and / or payment device is eligible for installment payments — eligibility may be predetermined and evaluated as a precursor to triggering an installment selection interface and generating a unique URL for the user to interact with.

[0073] Moreover, by generating a unique URL associated with an installment selection interface hosted by the transaction processing system, there is no longer a need to pre-configure each participating merchant system with installment-payment interfaces, integration with installment-based authentication flows, and / or the like. This reduces memory used, system upgrade downtime, and potential points of installment error in the aggregate, since a plurality of merchants can be made operable in the disclosed system via the centralization and coordination of the transaction processing system. For example, a merchant system may make use of an application programming interface (API) to allow a merchant payment interface to integrate with and / or redirect to the installment selection interface that is hosted by the transaction processing system, which would not require significant modifications to the merchant system, and which would require fewer modifications than individually updating each merchant system to host its own installment payment interface.

[0074] Furthermore, because the installment selection interface is made accessible by a computing device of a user via the unique URL, and because the installment selection interface is hosted by the transaction processing system, the installment selection interface interacted with by a user may be separate from the merchant system and merchant payment interface, which increases data privacy. Accordingly, since the merchant system does not need to be involved in the process for determining installment plan eligibility, presenting installment plans, selecting an installment plan, and initiating an installment payment, such data does not need to be presented to merchant-side servers and can be kept private to user, transaction processing system, and / or issuer. By way of further example, the variety of plans, interest rates, intervalperiods, and installment amounts that are available and presented to a user may be kept private from the merchant system, only revealing a final user selection of an installment plan to the merchant system.

[0075] Additionally, based on a user selection of an installment plan from the computing device of the user via the installment selection interface, a transaction processing system may generate a second authentication request identifying the user selection and comprising the amount of the transaction. The transaction processing system may then cause an issuer system to initiate an installment-based transaction instead of a full-payment transaction by transmitting the second authentication request to the issuer system. Such a process simplifies the number of messages that need to be triggered on the issuer-side servers, given that steps for determining installment eligibility, displaying installment plans, and receiving a selection of installment plans are concluded before the issuer system is involved in the transaction processing. For example, instead of separately implementing the above process steps at each individual issuer system, these steps are consolidated in a centralized transaction processing system, reducing overall environment computer resource requirements. Moreover, the issuer-side interactions are made more efficient, by being able to proceed directly to third-domain authentication (e.g., one-time password (OTP)) with the user based on the information of the user’s intent to engage in an installment-type transaction. In view of the foregoing, there are numerous computational resource savings in the ordered combination of systems, devices, and processes, as further disclosed herein in various non-limiting embodiments and aspects.

[0076] Referring now to FIG. 1 , shown is a schematic diagram of an example system 100 in which devices, systems, and / or methods, described herein, may be implemented. As shown in FIG. 1 , system 100 may include transaction processing system 102, merchant system 103, issuer system 104, computing device 106, and communication network 108. Transaction processing system 102, merchant system 103, issuer system 104, and computing device 106 may interconnect (e.g., establish a connection to communicate) via wired connections, wireless connections, or a combination of wired and wireless connections.

[0077] Transaction processing system 102 may include one or more computing devices configured to communicate with merchant system 103, issuer system 104, and / or computing device 106 at least partly over communication network 108. Transaction processing system 102 may be configured to receive a transactionauthentication request from merchant system 103 and, during processing, determine eligibility for installment payments based on the transaction authentication request. If eligibility is determined, transaction processing system 102 may inject an installment selection process to allow a user to select an installment plan, which may be used to initiate an installment-based transaction when transaction processing system 102 thereafter communicates with issuer system 104. Transaction processing system 102 may be configured to execute authentication using a three-domain secure (3-D Secure) authentication protocol, with the first domain being associated with merchant system 103, the second domain being associated with transaction processing system102, and the third domain being associated with issuer system 104.

[0078] Merchant system 103 may include one or more computing devices configured to communicate with transaction processing system 102, issuer system 104, and / or computing device 106 at least partly over communication network 108. Merchant system 103 may be associated with a POS system, with which a user may interact to initiate a transaction. Merchant system 103 may be configured to generate a first transaction request and transmit the first transaction request to transaction processing system 102. Merchant system 103 may be further configured to receive a unique URL from transaction processing system 102 and provide the unique URL to computing device 106 for use of unique URL to access an installment selection interface.

[0079] Issuer system 104 may include one or more computing devices configured to communicate with transaction processing system 102, merchant system 103, and / or computing device 106 at least partly over communication network 108. Issuer system 104 may be configured to receive a second transaction authentication request from transaction processing system 102 and, in response to receiving the second transaction authentication request, issuer system 104 may be caused to initiate an installment-based transaction based on information in the second transaction authentication request.

[0080] Computing device 106 may include one or more processors that are configured to communicate with transaction processing system 102, merchant system103, and / or issuer system 104 at least partly over communication network 108. Computing device 106 may be associated with a user. Computing device 106 may further store payment device data or act as a payment device (e.g., issued by an issuer associated with an issuer system) for completing transactions with a merchantassociated with merchant system 103. In some non-limiting embodiments or aspects, a user may have a payment device that is not associated with computing device 106 to complete transactions in an electronic payment processing network that includes, at least partly, communication network 108 and one or more devices of system 100.

[0081] Communication network 108 may include one or more wired and / or wireless networks over which the systems and devices of system 100 may communicate. For example, communication network 108 may include a cellular network (e.g., a longterm evolution (LTE®) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, and / or the like, and / or a combination of these or other types of networks.

[0082] The number and arrangement of systems and devices shown in FIG. 1 are provided as an example. There may be additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, or differently arranged systems and / or devices than those shown in FIG. 1. Furthermore, two or more systems and / or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of system 100 may perform one or more functions described as being performed by another set of systems or another set of devices of system 100.

[0083] In some non-limiting embodiments or aspects, one or more of transaction processing system 102, merchant system 103, issuer system 104, and / or computing device 106 may perform one or more steps of a method for dynamically configuring installment-based transactions during authentication processing. For example, transaction processing system 102 may receive a first authentication request (e.g., a network message in an electronic payment processing network configured to request authentication of a transaction request). As used herein, “authentication” may refer to verifying an identity of an entity making a transaction, and “authorization” may refer to determining whether an entity has the permission to complete the transaction based on their access level or available funds. Transaction processing system 102 mayreceive the first authentication request from merchant system 103 of a merchant (e.g., a merchant operating a physical or virtual business and offering one or more goods or services for sale to a user). The first authentication request may be associated with a transaction (e.g., a payment transaction) between a user (e.g., a cardholder) and the merchant for a first amount (e.g., a transaction value, such as designated by units in a specific currency).

[0084] In some non-limiting embodiments or aspects, transaction processing system 102 may, in response to receiving the first authentication request, transmit an issuer-side authentication request to issuer system 104 based on the transaction for the first amount. In response to receiving the issuer-side authentication request, issuer system 104 may authenticate the transaction (e.g., authenticate an identity of the user and / or payment device associated with the transaction) and transmit an issuer-side authentication response to transaction processing system 102. The issuer-side authentication response may indicate whether the user and / or payment device are authenticated for purposes of completing the transaction. If the user and / or payment device are not authenticated, as indicated by the issuer-side authentication response, transaction processing system 102 may terminate the forward-processing of the transaction and transmit a message to merchant system 103 indicating that the transaction is declined for failure of authentication. Conversely, if the user and / or payment device are authenticated, as indicated by the issuer-side authentication response, transaction processing system 102 may proceed with determining eligibility of the user, payment device, and / or transaction for installment payment.

[0085] In some non-limiting embodiments or aspects, transaction processing system 102 may determine eligibility for installment payment based on the first authentication request. For example, transaction processing system 102 may retrieve an eligibility status based on an identifier from the first authentication request (e.g., a user identifier, a payment device identifier) and determine if the eligibility status indicates that the current transaction is eligible for being processed as an installmentbased transaction. By way of further example, issuers may be provided with an interface (e.g., via an application programming interface (API)) to a transaction processing system processor and / or database, to permit issuer systems 104 to provide information about eligibility for individual users and / or payment devices, from which eligibility may be determined. Additionally, or alternatively, transaction processing system 102 may compare one or more parameters of the firstauthentication request (e.g., transaction description, transaction amount, merchant category code, transaction type, etc.) to a predetermined set of criteria associated with eligibility and determine if the parameters satisfy the criteria (e.g., transaction description matches approved descriptions, transaction amount greater than or equal to minimum threshold, transaction amount less than or equal to maximum threshold, merchant category code matches approved codes, transaction type matches approved types, etc.).

[0086] In some non-limiting embodiments or aspects, transaction processing system 102 may, when determining the eligibility for the installment payment, retrieve an eligibility status (e.g., a binary flag, an eligibility type, a set of parameters defining eligibility, etc.) from a stored record associated with a user and / or payment device associated with the transaction. Transaction processing system 102 may be further configured to dynamically process a first plurality of transactions as installment-based transactions and a second plurality of transactions as one-time-payment transactions based on a plurality of eligibility statuses in a plurality of stored records. For example, transaction processing system 102 may be configured to process a volume of transactions from a plurality of users using a plurality of payment devices. For payment devices and / or users that have stored records indicating that the payment device and / or user is eligible for installment-based transactions, transaction processing system 102 may allow such users (e.g., at the user’s election) to pay for instigating transactions using an installment plan. For payment devices and / or users that have stored records indicating that the payment device and / or user is not eligible for installment-based transactions, transaction processing system 102 may not present any installment plan options and instead process the instigating transaction as a single-payment transaction.

[0087] In some non-limiting embodiments or aspects, transaction processing system 102 may, in response to determining that a user, payment device, and / or transaction is eligible for installment payment, generate a unique uniform resource locator (URL) associated with an installment selection interface (e.g., an online form, a webpage, an application view, an embedded web frame, etc.) hosted by transaction processing system 102. The unique URL may be configured to permit access from computing device 106 of the user to the installment selection interface. For example, a merchant payment interface may be directed to the installment selection interface located at the unique URL. By way of another example, a merchant payment interfacemay display a window, frame, or other view including the installment selection interface that is available at the unique URL. By way of another example, computing device 106 may activate another browser or application to view the installment selection interface based on the unique URL. It will be appreciated that many configurations are possible based on the merchant system and payment interface in which the user is originally interacting to generate the first authentication request.

[0088] In some non-limiting embodiments or aspects, transaction processing system 102 may transmit the unique URL to merchant system 103. For example, transaction processing system 102 may communicate the unique URL to merchant system 103 via an API and / or return message in response to the first authentication request transmitted by merchant system 103 to transaction processing system 102. Additionally, or alternatively, transaction processing system 102 may transmit the unique URL to merchant system 103 in an authentication response message transmitted in response to the first authentication request. For example, transaction processing system 102 may transmit an authentication response message to merchant system 103 including information related to the eligibility of the user, payment device, and / or transaction for installment payment, which may include the unique URL for an eligible user, payment device, and / or transaction.

[0089] In some non-limiting embodiments or aspects, transaction processing system 102 may receive a user selection of an installment plan from computing device 106. For example, the user may use computing device 106 to select, via the installment selection interface hosted by transaction processing system 102 and accessible using the unique URL, an installment plan. As used herein, an “installment plan” may refer to a set of parameters defining an installment-based payment, including, but not limited to, an interval period (e.g., every week, every two weeks, every month, every three months, etc.), a payment amount, and / or the like. Each installment may be the same or a different payment amount. Each installment may also be paid at a consistent or varying interval. The installment plan may define a set of individual payments, collectively as the installment-based transaction, that combine to be equal to or greater than the first amount detailed in the first authentication request. The installment plan may further indicate a total time period for the series of installment payments, a number of intervals of payments, and / or the like.

[0090] In some non-limiting embodiments or aspects, transaction processing system 102 may be configured to, proximal to generating the unique URL (e.g., lessthan a minute, less than 10 seconds, etc., before, during, or after generating the unique URL), determine at least one optional installment plan. An optional installment plan may include an installment plan for an installment-based payment that the user, payment device, and / or transaction is eligible for. Transaction processing system 102 may be configured to display the at least one optional installment plan in the installment selection interface. The user selection of the installment plan may be a selection of one of the optional installment plans from the at least one optional installment plan.

[0091] In some non-limiting embodiments or aspects, each optional installment plan of the at least one optional installment plan may be associated with an interval period and an installment payment amount e.g., a payment amount due at a respective interval period, at every interval period, etc.). The second authentication request may include data of the interval period and the installment payment amount that is associated with the user selection of the installment plan. In some non-limiting embodiments or aspects, the at least one optional installment plan may include a plurality of optional installment plans. Each optional installment plan of the plurality of optional installment plans may be associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans. For example, a user seeking to complete a transaction for a first amount of $1000 may be presented with a plurality of optional installment plans, including those specified by the following parameters: a first optional installment plan, including $110 monthly payments for ten intervals of one month; a second optional installment plan, including $215 bi-monthly payments for five intervals of two months; a third optional installment plan, including $525 payments every five months, for two intervals.

[0092] It will be appreciated that the installment plan may present installment plans with different numbers of intervals, different numbers of payments, different payment amounts, and different total payment periods (e.g., determine by a number of payments multiplied by numbers of intervals, minus a first interval if the first payment is submitted at the time of initiating the installment-based transaction). In some nonlimiting embodiments or aspects, a first installment payment for a first interval, for an installment-based payment, may be initiated by issuer system 104 as part of initiating the installment-based transaction. In this manner, a first installment payment may be made at the time the user agrees to the installment-based transaction plan.

[0093] In some non-limiting embodiments or aspects, transaction processing system 102 may be configured to, in response to receiving the user selection of the installment plan from computing device 106, generate a second authentication request identifying the user selection of the installment plan and including the first amount. For example, if the first amount is for $800 and the transaction is for a new smartphone, the installment plan may indicate a payment of $200 (e.g., an installment amount) every three months (e.g., an interval period), concluding after four payments (e.g., a year). Such information may be embedded as data in one or more fields of a second authentication request. Transaction processing system 102 may then cause issuer system 104 to initiate an installment-based transaction by transmitting the second authentication request to issuer system 104, which may be configured to carry out the installment-based transaction based on information included in the second authentication request.

[0094] In some non-limiting embodiments or aspects, transaction processing system 102 may temporarily store (e.g., in a non-transitory, computer-readable medium) the unique URL in association with the at least one optional installment plan for a time period (e.g., several minutes, hours, and / or the like), which may include until the immediate transaction has reached an approval milestone (e.g., installment plan is selected by the user, second authentication request is transmitted to issuer system 104, the installment-based transaction is initiated by issuer system 104. For example, transaction processing system 102 may maintain a database of ongoing transactions and persist the unique URL in memory for a time period, such as until the installment plan is selected by the user, until the second authentication request is transmitted to issuer system 104, until the issuer system 104 initiates the installment-based transaction, and / or the like. The unique URL may be stored in association with one or more optional installment plans. The unique URL may be configured to automatically deactivate after the time period (e.g., link expires as a valid web page, record is deleted, access requests are denied, etc.). For example, in response to transmitting the second authentication request to issuer system 104, transaction processing system 102 may deactivate the unique URL and / or clear the at least one optional installment plan from memory. The foregoing arrangement reduces overall computing resources used by only storing URLs and / or optional installment plans during the transaction processing flow, such as after a first authentication request is transmittedby merchant system 103 and until / before issuer system 104 initiates the installmentbased transaction.

[0095] In some non-limiting embodiments or aspects, issuer system 104 may, in response to receiving the second authentication request, initiate the installment-based transaction. Issuer system 104 may, when initiating the installment-based transaction, perform a series of steps. Such initiation steps may include generating a second authentication response associated with the installment-based transaction, indicating that the identity of the user and / or payment devices is authenticated for the purposes of the installment-based payment. The initiation steps may further include transmitting the second authentication response to merchant system 103 via transaction processing system 102. The initiation steps may further include receiving an authorization request from merchant system 103 associated with the installmentbased transaction. The authorization request may be configured to cause issuer system 104 to thereafter transfer payment for a first installment of the installmentbased transaction from an account of the user to an account of the merchant. For example, in response to receiving the authorization request from merchant system 103, issuer system 104 may transfer a first installment payment that is less than the first amount from a transaction account of the user to a transaction account of the merchant. Issuer system 104 may further transmit a schedule of payments (e.g., a record indicating a timing and / or amount of expected installation-based payment portions to be transmitted to merchant’s account) to computing device 106 and / or merchant system 103 based on at least one remaining installment payment of the installment-based transaction.

[0096] Referring now to FIG. 2, shown is a diagram of example components of a device 200, according to non-limiting embodiments. Device 200 may correspond to transaction processing system 102, merchant system 103, issuer system 104, or computing device 106, as an example. In some non-limiting embodiments, such systems or devices may include at least one device 200 and / or at least one component of device 200. The number and arrangement of components shown are provided as an example. In some non-limiting embodiments, device 200 may include additional components, fewer components, different components, or differently arranged components than those shown. Additionally, or alternatively, a set of components (e.g., one or more components) of device 200 may perform one or more functions described as being performed by another set of components of device 200.

[0097] As shown in FIG. 2, device 200 may include a bus 202, a processor 204, memory 206, a storage component 208, an input component 210, an output component 212, and a communication interface 214. Bus 202 may include a component that permits communication among the components of device 200. In some non-limiting embodiments, processor 204 may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor 204 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that can be programmed to perform a function. Memory 206 may include random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by processor 204.

[0098] With continued reference to FIG. 2, storage component 208 may store information and / or software related to the operation and use of device 200. For example, storage component 208 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid-state disk, etc.) and / or another type of computer-readable medium. Input component 210 may include a component that permits device 200 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally, or alternatively, input component 210 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 212 may include a component that provides output information from device 200 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 214 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables device 200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 214 may permit device 200 to receive information from another device and / or provide information to another device. For example, communication interface 214 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, auniversal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and / or the like.

[0099] Device 200 may perform one or more processes described herein. Device 200 may perform these processes based on processor 204 executing software instructions stored by a computer-readable medium, such as memory 206 and / or storage component 208. A computer-readable medium may include any non- transitory memory device. A memory device includes memory space located inside of a single physical storage device or memory space spread across multiple physical storage devices. Software instructions may be read into memory 206 and / or storage component 208 from another computer-readable medium or from another device via communication interface 214. When executed, software instructions stored in memory 206 and / or storage component 208 may cause processor 204 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software. The term “configured to,” as used herein, may refer to an arrangement of software, device(s), and / or hardware for performing and / or enabling one or more functions (e.g., actions, processes, steps of a process, and / or the like). For example, “a processor configured to” may refer to a processor that executes software instructions (e.g., program code) that cause the processor to perform one or more functions.

[0100] Referring now to FIG. 3, shown is a flow diagram of a non-limiting embodiment or aspect of a method 300 for dynamically configuring installment-based transactions during authentication processing, according to some non-limiting embodiments or aspects. The steps shown in FIG. 3 are for example purposes only. It will be appreciated that additional, fewer, different, and / or a different order of steps may be used in non-limiting embodiments or aspects. In some non-limiting embodiments or aspects, one or more of the steps of method 300 may be performed (e.g., completely, partially, and / or the like) by transaction processing system 102. In some non-limiting embodiments or aspects, one or more of the steps of method 300 may be performed (e.g., completely, partially, and / or the like) by another system, another device, another group of systems, or another group of devices, separate from or including transaction processing system 102.

[0101] As shown in FIG. 3, at step 302, method 300 may include receiving a first authentication request. For example, transaction processing system 102 may receive a first authentication request from merchant system 103 of a merchant. The first authentication request may be associated with a transaction between a user and a merchant for a first amount.

[0102] As shown in FIG. 3, at step 304, method 300 may include determining eligibility for installment payments. For example, transaction processing system 102 may determine eligibility for installment payment based on the first authentication request.

[0103] As shown in FIG. 3, at step 306, method 300 may include generating a unique URL. For example, transaction processing system 102 may generate a unique URL associated with an installment selection interface hosted by transaction processing system 102. The unique URL may be configured to permit access from computing device 106 of user to the installment selection interface.

[0104] As shown in FIG. 3, at step 308, method 300 may include transmitting the unique URL. For example, transaction processing system 102 may transmit the unique URL to merchant system 103.

[0105] As shown in FIG. 3, at step 310, method 300 may include receiving a user selection of an installment plan. For example, transaction processing system 102 may receive a user selection of an installment plan from computing device 106 via the installment selection interface that is accessible via the unique URL.

[0106] As shown in FIG. 3, at step 312, method 300 may include generating a second authentication request. For example, transaction processing system 102 may generate a second authentication request identifying the user selection of the installment plan and including the first amount.

[0107] As shown in FIG. 3, at step 314, method 300 may include causing issuer system 104 to initiate an installment-based transaction. For example, transaction processing system 102 may cause issuer system 104 to initiate an installment-based transaction by transmitting the second authentication request to issuer system 104.

[0108] Referring now to FIG. 4, shown is a flow diagram of a non-limiting embodiment or aspect of a method 400 for dynamically configuring installment-based transactions during authentication processing, according to some non-limiting embodiments or aspects. For example, method 400 may illustrate one or more steps associated with an issuer system 104 initiating an installment-based transaction, whichmay be triggered in response to receiving the second authentication request from transaction processing system 102. The steps shown in FIG. 4 are for example purposes only. It will be appreciated that additional, fewer, different, and / or a different order of steps may be used in non-limiting embodiments or aspects. In some nonlimiting embodiments or aspects, one or more of the steps of method 400 may be performed {e.g., completely, partially, and / or the like) by issuer system 104. In some non-limiting embodiments or aspects, one or more of the steps of method 400 may be performed {e.g., completely, partially, and / or the like) by another system, another device, another group of systems, or another group of devices, separate from or including issuer system 104.

[0109] As shown in FIG. 4, at step 402, method 400 may include generating a second authentication response. For example, issuer system 104 may generate a second authentication response associated with the installment-based transaction.

[0110] As shown in FIG. 4, at step 404, method 400 may include transmitting the second authentication response to merchant system 103. For example, issuer system 104 may transmit the second authentication response to merchant system 103 via transaction processing system 102.

[0111] As shown in FIG. 4, at step 406, method 400 may include receiving an authorization request from merchant system 103. For example, issuer system 104 may receive an authorization request from merchant system 103 {e.g., via transaction processing system 102) associated with the installment-based transaction.

[0112] As shown in FIG. 4, at step 408, method 400 may include transferring a first installment payment. For example, issuer system 104 may, in response to receiving the authorization request from merchant system 103, transfer a first installment payment that is less than the first amount from a transaction account of the user {e.g., a checking account) to a transaction account of the merchant {e.g., a commercial banking account).

[0113] As shown in FIG. 4, at step 410, method 400 may include transmitting a schedule of payments. For example, issuer system 104 may transmit a schedule of payments to computing device 106 based on at least one remaining installment payment of the installment-based transaction.

[0114] Referring now to FIG. 5, shown is an electronic payment processing network 500, according to non-limiting embodiments or aspects. The payment processing network may be used in conjunction with the systems and methods described herein.It will be appreciated that the particular arrangement of electronic payment processing network 500 shown is for example purposes only, and that various arrangements are possible. Transaction processing system 501 (e.g., a transaction handler, transaction processing system 102) is shown to be in communication with one or more issuer systems (e.g., such as issuer system 506) and one or more acquirer systems (e.g., such as acquirer system 508). Although only a single issuer system 506 and single acquirer system 508 are shown, it will be appreciated that transaction processing system 501 may be in communication with a plurality of issuer systems and / or acquirer systems. In some embodiments, transaction processing system 501 may also operate as an issuer system such that both transaction processing system 501 and issuer system 506 are a single system and / or controlled by a single entity.

[0115] In some non-limiting embodiments or aspects, transaction processing system 501 may communicate with merchant system 504 (e.g., merchant system 103) directly through a public or private network connection. Additionally, or alternatively, transaction processing system 501 may communicate with merchant system 504 through payment gateway 502 and / or acquirer system 508. In some non-limiting embodiments or aspects, an acquirer system 508 associated with merchant system 504 may operate as payment gateway 502 to facilitate the communication of transaction requests from merchant system 504 to transaction processing system 501 . Merchant system 504 may communicate with payment gateway 502 through a public or private network connection. For example, a merchant system 504 that includes a physical POS device may communicate with payment gateway 502 through a public or private network to conduct card-present transactions. As another example, a merchant system 504 that includes a server (e.g., a web server) may communicate with payment gateway 502 through a public or private network, such as a public Internet connection, to conduct card-not-present transactions.

[0116] In some non-limiting embodiments or aspects, transaction processing system 501 , after receiving a transaction request from merchant system 504 that identifies an account identifier of a payor (e.g., such as an account holder) associated with an issued payment device 510, may generate an authorization request message to be communicated to the issuer system 506 (e.g., issuer system 104) that issued the payment device 510 and / or account identifier. Issuer system 506 may then approve or decline the authorization request and, based on the approval or denial, generate an authorization response message that is communicated to transaction processingsystem 501. Transaction processing system 501 may communicate an approval or denial to merchant system 504. When issuer system 506 approves the authorization request message, it may then clear and settle the payment transaction between the issuer system 506 and acquirer system 508.

[0117] Referring now to FIG. 6, shown is a flow diagram of a system and method for dynamically configuring installment-based transactions during authentication processing, according to some non-limiting embodiments or aspects. The steps shown in FIG. 6 are for example purposes only. It will be appreciated that additional, fewer, different, and / or a different order of steps may be used in non-limiting embodiments or aspects. In some non-limiting embodiments or aspects, merchant system 103, as shown, may have none, one, some, or all of its steps performed by an acquirer system (e.g., acquirer system 508, shown in FIG. 5) and / or payment gateway (e.g., payment gateway 502 shown in FIG. 5), which may carry out one or more of steps on behalf of a merchant.

[0118] As shown in FIG. 6, the method may include, at step S1 , initiating a payment. For example, user 602 e.g., which may be associated with a payment device and may be using computing device 106), may initiate a payment (e.g., a purchase transaction). By way of further example, user 602 may use computing device 106 to access a merchant POS system (e.g., a merchant payment interface in an application or web browser) to initiate a payment.

[0119] As shown in FIG. 6, the method may include, at step S2, making an API call to installment coordination system 604. Installment coordination system 604 may include at least one processor of transaction processing system 102 that are configured to facilitate installment-based payment transactions. For example, merchant system 103 may (e.g., directly or via an acquirer system and / or payment gateway) make an API call to installment coordination system 604 to check for eligibility of the transaction to be an installment-based transaction, and to obtain, at step S3, installment plan details and display eligible installment plans to user 602. Merchant system 103 may display the optional installment plans to user 602 for user to select an installment plan.

[0120] As shown in FIG. 6, the method may include, at step S4, sending an authorization request to transaction processing system 102. For example, merchant system 103 may (e.g., directly or via an acquirer system and / or payment gateway)send an authorization request to transaction processing system 102 for a full amount of the transaction (e.g., as in a business-as-usual transaction process flow).

[0121] As shown in FIG. 6, the method may include, at step S5, processing and forwarding the transaction to issuer system 104 for authorization. For example, transaction processing system 102 may process and forward the transaction (e.g., the original transaction authorization request) to issuer system 104 for authorization.

[0122] As shown in FIG. 6, the method may include, at step S6, sending a transaction approval response. For example, issuer system 104 may transmit an issuer approval response, for the transaction, to transaction processing system 102.

[0123] As shown in FIG. 6, the method may include, at step S7, responding to merchant system 103 with transaction approval. For example, transaction processing system 102 may transmit a response message indicating transaction approval to merchant system 103 (e.g., directly or indirectly via an acquirer system and / or payment gateway).

[0124] As shown in FIG. 6, the method may include, at step S8, displaying an approval message to user 602. For example, merchant system 103 may display an approval message (e.g., in a merchant payment interface) to user 602, indicating that the transaction has been approved.

[0125] As shown in FIG. 6, the method may include, at steps S9 and S10, if user 602 selected an installment plan: sending a plan selection API call to installment coordination system 604 with details of the approved transaction and installment plan that was selected.

[0126] Referring now to FIG. 7, shown is a flow diagram of a method 700 for dynamically configuring installment-based transactions during authentication processing, according to some non-limiting embodiments or aspects. The steps shown in FIG. 7 are for example purposes only. It will be appreciated that additional, fewer, different, and / or a different order of steps may be used in non-limiting embodiments or aspects. In some non-limiting embodiments or aspects, transaction processing system 102 may include a security and authentication system, which performs one or more steps related to authentication. In some non-limiting embodiments or aspects, transaction processing system 102 may include an installment system, which performs one or more steps related to installment payments.

[0127] As shown in FIG. 7, method 700 may include, at step 702, initiating a payment checkout process. For example, user 602, using computing device 106, mayinput information related to a payment device in a merchant payment interface, provided by merchant system 103. User 602 may seek to complete a payment transaction with merchant system 103. Computing device 106 may transmit a transaction request message to merchant system 103, which may include payment device data, user data, transaction data, and / or the like.

[0128] As shown in FIG. 7, method 700 may include, at step 704, submitting a transaction for authentication. For example, merchant system 103 may submit the transaction, which was requested by user 602, to transaction processing system 102 (e.g., a security and authentication system thereof) for further processing. In doing so, merchant system 103 may generate and transmit a transaction authentication request to transaction processing system 102.

[0129] As shown in FIG. 7, method 700 may include, at step 706, determining eligibility for installment payment and generating a unique URL. For example, transaction processing system 102 may determine an issuer identifier from the authentication request message received from merchant system 103, in addition to a payment device identifier (e.g., PAN). Transaction processing system 102 may then determine eligibility for installment payment based on the issuer identifier and the payment device identifier. For example, a security and authentication system of transaction processing system 102 may transmit the issuer identifier and payment device identifier to an installment system of transaction processing system 102. The installment system may check for eligibility of the payment device and / or issuer for processing the transaction as an installment payment. In response to determining that the user, payment device, and / or transaction is eligible, the installment system may generate a unique URL (e.g., hosted by transaction processing system 102) and transmit the unique URL to the security and authentication system of transaction processing system 102.

[0130] As shown in FIG. 7, method 700 may include, at step 708, transmitting the unique URL to merchant system 103. For example, transaction processing system102 may transmit the unique URL to merchant system 103, which may be used to provide user 602 with access to an installment selection interface hosted by transaction processing system 102.

[0131] As shown in FIG. 7, method 700 may include, at step 710, launching an installment selection interface using the unique URL. For example, merchant system103 may use the unique URL, in combination with a merchant payment interface, tolaunch the installment selection interface (e.g., opening a new window, application, etc., displaying the installment selection interface).

[0132] As shown in FIG. 7, method 700 may include, at step 712, requesting installment plans from transaction processing system 102. For example, merchant system 103 may transmit a request, using the unique URL, to fetch one or more optional installment plans that are available for the current transaction. Merchant system 103 may communicate with an installment system of transaction processing system 102. In some non-limiting embodiments or aspects, computing device 106 may perform step 712 to request the one or more optional installment plans, for display on computing device 106.

[0133] As shown in FIG. 7, method 700 may include, at step 714, displaying one or more optional installment plans for user 602 to make a selection. For example, transaction processing system 102, via the installment selection interface, may render one or more installment plans e.g., parameters thereof) on a screen of computing device 106 for user 602 to make a selection of one of the installment plans.

[0134] As shown in FIG. 7, method 700 may include, at step 716, selecting one of the optional installment plans. For example, user 602 may select, using computing device 106 viewing an installment selection interface accessible via the unique URL, an installment plan to proceed with for the current transaction. The user’s 602 selection may be transmitted from computing device 106 to transaction processing system 102 (e.g., an installment system thereof).

[0135] As shown in FIG. 7, method 700 may include, at step 718, sending the user’s installment plan and other transaction data to issuer system 104 for authentication. For example, an installment system of transaction processing system 102 may provide the user’s 602 selected installment plan (e.g., as equated monthly installment (EMI) data) to a security and authentication system of transaction processing system 102, which may forward the user’s 602 selected installment plan data and transaction data to issuer system 104 for authentication.

[0136] As shown in FIG. 7, method 700 may include, at step 720, completing an authentication of the requested installment-based transaction. For example, in response to receiving the user’s 602 installment plan and transaction data from transaction processing system 102, issuer system 104 may authenticate the transaction (e.g., using one-time passcode (OTP) or other step-up authentication process). Also in step 720, issuer system 104 may communicate an authenticationresponse message to transaction processing system 102 indicating success of the authentication and including the user’s 602 intended installment plan.

[0137] As shown in FIG. 7, method 700 may include, at step 722, forwarding the authentication response message to merchant system 103. For example, in response to receiving the authentication response message from issuer system 104 in step 720, transaction processing system 102 may forward an authentication response message to merchant system 103.

[0138] As shown in FIG. 7, method 700 may include, at step 724, transmitting an authorization and payment request message including the installment plan data. For example, merchant system 103, having confirmed authentication of the intended installment-based payment, may generate and transmit an authorization request to issuer system 104 (e.g., directly, or via transaction processing system 102) to continue the payment processing of the installment-based payment. The authorization request message may include data of the installment plan.

[0139] As shown in FIG. 7, method 700 may include, at step 726, converting the original transaction into a series of installment payments. For example, issuer system 104 may convert the original transaction into a series of installment payments, including a first immediate payment, followed by one or more later-scheduled payments. Issuer system 104 may, at step 726, transfer funds from an account of user 602 to an account of merchant system 103 for an amount associated with a first installment of the installment plan.

[0140] As shown in FIG. 7, method 700 may include, at step 728, transmitting a payment plan and statements for scheduled payments, under the installment plan, to computing device 106. For example, issuer system 104 may transmit a schedule of payments to computing device 106, associated with one or more remaining installment payments that are forthcoming under the installment plan, and which have been authorized.

[0141] With further reference to FIG. 7, the described method 700 may be performed in a 3-domain secure (3DS) environment. For example, merchant system 103 may include a user-facing payment interface (e.g., a merchant application), which communicates with computing device 106 on a frontend. Merchant system 103 may further include a merchant 3DS server, which communicates on the backend with transaction processing system 102 and issuer system 104. The merchant 3DS server may provide first-domain validations, and transaction processing system 102 mayprovide second-domain validations. By way of further example, issuer system 104 may include an access control server (ACS) that performs third-domain validations. After issuer system 104 provides the third-domain validation, eligibility for installment payment may be performed, and the installment payment process may be injected into the 3DS transaction process flow e.g., including generating the unique URL, receiving a user selection of an installment plan, and the like).

[0142] Although embodiments have been described in detail for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that the disclosure is not limited to the disclosed embodiments or aspects, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

What is claimed is:1 . A system comprising: at least one processor configured to: receive a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount; determine eligibility for installment payment based on the first authentication request; generate a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface; transmit the unique URL to the merchant system; receive a user selection of an installment plan from the computing device via the installment selection interface; generate a second authentication request identifying the user selection of the installment plan and comprising the first amount; and cause an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

2. The system of claim 1 , wherein the at least one processor is further configured to: in response to receiving the first authentication request, transmit an issuer-side authentication request to the issuer system based on the transaction for the first amount; receive an issuer-side authentication response from the issuer system; in response to receiving the issuer-side authentication response, determine the eligibility for installment payment; and in response to determining that the transaction is eligible for installment payment, generate the unique URL.

3. The system of claim 1 , wherein the at least one processor is further configured to:proximal to generating the unique URL, determine at least one optional installment plan based on the transaction and the first amount; and display the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

4. The system of claim 3, wherein each optional installment plan of the at least one optional installment plan is associated with an interval period and an installment payment amount, and wherein the second authentication request comprises data of the interval period and the installment payment amount associated with the user selection of the installment plan.

5. The system of claim 4, wherein the at least one optional installment plan comprises a plurality of optional installment plans, and wherein each optional installment plan of the plurality of optional installment plans is associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

6. The system of claim 3, wherein the at least one processor is further configured to temporarily store the unique URL in association with the at least one optional installment plan for a time period, and wherein the unique URL is configured to automatically deactivate after the time period.

7. The system of claim 6, wherein the at least one processor is further configured to, in response to transmitting the second authentication request to the issuer system, deactivate the unique URL and clear the at least one optional installment plan from memory.

8. The system of claim 1 , wherein the at least one processor is configured to, when determining the eligibility for the installment payment, retrieve an eligibility status from a stored record associated with a payment device of the user associated with the transaction, and wherein the at least one processor is further configured to dynamically process a first plurality of transactions as installment-basedtransactions and a second plurality of transactions as one-time-payment transactions based on a plurality of eligibility statuses in a plurality of stored records.

9. The system of claim 1 , further comprising at least one issuer processor of the issuer system, the at least one issuer processor configured to, in response to receiving the second authentication request, initiate the installment-based transaction, wherein the at least one issuer processor is configured to, when initiating the installment-based transaction: generate a second authentication response associated with the installment-based transaction; transmit the second authentication response to the merchant system via the at least one processor; and receive an authorization request from the merchant system associated with the installment-based transaction.

10. The system of claim 9, wherein the at least one issuer processor is further configured to: in response to receiving the authorization request from the merchant system, transfer a first installment payment that is less than the first amount from a transaction account of the user to a transaction account of the merchant; and transmit a schedule of payments to the computing device based on at least one remaining installment payment of the installment-based transaction.

11. A method comprising: receiving, with at least one processor, a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount; determining, with at least one processor, eligibility for installment payment based on the first authentication request; generating, with at least one processor, a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface;transmitting, with at least one processor, the unique URL to the merchant system; receiving, with at least one processor, a user selection of an installment plan from the computing device via the installment selection interface; generating, with at least one processor, a second authentication request identifying the user selection of the installment plan and comprising the first amount; and causing, with at least one processor, an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

12. The method of claim 11 , further comprising: in response to receiving the first authentication request, transmitting, with at least one processor, an issuer-side authentication request to the issuer system based on the transaction for the first amount; receiving, with at least one processor, an issuer-side authentication response from the issuer system; in response to receiving the issuer-side authentication response, determining, with at least one processor, the eligibility for installment payment; and in response to determining that the transaction is eligible for installment payment, generating, with at least one processor, the unique URL.

13. The method of claim 11 , further comprising: proximal to generating the unique URL, determining, with at least one processor, at least one optional installment plan based on the transaction and the first amount; and displaying, with at least one processor, the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

14. The method of claim 13, wherein each optional installment plan of the at least one optional installment plan is associated with an interval period and an installment payment amount, and wherein the second authentication requestcomprises data of the interval period and the installment payment amount associated with the user selection of the installment plan.

15. The method of claim 14, wherein the at least one optional installment plan comprises a plurality of optional installment plans, and wherein each optional installment plan of the plurality of optional installment plans is associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

16. A computer program product, comprising at least one non- transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive a first authentication request from a merchant system of a merchant, the first authentication request associated with a transaction between a user and the merchant for a first amount; determine eligibility for installment payment based on the first authentication request; generate a unique uniform resource locator (URL) associated with an installment selection interface hosted by a transaction processing system, wherein the unique URL is configured to permit access from a computing device of the user to the installment selection interface; transmit the unique URL to the merchant system; receive a user selection of an installment plan from the computing device via the installment selection interface; generate a second authentication request identifying the user selection of the installment plan and comprising the first amount; and cause an issuer system to initiate an installment-based transaction by transmitting the second authentication request to the issuer system.

17. The computer program product of claim 16, wherein the program instructions further cause the at least one processor to: in response to receiving the first authentication request, transmit an issuer-side authentication request to the issuer system based on the transaction for the first amount;receive an issuer-side authentication response from the issuer system; in response to receiving the issuer-side authentication response, determine the eligibility for installment payment; and in response to determining that the transaction is eligible for installment payment, generate the unique URL18. The computer program product of claim 16, wherein the program instructions further cause the at least one processor to: proximal to generating the unique URL, determine at least one optional installment plan based on the transaction and the first amount; and display the at least one optional installment plan in the installment selection interface, wherein the user selection of the installment plan is from the at least one optional installment plan.

19. The computer program product of claim 18, wherein each optional installment plan of the at least one optional installment plan is associated with an interval period and an installment payment amount, and wherein the second authentication request comprises data of the interval period and the installment payment amount associated with the user selection of the installment plan.

20. The computer program product of claim 19, wherein the at least one optional installment plan comprises a plurality of optional installment plans, and wherein each optional installment plan of the plurality of optional installment plans is associated with a different interval period and a different installment payment amount from other optional installment plans of the plurality of optional installment plans.

Images