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

Abstract

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

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 330,987, filed on April 14, 2022, the disclosure of which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to transactional message routing and, in some non-limiting embodiments or aspects, to systems, methods, and computer program products for flexible transactional message routing. Background Art

[0004] Electronic payment processing systems may use account identifiers to initiate and / or settle transactions. For example, a payment transaction may be initiated at a merchant system using a credit card number (e.g., a primary account number (PAN)), and the transaction may be settled later using the same credit card number. 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.

[0005] However, such systems may require the user to physically select different payment devices (or remember to type in account identifiers for different payment devices) in order to conduct different types of transactions using different accounts. Therefore, the user may be required to carry multiple different payment devices and / or memorize different account identifiers. In addition, once a payment transaction is initiated using a certain payment device, these electronic payment processing systems do not allow the user to substitute different accounts and / or different account types (e.g., debit card accounts, credit card accounts, prepaid card accounts, etc.). In addition, these payment processing systems do not allow transactions to be settled using accounts and / or account types that are different from the accounts associated with the payment device used to initiate the transaction. This can cause difficulties in situations where the settlement process of a payment transaction is rejected or blocked for unknown reasons. Summary of the invention

[0006] It is therefore an object of the present disclosure to provide systems, methods, and computer program products for flexible transaction message routing that overcome some or all of the above-identified deficiencies.

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

[0008] In some non-limiting embodiments or aspects, the method may also include receiving, with at least one processor, rule data associated with at least one rule. The rule data may include a threshold. The method may include determining, with 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 a plurality of account identifiers based on the transaction amount satisfying the threshold.

[0009] In some non-limiting embodiments or aspects, the at least one rule may include a first rule based on rule data received from a user and a fallback rule. Determining the second account identifier may include determining, using at least one processor, that the first rule is not applicable to the payment transaction associated with the authorization request message, and determining, using at least one processor, the 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.

[0010] In some non-limiting embodiments or aspects, the method may also include receiving, with 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, with at least one processor, a transaction history record based on the payment transaction. The method may include generating, with at least one processor, a modified settlement request message based on identifying the transaction history record. The modified settlement request message may include a second account identifier. The method may include sending, with at least one processor, the modified settlement request message to an issuer system associated with the second account identifier.

[0011] In some non-limiting embodiments or aspects, the method may also include receiving, with 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, with at least one processor, that a second transaction history associated with the second payment transaction is not stored. The method may include applying, with at least one processor, a fallback settlement rule in response to determining that the second transaction history is not stored.

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

[0013] In some non-limiting embodiments or aspects, the first account identifier may include a primary account identifier associated with a physical payment device associated with the user. The plurality of account identifiers may include a plurality of 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 plurality of virtual account identifiers based on at least one rule.

[0014] In some non-limiting embodiments or aspects, the primary 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.

[0015] According to non-limiting embodiments or aspects, a system for flexible transaction message routing is provided. An example system may include at least one processor and at least one non-transitory computer-readable medium storing instructions. When executed by at least one processor, the instructions may cause the at least one processor to receive an authorization request message associated with a payment transaction. The authorization request message may include a first account identifier associated with a user. When executed by 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 at least one processor, the instructions may cause the at least one processor to generate a modified authorization request message for the payment transaction. The modified authorization request message may include the second account identifier. When executed by at least one processor, the instructions may cause the at least one processor to send the modified authorization request message to an issuer system associated with the second account identifier. When executed by at least one processor, the instructions may cause the at least one processor to store a transaction history based on the payment transaction and the second account identifier.

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

[0017] In some non-limiting embodiments or aspects, at least one rule may include a first rule based on rule data received from a user and a fallback rule. Determining the second account identifier may include determining that the first rule is not applicable to the payment transaction associated with the authorization request message, and / or determining the 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.

[0018] In some non-limiting embodiments or aspects, the instructions, when executed by at least one processor, may also cause the at least one processor to receive a settlement request message associated with a 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 identified 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 send the modified settlement request message to an issuer system associated with the second account identifier.

[0019] In some non-limiting embodiments or aspects, the instructions, when executed by at least one processor, may further cause the at least one processor to receive a settlement request message associated with the 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 the 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.

[0020] 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 from the issuer system.

[0021] In some non-limiting embodiments or aspects, the first account identifier may include a primary account identifier associated with a physical payment device associated with the user. The plurality of account identifiers may include a plurality of 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 plurality of virtual account identifiers based on at least one rule.

[0022] In some non-limiting embodiments or aspects, the primary 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.

[0023] According to some non-limiting embodiments or aspects, a computer program product for flexible transaction message routing is provided. An example computer program product may include at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium including program instructions, which, when executed by at least one processor, causes the at least one processor to receive an authorization request message associated with a payment transaction. The authorization 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 authorization request message for the payment transaction. The modified authorization 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 authorization 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 based on the payment transaction and the second account identifier.

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

[0025] In some non-limiting embodiments or aspects, at least one rule may include a first rule based on rule data received from a user and a fallback rule. Determining the second account identifier may include determining that the first rule is not applicable to the payment transaction associated with the authorization request message, and / or determining the 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.

[0026] In some non-limiting embodiments or aspects, the instructions, when executed by at least one processor, may also cause the at least one processor to receive a settlement request message associated with a 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 identified 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 send the modified settlement request message to an issuer system associated with the second account identifier.

[0027] In some non-limiting embodiments or aspects, the instructions, when executed by at least one processor, may further cause the at least one processor to receive a settlement request message associated with the 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 the 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.

[0028] 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 from the issuer system.

[0029] In some non-limiting embodiments or aspects, the first account identifier may include a primary account identifier associated with a physical payment device associated with the user. The plurality of account identifiers may include a plurality of 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 plurality of virtual account identifiers based on at least one rule.

[0030] In some non-limiting embodiments or aspects, the primary 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.

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

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

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

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

[0035] Clause 4: According to the method described in any one of clauses 1 to 3, the method further includes: using at least one processor to receive a settlement request message associated with a payment transaction, the settlement request message including a first account identifier; using at least one processor to identify a transaction history record based on the payment transaction; using at least one processor to generate a modified settlement request message based on the identified transaction history record, the modified settlement request message including a second account identifier; and using at least one processor to send the modified settlement request message to an issuer system associated with the second account identifier.

[0036] Clause 5: According to the method described in any one of clauses 1 to 4, the method further includes: using at least one processor to receive a settlement request message associated with a second payment transaction, the settlement request message including a first account identifier; using at least one processor to determine that a second transaction history associated with the second payment transaction is not stored; and using at least one processor to apply a fallback settlement rule in response to determining that the second transaction history is not stored.

[0037] Clause 6: The method of any of clauses 1 to 5, further comprising: receiving, with at least one processor, rule data associated with at least one rule from an issuer system.

