JPH11250144A - Credit card settlement system and computer redable recording medium recording credit card settlement program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute the settlement of a case that a charged amount is not defined on a network at the time of a contract without changing a conventional secure credit card settlement protocol. SOLUTION: A card holder computer 100 is provided with a means for presenting (11) information obtained by adding the digital signature of the computer 100 to a charged amount from a merchant computer 200 to the computer 100 and information obtained by ciphering a credit card number inputted to the computer 100 by a payment gateway disclosed cipher key for a gateway computer 300 (hereafter these two information are referred to as I) to the computer 200 and a means for presenting (17) information including the I to the computer 300 when the computer 200 temporarily presents (13) information including the I to the computer 300, and after receiving a response that its authorization result is available, outputs an authorization request for the payment of the computer 100 in order to receive payment from the computer 100.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a credit card settlement system considering security on a network and a computer-readable recording medium recording a credit card settlement program.

[0002]

2. Description of the Related Art In credit card (hereinafter referred to as "card") settlement in consideration of security on a network, when a buyer submits a purchase request to a seller (hereinafter referred to as "contract time"), the buyer contracts with the seller according to the contract. (Hereinafter, abbreviated as “billing amount” when the buyer and seller, and the contract property are clear from the context). Under this assumption, the conventional secure credit card payment protocol follows the following procedure.

[0003] First, the buyer sends to the seller a "purchase request" which includes the information including the billing amount and a digital signature of the buyer and includes the buyer's own card information. The card information sent at this time is encrypted with the public encryption key of the payment gateway performing the authorization (operated by the financial institution), and can be decrypted only by the payment gateway. Next, the seller sends the encrypted card information and the digitally signed billing amount information to the payment gateway, and makes a payment authorization request (hereinafter, “authorization”) request for the buyer. As a result of this authorization request, if the payment is valid, the seller is confirmed to be able to receive the payment.

[0004] As described above, in the conventional secure credit card payment protocol, it is essential to determine the billing amount at the time of contract. Therefore, in the past, if the billing amount was undetermined at the time of contract, the use of secure credit card payment has been postponed. In this case, the buyer cannot fully confirm the identity of the seller due to transactions on the network,
This is because the seller presents card information that can be read by the seller and lacks security.

[0005]

SUMMARY OF THE INVENTION The present invention relates to a credit system which enables payment on a network when a charge amount is not fixed at the time of contract without changing a conventional secure credit card payment protocol. It is an object of the present invention to provide a computer-readable recording medium that records a card payment system and a credit card payment program.

[0006]

Means for Solving the Problems In order to solve the above-mentioned problems, the invention described in claim 1 is based on a financial institution that processes authorization of a buyer (hereinafter, “A”), a seller (hereinafter, “Otsu”), and a credit card ( (A) In the credit card settlement system described below, (a) the Party A has added the digital signature of Party A to the charge from Party B to Party A,
A means for presenting information obtained by encrypting the credit card number of Party A with the public encryption key of the payment gateway of Hei (hereinafter referred to as "I") to Company B, and (b) Company I (or Once the information including the copy) is presented to He, and after receiving a response indicating that the authorization result is acceptable, an authorization request for the payment of the party A is made for the purpose of receiving payment from Party A again, and I (or the Means for presenting information including (copy) to the user. According to a second aspect of the present invention, in the credit card settlement system according to the first aspect, the first, second, and third computers are constituted by a plurality of computers connected via a network. This is a computer-readable recording medium that records a credit card settlement program to be executed.

Here, a specific application example of the present invention will be described. In the above configuration, the seller provides a prepaid unit (a right for a buyer to use a service provided by the seller to a certain amount) as a product to be settled on a credit card. The buyer makes a contract for this prepaid unit purchase from the seller, and the buyer first setstles the service received from the seller in this prepaid unit (the seller manages the prepaid balance of the buyer). The settlement of the first prepaid unit purchase is performed only by the conventional secure credit card settlement protocol. At the same time, the seller saves the purchase request at the time of this contract.

[0008] The seller extracts card information encrypted with the public encryption key of the payment gateway and billing amount information with the buyer's digital signature from the information of the first prepaid purchase request. When the first prepaid balance becomes zero, the seller then configures an authorization request that includes these two. This means that the buyer again contracts with the seller to purchase the same prepaid unit.
Each time the buyer's prepaid balance goes to zero,
The billing is performed again by repeating the authorization request. Further, if the seller decides to separately stop providing the service (cancellation) with the buyer, the seller does not make a subsequent authorization request.

[0009]

Embodiments of the present invention will be described below with reference to the drawings. In the present embodiment, the buyer and the seller make a contract for prepaid unit purchase once, and SET (Sec.) Which is one of the conventional settlement methods (see the section of “Prior Art”).
ure Electronic Transaction (TM)) Version 1.0
(Reference: Secure Electronic Transaction Version
1.0 May, 1997.http: //www.mastercard.com/set/techno
logies.html) to settle this contract. Also, each time the buyer's prepaid balance becomes zero, the seller reconfigures the authorization request specified by the SET from the buyer's first prepaid purchase request and executes charging. FIG. 1 is a block diagram showing a configuration of a credit card settlement system according to the present invention, and FIG. 2 shows each step of processing in the system shown in FIG. 3 and 4
2 shows the components of information transmitted and received in each step of FIG. 2 and the contents thereof. In the following, the protocol part of the SET specification will be explained only when necessary,
Follow the procedure of non-SET processing.

First, the configuration of a system using the credit card settlement method according to the present invention will be described with reference to FIG. The credit card settlement system shown in FIG. 1 includes a buyer calculator 100 operated by a buyer who wants to purchase a product using a credit card installed in a network 10, a seller calculator 200 managed by a seller of the product, It is managed by a financial institution that processes the authorization of a credit card, and includes a payment gateway computer 300 that functions as a payment gateway. In the credit card settlement system according to the present invention, the buyer computer 100,
Seller computer 200 and payment gateway computer 300
Can be provided in plurals.

Next, a credit card settlement method according to the present invention in the system shown in FIG. 1 will be described with reference to FIGS. Figure 2 shows the buyer calculator shown in Figure 1.
The figure shows the processing of data transmitted and received between 100, the seller computer 200, and the payment gateway computer 300, and the data processed in each computer. In FIG. 2, a thin horizontal arrow indicates a message flow according to the conventional SET protocol, a thick horizontal arrow indicates a non-SET prescribed internal message flow processed in the seller computer 200, and a hatched vertical axis indicates a flow. The non-SET prescribed process in the seller computer 200 is shown.

First, in step 11 of FIG. 2, the buyer computer 100 creates an order instruction (purchase request; OI specified by SET) 22 and a payment instruction (PI specified by SET) 23 shown in FIG. The purchase request (PReq specified in SET) 21 is sent to the seller computer 200. In this example, the purchase request 21 shown in FIG. 3A is composed of an OI 22 composed of digitally signed purchase instruction data OIData generated by a private key owned by the buyer C, and a randomly generated symmetric key 1 A digital envelope that encloses the credit card information including the card number, expiration date, secret value, and random number with the public encryption key of the payment gateway, and has the same digital signature as OI22, and was encrypted with the symmetric key 1. Payment instruction data PIData
Authentication information is added as necessary to the PI23 consisting of. In addition, the legend of each symbol shown in FIG. 3 is shown in FIG.

In step 12 of FIG. 2, the seller calculator
200 is obtained from the purchase request 21 received in step 11 in FIG.
Extract and save PI23 of (a). Also, the steps in FIG.
At 13, the seller computer 200 makes an initial authorization request (AuthReq of the SET rule) 24 according to the SET rule as follows. That is, in step 13, the seller calculator 200
Creates the information component 25 according to the procedure specified by the SET, sets the PI 23 itself as the PI 26, and configures the authorization request 24 from the information component 25 and the PI 26.

FIG. 3B shows the structure of the authorization request 24. As shown in FIG. The authorization request 24 shown in this figure includes a digital envelope for enclosing a randomly generated symmetric key 2 with a public encryption key of a payment gateway and a digital signature generated with a private key owned by the seller M. Authorization data AuthReqDat encrypted with symmetric key 2
The information component 25 is composed of an information component 25 composed of a and a PI 26 that is configured similarly to the PI 23 shown in FIG.

Next, in FIG. 1, upon receiving the authorization request 24 in step 13, the payment gateway computer 300
Processing is performed as specified, and in step 14, the authorization is returned as an authorization response (AuthRes specified in SET).
If the content of the authorization response returned in step 14 is “OK”, it is determined that the seller can be paid, and the first prepaid unit purchase contract is established. On the other hand, if the content of the authorization response returned in step 14 is “No”, the contract is not established and the process does not proceed to the subsequent steps.

The buyer receives the service provided by the seller using the prepaid unit obtained in the procedure up to step 14 as a settlement means. Meanwhile, in step 15 of FIG.
The seller computer 200 changes the prepaid balance of the buyer according to the usage status of the buyer, and when detecting in step 16 that the balance has become zero, constitutes a second authorization request. In step 16, the seller computer 200 uses the copy of the first PI saved in step 12 as the PI to be included in the second authorization request, and the information component 25 in FIG. To create. In this way, the seller computer 200 creates an authorization request in a format conforming to SET (constructing an authorization request in this manner is hereinafter referred to as "reconstructing an authorization request").

In step 17 of FIG. 1, the seller calculator
200 sends the second authorization request prepared as described above to the payment gateway computer 300. In step 18, the payment gateway computer 300 sends an authorization response to the seller computer 200. After step 18, step 15,
This is the repetition of the steps 16, 17, and 18. This means that the buyer repeatedly makes a contract from the seller to purchase the same amount of prepaid units as the first time.

In the procedure of step 15 in FIG. 1, each time the prepaid balance of the buyer's computer 100 becomes zero, the seller's computer 200 repeats the reconfiguration of the authorization request, thereby performing recurring accounting. Further, after the service provision suspension (cancellation) is separately determined between the seller and the buyer, the settlement is completed by not allowing the buyer computer 100 to make an authorization request. At this time, if there is excess prepaid balance, the seller computer 200 sends an AuthRevReq, AuthRevRes message (Authorization r
eversal request message, Authorization reversal re
The accounting amount of the authorization request that has been made earlier is reduced by the sponse message). Generally, the reduction of the prepaid unit is also performed by these SET messages. The above operation is not affected even if the payment gateway is operated not by a financial institution but by an institution acting on behalf of the financial institution.

The programs executed by these computers can be distributed using a recording medium such as a magnetic disk or an optical disk, or a communication means such as a network as a medium.

[0020]

According to the present invention, the settlement in the case of a sales contract on the network and the billing amount is not fixed at the time of the contract can be performed by adding only the internal processing of the seller computer without changing the conventional secure credit card settlement protocol. Made it possible. As a result, when a buyer enters into a contract with an undetermined charge amount on a network, a secure credit card payment protocol using a secure credit card payment protocol can be used without presenting raw card information to the seller whose identity has not been sufficiently confirmed. Payment method is available.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a system configuration of the present invention.

FIG. 2 is an operation flow showing a processing procedure of the present invention.

FIG. 3 is a diagram showing components and contents of information processed in each step shown in FIG. 2;

FIG. 4 is a diagram showing a legend of each symbol and code shown in FIG. 3;

[Explanation of symbols]

 10: Network 100: Buyer calculator 200: Seller calculator 300: Payment gateway calculator

Claims (2)

[Claims] Claims 1. In a credit card settlement system by a buyer (hereinafter "A"), a seller (hereinafter "Otsu"), and a financial institution that processes credit card authorization (hereinafter "H"), a. The Party A has digitally signed the Party A's billing amount to Party A's digital signature, and the information obtained by encrypting Party A's credit card number with the public encryption key of the payment gateway of the Company (these two pieces of information are hereinafter referred to as "I"). (11) means for presenting to B, b. Party B once presents the information including I (or a copy thereof) to Party 13 (13), and after receiving a response stating that the authorization result is acceptable, Party B shall pay the Party A's payment for the purpose of receiving payment from Party A again. (17) means for making an authorization request and presenting information including I (or a copy thereof) to C. (17). 2. The credit card settlement system according to claim 1, wherein A, B, and C are constituted by a plurality of computers connected via a network, and the credit card executed by the computers. A computer-readable recording medium that records a payment program.