Abstract:

A method includes receiving transaction data associated with a payment
transaction. The transaction data includes a payment account identifier.
The payment account identifier identifies a payment account. The method
further includes obtaining a spending history associated with the payment
account identified by the payment account identifier. The spending
history reflects a total amount of spending transactions charged to the
payment account during a period of time. The method also includes
providing an indication of the spending history to an acquirer.

Claims:

1. A method comprising:receiving transaction data associated with a
payment transaction, said transaction data including a payment account
identifier, said payment account identifier identifying a payment
account;obtaining a spending history associated with said payment account
identified by said payment account identifier, said spending history
reflecting a total amount of transactions charged to said payment account
during a period of time; andproviding an indication of said spending
history to an acquirer.

2. The method of claim 1, wherein said indication identifies a relative
level of spending activity of said payment account.

3. The method of claim 2, wherein said indication includes at least one
of: a low spending activity, a medium spending activity, a high spending
activity, and a premium spending activity.

4. The method of claim 2, wherein said acquirer bases an interchange fee
for said payment transaction on said indication.

5. A method comprising:receiving in a first computer transaction data
associated with a transaction in a payment card system, said transaction
data including a payment card account identifier, said payment card
account identifier identifying a payment card account, said transaction
data including a transaction amount for said transaction;accessing a
database record for said payment card account; andtransmitting from said
first computer to a second computer an indication of a spending history
for said payment card account, said indication based on said database
record.

6. The method of claim 5, wherein:said spending history is determined
quarterly based on a total amount spent in a preceding twelve-month
period by said payment card account.

7. The method of claim 5, wherein said spending history is determined
based on an amount of spending by said payment card account with a
particular merchant.

8. The method of claim 5, wherein said spending history is determined
based on an amount of spending by said payment card account with a
particular class of merchants.

9. The method of claim 5, wherein said spending history is determined
based on all spending by said payment card account during a period of
time.

10. The method of claim 5, wherein:said spending history reflects spending
by a group of payment card accounts that includes said payment card
account identified by said payment card account identifier.

11. An apparatus comprising:a processor; anda memory in communication with
the processor, the memory storing program instructions, the processor
operative with the program to:receive transaction data associated with a
transaction in a payment card system, said transaction data including a
payment card account identifier, said payment card account identifier
identifying a payment card account, said transaction data including a
transaction amount for said transaction;determine whether an interchange
fee for said transaction is spending-history dependent;in a case where
said interchange fee is spending-history dependent:access a database
record for said payment card account; andinclude a spending history
indication in an authorization response transmitted by said apparatus to
an acquirer, said spending history indication indicative of a spending
history associated with said payment card account;in a case where said
interchange fee is not spending-history dependent, transmit an
authorization response to said acquirer without any spending history
indication.

12. The apparatus of claim 11, wherein:said spending history is determined
quarterly for said payment card account based on a total amount spent in
a preceding twelve-month period by said payment card account.

13. The apparatus of claim 11, wherein:said spending history reflects only
spending by said payment card account.

14. The apparatus of claim 11, wherein said spending history is determined
based on an amount of spending by said payment card account with a
particular merchant.

15. The apparatus of claim 11, wherein said spending history is determined
based on an amount of spending by said payment card account with a
particular class of merchants.

16. The apparatus of claim 11, wherein said spending history is determined
based on all spending by said payment card account during a period of
time.

17. The apparatus of claim 11, wherein:said spending history reflects
spending by a group of payment card accounts that includes said payment
card account identified by said payment card account identifier.

18. A method comprising:transmitting an authorization request from a first
computer to a second computer, said authorization request related to a
transaction in a payment card system, said authorization request
including a payment card account number, said payment card account number
identifying a payment card account to which the transaction is to be
charged;receiving a spending history indication in the first computer,
the spending history indication indicative of a spending history
associated with said payment card account; andthe first computer
determining an interchange fee for said transaction based at least in
part on said spending history indication.

19. The method of claim 18, wherein the spending history indication is
included in an authorization response received in the first computer via
a payment card system operator.

20. The method of claim 18, wherein the spending history indication is
included in a message that is not an authorization response, said message
received from a computer operated by or on behalf of a payment card
system operator.

21. A method comprising:transmitting an authorization request from a first
computer to a second computer, said authorization request related to a
transaction in a payment card system, said authorization request
including a payment card account number, said payment card account number
identifying a payment card account to which the transaction is to be
charged;receiving an authorization response in the first computer, said
authorization response including an information element not contained in
the authorization request; andthe first computer determining an
interchange fee for said transaction based at least in part on said
information element included in said authorization response and not
contained in said authorization request.

22. The method of claim 21, wherein said information element is a spending
history indication.

