Intelligent routing system and method

Abstract

Techniques are provided for intelligent routing to nodes in a network of transport computers, etc. A gateway server can receive an authorization request from a resource provider computer. Depending on the relationships established between the parties, there can be multiple potential transport computers to which the authorization request can be routed. Routing decisions can be made automatically based on real-time network measurements and / or static rules. Real-time network measurements can be obtained by monitoring transport computers for failures, delays, or other undesirable activity. The routing decisions can be further based on expected data volume (e.g., based on analysis of historical spikes in data volume). The routing decisions can be further based on user-configured rules and preferences received via a routing management interface.

Description

[0001] This application is a continuation-in-part of, and claims priority to, U.S. Patent Application No. 16 / 835, 1 10, filed March 20, 201 0, entitled "Intelligent Routing System and Method," which claims priority to International Application No. PCT / US2019 / 030265, filed May 1, 2019, which claims priority to U.S. Provisional Patent Application No. 62 / 850, 1 10, filed May 21, 2019, entitled "Intelligent Routing System and Method." BACKGROUND

[0002] In a distributed network, gateways perform the important function of routing messages to the appropriate destination. Computer networks enable different computers to cooperate to perform actions. For example, a first computer can issue a request that is sent to a gateway to route the request to a series of computers that cooperate to process the request. Each of these computers can perform a particular function. Increasingly, there can be multiple nodes in the network that can perform a particular function, creating routing options.

[0003] However, conventional authorized routing is prone to failure. At a given time, a computer in the network can be in a failure state, or overloaded with traffic, causing delays. If a particular computer cannot be accessed or is experiencing delays (e.g., due to infrastructure failure, system instability, maintenance, DDoS attack, etc.), messages can not move through the network in a timely manner.

[0004] Accordingly, there is a need for new systems and methods for automatically routing messages to the ideal destination, such as to one of several potential computers that can perform a given function. SUMMARY

[0005] Embodiments of the present disclosure include methods and systems for intelligently routing authorization requests to the appropriate transport computer using automated rules and real-time network measurements. The transport computer can be selected from a set of transport computers that have a relationship with a particular resource provider.

[0006] The automated rules can be used to create routing logic based on real-time network measurements. The network measurements can be determined by a gateway server that continuously or periodically monitors the set of transport computers. The gateway server can count failures or delays while maintaining a hysteresis threshold for controlling the flow of authorization messages between different communication networks to different transport computers.

[0007] The gateway server can determine transport computer availability based on response code, response time, and / or error discrimination. The gateway server can further determine a mapping specific to expected data volume (e.g., based on periodic volumn changes). The gateway server can further determine routing rules based on a percentage of requests to be routed to a transport computer (e.g., 50% of requests to transport computer 1 and 50% of requests to transport computer 2), based on weighted rules for response time, based on rules for success / rejection percentage, and based on rules for throughput metrics.

[0008] The routing decision can further be based on user-defined rules. The user-defined rules can be configured via a routing management interface. The user can provide preferences related to the order of selecting transport computers. Alternatively or additionally, the user can configure rules for manually overriding the routing logic.

[0009] The nature and advantages of embodiments of the disclosure can be better understood with reference to the following detailed description and the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1A is a schematic diagram illustrating an overview of a system and method for authorized routing according to some embodiments.

[0011] Figure 1B is a block diagram illustrating an overview of an authorized routing system according to some embodiments.

[0012] Figure 2 is a block diagram illustrating a gateway server according to some embodiments.

[0013] Figure 3 is a block diagram illustrating a resource provider computer according to some embodiments.

[0014] Figure 4 is a sequence diagram illustrating intelligent authorized routing of a message according to some embodiments.

[0015] Figure 5 is a flow diagram illustrating a method of determining transport computer availability based on a received response to a message according to some embodiments.

[0016] Figure 6 is a flow diagram illustrating a method of determining transport computer availability using a heartbeat message according to some embodiments.

[0017] Figure 7 is a flow diagram illustrating a method of determining expected data volume for a transport computer according to some embodiments.

[0018] Figure 8 is a flow diagram illustrating a method of evaluating a rejection-to-success ratio corresponding to a transport computer according to some embodiments.

[0019] Figures 9A-9C is an example interface for routing management according to some embodiments.

[0020] Figure 10 is a block diagram illustrating a computer system according to some embodiments.

[0021] Terminology

[0022] Before discussing various embodiments, a description of some terminology can aid in the understanding of the embodiments of the present disclosure.

[0023] The term“resource provider computer” can refer to a computer or computer system that participates in a transaction and other electronic communications for providing access to goods or services. A resource provider computer can be associated with a“resource provider,” which is an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, shipping agents, government entities, venue and residential operators, and the like.

[0024] The term“gateway server” can refer to a server computer that manages requests to a resource provider system. This gateway server can process routing authorization request messages and response messages on behalf of the resource provider system and can enable communication between the resource provider system and an associated transport computer.

[0025] The term“authorization computer” can refer to a computer that receives authorization requests. An authorization computer can access electronic records to determine an authorization response, thereby allowing a processing network to provide messages to other computers to coordinate authorization and settlement of transactions. An authorization computer can be associated with an issuer (e.g., a bank) that maintains an account for a user.

[0026] The term“transport computer” can refer to a computer that processes electronic payment communications on behalf of a resource provider system. A transport computer can receive authorization requests and settlement communications originating from a source address of a resource provider system, as well as authorization responses from a source address of an authorization computer, from which electronic payment messages can also originate. A transport computer can be associated with an“acquirer,” which can generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular resource provider or other entity. Some entities can perform the functions of both an issuer and an acquirer. Some embodiments can encompass such single entity issuer-acquirers.

[0027] A“processing network” can be a computer that functions to support and deliver credential issuing services, authorization services, exception file services, and clearing and settlement services. A processing network can be a“payment processing network.” An exemplary payment processing network can include VisaNet® by Visa Inc. TM . VisaNetTM The payment processing network can be capable of processing credit card transactions, debit card transactions, and / or other types of commercial transactions. The payment processing network can include one or more server computers. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0028] As used herein, payment or purchase “transaction data / information” can refer to any information corresponding to or describing a purchase, reservation, invoicing, payment involving a good, item, service, etc., can include, but is not limited to, a purchase amount, a merchant identifier, a description code (e.g., NAICS: North American Industry Classification System) associated with a purchased item, a cost and transaction of a purchased item, a purchased item, a purchase date, a purchase amount, an indication of a payment account used, an indication of whether the purchase was made online, a confirmation number, an order number, a cancellation number, shipping status updates (e.g., order being processed, being shipped, being delivered, backorder, etc.), a shipping tracking number, a cancellation notice, updates, etc.

[0029] The term “communication channel” can refer to a particular source and destination address (including intermediate addresses for routing) used for communication between two computers corresponding to the particular source and destination address. The communication channel can refer to a particular protocol (e.g., HTTP, TCP, UDP, etc.) and can have a particular set of associated encryption keys. The address can also specify a particular port, and thus two destination addresses can have the same IP address, but can have different ports.

[0030] The term “authorization request message” or “authorization request” can refer to an electronic message sent to a payment processing network and / or payment account for authorization to request authorization for a transaction. An authorization request message according to some embodiments can comply with ISO 8583, ISO 20022, and / or ISO 8538 / 20022, which are standards for systems that exchange electronic transaction information associated with payments made by a consumer using a payment device or payment account. An authorization request message can include a primary account number (PAN) or other identifying information associated with a consumer payment device or payment account. An authorization request message can also include additional data elements corresponding to the identifying information, including (by way of example only): a service code, a card verification value (CVV / iCVV), a dynamic card verification value (dCVV), a cryptogram (e.g., a unique cryptogram value for the transaction), an expiration date, etc. An authorization request message can also include transaction information, such as any information associated with a current transaction, such as a transaction amount, a resource provider identifier (e.g., an MVV, “resource provider verification value”), a resource provider location, a resource provider category code, etc., and any other information that can be used to determine whether to authorize a transaction.

[0031] An "authorization response message" or "authorization response" can refer to a message reply to an authorization request message. An authorization response message can include, by way of example only, one or more of the following status indicators: approved - the transaction is approved; declined - the transaction is not approved; or call center - more information is needed for the response to be resolved, the resource provider must call a toll-free authorization phone number. An authorization response message can also include an authorization code, which can be a code returned by a credit card issuing bank to a resource provider's access device (e.g., a POS device) in response to an authorization request message in an electronic message (directly or through a payment processing network) indicating that the transaction is approved. The code can serve as proof of authorization.

[0032] The term "heartbeat message" can refer to a message sent to indicate whether a sending device is available or to determine whether a receiving device is available. Heartbeat messages can be sent periodically and continue to be sent while the sending entity is available. The absence of a heartbeat message can indicate that the sending entity is no longer available.

[0033] The term "handshake synchronization message" can refer to a message sent by one device to establish a communication channel with another device. A handshake synchronization response message can be employed in response to a handshake synchronization message, indicating that the two entities are synchronized and able to communicate further.

[0034] A "processor" can refer to any suitable data computation device or devices. A processor can include one or more microprocessors, microprocessor-based systems, microcontroller-based systems, programmable logic devices, and / or the like. A processor can include a CPU, which comprises at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like.

[0035] A "memory" can be any suitable device or devices that can store electronic data. Suitable memory can include a non-transitory computer readable medium that stores instructions that are executable by a processor to implement a desired method. Examples of memory can include one or more memory chips, disk drives, and / or the like. Such memory can operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0036] A "server computer" can include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers working in concert. In one example, the server computer can be a database server coupled to a Web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer can comprise one or more computation devices and can use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. DETAILED DESCRIPTION

[0037] The present disclosure provides methods and systems for intelligent routing in a networked system, such as a hospital computer network, a distributed database, or a system for managing transactions and facilitating payment for goods and services using credit cards. In these networked systems, there are multiple servers, computers, and processors, each of which plays a respective role in the process. If a given computer is unavailable to perform its individual function in the network within an appropriate time frame, the performance of the entire network can be affected. The disclosed methods and systems provide a solution to this problem, enabling the network to perform its intended functions even when individual computers, servers, or processors are unavailable.

[0038] While the following examples and language focus on a transactional context, the methods and systems described below can be applicable to more general network systems. A fundamental aspect of some embodiments of the present disclosure is the ability to select, based on network measurements and user-configured rules, the appropriate node in a network to route a message to. This has advantages in many network scenarios, especially those in which both speed and reliability are important.

[0039] An example of such a system is a cloud computing system that includes redundant servers. This system can perform computational operations on behalf of a large number of client computers (e.g., thousands of client computers can utilize the cloud computing system).

[0040] When a client computer sends a request to the cloud computing system to process data, the cloud computing system can have hundreds of redundant servers that can process the data. By intelligently routing the request to the ideal server computer, the data can be processed in the most efficient manner.

[0041] Another example is a system for processing payments. Embodiments can include a system including a resource provider computer, a gateway server, a plurality of transport computers, a processing network, and an authorization computer. In some embodiments, the resource provider computer creates an authorization request that is sent over a network to the authorization computer. The resource provider computer receives an authorization response that is sent over the network from the authorization computer. The authorization request can be routed from the resource provider computer to the gateway server, then to a transport computer, then to the processing network, and then to the authorization computer at its destination. However, if the first option transport computer is unavailable or experiencing a delay, another transport computer can be selected. In doing so, the authorization request can reach the authorization computer in a timely manner even if the first option transport computer is unavailable or experiencing a delay. This provides a considerable advantage over conventional systems and methods of authorizing authorization requests.

[0042] Embodiments of the present disclosure provide advantages over conventional systems and methods because conventional systems and methods used in authorizing authorization requests are not able to intelligently route messages to the appropriate transport computer based on network measurements and user-defined rules. As a result, delays or complete failures often occur based on blindly routing messages to fixed computers. For example, in conventional systems for processing authorization requests, if a transport computer corresponding to a given resource provider is unavailable, the authorization request cannot be processed because the transport computer is unable to receive the authorization request and forward it to the payment network. If there is not a complete failure, the transport computer can experience a surge in data volume that can slow the speed of processing requests. In contrast, embodiments of the present disclosure can identify one of several transport computers to which to route an authorization request, allowing for fast authorization requests even if a given transport computer is unavailable or experiencing a delay. The result is a smoother and more efficient networking environment.

[0043] Various computers and other network entities are described below, along with the manner in which they interact and communicate with one another, as well as individual entity descriptions. Methods by which a gateway server can route authorization requests through different transport computers based on factors such as transport computer availability, expected data volume, and / or static rules are also provided. After an example of determining availability of transport computers on a network, ways of determining expected data volume of transport computers are discussed. Methods for calculating a rejection / success ratio are described. Finally, an example routing configuration interface is described.

[0044] I. Overview of Intelligent Routing Systems and Methods

[0045] Figure 1Ais a schematic diagram illustrating an overview of an intelligent routing system and method 100A in accordance with some embodiments. As shown, the system 100A includes a resource provider computer 101, a gateway server 103, a plurality of transport computers (e.g., transport computer A 111A, transport computer B 111B, and transport computer C 111C), and a routing management interface 107. Other network devices can exist between the various network computers shown, e.g., Internet routers, the functions of which are known to those skilled in the art. The system 100A can further include additional components to which messages can be routed by the transport computers, such as Figure 1B the details of the functionality of these components are described in detail in Section II below.

[0046] At an initial time, the routing management interface 107 can accept rule parameters from a user, e.g., an administrator associated with a resource provider. The routing management interface 107 can display interface elements for accepting user-configured rules directly or via another device, e.g., the resource provider computer. For example, the user can specify a primary transport computer and a set of conditions for using one or more backup transport computers. In Figure 9A an example of such an interface is shown in FIG. 1 1 and described in Section VII.

[0047] At step S1, the routing configuration service 103C can retrieve user-configured rules from the routing management interface 107. The routing configuration service 103C can convert the rules into an appropriate form and, at step S2, store the configuration rules to the routing database 105. The routing configuration service 103C can accept different sets of rules from various different resource providers. The rules can be stored in association with the resource provider for which the rules are configured. The routing database 105 can store a plurality of different sets of rules configured based on the preferences of different resource providers.

[0048] At step S3, the real-time network management engine 103B can monitor the plurality of transport computers. For simplicity of explanation, three transport computers are shown, i.e., transport computer A 111A, transport computer B 111B, and transport computer C 111C. However, the real-time network management engine 103B can monitor many (e.g., hundreds or thousands) of transport computers. Monitoring the transport computers can involve retrieving data, e.g., error codes and responses with timestamps, from the transport computers. The responses with timestamps can be used to determine response times. Such data can be collected by sending messages, e.g., request messages and handshake messages, to the transport computers. Alternatively or additionally, data can be collected from the transport computers by listening for heartbeat messages. Various methods of monitoring the transport computers are described in detail in Sections III-VI below. Figure 1A

[0049] ​At step S4, the routing manager 103A can receive the request from the resource provider computer 101. The request can be an authorization request.

[0050] At step S5, the routing manager 103A selects a transport computer to which the request is to be sent. Typically, the request would be routed to a predetermined transport computer (e.g., based on a business relationship between the resource provider and the entity that manages the transport computer). In contrast, using the intelligent routing method, the routing manager leverages user-configured rules in the routing database and real-time network measurements gathered by monitoring a set of transport computers to make routing decisions and select a transport computer. The routing manager can, for example, calculate a score for each potential transport computer and select the transport computer to which to route the request based on the scores. Selecting a transport computer is described in detail in Section III below. After selecting the transport computer, the routing manager 103 sends the request to the selected transport computer.

[0051] II. System Including Multiple Transport Computers

[0052] A system according to some embodiments includes a series of computers and servers. Included are a resource provider computer, a gateway server, a plurality of transport computers, a processing network, and an authorization computer. Authorization requests and responses are routed by the gateway server and the processing network between the resource provider computer, the transport computers, and the authorization computer. The gateway server selects an ideal transport computer to which to route authorization requests and / or responses based on network measurements determined by monitoring the transport computers, predicting expected data volumes for the transport computers, and / or predetermined routing rules, among other criteria.

[0053] The system can further include a routing management interface to accept user-defined parameters and display information to the user. The system can enable the display of interface elements such that a user, e.g., an administrator associated with the resource provider, can configure routing preferences. For example, the user can select a first, second, and third option transport computer to which to route authorization requests. The routing interface can further accept input to configure routing criteria (e.g., to weight pricing higher than timing in routing decisions, or vice versa). The routing management interface can further display information about the health status of one or more transport computers.

[0054] A. System Overview

[0055] Figure 1B is a block diagram illustrating an overview of an authorization routing system 100B according to some embodiments. Figure 1B Some elements of Figure 1AThe elements in FIG. 1 A are also present in system 100B. As shown, system 100B includes resource provider computer 102, gateway server 104, a plurality of transport computers (e.g., transport computer A 106A, transport computer B 106B, transport computer C 106C, and transport computer D 106D), processing network 110, authorization computer 112, routing interface 108, and user device 114. Other network devices can exist between the various network computers shown, e.g., Internet routers, the functions of which are known to those skilled in the art. In the example shown, gateway server 104 can select one of the four transport computers when sending an authorization message to the final destination of authorization computer 112.

[0056] User device 114 can be any suitable device operated by a user, such as a computer, a smart phone, a tablet computer, etc. Alternatively, user device can be an Internet of Things capable device configured to perform operations on behalf of a user. User device 114 can send information to resource provider computer 102 for initiating an interaction, such as a request for access to a resource. For example, a user can enter payment information and select an item for purchase via a smart phone, and then send the payment information to resource provider computer 102 for processing.

[0057] Resource provider computer 102 can be in electronic communication with user device 114, such as over the Internet or another network. Resource provider computer 102 can receive identifying information from user device 114. This information can take different forms depending on the context of the communication.

[0058] In some embodiments, such as in embodiments where user device 114 is authenticated, resource provider computer 102 can receive identifying information from user device 114, such as an IP or MAC address. In cases where security is more important, resource provider computer 102 can receive a hash, which can be verified by resource provider computer 102 or by authorization computer 112. In other cases, resource provider computer 102 can receive an encrypted message. Resource provider computer 102 or authorization computer 112 can decrypt the message and compare the decrypted message to an expected message. If the decrypted message matches the expected message, user device 114 can be identified. Identifying information can also take the form of payment credentials from a consumer, such as a personal account number or PAN, as well as other credentials or identifying information, such as a home address, a zip code, a credit card CVV2 value, a credit card expiration date, and a full legal name.

[0059] The resource provider computer 102 can additionally generate authorization requests. An authorization request can relate to an interaction between the resource provider computer 102 and the user device 114. For example, the resource provider computer 102 can generate an authorization request in order to request authorization for an interaction between the resource provider computer 102 and the user device 114 from a third party. The third party can be the authorization computer 112. The authorization request message can be encrypted or unencrypted, sent over a direct or distributed network (e.g., the Internet), and in any form suitable for electronic communication. Further details are provided below with respect to Figure 3 Various components of the resource provider computer 102 for performing such functions are described.

[0060] As another example, the user device 114 can request a protected or sensitive record, such as a patient medical history record, from the resource provider computer 102. The user device 114 can provide identifying information to the resource provider computer, such as a user ID and password. The resource provider computer 102 can generate an authorization request message in order to verify the identity of the user device 114 in order to determine whether the user device 114 is authorized to receive the medical history record.

