WO2020058900A1 - Adaptateur pour imprimante - Google Patents

Adaptateur pour imprimante Download PDF

Info

Publication number
WO2020058900A1
WO2020058900A1 PCT/IB2019/057911 IB2019057911W WO2020058900A1 WO 2020058900 A1 WO2020058900 A1 WO 2020058900A1 IB 2019057911 W IB2019057911 W IB 2019057911W WO 2020058900 A1 WO2020058900 A1 WO 2020058900A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
adapter
authentication device
printer
mobile device
Prior art date
Application number
PCT/IB2019/057911
Other languages
English (en)
Inventor
Francois Johannes Rautenbach
Original Assignee
Francois Johannes Rautenbach
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Francois Johannes Rautenbach filed Critical Francois Johannes Rautenbach
Priority to EP19863626.8A priority Critical patent/EP3853797A4/fr
Publication of WO2020058900A1 publication Critical patent/WO2020058900A1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00—Cash registers
    • G07G1/0018—Constructional details, e.g. of drawer, printing means, input means
    • 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/326—Payment applications installed on the mobile 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/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]
    • G06Q20/3223—Realising banking transactions through 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/3226—Use of secure elements separate from 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G5/00—Receipt-giving machines

Definitions

  • This invention relates to an adapter for a printer such as a point of sale printer.
  • DPA Digital Payment Acceptance
  • Payment cards are still very prevalent and include debit or credit cards generally in the form of magnetic stripe cards and smart chip cards.
  • mobile payments have become increasingly popular in recent times.
  • the most common DPA system currently being used involves payment cards issued to a customer or card holder by a bank or other financial institution.
  • a card payment terminal is then used by a merchant at a point of sale (POS) to capture data from the payment card to facilitate the payment process via a server which may be provided by an intermediary.
  • POS point of sale
  • a three-party scheme or a four-party scheme is typically used, depending on the circumstances.
  • card payment systems have a number of security flaws and drawbacks.
  • the financial transaction (or at least a significant portion thereof) is performed by the merchant and hence there is a risk to the customer’s personal information.
  • PIN Personal Identification Number
  • PCI DSS Payment Card Industry Data Security Standard
  • rogue POS devices are created by hackers or other unscrupulous parties. PINs entered on a rogue or hacked device are essentially compromised and may lead to a significant financial loss for the card holder.
  • Card terminals or card readers are expensive and usually require a stable internet connection in order to function properly. Even though communication between the card terminal and the transaction server is provided by a secure data link, the communication between the card terminal and the payment card is not secured. This opens up a possible avenue for a so-called man-in- the-middle attack (MITM), wherein transaction details between the card and the reader may be modified.
  • MITM man-in- the-middle attack
  • the communication between card terminals and payment cards is generally based on a stateless protocol according to the EMV standard (EMV originally stood for Europay International, MasterCard Inc., and Visa Inc., but the standard is now managed by a consortium also including other entities).
  • EMV Europay International, MasterCard Inc., and Visa Inc.
  • the stateless protocol has an underlying flaw whereby cards can be "logically" swapped when the PIN is checked and swapped back when the transaction is performed.
  • This underlying EMV protocol flaw is still present on many issued cards and card readers. Cloning of payment cards may still pose problems in some circumstances. If an EMV reader is compromised to the extent that the conversation between the card and the terminal is intercepted, the attacker may be able to recover data from the card as well as the card holder’s PIN.
  • Technology has also become available on the market for both reading and writing magnetic stripes, making cards easy to clone and use without the card holder’s knowledge.
  • NFC Near-field communication
  • SMS short message service
  • Point of sale (POS) printers are devices that are configured to print receipts after payment has been effected. Some of these point of sale printers have fast printing speeds and are fairly inexpensive. However, these POS printers have limited functionality and are generally only arranged to print receipts when receiving printing data (usually via a serial, parallel or LAN connection) from a point of sale computer associated with a merchant. There is accordingly scope to address the aforementioned problems and deficiencies or at least to provide a useful alternative to the known devices systems and methods.
  • an adapter for a printer comprising a first interface which connects the adapter to the printer, a second interface which enables communication between the printer and a point of sale system, a payment authentication device which includes a wireless interface for communicating with a mobile device of a customer, and a third interface which is connected to the payment authentication device and is configured to emulate a payment terminal.
  • printer to be a point of sale printer
  • adapter to be an adapter card insertable into an adapter card slot of the point of sale printer
  • first, second and third interfaces to be provided by physical or virtual ports.
  • the second and third interfaces are provided by means of ports which may be serial ports provided on the adapter card.
  • the second and third interfaces are provided by means of a single Universal Serial Bus (USB) interface on the adapter card capable of emulating two separate serial ports.
  • USB Universal Serial Bus
  • the payment authentication device to include a microprocessor mounted to the adapter and a memory; and for a private key or secure cryptographic element associated with the payment authentication device to be pre-stored in the memory; for the memory to be cryptographically secured, or to be in the form of a cryptographic element which inhibits or prevents unauthorised modification of the keys or data stored therein.
  • the payment authentication device to be configured to: transmit a transaction request including transaction data to the mobile device; sign the transaction request using the private key stored in the memory of the payment authentication device; authenticate or confirm the payment when a payment attestation certificate is received from the mobile device; and for the memory to also include a pre-stored public key that may be used to authenticate the payment attestation certificate in order to authenticate or confirm that payment has been effected.
  • the transaction data to include one or more of: a payment amount, information about the point of sale, and/or information about the payment authentication device.
  • the payment authentication device to be an offline device (in other words, it does not require Internet connectivity).
  • the payment authentication device to include a signing component configured to sign a transaction request using the private key stored in the memory; a transmitter for transmitting the signed transaction request to a mobile device of a customer; a receiver for receiving a payment attestation certificate from the mobile device; and an authentication component which is arranged to authenticate the payment attestation certificate using the public key, in order to confirm that payment has been effected.
  • a signing component configured to sign a transaction request using the private key stored in the memory
  • a transmitter for transmitting the signed transaction request to a mobile device of a customer
  • a receiver for receiving a payment attestation certificate from the mobile device
  • an authentication component which is arranged to authenticate the payment attestation certificate using the public key, in order to confirm that payment has been effected.
  • the wireless interface may be provided by a wireless technology selected from the list comprising: BluetoothTM, Bluetooth Low Energy (BLE), Near-field communication (NFC), Wi-FiTM, radio-frequency identification (RFID) and/or any other wireless technology capable of providing the wireless interface.
  • the wireless interface may also be provided by using a communications protocol such as Internet Protocol or a local area network (LAN) protocol.
  • a method of authenticating payment the method being conducted by an adapter for a printer, the method comprising: establishing a wireless link between a payment authentication device of the adapter and a mobile device of a customer; signing a transaction request including transaction data using a pre-stored private key associated with the payment authentication device; transmitting the transaction request to the mobile device; receiving a payment attestation certificate from the mobile device; and authenticating the payment attestation certificate using a pre-stored public key, to authenticate that payment has been effected.
  • a further feature provides for the method to include the step of: transmitting an instruction signal to the printer when payment is confirmed or authenticated.
  • a method of authenticating payment the method being conducted by a backend, the method comprising: receiving a transaction request from a payment authentication device of an adapter for a printer, the transaction request being relayed to the backend by a mobile device of a customer; generating a payment attestation certificate when payment is effected; and transmitting the payment attestation certificate to the mobile device wherefrom it is relayed to the payment authentication device of the adapter for the printer, to authenticate that payment has been effected.
  • the backend to include a cryptographic server or an attestation certificate generator server.
  • a still further feature provides for the method to include the step of: receiving payment data from a payment processor that indicates successful payment, and responsive thereto, generating the payment attestation certificate.
  • a payment authentication system comprising: an adapter for a printer including a first interface which connects the adapter to the printer, a second interface which enables communication between the printer and a point of sale system, a payment authentication device which includes a wireless interface for communicating with a mobile device of a customer, and a third interface which is connected to the payment authentication device and is configured to emulate a payment terminal, the payment authentication device being configured to transmit a transaction request including transaction data to the mobile device; and a backend that includes an attestation certificate generator server, wherein the backend is in data communication with a payment processor and configured to receive the transaction request from the mobile device, whereupon the payment processor is instructed to effect payment, and wherein the attestation certificate generator server is configured, responsive to a successful payment, to generate a payment attestation certificate and to transmit the attestation certificate to the mobile device wherefrom it is relayed to the payment authentication device to authenticate the payment.
  • a payment authentication application to be downloadable and installable on the mobile device to facilitate operation of the system; for the payment authentication application to be operable to activate a third-party payment application for guiding the customer through payment steps of the payment processor; and for the payment authentication application to be operable to receive the payment authentication certificate after the customer is guided through the payment steps of the payment processor.
  • Figure 1 is a top view of an exemplary embodiment of an adapter card for a printer
  • Figure 2 is a front view of a point of sale printer
  • Figure 3 is a three-dimensional view illustrating the adapter card comprising a payment authentication device being inserted into a card slot of the printer
  • Figure 4 is a high-level block diagram illustrating an exemplary system for authenticating mobile payments using the adapter for the point of sale printer
  • Figure 5 is a flow diagram illustrating a method of authenticating payment performed by the adapter
  • Figure 6 is a high-level block diagram illustrating the payment authentication device in more detail
  • Figure 7 illustrates an example of a computing device in which various aspects of the disclosure may be implemented
  • Figure 8 is a high-level block diagram illustrating another exemplary embodiment of a system for authenticating mobile payments
  • Figure 9 is a high-level block diagram illustrating yet another exemplary embodiment of a system for authenticating mobile payments.
  • Figure 10 is a swim-lane flow diagram illustrating a further example of a method of authenticating payments. DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS
  • the point of sale printer may be in communication with a point of sale system, for example in a retail or other commercial environment.
  • the adapter may include a payment authentication device for verifying that a payment transaction has been effected.
  • the payment authentication device may be configured to wirelessly connect to a mobile device or smartphone of a user or customer and to send a digitally signed payment request or transaction request to the mobile device.
  • An attestation certificate or token may be received by the payment authentication device from the mobile device.
  • the attestation certificate may be authenticated by the payment authentication device, and an instruction signal may be transmitted by the adapter.
  • FIG 1 is a schematic diagram which illustrates an exemplary adapter (10) for a printer (12), in this embodiment in the form of a point of sale printer which is shown in Figures 2, 3 and 4.
  • the adapter may include a first interface (14) which may connect the adapter to the printer (12).
  • a second interface (16) may also be provided, which may enable communication between the printer (12) and a point of sale system (18) (shown in Figure 4).
  • the adapter (10) may further include a payment authentication device (20), which may include a wireless interface (22) for communicating with a mobile device (24) of a customer (26).
  • a third interface (28) may also be provided and connected to the payment authentication device (20).
  • the third interface (28) may be configured to emulate a payment terminal (not shown).
  • the adapter (10) is in the form of an adapter card insertable into an adapter card slot (30) of the point of sale printer (12).
  • the second and third interfaces (16, 28) may be provided by means of ports which may be serial or parallel ports provided on the adapter card (10).
  • the second and third interfaces (16, 28) are provided by means of a single Universal Serial Bus (USB) interface (32) on the adapter card (10) capable of emulating two separate serial ports.
  • USB Universal Serial Bus
  • the second interface (16) (in the form of a first emulated serial port) may be configured to reference the printer (12) and to be indistinguishable from a standard serial port interface of a point of sale printer, from the perspective of the point of sale system (18) when a connection (34) (which may be a wired or a wireless connection) is made between the point of sale system and the printer (12).
  • the third interface (28) (in the form of a second emulated serial port) may be configured to emulate a payment terminal (not shown), such as a credit card payment terminal.
  • the third interface (28) may be connected to the payment authentication device (20).
  • the point of sale system may appear as though a printer and a payment terminal such as a credit card terminal are plugged (or otherwise connected e.g. wirelessly) into the system (18) and the system may hence recognise a valid credit card terminal being connected thereto.
  • FIG. 6 shows a high-level block diagram illustrating an example embodiment of the payment authentication device (20).
  • the payment authentication device may include a microprocessor (36) which may be mounted to the adapter (10).
  • the processor (36) may be configured for executing the functions of components described below, which may be provided by hardware or by software units executing on the payment authentication device (20).
  • the payment authentication device (20) may also include a memory (38) or a memory component, and the software units may be stored in the memory component (38) and instructions may be provided to the processor (36) to carry out the functionality of the described components.
  • a private key or secure cryptographic element associated with the payment authentication device (20) may be pre-stored in the memory (38), for example during manufacturing thereof.
  • the payment authentication device (20) may also include a transmitting component (40), a receiving component (42), a signing component (43) and an authenticating component (45).
  • security features for the relevant device may be programmed into a security chip or microchip of the payment authentication device (20).
  • Other security data for example a unique identifier
  • a public key associated with a secure backend or attestation certificate generator server (58) may also be pre-stored in the memory (38).
  • the payment authentication device (20) may be digitally (and/or physically) locked which may prevent any further updates to the security features, save for changing a security“realm” or domain of the device using properly signed commissioning and de-commissioning tokens.
  • the payment authentication device (20) may further include the signing component (43) configured to digitally sign the transaction request (52) using the private key stored in the memory (38), and an authenticating component (45) which may be arranged to authenticate the payment attestation certificate (60) using the public key in order to authenticate or verify that payment has been effected.
  • the adapter (10) is inserted into the slot (30), whereafter the printer is connected to the point of sale system (18), for example with a USB cable (34) (or by means of a USB based Wi-FiTM link or another communication channel such as Bluetooth, Bluetooth Low Energy, Ethernet, etc.).
  • the point of sale printer (12) may for example be provided in a retail or other commercial environment that the customer (26) visits.
  • a merchant (44) or beneficiary may be associated with the point of sale system (18) and the point of sale printer may be provided at the merchant’s (44) premises, e.g. at a retail store.
  • a code such as a QRTM code (46) (which may be physical or virtual) may be provided on the printer (12) (or elsewhere at the merchant’s premises).
  • the customer (26) enters the premises and intends to pay for goods or services provided by the merchant (44).
  • the customer may install (or may have pre-installed) a mobile application (app) (53) executing on the mobile device (24).
  • the customer (26) may then, via the app, use a camera of the mobile device to capture an image of the code (46).
  • the code may contain information about the payment authentication device (20) for example a media access control (MAC) address associated therewith.
  • the MAC address may then be used by the mobile device (24) to establish a wireless link (48) between the mobile device and the payment authentication device (20) via the wireless interface (22). Pairing may be performed, but a pairing step may not be necessary in the embodiment shown.
  • the QR code may be omitted and wherein the link may be automatically established once the mobile device is brought into proximity of the payment authentication device.
  • the payment authentication device (20) may generate a transaction request (52) which may contain transaction data including information about the payment transaction.
  • the information about the payment transaction may for example include: information about the merchant (44) (information about a financial institution associated with the merchant such as bank account details of the merchant); information about the point of sale; information about the payment authentication device (20); and/or an amount and currency of the required payment (for example United States Dollars $).
  • the information about the payment authentication device (20) may for example be a serial number assigned thereto, or other data relating to the device (20), or a unique identifier associated therewith.
  • the information about the payment authentication device may be signed with a server-based private key and stored into the memory (38) during manufacturing thereof.
  • the transaction request (52) may also be digitally signed by the payment authentication device using the private key associated with the payment authentication device (20). A reference number of the payment transaction may also be included in the transaction request.
  • the transaction request (52) may be transmitted to the mobile device (24) by the payment authentication device.
  • the transaction request may include the amount to be paid, and in another embodiment the customer (26) may be prompted by the app (53) to enter the amount (50) to be paid when guided through the payment process, whereafter the mobile device (24) may transmit the amount to be paid back to the payment authentication device (20) which then includes the payment amount into the signed transaction request (52) before again transmitting the signed transaction request via the mobile device (24) to the backend or to the payment processor.
  • the mobile device may include the amount to be paid into the transaction request.
  • the mobile device may also be arranged to include information about the customer (26), (for example information about a financial institution associated with the customer (26), such as bank account details of the customer) into the transaction request (52).
  • information about the customer (26) for example information about a financial institution associated with the customer (26), such as bank account details of the customer
  • An example of information that may be included in the transaction request may be a unique customer reference that could be used by the merchant to drive customer loyalty by providing incentives like discounts or coupons to repeat customers.
  • the payment authentication device may generate a digitally signed pro-forma invoice which may be transmitted with the transaction request to the mobile device (24).
  • the transaction request may be digitally signed by the mobile device.
  • the mobile device (24) may transmit the transaction request (52) with the transaction data to a payment processor (54) such as a bank or other financial institution which may be at the backend or separate from the backend.
  • the payment processor (54) may then perform steps to facilitate the necessary transfer of funds from a first account to a second account, for example from a bank account of the customer (26) (or an intermediary account) to a bank account of the merchant (44).
  • the payment processor (54) may transmit a proof of payment (56) to the mobile device (24).
  • the mobile device (24) may transmit the proof of payment (56) to an attestation certificate generator server (58) which may form part of the backend.
  • the attestation certificate generator server (58) may, in turn, be configured to generate a digitally signed attestation certificate (60). This certificate or token may be unique for every payment transaction. Depending on the type of payment processor (54) involved, the attestation certificate generator server (58) may be required to transmit a verification request (62) to the payment processor (54), whereupon the payment processor (54) transmits a verification (64) to the attestation certificate generator server (58), indicative that payment was successful. Next, the attestation certificate generator server (58) generates the attestation certificate (60), which may be in the form of a digitally signed payment certificate or attestation which indicates that payment was successfully processed by the payment processor (54).
  • the certificate (60) may also be digitally signed using a server-side private key of an asymmetric cryptographic key pair, so that it may be authenticated with a relevant public key.
  • the certificate (60) may then be transmitted to the mobile device (24) by the attestation certificate generator server (58).
  • the mobile device may transmit the certificate (60) via the wireless link (48) to the payment authentication device (20), where it is authenticated using the relevant public key, which may be pre-stored in the memory (38). This may enable the payment authentication device (20) to securely (and/or reliably) verify or confirm that payment was indeed successfully processed, and responsive thereto, the payment authentication device (20) may transmit an instruction signal to the printer via the first interface (14).
  • the printer may then, responsive to the instruction signal, print a receipt (66) indicating that payment was effected and successfully processed.
  • the payment authentication device (20) may be arranged to verify the authenticity of a successful payment. If the transaction was not successful (e.g. if the customer has insufficient funds available), a failed payment notification may be printed by the printer (12) or displayed on a display associated with the printer.
  • the payment processor (54) may be in the form of a bank or a digital payment processor such as the services provided by PayPal Holdings Inc., Google Pay (G Pay) By Google Inc., Android Pay, Apple Pay by Apple Inc., or any other payment processor capable of effecting payment between an account of the customer (26) and an account of the merchant (44).
  • the wireless interface may take on a variety of forms, and may be provided by a suitable wireless technology selected from the list comprising: BluetoothTM, BluetoothTM Low Energy (BLE) sometimes referred to as Bluetooth Smart (beacons, for example using Eddystone Beacon technology provided by GoogleTM, or other beacons, iBeaconsTM, etc.), Near-field communication (NFC), WiFiTM, radio-frequency identification (RFID) and/or any other wireless technology capable of providing the wireless interface.
  • the first, second and third interfaces may be provided by physical or virtual (i.e. emulated) ports.
  • the app (54) may be configured to enable the mobile device (24) to“listen” or scan for a signal (such as an advertisement signal) including a MAC address, transmitted by a nearby payment authentication device (20), whereafter the payment process may be initiated.
  • the mobile device (24) may listen for a BLE signal that includes a factory calibrated signal strength (received signal strength indicator or RSSI) associated with the payment authentication device (20).
  • the RSSI may be used by the mobile device to determine a distance between the mobile device and the payment authentication device (20).
  • the wireless link (48) may be automatically established when the mobile device is close enough to the payment authentication device (20).
  • NFC may also be used, whereby a passive (or active) RFID tag associated with the payment authentication device may return the relevant MAC address of the payment authentication device (20) to the mobile device (24) so that the wireless link (48) may be established.
  • the payment authentication device (20) may be configured to emit a sound signal (for example a low volume sound signal) which may contain the MAC address, which sound signal may be received by the mobile device (24) when it is near enough to the printer (12) and/or near the payment authentication device (20).
  • a sound signal for example a low volume sound signal
  • the MAC address may even be retrieved from the internet by the mobile device (24) by looking up the MAC address on a resolving Internet server.
  • An advertisement may also be displayed on a screen of the mobile device once the wireless link (48) has been established and/or a digital voucher (which may be a digitally signed redeemable voucher) may be generated for the customer as required.
  • the adapter may enable the printer to print customised receipts (or vouchers) including logos or banners associated with the merchant or custom messages to the customer.
  • the described systems may implement a method of authenticating payment.
  • Figure 5 is shown an exemplary flow diagram illustrating a method (100) of authenticating payment, the method being performed by the adapter (10).
  • the wireless link may be established (1 10) between the payment authentication device (20) of the adapter (10) and the mobile device (24) of the customer (26).
  • the transaction request (52) including the transaction data may be signed (1 12) using the pre-stored private key associated with the payment authentication device (20). This signed transaction request may be referred to as a payment request certificate (PRC), which is also described below.
  • PRC payment request certificate
  • the transaction request (52) may be transmitted (1 14) to the mobile device (24).
  • the payment attestation certificate (60) may be received (1 16) from the mobile device (24).
  • the payment attestation certificate may be authenticated (1 18) using the pre-stored public key, to enable the payment authentication device (20) to verify or confirm that payment has been effected.
  • An instruction signal may be transmitted (120) to the printer (12) after which the printer may for example print the receipt (66).
  • the attestation certificate (60) may be generated and signed with a server-side private signer key, and the attestation certificate (60) may be transmitted to the mobile device (24).
  • a transaction server (1036, 2036) (described below with reference to Figures 8 to 10) may be provided in communication with the mobile device.
  • the transaction server may also be used in other embodiments of the present disclosure, and may for example form part of a backend of the embodiment described with reference to Figure 4.
  • the transaction server may be in communication with the payment processor on the one hand, and with the attestation certificate generator server on the other. The transaction server then receives the transaction request from the mobile device (which was relayed from the payment authentication device), transmits the transaction request to the payment processor, and requests the payment attestation certificate from the payment attestation certificate generator server.
  • the payment attestation certificate generator server may then transmit the certificate to the transaction server wherefrom it may be relayed to the mobile device, and to the payment authentication device. More than one payment option may be provided to the customer via the app (53, 1053, 2053) (which may be referred to as a payment authentication app), so that the customer may select a preferred payment processor for the particular payment transaction at hand.
  • the payment processor may request the attestation certificate directly from the attestation certificate generator server and may transmit the certificate to the mobile device.
  • This may eliminate the additional request (for the proof of payment shown in Figure 4) from the mobile device and may increase security, because the attestation certificate generator server may be placed in a so-called“de-militarized zone” (DMZ) that may only be accessible by payment processors.
  • DZ de-militarized zone
  • a computing device (51 ) may be provided and it may be associated with the merchant (44).
  • the computing device (51 ) may form part of the point of sale system (18).
  • the merchant (or merchants) may be enabled to use the computing device (51 ) to directly obtain data from the backend.
  • a management application or interface may be provided (for example via downloadable and installable software) on the computing device (51 ) and may enable reconciliation features (which may be performed“after-the-fact”).
  • the merchant may be enabled to view information about the customer (26) such as a history of financial transactions of the customer, using the computing device (51 ).
  • Data relating to previous requests and certificates of the customer may be stored in a database at the backend and the merchant may be able to view this information (for example a history of successful, or unsuccessful payment transactions of the customer), using the management interface.
  • the payment authentication device (20) may also be configured to transmit information about the customer to the computing device (51 ), which may enable the management application to look up or retrieve data relating to the customer (26) at the backend.
  • the merchant (44) is enabled to look up the information about the customer via the computing device (51 ), even before the financial transaction is performed, which may enable the merchant to evaluate whether the customer is a good (i.e. financially reliable) customer or not.
  • the app (53) may prompt the customer to enter a PIN or password (and/or to provide a username or other personal information, biometric authentication, or another type of user authentication) on their own mobile device (24) while guiding the customer (26) through the payment process. This may prevent the various risks posed by rogue POS devices that may be created by hackers or other unscrupulous parties.
  • the customer may also register for use of the app (53) and particulars of the customer may be stored at the backend.
  • Distributed payment authentication devices may be registered and data relating to these devices (including their respective serial numbers, unique identifiers etc.) may be stored in a database at the backend. Even though not presently preferred, particulars of the customer may be stored at the attestation certificate generator server.
  • the device may be locked which may prevent any further updates to the security features, save for changing an application security realm (ASR) or domain of the device using properly signed commissioning and de-commissioning tokens.
  • ASR application security realm
  • configuration of the payment authentication device (20) it may be programmed according to an application specific security realm. This may be done to assign the device to a specific application use. Devices that have not been commissioned yet, may by default be assigned to a testing realm as part of the configuration process. The testing realm does not accept actual payments, but may otherwise be a fully functioning realm.
  • Distributed or commissioned devices may also be de-commissioned to move them back to the testing realm (and this may be done remotely for example via the internet) allowing re-configuration during any stage of the relevant device’s lifetime (for example when ownership of the payment authentication device changes).
  • Providing a plurality of different Application Security Realms may provide risk reducing features as it may allow transactions to be divided into logical groups based on the specific application. This grouping or categorization of transactions from related merchants may provide a so-called security fence that may reduce the impact of security breaches. It may also be beneficial to use different keys for different applications.
  • the use of an ASR may limit the payment authentication device to only accept tokens or certificates signed by signer keys from the same ASR.
  • the signer key may for example be used by the backend to sign the cryptographic token or certificate that may be transmitted to the payment authentication device after a successful payment.
  • Examples of different Application Security Realms are: automated vending; parking payment; food deliveries; micro vendors; restaurants; physical shops; Internet shopping; etc.
  • Information about the relevant ASR may be included in the transaction data that may be transmitted with the transaction request.
  • the transaction request may be in the form of a digitally signed transaction request certificate (a cryptographic certificate) generated by the payment authentication device and signed by its private key.
  • the payment authentication device may further be configured to keep a digital journal of processed payment transactions and to store details about the payment transactions into its memory.
  • FIG 8 is shown a high-level block diagram of another exemplary embodiment of a payment authentication system (1000).
  • the system may include components, devices, or features of the other systems and methods disclosed, and the systems and methods described with reference to the other Figures may include features of the system (1000) shown in Figure 6.
  • the point of sale system (18) is omitted from Figure 8 for the sake of brevity.
  • a customer (1016) may use a mobile device (1014) executing the app (1053) and a merchant (1050) may have a payment authentication device (1010) similar to the payment authentication device (20) described above and it may be provided in an adapter card (similar to the card (10) in Figure 1 ) of a point of sale printer (1012) associated with the merchant (1050).
  • the mobile device (1014) may connect with the payment authentication device (1010) as described above, and it may establish the wireless link as described above.
  • the app (1053) may initiate the connection to the payment authentication device (1010) and it may obtain an address (for example an Internet address) of a transaction server (1036) which may be associated with the merchant (1050).
  • the transaction server (1036) may also be referred to as a merchant payment server.
  • a backend (1020) may include the transaction server (1036) and an attestation certificate generator server (1024) may form part of the transaction server (1036).
  • a digitally signed payment request certificate (1018) may be transmitted from the payment authentication device (1010) to the mobile device (1014). Relevant merchant data and transaction data may also be included in the request certificate (1018).
  • the request certificate (1018) may be signed with a private key of the payment authentication device (1010).
  • the app (1053) may receive a list (1070) of supported payment options.
  • the app (1053) may prompt the customer (1016) to select a preferred payment option or method.
  • the app (1053) may communicate (1072) with the transaction server (1036) and notify the transaction server (1036) that a payment is being initiated.
  • the transaction server (1036) may set up the payment process with a selected customer payment processor (1022).
  • the app (1053) may activate a third-party payment application (1074) on the customer’s mobile device (1014) to authorise (1075) and to perform the actual payment with the selected payment processor (1022).
  • the customer payment processor (1022) may for example debit an account of the customer (1016) and credit an account of the merchant (1050).
  • the app (1053) may be moved to the background while the third-party payment application (1074) is active.
  • the transaction server (1036) may receive (1076) a payment notification (1058) (such as a proof of payment (POP)) from the payment processor (1022) containing relevant transaction details.
  • a payment notification (1058) such as a proof of payment (POP)
  • the attestation certificate generator server (1024) at the transaction server (1036) may generate a payment attestation certificate (1026) and it may be sent (1078) to the mobile device (1014) of the customer (1016).
  • the payment attestation certificate (1026) may be generated by a local attestation certificate generator server (1024) that may for example be associated with the merchant (1050), however it is also possible for the payment attestation certificate (1026) to be generated using an external attestation certificate generator server (not shown).
  • the attestation certificate generator server (1024) may also be an attached cryptographic device or service associated with the transaction server.
  • the mobile device may pass or relay (1080) the payment attestation certificate (1026) to the payment authentication device (1010).
  • the payment attestation certificate (1026) may be authenticated for example using a pre-stored public key, to enable the payment authentication device (1010) to verify or confirm that payment has been effected.
  • the payment attestation certificate (1026) may thus serve as a cryptographically verifiable proof of payment.
  • the other embodiments, systems, or methods disclosed herein may implement one or more of the features of the embodiment described with reference to Figure 8.
  • the present disclosure may enable a push payment which may be similar to an electronic funds transfer (EFT) type payment, as opposed to conventional credit card payments which are pull payments. Flowever, it may also be possible to implement the present disclosure to enable pull payments, or any type of payment.
  • EFT electronic funds transfer
  • the third-party payment application (1074) may execute separately from the payment authentication application (1053).
  • the payment authentication application (1053) may rely on the third-party payment application (1074) being pre-installed and/or pre-configured onto the customer’s mobile device (1014).
  • the transaction server (1036) may be managed by the merchant (1050), or by a payment service provider on behalf of the merchant (1050).
  • the transaction server (1036) may call on one or more payment processors to handle payments from the respective payment applications (1074).
  • Examples of payment processors or payment applications that may be used include: those marketed as: ZapperTM, SnapScanTM, iDEALTM, Bitcoin Lightning Network (sometimes referred to simply as “the Lightning Network”), MasterpassTM, Unified Payments Interface (UPI) (a payment system used in India), etc. Flowever, any number of payment options may be used or supported.
  • FIG 9 there is shown a high-level block diagram of another exemplary embodiment of a payment authentication system (2000).
  • the system may include components or features of the other systems and methods disclosed, and the systems and methods described with reference to the other Figures may include features of the system (2000) shown in Figure 9.
  • the point of sale system (18) is omitted from Figure 9 for the sake of brevity.
  • the system (2000) may implement a method of authenticating payments.
  • An exemplary method (3000) of authenticating payments is illustrated in the swim-lane flow diagram of Figure 10 (in which respective swim-lanes delineate steps, operations or procedures that may be performed by respective entities or devices).
  • Figure 9 is similar to Figure 8, however it shows more detail of steps that may be performed in the exemplary method (3000).
  • the backend (2020) may include the transaction server (2036) and/or the attestation certificate generator server (2024), and the payment processor (2022) may be in communication with the backend (2020) (or may form part of it).
  • the payment attestation device (conveniently termed a “PRINTER PAD”) (2010) (which may be provided on the printer card installed in the point of sale printer as previously described) may link (3010) with the mobile device (2014) as described above.
  • the mobile device may receive (3012) the Uniform Resource Locator (URL) of the transaction server (2036) (also referred to as a merchant server) as part of an initial connection or link with the printer PAD (2010).
  • the mobile device (2014) may then connect to the transaction server (2036) and request (3014) a list of supported payment options therefrom (or a list of payment processors that are supported by the merchant).
  • a list of all available payment options, including surcharge fees and restrictions may be sent (3016) by the transaction server (2036) to the mobile device (2014).
  • the payment authentication app (2053) on the mobile device (2014) may be operable to initiate third party (3P) payment apps (2074) available on the customer's mobile device (2014).
  • the list of available payment options may be received, and the subset of payment options supported by the merchant and available on the customer's mobile device (2014) may be shown to the customer when prompted for payment.
  • the payment authentication app (2053) on the mobile device (2014) may send (3018) a payment amount to the printer PAD (2010) (as also described above with reference to Figure 4).
  • the customer may for example be prompted to enter the payment amount (or alternatively, the payment amount may be entered by the merchant via the point of sale system).
  • the printer PAD may receive (3020) the amount to be paid, and it may sign a transaction request, for example using a pre-stored private key associated with the printer PAD (2010).
  • a payment request certificate may be generated (the PRC may be similar to the transaction request (52) described above with reference to Figure 4, and the PRC (1018) in Figure 8).
  • the PRC may be transmitted (3022) by the printer PAD (2010) to the mobile device (2014) where it may be received (3024).
  • the mobile device (2014) may forward (3026) the PRC to the transaction server (2036), and it may also indicate the selected payment option to be used.
  • the transaction server (2036) may receive (3028) the PRC, and it may request (3030) the attestation certificate generator server (2024) to parse and validate the PRC.
  • the transaction server (2036) may also be able to do the parsing and validation by itself, as it may only require access to an attestation certificate generator server public key to do so.
  • the parsed PRC (or payment information) may then be received (3032) by the transaction server (2036).
  • the transaction server (2036) may optionally request (3034) the selected payment processor (2022) to set up the expected payment transaction and the request may be received (3036) thereat. This step is optional and need not be required, depending on the selected payment processor.
  • the transaction may be set up (3038) by the selected payment processor (2022), and it may transmit (3040) a payment reference number or other payment information to the transaction server (2036) where same may be received (3042). This step is also optional and not required by all payment processors.
  • the transaction server (2036) may transmit (3044) payment details to the mobile device (2014). This information may be formatted as an "Intent URI" (where URI refers to a Uniform Resource Identifier).
  • This Intent URI may be received (3046) and accessed or opened by the payment authentication app (2053) on the mobile device (2014), and it may activate (3048) the relevant third party (3P) mobile application (2074) to perform the actual transaction.
  • the Intent URI typically contains all the transaction information, including merchant details and the amount to pay.
  • the intent URI (which may simply be referred to as the“intent”) may contain a transaction reference number that can be used by the customer payment processor (2022) to get access to the aforesaid information.
  • the third-party payment app (2074) may then connect (3050) to its payment processor (2022), and the customer may be guided (3052) through the payment steps to confirm and authorise the payment.
  • the payment processor may notify (3054) the transaction server (2036) of the successful payment and it may provide payment information such as a proof of payment (POP) which may be received (3056) at the transaction server (2036).
  • the transaction server (2036) may request (3058) the attestation certificate generator server (2024) to generate a payment attestation certificate (PAC).
  • the PAC may be similar to the payment attestation certificate (60, 1026) described above with reference to Figures 4 and 8.
  • the PAC (which may be digitally signed and which may include embedded payment information) may be received (3060) by the transaction server (2036) and it may be transmitted to the mobile device (2014) where it may be received (3062).
  • the PAC may be relayed via the mobile device (2014) and transmitted to the printer PAD (2010) where it may be received (3064).
  • the PAC may be authenticated (3066) using a public key, as described above, to prove that payment has been effected.
  • the printer PAD (2010) may transmit (3068) the instruction signal, and the receipt may be printed.
  • One or more of the aforementioned steps may be repeated for subsequent transactions.
  • the third-party payment application may be any payment application operable by the mobile device and includes, but is not limited to apps or services provided by entities such as ZapperTM, SnapScanTM, iDEALTM and iDEAL compatible banking apps (such as those used in the Netherlands), Bitcoin Lightning Network (including its compatible apps), MasterpassTM (including its compatible apps), UPI compatible apps etc.
  • the public key associated with the payment authentication device (20, 1010, 2010) may be associated with a so-called “realm” or domain of the payment transaction.
  • Each payment authentication device may compute its own unique private key that may be stored securely on the device.
  • the associated public key and other device information, e.g. serial no
  • the resulting certificate may then also be stored on the payment authentication device (20, 1010, 2010).
  • This resulting certificate may be conveniently termed the device credentials.
  • the relevant payment authentication device When the relevant payment authentication device generates a payment request, it signs the request with its own private key and includes its credentials. Since the credentials were digitally signed previously, the credentials may be verified by an external party. This validates the device’s public key, which may be used, in turn, to validate the payment request.
  • a private server key for the relevant realm may then be used to sign the attestation certificate before transmitting it to the mobile device.
  • the private realm keys may be generated and stored at the backend, for example on the cryptographic server (or attestation certificate generator server).
  • the payment authentication device may be configured for the particular application or realm, and the relevant public key (for the particular realm) associated with the payment authentication device may be pre-stored in its memory during manufacturing.
  • the realm’s associated public key may be sent to the device as part of a device configuration certificate.
  • the realm public key may be securely stored in the memory of the payment authentication device and used to validate attestation certificates.
  • the payment request may include a realm identifier.
  • the cryptographic server may use this identifier to select the correct private key with which it signs the relevant attestation certificate.
  • the attestation certificate generator server (58, 1024, 2024) may be able to determine that the transaction request was indeed generated by an authentic payment authentication device.
  • Information about the payment authentication device including a unique identification number or serial number thereof may also be transmitted with the transaction request that may be received at the payment attestation certificate generator server.
  • the transaction request (60) may include an embedded device certificate generated as part of the manufacturing and configuration of the payment authentication device (20), which can be used to verify the authenticity of the device. This verification may be performed by any computing device with access to the relevant public key (including the customer’s mobile device).
  • the point of sale printer may also be associated with a vending machine. In such an embodiment, the point of sale system may be associated with the vending machine and the merchant may be a remote party which owns or operates the vending machine.
  • the payment authentication device may provide the functionality of verifying successful payment without requiring an internet connection of the payment authentication device itself (or the printer).
  • an internet connection of the mobile device (which is an“un-trusted” or“proxy” device of the customer or user) may be used to convey the attestation certificate from the payment attestation certificate generator server to the payment authentication device in a secure fashion, because the attestation certificate or token may be signed using asymmetric cryptography (or another cryptographically secure protocol or system).
  • This may provide the advantage of enabling a relatively simple printer to facilitate mobile payments, without the merchant needing to have an internet connection, while still providing secure means of authenticating successful payment.
  • ECC Elliptic-curve cryptography
  • EDSA Elliptic Curve Digital Signature Algorithms
  • ECC is an Asymmetric Cryptographic algorithm with a relatively small key size while still providing a relatively high level of security, compared to other asymmetric algorithms
  • ECDSA is an application of Elliptic Curve Cryptography for creating Digital Signatures.
  • a proof-of-fact or proof of knowledge may be provided whereby the payment authentication device may be enabled to confirm payment via a proxy or intermediate device (customer’s mobile device or smartphone acting as a relay) which neither the merchant, nor an operator of the payment attestation certificate generator server have control over.
  • a proxy or intermediate device customer’s mobile device or smartphone acting as a relay
  • This may provide protection against modification, MITM attacks, spoofing, replay attacks or hacking.
  • the public and/or private cryptographic keys described herein may be changed from time to time (may be transient or short-lived) which may increase security.
  • a cryptographically secure key exchange protocol may be used when the attestation certificate or cryptographic token may be transmitted from the attestation certificate generator server to the mobile device and from the mobile device to the payment authentication device.
  • the attestation certificate may be authenticated by the payment authentication device, however, embodiments are possible wherein the attestation certificate may be authenticated by the mobile device, if the mobile device has access to the required public key of the relevant realm or domain.
  • the adapter may enable the printer to print relatively quickly, because of the USB interface provided.
  • the payment transaction may be authenticated or validated by the payment authentication device securely and in near real time which may provide a user experience similar to that of a contactless payment system while the adapter may be provided in a standard printer which does not require internet connectivity. This may provide the merchant with a contactless payment facility at a reduced cost compared to other alternatives that the applicant is aware of, which facility may be provided while maintaining security of the payment transaction without requiring a trusted or secure user device.
  • the printer with adapter may be compatible with a variety of point of sale systems (including older systems that use serial port printers) while the adapter may provide faster printing than a printer with a regular serial port. Software may be provided on the point of sale system to facilitate faster printing using the USB interface. By using cryptographic certificates or tokens that are digitally signed, the digital signature can be used to verify the authenticity of the contents of the relevant certificate or token.
  • the adapter card may provide the advantage that it may be retrofitted to an existing POS printer and it may turn the printer into a smart printer.
  • the printer Once fitted with the adapter card, the printer may be enabled not only to print receipts, but also to accept mobile payments in a secure manner.
  • merchants that already have POS printers can upgrade these printers with the presently disclosed printer cards and use the POS printers with the card and the associated payment authentication device (printer PAD) to accept payments from customers.
  • Customers may connect to the printer PAD with their mobile device and may perform payment without entering their credentials (username, password/PIN etc.) into a foreign device.
  • the customer may use his or her own banking application on the customer’s mobile device to perform the payment, and the payment can then be authenticated by the printer PAD, whereafter the receipt can be printed.
  • This may provide advantages to merchants, especially in areas with limited internet connectivity, as the printer PAD may perform authentication without requiring internet connectivity itself. It may thus“piggy-back” on the internet connectivity of the mobile device.
  • FIG. 7 illustrates an example of a computing device (700) in which various aspects of the disclosure may be implemented.
  • the computing device (700) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like.
  • a mobile phone e.g. cellular telephone
  • satellite phone e.g. cellular telephone
  • tablet computer e.g. cellular telephone
  • personal digital assistant e.g. cellular telephone
  • the computing device (700) may be suitable for storing and executing computer program code.
  • the various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (700) to facilitate the functions described herein.
  • the computing device (700) may include subsystems or components interconnected via a communication infrastructure (705) (for example, a communications bus, a network, etc.).
  • the computing device (700) may include one or more processors (710) and at least one memory component in the form of computer-readable media.
  • the one or more processors (710) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like.
  • a number of processors may be provided and may be arranged to carry out calculations simultaneously.
  • various subsystems or components of the computing device (700) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and/or process data on behalf of remote devices.
  • the memory components may include system memory (715), which may include read only memory (ROM) and random access memory (RAM).
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system
  • System software may be stored in the system memory (715) including operating system software.
  • the memory components may also include secondary memory (XX20).
  • the secondary memory (720) may include a fixed disk (721 ), such as a hard disk drive, and, optionally, one or more storage interfaces (722) for interfacing with storage components (723), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.
  • removable storage components e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.
  • network attached storage components e.g. NAS drives
  • remote storage components e.g. cloud-based storage
  • the computing device (700) may include an external communications interface (730) for operation of the computing device (700) in a networked environment enabling transfer of data between multiple computing devices (700) and/or the Internet.
  • Data transferred via the external communications interface (730) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal.
  • the external communications interface (730) may enable communication of data between the computing device (700) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (700) via the communications interface (730).
  • the external communications interface (730) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-FiTM), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuitry.
  • the external communications interface (730) may include a subscriber identity module (SIM) in the form of an integrated circuit that stores an international mobile subscriber identity and the related key used to identify and authenticate a subscriber using the computing device (700).
  • SIM subscriber identity module
  • One or more subscriber identity modules may be removable from or embedded in the computing device (700).
  • the external communications interface (730) may further include a contactless element (750), which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer element, such as an antenna.
  • the contactless element (750) may be associated with (e.g., embedded within) the computing device (700) and data or control instructions transmitted via a cellular network may be applied to the contactless element (750) by means of a contactless element interface (not shown).
  • the contactless element interface may function to permit the exchange of data and/or control instructions between computing device circuitry (and hence the cellular network) and the contactless element (750).
  • the contactless element (750) may be capable of transferring and receiving data using a near field communications capability (or near field communications medium) typically in accordance with a standardized protocol or data transfer mechanism (e.g., ISO 14443/NFC).
  • Near field communications capability may include a short-range communications capability, such as radio frequency identification (RFID), BluetoothTM, infra-red, or other data transfer capability that can be used to exchange data between the computing device (700) and an interrogation device.
  • RFID radio frequency identification
  • BluetoothTM BluetoothTM
  • infra-red infra-red
  • the computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data.
  • a computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (710).
  • a computer program product may be provided by a non-transient computer-readable medium, or may be provided via a signal or other transient means via the communications interface (730).
  • Interconnection via the communication infrastructure (705) allows the one or more processors (710) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components.
  • Peripherals such as printers, scanners, cameras, or the like
  • input/output (I/O) devices such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like
  • I/O input/output
  • One or more displays (745) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (700) via a display (745) or video adapter (740).
  • a software unit is implemented with a computer program product comprising a non-transient computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described.
  • Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, JavaTM, C++, or PerlTM using, for example, conventional or object-oriented techniques.
  • the computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
  • a non-transitory computer-readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM.
  • RAM random access memory
  • ROM read-only memory
  • magnetic medium such as a hard-drive
  • optical medium such as a CD-ROM.

