System, method, and computer program product for flexible account identifiers and flexible transaction message routing

Abstract

Systems, methods, and computer program products are provided for flexible account identifiers and flexible transaction message routing. An example method includes receiving an authorization request message that includes a first account identifier in a first field. A second account identifier is determined based on at least one rule. A modified authorization request message is generated and includes the second account identifier in the first field and the first account identifier in a second field. The modified authorization request message is transmitted to an issuer system associated with the second account identifier. An authorization response message is received from the issuer system and includes the second account identifier in the first field and the first account identifier in the second field. A modified authorization response message including the first account identifier in the first field and the second account identifier in the second field is generated and transmitted.

Description

SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR FLEXIBLE ACCOUNT IDENTIFIERS AND FLEXIBLE TRANSACTION MESSAGE ROUTINGCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to United States Provisional Patent Application No. 63 / 532,1 19 filed on August 1 1 , 2023, the disclosure of which is hereby incorporated by reference in its entirety.BACKGROUND1 . Technical Field

[0002] The present disclosure relates generally to transaction message routing and, in some non-limiting embodiments or aspects, to systems, methods, and computer program products for flexible account identifiers and flexible transaction message routing.2. Technical Considerations

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

[0004] However, such systems may require a user to physically select a different payment device (or remember to type in the account identifier of a different payment device) in order to use a different account for different types of transactions. As such, the user may be required to carry multiple different payment devices and / or memorize different account identifiers. Moreover, these electronic payment processing systems do not allow a user to substitute a different account and / or different account type (e.g. debit card account, credit card account, pre-paid card account, etc.) once the payment transaction is initiated with a certain payment device. Additionally, these payment processing systems do not allow a transaction to be settled with a different account and / or account type than the account associated with the payment device used to initiate a transaction. This poses difficulty in situations where a settlement process of the payment transaction is denied or hindered for unknown reasons.SUMMARY

[0005] Accordingly, provided are improved systems, methods, and computer program products for flexible account identifiers and flexible transaction message routing.

[0006] According to non-limiting embodiments or aspects, provided is a system for flexible account identifiers and flexible transaction message routing, that includes at least one processor configured to: receive an authorization request message associated with a payment transaction, the authorization request message including a first account identifier associated with a user in a first field; 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 in the first field and the first account identifier in a second field; transmit the modified authorization request message to an issuer system associated with the second account identifier; receive an authorization response message for the payment transaction from the issuer system, the authorization response message including the second account identifier in the first field and the first account identifier in the second field; generate a modified authorization response message, the modified authorization response message including the first account identifier in the first field and the second account identifier in the second field; and transmit the modified authorization response message.

[0007] In some non-limiting embodiments or aspects, the at least one processor is further configured to: receive rule data associated with the at least one rule, wherein the rule data includes a threshold value; and determine whether a transaction amount of the payment transaction satisfies the threshold value.

[0008] In some non-limiting embodiments or aspects, when determining the second account identifier, the at least one processor is configured to: select the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0009] In some non-limiting embodiments or aspects, when determining the second account identifier, the at least one processor is configured to: select the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule includes at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawalrule ;a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

[0010] In some non-limiting embodiments or aspects, the at least one processor is further configured to: receive a settlement request message associated with the payment transaction, the settlement request message including the first account identifier in the first field and the second account identifier in the second field; and settle the payment transaction based on the second account identifier.

[0011] In some non-limiting embodiments or aspects, the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, wherein the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, wherein the second account identifier includes a selected virtual account identifier, and wherein, when determining the second account identifier, the at least one processor is configured to: select the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

[0012] In some non-limiting embodiments or aspects, wherein the lead account identifier includes a debit account identifier, and wherein the plurality of virtual account identifiers includes a virtual credit account identifier and a virtual prepaid account identifier.

[0013] According to non-limiting embodiments or aspects, provided is a computer implemented method for flexible account identifiers and flexible transaction message routing that includes 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 in a first field; 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 in the first field and the first account identifier in a second field; transmitting, with at least one processor, the modified authorization request message to an issuer system associated with the second account identifier; receiving, with at least one processor, an authorization response message for the payment transaction from the issuer system, the authorization response message including thesecond account identifier in the first field and the first account identifier in the second field; generating, with at least one processor, a modified authorization response message, the modified authorization response message including the first account identifier in the first field and the second account identifier in the second field; and transmitting, with at least one processor, the modified authorization response message.

[0014] In some non-limiting embodiments or aspects, the computer-implemented method further includes 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, with at least one processor, whether a transaction amount of the payment transaction satisfies the threshold value.

[0015] In some non-limiting embodiments or aspects, determining the second account identifier includes selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0016] In some non-limiting embodiments or aspects, determining the second account identifier includes selecting the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule includes at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

[0017] In some non-limiting embodiments or aspects, the computer-implemented method further includes receiving, with at least one processor, a settlement request message associated with the payment transaction, the settlement request message including the first account identifier in the first field and the second account identifier in the second field; and settling, with at least one processor, the payment transaction based on the second account identifier.

[0018] In some non-limiting embodiments or aspects, the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, wherein the second account identifier includes a selected virtual account identifier, and determining the second account identifier includes selecting the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

[0019] In some non-limiting embodiments or aspects, the lead account identifier includes a debit account identifier, and wherein the plurality of virtual account identifiers includes a virtual credit account identifier and a virtual prepaid account identifier.

[0020] According to non-limiting embodiments or aspects, provided is a computer program product for flexible account identifiers and flexible transaction message routing, that includes at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive an authorization request message associated with a payment transaction, the authorization request message including a first account identifier associated with a user in a first field; 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 in the first field and the first account identifier in a second field; transmit the modified authorization request message to an issuer system associated with the second account identifier; receive an authorization response message for the payment transaction from the issuer system, the authorization response message including the second account identifier in the first field and the first account identifier in the second field; generate a modified authorization response message, the modified authorization response message including the first account identifier in the first field and the second account identifier in the second field; and transmit the modified authorization response message.

[0021] In some non-limiting embodiments or aspects, the instructions further cause the at least one processor to: receive rule data associated with the at least one rule, wherein the rule data includes a threshold value; and determine whether a transaction amount of the payment transaction satisfies the threshold value.

[0022] In some non-limiting embodiments or aspects, the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0023] In some non-limiting embodiments or aspects, the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the second account identifier from the plurality ofaccount identifiers based on the at least one rule, wherein the at least one rule includes at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

[0024] In some non-limiting embodiments or aspects, the instructions cause the at least one processor to: receive a settlement request message associated with the payment transaction, the settlement request message including the first account identifier in the first field and the second account identifier in the second field; and settle the payment transaction based on the second account identifier.

[0025] In some non-limiting embodiments or aspects, the first account identifier includes a lead account identifier associated with a physical payment device associated with the user, wherein the plurality of account identifiers includes a plurality of virtual account identifiers associated with the user, wherein the second account identifier includes a selected virtual account identifier, and wherein, when the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

[0026] In some non-limiting embodiments or aspects, the lead account identifier includes a debit account identifier, and wherein the plurality of virtual account identifiers includes a virtual credit account identifier and a virtual prepaid account identifier.

[0027] Further non-limiting embodiments or aspects will be set forth in the following numbered clauses:

[0028] Clause 1 : A system, comprising: at least one processor configured to: receive an authorization request message associated with a payment transaction, the authorization request message comprising a first account identifier associated with a user in a first field; 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 in the first field and the first account identifier in a second field; transmit the modified authorization request message to an issuer system associated with the second account identifier; receive an authorization response message for the paymenttransaction from the issuer system, the authorization response message comprising the second account identifier in the first field and the first account identifier in the second field; generate a modified authorization response message, the modified authorization response message comprising the first account identifier in the first field and the second account identifier in the second field; and transmit the modified authorization response message.

[0029] Clause 2: The system of clause 1 , wherein the at least one processor is further configured to: receive rule data associated with the at least one rule, wherein the rule data comprises a threshold value; and determine whether a transaction amount of the payment transaction satisfies the threshold value.

