JP2003536181A - Improved method and system for processing secure payments across computer networks without pseudo or proxy account numbers - Google Patents

Abstract

(57) Abstract: A method is provided for using a payment network and an inspection site to process an electronic transaction with a payment account number having a certain amount of funds available. The method comprises the steps of: (a) generating a secret key associated with the payment account number; (b) generating a transaction-specific message authentication code (MAC) using the secret key; (c) generating the MAC. Generating an authorization request message including: (d) forwarding the authorization request message across the payment network to the inspection site to verify the authenticity of the MAC; (e) the message by the inspection site using the private key. Verifying the authorization code, and (f) responding to the authorization request message across the payment network based on the transaction amount and available funds.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention relates to methods and systems for processing secure financial transactions across communication networks, and more particularly to securely sending payments over computer networks such as the Internet and across public communication channels. It relates to a method and system for transmitting sensitive information.

Priority Application This application is US Provisional Patent Application No. 60 / 225,168 (filed August 14, 2000), "Method and System for Processing Secure Electronic Commerce Transactions," as well as Provisional Application No. 60.
No. / 213,325 (June 22, 2000), "Same Name As Previous Application", claiming the benefit of each priority and are hereby incorporated by reference. The present application further discloses US Patent Application Serial No. 09 / 833,049 (April 11, 2001), "Improved Methods and Systems for Processing Secure Payments Across Computer Networks."
Of the present application, which is incorporated herein by reference, and which is itself US Provisional Patent Application No. 60 / 195,963 (April 11, 2000), "Safety Beyond Computer Networks. And systems for processing secure payments "and U.S. patent application serial number 09 / 809,367 (May 15, 2001)," Law and Systems for Processing Secure Payments Across Computer Networks, "Priority of Each Claiming interests.

Obviously, online commerce has grown tremendously over the last few years,
In fact, the ever-increasing number of consumers still sends information such as credit card numbers and personal identification numbers (personal identification numbers) across public communication networks such as the Internet, and uses personal financial information. I am in trouble or worried about doing this. As a result, over the last few years, companies have worked hard to find the best way to ensure secure payments across computer networks and reduce the risk of theft or misuse of financial information. .

For example, US Pat. No. 5,883,810 “Electronic Online Commerce Card with Transaction Proxy Number for Online Transactions” (assigned to Microsoft Corporation) provides a temporary transaction number for each transaction. And then associate it with a permanent account number, this transaction number looks like a real credit card number, and the customer uses this transaction number for the purpose of submitting it to the merchant as an alternative to the customer account number. And In this case, the customer does not have to send his true credit card number over the public network.

In the aforementioned '810 patent, the merchant passes the transaction number to the issuing agency, which then uses the transaction number as an index to access the real customer account number, process the authorization, and respond to the authorization. That is, the authorization response is returned to the merchant based on the transaction number. As a result, the patent claims that risk can be minimized. The reason is not only that the customer sends the transaction number, but also that the proxy number is only valid for one-time purchase, ie "
It cannot be used repeatedly for any other shopping or transaction, so thieves can't make a big profit if stolen ”(Col. 2, lines 60-61).

The conventional system needs to be improved, and more specifically, it avoids the need to send and generate a unique transaction number that is repeatedly generated and provides a permanent account number for each transaction processed. What is needed is a replacement method and system for processing secure financial transactions across the Internet.

Although co-pending application 09 / 809,367 (March 15, 2001) is incorporated herein by reference, a “pseudo” account number is assigned to the customer and cryptographically Linked to your payment account number. This payment account number is an account number issued by a financial institution or other organization that a customer can use to pay for goods and / or services. For example, the payment account number may be an account number obtained from a payment (payment) card such as a credit card or debit card, or from a payment application such as an electronic cash application stored on the customer's computer. Pseudo account numbers appear to merchants as genuine payment account numbers. That is, the pseudo account number has the same length as the proper payment account number and begins with the proper identification number (eg, "5" for MasterCard International, Inc. (MasterCard)). The pseudo account number is used by the customer in place of the real account number for all of his online financial transactions.

According to the invention of co-pending application 09 / 809,367, all transactions based on pseudo account numbers are preferably cryptographically authenticated using a private key unique to each account number. Is. Authentication can be based on a private key of a public key pair (public key authentication) or a secret key other than a private key. Thus, if an unauthorized person attempts to ascertain any pseudo account number, that number will be used to prevent unauthorized transactions.

Further, in accordance with the invention of co-pending application 09 / 833,049, a method is provided in which a service provider is assigned an acquirer code and uses a payment network to process transactions. More specifically, the service provider receives the first authorization request for an authorization request for authorization or approval of the transaction using the first payment account number, and (i) the first payment account number is Associated with a second payment account number having a BIN code (bank identification number) associated with the service provider and a BIN code associated with the issuer of the second payment account number, and (ii) a first authorization The request includes an acquirer code associated with the acquirer (membership acquiring institution), and (iii) the first payment account number is based on the BIN code of the first payment account number and is provided by the service provider through the payment network. Can be routed to.

The method further responds to the first authorization request by the service provider using the second payment account number to send a second authorization request for authorization or approval of the transaction. A second authorization request is associated with the service provider and is routed through the payment network to the issuer based on the issuer's BIN code (ie, the BIN code of the second payment account number). is there.

