WO2015121172A1

WO2015121172A1 - Method and system

Info

Publication number: WO2015121172A1
Application number: PCT/EP2015/052548
Authority: WO
Inventors: Puay Hiang Tan; Richard MENZINSKY
Original assignee: Global Blue SA
Current assignee: Global Blue SA
Priority date: 2014-02-11
Filing date: 2015-02-06
Publication date: 2015-08-20
Anticipated expiration: 2016-08-11
Also published as: JP2017505478A; JP7003383B2; JP6489712B2; JP2019117643A; KR102096692B1; KR20160119098A; MY175707A

Abstract

A refund system provides for detections of eligibility of a user for a refund and uses a token to identify purchases and to retrieve the information in respect of those purchases for processing a refund in respect of those purchases.

Description

SYSTEM AND METHOD FOR OBTAINING TAX REFUNDS ASSOCIATED WITH

PURCHASES

BACKGROUND

The present invention relates to apparatus, systems and methods for obtaining tax refunds associated with purchases.

Tax refund systems are offered in many countries for travellers. Providing tax free shopping can be attractive to visitors to a country and can help to promote tourism. However, traditionally, the administration for tax free shopping schemes has been paper-based with merchants issuing vouchers or cheques at a point of sale, and then customs verifying the export of the goods at a border. Although regulations vary from country to country, the traditional format for providing tax free shopping is for a merchant in a country to identify and verify that a user (customer) is a visiting traveller entitled to a tax refund, then to issue the voucher that includes details of the user and the purchased item, and then for customs to verify at the point of exit from the country that an item being exported and that the user corresponds to the item and traveller identified on the voucher. The refund can then be made. Tax refund operators act with merchants and customs to facilitate the operation of this process and to manage the paperwork associated therewith.

Such a process was traditionally very labour and cost intensive. Also, as discussed above one aspect of the process is determining whether a user is a traveller eligible to receive a tax refund. Various approaches have been proposed for attempting automatically to make such a determination. For example, WO 2004/081838 proposes that a user carries an information carrier such as a card for identifying the user that can be read by a terminal. WO 2005/057453 proposes that a user is provided with a smart card that identifies the user and the user's country of residence. However, the user needs to carry a card in addition to a card used for payments. WO 03/079249 proposes that a determination of eligibility for a VAT refund is based on an issuer code read from a payment card. However, maintaining accurate issuer records in terminal systems and/or in hosts connected to terminal systems provide significant technological challenges, due to the need to keep records updated and available to terminals.

The present application is directed to providing automatic determination of eligibility to receive a tax refund based on a payment card used by a user without needing to rely on the storage and maintenance of issuer codes. The present invention seeks to provide a

technological solution to such problems. SUMMARY

Aspects of the invention are defined in the claims.

An example embodiment comprises a computer-implemented method of conducting a transaction, the method comprising:

determining account currency information identifying a currency associated with an account of a user for conducting a transaction for the user;

comparing the account currency information to reference currency information identifying a reference currency; and

where the account currency information is different from the reference currency information, initiating a tax refund offering for the user in respect of the transaction.

An example embodiment provides a computer- implemented method comprising:

determining whether an account currency code carried by a payment card read by a card reader of a transaction terminal system is different from a currency code for the transaction terminal system, and where an account currency code carried by a payment card read by the card reader is determined to be different from the currency code for the transaction terminal system, automatically providing a tax refund offering to the user.

An example embodiment provides a program product comprising program instructions for carrying out such a computer-implemented method.

An example embodiment provides a system comprising at least one processor, the system configured: to determine account currency information identifying a currency associated with an account of a user for conducting a transaction for the user; to compare the account currency information to reference currency information identifying a reference currency; and where the account currency information identifies an account currency different from the reference currency identified by the reference currency information, to initiate a tax refund offering for the user in respect of the transaction.

Although various aspects of the invention are set out in the accompanying claims, other aspects of the invention include any combination of features from the described embodiments and/or the accompanying dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are described, by way of example only, with reference to the accompany drawings. Figure 1 is a schematic block diagram illustrating an example of a simple refund approach;

Figure 2 is a schematic diagram of an example embodiment of a refund system according to an embodiment of the invention;

Figures 3 to 5 are flow diagrams illustrating example operations;

Figure 6 is a schematic system overview;

Figures 7-9 are flow diagrams illustrating example operations.

DETAILED DESCRIPTION

Figure 1 illustrates a simple approach to obtaining a refund of tax associated with a purchase. The approach illustrated in Figure 1 includes a user (a traveller) receiving a conventional store receipt from a merchant on making a purchase. The store receipt, together with the goods, is then presented to customs. Customs then determines eligibility and validates the store receipt. The tax authority then accepts the validated receipts, processes the tax refund, and makes payment to the user.

There are a number of disadvantages with such a system, both from a commercial and technical point of view. The merchant in such a system has no relationship with the traveller. Unless the traveller is already aware of his eligibility for a tax refund, there is no additional in- store activity to stimulate traveller sales. The traveller perception after a purchase if no refund is received is not positive and the number of non-refund eligible customers in this simple system is high. Also, a traveller is unable to claim a refund if the traveller forgets to obtain the necessary paperwork on departure.

Further, the tax authority is required to issue refund forms, collect completed forms and receipts, process the claims, and issue payments. The administration of keeping track of shop receipts with the traveller and with each shop is substantial and this is necessary to be able to have reconciled tax declarations from the merchants. Further, dispute resolution and enquiries from travellers and merchants must also be handled by the tax authority.

An example embodiment maintains simplicity of operation but addresses both the integrity and usability shortcomings of prior approaches. In the example embodiment at least one system coordinates processing of purchases and refunds using a payment card of a user. The at least one system can be operated by a Tax Refund Operator (TRO). As well as providing administration of the refund operations, the TRO can provide education for a traveller and merchants throughout the process. Through the use of information technology systems, the TRO can ensure the integrity of the system.

Figure 2 illustrates example methods, apparatus and systems for managing a refund process. In the example process shopping and receiving of a receipt (issuing 30) is separated from further processing (acquiring 32, authorisation 34 and payment 36).

As with credit and debit cards, there can be multiple providers of issuing services, and multiple acquirers of transactions and processing. For example there can be multiple TROs. The issuing of transaction can follow a standard message type for transmission to an authorization and payment system. A wide range of point of sale (POS) devices and in-store support for traveller shopping can be provided.

In an example embodiment, a merchant system provides the issuing 30 of transactions using TRO provided POS devices and/or software, a TRO host system carries out the acquiring 32, a customs approval system carries out the authorization 34 and a TRO host system carries out the refund payment 36 using a kiosk (validation station) at a point of exit from a territory. In an example embodiment, the determination of eligibility for a refund is based on reading information from a payment card. An example embodiment can provide the simplicity of use of the approach described with reference to Figure 1 as perceived by the users of the system, while also providing enhanced integrity.

