[0001] The present disclosure relates to routing of electronic transactions and in particular the routing of payment transactions.
Background
[0002] Payment transactions using payment cards such as credit cards are typically processed by an acquirer identifying a payment network associated with the payment card and routing a transaction authorization request to the payment network. The payment network then routes the payment transaction authorization request to an issuer. The issuer determines whether to authorize the payment transaction and a payment authorization response is routed back to the acquirer via the payment network.
[0003] The above process requires that the acquirer has a connection to the payment network. In the event that there is no network connection between the acquirer and the payment network, payment transaction authorization requests for payment cards corresponding to that payment network cannot be processed.
Summary
[0004] According to a first aspect of the present invention a system for routing an electronic transaction is disclosed. The system comprises a server and a multiplexer. The server has a computer processor and a data storage device. The data storage device stores instructions operative by the processor to: receive a transaction authorization request from a server associated with an acquirer, the transaction authorization request comprising an indication of a payment card associated with a first payment network; determine that the transaction authorization request is to be routed to the first payment network and route the transaction authorization request to the multiplexer in the second payment network. The multiplexer is configured to route the transaction authorization request from the second payment network to the first payment network.
[0005] In an embodiment, the data storage device stores further instructions operative by the processor to: in response to receiving the transaction authorization request, format the transaction authorization request in a format of the second payment network, and the multiplexer being further configured to convert the transaction authorization request from the format of the second payment network to a format of the first payment network before routing the transaction authorization request to the first payment network.

[0006] In an embodiment, the data storage device stores further instructions operative by the processor to: format the transaction authorization request in a format of the second payment network by storing the transaction authorization request as a plurality of data elements formatted according to the IS08583 standard and at least one data element specific to the second payment network stored as a private data element.
[0007] In an embodiment, the multiplexer is further configured to convert the transaction authorization request from the format of the second payment network to a format of the first payment network by storing the private data element as a data element specific to the first payment network.
[0008] In an embodiment, the multiplexer is further configured to receive a transaction authorization response from the first payment network, and to route the transaction authorization response to the server associated with the acquirer.
[0009] According to a second aspect of the present invention, a system for routing an electronic transaction is disclosed. The system comprises a computer processor and a data storage device. The data storage device stores instructions operative by the processor to: receive a transaction authorization request, the transaction authorization request comprising an indication of a payment card associated with a first payment network; identify the first payment network using the indication of the payment card; determine that the transaction authorization request is to be rerouted; and route the transaction authorization request to a second payment network.
[0010] In an embodiment, the data storage device stores further instructions operative by the processor to: determine that the transaction request is to be rerouted by identifying that first payment network is inoperable.
[0011] In an embodiment, the data storage device stores further instructions operative by the processor to: identify that the first payment network is inoperable by sending the transaction authorization request over the first payment network and receiving a message failure or timeout indication.
[0012] In an embodiment, the data storage device stores further instructions operative by the processor to: determine that the transaction authorization request is to be rerouted by determining a payment card issuer associated with the payment card and identifying that transactions associated with payment cards from the payment card issuer should be rerouted via the second payment network.
[0013] According to a third aspect of the present invention, a method of routing an electronic transaction in a payment network is disclosed. The method comprises: receiving a