Further, a response to the second authorization request from the issuer is received by the service provider, the response including an acquirer code associated with the service provider and routed through the payment network based on the code. obtain. The response to the first authorization request is then sent by the service provider to the acquirer based on the response to the second authorization request, and the first
Preferably, the response to the authorization request includes an acquirer code associated with the acquirer and can be routed through the payment network based on the code.

In another preferred embodiment of the invention of this co-pending application 09 / 833,049, a first payment account number associated with a second payment account number is used to process transactions with a merchant. A. (A) generating a message authentication code based on details of one or more transactions, (b) sending at least a first payment account number and a message authentication code to the merchant.
(c) requesting authorization (authorization) by the merchant to pay for the transaction using the first payment account number, said request being as if
As if submitted at a POS terminal with a conventional magnetic stripe payment card, the message authentication code is sent to any data field contained in a track of the type used in conventional payment card magnetic stripes. And (d) responding to the authorization request for the first payment account number by requesting authorization to pay for the transaction using the associated second payment account number, (e) providing a method comprising accepting or rejecting an authorization request for a first payment account number based on a message authentication code and a response to the authorization request for a second payment account number.

This system still has room for improvement and can be made even more secure by protecting information and messages sent during or in connection with financial transactions processed over public communications lines. , Such improvements may be implemented without the use of pseudo or surrogate account numbers.

[0014] SUMMARY OF THE INVENTION Accordingly, the present invention provides a method of processing an electronic transaction using a payment account numbers with funds certain amount available using the payment network and "Inspection Site" . The method comprises: (a) generating a private key associated with the payment account number; (b) using the private key to generate a message authentication code (MAC) specific to the transaction; (c) ) Generating an authorization (authorization) request message containing the message authorization code, (d) forwarding the authorization request message across the payment network to the inspection site to verify the authenticity of the MAC. (E) validating the message authentication code by the inspection site using the private key, (f) responding to the authorization request message across the payment network based on the transaction amount and the available funds. The steps include ,.

According to a preferred embodiment of the invention, the authorization request message is routed, ie routed, across the payment network based on the special bank identification number corresponding to the inspection site. The software is preferably placed at the user's location to generate the private key.

According to another preferred embodiment of the invention, the authorization request message comprises an expiration date field and the message authentication code is placed in this expiration date field.

Further objects, features, and advantages of the present invention will become apparent from the following detailed description in view of the accompanying drawings, which show preferred embodiments of the invention. Throughout the drawings, the same reference numerals and characters, unless otherwise specified, refer to the same functions, components, or parts in the described embodiments. Further, the subject matter of the present invention will be described in detail together with the preferred embodiments with reference to the drawings. Without departing from the spirit and scope of the inventive subject matter defined in the claims,
It is intended that changes and modifications may be made to the described embodiments.

Detailed Description of the Preferred Embodiments As noted above, the present invention is a method and method for processing secure e-commerce transactions using a payment account number, such as a credit card account number. Intended for system. In the preferred embodiment of the present invention, the payment account number is a virtual payment account number, that is, an ISO (International Organization for Standardization) 7816 account number, which is used in electronic transactions, but is not physically ISO7816
No need to link to type card. Alternatively, the payment account number is a physical
It can be a payment account number issued to an ISO7816 type card, or
The payment account number can also be linked to a payment account number issued on a physical ISO7816 type card.

In the detailed description of the invention that follows, there are many references to MasterCard International, Inc. (or MasterCard), but this is merely an example, and a special payment account number is set forth below. It's something special to handle. Also, the following acronyms may be used.

[0020]   BIN-Bank identification number   DEA-Data encryption algorithm   PC-Consumer personal computer equipment   MAC-Message authentication code   MCI-Mastercard International or Mastercard   MCWS-Mastercard Website   PIN-Personal identification number (PIN)   POS-Point of sale management   SSL-Secure Socket Layer (Internet Security)   TSN-Transaction sequence number

According to an aspect of the invention, one or more BIN ranges or BINs of payment account numbers are associated with a secure e-commerce transaction. These BINs or BIN ranges may hereinafter be referred to as "special" BINs or BIN ranges. A payment account number with a special BIN may hereinafter be referred to as a "special" payment account number.

