GB2566824A

GB2566824A - Refund system and method

Info

Publication number: GB2566824A
Application number: GB1814184.6A
Authority: GB
Inventors: Michael Ling James; Menzinsky Richard
Original assignee: Global Blue SA
Current assignee: Global Blue SA
Priority date: 2018-08-31
Filing date: 2018-08-31
Publication date: 2019-03-27
Also published as: GB201814184D0

Abstract

An apparatus for validating tax refunds comprises a validation station 22 configured to receive a token and comprising a reader for a machine readable user identifier. The validation station is configured to transmit a validation request message that identifies the token to an approval system 28 that holds or has access to transaction information identifying one or more purchases associated with the token to validate a tax refund for the one or more purchases for an eligible user. Eligibility is derived from information from the machine readable identifier. The validation station is configured to receive a response message from the approval system and indicate to the user whether a refund associated with the one or more purchases has been validated. The refund is paid to a cryptocurrency wallet associated with the user. A customs approval station 16 and system 28, a tax refund operator host system 20 and a merchant system 14 are also disclosed. Preferably the token is a cryptocurrency wallet address, a passport number, or other user identifier. The validation station may be a self-service kiosk 22 at a territory exit point.

Description

REFUND SYSTEM AND METHOD

BACKGROUND

The present invention relates to apparatus, systems and methods for obtaining 5 tax refunds in associated with purchases where the refund is in a cryptocurrency.

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 customer is a visiting traveller entitled to a tax refund, and then to issue the voucher that includes details of the traveller and the purchased item and then for custom to verify at the point of exit from the country that an item being exported and the traveller correspond 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.

However, existing systems only allow refunds to be made in fiat currencies, such as US dollars, British pounds or Euro. The emergence of cryptocurrencies and other non-fiat currencies has led to a need to provide a means of providing the customer a choice as to how their refund is effected.

The present invention seeks to provide a technological solution to such problems.

SUMMARY

Aspects of the invention are defined in the claims.

An embodiment can provide an apparatus comprising a validation station. The validation station comprises an input interface configured to receive a token and includes a reader operable to read a machine readable user identifier that identifies the user. The validation station comprises processing logic configured to transmit a validation request message that identifies the token to an approval system that holds or has access to transaction information identifying one or more purchases associated with the token in order to validate a tax refund for the one or more purchases, wherein eligibility of the user is derived from the machine readable identifier. The validation station processing logic receives a response message from the approval system. The validation station also comprises an output interface configured to indicate to the user whether a refund associated with the one or more purchases has been validated, where the refund is to a cryptocurrency wallet associated with the user.

An embodiment can provide an apparatus comprising an approval station. The approval station comprises input means configured to receive a token and includes a reader operable to read a machine readable user identifier that identifies the user. The approval station comprises processing logic configured to obtain information from an approval system that holds or has access to transaction information identifying one or more purchases associated with the token to validate a tax refund for the one or more purchases, the tax refund to a cryptocurrency wallet associated with the user. The approval station also comprises an output interface configured to present to an official details of the one or more purchases and/or of the user associated with the identifier.

An embodiment can provide an apparatus comprising an approval system. The approval system has access to storage for transaction information identifying one or more purchases associated with a token and/or rules defining eligibility for a tax refund. The approval system responds to a validation request message that is received from a validation station and that identifies the token for a user to determine whether to validate a refund associated with the one or more purchases based on the token for the user and to transmit a validation response message, where the refund is to a cryptocurrency wallet associated with the user.

An embodiment can provide an operator host system. The operator host system includes storage for storing transaction information identifying one or more purchases in association with a token and a merchant identifier. The operator host system also includes processing logic configured responsive to transaction information that identifies one or more purchases associated with a token from a merchant system to store the transaction information identifying one or more purchases in association with the token and the merchant identifier. The operator host system processing means is further configured to be operable to transmit the transaction information identifying with one or more purchases associated with the token to an approval system.

An embodiment can provide a merchant system. The merchant system includes an input interface configured to receive a token identifying a user and/or details of one or more purchases. The merchant system comprises processing logic configured to transmit a transaction message to an operator host system, the transaction message defining one or more purchases associated with a token and a merchant identifier.

An embodiment can provide a computer implemented method of processing a refund comprising: in response to a user making one or more purchases, recording transaction information representative of the one or more purchases associated with a token; and in order to validate a refund, a validation station receiving input of a machine readable user identifier and the token; and an approval system that holds or has access to the recorded transaction information determining whether to validate a tax refund based on the eligibility of the user identified by the machine readable identifier for a tax refund for the transaction information; the validation station indicating to the user whether a refund associated with the one or more purchases has been validated and in response to positive validation, effecting a refund to a cryptocurrency wallet associated with the user.

An embodiment can provide a program product comprising program instructions for carrying out such a method.

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 lisa schematic block diagram illustrating an example of a simple 5 refund approach;

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

Figure 3 is a schematic system overview;

Figures 4-7 form a flow diagram of an example method of operation.

Figure 8 is a flow diagram of a method of effecting a refund payment in a cryptocurrency.

DETAILED DESCRIPTION

In some embodiments the term “fiat currency” is understood to mean a currency which a government or legal authority has declared to be legal tender. Examples of a fiat currency include the US dollar (USD), the British pound (GBP), the Japanese Yen (JPY) and the Euro (EUR)

In some embodiments the term “cryptocurrency” is understood to mean a digital asset or currency in which encryption techniques are used to regulate the generation of units of currency and verify the transfer of funds, operating independently of a central bank. Examples of a cryptocurrency include Bitcoin (BTC), Ethereum (ETH), Ripple (XRP), Litecoin (LTC) and Bitcoin cash (BCH). A transaction or payment may be made in a cryptocurrency as an alternative to a fiat currency. A given cryptocurrency, such as Bitcoin (BTC), has an exchange rate with a fiat currency, for example BTC1 = USD8695.

In some embodiments the term “cryptocurrency wallet” is understood to mean a data store for public and private keys which can be used to receive or spend a cryptocurrency.

An apparatus comprises a validation station having a validation station input interface configured to receive a token, the input interface comprising a reader operable to read a machine readable user identifier that identifies the user. The validation station includes validation station processing logic configured to transmit a validation request message that identifies the token to an approval system that holds or has access to transaction information identifying one or more purchases associated with the token to validate a tax refund for the one or more purchases for an eligible user, eligibility being derived from information from the machine readable identifier, the validation station processing logic further being configured to receive a response message from the approval system. The validation station also includes a validation station output interface configured to indicate to the user whether a refund associated with the one or more purchases has been validated, wherein the refund is to a cryptocurrency wallet associated with the user. This provides an easy to use system for the user to collate and process refund applications.

In some examples the validation station processing logic is operable to determine the eligibility of the user to receive a refund by comparing information from the machine readable identifier to information stored in the validation station. This allows the identity and eligibility of the user to be determined without requiring the validation station to store data relating to the user.

In some examples the validation station processing logic is operable to obtain a token identifier in response to determining eligibility of the user to receive a refund from comparing information from the machine readable identifier to information stored in the validation station. This allows further information relating to the user to be determined from the token.

In some examples the validation station processing logic is responsive to a first response message to indicate to the user that a refund associated with the one or more purchases has been validated automatically, and the validation station processing logic is responsive to a second response message to refer to the user to a manual validation check. This provides a means of informing the user as to the outcome of the validation for each transaction.

In some examples the validation station input interface further comprises one or more of a keypad, a keyboard, a touch sensitive screen, a card reader, a reader for a machine readable identifier, a scanner, a voice-activated input, a camera, biometric information capture apparatus. The validation station output interface comprises one or more of a display, a printer, a card writer, a speaker. This provides a validation station which the user can easily interact with.

An apparatus comprises an approval station having approval station input interface configured to receive a token, the input interface comprising a reader operable to read a machine readable user identifier that identifies the user. The approval station also includes approval station processing logic configured to obtain information from an approval system that holds or has access to transaction information identifying one or more purchases associated with the token. The approval station also includes an output interface configured to present to an official details of the one or more purchases and/or of the user associated with the identifier. This provides a means of retrieving information about a transaction to the output to an official in order for the official to be able to make an informed decision as to whether a refund should be provided.

In some examples the approval station is responsive to the official validating a refund associated with the one or more purchases to transmit a confirmation message to at least one of the approval system or a host system that validation has been effected for the refund to be effected, wherein the refund is to a cryptocurrency wallet associated with the user. This allows a refund to a cryptocurrency wallet to be performed in response to approval by the approval system.

An apparatus comprises an approval system, the approval system having access to storage for transaction information identifying one or more purchases associated with a token. The approval system also includes approval system storage for rules defining eligibility for a tax refund. The approval system also includes approval system processing logic operable in response to a validation request message that is received from a validation station and that identifies the token and a user to determine whether to validate a refund associated with the one or more purchases based on the token for the user and to transmit a validation response message, wherein the refund is to a cryptocurrency wallet associated with the user. This provides a means of retrieving information about a transaction in order to determine whether a refund to a cryptocurrency wallet associated with the user should be performed.

In some examples the approval system processing logic is operable to transmit the validation response message to an operator host system that maintains a cryptocurrency wallet associated with the user relationship between the token and the user should be made. This allows the outcome of the approval process to be relied to other systems in a network.

In some examples the approval system processing logic is operable to transmit a first validation response message where a refund associated with the one or more purchases has been validated automatically, and to transmit a second response validation message where a refund has not been authorised automatically and the user is to be referred to a manual validation check. This provides a means of informing the user as to the outcome of the validation for each transaction.

In some examples the approval system processing logic is further operable, in response to an information request from an approval station that identifies the token, to provide to the approval station transaction information identifying one or more purchases associated with the token. This ensures that the approval station is able to obtain all the information necessary to determine whether approval for a refund should be granted.

