Systems, methods, and computer program products for updating transaction message api fields

Abstract

Methods for updating application programming interface (API) fields of a transaction message can include receiving, with at least one processor, a payment transaction message, wherein the payment transaction message includes data associated with a payment transaction; determining, with at least one processor, one or more API fields of the payment transaction message based on the data associated with the payment transaction; and modifying, with at least one processor, the one or more API fields of the payment transaction message. Methods can also include transmitting, with at least one processor, the modified payment transaction message based on modifying the one or more API fields of the payment transaction message. Systems and computer program products are also disclosed.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 711,530, filed December 12, 2019, the disclosure of which is hereby incorporated by reference in its entirety. TECHNICAL FIELD

[0003] The present disclosure relates generally to transaction processing, and in some non-limiting embodiments or aspects, to systems, methods, and computer program products for updating application programming interface (API) fields of a payment transaction message. BACKGROUND

[0004] After a payment transaction is initiated (e.g., at a point-of-sale (POS) terminal or an automated teller machine (ATM)), a message can be generated that is transmitted across an electronic payment processing network. This message can comply with one or more message standards (e.g., International Organization for Standardization (ISO) 8583, etc.). By having the message comply with the message standard, one or more systems that receive the message can accurately identify values associated with transaction parameters of the payment transaction and process the payment transaction. However, in some instances, systems can be configured to process messages generated in accordance with different standards. As a result, systems that receive messages that do not comply with the standard for which they are configured to process can forego processing such payment transactions. This, in turn, can result in additional communications between one or more systems included in the payment processing network in an attempt to process the payment transaction, which can reinitiate the payment transaction.

[0005] With such reinitiation, additional computing resources within the electronic payment processing network can need to be allocated and / or reserved for payment transactions that could not be processed due to noncompliance with the standard for which the receiving system is configured to process messages associated with payment transactions. This, in turn, can result in unnecessary expense of computing resources and, in some instances, also delay processing of subsequent payment transactions. SUMMARY

[0006] Accordingly, systems, methods, and computer program products are disclosed for improving accuracy and efficiency of processing payment transactions by updating application programming interface (API) fields when processing payment transactions.

[0007] According to some non-limiting embodiments or aspects, a computer-implemented method for updating API fields of a transaction message is provided. The computer-implemented method can include receiving, with at least one processor, a payment transaction message, wherein the payment transaction message includes data associated with a payment transaction; determining, with at least one processor, a plurality of API fields of the payment transaction message based on the data associated with the payment transaction; modifying, with at least one processor, one or more API fields of the payment transaction message; and sending, with at least one processor, a modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0008] According to some non-limiting embodiments or aspects, a system is provided that includes at least one processor programmed or configured to: receive a payment transaction message, wherein the payment transaction message includes data associated with a payment transaction; determine one or more API fields of the payment transaction message based on the data associated with the payment transaction; determine an API field requirement associated with the payment transaction message based on the data associated with the payment transaction; compare the API field requirement to the one or more API fields of the payment transaction message; determine that the one or more API fields of the payment transaction message are to be modified; modify the one or more API fields of the payment transaction message based on determining that the one or more API fields of the payment transaction are to be modified; and send a modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0009] According to some non-limiting embodiments or aspects, a computer program product is provided that includes at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive a payment transaction message, the payment transaction message including data associated with a payment transaction, the payment transaction message associated with a route through an electronic payment processing network; determine one or more API fields of the payment transaction message based on the route through the electronic payment processing network; modify one or more API fields of the payment transaction message; and send a modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

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

[0011] Clause 1 : A method comprising: receiving, with at least one processor, a payment transaction message, wherein the payment transaction message comprises data associated with a payment transaction; determining, with at least one processor, one or more application programming interface (API) fields of the payment transaction message based on the data associated with the payment transaction; modifying, with at least one processor, the one or more API fields of the payment transaction message; and transmitting, with at least one processor, the modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0012] Clause 2: The method of clause 1, further comprising: determining, based on the data associated with the payment transaction, API field requirements associated with the payment transaction message; comparing the API field requirements to the one or more API fields of the payment transaction message; and determining that the one or more API fields of the payment transaction message are to be modified.

[0013] Clause 3: The method of clause 1 or 2, wherein the payment transaction message is a first payment transaction message, and wherein determining, based on the data associated with the payment transaction, one or more API fields of the payment transaction message comprises: determining a first one or more API fields of the first payment transaction message associated with a first route of the first payment transaction message through an electronic payment processing network; the method further comprising: determining a second one or more API fields of a second payment transaction message associated with a second route of the second payment transaction message through the electronic payment processing network; comparing the first one or more API fields of the first payment transaction message to the second one or more API fields of the second payment transaction message; determining, based on comparing the one or more API fields of the second payment transaction message associated with the first route of the first payment transaction message through the electronic payment processing network to the one or more API fields of the payment transaction message, that the one or more API fields of the second payment transaction message are to be modified; and transmitting, based on modifying the one or more API fields of the second payment transaction message, a modified second payment transaction message on the first route through the electronic payment processing network.

[0014] Clause 4: The method of any one of clauses 1-3, wherein modifying the one or more API fields of the payment transaction message comprises: modifying one or more merchant API fields of the one or more API fields of the payment transaction message, wherein the one or more merchant API fields are associated with a merchant that sent the payment transaction message; and wherein sending the modified payment transaction message comprises: sending the modified payment transaction message based on a route through an electronic payment processing network associated with the merchant.

[0015] Clause 5: The method of any one of clauses 1-4, wherein the one or more API fields comprise at least one of: an address verification system (AVS) field; a payment installment field; or any combination thereof.

[0016] Clause 6: The method of any one of clauses 1-5, further comprising: determining that the one or more API fields of the payment transaction message are to be modified based on an API field requirement associated with a merchant that sent the payment transaction message.

[0017] Clause 7: The method of any one of clauses 1-6, wherein the payment transaction message comprises a payload, and wherein modifying the one or more API fields of the payment transaction message comprises: modifying the one or more API fields of the payment transaction message independently of modifying the payload of the payment transaction message.

[0018] Clause 8: A system comprising: at least one processor programmed or configured to: receive a payment transaction message, wherein the payment transaction message comprises data associated with a payment transaction; determine one or more application programming interface (API) fields of the payment transaction message based on the data associated with the payment transaction; determine an API field requirement associated with the payment transaction message based on the data associated with the payment transaction; compare the API field requirement to the one or more API fields of the payment transaction message; determine that the one or more API fields of the payment transaction message are to be modified; modify the one or more API fields of the payment transaction message based on determining that the one or more API fields of the payment transaction are to be modified; and send a modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0019] Clause 9: The system of clause 8, wherein the payment transaction message is a first payment transaction message, and wherein when determining the one or more API fields of the payment transaction message based on the data associated with the payment transaction, the at least one processor is programmed or configured to: determine first one or more API fields of the first payment transaction message associated with a first route of the first payment transaction message through an electronic payment processing network; wherein the at least one processor is further programmed or configured to: determine second one or more API fields of a second payment transaction message associated with a second route of the second payment transaction message through the electronic payment processing network; compare the first one or more API fields of the first payment transaction message to the second one or more API fields of the second payment transaction message; determine that the one or more API fields of the second payment transaction message are to be modified based on comparing the one or more API fields of the second payment transaction message associated with the first route of the first payment transaction message through the electronic payment processing network to the one or more API fields of the payment transaction message; and send a modified second payment transaction message on the first route through the electronic payment processing network based on modifying one or more API fields of the second payment transaction message.

