VERIFYING TRANSACTION CONTEXT DATA AT WALLET SERVICE PROVIDER
A first message is received at a wallet service provider. The first message contains transaction detail and transaction context data. A second message is also received at the wallet service provider. The second message contains a copy of the transaction detail data and a copy of the transaction context data. The wallet service provider may verify that the data copies match the original data. One of the messages may be received from a payment-enabled mobile device. The other message may originate from a merchant.
This application claims the benefit of U.S. Provisional Patent Application No. 61/948,197 filed on Mar. 5, 2014, the contents of which are hereby incorporated by reference for all purposes.
BACKGROUNDPayment cards such as credit cards and debit cards are in widespread use. In some environments, payment cards in the form of magnetic stripe cards prevail in terms of popularity. With mag stripe cards, the payment card account number may be read from the card at the point of sale by a magnetic stripe reader, and then submitted with a transaction authorization request to the account issuer via the payment network.
In other environments, it is more common to use so-called “contactless” payment cards. With contactless payment cards, the payment card account number is stored in an integrated circuit (IC) within the card, and is read by short-range radio communication between the card and the contactless reader component of a point of sale (POS) terminal With enhancements that have occurred to mobile phones, including smartphones, the capability has been added to perform NFC (near field communication) communications to enable so-called “contactless” payment cards to be digitized into these consumer devices. These mobile devices utilize a secure element (SE) to store the payment card account number and associated data, keys and Personal Identification Number (PIN) to enable the consumer to perform a payment transaction using the NFC short-range radio communications provided by the mobile device and the contactless reader component of a POS terminal.
In still other environments, so-called “contact” payment IC cards are placed in point of sale readers that can read the payment card account number from the card IC via direct conductive contacts provided on the face of the card.
As recent events have underlined, security of payment card account numbers can be a significant issue. Large scale data breaches at the merchant level have occurred and have compromised many cardholders' payment card account numbers. Efforts are ongoing to reduce the risk of theft and misuse of payment card account numbers.
Features and advantages of some embodiments of the present invention, 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 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 network transaction is consummated at the point of sale without the POS terminal receiving or reading a payment card account number. The consumer offers a payment-enabled mobile device as a credential for the transaction. The payment card account number need not be stored in the mobile device, but rather has been enrolled in a digital wallet maintained for the consumer by a wallet service provider (WSP) that is located remotely from the point of sale.
The POS terminal and the payment-enabled mobile device exchange data to initiate the payment transaction. The data provided from the payment-enabled mobile device to the POS terminal may include only (a) data to identify the consumer's WSP, and (b) an internet address for a server function that is hosted by the payment-enabled mobile device. The data provided from the POS terminal to the payment-enabled mobile device may relate to the current purchase transaction (e.g., transaction amount) and to the transaction context (e.g., data to identify the merchant that operates the POS terminal and the location of the purchase transaction).
The exchange of data between the POS terminal and the payment-enabled mobile device may be by any convenient mode, such as NFC.
Using the identity of the WSP as received from the payment-enabled mobile device, the POS terminal may route a message to the WSP, where the message contains the transaction data, the transaction context data and the internet address for the mobile device server function. The WSP may then use the internet address to set up a cryptographically secured communication channel with the mobile device via the server function hosted by the mobile device. This may involve mutual authentication of the WSP's computer and the mobile device server function.
The WSP's computer may transmit wallet form data to the mobile device via the secure channel to permit the consumer to select a payment card account from among those for which data is stored in the digital wallet maintained for the consumer by the WSP. The mobile device server function may send data to the WSP's computer to serve as an authentication token for the transaction, including data that indicates the consumer's selection of a payment card account to be used for the transaction, and data by which the WSP can confirm the validity of the transaction data and transaction context data provided to the WSP from the POS terminal.
The WSP may then act much like an acquirer in a conventional payment card system, by routing an authorization request for the transaction via the payment network to the issuer of the selected payment card account. Upon receiving a favorable authorization response, the WSP may route a confirmation to the POS terminal to indicate that a valid payment for the purchase transaction has been secured. The purchase transaction is then complete at the point of sale.
By way of background, and to more sharply illustrate differences between conventional practices and the teachings of the present disclosure, a conventional payment system will first be briefly described.
The system 100 includes a conventional payment card/device 102 (which may alternatively be a conventional 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). The system 100 further includes a reader component 104 associated with a POS terminal 106. In some known manner (depending on the type of the payment card/device 102) the reader component 104 is capable of reading the payment card account number and other information from the payment card/device 102.
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 card/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 card issuer server computer 112 may be operated by or on behalf of a financial institution (“FI”) that issues payment card accounts to individual users. For example, the payment card issuer server computer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment card account transactions to be charged to payment card accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records.
The components of the system 100 as depicted in
As illustrated in
Also included in the payment system 200 is a merchant point-of-interaction (POI) terminal 204, which may be a POS terminal as configured in accordance with aspects of the present invention. The merchant POI terminal 204 may, for example, be operated by a merchant (or merchant employee) at a retail store, and may interact with the payment-enabled mobile device 202 in a manner described below (e.g., by a short-range mode of data communication). Further details of the merchant POI terminal 204 will be described subsequently, including in the sections of the description relating to
Another feature of the payment system 200 is a computer 206 operated by a payment system acquirer (or a payment services provider—“PSP”) on behalf of an acquirer. As is customary, the acquirer may be a financial institution with which the merchant maintains a banking relationship. However, as will be seen from subsequent discussion, the roles of the PSP/acquirer computer 206 in the payment system may be quite different from the roles typically performed by the acquirer in a conventional payment system such as that illustrated in
A central aspect and component of the payment system 200 is a computer 208 operated by or on behalf of a wallet service provider (WSP). It is assumed that the WSP in question maintains a digital wallet for an individual user depicted at 210 as the user of the payment-enabled mobile device 202. Two main functional blocks of the WSP computer 208 are shown in
The transaction concentrator block 214 handles individual payment transactions in accordance with aspects of the present invention and as described in detail below.
Also shown in
A detailed description of operation of the payment system 200 will be provided below, particularly with reference to
As noted above, the block diagram representation of the payment system 200 as shown in
Moreover, as will be understood from the above description of a conventional payment system, the payment system 200 may process many transactions, including simultaneous transactions. A considerable number of payment card account issuers may be included in the payment system 200, and the payment system 200 may also include a considerable number of acquirers/PSPs and their computers. In addition, the payment system 200 may include a large number of merchant POI devices (in-store and/or e-commerce host computers), operated by a large number of merchants. Also, there may be a very large number of payment-enabled mobile devices as described herein (each including the above-mentioned server function which has a unique URI), and owned/used by numerous individual users. The users are holders of payment card accounts issued by issuing financial institutions and have enrolled with one or more WSPs, which maintain digital wallets for the users.
The payment-enabled mobile device 202 may include a conventional housing (indicated by dashed line 302 in
The payment-enabled mobile device 202 further includes conventional control circuitry 304, for controlling over-all operation of the payment-enabled mobile device 202. For example, the control circuitry 304 may include a conventional processor of the type designed to be the “brains” of a smartphone.
Other components of the payment-enabled mobile device 202, which are in communication with and/or controlled by the control circuitry 304, include: (a) one or more memory devices 306 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module) card 308; (c) a conventional touchscreen 312 which serves as the primary input/output device for the payment-enabled mobile device 202, and which thus receives input information from the user and displays output information to the user. As is the case with many models of smartphones, in some embodiments the payment-enabled mobile device 202 may also include a few physically-actuatable switches/controls (not shown), such as an on/off/reset switch, a menu button, a “back” button, a volume control switch, etc. It may also be the case that the payment-enabled mobile device 202 includes a conventional digital camera (as is the case with many smartphones), which is not shown.
The payment-enabled mobile device 202 also includes conventional receive/transmit circuitry 316 that is also in communication with and/or controlled by the control circuitry 304. The receive/transmit circuitry 316 is coupled to an antenna 318 and provides the communication channel(s) by which the payment-enabled mobile device 202 communicates via the mobile telephone communication network (not shown). The receive/transmit circuitry 316 may operate both to receive and transmit voice signals, in addition to performing data communication functions. As is known to those who are skilled in the art, such data communication may be via HTTP (HyperText Transfer Protocol) or other communication protocol suitable for carrying out data communication over the internet.
The payment-enabled mobile device 202 further includes a conventional microphone 320, coupled to the receive/transmit circuitry 316. Of course, the microphone 320 is for receiving voice input from the user. In addition, a loudspeaker 322 is included to provide sound output to the user, and is coupled to the receive/transmit circuitry 316.
The receive/transmit circuitry 316 may operate in a conventional fashion to transmit, via the antenna 318, voice signals generated by the microphone 320, and to reproduce, via the loudspeaker 322, voice signals received via the antenna 318. The receive/transmit circuitry 316 may also handle transmission and reception of text messages and other data communications via the antenna 318.
The payment-enabled mobile device 202 may also include circuitry 324 that is partly or wholly dedicated to implementing NFC communications functionality of the payment-enabled mobile device 202. The payment-enabled mobile device 202 may further include a loop antenna 326, coupled to the NFC circuitry 324. In some embodiments, the NFC circuitry 324 may partially overlap with the control circuitry 304 for the payment-enabled mobile device 202. Moreover, the NFC circuitry 324 is associated with, and may also overlap with, a secure element 328 that is part of the payment-enabled mobile device 202 and is contained within the housing 302, or the NFC circuitry could be omitted in embodiments that do not utilize NFC. The term “secure element” is well known to those who are skilled in the art, and typically refers to a device that may include a small processor and volatile and nonvolatile memory (not separately shown) that are secured from tampering and/or reprogramming by suitable measures. In some embodiments, the secure element 328 may be provided as part of the SIM card 308. In other embodiments, the secure element 328 may be constituted by an integrated circuit card separate from the SIM card 308 but possibly having the same form factor as the SIM card 308. In some embodiments of the payment-enabled mobile device 202, the secure element 328 may be conventional in its hardware aspects but may be programmed in accordance with aspects of the present invention in a manner to be described below. (It should be noted that the term “secure element” is not intended to be limited to devices that are IC-based, but rather may also include any secure execution environment in a mobile device, and may include software based secure execution environments running on the main mobile device processor.)
It should also be understood that the payment-enabled mobile device 202 may be operable as a conventional mobile telephone for communication—both voice and data—over a conventional mobile telecommunications network, which is not depicted in the drawing. Thus, the payment-enabled mobile device 202 may be in communication from time to time in a conventional manner with a mobile network operator (“MNO”—also not shown). For example, an over-the air communication channel (of which an example is communication channel 222 in
Later sections of this disclosure, including those related to
In some embodiments, the merchant POI terminal 204 may be largely or entirely conventional in its hardware aspects (with the possible exception of cost reductions that may be facilitated by teachings of this disclosure, as described below). Nevertheless, the merchant POI terminal 204 may be programmed in accordance with aspects of the present disclosure to provide functionality as described herein. In addition to the below description of functional process steps performed by the merchant POI terminal 204 as part of a typical purchase transaction (e.g., in connection with FIGS. 11A and 11B—see below), there will also be discussion below of some software aspects of the merchant POI terminal 204 in connection with
The merchant POI terminal 204 may include a processing element (or elements) such as the processor 402 shown in
The merchant POI terminal 204 may also include conventional peripheral components, in communication with and/or controlled by the processor 402, such as: (a) a keypad 404 for receiving input from the human operator of the POS terminal; (b) a product reader 406 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 terminal for purchase; (c) a cash drawer 408 for storing cash received from customers; (d) one or more displays 410 for providing output (e.g., 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 sales associate); (e) a printer 412 for printing out sales receipts; and (f) a communication controller 414 for allowing the processor 402, and hence, the merchant POI terminal 204 to engage in communication over data networks with other devices (e.g., the PSP/acquirer computer 206,
In addition, the merchant POI terminal 204 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 merchant POI terminal 204 to perform functionality as described herein. Thus the memory/data storage device(s) 416 may be in communication with the processor 402. Further, the merchant POI terminal 204 may include one or more housings (not shown) which contain and/or support one or more of the other components shown in
In some embodiments, the merchant POI terminal 204 may depart from the customary hardware configuration of POS terminals, in that it may lack the usual card-reader elements such as a mag stripe reader, a contact IC card reader, a contactless IC card reader, etc. Instead, the merchant POI terminal 204 may include a suitable hardware arrangement to allow for local communications with the payment-enabled mobile device 202, to thereby establish the communication channel indicated at 216 in
Referring again to
With the absence of card-reading capability, and also with no need to provide security measures to safeguard PANs (primary account numbers) and other sensitive consumer information (because, as will be seen, such information is never received in the merchant POI terminal 204 according to the processes contemplated herein), it may be possible to greatly simplify the merchant POI terminal 204 and to reduce it in cost in comparison to widely used models of POS terminals. Nevertheless, alternative embodiments of the merchant POI terminal 204 are also contemplated in which, to accommodate legacy technology, card-reader(s), etc., are included so that the merchant POI terminal 204 may read conventional payment cards in addition to accepting payment via the payment-enabled mobile device 202 as described herein.
Referring now to
The WSP computer 208 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 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 WSP computer 208 to provide desired functionality.
Communication device 501 may be used to facilitate communication with, for example, other devices (such as one or more computers operated by the payment network 110, the PSP/acquirer computer 206 and/or computers operated by other acquirers/PSPs, and numerous payment-enabled mobile devices such as the device 202 depicted in
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 WSP computer 208, executed by the processor 500 to cause the WSP computer 208 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 WSP computer 208, and to serve as a host for application programs (described below) that run on the WSP computer 208.
The programs stored in the storage device 504 may also include a transaction handling application program 510 that controls the processor 500 to enable the WSP computer 208 to handle requests for payment transactions in a manner described below in connection with
The storage device 504 may also store numerous instances of client software programs 512 that control the processor 500 to enable the WSP computer 208 to play a client role with respect to server functions hosted in numerous payment-enabled mobile devices (as provided in accordance with aspects of the present invention) with which the WSP computer 208 may communicate at a given time.
In addition, the storage device 504 may store a wallet interface program 514 by which the processor 500 may access digital wallet data stored in the WSP computer 208 with respect to numerous users of the payment system 200.
Still further, the storage device 504 may store an acquirer interface program 516, which provides a data communications interface to the PSP/acquirer computer 206 (
Continuing to refer to
Again continuing to refer to
Moreover, the storage device 504 may store a transaction clearing program 522, which may handle clearing of payment transactions handled via the WSP computer 208.
The storage device 504 may also store, and the WSP computer 208 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 WSP computer 208. The other programs may also include, e.g., one or more data communication programs, device drivers, etc.
The storage device 504 may also store one or more databases 524 required for operation of the WSP computer 208. Such databases may include, for example, a database (not separately indicated in
Like the WSP computer 208, the PSP/acquirer computer 206 may be constituted by conventional computer hardware; thus the PSP/acquirer computer 206 may have the same hardware architecture and aspects as described above in connection with the description of the WSP computer. The computer hardware making up the PSP/acquirer computer 206 may be programmed to cause the PSP/acquirer computer 206 to perform functions such as are described below.
A user/consumer 210 is depicted in
Each consumer's digital wallet/WSP entry 602 may itself be a data repository for storing digitalized payment cards that the consumer has selected for inclusion in his/her digital wallet. The digitalized cards may be issued by the same issuing financial institution or by several different issuers. The digitalized cards may all be branded from the same payment network or from more than one payment network. Inclusion of digitalized cards from a given payment network in the WSP 208's database (i.e., in consumers' digital wallets maintained by WSP 208) can occur if the WSP 208 has entered into a relationship with that payment network to allow the WSP to act as a quasi-acquirer with respect to that payment network.
Block 604 in
For each digitalized card 606 in the user's digital wallet 602, there is a digitalized image of the payment card account stored in the WSP computer 208. The digitalized image consists of the personalization template of the card application (i.e., a software application for digitally implementing the payment card account). The items included in the digitalized image depend on the requirements for wallet based transactions as established by the payment network for which the payment card account was issued.
The WSP computer 208 implements an engine that emulates the card payment application for the digitalized card 606. It can be said that the digitalized card 606 is made up of the digitalized image/personalization template for the particular payment card account plus the WSP engine for the relevant card payment application. As will be seen, the WSP 208 uses the digitalized payment card 606 to trigger and complete wallet payment transactions in place of the payment account card itself
It will be noted that every payment network is likely to require the PAN and the expiration date for the digitalized card image. Some payment networks may also require a Card Authentication Method (CAM). For example, a static CAM may be required, such as the CVC2 as established by MasterCard or the CVV as established by Visa. Alternatively, a dynamic CAM may be required, such as is provided in an EMV transaction. (As is known to those who are skilled in the art, EMV is a standard for inter-operation of IC cards with POS terminals and/or ATMs.) For a digitalized card for which EMV is required as a CAM/CVM, the WSP computer 208 itself may run an EMV engine. Some payment networks may require a specific CVM, such as a biometric (e.g., voice recognition in real time and/or face motion recognition), for each transaction. Other types of CAM/CVM requirements are also possible and/or contemplated, and some others will be discussed below. In some embodiments, the issuer of the payment card account may specify one or more CVMs instead of or in addition to CVM(s) required by the payment network.
The payment-enabled mobile device 202 serves as the credential of the user 210 with respect to the payment system 200 and also is the mechanism by which the user 210 is able to initiate and perform payment transactions and otherwise to interact with the payment system 200.
One salient feature of the payment-enabled mobile device 202 is that it hosts a server function, represented at block 702 in
The WSP 208 may fulfill the role of parameterizing the consumer device server function 702. The parameters to be provided may include the WSP's identifier in the payment system 200, and appropriate cryptographic material, to allow the WSP 208 to form a secure data communication connection with the consumer device server function 702 during execution of a payment transaction.
Execution of a payment transaction may require services of a number of resources within the payment-enabled mobile device 202, such as a file system 704.
The file system may, for example, store files related to coupons, promotional vouchers, customer loyalty points, etc.
Other necessary or desirable resources may fall into the category of applications (block 706), and may include a wallet selection application 708, and an EMV payment application 710, among others. The wallet selection application 708, as will be seen, may function to allow the user 210 to select among payment card accounts (digitalized payment cards) housed in the user's digital wallet. The EMV payment application 710 may provide such functionality as producing a payment token for use in offline-only EMV POI terminals (for such transactions, the WSP would not be involved, and the authentication token provided—as described below—in consumer-device-server-function-to-WSP transactions would not be produced).
A database (block 712,
The consumer device server function 702 is uniquely identified in the payment system 200 through a unique URI, as referred to above. The URI is the root of a namespace tree, such as that depicted in
As seen in
The tree illustrated in
An HTTP web client (such as a client application hosted on the WSP computer 208) may interact with the consumer device server function 702 in the following manner, for example. The web client may ask the consumer device server function 702 for a service through an appropriate HTTP command. The command may encode several imbricated sub-commands that are targeted to resources accessible via the namespace tree. The consumer device server function 702 may dispatch the HTTP command based on the semantic of the command. The consumer device server function 702 may identify all imbricated sub-commands to be further directed to the appropriate resources, and then sequentially sends the identified sub-commands to each relevant resource.
While processing a sub-command, a resource may require an interaction with the user 210. For example, the resource (e.g., the wallet selection application) may need to receive input from the user 210 concerning the user's selection of a preferred card or set of cards to be used in a current payment transaction. As another example, the resource may require the user to perform a CVM (e.g., PIN entry or biometric) in order to produce proof that the user is not an impostor.
Each resource may elaborate its partial processing result corresponding to the set of sub-commands it executed and may return the partial processing result to the consumer device server function 702. The consumer device server function 702 may use the partial processing results received from the various resources to compose the HTTP response to be sent to the web client that made the HTTP command.
The main software features shown in
The interception application software program 902 may serve as a front end of the consumer device server function 702 referred to in connection with
Moreover, if the HTTP client is the WSP computer 208, the interception application software program 902 may establish a secure communication tunnel with the WSP computer 208 by taken such actions as: (a) successful authentication of the WSP computer 208; (b) providing authenticable information to the WSP computer 208 to certify that the payment-enabled mobile device 202 and the consumer device server function 702 are eligible for participation in the payment system 200 and were issued/enrolled by the operator of the WSP computer 208 (i.e., by the wallet service provider in question); and (c) establish secure communications with the WSP computer 208. The resulting communication session will provide encryption, data integrity and data origin authentication of all the data transferred between the payment-enabled mobile device 202 and the WSP computer 208. Various secure tunneling technologies can be used for this purpose, in accordance with the communication security aspects implemented in the payment-enabled mobile device 202 and the WSP computer 208.
Once a secure communication channel has been established between the WSP computer 208 and the consumer device server function 702, the client running in the WSP computer 208 can submit any type of HTTP request to the consumer device server function 702, with imbricated sub-commands to application resources within the payment-enabled mobile device 202.
Establishment of the secure communication channel between the WSP computer 208 and the consumer device server function 702 may involve use of a set of cryptographic keys previously loaded into the payment-enabled mobile device 202 during a personalization process performed by the WSP computer 208 with respect to the interception application software program 902.
In a case where the client making the request is one that runs on the payment-enabled mobile device 202 itself, the interception application software program 902 may filter the sub-commands submitted by the client to limit the client's request to actions such as selecting one or more payment card accounts and corresponding amounts to be charged to the accounts in accordance with options presented in a wallet selection form uploaded from the WSP client to the consumer device server function 702 for purposes of a current transaction. In this case the WSP computer 208 may consider the HTTP response from the consumer device server function 702 (i.e., conveying the wallet selection data as indicated by the user) if and only if such information is coming to the WSP computer 208 via the secure communication channel referred to above and established between the WSP client and the interception application software program 902. In this case, the communication of the wallet selection information, in a suitably secure manner, may be deemed an authentication token submitted for the transaction by the payment-enabled mobile device 202. It will be appreciated that the user's selection of wallet options as communicated via the authentication token may involve interaction between the user and the wallet selection application program 904.
Another action that the interception application software program 902 may permit a client on the payment-enabled mobile device 202 to perform may be a CVM for authentication of the user as the legitimate owner of the payment-enabled mobile device 202.
Still another action that the interception application software program 902 may permit a client on the payment-enabled mobile device 202 to perform may be selection of a communication technology (e.g., NFC, Bluetooth, Wi-Fi, QR code, SMS, USSD, etc.) as the mode of communication available between the payment-enabled mobile device 202 and the merchant POI terminal 204 (
In some embodiments, the interception application software program 902 may function such that other clients (e.g., a client program running on the merchant POI terminal 204) may only send information to an application resource on the payment-enabled enabled mobile device 202. For example, the interception application software program 902 may permit a client running on the merchant POI terminal 204 to send transaction detail data to the contact exchange application software program 906, without requesting processing, and the contact exchange application software program 906/interception application software program 902 may return contact information for the payment-enabled mobile device 202, such as data that identifies the WSP for the user of the payment-enabled mobile device 202, and the URI for the consumer device server function 702 on the payment-enabled mobile device 202.
Turning now to the wallet selection application program 904, the latter may serve as a resource application that receives data communicated from the WSP computer 208 via the secure tunnel established between the interception application software program 902 and the WSP computer 208. This data may include data retrieved by the WSP computer 208 from the digital wallet it maintains for the user of the payment-enabled mobile device 202. This data may be referred to as “wallet form data”, and may be such as is needed to allow the user to interact with a client running on the payment-enabled mobile device 202 to visualize his/her digital wallet as maintained on the WSP computer 208. With this data, the user is able to choose from his/her digital wallet a payment card account (or more than one such account) to be used for a current transaction. (I.e., it is contemplated that the user may pay for the entire transaction with one payment card account in his/her wallet, or alternatively he/she may split the transaction amount for funding by two or more of the payment card accounts represented in his/her digital wallet.)
Depending on the requirements set forth by the payment network (and/or the issuer) in question, the wallet selection application program 904 may require the user to perform a specific CVM. For example, the CVM may call for one or more of the following: (a) entry by the user of an overall wallet access password (not specific to a particular payment card account); (b) entry by the user of the PIN for a particular payment card account selected by the user for the current transaction; and/or (c) submission by the user of biometric input. (As just one example of the latter, where the transaction is to be funded wholly or in part from a social benefits (e.g., a government pension/social security scheme) account, the required CVM may include submission of a biometric that provides “proof of life”—one example of such a biometric would be a spoken utterance by the user to be processed for voice recognition; subsequent discussion herein will describe some examples of voice-recognition-based CVMs that may be provided in accordance with aspects of the present invention.)
The discussion will now turn to the contact exchange application software program 906. The contact exchange application software program 906 may also be a resource application on the payment-enabled mobile device 202 and may serve to permit the user to exchange data with the merchant POI terminal 204. For example, the contact exchange application software program 906 may supply to the merchant POI terminal 204 address data that identifies the (or a) WSP for the user. In some embodiments, this address data may simply be an identifier by which the WSP is recognized or designated in the payment system 200. In addition, the contact exchange application software program 906 may supply to the merchant POI terminal 204 address data for the payment-enabled mobile device 202, such as the above-mentioned URI which serves as an internet address for the consumer device server function 702 (which may ultimately be passed on to the WSP computer 208, via the merchant POI terminal 204 and the PSP/acquirer computer 206).
In terms of data communicated in the other direction, i.e., from the merchant POI terminal 204 to the contact exchange application software program 906, the latter data may include data concerning the present transaction (which may be denoted as “transaction detail data” and which may include the transaction amount, for example), and also may include data concerning the context (“transaction context data”), such as data related to identification of the merchant, the merchant location, and/or the particular merchant POI terminal 204 in question.
To enable the communication between the contact exchange application software program 906 and the merchant POI terminal 204 it may be necessary for there to be agreement on a mode of peer-to-peer communication by which the data is to be exchanged. In some embodiments, the mode of communication may be selected by the user, who may provide input into the payment-enabled mobile device 202 to select, e.g., one of a list of communication modes displayed on the merchant POI terminal 204 as visual icons that are viewable by the user. For example, the communication options may include one or more of NFC, Bluetooth, WiFi, QR code and/or USSD.
As noted before, and among a number of possibilities, the consumer device server function 702 may be configured to operate in accordance with GPNF, as promulgated by GlobalPlatform, and/or in accordance with the SCWS (Smart Card Web Server) standard published by OMA. Also as noted above, hardware options for the payment-enabled mobile device 202 may include a generally conventional smartphone, e.g., with the consumer device server function 702 running on an IC card installed in the smartphone.
At a higher level of the software in the merchant POI terminal 204 (reference numeral 1002 in
Relative to the contact exchange terminal application 1004 and the interaction with the payment-enabled mobile device 202, the contact exchange terminal application 1004 may establish a handshake with the contact exchange application software program 906 in the payment-enabled mobile device 202 to allow the following data exchange: (a) (from merchant POI terminal 204 to payment-enabled mobile device 202) transmission of the transaction detail data for the current transaction and the transaction context (merchant context) data for the current transaction; and (b) (from payment-enabled mobile device 202 to merchant POI terminal 204) transmission of the URI for the consumer device server function 702 and the identifier for the user's WSP.
Relative to the PSP/acquirer application 1006 and the interaction with the PSP/acquirer computer 206, the PSP/acquirer application 1006 may establish an internet connection with the PSP/acquirer computer 206 using, for example, TLS (transport layer security) tunneling via the internet to enable the following exchanges of data: (a) (from merchant POI terminal 204 to PSP/acquirer computer 206) the PSP/acquirer application 1006 transmits the contact details for the payment-enabled mobile device 202 (i.e., WSP identifier and URI for the consumer device server function 702) and the same transaction detail data and transaction context data that the contact exchange terminal application 1004 provided to the contact exchange application software program 906; and (b) (from PSP/acquirer computer 206 to merchant POI terminal 204; after interaction between the PSP/acquirer computer 206 and the WSP computer 208) the PSP/acquirer application 1006 running in the merchant POI terminal 204 receives a transaction result (e.g., approve/decline), to indicate that the purchase transaction may be completed.
At a lower level of the software in the merchant POI terminal 204 (reference numeral 1008 in
At block 1102 in
At 1104 in
At 1106, the merchant POI terminal 204 may transmit the transaction detail data (e.g., amount, currency, date, etc.) to the payment-enabled mobile device 202, and at the same time the merchant POI terminal 204 may transmit transaction context data to the payment-enabled mobile device 202. For example, the transaction context data may include a merchant identifier and location (which may be parameters stored in the merchant POI terminal 204). In addition, the transaction context data may include a unique transaction number (UTN). In some embodiments, the merchant POI terminal 204 may generate a fresh UTN for each transaction it handles. For example, the merchant POI terminal 204 may calculate the UTN as a hash of such information as the merchant identifier, the transaction location, a transaction counter value, and possibly other information as well. The merchant POI terminal 204 may operate to increment the transaction counter value with each transaction that occurs at the merchant POI terminal 204.
At 1108, the payment-enabled mobile device 202 may transmit data to the merchant POI terminal 204 to permit the payment-enabled mobile device 202 to be contacted for a subsequent stage (token passing) of the transaction process. As mentioned before, the data transmitted from the payment-enabled mobile device 202 to the merchant POI terminal 204 may be address data, in particular: (a) the identifier for the WSP that stores the digital wallet for the user (or at least one of the user's digital wallets), and (b) the URI for the consumer device server function 702 hosted in the payment-enabled mobile device 202. (It is worth noting at this point that in some embodiments of the invention and of the payment-enabled mobile device 202, the user may be prompted to select a WSP and/or a digital wallet from among a plurality of his/her WSPs/digital wallets before step 1108 occurs and/or the user may make such a selection without being prompted and perhaps while approaching the point-of-sale counter. It is within the contemplation of aspects of this invention that the payment-enabled mobile device 202 may run a WSP-selection app or the like for this purpose.)
It should also be noted that the communication channel 216 (
At 1110 in
Following block 1110 in
In addition, the PSP/acquirer computer 206 may check the identification of the WSP to confirm that the WSP is validly enrolled in the payment system 200. This may occur in a manner that is analogous to a conventional operation in which an acquirer may confirm the validity of a payment network for which a PAN-based authorization request is to be submitted.
Assuming that the checks all result in satisfactory findings, block 1114 may follow decision block 1112 in the process of
Block 1116 follows block 1114. At block 1116, the WSP computer 208 receives and processes the data transmitted by the PSP/acquirer computer 206. In particular, the WSP computer 208 may generate a transaction identifier, which may for example be formed from the merchant identifier (corresponding to the merchant that operates the merchant POI terminal 204) plus the UTN provided in the message received by the WSP computer 208 from the PSP/acquirer computer 206. Further as part of the operation of block 1116, the WSP computer 208 may store the transaction data (transaction detail data and transaction context data), as received from the PSP/acquirer computer 206, in association with the transaction identifier generated by the WSP computer 208. Still further as part of the operation of block 1116, the WSP computer 208 may read, from the data supplied by the PSP/acquirer computer 206, the URI for the consumer device server function 702 hosted in the payment-enabled mobile device 202. Next, the WSP computer 208 may verify that the URI in question is not blacklisted and that the user in question has a valid subscription to the wallet services provided by the WSP that operates the WSP computer 208.
Block 1118 follows block 1116. At block 1118, the WSP computer 208 goes on to retrieve the wallet entry for the user of the payment-enabled mobile device 202, as identified by the above-mentioned URI. With the data from the user's wallet entry (i.e., the user's digital wallet maintained by the WSP computer 208), the WSP computer 208 forms wallet form data to be sent to the consumer device server function 702 hosted in the payment-enabled mobile device 202. The wallet form data will present information to the user to permit him/her to choose among the payment card accounts in his/her digital wallet to select the account(s) to be used for the current transaction. If the user wishes to use more than one of his/her accounts and to distribute the transaction amount among the selected accounts, the wallet form data may allow the user to indicate his/her choices in this regard as well.
Block 1120 follows block 1118. At block 1120, the WSP computer 208 uses the URI for the consumer device server function 702 hosted in the payment-enabled mobile device 202 to initiate formation of a secure communication channel (channel 222 in
Referring again to the flowchart of
Block 1126 follows block 1124. As part of the operation of block 1126, the interception application software program 902 generates an authentication token for the transaction. The interception application software program 902 may generate the authentication token as a Message Authentication Code (MAC) on the basis of the account selection data, and the transaction data (transaction detail data and transaction context data) that the payment-enabled mobile device 202 had received at block 1106 (
Continuing to refer to
Block 1130 follows block 1128. It will initially be assumed for the purpose of describing block 1130 that the user 210 had selected only one payment card account from his/her digital wallet to fund the current transaction. Accordingly, at 1130 the WSP computer 208, acting substantially like a conventional acquirer, uses the PAN for the user-selected payment card account (as stored in and retrieved from the user's digital wallet) to route a payment network authorization request via the indicated payment network (assumed to be the payment network 110 shown in
Now, for an alternate description of block 1130, it will be assumed that the user selected more than one payment card account from his/her digital wallet, for distribution of the transaction amount among the selected payment card accounts. In this case, the account selection data provided by the payment-enabled mobile device 202 to the WSP computer 208 may include two or more lines, with each line corresponding to a respective user-selected account and with each line indicating the portion of the transaction amount to be charged to the respective account. For each such account, the WSP computer 208 may issue a respective authorization request via the appropriate payment network (i.e, more than one payment network may be involved in the current transaction, although only one payment network is depicted in
Continuing to refer to
At block 1134, the WSP computer 208 transmits an acknowledgment message to the PSP/acquirer computer 206 to confirm that payment has been duly made for the current transaction. Block 1136 then follows. At block 1136, the PSP/acquirer computer 206 transmits an acknowledgment message to the merchant POI terminal 204 to confirm that payment has duly been made for the current transaction. Block 1138 then follows, at which the purchase transaction at the retail store is completed. For example, the merchant POI terminal 204 may display to the merchant's sales associate an indication that payment has been acknowledged/confirmed, and may print a suitable receipt for the customer/mobile device user 210. The customer may then leave the retail store with the purchased merchandise and the receipt.
The payment system 200, as described herein, may provide enhanced security for sensitive information such as payment card account PANs as compared to conventional payment systems in which the merchant reads the PAN from a card or other device at the point of purchase. In the payment system 200, the merchant never has possession of the customer's PAN; accordingly, a mass data breach at the merchant level, with attendant difficulties and potential exposure to fraud, may be highly unlikely or impossible with the payment system 200.
Moreover, because the PAN and related data do not pass through the POS terminal (also referred to as the POI terminal) in the payment system 200, the cost of the POS terminal may be substantially reduced as compared to conventional POS equipment currently in use. For example, in the POI terminal as described herein, there may be no need for the type of complex cryptographic calculations that are employed in some conventional POS equipment. Accordingly the POI terminal as described herein may be simplified in that it may not need to have either a fast main processor and/or a specialized cryptographic processor, such as may be included in conventional POS equipment. Moreover, with this arrangement PCI compliance may not be required for the POI terminal There may also be savings with respect to the software that programs the POI terminal as described herein in that the software itself may be less complex than conventional POS equipment software, and may be subject to less complex certification processes than are conventionally employed in many cases for POS equipment software.
Further, in other hardware respects the POI terminal described herein may be simplified, in that there may be no need for such components as a secure keyboard, a secure biometric sensor or a secure display device. In general, tampering detection and tampering reaction mechanisms may not be needed in the POI terminal described herein, because the POI terminal no longer handles payment application processes, but rather is a protocol adapter for exchanging basic information between the customer and the merchant, while also relaying basic information from the consumer device server function 702 hosted in the payment-enabled mobile device 202 to the PSP/acquirer and on to the WSP.
It is another advantage of the payment system 200 that, in contrast to other payment token systems that have been proposed, there are potentially an unlimited number of authentication tokens available as the same have been described in this disclosure.
Still further, since the payment-enabled mobile device 202 provides a representation of transaction data to the WSP computer 208, for comparison by the WSP computer 208 with the transaction data received from the merchant POI terminal 204 via the PSP/acquirer computer 206, there is enhanced protection against fraudulent unsolicited transactions.
In the above discussion of the embodiment shown in
Referring again to the case where the purchase transaction occurs face-to-face, the merchant POI terminal 204 and the payment-enabled mobile device 202 may be able to interact directly via a bidirectional exchange. To establish the bidirectional exchange, the merchant POI terminal 204 and the payment-enabled mobile device 202, acting as peer devices, may perform an automatic setup of a bidirectional channel between the two devices. This could occur in a number of ways, depending on the features present in the devices. For example, this could be done directly through an NFC peer-to-peer data exchange. This may be an advantageous approach in that it takes advantage of existing smartphone capabilities.
However, in other embodiments, or if additional features require a larger volume of data to be exchanged, the bidirectional communication could occur through a process where the devices cooperate via NFC to transfer over to another technology such as Bluetooth or WiFi.
As another alternative, and as suggested above (and in either a face-to-face or remote transaction situation), the merchant POI terminal 204 and the payment-enabled mobile device 202 may interact outside a communication channel. For example, via USSD or SMS, the payment-enabled mobile device 202 may submit the information referred to in connection with block 1108 to a phone number visually displayed on the merchant POI terminal 204. As another possibility, the payment-enabled mobile device 202 (assuming it includes a camera, as many smartphones do), may capture an image of a QR code (quick response code) as displayed by the merchant POI terminal 204 (or downloaded from the merchant, in the case where the merchant POI terminal 204 is an e-commerce server).
In the embodiment shown in
In
A first level of the clearing process is indicated at 1206, and features a WSP 1208, having a WSP pool account 1210. A second level of the clearing process is indicated at 1212, and features settlement accounts 1214 belonging to PSPs/acquirers.
Also shown in
One of the payment card issuer settlement accounts 1202 may be associated with the issuer 112 shown in
It will be understood that two or more different payment networks are represented in the payment network settlement accounts 1204 shown in
Block 1210 shown in
At the first level 1206 of the clearing process, the WSP 1208 has a role like a “mega” acquirer, and each PSP/acquirer represented in
At the second level 1212 of the clearing process, each acquirer manages its respective settlement account 1214 to clear credits due to its subscriber merchants. In particular, each of the PSP/acquirer settlement accounts 1214 receives clearing credits from the WSP pool account 1210, and those credits are further distributed to the merchant accounts 1216.
The layered clearing process as illustrated in
The payment system 200a shown in
The VAS wallet services component 1308 may maintain the VAS/benefit funds digital wallets for users of the payment system 200a.
Also shown in
The VAS WSP computer 1302, the benefits system operator computer 1310 and the PSP/acquirer computer 206 may all be constituted by conventional computer hardware, such as that described above in connection with the description of the WSP computer 208 hardware shown in
The VAS WSP computer 1302 may store (in a storage medium such as those referred to above in connection with
In some embodiments, the wallet services provided by the VAS WSP computer 1302 may entail maintaining one or more digital wallets per user/subscriber for the services of the VAS WSP. In some embodiments, for example, the user 210 may have stored for his/her benefit in the VAS WSP computer 1302 one or more of the following: (a) a rewards wallet, for loyalty points, coupons, promotional payments, etc.; (b) a medical insurance wallet for medical, dental, long term care, and other like benefits; (c) a casualty insurance wallet; and (d) a social benefits wallet (e.g., for social welfare payments, government pension plan benefits, etc.).
The process of
At block 1402 in
Accordingly, the PSP/acquirer computer 206a may then contact the wallet service provider that maintains the selected wallet, assumed in this case to be the operator of the VAS WSP computer 1302. Thus, the PSP/acquirer computer 206a transmits a request to the VAS WSP computer 1302 to download wallet form data for the selected wallet.
The process of
In some embodiments, the account selection signal may be transmitted from the payment-enabled mobile device 202 via the secure communication channel 222 to the WSP computer 208. The WSP computer 208 may relay the account selection signal to the PSP/acquirer computer 206a, which in turn transmits the account selection signal to the VAS WSP computer 1302.
Then, at block 1406 in
The benefit computation method block 1502 may receive as an input (as indicated at 1504) the total amount that is to be paid for the current transaction (i.e., the transaction amount). The output (reference numeral 1506) from the benefit computation method block 1502 may be the maximum amount that the transaction is eligible to receive in funding from the selected funding account. At a node indicated by reference numeral 1508, an input 1510 may be received to indicate the user's preference that less than the entire available benefit be drawn from the selected funding account. (That is, the process of
A consequence of the process of
Following block 1408 in
With the second digital wallet having been selected, the process of
In the above discussion of
As noted above (e.g., in connection with discussion of block 1124 in
In
The reference data for the biometric CVM, in this embodiment, may be stored at the WSP computer 208, as indicated by block 1608 in
Assuming that the decision parameters are satisfied, the output from the decision function 1616 may be authorization of the transaction, as indicated at 1620.
With the arrangement shown in
Also, biometric verification block 1702 in
In operation of the apparatus of
Based on the biometry identifier, the WSP computer 208 chooses the appropriate biometric data processing algorithm for the raw biometric data and the appropriate stored biometric reference data repository. Within the selected biometric data repository, the particular set of biometric reference data for the user in question may be retrieved based on the URI for the consumer device server function 702 in the payment-enabled mobile device 202. The biometric verification block 1702 then applies the biometric verification process illustrated in
In operation of the apparatus of
Using the cell-phone telephone number, the payment gateway function 1808 retrieves the digital wallet for the user from the wallet partition unit 1806, and from the user's digital wallet the WSP computer 208a generates wallet form data, which is supplied to the IVR unit 1802 together with the cell-phone telephone number. The IVR unit 1802 calls the cell-phone 1810 and audibly prompts the user to make an account selection based on the wallet form data. The user responds by spoken utterance into the cell-phone 1810 to indicate his/her payment card account selection. The voice utterance is sent from the cell-phone 1810 to the voice recognition unit 1804 of the WSP computer 208a. The voice recognition unit performs both of the following on the basis of the voice utterance—(a) identifying the user based on a voice sample reference previously stored in a reference data repository on the WSP computer 208a (where the reference was associated with the cell-phone telephone number)—i.e., in effect CVM; and (b) detecting the user's selection of a payment card account from the user's digital wallet based on speech content recognition as applied to the voice utterance received from the cell-phone 1810. If the CVM is found “valid”, then the account selection is passed on to a wallet unit in the WSP computer 208a. The wallet unit then triggers an authorization request for the selected payment card account (or more than one authorization request, if the user elected to split payment among two or more of his/her payment card accounts). The WSP computer 208a then receives an authorization response from the payment card account issuer (or more than one, if more than one account is being used). The result of the authorization response is provided to the payment gateway function 1808 of the WSP computer 208a. If the transaction is approved, the payment gateway provides an acknowledgment message accordingly to the merchant e-commerce site, such that the transaction is successfully concluded.
Returning the discussion now to the payment-enabled mobile device 202, it has been noted above that in some embodiments the device 202 may be physically constituted by smartphone hardware. Alternatively, however, the device 202 may be an IC card of the type that includes a display and keyboard. In such a case, for example, the device 202 may communicate with the WSP computer 202 via the POI terminal In still other embodiments, the IC card need not have a keyboard or display. The IC card, which may be a contactless card or a contact card, may be in communication with the POI terminal, which may provide a user interface for the card and for selection of wallet account(s).
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.
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.
Claims
1. A method comprising:
- receiving a first message at a wallet service provider computer, the first message including (a) transaction detail data indicative of a transaction originated at a point of interaction (POI) device, and (b) transaction context data for the transaction;
- receiving a second message at the wallet service provider computer, the second message including (i) a copy of the transaction detail data, and (ii) a copy of the transaction context data;
- verifying, by the wallet service provider computer, that the copy of the transaction detail data matches the transaction detail data included in the first message and that the copy of the transaction context data matches the transaction context data included in the first message.
2. The method of claim 1, wherein the wallet service provider computer receives the second message via a cryptographically-secured internet communication channel between the wallet service provider computer and a server function present in a payment-enabled mobile device.
3. The method of claim 2, wherein the wallet service provider computer receives the first message from an acquirer financial institution.
4. The method of claim 2, wherein the wallet service provider computer receives the first message from a merchant that operates the POI device.
5. The method of claim 1, wherein:
- the transaction detail data includes a transaction amount and a transaction date, and
- the transaction context data includes (x) merchant identification data for identifying a merchant that operates the POI device; (y) location data for identifying a location of the POI device; and (z) a unique transaction number generated for the transaction by the POI device.
6. The method of claim 5, wherein the first message includes device address data that indicates an internet address for said server function present in the payment-enabled mobile device.
7. A non-transitory medium having program instructions stored thereon, the medium comprising:
- an interception application software program for providing a server function for receiving service requests from a remote device; and
- a contact exchange application software program for (a) exchanging communications with the interception application software program, and (b) providing contact data to a device in proximity to the medium, the contact data including (i) data that identifies a wallet service provider, and (ii) data that represents an internet address for the interception application software program.
8. The medium of claim 7, further comprising:
- a wallet selection application program for (x) exchanging communications with the interception application software program, and (y) receiving input from a user to select a payment card account from among a plurality of payment card accounts represented in a digital wallet maintained for the user by the wallet service provider.
9. The method of claim 8, wherein the remote device is a computer operated by the wallet service provider.
10. The medium of claim 9, wherein the wallet selection application software program is configured to receive from the remote device, via the interception application software program, data that represents said plurality of payment card accounts.
11. The medium of claim 10, wherein the interception application software program is configured to generate and transmit to the remote device a message authentication code based at least in part on (a) said user input for payment card account selection, (b) transaction data received from the device in proximity to the medium, and (c) transaction context data received from the device in proximity to the medium.
12. The medium of claim 11, wherein the contact exchange application software program is configured to receive the transaction data and the transaction context data and to provide the transaction data and the transaction context data to the interception application software program for forwarding to the remote device.
13. The medium of claim 12, wherein the medium is part of a mobile device.
14. The medium of claim 13, wherein the device in proximity to the medium is a point of interaction (POI) device that is in proximity to the mobile device.
15. The method of claim 14, wherein the contact exchange application software program is operative to select a mode of communication between the mobile device and the POI device.
16. The method of claim 13, wherein the wallet selection application program is operative to require a user of the mobile device to perform a cardholder verification method (CVM).
17. A method comprising:
- receiving, in a pool account computer operated by a wallet service provider, payment network clearing credits from payment card accounts; and
- distributing the payment network clearing credits, from the pool account computer, among a plurality of acquirer financial institutions, the distributed credits for further distribution from the acquirer financial institutions to merchants that accepted the payment card accounts.
18. The method of claim 17, wherein the receiving step includes receiving the credits from issuers of the payment card accounts via at least one payment network clearing account.
19. The method of claim 17, wherein the payment card accounts include:
- a first plurality of payment card accounts issued in connection with a first payment network; and
- a second plurality of payment card accounts issued in connection with a second payment network that is different from the first payment network.
20. The method of claim 17, wherein the received payment network clearing credits correspond to payment network transactions for which the wallet service provider requested authorization.
21. An apparatus comprising:
- a processor; and
- a memory in communication with the processor, the memory storing program instructions, the program instructions controlling the processor to perform operations as follows:
- receiving a first message, the first message including (a) transaction detail data indicative of a transaction originated at a point of interaction (POI) device, and (b) transaction context data for the transaction;
- receiving a second message, the second message including (i) a copy of the transaction detail data, and (ii) a copy of the transaction context data; and
- verifying that the copy of the transaction detail data matches the transaction detail data included in the first message and that the copy of the transaction context data matches the transaction context data included in the first message.
22. The apparatus of claim 21, wherein the second message is received via a cryptographically-secured internet communication channel with a server function present in a payment-enabled mobile device.
23. The apparatus of claim 22, wherein the first message is received from an acquirer financial institution.
Type: Application
Filed: Aug 26, 2014
Publication Date: Sep 10, 2015
Inventor: Cristian Radu (Beauvechain)
Application Number: 14/469,380