WO2006049585A1

WO2006049585A1 - Payment system

Info

Publication number: WO2006049585A1
Application number: PCT/SG2005/000376
Authority: WO
Inventors: Eng Sia Lee
Original assignee: Mobile Money International Sdn Bhd; Mobile Money (S) Pte Ltd
Priority date: 2004-11-05
Filing date: 2005-11-02
Publication date: 2006-05-11

Abstract

A system and method for secure payment is disclosed wherein the security offered is a close-loop confirmation using a matching approval code issued to both a merchant and a customer purchasing from the merchant. Furthermore, a random identity is also disclosed which may be used in conjunction with the approval code for a single purchase, thus preventing recycling of the random number by thieves for illegal purchases.

Description

Payment System

Field of invention

The present invention relates to electronic transaction.

Background of invention

Various forms of payment by electronic means have become popular in recent times. An on going problem with such transactions is their susceptibility to security breaches, particularly through user information being misappropriated and used by unauthorised persons.

One common form of electronic payment is based on credit card facility, such that a person makes payment by drawing on borrowed money from a credit account. In such a credit card transaction, a physical card is typically associated with the credit account holder (via a credit account number). The card is imprinted with a sixteen-digit credit card number, expiry date of the credit card and the name of the credit account holder. A magnetic strip on the back of the credit card carries similar information for electronic reading. To make a purchase using a credit card, the credit account holder presents the credit card

to a merchant who swipes the credit card through an electronic card reader,

which reads the information from the magnetic strip. The card reader then processes the payment by contacting the credit card company to pay the merchant from the credit card owner's credit account.

Once the transaction is successful, the transaction is further sealed by the credit account holder placing his signature on a receipt produced by the card reader. The back of the credit card also has a signature of the credit account holder, which the merchant uses to compare signatures to ensure that the signature placed on the receipt is authentic. However, there is a risk in such a system that the credit card may be stolen and the signature of the credit account holder forged by a thief in making an illegal purchase.

Some credit cards, in attempting to provide better security, print a picture of the credit account holder onto the credit card, to assist a merchant in determining that the person making the purchase is, in fact, the person shown in the picture as the credit account holder. However, it is not uncommon for some merchants not to check the signature of the credit account holder and it is therefore not unreasonable to expect that checking of the photograph would be equally haphazard.

Nevertheless, this extra level of security, albeit weak, of combining signature and picture authentication is not available when the credit card is used for Internet e-transactions. For Internet purchases, the e-transaction is impersonal

and a payment web page of the merchant merely requires the input of identification data only, such as the credit card number with verification based on the purchaser entering the card's expiry date.

Thus, the risk of theft is considerably higher with the advent of Internet payment. Credit card information have been known to be stolen from the credit card or copied electronically and then re-used repeatedly for illegal purchases before the credit card owner can deactivate his credit account.

In such a case, the credit card company may often insists on the credit account holder bearing responsibility for the lost card and the illegal transactions.

Furthermore, a new form of Internet misappropriation has recently emerged, which uses a fake web page looking and behaving like the genuine web page of a merchant or a bank. Such a web page is known as a 'phishing' web page. A 'phishing' web page, having the same look as the genuine one, tricks the merchant's or the bank's customers into supplying confidential login information to the 'phishing' web page, which is then used by the creator of the !phishing' web page for illegal transactions using customer's money or credit.

It is foreseeable that as money gets more electronically, mobile, these risks will

increase.

It is therefore an object of the invention to provide a novel method of cash-less payment whilst less prone to misappropriation as compared to the prior art. Summary of the invention

In a first aspect, the present invention provides a payment system comprising a first database, the first database being linked to a monetary account of a first person, a transaction approval code issued by the first database to the first person; wherein on initiation by a second person, the first database is capable of instructing a transaction on the monetary account of the first person and sending the transaction approval code to the second user; whereby the first person and the second person receive the same transaction approval code.

