GB2573049A

GB2573049A - Issuing refund transactions

Info

Publication number: GB2573049A
Application number: GB1903450.3A
Authority: GB
Inventors: Kletzer Victor; Menzinsky Richard
Original assignee: Global Blue SA
Current assignee: Global Blue SA
Priority date: 2019-03-13
Filing date: 2019-03-13
Publication date: 2019-10-23
Also published as: GB201903450D0

Abstract

A mobile device (120; Fig 1, Fig 7) comprising: storage circuitry configured to store user data 810; obtaining circuitry configured to obtain transaction data 820 relating to a transaction performed by a terminal device (110; Fig 1) or point-of-sale device and to obtain authentication data 830 that verifies authenticity of the transaction; and communication circuitry configured to associate or initiate a tax refund request 840 with the user in respect of the transaction, wherein the tax refund request comprises the user data and the authentication data. The transaction data may comprise one or more of: transaction time, transaction amount, transaction identifier and transaction tax amount. A payment request circuity may initiate a payment request to the terminal/PoS device for the transaction and the communication circuitry may initiate the tax refund request in response to an indication from the payment request circuitry that the request was successful. Also provided is an apparatus comprising: transaction input circuitry to input transaction data (910; Fig 9); generation circuitry to generate authentication data that verifies authenticity of the transaction (920; Fig 9); and communication circuitry to provide the transaction data (930; Fig 9) and the authentication data (940; Fig 9) to a mobile device.

Description

ISSUING REFUND TRANSACTIONS

The present technique relates to data processing.

In some jurisdictions, it is possible for a traveller to obtain a refund of tax paid in respect of a purchase. Typically, this requires a traveller to make a valid purchase and, once the transaction has completed, the merchant must then check the eligibility of the traveller (e.g. by checking the traveller’s passport) and providing evidence that the purchase took place. In some cases, the purchase may be linked to the traveller themselves so as to reduce fraud. This process is time consuming, since it typically involves filling in and verifying a number of different forms by both the merchant and the user.

Viewed from a first example configuration, there is provided a mobile device comprising: storage circuitry configured to store user data; obtaining circuitry configured to obtain transaction data relating to a transaction performed by a terminal device or point-of-sale device and to obtain authentication data that verifies authenticity of the transaction; and communication circuitry configured to associate or initiate a tax refund request with the user in respect of the transaction, wherein the tax refund request comprises the user data and the authentication data.

Viewed from a second example configuration, there is provided a method comprising: storing user data; obtaining transaction data relating to a transaction performed by a terminal device or point-of-sale device; obtaining authentication data that verifies authenticity of the transaction; and associating or initiating a tax refund request with the user in respect of the transaction, wherein the tax refund request comprises the user data and the authentication data.

Viewed from a third example configuration, there is provided an apparatus comprising: transaction input circuitry to input transaction data relating to a transaction; generation circuitry to generate authentication data that verifies authenticity of the transaction; and communication circuitry to provide the transaction data and the authentication data to a mobile device.

Viewed from a fourth example configuration, there is provided a method comprising: receiving transaction data relating to a transaction; generating authentication data that verifies authenticity of the transaction; and providing the transaction data and the authentication data to a mobile device.

The present technique will be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which:

Figure 1 illustrates a system for performing tax refunds comprising a mobile device and a terminal device;

Figure 2 is a communication chart showing the exchange of communications between a mobile device, a terminal device, a Tax Refund Operator (TRO) server, and a payment gateway in accordance with some embodiments;

Figure 3 is a communication chart showing the exchange of communications between a mobile device, a terminal device, a Tax Refund Operator (TRO) server, and a payment gateway in accordance with some embodiments;

Figure 4 is a communication chart showing the exchange of communications between a mobile device, a terminal device, a Tax Refund Operator (TRO) server, and a payment gateway in accordance with some embodiments;

Figure 5 is a communication chart showing the exchange of communications between a mobile device and a Tax Refund Operator (TRO) server in accordance with some embodiments;

Figure 6 schematically illustrates a mobile device and a terminal device in accordance with some embodiments;

Figure 7 shows the use of an electronic wallet for tracking refund requests in accordance with some embodiments;

Figure 8 is a flow chart illustrating a method in accordance with some embodiments; and

Figure 9 is a flow chart illustrating a method in accordance with some embodiments.

Before discussing the embodiments with reference to the accompanying figures, the following description of embodiments and associated advantages is provided.

In accordance with one example configuration there is provided a mobile device comprising: storage circuitry configured to store user data; obtaining circuitry configured to obtain transaction data relating to a transaction performed by a terminal device or point-of-sale device and to obtain authentication data that verifies authenticity of the transaction; and communication circuitry configured to associate or initiate a tax refund request with the user in respect of the transaction, wherein the tax refund request comprises the user data and the transaction data.

The user data that is stored by the storage circuitry may be used in order identify the user. The data could take the form, for instance, of government issued identification that can be used to identify a country of residence or a tax paying status of the user. In some embodiments, this user data is a token or an identifier that is produced as a result of an initial registration process that the user undergoes using, for instance, government backed identification. In these embodiments, the user’s sensitive identification information is not required to be stored. Such registration could take place on the mobile device itself or could take place via another device altogether. The obtaining circuitry is used to obtain the transaction data relating to a transaction performed by a terminal device or point-of-sale device. The process of obtaining the transaction data could be passive (i.e. the transaction data is simply provided) or could be active (i.e. the transaction data is explicitly requested). The transaction data need not be provided by the terminal device/point-of-sale device that performed the transaction itself. In some embodiments, the transaction data could be obtained indirectly via something produced by the terminal device/point-of-sale device such as a printed receipt or could be from another device altogether such as a server. In addition, the obtaining circuitry obtained authentication data which verifies the authenticity of the transaction. Such authentication data makes it difficult for the user to fraudulently claim as a transaction occurred when it did not. The communication circuitry is used in order to initiate associate a tax refund request with the user. The association could be in respect of a new tax refund request that is generated or initiated as part of the tax refund request that is generated as part of the tax refund request being issued or could be to associate an existing tax refund request that has previously been made with the user. The communication circuitry could operate indirectly. For instance, the communication circuitry could take the form of a printer that prints a tax refund request in paper for that is to be provided by the user to a Tax Refund Operator (TRO) or VAT Refund Operator (VRO), hereinafter simply referred to as a Tax Refund Operator or TRO. By making the user data and the authentication data available as part of the tax refund request, it is possible for all of the data required for a tax refund request to be presented by the user. Since the user provides this data, there is no need for the merchant to be responsible for filling in, signing, or validating forms. This reduces the burden on the merchant, while also making it possible for the merchant’s sale systems to make use of data processing devices in the form of the users (e.g. travellers) mobile device. In this way, the process of requesting the tax refund can be distributed and the processing load placed on merchant systems can be reduced.