[0038] Clause 7: A method according to any one of clauses 1 to 6, wherein the first account identifier comprises a primary account identifier associated with a physical payment device associated with the user, wherein the multiple account identifiers comprise multiple virtual account identifiers associated with the user, wherein the second account identifier comprises a selected virtual account identifier, and wherein determining the second account identifier comprises selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0039] Clause 8: The method of any of clauses 1 to 7, wherein the primary account identifier comprises a debit account identifier, and wherein the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

[0040] Clause 9: 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 authorization request message associated with a payment transaction, the authorization 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 authorization request message for the payment transaction, the modified authorization request message including the second account identifier; send the modified authorization 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.

[0041] Clause 10: A system according to 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, wherein the rule data includes a threshold; and determine whether a transaction amount of the payment transaction satisfies the threshold, wherein determining the second account identifier includes selecting the second account identifier from a plurality of account identifiers based on whether the transaction amount satisfies the threshold.

[0042] Clause 11: A system according to clause 9 or clause 10, wherein at least one rule includes a first rule and a fallback rule based on rule data received from a user, wherein 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 determining the second account identifier from a plurality of account identifiers based on the fallback rule in response to determining that the first rule is not applicable.

[0043] Clause 12: A system according to any one of clauses 9 to 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 a payment transaction, the settlement request message including a first account identifier; identify a transaction history record based on the payment transaction; generate a modified settlement request message based on the identified transaction history record, the modified settlement request message including a second account identifier; and send the modified settlement request message to an issuer system associated with the second account identifier.

[0044] Clause 13: A system according to any one of clauses 9 to 12, 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 a second payment transaction, the settlement request message including a first account identifier; determine that a second transaction history associated with the second payment transaction is not stored; and apply a fallback settlement rule in response to determining that the second transaction history is not stored.

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

[0046] Clause 15: A system as described in any of clauses 9 to 14, wherein the first account identifier comprises a primary account identifier associated with a physical payment device associated with a user, wherein the multiple account identifiers include multiple virtual account identifiers associated with the user, wherein the second account identifier comprises a selected virtual account identifier, and wherein determining the second account identifier comprises selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0047] Clause 16: The system of any of clauses 9 to 15, wherein the primary account identifier comprises a debit account identifier, and wherein the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

[0048] Clause 17: A computer program product comprising at least one non-transitory computer-readable medium, the 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 authorization request message associated with a payment transaction, the authorization request message comprising 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 authorization request message for the payment transaction, the modified authorization request message comprising the second account identifier; send the modified authorization 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.

[0049] Clause 18: A computer program product according to 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, wherein the rule data includes a threshold; and determine whether a transaction amount of the payment transaction satisfies the threshold, wherein determining the second account identifier includes selecting the second account identifier from a plurality of account identifiers based on whether the transaction amount satisfies the threshold.

[0050] Clause 19: A computer program product according to clause 17 or clause 18, wherein at least one rule includes a first rule and a fallback rule based on rule data received from a user, wherein 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 determining the second account identifier from a plurality of account identifiers based on the fallback rule in response to determining that the first rule is not applicable.

[0051] Clause 20: A computer program product according to any one of clauses 17 to 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 a payment transaction, the settlement request message including a first account identifier; identify a transaction history record based on the payment transaction; generate a modified settlement request message based on the identified transaction history record, the modified settlement request message including a second account identifier; and send the modified settlement request message to an issuer system associated with the second account identifier.

[0052] Clause 21: A computer program product according to any one of clauses 17 to 20, 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 a second payment transaction, the settlement request message including a first account identifier; determine that a second transaction history associated with the second payment transaction is not stored; and apply a fallback settlement rule in response to determining that the second transaction history is not stored.

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

[0054] Clause 23: A computer program product according to any one of clauses 17 to 22, wherein the first account identifier comprises a primary account identifier associated with a physical payment device associated with a user, wherein the multiple account identifiers comprise multiple virtual account identifiers associated with the user, wherein the second account identifier comprises a selected virtual account identifier, and wherein determining the second account identifier comprises selecting the selected virtual account identifier from the multiple virtual account identifiers based on at least one rule.

[0055] Clause 24: The computer program product of any of clauses 17 to 23, wherein the primary account identifier comprises a debit account identifier, and wherein the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

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

[0057] Additional advantages and details are explained in more detail below with reference to non-limiting exemplary embodiments shown in the schematic drawings, in which:

[0058] Figure 1 is a schematic diagram of a system for flexible transaction message routing according to some non-limiting embodiments or aspects;

[0059] Figure 2 is a flow chart of a method for flexible transaction message routing according to some non-limiting embodiments or aspects;

[0060] Figure 3 is a diagram of an exemplary environment in which methods, systems, and / or computer program products described herein may be implemented according to some non-limiting embodiments or aspects;

[0061] Figure 4 According to some non-limiting embodiments or aspects Figure 1 and / or Figure 3 schematic diagrams of example components of one or more devices;

[0062] Figure 5A and Figure 5B is a schematic diagram of an implementation of a system and method for flexible transaction message routing according to some non-limiting embodiments or aspects; and

[0063] Fig. 6A and Figure 6B is a schematic diagram of an implementation of a system and method for flexible transaction message routing according to some non-limiting embodiments or aspects. DETAILED DESCRIPTION

[0064] For the purposes of the following description, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives shall relate to the orientation of the embodiments in the accompanying drawings. However, it shall be understood that the embodiments may employ various alternative variations and step sequences, except where expressly specified to the contrary. It shall also 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. Accordingly, specific dimensions and other physical characteristics relating to the embodiments or aspects disclosed herein shall not be considered limiting.

[0065] The aspects, parts, elements, structures, actions, steps, functions, instructions, etc. used herein should not be understood as critical or necessary unless explicitly described as such. Moreover, as used herein, the article "one" is intended to include one or more items, and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, and / or the like), and can be used interchangeably with "one or more" or "at least one". In the case of intending to have only one item, the term "one" or similar language is used. Moreover, as used herein, the term "having" and / or the like is intended to be an open term. In addition, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on".

[0066] As used herein, the term "acquirer institution" may refer to an entity that is 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 may be initiated by an acquirer institution may include payment transactions (e.g., purchases, original letter of credit transactions (OCTs), account funding transactions (AFTs), and / or the like). In some non-limiting embodiments or aspects, the acquirer institution may be a financial institution, such as a bank. As used herein, the term "acquirer system" may refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer executing one or more software applications.

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

[0068] As used herein, the term "communication" may refer to the reception, acceptance, transmission, transfer, provision, etc. of data (e.g., information, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, and / or the like) communicating with another unit means that the unit is able to directly or indirectly receive information from the other unit and / or send information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. In addition, although the information sent may be modified, processed, relayed, and / or routed between the first unit and the second unit, the two units may also communicate with each other. For example, even if the first unit passively receives information and does not actively send information to the second unit, the first unit may communicate with the second unit. As another example, if at least one intermediate unit processes the information received from the first unit and transmits the processed information to the second unit, the first unit may communicate with the second unit.

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