In a second aspect, the present invention provides a payment system comprising a first database, an identity code issued by the first database to a first person, the first database being linked to a monetary account of the first person, the identity code useable by a second person to initiate the first database to make a transaction on the monetary account of the first person; wherein the identity code is useable for initiating a pre-determiπed number of transactions on the monetary account of the first person.

In a third aspect, the present invention provides a method of performing a

payment transaction comprising the steps of issuing a transaction approval code generated in a database to a first person, making electronic payment by the first person to a second person via the database_r-the second person

receiving from the database the transaction approval code when the payment is made, whereby the first and the second person receive the same transaction approval code.

In a fourth aspect, the present invention provides a method of performing a payment transaction comprising the steps of a payment facility issuing an identity code to a registered payer, a monetary account of the payer having been linked to the payment facility, the payer providing a payee the identity code, the payee initiating a taking of payment from the payer by sending the identity code to the payment facility, payment facility authenticating the identity code to be the one issued to the payer and payment facility effects a payment transfer from the monetary account of the payer.

Thus, the invention may provide a third party observation and confirmation on electronic transactions. The third party confirmation to both a customer and a merchant provides a closed-loop security which is not available by the conventional methods.

Brief description of the drawings

It will be convenient to further describe the present invention with respect to the accompanying figures which illustrate possible arrangements of the invention. Other arrangements of the invention are possible, and consequently the

particularity of the accompanying figures is not to be understood as superseding the generality of the preceding description of the invention. Figure 1 is a relationship diagram between entities according to an embodiment of the present invention;

Figure 2 is a flowchart showing the relationships as illustrated in Figure 1 ; and

Figure 3 is another flowchart according to the embodiment of Figure 1.

Detailed description of the preferred embodiments

Figure 1 illustrates a system 0001 comprising a payment facility 0300, a bank 0400 (or a bank-like institution or system), a customer's mobile phone 0100 which is registered with the payment facility 0300, a merchant's cashier system 0200 which is linked to communicate with the payment facility 0300 by conventional communication and network technology to the payment facility 0300. Figure 2 is a flowchart showing the system of Figure 1.

The payment facility 0300 comprises a database which contains records of the customer's mobile phone 0100 number, the customer's identity and the customer's bank account. The database of the payment facility 0300 also holds records of a merchant (not illustrated), who is the owner of the cashier system 0200, and his merchant account (not illustrated). The payment facility 0300 is authorised to make transactions on the customer's account in the bank 0400, particularly in debiting the customer's account for payment to a third party, such as the merchant.

Typically, the payment facility 0300 is operated by an independent third party payment facilitator such as those with operations similar to that of VISA or other credit management bureaux, but alternatively may be directly operated by the bank 0400. If the payment facility 0300 is operated independently by a third party, the payment facility may be linked to work with customers each having an account in a different bank 0400.

Thus, the customer may use the system 0001 to make a purchase from the merchant on the customer's account registered with the payment facility 0300. However, before the customer may make a purchase using the system 0001, the customer 0100 has to receive a six-digit random identity from the payment facility 0300 which he may use to identify himself in the system 0001. The random identity, in this embodiment, is randomly generated in the payment facility 0300 and may be sent by SMS to the customer's mobile phone 0100 registered with the payment facility 0300 (the random identity being six-digit is only exemplary and, in practice, the random identity need not be six-digit or even totally or partially numerical).

The customer's mobile phone number to which the SMS is sent therefore serves as a means of authenticating the customer in this embodiment. Using its database, the payment facility 0300 is able to keep record and track of the random identity. The random identity is therefore recognisable by the payment facility 0300 as having been assigned to the particular customer.

Furthermore, before he can start using the system, the customer 0100 also has to have received a personal identification number (PlN) from the payment facility 0300 (or, in a variation of the embodiment, from the bank 0400).

In making a purchase, the customer provides the random identity to the merchant. The merchant then enters the random identity appended with the customer's PIN and purchase price into the cashier system 0200 to initiate electronic payment. For example, the merchant may enter the following string into his cashier system 0200:

"123456000134.50"

where the customer's random identity is "123456", the customer's PIN is "0001 " and the purchase price is "34.50".

