U.S. patent application number 17/665836 was filed with the patent office on 2022-09-22 for transaction flows and transaction processing for bridged payment systems.
The applicant listed for this patent is MasterCard International Incorporated. Invention is credited to Dana Lorberg, Sandeep Malhotra, Vitorino Jose Pereira Lopes, Shanthan Subramaniam.
Application Number | 20220300937 17/665836 |
Document ID | / |
Family ID | 1000006379569 |
Filed Date | 2022-09-22 |
United States Patent
Application |
20220300937 |
Kind Code |
A1 |
Malhotra; Sandeep ; et
al. |
September 22, 2022 |
TRANSACTION FLOWS AND TRANSACTION PROCESSING FOR BRIDGED PAYMENT
SYSTEMS
Abstract
In operating a payment card account transaction acquirer
computer, a transaction request message is received from a
merchant. The message represents a purchase transaction accepted by
the merchant. The transaction request message is in a format
required by a payment card account system. The message includes an
indication that funds corresponding to the purchase transaction are
to be transferred to a bank account to benefit the merchant via an
EFT system. The indication is detected by the payment card account
transaction acquirer computer. That computer stores a record of the
purchase transaction. In response to the detection of the
indication, a flag is set in the record. The flag indicates that
the record is not to be submitted for clearing in the payment card
account system.
Inventors: |
Malhotra; Sandeep;
(Greenwich, CT) ; Subramaniam; Shanthan; (Baldwin
Place, NY) ; Pereira Lopes; Vitorino Jose;
(Brookfield, CT) ; Lorberg; Dana; (St. Louis,
MO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MasterCard International Incorporated |
Purchase |
NY |
US |
|
|
Family ID: |
1000006379569 |
Appl. No.: |
17/665836 |
Filed: |
February 7, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15621477 |
Jun 13, 2017 |
|
|
|
17665836 |
|
|
|
|
62350322 |
Jun 15, 2016 |
|
|
|
62350335 |
Jun 15, 2016 |
|
|
|
62350407 |
Jun 15, 2016 |
|
|
|
62351155 |
Jun 16, 2016 |
|
|
|
62350821 |
Jun 16, 2016 |
|
|
|
62351016 |
Jun 16, 2016 |
|
|
|
62351227 |
Jun 16, 2016 |
|
|
|
62350831 |
Jun 16, 2016 |
|
|
|
62350416 |
Jun 15, 2016 |
|
|
|
62351164 |
Jun 16, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/4012 20130101;
G06Q 20/401 20130101; G06Q 20/108 20130101; G06Q 20/023 20130101;
G06Q 20/405 20130101; G06N 20/00 20190101; G06Q 20/325 20130101;
G06Q 20/105 20130101; G06Q 20/4016 20130101; G06Q 20/322 20130101;
G06Q 10/107 20130101; G06Q 20/202 20130101; G06Q 20/341 20130101;
G06Q 20/385 20130101; G06Q 20/34 20130101; G06Q 20/40 20130101;
G06Q 20/027 20130101; G06Q 20/36 20130101; G06Q 20/3221 20130101;
G06Q 20/387 20130101; G06Q 20/102 20130101; G06Q 20/204 20130101;
G06Q 40/02 20130101; G06Q 20/10 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 operating a payment card account transaction
acquirer computer, the method comprising: receiving, at the payment
card account transaction acquirer computer, a transaction request
message from a merchant, the transaction request message
representing a purchase transaction accepted by the merchant, the
transaction request message in a format required by a payment card
account system, the transaction request message including an
indication that funds corresponding to the purchase transaction are
to be transferred to a bank account to benefit the merchant via an
EFT (electronic funds transfer) system; detecting said indication
by the payment card account transaction acquirer computer; storing,
by the payment card account transaction acquirer computer, a record
of the purchase transaction, said storing including, in response to
said detecting step, setting a flag in said record, said flag
indicating that the payment card account transaction acquirer
computer is not to submit said record for clearing in the payment
card account system.
2. The method of claim 1, wherein the EFT system is an ACH
(automated clearing house) system.
3. The method of claim 1, wherein the transaction request message
includes a payment token.
4. The method of claim 3, wherein the payment token is in a format
for payment card account numbers in the payment card account
system.
5. The method of claim 4, wherein: the payment token includes a BIN
(bank identification number) portion, said BIN portion of the
payment token being said indication.
6. A method of operating a payment card account system, the method
comprising: receiving, in a payment card account system computer, a
transaction request message, the transaction request message
related to a purchase transaction performed by a customer and a
merchant point of sale; routing the transaction request message for
payment to benefit the merchant from a deposit bank account of the
customer via an EFT (electronic funds transfer) system; receiving
confirmation of said payment; receiving, from a payment card
account transaction acquirer computer, a clearing request message,
said clearing request message requesting to include said purchase
transaction in a payment card account system clearing process; and
excluding said purchase transaction from said payment card account
system.
7. The method of claim 6, wherein: the clearing request message is
received by a payment card account system clearing computer; and in
determining to exclude said purchase transaction from said payment
card account system clearing process, said payment card account
system clearing computer refers to a BIN (bank identification
number) portion of an account indicator associated with the
purchase transaction.
8. The method of claim 6, wherein: the clearing request message is
received by a payment card account system clearing computer; and in
determining to exclude said purchase transaction from said payment
card account system clearing process, said payment card account
system clearing computer refers to a transaction record stored at a
time when said confirmation of said payment was received.
9. The method of claim 6, wherein said EFT system is an ACH
(automated clearing house) system.
10. The method of claim 6, further comprising: transmitting a
message to said payment card account transaction acquirer computer
to indicate that said purchase transaction has been excluded from
said payment card account system clearing process.
11. The method of claim 6, wherein said payment to benefit the
merchant is routed via the EFT system to a bank account owned by
the merchant.
12. The method of claim 6, wherein said payment to benefit the
merchant is routed via the EFT system to a pooled account at an
acquirer bank that provides services to the merchant.
13. The method of claim 6, wherein said payment to benefit the
merchant is routed via an EFT system switch.
14. A method comprising: initiating a transaction at a card
acceptance terminal, said initiating including receipt of payment
credentials; evaluating the payment credentials at a merchant
system; determining an originator payment services provider (O-PSP)
at the merchant system; building a transaction request message at
the merchant system; submitting the transaction request message
from the merchant system to the O-PSP; evaluating the transaction
request message at the O-PSP; authenticating consumer credentials
at the O-PSP; debiting a consumer's account in response to the
O-PSP; determining a transaction routing path at a payment network;
routing a transaction message from the payment network to a
beneficiary payment services provider (B-PSP); evaluating the
transaction message at the B-PSP; checking validity of a
beneficiary account at the B-PSP; posting the transaction against
the beneficiary account; returning a response message from the
B-PSP to the O-PSP via the payment network; and returning the
response message from the O-PSP to at least one of the merchant
system and the card acceptance terminal.
15. The method of claim 14, wherein the payment network is an EFT
(electronic funds transfer) network.
16. The method of claim 15, wherein the payment network is an ACH
(automated clearing house) network.
17. The method of claim 14, wherein the card acceptance terminal is
a point-of-sale (POS) terminal.
18. The method of claim 17, wherein the initiating of the
transaction includes reading a payment card account system card at
the POS terminal.
19. The method of claim 18, wherein the response message is
returned to the POS terminal.
20. The method of claim 18, wherein the response message is
returned to the merchant system.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a Continuation of U.S. Non-Provisional
patent application Ser. No. 15/621,477 (filed Jun. 13, 2017) which
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
[0002] Payment networks for the purpose of funds transfer between
bank accounts are commonly used for the purpose of moving money
from one person's bank account to another person's bank account
(i.e., a "Person to Person" or "P2P" transfer). A difficulty in
applying such transfers as a payment for goods or services at a
merchant site or payment to a merchant (a "P2M" payment) has
existed due to the lack of acceptance points to enable EFT payment
network transactions to be accepted by merchants.
[0003] Payment cards which allow users to perform credit and debit
transactions are in widespread use. These cards are typically
issued by financial institutions and allow users to initiate
transactions at merchants and other point of sale locations. In
order to ensure interoperability between these payment cards and
card readers, the payment cards are typically formed pursuant to
standards such as ISO/IEC 7810 and 7811 (regarding the physical
characteristics of magnetic stripe cards) or ISO/IEC 14443 or 15693
(or others, regarding the electrical characteristics of contactless
payment cards). These payment cards, however, use account numbers
and routing information which requires that they be routed through
a bank card network, and do not allow direct access to a user's
bank account. A routing number on a typical payment card is not the
same as the routing number of a user's direct deposit account (DDA)
or other financial account.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Features and advantages of some embodiments of the present
disclosure, and the manner in which the same are accomplished, will
become more readily apparent upon consideration of the following
detailed description of the invention taken in conjunction with the
accompanying drawings, which illustrate preferred and example
embodiments and which are not necessarily drawn to scale,
wherein:
[0005] FIG. 1 is a block diagram of a payment card account
system.
[0006] FIG. 2 is block diagram of a payment system such as an EFT
(electronic funds transfer) system.
[0007] FIG. 3 is a block diagram of a payment transaction system
provided in accordance with aspects of the present disclosure.
[0008] FIG. 4 is a schematic plan view of a payment IC (integrated
circuit) card that may be employed in connection with the system of
FIG. 3.
[0009] FIG. 5 is a block diagram of an example computer system that
may perform functions in the system of FIG. 3.
[0010] FIGS. 6, 7, 8 and 9 are flow charts that illustrate
processes that may be performed in the system of FIG. 3 in
accordance with aspects of the present disclosure.
DESCRIPTION
[0011] In general, and for the purpose of introducing concepts of
embodiments of the present disclosure, according to various use
cases or alternative transaction flows, a transaction may be
initiated at a merchant device, and then--via processing at one or
more of the merchant, an originator payment services provider
(O-PSP), a payment network (e.g., an EFT network) and a beneficiary
payment services provider (B-PSP)--payment for the transaction from
a customer to the merchant may be executed as an EFT from the
customer's deposit account. Such an arrangement brings card payment
network acceptance together with an EFT system to bridge an
existing gap relative to P2M payments. This arrangement builds on
the wide array of acceptance points that have secure interfaces and
are offered in the card payment network acceptance point population
and card payment network infrastructure. Measures may be taken to
exclude transactions initiated from merchant acceptance points and
funded via an EFT system from being included in card network
clearing processes.
[0012] In other embodiments, it may be allowed to issue a new type
of payment card to users so that users are able to conduct
transactions involving their direct deposit account (DDA) or other
financial accounts (such as checking, savings or other financial
accounts). Embodiments allow a card having a physical form factor
pursuant to ISO/IEC 7810 to be provided to a user, where the card
includes routing and account information of the user's bank
account. The routing and account information may be used to
initiate or conduct transactions using a payment network (e.g.,
such as an automated clearing house or ACH network). Pursuant to
some embodiments, systems, methods and devices are provided
including a data card which comprises a first face, a second face,
and a storage device comprising stored encoded data, wherein the
encoded data include a financial account routing number and a
customer bank account number wherein the stored encoded data is
readable by a payment card reader configured to read at least one
of (i) magnetic stripe data pursuant to ISO/IEC 7811, (ii)
contactless data pursuant to ISO/IEC 14443, (iii) contactless data
pursuant to ISO/IEC 15693; and (iv) data via direct electronic
contact pursuant to ISO/IEC 7816. In some embodiments, the data
card has a magnetic stripe on the first face. In some embodiments,
the data card has an embossed or printed account identifier on at
least one of said first face and said second face. The result is an
improved payment card system allowing users direct access to their
financial accounts at the many card payment network acceptance
points which support these card form factors.
[0013] Some embodiments allow the use of physical and virtual
payment cards and devices which may be used with at existing
payment card acceptance points which cause a push payment
instruction to be made via a banking network (such as the automated
clearing house "ACH" network) effecting a debit of funds from a
user's bank account. In some embodiments, the payment card of the
present invention includes an account identifier or other
information which, when routed through the existing payment card
network, identifies the payment transaction as relating to a
payment type in which a push payment instruction is to be
created.
[0014] FIG. 1 is a block diagram that illustrates a payment card
account system 100.
[0015] The 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.
Block 104 in FIG. 1 represents a merchant device such as a POS
(point of sale) terminal/card reader. The merchant device 104 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, e.g., 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, a mobile device
running a mobile browser, etc.; in such situations, the customer
device 102 may engage in an online shopping session with an
e-commerce website hosted by the merchant device 104.
[0016] A computer 106 operated by an acquirer (acquiring financial
institution) is also shown as part of the system 100 in FIG. 1. The
acquirer computer 106 may receive a payment account system
authorization request message for the transaction from the merchant
device 104. The acquirer computer 106 may route the authorization
request message via a card network 108 to a server computer 110
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. The authorization response message generated by the
payment issuer server computer 110 may be routed back to the
merchant device 104 via the card network 108 and the acquirer
computer 106.
[0017] One well known example of a card network is referred to as
the "Banknet" system, and is operated by Mastercard International
Incorporated, which is the assignee hereof.
[0018] The payment account issuer server computer 110 may be
operated by or on behalf of a financial institution ("FI") that
issues payment accounts to individual users such as the customer
who presented or operated the customer device 102 referred to
above. For example, the payment card issuer server 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.
[0019] 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.
[0020] The components of the system 100 as depicted in FIG. 1 are
only those that are needed for processing a single transaction. A
typical payment system may process many purchase transactions
(including simultaneous transactions) and may include a
considerable number of payment account issuers and their computers,
a considerable number of acquirers and their computers, and
numerous merchants and their devices, as well as a very large
number of customer devices.
[0021] FIG. 2 is a block diagram that illustrates a payment network
system 200, of which one example is the ACH (automated clearing
house) system operated in the United States.
[0022] The system 200 includes an originator device 202, which may
be a computer operated by an originator of a transaction. Common
kinds of transactions are credit transactions and debit
transactions. The originator is the party that initiates the
transaction. The originator may be, for example, an individual or a
corporation or other organization.
[0023] The system 200 further 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 system 200. The
originator PSP computer 204 may be operated by an originator PSP of
which the originator is a customer. The switch/network 206 may be
operated by a governmental or private entity that serves as a
clearing facility for the system 200.
[0024] Also included in the system 200 is a beneficiary PSP
computer 208. The beneficiary PSP computer 208 receives entries
from the payment system switch/network 206 and posts entries to
accounts of depositors.
[0025] 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 PSPs may
typically be banks or other financial institutions (FIs).
[0026] The communications among the parties in the system 200 may
typically be conducted using XML (eXtensible Markup Language) and
may comply with a standard according to ISO 20022.
[0027] The components of the system 200 as depicted in FIG. 2 are
only those that are needed for processing a single transaction. A
typical payment network system may process many transactions
(including simultaneous transactions) and may include a
considerable number of PSPs and their computers, one or more
clearing operators, and numerous originators and beneficiaries
[0028] FIG. 3 is a block diagram of a payment transaction system
300 provided in accordance with aspects of the present
disclosure.
[0029] The payment transaction system 300 may include a customer
device 302. The customer device 302 may be in the form of a card
shaped device that stores and allows reading of a token. The token
may be mapped in the system 300 to the customer's deposit account
details. Alternatively, the deposit account details may be directly
stored in the card shaped device. As an alternative to the card
shaped device, the customer device may be a fob or a mobile device
that runs a payment application to support interaction with
merchant devices (such as the merchant device/POS terminal
indicated by reference numeral 304 in FIG. 3).
[0030] As another alternative, the customer device 302 may be a PC
or laptop computer or a smartphone/mobile device that runs a web
browser.
[0031] The merchant device/POS terminal 304 may in some cases be
deployed at a checkout counter in a retail store and equipped with
a card reader or other mechanism for receiving data from a customer
device. In other use cases, the merchant device 304 may be an
e-commerce server computer that hosts an online shopping website
that the customer may access with the customer device 302.
[0032] In addition, the system 300 may include a merchant computer
system 306 that may in some embodiments receive transaction data
from the merchant device 304 and perform processing according to
one or more transaction flows as described below.
[0033] The system 300 may also include an originator PSP 308 in
communication with the merchant system 306. The description of the
originator PSP 204 in regard to FIG. 2 may also be applicable, in
at least some respects, to the originator PSP 308 shown in FIG. 3.
The originator PSP (O-PSP) 308 may perform processing according to
one or more transaction flows as described below.
[0034] In some use cases/transaction flows, a digital wallet
provider 310 may be involved in the transaction flow and may be in
communication with the merchant system 306. In such use cases, the
digital wallet provider 310 may perform processing as described
below. The digital wallet provider may, by previous arrangement,
have undertaken to store a digital wallet for the customer.
[0035] The system 300 may also include a payment switch/network
312. The payment switch/network 312 may be in communication with
the O-PSP 308. The description of the payment switch/network 206 in
regard to FIG. 2 may, in at least some respects, be applicable to
the payment switch/network 312 shown in FIG. 3. The payment
switch/network 312 may perform processing according to one or more
transaction flows as described below.
[0036] Still further, the system 300 may include a beneficiary
payment services provider (B-PSP) 314. The B-PSP 314 may be in
communication with the payment switch/network 312. The description
of the beneficiary PSP 208 in regard to FIG. 2 may be applicable,
at least in some respects, to the B-PSP 314 shown in FIG. 3. The
B-PSP may be a bank or other financial institution at which the
customer has a deposit account.
[0037] Any one or more of the blocks shown in FIG. 3, in addition
to representing the indicated entity, may also be considered to
represent one or more computer systems or other computing devices
(e.g. smartphones or other mobile devices) operated by such
entity.
[0038] FIG. 4 is a schematic plan view of a payment IC (integrated
circuit) card 400 that may be employed in connection with the
system of FIG. 3. In particular, in some instances and/or in some
embodiments, the payment IC card 400 may serve the role of the
customer device 302 shown in FIG. 3. In its hardware aspects, the
payment IC card 400 may resemble a typical contactless IC
(integrated circuit) payment card.
[0039] In the embodiment shown in FIG. 4, the payment IC card 400
may include a support structure 402 that has an outer surface that
defines a card shaped body. The card shaped body may have the same
form factor as a conventional payment card and may be formed from
one or more layers of plastic (not separately indicated). It will
be appreciated that the payment IC card 400 has front and rear
faces, which are not separately indicated by the drawing. Such
faces are well known to designers and users of payment cards.
[0040] The payment IC card 400 further includes an IC 404 and an
antenna 406, both supported in or on the support structure 402.
Although the following constituent components are not shown, it
should be understood that the IC 404 may include a processor, a
memory and a communications transceiver. The communications
transceiver may couple the processor to the antenna 406. The memory
may be in communication with the processor and may store program
instructions. The program instructions may control the processor to
perform functions as described herein. The processor may control
the communications transceiver so that the processor is enabled to
receive and transmit data via the transceiver in the form of
short-range data communications.
[0041] As shown in FIG. 4, the antenna 406 may comprise several
loops along the periphery of the support structure 402.
[0042] The IC 404 may include electrically conductive contact pads
408 and 410, by which the communications transceiver of the IC 404
may be electrically connected to the antenna 406.
[0043] The antenna 406 may be configured and/or the IC 404 may be
programmed such that the payment IC card 400 is operable in
accordance with either or both of the contactless data reading
standards ISO/IEC 14443 and ISO/IEC 15693. In addition or
alternatively, the payment IC card 400 may also include a magnetic
stripe (not shown) carried--for example-- on the rear face (not
shown) of the payment IC card 400. For example, the magnetic stripe
and the payment IC card 400 may be generally in compliance with the
magnetic stripe card standard ISO/IEC 7811. In addition or
alternatively, the payment IC card 400 may have surface contact
pads (not shown), e.g., on the front face (not shown) of the
payment IC card 400, and the payment IC card 400 may be otherwise
programmed and/or configured to conform to the contact data card
standard ISO/IEC 7816 and/or the well-known EMV standard.
[0044] The payment IC card 400 may be personalized by storage of
user-specific data in the memory of the IC 404. In some
embodiments, the stored data may include a bank deposit account
number. This would be appropriate in cases where the merchant
device 304 and the system 300 generally are configured to read and
engage in transaction messaging with use of the consumer's deposit
bank account number. In other embodiments, the stored data may
include a token that is in the format of a payment card account
number. The token may not be associated with a payment card
account, but rather may be translatable (for example, by the O-PSP
308; for example, by reference to a Token Service Provider (not
shown)) to the consumer's deposit bank account number.
[0045] As is commonly the case with payment cards, various types of
information may be printed and/or embossed on the face(s)--not
shown--of the payment IC card 400.
[0046] FIG. 5 is a block diagram of an example computer system 502
that may perform functions in the system of FIG. 3. The computer
system 502 illustrates an example of one or more of the computer
systems that may, as indicated above, be represented by one of the
blocks depicted in FIG. 3. The ensuing discussion provides an
overview of a typical one of the system component computers, and
accordingly, the computer system 502 will be nominally designated
as a "system component computer" in the following description.
[0047] Referring now to FIG. 5, the system component computer 502
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.
[0048] The system component computer 502 may include a computer
processor 500 operatively coupled to a communication device 501, a
storage device 504, an input device 506 and an output device 508.
The communication device 501, the storage device 504, the input
device 506 and the output device 508 may all be in communication
with the processor 500.
[0049] The computer processor 500 may be constituted by one or more
processors. Processor 500 operates to execute processor-executable
steps, contained in program instructions described below, so as to
control the system component computer 502 to provide desired
functionality.
[0050] Communication device 501 may be used to facilitate
communication with, for example, other devices (such as other
components of the payment system 300, as well as mobile devices
and/or computing devices operated by account holders).
Communication device 501 may comprise numerous communication ports
(not separately shown), to allow the system component computer 502
to communicate simultaneously with a number of other computers and
other devices, including communications as required to
simultaneously handle numerous interactions with other devices
and/or numerous transactions.
[0051] 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 a
printer.
[0052] 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 so-called flash memory. Any one or more of such information
storage devices may be considered to be a computer-readable storage
medium or a computer usable medium or a memory.
[0053] Storage device 504 stores one or more programs for
controlling processor 500. The programs comprise program
instructions (which may be referred to as computer readable program
code means) that contain processor-executable process steps of the
system component computer 502, executed by the processor 500, to
cause the system component computer 502 to function as described
herein.
[0054] The programs may include one or more conventional operating
systems (not shown) that control the processor 500 so as to manage
and coordinate activities and sharing of resources in the system
component computer 502, and to serve as a host for application
programs (described below) that run on the system component
computer 502.
[0055] The programs stored in the storage device 504 may include,
for example, a transaction handling application program 510. The
transaction handling application program 510 may operate to handle
transactions according to the particular role of the system
component computer 402 in one or more of the transaction flows
described below.
[0056] The storage device 504 may further store one or more
software modules (block 512) that serve as software interfaces
between the system component computer 502 and one or more other
components of the system 300.
[0057] The storage device 504 may also store, and the system
component computer 502 may also execute, other programs, which are
not shown. For example, such programs may include communications
software and a reporting application. The latter program may
respond to requests from system administrators for reports on the
activities performed by the system component computer 502. The
other programs may also include, e.g., device drivers, database
management software, etc.
[0058] The storage device 504 may also store one or more databases
514 needed for operation of the system component computer 502.
[0059] Other computerized components of the system 300 may be
constituted by computer hardware having the same type of components
and hardware architecture as described herein with reference to
FIG. 5.
[0060] FIG. 6 is a flow chart that provides an overview of the
various transaction processes that may be performed in the system
of FIG. 3 in accordance with aspects of the present disclosure.
Details of particular alternative transaction process flows are
described below.
[0061] At 602 in FIG. 6, an interaction occurs between the customer
device 302 and the merchant device 304 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.
[0062] Block 604 in FIG. 6 represents processing that may occur in
or by the merchant system 306 in connection with a transaction
flow.
[0063] Block 606 in FIG. 6 represents processing that may occur by
the digital wallet provider 310, in a use case in which the digital
wallet provider is involved in the transaction flow.
[0064] Block 608 in FIG. 6 represents processing that may occur by
the O-PSP 308 in connection with a transaction flow.
[0065] Block 610 in FIG. 6 represents processing that may occur by
the payment switch/network 312 in connection with a transaction
flow.
[0066] Block 612 in FIG. 6 represents processing that may occur by
the B-PSP 314 in connection with a transaction flow
[0067] There will now be described examples of four or more
transaction flows 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.
[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. 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. Also
prior to transmitting the request, the merchant system may
determine the originator PSP (O-PSP), and build the transaction
request message. The transaction request message is then submitted
by the merchant system to the O-PSP. The O-PSP evaluates the
transaction request message and authenticates the consumer
credentials and debits the originator/consumer account. The flow
then proceeds to the payment network (EFT network), which
determines the routing path and routes to the beneficiary PSP
(B-PSP). The B-PSP 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 returns a response
message to the O-PSP via the payment network (EFT network). The
O-PSP returns the response to the merchant system/merchant 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 a merchant system. The merchant system
builds and submits the transaction request message to the merchant
acquirer. The merchant acquirer may evaluate the payment
credentials in the message, and if the same are tokenized, may call
a detokenization service provided by a Token Service Provider. The
merchant acquirer may determine the O-PSP and transmit the message
to the O-PSP. The O-PSP evaluates the transaction request message
and authenticates the consumer credentials and debits the
originator/consumer account. The O-PSP also routes the message to
the payment network (EFT network). The payment network determines
the routing path and routes the message to the B-PSP. The B-PSP
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 returns a response message to the
O-PSP via the payment network (EFT network). The O-PSP returns the
response to the merchant system/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. The merchant acquirer may evaluate the payment
credentials in the message, and may determine the payment network
(EFT network). The payment 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 network may determine
the O-PSP and transmit the message to the O-PSP. The O-PSP may
evaluate the message and authenticate the consumer credentials and
debit the originator/consumer account. Also, the O-PSP may return
the response to the payment network, which determines the routing
path and routes the message to the B-PSP. The B-PSP 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 returns a response message to the O-PSP via the
payment network (EFT network). The O-PSP returns the response to
the merchant system/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 and
builds and submits a transaction request message to the O-PSP. The
O-PSP 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. The B-PSP 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 returns a response message to the O-PSP via the payment
network (EFT network). The O-PSP 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 flow, where the
digital wallet provider may act as B-PSP 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 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] FIG. 7 is a flow chart that illustrates a process that may
be performed in the system of FIG. 3. FIG. 7 may be regarded as
recapitulating and/or providing additional detail with respect to
the process illustrated in FIG. 6.
[0077] At 702 in FIG. 7, a transaction is initiated at a card
acceptance terminal. The card acceptance terminal may be a POS
terminal including a card reader, and may be an example of the
merchant device 304 shown in FIG. 3. The customer device 302 may be
a payment IC card. This process step may include the merchant
device 304 receiving payment credentials (e.g., account number or
token) by reading the customer device 302.
[0078] At 704, the merchant system 306 may receive the payment
credentials from the merchant device 304 and may evaluate the
payment credentials (including, e.g., parsing the format of data
contained in the payment credentials).
[0079] At 706, the merchant system 306 may determine an appropriate
O-PSP for the transaction, in view of the payment credentials
submitted for the transaction. At 708, the merchant system 306 may
build a suitable transaction request message. At 710, the merchant
system 306 may submit the transaction request message that it has
built to the O-PSP 308.
[0080] At 712, the O-PSP 308 may evaluate the transaction request
message. This may include performing various security checks.
Moreover, at 714, the O-PSP 308 may authenticate the consumer's
credentials (e.g., by validating a cryptogram that was generated by
the customer device 302 and included in the transaction request
message).
[0081] At 716, the O-PSP 308 may debit the consumer's account
(e.g., the consumer's bank deposit account maintained by the
O-PSP). The amount of the debit may correspond to the transaction
amount as indicated in the transaction request message. Suitable
messaging may then occur between the O-PSP 308 and the payment
switch/network 312.
[0082] At 718, the payment switch/network 312 may determine a
transaction routing path for a transaction message to complete the
transaction. The routing may be based on information provided in
the messaging from the O-PSP 308.
[0083] At 720, the payment switch/network 312 may route a
transaction message to the B-PSP 314. The message may identify the
merchant/beneficiary's account.
[0084] At 722, the B-PSP 314 may evaluate the transaction message
that was routed to it from the payment switch/network 312. This may
involve further security checks.
[0085] At 724, the B-PSP 314 may check the validity of the
indicated beneficiary account.
[0086] At 726, the B-PSP 314 may post the transaction against the
beneficiary account (this may be net of fees).
[0087] At 728, the B-PSP 314 may return a response message to the
O-PSP 308 via the payment switch/network 312. The response message
may be for confirming that the transaction was completed and the
funds credited to the merchant's account.
[0088] At 730, the response message provided to the O-PSP 308 may
be returned to the merchant system 306 and/or the merchant device
304. This may signal completion of the transaction at the point of
sale.
[0089] The discussion will now turn to certain measures that may be
necessary or desirable in a unified/bridged payment system in which
both EFT transactions and conventional payment card account
transactions are processed to settle purchases by consumers from
merchants. The system may resemble the system 300, while also
including elements of the payment card account system 100 shown in
FIG. 1.
[0090] In many payment card account transactions, the authorization
request and response occur at the time of the purchase transaction,
and then the actual transfer of funds from the consumer's bank to
the merchant's bank is implemented via a subsequent batch clearing
process. The following discussion will touch on certain measures
that may be undertaken to assist in enabling EFT transactions to
coexist with payment card account system clearing functions.
[0091] FIG. 8 is a flow chart that illustrates a process that may
be performed according to aspects of the present disclosure. The
process may be performed at a transaction acquirer (such as element
106 in FIG. 1) that also receives and processes EFT system
transactions (as does the O-PSP 308 in FIG. 3).
[0092] At 802 in FIG. 8, the transaction acquirer receives a
transaction request message from a merchant. The message may be in
a message format prescribed for the payment card account system in
which the transaction acquirer operates. The message may represent
a purchase transaction accepted by the merchant. The transaction
request message may include an indication that the payment to the
merchant for the current transaction is to be effected via an EFT
transaction contemporaneous with the underlying purchase
transaction. Thus the funds are to be transferred via an EFT system
to a bank account to benefit the merchant. The indicator may be a
specific flag and/or the format of the consumer's account number,
or based on the BIN (bank identification number) portion of a token
that is included in the transaction request message.
[0093] At 804, the transaction acquirer may detect the indication
that this is to be an EFT transaction. The indication may be
detected, in some embodiments, by reading the BIN portion of the
token (if present) and matching it to a BIN or BIN range that
corresponds to tokens used for EFT transactions. Alternatively, the
detection of the indication may be an outcome of a detokenization
process requested by the transaction acquirer.
[0094] At 806, the transaction acquirer stores a record of the
purchase transaction. The record, as stored, may include (in
response to the detection of the EFT transaction) a "don't clear"
flag that is set to indicate that the transaction acquirer is not
to submit the record for clearing in a subsequent batch clearing
process for the day's transactions. It is appropriate to omit the
transaction from clearing, because the EFT transaction has itself
provided the necessary transfer of funds to the merchant or the
merchant's account or for the merchant's benefit.
[0095] FIG. 9 is a flow chart that illustrates a process that may
be performed according to aspects of the present disclosure. The
process of FIG. 9 is an alternative to the process of FIG. 8, and
may be performed, for example, at a central facility of the payment
system. The central facility may be the payment switch/network 312,
the card network 108 (FIG. 1) and/or a bridging function or device
(not separately shown) that interconnects elements 108 and 312. For
purposes of discussing FIG. 9, it is assumed--without
limitation--that the process occurs at the card network 108 and is
accordingly performed by a payment card account system
computer.
[0096] At 902, the payment card account system computer receives a
transaction request message. The message relates to a purchase
transaction performed by a customer and a merchant point of
sale.
[0097] At 904, the transaction request message is routed by the
payment card account system computer for payment to benefit the
merchant from the customer's deposit bank account via an EFT
system.
[0098] At 906, confirmation of the payment is received.
[0099] Thereafter, a lapse of time (indicated at 908) may occur
until it becomes time for clearing of the day's payment card
account system transactions.
[0100] At 910, the payment card account system computer may receive
a request for clearing of the transaction according to payment card
account system clearing practices. The request may be included in a
batch of requests and may originate from a transaction acquirer.
However, the payment card account system computer "knows" that the
merchant has already received payment for the transaction.
Accordingly, and as indicated at 912, the payment card account
system computer excludes the transaction in question from the
clearing process. In some embodiments, the payment card account
system computer may exclude the transaction from clearing based on
a BIN portion of a token associated with the transaction (e.g.,
because the indicated BIN range is associated with tokens that
represent deposit bank accounts from which EFT transactions may be
funded). In some embodiments, the payment card account system
computer may exclude the transaction based on an indication or flag
in a previously stored record for the transaction. It will be
recognized that the payment card account system computer may be
deemed a clearing computer.
[0101] 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.
[0102] 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.
[0103] As used herein and in the appended claims, the term "memory"
should be understood to encompass a single memory or storage device
or two or more memories or storage devices.
[0104] As used herein and in the appended claims, a "server"
includes a computer device or system that responds to numerous
requests for service from other devices.
[0105] 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 simultaneous performance of at
least some steps and/or omitting one or more steps.
[0106] As used herein and in the appended claims, the term "payment
card system account" includes a credit card account, a deposit
account that the account holder may access using a debit card, a
prepaid card account, or any other type of account from which
payment transactions may be consummated. The terms "payment card
system account" and "payment card account" and "payment account"
are used interchangeably herein. The term "payment card account
number" includes a number that identifies a payment card system
account or a number carried by a payment card, or a number that is
used to route a transaction in a payment system that handles
payment card transactions. The term "payment card" includes a
credit card, debit card, prepaid card, or other type of payment
instrument, whether an actual physical card, electronic, or
virtual.
[0107] As used herein and in the appended claims, the term "payment
card system" or "payment account system" refers to a system for
handling purchase transactions and related transactions. An example
of such a system is the one operated by Mastercard International
Incorporated, the assignee of the present disclosure. In some
embodiments, the term "payment card system" may be limited to
systems in which member financial institutions issue payment card
accounts to individuals, businesses and/or other organizations.
[0108] Although the present invention has been described in
connection with specific example embodiments, it should be
understood that various changes, substitutions, and alterations
apparent to those skilled in the art can be made to the disclosed
embodiments without departing from the spirit and scope of the
invention as set forth in the appended claims.
* * * * *