[0030] Clause 3: The system of clauses 1 or 2, wherein, when determining the second account identifier, the at least one processor is configured to: select the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0031] Clause 4: The system of any of clauses 1 -3, wherein, when determining the second account identifier, the at least one processor is configured to: select the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule comprises at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule ;a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

[0032] Clause 5: The system of any of clauses 1 -4, wherein the at least one processor is further configured to: receive a settlement request message associated with the payment transaction, the settlement request message comprising the first account identifier in the first field and the second account identifier in the second field; and settle the payment transaction based on the second account identifier.

[0033] Clause 6: The system of any of clauses 1 -5, wherein the first account identifier comprises a lead 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, when determining the second account identifier, the at least one processor is configured to:select the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

[0034] Clause 7: The system of any of clauses 1 -6, wherein the lead 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.

[0035] Clause 8: A computer-implemented method, comprising: receiving, with at least one processor, an authorization request message associated with a payment transaction, the authorization request message comprising a first account identifier associated with a user in a first field; 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 comprising the second account identifier in the first field and the first account identifier in a second field; transmitting, with at least one processor, the modified authorization request message to an issuer system associated with the second account identifier; receiving, with at least one processor, an authorization response message for the payment transaction from the issuer system, the authorization response message comprising the second account identifier in the first field and the first account identifier in the second field; generating, with at least one processor, a modified authorization response message, the modified authorization response message comprising the first account identifier in the first field and the second account identifier in the second field; and transmitting, with at least one processor, the modified authorization response message.

[0036] Clause 9: The computer-implemented method of clause 8, further comprising:

[0037] receiving, with at least one processor, rule data associated with the at least one rule, wherein the rule data comprises a threshold value; and determining, with at least one processor, whether a transaction amount of the payment transaction satisfies the threshold value.

[0038] Clause 10: The computer-implemented method of clauses 8 or 9, wherein determining the second account identifier comprises: selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0039] Clause 1 1 : The computer-implemented method of any of clauses 8-10, wherein determining the second account identifier comprises selecting the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule comprises at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

[0040] Clause 12: The computer-implemented method of any of clauses 8-1 1 , further comprising: receiving, with at least one processor, a settlement request message associated with the payment transaction, the settlement request message comprising the first account identifier in the first field and the second account identifier in the second field; and settling, with at least one processor, the payment transaction based on the second account identifier.

[0041] Clause 13: The computer-implemented method of any of clauses 8-12, wherein the first account identifier comprises a lead 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.

[0042] Clause 14: The computer-implemented method of any of clauses 8-13, wherein the lead 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.

[0043] Clause 15: A computer program product comprising at least one non- transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive an authorization request message associated with a payment transaction, the authorization request message comprising a first account identifier associated with a user in a first field; 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, themodified authorization request message comprising the second account identifier in the first field and the first account identifier in a second field; transmit the modified authorization request message to an issuer system associated with the second account identifier; receive an authorization response message for the payment transaction from the issuer system, the authorization response message comprising the second account identifier in the first field and the first account identifier in the second field; generate a modified authorization response message, the modified authorization response message comprising the first account identifier in the first field and the second account identifier in the second field; and transmit the modified authorization response message.

[0044] Clause 16: The computer program product of clause 15, wherein the instructions further cause the at least one processor to: receive rule data associated with the at least one rule, wherein the rule data comprises a threshold value; and determine whether a transaction amount of the payment transaction satisfies the threshold value.

[0045] Clause 17: The computer program product of clauses 15 or 16, wherein, the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0046] Clause 18: The computer program product of any of clauses 15-17, wherein, the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule comprises at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

[0047] Clause 19: The computer program product of any of clauses 15-18, wherein the instructions cause the at least one processor to: receive a settlement request message associated with the payment transaction, the settlement request message comprising the first account identifier in the first field and the second account identifier in the second field; and settle the payment transaction based on the second account identifier.

[0048] Clause 20: The computer program product of any of clauses 15-19, wherein the first account identifier comprises a lead 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, when the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

[0049] Clause 21 : The computer program product of any of clauses 15-20, wherein the lead 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.

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

[0051] Additional advantages and details of the present disclosure are explained in greater detail below with reference to the exemplary embodiments that are illustrated in the accompanying figures, in which:

[0052] FIG. 1 is a diagram of a non-limiting embodiment or aspect of an environment in which systems, devices, products, apparatus, and / or methods, described herein, may be implemented according to the principles of the present disclosure;

[0053] FIG. 2 is a flowchart of a non-limiting embodiment or aspect of a process for flexible account identifiers and flexible transaction message routing;

[0054] FIGS. 3A-3G are schematic diagrams of an exemplary implementation of a system and / or method for flexible account identifiers and flexible transaction message routing, according to some non-limiting embodiments or aspects;

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

[0056] FIG. 5 is a schematic diagram of example components of one or more devices of FIG. 1 and / or FIG. 4, according to some non-limiting embodiments or aspects; and

[0057] FIGS. 6-1 1 are display screens for flexible account identifiers and flexible transaction message routing.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0074] Non-limiting embodiments or aspects of the disclosed subject matter are directed to systems, methods, and computer program products for flexible account identifiers and flexible transaction message routing. For example, non-limiting embodiments or aspects of the disclosed subject matter provide receiving an authorization request message that is associated with a payment transaction and that includes a first account identifier associated with a user in a first field, 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 that includes the second account identifier in the first field and the first account identifier in a second field, and transmitting the modified authorization request message to an issuer system associated with the second account identifier. Additionally, an authorization response message for the payment transaction is received from the issuer system and includes the second account identifier in the first field and the first account identifier in the second field, a modified authorization response message is generated and includes the first account identifier in the first field and the second account identifier in the second field, and the modified authorization response message is transmitted. As such, the disclosed subject matter enables one or more transactions to be initiated with a single account identifier (e.g., a flexible credential) and have a different account and / or account type to be used to authorize and then settle the transaction.Additionally, the disclosed subject matter allows a user to complete transactions using a plurality of different accounts and / or account types while only needing to carry a single payment device and / or to type in a single account identifier. Moreover, the disclosed subject matter enables the user to set customized rules for selection of which account and / or account type is used for different transactions (e.g., based on customizable criteria). Furthermore, the disclosed subject matter ensures that the same account is used for settlement of the transaction as was used for authorization of the transaction even though the (second) account identifier used to complete the authorization is different than the (first) account identifier in the settlement message due to the storage of the (second) account identifier used to complete the authorization in the separate field of the modified authorization response.

[0075] Referring now to FIG. 1 , FIG. 1 depicts system 100 for flexible account identifiers and flexible transaction message routing, according to non-limiting embodiments or aspects. As shown in FIG. 1 , system 100 may include transaction service provider system 102, authorization system 102a, settlement system 102b, rules database 102c, issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10. In some non-limiting embodiments or aspects, transaction service provider system 102, authorization system 102a, settlement system 102b, rules database 102c, issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10 may interconnect (e.g., establish a connection to communicate) via wired connections, wireless connections, or a combination of wired and wireless connections.

[0076] In some non-limiting embodiments or aspects, transaction service provider system 102, authorization system 102a, settlement system 102b, rules database 102c, issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10 may communicate via a communication network (e.g., not shown in FIG. 1 ). In some non-limiting embodiments or aspects, the communication network may include one or more wired and / or wireless networks. For example, the communication network 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., the public switched telephone network (PSTN) and / or the like), a private network, an ad hoc network, anintranet, the Internet, a fiber optic-based network, a cloud computing network, and / or the like, and / or a combination of some or all of these or other types of networks. In some non-limiting embodiments or aspects, transaction service provider system 102, authorization system 102a, settlement system 102b, rules database 102c, issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10 may communicate via one or more messages (e.g., one or more messages that include a status of an electronic payment transaction) that have a specific format, where the specific format may include an International Organization for Standardization (ISO) 8583 format.

