Systems, methods, and computer program products for multi-account access based on a single credential

Abstract

A system, method, and computer program product are provided for multi-account access based on a single authentication information. An exemplary system includes at least one processor configured to receive an authentication request message associated with a transaction having a first account identifier. It is determined whether the transaction and / or the first account identifier is eligible for dynamic processing. At least one processing option available for dynamic processing of the transaction is identified. A modified authentication request message is sent to an issuing system indicating one or more processing options. An authentication response message is received from the issuing system having an authentication indicator and a funds source identifier corresponding to the selected processing option. The modified authentication response message is sent to an acquiring system based on the authentication indicator and the funds source identifier.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 481,359, filed January 24, 2023, and U.S. Provisional Patent Application No. 63 / 485,516, filed February 16, 2023, the disclosures of each of which are incorporated herein by reference in their entireties.

[0002] The present disclosure relates generally to transaction message routing and, in some non-limiting embodiments or aspects, to systems, methods, and computer program products for multi-account access based on a single credential. [Background technology]

[0003] Electronic payment processing systems may use account identifiers to initiate and / or settle transactions. For example, a payment transaction may be initiated with a credit card number (e.g., a primary account number (PAN)) at a merchant system, and the same credit card number may be used to settle the transaction later. In such systems, each payment device (e.g., credit card, debit card, prepaid card, etc.) may have a single account number (e.g., PAN) associated with it.

[0004] However, such systems may require users to physically select different payment instruments (or remember to enter account identifiers for different payment instruments) to use different accounts for different types of transactions. As a result, users may be required to carry multiple different payment instruments and / or memorize different account identifiers. Furthermore, these electronic payment processing systems do not allow users to substitute different accounts and / or different account types (e.g., debit card accounts, credit card accounts, prepaid card accounts, etc.) once a payment transaction is initiated with a particular payment instrument. Furthermore, these payment processing systems do not allow a transaction to be settled with an account and / or account type different from the account associated with the payment instrument used to initiate the transaction. This is inconvenient in situations where the settlement process of a payment transaction is rejected or prevented for unknown reasons. Furthermore, these electronic payment processing systems only allow one funding source to be associated with one authentication information (e.g., account identifier). Summary of the Invention [Problem to be solved by the invention]

[0005] Thus, improved systems, methods, and computer program products are provided for multi-account access based on a single credential (eg, overcoming some or all of the deficiencies identified above). [Means for solving the problem]

[0006] According to a non-limiting embodiment or aspect, a system for multi-account access based on a single authentication credential is provided. An exemplary system may include at least one processor configured to receive an authentication request message associated with a transaction from an acquiring system. The authentication request message may include a first account identifier. A determination is made as to whether at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing. At least one processing option available for dynamic processing of the transaction is identified. A modified authentication request message is sent to the issuing system. The modified authentication request message may indicate the at least one processing option. An authentication response message may be received from the issuing system. The authentication response message may include an authentication indicator and a source of funds identifier corresponding to the selected processing option of the at least one processing option. The modified authentication response message based on the authentication indicator and the source of funds identifier may be sent to the acquiring system.

[0007] In some non-limiting embodiments or aspects, the first account identifier may include lead authentication information.

[0008] In some non-limiting embodiments or aspects, the lead authentication information may be configured to identify at least one of the account holder, the default payment account, or any combination thereof.

[0009] In some non-limiting embodiments or aspects, dynamic processing may comprise deferred processing.

[0010] In some non-limiting embodiments or aspects, the funding source identifier may include a second account identifier.

[0011] In some non-limiting embodiments or aspects, the source of funds identifier comprises at least one of a product identifier (PID), an account source of funds (AFS), or any combination thereof.

[0012] In some non-limiting embodiments or aspects, the at least one processing option may include at least two processing options associated with the same funding source.

[0013] In some non-limiting embodiments or aspects, the at least one processing option may include at least two processing options, each associated with a different funding source.

[0014] In some non-limiting embodiments or aspects, the at least one processor may be further configured to process the transaction based on the identifier of the funds source and the selected processing option prior to sending the modified authorization response message, and / or generate a modified authorization response message based on processing of the transaction.

[0015] In some non-limiting embodiments or aspects, the issuing system may be configured to determine the selected processing option, determine a funding source compatible with the selected processing option, and / or generate an authentication response message including the authentication indicator and an identifier of the funding source compatible with the selected processing option based on customized rules associated with the account holder associated with the first account identifier.

[0016] In some non-limiting embodiments or aspects, the issuing system may be configured to receive at least one input associated with the customized rule from the account holder.

[0017] According to a non-limiting embodiment or aspect, a method for multi-account access based on a single authentication information is provided. An exemplary computer-implemented method may include receiving an authentication request message associated with a transaction from an acquiring system. The authentication request message may include a first account identifier. The method may be configured to determine whether at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing. The method may be configured to identify at least one processing option available for dynamic processing of the transaction. The method may be configured to send a modified authentication request message to the issuing system, the modified authentication request message indicating the at least one processing option. The method may be configured to receive an authentication response message from the issuing system. The authentication response message may include an authentication indicator and a source of funds identifier corresponding to a selected processing option of the at least one processing option. The modified authentication response message based on the authentication indicator and the source of funds identifier may be sent to the acquiring system.

[0018] In some non-limiting embodiments or aspects, the first account identifier can include lead authentication information. In some non-limiting embodiments or aspects, the lead authentication information can identify at least one of the account holder, the default payment account, or any combination thereof.

[0019] In some non-limiting embodiments or aspects, dynamic processing may comprise deferred processing.

[0020] In some non-limiting embodiments or aspects, the funding source identifier may include a second account identifier.

[0021] In some non-limiting embodiments or aspects, the source of funds identifier may comprise at least one of a product identifier (PID), an account source of funds (AFS), or any combination thereof.

[0022] In some non-limiting embodiments or aspects, the at least one processing option may include at least one of at least two processing options associated with the same funding source, at least two processing options associated with different funding sources, or any combination thereof.

[0023] In some non-limiting embodiments or aspects, the transaction may be processed based on the identifier of the funds source and the selected processing options before sending the modified authorization response message, and / or the modified authorization response message may be generated based on processing of the transaction.

[0024] In some non-limiting embodiments or aspects, the issuing system may receive at least one input associated with a customized rule from an account holder associated with a first account identifier, determine the selected processing option based on the customized rule associated with the account holder, determine the source of funds compatible with the selected processing option, and / or generate the authentication response message including the authentication indicator and the identifier of the source of funds compatible with the selected processing option.

[0025] According to a non-limiting embodiment or aspect, a computer program product for multi-account access based on a single authentication information is provided. The exemplary computer program product may include 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, from an acquiring system, an authentication request message associated with a transaction. The authentication request message may include a first account identifier. The program determines whether at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing. At least one processing option available for dynamic processing of the transaction is identified. A modified authentication request message is sent to the issuing system. The modified authentication request message may indicate the at least one processing option. An authentication response message may be received from the issuing system. The authentication response message may include an authentication indicator and a source of funds identifier corresponding to a selected processing option of the at least one processing option. The modified authentication response message based on the authentication indicator and the source of funds identifier may be sent to the acquiring system.

[0026] According to non-limiting embodiments or aspects, a computer program product for multi-account access based on a single credential is provided. An exemplary computer program product may include 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 perform any one of the methods described herein.

[0027] Further non-limiting embodiments or aspects are described in the following numbered clauses:

[0028] Clause 1. A system, comprising: at least one processor configured to: receive from an acquiring system an authentication request message associated with a transaction, the authentication request message comprising a first account identifier; determine that at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing; identify at least one processing option available for the dynamic processing of the transaction; send a modified authentication request message to an issuing system indicating the at least one processing option; receive from the issuing system an authentication response message comprising an authentication indicator and an identifier of a funds source compatible with a selected processing option of the at least one processing option; and send a modified authentication response message to the acquiring system based on the authentication indicator and the identifier of the funds source.

[0029] Clause 2. The system of clause 1, wherein the first account identifier includes lead authentication information.

[0030] Clause 3. The system of clause 1 or 2, wherein the lead authentication information identifies at least one of an account holder, a default payment account, or any combination thereof.

[0031] Clause 4: The system of any one of clauses 1 to 3, wherein the dynamic processing includes delayed processing.

[0032] Clause 5. The system of any one of clauses 1-4, wherein the identifier of the source of funds includes a second account identifier.

[0033] Clause 6. The system of any one of clauses 1-5, wherein the identifier of the source of funds includes at least one of a product identifier (PID), an account source of funds (AFS), or any combination thereof.

[0034] Clause 7. The system of any one of clauses 1-6, wherein the at least one processing option includes at least two processing options associated with the same funding source.

[0035] Clause 8. The system of any one of clauses 1-7, wherein the at least one processing option includes at least two processing options, each associated with a different funding source.

[0036] Clause 9. The system described in any one of clauses 1 to 8, wherein the at least one processor is further configured to process the transaction based on the identifier of the funds source and the selected processing option before sending the modified authentication response message, and generate the modified authentication response message based on the processing of the transaction.

[0037] Clause 10. The system of any one of clauses 1-9, wherein the issuing system is configured to: determine the selected processing option based on customized rules associated with an account holder associated with the first account identifier; determine the source of funds capable of supporting the selected processing option; and generate the authentication response message including the authentication indicator and the identifier of the source of funds capable of supporting the selected processing option.

[0038] Clause 11. The system of any one of clauses 1-10, wherein the issuing system is configured to receive at least one input associated with the customized rule from the account holder.

[0039] Clause 12. A computer-implemented method, comprising: receiving, by at least one processor, from an acquiring system an authorization request message associated with a transaction, the authorization request message comprising a first account identifier; determining, by the at least one processor, that at least one of the transaction, the first account identifier, or any combination thereof, is eligible for dynamic processing; identifying, by the at least one processor, at least one processing option available for the dynamic processing of the transaction; transmitting, by the at least one processor, a modified authorization request message to an issuing system indicating the at least one processing option; receiving, by the at least one processor, from the issuing system an authorization response message comprising an authentication indicator and an identifier of a funds source compatible with a selected processing option of the at least one processing option; and transmitting, by the at least one processor, a modified authorization response message to the acquiring system based on the authentication indicator and the identifier of the funds source.

[0040] Clause 13. The method of clause 12, wherein the first account identifier includes lead authentication information, the lead authentication information identifying at least one of an account holder, a default payment account, or any combination thereof.

[0041] Clause 14. A method according to clause 12 or clause 13, wherein the dynamic processing comprises delayed processing.

[0042] Clause 15. The method of any one of clauses 12-14, wherein the identifier of the source of funds includes a second account identifier.

[0043] Clause 16. The method of any one of clauses 12-15, wherein the identifier of the funding source comprises at least one of a product identifier (PID), an account funding source (AFS), or any combination thereof.

[0044] Clause 17. The method of any one of clauses 12 to 16, wherein the at least one processing option includes at least one of at least two processing options associated with the same funding source, at least two processing options each associated with a different funding source, or any combination thereof.

[0045] Clause 18. The method of any one of clauses 12 to 17, further comprising, before sending the modified authentication response message, processing the transaction based on the identifier of the funds source and the selected processing option, by at least one processor; and generating, by at least one processor, the modified authentication response message based on the processing of the transaction.

[0046] Clause 19 The method of any one of clauses 12 to 18, further comprising: receiving, by the issuing system, at least one input associated with a customized rule from an account holder associated with the first account identifier; determining, by the issuing system, the selected processing option based on the customized rule associated with the account holder; determining, by the issuing system, the sources of funds compatible with the selected processing option; and generating, by the issuing system, the authentication response message including the authentication indicator and the identifier of the sources of funds compatible with the selected processing option.

[0047] Clause 20. A computer program product comprising at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receive, from an acquiring system, an authorization request message associated with a transaction, the authorization request message comprising a first account identifier; determine that at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing; identify at least one processing option available for the dynamic processing of the transaction; send a modified authorization request message to an issuing system indicating the at least one processing option; receive from the issuing system an authorization response message comprising an authentication indicator and an identifier of a funds source compatible with a selected processing option of the at least one processing option; and send a modified authorization response message to the acquiring system based on the authentication indicator and the identifier of the funds source.

[0048] Clause 21. A computer program product comprising at least one non-transitory computer readable medium containing program instructions that, when executed by at least one processor, cause the at least one processor to perform the method of any one of clauses 12 to 19.

[0049] These and other features and configurations of the present disclosure, as well as the method of operation and function of associated elements of construction and combination of parts and economies of manufacture, will become more apparent from a consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification, and in which like reference numerals indicate corresponding parts in the various views, it being expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a limiting definition of the disclosed subject matter. [Brief explanation of the drawings]

[0050] Further advantages and details are explained in more detail below with reference to non-limiting exemplary embodiments shown in the accompanying schematic drawings.

[0051] [Figure 1] FIG. 1 is a schematic diagram of an example payment processing network in which the systems, methods, and / or computer program products described in this disclosure may be implemented according to some non-limiting embodiments or aspects. [Figure 2] 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. [Figure 3] FIG. 3 is a flow diagram of an exemplary method for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 4] FIG. 4 is a schematic diagram of an example implementation of a transaction flow in a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 5] FIG. 5 is a schematic diagram of an example implementation of a transaction flow in a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 6] FIG. 6 is a schematic diagram of an example implementation in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using lead credentials and has alternative funding options, according to some non-limiting embodiments or aspects. [Figure 7] FIG. 7 is a schematic diagram of an example implementation in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using authentication information and has multiple processing options associated with the same funding source, according to some non-limiting embodiments or aspects. [Figure 8]FIG. 8 is a schematic diagram of an example implementation in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using authentication information and has multiple alternative processing options, each associated with a different funding source, according to some non-limiting embodiments or aspects. [Figure 9] FIG. 9 is a schematic diagram of an example implementation in which authentication information is associated with multiple processing options (e.g., payment program identifiers), and each payment option is associated with a different funding source, according to some non-limiting embodiments or aspects. [Figure 10] FIG. 10 is a schematic diagram of an example implementation in which authentication information is associated with multiple processing options (e.g., payment program identifiers), and each payment option is associated with a different funding source, according to some non-limiting embodiments or aspects. [Figure 11] FIG. 11 is a schematic diagram of an example implementation in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using authentication information and has multiple alternative processing options, according to some non-limiting embodiments or aspects. [Figure 12] FIG. 12 is a schematic diagram of an example implementation of a transaction flow in a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 13] FIG. 13 is a schematic diagram of an example implementation of a transaction flow in a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 14] FIG. 14 is a schematic diagram of an example implementation of a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 15] FIG. 15 is a schematic diagram of an example implementation of a transaction flow in a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. [Figure 16] FIG. 16 is a schematic diagram of an example implementation of a clearing / settlement flow in a system for multi-account access based on a single credential, according to some non-limiting embodiments or aspects. DETAILED DESCRIPTION OF THE INVENTION