[0070] As used herein, the terms "electronic wallet" and "electronic wallet application" refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device executing an electronic wallet application, and may also include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An "electronic wallet provider" may include an entity that provides and / or maintains electronic wallets for customers, such as Google Android Apple Samsung And / or other similar electronic payment systems. In some non-limiting examples, the issuing bank may be an electronic wallet provider.

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

[0072] As used herein, the term "merchant" may refer to a person or entity that provides goods and / or services or access to goods and / or services to a customer based on a transaction, such as a payment transaction. The term "merchant" or "merchant system" may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer that executes 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 merchant to conduct 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-based receivers, payment terminals, computers, servers, input devices, and / or other similar devices that can be used to initiate payment transactions.

[0073] As used herein, the term "payment device" may refer to a payment card (e.g., a credit or debit card), a gift card, a smart card, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a key chain device or fob, an RFID transponder, a retailer discount or membership card, a cellular telephone, 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, etc. In some non-limiting embodiments or aspects, a payment device may include volatile or non-volatile memory to store information (e.g., an account identifier, an account holder's name, etc.).

[0074] As used herein, the term "payment gateway" may refer to an entity and / or a payment processing system operated by or on behalf of such an entity that provides payment services (e.g., transaction service provider payment services, payment processing services, and / or the like) to one or more merchants (e.g., transaction service provider payment services, payment processing services, and / or the like). The payment services may be associated with the use of a portable financial device managed by a transaction service provider. As used herein, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, server groups, etc. operated by or on behalf of a payment gateway.

[0075] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communications and processing by multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and that there may be various other arrangements. In addition, multiple computing devices (e.g., servers, point of sale (POS) devices, mobile devices, etc.) that communicate directly or indirectly in a network environment may constitute a "system." As used herein, references to "servers" or "processors" may refer to previously described servers and / or processors, different servers and / or processors, and / or combinations of servers and / or processors that are stated to perform previous steps or functions. For example, as used in the specification and claims, a first server and / or first processor stated to perform a first step or function may refer to the same or different servers and / or processors stated to perform a second step or function.

[0076] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment assurance through an agreement between the transaction service provider and the issuer organization. For example, a transaction service provider may include, e.g. 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 executes 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.

[0077] Non-limiting embodiments or aspects of the disclosed subject matter relate 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 associated with a user (e.g., an identifier of a flexible account). A second account identifier (e.g., an identifier of an account distinguished from the flexible account) may be determined from a plurality of account identifiers. The determination may be made via a rule. The rule may be set or preset by the user. After such determination, a modified authorization request message for the payment transaction may be generated, wherein the modified authorization request message already includes the second account identifier. The modified authorization request message may be sent to other systems, such as issuer systems, for further processing. Then, a transaction history record may be stored based on the payment transaction involving the first account identifier and the second account identifier. After the transaction has been authorized, 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 the second account identifier. The modified settlement request message may then be sent to other systems, such as issuer systems, for further processing. Thus, the disclosed subject matter enables one or more transactions to be initiated using a single account identifier (e.g., of a flexible account) and having different accounts and / or account types used to authorize and then 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 needing to carry and / or type in a single account identifier. Additionally, the disclosed subject matter enables a user to set custom rules for selecting which account and / or account type to use for different transactions (e.g., based on customizable criteria). Additionally, the disclosed subject matter ensures that the same account as used for authorization of the transaction is used for settlement of the transaction, even if the (second) account identifier used to complete the authorization is different from the (first) account identifier in the settlement message due to storage of the transaction history.

[0078] Figure 1 A system 100 for flexible transaction message routing is depicted in accordance with a non-limiting embodiment or aspect. System 100 may include an authorization system 102, an authorization rules database 104, a transaction history database 106, a settlement system 108, and / or a settlement rules database 110.

[0079] The authorization system 102 may include one or more devices capable of receiving information from and / or transmitting information to the authorization rules database 104, the transaction history database 106, the acquirer system, the payment gateway system, and / or the issuer system. For example, the authorization 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 authorization system 102 may, for example, receive an authorization request from an acquirer system and / or a payment gateway system, as described herein. Additionally or alternatively, the authorization system 102 may transmit the authorization request, for example, to an issuer system, as described herein. In some non-limiting embodiments or aspects, the authorization system 102 may, for example, receive an authorization response from an issuer system, as described herein. Additionally or alternatively, the authorization system 102 may transmit the authorization response, for example, to an acquirer system and / or a payment gateway system, as described herein.

[0080] The authorization rules database 104 may include one or more devices capable of receiving information from and / or transmitting information to the authorization system 102, the issuer system, and / or the client device. For example, the authorization rules 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 authorization rules database 104 may communicate with a data storage device, which may be local or remote to the authorization rules database 104. In some non-limiting embodiments or aspects, the authorization rules database 104 may receive information from the data storage device, store information in the data storage device, transmit information to the data storage device, or search for information stored in the data storage device.

[0081] The transaction history database 106 may include one or more devices capable of receiving information from and / or transmitting information to the authorization system 102 and / or the settlement system 108. For example, the transaction history database 106 may include a computing device, such as a computer, a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction history database 106 may communicate with a data storage device, which may be local or remote to the transaction history database 106. In some non-limiting embodiments or aspects, the transaction history database 106 may be capable of receiving information from the data storage device, storing information in the data storage device, transmitting information to the data storage device, or searching for information stored in the data storage device.

[0082] The settlement system 108 may include one or more devices capable of receiving information from and / or transmitting information to the transaction history database 106, the settlement rules database 110, the acquirer system, the payment gateway system, and / or the issuer system. For example, the settlement system 108 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 settlement system 108 may, for example, receive a settlement request from an acquirer system and / or a payment gateway system, as described herein. Additionally or alternatively, the settlement system 108 may transmit the settlement request, for example, to the issuer system, as described herein. In some non-limiting embodiments or aspects, the settlement system 108 may, for example, receive a settlement response from the issuer system, as described herein. Additionally or alternatively, the settlement system 108 may transmit the settlement response, for example, to the acquirer system and / or the payment gateway system, as described herein.

[0083] The settlement rules database 110 may include one or more devices capable of receiving information from and / or transmitting information to the settlement system 108. For example, the settlement rules database 110 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 settlement rules database 110 may communicate with a data storage device, which may be local or remote to the settlement rules database 110. In some non-limiting embodiments or aspects, the settlement rules database 110 may be capable of receiving information from the data storage device, storing information in the data storage device, transmitting information to the data storage device, or searching for information stored in the data storage device.

[0084] Figure 1 The number and arrangement of the systems and devices shown in the FIG. are provided as examples. Figure 1 There may be additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, and / or systems and / or devices arranged in a different manner than the systems and / or devices shown in the drawings. Furthermore, a single system and / or device may be implemented Figure 1 Two or more systems or devices shown in Figure 1 The single system or device shown in the embodiment may be implemented as multiple distributed systems or devices. Additionally or alternatively, a group of systems (e.g., one or more systems) and / or a group of devices (e.g., one or more devices) of system 100 may perform one or more functions described as being performed by another group of systems or another group of devices of system 100.

[0085] Reference now Figure 2, illustrates a process 200 for flexible transaction message routing according to some non-limiting embodiments or aspects. Figure 2 The steps shown in are for example purposes only. It will be appreciated that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects.

[0086] like Figure 2 As shown, at step 202, process 200 includes receiving an authorization request message. In some non-limiting embodiments or aspects, system 100 (e.g., its authorization system 102) can receive an authorization request message associated with a payment transaction between a user and a merchant. For example, the authorization system 102 can receive an authorization request message associated with a payment transaction between a user and a merchant. The authorization 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 flexible account), which 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, the authorization system 102 may receive an authorization request message from an acquirer system, as described herein. In some non-limiting embodiments or aspects, the authorization request may include other identification information associated with the payment transaction, such as a transaction identifier, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, etc.

