Payment processing system and program

Abstract

To provide a settlement processing system capable of evading concentration of credit inquiry requests for a system of a card issuer.SOLUTION: Claim data from an affiliated store includes a token imparted beforehand to a card of a user. The token is capable of being converted to a card number in a settlement processing system 100. A settlement information storage unit 106 stores (1) a token imparted to the card and (2) a credit necessity flag expressing whether or not credit inquiry is necessary for every settlement process for every registered card by a user. The settlement processing system (A) references the credit necessity flag corresponding to the token included in the claim data from an affiliated store system, (B) converts the token included in the claim data to the card number when credit inquiry is necessary every time for settlement processing regarding the card, and (C) executes credit inquiry using the card number.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to a payment processing system for making payments for sales by credit card and a program for realizing the system. [Background technology]

[0002] It has been common practice for consumers who use services or products continuously or periodically to pay for those services or products by credit card. In this case, the provider of the service or product (credit card merchant) has the consumer enter card information (card number, cardholder name, expiration date, etc.) when registering as a user, and approves the user registration after conducting a credit inquiry with the card company. After the user registration is approved, the cost of the services or products used by the consumer is paid periodically (for example, monthly) based on the card information. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-312677 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, systems that support payment processing (payment processing systems) have come to be placed between member stores and card companies. Payment processing systems compile billing data from member stores and process payments with card companies, but consumers who register with member stores use a variety of cards for payments. Meanwhile, some card companies require credit inquiries each time a periodic payment is made, but a concentration of credit inquiry requests related to payments from a large number of consumers is something that should be avoided, as it places a heavy load on both the payment processing system and the card company's system.

[0005] Therefore, in order to solve the above problems, the present invention aims to provide a payment processing system that can avoid a concentration of credit inquiry requests on the card company's system by appropriately sharing information between the affiliated store system and the payment processing system regarding whether or not a credit inquiry is required for each payment. [Means for solving the problem]

[0006] To achieve the above object, one embodiment of the present invention provides a payment processing system that receives billing data for a user of a member store from a member store system and performs payment processing using a card previously registered by the user. The billing data includes an amount billed to the user and a token previously assigned to the user's card. The token does not include the card number of the card and can be converted to the card number within the payment processing system. The payment processing system includes a processor and a payment information storage unit. For each card registered by a user, the payment information storage unit stores (1) the token assigned to the card and (2) a credit requirement flag indicating whether a credit inquiry is required for each payment processing for the card, in association with each other. The processor (A) receives the billing data from the affiliated store system, and references the credit requirement flag stored in the payment information storage unit in association with the token included in the received billing data; (B) if the referenced credit requirement flag indicates that a credit inquiry is required for the card each time a payment is processed, converts the token included in the received billing data into a card number; and (C) performs a credit inquiry using the card number.

[0007] A payment processing system according to another embodiment of the present invention receives billing data for a user of a member store from a member store system and performs payment processing using a card previously registered by the user. The billing data includes the amount billed to the user, a token previously assigned to the user's card, and a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the user's card. The token does not include the card number of the card and can be converted to the card number within the payment processing system. The payment processing system includes a processor and a payment information storage unit. For each card registered by a user, the payment information storage unit stores (1) the token assigned to the card and (2) a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the card, in association with each other. The processor (A) receives the billing data from the affiliated store system, references the credit requirement flag included in the received billing data, (B) if the referenced credit requirement flag indicates that a credit inquiry is required for the card each time a payment is processed, converts the token included in the received billing data into a card number, and (C) performs a credit inquiry using the card number. [Effects of the Invention]

[0008] According to the above-mentioned payment processing system, by appropriately sharing information between the member store system and the payment processing system as to whether or not a credit inquiry is required for each payment, a payment processing system can be provided that can avoid a concentration of credit inquiry requests on the card company's system. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a block diagram showing a schematic functional configuration of a payment processing system according to a first embodiment. [Figure 2] FIG. 10 is a schematic diagram showing the process when a user applies to an affiliated store. [Figure 3]4 is a flowchart showing an outline of the operation of the payment processing system according to the first embodiment at the time of user registration. [Figure 4] FIG. 10 is a schematic diagram showing an example of data stored after user registration has been completed. [Figure 5] FIG. 2 is a schematic diagram illustrating processing at the time of payment in the payment processing system according to the first embodiment. [Figure 6] 4 is a flowchart showing an outline of the operation at the time of payment of the payment processing system according to the first embodiment. [Figure 7] FIG. 10 is a schematic diagram showing an example of data stored after user registration in the second embodiment. [Figure 8] FIG. 10 is a schematic diagram showing a process at the time of user registration in the payment processing system according to the second embodiment. [Figure 9] 10 is a flowchart showing an outline of the operation of the payment processing system according to the second embodiment at the time of user registration. [Figure 10] FIG. 10 is a schematic diagram illustrating processing at the time of payment in the payment processing system according to the second embodiment. [Figure 11] 10 is a flowchart showing an outline of the operation at the time of payment of the payment processing system according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] [First embodiment] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described in detail below with reference to the accompanying drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals and their description will not be repeated.

