Patent Publication Number: US-2022222643-A1

Title: Systems and methods for bridging transactions between eft payment networks and payment card networks

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Patent Application Nos. 62/350,322 (filed on Jun. 15, 2016); 62/350,335 (filed Jun. 15, 2016); 62/350,407 (filed Jun. 15, 2016); 62/351,155 (filed Jun. 16, 2016); 62/350,821 (filed Jun. 16, 2016); 62/351,016 (filed Jun. 16, 2016); 62/351,227 (filed Jun. 16, 2016); 62/350,831 (filed Jun. 16, 2016); 62/350,416 (filed Jun. 15, 2016); and 62/351,164 (filed Jun. 16, 2016), and to U.S. patent application Ser. No. 15/621,383 (filed Jun. 13, 2017); the contents of which provisional applications and patent application are hereby incorporated by reference for all purposes. 
    
    
     BACKGROUND 
     Electronic funds transfer (EFT) payment networks are configured to primarily transfer money electronically from one bank account to another, either within a single financial institution or across multiple institutions. The EFT network utilizes one or more computer-based systems without the direct intervention of bank staff to transfer the money, and the accounts can either be commercial accounts or consumer accounts. 
     Payment card networks are configured to process credit card, debit card, and/or pre-paid card account transactions primarily in the retail space, to complete a sale or guarantee payment for services rendered by merchants. Payment card systems and/or payment card networks operate independently and/or mutually exclusively of the EFT payment networks despite some overlaps in in their application. Moreover, the payment card networks use communication protocols that are distinct from those used by the EFT payment networks. 
     Efforts are currently underway to standardize communication protocols for both EFT payment networks and payment card networks such that they can be used interchangeably. However, legacy systems, adoption costs and migration challenges have made it a difficult to realize a single ubiquitous network that would serve all EFT network and payment card system needs and/or requirements. Gateways, which are defined in a communication network as nodes that interface between two or more networks using different protocols by means of a translator, have been built and/or proposed to perform translations at the lower communications layers. But very few gateways bridge two networks at the presentation layer (i.e., conversion from Extensible Markup Language (XML) to Abstract Syntax Notation One (ASN.1), wherein ASN.1 is a standard and notation that describes rules and structures for representing, encoding, transmitting, and decoding data in telecommunications and computer networking). In addition, few gateways bridge two networks at the application layer (i.e. conversion from International Organization for Standardization (ISO) 20022 to ISO 8583, wherein ISO 20022 is a standard for electronic data interchange between financial institutions and ISO 8583 is a standard for systems that exchange electronic transactions made by cardholders using payment cards). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Features and advantages of some embodiments, and the manner in which the same are accomplished, will become more readily apparent with reference to the following detailed description taken in conjunction with the accompanying drawings, which illustrate exemplary embodiments, wherein: 
         FIG. 1  is a block diagram illustrating a payment card account system in accordance with some embodiments of the disclosure. 
         FIG. 2  is a block diagram of an embodiment of a payment network system in accordance with some embodiments of the disclosure. 
         FIG. 3  is a diagram that illustrates a data communication model that is pertinent to aspects of the present disclosure. 
         FIG. 4  is a block diagram illustrating a financial transaction system in accordance with some embodiments of the disclosure. 
         FIG. 5  illustrates an example of a gateway computer system that may perform functions in the system of  FIG. 4  in accordance with some embodiments of the disclosure. 
         FIGS. 6, 7, 8 and 9  are flowcharts illustrating processes that may be performed in the system of  FIG. 4  in accordance with some embodiments of the disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     In general, and for the purpose of introducing concepts of novel embodiments described herein, presented are systems, apparatus and methods for bridging networks at an application layer level, especially between an EFT payment network and a payment card network. The described systems, apparatus and methods assist in the migration speed by which entities switch to modern common standards such as ISO 20022, while at the same time support backward compatibility to participants in a network. In addition, the systems, apparatus and methods presented herein provide freedom to networks and/or network participants to apply the protocol that best meets that system&#39;s optimal performance. 
     In some embodiments, a financial transaction network operates with one or more intelligent edge devices. These edge devices constitute the interface or gateway between network participants (for example, service providers for business applications) and to other networks. The edge devices or gateways serve a central switching platform that is the seat of the networks&#39; operations, and that works independently of the chosen protocol of the network participants and/or other networks. Thus, in some implementations the edge devices or gateways have the know how to be able to switch between its participants and other networks based on business rules that are applied at the application level. 
     In some embodiments, a transaction request message that includes a payment card account addressing indicator may be received at a gateway/bridging computer. The gateway/bridging computer may translate the payment card account addressing indicator to an account addressing indicator in a format for use in an EFT system. The gateway/bridging computer may generate and transmit a transaction request message suitable for routing in the EFT system. The latter request message may include the account addressing indicator that is in the EFT system format. 
     Bridging of transactions between a payment card account network and an EFT network may include translating transaction messages at a presentation layer and at an application layer. A data dictionary may be referred to in order to map business fields from one standard message format to another. Some data elements may be decrypted and then encrypted during conversion of transaction messages. Digital signatures may be managed to authenticate converted transaction messages. 
     A transaction message switching computer may be in communication with a payment card account system and an EFT system. In operation, the transaction message switching computer may store one or more business rules. Upon receiving a transaction request message, the transaction message switching computer may apply the stored business rule(s) and consider the content of the transaction request message so as to select between the payment card account system and the EFT system in determining how to route the transaction request message. Factors such as routing fees and rapidity of execution may be weighed based on the business rule(s). 
     Throughout this disclosure, examples of financial transactions will be described, which are not to be taken as limiting. In addition, a number of terms will be used, the use of which terms is not intended to be limiting, but rather the terms are used for convenience and ease of exposition. For example, as used herein, the term “user” may be used interchangeably with the term “consumer” and/or the with the term “cardholder” and these terms are used herein to refer to a person, individual, consumer, customer, company, business or other entity that owns (or is authorized to use) a financial account such as a bank account (i.e., a savings account and/or a checking account) or payment card account (i.e., a credit card account, debit card account, or pre-paid card account) or some other type of financial account (such as a brokerage account, loyalty card account, and/or mass transit access account). In addition, the term “payment card account” may include a credit card account, a debit card account, and/or a deposit account or other type of financial account that an account holder or cardholder may access. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, and/or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions and the like. Moreover, as used herein the terms “payment card system” or “payment card account system” refer to a system and/or network for processing and/or handling purchase transactions and related transactions, which may be operated by a payment card system operator such as Mastercard International Incorporated, or a similar system. In some embodiments, the term “payment card system” may be limited to systems in which member financial institutions (such as banks) issue payment card accounts to individuals, businesses and/or other entities or organizations (and thus are known as issuer financial institutions or issuer banks). In addition, the terms “payment card system transaction data” and/or “payment card network transaction data” or “payment card transaction data” refer to transaction data associated with payment or purchase transactions that have been or are being processed over and/or by a payment card network or payment card account system. For example, payment card system transaction data may include a number of data records associated with individual payment transactions (or purchase transactions) of cardholders that have been processed over a payment card system or payment card network. In some embodiments, payment card system transaction data may include information such as data that identifies a cardholder, data that identifies a cardholder&#39;s payment device and/or payment card account, transaction date and time data, transaction amount data, an indication of the merchandise or services that have been purchased, and information identifying a merchant and/or a merchant category. Additional transaction details and/or transaction data may also be available and/or utilized for various purposes in some embodiments. 
       FIG. 1  is a block diagram that illustrates a payment card system  100 . The payment card system  100  includes a customer device  102  such as a magnetic stripe card, a payment IC (integrated circuit) card (contactless and/or contact), or a payment-enabled mobile device (such as a Smartphone that includes a payment application), a merchant device  104 , an acquirer financial institution (FI) computer  106 , a card network  108 , and an issuer FI computer  110 . 
     The merchant device  104  may be, for example, a POS (point of sale) terminal/card reader or a merchant mobile device (i.e., a Smartphone), and may also be considered part of the payment card account system  100 . The customer device  102  may be presented to the merchant device  104  to consummate a purchase transaction and to permit the merchant device  104  to read payment card account data (including, for example, a payment account number) from the customer device  102 . In other situations, the merchant device  104  may be an e-commerce server computer, and the customer device  102  may be a personal computer or a mobile device running mobile browser software or the like. In this case, the customer device  102  may engage in an online shopping session with an e-commerce website hosted by the merchant device  104 . 
     During a purchase transaction, the acquirer FI computer  106  may receive a payment account system authorization request message for the transaction from the merchant device  104 . The acquirer FI computer  106  may then route the authorization request message via a card network  108  to an issuer FI computer  110 , which is operated by the issuer of a payment account that is associated with the account number obtained by the merchant device  104  (e.g., from the customer device  102 ) and included in the authorization request message. In some implementations, the authorization response message generated by the payment issuer server computer  110  is routed back to the merchant device  104  via the card network  108  and the acquirer FI computer  106 . 
     One well known example of a payment card network is referred to as the “Banknet” system, and is operated by Mastercard International Incorporated, the assignee of the present application. 
     Referring again to  FIG. 1 , the payment account issuer FI computer  110  may be operated by or on behalf of a financial institution, such as a bank, that issues payment accounts to individual users (such as the customer or consumer who presented or operated the customer device  102  referred to above). For example, the payment card issuer FI computer  110  may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records. 
     The payment card account system communications among the merchants, acquirers, card network and/or issuers may conform to a known standard such as ISO 8583. 
     It should be understood that the components shown in the system  100  of  FIG. 1  are only those that are needed for processing a single transaction. However, a typical or practical payment system may process hundreds, thousands or more purchase transactions per day (including simultaneous transactions), and thus may include a considerable number of payment account issuers and their computers and/or computer networks, a considerable number of acquirers and their computers and/or computer networks, and numerous merchants and their devices, as well as a very large number of customer devices. 
       FIG. 2  is a block diagram illustrating a payment network system  200 , of which one example is the ACH (automated clearing house) system operated in the United States. The payment network system  200  includes an originator device  202 , for example, a computer operated by an originator of a transaction. Common kinds of transactions handled by the payment network system  200  include credit transactions and debit transactions, wherein the originator  202  is the party that initiates the transaction. The originator may be, for example, an individual or a corporation or other organization or entity. 
     Referring again to  FIG. 2 , the payment network system  200  also includes an originator PSP (payment services provider) computer  204 . The originator PSP computer  204  receives payment instructions from the originator and forwards data entries that reflect the instructions to a payment system switch/network  206 , which is also part of the payment network system  200 . The originator PSP computer  204  may be operated by an originator PSP (which may be, for example, an originating depository financial institution or “ODFI”) of which the originator is a customer. In some embodiments, the switch/network  206  can be operated by a government agency or a private entity that serves as a clearing facility for the system  200 . 
     Also included in the system  200  is a beneficiary PSP computer  208  (which may be, for example, a receiving depository financial institution or “RDFI”). The beneficiary PSP computer  208  receives entries from the payment system switch/network  206  and posts entries to accounts of depositors. 
     Still further, the system  200  includes a beneficiary  210  that is one of the depositors of the beneficiary PSP. In the case of a credit transaction, the account at the beneficiary PSP of the beneficiary may be credited with the amount instructed to be paid by the originator device  202 . The beneficiary may be, for example, an individual or a corporation or other organization. Both the originator and beneficiary PSPs may be banks or other types of financial institutions (FIs). 
     The communications among the parties in the payment network system  200  may typically be conducted using XML (eXtensible Markup Language) and may comply with a standard according to ISO 20022. 
     It should be understood that the components of the system  200  as depicted in  FIG. 2  are only those that are needed for processing a single transaction. However, a typical payment network system  200  may process many transactions (including simultaneous transactions) and therefore may include a considerable number of PSPs and their computers and/or computer networks, one or more clearing operators, and numerous originators and beneficiaries. 
       FIG. 3  is a diagram that illustrates a data communication model  300  that is pertinent to aspects of the present disclosure. The model in question is sometimes referred to as the “OSI model” (i.e., the Open Systems Interconnection model). This model is a conceptual model and is conceived of as having seven abstraction layers. Each layer serves the layer above it and is served by the layer below it. The layers are schematically illustrated in  FIG. 3 , and consist of (from the lowest layer to the highest layer) the Physical Layer  302 , the Data Link Layer  304 , the Network Layer  306 , the Transport Layer  308 , the Session Layer  310 , the Presentation Layer  312  and the Application Layer  314 . A brief conceptual description of each layer now follows. 
     The Physical Layer  302  defines the electrical and physical specifications of the data connection. The definition includes the device-to-physical-transmission medium relationship, where the medium may, for example, be a copper or fiber optic cable or a radio frequency. Pin layout, voltages, line impedance, cable specifications, signal timing and similar characteristics (and frequency for wireless devices) are characteristics defined for the Physical Layer  302 . The Physical Layer handles transmission and reception of unstructured raw data in a physical medium (which may be “over-the-air”). A transmission mode (e.g., simplex, half duplex, full duplex) and a network topology may also be part of the definition of the Physical Layer  302 . 
     The Data Link Layer  304  is concerned with node-to-node data transfer, and defines the link between two directly connected modes. This layer detects (and may correct) errors that may occur in the physical layer. As part of the Data Link Layer  304 , protocols may be defined for establishing and terminating a connection between two physically connected devices, and also for flow control between the devices. The Data Link Layer  304  may consist conceptually of two sublayers (not separately shown), namely the MAC (media access control) layer and the LLC (logical link control) layer. 
     The Network Layer  306  provides functional and procedural arrangements for transferring variable length data sequences from one node to another connected to the same network (where the term network is defined as a medium to which many nodes can be connected, with each node having an address, and permitting each node connected to the network to transfer messages to other connected nodes by providing the message content and the address of the destination node). If a message is too long for transmission via the data link layer, the network may implement delivery by splitting the message into fragments at one node, sending the fragments separately, and reassembling the fragments at another node. 
     The Transport Layer  308  provides functional and procedural arrangements for transferring variable-length data sequences between nodes over one or more networks. One well known example of a transport protocol is “TCP” (Transmission Control Protocol). The Transport Layer  308  manages reliability of a given link via processes such as flow control, segmentation/desegmentation and error control. The Transport Layer  308  also creates packets out of a message received via the Application Layer  314 . In a sense, the Transport Layer  308  engages with messages in terms of one or more “envelopes” for the messages. 
     The Session Layer  310  controls connections between two devices. The Session Layer  310  sets up, maintains and terminates the connections between a local application and a remote application. The Session Layer  310  may allow for full-duplex, half-duplex or simplex operation, and provides functions such as checkpointing, adjournment, termination and restart. 
     The Presentation Layer  312  sets the context between application-layer entities. The latter entities may use different syntaxes and semantics if the Presentation Layer  312  provides mapping between the different syntaxes and semantics. The Presentation Layer  312  may provide translation between application and network formats. Serialization/de-serialization may also be provided at the Presentation Layer  312 . 
     The Application Layer  314  is the layer in the model  300  that is closest to the user. Both the user and the Application Layer  314  interact directly with the software application. Interaction between a software application and the Application Layer  312  occurs when the application implements a communication component. Functions provided by the Application Layer  314  include identifying communication partners, determining resource availability and synchronizing communication. 
       FIG. 4  is a block diagram illustrating a financial transaction system  400  in accordance with some embodiments. A gateway computer  402  is shown operably connected between a payment card network  108  and a payment switch/network  206 . It should be understood, however, that in some embodiments the gateway computer  402  may be a component or components associated with and/or provided by and/or operated by the operator of the payment card network  108 . In some embodiments, the gateway computer  402  may function as a transaction message switching computer. 
     As explained above, the payment card network  108  processes credit and/or debit card payments between an acquirer financial institution (FI)  106  ( FIG. 1 ) and an issuer FI  110 , whereas the payment switch/network  206  processes, for example, include credit and/or debit transactions between originator PSP computer  204  ( FIG. 2 ) and a beneficiary PSP computer  208 . In some embodiments, a consumer utilizes his or her customer device  102  to initiate transactions. The customer device  102  may be, for example, a payment-enabled mobile device, or a personal computer, or browser-equipped mobile device by which the customer may communicate with the merchant device (such as a point of sale (POS) terminal, or a proximity reader associated with a POS terminal, or via a merchant Web page hosted by a merchant server computer). The customer device  102  may also be a plastic payment card in a standard format. The customer device  102 , in whatever form, may have been provisioned/personalized with a token in a standard format for a payment card account number. Subsequent processing/translation of the token in the system  400  will be described below. 
     The system  400  may also include a merchant computer system  404  that, in some embodiments, receives transaction data from the merchant device  104  and performs processing according to one or more transaction flows as described below. 
     The system  400  may also include an acquirer/originator PSP  406  in communication with the merchant system  404  and the gateway computer  402 . The acquirer/originator PSP (O-PSP) computer  406  may perform processing according to one or more transaction flows as described below. In  FIG. 4 , the acquirer/originator PSP (O-PSP) computer  406  may implement functions of the above-mentioned acquirer FI  106  and/or the originator PSP computer  204 . 
     In some use cases and/or transaction flows, a digital wallet provider  408  may be involved in the transaction flow and may be in communication with the merchant system  404 . In such use cases, the digital wallet provider  408  may perform processing as described below. The digital wallet provider may, by previous arrangement, have undertaken to store a digital wallet for the customer. 
     As mentioned above, in some embodiments the gateway computer  402  is configured to bridge the payment switch/network  206  and the payment card network  108  at the presentation layer level and/or the application layer level. In some implementations the gateway computer  402  is also configured to assist in the migration speed by which entities switch to modern common standards (such as ISO 20022) while at the same time support backward compatibility to participants in any particular payment network. In addition, the gateway computer  402  may be configured for providing network operators and/or network participants to apply the protocol that best suits their system&#39;s optimal performance level(s). Thus, the gateway computer  402  serves as a central switching platform that is the seat of the network&#39;s operations, and works independently of the chosen protocol of the network participants. 
     Thus, the financial transaction system  400  allows a customer to pay a merchant for goods or services by various means, such as via a payment card account or via a value transfer from one or more of the customer&#39;s financial accounts (for example, a checking account) to a merchant&#39;s account. 
       FIG. 5  is a block diagram of an example gateway computer system  500  that may perform functions in the system of  FIG. 4 . Although the gateway computer system  500  is depicted as a stand-alone component, some or all of the functions ascribed to it may be performed by a computer system network and/or other components operated by, or associated with, the payment switch/network  206  and/or the payment card network  108 . 
     Referring again to  FIG. 5 , the gateway computer system  500  may, in its hardware aspects, resemble a typical server computer and/or mainframe computer, but may be controlled by software to cause it to function as described herein. In addition, the gateway computer system  500  may be designed as a special purpose computer, and thus specially configured to perform the functions described herein. 
     The gateway computer system  500  may include one or more gateway processor(s)  502  operatively coupled to a communication device  501 , a storage device  504 , an input device  506  and an output device  508 . The communications device  501 , the storage device  504 , the input device  506  and the output device  508  may all be in communication with and/or operably connected to the gateway processor(s)  502 . The gateway processor(s)  502  operate to execute processor-executable steps, contained in program instructions described below, so as to control the gateway computer system  500  to provide desired functionality. 
     Communication device  501  may be used to facilitate communication with, for example, other devices (such as other components of the system  400 , as well as user mobile devices and/or other computing devices). Communication device  501  may comprise numerous communication ports (not separately shown), to allow the gateway computer system  500  to communicate simultaneously with a number of other computers and/or other devices, including communications as required to simultaneously handle numerous interactions with other devices which may be associated with numerous transactions, and to simultaneously handle numerous translations of transactions during processing. 
     Input device  506  may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, the input device  506  may include a keyboard and a mouse. Output device  508  may comprise, for example, a display and/or an audio speaker, and/or a printer. 
     Storage device  504  may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as flash memory and the like. Any one or more of such information storage devices may be considered to be a non-transitory computer-readable storage medium or a computer usable medium or a memory. 
     Storage device  504  stores one or more programs for controlling the gateway processor(s)  502 . The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the gateway computer system  500 , executed by the gateway processor(s)  502  to cause the gateway computer system  500  (and/or other computer systems) to function as described herein. 
     The programs may include one or more conventional operating systems (not shown) that control the gateway processor(s)  502  so as to manage and coordinate activities and sharing of resources in the gateway computer system  500 , and to serve as a host for application programs (described below) that run on the gateway computer system  500 . 
     The programs stored in the storage device  504  may include, for example, a presentation layer translation module  510  which operates to convert various network messages at the presentation layer. The presentation layer translation module  510  may be configured for converting XML, ASN.1 (which may include BER, CER, DER, XER, CXER, E-XER, PER and GSER encoding rules), ISO 8583 encoding rules, FTP, and/or SMTP. 
     Another program that may be stored in the storage device  504  is an application layer translation module  512  for causing the gateway processor(s)  502  to convert between various network messages at the level of the application layer. The application layer translation module  512  may be configured for converting ISO 8583 (which standard is commonly used by card networks), ISO 20022, and ISO 9362. 
     The storage device  504  may also store a data dictionary module  514  for mapping all the business fields and their locations between the various protocols. This module  514  may also include encryption services configured to cause the gateway processor(s)  502  to encrypt and to decrypt sensitive data before and after translation, respectively, to ensure message component confidentiality (for example, to ensure the confidentiality associated with a PIN block in a card message). 
     The storage device  504  may further store one or more device interface modules  516  that serve as software interfaces between the gateway computer system  500  and one or more other components, for example, as depicted in the system  400  of  FIG. 4 . 
     The storage device  504  may also store, and the gateway processor(s)  502  may also execute, other programs, which are not shown. For example, such programs may include communications software and one or more reporting applications. The latter program(s) may respond to requests from system administrators, for example, for reports on the activities performed by the gateway computer system  500 . The other programs may also include, for example, device drivers, database management software, and the like. 
     The storage device  504  may also store one or more databases  518  that may be required for operation of the gateway computer system  500 . 
     It should be understood that other computerized components of the system  400  may be constituted by computer hardware having the same type of components and/or hardware architecture as described herein with reference to  FIG. 5 . 
       FIG. 6  is a flow chart  600  that illustrates an overview of various transaction processes that may be performed in the system of  FIG. 4  in accordance with aspects of the present disclosure. In particular, the process of  FIG. 6  relates to various types of payment transactions between customers and merchants, the details of which are described below. 
     At  602  in  FIG. 6  an interaction occurs between the customer device  102  and the merchant device  104  (See  FIG. 4 ) to launch a transaction in which, for example, the customer may purchase an item and the merchant may be compensated by EFT from the customer&#39;s deposit account. For example, a token or account number may be read/received from the customer device  102  by the merchant device  104 . The latter may also calculate a transaction amount. 
     Block  604  in  FIG. 6  represents processing that may occur in or by the merchant system  404  in connection with a transaction flow. 
     Block  606  in  FIG. 6  represents processing that may occur by the digital wallet provider  408  ( FIG. 4 ), in a use case in which the digital wallet provider is involved in the transaction flow. For example, customer payment credentials such as a payment token or an account number may be provided by the digital wallet provider  408 , rather than such credentials being read/received during the interaction between the customer device  102  and the merchant device  104  at  602 . 
     Block  608  in  FIG. 6  represents processing that may occur by the acquirer/originator PSP (acquirer/O-PSP)  406  computer in connection with a transaction flow. The processing at block  608  may include the acquirer/originator PSP  406  receiving and retransmitting a transaction request message (e.g., by routing the message to the gateway computer  402 ). 
     Block  610  in  FIG. 6  represents processing that may occur by the gateway computer  402  in connection with a transaction flow. As discussed below in connection with further flow charts, the processing at  610  may involve message translation services and/or application of business rules to select between the payment card network  108  and the payment/switch network  206  for further routing of the transaction. 
     Described below are several transaction flow examples that may be use cases of the process generally illustrated in  FIG. 6  with respect to payment from a customer to a merchant via an EFT network. It should be understood, however, that the financial transaction system  400  is also configured for accepting payment card account payments from customers to merchants. 
     According to one alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via a merchant system  404 . Prior to transmitting the request, the merchant system may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider (not shown). The merchant system  404  may transmit the request to an acquirer/originator PSP computer  406  which evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The acquirer/originator PSP computer  406  then may build the transaction request message and submit it to the gateway computer  402 . The gateway computer  402  is configured to convert between various network message types at the presentation layer, and can convert between various network messages at the level of the application layer. In some embodiments, the gateway computer determines that the flow should next proceed to the payment/switch network (EFT network), and thus processes the transaction request as necessary and transmits it to the payment/switch network which determines the routing path and routes to the beneficiary PSP (B-PSP) computer  208 . The B-PSP computer evaluates the messages, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP computer returns a response message to the acquirer/O-PSP computer  406  via the payment/switch network (EFT network) and the gateway computer  402 . The acquirer/O-PSP returns the response to the merchant system and/or merchant device (which may be, for example, a card acceptance terminal). 
     According to another alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via the merchant system  404 . The merchant system builds and submits the transaction request message to the merchant acquirer. Prior to transmitting the request, the merchant system may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider (not shown). The merchant system  404  may transmit the request to an acquirer/originator PCP computer  406  which evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The acquirer/originator PSP computer  406  then may build the transaction request message and submit it to the gateway computer  402 , which routes the message to the payment/switch network (EFT network)  206  for processing. The payment/switch network determines the routing path and routes the message to the B-PSP computer  208 . The B-PSP computer evaluates the message, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP computer then returns a response message to the acquirer/O-PSP  406  via the payment/switch network (EFT network) and gateway computer. The acquirer/O-PSP then returns the response to the merchant system and/or merchant card acceptance terminal. 
     According to still another alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via a merchant system. The merchant system builds and submits the transaction request message to the merchant acquirer/originator PSP computer, which may evaluate the payment credentials in the message before transmitting it to the gateway computer  402 . The gateway computer may determine that the transaction should be routed to the payment/switch network (EFT network). The payment/switch network may evaluate the message and evaluate the payment credentials in the message, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. Further, the payment/switch network may determine the O-PSP and transmit the message to the O-PSP computer. The O-PSP computer may evaluate the message and authenticate the consumer credentials and debit the originator/consumer account. Also, the O-PSP computer may return the response to the payment/switch network, which determines the routing path and routes the message to the B-PSP computer. The B-PSP computer evaluates the message, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP computer returns a response message to the O-PSP computer via the payment network (EFT network) and the gateway computer. The O-PSP computer returns the response to the merchant system and/or merchant card acceptance terminal. 
     The card acceptance interface for a remote transaction (such as an in-app transaction or an online transaction) may be a browser or mobile application utilizing manual entry of the token or other transaction information or the token may be supplied via a digital wallet. In such remote transactions, the user may provide payment credentials and other transaction-related information (name, billing address, shipping address, etc.) to complete the transaction either during the checkout process or with the information having been stored during enrollment (e.g., via a digital wallet). 
     When the user engages in checkout from such an interface using a deposit account as the underlying source of funds, any one of the above alternative transaction flows may occur in various use cases. As another alternative, the following further alternative flow may take place. 
     Via the merchant device a digital wallet acceptance interface may be invoked, with user/customer authentication or with the customer pre-authenticated. The digital wallet provider may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. The digital wallet provider determines the O-PSP computer and builds and submits a transaction request message to the O-PSP computer. The O-PSP computer evaluates the message and authenticates the consumer credentials and then forwards the message to the payment network (EFT network). The payment network determines the routing path and routes the message to the B-PSP computer. The B-PSP computer evaluates the message, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP computer returns a response message to the O-PSP computer via the payment/switch network (EFT network). The O-PSP computer returns the response message to the merchant via the payment network and via the digital wallet provider. The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message. 
     There may be intermediate steps in the above described flow(s), where the digital wallet provider may act as B-PSP computer for the funding leg of the transaction, with the consumer originator account being debited and a B-PSP account (which can be a pooled account) of the digital wallet provider posted and credited. In the payment leg of the transaction, the digital wallet provider may act as O-PSP computer of the transaction where the digital wallet provider account is debited and the B-PSP account of the beneficiary will be posted and credited. 
     In some embodiments, the payment credentials may be a bank account number and bank routing information (IBAN, IFSC code, SWIFT code, etc.) and/or card number (credit, debit, prepaid, commercial, or a push card instrument tied to a deposit account). Mapping of tokens and payment credentials may allow for the merchant only to see the token and not the real payment credentials. 
     Accordingly, in some embodiments the gateway computer  402  is configured to convert between various network messages at the presentation layer, including the likes of (but not limited to) XML, ASN.1 (which may include BER, CER, DER, XER, CXER, E-XER, PER and GSER encoding rules), ISO 8583 encoding rules, FTP, and/or SMTP. In some implementations, the gateway computer  402  is also configured to convert between various network messages at the level of the application layer, including the likes of (but not limited to) ISO 8583 (which standard is commonly used by card networks), ISO 20022, and ISO 9362. Moreover, the gateway computer  402  may include a data dictionary that maps all the business fields and their locations between the various protocols, and may include encryption services to encrypt and to decrypt sensitive data before and after translation, respectively, to ensure message component confidentiality (for example, to ensure the confidentiality associated with a PIN block in a card message). The gateway computer  402  is also, in some embodiments, configured to employ digital signature management to maintain message integrity across the translation service so that it can be established that any given message originated from a trusted source. 
     Accordingly, use of the gateway computer  402  as described herein provides a quick and seamless way for any participant in one network to participate in another network with minimal or no network modifications necessary. The gateway computer  402  is thus configured to manage these operations and/or functionality. The application(s) described herein thus allow for network switches and/or network participants to migrate to a more current protocol while the rest of the network infrastructure can work through a system wide migration effort. 
     It should be understood that, for ease of understanding, a minimal number of components are shown in the financial transaction system  400  of  FIG. 4 . However, a practical embodiment of a financial transaction system  400  may process many transactions (including simultaneous transactions) and therefore may include a multiplicity of gateway computers  402 , which can include two or more computers and/or computer networks, one or more payment card networks  108 , numerous acquirer FI computers  106  and numerous issuer FI computers  110 , one or more payment switch/network computers  206 , and numerous originator PSPs  204  and beneficiary PSPs  208 . In addition, numerous customer devices  102  and merchant devices  104  may be involved. 
       FIG. 7  is a flow chart that illustrates another process that may be performed in the system  400  according to aspects of this disclosure. In particular,  FIG. 7  illustrates processing that may occur (or primarily occur) in the gateway computer  402 . 
     At  702 , the gateway computer may receive a transaction request message. For present purposes it is assumed that the transaction request message includes a token that represents the customer&#39;s deposit bank account. The token may be in a standard format for payment card account numbers as that format is defined in a payment card account system. The format may be sixteen decimal digits, for example. The token may be taken as an addressing indicator in that it can be processed so as to indicate the account from which the requested transaction is to be funded. The received transaction request message may also be generally in a format for transaction messaging in a payment card account system. 
     Detokenization may then occur, either directly within the gateway computer  402  (by reference to a token directory, which is not shown) or indirectly by reference to a Token Service Provider (not shown). In either case, the token may be translated (block  704 ,  FIG. 7 ) to a bank account number that identifies the customer&#39;s bank deposit account. The bank account number may be in a format used in an EFT/ACH system, and may be in a format that is different from the format of the token received at  702 . The bank account number is suitable for being used as an addressing indicator in the EFT/ACH system to identify the funding account for the transaction. The bank account number may be in the IBAN (International Bank Account Number) format. 
     At  706 , the gateway computer  402  may generate a transaction request message that is suitable for routing in the EFT/ACH system. The transaction request message generated at  706  may be in a different format from the transaction request message received at  702 . With the generation of the transaction request message at  706 , the gateway computer  402  effectively provides a bridging function between the payment card account system and the EFT/ACH system. The transaction request message generated at  706  may include the customer&#39;s bank deposit account number obtained during the translation at  704 . 
     At  708 , the gateway computer  402  may transmit the transaction request message generated at  706  to the EFT/ACH system, to continue performing the function of bridging the payment card account system and the EFT/ACH system. It will be appreciated that the transaction funding may be completed in the EFT/ACH system based on the transaction request message transmitted at  708 . 
       FIG. 8  is a flow chart that illustrates another process that may be performed in the system  400  of  FIG. 4  according to aspects of the present disclosure. The processing illustrated in  FIG. 8  may be performed by the gateway computer  402 . 
     At  802  in  FIG. 8 , the gateway computer  402  may convert a transaction request message at the presentation layer. The conversion may convert the message from a programming language used for payment card account transaction messages to a programming language used in EFT transaction messages. 
     At  804 , the gateway computer may convert the transaction message at an application layer. This conversion may convert the transaction message between a standard message format used in payment card account transaction messages to a different standard message format used in EFT/ACH transaction messages. 
     At  806 , and possibly in aid of processing at  804 , the gateway computer  402  may refer to the data dictionary  514  ( FIG. 5 ) to map one or more business fields from the payment card transaction message format to the EFT/ACH transaction message format. 
     At  808  in  FIG. 8 , and possibly in aid of processing at  802 ,  804  and/or  806 , the gateway computer  402  may decrypt and then encrypt at least some data elements from the payment card account transaction message. The data element(s) decrypted and encrypted may, for example include a PIN (personal identification number) block. 
     At  810 , the gateway computer  402  may manage and utilize one or more digital signatures to provide for the converted transaction message to be subject to authentication in the EFT/ACH system. 
     In a practical embodiment of the system  400 , the gateway computer  402  may perform the process of  FIG. 8  with respect to each one of a large number of payment card account transaction messages that may be received for conversion by the gateway computer  402 . 
       FIG. 9  is a flow chart that illustrates another process that may be performed in the system  400  of  FIG. 4  according to aspects of the present disclosure. 
     At  902  in  FIG. 9 , and in a set-up, configuration or re-configuration mode for the gateway computer  402 , one or more business rules may be stored in the gateway computer  402 . As will be seen, the business rule(s) may guide the gateway computer  402  in selecting between the payment card account system and the EFT system for further routing of transaction messages received by the gateway computer  402 . The application of the business rules may allow the routing decisions of the gateway computer  402  to achieve certain business goals, including for example business goals of account issuers, merchants and/or system operators. 
     After the set-up/configuration/re-configuration mode is completed, and thus after a lapse of time indicated at  904 , the gateway computer  402  may receive a transaction message as indicated at  906 . It is assumed that the transaction message includes a token that is translatable into either one of a PAN (payment card account system account number) or a bank deposit account number (suitable for executing an EFT system transaction). Thus the token can be translated so as to represent either one of two different funding accounts, one accessible via a payment card account system and the other accessible via an EFT system. 
     At  908  in  FIG. 9 , the gateway computer  402  may apply one or more of the business rules stored at  902  to arrive at a routing decision to select between the two potential funding accounts, and thus to select between routing in the payment card account system or alternatively in the EFT system. In applying the business rule(s) to the transaction message received at  906 , the gateway computer may consider content of the transaction message, such as the BIN range of the token, the transaction amount, the merchant identifier or merchant category code, etc. In some embodiments, the business rule(s) may guide the gateway computer to select between a routing decision outcome that will result in a lower transaction handling fee for the merchant versus a routing decision outcome that will result in more timely completion of the transaction at the time of sale. For example, certain merchants may have indicated that they prefer that latter outcome to the former, or vice versa. Accordingly, business rules may be in place for merchants that have expressed such a preference to make a routing decision based on the merchant identifier in the received transaction message, along with the known speed of completion or known fee structure of the payment card account system versus the EFT system. 
     A decision block  910  may follow block  908  in the process of  FIG. 9 . At decision block  910  the gateway computer  402  makes a routing decision between the payment card system and the EFT system. That is, the gateway computer  402  selects between the payment card system and the EFT system for further routing of the transaction. It will be appreciated that the determination is based on one or more business rules and content of the transaction message received at  906 . 
     If the gateway computer  402  selects the payment card account system at decision block  910 , then block  912  may follow decision block  910 . At block  912 , the gateway computer  402  routes the transaction for completion via the payment card account system. In doing so, the gateway computer  402  may transmit a transaction message that includes a PAN into which the token has been translated. 
     If the gateway computer  402  selects the EFT system at decision block  910 , then block  914  may follow decision block  910 . At block  914 , the gateway computer  402  routes the transaction for completion via the EFT system. In doing so, the gateway computer may transmit a transaction message that includes a bank deposit account number into which the token has been translated. It may be the case that other aspects of message conversion may have occurred also in this instance, e.g., as described above in connection with  FIG. 8 . 
     In some embodiments, steps  908  et seq. may only be applied to transaction messages which contain tokens that are mapped to both a payment card account number and a deposit bank account number, such that translation to one or the other of the two account numbers is to be selected as part of the translation process. In some embodiments, the token may have a BIN (bank identification number) portion that is from a BIN or BIN range that indicates the token is mapped to both types of account numbers. Accordingly, in such embodiments, the gateway computer  402  may determine whether to proceed from step  906  to steps  908  et seq. based on the BIN portion of the token. 
     Some more specific examples will now be provided. These examples assume that the customer presents a token to the merchant, such that the token is translatable either into a PAN (for routing in the payment card account system) or a bank deposit account number (for routing in the EFT system). 
     For the first example, it is assumed that the merchant identifier (merchant ID) in the transaction message identifies a merchant for which a business rule is stored. It is further assumed that the business rule calls for routing transactions for the merchant via the faster alternative, so as to minimize transaction execution time at the merchant&#39;s point of sale. Still a further assumption is that the gateway computer  402  has access to data that indicates either current or prevailing conditions in the payment card account system and the EFT system, from which data the gateway computer  402  is able to determine which system provides faster transaction completion. Based on that data, the gateway computer  402  may select the faster of the two systems for routing the transaction. 
     In another example, it is again assumed that the merchant ID in the transaction message identifies a merchant for which a business rule is stored. In this current example, it is further assumed that the business rule in question calls for routing transactions for the merchant so as to minimize transaction fees. A further assumption is that the gateway computer  402  has access to data relating to the respective transaction fee arrangements applicable to the merchant for the two available routing alternatives. Based on that data and the business rule, the gateway computer  402  is able to determine which system is associated with a lower fee to the merchant for handling the current transaction. The gateway computer  402  may then route the transaction accordingly, by selecting the one of the two systems that provides the lower transaction cost for the merchant. 
     In some embodiments, transaction messaging referred to herein is performed in real time, or near-real time. In other embodiments, at least some messages are transferred in batch processes, such as daily delivery of batches of messages for posting transactions to accounts. 
     In some embodiments, the gateway computer  402  is embodied as an intelligent edge device. In other embodiments, the functional intelligence ascribed herein to the gateway computer  402  may reside elsewhere in the system  400 , and the topological location in the system depicted as occupied by the gateway computer  402  may alternatively be occupied by a conventional or near-conventional router. 
     In some embodiments, or in some situations, when the gateway computer  402  routes a transaction to the EFT system it does so via the payment/switch network  206 . However, in other embodiments, or in other situations, it does so via the consumer&#39;s bank (i.e., via the B-PSP computer  208 ). 
     The use of business rules for guiding routing decisions may provide improved flexibility and increased stakeholder options in a financial transaction system. 
     The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including the omission of one or more steps and/or the simultaneous performance of at least some steps. 
     As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other. 
     As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other. 
     Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations would be apparent to those skilled in the art and can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.