[0020] Clause 10: The system of clause 8 or 9, wherein when modifying the one or more API fields of the payment transaction message, the at least one processor is programmed or configured to: modify one or more merchant API fields of the one or more API fields of the payment transaction message, wherein the one or more merchant API fields are associated with a merchant sending the payment transaction message; and wherein when sending the modified payment transaction message, the at least one processor is programmed or configured to: send the modified payment transaction message based on a route through an electronic payment processing network associated with the merchant.

[0021] Clause 11: The system of any of clauses 8 to 10, wherein the one or more API fields comprise at least one of: an address verification system (AVS) field; a payment installment field; or any combination thereof.

[0022] Clause 12: The system of any of clauses 8 to 11, wherein the at least one processor is further programmed or configured to: determine that the one or more API fields of the payment transaction message are to be modified based on an API field requirement associated with a merchant sending the payment transaction message.

[0023] Clause 13: The system of any of clauses 8-12, wherein when the payment transaction message includes a payload, and when the at least one processor modifies the one or more API fields of the payment transaction message, the at least one processor is programmed or configured to modify the one or more API fields of the payment transaction message independently of modifying the payload of the payment transaction message.

[0024] Clause 14: A computer program product comprising at least one non-transitory computer- readable medium comprising one or more instructions, which, when executed by at least one processor, cause the at least one processor to: receive a payment transaction message, the payment transaction message comprising data associated with a payment transaction, the payment transaction message being associated with a route through an electronic payment processing network; determine one or more application programming interface (API) fields of the payment transaction message based on the route through the electronic payment processing network; modify one or more API fields of the payment transaction message; and send a modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0025] Clause 15: The computer program product of clause 14, wherein the one or more instructions further cause the at least one processor to: determine an API field requirement associated with the payment transaction message based on the data associated with the payment transaction; compare the API field requirement to the one or more API fields of the payment transaction message; and determine that the one or more API fields of the payment transaction message are to be modified.

[0026] Clause 16: The computer program product of clause 14 or 15, wherein the payment transaction message is a first payment transaction message, and wherein the one or more instructions further cause the at least one processor to: determine a second one or more API fields of a second payment transaction message associated with a second route of the second payment transaction message through the electronic payment processing network; compare the first one or more API fields of the first payment transaction message to the second one or more API fields of the second payment transaction message; determine that the one or more API fields of the second payment transaction message are to be modified based on comparing the one or more API fields of the second payment transaction message associated with the first route of the first payment transaction message through the electronic payment processing network to the one or more API fields of the payment transaction message; and send a modified second payment transaction message on the first route through the electronic payment processing network based on modifying one or more API fields of the second payment transaction message.

[0027] Clause 17: The computer program product of any one of Clauses 14-16, wherein the one or more instructions that cause the at least one processor to modify the one or more API fields of the payment transaction message cause the at least one processor to: modify one or more merchant API fields of the one or more API fields of the payment transaction message, wherein the one or more merchant API fields are associated with a merchant that sent the payment transaction message; and wherein the one or more instructions that cause the at least one processor to send the modified payment transaction message cause the at least one processor to: send the modified payment transaction message based on a route through an electronic payment processing network associated with the merchant.

[0028] Clause 18: The computer program product of any one of Clauses 14-17, wherein the one or more API fields comprise at least one of: an address verification computer program product (AVS) field; a payment installment field; or any combination thereof.

[0029] Clause 19: The computer program product of any one of Clauses 14-18, wherein the one or more instructions further cause the at least one processor to: determine that the one or more API fields of the payment transaction message are to be modified based on an API field requirement associated with a merchant that sent the payment transaction message.

[0030] Clause 20: The computer program product of any one of Clauses 14-19, wherein when the payment transaction message comprises a payload, and when the one or more instructions cause the at least one processor to modify the one or more API fields of the payment transaction message, the one or more instructions cause the at least one processor to: modify the one or more API fields of the payment transaction message independently of modifying the payload of the payment transaction message.

[0031] These and other features and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structure 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 purposes of illustration and description only and are not intended as a definition of the limits of the disclosure. As used in the specification and the claims, the singular form of “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1FIG. 1 is a diagram of a non-limiting embodiment or aspect of an example environment of an application programming interface (API) field of a transaction message being updated;

[0033] Figure 2 FIG. 1 is a diagram of a non-limiting embodiment or aspect of an example environment of an application programming interface (API) field of a transaction message being updated; Figure 1 FIG. 1 is a diagram of a non-limiting embodiment or aspect of an example environment of an application programming interface (API) field of a transaction message being updated;

[0034] Figure 3 FIG. 1 is a diagram of a non-limiting embodiment or aspect of an example environment of an application programming interface (API) field of a transaction message being updated;

[0035] Figures 4A-4G FIG. 1 is a diagram of a non-limiting embodiment or aspect of an example environment of an application programming interface (API) field of a transaction message being updated. DETAILED DESCRIPTION

[0036] For the 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 disclosure as it is oriented in the drawings. However, it is to be understood that the disclosure can assume various alternative orientations 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 present disclosure. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting, unless otherwise indicated.

[0037] No aspect, component, element, structure, act, step, function, instruction, or the like expressed herein is intended to be, nor should be construed as, a critical or essential element, or means. Additionally, as used herein, the article "a" is intended to include one or more items, and can be used interchangeably with "one or more" and "at least one." Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.), and can 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 in part, on" unless explicitly stated otherwise.