[0077] Transaction service provider system 102 may include one or more devices capable of receiving information from and / or communicating information to issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10, as described herein. For example, transaction service provider system 102 may include a computing device, such as a server (e.g., a transaction processing server), a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, transaction service provider system 102 may be associated with a transaction service provider, as described herein. In some non-limiting embodiments or aspects, transaction service provider system 102 may include authorization system 102a, settlement system 102b, and / or rules database 102c. Additionally or alternatively, at least one of (e.g., all of, a subset of, and / or the like) authorization system 102a, settlement system 102b, and / or rules database 102c may be separate (e.g., completely separate, partially separate, and / or the like) from transaction service provider system 102. In some non-limiting embodiments or aspects, transaction service provider system 102 may be capable of receiving information from and / or communicating information to authorization system 102a, settlement system 102b, and / or rules database 102c. In some non-limiting embodiments or aspects, transaction service provider system 102 may be in communication with a data storage device, which may be local or remote to transaction service provider system 102. In some non-limiting embodiments or aspects, transaction service provider system 102 may be capable of receiving information from, storing information in, communicating information to, or searching information stored in the data storage device.

[0078] Authorization system 102a may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 102, settlement system 102b, rules database 102c, issuer system104, payment device 106, acquirer system 1 10, a payment gateway system, and / or the like. For example, authorization system 102a may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, authorization system 102a may receive authorization requests, e.g., from acquirer system 110 and / or a payment gateway system, as described herein. Additionally or alternatively, authorization system 102a may communicate authorization requests (and / or modified authorization requests), e.g., to issuer system 104, as described herein. In some non-limiting embodiments or aspects, authorization system 102a may receive authorization responses, e.g., from issuer system 104, as described herein. Additionally or alternatively, authorization system 102a may communicate authorization responses, e.g., to acquirer system 1 10 and / or a payment gateway system, as described herein.

[0079] Rules database 102c may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 102, authorization system 102a, settlement system 102b, issuer system 104, payment device 106, and / or the like. For example, rules database 102c may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, rules database 102c may be in communication with a data storage device, which may be local or remote to rules database 102c. In some non-limiting embodiments or aspects, rules database 102c may be capable of receiving information from, storing information in, communicating information to, or searching information stored in the data storage device. In some non-limiting embodiments or aspects, rules database 102c may include a rules engine.

[0080] Settlement system 102b may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 102, rules database 102c, issuer system 104, acquirer system 1 10, a payment gateway system, and / or the like. For example, settlement system 102b may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, settlement system 102b may receive settlement requests, e.g., from acquirer system 1 10 and / or a payment gateway system, as described herein. Additionally or alternatively, settlement system 102b may communicate settlement requests, e.g., to issuer system 104, as described herein. In some non-limiting embodiments or aspects, settlement system 102b may receive settlement responses, e.g., from issuer system 104, as described herein.Additionally or alternatively, settlement system 102b may communicate settlement responses, e.g., to acquirer systems and / or payment gateway systems, as described herein.

[0081] Issuer system 104 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 102, authorization system 102a, settlement system 102b, rules database 102c, payment device 106, and / or the like. For example, issuer system 104 may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, issuer system 104 may be associated with an issuer institution, as described herein. For example, issuer system 104 may be associated with an issuer institution that issued a credit account, a debit account, a prepaid account, a credit card, a debit card, a prepaid card, and / or the like to a user associated with payment device 106.

[0082] Payment device 106 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 102, rules database 102c, issuer system 104, merchant system 108, and / or the like. For example, payment device 106 may include a payment device, as described herein. In some non-limiting embodiments or aspects, payment device 106 may or may not be capable of receiving information (e.g., from merchant system 108 or from another payment device 106) via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like), and / or communicating information (e.g., to merchant system 108 or to another payment device 106) via a short-range wireless communication connection.

[0083] Merchant system 108 may include one or more devices capable of receiving information from and / or communicating information to payment device 106, acquirer system 110, a payment gateway system, and / or the like. In some non-limiting embodiments or aspects, merchant system 108 may also include a device capable of receiving information from payment device 106 via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like), and / or communicating information to payment device 106 via a short-rage wireless communication connection. In somenon-limiting embodiments or aspects, merchant system 108 may include a computing device, such as a server, a group of servers, a client device, a group of client devices, and / or other like devices. In some non-limiting embodiments or aspects, merchant system 108 may be associated with a merchant, as described herein. In some nonlimiting embodiments or aspects, merchant system 108 may include one or more client devices. For example, merchant system 108 may include a client device that allows a merchant to communicate information to transaction service provider system 102 (e.g., via acquirer system 1 10, a payment gateway system, and / or the like). In some non-limiting embodiments or aspects, merchant system 108 may include one or more devices, such as computers, computer systems, and / or peripheral devices capable of being used by a merchant to conduct a transaction with a user. For example, merchant system 108 may include a POS device and / or a POS system.

[0084] Acquirer system 1 10 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 102, authorization system 102a, settlement system 102b, merchant system 108, a payment gateway system, and / or the like. For example, acquirer system 1 10 may include a computing device, a server, a group of servers, and / or the like. In some non-limiting embodiments or aspects, acquirer system 110 may be associated with an acquirer, as described herein.

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

[0086] Referring now to FIG. 2, shown is an example process 200 for flexible account identifiers and flexible transaction message routing, according to some nonlimiting embodiments or aspects. The steps shown in FIG. 2 are for example purposes only. It will be appreciated that additional, fewer, different, and / or a different order of steps may be used in non-limiting embodiments or aspects. In some non-limitingembodiments or aspects, one or more of the steps of process 200 may be performed (e.g., completely, partially, and / or the like) by transaction service provider system 102 (e.g., authorization system 102a, settlement system 102b, and / or rules database 102c, thereof). In some non-limiting embodiments or aspects, one or more of the steps of process 200 may be performed (e.g., completely, partially, and / or the like) by another system, another device, another group of systems, or another group of devices, separate from or including transaction service provider system 102, such as authorization system 102a, settlement system 102b, rules database 102c, issuer system 104, payment device 106, merchant system 108, acquirer system 1 10, and / or the like. The steps shown in FIG. 2 are for example purposes only. It will be appreciated that additional, fewer, different, and / or a different order of steps may be used in some non-limiting embodiments or aspects. In some non-limiting embodiments or aspects, a step may be automatically performed in response to performance and / or completion of a prior step.

[0087] As shown in FIG. 2, at step 202, process 200 may include receiving an authorization request message. For example, transaction service provider system 102 and / or authorization system 102a may receive an authorization request message associated with a payment transaction (e.g., from acquirer system 1 10, merchant system 108, a payment gateway system, and / or the like). In some non-limiting embodiments or aspects, the authorization request message may include a first account identifier associated with a user in a first field.

[0088] In some non-limiting embodiments or aspects, transaction service provider system 102 and / or rules database 102c may receive (e.g., from issuer system 104, payment device 106, and / or the like) rule data associated with at least one rule (e.g., before receiving the authorization request). Additionally or alternatively, transaction service provider system 102 and / or rules database 102c may store rule data associated with at least one rule. For example, transaction service provider system 102 may store received rule data associated with at least one rule in rule database 102c.

[0089] As shown in FIG. 2, at step 204, process 200 may include determining a second account identifier. For example, transaction service provider system 102 and / or authorization system 102a may determine a second account identifier from a plurality of account identifiers based on at least one rule associated with the first account identifier (e.g., stored in rules database 102c).

[0090] In some non-limiting embodiments or aspects, transaction service provider system 102 and / or rules database 102c may receive (e.g., from issuer system 104, payment device 106, and / or the like) rule data associated with at least one rule (e.g., before determining the second account identifier and / or contemporaneous with or after receiving the authorization request). Additionally or alternatively, transaction service provider system 102 and / or rules database 102c may store rule data associated with at least one rule. For example, transaction service provider system 102 may store received rule data associated with at least one rule in rules database 102c.

[0091] In some non-limiting embodiments or aspects, the rule data may include a threshold value (e.g., a threshold value associated with a parameter of transaction data, such as a threshold value of a transaction amount, a threshold value of a time of day, a threshold value of a number of a transaction, etc.). For example, transaction service provider system 102 and / or authorization system 102a may determine whether a transaction amount of the payment transaction satisfies the threshold value and / or determining the second account identifier may include selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value. In some non-limiting embodiments or aspects, the rule data may include a parameter of transaction data. For example, the rule data may include a parameter associated with a merchant (e.g., a merchant category code (MCC)), a parameter associated with a time period (e.g., a time of day, a day of a week, a day of a month, etc.), a parameter associated with a location (e.g., a location of a merchant), and / or the like. In some non-limiting embodiments or aspects, if transaction data associated with a payment transaction corresponds to the parameter of transaction data, transaction service provider system 102 may determine that the payment transaction satisfies the at least one rule.

[0092] In some non-limiting embodiments or aspects, determining the second account identifier may include selecting the second account identifier from the plurality of account identifiers based on the at least one rule. For example, the at least one rule may include at least one of a default account identifier rule, a transaction amount rule, a transaction type rule, a cash withdrawal rule, a merchant category rule, a merchant identifier (ID) rule, a currency rule, a recurring payment rule, an override rule, a cross-border transaction rule, a time-based rule, or any combination thereof.

[0093] In some non-limiting embodiments or aspects, the first account identifier may include a lead account identifier (e.g., a flexible credential) associated with aphysical payment device associated with the user. Additionally or alternatively, at least some of the plurality of account identifiers may include a plurality of virtual account identifiers associated with the user. For example, the second account identifier may include a selected virtual account identifier and / or 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. In some non-limiting embodiments or aspects, the first account identifier may be associated with a first account of a user and the second account identifier may be associated with a second account of the user. In some non-limiting embodiments or aspects, the first account identifier may be associated with a first account of a first user and the second account identifier may be associated with a second account of a second user (e.g., a different user than the first user).

[0094] In some non-limiting embodiments or aspects, the lead account identifier may include a debit account identifier. Additionally or alternatively, the plurality of virtual account identifiers may include a virtual credit account identifier and / or a virtual prepaid account identifier. In some non-limiting embodiments or aspects, other combinations of such types of account identifiers may be used (e.g., the lead account identifier may include a credit account identifier, and the plurality of virtual account identifiers may include a virtual debit account identifier and / or a virtual prepaid account identifier; the lead account identifier may include a prepaid account identifier, the plurality of virtual account identifiers may include a virtual debit account identifier and / or a virtual credit account identifier; and / or the like).

[0095] In some non-limiting embodiments or aspects, transaction service provider system 102 may determine whether to add a second account identifier to a transaction authorization request message. For example, transaction service provider system 102 may determine whether to add a second account identifier to a transaction authorization request message based on the at least one rule. In such an example, if transaction data associated with the payment transaction corresponds to the at least one rule (e.g., rule criteria associated with the at least one rule), transaction service provider system 102 may determine to add a second identifier to a transaction authorization request message (e.g., determine to modify a transaction authorization request message with a second account identifier). If the transaction data associated with the payment transaction does not correspond to the at least one rule, transaction service provider system 102 may determine not to add a second identifier to atransaction authorization request message (e.g., determine not to modify a transaction authorization request message with a second account identifier).

[0096] As shown in FIG. 2, at step 206, process 200 may include generating a modified authorization request message. For example, transaction service provider system 102 and / or authorization system 102a may generate a modified authorization request message for the payment transaction based on determining the second account identifier. In some non-limiting embodiments or aspects, the modified authorization request message may include the second account identifier in the first field and the first account identifier in the second field. In some non-limiting embodiments or aspects, transaction service provider system 102 may generate the modified authorization request message based on determining to add the second account identifier to a transaction authorization request message.

[0097] As shown in FIG. 2, at step 208, process 200 may include transmitting the modified authorization request message. For example, transaction service provider system 102 and / or authorization system 102a may transmit the modified authorization request message. In some non-limiting embodiments or aspects, transaction service provider system 102 and / or authorization system 102a may transmit the modified authorization request message to issuer system 104, which may be associated with the second account identifier.

[0098] In some non-limiting embodiments or aspects, there may be a plurality of issuer systems 104. For example, a first issuer system 104 may be associated with the first account identifier. Additionally or alternatively, a second issuer system 104 may be associated with the second account identifier. In some non-limiting embodiments or aspects, other issuer systems 104 (e.g., a third issuer system 104, etc.) may be associated with other account identifiers of the plurality of account identifiers (e.g., a third account identifier, etc.). In some non-limiting embodiments or aspects, at least two of the account identifiers (e.g., the first account identifier and the second account identifier, the second account identifier and the third account identifier, the first account identifier and the third account identifier, and / or the like) may be associated with a same issuer system 104.

[0099] As shown in FIG. 2, at step 210, process 200 may include receiving an authorization response message. For example, transaction service provider system 102 and / or authorization system 102a may receive an authorization response message for the payment transaction from issuer system 104. In some non-limitingembodiments or aspects, the authorization response message may include the second account identifier in the first field and the first account identifier in the second field.

[0100] As shown in FIG. 2, at step 212, process 200 may include generating a modified authorization response message. For example, transaction service provider system 102 and / or authorization system 102a may generate a modified authorization response message. In some non-limiting embodiments or aspects, the modified authorization response message may include the first account identifier in the first field and the second account identifier in the second field.

[0101] As shown in FIG. 2, at step 214, process 200 may include transmitting the modified authorization response message. For example, transaction service provider system 102 and / or authorization system 102a may transmit the modified authorization response message. In some non-limiting embodiments or aspects, transaction service provider system 102 and / or authorization system 102a may transmit the modified authorization response message to the entity (e.g., acquirer system 1 10, merchant system 108, the payment gateway system, and / or the like) that transmitted the authorization request message.

[0102] In some non-limiting embodiments or aspects, certain fees and / or rates (e.g., merchant service fee, merchant discount rate, and / or the like) may be different based on the account identifier used for the payment transaction. By including the first account identifier (e.g., in the first field) and the second account identifier (e.g., in the second field) in the authorization response, the entities (e.g., acquirer system 110, merchant system 108, the payment gateway system, and / or the like) that transmitted the authorization request message may be able to determine and / or reconcile the different fees and / or rates associated with the payment transaction (e.g., when the funding source for the payment transaction was changed from the first account identifier to the second account identifier).

[0103] In some non-limiting embodiments or aspects, transaction service provider system 102 and / or settlement system 102b may receive a settlement request message associated with the payment transaction (e.g., after transmitting the modified authorization response message). The settlement request message may include the first account identifier in the first field and the second account identifier in the second field. In some non-limiting embodiments or aspects, transaction service provider system 102 and / or settlement system 102b may settle the payment transaction basedon the second account identifier (e.g., even though the first account identifier is included in the first field and / or was previously used to initiate the payment transaction).

[0104] Referring now to FIGS. 3A-3G, shown are schematic diagrams of implementation 300 of a process (e.g., process 200) for flexible account identifiers and flexible transaction message routing. In some non-limiting embodiments or aspects, one or more of the steps of the process may be performed (e.g., completely, partially, etc.) by transaction service provider system 102 (e.g., one or more devices of transaction service provider system 102). In some non-limiting embodiments or aspects, one or more of the steps of the process may be performed (e.g., completely, partially, etc.) by another device or a group of devices separate from or including transaction service provider system 102, such as issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10.

[0105] As shown by reference number 301 in FIG. 3A, a user associated with payment device 106 may conduct an electronic payment transaction with a merchant associated with POS device 308 using payment device 106. In some non-limiting embodiments or aspects, POS device 308 may be the same as or similar to merchant system 108.