[0052] Hereinafter, for purposes of description, the terms "end," "top," "bottom," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and derivatives thereof, refer to the present embodiments as oriented in the drawings. However, it will be understood that the present disclosure contemplates various alternative modifications and step sequences unless expressly specified to the contrary. It will also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary and non-limiting embodiments or aspects of the disclosed subject matter. Therefore, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed in the present disclosure are not to be considered limiting.

[0053] Some non-limiting embodiments or aspects are described in this disclosure in relation to a threshold value. As used in this disclosure, meeting a threshold may refer to a value greater than the threshold, a value more than the threshold, a value higher than the threshold, a value equal to or greater than the threshold, a value less than the threshold, a value lower than the threshold, a value less than the threshold, a value equal to the threshold, etc.

[0054] No aspect, component, element, structure, act, step, function, instruction, and / or the like used in this disclosure should be construed as critical or essential unless expressly stated as such. Also, as used in this disclosure, 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 in this disclosure, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations 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 in this disclosure, the terms "has," "have," "having," or similar terms are intended to be open-ended. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Additionally, references to actions based on a state may refer to actions in response to a state. For example, the phrases "based on" and "depending on / in response to" may, in some non-limiting embodiments or aspects, refer to a condition for automatically triggering an action (e.g., a particular operation of an electronic device such as a computing device, processor, and / or the like).

[0055] As used in this disclosure, the term "acquirer institution" may refer to an entity licensed and / or authorized by a transaction service provider to initiate transactions (e.g., payment transactions) using payment devices associated with the transaction service provider. Transactions that an acquirer institution may initiate may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funds 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 in this disclosure, the term "acquiring system" may refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer running one or more software applications.

[0056] As used in this disclosure, 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 used as a substitute or alternative identifier for an original account identifier, such as a PAN. An account identifier may be alphanumeric or any combination of letters and / or symbols. A token may be associated with a PAN or other original account identifier in one or more data structures (one or more databases, and / or the like) such that it can be used to conduct transactions without directly using the original account identifier. In some implementations, an original account identifier, such as a PAN, may be associated with multiple tokens for different individuals or for different purposes.

[0057] As used in this disclosure, 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 examples, 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, 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 a transaction. For example, a client device may include one or more computers, handheld computers, laptop computers, tablet computers, mobile devices, mobile phones, wearable devices (e.g., watches, eyeglasses, lenses, clothing, and / or the like), PDAs, and / or the like. Furthermore, a “client” may also refer to an entity (e.g., a merchant, an acquirer, and / or the like) that owns, utilizes, and / or operates a client device to initiate a transaction (e.g., to initiate a transaction with a transaction service provider).

[0058] As used in this disclosure, the term “communication” may refer to receipt, receiving, sending, forwarding, providing, and / or the like of data (e.g., information, signals, messages, instructions, commands, and / or the like). When one unit (e.g., a device, a system, or a component of a device or system, combinations thereof, and / or the like) communicates with another unit, it means that the unit can directly or indirectly receive information from and / or send 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. Also, when two units communicate with each other, the information transmitted may be modified, processed, relayed, and / or routed between the first and second units. For example, a first unit may be communicating with a second unit even if the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be communicating with a second unit if at least one intermediate unit processes information received from a 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 containing data (e.g., a data packet and / or the like). It will be understood that many other configurations are possible.

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

[0060] 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 running 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 offers and / or maintains electronic wallets for customers, such as Google Pay®, Android Pay®, Apple Pay®, Samsung Pay®, and / or other similar electronic payment systems. In some non-limiting examples, an issuing bank may be an electronic wallet provider.

[0061] 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 a customer with an account identifier, such as a PAN, that uniquely identifies one or more accounts associated with the customer. The account identifier may be displayed 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 "issuing system" refers to one or more computing devices operated by or on behalf of an issuer institution, such as a server computer running one or more software applications. For example, an issuing system may include one or more authentication servers for authenticating transactions.

[0062] As used in this disclosure, the term "merchant" may refer to an individual or entity that provides goods and / or services, or access to goods and / or services, to a customer based on a transaction, such as a payment transaction. The terms "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 running one or more software applications.

[0063] As used herein, a "point-of-sale (POS) device" may refer to one or more devices that can be used by a merchant to conduct and / or process transactions (e.g., payment transactions). For example, a POS device may include one or more client devices. Additionally or alternatively, a POS device may include peripheral 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 receivers, payment terminals, and / or the like. As used herein, a "point-of-sale (POS) system" may refer to one or more client devices and / or peripheral devices used by a merchant to conduct transactions. For example, a POS system may include one or more POS devices and / or other similar devices that can be used to conduct payment transactions. 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 a web page, a mobile application, and / or the like.

[0064] As used in this disclosure, the term "payment device" may refer to a payment card (e.g., a credit or debit card), a gift card, a smart card, 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 merchant discount or loyalty card, a mobile phone, an electronic wallet mobile application, a personal digital assistant (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, a payment device may be configured to include volatile or non-volatile memory for storing information (e.g., an account identifier, an account holder's name, and / or the like).

[0065] As used in this disclosure, the term "payment gateway" may refer to an entity and / or payment processing system operated by or on behalf of such an entity (e.g., merchant service provider, payment service provider, payment facilitator, payment facilitator contracted with acquirer, payment aggregator, and / or the like) that provides payment services (e.g., transaction service provider payment services, payment processing services, and / or the like) to one or more merchants. The payment services may be associated with the use of portable financial devices managed by the transaction service provider. As used in this disclosure, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, server clusters, and / or the like operated by or for a payment gateway.

[0066] As used in this disclosure, the term "server" may refer to or include one or more computing devices operated by or facilitating communication and processing for multiple parties in a network environment, such as the Internet. However, it will be appreciated that communication may be facilitated through one or more public or private network environments, and various other configurations are possible. Furthermore, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) may be configured to communicate directly or indirectly within a network environment to form a "system."

[0067] As used in this disclosure, the term "system" may refer to one or more computing devices or a combination of computing devices (e.g., a processor, a server, a client device, a software application, components of the same, and / or the like). References to a "device," "server," "processor," and / or the like, as used in this disclosure, can refer to a previously described device, server, or processor, another device, server, or processor, and / or a combination of multiple devices, multiple servers, and / or multiple processors that are recited as performing a previous step or function. For example, as used in the specification and claims, a first device, first server, or first processor that is recited as performing a first step or first function may refer to the same or different device, server, or processor that is recited as performing a second step or second function.

[0068] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment guarantees 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 that runs 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.

[0069] As used in this disclosure, the term “payment token” or “token” may refer to an identifier used as a substitute or alternative identifier for an account identifier such as a PAN. The token may be associated with a PAN or other account identifier in one or more data structures (e.g., one or more databases and / or the like) so that it can be used to conduct transactions (e.g., payment transactions) without directly using the account identifier such as a PAN. In some implementations, an account identifier such as a PAN may be associated with multiple tokens for different individuals, different uses, and / or different purposes. For example, a payment token may include a sequence of numeric and / or alphanumeric characters that can be used as a substitute for the original account identifier. For example, the payment token “4900 0000 0000 0001” may be used in place of the PAN “4147 0900 0000 1234.” In some non-limiting embodiments or aspects, the payment token may be “format preserving” and configured to have a numeric format that conforms to account identifiers used in existing payment processing networks (e.g., ISO 8583 Financial Transaction Message Format). In some non-limiting embodiments or aspects, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve payment transactions, or to represent the original authentication information in other systems where the original authentication information would normally be provided. In some non-limiting embodiments or aspects, the token value may be generated such that recovery of the original PAN or other account identifier from the token value is not computationally derivable (e.g., by a one-way hash or other cryptographic function). Furthermore, in some non-limiting embodiments or aspects, the token format may be configured to allow an entity receiving a payment token to identify it as a payment token and recognize the entity that issued the token.

[0070] As used in this disclosure, the term "provisioning" may refer to the process of enabling a device to use a resource or service. For example, provisioning may involve enabling a device to perform transactions using an account. Additionally or alternatively, provisioning may include adding provisioning data associated with account data (e.g., a payment token representing an account number) to the device.

[0071] As used herein, the term “token requestor” may refer to an entity seeking to implement tokenization in accordance with embodiments or aspects of the subject matter of this disclosure. For example, a token requestor may initiate a request for a PAN to be tokenized by sending a token request message to a token service provider. Additionally or alternatively, a token requestor may receive a payment token in response to a token request message, eliminating the need to store the PAN associated with the token. In some non-limiting embodiments or aspects, a requestor may be an application, device, process, or system configured to perform actions associated with a token. For example, a requestor may request registration with a network token system, request token generation, token activation, token deactivation, token exchange, other token lifecycle management-related processes, and / or other token-related processes. In some non-limiting embodiments or aspects, a requestor may interface with the network token system via any suitable communication network and / or protocol (e.g., HTTPS, SOAP, and / or XML interfaces, among others). For example, a token requestor may include a card-on-file merchant, an acquirer, an acquirer processor, a payment gateway acting on behalf of a merchant, a payment enabler (e.g., an original equipment manufacturer, a mobile network operator, and / or the like), a digital wallet provider, an issuer, a third-party wallet provider, a payment processing network, and / or the like. In some non-limiting embodiments or aspects, a token requestor may request tokens for multiple domains and / or channels. Additionally or alternatively, a token requestor may be uniquely registered and identified by a token service provider within a tokenization ecosystem.For example, during token requestor registration, the token service provider may formally process the token requestor's application to join the token service system. In some non-limiting embodiments or aspects, the token service provider may collect information related to the nature of the requestor and associated usage of the token to validate and formally authorize the token requestor and establish appropriate domain restriction controls. Additionally or alternatively, a successfully registered token requestor may be assigned a token requestor identifier, which may be entered and maintained in a token vault. In some non-limiting embodiments or aspects, the token requestor identifier may be revoked and / or the token requestor may be assigned a new token requestor identifier. In some non-limiting embodiments or aspects, this information may be subject to reporting and auditing by the token service provider.

[0072] As used herein, the term “token service provider” may refer to an entity including one or more server computers in a token service system that generates, processes, and maintains payment tokens. For example, a token service provider may include or communicate with a token vault where generated tokens are stored. Additionally or alternatively, the token vault may maintain a one-to-one mapping between tokens and the PANs represented by the tokens. In some non-limiting embodiments or aspects, a token service provider may have the ability to reserve licensed BINs as token BINs to issue tokens for PANs that may be sent to the token service provider. In some non-limiting embodiments or aspects, various entities in a tokenization ecosystem may assume the role of token service provider. For example, payment networks and issuers, or their agents, may become token service providers by implementing a token service, according to non-limiting embodiments or aspects of the subject matter of this disclosure. Additionally or alternatively, a token service provider may provide reports or data output to a reporting tool regarding approved, pending, or rejected token requests, including assigned token requestor IDs. The token service provider may be configured to provide data output related to token-based transactions to reporting tools and applications, and, where appropriate, present the token and / or PAN in the report output. In some non-limiting embodiments or aspects, the EMVCo standards organization may be configured to publish specifications that define how tokenized systems may operate. For example, such specifications may be useful as technical information, but are not intended to limit any of the subject matter of this disclosure.

[0073] As used in this disclosure, the term "token vault" may refer to a repository that maintains established token-to-PAN mappings. For example, the token vault may also maintain other attributes of the token requestor that may be determined at registration and / or used by the token service provider to apply domain restrictions or other controls during transaction processing. In some non-limiting embodiments or aspects, the token vault may be part of the token service system. For example, the token vault may be provided as part of the token service provider. Additionally or alternatively, the token vault may be a remote repository accessible by the token service provider. In some non-limiting embodiments or aspects, the token vault may be protected by strong underlying physical and logical security due to the sensitive nature of the data mappings stored and managed therein. Additionally or alternatively, the token vault may be operated by any suitable entity, including a payment network, an issuer, a clearing house, another financial institution, a transaction service provider, and / or the like.

[0074] Non-limiting embodiments or aspects of the disclosed subject matter are directed to systems, methods, and computer program products for multi-account access based on a single credential. For example, non-limiting embodiments or aspects of the disclosed subject matter provide for receiving, from an acquiring system, an authentication request message associated with a transaction including a first account identifier; determining that at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing; identifying at least one processing option available for dynamic processing of the transaction; transmitting a modified authentication request message to an issuing system indicating the at least one processing option; receiving from the issuing system an authentication response message including an authentication indicator and an identifier of a funds source compatible with the selected processing option of the at least one processing option; and transmitting the modified authentication response message to the acquiring system based on the authentication indicator and the identifier of the funds source. In this manner, the disclosed subject matter enables one or more transactions to be initiated with a single account identifier (e.g., a flexible credential) and having different accounts and / or account types used to authorize and subsequently settle the transactions. Additionally, the presently disclosed subject matter allows a user to complete transactions using multiple different accounts and / or account types by carrying only one payment device and / or entering one account identifier. Furthermore, the disclosed subject matter allows a user to set customized rules for selecting which account and / or account type is used for different transactions (e.g., based on customizable criteria). Furthermore, the presently disclosed subject matter ensures that the same account used to authenticate the transaction is used to settle the transaction, even though the (second) account identifier used to complete the authentication is different from the (first) account identifier in the settlement message, by storing the (second) account identifier used to complete the authentication in a separate field of the modified authentication response. Furthermore, the disclosed subject matter allows multiple funding sources to be associated with a single authentication information (e.g., account identifier).

[0075] 1, there is shown a diagram of an exemplary payment processing network 100 in which the systems, methods, and / or computer program products for multi-account access based on a single credential described in this disclosure may be implemented according to certain non-limiting embodiments or aspects. As shown in FIG. 1, the payment processing network 100 may include a transaction processing system 101, a payment gateway system 102, a merchant system 104, an issuing system 106, an acquiring system 108, and / or a consumer device 110.

[0076] Transaction processing system 101 may include one or more devices capable of receiving information from and / or communicating information to payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like (e.g., directly, indirectly, via public and / or private communication network connections, and / or the like). For example, as shown in FIG. 1, transaction processing system 101 may be in communication with one or more issuing systems (e.g., issuing system 106), one or more acquiring systems (e.g., acquiring system 108), and / or one or more payment gateway systems (e.g., payment gateway system 102). While only a single issuing system 106, a single acquiring system 108, and a single payment gateway system 102 are shown, it will be understood that transaction processing system 101 may be in communication with multiple issuing systems, multiple acquiring systems, and / or multiple payment gateways. In some non-limiting embodiments or aspects, the transaction processing system 101 may include computing devices such as a server (e.g., a transaction processing server), a cluster of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction processing system 101 may be in communication with a data store, which may be local or remote to the transaction processing system 101. In some non-limiting embodiments or aspects, the transaction processing system 101 may receive information from, store information in, communicate information to, or retrieve information stored in a data store. In some non-limiting embodiments or aspects, the transaction processing system 101 may be associated with a transaction service provider, as described herein. In some non-limiting embodiments or aspects, the transaction processing system 101 may also operate as an issuing system, such that both the transaction processing system 101 and the issuing system 106 are a single system and / or controlled by a single entity.

[0077] The payment gateway system 102 may include one or more devices capable of receiving information from and / or communicating information to (e.g., directly, indirectly, via public and / or private communication network connections, and / or the like) the transaction processing system 101, the merchant system 104, the issuing system 106, the acquiring system 108, the consumer device 110, and / or the like. For example, as shown in FIG. 1, the payment gateway system 102 may be in communication with one or more merchant systems (e.g., the merchant system 104), one or more acquiring systems (e.g., the acquiring system 108), and / or one or more transaction processing systems (e.g., the transaction processing system 101). While only a single merchant system 104, a single acquiring system 108, and a single transaction processing system 101 are shown, it will be understood that the payment gateway system 102 may be in communication with multiple merchant systems, multiple acquiring systems, and / or multiple transaction processing systems. In some non-limiting embodiments or aspects, the payment gateway system 102 may include computing devices such as a server, a server cluster, and / or other similar devices. In some non-limiting embodiments or aspects, the payment gateway system 102 may be associated with a payment gateway, as described herein.

[0078] The merchant system 104 may include one or more devices capable of receiving information from and / or communicating information to (e.g., directly, indirectly, via public and / or private communication network connections, and / or the like) the transaction processing system 101, the payment gateway system 102, the issuing system 106, the acquiring system 108, the consumer device 110, and / or the like. For example, as shown in FIG. 1 , the merchant system 104 may be in communication with one or more payment gateway systems (e.g., the payment gateway system 102), one or more acquiring systems (e.g., the acquiring system 108), and / or one or more consumer devices (e.g., the consumer device 110). While only a single payment gateway system 102, a single acquiring system 108, and a single consumer device 110 are shown, it will be understood that the merchant system 104 may be in communication with multiple payment gateway systems, multiple acquiring systems, and / or multiple consumer devices. In some non-limiting embodiments or aspects, the merchant system 104 may include computing devices such as a server, a group of servers, a client device, a group of client devices, a POS device, a POS system, a computer, a computer system, peripherals, and / or other similar devices. In some non-limiting embodiments or aspects, the merchant system 104 may be associated with a merchant, as described herein. In some non-limiting embodiments or aspects, the merchant system 104 may include devices capable of receiving information from and / or communicating information to the consumer device 110 via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like) with the consumer device 110 and / or the like. In some non-limiting embodiments or aspects, the merchant system 104 may include one or more client devices.For example, the merchant system 104 may include a client device that allows the merchant to communicate information to the transaction processing system 101 (e.g., via at least one of the acquiring system 108 and / or the payment gateway system 102). Additionally, in some non-limiting embodiments or aspects, the merchant system 104 (e.g., its client device, its POS device, and / or the like) may operate as a payment gateway system such that both the merchant system 104 and the payment gateway system 102 are a single system and / or controlled by a single entity.