According to another aspect of the invention, the owner of the special payment account number has a private key (
A key for each card is provided and used when the e-commerce transaction is processed using the special payment account number and the message authentication code (M
AC) can be generated.

According to yet another aspect of the invention, there is provided at least one function with a copy of the private key, which is generated by the owner of the special payment account number.
It can be used to verify AC. Such a function may hereinafter be referred to as an "inspection site".

Therefore, as shown in FIG. 1, the present invention has several processing components:
These will be described. Special Pay Account Number (SPAN) owners or consumers may be provided with a secure Special Pay Account Number Software Application (SPANSA) on their computer 10. SPANSA is SP
Holds a private key associated with the AN and uses this key to generate the MAC. M
The AC is sent to the originating merchant 12 and forwards the authorization request message (MAC) to the acquirer bank 14 (membership acquisition bank) to initiate the authorization process.

E-commerce transactions using special payment account numbers are preferably approved through the payment (settlement) network 16. For example, if the special payment account numbers are MasterCard credit card numbers, these may be approved through MasterCard's Banknet payment network. Authorization request and authorization response messages for special payment account numbers are routed through the payment network 16 to the inspection site 18 based on the special BIN of the account number. Thus, for example, issuing agency and acquirer computers that interface with payment network 16 may be
A look-up table can be included that points to a special BIN corresponding to eight.
However, one or more computers at the inspection site 18 that interface with the payment network 16 include a look-up table that points to the issuer corresponding to the special BIN.

According to the present invention, when the inspection site 18 receives the authorization request message, the inspection site 18 uses the private key associated with the special payment account number to verify the MAC associated with the transaction. You can Further, the inspection site 18 can transmit the approval request message to the issuer 20 (the institution that issued the special payment account number). The inspection site 18 responds to the approval request message with M
Respond with an indication of whether the AC has been verified (ie, proved to be genuine) and / or with an approval response from the issuing authority.

When the inspection site 18 forwards the authorization request message to the issuing agency, the inspection site can indicate to the issuing agency 20 whether the MAC has been verified. As an example, assuming that the special payment account number is a MasterCard credit or debit card account number, the inspection site may send the debit to the issuing bank, in an outbound banknet, or to the mastercard debit switch debit. In the message, it can be indicated that the MAC has been verified. This indicator can be the newly defined value for the current security indicator field used in the "0100/0200" type message of the MasterCard. The inspection site may erase the contents of the incoming security level indicator for all transactions and write the supplied security level (ie whether the MAC has been verified) to its output. it can.

In the exemplary transaction using a special payment account number, the issuing bank's authorization response message is routed back to the inspection site due to the special BIN range. If the approval response message indicates approval, the inspection site 18
Displays "approval" on the display or indicator that the MAC returns to the verified acquirer. The acquirer 14 then sends the message to the originator's approval 12
Return to. In this way, the merchant knows, through his acquirer, that the issuing bank has confirmed the transaction as well as the issuing bank confirming the transaction. This means that the transaction must have originated from the cardholder, and it can be a "guaranteed" transaction.

As mentioned above, SPANSA can be stored on the computer of the special PAN owner. In addition to the computer, the application can also be stored on a cell phone or personal digital assistant (PDA). It is preferred that a special PAN owner request the application from the website 22 (eg, the publisher's website, including the inspection site, or other suitable location) over the Internet. This website is preferably capable of being coupled to or having access to a hardware security module 24 which has the ability to create a customer specific secret cryptographic key such as a DES key or the like.
Each security module preferably has one or more "derivative keys" as used to generate and regenerate a customer-specific private cryptographic key.
"rivation key)".

A secure PAN application stored on the owner's computer may include a transaction sequence number (detailed below) that communicates with the inspection site or other support site for each trunk. You don't have to. Instead, the application stored on the computer of the owner of the special PAN interacts with and inspects the transaction sequence counter with the inspection site or other support site at any interval desired by the particular issuing agency. Can be synchronized.

The present invention can also be used with remote wallet servers. In this case, the secure PAN application is not stored and is managed and maintained on the special PAN owner's computer system. Advantageously, in this embodiment, the invention allows a special PAN owner to utilize a general Internet browser, which is used to access a remote wallet server (this server is secure in it). PAN application).
In this embodiment, the special PAN owner's local system does not need to include any additional software or functionality that is superior to typical Internet browsers.

Advantageously, the present invention enables the utilization of virtual reality first account numbers. In contrast to systems that use pseudo or surrogate account numbers, the present invention can be switched by the acquirer's computer without conversion and requires backend switching or processing functionality changes. There is no.

Also, in contrast to systems that use pseudo or surrogate account numbers, the present invention 1) eliminates the need to send a clearing file to a central site, thereby eliminating all payment procedures. 2) eliminates the need for a charge back that needs to be sent back to the central site, and 3) is sent to the central site system for conversion into a real account number, Removes all search requests made by cardholders after the transaction has been placed on their bill. The cardholder is provided with and uses the real account number for these transactions.

In contrast to systems that utilize pseudo or surrogate account numbers, the present invention creates and manages the transaction log memory needed to convert special payment account numbers into real account numbers. Eliminate the need.

The MAC can be transmitted to the inspection site in a number of ways. An example of a method of transmitting the MAC to the inspection site is shown below. MAC Option 1 In this implementation, the MAC is placed in the card expiration date (expiration date) field and behaves as a "pseudo expiration date". MAC generation will be described in more detail below. In this embodiment, no changes need to be made to the merchant site. The only additional requirement considered for the merchant is the ability of the merchant to accept an additional authorization response field in the message from the acquirer indicating that the transaction MAC has been authenticated, but use this. No need. The field used for this display is a normal bank card authorization message send / receive POS.
In the system, the current can be any supported field.

MAC Option 2 This implementation may be used in connection with other options. In this embodiment, the cardholder's computer or remote wallet server maintains a log of merchant data associated with the transaction. For example, the cardholder's computer or remote wallet server may (a) transaction MAC, (b) merchant's web address (URL), (c) merchant's Secure Socket Layer (SSL) certificate serial number, and / or ( d) Log the complete merchant SSL certificate. This embodiment allows the log to provide sufficient data to prove that the claim is false if the cardholder later claims that the transaction was not initiated by him. In that respect, it provides additional safety. In this embodiment, the merchant website has not changed.

