AU2017101080A4

AU2017101080A4 - Method and System for Facilitating a Payment Transaction

Info

Publication number: AU2017101080A4
Application number: AU2017101080A
Authority: AU
Inventors: Damien Vasta
Original assignee: Sniip Australia Ltd
Current assignee: Sniip (australia) Ltd
Priority date: 2017-08-09
Filing date: 2017-08-09
Publication date: 2017-09-07
Anticipated expiration: 2025-08-09

Abstract

A method for facilitating a payment transaction, the method comprising the steps of: sending, from a first electronic device associated with a first user, a payment message including a payment amount; receiving, with a second electronic device associated with a second user, the payment message, the payment message being received by the second electronic device via a blockchain from the first electronic device; and wherein the payment message includes an authorisation request adapted to actuate one or more authorisation servers to authorise transfer of the payment amount from a payment credential of the first user to a payment credential of the second user, or from a payment credential of the second user to a payment credential of the first user. DRAWINGS 11 18 15 Me F rienrd s o Gotham C ity Counc o $325.00 Rates Bill 12345678 is due today Jessica requested $27.00 10 17 -- Pizz. and good times! i1 P ir You paid ABC Utility company< - 16 $ 320.50 Home Water Bill , You paid Jas $4.50 Morning coffee -a t @17 Pay RequesI 6lils Sea 19 20 21 22

Description

1 2017101080 09 Aug 2017

METHOD AND SYSTEM FOR FACILITATING A PAYMENT TRANSACTION TECHNICAL FIELD

[0001] The present invention relates to a method and system for facilitating a payment transaction. In particular, the present invention relates to a method and system for facilitating a payment transaction directly between the electronic devices of two or more users.

BACKGROUND ART

[0002] With the increased acceptance and use of electronic commerce (“e-commerce”), a number of electronic payment systems have been developed. These systems typically allow users to conduct payment transactions with financial institutions, merchants and/or other users.

[0003] Conventional electronic payment systems suffer from a number of drawbacks. For instance, in many conventional electronic payment systems, it is not unusual for a processing delay of several days to be experienced between a payment being sent from a payer’s account to it being received in a recipient’s account. This can lead to concerns that the payment was not correctly made. In addition, particularly for large transactions, this delay has the potential to lead to cash flow problems for the recipient.

[0004] In addition, many conventional electronic payment systems are standalone applications that require users to open an account with that application for the sole purpose of sending or receiving a payment. Some users may find this inconvenient, thereby discouraging use of the system.

[0005] Some attempts have been made to overcome these drawbacks. For instance, International patent application no. WO 2016/099492 discloses the use of an electronic payment system in which a payment is formatted for same day processing, thereby minimising the delay in receiving an electronic payment. However, this system suffers from the drawback that the electronic communication that includes the payment is not received by the recipient directly from the payer, but instead is received from the payer by a server, with the server then forwarding the electronic communication to the recipient. 2 2017101080 09 Aug 2017 [0006] In the event that the server is offline or experiencing high volumes of electronic traffic, a situation may arise in which the server is unable to process the payment and/or forward the electronic communication. Thus, a delay in the receipt of the payment may still be experienced.

[0007] In addition, electronic communications sent between electronic devices and/or servers using conventional systems are vulnerable to interception by third parties. If intercepted, personal financial information (such as bank account numbers, credit card information and so on) may be stolen and potentially used for fraudulent transactions.

[0008] Thus, there would be an advantage if it were possible to provide a method and system for facilitating a payment transaction that both minimised the delay between sending and receiving an electronic payment, as well as minimising the risk of the theft and misuse of a user’s personal information.

[0009] It will be clearly understood that, if a prior art publication is referred to herein, this reference does not constitute an admission that the publication forms part of the common general knowledge in the art in Australia or in any other country.

SUMMARY OF INVENTION

[0010] The present invention is directed to a method and system for facilitating a payment transaction, which may at least partially overcome at least one of the abovementioned disadvantages or provide the consumer with a useful or commercial choice.

[0011] With the foregoing in view, the present invention in one form, resides broadly in a method for facilitating a payment transaction, the method comprising the steps of: sending, from a first electronic device associated with a first user, a payment message including a payment amount; receiving, with a second electronic device associated with a second user, the payment message, the payment message being received by the second electronic device via a blockchain; and wherein the payment message includes an authorisation request adapted to actuate one or more authorisation servers to authorise transfer of the payment amount from a payment credential of the first user to a payment credential of the second user, or from a payment credential of the second user to a payment credential of the first user. 3 2017101080 09 Aug 2017 [0012] The first electronic device may be of any suitable form. For instance, the first electronic device may be a computer, mobile telephone, tablet or the like. Similarly, the second electronic device may be of any suitable form, although in some embodiments of the invention, the second electronic device may be a computer, mobile telephone, tablet or the like.

[0013] It will be understood that the first user and the second user may be any suitable entities. For instance, the first user and/or the second user may be individuals. Alternatively, the first user and/or the second user may be corporate entities or the like. Therefore, in some embodiments the transfer of money may be between individual users, corporate entities, a corporate entity and an individual and so on. The transfer of money may be as payment for goods or services procured from the first user (such as the sale or hire of goods or services), in which case the payment message may effectively be in the form of an invoice or request for payment. Alternatively, the transfer of money may be as a gift (for instance, a gift between two individual users), in which case the payment message may be to authorise the transfer of money from the first user to the second user. In other embodiments, the transfer of money may be from the first user to the second user for receipt of goods or services for which no invoice has been issued, or for which an invoice has been issued in another format (such as a paper invoice).

[0014] The payment message may include any suitable message. For instance, the payment message may be in the form of a message that allows for the initiation of a payment transaction, and may include, for instance a data package including one or more of a payment amount, a sender, a recipient, a payment method, formatting indicating how the system processes the payment method, as well as additional information such as user provided message text. The payment message may also be provided in any suitable form. For instance, the payment message may be in the form of an email, SMS message, MMS message, social network post, social network message, voice recording, video, voice mail or the like, or any combination thereof.

[0015] The payment amount may be of any suitable form. For instance, the payment amount may comprise the exact amount of money to be transferred from the payment credential of the first user to the payment credential of the second user, 4 2017101080 09 Aug 2017 or the payment credential of the second user to the payment credential of the first user (in which case, the payment message effectively acts as an invoice). Alternatively, the payment amount may comprise the amount of money to be transferred from the payment credential of the first user to the payment credential of the second user (or the payment credential of the second user to the payment credential of the first user) plus any transaction costs (such as financial institution duties, online payment system fees, currency exchange fees, taxes and the like).

The payment amount may be in any suitable currency, including one or more cryptocurrencies. Further, the payment amount may be in a combination of two or more currencies, including cryptocurrencies.

[0016] In a preferred embodiment of the invention, the payment message may be sent from the first electronic device to the blockchain, such that the payment message forms a portion of a blockchain (such as one or more blocks within a blockchain, or a portion of a block within a blockchain). In this embodiment of the invention, the first electronic device and the second electronic device may comprise nodes associated with the blockchain. It is envisaged that, in this embodiment of the invention, the authorisation server may also comprise a node associated with the blockchain.