In some embodiments, the obtaining circuitry comprises first data receive circuitry to receive first data from the terminal device or point-of-sale device. The first data could be the sole data that is received from the terminal device or point-ofsale device. However, in other embodiments, a number of different items of data can be received from the terminal device or point-of-sale device. By receiving only the first data, it is possible to improve the overall speed with which the tax refund request can be issued as a consequence of inhibiting any request/response mechanism from the process.

In some embodiments, the first data receive circuitry comprises any combination of: a barcode reader, a QR code reader, Bluetooth circuitry, NFC circuitry, WiFi circuitry, mobile data circuitry, and image recognition circuitry. There are a number of different ways in which the first data can be received. Each of these technologies has particular advantages that will be known to the skilled person. Other known techniques will also be known to the skilled person. Note that the first data need not be intelligible or exclusively intended for interpretation by a computerised system. In particular the first data could be transmitted in the form of a graphic or text that is presented as part of a display or is printed on a printer (e.g. in the form a receipt). It will be appreciated that there is no need for the first data receive circuitry to only use one of the different options presented. In some embodiments, the first data receive circuitry may use a number of the different circuits that have been described or that will be known to the skilled person. An example of mobile data circuitry would be, for instance, 3G or LTE circuitry.

In some embodiments, the first data comprises the transaction data. By initially providing the transaction data, it is possible for the mobile device to make an initial determination as to whether the transaction in question is likely to be valid in respect of a tax refund request. The exact determination process will be dependent on the jurisdiction in question. However, certain tests may be carried out on the basis of the transaction that will automatically exclude certain transactions from being the subject of a tax refund request. For instance, if the amount of tax paid on the goods is zero, then it is possible to inhibit the rest of the procedure for the tax refund request since clearly no tax will be refundable. A similar process occurs in respect of a transaction that is actually a refund. In this situation, although a previous tax refund request may be cancelled as a consequence of the transaction taking place, no further tax refund request should be made. Another example of where a tax refund could be inhibited is the situation in which the transactions having a particular value can be the subject of a tax refund request. Such a de minimis amount could be enforced by local jurisdictions. As another example, if the transaction data contains information regarding the goods purchased and it is known that particular goods are exempt from tax refund requests, then again such a tax refund request could be inhibited from being associated.

In some embodiments, the first data comprises the authentication data. By providing the authentication data as part of the first communication that is received, it is possible to inhibit a tax refund request from being associated if certain conditions are or are not met. One such condition could be that the authentication data is not valid. For instance, in a situation in which the authentication data is cryptographically signed, the authentication data may be invalid if the signature does not match the underlying transaction data. Other tests can be carried out on cryptographic signatures to check whether they are valid. For instance, if a particular process is used to generate a cryptographic signature that is of a certain number of bits, then the authentication data having a different number of bits would be an indicator that the authentication data is invalid. In other situations that may use, for instance, cryptographic certificates, for instance to validate the identity of a particular merchant, then if the certificate is found to be invalid (e.g. out of date or incorrect or corresponding to a merchant that is not permitted to enable tax refunds) then the tax refund request can be inhibited at an early stage.

In some embodiments, the obtaining circuitry comprises second data receive circuitry to receive second data from the terminal device or point-of-sale device. By receiving second data from the terminal device or point-of-sale device, it is possible to reduce bandwidth or processing power that is used to process a tax refund request. For instance, if the first data indicates that the tax refund request will not be valid, then second data that is transmitted can be disregarded and therefore not processed.

In some embodiments, the obtaining circuitry is configured to request the second data from the terminal device or point-of-sale device by providing at least part of the first data. Having received the first data, a request is transmitted to the terminal device or point-of-sale device to request specific second data. In this way, the processing power or bandwidth of the system can be reduced by only requesting data that is explicitly required for the tax refund process to continue. In some of these embodiments, the first data contains information that is used to identify a particular transaction (e.g. only information used to identify a particular transaction). Once this is known, the specific data that is required for the tax refund to proceed can be requested and then transmitted in the form of the second data.

In some embodiments, the second data receive circuitry comprises any combination of: Bluetooth circuitry, NFC circuitry, mobile data circuitry, and WiFi circuitry. There are a number of different ways in which the second data can be received. Each of these technologies has particular advantages that will be known to the skilled person. Other known techniques will also be known to the skilled person. Note that the second data need not be intelligible or exclusively intended for interpretation by a computerised system. It will be appreciated that there is no need for the second data receive circuitry to only use one of the different options presented. In some embodiments, the second data receive circuitry may use a number of the different circuits that have been described or that will be known to the skilled person.

In some embodiments, the second data comprises the transaction data. The transaction data could be transmitted as part of the second data when an explicit request is transmitted to the terminal device or point-of-sale device to indicate the desired transaction data. As another example, the transaction data may form part of the second data when initial data is sent as part of the first data to enable the mobile device to determine whether the second data should be disregarded or not. For instance, the first data may provide sufficient information for an initial verification to be performed to determine whether the tax refund request is likely to be valid or not.

In some embodiments, the second data comprises the authentication data. Determining the validity of the authentication data may be computationally expensive. Consequently, if validity checking is performed, then it may be desirable to leave the step of verifying the authentication data until other checks have been performed. This can be achieved by including the authentication data in the second data, with the first data containing information necessary to perform the initial checks.

In some embodiments, the transaction data comprises one or more of a time of the transaction, an amount of the transaction, an identifier of the transaction and a tax amount of the transaction. Such information can be used either to uniquely identify the particular transaction that occurred or can be used to determine the extent to which a tax refund is possible.

