WO2015100385A1 - Card reader emulation for cardless transactions - Google Patents
Card reader emulation for cardless transactions Download PDFInfo
- Publication number
- WO2015100385A1 WO2015100385A1 PCT/US2014/072285 US2014072285W WO2015100385A1 WO 2015100385 A1 WO2015100385 A1 WO 2015100385A1 US 2014072285 W US2014072285 W US 2014072285W WO 2015100385 A1 WO2015100385 A1 WO 2015100385A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transaction
- pos
- payment
- recited
- module
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/209—Specified transaction journal output feature, e.g. printed receipt or voice output
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/047—Payment circuits using payment protocols involving electronic receipts
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3224—Transactions dependent on location of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment 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/351—Virtual cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
Definitions
- 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.
- 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.
- 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.
- 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 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.
- 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. Initially, 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.
- 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.
- IC integrated circuit
- QR quick response
- 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
- 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 (CW)) to the computer system 114 of the merchant's acquirer (hereinafter "acquirer 114").
- the card e.g., the cardholders name, credit card number, expiration date and card verification value (CW)
- 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.
- 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
- main POS application 201 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.
- standard Windows USB APIs e.g., used for a magnetic stripe card reader
- printer APIs printer APIs.
- 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 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
- 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.
- 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).
- the mobile payment application 120 running on the user's mobile device 102
- 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.
- 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
- 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.
- 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 CW 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.
- 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. 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 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.
- the parsing can be performed by the CRE module 203.
- 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
- 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
- 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
- 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 CW 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
- the payment service system 108 sends a standard payment authorization (approval) message 704 back to the merchant's main POS application 201 , using a
- 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. 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.
- 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. [0063] 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 I/output (I/O) devices 913, all coupled to each other through an I/output (I/O) devices 913, all coupled to each other through an I/output
- 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,
- 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
- 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.
- Such special-purpose circuitry 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.
- 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.
- the above disclosure includes the following examples.
- a method comprising:
- POS point-of-sale
- 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;
- preventing generation of a printed receipt for the 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.
- a method as recited in example 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. A method as recited in example 1 , wherein outputting data that emulates output of a physical card reader comprises invoking a card reader application programming interface (API).
- API application programming interface
- 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.
- 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.
- a method as recited in example 1 further comprising: parsing the receipt data in the print signal to identify semantic elements of the receipt data.
- a method comprising:
- a method as recited in example 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.
- a method as recited in example 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.
- 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.
- card reader emulator is configured to emulate output of the physical card reader by invoking a card reader application programming interface (API).
- API application programming interface
- a point-of-sale (POS) system comprising:
- 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;
- 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.
- CRE card read emulator
- a POS system as recited in example 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.
- the CRE module is configured to emulate output of a physical card reader by invoking a card reader application programming interface (API).
- API application programming interface
- the CRE module is a component of the POS module.
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14875157.1A EP3077970A4 (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 |
CA2935177A CA2935177C (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 |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361921374P | 2013-12-27 | 2013-12-27 | |
US61/921,374 | 2013-12-27 | ||
US14/187,049 US9037491B1 (en) | 2013-11-26 | 2014-02-21 | Card reader emulation for cardless transactions |
US14/187,049 | 2014-02-21 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015100385A1 true WO2015100385A1 (en) | 2015-07-02 |
Family
ID=53479680
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2014/072285 WO2015100385A1 (en) | 2013-12-27 | 2014-12-23 | Card reader emulation for cardless transactions |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP3077970A4 (en) |
JP (1) | JP6475752B2 (en) |
AU (1) | AU2014369891B2 (en) |
CA (1) | CA2935177C (en) |
WO (1) | WO2015100385A1 (en) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3142054A1 (en) * | 2015-09-11 | 2017-03-15 | Ingenico Group | Data transmission method with corresponding devices and computer programs |
US9626669B2 (en) | 2013-11-26 | 2017-04-18 | Square, Inc. | Card reader emulation for cardless transactions |
EP3382628A1 (en) * | 2017-03-31 | 2018-10-03 | Ingenico Group | Method for data processing by a payment terminal, corresponding payment terminal and program |
US10438202B2 (en) | 2013-03-14 | 2019-10-08 | Square, Inc. | Mobile device payments |
WO2020079379A1 (en) | 2018-10-18 | 2020-04-23 | Clean Bill | Method for transmitting and storing virtual documents by retrofitting a pre-programmed publishing terminal and housing for implementing same |
FR3087562A1 (en) * | 2018-10-18 | 2020-04-24 | Clean Bill | METHOD FOR TRANSMITTING AND STORING INVOICES OR CASH TICKETS AND CASE FOR IMPLEMENTING THE SAME |
US10740748B2 (en) | 2016-11-30 | 2020-08-11 | Square, Inc. | System for improving card on file transactions |
US10878402B1 (en) | 2018-08-31 | 2020-12-29 | Square, Inc. | Temporarily provisioning payment functionality to alternate payment instrument |
US10997583B1 (en) | 2018-08-31 | 2021-05-04 | Square, Inc. | Temporarily provisioning card on file payment functionality to proximate merchants |
US11270304B2 (en) | 2015-09-16 | 2022-03-08 | Square, Inc. | Biometric payment technology |
US11348083B1 (en) | 2014-09-30 | 2022-05-31 | Block, Inc. | Payment by use of identifier |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7337423B1 (en) | 2023-01-26 | 2023-09-04 | 竜也 中野 | Server device, chip management method, chip management program and program |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080041937A1 (en) * | 2006-08-21 | 2008-02-21 | Mci Financial Management Corp. | Secure near field transaction |
US20090043696A1 (en) * | 2007-08-08 | 2009-02-12 | Electronic Payment Exchange | Payment Processor Hosted Account Information |
US20120253852A1 (en) * | 2011-04-01 | 2012-10-04 | Pourfallah Stacy S | Restricted-use account payment administration apparatuses, methods and systems |
US20130132274A1 (en) * | 2011-11-22 | 2013-05-23 | Square, Inc. | Cardless payment transactions |
US20130218721A1 (en) * | 2012-01-05 | 2013-08-22 | Ernest Borhan | Transaction visual capturing apparatuses, methods and systems |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002099858A (en) * | 2000-09-26 | 2002-04-05 | Toshiba Tec Corp | Settlement system, settlement device and settlement method |
JP2003150885A (en) * | 2001-11-15 | 2003-05-23 | Hitachi Ltd | Settlement system and settlement device |
JP2005321873A (en) * | 2004-05-06 | 2005-11-17 | Seiko Epson Corp | Electronic journal creation system, method, and program |
JP2007072534A (en) * | 2005-09-02 | 2007-03-22 | Star Micronics Co Ltd | Print system, control method of print system and program |
US8341083B1 (en) * | 2007-09-12 | 2012-12-25 | Devicefidelity, Inc. | Wirelessly executing financial transactions |
JP2009086832A (en) * | 2007-09-28 | 2009-04-23 | Nidec Sankyo Corp | Information system |
US20090187488A1 (en) * | 2008-01-22 | 2009-07-23 | John Shamilian | Method and system for providing a service to a customer |
JP2009226689A (en) * | 2008-03-21 | 2009-10-08 | Seiko Epson Corp | Printer |
US10839384B2 (en) * | 2008-12-02 | 2020-11-17 | Paypal, Inc. | Mobile barcode generation and payment |
US8548859B2 (en) * | 2010-01-22 | 2013-10-01 | Spendgo, Inc. | Point of sale network router |
JP2011197511A (en) * | 2010-03-23 | 2011-10-06 | Seiko Epson Corp | Voice output device, method for controlling the same, and printer and mounting board |
WO2011156884A1 (en) * | 2010-06-17 | 2011-12-22 | Consumer Mt Inc. | Electronic payment system and method |
JP5799757B2 (en) * | 2011-11-02 | 2015-10-28 | セイコーエプソン株式会社 | Receipt management device, receipt management system, and receipt management device control method |
JP2013238977A (en) * | 2012-05-14 | 2013-11-28 | Seiko Epson Corp | Receipt data processing apparatus and receipt data processing method |
-
2014
- 2014-12-23 EP EP14875157.1A patent/EP3077970A4/en not_active Ceased
- 2014-12-23 WO PCT/US2014/072285 patent/WO2015100385A1/en active Application Filing
- 2014-12-23 JP JP2016561596A patent/JP6475752B2/en active Active
- 2014-12-23 AU AU2014369891A patent/AU2014369891B2/en active Active
- 2014-12-23 CA CA2935177A patent/CA2935177C/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080041937A1 (en) * | 2006-08-21 | 2008-02-21 | Mci Financial Management Corp. | Secure near field transaction |
US20090043696A1 (en) * | 2007-08-08 | 2009-02-12 | Electronic Payment Exchange | Payment Processor Hosted Account Information |
US20120253852A1 (en) * | 2011-04-01 | 2012-10-04 | Pourfallah Stacy S | Restricted-use account payment administration apparatuses, methods and systems |
US20130132274A1 (en) * | 2011-11-22 | 2013-05-23 | Square, Inc. | Cardless payment transactions |
US20130218721A1 (en) * | 2012-01-05 | 2013-08-22 | Ernest Borhan | Transaction visual capturing apparatuses, methods and systems |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10438202B2 (en) | 2013-03-14 | 2019-10-08 | Square, Inc. | Mobile device payments |
US11455633B2 (en) | 2013-03-14 | 2022-09-27 | Block, Inc. | Mobile device payments |
US11562360B2 (en) | 2013-03-14 | 2023-01-24 | Block, Inc. | Mobile device payments |
US9799021B1 (en) | 2013-11-26 | 2017-10-24 | Square, Inc. | Tip processing at a point-of-sale system |
US9626669B2 (en) | 2013-11-26 | 2017-04-18 | Square, Inc. | Card reader emulation for cardless transactions |
US11107056B2 (en) | 2013-11-26 | 2021-08-31 | Square, Inc. | Card data output for cardless transactions |
US11348083B1 (en) | 2014-09-30 | 2022-05-31 | Block, Inc. | Payment by use of identifier |
FR3041132A1 (en) * | 2015-09-11 | 2017-03-17 | Ingenico Group | METHOD FOR TRANSMITTING CORRESPONDING DATA, DEVICES AND COMPUTER PROGRAMS |
US10929825B2 (en) | 2015-09-11 | 2021-02-23 | Ingenico Group | Method for transmitting data, corresponding devices and computer programs |
EP3142054A1 (en) * | 2015-09-11 | 2017-03-15 | Ingenico Group | Data transmission method with corresponding devices and computer programs |
US11270304B2 (en) | 2015-09-16 | 2022-03-08 | Square, Inc. | Biometric payment technology |
US10740748B2 (en) | 2016-11-30 | 2020-08-11 | Square, Inc. | System for improving card on file transactions |
EP3382628A1 (en) * | 2017-03-31 | 2018-10-03 | Ingenico Group | Method for data processing by a payment terminal, corresponding payment terminal and program |
FR3064787A1 (en) * | 2017-03-31 | 2018-10-05 | Ingenico Group | METHOD OF PROCESSING DATA WITH A PAYMENT TERMINAL, TERMINAL OF PAYMENT AND PROGRAM THEREOF |
US11074574B2 (en) | 2017-03-31 | 2021-07-27 | Ingenico Group | Method for processing data by a payment terminal, corresponding payment terminal and program |
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 |
FR3087562A1 (en) * | 2018-10-18 | 2020-04-24 | Clean Bill | METHOD FOR TRANSMITTING AND STORING INVOICES OR CASH TICKETS AND CASE FOR IMPLEMENTING THE SAME |
WO2020079379A1 (en) | 2018-10-18 | 2020-04-23 | Clean Bill | Method for transmitting and storing virtual documents by retrofitting a pre-programmed publishing terminal and housing for implementing same |
Also Published As
Publication number | Publication date |
---|---|
AU2014369891A1 (en) | 2016-07-14 |
JP6475752B2 (en) | 2019-02-27 |
EP3077970A4 (en) | 2017-08-16 |
EP3077970A1 (en) | 2016-10-12 |
CA2935177C (en) | 2019-08-13 |
AU2014369891B2 (en) | 2017-03-02 |
CA2935177A1 (en) | 2015-07-02 |
JP2017510903A (en) | 2017-04-13 |
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 | |
EP2637131B1 (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 | |
AU2009292926B2 (en) | Method of performing transactions with contactless payment devices using pre-tap and two-tap operations | |
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 | |
AU2013260701A1 (en) | Systems and methods for facilitating authorisation of payment | |
US20140101043A1 (en) | Sound-Based Payment Transactions | |
US9299071B1 (en) | System and method for processing a beacon based purchase transaction | |
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 | |
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 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14875157 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2935177 Country of ref document: CA Ref document number: 2016561596 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REEP | Request for entry into the european phase |
Ref document number: 2014875157 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2014875157 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref document number: 2014369891 Country of ref document: AU Date of ref document: 20141223 Kind code of ref document: A |