Systems, methods, and computer program products for flexible transactional message routing

Abstract

Systems, methods, and computer program products are provided for flexible transaction message routing. An exemplary method includes receiving an authorization request message associated with a payment transaction. The authorization request message includes a first account identifier associated with a user. A second account identifier is determined from a plurality of account identifiers based on at least one rule associated with the first account identifier. A modified authorization request message for the payment transaction is generated. The modified authorization request message includes the second account identifier. The modified authorization request message is transmitted to an issuer system associated with the second account identifier. A transaction history record based on the payment transaction and the second account identifier is stored.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 330,987, filed April 14, 2022, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure relates generally to transactional message routing and, in certain non-limiting embodiments or aspects, to systems, methods, and computer program products for flexible transactional message routing. [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 retailer 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 the user 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 such, the user may be required to carry multiple different payment instruments and / or to memorize different account identifiers. Furthermore, these electronic payment processing systems do not allow the user to substitute a different account and / or a different account type (e.g., a debit card account, a credit card account, a prepaid card account, 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 creates difficulties in situations where the settlement process of a payment transaction is rejected or prevented for unknown reasons. Summary of the Invention [Problem to be solved by the invention]

[0005] It is therefore an object of the present disclosure to provide a system, method, and computer program product for flexible transactional message routing that overcomes some or all of the deficiencies identified above. [Means for solving the problem]

[0006] According to a non-limiting embodiment or aspect, a computer-implemented method for flexible transaction message routing is provided. An exemplary method may include receiving, at at least one processor, an authentication request message associated with a payment transaction. The authentication request message may include a first account identifier associated with a user. The method may include determining, at the at least one processor, a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier. The method may include generating, at the at least one processor, a modified authentication request message for the payment transaction. The modified authentication request message may include the second account identifier. The method may include transmitting, at the at least one processor, the modified authentication request message to an issuer system associated with the second account identifier. The method may include storing, at the at least one processor, a transaction history record based on the payment transaction and the second account identifier.

[0007] In some non-limiting embodiments or aspects, the method may further include receiving, at the at least one processor, rule data associated with the at least one rule. The rule data may include a threshold. The method may include determining, at the at least one processor, whether a transaction amount of the payment transaction satisfies the threshold. Determining the second account identifier may include selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

[0008] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on the rule data received from the user and a fallback rule. Determining the second account identifier may include determining, with the at least one processor, that the first rule is not applicable to the payment transaction associated with the authentication request message, and determining, with the at least one processor, in response to determining that the first rule is not applicable, a second account identifier from the plurality of account identifiers based on the fallback rule.

[0009] In some non-limiting embodiments or aspects, the method may further include receiving, at the at least one processor, a settlement request message associated with the payment transaction. The settlement request message may include a first account identifier. The method may include identifying, at the at least one processor, a transaction history record based on the payment transaction. The method may include generating, at the at least one processor, a modified settlement request message based on the identification of the transaction history record. The modified settlement request message may include a second account identifier. The method may include transmitting, at the at least one processor, the modified settlement request message to an issuer system associated with the second account identifier.

[0010] In some non-limiting embodiments or aspects, the method may further include receiving, at the at least one processor, a settlement request message associated with the second payment transaction. The settlement request message may include the first account identifier. The method may include determining, at the at least one processor, that a second transaction history associated with the second payment transaction is not stored. The method may include applying, at the at least one processor, a fallback settlement rule in response to determining that the second transaction history is not stored.

[0011] In some non-limiting embodiments or aspects, the method may further include receiving, at the at least one processor, rules data associated with the at least one rule from the issuer system.

[0012] In some non-limiting embodiments or aspects, the first account identifier may include a lead account identifier associated with a physical payment device associated with the user. The multiple account identifiers may include multiple virtual account identifiers associated with the user. The second account identifier may include a selected virtual account identifier. Determining the second account identifier may include selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0013] In some non-limiting embodiments or aspects, the lead account identifier may include a debit account identifier. The plurality of virtual account identifiers may include a virtual credit account identifier and a virtual prepaid account identifier.

[0014] According to a non-limiting embodiment or aspect, a system for flexible transaction message routing is provided. An exemplary system may include at least one processor and at least one non-transitory computer-readable medium storing instructions. When executed by the at least one processor, the instructions may cause the at least one processor to receive an authentication request message associated with a payment transaction. The authentication request message may include a first account identifier associated with a user. When executed by the at least one processor, the instructions may cause the at least one processor to determine a second account identifier from a plurality of account identifiers based on at least one rule associated with the first account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to generate a modified authentication request message for the payment transaction. The modified authentication request message may include the second account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to send the modified authentication request message to an issuer system associated with the second account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to store a transaction history record based on the payment transaction and the second account identifier.

[0015] In some non-limiting embodiments or aspects, the instructions, when executed by the at least one processor, may further cause the at least one processor to receive rule data associated with the at least one rule. The rule data may include a threshold and / or may determine whether a transaction amount of the payment transaction satisfies the threshold. Determining the second account identifier may include selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

[0016] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on the rule data received from the user and a fallback rule, and determining a second account identifier may include determining that the first rule is not applicable to the payment transaction associated with the authentication request message and / or determining a second account identifier from the plurality of account identifiers based on the fallback rule in response to determining that the first rule is not applicable.

[0017] In some non-limiting embodiments or aspects, the instructions, when executed by the at least one processor, may further cause the at least one processor to receive a settlement request message associated with the payment transaction. The settlement request message may include a first account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to identify a transaction history record based on the payment transaction. When executed by the at least one processor, the instructions may cause the at least one processor to generate a modified settlement request message based on the identification of the transaction history record. The modified settlement request message may include a second account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to transmit the modified settlement request message to an issuer system associated with the second account identifier.

[0018] In some non-limiting embodiments or aspects, the instructions, when executed by the at least one processor, may further cause the at least one processor to receive a settlement request message associated with a second payment transaction. The settlement request message may include the first account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to determine that a second transaction history associated with the second payment transaction is not stored. When executed by the at least one processor, the instructions may cause the at least one processor to apply a fallback settlement rule in response to determining that the second transaction history is not stored.

[0019] In some non-limiting embodiments or aspects, the instructions, when executed by at least one processor, may cause the at least one processor to receive rule data associated with at least one rule from an issuer system.

[0020] In some non-limiting embodiments or aspects, the first account identifier may include a lead account identifier associated with a physical payment device associated with the user. The multiple account identifiers may include multiple virtual account identifiers associated with the user. The second account identifier may include a selected virtual account identifier. Determining the second account identifier may include selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0021] In some non-limiting embodiments or aspects, the lead account identifier may include a debit account identifier. The plurality of virtual account identifiers may include a virtual credit account identifier and a virtual prepaid account identifier.

[0022] According to a non-limiting embodiment or aspect, a computer program product for flexible transaction message routing 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 receive an authentication request message associated with a payment transaction. The authentication request message may include a first account identifier associated with a user. When executed by the at least one processor, the instructions may cause the at least one processor to determine a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to generate a modified authentication request message for the payment transaction. The modified authentication request message may include the second account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to send the modified authentication request message to an issuer system associated with the second account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to store a transaction history record based on the payment transaction and the second account identifier.

[0023] In some non-limiting embodiments or aspects, the instructions, when executed by the at least one processor, may further cause the at least one processor to receive rule data associated with the at least one rule. The rule data may include a threshold and / or may determine whether a transaction amount of the payment transaction satisfies the threshold. Determining the second account identifier may include selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

[0024] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on the rule data received from the user and a fallback rule, and determining a second account identifier may include determining that the first rule is not applicable to the payment transaction associated with the authentication request message and / or determining a second account identifier from the plurality of account identifiers based on the fallback rule in response to determining that the first rule is not applicable.

[0025] In some non-limiting embodiments or aspects, the instructions, when executed by the at least one processor, may further cause the at least one processor to receive a settlement request message associated with the payment transaction. The settlement request message may include a first account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to identify a transaction history record based on the payment transaction. When executed by the at least one processor, the instructions may cause the at least one processor to generate a modified settlement request message based on the identification of the transaction history record. The modified settlement request message may include a second account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to transmit the modified settlement request message to an issuer system associated with the second account identifier.

[0026] In some non-limiting embodiments or aspects, the instructions, when executed by the at least one processor, may further cause the at least one processor to receive a settlement request message associated with a second payment transaction. The settlement request message may include the first account identifier. When executed by the at least one processor, the instructions may cause the at least one processor to determine that a second transaction history associated with the second payment transaction is not stored. When executed by the at least one processor, the instructions may cause the at least one processor to apply a fallback settlement rule in response to determining that the second transaction history is not stored.

[0027] In some non-limiting embodiments or aspects, the instructions, when executed by at least one processor, may cause the at least one processor to receive rule data associated with at least one rule from an issuer system.

[0028] In some non-limiting embodiments or aspects, the first account identifier may include a lead account identifier associated with a physical payment device associated with the user. The multiple account identifiers may include multiple virtual account identifiers associated with the user. The second account identifier may include a selected virtual account identifier. Determining the second account identifier may include selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0029] In some non-limiting embodiments or aspects, the lead account identifier may include a debit account identifier. The plurality of virtual account identifiers may include a virtual credit account identifier and a virtual prepaid account identifier.

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

[0031] Clause 1 1. A computer-implemented method comprising: receiving, at at least one processor, an authentication request message associated with the payment transaction, the authentication request message including a first account identifier associated with a user; determining, at the at least one processor, a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier; generating, at the at least one processor, a modified authentication request message for the payment transaction, the modified authentication request message including the second account identifier; sending, at the at least one processor, the modified authentication request message to an issuer system associated with the second account identifier; and storing, at the at least one processor, a transaction history record based on the payment transaction and the second account identifier.