[0038] As used herein, the terms “communication” and “communicate” can refer to the reception, receipt, transmission, transfer, provision, and / or the like of information (e.g., data, signals, messages, instructions, commands, and / or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and / or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and / or transmit information to the other unit. This can refer to a direct or indirect connection, whether wired and / or wireless, between the one unit and the other unit. Additionally, two units can be in communication with each other even though the information transmitted can be modified, processed, relayed, and / or routed between the first unit and the second unit. For example, a first unit can be in communication with a second unit even though the first unit passively receives information from the second unit without actively transmitting information to the second unit. As another example, a first unit can be in communication with a second unit if at least one intermediary unit (e.g., a third unit positioned between the first unit and the second unit) processes information received from the first unit and transmits process information to the second unit. In some non-limiting embodiments or aspects, a message can refer to a network packet (e.g., a data packet, and / or the like) that includes data.

[0039] As used herein, the terms “issuer,” “issuer institution,” “issuer bank,” or “payment device issuer” can refer to one or more entities that provide an account to an individual (e.g., a user, a customer, and / or the like) for conducting payment transactions, such as credit payment transactions and / or debit payment transactions. For example, an issuer institution can provide a customer with an account identifier, such as a primary account number (PAN), that uniquely identifies one or more accounts associated with the customer. In some non-limiting embodiments or aspects, an issuer can be associated with a bank identification number (BIN) that uniquely identifies the issuer institution. As used herein, an “issuer system” can refer to one or more computer systems operated by or on behalf of an issuer, such as a server executing one or more software applications. For example, an issuer system can include one or more authorization servers for authorizing transactions.

[0040] As used herein, the term“account identifier” can include one or more types of identifiers associated with an account (e.g., a PAN associated with an account, a card number associated with an account, a payment card number associated with an account, a token associated with an account, etc.). In some non-limiting embodiments or aspects, an issuer can provide an account identifier (e.g., a PAN, a token, etc.) to a user that uniquely identifies one or more accounts associated with the user. An account identifier can be embodied on a payment device (e.g., a physical instrument for conducting payment transactions, such as a payment card, a credit card, a debit card, a gift card, etc.) and / or can be electronic information communicated to a user that the user can use for electronic payment transactions. In some non-limiting embodiments or aspects, an account identifier can be an original account identifier, where the original account identifier is provided to a user when an account associated with the account identifier is created. In some non-limiting embodiments or aspects, an account identifier can be a supplemental account identifier, which can include an account identifier that is provided to a user after the original account identifier is provided to the user. For example, a supplemental account identifier can be provided to a user if the original account identifier is forgotten, stolen, etc. In some non-limiting embodiments or aspects, an account identifier can be directly or indirectly associated with an issuer institution, such that the account identifier can be a token that maps to a PAN or other type of account identifier. An account identifier can be any combination of alphanumeric, character, and / or symbol, etc.

[0041] As used herein, the term“token” can refer to an account identifier that is used as a substitute for or in place of another account identifier (e.g., a PAN). A token can be associated with a PAN or another original account identifier in one or more data structures (e.g., one or more databases, etc.), such that the token can be used to conduct payment transactions without directly using the original account identifier. In some non-limiting embodiments or aspects, an original account identifier, such as a PAN, can be associated with multiple tokens for different individuals or purposes. In some non-limiting embodiments or aspects, a token can be associated with a PAN or other account identifier in one or more data structures, such that the token can be used to conduct transactions without directly using the PAN or other account identifier. In some examples, an account identifier, such as a PAN, can be associated with multiple tokens for different uses or purposes.

[0042] As used herein, the term“merchant” can refer to one or more entities (e.g., an operator of a retail business) that provide goods and / or services and / or access to goods and / or services to users (e.g., customers, consumers, etc.) based on transactions, such as payment transactions. As used herein, a“merchant system” can refer to one or more computer systems operated by or on behalf of a merchant, such as a server executing one or more software applications. As used herein, the term“product” can refer to one or more goods and / or services provided by a merchant.

[0043] As used herein, the term“point-of-sale (POS) device” can refer to one or more devices that can be used by a merchant to conduct transactions (e.g., payment transactions) and / or process transactions. For example, a POS device can include one or more client devices. Additionally or alternatively, a POS device can include a peripheral device, a card reader, a scanning device (e.g., a code scanner), a Bluetooth® communication receiver, a near-field communication (NFC) receiver, a radio-frequency identification (RFID) receiver, and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, etc.

[0044] As used herein, the term“point-of-sale (POS) system” can refer to one or more client devices and / or peripheral devices used by a merchant to conduct transactions. For example, a POS system can include one or more POS devices, and / or other similar devices that can be used to conduct payment transactions. In some non-limiting embodiments or aspects, a POS system (e.g., a merchant POS system) can include one or more server computers programmed or configured to process online payment transactions through a web page, a mobile application, etc.

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

[0046] As used herein, the term “acquirer” can refer to an entity licensed by and approved by a transaction service provider to initiate transactions (e.g., payment transactions) involving payment devices associated with the transaction service provider. As used herein, the term “acquirer system” can also refer to one or more computer systems, computer devices, etc. operated by or on behalf of an acquirer. Transactions that an acquirer can initiate can include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), etc.). In some non-limiting embodiments or aspects, an acquirer can be authorized by a transaction service provider to contract with merchants or service providers to initiate transactions involving payment devices associated with the transaction service provider. An acquirer can contract with a payment service provider to enable the payment service provider to offer sponsorship to merchants. An acquirer can monitor the compliance of a payment service provider according to transaction service provider regulations. An acquirer can conduct due diligence on a payment service provider and ensure that proper due diligence occurs prior to contracting with a sponsored merchant. An acquirer can be liable for all transaction service provider programs operated or sponsored by the acquirer. An acquirer can be responsible for the actions of acquirer payment service providers, merchants sponsored by acquirer payment service providers, etc. In some non-limiting embodiments or aspects, an acquirer can be a financial institution, such as a bank.

[0047] As used herein, the term “payment gateway” can refer to an entity and / or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment service broker, a payment service broker in contract with an acquirer, a payment aggregator, etc.) that provides payment services (e.g., transaction service provider payment services, payment processing services, etc.) to one or more merchants. The payment services can be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term “payment gateway system” can refer to one or more computer systems, computer devices, servers, groups of servers, etc. operated by or on behalf of a payment gateway.

[0048] As used herein, the terms “electronic wallet,” “electronic wallet mobile application,” and “digital wallet” can refer to one or more electronic devices, including one or more software applications, configured to initiate and / or conduct a transaction (e.g., a payment transaction, an electronic payment transaction, etc.). For example, an electronic wallet can include a user device (e.g., a mobile device) executing an application, as well as server-side software and / or databases for maintaining and providing data to the user device to be used during a payment transaction. As used herein, the term “electronic wallet provider” can include an entity that provides and / or maintains an electronic wallet and / or an electronic wallet mobile application for a user (e.g., a customer). Examples of electronic wallet providers include, but are not limited to, Google Pay®, Android Pay®, Apple Pay®, and Samsung Pay®. In some non-limiting examples, a financial institution (e.g., an issuer institution) can be an electronic wallet provider. As used herein, the term “electronic wallet provider system” can refer to one or more computer systems, computer devices, servers, groups of servers, etc., operated by or on behalf of an electronic wallet provider.

[0049] As used herein, the term “payment device” can refer to, for example, a portable financial device, an electronic payment device, a payment card (e.g., a credit or debit card), a gift card, a smart card, a smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or membership card, etc. A payment device can include volatile or non-volatile memory to store information (e.g., an account identifier, an account holder’s name, etc.).

[0050] As used herein, the terms “client” and “client device” can refer to one or more computing devices, such as a processor, a storage device, and / or similar computer components that access services that can be provided by a server. In some non-limiting embodiments or aspects, a “client device” can refer to one or more devices that facilitate a payment transaction, such as a POS device and / or POS system used by a merchant. In some non-limiting embodiments or aspects, a client device can include an electronic device configured to communicate with one or more networks and / or facilitate a payment transaction, such as, but not limited to, one or more desktop computers, one or more portable computers (e.g., tablet computers), one or more mobile devices (e.g., cellular phones, smart phones, PDAs, wearable devices such as watches, glasses, lenses, and / or clothing, etc.), and / or similar devices. Further, a “client” can also refer to an entity that owns, utilizes, and / or operates a client device to facilitate a payment transaction with a transaction service provider, such as a merchant.

[0051] As used herein, the term "server" can refer to one or more computing devices, such as processors, storage devices, and / or similar computer components, that communicate with client devices and / or other computing devices over a network, such as the Internet or a private network, and in some examples, facilitate communication between other servers and / or client devices.

