U.S. patent application number 12/574822 was filed with the patent office on 2010-04-08 for method and apparatus for dynamic interchange pricing.
Invention is credited to James Carrington, Steven J. Jonas, Anant Nambiar, Denise Torreyson.
Application Number | 20100088204 12/574822 |
Document ID | / |
Family ID | 42076533 |
Filed Date | 2010-04-08 |
United States Patent
Application |
20100088204 |
Kind Code |
A1 |
Nambiar; Anant ; et
al. |
April 8, 2010 |
METHOD AND APPARATUS FOR DYNAMIC INTERCHANGE PRICING
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.
Inventors: |
Nambiar; Anant; (Larchmont,
NY) ; Carrington; James; (Larchmont, NY) ;
Torreyson; Denise; (Elmsford, NY) ; Jonas; Steven
J.; (Westport, CT) |
Correspondence
Address: |
BUCKLEY, MASCHOFF & TALWALKAR LLC
50 LOCUST AVENUE
NEW CANAAN
CT
06840
US
|
Family ID: |
42076533 |
Appl. No.: |
12/574822 |
Filed: |
October 7, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61103279 |
Oct 7, 2008 |
|
|
|
Current U.S.
Class: |
705/30 ; 235/380;
705/400; 705/44 |
Current CPC
Class: |
G06K 15/1882 20130101;
G06Q 20/40 20130101; G06Q 20/4016 20130101; G06Q 30/02 20130101;
G06Q 30/0213 20130101; G06Q 20/04 20130101; G06Q 20/405 20130101;
G06Q 2250/10 20130101; G06Q 20/24 20130101; G06Q 30/0283 20130101;
G06Q 40/12 20131203 |
Class at
Publication: |
705/30 ; 235/380;
705/400; 705/44 |
International
Class: |
G06Q 20/00 20060101
G06Q020/00; G06K 5/00 20060101 G06K005/00; G06Q 10/00 20060101
G06Q010/00; G06Q 30/00 20060101 G06Q030/00 |
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; and providing 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; and transmitting 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; and a 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; and include 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; and the 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; and the 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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of provisional patent
application Ser. No. 61/103,279, filed Oct. 7, 2008, which is
incorporated herein by reference.
BACKGROUND
[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.
* * * * *