GB2475301A

GB2475301A - Payment Authentication System and Processing Method

Info

Publication number: GB2475301A
Application number: GB0919916A
Authority: GB
Inventors: Michael Jarman
Original assignee: Secure Electrans Ltd
Current assignee: Secure Electrans Ltd
Priority date: 2009-11-13
Filing date: 2009-11-13
Publication date: 2011-05-18
Also published as: GB0919916D0; WO2011058376A1

Abstract

A payment authentication system and processing method are disclosed. The system (10) includes a user interface unit (20) and a payment processing system (30). The payment processing system (30) is associated with a unique payment identifier which preferably is in a valid credit card number format, but is a virtual credit card number rather than an actual credit card number. The unique payment identifier is configured to cause an external system (40), associated with a merchant, processing a first transaction which uses the unique payment identifier to transmit data querying the transaction to the payment processing system (30), the data including or identifying the unique payment identifier. Upon receipt of data querying the transaction, the payment processing system (30) is arranged to communicate with the user interface unit (20) to obtain authorisation for the payment of the transaction. The payment can then be made if authorisation is made. The user interface unit preferably has a card reader, the card being charged via a further transaction which the external system (40) of the merchant is not a party to. The invention allows "card present" transactions to be made by online retailers.

Description

Authorisation system and method

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 percentage 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.

These transaction are referred to as card not present" transactions in the financial payment industry. In making an 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 cards account. The merchant is accountable for the verification and authentication of the card and the validation of the cardholders 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. Another 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, some merchants will only deliver to the address registered with the customers 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.

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 of transactions across the Internet, even if encrypted, has resulted in many financial problems 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 of 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 in order 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 against the card issuer/merchant. In order to cover themselves against losses and overheads from dealing with these fraudulent transactions the 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.

Detailed Description

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.

The payment authentication system associates a virtual credit or 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, 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 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 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. 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.

For all intents and purposes, the merchant sees the unique payment identifier as a valid format credit or debit card number. However, 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 pointing 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.

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 REID 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 on-screen keyboard.

The user interface unit 20 and payment processing system 30 then proceed to process a 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.

In a preferred embodiment of the present invention, the user interface unit 20 is tied to a utility metering system in the manner described in WO 01/91073, the contents of which are incorporated herein by reference.

In particular, 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 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.

The figures following figure 3 illustrate an online purchase from the perspective of a user.

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.

Claims

Claims 1. 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 transaction which uses the payment identifier to transmit data querying the transaction to the payment processing system, said data including or identifying the payment identifier, wherein upon receipt of data querying the transaction, the payment processing system is arranged to communicate with the user interface unit to obtain authorisation for payment of the transaction, and upon obtaining authorisation for payment of the transaction, the payment processing system being arranged to effect payment of the transaction.
2. A payment authentication system according to claim 1, wherein the user interface unit includes a card reader and the payment processing system is arranged to effect payment of the transaction by charging a credit or debit card inserted into the card reader.
3. A payment authentication system according to claim 2, wherein the payment processing system and/or the user interface unit is arranged to charge said credit or debit card via a further transaction, the further transaction being with a financial institution, wherein the external system is not party to processing of the further transaction.
4. A payment authentication system according to claim 2 or 3, wherein the payment authentication system is arranged to substitute the unique payment identifier at the external system with data on the charged credit or debit card.
5. A payment authentication system according to any of claims 1 to 4, wherein the user interface unit is configured to only enable authorisation for payment of a transaction at, or within a predetermined range of, a predetermined location.
6. A payment authentication system according to claim 5, further comprising 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.
7. A payment authentication system according to any preceding claim, comprising 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.
8. 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.
9. An authentication system according to claim 8, wherein the external system 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.