MAC Option 3 In this embodiment, the transaction MAC is placed at the card expiration date location, as in Option 1 or 4. The MAC is generated based on the merchant provided data elements. This merchant-provided data element is passed to the cardholder or remote wallet server in an additional, separate field designed to carry the merchant-provided data needed to calculate the MAC. In one embodiment, the merchant, such as the merchant's SSL certificate serial number, is already linked to a data element such as they have in the data field used in the MAC operation. For example, the MAC has the following data elements: (a) PAN, (b) real card expiration date (4 digit MMYY format), (c) transaction sequence number (this is the cardholder's system and inspection site). They are kept synchronized by both), (d) the date and time of the transaction, (e) the secure PAN application version number, (f) the merchant's SSL certificate serial number, and other data that identifies the merchant. You can

This embodiment requires modification of the merchant's e-commerce site. Merchants need to modify their systems to send their merchant certification serial numbers in outgoing authorization request messages. However, this embodiment provides key merchant identification data that links the merchant to a particular transaction. The MAC verification step calculated at the cardholder system and the verification site has this additional merchant identification field. If the inspection site recognizes that the incoming authorization request message has a merchant-provided certificate serial number, it uses it in the MAC calculation and the same process used when the cardholder system generated the MAC. To match.

MAC Option 4 In this embodiment, the transaction MAC is in the card expiration date field,
And placed in the CVC2 or equivalent field. CVC2 is a three-digit numeric value printed next to the signature line on some cards.
As background, the ISO payment card has a static (at least) three-digit code cryptographically generated by the issuer. For example, on a MasterCard payment card, this code is called CVC2. This value can be generated by the issuing bank using a private encryption key and verified using this same key. This option allows the generation of longer transaction MACs (ie the MAC output size is incremented by 3 digits). In this embodiment, the CVC2 (or equivalent code) field is dynamically generated and filled with MAC. The merchant site needs to support prompting of the cardholder and subsequent transmission of CVC2 or equivalent fields.

MAC Option 5 In this embodiment, the transaction MAC is placed in the CVC2 or equivalent field. This embodiment makes it possible to generate at least a 3-digit MAC. In a preferred embodiment of this option, when the MAC is generated for a transaction, the MAC references a real or static CVC2 value (ie, a CVC2 value generated by the issuing bank and issued with the payment card). And be inspected.
If the generated MAC is the same as the static CVC2 value, the secure PAN application transaction counter is incremented and a new MAC is generated. This new MAC is then compared to the static CVC2 value and as a result it is determined if the two values are the same. This process uses a CVC whose generated MAC value is static.
It is repeated until it is not the same as the binary value. When the MAC is verified for a transaction, the verification process compares the CVC2 value received with what was sent with the transaction with the expected static CVC2 value for the payment card. If these values are the same, the verification process determines that the secure PAN
The application is not used for the transaction and MA
C determines that it has not been transmitted. If the received CVC2 value differs from the static CVC2 value, then the secure PAN application determines that it is being used for the transaction and the CVC2 field contains the MAC. The verification process then attempts to verify the MAC in the CVC2 field.

Special payment account numbers need not be used in this embodiment (although they could be used). Alternatively, as described above, the value in the CVC2 field can be used to determine when a secure PAN application was used in the transaction.

General Background of Cardholder Authentication There are many cardholder authentication methods available and well known in the art,
May be specified by the cardholder's secure PAN application issuer.
Authentication methods also include, but are not limited to, the use of remote wallet servers accessed by a cardholder's Internet browser such as Netscape using SSL or Microsoft Internet Explorer browser. Here, the authentication method may include the use of access by user ID and password and / or the use of access by chip card based digital ID authentication. In the case of a remote wallet server, the present invention may also include locally stored applications, such as those managed and maintained by the cardholder's system itself.

The transaction authentication of the present invention is provided by the generation of a MAC that goes beyond the transaction details as described below.

The account number protection of the present invention can be further improved by the use of virtual account numbers, which consist of a magnetic stripe zero value in a face-to-face transaction at a POS terminal. Is because there is no issued magnetic stripe). In connection with the fact that these virtual account numbers must fall within the special BIN range that indicates these account numbers needed to be routed to the inspection site, each issuer has a special A BIN range is provided so that under the invention virtual account numbers are used.

In the case of the present invention, the need for merchant authentication prior to revealing the cardholder's own account number, because the account number of the present invention cannot be used without the transaction-specific MAC associated with it. Sex is removed. Any attempted fraudulent use of account numbers under the present invention, such as playing a transaction with an old MAC without the cardholder's authentication, will be routed to a special inspection site, but for the attempted transaction No verification is done. Therefore, all fraud attempts will fail.

The cardholder can provide the password before downloading the secure PAN application, or the application can be the cardholder's PC.
You can choose a password when introduced above. If a password is selected or provided, then the cardholder will need to enter this password to activate the application on his PC. This password chosen by the cardholder can be used to encrypt or otherwise change the private key. This secure PAN application can also be downloaded as part of the Digital Wallet application.

