WO2015008084A1

WO2015008084A1 - Discount offer system

Info

Publication number: WO2015008084A1
Application number: PCT/GB2014/052200
Authority: WO
Inventors: Oliver GRATRY; David Smith; Loren Barton
Original assignee: Barclays Bank Plc
Priority date: 2013-07-19
Filing date: 2014-07-18
Publication date: 2015-01-22

Abstract

The present disclosure provides a method, system and server for providing an offer to one or more consumers. The method comprises the steps of obtaining a payment account with an associated payment account reference; associating the obtained payment account with an offer identifier; and issuing the offer comprising the offer identifier and the payment account reference to the consumer for redemption of the offer from a merchant.

Description

DISCOUNT OFFER SYSTEM

Field of the Invention The present invention relates to an offer system.

Background of the Invention

Free offer and coupon issuing systems provide consumers with access to product offers, for example buy one get one free offers, or a percentage discount on the cost of a product without the need to make a purchase prior to

redemption of the offer. These offer systems provide merchants with a reliable channel for promoting and selling their goods and services, reaching new customers, and retaining existing customers. There is a desire for a mechanism for securely issuing offers to consumers, avoiding fraudulent offers, and measuring performance of marketing campaigns that include offer redemption. Such aims may be achieved by distributing dedicated offer redemption systems to merchants but this increases costs and reduces

convenience. Such dedicated or specialist offer redemption systems may require dedicated hardware or software and at least internet access to achieve secure and reliable

validation.

Furthermore, information relating to the redemption and use of the offers by consumers is very useful for the offer issuer and other entities. Therefore, there is a need to obtain more information as to how and when consumers redeem their offers. However, collection of this information can be difficult, especially if it relies on feedback provided by merchants who may be unwilling to provide such feedback due to technical overheads and other resource requirements. Without such merchant feedback then this valuable

information may be incomplete or lost. Large retailers may track their own promotion codes when redeemed using

specialised software, but this only addresses when and where the offers are used, not who is using them.

U2011/0302012A1 describes a system and method for redeeming coupons whereby a consumer signs up to an on-line coupon account provider and registers their credit or debit card with their coupon account. On-line coupons can then be maintained in their coupon account and a merchant can transmit the consumer's credit or debit card number to the coupon account provider and request that any valid coupons are returned to the merchant. Any coupons that are returned and then processed by the merchant are returned to the coupon account provider so that they can be marked in the coupon account as having been redeemed. However, this system requires the consumer to be signed up in advance for an account from a particular coupon provider account and maintain their coupons within that account. Furthermore, the merchant must also be signed up for access to coupons from the same coupon account provider and return any redeemed coupons to the coupon account provider so that they cannot be used again. If the merchant is not registered for use of the coupon account provider's service, or if the consumer has not made the effort properly to manage their account and maintain all of their coupons within the account, the system will not work. Furthermore, it requires the merchant to request and receive information through a dedicated system, which may require additional staff training, and undertake additional steps to return information relating to the redemption of the coupon.

Therefore, there is required a system and method that overcomes these problems.

Summary of the Invention

Against this background and in accordance with a first aspect there is disclosed a method of providing an offer to at least one consumer, the method comprising the steps of: obtaining a payment account with an associated payment account reference; associating the obtained payment account with the offer; and providing the offer to the consumer by issuing an offer identifier and the payment account

reference to the consumer for redemption of the offer from a merchant .

The payment account is not used to pay the merchant for a product (s) (goods or services) supplied to the one or more consumers. Payment for the product (s) is made separately from the payment account, directly between the consumer and merchant using any suitable means. Each of these steps and the steps described below may be implemented on one or more electronic/computer systems. For example, the obtaining and implementing the payment account may be implemented on a first electronic system and the step of providing may be implemented on a second

electronic system. Alternatively, all of the steps may be implemented on a single electronic system. Association of the payment account with the offer may be a step of preparing for issuance of the offer identifier and the payment account reference to the consumer, for example preparing a document or email comprising the offer identifier and the payment account reference. The offer identifier may be a textual description of the offer, or any other means by which the merchant will be able to understand and redeem the offer, for example a barcode or some other code that is comprehensible by any means at the disposal of the merchant.

The offer, unlike for example a gift card or pre-paid voucher, has no monetary value in itself. Rather, it is redeemable to provide a particular discount for specified purchase conditions, for example a percentage discount on the purchase price of a particular product (s), or a free sample of a product, or a buy two products and get a third for free. Preferably, the step of associating the obtained payment account with the offer identifier comprises storing the payment account reference with a record of the offer. The record of the offer may be the same as the offer

identifier, or may be any other means by which the offer may be identified at a later date. This enables a record to be kept of each offer issued, which may be useful for market analysis .

