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/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
• • 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/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/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable 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]
• • 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/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in 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/326—Payment applications installed on the mobile devices
  • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
• • 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/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
• • 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/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
  • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
  • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
• • 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
  • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Definitions

• This invention relates to mobile payments. More particularly, but not exclusively, this invention relates to a payment authentication device and an associated system and method of authenticating payment.
• 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
• 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. 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 the information on the magnetic stripes of cards easy to clone and use without the card holder’s knowledge.
• NFC Near-field communication
• Mobile payments generally involve a user of a mobile phone scanning a code at a POS, whereafter the user is prompted to enter an amount to pay.
• SMS short message service
• internet data packet is sent to the merchant to confirm that the payment has been processed.
• SMS messages and/or data packets may be prone to interception, falsification, modification or replay attacks by unscrupulous parties.
• the confirmation messages are sometimes delayed or not delivered at all.
• Point of sale transactions often occur in environments where the merchant does not have a reliable internet and/or electricity connection and as a result, electronic payments cannot be accepted in these environments. This may cause the merchant to lose business because many customers may prefer to do cashless transactions.
• a payment authentication system comprising: a payment authentication device which includes a wireless interface for communicating with a mobile device of a customer, the payment authentication device being configured to transmit a transaction request including transaction data to the mobile device; 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.
• the payment authentication device to include a microprocessor and a memory in which is stored a public key and a private key; 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; for the payment authentication device to be configured to sign the transaction request using the private key stored in the memory, and to use the public key to authenticate the payment attestation certificate when it is received from the mobile device in order to authenticate that payment has been effected.
• the payment attestation certificate may alternatively be authenticated by the mobile device using a public key that is stored in a memory of the mobile device.
• the payment authentication device to be an offline device (in other words, it does not require Internet connectivity); and for the payment authentication device to include a battery for powering the microprocessor.
• transaction data to include one or more of the following: information about a point of sale; information about the payment authentication device; and/or a payment amount.
• the payment authentication device to be configured to transmit an instruction signal upon receiving the certificate; for the instruction signal to include any one or more of the following instructions: an opening instruction to open a locking device; instructing a device to release a product; and displaying a visual indication or emitting a sound indicative of whether payment is successful or not.
• the wireless interface may be provided by a wireless technology selected from the list comprising: BluetoothTM, Bluetooth Low Energy (BLE), Near-field communication (NFC), WiFiTM 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 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.
• a payment authentication device comprising: a microprocessor and a memory in which is stored a public key and a private key associated with the device; 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.
• the payment authentication device to be provided in a portable offline device which includes a battery or other power source.
• a method of authenticating payment the method being conducted by a payment authentication device, the method comprising: establishing a wireless link between the payment authentication device 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 method of authenticating payment the method being conducted by a backend, the method comprising: receiving a transaction request from a payment authentication device, 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 to authenticate that payment has been effected.
• the backend to include a cryptographic server or an attestation certificate generator server.
• a yet 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.
• an authentication system comprising: an authentication device which includes a wireless interface for communicating with a mobile device of a user, the authentication device being configured to sign an attestation request using a private key stored in a memory associated with the device, and to transmit the attestation request to the mobile device; a backend that includes an attestation certificate generator server, the backend being configured to receive the signed attestation request from the mobile device whereupon the attestation certificate generator server is configured, responsive to authenticating that the attestation request originated from the authentication device and responsive to confirming that the user is an authorised user, to generate an attestation certificate and to transmit the attestation certificate to the mobile device wherefrom it is relayed to the authentication device.
• the authentication device to be arranged to transmit an instruction signal, responsive to receiving the attestation certificate.
• Still further features provide for the authentication device to be provided in an access control environment, and for the instruction signal to comprise an opening signal that causes a gate, turnstile, barrier or the like to open when the user is an authorised user.
• Figure 1 is a high-level block diagram illustrating an exemplary payment authentication system including a payment authentication device
• Figure 2 is another high-level block diagram, similar to Figure 1 , but illustrating an alternative embodiment of the system
• Figure 3 is a swim-lane flow diagram illustrating an example of a method of authenticating payments using the present disclosure
• Figure 4 is a high-level block diagram illustrating the payment authentication device in more detail
• Figure 5 illustrates an example of a computing device in which various aspects of the disclosure may be implemented
• Figure 6 is a high-level block diagram illustrating another exemplary embodiment of a payment authentication system
• Figure 7 is a high-level block diagram illustrating yet another exemplary embodiment of a payment authentication system.
• Figure 8 is a swim-lane flow diagram illustrating a further example of a method of authenticating payments. DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS
• the payment authentication device may be used by a merchant or vendor in a retail or other commercial environment.
• the payment authentication device may be arranged to verify, authenticate or attest that a payment transaction has been successfully effected.
• the payment authentication device may be a payment authentication component of an electronic device, such as a stand-alone device which can be used to authenticate payments.
• the stand-alone device may for example be a portable device.
• the payment authentication device need not be provided in a stand-alone electronic device and may be provided in a variety of locations, or may be provided in a variety of electronic devices as is evident from the present disclosure.
• the payment authentication device may be arranged to wirelessly connect to a mobile device or smartphone of a user or customer and to send a digitally signed transaction request to the mobile device.
• a cryptographic token or attestation certificate may then be received by the payment authentication device from the mobile device.
• the attestation certificate may be authenticated and an instruction signal may be transmitted by the payment authentication device.
• the payment authentication device may also be referred to as a payment attestation device.
• FIG. 1 is a high-level block diagram which illustrates an exemplary payment authentication device (10) provided in a payment authentication system (100).
• the payment authentication device (10) may include a wireless interface (12) for communicating with a mobile device (14) of a customer (16).
• the payment authentication device (10) may be configured to transmit a transaction request (18) including transaction data to the mobile device (14).
• a backend (20) may be provided and may include a payment processor (22) and an attestation certificate generator server (24) (which may be a cryptographic server).
• the backend (20) may be configured to receive the transaction request (18) from the mobile device (14), whereupon the payment processor (22) may effect payment.
• the payment processor (22) may be instructed by the mobile device (14), to effect payment.
• the payment processor (22) may form part of the backend (20), or it may be provided separately from the backend.
• the attestation certificate generator server (24) may in turn be configured, responsive to a successful payment, to generate a payment attestation certificate (26) and to transmit the certificate (26) to the mobile device (14), wherefrom it may be relayed to the payment authentication device (10) to authenticate the payment.
• FIG. 4 is a block diagram which illustrates exemplary components of the payment authentication device (10).
• the payment authentication device (10) may include a microprocessor (28).
• the processor (28) 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 (10).
• the payment authentication device (10) also includes a memory (30) or memory component, and the software units may be stored in the memory component (30) and instructions may be provided to the processor (28) to carry out the functionality of the described components.
• a private key may be stored in the memory (30), and/or may be stored in a secure cryptographic element associated with the payment authentication device (10), for example during manufacturing thereof.
• the payment authentication device (10) also includes a transmitting component (32) and a receiving component (34).
• security features for the relevant device may be programmed into a security chip or microchip of the payment authentication device (10).
• Other security data for example a unique identifier
• a public key associated with a secure backend or attestation certificate generator server (24) may also be pre-stored in the memory (30).
• the payment authentication device (10) 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 (10) may further include a signing component (31 ) configured to digitally sign the transaction request (18) using the private key stored in the memory (30), and an authenticating component (33) which may be arranged to authenticate the payment attestation certificate (26) using the public key in order to authenticate or verify that payment has been effected.
• the payment authentication device (10) may be provided at a point of sale (38) which may for example be a retail or other commercial environment that the customer (16) visits. Examples of point of sale locations may include (but are not limited to) public transport (40), retail stores (42), the restaurant and catering industry (44) (including deliveries), automated vending machines (46), automated parking payment machines (48), however, many more are possible.
• the payment authentication device may be connected to, or it may form part of any of these machines or devices.
• the payment authentication device (10) may be integrated into a parking payment machine, or into a vending machine, or into any electronic device provided at the relevant point of sale.
• a merchant (50) or beneficiary may be associated with the point of sale (38) and the payment authentication device (10) may be provided at the merchant’s (50) premises, e.g. at a retail store.
• the payment authentication device (10) is incorporated into a wearable or portable device (1 1 ), which may for example be worn like a watch or attached to a tether or lanyard.
• a code such as a QRTM code (52) may be provided at the merchant’s (50) premises (for example, displayed somewhere at the retail store).
• the customer (16) may enter the premises and may intend to pay for goods or services provided by the merchant (50).
• the customer may install (or may have pre-installed) a mobile application (app) (53) executing on the mobile device (14).
• the customer (16) may then, via the app (53), use a camera of the mobile device (14) to capture an image of the code (52).
• the code may contain information about the payment authentication device (10) for example a media access control (MAC) address associated therewith.
• the MAC address may then be used by the mobile device (14) to establish a wireless link (54) between the mobile device (14) and the payment authentication device (14) via the wireless interface (12). Pairing may be performed, but a pairing step may not be necessary in the embodiment shown.
• the QR code may be omitted as will be described in more detail below.
• the payment authentication device (10) may generate a transaction request (18) 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 (50) (information about a financial institution associated with the merchant such as bank account details of the merchant); information about the point of sale (38); information about the payment authentication device (10); and/or an amount and currency of the required payment (for example United States Dollars $).
• the information about the payment authentication device (10) may for example be a serial number assigned thereto, or other data relating to the device (10).
• the information about the payment authentication device may be signed with a server-based private key and stored into the memory (30) (or secure element) during manufacturing thereof.
• the transaction request (18) may also be digitally signed by the payment authentication device (10) using the private key associated with the payment authentication device (10). A reference number of the relevant payment transaction may also be included in the transaction data of the transaction request (18).
• the transaction request (18) may be transmitted to the mobile device (14) by the payment authentication device via the wireless link (54).
• the transaction request may include the amount to be paid, and in another embodiment the customer (16) may be prompted by the app (53) to enter the amount (56) to be paid when guided through the payment process, whereafter the mobile device (14) may transmit the amount to be paid back to the payment authentication device (10) which then includes the payment amount into the signed transaction request (18) before again transmitting the signed transaction request via the mobile device (14) to the backend (20).
• the mobile device (14) may also be arranged to include information about the customer (16), (for example information about a financial institution associated with the customer (16), such as bank account details of the customer) into the transaction request (18). It is also envisaged that embodiments are possible wherein the payment authentication device (10) may generate a digitally signed pro-forma invoice which may be transmitted with the transaction request (18) to the mobile device (14). Even though it is not presently preferred, embodiments may be possible wherein the transaction request may be digitally signed by the mobile device.
• the mobile device (14) may then transmit the transaction request (18) with the transaction data to the payment processor (22) such as a bank or other financial institution at the backend (20) (or separate from the backend).
• the payment processor (22) 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 (16) (or an intermediary account) to a bank account of the merchant (50).
• the payment processor (22) may transmit a proof of payment (58) to the mobile device (14).
• the mobile device (14) may transmit the proof of payment (58) to the attestation certificate generator server (24) which may, in some embodiments, form part of the backend (20).
• the attestation certificate generator server (24) may, in turn, be configured to generate the payment attestation certificate (26) which may be digitally signed. This certificate may be unique for every payment transaction. Depending on the type of payment processor (22) involved, the certificate generator server (24) may be required to transmit a verification request (60) to the payment processor (22), whereupon the payment processor may transmit a verification (62) to the attestation certificate generator server (24), indicative that payment was successful. The attestation certificate generator server (24) may generate the attestation certificate (26) which may be a digitally signed payment certificate or attestation or token which may indicate that payment was successfully processed by the payment processor (22).
• the certificate (26) 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 may then be transmitted to the mobile device (14) by the attestation certificate generator server (24).
• the mobile device (14) may transmit the attestation certificate (26) via the wireless link (54) to the payment authentication device (10), where it may be authenticated using the relevant public key, which may be pre-stored in the memory (30).
• This may enable the payment authentication device (10) to securely (and/or reliably) verify or confirm that payment was indeed successfully processed, and responsive thereto, the payment authentication device may transmit an instruction signal (or it may cause an action to be performed).
• the payment authentication device (10) may be arranged to verify the authenticity of a successful payment.
• the instruction signal may for example include any one or more of the following instructions: an opening instruction to open a locking device (such as in an access control implementation); instructing a device to release a product (such as in the automated vending machine implementation (46)); and displaying a visual indication or emitting a sound indicative of whether payment is successful or not (e.g. in the case of the wearable device (1 1 )).
• the payment authentication device (10) may be an offline device which does not require Internet connectivity, and it may include a battery for powering the microprocessor (28) and/or other components associated with the device (10).
• the merchant (50) may initiate the payment transaction by pressing a relevant button (64) on the portable device (1 1 ).
• a plurality of buttons or other user input methods may also be provided.
• the customer (16) may then start the application (53) on their mobile device (14) (or the app may already be running).
• the customer may then bring the mobile device (14) into proximity with the portable device (1 1 ) whereupon the wireless link (54) may be established (preferably automatically).
• the customer may then enter the amount (56) to pay, whereafter the amount (56) may also be displayed on a screen (67) of the portable device (1 1 ).
• the merchant (50) may then confirm the amount by pressing the button (64) again.
• the customer’s mobile device (14) may then connect to the customer’s relevant payment processor (22) (which may, or may not form part of the backend (20), depending on the particular implementation), whereafter the payment transaction may be processed.
• the customer’s mobile device (14) (and/or the payment processor (22)) may then request the attestation certificate (26) from the attestation certificate generator server (24).
• the attestation certificate (26) may then be forwarded or relayed via the wireless link (54) to the payment authentication device (10) of the portable device (1 1 ).
• the payment authentication device (10) may confirm the authenticity of the payment transaction and the portable device (1 1 ) may display an appropriate message on the screen (67), such as“Payment of $16.77 successfully processed”.
• the payment authentication device (10) may be provided in a variety of applications or implementations, and it may be incorporated into a variety of devices at point of sale locations (38).
• the payment authentication device may thus be a payment authentication component of the portable device (1 1 ).
• the payment authentication device may be a payment authentication component of an electronic device.
• the backend (20) of the system (100) may include a transaction server (36), which may be provided in data communication with the mobile device (14).
• the transaction server (36) may be in communication with the payment processor (22) on the one hand, and with the attestation certificate generator server (24) on the other.
• the transaction server (36) may receive the transaction request (18) from the mobile device (14).
• the transaction request (18) may be relayed via the mobile device (14) from the payment authentication device (10).
• the transaction server (36) may transmit the transaction request (18) to the payment processor (22), and may request the attestation certificate (26) from the attestation certificate generator server (24).
• the attestation certificate generator server (24) may transmit the attestation certificate (26) to the transaction server (36) wherefrom it may be relayed to the mobile device (14), and to the payment authentication device (10). More than one payment option may be provided to the customer (16) via the app (53), so that the customer (16) may select a preferred payment processor for the particular payment transaction at hand.
• the payment authentication device may be provided in, or connected to any electronic device at the point of sale (40, 42, 44, 46, 48). Other types of point of sale locations may also be possible.
• the payment processor (22) may request the attestation certificate (26) directly from the attestation certificate generator server (24) and may transmit the certificate (26) to the mobile device (14). This may eliminate the need for an additional request (for the proof of payment (58) shown in Figure 1 ) from the mobile device (14) and may increase security, because the attestation certificate generator server (24) may be placed in a so-called“de-militarized zone” (DMZ) that may only be accessible by payment processors.
• DMZ de-militarized zone
• a computing device (51 ) may be provided and it may be associated with the merchant (50).
• the merchant or merchants
• the merchant may be enabled to utilise the computing device (51 ) to directly obtain data from the backend (20).
• a management application or interface may be provided (for example by way of downloadable and installable software) on the computing device (51 ) and may enable reconciliation features (which may be performed“after-the-fact”).
• the merchant (50) may be enabled to view information about the customer (16) such as a history of financial transactions of the customer (16), using the computing device (51 ).
• Data relating to previous requests (18) and certificates (26) of the customer (16) may be stored in a database at the backend (20) 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 (10) may also be configured to transmit information about the customer (16) to the computing device (51 ), which may enable the management application to look up, or to retrieve data relating to the customer (16) from the backend (20).
• the merchant may be 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 payment processor (22) may a bank or a digital payment processor, and it may include services such as those 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 (16) and an account of the merchant (50).
• 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) (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.
• BLE BluetoothTM Low Energy
• NFC Near-field communication
• WiFiTM WiFiTM
• RFID radio-frequency identification
• the app may be configured to enable the mobile device (14) to“listen” or scan for a signal (such as an advertisement signal) including a MAC address, transmitted by a nearby payment authentication device (10), whereafter the payment process may be initiated.
• a signal such as an advertisement signal
• the mobile device 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 (10).
• RSSI may be used by the mobile device to determine a distance between the mobile device and the payment authentication device (10).
• the wireless link (54) may be automatically established when the mobile device is close enough to the payment authentication device (10).
• 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 (10) to the mobile device (14), so that the wireless link (54) may be established.
• the payment authentication device (10) 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 (14) when it is near enough to the payment authentication device (10).
• a sound signal for example a low volume sound signal
• the MAC address may even be retrieved from the internet by the mobile device (14) by looking up the MAC address on a resolving Internet server.
• An advertisement may also be displayed on a screen of the mobile device (14) once the wireless link (54) has been established and/or a digital voucher (which may be a digitally signed redeemable voucher) may be generated for the customer (16) as required.
• the described systems may implement a method of authenticating payment.
• FIG. 3 is shown a swim-lane flow diagram illustrating an example of a method of authenticating payment (200) using the system (100) of Figures 1 or 2 (or using any of the systems described herein).
• the swim-lane flow diagram shows respective swim-lanes that delineate steps, operations or procedures performed by respective entities or devices.
• the wireless link (54) may be established (210) between the payment authentication device (10) and the mobile device (14) of the customer (16).
• the transaction request (18) including the transaction data may be signed (212) using the pre-stored private key associated with the payment authentication device (10) (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 (18) may be transmitted (214) to the mobile device (14).
• the payment attestation certificate (26) may be received (216) from the mobile device (14).
• the payment attestation certificate (26) may be authenticated (218) using the pre-stored public key, to enable the payment authentication device (10) to verify or confirm that payment has been effected.
• An instruction signal may be transmitted (220) to the relevant device to perform the relevant action as described above (for example display a message, open a barrier, release a product, etc.).
• the transaction request (18) may be received (222) from the payment authentication device (10).
• the transaction request may be transmitted (224) to the payment processor (22).
• the proof of payment (58) may be received (226) from the payment processor (22).
• the proof of payment (58) may be transmitted (228) to the attestation certificate generator server (24).
• the attestation certificate (26) may be received (230) from the attestation certificate generator server (24), and the attestation certificate may be transmitted (232) to the payment authentication device (10).
• the proof of payment (58) may be received (234) from the mobile device (14).
• the attestation certificate generator server (24) may optionally transmit (236) the verification request (60) to the payment processor (22), and the verification (62) may be received (238) by the attestation certificate generator server (24).
• the attestation certificate (26) may be generated and signed (240) with the server-side private signer key, and the attestation certificate (26) may be transmitted (242) to the mobile device (14).
• the public key associated with the payment authentication device 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 is stored securely on the device.
• the associated public key (and other device information, e.g. serial number) may be digitally signed by a server provided for that purpose (which may be referred to as a provisioning server) and a resulting certificate may then also be stored on the payment authentication device.
• 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 may sign the request with its own private key and it may include its credentials therein. Since the credentials may have been digitally signed previously, the credentials may be verified by an external party. This may validate 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. This can happen during manufacturing (test realm) or later during the commissioning process (operating realm).
• 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 (24) may be able to determine that the transaction request (18) was indeed generated by an authentic payment authentication device (10).
• Information about the payment authentication device, including a unique identification number or serial number thereof may also be transmitted with the transaction request that is received at the attestation certificate generator server (24).
• the transaction request (18) may include an embedded device certificate generated as part of the manufacturing and configuration of the payment authentication device (10), which can be used to verify the authenticity of the device.
• the device certificate may be digitally signed. This verification may be performed by any computing device with access to the relevant public key, including the customer’s mobile device (14), the attestation certificate generator server (24) (which may also be referred to as the cryptographic server) at the backend.
• the payment authentication device (10) and the systems and methods described herein) may provide the functionality of verifying successful payment without requiring an internet connection of the payment authentication device (10) itself.
• 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 attestation certificate generator server to the payment authentication device in a secure fashion, because the attestation certificate is digitally signed using asymmetric cryptography (or another cryptographically secure protocol or system).
• asymmetric cryptography or another cryptographically secure protocol or system.
• 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 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 (both with reference to the attestation certificate generator server (24) and the payment authentication device (10)) may be changed from time to time (i.e. these keys may be transient or short-lived), which may increase security.
• a cryptographically secure key exchange protocol may be used when the attestation certificate is transmitted from the attestation certificate generator server (24) to the mobile device (14) and from the mobile device (14) to the payment authentication device (10).
• the attestation certificate (26) may be authenticated by the payment authentication device (10).
• 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 payment transaction may be authenticated or validated by the payment authentication device (10) securely and in near real time which may provide a user experience similar to that of a contactless payment system. 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 digital signature can be used to verify the authenticity of the contents of the relevant certificate or token.
• 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 while guiding the customer 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.
• a plurality of 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 (20). Even though it is not presently preferred, particulars of the customer may in some embodiments be stored at the attestation certificate generator server (24).
• 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 (10) 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 (10) changes).
• Having 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 (20) to sign the cryptographic attestation certificate (26) transmitted to the payment authentication device (10) after a successful payment as described herein.
• 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 is transmitted with the transaction request (18).
• the transaction request (18) may be in the form of a digitally signed transaction request certificate (a cryptographic certificate) generated by the payment authentication device (10).
• the payment authentication device (10) may further be configured to keep a digital journal of processed payment transactions and to store details, data or information about the payment transactions into its memory (30).
• FIG. 6 is shown a high-level block diagram of another exemplary embodiment of a payment authentication system (1000).
• 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 (1000) shown in Figure 6.
• a customer (1016) may utilise 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 (10) described above. It may for example be provided in a portable device (101 1 ) 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 or to the portable device (101 1 )) 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 (1072) 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 6.
• 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.
• 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 application(s) (1074).
• FIG. 7 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 7.
• the system (2000) may implement a method of authenticating payments.
• FIG. 8 An exemplary method (3000) of authenticating payments is illustrated in the swim-lane flow diagram of Figure 8 (in which respective swim-lanes delineate steps, operations or procedures that may be performed by respective entities or devices).
• Figure 7 is similar to Figure 6, 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 “PAD”) 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 PAD (2010).
• URL Uniform Resource Locator
• 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 PAD (2010) (as also described above with reference to Figure 1 ).
• the customer may for example be prompted to enter the payment amount (or alternatively, the payment amount may be entered by the merchant onto the PAD and it may be sent to the mobile device).
• the 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 PAD (2010).
• a payment request certificate may be generated (the PRC may be similar to the transaction request (18) described above).
• the PRC may be transmitted (3022) by the PAD 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).
• POP proof of payment
• 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 (26, 1026) described above.
• 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 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 was effected.
• the PAD (2010) may transmit (3068) the instruction signal.
• 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 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 payment authentication device may also be an attestation device, which may be utilised to confirm the occurrence of an event.
• This event is not necessarily limited to a financial transaction.
• the portable device may be re-programmed to be used in an access control environment, where an access control system can issue and/or request attestation certificates and verify access authorisation certificates.
• a turnstile, gate or barrier may include an attestation device which may be configured to verify that a particular person is authorised to have access to a specific place or building.
• the transaction server may be an authorisation server which may include a database.
• the system may be an authentication system including the authentication device which is configured to sign an attestation request using a private key pre stored in a memory associated with the device, and to transmit the attestation request to the mobile device of the user.
• the backend may include the attestation certificate generator server and the authorisation server (but not the payment processor).
• the backend may be configured to receive the signed attestation request from the mobile device whereupon the attestation certificate generator server may be configured, responsive to authenticating that the attestation request originated from the relevant authentication device and responsive to confirming that the user is an authorised user (for example by instructing the authorisation server to look up the user in the database of the authorisation server or by requiring the user to log in to the app), to generate an attestation certificate and to transmit the attestation certificate to the mobile device wherefrom it may be relayed to the authentication device.
• the authentication device may, in turn, be arranged to transmit an instruction signal, responsive to receiving the attestation certificate and having authenticated it using the relevant public key.
• the instruction signal may for example be an opening signal that causes a gate, turnstile, barrier or the like to open when the user is an authorised user.
• a customer or client or patient registration system may be implemented that may create a personal information request to verify personal identity certificates or credentials of the person (which may prevent or alleviate identity theft and/or cloning of personal particulars).
• delivery of goods including waybills or other documents that are distributed in a supply chain
• delivery certificates may be generated to verify proof of delivery.
• Secure confirmation of identity may be performed, for example in an embodiment where the merchant is a loan provider and loan applications may be provided to the customer.
• the customer’s identity may then be verified by the system, before the loan is granted.
• Other embodiments where the customer’s identity needs to be verified are also possible.
• FIG. 5 illustrates an example of a computing device (500) in which various aspects of the disclosure may be implemented.
• the computing device (500) 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
• the computing device (500) 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 (500) to facilitate the functions described herein.
• the computing device (500) may include subsystems or components interconnected via a communication infrastructure (505) (for example, a communications bus, a network, etc.).
• the computing device (500) may include one or more processors (510) and at least one memory component in the form of computer-readable media.
• the one or more processors (510) 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 (500) 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 (515), 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 (515) including operating system software.
• the memory components may also include secondary memory (520).
• the secondary memory (520) may include a fixed disk (521 ), such as a hard disk drive, and, optionally, one or more storage interfaces (522) for interfacing with storage components (523), 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 (500) may include an external communications interface (530) for operation of the computing device (500) in a networked environment enabling transfer of data between multiple computing devices (500) and/or the Internet.
• Data transferred via the external communications interface (530) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal.
• the external communications interface (530) may enable communication of data between the computing device (500) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (500) via the communications interface (530).
• the external communications interface (530) 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 (530) 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 (500).
• SIM subscriber identity module
• One or more subscriber identity modules may be removable from or embedded in the computing device (500).
• the external communications interface (530) may further include a contactless element (550), 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 (550) may be associated with (e.g., embedded within) the computing device (500) and data or control instructions transmitted via a cellular network may be applied to the contactless element (550) 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 (550).
• the contactless element (550) 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 (500) 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 (510).
• 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 (530).
• Interconnection via the communication infrastructure (505) allows the one or more processors (510) 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 controller such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like
• One or more displays (545) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (500) via a display (545) or video adapter (540).
• 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.
• 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.
• Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the

Applications Claiming Priority (2)

Publications (2)

Family

ID=69888431

Family Applications (1)

Country Status (2)

Families Citing this family (1)

Family Cites Families (9)

• 2019
  • 2019-09-18 EP EP19863066.7A patent/EP3853796A4/de active Pending
  • 2019-09-18 WO PCT/IB2019/057844 patent/WO2020058861A1/en unknown

Also Published As

Similar Documents

Legal Events