Generating a Customer-Specific Private Key The private key embedded in the secure PAN application is unique to each special payment account number and preferably uses a derived key and a special payment account number. And derive it from the security module. Each issuer or each BIN
Can be a derived key for a range. The derived key may be, for example, a triple length DEA key. The customer-specific key can be generated with the derived key using any encryption method known in the art.

The inspection site preferably has binding or access to a security module that has a copy of the derived key in it. When the inspection site receives the authorization request for the special payment account number, the inspection site derives the key needed to verify the MAC using the appropriate derived key with the special payment account number.

MAC Generation The following is an exemplary method to demonstrate that a MAC can be generated and used in accordance with the present invention. As mentioned above, the MAC can be placed in the transaction's expiration date field. The MAC then behaves as a "pseudo" expiration date. This pseudo expiration date is formatted in the MMYY format like the expiration date. Desirably, to work with the current processing systems of all or most merchants on the market today,
The pseudo expiration date should be included within 48 months of the transaction.

Preferably, it includes a secure PAN application (hereinafter also referred to as “secured application”), a transaction sequence number, which is 2
It consists of zero digits and is incremented for each transaction. Thus, 2 ² to ^0, i.e. approximately up to one million transaction occurs, it is not rotated like until all 1 all zeros. The secured application can also include a 4-bit "version number", which is the respective PC on which the secured application for a given account number resides,
Alternatively, it is a number unique to other devices.

For each transaction processed by the cardholder's secured application, the transaction sequence number is incremented first. The resulting 20-bit number and the 4-bit secured application version number concatenated to its left are left-justified in an 8-byte field,
On the right side, binary zeros are padded and triple length DEA encryption is performed using a key for each card of a double length secured application. The result is a 64-bit binary MAC.

Writing the MAC to the Expiration Date Field The transaction's Expiration Date field is then set to 6 as described above.
It can be obtained from a 4-bit binary MAC. 1. Select the leftmost "1" bit in "Number of Month Display (Binary, described in more detail below)", and select the rightmost bit (least significant bit) from this bit position.
Count the number of bit positions up to (including the leftmost "1" bit). This number is called "N". For example, when the “number of month display” is “0101 0100 (decimal 84)”, the value of “N” is 7. After determining "N", consider the 64-bit binary MAC as a group of "N" bits, ignoring the leftmost leftover bits. Start with the leftmost group and select the first group found that is less than or equal to "Number of Months Displayed". If no such group is found, select the leftmost group, add the "number of months displayed" to this selected group, and subtract 2 ^N from this total, which results (this is> 0, And <the number of months is displayed.) Is used as the selected value. 2. The result of step 1 is divided by the binary number "1100 (12 in decimal)" to generate the quotient and the remainder. Convert this quotient and the remainder to decimal. This remainder in decimal (00 to 11
Up to the two leftmost (most significant) decimal digits (MM) of the "reference date", which will be described in detail later. If the result is greater than 12, then subtract 12 from the result and in any case use the result as the leftmost digit of the card expiration date for the transaction, MM. If the result obtained needed to subtract 12, the quotient is incremented by 1. 3. Add the quotient of the two decimal numbers from step 2 (which may have been incremented as mentioned in step 2) to the two rightmost digits of "base date" (YY),
Modular operation is performed with 100 (Add, mod-100 ...). Use the result as the two rightmost numbers, YY, of the card expiration date for the transaction.

Writing the MAC to the CVC2 field or equivalent The MAC can be generated by the method described above, but can be generated by any method known in the art. Further, in addition to or in place of placing the MAC in the expiration date field, the MAC, or a portion thereof, may be placed or written in the CVC2 field or its equivalent.

Communication Between Cardholder and Merchant Once the secured application has been installed on the cardholder's computer, the cardholder uses this secured application for all Internet payments. The application provides the cardholder's special payment account number for all Internet transactions. The fact that this is a secured application transaction is transparent to the merchant, ie unaware of it.
The account number is actually a special payment account number, and the expiration date may actually represent the MAC, but the merchant is unaware that the transaction is different from other Internet SSL transactions received.

More specifically, whenever a MAC field is supported by a merchant, the secured application uses the private key embedded in it to create a message authentication code (MAC) associated with the transaction. However, this MAC and the data based on it are placed in the MAC field, which becomes part of the transaction.

Shortly after receiving the cardholder's transaction message, the merchant
Format the traditional approval request for the acquirer. This approval request
Preferably, it contains the MAC field as it was provided by the consumer's PC.

Only those that include the MAC field and the expiration date at the beginning of the transaction, the merchant will have multiple clearings / clearings for the cardholder's transaction.
) Transaction should be started. Subsequent transactions, including only the payment account number, can be considered as merchant-generated mail-order / telephone-order transactions. Also, it is authentic for all repeated payments and partial payments with multiple clearings.

Handling Acknowledgment Request Acquirers When an acquirer receives an approval request from an Internet merchant, it looks up the issuer BIN in its BIN table. In the MasterCard payment system, if the acquirer determines that the BIN of the transaction corresponds to an issuer other than the home country, the acquirer routes the transaction to MasterCard via the Banknet system. If the acquirer determines that the BIN of the transaction corresponds to the issuer of its own country, the transaction can be routed to MasterCard via Banknet. Alternatively, if the issuer is in the same country as the acquirer, the acquirer can usually route the transaction directly to the issuer specified by the BIN. In the case of a special payment account number transaction, the transaction is preferably routed to a central processing facility (preferably a master card approved processing facility, ie an inspection site).