[0079] The issuing system 106 may include one or more devices capable of receiving information and / or communicating information to the transaction processing system 101, the payment gateway system 102, the merchant system 104, the acquiring system 108, the consumer device 110, and / or the like (e.g., directly, indirectly, via a public and / or private communication network connection, and / or the like). For example, as shown in FIG. 1 , the issuing system 106 may be in communication with one or more transaction processing systems (e.g., the transaction processing system 101) and / or one or more consumer devices (e.g., the consumer device 110). While only a single transaction processing system 101 and a single consumer device 110 are shown, it will be understood that the issuing system 106 may communicate with multiple transaction processing systems and / or multiple consumer devices 110. In some non-limiting embodiments or aspects, the issuing system 106 may include computing devices such as a server, a cluster of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction processing system 101 may be in communication with a data storage device, which may be local or remote to the transaction processing system 101. In some non-limiting embodiments or aspects, the transaction processing system 101 may be capable of receiving information from, storing information in, communicating information to, or retrieving information stored in the data storage device. In some non-limiting embodiments or aspects, the issuing system 106 may be associated with an issuer institution, as described herein. For example, the issuing system 106 may be associated with an issuer institution that issued a credit account, debit account, credit card, debit card, payment device, and / or the like to a user associated with the consumer device 110.

[0080] The acquiring system 108 may include one or more devices capable of receiving information from and / or communicating information to (e.g., directly, indirectly, via public and / or private communication network connections, and / or the like) the transaction processing system 101, the payment gateway system 102, the merchant system 104, the issuing system 106, the consumer device 110, and / or the like. For example, as shown in FIG. 1 , the acquiring system 108 may be configured to communicate with one or more transaction processing systems (e.g., the transaction processing system 101), one or more payment gateway systems (e.g., the payment gateway system 102), and / or one or more merchant systems (e.g., the merchant system 104). While only a single transaction processing system 101, a single payment gateway system 102, and a single merchant system 104 are illustrated, it will be understood that the acquiring system 108 may communicate with multiple transaction processing systems, multiple payment gateway systems, and / or multiple merchant systems. In some non-limiting embodiments or aspects, the acquiring system 108 may include computing devices such as a server, a server cluster, and / or other similar devices. In some non-limiting embodiments or aspects, the acquiring system 108 may be associated with an acquirer institution, as described herein.

[0081] The consumer device 110 may include one or more devices capable of receiving information from and / or communicating information to (e.g., directly, indirectly, via a public and / or private communication network connection, and / or the like) the transaction processing system 101, the payment gateway system 102, the merchant system 104, the issuing system 106, the acquiring system 108, and / or the like. For example, as shown in FIG. 1 , the consumer device 110 may be configured to communicate with one or more merchant systems (e.g., the merchant system 104) and / or one or more issuing systems (e.g., the issuing system 106). While only a single merchant system 104 and a single issuing system 106 are shown, it will be understood that the consumer device 110 may be configured to communicate with multiple merchant systems and / or multiple issuing systems. In some non-limiting embodiments or aspects, the consumer device 110 may be associated with a user who issued a credit account, debit account, credit card, debit card, payment instrument, and / or the like. In some non-limiting embodiments or aspects, the user device 110 may include a computing device such as a computer, portable computer, laptop computer, tablet computer, mobile device, mobile phone, smartphone, wearable device (e.g., watch, eyeglasses, lenses, clothing, and / or the like), PDA, client device, and / or other similar device. In some non-limiting embodiments or aspects, the user device 110 may include a payment device, as described herein. In some non-limiting embodiments or aspects, the consumer device 110 may include a device capable of receiving information from and / or communicating information to other customer devices 110 (e.g., directly, indirectly, via public and / or private communication network connections, via short-range wireless communication connections, and / or the like).In some non-limiting embodiments or aspects, the consumer device 110 may include a device capable of receiving information from and / or communicating information to the merchant system 104 via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like) with the merchant system 104 and / or the like. In some non-limiting embodiments or aspects, the consumer device 110 may include a client device.

[0082] In some non-limiting embodiments or aspects, the transaction processing system 101 may be in direct communication with the merchant system 104 (e.g., via a public and / or private communication network connection and / or the like). Additionally or alternatively, the transaction processing system 101 may be in communication with the merchant system 104 via a payment gateway 102 and / or an acquiring system 108. In some non-limiting embodiments or aspects, the acquiring system 108 associated with the merchant system 104 may be configured to act as a payment gateway 102 to facilitate communication of transaction messages (e.g., authorization requests) from the merchant system 104 to the transaction processing system 101. In some non-limiting embodiments or aspects, the merchant system 104 may be in direct communication with the payment gateway 102 (e.g., via a public and / or private communication network connection and / or the like). For example, a merchant system 104 including a physical POS device may be configured to communicate with the payment gateway 102 over a public or private network to conduct card-present transactions. As another example, a merchant system 104 including a server (e.g., a web server) may be configured to communicate with the payment gateway 102 over a public or private network, such as the Internet, to conduct card-not-present transactions.

[0083] To illustrate, processing a transaction (e.g., a payment transaction) may include generating a transaction message (e.g., an authorization request and / or the like) based on a customer's (e.g., an account holder associated with the customer device 110 and / or the like) account identifier and / or transaction data associated with the transaction. For example, the merchant system 104 (e.g., a client device of the merchant system 104, a POS device of the merchant system 104, and / or the like) may initiate the transaction by, for example, generating an authorization request (e.g., in response to receiving an account identifier from a payment device and / or a customer's portable financial device and / or the like). The merchant system 104 may communicate the authorization request to the payment gateway 102 and / or the acquiring system 108. In some non-limiting embodiments or aspects, the payment gateway 102 may communicate the authorization request to the acquiring system 108 and / or the transaction processing system 101. Additionally or alternatively, the acquiring system 108 (and / or the payment gateway 102) may communicate the authentication request to the transaction processing system 101. After receiving an authentication request from the merchant system 104 identifying an account identifier of a customer (e.g., an account holder associated with the consumer device 110 and / or account identifier), the transaction processing system 101 may communicate the authentication request (or a modified authentication request described in this disclosure) to the issuing system 106 (e.g., the issuing system that issued the payment device and / or account identifier). The issuing system 106 may determine an authentication decision (e.g., approve, deny, and / or the like) based on the authentication request, and / or the issuing system 106 may generate an authentication response based on the authentication decision and / or authentication request. The issuing system 106 may communicate the authentication response to the transaction processing system 101. The transaction processing system 101 may be configured to communicate the authorization response (or a modified authorization response as described herein) to the acquiring system 108 and / or the payment gateway 102.In some non-limiting embodiments or aspects, the acquiring system 108 may be configured to communicate the authentication response (or a modified authentication response) to the payment gateway 102 and / or the merchant system 104. Additionally or alternatively, the payment gateway 102 (and / or the acquiring system 108) may be configured to communicate the authentication response (or a modified authentication response) to the merchant system 104.

[0084] To illustrate, clearing and / or settlement of a transaction may include generating a message (e.g., a clearing message and / or the like) based on a customer's account identifier (e.g., associated with the customer device 110 and / or the like) and / or transaction data associated with the transaction. For example, the merchant system 104 may be configured to generate at least one clearing message (e.g., multiple clearing messages, a batch of clearing messages, and / or the like). The merchant system 104 may be configured to communicate one or more clearing messages to the acquiring system 108 (and / or the payment gateway 102, which may communicate the one or more clearing messages to the acquiring system 108). The acquiring system 108 may be configured to communicate the one or more clearing messages to the transaction processing system 101. The transaction processing system 101 may be configured to communicate the one or more clearing messages to the issuing system 106. The issuing system 106 may be configured to generate at least one settlement message based on the one or more clearing messages. In some non-limiting embodiments or aspects, the issuing system 106 may be configured to communicate one or more payment messages and / or funds to the transaction processing system 101 (and / or a clearing bank system associated with the transaction processing system 101), which may be configured to communicate the one or more payment messages and / or funds to the acquiring system 108. Additionally or alternatively, the issuing system 106 may be configured to communicate the one or more payment messages and / or funds to the acquiring system 108. In some non-limiting embodiments or aspects, the acquiring system 108 may be configured to communicate the one or more payment messages and / or funds to the seller system 104 (and / or an account associated with the seller system 104).

[0085] In some non-limiting embodiments or aspects, the transaction processing system 101 may be configured to receive an authentication request message associated with a transaction (e.g., from at least one of the acquiring system 108, the payment gateway 102, and / or the merchant system 104). For example, the authentication request message may include a first account identifier. The transaction processing system 101 may determine that at least one of the transaction, the first account identifier, or any combination thereof is suitable for dynamic processing (e.g., deferred processing), as described herein. The transaction processing system 101 may be configured to identify at least one processing option available for dynamic processing of the transaction, as described herein. The transaction processing system 101 may be configured to send a modified authentication request message to the issuing system 106. For example, the modified authentication request message may indicate the at least one processing option, as described herein. The transaction processing system 101 may be configured to receive an authentication response message from the issuing system 106. For example, the authentication response message may include an authentication indicator and a funds source identifier corresponding to the selected processing option of at least one processing option, as described herein. The transaction processing system 101 may be configured to send a modified authentication response message (e.g., to at least one of the acquiring system 108, the payment gateway 102, and / or the merchant system 104) based on the authentication indicator and the funds source identifier, as described herein.

[0086] In some non-limiting embodiments or aspects, the first account identifier may include lead authentication information. For example, the lead authentication information may identify the account holder. Additionally or alternatively, the lead authentication information may identify a default payment account.

[0087] In some non-limiting embodiments or aspects, dynamic processing may comprise deferred processing, as described in this disclosure.

[0088] In some non-limiting embodiments or aspects, the source of funds identifier may include a second account identifier. In some non-limiting embodiments or aspects, the source of funds identifier may include at least one of a product identifier (PID), an account source of funds (AFS), or any combination thereof.

[0089] In some non-limiting embodiments or aspects, the at least one processing option may include at least two processing options associated with the same funding source, hi some non-limiting embodiments or aspects, the at least one processing option includes at least two processing options, each associated with a different funding source.

