GB2493138A

GB2493138A - A system for secure payment transactions

Info

Publication number: GB2493138A
Application number: GB1112173.8A
Authority: GB
Inventors: Edwin Stark; Nigel Taylor
Original assignee: FLICK MOBILE Ltd
Current assignee: FLICK MOBILE Ltd
Priority date: 2011-07-15
Filing date: 2011-07-15
Publication date: 2013-01-30
Also published as: GB201112173D0

Abstract

A system for secure payment includes a client, for example installed on a mobile communication device, that stores a unique user ID number, a first encryption key and encrypted second ID number of an account such as a CVV2 for a bank account. A remote server stores an encrypted first ID number, such as a PAN, of the account and a second encryption key, both associated with the unique customer ID number. The client may send the first encryption key and encrypted second number to server, which decrypts both first and second ID number for communication to payment server. A registration system includes a client generating a first encryption key and encrypting a first ID number, and a server to which the client sends the first encrypted ID number and a second ID number. The server then stores the first encrypted ID number and generates and stores a second encryption key to encrypt the second ID number. The server then sends the encrypted second ID number for storage at the client.

Description

Secure Payment System

Technical Field

The present invention relates to a secure payment system, particularly a mobile phone payment platform that minimises the possibility for credit card fraud.

Background

Credit card fraud has become a significant problem in recent times, reaching a peak of over £600 million of fraudulent transactions in 2008 in the UK. Many instances of card fraud originate from call centres and websites where PCI (Payment Card Industry) standards are either not present or not adhered to. Call centres are particularly high risk due to the number of places card data can be found, e.g. on tapes of recorded conversations, internal systems, paper trails, etc. Card information is often available along with personal information depending on the nature of the call centre's relationship with the customer.

Internet based payment by credit card is now cormnonplace.

In an effort to reduce fraudulent activity so-called 3D" secure services are offered by credit card companies which transfer the liability for chargebacks to banks rather than vendors. A 3D (three domain) secure service will typically open a new browser window where a password is communicated directly to the card issuer for authorisation of the payment details already entered in a previous window. however, even such systems can be hacked or the card holder can be directed to a forged (i.e. non-authentic) pop-up window designed to obtain the secret password.

I

Summary of the Invention

The present invention seeks to provide an improved or at least alternative secure payment system, particularly exemplified for use with mobile "smart" phones or other communication devices where payment requests from a vendor can be authorised from the customer's phone and processed through established payment gateway services.

In its most essential form the invention is a system for secure payment transactions including a client that stores a unique user ID number, a first encryption key and encrypted second ID number of an account; and a server that stores an encrypted first ID number of the account and a second encryption key, both associated with the unique customer ID number.

In a further broad aspect the invention provides a secure payment system including: a client for receiving the input of a first and second identification (ID) number associated with a credit or debit account, said client generating a first encryption key and encrypting the first ID number, a server to which the client sends the encrypted first ID number and the second ID number, wherein said server stores the first encrypted ID number and generates and stores a second encryption key to encrypt the second ID number, whereupon the server sends the encrypted second ID number for storage by the client.

Preferably the server destroys the record of the second ID number, both encrypted and non-encrypted.

The server also generates or is provided a unique ID number which enables it to identify and communicate with the client. The unique ID number may be based upon the mobile telephone number of the smart phone on which the client is based.

Accordingly, the system results in a client (most preferably resident on a smart phone) that possesses a unique ID number, first encryption key and encrypted second ID number that it can later communicate with the server. The server stores the encrypted first ID number and the second key in a file associated with the unique ID number in addition to any other relevant personal information (name, address etc) it has been communicated by the client and may be required for payment transactions.

Preferably, to be PCI compliant, the first ID number is a PAN (Permanent Account Number) from a credit/debit card and the second ID number is a CVV2 (Card Verification Value) code from that same credit/debit card. In this way a record of the CVV2 number itself is never stored on the server.