In some examples the transaction information identifying one or more purchases associated with a token is stored in the approval system storage. This provides a means of quickly referencing the transaction history for a given token or user.

In some examples the transaction information identifying the one or more purchases is stored in an operator host system. This reduces the storage requirement at the approval system.

An apparatus comprises an operator host system having storage for storing transaction information identifying one or more purchases in association with a token and a merchant identifier. In some examples processing logic responsive to transaction information that identifies one or more purchases associated with a token from a merchant system to store the transaction information identifying one or more purchases in association with the token and the merchant identifier, the processing logic being further operable to transmit the transaction information identifying with one or more purchases associated with the token to an approval system. This provides a means of linking transactions at a merchant to the approval system, which may be in a different location.

An apparatus comprises a merchant system having merchant system input interface configured to receive a token identifying a user and/or details of one or more purchases. The merchant system also includes merchant system processing logic operable to transmit a transaction message to an operator host system, the transaction message defining one or more purchases associated with a token and a merchant identifier. This provides a means of generating and transmitting transaction information from a merchant for use by another system to validate or approve a refund request relating to the transition.

In some examples the apparatus operates real-time messaging. This provides a quick means of validating and approving refund requests.

In some examples the machine readable identifier is one or a QR code or bar code representing an address for a cryptocurrency wallet. This allows a user to link each purchase to a cryptocurrency wallet

In some examples the token is a cryptocurrency wallet. This provides a means of linking each purchase to a cryptocurrency wallet

In some examples the information identifying one or more purchases associated with the token comprises a transaction identifier. This provides a simple means of tracking transactions associated with a token or user.

A refund system comprises the one or more of the apparatuses in the above examples interconnected by a network. This provides an integrated system for performing refunds.

A computer implemented method of processing a refund comprises, in response to a user making one or more purchases, recording transaction information representative of the one or more purchases associated with a token. In order to validate a refund, a validation station receives input of a machine readable user identifier and the token. An approval system that holds or has access to the recorded transaction information determines whether to validate a tax refund for the one or more purchases for an eligible user, eligibility being determined from information from the machine readable identifier. The validation station indicates to the user whether a refund associated with the one or more purchases has been validated and in response to positive validation, effecting a refund to a cryptocurrency wallet associated with the user. This provides a method of effecting a refund to a cryptocurrency wallet associated with the user for a transaction made in a local currency of a merchant.

In some examples the validation station determines eligibility by comparing information read from the machine readable user identifier to information stored in or accessible to the validation station. This allows the system to apply a criteria to each user which must be met in order for them to receive a refund.

In some examples the validation station, in response to receipt of the token and the machine readable user identifier, transmits a validation request message that identifies the token and the user to the approval system. This provides the approval system with information relating to the user, allowing the approval system to determine the eligibility of the user to a refund for each transaction associated with the user.

In some examples a first response message from the approval system represents that a refund associated with the one or more purchases has been validated automatically, and a second response message indicates that the user is referred to a manual validation check. This provides a means of informing the user as to the outcome of the validation.

In some examples, for a manual validation check, an approval station is responsive to input of the token and the machine readable user identifier to transmit an information request message to the approval system to retrieve information to determine eligibility for a tax refund for the one or more purchases and is operable to display the retrieved information to an official. This provides an additional means of checking the eligibility of the user for a refund prior to approving the refund.

In some examples the approval station is responsive to the official validating a refund associated with the one or more purchases to transmit a confirmation message to at least one of the approval system or a host system that validation has been effected for the refund to be effected. This provides a means of informing the other parts of the system that a refund has been approved and should be effected.

In some examples the approval system determines, on the basis of pre-defined rules, whether to validate a refund associated with the one or more purchases based on the token and the identity of the user. This provides a means of automatically validating a refund based on attributes of the user and their token.

In some examples the approval system stores the transaction information. This provides an easily accessible record of the transactions for which a refund has been requested.

In some examples the approval system accesses the transaction information from an operator host system. This reduces the storage requirements at the approval system.

In some examples an operator host system stores transaction information identifying one or more purchases in association with a token and merchant identifiers. This provides an easily accessible record of the transactions for which a refund has been requested.

In some examples the transaction information identifies one or more purchase transactions and the token is input at a merchant system, the merchant system transmitting a transaction message to an operator host system. This provides a central depository for transaction information in the system.

In some examples the method employs real-time messaging. This provides a quick means of validating and approving refund requests.

In some examples the machine readable identifier is one or a QR code or bar code representing an address for the cryptocurrency wallet. This allows a user to link each purchase to a cryptocurrency wallet.

In some examples the token is the cryptocurrency wallet. This provides a means of linking each purchase to a cryptocurrency wallet.

