WO2002039400A2

WO2002039400A2 - Real time electronic payment system using customer electronic bill payment system

Info

Publication number: WO2002039400A2
Application number: PCT/CA2001/001596
Authority: WO
Inventors: Fabio Charbonneau; Marco Fortier
Original assignee: Banque Laurentienne Du Canada
Priority date: 2000-11-13
Filing date: 2001-11-13
Publication date: 2002-05-16
Also published as: WO2002039400A3; AU2002218083A1

Abstract

The present invention is a system and method for permitting authentication and confirmation of payment for real-time electronic purchases by a customer from a merchant and method of putting in place such a system. A customer's client ID, a merchant identification and a purchase amount are communicated to a payment manager which has been previously arranged to have access to the customer's account information by way of the customer access Internet site of the customer's financial institution. On the customer's behalf, the payment manager requests a bill payment to the payment manager. A confirmation of bill payment is received by the payment manager and returned to the merchant. At a later time, the requested transfer of funds takes place, followed by a subsequent transfer to the merchant.

Description

REAL TIME ELECTRONIC PAYMENT SYSTEM USING CUSTOMER ELECTRONIC BILL PAYMENT SYSTEM

Field of the Invention

The invention relates primarily to the processing of financial transactions involving electronic payment in which the funds transfer is initiated by an electronic bill payment process, using for example a customer web interface, for initiating and confirming a bill payment to confirm a real-time payment transaction.

Background of the Invention

In recent years, more and more financial transactions are being completed without the exchange of cash. Such transactions generally require that the purchaser (or customer) provide to the merchant certain financial information and authentication so as to permit the merchant or the merchant's financial institution to confirm that it can obtain payment by whatever means the customer and the merchant have agreed to.

Typically, this has involved the customer temporarily surrendering to the merchant a credit card or a debit card which provides information concerning the account from which payment can be obtained. The merchant uses the account information on the card to obtain verification from the card issuer that payment can be obtained. The card issuer then adjusts the account to reflect the amount of the purchase. The customer's request to make the purchase is authenticated by providing a Personal Identification Number ("PIN") known only by the customer or by signing a document. The authentication of a credit card purchase may also be done by confirming the expiration date of the card in cases where the customer's signature cannot be obtained.

A disadvantage of this system is that a large amount of resources are required to create and maintain a system which permits real-time confirmation to the merchant of the transfer of funds as with a debit card. Also, specific programming of computers involved in such a system and coordination between computers run by different participants in the system is necessary in order for the merchant to receive confirmation that funds will be credited to its account. Even with credit card transactions, substantial programming of computers and coordination between computers of different companies is necessary to permit the real-time confirmation and authorization which is called for.

Summary of the Invention

According to a broad aspect of the present invention, the disadvantages discussed above are overcome by using the bill payment function offered by online banking systems and a payment manager system. The payment manager receives a user request for a payment transaction and uses the user's on-line banking system to request a transfer of funds. The payment manager then obtains an indication that the transfer is underway, in response to which the payment manager proceeds with implementing the necessary communication, e.g. between the user and the payee, for the user's payment transaction to proceed, preferably in real time. According to another broad aspect, the present invention provides a system and method for permitting authentication and confirmation of payment for real-time electronic purchases by a customer from a merchant and method of putting in place such a system. A customer's client ID, a merchant identification and a purchase amount are communicated to a payment manager which has been previously arranged to have access to the customer's account information by way of the customer access Internet site of the customer's financial institution. On the customer's behalf, the payment manager requests a bill payment to the payment manager. A confirmation of bill payment is received by the payment manager and returned to the merchant. At a later time, the requested transfer of funds takes place, followed by a subsequent transfer to the merchant.

More particularly, the invention provides a system for obtaining payment authorization and completing a financial transaction between a payer and a payee having the elements defined in claim 1. The invention also provides a method for obtaining payment authorization and completing a financial transaction between a payer and a payee involving the steps defined in claim 11. The invention additionally provides a method of establishing a payment service having the steps defined in claim 21. The present invention also provides a computer program product for implementing the system and methods according to the invention, and further the invention provides a data signal, embodied on a carrier wave, containing such computer program code.

Brief Description of the Drawings

The present invention will be better understood by way of the following non-limiting description of a preferred embodiment with reference to the appended drawing, in which: Fig. 1 shows a schematic representation of an embodiment of the secure payment system of the present invention.

Fig. 2A shows a flow chart illustrating secure payment steps in accordance with an embodiment of the present invention.

Fig. 2B shows a continuation of the flow chart of Fig. 2A; Fig. 3 shows a flow chart illustrating funds transfer steps in accordance with an embodiment of the present invention.

Fig. 4 shows a schematic representation of another embodiment of the secure payment system of the present invention.

Detailed Description of Preferred Embodiments

Referring to Fig. 1 , there is shown a schematic representation of a payer (customer 10) in communication with the Internet by link 12. The customer 10 preferably has a computer at his end of link 12. The customer 10 also has a wireless telephone 14. Link 12 is used by the customer 10 to send a purchase request message to a payee, which is a merchant which preferably has a merchant server 16. This message includes the identity of the customer 10. Link 12 is also used to receive a purchase confirmation message from the merchant server 16 indicating that the purchase request has been accepted and that the purchase has been completed. The merchant server 16 is in communication with the Internet by means of link 18. Rather than using links 12 and 18 to communicate between the customer 10 and the merchant 16, another suitable communication path could be used, such as a voice path to a voice server or operator, or even a local data communication path such as Bluetooth™ at a point of sale.

Link 18 is also used for sending a payment confirmation request message to a certification server 20. This message contains an identification of the merchant and the customer 10 as well as the amount of the purchase. The certification server 20 is in communication with the Internet via link 22. Normally, an authentication verification message will be returned from the certification server 20 to the merchant server 16 over the same links 18 and 22.

The certification server 20 contains information concerning the customer 10 including an authentication code and details of at least one account from which payment for a purchase can be made. The certification server 20 is in communication with a cellular telephone network 24 via dedicated connection 26. This network is linked to base station 28 which permits secure digital wireless communication with the customer's wireless telephone 14. The wireless communication path is used by the certification server 20 to send a message to the customer 10 advising of the identity of the merchant and the amount of the purchase and requesting acceptance and authentication by the customer 10. The customer 10 uses the same wireless communication path to send the acceptance and authentication message. The customer 10 enters his or her PIN and may also select from which account payment for the purchase should be taken. The selected account may be selected from a number of accounts at different financial institutions. Finally, this communication path can also be used to advise the customer 10 of confirmation of authentication and/or conclusion of the payment to the payee. The certification server 20 is also in communication with a payment manager 30 via a dedicated connection 32. The certification server 20 sends a message over dedicated connection 32 identifying the customer 10, the merchant 16 and the amount of the purchase. The certification server 20 may also identify which of a plurality of the customer's accounts should be used to obtain payment. Alternatively, there may be a default account from which payment is to be made. The payment manager 30 comprises a number of modules for performing its various functions. It contains a message processor 31 for receiving the message from the certification server 20. The payment manager 30 also contains a customer database 29 containing all of the information necessary to gain access the Internet sites of all of the financial institutions in which its customers have accounts. This information includes user identification, passwords and account numbers and is needed to request a bill payment. This information is preferably inputted to a payment requester 33 within the payment manager 30 in advance of the financial transaction directly by the customer 10 by means of an aggregator interface 34. The customer communicates with the aggregator interface 34 through a link 36 to the Internet using https communication. The aggregator interface 34 is used to update a customer's data in database 29 which is in communication with the payment requester 33 via a dedicated connection 38 over which the user identification, password and account information entered by the customer 10 is passed. For new customers, the aggregator interface 34 includes a function to automatically set up on the customer's Internet banking service a payee account for the payment manager 30. The aggregator module 34 thus logs in to the customer's account and requests, if permitted, that one of the bill payment payees registered for the customer be the payment manager 30. The can involve entering a lengthy transit and account number for the payment manager, and is thus convenient to automate. Since the manner in which a new payee account is established can be very different between institutions, the appropriate one of the customized modules 42 is used to execute the implementation of this new bill payment payee account set up.

The term "bill payment" is used herein to refer to a transfer of funds from an account of a payer to a predetermined account of a payee as a result of the payer's request to his or her financial institution. This includes a bill payment, as that term is currently understood in the context of financial transactions requested using financial institution servers. The term "bill payment" also implies that, while the amount paid is immediately deducted or frozen in the payer's account, the actual transfer of funds does not take place at the same time as the request for bill payment and confirmation of same. The actual transfer will take place some time later, typically overnight or the following day. The bill payment request and confirmation interaction is between the payer and his or her institution without a direct communication or commitment being expressed to the payee. The payment manager 30 also comprises a server selector 35 which is in communication with a series of modules 42. Each module 42 is specially programmed and contains specific information necessary to find and navigate within the customer access Internet site of a specific financial institution. The server selector chooses the module which is appropriate to reach the financial institution in which the customer's account is located. Generally, there is no agreement between the payment manager and the financial institution regarding access to the bill payment feature of a customer's account. So, the payment manager 30 must use the financial institution's customer access Internet site and perform the necessary operations as if it were the customer.

The module 42 is programmed with the information necessary to access the Internet site of a particular financial institution and obtain a page which presents the bill payment function. The module 42 is also programmed to simulate the keystrokes necessary to request a bill payment from the customer's account to the payment manager's account in the amount of the purchase. In addition, the module 42 must be programmed to recognize the confirmation of the bill payment. Normally, this is done by a process known as "screen scraping" whereby the module is programmed to check a certain location on a page to determine whether confirmation of bill payment has been received. The module then reads and recognizes the confirmation number. If an agreement were put in place between the payment manager and the financial institution concerning direct access to the customer's account information, it would no longer be necessary to request bill payment by imitating a customer at his computer using the Internet banking interface. This operation could instead be performed directly through a means set up between the payment manager and the financial institution.

There are as many modules 42 as there are financial institutions with which the payment manager 30 must communicate. This is because the manner of accessing the bill payment page and recognizing a bill payment confirmation message will likely be different for each financial institution's Internet banking site. Each of the modules 42 is in communication with the Internet through a link 44. Also in communication with the Internet, through secure Internet access links 46, are the servers 48 of all of the financial institutions from which a customer 10 may request that bill payment be made. The financial institution servers 48 and their links to the Internet are already in place and need not be created to put the present invention into use.

If appropriate, a confirmation processor 37 receives a confirmation of bill payment and uses Internet links 49 and 18 to confirm to the merchant server 16 via the Internet that the bill payment request has been accepted and that the purchase may be completed.

The payment requester 33, armed with information received from the message processor 31 concerning the customer account, the merchant and the amount of the purchase, as well as the necessary user identification and password information, communicates over one of the links 40 to the one of the modules 42 which relates to the financial institution which administers the selected customer account. This module 42 is in communication through the Internet and a secure Internet access 46, with a series of financial institution servers 48 corresponding to the financial institutions in which customers may request that bill payment be made.

Once communication between the payment requester 33 and the appropriate financial institution server 48 has been established, the payment requester 33 generates a request for bill payment to the payment manager 30 from the selected customer account. To accomplish this, the financial institution server 48 must have information necessary to permit this request to be processed. That is to say, the payment manager 30 must be registered with the financial institution server 48 as one of the companies to whom bill payments may be made. The financial institution server 48 generates a confirmation number or a message that must be collected by the payment requester 33 confirming that the bill payment request has been accepted or rejected. This message is then passed on to the confirmation processor 37.

This confirmation message is generated by the financial institution for the customer to confirm that the funds have been withdrawn from the customer's account and will be credited to the payment manager's account at a later time, usually within twenty-four hours, when such bill payments are normally transferred between financial institutions. It is important to note that the financial institution's obligation to make the bill payment and its associated communication is to the customer and not to the payment manager or to the merchant. Should the customer, after the bill payment confirmation but before the actual transfer of funds, request that the bill payment be cancelled, the financial institution is not obliged to transfer the funds. Such a cancellation can be considered a violation by the payer. The payment manager and/or the merchant can assume the minor risk that the customer will cancel the bill payment after the financial transaction has been completed. Because the payment manager has a continuing relationship with the customer, the payment manager will preferably guarantee payment to the merchant. The transfer is performed through an electronic funds transfer (EFT) system 50 such as Clearinghouse Interbank Payments System (CHIPS) or FedWire. Both of these systems have been in place for performing electronic funds transfers for some time. The EFT system 50 need not be created to put the present invention into use. Fig. 1 shows the EFT in communication with the financial institution server 48 and the payment manager 30 through links 52 and 54, respectively. This representation greatly over simplifies the funds transfer process which is well known. However, it serves to indicate that funds are transferred from the customer's financial institution to a funds transferor 39 within the payment manager 30. The funds transferor 39 preferably contains a database of merchants and details of their financial institution accounts. The funds transferor 39 is also in communication with the merchant's financial institution 56 via link 58. This link is used to make the transfer of the purchase funds from the payment manager 30 to the merchant's account. In certain cases, the payment manager 30 and the merchant's financial institution 58 may be one and the same. In such cases, the link 58 may not be a long distance link; the transfer of funds to the merchant can be accomplished with an internal accounting adjustment.