In a conventional approach, shop assistants and counter cashiers are expected to be able to verify eligibility for a tax refund by examining the passport of the traveller. In fact, many travellers are reluctant to carry their passports while out shopping, and so in practice shops permit the traveller to fill in such details that are required on refund vouchers after leaving the shop.

In contrast thereto, in an example embodiment, potential eligibility can be determined automatically from the traveller' s use of a payment card. By providing automated

determination of eligibility, the dependence on people who are less well trained can be reduced.

In an example embodiment, a terminal system is operable to read information from a payment card, and to determine whether the payment card is an EMV card (named after Europay, MasterCard, and Visa who developed the technology), that is a card with an electronic chip, and if so, to determine whether the card carries an Application Currency Code (ACC) for determining whether the ACC is the same as the currency used by the terminal system or not. If the latter is the case, then it can be determined that the payment card is for a currency "foreign" to that used by the terminal system and accordingly that a tax refund offer can be made to the user.

In an example embodiment, for terminal systems in countries for which only EMV cards are issued, if the payment card is determined not to be an EMV card, then it can also be determined automatically that the card was issued in a jurisdiction foreign to that of the terminal system and tax refund offer can be made to the user. For example, for cards provided with a magnetic stripe there is an indicator on both track 1 and 2 (Service Code Digit 1) of the magnetic stripe to indicate if the card is an EMV chip card. Thus, if a magnetic stripe card is used and Service Code Digit 1 is not 2 or 6, then the card can be determined to be a magnetic- stripe only card and not an EMV card.

As a result of determining that the ACC code is for a "foreign" currency and/or (where applicable) that the payment card is not an EMV card, then a tax refund offering can be made automatically. In one example a refund transaction record providing an association between the payment card, or another token, and a transaction identifier (e.g. a sales receipt) for a purchase transaction for at least one purchase can be initiated automatically. In another example, a merchant can receive a message to invite the user to proceed to a tax refund issuing desk to process a refund. In various examples, a payment card, or other token, can then be used subsequently to retrieve the record of the transaction(s) on exit from the territory to validate the refund on the purchases.

In the following a system and method of an example embodiment of a tax refund system for a territory is described with reference to Figure 2 in which multiple TROs affiliate merchants, and then provide tax refunds to travellers through the user of a self-service kiosk 22 at an exit point from a territory.

In a first stage 102 a user can optionally associate a payment card or another token to the user and this information could be stored in a central record. This can be done before or at a point of entry to the territory or at a point of sale. The user can choose a payment card or token to be used. The user could specify, for example via a website or at a point of sale terminal or in response to being asked by a merchant, a particular token to be used. For example, a user can register his/her details and associate his/her details with the payment card or token by registering on a web site provided by a TRO. The TRO can then provide information to the user about refund opportunities and processes. Alternatively, or in addition, the user could be issued with a token (for example a visitor card). User details can then be recorded in an input station local to the point of issue, for example at the point of entry or at a point of sale, or the issued token could be linked to user details pre-entered on the TRO website. A suitable input station can include, for example, a computer processor and memory, at least one input interface in the form of at least one of a keypad, a keyboard, a touch sensitive screen, a card reader, a machine readable identifier reader, a document scanner, a voice- activated input, and at least one output interface in the form of at least one of a display, a printer, a card writer, a speaker. The input station could also be provided with a finger print reading and/or camera technology for verifying biometric information held on a machine readable user identifier (e.g., an ID document such as a passport).

The token identifier (for example a number unique to the token) and/or the payment card details along with details of the user (the traveller) can be provided 103 to and held at an acquiring host server system 20 where the identifier and the user details are recorded (stored). The host server system 20 can comprise at least one server computer, each comprising at least one processor and memory, located in a single place or in a distributed system. The efficiency of the system is enhanced where the identifier for the token and the details of the user are forwarded to the host server system and are recorded in real time.

In a next stage 104, the user 12 can make purchases, for example at a merchant. Figure 3 illustrates an example of step 104 in more detail.

With reference to Figure 3, when the user provides a payment card for payment, a payment card reader (e.g. a magnetic stripe reader, contact chip reader or near field

communications (NFC) card reader), can be operable to read information from the payment card.

For example, in step 302, in the event that the terminal system reads the card using a magnetic stripe reader, the terminal system can be operable in step 304 to determine if the magnetic stripe on the card includes a Service Code Digit 1 (e.g. on track 1 or 2 on the magnetic stripe) that is 2 or 6. If it is determined in step 304 that the magnetic stripe on the card includes a Service Code Digit 1 (e.g. on track 1 or 2 on the magnetic stripe) that is 2 or 6, then the terminal system determines that the card is an EMV card, and the terminal system can be operable to display a message on a display of the terminal system to the user and/or the merchant for prompting the user to present the payment card to a contact chip reader for the EMV card.

In other words, when reading a card via the magnetic stripe reader, contact chip capable devices examine the Service Code on the magnetic stripe to determine if the card is chip enabled (2xx or 6xx). If the Service Code indicates that the card is chip enabled, the device prompts the cardholder or merchant to insert the card into the contact chip reader, unless operating under fall-back conditions.

If the terminal is in a country in which only EMV cards are issued, and the Service Code Digit 1 (e.g. on track 1 or 2 on the magnetic stripe) is determined in step 304 to be anything other than a 2 or 6, then it can be determined automatically that the payment card is a foreign card and that a tax refund offering can be made to the user in step 306 as described later.

If the chip of an EMV card is read by a contact chip reader of the transaction terminal system in step 308 or 310 or via a Near Field Communications (NFC) interface of the transaction terminal system in step 312, in step 314 it is determined whether an Application

Currency Code (ACC) is provided on the EMV chip.

If in step 314 an ACC is read from the card, then in step 316, the transaction terminal system is operable to determine whether the currency represented by the ACC is the same as a currency associated with the transaction terminal system (hereinafter also referred to as a local currency), which can be represented as a Terminal Currency Code (TCC). In this step the

ACC read from the card can be compared to TCC stored in storage in the transaction terminal system to determine whether the currency represented by the ACC is the same as the currency associated with the transaction terminal system.

If in step 316, it is determined by the transaction terminal system that the ACC is not the same as the TCC, then it can be determined automatically that the payment card is a foreign card and that a tax refund offering can be initiated for the user in step 306 as described later.

If in step 316, it is determined by the transaction terminal system that the ACC is the same as the TCC, then it can be determined automatically that the payment card is a local card and that a transaction is to be performed in step 318 without making a tax refund offering.

If in step 314, it is determined that no ACC is read from the EMV chip, then in step 320, the transaction terminal system can initiate an alternative process. For example, the user could be asked by the merchant whether the user is a traveller and wishes to receive a tax refund offering.

The transaction terminal system can be programmed to carry out the steps illustrated in Figure 3 by program code held in storage of the transaction terminal system and operable to control at least one processor of the transaction terminal system. Figure 4 illustrates one example of a process for step 306 for initiating and providing a tax refund offering.

In step 400 the process of creating a transaction record starts.