23. The method of claim 22, wherein said spending history indication is
indicative of a cumulative total of transaction amounts of a plurality of
transactions charged to said payment card account during a time period
prior to said transmitting step.

[0002]Embodiments disclosed herein relate to payment systems. In
particular, some embodiments relate to methods, apparatus, systems, means
and computer program products for dynamic interchange pricing in a
payment processing network.

[0003]Payment cards are frequently used to pay for goods and services. One
of the best known payment card systems is operated by MasterCard
International Incorporated, which is the assignee hereof. As is very well
known, cardholders present payment cards at point of sale terminals, or
otherwise provide their payment card account numbers to merchants, in
order to pay for purchase transactions.

[0004]Payment cards are issued by financial institutions such as banks to
individual cardholders and to businesses and other entities. These
financial institutions are referred to as issuers. The issuers of the
payment cards maintain the payment card accounts of the cardholders.

[0005]Another class of participants in a payment card system is referred
to as the "acquirers". These are financial institutions which have
relationships with merchants who accept payment cards in as payment for
transactions entered into by cardholders. Acquirers in substance serve as
the merchants' point of contact with the payment card system. To initiate
transactions in the payment card system, merchants accept payment cards
and transmit authorization requests to acquirers.

[0006]The operator of the payment card system (e.g., the assignee hereof)
is sometimes referred to as the "payment card system operator" or just
the "operator". The payment card system operator operates a payment
processing system that receives authorization requests for purchase
transactions from the acquirers and routes the requests to the issuers of
the payment cards. An example of a payment processing system is the
"Banknet" system, which is operated by the assignee hereof. The payment
card system operator also operates a clearing system by which settlement
of transactions occurs between issuers and acquirers.

[0007]One aspect of a typical payment card system is referred to as
"interchange". An interchange fee is a small fee paid by the acquirer to
the issuer with respect to a particular transaction. The purpose of the
interchange fee is to compensate the issuer for a portion of the risks
and costs it incurs. Interchange rates/fees are only one of the many cost
components of the "merchant discount rates" that are established by
acquirers and paid by merchants in exchange for card acceptance services
provided by acquirers to merchants.

[0008]Interchange rates may in some cases be established on the basis of a
bilateral agreement between an issuing bank and an acquiring bank.
However, for many transactions in a payment card system, the interchange
fee for a particular transaction is based on a "default" interchange rate
established by the payment card system operator. Such interchange rates
are "default" in the sense that they apply in the absence of a bilateral
agreement between the issuer and the acquirer bank.

[0009]Interchange fees are a necessary and efficient method for
maintaining a strong and vibrant payment card system. Setting interchange
rates is a challenging proposition that involves an extremely delicate
balance. If interchange rates are set too high, such that they lead to
disproportionately high merchant discount rates, then merchants' desire
and demand to accept a particular brand of payment card may be reduced.
However, if interchange rates are set too low, then issuers' willingness
to issue and promote the brand of payment cards will be reduced, and
cardholders' demand for the brand of payment cards will also be reduced.
In response to these competitive forces, a payment card system operator
may strive to maximize the value of the payment card system (including
total dollars spent with the system's cards, the number and types of
cards in circulation, and the number and types of merchants accepting the
system's cards) by setting default interchange rates at levels that
balance the benefits and costs to both cardholders and merchants.

[0010]In a typical arrangement, the payment card system operator publishes
interchange rates that apply to various categories of transactions.
During the process of clearing the transactions, the acquirers determine
which rates apply to the transactions based on information about the
transactions received from the merchants.

[0011]A published set of interchange rates may apply, for example, to
transactions submitted by merchants in the United States and charged to
payment card accounts issued in the United States. Another set of
interchange rates may apply to transactions submitted by merchants in the
United States and charged to payment card accounts issued outside of the
United States. Similarly, other sets of interchange rates may apply to
transactions submitted by merchants in other countries, based on payment
card accounts issued in those countries or outside of those countries.

[0012]Interchange rate tables may be organized by the type of card product
under which the payment card account is issued. Each interchange rate may
have a series of requirements, all of which must be satisfied in order
for a transaction to qualify for that rate. The requirements may include
such factors as: merchant category; the time between authorization and
clearing; the presence or absence of magnetic stripe data; the submission
of enhanced transaction data; and a merchant's sales and transaction
volume in the payment card system. In some cases the transaction amount
for the particular transaction must be above or below a particular
transaction amount threshold for the transaction to qualify for a
particular interchange rate.

[0013]Examples of merchant categories are restaurant, airline, vehicle
rental, convenience stores, and fuel dispenser. There are many other
merchant categories in use for establishing interchange rates.

[0014]Typically an interchange rate is composed of one or both of two
components, namely a percentage of the transaction amount and a flat per
transaction charge. A typical percentage amount for an interchange rate
may be in the range of 1.5% or 2.0% (although higher or lower percentage
amounts may apply in some cases). A typical flat per transaction charge
may be $0.05 to $0.10. Thus, for example, certain transactions may
qualify for an interchange rate of 1.55%+$0.10, whereas other
transactions may qualify for an interchange rate of 1.90%+$0.05. Many
other combinations of percentage plus flat fee are in use. A percentage
alone without flat fee is also applicable to some categories of
transactions. Also, for example, some interchange rates may simply be a
flat fee such as $0.75. For some categories, an interchange rate that
includes a percentage (with or without a flat charge component) may be
subject to a minimum fee floor and/or a maximum fee ceiling per
transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015]Features and advantages of some embodiments of the present
invention, and the manner in which the same are accomplished, will become
more readily apparent upon consideration of the following detailed
description of the invention taken in conjunction with the accompanying
drawings, which illustrate preferred and exemplary embodiments and which
are not necessarily drawn to scale, wherein:

[0016]FIG. 1 is a block diagram that illustrates a payment card system in
which the present invention may be applied.

[0017]FIG. 2 is a block diagram that illustrates additional details of the
payment card system of FIG. 1.

[0018]FIG. 3 is a simplified block diagram of a server computer that is
operated by a payment card system operator as part of the system of FIG.
1.

[0019]FIG. 4 is a simplified block diagram of a server computer that is
operated by an acquirer as part of the system of FIG. 1.

[0020]FIG. 5 is a flow chart that illustrates a process that may be
performed in accordance with aspects of the present invention by the
payment card system operator server computer of FIG. 3.

[0021]FIG. 6 is a flow chart that illustrates another process that may be
performed in accordance with aspects of the present invention by the
payment card system operator server computer of FIG. 3.

[0022]FIGS. 7A and 7B together form a flow chart that illustrates a
process that may be performed in accordance with aspects of the present
invention by the acquirer server computer of FIG. 4.

DETAILED DESCRIPTION

[0023]In general, and for the purpose of introducing concepts of
embodiments of the present invention, embodiments relate to payment card
systems in which an interchange fee is assessed to transactions. In
previous systems, to the extent that interchange rates were based on the
identity of the payment card account, the interchange rates were based on
static attributes, such as the type of card product issued for that
account. Embodiments of the present invention introduce systems and
methods for determining and assessing dynamic interchange fees based on,
for example, payment card account spending history.

[0024]FIG. 1 is a block diagram that illustrates a payment card system 100
in which the present invention may be applied.

[0025]The payment card system 100 includes numerous merchant processing
systems 102. Each merchant processing system 102 is a computer or
computer system that receives transaction data from the POS locations
(indicated by reference numerals 202 in FIG. 2) connected to it and that
forwards authorization requests and requests to settle purchase
transactions to an acquirer computer 104. In the case of an internet
shopping site, the POS location(s) and the merchant processing system may
be integrated together into a single computer system. In some cases (not
illustrated), the POS location 202 may communicate directly with an
acquirer computer 104, without an intervening merchant processing system.

[0026]The term "acquirer" is widely used in the payment processing field,
and refers to financial institutions such as banks or other financial
systems that have agreements with merchants to receive and forward
authorization and settlement messages in connection with payment card
payments received by those the merchants. The term "acquirer" also refers
to processing agents that act on behalf of such financial institutions or
systems. Each acquirer typically serves numerous merchants, and
accordingly each acquirer computer 104 is shown as being in communication
with numerous merchant processing systems 102. Moreover, a typical
payment card system involves numerous acquirers, and FIG. 1 therefore
schematically shows numerous acquirer computers 104.

[0027]As will be understood from FIGS. 1 and 2, taken together, the
payment card system 100 includes numerous POS locations 202 (FIG. 2). The
term "POS location" refers to "points of transaction" such as internet
commerce sites that receive payment account numbers from customers who
shop online, mail order or telephone (MOTO) merchants who receive payment
account numbers by telephone and/or mail, merchants who submit recurring
payments pursuant to agreements with cardholders and physical point of
sale terminals located in brick-and-mortar retail stores. In the case of
physical point of sale terminals, a payment card (not shown; e.g., a
credit card, debit card, charge card, stored value card, or a corporate
card or fleet card) is presented at the terminal by a customer and read
by the terminal to input, among other things, the number of the payment
card account to which a purchase transaction is to be charged. In the
case of other types of POS location, the payment card account number is
input into the POS location by human data entry or other means.