Furthermore, at least one of a time of obtaining the payment account, a date of obtaining the payment account, a time of issuing the offer and payment account reference to the consumer, a date of issuing the offer and payment account reference to the consumer and an identifier of the consumer, an expiry date of the offer and an expiry date of the payment account may also be stored with the payment account reference and identifier of the offer. Any other information relevant to the issuance of the offer to the consumer may also be stored. In this way a record may be kept of all offers issued to consumers, which may be useful for marketing purposes, for example to track the take-up of offers by consumers etc. Preferably, the method may further comprise receiving a notification of the offer being used. This may be an immediate notification that a transaction has been

authorised, or a notification at some time after a

transaction has been authorised (for example in a periodic statement of authorised transactions), or when a payment from the payment account has been made to the merchant.

Furthermore, redemption of the offer may also be recorded when the notification is received. In this way, the use of an offer may be tracked without requiring the merchant to provide additional feedback external messages. This may provide useful data for marketing, for example the

proportion of issued offers that are redeemed by consumer, indicating the effectiveness of an offer campaign. It may also enable performance based compensation to be paid to the offer provider.

In addition to recording redemption of the offer, at least one of a time of redemption of the offer, a date of redemption of the offer, location of redemption of the offer and an identifier of the merchant may also be recorded to provide more detailed redemption information that may be useful in tracking the use of offers. This data may be obtained at the same time as the offer being redeemed. Any other relevant information relating to the redemption of offers may also be recorded.

The offer may be made a limited use offer by

configuring the payment account to allow only a limited number of uses. The number of uses limit may be set at any level, for example the payment account may be configured for only a single use, or for multiple uses. In this way, the offer may be provided to only a single consumer for single or multiple use by the consumer, or may be provided to two or more consumers, for example by transmitting the offers directly to a number of consumers or through publication of the offer via a newspaper or such like, for a single use between all of the consumers, or multiple uses between them all .

The disclosed method may further comprise a step of: the consumer redeeming the offer from the merchant by: the consumer presenting the payment account reference to the merchant; and the merchant honouring the offer.

Honouring the offer may take place before or after the merchant has requested a transfer of funds from the payment account. For example, where the offer is not a limited use offer, the merchant may request a transfer of funds from the payment account after the offer has been redeemed. He may do this for offer usage tracking purposes. If the offer is a limited use offer, the merchant may request a transfer of funds from the payment account first and then redeem the offer following receipt of authorisation of a payment from the payment account . In this way, the merchant may determine whether or not the offer is still valid, for example that it has not already been used (where the offer is a single use offer) and has not expired, before honouring the offer.

The payment account may be made limited use, for example by setting a nominal spend limit for the account, wherein once the nominal spend limit has been reached by virtue of past transactions, no further transactions may be authorised. The nominal spend limit is independent from and unrelated to the offer that is provided to the consumer and may be set at any monetary value that can be processed by financial transaction networks. The nominal spend limit enables the offer to be limited use, for example limited to a single use, such that after the nominal spend limit has been reached, no further payments can be authorised.

The merchant may request the payment from the payment account by entering into a card processing terminal the payment account reference and a requested transfer amount that is less than or equal to the nominal spend limit of the payment account, the merchant honouring the offer following a receipt by the card processing terminal of authorisation of the requested transfer, and the merchant not honouring the offer following a receipt by the card processing

terminal of an indication that the requested transfer is declined .

The requested transfer amount may be an amount

equalling a transaction amount instruction included on the offer issued to the consumer. The nominal spend limit may be set to be a positive integer multiple of the transaction amount instruction, for example 1 or more

offer may be set to a desired usage limit

Consequently, the merchant may perform a transaction between the payment account and the merchant account using standard payment means in order to verify the validity of the offer and/or track usage of the offer, wherein a

separate transaction takes place between the consumer and the merchant for the purchase of a product (s) .

Therefore, the merchant can leverage existing

electronic payment systems, such as a point of sale terminal (physical/digital) and card payment system, to determine if they should honour the offer or not and/or to enable

tracking of the use of the offer. This allows existing systems and infrastructure at the merchant, to be used to validate and process offers without requiring new equipment or services. For example, separate offer systems and additional training are not required, thereby saving time and money for the merchant. Furthermore, because the merchant and consumer do not need to have signed up to an offer system, it is simpler for consumers to make use of offers that have been issued to them. Furthermore, rather than using a point of sales

terminal, the merchant may use any payment network access point, for example a fixed or mobile electronic device, such as a smart phone, that has access to an electronic payment network, for example via a portal.

Furthermore, the merchant and consumer are not tied into a particular payment method for purchasing the

product (s) related to the offer. For example, payment may be made using the consumer/merchant ' s choice of cash, a cheque, a debit card or a credit card and the offer still checked for validity by the merchant using existing

electronic payment systems.

For payment accounts with a nominal spend limit, when the requested transfer is authorised, the requested transfer may take place such that the remaining available spend limit for the payment account is reduced by the transaction amount and when the spend limit is reached, no further

