GB2457337A

GB2457337A - Processing a payment using a portable communications device

Info

Publication number: GB2457337A
Application number: GB0802437A
Authority: GB
Inventors: Timothy Corke; Michael O'shea; John Kennard; Roger Norman
Original assignee: TRACKTECH Ltd
Current assignee: TRACKTECH Ltd
Priority date: 2008-02-09
Filing date: 2008-02-09
Publication date: 2009-08-19
Also published as: GB0802437D0

Abstract

A method of processing a payment using a portable communications device includes obtaining user identification data from a portable communications device and a device identifier from the portable communications device. The method checks the authenticity of the user identification data and obtains an authenticated device identifier associated with the user identification data. The method compares the device identifier obtained from the portable communications device with the authenticated device identifier, and if the device identifier comparison is favourable, allows processing of a payment relating to a transaction specified on the portable communications device.

Description

I

Processing a Payment Using a Portable Communications Device The present invention relates to processing a payment using a portable communications device.

It is commonplace to process credit/debit card payments in stores, restaurants and the like. The process normally involves the customer's card being swiped in a suitable machine, which may be fixed adjacent a till/cash register or the like, or it may be a portable device specifically designed for swiping cards. In the example of a payment in a restaurant, the portable swiping device is often bought to the customer's table for swiping the card and to allow the customer to enter his/her PIN number. The device then communicates the card and PIN details to a modem situated on the premises that, in turn, transfers them to a remote payment processing centre for authentication and completing the transaction.

The present inventors have identified situations where this arrangement can be disadvantageous. In particular, sales agents who visit customers' premises do not conventionally carry portable card-swiping machines as many such devices cannot operate without a compatible modem. The cost of providing devices capable of full wireless operation to sales personnel can be prohibitive. Further, the devices become more susceptible to theft or loss if they are regularly carried around customers' premises by sales agents.

Embodiments of the present invention are intended to address at least some of the abovementioned problems.

According to a first aspect of the present invention there is provided a method of processing a payment using a portable communications device, the method including: obtaining user identification data from a portable communications device; obtaining a device identifier from the portable communications device; checking authenticity of the user identification data; obtaining an authenticated device identifier associated with the user identification data; comparing the device identifier obtained from the portable communications device with the authenticated device identifier, and if the device identifier comparison is favourable, allowing processing of a payment relating to a transaction specified on the portable communications device.

The method will normally include obtaining payment card (or account) details using the portable communications device and transferring the details to a payment authentication centre. The details may be transferred to the payment authentication centre using a secure communications channels, e.g. multiple X.25 communications channels. At least some of the details relating to the transaction may not be stored on (or deleted from) the portable communications device after the transaction has been completed. The details may be obtained by entering via a keyboard/keypad (or other standard/built-in user interface) of the portable communications device.

The payment authentication centre may communicate with a banking system in order to perform the step of checking authenticity of the user identification data and/or the device identifier comparison step.

The payment processing may include a bank making a payment (from an account associated with a customer associated with the transaction) to the payment authentication centre. The payment processing may further include the payment authentication centre making a payment to a merchant associated with the transaction.

If the device identifier companson is not favourable then the method can include preventing the processing of the payment and/or displaying a payment rejection message on the portable communications device andlor generating a security alert.

The device identifier may comprise an International Mobile Equipment Identity (IMEI).

The method may further include selecting at least one product (or other item/service) for inclusion in the transaction.

According to another aspect of the present invention there is provided a computer program product comprising computer readable medium, having thereon computer program code means, when the program code is loaded, to make the computer execute a method of processing a payment using a portable communications device substantially as described herein.

According to another aspect of the present invention there is provided a system configured to execute a method substantially as described herein.

According to another aspect of the present invention there is provided a portable communications device adapted to perform a method substantially as described herein. According to yet another aspect of the present invention there is provided a payment authentication centre adapted to perform part of a method substantially as described herein in conjunction with the portable communications device.

According to a further aspect of the present invention there is provided a portable communications device having a device identifier, the device including: a component configured to obtain user identification data; a component adapted to check authenticity of the user identification data; a component adapted to compare the device identifier of the portable communications device with an authenticated device identifier associated with the user, wherein if the device identifier comparison is favourable, allowing processing of a payment relating to a transaction specified on the portable communications device.