[0028]In addition to the acquirer computers 104, the payment card system
100 includes a payment processing network 106, such as the
above-mentioned Banknet system. The payment processing network 106 is
constituted by one or more computers operated by the payment card
association, and related data communication facilities (not separately
shown). The payment processing network 106 is in communication, at least
from time to time, with the acquirer computers 104. The payment
processing network 106 receives transaction authorization requests from
acquirers and passes the authorization requests to issuers of payment
cards. The payment processing network 106 also returns authorization
responses to the acquirers from the issuers.

[0029]The payment card system operator may also operate a transaction
clearing system, such as the well known Global Clearing Management System
(GCMS), also operated by the assignee hereof. The transaction clearing
system is not shown apart from the payment processing network 106. The
transaction clearing system, like the payment processing network 106, may
be constituted by one or more computers operated by, and associated
communication facilities commissioned by, the payment card system
operator. The transaction clearing system receives purchase transaction
clearing requests, typically in batches, from the acquirer computers 104.
However, in an alternative embodiment, the payment card system operator
computer(s) which handle(s) authorization requests and responses may be
integrated with the transaction clearing system computer(s).

[0030]The above description relates primarily to a so-called "two message"
system, in which an authorization request/response is later followed by a
clearing message. However, payment card systems may also operate on a
"one message" basis in which authorization and clearing are performed
simultaneously in a single round of request and response.

[0031]FIG. 1 also shows, as part of the payment card system 100, issuer
computers 108. Issuer computers 108 are operated by financial
institutions that have issued the payment cards used by cardholders in
connection with the payment card system 100. In the case of MasterCard
International Incorporated, numerous issuers participate in the
MasterCard payment card system, and accordingly numerous issuer computers
108 are schematically shown as being in communication with the payment
processing network 106. As is well-known, the issuers maintain payment
card accounts of the cardholders. Clearing messages received by the
issuer computers 108 from the payment card system clearing system (not
shown apart from payment processing network 106) indicate (typically in
batches) transactions that are to be charged by the issuers to the
cardholders' accounts.

[0032]FIG. 3 is a simplified block diagram of a server computer 301 that
is operated by a payment card system operator as part of the payment card
system 100. The server computer 301 (hereinafter referred to as a
"payment card system operator computer") may in practice be constituted
by one computer or two or more cooperating computers, and may perform
functions normally provided by the payment card system operator in
conjunction with a payment card system. From previous discussion it will
be understood that these functions may include routing of authorization
requests and authorization responses, and clearing of transactions in the
payment card system 100. Further, and in accordance with aspects of the
present invention, the payment card system operator computer 301 may
perform functions related to accumulating spending history information
and providing indications of such information to acquirers for use by the
acquirers in determining what interchange rates are to be applied to
purchase transactions in the payment card system 100.

[0033]The payment card system operator computer 301 may be conventional in
its hardware aspects but may be controlled by software to cause it to
operate in accordance with aspects of the present invention.

[0034]The payment card system operator computer 301 may include a computer
processor 300 operatively coupled to a communication device 302, a
storage device 304, an input device 306 and an output device 308.

[0035]The computer processor 300 may be constituted by one or more
conventional processors. Processor 300 operates to execute
processor-executable steps, contained in program instructions described
below, so as to control the payment card system operator computer 301 to
provide desired functionality. The program instructions may be referred
to as computer readable program code means.

[0036]Communication device 302 may be used to facilitate communication
with, for example, other devices (such as the acquirer computers 104 and
the issuer computers 108 shown in FIG. 1).

[0037]Input device 306 may comprise one or more of any type of peripheral
device typically used to input data into a computer. For example, the
input device 306 may include a keyboard and a mouse. Output device 308
may comprise, for example, a display and/or a printer.

[0038]Storage device 304 may comprise any appropriate information storage
device, including combinations of magnetic storage devices (e.g.,
magnetic tape and hard disk drives), optical storage devices such as CDs
and/or DVDs, and/or semiconductor memory devices such as Random Access
Memory (RAM) devices and Read Only Memory (ROM) devices, as well as
so-called flash memory. Any one or more of such information storage
devices may be referred to as a computer usable medium.

[0039]Storage device 304 stores one or more programs for controlling
processor 300. The programs comprise program instructions that contain
processor-executable process steps of payment card system operator
computer 301, including, in some cases, process steps that constitute
processes provided in accordance with principles of the present
invention, as described in more detail below.

[0040]The programs may include an application 310 that programs the
payment card system operator computer 301 to handle authorization
requests and clearing for transactions in the payment card system 100.
The payment card system operator computer 301 may handle the transactions
generally in accordance with conventional practices, except that, in
addition, the payment card system operator computer 301 may provide
information elements to the acquirer computers 104 for use by the
acquirer computers 104 in determining what interchange rates apply to the
transactions.

