Credit Transaction System

Abstract

To enable issuers to offer a variety of services without burdening merchants or acquirers. [Solution] The credit management method of the present invention includes the steps of: when a commercial transaction occurs, the issuer server receives transaction information from an acquirer server which contains merchant identification information that identifies a merchant where the commercial transaction took place, the credit card number used in the commercial transaction, and acquirer identification information that identifies an acquirer server which received the transaction information from the merchant terminal; and the issuer server notifies the acquirer server of the credit result for the received transaction information and stores the commercial transaction separately from other commercial transactions if the combination defined by the credit card number, the acquirer identification information, and the merchant identification information matches predetermined conditions.

Description

Technical Field

[0004] , , , ,

[0001] The present invention relates to a credit transaction management system.

Background Art

[0002] The current commercial transaction system using credit cards is formed with a card issuing company (Issuer), a merchant terminal, and a settlement agent (Acquirer; also called "merchant contract company" or "card merchant management company", etc.) as the framework, and is established by exchanging various information among them. Specifically, when a user purchases goods at a merchant using the issued credit card, the information of the commercial transaction (settlement information) is first transmitted from the merchant's terminal to the server of the settlement agent (Acquirer) via the server of the Acquirer. The Acquirer transmits the settlement information to the Issuer, and also collects various fees (such as merchant fees) and performs payment processing for the merchant. In this way, by having an Acquirer between the merchant terminal and the Issuer, it becomes easier for merchants to participate in the commercial transaction system, and for the Issuer, it becomes unnecessary to manage merchants, and it can focus on the credit (authorization) of card members and the management of settlement information, enabling smooth transactions overall.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] For example, if an issuer wants to offer special benefits to a particular merchant, it needs to enter into a new special agreement with the merchant regarding fees and other matters (a so-called On-us merchant agreement). However, this requires the merchant to amend their existing contract with the acquirer. Alternatively, the merchant could enter into a new contract with another acquirer (contracting with multiple acquirers), but this would increase the management burden on the merchant. Thus, within the framework of the traditional commercial transaction system, it was difficult for issuers to offer special services, such as providing benefits, without affecting the relationship between merchants and acquirers. The present invention aims to enable issuers to provide a variety of services without imposing burdens on merchants and acquirers. [Means for solving the problem]

[0005] In one embodiment, the present invention provides a credit transaction system comprising: a plurality of merchant terminals into which commercial transaction information is entered; one or more acquirer servers connected to the merchant terminals and performing payment processing; and an issuer server connected to the acquirer servers and managing credit information, wherein when a commercial transaction occurs, the issuer server receives transaction information from the acquirer server, which includes merchant identification information that identifies the merchant in which the commercial transaction took place, the credit card number used in the commercial transaction, and acquirer identification information that identifies the acquirer server that received the transaction information from the merchant terminal; and the issuer server notifies the acquirer server of the credit result for the received transaction information, and if the combination defined by the credit card number, the acquirer identification information, and the merchant identification information matches conditions predetermined by the issuer server, the issuer server stores the commercial transaction separately from other commercial transactions. [Effects of the Invention]

[0006] According to the present invention, card operators can provide a variety of services without imposing burdens on merchants and payment processing companies. [Brief explanation of the drawing]

[0007] [Figure 1] This shows an overview of the configuration of the credit transaction system 100. [Figure 2] This shows the functional configuration of issuer server 30. [Figure 3] An example of data stored in the condition table TBL1 is shown below. [Figure 4] An example of data stored in the aggregate database RC is shown. [Figure 5] This document presents 100 operational examples of a credit transaction system. [Figure 6] This is an example of data transmitted and received in the credit transaction system 100. [Modes for carrying out the invention]

[0008] Figure 1 shows an overview of the configuration of the credit transaction system 100. The credit transaction system 100 includes multiple merchant terminals 10, an acquirer server 20, an issuer server 30, a payment processing network 901, and an international brand network 902.