[0106] As further shown by reference number 303 in FIG. 3A, POS device 308 may generate a transaction authorization request message for the electronic payment transaction involving payment device 106. In some non-limiting embodiments or aspects, POS device 308 may generate the transaction authorization request message for the electronic payment transaction involving payment device 106 based on receiving a first account identifier (e.g., a flexible credential for an account of the user associated with payment device 106, such as a lead account identifier). The transaction authorization request message may include a transaction authorization request message having a format, such as an ISO 8583 format, that includes a plurality of fields for a plurality of account identifiers. In some non-limiting embodiments or aspects, the transaction authorization request message may include the first account identifier in a first field for an account identifier and a second field for an account identifier may be empty (e.g., have a null value, a zero value, etc.). Additionally, the transaction authorization request message may include transaction data associated with the electronic payment transaction, such as a transaction identifier (e.g., a transaction id), a transaction amount, a transaction time, and / or the like.

[0107] As shown by reference number 305 in FIG. 3B, POS device 308 may transmit the transaction authorization request message to acquirer system 1 10. As further shown by reference number 307 in FIG. 3B, acquirer system 1 10 may receive the transaction authorization request message from POS device 308 and may transmit the transaction authorization request message to transaction service provider system 102 based on receiving the transaction authorization request message. As further shown by reference number 309 in FIG. 3B, transaction service provider system 102 may receive the transaction authorization request message from acquirer system 1 10. As further shown by reference number 31 1 in FIG. 3B, transaction service provider system 102 may determine a second account identifier based on receiving the transaction authorization request message. In some non-limiting embodiments or aspects, the second account identifier may include an account identifier for another account of the user of POS device 308.

[0108] In some non-limiting embodiments or aspects, transaction service provider system 102 (e.g., authorization system 102a of transaction service provider system 102) may determine the second account identifier from a plurality of account identifiers based on at least one rule associated with the first account identifier (e.g., stored in rules database 102c). In some non-limiting embodiments or aspects, the at least one rule may include at least one of a default account identifier rule, a transaction amount rule, a transaction type rule, a cash withdrawal rule, a merchant category rule, an ID rule, a currency rule, a recurring payment rule, an override rule, a cross-border transaction rule, a time-based rule, or any combination thereof. In some non-limiting embodiments or aspects, determining the second account identifier may include selecting the second account identifier from the plurality of account identifiers based on the at least one rule.

[0109] In some non-limiting embodiments or aspects, transaction service provider system 102 may retrieve rule data associated with the at least one rule from a database (e.g., rules database 102c). In some non-limiting embodiments or aspects, the rule data may include a threshold value associated with an electronic payment transaction. In some non-limiting embodiments or aspects, transaction service provider system 102 may determine whether a transaction amount of the electronic payment transaction satisfies the threshold value, and transaction service provider system 102 may determine the second account identifier by selecting the secondaccount identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

[0110] As shown by reference number 313 in FIG. 30, transaction service provider system 102 may generate a modified transaction authorization request message based on determining the second account identifier. In some non-limiting embodiments or aspects, the modified transaction authorization request message may include the second account identifier in the first field for an account identifier and the first account identifier in a second field for an account identifier. Additionally, the modified transaction authorization request message may include transaction data associated with the electronic payment transaction. As further shown by reference number 315 in FIG. 30, transaction service provider system 102 may transmit the modified transaction authorization request message to issuer system 104 based on generating the modified transaction authorization request message. As further shown by reference number 317 in FIG. 30, issuer system 104 may receive the modified transaction authorization request message from transaction service provider system 102. As further shown by reference number 319 in FIG. 30, issuer system 104 may determine whether to authorize the electronic payment transaction based on the modified transaction authorization request message.

[0111] As shown by reference number 321 in FIG. 3D, issuer system 104 may generate a transaction authorization response message based on determining whether to authorize the electronic payment transaction. In some non-limiting embodiments or aspects, the transaction authorization response message may include the second account identifier in the first field for an account identifier and the first account identifier in a second field for an account identifier. Additionally, the transaction authorization response message may include transaction data associated with the electronic payment transaction and an indication of whether the electronic payment transaction has been authorized (e.g., an indication of yes, “Y” as shown in FIG. 3D). As further shown by reference number 323 in FIG. 3D, issuer system 104 may transmit the transaction authorization response message based on generating the transaction authorization response message. As further shown by reference number 325 in FIG. 3D, transaction service provider system 102 may receive the transaction authorization response message and may generate a modified transaction authorization response message based on the transaction authorization response message. In some non-limiting embodiments or aspects, the modified transactionauthorization response message may include the first account identifier in the first field for an account identifier and the second account identifier in a second field for an account identifier. Additionally, the modified transaction authorization response message may include transaction data associated with the electronic payment transaction and the indication of whether the electronic payment transaction has been authorized.

[0112] As shown by reference number 327 in FIG. 3E, transaction service provider system 102 may transmit the modified transaction authorization response message to acquirer system 1 10. As further shown by reference number 329 in FIG. 3E, acquirer system 1 10 may receive the modified transaction authorization response message and transmit the modified transaction authorization response message to POS device 308 based on receiving the modified transaction authorization response message. As further shown by reference number 331 in FIG. 3E, POS device 308 may receive the modified transaction authorization response message from acquirer system 110. As further shown by reference number 333 in FIG. 3E, POS device 308 may indicate an authorization status of the electronic payment transaction based on the modified transaction authorization response message. For example, POS device 308 may provide an indication that the electronic payment transaction is authorized based on receiving the modified transaction authorization response message.

[0113] As shown by reference number 335 in FIG. 3F, POS device 308 may transmit transaction data associated with the electronic payment transaction to acquirer system 1 10. For example, POS device 308 may transmit the transaction data after indicating the authorization status of the electronic payment transaction. As further shown by reference number 337 in FIG. 3F, acquirer system 1 10 may receive the transaction data associated with the electronic payment transaction and may transmit the transaction data associated with the electronic payment transaction to transaction service provider system 102. As further shown by reference number 339 in FIG. 3F, transaction service provider system 102 may receive the transaction data associated with the electronic payment transaction from acquirer system 1 10. As further shown by reference number 341 in FIG. 3F, transaction service provider system 102 may determine whether to clear the electronic payment transaction. For example, transaction service provider system 102 may determine to clear the electronic payment transaction based on the transaction data associated with the electronic payment transaction.

[0114] As shown by reference number 343 in FIG. 3G, transaction service provider system 102 may transmit clearing data associated with clearing of the electronic payment transaction based on determining to clear the electronic payment transaction. As further shown by reference number 345 in FIG. 3G, acquirer system 110 and issuer system 104 may receive the clearing data associated with clearing of the electronic payment transaction from transaction service provider system 102. As further shown by reference number 347 in FIG. 3G, acquirer system 1 10 and issuer system 104 may settle the electronic payment transaction. For example, acquirer system 110 and issuer system 104 may settle the electronic payment transaction via a settlement system (e.g., settlement system 102b of transaction service provider system 102).

[0115] Referring now to FIG. 4, shown is a diagram of a non-limiting embodiment or aspect of exemplary environment 400 in which systems, methods, and / or products, as described herein, may be implemented. As shown in FIG. 4, environment 400 may include transaction service provider system 402, issuer system 404, customer device 406, merchant system 408, acquirer system 410, and communication network 412. In some non-limiting embodiments or aspects, transaction service provider system 102 of FIG. 1 may be implemented by (e.g., part of) transaction service provider system 402. In some non-limiting embodiments or aspects, at least one of transaction service provider system 102, issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10 of FIG. 1 may be implemented by (e.g., part of) another system, another device, another group of systems, or another group of devices, separate from or including transaction service provider system 402, such as issuer system 404, customer device 406, merchant system 408, acquirer system 410, and / or the like. In some non-limiting embodiments or aspects, transaction service provider system 402 may be the same as or similar to transaction service provider system 102. In some non-limiting embodiments or aspects, issuer system 404 may be the same as or similar to issuer system 104. In some non-limiting embodiments or aspects, customer device 406 may be the same as or similar to payment device 106. In some non-limiting embodiments or aspects, merchant system 408 may be the same as or similar to merchant system 108. In some non-limiting embodiments or aspects, acquirer system 410 may be the same as or similar to acquirer system 110.