[0017] In other embodiments of the invention, neither the first and second electronic devices, nor the authorisation server may comprise nodes associated with the blockchain. In these embodiments, the first and second electronic devices and/or the authorisation server may access the blockchain (for instance, via one or more nodes) but may not form part of the blockchain, or at least may not form part of a computational portion of the blockchain. In this embodiment of the invention, the payment message may be delivered to the second electronic device and/or the authorisation server via the blockchain.

[0018] Any suitable blockchain may be used. However, in a preferred embodiment of the invention, the blockchain may be an open source blockchain. In a specific embodiment of the invention, the blockchain may be the Hyperledger blockchain hosted by the Linux Foundation.

[0019] There are a number of advantages to the use of a blockchain in the present invention. Firstly, the use of a blockchain renders any personal information 2017101080 09 Aug 2017 5 contained in the payment message (such as names, addresses, financial information, bank or credit/debit card numbers, telephone numbers, passwords etc.) secure and difficult, if not impossible, for unauthorised users to access and steal.

[0020] In addition, the use of a blockchain means that, in the event that the authorisation server is busy or offline (for instance, for maintenance, due to power outages or the like), the payment message may still be received by the second user. Thus, the method is not reliant on the authorisation server to be operative for delivery of the payment message.

[0021] The authorisation request may be of any suitable form. For instance, the payment message (including the authorisation request) may be sent from the first electronic device to the authorisation server simultaneously with the sending of the payment message from the first electronic device to the second electronic device. Alternatively, the payment message may be received simultaneously by the second electronic device, the authorisation server and any other nodes associated with the blockchain. In another embodiment, the payment message may be received by the second electronic device and any node associated with the blockchain.

[0022] The authorisation server may be associated with any suitable entity. For instance, the authorisation server may be associated with a financial institution (a bank, credit union, credit card provider or the like), an online payment system (such as an online payment system associated with a mobile app), social network or the like.

[0023] In a particular embodiment of the invention, the server may be associated with an integrated payment and message system. By integrating the online payment system and a messaging system, the system may provide users with the ability to send and receive electronic payments within the flow of a conversation. In this way, the system allows users to communicate with regards to a payment transaction and then conduct the payment transaction without having to open a separate application adapted to conduct electronic payment transactions. This provides a significant advantage to users in terms of improving the ease and speed with which electronic payment transactions may be conducted. 6 2017101080 09 Aug 2017 [0024] The payment credential of the first user and the payment credential of the second user may be of any suitable form. For instance, the payment credentials may be financial institution accounts, credit cards, debit cards, an account with an online payment system, a messaging account, a gift card, or any other account in which money may be withdrawn or deposited, or any suitable combination thereof. In some embodiments of the invention, such as when the authorisation server is associated with a financial institution, the users may be able to nominate one or more payment credentials from those the user already holds with the financial institution.

[0025] Alternatively, in embodiments of the invention in which the authorisation server is associated with an online payment system or social network (or integrated payment and message system), it is envisaged that the first user and/or the second user may be required to register one or more payment credentials with the online payment system, or open an account (a membership account and/or a financial account) with the online payment system, prior to being able to send and/or receive payments using the method of the present invention, or, alternatively, to send and/or receive payment messages using the method of the present invention.

[0026] The sending of the payment message (which includes the authorisation request) may actuate the authorisation server in any suitable manner. For instance, the payment message may generate an actionable alert or request that requires the entity associated with the authorisation server to take action to authorise transfer of the payment amount. Preferably, however, the authorisation request is in the form of machine-readable code that is read or recognised by the authorisation server such that the authorisation server automatically takes the necessary action to authorise transfer of the payment amount. Any suitable action may be taken, such as confirming the identity of the first user and/or the second user (so as to minimise the risk of fraudulent transaction), confirming the existence and/or validity of the payment credential of the first user and/or the second user, confirming that at least the amount of money equal to the payment amount is available for transfer from the payment credential of the first user or the second user and so on.

[0027] In embodiments of the invention in which the authorisation server confirms that at least the amount of money equal to the payment amount is available for transfer from the payment credential of the first user or the second user, it is 7 2017101080 09 Aug 2017 envisaged that the confirmation may involve querying a payment credential registered with the online payment system with which the authorisation server is associated to ensure that at least the amount of money equal to the payment amount is available for transfer from the payment credential of the first user or the second user. In this embodiment of the invention, it is envisaged that, if the authorisation server confirms that at least the amount of money equal to the payment amount is available for transfer from the payment credential of the first user, the authentication server will transfer the payment amount from the payment credential of the first user to the payment credential of the second user (or from the payment credential of the second user to the payment credential of the first user) such that the payment amount is received by the payment credential of the second user (or the first user) on the same day that the payment message is sent.

[0028] Conversely, if the authorisation server fails to confirm that at least the amount of money equal to the payment amount is available for transfer from the payment credential of the first user or the second user (or confirms that an amount of money equal to the payment amount is not available for transfer) the authorisation server will preferably decline to authorise the transfer of the payment amount.