[0090] In some non-limiting embodiments or aspects, the transaction processing system 101 may process the transaction based on the identifier of the funds source and the selected processing option (e.g., before sending the modified authorization response message). In some non-limiting embodiments or aspects, the transaction processing system 101 may be configured to generate a modified authorization response message based on the processing of the transaction (e.g., before sending the modified authorization response message).

[0091] 1 may be configured to communicate over one or more wired and / or wireless communication networks. For example, the one or more communication networks may include a cellular network (e.g., a Long Term 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, and / or the like), 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., a public switched telephone network (PSTN)), a private network (e.g., a private network associated with a transaction service provider), 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.

[0092] The number and configuration of systems and / or devices shown in Figure 1 are provided as examples. More or fewer systems and / or devices may be different and / or configured differently than those shown in Figure 1. Furthermore, two or more systems and / or devices shown in Figure 1 may be implemented within a single system and / or device, or a single system and / or device shown in Figure 1 may be implemented as multiple distributed systems or devices. Additionally or alternatively, a set of systems (e.g., one or more systems) and / or a set of devices (e.g., one or more devices) of payment processing network 100 may be configured to perform one or more functions described as being performed by another set of systems and / or another set of devices of payment processing network 100.

[0093] Referring now to FIG. 2 , a diagram of exemplary components of device 200 is shown, according to a non-limiting embodiment. Device 200 may correspond, by way of example, to transaction processing system 101, payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, and / or consumer device 110 of FIG. 1 . In some non-limiting embodiments, such a system or device 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 examples. In some non-limiting embodiments, device 200 may include additional, fewer, different, or differently configured components compared to 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.

[0094] 2, device 200 may include a bus 202, a processor 204, a memory 206, a storage component 208, an input component 210, an output component 212, and a communication interface 214. Bus 202 may include components that allow communication between 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 functions. The memory 206 may be configured to 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 the processor 204.

[0095] 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-optical disk, a solid-state disk, etc.) and / or another type of computer-readable medium. Input component 210 may include components that enable device 200 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally or alternatively, input component 210 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 212 may include components that provide output information from device 200 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 214 may include transceiver-like components (e.g., a transceiver, a separate receiver and transmitter, etc.) that enable 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 include a configuration that allows device 200 to receive information from 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, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, and / or the like.

[0096] The device 200 may be configured to implement one or more processes described in this disclosure. The device 200 may be configured to implement these processes based on the processor 204 executing software instructions stored by a computer-readable medium, such as the memory 206 and / or the storage component 208. The computer-readable medium may include any non-transitory memory device. The memory device may include memory space located within a single physical storage device or memory space spread across multiple physical storage devices. The software instructions may be read into the memory 206 and / or the storage component 208 from another computer-readable medium or from another device via the communication interface 214. When executed, the software instructions stored in the memory 206 and / or the storage component 208 may cause the processor 204 to implement one or more processes described in this disclosure. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described in this disclosure. Accordingly, the embodiments described in this disclosure are not limited to any specific combination of hardware circuitry and software. As used in this disclosure, the term "configured" may refer to a configuration of software, one or more devices, and / or hardware to perform and / or enable one or more functions (e.g., actions, processes, process steps, and / or the like). For example, a "configured processor" may refer to a processor that executes software instructions (e.g., program code) that cause the processor to perform one or more functions.

[0097] Referring now to FIG. 3 , a flow diagram of an exemplary method 300 for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 3 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be performed automatically in response to the execution and / or completion of a previous step. In certain non-limiting embodiments or aspects, one or more of the steps of method 300 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of method 300 may be performed (e.g., fully, partially, and / or to some other extent) by another system, device, system, or device separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0098] 3, at step 302, the method 300 may include receiving an authentication request message. For example, the transaction processing system 101 may receive an authentication request message associated with the transaction (e.g., from at least one of the acquiring system 108, the payment gateway 102, and / or the merchant system 104). In some non-limiting embodiments or aspects, the authentication request message may include an account identifier (e.g., a first account identifier).

[0099] In some non-limiting embodiments or aspects, the first account identifier may include lead authentication information, as described herein. For example, the lead authentication information may identify the account holder. Additionally or alternatively, the lead authentication information may identify a default payment account.

[0100] 3, in step 304, the method 300 may include determining that the transaction and / or the account identifier are eligible for dynamic processing. For example, the transaction processing system 101 may be configured to determine that at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing.

[0101] In some non-limiting embodiments or aspects, dynamic processing may comprise deferred processing, as described in this disclosure.

[0102] 3, in step 306, the method 300 may include identifying at least one processing option available for dynamic processing of the transaction. For example, the transaction processing system 101 may be configured to identify at least one processing option available for dynamic processing of the transaction.

[0103] In some non-limiting embodiments or aspects, the at least one processing option may include at least two processing options associated with the same funding source, as described herein.

[0104] In some non-limiting embodiments or aspects, the at least one processing option may include at least two processing options, each associated with a different funding source, as described herein.

[0105] 3, in step 308, the method 300 may include transmitting a modified authorization request message. For example, the transaction processing system 101 may transmit the modified authorization request message to the issuing system 106. In some non-limiting embodiments or aspects, the modified authorization request message may indicate one or more available processing options.

[0106] 3, at step 310, the method 300 may include receiving an authentication response. For example, the transaction processing system 101 may receive an authentication response message from the issuing system 106. In some non-limiting embodiments or aspects, the authentication response message may include an authentication indicator and an identifier of a source of funds corresponding to the selected processing option of at least one processing option.

[0107] In some non-limiting embodiments or aspects, the source of funds identifier may include a second account identifier. Additionally or alternatively, the source of funds identifier may include at least one of a product identifier (PID), an account source of funds (AFS), any combination thereof, and / or the like, as described herein.

[0108] In some non-limiting embodiments or aspects, the issuing system 106 may be configured to determine the selected processing option based on customized rules associated with the account holder associated with the first account identifier. Additionally or alternatively, the issuing system 106 may be configured to determine the funding sources available for the selected processing option.

[0109] In some non-limiting embodiments or aspects, the issuing system 106 may be configured to determine an authentication decision (e.g., approve, deny, and / or the like) based on the modified authentication request. For example, an authentication indicator may be associated with the authentication decision.

[0110] In some non-limiting embodiments or aspects, the issuing system 106 may be configured to generate an authentication response message (e.g., before sending the authentication response message) that includes an authentication indicator and a funding source identifier that correspond to the selected processing option.

[0111] In some non-limiting embodiments or aspects, the issuing system 106 may be configured to receive at least one input associated with the customized rule from the account holder (e.g., from a consumer device 110 associated with the account holder). For example, the consumer device 110 may be configured to receive one or more inputs via an application (e.g., a mobile application) on the consumer device 110, and the consumer device 110 may be configured to send at least one message to the issuing system 106 based on the one or more inputs. In some non-limiting embodiments or aspects, the issuing system 106 may be configured to receive the one or more inputs (and / or the one or more messages based on the one or more inputs) before determining the selected payment option and / or before generating an authentication response. For example, the issuing system 106 may receive the input (and / or the one or more messages based on the one or more inputs) before the transaction processing system receives the authentication request message.

[0112] In some non-limiting embodiments or aspects, the issuing system 106 may be configured to determine (e.g., set) customized rules based on one or more inputs. Additionally or alternatively, the issuing system 106 may be configured to communicate with the transaction processing system 101 based on these customized rules. For example, the issuing system 106 may be configured to communicate at least one communication based on the customized rules. Additionally or alternatively, the transaction processing system 301 may be configured to determine that the transaction and / or account identifier is eligible for dynamic processing based on these customized rules (and / or based on the one or more communications).

[0113] 3, at step 312, the method 300 may include transmitting a modified authorization response message. For example, the transaction processing system 101 may transmit the modified authorization response message (e.g., to at least one of the acquiring system 108, the payment gateway 102, and / or the merchant system 104) based on the authentication indicator and the funds source identifier.

[0114] In some non-limiting embodiments or aspects, prior to sending the modified authorization response, the transaction processing system 101 may process the transaction based on the identifier of the funds source and the selected processing option. Additionally or alternatively, the transaction processing system 101 may be configured to generate a modified authorization response message (e.g., based on processing the transaction).

[0115] Referring now to FIG. 4 , a schematic diagram of an illustrative example transaction flow 400 in a system for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. As shown in FIG. 4 , the example transaction flow 400 may include a consumer device 410, an acquiring system 408 / seller system 404, a transaction processing system 401, and / or an issuing system 406. In certain non-limiting embodiments or aspects, the consumer device 410 may be the same as or similar to the consumer device 110. In certain non-limiting embodiments or aspects, the acquiring system 408 / seller system 404 may be the same as or similar to the acquiring system 108 and / or the seller system 104. In certain non-limiting embodiments or aspects, the transaction processing system 401 may be the same as or similar to the transaction processing system 101. In certain non-limiting embodiments or aspects, the issuing system 406 may be the same as or similar to the issuing system 106. The number and configuration of systems and / or devices shown in FIG. 4 are provided as examples. Systems and / or devices may be more or less different and / or configured differently compared to those shown in Figure 4. Also, the steps shown in Figure 4 are for illustrative purposes only. It will be understood that some non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In some non-limiting embodiments or aspects, a step may be configured to be performed automatically in response to the execution and / or completion of a previous step.

[0116] As shown in FIG. 4, in step 422, a user (e.g., an account holder) may initiate a transaction (e.g., using a consumer device 410, a payment device, and / or the like). For example, the user (e.g., an account holder) may present an account identifier (e.g., a credential such as a lead credential, a modern credential, and / or the like) to a merchant terminal of the merchant system 404 (e.g., in-person transactions, card-present transactions) or to the consumer device 410 (e.g., electronic transactions, card-not-present transactions, and / or the like). For example, the account identifier (e.g., lead credential) may identify the user.

[0117] In some non-limiting embodiments or aspects, a user may have registered multiple programs, accounts, and / or transaction processing rules (e.g., customized rules) with the issuing system 406 and / or transaction processing system 401. In some non-limiting embodiments or aspects, the issuing system 406 and / or transaction processing system 401 may have configured customized rules.

[0118] As shown in FIG. 4, in step 424, the acquiring system 408 and / or the merchant system 404 may determine whether the transaction is associated with a transaction processing system 401 and / or whether the transaction can potentially be processed according to dynamic processing. Additionally or alternatively, the merchant (e.g., the merchant system 404) and / or the acquirer (e.g., the acquiring system 408) may have the option to opt in to (or out of) dynamic processing. If the transaction is not associated with a transaction processing system 401, if the transaction is not eligible for dynamic processing, and / or if the merchant and / or acquirer opts out of dynamic processing, embodiment 400 may proceed to step 426, where the transaction is processed as a regular transaction (e.g., one that does not include dynamic processing).

[0119] In some non-limiting embodiments or aspects, the acquiring system 408 and / or the seller system 404 may be configured to recognize an account identifier as potentially eligible for dynamic processing (e.g., lead authentication information associated with the dynamic processing). The acquiring system 408 and / or the seller system 404 may be configured to query options (e.g., secondary funding source / account options, processing options, etc.) from the transaction processing system 401 (e.g., based on the account identifier / lead authentication information). For example, such queries may be made using an application programming interface (API) with the transaction processing system 401. In some non-limiting embodiments or aspects, the acquiring system 408 and / or the seller system 404 may not be permitted to select secondary funding sources or transaction processing options, but may be configured to opt in or out after receiving potential processing options (e.g., based on the query). For example, the acquiring system 408 and / or the seller system 404 may be configured to determine, among other options, that a transaction may be processed as a split transaction. If the acquiring system 408 and / or the seller system 404 does not want to have the option of processing a transaction as a split transaction, the seller may be configured to opt out and request that the transaction be processed using the original or traditional form of funds (e.g., a default payment account). In some non-limiting embodiments or aspects, the seller may not be given the option to opt in or out.

[0120] In some non-limiting embodiments or aspects, the merchant system 404 may be configured to generate an authorization request message including at least one of an account identifier (e.g., lead credential), a merchant identifier (e.g., merchant ID and / or Visa Merchant Identifier (VMID)), a merchant category code (MCC), a transaction amount, any combination thereof, and / or the like. The merchant system 404 may be configured to forward the authorization request message to the acquiring system 408. The acquiring system 408 may be configured to recognize the account identifier (e.g., lead credential potentially eligible for dynamic processing) as a potential dynamic transaction (e.g., a transaction that may be processed with a different funding source than the account identifier / lead credential presented and / or accepted when the transaction is initiated).

[0121] In some non-limiting embodiments or aspects, the acquiring system 408 may be configured to send an authentication request message to the transaction processing system 401 .

[0122] 4, in steps 428-432, the transaction processing system 401 may be configured to determine whether the account identifier (e.g., lead authentication information) and / or transaction is suitable for dynamic processing (e.g., processing with at least one alternative funding source). For example, the transaction processing system 401 may be configured to determine (e.g., extract, identify, and / or perform other similar operations) at least one of an account number (e.g., PAN), a bank identification number (e.g., BIN), an MCC and / or a merchant identifier (e.g., VMID), an associated funding source / account and / or payment program, a transaction amount, any combination thereof, and / or the like (e.g., based on the authentication request message).

