GB2478304A

GB2478304A - Secure financial transaction for gift voucher system

Info

Publication number: GB2478304A
Application number: GB1003461A
Authority: GB
Inventors: Raj Krishnamurthy
Original assignee: ENRIA Ltd
Current assignee: ENRIA Ltd
Priority date: 2010-03-02
Filing date: 2010-03-02
Publication date: 2011-09-07
Also published as: GB201003461D0

Abstract

The invention relates to a method and apparatus for performing a secure financial transaction utilizing gift vouchers provided to mobile phones. The method comprises server apparatus 107 sending a first message including a first identifier and data indicative of a first quantity of currency to a mobile telephone 141. The server apparatus receives from a retailer terminal 104,105 a message including a mobile telephone number, an identifier and a transaction value. The retail terminal may determine from the received identifier whether the transaction value is less than the value of the voucher, and if not, refrains from sending a message to the server. The server apparatus then determines, from a database record 130, whether the received identifier is valid and is assigned to the received mobile telephone number. The server apparatus validates a transaction to the transaction value, and confirms the transaction to the retailer terminal. The server apparatus then sends a second message to the mobile telephone 141, the second message including a second identifier, the second identifier being different to the first identifier, and a value indicative of a second quantity of currency, the second quantity of currency being equal to or less than the first quantity of currency minus the transaction value.

Description

Secure Financial Transactions

Field

This invention relates to methods and apparatuses for performing secure financial transactions.

Background

It is known to conduct a financial transaction using a mobile or cellular telephone. Various service offerings exist. It is known, for instance, to purchase automotive fuel using a mobile telephone, with the cost of purchase being added to the user's monthly account. It is known also to transfer funds to non-business users, for instance using the PayPal MobileTM service. All of the available service offerings have shortcomings. Challenges for service providers include providing sufficient security for users, minimising the potential for fraud etc., all of which has to be balanced with providing a service that is easy to use and understand.

The invention was made in this context.

Summary

In accordance with a first aspect of the invention there is provided a method of performing a secure financial transaction, the method comprising, in sequence: a) server apparatus composing a first message comprising a first identifier and data indicative of a first quantity of currency; b) the server apparatus addressing the first message to a mobile telephone by way of a telephone number associated with the mobile telephone; c) sending the first message to the first mobile telephone; d) the server apparatus receiving from a retailer terminal a message including an identifier, a mobile telephone number and a transaction value; e) the server apparatus determining from a database record whether the so received identifier is valid and has been assigned to the received mobile telephone number; in response to e), the server apparatus validating a transaction to the transaction value, and confirming validation of the transaction to the retailer terminal; g) the server apparatus composing a second message comprising a second identifier, the second identifier being different to the first identifier, and a value indicative of a second quantity of currency, the second quantity of currency being equal to or less than the first quantity of currency minus the transaction value; and h) the server apparatus addressing the second message to the mobile telephone by way of the telephone number for sending to the first mobile telephone.

Using this method, a financial transaction can be deemed to be secure by confirming from the database at the server apparatus that the received message from the retailer terminal contains an identifier that is valid and is assigned to the received mobile telephone number. This feature reduces the possibility of fraud, in particular because the identifier (that is needed to complete the transaction) is needed to be sent only to the mobile telephone of the recipient (and so may not be known by others). Even if a third party obtained the identifier, they would not be able fraudulently to use it unless they also had access to the mobile telephone number. This further increases security.

An advantage of this method is the fact that a transaction can be performed using only a single message sent from the retailer terminal to the application server and a single message being sent from the application server to the retailer terminal. Since the sending of messages can increase the time taken to complete a transaction, minimising the number of messages required can reduce transaction time. It can also improve customer experience and reduce use of retailer resources.

The method may additionally comprise: j) the retailer terminal requiring entering of a verification number by a user, the verification number not being present in the first message, k) the retailer terminal sending the verification number to the server apparatus with the mobile telephone number, the identifier and the transaction value, and 1) the server apparatus validating the transaction only if the verification number received from the retailer terminal matches a verification number associated at the server apparatus with the mobile telephone number.

This can provide additional security. With these features, availability of the identifier and the telephone number are not sufficient for a third party fraudulendy to complete a transaction.

The method may comprise, prior to a), m) the server apparatus receiving a voucher request message from the mobile telephone requesting to redeem a voucher, and n) the server apparatus using a ctlling line identifier associated with the message to identify a record in a database that corresponds with the voucher request message, and wherein b) comprises the server apparatus addressing the first message to the mobile telephone by way of the telephone number stored in the database record.

Alternatively the method may comprise, prior to a), o) the server apparatus sending an introduction message to the mobile telephonc p) the server apparatus subsequently receiving a delivered receipt message from the mobile telephone network operator, and q) the server apparatus using a ctlling line identifier associated with the delivered receipt message to identify a record in a database that corresponds with the voucher request message, and wherein b) comprises the server apparatus addressing the first message to the mobile telephone by way of the telephone number stored in the database record.

In either case, improved security can be experienced. In particular, the features can allow the application server to ensure that a user is provided with the identifier (needed to complete a transaction) if the mobile telephone is pre-authenticated.

Step g) may be performed in response to the server apparatus receiving a redeem message from the mobile terminal.

The data indicative of a first quantity of currency may comprises an integer that is equal to the quantity of currency divided by a predetermined increment. This feature can allow a retailer terminal to perform an initial assessment as to whether the transaction value may exceed a maximum allowed transaction value. This can allow the retailer terminal to prevent a request for validation being sent in some situations where the transaction could not be completed successfully, potentially reducing use of retailer resources and/or utilisation of communication link or server resources.

The data indicative of a first quantity of currency may comprise first and second components, the first component comprising a first integer and the second component comprising a second integer, wherein the first and second integers are selected such that the quantity of currency is defined as the sum of the first integer multiplied by a first predetermined increment and the second integer multiplied by a second predetermined increment. This can allow a maximum transaction value not to be restricted to a value that is an integer multiple of the first predetermined increment. This can increase flexibility of the system, and has potential to increase convenience for users and retailers.