[0061] As another example, the user device 114 can belong to a consumer who wishes to acquire goods or services from the resource provider computer 102. The user device 114 can provide identifying information, such as a PAN. The resource provider computer 102 can generate an authorization request message including the PAN and send it in order to receive authorization to complete the transaction.

[0062] The gateway server 104 can receive authorization requests or other requests from resource provider computers and service these requests. Examples of other requests include settlement requests and capture requests. The gateway server 104 can take the form of a payment gateway that provides access to the communication infrastructure shown in the system 100B for many resource provider computers, for example, by parsing and analyzing the contents of payment request messages. The gateway server 104 can provide additional functionality, such as generating records of serviced requests.

[0063] As part of providing access to the authorization infrastructure, the gateway server 104 can establish communication with a transport computer over a communication channel. The gateway server 104 can be configured to communicate with a variety of transport computers. To identify the appropriate transport computer for a given authorization request, the gateway server 104 can use a combination of static rules and real-time network measurements. For example, the gateway server 104 can include a database that stores rules for each of a plurality of resource providers. Each resource provider can have a relationship with a different respective acquirer group that corresponds to a different transport computer. The rules can include rules configured by the resource provider (e.g., a preferred order of three potential transport computers), as well as general routing rules (e.g., select the closest node and / or the lowest cost option). The gateway server 104 can further analyze transport computer behavior and patterns to determine expected data volumes as well as transport computer health and availability, which can also be used in routing decisions. See, e.g., FIG. 2, below. Figure 2 Various components of the gateway server 104 for performing such functions are described.

[0064] This“smart routing” presents a number of advantages. The gateway server can select one of several transport computers to send a message, such as an authorization request message, to. Thus, requests can be processed in near real-time, even if one or more transport computers are experiencing a failure or delay. Additionally, a large set of data available to the gateway server can be used to select a transport computer. The gateway server can forward requests between a large number of different resource providers and transport computers. Additionally, the gateway server can be configured to process requests sent between such devices and utilize data therein. Thus, the gateway server has a large amount of data available to make informed decisions about when a transport computer can be experiencing a delay. This, in combination with the gateway server’s position as a node through which messages are passed early in a transaction, makes routing through the gateway server to different transport computers very advantageous.

[0065] Transport computers (e.g., transport computer A 106A, transport computer B 106B, transport computer C 106C, and transport computer D 106D) can manage one or more resource provider accounts of the resource provider computer 102. The transport computers can route requests, such as authorization request messages, authorization response messages, settlement requests, or capture requests. As part of settlement, the transport computers can debit or credit resource provider accounts associated with the resource provider computer 102.

[0066] The transmitting computers (e.g., transmitting computer A 106A, transmitting computer B 106B, transmitting computer C 106C, and transmitting computer D 106D) can also communicate with the processing network 110. This communication can be conducted electronically via the Internet or another suitable network. These communications primarily take the form of authorization requests, authorization responses, settlement requests, or other settlement messages, but may take other forms depending on the needs of the transmitting computer or the authorizing computer 112. For example, there may be inconsistencies between the states of settlement requests between the transmitting computer and the authorizing computer 112. In this case, the transmitting computer can communicate with the processing network 110 to facilitate communication with the authorizing computer 112. Generally, the transmitting computer can communicate with the processing network 110 to route communications to its designated recipient, such as a specific authorizing computer 112.

[0067] Processing network 110 can facilitate message delivery and information tracking between one or more transmission computers (e.g., transmission computer A 106A, transmission computer B 106B, transmission computer C 106C, and / or transmission computer D 106D) and one or more authorization computers (e.g., authorization computer 112). For example, processing network 110 can receive an authorization request message from a transmission computer and analyze the authorization request message to determine that authorization computer 112 is associated with the authorization request message. Such identification of the corresponding authorization computer can be performed by analyzing a portion of an account corresponding to a Bank Identification Number (BIN), which can be used to access a database that makes the corresponding authorization computer stored as associated with the BIN. Processing network 110 can forward authorization messages received from transmission computers to authorization computer 112 for authorization. Processing network 110 can then receive authorization response messages from authorization computer 112 and further send the authorization response messages to the transmission computers.

[0068] The routing management interface 108 may include software and / or hardware configured to accept user input to configure routing rules. The routing management interface 108 may further include functionality for displaying information to users (e.g., administrators associated with resource providers).

[0069] The routing management interface 108 can be displayed directly or via the resource provider's computer 102, providing interface elements for configuring routing rules. Figure 9A This interface is shown and described in Section VII. As an example, the routing management interface 108 can send instructions to the resource provider computer 102, thereby causing the resource provider computer to generate and display interface elements such as links, patterns, images, and text. Users can interact with these interface elements. Users can initiate rule generation, for example, by clicking a button or a URL. Rules can be generated and sent to the gateway server 104.

[0070] The resource provider computer 102 and / or the user device 114 (e.g., of an administrator) can further include functionality to present the routing management interface 108. The resource provider computer 102 can include a display, such as a screen, to display interface elements. The resource provider computer 102 can include elements to accept user input, such as a keyboard, mouse, voice detection hardware / software, etc. Based on configuration options displayed on the display elements via the routing management interface 108, the resource provider computer 102 can accept configuration data via one or more user input elements.

[0071] The authorization computer 112 can receive and analyze the authorization request message, such as to identify a stored record corresponding to the account information provided in the request. An authorization response message can then be created. Such an authorization response message can include an indication of whether the authorization request message was authorized, as well as information about the authorization status of the request or other information. Such information can include a status indicator (e.g., approved, declined, or call center). The information can also include a timestamp. The timestamp can indicate a time of sending the authorization request and / or a time of sending the authorization response. This information can also include an authorization code, which can serve as proof of authorization. The authorization code can be used as part of a later capture request. The authorization code and other information about the authorization status can be useful for archival purposes, as the timing of a capture request is often later than the authorization request.

[0072] The network computers in FIG. 1 can communicate over a distributed network, such as the Internet, or over a series of direct connections, a mixture of both, or any other suitable communication method between entities. Additionally, in some embodiments, there can be multiple resource provider computers, gateway servers, transport computers, processing networks 110, authorization computers 112, routing management interfaces 108, and / or user devices 114.

[0073] B. Gateway Server

[0074] Figure 2 FIG. 2 is a block diagram illustrating a gateway server 200, according to some embodiments. The gateway server 200 can include hardware and / or software configured to route messages between resource provider computers and one or more transport computers. The gateway server 200 can include a processor 204, a memory 206, and a computer-readable medium 208 operatively coupled to a network interface 202. The gateway server 200 can further include a routing database 216.

[0075] The processor 204 can be implemented as one or more integrated circuits (e.g., one or more single-core or multicore microprocessors and / or microcontrollers). The processor 204 can be used to control the operation of the gateway server 200. The processor 204 can execute a variety of programs in response to program code or computer-readable code stored in the memory 206. The processor 204 can include functionality to maintain multiple concurrently executing programs or processes.

[0076] The network interface 202 can be configured to connect to one or more communication networks to allow the gateway server 200 to communicate with other entities such as resource provider computers, transport computers, routing management interfaces, and the like. For example, communications with transport computers can be direct, indirect, and / or through an API.

[0077] The memory 206 can be implemented using any combination of any number of nonvolatile memory (e.g., flash memory) and volatile memory (e.g., DRAM, SRAM), or any other non-transitory storage medium or combination of media.

[0078] The computer-readable medium 208 can include one or more non-transitory media used to store and / or transmit. For example, suitable media include random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, optical media such as a compact disk (CD) or DVD, flash memory, and the like. The computer-readable medium 208 can be any combination of such storage or transmission devices.

[0079] The computer-readable medium 208 can include software code stored as a series of instructions or commands. The computer-readable medium 208 includes code that is executable by the processor 204 to implement the methods described herein. The computer-readable medium 208 can include a routing manager 210, a real-time network measurement engine 212, and a routing configuration service 214. Each of these modules can include code configured to perform the functions described below in conjunction with the processor 204.

[0080] The real-time network measurement engine 212 can include code configured to detect availability metrics of one or more transport computers. This can involve logging, counting, and / or analyzing handshake messages, authorization response messages, acknowledgement messages, and / or heartbeat messages in order to determine availability of a transport computer. The real-time network measurement engine 212 can communicate with the routing manager 210 to provide collected information to the routing manager 210. The routing manager 210 can then use the provided information to route messages to ideal destinations. More detail is provided below regarding Figures 4-6 Methods of detecting availability metrics of transport computers are discussed in further detail.

