US20150149309A1 - Card reader emulation for cardless transactions - Google Patents

Card reader emulation for cardless transactions Download PDF

Info

Publication number
US20150149309A1
US20150149309A1 US14/187,049 US201414187049A US2015149309A1 US 20150149309 A1 US20150149309 A1 US 20150149309A1 US 201414187049 A US201414187049 A US 201414187049A US 2015149309 A1 US2015149309 A1 US 2015149309A1
Authority
US
United States
Prior art keywords
pos
consumer
payment
card reader
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.)
Granted
Application number
US14/187,049
Other versions
US9037491B1 (en
Inventor
Robert Lee
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.)
Block Inc
Original Assignee
Square 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 Square Inc filed Critical Square Inc
Priority to US14/187,049 priority Critical patent/US9037491B1/en
Assigned to SQUARE, INC. reassignment SQUARE, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LEE, ROBERT
Priority to EP14875157.1A priority patent/EP3077970A4/en
Priority to PCT/US2014/072285 priority patent/WO2015100385A1/en
Priority to CA2935177A priority patent/CA2935177C/en
Priority to JP2016561596A priority patent/JP6475752B2/en
Priority to AU2014369891A priority patent/AU2014369891B2/en
Priority to US14/667,496 priority patent/US9626669B2/en
Publication of US9037491B1 publication Critical patent/US9037491B1/en
Application granted granted Critical
Publication of US20150149309A1 publication Critical patent/US20150149309A1/en
Assigned to JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT reassignment JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT PATENT SECURITY AGREEMENT Assignors: SQUARE, INC.
Priority to US15/489,700 priority patent/US11107056B2/en
Assigned to SQUARE, INC. reassignment SQUARE, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT
Priority to US17/461,509 priority patent/US20220058611A1/en
Assigned to BLOCK, INC. reassignment BLOCK, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SQUARE, INC.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

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
    • 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/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/209Specified transaction journal output feature, e.g. printed receipt or voice output
    • 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]
    • 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/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • 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/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351Virtual cards
    • 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
    • G06Q20/00Payment architectures, schemes or protocols
    • 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
    • G06Q30/00Commerce
    • 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
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Definitions

  • the traditional manner of paying by credit card in a restaurant or other full-service retail establishment is inefficient and time-consuming. For example, when a customer in a restaurant wishes to pay by credit card, he typically does so by first getting the waiter's attention and then requesting a check. The customer then waits several minutes for the check. After the waiter brings the check, the customer waits several more minutes for the waiter to return and collect the customer's credit card, and then waits several more minutes for the waiter to return with a printed receipt. While the customer is waiting for the receipt, the waiter brings the credit card to a point-of-sale (POS) terminal, runs the card through a card reader, and waits for an authorization signal to come back and for a paper receipt to be printed.
  • POS point-of-sale
  • the customer When the customer receives the printed receipt from the waiter, the customer writes any tip (gratuity) that he wishes to add onto the receipt and then signs the receipt.
  • the waiter then collects the signed receipt (typically after the customer has left the establishment) and enters the total amount of the transaction (including tip) into the POS system.
  • This process is very time-consuming and inefficient, from the perspectives of the customer, who may be in a hurry to leave the restaurant, the waiter, who may be busy serving other customers, and the restaurant owner, who may require high efficiency from service employees in order to remain profitable.
  • FIG. 1 illustrates an environment in which the card emulation technique introduced here can be implemented.
  • FIGS. 2A and 2B illustrate different embodiments of a merchant POS system.
  • FIG. 3 illustrates an example of a card read emulator (CRE) module used in a POS system.
  • CRE card read emulator
  • FIG. 4 is a flow diagram illustrating an example of a process for setting up and initiating a cardless payment transaction, according to a first embodiment.
  • FIG. 5 illustrates an example of a graphical user interface (GUI) display generated by a merchant POS system.
  • GUI graphical user interface
  • FIG. 6A illustrates operations performed in a cardless payment transaction, according to the first embodiment.
  • FIG. 6B illustrates a process that can be performed by the card read emulator (CRE) module.
  • CRE card read emulator
  • FIG. 7 illustrates operations performed in a cardless payment transaction, according to the second embodiment.
  • FIG. 8 illustrates operations performed in connection with specifying a tip for a cardless payment transaction.
  • FIG. 9 is a high-level block diagram showing an example of a processing system in which at least some operations related to a cardless transaction can be implemented.
  • references in this description to “an embodiment”, “one embodiment”, or the like, mean that the particular feature, function, structure or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment. On the other hand, the embodiments referred to also are not necessarily mutually exclusive.
  • the technique eliminates the need for a customer to carry a physical payment card (e.g., a credit card or debit card) and eliminates the need to do a physical card swipe (or other similar physical card read event) when performing a payment card transaction.
  • the technique is particularly advantageous when applied to a full-service retail establishment, such as a restaurant; in particular, the technique facilitates a “pay-by-name” paradigm in which a customer can pay essentially by just telling the merchant his name.
  • the technique introduced here can cleanly integrate into essentially any conventional POS system, without the need for customized software or hardware to accommodate individual POS vendors' proprietary application programming interfaces (APIs).
  • APIs application programming interfaces
  • the technique introduced here is not limited in applicability to restaurants or to any other particular kind of business. Additionally, the technique introduced here is not limited to use with payment cards or even to financial transactions. The technique can be employed with essentially any transaction that traditionally would be initiated by or involve the use of a physical card reader.
  • the term “sale”, as in point-of-sale (POS), refers to any type of payment-oriented transaction, including a lease or rental for example, and is not limited to an actual purchase.
  • the term “user” generally refers to a customer (as opposed to a merchant), except where otherwise indicated, and except that the term “user interface” does not necessarily refer to an interface used by a customer, as will be apparent from the context.
  • the technique introduced here involves the following sequence of actions, as described more fully below.
  • a customer registers with a cardless payment service.
  • the customer visits a merchant and “checks in” to the merchant by using a mobile payment application on the customer's mobile device (e.g., a smartphone or tablet computer).
  • the check-in action triggers a sequence of messages and other actions that cause the customer's name and photo to appear relatively immediately on a display device of the merchant's POS terminal.
  • swipe here refers to any manner of triggering a physical card reader to read a physical card, such as passing a card through a magnetic stripe reader, smartcard reader, optical code reader, radio frequency identification (RFID) reader, etc.
  • RFID radio frequency identification
  • a card read emulator (CRE) module in the merchant POS system enables the cardless payment technique to cleanly integrate into essentially any conventional POS system. It does so by emulating physical card read events and intercepting receipt printer output at the merchant POS system. More specifically, and as described in detail below, the CRE module responds to the merchant's triggering input by sending a virtual card swipe to the main POS software in the POS system. The CRE module also intercepts the receipt printing once the transaction has been authorized. Instead of printing a physical receipt, the CRE module causes a virtual copy of the receipt to be sent to the customer's mobile device, where it is displayed to the customer by the mobile payment application. For print operations that are not associated with a cardless transaction, the CRE module simply allows those to pass unaffected to the printer.
  • CRE card read emulator
  • the customer may input a tip amount into the mobile payment application on his mobile device.
  • the CRE module then instructs the merchant to enter the tip into their POS terminal as if it were a “virtual merchant copy.”
  • Other ways of inputting the tip amount and variations upon the disclosed technique are also described below.
  • the CRE module may be integrated within the merchant POS terminal, or it may be a separate device. If it is integrated within the POS terminal, it may be an integral part of the main POS software application, or it may be a separate add-on software application or hardware device.
  • the CRE module emulates the output of a physical card reader used by the merchant, where no actual card read event occurs in relation to the payment transaction. It does so by invoking the POS system's (well published) card reader API associated with the particular card reader used by the merchant, and sending the data that emulates the output of the card reader to the main POS application in the output protocol used by the card reader.
  • the card reader can be, for example, a conventional magnetic stripe card reader, a smartcard (integrated circuit (IC) card) reader, barcode reader, quick response (QR) code reader, RFID card reader, or the like.
  • the CRE module prevents generation of a printed receipt by using the POS terminal's (well published) printer API to intercept a print signal generated by the main POS application (for print operations that are not associated with a cardless transaction, the CRE module simply allows those to pass unaffected to the printer).
  • the CRE module causes a message to be sent from the merchant POS system to a remote computer system of the cardless payment service, which responds by sending a message to the consumer's mobile device to cause the mobile payment application to display a virtual receipt for the transaction.
  • FIG. 1 illustrates an environment in which the cardless payment technique can be implemented.
  • the environment includes a merchant POS system of a merchant 100 and a mobile device 102 of a user 101 (also referred to as “customer” or “consumer”).
  • the mobile device 102 can be, for example, a smart phone, tablet computer, notebook computer, or any other form of mobile processing device.
  • a mobile payment application 120 runs on the user's mobile device 102 .
  • the environment also includes a computer system 114 of the merchant's acquirer, a computer system 118 of an issuing bank, a computer system 116 of a card payment network, and a computer system 108 of a payment service (hereinafter “payment service system 108 ”).
  • payment service system 108 a payment service
  • Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks. All of the aforementioned devices are coupled to each other through an internetwork 106 , which can be or include the Internet and one or more wireless networks (e.g., a WiFi network and or a cellular telecommunications network).
  • an internetwork 106 can be or include the Internet and one or more wireless networks (e.g., a WiFi network and or a cellular telecommunications network).
  • the environment illustrated in FIG. 1 can accommodate both traditional payment card transactions (i.e., those involving reading of physical card of the customer at the merchant's location), as well as cardless transactions according to the technique introduced here.
  • a traditional credit card transaction for example, the merchant swipes the user's credit card through a card reader at the POS system 104 .
  • the POS system 104 sends data read from the card (e.g., the cardholders name, credit card number, expiration date and card verification value (CVV)) to the computer system 114 of the merchant's acquirer (hereinafter “acquirer 114 ”).
  • data read from the card e.g., the cardholders name, credit card number, expiration date and card verification value (CVV)
  • CVV card verification value
  • the acquirer 114 sends this data to the computer system 116 of the card payment network (e.g., Visa or MasterCard) (hereinafter “card payment network 116 ”), which forwards the data to the computer system 118 of the issuing bank (hereinafter “issuer 118 ). If the transaction is approved by the issuer 118 , a payment authorization message is sent from the issuer 118 to the merchant POS system 104 via a path opposite of that described above.
  • card payment network 116 e.g., Visa or MasterCard
  • a cardless payment service operates the payment service system 108 to facilitate cardless payment transactions.
  • the user's mobile device 102 can communicate with the payment service system 108 over internetwork 106 .
  • the payment service system 108 includes one or more server computers programmed to process payment transactions involving users registered with the cardless payment service. It also stores information such as registered credit card numbers, debit card numbers, bank accounts, user accounts, user identifying information or other sensitive information.
  • the payment service system 108 is also responsible for sending information about merchants who have accounts with the cardless payment system to the user's mobile device 102 .
  • FIGS. 2A and 2B illustrate different embodiments of the merchant POS system 104 .
  • the merchant POS system 104 includes a main POS module 201 and a display 202 .
  • the main POS module 201 may be a software application, e.g., a main POS application 201 , as henceforth assumed herein to facilitate description. Alternatively, it could be a hardware component (which may include a POS application and/or other POS software).
  • the display 202 can be, for example, a touchscreen display, or a traditional non-touch display (in which case the merchant POS system 104 likely also includes a separate keyboard or other input device).
  • the merchant POS system 104 also includes a card reader 204 , such as a magnetic stripe card reader or a smartcard reader, and a receipt printer 205 for printing transaction receipts.
  • the POS system 104 also includes a CRE module 203 that communicates with the main POS application 201 .
  • the CRE module 203 may also communicate with the display 202 , either directly or through the main POS application 201 .
  • the CRE module 203 can be software, hardware, or a combination thereof. As illustrated in FIG. 2A , the CRE module 203 can be logically separate from the main POS module but operate “along side” it. Alternatively, the CRE module 203 can be an integral part of the main POS application 201 , as shown in FIG. 2B .
  • Other alternatives include binding virtual USB devices or implementing the CRE module 203 as a separate hardware device that connects between the merchant POS terminal and the card reader 204 and printer 205 .
  • the CRE module 203 has two main functions. Firstly, it emulates card read events to the main POS module, by using a protocol and API associated with the card reader. Secondly, it intercepts print signals generated by the main POS application 201 for the printer 205 , by using an API of the printer 205 , and triggers a sequence of operations to cause a virtual receipt to be sent to the user's mobile device 102 . These functions enable the customer to pay by credit or debit in a cardless transaction, without the need to customize software or hardware to accommodate individual POS vendor-proprietary APIs.
  • the CRE module 203 includes a card reader emulator 301 and a receipt manager 302 .
  • the card reader emulator 301 is responsible for emulating card read events to the main POS application 201 .
  • the receipt manager 302 is responsible for intercepting print signals generated by the main POS application 201 and triggering the sequence of operations to cause a virtual receipt to be sent to the user's mobile device 102 .
  • Dynamic-link library (DLL) injection can be used to intercept and modify communications between the main POS application 201 and the standard Windows USB APIs (e.g., used for a magnetic stripe card reader) and printer APIs.
  • DLL Dynamic-link library
  • POS systems might integrate with a card processing terminal instead of a magnetic stripe reader.
  • the CRE module 203 can simply emulate the card processing terminal.
  • the mobile payment application 120 is installed on the user's mobile device 102 (e.g., through an online application store) and the CRE module 203 is installed on the merchant POS system 104 . Additionally, the user is required to create a user account with the payment service system 108 . The user can do so from the mobile device 102 by using the mobile payment application 120 or a mobile web browser, or by using another processing device such as a home computer with a conventional web browser.
  • the user enters a name, account password, and contact information, e.g., email address.
  • the user also enters financial account information sufficient to conduct the transaction into the payment service system 108 .
  • financial account information sufficient to conduct the transaction into the payment service system 108 .
  • the user can enter the credit card issuer, credit card number and expiration date into the payment service system 108 ; the CVV and mailing address may also be required.
  • the financial account could also be associated with a debit card or pre-paid card, or another third party financial account.
  • the payment service requires that the user provide additional personal identifying information before a cardless transaction will be allowed, such as a photo of the user.
  • the photo of the user would later be provided to the merchant (e.g., via the CRE module 203 ) so that the merchant can compare the photo to the person at the merchant's location.
  • the payment service can require a personal identification number (PIN) be entered by the user.
  • PIN personal identification number
  • Other requirements can also be added to increase security.
  • the data associated with the user's account can be stored in a database (not shown) at the payment service system 108 .
  • the user carries the mobile device 102 with the mobile payment application 120 installed, and the merchant uses the POS system 104 as described above.
  • the mobile payment application 120 , CRE module 203 , payment service 108 and main POS application 201 interact to enable the user to pay by a cardless transaction. This is accomplished, in part, by determining a relative location between the user's mobile device 102 and the merchant.
  • the system includes the ability to determine the current location of the user's mobile device 102 with a relatively high degree of accuracy.
  • the mobile device 102 may have an internal geolocation device, such as a global positioning system (GPS) receiver.
  • GPS global positioning system
  • the location of the mobile device 102 may be determined by the wireless network, e.g. using radio frequency (RF) signal triangulation or other known technique.
  • RF radio frequency
  • the cardless payment service can predetermine a distance, e.g., a radius, from the location of a merchant, such as 500 feet, such that if the mobile device 102 is within that distance from a given merchant and the checks in to the merchant, the system can reliably assume that the user is in fact present at the merchant. If the user is located within the predetermined distance from a merchant, the user will be allowed to “check in” at the merchant by using the mobile payment application 120 . This may be done by, for example, the user pressing a simple “check in” button or the like on a display of the mobile device 102 .
  • the check-in function may be considered to be an indication of the user's consent to perform a cardless transaction with that particular merchant and effectively “opens a tab” with the merchant.
  • the mobile payment application 120 may be configured to automatically check in the user when the user is within the predetermined distance of the merchant. If, on the other hand, the mobile device 102 is located beyond the predetermined distance from a particular merchant, the user will not be allowed to check in at that merchant. In that case, the user device 102 will indicate to the user that it is too far from the merchant to check-in.
  • FIG. 4 illustrates an example of a process of setting up and initiating a cardless payment transaction, according to a first embodiment of the technique introduced here.
  • the process involves relationships between the user's mobile device 102 , the payment service system 108 , and the merchant POS system 104 .
  • the payment service system 108 can be configured to send and receive communications to and from the mobile device 102 and the merchant POS system 104 .
  • the communications can be encrypted using secure protocols built into the mobile device 102 , payment service system 108 , and merchant POS system 104 .
  • this process is implemented through the mobile payment application 120 installed on the mobile device 102 and the CRE module 203 on the merchant POS system 104 .
  • the user inputs a request into the mobile device 102 to identify a merchant that can perform cardless payment transactions.
  • the request may be sent automatically, for example, when the user opens the mobile payment application 120 on the mobile device 102 .
  • the mobile device 102 sends the request to the payment service system 108 via the internetwork 106 .
  • the request can be accompanied by location information of the mobile device 102 , e.g., as determined by the mobile device 102 .
  • the payment service system 108 receives the request and selects one or more merchants based on the location information from the customer and the stored location information for the merchant. An identification of the merchant and the location information for the merchant is sent to the mobile device 102 .
  • the user checks in at the merchant by interacting with the mobile payment application 120 running on the user's mobile device 102 (step 402 ).
  • an identification of the merchant and the location information for the merchant is sent to the mobile device 102 .
  • the mobile device 102 determines whether it is within the predetermined distance from the merchant (step 404 ). If the mobile device 102 does not know the current location of the merchant, or if the merchant recently updated its location information, the merchant location can be pushed or pulled into the mobile device 102 . Alternatively, if the user opts in to sharing of location information, the location information of the mobile device 102 can be provided to the payment service system 108 , which determines the 30 distance between the merchant and the mobile device 102 .
  • the mobile device 102 determines the user's mobile device 102 is not within the predetermined distance (e.g. 500 feet).
  • the mobile device 102 displays a message indicating its inability to check in the user (step 408 ). In that case, the merchant cannot charge the user's financial account by using a cardless payment transaction.
  • the mobile device 102 sends an indication of proximity to the payment service system 108 (step 406 ).
  • the payment service system 108 After the payment service system 108 receives this indication of proximity, it sends the indication of the mobile device 102 's presence and personal identifying information to the merchant POS system 104 (step 410 ).
  • the personal identifying information sent to the merchant POS system 104 includes the user's name, photo and financial account number (e.g., credit or debit card number).
  • the financial account number may be encrypted such that it can only be decrypted by the CRE module 203 , such that it cannot be displayed by the POS system or otherwise accessed by the merchant.
  • the merchant POS system 104 Upon receipt of this information, the merchant POS system 104 displays a tab (a list of items the customer has ordered) (step 412 ) and the user's identifying information (e.g., name and photo) (step 414 ) on a graphical user interface (GUI) on its display 202 .
  • GUI graphical user interface
  • FIG. 5 An example of such a GUI is shown in FIG. 5 .
  • the right-hand portion 501 of the display is a customer tab section that includes a separate subsection 502 for each customer who has checked in at the merchant via the cardless payment service.
  • the customer tab section 501 can be generated by the CRE module 203 , for example, or by other merchant-side POS software. The amount each customer owes can be displayed in the corresponding subsection 502 for that customer on the display.
  • the left-hand portion 503 of the GUI is generated by the main POS application 201 and contains, for example, names and images of the items that can be ordered/purchased and their prices.
  • the user information displayed by the CRE module 203 can be provided in a completely separate window from that of the main POS application 201 .
  • the merchant can select items that a customer has requested to purchase.
  • the GUI can be configured to associate individual prices with each of the merchant's items and can automatically sum the total transaction amount that the customer owes.
  • displaying of the customer tab section 502 may be triggered automatically when a customer who is registered with the cardless payment service checks in at the merchant. Alternatively, it may be triggered by a soft-button on the GUI generated by the main POS application 201 . Such a soft button may be generated by the CRE module 203 and may automatically change appearance when a user registered with the cardless payment service checks in at the merchant.
  • a hardware button or other similar physical control is provided on a separate hardware module (not shown) that connects externally to the merchant POS terminal (e.g., via a USB port or other conventional interface) and communicates with the CRE module 203 to trigger the display of the customer tab portion 502 .
  • the separate hardware module can emulate a USB keyboard and generate a key combination that causes the merchant POS system 104 to enter the desired state as mentioned above.
  • the hardware module can also contain a storage device (e.g., a USB flash drive) that contains the CRE module 203 . Activation of the button or other control on the separate hardware module can cause notifications to be displayed on the display of the POS system 104 and/or light up the button when a customer checks in at the merchant.
  • a customer can authorize payment for his tab by orally notifying the merchant. For example, a user named John Smith can simply tell the merchant, “Put this on John Smith.” Before or after the user authorizes payment for the tab, the merchant verifies the user's identity (step 416 ), for example by confirming that the photo displayed on the merchant POS system 104 matches the user who is present in person. Assuming the photo matches, the merchant then selects the user's tab (e.g., by tapping the corresponding section 501 on the GUI) to trigger a cardless payment transaction (step 418 ) when the customer is ready to pay.
  • the merchant verifies the user's identity (step 416 ), for example by confirming that the photo displayed on the merchant POS system 104 matches the user who is present in person. Assuming the photo matches, the merchant then selects the user's tab (e.g., by tapping the corresponding section 501 on the GUI) to trigger a cardless payment transaction (step 418 ) when the customer is ready to pay.
  • the cardless payment transaction involves the following operations, as illustrated in FIG. 6 .
  • the CRE module 203 emulates the card reader by sending, to the main POS application 201 , card read event data 602 associated with the consumer.
  • the card read event data 602 appears to the main POS application 201 to be data resulting from a card read event, although no actual card read event has occurred.
  • the CRE module 203 does this by invoking the main POS application's card reader API and sending the data in the output protocol of the card reader 204 .
  • FIG. 6 In an embodiment consistent with FIG.
  • the CRE module 203 previously received from the payment service system 108 a real payment card account number (e.g., credit card number) of the customer when the customer checked in at the merchant. Accordingly, that account number as well as the consumer's name, card expiration date and CVV are provided by the CRE module 203 to the main POS application 201 in the protocol of the card reader 204 . In another embodiment, which is discussed further below, the CRE module 203 or the payment service system 108 generates a one-time-use payment card number for the transaction, and passes that to the main POS application 201 instead of a real payment card number of the consumer.
  • a real payment card account number e.g., credit card number
  • the CRE module 203 is programmed with DUKPT (Derived Unique Key Per Transaction) keys for the merchant's acquirer, for the purpose of emulating a card swipe.
  • DUKPT Dynamic Unique Key Per Transaction
  • Other data related to the customer may also be provided, if required by the API of the card reader 204 .
  • the main POS application 201 upon receiving the card read event data 602 from the CRE module 203 , sends the card read event data in a standard payment authorization request 603 that is forwarded to the issuer 118 .
  • the payment authorization request 603 may actually be sent first to the merchant's acquirer 114 , which forwards the request or sends a corresponding new request to the card payment network 116 , which then forwards the request or sends a corresponding new request to the issuer 118 ; however, these intermediate communications are omitted from FIG. 6 to simplify explanation.
  • the issuer 118 sends a standard payment authorization (approval) message 604 back to the merchant's main POS application 201 , using a communication path opposite of that mentioned above.
  • the main POS application 201 responds to the payment authorization message by generating a print message 605 for the local receipt printer 205 of the merchant POS system 104 .
  • the CRE module 203 by having access to the main POS application 201 's printer API, intercepts the print signal before it can reach the printer 205 .
  • the CRE module 203 also sends a message 606 to the payment service system 108 (via the internetwork 106 ) indicating that a payment authorization message has been received.
  • the payment service system 108 responds by sending a message 607 containing a virtual receipt for the transaction to the user's mobile device 102 .
  • the mobile payment application 120 on the mobile device 102 then displays the virtual receipt to the user.
  • the virtual receipt can include all of the information that a printed card transaction receipt would include, including the amount charged, name of the consumer, date and time of the transaction, etc.
  • the user can then optionally input a tip amount. Different ways of handling tips in this process are discussed further below.
  • the payment service system 108 parses the receipt data before sending the virtual receipt to the mobile payment application 120 , to determine whether the transaction processed successfully or not. It can also parse the receipt data to identify various semantic elements, including the total amount of the transaction and items ordered by the customer. Consequently, in such embodiments the virtual receipt that the payment service system 108 sends to the mobile device 102 also contains an itemization of these elements, which can be displayed to the user. Alternatively, the parsing can be performed by the CRE module 203 .
  • POS systems use relational databases, such as Sybase or Microsoft's SQL Server, to store their payment card transaction data.
  • the payment service system 108 can capture most if not all essential transaction data by parsing receipts as described above. Nonetheless, it might be desirable to synchronize a merchant's POS database with a database of the payment service system 108 . Among other benefits, that would allow the payment service 108 to provide backup storage for merchants.
  • FIG. 6B illustrates an example of a process that can be performed by the CRE module 203 in the embodiment described above.
  • the process begins when the CRE module 203 detects a user input specifying a checked-in customer and being indicative of an intent to initiate a payment transaction involving the customer (step 622 ).
  • the CRE module 203 initiates the payment transaction by outputting, to the main POS application 201 , data that emulates output of the card reader 204 , without an actual card read event having occurred in relation to the payment transaction (step 624 ).
  • the CRE module 203 After the transaction has been approved by a payment processing entity (e.g., the issuer 118 ), when the CRE module 203 detects a print signal generated by the main POS module 201 for generating a transaction receipt (step 626 ), the CRE module 203 prevents generation of a printed receipt by intercepting the print signal (step 628 ).
  • the print signal includes receipt data for enabling a receipt to be printed by the receipt printer 205 .
  • the CRE module 203 sends a first message to the payment service system 108 (step 630 ), including at least some of the receipt data, to cause the payment service system 108 to send a second message to the customer's mobile device 102 .
  • the second message enables the mobile device 102 to output a virtual receipt for the payment transaction to the consumer.
  • the CRE module 203 receives from the payment service system 108 an actual payment card number of the user, and passes that number to the main POS application 201 when a transaction is initiated.
  • the cardless payment service generates a one-time-use payment card number for the transaction, and passes that to the main POS application 201 instead of a real payment card number of the consumer, as noted above.
  • the one-time-use card number can be generated by the payment service system 108 or by the CRE module 203 in response to the user checking in at the merchant.
  • the payment service which operates the payment service system 108 essentially acts as the credit card issuer from the perspective of the merchant.
  • the merchant POS system 104 charges the one-time-use credit card number, and the payment service later charges the consumer's actual credit card number which is stored in the payment service system 108 .
  • the initial set-up process in this embodiment can be substantially identical to that of FIG. 4 , except that in step 410 , the payment service system 108 sends the one-time-use payment account number to the merchant POS system 104 instead of sending the consumer's actual credit card number.
  • the one-time-use account number has a format recognizable by the merchant POS system 104 , e.g., a standard credit or debit card format.
  • a cardless transaction using the one-time use payment account number can involve the following operations, as illustrated in FIG. 7 .
  • the CRE module 203 emulates the card reader 204 by sending, to the main POS application 201 , data 702 associated with the consumer that appears to the main POS application 201 to be associated with a card read event, although no actual card read event has occurred. This can be done in the manner described above.
  • the one-time-use payment account number as well as the consumer's name, account expiration date and CVV are provided by the CRE module 203 to the main POS application 201 in the protocol of the card reader. Other data related to the may also be provided if required by the API of the card reader.
  • the main POS application 201 upon receiving the card read event data 702 from the CRE module 203 , sends the card read event data in a standard payment authorization request 703 that, in this embodiment, is forwarded to the payment service system 108 , which represents the issuer.
  • the payment authorization request 703 may actually be sent first to the merchant's acquirer 114 , which forwards the request or sends a corresponding new request to the card payment network 116 , which then forwards the request or generates a corresponding new request to the payment service system 108 ; however, these intermediate communications are omitted from FIG. 7 to simplify explanation.
  • the payment service system 108 sends a standard payment authorization (approval) message 704 back to the merchant's main POS application 201 , using a communication path opposite of that mentioned above.
  • the main POS application 201 responds to the payment authorization message 704 by generating a print signal 705 for the local receipt printer 205 of the merchant POS system 104 .
  • the CRE module 203 intercepts the print signal 705 and prevents it from reaching the printer 205 , as described above.
  • the payment service system 108 does not need to receive a signal from the CRE module 203 before sending send the virtual receipt, since it already knows the transaction is approved.
  • the payment service system 108 sends the payment authorization signal 704 , or shortly thereafter, it also sends a message 706 containing a virtual receipt for the transaction to the mobile device 102 of the customer.
  • the mobile payment application 120 on the customer's mobile device 102 then displays the virtual receipt to the user.
  • the payment system 108 sends a payment request 707 to the issuer 118 of an actual payment card of the customer.
  • the information of that actual payment card was previously received and stored by the payment service system 108 when the customer registered for the cardless payment service.
  • the payment service system 108 subsequently receives payment 708 from the issuer 118 .
  • the technique introduced here also enables a customer to tip the merchant (e.g., a waiter).
  • a customer e.g., a waiter.
  • the customer is prompted ( 801 ) by the mobile payment application 120 running on the mobile device 102 to input a tip amount.
  • the customer inputs ( 802 ) a tip amount into the mobile payment application 120 .
  • the mobile payment application 120 then sends a message 803 to the payment service system 108 including the tip amount.
  • the payment service system 108 than sends a message 804 to the CRE module 203 in the merchant POS system 104 indicating the tip amount.
  • the CRE module 203 then triggers the display of the merchant POS system 104 to display the tip amount on the display of the merchant POS system ( 805 ).
  • the merchant 100 sees the displayed tip amount and then inputs ( 806 ) the total transaction amount (e.g., amount charged plus tip) into the main POS application 201 in the traditional manner.
  • the main POS application 201 then processes the transaction according to the traditional transaction capture process ( 807 ).
  • the CRE module 203 simulates a sequence of user inputs (e.g., a sequence of touchscreen or keypad presses) to the main POS application 201 , to cause the main POS application 201 to enter an appropriate state for inputting the tip amount (or total transaction amount), and then simulates the proper user input sequence to input that amount into the main POS application 201 .
  • a sequence of user inputs e.g., a sequence of touchscreen or keypad presses
  • the CRE module 203 can invoke an API of an input device of the POS system (e.g., a touchscreen or keyboard/keypad) to communicate the tip amount to the main POS application 201 , such that the tip amount appears to the main POS application 201 to have been input by a human user.
  • an input device of the POS system e.g., a touchscreen or keyboard/keypad
  • the waiter pre-registers with the payment service system 108 as a merchant (or merchant employee, as the case may be) and identifies himself to the CRE module 203 via the GUI when he arrives at work each day.
  • the CRE module 203 causes the display to output a prompt asking which waiter should receive the tip.
  • the waiter taps his own name on the display.
  • the CRE module 203 then sends a message indicating this selection to the payment service system 108 .
  • the payment service system 108 then pushes the tip directly to the waiter, via automated clearing house (ACH) or debit, for example.
  • ACH automated clearing house
  • FIG. 9 is a high-level block diagram showing an example of a processing device 900 that can represent any of the devices described above, such as the mobile device 102 , the merchant POS system 104 , payment service system 108 , acquirer system 114 , card payment network 116 , or issuer system 118 . As noted above, any of these systems may include two or more processing devices such as represented in FIG. 9 , which may be coupled to each other via a network or multiple networks.
  • the processing system 900 includes one or more processors 910 , memory 911 , a communication device 912 , and one or more input/output (I/O) devices 913 , all coupled to each other through an interconnect 914 .
  • the interconnect 914 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices.
  • the processor(s) 910 may be or include, for example, one or more general-purpose programmable microprocessors, microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices.
  • the processor(s) 910 control the overall operation of the processing device 900 .
  • Memory 911 may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. Memory 911 may store data and instructions that configure the processor(s) 910 to execute operations in accordance with the techniques described above.
  • the communication device 912 may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth transceiver, or the like, or a combination thereof.
  • the I/O devices 913 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc.
  • ASICs application-specific integrated circuits
  • PLDs programmable logic devices
  • FPGAs field-programmable gate arrays
  • Machine-readable medium includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.).
  • a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.

Abstract

Disclosed are method and apparatus that enable a cardless payment transaction to be executed from a merchant point-of-sale (POS) system. A user is enabled to check in at a merchant by using a mobile device of the user and then to pay by simply appearing at the merchant and mentioning his name. By emulating card read events and intercepting receipt printer outputs, the technique cleanly integrates into a conventional merchant POS system, without the need for customized software or hardware to accommodate individual POS vendor-proprietary application programming interfaces (APIs).

Description

  • This application claims the benefit of U.S. provisional patent application No. 61/909,282, filed on Nov. 26, 2013, and U.S. provisional patent application No. 61/921,374, filed on Dec. 27, 2013, both of which are incorporated herein by reference in their entirety.
  • BACKGROUND
  • The traditional manner of paying by credit card in a restaurant or other full-service retail establishment is inefficient and time-consuming. For example, when a customer in a restaurant wishes to pay by credit card, he typically does so by first getting the waiter's attention and then requesting a check. The customer then waits several minutes for the check. After the waiter brings the check, the customer waits several more minutes for the waiter to return and collect the customer's credit card, and then waits several more minutes for the waiter to return with a printed receipt. While the customer is waiting for the receipt, the waiter brings the credit card to a point-of-sale (POS) terminal, runs the card through a card reader, and waits for an authorization signal to come back and for a paper receipt to be printed. When the customer receives the printed receipt from the waiter, the customer writes any tip (gratuity) that he wishes to add onto the receipt and then signs the receipt. The waiter then collects the signed receipt (typically after the customer has left the establishment) and enters the total amount of the transaction (including tip) into the POS system.
  • This process is very time-consuming and inefficient, from the perspectives of the customer, who may be in a hurry to leave the restaurant, the waiter, who may be busy serving other customers, and the restaurant owner, who may require high efficiency from service employees in order to remain profitable.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.
  • FIG. 1 illustrates an environment in which the card emulation technique introduced here can be implemented.
  • FIGS. 2A and 2B illustrate different embodiments of a merchant POS system.
  • FIG. 3 illustrates an example of a card read emulator (CRE) module used in a POS system.
  • FIG. 4 is a flow diagram illustrating an example of a process for setting up and initiating a cardless payment transaction, according to a first embodiment.
  • FIG. 5 illustrates an example of a graphical user interface (GUI) display generated by a merchant POS system.
  • FIG. 6A illustrates operations performed in a cardless payment transaction, according to the first embodiment.
  • FIG. 6B illustrates a process that can be performed by the card read emulator (CRE) module.
  • FIG. 7 illustrates operations performed in a cardless payment transaction, according to the second embodiment.
  • FIG. 8 illustrates operations performed in connection with specifying a tip for a cardless payment transaction.
  • FIG. 9 is a high-level block diagram showing an example of a processing system in which at least some operations related to a cardless transaction can be implemented.
  • DETAILED DESCRIPTION
  • References in this description to “an embodiment”, “one embodiment”, or the like, mean that the particular feature, function, structure or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment. On the other hand, the embodiments referred to also are not necessarily mutually exclusive.
  • Introduced here is a technique that enables more efficient payment by use of a payment account, such as a credit card or debit card account. The technique eliminates the need for a customer to carry a physical payment card (e.g., a credit card or debit card) and eliminates the need to do a physical card swipe (or other similar physical card read event) when performing a payment card transaction. The technique is particularly advantageous when applied to a full-service retail establishment, such as a restaurant; in particular, the technique facilitates a “pay-by-name” paradigm in which a customer can pay essentially by just telling the merchant his name. Additionally, by emulating card read events and intercepting receipt printer outputs, as described further below, the technique introduced here can cleanly integrate into essentially any conventional POS system, without the need for customized software or hardware to accommodate individual POS vendors' proprietary application programming interfaces (APIs).
  • In the following description, the example of a restaurant is used, for illustrative purposes only, to explain various aspects of the technique. Note, however, that the technique introduced here is not limited in applicability to restaurants or to any other particular kind of business. Additionally, the technique introduced here is not limited to use with payment cards or even to financial transactions. The technique can be employed with essentially any transaction that traditionally would be initiated by or involve the use of a physical card reader. Hence, the term “sale”, as in point-of-sale (POS), refers to any type of payment-oriented transaction, including a lease or rental for example, and is not limited to an actual purchase. Note also that in this description, the term “user” generally refers to a customer (as opposed to a merchant), except where otherwise indicated, and except that the term “user interface” does not necessarily refer to an interface used by a customer, as will be apparent from the context.
  • In certain embodiments, the technique introduced here involves the following sequence of actions, as described more fully below. Initially, a customer registers with a cardless payment service. At some later time, the customer visits a merchant and “checks in” to the merchant by using a mobile payment application on the customer's mobile device (e.g., a smartphone or tablet computer). The check-in action triggers a sequence of messages and other actions that cause the customer's name and photo to appear relatively immediately on a display device of the merchant's POS terminal.
  • When the customer is ready to pay, he simply tells the merchant that he wants to pay with the payment service (preferably mentioning the service by its advertised trade name). The merchant then closes the ticket, or “tab”, in the merchant POS system in the traditional way. However, when it is time to swipe a credit card through the merchant's card reader, the waiter instead simply taps the customer's name or photo displayed on the merchant POS terminal. The term “swipe” here refers to any manner of triggering a physical card reader to read a physical card, such as passing a card through a magnetic stripe reader, smartcard reader, optical code reader, radio frequency identification (RFID) reader, etc.
  • A card read emulator (CRE) module in the merchant POS system enables the cardless payment technique to cleanly integrate into essentially any conventional POS system. It does so by emulating physical card read events and intercepting receipt printer output at the merchant POS system. More specifically, and as described in detail below, the CRE module responds to the merchant's triggering input by sending a virtual card swipe to the main POS software in the POS system. The CRE module also intercepts the receipt printing once the transaction has been authorized. Instead of printing a physical receipt, the CRE module causes a virtual copy of the receipt to be sent to the customer's mobile device, where it is displayed to the customer by the mobile payment application. For print operations that are not associated with a cardless transaction, the CRE module simply allows those to pass unaffected to the printer.
  • After some time, the customer may input a tip amount into the mobile payment application on his mobile device. The CRE module then instructs the merchant to enter the tip into their POS terminal as if it were a “virtual merchant copy.” Other ways of inputting the tip amount and variations upon the disclosed technique are also described below.
  • As described further below, the CRE module may be integrated within the merchant POS terminal, or it may be a separate device. If it is integrated within the POS terminal, it may be an integral part of the main POS software application, or it may be a separate add-on software application or hardware device. The CRE module emulates the output of a physical card reader used by the merchant, where no actual card read event occurs in relation to the payment transaction. It does so by invoking the POS system's (well published) card reader API associated with the particular card reader used by the merchant, and sending the data that emulates the output of the card reader to the main POS application in the output protocol used by the card reader. The card reader can be, for example, a conventional magnetic stripe card reader, a smartcard (integrated circuit (IC) card) reader, barcode reader, quick response (QR) code reader, RFID card reader, or the like.
  • After the transaction has been approved by a remote payment processing entity, the CRE module prevents generation of a printed receipt by using the POS terminal's (well published) printer API to intercept a print signal generated by the main POS application (for print operations that are not associated with a cardless transaction, the CRE module simply allows those to pass unaffected to the printer). In response to the print signal, the CRE module causes a message to be sent from the merchant POS system to a remote computer system of the cardless payment service, which responds by sending a message to the consumer's mobile device to cause the mobile payment application to display a virtual receipt for the transaction.
  • FIG. 1 illustrates an environment in which the cardless payment technique can be implemented. The environment includes a merchant POS system of a merchant 100 and a mobile device 102 of a user 101 (also referred to as “customer” or “consumer”). The mobile device 102 can be, for example, a smart phone, tablet computer, notebook computer, or any other form of mobile processing device. A mobile payment application 120 runs on the user's mobile device 102. The environment also includes a computer system 114 of the merchant's acquirer, a computer system 118 of an issuing bank, a computer system 116 of a card payment network, and a computer system 108 of a payment service (hereinafter “payment service system 108”). Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks. All of the aforementioned devices are coupled to each other through an internetwork 106, which can be or include the Internet and one or more wireless networks (e.g., a WiFi network and or a cellular telecommunications network).
  • The environment illustrated in FIG. 1 can accommodate both traditional payment card transactions (i.e., those involving reading of physical card of the customer at the merchant's location), as well as cardless transactions according to the technique introduced here. In a traditional credit card transaction, for example, the merchant swipes the user's credit card through a card reader at the POS system 104. The POS system 104 sends data read from the card (e.g., the cardholders name, credit card number, expiration date and card verification value (CVV)) to the computer system 114 of the merchant's acquirer (hereinafter “acquirer 114”). The acquirer 114 sends this data to the computer system 116 of the card payment network (e.g., Visa or MasterCard) (hereinafter “card payment network 116”), which forwards the data to the computer system 118 of the issuing bank (hereinafter “issuer 118). If the transaction is approved by the issuer 118, a payment authorization message is sent from the issuer 118 to the merchant POS system 104 via a path opposite of that described above.
  • A cardless payment service operates the payment service system 108 to facilitate cardless payment transactions. The user's mobile device 102 can communicate with the payment service system 108 over internetwork 106. The payment service system 108 includes one or more server computers programmed to process payment transactions involving users registered with the cardless payment service. It also stores information such as registered credit card numbers, debit card numbers, bank accounts, user accounts, user identifying information or other sensitive information. The payment service system 108 is also responsible for sending information about merchants who have accounts with the cardless payment system to the user's mobile device 102.
  • FIGS. 2A and 2B illustrate different embodiments of the merchant POS system 104. Note that certain components that are not germane to this description may not be shown. Referring first to FIG. 2A, the merchant POS system 104 includes a main POS module 201 and a display 202. The main POS module 201 may be a software application, e.g., a main POS application 201, as henceforth assumed herein to facilitate description. Alternatively, it could be a hardware component (which may include a POS application and/or other POS software). The display 202 can be, for example, a touchscreen display, or a traditional non-touch display (in which case the merchant POS system 104 likely also includes a separate keyboard or other input device). The merchant POS system 104 also includes a card reader 204, such as a magnetic stripe card reader or a smartcard reader, and a receipt printer 205 for printing transaction receipts.
  • In accordance with the technique introduced here, the POS system 104 also includes a CRE module 203 that communicates with the main POS application 201. The CRE module 203 may also communicate with the display 202, either directly or through the main POS application 201. The CRE module 203 can be software, hardware, or a combination thereof. As illustrated in FIG. 2A, the CRE module 203 can be logically separate from the main POS module but operate “along side” it. Alternatively, the CRE module 203 can be an integral part of the main POS application 201, as shown in FIG. 2B. Other alternatives include binding virtual USB devices or implementing the CRE module 203 as a separate hardware device that connects between the merchant POS terminal and the card reader 204 and printer 205.
  • The CRE module 203 has two main functions. Firstly, it emulates card read events to the main POS module, by using a protocol and API associated with the card reader. Secondly, it intercepts print signals generated by the main POS application 201 for the printer 205, by using an API of the printer 205, and triggers a sequence of operations to cause a virtual receipt to be sent to the user's mobile device 102. These functions enable the customer to pay by credit or debit in a cardless transaction, without the need to customize software or hardware to accommodate individual POS vendor-proprietary APIs.
  • Accordingly, as shown in FIG. 3, in certain embodiments the CRE module 203 includes a card reader emulator 301 and a receipt manager 302. The card reader emulator 301 is responsible for emulating card read events to the main POS application 201. The receipt manager 302 is responsible for intercepting print signals generated by the main POS application 201 and triggering the sequence of operations to cause a virtual receipt to be sent to the user's mobile device 102. Dynamic-link library (DLL) injection can be used to intercept and modify communications between the main POS application 201 and the standard Windows USB APIs (e.g., used for a magnetic stripe card reader) and printer APIs.
  • Note that certain POS systems might integrate with a card processing terminal instead of a magnetic stripe reader. In those cases, the CRE module 203 can simply emulate the card processing terminal.
  • Before a cardless transaction between the user and the merchant can be performed, the mobile payment application 120 is installed on the user's mobile device 102 (e.g., through an online application store) and the CRE module 203 is installed on the merchant POS system 104. Additionally, the user is required to create a user account with the payment service system 108. The user can do so from the mobile device 102 by using the mobile payment application 120 or a mobile web browser, or by using another processing device such as a home computer with a conventional web browser.
  • In certain embodiments, the user enters a name, account password, and contact information, e.g., email address. Before a cardless payment transaction can be performed, the user also enters financial account information sufficient to conduct the transaction into the payment service system 108. For example, in the case of a credit card account, the user can enter the credit card issuer, credit card number and expiration date into the payment service system 108; the CVV and mailing address may also be required. However, the financial account could also be associated with a debit card or pre-paid card, or another third party financial account.
  • In some embodiments, the payment service requires that the user provide additional personal identifying information before a cardless transaction will be allowed, such as a photo of the user. The photo of the user would later be provided to the merchant (e.g., via the CRE module 203) so that the merchant can compare the photo to the person at the merchant's location. In addition, the payment service can require a personal identification number (PIN) be entered by the user. Other requirements can also be added to increase security. The data associated with the user's account can be stored in a database (not shown) at the payment service system 108.
  • In operation, the user carries the mobile device 102 with the mobile payment application 120 installed, and the merchant uses the POS system 104 as described above. The mobile payment application 120, CRE module 203, payment service 108 and main POS application 201 interact to enable the user to pay by a cardless transaction. This is accomplished, in part, by determining a relative location between the user's mobile device 102 and the merchant. The system includes the ability to determine the current location of the user's mobile device 102 with a relatively high degree of accuracy. For example, the mobile device 102 may have an internal geolocation device, such as a global positioning system (GPS) receiver. Alternatively, the location of the mobile device 102 may be determined by the wireless network, e.g. using radio frequency (RF) signal triangulation or other known technique. The location of the merchant is assumed to be well known and pre-stored within the payment service system 108.
  • The cardless payment service can predetermine a distance, e.g., a radius, from the location of a merchant, such as 500 feet, such that if the mobile device 102 is within that distance from a given merchant and the checks in to the merchant, the system can reliably assume that the user is in fact present at the merchant. If the user is located within the predetermined distance from a merchant, the user will be allowed to “check in” at the merchant by using the mobile payment application 120. This may be done by, for example, the user pressing a simple “check in” button or the like on a display of the mobile device 102. The check-in function may be considered to be an indication of the user's consent to perform a cardless transaction with that particular merchant and effectively “opens a tab” with the merchant. Alternatively, the mobile payment application 120 may be configured to automatically check in the user when the user is within the predetermined distance of the merchant. If, on the other hand, the mobile device 102 is located beyond the predetermined distance from a particular merchant, the user will not be allowed to check in at that merchant. In that case, the user device 102 will indicate to the user that it is too far from the merchant to check-in.
  • FIG. 4 illustrates an example of a process of setting up and initiating a cardless payment transaction, according to a first embodiment of the technique introduced here. The process involves relationships between the user's mobile device 102, the payment service system 108, and the merchant POS system 104. The payment service system 108 can be configured to send and receive communications to and from the mobile device 102 and the merchant POS system 104. The communications can be encrypted using secure protocols built into the mobile device 102, payment service system 108, and merchant POS system 104. In some embodiments, this process is implemented through the mobile payment application 120 installed on the mobile device 102 and the CRE module 203 on the merchant POS system 104.
  • Initially, the user inputs a request into the mobile device 102 to identify a merchant that can perform cardless payment transactions. The request may be sent automatically, for example, when the user opens the mobile payment application 120 on the mobile device 102. The mobile device 102 sends the request to the payment service system 108 via the internetwork 106. The request can be accompanied by location information of the mobile device 102, e.g., as determined by the mobile device 102. The payment service system 108 receives the request and selects one or more merchants based on the location information from the customer and the stored location information for the merchant. An identification of the merchant and the location information for the merchant is sent to the mobile device 102.
  • In some embodiments, the user checks in at the merchant by interacting with the mobile payment application 120 running on the user's mobile device 102 (step 402). When the user checks in, an identification of the merchant and the location information for the merchant is sent to the mobile device 102. The mobile device 102 determines whether it is within the predetermined distance from the merchant (step 404). If the mobile device 102 does not know the current location of the merchant, or if the merchant recently updated its location information, the merchant location can be pushed or pulled into the mobile device 102. Alternatively, if the user opts in to sharing of location information, the location information of the mobile device 102 can be provided to the payment service system 108, which determines the 30 distance between the merchant and the mobile device 102.
  • As described above, if the mobile device 102 determines the user's mobile device 102 is not within the predetermined distance (e.g. 500 feet), the mobile device 102 displays a message indicating its inability to check in the user (step 408). In that case, the merchant cannot charge the user's financial account by using a cardless payment transaction. On the other hand, if the mobile device 102 is within the predetermined distance, the mobile device 102 sends an indication of proximity to the payment service system 108 (step 406).
  • After the payment service system 108 receives this indication of proximity, it sends the indication of the mobile device 102's presence and personal identifying information to the merchant POS system 104 (step 410). In some embodiments, the personal identifying information sent to the merchant POS system 104 includes the user's name, photo and financial account number (e.g., credit or debit card number). The financial account number may be encrypted such that it can only be decrypted by the CRE module 203, such that it cannot be displayed by the POS system or otherwise accessed by the merchant.
  • Upon receipt of this information, the merchant POS system 104 displays a tab (a list of items the customer has ordered) (step 412) and the user's identifying information (e.g., name and photo) (step 414) on a graphical user interface (GUI) on its display 202. An example of such a GUI is shown in FIG. 5. In the illustrated example, the right-hand portion 501 of the display is a customer tab section that includes a separate subsection 502 for each customer who has checked in at the merchant via the cardless payment service. The customer tab section 501 can be generated by the CRE module 203, for example, or by other merchant-side POS software. The amount each customer owes can be displayed in the corresponding subsection 502 for that customer on the display.
  • The left-hand portion 503 of the GUI is generated by the main POS application 201 and contains, for example, names and images of the items that can be ordered/purchased and their prices. In other embodiments, the user information displayed by the CRE module 203 can be provided in a completely separate window from that of the main POS application 201. Hence, in some embodiments, through the GUI the merchant can select items that a customer has requested to purchase. The GUI can be configured to associate individual prices with each of the merchant's items and can automatically sum the total transaction amount that the customer owes.
  • In some embodiments, displaying of the customer tab section 502 may be triggered automatically when a customer who is registered with the cardless payment service checks in at the merchant. Alternatively, it may be triggered by a soft-button on the GUI generated by the main POS application 201. Such a soft button may be generated by the CRE module 203 and may automatically change appearance when a user registered with the cardless payment service checks in at the merchant.
  • In yet another embodiment, a hardware button or other similar physical control is provided on a separate hardware module (not shown) that connects externally to the merchant POS terminal (e.g., via a USB port or other conventional interface) and communicates with the CRE module 203 to trigger the display of the customer tab portion 502. The separate hardware module can emulate a USB keyboard and generate a key combination that causes the merchant POS system 104 to enter the desired state as mentioned above. In an extension of this approach, the hardware module can also contain a storage device (e.g., a USB flash drive) that contains the CRE module 203. Activation of the button or other control on the separate hardware module can cause notifications to be displayed on the display of the POS system 104 and/or light up the button when a customer checks in at the merchant.
  • A customer (user) can authorize payment for his tab by orally notifying the merchant. For example, a user named John Smith can simply tell the merchant, “Put this on John Smith.” Before or after the user authorizes payment for the tab, the merchant verifies the user's identity (step 416), for example by confirming that the photo displayed on the merchant POS system 104 matches the user who is present in person. Assuming the photo matches, the merchant then selects the user's tab (e.g., by tapping the corresponding section 501 on the GUI) to trigger a cardless payment transaction (step 418) when the customer is ready to pay.
  • In one embodiment, the cardless payment transaction involves the following operations, as illustrated in FIG. 6. In response to the merchant providing a user input 601 to trigger the cardless payment transaction, the CRE module 203 emulates the card reader by sending, to the main POS application 201, card read event data 602 associated with the consumer. The card read event data 602 appears to the main POS application 201 to be data resulting from a card read event, although no actual card read event has occurred. The CRE module 203 does this by invoking the main POS application's card reader API and sending the data in the output protocol of the card reader 204. In an embodiment consistent with FIG. 4, the CRE module 203 previously received from the payment service system 108 a real payment card account number (e.g., credit card number) of the customer when the customer checked in at the merchant. Accordingly, that account number as well as the consumer's name, card expiration date and CVV are provided by the CRE module 203 to the main POS application 201 in the protocol of the card reader 204. In another embodiment, which is discussed further below, the CRE module 203 or the payment service system 108 generates a one-time-use payment card number for the transaction, and passes that to the main POS application 201 instead of a real payment card number of the consumer. It is not necessary for the CRE module 203 to implement the entire protocol of the card reader, since it only needs to be able to inject simulated card swipes to the main POS application 201. In one embodiment, the CRE module 203 is programmed with DUKPT (Derived Unique Key Per Transaction) keys for the merchant's acquirer, for the purpose of emulating a card swipe. Other data related to the customer may also be provided, if required by the API of the card reader 204.
  • The main POS application 201, upon receiving the card read event data 602 from the CRE module 203, sends the card read event data in a standard payment authorization request 603 that is forwarded to the issuer 118. In practice, the payment authorization request 603 may actually be sent first to the merchant's acquirer 114, which forwards the request or sends a corresponding new request to the card payment network 116, which then forwards the request or sends a corresponding new request to the issuer 118; however, these intermediate communications are omitted from FIG. 6 to simplify explanation.
  • If the transaction is approved by the issuer 118, the issuer 118 sends a standard payment authorization (approval) message 604 back to the merchant's main POS application 201, using a communication path opposite of that mentioned above. The main POS application 201 responds to the payment authorization message by generating a print message 605 for the local receipt printer 205 of the merchant POS system 104. However, the CRE module 203, by having access to the main POS application 201's printer API, intercepts the print signal before it can reach the printer 205. In response to detecting the print signal, the CRE module 203 also sends a message 606 to the payment service system 108 (via the internetwork 106) indicating that a payment authorization message has been received. The payment service system 108 responds by sending a message 607 containing a virtual receipt for the transaction to the user's mobile device 102. The mobile payment application 120 on the mobile device 102 then displays the virtual receipt to the user. The virtual receipt can include all of the information that a printed card transaction receipt would include, including the amount charged, name of the consumer, date and time of the transaction, etc. The user can then optionally input a tip amount. Different ways of handling tips in this process are discussed further below.
  • In certain embodiments, the payment service system 108 parses the receipt data before sending the virtual receipt to the mobile payment application 120, to determine whether the transaction processed successfully or not. It can also parse the receipt data to identify various semantic elements, including the total amount of the transaction and items ordered by the customer. Consequently, in such embodiments the virtual receipt that the payment service system 108 sends to the mobile device 102 also contains an itemization of these elements, which can be displayed to the user. Alternatively, the parsing can be performed by the CRE module 203.
  • Note that most POS systems use relational databases, such as Sybase or Microsoft's SQL Server, to store their payment card transaction data. The payment service system 108 can capture most if not all essential transaction data by parsing receipts as described above. Nonetheless, it might be desirable to synchronize a merchant's POS database with a database of the payment service system 108. Among other benefits, that would allow the payment service 108 to provide backup storage for merchants.
  • FIG. 6B illustrates an example of a process that can be performed by the CRE module 203 in the embodiment described above. The process begins when the CRE module 203 detects a user input specifying a checked-in customer and being indicative of an intent to initiate a payment transaction involving the customer (step 622). In response to the user input, the CRE module 203 initiates the payment transaction by outputting, to the main POS application 201, data that emulates output of the card reader 204, without an actual card read event having occurred in relation to the payment transaction (step 624). After the transaction has been approved by a payment processing entity (e.g., the issuer 118), when the CRE module 203 detects a print signal generated by the main POS module 201 for generating a transaction receipt (step 626), the CRE module 203 prevents generation of a printed receipt by intercepting the print signal (step 628). The print signal includes receipt data for enabling a receipt to be printed by the receipt printer 205. In response to the print signal, the CRE module 203 sends a first message to the payment service system 108 (step 630), including at least some of the receipt data, to cause the payment service system 108 to send a second message to the customer's mobile device 102. The second message enables the mobile device 102 to output a virtual receipt for the payment transaction to the consumer.
  • In the embodiment described above, the CRE module 203 receives from the payment service system 108 an actual payment card number of the user, and passes that number to the main POS application 201 when a transaction is initiated. In another embodiment, however, the cardless payment service generates a one-time-use payment card number for the transaction, and passes that to the main POS application 201 instead of a real payment card number of the consumer, as noted above. The one-time-use card number can be generated by the payment service system 108 or by the CRE module 203 in response to the user checking in at the merchant. In this embodiment, the payment service which operates the payment service system 108 essentially acts as the credit card issuer from the perspective of the merchant. The merchant POS system 104 charges the one-time-use credit card number, and the payment service later charges the consumer's actual credit card number which is stored in the payment service system 108. The initial set-up process in this embodiment can be substantially identical to that of FIG. 4, except that in step 410, the payment service system 108 sends the one-time-use payment account number to the merchant POS system 104 instead of sending the consumer's actual credit card number. The one-time-use account number has a format recognizable by the merchant POS system 104, e.g., a standard credit or debit card format.
  • A cardless transaction using the one-time use payment account number can involve the following operations, as illustrated in FIG. 7. In response to the merchant 100 providing a user input 701 to trigger the cardless payment transaction, the CRE module 203 emulates the card reader 204 by sending, to the main POS application 201, data 702 associated with the consumer that appears to the main POS application 201 to be associated with a card read event, although no actual card read event has occurred. This can be done in the manner described above. The one-time-use payment account number as well as the consumer's name, account expiration date and CVV are provided by the CRE module 203 to the main POS application 201 in the protocol of the card reader. Other data related to the may also be provided if required by the API of the card reader.
  • The main POS application 201, upon receiving the card read event data 702 from the CRE module 203, sends the card read event data in a standard payment authorization request 703 that, in this embodiment, is forwarded to the payment service system 108, which represents the issuer. In practice, the payment authorization request 703 may actually be sent first to the merchant's acquirer 114, which forwards the request or sends a corresponding new request to the card payment network 116, which then forwards the request or generates a corresponding new request to the payment service system 108; however, these intermediate communications are omitted from FIG. 7 to simplify explanation.
  • If the transaction is approved by the payment service system 108, the payment service system 108 sends a standard payment authorization (approval) message 704 back to the merchant's main POS application 201, using a communication path opposite of that mentioned above. The main POS application 201 responds to the payment authorization message 704 by generating a print signal 705 for the local receipt printer 205 of the merchant POS system 104. However, the CRE module 203 intercepts the print signal 705 and prevents it from reaching the printer 205, as described above. In this embodiment, the payment service system 108 does not need to receive a signal from the CRE module 203 before sending send the virtual receipt, since it already knows the transaction is approved. Accordingly, at approximately the same time that the payment service system 108 sends the payment authorization signal 704, or shortly thereafter, it also sends a message 706 containing a virtual receipt for the transaction to the mobile device 102 of the customer. The mobile payment application 120 on the customer's mobile device 102 then displays the virtual receipt to the user.
  • At some later time, the payment system 108 sends a payment request 707 to the issuer 118 of an actual payment card of the customer. The information of that actual payment card was previously received and stored by the payment service system 108 when the customer registered for the cardless payment service. The payment service system 108 subsequently receives payment 708 from the issuer 118.
  • The technique introduced here also enables a customer to tip the merchant (e.g., a waiter). There are various ways of accomplishing that. In one approach, illustrated in FIG. 8, when the virtual receipt is displayed to the customer 101 by the mobile device 102, the customer is prompted (801) by the mobile payment application 120 running on the mobile device 102 to input a tip amount. Accordingly, the customer inputs (802) a tip amount into the mobile payment application 120. The mobile payment application 120 then sends a message 803 to the payment service system 108 including the tip amount. The payment service system 108 than sends a message 804 to the CRE module 203 in the merchant POS system 104 indicating the tip amount. The CRE module 203 then triggers the display of the merchant POS system 104 to display the tip amount on the display of the merchant POS system (805). The merchant 100 sees the displayed tip amount and then inputs (806) the total transaction amount (e.g., amount charged plus tip) into the main POS application 201 in the traditional manner. The main POS application 201 then processes the transaction according to the traditional transaction capture process (807).
  • In another approach, rather than requiring the merchant to copy over the tip amount into the main POS application 201, the CRE module 203 simulates a sequence of user inputs (e.g., a sequence of touchscreen or keypad presses) to the main POS application 201, to cause the main POS application 201 to enter an appropriate state for inputting the tip amount (or total transaction amount), and then simulates the proper user input sequence to input that amount into the main POS application 201. For example, the CRE module 203 can invoke an API of an input device of the POS system (e.g., a touchscreen or keyboard/keypad) to communicate the tip amount to the main POS application 201, such that the tip amount appears to the main POS application 201 to have been input by a human user.
  • In yet another approach, the waiter pre-registers with the payment service system 108 as a merchant (or merchant employee, as the case may be) and identifies himself to the CRE module 203 via the GUI when he arrives at work each day. After a cardless payment transaction has been authorized as described above, the CRE module 203 causes the display to output a prompt asking which waiter should receive the tip. The waiter taps his own name on the display. The CRE module 203 then sends a message indicating this selection to the payment service system 108. The payment service system 108 then pushes the tip directly to the waiter, via automated clearing house (ACH) or debit, for example.
  • FIG. 9 is a high-level block diagram showing an example of a processing device 900 that can represent any of the devices described above, such as the mobile device 102, the merchant POS system 104, payment service system 108, acquirer system 114, card payment network 116, or issuer system 118. As noted above, any of these systems may include two or more processing devices such as represented in FIG. 9, which may be coupled to each other via a network or multiple networks.
  • In the illustrated embodiment, the processing system 900 includes one or more processors 910, memory 911, a communication device 912, and one or more input/output (I/O) devices 913, all coupled to each other through an interconnect 914. The interconnect 914 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices. The processor(s) 910 may be or include, for example, one or more general-purpose programmable microprocessors, microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices. The processor(s) 910 control the overall operation of the processing device 900. Memory 911 may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. Memory 911 may store data and instructions that configure the processor(s) 910 to execute operations in accordance with the techniques described above. The communication device 912 may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth transceiver, or the like, or a combination thereof. Depending on the specific nature and purpose of the processing device 900, the I/O devices 913 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc.
  • Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described above may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.
  • The techniques introduced above can be implemented by programmable circuitry programmed/configured by software and/or firmware, or entirely by special-purpose circuitry, or by a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.
  • Software or firmware to implement the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “machine-readable medium”, as the term is used herein, includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
  • Note that any and all of the embodiments described above can be combined with each other, except to the extent that it may be stated otherwise above or to the extent that any such embodiments might be mutually exclusive in function and/or structure.
  • Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.

Claims (32)

1. A method comprising:
detecting user input at a point-of-sale (POS) system located at a merchant location where a consumer is physically present at a time of a payment transaction involving the consumer and a merchant, the user input entered via a user interface of the POS system, the user input specifying the consumer and being indicative of an intent to initiate the payment transaction;
in response to the user input, initiating the payment transaction in the POS system by outputting, to a POS module in the POS system, data that emulates output of a physical card reader associated with a card read event, without an actual card read event having occurred in relation to the payment transaction, wherein said outputting data that emulates output of a physical card reader includes invoking a card reader application programming interface (API) associated with the physical card reader;
after the payment transaction has been approved by a payment processing entity, preventing generation of a printed receipt for the payment transaction by intercepting a print signal generated by the POS module for activating a receipt printer, the print signal including receipt data; and
in response to the print signal, sending a first message from the POS system to cause a second message to be sent to a mobile device of the consumer, the second message for enabling the mobile device to output a virtual receipt for the payment transaction to the consumer.
2. A method as recited in claim 1, wherein said outputting data that emulates output of a physical card reader comprises sending the data that emulates output of a card reader to the POS module in a protocol of the card reader.
3. (canceled)
4. A method as recited in claim 1, wherein said causing the second message to be sent to the mobile device of the consumer comprises sending the first message to a remote entity via a network, to cause the remote entity to send the second message to the mobile device of the consumer.
5. A method as recited in claim 1, wherein the second message contains data representing the virtual receipt.
6. A method as recited in claim 1, wherein said outputting data that emulates output of a physical card reader comprises providing to the POS module a payment account identifier of a payment card of the consumer.
7. A method as recited in claim 1, wherein said outputting data that emulates output of a physical card reader comprises providing to the POS module a one-time-use account identifier for use only for said payment transaction involving the consumer, wherein the one-time-use account identifier is not an account identifier of a payment card of the consumer but is in an account identifier format recognizable by the POS module.
8. A method as recited in claim 1, further comprising:
parsing the receipt data in the print signal to identify semantic elements of the receipt data.
9. A method comprising:
detecting, at a processing system, user input indicative of an intent to initiate a transaction associated with a person; and
initiating the transaction in response to the user input by emulating reading of a card associated with the person, without any card read event having occurred for the transaction.
10. A method as recited in claim 9, wherein the transaction is a financial transaction.
11. A method as recited in claim 10, wherein the transaction is a payment transaction.
12. A method as recited in claim 9, wherein said emulating comprises sending data that emulates output of a physical card reader to an application, in a protocol of the physical card reader.
13. A method as recited in claim 9, further comprising:
detecting a signal indicative that the transaction has been approved; and
in response to the signal,
preventing generation of a printed record of the transaction; and
causing a message to be sent to a mobile device of the person, to enable the mobile device to output a virtual record of the transaction to the person.
14. A method as recited in claim 13, wherein preventing generation of a printed record of the transaction comprises intercepting a print signal for activating a printer, the print signal including data for enabling a record of the transaction to be printed by the printer.
15. An apparatus comprising:
a card reader emulator to detect user input indicative of an intent to initiate a financial transaction involving a consumer and, in response thereto, to initiate the financial transaction by outputting data that emulates a card read event for the payment transaction without an actual card read event having occurred for the payment transaction; and
a receipt manager to prevent generation of a printed receipt for the financial transaction by preventing a print signal from being communicated to a printer in relation to said payment transaction, and to cause a message to be sent to a mobile device of the consumer, to enable the mobile device to output a virtual receipt for the financial transaction.
16. An apparatus as recited in claim 15, wherein the card reader emulator is configured to emulate output of the physical card reader by invoking a card reader application programming interface (API).
17. An apparatus as recited in claim 15, wherein the receipt manager is configured to parse receipt data in the print signal to identify semantic elements of the receipt data.
18. A point-of-sale (POS) system comprising:
a processor;
a memory coupled to the processor and storing a POS module executable by the processor, the POS module configured to process payment transactions, including to receive card data resulting from card read events from a physical card reader and to cause the card data to be sent to a remote authorization entity over a network in response to the card read events;
a user input device coupled to the processor, to receive user input specifying a consumer, the user input being indicative of an intent to initiate a payment transaction involving the consumer; and
a card read emulator (CRE) module configured to detect the user input and, in response thereto, to emulate the physical card reader by outputting, to the POS module, card read event data for the payment transaction without an actual card read event having occurred for the payment transaction.
19. A POS system as recited in claim 18, wherein the CRE module is further configured to prevent generation of a printed receipt for the payment transaction by preventing a print signal from being communicated to the printer in relation to said payment transaction, and to send a first message from the POS system to cause a second message to be sent to a mobile device of the consumer, the second message for enabling the mobile device to output a virtual receipt for the payment transaction to the consumer.
20. A POS system as recited in claim 19, wherein the CRE module is configured to cause the second message to be sent to the mobile device of the consumer by sending the first message to a remote entity via a network, to cause the remote entity to send the second message to the mobile device of the consumer, the second message containing data representing the virtual receipt.
21. A POS system as recited in claim 18, wherein the CRE module is configured to emulate output of a physical card reader by invoking a card reader application programming interface (API).
22. A POS system as recited in claim 18, wherein the CRE module is configured to emulate output of a physical card reader by providing to the POS module a one-time-use account identifier for use only for said payment transaction involving the consumer, wherein the one-time-use account identifier is not an account identifier of a payment card of the consumer but is in an account identifier format recognizable by the POS module.
23. A POS system as recited in claim 18, wherein the CRE module is further configured to parse the receipt data in the print signal to identify semantic elements of the receipt data.
24. A POS system as recited in claim 18, wherein the CRE module is a component of the POS module.
25. A POS system as recited in claim 18, wherein the CRE module is logically separate from the POS module.
26. A non-transitory machine-readable storage medium tangibly storing program code that, if executed by one or more processors in a point-of-sale (POS) system located at a POS location of a merchant, will cause the POS system to perform operations including:
detecting, at the point-of-sale (POS) system, user input entered via a user interface of the POS system, the user input specifying a consumer and being indicative of an intent to initiate a payment transaction involving the consumer;
in response to the user input, initiating the payment transaction in the POS system by outputting, to a POS module in the POS system, data that emulates output of a physical card reader associated with a card read event, without an actual card read event having occurred in relation to the payment transaction, wherein said outputting data that emulates output of a physical card reader includes invoking a card reader application programming interface (API) associated with the physical card reader;
after the payment transaction has been approved by a payment processing entity, preventing generation of a printed receipt for the payment transaction by intercepting a print signal generated by the POS module for activating a receipt printer, the print signal including receipt data; and
in response to the print signal, sending a first message from the POS system to cause a second message to be sent to a mobile device of the consumer, the second message for enabling the mobile device to output a virtual receipt for the payment transaction to the consumer.
27. A machine-readable storage medium as recited in claim 26, wherein said outputting data that emulates output of a physical card reader comprises sending the data that emulates output of a card reader to the POS module in a protocol of the card reader.
28. A machine-readable storage medium as recited in claim 26, wherein said causing the second message to be sent to the mobile device of the consumer comprises sending the first message to a remote entity via a network, to cause the remote entity to send the second message to the mobile device of the consumer.
29. A machine-readable storage medium as recited in claim 26, wherein the second message contains data representing the virtual receipt.
30. A machine-readable storage medium as recited in claim 26, wherein said outputting data that emulates output of a physical card reader comprises providing to the POS module a payment account identifier of a payment card of the consumer.
31. A machine-readable storage medium as recited in claim 26, wherein said outputting data that emulates output of a physical card reader comprises providing to the POS module a one-time-use account identifier for use only for said payment transaction involving the consumer, wherein the one-time-use account identifier is not an account identifier of a payment card of the consumer but is in an account identifier format recognizable by the POS module.
32. A machine-readable storage medium as recited in claim 26, further comprising:
parsing the receipt data in the print signal to identify semantic elements of the receipt data.
US14/187,049 2013-11-26 2014-02-21 Card reader emulation for cardless transactions Active 2034-02-25 US9037491B1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
US14/187,049 US9037491B1 (en) 2013-11-26 2014-02-21 Card reader emulation for cardless transactions
EP14875157.1A EP3077970A4 (en) 2013-12-27 2014-12-23 Card reader emulation for cardless transactions
PCT/US2014/072285 WO2015100385A1 (en) 2013-12-27 2014-12-23 Card reader emulation for cardless transactions
CA2935177A CA2935177C (en) 2013-12-27 2014-12-23 Card reader emulation for cardless transactions
JP2016561596A JP6475752B2 (en) 2013-12-27 2014-12-23 Card reader emulation for cardless transactions
AU2014369891A AU2014369891B2 (en) 2013-12-27 2014-12-23 Card reader emulation for cardless transactions
US14/667,496 US9626669B2 (en) 2013-11-26 2015-03-24 Card reader emulation for cardless transactions
US15/489,700 US11107056B2 (en) 2013-11-26 2017-04-17 Card data output for cardless transactions
US17/461,509 US20220058611A1 (en) 2013-11-26 2021-08-30 Card data output for cardless transactions

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361909282P 2013-11-26 2013-11-26
US201361921374P 2013-12-27 2013-12-27
US14/187,049 US9037491B1 (en) 2013-11-26 2014-02-21 Card reader emulation for cardless transactions

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/667,496 Division US9626669B2 (en) 2013-11-26 2015-03-24 Card reader emulation for cardless transactions

Publications (2)

Publication Number Publication Date
US9037491B1 US9037491B1 (en) 2015-05-19
US20150149309A1 true US20150149309A1 (en) 2015-05-28

Family

ID=53054728

Family Applications (5)

Application Number Title Priority Date Filing Date
US14/187,104 Active 2035-04-14 US9799021B1 (en) 2013-11-26 2014-02-21 Tip processing at a point-of-sale system
US14/187,049 Active 2034-02-25 US9037491B1 (en) 2013-11-26 2014-02-21 Card reader emulation for cardless transactions
US14/667,496 Active US9626669B2 (en) 2013-11-26 2015-03-24 Card reader emulation for cardless transactions
US15/489,700 Active 2034-07-16 US11107056B2 (en) 2013-11-26 2017-04-17 Card data output for cardless transactions
US17/461,509 Pending US20220058611A1 (en) 2013-11-26 2021-08-30 Card data output for cardless transactions

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US14/187,104 Active 2035-04-14 US9799021B1 (en) 2013-11-26 2014-02-21 Tip processing at a point-of-sale system

Family Applications After (3)

Application Number Title Priority Date Filing Date
US14/667,496 Active US9626669B2 (en) 2013-11-26 2015-03-24 Card reader emulation for cardless transactions
US15/489,700 Active 2034-07-16 US11107056B2 (en) 2013-11-26 2017-04-17 Card data output for cardless transactions
US17/461,509 Pending US20220058611A1 (en) 2013-11-26 2021-08-30 Card data output for cardless transactions

Country Status (1)

Country Link
US (5) US9799021B1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017039241A1 (en) * 2015-08-28 2017-03-09 Samsung Electronics Co., Ltd. Payment information processing method and apparatus of electronic device
US20170352017A1 (en) * 2016-06-01 2017-12-07 Ronny Hay Close proximity ordering and payment system and method
US10055721B1 (en) * 2014-05-09 2018-08-21 Square, Inc. Replicating online-transaction behavior in offline transactions

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090159681A1 (en) * 2007-12-24 2009-06-25 Dynamics, Inc. Cards and devices with magnetic emulators and magnetic reader read-head detectors
US9911103B2 (en) * 2010-10-14 2018-03-06 Syniverse Technologies, Llc Payment gateway for processing payment requests associated with a wireless users account
GB201105765D0 (en) 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
US9449461B1 (en) * 2012-03-25 2016-09-20 Dynamic Gaming Systems LLC Networked gaming system enabling a plurality of player stations to play independent games with online play
US10496977B2 (en) 2012-07-16 2019-12-03 Square, Inc. Storing and forwarding payment transactions
CN106710093A (en) * 2012-11-30 2017-05-24 精工爱普生株式会社 Receipt production system, printer, and control method thereof
US8924259B2 (en) 2013-03-14 2014-12-30 Square, Inc. Mobile device payments
US8892462B1 (en) 2013-10-22 2014-11-18 Square, Inc. Proxy card payment with digital receipt delivery
US20150134439A1 (en) 2013-11-08 2015-05-14 Square, Inc. Interactive digital receipt
WO2015073888A2 (en) * 2013-11-14 2015-05-21 Protean Payment, Inc. Method for remotely controlling a reprogrammable payment card
US9799021B1 (en) 2013-11-26 2017-10-24 Square, Inc. Tip processing at a point-of-sale system
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US20150332223A1 (en) 2014-05-19 2015-11-19 Square, Inc. Transaction information collection for mobile payment experience
CN106465112A (en) 2014-05-21 2017-02-22 维萨国际服务协会 Offline authentication
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US9741026B1 (en) 2014-09-30 2017-08-22 Square, Inc. Payment by use of identifier
US10515354B1 (en) 2014-12-05 2019-12-24 Square, Inc. Discounted card not present rates following failed card present attempts
US10325250B2 (en) * 2014-12-10 2019-06-18 Meijer, Inc. System and method for linking POS purchases to shopper membership accounts
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
US10026062B1 (en) 2015-06-04 2018-07-17 Square, Inc. Apparatuses, methods, and systems for generating interactive digital receipts
US10438177B2 (en) * 2015-06-15 2019-10-08 Worldpay, Llc System and method for third party payment at point of sale terminals
US9519901B1 (en) 2015-09-16 2016-12-13 Square, Inc. Biometric payment technology
US9569757B1 (en) 2015-09-30 2017-02-14 Square, Inc. Anticipatory creation of point-of-sale data structures
CN105590378B (en) * 2015-11-24 2018-10-23 中国银联股份有限公司 A kind of POS terminal and the method tested using the POS terminal
US11295293B2 (en) * 2016-01-07 2022-04-05 Worldpay, Llc Point of interaction device emulation for payment transaction simulation
US10163107B1 (en) 2016-03-31 2018-12-25 Square, Inc. Technical fallback infrastructure
US20170352030A1 (en) * 2016-06-02 2017-12-07 Diip, LLC Anonymous mobile payment system
US10289992B1 (en) * 2016-06-17 2019-05-14 Square, Inc. Kitchen display interfaces with in flight capabilities
US10311420B1 (en) 2016-06-17 2019-06-04 Square, Inc. Synchronizing open ticket functionality with kitchen display systems
US10360648B1 (en) 2016-06-22 2019-07-23 Square, Inc. Synchronizing KDS functionality with POS waitlist generation
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
SG11201808998RA (en) 2016-07-11 2018-11-29 Visa Int Service Ass Encryption key exchange process using access device
WO2018013050A1 (en) * 2016-07-14 2018-01-18 Aptus Business Logic Pte Ltd System, device, and method for capturing and managing point of sale transaction related data
US10872320B2 (en) 2016-07-29 2020-12-22 Square, Inc. Reprogrammable point-of-sale transaction flows
US10496973B2 (en) 2016-07-29 2019-12-03 Square, Inc. Reprogrammable point-of-sale transaction flows
US20180033014A1 (en) * 2016-07-29 2018-02-01 Square, Inc. Reprogrammable point-of-sale transaction flows
US10692055B2 (en) 2016-07-29 2020-06-23 Square, Inc. Reprogrammable point-of-sale transaction flows
US10062074B1 (en) 2016-11-30 2018-08-28 Square, Inc. System for improving card on file transactions
WO2018170404A1 (en) * 2017-03-16 2018-09-20 Jpmorgan Chase Bank, N.A. Systems and methods for supporting legacy and tokenized e-commerce
US11593773B1 (en) 2017-03-31 2023-02-28 Block, Inc. Payment transaction authentication system and method
US10755281B1 (en) 2017-03-31 2020-08-25 Square, Inc. Payment transaction authentication system and method
US20180315038A1 (en) 2017-04-28 2018-11-01 Square, Inc. Multi-source transaction processing
US10922727B2 (en) * 2017-08-29 2021-02-16 Mastercard International Incorporated System and method for automated distribution to selected multiple receivers
US10467559B1 (en) 2017-09-29 2019-11-05 Square, Inc. Order fulfillment and tracking systems and methods
US10943311B1 (en) 2017-09-29 2021-03-09 Square, Inc. Order fulfillment and tracking systems and methods
US10534680B1 (en) * 2017-12-11 2020-01-14 Worldpay, Llc Systems and methods for simulation-based replay of integrated devices
US10997583B1 (en) 2018-08-31 2021-05-04 Square, Inc. Temporarily provisioning card on file payment functionality to proximate merchants
US10878402B1 (en) 2018-08-31 2020-12-29 Square, Inc. Temporarily provisioning payment functionality to alternate payment instrument
US11138680B1 (en) 2018-11-21 2021-10-05 Square, Inc. Updating menus based on predicted efficiencies
US10915905B1 (en) 2018-12-13 2021-02-09 Square, Inc. Batch-processing transactions in response to an event
US11605064B2 (en) * 2019-03-12 2023-03-14 Innovative Control Systems, Inc. Payment processing and messaging system for an unattended kiosk
US11294693B2 (en) * 2020-04-14 2022-04-05 Ncr Corporation Virtualized transaction terminal platform
US20230015850A1 (en) * 2021-07-19 2023-01-19 Apple Inc. User input during an electronic data transfer

Citations (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5960411A (en) * 1997-09-12 1999-09-28 Amazon.Com, Inc. Method and system for placing a purchase order via a communications network
US20030208386A1 (en) * 2000-02-25 2003-11-06 Rayner Brondrup Wireless reservation, check-in, access control, check-out and payment
US20030212609A1 (en) * 2002-04-03 2003-11-13 Jeffery Blair Method of facilitating a transaction between a buyer and at least one seller
US20040029569A1 (en) * 2001-12-26 2004-02-12 Vivotech, Inc. Micropayment financial transaction process utilizing wireless network processing
US6738749B1 (en) * 1998-09-09 2004-05-18 Ncr Corporation Methods and apparatus for creating and storing secure customer receipts on smart cards
US6763399B2 (en) * 1998-11-10 2004-07-13 Aladdin Knowledge Systems, Ltd. USB key apparatus for interacting with a USB host via a USB port
US20060047576A1 (en) * 2004-08-30 2006-03-02 Nokia Corporation Automated memory and accessory purchasing agent for use in a mobile terminal
US7069240B2 (en) * 2002-10-21 2006-06-27 Raphael Spero System and method for capture, storage and processing of receipts and related data
US20070069013A1 (en) * 2005-09-28 2007-03-29 First Data Corporation Electronic receipting
US7305129B2 (en) * 2003-01-29 2007-12-04 Microsoft Corporation Methods and apparatus for populating electronic forms from scanned documents
US20080040233A1 (en) * 2006-08-08 2008-02-14 Thomas Alfred Wildman Mobile order fulfillment
US20080167961A1 (en) * 2007-01-09 2008-07-10 Dave Wentker Contactless transaction
US20080215475A1 (en) * 2005-11-05 2008-09-04 Jorey Ramer Exclusivity bidding for mobile sponsored content
US20090065571A1 (en) * 2007-09-12 2009-03-12 Devicefidelity, Inc. Selectively switching antennas of transaction cards
US20090157547A1 (en) * 2007-12-12 2009-06-18 John Ruckart Financial transaction authentication servers, methods, and computer program products for facilitating financial transactions between buyers and sellers
US20090159663A1 (en) * 2007-12-24 2009-06-25 Dynamics Inc. Payment cards and devices operable to receive point-of-sale actions before point-of-sale and forward actions at point-of-sale
US20090187488A1 (en) * 2008-01-22 2009-07-23 John Shamilian Method and system for providing a service to a customer
US20090187466A1 (en) * 2008-01-23 2009-07-23 Maphook, Inc. Location-Based Information-Geo Retail Notification
US20090187492A1 (en) * 2007-10-25 2009-07-23 Ayman Hammad Location based authentication
US20090228325A1 (en) * 2008-03-06 2009-09-10 J. Simmons, D. Pewzner & B. Kole Dba Now On Wireless Just in time pickup or receipt of goods or services by a mobile user
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US20090313101A1 (en) * 2008-06-13 2009-12-17 Microsoft Corporation Processing receipt received in set of communications
US20090327135A1 (en) * 2008-06-26 2009-12-31 Loc Duc Nguyen Credit card paired with location identifiable device for point of service fraud detection
US20100019033A1 (en) * 2007-01-26 2010-01-28 Paul Jolivet Contactless interface within a terminal to support a contactless service
US20100030651A1 (en) * 2005-11-04 2010-02-04 Richard Victor Matotek Mobile phone as a point of sale (POS) device
US20100082445A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Smart menu options
US20100138344A1 (en) * 2008-12-02 2010-06-03 Ebay Inc. Mobile barcode generation and payment
US20100169179A1 (en) * 2005-09-14 2010-07-01 Jorey Ramer Dynamic Bidding and Expected Value
US20100191551A1 (en) * 2009-01-26 2010-07-29 Apple Inc. Systems and methods for accessing hotel services using a portable electronic device
US20100293065A1 (en) * 2008-08-14 2010-11-18 Mike Brody System and method for paying a merchant using a cellular telephone account
US20110184822A1 (en) * 2010-01-22 2011-07-28 Naviit, Inc. Point of sale network router
US20110307342A1 (en) * 2010-06-15 2011-12-15 Haji Faizal Method and system for generating electronic receipts from print data
US20120010938A1 (en) * 2010-07-10 2012-01-12 Bazomb, Inc. Geographically defined electronic coupon or voucher dissemination
US8135624B1 (en) * 2010-03-23 2012-03-13 Amazon Technologies, Inc. User profile and geolocation for efficient transactions
US20120143707A1 (en) * 2010-12-07 2012-06-07 Deepak Jain Executing Reader Application
US8498900B1 (en) * 2011-07-25 2013-07-30 Dash Software, LLC Bar or restaurant check-in and payment systems and methods of their operation
US20130198076A1 (en) * 2012-01-30 2013-08-01 Ebay Inc. Systems and methods to provide check-in based payment processes
US8645222B1 (en) * 2009-03-20 2014-02-04 Jpmorgan Chase Bank, N.A. System and methods for mobile ordering and payment

Family Cites Families (170)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3863050A (en) 1974-01-07 1975-01-28 Max T Brugger Automatic credit card validating device
US4048476A (en) 1976-04-09 1977-09-13 Ncr Corporation Card reader
US5819226A (en) 1992-09-08 1998-10-06 Hnc Software Inc. Fraud detection using predictive modeling
US5859414A (en) 1995-12-29 1999-01-12 Aironet Wireless Communications, Inc. Interactive customer information terminal
US6311165B1 (en) 1998-04-29 2001-10-30 Ncr Corporation Transaction processing systems
US7555450B2 (en) 1999-06-04 2009-06-30 Alternative Financial Solutions Llc Process for seeking authorization for present receipt of legal tender and associated system
US6705520B1 (en) 1999-11-15 2004-03-16 Satyan G. Pitroda Point of sale adapter for electronic transaction device
US7263506B2 (en) 2000-04-06 2007-08-28 Fair Isaac Corporation Identification and management of fraudulent credit/debit card purchases at merchant ecommerce sites
US7698217B1 (en) 2000-04-20 2010-04-13 Christopher Phillips Masking private billing data by assigning other billing data to use in commerce with businesses
US7376618B1 (en) 2000-06-30 2008-05-20 Fair Isaac Corporation Detecting and measuring risk with predictive models using content mining
JP2002099858A (en) 2000-09-26 2002-04-05 Toshiba Tec Corp Settlement system, settlement device and settlement method
US7457767B1 (en) 2000-10-05 2008-11-25 International Business Machines Corporation Pay at the table system
CA2332656A1 (en) 2001-01-26 2002-07-26 Certapay Inc. Online payment transfer and identity management system and method
JP3809857B2 (en) 2001-03-15 2006-08-16 インターナショナル・ビジネス・マシーンズ・コーポレーション Transaction system, transaction terminal, transaction history output device, server, transaction history display method, computer program
US7958024B2 (en) 2001-03-15 2011-06-07 Versata Development Group, Inc. Method and apparatus for processing sales transaction data
US20030065618A1 (en) 2001-09-28 2003-04-03 Vandeboe Frank W. Method and system for electronic payroll advance and deposit
GB0127298D0 (en) 2001-11-14 2002-01-02 Ncr Int Inc Transaction system
JP2003150885A (en) 2001-11-15 2003-05-23 Hitachi Ltd Settlement system and settlement device
US20090177563A1 (en) * 2001-12-07 2009-07-09 American Express Travel Related Services Company, Inc. Authorization refresh system and method
US20040034612A1 (en) 2002-03-22 2004-02-19 Nick Mathewson Support vector machines for prediction and classification in supply chain management and other applications
US7333615B1 (en) * 2002-06-26 2008-02-19 At&T Delaware Intellectual Property, Inc. Encryption between multiple devices
US8397988B1 (en) 2002-08-09 2013-03-19 Britesmart Llc Method and system for securing a transaction using a card generator, a RFID generator, and a challenge response protocol
US7494055B2 (en) 2002-09-17 2009-02-24 Vivotech, Inc. Collaborative negotiation techniques for mobile personal trusted device financial transactions
US7702577B1 (en) 2003-11-06 2010-04-20 Jp Morgan Chase Bank, N.A. System and method for conversion of initial transaction to final transaction
US7543739B2 (en) 2003-12-17 2009-06-09 Qsecure, Inc. Automated payment card fraud detection and location
US7680694B2 (en) * 2004-03-11 2010-03-16 American Express Travel Related Services Company, Inc. Method and apparatus for a user to shop online in a three dimensional virtual reality setting
JP2005321873A (en) 2004-05-06 2005-11-17 Seiko Epson Corp Electronic journal creation system, method, and program
US20050071232A1 (en) 2004-10-19 2005-03-31 Stephanie A. Frater Credit system for restaurant tables and bars
US20060151598A1 (en) 2005-01-13 2006-07-13 Yen-Fu Chen Categorization based spending control
US8047908B2 (en) 2005-03-29 2011-11-01 Igt Methods and systems for determining and selling wagering game outcomes for a plurality of players
US7630938B2 (en) 2005-03-31 2009-12-08 United Parcel Service Of America, Inc. Flexible billing adjustment system
US7721969B2 (en) 2005-04-21 2010-05-25 Securedpay Solutions, Inc. Portable handheld device for wireless order entry and real time payment authorization and related methods
US9391985B2 (en) 2005-04-26 2016-07-12 Guy Hefetz Environment-based two-factor authentication without geo-location
JP2007072534A (en) 2005-09-02 2007-03-22 Star Micronics Co Ltd Print system, control method of print system and program
US7997476B2 (en) 2005-09-15 2011-08-16 Capital One Financial Corporation Wireless devices for storing a financial account card and methods for storing card data in a wireless device
US20070108279A1 (en) 2005-11-14 2007-05-17 A-Men Technology Corporation Unfold smart-card card reader
US8275312B2 (en) 2005-12-31 2012-09-25 Blaze Mobile, Inc. Induction triggered transactions using an external NFC device
US7693767B2 (en) 2006-03-23 2010-04-06 Oracle International Corporation Method for generating predictive models for a business problem via supervised learning
US7788195B1 (en) 2006-03-24 2010-08-31 Sas Institute Inc. Computer-implemented predictive model generation systems and methods
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US20080040261A1 (en) 2006-04-24 2008-02-14 Robert Nix Systems and methods for implementing financial transactions
US20070260513A1 (en) 2006-05-05 2007-11-08 Incentive Systems, Inc. System and method for administering a compensation management plan
US8490869B2 (en) 2006-05-10 2013-07-23 Metavante Corporation Predictive authorization techniques
US20080126260A1 (en) 2006-07-12 2008-05-29 Cox Mark A Point Of Sale Transaction Device With Magnetic Stripe Emulator And Biometric Authentication
US7748618B2 (en) 2006-08-21 2010-07-06 Verizon Patent And Licensing Inc. Secure near field transaction
WO2008042302A2 (en) 2006-09-29 2008-04-10 Narian Technologies Corp. Apparatus and method using near field communications
US20080208743A1 (en) 2007-02-22 2008-08-28 First Data Corporation Transfer of value between mobile devices in a mobile commerce system
US20090048936A1 (en) * 2007-04-13 2009-02-19 Lerch John W Method and system for RFID transaction integrity utilizing an EEPROM
US8121942B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Systems and methods for secure and transparent cardless transactions
US20090006151A1 (en) 2007-06-29 2009-01-01 Jay Zarghami Collection of receipt data from point-of-sale devices
US20090043696A1 (en) 2007-08-08 2009-02-12 Electronic Payment Exchange Payment Processor Hosted Account Information
JP2009086832A (en) 2007-09-28 2009-04-23 Nidec Sankyo Corp Information system
US20150081557A1 (en) 2010-09-14 2015-03-19 Craig Patrick Kinfoil Method of processing payment transactions
US20090164374A1 (en) 2007-12-21 2009-06-25 Ebay Inc. System and Methods for One Time Check Numbers
US20140258055A1 (en) 2008-03-13 2014-09-11 Giftya Llc System and method for a gift tracker
JP2009226689A (en) 2008-03-21 2009-10-08 Seiko Epson Corp Printer
US20100005013A1 (en) 2008-07-03 2010-01-07 Retail Decisions, Inc. Methods and systems for detecting fraudulent transactions in a customer-not-present environment
US9652023B2 (en) 2008-07-24 2017-05-16 Intelligent Mechatronic Systems Inc. Power management system
US20100057612A1 (en) 2008-09-03 2010-03-04 Fan Hub Llc Kiosk based purchasing system
US20100097946A1 (en) 2008-10-22 2010-04-22 Nokia Corporation Optimized data transfer between approaching devices
BRPI0921124A2 (en) 2008-11-06 2016-09-13 Visa Int Service Ass system for authenticating a consumer, computer implemented method, computer readable medium, and server computer.
US20100063945A1 (en) 2008-11-12 2010-03-11 Cowan Jr William Curtis Systems and Methods Involving Processing of Payments Using Handheld Devices
US9557889B2 (en) 2009-01-28 2017-01-31 Headwater Partners I Llc Service plan design, user interfaces, application programming interfaces, and device management
US20100248779A1 (en) 2009-03-26 2010-09-30 Simon Phillips Cardholder verification rule applied in payment-enabled mobile telephone
US7783515B1 (en) 2009-03-27 2010-08-24 Bank Of America Corporation Itemized receipt tracking system
US8600873B2 (en) 2009-05-28 2013-12-03 Visa International Service Association Managed real-time transaction fraud analysis and decisioning
US8745698B1 (en) 2009-06-09 2014-06-03 Bank Of America Corporation Dynamic authentication engine
US20110047075A1 (en) * 2009-08-19 2011-02-24 Mastercard International Incorporated Location controls on payment card transactions
US8412605B2 (en) 2009-12-01 2013-04-02 Bank Of America Corporation Comprehensive suspicious activity monitoring and alert system
JP2011197511A (en) 2010-03-23 2011-10-06 Seiko Epson Corp Voice output device, method for controlling the same, and printer and mounting board
WO2011130585A2 (en) 2010-04-16 2011-10-20 Tiny Towne International, Llc System and method for driver training in a controlled driving environment
US20110313871A1 (en) 2010-05-18 2011-12-22 Laura Greenwood Apparatus, system, and method for facilitating a payment
WO2011156884A1 (en) 2010-06-17 2011-12-22 Consumer Mt Inc. Electronic payment system and method
US8660948B2 (en) * 2010-07-02 2014-02-25 Qualcomm Incorporated System and method for managing transactions with a portable computing device
US8321281B2 (en) 2010-08-19 2012-11-27 Stac Media, Inc. Automated sales tax payment system
US20120054102A1 (en) 2010-08-26 2012-03-01 Obopay, Inc. Method & System for Providing Payments Over A Wireless Connection
US8831677B2 (en) 2010-11-17 2014-09-09 Antony-Euclid C. Villa-Real Customer-controlled instant-response anti-fraud/anti-identity theft devices (with true-personal identity verification), method and systems for secured global applications in personal/business e-banking, e-commerce, e-medical/health insurance checker, e-education/research/invention, e-disaster advisor, e-immigration, e-airport/aircraft security, e-military/e-law enforcement, with or without NFC component and system, with cellular/satellite phone/internet/multi-media functions
US20120123935A1 (en) * 2010-11-17 2012-05-17 David Brudnicki System and Method for Physical-World Based Dynamic Contactless Data Emulation in a Portable Communication Device
US20120173410A1 (en) 2011-01-03 2012-07-05 Relay Holdings, Llc System and method for paying citations using sms text messaging
US20130290127A1 (en) 2011-01-10 2013-10-31 James Finseth System and Method for Enabling Sales Requests and Offers from Multiple Buyers in Online Environment
CN102625304B (en) * 2011-01-27 2016-01-20 腾讯科技(深圳)有限公司 Failure mobile terminal associated application remembers system, the device and method of password
US8566648B2 (en) * 2011-02-02 2013-10-22 Salesforce, Inc. Automated testing on devices
CA2831890A1 (en) 2011-04-01 2012-10-04 Visa International Service Association Restricted-use account payment administration apparatuses, methods and systems
US8751318B2 (en) * 2011-05-30 2014-06-10 Lg Electronics Inc. Method for managing and/or controlling store and system for the same
US20160055583A1 (en) 2011-06-03 2016-02-25 Mozido, Inc. Mobile global exchange platform
US20120317013A1 (en) 2011-06-13 2012-12-13 Ho Ming Luk Computer-Implemented Systems And Methods For Scoring Stored Enterprise Data
WO2012178092A1 (en) 2011-06-23 2012-12-27 Fullcontact Inc Information cataloging
US20130073347A1 (en) 2011-09-21 2013-03-21 Albert Bogaard Vehicular citation management method and system
US20130226318A1 (en) 2011-09-22 2013-08-29 Dariusz Procyk Process transformation and transitioning apparatuses, methods and systems
US20130080331A1 (en) * 2011-09-26 2013-03-28 Ebay Inc. System and Method for Instantaneous Retail Payment
US20140310113A1 (en) * 2011-10-01 2014-10-16 Uttam Sengupta Cloud based credit card emulation
EP2579194A1 (en) 2011-10-04 2013-04-10 Research In Motion Limited Providing increased ability to perform a transaction based on locale
US8762265B2 (en) * 2011-10-25 2014-06-24 Ryder Kessler Method for collecting and disbursing electronic gratuities
US11580562B2 (en) 2011-10-25 2023-02-14 Alexander Song Anti-fraud financial transactions system
US10339525B2 (en) 2011-10-27 2019-07-02 Boom! Payments, Inc. Confirming local marketplace transaction consummation for online payment consummation
JP5799757B2 (en) 2011-11-02 2015-10-28 セイコーエプソン株式会社 Receipt management device, receipt management system, and receipt management device control method
DE202012100620U1 (en) 2011-11-22 2012-06-13 Square, Inc. System for processing cardless payment transactions
JP6153947B2 (en) 2012-01-05 2017-06-28 ヴィザ インターナショナル サーヴィス アソシエイション Transaction video capture device, method and system
US20130254115A1 (en) 2012-01-19 2013-09-26 Mastercard International Incorporated Converged cross-platform electronic wallet
US20130218757A1 (en) 2012-02-16 2013-08-22 Dharani Ramanathan Payments using a recipient photograph
US8947239B1 (en) 2012-03-05 2015-02-03 Fitbit, Inc. Near field communication system, and method of operating same
US8500010B1 (en) 2012-03-15 2013-08-06 Ebay Inc. Card reader for mobile device
US9741045B1 (en) 2012-03-16 2017-08-22 Square, Inc. Ranking of merchants for cardless payment transactions
US9898732B2 (en) 2012-03-31 2018-02-20 Intel Corporation Securely generating time and location bounded virtual transaction cards using mobile wallets without involving third parties or point of sale terminals
US20130282589A1 (en) 2012-04-20 2013-10-24 Conductiv Software, Inc. Multi-factor mobile transaction authentication
JP2013238977A (en) 2012-05-14 2013-11-28 Seiko Epson Corp Receipt data processing apparatus and receipt data processing method
US9607297B2 (en) 2012-06-06 2017-03-28 Intuit Inc. Mobile payment via a virtual peripheral device
US9818093B1 (en) * 2012-06-14 2017-11-14 Amazon Technologies, Inc. Third party check-in associations with cloud wallet
US9262755B2 (en) 2012-06-20 2016-02-16 Intuit Inc. Mobile payment system
US10096020B2 (en) 2012-08-30 2018-10-09 Worldpay, Llc Combination payment card and methods thereof
US8606696B1 (en) 2012-09-11 2013-12-10 Simplexity, Inc. Assessing consumer purchase behavior in making a financial contract authorization decision
US20140095310A1 (en) 2012-09-30 2014-04-03 Awear Solutions Ltd Methods and Apparatus for Advertising and Sale Promotion
US8856894B1 (en) 2012-11-28 2014-10-07 Consumerinfo.Com, Inc. Always on authentication
EP2926306A4 (en) * 2012-11-30 2016-08-10 Xromb Inc System and method of processing payment at a point-of-sale terminal using a mobile device
US20140172551A1 (en) 2012-12-19 2014-06-19 Sas Institute Inc. Using Transaction Data and Platform for Mobile Devices
US8762272B1 (en) 2012-12-27 2014-06-24 Google Inc. Management of emails containing payments
US20140195272A1 (en) 2013-01-07 2014-07-10 Hassan Sadiq Systems and methods of gamification for a driving performance product
US9123036B2 (en) * 2013-03-01 2015-09-01 Looppay, Inc. Mobile checkout systems and methods
US20140279113A1 (en) * 2013-03-15 2014-09-18 Harish Balasubramanian System and Method to Reduce Misuse of a Financial Instrument at a Point-of-Sale Location
US9125180B1 (en) 2013-03-15 2015-09-01 Google Inc. Techniques for automatically establishing a long-lasting connection across computing devices configured for short-range wireless communication
US9286500B1 (en) 2013-03-15 2016-03-15 Square, Inc. Card reader communication method
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
GB2513340A (en) 2013-04-23 2014-10-29 Travelex Ltd Processing system
US10592890B2 (en) 2014-09-03 2020-03-17 Intel Corporation Methods and arrangements to complete online transactions
US10217103B2 (en) 2013-05-16 2019-02-26 Avant-Garde Ip Llc System, method and article of manufacture to facilitate a financial transaction without unlocking a mobile device
US9125014B2 (en) 2013-06-09 2015-09-01 Apple Inc. Location-based ticket books
US20150041534A1 (en) 2013-08-07 2015-02-12 1 Oak Technologies, LLC Electronic payment transponder
WO2015023999A1 (en) * 2013-08-15 2015-02-19 Visa International Service Association Secure remote payment transaction processing using a secure element
US20150066699A1 (en) * 2013-08-30 2015-03-05 TrueMuze, Inc. Promotional techniques for new music artists
US9588801B2 (en) 2013-09-11 2017-03-07 Intel Corporation Apparatus and method for improved lock elision techniques
US9928493B2 (en) * 2013-09-27 2018-03-27 Groupon, Inc. Systems and methods for providing consumer facing point-of-sale interfaces
US9396730B2 (en) 2013-09-30 2016-07-19 Bank Of America Corporation Customer identification through voice biometrics
US20150106260A1 (en) 2013-10-11 2015-04-16 G2 Web Services System and methods for global boarding of merchants
US9727866B2 (en) 2013-10-15 2017-08-08 Intuit Inc. Methods systems and computer program products for verifying consumer identity during transaction
US20150120559A1 (en) 2013-10-29 2015-04-30 Douglas Fisher Enhancements to transaction processing in a secure environment
US9799021B1 (en) 2013-11-26 2017-10-24 Square, Inc. Tip processing at a point-of-sale system
CA2935177C (en) 2013-12-27 2019-08-13 Square, Inc. Card reader emulation for cardless transactions
US9858572B2 (en) 2014-02-06 2018-01-02 Google Llc Dynamic alteration of track data
US9342717B2 (en) 2014-02-26 2016-05-17 Ncr Corporation Tamper detection system and method
US9767471B1 (en) 2014-03-24 2017-09-19 Square, Inc. Determining recommendations from buyer information
US9971627B2 (en) 2014-03-26 2018-05-15 Intel Corporation Enabling maximum concurrency in a hybrid transactional memory system
US8990121B1 (en) 2014-05-08 2015-03-24 Square, Inc. Establishment of a secure session between a card reader and a mobile device
US20150332223A1 (en) 2014-05-19 2015-11-19 Square, Inc. Transaction information collection for mobile payment experience
US9852410B1 (en) 2014-06-17 2017-12-26 Square, Inc. Dynamically configuring verification information at point-of-sale devices
US9589263B2 (en) 2014-06-27 2017-03-07 Paypal, Inc. Automatic payment code display system
US9652759B2 (en) 2014-07-11 2017-05-16 Google Inc. Hands-free transactions
US9166999B1 (en) 2014-07-25 2015-10-20 Fmr Llc Security risk aggregation, analysis, and adaptive control
US9530128B1 (en) 2014-08-08 2016-12-27 Square, Inc. Payment instrument verification techniques
US20160055538A1 (en) 2014-08-25 2016-02-25 Ebay Inc. Wireless beacons for reporting of applications in the foreground of a user device interface
US9436335B1 (en) 2014-09-30 2016-09-06 Amazon Technologies, Inc. Input transformative system
WO2016068854A1 (en) 2014-10-27 2016-05-06 Facebook, Inc. Facilitating sending and receiving of payments using message-based contextual prompts
US9379841B2 (en) 2014-11-17 2016-06-28 Empire Technology Development Llc Mobile device prevention of contactless card attacks
US9836732B1 (en) 2014-11-25 2017-12-05 Square, Inc. Payment handling
US10515354B1 (en) 2014-12-05 2019-12-24 Square, Inc. Discounted card not present rates following failed card present attempts
US10542380B2 (en) 2015-01-30 2020-01-21 Bby Solutions, Inc. Beacon-based media network
US11481750B2 (en) 2015-06-30 2022-10-25 Block, Inc. Pairing a payment object reader with a point-of-sale terminal
US10643245B2 (en) 2016-07-15 2020-05-05 NXT-ID, Inc. Preference-driven advertising systems and methods
BR112018004896A2 (en) 2015-09-10 2019-04-16 Verrency Holdings Limited proxy device to represent multiple credentials
US10049349B1 (en) 2015-09-29 2018-08-14 Square, Inc. Processing electronic payment transactions in offline-mode
US20170091765A1 (en) 2015-09-30 2017-03-30 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
WO2017083961A1 (en) 2015-11-19 2017-05-26 Securter Inc. Coordinator managed payments
HK1218492A2 (en) 2015-12-30 2017-02-17 演基發展有限公司 Method for controlling wireless communication between a mobile device and an electronic device
US10552821B2 (en) 2016-01-13 2020-02-04 Paypal, Inc. Dongle device for automatic pairing of payment terminal to mobile computing device
US10163107B1 (en) 2016-03-31 2018-12-25 Square, Inc. Technical fallback infrastructure
US10068235B1 (en) 2016-06-14 2018-09-04 Square, Inc. Regulating fraud probability models
US10062078B1 (en) 2016-06-14 2018-08-28 Square, Inc. Fraud detection and transaction review
US10366378B1 (en) 2016-06-30 2019-07-30 Square, Inc. Processing transactions in offline mode
US9996829B1 (en) 2016-12-27 2018-06-12 Square, Inc. System for global point-of-sale capabilities
US20180268408A1 (en) 2017-03-20 2018-09-20 Square, Inc. Configuring Verification Information At Point-of-Sale Devices
US20180315038A1 (en) 2017-04-28 2018-11-01 Square, Inc. Multi-source transaction processing

Patent Citations (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5960411A (en) * 1997-09-12 1999-09-28 Amazon.Com, Inc. Method and system for placing a purchase order via a communications network
US6738749B1 (en) * 1998-09-09 2004-05-18 Ncr Corporation Methods and apparatus for creating and storing secure customer receipts on smart cards
US6763399B2 (en) * 1998-11-10 2004-07-13 Aladdin Knowledge Systems, Ltd. USB key apparatus for interacting with a USB host via a USB port
US20030208386A1 (en) * 2000-02-25 2003-11-06 Rayner Brondrup Wireless reservation, check-in, access control, check-out and payment
US20040029569A1 (en) * 2001-12-26 2004-02-12 Vivotech, Inc. Micropayment financial transaction process utilizing wireless network processing
US20030212609A1 (en) * 2002-04-03 2003-11-13 Jeffery Blair Method of facilitating a transaction between a buyer and at least one seller
US7069240B2 (en) * 2002-10-21 2006-06-27 Raphael Spero System and method for capture, storage and processing of receipts and related data
US7305129B2 (en) * 2003-01-29 2007-12-04 Microsoft Corporation Methods and apparatus for populating electronic forms from scanned documents
US20060047576A1 (en) * 2004-08-30 2006-03-02 Nokia Corporation Automated memory and accessory purchasing agent for use in a mobile terminal
US20100169179A1 (en) * 2005-09-14 2010-07-01 Jorey Ramer Dynamic Bidding and Expected Value
US20070069013A1 (en) * 2005-09-28 2007-03-29 First Data Corporation Electronic receipting
US20100030651A1 (en) * 2005-11-04 2010-02-04 Richard Victor Matotek Mobile phone as a point of sale (POS) device
US20080215475A1 (en) * 2005-11-05 2008-09-04 Jorey Ramer Exclusivity bidding for mobile sponsored content
US20080040233A1 (en) * 2006-08-08 2008-02-14 Thomas Alfred Wildman Mobile order fulfillment
US20080167961A1 (en) * 2007-01-09 2008-07-10 Dave Wentker Contactless transaction
US20100019033A1 (en) * 2007-01-26 2010-01-28 Paul Jolivet Contactless interface within a terminal to support a contactless service
US20090065571A1 (en) * 2007-09-12 2009-03-12 Devicefidelity, Inc. Selectively switching antennas of transaction cards
US20090187492A1 (en) * 2007-10-25 2009-07-23 Ayman Hammad Location based authentication
US20090157547A1 (en) * 2007-12-12 2009-06-18 John Ruckart Financial transaction authentication servers, methods, and computer program products for facilitating financial transactions between buyers and sellers
US20090159663A1 (en) * 2007-12-24 2009-06-25 Dynamics Inc. Payment cards and devices operable to receive point-of-sale actions before point-of-sale and forward actions at point-of-sale
US20090187488A1 (en) * 2008-01-22 2009-07-23 John Shamilian Method and system for providing a service to a customer
US20090187466A1 (en) * 2008-01-23 2009-07-23 Maphook, Inc. Location-Based Information-Geo Retail Notification
US20090228325A1 (en) * 2008-03-06 2009-09-10 J. Simmons, D. Pewzner & B. Kole Dba Now On Wireless Just in time pickup or receipt of goods or services by a mobile user
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US20090313101A1 (en) * 2008-06-13 2009-12-17 Microsoft Corporation Processing receipt received in set of communications
US20090327135A1 (en) * 2008-06-26 2009-12-31 Loc Duc Nguyen Credit card paired with location identifiable device for point of service fraud detection
US20100293065A1 (en) * 2008-08-14 2010-11-18 Mike Brody System and method for paying a merchant using a cellular telephone account
US20100082445A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Smart menu options
US20100138344A1 (en) * 2008-12-02 2010-06-03 Ebay Inc. Mobile barcode generation and payment
US20100191551A1 (en) * 2009-01-26 2010-07-29 Apple Inc. Systems and methods for accessing hotel services using a portable electronic device
US8645222B1 (en) * 2009-03-20 2014-02-04 Jpmorgan Chase Bank, N.A. System and methods for mobile ordering and payment
US20110184822A1 (en) * 2010-01-22 2011-07-28 Naviit, Inc. Point of sale network router
US8135624B1 (en) * 2010-03-23 2012-03-13 Amazon Technologies, Inc. User profile and geolocation for efficient transactions
US20110307342A1 (en) * 2010-06-15 2011-12-15 Haji Faizal Method and system for generating electronic receipts from print data
US20120010938A1 (en) * 2010-07-10 2012-01-12 Bazomb, Inc. Geographically defined electronic coupon or voucher dissemination
US20120143707A1 (en) * 2010-12-07 2012-06-07 Deepak Jain Executing Reader Application
US8498900B1 (en) * 2011-07-25 2013-07-30 Dash Software, LLC Bar or restaurant check-in and payment systems and methods of their operation
US20130198076A1 (en) * 2012-01-30 2013-08-01 Ebay Inc. Systems and methods to provide check-in based payment processes

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
How Square's New Pay-With-Your-Name System Works. Mashable. May 23, 2011. Retrieved from: http://mashable.com/2011/05/23/square-card-case/#_ *
Non Patent Literature of "Square-Pay-by-Name." (see attachment). Square-Pay-by-Name relates to a youtube video that can be found at: https://www.youtube.com/watch?v=d3CYigOjx8o (also on file with the examiner). This was posted by AppJudgment on September 7, 2011. Titled: Pay with your phone! Square Card case frees you of credit cards. *
Pay-by-name purcahsing: changing the future of spending. Kmov.com St Louis; Emerlad S. Morrow. Dec. 29, 2011. *
Paying With Square's New Mobile-Payments App. All Thigns D; Lauren Goode. April 30, 2012. *
Software card emulation in NFC-enabled mobile phones: great advantage or security nightmare? Micheal Roland. June 18, 2012. *
Square Announces New Consumer Initiative: Pay with your name. Mashable; Jennifer Van Grove. May 23, 2011. Retrieved from: http://mashable.com/2011/05/23/square-pay-with-name/ *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10055721B1 (en) * 2014-05-09 2018-08-21 Square, Inc. Replicating online-transaction behavior in offline transactions
WO2017039241A1 (en) * 2015-08-28 2017-03-09 Samsung Electronics Co., Ltd. Payment information processing method and apparatus of electronic device
US20170352017A1 (en) * 2016-06-01 2017-12-07 Ronny Hay Close proximity ordering and payment system and method

Also Published As

Publication number Publication date
US11107056B2 (en) 2021-08-31
US9799021B1 (en) 2017-10-24
US9037491B1 (en) 2015-05-19
US9626669B2 (en) 2017-04-18
US20170262827A1 (en) 2017-09-14
US20150235195A1 (en) 2015-08-20
US20220058611A1 (en) 2022-02-24

Similar Documents

Publication Publication Date Title
US20220058611A1 (en) Card data output for cardless transactions
CA2935177C (en) Card reader emulation for cardless transactions
US11720872B2 (en) Methods and systems for wallet enrollment
US11829964B2 (en) Apportioning a payment amount among multiple payers
EP2637131B1 (en) Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US9824355B2 (en) Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US20150324799A1 (en) Systems and methods for randomized mobile payment
JP2014021974A (en) Method for online payment, and system and electronic device for executing the same
CN108027925B (en) Card-free payment method and system using two-dimensional code
US20140101043A1 (en) Sound-Based Payment Transactions
WO2013122678A1 (en) Obtaining instant credit at a pos with limited information
AU2015201432A1 (en) Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US20160180320A1 (en) System and method for facilitating an online transaction with a second mobile device
US9864986B1 (en) Associating a monetary value card with a payment object
US10776809B1 (en) Use of payment card rewards points for an electronic cash transfer
US20210133726A1 (en) Transaction support program and system
US20160180319A1 (en) System and method for facilitating an online transaction with a mobile device
US11893562B2 (en) Offloading a signing operation on a user device
KR102442526B1 (en) Method, termibal unit and server for payment

Legal Events

Date Code Title Description
AS Assignment

Owner name: SQUARE, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LEE, ROBERT;REEL/FRAME:033906/0704

Effective date: 20140324

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:SQUARE, INC.;REEL/FRAME:037055/0715

Effective date: 20151102

AS Assignment

Owner name: SQUARE, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:043532/0662

Effective date: 20170811

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

AS Assignment

Owner name: BLOCK, INC., CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:SQUARE, INC.;REEL/FRAME:058646/0154

Effective date: 20211209

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8