Figure 1 illustrates a simple approach to obtaining a refund of tax associated with a purchase. The approach illustrated in Figure 1 includes a traveller receiving a conventional store receipt from a merchant on making a purchase. The store receipt together with the goods is the 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 traveller. The payment to the traveller may be in any suitable form, for example by crediting the amount of the tax refund onto a payment card, by giving cash to the traveller or by a transfer of funds into an account of the traveller. For example, the traveller may wish the payment to be made directly into a bank account or a cryptocurrency wallet owned by the traveller. The traveller provides, respectively, the bank account details or the address for the cryptocurrency wallet to the authority in order for the payment to be processed and completed.

Although this approach is simple, it is fraught with potential fraud. Experience around the world has shown that the trade-off between simplicity and integrity is too high.

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. As any receipt can be presented for refund, there is a temptation for collusion between merchants and travellers. Also, once outside a shop, there is the potential for “receipt buying” in which domestic customers sell their receipts to travellers. The traveller, potentially with only a small chance of being asked to present the goods for inspection, makes a claim on all the receipts the traveller is able to gather. Accordingly, the risk of fraud for refunding on receipts where the goods is never exported or intended for export is wide open. Also, a bone-fide 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 of the invention maintains simplicity of operation but addresses both the integrity and usability shortcomings of prior approaches. In the example embodiment one or more systems coordinate processing of purchases and refunds using one or more tokens that uniquely identify a user, for example a traveller. The one or more systems 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 the a territory. In an example embodiment, the determination of eligibility and identity is moved away from a point of sale to the point of exit from the territory. 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, the user (e.g., a traveller) uses a token when making a purchase and the eligibility is determined at a point exit from the territory. By moving the determination of eligibility away from the point of sale, the dependence on people who are less well trained can be reduced, and eligibility can then be performed by properly equipped machines and resources.

Examples of possible tokens include 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, a mobile phone, etc. In some examples, the token can include a cryptocurrency wallet address. As indicated, the token could be a visitor card or other visitor token that could be issued to the user, for example on entry to the territory, with or without checking of identity at this stage. The visitor token could, for example, be a chip card or a card with a magnetic stripe that would have a unique number.

By presenting the token when making a purchase, a record of the purchase can be made associated with the token. A computer record can be made of an association between the token and a transaction identifier (e.g. a sales receipt) for a purchase transaction for one or more purchases. The 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 token is allocated to a user. This can be done before or at a point of entry to the territory or at a point of sale. In one example the user can choose the token to be used. For example 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 (e.g., a token of one of the types referenced above, such as a cryptocurrency wallet). For example, a user can register his/her details and associate his/her details with a 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 as mentioned above). 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. For example, an address of the user’s cryptocurrency wallet can be recorded as one of the user details, such that the user’s cryptocurrency wallet is linked to the issued token. A suitable input station can include, for example, a computer processor including processing logic, computer memory, one or more input interfaces in the form of one or more 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 one or more output interfaces in the form of one or more 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).

A token identifier (for example a number unique to the token 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). For example, where the token is a cryptocurrency wallet, the token identifier may be the address for the cryptocurrency wallet. The host server system 20 can comprise one or more server computers, each comprising one or more processors, including processing logic, 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. When presented with the normal shop receipt, the user 12 can be asked if a tax refund is required (or the user can ask for a tax refund). If a refund is desired, a second, simple transaction can be created by entering a receipt identifier (e.g. a receipt number), the value of the goods purchased, and the token identifier. Thus, in this example embodiment, information including three items (receipt identifier, value of purchase, token identifier) can then be electronically transmitted by a merchant system 14 to the acquiring server system 20. The merchant system 14 can comprise one or more computers, each comprising one or more processors, including processing logic, 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. The transaction message 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), references to the 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 switch 24 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 one or more of a transaction identifier (e.g. a transaction number), a 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). The message switch 24 may be a separate system, or combined with a custom 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 one or more computers, each comprising one or more processors, including processing logic, and memory.

A transaction message received by the TRO at the acquiring host system 20 can be formatted in accordance with a standard proposed (e.g., GR-ISO) and can be transmitted to a message switch 24. 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., an identity document such as a passport) to be read. A validation station 22 can be provided with one or more input interfaces in the form, for example, of one or more of a keypad, a keyboard, a touch sensitive screen, a card reader, a scanner, a voice-activated input and one or more output interfaces in the form, for example, of one or more of a display, a printer, a card writer, a speaker. The validation station 22 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).

In one example the validation station 22 can be configured to determine the eligibility of a user for a tax refund by machine reading the identifier. In this example the validation station 22 reads the information from the identifier and determines eligibility by checking the information against an internal database that contains information about domestic/non-eligible travellers. In this case, the user can be deemed eligible if his/her nationality or status is not on the list (negative approval). Alternatively, or in addition, the validation station 22 can be operable to determine eligibility by checking the information against an internal database that contains information about non-domestic/eligible travellers. In this case, the user can be deemed eligible if his/her nationality or status is on the list (positive approval).

As mentioned above, the validation station 22 could also be provided with a fingerprint scanner and/or a camera and can be used to verify the identity of a user using biometric information held on the machine readable identifier (e.g., the identity documents such as a passport). A discussion about such biometric information is to be found, for example, at the following Internet link:

http://w^rww.highprogrammer.eom/alan/numbers/mrp.html.

Where eligibility of a user is determined at a validation station 22, then the validation station 22 can be operable to prompt the user to present a token. In the event that the user presents a token, then the validation station 22 can be operable to pass a one or more validation request messages through the message switch 24 to the customs approval system 26 custom approval system 26 requesting a list of all tax refund transactions from all TROs.

In another example, the validation station 22 can be configured to prompt a user to enter the user identifier and the token and then to pass a validation request message to a custom approval system to request approval based on both the eligibility of the user and the transactions recorded in association with the transactions. In this other example, the validation station 22 can transmit a validation request message that includes the information from the identifier and the token identifier, and the customs approval system can determine eligibility and whether to validate the transactions.

The customs approval system 26 can be operable to respond to a validation request message to retrieves 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 to reject a transaction (“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, reject, 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 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 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 TROissued token, a stored-value card can be issued from the validation station 22.

If the choice of refund is cryptocurrency, the refund can automatically be made to the registered cryptocurrency wallet. If no cryptocurrency wallet is registered, the validation station can prompt the user to provide an address for the cryptocurrency wallet the refund is to be made to. For example, the user may be prompted to provide a QR code, barcode or other machine readable identifier representing the address for the cryptocurrency wallet to a scanner associated with the validation station. The user may then launch an application on their mobile telephone or other portable electronic device in order to provide the machine readable identifier. Alternatively, the user may have the machine readable identifier printed onto a card or paper which they can present to the scanner. In another example, the validation station can prompt the user to manually enter the address of the cryptocurrency wallet, for example using a keyboard or touch screen display associated with the validation station. Where the token is a cryptocurrency wallet, and/or the token identifier is the address for the cryptocurrency wallet, the validation station may be configured to automatically make the refund to the cryptocurrency wallet associated with the token without asking the user to confirm how the refund is to be paid. Alternatively, the validation station may be configured to prompt the user to confirm that the refund is to be made to the cryptocurrency wallet associated with the token. If the user wishes the refund to be paid in a different way, the user can response negatively to this confirmation and the validation station is configured to ask the user how a refund is to be paid as described above.

The process set out above is 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 presents the token and the identifier to a customs officer, who can then use the token to begin processing. A customs official 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 form 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 or where the token is a cryptocurrency wallet by scanning a machine readable identifier representing the address for the cryptocurrency wallet), 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 authorisation system 26 can be configured to operate in one or both of two modes of operation. In one mode 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 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 caser 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 token identifier, and by further maintaining the user detail records linked to the token identifier in the acquiring host system, 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 one or more TROs. 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 prescreening process could be effected using, for example a validation station 22 (e.g., a kiosk) at an exit point form 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 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 3 is a schematic system diagram giving an overview of an example overall system configuration of an example embodiment.

Figure 3 illustrates various systems connected via a network 15, for example the Internet.

Figure 3 illustrates a plurality of user computers 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.

Figure 3 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 one or more input interfaces in the form, for example, of one or more 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 one or more output interfaces in the form, for example, of one or more of a display, a printer, a card writer and/or dispenser, a speaker. In an example embodiment the input station can be operable to issue a token, for example a card with a unique identifier.

Figure 3 illustrates a plurality of merchant systems 14 connected to the network

15. Each merchant system 14 can involve one or more computer systems, each comprising one or more processors, including processing logic, and memory, and one or more point of sale devices, that can include one or more input interfaces in the form, for example, of one or more of a keypad, a keyboard, a touch sensitive screen, a card reader, a scanner, a voice-activated input and one or more output interfaces in the form, for example, of one or more of a display, a printer, a card writer, a speaker.

Figure 3 illustrates a plurality of TRO acquiring host systems 20 connected to the network 15. Each acquiring host system can involve one or more computer systems, each comprising one or more processors, including processing logic, and memory.

Figure 3 illustrates a message switch 24 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 and a customs approval system 26.

Figure 3 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 one or more input interfaces in the form, for example, of one or more 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 one or more output interfaces in the form, for example, of one or more of a display, a printer, a card writer and/or dispenser, a speaker. The validation station could also be provided with one or more devices 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 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 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 is could be in the form of a magnetic stripe card, a chip card, a bar code, a QR code, a number that has to be entered at a key pad, etc.

The validation station can then determine eligibility for a refund based on information held in a customs approval system or a TRO acquiring host system defining one or more purchases associated with the identifier, in order to determine whether to validate a refund associated with the one or more purchases. 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 can respond to input of the token identifier to transmit a request to the server for information defining one or more purchases associated with the identifier, to compare information received from the server defining one or more purchases 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 can to transmit to the server confirmation that validation has been effected for the refund to be effected.

In another example, the validation station 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 respond to a response from the server indicative of whether a refund for the one or more purchases 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 can also be operative to prompt the user to identify 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 place airside to receive the cash. If the user selected cryptocurrency, the transaction can automatically be refunded to a cryptocurrency wallet, or the user prompted to provide a cryptocurrency wallet address as described above.

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 office can use an approval station to retrieve the information for the server system using the token identifier.

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

Using the token identifier, the customs officer can call up the transaction information form 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.

Figures 4-7 provide a flow diagram giving an overview of the operation of a system as illustrated in Figures 2 and 3.

At 410 (Figure 4), a user obtains a token. For example the user can specify a token or can be issued with a token as described above. In the example where the token is a cryptocurrency wallet, this user may create the cryptocurrency wallet or the user may register the cryptocurrency wallet in order to allow it to be used as a token in the TRO system.

At 412, the traveller presents the token when making a purchase. In the example where the token is a cryptocurrency wallet, the user may present a QR code, bar code or other machine readable identifier representing the address of the cryptocurrency wallet registered as the token. The purchase may be made in any suitable currency, for example the local fiat currency of the merchant or a cryptocurrency.

At 414, the merchant transmits a transaction record to an acquiring host system of a TRO that has provided the merchant with the POS devices and/or software. In an example embodiment this is done in real time using a message that includes a token identifier, such as the address for the cryptocurrency wallet, a receipt identifier and an amount of the transaction.

At 416 the acquiring host stores the transaction record to include the token identifier, the receipt identifier and the amount of the transaction.

Turning now to Figure 5, on leaving the territory, at 510 the user presents a machine readable ID (e.g., a passport) to an ID reader of a validation station (a kiosk) at a point of exit from the territory. In the example where the token is a cryptocurrency wallet, the user can present a QR code, bar code or other machine readable identifier representing the address of the cryptocurrency wallet registered as the token as the machine readable ID.

In this example, at 512, the kiosk determines the eligibility of a refund for the traveller based on stored information and on the identity of user derived from the machine readable ID, such as the address of the cryptocurrency wallet. Optionally, the kiosk could also verify the identity of the user by using biometric data held on the machine readable ID (e.g. a finger print or iris pattern).

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

Alternatively, if eligibility is detected, then at 518 the user can be invited to present the token.

At 520, the kiosk can read the token (e.g., using a card reader if the token is a card or, if the token is a cryptocurrency wallet, using a scanner to read a machine readable identifier representing an address of the cryptocurrency wallet) and can transmit a validation request to the customs approval system including a token identifier.

At 522, 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 524 approval is not given automatically, then the further processing is described with reference to Figure 7.

Alternatively, if at 524 approval is given automatically, then the approval system can transmit an approval message to the respective acquiring host system for each approved transaction.

Turning to Figure 6, 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 610 to the kiosk.

At 612, the kiosk can prompt the user to select a payment method, such as cryptocurrency.

At 614, 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 cash amount thereon. As described above, if the user selects cryptocurrency as a payment method, the kiosk can prompt the user to provide an address for the cryptocurrency wallet into which the payment should be made. Alternatively, if the token is a cryptocurrency wallet, the kiosk can action the payment into the cryptocurrency wallet associated with the token automatically.

Turning to Figure 7, where approval is not given automatically at 524, then the approval system can transmit at 710 a non-approval message to the respective acquiring host system for each approved transaction.

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

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

At 716, a customs officer can receive the token from the user or can invite the user to enter the token at a customs approval station, such as by presenting a machine readable identifier representing the address of the cryptocurrency wallet associated with the token.

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

At 720, 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 722, the customs officer approves a transaction then the process terminates at 724 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 of a given transaction is not given.

Alternatively, if at 722 approval is given for a refund, then at 726 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 728 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 730, the further processing to effect the refund can proceed as indicated in Figure 6 is steps 610-614.

Figure 8 illustrates a method of effecting the refund payment when cryptocurrency is a payment method, for example as part of step 614 illustrated in Figure 6.

At 810 the kiosk invites of otherwise prompts the user to provide an address for the cryptocurrency wallet into which the payment should be made, for example by scanning a QR code, barcode or other machine readable identifier representing the address for the cryptocurrency wallet or manually entering the address of the cryptocurrency wallet as described above. Alternatively, if the token is a cryptocurrency wallet, the kiosk can action the payment into the cryptocurrency wallet associated with the token automatically.

At 812 the kiosk transmits the cryptocurrency request and the address of the cryptocurrency wallet to the host system. The cryptocurrency request may contain the particular cryptocurrency, such as Bitcoin (BTC), Ethereum (ETH), Ripple (XRP), Litecoin (LTC) and Bitcoin cash (BCH), in which the refund payment is to be made. The kiosk may be configured to only refund payments in some cryptocurrencies, for example those which have subscribed to the TRO system. In this case, the kiosk is configured to list or otherwise indicate to the user which cryptocurrencies the payment can be made in when prompting the user to select the payment method. The cryptocurrency request may also contain the refund amount and the token ID if the token ID is not the address for the cryptocurrency wallet. Alternatively, host system may use the token ID to determine the refund amount, for example by accessing the transaction information associated with the token.