In some embodiments of the present invention, some countries may have the capability of being equipped with a special security module to process domestic transactions. It is preferred that each of these functions be set up only by authorization of the MasterCard and hold only account number conversion data and cryptographic keys for the country of the transaction being processed. In countries with such national inspection site functionality, all transactions are sent using this functionality so that transactions in the same country do not have to leave that country. A national inspection site function that handles domestic transactions can be more efficient than sending all transactions to a central processing function.

Starting Secured Applications Secured applications can be started on a transaction-by-transaction basis just prior to the execution of a secured application-based payment. The secured application sends the request to a payment processing website (preferably a Mastercard website or server). This request may include, for example, a 16-digit special payment account number, a 4-digit decimal digit payment account expiration date, a 4-bit secured application version number, a 20-bit transaction sequence number current value, and , A 16-bit MAC (message authentication code) based on the latter three of these values. The MAC is concatenated with the 20-bit transaction sequence number,
In addition, using a 4-bit secured application version number and a 16-bit expiration date (in binary coded decimal) concatenated (left to right), this is left-justified in a 64-bit field and to the right of it. By padding with binary zeros and then selecting the leftmost 16 bits of the resulting ciphertext, 3
It can be encrypted by the double-length DEA cipher.

When the website receives this information, it uses the secured application system with the special security module to verify the MAC based on the secured application version number, transaction sequence number, and expiration date. If the MAC is verified, ie proved to be genuine, the system increments the transaction sequence number (
Retain), generate an "expected transaction sequence number (ETSN)" and process the secured application authorization request for the indicated special payment account number BIN secure application authentication system in question (eg, ETSN for secure application version number and special payment account number of the inspection site). If the received ETSN is the same as or less than the highest numbered ETSN received last time for this secured application version number and special payment account number, this secured application approval system (inspection site) Reject the ETSN that was just received. This secured application authorization system (inspection site) is also given the expiration date that it just received, and if this expiration date is just after the current expiration date in the record, then this special payment account number Update the associated expiration date.

The special secured application system preferably sends the following two data values to the web, which then sends them to the secured application on the cardholder's PC. 1) A data value called "reference date". This is a four digit decimal number in MMYY format (actually the date of the current month or the following month). 2) A data value called "number of month display". It is an 8-bit binary number with a maximum value less than 256 (in decimal). These data are also included in the information sent to the appropriate secured application approval system (inspection site).

A special BIN for central processing functions (and / or national functions) special payment account numbers to process authorization requests allows the acquirer and payment network to route transactions to the inspection site. The inspection site will receive the highest 20-bit numbered ETSN record received by the MAC for this transaction sequence number for each secured application version number and special payment account number.
Store along with an indication of whether or not it has been verified. In addition, the inspection site stores the "expected transaction sequence number" received within the last 48 hours regarding that the MAC has not been verified. In association with each such expected transaction sequence number, the system also stores a "number of months display" and a "reference date" indication that matches the respective expected transaction sequence number.

The “reference date” is a date value indicating the earliest expiration date that the approval request message can be accepted. By way of background, some merchants do not require immediate approval,
Request approval in batches together. Therefore, this date is typically
One or two days before the date the transaction was initiated.

“Number of Months Displayed” indicates a number representing a month after the current date corresponding to the latest expiration date on which the payment card is accepted.

The verification site has access to, or its access to, a security module that has the ability to determine a unique and secret 16-byte cryptographic key placed in the secured application of the cardholder's PC when registered. Is bound to the module. The processing executed at the inspection site is as follows.

1. The security module is used to determine the unique cryptographic key for this secured application with the appropriate derived key and special payment account number. 2. Select the first 20-bit ETSN received within 48 hours for unverified MAC. 6 based on the secured application version number associated with that ETSN and this 20-bit transaction sequence number, as defined above for the secured application on the PC.
Calculate 4-bit MAC. Determine the expiration date from this MAC using the method defined above for the secured application on the PC, using the "Number of Months Displayed" and "Reference Date" specified for the associated ETSN. . If the determined expiration date is the same as the expiration date of the current transaction, the MAC has been properly verified. The entry for this ETSN resulting from the MAC verification is "if this entry is the highest numbered ETSN for the secured application version number associated with it."
ETS marked as "MAC verified" or labeled with the highest number
If it is not N, it is deleted. The entry in the lower numbered ETSN that is marked as "MAC verified" and is associated with the same secured application version number is now deleted.

3. If the Mac is validated in step 2 (or step 4), then it is known that the merchant of this transaction will never send a second authorization request message for the same transaction. Create an entry in the "History Data" for this special payment account number, except. It should be noted that some merchants may also send a second or more authorization request message if they are unable to ship all of the merchandise in a specified delivery time after the transaction. This historical data entry includes all of the above-mentioned data, and in addition to these, the identities of the merchants and acquirers, and the "expiration date" for this entry. This expiration date entry will be entered at a specified time in the future (
For example, 6 months).