[0011] FIG. 1 is a block diagram showing a schematic functional configuration of a payment processing system 100 according to a first embodiment. As shown in FIG. 1, payment processing system 100 is connected to an affiliated store system 200 and a card company system 300 via a communications network (not shown). This communications network is preferably a dedicated line. Although only one affiliated store system 200 is shown in FIG. 1, multiple affiliated store systems 200 can be connected to payment processing system 100. Furthermore, although only one card company system 300 is shown in FIG. 1, multiple card company systems 300 are connected to payment processing system 100.

[0012] The affiliated store system 200 is a system owned by each service or product provider, and is realized by one or more computers and one or more storage devices. The computer of the affiliated store system 200 may be a server, a personal computer, a tablet computer, a smartphone, or the like. The affiliated store system 200 may also be a system installed in the affiliated store (on-premise type) or a system built in a cloud environment, and its hardware configuration is optional. The storage device may be built into the computer, or may be realized as a storage device installed in any location accessible from the computer.

[0013] The affiliated store system 200 includes a user registration processing unit 201, a billing processing unit 202, and a user information storage unit 203. The user registration processing unit 201 and the billing processing unit 202 are functional blocks implemented by the computer of the affiliated store system 200 executing a predetermined program. The user information storage unit 203 is implemented as a storage device within the computer or an external storage device accessible by the computer. The user registration processing unit 201 performs a process of registering consumers who use the affiliated store's services or purchase its products as users. Examples of services or products provided by affiliated stores include, but are not limited to, distribution services for various content such as books, videos, and music; software licenses; telephone and data communication services; subscriptions for groceries and daily necessities; provision of learning materials and information products; management of various organizations; infrastructure services such as gas, water, and electricity; pay television broadcasting; and provision of various insurances. To register as a user in the affiliated store system 200, consumers must register contact information such as their name, address, and email address, as well as credit card information to be used for payment of charges. The details of the user registration process will be explained later. On a predetermined closing date (for example, a predetermined date each month), the billing processor 202 calculates the amount to be billed to each user according to the services used since the previous closing date.

[0014] Payment processing system 100 is located between affiliated store system 200 and card company system 300, and provides comprehensive support processing for credit card payments. Payment processing system 100 is implemented using one or more computers and one or more storage devices. The computer(s) of payment processing system 100 may also have any hardware configuration. The storage device(s) of payment processing system 100 may be built into the computer, or may be implemented as a storage device installed in any location accessible from the computer.

[0015] As shown in Figure 1, payment processing system 100 includes a registration credit inquiry unit 101, a token issuance processing unit 102, a BIN judgment processing unit 103, a credit necessity judgment unit 104, a payment credit inquiry unit 105, and a payment information storage unit 106. These blocks are functional blocks realized by the computer of payment processing system 100 executing a predetermined program.

[0016] The registration credit inquiry unit 101 performs a credit inquiry on the credit card used for payment when a user applies for user registration with a member store. The token issuance processing unit 102 issues a token that the member store system 200 uses during billing processing. The token issuance processing will be explained later. The BIN determination processing unit 103 determines whether a credit inquiry is required each time a payment is processed, based on the BIN code of the credit card used for payment, when a user applies for user registration with a member store. The credit necessity determination unit 104 identifies the user's card number based on the token sent from the member store system 200 during payment processing, and determines whether a credit inquiry is required during payment. The payment credit inquiry unit 105 performs a credit inquiry when it is determined that a credit inquiry is required during payment processing. The payment information storage unit 106 stores the data required during payment for each user.