The portable communications device may be a wireless handheld device with relatively limited computing power compared with a general-purpose computing device (e.g. a general-purpose laptop/notepad computer). An example of a suitable portable communication device is as a Blackberry (TM) device, produced by Research In Motion of Ontario, Canada. However, other devices, such as mobile telephones with some computing capability could be used. The portable communications device will not normally require additional hardware (e.g. a swiping device) in order to obtain card details.

According to another aspect of the present invention there is provided a (at least partially computer-implemented) method of processing transactions, the method including: authenticating an identity of a user of a portable communications device; authenticating an identity of the portable communications device; setting up a transaction using the portable communications device; verifying payment information obtained using the portable communications device, and allowing the transaction to be performed if the user identity is authenticated, and if the portable communications device identity is authenticated, and if the payment information is verified.

The payment verification information may be transferred to a payment processing centre that performs the payment information verification. The method may include the payment processing centre providing a payment due to a merchant entity as a result of the transaction set up using the portable device.

The method may include providing a database of goods and/or services on the portable communications device. The goods/service database may be provided by the merchant entity. The method may include allowing an entity with access to the payment processing centre to collect monies resulting from the transaction under Assignment of Debt provisions in order to transfer at least part of the monies to the merchant entity. The method may include awarding a commission relating to the completed transaction to the user of the portable communications device.

Whilst the invention has been described above, it extends to any inventive combination of features set out above or in the following description. Although illustrative embodiments of the invention are described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to these precise embodiments. As such, many modifications and variations will be apparent to practitioners skilled in the art.

Furthermore, it is contemplated that a particular feature described either individually or as part of an embodiment can be combined with other individually described features, or parts of other embodiments, even if the other features and embodiments make no mention of the particular feature. Thus, the invention extends to such specific combinations not already described.

The invention may be performed in various ways, and, by way of example only, embodiments thereof will now be described, reference being made to the accompanying drawings in which: Figure 1 is a schematic illustration of an example of the payment processing system.

The example system shown in Figure 1 includes a portable communications device 101. In the example, the portable communications device comprises a wireless handheld device with relatively limited computing power rather than a general-purpose computing device. Suitable portable communication devices include the Blackberry range of devices, produced by Research In Motion of Ontario, Canada. However, other devices, such as widely-available mobile telephones having some computing capability could be used. The device 101 includes, amongst other components, a processor lOlA, internal memory IOIB and a wireless communications interface IOIC. The processor and memory can be configured to execute code for cooperating with other elements of the system as described herein.

The system further includes a payment processing centre 103. The centre 103 can include at least one computing device 302 configured to provide an Internet Card Processing (ICP) service. Various types of ICP services are publicly available, e.g. www.worldpay.com, and so this aspect need not be described here in detail. In the example, the centre 103 communicates with at least one banking system 105 in order to perform certain steps, e.g. clearing a credit/debit card payment, but it will be understood that in other embodiments the portable device 101 may communicate directly with a banking system in order to perform at least some of these steps.

In the illustrated embodiment, the payment processing centre operates so as to collect payments due to a merchant (illustrated schematically at 107) as a result of sales of goods by the merchant due to transactions set up using the portable device. In a typical example, the merchant can be a trading body (e.g. a retailer providing goods/services from a catalogue) having agents (e.g. sales representatives) to whom portable communications devices are provided. The agents can visit customers' premises and assist with selecting products from a catalogue (illustrated schematically at 109), for example. It will also be apparent that other type of users could also benefit from versions of the system, e.g. debt collection agents.

An example of a typical transaction involving processing a payment using the system will now be described, It will be understood that the following description is exemplary only and in some cases the steps may be performed in a different order and/or some of the steps may be omitted. It will also be understood that in variations of the system, some of the process steps could be performed on different devices to the ones specified in the example.

The operation can begin with step 200, where a user (e.g. a sales agent representing a catalogue retailing company) of the portable communications device 101 logs on to an application (coded as a Java appletTM or the like) running on the device 101 that allows him/her to perform transactions using the system. This will normally involve the user entering a username and password, or perform any other type of software and/or hardware-based authentication procedure. When the user clicks on an icon (that can have the appearance of a conventional desktop shortcut) to launch the transaction application, the application triggers an action of which the user will normally be unaware. When the user arrives at the login screen the details they enter will be compared with the details stored in a database about the device itself.