authorisation for a transfer of funds from the payment account may be issued. In this way, the offer may be restricted to a limited number of uses. The payment account may be a virtual payment card account and the payment account reference is a virtual payment card number. This may include credit, debit, prepaid, charge funding cards / payments. This type of account typically has a maximum lifespan and can be set to expire automatically. The nominal spend limit may be a maximum credit that is allowable on the virtual payment card

account, or a prepaid amount.

Optionally, the step of obtaining the payment account may further comprise either: generating a new account or accounts; retrieving an account or accounts from an account store. Therefore, payment accounts may be generated as and when they are needed or taken from a store of available accounts to be used for this purpose.

Preferably, the step of obtaining the payment account may further comprise issuing an application programming interface, API request to an account generator. This improves and simplifies the interaction and interface of systems potentially operated by different entities.

Optionally, the offer and payment account may be associated with the merchant and the payment account is configured to approve a transfer of funds from the payment account requested by the merchant associated with the payment account. Therefore, only a request for a transfer from the associated merchant may be approved, whereas a request for a transfer from any other merchant may be declined. In this way, the offer may be restricted for use only with a particular merchant.

In another aspect, there is also disclosed a server for providing an offer to at least one consumer, the server being configured to: obtain a payment account with an associated payment account reference; associate the obtained payment account with the offer; and issue an offer

identifier and payment account reference to the consumer for redemption of the offer from a merchant.

Association of the payment account with the offer may be the preparation for issuance of the offer identifier and payment account reference to the consumer, for example preparing an offer document /email comprising the offer identifier and payment account reference for issuance to the consumer .

Preferably, the server may be configured to associate the obtained payment account with the offer by further storing the payment account reference with a record of the offer. The record of the offer may be the offer identifier, or any other means of identification. In this way, a record of issued offers may be maintained for analysis purposes.

Preferably, the server may receive a notification of use of the offer and record, for example on a database, redemption of the offer when the notification is received. The database may be part of the server, co-located or located at a different location to the server. In this way, use of the offer may be tracked, such that marketing

analysis may be performed, for example to determine the effectiveness of an offer campaign.

Optionally, the server may also record at least one of a time of redemption of the offer, a place of redemption of the offer, a date of redemption of the offer and an

identifier of the merchant. Other data relating to

redemption of the offer may also or alternatively be stored.

Optionally, the server may also be configured to record at least one of a time of obtaining the payment account, a date of obtaining the payment account, a time of issuing the offer and payment account reference to the consumer, a date of issuing the offer and payment account reference to the consumer, an identifier of the consumer, an expiry date of the offer and an expiry date of the payment account.

In a further aspect of the present disclosure, there is also provided a system for providing an offer to at least one consumer, the system comprising logic configured to: obtain a payment account with an associated payment account reference; associate the obtained payment account with the offer; and issue the offer identifier and payment account reference to the consumer for redemption of the offer from a merchant .

The logic may be configured to operate on one or more electronic/computer devices.

Preferably, the system may further comprise a data store, or example a database, wherein the logic is further configured to: store the payment account reference with a record of the offer on the data store. The record of the offer may be the offer identifier, with the storage of the offer identifier with the payment account reference further associating the obtained payment account with the offer identifier .

Preferably, the logic is further configured to: receive a notification of a use of the offer, for example a

notification of authorisation of payment or of a payment being made to from the payment account, and record

redemption of the offer on the data store when the

notification is received. Therefore, use of the offers may be tracked, for example for marketing purposes.

The logic may further be configured to record on the data store at least one of a time of redemption by the consumer, a location of redemption, a date of redemption by the consumer and an identifier of the merchant. Any other relevant redemption data may also be stored. The logic may be further configured to record on the data store at least one of a time of obtaining the payment account, a date of obtaining the payment account, a time of issuing the offer and payment account reference to the consumer, a date of issuing the offer and payment account reference to the consumer, an identifier of the consumer, an expiry date of the offer and an expiry date of the payment account .

Preferably, the system may further comprise an

interface with a card payment system, wherein the interface with the card payment system is configured such that: the merchant may request a payment from the payment account using the interface with the card payment system.

Therefore, existing infrastructure may be used, thereby avoiding the need for new infrastructure to be put in place.

The system may further comprise a payment account generator or virtual account issuer configured to generate the payment account .

The methods described above may be implemented as a computer program comprising program instructions to operate a computer or computers. The computer program may be stored on a computer-readable medium.

It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Combinations of features between aspects are also disclosed, even if not explicitly noted. Brief description of the Figures

The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram of a system and method for issuing and redeeming offers;

FIG. 2 shows a diagram representing the steps for issuing an offer;

FIG. 3 shows a schematic diagram of an issued offer; and

FIG. 4 shows the offer of Figure 3 displayed on a mobile device.

It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale.

Detailed description of the preferred embodiments An example implementation of the method and system involves several different entities. Figure 1 illustrates schematically the interactions between these separate entities and the steps required to implement an offer system 1 and method.

As shown in Figure 1, the entities comprise a consumer 10, an offer provider 20, an offer tracker 30, a payment card processing network 40, a merchant 50 and a payment processor 60. The payment card processing network 40 comprises a payment card processor 42, a virtual account issuer 44, a virtual card bank 46 and an offer platform 48, through which the payment card processing network 40 may pass data to the offer tracker 30. The merchant 50 comprises a point of sale (POS) 52, which is in communication with the payment network 60, and a marketing node 54, which may communicate with the offer provider 20 for merchant marketing purposes. The payment processor 60 may comprise any standard payment elements, for example an acquirer 62 and a payment network 64.

In this example, the consumer 10 is provided with an offer that can be redeemed with the purchase of a product (s) from the merchant 50 ('product' as used throughout this application is intended to encompass both goods and

services) . The offer itself does not have any monetary value, for example it is not a voucher that is worth a sum of money, such as a $10 gift card or a pre-paid voucher where a portion of the value of the product has been paid- for in advance. Instead, it is a discount that may be obtained in respect of a purchase of a particular product (s) from the merchant 50, for example a buy one get one free offer; a 10% discount on the price of a product; or a free sample of a product, or it may be a discount that may be obtained in respect of any purchases from a particular merchant 50, for example a 20% discount in the total spend of the consumer 10 with the merchant 50. The method steps and interactions that occur between each of these entities are also shown in Figures 1 and 2. The method steps in Figure 1 are labelled A-F and the method steps in Figure 2 are labelled S210-S230. The method starts with the consumer 10 requesting a particular offer from the offer provider 20 at step A. This may follow from the consumer 10 browsing and choosing one of a plurality of available offers. Such an offer browsing system is not described in detail here. The request for a particular offer by the consumer 10 initiates a number of steps. These steps create a

redeemable offer that may be used only once and a mechanism by which the use and effectiveness of the offer may be tracked .

After the consumer 10 has requested an offer, the offer provider 20 obtains an offer number from the payment card processing network 40 in Step S210. Obtaining the offer number takes place first by the offer provider 20

instructing the offer tracker 30 to retrieve an offer number from the payment card processing network 40, which the offer tracker 30 does in step B. The virtual account issuer 44 obtains the offer number from the payment card processor 42. In this example, the offer number is a virtual credit or payment card number associated with a virtual credit or payment card account with a nominal spend limit, for example $1. The spend limit, which may be a credit limit or a pre- paid amount, is unrelated to and independent from the offer, and is used to limit the number of times the offer may be used and for checking the validity of the offer, as

explained in more detail later. The offer number is returned to the offer tracker 30 via the offer platform. In Step S220, the offer is

associated with the offer number by preparing for issuance to the consumer of the offer number with an identifier of the offer. For example, an offer document or email that includes both the offer number and an identifier of the offer itself, for example a written description of 20% off the price of a particular product, may be prepared, thereby associating the offer with the offer number. Association in Step S220 may also comprise offer tracker 30 storing the offer number with a record of the offer itself, for example the identifier of the offer described above or an identification number that this unique to the type of offer, such that the offer may be identified from the records at a later date. Further information that may be stored with the offer number and indication of the type of offer includes, but is not limited to, at least one of the time of obtaining the offer number, the date of obtaining the offer number, an expiry date of the offer and consumer 10 information, such as geographic location, the channel through which they requested the offer (for example, the website they used to request the offer), the gender of the consumer 10, the age of the consumer 10, etc.

The offer is issued to the consumer 10 in Step S230, by transmitting the offer number and an identifier of the offer, for example 20% off the price of a particular

product, to the consumer. The issued offer may also include a transaction amount instruction that can be used by the merchant 50 when the offer is presented to them (explained below) to determine the transaction amount they should request from the virtual card account when the consumer 10 tries to redeem the offer. The issued offer may also include other offer information, for example, a start date for the offer (typically the day that the offer is issued), an expiry date for the offer (for example 12 months from the date of issuance) and an identifier of the merchant 50 (for example the name of the merchant) if the offer is linked to a particular merchant. The offer may be issued to the consumer 10 in any suitable electronic or physical format. After the offer is issued to the consumer 10, the offer tracker 30 may also record at least one of the time and date of issuance to the offer to the consumer 10.

An application programming interface (API) may exist between the offer tracker 30 and the payment card processing network 40 to facilitate easier communication. This API may be invoked to retrieve a payment account from the payment card processing network 40. In this example, the payment account is a virtual card account. The virtual card account issued by the virtual account issuer 44 on behalf of a virtual card bank 46. Therefore, the virtual account issuer 44 notifies the offer system bank 46 whenever it issues a virtual card account and this notification includes all the details of the virtual card account. The virtual card account may have a fixed lifespan, for example expiring at the same time that the offer expires, and a nominal spend limit, for example $1. At any time after the offer is issued to the consumer