[0087] In some non-limiting embodiments or aspects, the first account identifier may include a primary account identifier associated with a physical payment device associated with the user. Additionally or alternatively, the plurality of account identifiers may include a plurality of virtual account identifiers associated with the user (e.g., in addition to or in lieu of a primary account number). For example, the primary account identifier may include a debit account identifier (e.g., a debit account number), and the plurality of 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).

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

[0089] In some non-limiting embodiments or aspects, the authorization system 102 may receive rule data associated with at least one rule. For example, the authorization system 102 may receive rule data associated with at least one rule from the authorization rules database 104. The rule data associated with at least one rule may include a threshold. For example, the authorization system 102 and / or the authorization rules database 104 may determine whether the transaction amount of the payment transaction (e.g., associated with the authorization request) meets the threshold. The authorization system 102 and / or the authorization rules database 104 may identify (e.g., select) a second account identifier (e.g., from a plurality of account identifiers associated with the first account identifier and / or the user) in response to determining that the payment transaction meets the threshold. Additionally or alternatively, the authorization system 102 and / or the authorization rules 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 threshold.

[0090] In some non-limiting embodiments or aspects, the rule data associated with at least one rule may include at least one classification criterion. For example, the authorization system 102 and / or the authorization rules 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 authorization system 102 and / or the authorization rules database 104 may determine whether the payment transaction is a cross-border transaction. The authorization system 102 and / or the authorization rules database 104 may identify (e.g., select) a second account identifier (e.g., from a plurality of account identifiers associated with the first account identifier and / or the user) in response to determining that the payment transaction meets the classification criteria (e.g., is a cross-border transaction). Additionally or alternatively, the authorization system 102 and / or the authorization rules 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 classification criteria (e.g., is not a cross-border transaction). As another illustration, if the selected category is an e-commerce transaction, the authorization system 102 and / or the authorization rules database 104 may determine whether the payment transaction is an e-commerce transaction. The authorization system 102 and / or the authorization rules database 104 may identify (e.g., select) a second account identifier (e.g., from a plurality of account identifiers associated with the first account identifier and / or the user) in response to determining that the payment transaction satisfies the classification criteria (e.g., is an e-commerce transaction). Additionally or alternatively, the authorization system 102 and / or the authorization rules 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 satisfy the classification criteria (e.g., is not an e-commerce transaction). In some non-limiting embodiments or aspects, the classification criteria may be combined with at least one other classification criteria and / or at least one threshold value to create a complex rule (e.g., if the payment transaction is a cross-border transaction and an e-commerce transaction, then the second account identifier is selected, otherwise the third account identifier is selected).

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

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

[0093] In some non-limiting embodiments or aspects, the first account identifier may include a primary 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 in place of the primary account number). For example, the primary 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 a selected virtual account identifier from a plurality of virtual account identifiers based on at least one rule.

[0094] like Figure 2 As shown, at step 206, process 200 may include generating a modified authorization request message. In some non-limiting embodiments or aspects, system 100 (e.g., authorization system 102 thereof) may generate a modified authorization request message for a payment transaction, and the modified authorization request message may include a second account identifier. For example, authorization system 102 may generate a modified authorization request message for a payment transaction that includes a second account identifier (e.g., in place of a first account identifier). In some non-limiting embodiments or aspects, the modified authorization request may include other identification information associated with the payment transaction (e.g., from the authorization request), such as a transaction identifier, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, and the like.

[0095] like Figure 2 As shown, at step 208, process 200 may include sending a modified authorization request message. For example, system 100 (e.g., authorization system 102 thereof) may send the modified authorization request message to an issuer system associated with the second account identifier. The issuer system may process the modified authorization request message in response to receiving the modified authorization request message (e.g., determine whether to authorize the payment transaction based on the modified authorization request message, etc.), as described herein.

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

[0097] In some non-limiting embodiments or aspects, the issuer system may determine whether to authorize the payment transaction based on the modified authorization request message. For example, the issuer system may generate an authorization decision (e.g., authorization, rejection, etc.) based on the modified authorization request message. For illustrative purposes, 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 authorization 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 and / or available credit for the payment transaction (e.g., based on the transaction amount in the modified authorization request) and / or if some 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., reject, deny, etc.) the transaction. In some non-limiting embodiments or aspects, the issuer system may generate an authorization response based on determining whether to authorize the payment transaction (e.g., based on the authorization decision). For example, the authorization response may include the second account identifier.

[0098] In some non-limiting embodiments or aspects, the system 100 (e.g., the authorization system 102 thereof) may receive an authorization response, for example, from an issuer system. In some non-limiting embodiments or aspects, the system 100 (e.g., the authorization system 102 thereof) may generate a modified authorization response. For example, the authorization system 102 may generate a modified authorization response for the payment transaction, and the modified authorization response may include the first account identifier. For example, the authorization system 102 may identify a transaction history associated with the payment transaction (e.g., the transaction history may indicate that the second account identifier replaced the first account identifier when the modified authorization request was generated), and / or the authorization system 102 may generate a modified authorization response for the payment transaction including the first account identifier (e.g., in place of the second account identifier) ​​based on the identification of the transaction history. In some non-limiting embodiments or aspects, the authorization system 102 may transmit the modified authorization response, for example, to an acquirer system and / or a payment gateway system (e.g., the payment gateway system that originally transmitted the authorization request).

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

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

[0101] In some non-limiting embodiments or aspects, the settlement 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 settlement system 108 may identify a fallback rule associated with the first account identifier.

[0102] like Figure 2 As shown, at step 216, process 200 may include generating a modified settlement request message. In some non-limiting embodiments or aspects, system 100 (e.g., settlement system 108 thereof) may generate a modified settlement request message. For example, settlement system 108 may generate a modified settlement request message based on identifying transaction history records, and the modified settlement request message may include a second account identifier (e.g., in place of the first account identifier). Additionally or alternatively, if no transaction history records exist, settlement system 108 may generate a modified settlement request message based on a fallback settlement rule, as described herein.

[0103] In some non-limiting embodiments or aspects, the modified settlement request message may include other identification information associated with the payment transaction (e.g., from the settlement request message), such as a transaction identifier, a retrieval reference number, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, and the like.

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

[0105] In some non-limiting embodiments or aspects, the issuer system may generate a settlement response (e.g., a clearing message, etc.) 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 identification information associated with the payment transaction (e.g., from the settlement request message), such as a transaction identifier, a retrieval reference number, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, etc.

[0106] In some non-limiting embodiments or aspects, the system 100 (e.g., the settlement system 108 thereof) may receive a settlement response, for example, from an issuer system. In some non-limiting embodiments or aspects, the system 100 (e.g., the settlement system 108 thereof) may generate a modified settlement response. For example, the settlement system 108 may generate a modified settlement response for the payment transaction, and the modified settlement response may include the first account identifier. For example, the settlement system 108 may identify a transaction history associated with the payment transaction (e.g., the transaction history may indicate that the second account identifier replaced the first account identifier when the modified authorization request was generated), and / or the settlement system 108 may generate a modified settlement response for the payment transaction including the first account identifier (e.g., in place of the second account identifier) ​​based on the identification of the transaction history. In some non-limiting embodiments or aspects, the settlement system 108 may transmit the modified settlement response, for example, to an acquirer system and / or a payment gateway system (e.g., the payment gateway system that originally transmitted the settlement request).

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

[0108] The transaction service provider system 302 may include one or more devices capable of receiving information from and / or transmitting information to the issuer system 304, the client device 306, the merchant system 308, and / or the acquirer system 310 via a communication network 312. For example, the transaction service provider system 302 may include a computing device, such as a server (e.g., a transaction processing server, etc.), 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 described herein. In some non-limiting embodiments or aspects, the transaction service provider system 302 may communicate with a data storage device, which 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 the data storage device, store information in the data storage device, transmit information to the data storage device, or search for information stored in the data storage device.

[0109] The issuer system 304 may include one or more devices capable of receiving information from and / or transmitting information to the transaction service provider system 302, the client device 306, the merchant system 308, and / or the acquirer system 310 via a communication network 312. For example, the issuer system 304 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 issuer system 304 may be associated with an issuer organization described herein. For example, the issuer system 304 may be associated with an issuer organization that issues credit accounts, debit accounts, credit cards, debit cards, and / or the like to users associated with the client device 306.

[0110] The client devices 306 may include one or more devices capable of receiving information from and / or transmitting information to the transaction service provider system 302, the issuer system 304, the merchant system 308, and / or the acquirer system 310 via a communication network 312. Additionally or alternatively, each client device 306 may include a device capable of receiving information from and / or transmitting information to other client devices 306 via the communication network 312, another network (e.g., a temporary network, a local network, a private network, a virtual private network, and / or the like), and / or any other suitable communication technology. For example, a client device 306 may include a client device and / or the like. In some non-limiting embodiments or aspects, the client device 306 may or may not be capable of communicating via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, Communication connection, The client device 306 may receive information via a short-range wireless communication connection (eg, from a merchant system 308 or from another client device 306 ) and / or transmit information via a short-range wireless communication connection (eg, to a merchant system 308 ).

[0111] The merchant system 308 may include one or more devices capable of receiving information from and / or transmitting information to the transaction service provider system 302, the issuer system 304, the client device 306, and / or the acquirer system 310 via the communication network 312. The merchant system 308 may also include a communication connection (e.g., an NFC communication connection, an RFID communication connection, a NFC communication connection, a ... Communication connection, In some non-limiting embodiments or aspects, the merchant system 308 may include a computing device, 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 merchant system 308 may be associated with the merchant described herein. In some non-limiting embodiments or aspects, the merchant system 308 may include one or more client devices. For example, the merchant system 308 may include a client device that allows the merchant to transmit information to the transaction service provider system 302. In some non-limiting embodiments or aspects, the merchant system 308 may include one or more devices that can be used by merchants to conduct transactions with users, such as computers, computer systems, and / or peripheral devices. For example, the merchant system 308 may include a POS device and / or a POS system.

[0112] Acquirer system 310 may include one or more devices capable of receiving information from and / or transmitting information to transaction service provider system 302, issuer system 304, client device 306, and / or merchant system 308 via communication network 312. For example, acquirer system 310 may include a computing device, a server, a server group, and / or the like. In some non-limiting embodiments or aspects, acquirer system 310 may be associated with an acquirer as described herein.

[0113] The communication network 312 may include one or more wired and / or wireless networks. For example, the communication 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, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., 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-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0114] Provided as an example Figure 3 The number and arrangement of systems, devices, and / or networks shown are not intended to be construed as limiting the number and arrangement of systems, devices, and / or networks shown. Additional systems, devices, and / or networks may exist; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or networks in a manner similar to that shown. Figure 3 The systems, devices and / or networks shown in the figure may be arranged in different ways. In addition, the system or device may be implemented in a single system or device. Figure 3 Two or more systems or devices shown, or Figure 3 The single system or device shown may be implemented as multiple distributed systems or devices. Additionally or alternatively, a set of systems (e.g., one or more systems) and / or a set of devices (e.g., one or more devices) of 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.

[0115] Reference now Figure 4 , a diagram showing example components of an apparatus 400 according to a non-limiting embodiment or aspect. As an example, the apparatus 400 may correspond to Figure 1 At least one of the system 100, the authorization system 102, the authorization rules database 104, the transaction history database 106, the settlement system 108 and / or the settlement rules database 110 and / or Figure 3 At least one of the transaction service provider system 302, the issuer system 304, the client device 306, the merchant system 308 and / or the acquirer system 310 in the transaction. In some non-limiting embodiments or aspects, Figure 1 or Figure 3 Such a system or device in may include at least one device 400 and / or at least one component of a device 400. Figure 4 The number and arrangement of the components shown in FIG. are provided as examples. In some non-limiting embodiments or aspects, Figure 4 Compared to those shown in , device 400 may include additional components, fewer components, different components, or components arranged in a different manner. Additionally or alternatively, a group of components (e.g., one or more components) of device 400 may perform one or more functions described as being performed by another group of components of device 400.

[0116] like Figure 4As shown, 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 permit communication between 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 that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.). 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., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 404.

[0117] Continue to refer Figure 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 a component that allows the device 400 to receive information, for example, through user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). In addition or alternatively, the input component 410 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). The output component 412 may include a component that provides 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 a transceiver-like component (e.g., a transceiver, a separate receiver and a transmitter, etc.) that enables the device 400 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 414 may allow 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, interface, cellular network interface, and / or the like.

[0118] Device 400 can perform one or more processes described herein. Device 400 can perform these processes based on processor 404 executing software instructions stored by computer-readable media such as memory 406 and / or storage component 408. Computer-readable media can include any non-transient memory device. The memory device includes a memory space located inside a single physical storage device or a memory space spread over multiple physical storage devices. Software instructions can be read from another computer-readable medium or from another device to memory 406 and / or storage component 408 through communication interface 414. When executed, the software instructions stored in memory 406 and / or storage component 408 can enable processor 404 to perform one or more processes described herein. In addition or alternatively, hard-wired circuit systems can be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any specific combination of hardware circuit systems and software. The term "programmed or configured" used herein refers to the arrangement of software, hardware circuit systems, or any combination thereof on one or more devices.

[0119] Reference now Figure 5A and Figure 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. Figure 5A and Figure 5BAs shown, implementation 500 may include issuer system 504, user 506, merchant system 508, acquirer system 510, authorization system 522, transaction control database 524, authorization fallback rules database 524a, transaction history database 526, settlement system 528, and / or settlement fallback rules database 530. In some non-limiting embodiments or aspects, issuer system 504 may be the same or similar to issuer system 304. In some non-limiting embodiments or aspects, user 506 may be the same or similar to client device 306. In some non-limiting embodiments or aspects, merchant system 508 may be the same or similar to merchant system 308. In some non-limiting embodiments or aspects, acquirer system 510 may be the same or similar to acquirer system 310. In some non-limiting embodiments or aspects, authorization system 522 may be the same, similar, or a part of authorization system 102 and / or transaction service provider system 302. In some non-limiting embodiments or aspects, the transaction control database 524 may be the same as or similar to the authorization rules database 104 and / or the transaction service provider system 302. In some non-limiting embodiments or aspects, the authorization fallback rules database 524a may be the same as, similar to, or a part of the authorization 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.

[0120] refer to Figure 5A In some non-limiting embodiments or aspects, user 506 may transmit and / or set (e.g., configure, input, etc.) rule data associated with at least one rule. For example, user 506 may transmit the rule data to issuer system 504 and / or transaction control database 524 (e.g., using a computing device, such as client device 306, etc.). For example, user 506 may input the rule data associated with at least one rule using an application (e.g., a mobile application) associated with issuer system 504 and / or transaction control database 524 on a computing device (e.g., client device 306, etc.).

[0121] In some non-limiting embodiments or aspects, the issuer system 504 may receive the rule data (e.g., from the user 506). Additionally or alternatively, the issuer system 504 may transmit the rule data to the transaction control database 524, which may receive the rule data, as described herein. For example, the issuer system 504 may use an application programming interface (API) to transmit the rule data to the transaction control database 524. The API may be provided by the transaction control database 524 and / or by a transaction service provider system (e.g., the transaction service provider system 302, etc.). In some non-limiting embodiments or aspects, the rule data may include a first account identifier (e.g., a primary account identifier (PAN 1), etc.) 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, etc.). 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, etc.). In some non-limiting embodiments or aspects, transaction control database 524 may store rule data and / or communicate rule data to authorization system 522 .

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

[0123] In some non-limiting embodiments or aspects, the rule 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 rule(s). Additionally or alternatively, the authorization fallback rules database 524a may store the fallback rule(s).

[0124] refer to Figure 5BIn some non-limiting embodiments or aspects, user 506 can initiate a payment transaction with merchant system 508. For example, user 506 can use a physical payment device associated with a first account identifier (e.g., primary PAN (PAN 1)) to initiate a payment transaction with a POS device of merchant system 508. Additionally or alternatively, user 506 can use a computing device (e.g., client device 306, etc.) to initiate a payment transaction with merchant system 508 using a first account identifier (e.g., primary PAN (PAN 1) or token (Token 1)).

[0125] In some non-limiting embodiments or aspects, merchant system 508 can generate an authorization request message associated with a payment transaction. For example, the authorization request message can include a first account identifier (e.g., primary PAN (PAN 1)). Merchant system 508 can transmit the authorization request to acquirer system 510 (and / or payment gateway), which can transmit the authorization request to authorization system 522.

[0126] In some non-limiting embodiments or aspects, the authorization system 522 may receive the authorization request. Additionally or alternatively, the authorization system 522 may determine the 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), etc.) from a plurality of account identifiers based on at least one rule associated with the first account identifier (e.g., a primary PAN (PAN 1)). For example, the authorization system 522 may receive (e.g., retrieve, access, read, etc.) rule data from the transaction control database 524. Additionally or alternatively, the authorization system 522 may determine the second account identifier based on the rule data.

[0127] 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). Authorization system 522 may determine whether a transaction amount of a payment transaction (e.g., which may be part of an authorization request) satisfies 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 satisfying the threshold value(s).

[0128] 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 authorization fallback rule database 524a). Determining the second account identifier may include the authorization system 522 determining that the first rule is not applicable to the payment transaction associated with the authorization request message. In response to determining that the first rule is not applicable, the authorization system 522 may determine the second account identifier from the plurality of account identifiers based on the fallback rule.

[0129] In some non-limiting embodiments or aspects, the authorization 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), etc.). 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 being utilized). In some non-limiting embodiments or aspects, the authorization 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 authorization system 522 may store a transaction history record in a transaction history database 526 based on the payment transaction and / or the second account identifier.

[0130] In some non-limiting embodiments or aspects, the issuer system 504 may determine whether to authorize the payment transaction based on the modified authorization request message, as described herein. For example, the issuer system 504 may generate an authorization decision (e.g., authorization, rejection, etc.) based on the modified authorization request message, as described herein. In some non-limiting embodiments or aspects, the issuer system 504 may generate an authorization response based on determining whether to authorize the payment transaction (e.g., based on the authorization decision), as described herein. For example, the authorization response may include the second account identifier.

[0131] In some non-limiting embodiments or aspects, the authorization system 522 may receive an authorization response, for example, from the issuer system 504. In some non-limiting embodiments or aspects, the authorization system 522 may generate a modified authorization response, as described herein. For example, the authorization system 522 may identify a transaction history record associated with the payment transaction stored in the transaction history database 526 (e.g., the transaction history record may indicate that the second account identifier replaced the first account identifier when the modified authorization request was generated), and / or the authorization system 522 may generate a modified authorization response for the payment transaction including the first account identifier (e.g., in place of the second account identifier) ​​based on the identified transaction history record. In some non-limiting embodiments or aspects, the authorization system 522 may transmit the modified authorization response, for example, to an acquirer system and / or a payment gateway system (e.g., the payment gateway system that originally transmitted the authorization request).

[0132] 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 time period (e.g., a predetermined time period, a minimum time period, a selected time period, etc.) after the initial transmission of the authorization request message. In some non-limiting embodiments or aspects, the settlement request message may include a first account identifier (e.g., primary PAN (PAN 1) and / or token (Token 1)). Additionally or alternatively, the settlement request may include other identification information associated with the payment transaction, such as a transaction identifier, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, etc. In some non-limiting embodiments or aspects, the acquirer system 510 may transmit the settlement request message to the settlement system 528.

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