[0041]In addition the programs stored in the storage device 304 may
include an application 312 that programs the payment card system operator
computer 301 to keep track--on an account-by-account basis--of purchase
transactions performed in the payment card system 100 for each payment
card account (or at least for each account in a subset of the payment
card accounts).

[0042]Storage device 304 may also store a database 316 that contains data
relating to transactions handled in the payment card system 100. In some
embodiments, the transaction database may take the form of a data
warehouse maintained in a separate computer (not separately shown) from
the payment card system operator computer 301. The data warehouse may
store, for each transaction cleared in the payment card system 100,
information such as the transaction amount, the payment card account
number for the payment card account to which the transaction was charged,
and the merchant identifier (or at least merchant classification) for
each transaction. In addition to this transaction information, the data
warehouse/transaction database 316 may include any and all transaction
data required for subsequent audit of the transactions cleared through
the payment card system 100.

[0043]Another database that may be stored in the storage device 304 is a
spending history database 318. The spending history database may contain
account-by-account cumulative purchase information compiled by the
account level record keeping program 312 from data stored in the
transaction database/data warehouse 316.

[0044]There may also be stored in storage device 304 other unshown
elements that may be necessary for operation of the payment card system
operator computer 301, such as an operating system, a database management
system, communication software, other applications, other data files,
device drivers, etc.

[0045]FIG. 4 is a block diagram of a typical one of the acquirer computers
104 shown in FIG. 1.

[0046]The hardware architecture of the typical acquirer computer 104, as
depicted in FIG. 4, may be conventional and may be the same as that of
the payment card system operator computer 301. Thus, the above
description of the hardware aspects of the payment card system operator
computer 301 is equally applicable to the hardware aspects of the
acquirer computer 104. Nevertheless, the following description is
provided to summarize the hardware components of the acquirer computer
104.

[0047]The acquirer computer 104 may include a processor 400 that is in
communication with a communication device 402, a storage device 404, an
input device 406 and an output device 408. The storage device 404 may
store an application program 410 that controls the acquirer computer 104
for purposes of handling transaction authorization requests received from
merchant processing systems 102. As will be understood by those who are
skilled in the art, the handling of authorization requests includes
relaying of the authorization requests to the issuer computers 108 via
the payment processing network 106. Also included in this function is
receiving authorization responses that originated from the issuer
computers 108 and that were received via the payment processing network
106, and relaying the authorization responses to the merchant processing
systems 102. In general, the handling of authorization requests and
responses by the acquirer computer 104 may be done in a conventional
manner. But further, and in accordance with aspects of the present
invention, the authorization responses, as received by the acquirer
computer 104 from the payment processing network 106, may include--at
least for some transactions--information (e.g., one or more data
elements) that indicate a spending history status or classification for
the payment card account to which the transaction is being charged. In
accordance with aspects of the present invention, the acquirer computer
104 may store the information relating to spending history for subsequent
use in determining what interchange rate applies for the transaction.

[0048]In addition, the storage device 404 may store an application program
412 which controls the acquirer computer 104 to handle clearing of
transactions submitted (e.g., in batches) by the merchant processing
systems 102. In part, the acquirer computer 104 may handle clearing
transactions in a conventional manner. However, in other respects, and in
particular in regard to determining interchange fees for transactions,
the acquirer computer 104 may function in accordance with aspects of the
present invention, by selecting the applicable interchange rate for the
transaction based on account spending history, as described in more
detail below in connection with FIGS. 7A and 7B.

[0049]Also stored in the storage device 404 is a transaction database 414,
in which the acquirer computer 104 stores information relating to
transactions handled by the acquirer computer 104. The transaction
database may store, for example, the spending history indications
provided by the payment processing network 106 (payment card system
operator computer 301) in the form of the above-mentioned data
element(s).

[0050]In addition, the storage device 404 may store a database 416 of
interchange rates and the requirements for selection of the interchange
rates for application to a particular transaction.

[0051]Moreover, the storage device 404 may store other programs, such as
one or more operating systems, device drivers, web hosting software,
communication software, etc., and may also store one or more other
databases.

[0052]The other computers referred to above in connection with FIG. 1 may
be conventional in terms of their hardware aspects and thus may be
similar in hardware architecture to the payment card system operator
computer 301 depicted in FIG. 3. Also, in at least some aspects of their
operations, the components other than the payment card system operator
computer 301 and the acquirer computers 104 may operate in a conventional
manner for providing a payment card system.

[0053]FIG. 5 is a flow chart that illustrates a process performed in
accordance with aspects of the present invention by the payment card
system operator computer 301.

