AU2018220069A1

AU2018220069A1 - Systems and methods for enabling group payment transactions

Info

Publication number: AU2018220069A1
Application number: AU2018220069A
Authority: AU
Inventors: Milan BUTINA; Milica BUTINA
Original assignee: Individual
Current assignee: Individual
Priority date: 2017-08-24
Filing date: 2018-08-22
Publication date: 2019-03-14

Abstract

(Figure 1) The present invention concerns systems and methods for enabling group payment transactions to be processed in a communication session between a merchant and a primary payer. In a method, a remotely accessible server establishes the communication session between the primary payer and the merchant in response to the primary payer electing to group pay a transaction. The server receives a request originating from the primary payer to process a group payment transaction. The request includes a division, determined by the primary payer, of the transaction value to be paid into a first amount owed by the primary payer and at least a second amount owed by the at least one further payer. With the request, the remotely accessible server receives a transaction completion time, which is set by the merchant. Upon receiving the request, the remotely accessible server looks up an account associated with the primary payer for available payment options for display at a computing device of the primary payer. The server further receives a selected payment option from the primary payer and, responsive to the transaction value being secured within the transaction completion time, processes the group payment transaction. -------------------------------------------- ----------- 150b 150a Figure 1

Description

SYSTEMS AND METHODS FOR ENABLING GROUP PAYMENT TRANSACTIONS

TECHNICAL FIELD [0001] The present invention generally relates to payment processing and more particularly to systems and methods for enabling the processing of group payment transactions.

BACKGROUND [0002] It is not an uncommon scenario for two or more people to split a bill, an expense or other amount that is owed. For example, such a group payment scenario may arise in the context of rent, a utility or other home services bills (e.g., internet, telephone, etc.), social event bills (e.g., travel, restaurant, bar, accommodation, etc.) and retail purchases of goods and services (e.g., a pair of shoes shared by sisters or a mother and daughter).

[0003] However, generally such group payment transactions do not extend to online purchases as most online merchants only permit a single transaction. For example, it would be advantageous for two or more people to be able to group pay online tickets to an event, when booking flights or accommodation online or when purchasing an online gift (e.g., a group gift).

SUMMARY OF INVENTION [0004] Embodiments of the present invention provide systems and methods of enabling a group payment transaction, which may at least partially overcome the abovementioned problem or provide a consumer with a useful or commercial choice.

[0005] According to a first aspect of the present invention, there is provided a system for enabling a group payment transaction, said system including:

at least one remotely accessible server; and a payer account database in communication with the at least one remotely accessible server, wherein the at least one remotely accessible server includes at least one processor and a memory and is programmed to:

establish a communication session between a merchant computing system and a computing device of a primary payer in response to the primary payer electing to group pay a transaction;

receive a request from the primary payer to process a group payment transaction, wherein the request includes a division of a transaction value to be group paid into a first amount owed by the primary payer and at least a second amount owed by at least one further payer;

2018220069 22 Aug 2018 receive from the merchant computing system a transaction completion time; look-up in an account of the primary payer in the account database, one or more payment options for at least the second amount owed by the at least one further payer, said one or more payment options selected from:

applying one or more pre-authorised funds made available from the at least one further payer to the primary payer; and transmitting at least one payment request to the at least one further payer requesting funds;

receive from the primary payer a selected said one or more payment options and actioning said one or more payment options selected; and responsive to the transaction value being secured within the transaction completion time, processing the group payment transaction and transferring funds corresponding to the transaction value to the merchant computing system.

[0006] According to a second aspect of the present invention, there is provided a system for enabling a group payment transaction, said system including at least one remotely accessible server having a processor to control execution of instructions from a memory unit and including:

a communication session component for, in response to a primary payer electing to group pay a transaction, establishing a communication session between a computing device of the primary payer and a merchant computing system of a merchant;

a processing request component for receiving a request from the primary payer to process a group payment transaction, wherein the request includes a division of a transaction value to be group paid into a first amount owed by the primary payer and at least a second amount owed by at least one further payer;

a merchant receiving component for receiving, from the merchant computing system, a transaction completion time set by the merchant;

a look-up component for, in response to receiving the request from the primary payer, looking up in an account of the primary payer in an account database in communication with the at least one remotely accessible server one or more payment options for at least the second amount owed by the at least one further payer, said one or more payment options selected from:

an action component for receiving a selected said one or more payment options

2018220069 22 Aug 2018 from the primary payer and actioning said one or more payment options selected; and an authorization component for authorizing the group payment transaction to proceed, responsive to the to the transaction value being secured within the transaction completion time and transferring funds corresponding to the transaction value to the merchant computing system.

[0007] Advantageously, the present invention provides systems and methods of enabling a group payment transaction to be processed in a single transaction with an online merchant.

[0008] From a consumer perspective, the present invention enables a group of people to purchase flights, accommodation, gifts or pay a shared bill, for example, in a single transaction with each group members contributing to the transaction before it is processed. As such, the present invention eliminates the uncomfortable scenario in which a group member may pay an entire group purchase and then have to follow-up with each other group member to be reimbursed for that group member’s share of the purchase.

[0009] From a merchant’s perspective, the present invention is also appealing as it allows an online merchant to compete with brick and mortar merchants where split payments are a simple and common practice. Also, by enabling the group payment to be processed as a single transaction, the merchant is not left with the cost and complexity of processing multiple credit card payment and, in some scenarios, absorbing the transaction costs of processing those multiple credit card payments.

[0010] Preferably, said division is determined by the primary payer. The payment options may be for display at the computing device of the primary payer.

[0011] The term “payment transaction” may refer to an exchange of money or some other financial asset in exchange for something else of value, such as, information, goods, services or money.

[0012] Generally, a payment transaction involves at least two parties, namely: a payer, who gives up the money or other financial asset; and a payee, who receives the money or other financial asset. The parts of the payment transaction need not occur simultaneously. For example, money or the other financial asset may be given at onetime and the information, goods and/or services may be given at another time.

[0013] The total amount of money or other financial asset required to be exchanged as part of the payment transaction may be referred to as the “transaction value”.

[0014] A “group payment transaction” may refer to a payment transaction involving at least

2018220069 22 Aug 2018 two payers and a payee being a merchant. The at least two payers may include a “primary payer”, who initiates the group payment transaction, and “at least one further payer”, who contributes money or some other financial asset towards the group payment transaction. As used herein, “group payment transaction” may refer to an online payment transaction between the primary payer on behalf of the at least two payers and the merchant.

[0015] The term “merchant” may refer to any party or entity acting as the payee in a group payment transaction. The merchant is preferably an online merchant. Typically, the merchant may have a merchant computing system or use a third party computing system for receiving and processing payments (hereafter referred to as “merchant computing system”).

