JP2017510903A - Card reader emulation for cardless transactions - Google Patents

Abstract

A method and apparatus is disclosed that allows a cardless payment transaction to be performed from a point of sale (POS) system. After the user has checked in to the merchant by using the user's mobile device, the user can simply make a payment by simply appearing at the merchant and telling his name. By emulating card reading events and blocking receipt printer output, the technology does not require customized software or hardware to support individual POS vendor specific application programming interfaces (APIs). Easily integrated into a conventional merchant POS system. [Selection] Figure 2A

Description

This application claims the benefit of US Provisional Application No. 61 / 921,374, filed Dec. 27, 2013. The contents of the above applications are incorporated herein by reference in their entirety.

  This application claims the benefit of US patent application Ser. No. 14 / 187,049 filed Feb. 21, 2014. The contents of the above applications are incorporated herein by reference in their entirety.

  Traditional credit card payment methods at restaurants and other full service retail facilities are inefficient and time consuming. For example, when a customer wishes to pay by credit card at a restaurant, it is common to first pay the waiter's attention and then request an invoice. The customer then waits for an invoice for a few minutes. Even after the waiter brings the invoice, the customer will wait a few more minutes for the waiter to return and collect the customer's credit card, and then the waiter will return with a printed receipt. Wait a few more minutes. While the customer is waiting for a receipt, the waiter takes the credit card to the point-of-sale (POS) terminal, passes the card through the card reader, and waits for the authorization signal to return and the paper receipt to be printed. When the customer receives the printed receipt from the waiter, the customer writes on the receipt as many chips as he / she wants to add, and then signs the receipt. The waiter then collects the signed receipt (usually after the customer leaves the facility) and enters the total amount of the transaction (including the tip) into the POS system.

  A restaurant that may be looking for a customer who may be in a hurry to leave the restaurant, a waiter who may be busy dealing with other customers, and a service employee who needs high efficiency to keep profits From the owner's perspective, this process is very time consuming and very inefficient.

  One or more embodiments of the present invention are illustrated by way of example in the figures of the accompanying drawings and are not intended to be limiting. In these figures, like reference numerals indicate like elements.