[0123] As shown in FIG. 4 , in step 428, the transaction processing system 401 may be configured to determine whether the account identifier (e.g., lead authentication information) is within at least one range associated with dynamic processing. As shown in FIG. 4 , in step 430, the transaction processing system 401 may be configured to determine whether the transaction meets MCC criteria (e.g., whether the merchant's MCC is eligible for and / or associated with dynamic processing). As shown in FIG. 4 , in step 432, the transaction processing system 401 may be configured to determine whether other criteria associated with dynamic processing are met (e.g., associated with transaction amount / spend amount, whether the merchant has opted in, whether the user has registered at least one other funding source, etc.). If the account identifier is not within the range, if the MCC criteria are not met, and / or if other criteria are not met, embodiment 400 may proceed to step 442, where the transaction is processed as a regular transaction (e.g., not involving dynamic processing).

[0124] 4, in step 434, transaction processing system 401 may be configured to communicate with issuing system 406 (e.g., send a modified authorization request message including at least one additional field based on a determination related to the account identifier / transaction's eligibility for dynamic processing) to verify eligibility criteria and / or obtain other necessary data for dynamic processing. For example, issuing system 406 may be configured to determine (e.g., confirm) that the transaction can be processed as a dynamic transaction (e.g., eligible based on the account identifier being within the range, the MCC criteria being met, and / or other criteria being met). For example, issuing system 406 may be configured to make such a determination based on the modified authorization request (e.g., including reading the additional field or fields).

[0125] In some non-limiting embodiments or aspects, the transaction processing system 401 may not have (e.g., may not store) one or more account identifiers for one or more alternative funding sources. For example, the transaction processing system 401 may identify an initial account identifier (e.g., lead authentication information) and / or a transaction as a dynamic transaction, but the transaction processing system 401 may not have access to an account identifier for a second funding source (e.g., a funding source used to process the transaction). Additionally or alternatively, the issuing system 406 may return (e.g., communicate) an identifier for the second funding source to the transaction processing system 401. For example, the issuing system 406 may communicate an authentication response indicating authorization (e.g., including an authentication indicator) to process the transaction using the second funding source. The authentication response may include an identifier for the second funding source. For example, the lead authentication information may include at least one of a debit account and / or a credit account identifier, and the second funding source may include an installment account (e.g., a BNPL account).

[0126] As shown in FIG. 4 , in step 436, transaction processing system 401 may be configured to check to determine (e.g., confirm) that issuing system 406 provided the data necessary for dynamic processing (e.g., in the authorization response). For example, upon receiving an identifier of a second funding source from issuing system 406 (e.g., in the authorization response), transaction processing system 401 may be configured to process the transaction with the second funding source. For example, transaction processing system 401 may process the transaction as an installment transaction (e.g., a BNPL transaction), using, for example, a loan funding account (e.g., thus dynamically switching processing from the lead (debit and / or credit) authentication information to the BNPL funding source during transaction authorization). If issuing system 406 did not provide the data necessary for dynamic processing (e.g., in the authorization response), embodiment 400 may proceed to step 442 and process the transaction as a regular transaction (e.g., not including dynamic processing).

[0127] 4, in step 438, transaction processing system 401 may be configured to generate a modified authorization response message. For example, transaction processing system 401 may be configured to augment the authorization response message with data associated with the dynamic transaction, such as including indicators of the outcome of the transaction, including clearing and settlement information regarding the second funding source (e.g., an AFS, PID, and / or the like associated with the second funding source) and / or the like.

[0128] As shown in FIG. 4, in step 440, the transaction processing network 401 may be configured to send the modified authorization response message to the acquiring system 408 and / or the merchant system 404, which may complete the transaction based on the modified authorization response.

[0129] In some non-limiting embodiments or aspects, the acquiring system 408 and / or the seller system 404 may be configured to initiate (e.g., at a later time) clearing and settlement with the transaction processing system 401 and / or the issuing system 406. For example, the acquiring system 408 and / or the seller system 404 may be configured to communicate at least one clearing message based on the second funds source information (e.g., the second funds source identifier from the modified authorization response).

[0130] In some non-limiting embodiments or aspects, the identifier of the second funding source may not be communicated (e.g., not included in the modified authorization response) to the acquiring system 408. In that case, the acquiring system 408 may be configured to settle the transaction using the account identifier in the lead authentication information, any other information that the transaction processing system 401 and / or the issuing system 406 may have, and / or the like.

[0131] Referring now to FIG. 5 , a schematic diagram of an illustrative example transaction flow 500 in a system for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 5 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be performed automatically in response to the execution and / or completion of a previous step. In certain non-limiting embodiments or aspects, one or more of the steps of example 500 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 500 may be performed (e.g., fully, partially, and / or to some other extent) by another system, device, other systems, or other devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0132] 5, in step 502, a user (e.g., an account holder) may initiate a transaction (e.g., using a consumer device 110, a payment device, and / or the like) as described herein. For example, the user (e.g., an account holder) may submit an account identifier as described herein. The account identifier (e.g., lead authentication information) may be linked to various processing options (e.g., payment programs / program IDs, transaction controls, etc.) and / or secondary funding sources (e.g., based on customized rules) as described herein.

[0133] As shown in FIG. 5, in step 504, the seller system 104 (and / or the acquirer system 108) may be configured to optionally exercise a selection (e.g., opt-in or opt-out) associated with dynamic processing, as described herein.

[0134] 5, in step 506, the merchant system 104 and / or the acquiring system 108 may be configured to communicate an authentication request as described herein. In some non-limiting embodiments or aspects, the acquiring system 108 may be configured to determine (e.g., recognize) that the transaction may be a dynamic transaction (e.g., based on the account identifier / lead authentication information and / or the transaction) as described herein.

[0135] 5, in step 508, the transaction processing system 101 may be configured to determine (e.g., check) whether the authorization request message is eligible for dynamic processing (e.g., based on PAN, BIN, associated payment program, spending criteria, MCC / VMID criteria, and / or the like) as described herein. The transaction processing system 101 may be configured to communicate the modified authorization request to the issuing system 106.

[0136] 5, in step 510, the issuing system 106 may be configured to communicate an authorization response as described herein. For example, the issuing system 106 may be configured to validate eligibility criteria, verify information / data provided in the modified authorization request, and / or determine a secondary funding source as described herein.

[0137] 5, at step 512, the transaction processing system 101 may be configured to validate the authorization response as described herein. For example, the transaction processing system 101 may be configured to check to determine (e.g., confirm) that the issuing system 106 provided the data necessary for dynamic processing (e.g., in the authorization response) as described herein.

[0138] In some non-limiting embodiments or aspects, the transaction processing system 101 may be configured to generate a modified authorization response as described herein. For example, the transaction processing system 101 may be configured to augment the authorization response with clearing and / or settlement information (e.g., secondary funding source (e.g., AFS and / or PID), interchange refund fee (IRF) eligibility (e.g., based on the secondary funding source), payment program details, and / or the like) to generate the modified authorization response.

[0139] As shown in FIG. 5, in step 514, clearing and settlement may occur (e.g., between the acquirer 108, the transaction processing system 101, and the issuing system 106) as described herein. For example, the clearing and settlement may be based on the second funding source account (e.g., updated and / or replaced with respect to the lead authentication information) and / or the PID (and / or AFS) associated with the second funding source account.

[0140] Referring now to FIG. 6 , a schematic diagram of an illustrative example 600 is shown in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using lead authentication information and has alternative funding options, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 6 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be performed automatically in response to the execution and / or completion of a previous step. In certain non-limiting embodiments or aspects, one or more of the steps of example 600 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 600 may be performed (e.g., fully, partially, and / or to some other extent) by another system, device, group of systems, or group of devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0141] As shown in Figure 6, in step 602, a consumer may initiate a transaction with a resource provider (e.g., the merchant system 104) using authentication information. For example, the authentication information may be a debit account identifier. In some non-limiting embodiments or aspects, the merchant system 104 may be configured to generate an authorization request that may be communicated to the transaction processing system 101 (e.g., via the acquirer 108) as described herein.

[0142] As shown in FIG. 6, in step 604, the transaction processing system 101 may be configured to determine (e.g., recognize) that the consumer is enrolled in a single alternative processing option (e.g., a single PID): split transaction processing. The transaction processing system 101 may be configured to determine (e.g., evaluate) whether the transaction is eligible for split processing. For example, the eligibility rules may indicate that all transactions over a predetermined amount (e.g., $100) should be processed as BNPL transactions.

[0143] In some non-limiting embodiments or aspects, if the transaction processing system 101 determines that the transaction is eligible for dynamic processing (e.g., processed as an installment / BNPL transaction using a purchase credit account instead of the originally bid debit account), the transaction processing system 101 may be configured to communicate with the issuing system 106 (e.g., communicate a revised authorization request to the issuing system 106).

[0144] As shown in FIG. 6 , in step 606, the issuing system 106 may be configured to determine (e.g., confirm) that the transaction is eligible to be processed as a split (e.g., BNPL) transaction, and the issuing system 106 may be configured to determine an account identifier for the second funding source account (e.g., a purchase credit account for a split / BNPL transaction). The issuing system 106 may be configured to communicate an authorization response to the transaction processing system 101 as described herein. For example, the authorization response may include authorization (e.g., an authorization indicator) to process the transaction as a split transaction and / or may include an account identifier for the second funding source (e.g., for a split / BNPL transaction). The transaction processing system 101 may be configured to process the transaction and / or communicate a modified authorization response based on the second funding source and / or its account identifier as described herein.

[0145] As shown in FIG. 6, if in step 608 the transaction processing system 101 determines that the transaction does not meet the eligibility requirements, embodiment 600 may proceed to step 610, where the transaction processing system 101 may be configured to process the transaction using the debit account originally bid.

[0146] Referring to FIG. 7 , a schematic diagram of an illustrative implementation 700 is shown in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using authentication information and has multiple processing options associated with the same funding source, according to some non-limiting embodiments or aspects. The steps shown in FIG. 7 are for illustrative purposes only. It will be understood that some non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In some non-limiting embodiments or aspects, a step may be performed automatically in response to the execution and / or completion of a previous step. In some non-limiting embodiments or aspects, one or more of the steps of implementation 700 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 700 may be performed (e.g., fully, partially, and / or to some other extent) by another system, device, group of systems, or group of devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0147] As shown in Figure 7, in step 702, a consumer may initiate a transaction with a resource provider (e.g., the merchant system 104) using authentication information. For example, the authentication information may be a debit account identifier. In some non-limiting embodiments or aspects, the merchant system 104 may be configured to generate an authorization request that may be communicated to the transaction processing system 101 (e.g., via the acquirer 108) as described herein.

[0148] As shown in FIG. 7 , in step 704, the transaction processing system 101 may be configured to determine (e.g., recognize) that the user is enrolled in multiple alternative processing options (e.g., multiple PIDs), namely, a first installment transaction option, a second installment transaction option, and a third installment transaction option. Each option may have its own (e.g., unique) installment terms (e.g., 2 months, 5 months, and 10 months, respectively) and / or its own (e.g., unique) interest rate. The transaction processing system 101 may be configured to evaluate which options are available for the transaction (e.g., based on customized rules for the consumer and / or the like). In some non-limiting embodiments or aspects, all of the options (or option subsets) may be associated with the same funding account (e.g., a second funding source account, which may be a loan account), even though each option is associated with different installment processing rules (e.g., terms, interest rates, etc.). In some non-limiting embodiments or aspects, if the transaction processing system 101 determines that the transaction is eligible for dynamic processing (e.g., processing as a dynamic transaction), the transaction processing system 101 may be configured to communicate a revised authentication request to the issuing system 106, for example, including a PID for one or more of the available options.

[0149] As shown in FIG. 7 , in step 706, the issuing system 106 may determine (e.g., confirm) that the transaction is eligible to be processed as a split transaction and / or may be configured to select one of the options (e.g., the second option), for example, based on a user / consumer's customized rules, as described herein. The issuing system 106 may be configured to communicate an authorization response to the transaction processing system 101, as described herein. For example, the authorization response may include authorization (e.g., an authorization indicator) to process the transaction as a split transaction and / or may include an identifier of a second funding source account (e.g., a loan account associated with the second option). The transaction processing system 101 may be configured to process the transaction and / or communicate a modified authorization response based on the second funding source and / or its account identifier, as described herein.

[0150] As shown in FIG. 7, if in step 708 the transaction processing system 101 determines that the transaction does not meet the eligibility requirements, embodiment 700 may proceed to step 710, where the transaction processing system 101 may be configured to process the transaction using the debit account originally bid.

[0151] Referring now to FIG. 8 , a schematic diagram of an illustrative example 800 is shown in which a consumer uses authentication information to initiate a transaction with a resource provider (e.g., a merchant) and has multiple alternative processing options, each associated with a different funding source, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 8 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be configured to be performed automatically in response to the execution and / or completion of a previous step. In certain non-limiting embodiments or aspects, one or more of the steps of example 800 may be performed (e.g., fully, partially, and / or similarly) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 800 may be performed (e.g., fully, partially, and / or to some other extent) by another system, device, group of systems, or group of devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0152] As shown in FIG. 8, in step 802, a consumer may initiate a transaction with a resource provider (e.g., the merchant system 104) using the authentication information. For example, the authentication information may be a PAN associated with a lead authentication indicator (e.g., a modern authentication indicator). In some non-limiting embodiments or aspects, the merchant system 104 may be configured to generate an authentication request that may be communicated to the transaction processing system 101 (e.g., via the acquirer 108) as described herein.

[0153] As shown in FIG. 8 , in step 804, the transaction processing system 101 may be configured to determine (e.g., recognize) that the user is enrolled in multiple alternative processing options (e.g., multiple PIDs), namely, a flexible savings account program, a saved value option, a meal coupon option, and a transportation program option. Each option may have unique requirements. In some non-limiting embodiments or aspects, the available options may include and / or be associated with employee benefits, each benefit funded by a different funding source. The transaction processing system 101 may be configured to determine (e.g., evaluate) which one or more options are available for the transaction (e.g., based on customized rules, as described herein). In some embodiments, each option may be associated with a different funding account (e.g., a second funding account), such as a first financial account (e.g., a health savings account (HAS)), a member-owned prepaid account, an issuer prepaid funding source, and a second financial account (e.g., a securities account). In some non-limiting embodiments or aspects, if the transaction processing system 101 determines that the transaction is eligible for dynamic processing (e.g., processing as a dynamic transaction), the transaction processing system 101 may be configured to communicate a revised authentication request to the issuing system 106, for example, including a PID for one or more of the available options.

[0154] As shown in FIG. 8 , at step 806, the issuing system 106 may be configured to determine (e.g., confirm) that the transaction is eligible to be processed as a dynamic transaction (e.g., using one of the available options), for example, based on the user / consumer's customized rules, as described herein. The issuing system 106 may be configured to communicate an authorization response to the transaction processing system 101, as described herein. For example, the authorization response may include an identifier of a second funding source account associated with the appropriate (e.g., selected) option. The authorization response may include authorization (e.g., an authorization indicator) to process the transaction as a dynamic transaction (e.g., process the transaction according to the available / selected option) and / or may include the identifier of the second funding source account. The transaction processing system 101 may be configured to process the transaction and / or communicate a modified authorization response based on the second funding source and / or its account identifier, as described herein.