The server apparatus may receive the message including a mobile telephone number, an identifier and a transaction value via a connectionless communication, and may confirm validation of the transaction to the retailer terminal via a connectionless Jo communication. This can allow operation without the need for permanent or temporary connections between the retailer and the server apparatus.

Step I) may comprise: Li) the server apparatus pre-validating a transaction to the transaction value, and confirming pre-validation of the transaction to the retailer terminal; and £2) completing the transaction in response to receiving a transaction complete confirmation message from the retailer terminsl, or cancelling the transaction in response to receiving a transaction cancellation message from the retailer terminal.

These features can aliow a voucher to be used to settle part of the total amount of a transaction whilst allowing the transaction at the server to be completed only if the transaction i completed at the retailer.

The retailer terminal may determine from the identifier whether the transaction value is exceeded by an amount of currency that corresponds to a currency value of the voucher, and in the even to a negative determination refraining from sending the message including the mobile telephone number, the identifier and the transaction value. This can aliow the retailer terminal to prevent a request for validation being sent in some situations where the transaction could not be completed successfully, potentially reducing use of retailer resources and/or utilisation of communication link or server resources.

According to a second aspect of the invention there is provided computer apparatus configured by one or more computer programs topo in sequence a method comprising: a) composing a first message comprising a first identifier and data indicative of a first quantity of currency; b) addressing the first message to a mobile telephone by way of a telephone number associated with the mobile telephone; c) sending the first message to the first mobile telephone; d) receiving from a retailer terminal a message including an identifier, a mobile telephone number and a transaction value; e) determining from a database record whether the received identifier is valid and is assigned to the received mobile telephone number; in response to e), validating a transaction to the transaction value, and confirming validation of the transaction to the retailer terminal; g) composing a second message comprising a second identifier, the second identifier being different to the first identifier, and a value indicative of a second quantity of currency, the second quantity of currency being equal to or less than the first quantity of currency minus the transaction value; and h) addressing the second message to the mobile telephone by way of the telephone number for sending to the first mobile telephone.

Brief Description of the Drawings

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic drawing of a system in which embodiments of the present invention are implemented; Figure 2 is a schematic drawing illustrating stages of a process for a sender purchasing and sending funds according to an embodiment of the present invention; Figure 3 illustrates stages of a process for a sender buying funds for sending at a later stage; Figure 4 illustrates stages in a process for a recipient requesting a voucher for funds from a service provider according to embodiments of the invention; Figure 5 illustrates stages in a process for a recipient redeeming a voucher of funds according to embodiments of the invention; Figure 6 illustrates a voucher code; Figure 7 is a flowchart illustrating redeeming part of a voucher of funds according to other embodiments of the invention.

Detailed Description Of Embodiments

Referring firstly to Fig 1, a system 100 comprises of a payment communications network 101 that connects payment terminals of first and second merchants 104, 105 to process card payments. Two different types of merchants are shown here to illustrate two popular variations in prevalent payment communications systems. The first merchant 104 has various stores, that could be at different locations. Each store may have one or many Electronic Point of Sale (ePOS) Systems. These systems have PIN Entry Devices (PED) 111, 112, 113, and 114, each of which is integrated with a respective ePOS terminal 116, 117, 118 and 119. The PEDs 111-114 and the ePOS terminals 116-119 may be connected through a common Local Area Network 102, which connects to the payment communications network 101 through an Internet connection 150. The second merchant 105 is an example of a smaller operation with one store that has a card processing terminal 161 which is standalone to an ePOS terminal 126. The card processing terminal 161 connects to the payment communications network 101 through a phone connection 151.

The payment communications network 101 connects to plural acquiring banks 109, 110 and routes card payment requests to the one of the acquiring banks 109, 110 that provides services to the merchant 104, 105.

A first customer or user is denoted at 108. The first customer has a mobile or cellular phone 140, and has access to a user terminal 133. The user terminal 133 may for instance be a personal computer or such like. The mobile telephone 140 may take any suitable form. The mobile telephone 140 has the ability to send and receive messages in text form, in this embodiment in particular short message service (SMS) messages. The mobile telephone 140 is operable to communicate via second and third generation mobile telephone communication protocols. The mobile telephone 140 may alternatively or in addition be configured to operate according to fourth generation mobile telephone communication protocols.

A second customer or user has a second mobile or cellular phone 141. The mobile telephone 141 may take any suitable form. The second mobile telephone 141 has the ability to send and receive messages in text form, in this embodiment in particular SMS messages. The mobile telephone 141 is operable to communicate via second and third generation mobile telephone communication protocols. The mobile telephone 141 may alternatively or in addition be configured to operate according to fourth generation mobile telephone communication protocols.

The user terminal 133 is connected to the Internet 106 by a communication link 156, which may take any suitable form.

The first mobile telephone 140 and the second mobile telephone 141 are connected to an SMS server 132 by respective communication links 162, 163. The communication links 162, 16 are radio links, that are provided by a mobile network operator (MNO). The first mobile telephone 140 is associated in this example with a sender and the second mobile telephone 141 is associated with a recipient.

A GIFTxt application server 131 is provided, in order to provide a service termed GIFTxt in this specification. Details of the service will be apparent from the below description.

The GIFTxt application server 131 is provided in association with a database server 130.

The GIFTxt application server 131 is in communication with the SMS server 132. The GIFTxt application server 131 and the database server 130 are maintained by a GIFTxt service provider, indicated at 107 in the figure. The GIFTxt application server 131 is connected to the SMS server 132 by a communication link 161, which may take any suitable form. The GIFTxt application server 131 is connected to the payment communications network 101 by a link 154. This link 154 provides a secure connection with the payment communications network.

The user terminals at the head office of The first merchant 104 and The second merchant 105 are shown at 115 and 127 respectively. These user terminals may be a personal computer, or laptop or such like. The head office user terminals are connected to the internet 106 through links 157 and 158 respectively. The GIFTxt Application server 131 is also connected to the internet through the link 155.

All the connections 150 to 158 are bidirectional links, that is communications may be passed in both directions along the link.

The first merchant 104 has an ePOS system, that includes the ePOS terminals 116 to 119.