At 814, the host converts the refund amount into the relevant cryptocurrency. The host obtains a base conversion rate between the fiat currency of the refund amount and the relevant cryptocurrency. In some examples the host system is configured to transmit a request for the base conversion rate to a rate provider via a network and receive the base conversion rate in a response message. For example, the host system may have a separate or parallel administration process configured to create a base conversion rate in real-time from a basket of exchange rates obtained from one or more market rates from multiple rate providers, such as https://www.coinbase.com/ and https://www.btcmarkets.net/. Alternatively, the market rate at a data aggregator, such as the rate at https://coinmarketcap.eom/currencies/bitcoin/#markets may be used. The market data at data aggregators is derived from multiple exchanges worldwide. It will be appreciated that cryptocurrency exchange rates typically vary in real-time in the same manner as fiat currency exchange rates. Accordingly, the host system may be configured to maintain a record of the most recent exchange rates for each cryptocurrency in a table in storage, such as a rate table. The host can then obtain the base conversion rate by accessing the rate table. The host system may be configured to update the rates in the rate table periodically, for example every minute or every hour. Alternatively, the host system may be configured to obtain a base conversion rate in response to each cryptocurrency request received. The host system may apply a margin to the base conversion rate based on an average cost of converting the fiat currency into the cryptocurrency using known currency exchanges. The margin applied to the base conversion rate is configurable. For example, the margin might vary depending on which cryptocurrency is chosen in order to reflect the underlying buy-sell spreads that can be accessed via the various exchanges in used to generate the base conversion rate.

At 816 the host collects the refund amount from each of the merchants in the relevant fiat currency. For example, the transaction record acquired at recorded at the host in steps 414 and 416 illustrated in Figure 4 may be used to collect the relevant refund amount from the merchants corresponding to each transaction approved for a refund.

At 818 the host converts the refund amount in the relevant fiat currency into the relevant cryptocurrency using the base conversion rate, including the margin if applicable, and sends the converted amount to the address for the cryptocurrency wallet received from the kiosk, thereby paying the user.

At 820 the host transits an acknowledgement message to the kiosk acknowledging that the refund payment has been made.

At 822 the kiosk displays the acknowledgement message to the user, informing the user that the refund payment has been made into their cryptocurrency wallet.

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.

By providing an integrated system with information available from a server 5 system, in combination with the use of 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 an example embodiment the identity and eligibility verification is effected away from a shop. In an example embodiment this is done at the exit point.

Additionally this can be done at an entry point. An embodiment enables this to be achieved through the use of the integrated network approach and the use of the token identifier.

An embodiment may be embodied in a computer program product for operating one or more processors. The 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.

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

1. An apparatus comprising a validation station having:

a validation station input interface configured to receive a token, the input interface comprising a reader operable to read a machine readable user identifier that identifies the user;

validation station processing logic configured to transmit a validation request message that identifies the token to an approval system that holds or has access to transaction information identifying one or more purchases associated with the token to validate a tax refund for the one or more purchases for an eligible user, eligibility being derived from information from the machine readable identifier, the validation station processing logic further being configured to receive a response message from the approval system; and a validation station output interface configured to indicate to the user whether a refund associated with the one or more purchases has been validated, wherein the refund is to a cryptocurrency wallet associated with the user.

2. The apparatus of claim 1, wherein the validation station processing logic is operable to determine the eligibility of the user to receive a refund by comparing information from the machine readable identifier to information stored in the validation station.

3. The apparatus of claim 2, wherein the validation station processing logic is operable to obtain a token identifier in response to determining eligibility of the user to receive a refund from comparing information from the machine readable identifier to information stored in the validation station.

4. The apparatus of any preceding claim, wherein the validation station processing logic is responsive to a first response message to indicate to the user that a refund associated with the one or more purchases has been validated automatically, and the validation station processing logic is responsive to a second response message to refer to the user to a manual validation check.

5. The apparatus of any preceding claim, wherein:

the validation station input interface further comprises one or more of a keypad, a keyboard, a touch sensitive screen, a card reader, a reader for a machine readable identifier, a scanner, a voice-activated input, a camera, biometric information capture apparatus; and the validation station output interface comprises one or more of a display, a printer, a card writer, a speaker.

6. An apparatus comprising an approval station having:

approval station input interface configured to receive a token, the input interface comprising a reader operable to read a machine readable user identifier that identifies the user;

approval station processing logic configured to obtain information from an approval system that holds or has access to transaction information identifying one or more purchases associated with the token;

an output interface configured to present to an official details of the one or more purchases and/or of the user associated with the identifier.

7. The apparatus of claim 6, wherein the approval station is responsive to the official validating a refund associated with the one or more purchases to transmit a confirmation message to at least one of the approval system or a host system that validation has been effected for the refund to be effected, wherein the refund is to a cryptocurrency wallet associated with the user.

8. An apparatus comprising an approval system, the approval system having: access to storage for transaction information identifying one or more purchases associated with a token;

approval system storage for rules defining eligibility for a tax refund;