In more detail, the transaction application executing on the device 101 compares the login information with a record stored in a database 101 D. If the login information entered does not match an authorised user's login information then an alert may be generated and/or the transaction is aborted. The transaction application also checks whether a unique identifier associated with the device 101 itself corresponds with the device identifier expected to the associated with the authorised user. The device identifier may comprise the IMEI of the device that is hard-wired into its circuitry. Alternatively or additionally, another identifier, e.g. one stored at a reserved location in the memory of the device, could be used.

If this device identity check is not positive then the transaction may be aborted at this stage and/or an alert message may be sent to personnel at the payment processing centre and/or the relevant bank. This device authentication may be performed each time a payment request is made, or it may be performed less frequently, e.g. only when the user first logs onto the device. This additional check based on the identity of the hardware device, as well as confirming the user's login details, means that any given user is only able to process payments using the particular device that has been properly assigned to him/her. Thus, if the security of the user's login details are compromised (e.g. lost) then an unauthorised party trying to use them would be unable to do so successfully on any device other than the particular device having the unique identifier. In other embodiments the database 104 may be stored remotely from the device 104 and the check may also take place remotely.

At step 202 the user creates an order using the portable communications device 101. This can be done in various ways. For example, the device 101 may store a database of products in its internal memory. Alternatively, the device 101 may communicate over a network/the Internet with a remote system containing a database (e.g. catalogue 109), in which case data relating to a selected product, e.g. availability and/or estimate delivery time, etc. may be transferred (step 204) back to the device 101 so that the user can communicate this to the customer.

The database may be hosted by the provider of the transaction processing application executed on the device 101, in which case the merchant who operates the database may be enabled to update the database as necessary.

An order reference may be created that can provide a unique reference to the order and the user creating the order. The order reference number and associated details may also be transferred to the merchant at this stage. An image or further details of the product may also be displayed on the screen of the device 101 at this point. This process may be repeated if more than one item is being purchased. Various well known purchasing user interfaces can be used, e.g. a shopping basket and checkout procedure.

When the selection of the item(s) to be purchased has been completed the customer is asked for payment information. This will typically involve the customer being handed the device 101 in order to personally enter his/her card details, or the customer may read them out to the user who enters them onto the device 101. The card details will normally include the number set out across the front of the card, a security/CV2 code and an expiry date. Further details may be needed, as required by the ICP service, such as the name and the address of the cardholder. Additional contact details, e.g. at least one telephone number and/or email address may also be collected and stored by the system at this time. It will be noted that all of the relevant card information can be entered directly onto the device 101 without requiring any additional hardware such as a swiping device. The application may detect missing information, e.g. card expiry date, and request that this be entered before proceeding further.

At step 206 the card details that have been entered are transferred to the payment processing centre 103. This will normally involve high security measures, such as the details being encrypted and transferred via a dedicated communication channel. For instance, in order to ensure a reliable high speed authorisation service the ICP solution can utilise multiple X.25 communications channels. The X.25 network is a fast and secure means for online authorisation of cards and typically the authorisation process can take less than a second per transaction. All the details may be replicated on several, e.g. four, transaction channels, each of which will be linked, enabling the service to load-balance as well as provide high levels of resilience. Once data has been sent from the device using these channels, at least some of the data relating to the transaction (e.g. the card details) will not be stored on the device itself, and if any such data was temporarily stored on the device then it will be deleted. This improves security, e.g. by preventing unauthorised access to the details by using the "back" facility on the browser.

Upon receipt of the card processing details by a computing device 302 located at the payment processing centre 103 the computing device 302 communicates (step 208) with a computer at the relevant bank 105. In one implementation of the system, at least part of the system may be run by a company or other entity that effectively collects monies resulting from the transaction under Assignment of Debt documentation for a merchant entity that sells the product ordered.

At step 210 the banking system replies to the centre computer with an indication of the authenticity of the card, which enables the centre computing device 302 to provide a decision on whether or not the transaction has been approved or rejected.

Along with the card details transferred to the payment processing centre 103, the transaction application executing on the device 101 also transfers the user's login information. Before authorising the card payment, the computing device 302 compares the login information with records stored in a database 304. If these do not match an authorised user's login information then an alert may be generated and/or the transaction is aborted.