FIG. 1 illustrates an environment in which the card emulation techniques presented herein can be implemented. FIG. 2A illustrates various embodiments of a merchant POS system. FIG. 2B illustrates various embodiments of a merchant POS system. FIG. 3 shows an example of a card reading emulator (CRE) module used in the POS system. FIG. 4 is a flow diagram illustrating an example of a process for setting up and starting a cardless payment transaction according to the first embodiment. FIG. 5 shows an example of a graphical user interface (GUI) display generated by the merchant POS system. FIG. 6A shows operations performed in a cardless payment transaction according to the first embodiment. FIG. 6B illustrates a process that may be performed by a card reading emulator (CRE) module. FIG. 7 shows operations performed in a cardless payment transaction according to the second embodiment. FIG. 8 illustrates operations performed in connection with tip designation for a cardless payment transaction. FIG. 9 is a high-level block diagram illustrating an example of a processing system capable of performing at least some operations related to cardless transactions.

  References herein to "an embodiment," "one embodiment," and the like mean that the particular feature, function, structure, or characteristic described is included in at least one embodiment of the invention. . Such phrases appearing herein are not necessarily all referring to the same embodiment. On the other hand, the referenced embodiments are also not necessarily mutually exclusive.

  The technology presented herein is a technology that enables more efficient payments by using a payment account such as a credit card account or a debit card account. This technology eliminates the need for customers to carry physical payment cards (eg, credit cards or debit cards), and physical card swipes (or other similar physical cards) when performing payment card transactions. Reading event). The technology is particularly advantageous when applied to full service retail facilities such as restaurants. In particular, the technology facilitates a “pay-by-name” framework where customers can make payments by simply telling their names to the merchant. In addition, by emulating a card reading event and blocking the receipt printer output, the technology presented herein, as will be described further below, allows the POS vendor's unique application programming interface ( (API) can be easily integrated into virtually any conventional POS system without the need for customized software or hardware.

  In the following description, the restaurant example is used for illustrative purposes only to illustrate various aspects of the present technology. However, it should be noted that the technology presented herein is not limited to applications in restaurants or other specific types of business. In addition, the technology presented herein is not limited to use with payment cards or for financial transactions. The technology can be used for virtually any transaction that was previously initiated by or involved in the use of a physical card reader. Thus, the term “sale” as included in point of sale (POS) refers to any type of payment-oriented transaction including, for example, leasing or rental, and is not limited to actual purchases. Also, as used herein, the term “user” does not necessarily refer to an interface used by a customer, unless otherwise indicated, and as is apparent from the context. Note that it generally represents customers (as opposed to merchants).

  In certain embodiments, the techniques presented herein include the following sequence of operations, as described in more detail below. First, the customer registers for a cardless payment service. Thereafter, the customer visits the merchant and “checks in” to the merchant using a mobile payment application on the customer's mobile device (eg, smartphone or tablet computer). This check-in action triggers a series of messages and other actions that cause the customer's name and photo to appear relatively quickly on the display device of the merchant's POS terminal.

  When the customer is about to make a payment, he simply tells the merchant that he wishes to pay with the payment service (preferably by name of the service by its advertised business name). The merchant then closes the ticket or “tab” in the merchant's POS system in a conventional manner. However, when swiping the credit card through the merchant's card reader, the waiter simply taps the customer's name and photo displayed on the merchant POS terminal instead. As used herein, the term “swipe” refers to a physical card that triggers a physical card reader such as a magnetic stripe reader, smart card reader, optical code reader, radio frequency identification (RFID) reader, etc. Any method of reading.

  The card reader emulator (CRE) module in the merchant POS system allows cardless payment technology to be easily integrated into virtually any conventional POS system. This is done by emulating a physical card read event and blocking the output of the receipt printer in the merchant POS system. More specifically, as described in detail below, the CRE module responds to merchant triggered input by sending a virtual card swipe to the main POS software in the POS system. If the transaction is approved, the CRE module also blocks receipt printing. 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 the virtual copy of the receipt is displayed to the customer by the mobile payment application. For printing operations not related to cardless transactions, the CRE module simply allows the printing operation to be passed to the printer unaffected.

  Thereafter, the customer may input the amount of the chip into a mobile payment application on his mobile device. Subsequently, the CRE module instructs the merchant to enter a chip into their POS terminal as if it were a “virtual merchant copy”. Other methods of inputting tip amounts and variations in the disclosed technology are also described below.

  As described further below, the CRE module may be integrated within the merchant POS terminal or may be a separate device. If the CRC module 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 a merchant, where no actual card reading event related to a payment transaction has occurred. This invokes the (widely published) card reader API of the POS system associated with the specific card reader used by the merchant and emulates the card reader output in the output protocol used by the card reader. This is done by sending the data to be sent to the main POS application. The card reader can be, for example, a conventional magnetic stripe card reader, smart card (integrated circuit (IC) card) reader, bar code reader, quick response (QR) code reader, RFID card reader, and the like.

  After the transaction has been approved by the remote payment processing entity, the CRE module passes the main POS application (for print operations not associated with a cardless transaction. The CRE module passes those print operations unaffected by the printer. The generation of print receipts is prevented by using the (widely published) printer API of the POS terminal so as to block the print signal generated by simply allowing it. In response to the print signal, the CRE module causes a message to be sent from the merchant POS system to the remote computer system of the cardless payment service, which displays a virtual receipt for the transaction to the mobile payment application. To respond by sending a message to the consumer's mobile device.

  FIG. 1 illustrates an environment in which cardless payment technology can be implemented. The environment includes the merchant POS system of merchant 100 and mobile device 102 of user 101 (also referred to as a “customer” or “consumer”). Mobile device 102 may be, for example, a smartphone, tablet computer, notebook computer, or any other form of mobile processing device. The mobile payment application 120 runs on the user's mobile device 102. The environment also includes a merchant acquirer computer system 114, an issuing bank computer system 118, a card payment network computer system 116, and a payment service computer system 108 (hereinafter "payment service system 108"). Each of the above computer systems can include one or more separate physical computers and / or other processing devices, and in the case of multiple devices, each other via one or more wired and / or wireless networks. Can be connected. All the above devices are connected to each other via an internal network 106, which may be the Internet and one or more wireless networks (eg, a WiFi network and / or a cellular telecommunications network), They can be included.

  The environment shown in FIG. 1 is for both conventional credit card transactions (ie, those involved in reading a customer's physical card at the merchant location) and cardless transactions according to the present technology presented herein. It can correspond to. In conventional credit card transactions, for example, the merchant swipes the user's credit card through a card reader in the POS system 104. The POS system 104 stores the data read from the card (eg, the cardholder's name, credit card number, expiration date, card verification value (CVV)) into the merchant's acquirer computer system 114 (hereinafter “acquirer 114”). ). The acquirer 114 transmits this data to a card payment network (e.g., Visa or MasterCard) computer system 116 (hereinafter "card payment network 116"), which sends the data to the issuing bank's computer. Transfer to system 118 (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 to that described above.

  The cardless payment service operates the payment service system 108 to facilitate cardless payment transactions. The user's mobile device 102 may communicate with the payment service system 108 over the internal network 106. Payment service system 108 includes one or more server computers programmed to process payment transactions involving users enrolled in a cardless payment service. The payment service system 108 also stores information such as registered credit card numbers, debit card numbers, bank accounts, user accounts, user identification information or other sensitive information. The payment service system 108 is also responsible for sending information about the merchant with a cardless payment system account to the user's mobile device 102.

  2A and 2B illustrate another embodiment of the merchant POS system 104. Note that certain components that are not relevant 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, for example, the main POS application 201. In this specification, the main POS module 201 is hereinafter assumed to be the main POS application 201 for ease of explanation. Alternatively, the main POS module 201 may be a hardware component (which may include a POS application and / or other POS software). The display 202 can be, for example, a touch screen display or a conventional non-touch display (in which case the merchant POS system 104 is considered to include 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 smart card reader, and a receipt printer 205 for printing transaction receipts.

  In accordance with the techniques presented herein, 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 via the main POS application 201. The CRE module 203 can be software, hardware or a combination thereof. As shown in FIG. 2A, the CRE module 203 may be logically separated from the main POS module, but may operate “in conjunction” with the main POS module. Alternatively, the CRE module 203 may be an integral part of the main POS application 201 as shown in FIG. 2B. Other alternatives include binding the virtual USB device 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. First, the CRE module 203 emulates a card read event to the main POS module by using protocols and APIs associated with the card reader. Next, the printer 205 API is used to block the print signal generated by the main POS application 201 for the printer 205 and cause the virtual receipt to be sent to the user's mobile device 102. Trigger the operation. These features allow customers to make credit card or debit payments in cardless transactions without having to customize the software or hardware to support individual POS vendor specific APIs.

  Therefore, 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 involved in emulating a card reading event to the main POS application 201. The receipt manager 302 is responsible for blocking a print signal generated by the main POS application 201 and triggering a series of operations to cause a virtual receipt to be sent to the user's mobile device 102. Dynamic Link Library (DLL) injection is used to block and modify communication between the main POS application 201 and Windows standard USB APIs (eg, used for magnetic stripe card readers) and printer APIs. obtain.

  Note that a given POS system may be integrated with a card processing terminal instead of a magnetic stripe reader. In these examples, the CRE module 203 may simply emulate a 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 (eg, via an online application store) and the CRE module 203 is installed on the merchant's POS. Installed on system 104. In addition, the user is required to create a user account for the payment service system 108. This is done by the user using the mobile payment application 120 or mobile web browser from the mobile device 102, or using another processing device such as a home computer with a conventional web browser. Can do.

  In certain embodiments, the user enters a name, account password, and contact information (eg, email address). Before a cardless payment transaction can be performed, the user also enters into the payment service system 108 sufficient financial account information to make the transaction. For example, in the case of a credit card account, the user may enter a credit card issuer, credit card number, and expiration date into the payment service system 108. Also, CVV and email address may be requested. However, a financial account can also be associated with a debit card, prepaid card, or other third party financial account.

  In some embodiments, the payment service requires the user to provide additional personal identification information, such as the user's photo, before cardless transactions are permitted. The user's photo will be provided to the merchant later (eg, via the CRE module 203) so that the merchant can compare the photo with the person at the merchant's location. In addition, the payment service may require a personal identification number (PIN) entered by the user. Other requirements can also be added to increase security. Data related to the user's account may be stored in a database (not shown) of the payment service system 108.

  In operation, the user carries the mobile device 102 with the mobile payment application 120 installed, and the merchant is using the POS system 104 as described above. The mobile payment application 120, the CRE module 203, the payment service 108, and the main POS application 201 interact to allow payment by a user cardless transaction. This is achieved in part by determining the relative position 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 relatively high 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, for example, by using radio frequency (RF) signal triangulation or other known techniques. The merchant's location is assumed to be well known and pre-stored in the payment service system 108.

  The cardless payment service can predetermine a distance, eg, a radial distance (eg, 500 feet) from the merchant's location, so that the mobile device 102 is within that distance from a given merchant and that When checking in to a merchant, the system can infer that the user is actually at the merchant. If the user is located within a predetermined distance from the merchant, the user is allowed to “check in” to the merchant by using the mobile payment application 120. This can be done, for example, by the user pressing a simple “check-in” button or the like on the display of the mobile device 102. The check-in function can be thought of as indicating the user's consent to perform a cardless transaction with that particular merchant and can effectively “open a tab” to the merchant. Alternatively, the mobile payment application 120 may be configured to automatically check in the user when the user is within a predetermined distance from the merchant. On the other hand, if the mobile device 102 is located farther than a predetermined distance from a particular merchant, the user is not allowed to check in to 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 process for setting up and initiating a cardless payment transaction, according to an embodiment of the technology presented herein. The process relates to the relationship between the user's mobile device 102, payment service system 108 and merchant POS system 104. Payment service system 108 may be configured to send and receive communications with mobile device 102 and merchant POS system 104. The communication may be encrypted using a secure protocol embedded in the mobile device 102, payment service system 108 and merchant POS system 104. In some embodiments, the processing is performed through a mobile payment application 120 installed on the mobile device 102 and a CRE module 203 installed on the merchant POS system 104.

  First, a user inputs a request to the mobile device 102 to identify a merchant capable of performing a cardless payment transaction. 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 internal network 106. The request may be accompanied by location information of the mobile device 102, which is determined by the mobile device 102, for example. 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 merchant location information. The merchant and merchant location information identification information is transmitted to the mobile device 102.

  In some embodiments, the user checks in with 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, the merchant and merchant location information identification information is transmitted to the mobile device 102. The mobile device 102 determines whether it is within a predetermined distance from the merchant (step 404). If the mobile device 102 does not know the merchant's current location, or if the merchant has recently updated its location information, the merchant's location can be pushed or pulled to the mobile device 102. Alternatively, location information of mobile device 102 may be provided to payment service system 108 if the user has opted in to sharing location information. Here, the payment service system 108 determines 30 distances between the merchant and the mobile device 102.

  As described above, if the mobile device 102 determines that the user's mobile device 102 is not within a predetermined distance (eg, 500 feet), the mobile device 102 indicates that the user cannot be checked in. A message is displayed (step 408). In that case, the merchant cannot charge the user's financial account using a cardless payment transaction. On the other hand, if the mobile device 102 is within a predetermined distance, the mobile device 102 transmits an indicator indicating that it is close to the payment service system 108 (step 406).

  The payment service system 108 receives the indication indicating the proximity, and transmits the indication indicating the presence of the mobile device 102 and the personal identification information to the merchant POS system 104 (step 410). In some embodiments, the personal identification information transmitted to the merchant POS system 104 includes the user's name, photo, and financial account number (eg, credit card number or debit card number). The financial account number may be encrypted so that it can only be decrypted by the CRE module 203 so that the financial account number can be displayed by the POS system or otherwise accessed by the merchant. It becomes impossible.

  Upon receipt of this information, the merchant POS system 104 displays a tab (a list of items ordered by the customer) on a graphical user interface (GUI) on the display 202 of the system 104 (step 412). The user identification information (for example, name and photo) is displayed (step 414). An example of such a GUI is shown in FIG. In the illustrated example, the right side portion 501 of the display is a customer account section that includes a separate subsection 502 for each customer checking into the merchant via a cardless payment service. Customer account section 501 may be generated, for example, by CRE module 203 or by other merchant POS software. The amount each customer needs to pay can be displayed in a subsection 502 corresponding to that customer on the display.

  The left part 503 of the GUI is generated by the main POS application 201 and includes, for example, the names and images of items that can be ordered / purchased and their prices. In other embodiments, user information displayed by the CRE module 203 may be provided in a completely separate window from the main POS application 201. Thus, in some embodiments, via the GUI, the merchant may select items that the customer has requested to purchase. The GUI may be configured to associate individual prices with each of the merchant's items and may automatically sum the total transaction amount that the customer needs to pay.

  In some embodiments, the display of the customer account section 502 may be automatically triggered when a customer enrolled in a cardless payment service checks into the merchant. Alternatively, the display may be triggered by a soft button on the GUI generated by the main POS application 201. Such soft buttons may be generated by the CRE module 203 and may automatically change the appearance when a customer registered with the cardless payment service checks into the merchant.

  In yet another embodiment, a hardware button or other similar physical control is externally connected to the merchant POS terminal (eg, via a USB port or other conventional interface) to communicate with the CRE module 203. Is provided on a separate hardware module (not shown) that triggers the display of the customer account section 502. The other hardware module may emulate a USB keyboard to generate a key combination that allows the merchant POS system 104 to enter the desired state as described above. In an extension of this approach, the hardware module may also include a storage device (eg, USB flash drive) that includes the CRE module 203. A button or other control on the other hardware module can be activated to display a notification on the display of the POS system 104 and / or the button is lit when the customer checks in to the merchant. obtain.

  A customer (user) may authorize payment of his account by verbally informing the merchant. For example, a user named John Smith can simply tell the merchant that “I will pay with John Smith”. Before or after the user authorizes payment of the account, the merchant is the user, for example, by confirming that the photo displayed on the merchant POS system 104 matches the user who is there. This is verified (step 416). Assuming that the photos match, the merchant then selects the user's account (eg, by tapping the corresponding section 501 on the GUI) when the customer attempts to make a payment, thereby A cardless payment transaction is triggered (step 418).

  In one embodiment, the cardless payment transaction involves the following operations as shown in FIG. In response to the merchant providing user input 601 to trigger a cardless payment transaction, the CRE module 203 sends the card read event data 602 associated with the consumer to the main POS application 201, thereby providing a card Emulate a reader. Card read event data 602 appears to the main POS application 201 as data resulting from a card read event, even though no actual card read event has occurred. The CRE module 203 does this by calling the API of the card reader of the main POS application and sending data in the output protocol of the card reader 204. In an embodiment consistent with FIG. 4, the CRE module 203 receives the customer's actual card payment account number (eg, credit card number) from the payment service system 108 in advance when the customer checks in with the merchant. . Therefore, not only the account number but also the consumer's name, card expiration date and CVV are provided to the main POS application 201 by the CRE module 203 in the card reader 204 protocol. In another embodiment, further described below, the CRE module 203 or payment service system 108 generates a one-time use payment card number for the transaction, and uses the payment card number for the consumer's actual credit. It passes to the main POS application 201 instead of the card number. Since the CRE module 203 is only required to allow a simulated card swipe to be sent to the main POS application 201, no implementation of the entire card reader protocol is required. In one embodiment, the CRE module 203 is programmed with a DUKPT (Derived Per Derived Unique Key) key for a merchant acquirer to emulate a card swipe. Other data related to the customer may also be provided if required by the card reader 204 API.

  When the main POS application 201 receives the card reading event data 602 from the CRE module 203, the main POS application 201 transmits the card reading event data included in the standard payment authorization request 603, and the standard payment authorization request 603 is transferred to the issuer 118. The In practice, the payment authorization request 603 may first be actually sent to the merchant's acquirer 114, which forwards the request to the card payment network 116 or creates a corresponding new request. Then, the card payment network 116 forwards the request to the issuer 118 or sends a corresponding new request. However, these intermediate communications are omitted from FIG. 6 for simplicity of explanation.

  If the transaction has been approved by the issuer 118, the issuer 118 returns a standard payment authorization (approval) message 604 to the merchant's main POS application 201 using the reverse communication path. 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 accesses the printer API of the main POS application 201 to cut off the print signal before the print signal can reach the printer 205. In response to detecting the print signal, the CRE module 203 also sends a message 606 (via the internal network 106) to the payment service system 108 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. Subsequently, the mobile payment application 120 on the mobile device 102 displays a virtual receipt to the user. The virtual receipt may include all the information that will be included in the printed receipt of the card transaction, including the amount charged, the name of the consumer, the date and time of the transaction, and so on. Thereafter, the user can optionally input the amount of the chip. Other methods of handling chips in this process are discussed further below.

  In certain embodiments, the payment service system 108 analyzes the receipt data before sending the virtual receipt to the mobile payment application 120 to determine whether the processed transaction is normal. The payment service system 108 may also analyze the receipt data to identify various semantic factors including the total transaction amount and items ordered by the customer. Thus, in such embodiments, the virtual receipt that payment service system 108 sends to mobile device 102 also includes a breakdown of these elements, which can be displayed to the user. Alternatively, the analysis can be performed by the CRE module 203.

  It should be noted that most POS systems use a relational database such as Sybase or Microsoft SQL Server to store their payment card transaction data. Payment service system 108 can capture most if not all substantial transaction data by analyzing receipts as described above. Nevertheless, it may be desirable to synchronize the payment service system 108 database with the merchant POS database. Among other benefits, payment service 108 can provide backup storage for the merchant.

  FIG. 6B is a diagram illustrating an example of processing that can be executed by the CRE module 203 in the above-described embodiment. The process begins when the CRE module 203 detects a user input indicating the intention to initiate a payment transaction involving the customer, specifying the checked-in customer (step 622). In response to user input, the CRE module 203 outputs the data emulating the output of the card reader 204 to the main POS application 201 without the actual card reading event that occurs in connection with the payment transaction. A transaction is started (step 624). After the transaction is approved by a payment processing entity (eg, issuer 118), CRE module 203 detects the print signal generated by main POS module 201 for generating a payment transaction (step 626). Module 203 prevents printed receipts from being generated by blocking the print signal (step 628). The print signal includes receipt data for allowing a receipt to be printed by the receipt printer 205. In response to the print signal, the CRE module 203 sends a first message containing at least a portion of the receipt data to the payment service system 108 (step 630), thereby sending the second message to the payment service system 108 to the customer. To the mobile device 102. The second message allows 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 the user's actual payment card number from the payment service system 108 and passes the number to the main POS application 201 when a transaction is initiated. However, in another embodiment, the cardless payment service generates a one-time use payment card number for the transaction, and as described above, the payment card number is the consumer's actual credit card number. Instead, it is passed to the main POS application 201. The one-time use card number may be generated by the payment service system 108 or by the CRE module 203 in response to a user checking in with the merchant. In this embodiment, the payment service operating the payment service system 108 essentially functions as a credit card issuer from the merchant perspective. The merchant POS system 104 charges the one-time use credit card number, and then the payment service charges the consumer's actual credit card number stored in the payment service system 108. The initial setup process in this embodiment is that, in step 410, the payment service system 108 sends a one-time use payment account number to the merchant POS system 104 instead of sending the consumer's actual credit card number, It may be substantially the same as that of FIG. The one-time use account number has a format that the merchant POS system 104 can recognize, such as a standard credit card or debit card format.

  A cardless transaction using a one-time payment account number may involve the following operations, as shown in FIG. In response to the merchant 100 providing user input 701 to trigger a cardless payment transaction, the CRE module 203 transmits the data 702 associated with the consumer to the main POS application 201, thereby providing a card reader. Emulate 204. The data 702 appears to the main POS application 201 to relate to the card read event even though no actual card read event has occurred. This can be done in the manner described above. In addition to the one-time payment account number, the consumer's name, account expiration date and CVV are also provided to the main POS application 201 by the CRE module 203 in the card reader protocol. Other relevant data may also be provided if required by the card reader API.

  Upon receiving the card reading event data 702 from the CRE module 203, the main POS application 201 transmits the card reading event data included in the standard payment authorization request 703. In this embodiment, the standard payment authorization request 703 includes: Transferred to payment service system 108 representing the issuer. In practice, the payment authorization request 703 may first be actually sent to the merchant's acquirer 114, which forwards the request to the card payment network 116 or creates a corresponding new request. Then, the card payment network 116 forwards the request to the payment service system 108 or generates a new request corresponding to the payment service system 108. However, these intermediate communications are omitted from FIG. 7 for simplicity of explanation.

  If the transaction is authorized by the payment service system 108, the payment service system 108 returns a standard payment authorization (approval) message 704 to the merchant's main POS application 201 using the reverse communication path. . 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 blocks the print signal 705 and prevents the print signal 705 from reaching the printer 205 as described above. In this embodiment, the payment service system 108 already knows that the transaction is approved, so there is no need to receive a signal from the CRE module 203 before sending the virtual receipt. Accordingly, at about the same time as or immediately after payment service system 108 sends payment authorization signal 704, payment service system 108 sends message 706 containing a virtual receipt for the transaction to customer's mobile device 102. Subsequently, the mobile payment application 120 on the customer's mobile device 102 displays a virtual receipt to the user.

  The payment system 108 then sends a payment request 707 to the customer's actual payment card issuer 118. The actual payment card information is received and stored in advance by the payment service system 108 when the customer registers for the cardless payment service. Subsequently, payment service system 108 receives payment 708 from issuer 118.

  The technology presented herein also allows customers to give tips to merchants (eg, waiters). There are various ways to accomplish this. In one approach, as shown in FIG. 8, when a virtual receipt is displayed to the customer 101 by the mobile device 102, the customer pays the tip amount by the mobile payment application 120 running on the mobile device 102. (801). Thereby, the customer inputs the amount of the chip to the mobile payment application 120 (802). The mobile payment application 120 then sends a message 803 containing the tip amount to the payment service system 108. Subsequently, the payment service system 108 sends a message 804 indicating the amount of the chip to the CRE module 203 in the merchant POS system 104. The CRE module 203 then triggers the display of the merchant POS system 104 to display the amount of the chip on the display of the merchant POS system (805). After viewing the displayed tip amount, the merchant 100 inputs the total transaction amount (for example, the invoice amount + tip) to the main POS application 201 in a conventional manner (806). Thereafter, the main POS application 201 processes the transaction in accordance with the conventional transaction capturing process (807).

  In another approach, rather than requiring the merchant to copy the amount of the chip over to the main POS application 201, the CRE module 203 may have a sequence of user inputs to the main POS application 201 (eg, touch screen or keypad). In order to cause the main POS application 201 to input an appropriate state for inputting the amount of chips (or the total transaction amount), and then to input the amount to the main POS application 201. Simulate the appropriate user input sequence. For example, the CRE module 203 can call an API of an input device (eg, touch screen or keyboard / keypad) of a POS system to communicate the amount of the chip to the main POS application 201, thereby enabling the chip The POS application 201 appears 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 (possibly an employee of the merchant) and causes the CRE module 203 to verify the identity via the GUI during daily attendance. After a cardless payment transaction is authorized as described above, the CRE module 203 causes the display to output a prompt asking which waiter should receive the chip. The waiter taps his name on the display. Subsequently, the CRE module 203 sends a message indicating this selection to the payment service system 108. The payment service system 108 then pushes the chips directly to the waiter, for example, via an automatic clearing house (ACH) or debit.

  FIG. 9 shows an example of a processing device 900 that may represent any of the devices described above, such as mobile device 102, merchant POS system 104, payment service system 108, acquirer system 114, card payment network 116, or issuer system 118. It is a high-level block diagram. As described above, any of these systems can include two or more processing devices, as shown in FIG. 9, that are coupled to each other via a network or networks. It may be.

  In the illustrated embodiment, the processing system 900 includes one or more processors 910, a memory 911, a communication device 912, and one or more input / output (I / O) devices 913, all of which are interconnects 914. Are connected to each other through. Interconnect 914 may be one or more of conductive traces, buses, point-to-point connections, controllers, adapters, and / or other conventional connection devices, and may include one or more of them. The processor 910 may be, for example, one or more of a general purpose programmable microprocessor, microcontroller, application specific integrated circuit (ASIC), programmable gate array, etc., or a combination of such devices. Or a combination of such devices may be included. The processor 910 controls the overall operation of the processing device 900. The memory 911 may be one or more physical storage devices and may include one or more physical storage devices. The physical storage device may be in the form of random access memory (RAM), read only memory (ROM) (erasable and programmable), flash memory, small hard disk drive or other suitable type of storage device. It may well be a combination of such devices. Memory 911 may store data and instructions that configure processor 910 to perform operations in accordance with the techniques described above. The communication device 912 may be, for example, an Ethernet adapter, a cable modem, a wireless LAN adapter, a cellular transceiver, a Bluetooth transceiver, etc., or a combination thereof. Depending on the particular nature and purpose of the processing device 900, the I / O device 913 may be a display (which may be a touch screen display), an audio speaker, a keyboard, a mouse or other pointing device, a microphone, a camera, etc. Devices may be included.

  Unless contrary to physical possibilities, (i) the above methods / steps may be performed in any order and / or in any combination, and (ii) components of each embodiment It is envisaged that they may be combined in any way.

  The techniques presented above may be implemented by programmable circuitry programmed / configured by software and / or firmware, or entirely by dedicated circuitry, or a combination of such forms. Such dedicated circuitry (if any) may be in the form of, for example, one or more application specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), and the like.

  Software or firmware for implementing the techniques presented herein may be stored on a machine-readable storage medium and executed by one or more general purpose or special purpose programmable microprocessors. The term “machine-readable medium” as used herein includes any mechanism that can store information in a form accessible by a machine (eg, a computer, a network device, a mobile phone, a personal Digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, the medium accessible to the machine is a recordable / non-recordable medium (for example, read-only memory (ROM), random access memory (RAM); magnetic disk storage medium; optical storage medium; flash memory device, etc.) Is included.

  It should be noted that any and all of the embodiments described above can be combined with each other. However, this is not the case where there is a separate description above, or where any such embodiment may be mutually exclusive in function and / or structure.

  Although the invention has been described with reference to specific exemplary embodiments, the invention is not limited to the described embodiments, and can be modified and changed within the spirit and scope of the appended claims. It will be appreciated that it can be implemented. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Examples Thus, in summary, the above disclosure includes the following examples.
1. In a point-of-sale (POS) system, detecting a user input input via a user interface of the POS system, wherein the user input specifies a consumer and a payment transaction involving the consumer A step showing the intention to start
In response to the user input, output data emulating the physical card reader output associated with the card read event to a POS module in the POS system without an actual card read event occurring in connection with the payment transaction. Initiating the payment transaction in the POS system by:
Preventing a printed receipt for the transaction from being generated by blocking a print signal for operating a receipt printer generated by the POS module after the transaction is approved by a payment processing entity. Steps wherein the print signal includes receipt data;
Responsive to the print signal, sending a first message from the POS system to cause a second message to be sent to the consumer's mobile device, the second message comprising: And enabling the mobile device to output a virtual receipt for the payment transaction to the consumer.
2. Example 1 of outputting data that emulates the output of the physical card reader includes transmitting data that emulates the output of the card reader to the POS module in the protocol of the card reader. The method described in 1.
3. The method of example 1, wherein outputting data emulating the output of the physical card reader includes invoking an application programming interface (API) of the card reader.
4). Causing the second message to be transmitted to the consumer's mobile device, causing the remote entity to transmit the second message to the consumer's mobile device; The method of example 1, comprising transmitting to the remote entity via
5. The method of example 1, wherein the second message includes data representing the virtual receipt.
6). The method of example 1, wherein outputting data emulating the output of the physical card reader comprises providing a payment account identifier of the consumer payment card to the POS module.
7). Outputting data emulating the output of the physical card reader includes providing the POS module with a one-time use account identifier for use only in the payment transaction involving the consumer. The method of example 1, wherein the one-time use account identifier is not an account identifier of the consumer payment card, but is in an account identifier format identifiable by the POS module.
8). The method of example 1, further comprising analyzing the receipt data in the print signal to identify semantic elements of the receipt data.
9. Detecting in a processing system user input indicating an intention to initiate a transaction associated with a person;
In response to the user input, initiating a transaction by emulating a card reading associated with the person without an actual card reading event occurring for the transaction.
10. The method of example 9, wherein the transaction is a financial transaction.
11. The method of example 10, wherein the transaction is a payment transaction.
12 10. The method of example 9, wherein the emulating includes transmitting data that emulates a physical card reader output to an application in the physical card reader protocol.
13. Detecting a signal indicating that the transaction has been approved;
Responsive to the signal to the mobile device to prevent generation of a printed record of the transaction and to allow the mobile device of the person to output a virtual record of the transaction to the person. The method of example 9, further comprising: allowing a message to be sent.
14 Preventing generation of a printed record of the transaction includes blocking a print signal for operating a printer, and the print signal enables the record of the transaction to be printed by the printer. 14. The method of example 13, including data to do.
15. Detecting a user input indicating an intention to initiate a financial transaction involving a consumer, and in response to the user input, for the payment transaction without an actual card read event occurring for the payment transaction. A card reader emulator that initiates the financial transaction by outputting data emulating a card read event;
Preventing the generation of a printed receipt for the financial transaction by preventing a printed signal from being communicated to a printer associated with the payment transaction, wherein the consumer's mobile device is a virtual receipt for the financial transaction. And a receipt manager that allows a message to be sent to the consumer's mobile device to enable output.
16. The apparatus of example 15, wherein the card reader emulator is configured to emulate the output of the physical card reader by calling an application programming interface (API) of the card reader.
17. The apparatus of example 15, wherein the receipt manager is configured to analyze the receipt data in the print signal to identify semantic elements of the receipt data.
18. A processor;
A memory coupled to the processor and storing a POS module executable by the processor, the POS module configured to process a payment transaction and a card read event from a physical card reader Receiving the resulting card data and causing the card data to be transmitted over a network to a remote authorization entity in response to the card read event;
A user input device coupled to the processor for receiving user input designating the consumer, wherein the user input indicates an intention to initiate a payment transaction involving the consumer When,
Outputting card read event data for a payment transaction to the POS module to detect the user input and in response to the user input, without an actual card read event occurring for the payment transaction. A point-of-sale (POS) system including a card reader emulator (CRE) module configured to emulate the physical card reader.
19. The CRE module is further configured to prevent a printed receipt for the payment transaction from being generated by preventing a print signal from being communicated to a printer associated with the payment transaction. And is configured to send a first message from the POS system to cause a second message to be sent to the consumer's mobile device, the second message being received by the mobile device The POS system of Example 18, which is intended to allow a virtual receipt for the payment transaction to be output to the consumer.
20. The CRE module sends the first message to the remote entity over a network to cause the remote entity to send the second message to the consumer's mobile device. The POS system of example 19, wherein the POS system is configured to send the second message to a device, the second message including data representing the virtual receipt.
21. The POS system of Example 18, wherein the CRE module is configured to emulate the output of a physical card reader by calling a card reader application programming interface (API).
22. The CRE module is configured to emulate the output of the physical card reader by providing the POS module with a one-time use account identifier for use only in the payment transaction involving the consumer. The POS system of Example 18, wherein the one-time use account identifier is not in the consumer's payment card account identifier, but is in an account identifier format identifiable by the POS module.
23. The POS system of example 18, wherein the CRE module is further configured to analyze the receipt data in the print signal to identify semantic elements of the receipt data.
24. The POS system of Example 18 wherein the CRE module is a component of the POS module.
25. The POS system of example 18 wherein the CRE module is logically separated from the POS module.