[0054]At block 502, the payment card system operator computer 301 receives
and stores data (e.g., transaction clearing data) relating to
transactions handled in the payment card system 100. This data may, for
example, be stored in the above-mentioned data warehouse/transaction
database 316. In addition at block 502, the payment card system operator
computer 301 processes and/or aggregates the transaction data on an
account-by-account basis to generate spending history information for
each payment card account in the payment card system 100 (or for each
account in a group of payment card accounts for which dynamic interchange
rate setting is to be applied).

[0055]In some embodiments, the compilation of spending history information
is done for each payment card account of a certain card product type or
one or more card product types issued by one or more issuers. For
example, in some embodiments, only a certain type of premium card
product, such as a "platinum" level credit card account, is made subject
to dynamic interchange rate setting.

[0056]In some embodiments, the spending history compiled for a given
payment card account that is subject to dynamic interchange rate setting
consists simply of the total aggregate figure for purchases by the
account during the last 12 months prior to the date on which the
compilation was performed. In some embodiments, the compilation may be
performed immediately prior to the beginning of each calendar quarter for
the purpose of setting an interchange rate or rates for the particular
payment card account for the ensuing calendar quarter.

[0057]In other embodiments, aggregate spending figures may also or
alternatively be compiled each quarter for the prior 12 months for each
of a number of different categories of merchant patronized by the
cardholder, and/or for one or more specific merchants patronized by the
cardholder.

[0058]In other embodiments, the spending history may be compiled for a
time interval that is more or less than 12 months, and/or with a
frequency that is greater or less than quarterly. For example, the
spending history may be compiled for any period of 30 days or longer.

[0059]At 504 in FIG. 5, the payment card system operator computer 301
handles purchase transactions in the payment card system 100. This may
entail conventional routing of authorization requests and responses
between acquirer computers 104 and issuer computers 108. In addition, the
payment card system operator computer 301 may look up the spending
history status/classification for the payment card accounts in question,
and may insert information accordingly in authorization responses for
transmission to the acquirer computers 104, as described below in
connection with FIG. 6.

[0060]As indicated by process flow path 506, purchase transaction data
generated in connection with the transactions handled at step 504 is
subject to being stored and periodically aggregated in future iterations
of step 502, and step 504 may accordingly be reiterated as well.

[0061]FIG. 6 is a flow chart that illustrates aspects of a transaction
handling process that may be performed in accordance with aspects of the
present invention by the payment card system operator computer 301.

[0062]At decision block 602 in FIG. 6, the payment card system operator
computer 301 determines whether it has received an authorization response
from an issuer computer 108. As will be understood by those who are
skilled in the art, this may occur after the payment card system operator
computer 301 had received an authorization request transmitted from an
acquirer computer 104 and had routed the authorization request to the
issuer computer 108. (The authorization request may have been in a
conventional form, including the amount of the transaction and a payment
card account number that identifies the payment card account to which the
transaction is to be charged.) If no authorization response is received
by the payment card system operator computer 301, then the process of
FIG. 6 idles, as indicated by branch 604 from decision block 602.
However, for present purposes it is assumed that the authorization
response is received by the payment card system operator computer 301
(and it is further assumed that the authorization response indicates that
the transaction has been authorized by the issuer). Based on these
assumptions, the process of FIG. 6 advances from decision block 602 to
decision block 606.

[0063]At decision block 606, the payment card system operator computer 301
determines whether the current transaction (i.e., the transaction which
is the subject of the authorization response) is one for which selection
of the interchange rate is dependent on the spending history associated
with the payment card account to which the transaction is being charged.
For example, in some embodiments, the payment card system operator
computer 301 may make this determination based on a portion of the
payment card account number which indicates the card product under which
the account was issued. That is, according to an interchange rate
structure that may be established by the payment card system operator,
dynamic interchange rate setting, based on account spending history, may
be applicable to one or more card product types sponsored by the payment
card system operator. For accounts issued under those products, the
interchange rates applicable to transactions on those accounts vary
dynamically according to the spending history associated with each
account. For example, such card products may be identified by the "BIN
number", which is the first eight digits of the payment card account
number.

[0064]Assuming that the payment card account to which the transaction is
being charged is one for which dynamic interchange rate setting applies,
then the process of FIG. 6 advances from decision block 606 to block 608.
At 608 the payment card system operator computer 301 accesses the
spending database 318 (FIG. 3) and more specifically, accesses the record
in that database for the payment card account in question. Then, at 610,
the payment card system operator computer 301 determines the currently
applicable spending level for the account. This may be indicated by a
suitable flag in the spending database record for the account. In some
embodiments, for example, the flag may simply indicate whether, in a
prior 12 month period (perhaps ending at the beginning of the current
calendar quarter) there has been at least $50,000 of spending in the
account. In other embodiments, the flag may indicate that the spending
level was at a low, medium, high or premium level of activity. Other
types of classifications of the account's spending history are possible.