[0016] The term “communication session” may refer to a semi-permanent interactive information interchange between two or more communication devices, typically computing devices.

[0017] In some embodiments of the present invention, a communication session may be established between a merchant computing system, a computing device of a primary payer and the at least one remotely accessible server. In other embodiments, a communication session may be established between a computing device of at least one further payer and the at least one remotely accessible server. Generally, an established communication session may be torn down when a group payment transaction or action associated with a group payment transaction has been completed.

[0018] The at least one remotely accessible server may be any appropriate server computer, distributed server computer, cloud-based server computer, sever computer cluster or the like. The server may typically include one or more processors and one or more memory units containing executable instructions/software to be executed by the one or more processors. Generally, the server may be in communication with at least one database.

[0019] For example, in some embodiments, the server may be in communication with a payer account database containing a plurality of payer records. Preferably, the server may be linked to or may maintain a payer account database containing a plurality of payer records. Each payer record may include an account identifier, such as, e.g., an account number or user name. Each payer record may further include additional payer information, such as, e.g., personal information of the payer, funds available including any pre-authorised funds made available from at least one further payer, details of payment instruments, and/or the like.

[0020] In some embodiments, the server may be in communication with a further database, such as, e.g., a merchant database containing a plurality of merchant records who allow group

2018220069 22 Aug 2018 payment transactions. Again, preferably, the server may be linked to or may maintain the merchant database. Each merchant record may include a merchant identifier, such as, e.g., an account number or merchant number. Each merchant record may or may not further include additional information particular to the merchant, such as, e.g., a pre-set transaction completion time, communication details for communicating with the merchant computer system, etc.

[0021] The remotely accessible server is configured to transmit communications to and receive communications from a computing device of the primary payer and the merchant computing system of the merchant over any suitable communications network or networks and using any suitable communication protocol or interface (e.g., an application programming interface (API)). In some embodiments, the remotely accessible server is further configured to transmit communications to and receive communications from an electronic device associated with at least one further payer.

[0022] The communications may be received and transmitted over a communications network, which may include, among others, the Internet, LANs, WANs, GPRS network, a mobile communications network, etc., and may include wired and/or wireless communication links.

[0023] The communications may preferably be received and transmitted via a communication session established between the computing device of the primary payer, the merchant computing system, the remotely accessible server and/or, in some embodiments, the electronic device of the at least one further payer.

[0024] In preferred embodiments, the communication session established may be a secure communication session across an encrypted communication channel such as Hypertext Transfer Protocol Secure (HTTPS), Transport Layer Security / Secure Sockets Layer (TLS/SSL) or other secure channel.

[0025] The computing device of the primary payer may be any suitable external processing device capable of communication with the remotely accessible server and the merchant computing system. The computing device may include at least one processor, at least one memory unit and at least one display. The computing device may be in the form of a desktop computer, a laptop computer, a tablet device, a smart phone, a smart watch or a PDA, for example.

[0026] The merchant computing system may include any suitable processor-based device or system, such as a computer, a laptop, a server, a mainframe or a collection of multiple computers, for example. As with the computing device of the primary payer, the merchant computing system is capable of communication with the remotely accessible server and the

2018220069 22 Aug 2018 computing device of the primary payer.

[0027] As indicated above, in some embodiments of the present invention, the at least one further payer may communicate with the remotely accessible server with an electronic device. The electronic device may be of any suitable form for receiving and notifying the at least one further payer of a payment request and allowing the further payer to accept the request. The electronic device may typically be a computing device having at least one processor, at least one memory unit and at least one display. The electronic device may be a desktop computer, a laptop computer, a tablet device, a smart phone, a smart watch or a PDA.

[0028] Communication between the electronic device and the remotely accessible server may be effected by way of Short Message Service (SMS) protocol, Unstructured Supplementary Service Data (USSD) protocol, over a secure Internet connection, or by way of data communication enabled by a software application installed on the electronic device. The communication may be by way of a communication session as described above.

[0029] In some embodiments, the remotely accessible server may include a communication session component for establishing a communication session, preferably a secure communication session, between the computing device of the primary payer and the merchant computing system of the merchant. As indicated above, the communication session component may establish a communication session through the use of both physical and wireless communication links. In some embodiments, the communication session component may establish communication session with the electronic device of the at least one further payer.

[0030] In some embodiments, the remotely accessible server may include a processing request component for receiving a request originating from a primary payer to process a group payment transaction.

[0031] The request may include a payer account identifier and a division of a transaction value into a first amount owed by the primary payer and at least a second amount owed by the at least one further payer. The division is determined by the primary payer and may be an even or uneven split of the transaction value. For example, in some embodiments, the primary payer may not contribute to a group payment in which case the transaction value may be divided equally or unequally amongst two or more further payers.

[0032] Additionally, the remotely accessible server may include a merchant receiving component for receiving a merchant identifier of a merchant in favour of which the group payment transaction is to be processed. In some embodiments, the merchant identifier may be included in the request received from the primary payer and the merchant receiving component

2018220069 22 Aug 2018 may obtain the merchant identifier from the request. In other embodiments, the merchant identifier may be provided by the merchant computing system. The merchant receiving component may preferably further receive a transaction completion time from the merchant computing system setting a time period by which the group payment transaction must be completed. The primary payer will typically be notified of the transaction completion time, via his or her computing device.

[0033] The remotely accessible server may include a look-up component for looking up an account of the primary payer in the account database. Typically, the look-up component may look up the payer account identifier of the primary payer in the payer account database.

[0034] Upon looking-up the account of the primary payer, one or more payment options may be displayed on the computing device of the primary payer. The one or more payment options may include applying one or more pre-authorised funds made available to the primary payer from the at least one further payer and/or transmitting at least one payment request to the at least one further payer.

[0035] The one or more pre-authorised funds may typically have been created earlier by the at least one further payer and assigned to the primary payer, preferably for use in a desired group payment transaction, namely the group payment transaction. The creation and assignment of pre-authorised funds will be described in detail later.

[0036] The payment request may be a request for any value of funds from the at least one further payer. This will also be described in detail later.

[0037] In some embodiments, the amount of the payment request may be determined by the primary payer. In other embodiments, the amount of the payment request may be determined automatically by the remotely accessible server upon determination, by the primary payer, of the division of the transaction value.

[0038] The remotely accessible server may include an action component for receiving input from the primary payer indicating a selected one or more payment options and for actioning the payment option(s) selected. For example, upon selecting at least one payment request, the action component may action the request by transmitting the request to the electronic device associated with the at least one further payer. Additionally, the action component may monitor the request, once transmitted, for acceptance by the at least one further payer.