transaction authorization request from a server associated with an acquirer, the transaction authorization request comprising an indication of a payment card associated with a first payment network, in a server of a second payment network; routing the transaction authorization request to a multiplexer in the second payment network; and routing the transaction authorization request, in the multiplexer, to the first payment network.
[0014] According to a fourth aspect of the present invention, a method of routing an electronic transaction in a server associated with an acquirer is disclosed. The method comprises: receiving a transaction authorization request, the transaction authorization request comprising an indication of a payment card associated with a first payment network; identifying the first payment network using the indication of the payment card; determining that the transaction authorization request is to be rerouted; and routing the transaction authorization request to a second payment network.
[0015] Embodiments of the invention may be expressed as a network of communicating devices (i.e. a "computerized network"). It may further be expressed in terms of a software application downloadable into a computer device to facilitate the method. The software application may be a computer program product, which may be stored on a non-transitory computer-readable medium on a tangible data-storage device (such as a storage device of a server, or one within a user device).
Brief description of the drawings
[0016] Embodiments of the invention will now be described by way of example only with reference to the following drawings, in which:
Figure 1 is a block diagram showing a system for routing transactions according to an embodiment of the present invention;
Figure 2 is a block diagram showing the functional modules of the acquirer server shown in Figure 1;
Figure 3 is a block diagram showing the second payment network shown in Figure 1;
Figure 4 is a flowchart showing a method of routing a payment transaction authorization request in an acquirer server according to an embodiment of the present invention;
Figure 5 is a flowchart showing a method of routing a payment transaction authorization request in an acquirer server according to an embodiment of the present invention;

Figure 6 is a flowchart showing a method of routing a payment transaction authorization request in a payment network according to an embodiment of the present invention;
Figure 7 is a flowchart showing a method of routing a payment transaction authorization request and a corresponding payment transaction authorization response is a system according to an embodiment of the present invention;
Figure 8 is a flowchart showing a method of routing a payment transaction authorization response in a payment network according to an embodiment of the present invention;
Figure 9 is a block diagram showing a technical architecture of an acquirer server according to an embodiment of the present invention; and
Figure 10 is a block diagram showing a technical architecture of a payment network server according to an embodiment of the present invention.
Detailed description
[0017] Figure 1 is a block diagram showing a system 100 for routing transactions according to an embodiment of the present invention. The system 100 comprises a payment terminal 110 such as a point of sale (POS) device or an automated teller machine (ATM). The payment terminal is operable to read data from a payment card 115 and to generate transaction authorization requests using the data read from the payment card 115 and transaction details such as a transaction amount.
[0018] As used in this document, the term "payment card" refers to any cashless payment device associated with a payment account, such as a credit card, a debit card, a prepaid card, a charge card, a membership card, a promotional card, a frequent flyer card, an identification card, a prepaid card, a gift card, and/or any other device that may hold payment account information, such as mobile phones, Smartphones, personal digital assistants (PDAs), key fobs, transponder devices, NFC-enabled devices, and/or computers. Furthermore, the "payment card" may exist only as a data structure (i.e. without physical existence), which is registered with a digital wallet or cloud wallet.
[0019] The payment terminal 110 is coupled to an acquirer server 120 which is associated with an acquirer bank or similar organization. In the example scenario shown in Figure 1, the payment card 115 is issued by an issuer bank which has an associated issuer server 140. The issuer server 140 is connected to a first payment network 130. In conventional payment card transaction processing, the acquirer server 120 would send a transaction authorization request for a payment transaction made on the payment card 115 over the first payment network 130. Communication between the servers may take place via any