In some embodiments, the mobile device comprises: payment request circuitry to initiate a payment request to the terminal device or point-of-sale device for the transaction; and the communication circuitry is adapted to initiate the tax refund request in response to an indication from the payment request circuitry that the payment request is successful. In these embodiments, the mobile device can also be responsible for performing or initiating the payment. This can be done using services such as Paypal or Alipay. Other such services will be known to the skilled person. Having initiated a request for a payment to be made, a response is received from the underlying payment service as to whether the payment has been successful or not. If the indication is that the payment request was successful, then the communication circuitry initiates the tax refund request. Consequently, the tax refund request is made if it can be determined that the payment has been successfully made. In other embodiments where the payment request circuitry is not present, the step of determining whether the payment request (which is not necessarily the responsibility of the mobile device) is successful may be implicit in receiving the transaction data and/or the authentication data from the terminal device or point-of-sale device. In other words the presence of the transaction data and/or the authentication data indicates that the transaction has successfully occurred. However, this may not be possible if the mobile device itself is responsible for initiating the payment request as is the case when payment request circuitry is present. Accordingly, the communication circuitry initiates the tax refund request on the further requirement that there is an indication that the payment request has been successfully performed.

In some embodiments, the authentication data is valid for a validity period after being first provided by the terminal device or point-of-sale device. By limiting the period for which the authentication data is valid, it becomes necessary for the tax refund request to be issued within a short period of time of the transaction taking place. For instance, the authentication data may be valid for a period of one minute after the transaction has taken place and the authentication data is first made available by the terminal device or point-of-sale device. This can be achieved in a number of different ways. For instance, the authentication data may include a time to live, which indicates a time after which the authentication data is no longer valid. The mobile device may be configured to reject authentication data that is older than this. Furthermore, the processing of the tax refund request may be dependent on this data being a particular age. Hence, even if the mobile device were to be circumvented such that it is forced to accept old authentication data, this would not necessarily enable the tax refund request to be accepted. In order to prevent the authentication data being tampered with in order to extend the time to live, the time to live could be cryptographically signed by the terminal device or point-of-sale device. Other related practices may be used in order to enforce the time based validity of the authentication data. In some embodiments, the authentication data is single use and could be registered by the terminal device or point-of-sale device at a central server after having been issued along with a time to live. In particular, since the authentication data is only valid for a limited period of time this reduces the opportunity of a person to have a fraudulent request accepted since the data must be used almost immediately. This inhibits the user from using old transactions performed by other people in order to claim tax refunds. It also restricts the user’s ability to decrypt any of the data on which the tax refund relies, since a limited window is available for such decryption to occur. This in itself can be used in order to limit the extent to which encryption is necessary, since time limiting the data may make it possible for other, less robust encryption schemes to be used therefore limiting the processing resources required by devices within the system.

In some embodiments, the authentication data comprises at least some of the transaction data in encrypted form. In this way, it is possible to inhibit the transaction data from being used at all if the authentication data cannot be decrypted.

In some embodiments, the user data comprises one of a passport number, a passport, an identity card number, an identity card, a drivers licence number, a drivers licence, a payment card number, a payment card, a card refund operator card number, a card refund operator card, a visitor card number, a visitor card, a user defined identifier.

In some embodiments, in response to the communication circuitry associating the tax refund request, the tax refund request is stored in an electronic wallet on the mobile device. Once the tax refund request has been associated (either a new request generated or an old request identified as belonging to the user) the tax refund request can be stored in an electronic wallet of the mobile device. This makes it possible for the user to track the status of the tax refund request as well as keep track of the tax refund requests that have been submitted.

In accordance with another aspect there is provided an apparatus comprising: transaction input circuitry to input transaction data relating to a transaction; generation circuitry to generate authentication data that verifies authenticity of the transaction; and communication circuitry to provide the transaction data and the authentication data to a mobile device.

The apparatus could correspond with a device that is used by a merchant. In some instances, the apparatus could take the form of a terminal or Point of Sale (PoS) system that the merchant uses for the transaction when the user wishes to purchase goods. In other embodiments, the apparatus may be an additional device used in combination with a PoS system once the merchant has been satisfied that the purchaser (e.g. traveller) is entitled to reclaim tax (e.g. by viewing the traveller’s passport and concluding that the purchaser is a tourist). The transaction input circuitry makes it possible for a merchant to input details regarding the transaction. Such circuitry could take the form of a keypad or barcode scanner or in situations which the apparatus is separate to a PoS system, the transaction input circuitry could take the form of an interface to the PoS system. The generation circuitry is able to generate authentication data that verifies the authenticity of the transaction. This may be dependent on the merchant being satisfied that particular requirements for obtaining a tax refund have been met. However, in some embodiments, the use of the apparatus itself comprises such verification. The communication circuitry is then used in order to provide both the transaction data and the authentication data to a mobile device that is held by the traveller. In this way, once the merchant is satisfied that the tax refund requirements have been met, the apparatus can be operated in such a manner as to provide the authentication data to the user. Such a process may be carried out more quickly than the filling out of paperwork, which may have to be signed by the merchant and/or the traveller as well as the goods in question being listed and various pieces of information including purchase amount and tax amount being calculated and filled in. The merchant can therefore offer this service efficiently.

In some embodiments, the communication circuitry comprises first data transmit circuitry to transmit first data from the apparatus. The first data transmit circuitry may be used to communicate with first data receive circuitry found in the mobile device used by the traveller. In this way, it is possible for the communication circuitry to utilise one or more communications to transmit the necessary data to the traveller.

In some embodiments, the first data transmit circuitry comprises one of: a barcode generator, a QR code generator, Bluetooth circuitry, NFC circuitry, WiFi circuitry, mobile data circuitry, a printer, and a display. There are a number of different ways in which the first data transmit circuitry can transmit the first data from the apparatus to the merchant device. Each of these technologies has particular advantages that will be known to the skilled person. Other known techniques will also be known to the skilled person. Note that since the first data transmit circuitry may include circuitry such as a printer and/or a display the transmission need not be in a manner that is intelligible or exclusively intended for interpretation by a computerised system. In particular the first data could be transmitted in the form of a graphic or text that is presented as part of a display or is printed on a printer (e.g. in the form a receipt). It will be appreciated that there is no need for the first data transmit circuitry to only use one of the different options presented. In some embodiments, the first data transmit circuitry may use a number of the different circuits that have been described or that will be known to the skilled person.

In some embodiments, the first data comprises the transaction data.

In some embodiments, the first data comprises the authentication data. It will be appreciated that in embodiments where both the transaction data and the authentication data are sent as part of the first data that is transmitted by the first transmit circuitry, all of the data that is necessary to be transmitted by the apparatus to the mobile device may be transmitted at once. In such embodiments, the data can therefore be transmitted quickly without the need for request and response scenarios. This can lead to a system in which less processing is required and makes it possible for the decision of which data to be transmitted to be made by the mobile device or enables all data to be transmitted to a server of the Tax Refund Operator for a full analysis of that data to determine the actual eligibility of the traveller to obtain a tax refund. This can be used in order to reduce the complexity of legal or technological changes to the tax refund process, which may change the nature and type of data that is required to be obtained.

In some embodiments, the communication circuitry comprises second data transmit circuitry to transmit second data from the apparatus. Using second data transmit circuitry makes it possible to implement a request/response system in which the apparatus is queried for data that is desired by the merchant device. In this way, it is possible to reduce the overall bandwidth required for the necessary data to be transmitted from the apparatus to the merchant device, since only the necessary data is transmitted.

In some embodiments, the communication circuitry is configured to transmit the second data in response to a request from the mobile device; and the request comprises at least part of the first data. In systems in which a request/response process is configured, the first data may include information that is provided back to the apparatus in order to indicate part of the data that is required. For instance the first data could include a transaction identifier that identifies the transactions that the traveller has just been engaged in. At that point, the mobile device may determine which data is desired for a tax refund request to be made. This could vary according to jurisdiction or could vary according to technological capabilities. A request can then be issued back from the mobile device to the apparatus that includes the transaction identifier together with the data that is required for the mobile device. The second data that is then transmitted can include the requested data.

In some embodiments, the second transmit circuitry comprises one of: Bluetooth circuitry, NFC circuitry, mobile data circuitry, and WiFi circuitry. As in the case with the first data transmit circuitry, the second transmit circuitry could include a number of different circuits and could also include communication technologies that will also be known to the skilled person.

In some embodiments, the second data comprises the transaction data. As previously described, the second data could include the transaction data that is necessary to be transmitted as part of the tax refund request. This makes it possible for the exact content of the transaction data to be customised according to the request issued by the mobile device.

In some embodiments, the second data comprises the authentication data. Similarly to the transaction data, by providing the authentication data in the second data, it may be possible to customise the authentication data in order that the necessary data is authenticated. Similarly, in some systems, it may be possible to customise the degree of authentication that is provided as required by a particular jurisdiction according to legal or technological requirements. For instance, some jurisdictions may require a particular grade of encryption to be used in order to authenticate the data. In some instances, the mobile device itself may provide input as to the type of authentication data that it is capable of receiving.

In some embodiments, the transaction data comprises one or more of a time of the transaction, an amount of the transaction, an identifier of the transaction and a tax amount of the transaction. It will be appreciated that the transaction data is not limited to including just these items of data but that other items of data could also be included. The time of the transaction could be represented in a number of different ways and could be represented merely as a date on which the transaction occurred. The amount of the transaction could also include a currency identifier, particularly where the transaction could have occurred in multiple different currencies. The tax amount of the transaction could represent a proportion of the transaction that was paid as tax, an absolute amount of tax that has been paid, or could be implicitly provided as a consequence of the transaction goods being listed.

In some embodiments, the apparatus comprises: payment response circuitry to receive a payment request from the mobile device for the transaction, to effect the transaction in response to the payment request, and to provide an indication of transaction success to the mobile device. In some systems, the apparatus may also be capable of performing payment. For instance, the apparatus may be capable of receiving a payment request from the mobile device. In such situations, once the payment request has been received and once the payment request has been handled, an indication of the transaction success can be communicated back to the mobile device. In some of these embodiments, the authentication data is produced in dependence on the transaction success. In particular, the authentication data may only be produced once it has been confirmed that the transaction has been successfully carried out. In this way, the authentication data is able to act as a further verification that the transaction has actually occurred, thereby reducing the probability with which fraudulent tax refund requests can be issued. In particular, this may rule out or inhibit the possibility of a user issuing a tax refund request for a transaction that has not completed successfully.

In some embodiments, the authentication data is valid for a validity period after being first provided by the apparatus. The authentication data may only be valid for a period of time after first being provided by the apparatus. For instance, a QR code that is generated by the apparatus in order to provide the authentication data may only be valid for a period of one minute after first being displayed on a display device. In some instances, this can be controlled by the authentication data being removed from display once the validity period has passed. In other embodiments, the validity period may be provided as part of the authentication data (potentially in an encrypted form). In this way, once the authentication is received by the mobile device, the validity period will be checked in order to determine that the authentication data has been validly received. If it turns out that the validity period has expired, then the mobile device may refuse to accept the authentication data. In some embodiments, the authentication data contained in the validity period must be received by the Tax Refund Operator within the validity period. This makes it more difficult for a user that is intent on fraud from attempting to modify or extend the validity period. By using a validity period, it is possible to reduce the extent to which a user can claim a tax refund on goods that they did not actually purchase. For instance, the user will find it significantly more difficult to search for, e.g. receipts, for goods that have been purchased by other people and attempt to claim back the tax from those purchases.

In some embodiments, the authentication data comprises at least some of the transaction data in encrypted form. There are a number of different ways in which the authentication data can be provided. However, in these embodiments, the authentication data includes at least some of the transaction data in encrypted form such that the origin or content of the transaction data can be relied upon with some degree of certainty. For instance, part of the transaction data could be cryptographically signed using a private key that is known to belong to a particular merchant. Using a public key of that merchant can then be used to verify that only the merchant themselves could have performed the encryption in the first place. In other embodiments, a shared key may exist between the merchant and the Tax Refund Operator so that only the Tax Refund Operator and the merchant can read or produce the encrypted data. Again, since the data can be decrypted into a meaningful form by the Tax Refund Operator, it may be assumed that only the particular merchant could have generated the authentication data in the first place. Other techniques such as the use of cryptographic certificates will also be known to the skilled person and also can be used in order to verify the legitimacy of the authentication data.

Particular embodiments will now be described with reference to the figures.

