US20170364878A1 - Systems and methods for bridging transactions between eft payment networks and payment card networks - Google Patents

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 ofFIG. 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 ofFIG. 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 apayment card system100. Thepayment card system100 includes acustomer device102 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), amerchant device104, an acquirer financial institution (FI)computer106, acard network108, and anissuer FI computer110.
• Themerchant device104 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 paymentcard account system100. Thecustomer device102 may be presented to themerchant device104 to consummate a purchase transaction and to permit themerchant device104 to read payment card account data (including, for example, a payment account number) from thecustomer device102. In other situations, themerchant device104 may be an e-commerce server computer, and thecustomer device102 may be a personal computer or a mobile device running mobile browser software or the like. In this case, thecustomer device102 may engage in an online shopping session with an e-commerce website hosted by themerchant device104.
• During a purchase transaction, theacquirer FI computer106 may receive a payment account system authorization request message for the transaction from themerchant device104. Theacquirer FI computer106 may then route the authorization request message via acard network108 to anissuer FI computer110, which is operated by the issuer of a payment account that is associated with the account number obtained by the merchant device104 (e.g., from the customer device102) and included in the authorization request message. In some implementations, the authorization response message generated by the paymentissuer server computer110 is routed back to themerchant device104 via thecard network108 and theacquirer FI computer106.
• 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 toFIG. 1, the payment account issuer FIcomputer110 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 thecustomer device102 referred to above). For example, the payment card issuer FIcomputer110 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 thesystem100 ofFIG. 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 apayment network system200, of which one example is the ACH (automated clearing house) system operated in the United States. Thepayment network system200 includes anoriginator device202, for example, a computer operated by an originator of a transaction. Common kinds of transactions handled by thepayment network system200 include credit transactions and debit transactions, wherein theoriginator202 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 toFIG. 2, thepayment network system200 also includes an originator PSP (payment services provider)computer204. Theoriginator PSP computer204 receives payment instructions from the originator and forwards data entries that reflect the instructions to a payment system switch/network206, which is also part of thepayment network system200. Theoriginator PSP computer204 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/network206 can be operated by a government agency or a private entity that serves as a clearing facility for thesystem200.
• Also included in thesystem200 is a beneficiary PSP computer208 (which may be, for example, a receiving depository financial institution or “RDFI”). Thebeneficiary PSP computer208 receives entries from the payment system switch/network206 and posts entries to accounts of depositors.
• Still further, thesystem200 includes abeneficiary210 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 theoriginator device202. 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 thepayment network system200 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 thesystem200 as depicted inFIG. 2 are only those that are needed for processing a single transaction. However, a typicalpayment network system200 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 adata communication model300 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 inFIG. 3, and consist of (from the lowest layer to the highest layer) thePhysical Layer302, theData Link Layer304, theNetwork Layer306, theTransport Layer308, theSession Layer310, thePresentation Layer312 and theApplication Layer314. A brief conceptual description of each layer now follows.
• ThePhysical Layer302 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 thePhysical Layer302. 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 thePhysical Layer302.
• TheData Link Layer304 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 theData Link Layer304, protocols may be defined for establishing and terminating a connection between two physically connected devices, and also for flow control between the devices. TheData Link Layer304 may consist conceptually of two sublayers (not separately shown), namely the MAC (media access control) layer and the LLC (logical link control) layer.
• TheNetwork Layer306 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.
• TheTransport Layer308 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). TheTransport Layer308 manages reliability of a given link via processes such as flow control, segmentation/desegmentation and error control. TheTransport Layer308 also creates packets out of a message received via theApplication Layer314. In a sense, theTransport Layer308 engages with messages in terms of one or more “envelopes” for the messages.
• TheSession Layer310 controls connections between two devices. TheSession Layer310 sets up, maintains and terminates the connections between a local application and a remote application. TheSession Layer310 may allow for full-duplex, half-duplex or simplex operation, and provides functions such as checkpointing, adjournment, termination and restart.
• ThePresentation Layer312 sets the context between application-layer entities. The latter entities may use different syntaxes and semantics if thePresentation Layer312 provides mapping between the different syntaxes and semantics. ThePresentation Layer312 may provide translation between application and network formats. Serialization/de-serialization may also be provided at thePresentation Layer312.
• TheApplication Layer314 is the layer in themodel300 that is closest to the user. Both the user and theApplication Layer314 interact directly with the software application. Interaction between a software application and theApplication Layer312 occurs when the application implements a communication component. Functions provided by theApplication Layer314 include identifying communication partners, determining resource availability and synchronizing communication.
• FIG. 4 is a block diagram illustrating afinancial transaction system400 in accordance with some embodiments. Agateway computer402 is shown operably connected between apayment card network108 and a payment switch/network206. It should be understood, however, that in some embodiments thegateway computer402 may be a component or components associated with and/or provided by and/or operated by the operator of thepayment card network108. In some embodiments, thegateway computer402 may function as a transaction message switching computer.
• As explained above, thepayment card network108 processes credit and/or debit card payments between an acquirer financial institution (FI)106 (FIG. 1) and anissuer FI110, whereas the payment switch/network206 processes, for example, include credit and/or debit transactions between originator PSP computer204 (FIG. 2) and abeneficiary PSP computer208. In some embodiments, a consumer utilizes his or hercustomer device102 to initiate transactions. Thecustomer device102 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). Thecustomer device102 may also be a plastic payment card in a standard format. Thecustomer device102, 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 thesystem400 will be described below.
• Thesystem400 may also include amerchant computer system404 that, in some embodiments, receives transaction data from themerchant device104 and performs processing according to one or more transaction flows as described below.
• Thesystem400 may also include an acquirer/originator PSP406 in communication with themerchant system404 and thegateway computer402. The acquirer/originator PSP (O-PSP)computer406 may perform processing according to one or more transaction flows as described below. InFIG. 4, the acquirer/originator PSP (O-PSP)computer406 may implement functions of the above-mentionedacquirer FI106 and/or theoriginator PSP computer204.
• In some use cases and/or transaction flows, adigital wallet provider408 may be involved in the transaction flow and may be in communication with themerchant system404. In such use cases, thedigital wallet provider408 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 thegateway computer402 is configured to bridge the payment switch/network206 and thepayment card network108 at the presentation layer level and/or the application layer level. In some implementations thegateway computer402 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, thegateway computer402 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, thegateway computer402 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, thefinancial transaction system400 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 examplegateway computer system500 that may perform functions in the system ofFIG. 4. Although thegateway computer system500 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/network206 and/or thepayment card network108.
• Referring again toFIG. 5, thegateway computer system500 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, thegateway computer system500 may be designed as a special purpose computer, and thus specially configured to perform the functions described herein.
• Thegateway computer system500 may include one or more gateway processor(s)502 operatively coupled to acommunication device501, astorage device504, aninput device506 and anoutput device508. Thecommunications device501, thestorage device504, theinput device506 and theoutput device508 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 thegateway computer system500 to provide desired functionality.
• Communication device501 may be used to facilitate communication with, for example, other devices (such as other components of thesystem400, as well as user mobile devices and/or other computing devices).Communication device501 may comprise numerous communication ports (not separately shown), to allow thegateway computer system500 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 device506 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, theinput device506 may include a keyboard and a mouse.Output device508 may comprise, for example, a display and/or an audio speaker, and/or a printer.
• Storage device504 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 device504 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 thegateway computer system500, executed by the gateway processor(s)502 to cause the gateway computer system500 (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 thegateway computer system500, and to serve as a host for application programs (described below) that run on thegateway computer system500.
• The programs stored in thestorage device504 may include, for example, a presentationlayer translation module510 which operates to convert various network messages at the presentation layer. The presentationlayer translation module510 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 thestorage device504 is an applicationlayer translation module512 for causing the gateway processor(s)502 to convert between various network messages at the level of the application layer. The applicationlayer translation module512 may be configured for converting ISO 8583 (which standard is commonly used by card networks), ISO 20022, and ISO 9362.
• Thestorage device504 may also store adata dictionary module514 for mapping all the business fields and their locations between the various protocols. Thismodule514 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).
• Thestorage device504 may further store one or moredevice interface modules516 that serve as software interfaces between thegateway computer system500 and one or more other components, for example, as depicted in thesystem400 ofFIG. 4.
• Thestorage device504 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 thegateway computer system500. The other programs may also include, for example, device drivers, database management software, and the like.
• Thestorage device504 may also store one ormore databases518 that may be required for operation of thegateway computer system500.
• It should be understood that other computerized components of thesystem400 may be constituted by computer hardware having the same type of components and/or hardware architecture as described herein with reference toFIG. 5.
• FIG. 6 is aflow chart600 that illustrates an overview of various transaction processes that may be performed in the system ofFIG. 4 in accordance with aspects of the present disclosure. In particular, the process ofFIG. 6 relates to various types of payment transactions between customers and merchants, the details of which are described below.
• At602 inFIG. 6 an interaction occurs between thecustomer device102 and the merchant device104 (SeeFIG. 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 thecustomer device102 by themerchant device104. The latter may also calculate a transaction amount.
• Block604 inFIG. 6 represents processing that may occur in or by themerchant system404 in connection with a transaction flow.
• Block606 inFIG. 6 represents processing that may occur by the digital wallet provider408 (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 thedigital wallet provider408, rather than such credentials being read/received during the interaction between thecustomer device102 and themerchant device104 at602.
• Block608 inFIG. 6 represents processing that may occur by the acquirer/originator PSP (acquirer/O-PSP)406 computer in connection with a transaction flow. The processing atblock608 may include the acquirer/originator PSP406 receiving and retransmitting a transaction request message (e.g., by routing the message to the gateway computer402).
• Block610 inFIG. 6 represents processing that may occur by thegateway computer402 in connection with a transaction flow. As discussed below in connection with further flow charts, the processing at610 may involve message translation services and/or application of business rules to select between thepayment card network108 and the payment/switch network206 for further routing of the transaction.
• Described below are several transaction flow examples that may be use cases of the process generally illustrated inFIG. 6 with respect to payment from a customer to a merchant via an EFT network. It should be understood, however, that thefinancial transaction system400 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 amerchant system404. 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). Themerchant system404 may transmit the request to an acquirer/originator PSP computer406 which evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The acquirer/originator PSP computer406 then may build the transaction request message and submit it to thegateway computer402. Thegateway computer402 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)computer208. 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 computer406 via the payment/switch network (EFT network) and thegateway computer402. 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 themerchant system404. 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). Themerchant system404 may transmit the request to an acquirer/originator PCP computer406 which evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The acquirer/originator PSP computer406 then may build the transaction request message and submit it to thegateway computer402, 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 computer208. 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-PSP406 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 thegateway computer402. 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 thegateway computer402 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, thegateway computer402 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, thegateway computer402 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). Thegateway computer402 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 thegateway computer402 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. Thegateway computer402 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 thefinancial transaction system400 ofFIG. 4. However, a practical embodiment of afinancial transaction system400 may process many transactions (including simultaneous transactions) and therefore may include a multiplicity ofgateway computers402, which can include two or more computers and/or computer networks, one or morepayment card networks108, numerousacquirer FI computers106 and numerousissuer FI computers110, one or more payment switch/network computers206, andnumerous originator PSPs204 andbeneficiary PSPs208. In addition,numerous customer devices102 andmerchant devices104 may be involved.
• FIG. 7 is a flow chart that illustrates another process that may be performed in thesystem400 according to aspects of this disclosure. In particular,FIG. 7 illustrates processing that may occur (or primarily occur) in thegateway computer402.
• At702, 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 computer402 (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 (block704,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 at702. 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.
• At706, thegateway computer402 may generate a transaction request message that is suitable for routing in the EFT/ACH system. The transaction request message generated at706 may be in a different format from the transaction request message received at702. With the generation of the transaction request message at706, thegateway computer402 effectively provides a bridging function between the payment card account system and the EFT/ACH system. The transaction request message generated at706 may include the customer's bank deposit account number obtained during the translation at704.
• At708, thegateway computer402 may transmit the transaction request message generated at706 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 at708.
• FIG. 8 is a flow chart that illustrates another process that may be performed in thesystem400 ofFIG. 4 according to aspects of the present disclosure. The processing illustrated inFIG. 8 may be performed by thegateway computer402.
• At802 inFIG. 8, thegateway computer402 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.
• At804, 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.
• At806, and possibly in aid of processing at804, thegateway computer402 may refer to the data dictionary514 (FIG. 5) to map one or more business fields from the payment card transaction message format to the EFT/ACH transaction message format.
• At808 inFIG. 8, and possibly in aid of processing at802,804 and/or806, thegateway computer402 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.
• At810, thegateway computer402 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 thesystem400, thegateway computer402 may perform the process ofFIG. 8 with respect to each one of a large number of payment card account transaction messages that may be received for conversion by thegateway computer402.
• FIG. 9 is a flow chart that illustrates another process that may be performed in thesystem400 ofFIG. 4 according to aspects of the present disclosure.
• At902 inFIG. 9, and in a set-up, configuration or re-configuration mode for thegateway computer402, one or more business rules may be stored in thegateway computer402. As will be seen, the business rule(s) may guide thegateway computer402 in selecting between the payment card account system and the EFT system for further routing of transaction messages received by thegateway computer402. The application of the business rules may allow the routing decisions of thegateway computer402 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 at904, thegateway computer402 may receive a transaction message as indicated at906. 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.
• At908 inFIG. 9, thegateway computer402 may apply one or more of the business rules stored at902 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 at906, 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.
• Adecision block910 may follow block908 in the process ofFIG. 9. Atdecision block910 thegateway computer402 makes a routing decision between the payment card system and the EFT system. That is, thegateway computer402 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 at906.
• If thegateway computer402 selects the payment card account system atdecision block910, then block912 may followdecision block910. Atblock912, thegateway computer402 routes the transaction for completion via the payment card account system. In doing so, thegateway computer402 may transmit a transaction message that includes a PAN into which the token has been translated.
• If thegateway computer402 selects the EFT system atdecision block910, then block914 may followdecision block910. Atblock914, thegateway computer402 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 withFIG. 8.
• In some embodiments,steps908 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, thegateway computer402 may determine whether to proceed fromstep906 tosteps908 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 thegateway computer402 has access to data that indicates either current or prevailing conditions in the payment card account system and the EFT system, from which data thegateway computer402 is able to determine which system provides faster transaction completion. Based on that data, thegateway computer402 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 thegateway computer402 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, thegateway computer402 is able to determine which system is associated with a lower fee to the merchant for handling the current transaction. Thegateway computer402 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, thegateway computer402 is embodied as an intelligent edge device. In other embodiments, the functional intelligence ascribed herein to thegateway computer402 may reside elsewhere in thesystem400, and the topological location in the system depicted as occupied by thegateway computer402 may alternatively be occupied by a conventional or near-conventional router.
• In some embodiments, or in some situations, when thegateway computer402 routes a transaction to the EFT system it does so via the payment/switch network206. However, in other embodiments, or in other situations, it does so via the consumer's bank (i.e., via the B-PSP computer208).
• 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 (20)

What is claimed is:

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 ofclaim 1, wherein the second transaction request message is transmitted by the payment network bridging computer to the EFT system.

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

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

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

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

7. The method ofclaim 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 ofclaim 7, wherein the first addressing indicator is a payment token that was provisioned to the account holder.

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

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

11. The method ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 16, wherein the EFT system is an ACH (automated clearing house) system.

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

19. The method ofclaim 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 ofclaim 18, wherein the payment token is in a format defined for payment card account numbers in the payment card account system.

Images