[0155] For example, a user may conduct a transaction at a pharmacy. When the user presents a payment device containing lead authentication information, the transaction may be processed using the HSA account. If there are items in the transaction that are not eligible for HSA transactions, those items may be processed using the prepaid account. The user can then use the same payment device at an approved meal voucher restaurant to purchase food using the prepaid funds in question.

[0156] As shown in FIG. 8, if in step 808 the transaction processing system 101 determines that the transaction does not meet the eligibility requirements, embodiment 800 may proceed to step 810, where the transaction processing system 101 may be configured to process the transaction using the originally bidden PAN (e.g., as the default payment account).

[0157] Referring now to FIG. 9 , a schematic diagram of an illustrative example 900 is shown in which authentication information is associated with multiple processing options (e.g., payment program identifiers), with each payment option associated with a different funding source, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 9 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In some non-limiting embodiments or aspects, a step may be performed automatically in response to the execution and / or completion of a previous step. In some non-limiting embodiments or aspects, one or more of the steps of example 900 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 900 may be performed (e.g., completely, partially, and / or to some other extent) by another system, device, group of systems, or group of devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0158] As shown in FIG. 9 , in step 902, a consumer may initiate a transaction with a resource provider (e.g., the merchant system 104) using the authentication information. For example, the authentication information may be a PAN associated with a lead authentication indicator (e.g., a modern authentication indicator). In some non-limiting embodiments or aspects, the merchant system 104 may be configured to generate an authentication request that may be communicated to the transaction processing system 101 (e.g., via the acquirer 108) as described herein.

[0159] 9, in step 904, the transaction processing system 101 may be configured to determine (e.g., recognize) that the user is enrolled in multiple alternative processing options (e.g., multiple PIDs), as described herein. The transaction processing system 101 may be configured to determine (e.g., evaluate) which one or more options are available for the transaction (e.g., based on customized rules, as described herein). In some non-limiting embodiments or aspects, if the transaction processing system 101 determines that the transaction is eligible for dynamic processing (e.g., processing as a dynamic transaction), the transaction processing system 101 may be configured to communicate a revised authorization request to the issuing system 106, including, for example, the PIDs for one or more of the available options.

[0160] 9, at step 906, the issuing system 106 may be configured to determine (e.g., confirm) that the transaction is eligible to be processed as a dynamic transaction (e.g., using one of the available options), for example, based on the user / consumer's customized rules, as described herein. The issuing system 106 may be configured to communicate an authorization response to the transaction processing system 101, as described herein. For example, the authorization response may include an identifier of a second funding source account associated with the appropriate (e.g., selected) option, as described herein. The transaction processing system 101 may be configured to process the transaction and / or communicate a modified authorization response based on the second funding source and / or its account identifier, as described herein.

[0161] As shown in FIG. 9, if in step 908 the transaction processing system 101 determines that the transaction does not meet the eligibility requirements, embodiment 900 may proceed to step 910, where the transaction processing system 101 may be configured to process the transaction using the originally bidden PAN (e.g., as the default payment account).

[0162] Referring now to FIG. 10 , a schematic diagram of an illustrative example 1000 is shown in which authentication information is associated with multiple processing options (e.g., payment program identifiers), with each payment option associated with a different funding source, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 10 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In some non-limiting embodiments or aspects, a step may be configured to be performed automatically in response to the execution and / or completion of a previous step. In some non-limiting embodiments or aspects, one or more of the steps of example 1000 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 1000 may be performed (e.g., fully, partially, and / or to some other extent) by another system, device, group of systems, or group of devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0163] As shown in FIG. 10 , at step 1002, the consumer may initiate a transaction with a resource provider (e.g., the merchant system 104) using the authentication information. For example, the authentication information may be a PAN associated with a lead authentication indicator (e.g., a modern authentication indicator). In some non-limiting embodiments or aspects, the merchant system 104 may be configured to generate an authentication request that may be communicated to the transaction processing system 101 (e.g., via the acquirer 108) as described herein.

[0164] 10 , in step 1004, the transaction processing system 101 may be configured to determine (e.g., recognize) that the user is registered with multiple alternative processing options (e.g., multiple PIDs), as described herein. The transaction processing system 101 may be configured to determine (e.g., evaluate) which one or more options are available for the transaction (e.g., based on customized rules, as described herein). In some non-limiting embodiments or aspects, if the transaction processing system 101 determines that the transaction is eligible for dynamic processing (e.g., processing as a dynamic transaction), the transaction processing system 101 may be configured to communicate a revised authorization request to the issuing system 106, including, for example, the PIDs for one or more of the available options.

[0165] 10 , in step 1006, the issuing system 106 may be configured to determine (e.g., confirm) that the transaction is eligible to be processed as a dynamic transaction (e.g., using one of the available options), for example, based on the user / consumer's customized rules, as described herein. The issuing system 106 may be configured to communicate an authorization response to the transaction processing system 101, as described herein. For example, the authorization response may include an identifier of a second funding source account associated with the appropriate (e.g., selected) option, as described herein. The transaction processing system 101 may be configured to process the transaction and / or communicate a modified authorization response based on the second funding source and / or its account identifier, as described herein.

[0166] As shown in FIG. 10 , if in step 1008 the transaction processing system 101 determines that the transaction does not meet the eligibility requirements, the embodiment 900 may proceed to step 910, where the transaction processing system 101 may be configured to process the transaction using the originally bidden PAN (e.g., as the default payment account).

[0167] Referring now to FIG. 11 , a schematic diagram of an example implementation is shown in which a consumer initiates a transaction with a resource provider (e.g., a merchant) using authentication information and has multiple alternative processing options, according to some non-limiting embodiments or aspects. The steps shown in FIG. 11 are for illustrative purposes only. It will be understood that some non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In some non-limiting embodiments or aspects, a step may be performed automatically in response to the execution and / or completion of a previous step. In some non-limiting embodiments or aspects, one or more of the steps of example 1100 may be performed (e.g., fully, partially, and / or to some other extent) by transaction processing system 101 (e.g., one or more devices of transaction processing system 101). In some non-limiting embodiments or aspects, one or more steps of example 1100 may be performed (e.g., completely, partially, and / or to some other extent) by another system, device, group of systems, or group of devices separate from or including transaction processing system 101, such as payment gateway system 102, merchant system 104, issuing system 106, acquiring system 108, consumer device 110, and / or the like.

[0168] 11, in step 1102, a consumer may initiate a transaction with a resource provider (e.g., merchant system 104) using authentication information. For example, the authentication information may be a credit account identifier. In some non-limiting embodiments or aspects, the merchant system 104 may be configured to generate an authorization request that may be communicated to the transaction processing system 101 (e.g., via the acquirer 108) as described herein.

[0169] As shown in FIG. 10 , in step 1004, the transaction processing system 101 may be configured to determine (e.g., recognize) that the user is enrolled in multiple alternative processing options (sub-PIDs): a first credit transaction option and a second credit transaction option. Each option may have unique terms (e.g., interest rates). The transaction processing system 101 may be configured to determine (e.g., evaluate) which option is available for the transaction (e.g., based on customized rules, as described herein). In some non-limiting embodiments or aspects, both options may be associated with the same funding account (e.g., a credit account), even though each option is associated with different processing rules (e.g., terms, interest rates, etc.). For example, the funding source may be the same, but transaction details may determine whether the transaction qualifies for the first option or the second option.

[0170] In some non-limiting embodiments or aspects, if the transaction processing system 101 determines that the transaction is eligible for dynamic processing (e.g., processing as a dynamic transaction), the transaction processing system 101 may be configured to communicate a revised authentication request to the issuing system 106, for example, including sub-PIDs for one or more of the available options.

[0171] As shown in FIG. 11 , in step 1106, the issuing system 106 may be configured to determine (e.g., confirm) that the transaction is eligible to be processed as a dynamic transaction (e.g., using one of the available options, such as the second option). The issuing system 106 may be configured to identify (e.g., obtain) an identifier for the credit funding account. The issuing system 106 may be configured to communicate an authorization response to the transaction processing system 101 as described herein. For example, the authorization response may include authorization (e.g., an authorization indicator) to process the transaction using the selected (e.g., second) option, and the authorization response may include an account identifier for the second funding source (e.g., the credit funding account). The transaction processing system 101 may be configured to process the transaction and / or communicate a modified authorization response based on the second funding source and / or its account identifier as described herein.

[0172] As shown in FIG. 11, in step 1108, the transaction processing system 101 may be configured to process the transaction using one of the options (e.g., the first option) as the default payment account.

[0173] Referring now to FIG. 12 , a schematic diagram of an illustrative example transaction flow 1200 in a system for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 12 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be automatically performed in response to the execution and / or completion of a previous step. As shown in FIG. 12 , example 1200 may include a merchant system 1204, an acquiring system 1208, a transaction processing system 1201, and at least one issuing system (e.g., a first issuing system 1206-1 and a second issuing system 1206-2). In certain non-limiting embodiments or aspects, merchant system 1204 may be the same as or similar to merchant system 104. In some non-limiting embodiments or aspects, the acquiring system 1208 may be the same as or similar to the acquiring system 108. In some non-limiting embodiments or aspects, the transaction processing system 1201 may be the same as or similar to the transaction processing system 101. In some non-limiting embodiments or aspects, the first issuing system 1206-1 and / or the second issuing system 1206-2 may be the same as or similar to the issuing system 106. In some non-limiting embodiments or aspects, the first issuing system 1206-1 and the second issuing system 1206-2 may be associated with the same issuer institution and / or may be the same issuing system. In some non-limiting embodiments or aspects, the first issuing system 1206-1 and the second issuing system 1206-2 may each be associated with a separate issuer institution and / or may be separate issuing systems. The number and configuration of systems and / or devices shown in FIG. 12 are provided as examples.The systems and / or devices may be more or less different and / or configured differently compared to that shown in FIG.

[0174] 12, in step 1200, transaction processing system 1201 may be configured to configure (e.g., configure itself) the system for dynamic transaction processing. For example, at least one debit account identifier may be selected as lead authentication information, and at least one processing option (e.g., an alternative processing option associated with a second funding source) may be configured to be initialized as a loan / purchase credit account (e.g., installment and / or BNPL transaction). Thus, when a user presents a debit account identifier (e.g., an account identifier including a debit card and / or debit BIN), transaction processing system 1201 may be configured to determine (e.g., evaluate) whether the transaction is eligible for dynamic processing (e.g., process the eligible transaction using an alternative funding source, such as an installment / BNPL purchase credit account).

[0175] 12 , in step 1251, transaction processing system 1201 may set the account level processing (ALP) flag in the account range definition (ARDEF) file to Y (e.g., yes), which may be configured to indicate to acquiring system 1208 that the PID and funding source (e.g., AFS) may change during transaction authorization. In some non-limiting embodiments or aspects, first issuing system 1206-1 (e.g., the issuing system that issued the debit account) may be configured to communicate at least one BIN or at least one range of BINs to transaction processing system 1201.

[0176] As shown in FIG. 12, in step 1252, the transaction processing system 1201 may be configured to communicate (eg, send) the ARDEF file to the acquiring system 1208.

[0177] As shown in FIG. 12, in step 1253, a cardholder may initiate a transaction using lead (e.g., debit) authentication information (e.g., presenting and / or communicating the lead authentication information to the merchant system 1204). The merchant system 1204 may generate an authentication request based on the lead authentication information and / or communicate the authentication request to the acquiring system 1204. The authentication request may also include an identifier for the merchant (e.g., a merchant ID and / or VMID).

[0178] 12, in step 1254, acquiring system 1204 may be configured to communicate the authentication request to transaction processing system 1201. For example, acquiring system 1208 may be configured to use the ARDEF file to determine that the authentication request should be routed to transaction processing system 1201.

[0179] As shown in FIG. 12 , in step 1255, the transaction processing system 1201 may be configured to determine (e.g., analyze) whether the transaction is eligible for dynamic processing (e.g., deferred processing such as BNPL processing), as described herein. If the transaction is not eligible, the transaction may be processed as a regular (e.g., debit) transaction. If the transaction is eligible, the transaction processing system 1201 may be configured to generate a modified authorization request. For example, the authorization request may be modified by entering an indicator in a dedicated field (e.g., field 62.25) that the transaction is eligible for dynamic processing and / or that the eligibility criteria have been met. Additionally or alternatively, the authorization request may be modified by entering a PID in a dedicated field (e.g., field 62.23). In some non-limiting embodiments or aspects, the transaction processing system 1202 may be configured to communicate the modified authorization request to the first issuing system 1206-1 (e.g., communicate the modified authorization request to the issuing system that issued the debit account).

[0180] 12, in step 1256, the first issuing system 1206-1 verifies that the transaction is eligible for processing as a dynamic transaction, as described herein. If so, in some non-limiting embodiments or aspects, the first issuing system 1206-1 may be configured to communicate a request (e.g., a modified authorization request, a further modified authorization request, and / or the like) to the second issuing system 1206-2 (e.g., an issuer associated with the loan / BNPL account). The second issuing system 1206-2 may be configured to determine whether the transaction is eligible for dynamic processing (e.g., based on rules customized for the user, as described herein).

[0181] As shown in FIG. 12 , in step 1257, the second issuing system 1206-2 may communicate a confirmation to the first issuing system 1206-1 indicating whether the transaction qualifies / will be processed as a dynamic transaction. If not, the transaction is processed as a regular (e.g., debit) transaction. If the transaction qualifies / will be processed as a dynamic transaction, the confirmation may include additional data regarding the funding source (e.g., PID, payment terms, and / or funding source account identifier). In this manner, the transaction may be dynamically switched from a debit transaction to a deferred (e.g., BNPL) transaction.

[0182] As shown in FIG. 12 , in step 1258, the first issuing system 1206-1 communicates an authorization response to the transaction service provider system. If the transaction does not qualify / is not processed as a dynamic transaction, the authorization response is a regular (e.g., debit) transaction authorization response. If the transaction qualifies / is processed as a dynamic transaction, the first issuing system 1206-1 may be configured to populate additional fields in the authorization response. For example, the first issuing system 1206-1 may be configured to populate field 62.24 based on a PID associated with the dynamic transaction, field 102 based on payment terms (e.g., field 102=FNO PAN), and / or field 104DS-5D based on a tag (e.g., tags 03, 06-08, and 17).

[0183] 12, in step 1259, transaction processing system 1201 may be configured to determine (e.g., check) that issuing system 1206 has provided the necessary data for dynamic processing (e.g., in the authorization response). If so, transaction processing system 1201 may be configured to process the transaction based on the second funding source (e.g., for eligible transactions).

[0184] As shown in FIG. 12 , in step 1260, the transaction processing system 1201 may be configured to send a modified authorization response to the acquiring system 1208, as described herein. For example, the transaction processing system 1201 may be configured to modify the authorization response by populating additional fields with data useful (e.g., required) for clearing and settlement based on a second funding source (e.g., ACI (field 62.1) = T, field 62.23 = S (purchase credit for loan / BNPL account), field 62.24 = 6DigitalAN, field 62.25 = B). In some non-limiting embodiments or aspects, the transaction processing system 1201 may be configured to calculate a Val code. In some non-limiting embodiments or aspects, the transaction processing system 1201 may be configured to modify the authorization response by dropping at least one field (e.g., field 104 DS5D). If the transaction is not eligible for dynamic processing, the transaction may be processed as a regular (e.g., debit) transaction.

[0185] As shown in FIG. 12, in step 1261, the acquiring system 1208 may be configured to communicate the (modified) authentication response to the merchant system 1204.

[0186] As shown in FIG. 12, in step 1262, the seller system 1204 may be configured to communicate a settlement message (eg, an end of day (EOD) capture message) to the acquiring system 1208.

[0187] As shown in FIG. 12, in step 1263, the acquiring system 1208 may be configured to communicate a settlement message to the transaction processing system 1201 based on the second funding source account.

[0188] 12, in steps 1264 and 1265, transaction processing system 1201 may be configured to communicate a clearing message to first issuing system 1206-1 and / or second issuing system 1206-2. For example, transaction processing system 1201 may be configured to perform a VAL code check and / or determine an IRF based on the second funding source account. In some non-limiting embodiments or aspects, transaction processing system 1201 may be configured to clear and / or settle the transaction based on the second funding source account.

[0189] Referring now to FIG. 13 , a schematic diagram of an illustrative example transaction flow 1300 in a system for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 13 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be automatically performed in response to the execution and / or completion of a previous step. As shown in FIG. 13 , example 1300 may include a payment device 1310, a merchant system 1304, an acquiring system 1308, a transaction processing system 1301, and an issuing system 1306. In certain non-limiting embodiments or aspects, the payment device 1310 may be the same as or similar to the consumer device 110. In certain non-limiting embodiments or aspects, the merchant system 1304 may be the same as or similar to the merchant system 104. In some non-limiting embodiments or aspects, the acquiring system 1308 may be the same as or similar to the acquiring system 108. In some non-limiting embodiments or aspects, the transaction processing system 1301 may be the same as or similar to the transaction processing system 101. In some non-limiting embodiments or aspects, the issuing system 1306 may be the same as or similar to the issuing system 106. The number and configuration of systems and / or devices shown in FIG. 13 are provided as examples. More or fewer systems and / or devices may be different and / or configured differently compared to those shown in FIG. 13.

[0190] As shown in FIG. 13 , in step 1321, after a user presents a payment device 1310 (e.g., a debit BIN or debit card) to a merchant system 1304 (e.g., its POS device / terminal), the merchant system 1304 may send an authorization request message to the acquirer 1308 as described herein. For example, the authorization request message may include transaction information (e.g., transaction amount, merchant ID, MCC), as well as an account identifier associated with the payment device 1310.

[0191] As shown in FIG. 13, in step 1322, the acquiring system 1308 may be configured to send the authentication request message (and / or data associated therewith) to the transaction processing system 1301.

[0192] 13, in step 1323, transaction processing system 1301 may be configured to determine (e.g., analyze) whether the transaction is eligible for dynamic processing (e.g., based on customized rules and / or product-specific plans) as described herein. For example, transaction processing system 1301 may be configured to identify at least one product-specific plan available for the transaction along with a corresponding funding source associated with that plan (e.g., at least one of a credit account, a prepaid account, a loan account, and / or the like). For example, one or more products may be funded by one or more different funding sources.

[0193] 13, in step 1324, the transaction processing system 1301 may be configured to indicate to the issuing system 1306 that the transaction is eligible for dynamic processing, as described herein. For example, the transaction processing system 1301 may be configured to communicate a revised authorization request associated with one or more available product plans and / or corresponding funding sources.

[0194] As shown in FIG. 13 , in step 1325, the issuing system 1306 may be configured to validate the dynamic transaction (e.g., validate that the transaction is eligible for dynamic processing, as described herein). If so, the issuing system 1306 may be configured to select a product plan and an associated funding source for the product plan (e.g., based on rules customized for the user), as described herein. The issuing system 1306 may be configured to communicate an authorization response to the transaction processing system 1301, as described herein. For example, the authorization response may include the selected product plan and / or indicate the selected product plan and / or the funding source for the selected product plan. In this manner, the transaction has been dynamically switched from a debit transaction to a funding account transaction.