[0009] The payment processing network 901 connects the acquirer server 20 and the international brand network 902, relaying payment-related information.

[0010] The International Brand Network 902 is a network of so-called international brands such as Mastercard®, Visa®, and JCB®, and exchanges payment-related information between the issuer server 30 and the acquirer server 20.

[0011] Issuer Server 30 is managed and operated by a business operator (hereinafter referred to as the "card operator") that handles payment processing for its issued credit cards, including issuing credit cards in its own name and conducting credit checks (membership applications and setting credit limits). A credit card may or may not involve the issuance of a so-called plastic card (physical card) (so-called digital card, cardless); the point is that a card number used for credit transactions is issued. In addition, credit cards generally have an international brand assigned to them. In this example, the card operator has a contract with international brand M and issues cards with international brand M assigned to them.

[0012] The issuer server 30 is connected to one or more acquirer servers 20 and processes information about commercial transactions using the company's credit cards at the merchant terminal 10 via the acquirer servers 20. Specifically, it issues and manages the company's credit cards, handles credit authorization, and manages payment information (aggregation and clearing). The issuer server 30 also performs credit checks (authorization) and notifies the acquirer servers 20 of the credit result (approval / rejection). While the credit assessment process involves accessing external databases containing credit information as needed, this is not directly related to the present invention and therefore is omitted from this explanation. In this example, issuer server 30 is connected to acquirer servers 20-2, 20-3, and 20-4 that handle international brand M. It receives credit information and payment information sent from merchant terminals 10-1 to 10-4 via acquirer servers 20-2, 20-3, or 20-4 and performs various processing. Card operators may issue multiple international brands, in which case the acquirer server(s) 20 connected to issuer server 30 are capable of processing credit cards of those multiple international brands.

[0013] In this example, the card company designates A Store Online, A Store Store A, and A Store Store B as campaign partner stores and issues new credit cards (hereinafter referred to as "campaign cards") that offer special benefits not available before. Alternatively, the company may designate some of its existing cards as campaign cards. In this example, the international brand of the campaign cards is M, but if the card company handles multiple international brands, it can designate any international brand as a campaign card. On the other hand, at Store B, purchases using the company's existing cards can be made as before, but it is not a campaign partner store, and even if a purchase is made at Store B using a campaign card, the special benefits mentioned above will not be granted. In other words, transactions using the merchant terminal 10-4 will ultimately be aggregated and processed by the issuer server 30 in the same way as before. The distinction between transactions, the setting of benefits, and the method of granting benefits will be described later.

[0014] In this example, Store A was set as the merchant eligible for the benefits, but it is not necessary to set the eligible merchants for the benefits for each business or store, nor is it necessary for them to be defined by physical stores. For example, each store (including online stores and physical stores), in other words, the minimum unit being an information processing device that connects to the acquirer server 20 and can exchange payment information, credit information, and other information necessary for commercial transactions, can be freely set by the card business operator.

[0015] The merchant terminal 10 is managed and operated by a business that provides goods and services to general consumers. Specifically, the merchant terminal 10 is an information processing device equipped with a processor, memory, communication interface, etc., which is installed in a store and operated by the store's staff, etc., and processes credit card payments. Alternatively, in online sales, the merchant terminal 10 may be implemented as a server or other information processing device managed by a business that operates an e-commerce site, and which accepts product orders and processes other operations.

[0016] Each franchise terminal 10 is identified by franchise identification information (MID). In FIG. 1, examples of MID101, MID102, MID103, and MID104 are shown. Note that the number of franchise terminals 10 shown is for illustration purposes and is arbitrary. In this example, franchise terminals 10-1 to 10-3 are operated by the same operator. Franchise terminal 10-4 is operated by an operator different from A Store.