10 (step C) , the consumer 10 may redeem the offer with the merchant 50 by presenting the merchant 50 with the offer in step D. As mentioned previously, the issued offer comprises a description of the offer and the offer number identifying the virtual card account.

In a store environment, redemption of the offer may be achieved by the merchant 50 requesting a transfer from the virtual card payment account to a merchant account using the point of sale (POS) device 52 (e.g. a credit or debit card terminal) in step E. However, in this case, no physical card is presented but the offer number 9 i.e. the virtual card number) is entered. Where the issued offer includes a transaction amount instruction, the merchant 50 will request a transfer equalling the instructed transaction amount from the virtual card payment account to the merchant account. The requested transaction amount is processed in the same way as transactions for standard credit and debit cards through the payment network 60 and the payment card

processing system 40.

The transaction amount instruction may be any amount that can be processed by the payment network 60, for example $0.01 or $0.50 or $1, and may be set at a level to achieve a desired use limit for the offer. For example, the spend limit of the virtual card payment account may be $1 and the transaction amount instruction may also be $1, so that the offer is for single use only and after a $1 transaction has taken place, the virtual card account will cease to be operational. Alternatively, the transaction amount

instruction may be some amount less than the spend limit, for example the spend limit may be $10 and the transaction amount instruction may be $0.01, such that the offer is limited to 1000 uses.

If the offer issued to the consumer 10 has not yet exceeded its maximum number of allowable uses, the

associated virtual card account spend limit will not have been reached. In this case, provided the offer is still valid (i.e. the expiry date of the virtual card account has not passed) , the requested transfer from the virtual card account requested in step E will result in an authorisation of the transfer being returned to the POS 52. The requested transfer from the virtual card payment account to the merchant account may then take place either immediately or at a later date. The transfer from the virtual card payment account will be recorded, either immediately or soon after, by the payment network 40 so that the remaining spend limit is accordingly reduced by the use of the offer. Upon receipt at the POS 52 of an authorisation of the transfer, the merchant 50 will know that the offer issued to the consumer 10 is still valid and has not yet been used and will then honour the offer. If the offer issued to the consumer 100 has already been used a number of times equalling the maximum allowable number of uses, the spend limit of the associated virtual card payment account will have been reached and the POS 52 will receive an indication that the requested transfer has been declined. Furthermore, if a virtual card account expiry date has passed (regardless of whether the spend limit has been reached or not), the POS 52 will receive an indication that the requested transfer has been declined. The merchant 50 will then know that the offer issued to the consumer 10 has already been used the maximum allowable number of times and/or has expired and that they should not honour the offer.

Therefore, it can be determined by the merchant using the standard POS 52 whether or not the offer issued to the consumer 10 has already been used the maximum allowable number of times and is still valid. Consequently, the offer can be made to be a limited use offer preventing a wide distribution and exploitation of the offer via, for example, social media, and preventing fraudulent multiple uses of the same issued offer, without requiring the consumer 10 and/or merchant 50 to sign up for a dedicated offer providing system. The offer system may thus be implemented widely without the additional cost or inconvenience of a separate offer system.

The consumer 10 may then pay for the product (s), after the offer has been applied by the merchant 50, using any payment means supported by the merchant 50, or example with cash, a cheque, a credit card or a debit card. In this way, a two stage transaction process takes place - the first being the offer authorisation transaction where the merchant requests a transfer from the virtual card payment account in order to authorise use of the offer, and the second being the purchase of the product (s) by the consumer using

whatever payment means they desire. After a transaction from the virtual card payment account to the merchant account has taken place, the

merchant 50 may receive an invoice from the virtual card bank 46 and/or the payment network 64 (depending on the financial arrangements of the system) for at least part of the $1 transfer. For example, they may receive an invoice for the $1 transfer plus a further charge, for example

$0.03, for use of the payment network 60 and/or payment card processing network 40. The charge may form part of a regular statement that the merchant 50 receives, for example each month, or may be issued for each individual

transaction .

When a transaction has been authorised, the offer tracker 30 is also notified via the offer platform 48 that a transaction has taken place. The notification will comprise the virtual card number so that the offer tracker 30 can record that the offer has been used by the consumer 10. The notification may also comprise a time of authorisation of the transfer, a date of authorisation of the transfer and an indication of the merchant 50, for example the merchant name and/or location. In this way, the offer tracker 30 can record when and where the offer was used by the consumer 10. A notification may be issued to the offer tracker 30 after each authorised transfer, or the offer tracker 30 may periodically be issued with as collection of notifications for all authorised transfers that have taken place during a period of time, for example a collection of notifications may be issued at the end of each day.

Therefore, redemption of the offer can be tracked by the offer tracker 30 and the marketing node 54 may in step F obtain via the offer provider 20 data relating to the offer. For example, they may determine the response rate to a marketing campaign, average time for consumers to use issued offers, the most popular locations for using issued offers etc. The tracking data may also be used by the offer provider 20 to monitor the effectiveness of the service they provide and also provided to any other relevant third parties. It may also be used for performance based

compensation to the charged by the offer provider 20 to the merchant 50 in payment for the offer service that they provide .

Figure 3 shows an example offer 300 that may be issued to the consumer 10. In this example, the offer may be printed out to be presented to the merchant 50. The offer comprises a description of the offer (40% off the purchase price of product X) and details of the associated virtual card account 310, for example a 16 digit virtual card number and the start and end dates of the virtual card account. The offer may also comprise the expiry date of the offer (which may correspond with the expiry date of the virtual card account) and instructions to the merchant for how to use the virtual card number to determine whether or not to honour the offer, including, for example, the transaction amount instruction (less than or equal to the nominal spend limit of the virtual card payment account) that should be requested .

Figure 4 shows a further offer but in this example the offer is displayed on a smart phone 400. The same

information is included in this electronic offer. A benefit of including the offer on a smart phone (or other mobile device) is that the offer does not need to be printed.

Furthermore, the offer provider 20 may be accessed through a mobile application also residing on the smart phone 300. Therefore, the offer may be requested by the consumer 10 and/or issued to the consumer 10 whilst the consumer 10 is away from a fixed computer or even within the merchant premises .

The system may be implemented using a suitable computer system .

Many combinations, modifications, or alterations to the features of the above disclosure will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

For example, the payment accounts may be a virtual debit card or pre-paid account, or a virtual credit card, and the spend limit may accordingly be a pre-paid amount or a credit limit. Rather than receiving an invoice for each virtual payment card account transaction that takes place, it may be arranged that the merchant provides funds in advance. For example, they may instruct the offer provider 20 to issue 100 offers to consumers and transfer payment for the generation of 100 virtual card accounts to the offer provider 20. For each requested offer from the consumer 10, the offer provider 20 may request a virtual card account as described above and pay for the virtual card payment account (for example, $1 for the spend limit plus a service fee of $0.03 for use of the payment card processing network 40) . For any virtual card accounts that expire before they are used, the merchant 50 may be refunded at least part of their payment .

Rather than using a $1 nominal spend limit, a spend limit of any amount, for example the prevailing minimum spend limit allowed at the time, and any currency supported by the payment processing platforms may be implemented. For example, the spend limit may be $0.01, or £0.01, or 10 EUR, or $100. If the requested transaction amount matches the spend limit, the offer associated with the virtual card account will be for a single use offer. If the requested transaction amount is less than the spend limit, the same offer may be used a number of times. For example, a $100 spend limit may be implemented, but a transaction amount instruction on the issued offer may indicate that a

transaction request of $1 should be used. In that case, a single virtual card account may be associated with an offer that is issued to a single customer for multiple uses, or to plurality of consumers, or publically released for anyone to use, wherein the offer is limited to only 100 uses. Whilst in the above described method, the offer is a limited use offer and the merchant 50 first checks that the offer is still valid by requesting a transfer from the virtual card payment account to the merchant account before redeeming the offer, it may alternatively be arranged that the offer is not limited use and that the merchant 50 simply redeems the offer without checking its validity. This may be the case where not spend limit is set, or it is set at a very high number level such that expiry of the offer by usage is not a concern. Before or after redeeming the offer, the merchant 50 may request a transfer from the virtual card payment account to the merchant account so that use of the offer may be recorded for tracking purposes. In this case, the size of the transaction request is less relevant (although there may still be a transaction amount instruction on the issued offer), but the merchant may be disincentivised from making large transaction requests by invoicing the merchant 50 for any transfers made, optionally with an additional charge per transaction for making use of the service (as earlier described) . Thus, the above

described method may be used for offer validation and/or offer tracking purposes.

The virtual card payment account may be configured such that only transaction requests equalling a particular amount, for example the transaction amount instruction, will be authorised. Whilst it may generally not be in the merchant's interests to request transactions different to the transaction amount instruction as explained above, configuring the virtual card payment account to allow transactions only of a particular value may nevertheless provide additional protection against merchants requesting transactions of an amount different to that intended. In the above, the offer may be made limited use by setting a spend limit on the virtual card payment account. However, the offer may be made to be limited use by any suitable means. For example, by configuring the virtual card payment account to have a counter, whereby the counter increments with each authorised transaction until the counter reaches a pre-determined usage limit, at which time further transaction requests may be declined.

The issued offer may not include a transaction amount instruction, for example if the offer is not limited use (in which case the above merchant transaction request process may be used for offer usage tracking purposes), or if the merchant is aware, for example through training, that a particular transaction amount should be requested when carry out the above method steps .

Rather than the marketing node 54 requesting offer data from the offer provider 20, the offer provider 20 may simply issue regular updates to the marketing node 54 by any means including any suitable data relating to the offers being tracked by the offer tracker 30. Alternatively or

additionally, each change recorded by the offer tracker 30 (for example, a new virtual card payment account has been generated, an offer has been recorded as redeemed, an offer has been recorded as expired) may be reported immediately to the marketing node 54. Rather than new virtual card accounts being obtained in response to a request from the consumer 10 for an offer, the offer provider 20 may obtain a number of virtual card accounts in advance, using the process described above. Each offer requested by a consumer 10 may then be issued with a description of the offer and an associated virtual card payment number that has already been obtained by the offer provider 20.

Furthermore, offers may be issued to consumers without a request from the consumer 10. For example, offers may be issued to particular consumers targeted by the offer

provider 20 and/or the merchant 50 to reward loyalty etc.

Issued offers may be linked to a particular consumer 10, for example by including their details on the issued offer and requiring the merchant 50 to check the consumer's identity before processing the offer. Alternatively, they may be issued to the general public, for example by

including the offer in a generally available public.

Alternatively, multiple copies of the same offer may be distributed to different consumers. Communication between offer tracker 30 and the payment card processing network 40 may take place exclusively via the offer platform 48, for exclusively via at least one other communications channel or a combination of the two. Furthermore, the offer platform 48 may perform the

association between the offer and the virtual card payment account before passing the associated offer and virtual card payment account information to the offer tracker 30, or the payment card processing network 40 may transmit virtual card payment account information directly to the offer tracker 30 for association with an offer, in which case the offer platform 48 may be omitted from the payment card processing network 40. Rather than using a merchant POS 52, any electronic device capable of connection to the payment network 60 may be used. For example, merchant 50 may use a mobile

electronic device such as a smart phone may have access to the payment network 60 via a portal, and the transaction request in step E and the returned authorisation or

declining of the transaction be transmitted from and to the mobile electronic device using, for example, WiFi or a mobile data network. In this way, even when the merchant 50 does not have a POS 52 connected to the payment network 60 via, for example, a fixed telephone line, the system and method may still operate.

Rather than describing the type of offer in words on the offer issued to the consumer 10 as shown in Figures 2 and 3, the type of offer may be communicated on the offer in any way that may be comprehended by the merchant 50. For example, it may be a barcode that can be scanned by the merchant 50, such that the offer is automatically applied by the merchant's payment system to the product (s) that is being purchased. Likewise, for example, it may be a code that can be entered by the merchant into their payment system, or decoded by any other means by the merchant . The virtual card account may be linked to the merchant

50 such that the offer may be redeemed only at the linked merchant 50. A transaction request from any other merchant will be declined, such that a merchant making the request who is not linked to the virtual card account will not honour the offer.

The system and especially the offer tracker 30 may be implemented as a computer system used in a networked environment. The computer system may also be arranged as a personal computer (PC) a desktop computer, or any other machine capable of executing a set of programming

instructions (sequential or otherwise) that specify actions to be taken by that device. The term "system" may also be understood to include any arrangement of systems or sub- units. At least one of the offer provider 20, offer tracker 30 and offer platform 48 may form part of the same server or unit, wherein the offer provider 20 acts as a portal for the consumer 10 and merchant 50 and the offer platform acts as a portal for the virtual account issuer 44.

The computer system may include a processor such as a central processing unit (CPU) . The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. A computer-readable medium may be included to store the logic or program instructions used to implement the described method. The different parts of the system may be connected using a network (e.g. a wireless network and/or a wired network) . The computer system may include one or more interfaces. The computer system may contain a suitable operation system such as UNIX, Windows (RTM) or Linux, for example .

Different suppliers may provide services for various entities in system 1. For example, bespoke (RTM) from

Barclaycard (RTM) may be the offer provider 20. The virtual card bank 46 may be Barclaycard (RTM) . The payment network 60 may be VISA (RTM) . The payment card processor 42 may be TSYS (RTM) . The virtual account issuer 44 may be Conferma. Any combination or all of these functions may be provided by the same entity. As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the spirit and scope of the present invention, as defined by the appended claims.

Claims

CLAIMS :

1. A method of providing an offer to one or more

consumers, the method comprising the steps of:

obtaining a payment account with an associated payment account reference, ;

associating the obtained payment account with an offer identifier; and

issuing the offer comprising the offer identifier and the payment account reference to the consumer for redemption of the offer from a merchant.

2. The method of claim 1, wherein the step of associating the obtained payment account with the offer identifier comprises storing the payment account reference with a record of the offer.

3. The method of either claim 1 or claim 2, further comprising a step of:

receiving a notification of a transaction authorisation for a payment from the payment account to the merchant.

4. The method of claim 3 when dependent on claim 2, further comprising a step of:

recording redemption of the offer when the notification is received.

5. The method of claim 4, further comprising recording at least one of a time of redemption of the offer, a date of redemption of the offer, a place or geographic location of redemption of the offer, and/or an identifier of the

merchant .

6. The method of any one of claims 2 to 5, wherein the step of associating the obtained payment account with the offer further comprises storing at least one of a time of obtaining the payment account, a date of obtaining the payment account, a time of issuing the offer and payment account reference to the consumer, a date of issuing the offer and payment account reference to the consumer, an identifier of the consumer, an expiry date of the offer and an expiry date of the payment account .

7. The method of any preceding claim, wherein the payment account is configured for a limited number of uses

8. The method of claim 7, wherein the payment account is configured to have a limited number of uses by having a nominal spend limit.

9. The method of claim 8, wherein the issued offer further comprises a transaction amount instruction that is less than or equal to the nominal spend limit.

10. The method of any preceding claim, wherein the method further comprises a step of:

the consumer redeeming the offer from the merchant by: the consumer presenting the payment account reference to the merchant; and

the merchant honouring the offer.

11. The method of claim 9, wherein the merchant requests the payment from the payment account by entering into a card processing terminal the payment account reference and a transaction amount that is less than or equal to a nominal spend limit of the payment account, the merchant honouring the offer following a receipt by the card processing terminal of authorisation of the

requested transaction amount, and

the merchant not honouring the offer following a receipt by the card processing terminal of an indication that the requested transaction is declined.

12. The method of claim 11, wherein when the requested transaction is authorised, the requested transaction takes place such that the available spend limit of the payment account is reduced by an amount equalling the requested transaction .

13. The method of any preceding claim, wherein the payment account is a virtual payment card account and the payment account reference is a virtual payment card number.

14. The method according to any previous claim, wherein the offer identifier and payment account are associated with the merchant and the payment account is configured to approve a transfer of funds from the payment account requested by the merchant associated with the payment account.

15. A system for providing an offer to one or more

consumers, the system comprising logic configured to:

obtain a payment account with an associated payment account reference;

associate the obtained payment account with an offer identifier; and

issue the offer comprising the offer identifier and payment account reference to the consumer for redemption of the offer from a merchant.

16. The system of claim 15 further comprising a data store, wherein the logic is further configured to:

associate the obtained payment account with the offer identifier by storing the payment account reference with a record of the offer on the data store.

17. The system of either claim 15 or claim 16, wherein the logic is further configured to:

receive a notification of a transaction authorisation for a payment from the payment account to the merchant.

18. The system of claim 17 when dependent on claim 15, wherein the logic is further configured to:

record redemption of the offer on the data store when the notification is received.

19. The system of claim 18, wherein the logic is further configured to record on the data store at least one of a time of redemption by the consumer, a date of redemption by the consumer, a place or geographic location of redemption by the consumer, and an identifier of the merchant.

20. The system of any one of claims 16 to 19, wherein the logic is further configured to record on the data store at least one of a time of obtaining the payment account, a date of obtaining the payment account, a time of issuing the offer and payment account reference to the consumer, a date of issuing the offer and payment account reference to the consumer, an identifier of the consumer, an expiry date of the offer and an expiry date of the payment account.

21. The system of any one of claims 15 to 20 further comprising an interface with a card payment system, wherein the interface with the card payment system is configured such that :

the merchant may request a payment from the payment account using the interface with the card payment system.

22. The system of any one of claims 15 to 21, further comprising a payment account generator configured to

generate the obtained payment account.

23. A server for providing an offer to one or more

consumers, the server being configured to:

obtain a payment account with an associated payment account reference;

associate the obtained payment account with an offer identifier; and

24. The server of claim 23, further configured to:

store the payment account reference with a record of the offer.

25. The server of either claim 23 or claim 24, further configured to:

26. The server of claim 25 when dependent on claim 23, further configured to:

record redemption of the offer when the notification is received .

27. The server of claim 26 further configured to record at least one of a time of redemption of the offer, a place or geographic location of redemption of the offer, a date of redemption of the offer and/or an identifier of the

merchant .

28. The server of any one of claims 24 to 27 further configured to record at least one of a time of obtaining the payment account, a date of obtaining the payment account, a time of issuing the offer and payment account reference to the consumer, a date of issuing the offer and payment account reference to the consumer, an identifier of the consumer, an expiry date of the offer and an expiry date of the payment account .

29. The server of any one of claims 23 to 28, wherein the payment account is configured to have a limited number of uses .

30. The server of claim 29, wherein the payment account is configured to have a limited number of uses by having a nominal spend limit.

31. The server of claim 30, further configured to issue the offer comprising the offer identifier, payment account reference and an transaction amount instruction that is less than or equal to the nominal spend limit.

32. A computer program comprising program instructions that, when executed on a computer, cause the computer to perform the method of any of claims 1 to 14.

33. A computer-readable medium carrying a computer program according to claim 32.

34. A computer programmed to perform the method of any of claims 1 to 14.