Fig. 2A shows the first portion of a flow chart setting out the sequence of steps involved in completing a purchase in accordance with the present invention. As a first step, the customer 10 sends the merchant 16 an indication that the customer wishes to make a purchase. The customer 10 also sends an indication that payment for the purchase will be made in accordance with the system of the present invention. In addition, the customer 10 gives the merchant 16 a client ID sufficient to identify him with the certification server 20.

In the next step, the merchant server 16 sends to the certification server 20 the customer's client ID, its own identification and the amount of the proposed purchase and requests confirmation that the purchase amount will be paid.

The certification server 20 then initiates a secure wireless telephone connection with the customer 10 and sends a message indicating the identity of the merchant and the amount of the proposed purchase. It also requests the Personal Identification Number ("PIN") of the customer and, possibly, an indication of the account to be used for payment of the purchase. The customer 10 then returns over the same secure wireless telephone connection the PIN and, possibly, the selection of the account.

The certification server 20 verifies the PIN against the customer's client ID. If the PIN is incorrect, the certification server 20 returns to the customer 10 a message indicating that the PIN provided is incorrect and again requests the correct PIN. This step may be repeated until the correct PIN is received.

If the PIN entered by the customer 10 is correct, the certification server 20 has confirmation of the authenticity of the purchase request. It sends the customer 10 a message to this effect. The certification server 20 then sends to the payment manager 30 a request for bill payment in the amount of the purchase from the customer's selected account to the payment manager.

The message processor 31 within the payment manager 30 receives the request and relays it to the payment requestor 33. The payment requestor 33, via the modules 42, then enters into communication with the financial institution server 48 which contains the customer's selected account using the user identification, account and password information available to it as well as the detailed programming in the module 42 which corresponds to that financial institution server. The payment requester 33 then requests bill payment to the payment manager 30. Turning now to Fig. 2B, if the financial institution server 48 cannot confirm the bill payment, it indicates so. The payment manager 30 then sends a message to this effect to the merchant server 16. This is done by the payment requester 33 recognizing the financial institution server's response and relaying th is information to the confirmation processor 37 which relays the message to the merchant server 16.

If the financial institution server 48 can confirm bill payment, it provides a confirmation number. This number is recognized by the payment requester 33 as confirmation of bill payment. The financial institution server also withdraws the amount of the purchase from the customer's selected account. The confirmation processor 37 then sends to the merchant server 16 a confirmation of bill payment.

As a final step, the merchant 16 sends the customer 10 a confirmation that the payment has been accepted and that the transaction is complete.

All of the steps to this point are done in real time in a matter of seconds. At the completion of the purchase, the certification server 20 has requested a transfer of funds and confirmed to the merchant 16 that payment will be made. However, no funds have been transferred to complete the payment. The actual transfer of funds need not be done in real time and can be done over the next twenty-four hours.

Fig. 3 shows the steps involved in making the actual transfer of funds. The first step in the payment procedure is for the customer's financial institution to transfer the funds from the customer's selected account to the payment manager 30 (funds transferor 39) via an EFT system 50. The customer's financial institution then sends to the funds transferor 39 a message indicating that the funds have been transferred. Finally, the funds transferor 39 transfers the funds to the merchant's account at the merchant's financial institution 58.

While the foregoing paragraphs describe a preferred embodiment of the present invention, variation of certain elements is possible without departing from the spirit of the invention. For example, a change could be made to the first few steps of the authentication process, whereby the customer 10 advises the merchant 12 of his client ID certification server account number and the merchant 12 seeks a confirmation from the certification server 14 with reference to this client ID. Rather than having the customer transmit a client ID which identifies the customer, the system can be made to work so that the customer initially contacts the certification server and requests a transaction number. This transaction number given to the customer is transmitted from the customer to the

Claims

merchant instead of the client ID. The merchant then relays the transaction number to the certification server for confirmation of payment. In this way, the merchant does not receive information concerning the identity of the customer. Another possible variation involves a payment made from one individual to another, in which neither is a merchant. In this case, both the payer and the payee are preferably in communication with the certification server via wireless telephone. Fig. 4 illustrates this modified system. This system is similar to that shown in Fig. 1 except that the links 12 and 18 are missing, the customer 10 is replaced by a payer 100 and the merchant server 16 is replaced by a payee 102 with a wireless telephone 104. The payee 102 sends the payment confirmation request message to the certification server 20 via wireless telephone connection. The remaining steps are similar to those described above in respect of a financial transaction between a customer and a merchant except that .the confirmation of bill payment is sent from the payment manager 30 to the certification server 20 via dedicated connection 32 and then from the certification server 20 to the payee 102 via the wireless telephone connection.While the use of secure wireless telephone devices is a good example jsed in this specification of how payer authentication can be implemented, it will be appreciated that authentication by Internet data communication or voice communication are other practical alternatives. What is claimed is:

1. A system for obtaining payment authorization and completing a financial transaction between a payer and a payee comprising: a payment manager having a message processor for receiving a message including identification of the payer, the payee and an amount of funds; the payment manager further including a server selector for selecting one of a plurality of financial institution servers based on the message; the payment manager further including a payment requester for requesting bill payment of the amount of funds from an account of the payer held in the financial institution which is served by the selected one of the plurality of financial institution servers to an account of the payment manager; the payment manager further including a confirmation processor for receiving confirmation of bill payment and for sending confirmation of bill payment to the payee; and the payment manager further including a funds transferor for transferring the amount of funds to an account of the payee.

2. The system as claimed in claim 1 , wherein the payment requester uses information provided by the payer to permit the payment requester to communicate with the selected one of the plurality of financial institution server and to request bill payment on behalf of the payer.

3. The system as claimed in claim 2, wherein the payer provides the information by means of a secure Internet interface in communication with an aggregator interface.

4. The system as claimed in claim 3, wherein the aggregator interface communicates with the selected one of the plurality of financial institution servers to establish the payment manager as a party to whom bill payment can be requested from the payer.

5. The system as claimed in claim 1 , wherein the payment manager guarantees the payment to the payee's account.

6. The system as claimed in claim 1 , wherein the message includes a selection of a payer's account.

7. The system as claimed in claim 1 , wherein all of the operations are performed in real time except that of the funds transferor.

8. The system as claimed in claim 1 , wherein a certification processor authenticates the payer's wish to enter into the financial transaction.

9. The system as claimed in claim 8, wherein an authentication message is communicated from the payer to the certification processor using a secure communications means.

10. The system as claimed in claim 9, wherein the secure communications means is a secure digital wireless telephone connection.

11. A method for obtaining payment authorization and completing a financial transaction between a payer and a payee comprising: receiving a message including identification of the payer, the payee and an amount of funds; selecting one of a plurality of financial institution servers based on the message; requesting bill payment of the amount of funds from an account of the payer held in the financial institution which is served by the selected one of the plurality of financial institution servers to an account of a payment manager; receiving confirmation of bill payment; sending confirmation of bill payment to the payee; and transferring the amount of funds to an account of the payee.

12. The method of claim 11 , wherein information provided by the payer is used to permit communication with the selected one of the plurality of financial institution server and to request bill payment on behalf of the payer.

13. The method of claim 12, wherein the payer provides the information to permit by means of a secure Internet interface.

14. The method of either of claims 12 or 13, including the additional step of communicating with the selected one of the plurality of financial institution servers to establish the payment manager as a party to whom bill payment may be requested from the payer.

15. The method of claim 11 , wherein the payment manager guarantees the payment to the payee's account.

16. The method of claim 11 , wherein the message includes a selection of a payer's account.

17. The method of claim 11 , wherein all of the steps are performed in real time except transferring the amount of funds.

18. The method of claim 11 , including the additional step of authenticating the payer's wish to enter into the financial transaction.

19. The method of claim 18, wherein the step of authenticating is performed using a secure communications means.

20. The method of claim 19, wherein the secure communications means is a secure digital wireless telephone connection.

21. A method of establishing a payment service comprising the steps of establishing a communications mechanism between a payment manager and a plurality of financial institution servers having bill payment capabilities; receiving information to permit access to at least one account of a payer at a financial institution; for each of the financial institution servers, determining measures necessary to permit automated access to a payer's account to request bill payment of an amount of funds from the payer's account to an account of the payment manager and to receive confirmation of bill payment; providing a bill payment request communications module for each of the financial institution servers using the determined measures necessary to permit access to a payer's account; and establishing a communications mechanism between the payment manager and a financial institution of a payee.

22. The method of claim 21 , wherein the information to permit access to at least one account of a payer is provided by means of a secure Internet interface in communication with the payment manager.

23. The method of claim 22, including the additional step of communicating with at least one of the plurality of financial institution servers to establish the payment manager as a party to whom bill payment can be requested from the payer.

24. The method of claim 21 , including the additional step of creating a database of payees.