In some cases if the card is rejected then the transaction processing application may be configured to allow the customer to provide details of another card.

Steps 214, 216 and 218 show how the system can be specifically configured to deal with sales agents representing a merchant company. At step 214 a payment corresponding to the amount of the transaction being processed is made to a body associated with the payment processing centre 103. At step 216 that body then transfers an appropriate payment to the merchant (possibly deducting a commission). In some cases (step 218) the merchant makes a payment to an account associated with the user of the device 101, e.g. a sales commission to an agent. It will be understood that in other situations the payment arrangement can vary, for example, the payment centre may make a direct payment to a user of the device.

Claims

CLAIMS1. A method of processing a payment using a portable communications device, the method including: obtaining user identification data from a portable communications device; obtaining a device identifier from the portable communications device; checking authenticity of the user identification data; obtaining an authenticated device identifier associated with the user identification data; comparing the device identifier obtained from the portable communications device with the authenticated device identifier, and if the device identifier comparison is favourable, allowing processing of a payment relating to a transaction specified on the portable communications device.
2. A method according to claim 1, further including obtaining payment card (or account) details using the portable communications device and transferring the details to a payment authentication centre.
3. A method according to claim 2, wherein the details are transferred to the payment authentication centre using a secure communications channels, e.g. multiple X.25 communications channels.
4. A method according to claim 2 or 3, wherein at least some of the details relating to the transaction are not be stored on (or are subsequently deleted from) the portable communications device after the transaction has been completed.
5. A method according to any one of claims 2 to 4, wherein the details are obtained by entering via a keyboard/keypad (or other standard/built-in user interface) of the portable communications device.
6. A method according to any one of the preceding claims, wherein the payment authentication centre communicates with a banking system in order to perform the step of checking authenticity of the user identification data and/or the device identifier comparison step.
7. A method according to any one of the preceding claims, wherein the payment processing includes a bank making a payment (from an account associated with a customer associated with the transaction) to the payment authentication centre.
8. A method according to claim 7, further including the payment authentication centre making a payment to a merchant associated with the transaction.
9. A method according to any one of the preceding claims, wherein if the device identifier comparison is not favourable then the method includes preventing the processing of the payment and/or displaying a payment rejection message on the portable communications device and/or generating a security alert.
10. A method according to any one of the preceding claims, wherein the device identifier comprises an International Mobile Equipment Identity (IMEI).
11. A method according to any one of the preceding claims, further including selecting at least one product (or service) for inclusion in the transaction.
12. A computer program product comprising computer readable medium, having thereon computer program code means, when the program code is loaded, to make the computer execute a method of processing a payment using a portable communications device according to any one of the preceding claims.
13. A system configured to execute a method according to any one of the preceding claims.
14. A portable communications device having a device identifier, the device including: a component configured to obtain user identification data; a component adapted to check authenticity of the user identification data; a component adapted to compare the device identifier of the portable communications device with an authenticated device identifier associated with the user, wherein if the device identifier comparison is favourable, allowing processing of a payment relating to a transaction specified on the portable communications device.
15. A device according to claim 13, wherein the portable communications device comprises a wireless handheld device, e.g. a Blackberry (TM) device, having relatively limited computing power compared with a general-purpose computing device (e.g. a general-purpose laptop/notepad computer).
16. A method of processing transactions including: authenticating an identity of a user of a portable communications device; authenticating an identity of the portable communications device; setting up a transaction using the portable communications device; verifying payment information obtained using the portable communications device, and allowing the transaction to be performed if the user identity is authenticated, and if the portable communications device identity is authenticated, and if the payment information is verified.
17. A method according to claim 16, wherein the payment verification information is transferred to a payment processing centre that performs the payment information verification.
18. A method according to claim 17, including the payment processing centre providing a payment due to a merchant entity as a result of the transaction set up using the portable device.
19. A method according to claim 16, including providing a database of goods and/or services on the portable communications device.
20. A method according to claim 19, wherein the goods/service database is provided by the merchant entity.
21. A method of processing a payment using a portable communications device substantially as described herein and/or with reference to the accompanying drawings.
22. A portable communications device configured substantially as described herein and/or with reference to the accompanying drawings.