[0032] Clause 2 2. The method of claim 1, further comprising: receiving, at at least one processor, rule data associated with at least one rule, the rule data including a threshold; and determining, at the at least one processor, whether a transaction amount of the payment transaction satisfies the threshold; and determining a second account identifier comprises selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

[0033] Clause 3 3. The method of claim 1 or 2, wherein the at least one rule includes a first rule based on rule data received from the user and a fallback rule, and determining the second account identifier includes determining, with the at least one processor, that the first rule is not applicable to the payment transaction associated with the authentication request message, and in response to determining that the first rule is not applicable, determining, with the at least one processor, the second account identifier from the plurality of account identifiers based on the fallback rule.

[0034] Clause 4 The method of any one of clauses 1-3, further comprising: receiving, at at least one processor, a payment request message associated with the payment transaction, where the payment request message includes a first account identifier; identifying, at the at least one processor, a transaction history record based on the payment transaction; generating, at the at least one processor, a modified payment request message based on the identification of the transaction history record, where the modified payment request message includes a second account identifier; and transmitting, at the at least one processor, the modified payment request message to an issuer system associated with the second account identifier.

[0035] Clause 5 The method of any one of clauses 1-4, further comprising receiving, at at least one processor, a payment request message associated with the second payment transaction, where the payment request message includes the first account identifier; determining, at the at least one processor, not to store a second transaction history associated with the second payment transaction; and in response to determining that the second transaction history is not stored, applying, at the at least one processor, a fallback payment rule.

[0036] Clause 6 6. The method of any one of clauses 1-5, further comprising receiving, at the at least one processor, rules data associated with the at least one rule from the issuer system.

[0037] Clause 7 7. The method of any one of clauses 1-6, wherein the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, and the second account identifier includes a selected virtual account identifier, and determining the second account identifier includes selecting the selected virtual account identifier from the plurality of virtual account identifiers based on at least one rule.

[0038] Clause 8 The method of any one of clauses 1-7, wherein the lead account identifier includes a debit account identifier and the plurality of virtual account identifiers includes a virtual credit account identifier and a virtual prepaid account identifier.

[0039] Clause 9 1. A system comprising: at least one processor; and at least one non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the at least one processor to: receive an authentication request message associated with a payment transaction, the authentication request message including a first account identifier associated with a user; determine a second account identifier from a plurality of account identifiers based on at least one rule associated with the first account identifier; generate a modified authentication request message for the payment transaction, the modified authentication request message including the second account identifier; send the modified authentication request message to an issuer system associated with the second account identifier; and store a transaction history record based on the payment transaction and the second account identifier.

[0040] Clause 10 The system of clause 9, wherein the instructions, when executed by at least one processor, further cause the at least one processor to receive rule data associated with at least one rule, where the rule data includes a threshold, and determine whether a transaction amount of the payment transaction satisfies the threshold, and determining a second account identifier includes selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

[0041] Clause 11 The system of clause 9 or clause 10, wherein the at least one rule includes a first rule based on rule data received from the user and a fallback rule, and determining the second account identifier includes determining that the first rule is not applicable to the payment transaction associated with the authentication request message, and in response to determining that the first rule is not applicable, determining the second account identifier from the plurality of account identifiers based on the fallback rule.

[0042] Clause 12 The system of any one of clauses 9-11, wherein the instructions, when executed by at least one processor, further cause the at least one processor to: receive a settlement request message associated with the payment transaction, where the settlement request message includes a first account identifier; identify a transaction history record based on the payment transaction; generate a modified settlement request message based on the identification of the transaction history record, where the modified settlement request message includes a second account identifier; and send the modified settlement request message to an issuer system associated with the second account identifier.

[0043] Clause 13 The system of any one of clauses 9-12, wherein the instructions, when executed by at least one processor, further cause the at least one processor to: receive a payment request message associated with a second payment transaction, where the payment request message includes a first account identifier; determine that a second transaction history associated with the second payment transaction is not stored; and in response to determining that the second transaction history is not stored, apply a fallback payment rule.

[0044] Clause 14 The system of any one of clauses 9-13, wherein the instructions, when executed by at least one processor, further cause the at least one processor to receive rule data associated with at least one rule from the issuer system.

[0045] Clause 15 The system of any one of clauses 9-14, wherein the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, and the second account identifier includes a selected virtual account identifier, and determining the second account identifier includes selecting the selected virtual account identifier from the plurality of virtual account identifiers based on at least one rule.

[0046] Clause 16 The system of any one of clauses 9-15, wherein the lead account identifier includes a debit account identifier and the plurality of virtual account identifiers includes a virtual credit account identifier and a virtual prepaid account identifier.

[0047] Clause 17 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 an authentication request message associated with the payment transaction, the authentication request message including a first account identifier associated with the user; determine a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier; generate a modified authentication request message for the payment transaction, the modified authentication request message including the second account identifier; send the modified authentication request message to an issuer system associated with the second account identifier; and store a transaction history record based on the payment transaction and the second account identifier.

[0048] Clause 18 18. The computer program product of clause 17, wherein the instructions, when executed by at least one processor, further cause the at least one processor to receive rule data associated with at least one rule, where the rule data includes a threshold, and determine whether a transaction amount of the payment transaction satisfies the threshold, and determining a second account identifier includes selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

[0049] Clause 19 19. The computer program product of clause 17 or clause 18, wherein the at least one rule includes a first rule based on rule data received from the user and a fallback rule, and determining the second account identifier includes determining that the first rule is not applicable to the payment transaction associated with the authentication request message, and in response to determining that the first rule is not applicable, determining the second account identifier from the plurality of account identifiers based on the fallback rule.

[0050] Clause 20 20. The computer program product of any one of clauses 17-19, wherein the instructions, when executed by at least one processor, further cause the at least one processor to: receive a settlement request message associated with the payment transaction, where the settlement request message includes a first account identifier; identify a transaction history record based on the payment transaction; generate a modified settlement request message based on the identification of the transaction history record, where the modified settlement request message includes a second account identifier; and send the modified settlement request message to an issuer system associated with the second account identifier.

[0051] Clause 21 21. The computer program product of any one of clauses 17-20, wherein the instructions, when executed by at least one processor, cause the at least one processor to: receive a payment request message associated with a second payment transaction, where the payment request message includes a first account identifier; determine that a second transaction history associated with the second payment transaction is not stored; and in response to determining that the second transaction history is not stored, apply a fallback payment rule.

[0052] Clause 22 The computer program product of any one of clauses 17-21, wherein the instructions, when executed by at least one processor, further cause the at least one processor to receive rule data associated with the at least one rule from the issuer system.

[0053] Clause 23 23. The computer program product of any one of clauses 17-22, wherein the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, and the second account identifier includes a selected virtual account identifier, and determining the second account identifier includes selecting the selected virtual account identifier from the plurality of virtual account identifiers based on at least one rule.

[0054] Clause 24 24. The computer program product of any one of clauses 17-23, wherein the lead account identifier includes a debit account identifier and the plurality of virtual account identifiers includes a virtual credit account identifier and a virtual prepaid account identifier.

[0055] These and other characteristics and features of the present disclosure, as well as its 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 hereof, 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 and are not intended as a definition of the limits of the disclosed subject matter. [Brief description of the drawings]

[0056] Further advantages and details are explained in more detail below with reference to non-limiting exemplary embodiments illustrated in the accompanying schematic drawings. [Figure 1] FIG. 1 is a schematic diagram of a system for flexible transactional message routing according to some non-limiting embodiments or aspects. [Diagram 2] FIG. 2 is a flow diagram of a methodology for flexible transactional message routing according to some non-limiting embodiments or aspects. [Diagram 3]FIG. 3 is a diagram of an example environment in which the methods, systems, and / or computer program products described herein may be implemented according to some non-limiting embodiments or aspects. [Figure 4] FIG. 4 is a schematic diagram of example components of one or more devices of FIGS. 1 and / or 3 according to some non-limiting embodiments or aspects. [Figure 5A] FIG. 5A is a schematic diagram of an implementation of a system and method for flexible transactional message routing, according to some non-limiting embodiments or aspects. [Figure 5B] FIG. 5B is a schematic diagram of an implementation of a system and method for flexible transactional message routing, according to some non-limiting embodiments or aspects. [Figure 6A] FIG. 6A is a schematic diagram of an implementation of a system and method for flexible transactional message routing, according to some non-limiting embodiments or aspects. [Figure 6B] FIG. 6B is a schematic diagram of an implementation of a system and method for flexible transactional message routing, according to some non-limiting embodiments or aspects. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0057] Hereinafter, for purposes of explanation, the terms "end", "top", "bottom", "right", "left", "vertical", "horizontal", "top", "bottom", "lateral", "vertical", and their derivatives refer to the present embodiment as oriented in the drawings. However, it is to be understood that the present embodiment may assume various alternative variations and sequences of steps unless expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the disclosed subject matter. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.

[0058] No aspect, component, element, structure, act, step, function, instruction, and / or the like used herein should be construed as critical or essential unless expressly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more" and "at least one." Additionally, as used herein, 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." When only one item is intended, the term "a" or similar language is used. Also, as used herein, the terms "has," "have," "having," or similar terms are intended to be open-ended terms. Additionally, the phrase "based on" is intended to mean "based at least in part on" unless expressly stated otherwise.

[0059] As used herein, the term "acquirer institution" may refer to an entity licensed and / or approved by a transaction service provider to initiate transactions (e.g., payment transactions) using a payment device 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 herein, the term "acquirer system" may also 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.