If the MAC is not verified as legitimate in step 2, then the oldest to the newest that are not associated with already verified MACs, past 4
Other "expected transaction sequence numbers" received within 8 hours
Repeat the procedure defined in step 2 for all of the above. Once again, if the resulting dates of these attempts match the date of the current transaction, then the MAC is considered verified. If the 20 digit ETSN resulting from the MAC verification was the highest ETSN for the associated secured application version number in question when the MAC was verified, the resulting 20 MAC result is 20 The digit ETSN is "MAC
Marked as "verified" and deleted if not the highest ETSN for the associated secured application version number for the issue. M
If AC is verified in this step, then step 3 is also performed. 5. If neither step 2 nor step 4 verifies that the MAC is valid, then access the "history data" for the special payment account number in question. If there is an entry for data for the same merchant and acquirer that will generate a MAC with the same expiration date, and the entry has not expired, accept the MAC (this is an addition for an already approved transaction). Is presumed to be an approval request message). When the MAC is accepted for this entry, if the expiration date of this entry is less than 2 months, then this expiration date should be approximately 2 months. The reason is that this may be a "repeat payment" and there may be other authorization request messages for the same transaction around the next month.

If the MAC is not verified as valid in step 2, step 4, or step 5, the transaction is rejected. In this case, a "reject" response is sent to the acquirer and / or the fact that the MAC has not been verified is displayed in a special field, such as the security field described above.

In summary, the inspection site notes the presence of the MAC field. The inspection site determines the private key (as described above) and verifies the MAC with this key using essentially the same procedure that was used on the PC to create the MAC. The system also checks transaction Siemens numbers and, in order to do so, must maintain transaction sequence number information for each version number for each special account number it processes.

The system is as follows: 1. The transaction sequence number is less than or equal to the highest transaction sequence number for this version of this secured application number that was received at least 48 hours ago, or 1. Reject the transaction if the transaction sequence number matches one of the already received transaction sequence numbers for this version of this secured application number.

If the verification of the MAC or transaction sequence number fails, the function rejects the transaction and / or displays a verification failure in an appropriate field such as the SET security field. MAC
If both the transaction sequence number and the transaction sequence number are verified to be valid, this function causes the issuer to route the transaction. If the MAC is verified as valid, then the central processing facility, or inspection site, formats an authorization request message for the issuer. The authorization request message may include information indicating whether the MAC has been verified as valid.

The pseudo BIN use approval response is the acquirer BIN of the approval request message sent to the issuer.
When routed through a payment network according to the MasterCard, the MasterCard may replace the Acquirer BIN in the transaction message with a special MasterCard BIN that acts as a "pseudo" Acquirer BIN. As a result of the acquirer BIN being replaced, the issuer responds to the MasterCard on behalf of the acquirer. If the payment network keeps a record of where the authorization request message came from and the authorization response message to the same location, then this step need not be performed.

When the pseudo acquirer BIN is used, the pseudo acquirer BI may be used in order for the acquirer and the issuer to accurately calculate the interchange fee.
N should correspond to the country in which the acquirer is located, or the region where it will offer the same exchange rate, or other country. If each country has a special BIN associated with them, the Mastercard is the Acquirer BIN
Can be replaced with a special BIN associated with the country of the acquirer. If the country of the acquirer does not have a special BIN associated with that country, it is possible to select a special BIN associated with another country that will incur the same exchange fee.

When using a pseudo-acquirer BIN, the MasterCard has in its database the acquirer reference (reference) received in the approval request from the acquirer.
) Store data (hereinafter also referred to as "original acquirer reference data"). When formatting the approval request for the issuer, MasterCard can use the original acquirer reference data to find the pseudo acquirer BIN, the appropriate transaction type indicator, and the original acquirer reference data. Replace with "pseudo" acquirer reference data, including index values, such as

It is more efficient for the secured application approval system (or inspection site) to calculate and store the expiration date displayed by the MAC when receiving a new ETSN without waiting until the actual approval request is received. You can also do it. Then, when an approval request is received, the precomputed and stored within the last 48 hours that does not yet match the expiration date in the approval request message with any expiration date in the previous approval request message. Compare with.

Dealing with Issuers of Approval Requests Issuers approve transactions like any other transaction. The authorization response is routed back to the "pseudo" acquirer, the inspection site that originally received the special payment account number transaction, or the same MasterCard secured application authorization system. As described above, the inspection site sends an authorization response to the acquirer with an indication of whether the MAC has been verified. This message is then sent from the acquirer to the merchant, just like a normal Mastercard transaction.

Authentication Using Additional Fields The MAC of the present invention can be written to a separate MAC field consisting of, for example, three decimal digits. These 13 numbers can be as follows: 1. One decimal digit "Version Indicator" field. This field usually contains "1". However, if the cardholder has multiple copies of the secured application for the same special payment account number (eg, on desktop and laptop computers), additional versions of the secured application will be displayed in the version display field. Will have a different number (the secured application transaction sequence number is unique for each such version of the secured application). 2. Six decimal digits, the secured application transaction sequence number for this version of the secured application.
This field is incremented for each secured application transaction started on this particular computer (each computer will have its own version of the secured application and therefore its own set of sequence numbers).