Tax Free Shopping (TFS) is a process in which a visitor or traveller to a country may reclaim the tax that is associated with a particular purchase that the traveller makes. Since the traveller may not be required to pay taxes on particular purchases (as a consequence of being a visitor to the country) it may be possible for certain purchases for that traveller to reclaim the tax that has been paid as part of the purchase. For instance, within the UK a Value Added Tax (VAT) is charged on the majority of non-essential goods. However, a non-resident visitor to the UK may be able to claim back this tax on leaving the country. Typically, the process of reclaiming the goods involves a number of steps. First of all the purchase for the goods must be made. Secondly, the merchant that has sold the goods to the traveller must fill in paperwork relating to the quantity and type of goods and the amount for which those goods have been purchased including any tax. The merchant must then check the customers credentials (e.g. a passport) in order to confirm that the user is a visitor to the country and is therefore eligible for the tax to be reclaimed. All of these details may also have to be completed on the paperwork. A signature and, potentially, a validation stamp of the merchant must then be provided on the paperwork. On leaving the country, the visitor provides this paperwork, together with the goods themselves at a port such as an airport. The paperwork is then checked to determine that the goods were validly purchased by the customer, and once it has been determined that the customer is leaving the country (e.g. if the customer boards a plane or enters the secure area of an airport) then a refund of the paid taxes may be provided to the user. The present invention is made in the recognition that this process is time consuming, particularly for the merchant, and it not technologically efficient.

Figure 1 illustrates a system 100 comprising a network 160 in which a number of devices according to embodiments of the present invention are connected. A terminal device 110 is provided that is operated by the merchant. The terminal device 110 may be or may incorporate a Point of Sale (PoS) device that facilitates the transaction. However, this is not essential. The user operates a mobile device 120. This could take the form of, for instance, a mobile phone or tablet, or could constitute a dedicated device for the purpose of Tax Free Shopping. The system 100 also includes a registration server 130 that makes it possible for the user of the mobile device 120 to register for Tax Free Shopping. Such registration could take place via the mobile device 120 itself or could take place via another device such as a home computer or PC. During the registration process, the user provides personal details such as a scan or photograph of a passport, or other details that may establish a Tax Refund Operator 150 to determine the edibility of the user for Tax Free Shopping. This could, for instance, take place as a result of the mobile device 120 being used to read the Machine Readable Zone (MRZ) of a passport. This can then be provided to a Tax Refund Operator 150 that provides a special token (e.g. a unique identifier for the user). In the future, when a tax refund request is made, the user of the mobile device 120 may associate this with their own registration by providing the token. Accordingly, it may be possible for the user to make tax refund requests without the need to continually provide passport information. The Tax Refund Operator (TRO) 150 may include a number of different systems that are directly towards determining the eligibility of a user for tax refunds. The system 100 may also include a payment gateway 140, which is used to effect the transaction for which the user claims a tax refund. The payment gateway 140 may be used as part of the terminal device 110.

Figure 2 illustrates an example of communications between some of these devices. Within this process 200, a transaction request 210 is made from the terminal device 110 to the payment gateway 140 including the amount of a transaction and also an account ID that has been provided by the traveller for the purposes of paying for this transaction. Once the transaction request has been received by the payment gateway 140, the transaction is performed. This may require the interchange of further communications between the payment gateway 140 and other devices such as banking computers and so on in order to transfer funds from the traveller’s payment account to the merchant account. Once the payment gateway 140 is satisfied that the transaction has been effected, a transaction result 220 is returned from the payment gateway 140 to the terminal device 110. The transaction result 220 includes an authorisation code that can act as a “receipt” for the transaction in question. The authorisation code may therefore act as verification that the transaction has been completed successfully. Up until this point, the transaction has proceeded normally.

At this stage, however, the merchant may indicate that the user wishes the transaction to be considered for a tax refund. This could occur, for instance, once the merchant has checked the eligibility of the user for receiving a tax refund (e.g. by providing credentials to the merchant that demonstrate that the user is non-resident such as a passport). In some embodiments, no check is necessary and instead, eligibility is determined by the Tax Refund Operator themselves. In any event, when the process for a tax refund is to proceed, the terminal device 110 issues a first item of data in the form of a Bluetooth communication 230 to the mobile device 120, which could take the form of the user’s mobile phone for instance. This first data that is transmitted includes a time, purchase amount, amount of tax, and identifier of the transaction that has occurred. In addition, the communication includes authentication data that has been generated by the terminal device 110 that verifies at least some of this data.

In this example, the authentication data contains cryptographically encoded information that cannot be seen or modified by the user, but can be decrypted by the

TRO. This could, for instance, be a ‘hash’ of the transaction data. In addition, the authentication data contains a timestamp and a time-to-live - a period of time by which any tax refund must be made to the Tax Refund Operator. The timestamp and time-to-live are signed so that they can be read by anyone, but cannot be modified without detection. The authentication data is received by the mobile device 120. Once the mobile device 120 receives the authentication data, it checks the authentication data to ensure that the validity period is met. If not, the mobile device 120 discards the authentication data, since it cannot be used. In other embodiments, the mobile device 120 may indicate to the terminal device 110 that revised authentication data is necessary. In other embodiments, the hash could be signed so that it can be checked by the mobile device for validity (and discarded if found to be invalid). Alternatively, the transaction identifier itself could act as the authentication data if the TRO directly queries the transaction with the merchant in order to authenticate it.

Assuming that the authentication data is obtained and found to be valid (or if the authentication data is obtained and no checking takes place) then a refund request 240 can be issued from the mobile device 120 to the Tax Refund Operator 150. The refund request includes the amount of tax that was paid during the transaction, the authentication data that was generated by the terminal device 110, and user data that was stored by the mobile device 120 and identifies an eligibility of the user for receiving a tax refund. As previously explained, this could include passport data but could also include a token that is generated during a registration process with a registration server 130.

Having received the refund request, the Tax Refund Operator 150 considers the authentication data. In particular, a number of checks may be performed on this authentication data to ensure that it reflects the transaction that is alleged to have occurred. For instance, if the authentication data includes encrypted data, then the Tax Refund Operator 150 decrypts the data and ensures that everything is in order. In the case of digital signatures, the Tax Refund Operator 150 checks that the signed data is intact and unmodified (otherwise it may be disregarded and the request refused).

Furthermore, if cryptographic certificates are used, then the validity of the certificates will be checked to ensure that they have not been revoked, that they are still within their validity period, and that they correspond with entities that are trusted by the Tax Refund Operator 150. The Tax Refund Operator 150 also checks the validity period that is stored with the authentication data, if it is present. If the validity period has expired, then the Tax Refund Operator 150 may reject the refund request.