[0060] As used herein, the term "account identifier" may include one or more primary account numbers, PANs, tokens, or other identifiers associated with a customer account. The term "token" may refer to an identifier used as a substitute or replacement 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 may 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.

[0061] As used herein, the term "communication" may refer to receipt, reception, transmission, transfer, provision, and / or the like of data (e.g., information, signals, messages, instructions, commands, and / or the like). A unit (e.g., a device, a system, or a component of a device or system, combinations thereof, and / or the like) communicating with another unit means that the one unit can directly or indirectly receive information from the other unit and / or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) having a wired and / or wireless nature. Additionally, two units may communicate with each other even though the information transmitted may be modified, processed, relayed, and / or routed between the first and second units. For example, a first unit may communicate with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit can communicate with a second unit if at least one intermediate unit processes information received from the first unit and communicates the processed information to the second unit.

[0062] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. A computing device may, in some embodiments, 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 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 a non-mobile computer.

[0063] 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 that executes 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 issuer bank may be an electronic wallet provider.

[0064] As used herein, the term "issuing institution" may refer to one or more entities, such as a bank, that provide an account to a customer for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuing institution may provide an account identifier, such as a PAN, to a customer 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 "issuer system" may also refer to one or more computing devices operated by or on behalf of an issuing institution, such as a server computer running one or more software applications. For example, an issuer system may include one or more authentication servers for authenticating transactions.

[0065] As used herein, the term "retailer" may refer to an individual or entity that provides goods and / or services, or access to goods and / or services, to customers based on a transaction, such as a payment transaction. The term "retailer" or "retailer system" may also refer to one or more computer systems operated by or on behalf of a retailer, such as a server computer running one or more software applications. As used herein, a "point of sale (POS) system" may refer to one or more computers and / or peripheral devices used by a retailer to engage in payment transactions with customers, including one or more card readers, near field communication (NFC) receivers, RFID receivers, and / or other contactless transceivers or receivers, contact receivers, payment terminals, computers, servers, input devices, and / or other similar devices that can be used to initiate a payment transaction.

[0066] As used herein, the term "payment device" may refer to a payment card (e.g., a credit card or debit card), a gift card, a smart card, a smart media, a payroll card, a health care card, a wristband, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a 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 include volatile or non-volatile memory for storing information (e.g., an account identifier, the name of the account holder, and / or the like).

[0067] As used herein, 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., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator under contract with an acquirer, a 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 a portable financial device managed by the transaction service provider. As used herein, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, server groups, and / or the like operated by or for a payment gateway.

[0068] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communication and processing of multiple parties in a network environment, such as the Internet. However, it will be understood that communication may be facilitated via 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 constitute a "system" that communicates directly or indirectly within a network environment. References to a "server" or "processor" as used herein may refer to a previously described server and / or processor, a different server and / or processor, and / or a combination of servers and / or processors that are described as performing the previous step or function. For example, as used in the specification and claims, a first server and / or a first processor that is described as performing a first step or function may refer to the same or a different server and / or processor that is described as performing a second step or function.

[0069] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from retailers or other entities and, in some cases, provides a guarantee of payment by agreement between the transaction service provider and an issuing institution. For example, a transaction service provider may include a payment network, such as Visa®, or any other entity that processes transactions. As used herein, 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.

[0070] Non-limiting embodiments or aspects of the disclosed subject matter are directed to systems, methods, and computer program products for flexible transaction message routing. For example, non-limiting embodiments or aspects of the disclosed subject matter provide for receiving an authorization request message associated with a payment transaction. The authorization request message may include a first account identifier (e.g., an identifier of a flex account) associated with a user. A second account identifier (e.g., an identifier of an account separated from the flex account) may be determined from the multiple account identifiers. This determination may be made via a rule. The rule may be set by the user or may be pre-set. After such determination, a modified authorization request message for the payment transaction may be generated if the modified authorization request message includes the second account identifier. This modified authorization request message may be transmitted to other systems, such as an issuer system, for further processing. A transaction history record based on the payment transaction involving the first account identifier and the second account identifier may then be stored. Once the transaction is approved, a settlement request message associated with the payment transaction may be generated and received. The settlement request message may include the first account identifier. Based on the transaction history record, a modified settlement request message may be generated, and the modified settlement request message may include a second account identifier. The modified settlement request message may then be sent to other systems, such as issuer systems, for further processing. In this manner, the disclosed subject matter allows one or more transactions to be initiated with a single account identifier (e.g., a flex account) and have different accounts and / or account types used to approve and subsequently settle the transaction. Additionally, the disclosed subject matter allows a user to complete a transaction using multiple different accounts and / or account types while only carrying and / or typing a single account identifier.Additionally, the disclosed subject matter allows users to set customized rules for selecting which accounts and / or account types are used for different transactions (e.g., based on customizable criteria). Additionally, the 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 differs from the (first) account identifier in the settlement message due to the storage of the transaction history.

[0071] 1 illustrates a system 100 for flexible transaction message routing according to a non-limiting embodiment or aspect. The system 100 may include an authentication system 102, an authentication rules database 104, a transaction history database 106, a settlement system 108, and / or a settlement rules database 110.

[0072] The authentication system 102 may include one or more devices that can receive information from and / or communicate information to the authentication rules database 104, the transaction history database 106, the acquirer system, the payment gateway system, and / or the issuer system. For example, the authentication system 102 may include a computing device such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the authentication system 102 may receive an authentication request, e.g., from an acquirer system and / or a payment gateway system, as described herein. Additionally or alternatively, the authentication system 102 may communicate the authentication request, e.g., to an issuer system, as described herein. In some non-limiting embodiments or aspects, the authentication system 102 may receive an authentication response, e.g., from an issuer system, as described herein. Additionally or alternatively, the authentication system 102 may communicate the authentication response, e.g., to an acquirer system and / or a payment gateway system, as described herein.

[0073] The authentication rule database 104 may include one or more devices that can receive information from and / or communicate information to the authentication system 102, the issuer system, and / or the customer device. For example, the authentication rule database 104 may include a computing device such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the authentication rule database 104 may communicate with a data store that may be local or remote to the authentication rule database 104. In some non-limiting embodiments or aspects, the authentication rule database 104 may receive information from, store information in, communicate information to, or retrieve information stored in a data store.

[0074] The transaction history database 106 may include one or more devices that can receive information from and / or communicate information to the authentication system 102 and / or the payment system 108. For example, the transaction history database 106 may include a computing device such as a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction history database 106 may be in communication with a data store that may be local or remote to the transaction history database 106. In some non-limiting embodiments or aspects, the transaction history database 106 may receive information from, store information in, communicate information to, or retrieve information stored in a data store.

[0075] The payment system 108 may include one or more devices that can receive information from and / or communicate information to the transaction history database 106, the payment rules database 110, the acquirer system, the payment gateway system, and / or the issuer system. For example, the payment system 108 may include computing devices such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the payment system 108 may receive a settlement request, e.g., from an acquirer system and / or a payment gateway system, as described herein. Additionally or alternatively, the payment system 108 may communicate the settlement request, e.g., to an issuer system, as described herein. In some non-limiting embodiments or aspects, the payment system 108 may receive a settlement response, e.g., from an issuer system, as described herein. Additionally or alternatively, the payment system 108 may communicate the settlement response, e.g., to an acquirer system and / or a payment gateway system, as described herein.

[0076] The settlement rules database 110 may include one or more devices that can receive information from and / or communicate information to the settlement system 108. For example, the settlement rules database 110 may include a computing device such as a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the settlement rules database 110 may communicate with a data store that may be local or remote to the settlement rules database 110. In some non-limiting embodiments or aspects, the settlement rules database 110 may receive information from, store information in, communicate information to, or retrieve information stored in the data store.

[0077] The number and arrangement of systems and devices shown in Figure 1 are provided as an example. There may be additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, and / or differently arranged systems and / or devices compared to those shown in Figure 1. Furthermore, two or more systems or devices shown in Figure 1 may be implemented within a single system or device, or a single system 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) or a set of devices (e.g., one or more devices) of system 100 may perform one or more functions described as being performed by another set of systems or another set of devices of system 100.

[0078]

[0023] Referring now to Figure 2, a process 200 for flexible transactional message routing is shown, according to certain non-limiting embodiments or aspects. The steps shown in Figure 2 are for illustrative purposes only. It will be understood that additional, fewer, different, and / or differently ordered steps may be used in non-limiting embodiments or aspects.

[0079] As shown in FIG. 2, at step 202, process 200 may include receiving an authentication request message. In some non-limiting embodiments or aspects, system 100 (e.g., its authentication system 102) may receive an authentication request message associated with a payment transaction between a user and a retailer. For example, authentication system 102 may receive an authentication request message associated with a payment transaction between a user and a retailer. The authentication request message may include a first account identifier associated with the user. The first account identifier may be associated with a first account (e.g., a flex account) that may be associated with multiple other types of accounts. In some non-limiting embodiments or aspects, transaction data may be received from an acquirer system and / or a payment gateway system. For example, authentication system 102 may receive an authentication request message from an acquirer system as described herein. In some non-limiting embodiments or aspects, the authentication request may include other identifying information associated with the payment transaction, such as a transaction identifier, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0080] In some non-limiting embodiments or aspects, the first account identifier may include a lead account identifier associated with a physical payment device associated with the user. Additionally or alternatively, the multiple account identifiers may include multiple virtual account identifiers associated with the user (e.g., in addition to or instead of the lead account number). For example, the lead account identifier may include a debit account identifier (e.g., a debit account number) and the multiple virtual account identifiers may include a virtual credit account identifier (e.g., a virtual credit card number) and a virtual prepaid account identifier (e.g., a virtual prepaid card number).

[0081] As shown in FIG. 2, at step 204, process 200 may include determining a second account identifier. For example, system 100 (e.g., authentication system 102 and / or its authentication rule database 104) may determine the second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier. In some non-limiting embodiments or aspects, authentication system 102 and / or authentication rule database 104 may determine the second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier. In some non-limiting embodiments or aspects, the at least one rule may be stored in authentication rule database 104. In some non-limiting embodiments or aspects, authentication rule database 104 may communicate the at least one rule associated with the first account identifier (and / or rule data associated therewith) to authentication system 102.

[0082] In some non-limiting embodiments or aspects, the authentication system 102 may receive rule data associated with at least one rule. For example, the authentication system 102 may receive rule data associated with at least one rule from the authentication rule database 104. The rule data associated with the at least one rule may include a threshold value. For example, the authentication system 102 and / or the authentication rule database 104 may determine whether a transaction amount of a payment transaction (e.g., associated with an authentication request) meets a threshold value. The authentication system 102 and / or the authentication rule database 104 may identify (e.g., select) a second account identifier (e.g., from the first account identifier and / or multiple account identifiers associated with the user) in response to determining that the payment transaction meets the threshold value. Additionally or alternatively, the authentication system 102 and / or the authentication rule database 104 may identify (e.g., select) a third account identifier (e.g., from the multiple account identifiers) in response to determining that the payment transaction does not meet the threshold value.

[0083] In some non-limiting embodiments or aspects, the rule data associated with at least one rule may include at least one category criterion. For example, the authentication system 102 and / or the authentication rule database 104 may determine whether the payment transaction is in a selected category. For illustrative purposes, if the selected category is a cross-border transaction, the authentication system 102 and / or the authentication rule database 104 may determine whether the payment transaction is a cross-border transaction. In response to determining that the payment transaction meets the category criterion (e.g., is a cross-border transaction), the authentication system 102 and / or the authentication rule database 104 may identify (e.g., select) a second account identifier (e.g., from the first account identifier and / or a plurality of account identifiers associated with the user). Additionally or alternatively, the authentication system 102 and / or the authentication rule database 104 may identify (e.g., select) a third account identifier (e.g., from a plurality of account identifiers) in response to determining that the payment transaction does not meet the category criterion (e.g., is not a cross-border transaction). As another illustration, if the selected category is an e-commerce transaction, the authentication system 102 and / or the authentication rule database 104 may determine whether the payment transaction is an e-commerce transaction. In response to determining that the payment transaction meets the category criteria (e.g., is an e-commerce transaction), the authentication system 102 and / or the authentication rule database 104 may identify (e.g., select) a second account identifier (e.g., from the first account identifier and / or multiple account identifiers associated with the user). Additionally or alternatively, the authentication system 102 and / or the authentication rule database 104 may identify (e.g., select) a third account identifier (e.g., from the multiple account identifiers) in response to determining that the payment transaction does not meet the category criteria (e.g., is not an e-commerce transaction).In some non-limiting embodiments or aspects, a category criterion may be combined with at least one other category criterion and / or at least one threshold value to create complex rules (e.g., if the payment transaction is a cross-border transaction and an e-commerce transaction, select the second account identifier, otherwise select the third account identifier).

[0084] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on the rule data received from the user and a fallback rule. The authentication system 102 may determine a second account identifier. For example, the authentication system 102 may determine that the first rule is not applicable to the payment transaction associated with the authentication request message. In response to determining that the first rule is not applicable to the payment transaction, the authentication system 102 may determine (e.g., select) a second account identifier (e.g., from a plurality of account identifiers) based on the fallback rule.

[0085] In some non-limiting embodiments or aspects, at least one rule and / or rule data associated therewith may be received by the authentication rules database 104 from an issuer system. The at least one rule may be a user-configured rule associated with a first account identifier or a fallback rule configured by the issuer system and / or a transaction service provider system (e.g., the authentication system 102).

[0086] In some non-limiting embodiments or aspects, the first account identifier may include a lead account identifier associated with a physical payment device associated with the user. Additionally or alternatively, the multiple account identifiers may include multiple virtual account identifiers associated with the user (e.g., in addition to or instead of the lead account number). For example, the lead account identifier may include a debit account identifier (e.g., a debit account number) and the multiple virtual account identifiers may include a virtual credit account identifier (e.g., a virtual credit card number) and a virtual prepaid account identifier (e.g., a virtual prepaid card number). In some non-limiting embodiments or aspects, the second account identifier may include a selected virtual account identifier. For example, determining the second account identifier may include selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0087] 2, at step 206, process 200 may include generating a modified authentication request message. In some non-limiting embodiments or aspects, system 100 (e.g., its authentication system 102) may generate a modified authentication request message for the payment transaction, where the modified authentication request message may include a second account identifier. For example, authentication system 102 may generate a modified authentication request message for a payment transaction that includes a second account identifier (e.g., instead of a first account identifier). In some non-limiting embodiments or aspects, the modified authentication request may include other identifying information associated with the payment transaction (e.g., from the authentication request), such as a transaction identifier, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0088] 2, at step 208, process 200 may include transmitting a modified authentication request message. For example, system 100 (e.g., its authentication system 102) may transmit the modified authentication request message to an issuer system associated with the second account identifier. In response to receiving the modified authentication request message, the issuer system may process the modified authentication request message as described herein (e.g., determine whether to authorize the payment transaction based on the modified authentication request message and / or the like).

[0089] 2, at step 210, process 200 may include storing a transaction history record. In some non-limiting embodiments or aspects, system 100 (e.g., authentication system 102 and / or its transaction history database 106) may store the transaction history record. For example, authentication system 102 may store the transaction history record based on the payment transaction and the second account identifier in transaction history database 106. In some non-limiting embodiments or aspects, the transaction history record may include other identifying information associated with the payment transaction, such as a first account identifier, a transaction identifier, an acquisition reference number, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0090] In some non-limiting embodiments or aspects, the issuer system may determine whether to authorize the payment transaction based on the modified authentication request message. For example, the issuer system may generate an authentication decision (e.g., authorize, decline, and / or the like) based on the modified authentication request message. By way of example, if the account associated with the second account identifier has sufficient funds and / or available credit for the payment transaction (e.g., based on the transaction amount in the modified authentication request), the issuer system may determine to authorize the transaction. Additionally or alternatively, if the account associated with the second account identifier does not have sufficient funds or available credit for the payment transaction (e.g., based on the transaction amount in the modified authentication request) and / or other criteria for not authorizing the payment transaction are met (e.g., fraud detection criteria, anti-money laundering criteria, cross-border transaction prohibitions, etc.), the issuer system may determine not to authorize (e.g., decline, reject, etc.) the transaction. In some non-limiting embodiments or aspects, the issuer system may generate an authentication response based on the determination of whether to authorize the payment transaction (e.g., based on the authentication decision). For example, the authentication response may include a second account identifier.

[0091] In some non-limiting embodiments or aspects, the system 100 (e.g., its authentication system 102) may receive an authentication response, for example, from an issuer system. In some non-limiting embodiments or aspects, the system 100 (e.g., its authentication system 102) may generate a modified authentication response. For example, the authentication system 102 may generate a modified authentication response for the payment transaction, where the modified authentication response may include the first account identifier. For example, the authentication system 102 may identify a transaction history record associated with the payment transaction (e.g., the transaction history record may indicate that the first account identifier was replaced with the second account identifier at the time of generating the modified authentication request), and / or the authentication system 102 may generate a modified authentication response for the payment transaction including the first account identifier (e.g., instead of the second account identifier) ​​based on an identification of the transaction history record. In some non-limiting embodiments or aspects, the authentication system 102 may communicate the modified authentication response, for example, to the acquirer system and / or the payment gateway system (e.g., that originally communicated the authentication request).

[0092] As shown in FIG. 2, at step 212, process 200 may include receiving a payment request message. In some non-limiting embodiments or aspects, system 100 (e.g., its payment system 108) may receive the payment request message. For example, payment system 108 may receive a payment request message associated with a payment transaction (e.g., from an acquirer system and / or a payment gateway system), where the payment request message may include a first account identifier. The payment request message may be received from the acquirer system and / or a payment gateway system. In some non-limiting embodiments or aspects, the payment request message may include other identifying information associated with the payment transaction, such as a transaction identifier, an acquisition reference number, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0093] As shown in FIG. 2, at step 214, process 200 may include identifying a transaction history record. In some non-limiting embodiments or aspects, system 100 (e.g., payment system 108 and / or its transaction history database 106) may identify a transaction history record. For example, payment system 108 may identify a transaction history record stored in transaction history database 106 based on the payment transaction and / or a settlement request message associated therewith. Additionally or alternatively, payment system 108 may identify a transaction history record stored in transaction history database 106 based on other identifying information from the settlement request message that matches corresponding identifying information in the transaction history record. Thus, a transaction history record for the payment transaction associated with a first account identifier may be identified. Further, a second account identifier associated with the payment transaction may be determined based on the transaction history record, for example, because the transaction history record was generated based on (e.g., includes) a second account identifier.

[0094] In some non-limiting embodiments or aspects, the payment system 108 may not identify a transaction history record (e.g., because there is no transaction history record associated with the payment transaction stored in the transaction history database 106). Additionally or alternatively, the payment system 108 may identify a fallback rule associated with the first account identifier.

