JP7779482B2 - Payment processing system and program - Google Patents

Description

The present invention relates to a payment processing system for settling sales by credit card and a program for implementing the system.

It has traditionally been common for consumers who use services or products on an ongoing or regular basis 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 then 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 for periodically (for example, monthly) based on the card information.

Japanese Patent Application Laid-Open No. 2001-312677

In recent years, systems that support payment processing (payment processing systems) have come to intervene between merchants and card companies. Payment processing systems compile billing data from merchants and process payments with card companies, but consumers who are registered with merchants use a variety of cards for payments. Meanwhile, some card companies request credit inquiries each time a periodic payment is made, but a concentration of credit inquiry requests for 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.

To solve the above problem, 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 a credit inquiry is required for each payment.

To achieve the above objective, one embodiment of the payment processing system 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 process for the card, in association with each other. The processor (A) receives the billing data from the affiliated store system, references the credit necessity flag stored in the payment information storage unit in association with the token included in the received billing data, (B) if the referenced credit necessity 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.

A payment processing system according to another embodiment of the present invention is 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 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 process 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 process 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 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.

The above payment processing system allows the affiliated store system and the payment processing system to appropriately share information regarding whether a credit inquiry is required for each payment, thereby providing a payment processing system that can avoid a concentration of credit inquiry requests on the card company's system.

1 is a block diagram illustrating a schematic functional configuration of a payment processing system according to a first embodiment. FIG. 10 is a schematic diagram showing the process when a user applies to an affiliated store. 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. FIG. 10 is a schematic diagram showing an example of data stored after user registration has been completed. FIG. 2 is a schematic diagram illustrating a process at the time of payment in the payment processing system according to the first embodiment. 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. FIG. 11 is a schematic diagram showing an example of data stored after user registration in the second embodiment. FIG. 10 is a schematic diagram illustrating a process performed during user registration in a payment processing system according to a second embodiment. 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. FIG. 10 is a schematic diagram illustrating a process at the time of payment in the payment processing system according to the second embodiment. 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.

[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.

Figure 1 is a block diagram showing the general functional configuration of a payment processing system 100 according to the first embodiment. As shown in Figure 1, the 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. Note that although Figure 1 shows only one affiliated store system 200, multiple affiliated store systems 200 can be connected to the payment processing system 100. Also, although Figure 1 shows only one card company system 300, multiple card company systems 300 can be connected to the payment processing system 100.

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, etc. The affiliated store system 200 may also be a system installed within 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.

The affiliated store system 200 comprises 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 affiliated store system 200's computer 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 processing to register consumers who use affiliated store services or purchase 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; operation of various organizations; infrastructure services such as gas, water, and electricity; pay television broadcasting; and provision of various insurance policies. To be registered as a user in the affiliated store system 200, a consumer must register contact information such as name, address, and email address, as well as credit card information to be used for payment of charges. The user registration process will be explained later. On a specified closing date (e.g., a specified day each month), the billing processor 202 calculates the amount to be billed to each user based on the services used since the previous closing date.

Payment processing system 100 is located between member 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 of payment processing system 100 may also have any hardware configuration. The storage device of payment processing system 100 may also be built into the computer, or may be implemented as a storage device installed in any location accessible from the computer.

As shown in FIG. 1, the payment processing system 100 includes a registration credit inquiry unit 101, a token issuance processing unit 102, a BIN determination processing unit 103, a credit necessity determination 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 the payment processing system 100 executing a predetermined program.

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.

Now, with reference to Figures 2 and 3, we will explain the processing that occurs when a user registers with a member store. When a consumer applies for user registration with a member store, they enter their name, contact information, and credit card information to the member store system 200 to use for payment of charges. Note that instead of the consumer entering this information themselves, the consumer may provide consent to the member store system 200 to use information already registered in a system other than the member store system 200 (for example, account information in another system). When the member store system 200 accepts the consumer's application input, it transmits user data including information related to 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's 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.

When the payment processing system 100 receives card information from the affiliated store system 200 (step S1 in Figure 3), the registration credit inquiry unit 101 sends the card information to the card company system 300 and performs a credit inquiry (step S2). In the card company system 300, the credit processing unit 301 checks whether the card is valid based on the card information and returns the results 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.

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 S3). The token is digital data of any data length, and can be generated in any way, provided that it corresponds one-to-one with the users registered in the affiliated store system 200. However, from a security perspective, it is desirable that the token be generated as data that makes it impossible to identify the individual user or the user's card number from the token alone, outside the payment processing system 100. For example, a random number may be generated each time a user is registered, and used provided that it does not overlap with tokens already issued. Alternatively, a 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 where it is stored in the user information storage unit 203 (step S4).