[0134] In some non-limiting embodiments or aspects, the settlement system 528 may generate a modified settlement request message. For example, the settlement system 528 may generate a modified settlement 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 settlement request message may include the second account identifier. Additionally or alternatively, the modified settlement request may include other identification information associated with the payment transaction, such as a transaction identifier, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, and the like.

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

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

[0137] In some non-limiting embodiments or aspects, the issuer system 504 can generate a settlement response (eg, a clearing message, etc.) based on the modified settlement request message. For example, the settlement response can include the second account identifier.

[0138] In some non-limiting embodiments or aspects, the settlement system 528 may receive a settlement response, for example, from the issuer system 504. In some non-limiting embodiments or aspects, the settlement system 528 may generate a modified settlement response, as described herein. For example, the settlement system 528 may generate a modified settlement response for the payment transaction, and the modified settlement response may include the first account identifier. For example, the settlement system 528 may identify a transaction history associated with the payment transaction stored in the transaction history database 526 (e.g., the transaction history may indicate that the second account identifier replaced the first account identifier when the modified authorization request was generated), and / or the settlement system 528 may generate a modified settlement response for the payment transaction including the first account identifier (e.g., replacing the second account identifier) ​​based on the identified transaction history, as described herein. In some non-limiting embodiments or aspects, the settlement system 528 may transmit the modified settlement response, for example, to the acquirer system 510 and / or the payment gateway system (e.g., the payment gateway system that originally transmitted the settlement request).

[0139] Reference now Fig. 6A and Figure 6B, a schematic diagram of an implementation 600 of a system and method for flexible transaction message routing according to some non-limiting embodiments or aspects is shown. Fig. 6A and Figure 6B As shown, the embodiment 600 may include at least one issuer system 604a, 604b, 604c, a user 606, a merchant system 608, an acquirer system 610, an authorization 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(s) 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 client device 306. In some non-limiting embodiments or aspects, the merchant system 608 may be the same as or similar to the merchant 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 authorization system 622 may be the same as, similar to, or a part of the authorization 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 or similar to the authorization 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, similar, 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 628 may be the same, similar, or a 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., a debit system, a credit system, and a prepaid system of the same issuer system) and / or 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, each associated with a separate issuer.

[0140] refer to Fig. 6AIn some non-limiting embodiments or aspects, user 606 may transmit and / or set (e.g., configure, input, etc.) rule data associated with at least one rule. For example, user 606 may transmit the rule data to an issuer system (e.g., at least one of issuer systems 604a, 604b, 604c) and / or transaction control database 624 (e.g., using a computing device, such as client device 306, etc.). For example, user 606 may input the rule data associated with at least one rule using an application (e.g., a mobile application) associated with the issuer system and / or transaction control database 624 on a computing device (e.g., client device 306, etc.).

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

[0142] In some non-limiting embodiments or aspects, the transaction control database 624 may receive rule data, as described herein. In some non-limiting embodiments or aspects, the rule data may include a first account identifier (e.g., a primary 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, etc.). Additionally or alternatively, the rule data may include data representing each rule in a specified format (e.g., a customer rule). Additionally or alternatively, the rule data may include a rule identification number (e.g., a rule number) for each rule, an account type associated with each rule (e.g., prepaid, credit, debit, etc.), any combination thereof, etc. 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 rule data and / or transmit the rule data to the authorization system 622.

[0143] In some non-limiting embodiments or aspects, user 606 can initiate a payment transaction using merchant system 608. For example, user 606 can use a physical payment device associated with a first account identifier (e.g., a primary account) to initiate a payment transaction with a POS device of merchant system 608. Additionally or alternatively, user 606 can use a computing device (e.g., client device 306, etc.) to initiate a payment transaction with merchant system 608 using a first account identifier (e.g., a primary account).

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

[0145] In some non-limiting embodiments or aspects, the authorization system 622 may receive the authorization request. Additionally or alternatively, the authorization system 622 may determine the second account identifier (e.g., one of the customer funding options) from the plurality of account identifiers based on at least one rule stored in the transaction control database 624. For example, the authorization system 622 may receive (e.g., retrieve, access, read, etc.) rule data from the transaction control database 624. Additionally or alternatively, the authorization system 622 may determine the second account identifier based on the rule data.

[0146] 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). Fig. 6A As shown, a first rule (T1) can be associated with a transaction amount that is less than a first threshold of 500 yen (e.g., amount < ¥500), a second rule (T2) can be associated with a transaction amount that is greater than a second threshold of 50,000 yen (e.g., amount > ¥50,000), and a third rule (T4) can be associated with a transaction amount between the first threshold and the second threshold (e.g., between ¥500 and ¥50,000). The authorization system 622 can determine whether a transaction amount of a payment transaction (e.g., which can be part of an authorization request) satisfies one of these thresholds. For example, determining the second account identifier can include selecting the second account identifier from a plurality of account identifiers (e.g., a customer funds selection associated with each rule) based on the transaction amount satisfying a threshold (multiple) of one of the rules.

[0147] 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 authorization 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 authorization system 622 may determine the second account identifier based on the fallback rule (e.g., default payment).

[0148] In some non-limiting embodiments or aspects, the authorization 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 customer funding options). In some non-limiting embodiments or aspects, the authorization 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, based on which of these issuer systems issued the second account identifier). In some non-limiting embodiments or aspects, the authorization system 622 may store a transaction history record in a transaction history database 626 based on the payment transaction and / or the second account identifier.

[0149] In some non-limiting embodiments or aspects, the issuer system 604 may determine whether to authorize the payment transaction based on the modified authorization request message, as described herein. For example, the issuer system 604 may generate an authorization decision (e.g., authorization, rejection, etc.) based on the modified authorization request message, as described herein. In some non-limiting embodiments or aspects, the issuer system 604 may generate an authorization response based on determining whether to authorize the payment transaction (e.g., based on the authorization decision), as described herein. For example, the authorization response may include the second account identifier.

[0150] In some non-limiting embodiments or aspects, the authorization system 602 may receive an authorization response, for example, from the issuer system 604. In some non-limiting embodiments or aspects, the authorization system 602 may generate a modified authorization response, as described herein. For example, the authorization system 602 may identify a transaction history record associated with the payment transaction stored in the transaction history database 626 (e.g., the transaction history record may indicate that the second account identifier replaced the first account identifier when the modified authorization request was generated), and / or the authorization system 602 may generate a modified authorization response for the payment transaction including the first account identifier (e.g., in place of the second account identifier) ​​based on the identified transaction history record. In some non-limiting embodiments or aspects, the authorization system 602 may transmit the modified authorization response, for example, to an acquirer system and / or a payment gateway system (e.g., the payment gateway system that originally transmitted the authorization request).