Landscapes

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

Abstract

L'invention concerne un adaptateur (10) destiné à une imprimante, un procédé d'authentification de paiement et un système d'authentification de paiement. L'adaptateur (10) comporte une première interface (14) qui relie l'adaptateur (10) à l'imprimante et une deuxième interface (16) qui permet une communication entre l'imprimante et un système de point de vente. L'adaptateur (10) comprend un dispositif (20) d'authentification de paiement qui comprend une interface (22) sans fil servant à communiquer avec un dispositif mobile d'un client. Une troisième interface (28) de l'adaptateur est reliée au dispositif (20) d'authentification de paiement et est configurée pour émuler un terminal de paiement.
PCT/IB2019/057911 2018-09-21 2019-09-19 Adaptateur pour imprimante WO2020058900A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19863626.8A EP3853797A4 (fr) 2018-09-21 2019-09-19 Adaptateur pour imprimante

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ZA2018/06340 2018-09-21
ZA201806340 2018-09-21

Publications (1)

Publication Number Publication Date
WO2020058900A1 true WO2020058900A1 (fr) 2020-03-26

Family

ID=69888433

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/057911 WO2020058900A1 (fr) 2018-09-21 2019-09-19 Adaptateur pour imprimante

Country Status (2)

Country Link
EP (1) EP3853797A4 (fr)
WO (1) WO2020058900A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004105359A2 (fr) * 2003-05-19 2004-12-02 Einar Rosenberg Dispositif et procede permettant d'obtenir une securite accrue au cours de transactions par voie hertzienne
US7835942B1 (en) * 2000-10-18 2010-11-16 Ultra Proizvodnja Elektronskih Naprav System for payment data exchange and payment terminal device used therein
WO2011112158A1 (fr) * 2010-03-10 2011-09-15 Margento R&D D.O.O. Système de transaction mobile sans fil et procédure pour la réalisation de transactions avec un téléphone mobile
US20120197806A1 (en) * 2011-01-31 2012-08-02 Jason Lester Hill Sonic based digital networking
WO2016186851A1 (fr) * 2015-05-19 2016-11-24 Alibaba Group Holding Limited Dispositif de paiement mobile sans fil

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040223180A1 (en) * 2003-05-08 2004-11-11 Transact Technologies Incorporated Transactional printer with wireless communication to host
US20140122272A1 (en) * 2008-07-08 2014-05-01 Omnilync, Inc. Transaction data capture device and system
US20120185306A1 (en) * 2011-01-18 2012-07-19 Fang Cheng Electronic Transaction Record Distribution System
US20180181951A1 (en) * 2016-12-22 2018-06-28 AppCard, Inc. Apparatus and methods for processing commercial transaction data

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7835942B1 (en) * 2000-10-18 2010-11-16 Ultra Proizvodnja Elektronskih Naprav System for payment data exchange and payment terminal device used therein
WO2004105359A2 (fr) * 2003-05-19 2004-12-02 Einar Rosenberg Dispositif et procede permettant d'obtenir une securite accrue au cours de transactions par voie hertzienne
WO2011112158A1 (fr) * 2010-03-10 2011-09-15 Margento R&D D.O.O. Système de transaction mobile sans fil et procédure pour la réalisation de transactions avec un téléphone mobile
US20120197806A1 (en) * 2011-01-31 2012-08-02 Jason Lester Hill Sonic based digital networking
WO2016186851A1 (fr) * 2015-05-19 2016-11-24 Alibaba Group Holding Limited Dispositif de paiement mobile sans fil

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3853797A4 *

