IES20011056A2 - A Method of Making Electronic Payments - Google Patents

A Method of Making Electronic Payments

Info

Publication number
IES20011056A2
IES20011056A2 IES20011056A IES20011056A2 IE S20011056 A2 IES20011056 A2 IE S20011056A2 IE S20011056 A IES20011056 A IE S20011056A IE S20011056 A2 IES20011056 A2 IE S20011056A2
Authority
IE
Ireland
Prior art keywords
merchant
consumer
account
site
payment
Prior art date
Application number
Inventor
Richard Pike
Original Assignee
Ci Consultancy Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ci Consultancy Ltd filed Critical Ci Consultancy Ltd
Priority to IES20011056 priority Critical patent/IES20011056A2/en
Publication of IES20011056A2 publication Critical patent/IES20011056A2/en

Links

Abstract

The method of the invention comprises a series of steps for making secure and risk-free electronic payments. Initially a consumer connects to a merchant's internet site (70), from where the consumer chooses to purchase one or more items. The consumer then enters the merchants order page (10) on the internet site. The consumer is able to choose a payment method from the merchant's internet site that is connected to an online site of a bank with whom the consumer has one or more accounts. Once the consumer connects to the banks on-line site, the consumer selects an appropriate account (50) and instructs the bank to transfer the appropriate amount of money from the account to the merchant's account. The consumer then returns to the merchants internet site (70). The order is completed once the merchant receives confirmation (60) of the money transfer from the bank. <Figure 1>

Description

