SYSTEMS AND METHODS FOR BRIDGING TRANSACTIONS BETWEEN EFT PAYMENT NETWORKS AND PAYMENT CARD NETWORKS

Abstract

A method of operating a payment network bridging computer includes receiving a first transaction request message in the payment network bridging computer. The first transaction request message includes a first addressing indicator that represents a funding account. The first addressing indicator is of a type used in a payment card account system. The method also includes translating the first addressing indicator to a second addressing indicator. The second addressing indicator being of a type used in an EFT system. The method further includes transmitting a second transaction request message from the payment network bridging computer. The second transaction request message includes the second addressing indicator. The second addressing indicator represents the funding account.

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); the contents of which provisional applications 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'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' 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'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's optimal performance level(s). Thus, the gateway computer 402 serves as a central switching platform that is the seat of the network'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's financial accounts (for example, a checking account) to a merchant'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'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'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'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 MAN (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'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'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'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.

Claims

1. A method of operating a payment network bridging computer, the method comprising:

receiving, in the payment network bridging computer, a first transaction request message, the first transaction request message including a first addressing indicator that represents a funding account, the first addressing indicator being of a first type used in a payment card account system;

translating the first addressing indicator to a second addressing indicator, the second addressing indicator being of a second type used in an EFT (electronic funds transfer) system, the second type in a different format from the first type; and

transmitting, from the payment network bridging computer, a second transaction request message, the second transaction request message including the second addressing indicator, the second addressing indicator representing the funding account.

2. The method of claim 1, wherein the second transaction request message is transmitted by the payment network bridging computer to the EFT system.

3. The method of claim 2, wherein the first transaction request message is received by the payment network bridging computer from the payment card account system.

4. The method of claim 3, wherein the first addressing indicator is in a format defined for payment card account numbers.

5. The method of claim 4, wherein the second addressing indicator is a bank deposit account number.

6. The method of claim 5, wherein the funding account is a bank deposit account owned by the account holder.

7. The method of claim 6, wherein the first and second transaction request messages relate to a purchase transaction initiated by the account holder at a merchant's point of sale.

8. The method of claim 7, wherein the first addressing indicator is a payment token that was provisioned to the account holder.

9. The method of claim 8, wherein the payment token was provisioned in digital form to a mobile device owned by the account holder.

10. The method of claim 8, wherein the payment token was provisioned to the account holder on a plastic payment card.

11. The method of claim 1, wherein the EFT system is an ACH (automated clearing house) system.

12. A method of bridging transactions between a payment card account network and an EFT (electronic funds transfer) network, the method comprising:

converting transaction messages at a presentation layer from a programming language used for payment card account transaction messages to a programming language used in EFT transaction messages;

converting the transaction messages at an application layer between a first standard message format used in payment card account transaction messages to a second standard message format used in EFT transaction messages;

referring to a data dictionary to map business fields from the first standard message format to the second standard message format;

decrypting and encrypting at least some data elements during conversion of the transaction messages; and

managing digital signatures to authenticate converted transaction messages.

13. The method of claim 12, wherein the decrypted and encrypted at least some data elements include PIN (personal identification number) blocks in the payment card account transaction messages.

14. The method of claim 12, wherein the converting steps, the step of referring to the data dictionary, the decrypting and encrypting step and the step of managing digital signatures are all performed at a gateway computer that is in communication with the payment card account network and the EFT network.

15. The method of claim 14, wherein the EFT network is an ACH (automated clearing house) network.

16. A method of operating a transaction message switching computer, the transaction message switching computer in communication with a payment card account system and an EFT (electronic funds transfer) system, the method comprising:

storing at least one business rule in the transaction message switching computer;

receiving a transaction request message;

based on (a) content of the received transaction request message and (b) said stored at least one business rule, selecting one of the payment card account system and the EFT system; and

routing the transaction request message to the selected one of the payment card account system and the EFT system.

17. The method of claim 16, wherein the EFT system is an ACH (automated clearing house) system.

18. The method of claim 16, wherein the received transaction request message includes a payment token.

19. The method of claim 18, further comprising:

translating the payment token into one of a deposit bank account number and a payment card account number in accordance with a result of the selecting step.

20. The method of claim 18, wherein the payment token is in a format defined for payment card account numbers in the payment card account system.