[0039] The payment request may typically be transmitted to the electrical device of the at least one further payer in the form of an electronic notification and may be effected by way of

2018220069 22 Aug 2018

Short Message Service (SMS) protocol, Unstructured Supplementary Service Data (USSD) protocol, over a secure Internet connection, or by way of data communication enabled by a software application installed on the electronic device.

[0040] Generally, the payment request may include information identifying or about the group payment transaction, such as, e.g., the name of the primary payer, the amount owed, the transaction value, the number of people in the group (i.e., the number of further payers and the primary payer), a summary description of thegood(s), service(s) or information being purchased, and/or options to accept or decline the request. In some embodiments, the payment request may further include a deadline for responding to the request, typically set by the primary payer.

[0041] The option to accept or decline the request may be presented in any suitable form. Typically, however, the option may be presented in the form of a button or hyperlink routing or directing the at least one further payer into a secure communication session with the remotely accessible server. The at least one further payer may then elect to “accept” or “decline” the request.

[0042] If the request is accepted, the further payer may be prompted to at least enter payment details, such as, e.g., credit card or debit card details. In preferred embodiments, the further payer may further be prompted to enter his/her name and email address. Preferably, the payment details may include credit card details.

[0043] When payment details such as credit card details are entered, the system may preferably put a hold on the credit card for the amount being paid to “secure” the funds until the group payment transaction is authorized to proceed.

[0044] If the request is declined, the remotely accessible server may notify the primary payer that the request has been declined. The primary payer may then be presented with further options for securing the amount owed within the transaction completion time. These options may include altering the amount of funds requested and re-sending the request, altering the number of further payers participating in the group payment transaction, and/or sending further requests to further payers.

[0045] Additionally, the remotely accessible server may include an authorization component for authorizing a group payment transaction to proceed provided the transaction value has been secured within the transaction completion time. In some embodiments, the authorization component may decline a group payment transaction if the transaction value has not been secured within the transaction completion time. In preferred embodiments, however, the group payment transaction may be declined by the merchant computing system.

2018220069 22 Aug 2018 [0046] If authorized, the authorization component may further transfer funds corresponding to the transaction value to the merchant computing system. Generally, funds from each further payer are “secured” by placing a hold for an amount being paid on each payer’s nominated credit card. When the group payment transaction is authorised to proceed, the system finalises the hold on each of the nominated credit cards and then transfers funds corresponding to the transaction value to the merchant computing system.

[0047] If declined, the authorization component may additionally notify the primary payer that the group transaction has been declined. The primary payer may typically be notified by way of an electronic notification received on the computing device associated with the primary payer. In some embodiments, the authorization component may further notify the at least one further payer participating in the group payment transaction. Again, the at least one further payer may typically be notified by way of an electronic notification received on the electronic device associated with the at least one further payer.

[0048] Generally, if declined, the holds placed on each payer’s nominated credit card may be lifted, typically by the issuing bank orfinancial institution. Advantageously, this eliminates the need for the system to process refunds.

[0049] In some embodiments, the system may include software configured to be run on the computing device of the primary payer and/or the electronic device of the further payer. The software may preferably be interactive. In some embodiments, the software may be in the form of an application (i.e., an app) configured to be run on a smart phone or mobile device, for example. Generally, the app may enable payers to receive and transmit communications with the remotely accessible server and with group members via the remotely accessible server.

[0050] In other embodiments, the remotely accessible server may include a web server providing a graphical user interface through which a payer may interact with the system and the remotely accessible server. The web server may accept requests, such as HTTP and/or HTTPS requests and serve responses, such as HTTP and/or HTTPS responses, along with optional data content, such as web pages (e.g., HTML documents) and linked objects. Generally, the web server may enable payers to receive and transmit communications with the remotely accessible server and with group members via the remotely accessible server.

[0051] In some embodiments, the system may enable a primary payer to deposit the entire value or a part thereof of a pre-authorised fund, made available from a further payer to the primary payer, into a bank account associated with the account of the primary payer.

[0052] The funds may be provided in any suitable currency. The group transaction may be

2018220069 22 Aug 2018 formed of multiple different currencies. In particular, the primary payer may contribute funds in a first currency, and the at least one further payer may contribute funds in a second currency. The currencies may include digital currencies or cryptocurrencies.

[0053] In some embodiments, the system may enable a primary payer and/or further payer(s) to rate one another when involved in a group payment transaction. Typically, ratings may be visible within a group and/or outside the group. Advantageously, ratings may be used to portray confidence in a group payment transaction.

[0054] In some embodiments, the system may enable a follow-up request to be sent following-up on a payment request previously transmitted. The follow-up request, sent by the remotely accessible server, may be actioned by the primary payer or automatically by the server if the payment request is not responded to within a pre-set period of time.

[0055] In some embodiments, other further payers may be copied in on the follow-up request to increase social pressure on the further-payer to accept the payment request initially received.

[0056] In some embodiments, the follow-up request may include a response deadline to encourage a response by the recipient. The response deadline may be set by the primary payer or automatically by the system.

[0057] In some embodiments, the system may enable the primary payer to transmit a request for pre-authorised funds from one or more further payer in advance of a group payment transaction.

[0058] In some embodiments, the system may enable the primary payer to schedule periodic group payment transactions. Advantageously, this may facilitate in the group payment of utility bills and/or rent in a share house, for example. In such embodiments, the primary payer may specify in the request that the group payment transaction is a repeating transaction. The primary payer may further specify the frequency of the transaction, e.g., weekly, fortnightly, monthly, quarterly or every six months.

[0059] According to a third aspect of the present invention, there is provided a method of enabling a group payment transaction, said method including:

in response to a primary payer electing to group pay a transaction, establishing a communication session, via at least one remotely accessible server, between the primary payer and a merchant;

receiving a request at the at least one remotely accessible server from the primary

2018220069 22 Aug 2018 payer to process a group payment transaction, wherein the request includes a division of a transaction value to be group paid into a first amount owed by the primary payer and at least a second amount owed by the at least one further payer, said division being determined by the primary payer;

receiving and monitoring, at the at least one remotely accessible server, a transaction completion time set by the merchant;

upon receiving the request from the primary payer, looking up in an account associated with the primary payer one or more payment options for at least the second amount owed by the at least one further payer, said one or more payment options selected from:

receiving, at the at least one remotely accessible server, selected said one or more payment options from the primary payer and actioning said one or more payment options selected; and responsive to the transaction value being secured within the transaction completion time, processing the group payment transaction and transferring funds corresponding to the transaction value to the merchant.

[0060] The method may include one or more characteristics of the systems as hereinbefore described.