approval system processing logic operable in response to a validation request message that is received from a validation station and that identifies the token and a user to determine whether to validate a refund associated with the one or more purchases based on the token for the user and to transmit a validation response message, wherein the refund is to a cryptocurrency wallet associated with the user.

9. The apparatus of claim 8, wherein the approval system processing logic is operable to transmit the validation response message to an operator host system that maintains a relationship between the token and the user.

10. The apparatus of claim 8 or claim 9, wherein the approval system processing logic is operable to transmit a first validation response message where a refund associated with the one or more purchases has been validated automatically, and to transmit a second response validation message where a refund has not been authorised automatically and the user is to be referred to a manual validation check.

11. The apparatus of any of claims 8 to 10, wherein the approval system processing logic is further operable, in response to an information request from an approval station that identifies the token, to provide to the approval station transaction information identifying one or more purchases associated with the token.

12. The apparatus of any of claims 8 to 11, wherein the transaction information identifying one or more purchases associated with a token is stored in the approval system storage.

13. The apparatus of any of claims 8 to 12, wherein the transaction information identifying the one or more purchases is stored in an operator host system.

14. An apparatus comprising an operator host system having:

storage for storing transaction information identifying one or more purchases in association with a token and a merchant identifier; and processing logic responsive to transaction information that identifies one or more purchases associated with a token from a merchant system to store the transaction information identifying one or more purchases in association with the token and the merchant identifier, the processing logic being further operable to transmit the transaction information identifying with one or more purchases associated with the token to an approval system.

15. An apparatus comprising a merchant system having:

merchant system input interface configured to receive a token identifying a user and/or details of one or more purchases, merchant system processing logic operable to transmit a transaction message to an operator host system, the transaction message defining one or more purchases associated with a token and a merchant identifier.

16. The apparatus of any proceeding claim, wherein the apparatus operates realtime messaging.

17. The apparatus of any preceding claim, wherein the machine readable identifier is one or a QR code or bar code representing an address for a cryptocurrency wallet.

18. The apparatus of any preceding claim, wherein the token is a cryptocurrency wallet.

19. The apparatus of any preceding claim, wherein the information identifying one or more purchases associated with the token comprises a transaction identifier.

20. A refund system comprising the apparatus of one or more of the preceding claims interconnected by a network.

21. A computer implemented method of processing a refund comprising:

in response to a user making one or more purchases, recording transaction information representative of the one or more purchases associated with a token; and in order to validate a refund, a validation station receiving input of a machine readable user identifier and the token; and an approval system that holds or has access to the recorded transaction information determining whether to validate a tax refund for the one or more purchases for an eligible user, eligibility being determined from information from the machine readable identifier;

the validation station indicating to the user whether a refund associated with the one or more purchases has been validated and in response to positive validation, effecting a refund to a cryptocurrency wallet associated with the user.

22. The method of claim 21, comprising validation station determining eligibility by comparing information read from the machine readable user identifier to information stored in or accessible to the validation station.

23. The method of claim 21 or claim 22, wherein the validation station, in response to receipt of the token and the machine readable user identifier, transmits a validation request message that identifies the token and the user to the approval system.

24. The method of any of claims 21 to 23, wherein a first response message from the approval system represents that a refund associated with the one or more purchases has been validated automatically, and a second response message indicates that the user is referred to a manual validation check.

25. The method of claim 24, wherein, for a manual validation check, an approval station is responsive to input of the token and the machine readable user identifier to transmit an information request message to the approval system to retrieve information to determine eligibility for a tax refund for the one or more purchases and is operable to display the retrieved information to an official.

26. The method of claim 25, wherein the approval station is responsive to the official validating a refund associated with the one or more purchases to transmit a confirmation message to at least one of the approval system or a host system that validation has been effected for the refund to be effected.

27. The method of any of claims 21 to 26, wherein the approval system determines, on the basis of pre-defined rules, whether to validate a refund associated with the one or more purchases based on the token and the identity of the user.

28. The method of any of claims 21 to 27, wherein the approval system stores the transaction information.

29. The method of any of claims 21 to 27, wherein the approval system accesses the transaction information from an operator host system.

30. The method of any of claims 21 to 29, wherein an operator host system stores transaction information identifying one or more purchases in association with a token and merchant identifiers.

31. The method of any of claims 21 to 30, wherein the transaction information identifying one or more purchase transactions and the token is input at a merchant system, the merchant system transmitting a transaction message to an operator host system.

32. The method of any of claims 21 to 31, employing real-time messaging.

33. The method of any of claims 21 to 32, wherein the machine readable identifier is one or a QR code or bar code representing an address for the cryptocurrency wallet.

34. The method of any of claims 21 to 33, wherein the token is the cryptocurrency wallet.

35. The method of any of claims 21 to 34, wherein the information identifying one or more purchases associated with the token comprises a transaction identifier.

36. A program product comprising program instructions for carrying out the method of any of claims 21 to 35.

5

37. The program product of claim 36, comprising a carrier medium carrying the program instructions.