It should be noted that, in theory, it is not critical where the encryption steps occur (i.e. it could be in one location; on the client or server) so long as the encrypted numbers and keys are distributed for end use according to the invention. However, it is supposed that a system performing all the encryption on the server and passing information back to the client is far less secure than the preferred method of the invention (although While the preferred system of the invention utilises a smart phone as the host of the client application, the general principles of the client aspect of the invention can be incorporated into any device remote from the server, i.e. a personal computer or any such mobile device that may become popular in the future.

The broad aspect of the invention described above is primarily a registration process (which could also be considered a series of method steps) undertaken before any transactions are attempted according to the invention.

In order to conduct a transaction it is intended that a vendor, usually following placement of an order by a customer via a website or even in person at a retail outlet as an alternative to using conventional electronic funds transfer at the point of sale, sends a request for payment via the server to the client, by virtue of the unique ID number (to identify the customer). The customer sees an alert, e.g. on their smart phone, and is able to authorise the transaction by supplying a PIN or password (which was set up during the registration process) . Presuming the request is accepted, the client sends the first encryption key and encrypted second ID number to the server which now has the required information to decode both ID numbers of the credit/debit account and process the transaction via a conventional internet payment gateway. Funds are preferably transferred to the bank acoount of the system service provider for later payment to the vendor as an accumulated amount following numerous transactions (to reduce bank fees) A practical advantage of implementing the invention is being able to use native smart phone technologies to overcome what was historically a challenge for payment service providers to ensure they were compliant with PCI standards. Specifically, each time a consumer interacts with payment gateways, they are required to supply their CVV2 number as part of the transaction, however, to be PCI compliant the CVV2 number cannot be stored anywhere.

The invention preferably utilises a smart phone device with the client installed to store the CVV2 number in an encrypted format and passes it into each transaction only when required. The server holds the key to the CJV2 number, which is used to decrypt the 0VV2 and pass the information along with other card data to the gateway for payment. This process is most relevant for a first transaction performed by the user, i.e. the card information is sent.

To simplify future transactions the gateway can respond with a card token, which can be passed instead of the card details. The next time a payment is made the card details do not need to be sent again, just a token and the CVV2 number.

The invention is also a payment-processing engine that can fully support 3D-secure measures established by credit card issuers, enabling the liability for chargebacks to be with the banks and not the vendors.

This is possible by simply enabling a 3D-secure message to pop up in a browser window on the phone to be completed by the user for communication with the card issuer.

The result is that users of the invention can now perform round-trip transactions for payment, authorised by the user through the client on the mobile phone, without the need to supply card data each time. A user does not even need to have a credir card with them because all relevant details are stored in the phone.

Furthermore, the invention is potentially a "5D" secure transaction-processing engine, i.e. it is 3D-secure if the user has registered their card for 3D secure, 4D-secure if the user has a PIN on their handset to access the operating system (as is common) and 5D-secure with the added layer of security required by the client for password authentication to authorise each transaction.

Using available technology it is also possible to track the exact geographical location of each transaction, timestamp, phone device used, network connected to, etc. All the foregoing features combine to reduce the possibility of fraud to a negligible level. It is never possible to eliminate risk entirely, e.g. someone being held at gun point to divulge all their details before stealing the smart phone, but the invention does enable substantial improvements in the most common situations where fraud occurs.

Brief Description of the Drawings

Figure 1 is a flow chart showing a preferred embodiment of the registration process according to the secure payment system of invention; Figure 2 is a flow chart showing a typical transaction according to the invention; Figure 3 is a flow chart showing data exchange for a transaction according to a non-3D secure embodiment of the invention; Figure 4 is a flow chart showing data exchange for a transaction according to a 3D-secure embodiment; and Figure 5 is a flow chart showing data exchange for a transaction according to a 3D-secure tokenised embodiment.

Mode(s) for Carrying out the Invention The invention is a system/method utilising client/server technology, wherein preferably the client is in the form of a smart phone application (or "app") . The server side of the invention is a hosted software solution that provides the processing power of the system.

All communication between the client and server is encrypted both in transit and in storage.

The method or system of the invention requires a registration process and then several options for completing a transaction. These will be discussed hereinafter with reference to the drawings that describe the most commonly anticipated use of the invention, i.e. a payment system reguiring a smart phone and a credit/debit card (with a PAN and CVV2) from the user in addition to the business infrastructure required for processing the transaction.

The registration process is illustrated by Figure 1. The below steps are required.

152) Registration is initiated by the user/customer following installation of the client application on a smart phone. The user is required to enter their personal information along with the information of at least one credit / debit card. At this stage a password or PTN is chosen by the user which is needed for each eventual transaction.

354) The client generates a new (e.g. l2Bbit AES -Advanced Encryption Standard) PAN key. The PAN key is the key used to encrypt the PAN number for storage on the server. The unencrypted instance of the PAN number is then destroyed and the PAN key stored on the client.

5) The client establishes a secure encrypted connection with the server and sends the users personal information along with the encrypted PAN number.

6) The server generates a new (e.g. l2Sbit AES) 0VV2 key.

Preferably a new CVV2 key is generated for every card registered with the system. The 0VV2 number is then encrypted and the unencrypted instance is destroyed.

7) The server then stores the cvv2 key, the encrypted PAN number and the user's personal information. A unique ID is generated or otherwise assigned for the newly registered user, e.g. a number incorporating the user's telephone number is inherently unique and more likely to be remembered so this would make a good unique ID.

8) The server then responds to the olient over a seoure and encrypted oonnection, providing/verifying with the client the unique ID for the user along with the encrypted CVV2 number.

9) The client now stores the encrypted CVV2 number and the unique ID in its local database alongside the PAN key.

Once registered a user is able to make transactions with vendors which utilise the system. A basic flow chart is illustrated by Figure 2 which has the following steps: 1) The vendor initiates the transaction, either by a smart phone or through a system that integrates with the system of the invention. The target user of the transaction will be specified by their unique ID.

2) The server validates the transaction and sends an alert to the user with the corresponding unique ID.

Preferably this is exemplified by an alert that will appear as a message window on a smart phone.

3) The user will see the pending transaction on the client application and be able to authorize the transaction by supplying the chosen PIN or password. The authorized transaction will be sent to the server for processing.