[0017] Each franchise terminal 10 has a contract with one or more acquirer servers 20 and can purchase goods using a credit card issued by a card issuer that manages the issuer server 30. In addition, each franchise can also contract with other card issuers. In this example, at the A Store online store, contracts have been made with acquirer servers 20-1 and 20-3, and it supports both cards of international brand M and international brand V. When a consumer shops at the A Store online store using an M card, the settlement information is processed by acquirer server 20-3, and when shopping with an international brand V card, the settlement information is processed by acquirer server 20-1.

[0018] In the following, an example is shown where each store sells goods and a user purchases them, but the content of the goods or services handled by each store is arbitrary, and as a form of commercial transaction, in addition to purchase, lending or transfer may also be possible. In short, as long as the payment associated with the commercial transaction conducted at each franchise terminal 10 is made through a credit transaction.

[0019] The acquirer server 20 is managed and operated by a settlement agency (acquirer; generally a different entity from the card issuer and also called a "franchise contract company" or "card franchise management company", etc.) that enters into a contract with the franchise to perform the settlement agency process for commercial transactions conducted at the franchise using a credit card issued by the card issuer that operates the issuer server 30 and collects a fee.

[0020] The acquirer server 20 is responsible for mediating transactions between the merchant terminal 10 and the issuer server 30. Specifically, the acquirer server 20 is connected to one or more merchant terminals 10 under contract and performs payment processing (acquiring).

[0021] Each acquirer server 20 (20-1, 20-2, 20-3, 20-4) is uniquely identified by acquirer identification information (ICA). Figure 1 shows examples of ICA1, ICA2, ICA3, and ICA4. Note that the number of acquirer servers 20 shown is illustrative.

[0022] Each acquirer server 20 can contract with one or more international brands and process only cards of those international brands used by the contracted merchants. For example, the payment processor managing 20-1 contracts with international brand V and processes only payment information using cards of international brand V. This payment processor then contracts with 10-1, 10-2, and 10-3 and is responsible for processing payments made using V at Store A's online store, Store A's physical store, and Store A's physical store.

[0023] In this example, for the sake of explanation, each acquirer server 20 is connected only to the issuer server 30. However, it may also be connected to servers managed by other issuers (other card companies using international brand M) or servers managed by card companies using international brand V) to further perform payment processing for commercial transactions between these companies and merchants. In other words, there is no change to the information processing that each acquirer server 20 has been performing conventionally.

[0024] The merchant terminal 10, acquirer server 20, and issuer server 30 are implemented using a general-purpose computer with a hardware configuration consisting of, for example, memory, a processor, input means, and output means. The memory stores programs and data, and the processor executes the programs stored in memory to realize the functions of the terminal and server. In the following, the functions of the merchant terminal 10 and acquirer server 20 are the same as those used in conventional systems, so their explanations will be omitted, and the explanation will focus on the functions of the issuer server 30, which has features not found in conventional systems.

[0025] Figure 2 is a block diagram showing the functional configuration of the issuer server 30. Elements not related to the present invention have been omitted. The issuer server 30 includes a communication unit 310, a control unit 320, and a storage unit 330. The communication unit 310 is implemented as a communication interface for exchanging information with the acquirer server 20 and functions as receiving means 301 and receiving means 302.

[0026] The memory unit 330 is accessed by the control unit 320 and stores the program for realizing the operations described later, as well as the user management database DB1, the aggregation database RC, and the condition table TBL1. This program may be stored on a storage medium or downloaded via a telecommunications line and installed on a general-purpose computer.

[0027] The user management database DB1 stores user attribute information, account information, and card information (card numbers) issued to those users, which are necessary for credit checks and billing processes.

[0028] The conditions table TBL1 contains information set by the card company to identify campaign partner stores, the conditions for receiving benefits, and the details of the benefits. Figure 3 shows an example of the data stored in the conditions table TBL1. As shown in the figure, the conditions table TBL1 stores a serial number that uniquely identifies the conditions, MID, ICA, card number, benefit details, other conditions, and a pseudo-merchant number. The benefit details column describes the benefits granted for transactions at the pseudo-merchant.