Having performed any initial checks, a refund response 250 is issued back from the Tax Refund Operator 150 to the mobile device 120. This includes an application code, which is a unique identifier for the particular refund request that was made. In addition, the refund response 250 includes a status that indicates the outcome of the refund request. Note that in some instances, the refund responses status may be ‘pending’ until the user actually leaves the country, at which point the request can be fulfilled (if it is considered to be valid).

It will be appreciated that as a consequence of the above process, the merchant is involved to a much more limited extent. The processing, and the tracking of the request is performed by the user that receives the relevant information from the merchant. This makes it possible for the processing to be ‘offloaded’ to the user.

In Figure 3, some of the steps have been varied. In particular, the transaction request 310 and the transaction result 320 proceed as previously described with reference to Figure 2. At this point, the terminal device 110 provides a receipt 330 that indicates the time of the transaction, the amount of the transaction, and an amount of tax that has been paid. This could be, for instance, printed using a printer. The mobile device 120 can receive this receipt by means of a camera on the mobile device 120 that incorporates optical character recognition (OCR) in order to parse and input the data that is provided on the receipt. Shortly after having printed the receipt, the terminal device 120 also uses a visual display in order to provide a QR code 340. The QR code has encoded within it the amount of the transaction together with authentication data verifying the transaction that has taken place. As previously described, the authentication data may include a validity period that indicates the length of time for which the authentication data is valid. This could be provided as a time stamp for instance. The mobile device 120 can again use the camera of the mobile device 120 in order to interpret the QR code and thereby extract the data. Then, as previously described, a refund request can be issued by the mobile device to the Tax Refund Operator 150 and a refund response 360 may be issued with the application code and the status of the response.

Figure 4 illustrates a further variant of the process 400. Once more, a transaction request 410 and a transaction result 420 are issued between the terminal device 110 and the payment gateway 140. At this point, the terminal device 120 then provides a transaction ID to the mobile device 120 via Near Field Communication (NFC). This NFC communication 430 includes a transaction ID that identifies the transaction that has taken place. Once the transaction ID has been received, the mobile device 120 issues a request back to the terminal device 110 requesting full data. This request includes the transaction ID that was received by the mobile device 120 together with the list of requested data that can be used to issue a tax refund request. The terminal device 110 then responds by providing, via WiFi, the requested data in the form of: the time, amount, and amount of tax of the transaction corresponding with the transaction ID. In addition, authentication data corresponding to this transaction data is transmitted to the mobile device 120. The authentication data acts as a digital ‘signature’ for the time, amount, and amount of tax. Consequently, this information cannot be modified without the change being detected.

In this way, the transaction data and the authentication data that are transmitted by the terminal device 110 to the mobile device 120 includes only data that is explicitly requested by the mobile device 120. The mobile device 120 can therefore limit itself to requesting only that data that it understands will be required for a tax refund request to be made. This could be effected based on the local legal or technological requirements. For instance, if the authentication data includes information that uses a cryptographic certificate to verify the authenticity, then the mobile device 120 may be aware that only a small amount of information is necessary due to the data being inherently trusted. As a consequence, the mobile device 120 may only require the amount of tax that has been paid in the transaction. Alternatively, in a situation in which the user has only registered using a name and address, and in which the authentication data is nothing more than a low level encryption of the transaction data (or absent entirely), then it may be less likely that the transaction will be trusted and consequently more transaction data may be required for the mobile device 120 to be provided to a server of the Tax Refund Opperator (TRO) 150 for the tax refund request to be made. In either event, it will be appreciated that the amount of data can be customised based on the current situation, jurisdiction, and other factors so that only the necessary data is transmitted, thereby reducing the bandwidth consumption.

Having received the necessary data at the mobile device 120, a print operation 460 is performed that prints a tax refund request form including the necessary data. This data could include the authentication data in encrypted form or could include a reference to a location of the authentication data in such a way as the authentication data can be electronically or digitally received by a server of the TRO 150 at a later time. For instance, the authentication data that is provided as part of the form could include a URL where the digitally certified authentication data can be downloaded at the TRO server 150. Having performed the print operation 460 this can then be hand delivered by the user to the TRO 150. In some embodiments, the user could hand over their mobile device 120 to the TRO 150 who is then able to print the form.

In the embodiments described with reference to Figures 2, 3 and 4, the transaction and the tax refund request are made simultaneously. However, in Figure 5, a previous tax refund request that has been made is able to be associated with the user. In particular, the user acquires an issue slip that relates to a previous tax refund request, which may have been electronically submitted by the merchant. The issue slip contains the transaction identifier in a machine-readable format such as a barcode 520.

The mobile device 120 scans the machine-readable data on the issue slip in order to acquire transaction identifier data that was generated by the merchant. The user is then able to perform an input operation 530 in which they input details relating to the transaction. This could be achieved by the use of a camera that is able to scan a receipt, or could be manually input by the user. The mobile device 120 is then able to issue a request to the TRO server 150 including the amount of the previous transaction and the transaction identifier associated with the previous transaction. This enables the TRO server 150 to associate the previously made tax refund request for that transaction with the current user and mobile device 120. The result of the attempt 540 to attach the refund request to the user can then be provided as part of an AttachResponse communication sent back 550 from the TRO server 150 to the mobile device 120. This includes not only an application code of the previously made tax refund request, but also a status of the attempt to perform the attachment.

It will be appreciated that many of the individual steps described with reference to the embodiments shown in Figures 2 to 5 can be mixed and exchanged. Furthermore, a number of alternatives for such steps may be provided. For example, in respect of the first data that is transmitted, examples have been shown in the form of Bluetooth communication, communication via a receipt using image recognition circuitry, NFC communication, barcode reading, and manual inputs. However, other forms of communication could be used including WiFi, and mobile data. Each of these techniques can also be used in respect of the transmission of the second data, for which examples have been provided in the form of the use of a QR code and a WiFi communication.

It will also be appreciated that the makeup of the first data and the second data can be varied. In some of the above examples, the first data includes transaction data. In some of the above examples, first data includes authentication data as well as or instead of the transaction data. Similarly, the second data could include transaction data and the second data could include authentication data instead or as well as the transaction data.

Still furthermore, as each of the above examples has demonstrated, the data could be provided proactively or could be provided on request. By providing the data on request, as shown with reference to Figure 4 for instance, control can be kept over the extent to which data is transmitted, thereby preserving bandwidth. Alternatively, by proactively providing data, the exchange of data between the mobile device 120 and the terminal device 110 can be kept simple while also performing the interchange quickly by removing the need for a request/response mechanism.