type of network, for example, a virtual private network (VPN), the Internet, a local area and/or wide area network (LAN and/or WAN), and so on.
[0020] Embodiments of the present invention relate to a scenario as shown in Figure 1 in which there is a lack of connectivity between the acquirer server 120 and the first payment network 130. This lack of connectivity may be due to a network failure. Other embodiments are envisaged in which there is no connection between the acquirer server 120 and the first payment network 130.
[0021] As shown in Figure 1, the acquirer server 120 is connected to a second payment network 150. The second payment network 150 comprises a multiplexer 155. The multiplexer 155 has a connection to the first payment network 130.
[0022] The first payment network 130 and the second payment network 150 are payment networks such as the Banknet payment network operated by Mastercard, the VisaNet payment network operated by VISA, the RuPay network operated by the National Payments Corporation of India, the American Express payment network, the China UnionPay payment network, the Discover payment network, the Japan Credit Bureau (JCB) payment network and the Diners club payment network.
[0023] In embodiments of the present invention, the acquirer server 120 routes messages such as transaction authorization requests relating to the payment card 115 to the second payment network 150. The messages are then routed by the second payment network 150 to the multiplexer 155 which routes the messages to the first payment network 130. The first payment network 130 then routes the messages to the issuer server 140. Transaction authorization response messages are routed in the reverse path. As described in more detail below, the second payment network 150 may convert messages into a format for the second payment network 150 so that the messages can be processed by the second payment network 150. The multiplexer 155 may then convert the messages to a format of the first payment network 130 so that the messages can be processed by the first payment network 130 once they have been routed by the multiplexer 155.
[0024] Figure 2 is a block diagram showing the functional modules of the acquirer server 120 shown in Figure 1. As shown in Figure 2, the acquirer server 120 comprises payment terminal interface module 224a; a payment network identification module 224b; a payment network interface module 224c and a routing module 224d. A technical architecture of the acquirer server 120 is described in detail below with reference to Figure 9.
[0025] Figure 3 is a block diagram showing the second payment network 150 shown in Figure
1. The second payment network 150 comprises a payment network server 152. The
payment network server comprises the following functional modules. As shown in Figure 3,
6

the payment network server 152 comprises an acquirer interface module 324a, a format conversion module 324b, and a routing module 324c. A technical architecture of the payment network server 152 is described in more detail below with reference to Figure 10. As shown in Figure 3, the second payment network 150 also comprises the multiplexer 155.
[0026] Figure 4 is a flowchart showing a method 400 of routing a transaction in an acquirer server 120 according to an embodiment of the present invention. The method 400 is carried out by the acquirer server 120 of the system 100 shown in Figure 1.
[0027] In step 402, the payment terminal interface module 224a of the acquirer server 120 receives a payment transaction authorization request from the payment terminal 110. The payment transaction authorization request relates to a payment transaction for payment card 115. As described above, payment card 115 is issued by an issuing organization which operates issuer server 140. The payment transaction authorization request comprises an indication of the payment card 115, for example the payment card number of the payment card 115.
[0028] In step 404, the payment network identification module 224b of the acquirer server 120 identifies a payment network associated with the payment card 115. Step 404 may comprise using part of the payment card number, such as the first 4 digits, to determine the payment network associated with the payment card 115. In this example, the payment network identification module 224b of the acquirer server 120 identifies the first payment network 130 as the payment network associated with the payment card 115.
[0029] In step 406, the payment network interface module 224c of the acquirer server 120 attempts to send the payment transaction authorization request to the first payment network 130. The payment network interface module 224c of the acquirer server 120 then determines that the payment transaction authorization request cannot be sent over the first payment network 130. This determination may be made as a result of a multiple attempts, for example, three attempts to connect to the first payment network 130 and in each case receiving a connection failure or time out response.
[0030] In a conventional payment card transaction processing system a determination that the payment transaction authorization request cannot be sent over the first payment network 130 would result in a failed payment transaction and the user being prompted to pay by another payment method. However, in embodiments of the present invention, in response to the determination that the payment transaction authorization request cannot be sent over the first payment network 130, the method moves to step 408.
[0031] In step 408, the routing module 224d of the acquirer server 120 routes the payment
transaction authorization request to the second payment network 150. Then, the payment
7