The BIN determination processing unit 103 of the payment processing system 100 also 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 inquiry for each payment (step S5). Some credit card issuers require a credit inquiry 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 inquiry 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 inquiry 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. The value of the credit requirement flag is not limited to the above example and can be any value.

Figure 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 a corresponding manner. Note that the user information storage unit 203 may store information about a user other than the user ID and token shown in Figure 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 a corresponding manner. Note that the payment information storage unit 106 may store information other than that shown in Figure 4. In the example shown here, cards with a BIN code of "123456" (the first six digits of the card number) require credit approval each time a payment is made, while cards with a BIN code of "123789" do not require credit approval each time a payment is made. 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.

Next, with reference to Figures 5 and 6, we will explain the payment process that is performed based on the invoice sent from the affiliated store.

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 amount used since the previous closing date. The billing processor 202 sends 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.

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 obtains the credit necessity flag stored in association with the token included in the billing data (step S12). If the obtained credit necessity flag is "1" (Yes in step S13), a credit inquiry is required for each payment for the billing data. 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 perform a credit inquiry (step S14). Upon receiving the instruction to perform a credit inquiry, the payment credit inquiry unit 105 transmits the card number and billing amount to the card company system 300 and performs a credit inquiry. If the credit inquiry is successfully completed, the payment processing system 100 performs payment processing 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 aggregates billing data for multiple users.

As described above, according to the payment processing system 100 of this embodiment, when periodic payments are made, 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 payments are made, making it possible to reduce the processing load on both the payment processing system 100 and the card company system 300. Furthermore, since the affiliated store system 200 holds tokens rather than 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, it is possible to build a highly reliable system that does not leak card information.

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

The functional configuration of the payment processing system according to the second embodiment is the same as 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.

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 performs a credit inquiry (step S32). In the card company system 300, the credit processing unit 301 checks whether the card is valid based on the card information and returns the results 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.

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.

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."

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 transmitted 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).

Next, with reference to Figures 10 and 11, we will explain the payment process that is performed based on the invoice sent from the affiliated store.

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 amount used 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 Figure 10).

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 that billing data each time 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 perform a credit inquiry (step S44). Upon receiving the instruction to perform a credit inquiry, the payment credit inquiry unit 105 sends the card number and billing amount to the card company system 300 and performs a credit inquiry. If the credit inquiry is successfully completed, the payment processing system 100 performs 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 as a batch process that aggregates billing data for multiple users.

As described above, in the payment processing system 100 of the second embodiment, when periodic payments are made, 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 payments are made, making it possible to reduce the processing load on both the payment processing system 100 and the card company system 300. Furthermore, the affiliated store system 200 stores tokens rather than card information, and the user's card information is not included in the billing data sent from the affiliated store system 200 to the payment processing system 100, making it possible to build a highly reliable system that does not leak card information.

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

For example, in the above embodiment, an example was given in which the 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.

In the above embodiment, an example of the payment processing system 100 of the present invention has been described, 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 the payment processing system 100, or as a recording medium on which the program is stored.

The present invention can also be explained as follows:

[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 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, references the credit requirement flag stored in the payment information storage unit in correspondence 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.

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 numerous credit inquiry requests from being made to the card company system during payments, reducing the processing load on both the payment processing system and the card company system. Furthermore, since member stores hold tokens rather than card information, and 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.

[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.

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 numerous credit inquiry requests from being made to the card company system during payments, reducing the processing load on both the payment processing system and the card company system. Furthermore, since member stores hold tokens rather than card information, and the billing data sent from member stores to the payment processing system does not contain the user's card information, it is possible to build a highly reliable system that prevents the leakage of card information.

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

100: Payment processing system, 101: Registration credit inquiry unit, 102: Token issuance processing unit, 103: BIN determination processing unit, 104: Credit necessity determination unit, 105: Payment credit inquiry unit, 106: Payment information storage unit, 200: Merchant system, 201: User registration processing unit, 202: Billing processing unit, 203: User information storage unit, 300: Card company system, 301: Credit processing unit

Claims (9)

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. 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. A payment processing system as described in claim 1 or 2, wherein the payment information storage unit stores the user's card number and token in association with each other. The payment processing system of claim 1 or 2, wherein the process of converting the token into a card number includes decrypting the token using a predetermined algorithm. 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. 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. The payment processing program described in claim 5 or 6, further comprising instructions for storing the user's card number and token in association with each other in the payment information storage unit. The payment processing program according to claim 5 or 6, wherein the process of converting the token into a card number includes decrypting the token using a predetermined algorithm. 7. A program recording medium on which the payment processing program according to claim 5 or 6 is recorded.