TRANSACTION SYSTEM AND METHOD
BACKGROUND[0001] The present invention relates to a system and method to facilitate transactions, for example for obtaining refunds associated with purchases.
[0002] 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 - 10 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.
[0003] However, such a process can be very labour and cost intensive. There are significant technical difficulties in ensuring that a tax refund system can operate efficiently, while at the same time being secure.
[0004] The present invention seeks to provide a technological solution to facilitate the initiation of refund processing.
SUMMARY[0665] Aspects of the invention are defined in the claims.
[0006] An aspect of the invention provides a system comprising a purchase system "for processing purchase transactions in respect of goods or services, and a refund subsystem operationally connected to the purchase system and operable to process a tax refund transaction in respect of a purchase transaction. The purchase system is configured, in response to identification of goods or services for a purchase transaction, to retrieve stored purchase transaction information in respect of the purchase transaction for issuing a receipt for the purchase transaction and to communicate the purchase transaction information to the refund subsystem. The :
refund subsystem is responsive to user input to initiate a tax refund transaction in respect of the purchase transaction, the tax refund transaction including the generation of tax refund cheque. 10007] An aspect of the invention provides a method of processing a tax refund transaction in respect of a purchase transaction. The method comprises a purchase system processing a purchase transaction in respect of goods or services. A refund subsystem operationally connected to the purchase system processes a tax refund transaction in respect of a purchase transaction. The purchase system, in response to identification of goods or services for a purchase transaction, retrieves stored purchase transaction information in respect of the purchase transaction for issuing a receipt for the purchase transaction and communicates the purchase transaction information to the refund subsystem. The refund subsystem responds to user input to initiate a tax refund transaction in respect of the purchase transaction, the tax refund transaction including the generation of tax refund cheque.
[0008] 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[0009] Embodiments are described, by way of example only, with reference to the accompany drawings.
[0010] Figure 1 is a schematic diagram of an example embodiment of a refund system according to an embodiment of the invention, foo11] Figure 2 is a schematic system overview;
[0612] Figure 3 is a schematic block diagram representing functional elements of a purchase system and a refund subsystem,
[0013] Figures 4 and 5 are flow diagrams of example methods of operation.
DETAILED DESCRIPTION[0014] An example embodiment of the invention seeks to provide simplicity of operation while providing flexibility of use. In example embodiments one or more devices, apparatus and systems coordinate processing of purchases and refunds.
One or more devices, apparatus and systems can be operated by merchants and/or
Tax Refund Operators (TROs) and/or customs authorities.
[0015] As well as providing administration of refund operations, a TRO can provide education for a user and merchants throughout the process. Through the use of information technology systems, the TRO can ensure the integrity of the system.
[0016] Figure 1 illustrates an example method, apparatus and system 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).
[0017] 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. A wide range of point of sale (POS) devices and in-store support for user shopping can be provided.
[0018] In an example embodiment, a merchant system can provide the issuing 30 of transactions using TRO provided POS refund processing devices and/or software. A
TRO operated host system can carry out acquiring 32 of tax refund transactions. A validation system (for example a customs approval system) can carry out tax refund authorization 34. The host system can carry out refund payment operations 36. An automated kiosk (otherwise termed a validation station or validation terminal) can be provided at a point of exit from a territory and can be used for various operations, including the automatic recognition of a token for identifying a user. Refund payments can be handled by a refund desk (run by the TRO) or by the kiosks for immediate refunds in cash, or refunds can be provided using automated payments to bank and/or credit card accounts and/or using back-office processes by the TRO.
[0019] The determination of eligibility of a user can be made in store at atime of a purchase transaction as will be described later. However, subject to legal requirements in a given territory, the determination of eligibility and identity can be moved away from a point of sale to the point of exit from the territory.
[0020] An example embodiment can provide simplicity and flexibility of use as perceived by the users of the system, while also providing security and integrity of operation.
[0021] 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 user. In fact, many users are reluctant to carry their passports while out shopping,
and so some shops permit the user to fill in such details that are required on refund vouchers after leaving the shop.
[0022] As indicated above, subject to legislative requirements in a given territory, user (e.g., traveller) purchases can be recorded using a token when making a purchase and eligibility could be 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 trained customs or other staff or even by machine (e.g., using biometric testing).
[0023] Examples of possible tokens can include a passport number, a passport, a landing card, an identity card number, an identity card, a driver's licence number, a driver's 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. 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 or a bar code that would have a unigue number.
[0024] By presenting the token when making a purchase, a record of the purchase can be associated with the token. A computer record can be made, for example in a remote host system such as a TRO host system, of an association between the token and a transaction identifier for a purchase transaction for one or more purchases.
The token can then be used subsequently to retrieve the record of the transaction(s) from the remote server on exit from the territory to validate the refund on later purchases, for example for one or more subsequent trips. In an example embodiment, a computer record of the transaction identifier could be stored without a token if no token is available, the transaction identifier effectively becoming a temporary token. 0025; 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 1, in which one or more TROs, for example multiple TROs, affiliate merchants, and then provide tax refunds to users through the user of a self-service kiosk 22 at an exit point from a territory.
[0026] A token can be allocated to a user at stage 102. This can be done before or at a point of entry to the territory or at a point of sale. Alternatively, it can be allocated
} S following a purchase, for example at a kiosk 22 on exiting the territory in which the purchase is made and then be usable for subsequent trips, or at some intermediate time. In the latter case, the temporary token represented by a transaction identifier for the purchase can be used to form or to set up a token for the user. In one example the user can choose a token to be used. For example the user could specify, for - example via a website, or at a point of sale or other terminal, or in response to being asked by a merchant, or at a kiosk 22, a particular token to be used (e.g., a token of one of the types referenced above). For example, a user can register his/her details and associate his/her details with one or more tokens 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 to the territory, at a point of sale, or a point of exit from the territory, 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, 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 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).
[0027] 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 (a TRO host system) 20 where the identifier and the user details are recorded (stored). The host system 20 can comprise one or more server computers, each comprising one or more processors and memory, located in a single place orin 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 system 20 and are recorded in real time. In the event that a transaction identifier has been stored without a separate token identifier, then the token identifier when issued can be associated with the transaction in the host system 20, for example.
[0028] The user 12 can make purchases at 104, for example at a merchant, using the token, if available. In an example embodiment, the user can initiate processing of a refund transaction. The information relating to a purchase transaction, for example including a receipt identifier for a conventional purchase receipt, can be transmitted automatically to a refund subsystem. The user can be prompted, for example by the merchant or by the refund subsystem, to initiate a refund transaction, the refund subsystem already having been provided with the detail of the purchase transaction.
A second transaction can thus be generated using, for example, the receipt identifier (e.g. a receipt number), the value of the goods purchased, and the token identifier, if available. Thus, in this example embodiment, information including two or three items (receipt identifier, value of purchase, and token identifier if available} can then be electronically transmitted by a merchant system 14 to the host system 20.
[0020] The merchant system 14 can comprise one or more computers, each comprising one or more processors and memory, located in a single place or in a distributed system. The functionality can be integrated into a point of sale (POS) refund terminal (refund subsystem) where purchase details are directly retrieved from an electronic cash register (ECR) (purchase system) and therefore there is no need to enter this information again.
[0030] There may be only one TRO in a market. However, where there are 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.
[0031] The transaction message can therefore be transmitted 105 to the TRO 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) if available, 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 fo collect.
[0032] A separate host system 20 ¢an 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 Co generated by affiliated merchants can be stored in the database of the host system 20. A transaction record as stored in memory of the host system 20 can include, for example, a unique transaction identifier for the transaction, a token identifier (e.g., a token number) where available, a receipt identifier (e.g. a receipt number), references tothe goods purchased, a merchant identifier and a time and date stamp. The host system 20 can allocate the 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. The transaction identifier can be returned to the merchant system and can be printed on a purchase receipt given to a user, using clear text and/or a visible encoding such as a bar code or the like.
[0033] A message interface 24, for example a web-service based interface using an industry standard (e.g. SOAP, WCF, XML over IP), can provide an interface for messages to be formatted and/or routed. For example transaction messages can include one or more of the transaction identifier (e.g. a transaction number), the token identifier (e.g., a token number) if available, the receipt identifier (e.g. a receipt number), references to the goods purchased, the merchant identifier, the TRO identifier, the time and date stamp, and the security hash (which is used to prevent tampering). The message switch 24 may be a separate system, or combined with a validation system (for example a custom approval system) 26 according to a particular implementation.
[0034] In one example embodiment the message interface 24 could be implemented as a server system that comprises processing and storage capacity and is operable to act as a central repository for data to be accessed by the host system(s) and the validation system as well as providing for message formatting and forwarding.
However, in another embodiment the data can be held in the TRO's host systems and can be accessed via the message switch by the validation system 26.
[0035] The validation 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 validation system 26 is capable of approving or rejecting tax refund transactions automatically based on rules set in the system by customs. The validation system 26 can also be accessed manually by a customs officer.
[0036] Validation systems including self-service validation stations (kiosks) 22 at the territory exit points can be connected to the TRO host system(s) 20, for example via a standardized web service or through the message interface 24. A validation station 22 can be configured to invite a user to present a personal 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).
[0037] 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 personal identifier. In this example the validation station 22 reads the information from the personal identifier and determines eligibility by checking the information against an internal database that contains information about domestic/non-eligible users. 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 users. In this case, the user can be deemed eligible if his/her nationality or status is on the list (positive approval).
[0038] As mentioned above, the validation station 22 could also be provided with a fingerprint scanner and/or 2 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://www. highprogrammer.com/alan/numbers/mrp.html. 10039] 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 send one or more validation request messages to the TRO host system(s) 20 a standardized web service and/or via the message interface 24. In response to receipt of the token, the TRO host system 20 will return all transactions that are suitable for export validation.
[0040] Where the user does not enter a token, for example if the token has been mislaid, the validation station can be operable {o prompt the user to enter a transaction identifier that relates to a transaction effected with a token to retrieve the information for that token. The transaction identifier can be printed in human and/or machine readable form on a purchase receipt.
[0041] As another alternative, for example if the user had not already registered, then the user can be prompted to enter registration details, for example including a token to be used.
[0042] The validation station can also be operable to prompt the user to enter one or more transaction identifiers that relate to transactions effected without a token and to associate the transactions with the user. The transaction identifier can be printed in human and/or machine readable form on a purchase receipt.
[0043] The order of operation of the validation station 22 could vary from that indicated above according to implementation.
[0044] 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 validation system can determine eligibility and whether to validate the transactions.
[0045] As will be described in the following, the validation station can also be operable to prompt the user to enter missing or further personal information or transaction details that are not already held centrally (for example to complete a registration process and/or to obtain a token, or to enter purchase transactions for where no token was presented and/or available at the time the purchase transaction was performed). Computer records associated with information entered at the validation station can then be updated or recorded centrally in the host systems 20.
[6046] The validation system 26 can be operable to respond to a validation request message to retrieve all the transactions for the user (for example all transactions already associated with the token and/or transactions entered at the validation terminal) from its own database and/or from the host systems 20, and can apply rules set to determine approval or rejection. {0047] In one example, the validation system 26 could be set to either automatically approve one or more of 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 validation system 26. :
[0048] When the validation system 26 has made a decision about a transaction (approvefreject), an authorization message (validation request response message} is automatically routed through the message interface 24 back to the appropriate host system 20. Such a response could be in the form of a web service response and can hold the electronically approved transactions (including an electronic customs stamp).
The host system 20 updates an existing tax refund transaction record for the transaction with the authorization message (approve, reject, change).
[0649] In an example embodiment the customs approval host does not act as the payment authorization host, but rather the TRO’s host system 20 is the system of record.
[0050] Each 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 a token can be given first position on the validation station, and that TRO’s transactions are displayed. [oos1] [f one or more of the retrieved transactions have approved codes, the user could be given "green channel" service for the approved transactions and could be asked how a refund is to be paid. If any of the transactions are not approved, the user is given "red channel" service for at least those transactions (possible for all transactions) and is asked to present himself to a customs officer for further processing.
[0052] If the choice of refund is to 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 optionally prompt the user to swipe a card to which the refund should be made. 10053] 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. Alternatively, or in addition, if the user requests a cash equivalent refund and the user has not used a TRO-issued token, a stored-value card or cash could be issued from the validation station 22, subject to the kiosk being provided with a cash dispensing capability.
[0054] 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 validation system 26.
However, in other examples, the approval stations can be separate from and/or remote from the validation system and can communicate therewith, for example via the message switch.
[0055] In response to input of a 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 validation system 26, that can then retrieve a list of approved and rejected fransactions associated with the token.
[0056] The customs officer can then approve or reject each transaction, or change (reduce) 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 validation system 26 through the message switch 24 to the appropriate host system 20. The host system 20 then contains tax refund transactions with approval codes (approved, rejected, changed value).
[0057] In some implementations, the user could 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.
[0058] 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 host systems 20. In the first mode of operation, the validation system 26 is operable to retrieve transaction information from the respective host system 20 for validating refunds. The result of the authorisations is communicated back through the message switch 24 to the appropriate host system 20. The host system 20 now contains tax refund transactions with approval codes (approved, rejected, changed value). In the second mode of operation, the validation system retains a copy of each transaction within its own database, associated not only with the relevant token identifier, but also with a host system identifier. In this case the validation system 26 also passes the transaction and approval code back to the 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 host systems 20.
[0059] 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 aliow for multiple TRO providers, while ensuring that customs and tax authorities only have to deal with a single system for approvals.
[0060] By recording transactions on the host system 20 and/or on a validation system 26 using at least a transaction identifier and a value of purchase, and then associating user detail records linked to a token identifier in the host system, a validation system 26 can be operable to retrieve refund transactions from the 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 host system 20.
[0061] In the illustrated example communication between the host system(s) 20 and the validation system 26 can be effected via a message interface 24. The message interface 24 can provide a dedicated network between the validation system 26 and the host systems 20 for one or more TROs. The message interface can be implemented using web services or other online or offline connection arrangements.
[0062] 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 form the territory.
[0063] The validation station 22, or an approval system (e.g. the validation 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 at a customs station 16 for approval.
[0064] 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 according to certain criteria such as: country of origin of the traveller, item value, transaction value, value of all transactions, quantity of goods, merchant, etc., and logical combination of such criteria. Also white and black lists for countries or origin, retailers, travellers and so on can be used.
[0065] Figure 2 is a schematic system diagram giving an overview of an example overall system configuration of an example embodiment.
[0066] Figure 2 illustrates various systems connected via a network 15, for example the Internet.
[0067] Figure 2 illustrates a plurality of TRO host systems 20 connected to a network 15, for example the Internet. A user (traveller) can use a computer (not shown, for example a desktop, laptop, personal data assistant, mobile telephone, etc) connected to the network 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.
[0068] Alternatively, a user can use an input station (also not shown), connected to the network 15. An input station can be provided, for example, at a point of entry (e.g. an airport immigration area), a tourist office, a railway station, a retailer etc. An input 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 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. The unique identifier can be carried by the card (for example a plastic or paper card) and : can, for example be a unique card number, the passport number, a payment card number or some other identifier for the user. However, it is to be noted that in other example embodiments a physical token need not be issued, but the token may be another pre-existing identifier such as a passport, an ID card, a credit card or the like.
[0069] Figure 2 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 and memory, and one or more point of sale (POS) purchase systems (POS terminals) 44, 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. Each purchase system 44 is associated with refund subsystem 242 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, and communications interfaces for interfacing with the point of sale terminal and with a
TRO host system 20.
[0070] Each of the host systems 20 can involve one or more computer systems, each comprising one or more processors and memory.
[0071] Figure 2 illustrates a message switch 24 connected to the network 15. In this example the message switch 24 acts as a communications interface between the host systems 20, validation stations 22 and a validation system 26.
[0072] Figure 2 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.
[0073] The familiarity of users with automated teller machines and the like means that validation stations in the form of automated self-service kiosks at the exit points are acceptable to users.
[0074] 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 can be in the form of a magnetic stripe card, a chip card, a bar code, a passport, ID card, a number that has to be entered at a key pad, etc.
[0075] If a token is provided by the user, the validation station 22 can then determine eligibility for a refund based on information held in a validation system or a TRO host system defining one of more purchases associated with the token 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.
[0076] The validation station 22 can be operable to provide the user with other options than the present of a token to identify the user and/or to associate purchases with the user, for example by prompting the user to input a transaction identifier.
[0077] 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). In one example, the pre-defined validation rules are held in a validation system and would be received from the validation system with an electronic customs stamp attached. 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.
[0078] In example embodiments the validation stations can allow the user to modify his transactions. Means exclude transactions or items out of transactions or decrease quantity and amount of certain purchases, prior to requesting approval.
[0079] 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).
[0080] Alternatively, the user can be prompted to report to a manual validation check by a customs officer, for example at a customs desk provided with an approval station 28 connected to the validation system 26.
[0081] 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.
[0082] 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.
[0083] At the customs desk, a customs office can use the approval station 28 to retrieve the information from the server system using the token identifier and/or a transaction identifier.
[0084] An approval station 28 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.
[0085] Using the token identifier or a transaction 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.
[0086] 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 28. Alternatively, a debit card could be generated by the approval station 28, by the validation station 28 or by a
TRO service desk provided with a TRO station 56.
[0087] Figure 3 is a schematic representation of an example of a merchant's point of sale purchase system. As illustrated in Figure 1, the merchant system 14 includes a merchant system server connected to a plurality of purchase systems, for example point of sale terminals 44. As illustrated in Figure 3, the point of sale terminals include a POS module 214 that is configured in a conventional manner to provide point of sale purchase transaction processing. The point of sale terminal 44 also includes an interface module that provides an interface to the merchant server system and also an interface to one or more refund subsystems 242 (one is shown in Figure 3 by way of illustration only), for example provided by one or more TROs. A refund subsystem 242 can be in the form of an integrated unit that includes input devices, a printer and a communications interfaces for interfacing with the point of sale terminal and with a
TRO host system 20.
[0088] In an example embodiment, the point of sale terminal is configured, in response to identification of goods or services for a purchase transaction, to retrieve stored purchase transaction information in respect of the purchase transaction for issuing a receipt for the purchase transaction and to communicate the purchase transaction information to the refund subsystem. The point of sale terminal can be : configured to identify the goods or services in response, for example, the scanning of a bar code on or associated with the goods or services using a bar code scanner of the point of sale terminal.
[0089] The refund subsystem can be configured to be responsive to user input to initiate a tax refund transaction in respect of the purchase transaction, wherein the tax refund transaction including the generation of tax refund cheque.
[0090] The refund subsystem can be provided with a printer for printing a tax refund : cheque.
[0091] Alternatively, or in addition, an electronic tax refund cheque can be generated.
The refund subsystem can be connected via a network to a remote host server, for : example a TRO host server for storing records for electronic tax refund cheques created by the tax refund subsystem.
[0092] The refund subsystem can be in the form of a terminal operationally connected . to the purchase system. The refund subsystem terminal can be configured to initiate a tax refund transaction in respect of the purchase transaction in response fo the tax refund terminal detecting a user initiated operation.
[0093] The refund subsystem can include one or more input devices.
[0094] For example, it can be provided with one or more keys or buttons, including a button for user activation to request a tax refund.
[0095] The refund subsystem can be provided with one or more buttons (using one or more keys, touch sensitive screens, etc) and can be configured to initiate a tax refund transaction in respect of the purchase transaction in response to detecting activation of one or more of the button or other input device.
[0096] The refund subsystem can be provided with a card reader and can be configured to initiate a tax refund transaction in respect of the purchase transaction in : response to detecting swiping of a machine readable magnetic stripe of a card in the card reader.
[0097] The refund subsystem can be provided with a card reader and can be configured to initiate a tax refund transaction in respect of the purchase transaction in response to detecting reading of a chip of a smart card in the card reader.
[0698] The refund subsystem can be provided with a bar code reader and can be configured to initiate a tax refund transaction in respect of the purchase transaction in response to detecting reading of a bar code on a card or other token.
[0099] The refund subsystem can be provided with a near field communications reader and can be configured to initiate a tax refund transaction in respect of the purchase transaction in response to detecting reading of information from a near field communications enabled device. Near Field Communications (NFC) technology is a short-range wireless communication technology that can enable the exchange of data between devices over about a short distance, for example over a distance of about 0.1 metre. NFC technology is an extension of the proximity-card standard (contactless card, RFID) that can combine the interface of a smartcard and a reader into a single device. It is compatible with existing contactless infrastructure aiready in use for public transportation and payment. NFC is primarily aimed at usage in mobile telephones. Examples of mobile phones are already on the market that use NFC technology. NFC reading/writing devices that incorporate NFC interfaces are also available from various manufacturers.
[00100] The refund subsystem can be provided with an RFID reader and can be configured to initiate a tax refund transaction in respect of the purchase transaction in response to detecting reading of information from a RFID enabled device.
[00101] The refund subsystem can be provided with a machine readable identity document reader and the refund subsystem terminal can be configured to initiate a tax refund transaction in respect of the purchase transaction in response to detecting reading of information from a machine readable passport or other machine readable identity document.
[00102] The refund subsystem can also be configured to use a mobile communications device operationally connected to the purchase system and to initiate a tax refund transaction in respect of the purchase transaction in response to a user initiated operation using the mobile communications device.
[00103] The refund subsystem can also be configured to determine the eligibility of the user for a tax refund. For example, the refund subsystem can be configured to determine the eligibility of the user in response to the user input using information provided as a result of the user input and/or input by a merchant. The determination of eligibility can be effected by checking the input information against pre-registered information. The pre-registered information can be held in storage at a remote host server, for example a TRO host server, operatively connected to the refund subsystem, the refund subsystem being operable to query the remote server using the input information for confirmation of eligibility.
[00104] Figure 4 illustrates a summary of phases of operation of the POS terminal.
[00105] As shown in Figure 4, at 412, the POS terminal is configured to capture an identification of goods or services for a purchase transaction. This can be achieved, for example, by scanning a bar code on or associated with the goods or services, detecting an RFID or NFC identifier for the goods or services, by the manual entry by a merchant operator of a detail or code on or associated with the goods or services, etc.
[00106] At 414, the POS terminal is operable to retrieve stored purchase transaction information in respect of the purchase transaction for issuing a receipt for the purchase transaction. This can be retrieved, for example from the merchant server system, where the information is stored, or alternatively from the memory of the POS terminal or elsewhere.
[00107] At 416 data defining the purchase transaction is transmitted via the interface module 224 to the refund subsystem 242.
[060108] At 418, the POS terminal can be operable to complete processing of the purchase transaction, including the printing of a receipt, if required.
[00109] Figure 5 illustrates phases of operation of the refund subsystem in response to receipt of the data received from the POS terminal 44.
[00110] At 512, the refund subsystem receives the data from the POS terminal. The refund subsystem can be operable to start a timer in response to the receipt of this data. The refund subsystem can also be operable to prompt a user to request a refund transaction, for example by an audible or visual advice using output mechanisms such a speaker, a display, a light, etc.
[00111] At 514, the refund subsystem can be operable to determine whether the timer has indicated that a predetermined timeout time has elapsed since the receipt of the data from the point of sale terminal. If the timeout time has elapsed, the refund subsystem can be operable at 516 to purge from its memory the data received from the point of sale terminal in association with the purchase transaction.
[00112] If, however, the timeout time has not elapsed, the refund subsystem can be operable at 518 to determine whether the user has carried out an action for initiating refund processing. As explained above, the user action can take different forms, dependent on the input device with which the refund subsystem is provided.
[00113] For example, where the refund subsystem terminal is provided with one or more keys or buttons, the user action can be activation of a button. Where a refund subsystem terminal is provided with a card reader, the user action can be swiping of a machine readable magnetic stripe of a card in the card reader, or reading of a chip of a smart card in the card reader. Where the refund subsystem terminal is provided with a bar code reader the user action can be presenting a bar code on a card or other token for reading by the bar code reader. Where the refund subsystem terminal is provided with an NFC reader, the user action can be presenting a NFC enabled device to the NFC reader. Where the refund subsystem terminal is provided with an
RFID reader, the user action can be presenting an RFID enabled device for reading by the RFID reader. Where the refund subsystem terminal is provided with a machine readable identity document reader, the user action can be presenting a machine readable passport or other machine readable identity document to the reader.
[00114] As also mentioned above, the refund subsystem can also be configured to use a mobile communications device operationally connected to the purchase system and to initiate a tax refund transaction in respect of the purchase transaction in response to a user initiated operation using the mobile communications device.
[00115] If, at 518 no user action has been effected, the process returns to step 514, and the loop of steps 514 and 518 is repeated until either the timeout timer times out, as described above, or an appropriate user action is detected.
[00116] If, at 518, an appropriate user action is detected, then at 520, the refund subsystem terminal initiates refund processing operations.
[00117] The refund subsystem can be operable to transmit a transaction message to the host system 20. The transaction message can include a receipt identifier (e.g. a receipt number), the value of the goods purchased, and a user token identifier.
Further information can also be included in the message, for example details of the goods purchased.
[00118] The host system 20 can be operable to allocate a transaction identifier (e.g. a transaction number or string) the transaction and creates a transaction record including the transaction identifier, the receipt identifier, the value of purchase, and the mobile communications device identifier). Further information can also be included in the transaction record, for example details of the goods purchased.
[00119] In other words, an example transaction record entry held at the host system can include the following fields, some or ail of which may be populated in response to the above described steps:
Transaction identifier
Receipt identifier
Value of purchase
Token identifier;
Registered flag;
Details of Goods;
Details of traveller;
A payment target.
[00120] The host system 20 can further be configured to return a transaction response message that includes the transaction identifier that can be printed on the purchase receipt printed by the merchant system 14.
[00121] As part of the refund processing, the refund subsystem can also be configured to determine the eligibility of the user for a tax refund. For example, the refund subsystem can be configured to determine the eligibility of the user in response to the user input using information provided as a result of the user input and/or input by a merchant. The determination of eligibility can be effected by checking the input information against pre-registered information. The pre-registered information can be held in storage at a remote host server, for example the TRO host system server 20, operatively connected to the refund subsystem 242, the refund subsystem 242 being operable to query the remote server using the input information for confirmation of eligibility.
[00122] The refund subsystem can be provided with a printer for printing a tax refund cheque, for example following confirmation of eligibility.
[00123] Alternatively, or in addition, as mentioned above, an electronic tax refund cheque can be generated by means of the refund subsystem communicating via a network with a remote host server, for example the TRO host server 20, which can be operable to store records for the electronic tax refund cheques.
[00124] 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. lt is intended that the following claims be interpreted to include all such variations and modifications and their equivalents.