US20170364879A1

US20170364879A1 - Transaction flows and transaction processing for bridged payment systems

Info

Publication number: US20170364879A1
Application number: US15/621,477
Authority: US
Inventors: Sandeep Malhotra; Shanthan Subramaniam; Vitorino Jose Pereira Lopes; Dana Lorberg
Original assignee: Mastercard International Inc
Current assignee: Mastercard International Inc
Priority date: 2016-06-15
Filing date: 2017-06-13
Publication date: 2017-12-21
Also published as: WO2017218485A1; WO2017218479A1; US20220222643A1; CN109313755A; EP3472791A1; EP3472781A1; US20170364910A1; US20170364918A1; EP3472783A1; WO2017218482A1; US20170364880A1; WO2017218487A1; US20230385796A1; WO2017218489A1; EP3472782A1; US20220300937A1; CN109313756A; WO2017218483A1; US20170364890A1; CN109313766A

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.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 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

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.
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

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:

FIG. 1 is a block diagram of a payment card account system.

FIG. 2 is block diagram of a payment system such as an EFT (electronic funds transfer) system.

FIG. 3 is a block diagram of a payment transaction system provided in accordance with aspects of the present disclosure.

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.

FIG. 5 is a block diagram of an example computer system that may perform functions in the system of FIG. 3.

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

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.
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.
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.
FIG. 1 is a block diagram that illustrates a payment card account system 100.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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
FIG. 3 is a block diagram of a payment transaction system 300 provided in accordance with aspects of the present disclosure.
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).
As another alternative, the customer device 302 may be a PC or laptop computer or a smartphone/mobile device that runs a web browser.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
As shown in FIG. 4, the antenna 406 may comprise several loops along the periphery of the support structure 402.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The storage device 504 may also store one or more databases 514 needed for operation of the system component computer 502.
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.
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.
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.
Block 604 in FIG. 6 represents processing that may occur in or by the merchant system 306 in connection with a transaction flow.
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.
Block 608 in FIG. 6 represents processing that may occur by the O-PSP 308 in connection with a transaction flow.
Block 610 in FIG. 6 represents processing that may occur by the payment switch/network 312 in connection with a transaction flow.
Block 612 in FIG. 6 represents processing that may occur by the B-PSP 314 in connection with a transaction flow
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.
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.
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.
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.
The card acceptance interface for a remote transaction (such as an in-app transaction or an online transaction) may be a browser or mobile application utilizing manual entry of the token or other transaction information or the token may be supplied via a digital wallet. In such remote transactions, the user may provide payment credentials and other transaction-related information (name, billing address, shipping address, etc.) to complete the transaction either during the checkout process or with the information having been stored during enrollment (e.g., via a digital wallet).
When the user engages in checkout from such an interface using a deposit account as the underlying source of funds, any one of the above alternative transaction flows may occur in various use cases. As another alternative, the following further alternative flow may take place.
Via the merchant device a digital wallet acceptance interface may be invoked, with user/customer authentication or with the customer pre-authenticated. The digital wallet provider may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. The digital wallet provider determines the O-PSP 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.
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.
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.
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.
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.
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).
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.
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).
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.
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.
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.
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.
At 724, the B-PSP 314 may check the validity of the indicated beneficiary account.
At 726, the B-PSP 314 may post the transaction against the beneficiary account (this may be net of fees).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
At 906, confirmation of the payment is received.
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.
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.
As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.
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.
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.
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.
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.
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.
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.

Claims

What is claimed is:

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:

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.