Optionally, specific delimiters such as "#" or "_" may be provided between the random identity, PlN and purchase price to help the payment facility 0300 parse the information. For example, a string with delimiters may look like "123456#0001_34.50".

The cashier system 0200 then communicates the above exemplary electronic payment string to the payment facility 0300 and, in doing so, instruct the payment facility 0300 to transact on the customer's account in the bank 0400. Furthermore, the cashier system 0200 also communicates the identity of the merchant to the payment system 0300 so that the payment system knows who to make the payment to. As is known in conventional bank 0400 systems, it is not necessary that the merchant must have an account with the same bank 0400 in order for the bank 0400 to transfer money to the merchant's account; the merchant can have an account in another bank 0400 which can nevertheless receive payment. Thus, if the merchant does not have an account which is registered with the payment facility 0300, information on the merchant's bank account to be credited with the payment may also be sent by the cashier system 0200 to the payment facility 0300 when initiating payment transaction.

Understandably, the payment facility 0300 has the necessary computing and database infrastructure to parse the string containing the random identity, the customer's PIN and the bill amount sent by the merchant, and is able to authenticate that the random identity is the one issued to the same customer

having the PIN.

Upon confirmation that the customer having the PIN is also the one who has been issued with the random identity, the payment facility 0300 communicates with the bank 0400, at 2040, to transfer the transaction/bill amount out of the customer's account to the merchant's account.

Once the customer's bank 0400 has successfully transferred the money from the customer's account to the merchant's, the bank 0400 issues an indication of successful transaction to the payment facility 0300. The payment facility 0300 then, in turn, responds to the merchant and/or customer with an indication of successful transaction.

In this embodiment, the random identity only useable for a single transaction, after which the customer has to receive another random identity from the payment facility 0300, which he may use to make another purchase. The PIN, on the other hand, is permanent and reusable unlike the random identity.

If the purchase is made via Internet and not by the merchant's cashier system 0200, the customer enters the random identity and/or PIN himself into the merchant's web page.

As the random identity is useable only one, the customer is assured that unauthorised access to his account is prevented once the random identity has expired on the single use.

In a variation of the embodiment, the random identity may be useable repeatedly for an unlimited number of times, a fixed number of time, or unlimited number of time within a certain time frame after which the random identity expires and a new one has to be issued to the customer. Furthermore, the random identity may expire automatically within a predetermined period of non- use.

Alternatively, the payment facility 0300 may issue the random identity through an Internet web page, an email or a phone call etc., instead of SMS.

In another variation of the embodiment, the customer himself enters the random identity and/or PIN into the merchant's cashier system 0200 while the merchant enters only the bill amount and/or the random number. This could ensure that the merchant is not shown the PIN and the customer retains confidentiality on the PIN. In a further variation, the payment amount, along with the random identity, with or without the PIN, may be entered all together by the customer himself into the merchant's cashier system 0200.

In yet another variation of the embodiment, the customer is not provided with a PIN to be used with the random identity. In other words, the customer and merchant use the random number alone to complete the transaction, without

need of a PIN.

In the embodiment according to Figure 1 , the mobile phone 0100 represents the customer's means of communication. In alternative embodiments, other communication systems and devices such as the PDA, email or an Internet web page may be used.

In a variation of the embodiment, the cashier system 0200 comprises a microphone or receiver, such that Interactive Voice Response (IVR) technology with voice recognition capability may be used by the merchant to articulate the random identity to take payment. In using IVR to articulate the random identity, there is lesser likelihood that the random identity is copied by Trojans or other computer viruses.

The account of the customer may be any debit or credit account.

In a second embodiment, along with the random identity and the PIN, the customer is also pre-issued with a transaction approval code (TAC). For an example, the TAC is three-digit number.

