A METHOD AND APPARATUS FOR FACILITATING PAYMENTS
FIELD OF THE INVENTION
The invention relates to a method and apparatus for facilitating payments from a plurality of payers to a plurality of payees. In particular but not exclusively, the invention relates to a method and apparatus for monitoring financial institution accounts for receipt of payments identified with a payment code, notifying the payee of the payment and transferring the payment into the payee's account.
BACKGROUND TO THE INVENTION
As the popularity of card-based payments increases, it is becoming less common for customers to carry cash. However, for many merchants it is not feasible or desirable to set up sophisticated point of sale payment systems including electronic fund transfer at the point of sale "EFTPOS" or credit card machines. Further, the monthly rental charges involved with these systems may be cost-prohibitive. Small businesses such as market stallholders, low- volume tourism operators and home-based business therefore often do not accept card-based payments. Similarly, for infrequent events such as school fairs or charity events, cash is often the only accepted payment method.
As a result of the inabil ity to accept payment using cards such merchants lose sales from customers who are not carrying cash. The customers are also inconvenienced as they either need to find a nearby "Cash Machine" to take out cash, or they miss out on the products and/or services they wish to purchase.
In order to sell to cash-less customers, some merchants have allowed customers to make a money transfer into the merchant's account directly from the customer's bank, using for example the bank's mobile banking application on a smartphone. However, this requires a level of trust on the part of the seller - the customer can feign making the payment, accidentally enter the wrong account number, or a bank error can occur. There is no easy or immediate way for the merchant to verify the payment has been made successfully. Some attempts to have been made to allow alternatives to EFTPOS or credit payments for businesses that are primarily cash-based. However, these often require customers making payments to sign up in advance, and enter their financial information. Users often do not feel comfortable providing personal details such as financial information to unfamiliar third parties. In addition to the above, in some situations the physical l imitation of having only one or a small number of physical payment terminal devices can lead to congestion and bottlenecks. This can be problematic for some operators, for example charitable collections.
It is an object of the invention to provide a method for facilitating payments which overcomes or at least ameliorates some or all of the above mentioned problems, or to at least provide the publ ic with a useful choice.
Reference to any prior art in this specification does not constitute an admission that such prior art forms part of the common general knowledge.
SUMMARY OF THE INVENTION According to one exemplary embodiment there is provided a method for facilitating payments from a plurality of payers to a plurality of payees by a controller, including the steps of the controller:
i. associating with each payee, information on a payee financial institution account and at least one payment code; ii. monitoring, using financial institution provided electronic systems a plural ity of financial institution accounts for receipt of payments, wherein the plurality of financial institution accounts include at least one financial institution account at each of at least two financial institutions and wherein the payments are identified with a payment code; and iii. for each received payment: a. identifying the payee the payment is for based on the payment code; b. notifying the payee that the payment has been received; and c. transferring the payment into the payee financial institution account using financial institution provided electronic systems.
Preferably the notification is immediate.
Preferably, the payment code includes a transaction code.
Preferably the payment code includes a merchant code. Preferably the payment code includes a third party code.
Preferably the third party code is an online sale identifier.
Preferably the payment code is a transaction code.
Alternatively the payment code is a merchant code.
Alternatively the payment code is a third party code. Preferably the third party code is an online sale identifier.
Preferably at least one of the plural ity of financial institution accounts is registered as a pre- registered payee.
Preferably the controller pre-registers at least one payee with at least two financial institutions. Preferably the controller automates payee financial institution account verification.
Preferably the controller sends notification to the payee along with an identifier. Preferably the controller using financial institution provided electronic systems transfers the payment to the payee financial institution account after a predetermined time period.
Alternatively the controller using financial institution provided electronic systems transfers the payment to the payee financial institution account immediately after notifying the payee that payment has been received.
Preferably, the controller uses the payment amount to aid identification of the payee.
Preferably the controller for at least one payee aggregates payments having a payment code associated with the payee and pays using financial institution provided systems the aggregated amount to the payee financial institution account.
Preferably the controller notifies the payee by a communication method selected from one or more of the group consisting of email, mobile application, point of sale device, text message and automated telephone cal ls.
Preferably payment is received from a payer financial institution account at the same financial institution as the monitored financial institution account that receives the payment.
Preferably the payer financial institution account and the payee financial institution account are at different financial institutions. Preferably the controller using financial institution provided electronic systems transfers the payment in a different currency from the currency in which the payment is received.
Preferably the controller further receives a request from a payee for a payment code to be associated with a payee, generates the payment code and associates the payment code with the payee.
Preferably the generated payment code is associated with a single payment and the payment code is retired once the payment has been received.
Preferably the request for a payment code includes the amount of the payment to be made using the generated code and wherein the controller stores the amount of the expected payment in association with the payment code.
Preferably payment includes payment in currency and currency includes virtual currency.
According to another exemplary embodiment there is provided an apparatus for facilitating payments from a plurality of payers to a plural ity of payees comprising:
i. a processor; and
ii. a memory coupled to the processor and capable of storing data, wherein the processor is configured to:
a. associate with each payee, information on a payee financial institution account and at least one payment code;
b. monitor, using financial institution provided electronic systems a plural ity of financial institution accounts for receipt of payments, wherein the plurality of financial institution accounts include at least one financial institution account at each of at least two financial institutions and wherein the payments are identified with a payment code; and
c. for each received payment:
1 . identifying the payee the payment is for based on the payment code;
2. notifying the payee that the payment has been received; and
3. transferring the payment into the payee financial institution account using financial institution provided electronic systems.
Preferably the notification is immediate.
Preferably the payment code includes a transaction code.
Preferably the payment code includes a merchant code. Preferably the payment code includes a third party code.
Preferably the third party code is an online sale identifier.
Preferably the payment code is a transaction code.
Alternatively the payment code is a merchant code.
Alternatively the payment code is a third party code. Preferably the third party code is an online sale identifier.
Preferably at least one of the pl urality of financial institution accounts is registered as a pre-registered payee.
Preferably the processor is further configured to pre-register at least one payee with at least two financial institutions. Preferably the processor is further configured to automate payee financial institution account verification.
Preferably the processor is further configured to send notification to the payee along with an identifier. Preferably the processor is further configured to transfer using financial institution provided electronic systems, the identified payment to the payee financial institution account after a predetermined time period.
Alternatively the processor is further configured to transfer using financial institution provided electronic systems, the identified payment to the payee financial institution account immediately after notifying the payee that the identified payment has been received.
Preferably the processor is further configured to use the payment amount to aid identification of the payee.
Preferably the processor is further configured to, for at least one payee to aggregate payments having a payment code associated with the payee and pay using financial institution provided electronic systems the aggregated amount to the payee financial institution account.
Preferably the processor is further configured to notify the payee by a communication method selected from one or more of the group consisting of email, mobile application, point of sale device, text message and automated telephone calls.
Preferably payment is received from a payer financial institution account at the same financial institution as the monitored financial institution account that receives the payment. Preferably the payer financial institution account and the payee financial institution account are at different financial institutions. Preferably the processor is further configured to, using financial institution provided electronic systems transfer the payment in a different currency from the currency in which the payment is received.
Preferably the processor is further configured to receive a request from a payee for a payment code to be associated with a payee, generates the payment code and associates the payment code with the payee.
Preferably the generated payment code is associated with a single payment and the payment code is retired once the payment has been received.
Preferably the request for a payment code includes the amount of the payment to be made using the generated code and wherein the processor is further configured to store the amount of the expected payment in association with the payment code.
Preferably payment includes payment in currency and currency includes virtual currency. It is acknowledged that the terms "comprise", "comprises" and "comprising" may, under varying jurisdictions, be attributed with either an exclusive or an inclusive meaning. For the purpose of this specification, and unless otherwise noted, these terms are intended to have an inclusive meaning - i.e. they will be taken to mean an incl usion of the listed components which the use directly references, and possibly also of other non-specified components or elements.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will now be described by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows a flow diagram of a method for faci litating payments according to the present invention; Figure 2 shows a process diagram of the method of Figure 1 ;
Figure 3 shows the application architecture of an embodiment of the present invention;
Figure 4 shows a process diagram of transaction code generation according to an embodiment of the present invention;
Figure 5 shows a process diagram of transaction code usage according to an embodiment of the present invention;
Figure 6 shows a flow diagram a method for facilitating payments according to the present invention, including integration with a payee's point of sale system;
Figure 7 shows an embodiment of the method of Figure 6;
Figure 8 shows another embodiment of the method of Figure 6;
Figure 9 shows an embodiment of a method for facilitating payments according to the present invention, including integration with a vending machine; and
Figure 10 shows a block diagram of an apparatus according to the present invention.
DETAILED DESCRIPTION Overview
The present invention is for facilitating payments from consumer payers to merchant payees. In particular though not exclusively this invention is suited to situations in which the payee is not able to, or does not wish to allow card-based payments, and the payer does not have cash on hand. The present invention allows payees to be instantly notified when payers have successfully made payments into intermediate accounts, prior to actually receiving the money in the payees' own accounts.
In summary, referring to Figure 10 the controller, system or apparatus of the present invention includes at least a processor 101 , one or more memory devices 102 or an interface for connection to one or more memory devices, input and output interfaces for connection to external devices in order to enable the system to receive and operate upon instructions from one or more users or external systems, a data bus for internal and external communications between the various components, and a suitable power supply. Further, the controller may include one or more communication devices 103 (wired or wireless) for communicating with external and internal devices, and one or more input/output devices, such as a display, pointing device, keyboard or printing device. Further the controller may have access to a data store 102 including but not limited to a database. Processor includes single and multi-cored processors and is to be understood to include multiple processors.
The processor 101 is arranged to perform the steps of a program stored as program instructions within the memory device. The program instructions enable the various methods of performing the invention as described herein to be performed. The program instructions may be developed or implemented using any suitable software programming language and toolkit, such as, for example, a C-based language. Further, the program instructions may be stored in any suitable manner such that they can be transferred to the memory device or read by the processor, such as, for example, being stored on a computer readable medium. The computer readable medium may be any suitable medium, such as, for example, solid state memory, magnetic tape, a compact disc (CD-ROM or CD-R/W), memory card, flash memory, optical disc, magnetic disc or any other suitable computer readable medium. The system is arranged to be in communication with external data storage systems, transactions systems or devices in order to retrieve the relevant data and carry out the relevant transactions.
It will be understood that the system herein described includes one or more elements that are arranged to perform the various functions and methods as described. The description is aimed at providing the reader with an example of a conceptual view of how various modules and/or engines that make up the elements of the system may be interconnected to enable the functions to be implemented. Further, the following portion of the description explains in system related detail how the steps of the described method may be performed. The conceptual diagrams are provided to indicate to the reader how the various data elements are processed at different stages by the various different modules and/or engines.
Financial Institutions
In the context of this specification, a financial institution means an institution that provides financial services for its clients. Financial institutions include depositary institutions that accept and manage monetary deposits, including but not limited to banks, credit units, trust companies and mortgage loan companies. A financial institution may include one or more branches falling under the same financial institution. The branches collectively forming the financial institution. The following are examples of financial institutions operating in New Zealand: ASB Bank Limited, Kiwibank Limited and Bank of New Zealand.
Financial Institution Accounts
A "financial institution account" refers to an account at a financial institution.
The financial institution account may be a cheque, savings, credit or any other type of account offered by a financial institution. Generally, accounts are represented by account numbers, which identify the financial institution, the branch of the financial institution, and a number associated with the beneficiary of the account, followed by a suffix indicating a specific account belonging to the beneficiary. The suffix may indicate the type of account e.g. cheque or savings. Account numbers are used to make and track payments between different accounts either within the same financial institution, or between different financial institutions. In the context of the specification "payee financial institution accounts" belong to the payees. The present invention is for facilitating payments into these payee financial institution accounts.
Payee set-up
Referring to the Figures a payee or merchant registers with a controller 12 in advance of receiving payments. The control ler's administration web server 1 3 handles payee registration. The controller 12 associates with each payee information on a payee financial institution account and at least one payment code. The controller 12 may also associate various communication channels as detailed below with the various payees. The information on a payee financial institution account includes any information that enables the controller 12 to enact a payment into the financial institution account. In most circumstances, this information will consist of or incl ude an account number. The step of associating with each payee information on a payee financial institution account and at least one payment code may be fully or partially automated by the controller 12. For example, a payee may fill in an online form to sign-up for a service implementing the present invention. A controller 12 may then automatically generate a payment code for example a merchant code which is l inked to the payee's financial institution account and provide this payment code to the payee. Financial institution accounts, payment accounts, and the associations between these are stored in a database 1 1 associated with the controller 12.
When signing up new payees, the controller 12 may automate verification of the payee financial institution account. For example, the controller 12 may attempt to make a nominal payment, with a check payment code into the payee financial institution account provided by the payee, to confirm account number validity and ownership. The payee can then confirm ownership of their account by providing the check payment code to the controller 12, preferably via a web interface 1 3.
Payment Codes
A payment code is any code which identifies a particular payment. The payment code may represent a transaction code, merchant code, third party code, and/or an online sale identifier or any combination thereof.
Preferably, the controller 12 receives a request from a payee for a payment code to be associated with the payee. In response to such a request, the controller 12 will then generate the payment code and associate the payment code with the payee. The controller 12 may associate such a generated payment code with a single payment and retire the code once the payment has been received. Later reuse of the single payment codes after a period of time is also anticipated.
A payee request for a generated payment code may also include an amount of the payment to be made using the generated code. When such a request includes an amount, the controller 12 may store the amount for the expected payment in association with the payment code. This allows the controller 12 to cross-check payment codes against payment amounts and detect errors that may be made in payment. A transaction code is a code which is unique for each transaction or sale for a given period of time. For example a transaction code may l ink to an identification number of a product being sold e.g. corresponding to a barcode ID number, event ticket number etc. Transaction codes may be predefined in this way, or they may be manually or automatically generated at the point of sale. Transaction codes may be automatically generated by a payee's point of sale device or a payee's mobile application. Figure 4 shows a process diagram showing automatic transaction code generation by the controller 12. A merchant code is a code which uniquely identifies a merchant. Merchant codes may be assigned and provided to payees when they sign up for a service implementing the method of this invention. For example the assignment of merchant codes may be automated by the controller 1 2 when merchants sign-up online.
A third party code is any code which is assigned by a third party not being the controller 12 or the payee. For example, this may be an online sale identifier, which is assigned by an online shop that is not necessarily owned by the payee. Such online shops may include online auction sites or online shopping platforms.
Furthermore, the controller 12 may use the payment amount to aid identification of the payee.
Figure 1 shows an embodiment of a method for facilitating payments according to the present invention. Figure 2 shows a process diagram of the method of Figure 1 . Referring to Figure 1 after the payer and payee have reached a sale agreement 1 , the payee provides the payer with a payment code 2, associated with the payee financial institution account which the payee would like to receive the payment in. The payer makes a payment 3 into one of several financial institution accounts which are monitored by the controller 12. The payer may make the payment by any suitable means, including telephone banking and internet banking. When making the payment, the payer selects the monitored account from a list of preregistered payees provided by the payer's bank. The payer identifies the payment using a payment code associated with the payee to which payment is being made. For example, if the payer is making a payment using a mobile banking application provided by their bank, the payer may enter the payment code in the "particulars", "code", or "reference" section when entering payment details. The payment is credited 4 to a financial institution account monitored by the controller 12. Account Monitoring
Referring to Figure 3 a transaction monitor 19 of the controller 12 monitors a plurality of financial institution accounts for receipt of payments. The transaction monitor 19 monitors the plurality of financial institution accounts through financial institution provided electronic systems for example, a bank- provided online-banking system. The transaction monitor 1 9 may use a web- parsing engine 14 to access the financial institution's web application server 26 to monitor for receipt of payments. Alternatively, an Application Program Interface engine 15 accesses the financial institution's transaction servers 27. The controller 12 may access the financial institution provided electronic system in any suitable way, including bank-provided APIs.
The controller 12 monitors using transaction monitor 19 at least one financial institution account at multiple financial institutions. In the simplest case, the controller 12 monitors two or more accounts each of which are held at different financial institutions. Preferably, the controller 12 will monitor accounts at all of the major financial institutions between which transactions are carried out. For example, in a New Zealand context, the controller 12 may monitor financial institution accounts based in each of the major New Zealand banks. In the context of other countries or indeed multiple countries the banks located in those countries have accounts controlled and monitored by the controller 12.
In the preferred embodiment, the payment is received from a payer financial institution account at the same financial institution as the monitored financial institution account that receives the payment. For example, if a particular payer banks with bank A, the payer will make a payment into a monitored financial institution account held at bank A. Intra-financial institution transfers are in most cases much faster than inter-financial institution transfers. Most intra-financial institution transfers between accounts are instantaneous, or near-instantaneous, and are transferred as cleared funds. Therefore, when a payer makes a payment into a monitored financial institution account at the same financial institution as the payer's own account, the controller 12 will receive the payment almost instantly, and can in turn notify the payee that it has received the payment almost instantly.
The present invention is extremely beneficial in situations where the payer's financial institution account is under a different financial institution from that of the payee's financial institution account. If the payer were to attempt to make a payment through financial institution provided systems, the payee would generally not receive the payment in the payee's account until later, usually the next business day, but in some cases within the next hour if the payer's bank processes payments hourly and the transaction is during the bank's service hours. The present invention allows payees to have confidence that the payee has successfully made the payment. When the controller 12 detects 5 that a payment has been received, the controller 12 executes the following steps:
Payment Identification
Firstly, the controller 12 identifies the payee the payment is for based on the payment code 6. This is using the transaction code engine 20 and reconciliation engine 21 and the aforementioned stored associations between payees, information on payee financial institution accounts and payment codes. Thus the controller 12 is able to identify the payee using the payment codes referenced in the particulars for each received payment. The controller 12 can also use the payment code for other purposes, for example to verify a transaction. If the payment code is a transaction code which was generated by the controller 12 the controller can match received transaction codes against generated transaction codes. Figure 5 shows a process diagram of possible payment transaction code usage. Payee Notification
Once the controller 12 has identified the payee for a particular payment, the controller 12 then notifies the payee that the payment has been received 9. Preferably, the controller 12 notifies the payee immediately or as soon as possible after the controller 12 has identified the payee.
Notification can occur in any suitable way. Possible notification methods via the messaging interfaces 1 6 include but are not limited to email, a mobile application, notification via a point of sale device, text message, or automated telephone calls. The controller 12 may include a push messaging interface 1 6 for issuing notifications to a mobile application, for example.
The controller 12 may notify the payee via more than one notification method. The notifications may be simultaneous, or at different times. For example, the controller 12 may first send an immediate notification to the payee via text message, and at a later time for example at the end of a business day, send an email notification including all of the payments made during the day. The invention is not limited in this respect.
The notification message may contain any suitable information. For example, it may include a timestamp, payment code and a payment amount. In addition, the notification may include an identifier. The identifier may be used for security purposes, to verify the authenticity of the notification. For example, the identifier may be a secret identifier only known by the payee and the controller 12, such that if the identifier is included in a notification the payee can be assured that the notification is genuine. The identifier may be chosen by the payee and communicated to the controller 12 on sign-up, or alternatively it may be provided to the payee by the controller 12. The controller 12 may provide mechanisms to change the identifier at regular intervals, or when requested by the payee. The controller 12 may associate one or more communication channels and/or settings with each payee and store in a database 1 1 .
When the payee receives notification of the payment from the control ler 1 2, they can be assured that the payment has been made, and can safely provide the goods and/or services 10 to the payer.
Payment Transfer
Final ly, the control ler 12 transfers the payment into the payee's financial institution account 7. The control ler 1 2 requests the transfer using financial institution provided electronic systems. An example of such a financial institution provided electronic system is direct l i nks offered by some banks to their electronic systems over the internet via an FTP-server connection. Files can be automatically created at the control ler's end and uploaded directly into the FTP-server. The bank's system picks up the files and sends a Money Transfer Schedule back to the control ler's folder on the FTP server, which confirms receipt of the file. The bank systems then make the transfer 8.
The control ler 12 may request payment into the payee's financial institution as soon as the payee has been identified, simultaneously with payee notification, or immediately after notifying the payee. An immediate transfer may be preferred so that the payee can receive the payment in the payee financial institution account as soon as possible.
Alternatively, the control ler 12 may transfer the payment to the payee financial institution account after a predetermined time period. For example, the controller 1 2 may transfer the payment one hour after receiving the payment. This may be desirable to simplify the reversal of transaction errors, or to al low prompt refunds if the payer wishes to return the product and/or service. The present invention may incl ude a mechanism by which the control ler 12 receives requests for refunds back into the payer's account, and enacts the refunds. The controller 12 may transfer the payment into the payee financial institution account independently for each received payment. Alternatively, the controller 12 may aggregate payments having a payment code associated with the payee and pay the aggregated amount to the payee financial institution account. For example, the controller 12 may receive numerous payments destined for a particular payee throughout the day. The controller may receive these payments in multiple monitored financial institution accounts, from multiple financial institution accounts associated with financial institutions different payers. As the control ler 12 receives the payments, the controller 12 may notify the payee immediately after each payment, but refrain from making the transfer. At the end of a business day, week, or any other suitable time period, the controller 12 may make an aggregate payment which includes all of the payments within that time period as a single transaction. Alternatively payments may be aggregated when a certain threshold aggregated payment sum is reached. The invention is not limited in this respect.
The result is that the payee receives convenient and instant notification that the payment has successfully been paid to an intermediate financial institution account prior to the payment being received in the payee's financial institution account.
The controller 12 may, using financial institution provided electronic systems transfer the payment in a different currency from the currency in which the payment is received. For example, the controller 12 may make a payment into a foreign payee bank account. The controller 12 make use of bank- provided electronic transfer platform to make an international money transfer.
A currency may be a conventional currency or a virtual currency. Virtual currency is understood to mean a type of regulated or unregulated, digital money. Unregulated digital money is usually issued and control led by its developers, and used and accepted among the members of a specific virtual community. Virtual currencies include but are not limited to crypto currencies such as Bitcoin.
Financial Institution account pre-registration In a preferred embodiment, the financial institution accounts monitored by the controller 12 are registered with the financial institutions as pre-registered payees. Financial institutions, in particular banks, often have mechanisms by which an account can be pre-registered to enable quicker and easier payment into the account. Some financial institutions refer to these as "pre- assigned payees". For example, pre-registration might enable a payer to pay to the account by entering a simplified account name. Over bill payments or bank transfers, this replaces the need for payers to enter the account number, which is often a long series of digits which are cumbersome to enter and easy to mistype. Pre-registered accounts may be browseable, or searchable by key-words. The use of pre-registered accounts significantly decreases the chance that a mistake will occur when the payer makes payment into the financial institution account, and makes it quicker and easier to pay to the financial institution account.
High-vol ume payees may wish to be pre-registered under their own names with two or more financial institutions. Payers can then search for or enter the payee's custom pre-registered payee name to direct payment into the payee's account. This may avoid the need for payers to enter payment codes which identify the particular merchant e.g. payment codes including merchant codes. In such cases, the controller 12 may pre-register such payees with at least two financial institutions. The pre-registration itself may be automated where the financial institution allow this to be done electronically, or alternatively the controller 12 may issue instructions to manually pre-register the payee under one or more monitored accounts. POS software integration
Figure 6 shows a method for facilitating payments according to the present invention, including integration with a payee (merchant's) point of sale system 45. A payee enters 30 a sale into the payee's POS (Point of Sale) system 45, and selects the method/apparatus of the present invention as the payment method 31 .
The Point of Sale terminal apparatus or software implementation (POS System) can, at time of sale, request from the controller's transaction code interface 1 7 via a wired or wireless internet connection a unique transaction code for the transaction 32. This request would include a merchant identifier so the transaction code created can be stored in the controller database referenced against the given merchant.
The generated transaction code is returned 33 to the POS System which then communicates this code to the consumer 34. This can be via a number of possible channels, including a terminal display screen and via a mobile application on the consumer's personal device. This latter form can be triggered by user action such as scanning a Q code or tapping the phone to the terminal for Near Field Communication (NFC) transfer, or wireless signalling such as Bluetooth beacon.
The consumer then includes this transaction code when making the payment 35 and the payment is credited to a monitored financial institution account 36.
When the transaction monitor 19 detects a new credit 37 and the reference matches an allocated transaction code 38, the transaction code engine 20 of the controller 12 first deactivates 43 the transaction code in the database 1 1 , then notifies the POS System 45 via a call-back mechanism that the payment is received 39.
Payment to the payee's financial institution account 7 proceeds as previously described. Figure 7 shows an implementation of the method of Figure 6. The POS System 45 is configured to interface with the controller 12.
Figure 8 shows another implementation of the method of Figure 6. The POS System has a hardware device 46 positioned between an existing POS terminal device 45 and POS payment device (eg EFTPOS terminal) 47. This device 46 emulates both devices' connections so it can be dropped in-place to existing configurations. This payment channel device 46 is then responsible for initiating and completing the transaction when required and for transparently forwarding requests to the POS payment device when not required. Figure 9 shows another implementation of integrating a POS system with the method of the present invention. The POS system 45 is a vending machine. A payer (consumer) wishes to purchase an item, the payer credits the vending machine with an amount, using the method of the present invention. The vending machine includes a merchant code, which the customer uses to make the payment. When the vending machine receives notification that payment has been successful, the customer can make their selection and purchase the item. An alternative implementation may provide the vending machine with an interface to request and display transaction codes.
While the present invention has been illustrated by the description of the embodiments thereof, and while the embodiments have been described in detail, it is not the intention of the Applicant to restrict or in any way limit the scope of the appended claims to such detail. Further, the above embodiments may be implemented individually, or may be combined where compatible. Additional advantages and modifications, including combinations of the above embodiments, will readily appear to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described. Accordingly, departures may be made from such details without departure from the spirit or scope of the Applicant's general inventive concept.
There is thus provided a method for facilitating payments from a plurality of payers to a plurality of payees by a controller that is simple, reliable and convenient. Transaction bottlenecks associated with POS machines such as EFTPOS terminals are avoided, as the invention allows the acceptance of multiple payments concurrently. The invention also allows the acceptance of payments remotely (e.g. by telephone, or online).
There is no need to modify existing financial institution systems to use the method of the present invention. Payers can pay payees quickly and easily via a short reference code - this avoids the need to type in long account numbers which is cumbersome and prone to mistakes. The invention also removes real or perceived risks associated with publicising financial institution account numbers. Furthermore, the method of the present invention does not require intermediate accounts having a "float" of money and settlement between various intermediate accounts. Instead, payments flow directly from payer, to intermediate account, to payee. The system under the present invention also provides a convenient way to refund payments. Payers can feel comfortable making payments under the present invention as they use their own banking systems which they known and trust.
Through instant notification, payees can feel comfortable accepting payments from payers even if they do not receive the payment in their bank accounts immediately.