[0095] As shown in FIG. 2, at step 216, process 200 may include generating a modified settlement request message. In some non-limiting embodiments or aspects, the system 100 (e.g., its payment system 108) may generate the modified settlement request message. For example, the payment system 108 may generate the modified settlement request message based on identification of the transaction history record, where the modified settlement request message may include a second account identifier (e.g., instead of the first account identifier). Additionally or alternatively, in the absence of the transaction history record, the payment system 108 may generate the modified settlement request message based on a fallback settlement rule, as described herein.

[0096] In some non-limiting embodiments or aspects, the modified payment request message may include other identifying information (e.g., from the payment request message) associated with the payment transaction, such as a transaction identifier, an acquisition reference number, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0097] 2, at step 218, process 200 may include sending a modified settlement request message. In some non-limiting embodiments or aspects, the system 100 (e.g., its payment system 108) may send the modified settlement request message. For example, the payment system 108 may send the modified settlement request message to an issuer system associated with the second account identifier.

[0098] In some non-limiting embodiments or aspects, the issuer system may generate a settlement response (e.g., a clearing message and / or the like) based on the modified settlement request message. For example, the settlement response may include the second account identifier. In some non-limiting embodiments or aspects, the settlement response message may include other identifying information associated with the payment transaction (e.g., from the settlement request message), such as a transaction identifier, an acquisition reference number, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0099] In some non-limiting embodiments or aspects, the system 100 (e.g., its payment system 108) may receive a settlement response, for example, from an issuer system. In some non-limiting embodiments or aspects, the system 100 (e.g., its payment system 108) may generate a modified settlement response. For example, the payment system 108 may generate a modified settlement response for the payment transaction, where the modified settlement response may include the first account identifier. For example, the payment system 108 may identify a transaction history record associated with the payment transaction (e.g., the transaction history record may indicate that the first account identifier was replaced with the second account identifier at the time of generating the modified authorization request), and / or the payment system 108 may generate a modified settlement response for the payment transaction that includes the first account identifier (e.g., instead of the second account identifier) ​​based on the identification of the transaction history record. In some non-limiting embodiments or aspects, the payment system 108 may communicate the modified settlement response, for example, to the acquirer system and / or the payment gateway system (e.g., that originally communicated the settlement request).

[0100]

[0036] Referring now to Figure 3, Figure 3 is a diagram of a non-limiting embodiment or aspect of an example environment 300 in which the systems, products, and / or methods described herein may be implemented. As shown in Figure 3, the environment 300 may include a transaction service provider system 302, an issuer system 304, a customer device 306, a retailer system 308, an acquirer system 310, and a communication network 312. In some non-limiting embodiments or aspects, the system 100, the authentication system 102, the authentication rules database 104, the transaction history database 106, the settlement system 108, and / or the settlement rules database 110 may be implemented by (e.g., a portion of) the transaction service provider system 302. In some non-limiting embodiments or aspects, at least one of the system 100, the authentication system 102, the authentication rules database 104, the transaction history database 106, the settlement system 108, and / or the settlement rules database 110 may be implemented by another system, device, group of systems, or group of devices (part of) that is separate from or includes the transaction service provider system 302, such as an issuer system 304, a retailer system 308, an acquirer system 310, and / or the like.

[0101] The transaction service provider system 302 may include one or more devices that can receive information from and / or communicate information to the issuer system 304, the customer device 306, the retailer system 308, and / or the acquirer system 310 via a communication network 312. For example, the transaction service provider system 302 may include computing devices such as a server (e.g., a transaction processing server), a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction service provider system 302 may be associated with a transaction service provider as described herein. In some non-limiting embodiments or aspects, the transaction service provider system 302 may communicate with a data store that may be local or remote to the transaction service provider system 302. In some non-limiting embodiments or aspects, the transaction service provider system 302 may receive information from, store information in, communicate information to, or retrieve information stored in the data store.

[0102] The issuer system 304 may include one or more devices that can receive information from and / or communicate information to the transaction service provider system 302, the customer device 306, the retailer system 308, and / or the acquirer system 310 via the communication network 312. For example, the issuer system 304 may include computing devices such as a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the issuer system 304 may be associated with an issuer institution, as described herein. For example, the issuer system 304 may be associated with an issuer institution that issued a credit account, a debit account, a credit card, a debit card, and / or the like to a user associated with the customer device 306.

[0103] The customer devices 306 may include one or more devices that can receive information from and / or communicate information to the transaction service provider system 302, the issuer system 304, the retailer system 308, and / or the acquirer system 310 via the communications network 312. Additionally or alternatively, each customer device 306 may include devices that can receive information from and / or communicate information to other customer devices 306 via the communications network 312, another network (e.g., an ad-hoc network, a local network, a private network, a virtual private network, and / or the like), and / or any other suitable communications technology. For example, the customer devices 306 may include client devices and / or the like. In some non-limiting embodiments or aspects, a customer device 306 may or may not be able to receive information (e.g., from a retailer system 308 or from another customer device 306) 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) and / or may or may not be able to communicate information (e.g., to a retailer system 308) via a short-range wireless communication connection.

[0104] The retailer system 308 may include one or more devices that can receive information from and / or communicate information to the transaction service provider system 302, the issuer system 304, the customer device 306, and / or the acquirer system 310 via a communication network 312. The retailer system 308 may also include devices that can receive information from the customer device 306 via a 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 communication network 312, the customer device 306, and / or the like, and / or communicate information to the customer device 306 via the communication network 312, the communication connection, and / or the like. In some non-limiting embodiments or aspects, the retailer system 308 may include computing devices such as a server, a server group, a client device, a client device group, and / or other similar devices. In some non-limiting embodiments or aspects, the retailer system 308 may be associated with a retailer, as described herein. In some non-limiting embodiments or aspects, the retailer system 308 may include one or more client devices. For example, the retailer system 308 may include a client device that allows a retailer to communicate information to the transaction service provider system 302. In some non-limiting embodiments or aspects, the retailer system 308 may include one or more devices, such as computers, computer systems, and / or peripheral devices that the retailer can use to conduct transactions with users. For example, the retailer system 308 may include a POS device and / or a POS system.

[0105] The acquirer system 310 may include one or more devices that can receive information from and / or communicate information to the transaction service provider system 302, the issuer system 304, the customer device 306, and / or the retailer system 308 via a communication network 312. For example, the acquirer system 310 may include a computing device, a server, a group of servers, and / or the like. In some non-limiting embodiments or aspects, the acquirer system 310 may be associated with an acquirer, as described herein.

[0106] The communications network 312 may include one or more wired and / or wireless networks. For example, the communications network 312 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 combinations of these or other types of networks.

[0107] The number and arrangement of systems, devices, and / or networks shown in Figure 3 are provided as an example. There may be additional systems, devices, and / or networks, fewer systems, devices, and / or networks, different systems, devices, and / or networks, and / or different arrangements of systems, devices, and / or networks compared to Figure 3. Furthermore, two or more systems or devices shown in Figure 3 may be implemented within a single system or device, or a single system or device shown in Figure 3 may be implemented as multiple distributed systems or devices. Additionally or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of environment 300 may perform one or more functions described as being performed by another set of systems or another set of devices of environment 300.

[0108] Referring now to FIG. 4, a diagram of example components of an apparatus 400 according to a non-limiting embodiment or aspect is shown. The apparatus 400 may correspond, by way of example, to at least one of the system 100, the authentication system 102, the authentication rules database 104, the transaction history database 106, the settlement system 108, and / or the settlement rules database 110 of FIG. 1, and / or at least one of the transaction service provider system 302, the issuer system 304, the customer device 306, the retailer system 308, and / or the acquirer system 310 of FIG. 3. In some non-limiting embodiments or aspects, such a system or apparatus of FIG. 1 or FIG. 3 may include at least one apparatus 400 and / or at least one component of the apparatus 400. The number and arrangement of components shown in FIG. 4 are provided as an example. In some non-limiting embodiments or aspects, the apparatus 400 may include additional components, fewer components, different components, or a different arrangement of components compared to those shown in FIG. 4. Additionally or alternatively, a set of components (e.g., one or more components) of apparatus 400 may perform one or more functions described as being performed by another set of components of apparatus 400.

[0109] As shown in FIG. 4, the device 400 may include a bus 402, a processor 404, a memory 406, a storage component 408, an input component 410, an output component 412, and a communication interface 414. The bus 402 may include components that enable communication between the components of the device 400. In some non-limiting embodiments or aspects, the processor 404 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 404 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 may be programmed to perform functions. The memory 406 may include a random access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and / or instructions for use by the processor 404.

[0110] With continued reference to FIG. 4, the storage component 408 may store information and / or software related to the operation and use of the device 400. For example, the storage component 408 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. The input component 410 may include components that enable the device 400 to receive information via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally or alternatively, the input component 410 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). The output component 412 may include components that provide output information from the device 400 (e.g., a display, a speaker, one or more light emitting diodes (LEDs), etc.). The communication interface 414 may include transceiver-like components (e.g., a transceiver, a separate receiver and transmitter, etc.) that enable the device 400 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 414 may enable the device 400 to receive information from another device and / or provide information to another device. For example, the communication interface 414 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.

[0111] The device 400 may perform one or more processes described herein. The device 400 may perform these processes based on the processor 404 executing software instructions stored by a computer-readable medium, such as the memory 406 and / or the storage component 408. The computer-readable medium may include any non-transitory memory device. The memory device includes a memory space located within a single physical storage device or a memory space spread across multiple physical storage devices. The software instructions may be read into the memory 406 and / or the storage component 408 from another computer-readable medium or from another device via the communication interface 414. When executed, the software instructions stored in the memory 406 and / or the storage component 408 may cause the processor 404 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, the embodiments described herein are not limited to any particular combination of hardware circuitry and software. As used herein, the term "programmed or configured" refers to the arrangement of software, hardware circuitry, or any combination thereof, on one or more devices.