3. MAC itself, 6-digit decimal number In this situation, the recommended MAC generation process is as follows. (a) Describe the 7-digit number of the secured application version number (on the left) and the secured application transaction sequence number (for this computer) in binary coded decimal number, resulting in 28 bits.
These 28 bits are left-justified in the 64-bit field, and zero bits are padded on the right. (B) Using the leftmost 8 bytes of the key for each card as the encryption key,
The result of (3) is DE-encrypted. (c) Using the rightmost 8 bytes of the key for each card as the decryption key,
The result of is DE-decrypted. (d) Step 3 using the leftmost 8 bytes of the key for each card as the encryption key
DEA-encrypt the result of. (e) Consider the 64-bit result of step 4 as a 16-digit hexadecimal number of 4 bits each. Scan these 16-digit hexadecimal numbers (from left to right),
Select the first 6 numbers with the following values: If no such first six digits are found, re-scan these digits to select the rest of the required digits, but at this point, select only hexadecimal digits greater than "9". Then, a hexadecimal number "A" is subtracted from each selected. (f) The result of step 5 is the 6-digit decimal MA for this transaction.
Used as C.

The MAC is provided by the secured application of the cardholder's PC, and this MAC will be verified by the appropriate master card secured application function or inspection site. When generated, the 6 digit decimal number resulting from step 6 is inserted into the MAC field as the actual MAC. When verified, secured application functionality
Perform the above 6 steps using the leftmost 7 digits of the MAC field and then the 6 digits resulting from step 6 and the rightmost 6 digits of the received MAC field. Compare with. As a result, if the match is exact, it indicates that the transaction is authenticated. If they do not match, it indicates that the transaction should be rejected.

While the preferred embodiment of the invention has been disclosed for purposes of illustration, those skilled in the art may make numerous additions, changes, and modifications without departing from the scope and spirit of the invention as defined by the claims.
It will be appreciated that and substitutions are possible.

[Brief description of drawings]

FIG. 1 is a block diagram of processing components associated with a transaction method in accordance with one embodiment of the present invention.

─────────────────────────────────────────────────── ─── Continuation of front page (51) Int.Cl. ⁷ Identification code FI theme code (reference) H04L 9/32 H04L 9/00 675Z (31) Priority claim number 09/809, 367 (32) Priority date Heisei March 15, 2013 (March 15, 2001) (33) Priority claiming country United States (US) (31) Priority claim number 09 / 833,049 (32) Priority date April 11, 2001 (2001) 4.11. (33) Priority claiming country United States (US) (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE, TR), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH , GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN , YU, ZA, ZW (72) Inventor Karl M Campbell USA Pencil Veneer 19073 Newton Square Marine Road 809 F Term (reference) 5B085 AA08 AE03 AE23 BG02 BG07 CA02 CA04 CA06 5J104 AA08 NA38 PA10

Claims (11)

[Claims] 1. A method of processing electronic transactions across a public communications network using a payment network linked to an inspection site, with a payment account number having a certain amount of funds available, comprising: (A) generating a private key associated with the payment account number; (b) using the private key to generate a message authentication code specific to the transaction; (c) the message authentication. Generating an authorization request message containing a code; (d) forwarding the authorization request message across the payment network to the inspection site to verify the authenticity of the message authentication code; ) Use the private key to verify the message authentication code by the inspection site. The method comprising-up, the steps of: responsive to said authorization request message over the (f) based on the transaction amount and the available funds, the payment network. 2. The method according to claim 1, wherein the authorization request message is routed across the payment network based on a special bank identification number corresponding to the inspection site. 3. The method of claim 2, further comprising the step of providing software at a user's location to generate the private key. 4. The method of claim 3, wherein the payment account number is issued by an issuer and the response is provided by the issuer. 5. The method of claim 4, wherein the authorization request message includes an expiration date field and the message authentication code is placed in the expiration date field. 6. A method of processing electronic transactions across a public telecommunications network using a payment account number having a bank identification number (BIN) associated with an inspection site and the inspection site, comprising: (a) the payment. Generating a per-card key associated with an account number; (b) generating a message authentication code (MAC) using the card key; Generating a MAC verification request including a MAC and the payment account number; (d) verifying the MAC; (e) based on the verification, an expected transaction sequence number (ETSN) for the MAC. ), And (f) providing to the inspection site reference data associated with the ETSN. And (g) generating a second message authentication code using the card-specific key and the ETSN, and (h) to the inspection site based on the BIN associated with the inspection site. Routing a second message authentication code; (i) determining a per-card key associated with the payment data number of the unverified message authentication code associated with reference data and ETSN; j) verifying the second message authentication code by the inspection site using the associated ETSN and reference data and the determined per-card key. 7. The method of claim 6, further comprising: (a) pseudo-expiring the second message authentication code using the reference data after the step of generating the second message authentication code. Converting to a day; (b) generating an approval request having an expiration date field including the pseudo expiration date; (c) responding to the approval request and based on the pseudo expiration date, the second message. A step of verifying an authorization code, the method comprising: 8. The method of claim 7, wherein generating the message authentication code further comprises using a transaction sequence number and an application version number associated with the payment account number and an expiration date. Including a method. 9. The method according to claim 8, wherein the MAC verification request also includes the application version number and the expiration date. 10. The method of claim 9, wherein verifying the MAC also includes using a key for each card. 11. The method of claim 61, wherein   The reference data includes reference data and a number representing a month, A method characterized by the following.