Each of the ePOS terminals 116 to 119 includes a respective processor and memory. The ePOS terminals 116-119 perform all the computing functions associated with a sale such as product identification, cash registry, payment processing and transaction routing. The ePOS terminals 116-119 have various peripherals that connect to it, including a scanner, a printer 120-124, a keyboard, a Pin Entry Device 111-114 and a display. ePOS systems are typically connected to the Merchant's Local or Wide Area Network which in turn is connected to the payment communications network through a high speed internet connection.

The second merchant 105 has a standalone card payment terminal. In this manifestation, the function of the ePOS terminal 126 is separated from a card payment processor terminal 125. The card terminal 125 has a processor, memory, a display, a printer, a card entry slot and a numeric keypad. Standalone card terminals are typically connected to the payment communications network through a standard or secure phone connection, shown in the figure as phone network 103. Computer programs stored in the memory of the card terminal 125 are able to be executed by the processor thereof.

The mobile telephones 140, 141 each include a respective processor, display, memory and input device. The input devices may for instance be numeric keypads, qwerty keypads or touch screen virtual keypads. The SMS server 132 includes a processor and a memory.

The GIFTxt application server 131 includes a processor and a memory. The GIFTxt Database server 130 includes a processor and a memory.

The following description of processing will be explained using the standalone card terminal 125. Standalone terminals have more restrictive requirements because of limitation of bandwidth and the higher cost associated with a phone connection. However, the skilled person will understand how the process can be performed with integrated ePOS and card payment systems, such as the system of the first merchant 104.

Figure 2 relates to the buying and the sending of a GIFTxt voucher by a sender at a merchant. Figure 2 can be thought of as a flow diagram, although some process steps are omitted from the figure for the sake of clarity.

As a first step 201, the merchant selects an input that indicates that the sender wishes to buy a GIFTxt voucher. At step 202 the merchant 105 enters the value of the GIFTxt voucher directly on the card terminal 125. Alternately, for the first merchant 104, this process flow enters this value on the ePOS terminal such as 116. In the next step 202, it can be seen from the screen shot shown that the maximum amount is L100 and that the -10 -increment value is The value of the voucher is allowed to be equal only to an integer multiple of the increment value. It can also be seen in the step 202 that the merchant has entered a number "25" relating to L25 in value. At step 203, the merchant confirms their text entry by selecting a "return" or "enter" key. This ends the merchant's involvement in the process.

At step 204, the sender is requested through a user interface of the card terminal 125 to choose a greeting. As can be seen at Figure 2, a number of options are displayed in a vertical list, the first three of which are shown in the screen shot at step 204. The sender chooses their greeting by entering a return or enter command at step 205. At step 206, the sender is requested by the terminal 125 to enter their mobile telephone number. The sender in response enters their mobile telephone number, as is shown in step 206, and confirms their entry by pressing the return or enter key at step 207.

At step 208, the sender is prompted to enter the mobile telephone number of the intended recipient of the GIFTxt voucher. This is provided by the user using the card terminal 125, and the entry confirmed at step 209. At step 210, the card terminal 125 displays details of the GIFTxt voucher and requests that the sender confirms that the details are correct. This is achieved at step 211 by the sending selecting the enter or return key on the terminal card 125.

It will be appreciated that prior to allowing the sender to complete purchase of the GIFTxt voucher, the merchant obtains payment from the sender for the value of the GIFTxt voucher. This transaction could be achieved in a similar manner to any other purchase of goods from the merchant. A possible approach for handling payment during purchase and redemption will be described later. The merchant may be incentivised for retailing GIFTxt vouchers by being provided with a percentage of values of GIFTxt vouchers sold.

Figure 3 represents an alternative method of a sender purchasing a GIFTxt voucher as a gift. The process starts with step 301. Not shown in Figure 3 is the payment to the merchant by the sender, which occurs prior to step 301. On making the payment, the merchant is provided with the mobile telephone number of the sender's phone 140. The card terminal sends a message addressed to the GIFTxt application server 131 that includes -11 -transaction information, that identifies the merchant whose voucher is purchased, the value of the voucher purchased and the mobile telephone number of the sender's phone 140 and optionally the mobile phone number of the recipient 141. This message is sent through the communication links 150 or 151 and 154. The GIFTxt application server 131 creates a record including this information and stores the record in the database 130. The GIFTxt application server 131 then instructs the SMS server 132 to send a message at step 301 to the sender's phone 140, addressed the telephone number provided, which the SMS server does. As shown in Figure 3, the message provided at step 301 includes two parts, namely a thank you message and instructions for sending a GIFTxt voucher. The first part of the message is personalised with the name of the merchant through which the sender purchased the GIFTxt voucher. The second part of the message shown at step 301 includes instructions to send text and the mobile telephone number of the recipient to a certain telephone number in a particular format. At step 302, the sender is shown as having created a message meeting the format. Here, the message is addressed to number 89008, which relates to the SMS server 132. The message commences with the word "wish" followed by the mobile telephone number of the intended recipient of the GIFTxt voucher, followed immediately by a message. In this example, the message wishes a grandchild a happy birthday. The sender confirms sending of the GIFTxt voucher at step 303 by selecting send' on an input device of their mobile telephone 140. This results in an SMS having the message shown in step 302 being sent from the sender's mobile telephone to the SMS server 132 via the communication link 121. The SMS is received at the SMS server 132 having the telephone number of the sender's mobile telephone 140 as the calling device identifier and is then forwarded to the GIFTxt application server. From this, the GIFTxt application server 131 is able to determine the telephone number of the sender's telephone and thus match the received SMS message with the record stored in the database 130 that relates to the previously purchased GIFTxt voucher.

Figure 4 illustrates a process for a recipient requesting their GIFTxt voucher. The process is performed using the mobile telephone 141 of the GIFTxt voucher recipient.