The TAC is useable to indicate to the customer that the random identity has been used. For example, when a payment transaction via the system 0001 on the customer's account is successful and the bank 0400 indicates to the payment facility 0300 that the transaction is successful, the payment facility 0300 sends the TAC to the merchant who then shows the TAC to the customer. As the TAG has never beeri disclosed to the merchant, the TAG which the merchant receives from the payment facility 0300 matching the TAC which the customer has been pre-issued with would assure the customer that the random identity has indeed been used for the transaction. Since the random identity expires on a single use, matching the TAG between customer and merchant assures that the merchant has not kept the random identity and PIN to himself, without actually performing the transaction, and the random identity has indeed expired on use. This prevents occasions in which the merchant may surreptitiously obtain and use the random identity and PIN for his own purposes without the customer knowing.

In matching the TAC to confirm a successful transaction, the payment facility 0300 may have the security feature of a closed-loop system, wherein the customer may be assured by both the merchant and the payment facility 0300 of the transaction having been made.

On successful transaction, the TAC may be sent to the merchant by the payment facility 0300 in the form of a printout from the cashier system 0200 (which may also be used as proof of receipt). Alternatively, the TAC may be sent to the merchant by SMS, Internet, email or a telephone call etc..

Advantageously, the merchant may also match the TAC he received from the payment facility 0300 to confirm if the customer is the person authorised to make the purchase using the random identity. This is more secure than the credit card method in which the signature and/or picture of the authorised

cardholder is to be authenticated by the merchant who is not expected to be trained to identify forgery. Optionally, the customer may obtain the TAC from the payment facility by calling the payment facility. The payment facility may have a teller or an interactive voice response to issue the TAC. Preferably, the PIN is to be supplied to the payment facility before the customer could obtain the TAG, and the payment facility therefore uses both the caller ID of the customer's mobile phone and his PIN to authenticate the customer. The TAG may alternatively be recited verbally over the phone to the customer or may be sent via SMS to the customer. Preferably, electronic transaction on the customer's account, whether by convention electronic methods or by the afore-mentioned random identity, is disabled until the TAG is issued.

Optionally, the TAG is also a randomly generated number which is re-issued each time the customer makes a purchase.

Alternatively, the TAC may be a number which is issued once and is re-useable for an unlimited number of purchase by the customer.

Alternatively, the same TAG may be used for a specific number of purchases before it has to be changed, for example, after making five puchases, the TAG has to be changed and the bank 0400 issues a new one for confirming further

purchases. The TAC may also be issued once and is useable for a specific period of time, such as a week or a month, after which the TAC expires and a new one has to be issued to the customer. Using the same TAC for a period of time, instead of using a new TAC for each new purchase, reduces effort on the customer's part to remember a new TAC for each purchase.

Optionally, the TAC expires after a period of non-use.

Optionally, the TAG comprises numerals, alphabetical letters or a mix of both.

The TAC may also be an incremental number Which shows the customer a cumulative number of total transactions made on his bank 0400 account via the payment facility 0300. This provides a further security measure in that the customer may be alerted that a transaction has been made on the customer's account via the payment facility 0300 without him knowing, that is, if the TAC skips an increment. The incremental TAC may be reset, for example, daily, weekly, monthly, yearly or whenever the customer wishes to reset the incremental TAG. As a further alternative, the TAC may be set to start at a certain number and is reduced decrementally as the customer makes purchase transactions on the system 0100 and transactions via the payment system 0300 is disabled when the TAC reaches a minimum figure, such as "000". This could help the customer in self-monitoring the number of purchases he makes. Furthermore, the resetting of the TAC may be password protected, which could be used to control and monitor purchases made on the customer's account, for example, by a parent permitting a fixed number of transactions executable by his child to until the TAC is reset.

Thus, advantageously, the embodiment may also allow the customer to provide the random number to a third party to make a purchase for him, without having to worry about the third party making more than one^' purchase without permission.

In a further variation of the embodiment, the TAC is not pre-issued to the customer. When a purchase payment is transacted successfully by the payment facility 0300, a new TAC is issued to both the customer and the merchant at the same time which they can compare at once to ensure that the purchase has been made, and that the correct customer account has been transacted on. This prevents the TAC from being written down, stolen and used by an unauthorised person.

