Abstract: Disclosed herein are system, method, and computer program product embodiments for controlling message routing for transaction processing platforms. The routing of transaction messages mitigates service disruptions to client systems facilitating transactions with consumers. A connection management and transaction routing platform (CMTRP) system applies routing configurations, such as passthrough, throttling, and/or maintenance toggle configurations, to facilitate the routing of transaction messages. This routing may route message to different transaction processing platforms and/or different instances of transaction processing platforms. The CMTRP system also routes transaction messages when transaction processing functionality is being migrated from a first transaction processing platform to a second transaction processing platform and/or when a platform is undergoing maintenance.

Abstract: Disclosed herein are system, method, and computer program product embodiments for controlling message routing for transaction processing platforms. The routing of transaction messages mitigates service disruptions to client systems facilitating transactions with consumers. A connection management and transaction routing platform (CMTRP) system applies routing configurations, such as passthrough, throttling, and/or maintenance toggle configurations, to facilitate the routing of transaction messages. This routing may route message to different transaction processing platforms and/or different instances of transaction processing platforms. The CMTRP system also routes transaction messages when transaction processing functionality is being migrated from a first transaction processing platform to a second transaction processing platform and/or when a platform is undergoing maintenance.

Abstract: Disclosed are various embodiments for implementing scheduled transactions within a payment network. A computing device first determines that a trigger has occurred for a scheduled transaction for a first payment network. Then, the computing device identifies a network identifier for the recipient and a participant identifier for a recipient of the scheduled transaction. Next, the computing device determines, based at least in part on the network identifier, that the recipient of the scheduled transaction is associated with a second payment network. Subsequently, the computing device generates a payment request representing the scheduled transaction, the payment request comprising the network identifier for the recipient and the participant identifier for the recipient. Then, the computing device forwards the payment request to a global transaction router of a supernetwork.

Abstract: Disclosed are various embodiments for implementing scheduled transactions within a payment network. A computing device first determines that a trigger has occurred for a scheduled transaction for a first payment network. Then, the computing device identifies a network identifier for the recipient and a participant identifier for a recipient of the scheduled transaction. Next, the computing device determines, based at least in part on the network identifier, that the recipient of the scheduled transaction is associated with a second payment network. Subsequently, the computing device generates a payment request representing the scheduled transaction, the payment request comprising the network identifier for the recipient and the participant identifier for the recipient. Then, the computing device forwards the payment request to a global transaction router of a supernetwork.

Abstract: Disclosed are various embodiments for determining availability of payment entities existing on various payment networks. In one non-limiting example, a computing device is configured to transmit a query to a first network hub for a status of a participant system. The participant system is connected to the first network hub. The computing device is configured to determine a participant status for the participant system based at least in part on a query response from the first network hub. A participant status cache is updated based at least in part on the participant status. The participant status is propagated to a second network hub connected to the first supernetwork instance. The participant status is propagated to a second supernetwork instance connected to the first supernetwork instance.

Abstract: Disclosed are various embodiments for facilitating payments between members of separate payment networks. At least one embodiment can send a payment request to a network hub connected to a supernetwork instance and linked to a first payment network, the payment request specifying an identifier for a recipient institution and an amount of the payment request. Then the embodiment can receive a payment response to the payment request indicating that the payment request is being forwarded to a global transaction router of the supernetwork instance, wherein the response to the payment request comprises at least a supernetwork tracking identifier. The embodiment can then send a tracking request to a transaction tracker service of the supernetwork instance, the tracking request comprising the supernetwork tracking identifier. Then the embodiment can receive a tracking response to the tracking request, the tracking response comprising various tracking information.

Abstract: Disclosed are various embodiments for implementing scheduled transactions within a payment network. A computing device first determines that a trigger has occurred for a scheduled transaction for a first payment network. Then, the computing device identifies a network identifier for the recipient and a participant identifier for a recipient of the scheduled transaction. Next, the computing device determines, based at least in part on the network identifier, that the recipient of the scheduled transaction is associated with a second payment network. Subsequently, the computing device generates a payment request representing the scheduled transaction, the payment request comprising the network identifier for the recipient and the participant identifier for the recipient. Then, the computing device forwards the payment request to a global transaction router of a supernetwork.

Abstract: Disclosed are various embodiments for providing multirail payment accounts. First, a payment instruction specifying at least a recipient of the payment and an amount of the payment can be received. Then, one or more payment policies applicable to the payment instruction can be identified. Next, the payment instruction can be funded according to the one or more payment policies. Subsequently, a payment request can be generated based at least in part on the payment instruction. Then, the payment request can be sent to a network hub.

Abstract: Disclosed are various embodiments for facilitating payments between members of separate payment networks. A first instance of a supernetwork can receive a payment request from a source network hub connected to the first supernetwork instance and linked to a first payment network, the first payment request specifying an identifier for a recipient institution and an amount of the payment request. The first instance of the supernetwork can then query a participant status cache to identify a destination network hub linked to a second payment network associated with the recipient institution. Next, the first instance of the supernetwork can query a participant registry to identify a second supernetwork instance connected to the destination network hub. Finally, the first instance of the supernetwork can forward the payment request to a second global transaction router hosted by a second supernetwork instance connected to the destination network hub.