[0065]Block 612 follows block 610. At block 612, and based on the
determination made at 610, the payment card system operator computer 301
inserts into the authorization response an indication as to the spending
history level or classification that is currently effective for the
payment card account in question. Then, at 614, the payment card system
operator computer 301 transmits the authorization response to the
acquirer computer 104, with the spending history indication included in
the authorization response. (It will be understood that the particular
acquirer computer 104 to which the authorization response is sent by the
payment card system operator computer 301 is the acquirer computer that
sent the authorization request that prompted the authorization response.)

[0066]Considering again decision block 606, if the payment card system
operator computer 301 determines that dynamic interchange rate setting is
not applicable for the payment card account in question, then the process
of FIG. 6 advances directly from decision block 606 to block 614, without
any indication as to spending history level or classification having been
inserted into the authorization response.

[0067]FIGS. 7A and 7B together form a flow chart that illustrates a
process that may be performed in accordance with aspects of the present
invention by an acquirer computer 104.

[0068]At 702 in FIG. 7A, the acquirer computer 104 determines whether it
has received an authorization response from the payment processing
network 106. If no authorization response is received by the acquirer
computer 104, then the process of FIGS. 7A and 7B idles, as indicated by
branch 704 from decision block 702. However (as in the discussion of
block 602, FIG. 6) it is assumed that the authorization response is
received and that it indicates that the transaction is authorized. Based
on these assumptions, the process of FIGS. 7A and 7B advances from
decision block 702 to decision block 706.

[0069]At decision block 706, the acquirer computer 104 determines whether
the authorization response contains an indication as to the spending
history status/level for the payment card account in question. If so,
then block 708 follows decision block 706. At block 708, the acquirer
computer 104 stores the account spending level indication as data that is
relevant to interchange rate selection for the current transaction. This
data may, for example, be stored in the transaction database 414 (FIG.
4).

[0070]Continuing to refer to FIG. 7A, if the acquirer computer 104
determines at decision block 706 that the authorization response received
from the payment processing network 106 does not include a spending
history indication, then block 708 is skipped. In either case, the
acquirer computer 104 may thereafter proceed to relay the authorization
response to the merchant processing system 102 which sent the
authorization request so that the transaction can be completed.

[0071]Thereafter, as indicated by ellipsis 710 in FIG. 7A, a clearing
process 712 takes place for the transaction, in response to the merchant
processing system 102 submitting the transaction to the acquirer computer
104 as part of a clearing file. As part of the clearing process, the
acquirer computer 104 determines what the interchange fee is to be for
the transaction; and as a part of that function, the acquirer computer
104 determines what interchange rate from a list or database of
interchange rates is applicable to the transaction. Still more
specifically, and as indicated by decision block 714 (in accordance with
aspects of the present invention), the acquirer computer 104 determines
whether the applicable interchange rate for the transaction depends on a
spending history level or status that is associated with the payment card
account to which the transaction is being charged. This determination
may, for example, be made by accessing information in the interchange
rate database 416 (FIG. 4).

[0072]Continuing to refer to FIG. 7A, if a positive determination is made
at decision block 714 (i.e., if the acquirer computer 104 determines that
the applicable interchange rate is dependent on a spending history level
or classification associated with the account in question), then block
716 follows decision block 714. At block 716, the acquirer computer 104
selects the interchange rate that is to be applied to the transaction
based on the spending history information stored for the transaction at
block 708. The selection of the interchange rate may also be based on
other factors, including conventional factors such as the merchant
category, the time elapsed since authorization, the card product type,
the amount of the transaction, etc.

[0073]Considering again decision block 714, if a negative determination is
made at that decision block, then block 718 follows decision block 714.
At block 718, the acquirer computer 104 selects the applicable
interchange rate for the transaction in a conventional manner, i.e.,
based on conventional factors and not based on a spending history level
or classification associated with the payment card account to which the
transaction is being charged.

[0074]Following either block 716 or block 718, as the case may be, is
block 720 (FIG. 7B). At block 720, the acquirer computer 104 calculates
the interchange fee for the transaction based on the interchange rate
selected at block 716 or block 718. The resulting interchange fee then is
included in the clearing of the transaction, as an amount held back by
the issuer from the transaction amount transferred to the acquirer during
clearing. Inclusion of the transaction in the clearing file submitted for
clearing by the acquirer computer 104 is indicated at block 722, and the
clearing process then continues in a conventional manner, as represented
by block 724.