In a further variation of the embodiment, the customer may make a purchase on the Internet and receive a confirmation of the purchase, with the transaction web page showing the TAC that the customer expects to see. This provides closed-loop security for Internet purchases as the TAC is issued by the payment facility 0300 directly to the customer and the TAC is also shown by the merchant web page on a successful transaction. The Internet application of the TAC to confirm a transaction may be used with the random identity aforementioned, with conventional credit card or Internet banking facilities.

Typically, purchases are transacted on the Internet via a web page hosted by the merchant. In yet a further variation of the embodiment, it is possible that the customer makes a purchase, or fund transfer, via a web page hosted by the payment facility (or bank or bank-like institute) itself, instead of a web page hosted by the merchant. In other words, the web page may not be that of the customer but of the payment facility, and the payment in made in the form of a simple fund transfer to the merchant's account from the payment facility. In this case, the payment facility that has pre-issued the customer with the TAG will again send or display the same TAG to the customer, i.e. a second time, when the customer has successfully made the fund transfer. This is advantageous in preventing misappropriation of information by 'phishing' web pages. A 'phishing¹ web page is a tool in a recent illegal trend in which a fake web page looking exactly like the genuine web page of a bank or payment facility misleads a customer to furnish private login information to the creator of the 'phishing' web page. Such 'phishing' web pages are on the rise in recent times and banks have resorted to fight such 'phishing' web pages by sending out alerting emails to their customers, which are not very effective. In this variation of the embodiment, as the customer expects to see the TAG he was pre-issued with

after having made a fund transfer or payment via a web page, receiving the expected TAG would prove that the web page facilitating the transaction is genuine; the TAC is able to confirm that the transfer or payment has been made with the right payment facility.or bank. The 'phishing' web pages are not able to issue the TAC, as the TAC issued by the payment facility or bank is confidential to only the customer and the payment facility or the bank.

Therefore, the TAC may be used not only with a merchant to confirm a successful purchase transaction, the TAC may also be used with the same payment facility (or bank) which issues the TAC to confirm a fund transfer. In fund transfers, the receiving account may be the merchant's account. It may be that of any recipient of the fund transfer, such as a dependent or a child of the customer.

In a third embodiment of the invention, the customer is pre-issued by the payment facility with only the random identity and the PIN and not with the TAC. When the customer wants to make a purchase, the customer firstly sends the payment facility 0300, preferably via SMS₁ the random identity issued to him. In the SMS, the customer appends at the end of the random identity the PIN and also a TAC of his own composition. When the SMS is sent to the payment facility 0300, the TAC of the customer's own composition is then stored in the payment facility 0300's database. The customer then provides the random identity, with or without the PIN, to the merchant in making a purchase. The merchant then sends the random identity, with or without the PIN, and the bill amount to the payment facility 0300 to take a payment from the customer's account in the bank 0400. On successful payment transaction, the payment facility 0300 responds to the merchant with the very TAC composed by the customer, and the merchant then shows the customer the TAC to confirm that the transaction has indeed been made using the random identity.

The customer-composed TAC may be valid for a single use; once the customer- composed TAC has been used, the customer will need to compose and send to the payment facility 0300 another self-composed TAC or the payment facility 0300 will not allow anymore transactions.

Alternatively, the customer-composed TAC may be re-useable indefinitely.

Alternatively, the customer-composed TAC may be re-useable indefinitely within a certain time frame.

Alternatively, the customer-composed TAG may be re-useable for a pre¬ determined number of times.

Optionally, the customer-composed TAC expires after a pre-determined period of non-use,

The TAC may also be used with conventional credit card payment, i.e. without using the random identity. For example, a conventional credit card company may issue the TAC to the customer for confirmation of a purchase as afore- described, or the customer may pre-send a self-composed TAC to the credit card company by SMS for use in confirming a purchase later using his credit card.

This third embodiment thus may provide the advantage of a personalised security measure.

Figure 3 is a flowchart further illustrating an embodiment.