At step 401, the recipient's telephone receives a message from the GIFTxt application server 131, sent via the SMS server 132. This message is shown at step 401 to spoof the name of the sender of the GIFTxt voucher, and includes the message that was provided by -12 -the sender at step 302 in Figure 3. At the end of the message is a message that names the merchant, indicates the value of the voucher (in this case f25) and provides instructions for obtaining the voucher. In this case, the instructions require the sending of a particular text string to a particular telephone number (the number of the SMS server 132) in an SMS. At step 402, the recipient is shown to have constructed a message in accordance with the instructions provided in step 401. The message is confirmed at step 403, resulting in an SMS message being sent from the recipient's mobile telephone 141 to the SMS server 132.

On receiving the message, the SMS server 132 provides a corresponding message to the GIFTxt application server 131 via the communication link 161. The SMS is received at the SMS server 132 having the telephone number of the recipient's mobile telephone 141 as the calling device identifier. From this, the GIFTxt application server 131 is able to determine the telephone number of the recipient's telephone 141 and thus match the received SMS message with the record in the database 130 that relates to the purchased GIFTxt voucher. In response, the GIFTxt application server 131 provides an instruction to the SMS server 132 to provide a response message. The second message is shown in step 404 in Figure 4. As shown, the message includes a number of fields, namely: a field indicating the name of the merchant, a field indicating the balance of the voucher value, a field including a voucher code, and a field providing redemption instructions. The name of the merchant and the voucher balance are determined from information that is stored in the database record. The voucher code is created by the GIFTxt application server and is stored in the associated record in the database. The voucher code is unique or quasi-unique. The voucher code includes two components, namely a part which includes a voucher indicative value, and a voucher number. As can be seen in step 404, the voucher code is 12 2344 3205. The voucher indicative value here is the last two digits (here, 05'), and the remaining digits are the voucher number. The last two digits of the voucher indicative value indicate the number of multiples of an increment that are present in the value of the voucher. In this embodiment, the increment is L and the value indicative digits "05" indicates a value of L25. The voucher number is a unique or pseudo-unique identifier that is used by the application server 131 to identify the record in the database 130 to which the voucher corresponds.

Following step 402, and optionally in parallel with in step 404, the GIFTxt server 131 controls the SMS server 132 to send an SMS message to the sender's mobile telephone 140 -13 -at step 405. As can be seen from the figure, the message received by the sender at step 405 indicates that the GIFTxt voucher was delivered to the recipient (but may not yet been redeemed). The message also includes a thank you message. Data indicating that this message was sent is stored in the database record.

In an alternative embodiment, described with reference again to Figure 4, step 402 is omitted. In the following, details are the same as described above with reference to Figure 4 unless otherwise stated.

The message at step 401 to spoof the name of the sender of the GIFTxt voucher, and includes the message that was provided by the sender at step 302 in Figure 3. At the end of the message is a message that names the merchant, indicates the value of the voucher (in this case L25). However, the message does not provide instructions for obtaining the voucher. Instead, the message is sent with a delivery receipt request. On receiving the message, the network operator of the recipient's phone 141, without any involvement from the recipient, sends a delivered receipt message. On receiving the delivered receipt message, the SMS server 132 provides a corresponding message to the GIFTxt application server 131 via the communication link 161. The delivered receipt message is received at the SMS server 132 having the telephone number of the recipient's mobile telephone 141 as the calling device identifier. From this, the GIFTxt application server 131 is able to determine the telephone number of the recipient's telephone 141 and thus match the received delivered receipt message with the record in the database 130 that relates to the purchased GIFTxt voucher. In response, the GIFTxt application server 131 provides an instruction to the SMS server 132 to provide a response message, which is the same as the second message shown in step 404 in Figure 4. In this way, the GIFTxt application server 131 can confirm that the recipient mobile phone 141 is active and is in the ON' position to receive the message at step 404 without requiring any involvement from the recipient.

GIFTxt voucher redemption is illustrated in the flowchart of Figure 5. Redemption Jo involves one of the PEDs 111 to 114 used with ePOS terminals 116 to 119 or card terminal 125(shown at 105 in Figure 5) and the mobile telephone 141 of the recipient. The redemption process is as follows. -14-

Firstly, at step 501 the merchant selects the amount to be redeemed (such as the value of goods required to be purchased) and applies it to GIFTxt by selecting a Redeem GIFTxt' option. In this example, a purchase value of DO is applied for redemption. This option can be selected directly on the card terminal 125 or by entering on the integrated terminal through the keypad at 116 to 119. This selection is confirmed at step 502. At step 503, the card terminal 125 prompts the user to enter their mobile telephone number, which is shown entered at the bottom of the step 503. Entry is confirmed at step 504. At step SOS, the card terminal 125 prompts the user to enter their GIFTxt voucher code. This is the voucher code that is shown in the SMS message received at step 404 of Figure 4, and was initially created by the GIFTxt application server 131. The voucher code is shown entered into the display at step 505 in Figure 5, and is confirmed at step 506. At step 507 the user is asked to confirm their redemption request which is shown in step 508.

At this stage, the card terminal 125 performs a preliminary check. In this particular case, the card terminal determines from the voucher code whether the voucher value is sufficient to cover the redemption amount entered by the recipient. This is performed by the card terminal 125 isolating a part of the voucher code that indicates the value and determining therefrom the value. In this case, the last two digits of the voucher code (here, 05') indicate the number of multiples of an increment (here, L) that equals the value of the voucher (here, L25). If the card terminal 125 determines that the redemption amount exceeds the voucher value, a message is displayed to the merchant that the redemption amount is exceeded and that a balance will be due after redemption, and at an appropriate later step instructs the merchant to collect the balance. If the card terminal determines that the redemption amount is equal to or less than the voucher value, the redemption process continues. In this case, a message including the mobile number, the GIFTxt voucher number and the redemption amount is then sent to the GIFTxt application server 131 via the payment communication network 101 and the communication links 151 and 154. In response, the GIFTxt application server 131 uses the voucher number to identify the database record relating to the voucher, and confirms that the mobile telephone number and the voucher number match. The GIFTxt application server 131 also confirms that the redemption amount does not exceed the voucher balance, as indicated in the database record. On determining that there is a match and that the redemption amount is suitable, the GIFTxt application server 131 deducts the redemption amount from the voucher -15 -balance and updates the database record with the updated voucher balance. The GIFTxt application server 131 then sends a message to the SMS server 132 via the communication link 161 requesting the sending of an SMS to the recipient's mobile telephone 141. In the example shown in Figure 5, the voucher balance after deducting the redeemed amount is LI S. The resulting message is shown in step 509 of Figure 5 as originating at the merchant and for including a thank you message, the remaining value of the voucher (which is equal to the original voucher value minus the redeemed amount) and instructions for obtaining a voucher in respect of the remaining balance (these instructions are the same as those provided at step 401 of Figure 4). The GIFTxt application server, simultaneously sends a message to the card terminal 125 using the payment communications network 101 through links 154 and 151 that the voucher has been settled and instructs it to print out a receipt including relevant details for each of the customer and the merchant.

The inclusion in the voucher number of a value indicative value provides a technical advantage in that it allows the merchant to perform a preliminary check without the need to revert to the application server 131. If the recipient attempts to redeem a value that exceeds the value of the voucher, as can be determined from the value indicative value of the voucher number, the card terminal 125 detects this without reference to the application server 131 and takes the necessary action. This action may be refusing the transaction, or simply requesting the recipient to provide a lower value for the redemption, or asking them to pay the balance of the transaction amount through alternate means. If the card terminal 125 determines that the value that is requested to be redeemed is within the value of the voucher, as identified by the indicative value, the merchant proceeds with the redemption of the voucher as discussed above. For the avoidance of doubt, it will be appreciated that an improved technical operation is provided by the fact that some invalid transactions can be prevented without the need to contact the application server 131, thereby reducing use of communications bandwidth and reducing the amount of time needed to prevent or refuse the transaction.

In the above, the value of the voucher is able only to take an integer multiple of an increment value, which in the example is an increment of L* This limitation on possible values of the vouchers provides certain advantages. In particular, the voucher number can be relatively short for a given length of voucher code. Short voucher numbers require less -16 -user input and also utilise fewer of the maximum 140 characters that are permitted to be included in an SMS message.

In the above example, only redemption values lower than voucher indicated balance were accepted. This illustrates the primary benefits of including an indicative value with the voucher code.

In other embodiments, these limitations are not present. Some such embodiments will now be described with reference to Figures 6 and 7.

A second example voucher code is shown in Figure 6. The voucher code includes two components, namely a part VN, which is a voucher number, and a part VV which includes a voucher indicative value and a check digit. As can be seen in Figure 6, the VN has eight digits. The VN is unique or pseudo-unique. The VN is stored in a record in the database 130 and is accessible to the application server 131. VV, the voucher indicative value here is 073, with a check digit of 9. The voucher indicative value is typically used for representing the actual value of the voucher. However, it can be used in conjunction with the voucher number VN for additional purposes as will be illustrated in the following. In the shown example, the first two digits of the voucher indicative value indicate the number of multiples of a first increment that are present in the value of the voucher. In this case, the first increment is L and the number "07" indicates a balance of The third numeral in the voucher indicative value indicates the number of multiples of a second increment that are included in the voucher value. In this example, the second increment is SOp (or one half of LI) and the number "3" denotes three SOp increments, indicating that the voucher value includes an amount between LI.50 and LI.99. Adding two components together, the voucher indicative value denotes a value of the voucher that is between L36.50 and L36.99.

The check digit is calculated across the twelve digits of the voucher code, for instance using a checksum function.

This implementation of the eight digit voucher number, three digit voucher indicative value and one check digit is particularly suitable for person to person vouchers which need to be tracked uniquely. However, the voucher number and voucher indicative value can be used in combination for other similar purposes. For example, consider a merchant that -17 -wants to send out a specific promotion to a population of their customers. These may not be unique to every individual customer, however more likely unique to categories of customers, for example a lO% discount to the most valuable customers and a S% discount to the next category. In this case, the purpose may be merely to attract a proportion of these customers to shop rather than to track them individually. The voucher number and voucher indicative value could then be used as follows.

The voucher number VN in this case is a six digit number (instead of an eight digit number). The ePOS terminal is configured to recognise from the length of the voucher number VN that this voucher is a special merchant voucher, not a person to person voucher. The voucher indicative value VV then is chosen to represent one of a number of allowed categories of vouchers. For example, I O% off customers could be assigned a category number of "101" and S% off customers could be assigned a category number of "902". These category numbers can be sent to the ePOS terminal from the server during an end of day transaction sometime before the promotion is set to begin. The merchant 104, 105 then offers through an interface to the GIFTxt application server 131 using their head office terminal 115, 127 and through the internet connection 106, 158 a command to send these vouchers to their customers. A IO% off voucher to a customer could be constructed to be 2332331016. A S% off voucher to a customer could constructed to be 6332489021. It will be appreciated that in this case the merchant terminal 125 is able to pre-validate the voucher before sending it to the GIFTxt application server 131, thereby minimising errors.

Figure 7 illustrates a process that is performed when redeeming a GIFTxt voucher at a merchant's location. In the following, references to a terminal are generic. The terminal may be constituted for instance by the card terminal 125, or by one of the ePOS terminals 116-119 and its corresponding PED 111-114. In either case, the terminal includes software in the form of one or more computer programs that causes the terminal to operate as described. Further, the process described here corresponds to manual entry of the voucher code and voucher balance into the terminal. However the skilled reader will understand that methods using automated systems such as swipe cards, optical character recognition and wireless communications to transmit these numbers can be used, and that such techniques simplify and speed the entry of these numbers into the merchant terminal.

-18 -At step 1001, a transaction is initiated from a merchant terminal 116 to 119 or 125 with a purchase value (P7). The purchase value could be the value of goods required to be purchased by the customer or such like. At step 1002, the merchant enters the voucher code into the terminal.

At step 1003, the terminal determines whether the purchase value (P7) is greater than a voucher indicative value lower limit (VYL). The VVL is calculated as the smallest amount of the range that can be constituted by the voucher indicative value (VV). Using the example code in Figure 6, the merchant terminal 108 determines that the maximum value of the voucher is L36.99 (equal to 7 x L + 3 x SOp + 49p (49p is the second increment minus the smallest unit of currency, namely Ip)). A negative determination indicates that the voucher balance will sufficiently cover the purchase value. The customer/recipient is asked to confirm that they agree with the purchase value being deducted from the voucher balance. If the customer changes their mind and indicates no' the process is terminated as per steps 1007 and 1024. If the customer decides to continue with the redemption at step 1007, the card terminal proceeds to step 1009 which initiates the sending of a message (optionally encrypted) to the GIFTxt application server 131, the message including the Voucher Code (IC) and the Purchase Value (P7). The GIFTxt application server 131 determines whether the voucher is valid, with reference to the database server 130, and send a response as appropriate. On receiving the response from the GIFTxt application server 131,the terminal decides whether the voucher is valid at step 1010. If the voucher is valid, the terminal proceeds to step 1021 and prints a transaction complete receipt. At this time, the GIFTxt application server 131 causes the SMS server 132 to send a message to the recipient's telephone 141 indicating that a voucher has been redeemed. If the voucher balance is non 2ero, or alternatively is above a threshold equal to the first increment (here Li), the message may provide instructions for requesting a voucher, or transmit a new voucher number for redeeming some or all of the remaining balance. If however the voucher is found to be invalid at step 1010, the terminal proceeds to print a transaction cancel receipt indicating the reason for the same.

In the event of a positive determination at step 1003, the operation proceeds to step 1004.

Here, the terminal prompts the merchant to obtain the actual voucher balance from the -19 -customer. This information is available from the recipient's mobile phone 141, in particular from the text of the latest message from the GIFTxt application server 131. At step 1005, the terminal determines whether the entered voucher balance is within the indicated value minimum and maximum limit. This step again enables to reduce the errors that may occur during this transaction. When this is confirmed, the terminal proceeds to step 1006 where the test of the purchase value being greater than the entered voucher balance is performed. The probability of this test being negative is quite low since limited to the cases where the purchase value is also within the voucher indicative value range, which is a small number. If however, this is the case, the terminal proceeds to 1007 which then progresses as above. If the test in step 1006 is confirmed to be positive, this indicates that the voucher balance entered is less than the purchase value and there will be a residual amount due. The terminal then proceeds to step 1011 where it prompts the merchant to indicate to the customer that a balance of the residual value (RV) will be due after the voucher is approved, and to confirm if they should continue with the transaction. If the customer declines, the terminal proceeds to step 1023 where a transaction cancellation receipt is printed.

If the customer agrees to continue, the terminal performs another test at step 1013 to check if the residual value (RV) is greater that an internally set card limit (CL). The card limit is a value set by the merchant below which they will not accept a credit card as a mode of payment. If the outcome of this test is positive, a credit or debit card can be accepted as a mode of payment and the terminal proceeds to step 1014. If the outcome of this test is negative, a credit card or debit card cannot be accepted as a mode of payment and the terminal proceeds to step 1015.

At step 1014, the merchant is prompted to ask the customer to indicate how they would like to pay for the residual amount. If the payment is to be made by cash, the terminal progresses to step 1015. In case of a cash transaction, the terminal ensures that the tendered amount is larger than the residual value at step 1017.

If the payment will be by card, the terminal progresses to step 1025. In the case where the payment has been chosen to be made by card, the terminal at step 1025 evaluates if the voucher has pre-validated in a previous step. Note, this test will be negative in the first -20 -instance, but for future iterations, as discussed below, this step could have a positive result.

For a card payment, however, the terminal at step 1026 prepares a message including the Voucher Code (IC), Purchase Value (P7) and Voucher Balance (lB -as entered by the merchant) and sends it to the GIFTxt application server 131. The GIFTxt application server 131 determines whether the voucher is valid, with reference to the database server 130, and send a response as appropriate. At step 1027, the terminal uses the response to determine voucher validity. If the voucher is declined, the process terminates in step 1031.

If the voucher is accepted, the GIFTxt application server 131 response includes the sending of a pre-validated voucher to the terminal. A pre-validated voucher completes validation only when a confirmation is sent back to the GIFTxt server about its completion, as will be explained below.

On confirming completion of a pre-validated voucher, the GIFTxt application server 131 causes the SMS server 132 to send a message to the recipient's telephone 141 indicating that a voucher has been fully redeemed and a balance is due.

On receiving the pre-validated voucher at step 1036 or on a positive determination at step 1025, the terminal proceeds to the card transaction at step 1028 for the residual amount. If the card transaction is a success at step 1029, the terminal completes the GIFTxt transaction at step 1030 after the card transaction is completed, by printing a transaction complete receipt. This step involves the terminal sending confirming completion of the pre-validated voucher to the GIFTxt application server 131. On receipt, the GIFTxt application server completes the transaction by updating the record in the database server appropriately. If, alternatively, the card transaction fails to authorise the residual value payment at step 1029, the terminal prompts the merchant to ask the customer if they would like to continue with paying the residual value by other means at step 1032.

If the customer decides to cancel the transaction, the terminal proceeds to step 1034, where the terminal prepares a second message including the details of the pre-validated voucher and transmits it to the GIFTxt application server 131 for cancellation of the voucher. On receiving confirmation of cancellation of the pre-validated voucher from the GIFTxt application server 131, the terminal cancels the transaction and prints a transaction cancellation receipt. At this time, the GIFTxt application server 131 causes the SMS server -21 - 132 to send a message to the recipient's telephone 141 indicating the voucher redemption has been cancelled, the resulting voucher balance amount and instructions on how to redeem the voucher balance.

If the recipient/customer at step 1032 chooses to continue with the payment, they are returned to step 1014 where they are again asked to choose the payment method. There If they again choose card, for instance desiring to pay with a different card, operation proceeds again to step 1025. Of course, this time the voucher has been pre-validated, so the operation proceeds straight to step 1028. If instead the customer chooses the cash option at step 1014, the test at step 1016 results in a negative response and the terminal proceeds to 1015 where the merchant is asked to enter the tendered amount. Note that this is the same step that is arrived at if the residual value is determined to be below the Card Limit in step 1013. After ensuring that the tendered amount is above the residual value in step 1017, the terminal proceeds to step 1018. This step is similar to step 1025, where a check is made if the voucher has been pre-validated. Since the voucher has been pre-validated (at step 1036), the terminal proceeds to step 1022 where it computes the balance due on the tendered amount and prints the transaction complete receipt including all payment details. This ends the illustration of how the transaction completes if a first card transaction is declined but the customer successfully settles the residual value with cash tender.

If the customer had arrived at step 1015 in the first instance by choosing to pay by cash or if the residual value is below the card limit, the response to the test at step 1018 would be negative since pre-validation would not have occurred at step 1036. In this case, the terminal proceeds to step 1019 where it prepares a message including Voucher Code (VC), Purchase Value (PV), Voucher Balance (VB as entered by the merchant) and Tender Amount (T) and transmits this to the GIFTxt application server 131. The GIFTxt application server 131 determines whether the voucher is valid, with reference to the database server 130, and send a response as appropriate. If the voucher is declined, step 1020 leads to the process being terminated at step 1024. If the voucher is approved, the terminal proceeds from step 1020 to print a transaction complete receipt at step 1021. At this time, the GIFTxt application server 131 causes the SMS server 132 to send a message -22 -to the recipient's telephone 141 indicating that a voucher has been fully redeemed and that there is no balance due.

In the above method, successful completion of a pre-validated voucher is not required to be confirmed to the GIFTxt application server during the same transaction. This is possible because a successful completion has no immediate consequence in any further interaction the customer may have with the merchant, except if the customer wants to reverse the transaction with the merchant. In the methods described above, successful completion of a pre-validated voucher is indicated in the next transaction carried out by the same ePOS terminal with the GIFTxt application server 131 or when reconciliation takes place with the GIFTxt application server 131 at the end of the day. In this manner, another transaction step is reduced in the case of successful pre-validated voucher redemption. In the event that the customer wants to reverse the transaction before the end of the day and returns to the same merchant terminal, the terminal will have confirmed the acceptance in a transaction that followed the purchase transaction or would do it while transmitting the request for reversal to the GIFTxt server 131.

Although in the above it is described that the voucher code is provided with the voucher indicative value plainly visible, it will be appreciated that the voucher indicative value may instead be hidden. For instance, in some embodiments the GIFTxt application server 131 generates the voucher code as described above and then applies encryption or obfuscation before sending an encrypted or obfuscated voucher code to the recipient's mobile telephone 141 as part of an SMS message. The merchant's terminal is provided with the capability be decrypt or deobfuscate the voucher code, and processes the result as processing of the voucher code is described above. In this case, the merchant's terminal may transmit the encrypted or obfuscated voucher code, or the decrypted or deobfuscated voucher code, to the GIFTxt application server 131. In either case, the merchant's terminal needs to know the encryption or obfuscation used, and needs to know whether to send the encrypted or obfuscated voucher code or the decrypted or deobfuscated voucher code to the GIFTxt application server 131.

An advantage of having the voucher indicative value hidden in the voucher code is reduced opportunity for attempted fraud through faked voucher codes. However, no fraud could -23 -occur since a faked voucher code would not be authorised by the GIFTxt application server 131.

There are numerous advantages effects of the operations outlined above. One effect of particular note is the effect that the operations have on the communications required between the ePOS terminal 125, 116-119 and the GIFTxt application server 131. In particular, with the embodiments described, redemption of a voucher requires the sending of only a single message from the ePOS terminal to the GIFTxt application server 131. It also requires the sending of only a single message from the GIFTxt application server 131 to the ePOS terminal to confirm (or otherwise) the validity of the voucher and the transaction prior to the transaction between the ePOS terminal and the customer being completed (although in the less frequent incidence of cancelling a pre-validated voucher, a message is sent later from the ePOS terminal to GIFTxt application server 131). Since sending messages and awaiting responses takes time, this contributes to a short transaction time. This is advantageous from a technical viewpoint, and also results in an improved customer experience as well as a lower utilisation of merchant staff and ePOS equipment.

Furthermore, this is achieved without requiring a permanent connection between the ePOS terminal and the GIFTxt application server 131. Instead, connectionless and sessionless protocols are suitable, and are used in the above embodiments. Connectionless or sessionless communication is technically superior for many reasons, especially in retail environments.

Furthermore, with this process, the ePOS always requests an approval of an amount equal to or less than the actual voucher balance. This enables the system to be required only to provide a response either of accepted or declined. This obviates the need for partial approval amount transactions, which currently are not universally supported by credit card processing software. -24-

Claims

Claims 1. A method of performing a secure financial transaction, the method comprising, in sequence: a) server apparatus composing a first message comprising a first identifier and data indicative of a first quantity of currency; b) the server apparatus addressing the first message to a mobile telephone by way of a telephone number associated with the mobile telephone; c) sending the first message to the first mobile telephone; d) the server apparatus receiving from a retailer terminal a message including an identifier, a mobile telephone number and a transaction value; e) the server apparatus determining from a database record whether the identifier is valid and is assigned to the received mobile telephone number; I) in response to e), the server apparatus validating a transaction to the transaction value, and confirming validation of the transaction to the retailer terminal; g) the server apparatus composing a second message comprising a second identifier, the second identifier being different to the first identifier, and a value indicative of a second quantity of currency, the second quantity of currency being equal to or less than the first quantity of currency minus the transaction value; and h) the server apparatus addressing the second message to the mobile telephone by way of the telephone number for sending to the first mobile telephone.
2. A method as claimed in claim 1, additionally comprising: j) the retailer terminal requiring entering of a verification number by a user, the verification number not being present in the first message, Ic) the retailer terminal sending the verification number to the server apparatus with the mobile telephone number, the identifier and the transaction value, and 1) the server apparatus validating the transaction only if the verification number received from the retailer terminal matches a verification number associated at the server apparatus with the mobile telephone number.
3. A method as daimed in rlsini I or rlsini 2, comprising, prior to a), m) the server apparatus receiving a voucher request message from the mobile telephone requesting to redeem a voucher, and n) the server apparatus using a ctlling line identifier associated with the message to identify a record in a database that corresponds with the voucher request message, and wherein b) comprises the server apparatus addressing the first message to the mobile telephone by way of the telephone number stored in the database record.
4. A method as daimed in rlsini I or rlsini 2, comprising, prior to a), o) the server apparatus sending an introduction message to the mobile telephonc p) the server apparatus subsequently receiving a delivered receipt message from the mobile telephone, and q) the server apparatus using a ctlling line identifier associated with the delivered receipt message to identify a record in a database that corresponds with the voucher request message, and wherein b) comprises the server apparatus addressing the first message to the mobile telephone by way of the telephone number stored in the database record.
5. A method as claimed in any preceding ckini, wherein g) is performed in response to the server apparatus receiving a redeem message from the mobile telephone.
6. A method as claimed in any preceding rlsini, the server apparatus provides the data indicative of a first quantity of currency comprises an integer that is equal to the quantity of currency divided by a predetermined increment.