[0052] As used herein, the term "system" can refer to one or more computing devices or combinations of computing devices, such as but not limited to processors, servers, client devices, software applications, and / or other similar components. Moreover, as used herein, a reference to a "server" or a "processor" can refer to a previously recited server and / or processor recited as performing a previous step or function, a different server and / or processor, and / or a combination of servers and / or processors. For example, as used in the specification and claims, a first server and / or a first processor recited as performing a first step or function can refer to the same or a different server and / or processor recited as performing a second step or function.

[0053] Improved systems, methods, and computer program products are provided for updating API fields of transaction messages. In some non-limiting embodiments or aspects, a method can include receiving, with at least one processor, a payment transaction message, wherein the payment transaction message includes data associated with a payment transaction; determining, with at least one processor, one or more API fields of the payment transaction message based on the data associated with the payment transaction; modifying, with at least one processor, the one or more API fields of the payment transaction message; and sending, with at least one processor, the modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0054] By implementing the systems, methods, and computer program products described herein, systems can be developed and / or implemented that enable the systems to modify messages associated with payment transactions to enable systems that receive the messages (e.g., issuer systems) to successfully process the payment transactions (e.g., determine whether to authorize or decline the payment transaction). By virtue of the features disclosed in the present disclosure, additional computing resources within an electronic payment processing network can not need to be allocated and / or reserved for payment transactions that cannot be processed due to not meeting criteria with which a receiving system is configured to process messages associated with payment transactions. This, in turn, can result in conservation of computing resources, and in some cases, speed up subsequent processing of payment transactions and improve accuracy of processing payment transactions.

[0055] Reference is now made to Figure 1 , Figure 1 is a diagram of a non-limiting embodiment of an example environment 100 in which the apparatuses, systems, methods, and / or products described herein can be implemented. As Figure 1As shown, the environment 100 includes a transaction processing network 101, a user device 102, a merchant system 104, a payment gateway system 106, an acquirer system 108, a transaction service provider system 110, and / or an issuer system 112. The transaction processing network 101, the user device 102, the merchant system 104, the payment gateway system 106, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112 can be interconnected (e.g., establish connections to communicate, etc.) by wire, wireless, or a combination of both wired and wireless connections.

[0056] The user device 102 can include one or more devices configured to communicate with the merchant system 104, the payment gateway system 106, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112 via the communication network 114 and / or other networks. For example, the user device 102 can include a client device, etc. The user device 102 can be configured to transmit data to and / or receive data from the merchant system 104 via an imaging system and / or a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, etc.). In some non-limiting embodiments or aspects, the user device 102 can be associated with a user (e.g., an individual operating the device). In some non-limiting embodiments or aspects, the user device 102 can include an application associated with the user device 102 (e.g., an application stored on the user device 102, such as a mobile device application, a native application of a mobile device, a mobile cloud application of a mobile device, an electronic wallet application, a peer-to-peer payment transfer application, etc.).

[0057] The merchant system 104 can include one or more computing devices configured to communicate with the user device 102, the payment gateway system 106, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112 via the communication network 114 and / or other networks. For example, the merchant system 104 can include one or more computing devices, such as servers, groups of servers, client devices, groups of client devices, and / or other similar devices, configured to send data to and / or receive data from the user device 102, the payment gateway system 106, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112 via the communication network 114 and / or other networks. In some non-limiting embodiments or aspects, the merchant system 104 can include a point-of-sale (POS) device. In some non-limiting embodiments or aspects, the merchant system 104 can be associated with a merchant as described herein. In some non-limiting embodiments or aspects, the merchant system 104 can include an application associated with the merchant system 104 (e.g., an application stored on the merchant system 104, such as an application, a native application, a cloud application, a mobile device application, a native application for a mobile device, a mobile cloud application for a mobile device, a digital wallet application, a peer-to-peer payment transfer application, and / or the like).

[0058] The payment gateway system 106 can include one or more computing devices configured to communicate with the user device 102, the merchant system 104, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112 via the communication network 114 and / or other networks. For example, the payment gateway system 106 can include servers, groups of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the payment gateway system 106 can be associated with a payment gateway as described herein.

[0059] The acquirer system 108 can include one or more computing devices configured to communicate with the user device 102, the merchant system 104, the payment gateway system 106, the transaction service provider system 110, and / or the issuer system 112 via the communication network 114 and / or other networks. For example, the acquirer system 108 can include servers, groups of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the acquirer system 108 can be associated with an acquirer as described herein.

[0060] The transaction service provider system 110 can include one or more computing devices configured to communicate with the user device 102, the merchant system 104, the payment gateway system 106, the acquirer system 108, and / or the issuer system 112 via the communication network 114 and / or other networks. For example, the transaction service provider system 110 can include a server (e.g., a transaction processing server), a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction service provider system 110 can be associated with a transaction service provider described herein.

[0061] The issuer system 112 can include one or more computing devices configured to communicate with the user device 102, the merchant system 104, the payment gateway system 106, the acquirer system 108, and / or the transaction service provider system 110 via the communication network 114 and / or other networks. For example, the issuer system 112 can include a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the issuer system 112 can be associated with an issuer institution that issues payment accounts and / or instruments (e.g., credit accounts, debit accounts, credit cards, debit cards, etc.) to users (e.g., a user associated with the user device 102, etc.).

[0062] In some non-limiting embodiments or aspects, the transaction processing network 101 includes multiple systems in a communication path for processing transactions. For example, the transaction processing network 101 can include the merchant system 104, the payment gateway system 106, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112 in a communication path (e.g., a communication path, a communication channel, a communication network, etc.). For example, the transaction processing network 101 can process (e.g., initiate, conduct, authorize, etc.) an electronic payment transaction via a communication path between the merchant system 104, the payment gateway system 106, the acquirer system 108, the transaction service provider system 110, and / or the issuer system 112.

[0063] The communication network 114 can include one or more wired and / or wireless networks. For example, the communication network 114 can include a cellular network (e.g., a long-term evolution (LTE) network, a third generation (3G) network, a fourth generation (4G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a

[0064] Provided by way of example Figure 1the number and arrangement of systems and / or devices shown. There can be additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, or differently arranged systems and / or devices than those shown. Figure 1 Moreover, the two or more systems and / or devices shown can be implemented within a single system and / or a single device, or Figure 1 Figure 1 the single system or the single device shown can be implemented as multiple, distributed systems or devices. Additionally or alternatively, a set of systems or a set of devices (e.g., one or more systems, one or more devices) of environment 100 can perform one or more functions described as being performed by another set of systems or another set of devices of environment 100.

[0065] Reference is now made to Figure 2 , Figure 2 is a diagram of example components of a device 200. Device 200 can correspond to one or more devices of transaction processing network 101, one or more devices of user devices 102 (e.g., one or more devices of a system of user devices 102), one or more devices of merchant systems 104, one or more devices of payment gateway systems 106, one or more devices of acquirer systems 108, one or more devices of transaction service provider systems 110, one or more devices of issuer systems 112, and / or one or more devices of communication network 114. In some non-limiting embodiments or aspects, one or more devices of user devices 102, one or more devices of merchant systems 104, one or more devices of payment gateway systems 106, one or more devices of acquirer systems 108, one or more devices of transaction service provider systems 110, one or more devices of issuer systems 112, and / or one or more devices of communication network 114 can include at least one device 200 and / or at least one component of device 200.

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

[0067] The storage component 208 can store information and / or software related to the operation and use of the apparatus 200. For example, the storage component 208 can include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of computer- readable medium, along with a corresponding drive.

[0068] The input component 210 can include a component that permits the apparatus 200 to receive information, such as via a user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, a camera, etc.). Additionally, or alternatively, the input component 210 can include a sensor (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.) for sensing information. The output component 212 can include a component that provides output information from the apparatus 200 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).