[0061] The method may or may not include an initial step of the primary payer registering an account with the payer account database via the remotely accessible server. The registering may include entering the primary payer’s name, contact details (e.g., address, email address and/or contact telephone number) and/or payment details, such as, e.g., credit card or debit card details, preferably credit card details.

[0062] Once registered, the primary payer, in some embodiments, may be assigned or may select an available account identifier, such as, e.g., an account number or a username. In other embodiments, the primary payer may use his or her email address as an account identifier. Generally, the primary payer may also be assigned or may select a password to enable the primary payer to log in to their account via a portal to the system, such as, e.g., a web page or app[0063] The primary payer may typically elect to group pay a transaction when online at a participating merchant’s website. The transaction may be in regard to any suitable online

2018220069 22 Aug 2018 transaction. For example, the transaction may be an online purchase or the paying of a utility bill. Generally, the primary payer may elect to group pay the transaction during the checkout process. Preferably, the primary payer may elect to group pay when selecting a payment method (e.g., over PayPal™, credit card, etc.).

[0064] On electing to group pay the transaction, a communication session may be established between the computing device of the primary payer and the merchant computing system via the remotely accessible server. Preferably the communication session may be a secure communication session.

[0065] In some embodiments, the primary payer, on his or her computing device, may be redirected to a group pay transaction website or app. In other embodiments, a group pay transaction platform may be directly integrated into the website of the merchant thereby allowing the group pay transaction to be processed from the merchant’s website.

[0066] The primary payer may be prompted by the website or app to input a payer account identifier (e.g., an account number, username or email address) and a password.

[0067] Once logged on, the primary payer may request to process a group payment transaction. As part of the request, the primary payer may designate one or more further payer participants from a list of available participants.

[0068] In some embodiments, the list of available participants may be restricted to a preorganised group (e.g., a group of friends, colleagues or connections who have all previously connected with one another through the group pay website or application).

[0069] In other embodiments, the list may present available participants restricted to a geographical region, a common interest group or some other grouping factor.

[0070] In yet other embodiments, the display may present a search window in which the primary payer may search for one or more further payers to participate in the group pay transaction. The search may be based on the name of the further payer or the account identifier of the further payer.

[0071] Any suitable number of available participants may be invited to participate in a group pay transaction. For example, the group pay transaction may include the primary payer and at least one, at least two, at least three, at least four, at least five, at least 10, at least 15, at least 20, at least 25, at least 30, at least 35, at least 40, at least 45, at least 50, at least 60, at least 70, at least 80, at least 90 or even at least 100 further payers.

2018220069 22 Aug 2018 [0072] In some embodiments, the at least one further payer may have been invited to participate in the group pay transaction prior to the primary payer electing to group pay a particular transaction. In other embodiments, the at least one further payer may be invited to participate after the primary payer has elected to group pay the particular transaction. In some such embodiments, the further payer invited may have to register an account with the payer account database prior to participating in the group pay transaction.

[0073] Once at least one further payer has been invited to participate in the group pay transaction, the primary payer may further designate, through the computing device of the primary payer, a division of the entire transaction value amongst the at least one further payer and optionally the primary payer. As indicated previously, the division may be an even or uneven division.

[0074] Prior to, during or after the request is received from the primary payer to process a group payment transaction, a transaction completion time by which the group payment transaction must be completed may be set. The transaction completion time may typically be set by the merchant and may be for any suitable period of time. For example, the transaction completion time may be for about two minutes, about three minutes, about four minutes, about five minutes, about six minutes, about seven minutes, about eight minutes, about nine minutes, about 10 minutes, about 15 minutes, about 20 minutes, about 30 minutes, about 45 minutes, about one hour, about two hours, about three hours, about four hours, about five hours, about six hours, about seven hours, about eight hours, about nine hours, about 10 hours, about 11 hours, about 12 hours, about 24 hours, about two days, about three days, about four days, about five days, about six days, about one week, about two weeks or even about one month.

[0075] Generally, the transaction completion time set by the merchant will be dependent upon the type of good(s) or service(s) being sold. For example, for high demand items, such as, e.g., concert tickets, it is envisaged that a short transaction time of between about 5-10 minutes may be set. Conversely, for items in less demand, a transaction time of between about 30 minutes to about 1 hour may be set.

[0076] The transaction completion time may typically be displayed on the computing device of the primary payer, preferably in the form of a countdown timer. In some embodiments, the transaction completion time may also be displayed on the display of electronic devices of participating further payers.

[0077] The transaction completion time may preferably be monitored by the remotely accessible server.

2018220069 22 Aug 2018 [0078] Upon receiving the request to process the group payment transaction from the primary payer, the remotely accessible computer may look up the account of the primary payer and display, on the computing device of the primary payer, one or more payment options available to the primary payer. The payment options, as indicated above, may be selected from: (i) applying one or more pre-authorised funds made available from the at least one further payer; and (ii) transmitting at least one payment request to the at least one further payer requesting funds [0079] The primary payer may then select, via his or her computing device, one or more of the payment options for actioning via the remotely accessible server as previously described.

[0080] Once any and all payments have been secured within the transaction completion time, the remotely accessible server may process the group payment transaction and transfer funds corresponding to the transaction value to the merchant. In some embodiments, the remotely accessible server may prompt the primary payer beforehand to confirm whether or not the group payment transaction is to proceed. Typically, primary payer may be prompted via an electronic notification received on his or her computing device, such as, e.g., a pop-up window with “proceed” and “decline” buttons.

[0081] If payments or funds are not secured within the transaction completion time, the remotely accessible server may decline the group payment transaction. In preferred embodiments, however, the merchant computing system may decline the group payment transaction.

[0082] If declined, the remotely accessible server may notify the primary payer that the group transaction has been declined. Again, the primary payer may typically be notified by way of an electronic notification received on the computing device associated with the primary payer. In some embodiments, the remotely accessible server may further notify the at least one further payer participating in the group payment transaction that the transaction has been declined. Again, the at least one further payer may typically be notified by way of an electronic notification received on the electronic device associated with the at least one further payer.

[0083] According to a fourth aspect of the present invention, there is provided a system for creating pre-authorised funds for use in a group payment transaction, said system including:

2018220069 22 Aug 2018 establish a communication session between the at least one remotely accessible server and a computing device of at least one further payer in response to the at least one further payer electing to create a pre-authorised fund;

receive a request from the at least one further payer to create a preauthorised fund, wherein the request at least includes account information of an account associated with the at least one further payer and a value of the preauthorised fund to be created;

securing funds from the at least one further payer corresponding to the value of the pre-authorised fund to be created;

creating the pre-authorised fund on the account associated with the at least one further payer; and optionally, upon receiving a request from the at least one further payer, assigning the pre-authorised fund created to an account associated with a primary payer.