Figure 6 illustrates examples of the makeup of the mobile device 120 the terminal device 110. In the example shown in Figure 6, the mobile device includes obtain circuitry 610 that is used to obtain both the transaction data relating to a transaction performed by the terminal device 110 and the authentication data that verifies the authenticity of that transaction. In this example, the obtain circuitry 610 includes first data receive circuitry 615 to receive first data, and second data receive circuitry 620 to receive second data. As previously explained, the first data and the second data could variously correspond with the transaction data and the authentication data, alternatively, the first data or the second data could include all of the transaction data and the authentication data. In other embodiments, part of the transaction data and part of the authentication data may be included in the first data and the other parts could be included in the second data. In some embodiment, there may be no second data at all, and everything could be provided in the first data. Other combinations will be known to the skilled person.

In addition, the mobile device 120 includes storage circuitry 625 that stores user data. This user data may be used in the tax refund request in order to identify the user as well as to determine an eligibility of the user to perform tax free shopping. As previously explained, the user data could correspond with a token that is provided during a registration process with a registration server 130 after the user registers identity documents with the registration server 130 which therefore removes the need for the user to continue to supply data relating to the identity information each time a tax refund request is made. Communication circuitry 605 is provided in order to transmit the user data and the authentication data to the server of the TRO 150. In some embodiments, the request that is made by the communication circuitry 605 may also include the transaction data itself, whilst in other embodiments, the authentication data may include the transaction data in encrypted or signed form. Accordingly, there may be no need for the transaction data to be separately included provided the TRO server 150 can decrypt the authentication data in order to extract the transaction data. In this embodiment, the mobile device 120 also includes payment request circuitry 630. The payment request circuitry 630 is provided in order to perform payment for a transaction.

Figure 6 also illustrates an example of a terminal device 110 that may be used by a merchant in order to effect a transaction. The terminal device 110 includes transaction input circuitry 656 into which the merchant is able to input transaction data relating to a transaction. This could take the form, for instance, of a network connection or other hardware connection to a PoS system that is responsible for actually performing the transaction. In other embodiments, this could constitute an input device such as a keypad into which the merchant can enter details of the transaction that has taken place. Other forms of input will be known to the skilled person. The terminal device 110 also includes generation circuitry 635 that is used to generate authentication data that verifies an authenticity of a transaction that has been input via the transaction input circuitry 655. The generation circuitry 635 could operate autonomously, or could operate as a result of the merchant entering a password or PIN or pressing a button to indicate that they are satisfied that they have fully reviewed the credentials offered by the traveller in order to demonstrate their tax exemption status. The generation circuitry can operate by generating the authentication data using cryptography. For instance, the generation circuitry could encrypt (e.g. using a symmetric or asymmetric key) part or all of the transaction data.

In some embodiments, the transaction data could merely be signed by the generation circuitry. The signature could constitute a hash of the transaction input circuitry being generated using one part of an asymmetric key. The other part of the asymmetric key can then be used to determine whether the hash corresponds with the underlying transaction data. As previously discussed, cryptographic certification can also be used in order to verify the authenticity of the merchant. Again, such techniques will be known to the skilled person. Communication circuitry 640 is provided in order to provide the transaction data and the authentication data to the mobile device 120. Similarly to the obtain circuitry 610 of the mobile device, the communication circuitry in this example includes first data transmit circuitry 645 for transmitting first data and second data transmit circuitry 650 for transmitting second data. Of course, as previously stated, in some embodiments only first data may be transmitted by the terminal device and received by the mobile device 120.

Also in this example, payment response circuitry 660 is provided. The payment response circuitry 660 is provided to communicate with the payment request circuitry 630 of the mobile device 120. The payment response circuitry 660 makes it possible to effect a transaction between the traveller using the mobile device 120 and the merchant using the terminal device 110. In this way, the terminal device 110 is able to determine that the transaction has occurred successfully. The output of the generation circuitry 635 - e.g. the authentication data may therefore be predicated on the payment response circuitry 660 indicating that the transaction has successfully occurred. In this way, it is possible to tie the generation of the authentication data, which is necessary for the tax refund request to be completed, to verification that the transaction has actually occurred. In this way, it is possible to provide further security to determine whether the tax refund that eventually occurs is being made in respect of a transaction that actually happened.

Figure 7 illustrates the use of an electronic wallet that can be used in order to track the status of tax refund requests. The electronic wallet forms part of the operation of the mobile device 120, which in this example is a smart phone. The interface provides the user with the opportunity to add a new tax refund request using an add button 700. This process will initiate the payment request process (where payment request circuitry 630 and the payment response circuitry 660 are in use) and in any event will initiate the process of acquiring the first data and second data from the terminal device 100 using, for instance, one of the processes described with reference to Figures 2 to 5. Having acquired this information, the ID of the tax refund request application, the amount the request is made in respect of, and the current status of the request are then illustrated in a table 720.

In addition, an association of an existing tax refund request may be made using the import button 710. Here, a process corresponding with the example illustrated with reference to Figure 5 may take place in which the user utilises an issue slip together with the scanning of a bar code in order to allow a transaction to be input together with authentication data. An attachment request can then be issued to the TRO server 150 in order to import or associate or attach the exiting tax refund request with the current user. The relevant data can then be transmitted back to the mobile device 120 where it can be inserted into the table 720. In this way, it is possible for a user to keep track of all of their tax refund requests. This can include tax refund requests that are made directly on the mobile device 120 as well as tax refund requests that are made using older technologies that are imported later.

Figure 8 illustrates a flow chart 800 that indicates a method in accordance with some embodiments associated with the mobile device 120. At a step 810, user data is stored. This could take place as a consequence of the user entering identification information and may be followed by the acquisition of a token when the user registers this identification information with a registration server 130. The user data may therefore take the form of the identification data and/or token as appropriate. Having stored this data, transaction data is then acquired at step 820. As previously described, this transaction data may occur in a number of different ways. At a step 830, authentication data is acquired. Again, as previously described, the transaction data and the authentication data could be acquired in any order and could be acquired simultaneously across multiple communications or even in a single communication. Having acquired all of this information, an association request is then made by transmitting the transaction data and the authentication data to a TRO server 150 that cause the tax refund request to be associated with the user. In the case of a new tax refund request this will cause a new request to be generated and in the case of an existing request, the request will be “attached” to the user.