[0069] The communication interface 214 can include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the apparatus 200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 214 can permit the apparatus 200 to receive information from another device and / or provide information to another device. For example, the communication interface 214 can 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 Bluetooth® interface, a Zigbee® interface, a cellular network interface, etc.

[0070] The apparatus 200 can perform one or more processes described herein. The apparatus 200 can perform these processes based on the processor 204 executing software instructions stored by a computer-readable medium, such as the memory 206 and / or the storage component 208. A computer-readable medium (e.g., a non-transitory computer-readable medium) is defined herein as a non-transitory memory device. A non-transitory memory device includes a memory space located inside of a single physical storage device or a memory space spread across multiple physical storage devices.

[0071] The software instructions can be read into the memory 206 and / or the storage component 208 from another computer-readable medium or from another device via the communication interface 214. When executed, the software instructions stored in the memory 206 and / or the storage component 208 can cause the processor 204 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry can be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments or aspects described herein are not limited to any specific combination of hardware circuitry and software.

[0072] The memory 206 and / or the storage component 208 can include a data store or one or more data structures (e.g., a database, etc.). The apparatus 200 can receive information from, store information in, communicate information to, or retrieve information from the data store or one or more data structures in the memory 206 and / or the storage component 208. For example, the information can include clearing record data, input data, output data, transaction data, account data, or any combination thereof.

[0073] The number and arrangement of components shown in Figure 2 The apparatus 200 can include additional components, fewer components, different components, or differently arranged components than those shown in Figure 2 Additionally or alternatively, a set of components (e.g., one or more components) of the apparatus 200 can perform one or more functions described as being performed by another set of components of the apparatus 200.