[0081] The route configuration service 214 can include code configured to receive and process user-defined route configuration parameters. The route configuration service can communicate with the route management interface. The route configuration service 214 can send information to the route management interface so that appropriate configuration options can be displayed to a given resource provider. The route configuration service 214 can retrieve user-defined rules from the route management interface (e.g., the route management interface 108, described above with respect to Figure 1B the route configuration service 214 can store user-defined route rules to the route database 216.

[0082] The route manager 210 can include code configured to route authorization requests and / or other messages. The route manager can obtain real-time network measurements regarding one or more transport computers from the real-time network measurement engine 212. The route manager can obtain user-defined routing preferences from the route configuration service 214 and / or the route database 216. The route manager can further obtain static rules from the route database. The route manager 210 can use any combination of these factors, as well as additional factors described below, to make routing decisions.

[0083] The route manager 210 can further include code configured to perform analysis for routing decisions. The route manager 210 can predict expected data volume. The expected data volume can be predicted based on current data volume. Alternatively or additionally, the expected data volume can be predicted based on historical data volume analysis. The route manager 210 can compare historical parameters retrieved and stored in the process of processing previous authorization requests to corresponding parameters corresponding to a current authorization request. As an example, historical data can show that a particular set of transport computers located in the western United States historically experience a surge in data volume around 9:00 a.m. on "Black Friday," a particular frenzied shopping day in that region. Thus, the route manager 210 can predict high data volume for these transport computers at that time. The route manager 210 can determine various other metrics used in routing decisions, such as response time, success / rejection ratio, response ratio, and static rules, as described in detail below with respect to Figures 4-8 the route manager 210.

[0084] The route manager 210 can further include code configured to process authorization requests and responses. This can involve interpreting the contents of a message to determine the ultimate recipient of the message and authorization status. It can also involve storing some or all of the information in a database, such as the route database 216, for future access. The route manager 210 can additionally decrypt or encrypt authorization requests and responses. As an example, the route manager 210 can decrypt an authorization response message in order to access and interpret the contents of the message. The route manager 210 can re-encrypt the message for secure transmission before the authorization response message is sent to the appropriate resource provider computer.

[0085] The routing manager 210 can further prepare the message for routing to the selected destination. This can involve evaluating the network address and determining the appropriate communication protocol or standard. Additionally, the routing manager 210 can format the authorization request or response so that it complies with the appropriate communication protocol. As an example, the routing manager 210 can determine that routing the authorization request to the transport computer requires the use of the transmission control protocol and that the message should comply with ISO 8583. The routing manager 210 can format the message so that it complies with both the protocol and the standard, then route the message to the transport computer for further processing. If it is determined that the request is fraudulent, the routing manager 210 can send an authorization response message to the merchant computer system indicating that the request has been declined.

[0086] The routing database 216 can be a storage unit and / or device (e.g., a file system, database, collection of tables, or other storage mechanism) for storing data. The routing database 216 can store routing rules. Such rules can be stored in association with a plurality of different resource providers. Each resource provider can define their own routing preferences (e.g., via a routing management interface). Alternatively or additionally, the routing database 216 can store general rules (e.g., route to the transport computer that is expected to process the request the fastest, and / or route to the transport computer that is the least expensive).

[0087] In some embodiments, the gateway server 200 can further include hardware and / or software configured to analyze transaction data to identify whether specified criteria are met or otherwise fraud assess a request for access to a resource. If the gateway server 200 determines that a transaction is likely fraudulent, the gateway server 200 can determine that the transaction should be declined and should not be forwarded to other network entities for an authorization response message. If the gateway server 200 determines that a transaction is not fraudulent, the gateway server 200 can determine that the transaction should be allowed. If the gateway server 200 is unable to determine whether a transaction is fraudulent, the gateway server 200 can send the transaction to a transport computer or processing network for further review.

[0088] C. Resource Provider Computer

[0089] As Figure 3 depicted in FIG. 3, the resource provider computer 300 can include hardware and / or software configured to generate and send an authorization request to initiate a request for access to a resource. The resource provider computer 300 can include a processor 304, a memory 306, and a computer-readable medium 310 operatively coupled to a network interface 302.

[0090] The processor 304, network interface 302, and memory 306 can be substantially similar to the processor 204, network interface 202, and memory 206 described above with respect to Figure 2

[0091] The computer-readable medium 310 can include one or more non-transitory media used to store and / or transmit. For example, suitable media include random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, optical media such as a Compact Disk (CD) or DVD, flash memory, and the like. The computer-readable medium 310 can be any combination of such storage or transmission devices.

[0092] The computer-readable medium 310 can include software code stored as a series of instructions or commands that can be executed by the processor 304 to implement methods as described herein. The computer-readable medium 310 includes code that can be executed by the processor 304 to implement methods as described herein. The computer-readable medium 310 can include a request processing module 312 and a messaging module 314.

[0093] The messaging module 314 can include code for preparing and sending messages. The messaging module 314 can be further configured to accept and analyze messages. The messaging module 314 can include functionality to send authorization request messages and receive authorization response messages. The messaging module 314 can be configured to prepare and send notifications (e.g., upon determining that a request has been declined).

[0094] The request processing module 312 can include software configured to process requests, such as authorization requests. The request processing module 312 can receive transaction information from a user device of a user requesting access to a resource. For example, the request processing module 312 can receive transaction information, such as payment information, items to be purchased, the name and address of the user, and the like, from a user device. The request processing module 312 can use the received information to generate an authorization request message. The request processing module 312 can process authorization response messages, dictating an authorization result of whether a request is approved or declined. Based on the authorization result, the request processing module 312 can continue processing the request, or notify the messaging module 314 that the request has been declined.

[0095] III. Intelligent routing method

[0096] Generally, the "intelligent routing" method involves a gateway server that facilitates sending authorization request messages to one of a plurality of transport computers. An appropriate transport computer can be selected based on error codes, real-time network measurements, and / or expected data volume, among other factors. This intelligent routing method can involve receiving an authorization request message, then determining availability of transport computers and expected data volume, and routing the authorization request message to an appropriate transport computer. ​

[0097] Figure 4 is a sequence diagram illustrating a method 400 of detailed authorization routing according to some embodiments of the application. Resource provider computer 401, gateway server 403, transport computer A 405A, and transport computer B 405B correspond to resource provider computer 102, gateway server 104, transport computer A 106A, and transport computer B 106B, respectively, described above with respect to FIG. 1. Although two transport computers are shown for simplicity of illustration, a larger group of transport computers can be involved.

[0098] At step S402, resource provider computer 401 prepares an authorization request associated with a request for access to a resource and sends the authorization request to gateway server 403. The authorization request can conform to ISO 8583 or another standard for electronic communications and can include identification information such as a resource provider identifier. The authorization request can include various types of identification information that can be used for authorization, such as any of a user name, a password, a PAN, or other instances of identification information recited above, as well as other forms of identification information. Gateway server 403 receives the authorization request.

[0099] At step S404, gateway server 403 determines a group of transport computers. Gateway server 403 can determine the group of transport computers based on the resource provider. Gateway server can use the resource provider identifier obtained from the authorization request to identify a group of transport computers available to the resource provider. For example, a first resource provider can have a relationship with two acquirers, with two or more corresponding transport computers that can handle authorization requests. A second resource provider can have a relationship with one acquirer and one third-party acquirer processor, with two or more corresponding transport computers that can handle authorization requests. Thus, different groups of transport computers can be used based on the relationships established by the resource provider. The appropriate group of transport computers can be identified by retrieving a stored mapping based on the resource provider identifier.

[0100] At step S406, gateway server 403 retrieves status information from the determined group of transport computers (e.g., transport computer A 405A and transport computer B 405B). Gateway server 403 can send a message (e.g., an authorization request message or a handshake message) to each transport computer. In response, gateway server 403 can receive a response message with a corresponding timestamp, indicating a response time. Alternatively or additionally, the response message can include one or more error codes. Alternatively or additionally, gateway server 403 can remain in a listening state to wait for messages, such as continuously sent heartbeat messages from the transport computers.

[0101] At step 408, the gateway server 403 determines a respective measure of network availability of the transport computer 405A, 405B. The gateway server 403 can determine the measure of network availability using one or more of error codes, response times, a ratio of connection successes to failures, or a ratio of recorded missed heartbeats to expected heartbeats.

[0102] In some embodiments, this determination can involve an analysis of a rate of receipt of the first authorization requests. As an example, the gateway server 403 can compare a number of authorization requests sent to each transport computer to a number of authorization requests confirmed as received by the transport computer (e.g., through an acknowledgement message). The gateway server 403 can further determine a response time associated with the transport computer.

[0103] The analysis of receipt of the received authorization requests can be accomplished in a variety of ways. For example, the transport computer can send an electronic receipt message to the gateway server 403 for each of the first authorization request messages. This electronic receipt message can indicate that the transport computer has received a given first authorization request. In other cases, it can be appropriate to use a different message to indicate the number of received authorization requests.

[0104] For example, according to TCP, a series of handshake messages are sent back and forth by the computers in order to establish a communication channel. It is assumed that once a communication channel has been established, the messages will be received by the recipient, in this case by the transport computer. If a handshake message is not received, then the communication channel cannot be established and a given first authorization request cannot be received by the transport computer. Thus, the availability of the transport computer can be determined by comparing the number of handshake messages sent to the handshake responses received.

[0105] Other methods can be used to determine a measure of the availability of a transport computer. In some embodiments, heartbeat messages are used to determine the availability of a transport computer. Heartbeat messages can be short messages and can be sent to one or more computers in the network at a predetermined rate. A heartbeat message indicates to its recipient that the computer sending the heartbeat message is available for communication. In some embodiments, the gateway server 403 can periodically receive heartbeat messages from transport computers. The gateway server 403 can compare the number of heartbeat messages received to an expected number of heartbeat messages in order to determine the availability of a transport computer. Additionally, the gateway server 403 can determine a ratio of the number of heartbeat messages received to the expected number of heartbeat messages and compare the ratio to a predetermined threshold. As an example, heartbeat messages are sent on average once per second. The gateway server 403 can calculate the expected number of heartbeat messages received over any time period. Over a 30 minute period, the gateway server expects to receive 1800 heartbeat messages. If the gateway server instead receives 1000 heartbeat messages, the ratio of heartbeat messages received to expected heartbeat messages is 0.556. This ratio can be compared to the ratios of other transport computers when determining a transport computer to which to send an authorization request. Methods for determining measures of network availability of transport computers 405A, 405B are discussed in further detail below in Section IV.

[0106] At step 410, the gateway server 403 identifies an expected authorization request data volume for the transport computers 405A, 405B. The gateway server 403 can determine the expected authorization request data volume by analyzing recent data volumes and / or comparing current transport computer parameters to historical transport computer parameters. Methods for determining expected data volumes for the transport computers 405A, 405B are discussed in detail below in Section V.

[0107] At step 412, the gateway server 403 selects a particular transport computer (e.g., transport computer A 405A or transport computer 405B) to process the request. The gateway server 403 can select a particular transport computer to process the request based on the determined measures of network availability and / or the expected data volumes of the transport computers. The gateway server can use additional factors when making the routing determination, such as predefined rules, success / rejection rates, and throughput measures. Such factors can be combined to arrive at a score or "health score" for a transport computer. The gateway server 403 can select a transport computer to process the request based on the score (e.g., by selecting the transport computer with the highest or lowest score according to the scoring system used).

[0108] The gateway server 403 can use predefined rules for transport computer selection when making the routing determination. The gateway server 403 can retrieve such predefined rules from a routing database. As discussed above with respect toFigure 1A As described, some or all of the rules can be stored in association with different resource providers. Based on, for example, a resource provider identifier, the gateway server 403 can retrieve a set of rules. Such rules can be accepted via user input. For example, a particular resource provider can generally prefer to use a particular transport computer based on a favorable relationship. The rules for this resource provider can then specify that the particular transport computer should be utilized unless the transport computer is in a failure state. In the event that the particular transport computer is in a failure state, the resource provider can specify one or more backup transport computers to which messages can be routed.

[0109] Other examples of predefined rules include sending a certain percentage of requests to each of a set of transport computers (e.g., sending 70% of requests to transport computer A, 20% of requests to transport computer B, and 10% of requests to transport computer C), and routing based on request details (e.g., transaction channel (e.g., card present, not card present, chip, stripe, PIN, etc.), currency, country, amount, etc.). In some embodiments, user-configured rules can be used to override the routing logic. For example, a rule can specify that a preferred transport computer should be used even if the transport computer is experiencing delays. Section VII below describes in detail the selection of rules by a user via this interface. Alternatively or additionally, the gateway server 403 can use predefined default rules across resource providers (e.g., select the closest node, select the fastest computer, etc.).

[0110] The gateway server 403 can further use success / rejection rates in the routing determination. If messages processed by a transport computer are being rejected at a relatively high rate (e.g., compared to other transport computers and / or previous time points), this can indicate that the transport computer is passing inaccurate data and is not an ideal message destination.

[0111] The gateway server 403 can further use throughput capacity in making routing determinations. Throughput capacity can indicate the number of requests that a particular transport computer is able to process in a particular time period. The throughput capacity of each transport computer can be determined at an initial time. For example, the gateway server 403 can retrieve information from the transport computer A 405A and the transport computer B 405B indicating one or more of the type of transport computer, the processing speed of the transport computer, and / or the throughput capacity of the transport computer. If the throughput capacity of the transport computer is not provided directly, the gateway server can calculate the throughput capacity.

[0112] The gateway server 403 can combine various metrics as described above in computing a score for each of the plurality of transport computers. The score can be computed, for example, via a decision algorithm that combines various static rules and real-time network measurements to reach a routing decision. For example, for a particular resource provider, the decision algorithm can provide for selecting the transport computer with the highest score (e.g., the ideal node for routing) using the following formula: where V is the expected data volume for the transport computer, A is a measure of the availability of the transport computer, C is the cost associated with the transport computer (e.g., the dollar amount or percentage that the transport computer charges the resource provider for each request), P is the proximity score for the transport computer (e.g., the proximity score for the closest node can be 1 and the proximity score for the farthest node can be 0, with intermediate distances having intermediate values), and R is the success / rejection ratio for the transport computer. B1, B2, B3, B4, and B5 are coefficients that can be adjusted as desired to weight the factors in the decision logic.

[0113] The gateway server 403 can further use hysteresis to avoid unnecessary switching between transport computers. The gateway server can establish one or more hysteresis thresholds. For example, a first hysteresis threshold can be used for switching from transport computer A to transport computer B, and a second hysteresis threshold can be used for switching from transport computer B to transport computer C. The hysteresis thresholds can be used to diminish the impact of one or more factors used in making routing decisions. For example, the selection algorithm can include a condition that only changes from a primary transport computer if the secondary transport computer is given a score that exceeds the score of the primary transport computer by an amount that exceeds the hysteresis threshold. Using hysteresis thresholds is advantageous because it can prevent unnecessary back-and-forth switching between transport computers. Such perturbations can be particularly problematic when the routing algorithm is sensitive to small changes in, for example, data volume and / or response time.

[0114] At step 414, the gateway server 403 sends the authorization request to the selected particular transport computer. This communication can be made through a direct connection or via a network such as the Internet, and can comply with any appropriate standards and use any appropriate transport protocol or scheme.

[0115] In some embodiments, the gateway server 403 can determine to send the authorization request directly to the processing network for processing (e.g., if one or more transport computers are unavailable or experiencing delays). When a transport computer becomes available, a further settlement message can be sent to the transport computer. Backup routing to the processing network is described in detail in U.S. Patent Application No. 15 / 653,350, which is incorporated herein by reference in its entirety.

[0116] IV. Determining Network Availability

[0117] Detecting availability generally involves statistical analysis of messages sent between the gateway server and the transport computer.

[0118] One such method of detecting availability described below involves analyzing error codes received by the gateway server from the transport computer. In determining network availability of a set of potential transport computers, the gateway server can analyze error codes generated by the transport computer based on a variety of different schemes.

[0119] Another such method of detecting availability described below involves analyzing messages received by the gateway server from the transport computer. Some messages, such as handshake messages, can be used to establish a communication channel between two entities. If the gateway server sends a message to the transport computer and the transport computer does not respond with its own response message, then communication generally does not proceed. Additionally, if the transport computer does not respond within a threshold period of time, the gateway server can preferentially route messages to another transport computer. Thus, the gateway server can evaluate some combination of responses received within a period of time and response times recorded over the period of time to determine the quality of communication between the gateway server and the transport computer. If only a small fraction of messages are responded to in a timely manner, and / or the response times are longer than average, this can indicate that the transport computer is not the desired destination for authorization requests.

[0120] Another such method of detecting availability can involve statistical analysis of heartbeat messages. Heartbeat messages can involve repeated message sending that indicates that an entity is available to communicate over a channel. A steady stream of heartbeat messages indicates a "healthy" connection, and an unstable heartbeat signal can indicate a network problem (e.g., the transport computer can be experiencing delays or failures). By analyzing the number of heartbeat messages received over a certain predetermined period of time to an expected number of heartbeats received, the availability of the transport computer can be determined.

[0121] A. Error Codes

[0122] According to some embodiments, the server computer can use error codes to determine a measure of availability of the transport computer. The gateway server can initially send a request to the transport computer. The request can be an authorization request. Alternatively or additionally, the request can be a handshake message, as described below with respect to Figure 6 Thus, various types of messages sent to the transport computer in an error state can prompt receipt of an error code.

[0123] The gateway server can determine whether the transport computer transmitted back an error code. For example, the gateway server can store one or more tables that define error codes for use by different transport computers. As an example, a first transport computer can transmit back error code 04 indicating that the transport computer is unavailable, or error code 07 indicating a failure for an unspecified reason. Another transport computer can use another error code scheme (e.g., 5677 indicating that the transport computer is unavailable). The transport computer can use such a table to look up a received code to determine whether an error code has been transmitted back. If the transport computer transmitted back an error code, the gateway server can determine not to route authorization requests to this transport computer for a particular period of time (e.g., for 1 minute or 4 hours). Alternatively or additionally, the gateway server can use the type of error code received as a factor in computing a health score for the transport computer.

[0124] B. Response Analysis

[0125] Figure 5 A method 500 for determining a measure of availability of a transport computer using analysis of a response received from the transport computer is shown in accordance with some embodiments.

[0126] At step 502, the gateway server sends a message to the transport computer. For example, the message can be an authorization request message or a handshake message. The handshake message can include any information needed for the handshake process. Handshake processes are used in many different transport protocols, such as "Transmission Control Protocol" or TCP, and are used to establish a stable communication channel before more substantive communication takes place.

[0127] This handshake process can involve first sending a first handshake message by the gateway server to the transport computer. The first handshake message can indicate to the transport computer that the gateway server wishes to establish a communication channel. The first handshake message can include information such as a network address that can reach the gateway server. The first handshake message can also include an indicator or code that informs the transport computer of the communication or handshake protocol. The handshake message sent at step 502 can be similar to the first handshake message described above. Additionally, the handshake message sent at step 502 can be a later message sent as part of the handshake process. The handshake message can be represented as an octet stream, a group of eight bits. The handshake message can also be represented in different data structures. The size and amount of data of the handshake message can depend on the nature of the handshake process or the network.

[0128] At step 504, the gateway server waits for a predetermined period of time for the transport computer to respond to the message. The predetermined period of time can be based on the amount of data that the gateway server or other factors or empirical observations process requests. For example, if experiments determine that a specified percentage (e.g., 99.99%) of responses occur within 30 milliseconds of sending a message, the predetermined period of time can be 30 milliseconds.

[0129] At step 506, the gateway server determines whether the transport computer responded to the authorization request or the handshake message within a predetermined time period. This determination can involve determining a response time. For example, the response time can be measured based on the time that elapses between sending the message to the transport computer and receiving a response from the transport computer. The gateway server can determine this elapsed time and compare the elapsed time to a predetermined threshold.

[0130] Alternatively or additionally, this determination can involve evaluating whether the gateway server received a valid response to the handshake message within a predetermined time period. For some communication protocols, the gateway server can expect a handshake message response that is specifically formatted. As an example, the gateway server can expect a first eight octets corresponding to a network address, a second 2 octets corresponding to a timestamp, and a last eight octets corresponding to an "operation code" that indicates the next step in the handshake process. If the transport computer is unable to send a valid response, the gateway server can determine that the transport computer did not respond to the handshake message.

[0131] When the message is an authorization request message, the response from the transport computer can be an acknowledgement response or an authorization response. An acknowledgement response can be used in some network communication protocols in order to verify that a message has been received. After receiving a substantive communication from the transport computer, the transport computer can be expected to provide an authorization response, either as an octet stream or another data structure.

[0132] If the transport computer has responded to the message within the predetermined time period, the flow proceeds to step 508. If the transport computer has not responded to the message within the predetermined time period, the flow proceeds to step 510.

[0133] At step 508, when the gateway server determines that the transport computer has responded to the message, the gateway server records the response time. The gateway server can calculate the response time, for example, by subtracting the time that the message was sent from the time that the response was received. The gateway server can store the response time in an array along with other relevant data, such as an identifier of the transport computer, an identifier of the resource provider, a timestamp associated with the request, and the like.

[0134] At 510, when the gateway server determines that the transport computer has not responded to the message, the gateway server records a connection failure. The recorded connection failure can indicate that the transport computer did not respond to the message within a threshold time. Such a recorded connection failure can include information such as a timestamp that indicates when the connection failure occurred. For example, the gateway server can record the connection failure by incrementing a counter or by updating a stored failure data array to indicate a timestamp corresponding to the time of the failure.

[0135] At step 512, the gateway server determines whether it has made a predetermined number of attempts to reach the transport computer. For example, the gateway server can increment an attempt counter each time an attempt is made. The attempt counter can serve as a record of the number of attempts made by the gateway server. The attempt counter can be a software counter, or it can be implemented as a dedicated piece of hardware. In either case, the attempt counter can be incremented or read by the gateway server. After incrementing the counter, the gateway server can compare the counter value to some predetermined number of attempts. The predetermined number of attempts can be set to a value such as two, three, or ten, for example, depending on the circumstances.

[0136] The advantage of repeated attempts to reach the transport computer is apparent from a statistical perspective. If 90% of communications receive a response to a message, then one in ten communications will fail. However, if the probability of a response is independent, then the probability that four communications fail to receive a response to a message is only one in 10,000, which is a much lower failure rate.

[0137] At step 512, when the gateway server has not made a predetermined number of attempts to reach the transport computer, the flow returns to step 502, and the gateway server makes another attempt to reach the transport computer, repeating this operation until the gateway server has made the predetermined number of attempts.

[0138] At step 516, when the gateway server has made the predetermined number of attempts to reach the transport computer, the gateway server can determine the availability of the transport computer. Determining the availability of the transport computer can involve calculating an availability score based on the recorded response times and connection failures. As an example, the gateway server can calculate an availability score that is inversely proportional to the average response time and the number of connection failures recorded after the predetermined number of attempts. The response times and connection failures can be evaluated based on the predetermined number of attempts and / or over a period of time. The availability can be further determined based on additional factors, such as error codes, success / rejection ratios, heartbeat messages, and the like.

[0139] C. Heartbeat Messages

[0140] Figure 6 A method 600 of using heartbeat messages to determine the availability of a transport computer is shown.

[0141] At step 602, the gateway server waits for a heartbeat message from the transport computer. The heartbeat message can be a message sent during the absence of other communications, and indicates that the transport computer is "up and running" in the sense that it accepts communications. The heartbeat message can be sent during regular intervals or on an irregular but known schedule. The heartbeat message can be sent, for example, once per second in the absence of other communications.

[0142] At step 604, the gateway server assesses whether it received a heartbeat message from the transport computer. If the gateway server received a heartbeat message, no abnormal condition occurred and the availability of the transport computer is expected to remain unchanged. In this case, the flow proceeds to step 608. If the gateway server did not receive a heartbeat message, the flow proceeds to step 606.

[0143] At step 606, the gateway server records the missed heartbeat. There are multiple ways in which the gateway server can record the missed heartbeat. For example, the gateway server can use software or hardware to maintain a count of missed heartbeats or a count of both missed heartbeats and received heartbeats. For example, the gateway server can maintain a variable stored in memory that is incremented upon a missed heartbeat. As a second example, the gateway server can maintain a two-row by N-column array, where each column corresponds to a missed or received heartbeat and a timestamp.

[0144] At step 608, the gateway server records the received heartbeat. Recording a received heartbeat can be performed in a similar manner to recording a missed heartbeat as described above with respect to step 606.

[0145] At step 610, the gateway server determines whether a predetermined time has elapsed. The predetermined time can be some stored interval of time for analyzing a collection of heartbeat messages. For example, the predetermined time period can be up to five minutes. In some cases, it can be advantageous to have a shorter time period in cases where, for example, the heartbeat rate is high or a longer time period in cases where the heartbeat rate is low. Thus, the gateway server can obtain a stored number of recorded missed and received heartbeats over the predetermined time period. After determining that the predetermined time has elapsed, the gateway server can proceed to step 612. If the gateway server determines that the predetermined time has not elapsed, the gateway server can return to step 602 and continue collecting additional heartbeat data.

[0146] At step 612, the gateway server calculates a ratio of recorded missed heartbeats to expected heartbeats over the predetermined time period. Calculating the ratio can involve traversing a data structure holding heartbeat records and calculating a number of missed heartbeats to a total number of heartbeats. Calculating the ratio can also involve determining an elapsed time value (e.g., recorded by a software or hardware timer) and calculating an expected number of heartbeat messages as a product of the length of time elapsed and a known heartbeat message rate (e.g., a prescribed heartbeat message rate). The ratio can then be calculated by dividing the recorded number of missed heartbeats by the total number of heartbeats.

[0147] Alternatively or additionally, the ratio of missed heartbeats can be calculated using different groupings of heartbeats (e.g., without using a time interval). For example, the ratio can be calculated for the last 10,000 heartbeats rather than for a number of heartbeats in a predetermined time range.

[0148] At step 614, the gateway server determines the availability of the transport computer. The gateway server can determine the availability of the transport computer based on the rate of missed heartbeats. The rate of missed heartbeats can be compared to a predetermined level of missed heartbeats that are considered normal (e.g., less than 0.2 is considered an indicator or poor health). Alternatively or additionally, the rate of missed heartbeats can be used in conjunction with other factors to determine an overall health score of the transport computer (e.g., based on missed heartbeats, response times, and success / rejection rates).

[0149] V. Determining an expected data volume

[0150] Determining an expected data flow involves analyzing historical behavior of the transport computer. The historical behavior can be selected based on temporal proximity and / or based on cyclical patterns.

[0151] One such method of determining an expected data volume described below involves an analysis of historical parameters compared to current parameters associated with the transport computer. As requests are processed, the gateway server can store parameters associated with the transport computer along with data volume data. Analysis of such data can be used to create a predictive model for determining an expected data volume based on current conditions.

[0152] Another such method of determining an expected data volume described below involves an analysis of recent data volumes. The gateway server can store data volume data associated with each of a plurality of transport computers. The gateway server can use the stored data volume data to identify transport computers that have recently experienced a relatively high data volume.

[0153] A. Historical parameter analysis

[0154] Figure 7 A method 700 of determining a recent data volume of a transport computer using historical parameter analysis is shown.

[0155] At step 702, the gateway server sends an initial set of authorization requests to the transport computer. The gateway server can receive the initial set of authorization requests from various resource provider computers. The gateway server can forward the initial set of authorization requests to the transport computer. This can occur over a particular period of time. For example, the gateway server can track initial authorization requests over a period of months to collect data for training a model.

[0156] At step 704, the gateway server stores a plurality of parameters associated with the initial set of authorization requests. For example, the gateway server can store the parameters in one or more arrays or objects in a routing database. The gateway server can parse each received message based on data fields of the authorization requests to obtain the parameters. The parameters can include time, location, amount, communication channel, etc. Values corresponding to these parameters can be stored in an indexed manner into the routing database (e.g., one column of an array can correspond to timestamps associated with each of a series of received authorization requests, another column of the array can correspond to corresponding amounts, etc.).

[0157] At step 706, the gateway server receives a new authorization request. The gateway server can receive the new authorization request from a resource provider computer, as described above in Section III.

[0158] At step 708, the gateway server identifies a plurality of current data elements associated with the transport computer. The data elements can be associated with the transport computer in the sense that the data elements pertain to the transport computer. For example, the data elements can include one or more of a location of the transport computer, a timestamp of a record of the transport computer, a communication channel used by the transport computer, or an error status of the transport computer. The gateway server can parse the new authorization request and obtain the various data elements, generally as described above with respect to collecting historical parameters at step 704.

[0159] At step 710, the gateway server analyzes the parameters associated with the initial set of authorization requests. The gateway server can analyze the initial authorization requests to identify parameters associated with a high historical data volume. For example, a particular date, time of day, and / or location can historically be associated with a higher than average data volume for the transport computer. The gateway server can identify particular parameter values or combinations thereof that are associated with a higher than average data volume. This can include using the collected historical data to determine an average data volume.

[0160] At step 712, the gateway server determines an expected data volume for the transport computer. The gateway server can determine the expected data volume for the transport computer by comparing the current data and the analyzed parameters associated with the initial set of authorization requests. This can be done using rules determined based on the analysis of step 710. For example, based on the parameter analysis of step 710, the gateway server can have determined that on Dhanteras, a popular shopping day in India, the data volume for the transport computer is expected to be high. If the current request data indicates that a request has been received on Dhanteras, the gateway server can predict a high data volume.

[0161] B. Recent data volume

[0162] The gateway server can determine the expected data volume of the transport computer based on the recent data volume of the authorization requests. The gateway server can track messages and / or multiple authorization requests that are routed to the transport computer over a period of time. For example, the gateway server can increment a counter each time a message is routed to the transport computer within an hour of time. As another example, the gateway server can store data associated with each message to the transport computer to a routing database. Such data can include a timestamp, a message source, a transaction channel, and the like.

[0163] The gateway server can analyze the recent messages to determine the expected data volume. The gateway server can use the counter value calculated over a predetermined period of time and use it as an indication of the current data volume. The current data volume can serve as a good measure of the recent data volume. Alternatively or additionally, the gateway server can calculate the change in data volume over a recent period of time. For example, if the data volume has been steadily increasing over an hour, the expected data volume can continue to increase in a similar trajectory.

[0164] VI. Success / rejection analysis

[0165] Figure 8 A method 800 is shown for determining a measure of availability of a transport computer using success / rejection analysis, according to some embodiments.

[0166] At step 802, the gateway server sends a request to the transport computer. The request can be an authorization request. Alternatively or additionally, the request can be an authentication request.

[0167] Subsequently, the transport computer can receive the request. The transport computer can add data and / or code to the request. The transport computer can send the request to a processing network and / or an authorization computer.

[0168] The processing network and / or the authorization computer can perform a fraud analysis. In some cases, based on the information received from the transport computer, the processing network and / or the authorization computer can determine that the request should be erroneously rejected. For example, the transport computer can add an incorrect code or piece of information to the request before proceeding to send the request. Thus, some transport computers can cause the system to reject an disproportionate number of requests based on false positives. Thus, the ratio of rejected requests to successful requests can be used to assess the health of the transport computer.

[0169] The processing network and / or the authorization computer sends a response to the transport computer indicating success (e.g., the request passed fraud screening) or rejection (e.g., the request failed fraud screening). The transport computer receives the response and sends the response to the gateway server. The gateway server receives the response.

[0170] At step 804, the gateway server determines whether the transport computer transmitted back a success or a denial. The gateway server can analyze the received message to make this determination. For example, the gateway server can receive an authorization response message containing a numeric code that indicates whether the request was approved or denied. The gateway server can identify the code within the message and use a stored mapping to find the meaning of the code. These codes can vary between the transport computer, the processing network, and / or the authorization computer. Thus, the gateway server can maintain a set of mappings that specify different approval / denial codes used by different entities.

[0171] If the gateway server determines that the transport computer transmitted back a success (e.g., the authorization request was approved), the gateway server can proceed to step 806. If the gateway server determines that the transport computer transmitted back a denial (e.g., the authorization request was denied), the gateway server can proceed to step 808.

[0172] At step 806, the gateway server records the success. As an example, the gateway server can maintain a variable stored in memory that is incremented as messages indicating success are received. As a second example, the gateway server can maintain a two-row by N-column array, where each column corresponds to a received message indicating a success or a denial, respectively.

[0173] At step 808, the gateway server records the denial. As an example, the gateway server can maintain a variable stored in memory that is incremented as messages indicating denial are received. As a second example, the gateway server can store successes and denials to an array, as described above with respect to step 806.

[0174] At step 810, the gateway server determines whether a predetermined time has passed. The gateway server can periodically evaluate a set of recorded successes and denials. This can correspond to a stored predetermined time interval. For example, every day or every two hours, the gateway server can determine that a predetermined time has passed. Thus, the gateway server can obtain a stored number of recorded successes and failures within a predetermined time interval. After determining that a predetermined time has passed, the gateway server can proceed to step 812. If the gateway server determines that a predetermined time has not passed, the gateway server can return to step 802 and continue to collect additional success / denial data.

[0175] At step 812, the gateway server computes a denial / success ratio. The gateway server can identify a number of stored recorded successes. The gateway server can identify a number of stored recorded denials. The gateway server can compute a denial / success ratio based on the recorded successes and denials.

[0176] Alternatively or additionally, a different response grouping can be used to calculate the reject / success ratio (e.g., not using time intervals). For example, the ratio can be calculated for the last 10,000 responses rather than for a number of responses in a predetermined time range.

[0177] At step 814, the gateway server compares the ratio to a baseline ratio. The gateway server can identify a stored baseline ratio. The baseline ratio can correspond to an average or acceptable ratio of successes to rejections. For example, 10% of requests are fraudulent in a particular region and / or time of year. Thus, the gateway server can determine that a transport computer that processes requests in which 30% or a higher percentage of requests are rejected as fraudulent is likely doing so in error, and is a less desirable destination for routing messages than those transport computers that process requests in which nearly 10% of requests are flagged as fraudulent.

[0178] VII. Example Interfaces

[0179] An example interface is shown in Figures 9A-9C . The interface of Figure 9A may be used by an administrator (e.g., associated with a resource provider) to configure routing rules. Figure 9B The interface of 9C may be used by an administrator to check the health of transport computers.

[0180] A. Rule Configuration

[0181] Figure 9A An interface 900 for intelligent rule configuration is shown, in accordance with some embodiments. The intelligent rule configuration interface can include various elements that enable a user (e.g., an administrator associated with a resource provider) to configure routing preferences for use in the intelligent routing decisions described in detail above.

[0182] The interface 900 can include a field for a rule name 902. The field for the rule name 902 can enable a user to enter a name to distinguish various rules to be configured. The interface 900 can accept a rule name via a text entry and / or a drop-down menu. As shown in Figure 9A , the rule name is ROUTING RULE 1.

[0183] The interface 900 can include a field for a resource provider ID 904. The field for the resource provider ID 904 can enable a user to enter or select data specifying a resource provider corresponding to the rule. The interface 900 can accept a resource provider ID via a text entry and / or a drop-down menu. As shown in Figure 9A , the rule name is 1234567.

[0184] Interface 900 can include fields that specify a set of transport computers (906, 908, 910). These fields can include a primary transport computer field 906 for specifying a primary transport computer. This primary transport computer can receive preference in routing. A secondary transport computer field 908 can be configured to accept input specifying a second option transport computer. A tertiary transport computer field 910 can be configured to accept input specifying a third option transport computer. Interface 900 can accept data specifying a set of transport computers using text entries and / or drop-down menus. As Figure 9A shown, the primary transport computer is TC1, the secondary transport computer is TC2, and the tertiary transport computer is TC3. In some embodiments, a routing algorithm can generally send requests to the primary transport computer, and send requests to the secondary or tertiary transport computer if the primary transport computer is not in good health (e.g., experiences a fault and / or a delay resulting in a low health score). Alternatively or additionally, the ranking of the transport computers can be used as a factor in the routing algorithm (e.g., the primary transport computer is weighted more than the secondary transport computer, which is weighted more than the tertiary transport computer).

[0185] Interface 900 can further include fields for configuring specific rules. Parameters can be selected using a "field" entry 914. These parameters can correspond to information received in an authorization request message. As Figure 9A shown, the configured rules relate to a "currency" field. This can correspond to a specific field of an authorization request message. For example, in the ISO 8583 format, field 49 corresponds to a transaction currency code. Using the "field" entry 914, a user can specify data corresponding to such a field of an authorization request message. Other examples include a transaction time (field 12 in ISO 8583), a transaction date (field 13 in ISO 8583), and a transaction amount (field 4 in ISO 8583).

[0186] A "value" entry 916 can be configured to receive information corresponding to a value corresponding to the "field" entry 914. As Figure 9A shown, a first rule specifies a value of USD for currency, a second rule specifies a value of CAD for currency, and a third rule specifies a currency of GBP. As another example, if the field is a transaction amount, the value can be a dollar amount for the transaction (e.g., $100).

[0187] The "priority" entry 918 can be configured to receive information that specifies the priority of the rules. As shown in 918, the priority of the rules is 1, 2, 3, respectively. This can indicate that the weighting of the rule with priority "1" should be greater than the rule with priority "2," and the weighting of the rule with priority "2" should be greater than the rule with priority "3." In Figure 9A In the example shown, the rules are mutually exclusive (e.g., currency is either dollars, Canadian dollars, or pounds). However, other rule sets can include two or more rules that can apply at the same time. For example, rule 1 specifies currency = dollars, and rule 2 specifies greater than $1,000. In this case, the priority of the rules can come into play.

[0188] The "transport computer" entry 920 can be configured to receive information that specifies the transport computer to select in conjunction with the rules. As shown in 918, the transport computer for the rules is TC1, TC1, and TC2, respectively. Thus, if the currency is dollars according to the first rule, TC1 should be selected. If the currency is Canadian dollars according to the second rule, TC1 should also be selected. If the currency is pounds according to the third rule, TC2 should be selected.

[0189] The "condition" entry 922 can be configured to receive information that specifies the condition. The condition can link the field to the value. For example, as shown in 922, each of the condition entries is "equals." Thus, the rules specify "currency equals dollars," "currency equals Canadian dollars," and "currency equals pounds." As another example, if the field is "transaction amount" and the value is "$100," the condition can be "equals," "greater than," "greater than or equal to," "less than," "less than or equal to." Figure 9A

[0190] The interface 900 can further include a rule submission element 924 for submitting the rules. This rule submission element 924 can be, for example, a clickable button, as shown in 924. Upon detecting an interaction by the user with the rule submission element 924, the interface can retrieve the data selected by the user and generate and store the rules based on this user-selected data. Figure 9A

[0191] B. Transport Computer Status

[0192] Figure 9B and 9C Figures 17A-17C show interfaces that display information about the status of the transport computers. These interfaces can include various elements that show the user (e.g., an administrator associated with the resource provider) detailed information about the health of the transport computers.

[0193] Figure 9B ​​An interface 950 is shown for displaying information about the status of transmission computers, where a group of transmission computers have a "health status". Interface 950 includes a rules section 952. The rules section 952 specifies a set of routing filtering rules 954 and a set of ordered transmission computers 956 for a specific resource provider defined by resource provider ID 958.

[0194] A set of ordered transport computers 956 indicates the three transport computers to be used in preferred order (primary transport computer A, secondary transport computer B, and tertiary transport computer C). Routing filtering rule 954 specifies the conditions under which a particular transport computer—including additional transport computers (D and E)—should be selected.

[0195] Interface 950 further includes a daemon status section 960. The daemon status section 960 displays the status 964 of each of the transmission computers 962 indicated in rule section 952. (As...) Figure 9B As shown, each of the transmission computers has a "healthy" state. This can indicate that these transmission computers are not returning error codes, are unresponsive, or are experiencing significant delays or data surges. The daemon status section 960 may further include color codes 968 that indicate the health status of the transmission computers in a prominent, user-friendly manner. The daemon status section 960 may further include the time of the last activity 966 of each of the transmission computers 962.

[0196] Interface 950 further includes an “All Status” section 970. The “All Status” section 970 displays detailed information about a specific request processed by a transport computer. This detailed information may include a request ID 972 identifying the specific request, the transport computer 974 processing the corresponding request, and the response time 976 for each transport computer (e.g., how long it takes to receive a response after the request is sent to the appropriate transport computer). This detailed information may further include the service 978 corresponding to the request (e.g., authorization), the request status 980 (e.g., successful acceptance (SOK)), the amount 982 (e.g., $99 or $101), and the resource provider ID 984 corresponding to the resource provider that submitted the request. Although a particular resource provider may have configured the rules shown in interface 950, the “All Status” section can display information based on transaction retrieval between multiple resource providers, thereby fully utilizing the large amount of data available to the gateway computer.

[0197] Figure 9C An interface 990 is shown for displaying information about the status of the transmission computer, where the transmission computer is in an "unhealthy" state. The elements of interface 990 are largely similar to those described above. Figure 9Binterface 950 described. However, transfer computer E has an "unhealthy" status 992 and is indicated with a different health color code 994. Since transfer computer E was selected by one of the rules, this will show the administrator that the rules are likely to be overridden due to the poor health of the transfer computer.

[0198] VIII. Computer System

[0199] Any computer system referred to herein can utilize any suitable number of subsystems. Figure 10 Examples of such subsystems are shown in computer device 1000 in FIG. 10. In some embodiments, a computer system includes a single computer device, where the subsystems can be components of the computer device. In other embodiments, a computer system can include multiple computer devices with internal components, each computer device being a subsystem.

[0200] Figure 10 The subsystems shown in FIG. 10 are interconnected via a system bus 1005. Additional subsystems such as a printer 1004, a keyboard 1008, a storage device 1009, a monitor 1006, which is coupled to display adapter 1011, and many other devices can be connected to the computer system. Peripheral devices and I / O devices can be connected to the computer system by any number of means known in the art such as input / output (I / O) port 1007 (e.g., USB, Firewire, etc.) or external interface 1010 (e.g., Ethernet, Wi-Fi, etc.) for example. The interconnection via system bus 1005 allows the central processor 1003 to communicate with each subsystem and to control the execution of instructions from system memory 1002 or the storage device 1009 (e.g., a fixed disk, such as a hard drive or optical disk), as well as the exchange of information between the subsystems. The system memory 1002 and / or the storage device 1009 can embody a computer readable medium. Any data mentioned herein can be output from one component to another component and can be output to a user.

[0201] The computer system can include a plurality of the same components or subsystems, which can be configured to operate as processing devices in a cluster or a parallel processing environment. In some embodiments, the computer system, subsystem, or device can communicate over a network with one or more other computer systems, subsystems, or devices. In such cases, the one or more other computer systems, subsystems, or devices can be similar to the computer system, subsystem, or device.

[0202] It should be appreciated that any of the embodiments of the present application can be implemented in the form of control logic using hardware (e.g. an application specific integrated circuit or field programmable gate array) and / or using computer software with a generally programmable processor in a modular or integrated manner. As used herein, a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods to implement embodiments of the present application using hardware and a combination of hardware and software.

[0203] Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, such as a

[0204] Such a computer readable medium can be a combination of one or more of the above examples or others now known or later learned. A computer program product on the computer readable medium can also contain program code executable by one or more processors in a computer system or product for carrying out the methods and / or techniques described herein. The computer readable medium can be, for example, but is not limited to, random access memory (RAM) including static and dynamic RAM, ROM, electrically programmable ROM (EPROM), electrically erasable and programmable ROM (EEPROM), non-volatile memory (e.g., flash memory), a floppy disk, a flexible disk, a hard disk, a magnetic tape or cassette, an optical disk such as CD or DVD, magneto-optical disk, a holographic memory, a PC card, a smart card, a DRAM, SRAM, flash memory, or any other appropriate circuitry, as well as any suitable information bearing medium now known or later learned, including the Internet and intranets, including wireline and wireless options.

[0205] Any method described herein can be performed wholly or partially by a computer system including one or more processors configured to perform the steps. Therefore, embodiments may relate to a computer system configured to perform the steps of any method described herein, possibly having different components that perform corresponding steps or groups of corresponding steps. Although presented as numbered steps, the method steps herein may also be performed simultaneously or in different orders. Furthermore, portions of these steps may be used in conjunction with portions of other steps from other methods. Similarly, all or part of a step may be optional. Additionally, any step of any method may be performed using modules, circuits, or other means for performing these steps.

[0206] Specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention. However, other embodiments of the invention may be directed to specific embodiments relating to each individual aspect or a particular combination of these individual aspects. The foregoing description of exemplary embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms described; many modifications and variations are possible in accordance with the teachings above. These embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling those skilled in the art to best utilize the invention in various embodiments and to make various modifications suitable for the particular intended use.

[0207] Unless explicitly indicated otherwise, the use of “a / kind” or “the / described” is intended to mean “one / kind or more / kinds”. Unless explicitly indicated otherwise, the use of “or” is intended to indicate “inclusive or” rather than “exclusive or”.

[0208] All patents, patent applications, publications, and descriptions mentioned herein are incorporated herein by reference in their entirety for all purposes. They are not acknowledged as prior art.

Claims

1. A method for routing, the method comprising performing the following operations by a gateway server: receiving, from a resource provider computer, an authorization request to access a resource, the authorization request including a resource provider identifier corresponding to a resource provider; determining a set of transport computers based on the resource provider identifier; for each transport computer in the set of transport computers: determining a measure of network availability of the transport computer within a network based on state information retrieved from the transport computer; and identifying an expected data volume of authorization requests for the transport computer; based at least on a plurality of stored rules, the expected data volume of authorization requests for each transport computer in the set of transport computers, and the measure of network availability of each transport computer in the set of transport computers: selecting a particular transport computer to process the authorization request; and sending the authorization request to the particular transport computer over the network.

2. The method of claim 1, wherein the state information retrieved from the transport computer includes one or more of: an error code, a response code, or a response time.

3. The method of claim 1, further comprising: retrieving the state information of the transport computer by: sending one or more messages to the transport computer; and recording one or more respective response times or connection failures, wherein determining the measure of network availability of the transport computer includes calculating a score based on the one or more respective response times or connection failures.

4. The method of claim 1, further comprising: retrieving the state information of the transport computer by receiving a number of heartbeat messages from the transport computer over a time period, wherein determining the measure of network availability of the transport computer includes comparing the number of heartbeat messages received over the time period to an expected number of heartbeat messages to be received over the time period, the expected number of heartbeat messages determined based on a specified heartbeat message rate and a length of the time period.

5. The method of claim 1, further comprising: sending a plurality of requests to the transport computer; receiving a respective plurality of responses from the transport computer, each response indicating success or rejection; based on the respective plurality of responses, calculating a ratio of rejections to successes; and comparing the calculated ratio to a baseline ratio, wherein the particular transport computer is selected based on the comparison.

6. The method of claim 1, further comprising: calculating a score based on the measure of network availability, the expected data volume of authorization requests, and the plurality of stored rules; and using the score in selecting the particular transport computer.

7. The method of claim 1, further comprising: causing display of an interface for the resource provider to configure rules; receiving, by the gateway server, input configuring rules via the interface; based on the input, generating the rules; and storing the rules as part of the plurality of stored rules. ​ ​ 8. The method of claim 1, further comprising: receiving a notification that the particular transport computer failed to process the authorization request; based at least on the notification, the stored plurality of rules, the expected amount of data for authorization requests of each transport computer in the set of transport computers, and the measure of network availability of each transport computer in the set of transport computers: selecting a different transport computer to process the authorization request; and sending the authorization request to the different transport computer.

9. A method for routing, the method comprising performing by a resource provider computer: sending, to a gateway server, an authorization request for access to a resource, the authorization request including a resource provider identifier corresponding to a resource provider associated with the resource provider computer; thereby causing the gateway server to send the authorization request to a particular transport computer in a set of transport computers determined based on the resource provider identifier, wherein the particular transport computer is selected based on an expected amount of data for authorization requests of the transport computers, a measure of network availability of the transport computers, and a stored plurality of rules for transport computer selection; and receiving, by the resource provider computer, an authorization response via the particular transport computer.

10. The method of claim 9, further comprising, prior to sending the authorization request: displaying, by the resource provider computer, a rules configuration interface; receiving, via the rules configuration interface, a ranking of a set of transport computers; and generating the stored plurality of rules based on the received ranking.

11. A computer program product storing code executable by one or more processing devices to perform the method of any of claims 1-10.

12. A system for routing, the system comprising: one or more processing devices; and a non-transitory computer-readable medium coupled to the one or more processing devices, the non-transitory computer-readable medium comprising code executable by the one or more processing devices to perform the method of any of claims 1-10.

Images