[0017] Here, with reference to Figures 2 and 3, the processing when a user registers with an affiliated store will be described. When a consumer applies for user registration with an affiliated store, they input their name, contact information, and credit card information to the affiliated store system 200 to use for payment. Instead of inputting this information themselves, the consumer may provide consent to the affiliated store system 200 to use information already registered in a system other than the affiliated store system 200 (e.g., account information in another system). Upon receiving the consumer's application input, the affiliated store system 200 transmits user data including information about the credit card (card information) to the payment processing system 100. This card information includes the credit card number, the cardholder's name, the card expiration date, and, if necessary, a security code (CVC code). The payment processing system 100 stores the received user data in the payment information storage unit 106.

[0018] When the payment processing system 100 receives card information from the affiliated store system 200 (step S1 in FIG. 3), the registration credit inquiry unit 101 sends the card information to the card company system 300 and executes a credit inquiry (step S2). In the card company system 300, the credit processing unit 301 checks whether the card is valid or not based on the card information, and returns the result of the credit check to the payment processing system 100. If the credit check is not passed, the registration credit inquiry unit 101 notifies the affiliated store system 200 of this fact.

[0019] If the credit check is completed without any problems, the token issuance processing unit 102 of the payment processing system 100 generates a token unique to the user (step S3). The token is digital data of any data length, and can be generated in any manner, provided that it corresponds one-to-one with the user registered in the affiliated store system 200. However, from a security perspective, it is desirable that the token be generated outside the payment processing system 100 as data that makes it impossible to identify the individual user or the user's card number from the token alone. For example, a random number may be generated each time a user is registered, and used provided that it does not overlap with any previously issued tokens. Alternatively, the token may be generated using a hash function, encryption algorithm, or the like, based on some or all of the user data received from the affiliated store system 200. The generated token is stored in the payment information storage unit 106 of the payment processing system 100 and is also sent to the affiliated store system 200 and stored in the user information storage unit 203 (step S4).

[0020] In addition, the BIN determination processing unit 103 of the payment processing system 100 references the BIN code (issuer identification code) included in the card number of the credit card used by the user for payment and determines whether the issuer of the credit card requires a credit check for each payment (step S5). Some credit card issuers require a credit check for each payment, while others do not. If the credit card used by the user for payment has a BIN code from an issuer that requires a credit check for each payment, the BIN determination processing unit 103 assigns a credit requirement flag of "1" to the user's card information in the user information storage unit 203. If the credit card used by the user for payment has a BIN code from an issuer that does not require a credit check for each payment, the BIN determination processing unit 103 assigns a credit requirement flag of "0" to the user's card information in the user information storage unit 203. Note that the value of the credit requirement flag is not limited to the above example and may be any value.

[0021] FIG. 4 is a schematic diagram showing an example of data stored in the user information storage unit 203 in the affiliated store system 200 and the payment information storage unit 106 in the payment processing system 100 after user registration. The user information storage unit 203 in the affiliated store system 200 stores, as user information, for example, a user ID uniquely assigned to each user within the affiliated store system 200 and a token issued to that user, in association with each other. The user information storage unit 203 may store other user-related information in addition to the user ID and token shown in FIG. 4. The payment information storage unit 106 in the payment processing system 100 stores, for each user's card, a card number, an issued token, and a credit requirement flag, in association with each other. The payment information storage unit 106 may store information other than that shown in FIG. 4. In the example shown here, a card with a BIN code of "123456" (the first six digits of the card number) requires credit verification for each payment, while a card with a BIN code of "123789" does not require credit verification for each payment. Note that the data shown in Figure 4 is merely an example, and the number of digits of each piece of data is not limited to the example shown here.

[0022] Next, the settlement process performed based on a bill sent from a member store will be described with reference to FIGS.

[0023] The billing processor 202 of the affiliated store system 200 determines the billing amount for each user, for example, on the closing date of each month by tallying up the usage amount since the previous closing date. The billing processor 202 transmits billing data including the billing amount for each user to the payment processing system 100. This billing data includes, for each user, the billing amount as well as a token for identifying the user.