[0074] Reference is now made to Figure 3 , Figure 3This is a flowchart of a non-limiting aspect or embodiment of process 300 for updating API fields of transaction messages. In some non-limiting embodiments or aspects, one or more functions described regarding process 300 may be performed by transaction service provider system 110 (e.g., wholly, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 300 may be performed by another device or group of devices (e.g., user device 102, merchant system 104, payment gateway system 106, acquiring system 108, and / or issuing system 112) separate from and / or including said transaction service provider system 110 (e.g., wholly, partially, etc.).

[0075] like Figure 3 As shown, in step 302, process 300 may include receiving a payment transaction message. For example, payment gateway system 106 may receive a payment transaction message that includes data associated with a payment transaction involving a user associated with user device 102 and a merchant associated with merchant system 104. In some non-limiting embodiments, payment gateway system 106 may receive a payment transaction message from acquiring system 108 based on acquiring system 108 receiving data associated with a payment transaction. For example, acquiring system 108 may send a payment transaction message including data associated with a payment transaction to payment gateway system 106 based on acquiring system 108 receiving data associated with a payment transaction from merchant system 104. In such examples, acquiring system 108 may generate a payment transaction message. For example, acquiring system 108 may send a payment transaction message including data associated with a payment transaction to payment gateway system 106 based on acquiring system 108 receiving a payment transaction message from merchant system 104 (e.g., in response to and / or after this). In such an example, merchant system 104 can generate a payment transaction message based on data associated with the payment transaction determined by merchant system 104.

[0076] In some non-limiting embodiments or aspects, the acquiring system 108 may generate a payment transaction message based on data associated with the payment transaction received by the acquiring system 108 from the merchant system 104. For example, the acquiring system 108 may generate the payment transaction message based on the data associated with the payment transaction and messaging standards (e.g., templates for generating transaction messages, templates defining one or more API fields). In some non-limiting embodiments or aspects, messaging standards may be associated with the acquiring system 108. In another example, messaging standards may be associated with the payment gateway system 106 and / or the issuing system 112.

[0077] like Figure 3As shown, at step 304, process 300 can include determining a plurality of application programming interface (API) fields of the payment transaction message. For example, payment gateway system 106 can determine one or more API fields of the payment transaction message based on data included in the payment transaction message that is associated with the payment transaction. In such examples, payment gateway system 106 can determine the one or more API fields of the payment transaction message based on an acquirer system 108 from which payment gateway system 106 receives the payment transaction message. In another example, payment gateway system 106 can determine the one or more API fields of the payment transaction message based on an issuer system 112 to which the payment transaction message is addressed. In some non-limiting embodiments or aspects, payment gateway system 106 can determine the one or more API fields of the payment transaction message based on receiving the payment transaction message. For example, payment gateway system 106 can determine the one or more API fields of the payment transaction message based on payment gateway system 106 receiving the payment transaction message from acquirer system 108.

[0078] In some non-limiting embodiments or aspects, payment gateway system 106 can determine the one or more API fields of the payment transaction message based on payment gateway system 106 determining that the payment transaction message is associated with a route through an electronic payment processing network. For example, payment gateway system 106 can determine that the payment transaction message is associated with a route through an electronic payment processing network based on payment gateway system 106 determining that user device 102 and / or merchant system 104 participate in the payment transaction. Additionally or alternatively, payment gateway system 106 can determine that the payment transaction message is associated with a route through an electronic payment processing network based on determining that issuer system 112 participates in the payment transaction. For example, payment gateway system 106 can determine that issuer system 112 participates in the payment transaction based on payment gateway system 106 determining that a payment account associated with user device 102 (e.g., issued to a user associated with user device 102) is associated with issuer system 112.

[0079] In some non-limiting embodiments or aspects, one or more of the one or more API fields of the payment transaction message can be associated with one or more of: an address verification system (AVS) field, a payment installment field, an API field associated with a custom code of one or more systems associated with a route through the electronic payment processing network, and / or other similar fields. For example, a first API field of the one or more API fields of the payment transaction message can be an AVS field that corresponds to data associated with an address involved in the payment transaction (e.g., an address associated with the user device 102 and / or the merchant system 104). In another example, a second API field of the one or more API fields of the payment transaction message can be a payment installment field that corresponds to data associated with a payment installment type (e.g., an instruction to transfer funds from an account maintained by the issuer system 112 to the acquirer system 108 within a predetermined time period, immediately, etc.).

[0080] In some non-limiting embodiments or aspects, the payment gateway system 106 can determine API field requirements associated with the payment transaction message. For example, the payment gateway system 106 can determine the API field requirements associated with the payment transaction message based on data associated with the payment transaction included in the payment transaction message. The API field requirements can include, for example, one or more API fields that must be included in the payment transaction message for the payment transaction message to be successfully processed when sent along a route through the electronic payment processing network. Additionally or alternatively, the payment gateway system 106 can determine the API field requirements associated with the payment transaction message based on one or more previously processed payment transaction messages. For example, the payment gateway system 106 can determine the API field requirements associated with the payment transaction message based on one or more previously processed payment transaction messages. In such examples, the payment gateway system 106 can determine the API field requirements associated with the payment transaction message based on the one or more previously processed payment transaction messages, where the payment gateway system 106 determines that a route through the electronic payment processing network associated with the one or more previously processed payment transaction messages is associated with (e.g., partially and / or completely identical to) a route through the electronic payment processing network associated with the payment transaction message. In some non-limiting embodiments or aspects, the payment gateway system 106 can determine the API field requirements associated with the payment transaction message based on the payment gateway system 106 determining that the one or more previously processed payment transaction messages are associated with successfully processed payment transactions.

[0081] In some non-limiting embodiments or aspects, the payment gateway system 106 can compare the API field requirements to one or more API fields of the payment transaction message. For example, the payment gateway system 106 can compare the API field requirements to the one or more API fields of the payment transaction message based on the payment gateway system 106 determining that the API field requirements are associated with the payment transaction message. In some non-limiting embodiments or aspects, the payment gateway system 106 can determine that one or more API fields of the payment transaction message are to be modified. For example, the payment gateway system 106 can determine that one or more API fields of the payment transaction message are to be modified based on the API field requirements. In such examples, the payment gateway system 106 can compare the one or more API fields of the payment transaction message to the API field requirements, and the payment gateway system 106 can determine that the one or more API fields of the payment transaction message are to be modified based on the comparison of the one or more API fields of the payment transaction message to the API field requirements.

[0082] In some non-limiting embodiments or aspects, the payment gateway system 106 can determine that one or more API fields of the payment transaction message are to be modified based on API field requirements associated with a merchant participating in the payment transaction. For example, the payment gateway system 106 can determine that one or more API fields of the payment transaction message are to be modified based on one or more previously processed payment transaction messages associated with the merchant. In such examples, the payment gateway system 106 can determine API field requirements associated with the one or more previously processed payment transaction messages associated with the merchant, and the payment gateway system 106 can determine that the one or more API fields of the payment transaction message are to be modified based on the API field requirements associated with the one or more previously processed payment transaction messages.

[0083] In some non-limiting embodiments or aspects, the payment gateway system 106 can determine one or more API fields of a second payment transaction message. For example, the payment gateway system 106 can determine one or more API fields of a second payment transaction message previously received by the payment gateway system 106 and / or previously processed by the payment gateway system 106 (e.g., received by the payment gateway system 106 and sent to the issuer system 112). In such examples, the second payment transaction message can be associated with a route through the electronic payment processing network. In some non-limiting embodiments or aspects, the route through the electronic payment processing network associated with the second payment transaction message can be the same as or different from the route through the electronic payment processing network associated with the payment transaction message.

[0084] In some non-limiting embodiments or aspects, the payment gateway system 106 may compare one or more API fields of the second payment transaction message with one or more API fields of the payment transaction message. For example, the payment gateway system 106 may compare one or more API fields of the second payment transaction message with one or more API fields of the payment transaction message based on the payment gateway system 106 determining that the second payment transaction message and the payment transaction message are associated with each other (e.g., both the second payment transaction message and the payment transaction message are associated with the same route through the electronic payment processing network, both the second payment transaction message and the payment transaction message are associated with the merchant system 104, both the second payment transaction message and the payment transaction message are associated with the issuer system 112, etc.).

[0085] In some non-limiting embodiments or aspects, the payment gateway system 106 may determine that one or more API fields of the payment transaction message need to be modified based on comparing one or more API fields of the second payment transaction message with one or more API fields of the payment transaction message. For example, the payment gateway system 106 may determine that one or more API fields not included in the payment transaction message are included in the second payment transaction message. The payment gateway system 106 may then determine that one or more API fields included in the second payment transaction message will be included in the API fields of the payment transaction message. In another example, the payment gateway system 106 may determine that one or more API fields of the payment transaction message are not included in one or more API fields of the second payment transaction message. The payment gateway system 106 may then determine that one or more fields not included in the second payment transaction message but included in the payment transaction message are not included in one or more API fields of the payment transaction message.

[0086] like Figure 3 As shown, in step 306, process 300 may include modifying one or more application programming interface (API) fields of the payment transaction message. For example, payment gateway system 106 may modify one or more API fields of the payment transaction message. In such an example, payment gateway system 106 may modify one or more API fields of the payment transaction message based on a determination made by payment gateway system 106 that one or more API fields of the payment transaction message need to be modified.

[0087] In some non-limiting embodiments or aspects, the payment gateway system 106 can modify one or more API fields of the payment transaction message based on the payment gateway system 106 determining that the one or more API fields of the payment transaction message are merchant API fields associated with the merchant. For example, the payment gateway system 106 can modify one or more API fields of the payment transaction message based on the payment gateway system 106 determining that the one or more API fields of the payment transaction message are merchant API fields associated with the merchant. In such examples, the merchant API fields can correspond to data associated with the payment transaction and / or generated by the merchant system 104 that is associated with the payment transaction. In some non-limiting embodiments or aspects, the payment gateway system 106 can generate a modified payment transaction message based on modifying the one or more API fields of the payment transaction message.

[0088] In some non-limiting embodiments or aspects, the payment gateway system 106 can modify one or more API fields of the payment transaction message by the payment gateway system 106 including the one or more API fields in the payment transaction message. For example, the payment gateway system 106 can modify one or more API fields of the payment transaction message by the payment gateway system 106 including the one or more API fields in the payment transaction message and the one or more API fields including a default value (e.g., a default value for the payment transaction). In an example, the payment gateway system 106 can modify one or more API fields of the payment transaction message by the payment gateway system 106 including the one or more API fields in the payment transaction message and the one or more API fields including a value generated by the payment gateway system 106 based on data associated with the payment transaction. In some non-limiting embodiments or aspects, the payment gateway system 106 can modify one or more API fields of the payment transaction message based on one or more trends and / or a date at which the payment transaction is initiated. For example, the payment gateway system 106 can modify one or more API fields of the payment transaction message based on a trend that one or more parameters of the payment transaction are included in the payment transaction message when the payment transaction is processed. In another example, the payment gateway system 106 can modify one or more API fields of the payment transaction message based on a date at which the one or more API fields are requested (e.g., the one or more API fields can be requested during a time period associated with a holiday, etc.) during a particular date or range of dates.

[0089] In some non-limiting embodiments or aspects, the payment gateway system 106 may modify one or more API fields of the payment transaction message (e.g., data included in the payment transaction message, such as data associated with the payment transaction and / or other data included in the payment transaction message) independently of modifying the payload of the payment transaction message. For example, the payment gateway system 106 may modify one or more API fields of the payment transaction message, and the payment gateway system 106 may modify the payload of the payment transaction message based on modifying one or more API fields of the payment transaction message. In another example, the payment gateway system 106 may modify the payload of the payment transaction message before modifying one or more API fields of the payment transaction message. In this example, the payment gateway system 106 may modify one or more API fields of the payment transaction message, and the payment gateway system 106 may choose not to modify the payload of the payment transaction message.

[0090] like Figure 3 As shown, in step 308, process 300 may include sending a modified payment transaction message. For example, payment gateway system 106 may send a modified payment transaction message to issuer system 112. In such an example, payment gateway system 106 may send the modified payment transaction message based on modifications made by payment gateway system 106 to one or more API fields of the payment transaction message. Payment gateway system 106 may send the modified payment transaction message to issuer system 112 along a route through an electronic payment processing network. In some non-limiting embodiments or aspects, the route through the electronic payment processing network may be the same as the route associated with the payment transaction message. Alternatively or additionally, payment gateway system 106 may send the modified payment transaction message along a route different from the route associated with the payment transaction message (e.g., a route associated with a previously processed payment transaction message, a route associated with merchant system 104 participating in the payment transaction, a route associated with issuer system 112 participating in the payment transaction, etc.).

[0091] Figures 4A-4G This is a non-limiting embodiment or aspect of implementation 400 for updating API fields in transaction messages. (Example) Figure 4A As shown in –4G, implementation 400 may include a payment gateway system 406, an acquiring system 408, an issuing system 412, and a payment processing node 416. In some non-limiting embodiments or aspects, the payment gateway system 406 may be the same as or similar to the payment gateway system 106. In some non-limiting embodiments or aspects, the acquiring system 408 may be the same as or similar to the acquiring system 108. In some non-limiting embodiments or aspects, the issuing system 412 may be the same as or similar to the issuing system 112.

[0092] The payment processing node 416 can include one or more computing devices configured to communicate with the payment gateway system 406, the acquirer system 408, and / or the issuer system 412 via a communication network (e.g., the communication network 114 and / or a communication network that is the same as or similar to the communication network 114). For example, the payment processing node 416 can include a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the payment processing node 416 can be associated with a payment gateway, a transaction service provider, a merchant, an acquirer, an issuer, and / or the like, as described herein.

[0093] As shown by reference number 420 in Figure 4A The payment gateway system 406 can receive a first payment transaction message from the acquirer system 408, as shown by reference number 425 in

[0094] As shown by reference number 425 in Figure 4A The payment gateway system 406 can determine a plurality of API fields, as shown by reference number 430 in

[0095] As shown by reference number 430 in Figure 4B The payment gateway system 406 can send the first payment transaction message to the issuer system 412, as shown by reference number 435 in

[0096] As shown by reference number 435 in Figure 4CAs indicated by reference numeral 435 in the accompanying drawings, payment gateway system 406 can receive a second payment transaction message from acquiring system 408. For example, payment gateway system 406 may receive a second payment transaction message from acquiring system 408 based on data associated with a second payment transaction that is different from the payment transaction associated with the first payment transaction message. In such an example, payment gateway system 406 may receive a second payment transaction message from acquiring system 408 based on data associated with the second payment transaction received from the merchant system after acquiring system 408 has communicated with user device (e.g., user device 102 and / or different user devices) to initiate a second payment transaction.

[0097] like Figure 4C As indicated by reference numeral 440 in the accompanying drawings, the payment gateway system 406 can determine multiple API fields. For example, the payment gateway system 406 can determine multiple API fields of a second payment transaction message. In such an example, the payment gateway system 406 can determine multiple API fields of a second payment transaction message associated with a second route through an electronic payment processing network.

[0098] like Figure 4D As shown by reference numeral 445 in the accompanying drawings, the payment gateway system 406 can compare multiple API fields of a first payment transaction message with multiple API fields of a second payment transaction message. For example, the payment gateway system 406 can compare one or more API fields of the first payment transaction message with one or more API fields of the second payment transaction message, and the payment gateway system 406 can determine whether one or more API fields of the first payment transaction message are associated with and / or not associated with one or more API fields of the second payment transaction message.

[0099] like Figure 4E As indicated by reference numeral 450 in the accompanying drawings, the payment gateway system 406 can determine that one or more API fields need to be modified. For example, the payment gateway system 406 can determine that one or more API fields of a second payment transaction message need to be modified based on comparing multiple API fields of a first payment transaction message with multiple API fields of a second payment transaction message.

[0100] like Figure 4FAs indicated by reference numeral 455 in the accompanying drawings, payment gateway system 406 can modify one or more API fields of a second payment transaction message. For example, payment gateway system 406 can modify one or more API fields of the second payment transaction message based on a determination by payment gateway system 406 that one or more API fields of the second payment transaction message need to be modified. In some non-limiting embodiments or aspects, payment gateway system 406 may include and / or remove API fields from the second payment transaction message. For example, payment gateway system 406 may include in the second payment transaction message the same as or similar to API fields included in the first payment transaction message. In the example where payment gateway system 406 includes API fields in the second payment transaction, payment gateway system 406 can determine values ​​associated with the API fields included in the second payment transaction message, the values ​​being determined based on data and / or default values ​​associated with the payment transaction in the second payment transaction message. In some non-limiting embodiments or aspects, payment gateway system 406 can receive input (e.g., at payment gateway system 406) representing one or more new tasks (e.g., one or more API fields) to be included or excluded in payment transaction messages sent along one or more routes of an electronic payment processing network.

[0101] like Figure 4G As indicated by reference numeral 460 in the accompanying drawings, payment gateway system 406 can send a modified second payment transaction message. For example, payment gateway system 406 can send the modified second payment transaction message via a first route through the electronic payment processing network. In such examples, payment gateway system 406 can send the modified second payment transaction message via the first route through the electronic payment processing network based on modifications made by payment gateway system 406. In some non-limiting embodiments or aspects, after payment gateway system 406 modifies the payment transaction message, payment gateway system 406 can send the modified second payment transaction message via a second route through the payment processing network. In some non-limiting embodiments or aspects, payment gateway system 406 can send the second payment transaction message along the first or second route through the electronic payment processing network based on a determination by payment gateway system 406 that the first or second route through the electronic payment processing network is associated with a higher success rate in processing payment transactions. For example, the payment gateway system 406 may determine that a first route or a second route through the electronic payment processing network is associated with a higher success rate of processing payment transactions, and may determine that one or more payment transaction messages are successfully processed when sent along the first route or the second route through the electronic payment processing network, and send a second payment transaction message along the first route or the second route through the electronic payment processing network.

[0102] In some non-limiting embodiments or aspects, the payment gateway system 406 can generate a message including data associated with the modification of the second payment transaction message, and the payment gateway system 406 can transmit the message to the acquirer system 408. The acquirer system 408 can then modify one or more payment transaction messages generated after the second payment transaction message based on the modification of the second payment transaction message.

[0103] While the above method, system and computer program product have been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred embodiments or aspects, it is understood that such detail is solely for that purpose and that the disclosure is not limited to the described 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 instance, it is to be understood that the disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

1. A method for updating application programming interface (API) fields of a transaction message, comprising: receiving, with at least one processor, a first payment transaction message, wherein the first payment transaction message includes data associated with a first payment transaction involving a user associated with a user device and a merchant associated with a merchant system, and wherein the first payment transaction message conforms to a message standard for messages communicated on an electronic payment processing network; determining, with at least one processor, values for one or more API fields of the first payment transaction message based on the data associated with the payment transaction, wherein determining one or more values for an API field of a payment transaction message includes: determining a plurality of values for an API field of the first payment transaction message associated with a first route of the first payment transaction message through an electronic payment processing network; receiving, with at least one processor, a second payment transaction message, wherein the second payment transaction message includes data associated with a second payment transaction involving the user associated with the user device and the merchant associated with the merchant system, and wherein the second payment transaction message conforms to the message standard; determining values for a plurality of API fields of the second payment transaction message associated with a second route of the second payment transaction message through an electronic payment processing network; comparing the values for the plurality of API fields of the first payment transaction message with the values for the plurality of API fields of the second payment transaction message; determining, based on comparing the values for the plurality of API fields of the first payment transaction message with the values for the plurality of API fields of the second payment transaction message, values for one or more API fields of the second payment transaction message to modify; modifying, with at least one processor, the values for the one or more API fields of the second payment transaction message based on determining values for one or more API fields of the second payment transaction message to modify independent of modifying a payload of the second payment transaction message; and sending, with at least one processor, a modified payment transaction message based on modifying the values for the one or more API fields of the second payment transaction message via the first route through an electronic payment processing network.

2. The method of claim 1, further comprising: determining, based on the data associated with the second payment transaction, values for API field requirements associated with the second payment transaction message; comparing the values for the API field requirements with the one or more API fields of the second payment transaction message; and determining that the values for the one or more API fields of the second payment transaction message are to be modified.

3. The method of claim 1, wherein modifying the values for the one or more API fields of the second payment transaction message includes: modifying values for one or more merchant API fields of the values for the one or more API fields of the second payment transaction message, wherein the values for the one or more merchant API fields are associated with a merchant sending the second payment transaction message; and wherein sending the modified second payment transaction message includes: ​ ​ sending the modified second payment transaction message based on a route associated with the merchant through the electronic payment processing network.

4. The method of claim 1, wherein the values of the one or more API fields comprise at least one of: a value of an address verification system (AVS) field; a value of a payment installment field; or any combination thereof.

5. The method of claim 1, further comprising: determining that values of the one or more API fields of the second payment transaction message are to be modified based on values of API field requirements associated with a merchant that sent the second payment transaction message.

6. A system for updating application programming interface (API) fields of a transaction message, comprising: at least one processor programmed or configured to: receive a first payment transaction message, wherein the first payment transaction message comprises data associated with a first payment transaction, and wherein the first payment transaction message conforms to a message standard for messages communicated on an electronic payment processing network; determine values of one or more API fields of the first payment transaction message based on the data associated with the payment transaction, wherein when determining values of one or more API fields of a payment transaction message, the at least one processor is programmed or configured to: determine a plurality of values of API fields of the first payment transaction message associated with a first route of the first payment transaction message through an electronic payment processing network; receive a second payment transaction message, wherein the second payment transaction message comprises data associated with a second payment transaction, and wherein the second payment transaction message conforms to the message standard for messages communicated on the electronic payment processing network; determine values of a plurality of API fields of the second payment transaction message associated with a second route of the second payment transaction message through the electronic payment processing network; compare the values of the plurality of API fields of the first payment transaction message to the values of the plurality of API fields of the second payment transaction message; determine values of one or more API fields of the second payment transaction message that are to be modified based on comparing the values of the plurality of API fields of the first payment transaction message to the values of the plurality of API fields of the second payment transaction message; modify the values of the one or more API fields of the second payment transaction message based on determining that the values of one or more API fields of a payment transaction are to be modified independent of modifying a payload of the second payment transaction message; and send the modified second payment transaction message via the first route through the electronic payment processing network based on the values of the one or more API fields of the modified payment transaction message.

7. The system of claim 6, wherein when modifying the values of the one or more API fields of the second payment transaction message, the at least one processor is programmed or configured to: modify values of one or more merchant API fields of the values of the one or more API fields of the second payment transaction message, wherein the values of the one or more merchant API fields are associated with a merchant that sent the second payment transaction message; and ​ wherein when transmitting the modified second payment transaction message, the at least one processor is programmed or configured to: transmit the modified second payment transaction message based on a route through an electronic payment processing network associated with the merchant.

8. The system of claim 6, wherein the values of the one or more API fields comprise at least one of: a value of an address verification system (AVS) field; a value of a payment installment field; or any combination thereof.

9. The system of claim 6, wherein the at least one processor is further programmed or configured to: determine that values of the one or more API fields of the second payment transaction message are to be modified based on values of API field requirements associated with a merchant transmitting the second payment transaction message.

10. A computer program product for updating application programming interface (API) fields of a transaction message, comprising at least one non-transitory computer- readable medium including one or more instructions, which, when executed by at least one processor, cause the at least one processor to: receive a first payment transaction message, wherein the first payment transaction message includes data associated with a first payment transaction, and wherein the first payment transaction message conforms to a message standard for messages communicated on an electronic payment processing network; determine values of one or more API fields of the payment transaction message based on data associated with the first payment transaction, wherein the one or more instructions that cause the at least one processor to determine values of one or more API fields of a first payment transaction message further cause the processor to: determine a plurality of values of API fields of the first payment transaction message associated with a first route of the first payment transaction message through an electronic payment processing network; receive a second payment transaction message, wherein the second payment transaction message includes data associated with a second payment transaction, and wherein the second payment transaction message conforms to the message standard; determine values of a plurality of API fields of the second payment transaction message associated with a second route of the second payment transaction message through an electronic payment processing network; compare the values of the plurality of API fields of the first payment transaction message to the values of the plurality of API fields of the second payment transaction message; determine values of one or more API fields of the second payment transaction message that are to be modified based on comparing the values of the plurality of API fields of the first payment transaction message to the values of the plurality of API fields of the second payment transaction message; modify the values of the one or more API fields of the second payment transaction message based on determining that the values of one or more API fields of the second payment transaction are to be modified independent of modifying a payload of the second payment transaction message; and transmit a modified second payment transaction message based on modifying the values of the one or more API fields of the second payment transaction message via the first route through an electronic payment processing network.

11. The computer program product of claim 10, wherein the one or more instructions further cause the at least one processor to: ​ determining a value for an API field requirement associated with the second payment transaction message based on the data associated with the second payment transaction; comparing the value for the API field requirement to a value for the one or more API fields of the second payment transaction message; and determining that the value for the one or more API fields of the second payment transaction message is to be modified.

12. The computer program product of claim 10, wherein the one or more instructions that cause the at least one processor to modify the value for the one or more API fields of the second payment transaction message cause the at least one processor to: modify one or more merchant API fields of the value for the one or more API fields of the second payment transaction message, wherein the one or more merchant API fields are associated with a merchant that sent the second payment transaction message; and wherein the one or more instructions that cause the at least one processor to send the modified second payment transaction message cause the at least one processor to: send the modified second payment transaction message based on a route through an electronic payment processing network associated with the merchant.

13. The computer program product of claim 10, wherein the value for the one or more API fields comprises at least one of: a value for an address verification computer program product (AVS) field; a value for a payment installment field; or any combination thereof.

14. The computer program product of claim 10, wherein the one or more instructions further cause the at least one processor to: determine that the value for the one or more API fields of the second payment transaction message is to be modified based on a value for an API field requirement associated with a merchant that sent the second payment transaction message.

Images