4) Once the server has received the authorized transaction, it will pass the user's credit/debit card details to the payment gateway to process the card details and take payment. At least at the first transaction this includes the decoded PAN and CVV2 numbers processed by the server.

5) Funds acquired by the Payment Gateway will be deposited into the service provider's bank account.

6) Every 4 days (by way of example only) , the service provider will automatically transfer the acquired funds to the vendor bank account.

An example of data transfer for a non 3D-secure payment is illustrated by Figure 3, wherein: 1) vendor initiates the transaction and supplies relevant transaction information. The information is transmitted over a secure and encrypted link to the server.

2) The server receives the transaction request from the vendor and sends a notification message to the client, as identified by the unique ID number.

3) The user sees the notification of the transaction and chooses to authorize or cancel.

4) For authorised transactions, the client sends the PAN Key, encrypted CVV2 number, the user's unique ID and a session ID (for traceability) 5) The server decrypts the PAN and CVV2 and sends the information to the gateway. Preferably, if the transaction is successful, a gateway token for those card details is returned to the server, which is stored for future transactions. Any unencrypted 0vv2 and PAN data is then destroyed.

6) The server then notifies the user and vendor of the transaction status.

An example of data transfer for a 3D-secure payment is illustrated by Figure 4, wherein: 1) Vendor initiates the transaction and supplies relevant transaction information. The information is transmitted over a secure and encrypted link to the server.

2) The server receives the transaction request from the vendor and sends a notification message to the client.

4) For authorised transactions, the client sends the PAN Key, encrypted CVV2 number, the unique ID and a session ID.

5) The server decrypts the PAN and CVV2 and sends the information to the payment gateway. If the transaction is successful, a gateway token for the card details is returned to the server, which is stored for future transactions. Any unencrypted CVV2 and PAN data is then destroyed.

6) The user is requested to enter their 3D secure information associated with the card by the card issuer.

7) The server then notifies the user and vendor of the transaction status.

An example of data transfer for a 3D-secure payment (once a token has already been generated) is illustrated by Figure 5, wherein: 1) Vendor initiates the transaction and supplies relevant transaction information. The information is transmitted over a secure and encrypted link to the server.

3) The user sees the notification of the transaction and chooses to authorize or cancel by entering their password/PIN. The user may also select a preferred debit/credit card if there are multiple cards to choose from.

4) For authorised transactions, the client sends the encrypted CVV2 Number (of the chosen card), the users unigue ID and a session ID.

5) The server decrypts the CVV2 and sends the information along with the previously stored card token to the gateway. Any unencrypted CVV2 and PAN data is then destroyed.

6) The user is requested to enter their 3D secure information associated with the card.

7) The server then notifies the user and vendor of the transaction status.

It will be apparent that, once implemented, the system of the invention will save considerable time for making card payments, and not necessarily limited to internet based transactions. Payment via a smart phone where card details are stored can be processed by any vendor registered with the system, e.g. at a restaurant where payment can be made in response to a reguest sent by the restaurant.

It is envisaged that the client will keep a "safe list" of vendors that have been deemed worthy of sending payment requests, to avoid a vendor sending unsolicited payment requests. f this were to occur then a vendor can be "blocked" in a similar way to e-mail spam.

In general, if a vendor is not known to a user then the transaction will appear in a "vendor-to-be-approved" list.

The user can then accept the vendor into the safe list, particularly if it is a service which will be used frequently.

Claims

<claim-text>What We Claim Is: 1. A system for secure payment transactions including: a client that stores a unique user ID number, a first encryption key and encrypted second ID number of an account; and a server that stores an encrypted first ID number of the account and a second encryption key, both associated with the unique customer ID number.</claim-text> <claim-text>2. The system of claim 1 wherein, upon receipt of a request for payment from a vendor to the client's unique user ID number, the client sends the first encryption key and encrypted second ID number to the server which decrypts both the first and second ID number for communication to a payment server for transferring funds.</claim-text> <claim-text>3. A secure payment registration system including: a client for receiving the input of a first and second identification (ID) number associated with a credit or debit account, said client generating a first encryption key and encrypting the first ID number, a server to which the client sends the encrypted first ID number and the second ID number, wherein said server stores the first encrypted ID number and generates and stores a second encryption key to encrypt the second ID number, whereupon the server sends the encrypted second ID number for storage by the client.</claim-text> <claim-text>4. The secure payment registration system of claim 3 wherein the server destroys its record of the second ID number, both encrypted and non-encrypted, after it has sent the second encrypted ID number to the client.</claim-text> <claim-text>5. The system of any of the preceding claims wherein the client is hosted on a mobile phone.</claim-text> <claim-text>6. The system of any of the preceding claims wherein, in use, the first ID number is an account number (e.g. PAN) and the second TD number is a verification number (e.g. C\JV2), both from the same credit/debit card.</claim-text> <claim-text>7. The system of claim 2 wherein a token is generated by the payment server to replace the first ID number in future transactions.</claim-text> <claim-text>8. A system fo r secure payment transactions substantially as herein described with reference to the accompanying drawings.</claim-text>