[0024] When the payment processing system 100 receives billing data (step S11 in FIG. 6), the credit necessity determination unit 105 references the payment information storage unit 106 for each billing data item (i.e., billing data for one user) and acquires the credit necessity flag stored in association with the token included in the billing data (step S12). If the acquired credit necessity flag is "1" (Yes in step S13), a credit inquiry is required for the billing data each time a payment is made. In this case, the credit necessity determination unit 105 reads the card number corresponding to the token included in the billing data from the payment information storage unit 106, sends the read card number and the billing amount to the payment credit inquiry unit 105, and instructs it to execute a credit inquiry (step S14). Upon receiving the instruction to execute a credit inquiry, the payment credit inquiry unit 105 transmits the card number and the billing amount to the card company system 300 and executes a credit inquiry. When the credit inquiry is completed successfully, the payment processing system 100 performs the payment process for the billing data (step S15). The credit inquiry from the payment credit inquiry unit 105 to the card company system 300 may be performed as a batch process that compiles the billing data of multiple users.

[0025] As described above, according to the payment processing system 100 of this embodiment, when making periodic payments, credit inquiries are made to the card company system 300 only for cards that require a credit inquiry each time. This prevents a large number of credit inquiry requests from being made to the card company system 300 when making payments, reducing the processing load on both the payment processing system 100 and the card company system 300. Furthermore, the affiliated store system 200 stores tokens instead of card information, and the billing data sent from the affiliated store system 200 to the payment processing system 100 does not include the user's card information, making it possible to build a highly reliable system that does not leak card information.

[0026] [Second embodiment] A payment processing system according to the second embodiment of the present invention will be described below. Note that parts having the same functions as those in the first embodiment will be given the same reference numerals, and detailed descriptions thereof will be omitted.

[0027] The functional configuration of the payment processing system according to the second embodiment is similar to that of the payment processing system 100 according to the first embodiment. However, as can be seen from a comparison between Figures 4 and 7, the second embodiment (Figure 7) differs from the first embodiment in that the credit requirement flag is stored in the user information storage unit 203 of the affiliated store system 200, rather than in the payment information storage unit 106 of the payment processing system 100.

[0028] The processing for user registration in the second embodiment will now be described with reference to Figures 8 and 9. When the payment processing system 100 of the second embodiment receives card information from the affiliated store system 200 (step S31 in Figure 9), the registration credit inquiry unit 101 sends the card information to the card company system 300 and executes a credit inquiry (step S32). In the card company system 300, the credit processing unit 301 checks whether the card is valid or not based on the card information, and returns the result of the credit check to the payment processing system 100. If the credit check is not passed, the registration credit inquiry unit 101 notifies the affiliated store system 200 of this fact.

[0029] If the credit check is completed without any problems, the token issuance processing unit 102 of the payment processing system 100 generates a token that is uniquely assigned to the user (step S33). The generated token is stored in the payment information storage unit 106 of the payment processing system 100.

[0030] Next, the BIN determination processing unit 103 of the payment processing system 100 references the BIN code (issuer identification code) included in the card number of the credit card used by the user for payment, and determines whether the issuer of that credit card requires a credit inquiry for each payment (step S34). If the credit card used by the user for payment has a BIN code from an issuer that requires a credit inquiry for each payment, the BIN determination processing unit 103 generates a credit necessity flag of "1." If the credit card used by the user for payment has a BIN code from an issuer that does not require a credit inquiry for each payment, the BIN determination processing unit 103 generates a credit necessity flag of "0."

[0031] The payment processing system 100 associates the token generated in step S33 with the credit requirement flag determined in step S34 and transmits them to the affiliated store system 200 (step S35). The affiliated store system 200 associates the token sent from the payment processing system 100 with the credit requirement flag and stores them in the user information storage unit 203 (see Figures 7 and 8).

[0032] Next, the settlement process performed based on a bill sent from a member store will be described with reference to FIGS.

[0033] The billing processor 202 of the affiliated store system 200 determines the billing amount for each user, for example, on the closing date of each month by tallying up the usage amount since the previous closing date. The billing processor 202 transmits billing data including the billing amount for each user to the payment processing system 100. In the second embodiment, the billing data includes, for each user, the billing amount as well as a token for identifying the user and a credit requirement flag (see FIG. 10).

[0034] When the payment processing system 100 receives billing data (step S41 in FIG. 11), the credit necessity determination unit 105 references the credit necessity flag included in the billing data for each item of billing data (i.e., billing data for one user) (step S42). If the credit necessity flag is "1" (Yes in step S43), a credit inquiry is required for the billing data each time a payment is made. In this case, the credit necessity determination unit 105 reads the card number corresponding to the token included in the billing data from the payment information storage unit 106, sends the read card number and billing amount to the payment credit inquiry unit 105, and instructs it to execute a credit inquiry (step S44). Upon receiving the instruction to execute a credit inquiry, the payment credit inquiry unit 105 transmits the card number and billing amount to the card company system 300 and executes a credit inquiry. If the credit inquiry is successfully completed, the payment processing system 100 executes the payment processing for the billing data (step S45). The credit inquiry from the payment credit inquiry unit 105 to the card company system 300 may be performed by batch processing that compiles billing data for multiple users.

[0035] As described above, in the payment processing system 100 of the second embodiment, when making periodic payments, credit inquiries are made to the card company system 300 only for cards that require a credit inquiry each time. This prevents a large number of credit inquiry requests from being made to the card company system 300 when making payments, reducing the processing load on both the payment processing system 100 and the card company system 300. Furthermore, the affiliated store system 200 stores tokens instead of card information, and the billing data sent from the affiliated store system 200 to the payment processing system 100 does not include the user's card information, making it possible to build a highly reliable system that does not leak card information.

[0036] [Variations] The specific examples given in the above embodiments are merely examples, and are not intended to limit the embodiments of the present invention.

[0037] For example, in the above embodiment, a mode has been exemplified in which a card number is associated with a token and stored in the payment information storage unit 106. However, if a token is generated based on the card number using a predetermined algorithm and the card number can be reversibly decrypted from the generated token, there is no need to store the card number in the storage unit.

[0038] In the above embodiment, payment processing system 100, an example of the present invention, is described as being implemented as hardware using one or more computers and their peripheral devices. However, the present invention can also be implemented as a program for causing one or more computers to execute the functions of payment processing system 100, or as a recording medium storing the program.

[0039] The present invention can also be explained as follows.

[0040] [First configuration] A payment processing system according to a first configuration receives billing data for a user of a member store from a member store system and performs payment processing using a card previously registered by the user. The billing data includes the amount billed to the user and a token previously assigned to the user's card. The token does not include the card number of the card and can be converted to the card number within the payment processing system. The payment processing system includes a processor and a payment information storage unit. For each card registered by a user, the payment information storage unit stores (1) the token assigned to the card and (2) a credit requirement flag indicating whether a credit inquiry is required for each payment processing for the card, in association with each other. The processor (A) receives the billing data from the affiliated store system, and references the credit requirement flag stored in the payment information storage unit in association with the token included in the received billing data; (B) if the referenced credit requirement flag indicates that a credit inquiry is required for the card each time a payment is processed, converts the token included in the received billing data into a card number; and (C) performs a credit inquiry using the card number.

[0041] With this configuration, credit inquiries are made to the card company system only for cards that require credit inquiries each time a periodic payment is made. This prevents the card company system from receiving numerous credit inquiry requests during a payment, reducing the processing load on both the payment processing system and the card company system. Furthermore, because member stores hold tokens rather than card information, and because the billing data sent from member stores to the payment processing system does not contain the user's card information, a highly reliable system can be built that prevents card information leaks.

[0042] [Second configuration] A payment processing system according to a second configuration receives billing data for a user of a member store from a member store system and performs payment processing using a card previously registered by the user. The billing data includes the amount billed to the user, a token previously assigned to the user's card, and a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the user's card. The token does not include the card number of the card and can be converted to the card number within the payment processing system. The payment processing system includes a processor and a payment information storage unit. For each card registered by a user, the payment information storage unit stores (1) the token assigned to the card and (2) a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the card, in association with each other. The processor (A) receives the billing data from the affiliated store system, references the credit requirement flag included in the received billing data, (B) if the referenced credit requirement flag indicates that a credit inquiry is required for the card each time a payment is processed, converts the token included in the received billing data into a card number, and (C) performs a credit inquiry using the card number.

[0043] With this second configuration, credit inquiries are also made to the card company system only for cards that require credit inquiries each time a periodic payment is made. This prevents the card company system from receiving numerous credit inquiry requests during a payment, reducing the processing load on both the payment processing system and the card company system. Furthermore, because member stores hold tokens rather than card information, and because the billing data sent from member stores to the payment processing system does not contain the user's card information, a highly reliable system can be built that prevents card information leaks.

[0044] The invention disclosed herein can also be implemented as a program executed by a processor of a computer in a payment processing system, or as a recording medium on which the program is recorded. [Explanation of symbols]