[0084] The system may include one or more characteristics or features of the systems and method as hereinbefore described.

[0085] For example, the at least one remotely accessible server and the payer account database may be the same as described previously.

[0086] The remotely accessible server may be configured to transmit communications to and receive communications from a computing device of the at least one further payer over any suitable communications network or networks.

[0087] The communications may be received and transmitted over a communications network, which may include, among others, the Internet, LANs, WANs, GPRS network, a mobile communications network, etc., and may include wired and/or wireless communication links.

[0088] The communications may preferably be received and transmitted via a communication session established between the computing device of the at least one further payer and the remotely accessible server.

[0089] In preferred embodiments, the communication session established may be a secure communication session across an encrypted communication channel such as Hypertext Transfer Protocol Secure (HTTPS), Transport Layer Security / Secure Sockets Layer (TLS/SSL) or other secure channel.

[0090] The computing device of the at least one further payer may be any suitable external

2018220069 22 Aug 2018 processing device capable of communication with the remotely accessible server. The computing device may include at least one processor, at least one memory unit and at least one display. The computing device may be in the form of a desktop computer, a laptop computer, a tablet device, a smart phone, a smart watch or a PDA, for example.

[0091] Once a communication session has been established, the system may receive the request from the further payer to create the pre-authorised fund. The request may include account information of an account associated with the further payer, wherein the information is a payer account identifier. The request further includes a value of the pre-authorised fund to be created.

[0092] In some embodiments, the system may present a list of pre-set values for the further payer to elect (e.g., $20, $50, $100, etc.). In other embodiments, the further payer may input any suitable value.

[0093] Upon receiving the request, the system may secure funds from the further payer amounting to the value of the pre-authorised fund to be created. Funds may be secured in any suitable way. Typically, however, the further payer may be prompted to input payment details, such as, e.g., credit card, debit card or like, preferably credit card details.

[0094] When payment details such as a credit card are entered, the system may preferably put a hold on the credit card for an amount amounting to the value of the pre-authorised fund to be created. The hold may preferably “secure” the funds until the pre-authorised funds are either utilised or expire.

[0095] In some embodiments, the request may further include an expiry date before which any pre-authorised fund created must be utilised or it will expire. The expiry date may be set by the further payer or the system, preferably the further payer.

[0096] Once the funds are secured, the system may record on the pre-authorised fund on the account associated with the further payer. Additionally, the further payer may be notified that the pre-authorised fund has successfully been created.

[0097] Once created, the further payer may keep the pre-authorised fund in his or her account for use in or with a future group payment transaction.

[0098] In some embodiments, the further payer may elect to assign the pre-authorised fund to another payer, such as, e.g., a primary payer. Typically, a pre-authorised fund may be assigned by the further payer inputting, into the computing device, an account identifier of the another payer or primary payer to who the pre-authorised fund is to be assigned.

2018220069 22 Aug 2018 [0099] The account identifier may include a name, an email address or a telephone number, for example. Generally, upon entering the account identifier, the remotely accessible server may look-up an account associated with the account identifier and request verification from the further payer before assigning the pre-authorised fund.

[00100] In some embodiments, the further payer may be able to retract a pre-authorised fund previously assigned. For example, if a further payer assigns a pre-authorised fund for use in a proposed group payment transaction, the further payer may preferably be able to retract the preauthorised fund if he or she has a change of mind or if the group payment transaction never proceeds.

[00101] In some embodiments, the further payer may further be able to assign a preauthorised fund to a primary payerfor use in a specific group payment transaction. For example, the further payer may be able to specify that the pre-authorised fund assigned is to be used only in the group purchase of a particular item or group or category of items, e.g., concert tickets.

[00102] In some embodiments, the further payer may be able to alter the value of a preauthorised fund created and/or assigned. For example, the further payer may increase or decrease the value.

[00103] If decreasing the value, the difference may be returned to the further payer’s account and/or to nominated credit card of the further payer. In preferred embodiments, the hold on the further payer’s credit card may be decreased accordingly, releasing the hold on the difference.

[00104] If increasing the value, the further payer may be prompted to input payment details, e.g., credit card or debit card details, preferably credit card, for the difference. In preferred embodiments, the hold on the further payer’s credit card may be increased to the new amount.

[00105] According to a fifth aspect of the present invention, there is provided a method of creating pre-authorised funds for use in a group payment transaction, said method including:

in response to an at least one further payer electing to create a pre-authorised fund, obtaining at least account information of an account associated with the at least one further payer and a value of the pre-authorised fund to be created;

creating the pre-authorised fund on the account associated with the at least one further payer; and optionally, upon receiving a request from the at least one further payer, assigning the pre-authorised fund to an account of a primary payer.

2018220069 22 Aug 2018 [00106] The method may include one or more characteristics of the systems and method as hereinbefore described.

[00107] The method may or may not include an initial step of the further payer registering an account with the payer account database via the remotely accessible server. The registering may include entering the payer’s name, contact details (e.g., address, email address and/or contact telephone number) and/or payment details, such as, e.g., credit card or debit card details, preferably credit card details.

[00108] Once registered, the further payer, in some embodiments, may be assigned or may select an available account identifier, such as, e.g., an account number or a username. In other embodiments, the further payer may use his or her email address as an account identifier. Generally, the further payer may also be assigned or may select a password to enable the payer to log in to his or her account via a portal to the system, such as, e.g., a web page or app.

[00109] The further payer may typically elect to create a pre-authorised fund when online at the group pay transaction website or when using the app.

[00110] On electing to create a pre-authorised fund, a communication session may be established between the computing device of the further payer and the remotely accessible server. Preferably the communication session may be a secure communication session.

[00111] The further payer may then be prompted by the website or app to input his or her account identifier (e.g., an account number, username or email address) and a password.

[00112] Once logged on, the further payer may enter a value of the pre-authorised fund to be created. In some embodiments, the further payer may select a value from a list of pre-set values for the pre-authorised fund. In other embodiments, the further payer input any desired value.

[00113] Once a value has been entered, funds from the at least one further payer corresponding to the value of the pre-authorised fund to be created may be secured. Generally, the funds may be secured by the further payer inputting payment details, such as, e.g., credit card, debit card or like, preferably credit card details.

[00114] The remotely accessible server may preferably put a hold on the credit card for an amount amounting to the value of the pre-authorised fund to be created. The hold may preferably “secure” the funds until the pre-authorised funds are either utilised or expire.

[00115] In some embodiments, the method may further include setting an expiry date by

2018220069 22 Aug 2018 which the pre-authorised fund created must be utilised or it will expire. The expiry date may be set by the further payer or the system, preferably the further payer.

[00116] Once the funds are secured, the pre-authorised fund may be created and recorded against the account associated with the further payer. Additionally, the further payer may be notified that the pre-authorised fund has successfully been created.

[00117] As indicated above with respect to the system, in some embodiments, the further payer may elect to assign the pre-authorised fund to another payer, such as, e.g., a primary payer, retract an assigned pre-authorised fund and/or alter the value of a pre-authorised fund created and/or assigned.

[00118] 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.

[00119] 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 [00120] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information forthose skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of Invention in anyway. The Detailed Description will make reference to a number of drawings as follows:

[00121] Figure 1 illustrates a group payment transaction system according to an embodiment of the present invention;

[00122] Figure 2 is a flowchart showing steps in a method of the system shown in Figure 1;

[00123] Figure 3 illustrates a pre-authorised fund creation system according to an embodiment of the present invention; and [00124] Figure 4 is a flowchart showing steps in a method of the system shown in Figure 3.

DETAILED DESCRIPTION [00125] Figure 1 shows an embodiment of a group payment transaction system (100).

[00126] The group payment transaction system (100) includes a remotely accessible server

2018220069 22 Aug 2018 (110) and a payer account database (120) in communication with the server (110). The system (100) is interactive and configured to enable a primary payer (130) to coordinate, via a computing device (140), a group payment transaction between a group (indicated by the dashed box and including the primary payer (130) and one or more further payers (150) with respective electronic devices (160)), and a merchant computing system (170) of a merchant (180).

[00127] In the embodiment shown in Figure 1, the system (100) is being used to coordinate the group payment of a utility bill (190).

[00128] As shown, the remotely accessible server (110) may be any appropriate server computer including one or more processors and one or more memory units containing executable instructions/software to be executed by the one or more processors. The server (110) is in communication with the payer account database (120) and is able maintain the payer account database (120), which contains a plurality of payer records.

[00129] Each payer record includes an account identifier, such as, e.g., an account number, user name or registered email address. Each payer record further includes additional payer information, such as, e.g., personal information of the payer, funds available including any preauthorised funds made available, details of payment instruments, and/or the like.

[00130] When the primary payer (130) elects to group pay the utility bill (190) on the website of the merchant computing system (170), a secure communication session is established between the computing device (140) of the primary payer (130) and the merchant computing system (170) via the remotely accessible server (110). The primary payer (130) may or may not be redirected to a group payment website of the system (100).

[00131] Once the secure communication session is established, the primary payer (130) sends a request to the remotely accessible server (110) to process a group payment transaction. The request includes a division of the value (i.e., transaction value) of the utility bill (190) to be group paid into a first amount owed by the primary payer (130) and a second and third amount respectively owed by a second further payer (150a) and a third further payer (150b). The division is determined by the primary payer (130) and can be an even or uneven split of the value.

[00132] Before, at the same time as or after the primary payer (130) sends the request, the merchant (180) sets and sends a transaction completion time from the merchant computing system (170) to the remotely accessible server (110). The transaction completion time set is, in turn, displayed on the computing device (140) of the primary payer (130) as a countdown timer by which the group payment transaction must be finalised or be declined.

2018220069 22 Aug 2018 [00133] Upon receiving the request from the primary payer (130), the server (110) looks up, in an account of the primary payer (130) in the payer account database (120), one or more available payment options for payment of the value of the utility bill (190) for display on the computing device (140) of the primary payer (130).

[00134] The available payment options are selected from: (i) applying one or more preauthorised funds made previously available from the second and/or third further payers (150a, 150b); and/or (ii) transmitting one or more payment requests to the second and/or third further payers (150a, 150b) requesting funds.

[00135] Upon receiving the one or more payment options selected by the primary payer (130), the server (110) will, depending on the payment option selected, either process the group payment transaction if the entire value has been secured or transmit payment requests to the electronic devices (160) of the second and/or third further payers (150a, 150b) and monitor for acceptance of the requests.

[00136] The payment requests are transmitted to the electronic devices (160) of the second and/or third further payers (150a, 150b) as electronic notifications and may be effected byway of Short Message Service (SMS) protocol, Unstructured Supplementary Service Data (USSD) protocol, over a secure Internet connection, or by way of data communication enabled by a software application installed on the electronic device (160).

[00137] The payment requests include information about the group payment transaction, such as, e.g., the name of the primary payer (130), the amount owed, the entire value being group paid, the number of people in the group (i.e., the number of further payers (150) and the primary payer (130), a summary description of the good(s), service(s) or information being purchased, i.e., the utility bill (190), and/or options to accept or decline the request.

[00138] The option to accept or decline the request is presented in the form of a button or hyperlink in the electronic notification configured to route or direct the further payers (150) into a secure communication session with the remotely accessible server (110). Each further payer (150) can then elect to “accept” or “decline” the request.

[00139] If the request is accepted, the further payer (150) is prompted to enter payment details in the form of credit card details. The system (100) then proceeds to put a hold on a nominated credit card of the further payer (150) for an amount being paid to “secure” the funds until the group payment transaction is processed.

[00140] If the request is declined, the remotely accessible server (110) notifies the primary

2018220069 22 Aug 2018 payer (130) that the request has been declined. The primary payer (130) can then pursue further options for securing the amount owed within the transaction completion time. These options can include altering the amount of funds requested and re-sending the request, altering the number of further payers (150) participating in the group payment transaction, and/or sending further requests to further payers (150).

[00141] Responsive to the entire transaction value being secured within the transaction completion time, the server (110) will process the group payment transaction and transfer funds corresponding to the transaction value to the merchant computing system (170) of the merchant (180).

[00142] If the entire transaction value is not secured within the transaction completion time, the merchant computing system (170) will time-out and decline the group payment transaction. The remotely accessibly server (110) will, in turn, transmit an electronic notification to the computing device (140) of the primary payer (130) notifying the primary payer (130) that the group payment transaction has been declined.

[00143] If declined, the holds placed on any of the further payers (150) nominated credit cards will be lifted thereby releasing the funds. Advantageously, this eliminates the need for the system (100) to process refunds.

[00144] A method (200) of using the system (100) as shown in Figure 1 is now described in detail with reference to Figure 2.

[00145] As an initial step, the method (200) may include an initial step of the primary payer (130) registering an account with the payer account database (120) via the remotely accessible server (110). The registering includes entering the primary payer’s name, contact details (e.g., address, email address and/or contact telephone number) and/or payment details being a nominated credit card.

[00146] Once registered, the primary payer (130) typically elects to group pay a transaction when online at a participating merchant’s website. The transaction may be in regard to any suitable online transaction. For example, the transaction may be an online purchase or the paying of a utility bill as for example shown in Figure 1. The primary payer (130) elects to group pay the transaction during the checkout process, electing to group pay when selecting a payment method.

[00147] At step 210, on electing to group pay the transaction, a secure communication session is established between the computing device (140) of the primary payer (130) and the

2018220069 22 Aug 2018 merchant computing system (170) via the remotely accessible server (110).

[00148] At step 220, upon electing to group pay, the primary payer (130), on his or her computing device (140), is then prompted to logon by inputting a payer account identifier (e.g., an account number, username or email address) and a password.

[00149] Once logged on, the primary payer (130) requests to process a group payment transaction. As part of the request, the primary payer (130) designates one or more further payers (150) to participate in the group payment transaction and inputs a division of the transaction value to be divided for payment among the primary payer (130) and the further payers (150). Again, the division can be an even or uneven split and is determined by the primary payer (130).

[00150] At step 230, which can occur prior to, during or after step 220, a transaction completion time by which the group payment transaction must be finalised or be declined is set by the merchant (180) and sent from the merchant computing system (170) to the remotely accessible server (110). The transaction completion time set is, in turn, displayed on the computing device (140) of the primary payer (130) as a countdown timer.

[00151] At step 240, the remotely accessible server (110), upon receiving the request from the primary payer (130), looks up, in the account of the primary payer (130) in the payer account database (120), one or more available payment options for payment for display on the computing device (140) of the primary payer (130).

[00152] As indicated previously, the available payment options are selected from: (i) applying one or more pre-authorised funds made previously available from the second and/or third further payers (150a, 150b); and/or (ii) transmitting one or more payment requests to the second and/or third further payers (150a, 150b) requesting funds.

[00153] At step 250, the remotely accessible server (110) receives the one or more available payment options selected from the primary payer (130) and actions the payment options selected.

[00154] Depending on the payment options selected, the remotely accessibly server (110) will either proceed to step 260 and process the group payment transaction if the entire value has been secured, or transmit payment requests to the electronic devices (160) of the second and/or third further payers (150a, 150b) and monitor for acceptance of the requests. These options are described in greater detail above with respect to Figure 1.

[00155] At step 260, responsive to the entire transaction value being secured within the

2018220069 22 Aug 2018 transaction completion time, the server (110) processes the group payment transaction and transfers funds corresponding to the transaction value to the merchant computing system (170).

[00156] If the entire transaction value is not secured within the transaction completion time, the merchant computing system (170) will time-out and decline the group payment transaction. The remotely accessibly server (110) will, in turn, transmit an electronic notification to the computing device (140) of the primary payer (130) notifying the primary payer (130) that the group payment transaction has been declined.

[00157] Referring now to Figure 3, which shows an embodiment of a pre-authorised fund creation system (300) for use with the above described group payment transaction system (100). For the sake of clarity, reference numerals referring to the same features shown in Figure 1 will be retained in Figure 3.

[00158] The pre-authorised fund creation system (300) includes a remotely accessible server (110) and a payer account database (120) in communication with the server (110). The system (300) is interactive and configured to enable a payer (150) to create with a computing device (140) a pre-authorised fund for use in a group payment transaction.

[00159] In the embodiment shown in Figure 3, the system (300) is being used by a further payer (150) to create a pre-authorised fund to be assigned to a primary payer (130) for use in a group payment transaction.

[00160] As with the system shown in Figure 1, when the further payer (150) elects to create a pre-authorised fund on the website of the system (300), a secure communication session is established between the computing device (140) of the further payer (150) and the remotely accessible server (110).

[00161] Once the secure communication session is established, the further payer (150) sends a request to create a pre-authorised fund. The request includes account information of an account associated with the further payer (150) and a value of the pre-authorised fund to be created.

[00162] The system (300) then requests the further payer (150) to enter payment details in the form of credit card details and puts a hold on a nominated credit card of the further payer (150) for an amount amounting to the value of the pre-authorised fund to be created. The hold placed by the system (300) secures the funds until the pre-authorised fund created is used or expires.

[00163] The further payer (150) can also enter an expiry date by which the pre-authorised

2018220069 22 Aug 2018 fund created must be used or it will expire.

[00164] Once funds corresponding to the value of the pre-authorised fund have been secured, the system (300) creates the pre-authorised fund on the account associated with the further payer (150). An electronic notification is transmitted from the remotely accessible server (110) to the computing device (140) of the further payer (150) notifying the further payer (150) that the pre-authorised fund has been created.

[00165] The further payer (150) can then send a further request to the remotely accessible server (110) requesting that the pre-authorised fund created be assigned to the primary payer (130). The request includes an account identifier (e.g., account number, username, telephone number or email address) of the primary payer (130) to whom the pre-authorised fund is to be assigned.

[00166] Upon receiving the further request, the server (110) looks up, in the payer account database (120), the account identifier of the primary payer (130) and, upon identifying the account of the primary payer, requests verification from the further payer (150) before assigning the pre-authorised fund. An electronic notification may then be transmitted from the remotely accessible server (110) to the computing device (140) of the primary payer (130) notifying the primary payer (130) that a pre-authorised fund has been assigned from the further payer (150) to them.

[00167] A method (400) of using the system (300) as shown in Figure 3 is now described in detail with reference to Figure 4.

[00168] As with method (200), the method (400) may include an initial step of the further payer (150) registering an account with the payer account database (120) via the remotely accessible server (110). The registering includes entering the further payer’s name, contact details (e.g., address, email address and/or contact telephone number) and/or payment details being a nominated credit card.

[00169] Once registered, the further payer (150) typically elects to create a pre-authorised fund when online at a website of the system (300) or via a software application of the system (300).

[00170] At step 410, the further payer (150), on his or her computing device (140), logs on to the website of the system (300) by inputting a payer account identifier (e.g., an account number, username or email address) and a password.

[00171] Once logged on, the further payer (150) requests to create a pre-authorised fund.

2018220069 22 Aug 2018

As part of the request, the further payer (150) inputs a value of the pre-authorised fund to be created.

[00172] At step 420, the remotely accessible server (110) secures funds for the preauthorised fund to be created by prompting the further payer (150) to input payment details in the form of a nominated credit card for an amount corresponding to the value of the preauthorised fund to be created. The system (300) then proceeds to put a hold on the nominated credit card for the amount to secure the funds until the pre-authorised fund created is used or expires.

[00173] At step 430, the system (300) creates the pre-authorised fund on the account associated with the further payer (150). An electronic notification is transmitted from the remotely accessible server (110) to the computing device (140) of the further payer (150) notifying the further payer (150) that the pre-authorised fund has been created.

[00174] At step 440, the further payer (150) can optionally assign the pre-authorised fund to another payer, such as, e.g., a primary payer (130) as shown in Figure 3 for use in a group payment transaction, for example.

[00175] To assign the pre-authorised fund created, the further payer (150) submits a further request to the system (300) to assign the pre-authorised fund. The request includes an account identifier (e.g., account number, username, telephone number or email address) of the primary payer (130) to whom the pre-authorised fund is to be assigned.

[00176] Upon receiving the further request, the server (110) looks up, in the payer account database (120), the account identifier of the primary payer (130) and, upon identifying the account of the primary payer, requests verification from the further payer (150) before assigning the pre-authorised fund. An electronic notification may then be transmitted from the remotely accessible server (110) to the computing device (140) of the primary payer (130) notifying the primary payer (130) that a pre-authorised fund has been assigned from the further payer (150) to them.

[00177] The systems and methods described above may utilise funds provided in any suitable currency. The group transaction may be formed of multiple different currencies. As an illustrative example, the primary payer may contribute funds in a first currency, and the at least one further payer may contribute funds in a second currency. The currencies may include digital currencies or cryptocurrencies.

[00178] In the present specification and claims (if any), the word ‘comprising’ and its

2018220069 22 Aug 2018 derivatives including ‘comprises’ and ‘comprise’ include each of the stated integers but does not exclude the inclusion of one or more further integers.

[00179] 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.

[00180] 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.

2018220069 22 Aug 2018

Claims

1) applying one or more pre-authorised funds made available from the at least one further payer to the primary payer; and

1. A system for enabling a group payment transaction, said system including:

receive from the merchant computing system a transaction completion time;

look-up in an account of the primary payer in the payer account database, one or more payment options for at least the second amount owed by the at least one further payer, said one or more payment options selected from:

2) transmitting at least one payment request to the at least one further payer requesting funds;

receiving, at the at least one remotely accessible server, selected said one or more payment options from the primary payer and actioning said one or more payment options selected; and

2018220069 22 Aug 2018 responsive to the transaction value being secured within the transaction completion time, processing the group payment transaction and transferring funds corresponding to the transaction value to the merchant.

an action component for receiving a selected said one or more payment options from the primary payer and actioning said one or more payment options selected; and an authorization component for authorizing the group payment transaction to proceed, responsive to the to the transaction value being secured within the transaction completion time and transferring funds corresponding to the transaction value to the merchant computing system.

2. A system for enabling a group payment transaction, said system including at least one remotely accessible server having a processor to control execution of instructions from a memory unit and including:

a processing request component for receiving a request from the primary payer to

2018220069 22 Aug 2018 process a group payment transaction, wherein the request includes a division of a transaction value to be group paid into a first amount owed by the primary payer and at least a second amount owed by at least one further payer;

3. The system of claim 1 or claim 2, wherein the transaction is an online transaction, and the primary payer elects to group pay the transaction when selecting a payment method.

4. The system of any one of the preceding claims, wherein the division is determined by the primary payer.

5. The system of any one of the preceding claims, wherein a communication session is established between a merchant computing system, a computing device of a primary payer and the at least one remotely accessible server.

6. The system of any one of the preceding claims, wherein a communication session is established between a computing device of the at least one further payer and the at least one remotely accessible server.

7. The system of any one of the preceding claims, wherein the payer account database contains a plurality of payer records, each payer record including at least an account identifier associated with a payer of the payer record.

8. The system of any one of the preceding claims, wherein the server is in communication with a merchant database containing a plurality of merchant records, corresponding to

2018220069 22 Aug 2018 merchants who allow group payment transactions.

9. The system of any one of the preceding claims, wherein the remotely accessible server is configured to establish a secure communication session between the computing device of the primary payer and the merchant computing system of the merchant.

10. The system of any one of the preceding claims, wherein the remotely accessible server may include a merchant receiving component for receiving a merchant identifier of a merchant in favour of which the group payment transaction is to be processed.

11. The system of any one of the preceding claims, wherein the primary payer is notified of the transaction completion time.

12. The system of any one of the preceding claims, wherein the remotely accessible server includes a look-up component for looking up an account of the primary payer in the account database, and wherein upon looking-up the account of the primary payer, one or more payment options are displayed on the computing device of the primary payer.

13. The system of any one of the preceding claims, wherein the one or more pre-authorised funds have been created earlier by the at least one further payer and assigned to the primary payer.

14. The system of claim 13, wherein the pre-authorised funds have been allocated for use in the group payment transaction.

15. The system of any one of the preceding claims, wherein the remotely accessible server is configured to action a payment request by transmitting a corresponding payment request to electronic device(s) associated with the at least one further payer.

16. The system of any one of the preceding claims, wherein the payment request includes information identifying or about the group payment transaction.

17. The system of any one of the preceding claims, wherein the payment request includes a deadline for responding to the request, typically set by the primary payer.

18. The system of any one of the preceding claims, wherein credit card details are entered, and the system places a hold on the credit card for the amount being paid to “secure” the funds until the group payment transaction is authorized to proceed.

19. The system of any one of the proceeding claims, wherein the remotely accessible server is configured to decline a group payment transaction if the transaction value has not been

2018220069 22 Aug 2018 secured within the transaction completion time.

20. The system of any one or the proceeding claims, further including the step of enabling a primary payer and/or further payer(s) to rate one another when involved in a group payment transaction.

21. The system of any one or the proceeding claims, configured to enable the primary payer to schedule periodic group payment transactions.

22. The system of any one or the proceeding claims, wherein the at least one further payer is invited to participate in the group pay transaction prior to the primary payer electing to group pay a particular transaction.

23. The system of any one or the proceeding claims, wherein once any and all payments have been secured within the transaction completion time, the remotely accessible server processes the group payment transaction and transfer funds corresponding to the transaction value to the merchant.

24. A method of enabling a group payment transaction, said method including:

receiving a request at the at least one remotely accessible server from the primary payer to process a group payment transaction, wherein the request includes a division of a transaction value to be group paid into a first amount owed by the primary payer and at least a second amount owed by the at least one further payer;

upon receiving the request from the primary payer, looking up in an account associated with the primary payer one or more payment options for at least the second amount owed by the at least one further payer for display on a computing device of the primary payer, said one or more payment options selected from:

25. A system for creating pre-authorised funds for use in a group payment transaction, said system including:

establish a communication session between the at least one remotely accessible server and a computing device of at least one further payer in response to the at least one further payer electing to create a pre-authorised fund;

receive a request from the at least one further payer to create a pre-authorised fund, wherein the request at least includes account information of an account associated with the at least one further payer and a value of the pre-authorised fund to be created;

26. A method of creating pre-authorised funds for use in a group payment transaction, said method including:

securing funds from the at least one further payer corresponding to the value of the preauthorised fund to be created;