Patent Application
20190114645
The system 100 includes a payment device 102 (which may in some situations be a payment-enabled mobile device that stores a payment card account number and runs a payment applet; other form factors for the payment device, such as a fob, are also possible; also card-shaped payment devices, including payment IC cards and magnetic stripe cards are widely used). The system 100 further includes a reader component 104 associated with a POS (point of sale) terminal 106. In some known manner the reader component 104 is capable of reading the payment card account number and other information from the payment device 102. (Some usages include the term “point of interaction” to include both the point of sale at a retail store, plus card acceptance terminals or the like at premises of service providers, transit system entrance gate terminals, etc.)
The reader component 104 and the POS terminal 106 may be located at the premises of a retail store and operated by a sales associate of the retailer for the purpose of processing retail transactions. The payment device 102 is shown in
A computer 108 operated by an acquirer (acquiring financial institution) is also shown as part of the system 100 in
One well known example of a payment 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 112 may be operated by or on behalf of a financial institution (“FI”) that issues payment accounts to individual users and/or other entities. For example, the payment account issuer server computer 112 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 components of the system 100 as depicted in
A typical payment system like that shown in
Referring again to the authorization response mentioned above, which is generated by the account issuer and routed to the point of sale, the indication provided in such authorization response may indicate that the requested transaction is approved, but alternatively, in some cases, the authorization response may indicate that the requested transaction is declined.
The present inventors have now recognized opportunities to improve handling of situations in which the authorization response indicates the requested transaction is declined.
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 taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
In general, and for the purpose of introducing concepts of embodiments of the present invention, a payment system may handle declined payment account transactions in a manner that is more user-friendly than in conventional payment systems. When an authorization response indicates that a transaction is declined, the payment network may provide additional messaging, in parallel with the authorization response, such that an account holder's payment-enabled mobile device at the point of sale may receive and display additional information related to the declined transaction. The additional information may indicate a reason or reasons why the transaction was declined and/or may prompt the account holder to take one or more actions to facilitate a successful retry of the declined transaction.
In addition to and/or inclusive of components shown in
As seen in
(The short-range radio communication indicated at 204 in
To some extent, it will be posited in the following discussion, without limitation, that the payment-enabled mobile device 102a is a smartphone.
The payment-enabled mobile device 102a may include a housing 303. In many embodiments, the front of the housing 303 is predominantly constituted by a touchscreen (not separately shown), which is a key element of the user interface 304 of the payment-enabled mobile device 102a.
The payment-enabled mobile device 102a further includes a mobile processor/control circuit 306, which is contained within the housing 303. Also included in the payment-enabled mobile device 102a is a storage/memory device or devices (reference numeral 308). The storage/memory devices 308 are in communication with the processor/control circuit 306 and may contain program instructions to control the processor/control circuit 306 to manage and perform various functions of the payment-enabled mobile device 102a. As is well-known, a smartphone may function as what is in effect a pocket-sized personal computer, via programming with a number of application programs, or “apps”, as well as a mobile operating system (OS). (The apps are represented at block 310 in
As is typical for smartphones, the payment-enabled mobile device 102a may include mobile communications functions as represented by block 314 (
Moreover, the payment-enabled mobile device 102a may further include hardware and software/firmware to implement NFC (near field communication) capabilities or the like (represented by block 316 in the drawing) to facilitate interactions/short range-data communication between the payment-enabled mobile device 102a and the payment terminal 206 (
According to the example embodiment of
From the foregoing discussion, it will be appreciated that the blocks depicted in
Although the payment-enabled mobile device 102a has been described herein primarily as a smartphone, other types of mobile devices (e.g., a tablet computer) may be used in place of a smartphone in other embodiments.
Referring now to
The payment terminal 206 may also include peripheral components, in communication with and/or controlled by the processor 402, such as: (a) a keyboard 404 for receiving input from the human operator of the payment terminal 206, together with other input devices (not separately shown, such as a numeric keypad, a mouse, and/or a touch screen); (b) a product reader 406 (shown in phantom, for some embodiments) for reading any form of unique product identifier, such as a barcode or RFID, that appears on, or is attached to, products brought to the payment terminal 206 for purchase; (c) a cash drawer 408 (shown in phantom, for some embodiments) for storing cash received from customers; (d) one or more displays 410 for providing output and/or (in some embodiments) identifying products presented for purchase and their prices, indicating sales tax due, indicating transaction subtotals and totals, etc., providing prompts to the customer and/or to the service provider)—and, most pertinently for present purposes, displaying messages to indicate that requested payment account transactions have been approved or declined according to transaction authorization response messages routed from account issuers to the payment terminal 206; (e) a printer 412 for printing out documents and/or sales receipts; and (f) a number of communication interfaces 414 for allowing the processor 402, and hence, the payment terminal 206 to engage in communication over data networks with other devices (e.g., the acquirer 108 and one or more other devices).
In addition, the payment terminal 206 may include one or more memory and/or data storage devices (indicated collectively at 416), which may comprise any combination of one or more of a hard disk drive, RAM (random access memory), ROM (read only memory), flash memory, etc. The memory/data storage device(s) 416 may store software and/or firmware that programs the processor 402 and the payment terminal 206 to perform its functionality in what may be a conventional manner. Thus the memory/data storage device(s) 416 may be in communication with the processor 402. Further, the payment terminal 206 may include one or more housings (not shown) which contain and/or support one or more of the other components shown in
Further, the payment terminal 206 may include one or more card/payment device-reader elements (block 418) such as a mag stripe reader, a contact IC card reader, a contactless IC card reader, NFC communications capabilities (for communicating with payment-enabled mobile devices), etc. The reader elements 418 may be in communication with the processor 402.
Referring now to
The payment network 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 communications 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 conventional processors. Processor 500 operates to execute processor-executable steps, contained in program instructions described below, so as to control the payment network computer 502 to provide desired functionality.
Communication device 501 may be used to facilitate communication with, for example, other devices (such as computers operated by acquirers and account issuers and with numerous payment-enabled mobile devices, for purposes as described in this disclosure). For example (and continuing to refer to
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 payment network computer 502, executed by the processor 500 to cause the payment network 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 payment network computer 502, and to serve as a host for application programs (described below) that run on the payment network computer 502.
The programs stored in the storage device 504 may also include a communications software interface 510 to support communications between the payment network computer 502 and computers operated by or on behalf of transaction acquirers.
The storage device 504 may also store a communications software interface 512 to support communications between the payment network computer 502 and computers operated by or on behalf of payment account issuers.
Still further, the storage device 504 may store a communications software interface 514 to facilitate messaging from the payment network computer 502 to the respective wallet apps in numerous payment-enabled mobile devices such as the device 102a shown in
Continuing to refer to
Moreover, the storage device 504 may additionally store an application program 518 for managing generation and dispatching of additional/supplemental information messages to payment-enabled mobile devices in connection with current transactions that the account issuer has declined.
The storage device 504 may also store, and the payment network computer 502 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by the payment network computer 502. The other programs may also include, e.g., a database management program, device drivers, etc.
The storage device 504 may also store one or more databases 520 required for operation of the payment network computer 502.
A process that may be performed in the payment system 200 of
As indicated in phantom at 602 in
It will be appreciated that, in some contexts, the process of block 602 (or the process of block 604, as described below) may occur at the checkout counter of a retail store. The user 202 may have brought items (not shown) to be purchased to the checkout counter, and the payment terminal 206 may have scanned tags on the items to identify the items and permit the charge for the transaction (e.g., including sales tax) to be calculated by the payment terminal 206.
At block 604, the payment account transaction may be initiated by the user 202 tapping his/her payment-enabled mobile device 102a at a suitable location on the payment terminal 206 to allow the payment-enabled mobile device 102a to be read by the payment terminal 206. As is customary, an exchange of data messages may occur between the payment terminal 206 and the payment-enabled mobile device 102a via NFC or the like. For example, the data exchange may include the payment-enabled mobile device 102a transmitting a user-selected payment account number or token (representing one of the user's payment accounts) to the payment terminal 206. Other related information may also be transmitted from the payment-enabled mobile device 102a to the payment terminal 206. Such information may include an indication as to whether the user has recently (e.g., upon accessing the wallet app/wallet 312 immediately before the transaction) authenticated himself/herself to the wallet app/wallet 312, and if so, in what manner (e.g., biometrically or via PIN entry).
At block 606 the payment terminal 206 may generate a transaction authorization request message (also referred to as an “authorization request”). This may be done in a customary manner as currently takes place in payment account systems. The authorization request may include the transaction amount, a payment account number or token (received by the payment terminal 206 from the payment-enabled mobile device 102a at 604), and other information typically included in an authorization request. In some situations, the authorization request may contain data codes to indicate whether and/or how user authentication was performed with respect to the current transaction.
At block 608, the authorization request may be routed from the payment terminal 206 through the payment system 200. This also may occur in a manner as customarily performed in payment account systems. For example, the authorization request may be routed from the payment terminal 206 to a transaction processor (not shown apart from the acquirer 108) and/or to the acquirer 108. In some situations or arrangements, the authorization request may be forwarded from the payment terminal 206 to the transaction processor/acquirer via a merchant system (not shown). From the acquirer 108 and/or the transaction processor, the authorization request may be routed to the payment network 110a, and from the payment network 110a to the account issuer 112a. If the authorization request contains a payment token, detokenization (i.e., translation to a payment account number) may occur by or in association with the payment network 110a.
At block 610, the account issuer 112a receives the authorization request via the payment network 110a. At block 612, the account issuer generates a transaction authorization response message (also referred to as an “authorization response”) by processing the authorization request. This may occur in a generally or entirely customary manner in accordance with current practices in payment account systems. However, as will be seen, in some situations or in some embodiments, the authorization response may include data that is different from or in addition to data currently included in a typical authorization response. It will be appreciated that the authorization response may indicate that the transaction is approved or the authorization response may indicate that the transaction is declined. Examples of situations in which the transaction may be declined will be discussed further below. If the transaction is declined, the authorization response as generated by the account issuer 112a may contain a data code that indicates a reason why the transaction was declined. After the authorization response is generated, it is routed to the payment network 110a from the account issuer 112a.
At block 614, the payment network 110a receives the authorization response from the account issuer 112a.
A decision block 616 may follow block 614 in the process of
If the payment network 110a detects at 616 that the transaction has been declined, then the process of
Continuing to refer to
At block 626, the payment network 110a may transmit the decline reason message to the payment-enabled mobile device 102a via the channel of communications 208 (
At block 632, the user 202 may respond to the decline reason message displayed at 630 by taking one or more remedial steps (e.g., as prompted by the decline reason message). The remedial step(s) may lead to or facilitate a successful retry of the transaction.
In one example, it is assumed that the transaction was low value and was not immediately preceded by a user authentication. It is further assumed that the account issuer 112a declined the transaction because a low value transaction counter maintained by the account issuer 112a had reached a limit such that user authentication was required for the next transaction (i.e.,—in this case—the current transaction). In this situation, the authorization response may contain a data element that indicates that a transaction counter limit had been exceeded, and the decline reason message generated by the payment network computer 502 at block 624 (
In a variant of the above example, the decline reason message and payment-enabled mobile device 102a may prompt for another sort of user authentication, such as via fingerprint scan, facial recognition, or another type of biometric user authentication.
In another variant, a transaction may be declined by the account issuer 112a based on a result of a risk management process. Again the decline reason message may prompt for user authentication and retry, perhaps specifically prompting for a relatively strong authentication such as a biometric user authentication. The account issuer 112a may apply the risk management process only to very high value transactions, in some embodiments.
In another variant, the decline reason message/prompt to the user 202 may call for entry of an online PIN rather than a wallet PIN. (Those who are skilled in the art will recognize that the latter type of PIN is verified locally, at the payment-enabled mobile device 102a, whereas the former type of PIN is verified remotely, by the account issuer 112a.)
In another variant, the transaction may be declined because the user made an error while entering the PIN. The decline reason messaging via the payment-enabled mobile device 102a may prompt for re-entry of the PIN and retry.
In another example, it is assumed that the transaction is a debit account transaction and that the account issuer 112a declines the transaction because there are insufficient funds to cover the transaction in the underlying bank deposit account. The authorization response may include a data code that indicates insufficient funds as the reason the transaction was declined, but the payment terminal 206 may be arranged/programmed such that it provides the same message for all declined transactions, say, “transaction declined.” The payment network 112a, however, may generate and transmit to the payment-enabled mobile device 102a—in coded form or “en claire”—a decline reason message that says, “declined for insufficient funds.” This message may then be displayed to the user 202 via the payment-enabled mobile device 102a. As a remedial measure, the user 202 may operate one or more mobile banking apps on the payment-enabled mobile device 102a to transfer additional funds to the underlying bank deposit account. The user 202 may then retry the transaction, and it may be assumed that upon retry the transaction may be approved because—after the transfer—sufficient funds are available in the underlying bank deposit account.
In some situations, it may not be the case that all the steps of the process of
With a process such as that illustrated in
The teachings of this disclosure may be applied in the context of an e-commerce (online shopping) transaction as well as in a transaction at a retail store, as particularly described in connection with
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.
The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method 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 or a deposit account that the account holder may access using a debit card. The terms “payment card system account” and “payment card 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 debit card and/or credit card transactions. The term “payment card” includes a credit card or a debit card.
As used herein and in the appended claims, the term “payment card 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 exemplary 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.