network interface module 224c of the acquirer server 120 sends the payment transaction authorization request over the second payment network 150.
[0032] In the embodiment described above with reference to Figure 4, the acquirer server 120 has a connection to both the first payment network 130 and the second payment network 150 and the payment transaction authorization request is rerouted from the first payment network 130 to the second payment network 150 as a result of determining that the payment transaction authorization request cannot be sent over the first payment network 130. In an alternative embodiment, payment transactions relating to a payment card issued for the first payment network 130 may be routed through the second payment network 150. Thus, an acquirer with only a connection to the second payment network 150 would still be able to process transactions for payment cards issued for the first payment network 130. Figure 5 which is described below shows such an alternative embodiment.
[0033] Figure 5 is a flowchart showing a method 500 of routing a transaction in an acquirer server 120 according to an embodiment of the present invention. The method 500 is carried out by the acquirer server 120 of the system 100 shown in Figure 1.
[0034] In step 502, the payment terminal interface module 224a of the acquirer server 120 receives a payment transaction authorization request from the payment terminal 110. The payment transaction authorization request relates to a payment transaction for payment card 115. As described above, payment card 115 is issued by an issuing organization which operates issuer server 140. The payment transaction authorization request comprises an indication of the payment card 115, for example the payment card number of the payment card 115.
[0035] In step 504, the payment network identification module 224b of the acquirer server 120 identifies a payment network associated with the payment card 115. As described above in relation to step 404 shown in Figure 4, step 504 may comprise using part of the payment card number, such as the first 4 digits, to determine the payment network associated with the payment card 115. In this example, the payment network identification module 224b of the acquirer server 120 identifies the first payment network 130 as the payment network associated with the payment card 115.
[0036] In step 506, the routing module 224d of the acquirer server 120 determines that the payment transaction authorization request is to be sent over the second payment network 150. The acquirer server 120 may store a routing table indicating that payment cards issued for specific payment networks or payment cards issued by specific payment card issuers are to be routed over the second payment network 150. The routing table may
8

allow the acquirer server 120 to identify the payment cards to be routed over the second payment network 150 by a set of digits of the payment card number.
[0037] In step 508, the routing module 224d of the acquirer server 120 routes the payment transaction authorization request to the second payment network 150. Then, the payment network interface module 224c of the acquirer server 120 sends the payment transaction authorization request over the second payment network 150.
[0038] The routing module 224d of the acquirer server 120 may store a retrieval reference number (RRN) in the payment transaction authorization request which allows the payment transaction authorization request and any corresponding payment transaction authorization response messages to be identified. The RRN remains the same throughout the processing of the transaction authorization request and the corresponding response. Hence the acquirer server may populate this RRN in data element (DE) 37 of the transaction authorization request according to the ISO8583 standard.
[0039] Figure 6 is a flowchart showing a method 600 of routing a payment transaction authorization request in a payment network according to an embodiment of the present invention. The method 600 is carried out by the second payment network 150 shown in Figure 1 after a payment transaction authorization request for a payment card 115 associated with the first payment network 130 is rerouted to the second payment network 150. The method 600 may take place following routing of a payment transaction authorization request to the second payment network 150 by the method 400 described above in relation to Figure 4 or by the method 500 described above in relation to Figure 5. The method 600 is carried out by the second payment network 150 described above in relation to Figure 3.
[0040] In step 602, the acquirer interface module 324a of the payment network server 152 receives the payment transaction authorization request from the acquirer server 120. During step 602, the payment network server 152 may determine that the payment transaction authorization request is to be routed to the first payment network. This determination may be made from the payment card account identifier in the payment transaction authorization request, or alternatively from a flag or other information included in the payment transaction authorization request by the acquirer server 120.
[0041] In step 604, the format conversion module 324b formats the payment transaction authorization request according to a format of the second payment network 150. Parts of the payment transaction authorization request may be formatted according to a standard such as the ISO8583 standard. However, different payment networks may use different communication protocols for communication. For example, the VisaNet payment network
9

uses the Base 1 protocol for authorization request and response messages, whereas the RuPay payment network uses the XML format. Parts of the payment transaction authorization request may be formatted according to a scheme specific to the second payment network 150. Thus the payment transaction authorization request may comprise a plurality of data elements which are formatted according to the ISO8583 standard and at least one data element specific to the second payment network. The parts of the payment transaction authorization method formatted according to a scheme specific to the second payment network may be stored in parts of the payment transaction authorization request specified as private data elements in the ISO8583 standard.
[0042] In step 606, the routing module 324c of the payment network server 152 routes the payment network authorization request to the multiplexer 155. In some embodiments, the second payment network 150 may use part of the payment card number contained within the payment transaction authorization request to identify that the payment transaction authorization request relates to a payment card issued for the first payment network 130 and therefore, the second payment network 150 routes the payment transaction authorization request to the multiplexer 155.
[0043] In step 608, the multiplexer 155 receives the payment transaction authorization request and converts the format of the payment transaction authorization request to a format of the first payment network 130. As described above, the payment transaction authorization request may be formatted according to a protocol of the second payment network and may also comprise a plurality of data elements that are formatted according to the ISO8583 standard and at least one data element private data element which is formatted for the second payment network. Standard data elements (DEs) such as data element 4 which indicates the amount of the transaction, DE 2 which indicates the primary account number (PAN) involved in the transaction, DE 11 which indicates a system trace audit number (STAN), DE 37 which indicates the retrieval reference number (RRN), DE 41 which indicates the card accepter terminal identification, DE 42 which indicates the card acceptor identification code, and DE 43 which indicates the card acceptor name and location may remain the same in the different formats for the first and second payment networks. The format conversion of step 608 may comprise converting the payment transaction authorization request from one protocol (for example the Base 1 protocol used by the VisaNet payment network) to another protocol (such as the XML format used by the RuPay payment network). The format conversion step may also comprise storing the private data element in a format of the first payment network 130. The multiplexer 155 may store a retrieval reference number (RRN) in the payment transaction authorization request which allows the payment transaction authorization request and any corresponding payment transaction authorization response messages to be identified.
10

[0044] In step 610, the multiplexer sends the payment transaction authorization request to the first payment network 130.
[0045] As described above with reference to Figure 6, the payment transaction authorization request is routed by the second payment network 150 and reformatted before it is sent to the first payment network 130. The routing of the payment transaction authorization request and a corresponding payment transaction authorization response by the first payment network 130 is described below with reference to Figure 7.
[0046] Figure 7 is a flowchart showing a method 700 of routing a payment transaction authorization request and a corresponding payment transaction authorization response is a system according to an embodiment of the present invention. The method 700 is carried out by the first payment network 130 shown in Figure 1.
[0047] In step 702, the first payment network 130 receives the payment transaction authorization request. As described above, the payment transaction authorization request may be formatted according to the ISO8583 standard and any non-standard data elements are reformatted so that they may be processed by the first payment network 130. The payment transaction authorization request includes an indication of the payment card 115 may also include a retrieval reference number (RRN).
[0048] In step 704, the first payment network 130 routes the payment transaction authorization request to the issuer server 140. The first payment network uses the indication of the payment card 115 to determine the issuer that issued the payment card 115 and therefore determines the corresponding issuer server 140 to which the payment transaction authorization request is to be routed.
[0049] Upon receiving the payment transaction authorization request, the issuer server 140 determines whether to authorize the payment transaction and generates a payment transaction authorization response. The payment transaction authorization response includes the retrieval reference number which indicates that it corresponds to the payment transaction authorization request sent to the first payment network 130 by the multiplexer 155.
[0050] In step 706, the first payment network 130 receives the payment transaction authorization response from the issuer server 140.
[0051] In step 708, the first payment network 130 routes the payment transaction authorization response to the multiplexer 155. As described above, the payment transaction authorization response includes the RRN which indicates that it relates to the payment transaction authorization request received from the multiplexer 155. Therefore the first
11

payment network 130 uses the RRN to determine that the payment transaction authorization response is to be routed to the multiplexer 155. The first payment network may use a private data element (PDE) populated by the second payment network to be validated back at the time of response. Additionally or alternatively, the following data elements may be used to uniquely identify a transaction authorization request during the routing process: DE 2 which indicates the primary account number (PAN); DE 37 which indicates the retrieval reference number (RRN) and DE 4 which indicates the transaction amount. Other private data elements populated by the acquirer server 120 may also be used to uniquely identify the transaction authorization request and the corresponding response.
[0052] Following step 708 of the method 700 described above with reference to Figure 7, the payment transaction authorization response is routed back to the acquirer server by the second payment network. A method 800 of routing the payment transaction authorization response to the acquirer server 120 is described below with reference to Figure 9.
[0053] Figure 8 is a flowchart showing a method of routing a payment transaction authorization response in a payment network according to an embodiment of the present invention. The method 800 is carried out by the second payment network 150 shown in Figure 1.
[0054] In step 802, the multiplexer 155 receives the payment transaction authorization response from the first payment network 130.
[0055] In step 804, the multiplexer 155 converts the payment transaction authorization response to the format of the second payment network 150. As described above, the format conversation may comprise storing data into private data elements of the payment transaction authorization response which may be formatted according to the ISO8583 standard.
[0056] In step 806, the second payment network 150 routes the payment transaction authorization response to the acquirer server 120. This routing may be implemented by identifying that the transaction authorization response corresponds to the transaction authorization request generated by the acquirer server 120.
[0057] Once the acquirer server 120 receives the payment transaction authorization response, the acquirer processes the payment transaction according to the payment transaction authorization response.
[0058] Figure 9 is a block diagram showing a technical architecture 200 of the acquirer server 120 for performing steps of exemplary methods described above. Typically, the methods
12

are implemented by a number of computers each having a data-processing unit. The block diagram as shown in Figure 9 illustrates a technical architecture 200 of a computer which is suitable for implementing one or more embodiments herein.
[0059] The technical architecture 200 includes a processor 222 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 224 (such as disk drives), read only memory (ROM) 226, random access memory (RAM) 228. The processor 222 may be implemented as one or more CPU chips. The technical architecture 220 may further comprise input/output (I/O) devices 230, and network connectivity devices 232.
[0060] The secondary storage 224 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 228 is not large enough to hold all working data. Secondary storage 224 may be used to store programs which are loaded into RAM 228 when such programs are selected for execution. In this embodiment, the secondary storage 224 has a payment terminal interface module 224a, payment network identification module 224b, a payment network interface module 224c and a routing module 224d, comprising non-transitory instructions operative by the processor 222 to perform various operations of the method of the present disclosure. As depicted in Figure 9, the modules 224a-224d are distinct modules which perform respective functions implemented by the acquirer server 120. It will be appreciated that the boundaries between these modules are exemplary only, and that alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into sub-modules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or sub-module. It will also be appreciated that, while a software implementation of the modules 224a-224d is described herein, these may alternatively be implemented as one or more hardware modules (such as field-programmable gate array(s) or application-specific integrated circuit(s)) comprising circuitry which implements equivalent functionality to that implemented in software. The ROM 226 is used to store instructions and perhaps data which are read during program execution. The secondary storage 224, the RAM 228, and/or the ROM 226 may be referred to in some contexts as computer readable storage media and/or non-transitory computer readable media.
[0061] The I/O devices may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.
13

[0062] The network connectivity devices 232 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 232 may enable the processor 222 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 222 might receive information from the network, or might output information to the network in the course of performing the method operations described herein. Such information, which is often represented as a sequence of instructions to be executed using processor 222, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.
[0063] The processor 222 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 224), flash drive, ROM 226, RAM 228, or the network connectivity devices 232. While only one processor 222 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors.
[0064] It is understood that by programming and/or loading executable instructions onto the technical architecture 200, at least one of the CPU 222, the RAM 228, and the ROM 226 are changed, transforming the technical architecture 200 in part into a specific purpose machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules.
[0065] Figure 10 is a block diagram showing a technical architecture 300 of the payment network server 152 for performing steps of the methods described above. Typically, the methods are implemented by a number of computers each having a data-processing unit. The block diagram as shown in Figure 10 illustrates a technical architecture 300 of a computer which is suitable for implementing one or more embodiments herein.
[0066] The technical architecture 300 includes a processor 322 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including
14

secondary storage 324 (such as disk drives), read only memory (ROM) 326, random access memory (RAM) 328. The processor 322 may be implemented as one or more CPU chips. The technical architecture 320 may further comprise input/output (I/O) devices 330, and network connectivity devices 332.
[0067] The secondary storage 324 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 328 is not large enough to hold all working data. Secondary storage 324 may be used to store programs which are loaded into RAM 328 when such programs are selected for execution. In this embodiment, the secondary storage 324 has an acquirer interface module 324a, a format conversion module 324b, and a routing module 324c, comprising non-transitory instructions operative by the processor 322 to perform various operations of the method of the present disclosure. As depicted in Figure 10, the modules 324a-324c are distinct modules which perform respective functions implemented by the payment network server 152. It will be appreciated that the boundaries between these modules are exemplary only, and that alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into sub-modules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or sub-module. It will also be appreciated that, while a software implementation of the modules 324a-324c is described herein, these may alternatively be implemented as one or more hardware modules (such as field-programmable gate array(s) or application-specific integrated circuit(s)) comprising circuitry which implements equivalent functionality to that implemented in software. The ROM 326 is used to store instructions and perhaps data which are read during program execution. The secondary storage 324, the RAM 328, and/or the ROM 326 may be referred to in some contexts as computer readable storage media and/or non-transitory computer readable media.
[0068] The I/O devices may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.
[0069] The network connectivity devices 332 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM),
15

long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 332 may enable the processor 322 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 322 might receive information from the network, or might output information to the network in the course of performing the method operations described herein. Such information, which is often represented as a sequence of instructions to be executed using processor 322, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.
[0070] The processor 322 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 324), flash drive, ROM 326, RAM 328, or the network connectivity devices 332. While only one processor 322 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors.
[0071] It is understood that by programming and/or loading executable instructions onto the technical architecture 300, at least one of the CPU 322, the RAM 328, and the ROM 326 are changed, transforming the technical architecture 300 in part into a specific purpose machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules.
[0072] Although the technical architecture 300 is described with reference to a computer, it should be appreciated that the technical architecture may be formed by two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and/or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and/or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the technical architecture 300 to provide the functionality of a number of servers that is not directly bound to the number of computers in the technical architecture 300. In an embodiment, the functionality disclosed above may be provided by executing the application and/or applications in a cloud computing environment. Cloud computing may
16

comprise providing computing services via a network connection using dynamically scalable computing resources. A cloud computing environment may be established by an enterprise and/or may be hired on an as-needed basis from a third party provider.
[0073] Whilst the foregoing description has described exemplary embodiments, it will be understood by those skilled in the art that many variations of the embodiments can be made in accordance with the appended claims.

We Claim:

A system for routing an electronic transaction, the system comprising: a server and a
multiplexer,
the server having a computer processor and a data storage device, the data storage device storing instructions operative by the processor to:
receive a transaction authorization request from a server associated with an acquirer, the transaction authorization request comprising an indication of a payment card associated with a first payment network;
determine that the transaction authorization request is to be routed to the first payment network; and
route the transaction authorization request to the multiplexer in a second payment network,
the multiplexer being configured to route the transaction authorization request from the second payment network to the first payment network.
2. A system according to claim 1, wherein the data storage device stores further instructions operative by the processor to: in response to receiving the transaction authorization request, format the transaction authorization request in a format of the second payment network, and the multiplexer being further configured to convert the transaction authorization request from the format of the second payment network to a format of the first payment network before routing the transaction authorization request to the first payment network.
3. A system according to claim 2, wherein the data storage device stores further instructions operative by the processor to: format the transaction authorization request in a format of the second payment network by storing the transaction authorization request as a plurality of data elements formatted according to the IS08583 standard and at least one data element specific to the second payment network stored as a private data element.
4. A system according to claim 3, wherein the multiplexer is further configured to convert the transaction authorization request from the format of the second payment network to a format of the first payment network by storing the private data element as a data element specific to the first payment network.
5. A system according to any preceding claim, wherein the multiplexer is further configured to store a retrieval reference number in the transaction authorization request, the retrieval reference number being configured to allow the first payment network to identify that

any response messages associated with the transaction authorization request are to be routed to the multiplexer.
6. A system according to any preceding claim, wherein the multiplexer is further configured to receive a transaction authorization response from the first payment network, and to route the transaction authorization response to the server associated with the acquirer.
7. A system for routing an electronic transaction, the system comprising:
a computer processor and a data storage device, the data storage device storing instructions operative by the processor to:
receive a transaction authorization request, the transaction authorization request comprising an indication of a payment card associated with a first payment network;
identify the first payment network using the indication of the payment card;
determine that the transaction authorization request is to be rerouted; and
route the transaction authorization request to a second payment network.
8. A system according to claim 7, wherein the data storage device stores further instructions operative by the processor to: determine that the transaction request is to be rerouted by identifying that first payment network is inoperable.
9. A system according to claim 8, wherein the data storage device stores further instructions operative by the processor to: identify that the first payment network is inoperable by sending the transaction authorization request over the first payment network and receiving a message failure or timeout indication.
10. A system according to claim 7, wherein the data storage device stores further instructions operative by the processor to: determine that the transaction authorization request is to be rerouted by determining a payment card issuer associated with the payment card and identifying that transactions associated with payment cards from the payment card issuer should be rerouted via the second payment network.
11. A method of routing an electronic transaction in a payment network, the method comprising
receiving a transaction authorization request from a server associated with an acquirer, the transaction authorization request comprising an indication of a payment card associated with a first payment network, in a server of a second payment network;
routing the transaction authorization request to a multiplexer in the second payment network; and

routing the transaction authorization request, in the multiplexer, to the first payment network.
12. A method according to claim 11, further comprising, in response to receiving the transaction authorization request, formatting the transaction authorization request in a format of the second payment network; and converting the transaction authorization request from the format of the second payment network to a format of the first payment network in the multiplexer before routing the transaction authorization request to the first payment network.
13. A method according to claim 12, wherein the formatting the transaction authorization request in a format of the second payment network comprises storing the transaction authorization request as a plurality of data elements formatted according to the IS08583 standard and at least one data element specific to the second payment network stored as a private data element.
14. A method according to claim 13, wherein converting the transaction authorization request from the format of the second payment network to a format of the first payment network in the multiplexer before routing the transaction authorization request to the first payment network comprises storing the private data element as a data element specific to the first payment network.
15. A method according to any one of claims 11 to 14, further comprising storing by the multiplexer, a retrieval reference number in the transaction authorization request, the retrieval reference number being configured to allow the first payment network to identify that any response messages associated with the transaction authorization request are to be routed to the multiplexer.
16. A method according to any one of claims 11 to 15, further comprising receiving at the multiplexer a transaction authorization response from the first payment network, and routing the transaction authorization response to the server associated with the acquirer.
17. A method of routing an electronic transaction in a server associated with an acquirer, the method comprising:
receiving a transaction authorization request, the transaction authorization request comprising an indication of a payment card associated with a first payment network; identifying the first payment network using the indication of the payment card; determining that the transaction authorization request is to be rerouted; and routing the transaction authorization request to a second payment network.

18. A method according to claim 17, wherein determining that the transaction request is to be rerouted comprises identifying that first payment network is inoperable.
19. A method according to claim 17, wherein determining that the transaction authorization request is to be rerouted comprises determining a payment card issuer associated with the payment card and identifying that transactions associated with payment cards from the payment card issuer should be rerouted via the second payment network.
20. A non-transitory computer readable medium carrying computer executable instructions which when executed on at least one processor cause the at least one processor to carry out a method according to any one of claims 11 to 19.