[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

US20090094123A1 - Payment services provider methods in connection with personalized payments system - Google Patents

Payment services provider methods in connection with personalized payments system Download PDF

Info

Publication number
US20090094123A1
US20090094123A1 US11/964,343 US96434307A US2009094123A1 US 20090094123 A1 US20090094123 A1 US 20090094123A1 US 96434307 A US96434307 A US 96434307A US 2009094123 A1 US2009094123 A1 US 2009094123A1
Authority
US
United States
Prior art keywords
merchant
customer
payment card
card account
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/964,343
Inventor
Patrick Killian
Sandeep Malhotra
Andrew D. Campbell
Shoon Wong
Dana Lorberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard International Inc
Original Assignee
Mastercard International Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Priority to US11/964,343 priority Critical patent/US20090094123A1/en
Assigned to MASTERCARD INTERNATIONAL, INC. reassignment MASTERCARD INTERNATIONAL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WONG, SHOON, KILLIAN, PATRICK, MALHOTRA, SANDEEP
Assigned to MASTERCARD INTERNATIONAL, INC. reassignment MASTERCARD INTERNATIONAL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CAMPBELL, ANDREW D., LORBERG, DANA
Publication of US20090094123A1 publication Critical patent/US20090094123A1/en
Priority to US14/039,180 priority patent/US20140032381A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855Payment architectures involving remote charge determination or related payment systems involving a third party
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/204Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3221Access to banking information through M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229Use of the SIM of a M-device as secure element
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/10Tax strategies

Definitions

  • Embodiments disclosed herein relate to payment systems.
  • some embodiments relate to methods, apparatus, systems, means and computer program products for implementing a payment system on the basis of a payment card system.
  • FIG. 1 schematically illustrates a typical transaction, as carried out in a payment system 100 .
  • a customer visits a retail store (not shown) operated by a merchant, selects goods (not shown) that he/she wishes to purchase, carries the goods to the merchant's point of sale terminal 104 , and presents his/her payment card 102 to the point of sale terminal 104 .
  • the point of sale terminal 104 reads the customer's payment card account number from the payment card 102 , and then sends an authorization request to an acquirer financial institution (FI) 106 with which the merchant has a relationship.
  • FI acquirer financial institution
  • the authorization request includes the payment card account number and the amount of the transaction, among other information.
  • the authorization request is routed via a payment card system 108 (which may be, for example, the well-known Banknet system operated by the assignee hereof) to the issuer financial institution 110 that issued the customer's payment card 102 .
  • Arrows 112 , 114 and 116 trace the path of the authorization request from the POS terminal 104 to the issuer 110 .
  • the issuer FI 110 transmits a favorable authorization response to the point of sale terminal 104 through the payment card system 108 and via the acquirer FI 106 .
  • the path of the authorization response from the issuer FI 110 to the POS terminal 104 is traced by arrows 118 , 120 , 122 .
  • the transaction at the point of sale terminal 104 is then completed and the customer leaves the store with the goods.
  • a subsequent clearing transaction initiated by the merchant results in a transfer of the transaction amount from the customer's payment card account 124 to an account that belongs to the merchant.
  • the customer's payment card account 124 may be, for example, either a debit card account or a credit card account. In the former case, the clearing transaction results in the funds being debited directly from the account 124 . In the latter case, the clearing transaction results in a charge being posted against the account 124 , and the charge subsequently appears on the customer's monthly credit card statement.
  • a so-called merchant processing system may be interposed between the POS terminal and the acquirer FI.
  • a merchant processing system may be operated by or on behalf of the merchant to form part of the communications path between the acquirer FI and a considerable number of POS terminals operated by the merchant.
  • a third party transaction processing service may operate to handle payment card transactions on behalf of the acquirer and on behalf of a large number of other like financial institutions.
  • a payment transaction an existing facility of a payment card system, referred to as a “payment transaction”, may be utilized to provide more convenient and flexible handling of purchases of goods and other exchanges of value.
  • the transactions described herein may be conducted such that the customer need not disclose his/her payment card account number to the merchant. This may, in at least some circumstances, enhance the security of the customer's payment card account and lessen the possibilities for misappropriation of the payment card account number.
  • novel use of payment transactions disclosed herein may also cause transactions to be conducted in such a manner that the customer may be made fully aware of all transaction details before the customer initiates the payment transaction. This may help to protect the customer from unintentionally authorizing erroneous or fraudulent payment card transactions, and may reduce the number of occasions in which transactions need to be reversed.
  • transaction techniques disclosed herein may save the merchant from having to enter into a relationship with an acquirer financial institution. This may be particularly advantageous for very small merchants or for merchants who do not have fixed places of business. Moreover, elimination of the “acquirer” function, as proposed herein, may result in savings in bank fees charged to merchants.
  • the present inventors have also recognized that the novel transaction techniques proposed herein present opportunities for novel value-added services which may be provided to customers, merchants and/or financial institutions.
  • FIG. 1 is a block diagram that illustrates a conventional payment system.
  • FIG. 2 is a block diagram that illustrates a transaction-handling system in accordance with aspects of the present invention.
  • FIG. 3 is a block diagram that illustrates a point of sale terminal that is shown in FIG. 2 .
  • FIG. 4 is a block diagram that illustrates a customer's mobile telephone that is shown in FIG. 2 .
  • FIG. 5 is a block diagram that illustrates a transaction-handling system according to some other embodiments.
  • FIG. 6 is block diagram that illustrates another embodiment of a transaction-handling system.
  • FIG. 7 is a block diagram representation of a computer that provides payment services in the system of FIG. 5 or 6 .
  • FIG. 8 is a flow chart that illustrates a process that may be performed by a point of sale terminal or other merchant device in connection with a transaction handled as in FIG. 2 , FIG. 5 or FIG. 6 .
  • FIG. 9 is a flow chart that illustrates a process that may be performed by a customer's mobile device in connection with a transaction handled as in FIG. 2 , FIG. 5 or FIG. 6 .
  • FIG. 10 is a flow chart that illustrates a process that may be performed by the computer of FIG. 7 .
  • FIG. 11 is a block diagram that illustrates a bill payment system according to some embodiments.
  • FIG. 12 is a flow chart that illustrates a process that may be performed by a payment services provider computer in the system of FIG. 11 .
  • FIG. 13 is a block diagram that illustrates a payroll disbursement system according to some embodiments.
  • FIG. 14 is a flow chart that illustrates a process that may be performed by a payment services provider computer in the system of FIG. 13 .
  • FIG. 15 is a block diagram that illustrates still another embodiment of a transaction-handling system.
  • FIG. 16 is a block diagram that illustrates yet another embodiment of a transaction-handling system.
  • FIG. 17 is a flow chart that illustrates a process that may be performed in a point of sale terminal that may serve as the merchant device shown in FIG. 2 .
  • a payment card system payment transaction initiated from a customer's device is utilized to consummate a purchase of goods or services.
  • the transaction information such as an amount due for the purchase, and a code that identifies the merchant, may be entered into or transmitted to the customer's device.
  • the transaction information may be displayed by a merchant's device (e.g., a POS terminal) to be read by the customer and manually entered by the customer into the customer's device.
  • the customer may operate his/her device to initiate a request for a payment transaction via the issuer of the customer's payment card account.
  • the request may direct the customer's issuer to implement a transfer of funds from the customer's payment card account to the merchant's payment card account.
  • the vehicle for the funds transfer may be a conventional payment transaction of the type now supported by at least one payment card system.
  • the issuer of the customer's payment card account may cause the payment transaction to be routed via the payment card system to the issuer of the merchant's payment card account to be credited to the merchant's payment card account.
  • the merchant's issuer may confirm to the merchant that the funds transfer has occurred (or is assured to occur subsequently during conventional clearing operations), and in response to receiving the confirmation, the merchant may transfer ownership of the goods to the customer, or may accept the confirmation as payment for services rendered or to be rendered to the customer.
  • the payment card transaction enters the system via a device operated by the customer and is initiated for routing from the customer's issuing financial institution, rather than originating from the merchant's POS terminal and the acquiring financial institution.
  • a payment services provider computer may facilitate and/or relay communications between the merchant's device and the customer's device, and/or between the customer's device and the customer's issuer, and/or between the merchant's issuer and the merchant.
  • the payment services provider computer may be operated by the payment card organization (e.g., the assignee hereof) that routes payment transactions from customer issuers to merchant issuers and also routes purchase transactions from acquirers to issuers.
  • FIG. 2 is a block diagram that illustrates a transaction process in accordance with aspects of the present invention.
  • the various components shown in FIG. 2 may be a subset of a larger system, indicated generally by reference numeral 200 , for facilitating payments to merchants via credit cards, debit cards and the like.
  • reference numeral 200 may be a subset of a larger system, indicated generally by reference numeral 200 , for facilitating payments to merchants via credit cards, debit cards and the like.
  • reference numeral 200 for facilitating payments to merchants via credit cards, debit cards and the like.
  • only components of system 200 that operate with respect to a single transaction are shown.
  • the system 200 includes a merchant device 202 , which may for example be a POS terminal or a suitably programmed mobile telephone or PDA (personal digital assistant) with communication capabilities.
  • a merchant device 202 may for example be a POS terminal or a suitably programmed mobile telephone or PDA (personal digital assistant) with communication capabilities.
  • PDA personal digital assistant
  • the latter two possible embodiments of the merchant device may for example be particularly appropriate for merchants who operate without a fixed place of business. Examples of such merchants may be flea market sellers, artisans and crafters who sell their handiwork at craft fairs, itinerant merchants or merchants in third world marketplaces.
  • the merchant device is a POS terminal
  • the latter may operate for the most part in a conventional manner or may alternatively have functionality that actively contributes to the novel transaction flow illustrated in FIG. 2 .
  • the POS terminal may be operated in any type of business establishment or retail store, including a “mom and pop” operation all the way up to a big box store that is part of a mega retail chain.
  • the merchant device may be installed in a store such as a small antiques or collectibles shop or the like in which the low volume of transactions may weigh against the expense and paperwork requirements involved in entering into a merchant-acquirer relationship with an FI.
  • the merchant device 202 may display transaction information to be read by the customer (not shown) and manually inputted by the customer into his/her mobile device 204 .
  • the merchant device may display the total amount due for the transaction, and a merchant identification number.
  • the merchant ID may be permanently displayed on a sticker affixed to the merchant device 202 .
  • the merchant identification number may be the account number that identifies the merchant's payment card account to which payment transactions are to be routed. In other embodiments the merchant identification number may require translation into such an account number, e.g., in a manner as described below. If the merchant identification number is the merchant's payment card number, steps may be taken to prevent misuse of the account number.
  • the account corresponding to the account number may be enabled only to have funds transfers credited thereto, but not to receive charges via the payment card system, and with any transfers out of the account in question going into a companion account, with a different number, from which charges may be made.
  • the merchant identification number may in some embodiments be the merchant's mobile telephone number or another mobile identifier; this may be particularly convenient where the merchant device 202 is a mobile telephone.
  • the merchant device 202 may have capabilities for transmitting the transaction information to the customer device 204 .
  • the transmitting of the transaction information from the merchant device 202 to the customer device 204 may be via wireless communication such as NFC (near field communication) or alternatively may be via a mobile telephone network using text messaging or the like.
  • the customer's mobile device 204 may for example be a mobile telephone with capabilities for initiating payment transactions in a payment card system. Operation of a mobile telephone to initiate funds transfers via a payment card system is for example described in commonly assigned U.S. patent application Ser. No. 11/836,945, filed Aug. 10, 2007, entitled “Payment Card Based Remittance System with Designation of Recipient By Mobile Telephone Number”, which is incorporated herein by reference.
  • the customer's mobile device 204 may be a PDA with communication capabilities.
  • the customer's mobile device may initiate a payment transaction by interacting with a website operated by a payment services provider or by the issuer of the customer's payment card account.
  • FIG. 2 also shows, as included in the system 200 , an issuer financial institution 206 which issued the customer's payment card account 208 , a payment system 210 (such as the Banknet system referred to above) for routing transactions from issuer to issuer (and also, e.g., from acquirers to issuers), and an issuer financial institution 212 which issued the merchant's payment card account 214 .
  • Blocks 206 and 212 should also be understood to represent, respectively, computer systems operated by or on behalf of the customer issuer FI and the merchant issuer FI.
  • Arrows 216 , 218 , 220 trace the path of the payment transaction, requested from the customer's mobile device 204 , as routed from the customer issuer 206 , via the payment system 210 to the merchant issuer 212 .
  • Arrows 222 , 224 and 226 trace the path of acknowledgement messages from the merchant issuer 212 via the payment system 210 and the customer issuer 206 to the customer's mobile device 204 .
  • Arrow 228 represents a confirmation message sent from the merchant issuer 212 to the merchant device 202 to confirm that the payment transaction to pay for the pending sale has or will be credited to the merchant account 214 .
  • the merchant may allow the sale or other exchange of value to be completed.
  • the system 200 may include numerous issuing FIs all connected to the payment system 210 , a large number of merchant devices 202 and a very large number of customer mobile devices.
  • the system 210 preferably also operates in accordance with the conventional purchase transaction model illustrated in FIG. 1 , and thus may include a considerable number of acquirer FIs as well. Of course, many if not all acquirer FIs may also be issuer FIs.
  • FIG. 3 is a block diagram of a POS terminal as provided in accordance with aspects of the invention to serve (in some embodiments) as the merchant device 202 shown in FIG. 2 .
  • the POS terminal 202 may be largely or entirely conventional in its hardware aspects. Nevertheless, the POS terminal 202 may be programmed in accordance with the aspects of the present invention to provide functionality as described herein.
  • the POS terminal may include a processing element (or elements) such as the processor 302 shown in FIG. 3 .
  • the processor 302 may for example be a conventional microprocessor, and may operate to control the overall functioning of the POS terminal 202 .
  • the POS terminal may also include conventional peripheral components, in communication with and/or controlled by the processor 302 , such as: (a) a keypad 304 for receiving input from the human operator of the POS terminal; (b) a barcode reader 306 for reading product barcodes from products brought to the terminal for purchase; (c) a cash drawer 308 for storing cash received from customers; (d) a magnetic stripe reader 310 for reading payment card account numbers and related information from magnetic stripe payment cards; (e) one or more displays 312 for providing output (e.g., identifying products presented for purchase and their prices, indicating sales tax due, indicating transaction subtotals and totals, etc.); (f) a printer 314 for printing out sales receipts; (g) a wireless communication terminal/
  • the communication controller may be provided to allow the POS terminal 202 to transmit and receive text messages or the like via a mobile telephone network (not shown).
  • the POS terminal 202 may include one or more memory and/or data storage devices (indicated collectively at 320 ), 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) 320 may store software and/or firmware that programs the processor 302 and the POS terminal 202 to perform functionality as described herein. Further, the POS terminal may include one or more housings (not shown) which contain and/or support one or more of the other components shown in FIG. 3 .
  • components 310 , 316 may be integrated in a single unit, and may include a display/touch screen to allow for user interaction.
  • FIG. 4 is a block diagram of an example mobile telephone which may serve as the customer's mobile device 204 shown in FIG. 2 .
  • the mobile telephone 204 shown in FIG. 4 may also (but need not) have capabilities for functioning as a contactless payment device.
  • the mobile telephone 204 may be entirely conventional, and indeed in its software aspects it also may be conventional, and may provide novel functionality as described herein through interaction (via a conventional browser) with a web page that supports initiation of payment transactions. In other embodiments, however, novel functionality as described herein may result at least partially from software and/or firmware that programs the mobile telephone 204 .
  • the mobile telephone 204 may include a conventional housing (indicated by dashed line 402 ) that contains and/or supports the other components of the mobile telephone 204 .
  • the mobile telephone 204 further includes conventional control circuitry 404 , for controlling over-all operation of the mobile telephone 402 .
  • the control circuitry 404 is suitably programmed to allow the mobile telephone 204 to engage in data communications and/or text messaging with other devices, and to allow for interaction with web pages accessed via browser software, which is not separately shown.
  • Other components of the mobile telephone 204 which are in communication with and/or controlled by the control circuitry 404 , include: (a) one or more memory devices 406 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module) card 408 ; (c) a conventional keypad 410 (or touch screen) for receiving user input; and (d) a conventional display 412 (or, again, touch screen) for displaying output information to the user.
  • SIM subscriber identification module
  • the mobile telephone 204 also includes conventional receive/transmit circuitry 416 that is also in communication with and/or controlled by the control circuitry 404 .
  • the receive/transmit circuitry 416 is coupled to an antenna 418 and provides the communication channel(s) by which the mobile telephone 204 communicates via the mobile network (not shown).
  • the mobile telephone 204 further includes a conventional microphone 420 , coupled to the receive/transmit circuitry 416 .
  • the microphone 420 is for receiving voice input from the user.
  • a loudspeaker 422 is included to provide sound output to the user, and is coupled to the receive/transmit circuitry 416 .
  • the mobile telephone 204 may also include an integrated circuit (IC) or chipset 424 of the kind embedded in contactless payment cards.
  • the IC 424 is connected to an antenna 426 and operates so as to interact with an RFID/NFC proximity reader of a POS terminal to provide a payment card account number for a purchase transaction at the POS terminal.
  • the IC 424 may be designed/programmed to operate in accordance with the well-known “PayPass” standard (promulgated by the assignee hereof) for contactless payment applications.
  • FIG. 5 is a block diagram that illustrates an alternative embodiment (generally represented by reference numeral 200 a ) of the system shown in FIG. 2 .
  • the system 200 a of FIG. 5 may include every component shown in FIG. 2 , while also including a payment services provider (PSP) computer 502 that provides “on behalf” and/or value added services.
  • PSP payment services provider
  • the PSP computer 502 may exchange communications (by wireless communications and/or landline communications) with each of the merchant device 202 , the customer's mobile device 204 and the customer issuer 206 .
  • the PSP computer 502 may operate to relay communications between the merchant device 202 and the customer's mobile device 204 , and between the customer's mobile device 204 and the customer issuer 206 . Although only one PSP computer 502 is shown, in practice it may be desirable to provide a considerable number of PSP computers, each serving a respective geographical region.
  • the PSP computer may effectively provide front end processing on behalf of the customer issuer 206 so that the revised transaction flow proposed herein may be implemented with little or no modification to the operations of the customer issuer 206 .
  • the PSP computer or computers 502 may in some embodiments be operated by the payment card association which also operates the payment system 210 .
  • the PSP computer(s) 502 may be a vehicle for the payment card association to enhance its service offerings for issuers, cardholders and/or merchants.
  • FIG. 6 is a block diagram that illustrates still another embodiment (generally represented by reference numeral 200 b ) of the systems shown in FIGS. 2 and 5 .
  • the system 200 b of FIG. 6 includes all of the components shown in FIG. 5 .
  • the PSP computer 502 performs the additional function of relaying the payment transaction confirmation 602 from the merchant issuer 212 to the merchant device 202 .
  • the PSP computer 502 is performing “on behalf” services for both the customer issuer and the merchant issuer.
  • FIG. 7 is a block diagram representation of an example PSP computer 502 which may be operated as part of the systems shown in FIG. 5 or FIG. 6
  • the PSP computer 502 may be conventional in its hardware aspects but may be controlled by software to cause it to operate in accordance with aspects of the present invention.
  • the PSP computer 502 may include a computer processor 700 operatively coupled to a communication device 701 , a storage device 704 , an input device 706 and an output device 708 .
  • the computer processor 700 may be constituted by one or more conventional processors. Processor 700 operates to execute processor-executable steps, contained in program instructions described below, so as to control the PSP computer 502 to provide desired functionality.
  • Communication device 701 may be used to facilitate communication with, for example, other devices (such as customers' mobile devices 204 , merchant devices 202 , customer issuer computers 206 and/or merchant issuer computers 212 ). Communication device 701 may, for example, have capabilities for sending and receiving messages over mobile telephone networks, as well as engaging in data communication over conventional computer-to-computer data networks.
  • Input device 706 may comprise one or more of any type of peripheral device typically used to input data into a computer.
  • the input device 706 may include a keyboard and a mouse.
  • Output device 708 may comprise, for example, a display and/or a printer.
  • Storage device 704 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and 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.
  • magnetic storage devices e.g., magnetic tape and hard disk drives
  • optical storage devices such as CDs and/or DVDs
  • semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory.
  • Storage device 704 stores one or more programs for controlling processor 700 .
  • the programs comprise program instructions that contain processor-executable process steps of PSP computer 502 , including, in some cases, process steps that constitute processes provided in accordance with principles of the present invention, as described in more detail below.
  • the programs may include an application 710 that manages a process by which customers (i.e., cardholders) may enroll themselves and/or their mobile devices with the PSP computer 502 .
  • the cardholder enrollment process may allow the cardholders to enroll themselves with the PSP computer 502 by accessing via their mobile devices 204 a suitable web page hosted by the PSP computer 502 .
  • the information gathered from the cardholder during the enrollment process may include payment card account number and mobile telephone number (or other mobile identifier).
  • the enrollment process may also require the cardholder to select a PIN (personal identification number) to be used for security purposes in connection with payment transactions to be initiated by the cardholder via his/her mobile telephone and via the PSP computer 502 . Other security measures may also be put in place.
  • the PSP may cooperate with the cardholder's issuing FI to provide security measures that assure that the individual enrolling with the PSP computer 502 is not an impostor.
  • the storage device 704 may also store an application 712 for managing enrollment of issuing FIs with the PSP computer 502 .
  • actual enrollment of FIs with the PSP computer 502 may be performed by data entry or file downloads managed by an administrative employee of the entity that operates the PSP computer 502 . This may occur after person-to-person contacts between an employee of the operator of the PSP computer 502 and an employee of the FI that is seeking enrollment.
  • the FI may be enrolled as a customer issuer, a merchant issuer, or both.
  • the FI as part of its enrollment process, may also enroll its account holders (consumers and/or merchants) en masse with the PSP computer 502 . Further, after enrollment of an FI, it may thereafter, from time to time, feed to the PSP computer 502 enrollments of consumer and/or merchant holders of payment card accounts issued by the FI.
  • Another application that may be stored by the storage device 704 is for handling individual transactions and is indicated by reference numeral 714 in FIG. 7 . Details of operation of the transaction handling application 714 will be discussed hereinbelow, particularly with reference to FIG. 10 .
  • Still another application 716 may be stored by the storage device 704 and may operate in conjunction with the transaction handling application 714 to provide special value added services to individual consumer cardholders. Examples of such special services will be described below.
  • applications 718 and 720 both stored by the storage device 704 , respectively provide special value added services to merchants and to issuer FIs.
  • Reference numeral 722 in FIG. 7 identifies one or more databases that are maintained by the PSP computer 502 on the storage device 704 .
  • these databases may be a consumer cardholder database, a merchant database, an issuer database and a transaction database.
  • the application programs of the PSP computer 502 as described above, may be combined in some embodiments, as convenient, into one, two or more application programs.
  • the storage device 704 may store other programs, such as one or more operating systems, device drivers, database management software, web hosting software, etc.
  • FIG. 8 is a flow chart that illustrates an example sales transaction process that may be performed by the merchant device 202 ( FIGS. 2 , 5 , 6 ) in accordance with aspects of the present invention.
  • information to define the transaction is entered into the merchant device 202 .
  • the merchant device is a conventional POS terminal
  • at least some of the transaction information may be entered by using a barcode scanning component of the POS terminal to scan the product identification barcodes from one or more items presented for purchase by the customer.
  • the POS terminal upon reading the product barcodes, retrieves the prices for the items to be purchased (and possibly the product description and other information as well) and generates a subtotal and a total (e.g., including sales tax) for the sale transaction.
  • Some or all of the steps referred to in the previous sentence may be considered to be “generating transaction data” and are represented at 804 in FIG. 8 .
  • a set of transaction data for the transaction in question may include identifying codes (e.g. ID numbers) for either or both of the POS terminal and the merchant who is the proprietor of the POS terminal.
  • generating the transaction data may include generating a set of information for the transaction that includes the amount due for the transaction and one or both of the merchant identifier and the POS terminal identifier.
  • Generating the transaction data may also included generating and including in the set of data a unique identifying number for the transaction (transaction identifier/reference number).
  • the transaction data generated at 804 may also include line items and/or product descriptions.
  • the merchant device 202 is a suitably programmed mobile telephone owned by an individual merchant.
  • the merchant may, for example, be a farmer or a dealer in produce, handicrafts, second-hand or new clothing or anything else commonly traded by individual entrepreneurs in the markets of third world countries. It may be assumed further that the merchant conducts his or her business in a stall or at a table in an open air market, without electricity or any other modern convenience.
  • the entry 402 of the purchase information may consist simply in the merchant entering a sales transaction total amount due into the merchant device/mobile telephone 202 via the keypad of the device 202 .
  • the total amount due may for example have been arrived at by the merchant adding in his/her head—or on a separate calculator—the prices of the items purchased, or may be calculated by a calculator function in the mobile telephone 202 (another example embodiment of 804 ) from individual item prices manually entered (another example embodiment of 802 ) one after the other into the mobile telephone by the merchant.)
  • the generating of the transaction data may consist in assembling a transaction data set consisting of just two items of data—amount due, and the mobile telephone number assigned to the merchant device/mobile telephone 202 . These two data items may form the payload of a text message/SMS message or other type of information message to be sent to the customer's mobile telephone (mobile device 204 ).
  • the mobile telephone network may operate so that, by a “caller ID” feature the mobile telephone number assigned to the merchant device 202 is automatically provided to the customer mobile telephone 204 when the text message or other information message is received.
  • the merchant may receive (step 806 , FIG. 8 ) from the customer, by oral face to face communication, the mobile telephone number assigned to the customer's mobile telephone 204 and may enter that number into the merchant's mobile telephone 202 , so that the transaction information may be transmitted (step 808 , FIG. 8 ) from merchant device 202 to customer mobile device 204 .
  • transmission of the transaction information should be understood to encompass provision of the merchant mobile telephone number from the merchant mobile telephone to the customer mobile telephone via a “caller ID” feature of the mobile network. It should also be noted that the merchant mobile telephone number may serve as a merchant identifier for purposes of the customer's subsequent initiation of a request for a payment transaction.)
  • the customer may next operate his mobile telephone 204 , using the transaction information transmitted thereto from the merchant device 202 , to request that a payment transaction be carried out in the payment system (e.g., system 200 , FIG. 2 ) to transfer the transaction amount from the customer's payment card account 208 to the merchant's payment card account 214 . While this is occurring, the merchant/merchant device 202 may wait (block 810 , FIG. 8 ) to receive the confirmation 228 ( FIG. 2 ) that the funds transfer has been or will be accomplished via the channels of the payment card system 210 . Once the confirmation is received by the merchant device 810 (the whole process may require only a few seconds), the merchant transfers title in the purchased items to the customer, and the transaction is complete (FIG. 8 —block 812 ).
  • the payment system e.g., system 200 , FIG. 2
  • the merchant/merchant device 202 may wait (block 810 , FIG. 8 ) to receive the confirmation 228 ( FIG. 2 ) that the funds transfer has been
  • FIG. 8 Before returning to the “mega-retailer” scenario with which we opened discussion of FIG. 8 , there will be a brief mention of advantages provided by aspects of the present invention in the above-described third world market scenario. Perhaps most important, the process of FIG. 8 is cashless, so that neither the merchant nor the customer takes on the often large risks of carrying and holding cash in a third world environment. Also, this process leverages on the already existing prevalence of mobile telephones among third world merchants and consumers. The banking relationships required by the participants are also such as may be established and maintained at relatively low cost, thus minimizing the economic barriers to adoption.
  • the system is an open one, in the sense that the parties need not have a relationship with the same financial institution/service provider, but need only have low level banking relationships with respective FIs that belong to a widespread payment card system such as that organized by the assignee hereof.
  • the parties do not need to even use the same mobile network operator (MNO), so long as their respective MNOs are interoperative.
  • MNO mobile network operator
  • the POS terminal 202 had received entry of purchase information ( 802 in FIG. 8 ) and had generated transaction data for the sales transaction ( 804 in FIG. 8 ). It may next possibly be the case ( 806 , FIG. 8 ) that the customer will orally advise the POS terminal operator of the customer's mobile telephone number (or other mobile identifier), so that the POS terminal operator may enter the customer's mobile telephone number (or other mobile identifier) into the POS terminal, as a prelude to the POS terminal transmitting the transaction data ( 808 in FIG. 8 ) to the customer's mobile device.
  • the transmission may be a text message/SMS or the like.
  • the POS terminal may transmit the transaction information to the customer's mobile device via NFC (near field communication) or the like.
  • the POS terminal may display the transaction information (e.g., total amount due and merchant/POS terminal identifier) for the customer to manually enter into his/her mobile device.
  • step 808 may be preferable for a high volume environment, any of the other alternatives set forth above may be quite appropriate for a retail establishment in which the transactions are relatively infrequent.
  • the POS terminal 202 may transmit the transaction information to a payment services provider computer 502 ( FIGS. 5 and 6 ), which may in turn relay the information to the customer's mobile device 204 .
  • a payment services provider computer 502 FIGS. 5 and 6
  • the POS terminal may include the mobile telephone number or other addressing information for the customer's mobile device 204 in the transmission to the payment services provider computer 502 , so that the payment services provider computer 502 may in turn route the transaction information to the customer's mobile device 204 .
  • the POS terminal 202 may include a transaction reference number in the transmission to the payment services provider computer 502 , and may also transmit the transaction reference number to the customer's mobile device 204 . (Or, the POS terminal 202 may display the transaction reference number, and the customer may enter the transaction reference number into the mobile device 204 .) The customer may then use the mobile device 204 to call in to the payment services provider computer 502 and use the transaction reference number to identify to the payment services provider computer 502 the transaction information to be relayed from the payment services provider computer 502 to the customer's mobile device 204 .
  • the transaction reference number may be unique only to the merchant, so that the merchant identifier may also be needed to index the transaction information within a database maintained by the payment services provider computer 502 .
  • the merchant identifier may be transmitted to the customer's mobile device 204 by the POS terminal 202 or may be displayed by the POS terminal 202 for the customer to read and enter into the mobile device 204 .
  • the mobile device 204 may report its current location (via GPS—Global Positioning System—data or the like) to the payment services provider computer 502 ; the payment services provider computer 502 may then infer, from the location information, the identity of the merchant at which the customer and his/her device are currently located. For such a purpose, the payment services provider computer 502 may maintain a database of merchant locations.
  • the transaction information transmitted by the POS terminal 202 to the customer's mobile device 204 or to the payment services provider computer 502 , as the case may be, may include line item information that identifies individual product items that are included in the current sale transaction.
  • the process of FIG. 8 may end as in the third world market example, with the merchant device 202 (currently assumed to be a POS terminal) waiting ( 810 in FIG. 8 ) to receive from the merchant's FI (or a PSP acting as an intermediary) confirmation of the payment transaction in favor of the merchant's account 214 .
  • the transaction is then completed (step 812 ).
  • the merchant releases goods purchased to the customer and/or uses the merchant device 202 to print a receipt for the transaction and gives the receipt to the customer.
  • the third world model described above may be conveniently adopted even in a developed country, and that the merchant device 202 accordingly may be a mobile telephone in the case of any merchant who lacks or prefers not to use a POS terminal, regardless of the merchant's location.
  • the process could have a time-out feature such that the merchant device aborts the transaction if the payment transaction confirmation is not received within a predetermined waiting period.
  • FIG. 9 is a flow chart that illustrates a process that may be performed by the customer's mobile device 204 in connection with a transaction handled as in FIG. 2 , FIG. 5 or FIG. 6 .
  • the mobile device 204 may receive the transaction information or the transaction information may be entered into the mobile device 204 by the customer's interaction with the user interface offered by the mobile device 204 . If the mobile device receives the transaction information, this may occur by wireless transmission from either the merchant device 202 or from the payment services provider 502 .
  • the transaction information and/or other information received by the customer's mobile device 204 may (as indicated at 904 in FIG. 4 ) include the name of the merchant. For example, the name of the merchant may be transmitted to the customer's mobile device 204 by the payment services provider 502 or by the customer's issuing FI 206 .
  • the payment services provider 502 may serve as a trusted third party to verify the identity of the merchant and to protect the customer from dealing with an impostor.
  • the payment services provider may be able to vouch for the merchant because the merchant has gone through an enrollment process with the payment services provider or with an FI that is trusted by the payment services provider. In this way, the customer may be assured of the merchant's identity before the customer initiates the payment transaction.
  • the customer's mobile device 204 generates a request for a payment transaction.
  • the request for a payment transaction includes the transaction amount and a merchant identification code.
  • the request for the payment transaction may also include an identification code or number that identifies the customer. This code or number may be explicitly included in the request or may be implicitly generated as, e.g., a caller identification that identifies the mobile telephone number assigned to the mobile device 204 .
  • the identifier for the customer may for example thus be the mobile telephone number assigned to the mobile device 204 or the payment card account number that identifies the customer's payment card account that is to be used to fund the payment transaction.
  • the merchant identification code may be one or more of a mobile telephone number assigned to the merchant device 202 , or the payment card account number that identifies the merchant's payment card account that is to be credited by the payment transaction, or an identifier that otherwise identifies the merchant, such as a code used to index the merchant's record in a database maintained by a payment services provider computer 502 .
  • an identifier for the particular merchant device 202 may also be included in the payment transaction request.
  • the request need only refer to the transaction by a transaction reference number, with the payment services provider computer 502 being relied upon to look up the other transaction information, such as merchant ID and transaction amount.
  • the customer's mobile device 204 transmits the request for a payment transaction.
  • the mobile device 204 transmits the request for a payment transaction to the FI 206 ( FIG. 2 ) which issued the customer's payment card account.
  • the mobile device 204 transmits the request for a payment transaction to a payment services provider, as in FIGS. 5 and 6 .
  • the request for a payment transaction may explicitly include the customer's payment card account number, the merchant's payment card account number and the amount of the requested payment transaction, in which case the request may be handled in a straightforward manner by the customer's FI 206 .
  • the customer and/or the merchant may be identified by their respective mobile telephone numbers or in another manner apart from their payment card account numbers. If so, the customer's FI may translate the customer's mobile telephone number (whether explicitly or implicitly (by caller ID) included in the request) into the customer's payment card account number, and the payment system 210 may translate the merchant's mobile telephone number into the merchant's payment card account number and may route the transaction accordingly.
  • the payment services provider computer 502 may perform one or both of the translations referred to in the previous sentence.
  • the customer's mobile device and hence the customer, may be identified by a SIM identifier or the like rather than by mobile telephone number.
  • the payment transaction request transmitted by the customer's mobile device 204 may include line item information that identifies individual product items that the customer is purchasing.
  • an authentication procedure may be included in the process of FIG. 9 . This may go beyond requiring the customer to enter a PIN in order to access the payment transaction request function.
  • the customer's issuer 206 and/or the payment services provider computer 502 acting on behalf of the customer's issuer, may selectively require additional authentication in the case of certain transactions, based on various criteria. These criteria may include, for example, the amount of the requested payment transaction, the time of day and/or day of the week, the item(s) being purchased, the identity of the customer and/or the identity of the merchant. Recent or past account activity or inactivity may also be taken into consideration in determining whether to require authentication.
  • the authentication procedure may include an exchange of text messages and/or electronic mail messages (or another type of information message) via the customer's mobile device 204 or a telephone conversation via the customer's mobile device 204 .
  • the exchange of messages and/or the telephone conversation may be handled by a human employee of the customer issuer 206 and/or the payment services provider 502 .
  • the exchange of information messages may be automatically conducted by computer on the part of the customer issuer 206 and/or the payment services provider 502 , or the customer may be required to “converse” with an automated voice response system operated by the customer issuer 206 and/or the payment services provider 502 .
  • the exchange of messages or telephone conversation may include issuing a “challenge” to the customer, such as requiring the customer to provide one or more items of security information (e.g., date of birth, mother's maiden name, birthplace, home telephone number, home address, Social Security number, etc.).
  • a “challenge” e.g., date of birth, mother's maiden name, birthplace, home telephone number, home address, Social Security number, etc.
  • the authentication procedure may call for the customer to use the mobile device to take his/her picture and send it to the authenticating authority so that an individual employee of the authenticating authority may compare the picture with another picture of the customer that is previously on file.
  • demographic information about customers as collected by the customers' mobile network providers may be provided to merchants for market research purposes.
  • the process of FIG. 9 may include value added services (block 912 ), provided to the customer by either of both of the customer's issuer 206 and the payment services provider 502 .
  • value added services may be such as cannot readily be provided in the conventional transaction flow depicted in FIG. 1 .
  • the customer's issuer 206 may respond to the request for a payment transaction with a message (sent to the customer's mobile device 204 ) offering to make an overdraft or credit facility available to the customer, so that the request for a payment transaction can be honored.
  • the customer's issuer 206 and/or the payment services provider 502 may present the customer (via a message or messages to the mobile device 204 ) with one or more promotional offers and/or virtual coupons which the customer may avail himself/herself with to fund at least a portion of the payment transaction.
  • the payment services provider 502 may offer on behalf of the merchant that a portion of the payment transaction will be funded by the merchant if the customer enrolls in the merchant's customer loyalty program.
  • an offer provided by a third party may be contingent on the customer adding an additional item to the pending transaction.
  • the manufacturer or warranty provider may offer to be a source of funding for a portion of the purchase price, contingent on the customer purchasing installation services for the item from the merchant. This offer benefits the merchant, by increasing the merchant's installation business; benefits the customer, by reducing the customer's cost for the transaction; and benefits the manufacturer/warranty provider by increasing the likelihood that installation will be performed correctly, thereby decreasing the likelihood of a warranty claim.
  • a third party installation provider may offer to partially fund the transaction on the condition that the customer agree to defer installation until after the busy period is over.
  • the customer's issuer 206 (or the payment services provider 502 acting on behalf of the customer's issuer 206 ) may offer to fund part of the payment transaction if the customer agrees to open a deposit account with the customer's issuer.
  • the customer's issuer 206 may offer to fund part of the payment transaction if the customer agrees to open a deposit account with the customer's issuer.
  • the customer's mobile device 204 receives a message that confirms that the payment transaction has been executed (possibly subject to a subsequent clearing operation).
  • the customer's mobile device 204 may for example receive this confirmation message from the customer's issuer 206 or from the payment services provider computer 502 .
  • step 914 may be omitted, and the customer may effectively be informed that the payment transaction has gone through based on the merchant's willingness to complete the sales transaction, release the goods to be purchased, issue a receipt, etc. in response to the merchant device 202 receiving confirmation of the payment transaction.
  • FIG. 10 is a flow chart that illustrates a process that may be performed by the payment services provider computer 502 .
  • the payment services provider computer 502 receives the transaction information from the merchant device 202 .
  • the transaction information may include the amount of payment to be made for the transaction and merchant identifying information, such as a merchant number or a mobile telephone number that was assigned to the merchant device 202 .
  • the merchant device 202 may be a mobile telephone, or alternatively a POS terminal or PDA.
  • the transaction information also includes a transaction reference number assigned by the merchant device, for use in subsequent communications among the payment services provider computer 502 , the merchant device 202 and the customer's mobile device 204 .
  • the transaction information may also include details of the transaction, including information that identifies the items purchased, line item pricing, promotional offers or coupons made available by the merchant, etc.
  • the transaction information may also include addressing information to allow the payment services provider computer 502 to contact the customer's mobile device 204 .
  • the transaction information may include particulars about the merchant device and/or capabilities of the merchant device (e.g., whether the merchant device is a POS terminal or a mobile phone; if the latter, what the capabilities are of the mobile phone; whether the merchant device is NFC/RFID capable).
  • Another category of transaction information may include encryption- and/or authentication-related information, such as the merchant's public keys for digital signatures, etc.
  • Still another category of transaction information may include information that identifies the merchant's physical location, or the location of the merchant device.
  • the addressing information may for example be a mobile telephone number assigned to the customer's mobile device 204 .
  • the payment services provider computer 502 may use the addressing information for the customer's mobile device 204 to transmit at least some of the transaction information to the customer's mobile device 204 .
  • the payment services provider computer 502 may have looked up the name of the merchant based on the merchant identifying information received from the merchant device 202 , and the payment services provider computer 502 may append the name of the merchant to transaction information that the payment services provider computer 502 transmits to the customer's mobile device.
  • the payment services provider computer 502 receives a request for a payment transaction from the customer's mobile device 204 .
  • the request may consist entirely of an indication to the effect of “yes, I want to go ahead with the transaction” plus the transaction reference number.
  • the request for the payment transaction, as received from the customer's mobile device may include more detail, such as transaction amount (amount to be transferred by the payment transaction), merchant identifier (e.g., merchant mobile telephone number) and customer identifier (e.g., customer mobile telephone number—included explicitly in the request or implicitly by caller ID, or customer's payment card account number, or another code or reference that identifies the customer).
  • the payment services provider computer 502 may undertake an authentication procedure or procedures, as described above in connection with step 910 in FIG. 9 , and/or the payment services provider computer 502 may offer or provide certain special services, promotional offers, credit offers, as described above in connection with step 912 in FIG. 9 .
  • the special services for example, may be initiated earlier in the process, such as in conjunction with step 1004 . That is, the transaction information that the payment services provider computer 502 transmits to the customer's mobile device at 1004 may include offers of special services, etc.
  • Another type of special service that may be provided by the payment services provider computer, and not mentioned up to now, may entail enforcing restrictions on usage of the customer's payment card account 208 .
  • a payment card account set up by a parent for his/her college student child The parent may be able to set up restrictions as to (a) which merchants the payment card account may be used to pay (college bookstore and dining hall only, e.g.), and/or (b) a maximum dollar amount of transactions allowed per period of time (e.g., $100.00 per week).
  • the payment card account may be restricted as invalid for purchase transactions or other transactions that are not payment transactions as described herein, so that the payment services provider computer (in enforcing the parental restrictions) effectively may have complete control over the use of the payment card account.
  • the customer's issuing FI 206 may enforce restrictions of the sort described in the previous paragraph.
  • the PSP computer 502 or the customer FI 206 may send a real time inquiry message to the parent, asking whether the parent will allow the particular transaction. If the parent approves the requested payment transaction, the PSP computer 502 or the customer FI 206 proceeds with the requested payment transaction. If the parent does not approve, the requested payment transaction is declined. With this arrangement, it will be appreciated that the child may phone the parent ahead of time to alert the parent that the child intends to request a payment transaction that falls outside the established restrictions.
  • a restricted use payment card account may be useful, consider the case of a well-to-do individual who hires a personal assistant to help in managing his/her household.
  • the employing individual may set up a restricted-use payment card account for the assistant to use in paying some of the household expenses, but again limited to certain suppliers (e.g., grocery store, house-cleaning contractor, utility companies, etc.) and/or to a maximum amount per period of time.
  • the payment services provider computer 502 may translate the customer identifying information (e.g., customer's mobile telephone number) into the customer's (funding) payment card account number for the requested payment transaction, and the payment services provider computer 502 may translate the merchant's identifying information (e.g., the merchant's mobile telephone number) into the payment card account number for the merchant's account to which the payment transaction is to be routed.
  • customer identifying information e.g., customer's mobile telephone number
  • the payment services provider computer 502 may translate the merchant's identifying information (e.g., the merchant's mobile telephone number) into the payment card account number for the merchant's account to which the payment transaction is to be routed.
  • the payment services provider computer 502 may forward the request for the payment transaction to the customer's issuing FI 206 .
  • the request for the payment transaction may include all information that the customer's issuing FI 206 may need to process the payment transaction in a conventional manner.
  • the request as forwarded by the payment services provider computer 502 to the customer's issuing FI 206 may include the payment card account number for the funding payment card account (issued by the FI 206 to the customer), the amount of the payment transaction, and the payment card account number for the merchant's payment card account to which the payment transaction is to be routed.
  • the payment services provider computer 502 may have no more involvement in the transaction.
  • the payment transaction may proceed from the customer's FI 206 to the merchant's FI 212 via the payment system 210 , and the merchant's FI 212 may provide a confirmation 228 ( FIG. 5 ) to the merchant device 202 to allow for completion of the sales transaction between the merchant and the customer.
  • the payment services provider computer 502 may be in the communication path between the merchant FI 212 and the merchant device 202 , as illustrated in FIG. 6 . That is, and as indicated at 1014 in FIG.
  • the payment services provider computer 502 may receive from the merchant FI 212 an authorization response to indicate that the merchant's account exists and is in a proper status to receive the payment, so that the payment transaction will go through (or has gone through). Then, at 1016 in FIG. 10 , the payment services provider computer 502 may provide a confirmation of the payment transaction to the merchant device 202 to allow for completion of the sales transaction. Also, and optionally, the payment services provider computer 502 may provide confirmation of the payment transaction to the customer's mobile device 204 (step 1018 ).
  • the request for the payment transaction may include a transaction reference number that the merchant FI 212 , in turn, includes in the authorization response.
  • the payment services provider computer 502 is able to retrieve its record of the transaction upon receiving the authorization response, and is able to provide a proper confirmation message to the merchant device 202 .
  • FIG. 11 is a block diagram that illustrates a bill payment system 1102 according to some embodiments.
  • the bill payment system 1102 may have the following components in common with the payment system 200 b shown in FIG. 6 : (a) mobile device 204 (customer's mobile device); (b) payment services provider computer 502 ; (c) issuing FI 206 (for the customer's payment card account); (d) payment system 210 ; and (e) receiving/issuing FI 212 .
  • the bill payment system 1102 includes a service provider computer 1104 operated by or on behalf of a service provider such as a public utility, a daily or periodical publication or any other entity with a large customer base that it regularly sends bills to.
  • the receiving issuer FI 212 in the case of the system 1102 receives payment transactions for the service provider rather than for a retail merchant.
  • FIG. 12 is a flow chart that illustrates a process that may be performed by the payment services provider computer 502 in the bill payment system 1102 of FIG. 1 .
  • the payment services provider computer 502 receives a batch of billing information from the service provider 1104 (for example, an electric utility company).
  • the billing information concerns monthly electricity bills from the service provider 1104 to its residential subscribers (or at least for those who have signed up for bill payment through the system 1102 illustrated in FIG. 11 ).
  • the billing information may contain numerous records, each of which represents a single bill. Each record may contain, for example, the amount of the bill, a customer identifier for the customer in question, and the mobile telephone number for the customer in question (or alternatively, the mobile telephone number may serve as the customer identifier), a record number, etc.
  • the service provider 1104 may also send the billing information directly to the customer's mobile device 204 , as indicated by arrow 1106 in FIG. 11 .)
  • the payment services provider computer 502 transmits the billing information in each record to the mobile device 204 (only one shown) that belongs to the respective customer for the billing record.
  • the information transmitted to the customer's mobile device may indicate, “Your monthly electric bill is $XXX.XX. Do you wish to pay with your credit/debit card?”
  • the payment services provider computer 502 effectively receives a request from the customer for a payment transaction to settle the bill.
  • the payment services provider computer 502 may translate the customer identifying information (e.g., the customer's mobile telephone number or the customer's account number with the service provider) into the customer's (funding) payment card account number for the requested payment transaction, and the payment services provider computer 502 may translate the service provider's identifying information into the payment card account number for the service provider's payment card account to which the payment transaction is to be routed.
  • the payment services provider computer 502 may be programmed to automatically interpret the customer's affirmative response to the question transmitted at 1204 as a request to initiate a payment transaction to the service provider's payment card account number that the payment services provider computer 502 had previously associated with the batch of billing information received at 1202 .
  • the batch of billing information may have included instructions from the service provider 1104 as to the payment card account number for the service provider's payment card account 214 ( FIG. 11 ).
  • step 1208 may typically occur with respect to each customer to whom the billing information was sent at 1204 .
  • the payment services provider computer 502 may forward the customers' request for payment transactions to the customers' various issuing FIs 206 (only one shown in FIG. 11 ).
  • the requests for payment transactions may include all information required for the customers' issuers 206 to process the payment transactions in a conventional manner.
  • the requests forwarded by the payment services provider computer 502 each may include the payment card account number for the customer's payment card account 208 , the amount of the payment transaction (amount due on the bill), and the payment card account number for the service provider's payment card account 214 .
  • the payment services provider computer 502 may have no more involvement in the service provider's billing activities for the current billing cycle. For example, the payment transaction may proceed from the customer's FI 206 to the service provider's FI 212 via the payment system 210 , and the service provider 1106 may receive a confirmation message or report from its FI 212 as to payments received.
  • the payment services provider computer 502 may receive, from the service provider's FI 212 , individually or in batches/reports, confirmations or authorization responses from the service provider's FI 212 to indicate that the payment transaction had gone through or would do so, via normal clearing activities. Then at 1214 in FIG.
  • the payment services provider computer 502 may provide confirmations of the payment transactions (individually or in batches) to the service provider computer 1104 . In addition, as indicated at 1216 , the payment services provider computer 502 may confirm the payment transaction and settlement of the bill to each customer's mobile device 204 .
  • FIG. 13 is a block diagram that illustrates a payroll disbursement system 1302 according to some embodiments.
  • the payroll disbursement system 1302 may include an employer computer 1304 operated by or on behalf of an employer organization which pays its employees via the system 1302 .
  • the employer may, but need not, have a considerable number of employees on its payroll.
  • Block 1306 in FIG. 13 represents a mobile telephone or home computer that belongs to an employee of the employer.
  • the payroll disbursement system 1302 further includes a payment services provider computer 502 and a payment system 210 as in systems shown in FIGS. 2 , 5 , 6 or 11 , for example.
  • the payroll disbursement system includes an FI 1308 that issued a payment card account 1310 to the employer, and issuing FIs 1312 (only one shown) that issued payment card accounts 1314 to employees.
  • FIG. 14 is a flow chart that illustrates a process that may be performed by the payment services provider computer 502 in the system of FIG. 13 .
  • the payment services provider computer 502 receives a batch of payroll disbursement information from the employer computer 1304 (or alternatively from a payroll services provider retained by the employer).
  • the payroll disbursement information may include a number (potentially a large number) of records, each representing wages or salary to be paid to a respective employee for the current employment period.
  • Each record may contain, for example, a record number, the net amount that is being paid to the employee in question, an employee identification number (which could be the employee's Social Security number), the mobile telephone number for the employee in question, or a payment card account number that identifies the payment account to which the employee's wages or salary are to be disbursed.
  • the employer may also provide a paystub or virtual paystub directly to the employee device, as indicated by arrow 1316 .
  • the payment services provider computer 502 may translate the employee identifier into the payment card account number for the employee's payment card account to which the wage/salary payment is to be routed.
  • the payment services provider computer 502 may forward, to the employer's issuing FI 1308 , requests for payment transactions with respect to each of the wage/salary payments indicated by the batch of payroll information received at 1402 .
  • each of the requests for a payment transaction may include the amount of the payment, the payment card account number that identifies the employer's payment card account 1310 from which the payment transaction is to be funded, and the payment card account number that identifies the employee's payment card account to which the payment transaction is to be routed.
  • the payment services provider computer 502 may have no more involvement in the payroll disbursement process.
  • the payment transactions may proceed from the employer's FI 1308 to the employees' FIs 1312 via the payment system 210 , and either no confirmations of the payment transactions are provided to the employees, or the employees receive confirmations of the payment transactions from their individual FIs 1312 .
  • the payment services provider computer 502 may receive, from each of the employees' FIs 1312 , confirmations or authorization responses to indicate that the payment transactions had gone through or would do so (via normal clearing activities).
  • the payment services provider computer 502 may provide confirmations of the payment transactions to the employee devices 1306 .
  • the payment services provider computer 502 may also provide confirmations of the payment transactions to the employer computer 1304 .
  • FIG. 15 is a block diagram that illustrates still another embodiment of a transaction-handling system, indicated by reference numeral 200 c.
  • the transaction-handling system 200 c of FIG. 15 may have all of the components shown in FIG. 5 , including the merchant device 202 , the customer's mobile device 204 , the payment services provider computer 502 , the customer's issuing FI 206 , the payment system 210 and the merchant's issuing FI 212 .
  • the system 200 c may include a computer that is represented by block 1502 in FIG. 15 and that is operated by an entity that, at least on occasion, may partially or completely fund payment transactions instead of the payment transactions being totally funded from the customer's payment card account 208 .
  • the additional funding source computer 1502 may be in data communication, at least from time to time, with the payment services provider computer 502 .
  • the payment services provider computer 502 and/or the additional funding source computer 1502 may have capabilities for tracking all payment card transactions (e.g., both payment transactions as described herein and conventional purchase transactions as illustrated in FIG. 1 ) initiated by the customer, and may detect when a particular transaction, for which information is received from a merchant, is qualified to be partially funded by a loyalty program. For example, such a loyalty program may be operated by the customer's issuing FI 206 . Upon detection of a qualified transaction, the payment services provider computer 502 may send to the customer's mobile device 204 , along with the transaction information, an inquiry as to whether the customer wishes to apply a rewards payment to the pending transaction.
  • all payment card transactions e.g., both payment transactions as described herein and conventional purchase transactions as illustrated in FIG. 1
  • a loyalty program may be operated by the customer's issuing FI 206 .
  • the payment services provider computer 502 may send to the customer's mobile device 204 , along with the transaction information, an inquiry as to whether the customer wishes to
  • a portion of the funds for the payment transaction may come from the additional funding source 1502 , and the amount to be charged to the customer's payment card account 208 for the payment transaction may be reduced by the amount supplied by the additional funding source 1502 .
  • the payment services provider computer 502 may perform one or more of the following roles, among others: (a) acting as a control agent for the transaction; (b) acting as a storage facility for information and logic used (i) to determine whether split-funding should occur, and (ii) to identify funding sources and to determine how to split the sourcing of funds between the sources; and (c) initiating two or more payment transactions to implement the split-funding transaction.
  • a request for the transaction is received by the payment services provider computer 502 from the customer's mobile device 204 , with the request including for example the total amount to be paid and a merchant identifier.
  • the payment services provider computer 502 may identify the transaction as qualifying for split funding based on (1) an explicit instruction from the customer or (2) the payment services provider computer 502 recognizing predefined characteristics of the transaction.
  • the request from the customer may include indications of the funding accounts and how the payment is to be split between the accounts; in the latter case, the payment services provider computer 502 may detect the qualification of the transaction for split funding from one or more of the following attributes, among others: customer ID, customer payment card account number, merchant ID, merchant payment card account number, detail(s) of the items purchased, date and/or time, type of transactions, etc.) (C) After recognizing the transaction as qualified for split funding, the payment services provider computer 502 may temporarily suspend the transaction and then may access a database record or other stored information to determine how to split the payment amount, and between what source accounts, and further may automatically seek and obtain any required approvals (e.g., from a funding third party) or alternatively the funding third party may indicate to the payment services provider computer 502 how much funding the third party will provide.
  • the payment services provider computer 502 may temporarily suspend the transaction and then may access a database record or other stored information to determine how to split the payment amount, and between what source accounts, and further may automatically seek and obtain any required approvals
  • the payment services provider computer 502 may initiate funding authorization requests to verify that the indicated source account(s) have sufficient funds to support the indicated payment transactions.
  • the payment services provider computer 502 may initiate a respective payment transaction to implement each partial funding portion of the split-funded transaction.
  • the payment services provider computer 502 may initiate a confirmation message to the customer and/or to the merchant (or alternatively confirmation to the merchant may come from the merchant's issuer.)
  • the payment services provider computer 502 may take such actions (depending, e.g., on stored instructions for such a situation) as (a) transmitting a message to the customer's mobile device 204 to report the failed transaction (e.g., due to refusal to approve the transaction by a third party or for reasons described above) and possibly to ask the customer for an alternative funding source or for instructions to default to an alternative manner (such as an alternative split-funding arrangement) of funding the transaction; (b) following stored instructions to substitute an alternative funding or split-funding arrangement for the arrangement that failed.
  • Clearing and settlement of the constituent payment transactions may be undertaken in normal course and may in effect clear and settle the entire transaction.
  • Split funding of transactions may not require any modification of conventional payment transaction practices. Nevertheless, in some embodiments it may be useful to modify some conventional processes or provide new processes to facilitate handling of failed transactions.
  • Such processes may include reversals of payment transactions, establishment of rules of hierarchy as to funding sources and establishment of rules as to the order in which the constituent payment transactions are to be executed.
  • the additional funding source need not be a loyalty program.
  • One possible alternative is a product specific or merchant specific electronic coupon.
  • the additional funding source may be a medical or dental insurance plan.
  • the merchant device may, as part of the transaction information transmitted to the payment services provider computer 502 , include claim information required by the insurance plan, and that information may be passed on by the payment services provider computer 502 to the insurance plan as a request for coverage of the payment.
  • the actual source of the additional funding may be a payment card account (not shown) issued by another issuer (not shown) to the underwriter (loyalty plan, insurance plan, etc.) of the additional funding.
  • FIG. 16 is a block diagram that illustrates still another embodiment of a transaction-handling system, indicated by reference numeral 200 d.
  • the transaction-handling system 200 d of FIG. 16 may have all of the components shown in FIG. 5 , including the merchant device 202 , the customer's mobile device 204 , the payment services provider computer 502 , the customer's issuing FI 206 (i.e. the FI which issued the customer's payment card account 208 ), the payment system 210 and the merchant's issuing FI 212 (i.e., the FI which issued the merchant's payment card account 214 ).
  • the system 200 d may include another payment card account 1602 (issued by issuing FI 1604 ), which is to receive a portion of the payment transaction, with the merchant's payment card account 214 receiving the balance of the payment transaction.
  • the payment card account 1602 may be referred to as a co-recipient's account in the sense that the party to which the payment card account was issued is a co-recipient, with the merchant, designated in the payment transaction.
  • the issuing FI 1604 may be referred to as the co-recipient's issuing FI.
  • a request for the transaction is received by the payment services provider computer 502 from the customer's mobile device 204 , with the request including for example the total amount to be paid and a merchant identifier. In some embodiments, the request may specify that the payment be split and between which recipients.
  • the payment services provider computer 502 may identify the transaction as qualifying for or requiring split payment based on either explicit instructions in the request or one or more rules triggered by characteristics of the transaction.
  • C After recognizing that split payment is or may be in order, the payment services provider computer 502 may temporarily suspend the transaction and then may access a database record or other stored information to determine how to divide the payment, and between what destination accounts.
  • the payment services provider computer 502 may initiate an authorization request to confirm that sufficient funds are available for the transaction in the customer's payment card account.
  • E Next the payment services provider computer 502 may initiate respective payment transactions to implement each partial funding portion of the split payment transaction.
  • the payment services provider computer 502 may initiate a confirmation message to the customer and/or to either or both of the recipients of the payment transactions (or alternatively one or both of the recipients may receive confirmation from the respective issuer for the recipient's payment card account).
  • the payment services provider computer 502 may be guided by stored instructions to take appropriate action.
  • Clearing and settlement of the constituent payment transactions may be undertaken in normal course and may in effect clear and settle the entire transaction.
  • Split payment transactions may not require any modification of conventional payment transaction practices. Nevertheless, in some embodiments it may be useful to modify some conventional processes or provide new processes to facilitate handling of failed transactions. Such processes may include reversals of payment transactions, and establishment of rules as to the order in which the constituent payment transactions are to be executed.
  • the co-recipient is a sales tax collection authority.
  • the payment transaction requested by the customer may call for the pre-tax subtotal amount of a sales transaction to be transferred to the merchant's payment card account 214 , with the tax due on the sales transaction to be transferred (in the same or a related payment transaction) to the sales tax collection payment card account (reference numeral 1602 , according to this example).
  • the customer is purchasing an item (e.g., a piece of furniture) that has been consigned for sale by the merchant.
  • the co-recipient is the consignor.
  • the consignor's share of the purchase price is transferred to the consignor's payment card account (reference numeral 1602 , according to this example) by a purchase transaction requested by the customer, and the balance of the purchase price, which can also be considered the merchant's commission, is transferred to the merchant's payment card account 214 by the same or a related payment transaction requested by the customer.
  • the “merchant” is assumed to be a construction company/home remodeling company that serves as a general contractor (GC), and the co-recipient may be a subcontractor or supplier of materials to the GC.
  • GC general contractor
  • the “merchant” is assumed to be a part-time domestic employee, and the co-recipient may be the Internal Revenue Service or a state tax authority, acting as collector of payroll withholding taxes or other payroll taxes.
  • FIG. 17 is a flow chart that illustrates a process that may be performed in the point of sale terminal 202 that may serve as the merchant device shown in FIG. 2 , 5 , 6 , 15 or 16 .
  • the POS terminal 202 may be selectively operable in either a conventional payment card purchase transaction mode (described with reference to FIG. 1 ) or in a novel mode, as described hereinabove, in which the POS terminal 202 serves as an adjunct to a customer-requested payment card system payment transaction by which the pending sales transaction will be settled.
  • a conventional payment card purchase transaction mode described with reference to FIG. 1
  • a novel mode as described hereinabove, in which the POS terminal 202 serves as an adjunct to a customer-requested payment card system payment transaction by which the pending sales transaction will be settled.
  • the POS terminal 202 does not initiate a payment card purchase transaction authorization request, but rather only displays or transmits transaction information (to the customer's mobile device 204 or to an intermediary such as payment services provider computer 502 ) and then awaits confirmation of the effectiveness of the customer-requested payment transaction.
  • information to define the purchase transaction is entered into the POS terminal 202 .
  • This may entail, for example, the barcode reader component 306 ( FIG. 3 ) of the POS terminal 202 being used to read a product identifying barcode or barcodes from one or more items that the customer wishes to purchase.
  • the POS terminal determines whether it has been placed in the (conventional) purchase transaction mode or in the (novel) payment transaction mode. If the former mode is selected, the POS terminal operates (step 1706 ) in the manner described above with reference to FIG. 1 . If the latter mode is selected, the POS terminal does not initiate a purchase transaction authorization request, but rather operates (step 1708 ) as described above in connection with FIG. 8 .
  • the purchase transaction mode may be selected by swiping a magnetic stripe payment card through the magnetic stripe reader component 310 ( FIG. 3 ) of the POS terminal 202 or by bringing a contactless payment card or payment device (including, e.g., a mobile telephone equipped with contactless payment device capabilities) into proximity with the RFID/NFC terminal component 316 of the POS terminal 202 .
  • selection of the payment transaction mode may require positive input from the operator, such as touching a relevant portion of a touch screen, actuating a soft key, or actuating a dedicated function key to indicate selection of the payment transaction mode.
  • the payment transaction mode may be the default mode of operation for the POS terminal, entered upon initiation of a purchase transaction (e.g., by reading a barcode from a product item), with the purchase transaction mode only being entered upon presentation of a payment card or device to the POS terminal, as described earlier in this paragraph.
  • selection of either mode may require positive input from the operator, e.g., by selecting an appropriate option from a menu displayed by the POS terminal.
  • the device may support only one mode of operation, namely a payment transaction mode as described hereinabove in connection with FIG. 8 .
  • the merchant device 202 may support cash transactions in addition to payment-system-based payment transactions as described herein.
  • the customer's mobile device 204 may also be a dual use device in terms of its payment capabilities. That is, in some embodiments the customer's mobile device 204 may be selectively operable either in a conventional contactless payment mode (in which the payment card account number is read from an RFID chip (reference numeral 424 , FIG. 4 ) in the device by the POS terminal, which in turn initiates an authorization request for a purchase transaction) or a payment transaction request mode of operation, as described hereinabove in connection with FIG. 9 . In some embodiments, the customer may select the former mode simply by bringing the device 204 into proximity with the RFID/NFC reading component of a POS terminal 202 .
  • Selection of the latter mode may require positive input from the customer, as by selecting a suitable menu option displayed by the display 402 of the device 204 .
  • the latter mode may be entered semi-automatically, by receiving a message containing the transaction information, where the message is pushed to the device 204 by the merchant device 202 or by the payment service provider computer 502 , and the customer then responds affirmatively to the message to initiate the request for the payment transaction.
  • selecting either the purchase transaction mode or the payment transaction mode for the customer's mobile device 204 may require the customer to actuate a soft key, a dedicated button, or the like.
  • the customer's mobile device 204 may take its cue, in terms of selecting between the two modes, from a POS terminal 202 to which the mobile device 204 is presented. That is, if the POS terminal 202 is in the purchase transaction mode when the mobile device 204 is presented to the POS terminal's RFID/NFC component, then the purchase transaction mode may be automatically selected for the mobile device 202 , such that the mobile device uploads the payment card account number to the POS terminal in a conventional manner in response to a conventional interrogation signal from the RFID/NFC component.
  • the POS terminal may respond to the presence of the mobile device at the RFID/NFC component by pushing the transaction information to the mobile device via NFC, and in response to receiving the transaction information the mobile device enters the payment transaction mode.
  • FIGS. 2 , 5 , 6 , 11 , 13 , 15 and 16 each depict only system components that may be involved in a single transaction, rather than all of the components that may be present in the system.
  • each system may also include: (a) numerous other customer mobile devices 204 in addition to the one such device shown; (b) numerous other merchant devices 202 in addition to the one such device shown; (c) numerous other payment card account issuers in addition to the two issuing FIs typically shown in the drawings; (d) numerous service providers in addition to the service provider 1104 shown in FIG. 11 ; (e) numerous other employees and employers besides the single employee and single employer shown in FIG. 13 ; (f) a considerable number of additional funding sources in addition to the one shown in FIG. 15 .
  • the various system embodiments shown in the drawings may be combined in various combinations. For example, a single system may be provided which provides most or all of the features described with reference to FIGS. 2 , 5 , 11 , 13 , 15 and 16 .
  • the confirmation of the payment transaction is shown as flowing from the merchant's issuer to the merchant directly and indirectly via the payment services provider computer 502 .
  • the confirmation of the payment transaction may flow to the merchant via the payment system 210 and the payment services provider computer 502 .
  • payment transactions may also be requested via a mobile device by a payment card account holder to settle payments for services such as automobile rentals, taxi rides, airline and train fares, personal care services (e.g., hair salon services, manicures, personal training, etc.), health club and gym fees, medical and dental services, dry cleaning, home renovations, cultural and sporting event ticketing, periodical subscriptions, museum entrance fees, etc., etc. It is also not required that the merchant/service provider be face-to-face with the customer.
  • services such as automobile rentals, taxi rides, airline and train fares, personal care services (e.g., hair salon services, manicures, personal training, etc.), health club and gym fees, medical and dental services, dry cleaning, home renovations, cultural and sporting event ticketing, periodical subscriptions, museum entrance fees, etc., etc.
  • services such as automobile rentals, taxi rides, airline and train fares, personal care services (e.g., hair salon services, manicures, personal training, etc.), health club and gym fees, medical and dental services, dry cleaning, home renovations
  • payment transactions may be initiated by the customer to pay for telephone or online orders.
  • the customer's mobile device is a PDA
  • the customer may access an online store, which may push the transaction information, upon checkout, to the customer's mobile device (possibly via a PSP computer 502 ).
  • the customer's mobile device may then request a payment transaction to settle the online purchase.
  • the online store may receive confirmation via its issuing FI that the payment transaction is or will be completed before proceeding to fulfill the customer's order.
  • the above-noted advantage that the customer does not disclose his/her payment card account number to the merchant may be particularly attractive in the case of online purchases.
  • confirmed identification of the merchant (as per step 904 , FIG. 9 ) to the customer prior to requesting the payment transaction may also be a very significant, though optional, feature from the customer's point of view.
  • the payment services provider computer need not necessarily perform all of the services described.
  • the transaction information may be transmitted from the merchant device to the customer's mobile device, or entered manually into the customer's mobile device, which then sends the payment transaction request to the payment services provider computer for forwarding to the customer's issuing FI.
  • system architectures shown, e.g., in FIGS. 5 and 6 may also allow the customer's issuing FI to set policies for personalizing and/or customizing service practices, such that, for example: (a) credit offers may be made only to certain customers and/or in connection only with certain kinds of transactions; and (b) whether additional authentication procedures are required may be determined according to predetermined rules on a customer-by-customer and/or on a transaction-by-transaction basis. More complex rules may also determine when authentication is required, including for example rules based on recent transaction history for an account.
  • communications among the customer's mobile device 204 and/or the merchant device 202 and/or other components in the system may be carried, at least in part, via a conventional mobile telephone network, which is not explicitly shown in the drawings.
  • the customer's mobile device triggers the merchant device to download the transaction information to the customer's mobile device by transmitting a suitable signal to the merchant device, e.g., by NFC.
  • the merchant device may download the transaction information to the customer's mobile device in response to receiving such a signal from the customer's mobile device. Receiving such a signal may place the merchant device in the above-mentioned payment transaction mode of operation.
  • an “information message” includes a text message or any other message sent to or from a mobile device to transmit information other than audible or visual information.
  • mobile identifier refers to a mobile telephone number or any other identification information that uniquely identifies a mobile telephone or other mobile device.
  • the term “payment card account” includes a credit card account or a deposit account that the account holder may access using a debit card.
  • the term “payment card account number” includes a number that identifies a payment card account or a number carried by a payment card, or a number that is used to identify an account in a payment system that handles debit card and/or credit card transactions or 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 (including a pre-paid debit card).
  • the term “payment card account” also includes an account to which a payment card account number is assigned.
  • a payment card account may include an account to which payment transactions may be routed by a payment system that handles debit card and/or credit card transactions, even if the account in question is not eligible to be charged for purchase transactions or other transactions.
  • a payment card account may also include an account from which payment transactions may be routed by a payment system that handles debit card and/or credit card transactions, even if the account in question is not customarily used, or is not eligible, to be charged for purchase transactions.
  • the account numbers that identify the merchants' or other recipients' payment card accounts herein may be in a format and in an account number range that allow payment transactions to be routed to the accounts in question; the accounts may, but need not, be operable also for charging purchase transactions to such accounts.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A method includes receiving transaction information from a merchant device. The transaction information includes a transaction amount and merchant information that identifies a merchant that operates the merchant device. The method further includes receiving, from a mobile device, a request that a funds transfer be made from a payment card account that belongs to a customer who is operating the mobile device to a payment card account that belongs to the merchant. The method also includes forwarding the request to a financial institution that issued the payment card account that belongs to the customer.

Description

    CROSS-REFERENCE TO RELATED APPLICATION
  • This application claims the benefit of provisional patent application Ser. No. 60/977,260, filed Oct. 3, 2007, which application is incorporated herein by reference.
  • BACKGROUND
  • Embodiments disclosed herein relate to payment systems. In particular, some embodiments relate to methods, apparatus, systems, means and computer program products for implementing a payment system on the basis of a payment card system.
  • Payment card systems are in widespread use. A prominent payment card system is operated by the assignee hereof, MasterCard International Incorporated, and by its member financial institutions. FIG. 1 schematically illustrates a typical transaction, as carried out in a payment system 100. To initiate the transaction, a customer (not shown) visits a retail store (not shown) operated by a merchant, selects goods (not shown) that he/she wishes to purchase, carries the goods to the merchant's point of sale terminal 104, and presents his/her payment card 102 to the point of sale terminal 104. The point of sale terminal 104 reads the customer's payment card account number from the payment card 102, and then sends an authorization request to an acquirer financial institution (FI) 106 with which the merchant has a relationship. The authorization request includes the payment card account number and the amount of the transaction, among other information. The authorization request is routed via a payment card system 108 (which may be, for example, the well-known Banknet system operated by the assignee hereof) to the issuer financial institution 110 that issued the customer's payment card 102. Arrows 112, 114 and 116 trace the path of the authorization request from the POS terminal 104 to the issuer 110.
  • Assuming that all is in order, the issuer FI 110 transmits a favorable authorization response to the point of sale terminal 104 through the payment card system 108 and via the acquirer FI 106. (The path of the authorization response from the issuer FI 110 to the POS terminal 104 is traced by arrows 118, 120, 122.) The transaction at the point of sale terminal 104 is then completed and the customer leaves the store with the goods. A subsequent clearing transaction initiated by the merchant results in a transfer of the transaction amount from the customer's payment card account 124 to an account that belongs to the merchant. The customer's payment card account 124 may be, for example, either a debit card account or a credit card account. In the former case, the clearing transaction results in the funds being debited directly from the account 124. In the latter case, the clearing transaction results in a charge being posted against the account 124, and the charge subsequently appears on the customer's monthly credit card statement.
  • The foregoing description of the typical transaction may be considered to be somewhat simplified in some respects. For example, a so-called merchant processing system (not shown) may be interposed between the POS terminal and the acquirer FI. As is familiar to those who are skilled in the art, a merchant processing system may be operated by or on behalf of the merchant to form part of the communications path between the acquirer FI and a considerable number of POS terminals operated by the merchant. It is also often the case that a third party transaction processing service may operate to handle payment card transactions on behalf of the acquirer and on behalf of a large number of other like financial institutions.
  • The present inventors have now recognized that an existing facility of a payment card system, referred to as a “payment transaction”, may be utilized to provide more convenient and flexible handling of purchases of goods and other exchanges of value. Among other advantages, the transactions described herein may be conducted such that the customer need not disclose his/her payment card account number to the merchant. This may, in at least some circumstances, enhance the security of the customer's payment card account and lessen the possibilities for misappropriation of the payment card account number.
  • The novel use of payment transactions disclosed herein may also cause transactions to be conducted in such a manner that the customer may be made fully aware of all transaction details before the customer initiates the payment transaction. This may help to protect the customer from unintentionally authorizing erroneous or fraudulent payment card transactions, and may reduce the number of occasions in which transactions need to be reversed.
  • From the merchant's point of view, transaction techniques disclosed herein may save the merchant from having to enter into a relationship with an acquirer financial institution. This may be particularly advantageous for very small merchants or for merchants who do not have fixed places of business. Moreover, elimination of the “acquirer” function, as proposed herein, may result in savings in bank fees charged to merchants.
  • The present inventors have also recognized that the novel transaction techniques proposed herein present opportunities for novel value-added services which may be provided to customers, merchants and/or financial institutions.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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:
  • FIG. 1 is a block diagram that illustrates a conventional payment system.
  • FIG. 2 is a block diagram that illustrates a transaction-handling system in accordance with aspects of the present invention.
  • FIG. 3 is a block diagram that illustrates a point of sale terminal that is shown in FIG. 2.
  • FIG. 4 is a block diagram that illustrates a customer's mobile telephone that is shown in FIG. 2.
  • FIG. 5 is a block diagram that illustrates a transaction-handling system according to some other embodiments.
  • FIG. 6 is block diagram that illustrates another embodiment of a transaction-handling system.
  • FIG. 7 is a block diagram representation of a computer that provides payment services in the system of FIG. 5 or 6.
  • FIG. 8 is a flow chart that illustrates a process that may be performed by a point of sale terminal or other merchant device in connection with a transaction handled as in FIG. 2, FIG. 5 or FIG. 6.
  • FIG. 9 is a flow chart that illustrates a process that may be performed by a customer's mobile device in connection with a transaction handled as in FIG. 2, FIG. 5 or FIG. 6.
  • FIG. 10 is a flow chart that illustrates a process that may be performed by the computer of FIG. 7.
  • FIG. 11 is a block diagram that illustrates a bill payment system according to some embodiments.
  • FIG. 12 is a flow chart that illustrates a process that may be performed by a payment services provider computer in the system of FIG. 11.
  • FIG. 13 is a block diagram that illustrates a payroll disbursement system according to some embodiments.
  • FIG. 14 is a flow chart that illustrates a process that may be performed by a payment services provider computer in the system of FIG. 13.
  • FIG. 15 is a block diagram that illustrates still another embodiment of a transaction-handling system.
  • FIG. 16 is a block diagram that illustrates yet another embodiment of a transaction-handling system.
  • FIG. 17 is a flow chart that illustrates a process that may be performed in a point of sale terminal that may serve as the merchant device shown in FIG. 2.
  • DETAILED DESCRIPTION
  • In general, and for the purpose of introducing concepts of embodiments of the present invention, a payment card system payment transaction initiated from a customer's device (such as a mobile telephone) is utilized to consummate a purchase of goods or services. In some embodiments, the transaction information, such as an amount due for the purchase, and a code that identifies the merchant, may be entered into or transmitted to the customer's device. In the former case, the transaction information may be displayed by a merchant's device (e.g., a POS terminal) to be read by the customer and manually entered by the customer into the customer's device. The customer may operate his/her device to initiate a request for a payment transaction via the issuer of the customer's payment card account. The request may direct the customer's issuer to implement a transfer of funds from the customer's payment card account to the merchant's payment card account. The vehicle for the funds transfer may be a conventional payment transaction of the type now supported by at least one payment card system. The issuer of the customer's payment card account may cause the payment transaction to be routed via the payment card system to the issuer of the merchant's payment card account to be credited to the merchant's payment card account. Upon authorization/completion of the payment transaction, the merchant's issuer may confirm to the merchant that the funds transfer has occurred (or is assured to occur subsequently during conventional clearing operations), and in response to receiving the confirmation, the merchant may transfer ownership of the goods to the customer, or may accept the confirmation as payment for services rendered or to be rendered to the customer.
  • In this arrangement, the payment card transaction enters the system via a device operated by the customer and is initiated for routing from the customer's issuing financial institution, rather than originating from the merchant's POS terminal and the acquiring financial institution. Certain advantages of the rearranged and novel transaction flow described herein have been alluded to above and will be discussed in more detail below, along with other advantages and advantageous features.
  • In other aspects, a payment services provider computer may facilitate and/or relay communications between the merchant's device and the customer's device, and/or between the customer's device and the customer's issuer, and/or between the merchant's issuer and the merchant. In some embodiments, the payment services provider computer may be operated by the payment card organization (e.g., the assignee hereof) that routes payment transactions from customer issuers to merchant issuers and also routes purchase transactions from acquirers to issuers.
  • FIG. 2 is a block diagram that illustrates a transaction process in accordance with aspects of the present invention. The various components shown in FIG. 2, and discussed below, may be a subset of a larger system, indicated generally by reference numeral 200, for facilitating payments to merchants via credit cards, debit cards and the like. In the example embodiment illustrated in FIG. 2, only components of system 200 that operate with respect to a single transaction are shown.
  • The system 200 includes a merchant device 202, which may for example be a POS terminal or a suitably programmed mobile telephone or PDA (personal digital assistant) with communication capabilities. (The latter two possible embodiments of the merchant device may for example be particularly appropriate for merchants who operate without a fixed place of business. Examples of such merchants may be flea market sellers, artisans and crafters who sell their handiwork at craft fairs, itinerant merchants or merchants in third world marketplaces. For many merchants in the categories described in this parenthetical, it may not be practical or economic to enter into a conventional relationship with an acquirer FI.) If the merchant device is a POS terminal, the latter may operate for the most part in a conventional manner or may alternatively have functionality that actively contributes to the novel transaction flow illustrated in FIG. 2. The POS terminal may be operated in any type of business establishment or retail store, including a “mom and pop” operation all the way up to a big box store that is part of a mega retail chain. In some particularly helpful embodiments, the merchant device may be installed in a store such as a small antiques or collectibles shop or the like in which the low volume of transactions may weigh against the expense and paperwork requirements involved in entering into a merchant-acquirer relationship with an FI.
  • Among other capabilities, and as will be described further below, the merchant device 202 may display transaction information to be read by the customer (not shown) and manually inputted by the customer into his/her mobile device 204. For example, the merchant device may display the total amount due for the transaction, and a merchant identification number. Alternatively, the merchant ID may be permanently displayed on a sticker affixed to the merchant device 202. (In some embodiments, the merchant identification number may be the account number that identifies the merchant's payment card account to which payment transactions are to be routed. In other embodiments the merchant identification number may require translation into such an account number, e.g., in a manner as described below. If the merchant identification number is the merchant's payment card number, steps may be taken to prevent misuse of the account number. For example, the account corresponding to the account number may be enabled only to have funds transfers credited thereto, but not to receive charges via the payment card system, and with any transfers out of the account in question going into a companion account, with a different number, from which charges may be made.) The merchant identification number may in some embodiments be the merchant's mobile telephone number or another mobile identifier; this may be particularly convenient where the merchant device 202 is a mobile telephone.
  • In other embodiments, the merchant device 202 may have capabilities for transmitting the transaction information to the customer device 204. The transmitting of the transaction information from the merchant device 202 to the customer device 204 may be via wireless communication such as NFC (near field communication) or alternatively may be via a mobile telephone network using text messaging or the like.
  • The customer's mobile device 204 may for example be a mobile telephone with capabilities for initiating payment transactions in a payment card system. Operation of a mobile telephone to initiate funds transfers via a payment card system is for example described in commonly assigned U.S. patent application Ser. No. 11/836,945, filed Aug. 10, 2007, entitled “Payment Card Based Remittance System with Designation of Recipient By Mobile Telephone Number”, which is incorporated herein by reference. As an alternative, the customer's mobile device 204 may be a PDA with communication capabilities. In some embodiments, the customer's mobile device may initiate a payment transaction by interacting with a website operated by a payment services provider or by the issuer of the customer's payment card account.
  • FIG. 2 also shows, as included in the system 200, an issuer financial institution 206 which issued the customer's payment card account 208, a payment system 210 (such as the Banknet system referred to above) for routing transactions from issuer to issuer (and also, e.g., from acquirers to issuers), and an issuer financial institution 212 which issued the merchant's payment card account 214. Blocks 206 and 212 should also be understood to represent, respectively, computer systems operated by or on behalf of the customer issuer FI and the merchant issuer FI.
  • Arrows 216, 218, 220 trace the path of the payment transaction, requested from the customer's mobile device 204, as routed from the customer issuer 206, via the payment system 210 to the merchant issuer 212. Arrows 222, 224 and 226 trace the path of acknowledgement messages from the merchant issuer 212 via the payment system 210 and the customer issuer 206 to the customer's mobile device 204. Arrow 228 represents a confirmation message sent from the merchant issuer 212 to the merchant device 202 to confirm that the payment transaction to pay for the pending sale has or will be credited to the merchant account 214. Upon receiving the confirmation message 228 the merchant may allow the sale or other exchange of value to be completed.
  • Although only two issuing FIs, one mobile device and one merchant device are shown in FIG. 2, it should be understood that the system 200, in a practical embodiment, may include numerous issuing FIs all connected to the payment system 210, a large number of merchant devices 202 and a very large number of customer mobile devices. Furthermore, the system 210 preferably also operates in accordance with the conventional purchase transaction model illustrated in FIG. 1, and thus may include a considerable number of acquirer FIs as well. Of course, many if not all acquirer FIs may also be issuer FIs.
  • FIG. 3 is a block diagram of a POS terminal as provided in accordance with aspects of the invention to serve (in some embodiments) as the merchant device 202 shown in FIG. 2. In some embodiments, the POS terminal 202 may be largely or entirely conventional in its hardware aspects. Nevertheless, the POS terminal 202 may be programmed in accordance with the aspects of the present invention to provide functionality as described herein.
  • The POS terminal may include a processing element (or elements) such as the processor 302 shown in FIG. 3. The processor 302 may for example be a conventional microprocessor, and may operate to control the overall functioning of the POS terminal 202. The POS terminal may also include conventional peripheral components, in communication with and/or controlled by the processor 302, such as: (a) a keypad 304 for receiving input from the human operator of the POS terminal; (b) a barcode reader 306 for reading product barcodes from products brought to the terminal for purchase; (c) a cash drawer 308 for storing cash received from customers; (d) a magnetic stripe reader 310 for reading payment card account numbers and related information from magnetic stripe payment cards; (e) one or more displays 312 for providing output (e.g., identifying products presented for purchase and their prices, indicating sales tax due, indicating transaction subtotals and totals, etc.); (f) a printer 314 for printing out sales receipts; (g) a wireless communication terminal/proximity reader 316 for exchanging wireless short range communications/near field communications (NFC) with contactless payment cards and/or with mobile telephone equipped with contactless payment device capabilities; and (h) a communication controller 318 for allowing the processor 302, and hence the POS terminal 202 to engage in communication over data networks with other devices (e.g., a merchant processing system (not shown), an acquirer (not shown) or its transaction processor (not shown), an issuer 212 (FIG. 2) of the merchant's payment card account, etc. (In some embodiments, at least one of the displays 312 may be a touch screen, so as to provide an input function as well as an output function.) In some embodiments, the communication controller, or another communication device coupled to the processor 302, may be provided to allow the POS terminal 202 to transmit and receive text messages or the like via a mobile telephone network (not shown). In addition, the POS terminal 202 may include one or more memory and/or data storage devices (indicated collectively at 320), 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) 320 may store software and/or firmware that programs the processor 302 and the POS terminal 202 to perform functionality as described herein. Further, the POS terminal may include one or more housings (not shown) which contain and/or support one or more of the other components shown in FIG. 3.
  • Those who are skilled in the art will recognize that components 310, 316 may be integrated in a single unit, and may include a display/touch screen to allow for user interaction.
  • FIG. 4 is a block diagram of an example mobile telephone which may serve as the customer's mobile device 204 shown in FIG. 2. The mobile telephone 204 shown in FIG. 4 may also (but need not) have capabilities for functioning as a contactless payment device. In its hardware aspects the mobile telephone 204 may be entirely conventional, and indeed in its software aspects it also may be conventional, and may provide novel functionality as described herein through interaction (via a conventional browser) with a web page that supports initiation of payment transactions. In other embodiments, however, novel functionality as described herein may result at least partially from software and/or firmware that programs the mobile telephone 204.
  • The mobile telephone 204 may include a conventional housing (indicated by dashed line 402) that contains and/or supports the other components of the mobile telephone 204. The mobile telephone 204 further includes conventional control circuitry 404, for controlling over-all operation of the mobile telephone 402. Preferably the control circuitry 404 is suitably programmed to allow the mobile telephone 204 to engage in data communications and/or text messaging with other devices, and to allow for interaction with web pages accessed via browser software, which is not separately shown. Other components of the mobile telephone 204, which are in communication with and/or controlled by the control circuitry 404, include: (a) one or more memory devices 406 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module) card 408; (c) a conventional keypad 410 (or touch screen) for receiving user input; and (d) a conventional display 412 (or, again, touch screen) for displaying output information to the user.
  • The mobile telephone 204 also includes conventional receive/transmit circuitry 416 that is also in communication with and/or controlled by the control circuitry 404. The receive/transmit circuitry 416 is coupled to an antenna 418 and provides the communication channel(s) by which the mobile telephone 204 communicates via the mobile network (not shown). The mobile telephone 204 further includes a conventional microphone 420, coupled to the receive/transmit circuitry 416. Of course, the microphone 420 is for receiving voice input from the user. In addition, a loudspeaker 422 is included to provide sound output to the user, and is coupled to the receive/transmit circuitry 416.
  • The mobile telephone 204 may also include an integrated circuit (IC) or chipset 424 of the kind embedded in contactless payment cards. For example, the IC 424 is connected to an antenna 426 and operates so as to interact with an RFID/NFC proximity reader of a POS terminal to provide a payment card account number for a purchase transaction at the POS terminal. For example, the IC 424 may be designed/programmed to operate in accordance with the well-known “PayPass” standard (promulgated by the assignee hereof) for contactless payment applications.
  • FIG. 5 is a block diagram that illustrates an alternative embodiment (generally represented by reference numeral 200 a) of the system shown in FIG. 2. The system 200 a of FIG. 5 may include every component shown in FIG. 2, while also including a payment services provider (PSP) computer 502 that provides “on behalf” and/or value added services. For example, as seen from FIG. 5, the PSP computer 502 may exchange communications (by wireless communications and/or landline communications) with each of the merchant device 202, the customer's mobile device 204 and the customer issuer 206. As will be seen, among other functions, the PSP computer 502 may operate to relay communications between the merchant device 202 and the customer's mobile device 204, and between the customer's mobile device 204 and the customer issuer 206. Although only one PSP computer 502 is shown, in practice it may be desirable to provide a considerable number of PSP computers, each serving a respective geographical region.
  • One potential advantage of the architecture shown in FIG. 5 is that the PSP computer may effectively provide front end processing on behalf of the customer issuer 206 so that the revised transaction flow proposed herein may be implemented with little or no modification to the operations of the customer issuer 206.
  • The PSP computer or computers 502 may in some embodiments be operated by the payment card association which also operates the payment system 210. Thus the PSP computer(s) 502 may be a vehicle for the payment card association to enhance its service offerings for issuers, cardholders and/or merchants.
  • FIG. 6 is a block diagram that illustrates still another embodiment (generally represented by reference numeral 200 b) of the systems shown in FIGS. 2 and 5. The system 200 b of FIG. 6 includes all of the components shown in FIG. 5. However, in the system embodiment as shown in FIG. 6, the PSP computer 502 performs the additional function of relaying the payment transaction confirmation 602 from the merchant issuer 212 to the merchant device 202. Thus it could be said that the PSP computer 502 is performing “on behalf” services for both the customer issuer and the merchant issuer.
  • FIG. 7 is a block diagram representation of an example PSP computer 502 which may be operated as part of the systems shown in FIG. 5 or FIG. 6
  • The PSP computer 502 may be conventional in its hardware aspects but may be controlled by software to cause it to operate in accordance with aspects of the present invention.
  • The PSP computer 502 may include a computer processor 700 operatively coupled to a communication device 701, a storage device 704, an input device 706 and an output device 708.
  • The computer processor 700 may be constituted by one or more conventional processors. Processor 700 operates to execute processor-executable steps, contained in program instructions described below, so as to control the PSP computer 502 to provide desired functionality.
  • Communication device 701 may be used to facilitate communication with, for example, other devices (such as customers' mobile devices 204, merchant devices 202, customer issuer computers 206 and/or merchant issuer computers 212). Communication device 701 may, for example, have capabilities for sending and receiving messages over mobile telephone networks, as well as engaging in data communication over conventional computer-to-computer data networks.
  • Input device 706 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, the input device 706 may include a keyboard and a mouse. Output device 708 may comprise, for example, a display and/or a printer.
  • Storage device 704 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and 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.
  • Storage device 704 stores one or more programs for controlling processor 700. The programs comprise program instructions that contain processor-executable process steps of PSP computer 502, including, in some cases, process steps that constitute processes provided in accordance with principles of the present invention, as described in more detail below.
  • The programs may include an application 710 that manages a process by which customers (i.e., cardholders) may enroll themselves and/or their mobile devices with the PSP computer 502. In some embodiments, the cardholder enrollment process may allow the cardholders to enroll themselves with the PSP computer 502 by accessing via their mobile devices 204 a suitable web page hosted by the PSP computer 502. The information gathered from the cardholder during the enrollment process may include payment card account number and mobile telephone number (or other mobile identifier). The enrollment process may also require the cardholder to select a PIN (personal identification number) to be used for security purposes in connection with payment transactions to be initiated by the cardholder via his/her mobile telephone and via the PSP computer 502. Other security measures may also be put in place. The PSP may cooperate with the cardholder's issuing FI to provide security measures that assure that the individual enrolling with the PSP computer 502 is not an impostor.
  • The storage device 704 may also store an application 712 for managing enrollment of issuing FIs with the PSP computer 502. In some embodiments, actual enrollment of FIs with the PSP computer 502 may be performed by data entry or file downloads managed by an administrative employee of the entity that operates the PSP computer 502. This may occur after person-to-person contacts between an employee of the operator of the PSP computer 502 and an employee of the FI that is seeking enrollment. The FI may be enrolled as a customer issuer, a merchant issuer, or both. In some embodiments, the FI, as part of its enrollment process, may also enroll its account holders (consumers and/or merchants) en masse with the PSP computer 502. Further, after enrollment of an FI, it may thereafter, from time to time, feed to the PSP computer 502 enrollments of consumer and/or merchant holders of payment card accounts issued by the FI.
  • Another application that may be stored by the storage device 704 is for handling individual transactions and is indicated by reference numeral 714 in FIG. 7. Details of operation of the transaction handling application 714 will be discussed hereinbelow, particularly with reference to FIG. 10.
  • Still another application 716 may be stored by the storage device 704 and may operate in conjunction with the transaction handling application 714 to provide special value added services to individual consumer cardholders. Examples of such special services will be described below.
  • In addition, applications 718 and 720, both stored by the storage device 704, respectively provide special value added services to merchants and to issuer FIs.
  • Reference numeral 722 in FIG. 7 identifies one or more databases that are maintained by the PSP computer 502 on the storage device 704. Among these databases may be a consumer cardholder database, a merchant database, an issuer database and a transaction database.
  • The application programs of the PSP computer 502 as described above, may be combined in some embodiments, as convenient, into one, two or more application programs. Moreover, the storage device 704 may store other programs, such as one or more operating systems, device drivers, database management software, web hosting software, etc.
  • FIG. 8 is a flow chart that illustrates an example sales transaction process that may be performed by the merchant device 202 (FIGS. 2, 5, 6) in accordance with aspects of the present invention.
  • At 802 in FIG. 8, information to define the transaction is entered into the merchant device 202. For example, if the merchant device is a conventional POS terminal, at least some of the transaction information may be entered by using a barcode scanning component of the POS terminal to scan the product identification barcodes from one or more items presented for purchase by the customer. In accordance with conventional practices, upon reading the product barcodes, the POS terminal retrieves the prices for the items to be purchased (and possibly the product description and other information as well) and generates a subtotal and a total (e.g., including sales tax) for the sale transaction. Some or all of the steps referred to in the previous sentence may be considered to be “generating transaction data” and are represented at 804 in FIG. 8. Moreover, as will be seen, for subsequent stages in the transaction, a set of transaction data for the transaction in question may include identifying codes (e.g. ID numbers) for either or both of the POS terminal and the merchant who is the proprietor of the POS terminal. Thus generating the transaction data may include generating a set of information for the transaction that includes the amount due for the transaction and one or both of the merchant identifier and the POS terminal identifier. Generating the transaction data may also included generating and including in the set of data a unique identifying number for the transaction (transaction identifier/reference number). In some cases, the transaction data generated at 804 may also include line items and/or product descriptions.
  • From the “first world” (possibly mega-retailer) example embodiment of steps 802-804 as described up to this point, the discussion will now turn to a radically different example embodiment, suitable for use even in a developing country. Assume, then, that the merchant device 202 is a suitably programmed mobile telephone owned by an individual merchant. The merchant may, for example, be a farmer or a dealer in produce, handicrafts, second-hand or new clothing or anything else commonly traded by individual entrepreneurs in the markets of third world countries. It may be assumed further that the merchant conducts his or her business in a stall or at a table in an open air market, without electricity or any other modern convenience. Further assume that the merchant is “banked” only to the extent of holding a payment card account issued by an FI and by being enrolled as a merchant with respect to the payment card account (i.e., the FI in question does not act as a purchase transaction acquirer for the merchant, in this scenario). In such a situation, the entry 402 of the purchase information may consist simply in the merchant entering a sales transaction total amount due into the merchant device/mobile telephone 202 via the keypad of the device 202. (The total amount due may for example have been arrived at by the merchant adding in his/her head—or on a separate calculator—the prices of the items purchased, or may be calculated by a calculator function in the mobile telephone 202 (another example embodiment of 804) from individual item prices manually entered (another example embodiment of 802) one after the other into the mobile telephone by the merchant.) The generating of the transaction data may consist in assembling a transaction data set consisting of just two items of data—amount due, and the mobile telephone number assigned to the merchant device/mobile telephone 202. These two data items may form the payload of a text message/SMS message or other type of information message to be sent to the customer's mobile telephone (mobile device 204). (Alternatively, the mobile telephone network may operate so that, by a “caller ID” feature the mobile telephone number assigned to the merchant device 202 is automatically provided to the customer mobile telephone 204 when the text message or other information message is received.) In any event, the merchant may receive (step 806, FIG. 8) from the customer, by oral face to face communication, the mobile telephone number assigned to the customer's mobile telephone 204 and may enter that number into the merchant's mobile telephone 202, so that the transaction information may be transmitted (step 808, FIG. 8) from merchant device 202 to customer mobile device 204. (For definitional purposes, transmission of the transaction information should be understood to encompass provision of the merchant mobile telephone number from the merchant mobile telephone to the customer mobile telephone via a “caller ID” feature of the mobile network. It should also be noted that the merchant mobile telephone number may serve as a merchant identifier for purposes of the customer's subsequent initiation of a request for a payment transaction.)
  • As will be expected from previous discussion, and as will be described further below (e.g., in conjunction with FIG. 9), the customer may next operate his mobile telephone 204, using the transaction information transmitted thereto from the merchant device 202, to request that a payment transaction be carried out in the payment system (e.g., system 200, FIG. 2) to transfer the transaction amount from the customer's payment card account 208 to the merchant's payment card account 214. While this is occurring, the merchant/merchant device 202 may wait (block 810, FIG. 8) to receive the confirmation 228 (FIG. 2) that the funds transfer has been or will be accomplished via the channels of the payment card system 210. Once the confirmation is received by the merchant device 810 (the whole process may require only a few seconds), the merchant transfers title in the purchased items to the customer, and the transaction is complete (FIG. 8—block 812).
  • Before returning to the “mega-retailer” scenario with which we opened discussion of FIG. 8, there will be a brief mention of advantages provided by aspects of the present invention in the above-described third world market scenario. Perhaps most important, the process of FIG. 8 is cashless, so that neither the merchant nor the customer takes on the often large risks of carrying and holding cash in a third world environment. Also, this process leverages on the already existing prevalence of mobile telephones among third world merchants and consumers. The banking relationships required by the participants are also such as may be established and maintained at relatively low cost, thus minimizing the economic barriers to adoption. Still further, the system is an open one, in the sense that the parties need not have a relationship with the same financial institution/service provider, but need only have low level banking relationships with respective FIs that belong to a widespread payment card system such as that organized by the assignee hereof. Finally, the parties do not need to even use the same mobile network operator (MNO), so long as their respective MNOs are interoperative.
  • Returning now to the previous example in which the merchant device 202 was a conventional POS terminal, it will be recalled that the POS terminal 202 had received entry of purchase information (802 in FIG. 8) and had generated transaction data for the sales transaction (804 in FIG. 8). It may next possibly be the case (806, FIG. 8) that the customer will orally advise the POS terminal operator of the customer's mobile telephone number (or other mobile identifier), so that the POS terminal operator may enter the customer's mobile telephone number (or other mobile identifier) into the POS terminal, as a prelude to the POS terminal transmitting the transaction data (808 in FIG. 8) to the customer's mobile device. (As suggested above, the transmission may be a text message/SMS or the like.) However, in a high-volume retail environment, it may be preferred not to take the time for such an oral exchange of information and manual entry of the telephone number. Instead, for example, the POS terminal may transmit the transaction information to the customer's mobile device via NFC (near field communication) or the like. As another alternative embodiment of 808, the POS terminal may display the transaction information (e.g., total amount due and merchant/POS terminal identifier) for the customer to manually enter into his/her mobile device. (The merchant/POS identifier may even be permanently displayed on a sticker or placard, for example.) Although the NFC (or such) example embodiment of step 808 may be preferable for a high volume environment, any of the other alternatives set forth above may be quite appropriate for a retail establishment in which the transactions are relatively infrequent.
  • In still another embodiment of step 808, the POS terminal 202 may transmit the transaction information to a payment services provider computer 502 (FIGS. 5 and 6), which may in turn relay the information to the customer's mobile device 204. Presumably in this embodiment of step 808 it may be necessary for the POS terminal to receive, either by wireless communication or by operator data entry, a mobile telephone number or other addressing information for the customer's mobile device 204. In this embodiment, the POS terminal may include the mobile telephone number or other addressing information for the customer's mobile device 204 in the transmission to the payment services provider computer 502, so that the payment services provider computer 502 may in turn route the transaction information to the customer's mobile device 204. In another variation, the POS terminal 202 may include a transaction reference number in the transmission to the payment services provider computer 502, and may also transmit the transaction reference number to the customer's mobile device 204. (Or, the POS terminal 202 may display the transaction reference number, and the customer may enter the transaction reference number into the mobile device 204.) The customer may then use the mobile device 204 to call in to the payment services provider computer 502 and use the transaction reference number to identify to the payment services provider computer 502 the transaction information to be relayed from the payment services provider computer 502 to the customer's mobile device 204.
  • In still another variation, the transaction reference number may be unique only to the merchant, so that the merchant identifier may also be needed to index the transaction information within a database maintained by the payment services provider computer 502. The merchant identifier may be transmitted to the customer's mobile device 204 by the POS terminal 202 or may be displayed by the POS terminal 202 for the customer to read and enter into the mobile device 204. As an alternative to the possibilities stated in the previous sentence, when the customer calls in to the payment services provider computer 502 with the mobile device 204, the mobile device 204 may report its current location (via GPS—Global Positioning System—data or the like) to the payment services provider computer 502; the payment services provider computer 502 may then infer, from the location information, the identity of the merchant at which the customer and his/her device are currently located. For such a purpose, the payment services provider computer 502 may maintain a database of merchant locations.
  • In some embodiments, the transaction information transmitted by the POS terminal 202 to the customer's mobile device 204 or to the payment services provider computer 502, as the case may be, may include line item information that identifies individual product items that are included in the current sale transaction.
  • Even in the case of the mega-retailer example, the process of FIG. 8 may end as in the third world market example, with the merchant device 202 (currently assumed to be a POS terminal) waiting (810 in FIG. 8) to receive from the merchant's FI (or a PSP acting as an intermediary) confirmation of the payment transaction in favor of the merchant's account 214. The transaction is then completed (step 812). For example, the merchant releases goods purchased to the customer and/or uses the merchant device 202 to print a receipt for the transaction and gives the receipt to the customer.
  • It should be understood that, for relatively small and/or mobile merchants, the third world model described above may be conveniently adopted even in a developed country, and that the merchant device 202 accordingly may be a mobile telephone in the case of any merchant who lacks or prefers not to use a POS terminal, regardless of the merchant's location.
  • According to one possible feature of the above described merchant device process, and although not indicated in FIG. 8, the process could have a time-out feature such that the merchant device aborts the transaction if the payment transaction confirmation is not received within a predetermined waiting period.
  • FIG. 9 is a flow chart that illustrates a process that may be performed by the customer's mobile device 204 in connection with a transaction handled as in FIG. 2, FIG. 5 or FIG. 6.
  • At 902 in FIG. 9, the mobile device 204 may receive the transaction information or the transaction information may be entered into the mobile device 204 by the customer's interaction with the user interface offered by the mobile device 204. If the mobile device receives the transaction information, this may occur by wireless transmission from either the merchant device 202 or from the payment services provider 502. In some embodiments, the transaction information and/or other information received by the customer's mobile device 204 may (as indicated at 904 in FIG. 4) include the name of the merchant. For example, the name of the merchant may be transmitted to the customer's mobile device 204 by the payment services provider 502 or by the customer's issuing FI 206. In effect, the payment services provider 502 may serve as a trusted third party to verify the identity of the merchant and to protect the customer from dealing with an impostor. The payment services provider may be able to vouch for the merchant because the merchant has gone through an enrollment process with the payment services provider or with an FI that is trusted by the payment services provider. In this way, the customer may be assured of the merchant's identity before the customer initiates the payment transaction.
  • Next, at 906, the customer's mobile device 204 generates a request for a payment transaction. In some embodiments, the request for a payment transaction includes the transaction amount and a merchant identification code. The request for the payment transaction may also include an identification code or number that identifies the customer. This code or number may be explicitly included in the request or may be implicitly generated as, e.g., a caller identification that identifies the mobile telephone number assigned to the mobile device 204. The identifier for the customer may for example thus be the mobile telephone number assigned to the mobile device 204 or the payment card account number that identifies the customer's payment card account that is to be used to fund the payment transaction. In some embodiments, the merchant identification code may be one or more of a mobile telephone number assigned to the merchant device 202, or the payment card account number that identifies the merchant's payment card account that is to be credited by the payment transaction, or an identifier that otherwise identifies the merchant, such as a code used to index the merchant's record in a database maintained by a payment services provider computer 502. In addition, an identifier for the particular merchant device 202 may also be included in the payment transaction request.
  • In other embodiments, the request need only refer to the transaction by a transaction reference number, with the payment services provider computer 502 being relied upon to look up the other transaction information, such as merchant ID and transaction amount.
  • At 908, the customer's mobile device 204 transmits the request for a payment transaction. In some embodiments, the mobile device 204 transmits the request for a payment transaction to the FI 206 (FIG. 2) which issued the customer's payment card account. In other embodiments, the mobile device 204 transmits the request for a payment transaction to a payment services provider, as in FIGS. 5 and 6.
  • In some embodiments, the request for a payment transaction may explicitly include the customer's payment card account number, the merchant's payment card account number and the amount of the requested payment transaction, in which case the request may be handled in a straightforward manner by the customer's FI 206. In other embodiments, the customer and/or the merchant may be identified by their respective mobile telephone numbers or in another manner apart from their payment card account numbers. If so, the customer's FI may translate the customer's mobile telephone number (whether explicitly or implicitly (by caller ID) included in the request) into the customer's payment card account number, and the payment system 210 may translate the merchant's mobile telephone number into the merchant's payment card account number and may route the transaction accordingly. In other embodiments, the payment services provider computer 502 may perform one or both of the translations referred to in the previous sentence.
  • In some embodiments, the customer's mobile device, and hence the customer, may be identified by a SIM identifier or the like rather than by mobile telephone number.
  • In some embodiments, the payment transaction request transmitted by the customer's mobile device 204 may include line item information that identifies individual product items that the customer is purchasing.
  • In some embodiments, an authentication procedure (block 910) may be included in the process of FIG. 9. This may go beyond requiring the customer to enter a PIN in order to access the payment transaction request function. For example, the customer's issuer 206, and/or the payment services provider computer 502 acting on behalf of the customer's issuer, may selectively require additional authentication in the case of certain transactions, based on various criteria. These criteria may include, for example, the amount of the requested payment transaction, the time of day and/or day of the week, the item(s) being purchased, the identity of the customer and/or the identity of the merchant. Recent or past account activity or inactivity may also be taken into consideration in determining whether to require authentication.
  • The authentication procedure may include an exchange of text messages and/or electronic mail messages (or another type of information message) via the customer's mobile device 204 or a telephone conversation via the customer's mobile device 204. The exchange of messages and/or the telephone conversation may be handled by a human employee of the customer issuer 206 and/or the payment services provider 502. Alternatively, the exchange of information messages may be automatically conducted by computer on the part of the customer issuer 206 and/or the payment services provider 502, or the customer may be required to “converse” with an automated voice response system operated by the customer issuer 206 and/or the payment services provider 502. The exchange of messages or telephone conversation may include issuing a “challenge” to the customer, such as requiring the customer to provide one or more items of security information (e.g., date of birth, mother's maiden name, birthplace, home telephone number, home address, Social Security number, etc.).
  • In other embodiments, and assuming that the customer's mobile device is a mobile camera-phone, the authentication procedure may call for the customer to use the mobile device to take his/her picture and send it to the authenticating authority so that an individual employee of the authenticating authority may compare the picture with another picture of the customer that is previously on file.
  • In some embodiments, demographic information about customers as collected by the customers' mobile network providers may be provided to merchants for market research purposes.
  • In some embodiments, the process of FIG. 9 may include value added services (block 912), provided to the customer by either of both of the customer's issuer 206 and the payment services provider 502. These value added services may be such as cannot readily be provided in the conventional transaction flow depicted in FIG. 1.
  • For example, if the customer requests a payment transaction at a time when the customer has exceeded his/her credit limit or has depleted his/her debit card account, the customer's issuer 206 (or the payment services provider acting on behalf of the customer's issuer 206) may respond to the request for a payment transaction with a message (sent to the customer's mobile device 204) offering to make an overdraft or credit facility available to the customer, so that the request for a payment transaction can be honored.
  • According to another special service, the customer's issuer 206 and/or the payment services provider 502 (in this case not necessarily acting on behalf of the customer's issuer 206) may present the customer (via a message or messages to the mobile device 204) with one or more promotional offers and/or virtual coupons which the customer may avail himself/herself with to fund at least a portion of the payment transaction. For example, based on the identity of the merchant (and the customer not previously being enrolled with the merchant), the payment services provider 502 may offer on behalf of the merchant that a portion of the payment transaction will be funded by the merchant if the customer enrolls in the merchant's customer loyalty program.
  • In another example, an offer provided by a third party may be contingent on the customer adding an additional item to the pending transaction. For example, say the customer is purchasing an item that requires installation, and is also purchasing a warranty on the item. The manufacturer or warranty provider may offer to be a source of funding for a portion of the purchase price, contingent on the customer purchasing installation services for the item from the merchant. This offer benefits the merchant, by increasing the merchant's installation business; benefits the customer, by reducing the customer's cost for the transaction; and benefits the manufacturer/warranty provider by increasing the likelihood that installation will be performed correctly, thereby decreasing the likelihood of a warranty claim.
  • In still another example, suppose that the customer is purchasing an item that requires installation during a particularly busy time period such as the holiday season. In this case, a third party installation provider may offer to partially fund the transaction on the condition that the customer agree to defer installation until after the busy period is over.
  • Alternatively, the customer's issuer 206 (or the payment services provider 502 acting on behalf of the customer's issuer 206) may offer to fund part of the payment transaction if the customer agrees to open a deposit account with the customer's issuer. (Additional examples and a further discussion of “split-funding” of payment transactions will be described below in conjunction with FIG. 15.)
  • At 914 in FIG. 9, the customer's mobile device 204 receives a message that confirms that the payment transaction has been executed (possibly subject to a subsequent clearing operation). The customer's mobile device 204 may for example receive this confirmation message from the customer's issuer 206 or from the payment services provider computer 502. However, in alternative embodiments step 914 may be omitted, and the customer may effectively be informed that the payment transaction has gone through based on the merchant's willingness to complete the sales transaction, release the goods to be purchased, issue a receipt, etc. in response to the merchant device 202 receiving confirmation of the payment transaction.
  • FIG. 10 is a flow chart that illustrates a process that may be performed by the payment services provider computer 502.
  • At 1002 in FIG. 10, the payment services provider computer 502 receives the transaction information from the merchant device 202. As will be appreciated from previous discussion, the transaction information may include the amount of payment to be made for the transaction and merchant identifying information, such as a merchant number or a mobile telephone number that was assigned to the merchant device 202. (As noted above, the merchant device 202 may be a mobile telephone, or alternatively a POS terminal or PDA.) In some cases, the transaction information also includes a transaction reference number assigned by the merchant device, for use in subsequent communications among the payment services provider computer 502, the merchant device 202 and the customer's mobile device 204. The transaction information may also include details of the transaction, including information that identifies the items purchased, line item pricing, promotional offers or coupons made available by the merchant, etc. The transaction information may also include addressing information to allow the payment services provider computer 502 to contact the customer's mobile device 204. Further, the transaction information may include particulars about the merchant device and/or capabilities of the merchant device (e.g., whether the merchant device is a POS terminal or a mobile phone; if the latter, what the capabilities are of the mobile phone; whether the merchant device is NFC/RFID capable). Another category of transaction information may include encryption- and/or authentication-related information, such as the merchant's public keys for digital signatures, etc. Still another category of transaction information may include information that identifies the merchant's physical location, or the location of the merchant device. The addressing information may for example be a mobile telephone number assigned to the customer's mobile device 204.
  • At 1004 in FIG. 10, the payment services provider computer 502 may use the addressing information for the customer's mobile device 204 to transmit at least some of the transaction information to the customer's mobile device 204. In some embodiments, the payment services provider computer 502 may have looked up the name of the merchant based on the merchant identifying information received from the merchant device 202, and the payment services provider computer 502 may append the name of the merchant to transaction information that the payment services provider computer 502 transmits to the customer's mobile device.
  • At 1006 in FIG. 10, the payment services provider computer 502 receives a request for a payment transaction from the customer's mobile device 204. In some embodiments, the request may consist entirely of an indication to the effect of “yes, I want to go ahead with the transaction” plus the transaction reference number. In other embodiments, the request for the payment transaction, as received from the customer's mobile device, may include more detail, such as transaction amount (amount to be transferred by the payment transaction), merchant identifier (e.g., merchant mobile telephone number) and customer identifier (e.g., customer mobile telephone number—included explicitly in the request or implicitly by caller ID, or customer's payment card account number, or another code or reference that identifies the customer).
  • At 1008, in some embodiments, the payment services provider computer 502 may undertake an authentication procedure or procedures, as described above in connection with step 910 in FIG. 9, and/or the payment services provider computer 502 may offer or provide certain special services, promotional offers, credit offers, as described above in connection with step 912 in FIG. 9. In some cases, the special services, for example, may be initiated earlier in the process, such as in conjunction with step 1004. That is, the transaction information that the payment services provider computer 502 transmits to the customer's mobile device at 1004 may include offers of special services, etc.
  • Another type of special service that may be provided by the payment services provider computer, and not mentioned up to now, may entail enforcing restrictions on usage of the customer's payment card account 208. Consider, for example, a payment card account set up by a parent for his/her college student child. The parent may be able to set up restrictions as to (a) which merchants the payment card account may be used to pay (college bookstore and dining hall only, e.g.), and/or (b) a maximum dollar amount of transactions allowed per period of time (e.g., $100.00 per week). The payment card account may be restricted as invalid for purchase transactions or other transactions that are not payment transactions as described herein, so that the payment services provider computer (in enforcing the parental restrictions) effectively may have complete control over the use of the payment card account.
  • In another embodiment, the customer's issuing FI 206, rather than the payment services provider computer, may enforce restrictions of the sort described in the previous paragraph.
  • In other embodiments, when the child requests a payment transaction of a kind that is not permitted by existing parental restrictions, the PSP computer 502 or the customer FI 206 may send a real time inquiry message to the parent, asking whether the parent will allow the particular transaction. If the parent approves the requested payment transaction, the PSP computer 502 or the customer FI 206 proceeds with the requested payment transaction. If the parent does not approve, the requested payment transaction is declined. With this arrangement, it will be appreciated that the child may phone the parent ahead of time to alert the parent that the child intends to request a payment transaction that falls outside the established restrictions.
  • In another example in which a restricted use payment card account may be useful, consider the case of a well-to-do individual who hires a personal assistant to help in managing his/her household. The employing individual may set up a restricted-use payment card account for the assistant to use in paying some of the household expenses, but again limited to certain suppliers (e.g., grocery store, house-cleaning contractor, utility companies, etc.) and/or to a maximum amount per period of time.
  • At 1010, the payment services provider computer 502, to the extent required, may translate the customer identifying information (e.g., customer's mobile telephone number) into the customer's (funding) payment card account number for the requested payment transaction, and the payment services provider computer 502 may translate the merchant's identifying information (e.g., the merchant's mobile telephone number) into the payment card account number for the merchant's account to which the payment transaction is to be routed.
  • Next, at 1012, the payment services provider computer 502 may forward the request for the payment transaction to the customer's issuing FI 206. As forwarded by the payment services provider computer 502, the request for the payment transaction may include all information that the customer's issuing FI 206 may need to process the payment transaction in a conventional manner. Thus, the request as forwarded by the payment services provider computer 502 to the customer's issuing FI 206 may include the payment card account number for the funding payment card account (issued by the FI 206 to the customer), the amount of the payment transaction, and the payment card account number for the merchant's payment card account to which the payment transaction is to be routed.
  • In some embodiments, the payment services provider computer 502 may have no more involvement in the transaction. For example, the payment transaction may proceed from the customer's FI 206 to the merchant's FI 212 via the payment system 210, and the merchant's FI 212 may provide a confirmation 228 (FIG. 5) to the merchant device 202 to allow for completion of the sales transaction between the merchant and the customer. In other embodiments, however, the payment services provider computer 502 may be in the communication path between the merchant FI 212 and the merchant device 202, as illustrated in FIG. 6. That is, and as indicated at 1014 in FIG. 10, the payment services provider computer 502 may receive from the merchant FI 212 an authorization response to indicate that the merchant's account exists and is in a proper status to receive the payment, so that the payment transaction will go through (or has gone through). Then, at 1016 in FIG. 10, the payment services provider computer 502 may provide a confirmation of the payment transaction to the merchant device 202 to allow for completion of the sales transaction. Also, and optionally, the payment services provider computer 502 may provide confirmation of the payment transaction to the customer's mobile device 204 (step 1018). In some embodiments, to facilitate at least steps 1014 and 1016, the request for the payment transaction, as forwarded from the payment system 210 to the merchant FI 212, may include a transaction reference number that the merchant FI 212, in turn, includes in the authorization response. In that way, the payment services provider computer 502 is able to retrieve its record of the transaction upon receiving the authorization response, and is able to provide a proper confirmation message to the merchant device 202.
  • FIG. 11 is a block diagram that illustrates a bill payment system 1102 according to some embodiments. The bill payment system 1102 may have the following components in common with the payment system 200 b shown in FIG. 6: (a) mobile device 204 (customer's mobile device); (b) payment services provider computer 502; (c) issuing FI 206 (for the customer's payment card account); (d) payment system 210; and (e) receiving/issuing FI 212. However, instead of the merchant device 202 shown in FIG. 6, the bill payment system 1102 includes a service provider computer 1104 operated by or on behalf of a service provider such as a public utility, a daily or periodical publication or any other entity with a large customer base that it regularly sends bills to. Moreover the receiving issuer FI 212 in the case of the system 1102 receives payment transactions for the service provider rather than for a retail merchant.
  • FIG. 12 is a flow chart that illustrates a process that may be performed by the payment services provider computer 502 in the bill payment system 1102 of FIG. 1.
  • At 1202 in FIG. 12, the payment services provider computer 502 receives a batch of billing information from the service provider 1104 (for example, an electric utility company). Let us assume that the billing information concerns monthly electricity bills from the service provider 1104 to its residential subscribers (or at least for those who have signed up for bill payment through the system 1102 illustrated in FIG. 11). The billing information may contain numerous records, each of which represents a single bill. Each record may contain, for example, the amount of the bill, a customer identifier for the customer in question, and the mobile telephone number for the customer in question (or alternatively, the mobile telephone number may serve as the customer identifier), a record number, etc. (In some embodiments, the service provider 1104 may also send the billing information directly to the customer's mobile device 204, as indicated by arrow 1106 in FIG. 11.)
  • At 1204 in FIG. 12, the payment services provider computer 502 transmits the billing information in each record to the mobile device 204 (only one shown) that belongs to the respective customer for the billing record. In effect, the information transmitted to the customer's mobile device may indicate, “Your monthly electric bill is $XXX.XX. Do you wish to pay with your credit/debit card?” Assuming that the customer indicates “yes” via suitable interaction with the mobile device 204, then at 1206, the payment services provider computer 502 effectively receives a request from the customer for a payment transaction to settle the bill.
  • At 1208, the payment services provider computer 502, to the extent required, may translate the customer identifying information (e.g., the customer's mobile telephone number or the customer's account number with the service provider) into the customer's (funding) payment card account number for the requested payment transaction, and the payment services provider computer 502 may translate the service provider's identifying information into the payment card account number for the service provider's payment card account to which the payment transaction is to be routed. In one alternative, the payment services provider computer 502 may be programmed to automatically interpret the customer's affirmative response to the question transmitted at 1204 as a request to initiate a payment transaction to the service provider's payment card account number that the payment services provider computer 502 had previously associated with the batch of billing information received at 1202. In fact, the batch of billing information may have included instructions from the service provider 1104 as to the payment card account number for the service provider's payment card account 214 (FIG. 11).
  • It will be appreciated that step 1208 may typically occur with respect to each customer to whom the billing information was sent at 1204.
  • At 1210, the payment services provider computer 502 may forward the customers' request for payment transactions to the customers' various issuing FIs 206 (only one shown in FIG. 11). As forwarded by the payment services provider computer 502, the requests for payment transactions may include all information required for the customers' issuers 206 to process the payment transactions in a conventional manner. Thus, the requests forwarded by the payment services provider computer 502 each may include the payment card account number for the customer's payment card account 208, the amount of the payment transaction (amount due on the bill), and the payment card account number for the service provider's payment card account 214.
  • In some embodiments, the payment services provider computer 502 may have no more involvement in the service provider's billing activities for the current billing cycle. For example, the payment transaction may proceed from the customer's FI 206 to the service provider's FI 212 via the payment system 210, and the service provider 1106 may receive a confirmation message or report from its FI 212 as to payments received. However, in an alternative arrangement, as illustrated in FIG. 11 and step 1212 in FIG. 12, the payment services provider computer 502 may receive, from the service provider's FI 212, individually or in batches/reports, confirmations or authorization responses from the service provider's FI 212 to indicate that the payment transaction had gone through or would do so, via normal clearing activities. Then at 1214 in FIG. 12, the payment services provider computer 502 may provide confirmations of the payment transactions (individually or in batches) to the service provider computer 1104. In addition, as indicated at 1216, the payment services provider computer 502 may confirm the payment transaction and settlement of the bill to each customer's mobile device 204.
  • FIG. 13 is a block diagram that illustrates a payroll disbursement system 1302 according to some embodiments.
  • The payroll disbursement system 1302 may include an employer computer 1304 operated by or on behalf of an employer organization which pays its employees via the system 1302. The employer may, but need not, have a considerable number of employees on its payroll. Block 1306 in FIG. 13 represents a mobile telephone or home computer that belongs to an employee of the employer.
  • The payroll disbursement system 1302 further includes a payment services provider computer 502 and a payment system 210 as in systems shown in FIGS. 2, 5, 6 or 11, for example. In addition, the payroll disbursement system includes an FI 1308 that issued a payment card account 1310 to the employer, and issuing FIs 1312 (only one shown) that issued payment card accounts 1314 to employees.
  • FIG. 14 is a flow chart that illustrates a process that may be performed by the payment services provider computer 502 in the system of FIG. 13.
  • At 1402 in FIG. 14, the payment services provider computer 502 receives a batch of payroll disbursement information from the employer computer 1304 (or alternatively from a payroll services provider retained by the employer). The payroll disbursement information may include a number (potentially a large number) of records, each representing wages or salary to be paid to a respective employee for the current employment period. Each record may contain, for example, a record number, the net amount that is being paid to the employee in question, an employee identification number (which could be the employee's Social Security number), the mobile telephone number for the employee in question, or a payment card account number that identifies the payment account to which the employee's wages or salary are to be disbursed. (In some embodiments, the employer may also provide a paystub or virtual paystub directly to the employee device, as indicated by arrow 1316.)
  • At 1404, the payment services provider computer 502, to the extent required, may translate the employee identifier into the payment card account number for the employee's payment card account to which the wage/salary payment is to be routed.
  • At 1406 in FIG. 14, the payment services provider computer 502 may forward, to the employer's issuing FI 1308, requests for payment transactions with respect to each of the wage/salary payments indicated by the batch of payroll information received at 1402. For example, each of the requests for a payment transaction may include the amount of the payment, the payment card account number that identifies the employer's payment card account 1310 from which the payment transaction is to be funded, and the payment card account number that identifies the employee's payment card account to which the payment transaction is to be routed.
  • In some embodiments, the payment services provider computer 502 may have no more involvement in the payroll disbursement process. For example, the payment transactions may proceed from the employer's FI 1308 to the employees' FIs 1312 via the payment system 210, and either no confirmations of the payment transactions are provided to the employees, or the employees receive confirmations of the payment transactions from their individual FIs 1312. Alternatively, however, and as indicated at 1408 in FIG. 14, the payment services provider computer 502 may receive, from each of the employees' FIs 1312, confirmations or authorization responses to indicate that the payment transactions had gone through or would do so (via normal clearing activities). Then, at 1410, the payment services provider computer 502 may provide confirmations of the payment transactions to the employee devices 1306. (Although not indicated in FIG. 14, the payment services provider computer 502 may also provide confirmations of the payment transactions to the employer computer 1304.)
  • FIG. 15 is a block diagram that illustrates still another embodiment of a transaction-handling system, indicated by reference numeral 200 c.
  • For example, the transaction-handling system 200 c of FIG. 15 may have all of the components shown in FIG. 5, including the merchant device 202, the customer's mobile device 204, the payment services provider computer 502, the customer's issuing FI 206, the payment system 210 and the merchant's issuing FI 212. In addition, the system 200 c may include a computer that is represented by block 1502 in FIG. 15 and that is operated by an entity that, at least on occasion, may partially or completely fund payment transactions instead of the payment transactions being totally funded from the customer's payment card account 208. As indicated in FIG. 15, the additional funding source computer 1502 may be in data communication, at least from time to time, with the payment services provider computer 502.
  • For example, the payment services provider computer 502 and/or the additional funding source computer 1502 may have capabilities for tracking all payment card transactions (e.g., both payment transactions as described herein and conventional purchase transactions as illustrated in FIG. 1) initiated by the customer, and may detect when a particular transaction, for which information is received from a merchant, is qualified to be partially funded by a loyalty program. For example, such a loyalty program may be operated by the customer's issuing FI 206. Upon detection of a qualified transaction, the payment services provider computer 502 may send to the customer's mobile device 204, along with the transaction information, an inquiry as to whether the customer wishes to apply a rewards payment to the pending transaction. If the customer assents, then a portion of the funds for the payment transaction may come from the additional funding source 1502, and the amount to be charged to the customer's payment card account 208 for the payment transaction may be reduced by the amount supplied by the additional funding source 1502.
  • In connection with split-funding transactions, the payment services provider computer 502 may perform one or more of the following roles, among others: (a) acting as a control agent for the transaction; (b) acting as a storage facility for information and logic used (i) to determine whether split-funding should occur, and (ii) to identify funding sources and to determine how to split the sourcing of funds between the sources; and (c) initiating two or more payment transactions to implement the split-funding transaction.
  • One manner in which a split-funding transaction takes place may be as follows: (A) A request for the transaction is received by the payment services provider computer 502 from the customer's mobile device 204, with the request including for example the total amount to be paid and a merchant identifier. (B) The payment services provider computer 502 may identify the transaction as qualifying for split funding based on (1) an explicit instruction from the customer or (2) the payment services provider computer 502 recognizing predefined characteristics of the transaction. (In the former case, the request from the customer may include indications of the funding accounts and how the payment is to be split between the accounts; in the latter case, the payment services provider computer 502 may detect the qualification of the transaction for split funding from one or more of the following attributes, among others: customer ID, customer payment card account number, merchant ID, merchant payment card account number, detail(s) of the items purchased, date and/or time, type of transactions, etc.) (C) After recognizing the transaction as qualified for split funding, the payment services provider computer 502 may temporarily suspend the transaction and then may access a database record or other stored information to determine how to split the payment amount, and between what source accounts, and further may automatically seek and obtain any required approvals (e.g., from a funding third party) or alternatively the funding third party may indicate to the payment services provider computer 502 how much funding the third party will provide. (D) To the extent necessary, the payment services provider computer 502 may initiate funding authorization requests to verify that the indicated source account(s) have sufficient funds to support the indicated payment transactions. (E) Next the payment services provider computer 502 may initiate a respective payment transaction to implement each partial funding portion of the split-funded transaction. (F) Upon receiving confirmation that the payment transactions have completed, the payment services provider computer 502 may initiate a confirmation message to the customer and/or to the merchant (or alternatively confirmation to the merchant may come from the merchant's issuer.) In the event that one or more of the payment transactions fails (e.g., due to insufficient funds or denial of authorization), the payment services provider computer 502 may take such actions (depending, e.g., on stored instructions for such a situation) as (a) transmitting a message to the customer's mobile device 204 to report the failed transaction (e.g., due to refusal to approve the transaction by a third party or for reasons described above) and possibly to ask the customer for an alternative funding source or for instructions to default to an alternative manner (such as an alternative split-funding arrangement) of funding the transaction; (b) following stored instructions to substitute an alternative funding or split-funding arrangement for the arrangement that failed.
  • Clearing and settlement of the constituent payment transactions may be undertaken in normal course and may in effect clear and settle the entire transaction. Split funding of transactions may not require any modification of conventional payment transaction practices. Nevertheless, in some embodiments it may be useful to modify some conventional processes or provide new processes to facilitate handling of failed transactions. Such processes may include reversals of payment transactions, establishment of rules of hierarchy as to funding sources and establishment of rules as to the order in which the constituent payment transactions are to be executed.
  • In alternative versions of the system 200 c, the additional funding source need not be a loyalty program. One possible alternative is a product specific or merchant specific electronic coupon. As another alternative, and in the case of payment for medical or dental services or prescription drugs, the additional funding source may be a medical or dental insurance plan. For the latter case, the merchant device may, as part of the transaction information transmitted to the payment services provider computer 502, include claim information required by the insurance plan, and that information may be passed on by the payment services provider computer 502 to the insurance plan as a request for coverage of the payment. In some embodiments, such as the medical insurance example, the actual source of the additional funding may be a payment card account (not shown) issued by another issuer (not shown) to the underwriter (loyalty plan, insurance plan, etc.) of the additional funding.
  • FIG. 16 is a block diagram that illustrates still another embodiment of a transaction-handling system, indicated by reference numeral 200 d.
  • For example, the transaction-handling system 200 d of FIG. 16 may have all of the components shown in FIG. 5, including the merchant device 202, the customer's mobile device 204, the payment services provider computer 502, the customer's issuing FI 206 (i.e. the FI which issued the customer's payment card account 208), the payment system 210 and the merchant's issuing FI 212 (i.e., the FI which issued the merchant's payment card account 214). In addition, the system 200 d may include another payment card account 1602 (issued by issuing FI 1604), which is to receive a portion of the payment transaction, with the merchant's payment card account 214 receiving the balance of the payment transaction. (Without loss of generality, it may equally be said that the merchant's payment card account 214 receives a portion of the payment transaction, while the other payment card account 1602 receives another portion (or the “balance”) of the payment transaction.) The payment card account 1602 may be referred to as a co-recipient's account in the sense that the party to which the payment card account was issued is a co-recipient, with the merchant, designated in the payment transaction. Similarly, the issuing FI 1604 may be referred to as the co-recipient's issuing FI.
  • One manner in which a split payment transaction takes place may be as follows: (A) A request for the transaction is received by the payment services provider computer 502 from the customer's mobile device 204, with the request including for example the total amount to be paid and a merchant identifier. In some embodiments, the request may specify that the payment be split and between which recipients. (B) The payment services provider computer 502 may identify the transaction as qualifying for or requiring split payment based on either explicit instructions in the request or one or more rules triggered by characteristics of the transaction. (C) After recognizing that split payment is or may be in order, the payment services provider computer 502 may temporarily suspend the transaction and then may access a database record or other stored information to determine how to divide the payment, and between what destination accounts. (D) To the extent necessary, the payment services provider computer 502 may initiate an authorization request to confirm that sufficient funds are available for the transaction in the customer's payment card account. (E) Next the payment services provider computer 502 may initiate respective payment transactions to implement each partial funding portion of the split payment transaction. (F) Upon receiving confirmation that the payment transactions have completed, the payment services provider computer 502 may initiate a confirmation message to the customer and/or to either or both of the recipients of the payment transactions (or alternatively one or both of the recipients may receive confirmation from the respective issuer for the recipient's payment card account). In the event that one or more of the payment transactions fails (e.g., due to insufficient funds or denial of authorization or unavailability of a recipient account), the payment services provider computer 502 may be guided by stored instructions to take appropriate action.
  • Clearing and settlement of the constituent payment transactions may be undertaken in normal course and may in effect clear and settle the entire transaction. Split payment transactions may not require any modification of conventional payment transaction practices. Nevertheless, in some embodiments it may be useful to modify some conventional processes or provide new processes to facilitate handling of failed transactions. Such processes may include reversals of payment transactions, and establishment of rules as to the order in which the constituent payment transactions are to be executed.
  • There will now be discussed specific applications of the concept of splitting a payment transaction between two (or more) recipients.
  • In one example, the co-recipient is a sales tax collection authority. For example, the payment transaction requested by the customer may call for the pre-tax subtotal amount of a sales transaction to be transferred to the merchant's payment card account 214, with the tax due on the sales transaction to be transferred (in the same or a related payment transaction) to the sales tax collection payment card account (reference numeral 1602, according to this example).
  • In another example, it is assumed that the customer is purchasing an item (e.g., a piece of furniture) that has been consigned for sale by the merchant. In this case, the co-recipient is the consignor. Thus the consignor's share of the purchase price is transferred to the consignor's payment card account (reference numeral 1602, according to this example) by a purchase transaction requested by the customer, and the balance of the purchase price, which can also be considered the merchant's commission, is transferred to the merchant's payment card account 214 by the same or a related payment transaction requested by the customer.
  • In yet another example, the “merchant” is assumed to be a construction company/home remodeling company that serves as a general contractor (GC), and the co-recipient may be a subcontractor or supplier of materials to the GC.
  • In still another example, the “merchant” is assumed to be a part-time domestic employee, and the co-recipient may be the Internal Revenue Service or a state tax authority, acting as collector of payroll withholding taxes or other payroll taxes.
  • FIG. 17 is a flow chart that illustrates a process that may be performed in the point of sale terminal 202 that may serve as the merchant device shown in FIG. 2, 5, 6, 15 or 16.
  • To summarize the import of FIG. 17 before discussing it in detail, in some embodiments the POS terminal 202 may be selectively operable in either a conventional payment card purchase transaction mode (described with reference to FIG. 1) or in a novel mode, as described hereinabove, in which the POS terminal 202 serves as an adjunct to a customer-requested payment card system payment transaction by which the pending sales transaction will be settled. As will be appreciated from the previous discussion (e.g., of FIGS. 2, 5 and 6), in the latter mode, the POS terminal 202 does not initiate a payment card purchase transaction authorization request, but rather only displays or transmits transaction information (to the customer's mobile device 204 or to an intermediary such as payment services provider computer 502) and then awaits confirmation of the effectiveness of the customer-requested payment transaction.
  • Turning, then to FIG. 17, at 1702, information to define the purchase transaction is entered into the POS terminal 202. This may entail, for example, the barcode reader component 306 (FIG. 3) of the POS terminal 202 being used to read a product identifying barcode or barcodes from one or more items that the customer wishes to purchase.
  • Next, at 1704 in FIG. 17, the POS terminal determines whether it has been placed in the (conventional) purchase transaction mode or in the (novel) payment transaction mode. If the former mode is selected, the POS terminal operates (step 1706) in the manner described above with reference to FIG. 1. If the latter mode is selected, the POS terminal does not initiate a purchase transaction authorization request, but rather operates (step 1708) as described above in connection with FIG. 8.
  • Selection between the purchase transaction mode and the payment transaction mode may occur in a number of ways. For example, in some embodiments, the purchase transaction mode may be selected by swiping a magnetic stripe payment card through the magnetic stripe reader component 310 (FIG. 3) of the POS terminal 202 or by bringing a contactless payment card or payment device (including, e.g., a mobile telephone equipped with contactless payment device capabilities) into proximity with the RFID/NFC terminal component 316 of the POS terminal 202. In such embodiments, selection of the payment transaction mode may require positive input from the operator, such as touching a relevant portion of a touch screen, actuating a soft key, or actuating a dedicated function key to indicate selection of the payment transaction mode. In other embodiments, the payment transaction mode may be the default mode of operation for the POS terminal, entered upon initiation of a purchase transaction (e.g., by reading a barcode from a product item), with the purchase transaction mode only being entered upon presentation of a payment card or device to the POS terminal, as described earlier in this paragraph. In still other embodiments, selection of either mode may require positive input from the operator, e.g., by selecting an appropriate option from a menu displayed by the POS terminal.
  • (The above discussion is not meant to imply the absence of another mode or modes of operation, such as a cash payment mode.)
  • Departing from the above discussion of dual (or more than dual) use embodiments of the POS terminal 202, it should also be understood that in some embodiments of the merchant device, whether or not it would generally be considered a POS terminal, the device may support only one mode of operation, namely a payment transaction mode as described hereinabove in connection with FIG. 8. Alternatively, the merchant device 202 may support cash transactions in addition to payment-system-based payment transactions as described herein.
  • In some embodiments, the customer's mobile device 204 may also be a dual use device in terms of its payment capabilities. That is, in some embodiments the customer's mobile device 204 may be selectively operable either in a conventional contactless payment mode (in which the payment card account number is read from an RFID chip (reference numeral 424, FIG. 4) in the device by the POS terminal, which in turn initiates an authorization request for a purchase transaction) or a payment transaction request mode of operation, as described hereinabove in connection with FIG. 9. In some embodiments, the customer may select the former mode simply by bringing the device 204 into proximity with the RFID/NFC reading component of a POS terminal 202. Selection of the latter mode may require positive input from the customer, as by selecting a suitable menu option displayed by the display 402 of the device 204. In other embodiments, the latter mode may be entered semi-automatically, by receiving a message containing the transaction information, where the message is pushed to the device 204 by the merchant device 202 or by the payment service provider computer 502, and the customer then responds affirmatively to the message to initiate the request for the payment transaction.
  • In other embodiments, selecting either the purchase transaction mode or the payment transaction mode for the customer's mobile device 204 may require the customer to actuate a soft key, a dedicated button, or the like.
  • In still other embodiments, the customer's mobile device 204 may take its cue, in terms of selecting between the two modes, from a POS terminal 202 to which the mobile device 204 is presented. That is, if the POS terminal 202 is in the purchase transaction mode when the mobile device 204 is presented to the POS terminal's RFID/NFC component, then the purchase transaction mode may be automatically selected for the mobile device 202, such that the mobile device uploads the payment card account number to the POS terminal in a conventional manner in response to a conventional interrogation signal from the RFID/NFC component. However, if the POS terminal is in the payment transaction mode, the POS terminal may respond to the presence of the mobile device at the RFID/NFC component by pushing the transaction information to the mobile device via NFC, and in response to receiving the transaction information the mobile device enters the payment transaction mode.
  • FIGS. 2, 5, 6, 11, 13, 15 and 16 each depict only system components that may be involved in a single transaction, rather than all of the components that may be present in the system. For example, each system may also include: (a) numerous other customer mobile devices 204 in addition to the one such device shown; (b) numerous other merchant devices 202 in addition to the one such device shown; (c) numerous other payment card account issuers in addition to the two issuing FIs typically shown in the drawings; (d) numerous service providers in addition to the service provider 1104 shown in FIG. 11; (e) numerous other employees and employers besides the single employee and single employer shown in FIG. 13; (f) a considerable number of additional funding sources in addition to the one shown in FIG. 15. Moreover, the various system embodiments shown in the drawings may be combined in various combinations. For example, a single system may be provided which provides most or all of the features described with reference to FIGS. 2, 5, 11, 13, 15 and 16.
  • In FIGS. 5 and 6, respectively, the confirmation of the payment transaction is shown as flowing from the merchant's issuer to the merchant directly and indirectly via the payment services provider computer 502. Alternatively, however, the confirmation of the payment transaction may flow to the merchant via the payment system 210 and the payment services provider computer 502.
  • To a large extent, the novel applications of payment transactions as proposed herein have been described in the context of face-to-face retail sales of goods. However, a considerable number of other novel applications of payment transactions are also contemplated. For example (and as briefly indicated above in connection with split payments, FIG. 16), payment transactions may also be requested via a mobile device by a payment card account holder to settle payments for services such as automobile rentals, taxi rides, airline and train fares, personal care services (e.g., hair salon services, manicures, personal training, etc.), health club and gym fees, medical and dental services, dry cleaning, home renovations, cultural and sporting event ticketing, periodical subscriptions, museum entrance fees, etc., etc. It is also not required that the merchant/service provider be face-to-face with the customer. Thus payment transactions may be initiated by the customer to pay for telephone or online orders. For example, in the case where the customer's mobile device is a PDA, the customer may access an online store, which may push the transaction information, upon checkout, to the customer's mobile device (possibly via a PSP computer 502). The customer's mobile device may then request a payment transaction to settle the online purchase. The online store may receive confirmation via its issuing FI that the payment transaction is or will be completed before proceeding to fulfill the customer's order. The above-noted advantage that the customer does not disclose his/her payment card account number to the merchant may be particularly attractive in the case of online purchases. Similarly, confirmed identification of the merchant (as per step 904, FIG. 9) to the customer prior to requesting the payment transaction may also be a very significant, though optional, feature from the customer's point of view.
  • While many of the above examples of transactions implemented with payment card system payment transactions have related to consumer purchases, similar transactions may occur with respect to business transactions, such as purchases of supplies by businesses using commercial credit or debit cards, or, e.g., a small contractor purchasing building materials with a credit or debit card. Thus a customer, as referred to herein and in the appended claims, need not be an individual consumer.
  • In cases where there is a payment services provider computer to perform “on behalf” services as in the systems of FIGS. 5 and 6, the payment services provider computer need not necessarily perform all of the services described. For example, in at least some situations, the transaction information may be transmitted from the merchant device to the customer's mobile device, or entered manually into the customer's mobile device, which then sends the payment transaction request to the payment services provider computer for forwarding to the customer's issuing FI.
  • In addition to other advantages, including those described above, the system architectures shown, e.g., in FIGS. 5 and 6 may also allow the customer's issuing FI to set policies for personalizing and/or customizing service practices, such that, for example: (a) credit offers may be made only to certain customers and/or in connection only with certain kinds of transactions; and (b) whether additional authentication procedures are required may be determined according to predetermined rules on a customer-by-customer and/or on a transaction-by-transaction basis. More complex rules may also determine when authentication is required, including for example rules based on recent transaction history for an account.
  • It will be understood that communications among the customer's mobile device 204 and/or the merchant device 202 and/or other components in the system may be carried, at least in part, via a conventional mobile telephone network, which is not explicitly shown in the drawings.
  • In some embodiments, the customer's mobile device triggers the merchant device to download the transaction information to the customer's mobile device by transmitting a suitable signal to the merchant device, e.g., by NFC. Correspondingly, the merchant device may download the transaction information to the customer's mobile device in response to receiving such a signal from the customer's mobile device. Receiving such a signal may place the merchant device in the above-mentioned payment transaction mode of operation.
  • 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, an “information message” includes a text message or any other message sent to or from a mobile device to transmit information other than audible or visual information.
  • As used herein and in the appended claims, “mobile identifier” refers to a mobile telephone number or any other identification information that uniquely identifies a mobile telephone or other mobile device.
  • As used herein and in the appended claims, the term “payment card account” includes a credit card account or a deposit account that the account holder may access using a debit card. The term “payment card account number” includes a number that identifies a payment card account or a number carried by a payment card, or a number that is used to identify an account in a payment system that handles debit card and/or credit card transactions or 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 (including a pre-paid debit card). The term “payment card account” also includes an account to which a payment card account number is assigned. Thus a payment card account may include an account to which payment transactions may be routed by a payment system that handles debit card and/or credit card transactions, even if the account in question is not eligible to be charged for purchase transactions or other transactions. A payment card account may also include an account from which payment transactions may be routed by a payment system that handles debit card and/or credit card transactions, even if the account in question is not customarily used, or is not eligible, to be charged for purchase transactions.
  • The account numbers that identify the merchants' or other recipients' payment card accounts herein may be in a format and in an account number range that allow payment transactions to be routed to the accounts in question; the accounts may, but need not, be operable also for charging purchase transactions to such accounts.
  • 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 (44)

1. A method comprising:
receiving transaction information from a merchant device, the transaction information including a transaction amount and merchant information that identifies a merchant that operates the merchant device;
receiving, from a mobile device, a request that a funds transfer be made from a payment card account that belongs to a customer who is operating the mobile device to a payment card account that belongs to said merchant; and
forwarding the request to a financial institution that issued said payment card account that belongs to said customer.
2. The method of claim 1, further comprising:
receiving an authorization response from a financial institution that issued said payment card account that belongs to said merchant, said authorization response confirming validity and availability of said payment card account that belongs to said merchant.
3. The method of claim 2, further comprising:
transmitting to said merchant device a confirmation that said funds transfer has been or will be made to said payment card account that belongs to said merchant.
4. The method of claim 1, further comprising:
translating customer identification information into an account number that identifies said payment card account that belongs to said customer, said customer identification information identifying said customer and included in said request received from said mobile device.
5. The method of claim 4, wherein said customer identification information is information that identifies said mobile device.
6. The method of claim 4, wherein said customer identification information is a mobile telephone number assigned to said mobile device.
7. The method of claim 1, further comprising:
translating said merchant information into an account number that identifies said payment card account that belongs to said merchant.
8. The method of claim 1, wherein the transaction information includes a mobile telephone number assigned to the mobile device.
9. The method of claim 1, wherein:
the transaction information includes a transaction reference number generated by the merchant device; and
the request includes said transaction reference number.
10. The method of claim 9, further comprising:
prior to receiving said request, transmitting at least some of the transaction information to the mobile device.
11. The method of claim 1, further comprising:
prior to receiving said request, transmitting at least some of the transaction information to the mobile device.
12. A method comprising:
first receiving a transaction reference number from a merchant device, the merchant device operated by a merchant, the transaction reference number for uniquely identifying a retail transaction to be performed by the merchant device with a customer; and
second receiving said transaction reference number from a mobile device operated by the customer.
13. The method of claim 12, further comprising:
after said second receiving step, transmitting a funds transfer request to a financial institution, said request for causing a funds transfer from a first payment card account to a second payment card account, the first payment card account issued by the financial institution and belonging to the customer, the second payment card account belonging to the merchant.
14. The method of claim 13, further comprising:
transmitting, to the merchant device, confirmation of the funds transfer.
15. The method of claim 14, wherein the confirmation includes the transaction reference number.
16. The method of claim 12, wherein the transaction reference number was generated by the merchant device.
17. The method of claim 12, further comprising:
before said second receiving, transmitting said transaction reference number to the mobile device.
18. A method comprising:
receiving transaction information from a merchant, the transaction information including a transaction amount and merchant information that identifies the merchant;
transmitting at least the transaction amount to a mobile device operated by a customer; and
receiving from the mobile device a request for a funds transfer from a payment card account that belongs to the customer to a payment card account that belongs to the merchant.
19. The method of claim 18, wherein said transmitting step includes transmitting the merchant information to the mobile device.
20. The method of claim 18, further comprising:
forwarding the request to a financial institution that issued said payment card account that belongs to said customer.
21. The method of claim 18, further comprising:
transmitting, to the merchant device, confirmation of the funds transfer.
22. A method comprising:
receiving transaction information from a merchant, said transaction information including a customer mobile telephone number, a merchant identification code and a transaction amount;
translating the merchant identification code into a name of a merchant; and
transmitting the name of the merchant to a mobile device operated by a customer.
23. The method of claim 22, further comprising:
receiving a funds transfer request from the mobile device, said funds transfer request for requesting that funds be transferred from a payment card account that belongs to said customer to a payment card account that belongs to said merchant.
24. The method of claim 23, further comprising:
translating the merchant identification code into a first payment card account number, said first payment card account number for identifying said payment card account that belongs to said merchant.
25. The method of claim 24, further comprising:
translating the customer mobile telephone number into a second payment card account number, said second payment card account number for identifying said payment card account that belongs to said customer.
26. The method of claim 25, further comprising:
forwarding said funds transfer request to a financial institution that issued said payment card account that belongs to said customer.
27. The method of claim 23, wherein said received funds transfer request includes said merchant identification code.
28. The method of claim 22, further comprising:
transmitting a transaction reference number to said mobile device.
29. The method of claim 28, wherein said transaction reference number was generated by a device operated by the merchant.
30. A method comprising:
receiving transaction information from a merchant device, the transaction information including a transaction amount and merchant information that identifies a merchant that operates the merchant device;
transmitting at least some of the transaction information to a mobile device operated by a customer of the merchant;
receiving, from the mobile device, a request that a funds transfer be made from a payment card account that belongs to the customer to a payment card account that belongs to the merchant;
forwarding the request to a financial institution that issued said payment card account that belongs to said customer.
receiving a message that confirms that the funds transfer has been or will be made; and
transmitting, to the merchant device, confirmation of the funds transfer.
31. The method of claim 30, wherein said message is received from the financial institution which issued said payment card account that belongs to said customer.
32. The method of claim 30, wherein said message is received from a financial institution which issued said payment card account that belongs to said merchant.
33. A method comprising:
receiving a request from a customer for a funds transfer; and
responding to the request by:
implementing a first partial funds transfer by initiating a payment transaction to transfer funds from a first payment card account to a second payment card account, the first payment card account belonging to the customer; and
implementing a second partial funds transfer by initiating a payment transaction to transfer funds from the first payment card account to a third payment card account that is different from the first payment card account.
34. The method of claim 33, wherein said second payment card account belongs to a service provider.
35. The method of claim 34, wherein said third payment card account belongs to a subcontractor of the service provider.
36. The method of claim 34, wherein said third payment card account is a tax withholding account.
37. The method of claim 33, wherein:
the second payment card account belongs to a merchant; and
the third payment card account is a sales tax collection account.
38. The method of claim 33, wherein the request is received from a mobile device.
39. A method comprising:
receiving billing information from a holder of a first payment card account, the billing information indicative of an amount due from a customer to the holder;
transmitting at least some of the billing information to a mobile device that belongs to the customer;
receiving a request from the mobile device to transfer the amount from a second payment card account to the first payment card account, the second payment card account belonging to the customer; and
relaying the request to a financial institution that issued the second payment card account.
40. The method of claim 39, further comprising:
receiving an authorization response from a financial institution that issued said first payment card account, said authorization response confirming validity and availability of said first payment card account.
41. The method of claim 40, further comprising:
transmitting to said holder a confirmation that said funds transfer has been or will be made to said first payment card account.
42. The method of claim 39, further comprising:
translating customer identification information into an account number that identifies said second payment card account, said customer identification information identifying said customer and included in said request received from said mobile device.
43. A method comprising:
receiving a request from a customer for a funds transfer; and
responding to the request by:
implementing a first partial funds transfer by initiating a payment transaction to transfer funds from a first payment card account to a second payment card account, the first payment card account belonging to the customer; and
implementing a second partial funds transfer by initiating a payment transaction to transfer funds from a third payment card account to the second payment card account, the third payment card account different from the first payment card account.
44. The method of claim 43, wherein the second payment card account belongs to a merchant.
US11/964,343 2007-10-03 2007-12-26 Payment services provider methods in connection with personalized payments system Abandoned US20090094123A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/964,343 US20090094123A1 (en) 2007-10-03 2007-12-26 Payment services provider methods in connection with personalized payments system
US14/039,180 US20140032381A1 (en) 2007-10-03 2013-09-27 Payment services provider methods in connection with personalized payments system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US97726007P 2007-10-03 2007-10-03
US11/964,343 US20090094123A1 (en) 2007-10-03 2007-12-26 Payment services provider methods in connection with personalized payments system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/039,180 Continuation US20140032381A1 (en) 2007-10-03 2013-09-27 Payment services provider methods in connection with personalized payments system

Publications (1)

Publication Number Publication Date
US20090094123A1 true US20090094123A1 (en) 2009-04-09

Family

ID=40522420

Family Applications (8)

Application Number Title Priority Date Filing Date
US11/964,343 Abandoned US20090094123A1 (en) 2007-10-03 2007-12-26 Payment services provider methods in connection with personalized payments system
US11/964,360 Active 2029-09-16 US8762211B2 (en) 2007-10-03 2007-12-26 System for personalized payments via mobile devices
US11/964,425 Active US7575177B2 (en) 2007-10-03 2007-12-26 Dual use payment device
US11/964,444 Abandoned US20090094126A1 (en) 2007-10-03 2007-12-26 Dual use point of sale terminal and methods of operating same
US12/500,963 Active 2028-03-09 US7988060B2 (en) 2007-10-03 2009-07-10 Dual use payment device
US13/777,487 Abandoned US20130173407A1 (en) 2007-10-03 2013-02-26 Dual use point of sale terminal and methods of operating same
US14/039,180 Abandoned US20140032381A1 (en) 2007-10-03 2013-09-27 Payment services provider methods in connection with personalized payments system
US14/299,213 Abandoned US20140289125A1 (en) 2007-10-03 2014-06-09 System for personalized payments via mobile devices

Family Applications After (7)

Application Number Title Priority Date Filing Date
US11/964,360 Active 2029-09-16 US8762211B2 (en) 2007-10-03 2007-12-26 System for personalized payments via mobile devices
US11/964,425 Active US7575177B2 (en) 2007-10-03 2007-12-26 Dual use payment device
US11/964,444 Abandoned US20090094126A1 (en) 2007-10-03 2007-12-26 Dual use point of sale terminal and methods of operating same
US12/500,963 Active 2028-03-09 US7988060B2 (en) 2007-10-03 2009-07-10 Dual use payment device
US13/777,487 Abandoned US20130173407A1 (en) 2007-10-03 2013-02-26 Dual use point of sale terminal and methods of operating same
US14/039,180 Abandoned US20140032381A1 (en) 2007-10-03 2013-09-27 Payment services provider methods in connection with personalized payments system
US14/299,213 Abandoned US20140289125A1 (en) 2007-10-03 2014-06-09 System for personalized payments via mobile devices

Country Status (1)

Country Link
US (8) US20090094123A1 (en)

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090182634A1 (en) * 2008-01-10 2009-07-16 Park David S Image-Based Payment Medium
US20090202081A1 (en) * 2008-02-08 2009-08-13 Ayman Hammad Key delivery system and method
US20090254463A1 (en) * 2008-04-04 2009-10-08 Brad Michael Tomchek Methods and systems for managing merchant screening
US20090254462A1 (en) * 2008-04-04 2009-10-08 Brad Michael Tomchek Methods and systems for managing co-brand proprietary financial transaction processing
US20090271276A1 (en) * 2008-04-24 2009-10-29 Qualcomm Incorporated Electronic payment system
US20100145855A1 (en) * 2008-12-06 2010-06-10 Fordyce Iii Edward W Payment account processing which conveys non purchase related data exchanges
US20100228639A1 (en) * 2009-03-05 2010-09-09 Barclays Bank Delaware Systems And Methods To Initiate Payments From Electronic Devices
US20110161231A1 (en) * 2009-12-29 2011-06-30 Pitney Bowes Inc. Postal services kiosk having payment card security
US20110213711A1 (en) * 2010-03-01 2011-09-01 Entrust, Inc. Method, system and apparatus for providing transaction verification
US20120005076A1 (en) * 2010-07-02 2012-01-05 Firethorn Holdings, Llc System and method for managing transactions with a portable computing device
WO2012009165A1 (en) * 2010-07-16 2012-01-19 Mastercard International, Inc. Money transfer system gateway service
US20120221468A1 (en) * 2011-02-25 2012-08-30 Phil Kumnick Direct connection systems and methods
WO2013055933A2 (en) * 2011-10-12 2013-04-18 Boost Payment Solutions, LLC Electronic payment processing
US20130097032A1 (en) * 2007-11-30 2013-04-18 Blaze Mobile, Inc. Utilizing shopping lists for nfc transactions
US8442914B2 (en) 2010-07-06 2013-05-14 Mastercard International Incorporated Virtual wallet account with automatic-loading
US20130166448A1 (en) * 2011-12-27 2013-06-27 Infosys Limited Financial transfers from mobile devices
US8589300B2 (en) * 2007-10-25 2013-11-19 Visa U.S.A. Inc. Payment transaction using mobile phone as relay
DE102012214744A1 (en) 2012-08-20 2014-02-20 Tobias Pfütze Method and system for carrying out a financial transaction
US20140129451A1 (en) * 2008-10-13 2014-05-08 Mark Carlson P2P Transfer Using Prepaid Card
US20140214677A1 (en) * 2010-11-05 2014-07-31 Mastercard International Incorporated Remittance system with improved service for unbanked individuals
US20140279103A1 (en) * 2013-03-15 2014-09-18 Cullinan Consulting Group Pty Ltd. System and method for enabling financial transactions
US20150006376A1 (en) * 2013-06-27 2015-01-01 Ebay Inc. Conductive payment device
US20150142661A1 (en) * 2013-11-20 2015-05-21 Capital One Financial Corporation Shared expense management
US9270447B2 (en) 2011-11-03 2016-02-23 Arvind Gidwani Demand based encryption and key generation and distribution systems and methods
US20170171183A1 (en) * 2015-12-15 2017-06-15 Phaneendra Ramaseshu Lingappa Authentication of access request of a device and protecting confidential information
US9721283B2 (en) 2010-09-30 2017-08-01 Paypal, Inc. Location based transactions
US10127540B2 (en) * 2011-12-19 2018-11-13 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
US10176477B2 (en) 2010-11-16 2019-01-08 Mastercard International Incorporated Methods and systems for universal payment account translation
US10210497B2 (en) * 2011-04-06 2019-02-19 OnDot Systems, Inc. System and method for cashless peer-to-peer payment
US10410194B1 (en) 2015-08-19 2019-09-10 Square, Inc. Customized tipping flow
US20200082376A1 (en) * 2012-07-16 2020-03-12 Square, Inc. Storing and Forwarding Payment Transactions
US10592899B2 (en) 2014-05-13 2020-03-17 Visa International Service Association Master applet for secure remote payment processing
US11004061B2 (en) 2006-09-24 2021-05-11 Rfcyber Corporation Method and apparatus for payments between two mobile devices
US20220012698A1 (en) * 2020-07-07 2022-01-13 Mastercard International Incorporated Methods and systems of providing interoperability between incompatible payment systems
US11636462B2 (en) 2015-03-20 2023-04-25 Block, Inc. Context-aware peer-to-peer transfers of items
US12020247B1 (en) 2014-12-11 2024-06-25 Block, Inc. Intelligent payment capture in failed authorization requests

Families Citing this family (340)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7333955B2 (en) 2001-09-24 2008-02-19 E2Interactive, Inc. System and method for securing communication service
US8596527B2 (en) 1999-11-05 2013-12-03 Lead Core Fund, L.L.C. Methods for locating a payment system utilizing a point of sale device
US8073772B2 (en) 1999-11-05 2011-12-06 American Express Travel Related Services Company, Inc. Systems and methods for processing transactions using multiple budgets
US8458086B2 (en) * 1999-11-05 2013-06-04 Lead Core Fund, L.L.C. Allocating partial payment of a transaction amount using an allocation rule
US20090164331A1 (en) * 1999-11-05 2009-06-25 American Express Travel Related Services Company, Inc. Systems for Locating a Payment System Utilizing a Point of Sale Device
US8195565B2 (en) 1999-11-05 2012-06-05 Lead Core Fund, L.L.C. Systems and methods for point of interaction based policy routing of transactions
US8180706B2 (en) 1999-11-05 2012-05-15 Lead Core Fund, L.L.C. Systems and methods for maximizing a rewards accumulation strategy during transaction processing
US8851369B2 (en) 1999-11-05 2014-10-07 Lead Core Fund, L.L.C. Systems and methods for transaction processing using a smartcard
US8646685B2 (en) 1999-11-05 2014-02-11 Lead Core Fund, L.L.C. Device for allocating a payment authorization request to a payment processor
US20090271278A1 (en) * 1999-11-05 2009-10-29 American Express Travel Related Services Company, Inc. Systems and methods for routing a transaction request to a payment system via a transaction device
US8190514B2 (en) 1999-11-05 2012-05-29 Lead Core Fund, L.L.C. Systems and methods for transaction processing based upon an overdraft scenario
US8814039B2 (en) 1999-11-05 2014-08-26 Lead Core Fund, L.L.C. Methods for processing a payment authorization request utilizing a network of point of sale devices
CA2370934C (en) 2001-02-23 2004-06-22 Navaho Networks Inc. Secure electronic commerce
US7401224B2 (en) * 2002-05-15 2008-07-15 Qualcomm Incorporated System and method for managing sonic token verifiers
US9016565B2 (en) * 2011-07-18 2015-04-28 Dylan T X Zhou Wearable personal digital device for facilitating mobile device payments and personal use
US9824349B2 (en) * 2002-10-01 2017-11-21 World Award Academy Facilitating mobile device payments using product code scanning
US9367841B2 (en) * 2011-07-18 2016-06-14 Tiger T G Zhou Facilitating mobile device payments using product code scanning
US20130018782A1 (en) * 2011-07-18 2013-01-17 Tiger T G Zhou Methods and systems for facilitating mobile device payments using codes and cashback business model
WO2004114239A2 (en) 2003-06-13 2004-12-29 Wildseed Ltd. Emulated radio frequency identification
US8175938B2 (en) * 2004-04-13 2012-05-08 Ebay Inc. Method and system for facilitating merchant-initiated online payments
CA2648523C (en) 2005-04-21 2018-09-04 Securedpay Solutions, Inc. Portable handheld device for wireless order entry and real time payment authorization and related methods
US7837100B2 (en) 2005-07-05 2010-11-23 American Express Travel Related Services Company, Inc. System, method, and computer program product for issuing and using debit cards
US20100030651A1 (en) * 2005-11-04 2010-02-04 Richard Victor Matotek Mobile phone as a point of sale (POS) device
US20070106564A1 (en) 2005-11-04 2007-05-10 Utiba Pte Ltd. Mobile phone as a point of sale (POS) device
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US7886962B2 (en) * 2006-08-17 2011-02-15 Verizon Patent And Licensing Inc. Multi-function transaction device
US8909553B2 (en) * 2006-09-06 2014-12-09 Transaction Wireless, Inc. Payment card terminal for mobile phones
CN101647040A (en) * 2006-12-26 2010-02-10 维萨美国股份有限公司 Mobile payment system and method using alias
US8566240B2 (en) * 2007-01-16 2013-10-22 E2Interactive, Inc. Systems and methods for the payment of customer bills utilizing payment platform of biller
US10055735B2 (en) 2007-01-30 2018-08-21 Visa U.S.A., Inc. Delayed transit fare assessment
US11257080B2 (en) 2007-05-04 2022-02-22 Michael Sasha John Fraud deterrence for secure transactions
US10853855B2 (en) * 2007-05-20 2020-12-01 Michael Sasha John Systems and methods for automatic and transparent client authentication and online transaction verification
US9830582B1 (en) 2007-08-18 2017-11-28 Expensify, Inc. System, computer readable medium, and method for authorizing purchase using on-demand prepaid card
US10068225B2 (en) * 2007-08-18 2018-09-04 Espensify, Inc. System and method for utilizing a universal prepaid card
US10423896B2 (en) 2007-08-18 2019-09-24 Expensify, Inc. Computer system implementing a network transaction service
US10163092B2 (en) 2007-08-18 2018-12-25 Expensify, Inc. System and method for establishing a payment mechanism with a plurality of merchants
US7909243B2 (en) * 2007-08-28 2011-03-22 American Express Travel Related Services Company, Inc. System and method for completing a secure financial transaction using a wireless communications device
US8041338B2 (en) * 2007-09-10 2011-10-18 Microsoft Corporation Mobile wallet and digital payment
US8341083B1 (en) 2007-09-12 2012-12-25 Devicefidelity, Inc. Wirelessly executing financial transactions
US9311766B2 (en) 2007-09-12 2016-04-12 Devicefidelity, Inc. Wireless communicating radio frequency signals
US9304555B2 (en) 2007-09-12 2016-04-05 Devicefidelity, Inc. Magnetically coupling radio frequency antennas
US8070057B2 (en) * 2007-09-12 2011-12-06 Devicefidelity, Inc. Switching between internal and external antennas
US8915447B2 (en) 2007-09-12 2014-12-23 Devicefidelity, Inc. Amplifying radio frequency signals
US9883381B1 (en) 2007-10-02 2018-01-30 Sprint Communications Company L.P. Providing secure access to smart card applications
US8583515B2 (en) 2007-12-21 2013-11-12 Metabank Transfer account systems, computer program products, and associated computer-implemented methods
US8788414B2 (en) 2007-12-21 2014-07-22 Metabank Transfer account systems, computer program products, and computer-implemented methods to prioritize payments from preselected bank account
US9639796B2 (en) 2007-12-24 2017-05-02 Dynamics Inc. Cards and devices with magnetic emulators with zoning control and advanced interiors
US8756161B2 (en) * 2008-02-11 2014-06-17 Accenture Global Services Limited Customer initiated payment method using mobile device
US20090204525A1 (en) * 2008-02-13 2009-08-13 Simon Phillips Payment device to issuer communication via authorization request
US11816665B2 (en) 2008-02-20 2023-11-14 Stripe, Inc. Method and system for multi-modal transaction authentication
US8577804B1 (en) * 2008-02-20 2013-11-05 Collective Dynamics LLC Method and system for securing payment transactions
US9852426B2 (en) 2008-02-20 2017-12-26 Collective Dynamics LLC Method and system for secure transactions
US10515405B2 (en) 2008-03-03 2019-12-24 Metabank Person-to-person lending program product, system, and associated computer-implemented methods
US20090281904A1 (en) * 2008-04-02 2009-11-12 Pharris Dennis J Mobile telephone transaction systems and methods
US11227331B2 (en) 2008-05-14 2022-01-18 Metabank System, program product, and computer-implemented method for loading a loan on an existing pre-paid card
WO2009146415A1 (en) * 2008-05-30 2009-12-03 Total System Services, Inc. System and method for processing transactions without providing account information to a payee
US8090650B2 (en) 2008-07-24 2012-01-03 At&T Intellectual Property I, L.P. Secure payment service and system for interactive voice response (IVR) systems
WO2010028266A1 (en) 2008-09-04 2010-03-11 Metabank System, program product and methods for retail activation and reload associated with partial authorization transactions
US9824355B2 (en) 2008-09-22 2017-11-21 Visa International Service Association Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US10706402B2 (en) 2008-09-22 2020-07-07 Visa International Service Association Over the air update of payment transaction data stored in secure memory
US8977567B2 (en) 2008-09-22 2015-03-10 Visa International Service Association Recordation of electronic payment transaction information
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US20100114768A1 (en) 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US11797953B2 (en) * 2008-11-24 2023-10-24 Malikie Innovations Limited Electronic payment system including merchant server and associated methods
US9213965B1 (en) 2008-11-26 2015-12-15 Metabank Machine, methods, and program product for electronic inventory tracking
US8286863B1 (en) 2009-02-04 2012-10-16 Metabank System and computer program product to issue a retail prepaid card including a user-designed external face using a chit and related computer implemented methods
US20110060684A1 (en) * 2009-03-25 2011-03-10 Jucht Scott J Machine, program product, and computer-implemented methods for confirming a mobile banking request
US20100250376A1 (en) * 2009-03-31 2010-09-30 Srikanth Nandiraju Virtual terminal for mobile devices
US9235831B2 (en) 2009-04-22 2016-01-12 Gofigure Payments, Llc Mobile payment systems and methods
US20100274678A1 (en) * 2009-04-22 2010-10-28 Gofigure Payments, Llc Systems, methods and devices for facilitating mobile payments
US8559923B2 (en) 2009-05-18 2013-10-15 Mastercard International Incorporated Switching functions for mobile payments system
US20110046969A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias hierarchy and data structure
US20110082737A1 (en) 2009-09-28 2011-04-07 Crowe Andrew B Computer-implemented methods, computer program products, and systems for management and control of a loyalty rewards network
US8374916B2 (en) * 2009-10-27 2013-02-12 At&T Mobility Ii Llc Secure mobile-based financial transactions
US8907768B2 (en) * 2009-11-25 2014-12-09 Visa International Service Association Access using a mobile device with an accelerometer
US20110137804A1 (en) * 2009-12-03 2011-06-09 Recursion Software, Inc. System and method for approving transactions
US8930265B2 (en) 2010-01-29 2015-01-06 Bank Of America Corporation Monitoring retail transactions associated with a financial institution-based merchant offer program and determining savings metrics
US20110191184A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Mobile location integrated merchant offer program and customer shopping
US8442894B2 (en) * 2010-01-29 2013-05-14 Bank Of America Corporation Guaranteed merchant payment in a card-not-present transaction
US20110191150A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Mobile integrated merchant offer program and customer shopping using product level information
US20110191173A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Offer determination and settlement for integrated merchant offer program and customer shopping
US20110191181A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Wish list for integrated merchant offer program and customer shopping
US20110191157A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Integrated merchant offer program and customer shopping
US20110191238A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Variable merchant settlement options
US20110191177A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Pre-population of merchant check-out entry fields
US20110191149A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Customer-selected payment clearinghouse
US20110191180A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Search analyzer system for integrated merchant offer program and customer shopping
US9501773B2 (en) * 2010-02-02 2016-11-22 Xia Dai Secured transaction system
US20110196782A1 (en) * 2010-02-05 2011-08-11 Bank Of America Corporation Transferring Funds Using Mobile Devices
BR112012019539A2 (en) * 2010-02-09 2018-03-13 Ebay Inc method of conducting a financial transaction, and non-transitory machine readable medium
US20110218849A1 (en) * 2010-03-03 2011-09-08 Rutigliano John R Cloud platform for multiple account management & automated transaction processing
JP6129560B2 (en) 2010-03-11 2017-05-17 ウォル−マート・ストアーズ・インコーポレイテッドWal−Mart Stores, Inc. System and method for transaction payments using portable devices
US8892474B1 (en) * 2010-03-11 2014-11-18 Bank Of America Corporation Virtual purchasing card transaction
US10460316B2 (en) * 2010-04-05 2019-10-29 Paypal, Inc. Two device authentication
US20110276417A1 (en) * 2010-05-05 2011-11-10 Andrew Campbell System for personalized payments via mobile and internet connected devices
US8355987B2 (en) * 2010-05-06 2013-01-15 Boku, Inc. Systems and methods to manage information
KR101318958B1 (en) * 2010-05-06 2013-10-29 (주)시루정보 Method for payment service and device mobile communication terminal and transaction terminal
US20110276419A1 (en) * 2010-05-10 2011-11-10 Craig Johnson System and method for payment between a hand held` device and a merchant device
US9143807B2 (en) * 2010-06-22 2015-09-22 Livetv, Llc Registration of a personal electronic device (PED) with an aircraft IFE system using PED generated registration token images and associated methods
US9143732B2 (en) * 2010-06-22 2015-09-22 Livetv, Llc Aircraft IFE system cooperating with a personal electronic device (PED) operating as a commerce device and associated methods
AU2015202031B2 (en) * 2010-06-29 2016-10-13 Paypal, Inc. Smart wallet
US20120123841A1 (en) 2010-06-29 2012-05-17 Ebay, Inc. Smart wallet
US8571939B2 (en) 2010-07-07 2013-10-29 Toshiba Global Commerce Solutions Holdings Corporation Two phase payment link and authorization for mobile devices
US20120016856A1 (en) * 2010-07-15 2012-01-19 Google Inc Content extractor
US8392261B2 (en) 2010-07-15 2013-03-05 Google Inc. Local shopping and inventory
US8676161B2 (en) 2010-07-20 2014-03-18 Mastercard International Incorporated Enforcing time-out periods in payment-enabled mobile device
US9595036B2 (en) 2010-09-10 2017-03-14 Bank Of America Corporation Service for exceeding account thresholds via mobile device
US20120066077A1 (en) * 2010-09-10 2012-03-15 Bank Of America Corporation Overage service via mobile device
US9595035B2 (en) 2010-09-10 2017-03-14 Bank Of America Corporation Service for exceeding account thresholds via transaction machine
US9047640B2 (en) 2010-09-10 2015-06-02 Bank Of America Corporation Exceeded account threshold service involving exceeded account threshold magnetic stripe
US9508076B2 (en) 2010-09-10 2016-11-29 Bank Of America Corporation Service for account with unavailable funds or credit using a passcode
US9098521B2 (en) 2010-09-15 2015-08-04 Qualcomm Incorporated System and method for managing resources and threshsold events of a multicore portable computing device
US8806502B2 (en) 2010-09-15 2014-08-12 Qualcomm Incorporated Batching resource requests in a portable computing device
US8615755B2 (en) 2010-09-15 2013-12-24 Qualcomm Incorporated System and method for managing resources of a portable computing device
US8631414B2 (en) 2010-09-15 2014-01-14 Qualcomm Incorporated Distributed resource management in a portable computing device
US9152523B2 (en) 2010-09-15 2015-10-06 Qualcomm Incorporated Batching and forking resource requests in a portable computing device
US9953309B2 (en) 2010-09-21 2018-04-24 Visa International Service Association Third party integrated security system
EP2434793B1 (en) * 2010-09-23 2014-03-12 BlackBerry Limited Mobile wireless communications device establishing wireless communication links based upon near field communication and related methods
US8798532B2 (en) 2010-09-23 2014-08-05 Blackberry Limited Mobile wireless communications device establishing wireless communication links based upon near field communication and related methods
US20120084162A1 (en) * 2010-10-05 2012-04-05 Merrill Brooks Smith Systems and methods for conducting a composite bill payment transaction
US11144916B2 (en) * 2010-10-28 2021-10-12 Ncr Corporation Techniques for conducting single or limited use purchases via a mobile device
EP2455922B1 (en) 2010-11-17 2018-12-05 Inside Secure NFC transaction method and system
US11978031B2 (en) 2010-12-14 2024-05-07 E2Interactive, Inc. Systems and methods that create a pseudo prescription from transaction data generated during a point of sale purchase at a front of a store
TWI588761B (en) * 2010-12-28 2017-06-21 li-he Yao Wireless secure transaction payment system and its method
US11004056B2 (en) 2010-12-30 2021-05-11 Visa International Service Association Mixed mode transaction protocol
WO2012103147A2 (en) * 2011-01-24 2012-08-02 Visa International Service Association Transaction overrides
US9659286B2 (en) 2011-01-28 2017-05-23 Target Brands, Inc. Point-of-sale terminal having a scanner shared by full and scan-only checkout modules
US9916619B2 (en) * 2011-02-14 2018-03-13 Paypal, Inc. Payment system with location restrictions
US9773285B2 (en) 2011-03-08 2017-09-26 Bank Of America Corporation Providing data associated with relationships between individuals and images
US8811711B2 (en) 2011-03-08 2014-08-19 Bank Of America Corporation Recognizing financial document images
US8873807B2 (en) 2011-03-08 2014-10-28 Bank Of America Corporation Vehicle recognition
US8438110B2 (en) 2011-03-08 2013-05-07 Bank Of America Corporation Conducting financial transactions based on identification of individuals in an augmented reality environment
US8611601B2 (en) 2011-03-08 2013-12-17 Bank Of America Corporation Dynamically indentifying individuals from a captured image
US8929591B2 (en) 2011-03-08 2015-01-06 Bank Of America Corporation Providing information associated with an identified representation of an object
US9317860B2 (en) 2011-03-08 2016-04-19 Bank Of America Corporation Collective network of augmented reality users
US8582850B2 (en) 2011-03-08 2013-11-12 Bank Of America Corporation Providing information regarding medical conditions
US8688559B2 (en) 2011-03-08 2014-04-01 Bank Of America Corporation Presenting investment-related information on a mobile communication device
US8922657B2 (en) 2011-03-08 2014-12-30 Bank Of America Corporation Real-time video image analysis for providing security
US8660951B2 (en) 2011-03-08 2014-02-25 Bank Of America Corporation Presenting offers on a mobile communication device
US9406031B2 (en) 2011-03-08 2016-08-02 Bank Of America Corporation Providing social impact information associated with identified products or businesses
US9224166B2 (en) * 2011-03-08 2015-12-29 Bank Of America Corporation Retrieving product information from embedded sensors via mobile device video analysis
US8721337B2 (en) 2011-03-08 2014-05-13 Bank Of America Corporation Real-time video image analysis for providing virtual landscaping
US9317835B2 (en) 2011-03-08 2016-04-19 Bank Of America Corporation Populating budgets and/or wish lists using real-time video image analysis
US8668498B2 (en) 2011-03-08 2014-03-11 Bank Of America Corporation Real-time video image analysis for providing virtual interior design
US8571888B2 (en) 2011-03-08 2013-10-29 Bank Of America Corporation Real-time image analysis for medical savings plans
US8718612B2 (en) 2011-03-08 2014-05-06 Bank Of American Corporation Real-time analysis involving real estate listings
US8392259B2 (en) 2011-03-17 2013-03-05 Research In Motion Limited Methods and apparatus to obtain transaction confirmation
AP3678A (en) * 2011-04-11 2016-04-16 Visa Int Service Ass Interoperable financial transactions via mobile devices
US9715704B2 (en) 2011-05-11 2017-07-25 Riavera Corp Merchant ordering system using optical machine readable image representation of invoice information
US9547861B2 (en) 2011-05-11 2017-01-17 Mark Itwaru System and method for wireless communication with an IC chip for submission of pin data
MX2013013164A (en) 2011-05-11 2014-09-01 Mark Itwaru Mobile image payment system using short codes.
WO2012151660A1 (en) * 2011-05-11 2012-11-15 Mark Itwaru Mobile image payment system
US9734498B2 (en) 2011-05-11 2017-08-15 Riavera Corp Mobile image payment system using short codes
US9785935B2 (en) 2011-05-11 2017-10-10 Riavera Corp. Split mobile payment system
US10223674B2 (en) 2011-05-11 2019-03-05 Riavera Corp. Customized transaction flow for multiple transaction types using encoded image representation of transaction information
US9721243B2 (en) 2011-05-11 2017-08-01 Riavera Corp. Mobile payment system using subaccounts of account holder
US8616453B2 (en) 2012-02-15 2013-12-31 Mark Itwaru System and method for processing funds transfer between entities based on received optical machine readable image information
US20120296725A1 (en) * 2011-05-17 2012-11-22 Dessert Robert L System and method for managing transactions with a portable computing device
US20120296726A1 (en) * 2011-05-17 2012-11-22 Firethorn Mobile, Inc. System and Method For Managing Transactions With A Portable Computing Device
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
US12014347B2 (en) 2011-07-18 2024-06-18 Rabih S. Ballout Kit, system and associated method and service for providing a platform to prevent fraudulent financial transactions
US10733593B2 (en) 2011-07-18 2020-08-04 Rabih S. Ballout Kit, system and associated method and service for providing a platform to prevent fraudulent financial transactions
US8554671B2 (en) * 2011-07-18 2013-10-08 Rabih Salem Ballout System and associated method and service for providing a platform that allows for the exchange of cash between members in a mobile environment
US20130036050A1 (en) * 2011-08-02 2013-02-07 Bank Of America Corporation System and method for using a near field communication device to conduct a transaction with an alias
US9008616B2 (en) * 2011-08-19 2015-04-14 Google Inc. Point of sale processing initiated by a single tap
US9390414B2 (en) 2011-09-18 2016-07-12 Google Inc. One-click offline buying
US8577731B1 (en) 2011-09-30 2013-11-05 Sprint Communications Company L.P. Method of transaction processing to support proxy financial card
US9105025B2 (en) 2011-10-17 2015-08-11 Capital One Financial Corporation Enhanced near field communications attachment
US10482457B2 (en) 2011-10-17 2019-11-19 Capital One Services, Llc System and method for token-based payments
US9183490B2 (en) * 2011-10-17 2015-11-10 Capital One Financial Corporation System and method for providing contactless payment with a near field communications attachment
US10510056B2 (en) * 2011-11-02 2019-12-17 Mastercard International Incorporated Method and system for multiple payment applications
US10007906B2 (en) * 2011-11-17 2018-06-26 Abdolreza Behjat Using a mobile device in a commercial transaction
US10438196B2 (en) 2011-11-21 2019-10-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US9292846B2 (en) * 2011-11-28 2016-03-22 Mocapay, Inc. Mobile device authorization system for concurrent submission of multiple tender types
US20130173425A1 (en) * 2011-12-30 2013-07-04 Intuit Inc. Consumer-initiated financial transaction based on sales-side information
US20140195361A1 (en) * 2011-12-31 2014-07-10 Kaitlin Murphy Method and system for active receipt management
US8566168B1 (en) * 2012-01-05 2013-10-22 Sprint Communications Company L.P. Electronic payment using a proxy account number stored in a secure element
US20130185214A1 (en) * 2012-01-12 2013-07-18 Firethorn Mobile Inc. System and Method For Secure Offline Payment Transactions Using A Portable Computing Device
US9420403B1 (en) 2012-01-31 2016-08-16 Sprint Communications Company L.P. Remote deactivation of near field communication functionality
US8774721B2 (en) 2012-04-10 2014-07-08 Google Inc. Detecting a communication tap via signal monitoring
US9286266B1 (en) 2012-05-04 2016-03-15 Left Lane Network, Inc. Cloud computed data service for automated reporting of vehicle trip data and analysis
US20130304553A1 (en) 2012-05-09 2013-11-14 Google Inc. Point of sale offer redemptions
US8862181B1 (en) 2012-05-29 2014-10-14 Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure
US20150161578A1 (en) * 2012-06-04 2015-06-11 Nokia Corporation Method and apparatus for providing navigation-centric billing and payment
US9947004B2 (en) 2012-06-28 2018-04-17 Green Dot Corporation Wireless client transaction systems and related methods
US20140019322A1 (en) 2012-07-13 2014-01-16 Green Dot Corporation Mobile banking systems and related methods
US20140025457A1 (en) * 2012-07-17 2014-01-23 Mastercard International Incorporated Method and system for deal redemption by electronic wallet
US11195182B2 (en) * 2012-07-31 2021-12-07 Worldpay, Llc Systems and methods for cost altering payment services
US11055686B2 (en) 2012-08-08 2021-07-06 E2Interactive, Inc. S/M for providing, reloading, and redeeming stored value cards used in transit applications
WO2014028110A1 (en) * 2012-08-15 2014-02-20 Qualcomm Incorporated System and method for managing transactions with a portable computing device
US9569769B2 (en) 2012-09-17 2017-02-14 E2Interactive, Inc. Composite activation indicia substrate
US9171328B2 (en) 2012-12-20 2015-10-27 Wal-Mart Stores, Inc. Method for transferring shopping cart contents to a register from a mobile electronic device
CN103914777A (en) * 2013-01-08 2014-07-09 舒默 Self-service internet-of-things shopping system and self-service handheld shopping terminal
US9818104B1 (en) 2013-01-25 2017-11-14 Sprint Communications Company L.P. Secure online credit card transactions
US9704146B1 (en) 2013-03-14 2017-07-11 Square, Inc. Generating an online storefront
US9940616B1 (en) 2013-03-14 2018-04-10 Square, Inc. Verifying proximity during payment transactions
US9870556B2 (en) * 2013-05-22 2018-01-16 Google Llc Split tender in a prepaid architecture
US10147112B2 (en) 2013-05-22 2018-12-04 Google Llc Delayed processing window in a prepaid architecture
US20140379577A1 (en) * 2013-06-24 2014-12-25 Infosys Limited Methods, systems, and computer-readable media for providing financial transactions
US9384497B2 (en) 2013-07-26 2016-07-05 Bank Of America Corporation Use of SKU level e-receipt data for future marketing
US20150081548A1 (en) * 2013-08-15 2015-03-19 MDR Group LLC Methods and systems for making mobile payments
US9922321B2 (en) 2013-10-22 2018-03-20 Square, Inc. Proxy for multiple payment mechanisms
US10417635B1 (en) 2013-10-22 2019-09-17 Square, Inc. Authorizing a purchase transaction using a mobile device
US9836739B1 (en) 2013-10-22 2017-12-05 Square, Inc. Changing a financial account after initiating a payment using a proxy card
US8892462B1 (en) 2013-10-22 2014-11-18 Square, Inc. Proxy card payment with digital receipt delivery
US11120462B2 (en) 2013-11-04 2021-09-14 E2Interactive, Inc. Systems and methods for using indicia of membership as a partial authorization in a transaction
US20150134439A1 (en) 2013-11-08 2015-05-14 Square, Inc. Interactive digital receipt
US20150178731A1 (en) * 2013-12-20 2015-06-25 Ncr Corporation Mobile device assisted service
US9646297B2 (en) * 2013-12-23 2017-05-09 Mastercard International Incorporated Method and system of providing financial transaction card related mobile apps
US10810682B2 (en) 2013-12-26 2020-10-20 Square, Inc. Automatic triggering of receipt delivery
US10621563B1 (en) 2013-12-27 2020-04-14 Square, Inc. Apportioning a payment card transaction among multiple payers
US11138581B2 (en) * 2014-01-10 2021-10-05 Elo Touch Solutions, Inc. Multi-mode point-of-sale device
US10198731B1 (en) 2014-02-18 2019-02-05 Square, Inc. Performing actions based on the location of mobile device during a card swipe
US9224141B1 (en) 2014-03-05 2015-12-29 Square, Inc. Encoding a magnetic stripe of a card with data of multiple cards
US20150254662A1 (en) * 2014-03-05 2015-09-10 Mastercard International Incorporated Verifying transaction context data at wallet service provider
JP5703452B1 (en) * 2014-03-06 2015-04-22 パナソニックIpマネジメント株式会社 Information processing apparatus and information processing method
US10692059B1 (en) 2014-03-13 2020-06-23 Square, Inc. Selecting a financial account associated with a proxy object based on fund availability
US9619792B1 (en) 2014-03-25 2017-04-11 Square, Inc. Associating an account with a card based on a photo
US9864986B1 (en) 2014-03-25 2018-01-09 Square, Inc. Associating a monetary value card with a payment object
US9569767B1 (en) 2014-05-06 2017-02-14 Square, Inc. Fraud protection based on presence indication
US9911116B1 (en) * 2014-05-06 2018-03-06 Square, Inc. Fraud protection in payment card transactions
US9881305B1 (en) * 2014-05-06 2018-01-30 Square, Inc. Context-based restrictions on payment cards
US20150332223A1 (en) 2014-05-19 2015-11-19 Square, Inc. Transaction information collection for mobile payment experience
US20150356547A1 (en) * 2014-06-05 2015-12-10 Lutfi Abed System and method for providing tipping and review services via a mobile device
US20150363762A1 (en) * 2014-06-14 2015-12-17 Mastercard International Incorporated Apparatus, method, and computer program product for mobile open payment network
WO2015199977A1 (en) * 2014-06-27 2015-12-30 Psi Systems, Inc. Systems and methods providing payment transactions
CA2954788A1 (en) * 2014-07-11 2016-01-14 Avanti Commerce Inc. Reliable, robust and structured duplex communication infrastructure for mobile quick service transactions
US9613381B2 (en) 2014-08-15 2017-04-04 Mastercard International Incorporated Payroll system with flexible disbursement options
EP2998916A1 (en) * 2014-09-18 2016-03-23 Vodafone GmbH Method and system for carrying out payment transactions
US20160098699A1 (en) * 2014-10-07 2016-04-07 Mastercard International Incorporated User-friendly mobile payments system
WO2016057025A1 (en) * 2014-10-07 2016-04-14 Demandware, Inc. Contract broker for secure ad-hoc personal data sharing
US10140623B1 (en) 2014-10-27 2018-11-27 Square, Inc. Detection and explanation of lifts in merchant data
US9792605B2 (en) * 2014-11-06 2017-10-17 Mastercard International Incorporated System and method for split payment card account transactions
US9985699B1 (en) 2014-12-16 2018-05-29 Blazer and Flip Flops, Inc. NFC center
US10783508B1 (en) 2014-12-16 2020-09-22 Square, Inc. Processing multiple point-of-sale transactions
US10580011B1 (en) 2014-12-17 2020-03-03 Blazer and Flip Flops, Inc. NFC-based options selection
US10679207B1 (en) * 2014-12-17 2020-06-09 Blazer and Flip Flops, Inc. Bill splitting and account delegation for NFC
US10262318B1 (en) 2014-12-17 2019-04-16 Blazer and Flip Flops, Inc. Eligibility verification for real-time offers
US11062375B1 (en) 2014-12-17 2021-07-13 Blazer and Flip Flops, Inc. Automatic shopping based on historical data
US10262311B1 (en) 2014-12-17 2019-04-16 Blazer and Flip Flops, Inc. NFC-based payments tagging
US10037517B1 (en) 2014-12-22 2018-07-31 Square, Inc. Risk management in online and offline transactions
US10037528B2 (en) 2015-01-14 2018-07-31 Tactilis Sdn Bhd Biometric device utilizing finger sequence for authentication
US9607189B2 (en) 2015-01-14 2017-03-28 Tactilis Sdn Bhd Smart card system comprising a card and a carrier
US20160203492A1 (en) * 2015-01-14 2016-07-14 Tactilis Sdn Bhd System and method for requesting reconciliation of electronic transaction records for enhanced security
US10395227B2 (en) 2015-01-14 2019-08-27 Tactilis Pte. Limited System and method for reconciling electronic transaction records for enhanced security
US20160253643A1 (en) * 2015-02-27 2016-09-01 Ncr Corporation Method of completing a purchase transaction
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US10528945B1 (en) 2015-03-31 2020-01-07 Square, Inc. Open ticket payment handling with incremental authorization
US10043162B1 (en) * 2015-03-31 2018-08-07 Square, Inc. Open ticket payment handling with bill splitting
US20160321658A1 (en) * 2015-04-28 2016-11-03 Mastercard International Incorporated Method for leveraging multiple products
US10475011B1 (en) 2015-04-30 2019-11-12 Square, Inc. Automatic invoice notification
US10055769B1 (en) * 2015-04-30 2018-08-21 Square, Inc. Automatic invoice generation
US10026062B1 (en) 2015-06-04 2018-07-17 Square, Inc. Apparatuses, methods, and systems for generating interactive digital receipts
US9727869B1 (en) 2015-06-05 2017-08-08 Square, Inc. Expedited point-of-sale merchant payments
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
US10430788B2 (en) 2015-08-06 2019-10-01 Green Dot Corporation Systems and methods for fund transfers
US20170053276A1 (en) * 2015-08-21 2017-02-23 Green Dot Corporation Systems and Methods for Transaction Routing
US9569757B1 (en) 2015-09-30 2017-02-14 Square, Inc. Anticipatory creation of point-of-sale data structures
JP6657727B2 (en) * 2015-09-30 2020-03-04 日本電気株式会社 POS device
US10607200B2 (en) 2015-12-28 2020-03-31 Square, Inc. Point of sale system having a customer terminal and a merchant terminal
US10021672B2 (en) 2016-01-04 2018-07-10 Bank Of America Corporation Resource allocation based on available resources via interactive interface
US10506641B2 (en) 2016-01-04 2019-12-10 Bank Of America Corporation Resource optimization allocation system
US10853784B2 (en) 2016-01-04 2020-12-01 Bank Of America Corporation Real-time determination of resource availability for usage
US10068211B2 (en) 2016-01-04 2018-09-04 Bank Of America Corporation Reallocation of resources system
SG10201601831SA (en) * 2016-03-09 2017-10-30 Mastercard International Inc Methods and devices for obtaining information about consumer spending
US10039113B2 (en) 2016-03-28 2018-07-31 Bank Of America Corporation Intelligent resource procurement system based on physical proximity to related resources
US10080132B2 (en) 2016-03-28 2018-09-18 Bank Of America Corporation System for adaptation of multiple digital signatures in a distributed network
US9507984B1 (en) 2016-03-28 2016-11-29 Bank Of America Corporation Resource tag generation and deployment for resource valuation and distribution
US9743272B1 (en) 2016-03-28 2017-08-22 Bank Of America Corporation Security implementation for resource distribution
US10135817B2 (en) 2016-03-28 2018-11-20 Bank Of America Corporation Enhancing authentication and source of proof through a dynamically updatable biometrics database
US9805370B1 (en) 2016-03-31 2017-10-31 Square, Inc. Device fingerprinting at a merchant location
US10636019B1 (en) 2016-03-31 2020-04-28 Square, Inc. Interactive gratuity platform
US10291487B2 (en) 2016-06-08 2019-05-14 Bank Of America Corporation System for predictive acquisition and use of resources
US10433196B2 (en) 2016-06-08 2019-10-01 Bank Of America Corporation System for tracking resource allocation/usage
US10129126B2 (en) 2016-06-08 2018-11-13 Bank Of America Corporation System for predictive usage of resources
US10581988B2 (en) 2016-06-08 2020-03-03 Bank Of America Corporation System for predictive use of resources
US10178101B2 (en) 2016-06-08 2019-01-08 Bank Of America Corporation System for creation of alternative path to resource acquisition
US10311420B1 (en) 2016-06-17 2019-06-04 Square, Inc. Synchronizing open ticket functionality with kitchen display systems
US10796253B2 (en) 2016-06-17 2020-10-06 Bank Of America Corporation System for resource use allocation and distribution
US10289992B1 (en) 2016-06-17 2019-05-14 Square, Inc. Kitchen display interfaces with in flight capabilities
US10038607B2 (en) 2016-06-17 2018-07-31 Bank Of America Corporation System for aggregated machine-initiated resource distribution
US10103936B2 (en) 2016-06-21 2018-10-16 Bank Of America Corporation Computerized resource reallocation system for transferring resource blocks based on custodian event
US10504092B2 (en) 2016-06-21 2019-12-10 Square, Inc. Transaction interface control
US10360648B1 (en) 2016-06-22 2019-07-23 Square, Inc. Synchronizing KDS functionality with POS waitlist generation
US10334462B2 (en) * 2016-06-23 2019-06-25 Bank Of America Corporation Predictive analytics for resource development based on information communicated from inter-related communication devices
US10580062B1 (en) 2016-06-28 2020-03-03 Square, Inc. Integrating predefined templates with open ticket functionality
US10366378B1 (en) 2016-06-30 2019-07-30 Square, Inc. Processing transactions in offline mode
US12130937B1 (en) 2016-07-01 2024-10-29 Wells Fargo Bank, N.A. Control tower for prospective transactions
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US10439913B2 (en) 2016-07-01 2019-10-08 Bank Of America Corporation Dynamic replacement and upgrade of existing resources based on resource utilization
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11430070B1 (en) 2017-07-31 2022-08-30 Block, Inc. Intelligent application of reserves to transactions
US10127400B2 (en) 2016-09-26 2018-11-13 Bank Of America Corporation Control device for aggregation and distribution of machine-initiated resource distribution
KR101758575B1 (en) * 2016-11-14 2017-07-26 이선관 Method and system for financial payment using mobile devices
US12051055B2 (en) * 2016-11-14 2024-07-30 Ghost Pass Inc. Financial payment method and payment system using mobile device
US10373146B2 (en) 2016-12-29 2019-08-06 Capital One Services, Llc Smart card NFC secure money transfer
CN107038560B (en) * 2017-01-06 2020-09-08 阿里巴巴集团控股有限公司 System, method and device for executing payment service
US10977624B2 (en) 2017-04-12 2021-04-13 Bank Of America Corporation System for generating paper and digital resource distribution documents with multi-level secure authorization requirements
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
US10122889B1 (en) 2017-05-08 2018-11-06 Bank Of America Corporation Device for generating a resource distribution document with physical authentication markers
US20180330361A1 (en) * 2017-05-09 2018-11-15 Mastercard International Incorporated Payment account system transaction notification and reporting methods and apparatus
US10621363B2 (en) 2017-06-13 2020-04-14 Bank Of America Corporation Layering system for resource distribution document authentication
US10524165B2 (en) 2017-06-22 2019-12-31 Bank Of America Corporation Dynamic utilization of alternative resources based on token association
US10511692B2 (en) 2017-06-22 2019-12-17 Bank Of America Corporation Data transmission to a networked resource based on contextual information
US10313480B2 (en) 2017-06-22 2019-06-04 Bank Of America Corporation Data transmission between networked resources
US10915900B1 (en) 2017-06-26 2021-02-09 Square, Inc. Interchange action delay based on refund prediction
US11062388B1 (en) 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
SG10201706266YA (en) * 2017-08-01 2019-03-28 Mastercard International Inc Method and system for transaction authorization
US11715154B2 (en) 2017-09-22 2023-08-01 Green Dot Corporation Systems and methods for managing accounts in a financial services system
US10943311B1 (en) 2017-09-29 2021-03-09 Square, Inc. Order fulfillment and tracking systems and methods
US10467559B1 (en) 2017-09-29 2019-11-05 Square, Inc. Order fulfillment and tracking systems and methods
US10783509B2 (en) 2017-09-29 2020-09-22 Square, Inc. Message sizing and serialization optimization
WO2019075162A1 (en) * 2017-10-13 2019-04-18 Walmart Apollo, Llc Open mobile payment systems and methods
US11935024B1 (en) 2017-10-20 2024-03-19 Block, Inc. Account-based data and marketplace generation
US20190147417A1 (en) * 2017-11-14 2019-05-16 American Express Travel Related Services Company, Inc. Item Information Retrieval System
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
WO2019125841A1 (en) * 2017-12-19 2019-06-27 Mastercard Internationa Incorporated A server and method for determining if an account in a transaction request is eligible for a promotion
US11270288B2 (en) 2017-12-19 2022-03-08 International Business Machines Corporation System and method for automatic device connection following a contactless payment transaction
US11893581B1 (en) 2018-02-20 2024-02-06 Block, Inc. Tokenization for payment devices
CN109146318A (en) * 2018-09-11 2019-01-04 深圳市卓邦远科技有限公司 A kind of marketing system and marketing method of automatic vending nail beauty machine
US11210721B1 (en) 2018-10-15 2021-12-28 Square, Inc. Converting items into vectors to determine optimized locations
US11244382B1 (en) 2018-10-31 2022-02-08 Square, Inc. Computer-implemented method and system for auto-generation of multi-merchant interactive image collection
US11210730B1 (en) 2018-10-31 2021-12-28 Square, Inc. Computer-implemented methods and system for customized interactive image collection based on customer data
TWI678096B (en) * 2018-11-09 2019-11-21 虹光精密工業股份有限公司 File processing system and method for exchanging data by graphic code
US11138680B1 (en) 2018-11-21 2021-10-05 Square, Inc. Updating menus based on predicted efficiencies
US11645613B1 (en) 2018-11-29 2023-05-09 Block, Inc. Intelligent image recommendations
US10915905B1 (en) 2018-12-13 2021-02-09 Square, Inc. Batch-processing transactions in response to an event
US11250406B2 (en) * 2018-12-31 2022-02-15 Paypal, Inc. Split transaction physical payment instrument
US11562355B2 (en) 2019-01-31 2023-01-24 Visa International Service Association Method, system, and computer program product for automatically re-processing a transaction
US11514428B2 (en) * 2019-07-10 2022-11-29 Slip Cash Inc. Device for launching multiple peer to peer cashless payment applications on mobile devices
JP6686242B1 (en) * 2019-07-17 2020-04-22 楽天株式会社 Information providing system and information providing method
US11783310B1 (en) * 2020-06-16 2023-10-10 Block, Inc. Point-of-sale authorization
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US20230146558A1 (en) * 2021-11-07 2023-05-11 ExtoLabs, LLC Secure Pairing for Payment Devices
US20240169358A1 (en) * 2022-11-21 2024-05-23 Igt Debit card integrated with multiple gaming establishment account management systems

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6047269A (en) * 1996-07-19 2000-04-04 Peter Biffar Self-contained payment system with circulating digital vouchers
US20030233317A1 (en) * 2001-01-30 2003-12-18 Nyce Corporation Methods and systems for transferring funds
US20040019564A1 (en) * 2002-07-26 2004-01-29 Scott Goldthwaite System and method for payment transaction authentication
US20040049455A1 (en) * 2001-07-06 2004-03-11 Hossein Mohsenzadeh Secure authentication and payment system
US20040107170A1 (en) * 2002-08-08 2004-06-03 Fujitsu Limited Apparatuses for purchasing of goods and services
US6807410B1 (en) * 1999-02-19 2004-10-19 France Telecom Electronic payment process and system for implementing this process
US20040248554A1 (en) * 2003-06-09 2004-12-09 Khan Mohammad Ather Method of paying from an account by a customer having a mobile user terminal, and a customer authenticating network
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
US7058611B2 (en) * 2000-07-10 2006-06-06 Mastercard International Incorporated Method and system for conducting secure electronic commerce transactions with authorization request data loop-back
US20070179885A1 (en) * 2006-01-30 2007-08-02 Cpni Inc. Method and system for authorizing a funds transfer or payment using a phone number
US7258267B2 (en) * 2003-12-19 2007-08-21 Keyzap Inc. Wireless banking system and wireless banking method using mobile phones
US20080099552A1 (en) * 2006-10-26 2008-05-01 Robert John Grillion Method and apparatus for wireless authorization

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0950968A4 (en) * 1997-08-13 2004-05-19 Matsushita Electric Ind Co Ltd Mobile electronic commerce system
US7089208B1 (en) * 1999-04-30 2006-08-08 Paypal, Inc. System and method for electronically exchanging value among distributed users
WO2001024082A1 (en) * 1999-09-24 2001-04-05 Mary Mckenney System and method for providing payment services in electronic commerce
US6934689B1 (en) * 1999-10-25 2005-08-23 Swisscom Mobile Ag Payment transaction method and payment transaction system
US6535726B1 (en) * 2000-01-12 2003-03-18 Gilbarco Inc. Cellular telephone-based transaction processing
US7194422B1 (en) * 2000-03-08 2007-03-20 The Coca-Cola Company Disaggregated databases for tracking consumer purchasing data
FR2817061B1 (en) * 2000-11-22 2003-03-28 Welcome Real Time METHOD AND SYSTEM FOR RECEIVING, STORING AND PROCESSING ELECTRONIC COUPONS WITH A MOBILE TELEPHONE OR DIGITAL ASSISTANT
WO2002046881A2 (en) * 2000-12-09 2002-06-13 Singhal Tara Chand Method and apparatus for an integrated identity security and payment system
JP2002197390A (en) * 2000-12-25 2002-07-12 Nec Corp Transaction intermediary system and transaction intermediary method
US7921297B2 (en) * 2001-01-10 2011-04-05 Luis Melisendro Ortiz Random biometric authentication utilizing unique biometric signatures
EP1229467A1 (en) * 2001-02-06 2002-08-07 Wincor Nixdorf GmbH & Co KG Payment system comprising a mobile device
EP1372089A4 (en) 2001-03-13 2006-06-07 Fujitsu Ltd Electronic money settlement method using mobile communication terminal
US20020143634A1 (en) * 2001-03-30 2002-10-03 Kumar K. Anand Wireless payment system
US7280981B2 (en) * 2002-08-27 2007-10-09 Visa U.S.A. Inc. Method and system for facilitating payment transactions using access devices
US7571140B2 (en) * 2002-12-16 2009-08-04 First Data Corporation Payment management
US8352360B2 (en) * 2003-06-30 2013-01-08 Toshiba Global Commerce Solutions Holdings Corporation Method and system for secured transactions over a wireless network
CN1849632A (en) * 2003-07-02 2006-10-18 莫比培国际公司 Digital mobile telephone transaction and payment system
EP1530177B1 (en) * 2003-11-07 2006-09-13 Alcatel Method for supporting cashless payment
US20060018450A1 (en) * 2004-07-26 2006-01-26 Erik Sandberg-Diment Mobile telephone transaction system employing electronic account card
US20060293952A1 (en) * 2005-06-22 2006-12-28 Nicholson G R Debit card incentive system and method
WO2007023483A2 (en) 2005-08-22 2007-03-01 Meir Shavit Method and system for providing banking services to a user of a communication device
US7487912B2 (en) * 2005-09-28 2009-02-10 First Data Corporation Electronic receipting
CN1828649A (en) * 2005-12-22 2006-09-06 韩燕� Electronic payment identification method and its ID identification terminal and ATM
US7641111B2 (en) * 2005-12-29 2010-01-05 Research In Motion Limited Method and apparatus for contactless payment authentication
US7818264B2 (en) * 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US7775442B2 (en) * 2006-07-12 2010-08-17 Nokia Corporation Method for accessing after-operation information of secure element applications
US20080208681A1 (en) * 2006-09-28 2008-08-28 Ayman Hammad Payment using a mobile device
US20080208762A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Payments using a mobile commerce device
US8548908B2 (en) * 2007-04-11 2013-10-01 First Data Corporation Mobile commerce infrastructure systems and methods
US20100299212A1 (en) * 2008-08-27 2010-11-25 Roam Data Inc System and method for a commerce window application for computing devices

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6047269A (en) * 1996-07-19 2000-04-04 Peter Biffar Self-contained payment system with circulating digital vouchers
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
US6807410B1 (en) * 1999-02-19 2004-10-19 France Telecom Electronic payment process and system for implementing this process
US7058611B2 (en) * 2000-07-10 2006-06-06 Mastercard International Incorporated Method and system for conducting secure electronic commerce transactions with authorization request data loop-back
US20030233317A1 (en) * 2001-01-30 2003-12-18 Nyce Corporation Methods and systems for transferring funds
US20040049455A1 (en) * 2001-07-06 2004-03-11 Hossein Mohsenzadeh Secure authentication and payment system
US20040019564A1 (en) * 2002-07-26 2004-01-29 Scott Goldthwaite System and method for payment transaction authentication
US20040107170A1 (en) * 2002-08-08 2004-06-03 Fujitsu Limited Apparatuses for purchasing of goods and services
US20040248554A1 (en) * 2003-06-09 2004-12-09 Khan Mohammad Ather Method of paying from an account by a customer having a mobile user terminal, and a customer authenticating network
US7258267B2 (en) * 2003-12-19 2007-08-21 Keyzap Inc. Wireless banking system and wireless banking method using mobile phones
US20070179885A1 (en) * 2006-01-30 2007-08-02 Cpni Inc. Method and system for authorizing a funds transfer or payment using a phone number
US20080099552A1 (en) * 2006-10-26 2008-05-01 Robert John Grillion Method and apparatus for wireless authorization

Cited By (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11004061B2 (en) 2006-09-24 2021-05-11 Rfcyber Corporation Method and apparatus for payments between two mobile devices
US8589300B2 (en) * 2007-10-25 2013-11-19 Visa U.S.A. Inc. Payment transaction using mobile phone as relay
US9015064B2 (en) * 2007-11-30 2015-04-21 Michelle Fisher Utilizing a secure element for NFC transactions which includes response data during induction
US20130097032A1 (en) * 2007-11-30 2013-04-18 Blaze Mobile, Inc. Utilizing shopping lists for nfc transactions
US20090182634A1 (en) * 2008-01-10 2009-07-16 Park David S Image-Based Payment Medium
US8249967B2 (en) * 2008-01-10 2012-08-21 Park David S Image-based payment medium
US20090202081A1 (en) * 2008-02-08 2009-08-13 Ayman Hammad Key delivery system and method
US8606662B2 (en) * 2008-04-04 2013-12-10 Mastercard International Incorporated Methods and systems for managing co-brand proprietary financial transaction processing
US20090254462A1 (en) * 2008-04-04 2009-10-08 Brad Michael Tomchek Methods and systems for managing co-brand proprietary financial transaction processing
US20090254463A1 (en) * 2008-04-04 2009-10-08 Brad Michael Tomchek Methods and systems for managing merchant screening
US8271392B2 (en) 2008-04-04 2012-09-18 Mastercard International Incorporated Methods and systems for managing merchant screening
US9626821B2 (en) * 2008-04-24 2017-04-18 Qualcomm Incorporated Electronic payment system
US20090271276A1 (en) * 2008-04-24 2009-10-29 Qualcomm Incorporated Electronic payment system
US20140129451A1 (en) * 2008-10-13 2014-05-08 Mark Carlson P2P Transfer Using Prepaid Card
US20100145855A1 (en) * 2008-12-06 2010-06-10 Fordyce Iii Edward W Payment account processing which conveys non purchase related data exchanges
US8463650B2 (en) * 2009-03-05 2013-06-11 Barclays Bank Delaware Systems and methods to initiate payments from electronic devices
US20100228639A1 (en) * 2009-03-05 2010-09-09 Barclays Bank Delaware Systems And Methods To Initiate Payments From Electronic Devices
US9478094B2 (en) * 2009-12-29 2016-10-25 Pitney Bowes Inc. Postal services kiosk having payment card security
US20110161231A1 (en) * 2009-12-29 2011-06-30 Pitney Bowes Inc. Postal services kiosk having payment card security
US20110213711A1 (en) * 2010-03-01 2011-09-01 Entrust, Inc. Method, system and apparatus for providing transaction verification
US20120005076A1 (en) * 2010-07-02 2012-01-05 Firethorn Holdings, Llc System and method for managing transactions with a portable computing device
US8660948B2 (en) * 2010-07-02 2014-02-25 Qualcomm Incorporated System and method for managing transactions with a portable computing device
US20140122206A1 (en) * 2010-07-02 2014-05-01 Qualcomm Incorporated System and method for managing transactions with a portable computing device
US20140222546A1 (en) * 2010-07-02 2014-08-07 Qualcomm Incorporated System and method for managing transactions with a portable computing device
US8442914B2 (en) 2010-07-06 2013-05-14 Mastercard International Incorporated Virtual wallet account with automatic-loading
US10664832B2 (en) 2010-07-06 2020-05-26 Mastercard International Incorporated Virtual wallet account with automatic-loading
WO2012009165A1 (en) * 2010-07-16 2012-01-19 Mastercard International, Inc. Money transfer system gateway service
US10733644B2 (en) 2010-09-30 2020-08-04 Paypal, Inc. Location based transactions
US9721283B2 (en) 2010-09-30 2017-08-01 Paypal, Inc. Location based transactions
US20140214677A1 (en) * 2010-11-05 2014-07-31 Mastercard International Incorporated Remittance system with improved service for unbanked individuals
US10176477B2 (en) 2010-11-16 2019-01-08 Mastercard International Incorporated Methods and systems for universal payment account translation
US11017393B2 (en) 2011-02-25 2021-05-25 Visa International Service Association Direct connection systems and methods
US8924297B2 (en) * 2011-02-25 2014-12-30 Visa International Service Association Direct connection systems and methods
US9978063B2 (en) 2011-02-25 2018-05-22 Visa International Service Association Direct connection systems and methods
US20120221468A1 (en) * 2011-02-25 2012-08-30 Phil Kumnick Direct connection systems and methods
US10210497B2 (en) * 2011-04-06 2019-02-19 OnDot Systems, Inc. System and method for cashless peer-to-peer payment
WO2013055933A3 (en) * 2011-10-12 2014-05-01 Boost Payment Solutions, LLC Electronic payment processing
WO2013055933A2 (en) * 2011-10-12 2013-04-18 Boost Payment Solutions, LLC Electronic payment processing
US9270447B2 (en) 2011-11-03 2016-02-23 Arvind Gidwani Demand based encryption and key generation and distribution systems and methods
US11030607B2 (en) 2011-12-19 2021-06-08 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
US10127540B2 (en) * 2011-12-19 2018-11-13 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
US11687908B2 (en) 2011-12-19 2023-06-27 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
US20130166448A1 (en) * 2011-12-27 2013-06-27 Infosys Limited Financial transfers from mobile devices
US20200082376A1 (en) * 2012-07-16 2020-03-12 Square, Inc. Storing and Forwarding Payment Transactions
US11475431B2 (en) * 2012-07-16 2022-10-18 Block, Inc. Transaction processing by multiple devices
US11669826B2 (en) 2012-07-16 2023-06-06 Block, Inc. Transaction processing by multiple devices
DE102012214744A1 (en) 2012-08-20 2014-02-20 Tobias Pfütze Method and system for carrying out a financial transaction
WO2014029744A1 (en) 2012-08-20 2014-02-27 Pfuetze Tobias Method and system for executing a financial transaction
US9836733B2 (en) * 2013-03-15 2017-12-05 Cullinan Consulting Group Pty Ltd. Transaction verification system
US20140279103A1 (en) * 2013-03-15 2014-09-18 Cullinan Consulting Group Pty Ltd. System and method for enabling financial transactions
US20150006376A1 (en) * 2013-06-27 2015-01-01 Ebay Inc. Conductive payment device
US20230169586A1 (en) * 2013-11-20 2023-06-01 Capital One Services, Llc Shared expense management
US20150142661A1 (en) * 2013-11-20 2015-05-21 Capital One Financial Corporation Shared expense management
US10402899B2 (en) * 2013-11-20 2019-09-03 Capital One Services, Llc Shared expensive management
US11580596B2 (en) * 2013-11-20 2023-02-14 Capital One Services, Llc Shared expense management
US10592899B2 (en) 2014-05-13 2020-03-17 Visa International Service Association Master applet for secure remote payment processing
US12020247B1 (en) 2014-12-11 2024-06-25 Block, Inc. Intelligent payment capture in failed authorization requests
US11636462B2 (en) 2015-03-20 2023-04-25 Block, Inc. Context-aware peer-to-peer transfers of items
US11989718B2 (en) 2015-03-20 2024-05-21 Block, Inc. Context-aware peer-to-peer transfers of items
US11301825B2 (en) 2015-08-19 2022-04-12 Block, Inc. Customized transaction flow
US10410194B1 (en) 2015-08-19 2019-09-10 Square, Inc. Customized tipping flow
US11915216B2 (en) 2015-08-19 2024-02-27 Block, Inc. Dynamically determining a customized transaction flow
US20170171183A1 (en) * 2015-12-15 2017-06-15 Phaneendra Ramaseshu Lingappa Authentication of access request of a device and protecting confidential information
US10523441B2 (en) * 2015-12-15 2019-12-31 Visa International Service Association Authentication of access request of a device and protecting confidential information
US20220012698A1 (en) * 2020-07-07 2022-01-13 Mastercard International Incorporated Methods and systems of providing interoperability between incompatible payment systems
US11663563B2 (en) * 2020-07-07 2023-05-30 Mastercard International Incorporated Methods and systems of providing interoperability between incompatible payment systems

Also Published As

Publication number Publication date
US8762211B2 (en) 2014-06-24
US20090266884A1 (en) 2009-10-29
US20090094125A1 (en) 2009-04-09
US20130173407A1 (en) 2013-07-04
US20140289125A1 (en) 2014-09-25
US20090090783A1 (en) 2009-04-09
US20140032381A1 (en) 2014-01-30
US7988060B2 (en) 2011-08-02
US20090094126A1 (en) 2009-04-09
US7575177B2 (en) 2009-08-18

Similar Documents

Publication Publication Date Title
US7988060B2 (en) Dual use payment device
US11625771B2 (en) Systems and methods for transferring funds using a wireless device
US20200051073A1 (en) System and method for enhanced token-based payments
US20130097078A1 (en) Mobile remote payment system
US10528935B2 (en) Payment system and method
US9805369B2 (en) Private payment and purchasing system
RU2604671C2 (en) Calculation of cost of a purchase at point of sale using bar codes
US20150371212A1 (en) Integrated transaction and account system
US20150058145A1 (en) Universal check-out system for Mobile Payment Applications/Platforms
US10147112B2 (en) Delayed processing window in a prepaid architecture
US20110218907A1 (en) System and method for creating and managing a shared stored value account associated with a client device
CN107209890B (en) Flexible electronic payment transaction processing
CA2934342C (en) Systems and methods for generating offers from tokenized contactless payments
US20150235309A1 (en) Business services platform solutions for small and medium enterprises
KR20190088956A (en) Donation service system using QR code and a method thereof
KR20110035548A (en) Apparatus and method of credit card settlement using a mobile station in a electronic settlement system and system thereof
US10325251B2 (en) Apparatus, method, and computer program product for secure, privacy-aware qualified expenditure tracking in an ISO 8583 network or the like
US11127017B2 (en) Enablement of enhanced authorization decisions of purchases including stored value products
WO2013134425A1 (en) Distributing coupons and processing coupon reimbursement requests over mobile communication networks
KR20210101921A (en) Inter-Personal Payment System And Method
KR20130070509A (en) System and method for payment using portable terminal, and storage medium recording program for implementing method thereof
KR20190075422A (en) Donation service system using QR code and a method thereof
KR20180064903A (en) System for managing payment and method for payment

Legal Events

Date Code Title Description
AS Assignment

Owner name: MASTERCARD INTERNATIONAL, INC., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KILLIAN, PATRICK;MALHOTRA, SANDEEP;WONG, SHOON;REEL/FRAME:020556/0478;SIGNING DATES FROM 20071219 TO 20071222

Owner name: MASTERCARD INTERNATIONAL, INC., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CAMPBELL, ANDREW D.;LORBERG, DANA;REEL/FRAME:020556/0514;SIGNING DATES FROM 20080208 TO 20080212

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION