WO2007048179A1

WO2007048179A1 - Method and system for acquiring product data

Info

Publication number: WO2007048179A1
Application number: PCT/AU2006/001579
Authority: WO
Inventors: Mark Nagy; Tareq Hafez
Original assignee: Keycorp Limited
Priority date: 2005-10-24
Filing date: 2006-10-24
Publication date: 2007-05-03
Also published as: AU2005225141A1

Abstract

The present invention provides a method and system for acquiring product data through the use of a payment terminal. The method includes receiving product identification data at a payment terminal, aggregating said product identification data with at least location identity data to form a message and communicating said message via a network to a server.

Description

METHOD AND SYSTEM FOR ACQUIRING PRODUCT DATA

FIELD OF THE INVENTION

The present invention relates to a method and system for acquiring product data, and is particularly suited to the collection and management of product sales data from many different locations. BACKGROUND OF THE INVENTION

Small retail stores such as convenience stores sell many different products originating from many different suppliers. Given the limited technological resources of many convenience stores, it is often difficult for the store owners to easily collect data relating to the sale of their stock.

In addition, the suppliers of products to these retail stores often have limited information in regard to the products sold at specific locations. While manual figures may be acquired by considering the number of products supplied to a particular location over a certain time period, this data is often not accurate, is of limited detail, and is time consuming to acquire. The same products may also be supplied through many different intermediaries, so the manufacturer itself will not know the final sales location of the products.

For many suppliers, the only way to efficiently manage their products at retail stores is to employ representatives who regularly visit stores to check and monitor stock levels. Eliminating the need for representatives to frequently visit a large number of stores would improve efficiency and reduce the costs to suppliers.

Alternatively, some suppliers simply make regular telephone calls to retailers to ask whether they require any more stock. It is then the responsibility of the retailer to estimate the amount of stock remaining and how much they are likely to require. This method of stock control is often inaccurate because retailers do not know exactly how much stock they have on hand and in storage at the time sales representative calls, and highly inefficient as often more stock is ordered than is actually required. It would be advantageous to both suppliers and retailers to have a system that enables the automatic monitoring of purchases to assist with stock re- ordering and control. It would be further advantageous if the system could be accessed and utilised by both the supplier (or manufacturer) and the retailer.

Many large supermarkets and the like do have sophisticated Point of Sale (POS) systems that are linked to systems incorporating software that automatically process the stock at hand. These systems can then provide reports for each product to enable automatic or semi-automatic ordering of new stock. However, for smaller businesses, which represent approximately 80% of the market, such form of stock control is not achievable.

In addition, it would be advantageous for suppliers to have a system that enables the collecting and acquisition of product data such as the times of day or days of the week when specific products achieve the greatest sales, or which locations have the greatest sales in certain products. This type of information allows marketing strategies to be developed by suppliers or manufacturers in accordance with the sales data collected.

For example, a supplier may wish to run a promotion on one particular product at one store. It would be preferable for such a promotion to be run on the day and time when the particular product usually achieves the highest sales at that particular store. Alternatively, a supplier or manufacturer can use sales and product data acquired on their products to run campaigns on underperforming products or in underperforming areas. Presently gaining such data from retail stores that have limited technological resources is a difficult task.

One available option is to install software onto a retail sales terminal which collects data as products are sold. However, this is not an option for businesses that do not have sophisticated IT systems, and for small retail businesses it is not practical from a cost and system maintenance perspective. It is an object of the present invention to provide a method and system for collecting and processing product data which is practical for use in a wider range of businesses. SUMMARY OF THE INVENTION

Broadly, the present invention utilises an electronic payment terminal as a mechanism to collect, process and communicate product information from the point of sale to a remote location. According to a first aspect of the present invention, there is provided a method for acquiring and communicating product data, said method including the steps of: receiving product identification data at a payment terminal; aggregating said product identification data with at least location identity data to form a message;

- - communicating said message via a network to a server. According to a second aspect of the present invention, there is provided a system for acquiring and communicating product data, said system including: a payment terminal; - a receiver for receiving product identification data at said payment terminal; a processor for aggregating said product identification data with at least location identity data to form a message; a communicator for communicating said message via a network to a server.

According to a third aspect of the present invention, there is provided a payment terminal enabled to acquire product data, said payment terminal including: a receiver for receiving product identification data; - a processor for aggregating said product identification data with at least location identity data to form message;

- a communicator for communicating said message via a network to a remote server.

According to a fourth aspect of the present invention, there is provided a computer program for acquiring product data through a payment terminal adapted to implement the method defined above.

According to a further aspect of the present invention, there is provided a method for acquiring marketing information, said method including the steps of: at a merchant premises, receiving product identification data at a payment terminal, aggregating said product identification data with at least location identity data to form a message, and communicating said message via a network to a server; at said server, processing a plurality of said messages so as to provide marketing information.

According to another aspect, the present invention provides a payment terminal adapted to acquire product data and facilitate a loyalty scheme, said payment terminal including: - a receiver for receiving price information data; a receiver for receiving identity data of a customer; a processor for generating at least loyalty data messages including at least said identity data, said price information and location identity data; and communicating said data to a remote server; said processor being responsive to messages from said remote server to provide a loyalty benefit to a customer.

Many small retail businesses have credit card or EFTPOS payment terminals. Given the large number of retailers who have payment terminals, it has been recognised by the inventors that it would be advantageous if such a payment terminal could collect and process product data. Payment terminals have communication links to enable financial transactions to be completed, and the present invention utilises this capability to provide product data reporting. As a consequence, with little extra complexity and expense for the business operator, the payment terminal can provide this valuable capability.

The product data may conveniently be acquired by the payment terminal using a barcode reader, and in a preferred form, is acquired by extracting data from an existing bar code scanner associated with a cash register. In this form, the product data may be collected by the payment terminal at the same time the product data is acquired by the cash register, requiring only one step for both functions. In another preferred form, the product identification data is further aggregated with timing data prior to the data being communicated to the server. This allows further sales and marketing data to be collected and used by suppliers and manufacturers as they wish.

In another preferred form, the present invention further provides a mechanism for providing a loyalty program for a specific small business, or group of businesses, based on the product data acquired. BRIEF DESCRIPTION OF THE DRAWINGS

One implementation of the present invention will be described with reference to the accompanying figures, in which:

Figure 1 is a conceptual diagram of the components of the preferred implementation of the present invention and their interaction; Figure 2 is a conceptual diagram of the operating system used in the preferred implementation of the present invention;

Figure 3 is a modified cable and accompanying connectors for collecting the product data according to the preferred implementation of the present invention; Figure 4 is a sample merchant report according to the preferred implementation of the present invention;

Figure 5 is a sample report of customer purchases according to the preferred implementation of the present invention. DESCRIPTION OF PREFERRED EMBODIMENT The present invention will be described with reference to one particular implementation. It will be appreciated that persons skilled in the art could implement the present invention in many different ways, and variations of the invention may be produced without departing from its spirit or scope.

The present invention is not specific to any particular hardware or software implementation, and is at a conceptual level above specifics of implementation. The following is provided to assist in understanding the practical implementation of one embodiment of the invention.

Figure 1 illustrates the components of the preferred implementation of the present invention. At the retail store level, the system includes a payment terminal 1 , a modem 2, a barcode scanner 3, and optionally an electronic cash register 4.

The payment terminal 1 is operatively connected to a financial host 5, typically a financial institution, the financial host 5 being responsible for the financial transactions made through the payment terminal 1. The payment terminal 1 and the modem 2 (the modem 2 may form part of the payment terminal 1) are also connected to a data collection host 6, the data collection host 6 being responsible for the acquisition and reporting of the product identification data. The payment terminal 1 is not limited to any particular type of payment terminal. The payment terminal 1 in the present invention may be any type of electronic credit card or debit card terminal or system that allows the crediting or debiting of a customer's bank account electronically. This includes terminals or systems suitable for magnetic stripe, smartcard or Internet based payments. However, the payment terminal according to the present invention is not intended to encompass integrated cash register and payment terminals which are linked to in-store IT systems, for example of the type employed by large retail stores and supermarkets. The payment terminal 1 may also have other existing functionality, for example loyalty schemes or stored payment schemes. Payment terminals, as is well understood, are generally required to operate in accordance with the standards and protocols appropriate for a given jurisdiction, and for the particular payment scheme. The details of payment operations per se do not form part of the present invention and will not be described in detail, as they are well understood by those skilled in the art. Payment terminals are traditionally manufactured by a range of different companies. Each manufacturer generally has its own hardware and software configuration, different from terminals manufactured by other companies. Whilst it would be possible to implement the present invention using terminals supplied by a single manufacturer, it is strongly preferred that it be implemented on a platform independent basis. Therefore, it is preferred that the operating system and software used to implement the present invention may be utilised by all payment terminals, regardless of the terminal's manufacturer.

The preferred operating system for implementing the present invention on a payment terminal 1 is broadly represented in figure 2. This preferred operating system is an abstraction layer, configuration/application management system, and a multi-acquirer payment system. The operating system is designed to run on any type of secure payment terminal.

The operating system contains a set of functions/Application Programming Interface (API) which presents a generic interface to the payment application and the Java Virtual Machine (JVM). The hardware library functions are hidden within this interface. This makes the multi-merchant payment application and JVM easily portable from one platform to another and independent of the terminal hardware and libraries provided by the hardware supplier.

The operating system supports multi-acquirers. Each acquirer is a separate module. The payment module generates a generic payment message and expects a generic payment response. It is the responsibility of the acquirer module to package the payment messages into acquirer specific messages.

The presence of the JVM to support a number of Java-based value added applications is where the biggest strength of this system lies. Applications written in Java are even more portable to other terminal platforms since they can be compiled once for all terminals. The same software image can be used on any terminal.

Figure 2 broadly describes one operating system that may be used with the present invention. The component labelled "FPCon" 7 provides a non-terminal specific interact to manipulate the screen text an graphics displays including prompts and menus, differing fonts and languages, screen prompts, timers and clocks, and event handling including smart cards, magnetic cards and port data detections.

The component labelled "FPPrt" 8 provides a non-terminal specific interface to print buffered text and graphics, and to report printer errors.

The component labelled "FPComms" 9 provides non-terminal specific functions to passively and actively open/configure a port, which is used by Value

Added Applications 17. It also provides functions to connect and disconnect to a port, and send and receive to and from a port, update mobile signal strength, and report generic communication errors.

The component labelled "FPAS2805" 10 provides non-terminal specific functions to convert an AS2805 message stream to native elements in a format that can easily be manipulated, and to convert native elements to an AS2805 message stream.

The component labelled "FPCrypto" 11 provides non-terminal specific functions to the storage of injected keys, encryption functions, store and derive Key Encrypting Keys (KEKs) and session keys. The specific functions of this component depends upon on the security requirement of the various acquirers programmed into the terminal. The component labelled "FPMaint" and "FPUpgEng" 12 handles the TMS

Engine message and communication. It also manages the configuration downloads and preservation during upgrade, manages non-destructive software downloads and manages VAA upgrades.

The component labelled "FPUgd" 13 provides a non-terminal specific interface to perform last minute destructive upgrade of software.

The component labelled "FPEftpos" 14 provides a non-terminal specific interface to manage acquirer applets in the terminal, marshal data to various acquirer applets, provide access to data stored within the various acquirer applets, and analyses errors reported by the Acquirer applets and provide error descriptions to the terminal.

The component labelled "AQBank" 15 provides a non-terminal specific interface to provide specific message streams required by the acquirer for various financial messages, analyses message streams from the acquirer and populates the appropriate data required by the payment application, and maintains configuration data for the acquirer.

The component labelled "KLBank" 16 provides a non-terminal specific interface to inject bank keys and remove the applet after injection.

The component labelled "FPPay" 18 is a generic payment application that controls financial screen flows, reports, manual terminal configuration, activation of Value Added Applications 17, activation of profile maintenance 12, and activation of automatic settlement and logons.

The JVM 19 includes Java security which provides a native firewall to other Value Added Applications 17 and the payment application. The Value Added Applications 17 may include a wide range of applications depending upon the desire of the merchant, for example product data capture applications, loyalty scheme applications, or applications for the loading of telephone cards.One operating system that is available for use with the present invention is that commercially available through the applicant of the present invention, Fox Technology Pty Ltd. When a product is sold by a retailer, product identification data is communicated to the payment terminal 1. Product identification data in its broadest form represents any electronic means by which a particular product can be identified by a manufacturer, supplier, retailer or other party. Product identification data is preferably in the form of a specific code consisting of letters and numbers unique to a particular product. Most preferably, the product identification data is represented by a barcode on a product.

In the most preferred form, the barcode is communicated to the payment terminal 1 through the use of a barcode scanner 3. The barcode scanner 3 will capture the barcode data, which will then be decoded in the usual manner to reveal the electrical output corresponding to the barcode data. This electrical output, ultimately corresponding to the product identification data, is communicated to the payment terminal 1 for sending to the data collection server 6.

The electrical output may be processed at the payment terminal 1 so the product details are visible on the payment terminal 1 , (ie the payment terminal will display "600ml Coca-Cola bottle"). Alternatively, the product details may remain in coded format until the details are processed at the data collection host 6. In this way, the processing of the product data may be done behind the scenes, without the retailer's interaction or specific knowledge.

The barcode scanner 3 may communicate directly and solely with the payment terminal 1. Alternatively, the barcode scanner 3 may communicate solely with an electronic cash register 4. In the latter case, the electrical output from the barcode may then be communicated to the payment terminal 1 through a connection with the electronic cash register 4. Preferably, the barcode scanner 3 will communicate with both the electronic cash register 4 and the payment terminal 1 simultaneously by splitting the input signal. Signal splitting may be achieved by using a cable such as that shown in figure 3. The scanned data is captured by the barcode scanner 3 and communicated to two outputs, both the electronic cash register 4 and the payment terminal 1.

For items purchased that do not contain barcodes, for example petrol, it is preferable that product information data can be communicated to the payment terminal 1 through alternative means. This may be done by entering in a unique code for the specific item using the keypad on the payment terminal 1. Alternatively, the product information data may be initially entered into the electronic cash register, and a specific code may then be automatically or semi- automatically communicated from the electronic cash register to the payment terminal 1.

Each specific location, for example each convenience store, has its own location identity data. This may be any form of data that allows each location to be uniquely identified. Preferably, this data will be in the form of a string of numbers and/or letters.

The location identity data is stored in the payment terminal 1 for utilisation by the software. When product identification data is communicated to the payment terminal 1 ready to be communicated to the data collection server 6, the product identification data is first aggregated with the location identity data. This aggregated data is then processed by the payment terminal 1 to form a message ready to be communicated to the data collection server 6.

It is preferred that the aggregated data is further aggregated with timing data prior to being communicated to the data collection server 6. The timing data represents the date and time when the product identification data was communicated to the payment terminal 1 , thereby enabling the exact date and time of the product purchase to be determined and used in further information provided to a supplier (or similar), for example for marketing purposes.

When the data message has been aggregated and processed by the payment terminal 1 , it is ready to be communicated to the data collection server 6. A communication device, most preferably a modem 2, is used to communicate the data from the payment terminal 1 to a data collection server 6. The preferred implementation uses a broadband connection to enable always-on operation of product capture, so as to provide real time product purchase data to be communicated to the data collection server 6. This prevents the need to store large amounts of data on the payment terminal 1. This also allows the data collection server 6 to process the data dynamically and provide reports at any moment in time. However, if desired, the present implementation could be configured on a store and forward basis with periodic connection to the data collection server 6. Adequate memory would need to be present in the payment terminal. A disadvantage of this approach is the loss of near real-time data at the server 6. Figure 4 is a screen shot of a sample report of the communicated data after it arrives at the data collection server 6. The information outlined in the rectangle 19 is the aggregated product identification data, location identity data and timing data. This information shows (1) what product or products were purchased; (2) the store or location the products were purchased from; and (3) the date and time the products were purchased.

Once the aggregated data has arrived at the data collection server 6, it is then processed into a readable form. The data collection host 6 will have stored a database of product identification data and location identity data to process the data received from the payment terminal 1 into a report suitable for use by a supplier. The report may then be sent to a supplier or the like 20.

Preferably, the reports will include details of products sold at certain locations during certain time periods. It may consist of a list of all products sold per location, or a specific product sold per location, or specific products sold during a certain period of time or on a certain day. The exact detail and format of the reports will be determined by the needs of the suppliers.

The reports can be communicated to the suppliers (or similar) at any point in time, depending upon the specific needs of the supplier. For example, a report may be produced and communicated to the supplier each hour, or alternatively at the end of each day, week or month. The supplier is able to then use the information provided in the reports for marketing purposes. For example, the supplier can determine those areas where a particular product is achieving the least sales, and commit specific marketing resources to that area to build up the product sales. This information is very difficult to readily achieve for small businesses under existing arrangements. The supplier may also use this information for automatic stock reordering for small businesses. Being able to automatically manage stock levels and ordering may reduce the need for human resources to perform such a task, and thereby increase efficiency and profits.

A preferred feature of the method and system is to include a customer loyalty system operated through the payment terminal 1 and managed by the data collection host 6. The customer loyalty system will allow a specific merchant to reward customers for continued purchases and will be conducted through the payment terminal 1.

Merchants will be provided with customer reward cards from the data collection host 6. The merchants will obtain customer information, such as the customer's name and address, which will be provided to the data collection host 6 for entering into a database connected to the specific merchant. The customer information may be utilised by either or both the merchant and the suppliers for marketing purposes.

Each time a customer makes a purchase from the specific merchant's store, the customer hands their customer reward card to the merchant. The merchant can enter the details of the customer, preferably by swiping the customer reward card, into the payment terminal 1. This is entirely conventional, as for magnetic stripe credit cards and the like. The payment terminal 1 will have software enabled on the terminal to allow this function to be performed. The software enabled on the payment terminal 1 is preferably a Java application. The specific amount of the purchase made by the customer may then be entered into the payment terminal 1 , the amount of which will then be added onto the customer reward card. The purchase amount may be typed in manually to the payment terminal 1 using the keypad, or alternatively may automatically be transferred to the payment terminal 1 through an electronic cash register 4. Alternatively, the purchase amount may be entered automatically when the barcodes on the products are scanned into the payment terminal 1 by the signal splitting method as described above.

The specific amount of the purchase is added onto the customer reward card. Each time the customer makes a purchase at the particular merchant, the purchase amount is added onto the customer reward card. When the customer reaches a certain amount on their customer reward card, for example $100, the customer may be provided with a reward, for example a $10 voucher. The loyalty scheme preferably allows the merchant to adjust the value of the redemption as he or she sees fit. It is preferably the loyalty scheme is entirely configurable for individual merchants. While the make up of the specific prize is not defined in the present invention, it is preferred the customer receives a voucher that may be redeemed in that particular merchant's shop at a later time. The voucher may be printed off the payment terminal 1 , with the data collection host 6 being responsible for the management of the system. It is preferred that each merchant has a set purchase amount threshold, such that when a customer reaches the specific threshold, the system will automatically generate a redemption voucher to the value of the merchant-set reward amount. The data collection host 6 will automatically calculate and tally a customer's purchase amount, and a customer's reward amount. It is preferred the purchase and reward amounts may be extracted from the data collection host 6 for use by a merchant.

In another form, a real time loyalty reward may be awarded based on a specific product identified by the bar code, being part of a targeted loyalty program. For example, whenever a customer purchases a "600ml Coca-Cola bottle", from any participating retailer, a reward, for example a free chocolate bar, may appear on the terminal. Such a loyalty reward could be provided or managed by the product supplier rather than the retailer, providing an efficient way of managing the targeted loyalty program without the need for the customer or retailer to store vouchers, labels or other such monitoring and reward devices.

The data collection host 6 may provide the merchant, supplier, or any other person authorised to be given the customer's details, a print out of that customer's purchasing activity. An example report that may be provided to one of these parties is shown in figure 5. These parties can then use this collection of information for marketing, sales or advertising purposes.

The core data for the loyalty scheme is stored on the data collection host 6. Basic data is stored on the payment terminal 1 and this stored data may then be settled up either daily or immediately, depending upon the opportunity for the terminal to communicate with the data collection host 6. The loyalty transactions are stored on the data collection host 6.

The embodiment discussed has focussed upon an implementation using magnetic strip cards for loyalty identification, barcodes for product identification, and broadband wired Internet connections. However, the present invention may be implemented with a wide range of technologies. For example, smartcards or other data tokens could be used as data carriers. The payment terminal may be adapted to accept smart cards, stored value cards or other loyalty reward cards in addition to magnetic stripe cards. Product identification could be by entry of a manual identifier, or detection of an RFID or similar device. Any suitable communication system, for example wireless broadband, GPRS or satellite could be substituted for cable or ADSL broadband.

Claims

CLAIMS:

1. A method for acquiring and communicating product data, said method including the steps of: receiving product identification data at a payment terminal; aggregating said product identification data with at least location identity data to form a message; communicating said message via a network to a server.

2. A method according to claim 1 , said method including the further step of aggregating said product identification data and said location identity data with timing data.

3. A method according to any one of the preceding claims wherein the step of communicating said message via a network to a server includes communicating said message to said server at a time independent of any financial transaction being communicated via said payment terminal to a financial host.

4. A method according to any one of the preceding claims wherein the step of receiving product identification data at a payment terminal includes inputting said data directly at said payment terminal.

5. A method according to any one of the preceding claims, wherein the step of receiving product identification data at a payment terminal includes receiving data in the form of a barcode on a product.

6. A method according to claim 5, wherein the step of receiving product identification data at a payment terminal includes scanning said barcode using a barcode scanner.

7. A method according to claim 4 wherein the step of receiving product identification data at a payment terminal includes inputting said data via a keypad.

8. A system for acquiring and communicating product data, said system including: a payment terminal; a receiver for receiving product identification data at said payment terminal; a processor for aggregating said product identification data with at least location identity data to form a message; a communicator for communicating said message via a network to a server.

9. A system according to claim 8, said system further including a processor for aggregating said product identification data and said location identity data with timing data.

10. A system according to any one of claims 8 or 9, wherein said communicator is capable of communicating said message to said server at a time independent of any financial transaction being communicated via said payment terminal to a financial host.

11. A system according to any one of claims 8 to 10, wherein said receiver inputs said product identification data directly at said payment terminal.

12. A system according to any one of claims 8 to 11 , wherein said receiver receives said product identification data in the form of a barcode on a product.

13. A system according to claim 12 wherein said receiver receives said product identification data by scanning said barcode using barcode scanner.

14. A system according to claim 11 wherein said receiver inputs said data via a keypad.

15. A payment terminal enabled to acquire product data, said payment terminal including: a receiver for receiving product identification data; a processor for aggregating said product identification data with at least location identity data to form message; a communicator for communicating said message via a network to a remote server.

16. A payment terminal according to claim 15, said payment terminal further including a processor for aggregating said product identification data and said location identity data with timing data.

17. A payment terminal according to any one of claims 15 or 16, wherein said communicator is capable of communicating said message to said server at a time independent of any financial transaction being communicated via said payment terminal to a financial host.

18. A payment terminal according to any one of claims 15 to 17, wherein said receiver inputs said product identification data directly at said payment terminal.

19. A payment terminal according to any one of claims 15 to 18, wherein said receiver receives said product identification data in the form of a barcode on a product.

20. A payment terminal according to claim 19 wherein said receiver includes a barcode scanner for scanning said barcode to receive said product .

21. A system according to claim 18 wherein said receiver includes a keypad for inputting said product identification data.

22. A payment terminal according to any one of claims 15 to 21 , wherein said payment terminal further includes means for enabling a loyalty scheme.

23. A payment terminal adapted to acquire product data and facilitate a loyalty scheme, said payment terminal including: a receiver for receiving price information data; a receiver for receiving identity data of a customer; a processor for generating at least loyalty data messages including at least said identity data, said price information and location identity data; and communicating said data to a remote server; said processor being responsive to messages from said remote server to provide a loyalty benefit to a customer.

24. A payment terminal according to claim 23 wherein said price information data is collected directly on said payment terminal.

25. A payment terminal according to claim 23 wherein said price information data is collected on said payment terminal through data inputted on a sales terminal.

26. A payment terminal according to any one of claims 23 to 25 further including means for enabling the selective redemption of loyalty points.

27. A payment terminal according to claim 23 wherein the redemption of loyalty points is at a customer's choosing.

28. A computer program for acquiring product data through a payment terminal, said program adapted to implement the method of any one of claims 1 to 7.

29. A method for acquiring marketing information, said method including the steps of: at a merchant premises, receiving product identification data at a payment terminal, aggregating said product identification data with at least location identity data to form a message, and communicating said message via network to a server; at said server, processing a plurality of said messages so as to provide marketing information.

30. A method according to claim 29, said method including the further step of aggregating said product identification data and said location identity data with timing data.

31. A method according to any one of claims 29 or 30 wherein the step of communicating said message via a network to a server includes communicating said message to said server at a time independent of any financial transaction being communicated via said payment terminal to a financial host.

32. A method according to any one of claims 29 to 31 wherein the step of receiving product identification data at a payment terminal includes inputting said data directly at said payment terminal.

33. A method according to any one of claims 29 to 32, wherein the step of receiving product identification data at a payment terminal includes receiving data in the form of a barcode on a product.

34. A method according to claim 33, wherein the step of receiving product identification data at a payment terminal includes scanning said barcode using a barcode scanner.

35. A method according to claim 32 wherein the step of receiving product identification data at a payment terminal includes inputting said data via a keypad.