[0029] Here, a pseudo-merchant is not a real store (physical or online) where a merchant terminal 10 is installed, but a virtual store set up virtually by the card business operator for the convenience of processing rewards and other processes on the issuer server 30, and associated with at least one real store (merchant terminal 10). As will be described later, a transaction at a real merchant will be managed as a transaction that took place at a virtual merchant, rather than a real merchant, if certain conditions are met.

[0030] The benefits include, for example, reduced or waived installment interest and fees, point accrual, cashback, and discounts on product prices. Reduced installment interest and fees means, for example, halving or reducing the interest and fees for installment payments by half or one-third. Point accrual means, for example, awarding points (typically having an economic value equivalent to money in transactions at the participating store or transactions using the credit card), or awarding more points (e.g., double) than the points awarded for normal transactions (transactions at non-campaign stores or transactions using non-campaign cards). Cashback means returning money to the purchaser. "Other conditions" describe additional conditions for awarding benefits, such as the purchase period (campaign period), specified products (campaign eligible products), and purchase amount (e.g., 10,000 yen or more). The pseudo-merchant number is a number set by the card company to identify the pseudo-merchant.

[0031] In this example, four simulated merchants, 991-1 to 991-4, are set up according to the benefits offered by the card provider. For example, in the case of condition serial number "1", if the MID is "101" (i.e., the purchase store is the online store of Store A), the ICA is "3" (acquirer server 20-3 processed the payment), and the first four digits of the card number are "1234************" (it is a campaign card), then a benefit of no interest charges on installment payments will be granted, and this transaction should be counted as pseudo-merchant number "999-1". Similarly, for condition serial number "2", if the MID is "102" (i.e., the purchase store is Store A's store A), the ICA is "2" (acquirer server 20-2 processed the payment), and a campaign card was used, then a benefit of half-price interest charges on installment payments will be granted, and this transaction should be counted as pseudo-merchant number "999-2".

[0032] The aggregation database RC is a database established to store payment information obtained from each merchant terminal 10-1 to 10-4 via each acquirer server 20. In the aggregation database RC, transactions made at non-campaign partner stores or at campaign partner stores using conventional cards (cards that are not campaign cards) are managed as store-specific sales, as before. In the diagram, store A A is recorded in aggregation database RC001, and store A B is recorded in aggregation database RC002.

[0033] Figure 4 will be used to explain in more detail how transaction information is aggregated. Figure 4 shows an example of transaction information stored in a database. Figure 4(a) is the aggregated database RC001 for Store A, Branch A (non-pseudo-franchise store transaction data). Figure 4(b) is the aggregated database RC002 for Store A, Branch A (non-pseudo-franchise store transaction data). In each database, one transaction generates one record. Each record is associated with a serial number corresponding to each transaction and includes the MID (the store where the transaction took place), the date and time the transaction occurred, the credit card number used for payment, and payment information. The payment information includes, for example, the purchase amount, the number of installments, and other information (such as a code that identifies the purchased item).

[0034] Returning to Figure 3, the aggregation databases RC999-1 (pseudo-merchant 1) and RC999-2 (pseudo-merchant 2) are databases that record payment information when a store is designated as a campaign partner store, the campaign card is used as the payment method, and the conditions for granting benefits are met. In this example, pseudo-merchant 1 and 2 are shown as separate databases for each benefit condition (the type of benefit that can be received), but it is also possible to have just one database to store payment information for stores designated as campaign partner stores where the campaign card was used, regardless of the type of benefit.

[0035] Figure 4(c) shows an example of the aggregate database RC999-1, which records transaction information when a transaction is made using a campaign card that meets the conditions for receiving a benefit such as interest-free installments under any of the campaigns. Similar to the aggregation databases RC001 and RC002, the aggregation database RC999-1 also generates one record for each transaction. Each record is associated with a serial number corresponding to each transaction and includes the MID (the store where the transaction took place), the date and time of the transaction, the credit card number used for payment, and payment information. The payment information includes, for example, the purchase amount, the number of installments, and other information (such as a code that identifies the purchased item).

[0036] Thus, in addition to the databases used for performing store-specific aggregations (aggregation databases RC001 and RC002) as before, issuer server 30 is also provided with databases (aggregation databases RC999-1 and RC999-2) to aggregate only transactions that meet the conditions of being at stores designated as campaign partner stores and having campaign cards used. By independently aggregating only the transactions that should be eligible for benefits in this way, the process of granting benefits can be easily carried out.

[0037] The control unit 320 is a processor and implements the functions of the credit processing unit 303, the settlement processing unit 304, the reward processing unit 305, and the reward setting unit 306.

[0038] The receiving means 301 receives transaction information and credit authorization requests from the acquirer server 20. The transaction information includes merchant identification information (MID), credit card number, acquirer identification information (ICA), etc. The received transaction information is supplied to the settlement processing unit 304. More specifically, when a commercial transaction occurs, the system receives transaction information from an acquirer server that includes merchant identification information identifying the merchant where the transaction took place, the credit card number used in the transaction, and acquirer server identification information identifying the acquirer server that received the transaction information from the merchant terminal.

[0039] The credit processing unit 303 performs a credit determination (authorization) based on the received credit request. It queries external databases such as CIC (not shown) and, based on the credit information, determines the credit result (approval / rejection of the transaction), sets a credit limit, and makes other preparations for conducting transactions using the company's own cards.

[0040] The reward setting unit 306 is responsible for issuing new campaign cards and setting rewards for existing cards. The set information is written to TBL1. Rewards are, for example, predetermined uniform rewards for commercial transactions at simulated member stores.

[0041] The reward processing unit 305 refers to TBL1 and the aggregation database RC, and for each pseudo-merchant, it grants rewards corresponding to the pseudo-merchant in a batch for transactions deemed to have been purchased at that pseudo-merchant. The reward granting process may be executed each time a record is added to the pseudo-merchant data, or it may be performed in a batch for all transaction records accumulated up to that point (for example, every week) at predetermined intervals (for example, every week).

[0042] In a preferred embodiment, the settlement processing unit 304 notifies an acquirer server 20 of the credit authorization result for the received settlement information, and processes the transaction separately from other transactions if the combination defined by the credit card number, acquirer identification information, and merchant identification information matches conditions predetermined by the issuer server 30. Preferably, the settlement processing unit 304 stores the transaction that matches the conditions as a transaction made at a pseudo-merchant rather than the actual merchant.

[0043] Specifically, the settlement processing unit 304 refers to the condition table TBL1 and determines whether the transaction indicated by the settlement information is a campaign-eligible transaction based on the settlement information received from the acquirer server 20. Specifically, the settlement processing unit 304 makes the above determination based on the card number, MID, and ICA included in the settlement information. For example, it is determined that a transaction is eligible for the campaign if all three of the following conditions are met. (1) Condition 1: The card used for payment must be a promotional card. (2) Condition 2: The MID must be from a store participating in the campaign. (3) Condition 3: ICA must correspond to MID.

[0044] Regarding condition 3, the reason for referring to ICA is that if a card issuer issues cards of multiple international brands, the acquirer server 20 cannot identify the international brand of the credit card and perform the clearing process. Furthermore, by checking the correspondence with MID, it is possible to detect tampering with transaction information or other fraudulent activity. For example, in Figure 1, the merchant terminal 10-1 (MID101) is connected to either ICA1 (20-1) or ICA3 (20-3), so MID101 corresponds to either ICA1 (20-1) or ICA3 (20-3). If the received transaction information contains both MID101 and ICA2, it raises suspicion that the transaction information may have been tampered with.

[0045] Figure 5 is a sequence diagram showing an example of the operation of the credit transaction system 100. Figure 6 is an example of the data structure exchanged, which should be referred to as appropriate. In S502, the card provider inputs the campaign details to the issuer server 30 via an input unit (not shown), and the reward setting unit 306 writes the necessary information to TBL1. After this, a campaign card is issued to a certain user. In S504, when this user specifies the campaign card as the payment method at one of the participating stores in the campaign, and specifies the desired products and other necessary information, a credit request is sent from the merchant terminal 10 to the issuer server 30 via the acquirer server 20 (S506, S508). As shown in Figure 6(c), the credit request received by the issuer server 30 includes the card number, MID, payment information, and ICA. The MID is the MID of the merchant terminal 10, and the ICA belongs to the acquirer server 20 that mediated the processing and was added by the acquirer server 20. Returning to Figure 5, at S510, the issuer server 30 performs a credit check (authorization). In S512 and S514, the credit assessment result is notified to the acquirer server 20 and the merchant terminal 10. Figure 6(d) shows an example of the data structure notified from the issuer server 30 to the acquirer server 20 and the merchant terminal 10. Here, we assume that the credit request has been approved (S516, transaction completed).

[0046] Next, in S518, the merchant terminal 10 transmits settlement information related to the completed transaction to the acquirer server 20. As shown in Figure 6(a), the data transmitted from the merchant terminal 10 to the acquirer server 20 includes the transaction serial number, MID, transaction date and time, card number, and settlement information. Upon receiving the settlement information from the merchant terminal 10, the acquirer server 20 adds its own ICA and transmits it to the issuer server 30 (S522), as shown in Figure 6(b). At the same time, the acquirer server 20 performs the prescribed acquiring process (payment of the purchase price to the merchant, collection of fees from the merchant, payment of fees to the international brand, etc.) (S520).

[0047] In S524, the issuer server 30 processes the received payment information. Specifically, it notifies the acquirer server 20 and its merchant terminal 10 that the payment has been completed (S525). Next, it performs aggregation processing. Specifically, it determines whether the card number, MID, and ICA meet the conditions registered in the condition table TBL1 (the three conditions mentioned above) (S528). If these three conditions are met, it aggregates the transaction as a transaction at a pseudo-merchant. If the conditions are not met, it aggregates the transaction as a normal transaction (S530). Subsequently, issuer server 30 refers to the aggregate database RC to collect interest and fees from the user and provide the benefits specified in TBL1 (S532).

[0048] As described above, according to the embodiment, the issuer server 30 can determine whether a transaction is eligible for a campaign based on the payment information it has received conventionally, and card companies can freely grant benefits without making any changes to the processing at the merchant terminal 10 or the acquirer server 20. Therefore, for example, even if a merchant's policy is to contract only with a specific payment processing company and does not allow so-called on-us contracts with individual card issuers, the issuer server 30 allows card companies to provide their merchants with a variety of services, such as awarding double the usual points to members of a campaign card or offering preferential interest rates. This is expected to revitalize the credit transaction industry and bring benefits to all parties involved in credit transactions, including card companies, general consumers, merchants, and acquirers.

[0049] Furthermore, by aggregating campaign-eligible transactions as transactions at simulated merchants, issuers no longer need to manually verify the merchant names listed in the sales data, making the reward distribution process easier.

[0050] Furthermore, if the acquirer does not authorize an on-us agreement, it is in principle possible to offer special conditions to co-branded cardholders through methods such as modifying the POS system, expanding cashback programs, or extending points programs. For example, a mechanism could be introduced into the merchant's POS system to identify co-branded cards and apply special conditions based on the card number and the card's international brand information, or the card issuer could provide cashback at a later date based on the amount spent by the co-branded cardholder at a specific merchant. However, such methods are expected to incur system modification costs and become complicated to operate. In contrast, the above embodiment processes payment information obtained in the conventional system, and only requires the creation of a condition table and modifications to the database structure, thus reducing the cost of system modification.

[0051] In the above embodiment, the issuer server 30 is shown to be implemented on a single piece of hardware, but the functions of the issuer server 30 may be distributed and implemented across multiple hardware devices. In short, the credit transaction method according to the present invention is a system having a plurality of merchant terminals into which commercial transaction information is entered, one or more acquirer servers connected to the merchant terminals and performing payment processing, and an issuer server connected to the acquirer server and managing credit information. When a commercial transaction occurs, the system is configured to receive transaction information from the acquirer server, which includes merchant identification information that identifies the merchant in which the transaction took place, the credit card number used in the transaction, and acquirer server identification information that identifies the acquirer server that received the transaction information from the merchant terminal. The system is configured to notify the acquirer server of the credit result for the received transaction information, and if the combination defined by the credit card number, the acquirer identification information, and the merchant identification information matches conditions predetermined by the issuer server, the system is configured to store the transaction separately from other transactions. [Explanation of symbols]

[0052] 10... Merchant terminal, 20... Acquirer server, 30... Issuer server, 100... Credit transaction system, 310... Communication unit, 320... Control unit, 330... Storage unit, 302... Receiving means, 301... Receiving means, 303... Credit processing unit, 304... Settlement processing unit, 305... Reward processing unit, 306... Reward setting unit

Claims

1. In a credit transaction system comprising multiple merchant terminals into which commercial transaction information is entered, one or more acquirer servers connected to the merchant terminals to perform payment processing, and an issuer server connected to the acquirer servers to manage credit information, When a commercial transaction occurs, the issuer server receives from the acquirer server transaction information which includes merchant identification information that identifies the merchant where the commercial transaction took place, the credit card number used in the commercial transaction, and acquirer identification information that identifies the acquirer server that received the transaction information from the merchant terminal. The issuer server notifies the first acquirer server of the credit assessment result for the received transaction information, and stores the commercial transaction separately from other commercial transactions if the combination defined by the credit card number, the acquirer identification information, and the merchant identification information matches the conditions predetermined by the issuer server. Credit transaction management method.

2. The issuer server manages commercial transactions that meet the above conditions as transactions that took place at a pseudo-merchant rather than at the actual merchant. The credit transaction management method according to claim 1.

3. The issuer server grants predetermined, uniform benefits to commercial transactions at the pseudo-merchant. The credit transaction management method according to claim 2.

4. The aforementioned benefits include at least one of the following: reduction or waiver of installment interest charges, awarding of points, cashback, and discounts on product prices. The credit transaction management method described in claim 3.

5. An information processing device that manages credit information, connected to multiple merchant terminals into which commercial transaction information is entered, and to one or more acquirer servers connected to the merchant terminals and performing payment processing, When a commercial transaction occurs, a means for receiving transaction information from an acquirer server, which includes merchant identification information identifying a merchant where the transaction took place, the credit card number used in the transaction, and acquirer identification information identifying an acquirer server that received the transaction information from the merchant terminal, The credit assessment result for the received transaction information is notified to the acquiring server, and if the combination defined by the credit card number, the acquiring identification information, and the merchant identification information matches predetermined conditions, there is a means to store the commercial transaction separately from other commercial transactions. An information processing device having

6. A credit transaction system comprising: multiple merchant terminals into which commercial transaction information is entered; one or more acquirer servers connected to the merchant terminals and performing payment processing; and one or more issuer servers connected to the acquirer servers and managing credit information, When a commercial transaction occurs, a means for receiving transaction information from an acquirer server, which includes merchant identification information identifying a merchant where the transaction took place, the credit card number used in the transaction, and acquirer identification information identifying an acquirer server that received the transaction information from the merchant terminal, The issuer server notifies the acquirer server of the credit decision result for the received transaction information, and if the combination defined by the credit card number, the acquirer identification information, and the merchant identification information matches the conditions predetermined by the issuer server, it has means to store the commercial transaction separately from other commercial transactions. Issuer servers that have A credit transaction system that it possesses.

Images