A SYSTEM AND METHOD FOR FACILITATING A PAYMENT TRANSACTION

Technical Field

The present invention relates to a system and method for facilitating payment transactions.

Background of the Invention

Payment transactions may be implemented using transfer systems including Internet credit card transfer or other monetary transfer services arranged to transfer between accounts associated with parties involved in a transaction.

To facilitate a transfer a payee's account details are required. This generally requires a payer to have a payee's account details. Bank account numbers, for example, are unusually lengthy and difficult to remember. Further, allowing many persons access to a payee's account details risks the security of the account.

Summary of the Invention

In accordance with a first aspect, the present invention provides a method for facilitating a payment transaction, comprising the steps of receiving from a payer a payee identifier, retrieving payee account details associated with the payee identifier, the account details identifying a payee account, and making a payment to the payee account .

In an embodiment, the payee identifier does not disclose the account details of the payee account.

In an embodiment, the payee identifier is a simple to remember or store alphanumeric code.

In an embodiment, the payee identifier comprises a communication identifier of a communication device. In some embodiments, the communication identifier is a telephone number or an email address. The telephone number may be utilized for mobile telephone or PDA phone functionalities .

At least an embodiment of the invention has the advantage that a transaction can take place between a payer and the payee without the need for the payer to know the payee's account details. Rather, the payer only needs to know an identifier which could, for example, be a telephone number or email address. This also has the advantage of retaining security of the account details.

In an embodiment the method further comprises the step of providing a confirmation of the payment transaction via a payee device.

In an embodiment, the step of providing confirmation comprises the step of sending a confirmation prompt to a communication device of the payee, the prompt being arranged to direct the payee to retrieve a confirmation of the payment transaction. This embodiment may provide a real time confirmation of the transaction to the payee. This confirmation may be particularly useful in situations where a payee requires proof of payment for the provision of goods or services .

In some circumstances payee account details may not be retrievable, because they have not been associated with the payee identifier, for example.

In one embodiment, for example, the payee identifier is associated with the payee account details by being accessible from a database. If the payee has not registered their payee account details in the database, then the payee account details will not be retrievable.

In an embodiment, the method further comprises a step of, when payee account details are not associated with the payee identifier, sending a message to the payee requesting payee account details. By sending the payee a request for the payee account details, this embodiment can continue to function even when a payee is not yet registered. This is of particular advantage as during the operation of the embodiment, new payees not yet registered can continue to receive monetary transfers by contracting the payee with a message prompting the payee to supply their account details as well as push any additional products or services to the payee. In an embodiment, the message prompts the payee to register their account details for future payment transactions.

In accordance with a second aspect, the present invention provides a method for registering a payee to enable a payment transaction in accordance with the method of the first aspect of the invention, comprising the steps of receiving from the payee account details, and a payee identifier, and associating the payee account details with the payee identifier.

In an embodiment, the method further comprises the step of sending a verification to the payee requesting confirmation of the payee's identity. In one embodiment, the verification is sent to a communication device of the payee .

In accordance with a third aspect, the present invention provides a system for facilitating a payment transaction, comprising an interface for receiving from a payer a payee identifier, and a processor for retrieving payee account details associated with the payee identifier, the account details identifying a payee account , and making a payment to the payee account .

In accordance with a fourth aspect, the present invention provides a registration system for enabling registration of a payee with a system in accordance with the third aspect of the invention, comprising a registration interface arranged to receive from the payee account details and a payee identifier, and a processor arranged to associate the payee account details with the payee identifier.

In accordance with a fifth aspect, the present invention provides a computer program comprising instructions for controlling a computer to implement a method in accordance with the first or second aspect of the invention.

In accordance with a sixth aspect , the present invention provides a computer readable medium providing a computer program in accordance with the fifth aspect of the invention.

Brief Description of the Drawings

Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 is a block diagram of a system in accordance with one embodiment of the present invention;

Figure 2 is a diagram illustrating operation of the system of Figure 1 ; Figure 3 is a diagram illustrating operation of the system in accordance with the embodiment of Figure 1;

Figure 4 is a block diagram illustrating operation of the system of Figure;

Figure 5 is a flowchart illustrating operation of the system of Figure 1;

Figures 6A to Figures 6E illustrate example screenshots as presented to a payer during a registration process with the system of Figure 1 ;

Figures 7A to 7C illustrate examples of screenshots as presented to a payer during a payment process using the system of Figure 1;

Figures 8A to 8D illustrate examples of screenshots presented to a payer during operation of the systems of Figure 1; and, Figures 9A to 9C illustrate examples of further screenshots presented to a payer during operation of the system of Figure 1.

Detailed Description of the Preferred Embodiment Referring to Figure 1, an embodiment of the present invention is illustrated. This embodiment is arranged to provide a system for facilitating a payment transaction, comprising an interface for receiving from a payer 204 a

payee identifier 124 and a processor for retrieving account details 126 associated with the payee identifier 124, the account details 126 identifying a payee account, and making a payment to the payee account. In this example embodiment, the interface and processor are implemented by a computer having an appropriate user interface . The computer may be implemented by any computing architecture, including stand-alone PC, client/server architecture, "dumb" terminal/mainframe architecture, or any other appropriate architecture. The computing device is appropriately programmed to implement the invention.

In this embodiment, payment transfers are carried between banks . Bank systems may access a separately administered database containing payee account details and payee identifiers, in order to obtain the payee account details .

In an alternative embodiment, the database may not be separately administered and may be administered by one or more of the banks .

Referring to Figure 1 there is a shown a schematic diagram of a central transfer system which in this embodiment comprises a server 100. The server 100 comprises suitable components necessary to receive, store and execute appropriate computer instructions. The components may include a processing unit 102, read-only memory (ROM) 104, random access memory (RAM) 106, and input/output devices such as disk drives 108, input devices 110 such as an Ethernet port, a USB port, etc. Display 112 such as a liquid crystal display, a light

emitting display or any other suitable display and communications links 114. The server 100 includes instructions that may be included in ROM 104, RAM 106 or disk drives 108 and may be executed by the processing unit 102. There may be provided a plurality of communication links 114 which may variously connect to one or more computing devices such as a server, personal computers, terminals, wireless or handheld computing devices. At least one of a plurality of communications link may be connected to an external computing network through a telephone line or other type of communications link.

The service may include storage devices such as a disk drive 108 which may encompass solid state drives, hard disk drives, optical drives or magnetic tape drives. The server 100 may use a single disk drive or multiple disk drives. The server 100 may also have a suitable operating system 116 which resides on the disk drive or in the ROM of the server 100.

The system has a database 120 residing on a disk or other storage device which is arranged to store at least one record 122 providing a link between a payee's bank account details 126 and a payee identifier 124. The database 120 is in communication with an interface 202, which is implemented by computer software residing on the server 100. The interface 202 provides a means by which a payer 204 is able to enter transfer details relating to an intended monetary transfer. In one example the payer 204 will enter an identifier 124 into the interface 202, the identifier 124 is arranged to identify a payee 206 who is due to receive a monetary transfer from the payer 204. The payer 204 then enters into the interface 202 an amount for

transfer from the payer's financial institution to the payee's financial institution 210.

With reference to Figure 2, the interface 202 has a processor arranged to facilitate the monetary transfer to the payee 206. The processor in one example is a computing device having a combination of hardware and software components to execute optical, electronic or computer instructions .

Once the payer completes entering the identifier 124 and the amount of money intending to be transferred, the payer 204 can confirm this payment via the interface 202. The interface 202 will then communicate with the database 120 to extract the account details 126 required in order to facilitate this transfer between the payer' s financial institution 208 and the payee's financial institution 210. In an embodiment the account details 126 comprises a reference number referring to a specific bank account or financial instrument which is associated with the payee 206.

Once the payer commits to the . transaction through the interface 202 the interface triggers the processor to execute a query 220 with the database 120. The database 120 is implemented using a database service such as a relational-database management system (RDBMS) , objected oriented database or a text based database. The database may be implemented in any other appropriate manner. The query 220 is then executed on the database 120 to retrieve each record 122 using the identifier 124. By executing the query 220, the database attempts to retrieve any associated account details 126 using only the identifier

124 which was previously entered by the payer into the interface 202.

To successfully retrieve the record 122, the payee's account details 126 and identifier 124 must have been previously entered into the interface 202. This is done by a registration process where a payer enters their account details 126 and their identifier 124 into the interface 202. The interface 202 then triggers the processor to store the information in a record 122 and writes the record into the database 120. In this embodiment, the registration process is implemented by computer software arranged to be executed by the processor triggered by the interface 202, and thereby provides additional functionality to the interface. In other embodiments, the registration process can be implemented on a separate server with a separate processor and communicate with the database 120.

Once the account details 126 are retrieved from the query 220, the account details 126 are provided back to the interface 202 such that the interface 202 now has the account details 126 and the amount to be transferred. At this point, the interface 202 proceeds to contact the electronic gateway of the payee's bank 210 to allow a monetary transfer request to be sent to the payee's bank 210 for clearance. This process 222 is executed by a direct entry system (BECS) as used in online banking services, although it will be appreciated by that the process 222 could be done by other transfer methods. Once the transfer is complete, a confirmation message 224 can be sent from the payer's financial institution 208, the interface 202 or the database 120 to the payee 206

confirming the complete of the transfer. In certain situations, it is possible for a fraudster to send a fake confirmation message to the payee in order to deceive the payee to believe the message is from the payee's bank. By sending this fake message, a payee can mistakenly trust that the payment transfer was actually made when in fact no payment transfer was initiated. To reduce this risk of fraud, in some examples, the confirmation message is a prompt directing the payee to log onto a trusted entity such as the payee's financial institution 210 to retrieve a confirmation of the transfer.

In some embodiments the identifier 124 is preferably a numerical or alphanumeric code which is commonly remembered by the payer 204 and the payee 206. The code in this embodiment is also arranged to identify at least one communication device. This may be a home phone number, an email address or a mobile phone number. By allowing the use of a phone number or otherwise easily remembered identifier 124 the payee 206 is able to provide the identifier 124 to another party without having to remember complex account details, or being subjected to the risk of providing their private account details to an untrustworthy third party. This is because the identifier 124 can only be linked to the account details 126 through the database 120. The database can secure the account details 126 from being known by the payer 204. This feature therefore allows the identifier 124 to be easily known by a payer 204 or advertised to external parties without exposing the private account details.

In this embodiment, the database 120 is only accessible through the interface 202 as this ensures

security of the information within the database 120. In some examples of this embodiment, the database 120 is separately housed and located on a separate server from the interface 202 and is connected to the interface 202 via a secure communications link such that the information transferred between the interface 202 and the database 120 is properly protected against security risks. In other examples of this embodiment, both the interface 202 and the database 120 is integrated on the same server and operates as separate processes on the same computer system similar to the system as illustrated in Figure 1.

With reference to Figure 3 , an embodiment of the present system facilitating a transaction to an unregistered payee 206 is shown. In operation, the payer 204 initiates a transfer with the interface 202, the interface 202 allowing for the payer 204 to provide a payee's identifier 124. Having received the identifier 124, the interface 202 queries the database 120. Once the interface 202 is connected to the database, the interface will query the database 120 with the identifier 124. However in this example, as the payee 206 is not yet registered on the database 120, the query 220 cannot retrieve any associated account details 126 since no records exist for the payee 206.

As the interface 202 is unable to complete the transaction without the payee's account details 126, the interface will initiate contact with the payee 206 using the identifier 124. Where the identifier is a telephone number, the interface 202 will contact a telecommunications provider to send a message 306 such as an SMS to the payee 206. The message 306 will inform the

payee 206 of an attempted by the payer 204 to make a monetary transfer to them. The message may indicate to the payee 206 the method for registering their details in the database 120 to allow the transfer to proceed.

In this embodiment, the interface 202 will also inform the payer 204 that the payee 206 as referred to by the identifier 124 is not yet registered on the system and thereby, the transaction cannot proceed. The payer 204 is then given an option by the interface 202 to cancel the transfer request or to make the transfer request pending for a specific period of time to allow a window period for the payee 206 to register their account details 126 into the database 120.

Once the payee 206 receives this message 306, the payee 206 can undertake a registration process 308. This registration process 308 enables the payee 206 to enter in any required details, including the account details 126. The registration process 308 can connect with the database 120 using a secure communication link and write the details entered by the payee 206 into the database.

In alternative embodiments, the registration process 308 is integrated with the interface 202 and thereby utilizing the communications between the interface 202 and the database 120 to write details entered by the payee 206 into the database 120.

These alternative embodiments have an advantage that a payee 206 of a different financial institution 210 will be contacted by the first payer's financial institution 208. This is of significant commercial benefit for

marketing purposes since the communication 306 by the payer's bank 208 allows marketing and branding materials to be directed to a customer 206 of a different bank 210, yet, the communication is one of information relating to the receiving of monies, and thereby unlikely to cause any inconvenience to the payee 206.

With reference to Figure 4 an embodiment of the system as utilized within a merchant setting is shown. In this embodiment a payer 204 may be browsing a specific merchant 404 and intends purchasing goods or services from this merchant 404. Once the payer enters the checkout of the merchant, the payer 204 is provided with a payee identifier 124, which may be merely the contact phone number of the merchant, an email address of the merchant or some other common reference that can identify the merchant, such as a trade mark, business name or street address. The payer 204 can then submit these details to the interface 202. The interface 202 then triggers the processor to query the database 120 to retrieve the merchant's account details 126. The account details 126 are then sent to the interface 202 such that a transfer can immediately be processed between the payer's financial institution and the merchant 404. Where the merchant is connected to a specific bank or financial institution, the transfer will be conducted between the payer's bank 208 and the merchant's bank or financial institution 410. In an embodiment the merchant 404 may provide one of a plurality of available identifiers 124, which are specific to each individual line of services or group of products which the merchant may be offering. This allows an additional advantage for the merchant 404 in that the transfer may be easily tracked to specific lines of

products or services when the merchant's own accounting process begins.

With reference to Figures 5, 6, 7, 8 and 9 operation of a system in accordance with an embodiment is illustrated, by way of screen shots of the interface 202 are shown. At first instance, as shown in Figure 6A, a payer 204 interested in utilizing this payment transaction service firstly registers their details with the database 120 by submitting an identifier 124, which in this example, is a mobile phone number. The identifier 124 is entered into an entry field 602 along with associated account details 126 as shown at 604. The payer 204 can also enter in a public name 606 for messaging purposes. The public name is intended for easy identification only and cannot be used to retrieve the account details 126. Once the payer enters this information into the interface 202, the payer can select the register button 608, which triggers the interface 202 to store the information into database 120.

In an embodiment as shown in Figures 6B and 6C, a message is sent to the payer to confirm their registration. In this example, the payer is presented with a registration screen as shown in Figure 6B, and will receive a SMS to their mobile phone as shown in Figures 6C. To complete the registration process, the payer must reply to this SMS with a verification code 610. This code, once received by the interface 202, is then processed and used to verify that the payer has given consent to the registration of their details onto the database 120. A further confirmation messaged as shown in Figure 6D is then sent to the payer's mobile phone.

This verification process is of particular advantage in that the chances of a fraudulent registration can be minimized by at least further requiring possession of the payer's mobile telephone before any such registration can take place.

With reference to Figure 5, once a payer initiates the payment process, the interface 202 checks to see if the payer is registered on the database 120 (504) . If it is deemed the payer is not yet registered, the payer is firstly directed to register their information (526) in accordance with the registration process above. Once the payer is registered, the payer is prompted by the interface to enter in the identifier 124 of the payee 206 along with additional information required to initiate the transaction, including the total amount of monies to be transferred to the payee 206 (506) .

An example of a screen shot as presented to a payer is shown in Figure 7A where the payer 204 is able to enter the payee's details. In this example, the payer can enter in a payee's identifier through an input box 702. The payer 204 is also able to select which of the payer's account the money is to be transferred from 704. Once this has been entered, the payer can enter the amount to be transferred 708 along with a reference phrase 706, which will assist the payee 206 to identify the reason for the transfer.

Once the payer 204 selects the continue button 710, the interface 202 triggers the screen as shown in Figure 7B which allows a confirmation screen to be shown to the

payer 204 so that in the event that there was any error in the process, the error can be rectified. In this example, the payer can select a tick box 712 for the interface 202 to send an additional confirmation to the payee 206 once the transfer takes place. This is particular useful in situations where a payee 206 or merchant 404 is awaiting for a transfer confirmation before they can proceed with any agreed service or delivery of any agreed goods.

In this embodiment, the interface 202 is arranged to have a confirmation process as shown in Figure 7C. The process allows the payee to review their transfers on the system. This confirmation process is of particular advantage to a payee who needs to check their transfer records for personal or organizational accounting purposes .

With reference to Figure 5, once the payer has entered in the identifier 124, the interface 202 then retrieves the account details 126 (508) by querying the database 120 (510) . If the account details 126 cannot be retrieved, the interface will then contact the payee (512) to notify them of an attempted transaction. In one example as illustrated by Figure 8B, the payee 206 will receive a message 306 or SMS on their mobile phone to inform them of this attempted transaction, and a link is provided to allow the payee 206 to register their details with the database 120 in order for the transfer to be processed 806. Figures 8C and 8D shows an example of the interface 202 arranged to allow a payee 206 to register their details with the database 120. In further examples of security as shown in Figure 8E, a payer is required to submit a password into a security field 812 which must be

subsequently entered by the payer before any changes can be made to the details in the database 120.In this embodiment, the interface 202 will delay the transaction (514) to provide an opportunity for the payee 206 to register their details with the database 120. This delay period will put the transfer into a pending state. The interface 202 will also inform the payer 204 of the failure in the transfer, an example of a screen shot of this action is shown in Figures 8A. In an embodiment, the payer 204 can also specify how long the payee 206 has to register their details (516) before the transaction is deemed to have completely failed (518) . In situations where the payee 206 proceeds to register their details with the database before the time period lapses, the interface 202 will continue the pending transfer request between the payer's bank 208 and the payee's bank 210.

Once the interface 202 has the payee's account details 126, the interface 202 is able to identify the relevant account and financial institution to which the funds are to be transferred. In an embodiment, this is done by an electronic clearing house which is integrated with the payee's financial institution (520) . Once the payer's financial institution has debited the funds from the payer's account and an interbank settlement procedure is initiated, the transfer is deemed to be complete (522) and a confirmation is then sent to both the payer 204 and the payee 206 (514) .

With reference to Figure 9A, a screenshot of the system in use with a merchant website is illustrated. In this embodiment once a payer completes shopping on a merchant website and proceeds towards the checkout point

of the website, the payer can select payment using the system, which in this example is referred to as the "mobile pay service" 902. In this instance the payer 204 is supplied with the identifier 904 which includes the mobile number of the merchant and a reference number to indicate the specific transaction in which the payer 204 is transferring funds for.

As it is shown in Figures 9B, the payer 204 is connected to one embodiment of the interface 202 which has already received the transfer details 908 from the merchant 404. The payer 204 can then review additional details provided by the merchant to the interface 202 in the description box 910 to assist the payer 204 in accounting for the transaction. In this example, the payer can select the "Proceed" button 912 which will allow the interface 202 to proceed to a screen as shown in Figure 9C. The screen is arranged for the payer to enter in any additional reference or amount details relating to the transfer. In some examples, the fields would be automatically filled in by the interface 202 so as to simplify the process, but can be changed by the payer if the payer so desires . Once the payer selects the "Continue" button 914, the details are then submitted to the interface 202 to proceed with the transfer of monetary assets between the payer 204 and the merchant 404. In instances where the merchant operates with a financial institution 410, the interface 202 will transfer the monies to the financial institution 410. A subsequent confirmation message may be sent to both the payer 204 and the merchant 404 to confirm the transaction has been completed successfully.

In this embodiment, the interface 202, processor and the registration process 308 are implemented on a computing device residing on or integrated with the systems of a bank or financial institution. In alternative embodiments, any one or combination of the interface 202, processor or the registration process can be implemented on independent computing devices separated from any individual bank or financial institution. The selection of which embodiments are best implemented will depend on the commercial arrangement and/or available computing apparatus at the time of implementation by a person skilled in the art .

Although not required, the embodiments described with reference to the Figures can be implemented to file an application programming interface (API) or as a series of libraries for use by a developer or can be included within another software application, such as a terminal or personal computer operating system or a portable computing device operating system. Generally, as program modules include routines, programs, objects, components and data files the skilled person assisting in the performance of particular functions, will understand that the functionality of the software application may be distributed across a number of routines, objects or components to achieve the same functionality.

It will also be appreciated that the methods and systems of the present invention are implemented by computing system or partly implemented by computing systems than any appropriate computing system architecture may be utilised. This will include stand alone computers, network computers and dedicated computing devices. Where

the terms "computing system" and "computing device" are used, these terms are intended to cover any appropriate arrangement of computer hardware for implementing the function described.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.