-26 -
7. A method as claimed in claim 6, wherein the data indicative of a first quantity of currency comprises first and second components, the first component comprising a first integer and the second component comprising a second integer, wherein the first and second integers are selected such that the quantity of currency is defined as the sum of the first integer multiplied by a first predetermined increment and the second integer multiplied by a second predetermined increment.
8. A method as claimed in any preceding claim, wherein the server apparatus receiving the message including a mobile telephone number, an identifier and a transaction value via a connectionless communication, and confirms validation of the transaction to the retailer terminal via a connectionless communication.
9. A method as claimed in any preceding claim, wherein IT) comprises: fI) the server apparatus pre-validating a transaction to the transaction value, and confirming pre-validation of the transaction to the retailer terminal; and f2) completing the transaction in response to receiving a transaction complete confirmation message from the retailer terminal, or cancelling the transaction in response to receiving a transaction cancellation message from the retailer terminal.
10. A method as claimed in any preceding claim, comprising: r) the retailer terminal determining from the identifier whether the transaction value is exceeded by an amount of currency that corresponds to a currency value of the voucher, and in the even to a negative determination refraining from sending the message including the mobile telephone number, the identifier and the transaction value.
11. A computer program, optionally stored on a computer readable medium, the program comprising instructions which when implemented by computer apparatus control it to perform a method as claimed in any preceding claim.
12. Computer apparatus configured by one or more computer programs to perform in sequence a method comprising: a) composing a first message comprising a first identifier and data indicative of a first quantity of currency b) addressing the first message to a mobile telephone by way of a telephone number associated with the mobile telephone; c) sending the first message to the first mobile telephone; d) receiving from a retailer terminal a message induding an idendfler a mobile telephone number and a transaction value; e) determining from a database record whether the identifier is valid and is assigned to the received mobile telephone number 1) in response to e), validating a transaction to the transaction value, and confirming validation of the transaction to the retailer terminal; g) composing a second message comprising a second identifier, the second identifier being different to the first identifier, and a value indicative of a second quantity of currency, the second quantity of currency being equal to or less than the first quantity of currency minus the transaction value; and h) addressing the second message to the mobile telephone by way of the telephone number for sending to the first mobile telephone.
13. Computer apparatus as chimed in rhim 12, configured additionally to perform: j) retailer terminal apparatus reqniring entering of a verification number by a user, the verification number not being present in the first message, k) the retailer terminal apparatus sending the verification number to the server apparatus with the mobile telephone number, the identifier and the transaction value, and 1) validating the transaction only if the verification number received from the retailer terminal matches a verification number associated at the server apparatus with the mobile telephone number.
14. Computer apparatus as rhimed in rhim 12 or chim 13, configured additionally to perform, prior to a): m) receiving a voucher request message from the mobile telephone requesting to redeem a voucher, and n) using a cIling line identifier associated with the message to identify a record in a database that corresponds with the voucher request message, and wherein b) comprises the server apparatus addressing the first message to the mobile telephone by way of the telephone number stored in the database record.
15. Computer apparatus as risimed in rhim l2or chini 13, configured additionally to perform, prior to a): o) the server apparatus sending an introduction message to the mobile telephonc p) the server apparatus subsequently receiving a delivered receipt message from the mobile telephone, and q) the server apparatus using a ctlling line identifier associated with the delivered receipt message to identify a record in a database that corresponds with the voucher request message, and wherein b) comprises the server apparatus addressing the first message to the mobile telephone by way of the telephone number stored in the database record.
16. Computer apparatus as chimed in any of risims 12 to 15, configured additionally such that g) is performed in response to the server apparatus receiving a redeem message from the mobile terminal.
17. Computer apparatus as chimed in any of rhims 12 to 17, configured additionally to provide the data indicative of a first quantity of currency comprises anintegerthatis equal to the quantity of currency divided byapredetermined increment.
18. Computer apparatus as chimed in rhini 17, wherein the data indicative of a first quantity of currency comprises first and second components, the first component comprising a first integer and the second component comprising a second integer, wherein the first and second integers are selected such that the quantity of currency is defined as the sum of the first integer multiplied by a first predetermined increment and the second integer multiplied by a second predetermined increment.
19. Computer apparatus as chimed in any of risims 12 to 18, configured additionally to receive the message including a mobile telephone number, an identifier and a transaction value via a connectionless communication, and to confirm validation of the transaction to the retailer terminal via a connectionless communication.
20. Computer apparatus as chimed in any of rhims 12 to 19, configured additionally such that 1) comprises: fI) pre-validating a transaction to the transaction value, and confirming pre-validation of the transaction to the retailer terminal; and £2) completing the transaction in response to receiving a transaction complete confirmation message from the retailer terminal, or cancelling the transaction in response to receiving a transaction cancellation message from the retailer terminal.
21. Computer apparatus as rhimed in any of rhims 12 to 20, the retailer terminal being configured to determine from the identifier whether the transaction value is exceeded by an amount of currency that corresponds to a currency value of the voucher, and in the even to a negative determination refraining from sending the message including the mobile telephone number, the identifier and the transaction value.