[0112] 5A and 5B, a schematic diagram of an implementation 500 of a system and method for flexible transaction message routing according to some non-limiting embodiments or aspects is shown. In FIG. 5A and 5B, the implementation 500 may include an issuer system 504, a user 506, a retailer system 508, an acquirer system 510, an authentication system 522, a transaction control database 524, an authentication fallback rules database 524a, a transaction history database 526, a settlement system 528, and / or a settlement fallback rules database 530. In some non-limiting embodiments or aspects, the issuer system 504 may be the same as or similar to the issuer system 304. In some non-limiting embodiments or aspects, the user 506 may be the same as or similar to the customer device 306. In some non-limiting embodiments or aspects, the retailer system 508 may be the same as or similar to the retailer system 308. In some non-limiting embodiments or aspects, the acquirer system 510 may be the same as or similar to the acquirer system 310. In some non-limiting embodiments or aspects, the authentication system 522 may be the same as, similar to, or a part of the authentication system 102 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the transaction control database 524 may be the same as, similar to, or a part of the authentication rules database 104 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the authentication fallback rules database 524a may be the same as, similar to, or a part of the authentication rules database 104 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the transaction history database 526 may be the same as, similar to, or a part of the transaction history database 106 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the settlement system 528 may be the same as, similar to, or a part of the settlement system 108 and / or the transaction service provider system 302.In some non-limiting embodiments or aspects, the settlement fallback rules database 530 may be the same as, similar to, or a part of the settlement rules database 110 and / or the transaction service provider system 302.

[0113] 5A illustrates that in some non-limiting embodiments or aspects, a user 506 may communicate and / or set (e.g., configure, input, and / or the like) rule data associated with at least one rule. For example, a user 506 may communicate the rule data to an issuer system 504 and / or a trading control database 524 (e.g., using a computing device such as a customer device 306 and / or the like). For example, a user 506 may use an application (e.g., a mobile application) associated with the issuer system 504 and / or a trading control database 524 on a computing device (e.g., a customer device 306 and / or the like) to input rule data associated with at least one rule.

[0114] In some non-limiting embodiments or aspects, the issuer system 504 may receive the rules data (e.g., from the user 506). Additionally or alternatively, the issuer system 504 may communicate the rules data to the exchange control database 524, which may receive the rules data as described herein. For example, the issuer system 504 may communicate the rules data to the exchange control database 524 using an application programming interface (API). The API may be provided by the exchange control database 524 and / or an exchange service provider system (e.g., the exchange service provider system 302 and / or the like). In some non-limiting embodiments or aspects, the rules data may include a first account identifier (e.g., a lead account identifier (PAN1)) and / or at least one second account identifier (e.g., a credit account identifier (PAN C), a debit account identifier (PAN D), a prepaid account identifier (PAN P), at least one virtual account identifier, a virtual credit account identifier, a virtual prepaid account identifier, a virtual debit account identifier, any combination thereof, and / or the like). Additionally or alternatively, the rule data may include data representing at least one rule in a specified format (e.g., a standardized format, a JavaScript Object Notation (JSON) format, and / or the like). In some non-limiting embodiments or aspects, the transaction control database 524 may store the rule data and / or communicate the rule data to the authentication system 522.

[0115] In some non-limiting embodiments or aspects, the issuer system 504 and / or the trading control database 524 may receive at least one change to the rules data (e.g., from a user 506). For example, the change to the rules data may include at least one of adding a new secondary account identifier, deleting a secondary account identifier, changing which account identifier is the lead account identifier, replacing the lead account identifier with a new account identifier, and / or the like. Additionally or alternatively, the change to the rules data may include at least one of adding a new rule, deleting an existing rule, modifying an existing rule, and / or the like.

[0116] In some non-limiting embodiments or aspects, the rules data may include at least one fallback rule, as described herein. In some non-limiting embodiments or aspects, the transaction control database 524 may store the fallback rules. Additionally or alternatively, the authentication fallback rules database 524a may store the fallback rules.

[0117] 5B , in some non-limiting embodiments or aspects, a user 506 may initiate a payment transaction at a retailer system 508. For example, the user 506 may initiate a payment transaction at a POS device of the retailer system 508 using a physical payment device associated with a first account identifier (e.g., lead PAN (PAN1)). Additionally or alternatively, the user 506 may initiate a payment transaction at the retailer system 508 using a computing device (e.g., customer device 306 and / or the like) using a first account identifier (e.g., lead PAN (PAN1) or token (Token1)).

[0118] In some non-limiting embodiments or aspects, the retailer system 508 may generate an authentication request message associated with the payment transaction. For example, the authentication request message may include a first account identifier (e.g., lead PAN (PAN1)). The retailer system 508 may communicate the authentication request to the acquirer system 510 (and / or a payment gateway), which may communicate the authentication request to the authentication system 522.

[0119] In some non-limiting embodiments or aspects, the authentication system 522 may receive an authentication request. Additionally or alternatively, the authentication system 522 may determine a second account identifier (e.g., one of a credit account identifier (PAN C), a debit account identifier (PAN D), a prepaid account identifier (PAN P), or the like) from the plurality of account identifiers based on at least one rule associated with a first account identifier (e.g., a lead PAN (PAN1)). For example, the authentication system 522 may receive (e.g., obtain, access, read, and / or the like) rules data from the transaction control database 524. Additionally or alternatively, the authentication system 522 may determine the second account identifier based on the rules data.

[0120] In some non-limiting embodiments or aspects, the rules data may include at least one threshold value (e.g., at least one threshold transaction amount value). The authentication system 522 may determine whether a transaction amount of a payment transaction (e.g., which may be part of the authentication request) meets the threshold value. For example, determining the second account identifier may include selecting the second account identifier from a plurality of account identifiers based on the transaction amount meeting the threshold value.

[0121] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on rule data received from the user 506 and / or stored by the transaction control database 524. Additionally or alternatively, at least one fallback rule may be stored (e.g., by the transaction control database 524 and / or the authentication fallback rule database 524a). Determining the second account identifier may include the authentication system 522 determining that the first rule is not applicable to the payment transaction associated with the authentication request message. In response to determining that the first rule is not applicable, the authentication system 522 may determine a second account identifier from the plurality of account identifiers based on the fallback rule.

[0122] In some non-limiting embodiments or aspects, the authentication system 522 may generate a modified authorization request message for the payment transaction. For example, the modified authorization request message may include a second account identifier (e.g., one of a credit account identifier (PAN C), a debit account identifier (PAN D), a prepaid account identifier (PAN P), or the like). In some non-limiting embodiments or aspects, the modified authorization request message may include a token (e.g., token 1) associated with the user (e.g., the token may indicate that flexible transaction message routing is utilized). In some non-limiting embodiments or aspects, the authentication system 522 may send the modified authorization request message to the issuer system 504, which may be associated with the second account identifier. In some non-limiting embodiments or aspects, the authentication system 522 may store a transaction history record based on the payment transaction and / or the second account identifier in the transaction history database 526.

[0123] In some non-limiting embodiments or aspects, the issuer system 504 can determine whether to authorize the payment transaction based on the modified authentication request message, as described herein. For example, the issuer system 504 can generate an authentication decision (e.g., authorize, decline, and / or the like) based on the modified authentication request message, as described herein. In some non-limiting embodiments or aspects, the issuer system 504 can generate an authentication response based on the decision of whether to authorize the payment transaction (e.g., based on the authentication decision), as described herein. For example, the authentication response can include the second account identifier.

[0124] In some non-limiting embodiments or aspects, the authentication system 522 may receive an authentication response, for example, from the issuer system 504. In some non-limiting embodiments or aspects, the authentication system 522 may generate a modified authentication response as described herein. For example, the authentication system 522 may identify a transaction history record stored in the transaction history database 526 associated with the payment transaction (e.g., the transaction history record may indicate that the first account identifier was replaced with the second account identifier at the time of generating the modified authentication request), and / or the authentication system 522 may generate a modified authentication response for the payment transaction including the first account identifier (e.g., instead of the second account identifier) ​​based on the identification of the transaction history record. In some non-limiting embodiments or aspects, the authentication system 522 may communicate the modified authentication response, for example, to the acquirer system and / or the payment gateway system (e.g., that originally communicated the authentication request).

[0125] In some non-limiting embodiments or aspects, the acquirer system 510 may generate a settlement request message associated with the payment transaction. For example, the settlement request may be generated after a period of time (e.g., a predetermined period of time, a minimum period of time, a selected period of time, and / or the like) after the authentication request message is first communicated. In some non-limiting embodiments or aspects, the settlement request message may include a first account identifier (e.g., a lead pan (PAN1) and / or a token (Token1)). Additionally or alternatively, the settlement request may include other identifying information associated with the payment transaction, such as a transaction identifier, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like. In some non-limiting embodiments or aspects, the acquirer system 510 may communicate the settlement request message to the settlement system 528.

[0126] In some non-limiting embodiments or aspects, the payment system 528 may receive (e.g., from the acquirer system 510) a payment request message associated with the payment transaction. In some non-limiting embodiments or aspects, the payment system 528 and / or the transaction history database 526 may identify a transaction history record based on the payment transaction. For example, the payment system 528 may receive (e.g., obtain, request, receive, etc.) a transaction history record from the transaction history database 526 and / or the payment system 528 may receive a second account identifier associated with the transaction history record from the transaction history record from the transaction history database 526.