[0116] Transaction service provider system 402 may include one or more devices capable of receiving information from and / or communicating information to issuer system 404, customer device 406, merchant system 408, and / or acquirer system 410via communication network 412. For example, transaction service provider system 402 may include a computing device, such as a server (e.g., a transaction processing server), a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, transaction service provider system 402 may be associated with a transaction service provider, as described herein. In some non-limiting embodiments or aspects, transaction service provider system 402 may be in communication with a data storage device, which may be local or remote to transaction service provider system 402. In some non-limiting embodiments or aspects, transaction service provider system 402 may be capable of receiving information from, storing information in, communicating information to, or searching information stored in the data storage device.

[0117] Issuer system 404 may include one or more devices capable of receiving information and / or communicating information to transaction service provider system 402, customer device 406, merchant system 408, and / or acquirer system 410 via communication network 412. For example, issuer system 404 may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, issuer system 404 may be associated with an issuer institution, as described herein. For example, issuer system 404 may be associated with an issuer institution that issued a credit account, debit account, credit card, debit card, and / or the like to a user associated with customer device 406.

[0118] Customer device 406 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 402, issuer system 404, merchant system 408, and / or acquirer system 410 via communication network 412. Additionally or alternatively, each customer device 406 may include a device capable of receiving information from and / or communicating information to other customer devices 406 via communication network 412, another network (e.g., an ad hoc network, a local network, a private network, a virtual private network, and / or the like), and / or any other suitable communication technique. For example, customer device 406 may include a client device and / or the like. In some non-limiting embodiments or aspects, customer device 406 may or may not be capable of receiving information (e.g., from merchant system 408 or from another customer device 406) via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like),and / or communicating information (e.g., to merchant system 408) via a short-range wireless communication connection.

[0119] Merchant system 408 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 402, issuer system 404, customer device 406, and / or acquirer system 410 via communication network 412. Merchant system 408 may also include a device capable of receiving information from customer device 406 via communication network 412, a communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like) with customer device 406, and / or the like, and / or communicating information to customer device 406 via communication network 412, the communication connection, and / or the like. In some non-limiting embodiments or aspects, merchant system 408 may include a computing device, such as a server, a group of servers, a client device, a group of client devices, and / or other like devices. In some non-limiting embodiments or aspects, merchant system 408 may be associated with a merchant, as described herein. In some non-limiting embodiments or aspects, merchant system 408 may include one or more client devices. For example, merchant system 408 may include a client device that allows a merchant to communicate information to transaction service provider system 402. In some non-limiting embodiments or aspects, merchant system 408 may include one or more devices, such as computers, computer systems, and / or peripheral devices capable of being used by a merchant to conduct a transaction with a user. For example, merchant system 408 may include a POS device and / or a POS system.

[0120] Acquirer system 410 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 402, issuer system 404, customer device 406, and / or merchant system 408 via communication network 412. For example, acquirer system 410 may include a computing device, a server, a group of servers, and / or the like. In some non-limiting embodiments or aspects, acquirer system 410 may be associated with an acquirer, as described herein.

[0121] Communication network 412 may include one or more wired and / or wireless networks. For example, communication network 412 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 multipleaccess (CDMA) network, and / or the like), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN)), a private network (e.g., a private network associated with a transaction service provider), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, and / or the like, and / or a combination of these or other types of networks.

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

[0123] Referring now to FIG. 5, shown is a diagram of example components of device 500, according to non-limiting embodiments or aspects. Device 500 may correspond to at least one of transaction service provider system 102, issuer system 104, payment device 106, merchant system 108, and / or acquirer system 1 10 in FIG. 1 and / or at least one of transaction service provider system 402, issuer system 404, customer device 406, merchant system 408, and / or acquirer system 410 in FIG. 4, as an example. In some non-limiting embodiments or aspects, such systems or devices in FIG. 1 or FIG. 4 may include at least one device 500 and / or at least one component of device 500. The number and arrangement of components shown in FIG. 5 are provided as an example. In some non-limiting embodiments or aspects, device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 5. Additionally or alternatively, a set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500.

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

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

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

[0127] Referring now to FIGS. 6-11 , FIGS. 6-1 1 are display screens for flexible account identifiers and flexible transaction message routing, according to non-limiting embodiments of the present disclosure. In some non-limiting embodiments or aspects, transaction service provider system 102 may cause one or more of the display screens to be displayed in a user interface (e.g., a user interface displayed on payment device 106). FIGS. 6-1 1 are shown as examples only. Additional or alternative display screens may be provided, with additional or alternative user elements from those shown in FIGS. 6-1 1 .

[0128] As shown in FIG. 6, payment toggle onboarding display screen 602 may include elements 602a, 602b, 602a, and / or 602d. In some non-limiting embodiments or aspects, transaction service provider system 102 may display payment toggle onboarding display screen 602. In some non-limiting embodiments or aspects, payment toggle onboarding display screen 602 may enable a user to configure a default payment method (e.g., configure the default method of a payment card to a debit card, a credit card, and / or a prepaid card). Such a configuration may apply to allpayment transactions (e.g., in-person, such as card present, and / or online, such as card not-present) unless a one-time override or a rule (e.g., a smart rule) is applied. In some non-limiting embodiments or aspects, the user may change the default payment method of the payment card.

[0129] In some non-limiting embodiments or aspects, element 602a may include a payment toggle first time use indicator. For example, transaction service provider system 102 may display a payment toggle first time use indicator (e.g., “Say Hello to Flex”) via payment toggle onboarding display screen 602 to encourage a user to use a payment toggle feature associated with a payment card (e.g., a Flex card). In some non-limiting embodiments or aspects, the payment toggle may change the primary payment method of a payment card.

[0130] In some non-limiting embodiments or aspects, element 602b may include a digital payment card. For example, transaction service provider system 102 may display a digital payment card via payment toggle onboarding display screen 602. In some non-limiting embodiments or aspects, the digital payment card may include a representation on a user’s payment card and / or data associated with the user’s payment card (e.g., card art indicating that a payment card is one of a debit card, a credit card, and / or a prepaid card) based on a payment method selected by the user.

[0131] In some non-limiting embodiments or aspects, element 602c may include a default payment method indicator. For example, transaction service provider system 102 may display a default payment method indicator via payment toggle onboarding display screen 602. In some non-limiting embodiments or aspects, the default payment method indicator may include the payment method of the payment card. In some nonlimiting embodiments or aspects, element 602c may be directly adjacent to element 602b.

[0132] In some non-limiting embodiments or aspects, element 602d may include a link. For example, transaction service provider system 102 may display a link via payment toggle onboarding display screen 602. In some non-limiting embodiments or aspects, the link may include a dynamic link which may be selected by a user to change a default payment method of the payment card.

[0133] In some non-limiting embodiments or aspects, transaction service provider system 102 may display card settings display screen 604. In some non-limiting embodiments or aspects, card settings display screen 604 may include element 604e.

[0134] In some non-limiting embodiments or aspects, element 604e may include a payment toggle selection and / or a payment method selection. For example, transaction service provider system 102 may display a payment toggle selection and / or a payment method selection via card settings display screen 604. In some nonlimiting embodiments or aspects, the payment toggle selection and / or the payment method selection may be selected by a user. In some non-limiting embodiments or aspects, card settings display screen 604 may include a list including a plurality of card settings. In some non-limiting embodiments or aspects, the payment toggle selection and / or the payment method selection may be a first card setting, located at a top of the list of the plurality of card settings displayed via card settings display screen 604.

[0135] As shown in FIG. 7, smart rules onboarding display screen 702 may include element 702a. In some non-limiting embodiments or aspects, transaction service provider system 102 may display smart rules onboarding display screen 702.

