U.S. patent application number 17/708458 was filed with the patent office on 2022-07-14 for systems and methods for bridging transactions between eft payment networks and payment card networks.
The applicant listed for this patent is MasterCard International Incorporated. Invention is credited to Dana J. Lorberg, Sandeep Malhotra, Shanthan Subramaniam.
Application Number | 20220222643 17/708458 |
Document ID | / |
Family ID | 1000006230796 |
Filed Date | 2022-07-14 |
United States Patent
Application |
20220222643 |
Kind Code |
A1 |
Malhotra; Sandeep ; et
al. |
July 14, 2022 |
SYSTEMS AND METHODS FOR BRIDGING TRANSACTIONS BETWEEN EFT PAYMENT
NETWORKS AND PAYMENT CARD NETWORKS
Abstract
Methods and apparatus for bridging transactions between
electronic funds transfer (EFT) payment networks and payment card
networks. In an embodiment, a process includes a gateway computer
receiving a transaction message that includes a token and content,
determining that at least one business rule applies which concerns
routing of the transaction, and based on the business rule and the
content selecting a routing decision to one of route the
transaction to a payment card account system or route the
transaction to an electronic funds transfer (EFT) system. The
process also includes the gateway computer translating the token
into a payment card account number (PAN) when the routing decision
is to route the transaction to a payment card system, or
translating the token into a bank deposit account number when the
routing decision is to route the transaction to an EFT system. A
second transaction message is then transmitted to the payment card
system that includes the PAN when the payment card system is
selected or is transmitted to the EFT system that includes the bank
deposit account number when the EFT system is selected.
Inventors: |
Malhotra; Sandeep;
(Greenwich, CT) ; Subramaniam; Shanthan; (Baldwin
Place, NY) ; Lorberg; Dana J.; (St. Louis,
MO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MasterCard International Incorporated |
Purchase |
NY |
US |
|
|
Family ID: |
1000006230796 |
Appl. No.: |
17/708458 |
Filed: |
March 30, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15621383 |
Jun 13, 2017 |
|
|
|
17708458 |
|
|
|
|
62350821 |
Jun 16, 2016 |
|
|
|
62351016 |
Jun 16, 2016 |
|
|
|
62351227 |
Jun 16, 2016 |
|
|
|
62350831 |
Jun 16, 2016 |
|
|
|
62351164 |
Jun 16, 2016 |
|
|
|
62351155 |
Jun 16, 2016 |
|
|
|
62350322 |
Jun 15, 2016 |
|
|
|
62350407 |
Jun 15, 2016 |
|
|
|
62350416 |
Jun 15, 2016 |
|
|
|
62350335 |
Jun 15, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/3221 20130101;
G06Q 20/34 20130101; G06Q 20/027 20130101; G06Q 20/40 20130101;
G06Q 20/401 20130101; G06Q 20/102 20130101; G06Q 20/204 20130101;
G06Q 20/387 20130101; G06Q 40/02 20130101; G06Q 20/108 20130101;
G06Q 20/4012 20130101; G06Q 20/10 20130101; G06Q 20/405 20130101;
G06Q 20/023 20130101; G06Q 20/325 20130101; G06N 20/00 20190101;
G06Q 20/105 20130101; G06Q 20/4016 20130101; G06Q 20/322 20130101;
G06Q 10/107 20130101; G06Q 20/341 20130101; G06Q 20/202 20130101;
G06Q 20/385 20130101; G06Q 20/36 20130101 |
International
Class: |
G06Q 20/20 20060101
G06Q020/20; G06N 20/00 20060101 G06N020/00; G06Q 20/02 20060101
G06Q020/02; G06Q 20/34 20060101 G06Q020/34; G06Q 20/10 20060101
G06Q020/10; G06Q 20/38 20060101 G06Q020/38; G06Q 20/32 20060101
G06Q020/32; G06Q 20/40 20060101 G06Q020/40; G06Q 40/02 20060101
G06Q040/02; G06Q 20/36 20060101 G06Q020/36 |
Claims
1. A method of bridging transactions between electronic funds
transfer (EFT) payment networks and payment card networks
comprising: receiving, by a gateway computer, a transaction message
associated with a transaction, wherein the transaction message
comprises a token and content, and wherein the content comprises at
least a bank identification number (BIN) range, a transaction
amount and a merchant identifier; determining, by the gateway
computer based on the merchant identifier, that at least one
business rule applies which concerns routing of the transaction;
selecting, by the gateway computer based on the at least one
business rule and the content, a routing decision comprising a
decision to one of route the transaction to a payment card account
system or route the transaction to an electronic funds transfer
(EFT) system; translating, by the gateway computer when the routing
decision is to route the transaction to a payment card system, the
token into a payment card account number (PAN); translating, by the
gateway computer number when the routing decision is to route the
transaction to an EFT system, the token into a bank deposit account
number; and transmitting, by the gateway computer, a second
transaction message comprising the PAN to the payment card system
when the payment card system is selected or a second transaction
message comprising the bank deposit account number to the EFT
system when the EFT system is selected.
2. The method of claim 1 further comprising, prior to receiving the
transaction request message for a transaction: receiving, by the
gateway computer, at least one business rule concerning routing of
transaction request messages; and storing, by the gateway computer,
the at least one business rule.
3. The method of claim 1 wherein the transaction request message is
received from one of an acquirer computer or an originator payment
services provider (PSP) computer.
4. The method of claim 1 wherein the business rule calls for
routing the transaction in a manner that minimizes transaction
execution time.
5. The method of claim 4, further comprising, prior to selecting a
routing decision: receiving, by the gateway computer, data
associated with at least one of current conditions and prevailing
conditions in the payment card account system and in the EFT
system; and determining, by the gateway computer based on the data,
which one of the payment card account system or the EFT system
provides faster transaction completion.
6. The method of claim 1 wherein the business rule calls for
routing the transaction in a manner that at least one of minimizes
merchant transaction fees and that achieves business goals of at
least one of account issuers, merchants, and system operators.
7. A gateway computer comprising: a gateway processor; a
communication device operably connected to the gateway processor;
and a storage device operably connected to the gateway processor,
wherein the storage device stores processor-executable instructions
which when executed cause the gateway processor to: receive a
transaction message associated with a transaction, wherein the
transaction message comprises a token and content, and wherein the
content comprises at least a bank identification number (BIN)
range, a transaction amount and a merchant identifier; determine,
based on the merchant identifier, that at least one business rule
applies which concerns routing of the transaction; select, based on
the at least one business rule and the content, a routing decision
comprising a decision to one of route the transaction to a payment
card account system or route the transaction to an electronic funds
transfer (EFT) system; translate, when the routing decision is to
route the transaction to a payment card system, the token into a
payment card account number (PAN); translate, when the routing
decision is to route the transaction to an EFT system, the token
into a bank deposit account number; and transmit a second
transaction message comprising the PAN to the payment card system
when the payment card system is selected or a second transaction
message comprising the bank deposit account number to the EFT
system when the EFT system is selected.
8. The apparatus of claim 7, wherein the storage device stores
further instructions, prior to the instructions for receiving the
transaction request message, which when executed cause the gateway
processor to: receive at least one business rule concerning routing
of transaction request messages; and store the at least one
business rule.
9. The apparatus of claim 7 wherein the business rule calls for
routing the transaction in a manner that minimizes transaction
execution time.
10. The apparatus of claim 9, wherein the storage device stores
further instructions, prior to the instructions for selecting a
routing decision, which when executed cause the gateway processor
to: receive data associated with at least one of current conditions
and prevailing conditions in the payment card account system and in
the EFT system; and determine, based on the data, which one of the
payment card account system or the EFT system provides faster
transaction completion.
11. The apparatus of claim 7 wherein the business rule calls for
routing the transaction in a manner that at least one of minimizes
merchant transaction fees and that achieves business goals of at
least one of account issuers, merchants and system operators.
12. A method of bridging transactions between electronic funds
transfer (EFT) payment networks and payment card networks
comprising: receiving, by a gateway computer, a transaction message
associated with a transaction, wherein the transaction message
comprises a token and content, and wherein the content comprises at
least a bank identification number (BIN) range, a transaction
amount and a merchant identifier; determining, by the gateway
computer based on the BIN range, that at least one business rule
applies which concerns routing of the transaction; translating, by
the gateway computer, the token into a payment card account number
(PAN) and into a bank deposit account number; selecting, by the
gateway computer based on the at least one business rule and the
content, a routing decision comprising a decision to one of route
the transaction to a payment card system or to route the
transaction to an electronic funds transfer (EFT) system; and
transmitting, by the gateway computer, one of a second transaction
message comprising the PAN to the payment card system when the
payment card system is selected or a second transaction message
comprising the bank deposit account number to the EFT system when
the EFT system is selected.
13. The method of claim 12 further comprising, prior to receiving
the transaction request message for a transaction: receiving, by
the gateway computer, at least one business rule concerning routing
of transaction request messages; and storing, by the gateway
computer, the at least one business rule.
14. The method of claim 12 wherein the business rule calls for
routing the transaction in a manner that minimizes transaction
execution time.
15. The method of claim 14, further comprising, prior to selecting
a routing decision: receiving, by the gateway computer, data
associated with at least one of current and prevailing conditions
in the payment card account system and in the EFT system; and
determining, by the gateway computer based on the data, which one
of the payment card account system or the EFT system provides
faster transaction completion.
16. The method of claim 12 wherein the business rule calls for
routing the transaction in a manner that comprises at least one of
minimizing merchant transaction fees and achieving business goals
of at least one of account issuers, merchants, and system
operators.
17. A gateway computer comprising: a gateway processor; a
communication device operably connected to the gateway processor;
and a storage device operably connected to the gateway processor,
wherein the storage device stores processor-executable instructions
which when executed cause the gateway processor to: receive a
transaction message associated with a transaction, wherein the
transaction message comprises a token and content, and wherein the
content comprises at least a bank identification number (BIN)
range, a transaction amount and a merchant identifier; determine,
based on the BIN range, that at least one business rule applies
which concerns routing of the transaction; translate the token into
a payment card account number (PAN) and into a bank deposit account
number; select, based on the at least one business rule and the
content, a routing decision comprising a decision to one of route
the transaction to a payment card system or to route the
transaction to an electronic funds transfer (EFT) system; and
transmit one of a second transaction message comprising the PAN to
the payment card system when the payment card system is selected or
a second transaction message comprising the bank deposit account
number to the EFT system when the EFT system is selected.
18. The apparatus of claim 17 wherein the storage device further
comprises instructions, prior to the instructions for receiving the
transaction request message for a transaction, which when executed
cause the gateway processor to: receive at least one business rule
concerning routing of transaction request messages; and store the
at least one business rule.
19. The apparatus of claim 17 wherein the business rule calls for
routing the transaction in a manner that minimizes transaction
execution time.
20. The apparatus of claim 19, wherein the storage device includes
further instructions, prior to the instructions for selecting a
routing decision, which when executed cause the gateway processor
to: receive data associated with at least one of current and
prevailing conditions in the payment card account system and in the
EFT system; and determine, based on the data, which one of the
payment card account system or the EFT system provides faster
transaction completion.
21. The apparatus of claim 17 wherein the business rule calls for
routing the transaction in a manner that comprises at least one of
minimizing merchant transaction fees and achieving business goals
of at least one of account issuers, merchants, and system
operators.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Patent Application Nos. 62/350,322 (filed on Jun. 15, 2016);
62/350,335 (filed Jun. 15, 2016); 62/350,407 (filed Jun. 15, 2016);
62/351,155 (filed Jun. 16, 2016); 62/350,821 (filed Jun. 16, 2016);
62/351,016 (filed Jun. 16, 2016); 62/351,227 (filed Jun. 16, 2016);
62/350,831 (filed Jun. 16, 2016); 62/350,416 (filed Jun. 15, 2016);
and 62/351,164 (filed Jun. 16, 2016), and to U.S. patent
application Ser. No. 15/621,383 (filed Jun. 13, 2017); the contents
of which provisional applications and patent application are hereby
incorporated by reference for all purposes.
BACKGROUND
[0002] 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.
[0003] 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.
[0004] 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
[0005] 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:
[0006] FIG. 1 is a block diagram illustrating a payment card
account system in accordance with some embodiments of the
disclosure.
[0007] FIG. 2 is a block diagram of an embodiment of a payment
network system in accordance with some embodiments of the
disclosure.
[0008] FIG. 3 is a diagram that illustrates a data communication
model that is pertinent to aspects of the present disclosure.
[0009] FIG. 4 is a block diagram illustrating a financial
transaction system in accordance with some embodiments of the
disclosure.
[0010] 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.
[0011] 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
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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).
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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).
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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).
[0057] 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.
[0058] 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.
[0059] The storage device 504 may also store one or more databases
518 that may be required for operation of the gateway computer
system 500.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] Block 604 in FIG. 6 represents processing that may occur in
or by the merchant system 404 in connection with a transaction
flow.
[0064] 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.
[0065] 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).
[0066] 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.
[0067] 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.
[0068] 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).
[0069] 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.
[0070] 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.
[0071] 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).
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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 IBAN
(International Bank Account Number) format.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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).
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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.
[0104] 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).
[0105] The use of business rules for guiding routing decisions may
provide improved flexibility and increased stakeholder options in a
financial transaction system.
[0106] 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.
[0107] 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.
[0108] 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.
[0109] 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.
* * * * *