A METHOD OF MAKING ELECTRONIC PAYMENTS The present invention relates to a method of making electronic payments (E-payments) and in particular to a method of making secure and risk-free electronic payments.
Retail electronic commerce is conducted daily. Despite this, a large number of Internet retail sites are unable to conduct business to their full potential. This is due to concerns that have arisen amongst financial institutions, credit card companies, goods providers, service providers and potential customers with regard to fraud. Generally all that is required when purchasing an item over the internet from a retail site is a name, address, credit card number and expiry date, thus safety checks such as signature and/or photo ID become defunct. This information is entered and stored in the merchants’ database. Concerns arise with regard to the misuse of the information by parties enabling a third person to charge fraudulently goods to a card holders credit card. Currently, efforts to prevent credit card fraud are dependent on either a theft being reported, or use of elaborate verification systems whereby altered patterns of use promote an inquiry by the credit card company. Thus, it may take some time to detect fraudulent use of a credit card and ultimately the consumer will have to pay.
Furthermore a number of small to medium sized enterprises (SME’s) are failing to attain Internet payment services from their banks due to stringent internal bank checking procedures. This could be due to lack of track record or low value of turnover. Alternatively, the mere fact that a number of enterprises are run at very low margins thus are susceptible when an increase in prices occurs is sufficient for an SME to fail to receive internet payment services.
It is the object of the present invention to seek to alleviate the above described disadvantages by providing an improved method of making internet payments which significantly reduce the occurrence of fraud and also provide security for banks thus enabling the bank to provide an SME with internet payment services. /»... ......—— Irn..
OPEN TO PUBLIC INSPECTION ist a__I—,— Gtir.i- lY/bA UNDER SECTION 28 ANO RULE 23 j JNL No. jXtL·. ΙΕΟ 1 105 β Accordingly the present invention provides a method of making electronic payments comprising the steps of: connecting to a merchant’s internet site; choosing to purchase one or more items from the merchant’s internet site; entering a merchant’s order page on the merchant’s internet site; choosing a payment method from the merchant’s internet site that is connected to an online site of a bank with whom the consumer has one or more accounts; . connecting to the online site of the bank; selecting a consumer’s account to make a withdrawal from; transferring money, from the consumer’s account to the credit ofrnerchant’s account; returning to the merchant’s internet site; and completing the order is upon confirmation of the money transfer.
In particular the present invention allows the consumer to securely purchase items on Internet retail sites. The consumer has the additional benefit of not having to possess a credit card as all transactions conducted using the method described above are akin to an internet based debit card. It is preferable for the consumer to interact directly with their bank and not divulge any information to the merchant. Ideally the merchant has no financial risk of non-payment as the money is transferred directly from the consumer’s account to the merchant’s account. Preferably the merchant is then notified that the payment has been made and that they have funds on their account prior to distributing the goods. Ideally the bank is in full control of the funds transfer process and uses standard account management security requirements to mitigate against the risk of fraud.
Advantageously the e-payment method provides dual security as real-time balance checking is 5 performed on the consumer’s account and no transaction will take place if the customer has insufficient funds. Furthermore the merchant does not receive any of the consumer’s bank details, thus is not responsible for the security of these details reducing the risk of fraud.
It is preferable to incorporate a payment reversal method. This is used when an ordered item is either out of stock or is unavailable. For example, the merchant is able to reject or accept a payment transaction. If the merchant accepts the payment transaction, the goods ordered are in stock and are available for shipment however if the merchant chooses to reject the payment transaction the goods are unavailable. When the merchant rejects a payment transaction the money is credited back into the consumer’s account. It is preferable that the bank also controls all reversed payment transactions.
A problem that may occur with this method is the use of “dummy” Internet sites, where “dummy” Internet sites resemble the online banking site. A consumer would then be asked to enter their user ID and security information, enabling a fraudster to gain access to the consumers account details. However in order to transfer money from one account to another the destination account to which the money is transferred needs to be registered. The fraudster needs the consumers actual account number to do this, thus the consumer is required to enter the account number on the “dummy” Internet site. Ideally, in order to prevent fraudulent companies from utilising “dummy” Internet sites, consumers are educated by the bank that at no time are they required to divulge their account numbers on-line.
Ideally the architecture of the system is designed to allow the merchant to easily integrate within the environment used to support the e-Commerce initiatives. Whilst the architecture for the bank preferably incorporates the specifics of the banks web-site but minimises the amount of code required by the bank. Thus it is preferable for the bank to create a merchant ΙΕΟ 1 105 β specific installation disk, enabling the bank to create a unique Merchant ID for the merchant, software for use by the merchant for decrypting messages from the bank and a password for access to transaction information.
Ideally, the disk will contain two modules, the first module being E-payment/Transaction ID generation for the bank, the second module being software (known as a key) for decrypting a message from the bank confirming receipt of payment. It is preferable for these modules to be specific to the web server type of the merchant. Ideally, the merchant installs the disk on their server and maintains the key for decrypting the messages in a secure directory. It is preferable once the disk is installed to send to the bank the URL of the merchant’s website to which the bank subsequently posts any payment confirmations.
The invention will hereinafter be more particularly described with reference to the accompanying drawings, which illustrate by way of example only one embodiment of the payment method in accordance with the invention.
Figure 1 is a flow chart illustrating the overall structure of the payment method; Figure 2 is a flow chart illustrating the operation of the bank web site; and Figure 3 is a flow chart illustrating the operation of the merchant web-site.
Referring initially to figure 1, the overall structure of the payment method is shown. The consumer reviews the merchandise on the merchant’s web server block 70 and decides to purchase one or more items. The consumer then enters the merchant’s order page block 10 and from there highlights the bank logo block 20. Upon clicking the bank logo block 20 using the mouse or arrow and return keys the consumer is connected to the bank web server block 40. During the connection process the merchant’s details i.e. merchant number, transaction number and goods purchase price are automatically sent to the bank’s web server block 40. The details are formatted and transferred using software that is embedded into the ΙΕΟ 1 105 6 merchant’s web server block 70. A second browser window directed to the bank’s web server block 30 opens on the consumer’s monitor. The consumer is directed to log onto the bank’s web server block 30 using the security and password infrastructure dictated and provided by the bank. The bank’s web server block 30 automatically provides the consumer with details of the merchant, payment amount and details of the users account or accounts block 50. The consumer selects the account to be debited and the merchant to be credited and submits this to the bank’s web server block 40.
Subsequently, the consumer decides whether or not the transaction is to be completed. If the 10 consumer chooses to complete the transaction, he or she highlights and clicks the acceptance icon block 60 and enters details of their personal identity number as requested. Once the consumer completes the transaction, the bank’s internal system debits the consumers account and credits the merchants account with the respective amount. If there is a problem with the transaction due to lack of funds or technical issues, the consumer is informed at this point that the bank is unable to complete the transaction and optionally the reason why.
Once the funds are successfully transferred the bank’s web server block 40 sends an encrypted message to the merchant’s web server block 70 detailing the transaction number and confirming that a payment has been made. The merchant’s web server block 70 decrypts the message from the bank using the key. Upon receipt of confirmation that the payment transaction has occurred the merchant’s web server block 70 notifies the consumer’s browser. Any remaining details required such as shipping details are submitted by the consumer to the merchant and the transaction is completed.
Furthermore the merchant’s web server block 70 can store all encrypted messages sent by a bank’s web server block 40. The merchant can also record all details supplied by the consumer. This enables the merchant to create a log of all transactions such that the merchant can trace individual transactions if required or reconcile all internet transactions with their bank statements.
Figure 2 illustrates the operation of the bank website. The banks web server block 40 modifies the on-line banking page to generate a payment confirmation block 42. This page is then linked to the pages to perform login block 41 where the consumer logs into his or her online booking site. The user is then connected to a site which displays details of his/her accounts, the merchants name and the payment amount. The banks web server block 40 obtains the merchants name and account details by referencing the E-payment database block 43. Once the consumer has confirmed the payment transaction the banks web server block 40 connects to the merchants web server block 70 using the Internet Explorer Browser object. An XML document containing the necessary information block 44 and encrypted block 45 and sends the message to the merchants web server block 70. Once this task is completed the bank updates the E-payment database block 43.
The E-payment database block 43 stores details of each merchant utilising the E-payment method. For Example, the details stored may comprise the following: Merchant name; Merchant ID; Merchant Bank Account; Merchant Key; Merchant Payment Confirmation URL; Merchant Password; Date of Payments; Transaction ID; Amount of Transaction; and Customer Account Number.
Figure 3 illustrates the operation of the merchant web site. The consumer clicks the bank logo and selects the e-payment option block 11. The order then is either given an identification automatically by the merchant or generates its own using a transaction identification module block 21. If the order generates a transaction identity automatically the IEO 1 1056 identify tag is returned to the merchant for inclusion as a pending transaction alternatively if the merchant gives the identity tag, a simple cross-reference mechanism occurs when confirmation messages are received from the bank. The consumer is then directed to the bank login process block 30 enabling the consumer to access their accounts on-line. Once the payment transaction has been completed block 61 the bank sends an encrypted message to the merchant web server. The message is decrypted by the software installed within the payment confirmation process block 62. The pending payment transaction block 71 receives notice either confirming or denying the payment allowing the consumer to be returned to the merchants website on the consumers browser. The consumer is then free to complete any remaining details required by the merchant if necessary.
Ideally, the merchant website resides on a server that is within easy reach of the merchant. It is preferable for the server to run Microsoft IIS web server and Microsoft NT/2000 operating system or a similar or higher version of these packages.
It will of course be understood that the invention is not limited to the specific details as herein described, which are given by way of example only, and that various alternations and modifications may be made without departing from the scope of the invention.
MACLACHLAN & DONALDSON, Applicants’ Agents, 47 Merrion Square, DUBLIN 2. ΙΕΟ 110 5 6

Claims (5)

CLAIMS:
1. A method of making electronic payments comprising the steps of: 5 (a) connecting to a merchant’s internet site; (b) choosing one or more items for purchase; (c) entering a merchant’s order page on the merchant’s internet site; (d) choosing a payment method from the merchant’s internet site that is connectable to an on-line site of a financial institution with whom the consumer has one or more accounts; 15 (e) connecting to the online site of the financial institution; (f) selecting a consumer’s account to make a withdrawal from; (g) transferring money from the consumer’s account to the merchant’s account; (h) returning to the merchant’s internet site; and (i) completing the order upon confirmation of the money transfer. Γ 25
2. A method as claimed in claim 1, in which the financial institution controls all payment transactions between the consumer and the merchant; optionally, in which the only information given to the merchant by the consumer is the item or items chosen for purchasing; optionally, in which the financial institution confirms that the merchant has funds for the purchase on his/her account prior to distributing the goods to the consumer; IE 0 11 ο 5 6 and optionally, in which standard account management security requirements are used to mitigate against the risk of fraud. 5
3. A method as claimed in claim 1 or claim 2, including reversing a payment when an ordered item is either out stock or is unavailable; optionally, crediting money back into the consumer’s account on rejection of a payment transaction by a merchant; optionally, in which the financial institution controls all reversed payment transactions; and optionally using a unique identification tag for a consumer’s account other 15 than the account number in the financial institution in the transaction with the merchant.
4. Apparatus for making electronic payments comprising: 20 (a) means for connecting to a merchant’s internet site; (b) means for choosing an item to purchase; (c) means for entering a merchant’s order page on the merchant’s internet site; 25 (d) means for'choosirig a payment method from the merchant’s internet site that is connectable to an online site of a financial institution with whom the consumer has one or more accounts; 30 (e) means for connecting to the online site of the financial institution; (f) means for selecting a consumer’s account to make a withdrawal from; •EO I Ιο 5 8 (g) means for transferring money, from the consumer’s account to the merchant’s account; 5. (h) means for returning to the merchant’s internet site; and (i) means for completing the order upon confirmation of the money transfer.
5. A method of making electronic payments substantially as herein described with 10 reference to the accompanying drawings.
IES20011056 2001-12-11 2001-12-11 A Method of Making Electronic Payments IES20011056A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
IES20011056 IES20011056A2 (en) 2001-12-11 2001-12-11 A Method of Making Electronic Payments

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IES20011056 IES20011056A2 (en) 2001-12-11 2001-12-11 A Method of Making Electronic Payments

Publications (1)

Publication Number Publication Date
IES20011056A2 true IES20011056A2 (en) 2003-06-25

Family

ID=27637963

Family Applications (1)

Application Number Title Priority Date Filing Date
IES20011056 IES20011056A2 (en) 2001-12-11 2001-12-11 A Method of Making Electronic Payments

Country Status (1)

Country Link
IE (1) IES20011056A2 (en)

Similar Documents

Publication Publication Date Title
AU754886C (en) A virtual private lock box
US8468092B2 (en) Method and system for processing internet payments using the electronic funds transfer network
US20090327133A1 (en) Secure mechanism and system for processing financial transactions
US20130191278A1 (en) Method and System for Processing Internet Payments Using the Electronic Funds Transfer Network
US20070061206A1 (en) System and method for providing rapid rebate payments
US9953305B2 (en) Online payment system and method according to the mirror authorization server principle
WO1999007102A1 (en) Real time bank-centric universal payment system
AU2001259944B2 (en) System and method for facilitating payment over the internet or like communication media
AU2001259944A1 (en) System and method for facilitating payment over the internet or like communication media
WO2000067216A1 (en) A banking card associated with a cash account
WO2000057330A1 (en) Financial payment method and medium
WO2007040555A2 (en) Method and system for expediting coupon and rebate processing
IES20011056A2 (en) A Method of Making Electronic Payments
AU2004201231B2 (en) Method and system for processing internet payments using the electronic funds transfer network
JP2007026160A (en) Settlement system and method thereof
WO2001069914A2 (en) Methods for managing transactions on the internet with anonymous shipping addresses
US20040128234A1 (en) Method of conducting financial transactions over the internet
WO2007044830A2 (en) System and method for providing rapid rebate payments
CA2409680A1 (en) Method of conducting financial transactions over the internet
EP1301880A1 (en) System and method for facilitating payment over the internet or like communication media
KR20020030047A (en) Enterprise for loan settlement line urgent civil official
WO2001093219A2 (en) Financial payment system

Legal Events

Date Code Title Description
MM4A Patent lapsed