[0075]In some embodiments of the invention, a different interchange rate
may be applied to transactions effected with "high spending" accounts
(according to how the threshold would be defined than for similar
transactions charged to lower spending accounts of the same type of card
product. For example, an interchange rate of 2.3% could be applicable to
the former category of transactions, with an interchange rate of 2.0%
applicable to the latter category of transactions.

[0076]With a dynamic interchange setting mechanism as described in the
preceding paragraph, issuers automatically receive the benefits of a
higher interchange rate for transactions undertaken by high-spending
payment card accounts, without the issuers being required to change the
card product issued to the high-spending cardholders. This feature
rewards issuers for increasing the value of the network, including for
merchants, by attracting high-spending cardholders and for promoting use
of the cards issued to those cardholders. This may give issuers
incentives to enhance rewards programs for the high-spending cardholders,
and may also provide incentives for the issuers to promote and issue
premium card products.

[0077]Further, the increased interchange rate applied to purchases by
high-spending individuals may be more attractive to merchants because of
the increased revenues they stand to gain by having the high-spending
cardholders as their customers.

[0078]According to aspects of the invention, the spending history upon
which the determination of an interchange rate depends may be for an
individual payment card account or for a group of payment card accounts,
such as all accounts held within a household or all accounts held by a
group of business partners. A spending history should be understood to be
"associated with" a payment card account if the spending history in
question reflects spending by the payment card account in question or by
a group of payment card accounts that includes the payment card account
in question. A spending history used to determine an applicable
interchange rate may be based on total spending by an account or group of
accounts, or may be based on a subset of total spending, such as spending
with a particular merchant or category of merchants or by industry.

[0079]According to aspects of the present invention, spending histories
may be compiled based on periods of time of different durations than a
12-month period. Spending histories may be compiled with a frequency
other than quarterly. It will be understood that "quarterly" refers to
performing a function at a timing that corresponds to calendar quarters.

[0080]Principles of the present invention are applicable to business and
fleet payment card accounts as well as to payment card accounts used
primarily for personal, family or household purposes.

[0081]In embodiments described above, the acquirer is provided with the
spending history indication via an authorization response. Alternatively,
however, a message from the payment card system operator other than the
authorization response may be used to provide the spending history
indication to the acquirer.

[0082]The above description and/or the accompanying drawings are not meant
to imply a fixed order or sequence of steps for any process referred to
herein; rather any process may be performed in any order that is
practicable, including but not limited to simultaneous performance of
steps indicated as sequential.

[0083]Those who are skilled in the art will appreciate the distinction
between an "interchange fee" and an "interchange rate". The former is a
dollar amount of a fee that is charged to an acquirer for a particular
transaction and is calculated by applying the latter (the "interchange
rate") to the transaction amount (in the case where the interchange rate
is at least partially expressed in percentage terms). Thus the
interchange rate may be at least partially expressed in terms of
"percentage points", where for example 1.7% is 1.7 percentage points,
1.9% is 1.9 percentage points, etc., and 1.7 is a different number of
percentage points from 1.9.

[0084]It will also be understood that "transaction amount" refers to the
dollar (or other currency) amount that is to be charged to a payment card
account in connection with a particular purchase or other transaction in
a payment card system.

[0085]The terms "payment card account" and "payment account" may be used
interchangeably herein. Also, the term "payment transaction" may be used
as a synonym for a purchase or other transaction carried out in a payment
card system. A payment card account number is an example of a payment
account identifier.

[0086]As used herein and in the appended claims, the term "payment card
system account" includes: (i) a credit card account or (ii) a deposit
account that the account holder may access using a debit card. The terms
"payment card system account" and "payment card account" are used
interchangeably herein. The term "payment card account number" includes a
number that identifies a payment card system account or a number carried
by a payment card, or a number that is used to route a transaction in a
payment system that handles debit card and/or credit card transactions.
The term "payment card" includes a credit card, debit card, stored value
card, prepaid card, charge card, corporate card, fleet card, or any
similar device or number used by cardholders in connection with payment
transactions.

[0087]As used herein and in the appended claims, the term "payment card
system" refers to a system for handling purchase transactions and related
transactions and operated under the name of MasterCard, Visa, American
Express, Diners Club, Discover Card or a similar system. In some
embodiments, the term "payment card system" may be limited to systems in
which member financial institutions issue payment card accounts to
individuals, businesses and/or other organizations.

[0088]As used herein and in the appended claims, the term "computer"
should be understood to encompass a single computer or two or more
computers in communication with each other.

[0089]As used herein and in the appended claims, the term "processor"
should be understood to encompass a single processor or two or more
processors in communication with each other.

[0090]As used herein and in the appended claims, the term "memory" should
be understood to encompass a single memory or storage device or two or
more memories or storage devices.

[0091]Although the present invention has been described in connection with
specific exemplary embodiments, it should be understood that various
changes, substitutions, and alterations apparent to those skilled in the
art can be made to the disclosed embodiments without departing from the
spirit and scope of the invention as set forth in the appended claims.