Claims (25)

In a point-of-sale (POS) system, detecting a user input input via a user interface of the POS system, wherein the user input specifies a consumer and a payment transaction involving the consumer A step showing the intention to start
In response to the user input, output data emulating the physical card reader output associated with the card read event to a POS module in the POS system without an actual card read event occurring in connection with the payment transaction. Initiating the payment transaction in the POS system by:
Preventing a printed receipt for the transaction from being generated by blocking a print signal for operating a receipt printer generated by the POS module after the transaction is approved by a payment processing entity. Steps wherein the print signal includes receipt data;
Responsive to the print signal, sending a first message from the POS system to cause a second message to be sent to the consumer's mobile device, the second message comprising: And enabling the mobile device to output a virtual receipt for the payment transaction to the consumer.   Outputting data that emulates the output of the physical card reader includes transmitting data that emulates the output of the card reader to the POS module in a protocol of the card reader. The method according to 1.   The method of claim 1, wherein outputting data that emulates the output of the physical card reader comprises invoking an application programming interface (API) of the card reader.   Causing the second message to be transmitted to the consumer's mobile device, causing the remote entity to transmit the second message to the consumer's mobile device; The method of claim 1 comprising transmitting to the remote entity via   The method of claim 1, wherein the second message includes data representing the virtual receipt.   The method of claim 1, wherein outputting data emulating the output of the physical card reader comprises providing a payment account identifier of the consumer payment card to the POS module.   Outputting data emulating the output of the physical card reader includes providing the POS module with a one-time use account identifier for use only in the payment transaction involving the consumer. The method of claim 1, wherein the one-time use account identifier is not in the consumer payment card account identifier, but in an account identifier format identifiable by the POS module.   The method of claim 1, further comprising analyzing the receipt data in the print signal to identify semantic elements of the receipt data. Detecting in a processing system user input indicating an intention to initiate a transaction associated with a person;
In response to the user input, initiating a transaction by emulating a card reading associated with the person without an actual card reading event occurring for the transaction.   The method of claim 9, wherein the transaction is a financial transaction.   The method of claim 10, wherein the transaction is a payment transaction.   The method of claim 9, wherein the emulating includes transmitting data that emulates a physical card reader output to an application in a protocol of the physical card reader. Detecting a signal indicating that the transaction has been approved;
Responsive to the signal to the mobile device to prevent generation of a printed record of the transaction and to allow the mobile device of the person to output a virtual record of the transaction to the person. 10. The method of claim 9, further comprising: allowing a message to be transmitted.   Preventing generation of a printed record of the transaction includes blocking a print signal for operating a printer, and the print signal enables the record of the transaction to be printed by the printer. The method of claim 13, comprising data for: Detecting a user input indicating an intention to initiate a financial transaction involving a consumer, and in response to the user input, for the payment transaction without an actual card read event occurring for the payment transaction. A card reader emulator that initiates the financial transaction by outputting data emulating a card read event;
Preventing the generation of a printed receipt for the financial transaction by preventing a printed signal from being communicated to a printer associated with the payment transaction, wherein the consumer's mobile device is a virtual receipt for the financial transaction. And a receipt manager that allows a message to be sent to the consumer's mobile device to enable output.   The apparatus of claim 15, wherein the card reader emulator is configured to emulate the output of the physical card reader by calling an application programming interface (API) of the card reader.   The apparatus of claim 15, wherein the receipt manager is configured to analyze the receipt data in the print signal to identify semantic elements of the receipt data. A processor;
A memory coupled to the processor and storing a POS module executable by the processor, the POS module configured to process a payment transaction and a card read event from a physical card reader Receiving the resulting card data and causing the card data to be transmitted over a network to a remote authorization entity in response to the card read event;
A user input device coupled to the processor for receiving user input designating the consumer, wherein the user input indicates an intention to initiate a payment transaction involving the consumer When,
Outputting card read event data for a payment transaction to the POS module to detect the user input and in response to the user input, without an actual card read event occurring for the payment transaction. A point-of-sale (POS) system including a card reader emulator (CRE) module configured to emulate the physical card reader.   The CRE module is further configured to prevent a printed receipt for the payment transaction from being generated by preventing a print signal from being communicated to a printer associated with the payment transaction. And is configured to send a first message from the POS system to cause a second message to be sent to the consumer's mobile device, the second message being received by the mobile device The POS system of claim 18 for enabling a virtual receipt for the payment transaction to be output to the consumer.   The CRE module sends the first message to the remote entity over a network to cause the remote entity to send the second message to the consumer's mobile device. 20. The POS system of claim 19, wherein the POS system is configured to send the second message to a device, the second message including data representing the virtual receipt.   The POS system of claim 18, wherein the CRE module is configured to emulate a physical card reader output by calling a card reader application programming interface (API).   The CRE module is configured to emulate the output of the physical card reader by providing the POS module with a one-time use account identifier for use only in the payment transaction involving the consumer. 19. The POS system of claim 18, wherein the one-time use account identifier is not an account identifier of the consumer payment card, but is in an account identifier format identifiable by the POS module.   The POS system of claim 18, wherein the CRE module is further configured to analyze the receipt data in the print signal to identify semantic elements of the receipt data.   The POS system of claim 18, wherein the CRE module is a component of the POS module.   The POS system of claim 18, wherein the CRE module is logically separated from the POS module.

Images