Note: Descriptions are shown in the official language in which they were submitted.
CA 02326085 2000-11-14
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
14767-3US - 1 -
CA 02326085 2000-11-14
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.
Summarlr of the Invention
The present invention overcomes the disadvantages discussed above and
provides 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. Preferably, the
payment
requester uses information provided by the payer, preferably by means of a
secure
Internet interface in communication with an aggregator interface, 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. Preferably, 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.
The present invention also provides a method for obtaining payment
authorization and completing a financial transaction between a payer and a
payee
comprising the steps of: receiving a message including identification of the
payer, the
14767-3US - 2 -
CA 02326085 2000-11-14
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. Preferably,
information
provided by the payer, preferably by means of a secure Internet interface, 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. Preferably, the method
includes 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.
The present invention also provides 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;
providing, in
association with the payment manager, a bill payment request communications
module
for each of the financial institution servers; and establishing a
communications
mechanism between the payment manager and a financial institution of a payee.
Preferably, 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. Preferably, the method includes 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.
14767-3US - 3 -
CA 02326085 2000-11-14
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:
Figure 1 shows a schematic representation of an embodiment of the secure
payment system of the present invention;
Figure 2A shows a flow chart illustrating secure payment steps in accordance
with an embodiment of the present invention;
Figure 2B shows a continuation of the flow chart of Figure 2A;
Figure 3 shows a flow chart illustrating funds transfer steps in accordance
with an
embodiment of the present invention;
Figure 4 shows a schematic representation of another embodiment of the secure
payment system of the present invention.
Detailed Description of Preferred Embodiments
Referring to Figure 1, there is shown a schematic representation of a payer
(customer 10) in communication with the Internet by link 12 or other device to
communicate with the merchant. 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
14767-3US - 4 -
CA 02326085 2000-11-14
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
BluetoothT"" 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 or personal digital assistant or other like
wireless
device. 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 or a secure 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
14767-3US - 5 -
CA 02326085 2000-11-14
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 assigns the customer an ID
for
the payment manager service. The aggregator module 34 thus logs in to the
customer's account at a financial institution and requests, if permitted, that
one of the
bill payment payees registered for the customer be the payment manager 30.
This can
involve entering the customer ID 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.
It should be understood from the foregoing that arrangements must be made with
the financial institution that the payment manager is included in its list of
possible
payees for bill payment requests.
14767-3US - 6 -
CA 02326085 2000-11-14
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 necessarily take place at the same time as the request for bill payment
and
confirmation of same. The actual transfer typically takes place some time
later, i.e.
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
14767-3US - 7 -
CA 02326085 2000-11-14
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 confirmation processor may also send confirmation of bill
payment over
a secure link to an account deposit processor 57 which is associated with the
merchant's financial institution 56.
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.
14767-3US - 8 -
CA 02326085 2000-11-14
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.
Where confirmation of bill payment is sent to the account deposit processor
57, it
credits the merchant's account with the amount of the purchase but freezes
that amount
in the account until the funds are transferred.
The transfer is performed through an electronic funds transfer (EFT) system 50
such as Clearinghouse Interbank Payments System (CHIPS) or FedWire. Both of
these
14767-3US - 9 -
CA 02326085 2000-11-14
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.
Figure 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 (e.g. EFT). This link
is used to
make the transfer of the purchase funds from the payment manager 30 to the
merchant's account. The link 58 may also pass through the account deposit
processor
57 which has already credited the merchant's account and frozen that amount.
Upon
receiving the transfer of funds, the account deposit processor 57 unfreezes
the payment
amount. 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.
Figure 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.
14767-3US - 10 -
CA 02326085 2000-11-14
The certification server 20 then initiates a secure wireless 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 a limited number of times 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
merchant a
message to this effect. It can also send a similar message to the wireless
device 14.
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 Figure 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 this information to
the
confirmation processor 37 which relays the message to the merchant server 16.
14767-3US - 11 -
CA 02326085 2000-11-14
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.
In parallel, the confirmation processor 37 may also send confirmation of bill
payment to the account deposit processor 57. The account deposit processor
then
credits the merchant's account and freezes the amount of the credit in that
account.
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.
Figure 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. The funds are preferably transferred to
the account
deposit processor where one is used. The account deposit processor 57 then
unfreezes the funds which had been previously credited to the merchant's
account and
frozen.
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
14767-3US - 12 -
CA 02326085 2000-11-14
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 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. Figure
4 illustrates this modified system. This system is similar to that shown in
Figure 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 used 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.
14767-3US - 13 -