At step 1010, a customer having an account accessible by the payment facility 0300 is supplied with a random number by the payment facility 0300, i.e. the random identity. Preferably, the random identity is issued by SMS through the customer's mobile phone 0100 and the random identity is recognisable by the payment facility 0300 for instructing, preferably, only one financial transaction from the customer's bank 0400 account. In other words, the payment facility 0300 is linked to the customer's account in a bank 0400. At the same time, the customer is also been supplied with a PIN and a 3 digit TAC by the credit payment facility 0300.

At step 1020, the customer makes a purchase from the merchant and, in doing so, provides the merchant the random identity and PIN for electronic payment.

At step 1030, the merchant sends the random identity and the PIN of the client, as well as the payment amount, through the merchant's cashier system 0200 to the payment facility 0300 to take payment from the customer's bank 0400 account.

At step 1040, the payment facility 0300 authenticates that the random identity and the PIN are those that were supplied to the same account holder. If the random identity and the password were those of the same account holder, the payment facility 0300 communicates with the bank 0400 of the customer to transfer money, at 1050, from the customer's account to the merchant's account. The merchant's account need not be in the same bank 0400, but could be in another bank 0400 to which the customer's bank 0400 may make a transfer.

At step 1060, if the transaction is not successful, which may be because the random identity and/or the PIN is not recognised by the payment facility 0300, the payment facility 0300 will issue a rejection notice to the merchant and the customer, at step 1070. If the transaction is successful, at step 1060, the payment facility 0300 will inform the merchant that the transaction is successful, at step 1075. The payment facility 0300 will also send the TAC to the merchant.

Then, at step 1080, the merchant shows the TAC to the customer to prove that the transaction has been made using the customer's random identity.

At step 1090, the customer checks to ensure that the TAC is the one he expects

to receive. If so, he is assured that the transaction has been made and the random identity, once used, is then rendered useless. This relieves the customer from worry that the merchant might not have made the transaction and has kept the random identity to himself to make a surreptitious and unauthorised transaction later.

The process repeats when the customer receives another random credit facility and TAG to make another purchase. Optionally, the TAG is reusable so that the customer receives another random credit facility only, without the TAG.

The random identity and the PIN as mentioned in the embodiments may also be termed interchangeably, the random identity may be called a random PIN while the PIN may also be termed a virtual account number. In other words, the random identity may be seen as a PIN in the relationship of the parts of the system.

Optionally, the TAG, the random identity and/or the PIN may be issued by an interactive voice response (IVR), such as those used in machine-based tellers in phone banking. It is preferable to use IVR instead of SMS where the SMS system is not suitable for the customer to receive the SMS messages without delay. Furthermore, receiving the TAG, random identity or the PIN through IVR prevents the TAC, random identity or the PIN from being read by an unauthorised person who has stolen the mobile phone or email password of the

customer. It should be understood that the embodiments described herein are but embodiments of underlying concepts of the invention. Alternatives to the embodiments, though not described, are intended to be within the scope of this invention as claimed.

Claims

1. A payment system comprising: a first database, the first database being linked to a monetary account of a first person; a transaction approval code issued by the first database to the first person; wherein on initiation by a second person, the first database is capable of instructing a transaction on the monetary account of the first person and sending the transaction approval code to the second user; whereby the first person and the second person receive the same transaction approval code.

2. A payment system as claimed in claim 1 wherein the first database is capable of instructing the transaction only when the transaction approval code has been issued by the first database to the first person.

3. A payment system as claimed in claims 1 or 2 wherein the first database is capable of instructing a pre-determined number of transactions on the monetary account of the first person for the transaction approval code issued by the first database to the first person.

4. A payment system as claimed in claim 3 wherein a pre-determined number of transaction is only one transaction.

5. A payment system as claimed in any one of claims 1 and 2 wherein the first database is capable of instructing one or more transactions on the monetary account of the first person within a predetermined period of time after the transaction approval code has been issued to the first person.

6. A payment system as claimed in any one of the preceding claims wherein the transaction approval code is issued by the first database to the first person by any one or a combination of the Internet, email, interactive voice response or SMS.

7. A payment system as claimed in claim 6 wherein the SMS is sent to a mobile phone of the first person.

8. A payment system as claimed in claim 7 wherein the mobile phone is registered with the first database as belonging to the first person.