Also Published As

Publication number Publication date
EP3853797A4 (fr) 2022-06-22
EP3853797A1 (fr) 2021-07-28

Similar Documents

Publication Publication Date Title
AU2017203373B2 (en) Provisioning payment credentials to a consumer
CN111357025B (zh) 安全qr码服务
US10922675B2 (en) Remote transaction system, method and point of sale terminal
US20160117673A1 (en) System and method for secured transactions using mobile devices
US20130226812A1 (en) Cloud proxy secured mobile payments
US20150142666A1 (en) Authentication service
US10977641B2 (en) Binding process using electronic telecommunications device
US20150142669A1 (en) Virtual payment chipcard service
US20220060889A1 (en) Provisioning initiated from a contactless device
US20150142667A1 (en) Payment authorization system
US11296862B2 (en) Provisioning method and system with message conversion
CA2943854A1 (fr) Systeme de transaction a distance, procede et terminal de point de vente
US20220291979A1 (en) Mobile application integration
EP3853796A1 (fr) Dispositif d'authentification de paiement, système d'authentification de paiement et procédé d'authentification de paiement
CA2919323C (fr) Systeme et procede de production de justificatifs d'identite de paiement
EP3853797A1 (fr) Adaptateur pour imprimante
EP4179697B1 (fr) Appariement sécurisé de bout en bout d'un élément sécurisé à un appareil mobile
EP4191496A1 (fr) Dispositifs, procédés et système de transactions de paiements électroniques sécurisées

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: 19863626

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019863626

Country of ref document: EP

Effective date: 20210421