U.S. patent application number 11/943062 was filed with the patent office on 2008-03-13 for method and system for conducting secure payments over a computer network.
Invention is credited to Carl M. Campbell, Edward J. Hogan.
Application Number | 20080065554 11/943062 |
Document ID | / |
Family ID | 26891523 |
Filed Date | 2008-03-13 |
United States Patent
Application |
20080065554 |
Kind Code |
A1 |
Hogan; Edward J. ; et
al. |
March 13, 2008 |
METHOD AND SYSTEM FOR CONDUCTING SECURE PAYMENTS OVER A COMPUTER
NETWORK
Abstract
A method is provided for conducting a financial transaction by a
purchaser with a merchant having an acquirer bank, over a
communications network. The method includes the steps of sending a
first authorization request using a pseudo account number
associated with a real account number to a service provider which
forwards a second authorization request to the issuer using the
real account number and preferably a pseudo acquirer code
associated with the service provider such that the response to the
second request is based on the real account number and sent back to
the service provider who preferably forwards a response to the
first request preferably to the "real" acquirer. A message
authentication code is further provided which includes transaction
data, and where the authorization request is formatted as a
standard payment card track having one or more fields including a
discretionary field in which the message authentication code is
placed.
Inventors: |
Hogan; Edward J.;
(Larchmont, NY) ; Campbell; Carl M.; (Newtown
Square, PA) |
Correspondence
Address: |
BAKER BOTTS L.L.P.
30 ROCKEFELLER PLAZA
44TH FLOOR
NEW YORK
NY
10112-4498
US
|
Family ID: |
26891523 |
Appl. No.: |
11/943062 |
Filed: |
November 20, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09833049 |
Apr 11, 2001 |
|
|
|
11943062 |
Nov 20, 2007 |
|
|
|
60195963 |
Apr 11, 2000 |
|
|
|
Current U.S.
Class: |
705/64 ;
705/44 |
Current CPC
Class: |
G07F 7/08 20130101; G06Q
30/06 20130101; G06Q 20/04 20130101; G06Q 20/403 20130101; G06Q
20/3823 20130101; G06Q 20/3825 20130101; G07F 7/122 20130101; G06Q
20/3829 20130101; G06Q 20/385 20130101; G06Q 20/24 20130101; G06Q
20/14 20130101; G06Q 20/382 20130101; G06Q 20/40 20130101; G06Q
20/102 20130101; G07F 7/12 20130101; G06Q 20/4014 20130101; G06Q
20/02 20130101 |
Class at
Publication: |
705/064 ;
705/044 |
International
Class: |
G06Q 20/00 20060101
G06Q020/00; H04K 1/00 20060101 H04K001/00; H04L 9/00 20060101
H04L009/00 |
Claims
1. A method of conducting a transaction involving a merchant over
an electronic payment network, the method comprising: receiving
data related to the transaction from the merchant; computing a
message authentication code based on the data related to the
transaction; placing the message authentication code in a portion
of the discretionary data field of a standard payment card magnetic
stripe track format to form a track image; and transmitting the
track image including the message authentication code, over the
payment network, before or without first storing the message
authentication code on a magnetic stripe of a payment card.
2. The method of claim 1, wherein computing a message
authentication code results in binary data, further comprising
truncating and converting the message authentication code to
decimal digits.
3. The method of claim 1, wherein computing a message
authentication code is further based on a transaction sequence
number.
4. The method of claim 3, further comprising inserting at least a
portion of the transaction sequence number in a portion of the
discretionary data field of the track image, and wherein
transmitting the track image further includes transmitting at least
the portion of the transaction sequence number over the payment
network.
5. The method of claim 4, further comprising inserting a payment
account number in a payment account number field of the standard
payment card magnetic stripe track format image, wherein
transmitting the track image further includes transmitting the
payment account number over the payment network.
6. The method of claim 5, further comprising providing a
card-unique secret key calculated using at least a derivation key
and the payment account number, wherein computing the message
authentication code comprises applying the card-unique secret key
to the transaction sequence number and the data related to the
transaction to compute the message authentication code.
7. An apparatus for conducting a transaction involving a cardholder
and merchant having a merchant device over an electronic payment
network, the apparatus comprising: a cardholder memory device
containing at least a card-unique secret key; a receiver module
capable of receiving data from the merchant device related to the
transaction; a message authentication code calculator coupled to
the receiver module and the cardholder memory device for
calculating a message authentication code using at least the data
related to the transaction received from the merchant device and
the secret key; a track image data formatter coupled to the message
authentication code calculator for placing at least a portion of
the message authentication code in a portion of the discretionary
data field of a track image data formatted as a standard payment
card magnetic stripe data track; a transmitter coupled to the track
image data formatter for transmitting the track image data
formatted as a standard payment card magnetic stripe data track to
the merchant device for subsequent transmission over the payment
network before or without first storing the message authentication
code on a magnetic stripe of a payment card.
8. The apparatus of claim 7, wherein the message authentication
code calculator further includes a decimalization module for
truncating and converting the message authentication code to a
shortened decimal digit representation.
9. The apparatus of claim 7, wherein the cardholder memory device
additionally has a transaction sequence number, and wherein the
message authentication code calculator is further configured to
compute the message authentication code based on the transaction
sequence number.
10. The apparatus of claim 9, wherein the track image data
formatter is further configured to insert at least a portion of the
transaction sequence number in a portion of the discretionary data
field of the track image data formatted as a standard payment card
magnetic stripe data track.
11. The apparatus of claim 10, wherein the cardholder memory device
additionally stores a payment account number, and wherein the track
image data formatter is further configured to insert the payment
account number in a payment account number field of the track image
data formatted as a standard payment card magnetic stripe data
track.
12. The apparatus of claim 10, wherein the message authentication
code calculator is configured to compute a message authentication
code by applying the card-unique secret key to the transaction
sequence number and the data related to the transaction.
13. The apparatus of claim 7, further comprising a processor,
wherein the message authentication code calculator and the track
image data formatter are implemented within the processor.
Description
RELATED APPLICATIONS
[0001] This application is a divisional of U.S. patent Ser. No.
09/833,049 filed Apr. 11, 2001 which claims priority to U.S.
provisional application 60/195,963, filed on Apr. 11, 2000, and
entitled "Method and System for Conducting Secure Payments Over A
Computer Network," which is hereby incorporated by reference, and
to U.S. application Ser. No. 09/809,367, filed Mar. 15, 2001, and
entitled "Method and System for Secure Payments Over A Computer
Network," also incorporated by reference.
BACKGROUND OF INVENTION
[0002] This invention relates to a method and system for conducting
secure financial transactions over a communications network and
more particularly to a method and system for transmitting payments
securely over a computer network, such as the Internet, and for
transmitting sensitive information securely over public
communication channels.
[0003] As is self-evident, on-line commerce has experienced
tremendous growth over the last few years but even with that growth
consumers are still troubled and concerned about using personal
financial information and transmitting such information, such as
credit card numbers and personal identification numbers, over
public communications networks, such as the Internet. As a result,
over the last few years, companies have struggled to find a
way--the best way--to ensure the security of payments made over a
computer network and to decrease the risk of theft or misuse of
financial information.
[0004] For example, U.S. Pat. No. 5,883,810 entitled "Electronic
Online Commerce Card With Transaction Proxy Number For Online
Transactions" and assigned to Microsoft Corporation, is directed to
a system which provides for each transaction a temporary
transaction number and associates it with the permanent account
number; the transaction number looks like a real credit card number
and the customer uses that transaction number and submits it to the
merchant as a proxy for the customer account number. In this
matter, the customer does not have to transmit over a public
network his or her real credit card number.
[0005] In the '810 patent, the merchant passes along the
transaction number to the issuing institution, which in turn uses
the transaction number as an index, accesses the real customer
account number and processes the authorization, sending the
authorization reply back to the merchant under the transaction
number. As a result, risk is purportedly minimized not only because
the customer only transmits a transaction number but also because
the proxy number is good only for a single purchase--theft "would
not greatly benefit a thief because it cannot be repeatedly used
for other purchases or transactions." Col. 2, lines 60-61.
[0006] There is a need to improve upon the prior art systems and in
particular there is a need for a method and system for conducting a
secure financial transaction over the Internet which avoids
requiring the creation and transmission of a unique repeatedly
generated transaction number to replace the transmission of the
permanent account number for each conducted transaction.
[0007] According to the invention of co-pending application Ser.
No. 09/809,367, filed Mar. 15, 2001, which is incorporated herein
by reference, a "pseudo" account number is assigned to a customer
and cryptographically linked to a consumer's payment account
number. The payment account number is an account number issued by a
financial institution or other organization that a consumer may use
to make a payment for goods and/or services. For example, the
payment account number may be the account number from a payment
card, such as a credit or debit card, or from a payment
application, such as an electronic cash application stored on a
consumer's computer. The pseudo account number appears to be an
actual payment account number to a merchant. That is, the pseudo
account number has the same length as a valid payment account
number and begins with a valid identification number (e.g., a "5"
for MasterCard International Incorporated ("MasterCard")). The
pseudo account number is used by the customer instead of the real
account number for all of his or her on-line financial
transactions.
[0008] According to the invention of the co-pending application
Ser. No. 09/809,367, all transactions based on pseudo account
numbers are preferably cryptographically authenticated using a
secret key that is unique for each account number. The
authentication may be based on the private key of a public-key pair
("public-key authentication"), or based on a secret key other than
a private key ("secret-key authentication"). Thus, if unauthorized
persons were to ascertain any pseudo account numbers, they would be
unable to make fraudulent transactions using them.
[0009] This system can still be improved upon and security can be
further enhanced to protect the messages and information being
transmitted during or in connection with a financial transaction
being conducted over public communications lines.
SUMMARY OF INVENTION
[0010] According to the present invention, therefore, a method of
conducting a transaction using a payment network is provided, in
which a service provider receives a first authorization request for
the authorization of a transaction using a first payment account
number, wherein: [0011] (i) the first payment account number has a
BIN code associated with the service provider, and is associated
with a second payment account number having a BIN code associated
with an issuer of said second number; [0012] (ii) the first
authorization request includes an acquirer code associated with an
acquirer; and [0013] (iii) the first authorization request is
routable through the payment network to the service provider based
on the BIN code of the first payment account number.
[0014] The method further includes having the service provider
respond to the first authorization request by transmitting a second
authorization request for authorization of the transaction using
the second payment account number, the second authorization request
including an acquirer code associated with the service provider and
being routable through the payment network to the issuer based on
the BIN code of the second payment account number.
[0015] Additionally, a response to the second authorization request
is received by the service provider from the issuer, where the
response includes the acquirer code associated with the service
provider and is routable through the payment network based on that
code. A response to the first authorization request is then
transmitted by the service provider to the acquirer based on the
response to the second authorization request, and the response to
the first authorization request preferably includes the acquirer
code associated with the acquirer and is routable through the
payment network based on that code.
[0016] Another preferred embodiment of the invention includes a
method of conducting a transaction with a merchant using a first
payment account number that is associated with a second payment
account number, where the method comprises: (a) generating a
message authentication code based on one or more transaction
details; (b) transmitting at least the first payment account number
and the message authentication code to the merchant; (c) requesting
by the merchant an authorization for payment of the transaction
using the first payment account number, the request being formatted
as if payment were tendered at a point-of-sale terminal with a
conventional magnetic-stripe payment card, the message
authentication code being transmitted in a discretionary data field
contained in a track of the type used in the magnetic stripe of
said conventional payment card; (d) responding to the authorization
request for the first payment account number by requesting an
authorization for payment of the transaction using the associated
second payment account number; and (e) accepting or declining the
authorization request for the first payment account number based on
the response to the authorization request for the second payment
account number and the message authentication code.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Further objects, features and advantages of the invention
will become apparent from the following detailed description taken
in conjunction with the accompanying figures showing a preferred
embodiment of the invention, on which:
[0018] FIG. 1 is a block diagram of the system for obtaining a
secure payment application from a provider over the Internet in
accordance with the invention;
[0019] FIG. 2 is a flow diagram illustrating the flow of
information between a cardholder and a merchant when conducting a
secure payment over the Internet using the present invention;
[0020] FIG. 3 is a flow diagram illustrating the flow of
information between an acquirer, a service provider and an issuer,
in accordance with the present invention;
[0021] FIG. 4 is a flow diagram illustrating the flow of
information between an issuer, a service provider and an acquirer,
in accordance with the present invention;
[0022] FIG. 5 is a flow diagram illustrating the flow of
communication between a merchant and an acquirer for purposes of
settlement and clearing, in accordance with the present
invention;
[0023] Throughout the figures, the same reference numerals and
characters, unless otherwise stated, are used to denote like
features, elements, components or portions of the illustrated
embodiment. Moreover, while the subject invention will now be
described in detail with reference to the figures, it is done so in
connection with a preferred embodiment. It is intended that changes
and modifications can be made to the described embodiment without
departing from the true scope and spirit of the subject invention
as defined by the appended claims.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Initialization of the Secure Payment Application
[0024] In accordance with a preferred embodiment of the invention,
a service provider issues, maintains and/or processes several
components, including a secure payment application ("SPA"), of the
secure payment system to be conducted in accordance with the
techniques of the present invention.
[0025] FIG. 1 illustrates first how a cardholder with a financial
transaction card may obtain a secure payment application from the
service provider 10 over the Internet, according to an exemplary
embodiment of the present invention. It should initially be
understood that a physical card is not necessary to utilize and
obtain the benefits of the invention, but that only an account
number be issued to a holder (in this case a cardholder) which
identifies and links a user or participant to an account for
purposes of conducting a financial transaction. The cardholder may
contact a web server associated with the service provider using any
appropriate device that may communicate over the Internet, such as
a computer, cellular phone, or a personal digital assistant (PDA).
For the purpose of simplicity in the following discussions, it is
assumed that the cardholder uses a computer to communicate over the
Internet.
[0026] As shown in FIG. 1, the service provider, for example
MasterCard International Incorporated (or an agent of MasterCard),
has in its control one or more physically secure security modules
12, which offer physical protection for the information stored
inside the modules. These security modules each contain one or more
"derivation keys" that are used to create and re-create
account-unique secret cryptographic keys, as explained below, which
are provided within the secure payment application.
[0027] First, in accordance with a preferred embodiment of the
invention, the cardholder must obtain an SPA from the service
provider. The preferable steps for downloading and initializing the
secure payment application (SPA) include: [0028] 1. The cardholder
contacts the service provider's web site via the Internet (either
directly or through a hyperlink to the web site through another web
site, such as an issuer's web site. [0029] 2. The cardholder
provides, under SSL encryption generally known to those skilled in
the art, (a) a payment card account number, (b) a card expiration
date, and (c) card authenticating information. The card
authenticating information may include, for example, the card's
CVC2 value, which refers to a three or four digit value that is
printed next to the signature panel of some cards. This value is
generated by the issuing bank using a secret cryptographic key and
can be verified using this same key. [0030] 3. The service provider
may confirm the legitimacy of the card account number and the card
expiration date by obtaining a zero amount authorization from the
issuer of the cardholder's payment card. For instance, MasterCard
may obtain this authorization over its Banknet.TM. communications
network. [0031] 4. The service provider may verify the CVC2 value
if the issuer of the cardholder's payment card has provided the
service provider with the cryptographic key(s) for verifying the
CVC2 value. [0032] 5. The service provider may verify other card
authenticating information by sending such information to the
issuer for verification. [0033] 6. After the service provider
("SP") has confirmed the legitimacy of the cardholder-provided card
data, the SP creates or selects a pseudo account number and a
secret key and embeds these data elements into a secure payment
software application that is made available to the cardholder for
download over the Internet preferably under SSL encryption.
[0034] The pseudo account number has as its BIN a special BIN
reserved for pseudo account numbers. The remainder of the pseudo
account number is a value that can be translated by the service
provider via a table look-up process to the "real" account
number.
[0035] Preferably, the assigned special service provider BIN may be
one from a set of many such special BINs, where each BIN may
correspond to a particular country or region and/or to a particular
product within a country or region. Thus, the assigned special BIN
may be the one that corresponds to the country and/or the product
of the submitted "real" account number.
[0036] The secret key that the service provides preferably embeds
in an SPA is unique for each card account number and is preferably
derived within a security module using the card account number and
a derivation key. This derivation key may itself be derived within
the same or another security module using a higher-level derivation
key.
[0037] The cardholder may provide a password to the service
provider prior to downloading the secure payment application or may
select a password when the secure payment application is being
installed on the cardholder's computer. If a password is provided
or selected, the cardholder will thereafter be required to enter
this password in order to activate the secure payment application.
The password selected by the cardholder may be used to encrypt the
secret key included in the SPA.
[0038] As would be recognized by those skilled in the art, the SPA
may be downloaded as part of a digital wallet application. In
addition to the SPA, the digital wallet may store a cardholder's
personal information and other applications, such as a purse
application.
Generating Card-Unique Secret Keys
[0039] The following steps may preferably be performed within a
security module 12 controlled by the service provider or one of its
agents to obtain a card-unique secret key to be included in the
secure payment application. The following steps assume that the
cardholder's payment card has a 16-digit account number and that
the Data Encryption Algorithm (DEA) known to those skilled in the
art, with a double-length key is used. The DEA is a U.S. Government
standard cryptographic algorithm that is described in Federal
Information Processing Standard (FIPS) 46-1, which is incorporated
herein by reference in its entirety. The DEA is also defined in the
ANSI standard X9.32, which is also incorporated herein by reference
in its entirety.
[0040] It is also assumed that the security module holds a secret
high-level key called the derivation key that consists of 16 bytes
and is used with many or all card account numbers to
cryptographically compute a card-unique secret key, called the
Per-Card Key, given the cardholder's 16-digit payment account
number. The derivation key may be unique for each country or for
each special bank identification number or BIN.
[0041] Preferably, the steps are: [0042] 1. Considering the payment
account number as 16 binary-coded-decimal digits of 4 bits each,
DEA-encrypt these 64 bits using as the encryption key the left-most
8 bytes of the 16-byte Derivation Key. [0043] 2. DEA-decrypt the
result of Step 1 using as the decryption key the right-most 8 bytes
of the 16-byte Derivation Key. [0044] 3. DEA-encrypt the result of
Step 2 using as the encryption key (again) the left-most 8 bytes of
the 16-byte Derivation Key. [0045] 4. Use the result of Step 3 as
the left-most 8 bytes of the unique Per-Card Key. [0046] 5.
DEA-encrypt the result of Step 3 using as the encryption key the
left-most 8 bytes of the 16-byte Derivation Key. [0047] 6.
DEA-decrypt the result of Step 5 using as the decryption key the
right-most 8 bytes of the 16-byte Derivation Key. [0048] 7.
DEA-encrypt the result of Step 6 using as the encryption key
(again) the left-most 8 bytes of the 16-byte Derivation Key. [0049]
8. Use the result of Step 7 as the right-most 8 bytes of the
16-byte unique Per-Card Key, and place this key in the secure
payment application in such a way that it will not be disclosed
during the normal operation of this application.
Communication Between Cardholder and Merchant
[0050] FIG. 2 illustrates the flow of information between the
cardholder 14 and merchant 16 when conducting a secure payment over
the Internet according to an exemplary embodiment of the present
invention.
[0051] Once the SPA has been installed on a cardholder's computer,
the cardholder preferably uses the SPA for all Internet payments
and the SPA provides the cardholder's pseudo account number for all
Internet transactions.
[0052] Once a cardholder has indicated a desire to conduct a
transaction, it is desirable (but not essential) that the merchant
pass to the cardholder's computer the following data elements: (1)
the acquirer BIN, (2) the MID (the merchant identifier as known to
the acquirer), and (3) the date and time (GMT or equivalent) of the
transaction.
[0053] Preferably, the SPA uses its embedded, secret key to create
a Message Authentication Code (MAC) relating to the transaction.
For example, a MAC of approximately 8 decimal digits may be created
on the following data elements: [0054] 1. A transaction sequence
number stored in the cardholder's SPA and incremented by the SPA
whenever it generates a MAC. This transaction sequence number may
be, for example, six (6) decimal-digits in length. [0055] 2. The
acquirer BIN if received from the merchant, otherwise zeros (which
may be, for example, 6 decimal digits). [0056] 3. The MID if
received from the merchant, otherwise zeros (which may be, for
example, 6 decimal digits). [0057] 4. Date and time, to the nearest
hour or minute (in GMT), if received from the merchant, otherwise
zeros (which may be, for example, 10 decimal digits). [0058] 5. The
transaction amount, as displayed for the cardholder, and as
normally included in the message from cardholder to merchant (which
may be, for example, 8 decimal digits).
[0059] Preferably, a merchant is able to accept a full Track-1
image from the cardholder's computer, just as if the merchant were
prepared to communicate with computers that include magnetic-stripe
readers. (The Track-1 image refers to the data on track 1 of the
magnetic stripe of a payment card.) Moreover, the merchant
preferably is able to pass the Track-1 data to the acquirer as if
the transaction were a point-of-sale (POS) transaction.
[0060] If the merchant can accept the full Track-1 data, the MAC
itself and the data elements upon which the MAC is based are placed
in the Track-1 discretionary-data field. The pseudo account number
is placed in the Track-1 account-number field, and the card
expiration date is placed in the Track-1 expiration-date field.
[0061] By sending the MAC in the Track-1 discretionary-data field,
many merchants will not need to make any changes to their systems
and/or software because they can already handle POS transactions,
which include Track-1 discretionary data. For other merchants,
systems and/or software to handle POS transactions are readily
available.
[0062] If a merchant cannot accept the full Track-1 data, the SPA
may send a conventional SSL payment message, except that the pseudo
account number is used instead of the cardholder's "real" account
number. The merchant then sends the transaction data to the
acquirer in the manner that it normally does. In practice, during a
transition period, the merchants that are not capable of handling
POS transactions with Track-1 data might not be required to receive
and handle MACs.
[0063] Instead of being sent in the Track-1 discretionary-data
field, the MAC may also be sent in another format, in which case
merchants and acquirers may be required to change their systems
and/or software to handle this other format.
[0064] Upon receipt of the cardholder's transaction message, the
merchant formats a conventional authorization request for the
acquirer. For those merchants that are able to able to accept
Track-1 data, this authorization request will be formatted exactly
as if it originated from a POS terminal and will include the
Track-1 data provided by the cardholder.
[0065] Should a merchant initiate multiple authorization/clearing
transactions for a cardholder transaction, preferably only the
first of these transactions will include the Track-1 data. The
subsequent transactions will include only the pseudo account number
and expiration date and may be considered
mail-order-telephone-order transactions. This is true for all
recurring payments and partial payments with multiple
clearings.
Acquirer Handling of Authorization Request
[0066] FIG. 3 illustrates the communication between an acquirer 18,
service provider 10, and an issuer according to an exemplary
embodiment of the present invention.
[0067] The presence of Track-1 data in an Internet transaction
should not adversely impact those acquirers who receive
transactions from Internet merchants via conventional telephone
lines, since such transactions will be formatted identically to
transactions from conventional point-of-sale terminals. However,
acquirers who receive transactions via the Internet (and not
conventional telephone) may need a "conversion box" that would
deliver transactions without Track-1 data unchanged and would
deliver transactions with Track-1 data over a different physical
wire as if they had come from POS terminals. The design of such a
conversion box is well within the ability of a person of ordinary
skill in the art.
[0068] When an acquirer 18 receives an authorization request
message from an Internet merchant 16, it looks up the issuer BIN in
its BIN table. In the case of a pseudo account number transaction,
the "issuer" will correspond to a service provider-authorized
processing facility 10, which will receive the request. In the case
of a non-pseudo or real account number, normal processing will take
place.
[0069] Some countries may have a special security-module-equipped
facility that handles domestic transactions. Each such domestic
facility would preferably be set up only with the service
provider's approval and would hold only the cryptographic keys and
account-number conversion data for the country whose transactions
it processes. In countries with such a domestic facility, all
same-country transactions will be sent to this facility. This can
also be done for individual banks in a country, if it is so
desired.
[0070] A domestic facility to handle domestic transactions would be
far more efficient than causing domestic transactions to go through
a central processing facility.
Service Provider Handling of the Authorization Request
[0071] When the service provider receives the request, it
determines from the issuer BIN whether the account number is really
a pseudo account number and, if so, sends the transaction to a
special system for processing. This system translates the pseudo
account number to the "real" account number using a table-lookup
procedure. If the system determines that a Track-1 image is
included, it uses a security module to derive the appropriate Per
Card Key for this card account number in order to verify the MAC.
(The derivation of the Per Card Key is described above.)
[0072] If the MAC is verified, the system then examines the BIN in
the Track-1 discretionary-data area. If this is not all zeros, the
system compares this BIN with the acquirer BIN of the transaction,
and verifies that the date and time included in the Track-1
discretionary-data area are reasonable (taking into consideration
that the merchant may batch its transactions and obtain delayed
authorizations). The system also verifies that the authorization
request amount does not exceed the transaction amount in the
Track-1 discretionary-data area (the amount as approved by the
cardholder) by more than a specified amount (e.g., 20%).
[0073] It is possible that an acquirer may include the MID in the
Acquirer Reference Data (which is also called the Acquirer
Reference Number). It is assumed that the 23-digit Acquirer
Reference Data includes a mandatory "transaction type" indicator
and a mandatory acquirer BIN, but that the remaining digits are for
the acquirer's discretionary use and may in some cases include the
MID. The service provider may obtain from its Internet acquirers an
indication of which acquirers include the MID in the Acquirer
Reference Data, and if so, where in the Acquirer Reference Data
they include it. In the case of such an acquirer, if the Track-1
image includes an acquirer BIN (rather than six zeros), the service
provider system may also verify that the MID in the Track-1
discretionary-data area matches the MID in the Acquirer Reference
Data.
[0074] The service provider system may store a history of
transaction sequence numbers (TSNs) for comparison with transaction
sequence numbers in authorization requests. The comparison may be
triggered by some condition, such as when the Track-1 amount
exceeds some specified threshold (e.g., $200). Such a threshold may
be lower when the Track-1 image does not include an acquirer BIN.
When the comparison is triggered, the system may compare the
transaction sequence number included in the Track-1
discretionary-data area against the stored history of transaction
sequence numbers for the relevant card account number. If the
transaction sequence number of the current transaction is 1) higher
than the smallest stored value for the current account number and
2) does not match any stored value for this account, there is a
reasonable assurance that the current transaction is not the
fraudulent replay of data from a previous legitimate
transaction.
[0075] The stored history of TSNs may be limited to a predetermined
number of TSNs. For example, the system might store only the last
10 transaction sequence numbers received for a particular card
account number. In addition, the verification of transaction
sequence numbers need not occur in real time. It may occur while
the system is obtaining an authorization from an issuer.
[0076] The purpose of these checks is to make it very difficult for
wrongdoers who operate in collusion with Internet merchants and who
may be able to obtain unencrypted transaction data to fraudulently
replay data from legitimate transactions.
[0077] Once the service provider system has completed the
above-described verification processes (with the possible exception
of the transaction sequence number verification), the system
formats an authorization request message for the issuer 20. This
message includes the "real" account number and expiration date, but
excludes the other Track-1 data. The system replaces the acquirer
BIN with one of the special BINs that serves as a "pseudo" acquirer
BIN. The acquirer BIN is replaced so that the issuer responds to
the service provider instead of the acquirer.
[0078] In order for the acquirer and issuer to compute interchange
fees correctly, the pseudo acquirer BIN should preferably
correspond to the country in which the acquirer is located or to
another country or region that will provide the same resultant
interchange fees. If each country has a special BIN associated with
it, the service provider may replace the acquirer BIN with the
special BIN associated with the acquirer's country. If an
acquirer's country does not have a special BIN associated with it,
a special BIN associated with another country may be selected that
results in the same interchange fees.
[0079] The service provider stores in a database the Acquirer
Reference Data received in the authorization request from the
acquirer (hereinafter referred to as the "original Acquirer
Reference Data"). In formatting an authorization message for the
issuer, the service provider preferably replaces the original
Acquirer Reference Data with "pseudo" Acquirer Reference Data that
includes the pseudo acquirer BIN, an appropriate transaction-type
indicator, and an index value that the service provider can use to
find the original Acquirer Reference Data.
[0080] When a domestic facility processes a pseudo-account-number
transaction, it operates as described above. Preferably, however,
this domestic facility will process only transactions for domestic
issuers, and therefore will need only the cryptographic keys and
account-number conversion table entries that apply to that
country.
Issuer Handling of Authorization Request
[0081] FIG. 4 illustrates the communication between the issuer 20,
the service provider 10, and an acquirer 18 according to an
exemplary embodiment of the present invention after the issuer has
received an authorization request from the service provider or from
an authorized domestic processing facility.
[0082] The issuer 20 authorizes the transaction just as it would
any other transaction. It sends the authorization response back to
the "pseudo" acquirer BIN, which will be either a service provider
facility or a facility authorized by a service provider.
[0083] When the service provider 10 receives an authorization
response from an issuer, it examines the acquirer BIN to determine
whether it is a "pseudo" acquirer BIN. If so, the service provider
determines that the authorization response corresponds to a pseudo
account number transaction that must be "restored" to its original
format. Thus, the service provider translates the "real" account
number back to the pseudo account number, and restores the Acquirer
Reference Data that had been in the original transaction. The
service provider then transmits the resulting message to the "real"
acquirer, which processes the transaction normally and sends the
authorization response to the merchant in the normal way. The
merchant responds to the authorization response as it would for any
other transaction.
Settlement and Clearing
[0084] FIG. 5 illustrates the flow of communication between a
merchant 16, an acquirer, service provider or payment processor,
for example, MasterCard's Banknet, and an issuer for the purpose of
settlement and clearing according to an exemplary embodiment of the
present invention.
[0085] A clearing message is processed essentially in the same
manner as an authorization request message. As previously
described, the acquirer 18 (because of entries in its BIN table)
automatically routes a clearing message using a pseudo account
number preferably to the service provider 10 or payment processor.
At this facility, the pseudo account number is replaced by the
"real" account number, the acquirer BIN is replaced by the "pseudo"
acquirer BIN, and the remainder of the Acquirer Reference Data is
replaced by an index that the service provider can subsequently use
to obtain the original Acquirer Reference Data. The clearing
message with these changes is transmitted to the "real" card issuer
20, which processes the transaction in the normal way. If the
acquirer happens to also be the issuer, the service provider
returns the cleared transaction to the acquirer with the real
account number and proper fee calculations.
Exception Processing
[0086] When a message about a transaction must be transmitted back
to the acquirer or merchant from an issuer, the message is
processed by the issuer as it normally would process any
transaction message. Since the transaction as known to the issuer
includes the "pseudo" acquirer BIN, the "pseudo" acquirer BIN will
cause the transaction message to be routed to a service provider
facility. At this facility the "real" account number is replaced by
the pseudo account number, and the pseudo Acquirer Reference Data
is replaced with the original Acquirer Reference Data. The
transaction message is then routed to the acquirer, which processes
it like any other such transaction message.
Issuance of Plastic Cards for Identification
[0087] In some situations, a cardholder may buy a ticket over the
Internet and will be required, upon showing up at the event to
which the ticket grants admission, to produce the card used in the
transaction in order to authenticate rightful possession of the
ticket.
[0088] To accommodate such situations, the service provider may
issue and mail physical plastic cards to cardholders who obtain
pseudo account numbers for Internet use. These cards would clearly
indicate "for identification purposes only, not valid for
transactions" on them. The embossed and encoded account number
would be the pseudo account number, though the CVC2 may be that of
the "real" payment card.
[0089] As another alternative, those merchants that have a
legitimate need to authenticate a cardholder using a pseudo account
number may register with the service provider (by providing to the
service provider appropriate identification and authentication
information), and the merchants will be provided with a secret key
or certificate as cryptographic proof of their registration.
Thereafter, such merchants may obtain "real" account numbers from a
service provider facility by providing a copy of the
pseudo-account-number transaction details under cryptographic
authentication that authenticates both the transaction data and the
merchants' right to obtain a "real" account number. The service
provider may then forward the "real" account numbers in encrypted
form to the merchants, so that the cardholders may be identified
with the cards corresponding to their "real" account numbers.
[0090] Advantageously, the present invention provides enhanced
security for the use of payment account numbers over the
Internet.
[0091] The foregoing merely illustrates the principles of the
invention. It will thus be appreciated that those skilled in the
art will be able to devise numerous systems and methods which,
although not explicitly shown or described herein, embody the
principles of the invention and thus within the spirit and scope of
the invention.
* * * * *