9. A payment system as claimed in any one of the preceding claims wherein the first person is a customer of the second person; and the transaction

is a purchase transaction between the first and the second person.

10. A payment system as claimed in any one of the preceding claims wherein the transaction approval code is used in conjunction with a conventional credit card payment.

11. A payment system as claimed in any one of the preceding claims wherein the instruction is made via the second person initiating the first person to send an SMS indicating the identity and a transaction amount to the payment facility.

12. A payment system as claimed in any claim 1 , wherein the first person is the same person as the second person; the transaction approval code is issued to the first person before the transaction instruction is made; and the same transaction code is re-issued to the first person after the transaction; whereby the first person receives the same transaction approval code.

13.A payment system comprising: a first database; an identity code issued by the first database to a first person;

the first database being linked to a monetary account of the first person; the identity code useable by a second person to initiate the first database to make a transaction on the monetary account of the first person; wherein the identity code is useable for initiating a pre-determined number of transactions on the monetary account of the first person.

14. A payment system as claimed in claim 13 wherein: the identity code is sent by the second person along with a monetary amount to the first database to initiate the first database to instruct the transaction on the monetary account of the first person.

15. A payment system as claimed in claims 13 or 14 wherein: the identity code is sent by the second person along with a personal identification number of the first person to the first database to instruct the transaction on the monetary account of the first person.

16. A payment system as claimed in claim 15 wherein: the identity code is sent by the second person; and the personal identification number of the first person is sent along by the first person; whereby the personal identification number of the first person is not made known to the second person.

17.A payment system as claimed in any one of claims 13 to 16 wherein: the identity code is useable for initiating only one transaction on instruction by the first database on the monetary account of the first

person.

18. A payment system as claimed in claims 13 or 17 wherein the identity code is useable for initiating a pre-determined number of transactions within a predetermined period of time after the identity code has been issued to the first person.

19. A payment system as claimed in any one of claims 13 to 18 wherein: the initiation is made via a cashier system linked to the first database.

20. A payment system as claimed in claim 19 wherein: the cashier system comprises operations on the Internet.

21. A payment system as claimed in any one of claims 13 to 18 wherein: the initiation is made via a IVR system linked to the first database.

22.A payment system as claimed in any one of claims 13 to 21 wherein: the second person initiates the transaction by initiating the first user to send the identity code to the first database.

23. A payment system as claimed in any one of claims 13 to 21 wherein the identity code is issued by the first database to the first person by any one or a combination of the Internet, email, interactive voice response or SMS.

24. A payment system as claimed in claim 23 wherein the SMS is sent to a mobile phone of the first person.

25.A payment system as claimed in claim 24 wherein the mobile phone is registered with the first database as belonging to the first person.

26.A payment system as claimed in any one of claims 13 to 25 wherein the first person is a customer of the second person; and the transaction is a purchase transaction between the first and the second person.

27. A method of performing a payment transaction comprising the steps of: issuing a transaction approval code generated in a database to a first person; making electronic payment by the first person to a second person via the database; the second person receiving from the database the transaction approval code when the payment is made; whereby the first and the second person receive the same transaction approval code.

28. A method of performing a payment transaction as claimed in claim 27 wherein the payment is made on a credit account of the first person.

29. A method of performing a payment transaction as claimed in claims 27 or 28 wherein the payment is made on a debit account of the first person.

30. A method of performing a payment transaction comprising the steps of: issuing an identity code to a registered payer by a payment facility, a monetary account of the payer having been linked to the payment facility; the payer providing a payee the identity code; the payee initiating a taking of payment from the payer by sending the identity code to the payment facility; the payment facility authenticating the identity code to be the one issued to the payer; and the payment facility effecting a payment transfer from the monetary account of the payer.

31.A method of performing a payment transaction as claimed in claim 30 further comprising the step of the payee initiating a taking payment from a payer by further . sending a personal identification number of the payer to a payment

facility; and the payment facility authenticating the personal identification number to be the one issued to the payer before the payment facility effects a payment transfer from the monetary account of the payer.