[0045] 100: Payment processing system, 101: Credit inquiry unit at registration, 102: Token issuance processing unit, 103: BIN determination processing unit, 104: Credit necessity determination unit, 105: Credit inquiry unit at payment, 106: Payment information storage unit, 200: Member store system, 201: User registration processing unit, 202: Billing processing unit, 203: User information storage unit, 300: Card company system, 301: Credit processing unit

Claims

1. A payment processing system that receives billing data for a user of a member store from a member store system and processes a payment using a card that the user has registered in advance, the billing data includes a billing amount to be charged to the user and a token previously assigned to the card of the user; the token does not include the card number of the card and is convertible to the card number within the payment processing system; The payment processing system includes a processor and a payment information storage unit, The payment information storage unit stores, for each card registered by a user, A token attached to the card; a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the card; are associated and stored, The processor: receiving the billing data from the affiliated store system, and referencing the credit requirement flag stored in the payment information storage unit in association with the token included in the received billing data; If the referenced credit necessity flag indicates that a credit inquiry is required for the card in question each time a payment is processed, convert the token included in the received billing data into a card number, performing a credit inquiry using said card number; Payment processing system.

2. A payment processing system that receives billing data for a user of a member store from a member store system and processes a payment using a card that the user has registered in advance, The billing data includes an amount to be billed to the user, a token previously assigned to the card of the user, and a credit necessity flag indicating whether a credit inquiry is required for each payment process for the card of the user, the token does not include the card number of the card and is convertible to the card number within the payment processing system; The payment processing system includes a processor and a payment information storage unit, The payment information storage unit stores, for each card registered by a user, A token attached to the card; a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the card; are associated and stored, The processor: Receive the billing data from the affiliated store system, and refer to the credit requirement flag included in the received billing data; If the referenced credit necessity flag indicates that a credit inquiry is required for the card in question each time a payment is processed, convert the token included in the received billing data into a card number, performing a credit inquiry using said card number; Payment processing system.

3. 3. The payment processing system according to claim 1, wherein the payment information storage unit stores a card number of a user's card in association with a token.

4. The payment processing system according to claim 1 or 2, wherein the process of converting the token into a card number includes decrypting the token using a predetermined algorithm.

5. A payment processing program that receives billing data for a user of a member store from a member store system and causes a processor of a computer in a payment processing system to execute payment processing using a card previously registered by the user, the billing data includes a billing amount to be charged to the user and a token previously assigned to the card of the user; the token does not include the card number of the card and is convertible to the card number within the payment processing system; The payment processing system includes the processor and a payment information storage unit, The payment information storage unit stores, for each card registered by a user, A token attached to the card; a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the card; are associated and stored, The payment processing program causes the processor to: receiving the billing data from the affiliated store system, and referencing the credit requirement flag stored in the payment information storage unit in association with the token included in the received billing data; If the referenced credit necessity flag indicates that a credit inquiry is required for the card in question each time a payment is processed, convert the token included in the received billing data into a card number, performing a credit inquiry using said card number; A payment processing program containing instructions to carry out the processing.

6. A payment processing program that receives billing data for a user of a member store from a member store system and causes a processor of a computer in a payment processing system to execute payment processing using a card previously registered by the user, The billing data includes an amount to be billed to the user, a token previously assigned to the card of the user, and a credit necessity flag indicating whether a credit inquiry is required for each payment process for the card of the user, the token does not include the card number of the card and is convertible to the card number within the payment processing system; The payment processing system includes the processor and a payment information storage unit, The payment information storage unit stores, for each card registered by a user, A token attached to the card; a credit requirement flag indicating whether a credit inquiry is required for each payment transaction for the card; are associated and stored, The payment processing program causes the processor to: Receive the billing data from the affiliated store system, and refer to the credit requirement flag included in the received billing data; If the referenced credit necessity flag indicates that a credit inquiry is required for the card in question each time a payment is processed, convert the token included in the received billing data into a card number, performing a credit inquiry using said card number; A payment processing program containing instructions to carry out the processing.

7. 7. The payment processing program according to claim 5, further comprising an instruction to store the card number of the user's card and the token in association with each other in the payment information storage unit.

8. 7. The computer-readable storage medium according to claim 5, wherein the process of converting the token into a card number includes decrypting the token using a predetermined algorithm.

9. 7. A program recording medium on which the payment processing program according to claim 5 or 6 is recorded.

Images