[0151] refer to Figure 6B In some 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 time period (e.g., a predetermined time period, a minimum time period, a selected time period, etc.) after the initial transmission of the authorization request message. In some non-limiting embodiments or aspects, the settlement request message may include a first account identifier (e.g., a primary account). Additionally or alternatively, the settlement request may include other identification information associated with the payment transaction, such as a transaction identifier, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, etc. In some non-limiting embodiments or aspects, the acquirer system 610 may transmit the settlement request message to the settlement system 628.

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

[0153] In some non-limiting embodiments or aspects, the settlement system 628 may generate a modified settlement request message. For example, the settlement system 628 may generate a modified settlement 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 settlement request message may include the second account identifier. Additionally or alternatively, the modified settlement request may include other identification information associated with the payment transaction, such as a transaction identifier, a timestamp, a merchant identifier, a merchant account identifier, any combination thereof, and the like.

[0154] In some non-limiting embodiments or aspects, the settlement system 628 may transmit the modified settlement 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, based on which of these issuer systems issued the second account identifier).

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

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

[0157] In some non-limiting embodiments or aspects, the settlement system 628 may receive a settlement response, for example, from an issuer system. In some non-limiting embodiments or aspects, the settlement system 628 may generate a modified settlement response, as described herein. For example, the settlement system 628 may generate a modified settlement response for the payment transaction, and the modified settlement response may include the first account identifier. For example, the settlement system 628 may identify a transaction history associated with the payment transaction stored in the transaction history database 626 (e.g., the transaction history may indicate that the second account identifier replaced the first account identifier when the modified authorization request was generated), and / or the settlement system 628 may generate a modified settlement response for the payment transaction including the first account identifier (e.g., replacing the second account identifier) ​​based on the identified transaction history, as described herein. In some non-limiting embodiments or aspects, the settlement system 628 may transmit the modified settlement response, for example, to the acquirer system 610 and / or the payment gateway system (e.g., the payment gateway system that originally transmitted the settlement request).

[0158] Although the embodiments have been described in detail for the purpose of illustration, it should be understood that such details are used for that purpose only, and the present 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 present disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

1. A computer-implemented method, the method comprising: include: receiving, with at least one processor, an authorization request message associated with a payment transaction, the authorization request message including a first account identifier associated with a user; determining, with at least one processor, a second account identifier from a 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; sending, with at least one processor, the modified authorization request message to an issuer system associated with the second account identifier; as well as Utilizing at least one processor, a transaction history is stored based on the payment transaction and the second account identifier.

2. The method according to claim 1, further comprising: include: receiving, with at least one processor, rule data associated with the at least one rule, wherein the rule data includes a threshold value; and determining, using at least one processor, whether a transaction amount of the payment transaction satisfies the threshold, 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 method according to claim 1, in, The at least one rule includes a first rule based on rule data received from the user and a fallback rule, wherein determining the second account identifier includes: determining, using at least one processor, 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, utilizing at least one processor, determining the second account identifier from the plurality of account identifiers based on the fallback rule.

4. The method according to claim 1, further comprising: include: receiving, with at least one processor, a settlement request message associated with the payment transaction, the settlement 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 settlement request message based on identifying the transaction history record, the modified settlement request message including the second account identifier; as well as The modified settlement request message is sent, with at least one processor, to the issuer system associated with the second account identifier.

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

6. The method according to claim 1, further comprising: include: Rule data associated with the at least one rule is received from the issuer system using at least one processor.

7. The method according to claim 1, in, The first account identifier comprises a primary account identifier associated with a physical payment device associated with the user, wherein the multiple account identifiers comprise multiple virtual account identifiers associated with the user, wherein the second account identifier comprises a selected virtual account identifier, and wherein determining the second account identifier comprises selecting the selected virtual account identifier from the multiple virtual account identifiers based on the at least one rule.

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

9. A system, wherein the system include: at least one processor; as well as 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: receiving an authorization request message associated with a payment transaction, the authorization request message including a first account identifier associated with a user; determining a second account identifier from a 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 authorization request message to an issuer system associated with the second account identifier; as well as A transaction history is stored based on the payment transaction and the second account identifier.

10. The system according to claim 9, in, The instructions, when executed by the at least one processor, further cause the at least one processor to: receiving rule data associated with the at least one rule, wherein the rule data includes a threshold value; and determining whether the transaction amount of the payment transaction meets the threshold, 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 system according to claim 9, in, The at least one rule includes a first rule based on rule data received from the user and a fallback rule, wherein 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 The second account identifier is determined from the plurality of account identifiers based on the fallback rule in response to determining that the first rule is not applicable.

12. The system according to claim 9, in, The instructions, when executed by the at least one processor, further cause the at least one processor to: receiving a settlement request message associated with the payment transaction, the settlement request message including the first account identifier; identifying the transaction history based on the payment transaction; generating a modified settlement request message based on identifying the transaction history record, the modified settlement request message including the second account identifier; as well as The modified settlement request message is sent to the issuer system associated with the second account identifier.

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

14. The system according to claim 9, in, The instructions, when executed by the at least one processor, further cause the at least one processor to: Rule data associated with the at least one rule is received from the issuer system.

15. The system according to claim 9, in, The first account identifier comprises a primary account identifier associated with a physical payment device associated with the user, wherein the multiple account identifiers comprise multiple virtual account identifiers associated with the user, wherein the second account identifier comprises a selected virtual account identifier, and wherein determining the second account identifier comprises selecting the selected virtual account identifier from the multiple virtual account identifiers based on the at least one rule.

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

17. A computer program product, the computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions, the program instructions, when executed by at least one processor, causing the at least one processor to: receiving an authorization request message associated with a payment transaction, the authorization request message including a first account identifier associated with a user; determining a second account identifier from a 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 authorization request message to an issuer system associated with the second account identifier; as well as A transaction history is stored based on the payment transaction and the second account identifier.

18. The computer program product according to claim 17, in, The instructions, when executed by the at least one processor, further cause the at least one processor to: receiving rule data associated with the at least one rule, wherein the rule data includes a threshold value; and determining whether the transaction amount of the payment transaction meets the threshold, 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 computer program product according to claim 17, in, The instructions, when executed by the at least one processor, further cause the at least one processor to: receiving a settlement request message associated with the payment transaction, the settlement request message including the first account identifier; identifying the transaction history based on the payment transaction; generating a modified settlement request message based on identifying the transaction history record, the modified settlement request message including the second account identifier; as well as The modified settlement request message is sent to the issuer system associated with the second account identifier.

20. The computer program product according to claim 17, in, The first account identifier comprises a primary account identifier associated with a physical payment device associated with the user, wherein the plurality of account identifiers comprises a plurality of virtual account identifiers associated with the user, wherein the second account identifier comprises a selected virtual account identifier, and wherein 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, and Wherein the primary account identifier comprises a debit account identifier, and wherein the plurality of virtual account identifiers comprises a virtual credit account identifier and a virtual prepaid account identifier.

Images