Either the payment card number (e.g. a credit card number CC #) for the payment card can be used in step 402 or an identifier of another token can be used in step 404 by the transaction terminal system to access details of the user via a network from traveller records held in storage at a TRO host system 20 for creating a transaction record. The transaction terminal system can create a transaction record using the retrieved user details.

In step 406, optionally a merchant or user can be prompted to enter passport details. This could be effected by manual entry of a passport number or other traveller identifier or by using a passport reader to read user details from a passport or other travel document. The transaction terminal system can be operable to add this information to the transaction record and/or to verify information retrieved from the traveller records held in storage at the TRO host system 20.

In step 408, the transaction terminal system can be operable to add purchase details in respect of purchase information scanned or otherwise entered at the transaction terminal system and merchant details for the transaction terminal system to the transaction record.

In step 410, the transaction terminal system can optionally add a category of goods identifier to the transaction terminal. The category of goods can identify, for example a tax refund category.

In step 412, the transaction terminal system can be operable to issue a tax refund transaction. This can be in the form of sending a tax refund transaction record to the TRO host for associating a transaction record with the user records held at the TRO host system. In addition, or alternatively, a tax refund cheque or other confirmation can be output (e.g., printed) for the user.

Figure 5 illustrates another example of a process for step 306 for initiating and providing a tax refund offering.

The process starts at step 500, and in step 502, a message is displayed to a merchant to invite the user to proceed to a tax refund issuing desk to process a tax refund. The tax refund process performed at the tax refund issuing desk can be to generate a tax refund record, for example as described with reference to Figure 4.

In other examples, the tax refund offering can be in the form, for example, of offering the user whether to proceed with processing for a refund of tax. This could, for example be in the form of displaying the option to the user, and allowing the user to accept or not, for example by a touch screen panel or other user input, to proceed with a request for refund.

In the alternative process described at 320, various options are available. For example, a message could be displayed to the merchant to ask the user whether a tax refund is required and then entering a code or pressing a displayed or physical button to confirm acceptance or not of a request for refund. Following this manual selection process, a refund record could be generated, for example using a process as described with reference to Figure 4. Alternatively, the user could be invited to proceed to a refund processing desk within a store for preparation of a refund cheque or the like.

The merchant system 14 can comprise at least one computer, each comprising at least one processor and memory, located in a single place or in a distributed system.

As there can be multiple TROs in a market, there can be multiple acquiring system hosts 20. The relationship between a merchant and a TRO is that of merchant and acquirer (to use the credit/debit card example). Each TRO affiliates its own merchants and is responsible for the point of sale (POS) devices and integrated software that creates a tax refund

transaction.

Returning to Figure 2, a transaction message including the information for a transaction record can therefore be transmitted 105 to the TRO acquiring host system 20 where further processing can be performed. The transaction message format between the POS and the acquiring host can take any appropriate form as this can be proprietary. In one example the transaction message transmitted between the merchant system 14 and the acquiring host 20 contains the token identifier (e.g., a token number), a receipt identifier (e.g. a receipt number), references to the goods purchased, a merchant identifier, a TRO identifier, a time and date stamp, and a security hash (which is used to prevent tampering). It may in addition contain information about a tour guide, promotional codes, or any other data that the TRO wishes to collect.

A separate acquiring host system 20 can be provided for each TRO, so that

commercially sensitive information can be kept separate in that each TRO is only able to see transactions generated by its affiliated merchants. All tax refund transactions generated by affiliated merchants can be stored in the database of the acquiring host system 20. A transaction record as stored in memory of the acquiring host system can include, for example, a token identifier (e.g., a token number), a receipt identifier (e.g. a receipt number), at least one reference to the good or goods purchased, a merchant identifier and a time and date stamp. The acquiring host system 20 could also allocate a unique transaction identifier (e.g., a unique transaction number) to the transaction in order that a unique number is available within the system to track that transaction during processing.

A message interface 24 (also referred to herein as a message switch) provides a neutral place for all messages to be received and transmitted, and to provide for messages to be properly formatted and routed. For example transaction messages can include at least one of a transaction identifier (e.g. a transaction number), a token identifier (e.g., a payment card or other token number), a receipt identifier (e.g. a receipt number), references to the goods purchased, a merchant identifier, a TRO identifier, a time and date stamp, and a security hash (which is used to prevent tampering). The message switch 24 may be a separate system, or combined with a customs approval system 26 according to a particular implementation.

Transactions received by each of the acquiring host systems 20 can be forwarded through the message switch 24 to the customs approval system 26. The customs approval system can comprise at least one computer, each comprising at least one processor and memory.

A transaction message received by the TRO at the acquiring host system 20 can be formatted in accordance with a standard (e.g., IS08583 or its variants) and can be transmitted to a message switch 24. As shown in Figure 2, GBISO is an IS08583 message format with private fields being filled with TFS or DCC related information. The message switch can be operable to pass a transaction message to a customs approval system 26.

The customs approval system 26 provides an authorisation system for authorising refunds, and can be run by a customs authority, or on its behalf by a third party. The customs approval system 26 is capable of approving or rejecting tax refund transactions automatically based on rules set in the system by customs. The customs approval system 26 can also be accessed manually by a customs officer.

Self-service validation stations (kiosks) 22 at the territory exit points can be connected to the message switch 24. A validation station 22 can be configured to invite a user to present an identifier (e.g., the payment card, or other token) to be read. A validation station 22 can be provided with at least one input interface in the form, for example, of at least one of a keypad, a keyboard, a touch sensitive screen, a card reader, a scanner, a voice-activated input and at least one output interface in the form, for example, of at least one of a display, a printer, a card writer, a speaker. The validation station 22 could optionally be provided with a finger print reading and/or camera technology for verifying biometric information held on a machine readable user identifier (e.g., an ID document such as a passport).

The validation station 22 can be operable to prompt the user to present a payment card or token that is associated with payments for refund of tax. In the event that the user presents a token, then the validation station 22 can be operable to pass at least one validation request message through the message switch 24 to the customs approval system 26 requesting a list of all tax refund transactions from all TROs.

The customs approval system 26 can be operable to respond to a validation request message to retrieve all the transactions associated with the token from its own database and/or from the acquiring host systems 20, and can apply rules set to determine approval or rejection.

In one example, the customs approval system 26 could be set to either automatically approve the transactions based on rules that have been set, ("green channel") or automatically identify that an item needs to be inspected by a customs officer for approval ("red channel"), again based on rules set within the customs approval system 26.

When the customs approval system 26 has made a decision about a transaction

(approve/reject), an authorization message (validation request response message) is automatically routed through the message switch 24 back to the appropriate acquiring host system 20. The acquiring host system 20 updates an existing tax refund transaction record for the transaction with the authorization message (approve, present for approval, change).

A decision to pay a refund rests with the TRO as the TRO is responsible to the tax authority for the transaction. For that reason, the customs approval host does not act as the payment authorization host, but rather the TRO's acquiring host system 20 is the system of record.

Each acquiring host system 20 formats and transmits a refund message to the validation station indicating which transactions have been approved for "green channel" automatic payment. A TRO that issued the token is given first position on the Validation station, and that TRO's transactions are displayed.

If all the retrieved transactions have approved codes, the user is given "green channel" service and is asked how a refund is to be paid. If any of the transactions are not automatically approved, the user is given "red channel" service and is asked to present himself to a customs officer for further processing. If the choice of refund is via a payment card (e.g., a credit card), the refund can be made automatically to the registered payment card. If no payment card is registered, the validation station can prompt the user to swipe a card to which the refund should be made.

If the user requests a cash equivalent refund and the user has used a TRO issued token that can store a cash amount, then the refund amount can be credited to the token.

If the user requests a cash equivalent refund and the user has not used a TRO-issued token, a stored- value card can be issued from the validation station 22.

The process set out above can be repeated for each remaining TRO that has transactions associated with the token.

In the event that red channel processing is indicated, then the validation station prompts the user to present the token and the identifier to a customs officer, who can then use the token to begin processing. A customs officer can be provided with an approval station that is linked to or forms part of the customs approval system 26. However, in other examples, the approval stations can be separate from and/or remote from the customs approval system and can communicate therewith, for example via the message switch.

In response to input of the token identifier (e.g., where the token is a magnetic stripe card, by swiping the card), the approval station can be configured to use the token identifier to transmit an information retrieval message to the customs approval system 26, that can then retrieve a list of approved and rejected transactions associated with the token.

The customs officer can then approve or reject each transaction, or change the value amount. The customs officer can enter the result of his/her decisions using input device(s) of the approval station 28. The result of his/her decisions is communicated by the customs approval system 26 through the message switch 24 to the appropriate acquiring host system 20. The acquiring host system 20 now contains tax refund transactions with approval codes (approved, rejected, changed value).

The user can then return to the validation station 22, present his/her token once more and be prompted for the manner of the refund as discussed above.

The customs approval system 26 can be configured to operate in one or both of two modes of operation. In both modes of operation, information for transactions is stored on the respective acquiring host systems 20. In the first mode of operation, the customs approval system 26 is operable to retrieve transaction information from the respective acquiring host system 20 for validating refunds. The result of the authorisations is communicated back through the message switch 24 to the appropriate acquiring host system 20. The acquiring host system 20 now contains tax refund transactions with approval codes (approved, rejected, changed value). In the second mode of operation, the customs approval system 26 (CAS) retains a copy of each transaction within its own database, associated not only with the relevant token identifier, but also with an acquiring host system identifier. In this case, the customs approval system 26 also passes the transaction and approval code back to the acquiring host system 20 concerned. The difference between the two modes is that in the second mode, the CAS retains a copy of all data from all acquiring host systems 20.

Secure transmission, messages and protocols can be used for communicating information using existing software, equipment, and processes for handling secure financial transactions as known for electronic payments. A standards-based message format can thus be used for transmitting refund transactions. The use of standard message format can allow for multiple TRO providers, while ensuring that customs and inland revenue services only have to deal with a single system for approvals.

By recording transactions on the acquiring host system 20 and/or on a customs approval system 26 using the transaction identifier, value of purchase and payment card or other token identifier, and by further maintaining the user detail records linked to the token identifier in the acquiring host system 20, a customs approval system 26 can be operable to retrieve refund transactions from the acquiring host system 20 of a TRO based on the presentation of a token, to indicate a "yes/no" response to a request for permission to refund, and to transmit that result to the acquiring host system 20.

In the illustrated example communication between the acquiring host system(s) 20 and the customs approval system 26 can be effected by a message switch 24. The message switch 24 can provide a dedicated network between the customs approval system 26 and the acquiring host systems 20 for at least one TRO. Rather than a dedicated network, the communication can be made via secure switching channels operating over a public network such as the Internet.

In an example embodiment, automated validation stations (kiosks) 22 can be provided that allow automatic pre-screening of refund transactions to generate a "red channel/green channel" response without human intervention. The automatic pre-screening process could be effected using, for example a validation station 22 (e.g., a kiosk) at an exit point from the territory.

The validation station 22, or an approval system (e.g. the customs approval system 26) in communication with the validation station 22, could be provided with rules defining a "red channel" requirement, for example for high- value purchases and/or for purchases of a particular type. The "red channel" behaviour could be to require a user to present a token, shopping receipt, passport, and the goods purchased to a customs officer for approval.

The validation station 22, or the customs approval system 26 in communication with the validation station, could be provided with rules defining a "green channel" situation providing automatic approval for low value items and/or for purchases by travellers from particular countries, and so on.

Figure 6 is a schematic system diagram giving an overview of an example overall system configuration of an example embodiment.

Figure 6 illustrates various systems connected via a network 15, for example the

Internet.

Figure 6 illustrates a plurality of network-connectable computing devices 13 (e.g. a desktop, laptop, personal data assistant, mobile telephone, etc.) connected to the network 15. A user computer 13 can be used by a user (e.g., a traveller) to access a website to register a token. The website can be provided by one of a plurality of TROs, a tourist or travel organisation or authority, by way of example only. As will be described later, such a network- connectable computing device 13 can also be used for initiating or conducting a transaction.

Figure 6 illustrates a plurality of input stations 17 connected to the network 15. An input station 17 can be provided, for example, at a point of entry (e.g. an airport immigration area), a tourist office, a retailer etc. An input station 17 can be provided with at least one input interface in the form, for example, of at least one of a keypad, a keyboard, a touch sensitive screen, a passport or other ID document reader, a card reader, a scanner, a voice- activated input and at least one output interface in the form, for example, of at least one of a display, a printer, a card writer and/or dispenser, a speaker. In an example embodiment the input station 17 can be operable to issue a token, for example a card with a unique identifier.

Figure 6 illustrates a plurality of merchant systems 14 connected to the network 15. Each merchant system 14 can involve at least one computer system, each comprising at least one processor and memory, and at least one point of sale device, that can include at least one input interface in the form, for example, of at least one of a keypad, a keyboard, a touch sensitive screen, a card reader, a scanner, a voice-activated input and at least one output interface in the form, for example, of at least one of a display, a printer, a card writer, a speaker. Figure 6 illustrates a plurality of TRO acquiring host systems 20 connected to the network 15. Each acquiring host system 20 can involve at least one computer system, each comprising at least one processor and memory.

Figure 6 illustrates a message switch 24 (which corresponds to the message interface 24 of Figure 2) connected to the network 15. In this example the message switch 24 acts as a communications interface between the acquiring host systems 20, validation stations 22 and a customs approval system 26.

Figure 6 illustrates a plurality of validation stations 22 connected to the network 15. A validation station 22 can be located at a point of exit (e.g. an airport departure area). A validation station 22 can be provided with at least one input interface in the form, for example, of at least one of a keypad, a keyboard, a touch sensitive screen, a passport or other ID document reader, a card reader, a scanner, a voice- activated input and at least one output interface in the form, for example, of at least one of a display, a printer, a card writer and/or dispenser, a speaker. The validation station 22 could also be provided with at least one device for inputting user biometric information, such as a finger print scanner or a camera.

The familiarity of users with automated teller machines and the like means that validation stations 22 in the form of self-service kiosks at the exit points are acceptable to users.

As described above, in one example, the validation station 22 can be provided with a reader for automatically reading machine readable identifiers (e.g. machine readable identification documents such as machine readable passports) and can thereby enable automatic verification of the identity and eligibility of the user for a refund. The validation station 22 can prompt the user to present the token identifier. As also indicated above, the token can be in the form of a magnetic stripe card, a chip card, a bar code, a number that has to be entered at a key pad, etc.

The validation station 22 can then determine eligibility for a refund based on information held in a customs approval system 26 or a TRO acquiring host system 20 defining at least one purchase associated with the identifier, in order to determine whether to validate a refund associated with the at least one purchase. Optionally the validation station 22 could receive biometric information and cross check this against information held on the machine readable identifier to verify the identity of a user.

In one example the validation station 22 can respond to input of the token identifier to transmit a request to the server for information defining at least one purchase associated with the identifier, to compare information received from the server defining at least one purchase associated with the identifier to pre-defined rules to determine whether to validate a refund and to cause the output interface to indicate to the user whether the refund has been validated automatically (i.e. whether the validation is effected automatically). Where the refund is validated, the validation station 22 can transmit to the server confirmation that validation has been effected for the refund.

In another example, the validation station 22 can respond to input of the token identifier to transmit a request to the server to determine whether to validate a refund and to be responsive to a response from the server indicative of whether a refund for the at least one purchase has been validated to cause the output interface to indicate to the user whether the refund has been validated (i.e. whether the validation is effected automatically).

Alternatively, the user can be prompted to report to a manual validation check by a customs officer.

The validation station 22 can also be operative to prompt the user to identify how the refund should be made (for example to a credit card or with cash). If the user selects credit card, the transaction can automatically be refunded. If the user selects cash, then the user can be issued a fully active debit card with the refund amount, or be prompted to go to a refund counter at air side to receive the cash.

If a "red channel" response is the result, the user can be prompted to indicate how a refund is to be made if approved, and the user can then be directed to a Customs desk for further checking.

At the customs desk, a customs officer can use an approval station to retrieve the information from the server system using the token identifier.

An approval station can be provided with at least one input interface in the form, for example, of at least one of a keypad, a keyboard, a touch sensitive screen, a card reader, a scanner, a voice-activated input and with at least one output interface in the form, for example, of at least one of a display, a printer, a card writer, a speaker.

Using the token identifier, the customs officer can call up the transaction information from the server system, inspect the documents and goods, and decide whether to approve or reject the refund.

If the refund is approved, and the user had requested a credit card refund, the credit card transfer could then be effected automatically in response to the customs officer approving the refund using the approval station. Alternatively, a debit card could be generated by the approval station, or by the validation station 22.

Figure 7 illustrates an example of steps performed in response to a user leaving the territory and, at 710 presenting a token (e.g., a payment card) or machine readable ID (e.g., a passport) to a token (payment card) or ID reader at a validation station (a kiosk) at a point of exit from the territory.

In this example, at 712, the kiosk can be operable to identify the user based on stored information in response to reading of the token as described above with reference to Figure 3, or in response to reading of the ID.

At 714, if the user is not recognised as an eligible user, then the user will be provided with an appropriate message at the kiosk and the process ends at 716 - for example the user could be referred to a customs desk for manual processing.

Alternatively, if eligibility is detected, based on a machine readable ID, then at 718 the user can be invited to present a token associated with the user for retrieving transaction records for the user.

At 720, the kiosk can read the token (e.g., using a card reader if the token is a card) and can transmit a validation request to the customs approval system 26 including a token identifier.

At 722, the approval system can check the transactions (available in the approval system and/or from an acquiring host system as appropriate) using the token identifier to retrieve relevant transactions.

If, at 724 approval is not given automatically, then the further processing at 730 is described with reference to Figure 9.

Alternatively, if at 724 approval is given automatically, then the approval system can transmit at 726 an approval message to the respective acquiring host system for each approved transaction and further processing at 728 is described with reference to Figure 8.

Turning to Figure 8, for each acquiring host system that received an approval message from the approval system, the acquiring host system can transmit an appropriate approval message at 810 to the kiosk.

At 812, the kiosk can prompt the user to select a payment method.

At 814, the kiosk can action the payment, for example by inviting the user to enter a payment to which a refund is to be credited, or by dispensing a card having a refund amount thereon. Turning to Figure 9, where approval is not given automatically at 724, then the approval system can transmit at 910 a non-approval message to the respective acquiring host system for each unapproved transaction.

At 912, an acquiring host system receiving such a non-approval message transmits an appropriate non-approval message to the kiosk.

At 914, if the kiosk receives a non-approval message, it can prompt the traveller to report to customs for a manual validation check.

At 916, a customs officer can receive the token from the user or can invite the user to enter the token at a customs approval station.

At 918, the approval station transmits an information request to the approval system including a token identifier.

At 920, the approval system obtains transaction information (available in the approval system and/or from an acquiring host system as appropriate) using the token identifier to identify relevant transactions and returns the transaction information.

If, at 922, the customs officer disapproves a transaction then the process terminates at

924 with the user (traveller) being told that the transaction is not approved by the customs officer, and by a message being returned from the approval station to the approval system and the acquiring host concerned that approval for a refund in respect to a given transaction is not given.

Alternatively, if at 922 approval is given for a refund, then at 926 the approval station transmits an appropriate message via the approval system to the relevant acquiring host system that approval for given transactions is given.

At 928 the user can present the token to the kiosk and a refund message can be sent to the acquiring host for transactions associated with the token.

As indicated at 930, the further processing to effect the refund can proceed as indicated in Figure 8 in steps 810-814.

A refund system provides for detection of eligibility of a user for a refund and uses a token to identify purchases and to retrieve the information in respect of those purchases for processing a refund in respect of those purchases.

By providing an integrated system with information available from a server system, in combination with the use of a payment card and optionally also a token identifier, purchases can be associated with a traveller and eligibility can be determined at a point of exit following the purchase transactions. In the examples above, it is assumed that payment is made using a payment card using a transaction terminal system.

It should be noted that the term "payment card" as used herein is used in a generic manner to describe a token or device or carrier that can used to effect a transaction based on an account associated therewith. It should be noted that the "payment card" does not need to take form of a conventional rectangular plastic credit card or the like, possible with an integrated chip integrated therein, but the "payment card", within the meaning applied herein, may take any other form that can be operable as a credit, debit, or other form of payment token, device or carrier. For example, within the meaning of the term "payment card" as used herein, a payment system could be based on, or permit the use of mobile telephones, personal data assistants (PDAs), or other carriers of information as the "payment card". A mobile telephone configured as a payment card can include, for example, circuitry or software having

functionality equivalent to that of a chip in a chip-based payment card, or indeed other functionality in the form, for example of an electronic wallet. Accordingly, where reference is herein to a payment card, it is to be understood in the above examples that the "payment card" can take any suitable form to be operable as a payment token, device or carrier that is configured to conduct transactions based on an account associated therewith, for example means of appropriate software and/or a mechanism for transferring information to and from a payment terminal system (for example via contacts or in a contactless manner).

Example embodiments are also envisaged that operate without the use of a transaction terminal system.

In one example, a purchase may be conducted by a user using a network-connectable computing device 13 illustrated in Figure 6 (e.g., a mobile communications device such as a mobile telephone, a tablet, a wearable mobile computing device) by connecting (e.g.

wirelessly) to a payment channel. In an example embodiment, determining account information currency information identifying a currency associated with an account of a user comprises identifying an account currency code associated with at least one of a network- connectable computing device or an application (e.g. a shopping application, an electronic wallet or the like) of a network-connectable computing device 13. In an example embodiment, reference currency information is determined that identifies a reference currency associated with:

a location at which the network-connectable computing device is connected to a network for conducting the transaction; and/or a location of a terminal, which terminal is operable to receive the account currency information from the network-connectable computing device.

In an example embodiment, the determination of the account currency information and the reference currency information is made by a terminal via which the network-connectable computing device 13 connects to a network, or by at least one processor of at least one computer system in or connected directly or indirectly to the payment channel (e.g. at a TRO host system 20). The application (e.g. the shopping application, electronic wallet or the like) of the network-connectable computing device is configured so that, when the application is used to make the purchase, the appropriate terminal or computer system(s) are engaged to make the determination. For example, the application can be operable to send a message via the network to a TRO host system including details of the transaction, a payment channel to be used (e.g. identifying a payment account and an ACC of the payment account) and geolocation information relating to the current location of the network-connectable computing device or the terminal operable to receive the account currency information from the network- connec table computing device.

The connection of the network-connectable computing device 13 to a network 15 can be, for example, via at least one of a mobile telephony connection (e.g., a cellular connection), a WiFi connection, a Bluetooth connection, a near field communication (NFC) connection, Ethernet connection, or indeed any wireless or wired connection.

In the example embodiment, the at least one processor of the at least one computer system in, or connected directly or indirectly to, the payment channel (e.g. at a TRO host system) is programmed to determine account currency information identifying a currency associated with an account of a user for conducting a transaction for the user, for example from user records stored in storage associated with the at least one computing system, to compare the account currency information to reference currency information identifying the reference currency, and, where the account currency information identifies an account currency different from the reference currency identified by the reference currency

information, to initiate a tax refund offering for the user in respect of the transaction. As indicated above, the at least one processor of the at least one computing system can be operable to determine the reference currency based on the location at which the network- connectable computing device is connected to a network for conducting the transaction (e.g., using geolocation technologies) and/or the location of a terminal which is operable to receive the account currency information from the network-connectable computing device (e.g. using stored information relating to the location of the terminal). For example, the at least one processor can be operable to access stored information (for example held in storage of the at least one computer systems) that maps, or associates, such locations to reference currencies to determine a reference currency associated with a said location.

Rather than solely identifying currencies, it is envisaged that in an example implementation the account currency information may instead or in addition include or identify a location, country or region associated with that account currency and the reference currency information may instead or in addition include or identify a location, country or region in which the network-connectable computing device connects to a network. In such a case, where as a result of comparing the account currency information to the reference currency information the at least one processor determines that the location, country or region associated with the account currency is different from the location, country or region in which the network-connectable computing device connects to a network, the at least one processor is programmed to automatically initiate a tax refund offering for the user in respect of the transaction.

Although in the example embodiment the at least one processor of the at least one computer system is programmed to determine and compare currency information to determine whether to initiate a tax refund offering for the user in respect of the transaction, in another example, an application of the network-connectable computing device can be operable to make this determination. For example the application can be configured to use an ACC for a payment account associated with the application, and reference currency information, to determine whether an account currency represented by the ACC is the same as or different from a reference currency represented by the reference currency information, and based thereon to determine whether to initiate a tax refund offering for the user in respect of a transaction initiated using the network-connectable computing device. In order to determine reference currency information (e.g. a reference currency code) associated with current location of the network-connectable computing device, the application can be configured to use geolocation to determine the current location of the network-connectable computing device and to use information (for example held in storage of the network-connectable computing device or accessible by the network) that maps, or associates locations to such reference currency information.

In a further example, a purchase may be conducted using an e-commerce channel. In conducting the purchase, a user may access a website at a given location or in a given country or region using a browser of a network-connectable computing device 13 and conduct the purchase using an account (e.g. a conventional credit or debit account, a PayPal™ account or the like) with which a given account currency is associated. The website can be hosted, for example, by a server computer system comprising at least one processor. In such an example the at least one processor of the server computer system (or another system in communication therewith, e.g. a TRO host system 20) is programmed to use information derived from the use of that browser to identify the location, country or region in which the browser is being used and from this to identify reference currency information identifying a reference currency associated with that location, country or region based on stored information and information received from the use of that browser. The at least one processor of the server computer system (or another system in communication therewith, e.g. a TRO host system 20) can be programmed to compare account currency information identifying the account currency to reference currency information identifying the reference currency and, where the account currency information identifies an account currency different from the reference currency, to initiate a tax refund offering for the user in respect of the transaction.

As described above, rather than solely identifying currencies, it is envisaged that in an example implementation the account currency may instead or in addition include or identify a location, country or region associated with that account currency, and the reference currency information may instead or in addition include a location, country or region at which the browser is being used. In such a case, where as a result of comparing the account currency information to the reference currency information the at least one processor determines that the location, country or region in which the browser is being used, is different from the location, country or region associated with that account currency, the at least one processor is programmed to automatically initiate a tax refund offering for the user in respect of the transaction.

Initiating a tax refund offering for the user in respect of the transaction can comprise outputting to a merchant or the user an indication (e.g., a visual indication via a display device) that a user is entitled to a tax refund offering.

Initiating a tax refund offering for the user in respect of the transaction can comprise creating a transaction record for a tax refund offering including at least one of: an identifier of a token used to reference user records held in a remote system; information indicative of the identity of the user derived from a passport or other travel document; transaction information indicative of goods or services purchased; merchant details for a transaction terminal system or a website; a category of goods or services. Such a token can be 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 examples, a print of a record of the tax refund transaction can be caused to be generated.

Transaction records can be stored in storage associated with a host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

Example embodiments can be implemented by at least one program product comprising program instructions using at least one processor of, for example, a host system, a transaction terminal system, a network-connectable computing device or other computer system, for example in, or connected directly or indirectly to, a payment channel.

A computer program product may be in the form of a computer program on a carrier medium. The carrier medium could be a storage medium such as a solid state, magnetic, optical, magneto-optical or other storage medium. The carrier medium could be a transmission medium such as broadcast, telephonic, computer network, wired, wireless, electrical, electromagnetic optical or any other transmission medium.

Aspects of the subject matter described herein are set out in the following numbered clauses:

1. A computer- implemented method of conducting a transaction, the method comprising: determining account currency information associated with an account of a user for conducting a transaction for the user;

comparing the account currency information to reference currency information; and where the account currency information is different from the reference currency information, initiating a tax refund offering for the user in respect of the transaction.

2. The method of clause 1, wherein determining account currency information associated with an account of a user comprises identifying an account currency code associated with at least one of:

a network-connectable computing device;

an application of a network-connectable computing device. 3. The method of clause 2, wherein the network-connectable computing device is a mobile communications device.

4. The method of clause 3, wherein the mobile communications device is a mobile telephone.

5. The method of any one of clauses 2 to 4, wherein the reference currency information identifies a reference currency associated with a location at which the network-connectable computing device is connected to a network for conducting the transaction.

6. The method of any one of clauses 2 to 5, wherein the reference currency information identifies a reference currency associated with a location of a terminal, which terminal is operable to receive the account currency information from the network connectable computing device.

7. The method of clause 1, wherein determining account currency information associated with an account of a user comprises identifying an account currency code carried by a payment device read by a payment device reader of a terminal.

8. The method of clause 7, wherein the reference currency information identifies a reference currency associated with the terminal.

9. The method of clause 7 or clause 8, wherein the payment device is an EMV card, and the payment device reader is at least one of a contact or contactless chip card reader.

10. The method of any one of the preceding clauses, wherein initiating a tax refund offering for the user in respect of the transaction comprises:

outputting to a merchant an indication that a user is entitled to a tax refund offering.

11. The method of any one of the preceding clauses, wherein initiating a tax refund offering for the user in respect of the transaction comprises creating a transaction record for a tax refund offering including at least one of:

an identifier of a token used to reference user records held in a remote system;

information indicative of the identity of the user derived from a passport or other travel document;

transaction information indicative of goods or services purchased;

merchant details for the transaction terminal system;

a category of goods or services.

12. The method of clause 11, wherein the token is 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.

13. The method of clause 11 of clause 12, comprising causing printing of a record of the tax refund transaction.

14. The method of any one of the preceding clauses, comprising storing transaction records in storage associated with a host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

15. The method of clause 14, wherein the host system is operable to perform the method of any one of the preceding clauses.

16. The method of any one of clauses 1 to 13, performed by at least one of a computer system or a transaction terminal system.

17. The method of clause 14, wherein the method of any one of clauses 1 to 13 is performed by at least one of a computer system or a transaction terminal system connected to the host system via a network.

18. A computer program product comprising program instructions for causing at least one processor to perform the method of any one of any one of the preceding clauses.

19. The computer program product of clause 18, comprising a non-transient storage medium carrying the instructions.

20. A system comprising at least one processor, the system configured:

to determine account currency information associated with an account of a user for conducting a transaction for the user;

to compare the account currency information to reference currency information; and where the account currency information is different from the reference currency information, to initiate a tax refund offering for the user in respect of the transaction.

21. The system of clause 20, wherein determining account currency information associated with an account of a user comprises identifying an account currency code associated with at least one of:

a network-connectable computing device;

an application of a network-connectable computing device.

22. The system of clause 21, wherein the network-connectable computing device is a mobile communications device. 23. The system of clause 22, wherein the mobile communications device is a mobile telephone.

24. The system of any one of clauses 21 to 23, wherein the reference currency information identifies a reference currency associated with a location at which the network-connectable computing device is connected to a network for conducting the transaction.

25. The system of any one of clauses 21 to 24, wherein the reference currency information identifies a reference currency associated with a location of a terminal, which terminal is operable to receive the account currency information from the network connectable computing device.

26. The system of clause 20, wherein determining account currency information associated with an account of a user comprises identifying an account currency code carried by a payment device read by a payment device reader of a terminal.

27. The system of clause 26, wherein the reference currency information identifies a reference currency associated with the terminal.

28. The system of clause 26 or clause 27, wherein the payment device is an EMV card, and the payment device reader is at least one of a contact or contactless chip card reader.

29. The system of any one of clauses 20 to 28, wherein initiating a tax refund offering for the user in respect of the transaction comprises:

outputting to a merchant an indication that a user is entitled to a tax refund offering. 30. The system of any one of clause 20 to 29, wherein initiating a tax refund offering for the user in respect of the transaction comprises creating a transaction record for a tax refund offering including at least one of:

transaction information indicative of goods or services purchased;

merchant details for the transaction terminal system;

a category of goods or services.

31. The system of clause 30, wherein the token is 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. 32. The system of clause 29 or clause 30, comprising a printer for printing a record of the tax refund transaction.

33. The system of any one of clauses 20 to 32, comprising a host system for storing transaction records in storage associated with the host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

34. The system of clause 33, wherein the host system comprises the at least one processor. 35. The system of any one of clauses 20 to 32, wherein a computer system or a transaction terminal system comprises the at least one processor.

36. The system of any one of clauses 20 to 32, wherein at least one of a computer system or a transaction terminal system comprises the at least one processor, said at least one of the computer system or the transaction terminal system being connected to a host system via a network, the host system being operable to store transaction records in storage associated with the host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

37. A transaction terminal system, comprising a card reader for reading a payment card of a user, the transaction terminal system comprising a magnetic stripe reader and being operable to determine whether a magnetic stripe on the card includes a Service Code Digit 1 that is indicative that the card is an EMV card, and in the event that the Service Code Digit 1 is not indicative that the card is an EMV card, to initiate a tax refund offering for the user.

38. The transaction terminal system of clause 37, wherein, in the event that the Service Code Digit 1 is indicative that the card is an EMV card, to prompt the user to present the payment card for reading of the EMV chip on the card.

39. The transaction terminal system of clause 38, comprising a card reader that is at least one of a contact or contactless chip card reader.

40. The transaction terminal system of clause 37 or clause 38, wherein, in response to the user presenting the payment card for reading of the EMV chip on the card, the transaction terminal system is operable to determine whether an account currency code carried by a payment card read by at least one of a contact or contactless chip card reader is different from a currency code for the transaction terminal system, and

where an account currency code carried by a payment card read by the card reader is determined to be different from the currency code for the transaction terminal system, to initiate a tax refund offering for the user.

41. The transaction terminal system of any one of clauses 37 to 40, wherein initiating a tax refund offering for the user comprises:

42. The transaction terminal system of any one of clauses 37 to 41, wherein initiating a tax refund offering for the user comprises the transaction terminal system creating a transaction record for a tax refund offering including at least one of:

an identifier of a token used to reference user records held in a remote system; information indicative of the identity of the user derived from a passport or other travel document;

transaction information indicative of goods or services purchased; merchant details for the transaction terminal system;

a category of goods or services.

43. The transaction terminal system of clause 42, wherein the token is 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.

44. The transaction terminal system of clause 42 or clause 43, comprising the transaction terminal system being operable to transmit a transaction message including the transaction record via a network to a remote system.

45. The transaction terminal system of any one of clauses 42 to 44, wherein the transaction terminal system comprises a printer and is operable to print a record of the tax refund transaction.

46. A system comprising the transaction terminal system of any one of clauses 37 to 45 and remote host system, wherein the remote host system is associated with storage for storing transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the remote host system being operable to be responsive to a transaction message including the transaction record received via a network from the transaction terminal system to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

47. A computer implemented method comprising:

determining whether a magnetic stripe on a payment card of a user read by a magnetic stripe reader of a transaction terminal system includes a Service Code Digit 1 that is indicative that the card is an EMV card; and

in the event that the Service Code Digit 1 is not indicative that the card is an EMV card, initiating a tax refund offering for the user.

48. The method of clause 47, wherein, in the event that the Service Code Digit 1 is indicative that the card is an EMV card, to prompt the user to present the payment card for reading of the EMV chip on the card.

49. The method of clause 48, comprising prompting the user to present the payment card to at least one of a contact or contactless chip card reader for reading of the EMV chip on the card.

50. The method of clause 47 or clause 48, wherein, in response to the user presenting the payment card for reading of the EMV chip on the card:

determining whether an account currency code carried by a payment card read by a card reader of a transaction terminal system is different from a currency code for the transaction terminal system, the card reader being at least one of a contact or contactless card reader; and

where an account currency code carried by a payment card read by the card reader is determined to be different from the currency code for the transaction terminal system, initiating a tax refund offering for the user.

51. The method of any one of clauses 47 to 50, wherein initiating a tax refund offering for the user comprises:

52. The method of any one of clauses 47 to 51, wherein initiating a tax refund offering for the user comprises creating a transaction record for a tax refund offering including at least one of:

a category of goods or services.

53. The method of clause 52, wherein the token is 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.

54. The method of clause 52 or clause 53, comprising transmitting a transaction message including the transaction record from the transaction terminal system via a network to a remote system.

55. The method of any one of clauses 47 to 54, comprising printing a record of the tax refund transaction using a printer associated with the transaction terminal system.

56. The method of any one of clauses 47 to 55, comprising storing transaction records in storage associated with a host system, system comprising the transaction terminal system of any one of the preceding clauses and remote host system, wherein the remote host system is associated with storage for storing transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the remote host system being operable to be responsive to a transaction message including the transaction record received via a network from the transaction terminal system to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

56. A computer program product comprising program instructions for causing at least one processor to perform the method of any one of clauses 47 to 56.

57. The computer program product of clause 56, comprising a non-transient storage medium carrying the instructions.

Although the embodiments described above have been described in detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications and their equivalents.

Claims

comparing the account currency information to reference currency information; and where the account currency information is different from the reference currency information, automatically initiating a tax refund offering for the user in respect of the transaction.

2. The method of claim 1, wherein determining account currency information associated with an account of a user comprises identifying an account currency code associated with at least one of:

a network-connectable computing device;

an application of a network-connectable computing device.

3. The method of claim 2, wherein the network-connectable computing device is a mobile communications device.

4. The method of claim 3, wherein the mobile communications device is a mobile telephone.

5. The method of any one of claims 2 to 4, wherein the reference currency information identifies a reference currency associated with a location at which the network-connectable computing device is connected to a network for conducting the transaction.

6. The method of any one of claims 2 to 5, wherein the reference currency information identifies a reference currency associated with a location of a terminal that is operable to receive the account currency information from the network connectable computing device.

7. The method of claim 1, wherein determining account currency information associated with an account of the user comprises identifying an account currency code carried by a payment device read by a payment device reader of a terminal.

8. The method of claim 7, wherein the reference currency information identifies a reference currency associated with the terminal.

9. The method of claim 7 or claim 8, wherein the payment device is an EMV card, and the payment device reader is at least one of a contact or contactless chip card reader.

10. The method of any one of the preceding claims, wherein initiating a tax refund offering for the user in respect of the transaction comprises:

outputting to a merchant an indication that the user is entitled to a tax refund offering.

11. The method of any one of the preceding claims, wherein initiating a tax refund offering for the user in respect of the transaction comprises creating a transaction record for a tax refund offering including at least one of:

transaction information indicative of goods or services purchased;

merchant details for the transaction terminal system;

a category of goods or services.

12. The method of claim 11, wherein the token is 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.

13. The method of claim 11 of claim 12, comprising causing printing of a record of the tax refund transaction.

14. The method of any one of the preceding claims, comprising storing transaction records in storage associated with a host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

15. The method of claim 14, wherein the host system is operable to perform the method of any one of the preceding claims.

16. The method of any one of claims 1 to 13, performed by at least one of a computer system or a transaction terminal system.

17. The method of claim 14, wherein the method of any one of claims 1 to 13 is performed by at least one of a computer system or a transaction terminal system connected to the host system via a network.

18. A computer program product comprising program instructions for causing at least one processor to perform the method of any one of any one of the preceding claims.

19. The computer program product of claim 18, comprising a non-transient storage medium carrying the instructions.

20. A system comprising at least one processor, the system configured:

21. The system of claim 20, wherein determining account currency information associated with an account of a user comprises identifying an account currency code associated with at least one of:

a network-connectable computing device;

an application of a network-connectable computing device.

22. The system of claim 21, wherein the network-connectable computing device is a mobile communications device.

23. The system of claim 22, wherein the mobile communications device is a mobile telephone.

24. The system of any one of claims 21 to 23, wherein the reference currency information identifies a reference currency associated with a location at which the network-connectable computing device is connected to a network for conducting the transaction.

25. The system of any one of claims 21 to 24, wherein the reference currency information identifies a reference currency associated with a location of a terminal that is operable to receive the account currency information from the network connectable computing device.

26. The system of claim 20, wherein determining account currency information associated with an account of the user comprises identifying an account currency code carried by a payment device read by a payment device reader of a terminal.

27. The system of claim 26, wherein the reference currency information identifies a reference currency associated with the terminal.

28. The system of claim 26 or claim 27, wherein the payment device is an EMV card, and the payment device reader is at least one of a contact or contactless chip card reader.

29. The system of any one of claims 20 to 28, wherein initiating a tax refund offering for the user in respect of the transaction comprises:

30. The system of any one of claim 20 to 29, wherein initiating a tax refund offering for the user in respect of the transaction comprises creating a transaction record for a tax refund offering including at least one of:

transaction information indicative of goods or services purchased;

merchant details for the transaction terminal system; a category of goods or services.

31. The system of claim 30, wherein the token is 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.

32. The system of claim 29 or claim 30, comprising a printer for printing a record of the tax refund transaction.

33. The system of any one of claims 20 to 32, comprising a host system for storing transaction records in storage associated with the host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.

34. The system of claim 33, wherein the host system comprises the at least one processor.

35. The system of any one of claims 20 to 32, wherein a computer system or a transaction terminal system comprises the at least one processor.

36. The system of any one of claims 20 to 32, wherein at least one of a computer system or a transaction terminal system comprises the at least one processor, said at least one of the computer system or the transaction terminal system being connected to a host system via a network, the host system being operable to store transaction records in storage associated with the host system, the transaction records identifying at least one purchase in association with a token identifier and a merchant identifier, the host system being operable to store the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier.