Field of the Invention

The present invention relates to an authorisation system and method, and in particular to a transaction authorisation system for secure authorisation of transactions such as financial transactions.

Background to the Invention

Fraud is always an issue in financial transactions. The highest percentages of fraudulent transactions occur where the purchaser is not physically present when making the transaction. For example, a much higher percentage of orders made over the telephone and over the internet are fraudulent compared to those made at a point of sale in a shop etc.

Credit and debit cards remain the payment type of choice for transactions made over the internet or by telephone. It is highly unusual for a merchant not to accept such payment mechanisms and the majority of the adult population have at least one credit and/or debit card.

Transactions where the credit or debit card is not physically present to be verified by the merchant are referred to as "card not present" transactions in the financial payment industry. In making a card not present order, a purchaser discloses his or her name, credit card number and expiry date in order for the credit card to be charged for a product or service. The card itself is not present at the point of sale so it cannot be checked.

These sorts of transactions are different to so-called "card present" transactions at Electronic Point- of-Sale Terminals or the like, where both the cardholder (purchaser) and the card are required to be physically present. The purchaser is required to sign an authorisation or enter a pin number to permit a transaction to be charged against that card's account. The merchant is accountable for the verification and authentication of the card and the validation of the cardholder's identity. By the fact that:

1. A recognisable card is presented

2. Identification, Authorisation and Entitlement processes are enforced

3. The location of the transaction is legitimate

Then the transaction qualifies as a "card present" transaction. Typically in "card not present" transactions it is not possible to verify the identity of the purchaser and the validity of the "card". Anybody knowing the information contents of a valid credit card can make purchases and charge that card account with "card not present" transactions. The purchaser need not even have the card. A common fraudulent practice is to acquire discarded credit card receipts, which contain the necessary account information, to create fraudulent "card not present" transactions. In order to avoid this, many receipts now only specify part of the account information. Additionally, some merchants will only deliver to the address registered with the customer's credit card issuer (usually a Financial Institution). Recently, computer programs have been developed and made available on the Internet that successfully generate random credit card numbers. While the numbers generated may not always be valid, computing power is such that a brute force approach can be applied as a 99% or higher failure rate still means that valid numbers are generated. In order to combat this, a relatively crude way of providing some assurance that the card was held by the purchaser at the time of the transaction was introduced. A code (called, among other things, the CVV - card verification value) was added to the physical cards and was not included in transaction receipts etc. Therefore (in theory) the provision of the code in card not present transactions provided an indication that the physical card was in the purchaser's possession.

One particular area where the use of credit cards is increasing exponentially is on the World Wide Web in e-commerce websites and the like. Whilst credit and debit cards are currently the only commonly accepted and feasible ways for such sites to be paid for their products or services, the lack of security in transactions across the Internet, even if encrypted, has resulted in many financial issues and privacy concerns. Because transactions can be intercepted or monitored, unscrupulous persons are obtaining credit card numbers and fraudulently using them for other purchases. The level of security provided by websites varies considerably and many sites have found themselves being attacked for the contents of their databases containing credit card details.

In response to the potential and actual problems, the international bodies responsible for credit cards, including VISA (RTM) and MasterCard (RTM), have introduced premium charges and different terms and conditions for merchants using their services depending on whether the card is present. For example, a merchant submitting a card present transaction may typically be charged 0.75% up to 3% of the transaction value by the financial institution whereas a merchant submitting a card not present transaction may be charged 4 to 5% or more. An online merchant, who is competing with traditional merchants using point-of-sale "card present" transactions, has to bear a substantial overhead; this reduces his profit margin if he or she wishes to remain competitive. The main reason that the international card issuing bodies claim that the premiums are justified is that a consumer has a legal right to claim against a credit card issuer if the order is not properly fulfilled. Where there is a dispute over a "card not present" transaction, such as the validity of the amount charged, authenticity of the transaction or proven receipt of goods, the rules favour the consumer over the card issuer/merchant. In order to cover themselves against losses and overheads from dealing with these fraudulent transactions, card issuers add a premium to the merchant discount rate, as a form of insurance. As a double blow, the merchant is also accountable for all costs for transactions in dispute.

Clearly a merchant who processes card not present transactions is at a disadvantage. However, it is a desirable business model to operate a virtual/online store or service because this does not entail the same overheads of a bricks and mortar operation.

Various mechanisms have been suggested that allow mobile telephones and the like to act either as a credit card themselves or as a means for authenticating the legitimacy of a transaction. A user presents the card (physically or virtually), the system detects that the card has been presented and sends a query to the mobile telephone. Only upon approval from the mobile telephone is the transaction completed and approved. In such systems, changes are required to the back-end processing such that verification is sought during the authentication process.

One complication with such systems is that there is no one back-end system or processing authority. Transactions are routed to a particular data network depending on the supporting bank/financial institution. Therefore such systems are dependent on being implemented by the financial institution. Not only is there an overhead in doing so, financial institutions are nervous in making fundamental changes to their underlying systems due to concerns over creating security flaws or otherwise undermining the integrity of their systems. It is clearly desirable to be able to provide a mechanism for authentication of payment transactions that could be implemented in present day transaction authentication systems without modification of those systems. Furthermore, it would be desirable to be able to provide such a mechanism in a manner that is transparent to current authentication systems so as to provide an additional layer of security on top of security and procedures that are in place and have been accepted by financial institutions.

Statement of Invention

According to an aspect of the present invention, there is provided a payment authentication system comprising a user interface unit and a payment processing system;

the payment processing system being associated with a unique payment identifier, the unique payment identifier being configured to cause an external system processing a first transaction which uses the payment identifier to transmit data querying the transaction to the payment processing system, said data including or identifying the unique payment identifier,

wherein upon receipt of data querying the transaction, the payment processing system is arranged to communicate with the user interface unit to process a further transaction to make a payment corresponding to the first transaction. The user interface unit preferably includes a card reader and the payment processing system is arranged to make the payment by charging a credit or debit card inserted into the card reader.

Processing of the further transaction is preferably performed between the user interface unit and a financial institution, wherein the external system is not party to processing of the further transaction.

The payment authentication system may be arranged to substitute the unique payment identifier at the external system with data on the charged credit or debit card. The user interface unit may be configured to only enable authorisation for payment of a transaction at, or within a predetermined range of, a predetermined location.

The payment authentication system may further comprise a utility meter at the predetermined location and including a wireless communication system, wherein the user interface unit is uniquely associated with the utility meter and is configured to communicate with the utility meter to enable authorisation for payment of a transaction.

The payment authentication system may comprise a plurality of user interface units, wherein the payment processing system is associated with a unique payment identifier for each of the plurality of user interface units and is arranged to communicate with the respective user interface unit upon receipt of said data querying a transaction.

The unique payment preferably identifier comprises a virtual credit or debit card number registered to the payment processing system, whereby presentation of the virtual credit or debit card number in a first transaction to a credit card processing system is operative to cause data querying the first transaction to be communicated to the payment processing system.

The virtual credit or debit card number may include an issuer identification number associated with the payment processing system, said issuer identification number being operative to cause routing of said data querying the first transaction to the payment processing system.

In embodiments of the present invention, a virtual credit card institution is registered alongside real life institutions. The virtual institution issues virtual credit card numbers that have the sole purpose of redirecting (hijacking) card not present authentication such that a query can be presented to a user at a user interface unit to provide a genuine payment. Processing of the genuine payment can be kept separate to the original transaction to maintain control over disclosure of the genuine credit card number. The genuine payment can then be substituted for the virtual one. Two transactions are in effect made - the first cannot be completed in its original form and is instead re-written with a second transaction that is secure and can be made "card-present". Genuine credit card data advantageously need not be presented to a merchant over the phone or via a website.

According to another aspect of the present invention, there is provided a payment processing method comprising:

associating with a unique payment identifier with a payment processing system, the unique payment identifier being configured to cause an external system processing a first transaction which uses the payment identifier to transmit data querying the transaction to the payment processing system, said data including or identifying the unique payment identifier,

upon receiving data querying the transaction at the payment processing system, communicating with a user interface unit associated with the unique payment identifier to process a further transaction to make a payment corresponding to the first transaction. The user interface unit preferably includes a card reader, the method further comprising receiving a credit or debit card in the card reader and making the payment by charging a credit or debit card inserted into the card reader. Processing of the further transaction is preferably performed between the user interface unit and a financial institution, wherein the external system is not party to processing of the further transaction.

