WO2010028454A1

WO2010028454A1 - Payment card system and process

Info

Publication number: WO2010028454A1
Application number: PCT/AU2009/001209
Authority: WO
Inventors: Paul Reeves
Original assignee: TELECHOICE Pty Ltd
Current assignee: TELECHOICE Pty Ltd
Priority date: 2008-09-12
Filing date: 2009-09-11
Publication date: 2010-03-18
Anticipated expiration: 2011-03-12

Abstract

A payment card process for authorising a transaction requested by a merchant including: receiving transaction request data from a payment card network representing a transaction requested by the merchant, including a transaction value and a merchant identifier of the merchant; accessing offer data, representing at least one offer having a merchant identifier; accessing offer float data, representing an offer value associated with the offer; determining whether funds are available for the transaction based on: whether the merchant identifier of the merchant matches the merchant identifier of the offer, using the transaction request data and the offer data, and whether the offer value is at least equal to the transaction value, using the transaction request data and the offer float data; and sending approval data over the payment card network representing an approval of the transaction if the funds are determined to be available.

Description

PAYMENT CARD SYSTEM AND PROCESS

FIELD

The present invention relates to a payment card system and process for use with a payment card network.

BACKGROUND

Payment card management systems, e.g. systems for managing credit, debit and pre-paid cards of card scheme providers, such as MasterCard, VISA, Diners Club, American Express, etc, are based on technically complex computer systems maintained by card issuers and card acquirers to process card transactions between a cardholder and a merchant. The computer systems are connected by dedicated communications protocols operating over data communications networks. Despite their technical sophistication it is considered that the systems still have the following problems: (i) The systems are unable to generate and process sufficient and flexible offer methods for cardholders using their cards with certain merchants; for example, the systems fail to provide sufficient processes for offering and honouring incentives for holders of a pre-paid cards (sometimes called a "prepaid debit cards") to use and re-charge their cards (re-charging refers to depositing more funds / money onto the card's account), (ii) For a merchant, there may be insufficient data generated and reported that represents the activity of their customers who use the payment card systems.

It is desired to address or ameliorate one or more disadvantages or limitations associated with existing payment card management systems and processes, or to at least provide a useful alternative. SUMMARY

In accordance with the present invention there is provided a payment card process for authorising a transaction requested by a merchant including: receiving transaction request data from a payment card network representing a transaction requested by the merchant, including a transaction value and a merchant identifier of the merchant; accessing offer data, representing at least one offer having a merchant identifier; accessing offer float data, representing an offer value associated with the offer; determining whether funds are available for the transaction based on: whether the merchant identifier of the merchant matches the merchant identifier of the offer, using the transaction request data and the offer data, and whether the offer value is at least equal to the transaction value, using the transaction request data and the offer float data; and sending approval data over the payment card network representing an approval of the transaction if the funds are determined to be available.

The offer value may be based on a predetermined offer value associated with a prepayment by the merchant. The payment card process may include: accessing merchant data, representing invoicing details of the merchant, using the merchant identifier; and generating invoice data, representing an invoice for recovering the offer value from the merchant, based on the offer data and merchant data. The offer data may include offer rules data representing one or more conditions for honouring the offer; and the determining whether the funds are available for the transaction may include determining whether the conditions are fulfilled, using the offer rules data and the transaction request data. The conditions may include the transaction value having at least one required value. The transaction request data may include time data representing a transaction time; and the conditions may include the transaction time corresponding to at least one required time. The transaction request data may include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; the payment card process may include accessing customer relationship management (CRM) data of the cardholder, representing CRM information of the cardholder, based on the cardholder identifier; and the conditions may include the cardholder having a required demographic profile in the CRM information. The transaction request data may include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; and the payment card process may include updating account data of the cardholder based on the offer rules data defining a value to add to the cardholder's account value.

The payment card process may include accessing cardholder record data representing an account value of the cardholder, and determining whether the funds are available for the transaction based on the cardholder's account value. The conditions including the transaction value having a required value may include requiring a minimum value, associated with a minimum spend from the cardholder's account, or a minimum transaction value relative to the offer value. The conditions may include a required location, and a location of the offering merchant may be determined based on the merchant identifier.

The payment card process provides a cardholder of a card on the payment card network with credits, associated with an offer, to spend with the offering merchant. The cardholder spends the credits corresponding to the offer value as a customer of the merchant. The card may be related to a cardholder account and may be a credit card, debit card or prepaid card.

Approving the payment card transaction based on the offer value allows a purchase to be approved even if the cardholder does not have sufficient funds in their account to pay for the transaction. The approval may be based on the cardholder's deposit value (i.e. the value of money in their account) together with a relevant offer value. For example, if an offer states "pay only $100 for $150-worth of goods from a certain merchant", a $150 transaction is approved by the payment card management system, and $150 is sent to the merchant, even if the cardholder only has from $100 to $149 in their account. The extra value may be provided by an offer float.

The authorising process may include receiving recovery payment data representing a recovery payment received from the offering merchant based on the invoice data. The invoice data may be sent, and the recovery payment data received, using a direct debit bank network. The recovery payment is typically at least equal to the offer value. The offer data may be accessed in an offers database which includes offer data records representing predefined offers. The transaction request data include cardholder identifier data (e.g. representing a cardholder number), merchant identifier data (e.g. representing a merchant number) and transaction value data. The determination of funds availability may be based on the transaction value data, the offer value data, the cardholder identifier data, cardholder data accessed in a cardholder database (which may include customer relationship management data) and the offer data.

The present invention also provides computer-readable storage having modules stored thereon with program instructions for performing the steps of at least one of the payment card processes.

The present invention also provides a payment card system for authorising a transaction requested by a merchant including: an authorisation module configured to: receive transaction request data from a payment card network representing a transaction requested by the merchant, including a transaction value and a merchant identifier of the merchant; and access offer data in an offers database, representing at least one offer having a merchant identifier; access offer float data, representing an offer value associated with the offer; determine whether funds are available for the transaction based on: whether the merchant identifier of the merchant matches the merchant identifier of the offer, using the transaction request data and the offer data, and whether the offer value is at least equal to the transaction value, using the transaction request data and the offer float data; and send approval data over the payment card network representing an approval of the transaction if the funds are determined to be available.

The offer value may be based on a predetermined offer value associated with a prepayment by the merchant using a management module of the payment card system. The payment card system may include a recovery module configured to: access merchant data in a merchant database, representing invoicing details of the merchant, using the merchant identifier; and generate invoice data, representing an invoice for recovering the offer value from the merchant, based on the offer data and merchant data. The offer data may include offer rules data representing one or more conditions for honouring the offer; and the authorisation module may be configured to determine whether the conditions are fulfilled, using the offer rules data and the transaction request data. The transaction request data may include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; the authorisation module may be configured to access customer relationship management (CRM) data of the cardholder in a cardholder database, representing CRM information of the cardholder, based on the cardholder identifier; and the conditions may include the cardholder having a required demographic profile in the CRM information. The transaction request data may include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; and the authorisation module may be configured to update account data of the cardholder based on the offer rules data defining a value to add to the cardholder's account value. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments are hereinafter further described, by way of example only, with reference to the accompanying drawings, which are not to scale, wherein:

Figure l is a schematic diagram of an embodiment of a payment card system;

Figure 2 is a schematic diagram of a computing machine of the payment card system;

Figure 3 is a schematic diagram of a merchant database of the payment card system;

Figure 4 is a schematic diagram of an offers database of the payment card system;

Figure 5 is a schematic diagram of a cardholder database of the payment card system;

Figure 6 is a schematic diagram of a transaction request of the payment card system;

Figure 7 is a flowchart of a payment card process performed by the payment card system;

Figure 8 is a flowchart of an offer generation process of the payment card process;

Figure 9 is a flowchart of a transaction analysis process of the payment card process;

Figure 10 is a flowchart of an authorisation process of the payment card process;

Figure 11 is a flowchart of a recovery process of the payment card process; and

Figure 12 is a flowchart of a reporting process of the payment card process.

DETAILED DESCRIPTION

A payment card system 100, as shown in Figure 1, includes a merchant 102 with a merchant terminal 104, such as a payment card point-of-sale (POS) terminal, in communication with an acquiring bank server 106, for example of a bank that has provided the merchant terminal 104 to the merchant 102. For example, the acquiring bank server 106 may be part of a bank system of a bank such as Commonwealth Bank or the ANZ bank in Australia. The acquiring bank server 106 is in communication with a payment card network 108, such as a credit card network operated by VISA, MasterCard, American Express or Diner's Club. The acquiring bank server 106 is in communication with an issuing bank server 110 of an issuing bank 112 via the payment card network 108. The acquiring bank server 106 is also in communication with an issuing party server 114 of an issuing party system 116 via the payment card network 108. The issuing party system 116 is related to and controlled by a third party to the merchant 102 and the cardholder. The third party is typically an issuing party that issues payment cards to cardholders, including a cardholder. Each card may be a credit card, a debit card or a pre-paid card (also called a pre-paid "debit" card). The third party has financial information relating to the issued cards and information on the cardholders. The third party controls a monetary float from which monies (i.e. value, or funds, etc.) are drawn to make payments when the cardholders use their cards.

The issuing party system 116 includes a cardholder database 120 accessed by the issuing party server, as shown in Figure 1. The cardholder database 120 contains information about each cardholder. The cardholder database 120 is updated when a new cardholder receives a card and a corresponding card account, when a cardholder is removed, and when personal details about a card relating to a cardholder change. The issuing party server 114 also includes a merchant database 122 with information about each merchant 102 accessed by in the issuing party system 116, as shown in Figure 1.

The issuing party server 114 includes a management module 124 which manages financial funds in the issuing bank 112 in the form of the third party float, represented by third party float data 126, in the issuing bank 112. The management module 124 is in communication with a float management module in the issuing bank server 1 10 which controls the float data 126 (and thus the float). The float data 126 is in the form of secure data representing a monetary float value (i.e. monies, or funds, or value, or money) held by the issuing party in the issuing bank 112 for use in the payment card system. The float data 126 includes cardholder float data 128 which represent the monies (i.e. a cardholder monetary float value) in the account of each cardholder, including in particular monies or value of a pre-paid card account of the cardholder.

The float data 126 include offer float data 130 which represent monies (i.e. an offer monetary float value) provided by the issuing party which are to be used as offer credits for each cardholder when the cardholder is redeeming an offer associated with an offering merchant (e.g. the merchant 102). For example, the offering merchant may make an offer to a cardholder that the offering merchant will provide the cardholder with a predefined value (e.g. $5) if they make a purchase using their payment card with the offering merchant. To redeem this offer, the cardholder makes a purchase using the payment card network 108 with the offering merchant. A portion of the funds for this purchase, represented by the offer value, is drawn from the monies of the offer float data 130. Thus, the issuing party system 116 approves the payment card transaction using a portion of value represented by the offer float data 130 to pay for the purchase by the cardholder. In this way, a cardholder can be effectively provided with temporary or virtual credit based on the offers when using the payment card system 100.

Information about the float data 126 is stored in a float database 132 accessed by the issuing party server 1 14 in the issuing party system 116, as shown in Figure 1. The stored information may include copies of the float data 126, and in particular copies of the cardholder float data 130 and the offer float data 130 which can be accessed by the modules of the issuing party server 114, e.g., the management module 126 and the authorisation module 136.

Information about each offer provided by each merchant 102 is stored as data in an offers database 134 accessed by the issuing party server 114 in the issuing party system 116, also shown in Figure 1. Authorisation of credit card transactions by the issuing party system 116 is performed by the authorisation module 136 in the issuing party server 114. The authorisation module 136 is in communication with the payment card network 108, which receives payment card transaction requests, and approves and declines (i.e. allows and denies) these requests.

The issuing party system 116 recovers funds spent (from funds represented by the offer float data 130) in fulfilling offers of the merchant 102 using a recovery module 138 in the issuing party server 114. The recovery module 138 is in communication with the issuing bank 1 12, via which the recovery module 138 recovers funds (or monies) from the merchant 102 using a merchant bank server 140 (i.e. a server in the merchant's bank) and a data communication bank network 142, e.g. the direct debit network.

The recovery module 138 may arrange for recovery of funds (or monies) from the merchant 102 after an offer has been redeemed by a cardholder, or before an offer is redeemed, based on an estimation of the amount that will be redeemed in a certain period. For example, for an offer with an offer value of $5, which is issued to 1,000 cardholders, the recovery module 138 may receive a portion of this value, based on an estimation of how many cardholders will redeem the offer in the coming month; the recovery module 138 may operate periodically to receive pre-payments of this estimated value on a periodic basis, such as daily, weekly or monthly.

The issuing party server 114 includes a reporting module 144 for reporting relevant cardholder transactions and cardholder information to the merchant 102. The reporting module 144 generates report data representing reports for the merchant 102. The reports include information about the one or more cardholders and related offers from the cardholder database 120 and the offers database 134. The reports include information about transactions that have been approved and denied, which is stored as data in a transactions database 146 of the issuing party system 116, as shown in Figure 1. The reporting module 144 generates reports for an issuing party web server 148 of the issuing party system 116. The web server 148 transmits the report data to an authorised merchant computer 150 over a data network such as the Internet 152. The reports can be used by the merchant 102 to determine which cardholders have acted in relation to each offer, e.g. to determine demographic profiles of the cardholders.

The cardholder can access information about their account issued by the issuing party using a cardholder computer 154 connected to the web server 148 via the Internet 152, and using a cardholder phone 156 connected to an issuing party interactive voice response (IVR) system 158 of the issuing party system 116 via a telephone network 160. The web server 148 and the IVR system 158 generate reporting data for the cardholder about their accounts, and allow the cardholder to manage their accounts via the management module 124.

The cardholder can transfer or deposit money/value into their account (which may be a credit, debit or pre-paid account) using the cardholder computer 154 over the Internet 152, the cardholder phone 156 over the telephone network 160, or a recharge facility offered by a recharge merchant (not shown) where the cardholder can purchase recharge amounts or payments, such as pre-paid cards, or recharge services offered by the recharge merchant. The recharge merchant may include merchant 102 and the recharge may be operated via the merchant terminal 104. Recharging allows the cardholder to transfer money into a cardholder account associated with their card, which may include transferring money/value into the float represented by the cardholder float data 128.

In the described embodiment, at least the issuing party server 114 and the issuing party web server 148 are each implemented using a computing device such as a 32-bit or 64-bit Intel Architecture based computer system 200. The computing devices execute the processes of the payment card system 100 using programming instructions in one or more software modules 202 stored on non-volatile (e.g., hard disk) computer-readable storage 204 associated with the computer system 200, as shown in Figure 2. The software modules 202 include the software modules of the payment card system 100 — particularly the management module 124, the authorisation module 136, the recovery module 138 and the reporting module 144 — in computer-executable code (e.g. compiled programs written using C, C++, Java, etc.). It will be apparent that at least parts of the processes of the payment card system 100 could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field programmable gate arrays (FPGAs).

The computer system 200 includes standard computer components, including random access memory (RAM) 206, at least one processor 208, and external interfaces 210, 212, 214, all interconnected by a bus 216. The external interfaces include universal serial bus (USB) interfaces 210, at least one of which is connected to a keyboard and a pointing device such as a mouse 218, a network interface connector (NIC) 212 which connects the system 200 to a communications network 220, and a display adapter 214, which is connected to a display device such as an LCD panel display 222. The system 200 also includes a number of standard software modules 226 to 230, including an operating system 224 such as Linux or Microsoft Windows XP, web server software 226 such as Apache, available at http://www.apache.org, scripting language support 228 such as PHP, available at http://www.php.net, or Microsoft ASP, and structured query language (SQL) support 230 such as MySQL, available from http://www.mysql.com, which allows data to be stored in and retrieved from an SQL database 232.

For the issuing party server 114, the network 220 connects to the payment card network 108 and the issuing bank server 110. For the issuing party web server 148, the network 220 connects to the Internet 152.

Together, the web server 226, scripting language 228, and SQL modules 230 provide the system 200 with the general ability to allow computing devices connected to the network 220 to access the system 200 and in particular to provide data to and receive data from the database 232. Some of the functionality provided by the system 200 is provided by scripts accessible by the web server 226, including the one or more software modules 202, and also any other scripts and supporting data 234, including markup language (e.g., HTML, XML) scripts, PHP (or ASP), and/or CGI scripts, image files, style sheets, standard libraries, and the like.

The merchant database 122, as shown in Figure 3, includes at least one merchant record represented by merchant record data 302, which include a merchant identifier represented by merchant ID data 304, such as a merchant reference number on the payment card network 108. The merchant record data 302 include deposit value data 306, representing a deposit value of the merchant 102. The merchant deposit value is the (monetary) value of any deposits made into the merchant's account of the issuing party by the merchant 102. The deposit value data 306 enable the issuing party system 116 to record recovery payments made from the merchant 102 to the issuing party including recovery payments, in return for redemption of offers, arranged by the recovery module 138. The merchant record data 302 include direct debit details data 308 representing direct debit details of the merchant 102. The direct debit details data 308 are used by the recovery module 138 for recovering funds after offers have been redeemed. The direct debit details include a bank account name, a bank account number, and authorisation data, allowing the issuing party system 116 to recover/transfer money/funds from the bank account (or similar) of the merchant 102. The merchant record data 302 include offers list data 310 representing a list of offers from the merchant 102, including whether they are current or past offers. Each offer is represented in the offers list data 310 by an offer identifier, or offer ID.

The offers database 134 includes at least one offer record represented by offer record data 402 for each offer made by each merchant 102. Each offer record is indexed by the offer identifier, or offer ID, represented by offer ID data 404. The offer record data 402 includes merchant ID data 406 corresponding to the merchant ID data 304 of the merchant 102 associated with the offer (i.e. the offering merchant). The offer record data 402 includes offer rules data 408 representing rules controlling how the offer is to be applied (i.e. the rules include conditions for honouring the offer). The offer rules are specified by the merchant 102 when making or creating the offer. The conditions in the offer rules may include: the transaction value having a required value; the transaction request data including time data representing one or more required transaction times; and the cardholder having a required demographic profile in customer relationship management (CRM) information of the cardholder. The conditions may therefore relate to, for example, the times and dates when the offer will be valid (e.g. transaction times and dates, such as "each Tuesday", or "next month", or "on 8 August 2008"), for which location(s) the offer is valid (e.g. a location, such as a shop, a suburb, a town, or a premises of the offering merchant), and for which types of cardholders, selected based on the CRM information — represented by CRM data 516 — of each cardholder. The CRM information includes personal, geographic and demographic information, including age, salary, residential location, work location, likes, dislikes, favourite songs / films / foods, friends in social networks, spending habits, past transactions, credit history (at least with the issuing party system 116), etc. The offer record data 402 includes offer value data 410 representing a value, e.g. in dollars, of the offer.

The cardholder database 120, as shown in Figure 5, includes at least one cardholder record represented by cardholder record data 502 for each cardholder with an account administered by the issuing party. The cardholder record data 502 include a cardholder identifier, or cardholder ID, represented by cardholder ID data 504, such as a cardholder number corresponding to a card number in the payment card network 108. The cardholder record data 502 include credit limit data 506 representing a credit limit of the cardholder if the cardholder has a credit card account, and/or deposit value data 508 representing any deposit of monies/funds made by the cardholder. The deposit value may be positive if monies have been deposited for example for a pre-paid card, or negative if the cardholder is permitted to go into debt, e.g. for a credit card. The cardholder record data 502 include a list of offers represented by offers list data 510, where offers relevant to the cardholder are listed by their offer ID in offer ID data 512 and by their redemption status, i.e. whether they have been redeemed or not, in redemption status data 514. The cardholder record data 502 include the customer relationship management (CRM) data 516, representing the CRM information of the cardholder. The issuing party system 116 receives transaction requests from the payment card network 108. Each transaction request is represented by transaction request data 606 which include, as shown in Figure 6, cardholder number data 608 representing the card identifier or card number of the cardholder, merchant number data 610, representing the reference identifier or number of the merchant terminal 104, and transaction value data 612, representing the value of the transaction, i.e. the amount being requested for the purchase.

The databases 120, 122, 132, 134, 146 of the issuing party system 116 are formed on computer-readable storage, such as hard disc drives of database server computers, with a database server (e.g., from Oracle Corp.) providing read and write access to the data. The databases may be in the issuing party server 114, or in one or more separate database server computers connected by a data communications network.

The payment card system 100 performs a payment card process 700, as shown in Figure 7, which commences with an offer generation process 800 (step 702) in which an offer is generated (i.e. an offer from the merchant 102 to one or more cardholders). Once the offer is generated, the cardholder is informed, e.g. in a promotion or advertising campaign. The promotion may be, for example, associated with signing up new cardholders by the issuing party.

When the cardholder (e.g. a person with a credit card issued by the issuing party) uses their card to make a payment to the merchant 102 (using the merchant terminal 104), payment card transaction request data 606 is generated by the acquiring bank server 106 based on data about the transaction from the merchant terminal 104. The issuing party server 114 receives the transaction request data 606 from the payment card network 108 (step 704). The authorisation module 136, upon receiving the transaction request data 606, accesses offer data from the offers database 136 for offers with the merchant ID data 406 (associated with an offering merchant) corresponding to the merchant number data 610 of the transaction request (step 706). If such a corresponding offer (referred to as a "matching offer") is found, the transaction merchant matches the offering merchant. The transaction request represented by the transaction request data 606 is approved or denied in a transaction analysis process 900 (step 708). The authorisation module 136 determines that funds are available to pay for the transaction, and generates verification data representing fund availability for the transaction based on the transaction request data 606 and the offer value data 410 in the offer record data 402. The verification data are also generated based on the offers list data 510 in the cardholder record data 502: the offer is only verified on the basis of the offer value data 410 if the cardholder record data 502 corresponding to the cardholder number 608 in the transaction request data 606 include offer ID data 512 corresponding to the offer ID data 404 of the retrieved offer for this merchant 102, and if the redemption status data 514 of the offer indicates that the offer is still valid. The redemption status data 514 indicate whether, and when, the offer listed by the offer ID data 512 has been redeemed by the cardholder.

If a positive verification is generated in the transaction analysis process 900 in step 708, i.e. if it is determined that the funds are available, approval data is sent to the acquiring bank server 106 using the payment card network 108 in an authorisation process 1000 (step 710). The authorisation module 136 also activates a recovery process 1100 performed by the recovery module 138 (step 712). After the recovery process 1100 in step 712, or following a denied transaction from the transaction analysis process 900 in step 708, the issuing party system 116 performs a reporting process 1200 for reporting to the merchant 102 (step 714).

In the offer generation process 800, as shown in Figure 8, the issuing party server 114 receives offer details for a new offer, from the merchant 102, and generates new offer record data 402 representing the new offer, including the merchant ID data 406, the offer rules data 408 and the offer value data 410 (step 802). The issuing party, in the offer generation process 800, receives details of the offer, but not monies or funds corresponding to the offer value 410. Following generation of the new offer record data 402, and thus generation of the offer ID data 404, the offer is applied to one or more cardholder records by updating the offers list data 510 of each relevant cardholder to include offer ID data 512 corresponding to this offer. The cardholders which are to receive this offer are selected based on a CRM profile from the merchant 102 applied to the CRM data 516 (step 804). For example, the CRM data 516 includes the current age of the cardholders, and the offer may be included in the offers list data 510 only for the cardholders in a certain age bracket, e.g. between the ages of 10 and 20 years. Once the relevant cardholders are selected, data representing the details of the offer, including the offer value, and the corresponding offering merchant, are sent to the selected cardholders (step 806). For certain offers, the relevant cardholders are all of the cardholders, i.e. the entire cardholder population. Alternatively or additionally, details of the offer may be transmitted to potential cardholders fitting the selected CRM profile using a third-party CRM marketing database, e.g. from a marketing and communications firm.

Offer record data 402 are generated for each offer (step 808) and the cardholder record is tagged with the offer ID data 404 and the corresponding merchant ID data 304 (step 810).

The management module 124 optionally receives a deposit of value/money from the cardholder into the float represented by the cardholder float data 128, for example a prepayment can be made by a holder of a pre-paid card (step 812), which then activates certain offers for the paying cardholder. For example, offers in the offers database 134 may only become active or redeemable (indicated in the redemption status data 514) after a pre-paid cardholder recharges their card account by a minimum amount, for example $50 or $100.

The transaction analysis process 900 commences, as shown in Figure 9, with the authorisation module 136 receiving the transaction request data 606 from the payment card network representing a transaction requested by the transaction merchant 102 (i.e. a merchant performing a transaction) (step 902). The authorisation module 136 determines the relevant offer ID based on the merchant number data 610 in the transaction request data 606 matching merchant ID data 406 in the offers database 134, and the cardholder number data 608 and the offer ID data 404 matching a relevant cardholder in the cardholder database 120 (step 904). If an unredeemed relevant offer is determined, the offer rules and the offer value are determined from the offer record 402 in the offers database 134 using the offer ID data 404.

The issuing party system 116, using the authorisation module 136 and/or the management module 124 determines whether the one or more offer conditions of the offer rules in the offer rules data 408 are fulfilled, e.g. including an offer condition based on the transaction value (step 906). The offer condition may require a minimum transaction value, for example at least a spend of $100 in the transaction, or a minimum transaction value relative to the offer value, e.g. a spend of twice the offer value in the offer value data 410.

The authorisation module 136 determines whether the offer rules are fulfilled, e.g. based on the transaction value (step 908), and whether the cardholder has sufficient value to pay for the transaction once any valid offer value is taken into consideration. The account value of the selected cardholder is determined based on the credit limit of the cardholder and the deposit value of the cardholder represented by the credit limit data 506 and the deposit value data 508 in the cardholder record 502 (step 910).

The authorisation module 136 generates verification data representing the fund availability for the transaction, i.e. from funds represented by the float data 126, based on the transaction value data 612, the offer value data 410, the credit limit data 506 and the deposit value data 508 (step 912). If the cardholder account has sufficient value to pay for the transaction, including any discount associated with the relevant offer, and if the offer float data 130 represents sufficient value to pay for the relevant offer value, the transaction request is verified, representing the determination that the funds are available.

The authorisation process 1000, as shown in Figure 10, commences by receiving the verification data from the transaction analysis process 900 (step 1002), after which the authorisation module 136, in communication with the management module 124, generates data to hold (or reserve or freeze) the funds corresponding to the transaction value in the float data 126 (step 1004). The authorisation module 136 then sends approval data over the payment card network 108 to the acquiring bank server 106 representing approval of the transaction based on the verification data (step 1006). The issuing bank 112 is authorised to send the funds of the approved transaction value to the acquiring bank.

Following transmission of the approval, the management module 124 updates the deposit value data 508 of the cardholder (and the cardholder float data 128), the redemption status data 514 and the CRM data 516 based on the approved transaction request data 606, in particular the transaction value data 612, the offer value data 410, and optionally the offer rules data 408 (step 1008). The updating is performed by sending update data to the issuing bank 112 and the databases of the issuing party system 116.

Following redemption of the offer, the redemption status data 514 may be sent to indicate that the offer has been redeemed and is no longer available; alternatively, for an "ever- greening offer" the redemption status data 514 is set (or allowed to remain) to indicate that the offer is still available — i.e. the offer is renewed automatically when it is used — which may be used for example in a conditional offer of $2 value if $100 is spent in stores such as newsagents, petrol stations and supermarkets. The ever-greening offer may be reset in the redemption status data 514 after a period of time has passed: the redemption status data 514 may be reset to indicate that the offer is available after a certain period of time (e.g. after a number of minutes, hours or days predefined by the offering merchant in the offer record 402), or at a regular intervals (e.g. regularly after a number of hours, days or weeks predefined by the offering merchant in the offer record 402). The management module 124 also updates data in the float database 132 representing a cardholder float record and a offer float record (step 1010).

The updates to the cardholder float data 128 and the cardholder float record in steps 1008 and 1010 may be either negative or positive, representing monies being spent or received respectively from or by the cardholder's account. Typically these account updates represent monies being spent as in a typical credit card transaction; however, for some offer rules (represented in the offer rules data 408), the cardholder account may be credited with value in step 1008 in association with particular offers. Thus updating the cardholder record data 502 (and the cardholder float data 128) is based on the offer rules data defining a value to add or deduct from the cardholder's account value. For example, the offer rules may define that the cardholder's account receive a determined amount of value into their account if a determined amount of money is spent, e.g. "receive $5,000 cash back for purchasing a new car" or "receive $10 cash for purchasing any Coca-Cola beverage". The value transferred to the cardholders' account is recovered from the merchant 102, either as a pre-payment or in the recovery process 1100.

At the end of the authorisation process 1000, the management module 124 updates the deposit value in the deposit value data 306 of the merchant 102 corresponding to the approved transaction, based on the offer value (step 1012): the deposit value is represented by a negative number when the offer has been paid out of the offer float.

The recovery module 138 performs a recovery process 1100 if funds have been paid from the offer float in accordance with an approved transaction, i.e. a transaction where the funds were determined to be available based on an offer value. The recovery process 1100, as shown in Figure 11, commences with the recovery module 138 accessing the redeemed offer ID (represented by the offer ID data 404 of the redeemed offer), and thus the corresponding merchant ID data 406 of the offering and transaction merchant (step 1102). The recovery module 138 determines the offer value from the offer value data 410 of the offer record 402 corresponding to the offer ID (step 1104), and sends data representing a value request (e.g. a direct debit request) to the issuing bank server 110 including the offer value and the direct debit details data 308 of the offering and transaction merchant (step 1106). The issuing bank server 110 receives the direct debit request (step 1108), and sends the direct debit request (step 1110), via the bank network 142 (step 1112) to the merchant bank server 140. The merchant bank server 140 processes the direct debit request by accessing the merchant's bank account (step 1114) and sends a recovery payment (represented by recovery payment data) corresponding to the offer value (step 1116) via the bank network 142 (step 1118) to the issuing bank server 1 10. The issuing bank server 110 receives the recovery payment data (step 1 120), and adds the recovered funds/value to the offer float, recorded in the offer float data 130 (step 1122). The recovery process allows for recovering of the value of the offer that was transmitted to the merchant after approval of the transaction. The issuing party server 110 sends confirmation of the addition of the recovery payment to the float to the issuing bank system 116 (step 1124). The recovery module 138 receives the confirmation of recovery payment (step 1126), and in conjunction with the management module 124 updates the deposit value data 306 of the merchant record 302 to indicate that the deposit has increased by the recovery payment value, and updates the offer float record in the float database 132 to indicate that the offer float value has also increased by the recovery payment value (step 1128).

In certain embodiments, the recovery module 138 performs an alternative predetermined value recovery process. In the predetermined value recovery process, the monetary float value is based on a predetermined float value made in a prepayment by the offering merchant. The prepayment allows at least a portion of an estimated total offer value to be received from the merchant before the funds are paid from the offer float. The total offer value is determined based on the offer value (e.g. $5), multiplied by the number cardholders for whom the offer is valid (e.g. 1,000). This process may occur periodically, e.g. weekly, monthly or yearly, and may recover a pre-selected portion or percentage of the total offer value, e.g. between 1% and 100%, based on an estimated rate of redemption selected by the offering merchant.

In the reporting process 1200, performed by the reporting module 144, as shown in Figure 12, the reporting module 144 receives a report request from a merchant, e.g. from the merchant computer 150 via the Internet 152 to the web server 148 (step 1202). The report request is authenticated, e.g. by requiring secure login data from the merchant computer 150. The reporting module 144 generates the report based on the merchant ID data 304 corresponding to the authenticated merchant, any offer record data 402 with a corresponding merchant ID in the merchant ID data 406 (and thus one or more offer IDs for the report), and any cardholder record data 502 with one or more corresponding offer IDs in the offer ID data 512 (step 1204). The report is generated based on the CRM data 516, for example the number of cardholders of a certain age corresponding to a particular offer. The report is also generated based on transactions data in the transaction database 146, and the redemption status data 514, showing the rate of redemption of offers, and selected data regarding the demographics of the redeeming cardholders. The generated report data is sent to the merchant 102 by the web server 148 over the Internet 152 (step 1206).

In an example, an offering merchant manages a "one-dollar" shop which makes the following offer: "all customers paying using their ABCD card receive $5 to spend on any item in the shop". The ABCD card corresponds to a card managed (i.e. controlled or administered) by the issuing party system 116. The only items available for purchase from the one-dollar shop using the payment card may have a predefined value of $5, thus the offer value is $5. An offer float is available, managed by the payment card system, with a value based on the offer value of $5 and an estimation of how many times this offer will be accepted or taken advantage of by cardholders within a particular period (e.g. one month). The offer merchant has 10,000 items in stock, so the offer float value is selected to be $50,000. The offer rules specify that all cardholders making a transaction request should have it approved. Any transaction with the merchant identifier corresponding to the offer merchant is approved. The merchant is invoiced (billed) for the offer value for each approved transaction.

In another example, a "no-condition cash" offer is made as follows: "make any purchase from Merchant A and receive $1 off the marked price". The offer value is $1 and the offer rules define that the offer is honoured for all transaction requests with a merchant identifier corresponding to "Merchant A". (The offer rules may also define limited ever-greening, limited transactions times at which the offer will be honoured, and/or a limited CRM profile for a cardholder.) The payment card system 100 manages this offer with no changes being required to information-technology systems of the merchant 102, or even any requirement for the staff of the merchant 102 to be trained or informed.

In another example, a "condition cash" offer is made as follows: "spend at least $100 at Merchant A and get $50 off or "spend $100 at Merchant A and get 25% off. The offer rules define a minimum value of the transaction value for the offer to be honoured. The offer value may be a set amount, such as "$50", or an amount that depends from the transaction value, such as 25% of the transaction value. The value of the offer is recovered from the merchant 102 (either by prepayment or in the recovery process 1100). The difference between transaction value and the offer value is deducted from the cardholder's account (managed by the issuing party system 116).

In another example, a "reimbursement cash" off is made as follows: "spend $5 at Merchant A and get $10 cash back". The offer rules define a minimum value of the transaction value for the offer to be honoured. The offer rules define a positive value to credit to the cardholder account.

Many modifications to the embodiments described herein with reference to the accompanying drawings will be apparent to those skilled in the art without departing from the scope of the present invention defined in the appended claims.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Claims

CLAIMS:

1. A payment card process for authorising a transaction requested by a merchant including: receiving transaction request data from a payment card network representing a transaction requested by the merchant, including a transaction value and a merchant identifier of the merchant; accessing offer data, representing at least one offer having a merchant identifier; accessing offer float data, representing an offer value associated with the offer; determining whether funds are available for the transaction based on: whether the merchant identifier of the merchant matches the merchant identifier of the offer, using the transaction request data and the offer data, and whether the offer value is at least equal to the transaction value, using the transaction request data and the offer float data; and sending approval data over the payment card network representing an approval of the transaction if the funds are determined to be available.

2. A payment card process as claimed in claim 1, wherein the offer value is based on a predetermined offer value associated with a prepayment by the merchant.

3. A payment card process as claimed in 1 , including: accessing merchant data, representing invoicing details of the merchant, using the merchant identifier; and generating invoice data, representing an invoice for recovering the offer value from the merchant, based on the offer data and merchant data.

4. A payment card process as claimed in any one of claims 1 to 3, wherein: the offer data include offer rules data representing one or more conditions for honouring the offer; and the determining whether the funds are available for the transaction includes determining whether the conditions are fulfilled, using the offer rules data and the transaction request data.

5. A payment card process as claimed in claim 4, wherein: the conditions include the transaction value having at least one required value.

6. A payment card process as claimed in one of claims 4 or 6, wherein: the transaction request data include time data representing a transaction time; and the conditions include the transaction time corresponding to at least one required time.

7. A payment card process as claimed in any one of claims 4 to 6, wherein: the transaction request data include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; the payment card process includes accessing customer relationship management

(CRM) data of the cardholder, representing CRM information of the cardholder, based on the cardholder identifier; and the conditions include the cardholder having a required demographic profile in the

CRM information.

8. A payment card process as claimed in any one of claims 1 to 7, wherein: the transaction request data include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; and the payment card process includes updating account data of the cardholder based on the offer rules data defining a value to add to the cardholder's account value.

9. Computer-readable storage having modules stored thereon with program instructions for performing the steps of a payment card process as claimed in any one of claims 1 to 8.

10. A payment card system for authorising a transaction requested by a merchant including: an authorisation module configured to: receive transaction request data from a payment card network representing a transaction requested by the merchant, including a transaction value and a merchant identifier of the merchant; and access offer data in an offers database, representing at least one offer having a merchant identifier; access offer float data, representing an offer value associated with the offer; determine whether funds are available for the transaction based on: whether the merchant identifier of the merchant matches the merchant identifier of the offer, using the transaction request data and the offer data, and whether the offer value is at least equal to the transaction value, using the transaction request data and the offer float data; and send approval data over the payment card network representing an approval of the transaction if the funds are determined to be available.

11. A payment card system as claimed in claim 10, wherein the offer value is based on a predetermined offer value associated with a prepayment by the merchant using a management module of the payment card system.

12. A payment card system as claimed in 10, including: a recovery module configured to: access merchant data in a merchant database, representing invoicing details of the merchant, using the merchant identifier; and generate invoice data, representing an invoice for recovering the offer value from the merchant, based on the offer data and merchant data.

13. A payment card system as claimed in any one of claims 10 to 12, wherein: the offer data include offer rules data representing one or more conditions for honouring the offer; and the authorisation module is configured to determine whether the conditions are fulfilled, using the offer rules data and the transaction request data.

14. A payment card system as claimed in claim 13, wherein: the conditions include the transaction value having at least one required value.

15. A payment card system as claimed in one of claims 13 or 14, wherein: the transaction request data include time data representing a transaction time; and the conditions include the transaction time corresponding to at least one required time.

16. A payment card system as claimed in any one of claims 13 to 15, wherein: the transaction request data include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; the authorisation module is configured to access customer relationship management

(CRM) data of the cardholder in a cardholder database, representing CRM information of the cardholder, based on the cardholder identifier; and the conditions include the cardholder having a required demographic profile in the

CRM information.

17. A payment card system as claimed in any one of claims 10 to 16, wherein: the transaction request data include cardholder identifier data representing a cardholder identifier of a cardholder requesting the transaction; and the authorisation module is configured to update account data of the cardholder based on the offer rules data defining a value to add to the cardholder's account value.