[0136] In some non-limiting embodiments or aspects, element 702a may include a merchant category code (MCC) rules overview. For example, transaction service provider system 102 may display the MCC rules overview via smart rules onboarding display screen 702. In some non-limiting embodiments or aspects, the MCC rules overview may include a view of all available MCC rules set by the user for their payment card.

[0137] In some non-limiting embodiments or aspects, a plurality of rules (e.g., smart rules) may be defined by a user to automate how a payment is made using a payment card. For example, the user may select to use a selected payment method (e.g., credit, debit, and / or prepaid) if a payment exceeds a threshold value. Once the rule is set, it may be automatically applied to a payment transaction if the transaction meets the pre-defined criteria.

[0138] In some non-limiting embodiments or aspects, transaction service provider system 102 may display smart rules overview display screen 704. In some non-limiting embodiments or aspects, smart rules overview display screen 704 may include elements 704b and / or 704c.

[0139] In some non-limiting embodiments or aspects, element 704b may include a plurality of categories. For example, transaction service provider system 102 may display a plurality of categories selected by the user and / or recommended for the user via smart rules overview display screen 704. In some non-limiting embodiments or aspects, MCCs may be grouped into at least one category of the plurality of categoriesand presented as a selectable shortcut to the user. In some non-limiting embodiments or aspects, the plurality of categories may include credit, debit, and / or prepaid.

[0140] In some non-limiting embodiments or aspects, element 704c may include a plurality of merchant category details. For example, transaction service provider system 102 may display a plurality of merchant category details via smart rules overview display screen 704. In some non-limiting embodiments or aspects, the merchant category details may include a use case (e.g., if payment is above $100, use credit).

[0141] As shown in FIG. 7, configuration display screen 706 may include elements 706c, 706d, and / or 706e. In some non-limiting embodiments or aspects, transaction service provider system 102 may display configuration display screen 706.

[0142] In some non-limiting embodiments or aspects, elements 706c may be the same as, similar to, and / or part of 704c.

[0143] In some non-limiting embodiments or aspects, element 706d may include at least one payment method. For example, transaction service provider system 102 may display at least one payment method via configuration display screen 706. In some non-limiting embodiments or aspects, the at least one payment method may include credit, debit, and / or prepaid. In some non-limiting embodiments or aspects, element 706d may include a drop-down menu including the at least one payment method.

[0144] In some non-limiting embodiments or aspects, element 706e may include a result message. For example, transaction service provider system 102 may display a result message via configuration display screen 706. In some non-limiting embodiments or aspects, the result message may include data including a confirmation indicating a success and / or a failure of a selected MCC rule.

[0145] As shown in FIG. 8, ATM rule overview display screen 802 may include elements 802a and / or 802b. In some non-limiting embodiments or aspects, transaction service provider system 102 may display ATM rule overview display screen 802.

[0146] In some non-limiting embodiments or aspects, element 802a may include a feature-level toggle. For example, transaction service provider system 102 may display the feature-level toggle via ATM rule overview display screen 802. A user may toggle the feature-level toggle to activate and / or deactivate the ATM rule, respectively.

[0147] In some non-limiting embodiments or aspects, element 802b may include a drop-down menu including a payment method. For example, transaction serviceprovider system 102 may display a drop-down menu including a list of selectable payment methods via ATM rule overview display screen 802. In some non-limiting embodiments or aspects, the user may select a payment method (e.g., credit) from the drop-down menu to use for an ATM rule.

[0148] As shown in FIG. 8, result message display screen 804 may include element 804c. In some non-limiting embodiments or aspects, transaction service provider system 102 may display result message display screen 804.

[0149] In some non-limiting embodiments or aspects, element 804c may include a result message. For example, transaction service provider system 102 may display a result message via result message display screen 804. In some non-limiting embodiments or aspects, the result message may include data including an indication of a success and / or a failure of an ATM rule.

[0150] As shown in FIG. 9, payment channels display screen 902 may include elements 902a, 902b, and / or 902c. In some non-limiting embodiments or aspects, transaction service provider system 102 may display payment channels display screen 902.

[0151] In some non-limiting embodiments or aspects, element 902a may include a contactless rule. For example, transaction service provider system 102 may display a contactless rule via payment channels display screen 902. In some non-limiting embodiments or aspects, the contactless rule may include a status of a contactless rule.

[0152] In some non-limiting embodiments or aspects, element 902b may include an e-commerce rule. For example, transaction service provider system 102 may display an e-commerce rule via payment channels display screen 902. In some nonlimiting embodiments or aspects, the contactless rule may include a status of an e- commerce rule.

[0153] In some non-limiting embodiments or aspects, element 902c may include a cross-border rule. For example, transaction service provider system 102 may display a cross-border rule via payment channels display screen 902. In some non-limiting embodiments or aspects, the contactless rule may include a status of a cross-border rule.

[0154] As shown in FIG. 9, cross-border display screen 904 may include elements 904d, 904e, and / or 904f. In some non-limiting embodiments or aspects, transaction service provider system 102 may display cross-border display screen 904.

[0155] In some non-limiting embodiments or aspects, element 904d may include a current payment method indicator. For example, transaction service provider system 102 may display a current payment method indicator via cross-border display screen 904. In some non-limiting embodiments or aspects, the current payment method indicator may include a current (e.g., default) payment method for payment transactions on a payment card.

[0156] In some non-limiting embodiments or aspects, element 904e may include a feature-level toggle. For example, transaction service provider system 102 may display a feature-level toggle via cross-border display screen 904. In some non-limiting embodiments or aspects, the feature-level toggle may be selected by a user to activate and / or deactivate a payment channel rule.

[0157] In some non-limiting embodiments or aspects, element 904f may include a payment method. For example, transaction service provider system 102 may display a payment method via cross-border display screen 904. In some non-limiting embodiments or aspects, element 904f may include a drop-down menu including a plurality of selectable payment methods. In some non-limiting embodiments or aspects, the user may select the payment method from the drop-down menu to use for a payment channel rule (e.g., contactless, e-commerce, and / or cross-border).

[0158] As shown in FIG. 9, result message display screen 906 may include element 906g. In some non-limiting embodiments or aspects, transaction service provider system 102 may display result message display screen 906.

[0159] In some non-limiting embodiments or aspects, element 906g may include a result message. For example, transaction service provider system 102 may display a result message via result message display screen 906. In some non-limiting embodiments or aspects, the result message may include data including an indication of a success and / or a failure of a payment channel rule.

[0160] As shown in FIG. 10, merchant category code (MCC) rules overview display screen 1002 may include element 1002a. In some non-limiting embodiments or aspects, transaction service provider system 102 may display MCC rules overview display screen 1002.

[0161] In some non-limiting embodiments or aspects, element 1002a may include data including a guided onboarding to educate a user that may be a first-time user regarding features (e.g., Smart Rules). For example, transaction service provider system 12 may display the guided onboarding via MCC rules overview display screen1002. In some non-limiting embodiments or aspects, element 1002a may include a list of MCCs.

[0162] As shown in FIG. 10, search category display screen 1004 may include element 1004b. In some non-limiting embodiments or aspects, transaction service provider system 102 may display search category display screen 1004.

[0163] In some non-limiting embodiments or aspects, elements 1004b may include a smart rules overview. For example, transaction service provider system 102 may display the smart rules overview via search category display screen 1004. In some non-limiting embodiments or aspects, the smart rules overview may include a selection of a plurality of categories (e.g., popular categories and / or all categories).

[0164] As shown in FIG. 10, category details display screen 1006 may include elements 1006c and / or 1006d. In some non-limiting embodiments or aspects, transaction service provider system 102 may display category details display screen 1006.

[0165] In some non-limiting embodiments or aspects, element 1006c may include a payment rule set by the user for a payment method. For example, transaction service provider system 102 may display the payment rule set by the user for the payment method via category details display screen 1006.

[0166] In some non-limiting embodiments or aspects, element 1006d may include a payment method. For example, transaction service provider system 102 may display a payment method for a payment card via category details display screen 1006. In some non-limiting embodiments or aspects, element 1006d may include a drop-down menu including a plurality of selectable payment methods. In some non-limiting embodiments or aspects, the user may select the payment method from the dropdown menu to use for a payment card (e.g., prepaid).

[0167] As shown in FIG. 10, result message display screen 1008 may include element 1008e. In some non-limiting embodiments or aspects, transaction service provider system 102 may display result message display screen 1008.

[0168] In some non-limiting embodiments or aspects, element 1008e may include a result message. For example, transaction service provider system 102 may display the result message via result message display screen 1008. In some non-limiting embodiments or aspects, the result message may include data including an amount rage for a rule (e.g., a smart rule). In some non-limiting embodiments or aspects, the result message may include data indicating a change in a payment method.

[0169] As shown in FIG. 11 , schedule switch rule overview display screen 1 102 may include elements 1 102a, 1 102b, 1 102c, 1 102d, and / or 1 102e. In some nonlimiting embodiments or aspects, transaction service provider system 102 may display schedule switch rule overview display screen 1 102.

[0170] In some non-limiting embodiments or aspects, element 1102a may include a current payment method indicator. For example, transaction service provider system 102 may display the current payment method indicator via schedule switch rule overview display screen 1 102.

[0171] In some non-limiting embodiments or aspects, element 1102b may include a feature-level toggle. For example, transaction service provider system 102 may display a feature-level toggle via schedule switch rule overview display screen 1102. In some non-limiting embodiments or aspects, the feature-level toggle may be selected by a user to activate and / or deactivate a schedule switch.

[0172] In some non-limiting embodiments or aspects, element 1 102c may include a payment method. For example, transaction service provider system 102 may display a payment method for a payment card via schedule switch rule overview display screen 1 102. In some non-limiting embodiments or aspects, element 1 102c may include a drop-down menu including a plurality of selectable payment methods. In some non-limiting embodiments or aspects, the user may select the payment method from the drop-down menu to use for a payment card (e.g., credit).

[0173] In some non-limiting embodiments or aspects, element 1 102d may include a duration setting. For example, transaction service provider system 102 may display a duration setting to allow the user to select a duration (e.g., a time period of days, weeks, and / or years) for the scheduled switch. The duration may include a starting date and / or an ending date. In some non-limiting embodiments or aspects, the user may select the starting date and / or the ending date.

[0174] In some non-limiting embodiments or aspects, element 1 102e may include a message. For example, transaction service provider system 102 may display a message including data including a switch-back message indicating when spending will switch based to a current default payment method after the selected duration expires (e.g., on the selected ending date).

[0175] As shown in FIG. 1 1 , result message display screen 1 104 may include element 1 104f. In some non-limiting embodiments or aspects, transaction service provider system 102 may display result message display screen 1 104.

[0176] In some non-limiting embodiments or aspects, element 1 104f may include a result message. For example, transaction service provider system 102 may display the result message via result message display screen 1104. In some non-limiting embodiments or aspects, the result message may include data including an indication of a success and / or a failure of a scheduled switch message.

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

Claims

WHAT IS CLAIMED IS:1 . A system, comprising: at least one processor configured to: receive an authorization request message associated with a payment transaction, the authorization request message comprising a first account identifier associated with a user in a first field; 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 in the first field and the first account identifier in a second field; transmit the modified authorization request message to an issuer system associated with the second account identifier; receive an authorization response message for the payment transaction from the issuer system, the authorization response message comprising the second account identifier in the first field and the first account identifier in the second field; generate a modified authorization response message, the modified authorization response message comprising the first account identifier in the first field and the second account identifier in the second field; and transmit the modified authorization response message.

2. The system of claim 1 , wherein the at least one processor is further configured to: receive rule data associated with the at least one rule, wherein the rule data comprises a threshold value; and determine whether a transaction amount of the payment transaction satisfies the threshold value.

3. The system of claim 2, wherein, when determining the second account identifier, the at least one processor is configured to:select the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

4. The system of claim 1 , wherein, when determining the second account identifier, the at least one processor is configured to: select the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule comprises at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

5. The system of claim 1 , wherein the at least one processor is further configured to: receive a settlement request message associated with the payment transaction, the settlement request message comprising the first account identifier in the first field and the second account identifier in the second field; and settle the payment transaction based on the second account identifier.

6. The system of claim 1 , wherein the first account identifier comprises a lead 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, when determining the second account identifier, the at least one processor is configured to:select the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

7. The system of claim 6, wherein the lead 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.

8. A computer-implemented method, comprising: receiving, with at least one processor, an authorization request message associated with a payment transaction, the authorization request message comprising a first account identifier associated with a user in a first field; 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 comprising the second account identifier in the first field and the first account identifier in a second field; transmitting, with at least one processor, the modified authorization request message to an issuer system associated with the second account identifier; receiving, with at least one processor, an authorization response message for the payment transaction from the issuer system, the authorization response message comprising the second account identifier in the first field and the first account identifier in the second field; generating, with at least one processor, a modified authorization response message, the modified authorization response message comprising the first account identifier in the first field and the second account identifier in the second field; and transmitting, with at least one processor, the modified authorization response message.

9. The computer-implemented method of claim 8, further comprising:receiving, with at least one processor, rule data associated with the at least one rule, wherein the rule data comprises a threshold value; and determining, with at least one processor, whether a transaction amount of the payment transaction satisfies the threshold value.

10. The computer-implemented method of claim 9, wherein determining the second account identifier comprises: selecting the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.1 1 . The computer-implemented method of claim 8, wherein determining the second account identifier comprises selecting the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule comprises at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule; a time-based rule; or any combination thereof.

12. The computer-implemented method of claim 8, further comprising: receiving, with at least one processor, a settlement request message associated with the payment transaction, the settlement request message comprising the first account identifier in the first field and the second account identifier in the second field; andsettling, with at least one processor, the payment transaction based on the second account identifier.

13. The computer-implemented method of claim 8, wherein the first account identifier comprises a lead 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.

14. The computer-implemented method of claim 13, wherein the lead 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.

15. A computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive an authorization request message associated with a payment transaction, the authorization request message comprising a first account identifier associated with a user in a first field; 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 in the first field and the first account identifier in a second field; transmit the modified authorization request message to an issuer system associated with the second account identifier; receive an authorization response message for the payment transaction from the issuer system, the authorization response message comprising the second account identifier in the first field and the first account identifier in the second field;generate a modified authorization response message, the modified authorization response message comprising the first account identifier in the first field and the second account identifier in the second field; and transmit the modified authorization response message.

16. The computer program product of claim 15, wherein the instructions further cause the at least one processor to: receive rule data associated with the at least one rule, wherein the rule data comprises a threshold value; and determine whether a transaction amount of the payment transaction satisfies the threshold value.

17. The computer program product of claim 16, wherein, the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the second account identifier from the plurality of account identifiers based on the transaction amount satisfying the threshold value.

18. The computer program product of claim 15, wherein, the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the second account identifier from the plurality of account identifiers based on the at least one rule, wherein the at least one rule comprises at least one of: a default account identifier rule; a transaction amount rule; a transaction type rule; a cash withdrawal rule; a merchant category rule; a merchant identifier (ID) rule; a currency rule; a recurring payment rule; an override rule; a cross-border transaction rule;a time-based rule; or any combination thereof.

19. The computer program product of claim 15, wherein the instructions cause the at least one processor to: receive a settlement request message associated with the payment transaction, the settlement request message comprising the first account identifier in the first field and the second account identifier in the second field; and settle the payment transaction based on the second account identifier.

20. The computer program product of claim 15, wherein the first account identifier comprises a lead 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, when the instructions that cause the at least one processor to determine the second account identifier, cause the at least one processor to: select the selected virtual account identifier from the plurality of virtual account identifiers based on the at least one rule.

21. The computer program product of claim 20, wherein the lead 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