The method may further comprise substituting the unique payment identifier at the external system with data on the charged credit or debit card.

The method may further comprise permitting making payment of the further transaction only when said user interface unit is at, or within a predetermined range of, a predetermined location. The method may further comprise: uniquely associating the user interface unit with a utility meter at a location, said meter having an identifier associated with said location; communicate with the utility meter to obtain the identifier; and, identifying said identifier in communications on said further transaction. The method may further comprise associating plurality of unique payment identifiers with the payment processing system and maintaining a database associating each unique payment identifier with a user interface unit, wherein upon receiving data querying a transaction, the payment processing system determining the user interface unit associated with the is associated with the a unique payment identifier of the queried transaction and communicates with the respective user interface unit to process the further transaction to make a payment corresponding to the first transaction.

The or each unique payment identifier may comprise a virtual credit or debit card number registered to the payment processing system, whereby presentation of the virtual credit or debit card number in a first transaction to a credit card processing system is operative to cause data querying the first transaction to be communicated to the payment processing system. The or each virtual credit or debit card number may include an issuer identification number associated with the payment processing system, said issuer identification number being operative to cause routing of said data querying the first transaction to the payment processing system. According to another aspect of the present invention, there is provided an authentication system comprising a user interface unit associated with a unique identifier, the unique identifier being configured to cause an external system processing an authentication request which uses the unique identifier to transmit data querying the authentication request to user interface unit, said data including or identifying the unique identifier,

wherein upon receipt of data querying the authentication request, the user interface unit is arranged to obtain a user input on the authentication, the user interface unit being arranged to answer said query in dependence on the user input.

The external system may comprises a secure website, said authentication request comprising a request to access said secure website, the user interface unit being arranged to authenticate with said secure website in dependence on the user input.

Detailed Description

Specifications for credit card numbering are set by the International Standards Organization (ISO/IEC 7812-1:1993). In conventional systems, a credit or debit card number is typically between 12 and 19 numerical digits long and uniquely identifies not only the account for the card itself but also the issuing financial institution and network. The first six digits are known as the Issuer Identification Number (UN). These identify the institution that issued the card to the card holder. The rest of the number is allocated by the issuer. The first digits of the UN identify the issuing network (34 or 37 for American Express (RTM), Visa cards start with a 4, etc). When a transaction (either card present or card not present) is submitted for processing, the merchant's system communicates the credit card number to its banking or card processing institution (this is typically done automatically by its e- commerce server or point of sale (POS) card machine). Upon receipt of the card number, the banking or card processing institution uses the UN to route the transaction to the issuing network (and potentially the issuing financial institution) of the card.

Figure 1 is a schematic diagram of a payment authentication system 10 according to an embodiment of the present invention. The payment authentication system includes a user interface unit 20 and a payment processing system 30. When a merchant at a system 40 external to the payment authentication system 10 attempts to process the unique payment identifier for payment of a transaction, the unique payment identifier causes the external system 40 to transmit data querying the transaction to the payment processing system 10. The data querying the transaction includes (or identifies by a hash, encrypted message etc) the payment identifier. The payment authentication system 10 associates a virtual credit card number or virtual debit card number (referred to as a unique payment identifier) with the user interface unit 20. Although the unique payment identifier has the same format as a conventional credit or debit card number, in preferred embodiments it has a dedicated UN that identifies it as a virtual card and directs queries to the payment processing system 30.

Although not illustrated, it will be appreciated that multiple user interface units 20 may be associated with the payment processing system 30. Each virtual credit or debit card number would be associated with one user interface unit 20, although a user interface unit 20 may be associated with multiple virtual credit or debit card numbers (for example for different family members, uses or for limited/one-time use numbers in high risk situations).

The dotted area in Figure 1 delineates the payment authentication system 10 from conventional payment processing systems. Embodiments of the present invention take advantage of the fact that credit/debit card numbers include data (the UN, or at least part of it) that identifies the issuing party such that the correct party can be approached for payment and also in the case of queries. In preferred embodiments of the present invention, the unique payment identifier, although looking like a credit/debit card number, is of no use in making any payment or obtaining any funds and is not in fact associated with a financial credit or bank account. The purpose of the unique payment identifier is to cause the external systems 41, 42 associated with the merchant 40 (in particular his or her card processing system 41 and a bill server 42 which routes transactions to the correct issuing party) to communicate with the payment processing system 30.

The user has the reassurance that even if the card number was obtained, there is no way it could ever be used to complete a payment. However, for all intents and purposes, the merchant sees the unique payment identifier as a valid format credit or debit card number. Rather than being linked to an authorising credit or debit card system that would authorise a standard credit or debit card transaction, the unique payment identifier instead hijacks the authentication process by redirecting to the payment processing system 10. Upon receipt of the data querying the transaction, the payment processing system 30 communicates with the user interface unit 20 to obtain authorisation for payment of the transaction. It will be appreciated that authorisation could be in varying ways, although a preferred embodiment is described below. Upon obtaining authorisation for payment of the transaction, the payment processing system effects payment of the transaction. At least part of the authorisation for payment of the transaction results in a further (valid) credit or debit card transaction being made for the same value as the original transaction and substitution of that further transaction in place of the original transaction.

In a preferred embodiment, the user interface unit 20 includes a card reader 21. The card reader may be a chip and pin (smart card type) card reader, it may be a magnetic stripe card reader or it may be some other type of card reader such as FID or other near field card reader. In this embodiment, the user interface unit 20 prompts the user to enter a valid payment (credit or debit) card to pay for the transaction. Details of the transaction (cost, source, date etc) could be displayed on a screen 22 at the user interface unit 20 at this stage. The user inserts his or her card into the card reader 21 and enters authorisation data (such as an associated pin number) via a physical or onscreen keyboard. The user interface unit 20 and payment processing system 30 then proceed to process the further transaction with an acquirer financial institution system 50 as is shown in Figure 2. This process is entirely separate to the transaction originating from the merchant 40 but does result in a valid payment being made to the merchant 40 to settle the original transaction. Once the further transaction is completed, authorisation data is passed back to the payment processing system 30 which then forwards this to the merchant's system 41 in order to reconcile the original transaction with a valid payment.

It will be appreciated that the processing of the further transaction is independent of the original transaction and does not involve the merchant 40. In this manner, the transaction can be processed securely and because the card is present at the user interface unit 20, it can be processed as a "card present" type transaction and avoid the penalties and surcharges associated with a card not present transaction. Furthermore, even if the unique payment identifier was copied or otherwise obtained by another party, if a payment was attempted to be made using the identifier, it would

automatically result in a query being passed to the user interface unit 20 for authorisation. A user can therefore rely on the fact that only transactions they authorise via their user interface unit 20 will ever be progressed for payment and their credit/debit card details need not be revealed to an unknown or untrusted merchant over the telephone or the internet. Advantageously, while it is of course desirable that the virtual credit or debit card number is kept secret, it would not be a security risk of the same level as revealing a genuine credit or debit card number in public. For example, there are situations where a payment needs to be made via an unsecured PC (for example at an internet cafe) or over the telephone on a crowded train. In these situations, the user can use the virtual card number in the knowledge that even if someone did overhear or capture the information, it is useless to them.

In a preferred embodiment of the present invention, the user interface unit 20 is tied to a location by a location authentication system or device that provides an assurance of the location of the location of the user interface unit 20 (and therefore the card where the further transaction is a credit card transaction) at the time of making the further transaction. One such system is the utility metering system described in WO 01/91073, the contents of which are incorporated herein by reference.

In this embodiment, the user interface unit 20 is arranged to require a unique identifier from the utility meter 60 in order to be able to submit the further transaction for payment. The user interface unit 20 and utility meter are arranged to communicate wirelessly within a predetermined limited range such that the unique identifier from the utility meter 60 can only be obtained whilst the user interface unit 20 is within a predetermined vicinity of the utility meter 60. This tethering means that if the user interface unit is stolen, it is rendered inoperable and any further transaction authorised from the user interface unit 20 can be guaranteed to have been performed at the location of the utility meter 60.

The user inserts a credit or debit card into the card reader device 21, which obtains the necessary card details including card number and expiry date. The user then enters an authorisation code associated with the card via the keypad. The user interface unit 20 communicates with the utility meter 60 to obtain the unique identifier. This is combined with data on the original transaction (such as merchant to be paid, merchant's ref) and details on the card to be charged to form an authorisation request. Preferably, parts or all of authorisation request are encrypted. The authorisation request is then passed via the payment processing system 30 to the acquirer financial institution system 50 for fulfilment.

An authorisation response message indicating success or failure of the authorisation request is returned to the user interface unit. This message may contain an authorisation code to be passed on to the product/service provider to indicate fulfilment of payment.

Figure 4 is a schematic diagram illustrating data flow in accordance with an embodiment of the present invention. Figures 5a-5e illustrate steps in the process of Figure 4 from the perspective of a user.

In step 100, data (acquired over the telephone or online (shown in Figure 5a)) is submitted by the merchant's system 40 to the billing server 42 of its supporting financial institution. The UN of the card number has been obtained from the banking authorities (in the same way a new financial network would register) and this registration associates the UN with a data processing system that in all likelihood will be formed from a network of servers but in this embodiment is illustrated by server 30. The billing server 42 cross-references the UN with its records and identifies the association of the UN with the payment processing system 30. The billing server 42 directs a query on the transaction (which may include or be based on some or all of the data received from the merchant) to the payment processing system 30 in step 110. Upon receipt of the query data, the payment processing system 30 checks its database to identify the user interface unit 20 that is associated with the virtual credit card number and transmits data in step 120 to the user interface unit 20 that causes an authentication query to be displayed in step 130, as is shown in Figure 5b. Assuming the transaction is genuine and the user wishes to make a payment, he or she inserts a valid credit or debit card into the user interface unit 20 in step 140 and enters the pin number (assuming the card is chip and pin type), as is shown in Figure 5c. This causes the further transaction to be submitted to the payment processing system 30 in step 150. The payment processing system 30 communicates with the acquirer financial institution system 50 in step 160 to cause payment for the same amount as the original transaction to the merchant but using the credit card details provided by the user in step 140. Success of the payment is communicated by the acquirer financial institution system 50 in step 170 to the payment processing system 30 which communicates this information on to the billing server 42 in step 180 and to the merchant's system 40 in step 190. Upon receipt of data indicating successful processing of the transaction, the merchant's system 40 causes fulfilment of the order. Assuming this was an online order and the user remained online between steps 100 and 190, the website could optionally display confirmation of success as shown in Figure 5e. It will be appreciated that principles of the authorisation system need not be used solely for payment transactions. For example, one embodiment of the present invention utilises a user interface unit 20 associated with a unique identifier. In a similar manner to the embodiments described above, the unique identifier is configured to cause an external system processing an authentication request which uses the unique identifier to transmit data querying the authentication request to user interface unit, said data including or identifying the unique identifier. However, the authentication request could, for example, be an authentication request for access to a secure website that would otherwise require a username and password or other challenge to be successfully completed. As with the payment authentication, the authentication request is redirected to the user interface unit 20 for validation by the user. Thus, even if the unique identifier was compromised, it could not be used to successfully access the external system without the user interface unit 20. As with the above described embodiments, the user interface unit 20 could be tethered to a particular location such as via a utility meter and be rendered inoperable if out of range of communication with the meter.

Optionally, the user interface unit 20 may be or may interface with a portable device such as a mobile telephone such that authentication may be performed anywhere. For example, in addition to or alternately to presenting the authentication query on screen at the user interface unit 20, the user interface unit 20 may establish a connection (which may optionally be secure, encrypted, authenticated by some authentication mechanism etc) with a mobile device such as a mobile telephone prompting the recipient to approve the transaction. The user approves the transaction at his or her mobile telephone via keypresses etc and this is communicated back to the user interface unit 20 which then progresses the transaction as previously described.

Authentication in the case of website access could simply be on a trust basis (ie instead of username/password credentials, authentication by a previously registered user interface unit 20 may be sufficient for the site to allow access) or it could be via the user interface unit 20 providing pre-stored credentials to the external system (such as previously registered username and password) upon approval of the authentication at the user interface unit 20.

Access to the external system for which authentication approval is sought could be from a remote device (such as a PC, mobile telephone etc) or it may be via a suitable web browsing client on the user interface unit 20 itself.