[0029] Alternatively, the authorisation server may send a charge request against the payment credential to a payment network. It is envisaged that, in this embodiment of the invention, the payment network may be associated with an entity other than the entity with which the authorisation server is associated. For instance, the payment network may be associated with a financial institution, such as a bank, credit union, credit card provider or the like. In some embodiments of the invention, the payment network may comprise one or more of a payment gateway system, a payment processing system, a card network system and/or an issuing financial institution system. It is envisaged that the issuing financial institution system may either approve or decline the payment transaction depending on a number of factors such as, but not limited to, the user’s credit rating, the funds available or credit limit of the payment credential of the first or second user, the identity of the first and/or second user (for instance, if the payment amount is to be transferred to a suspect or prohibited person or entity, or the payment credential is located in a country with which financial transactions are prohibited by law, and so on. Thus, it is envisaged that the authorisation of the transfer of the payment amount from the payment 8 2017101080 09 Aug 2017 credential of the first user to the payment credential of the second user (or vice versa) may be dependent on the acceptance of the payment transaction by the payment network. Preferably, in situations in which the payment network declines the payment transaction, the authorisation server will decline to authorise the transfer of the payment amount.

[0030] In another embodiment, the authorisation request may only be sent to the authorisation server following the execution or approval of the payment message by the blockchain, and, more specifically, by the one or more nodes associated with the blockchain. In this embodiment, it is envisaged that the payment message (including the authorisation request) may be sent from the first electronic device directly to the second electronic device (and one or more nodes) using the blockchain. Upon execution or approval of the payment message, one or more nodes associated with the blockchain may send the authorisation request to the authorisation server, or may otherwise notify the authorisation server of the authorisation request. In this embodiment of the invention, upon receipt of the authorisation request, the authorisation server may contact a payment network (such as a payment network associated with a financial institution, such as a bank, credit union, credit card provider, electronic payment system (such as an EFTPOS system or the like) and so on) to authorise the transfer of the payment amount from the payment credential of the first user to the payment credential of the second user (or vice versa).

[0031] Alternatively, the authorisation request may be sent to the authorisation server from one or nodes associated with the blockchain upon receipt of the payment message from the first user by the one or more nodes. In this embodiment, the authorisation server may send a charge request against the payment credential of the first user or the second user to a payment network. It is envisaged that, in this embodiment of the invention, the payment network may be associated with an entity other than the entity with which the authorisation server is associated. For instance, the payment network may be associated with a financial institution, such as a bank, credit union, credit card provider, and electronic payment system (such as an EFTPOS system or the like) and so on. In some embodiments of the invention, the payment network may comprise one or more of a payment gateway system, a payment processing system, a card network system and/or an issuing financial institution system. It is envisaged that the issuing financial institution system may 9 2017101080 09 Aug 2017 either approve or decline the payment transaction depending on a number of factors such as, but not limited to, the user’s credit rating, the funds available or credit limit of the payment credential of the user, the identity of the user (for instance, if the payment amount is to be transferred to a suspect or prohibited person or entity, or the payment credential of the second user is located in a country with which financial transactions are prohibited by law, and so on. Thus, it is envisaged that the authorisation of the transfer of the payment amount from the payment credential of the first user to the payment credential of the second user (or vice versa) may be dependent on the acceptance of the payment transaction by the payment network. Preferably, in situations in which the payment network declines the payment transaction, the authorisation server will decline to authorise the transfer of the payment amount.

[0032] It is envisaged that, once the authorisation request is either approved or declined by the payment network, the authorisation server may electronically communicate the approval (or decline) of the authorisation request to the blockchain via one or more nodes. The blockchain then executes the payment message in a manner dependent on whether the authorisation request has been approved or declined. For instance, if the authorisation request has been approved, and the payment message satisfies all of the rules of the blockchain, the payment request will be approved and the payment amount will be transferred from the payment credential of the first user to the payment credential of the second user, or from the payment credential of the second user to the payment credential of the first user.

[0033] In other embodiments of the invention, the authorisation server may authorise or decline the transfer of the payment amount without accessing an external payment network. For instance, the authorisation server may take the necessary action to authorise transfer of the payment amount by interrogating an electronic database associated with the authorisation server. The electronic database may contain, for instance, the details of users (including name, address, payment credentials etc.) registered with the system. Any suitable action may be taken, such as confirming the identity of the first user and/or the second user (so as to minimise the risk of fraudulent transaction), confirming the existence and/or validity of the payment credential of the first user and/or the second user, confirming that at 10 2017101080 09 Aug 2017 least the amount of money equal to the payment amount is available for transfer from the payment credential of the first user or the second user and so on.

[0034] In embodiments of the invention in which the first user requests payment from the second user via the payment message, it is envisaged that the transfer of the payment amount from the payment credential of the second user to the payment credential of the first user may be authorised by the second user prior to the transfer of the payment amount. In this way, the second user may confirm that the request for payment from the first user is legitimate and that the payment amount is correct.

In this embodiment of the invention, it is envisaged that the authorisation request may only be authorised on receipt of the second user’s approval of the transfer of the payment amount. In this way, misdirected, wrongly generated or potentially fraudulent payment messages generated by the first user may be reviewed and approved by the second user prior to the transfer of the payment amount. Preferably, the step of approving the transfer of the payment amount may comprise inputting authentication information into the second electronic device. Any suitable authentication information may be used, such as a code (numerical or alphanumerical code), a password, a biometric reading or the like, or any suitable combination thereof. Alternatively, a prompt may be provided to the second user on the second electronic device, the second user being prompted to either accept or decline the transfer of the payment amount.

[0035] Preferably, if the authorisation request is approved, the authorisation server may electronically communicate the approval of the authorisation request to the one or more nodes associated with the block chain. The authorisation server may also electronically communicate the approval of the authorisation request to a payment processing system (such as an EFTPOS system, credit card provider, financial institution or the like) for transfer of the payment amount. Finally, the authorisation server may electronically communicate the approval of the authorisation request to the electronic device associated with the first user and/or the second user.

[0036] In some embodiments of the invention, it is envisaged that the authorisation server may also send a push-to-debit request to the payment network. In this embodiment, the push-to-debit request may comprise a request to credit the 11 2017101080 09 Aug 2017 payment amount to the payment credential of the first or second user. Preferably, the push-to-debit request may be formatted for same day processing.

[0037] In some embodiments of the invention, a plurality of authorisation servers may be provided. In this way, if a first authorisation server is offline, or experiencing heavy electronic traffic, a second authorisation server may be actuated to authorise transfer of the payment amount.

[0038] It is envisaged that, in some embodiments of the invention, once the transfer of the payment amount has been authorised, the payment amount may be transferred directly from the payment credential of the first user to the payment credential of the second user (or the payment credential of the second user to the payment credential of the first user). Alternatively, the authorisation server may be associated with an intermediate account. In this embodiment of the invention, upon the authorisation the transfer of the payment amount, the authorisation server may authorise the transfer of the payment amount from the payment credential of the first (or second) user to the intermediate account while simultaneously authorising the transfer of the payment amount from the intermediate account to the payment credential of the second (or first) user. In this way, the second user received the payment amount (preferably on the same day that the payment message is sent) regardless of whether any delays are experienced in receiving the payment amount from the payment credential of the first user.

[0039] Preferably, prior to transferring the payment amount from the intermediate account to the relevant payment credential, the authorisation server may confirm that at least an amount equal to the payment amount is available for transfer from the intermediate account. Once the authorisation server confirms that at least an amount equal to the payment amount is available for transfer from the intermediate account, the transfer of the payment amount from the intermediate account to the relevant payment credential may be authorised and actioned. Alternatively, if the authorisation server fails to confirm that at least the amount of money equal to the payment amount is available for transfer from the intermediate account (or confirms that an amount of money equal to the payment amount is not available for transfer) the authorisation server may decline to authorise the transfer of the payment amount, 12 2017101080 09 Aug 2017 or may transfer the payment amount directly from the payment credential of the first user to the payment credential of the second user (or vice versa).

[0040] As described previously, the present invention encompasses a situation in which a payment amount is transferred from a first user to a second user (or vice versa). However, it is envisaged that the payment amount may be transferred from the payment credential of the first user and then divided between the payment credentials of two or more users or recipients. In this embodiment of the invention, the payment amount may be divided evenly between the two or more recipients such that each recipient receives an equal portion of the payment amount, or may be divided unevenly between the two or more recipients such that each recipient receives an unequal portion of the payment amount. It is envisaged that the division of the payment amount between the two or more recipients may be set by the first user in the payment message.

[0041] In another embodiment of the invention, the payment message sent by the first user may include a payment amount to be transferred to the first user from two or more second users. In this embodiment of the invention, the payment amount may be divided evenly between the two or more second users such that each second user pays an equal portion of the payment amount, or may be divided unevenly between the two or more second users such that each second user pays an unequal portion of the payment amount. It is envisaged that the division of the payment amount between the two or more second users may be set by the first user in the payment message.

[0042] As previously stated, in some embodiments of the invention the authorisation server may be associated with an online payment system or a social network. In these embodiments of the invention, it is envisaged that the first user and the second user may be registered members of the online payment system or the social network. Preferably, online payment system or social network may be adapted to allow users to communicate with one another.

[0043] In a specific embodiment of the invention, the online payment system or social network may be adapted to allow the second user to request a payment from the first user. This may occur if, for instance, the first user has agreed to a quote for goods or services provided by the second user (or has provided goods or services to 13 2017101080 09 Aug 2017 the first user for which it requires payment), if the first user owes the second user money, or so on. The request may be in any suitable form, and may be in the form of an electronic message sent and/or received on the electronic devices of the users.

In a preferred embodiment of the invention, the request may be received within the online payment system or social network, although it is envisaged that the request may be received by SMS message, MMS message, email, voice mail, voice recording or the like, or a combination thereof.

[0044] In other embodiments of the invention, the request may be in the form of an invoice received by the first user from the second user. In this embodiment of the invention, the second user may issue the invoice to the first user so that it is received in the online payment system or social network. Alternatively, the request may be in the form of an invoice received by the second user from the first user. In this embodiment of the invention, the first user may issue the invoice to the second user so that it is received in the online payment system or social network.

[0045] In further embodiments of the invention, the payment message may be generated by the first user scanning an electronically readable element associated with a product or a service. The electronically readable element may be of any suitable form, although in a preferred embodiment of the invention, the electronically readable element may include a barcode, and particularly a two dimensional barcode. In some embodiments of the invention, the electronically readable element may be a Quick Response (QR) code. It is envisaged that the scanning of the electronically readable element may be achieved using the first electronic device.

[0046] In some embodiments of the invention, the electronically readable element may be provided on physical media. Preferably, the step of scanning an electronically readable element associated with a product or service using the first electronic device comprises scanning the electronically readable element using a camera of the first electronic device. Preferably, the camera of the first electronic device scans the physical media to locate and scan the electronically readable element.

[0047] In a preferred embodiment of the invention, prior to sending the payment message from the first electronic device, the first user may be required to authorise the sending of the payment message. Preferably, the step of authorising the sending 14 2017101080 09 Aug 2017 of the payment message may comprise inputting authentication information into the first electronic device. Any suitable authentication information may be used, such as a code (numerical or alphanumerical code), a password, a biometric reading or the like, or any suitable combination thereof. Alternatively, a prompt may be provided to the first user on the first electronic device, the first user being prompted to either accept or decline the sending of the payment message.

[0048] In some embodiments of the invention, the second user may, on receipt of the payment message, be required to accept the transfer of the payment amount prior to the payment amount being transferred to the payment credential of the second user. The acceptance of the transfer of the payment amount may comprise inputting authentication information into the second electronic device. Any suitable authentication information may be used, such as a code (numerical or alphanumerical code), a password, a biometric reading or the like, or any suitable combination thereof. Alternatively, a prompt may be provided to the second user on the second electronic device, the second user being prompted to either accept or decline the transfer of the payment amount.

[0049] In embodiments of the invention in which the payment amount is divided between two or more recipients, it is envisaged that the payment credentials of each of the two or more recipients may be confirmed by the authorisation server prior to the transfer of the payment amount. If not all of the payment credentials of the two or more users can be confirmed by the authorisation server, only the portion or portions of the payment amount designated for transfer to the confirmed payment credentials may be transferred. Alternatively, if not all of the payment credentials of the two or more users can be confirmed by the authorisation server, the authorisation server may decline the payment transaction until such time as all of the payment credentials may be confirmed.

[0050] It is envisaged that the first user and/or the second user may cancel the payment transaction. The payment transaction may be cancelled at any time during the payment transaction process. However, it is preferred that the payment transaction may only be cancelled prior to the receipt of the payment amount by the first user or the second user. Alternatively, it may be preferred that the payment transaction may only be cancelled prior to the authorisation of the transfer of the 15 2017101080 09 Aug 2017 payment amount by the authorisation server. The payment transaction may be cancelled if, for instance, a user changes its mind regarding the purchase, or a user cannot provide the goods or services for which the payment amount is intended. In other embodiments, the payment transaction may be cancelled if, for instance, the first user enters an incorrect payment amount for transfer.

[0051] In all embodiments of the invention, it is envisaged that the method for facilitating a payment transaction may be conducted using one or more electronic interfaces displayed on the first electronic device and the second electronic device. Preferably, the one or more electronic interfaces may be associated with the online payment system, the messaging system or the integrated payment and message system.

[0052] It is envisaged that changes to the interface produced and displayed are preferably made and/or a new interface is displayed and produced depending upon the instructions and/or interaction that a user has with the interface, and thereby with the online payment system, the messaging system or the integrated payment and message system.

[0053] In some embodiments of the invention, a user may access the online payment system, the messaging system or the integrated payment and message system through a website. More preferably, the online payment system, the messaging system or the integrated payment and message system may be accessed by a user through an application, such as an application downloaded to a mobile telephone, computing tablet or the like. The application may include one or more application programming interfaces (APIs) that a user may access using the electronic device. It is envisaged that the application may (via the one or more APIs) send notifications or messages to the user. In this way, the authorisation server may effectively communicate with the users through the one or more APIs.

[0054] In another aspect, the invention resides broadly in a system for facilitating a payment transaction, the system comprising: at least one processor, at least one non-transitory computer readable storage medium storing instructions thereon, that, when executed by the at least one processor, cause the system to: authorise an authorisation request associated with a payment message sent from a first electronic device associated with a first user and received, via a blockchain, by a second 16 2017101080 09 Aug 2017 electronic device associated with a second user, wherein authorising the authorisation request comprises authorising transfer of a payment amount from a payment credential of the first user to a payment credential of the second user, or from a payment credential of the second user to a payment credential of the first user.

[0055] Any of the features described herein can be combined in any combination with any one or more of the other features described herein within the scope of the invention.

[0056] The reference to any prior art in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

BRIEF DESCRIPTION OF DRAWINGS

[0057] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed ODescription is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way. The Detailed Description will make reference to a number of drawings as follows: [0058] Figure 1 illustrates an electronic user interface adapted to facilitate a method for facilitating a payment transaction according to an embodiment of the present invention.

[0059] Figures 2 to 5 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention.

[0060] Figures 6 to 9 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention.

[0061] Figures 10 to 13 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention.

[0062] Figures 14 to 16 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention. 17 2017101080 09 Aug 2017 [0063] Figures 17 to 20 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention.

[0064] Figures 21 and 22 illustrate schematic views of a system and method for facilitating a payment transaction according to embodiments of the present invention.

[0065] Figure 23 illustrates a schematic view of a system and method for facilitating a payment transaction according to an embodiment of the present invention.

[0066] Figure 24 illustrates a schematic view of a system and method for facilitating a payment transaction according to an embodiment of the present invention.

DESCRIPTION OF EMBODIMENTS

[0067] In Figure 1 there is shown an electronic user interface 10 adapted to facilitate a method for facilitating a payment transaction according to an embodiment of the present invention. The electronic user interface 10 is displayed on the screen 11 of a mobile telephone 12.

[0068] It is envisaged that the electronic user interface 10 is provided as part of an application (app) that has been downloaded by a user to the mobile telephone 12. In the embodiment of the invention shown in the Figures, the application is a combined payment system and messaging application.

[0069] It is envisaged that the user will have registered to use the application, the registration process including providing at least the details of a payment credential (such as the details of a financial institution account, credit card, debit card etc.) or the user has opened an account associated with the application. Preferably, the user has also provided one or more additional pieces of information during the registration process, the one or more additional pieces of information being selected from the user’s name, address, telephone number, email address, a password, additional payment credential details and the like.

[0070] The user interface 10 of Figure 1 is a summary interface in which a user can view a list of payments that remain outstanding 13, as well as a list of recent 18 2017101080 09 Aug 2017 payments 14 made to other people or entities. A button 15 marked “Pay Now” is provided in the list of outstanding payment 13 that allows a user to be taken to a new interface (not shown in this Figure) where the outstanding payment may be paid using one or more registered payment credentials.

[0071] In the embodiment of the invention shown in Figure 1, a user has registered (or linked accounts) with a number of service providers 16 in order to receive invoices and/or make payments through the application. Similarly, the user has registered (or linked accounts) with a number of individuals 17 to receive and/or make payments through the application.

[0072] The user interface 10 includes a notification alert 18 to indicate to the user that a notification has been received (for instance, a payment must be made or has been received, a new invoice has been received and so on). In some embodiments of the invention, the application may also send a further alert to the user when a notification is received, such as an email, SMS message, push notification or the like, or any suitable combination thereof.

[0073] The user interface 10 shown in Figure 1 also includes a number of buttons that transfer the user to further user interfaces where other actions may be completed. For instance, the user interface includes a pay button 19 that opens a payment interface through which a user may make a payment to another party, a request button 20 that opens a request interface through which a user may request a payment from another party, a bills button 21 that opens a bills interface that allows a user to view a list of paid and/or outstanding invoices or bills, and a scan button 22 that allows a user to use the camera (not shown) associated with the mobile telephone 12 to scan an electronically-readable element (such as a barcode or QR code). It is envisaged that the electronically-readable element will be provided on a bill or invoice that the user wishes to pay.

[0074] Figures 2 to 5 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention. In Figure 2, a user has pressed the pay button (reference number 19 in Figure 1), and been transferred to a payment interface 23 through which a payment may be made to another party.

In this Figure, a user is able to select the recipient 24 of the payment and the payment amount 25. The user may also provide a message 26 to the recipient. The 19 2017101080 09 Aug 2017 user also selects a payment credential 27 registered with the application from which the payment amount will be debited. In the embodiment of the invention shown in Figure 2, the payment credential 27 is a debit card. It is envisaged that, in some embodiments, the user may press screen 11 at the location where the payment credential 27 is identified to display a list (not shown) of all payment credentials registered to the user or to enter a new payment credential.

[0075] Once the recipient 24 and the payment credential 27 have been selected, the payment amount 25 entered and, optionally, a message 26 entered, the user presses a “Pay now” button 28 to send a payment message to an electronic device associated with the recipient 24 using a blockchain (not shown).

[0076] In Figure 3, the payment message 29 is received directly using the blockchain (not shown) by the electronic device (a mobile telephone 12) associated with the recipient. The payment message 29 identifies both the user 30 sending the payment and the payment amount 25. The message 26 written by the user 30 sending the payment is also displayed on the recipient’s screen 11.

[0077] Before the payment amount 25 is transferred from the first user (the payer) to the second user (the recipient), the recipient must accept the transfer of the payment amount 25 by pressing the “Accept” button 31. Optionally, the recipient may send a message 32 back to the payer when accepting the transfer of the payment amount 25.

[0078] When the recipient presses the “Accept” button 31, the server (not shown) reviews an authorisation request (not shown) associated with the payment message 29. The server (not shown) reviews the authorisation request to confirm the validity of the payment credential of the payer, and whether funds at least equal to the payment amount are available for transfer. The server also confirms the validity of the payment credential 34 of the recipient (in this case a bank account), which is then displayed on a confirmation interface 33 shown in Figure 4. If the recipient is happy to receive the payment amount 25 to the payment credential 34, the user presses a “Confirm” button 35 to confirm transfer of the payment amount 25 to the payment credential 34. It is envisaged that, in some embodiments, the recipient may press the screen 11 at the location where the payment credential 34 is identified to display 20 2017101080 09 Aug 2017 a list (not shown) of all payment credentials registered to the recipient or to enter a new payment credential.

[0079] Once the “Confirm” button 35 is pressed, a completion interface 36 as shown in Figure 5 is displayed. The completion interface 36 includes a message 37 confirming that the transfer of the payment amount 25 has been accepted by the recipient. The payment amount 25 may be transferred from the payment credential (not shown in this Figure) of the payer to the payment credential (not shown in this Figure) of the recipient. Alternatively, to ensure same day receipt of the payment amount 25 by the recipient, the payment amount 25 may be transferred from an intermediate account (not shown) associated with the server (not shown) to the payment credential (not shown in this Figure) of the recipient. Similarly, the payment amount 25 may be transferred from the payment credential (not shown in this Figure) of the payer to the intermediate account (not shown). In this way, delays in the receipt of the payment amount 25 by the recipient may be minimised or eliminated.

[0080] Figures 6 to 9 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention. In Figure 6, a user has pressed the request button (reference number 20 in Figure 1), and been transferred to a request interface 38 through which a payment may be requested from another party.

[0081] In Figure 6, the user selects the person 39 from whom the payment is being requested and the payment amount 25. The user may also provide a message 40 to the person 39 explaining what the requested payment amount 25 is for. The user also selects a payment credential 41 registered with the application into which the payment amount 25 will be received. In the embodiment of the invention shown in Figure 6, the payment credential 41 is a bank account. It is envisaged that, in some embodiments, the user may press screen 11 at the location where the payment credential 41 is identified to display a list (not shown) of all payment credentials registered to the user or to enter a new payment credential.

[0082] Once the person 39 and the payment credential 41 have been selected, the payment amount 25 entered and, optionally, a message 40 entered, the user presses a “Request” button 42 to send a payment message to an electronic device associated with the person 39 using a blockchain (not shown). 21 2017101080 09 Aug 2017 [0083] In Figure 7, the payment message 43 is received directly using the blockchain (not shown) by the electronic device (a mobile telephone 12) associated with the person. The payment message 43 identifies both the user 44 sending the request and the payment amount 25. The message 40 written by the user 44 requesting the payment is also displayed on the person’s screen 11.

[0084] Before the payment amount 25 is transferred from the person to the user 44, the person must confirm the transfer of the payment amount 25 by pressing the “Pay now” button 45. Optionally, the person may send a message back to the user 44 using message field 46 when confirming the transfer of the payment amount 25.

[0085] When the person presses the “Pay now” button 45, the server (not shown) reviews an authorisation request (not shown) associated with the payment message 43. The server (not shown) reviews the authorisation request to confirm the validity of the payment credential of the person, and whether funds at least equal to the payment amount 25 are available for transfer. The server also confirms the validity of the payment credential 48 (in this case a debit card) of the user 44, which is then displayed on a confirmation interface 47 shown in Figure 8. If the recipient is happy to send the payment amount 25 from the payment credential 47, the user presses a “Confirm” button 49 to confirm transfer of the payment amount 25 from the payment credential 48. It is envisaged that, in some embodiments, the recipient may press the screen 11 at the location where the payment credential 48 is identified to display a list (not shown) of all payment credentials registered to the recipient or to enter a new payment credential.

[0086] Once the “Confirm” button 49 is pressed, a completion interface 50 as shown in Figure 9 is displayed. The completion interface 50 includes a message 51 confirming that the transfer of the payment amount 25 has been sent to the user.

The payment amount 25 may be transferred from the payment credential (not shown in this Figure) of the person to the payment credential (not shown in this Figure) of the user. Alternatively, to ensure same day receipt of the payment amount 25 by the user, the payment amount 25 may be transferred from an intermediate account (not shown) associated with the server (not shown) to the payment credential (not shown in this Figure) of the user. Similarly, the payment amount 25 may be transferred from the payment credential (not shown in this Figure) of the person to the intermediate 22 2017101080 09 Aug 2017 account (not shown). In this way, delays in the receipt of the payment amount 25 by the user may be minimised or eliminated.

[0087] Figures 10 to 13 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention. The method illustrated in Figures 10 to 13 is a variation on that shown in Figures 6 to 9, and differs in that a request for payment is made to multiple parties. In Figure 10, a user has pressed the request button (reference number 20 in Figure 1), and been transferred to a request interface 38 through which a payment may be requested from two or more parties.

[0088] In Figure 10, the user selects the two or more people 39a, 39b from whom the payment is being requested, and the payment amount 25. The user may also provide a message 40 to the people 39a, 39b explaining what the requested payment amount 25 is for. When a payment is requested from two or more people 39a, 39b, the user may select whether the payment amount 25 is to be split evenly between the people 39a, 39b by selecting an “even split” option 52. Alternatively, where one of the people 39a, 39b is to pay more than the other, the user may select the “uneven split” option 53. In the embodiment of the invention shown in Figure 10, the “even split” option 52 has been selected.

[0089] In addition, the user selects a payment credential 41 registered with the application into which the payment amount 25 will be received. In the embodiment of the invention shown in Figure 10, the payment credential 41 is a bank account. It is envisaged that, in some embodiments, the user may press the screen 11 at the location where the payment credential 41 is identified to display a list (not shown) of all payment credentials registered to the user or to enter a new payment credential.

[0090] Once the people 39a, 39b and the payment credential 41 have been selected, the payment amount 25 entered and, optionally, a message 40 entered, the user presses a “Request” button 42 to send a payment message to electronic devices associated with the people 39a, 39b using a blockchain (not shown).

[0091] In Figure 11, the payment message 43 is received directly using the blockchain (not shown) by the electronic device (a mobile telephone 12) associated with one of the people from whom payment is requested. The payment message 43 23 2017101080 09 Aug 2017 identifies both the user 44 sending the request and the portion of the payment amount 55 that the person receiving the payment message 43 owes. The message 40 written by the user 44 requesting the payment is also displayed on the person’s screen 11.

[0092] Before the portion of the payment amount 55 is transferred from the person to the user 44, the person must confirm the transfer of the portion of the payment amount 55 by pressing the “Pay now” button 45. Optionally, the person may send a message back to the user 44 using message field 46 when confirming the transfer of the portion of the payment amount 55.

[0093] A status bar 54 displays the status of the payment between each person 39a, 39b and the user 44. The status of the payment in the status bar 54 will change when the payment of the portion of the payment amount 55 is made and/or completed.

[0094] When the person presses the “Pay now” button 45, the server (not shown) reviews an authorisation request (not shown) associated with the payment message 43. The server (not shown) reviews the authorisation request to confirm the validity of the payment credential of the person, and whether funds at least equal to the portion of the payment amount 55 are available for transfer. The server also confirms the validity of the payment credential (not shown) of the user 44, which is then displayed on a confirmation interface similar to the one shown in Figure 8.

[0095] Once the transfer of the payment is completed, a completion interface 50 as shown in Figure 12 is displayed. The completion interface 50 includes messages 51 confirming that the transfer of the payment amount has been sent to the user, and the status bar 54 is updated to reflect the completion of the transfer of the payment amount from each person 39a, 39b. The payment amount 25 may be transferred from the payment credential (not shown in this Figure) of each person 39a, 39b to the payment credential (not shown in this Figure) of the user. Alternatively, to ensure same day receipt of the payment amount 25 by the user, the payment amount 25 may be transferred from an intermediate account (not shown) associated with the server (not shown) to the payment credential (not shown in this Figure) of the user. Similarly, the portion of the payment amount 55 may be transferred from the payment credential (not shown in this Figure) of each person 39a, 39b to the intermediate 2017101080 09 Aug 2017 24 account (not shown). In this way, delays in the receipt of the payment amount 25 by the user may be minimised or eliminated.

[0096] Each person involved in the payment transaction may also communicate with one another via messages displayed on the confirmation interface 50.

[0097] In Figure 13, an uneven split interface 57 is illustrated. The uneven split interface 57 is displayed when a user selects the uneven split option (reference numeral 53 in Figure 10).

[0098] In the uneven split interface 57, the user may enter the portions of the payment amount 55 that each person 39a, 39b owes prior to sending the payment message to the people 39a, 39b.

[0099] Figures 14 to 16 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention. The method shown in Figures 14 to 16 is a variation on that shown in Figures 6 to 9 and also Figures 10 to 13.

[0100] In Figure 14, the request interface 38 is shown, and a user selects a person 39 and a payment amount 25 for payment by the person 39. The user may also provide a message 40 to the person 39 explaining what the requested payment amount 25 is for. The user also selects a payment credential 41 registered with the application into which the payment amount 25 will be received. In the embodiment of the invention shown in Figure 6, the payment credential 41 is a bank account. It is envisaged that, in some embodiments, the user may press screen 11 at the location where the payment credential 41 is identified to display a list (not shown) of all payment credentials registered to the user or to enter a new payment credential. The difference between the embodiment shown in Figure 14 and other embodiments is that the user may add an invoice 58 to the payment message.

[0101] Once the person 39 and the payment credential 41 have been selected, the payment amount 25 entered and, optionally, a message 40 entered, the user presses a “Request” button 42 to send a payment message to an electronic device associated with the person 39 using a blockchain (not shown). 25 2017101080 09 Aug 2017 [0102] In Figure 15, the payment message 43 is received directly using the blockchain (not shown) by the electronic device (a mobile telephone 12) associated with the person. The payment message 43 identifies both the user 44 sending the request and the payment amount 25. The message 40 written by the user 44 requesting the payment is also displayed on the person’s screen 11.

[0103] Before the payment amount 25 is transferred from the person to the user 44, the person must confirm the transfer of the payment amount 25 by pressing the “Pay now” button 45. Optionally, the person may send a message back to the user 44 using message field 46 when confirming the transfer of the payment amount 25.

[0104] When the person presses the “Pay now” button 45, the server (not shown) reviews an authorisation request (not shown) associated with the payment message 43. The server (not shown) reviews the authorisation request to confirm the validity of the payment credential of the person, and whether funds at least equal to the payment amount 25 are available for transfer. The server also confirms the validity of the payment credential of the user 44, which is then displayed on a confirmation interface similar to that illustrated in Figure 8.

[0105] Once the transfer of the payment amount 25 is completed, a completion interface 50 as shown in Figure 16 is displayed. The completion interface 50 includes a message 51 confirming that the transfer of the payment amount 25 has been sent to the user. The payment amount 25 may be transferred from the payment credential (not shown in this Figure) of the person to the payment credential (not shown in this Figure) of the user. Alternatively, to ensure same day receipt of the payment amount 25 by the user, the payment amount 25 may be transferred from an intermediate account (not shown) associated with the server (not shown) to the payment credential (not shown in this Figure) of the user. Similarly, the payment amount 25 may be transferred from the payment credential (not shown in this Figure) of the person to the intermediate account (not shown). In this way, delays in the receipt of the payment amount 25 by the user may be minimised or eliminated.

[0106] Figures 17 to 20 illustrate steps in a method for facilitating a payment transaction according to an embodiment of the present invention. In Figure 17, a user has pressed the scan button (reference numeral 22 in Figure 1) to open a scan interface 59. The scan interface uses a camera associated with the mobile 26 2017101080 09 Aug 2017 telephone 12 to allow a user to scan an electronically-readable element (in this case a QR code 60). It is envisaged that the QR code may be provided on an invoice, and that the invoice may be provided in paper or electronic form.

[0107] When the QR code 60 is lined up in the scan field on the scan interface 59, the QR code will be scanned, and details of the invoice associated with the QR code (and/or the invoice itself) will be displayed, as illustrated in Figure 18. In this Figure, the details of the invoice (including the name of the issuer 62 of the invoice, an identification 63 of the charges contained in the invoice and the payment amount 25) are displayed.

[0108] In the embodiment of the invention illustrated in Figure 18, the user has the choice of paying the invoice immediately by pressing the “Pay now” button 64 or deferring payment of the invoice by pressing the “Pay later” button 65.

[0109] If the user presses the “Pay now” button 64, a payment interface 66 as illustrated in Figure 19 will be displayed. In the payment interface, the invoice details 67 are displayed, along with the payment credential 41 (in this case a credit card) with which the invoice will be paid. It is envisaged that, in some embodiments, the user may press screen 11 at the location where the payment credential 41 is identified to display a list (not shown) of all payment credentials registered to the user or to enter a new payment credential.

[0110] If satisfied with the selection of the payment credential 41, the user will press the “Pay” button 68 to transfer the payment amount from the payment credential 41 to a payment credential of the issuer 62 of the invoice.

[0111] In an alternative embodiment of the invention, if the user selects the “Pay later” button (reference numeral 65 in Figure 18), the invoice will be added to an invoice list and displayed in an invoice list interface 69 illustrated in Figure 20. In this Figure it may be seen that a list of upcoming bills 70 is provided, along with the due date 71 for their payment. In addition, a list of past bills 72 is provided along with the date of payment 73 of each. In this way, a user may keep track of both bills that are due for payment and bills that have already been paid.

[0112] Figure 21 illustrates a schematic view of a system and method for facilitating a payment transaction according to an embodiment of the present 27 2017101080 09 Aug 2017 invention. In this Figure, a first user 100 wishes to send a monetary payment to a second user 101. To do so, the first user sends a payment message 102 from a first electronic device 103 associated with the first user 100 (in this case a mobile telephone using an application for a combined payment and messaging system) directly to a second electronic device 104 associated with the second user 101 (in this case a mobile telephone using an application for a combined payment and messaging system). The payment message 102 is sent as a blockchain, or portion of a blockchain.

[0113] The payment message 102 includes an authorisation request 105 that actuates a server 106 to authorise the transfer of a payment amount 107 from a payment credential of the first user 100 (in this case a bank account 108) to a payment credential of the second user 101 (in this case a bank account 109). In this embodiment of the invention, the server 106 is associated with the combined payment and messaging system, and the bank accounts 108, 109 are registered with the combined payment and messaging system by the first user 100 and the second user 101, respectively.

[0114] Once actuated by the authorisation request 105, the server 106 performs a check 110 against bank account 108 to ensure that bank account 108 has funds available for transfer that are at least equal to the payment amount 107. If the server 106 confirms that these funds are available in bank account 108, the server 106 will authorise transfer of the payment amount 107 from bank account 108 to bank account 109.

[0115] Figure 22 illustrates a schematic view of a method for facilitating a payment transaction according to an embodiment of the present invention. This Figure shows a method very similar to that shown in Figure 21 with the exception that the method is adapted for same day receipt of the payment amount 107 by the second user 101.

[0116] As with Figure 21, in Figure 22 a first user 100 wishes to send a monetary payment to a second user 101. To do so, the first user sends a payment message 102 from a first electronic device 103 associated with the first user 100 (in this case a mobile telephone using an application for a combined payment and messaging system) directly to a second electronic device 104 associated with the second user 28 2017101080 09 Aug 2017 101 (in this case a mobile telephone using an application for a combined payment and messaging system). The payment message 102 is sent as a blockchain, or portion of a blockchain.

[0117] The payment message 102 includes an authorisation request 105 that actuates a server 106 to authorise the transfer of a payment amount 107 from a payment credential of the first user 100 (in this case a bank account 108) to a payment credential of the second user 101 (in this case a bank account 109). In this embodiment of the invention, the server 106 is associated with the combined payment and messaging system, and the bank accounts 108, 109 are registered with the combined payment and messaging system by the first user 100 and the second user 101, respectively.

[0118] Once actuated by the authorisation request 105, the server 106 performs a check 110 against bank account 108 to ensure that bank account 108 has funds available for transfer that are at least equal to the payment amount 107. If the server 106 confirms that these funds are available in bank account 108, the server 106 will authorise transfer of the payment amount 107 from bank account 108 to an intermediate account 111 associated with the server 106. The server 106 will also simultaneously authorise 112 the transfer of the payment amount from the intermediate account 111 to bank account 109. In this way, the payment amount 107 received from the bank account 108 of the first user 100 will be received by and retained in the intermediate account 111 while an equivalent amount will be transferred from the intermediate account 111 to the bank account 109 of the second user 101.

[0119] By simultaneously authorising the transfer of the payment amount 107 from the intermediate account 111 to the bank account 109 of the second user 101, any delays in the receipt of the payment amount 107 by the second user 101 can be reduced or eliminated. Ideally, this ensures same day receipt of the payment amount 107 by the second user 101, even if there is a delay in the payment amount being received by the intermediate account 111 from the bank account 108 of the first user 100.

[0120] Figure 23 illustrates a method and system for facilitating a payment transaction according to an alternative embodiment of the present invention. In this 29 2017101080 09 Aug 2017

Figure, user devices 120 such as mobile telephones, computer tablets and computers, are in electronic communication with a blockchain 121 such that payment messages 122 can be electronically sent from a user device 120 to the blockchain 121. The blockchain 121, and therefore the payment messages 122, maybe accessed by any user device 120 in electronic communication with the blockchain 121, as well as by any node 123 (i.e. one or more computers, servers or the like) associated with the blockchain 121.

[0121] Upon receipt of a payment message 122, a node 123 sends an authorisation request 124 to an authorisation server 125. The authorisation server 125 is in electronic communication with an electronic database 126 that contains details relating to the users, including details of a payment credential of both the user sending the payment and the user to receive the payment. In the embodiment of the invention illustrated in Figure 23, the electronic database 126 is maintained by the same entity as the entity that operates the authorisation server 125, although in other embodiments of the invention, the electronic database may be maintained by a different entity, such as a financial institution, credit card provider, electronic payment platform or the like.

[0122] The authorisation server 125 communicates with the electronic database 126 to confirm that (at least) there are funds at least equal to the payment amount (i.e. the amount to be transferred to the user receiving the payment plus any applicable administrative charges, shipping and handling costs etc.) available in connection with the payment credential of the user sending the payment. If there are sufficient funds available, the authorisation server authorises the payment message 122 and electronically communicates the authorisation to the node 123. The nodes 123 then execute the payment message 122 within the blockchain 121.

[0123] Simultaneously to the authorisation of the authorisation request 124, the authorisation server 125 communicates electronically with an external payment system 127 (such as an EFTPOS system) to process the transfer of the payment amount from the payment credential of the first user to the payment credential of the second user.

[0124] Upon authorisation of the authorisation request 124 (or, alternatively, the transfer of the payment amount) the authorisation server 125 sends an electronic 30 2017101080 09 Aug 2017 confirmation 128 to the devices 120 of the user receiving the payment and/or the user sending the payment confirming authorisation of the payment message 122 (or transfer of the payment amount). In the embodiment of the invention shown in Figure 23, the electronic confirmation 128 is sent from the authorisation server 125 to the user devices 120 via an application 129 downloaded to the user devices 120. More specifically, the electronic confirmation 128 may be sent from one or more interfaces associated with the application 129 downloaded to the user devices 120.

[0125] Figure 24 illustrates a method and system for facilitating a payment transaction according to an alternative embodiment of the present invention. This Figure is very similar to the method and system shown in Figure 23, with the exception that the payment message 122 is generated by a first electronic device 130 associated a first user who is, in this instance, a vendor. The first user may be a vendor of goods and/or services which the second user 131 has purchased or desires to purchase. Thus, in this embodiment of the invention, the payment message 122 is in the form of an invoice sent by the first user to the second user 131 for payment. In this Figure, user devices 120 such as mobile telephones, computer tablets and computers, are in electronic communication with a blockchain 121 such that payment message 122 can be electronically sent from a user device 130 to the blockchain 121 either directly or via a node 123 associated with the blockchain 121. The blockchain 121, and therefore the payment message 122, may be accessed by any user device 120 in electronic communication with the blockchain 121, as well as by any node 123 (i.e. one or more computers, servers or the like) associated with the blockchain 121.

[0126] Upon receipt of a payment message 122, a node 123 sends an authorisation request 124 to an authorisation server 125. The authorisation server 125 is in electronic communication with an electronic database 126 that contains details relating to the users, including details of a payment credential of both the user sending the payment and the user to receive the payment (in this instance, the user requesting the payment). In the embodiment of the invention illustrated in Figure 24, the electronic database 126 is maintained by the same entity as the entity that operates the authorisation server 125, although in other embodiments of the invention, the electronic database may be maintained by a different entity, such as a financial institution, credit card provider, electronic payment platform or the like. 31 2017101080 09 Aug 2017 [0127] The authorisation server 125 communicates with the electronic database 126 to confirm that (at least) there are funds at least equal to the payment amount (i.e. the amount to be transferred to the user receiving the payment plus any applicable administrative charges, shipping and handling costs etc.) available in connection with the payment credential of the user sending the payment. If there are sufficient funds available, the authorisation server 125 authorises the payment message 122 and electronically communicates the authorisation to the node 123.

The nodes 123 then execute the payment message 122 within the blockchain 121. Alternatively, but preferably, the authorisation server 125 issues an authorisation notice to the device 120 of the second user 131 prior to authorising transfer of the payment amount. In this way, the second user 131 has an opportunity to reject the transfer of the payment amount, for instance if the payment message 122 is misdirected, incorrect or fraudulent.

[0128] Simultaneously to the authorisation of the authorisation request 124, the authorisation server 125 communicates electronically with an external payment system 127 (such as an EFTPOS system) to process the transfer of the payment amount from the payment credential of the second user 131 to the payment credential of the first user.

[0129] Upon authorisation of the authorisation request 124 (or, alternatively, the transfer of the payment amount) the authorisation server 125 sends an electronic confirmation 128 to the devices 120, 130 of the user receiving the payment and/or the user sending the payment confirming authorisation of the payment message 122 (or transfer of the payment amount). In the embodiment of the invention shown in Figure 24, the electronic confirmation 128 is sent from the authorisation server 125 to the user devices 120, 130 via an application 129 downloaded to the user devices 120, 130. More specifically, the electronic confirmation 128 may be sent from one or more interfaces associated with the application 129 downloaded to the user devices 120, 130.

[0130] The present invention provides numerous advantages over the prior art.

As previously mentioned, the use of a blockchain renders any personal information contained in the payment message (such as names, addresses, financial information, bank or credit/debit card numbers, telephone numbers, passwords etc.) secure and 2017101080 09 Aug 2017 32 difficult, if not impossible, for unauthorised users to access and steal. In addition, the use of a blockchain results in rapid, if not instantaneous, execution of a payment message, resulting in the second user receiving the payment amount faster than in prior art systems.

[0131] In the present specification and claims (if any), the word ‘comprising’ and its derivatives including ‘comprises’ and ‘comprise’ include each of the stated integers but does not exclude the inclusion of one or more further integers.

[0132] Reference throughout this specification to ‘one embodiment’ or ‘an embodiment’ means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases ‘in one embodiment’ or ‘in an embodiment’ in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[0133] In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect. The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims (if any) appropriately interpreted by those skilled in the art.

Claims

1. A method for facilitating a payment transaction, the method comprising the steps of: sending, from a first electronic device associated with a first user, a payment message including a payment amount; receiving, with a second electronic device associated with a second user, the payment message, the payment message being received by the second electronic device via a blockchain from the first electronic device; and wherein the payment message includes an authorisation request adapted to actuate one or more authorisation servers to authorise transfer of the payment amount from a payment credential of the first user to a payment credential of the second user, or from a payment credential of the second user to a payment credential of the first user.

2. A method according to claim 1 wherein the payment message is sent from the first electronic device to the blockchain, such that the payment message forms a portion of a blockchain.

3. A method according to claim 1 or claim 2 wherein an amount equal to the payment amount is transferred to the payment credential of the second user from an intermediate account associated with the authorisation server, and the payment amount is transferred from the payment credential of the first user to the intermediate account.

4. A system for facilitating a payment transaction, the system comprising: at least one processor, at least one non-transitory computer readable storage medium storing instructions thereon, that, when executed by the at least one processor, cause the system to: authorise an authorisation request associated with a payment message sent from a first electronic device associated with a first user and received, via a blockchain, by a second electronic device associated with a second user, wherein authorising the authorisation request comprises authorising transfer of a payment amount from a payment credential of the first user to a payment credential of the second user, or from a payment credential of the second user to a payment credential of the first user.

5. A system according to claim 4 wherein the payment message is sent from the first electronic device to the blockchain, such that the payment message forms a portion of a blockchain.