[0127] In some non-limiting embodiments or aspects, the payment system 528 may generate a modified payment request message. For example, the payment system 528 may generate the modified payment request message based on identifying the transaction history record and / or receiving the second account identifier. In some non-limiting embodiments or aspects, the modified payment request message may include the second account identifier. Additionally or alternatively, the modified payment request may include other identifying information associated with the payment transaction, such as a transaction identifier, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0128] In some non-limiting embodiments or aspects, the payment system 528 may communicate the modified payment request message to the issuer system 504 associated with the second account identifier.

[0129] In some non-limiting embodiments or aspects, the payment system 528 may determine that there is no transaction history record associated with the payment transaction stored in the transaction history database 526. In response to such a determination, the payment system 528 may apply a fallback payment rule. For example, the payment system 528 may receive (e.g., obtain, request and receive, and / or the like) a fallback payment rule from the payment fallback rules database 530.

[0130] In some non-limiting embodiments or aspects, the issuer system 504 may generate a settlement response (e.g., a clearing message and / or the like) based on the modified settlement request message. For example, the settlement response may include the second account identifier.

[0131] In some non-limiting embodiments or aspects, the payment system 528 may receive a settlement response, for example, from the issuer system 504. In some non-limiting embodiments or aspects, the payment system 528 may generate a modified settlement response, as described herein. For example, the payment system 528 may generate a modified settlement response for the payment transaction, where the modified settlement response may include the first account identifier. For example, as described herein, the payment system 528 may identify a transaction history record stored in the transaction history database 526 associated with the payment transaction (e.g., the transaction history record may indicate that the first account identifier was replaced with the second account identifier upon generation of the modified authorization request), and / or the payment system 528 may generate a modified settlement response for the payment transaction that includes the first account identifier (e.g., instead of the second account identifier) ​​based on the identification of the transaction history record. In some non-limiting embodiments or aspects, the payment system 528 may communicate the modified settlement response, for example, to the acquirer system 510 and / or the payment gateway system (e.g., which originally communicated the settlement request).

[0132] 6A and 6B, a schematic diagram of an implementation 600 of a system and method for flexible transaction message routing is shown, according to some non-limiting embodiments or aspects. As shown in FIG. 6A and 6B, the implementation 600 may include at least one issuer system 604a, 604b, 604c, a user 606, a retailer system 608, an acquirer system 610, an authentication system 622, a transaction control database 624, a transaction history database 626, and / or a settlement system 628. In some non-limiting embodiments or aspects, the issuer system 604a, 604b, 604c may be the same as or similar to the issuer system 304. In some non-limiting embodiments or aspects, the user 606 may be the same as or similar to the customer device 306. In some non-limiting embodiments or aspects, the retailer system 608 may be the same as or similar to the retailer system 308. In some non-limiting embodiments or aspects, the acquirer system 610 may be the same as or similar to the acquirer system 310. In some non-limiting embodiments or aspects, the authentication system 622 may be the same as, similar to, or part of the authentication system 102 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the transaction control database 624 may be the same as, similar to, or part of the authentication rules database 104 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the transaction history database 626 may be the same as, similar to, or part of the transaction history database 106 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the settlement system 628 may be the same as, similar to, or part of the settlement system 108 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the first issuer system 604a, the second issuer system 604b, and the third issuer system 604c may be part of the same system (e.g., the debit system, credit system, and prepaid system of the same issuer system) and / or may be associated with the same issuer.In some non-limiting embodiments or aspects, the first issuer system 604a, the second issuer system 604b, and the third issuer system 604c may be separate issuer systems and each may be associated with a separate issuer.

[0133] In a non-limiting embodiment or aspect, a user 606 may communicate and / or set (e.g., configure, input, and / or the like) rule data associated with at least one rule. For example, a user 606 may communicate the rule data to an issuer system (e.g., at least one of issuer systems 604a, 604b, 604c) and / or a trading control database 624 (e.g., using a computing device such as a customer device 306 and / or the like). For example, a user 606 may use an application (e.g., a mobile application) associated with an issuer system and / or a trading control database 624 on a computing device (e.g., a customer device 306 and / or the like) to input rule data associated with at least one rule.

[0134] In some non-limiting embodiments or aspects, an issuer system (e.g., at least one of issuer systems 604a, 604b, 604c) and / or trading control database 624 may receive (e.g., from user 606) at least one change to the rules data. For example, the change to the rules data may include at least one of adding a new secondary account identifier, deleting a secondary account identifier, changing which account identifier is the lead account identifier, replacing the lead account identifier with a new account identifier, and / or the like. Additionally or alternatively, the change to the rules data may include at least one of adding a new rule, deleting an existing rule, modifying an existing rule, and / or the like.

[0135] In some non-limiting embodiments or aspects, the transaction control database 624 may receive the rule data, as described herein. In some non-limiting embodiments or aspects, the rule data may include a first account identifier (e.g., a lead account) and / or at least one second account identifier (e.g., a consumer funding selection for each rule, such as a (virtual) credit account identifier, a (virtual) prepaid account identifier, a (virtual) debit account identifier, any combination thereof, and / or the like). Additionally or alternatively, the rule data may include data representing each rule in a specified format (e.g., consumer rule). Additionally or alternatively, the rule data may include a rule identification number (e.g., a rule number) for each rule, an account type (e.g., prepaid, credit, debit, and / or the like) associated with each rule, any combination thereof, and / or the like. In some non-limiting embodiments or aspects, the rule data may include at least one fallback rule (e.g., a default payment), as described herein. In some non-limiting embodiments or aspects, the transaction control database 624 may store the rules data and / or communicate the rules data to the authentication system 622 .

[0136] In some non-limiting embodiments or aspects, a user 606 may initiate a payment transaction with a retailer system 608. For example, the user 606 may initiate a payment transaction at a POS device of the retailer system 608 using a physical payment device associated with a first account identifier (e.g., a lead account). Additionally or alternatively, the user 606 may initiate a payment transaction with the retailer system 608 using a computing device (e.g., a customer device 306 and / or the like) using a first account identifier (e.g., a lead account).

[0137] In some non-limiting embodiments or aspects, the retailer system 608 may generate an authorization request message associated with the payment transaction. For example, the authorization request message may include a first account identifier (e.g., a lead account). The retailer system 608 may communicate the authorization request to the acquirer system 610 (and / or a payment gateway), which may communicate the authorization request to the authentication system 622.

[0138] In some non-limiting embodiments or aspects, authentication system 622 may receive the authentication request. Additionally or alternatively, authentication system 622 may determine a second account identifier (e.g., one of the consumer financing selections) from the plurality of account identifiers based on at least one rule stored in transaction control database 624. For example, authentication system 622 may receive (e.g., obtain, access, read, and / or the like) rule data from transaction control database 624. Additionally or alternatively, authentication system 622 may determine the second account identifier based on the rule data.

[0139] In some non-limiting embodiments or aspects, the rule data may include at least one threshold value (e.g., at least one threshold transaction amount value). For example, as shown in FIG. 6A, a first rule (T1) may be associated with a transaction amount less than a first threshold value of 500 yen (e.g., amount < 500 yen), a second rule (T2) may be associated with a transaction amount greater than a second threshold value of 50,000 yen (e.g., amount > 50,000 yen), and a third rule (T3) may be associated with a transaction amount between the first and second threshold values ​​(e.g., between 500 yen and 50,000 yen). The authentication system 622 may determine whether the transaction amount of the payment transaction (e.g., which may be part of the authentication request) satisfies one of these thresholds. For example, determining the second account identifier may include selecting the second account identifier from a plurality of account identifiers (e.g., consumer funding selections associated with each rule) based on the transaction amount satisfying the threshold value of one of the rules.

[0140] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on rule data received from the user 606 and / or stored by the transaction control database 624. Additionally or alternatively, at least one fallback rule (e.g., default payment) may be stored (e.g., by the transaction control database 624). Determining the second account identifier may include the authentication system 622 determining that the first three rules (T1-T3) are not applicable to the payment transaction associated with the authorization request message. In response to determining that the rules are not applicable, the authentication system 622 may determine the second account identifier based on the fallback rule (e.g., default payment).

[0141] In some non-limiting embodiments or aspects, the authentication system 622 may generate a modified authorization request message for the payment transaction. For example, the modified authorization request message may include a second account identifier (e.g., one of the consumer financing choices). In some non-limiting embodiments or aspects, the authentication system 622 may send the modified authorization request message to an issuer system associated with the second account identifier (e.g., one of the first issuer system 604a, the second issuer system 604b, and / or the third issuer system 604c, from which one of these issuer systems issued the second account identifier). In some non-limiting embodiments or aspects, the authentication system 622 may store a transaction history record based on the payment transaction and / or the second account identifier in the transaction history database 626.

[0142] In some non-limiting embodiments or aspects, the issuer system 604 can determine whether to authorize the payment transaction based on the modified authentication request message, as described herein. For example, the issuer system 604 can generate an authentication decision (e.g., authorize, decline, and / or the like) based on the modified authentication request message, as described herein. In some non-limiting embodiments or aspects, the issuer system 604 can generate an authentication response based on the determination of whether to authorize the payment transaction (e.g., based on the authentication decision), as described herein. For example, the authentication response can include the second account identifier.

[0143] In some non-limiting embodiments or aspects, the authentication system 602 may receive an authentication response, for example, from the issuer system 604. In some non-limiting embodiments or aspects, the authentication system 602 may generate a modified authentication response as described herein. For example, the authentication system 602 may identify a transaction history record stored in the transaction history database 626 associated with the payment transaction (e.g., the transaction history record may indicate that the first account identifier was replaced with the second account identifier at the time of generating the modified authentication request), and / or the authentication system 602 may generate a modified authentication response for the payment transaction including the first account identifier (e.g., instead of the second account identifier) ​​based on the identification of the transaction history record. In some non-limiting embodiments or aspects, the authentication system 602 may communicate the modified authentication response, for example, to the acquirer system and / or the payment gateway system (e.g., which originally communicated the authentication request).

[0144] With reference to FIG. 6B, in non-limiting embodiments or aspects, the acquirer system 610 may generate a settlement request message associated with the payment transaction. For example, the settlement request may be generated after a period of time (e.g., a predetermined period of time, a minimum period of time, a selected period of time, and / or the like) after the authorization request message is first communicated. In some non-limiting embodiments or aspects, the settlement request message may include a first account identifier (e.g., a lead account). Additionally or alternatively, the settlement request may include other identifying information associated with the payment transaction, such as a transaction identifier, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like. In some non-limiting embodiments or aspects, the acquirer system 610 may communicate the settlement request message to a settlement system 628.

[0145] In some non-limiting embodiments or aspects, the payment system 628 may receive a payment request message associated with the payment transaction (e.g., from the acquirer system 610). In some non-limiting embodiments or aspects, the payment system 628 and / or the transaction history database 626 may identify a transaction history record based on the payment transaction. For example, the payment system 628 may receive (e.g., obtain, request and receive, and / or the like) a transaction history record from the transaction history database 626, and / or the payment system 628 may receive a second account identifier associated with the transaction history record from the transaction history record from the transaction history database 626.

[0146] In some non-limiting embodiments or aspects, the payment system 628 may generate a modified payment request message. For example, the payment system 628 may generate the modified payment request message based on identifying the transaction history record and / or receiving the second account identifier. In some non-limiting embodiments or aspects, the modified payment request message may include the second account identifier. Additionally or alternatively, the modified payment request may include other identifying information associated with the payment transaction, such as a transaction identifier, a timestamp, a retailer identifier, a retailer account identifier, any combination thereof, and / or the like.

[0147] In some non-limiting embodiments or aspects, the payment system 628 may communicate the modified payment request message to an issuer system associated with the second account identifier (e.g., one of the first issuer system 604a, the second issuer system 604b, and / or the third issuer system 604c, through which one of these issuer systems issued the second account identifier).

[0148] In some non-limiting embodiments or aspects, the payment system 628 may determine that there are no transaction history records associated with the payment transaction stored in the transaction history database 626. In response to such a determination, the payment system 628 may apply a fallback payment rule. For example, the payment system 628 may store and / or receive a fallback payment rule (e.g., from a payment fallback rules database and / or the like).

[0149] In some non-limiting embodiments or aspects, an issuer system (e.g., one of issuer systems 604a, 604b, 604c) may generate a settlement response (e.g., a clearing message and / or the like) based on the modified settlement request message. For example, the settlement response may include the second account identifier.

[0150] In some non-limiting embodiments or aspects, the payment system 628 may receive a settlement response, for example, from the issuer system. In some non-limiting embodiments or aspects, the payment system 628 may generate a modified settlement response, as described herein. For example, the payment system 628 may generate a modified settlement response for the payment transaction, where the modified settlement response may include the first account identifier. For example, as described herein, the payment system 628 may identify a transaction history record stored in the transaction history database 626 associated with the payment transaction (e.g., the transaction history record may indicate that the first account identifier was replaced with the second account identifier upon generation of the modified authorization request), and / or the payment system 628 may generate a modified settlement response for the payment transaction that includes the first account identifier (e.g., instead of the second account identifier) ​​based on the identification of the transaction history record. In some non-limiting embodiments or aspects, the payment system 628 may communicate the modified settlement response, for example, to the acquirer system 610 and / or the payment gateway system (e.g., which originally communicated the settlement request).

[0151] While embodiments have been described in detail for purposes of illustration, it should be understood that such details are for this 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 should 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 computer-implemented method comprising: receiving, with at least one processor, an authentication request message associated with the payment transaction, the authentication request message including a first account identifier associated with a user; determining, with at least one processor, a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier; generating, with at least one processor, a modified authorization request message for the payment transaction, the modified authorization request message including the second account identifier; transmitting, with at least one processor, the modified authentication request message to an issuer system associated with the second account identifier; and storing, with at least one processor, a transaction history record based on the payment transaction and the second account identifier.

2. receiving, with at least one processor, rule data associated with the at least one rule, the rule data including a threshold value; determining, with at least one processor, whether a transaction amount of the payment transaction meets the threshold; The method of claim 1 , wherein determining the second account identifier comprises selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

3. The at least one rule includes a first rule based on rule data received from the user and a fallback rule, and determining the second account identifier includes: determining, with at least one processor, that the first rule is not applicable to the payment transaction associated with the authorization request message; 2. The method of claim 1 , further comprising: in response to determining that the first rule is not applicable, determining, with at least one processor, the second account identifier from the plurality of account identifiers based on the fallback rule.

4. receiving, with at least one processor, a payment request message associated with the payment transaction, the payment request message including the first account identifier; identifying, with at least one processor, the transaction history record based on the payment transaction; generating, with at least one processor, a modified payment request message based on the identification of the transaction history record, the modified payment request message including the second account identifier; 10. The method of claim 1, further comprising: transmitting, with at least one processor, the modified settlement request message to the issuer system associated with the second account identifier.

5. receiving, at at least one processor, a payment request message associated with a second payment transaction, the payment request message including the first account identifier; determining, with at least one processor, that a second transaction history associated with the second payment transaction is not stored; and 10. The method of claim 1, further comprising: in response to determining that the second transaction history is not stored, applying, at the at least one processor, fallback settlement rules.

6. The method of claim 1 , further comprising receiving, at at least one processor, rule data associated with the at least one rule from the issuer system.

7. 2. The method of claim 1 , wherein the first account identifier comprises a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers comprises a plurality of virtual account identifiers associated with the user, and the second account identifier comprises a selected virtual account identifier, and determining the second account identifier comprises selecting the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

8. The method of claim 7 , wherein the lead account identifier comprises a debit account identifier, and the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

9. 1. A system comprising: At least one processor; When executed by the at least one processor, the at least one processor receiving an authentication request message associated with a payment transaction, the authentication request message including a first account identifier associated with a user; determining a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier; generating a modified authorization request message for the payment transaction, the modified authorization request message including the second account identifier; sending the modified authentication request message to an issuer system associated with the second account identifier; and and storing a transaction history record based on the payment transaction and the second account identifier.

10. The instructions, when executed by the at least one processor, cause the at least one processor to: receiving rule data associated with the at least one rule, the rule data including a threshold value; and determining whether a transaction amount of the payment transaction satisfies the threshold; 10. The system of claim 9, wherein determining the second account identifier comprises selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

11. The at least one rule includes a first rule based on rule data received from the user and a fallback rule, and determining the second account identifier includes: determining that the first rule is not applicable to the payment transaction associated with the authorization request message; and in response to determining that the first rule is not applicable, determining the second account identifier from the plurality of account identifiers based on the fallback rule.

12. The instructions, when executed by the at least one processor, cause the at least one processor to: receiving a payment request message associated with the payment transaction, the payment request message including the first account identifier; identifying said transaction history record based on said payment transaction; generating a modified payment request message based on the identification of the transaction history record, the modified payment request message including the second account identifier; and 10. The system of claim 9, further comprising: transmitting the modified payment request message to the issuer system associated with the second account identifier.

13. The instructions, when executed by the at least one processor, cause the at least one processor to: receiving a payment request message associated with a second payment transaction, the payment request message including the first account identifier; determining that a second transaction history associated with the second payment transaction is not stored; and 10. The system of claim 9, further comprising: in response to determining that the second transaction history is not stored, applying a fallback settlement rule.

14. The instructions, when executed by the at least one processor, cause the at least one processor to: The system of claim 9 , further comprising: receiving rules data associated with the at least one rule from the issuer system.

15. 10. The system of claim 9, wherein the first account identifier comprises a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers comprises a plurality of virtual account identifiers associated with the user, and the second account identifier comprises a selected virtual account identifier, and determining the second account identifier comprises selecting the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

16. 16. The system of claim 15, wherein the lead account identifier comprises a debit account identifier and the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

17. When executed by at least one processor, the at least one processor: receiving an authentication request message associated with a payment transaction, the authentication request message including a first account identifier associated with a user; determining a second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier; generating a modified authorization request message for the payment transaction, the modified authorization request message including the second account identifier; sending the modified authentication request message to an issuer system associated with the second account identifier; and storing a transaction history record based on the payment transaction and the second account identifier.

18. The instructions, when executed by the at least one processor, cause the at least one processor to: receiving rule data associated with the at least one rule, the rule data including a threshold value; and determining whether a transaction amount of the payment transaction satisfies the threshold; 20. The computer program product of claim 17, wherein determining the second account identifier comprises selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold.

19. The instructions, when executed by the at least one processor, cause the at least one processor to: receiving a payment request message associated with the payment transaction, the payment request message including the first account identifier; identifying said transaction history record based on said payment transaction; generating a modified payment request message based on the identification of the transaction history record, the modified payment request message including the second account identifier; and 20. The computer program product of claim 17, further comprising: transmitting the modified payment request message to the issuer system associated with the second account identifier.

20. the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, and the second account identifier includes a selected virtual account identifier, and determining the second account identifier includes selecting the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule; 20. The computer program product of claim 17, wherein the lead account identifier comprises a debit account identifier and the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

Images