Credit card company system that perform credit card settlement, settlement method, and program thereof
The card company system enhances user monitoring of credit card usage by requiring direct reporting and three-step authorization, enabling early detection of fraudulent transactions.
Patent Information
- Application Number
- JP2025166176
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-10-02
- Publication Date
- 2025-12-05
AI Technical Summary
Existing credit card systems only allow users to check their usage history from statements issued by the card company, which are delayed and may miss small, fraudulent transactions made long ago.
A card company system that requires users to report their card usage directly to the card company, integrating a three-step authorization process involving card authorization, sales data from affiliated stores, and user declarations, with notifications for undeclared usage.
Enables cardholders to monitor fraudulent use proactively, increases awareness of card usage, and facilitates early detection of fraudulent transactions.
Smart Images

Figure 2025178472000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a card company system for credit card settlement. [Background technology]
[0002] Many methods for preventing fraudulent use of cards such as credit cards have been known for some time. For example, Patent Document 1 discloses a system in which, when an inquiry server receives a credit card authentication inquiry or credit inquiry via a communication line from a credit card authentication terminal installed at a credit card member store, the inquiry server retrieves the member information of the inquired member from a member database, notifies the email address included in the member information that the card will be used, and, if it is confirmed that this notification will likely reach the credit card member's mobile terminal, notifies the credit card authentication terminal that the credit card can be used.
[0003] Patent document 2 also discloses a system in which an authorization server includes a storage unit that stores approval conditions (such as the credit card being recognized by a specific card reader, or the card reader being within a specific geographical range) associated with the credit card's identification information and indicating that a credit card transaction will be approved if the credit card is recognized by a card reader, a receiving unit that receives a credit card transaction request including the credit card's identification information and card recognition information including information indicating whether the credit card is recognized by the card reader, and an approval unit that approves the credit card transaction request on the condition that the receiving unit has received the card recognition information when the storage unit stores the approval conditions associated with the identification information included in the credit card transaction request. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2005-62957 [Patent Document 2] Japanese Patent Publication No. 2020-173512 Summary of the Invention [Problem to be solved by the invention]
[0005] The systems described in the above patent documents are effective methods for preventing fraudulent card use. However, cardholders can usually only check their card usage history from the statement issued by the card company. These statements are only entered after the affiliated store's sales data is submitted to the card company at different times for each affiliated store, so users often do not notice small transactions, especially those made long ago.
[0006] Therefore, in consideration of the above-mentioned problems, the present invention aims to provide a new method that allows card members to monitor fraudulent use of their cards (including fictitious billing) themselves. [Means for solving the problem]
[0007] In order to solve the above problems, the present invention provides the following solutions.
[0008] (1) A card company system for making payments using a user's credit card, characterized by comprising: an authorization processing means for authorizing the user's credit card based on an authorization request from an affiliated store that accepts payments using the credit card; an affiliated store payment processing means for processing payments with the affiliated store based on sales data from the affiliated store; and a usage declaration acceptance means for accepting a usage declaration for the credit card created by the user on a user terminal based on information obtained from the affiliated store.
[0009] (2) In the configuration described in (1) above, it is characterized by being provided with a user settlement means for processing the settlement with the user, provided that the authorization result of the credit card, sales data from the affiliated store, and a usage declaration from the user are all present.
[0010] (3) In the configuration described in (1) or (2) above, the usage declaration acceptance means is characterized in that the user terminal of the user reads the receipt issued by the affiliated store and receives information about the receipt from the user terminal.
[0011] (4) In the configuration described in any one of (1) to (3) above, the device is characterized by having an undeclared notification means for notifying the user that a usage declaration has not been made if the user has not made a usage declaration by the card's billing settlement date.
[0012] (5) In the configuration described in (4) above, the non-filing notification means is characterized by having a means for accepting a user who receives a non-filing notification to choose one of the following actions: “file immediately,” “suspend filing and request investigation,” or “reject claim.”
[0013] (6) In the configuration described in any one of (1) to (5) above, the status of the usage declaration is displayed for each billing from the affiliated store on the credit card's web statement.
[0014] (7) A payment method for making a payment with a user's credit card, characterized in that the system of the card company of the credit card executes the steps of: authorizing the user's credit card based on an authorization request from an affiliated store that accepts payment with the credit card; processing the payment with the affiliated store based on sales data from the affiliated store; and accepting a declaration of use of the credit card created by the user on a user terminal based on information obtained from the affiliated store.
[0015] (8) A program that causes a computer to execute each step described in (7) above. [Effects of the Invention]
[0016] According to the present invention, a new method can be provided that enables card members themselves to monitor fraudulent use of their cards (including fictitious charges). [Brief explanation of the drawings]
[0017] [Figure 1] FIG. 1 is a diagram showing a comparison between a conventional payment process at a card company and the payment process of this system. [Figure 2] FIG. 2 is a diagram showing functional blocks of a card company's system according to an embodiment of the present invention. [Figure 3] FIG. 10 shows an example of a self-reporting means. [Figure 4] FIG. 10 is a diagram showing a processing flow of a settlement executed by a card company system. [Figure 5] FIG. 10 is a diagram showing an example of a screen for notifying a usage statement. [Figure 6] FIG. 10 is a diagram showing an example of a non-filing notice. DETAILED DESCRIPTION OF THE INVENTION
[0018] A system (hereinafter referred to as the present system) relating to an embodiment (an embodiment) of the present invention will be described below with reference to the drawings. In the following figures, the same elements are assigned the same numbers or symbols throughout the description of the embodiment. In addition, in the diagrams of the functional configuration, arrows between functional blocks indicate the direction of data flow or the direction of processing flow.
[0019] (Traditional credit card payment processing) Figure 1(A) shows an overview of the conventional payment process that takes place between a member store and a card company. In the following, we will refer to credit cards simply as cards. Note that the numbers in parentheses below correspond to the circled numbers in the diagram.
[0020] (1) A card member presents the card at an affiliated store where the card can be used and requests the purchase of a product or service (hereinafter referred to as a product, etc.). (2) When a merchant receives a purchase request, it reads the card information presented and sends an authorization request to the card company along with the card information and sales information (sales data). Authorization here refers to the process by which the card company confirms whether the presented card can be used for payment, and is also called "credit approval" or "sales approval." (3, 4) The card company checks the card information sent by the merchant to determine whether the card is legitimate, has not expired, the amount after the purchase will not exceed the user's credit limit, etc. It then returns the result of the determination (authorization result) to the merchant. (5, 6) The merchant checks the authorization result sent back from the card company. If there are no problems with the authorization result, the merchant provides the product to the customer. At this point, the transaction between the merchant and the customer is complete. (7, 8) After that, the affiliated store processes the sales within the authorization expiration date. In other words, it sends the sales data of the card payment to the card company. The timing of sending the sales data varies depending on the affiliated store. (9,10) The card company processes the payment to the merchant based on the sales data sent. At this time, it calculates the card usage fee based on the contract with the merchant. The payment between the card company and the merchant is completed when the sales amount after deducting the fee is paid to the merchant. (11-13) Finally, as part of the user settlement process, the card company notifies the user of the final billing amount for the current month's card usage, and debits the amount from the user's registered account on the designated payment date.
[0021] However, with this conventional method, users can only confirm their own usage history after the sales data from the affiliated store has been submitted to the card company, and even if their card has been used fraudulently, unless they check their online statement every day, they will only notice after the billing amount has been confirmed (approximately one month later).
[0022] (Credit card payment processing for this system) In this system, cardholders report their card usage to the card company, and the card company will bill only when all three elements (card authorization processing, sales data from the affiliated store, and usage report from the member) are met, instead of the two elements previously required (card authorization processing, sales data from the affiliated store), and will notify the member that any usage not reported may be misused.
[0023] More specifically, as shown in FIG. 1(B), the above processes (1) to (10) are the same as those in the conventional method, but the following process is added in this system. (11) The user sends a usage report to the card company to report that they have purchased a product, etc. with their card. The report is generally sent at the same time as or after the purchase, but can be sent before the purchase if the purchase is 100% confirmed. (12) Upon receiving the usage report, the card company registers the usage report in the card usage information. (13-15) Finally, in the user payment process by the card company, the user is charged the final invoice amount for the current month, subject to the completion of authorization (3), settlement of sales data (merchant payment processing) (9), and registration of usage declaration (12), and the amount is debited from the account registered by the user on the designated payment date.
[0024] In this way, while traditional credit card payment authentication was done in two steps: completing authorization and checking sales data, payment authentication with this method is done in three steps (three way authorization).
[0025] (function block) 2 is a diagram showing the functional blocks of a card company's system according to one embodiment of the present invention. As shown in the figure, the card company system 100 of this embodiment includes an authorization processing means 101, a card usage information DB 102, an affiliated store payment processing means 103, an affiliated store information DB 104, a usage declaration receiving means 105, a user payment means 106, and an undeclared notification means 107.
[0026] The authorization processing means 101 receives sales information (purchase amount, merchant identification information, etc.) and card information of the card the user is attempting to use from the affiliated store terminal 200, such as a store cash register, performs the authorization determination described above, and returns the determination result. If there are no problems with the determination result, the card's credit limit is secured. At this time, information indicating that the authorization has been successfully completed, called an authorization code, is sent to the affiliated store terminal 200.
[0027] Furthermore, if the affiliated store is a brick-and-mortar store, the authorization processing means 101 (including other means for determining the validity of the card) may determine, based on the location information of the user's mobile device, that card use from a location other than the affiliated store is likely to be fraudulent. Furthermore, if the affiliated store is an online store, the authorization processing means 101 may determine, based on the registered location information of the user's fixed device, that card use from a location other than the registered location is likely to be fraudulent. This is because many users are likely to make payments at online stores using larger screens, such as their home PCs or tablets, rather than the small screens of their smartphones. Of course, if there is a possibility of fraudulent use, the user may be notified. However, because the user's phone number and email address may be known to malicious users, the URL of the member site should not be included when notifying the user by email (including SMS). This is because there is a possibility that the member site may be forged and the login ID and password may be stolen.
[0028] The card usage information DB 102 is a database that stores all registration information and usage information for each user and each card. In this system, the card usage history and usage details are also stored in this DB, but they may also be stored in separate DBs.
[0029] The member store payment processing means 103 checks the sales data sent from the member store (not necessarily from the member store terminal 200, but also from other member store systems) at a timing determined for each member store, and if it is within the authorization expiration date, performs sales processing for the member store. In other words, it performs processing to deduct a predetermined fee from the sales amount included in the member store's sales data and pay the amount to the member store.
[0030] The affiliated store information DB 104 is a database that stores, for each affiliated store, the registration information, contract information, usage information, etc. There may be multiple affiliated store information DBs 104, one for each region or type of business of the affiliated store.
[0031] The usage report receiving means 105 receives a usage report from the user terminal 300 in which the user reports that they have purchased a product or the like with the card, and registers the usage report in the card usage information DB 102. The card usage information DB 102 also stores information on family cards and the like, linked to the parent card. An example of the usage report receiving means 105 will be described later.
[0032] As already mentioned, the card company system 100 determines the amount to be charged to the user only after this usage report has been submitted. The usage report is submitted voluntarily by the user, not in response to any inquiry from the card company. If the card company were to make an inquiry to the user, and if member information has also been stolen, the inquiry would be directed to the abuser, and abuse could not be prevented. For this reason, as a general rule, the user himself / herself is required to submit the usage report for the card.
[0033] However, in cases where a user fails to report a card due to malice or negligence, if the cardholder fails to report the card usage by the specified billing settlement date, the cardholder will also be billed for the unreported usage. Therefore, users are required to report card usage in advance and check their card details online to ensure there is no misuse, which increases users' awareness of preventing fraudulent use. As mentioned above, the authorization processing means 101 may also acquire location information from the user terminal 300 (a mobile terminal) when the card is used for payment, and may consider the card usage to be misused if the user is not present at the affiliated store (excluding online stores). Many users likely only use fixed terminals, such as home PCs or tablets, at online stores. Such users may be required to register the location information of their fixed terminals, and payments at online stores made using terminals other than those registered in this location may be deemed to be fraudulent use.
[0034] Furthermore, when making payments using Apple Pay (registered trademark) or QR Code (registered trademark) on a smartphone or other device, identity verification is performed using fingerprint authentication, facial recognition, etc. when the smartphone is turned on, so reporting the usage at that time can save time. Also, to provide an incentive for reporting, points can be doubled for self-reported payments. It is also preferable to report each payment to avoid mistakes at the register.
[0035] The user payment means 106 bills the user for the current month's payment, provided that the authorization code received by the authorization processing means 101, the sales data received by the affiliated store payment processing means 103, and the usage declaration accepted by the usage declaration accepting means 105 have been registered. That is, it sends a billing confirmation notice to the user terminal 300. For users who do not use web statements, it sends the billing confirmation notice together with the usage statement by mail. Thereafter, it debits the billing amount from the user's account on the specified payment date, and the payment for the current month is completed.
[0036] The non-declaration notification means 107 sends a non-declaration notification to the user for card usage that has not been declared by the billing settlement date of the current month. In this case, even if the usage has not been declared, the user will be billed in principle, but if it is discovered later that the usage was fraudulent, it is possible to take relief measures such as refund.
[0037] The functional configuration of the present system shown in Figure 2 above is merely an example. A single functional block (database and functional processing unit) may be divided, or multiple functional blocks may be combined into a single functional block. Each functional processing unit is implemented by a central processing unit (CPU) built into the device that reads a computer program stored in a storage device, such as a read-only memory (ROM), flash memory, solid-state drive (SSD), or hard disk, and executes the computer program. That is, each functional processing unit is implemented by the computer program reading and writing necessary data, such as tables, from a database (DB) stored in the storage device or a memory area in memory, and, in some cases, controlling related hardware (e.g., an input / output device, a display device, or a communication interface device). Furthermore, the database (DB) in the embodiments of the present invention may be a commercial database, but it also refers to a simple collection of tables and files, regardless of the internal structure of the database itself.
[0038] FIG. 3 is a diagram showing a specific example of the usage report receiving means 105. In this example, a user does not have a physical card, but makes a payment at an affiliated store using a credit card registered on their smartphone. The user launches the Wallet app on their smartphone (user terminal 300) and selects the card 301 (an image of the card face) to be used for payment. Then, when the user holds the smartphone over the card reader 211 of the store's cash register 210 (affiliated store terminal 200), the card information of the card 301 is sent via the cash register to the card company system 100, and an authorization request is made. Once the card authorization is complete, a receipt 400 is issued from the receipt issuing machine 212. If the affiliated store is an online store, the receipt can be obtained from the online store's website.
[0039] The user checks this receipt 400, and if the names of the purchased items and the payment amount are correct, they take a picture of the receipt 400 with their smartphone camera or read the QR code (registered trademark) printed on the receipt and save the data of the receipt 400. It would be better if the cash register had a function to send receipt data to a smartphone instead of issuing a paper receipt.
[0040] The user logs into the card company's member website from their smartphone at the same time as the purchase, or as soon thereafter as possible (at the latest by the date the card payment amount is finalized), and taps the "Usage Report Button" 302 to display the usage report menu 303. From this usage report menu 303, the user taps the "Read receipt and report" button 304 and selects the receipt they wish to report (the selected receipt is underlined in the figure), allowing them to display the data of the receipt they wish to report from among the receipts saved on their smartphone. It is preferable, but not essential, that the receipt display a list of the names of the products purchased.
[0041] When this receipt is selected and the "Declaration Button" 305 is tapped, a declaration of the use of the payment corresponding to that receipt is sent to the card company. At this time, text data of the necessary information is extracted from the image of the receipt using image analysis and OCR technology.
[0042] If you forget to save the receipt to your smartphone, instead of scanning the receipt, you can tap the "Declare from Input Screen" button 306 to display the declaration input form, where you can enter the necessary information to declare. The required input information here is the minimum information necessary to identify the payment, such as the abbreviation of the card used for the payment (e.g., "SMB XX"), the approximate date and time of use (e.g., around 1:00 PM on the 22nd), the abbreviation of the store used (e.g., "Convenience Store XX"), and the first digit of the amount used (e.g., "1" if the total payment amount was ¥1,350). Of course, if you have a paper receipt, you can enter more accurate information from there. Incidentally, the card number, cardholder name, etc. can be identified from the Wallet app on your smartphone, simplifying the input process.
[0043] (Processing flow) 4 is a diagram showing the processing flow of the settlement executed by the card company system 100. In this processing flow diagram (flowchart), the processing order of each step may be changed as long as the relationship between input and output of each step is not affected.
[0044] When the card company system 100 (hereinafter simply referred to as the card company) receives any data, it first checks whether the data is sales data (step S10). Then, it checks whether authorization has been successfully completed based on the authorization code corresponding to the sales data (step S11). If the data received in step S10 is not sales data from an affiliated store, it proceeds to step S20.
[0045] If authorization is not completed successfully in step S11, the merchant is notified of the error and the process ends (step S12). However, if authorization is completed successfully, the specified fee for card usage is calculated from the sales data (step S13). The fee is then deducted from the sales amount and the remaining amount is sent to the merchant (step S14). Up to this point, the process is the same as the normal merchant payment process.
[0046] If the data received in step S10 is not sales data from an affiliated store, a check is made to see if it is a declaration from the user (usage declaration) (step S20). If it is not a usage declaration, the process ends here and moves on to another process. However, if it is a usage declaration, a check is made to see if the current date and time is the billing confirmation date and time (usually 23:59 on the confirmation date) (step S21). If the current date and time is the billing confirmation date and time, the amount billed to the user is confirmed (step S22). Then, if there is a payment that has not been declared for use among the payments to be billed, a non-declaration notice is sent to the user (step S23), but the billing process itself is carried out as usual (step S24). Note that the process of step S23 may be performed several days before the billing confirmation date to give the user time to confirm.
[0047] In step S21, if the current date and time is not the billing confirmation date and time, a reported flag is entered for that usage in the usage details (step S25). Note that the processing of steps S22 to S24 is automatically performed when the billing confirmation date and time arrives, even if it is not when the usage report is received.
[0048] (Example usage details screen) Figure 5 is a diagram showing an example of a screen that notifies the user of a transaction statement. The transaction statement screen 310 shown in the figure is the web statement screen that is displayed when the user logs in to the card company's member site. The web statement displays the current month's transaction amount, which is included in the sales data received from the affiliated store up to that point. If the user does not use the web statement, the transaction statement will be sent by mail after the billing has been finalized.
[0049] In this example screen, the current billing amount is displayed as unconfirmed in "Scheduled Payment Amount." It also shows that the billing amount for this month was confirmed on the 12th, with the payment date (account withdrawal date) being the 27th. If you hold multiple cards with one card company, select the card for which you want to see the statement details in the card selection field 311. What makes this statement screen 310 different from a regular web statement is that it displays a field for usage reports 312. Check marks in the usage reports for each billing indicate that the user has already reported it. Here, the absence of a check mark in the billing for 2020 / 11 / 23 indicates that the user has not confirmed that they used their card on that day.
[0050] In such cases, the user may have forgotten to file a claim, or may have become suspicious of the claim and requested an investigation from the card company. If such an investigation is ongoing, a notice to that effect may be displayed in the usage report field. However, if confirmation is not received by the billing settlement date and the claim remains unfiled, the user will be notified of the unfiled claim (described below), and the claim itself will proceed as normal.
[0051] Among fraudulent card use cases, fictitious charges in particular are often made for relatively small amounts, as in this example, and are therefore easily overlooked. However, this system makes it easier to detect fictitious charges by notifying the user of such conditions. This is because fictitious charges may continue month after month if the user does not notice. Of course, if fraudulent use, not limited to fictitious charges, is discovered after the charge has been made, the user can request a refund. Although not shown in the figure, charges that are determined to be potentially fraudulent at the authorization stage may be displayed on the usage details screen 310 or a notification to that effect may be sent.
[0052] FIG. 6 illustrates an example of a non-filing notification. The non-filing notification screen 320 shown in the figure is notified to the user via email or other means, and is also displayed after the user logs in to the card company's member website. However, because the user's phone number and email address may be known to fraudsters, the non-filing notification does not include a URL for filing. Upon receiving the non-filing notification, the user selects a course of action in response to the non-filing notification from the action selection field 321. Here, the user can choose to "file immediately," "suspend the filing and request a card investigation," or, in the case of obvious fraudulent use, "reject the charge due to lack of knowledge." However, if an investigation is requested but is not completed by the billing settlement date, the billing itself will be executed. The same applies if the user rejects the billing but the card company's investigation reveals no fraudulent use. Although not illustrated, charges determined to be potentially fraudulent at the authorization stage may also be displayed on the non-filing notification screen 320.
[0053] (Effects of the embodiment) First, this system provides a new method for monitoring fraudulent card use by having cardholders themselves report each card transaction to their card company, which also increases users' awareness of fraudulent use.
[0054] In addition, if the user does not report the use by the date of the card billing settlement, the card is provided with a non-reporting notification means for notifying the user that the report has not been made, so that the possibility of fraudulent use can be discovered early.
[0055] Furthermore, the usage report receiving means is implemented by the user's user terminal reading the receipt issued by the affiliated store and receiving the receipt information from the user terminal, thereby reducing the effort required for usage report.
[0056] Furthermore, the non-filing notification means is provided with a means on the notification screen that allows the user who receives the non-filing notification to select one of "file immediately," "suspend filing and request investigation," or "reject the claim," so that an action in the case of non-filing can be taken immediately.
[0057] In addition, the status of usage declarations will be displayed on the credit card's web statement for each bill from the affiliated store, allowing users to easily see at a glance whether or not a declaration has been made for the current month.
[0058] In addition, based on the location information of the terminal at the authorization stage, it will be possible to determine the possibility of fraudulent use, whether at a physical store or an online store.
[0059] In the above embodiment, the explanation is mainly on credit cards, but the invention can also be applied to other payment methods such as debit cards and XX Pay (also known as smartphone payment or app payment). In the case of debit cards, the money is immediately debited from the account after authorization processing (which corresponds to checking the account balance), but the same applies in that fraudulent use can be easily detected early if the user reports the use. The same applies to XX Pay credit cards and payment methods that automatically debit from bank accounts.
[0060] Although the present invention has been described above using the embodiments, it goes without saying that the technical scope of the present invention is not limited to the scope described in the above embodiments. It will be apparent to those skilled in the art that various modifications and improvements can be made to the above embodiments. Furthermore, it is clear from the claims that such modifications and improvements can also be included within the technical scope of the present invention.
[0061] In the above embodiment, the present invention has been described as an invention of a product, namely, a card company system (or a card company server), but the present invention can also be regarded as an invention of a payment method or a computer program therefor. [Explanation of symbols]
[0062] 100 Card company system 101 Authorization Method 102 Card usage information DB 103 Merchant payment processing means 104 Member store information DB 105 Usage notification acceptance method 106 User payment methods 107 Notification of non-filing 200 Merchant terminal 210 Registers 211 Card Reader 212 Receipt issuing machine 300 User terminal 301 Card (Image of card face) 302 Usage Report Button 303 Usage Report Menu 304 "Read receipt and declare" button 305 Declaration button 306 "Declare from input screen" button 310 Usage details screen 311 Card selection column 312 User Declaration Column 320 Undeclared Notification Screen 321 Action selection field for non-filing notice 400 Receipt
Claims
1. A card company system for making payments using a user's credit card, an authorization processing means for authorizing the credit card of the user based on an authorization request from an affiliated store that accepts payment by credit card; A member store payment processing means for performing payment processing with the member store based on sales data from the member store; a credit card usage report receiving means for receiving a credit card usage report prepared by the user on a user terminal based on information obtained from the member store; A card company system comprising:
2. 2. The card company system according to claim 1, further comprising a user settlement means for carrying out settlement processing with the user on the condition that the authorization result of the credit card, sales data from the affiliated store, and a usage declaration from the user are all present.
3. The card company system according to claim 1 or 2, characterized in that the usage declaration acceptance means is performed by the user's user terminal reading a receipt issued by the affiliated store and receiving information about the receipt from the user terminal.
4. 4. The card company system according to claim 1, further comprising: an undeclared notification means for notifying the user that a usage report has not been made if the user has not made the usage report by the card billing settlement date.
5. The card company system according to claim 4, wherein the non-filing notification means includes a means for accepting a user who has received the non-filing notification from selecting one of the following actions: "file immediately," "suspend filing and request investigation," or "reject the claim."
6. 6. The card company system according to claim 1, wherein the status of the usage declaration is displayed for each bill from the affiliated store in the web statement of the credit card.
7. A payment method for making a payment by a user's credit card, The credit card company's system a step of authorizing the credit card of the user based on an authorization request from an affiliated store that accepts payment by credit card; performing a settlement process with the affiliated store based on sales data from the affiliated store; A step of accepting a declaration of use of the credit card created by the user on a user terminal based on information obtained from the member store; A payment method characterized by executing the following.
8. A program causing a computer to execute the steps set forth in claim 7.
Citation Information
Patent Citations
Security system for credit card transactions
JP2005062957A
System, card reader, and program
JP2020173512A