[0195] In some non-limiting embodiments or aspects, the issuing system 1306 may be configured to communicate the selection of the funding source to the user (e.g., to the user's device), thus informing the user that the transaction initiated using the lead credentials is being processed using the selected funding source (and, if applicable, the product plan, e.g., installment plan terms and / or interest rate).

[0196] 13, in step 1326, transaction processing system 1301 may be configured to determine (e.g., check) that the information provided by issuing system 1306 includes data necessary for dynamic processing. If so, transaction processing system 1301 may be configured to process the transaction based on the selected funding source.

[0197] 13, in step 1327, the transaction processing system 1301 may be configured to send a modified authorization response to the acquiring system 1308, as described herein. For example, if the source of funds has changed based on dynamic processing, the modified authorization response may include any additional information required for clearing and / or settlement.

[0198] As shown in FIG. 13, in step 1328, if the transaction is not eligible for dynamic processing, the transaction may be configured to be processed as a normal transaction (e.g., using the debit or credit account presented to initiate the transaction or a default account, such as a default debit or credit account associated with the lead authentication information), as described herein.

[0199] Referring now to FIG. 14 , a schematic diagram of an exemplary implementation 1400 of a system for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. As shown in FIG. 14 , implementation 1400 may include an acquiring system 1408, a transaction processing system 1401, and an issuing system 1406. In certain non-limiting embodiments or aspects, acquiring system 1408 may be the same as or similar to acquiring system 108. In certain non-limiting embodiments or aspects, transaction processing system 1401 may be the same as or similar to transaction processing system 101. In certain non-limiting embodiments or aspects, issuing system 1406 may be the same as or similar to issuing system 106. The number and configuration of systems and / or devices shown in FIG. 14 are provided as examples. Compared to those shown in FIG. 14 , more or fewer systems and / or devices may be different and / or configured differently.

[0200] As shown in FIG. 14, the profile data may include data (e.g., stored in a database such as a card registry) associated with account identifiers and / or account information eligible for the multi-account access model. For example, the profile data may include status, product plan(s), account type (e.g., debit, credit, loan, BNPL, etc.), issuer discretionary data (IDD), any combination thereof, and / or the like. Participating PANS on file may include account identifiers and other relevant information such as BINs, PIDs, AFSs, and multi-account access (MAA) indicators (e.g., indicators that the PAN is eligible for dynamic processing).

[0201] The system tables may include configuration data for storing details of a commodity plan and / or a routing table for processing transactions in accordance with the commodity plan. For example, the ARDEF may be as described herein. The commodity plan may be as described herein. The commodity plan rule table may be associated with and / or based on customized rules as described herein. For example, the rule table may include rules associated with each commodity plan that are used to identify whether a transaction can be processed in accordance with one or more commodity plans.

[0202] Referring now to FIG. 15 , a schematic diagram of an illustrative example transaction flow 1500 in a system for multi-account access based on a single credential is shown, according to certain non-limiting embodiments or aspects. The steps shown in FIG. 15 are for illustrative purposes only. It will be understood that certain non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In certain non-limiting embodiments or aspects, a step may be automatically performed in response to the execution and / or completion of a previous step. As shown in FIG. 15 , example 1500 may include a payment device 1510-1, a consumer device 1510-2, a merchant system 1504, an acquiring system 1508, a transaction processing system 1501, a first issuing system 1506-1, and a second issuing system 1506-2. In certain non-limiting embodiments or aspects, payment device 1510-1 and / or consumer device 1510-2 may be the same as or similar to consumer device 110. In some non-limiting embodiments or aspects, the payment device 1510-1 and the consumer device 1510-2 may belong to the same user and / or may be the same device. In some non-limiting embodiments or aspects, the payment device 1510-1 may be separate from the consumer device 1510-2. In some non-limiting embodiments or aspects, the merchant system 1504 may be the same as or similar to the merchant system 104. In some non-limiting embodiments or aspects, the acquiring system 1508 may be the same as or similar to the acquiring system 108. In some non-limiting embodiments or aspects, the transaction processing system 1501 may be the same as or similar to the transaction processing system 101. In some non-limiting embodiments or aspects, the first issuing system 1506-1 and / or the second issuing system 1506-2 may be the same as or similar to the issuing system 106. The number and configuration of systems and / or devices shown in FIG. 15 are provided as examples.The systems and / or devices may be more or less different and / or configured differently compared to that shown in FIG.

[0203] 15, as described herein, in step 1521, after a user presents payment device 1510-1 to merchant system 1504 (e.g., its POS device / terminal), the merchant system 1504 may be configured to send an authentication request message to acquirer 1508. For example, the account identifier associated with payment device 1510-1 may be a payment token, as described herein.

[0204] As shown in FIG. 15, in step 1522, the acquiring system 1508 may be configured to determine (e.g., based on the payment token) to route the authentication request message to the transaction processing system 1501 as described in this disclosure.

[0205] As shown in FIG. 15, in step 1523, the acquiring system 1508 may be configured to send an authorization request message to the transaction processing system 1501 as described in this disclosure.

[0206] 15, in step 1524, transaction processing system 1501 may be configured to determine that the authentication request message includes a payment token. If so, transaction processing system 1524 and / or its token vault may be configured to detokenize the payment token as described herein. For example, a PAN corresponding to the payment token (e.g., a lead PAN) may be obtained (e.g., by transaction processing system 1501) from the token vault.

[0207] 15, at step 1525, the transaction processing system 1501 may be configured to determine whether the detokenized account identifier (e.g., PAN) and / or transaction is eligible for dynamic processing (e.g., MAA), as described herein. For example, as shown in FIG. 15, at step 1526, the transaction processing system 1501 may be configured to retrieve profile data, including product plans and associated rules, from a card registry of the transaction processing system 1501, as described herein.

[0208] As shown in Figure 15, in step 1527, the transaction processing system may be configured to determine whether the transaction meets eligibility requirements, as described herein. For example, as shown in Figure 15, in step 1528, the transaction processing system 1501 may be configured to communicate with a transaction control database (which may store data associated with customized rules and / or the like, e.g., as described herein).

[0209] As shown in Figure 15, in step 1528, transaction processing system 1501 may be configured to generate a modified authorization request as described herein. As shown in Figure 15, in step 1529, transaction processing system 1801 may be configured to send the modified authorization request (e.g., including and / or based on the eligible product plan) to first issuing system 1506-1. First issuing system 1506-1 may be configured to perform an eligibility check as described herein.

[0210] 15, in step 1530, if the first issuing system 1506-1 agrees that the transaction is suitable for one or more of the product plans, the first issuing system 1506-1 may be configured to make a selection (e.g., by selecting one of the product plans) and / or communicate an authorization response message to the transaction processing system. As shown in FIG. 15, in step 1531, the first issuing system 1506-1 may be configured to communicate a notification to the consumer device 1510-2, as described herein.

[0211] 15, in step 1532, the transaction processing system may be configured to receive an authorization response as described herein. For example, the authorization response message may include a lead PAN, a selected product plan, and / or required data (e.g., a funds source identifier, a funds PAN, and / or the like) as described herein.

[0212] As shown in FIG. 15 , in step 1533, the transaction processing system 1501 verifies the information received from the issuing system as described herein. For example, the transaction processing system 1501 may process the transaction using the funding PAN in accordance with the rules of the selected product plan. In some non-limiting embodiments or aspects, as shown in FIG. 15 , in step 1534, if the funding PAN is issued by the second issuing system 1506-2 (e.g., or is associated with a product plan managed by a second system of the same issuer), the transaction processing system 1501 may send a communication to the second issuing system 1506-2. For example, the communication may notify the second issuing system 1506-2 that the transaction has been approved and is being processed using the funding PAN.

[0213] As shown in Figure 15, at step 1534, transaction processing system 1501 may be configured to input at least one additional field of the authentication response as described herein. Additionally or alternatively, as shown in Figure 15, at step 1535, transaction processing system 1501 may be configured to generate a modified authentication response (e.g., based on input of the additional field(s) of the authentication response) as described herein.

[0214] 15, in step 1536, the transaction processing system 1501 may be configured to send a modified authorization response message to the acquiring system 1508, as described herein. For example, the modified authorization response message may include information necessary for the acquirer to later clear and / or settle the transaction.

[0215] In some non-limiting embodiments or aspects, in step 1528, the transaction processing system 1501 may obtain the funding PAN directly (e.g., from a transaction control database) rather than receiving the funding PAN from one or more issuing systems. For example, the funding PAN for one or more product plans may be stored in a database (e.g., a transaction control database). The transaction processing system 1501 may access the database to identify the funding PAN for a product plan selected from among the available product plans by the transaction processing system 1501 or by one or more issuing systems. For example, the one or more issuing systems may return the product plan selection to the transaction processing system 1501 without providing the transaction processing system 1501 with a funding PAN associated with the selected product, and the transaction processing system 1501 may then obtain the funding PAN from the database by querying the database of product plans selected by the one or more issuing systems.

[0216] In some non-limiting embodiments or aspects, if the first issuing system 1506-1 does not have sufficient information, the first issuing system 1506-1 may be configured to communicate (e.g., return) the funds PAN to the transaction processing system 1501 in steps 1530 and / or 1532 without providing an authentication response. In this manner, the transaction processing system 1501 may be configured to subsequently contact the second issuing system 15606-2 with a (modified) authentication request using the funds PAN.

[0217] Referring now to FIG. 16 , a schematic diagram of an example implementation 1600 of a clearing / settlement flow within a system for multi-account access based on a single credential is shown, according to some non-limiting embodiments or aspects. The steps shown in FIG. 16 are for illustrative purposes only. It will be understood that some non-limiting embodiments or aspects may use more, fewer, different, and / or differently ordered steps. In some non-limiting embodiments or aspects, a step may be automatically performed in response to the execution and / or completion of a previous step. As shown in FIG. 16 , example 1600 may include a first consumer device 1610-1, a second consumer device 1610-2, a merchant system 1604, an acquiring system 1608, a transaction processing system 1601, a first issuing system 1606-1, and a second issuing system 1606-2. In some non-limiting embodiments or aspects, the first consumer device 1610-1 and / or the second consumer device 1610-2 may be the same as or similar to the consumer device 110. In some non-limiting embodiments or aspects, the consumer device 1610-1 and the second consumer device 1610-2 may be associated with the same user and / or may be the same device. In some non-limiting embodiments or aspects, the first consumer device 1610-1 may be separate from the second consumer device 1610-2. In some non-limiting embodiments or aspects, the seller system 1604 may be the same as or similar to the seller system 104. In some non-limiting embodiments or aspects, the acquiring system 1608 may be the same as or similar to the acquiring system 108. In some non-limiting embodiments or aspects, the transaction processing system 1601 may be the same as or similar to the transaction processing system 101. In some non-limiting embodiments or aspects, the first issuing system 1606-1 and / or the second issuing system 1606-2 may be the same as or similar to the issuing system 106. The number and configuration of systems and / or devices shown in Figure 16 are provided as an example.The systems and / or devices may be more or less different and / or configured differently compared to that shown in FIG.

[0218] As shown in FIG. 16, in step 1621, the seller system 1604 may be configured to communicate at least one settlement message (e.g., a capture message) to the acquiring system 1608 as described herein.

[0219] As shown in FIG. 16 , in step 1622, the acquiring system 1608 may communicate at least one clearing message (e.g., including at least one trade clearing (TC) record) to the transaction processing system 1601, as described herein. For example, the clearing message (e.g., TC record) from the acquiring system 1608 may include and / or be based on lead authentication information submitted by a user to the seller system 1604 to initiate a transaction (here, there may be multiple clearing messages (e.g., TC records), each initiating a respective transaction, etc.). In some non-limiting embodiments or aspects, the clearing message (e.g., TC record) may be based on the ARDEF, the MAA indicator, and / or clearing logic. Additionally or alternatively, the clearing message (e.g., TC record) may be based on IRF request logic.

[0220] As shown in FIG. 16, in step 1623, the trade processing system 1601 may edit (e.g., modify) a clearing message (e.g., TC record) (where there may be multiple clearing messages (e.g., TC records), etc.) based on the dynamic processing of the trade, as described herein. For example, the trade processing system 1601 may be configured to modify and / or populate fields in the clearing message (e.g., TC record) based on the MAA indicator and the secondary funding source used for each dynamic trade (e.g., MAA trade).

[0221] 16, in step 1624, transaction processing system 1601 may be configured to perform clearing of the one or more transactions. For example, transaction processing system 1601 may be configured to clear the one or more transactions (e.g., look up the PAN associated with each token, convert between currencies, and check the CRB data, respectively) using at least one of a token mapping database (e.g., a token vault), a currency transaction database, a card recovery bulletin (CRB) database, any combination thereof, and / or the like.

[0222] 16, in step 1625, transaction processing system 1601 may be configured to evaluate one or more transactions. For example, transaction processing system 1601 may be configured to calculate an IRF for each transaction. For each dynamic transaction (e.g., an MAA transaction), transaction processing system 1601 may be configured to calculate an IRF based on a secondary funding source, as described herein.

[0223] 16, in step 1626, the transaction processing system 1601 may be configured to generate at least one settlement message (e.g., based on the TC record) to at least one of the first issuing system 1606-1 and / or the second issuing system 1606-2. For example, if the transaction was not a dynamic transaction (e.g., not eligible for dynamic processing), a settlement message for the transaction may be generated to the first issuing system 1606-1 (e.g., associated with the authentication information presented to initiate the transaction). Additionally or alternatively, if the transaction was a dynamic transaction (e.g., eligible for dynamic processing), a settlement message for the transaction may be generated to the second issuing system 1606-2 (e.g., associated with an identifier of the second funding source selected for the transaction).

[0224] As shown in Figure 16, in step 1627, the transaction processing system 1601 may be configured to communicate at least one settlement message to at least one of the first issuing system 1606-1 and / or the second issuing system 1606-2. For example, if the transaction was not a dynamic transaction (e.g., not eligible for dynamic processing), the settlement message for the transaction may be communicated to the first issuing system 1606-1 (e.g., associated with the authentication information presented to initiate the transaction). Additionally or alternatively, if the transaction was a dynamic transaction (e.g., eligible for dynamic processing), the settlement message for the transaction may be communicated to the second issuing system 1606-2 (e.g., associated with the identifier of the second funding source selected for the transaction).

[0225] As shown in FIG. 16, in step 1628, the first issuing system 1506-1 may be configured to communicate the notification to the first consumer device 1510-1 and / or the second issuing system 1506-1 may be configured to communicate the notification to the second consumer device 1510-2, as described herein.

[0226] As shown in FIG. 16, in step 1629, transaction processing system 1601 may be configured to perform and / or determine fee reporting (e.g., based on valuation and / or IRF fees) as described in this disclosure.

[0227] As shown in FIG. 16, in step 1630, transaction processing system 1601 may be configured to process returns (e.g., transactions indicating that the item has been returned to the merchant and / or the like).

[0228] In some non-limiting embodiments or aspects, the disclosed subject matter allows access to multiple funding sources (e.g., funding accounts) using a single credential (e.g., using a loan account to fund an installment transaction). Additionally or alternatively, a user may initiate a transaction with a first funding source associated with a credential and then switch to a second funding source associated with the same credential (or different credential) to process the transaction. An issuer and / or cardholder may use a single credential to access desired accounts authorized by the issuer. Funding sources may include one or more of a debit account, a credit account, a line of credit account, loyalty points, a consumer loan account, a BNPL account, a commercial loan account, and / or the like.

[0229] In some non-limiting embodiments or aspects, the disclosed subject matter enables initiating a transaction with a merchant using authentication information. The authentication information may be associated with a first account (e.g., a debit account). However, a user may have predetermined (e.g., customized) rules associated with the authentication information. The predetermined (e.g., customized) rules may indicate a requirement to process transactions over a threshold amount or a requirement to process transactions with a particular merchant using a loan account. In this manner, after initiating a transaction with the first account, a transaction processing system (e.g., of a transaction service provider entity) can verify that the transaction matches (e.g., triggers) a predetermined rule and may switch the source account to a second account (e.g., a loan account). Thus, the consumer debit transaction may be converted into a commercial credit transaction.

[0230] In some non-limiting embodiments or aspects, a transaction processing system may be configured to receive a transaction authorization request including at least authentication information, a transaction amount, and a merchant identifier. The transaction processing network may be configured to analyze the transaction authorization request and identify one or more predetermined rules that apply to the transaction. For example, some of the predetermined rules may be set by the account holder and / or some of the predetermined rules may be set by the transaction processing network. The authentication information may be associated with multiple funding sources of different types (e.g., a debit-type funding source, a credit-type funding source, and a loan-type funding source). For example, upon analyzing the transaction authorization request, the transaction processing system may be configured to determine that the transaction should be processed as a BNPL transaction. The transaction processing system may be configured to communicate with the issuer of the loan account to determine whether the BNPL transaction is funded by a commercial loan source or a consumer loan source.

[0231] In some non-limiting embodiments or aspects, the authentication information may not be associated with a funding source. The authentication information may be configured to identify a user (e.g., an account holder). The user may have one or more accounts registered with the transaction processing server. When the transaction processing server receives a transaction authorization request, the transaction processing server may be configured to identify available funding sources based on transaction information such as the transaction amount and / or merchant identity. The transaction processing system may be configured to notify the issuer of available funding sources, and the issuer may be configured to select an appropriate funding source for the transaction. Thus, a transaction may be initiated by presenting lead authentication information, and the transaction may be processed (e.g., funded) using funds authentication information, a funding source different from the lead authentication information.

[0232] In some non-limiting embodiments or aspects, the transaction processing system may be configured to identify and assign BINs, activate ALPs or create modern credential indicators (e.g., lead credential indicators, MAA indicators, and / or the like), configure and verify issuer-defined eligibility criteria and transaction controls on the credential, as needed, and / or define a complete set of program identifiers (e.g., for one or more funding accounts).

[0233] In some non-limiting embodiments or aspects, an issuer may define transaction eligibility criteria and inform the transaction processing system of authentication information (e.g., product ID, program ID, and configuration information (e.g., from a credential registry), funding information associated with each program, and / or secondary funding sources, etc.). In some non-limiting embodiments or aspects, an issuer or user / account holder may set (e.g., customize) rules governing transaction processing logic. For example, the rules may include bundling PAN, ATM, PoS, Ecom routing logic (default PAN), transaction amount, transaction channel, MCC, individual merchant-based rules (e.g., transactions > $100 or jewelry transactions routed to a credit account), any combination thereof, and / or the like.

[0234] In some non-limiting embodiments or aspects, one or more acquiring systems may be configured to receive the ARDEF file and prepare to transmit a merchant identifier (e.g., merchant ID, VMID, and / or the like) and / or may be configured to be capable of processing with different funding sources.

[0235] In some non-limiting embodiments or aspects, the merchant may be given the option or configuration to give the customer the choice to opt in or opt out.

[0236] While embodiments have been described in detail for purposes of illustration, it should be understood that such details are for that purpose only, 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 within the spirit and scope of the appended claims. For example, it will be understood that the 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

1. 1. A system comprising: at least one processor, receiving, from an acquiring system, an authentication request message associated with the transaction, the authentication request message including a first account identifier; determining that at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing; identifying at least one processing option available for the dynamic processing of the transaction; sending a modified authentication request message to the issuing system indicating the at least one processing option; receiving an authentication response message from the issuing system, the authentication response message including an authentication indicator and an identifier of a funding source corresponding to a selected processing option of the at least one processing option; and sending a modified authentication response message to the acquiring system based on the authentication indicator and the identifier of the source of funds.

2. The system of claim 1 , wherein the first account identifier comprises lead authentication information.

3. The system of claim 1 , wherein the lead authentication information identifies at least one of an account holder, a default payment account, or any combination thereof.

4. The system of claim 1 , wherein the dynamic processing comprises a delayed processing.

5. The system of claim 1 , wherein the identifier of the funding source includes a second account identifier.

6. The system of claim 1 , wherein the identifier of the source of funds comprises at least one of a product identifier (PID), an account source of funds (AFS), or any combination thereof.

7. The system of claim 1 , wherein the at least one processing option includes at least two processing options associated with the same funding source.

8. The system of claim 1 , wherein the at least one processing option includes at least two processing options, each associated with a different funding source.

9. the at least one processor, before transmitting the modified authentication response message: processing the transaction based on the identifier of the funding source and the selected processing option; 10. The system of claim 1, further configured to: generate the modified authentication response message based on processing of the transaction.

10. The issuing system determining the selected processing option based on customized rules associated with an account holder associated with the first account identifier; determining the funding sources available for the selected processing options; The system of claim 1 , configured to generate the authentication response message including the authentication indicator and the identifier of the funding source compatible with the selected processing option.

11. The system of claim 1 , wherein the issuing system is configured to receive at least one input from the account holder associated with the customized rule.

12. 1. A computer-implemented method comprising: receiving, by at least one processor, from an acquiring system, an authentication request message associated with the transaction, the authentication request message including a first account identifier; determining, by at least one processor, that at least one of the transaction, the first account identifier, or any combination thereof, is eligible for dynamic processing; identifying, by at least one processor, at least one processing option available for said dynamic processing of said transaction; sending, by the at least one processor, a modified authentication request message indicating the at least one processing option to the issuing system; receiving, by at least one processor, from the issuing system an authentication response message including an authentication indicator and an identifier of a funding source corresponding to a selected processing option of the at least one processing option; and transmitting, by at least one processor, a modified authentication response message to the acquiring system based on the authentication indicator and the identifier of the funding source.

13. 13. The method of claim 12, wherein the first account identifier includes lead authentication information, the lead authentication information identifying at least one of an account holder, a default payment account, or any combination thereof.

14. The method of claim 12 , wherein the dynamic processing comprises a delayed processing.

15. The method of claim 12 , wherein the identifier of the funding source includes a second account identifier.

16. 13. The method of claim 12, wherein the identifier of the source of funds comprises at least one of a product identifier (PID), an account source of funds (AFS), or any combination thereof.

17. The at least one processing option is At least two processing options associated with the same funding source; At least two processing options, each associated with a different funding source; or The method of claim 12 including at least one of any combination thereof.

18. before transmitting the modified authentication response message; processing, by at least one processor, the transaction based on the identifier of the funding source and the selected processing option before transmitting the modified authorization response message; 13. The method of claim 12, further comprising generating, by at least one processor, the modified authorization response message based on processing of the transaction.

19. receiving, by the issuing system, at least one input associated with a customized rule from an account holder associated with the first account identifier; determining, by the issuing system, the selected processing option based on the customized rules associated with the account holder; determining, by the issuing system, the funding sources available for the selected processing option; generating, by the issuing system, the authentication response message including the authentication indicator and the identifier of the funding source compatible with the selected processing option; 13. The method of claim 12, further comprising:

20. 1. A computer program product comprising at least one non-transitory computer-readable medium containing program instructions, the program instructions, when executed by at least one processor, causing the at least one processor to: receiving, from an acquiring system, an authentication request message associated with the transaction, the authentication request message including a first account identifier; determining that at least one of the transaction, the first account identifier, or any combination thereof is eligible for dynamic processing; identifying at least one processing option available for the dynamic processing of the transaction; sending a modified authentication request message to the issuing system indicating the at least one processing option; receiving an authentication response message from the issuing system, the authentication response message including an authentication indicator and an identifier of a funding source corresponding to a selected processing option of the at least one processing option; and sending a modified authentication response message to the acquiring system based on the authentication indicator and the identifier of the funding source.

21. 20. A computer program product comprising at least one non-transitory computer readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to perform the method of any one of claims 12 to 19.

Images