Figure 9 illustrates an example of a method in accordance with some embodiments. These embodiments may have relevance to the operation of the terminal device 110. The method is illustrated in the form of a flow chart 900. At a step 910, the transaction data is received by the terminal device 110. At a step 920, authentication data is generated based on the transaction data. At a step 930, the transaction data is provided to the mobile device 120, and at a step 940, the authentication data is provided to the mobile device 120. It will be appreciated that the provision of the transaction data and the authentication data can occur in any order. In particular, the transaction data could be provided after having been received at step 910 but before the authentication data is generated at step 920. The authentication data can, naturally, be provided at any time after its generation at step 920.

Accordingly, it can be seen that by means of the above examples, it is possible to simplify the operation of the tax refund process. In particular, it is possible for the traveller themselves to issue the tax refund request, thereby freeing up the resources of the merchant. Furthermore, it is possible for the user to maintain oversight of the tax refund requests that have been made through the use of an electronic wallet. These processes are more efficient and more user-friendly than traditional methods. Furthermore, such processes may be performed more quickly than may otherwise be possible.

In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. A mobile device comprising:

storage circuitry configured to store user data;

obtaining circuitry configured to obtain transaction data relating to a transaction performed by a terminal device or point-of-sale device and to obtain authentication data that verifies authenticity of the transaction; and communication circuitry configured to associate or initiate a tax refund request with the user in respect of the transaction, wherein the tax refund request comprises the user data and the authentication data.

2. A mobile device according to claim 1, wherein the obtaining circuitry comprises first data receive circuitry to receive first data from the terminal device or point-of-sale device.

3. A mobile device according to claim 2, wherein the first data receive circuitry comprises any combination of: a barcode reader, a QR code reader, Bluetooth circuitry, NFC circuitry, WiFi circuitry, mobile data circuitry, and image recognition circuitry.

4. A mobile device according to any one of claims 2-3, wherein the first data comprises the transaction data.

5. A mobile device according to any one of claims 2-4, wherein the first data comprises the authentication data.

6. A mobile device according to any one of claims 2-5, wherein the obtaining circuitry comprises second data receive circuitry to receive second data from the terminal device or point-of-sale device.

7. A mobile device according to claim 6, wherein the obtaining circuitry is configured to request the second data from the terminal device or point-of-sale device by providing at least part of the first data.

8. A mobile device according to any one of claims 6-7, wherein the second data receive circuitry comprises any combination of Bluetooth circuitry, NFC circuitry, mobile data circuitry, and WiFi circuitry.

9. A mobile device according to any one of claims 6-8, wherein the second data comprises the transaction data.

10. A mobile device according to any one of claims 6-9, wherein the second data comprises the authentication data.

11. A mobile device according to any preceding claim, wherein the transaction data comprises one or more of a time of the transaction, an amount of the transaction, an identifier of the transaction and a tax amount of the transaction.

12. A mobile device according to any preceding claim, comprising payment request circuitry to initiate a payment request to the terminal device or point-of-sale device for the transaction; and the communication circuitry is adapted to initiate the tax refund request in response to an indication from the payment request circuitry that the payment request is successful.

13. A mobile device according to any preceding claim, wherein the authentication data is valid for a validity period after being first provided by the terminal device or point-of-sale device.

14. A mobile device according to any preceding claim, wherein the authentication data comprises at least some of the transaction data in encrypted form.

15. A mobile device according to any preceding claim, wherein the user data comprises one of a passport number, a passport, an identity card number, an identity card, a drivers licence number, a drivers licence, a payment card number, a payment card, a card refund operator card number, a card refund operator card, a visitor card number, a visitor card, a user defined identifier.

16. A mobile device according to any preceding claim, wherein in response to the communication circuitry associating the tax refund request, the tax refund request is stored in an electronic wallet on the mobile device.

17. A method comprising:

storing user data;

obtaining transaction data relating to a transaction performed by a terminal device or point-of-sale device;

obtaining authentication data that verifies authenticity of the transaction; and associating or initiating a tax refund request for the user in respect of the transaction, wherein the tax refund request comprises the user data and the authentication data.

18. An apparatus comprising:

transaction input circuitry to input transaction data relating to a transaction;

generation circuitry to generate authentication data that verifies authenticity of the transaction; and communication circuitry to provide the transaction data and the authentication data to a mobile device.

19. An apparatus according to claim 18, wherein the communication circuitry comprises first data transmit circuitry to transmit first data from the apparatus.

20. An apparatus according to claim 19, wherein the first data transmit circuitry comprises one of a barcode generator, a QR code generator, Bluetooth circuitry, NFC circuitry, WiFi circuitry, mobile data circuitry, a printer, and a display.

21. An apparatus according to any one of claims 19-20, wherein the first data comprises the transaction data.

22. An apparatus according to any one of claims 19-21, wherein the first data comprises the authentication data.

23. An apparatus according to any one of claims 18-22, wherein the communication circuitry comprises second data transmit circuitry to transmit second data from the apparatus.

24. An apparatus according to claim 23, wherein the communication circuitry is configured to transmit the second data in response to a request from the mobile device; and the request comprises at least part of the first data.

25. An apparatus according to any one of claims 23-24, wherein the second transmit circuitry comprises one of: Bluetooth circuitry, NFC circuitry, mobile data circuitry, and WiFi circuitry.

26. An apparatus according to any one of claims 23-25, wherein the second data comprises the transaction data.

27. An apparatus according to any one of claims 23-26, wherein the second data comprises the authentication data.

28. An apparatus according to any one of claims 18-27, wherein the transaction data comprises one or more of: a time of the transaction, an amount of the transaction, an identifier of the transaction and a tax amount of the transaction.

29. An apparatus according to any one of claims 18-28, comprising:

payment response circuitry to receive a payment request from the mobile device for the transaction, to effect the transaction in response to the payment request, and to provide an indication of transaction success to the mobile device.

30. An apparatus according to any one of claims 18-29, wherein the authentication data is valid for a validity period after being first provided by the apparatus.

31. An apparatus according to any preceding claim, wherein the authentication data comprises at least some of the transaction data in encrypted form.

32. A method comprising:

receiving transaction data relating to a transaction;

generating authentication data that verifies authenticity of the transaction; and providing the transaction data and the authentication data to a mobile device.