Payment system, payment method, and program

Abstract

Improve user convenience. [Solution] The setting acquisition unit (104) of the payment system (1) acquires the settings for installment payments, revolving payments, or bonus payments of the payment methods available to the user. The processing execution unit (102) executes processing related to installment payments, revolving payments, or bonus payments based on the settings. The setting cancellation unit (105) cancels the settings based on predetermined cancellation conditions.

Description

[Technical Field]

[0001] The present disclosure relates to a payment system, a payment method, and a program. [Background technology]

[0002] Conventionally, payment services provided by a payment app stored in a user terminal have been known. For example, Patent Document 1 describes a payment system in which a user acquires, via a payment app, an installment interest-bearing ticket that allows the affiliated party to cover the fees for purchasing a product or service sold by the affiliated party in installments, and makes installment payments using the installment interest-bearing ticket. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7097487 [Overview of the Initiative] [Problem to be solved by the invention]

[0004] However, with the technology of Patent Document 1, although users can make installment payments using installment interest-bearing tickets, they cannot configure settings related to installment payments on the payment app, nor can they cancel such settings. For this reason, the technology of Patent Document 1 does not sufficiently improve the convenience of users of payment apps. This point is not limited to installment payments as in Patent Document 1, but also applies to revolving payments or bonus payments. Furthermore, it is also true for payment services for which payment apps are not particularly used. For this reason, conventional technologies have not sufficiently improved the convenience of users.

[0005] One of the purposes of the present disclosure is to improve user convenience. [Means for solving the problem]

[0006] The payment system according to the present disclosure includes a setting acquisition unit that acquires settings related to installment payments, revolving payments, or bonus payments for payment methods available to a user, a processing execution unit that executes processing related to the installment payments, revolving payments, or bonus payments based on the settings, and a setting cancellation unit that cancels the settings based on specified cancellation conditions. [Effects of the Invention]

[0007] The present disclosure can improve convenience for users. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of a hardware configuration of the payment system according to the first embodiment. [Figure 2] FIG. 10 is a diagram illustrating an example of a screen of a payment application. [Figure 3] FIG. 10 is a diagram illustrating an example of a screen of a payment application. [Figure 4] FIG. 2 is a diagram illustrating an example of functions implemented in the payment system of the first embodiment. [Figure 5] FIG. 10 is a diagram illustrating an example of a payment database. [Figure 6] FIG. 10 is a diagram illustrating an example of a card database. [Figure 7] FIG. 2 is a diagram illustrating an example of processing executed in the payment system of the first embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of processing executed in the payment system of the second embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of functions realized in the payment system of the second embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of processing executed in the payment system of the second embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of processing executed in the payment system of the third embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of functions realized in the payment system of the third embodiment. [Figure 13]FIG. 11 is a diagram illustrating an example of processing executed in the payment system of the third embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of processing executed in the payment system of the fourth embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of functions realized in the payment system of the fourth embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of processing executed in the payment system of the fourth embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of functions realized in a modification of the first embodiment. [Figure 18] FIG. 10 is a diagram showing an example of a code screen according to Modification Example 1-1. [Figure 19] FIG. 10 is a diagram showing an example of a code screen according to Modification Example 1-2. [Figure 20] FIG. 10 is a diagram showing an example of a screen of a payment application in Modification Example 1-3. [Figure 21] FIG. 10 is a diagram showing an example of a setting screen in Modification Example 1-4. [Figure 22] FIG. 10 is a diagram showing an example of a charge screen in Modification Example 1-6. [Figure 23] FIG. 11 is a diagram showing an example of a confirmation screen in Modification Example 1-12. [Figure 24] FIG. 10 is a diagram illustrating an example of functions realized in a modified example of the second embodiment. [Figure 25] FIG. 10 is a diagram illustrating an example of a processing result notification. [Figure 26] This figure shows an example of a payment notice. [Figure 27] FIG. 10 is a diagram illustrating an example of a change inquiry. [Figure 28] FIG. 11 is a diagram illustrating an example of functions realized in a modification of the third embodiment. [Figure 29] FIG. 10 is a diagram showing an example of a screen displayed on a user terminal in Modification Example 3-2. [Figure 30] FIG. 10 is a diagram illustrating an example of a setting cancellation notification. [Figure 31] FIG. 13 is a diagram illustrating an example of functions realized in a modification of the fourth embodiment. [Figure 32]FIG. 10 is a diagram showing an example of a confirmation screen of Modification Example 4-2. [Figure 33] FIG. 10 is a diagram showing an example of a code screen according to Modification Example 4-3. [Figure 34] This figure shows an example of the confirmation screen for Modification 4-4. [Figure 35] FIG. 10 is a diagram illustrating an example of a charge inquiry. [Figure 36] FIG. 10 is a diagram showing an example of a usage history screen of Modification Example 4-7. [Figure 37] This figure shows an example of the completion screen for modified example 4-15. DETAILED DESCRIPTION OF THE INVENTION

[0009] [1. First embodiment] A first embodiment, which is an example of an embodiment of a payment system, a payment method, and a program according to the present disclosure, will be described.

[0010] [1-1. Hardware configuration of the payment system of the first embodiment] Fig. 1 is a diagram showing an example of the hardware configuration of a payment system according to the first embodiment. For example, the payment system 1 according to the first embodiment includes a payment server 10, a card server 20, a user terminal 30, and a store terminal 40. Each of the payment server 10, the card server 20, the user terminal 30, and the store terminal 40 is connected to a network N such as the Internet or a LAN. Note that there may be multiple units of at least one of the payment server 10, the card server 20, the user terminal 30, and the store terminal 40.

[0011] The payment server 10 is a server computer for a payment service. The payment service is a service that provides users with electronic payments (cashless payments). For example, the payment server 10 includes a control unit 11, a memory unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The memory unit 12 includes at least one of a volatile memory such as RAM and a non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0012] The card server 20 is a server computer for the card service. The card service is a service operated by an administrator of cards that can be used in the payment service (for example, a card company that issued a credit card). The administrator of the cards may be the same as or different from the administrator of the payment service. In the first embodiment, a credit card is described as an example of a card, but the card may be a card other than a credit card. For example, the card may be a debit card, an electronic money card, a point card, or a transportation card. For example, the card server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be the same as those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0013] The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, a tablet, a personal computer, or a wearable terminal. The user terminal 30 includes a control unit 31, a memory unit 32, a communication unit 33, an operation unit 34, a display unit 35, and an imaging unit 36. The hardware configurations of the control unit 31, the memory unit 32, and the communication unit 33 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 34 is an input device such as a touch panel or a mouse. The display unit 35 is a display such as a liquid crystal or organic EL display. The imaging unit 36 ​​includes at least one camera.

[0014] The store terminal 40 is a computer at a store where a user makes a payment using a payment service. The store is not limited to a physical store that the user actually visits, but may also be an online store. For example, the store terminal 40 is a POS terminal, a self-checkout register, a handheld terminal, a smartphone, a tablet, or a personal computer. The store terminal 40 includes a control unit 41, a memory unit 42, a communication unit 43, an operation unit 44, a display unit 45, and a reading unit 46. The hardware configurations of the control unit 41, the memory unit 42, the communication unit 43, the operation unit 44, and the display unit 45 may be similar to those of the control unit 11, the memory unit 12, the communication unit 13, the operation unit 34, and the display unit 35, respectively. The reading unit 46 includes at least one code reader or reader / writer. The reading unit 46 may include at least one camera.

[0015] The programs stored in the storage units 12, 22, 32, 42 may be supplied to the payment server 10, the card server 20, the user terminal 30, or the store terminal 40 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) for inputting and outputting data to and from an external device may be included in the payment server 10, the card server 20, the user terminal 30, or the store terminal 40. For example, a program stored in an information storage medium may be supplied to the payment server 10, the card server 20, the user terminal 30, or the store terminal 40 via at least one of the reading unit and the input / output unit.

[0016] Furthermore, the payment system 1 only needs to include at least one computer. The computers included in the payment system 1 are not limited to the example in FIG. 1. For example, the payment system 1 may include only the payment server 10 and the user terminal 30. In this case, the card server 20 and the store terminal 40 exist outside the payment system 1. The payment system 1 may also include only the payment server 10. In this case, the card server 20, the user terminal 30, and the store terminal 40 exist outside the payment system 1. For example, the payment system 1 may include the payment server 10 and other computers not shown in FIG. 1.

[0017] [1-2. Overview of the First Embodiment] The first embodiment takes as an example a case where the payment service supports multiple payment methods. A payment method is a method used for payment. Payment methods include payment methods that can be set as a charge source and a payment source, as described below. For example, a payment method may be various cards, such as a credit card, electronic money, points, cryptocurrency, a wallet, an account such as a bank account, or other methods. Codes such as barcodes and two-dimensional codes are also methods for payment and therefore correspond to payment methods. Payment methods can also be used to pay for products or services provided by a store (hereinafter simply referred to as payment), so they can also be called payment methods. A payment service may support only one payment method, rather than multiple payment methods.

[0018] For example, a user uses a payment service from a payment app stored in user terminal 30. A payment app is an application provided by a payment service administrator. Once a user installs the payment app on user terminal 30 and registers as a member of the payment service, the user can use the payment service from the payment app. For example, when a user operates user terminal 30 to launch the payment app, user terminal 30 displays the payment app screen on display unit 35. Note that a user may also use the payment service from a browser or from an app other than the payment app stored in user terminal 30 (for example, a card company app or other non-payment app).

[0019] 2 and 3 are diagrams showing examples of payment app screens. For example, when the payment app is launched, as shown in the upper left of FIG. 2, the user terminal 30 displays a code screen SC1 on the display unit 35, which includes a code C10 generated based on a code ID that can temporarily identify the user. The code C10 is at least one of a barcode and a two-dimensional code. When the code C10 is read by the reader unit 46 of the store terminal 40, payment is executed based on the code ID obtained from the code C10. The basic payment flow itself may be similar to that of known payment services.

[0020] The payment may be performed by a method other than having the store terminal 40 read the code C10. For example, the payment may be performed by reading a code displayed on the store terminal 40 with the user terminal 30, by reading a code posted in a store with the user terminal 30, by completing the payment only by operating the user terminal 30, by using an IC chip in the user terminal 30, online payment (for example, account payment using the user's account, or ID payment using the user's ID), carrier payment which is payment by the carrier used by the user terminal 30, or any other type. Alternatively, for example, the user may read a code on a bill with the user terminal 30 and pay the bill.

[0021] For example, a user can select any payment method from among multiple payment methods available in the payment app as the payment source. A payment source is the payment method used by the user to pay the price. A payment source can also be said to be the payment method that provides the funds for the payment. If the payment app does not support multiple payment methods but supports only one payment method, the user does not need to select a payment source. In other words, if only one payment method is available in the payment app, the user does not need to select a payment source. A user may set priorities for multiple payment methods available in the payment app, and the payment source may be automatically switched according to the set priorities.

[0022] For example, the code screen SC1 includes a panel P11 that shows the current payment source. In the upper left example of Figure 2, panel P11 shows information about the selected credit card, "AAA Card". When the user selects panel P11, the user terminal 30 displays a payment source selection screen SC2 on the display unit 35, which includes a panel P20 that shows the payment methods that can be selected as the payment source, as shown in the upper right example of Figure 2. In the upper right example of Figure 2, the top panel P20 shows the current payment source. If the user wants to change the payment source, the user selects the second or subsequent panel P20. For example, the user can change the payment source to electronic money or another credit card.

[0023] In the first embodiment, when a credit card is selected as the payment source, the user can use installment payments, revolving credit, or bonus payments when paying for items using the payment app. Installment payments are a payment method in which the amount used is paid in multiple installments. Revolving credit is a payment method in which payments are made over several months so that the monthly payment amount remains constant. Bonus payments are a payment method in which the entire amount is paid in a predetermined month. The meanings of installment payments, revolving credit, and bonus payments may be those that are commonly known.

[0024] From here on, we will use the example of a user using installment payments through a payment app, but the process for a user using revolving credit or bonus payments through a payment app may be similar. Users may be allowed to arbitrarily choose which of installment payments, revolving credit, or bonus payments to use. Payment apps may support only installment payments, only revolving credit, only bonus payments, only installment payments and revolving credit, only installment payments and bonus payments, or only revolving credit and bonus payments.

[0025] In the upper right example of Figure 2, the payment app supports installment payments for the selected credit card. Users can specify installment payment settings from the payment source selection screen SC2. Users can either pay for the purchase using the payment app without using installment payments, or they can pay for the purchase using the payment app with installment payments. In the upper right example of Figure 2, the user has not set up installment payments. In this case, when code C10 is read, a lump-sum payment will be made using the selected credit card.

[0026] For example, when a user selects the top panel P20, which shows the credit card selected as the payment source, the user terminal 30 displays a modal M21 on the display unit 35, superimposed on the payment source selection screen SC2, which includes a panel P210 showing the number of installments. In the example at the bottom left of Figure 2, if the user selects the top panel P210, they can specify a setting to indicate that they will not use installment payments. If the user selects a second or subsequent panel P210, they can specify a setting to indicate that they will use installment payments with the number of installments shown on panel P210.

[0027] For example, if the user selects a second or subsequent panel P210, the user terminal 30 will clear the modal M21 and display the installment payment settings specified by the user on the top panel P20, as shown in the lower right of Figure 2. In the example in the lower right of Figure 2, the user has specified 3 installments as the installment payment setting. When the user performs an operation to return to the code screen SC1, the user terminal 30 will display the installment payment settings specified by the user on panel P11, as shown on the left side of Figure 3.

[0028] For example, when the store terminal 40 reads the code C10 displayed on the code screen SC1 on the left side of Figure 3, installment payments are made based on the installment payment settings specified by the user. In the example on the left side of Figure 3, the user specifies three installments. Specifically, payments from the payment service or card service to the store (e.g., bank transfer) are basically made in a lump sum, but payments from the user to the credit card administrator (e.g., automatic withdrawal) are made in three installments.

[0029] In the first embodiment, even if the user specifies installment payments, the transaction is initially processed as a lump-sum payment before being changed to installments. Details of the process for changing from a lump-sum payment to installments will be described later. When the payment server 10 executes the payment based on the code ID received from the store terminal 40, the user terminal 30 displays a completion screen SC3 on the display unit 35, as shown on the right side of Figure 3, indicating that the payment has been completed. For example, the completion screen SC3 displays a message indicating that the 3-installment payment specified by the user has been accepted. In addition to the number of installments specified by the user, the completion screen SC3 may also display other information related to installment payments, such as fees.

[0030] Furthermore, if a user uses revolving credit or bonus payments with the payment app, they may specify the setting for revolving credit or bonus payments from the payment source selection screen SC2, in the same manner as in Figures 2 and 3. When a user specifies the setting for revolving credit or bonus payments, the setting specified by the user is displayed on panel P11 of the code screen SC1. When the store terminal 40 reads code C10, the revolving credit or bonus payment is made based on the setting specified by the user.

[0031] As described above, the payment system 1 of the first embodiment displays a payment source selection screen SC2 on the user terminal 30, which accepts the user's specification of settings related to installment payments, revolving payments, or bonus payments. In the payment system 1, installment payments, revolving payments, or bonus payments are made when using the payment app based on the settings specified by the user. The details of the payment system 1 of the first embodiment will be described below. Hereafter, "installment payments, revolving payments, or bonus payments" may be abbreviated as "installment payments, etc." Wherever "installment payments, etc." is written in the following explanation, it can be read as "installment payments, revolving payments, or bonus payments."

[0032] [1-3. Functions realized in the payment system of the first embodiment] 4 is a diagram showing an example of functions realized by the payment system 1 of the first embodiment. The units realized by the payment system 1 of the first embodiment can be configured by consolidating them into one device or by distributing them into smaller devices.

[0033] [1-3-1. Functions implemented by the payment server] For example, the payment server 10 includes a data storage unit 100, a display control unit 101, and a process execution unit 102. The data storage unit 100 is realized by the storage unit 12. The display control unit 101 and the process execution unit 102 are each realized by the control unit 11.

[0034] [Data Storage Unit] The data storage unit 100 stores various types of data related to the payment service. For example, the data storage unit 100 stores the payment database DB1.

[0035] Fig. 5 is a diagram showing an example of payment database DB1. Payment database DB1 is a database that stores various information related to users of payment services. For example, payment database DB1 stores user IDs, passwords, code IDs, payment method information, payment source information, charge source information, installment payment settings, etc., and usage information. The information stored in payment database DB1 is not limited to the example of Fig. 5. Other information may also be stored in payment database DB1.

[0036] The user ID is an example of user identification information that can identify a user. A login account may exist in addition to the user ID. The login account may be freely changeable by the user. The login account is also an example of user identification information. A password is information that is confirmed when logging in. The code ID is also an example of user identification information, as it is an ID that can identify a user in the payment service. The code ID is updated each time the code C10 is displayed. The user identification information may be information other than the user ID, login account, and code ID.

[0037] Payment method information is information that can identify a payment method. For example, payment method information is information such as a credit card number, electronic money number, bank account number, or point card number. Payment source information is information that can identify a payment method selected as a payment source. Charge source information is information that can identify a payment method selected as a charge source. Charging is a process of increasing the balance of a payment method that has a balance. A charge source is a payment method used for charging. It is a payment method that serves as the source of funds for charging. In the first embodiment, it is assumed that electronic money can be charged from a payment app. Charging may also be a process of increasing the balance of a payment method other than electronic money.

[0038] The settings for installment payments, etc., are information that indicates the specific settings specified by the user. For example, the settings for installment payments, etc., indicate whether or not to use installment payments, etc. The settings for installment payments, etc., may not only indicate whether or not to use installment payments, etc., but may also indicate how to use installment payments, etc. (details of installment payments, etc.). For example, the settings for installment payments, etc., may indicate the number of installments (number of payments) in installment payments, the payment amount or number of installments in revolving credit payments, or the payment month in bonus payments. In the first embodiment, the settings specified by the user on the payment source selection screen SC2 are stored in the settlement database DB1.

[0039] Usage information refers to information about the usage of the payment app. It can also be said that usage information refers to information about payments made through the payment app. In the first embodiment, payments are made not only when paying for services but also when charging, so usage information can also be said to refer to payment or charge information. Usage information may include not only payments made through the payment app but also other information such as the user's operation history with the payment app. For example, if usage information indicates past usage, it can also be said to be the payment app usage history. Usage information may also indicate the details of payments that are about to be made. Usage information may include information such as an ID that can identify individual payments.

[0040] For example, if payment is equivalent to using a payment app, the usage information will show the payment method selected as the source of payment, the amount used, the date and time of use, and the store where the payment was made. The usage information may also include information about the goods or services for which the payment was made. If charging is equivalent to using a payment app, the usage information will show the payment method selected as the source of the charge, the amount charged, and the date and time of the charge. If installment payments or similar settings are specified, the usage information may show the installment payment or similar settings specified at the time of use. For example, the usage information may show the number of installments in an installment payment, the payment amount or number of installments in a revolving credit payment, or the bonus month in a bonus payment. The usage information may include other arbitrary information.

[0041] For example, when a user uses a payment app, the payment server 10 generates usage information indicating the details of the payment app usage and stores the usage information in the payment database DB1 in association with the user's user ID. When a user makes a payment using the payment app, the payment server 10 generates usage information indicating the selected payment method, whether or not installment payments are being made, the amount used, the date and time of use, and the store used, and stores the usage information in association with the user's user ID. When a user makes a charge using the payment app, the payment server 10 generates usage information indicating the selected payment method, the amount charged, whether or not installment payments are being made, and the date and time of charge, and stores the usage information in the payment database DB1 in association with the user's user ID.

[0042] The data stored in the data storage unit 100 is not limited to the examples above. The data storage unit 100 only needs to store data related to payment services. For example, the data storage unit 100 may store data from various screens displayed on the payment application. The data storage unit 100 may also store various types of data as described below. For example, the data storage unit 100 may store a store database containing various information about stores where users can use the payment service.

[0043] [Display control section] The display control unit 101 causes the payment service screen to be displayed on the user terminal 30. For example, the display control unit 101 causes the payment application screen to be displayed on the user terminal 30. The display control unit 101 may also cause the screen of another application or browser other than the payment application to be displayed on the user terminal 30. For example, the display control unit 101 causes the screen to be displayed to be displayed on the user terminal 30 by transmitting the display data of the screen to the user terminal 30. The display data is data that shows all or part of the payment application screen. The display data may be in any format, and may be, for example, markup language data such as HTML, image data, or text data. The data storage unit 100 may store the display data itself that is transmitted to the user terminal 30, or it may store the data necessary for generating the display data.

[0044] For example, the display control unit 101 causes the user terminal 30 to display a payment source selection screen SC2 that accepts the specification of settings related to installment payments and the like for payment methods that can be used on the user terminal 30. In the first embodiment, since the user can use installment payments and the like to pay for a purchase, the display control unit 101 causes the user terminal 30 to display a payment source selection screen SC2 that accepts the specification of settings for paying for a purchase to a store that accepts a payment method. The payment source selection screen SC2 is an example of a settings screen. Therefore, any description of the payment source selection screen SC2 can be read as "settings screen." Furthermore, the payment source selection screen SC2 may be a screen that allows the user to switch payment sources (payment methods) and set their priorities. For example, the settings screen may be another screen such as a home screen, a payment screen, or a payment method management screen.

[0045] The setting screen functions as a user interface that accepts settings for installment payments and the like. The setting screen may include any user interface component. For example, the setting screen may include panels, buttons, check boxes, slide bars, other input forms, icons, links, text, or other images. In the first embodiment, the setting screen may be any screen on the user terminal 30. The setting screen is not limited to the payment source selection screen SC2. For example, the setting screen may be a home screen, a code screen SC1, a payment in progress screen (a payment confirmation screen, e.g., the confirmation screen SC5 described below), a completion screen SC3, a screen dedicated to setting installment payments and the like, a screen showing the payment app's usage history, or another screen. The setting screen may also be a screen other than a payment app. For example, the screen displayed on the browser of the user terminal 30 may correspond to the setting screen.

[0046] In the example of FIG. 2, when a user selects panel P11 on code screen SC1, the user terminal 30 sends a display request for the payment source selection screen SC2 to the payment server 10. The display request is data in a predetermined format (for example, a request defined by a communication protocol such as HTTP, or data in a format defined by an API) indicating a request to display the payment source selection screen SC2. When the payment server 10 receives the display request for the payment source selection screen SC2 from the user terminal 30, the display control unit 101 acquires, from the payment database DB1, the payment method information and payment source information of the user who requested the display of the payment source selection screen SC2, and generates display data for the payment source selection screen SC2. The display control unit 101 causes the payment source selection screen SC2 to be displayed on the user terminal 30 by sending the display data for the payment source selection screen SC2 to the user terminal 30.

[0047] The display request for the payment source selection screen SC2 may include a user ID or other information that can identify the user ID (for example, a session ID that can identify a session between the payment server 10 and the user terminal 30, or authentication information called a token stored in the user terminal 30). The display control unit 101 can identify which user's payment method information and payment source information to obtain based on the user ID or other information included in the display request. Data indicating the basic layout of the payment source selection screen SC2 is stored in the data storage unit 100. The display control unit 101 can generate display data for the payment source selection screen SC2 by inserting text, images, etc. that correspond to the payment method information and payment source information into the layout indicated by the data.

[0048] Furthermore, the display control unit 101 may include a script for displaying the modal M21 in the display data of the payment source selection screen SC2. The script contains code that indicates that the modal M21 is to be displayed when the panel P20 of a payment method that allows installment payments or the like is selected. The user terminal 30 may execute the script to display the modal M21 superimposed on the payment source selection screen SC2 without communicating with the payment server 10. Instead of including a script in the display data of the payment source selection screen SC2, the display control unit 101 may communicate with the user terminal 30 to display the modal M21 superimposed on the payment source selection screen SC2 when the user selects the panel P20. The display control unit 101 may execute program code included in the payment app instead of a script to display the modal M21 superimposed on the payment source selection screen SC2.

[0049] [Processing Execution Unit] The process execution unit 102 executes processes related to installment payments, etc., based on the settings for installment payments, etc., specified on a setting screen, such as the payment source selection screen SC2. In the first embodiment, since the user can use installment payments, etc., to pay the price, the process execution unit 102 executes processes for installment payments, etc., based on the settings for installment payments, etc., specified on a setting screen, such as the payment source selection screen SC2.

[0050] The installment payment process is a process directly or indirectly related to the installment payment. For example, the installment payment process may be a process for requesting the card server 20 to make an installment payment, a process for determining the amount of each installment payment, a process for determining a fee for the installment payment, a process for generating usage information indicating that the payment is eligible for installment payment, or other processes. The installment payment process may simply involve storing data (data related to the installment payment, etc.) in the payment server 10, or transmitting data (data related to the installment payment, etc.) to the card server 20. The first embodiment takes as an example a case in which payment of the price is initially processed as a lump-sum payment and then changed by the card server 20 from the lump-sum payment to the installment payment. Therefore, the process execution unit 102 executes, as the installment payment process, a process for generating usage information indicating that the payment is eligible for installment payment. The process execution unit 102 stores the usage information in the payment database DB1 and, at any timing thereafter, transmits the usage information to the card server 20 to request a change from the lump-sum payment to the installment payment. All or part of this series of processes may correspond to the installment payment process. The usage information includes information regarding payment or charging, and information regarding settings for specified installment payments, etc. These pieces of information may be sent to the card server 20 simultaneously, or may be sent to the card server 20 at different times. The same applies to revolving payments and bonus payments.

[0051] The revolving payment process is a process directly or indirectly related to the revolving payment process. For example, the revolving payment process may be a process for requesting the card server 20 to make a revolving payment, a process for determining the amount or number of payments for the revolving payment process, a process for determining a fee for the revolving payment process, a process for generating usage information indicating that the payment is eligible for the revolving payment process, or other processes. In the first embodiment, a case is taken as an example in which the payment of the price is initially processed as a lump-sum payment and then changed by the card server 20 from the lump-sum payment to the revolving payment process. Therefore, the process execution unit 102 executes, as the revolving payment process, a process for generating usage information indicating that the payment is eligible for the revolving payment process. The process execution unit 102 stores the usage information in the payment database DB1 and, at any timing thereafter, transmits the usage information to the card server 20 and requests a change from the lump-sum payment to the revolving payment process. All or part of this series of processes may correspond to the revolving payment process.

[0052] The bonus payment process is a process directly or indirectly related to the bonus payment. For example, the bonus payment process may be a process for requesting a bonus payment from the card server 20, a process for determining the payment amount for the bonus payment, a process for determining the payment month for the bonus payment, a process for generating usage information indicating that the payment is eligible for the bonus payment, or other processes. In the first embodiment, a case is taken as an example in which the payment is initially processed as a lump-sum payment and then changed by the card server 20 from the lump-sum payment to the bonus payment. Therefore, the process execution unit 102 executes, as the bonus payment process, a process for generating usage information indicating that the payment is eligible for the bonus payment. The process execution unit 102 stores the usage information in the payment database DB1 and, at any time thereafter, transmits the usage information to the card server 20 and requests a change from the lump-sum payment to the bonus payment. All or part of this series of processes may correspond to the bonus payment process.

[0053] For example, when the store terminal 40 reads the code C10 on the code screen SC1 with the reading unit 46, it acquires a code ID from the code C10. The store terminal 40 sends a payment request including the code ID to the payment server 10. The payment request is data in a predetermined format indicating that a payment has been requested (for example, a request defined by a communication protocol such as HTTP, or data in a format defined by an API). The payment server 10 receives the payment request from the store terminal 40. The processing execution unit 102 acquires, from the payment database DB1, payment source information and settings such as installment payment associated with the code ID indicated in the payment request. Note that the payment source information and settings such as installment payment may be coded in the code C10 and included in the payment request. As is the case with other embodiments and modifications, the payment server 10 may receive a payment request from the store terminal 40 or from the user terminal 30.

[0054] For example, the process execution unit 102 determines whether to execute a process such as installment payment based on the settings for installment payment, etc. If the settings for installment payment, etc. indicate that installment payment, etc. is not to be used, the process execution unit 102 does not determine to execute a process such as installment payment, etc., and if the settings for installment payment, etc. indicate that installment payment, etc. is to be used, the process execution unit 102 determines to execute a process such as installment payment, etc. In the first embodiment, the process execution unit 102 executes a process such as installment payment, etc., by generating usage information indicating that installment payment, etc. is applicable and storing the usage information in the payment database DB1. For example, the usage information may indicate not only information indicating that installment payment, etc. is applicable (e.g., a flag, etc.) but also detailed settings such as the number of installments.

[0055] For example, if there is no setting for installment payment or the like, the processing execution unit 102 executes normal payment processing (processing of payment data) that is not installment payment or the like. This processing may follow the same flow as known payment services. For example, as normal payment processing, payment data is linked from the payment server 10 to the card server 20, and the card server 20 receives the payment data, records it a few days later (reflects it in the user's statement), and performs processing for payment. Payment from the user to the card company is processed as a lump sum payment.

[0056] For example, if installment payment or the like is set, the process execution unit 102 executes normal payment processing (processing of payment data) and processing for installment payment or the like (processing of data for installment payment or the like). Normal payment processing is as described in the previous paragraph. For processing for installment payment or the like, payment data and data for installment payment or the like are linked from the payment server 10 to the card server 20. The card server 20 receives the payment data and performs various processes such as determining whether installment payment or the like is possible, recording the payment, and making a payment. If it is determined that installment payment or the like is possible, the payment data is changed from a lump-sum payment to an installment payment and recorded. If it is determined that installment payment or the like is not possible, the lump-sum payment is recorded as is. These determinations are made by the card server 20, and the determination results are communicated to the payment server 10. The payment server 10 stores the determination results in a database such as the payment database DB1, and notifies the user.

[0057] Note that the payment data and the data for installment payments, etc. may be linked separately, or may be linked together and simultaneously. The timing of determining whether installment payments, etc. are possible and recording may be at any timing. These may be done simultaneously, or recording may be done after determining whether installment payments, etc. are possible. Whether installment payments, etc. are possible may be determined after recording. An example will be given of a case where installment payments, etc. are recorded as installment payments, etc. after a determination is made that installment payments, etc. are possible, but if a lump-sum payment is recorded and it is determined that installment payments, etc. are possible, it may be changed to installment payments, etc.

[0058] For example, the processing execution unit 102 acquires from the payment database DB1 usage information on card payments made during a certain period (e.g., a certain day). The processing execution unit 102 sends the acquired usage information to the card server 20 and requests that the information be recorded in the card database DB2. Recording is a process of adding information to a credit card statement. Recording itself may be a process adopted in known card services. The processing execution unit 102 may transmit the usage information to the card server 20 and request that the information be recorded in the card database DB2 immediately after executing a lump-sum payment process. The card server 20 performs recording in the card database DB2 through processing by the processing execution unit 201, which will be described later. At that time, the payment of the usage information, which was initially processed as a lump-sum payment, is changed to a payment in installments or the like and recorded. As a result, the payment is processed as a payment in installments or the like.

[0059] The process of changing a lump sum payment that has been executed for the time being to payment in installments or the like may be executed by the settlement server 10, not by the card server 20. In this case, the process execution unit 102 may execute the process of payment in installments or the like by changing the lump sum payment that has been executed for the time being indicated by the usage information to payment in installments or the like. The process execution unit 102 transmits the usage information that has been changed to payment in installments or the like to the card server 20. When the card server 20 receives the usage information that has been changed to payment in installments or the like, the process execution unit 201, which will be described later, executes entries in the card database DB2 based on the usage information.

[0060] [1-3-2. Functions implemented by the card server] For example, the card server 20 includes a data storage unit 200 and a process execution unit 201. The data storage unit 200 is realized by the storage unit 22. The process execution unit 201 is realized by the control unit 21.

[0061] [Data Storage Unit] The data storage unit 200 stores various types of data related to the card service. For example, the data storage unit 200 stores the card database DB2.

[0062] Fig. 6 is a diagram showing an example of card database DB2. Card database DB2 is a database that stores various information related to users of card services. For example, card database DB2 stores user IDs, passwords, card information, and usage information. The information stored in card database DB2 is not limited to the example of Fig. 6. Other information may also be stored in card database DB2. For example, card database DB2 may store information indicating the contents of entries (i.e., information indicating credit card details) in addition to usage information.

[0063] In the first embodiment, an example is given in which the user ID is the same for the payment service and the card service, but the user ID for the payment service and the user ID for the card service may be different. When the user ID for the payment service and the user ID for the card service are different, a relational database indicating the relationship between these user IDs is stored in the data storage unit 200. It is sufficient if the relational database can identify which user has which user ID. The relational database may be stored in the data storage unit 100 of the payment server 10 instead of the data storage unit 200. The relational database may be stored in a computer other than the payment server 10 or the card server 20, or in an external information storage medium.

[0064] Card information is information about a user's credit card. For example, card information indicates the credit card number, expiration date, or cardholder name. Usage information is information about card usage in card services. For example, usage information may be the amount used, the date and time of use, the store used, or other information. When a card is used, card server 20 generates usage information and stores it in card database DB2. Card server 20 generates usage information and stores it in card database DB2 not only when a payment app is used, but also when a flat card is used.

[0065] [Processing Execution Unit] The processing execution unit 201 executes processing such as installment payments made by the user using the payment app. In the first embodiment, the payment is initially made as a lump sum payment, so the processing execution unit 201 executes card payment for the lump sum payment and stores the usage information in the card database DB2. The processing execution unit 201 subsequently executes processing such as installment payments by changing the payment that was initially made as a lump sum payment to installment payments or the like and recording the change. For example, the processing execution unit 201 may record the change by changing the lump sum payment indicated by the usage information stored in the card database DB2 to installment payments or the like, or may generate information for recording separately from the usage information and store the information in the card database DB2.

[0066] For example, when the card server 20 acquires from the settlement server 10 usage information on card payments made during a certain period (for example, a certain day) and accepts a request for posting, the process execution unit 201 changes the lump-sum payment indicated by the usage information to installment payment or the like. The process execution unit 201 performs posting for installment payment or the like by storing the usage information changed to installment payment or the like in the card database DB2, or by generating information for posting and storing it in the card database DB2. Note that when a change from lump-sum payment to installment payment or the like is made on the settlement server 10 side, the process execution unit 201 may perform posting by storing the usage information received from the settlement server 10 as is in the card database DB2.

[0067] [1-3-3. Functions implemented on user devices] For example, the user terminal 30 includes a data storage unit 300, an operation reception unit 301, and a display control unit 302. The data storage unit 300 is realized by the storage unit 32. The operation reception unit 301 and the display control unit 302 are realized by the control unit 31.

[0068] [Data Storage Unit] The data storage unit 300 stores data necessary for a user to use a payment service. For example, the data storage unit 300 stores a payment app. When a user uses a payment service from a browser rather than a payment app, the data storage unit 300 stores the browser.

[0069] [Operation reception section] The operation reception unit 301 receives various user operations. For example, the operation reception unit 301 receives operations on the payment application. The operation reception unit 301 transmits data indicating the user's operations to the payment server 10.

[0070] [Display control section] The display control unit 302 displays various screens on the display unit 35. For example, the display control unit 302 displays a code screen SC1, a payment source selection screen SC2, and a completion screen SC3 on the display unit 35. The display control unit 302 communicates with the payment server 10, receives display data for these screens, and displays these screens on the display unit 35 based on the display data.

[0071] [1-3-4. Functions realized by store terminals] For example, the store terminal 40 includes a data storage unit 400 and a payment request transmission unit 401. The data storage unit 400 is implemented by a storage unit 42. The payment request transmission unit 401 is implemented by a control unit 41.

[0072] [Data Storage Unit] The data storage unit 400 stores data necessary for store-side processing in the payment service. For example, the data storage unit 400 stores a database that stores various information such as the prices of products or services handled by the store. The data storage unit 400 also stores information (e.g., price) about the product or service to be paid for. The data storage unit 400 may store a store ID that can identify the store. The store terminal 40 may obtain product and price information based on the results of reading the product's barcode, etc., and calculate the payment amount and record it in the data storage unit 400.

[0073] [Payment request sending section] The payment request transmission unit 401 sends a payment request to the payment server 10. For example, when the store terminal 40 reads code C10 with the reading unit 46, the payment request transmission unit 401 obtains a code ID from code C10. The payment request transmission unit 401 sends a payment request to the payment server 10 that includes information necessary for payment, such as the code ID, payment amount, and store ID. The payment request can be any request used in a well-known payment service. The payment request transmission unit 401 obtains the payment execution result from the payment server 10 and completes the payment. These processes can also be any processes adopted in a well-known payment service. In the first embodiment, even if settings such as installment payments are specified, the payment is processed as a lump sum payment for the time being, so the format of the payment request may be the same whether settings such as installment payments are specified or not.

[0074] [1-4. Processing Executed in the Payment System of the First Embodiment] Figure 7 shows an example of the processing performed in the payment system 1 of the first embodiment. The processing in Figure 7 is performed by the control units 11, 21, 31, and 41 executing programs stored in the storage units 12, 22, 32, and 42, respectively. In Figure 7, the processing for executing installment payments and the like, among the processing performed in the payment system 1, will be explained.

[0075] As shown in Figure 7, the user terminal 30 launches the payment application and performs a login process with the payment server 10 to allow the user to log in to the payment service (S100). The user terminal 30 performs a process with the payment server 10 to display the code screen SC1 on the display unit 35 (S101). In S101, the payment server 10 issues a new code ID based on a predetermined issuance rule and stores it in the payment database DB1. The payment server 10 sends the code ID to the user terminal 30. Upon receiving the code ID, the user terminal 30 displays the code screen SC1, including code C10, on the display unit 35.

[0076] When the user selects panel P11, the user terminal 30 executes processing with the payment server 10 to display the payment source selection screen SC2 (S102). In S102, when the payment server 10 receives a display request for the payment source selection screen SC2 from the user terminal 30, it generates display data for the payment source selection screen SC2 based on the payment method information and payment source information stored in the payment database DB1 and sends it to the user terminal 30. When the user terminal 30 receives the display data for the payment source selection screen SC2 from the payment server 10, it displays the payment source selection screen SC2 on the display unit 35.

[0077] When the user selects panel P20 indicating a card that allows installment payments, etc., the user terminal 30 executes processing for displaying modal M21, which accepts designation of settings for installment payments, etc., on the display unit 35 (S103). In S103, if the display data of the payment source selection screen SC2 includes a script for displaying modal M21, the user terminal 30 displays modal M21 based on the script. If the script is not included, the user terminal 30 may acquire data for modal M21 from the payment server 10 and display modal M21. The processing for displaying modal M21 may be specified in the payment app.

[0078] When the user specifies settings such as installment payment in modal M21, the user terminal 30 executes processing with the payment server 10 to reflect the settings such as installment payment specified by the user (S104). In S104, the user terminal 30 transmits data indicating the settings specified by the user to the payment server 10. When the payment server 10 receives the data from the user terminal 30, it stores the settings indicated by the data in the payment database DB1 in association with the user ID of the user. Thereafter, the user terminal 30 executes processing with the payment server 10 to display the code screen SC1 again on the display unit 35 (S105). The processing of S105 is the same as the processing of S101.

[0079] When the code C10 on the code screen SC1 is read by the reading unit 46, the store terminal 40 transmits a payment request based on the code ID acquired from the code C10 to the payment server 10 (S106). When the payment server 10 receives the payment request from the store terminal 40 (S107), it executes a payment process for card payment with the card server 20 (S108). In S108, the payment is processed as a lump sum payment for the time being.

[0080] The payment server 10 acquires the settings for installment payments, etc. stored in the payment database DB1 (S109). The payment server 10 executes the process for installment payments, etc. based on the settings for installment payments, etc. specified by the user (S110). In S110, if the settings for installment payments, etc. indicate that installment payments, etc. will be used, the payment server 10 generates usage information indicating that installment payments, etc. will be applied, and stores the usage information in the payment database DB1 in association with the code ID included in the payment request. The usage information may indicate details of the settings, such as the number of installments.

[0081] The payment server 10 executes processing with the user terminal 30 to display the completion screen SC3 on the display unit 35 (S111), and this processing ends. In S111, the payment server 10 generates display data for the completion screen SC3 based on the processing results of S109 and S110, and transmits it to the user terminal 30. The user terminal 30 receives the display data for the completion screen SC3 from the payment server 10, and displays the completion screen SC3 on the display unit 35. Thereafter, the payment server 10 executes processing with the card server 20 to change the lump-sum payment to installment payment, etc.

[0082] [1-5. Summary of the first embodiment] The payment system 1 of the first embodiment displays a payment source selection screen SC2 on the user terminal 30, which accepts the specification of settings for installment payments, etc. The payment system 1 executes processing for installment payments, etc. based on the settings for installment payments, etc. This allows the user to use installment payments, etc. from the payment app, thereby improving user convenience. For example, a user can use installment payments, etc. by simply preparing a payment app without having to prepare a plate-shaped card, so the user can use various payment methods with the payment app. The user can also complete the settings for installment payments, etc. on the user terminal 30, making it easy to use installment payments, etc.

[0083] The payment system 1 also displays on the user terminal 30 a payment source selection screen SC2 that accepts the specification of settings for installment payments, etc., for payment of the price of goods or services provided by a store. The payment system 1 executes the process of installment payments, etc., for payment of the price based on the settings for installment payments, etc. This allows the user to use installment payments, etc., from the payment app when paying the price, so the payment system 1 can improve the user's convenience when paying the price. For example, the user can use installment payments, etc., by presenting the code screen SC1 of the payment app without having to present a plate-shaped card at the store, so the user can use various payment methods with the payment app.

[0084] [2. Second Embodiment] A second embodiment, which is an example of an embodiment of the payment system 1, payment method, and program according to the present disclosure, will be described. In the second embodiment, a description of the same configuration as in the first embodiment will be omitted. For example, the hardware configuration of the payment system 1 may be the same as in the first embodiment.

[0085] [2-1. Overview of the Second Embodiment] In the second embodiment, a case where terms of use are set for installment payments and the like that a user can use from a payment app will be taken as an example. The terms of use are criteria for determining whether installment payments and the like are permitted to be used from the payment app. The terms of use may be any conditions depending on the content of use from the payment app. Multiple terms of use may be set for installment payments and the like. For example, the terms of use may be whether payment is made for a product or service provided by a store that accepts installment payments and the like, whether the payment is within a credit limit for installment payments and the like, whether the amount used is equal to or greater than a predetermined amount, or other conditions. The terms of use for installment payments, revolving payments, and bonus payments may be the same or different from each other. Stores that accept installment payments and the like may be determined based on attribute information of the store (e.g., the industry or category to which the store belongs) or on credit information of the store (e.g., whether there has been any fraud in the past). The terms of use may be set by the user.

[0086] 8 is a diagram showing an example of processing executed in the payment system 1 of the second embodiment. In the second embodiment, as in the first embodiment, an example is given of a case where payment of the price is first processed as a lump sum payment, and then the lump sum payment is changed to payment in installments or the like and processed. Furthermore, an example is given of a case where a change from lump sum payment to payment in installments or the like is executed by the card server 20. The change from lump sum payment to payment in installments or the like may be executed by the payment server 10, or may be executed by a computer other than the payment server 10 and the card server 20.

[0087] As shown in Figure 8, when the code C10 on the code screen SC1 is read by the reader 46 of the store terminal 40, the payment server 10 communicates with the card server 20 and processes the payment as a lump-sum payment for the time being. This is as explained in the first embodiment. Even if the payment app specifies settings such as installment payments, the store terminal 40 executes the same processing as for a normal lump-sum payment. Therefore, even if installment payments become possible in the payment app, no modifications are required on the store terminal 40, reducing the amount of work required for modifications.

[0088] For example, at a predetermined timing (e.g., a predetermined time on a certain day), the payment server 10 transmits usage information processed as a lump-sum payment to the card server 20 and requests the card server 20 to process the bookkeeping. As described in the first embodiment, the usage information for a payment that is subject to installment payments, etc. indicates that the payment is subject to installment payments, etc. When the card server 20 receives the usage information from the payment server 10, the card server 20 identifies the payment that is subject to installment payments, etc. based on the usage information. The card server 20 determines whether the usage conditions are met based on the usage information for the payment that is subject to installment payments, etc.

[0089] In the example of FIG. 8, card server 20 determines (usage condition 1) whether the store where the payment is made does not support installment payments, etc., (usage condition 2) whether the use is within the limit of the installment payment limit (for example, the installment limit), and (usage condition 3) whether the amount of the installment payment is equal to or greater than a predetermined amount (for example, 50 yen). If card server 20 determines that these usage conditions are met, it changes the lump-sum payment indicated by the usage information to installment payments, etc. and records the payment. If card server 20 determines that these usage conditions are not met, it does not change the lump-sum payment indicated by the usage information to installment payments, etc., and records the payment as a lump-sum payment.

[0090] As described above, the payment system 1 of the second embodiment determines whether the terms of use, such as installment payments, are met. The payment system 1 executes the installment payment process based on the results of the determination. This allows the payment system 1 to prevent installment payments, etc., from being made without the user's or administrator's intention, thereby improving user convenience. The second embodiment will be described in detail below.

[0091] [2-2. Functions realized in the payment system of the second embodiment] Figure 9 shows an example of the functions implemented in the payment system 1 of the second embodiment. Although some of the functions described in the first embodiment are not shown in Figure 9, the payment system 1 of the second embodiment may include the functions described in the first embodiment. The components implemented in the payment system 1 of the second embodiment can be configured by combining them into a single device or by further distributing them among multiple devices.

[0092] Furthermore, the payment system 1 of the second embodiment does not have to include the functions described in the first embodiment (for example, functions for displaying setting screens such as the payment source selection screen SC2). For example, the payment system 1 of the second embodiment does not have to include functions for displaying setting screens, such as the payment source selection screen SC2. If the payment system 1 of the second embodiment does not include some of the functions described in the first embodiment, the payment system 1 of the second embodiment does not have to allow the user to specify settings such as installment payments from the setting screen. For example, the payment database DB1 does not have to store settings such as installment payments for each user. These points also apply to the third and fourth embodiments described later.

[0093] For example, if the payment system 1 of the second embodiment does not include the functions described in the first embodiment, the user may specify settings such as installment payments from a location other than the payment app (e.g., a browser). In this case, the payment app will not display setting screens such as the payment source selection screen SC2, but the user may specify settings such as installment payments from a screen displayed elsewhere. The payment database DB1 may store the settings such as installment payments specified from a screen displayed elsewhere. These points also apply to the third and fourth embodiments described later.

[0094] For example, if the payment system 1 of the second embodiment does not include the functions described in the first embodiment, the user may declare that they will use installment payments or the like at the store. The user may input that they will use installment payments or the like in the payment app by operating the store terminal 40. The store terminal 40 may send a payment request indicating that the user will use installment payments or the like to the payment server 10. The payment request may also include information equivalent to settings such as the number of installments. The payment server 10 may specify that the user will use installment payments or the like from the payment request. These points also apply to the third and fourth embodiments described below.

[0095] As described above, an embodiment in which the payment system 1 does not include the functions described in the first embodiment but includes the functions described in the second embodiment is within the scope of the present disclosure. Of course, an embodiment in which the payment system 1 includes the functions described in the first embodiment and the functions described in the second embodiment is also within the scope of the present disclosure. These points are matters that a person skilled in the art would naturally understand from the description of the present disclosure.

[0096] [2-2-1. Functions implemented by the payment server] For example, the payment server 10 includes a data storage unit 100 and a processing execution unit 102.

[0097] [Data Storage Unit] The data storage unit 100 may be the same as in the first embodiment.

[0098] [Processing Execution Unit] The processing execution unit 102 may be the same as in the first embodiment. For example, when payment is instructed, the processing execution unit 102 may process the payment as a lump sum payment, in the same way as when installment payments are not specified, and then execute processing to change it to installment payments. This point is the same as in the first embodiment. When installment payments are not specified, it can also be said that the user has selected a lump sum payment. In other words, when installment payments are not specified, it is the same as in conventional payment services where installment payments cannot be selected. For example, when the processing execution unit 102 receives a payment request from the store terminal 40, it may execute a lump sum payment without performing any special processing for installment payments.

[0099] For example, if a credit card is selected as the payment source, the processing unit 102 performs a lump-sum card payment with the card server 20. The method of performing the card payment may be the same as known methods. If a payment method other than a card (e.g., electronic money, points, or bank account) is selected as the payment source, the processing unit 102 performs a lump-sum payment with the server computer that manages the other payment method. The method of performing the payment for the other payment method may also be the same as known methods.

[0100] The processing execution unit 102 may have all or part of the functions of the processing execution unit 102 described in the first embodiment. For example, the processing execution unit 102 may determine whether or not to execute installment payment processing based on the settings for installment payments, etc., in the same manner as the processing execution unit 102 of the first embodiment. If the settings for installment payments, etc., are not specified as in the first embodiment, the settings for installment payments, etc., may be included in the settlement request. The processing execution unit 102 may determine whether or not to execute installment payment processing based on these settings for installment payments, etc.

[0101] For example, after executing a lump-sum payment, the processing execution unit 102 may generate usage information indicating that the payment is eligible for installment payments, etc., in the same manner as the processing execution unit 102 of the first embodiment, and store the usage information in the settlement database DB1. For example, the usage information may include not only information indicating that the payment is eligible for installment payments, etc. (e.g., a flag), but also detailed settings such as the number of installments. This information may allow identification that the payment is eligible for installment payments, etc.

[0102] [2-2-2. Functions realized by the card server] For example, the card server 20 includes a data storage unit 200, a processing execution unit 201, a usage information acquisition unit 202, and a usage condition determination unit 203. The usage information acquisition unit 202 and the usage condition determination unit 203 are each implemented by a control unit 21. At least one of the usage information acquisition unit 202 and the usage condition determination unit 203 may be implemented by the payment server 10.

[0103] [Data Storage Unit] The data storage unit 200 may be the same as in the first embodiment. In the second embodiment, the data storage unit 200 stores usage condition data indicating usage conditions. The usage condition data may indicate only one usage condition or multiple usage conditions. In the example in Figure 8, three usage conditions are defined, so the usage condition data indicates three usage conditions. The usage condition data may be in any format. For example, the usage condition data may be in table format, formula format, part of a program, machine learning model, or other format. The usage condition data may be defined by the administrator of the payment service or by the administrator of the card service (card issuer).

[0104] [Usage information acquisition department] The usage information acquisition unit 202 acquires usage information regarding the use of payment methods available on the user terminal 30. In the second embodiment, an example is given in which the usage information indicates the usage details of past uses, but as in a modified example described below, the usage information may also indicate the usage details of upcoming uses (future uses). The usage information acquisition unit 202 may acquire usage information indicating the use of a payment app that is the subject of usage condition determination. The usage information acquisition unit 202 may acquire any number of pieces of usage information. For example, the usage information acquisition unit 202 may acquire usage information indicating multiple uses performed within a certain period of time. The usage information acquisition unit 202 may acquire usage information for each of multiple users.

[0105] In the second embodiment, as in the first embodiment, it is assumed that the usage information is stored in the payment database DB1. The usage information acquisition unit 202 acquires the usage information from the payment server 10 that manages the payment database DB1. The usage information may be stored in a database other than the payment database DB1. The usage information acquisition unit 202 may acquire the usage information from another database. The usage information may be stored in a computer other than the payment server 10 or in an external information storage medium. The usage information acquisition unit 202 may acquire the usage information from another computer or an external information storage medium.

[0106] In the second embodiment, as in the first embodiment, an example is taken in which payment of a price corresponds to the use of a payment app. The usage information acquisition unit 202 acquires usage information for the payment of a price for a product or service provided by a store that accepts a payment method. For example, the usage information indicates information on the payment source used to pay the price (for example, information that can identify the payment method, such as part of a credit card number), the amount used, the date and time of use, and the store used. The usage information may indicate whether or not payment in installments is applicable, or may indicate details of the payment in installments (for example, the number of installments, etc.).

[0107] In the second embodiment, we take the example of a case where the timing for recording usage information occurs periodically. For example, a predetermined time on a given day may correspond to the timing for recording usage information. In this case, the usage information acquisition unit 202 determines whether the timing for recording usage information has arrived by determining whether the predetermined time on a given day has arrived. The time interval between timings for recording usage information is not limited to one day, but may be any time interval. For example, the timing for recording usage information may occur every few hours, every few days, every week, or at other time intervals. When the usage information acquisition unit 202 determines that the timing for recording usage information has arrived, it acquires usage information that includes the date and time of use within the period from the most recent determination timing to the present time.

[0108] The usage information acquisition unit 202 may determine whether the timing for recording usage information has arrived by determining whether a predetermined time has elapsed since the date and time of use. In this case, the usage information acquisition unit 202 determines whether the timing for recording usage information has arrived for each individual use. The usage information acquisition unit 202 acquires usage information for which it has been determined that the timing for recording usage information has arrived. If no specific timing for recording is defined, the usage information acquisition unit 202 may acquire usage information from the settlement server 10 each time usage information is generated by the settlement server 10.

[0109] [Usage conditions judgment section] The usage conditions determination unit 203 determines whether the usage conditions for using installment payments or other payment methods are met, based on the usage information acquired by the usage information acquisition unit 202. For example, the usage conditions determination unit 203 acquires the usage conditions data stored in the data storage unit 200 and determines whether the usage information satisfies the usage conditions indicated by the usage conditions data. If the usage conditions data indicates multiple usage conditions, the usage conditions determination unit 203 determines whether each of the multiple usage conditions is met.

[0110] In the example shown in Figure 8, the usage condition determination unit 203 determines whether usage condition 1 is met by determining, based on the usage information acquired by the usage information acquisition unit 202, whether the store to which the payment was made is a store that does not support installment payments, etc. In other words, the usage condition determination unit 203 determines whether usage condition 1 is met by determining, based on the usage information acquired by the usage information acquisition unit 202, whether the store to which the payment was made is a store that supports installment payments, etc. It is possible that there are stores that support only a part of installment payments, etc., such as supporting installment payments but not revolving credit.

[0111] For example, the data storage unit 200 stores a correspondence database that indicates at least one of the corresponding stores and non-corresponding stores. The usage condition determination unit 203 determines whether or not usage condition 1 is met based on the correspondence database. If a corresponding store is defined in the correspondence database, the usage condition determination unit 203 determines that the store indicated by the usage information is a corresponding store if it is defined in the correspondence database, and determines that the store is a non-corresponding store if it is not defined in the correspondence database. If a non-corresponding store is defined in the correspondence database, the usage condition determination unit 203 determines that the store indicated by the usage information is a non-corresponding store if it is defined in the correspondence database, and determines that the store is a corresponding store if it is not defined in the correspondence database.

[0112] For example, the usage condition determination unit 203 determines whether usage condition 3 is met by determining whether the usage is within the user's usage limit based on the usage information acquired by the usage information acquisition unit 202. In other words, the usage condition determination unit 203 determines whether usage condition 3 is met by determining whether the usage exceeds the user's usage limit. The usage limit is the range for which installment payments, etc., are possible. The usage limit is sometimes called the installment payment limit. The usage limit may be a limit adopted in a publicly known installment payment, etc.

[0113] In the second embodiment, the credit limit information indicating the user's credit limit is stored in the card database DB2. The credit limit information may indicate the total amount of the credit limit allocated to the user, or it may indicate the remaining amount of the credit limit. The usage condition determination unit 203 identifies the credit limit based on the credit limit information of the user from which the usage information has been obtained, and determines whether the amount used indicated by the usage information is within the range of the credit limit. If the credit limit information is stored in a database other than the card database DB2, the usage condition determination unit 203 may obtain the credit limit information from the other database.

[0114] For example, the usage condition determination unit 203 determines whether usage condition 3 is met by determining whether the amount used for installment payments, etc., is equal to or greater than a predetermined amount, based on the usage information obtained by the usage information acquisition unit 202. The predetermined amount information indicating the predetermined amount is stored in the data storage unit 100. The predetermined amount may be common to all stores, or it may be determined for each store or each user. The usage condition determination unit 203 determines whether usage condition 3 is met based on the predetermined amount information stored in the data storage unit 100 and the amount used indicated by the usage information.

[0115] In the second embodiment, as in the first embodiment, we take the example of a case where payment corresponds to the use of a payment application. The usage condition determination unit 203 determines, based on the usage information, whether or not the usage conditions for payment are met. The usage condition determination unit 203 also determines whether or not the usage conditions indicating whether or not the user can use installment payments, etc., for payment are met. The method for determining the usage conditions is as described above.

[0116] In the second embodiment, similar to the first embodiment, we take the example of a case where a lump-sum payment is initially executed, and then the lump-sum payment is changed to an installment payment or the like. The usage condition determination unit 203 determines whether the usage conditions are met after the initial lump-sum payment has been executed. For example, when the timing for recording usage information arrives, the usage condition determination unit 203 determines whether the usage conditions are met based on the usage information.

[0117] The use condition determination unit 203 may determine only one or two of the use conditions 1 to 3. The use condition determination unit 203 may determine use conditions other than the use conditions 1 to 3. For example, when only specific products or services are eligible for installment payments, the use condition determination unit 203 may determine whether the use conditions are met by determining whether the product or service is eligible for installment payments. When an upper limit (e.g., 10 times per month) is set for the number of installment payments, etc. that a user can use in a certain period (e.g., one month), the use condition determination unit may determine whether the use conditions are met by determining whether the upper limit has been reached.

[0118] [Processing Execution Unit] The process execution unit 201 executes a process related to installment payment, etc., based on the determination result of the use condition determination unit 203. If the process execution unit 201 determines that the use conditions are not satisfied, the process execution unit 201 does not execute a process for installment payment, etc., and if the process execution unit 201 determines that the use conditions are satisfied, the process execution unit 201 executes a process for installment payment, etc., on the condition that the use conditions are satisfied. The meaning of the process for installment payment, etc. may be the same as in the first embodiment. Note that the process execution unit 201 in the second embodiment may execute a process similar to that in the first embodiment.

[0119] For example, when multiple use conditions are set, the process execution unit 201 may not execute a process such as installment payment if it is determined that at least some of the use conditions are not satisfied, and may execute a process such as installment payment if it is determined that all of the use conditions are satisfied. The process execution unit 201 may not execute a process such as installment payment if it is determined that a predetermined number or more of the use conditions are not satisfied, and may execute a process such as installment payment if it is determined that a predetermined number or more of the use conditions are satisfied.

[0120] In the second embodiment, as in the first embodiment, an example is taken of a case where payment of a price corresponds to the use of a payment app. The process execution unit 201 executes a process such as installment payment for the payment of a price based on the determination result of the use condition determination unit 203. If the process execution unit 201 determines that the use conditions are not met, it does not execute a process such as installment payment for the payment of a price, and if it determines that the use conditions are met, the process execution unit 201 executes a process such as installment payment for the payment of a price.

[0121] In the second embodiment, as in the first embodiment, an example is taken of a case where a lump sum payment is initially made, and then the lump sum payment is changed to installment payments or the like and processed. After the lump sum payment is initially made, the processing execution unit 201 executes processing of installment payments or the like in the payment of the price. If it is determined that the terms of use are not met, the processing execution unit 201 processes the lump sum payment as is without changing it to installment payments or the like in the payment of the price, and if it is determined that the terms of use are met, the processing execution unit 201 changes the lump sum payment to installment payments or the like and processes the payment of the price.

[0122] [2-2-3. Functions implemented on user devices] The functions of the user terminal 30 may be the same as those in the first embodiment.

[0123] [2-2-4. Functions realized by store terminals] The functions of the store terminal 40 may be the same as those in the first embodiment.

[0124] [2-3. Processing executed in the payment system of the second embodiment] Fig. 10 is a diagram showing an example of processing executed in the payment system 1 of the second embodiment. Fig. 10 describes processing related to determining the terms of use, among the processing executed in the payment system 1. For example, the processing of Fig. 10 may be executed after the processing of S100 to S111 described in the first embodiment has been executed. The processing of Fig. 10 is executed by the control units 11 and 21 executing programs stored in the storage units 12 and 22, respectively.

[0125] As shown in Fig. 10, the payment server 10 determines whether the timing for recording the usage information (for example, a predetermined time in a day) has arrived (S200). In S200, the payment server 10 determines whether the timing for recording the usage information has arrived by determining whether the predetermined time has arrived. In S200, if it is not determined that the timing for recording the usage information has arrived (S200: N), the process returns to S200 again.

[0126] If it is determined in S200 that the timing for recording the usage information has arrived (S200: Y), the payment server 10 acquires, from the payment database DB1, usage information to be used to determine the usage conditions (S201). In S201, the payment server 10 acquires, from the payment database DB1, usage information that includes a usage date and time within the period from the most recent determination timing to the present time. The payment server 10 transmits the usage information acquired in S201 to the card server 20 (S202). The card server 20 acquires the usage information from the payment server 10 (S203).

[0127] The card server 20 identifies a payment that is eligible for installment payment or the like based on the usage information, and determines whether the usage conditions are met based on the usage information of the identified payment (S204). If it is determined in S204 that the usage conditions are met (S204: Y), the payment server 10 changes the usage information for which it is determined that the usage conditions are met from a lump sum payment to an installment payment or the like and records the change (S205). If it is determined in S204 that the usage conditions are not met (S204: N), the payment server 10 does not execute the process of S205, and records the usage information for which it is determined that the usage conditions are met as a lump sum payment (S206).

[0128] The card server 20 determines whether or not the recording of the usage information has been completed (S207). In S207, the card server 20 determines whether or not the processing from S204 onwards has been executed for all usage information that is subject to installment payments, etc. If it is determined in S207 that the recording of the usage information has not been completed (S207: N), the process returns to S204. The card server 20 records the usage information that has not yet been recorded. If it is determined in S207 that the recording of the usage information has been completed (S207: Y), this process ends.

[0129] [2-4. Summary of the second embodiment] The payment system 1 of the second embodiment acquires usage information regarding the use of payment methods available in the payment app. Based on the usage information, the payment system 1 determines whether usage conditions for the use of installment payments, etc. are satisfied. Based on the determination result of the usage conditions, the payment system 1 executes processes such as installment payments. As a result, the payment system 1 can use the determination of whether usage conditions are satisfied as a condition for executing processes such as installment payments, thereby preventing installment payments, etc. that are not intended by administrators of payment services, users, etc., from being executed, thereby improving user convenience. From the perspective of administrators and stores, the payment system 1 can also prevent unintended installment payments, etc. from being executed, thereby improving the convenience of administrators and stores. For example, the payment system 1 can prevent installment payments, etc. from being executed at stores that do not support installment payments, etc. The payment system 1 can prevent installment payments, etc. that exceed the user's credit limit. The payment system 1 can prevent low-amount installment payments, etc.

[0130] The payment system 1 also acquires usage information for payment of goods or services provided by stores that accept the payment method. Based on the usage information, the payment system 1 determines whether the usage conditions for payment of the price are met. Based on the results of the usage conditions determination, the payment system 1 executes the payment process. This allows the payment system 1 to prevent unintended installment payments, etc. from being made when paying the price, thereby improving user convenience.

[0131] Furthermore, when payment of the price is instructed, the payment system 1 processes the payment as a lump sum payment, just as if installment payment or the like was not specified, and then executes processing to change to installment payment or the like. This allows the payment system 1 to provide users with functions such as installment payment without modifying the store terminal 40. The payment system 1 can process the payment as a lump sum payment even if the terms of use are not met, thereby improving user convenience.

[0132] 3. Third Embodiment A third embodiment, which is an example of an embodiment of the payment system 1, payment method, and program according to the present disclosure, will be described. In the third embodiment, a description of the same configuration as the first or second embodiment will be omitted. For example, the hardware configuration of the payment system 1 may be the same as that of the first embodiment.

[0133] [3-1. Overview of the Third Implementation] In the third embodiment, an example will be given in which a setting such as installment payment is automatically cancelled based on a predetermined cancellation condition. The cancellation condition is a criterion for determining whether or not the setting such as installment payment is cancelled. The cancellation condition may be any condition defined by the payment service. The cancellation condition may be a combination of multiple conditions. For example, the cancellation condition may be that the payment app is used with the setting such as installment payment, that the payment app is terminated, that the payment app is moved from the foreground to the background, that a predetermined time has passed since the setting such as installment payment was made, that the expiration date set in the code ID has passed, or other conditions. The cancellation condition may be that the usage conditions are not met. If the usage conditions are not met, the setting such as installment payment may be automatically cancelled.

[0134] In the third embodiment, as in the first and second embodiments, an example is given in which a user uses a payment service from a payment app; however, the user may use the payment service from means other than a payment app. For example, the user may display code C10 on the browser of the user terminal 30 and use the payment service from the browser. The user may use the payment service from the IC chip of the user terminal 30 (e.g., touch payment) rather than from a screen displayed on the user terminal 30. The user may use the payment service with a card (a physical plate-shaped card) such as an IC card or magnetic card instead of the user terminal 30. The user may use the payment service through biometric authentication without using the user terminal 30 and a medium such as a card.

[0135] Figure 11 is a diagram showing an example of processing executed by the payment system 1 of the third embodiment. In the third embodiment, an example is given in which the cancellation condition corresponds to the execution of a payment with the installment payment setting specified. For example, when a user specifies the installment payment setting as in the first embodiment, the user terminal 30 displays on the display unit 35 a code screen SC1 including a panel P11 indicating that the installment payment setting has been specified, as shown in the upper left of Figure 11.

[0136] For example, when the store terminal 40 reads the code C10, the user terminal 30 displays a completion screen SC3 on the display unit 35, indicating that payment has been completed, as shown in the upper right of FIG. 11. The completion screen SC3 may also indicate that the installment payment settings have been cancelled. When the user performs an operation to return to the code screen SC1, the user terminal 30 displays on the display unit 35 the code screen SC1 including a panel P11, indicating that the installment payment settings have been cancelled, as shown in the lower left of FIG. 11. If the user wishes to make an installment payment for the next payment, the user specifies the installment payment settings again, following the same process as in the first embodiment.

[0137] As described above, the payment system 1 of the third embodiment cancels the setting of installment payments, etc., based on a cancellation condition, for example, when a payment is made with the setting of installment payments, etc., specified. This eliminates the need for the user to manually cancel the setting of installment payments, etc., so the payment system 1 can reduce the operational burden on the user and increase user convenience. Details of the third embodiment will be described below.

[0138] [3-2. Functions implemented in the payment system of the third embodiment] Figure 12 is a diagram showing an example of functions implemented in the payment system 1 of the third embodiment. Although some of the functions described in the first and second embodiments are not shown in Figure 12, the payment system 1 of the third embodiment may include the functions described in the first and second embodiments. The units implemented in the payment system 1 of the third embodiment can be configured by consolidating them into a single device or by distributing them into smaller devices.

[0139] The payment system 1 of the third embodiment may not include at least one of the functions described in the first embodiment (e.g., the function for displaying a setting screen such as the payment source selection screen SC2) and the functions described in the second embodiment (e.g., the function for determining the terms of use and related functions). For example, the payment system 1 of the third embodiment may execute installment payments for which no particular terms of use are specified. This also applies to the fourth embodiment described below.

[0140] As described above, an embodiment in which the payment system 1 does not include at least one of the functions described in the first embodiment and the functions described in the second embodiment, but includes the functions described in the third embodiment, is within the scope of the present disclosure. Of course, an embodiment in which the payment system 1 includes at least one of the functions described in the first embodiment and the functions described in the third embodiment is also within the scope of the present disclosure. These points are matters that a person skilled in the art would naturally understand from the description of the present disclosure.

[0141] [3-2-1. Functions implemented by the payment server] For example, the payment server 10 includes a data storage unit 100, a processing execution unit 102, a setting acquisition unit 104, and a setting cancellation unit 105. The setting acquisition unit 104 and the setting cancellation unit 105 are implemented by the control unit 11.

[0142] [Data Storage Unit] The data storage unit 100 may be the same as in the first or second embodiment. In a third embodiment, the data storage unit 100 may store cancellation condition data indicating a cancellation condition. The cancellation condition data may be in any format, such as a table format, a mathematical formula format, part of a program, a machine learning model, or other format. In the example of FIG. 11, it is assumed that cancellation condition data indicating that a setting such as installment payment should be cancelled when a payment specifying the setting is made is stored in the data storage unit 100.

[0143] [Settings Acquisition Section] The setting acquisition unit 104 acquires settings related to installment payments and the like of payment methods available to the user. The function of the setting acquisition unit 104 may be the same as the function described as part of the function of the process execution unit 102 in the first embodiment. In the third embodiment, as in the first and second embodiments, an example is given in which payment of a price corresponds to the use of a payment app, and therefore the setting acquisition unit 104 acquires settings related to installment payments and the like for payment of a price.

[0144] In the third embodiment, since the settings for installment payments and the like are stored in the payment database DB1, the setting acquisition unit 104 acquires the settings for installment payments and the like from the payment database DB1. For example, the setting acquisition unit 104 acquires the settings for installment payments and the like associated with the code ID included in the payment request received from the store terminal 40 from the payment database DB1. The settings for installment payments and the like may be stored in a database other than the payment database DB1. The setting acquisition unit 104 may acquire the settings for installment payments and the like from another database. The settings for installment payments and the like may be stored in a computer other than the payment server 10 or an external information storage medium. The setting acquisition unit 104 may acquire the settings for installment payments and the like from another computer or an external information storage medium.

[0145] [Processing Execution Unit] The processing execution unit 102 executes processing related to installment payments, etc., based on the settings for installment payments, etc., acquired by the setting acquisition unit 104. In the second embodiment, as in the first embodiment, an example is given in which payment of a price corresponds to the use of a payment app, and therefore the processing execution unit 102 executes processing for payment of a price, based on the settings for installment payments, etc., acquired by the setting acquisition unit 104. The processing of the processing execution unit 102 may be the same as in the first embodiment. In the third embodiment, as in the first embodiment, an example is given in which, after a lump-sum payment has been executed, the lump-sum payment is changed to installment payments, etc.

[0146] [Cancel settings section] The setting cancellation unit 105 cancels the setting of installment payments, etc., based on a predetermined cancellation condition. Canceling the setting of installment payments, etc., means changing the setting of installment payments, etc., from a state indicating that installment payments, etc., are used to a state indicating that installment payments, etc., are not used. Canceling the setting of installment payments, etc., includes both cases where the setting of installment payments, etc., is canceled when the cancellation condition is met and remains canceled thereafter, and cases where the setting of installment payments, etc., is temporarily canceled when the cancellation condition is met, but is not canceled unless the cancellation condition is met in the next use. For example, deleting the setting of installment payments, etc., stored in the payment database DB1, or changing the setting of installment payments, etc., stored in the payment database DB1 to a value indicating that installment payments, etc., are not used, corresponds to canceling the setting of installment payments, etc.

[0147] For example, if it is determined that the cancellation condition is not satisfied, the setting cancellation unit 105 does not cancel the setting of installment payments, etc., and if it is determined that the cancellation condition is satisfied, the setting cancellation unit 105 cancels the setting of installment payments, etc. The setting cancellation unit 105 may determine whether or not the cancellation condition is satisfied using a determination method according to the content of the cancellation condition. For example, the setting cancellation unit 105 acquires cancellation condition data stored in the data storage unit 100 and determines whether or not the cancellation condition indicated by the cancellation condition data is satisfied. If the cancellation condition data indicates multiple cancellation conditions, the setting cancellation unit 105 determines whether or not each of the multiple cancellation conditions is satisfied.

[0148] For example, the setting cancellation unit 105 determines whether the cancellation condition is satisfied by determining whether payment of the price (for example, payment by reading the code C10) has been made, and cancels the setting if it is determined that payment of the price has been made. The payment of the price here refers to payment made when installment payments or the like have been set. The setting cancellation unit 105 determines whether the cancellation condition is satisfied by referring to the processing result of the processing execution unit 102 and determining whether payment processing has been executed in response to a payment request from the store terminal 40. The execution of payment of the price corresponds to the cancellation condition being satisfied. The non-execution of payment of the price corresponds to the cancellation condition not being satisfied.

[0149] In the second embodiment, as in the first embodiment, an example is given in which payment of a price corresponds to the use of a payment app, and therefore the setting cancellation unit 105 cancels the setting of installment payments, etc. for payment of a price based on the cancellation conditions. For example, if it is determined that the cancellation conditions are not met, the setting cancellation unit 105 does not cancel the setting of installment payments, etc. for payment of a price, and if it is determined that the cancellation conditions are met, the setting cancellation unit 105 cancels the setting of installment payments, etc. for payment of a price.

[0150] [3-2-2. Functions realized by the card server] The function of the card server 20 may be the same as that of the first or second embodiment.

[0151] [3-2-3. Functions implemented on the user terminal] The functions of the user terminal 30 may be the same as those of the first or second embodiment.

[0152] [3-2-4. Functions implemented on store terminals] The functions of the store terminal 40 may be the same as those of the first or second embodiment.

[0153] [3-3. Processing performed in the payment system of the third embodiment] Figure 13 is a diagram showing an example of processing executed in the payment system 1 of the third embodiment. The processing in Figure 13 is executed by control units 11, 21, 31, and 41 executing programs stored in storage units 12, 22, 32, and 42, respectively. Figure 13 mainly describes processing executed in the payment system 1, particularly processing for canceling settings such as installment payments.

[0154] As shown in Fig. 13, the processes of S300 to S310 are the same as S100 to S110, respectively. When the process of installment payment, etc. in S310 is executed, the payment server 10 determines that the cancellation condition has been met and cancels the setting of installment payment, etc. (S311). In S311, the payment server 10 deletes the setting of installment payment, etc. stored in the payment database DB1. The process of the following S312 may be the same as S111. Since the setting of installment payment, etc. has been canceled in S311, the payment server 10 may display information such as a message indicating that the setting of installment payment, etc. has been canceled on the completion screen SC3.

[0155] [3-4. Summary of the Third Embodiment] The payment system 1 of the third embodiment acquires settings for installment payments, etc. The payment system 1 executes processing for installment payments, etc. based on the settings for installment payments, etc. The payment system 1 cancels the settings for installment payments, etc. based on predetermined cancellation conditions. This eliminates the need for the user to manually cancel the settings for installment payments, etc., so the payment system 1 can reduce the operational burden on the user and increase user convenience. For example, the payment system 1 can prevent installment payments, etc. from being made even if the user does not want to make installment payments, etc., while the settings for installment payments, etc. remain.

[0156] Furthermore, the payment system 1 acquires settings for installment payments, etc. for payment of the price. The payment system 1 executes the process for installment payments, etc. for payment of the price based on the settings for installment payments, etc. The payment system 1 cancels the settings for installment payments, etc. for payment of the price based on the cancellation conditions. This eliminates the need for the user to manually cancel the settings for installment payments, etc. every time they make a payment, thereby improving the convenience of the user when making payments of the price.

[0157] Furthermore, the payment system 1 determines whether the cancellation condition is met by determining whether payment of the price has been made, and cancels the setting if it is determined that payment of the price has been made. This allows the payment system 1 to cancel the setting of installment payments, etc., every time a payment using installment payments, etc. is made. For example, when there are few or no users who want to use installment payments, etc., consecutively, the payment system 1 can improve user convenience.

[0158] [4. Fourth Embodiment] A fourth embodiment, which is an example of an embodiment of the payment system 1, payment method, and program related to this disclosure, will be described. In the fourth embodiment, the same configuration as in the first to third embodiments will not be described. For example, the hardware configuration of the payment system 1 may be the same as in the first embodiment.

[0159] [4-1. Overview of the Fourth Embodiment] The fourth embodiment takes as an example a payment system 1 that does not include at least one of the functions described in the first embodiment (for example, a function for displaying a setting screen such as the payment source selection screen SC2), the functions described in the second embodiment (for example, a function for determining the terms of use and related functions), and the functions described in the third embodiment (for example, a function for canceling the setting of installment payments, etc., according to the cancellation conditions). For example, the payment system 1 may be capable of setting installment payments, etc., from the code screen SC1 without having the functions described in the first embodiment.

[0160] FIG. 14 is a diagram showing an example of processing executed by the payment system 1 of the fourth embodiment. In the fourth embodiment, an example is given in which, when a user makes a payment at a store using a payment app, settings such as installment payment are specified for the store terminal 40. In the example of FIG. 14, the store terminal 40 is a self-checkout. For example, the user causes the store terminal 40 to read the barcode of an item and performs an operation to select a payment method on the store terminal 40. When the user selects code payment using code C10 as the payment method, the store terminal 40 displays a settings screen SC4 on the display unit 45, as shown in FIG. 14, for specifying settings such as installment payment.

[0161] For example, the user specifies settings for installment payments, etc., from the setting screen SC4. The content that can be specified as the settings for installment payments, etc., may be the same as in the first embodiment. However, the first embodiment is different in that the example is a case where the settings for installment payments, etc., are specified from the payment source selection screen SC2 on the user terminal 30, whereas the fourth embodiment is different in that the example is a case where the settings for installment payments, etc., are specified from the setting screen SC4 of the store terminal 40, but the basic setting flow may be the same as in the first embodiment.

[0162] The example in Figure 14 shows a settings screen SC4 when the user selects installment payment. For example, the settings screen SC4 displays a button B40 that accepts the specification of the number of installments. The user can specify any number of installments. When the user specifies the number of installments and has the store terminal 40 read the code C10 on the code screen SC1, the store terminal 40 sends a payment request to the payment server 10. The payment request includes settings such as the number of installments specified by the user. Note that the user may also be able to specify settings at the store terminal 40 indicating that they wish to use revolving payment or bonus payment.

[0163] For example, when the payment server 10 receives a payment request from the store terminal 40, it determines whether or not the payment request includes a setting for installment payments, etc. If the payment server 10 determines that the payment request does not include a setting for installment payments, etc., it processes the payment request as a lump-sum payment, as in the past. If the payment server 10 determines that the payment request does not include a setting for installment payments, etc., it processes the installment payments, etc., in the same manner as in the first embodiment. In the fourth embodiment, the terms of use may be determined in the same manner as in the second embodiment, and the setting for installment payments, etc. may be canceled after payment of the price, as in the third embodiment.

[0164] As described above, the payment system 1 of the fourth embodiment executes processes such as installment payments from a payment app based on the settings for installment payments, etc. For example, the payment system 1 executes processes such as installment payments for payment using the code C10 on the code screen SC1. While FIG. 14 illustrates an example of a setting method different from that of the first embodiment, the fourth embodiment may also use a setting method similar to that of the first embodiment to set up installment payments, etc. For this reason, the payment system 1 of the fourth embodiment can also be considered a generic payment system 1 that encompasses the first embodiment. The payment system 1 of the fourth embodiment may also be a generic payment system 1 that encompasses at least the second and third embodiments. Details of the fourth embodiment will be described below.

[0165] [4-2. Functions realized by the payment system of the fourth embodiment] Figure 15 shows an example of the functions implemented in the payment system 1 of the fourth embodiment. Although some of the functions described in the first to third embodiments are not shown in Figure 15, the payment system 1 of the fourth embodiment may include the functions described in the first to third embodiments. The components implemented in the payment system 1 of the fourth embodiment can be configured by combining them into a single device or by further distributing them among multiple devices.

[0166] [4-2-1. Functions implemented by the payment server] For example, the payment server 10 includes a data storage unit 100, a process execution unit 102, and a setting acquisition unit 104.

[0167] [Data Storage Unit] The data storage unit 100 may be the same as those in the first to third embodiments. The payment database DB1 in the fourth embodiment does not need to store settings such as installment payments.

[0168] [Settings Acquisition Section] The setting acquisition unit 104 may be the same as in the third embodiment. In the fourth embodiment, a type of payment in which code C10 is read is performed, so the processing execution unit 102 acquires settings such as installment payments for the payment of goods or services provided by the store in which code C10 displayed in the payment app is read. The setting acquisition unit 104 may acquire settings such as installment payments from the payment database DB1, as in the first to third embodiments.

[0169] In the example shown in Figure 14, the setting acquisition unit 104 acquires the settings for installment payments, etc., specified on the setting screen SC4 displayed on the store terminal 40. For example, the setting acquisition unit 104 acquires the settings for installment payments, etc., included in the payment request from the store terminal 40. In the fourth embodiment, the settings for installment payments, etc., do not need to be stored in the payment database DB1. In the case of a payment where a code displayed on the store terminal 40 is read by the user terminal 30, the setting acquisition unit 104 may acquire the settings for installment payments, etc., included in the payment request from the user terminal 30.

[0170] [Processing Execution Unit] The processing execution unit 102 may be the same as in the first or third embodiment. The processing of the processing execution unit 102 may be the same as the processing of the processing execution unit 102 in the second embodiment. In the fourth embodiment, a type of payment in which code C10 is read is performed, so when code C10 is read at the store, the processing execution unit 102 executes installment payment processing based on the settings for installment payments, etc. In the example in Figure 14, the processing execution unit 102 executes installment payment processing based on the settings for installment payments, etc. specified on the setting screen SC4 of the store terminal 40. The installment payment processing itself may be the same as in the first or third embodiment. The installment payment processing may be the same as the processing of the processing execution unit 102 in the second embodiment.

[0171] [4-2-2. Functions implemented by the card server] The functions of the card server 20 may be the same as those of the first to third embodiments.

[0172] [4-2-3. Functions implemented on user devices] The functions of the user terminal 30 may be the same as those of the first to third embodiments.

[0173] [4-2-4. Functions realized by store terminals] The functions of the store terminal 40 may be the same as those of the first to third embodiments.

[0174] [4-3. Processing performed in the payment system of the fourth embodiment] Figure 16 shows an example of the processing performed in the payment system 1 of the fourth embodiment. The processing in Figure 16 is performed by the control units 11, 21, 31, and 41 executing the programs stored in the storage units 12, 22, 32, and 42, respectively. In Figure 16, as in Figure 14, an example is given in which settings such as installment payments are specified on the setting screen SC4 of the store terminal 40. However, in the fourth embodiment as well, the user may be able to use installment payments in a flow similar to that described in the first to third embodiments.

[0175] As shown in FIG. 16, the processes of S400 and S401 are the same as the processes of S100 and S101, respectively. The store terminal 40 displays a setting screen SC4 on the display unit 45, which accepts the specification of settings for installment payments, etc. (S402). The store terminal 40 accepts the specification of settings for installment payments, etc. from the setting screen SC4 (S403). When the code C10 on the code screen SC1 is read by the reading unit 46, the store terminal 40 transmits a payment request based on the code ID acquired from the code C10 to the payment server 10 (S404). If settings for installment payments, etc. are specified, the payment request includes the settings for installment payments, etc.

[0176] When the payment server 10 receives a payment request from the store terminal 40 (S405), it executes processing for card payment with the card server 20 (S406). In S406, it is processed as a lump-sum payment for the time being. The payment server 10 determines whether or not the payment request includes a setting for installment payment or the like (S407). If it is determined in S407 that the payment request includes a setting for installment payment or the like (S407: Y), the payment server 10 executes the processing of S408 to S410, which is the same as S109 to S111. If it is determined in S407 that the payment request does not include a setting for installment payment or the like (S407: N), the processing of S408 and S409 is not executed, and the processing of S410 is executed.

[0177] [4-4. Summary of the Fourth Embodiment] The payment system 1 of the fourth embodiment acquires settings for installment payments and the like. The payment system 1 executes processes for installment payments and the like. This allows users to use installment payments and the like from a payment app, thereby improving user convenience. For example, a user can use installment payments and the like by simply preparing a payment app without having to prepare a plate-shaped card, allowing users to use various payment methods with the payment app.

[0178] Furthermore, the payment system 1 acquires settings for installment payments, etc., for payment of the price of goods or services provided by a store where the code C10 displayed on the payment app is read. When the code C10 is read at the store, the payment system 1 executes processing for installment payments, etc., based on the settings for installment payments, etc. This allows the user to use installment payments, etc., when paying for a price using the code C10 of the payment app, thereby improving the user's convenience in paying for a price. For example, the user can use installment payments, etc., by presenting the code screen SC1 of the payment app, without having to present a flat card at the store, so that the user can use various payment methods with the payment app.

[0179] [5. Variant] The present disclosure is not limited to the first to fourth embodiments described above. The present disclosure can be modified as appropriate without departing from the spirit of the present disclosure. Modifications of each of the first to fourth embodiments will be described below.

[0180] [5-1. Modifications relating to the first embodiment] 17 is a diagram showing an example of functions realized in a modification of the first embodiment. For example, the payment server 10 includes a store information acquisition unit 106, a first correspondence determination unit 107, a second correspondence determination unit 108, a use condition determination unit 109, and a simulation execution unit 110. Each of the store information acquisition unit 106, the first correspondence determination unit 107, the second correspondence determination unit 108, the use condition determination unit 109, and the simulation execution unit 110 is realized by the control unit 11.

[0181] [Variation 1-1] For example, the setting screen that accepts the specification of settings such as installment payments is not limited to the payment source selection screen SC2. The setting screen may be a screen other than the payment source selection screen SC2. In variant example 1-1, the code screen SC1 corresponds to the setting screen. The display control unit 101 of variant example 1-1 displays the code screen SC1, which includes the code C10 related to payment of the price, on the user terminal 30 as the setting screen.

[0182] FIG. 18 is a diagram showing an example of a code screen SC1 of Modification Example 1-1. As shown in the upper left of FIG. 18, the display control unit 101 transmits display data for the code screen SC1 similar to that shown in the upper left of FIG. 2 to the user terminal 30, thereby causing the code screen SC1 to be displayed on the user terminal 30. Based on the display data, the user terminal 30 causes the display unit 35 to display the code screen SC1. The code screen SC1 of Modification Example 1-1 includes a user interface part that accepts settings such as installment payments. In the example in the upper left of FIG. 18, the pull-down menu P110 of the panel P11 corresponds to this part. This part is not limited to the pull-down menu P110. This part may also be another part such as a button or a panel.

[0183] Hereinafter, an example will be given in which a user specifies installment payment settings. For example, when a user selects a pull-down menu P110, the user terminal 30 displays the number of installments that the user can specify in the pull-down menu P110, as shown in the upper right of FIG. 18. When a user selects a number of installments from the pull-down menu P110, the user terminal 30 displays the number of installments selected by the user in the pull-down menu P110, as shown in the lower left of FIG. 18. This series of processes may be executed by a script included in the display data of the code screen SC1, or may be executed by the user terminal 30 communicating with the payment server 10 each time the user operates the code screen SC1. This series of processes may be indicated in the program code of the payment app.

[0184] For example, the user terminal 30 sends the installment payment settings specified by the user from the pull-down menu P110 (i.e., data indicating the installment payment settings) to the payment server 10. The payment server 10 stores the installment payment settings received from the user terminal 30 in the payment database DB1, associating them with the user's user ID. If the user cancels the installment payment settings from the pull-down menu P110 (in the example in the upper right of Figure 18, the user selects "lump-sum payment"), the user terminal 30 sends a request to the payment server 10 indicating that it wants to cancel the installment payment settings. Based on the request received from the user terminal 30, the payment server 10 cancels the installment payment settings associated with the user's user ID. The meaning of canceling the installment payment settings is as explained in the third embodiment.

[0185] Furthermore, when a user specifies a revolving payment or bonus payment setting, the display of the code screen SC1 may be controlled in the same manner as when a user specifies an installment payment setting. For example, the display control unit 101 may display the code screen SC1 on the user terminal 30 by transmitting the display data of the code screen SC1, which includes a user interface part that accepts the specification of a revolving payment or bonus payment setting, to the user terminal 30.

[0186] Furthermore, the method for generating the code C10 included in the code screen SC1 may be the same as in the first embodiment. The display control unit 101 generates a code ID that does not overlap with other code IDs, and generates the display data for the code screen SC1 based on the code ID. The process of converting the code ID to code C10 may be performed on the payment server 10 side or on the user terminal 30 side. The display control unit 101 generates all or part of the data necessary for displaying the code screen SC1, including the code C10 for code payment and parts of the user interface that accept the specification of settings such as installment payments, as the display data for the code screen SC1 and transmits it to the user terminal 30.

[0187] When the code C10 on the code screen SC1 is read at a store, the processing execution unit 102 in Modification Example 1-1 executes processing for payment of the price, such as installment payment, based on the setting of the installment payment, etc., specified on the code screen SC1. For example, when the code C10 is read by the reading unit 46 of the store terminal 40, the store terminal 40 transmits the code ID obtained from the code C10 to the payment server 10. The processing execution unit 102 executes a lump-sum payment for the time being based on the code ID received from the store terminal 40, and if the setting of the installment payment, etc., is specified, generates transaction information indicating that the payment is eligible for installment payment, etc., and stores the transaction information in the payment database DB1. The processing after the code C10 is read may be the same as in the first embodiment.

[0188] The payment system 1 of variation 1-1 displays the code screen SC1 as a settings screen on the user terminal 30. When the code C10 on the code screen SC1 is read at a store, the payment system 1 executes a process for payment of the price, such as installment payments, based on the settings for installment payments, etc., specified on the code screen SC1. Because the user can specify the settings for installment payments, etc., directly from the code screen SC1 displayed at the time of payment, the payment system 1 can improve user convenience.

[0189] [Variation 1-2] For example, as in variant example 1-1, when the code screen SC1 corresponds to a setting screen, the display control unit 101 may cause the user terminal 30 to display the code screen SC1 that accepts a first operation for starting the setting of installment payments, etc. The first operation is an operation that is performed before specifying the details of the setting of installment payments, etc. In other words, the first operation is an operation for displaying a part of a user interface that accepts the specification of the details of the setting of installment payments, etc. The first operation is an operation that is performed before a second operation, which will be described later. The first operation can also be said to be an operation for starting the setting of installment payments, etc. The code screen SC1 includes a part of a user interface that accepts the first operation.

[0190] FIG. 19 is a diagram showing an example of a code screen SC1 of Modification Example 1-2. The code screen SC1 in the upper left of FIG. 19 is similar to the code screen SC1 in the upper left of FIG. 18. In the example in the upper left of FIG. 19, a pull-down menu P110 corresponds to a part of the user interface that accepts a first operation. The user performs the first operation by selecting the pull-down menu P110. The first operation is not limited to selecting the pull-down menu P110. The first operation may be any operation performed from the code screen SC1. For example, the first operation may be an operation of selecting another part, such as a button or a panel, instead of the pull-down menu P110.

[0191] When a first operation is performed on the code screen SC1 in Modification 1-2, the display control unit 101 causes the user terminal 30 to display a user interface that accepts a second operation for specifying details of the settings for installment payments, etc., so as to be superimposed on the code screen SC1. The second operation is an operation that is performed after the first operation. For example, the second operation may be an operation that specifies whether or not to use installment payments, etc. The second operation may be an operation that specifies the number of installments for installment payments, the payment amount or number of payments for revolving payments, or the bonus month for bonus payments. The second operation can also be an operation that specifies a numerical value that indicates the settings for installment payments, etc. In Modification 1-2, the user performs at least two operations, including the first operation and the second operation, to complete the settings for installment payments, etc.

[0192] Hereinafter, an example will be given in which a user specifies an installment payment setting. For example, the display control unit 101 includes a script instructing that a user interface for accepting a second operation be displayed when a first operation is performed in the display data of the code screen SC1, thereby causing the user terminal 30 to display the user interface. For example, when the user selects the pull-down menu P110 in the state of the code screen SC1 in the upper left of FIG. 19, the user terminal 30 executes the script included in the display data of the code screen SC1, and displays a modal M12 including a panel P120 for accepting a specification of the number of installments, superimposed on the code screen SC1, as shown in the upper right of FIG. 19.

[0193] In the example at the top right of FIG. 19, modal M12 corresponds to a user interface that accepts the second operation. This user interface may be a user interface other than modal M12. For example, this user interface may be another user interface such as a pop-up or a window. This user interface is displayed so as to be superimposed on all or part of code screen SC1. Note that in the example at the top right of FIG. 19, modal M12 is similar to modal M21 at the bottom left of FIG. 2, but may have a different layout from modal M21.

[0194] For example, the user performs the second operation by selecting a panel P120 indicating the desired number of divisions from modal M12. When the user selects panel P120, as shown in the lower left of FIG. 19, the user terminal 30 closes modal M12 and displays the number of divisions indicated by panel P120 in a pull-down menu P110. This series of processes may be executed by a script included in the display data of code screen SC1, or may be executed by the user terminal 30 communicating with the payment server 10 each time the user performs an operation on code screen SC1. This series of processes may be specified in the program code of the payment app.

[0195] For example, the user terminal 30 transmits to the payment server 10 the installment payment settings specified by the user from panel P120 of modal M12 (i.e., data indicating the installment payment settings). The payment server 10 stores the installment payment settings received from the user terminal 30 in the payment database DB1 in association with the user's user ID. If the user cancels the installment payment settings from panel P120 of modal M12 (in the example at the top right of FIG. 19, the user selects "None"), the user terminal 30 transmits to the payment server 10 a request indicating that the installment payment settings be canceled. Based on the request received from the user terminal 30, the payment server 10 cancels the installment payment settings associated with the user's user ID.

[0196] Furthermore, when a user specifies whether to set up revolving credit or bonus payments, the display of the code screen SC1 may be controlled in the same manner as when a user specifies whether to set up installment payments. For example, when the first operation is performed, the display control unit 101 may display a user interface that accepts a second operation to specify the details of the revolving credit or bonus payment settings, superimposed on the code screen SC1. The display control unit 101 may control these processes by sending display data containing a script that shows these processes to the user terminal 30, or it may control these processes by communicating with the user terminal 30 each time the user performs an operation on the code screen SC1. These processes may also be shown in the program code of the payment application.

[0197] Furthermore, although it differs from Modification 1-1 in that display control is performed according to the first and second operations, the processing for displaying code C10, such as generating a code ID, may be the same as in Modification 1-1. The processing execution unit 102 of Modification 1-2 executes the processing for installment payments, etc., in the payment of the price based on the details of the settings for installment payments, etc., specified by the second operation. Although it differs from Modification 1-1 in that display control is performed according to the first and second operations, the processing after code C10 is read may be the same as in Modification 1-1.

[0198] The payment system 1 of Variation 1-2 displays a code screen SC1 that accepts a first operation on the user terminal 30. When the first operation is performed on the code screen SC1, the payment system 1 displays a user interface that accepts a second operation on the user terminal 30 so that the user interface is superimposed on the code screen SC1. The payment system 1 executes a process such as installment payment for payment of the price based on the details of the settings for the installment payment, etc., specified by the second operation. This allows the user to specify the settings for the installment payment, etc. directly from the modal M12 that is displayed superimposed on the code screen SC1 displayed at the time of payment, thereby improving user convenience. The modal M12 is displayed superimposed on the code screen SC1, and has enough space for the user to perform the second operation, making it easier for the user to specify the details of the settings for the installment payment, etc.

[0199] [Variation 1-3] For example, the payment system 1 may be able to identify in advance which store the payment will be made to before the operation for payment is performed. In this case, the payment system 1 may determine whether the store supports installment payments or the like, and, based on the results of this determination, may display a setting screen, such as the code screen SC1 or the payment source selection screen SC2, on the user terminal 30.

[0200] The payment system 1 of Modification 1-3 includes a store information acquisition unit 106 and a first support determination unit 107. The store information acquisition unit 106 acquires store information about the store before payment is made. The store information may be a store ID that can identify the store, other information that can search for the store ID (for example, the terminal ID of the store terminal 40), the name of the store, compatible store information that indicates whether the store supports installment payments, or other information.

[0201] For example, when the code C10 on the code screen SC1 is read by the store terminal 40 as in the first embodiment, the store information acquisition unit 106 can identify which store the user is located in based on a payment request from the store terminal 40. Alternatively, when the user reads a store code with the user terminal 30, the store information acquisition unit 106 can identify which store the user is located in based on information about the code acquired from the user terminal 30. On the other hand, the store information acquisition unit 106 may acquire store information based on current location information indicating the current location of the user terminal 30 before reading the code, for example, when the user enters the store or when the user stays at a predetermined location for a predetermined period of time or longer. The user terminal 30 includes a GPS receiver. The user terminal 30 acquires current location information indicating the current location of the user terminal 30 detected by the GPS receiver. Modification 1-3 illustrates an example in which the current location of the user terminal 30 is expressed in latitude and longitude. The user terminal 30 transmits the current location information to the payment server 10. The payment server 10 receives the current location information from the user terminal 30.

[0202] The current location of the user terminal 30 may be expressed by information other than latitude and longitude. For example, the current location of the user terminal 30 may be expressed by coordinates other than latitude and longitude, an address, or other information. The method by which the user terminal 30 acquires the current location information may be a known method and is not limited to a method using a GPS receiver. For example, the user terminal 30 may acquire the current location information by a wireless LAN access point, a mobile base station, or another method.

[0203] In Modification 1-3, the data storage unit 100 stores a store database in which basic information about stores is stored. The store database stores a store ID that can identify a store, store location information that indicates the location of the store, and store availability information that indicates whether the store is a store that accepts installment payments, etc. The store database may also store other information such as the name of the store. The store location may be expressed in latitude and longitude, like the current location of the user terminal 30, or may be expressed by other information such as coordinates.

[0204] For example, the store information acquisition unit 106 identifies a store located near the current location of the user terminal 30 based on the current location information and the store location information. Near the current location means a location within a predetermined distance (e.g., a predetermined distance such as 10 meters) from the current location. The store information acquisition unit 106 identifies a store located within a predetermined distance from the current location indicated by the current location information from among stores whose store location information is stored in the store database. The store information acquisition unit 106 acquires corresponding store information of the identified store as store information.

[0205] The method of acquiring store information is not limited to the above example. For example, when a code displayed on the store terminal 40 or a code posted in a store is read by the user terminal 30, the store information acquisition unit 106 may acquire the store ID included in the code as store information. When the user terminal 30 reads the code, the user terminal 30 acquires the store ID from the code and transmits the store ID to the payment server 10. The store information acquisition unit 106 may acquire the store ID from the user terminal 30 as store information. The store information acquisition unit 106 may acquire compatible store information associated with the store ID acquired from the user terminal 30 as store information. For example, the current location may be acquired based on other apps or other functions linked to the payment app (for example, the check-in function of a check-in app or a mini-app "Available Stores" map).

[0206] For example, when a list of stores is displayed on the user terminal 30 and the user selects a store to make payment, the store information acquisition unit 106 may acquire store information of the store selected by the user from the list of stores. The user terminal 30 stores the store IDs of stores included in the list of stores displayed in the payment app. When the user selects a store from the list of stores, the user terminal 30 transmits the store ID of the selected store to the payment server 10. The store information acquisition unit 106 acquires the store ID from the user terminal 30 as store information. The store information acquisition unit 106 may acquire, as store information, corresponding store information associated with the store ID acquired from the user terminal 30.

[0207] The first correspondence determination unit 107 determines whether or not a store supports installment payments, etc., based on the store information. For example, when a store ID corresponds to store information, the first correspondence determination unit 107 obtains compatible store information associated with the store ID, which is store information, from a store database, and determines whether or not the compatible store information indicates a compatible store, thereby determining whether or not the store supports installment payments, etc. When compatible store information corresponds to store information, the first correspondence determination unit 107 may determine whether or not a store supports installment payments, etc., by determining whether or not the compatible store information, which is store information, indicates a compatible store, from the store database.

[0208] The display control unit 101 in Modification 1-3 displays a setting screen, such as the code screen SC1 or the payment source selection screen SC2, on the user terminal 30 based on the determination result of the first correspondence determination unit 107. For example, if the first correspondence determination unit 107 determines that the store does not support installment payments, etc., the display control unit 101 does not display a setting screen for accepting designation of settings for installment payments, etc. on the user terminal 30. If the first correspondence determination unit 107 determines that the store supports installment payments, etc., the display control unit 101 displays a setting screen for accepting designation of settings for installment payments, etc. on the user terminal 30.

[0209] FIG. 20 is a diagram showing an example of a payment app screen in Modification 1-3. FIG. 20 illustrates an example of a payment in which a code displayed on a store terminal 40 is read by the user terminal 30. For example, the code includes information necessary for payment (e.g., a store ID and payment amount). When the user terminal 30 reads the code, it transmits the information included in the code to the payment server 10. When the payment server 10 receives the information included in the code from the user terminal 30, the store information acquisition unit 106 and the first correspondence determination unit 107 execute processing. Based on the information included in the code, the payment server 10 identifies the store that is the subject of the payment (i.e., the store to which the payment is made) and the payment amount. Identifying the store and payment amount may be similar to a mechanism adopted in known payment services.

[0210] For example, if the first correspondence determination unit 107 determines that the store does not support installment payments, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 that does not accept designation of settings for installment payments, as shown on the left side of FIG. 20. In the example on the left side of FIG. 20, the confirmation screen SC5 includes a panel P50 that shows the current payment source. When the user selects panel P50, the user terminal 30 causes the display unit 35 to display a payment source selection screen SC2. In the example on the left side of FIG. 20, the confirmation screen SC5 does not include a pull-down menu P500, which will be described later.

[0211] For example, when the first correspondence determination unit 107 determines that the store supports installment payments, etc., the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 for accepting designation of settings for installment payments, etc., as shown on the right side of FIG. 20. In the example on the right side of FIG. 20, the panel P50 includes a pull-down menu P500 for designating settings for installment payments, etc. The pull-down menu P500 may be similar to the pull-down menu P110 on the code screen SC1. The user can designate settings for installment payments, etc., by selecting the pull-down menu P110. The confirmation screen SC5 on the right side of FIG. 20 is an example of a setting screen.

[0212] For example, when the user selects panel P50 on the confirmation screen SC5 on the right side of FIG. 20, the display control unit 101 causes the user terminal 30 to display a payment source selection screen SC2 similar to the one shown in the upper right of FIG. 2. The flow of specifying settings such as installment payments from the payment source selection screen SC2 may be the same as in the first embodiment. When the user selects pull-down menu P500 in panel P50, the display control unit 101 may cause a modal similar to modal M21 in FIG. 19 to be displayed on the confirmation screen SC5. The flow of specifying settings such as installment payments from this modal may be the same as in Modification 1-2.

[0213] For example, when the user slides the slide bar B51 on the confirmation screen SC5, the user terminal 30 sends a payment request to the payment server 10. The payment request sent from the user terminal 30 to the payment server 10 when the slide bar B51 is slid on the confirmation screen SC5 on the left side of Fig. 20 may be similar to that of a known payment service. When the processing execution unit 102 receives the payment request from the user terminal 30, it executes processing such as installment payment based on the settings for installment payment, etc. stored in the payment database DB1.

[0214] Note that, although the second embodiment differs from the first embodiment in terms of whether the payment request is transmitted from the store terminal 40 or the user terminal 30, the installment payment and other processing executed by the processing execution unit 102 may be the same as in the first embodiment. In addition, in Modification 1-3, the payment request is transmitted from the user terminal 30, and therefore the payment request may include settings for installment payment and other processing specified by the user on the confirmation screen SC5. The processing execution unit 102 may execute the installment payment and other processing based on the settings for installment payment and other processing included in the payment request.

[0215] The payment system 1 of Variation 1-3 acquires store information before payment of the price. Based on the store information, the payment system 1 determines whether the store supports installment payments, etc. Based on the determination result of whether the store supports installment payments, etc., the payment system 1 displays a setting screen on the user terminal 30. This allows the user to specify settings for installment payments, etc. from a setting screen depending on whether the store supports installment payments, etc., thereby effectively improving user convenience. For example, the payment system 1 can prevent settings for installment payments, etc. from being specified for payment of a price that does not support installment payments, etc.

[0216] [Variation 1-4] For example, in the first embodiment, a case where a user uses installment payment or the like to pay a price has been described, but the user may also use installment payment or the like in situations other than paying a price. Modification 1-4 takes as an example a case where a user uses installment payment or the like to charge electronic money. Installment payment or the like in charging does not involve charging in multiple installments. The charge itself is completed in one go. In other words, when a single charge is performed, the balance of electronic money increases only once.

[0217] The installment payments etc. in a charge described in Variation Example 1-4 are installment payments etc. in a payment made by the charge source that is the source of the charge. For example, suppose a user designates a credit card as the charge source and performs a charge of 10,000 yen in five installments. The balance of the electronic money increases by 10,000 yen immediately after the payment for the charge is made. The balance of the electronic money does not increase in five installments of 2,000 yen each. The deduction from the credit card used as the charge source is made in five installments. Similarly, if a revolving payment or bonus payment is designated for the charge, the balance of the electronic money increases immediately after the payment for the charge is made, and subsequent deductions are made in multiple installments or in a bonus month.

[0218] FIG. 21 is a diagram showing an example of a setting screen in Modification 1-4. In the example of FIG. 21, the charge screen SC6 that accepts the specification of charge conditions corresponds to the setting screen. The parts described as charge screen SC6 in Modification 1-4 can be read as setting screen. The display control unit 101 in Modification 1-4 displays the charge screen SC6 that accepts the specification of settings for charge using a payment method on the user terminal 30. The display control unit 101 generates display data for the charge screen SC6 and transmits the display data to the user terminal 30, thereby displaying the charge screen SC6 on the user terminal 30.

[0219] For example, as shown in the upper left of FIG. 21, the display control unit 101 causes the user terminal 30 to display a charge screen SC6 including an input form F60 for charge conditions and a panel P61 showing the payment method set as the charge source. Charge conditions are conditions for charging. For example, charge conditions may be the charge amount or the balance after charging. The payment method to be used as the charge source is also one type of charge condition. Conditions that can be specified as charge conditions may be similar to conditions used for known charges.

[0220] For example, panel P61 differs from panel P11 on code screen SC1 in that it indicates the charge source rather than the payment source, but the usage of panel P61 is generally the same as panel P11. When the user selects panel P61, the display control unit 101 may display a charge source selection screen SC7, which has a layout similar to the payment source selection screen SC2, on the user terminal 30, as shown in the upper right of Figure 21. The charge source selection screen SC7 displays a list of payment methods that can be specified as the charge source. The user may also specify settings such as installment payments from the charge source selection screen SC7. In this case, the charge source selection screen SC7 corresponds to the settings screen. The flow of specifying settings such as installment payments from the charge source selection screen SC7 may be the same as the flow shown for payment source selection screen SC2 in Figure 2. In addition, the charge source selection screen SC7 may be a screen that allows switching charge sources (charge methods) and setting their priority. For example, it may be another screen such as a home screen, a payment screen, or a payment method management screen. Although the charge source selection screen SC7 is shown as being separate from the charge screen SC6, it may be the same screen as the charge screen SC6.

[0221] For example, when a user selects a payment method from panel P70 as a potential source of payment, the user terminal 30 displays a modal M71 on the payment source selection screen SC7, as shown in the lower left of Figure 21, which accepts the specification of settings such as installment payments. The series of processes, including the display of modal M71, may be the same as the process for displaying modal M21 on the payment source selection screen SC2. For example, the series of processes, including the display of modal M71, may be executed by a script included in the display data of the payment source selection screen SC7. These series of processes may also be shown in the program code of the payment application.

[0222] For example, the display control unit 101 may generate display data including a script and transmit it to the user terminal 30, thereby displaying a modal M71 or the like on the user terminal 30. When the user specifies settings for installment payments or the like for recharging from the modal M71, the settings for installment payments or the like are reflected on the recharging source selection screen SC7, as shown in the lower right of FIG. 21. The payment server 10 acquires the settings for installment payments or the like from the user terminal 30 and stores the settings for installment payments or the like for recharging in the payment database DB1. The settings for installment payments or the like for payment of the price and the settings for installment payments or the like for recharging may be separate from each other or may be the same.

[0223] The process execution unit 102 in variant 1-4 executes a process such as installment payment for recharging based on the setting of installment payment or the like. As with payment of a price, the process execution unit 102 may execute a process of recharging with a lump-sum payment for the time being and then execute a process of changing the lump-sum payment to installment payment or the like, or may execute a settlement for recharging with installment payment or the like from the beginning without executing a lump-sum payment for the time being. For example, when executing a settlement for recharging, the process execution unit 102 requests the card server 20 to execute the settlement for recharging with installment payment or the like. Based on the request, the card server 20 executes the settlement for recharging with installment payment or the like. The process by which the card server 20 executes a settlement for installment payment or the like may be similar to the process of a known payment service.

[0224] For example, in the state shown in the lower right of Figure 21, if the user performs an operation to return to the charge screen SC6, the user terminal 30 will display the charge screen SC6 again on the display unit 35. The pull-down menu P610 on the charge screen SC6 contains settings such as installment payments specified by the user. In this state, if the user selects button B62 to support the execution of the charge, the charging process and the installment payment process will be executed based on the charging conditions and installment payment settings specified by the user. If a lump-sum payment is to be executed for the time being, the charging process may be the same as known processing. The processing execution unit 102 generates usage information that includes the charge amount, charge date and time, information on the charge source, and information indicating that it is subject to installment payments, and stores it in the payment database DB1.

[0225] The payment system 1 in Modification 1-4 displays a settings screen on the user terminal 30 that accepts the specification of settings such as installment payments when a payment method is used for charging. The payment system 1 executes the processing of installment payments, etc., for charging based on the settings for installment payments, etc. As a result, the user can use installment payments, etc., when charging from the payment app, and the payment system 1 can improve the convenience of the user when charging from the payment app.

[0226] [Variation 1-5] For example, as explained to some extent in Modification 1-4, the display control unit 101 may display a charge screen SC6, which accepts the specification of charge conditions related to charging, as a setting screen on the user terminal 30. For example, if the user selects pull-down P610, the user terminal 30 may display the number of divisions that the user can specify in pull-down P610. The number of divisions displayed in pull-down P610 may be the same as the number of divisions displayed in pull-down P110 of the code screen SC1 in the upper right of Figure 18.

[0227] For example, when the user selects the number of installments from the pull-down menu P610, the user terminal 30 may display the number of installments selected by the user on the pull-down menu P610. This series of steps may be similar to that of the code screen SC1 in FIG. 18. This series of processes may be executed by a script included in the display data of the charge screen SC6, or may be executed by the user terminal 30 communicating with the payment server 10 each time the user performs an operation on the charge screen SC6. This series of processes may be indicated in the program code of the payment app. Similarly, when a revolving payment or bonus payment is executed, the display control unit 101 may cause the user terminal 30 to display the charge screen SC6, which accepts designation of the revolving payment or bonus payment settings, as a setting screen.

[0228] The processing execution unit 102 of Modification 1-5 executes processing such as installment payments for charging based on the charging conditions and the settings of installment payments, etc. specified on the charging screen SC6. It differs from Modification 1-4 in that the settings of installment payments, etc. are made on the charging screen SC6, but the processing itself of installment payments, etc. for charging is the same as Modification 1-4.

[0229] The payment system 1 of variant 1-5 displays a charge screen SC6, which accepts the specification of charge conditions related to charge, as a settings screen on the user terminal 30. The payment system 1 executes the charge process based on the charge conditions and settings such as installment payments specified on the charge screen SC6. Since the user can specify settings such as installment payments directly from the charge screen SC6 for inputting charge conditions, the payment system 1 can improve user convenience.

[0230] [Variations 1-6] For example, as in Modification 1-5, if the charge screen SC6 corresponds to a settings screen, the display control unit 101 may display the charge screen SC6 on the user terminal 30, which accepts a third operation to start setting up installment payments, etc. The third operation is performed before specifying the details of the installment payment settings, etc. In other words, the third operation is an operation to display a user interface part that accepts the specification of the details of the installment payment settings, etc. The third operation is performed before the fourth operation described later. The third operation can also be said to be an operation to start setting up installment payments, etc. The charge screen SC6 includes a user interface part that accepts the third operation.

[0231] Figure 22 shows an example of the charge screen SC6 in Modification 1-6. The charge screen SC6 in the upper left of Figure 22 is the same as the charge screen SC6 in the upper left of Figure 21. In the example in the upper left of Figure 22, the pull-down P610 corresponds to a user interface part that accepts a third operation. The user performs the third operation by selecting from the pull-down P610. The third operation is not limited to selecting from the pull-down P610. The third operation may be any operation performed from the code screen SC1. For example, the third operation may be an operation to select another part such as a button or panel instead of the pull-down P610.

[0232] In Modification 1-6, the display control unit 101 displays a user interface on the user terminal 30, superimposed on the charge screen SC6, that accepts a fourth operation for specifying the details of the installment payment settings, etc., when the third operation is performed on the charge screen SC6. The fourth operation is performed after the third operation. For example, the fourth operation may be an operation to specify whether or not to use installment payments, etc. The fourth operation may be an operation to specify the number of installments in installment payments, the payment amount or number of installments in revolving payments, or the bonus month in bonus payments. The fourth operation can also be an operation to specify a numerical value indicating the settings for installment payments, etc. In Modification 1-6, the user performs at least two operations, including the third and fourth operations, to complete the settings for installment payments, etc.

[0233] Hereinafter, an example will be given in which the user specifies the installment payment setting. For example, the display control unit 101 includes a script instructing that a user interface for accepting a fourth operation be displayed when a third operation is performed in the display data of the charge screen SC6, thereby displaying the user interface on the user terminal 30. For example, when the user selects the pull-down menu P610 on the charge screen SC6 shown in the upper left of FIG. 22, the user terminal 30 executes the script included in the display data of the charge screen SC6, and displays a modal M63 including a panel P630 for accepting the specification of the number of installments, superimposed on the charge screen SC6, as shown in the upper right of FIG. 22.

[0234] In the example at the top right of FIG. 22, modal M63 corresponds to the user interface that accepts the fourth operation. This user interface may be a user interface other than modal M63. For example, this user interface may be another user interface such as a pop-up or a window. This user interface is displayed so as to be superimposed on all or part of the charge screen SC6. Note that in the example at the top right of FIG. 22, modal M63 is generally similar to modal M21 at the bottom left of FIG. 2, but may have a different layout from modal M21.

[0235] For example, the user performs the fourth operation by selecting panel P630 indicating the desired number of installments from modal M63. When the user selects panel P630, as shown in the lower left of FIG. 22, the user terminal 30 closes modal M63 and displays the number of installments indicated by panel P630 in pull-down menu P610. This series of processes may be executed by a script included in the display data of the charge screen SC6, or may be executed by the user terminal 30 communicating with the payment server 10 each time the user operates the charge screen SC6. This series of processes may be specified in the program code of the payment app.

[0236] For example, the user terminal 30 transmits to the payment server 10 the installment payment settings specified by the user from panel P630 of modal M63. The payment server 10 stores the installment payment settings received from the user terminal 30 in the payment database DB1 in association with the user's user ID. When the user cancels the installment payment settings from panel P630 of modal M63 (in the example in the upper right of FIG. 22, the user selects "None"), the user terminal 30 transmits to the payment server 10 a request indicating that the installment payment settings be canceled. Based on the request received from the user terminal 30, the payment server 10 cancels the installment payment settings associated with the user's user ID.

[0237] Note that when the user specifies the setting of revolving payment or bonus payment, the display of the charge screen SC6 may be controlled in the same manner as when the user specifies the setting of installment payment. For example, when the third operation is performed, the display control unit 101 may display a user interface that accepts a fourth operation for specifying details of the setting of revolving payment or bonus payment so as to be superimposed on the charge screen SC6. The display control unit 101 may control this series of processes by transmitting display data including a script that indicates this series of processes to the user terminal 30, or may control this series of processes by communicating with the user terminal 30 each time the user performs an operation on the charge screen SC6.

[0238] Also, although it differs from Modification Example 1-5 in that display control is performed in response to the third operation and the fourth operation, the processing for charging may be the same as that of Modification Example 1-5. The processing execution unit 102 of Modification Example 1-5 executes processing such as installment payments for charging based on the details of the settings for installment payments, etc. specified by the fourth operation. Although it differs from Modification Example 1-4 in that display control is performed in response to the third operation and the fourth operation, the processing after the execution of charging is instructed may be the same as that of Modification Example 1-4.

[0239] In the modified example 1-6, the payment system 1 displays a charge screen SC6 that accepts a third operation on the user terminal 30. When the third operation is performed on the charge screen SC6, the payment system 1 displays a user interface that accepts a fourth operation on the user terminal 30, superimposed on the charge screen SC6. The payment system 1 executes the charging process based on the details of the installment payment settings specified by the fourth operation. As a result, the user can specify the installment payment settings directly from the modal M63 that is superimposed on the charge screen SC6 displayed during charging, thus improving user convenience. The modal M63 is displayed superimposed on the charge screen SC6 and has sufficient space for the user to perform the fourth operation, making it easier for the user to specify the details of the installment payment settings.

[0240] [Variation 1-7] For example, as explained to some extent in the first embodiment and modifications 1-1 to 1-6, the display control unit 101 may display the details of settings such as installment payments on the settings screen in association with payment method information related to the payment method. The payment method information displayed on the settings screen may be the same as the payment method information stored in the payment database DB1, or it may be only a part of that information. If the code screen SC1 in the upper left of Figure 2 corresponds to the settings screen, the payment method information is credit card information. For example, the payment method information may be the credit card brand, card name, part of the credit card number, or other information. The payment method for which payment method information is displayed on the settings screen is the payer or charge source.

[0241] For example, in the case where the payment source selection screen SC2, the charge screen SC6, or the charge source selection screen SC7 corresponds to the setting screen, the display control unit 101 may similarly display the details of the settings for installment payments, etc., on the setting screen in association with payment method information for a payment method such as a credit card. Displaying the details of the settings for installment payments, etc., in association with the payment method information means displaying the payment method information and the details of the settings for installment payments, etc., on the same setting screen. The display control unit 101 generates display data for the setting screen showing the payment method information and the details of the settings for installment payments, etc., and transmits the data to the user terminal 30, thereby displaying the setting screen in which these are associated on the user terminal 30.

[0242] The payment system 1 of Variation 1-7 displays the details of the settings for installment payments, etc., in association with the payment method information related to the payment method on the settings screen. This allows the user to check both the payment method information and the details of the settings for installment payments, etc., on the settings screen, thereby improving user convenience.

[0243] [Variation 1-8] For example, the payment source selection screen SC2 described in the first embodiment and the charge source selection screen SC7 described in modification 1-4 are each an example of a payment method screen that accepts the designation of a payment method to be used on the user terminal 30. The payment source or charge source is an example of a payment method to be used. The display control unit 101 may display, as a setting screen, a payment method screen that accepts the designation of a payment method to be used on the user terminal 30 from among multiple payment methods available on the user terminal 30. The processing by the display control unit 101 to display the payment source selection screen SC2 or the charge source selection screen SC7 as a payment method screen is as described in the first embodiment or modification 1-4.

[0244] The payment method selection screen may be any screen other than the payment source selection screen SC2 and the charge source selection screen SC7. For example, the payment method selection screen may be a screen for specifying the payment method to be registered in the payment app. In this case, the display control unit 101 should display the screen for specifying the payment method to be registered in the payment app as a settings screen. The payment method selection screen may also be a screen for deleting a payment method registered in the payment app. In this case, the display control unit 101 should display the screen for deleting a payment method registered in the payment app as a settings screen.

[0245] In the modified example 1-8, the processing execution unit 102 executes installment payment processing based on the payment method and installment payment settings specified on the payment method screen. For example, the processing execution unit 102 executes installment payment processing for payment based on the payment source and installment payment settings selected on the payment source selection screen SC2, which is an example of a payment method screen. This processing is as described in the first embodiment. The processing execution unit 102 also executes installment payment processing for charging based on the charge source and installment payment settings selected on the charge source selection screen SC7, which is an example of a payment method screen. This processing is as described in the modified example 1-4.

[0246] In the modified version 1-8, the payment system 1 displays the payment method selection screen as a settings screen on the user terminal 30. The payment system 1 executes the installment payment process based on the payment method and installment payment settings specified on the payment method selection screen. As a result, the user can specify the installment payment settings on the payment method selection screen, thereby effectively enhancing user convenience.

[0247] [Variation 1-9] For example, if a payment app supports multiple payment methods, all of them may support installment payments, etc. from the payment app, or only some of them may support installment payments, etc. from the payment app. Variation 1-9 takes as an example a case where, of the multiple payment methods supported by the payment app, only a specific payment method supports installment payments, etc. from the payment app. In this case, a setting screen may be displayed depending on the result of determining whether or not the specific payment method will be used.

[0248] The payment system 1 of variants 1-9 includes a second support determination unit 108. The second support determination unit 108 determines whether the payment method supports installment payments, etc. on the user terminal 30. For example, the data storage unit 100 stores supported payment method data indicating payment methods that support installment payments, etc. The supported payment method data may be in any format. For example, the supported payment method data may be in table format, mathematical formula format, part of a program, a machine learning model, or other format. The supported payment method data may be determined by the administrator of the payment service or the administrator of the card service (card issuer).

[0249] For example, the second correspondence determination unit 108 determines whether the user's payment method supports installment payments, etc., based on the supported payment method data. If only credit cards issued by a specific card company support installment payments, etc., the supported payment method data indicates the credit cards of that card company. The second correspondence determination unit 108 identifies the card company of the user's credit card based on part of the credit card number (e.g., predetermined digits), etc., and determines whether the card company supports installment payments, etc. The second correspondence determination unit 108 determines whether the payment source or the charge source supports installment payments, etc. Note that this also includes cases where only a predetermined type of credit card issued by a specific card company supports installment payments, etc.

[0250] The display control unit 101 in Modification Example 1-9 displays a setting screen on the user terminal 30 based on the determination result of the second correspondence determination unit 108. For example, if it is determined that the user's payment method does not support installment payments or the like, the display control unit 101 does not display the setting screen on the user terminal 30, and if it is determined that the user's payment method supports installment payments or the like, the display control unit 101 displays the setting screen on the user terminal 30. If it is determined that the user's payment method does not support installment payments or the like, the display control unit 101 may display a setting screen on the user terminal 30 that does not accept designation of settings for installment payments or the like (for example, a setting screen in which user interface parts that accept designation of settings for installment payments or the like are grayed out, or a setting screen that does not include such parts), and if it is determined that the user's payment method supports installment payments or the like, the display control unit 101 may display a setting screen on the user terminal 30 that accepts designation of settings for installment payments or the like.

[0251] The payment system 1 of Variation 1-9 determines whether the payment method supports installment payments, etc. on the user terminal 30. Based on the result of the determination, the payment system 1 displays a setting screen on the user terminal 30. This allows the payment system 1 to display a setting screen corresponding to the result of the determination on the user terminal 30, thereby effectively improving user convenience. For example, the payment system 1 can prevent the setting screen from being displayed even if the payment method does not support installment payments, etc.

[0252] [Variation 1-10] For example, the payment server 10 may include a usage condition determination unit 109 having the same function as the usage condition determination unit 203 described in the second embodiment. The usage condition determination unit 109 determines whether or not usage conditions related to the use of installment payments or the like at the user terminal 30 are satisfied. The method for determining the usage conditions may be the same as in the second embodiment. In Modification 1-10, the data storage unit 100 stores usage condition data. The usage condition data may be the same as in the second embodiment. The usage condition data defines the specific contents of the usage conditions.

[0253] For example, the usage condition determination unit 109 determines whether the usage conditions are met based on usage information acquired before the setting of installment payments, etc., is specified. The payment server 10 includes the same functions as the usage information acquisition unit 202 described in the second embodiment. For example, in the type that reads the store code, information on the store to be paid for and the amount to be paid can be acquired before the setting of installment payments, etc., is specified. Information on the credit limit can also be acquired in advance. The usage condition determination unit 109 determines whether the usage conditions are met based on the usage condition data and the usage information subject to installment payments, etc. The method for determining the usage conditions may be the same as that of the usage condition determination unit 203 described in the second embodiment.

[0254] In the modified example 1-10, the display control unit 101 displays the settings screen on the user terminal 30 based on the determination result of the usage condition determination unit 109. For example, if the display control unit 101 determines that the usage conditions are not met, it does not display the settings screen on the user terminal 30, and if it determines that the usage conditions are met, it displays the settings screen on the user terminal 30. If the display control unit 101 determines that the usage conditions are not met, it may display a settings screen on the user terminal 30 that does not accept the specification of settings such as installment payments (for example, a settings screen in which the user interface part that accepts the specification of settings such as installment payments is grayed out, or a settings screen that does not include such part), and if it determines that the usage conditions are met, it may display a settings screen on the user terminal 30 that accepts the specification of settings such as installment payments.

[0255] The payment system 1 in the modified example 1-10 determines whether the usage conditions for installment payments, etc., on the user terminal 30 are met. Based on the result of this determination, the payment system 1 displays a settings screen on the user terminal 30. As a result, the payment system 1 can display a settings screen on the user terminal 30 that corresponds to the result of the determination, thereby effectively improving user convenience. For example, the payment system 1 can prevent the settings screen from being displayed even if the usage conditions are not met.

[0256] [Variation 1-11] For example, the display control unit 101 may display setting screens on the user terminal 30 that correspond to each of the multiple payment methods available on the user terminal 30. In Modification 1-11, two examples of payment methods are given: the method of reading the code C10 described in the first embodiment with the store terminal 40, and the method of reading the code displayed on the store terminal 40 with the user terminal 30, as described in Modification 1-3. The display control unit 101 can display the code screen SC1 and the confirmation screen SC5 as setting screens. These display methods are as described in the first embodiment and Modification 1-3. As mentioned above, the setting screens are not limited to the code screen SC1 and the confirmation screen SC5.

[0257] In the modified example 1-11, the display control unit 101 displays the setting screen corresponding to one of the multiple payment methods on the user terminal 30 so that the settings specified on the setting screen corresponding to one payment method are carried over to the setting screens corresponding to the other payment methods. For example, if the display control unit 101 displays the confirmation screen SC5 after the settings for installment payments etc. are specified on the code screen SC1, it displays the confirmation screen SC5 on the user terminal 30 which shows the same settings as the settings for installment payments etc. on the code screen SC1. If the display control unit 101 displays the code screen SC1 after the settings for installment payments etc. are specified on the confirmation screen SC5, it displays the code screen SC1 on the user terminal 30 which shows the same settings as the settings for installment payments etc. on the confirmation screen SC5.

[0258] The processing execution unit 102 in Modification 1-11 executes processing for each of the multiple payment methods based on the settings for installment payments, etc., specified on the setting screen corresponding to each of the multiple payment methods. This differs from the first embodiment in that the settings for installment payments, etc., are carried over between setting screens, but the processing for installment payments, etc., itself is the same as in the first embodiment.

[0259] In variation 1-11, the payment system 1 displays a setting screen corresponding to one of a plurality of payment methods on the user terminal 30 so that the settings specified on the setting screen corresponding to that payment method are carried over to the setting screen corresponding to the other payment method. The payment system 1 executes processing for that payment method based on the settings specified on the setting screen corresponding to each of the plurality of payment methods. This eliminates the need to redo settings for installment payments, etc., when the user changes the payment method, thereby enabling the payment system 1 to effectively improve user convenience.

[0260] [Variation 1-12] For example, if the amount of payment or charge that is subject to installment payments, etc., is known in advance, a simulation result according to the amount of use may be displayed. The payment system 1 of variant 1-12 includes a simulation execution unit 110. The simulation execution unit 110 executes a simulation related to installment payments, etc. The simulation calculates the amount of payment per installment (amount withdrawn), the fee, the period during which payments will occur, or the payment month.

[0261] The data storage unit 100 of Modification Example 1-12 stores a simulation program for simulating installment payments, etc. The simulation program defines a calculation formula for the fee for each setting of installment payments, etc., a calculation formula for the amount of payment per installment, or other calculation formulas. The simulation program may be similar to programs used in known card services, etc. For example, when a user uses installment payments, the simulation execution unit 110 calculates the fee required for installment payments and the amount of payment per installment based on the amount used, the number of installments, and the simulation program. Similarly, when a user uses revolving payments or bonus payments, the simulation execution unit 110 may execute a simulation based on the amount used, the settings specified by the user, and the simulation program.

[0262] FIG. 23 is a diagram showing an example of a confirmation screen SC5 of Modification Example 1-12. The display control unit 101 of Modification Example 1-12 displays a confirmation screen SC5, which is an example of a setting screen, on the user terminal 30 based on the results of the simulation. In the example of FIG. 23, when the user selects a pull-down menu P500 in the state of the confirmation screen SC5 on the right side of FIG. 20, the user terminal 30 displays a modal M52 on the confirmation screen SC5 that accepts designation of settings such as installment payments. The modal M52 may be the same as the modal M12.

[0263] For example, the simulation execution unit 110 calculates the payment amount for each installment payment for each installment payment based on the usage amount identified when the code displayed on the store terminal 40 is read and each of the multiple installment payment numbers. The display control unit 101 displays the payment amount for each installment payment in modal M52. The user checks the simulation results on panel P520 and selects the number of installments.

[0264] For example, the display control unit 101 may display the simulation results on a setting screen other than the confirmation screen SC5 (for example, the code screen SC1, the payment source selection screen SC2, the completion screen SC3, the charge screen SC6, or the charge source selection screen SC7). When the simulation results are displayed on the completion screen SC3, if the user performs an operation on the completion screen SC3 to request installment payment, the processing execution unit 102 may execute processing such as installment payment.

[0265] The payment system 1 of Variation 1-12 executes a simulation related to installment payments, etc. Based on the results of the simulation, the payment system 1 displays a settings screen on the user terminal 30. This allows the user to specify settings for installment payments, etc. while referring to the results of the simulation, so the payment system 1 can effectively improve user convenience.

[0266] [5-2. Modifications of the Second Embodiment] 24 is a diagram showing an example of functions realized in a modification of the second embodiment. For example, the payment server 10 includes a processing execution unit 102, a usage condition determination unit 109, a processing result notification unit 111, a usage information acquisition unit 112, a payment notification unit 113, a change inquiry unit 114, and a response execution unit 115. Each of the processing result notification unit 111, the usage information acquisition unit 112, the payment notification unit 113, the change inquiry unit 114, and the response execution unit 115 is realized by the control unit 11.

[0267] [Modification 2-1] For example, in the second embodiment, when a payment app is used with a credit card set as the payment source, a lump-sum payment is executed. In this case, the payment from the card service administrator to the store is made in one lump sum, not in installments. After the lump-sum payment is executed, the payment server 10 and the card server 20 cooperate with each other, and if the terms of use are met, a process is executed to change the lump-sum payment to installment payments, etc.

[0268] As explained somewhat in the second embodiment, if it is determined that the terms of use are not met, the processing execution unit 201 may change installment payments or the like to a lump-sum payment and process the payment. That is, if it is determined that the terms of use are not met, the processing execution unit 201 does not change the lump-sum payment for the time being and simply records the payment as a lump-sum payment. Even if the payment was made by the user setting up installment payments or the like, it is recorded as a lump-sum payment, so the card server 20 processes the withdrawal for the payment as a lump-sum payment. The process for withdrawing the lump-sum payment may be realized by the same process as known card services.

[0269] In the payment system 1 of variation 2-1, if it is determined that the terms of use are not met, the payment system 1 changes the installment payment to a lump-sum payment and processes the payment. This allows the payment system 1 to process the payment as a lump-sum payment even if the payment does not meet the terms of use and the payment setting is specified. This prevents the store from being unable to receive the payment.

[0270] [Variation 2-2] For example, when a user makes a payment specifying installment payments, they may want to know whether the payment was processed as installment payments because the conditions for use were met, or whether it was not processed as installment payments because the conditions for use were not met. Therefore, in Modification 2-2, we will take the example of a case where the processing result of the processing execution unit 201 is notified to the user.

[0271] The payment system 1 of modification 2-2 includes a processing result notification unit 111. The processing result notification unit 111 notifies the user of the payment application of the processing result of the processing execution unit 201. The processing result notification is a notification indicating the processing result of the processing execution unit 201. For example, the processing result notification may be a notification indicating whether the usage conditions have been met, or a notification indicating whether the user's payment has been processed as an installment payment, etc.

[0272] Figure 25 shows an example of a processing result notification. For example, the processing result notification unit 111 notifies the user of the processing result using the payment application's notification function. The processing result notification unit 111 displays a notification screen SC8 on the user terminal 30, which shows notifications from the payment application's notification function. Various notifications from the payment application are displayed on the notification screen SC8. In modification 2-2, the processing result notification unit 111 displays a notification screen SC8, which includes a processing result notification, on the user terminal 30 as one of the notifications from the payment application. In the example in Figure 25, the processing result notification includes a message indicating whether or not a payment for which the user specified installment payments, etc., was processed as installment payments, etc.

[0273] Similar to the second embodiment, when the card server 20 performs a determination of the usage conditions and processes according to the determination result, the settlement server 10 receives processing result data from the card server 20 indicating the processing result by the card server 20. The processing result data includes payment identification information (for example, an ID assigned to each payment) that identifies the payment processed by the processing execution unit 201, and processing information indicating whether the payment was processed as an installment payment or the like (i.e., information indicating whether the usage conditions were met).

[0274] For example, the processing result notification unit 111 provides a processing result notification based on the processing result data. The processing result notification unit 111 refers to the usage information stored in the settlement database and identifies the user who made the payment, as indicated by the payment identification information included in the processing result data. The processing result notification unit 111 refers to the processing information included in the processing result data and identifies the processing result of the processing execution unit 201 for that user. The processing result notification unit 111 provides the user with a processing result notification indicating the identified processing result. If the settlement server 10 determines the usage conditions, the processing result notification unit 111 can obtain the processing result of the processing execution unit 102 according to the usage condition determination result by the usage condition determination unit 109 (described later) and provide a processing result notification.

[0275] Furthermore, the processing result notification may be provided by means other than the payment app's notification function. For example, the processing result notification unit 111 may notify the user of the processing result via email, SMS message, messaging app message, SNS message, message in an app other than the payment app, push notification, pop-up notification, or banner notification. Even when the processing result notification unit 111 provides the processing result notification by means of other notification, the processing result notification unit 111 may identify which user's payment was processed and how, based on the processing result data, and provide the user with a processing result notification indicating the specific execution result.

[0276] In the modified version 2-2, the payment system 1 notifies the user of the payment application of the processing result of the processing execution unit 201. This allows the user to know how the payment they specified, such as installment payments, has been processed, thus effectively enhancing user convenience.

[0277] [Variation 2-3] For example, in the second embodiment, the payment is initially processed as a lump sum payment, and then, if the usage conditions are met, the initial lump sum payment is changed to installment payments, etc. Whether or not the usage conditions are met may be determined when payment is instructed. The determination of the usage conditions when payment is instructed may be performed by the card server 20, but in modification 2-3, the case in which the determination is performed by the settlement server 10 is given as an example.

[0278] The payment system 1 of Modification 2-3 includes a usage condition determination unit 109 and a usage information acquisition unit 112. The usage information acquisition unit 112 acquires usage information when payment is instructed. For example, the payment server 10 receives a payment request from the store terminal 40 in the same manner as in the second embodiment. The payment request includes at least a portion of the usage information (e.g., store ID and payment amount). When the payment server 10 receives a payment request, the usage information acquisition unit 112 of the payment server 10 acquires at least a portion of the usage information included in the payment request. The usage information acquisition unit 112 may acquire information from the payment database DB1 that is not included in the payment request.

[0279] For example, the usage conditions determination unit 109 determines whether the usage conditions are met when payment is instructed. The usage conditions determination unit 109 determines whether the usage conditions are met based on at least a portion of the usage information included in the payment request. In modification 2-3, the data storage unit 100 stores the usage conditions data described in the second embodiment. The usage conditions determination unit 109 implemented by the payment server 10 determines whether the usage conditions are met based on the usage conditions data stored in the data storage unit 100.

[0280] Taking the case where the same usage conditions 1 to 3 as in the second embodiment are determined as an example, the usage condition determination unit 109 determines whether or not usage condition 1 is met by determining whether or not it is a non-supported store based on the store ID included in the payment request. The usage condition determination unit 109 queries the card server 20 for information on the user's card's spending limit and determines whether or not it exceeds the spending limit based on the amount included in the payment request, thereby determining whether or not usage condition 2 is met. The usage condition determination unit 109 determines whether or not usage condition 3 is met by determining whether or not it is equal to or greater than a predetermined amount.

[0281] In the modified example 2-3, the processing execution unit 102 executes installment payment processing based on the determination result of the usage condition determination unit 109. For example, when payment is instructed, the processing execution unit 102 executes installment payment processing for payment based on the determination result of the usage condition determination unit 109. If the processing execution unit 102 determines that the usage conditions are not met, it does not execute installment payment processing. Alternatively, if the processing execution unit 102 determines that the usage conditions are not met, it may change the installment payment to a lump-sum payment and execute the settlement as usual.

[0282] For example, if the processing execution unit 102 determines that the usage conditions are met, it executes a payment in installments or the like. The processing execution unit 102 may process it as a lump-sum payment for the time being, as in the second embodiment, or it may execute a payment in installments or the like with the card server 20 at the time of processing the payment request. The method by which the processing execution unit 102 executes a payment in installments or the like with the card server 20 may be the same as the method used in known card services. For example, the processing execution unit 102 may process a payment in installments or the like at the time of execution by sending data for installments or the like (for example, data indicating that it is eligible for installments or the like and setting up installments or the like) to the card server 20 in the format defined by the card service API.

[0283] The payment system 1 of Variation 2-3 determines whether the terms of use are met when an instruction to pay the price is received. The payment system 1 executes the payment process based on the determination result of the terms of use determination unit 109 executed when an instruction to pay the price is received. This allows the payment system 1 to determine whether the terms of use are met at an earlier stage, thereby providing the user with more flexible payment services. For example, the payment system 1 can notify the user that an installment payment or the like has resulted in an error when the store terminal 40 reads the code C10.

[0284] [Variation 2-4] For example, in variant 2-3, when an instruction to pay the price is given, a notification indicating the processing result of the installment payment or the like may be given to the user. The payment system 1 of variant 2-4 includes a payment notification unit 113. When an instruction to pay the price is given and it is determined that the terms of use are not satisfied, the payment notification unit 113 gives a payment notification regarding the installment payment or the like in the payment of the price to the user of the payment app. The payment notification is a notification indicating the processing result of the installment payment or the like. The payment notification may be the same as the processing result notification described in variant 2-2.

[0285] FIG. 26 is a diagram showing an example of a payment notification. For example, when payment of the price is instructed and it is determined that the terms of use are not satisfied, the payment notification unit 113 displays a window W13 showing an error message on the code screen SC1. The payment notification unit 113 displays the window W13 on the code screen SC1 by transmitting display data for the window W13 to the user terminal 30. The user terminal 30 displays the window W13 on the code screen SC1 based on the display data. The user closes the window W13, changes the setting to lump-sum payment, and executes the payment again, or pays the price using a payment method other than the payment app.

[0286] In addition, in Modification 2-4, when payment of the price is instructed and it is determined that the terms of use are not satisfied, the installment payment or the like may be changed to a lump-sum payment and processed. In this case, the payment notifying unit 113 may issue a payment notice by displaying on the user terminal 30 a completion screen SC3 indicating that the installment payment or the like has been changed to a lump-sum payment and processed. The completion screen SC3 in this case is an example of a payment notice.

[0287] Furthermore, the payment notification may be sent by a notification means other than the display of window W13 on code screen SC1. For example, payment notification unit 113 may notify the user of the payment by a notification from the notification function of the payment app, an email, an SMS message, a message from a messaging app, a message on an SNS, a message from an app other than the payment app, a push notification, a pop-up notification, or a banner notification. Even when payment notification unit 113 sends the payment notification by another notification means, payment notification unit 113 may identify which user's payment was processed and how it was processed, depending on the determination result of the terms of use, and send the user a payment notification indicating the specified execution result.

[0288] In the payment system 1 of Variation 2-4, when payment of a price is instructed and it is determined that the terms of use are not satisfied, a payment notification regarding installment payments, etc., is sent to the user of the payment app. This allows the user to know how the payment for which the user specified the settings for installment payments, etc., was processed, and therefore the payment system 1 can effectively improve user convenience.

[0289] [Variation 2-5] For example, in modified examples 2-3 and 2-4, if payment is instructed but the usage conditions are not met, the user may be asked whether to change to a lump-sum payment. The user operates the user terminal 30 and inputs their answer to the inquiry. Depending on the user's answer, the payment may be changed from installment payments to a lump-sum payment and processed. For example, if the usage limit for installment payments is insufficient, the payment system 1 may, as part of the inquiry, suggest to the user, "Would you like to change to installment payments?"

[0290] The payment system 1 in modified example 2-5 includes a change inquiry unit 114 and a response execution unit 115. When payment is instructed and it is determined that the usage conditions are not met, the change inquiry unit 114 makes a change inquiry on the user terminal 30 regarding whether or not to change the payment method from installment payments, etc., to another payment method. The other payment method is a payment method that is changed to a lump-sum payment while keeping the current payer, or a payment method that is changed to a different payer.

[0291] Figure 27 shows an example of a change inquiry. For example, if payment is instructed and it is determined that the usage conditions are not met, the change inquiry unit 114 displays a window W14 on the code screen SC1 asking whether to change to another payment method. The change inquiry unit 114 displays window W14 on the code screen SC1 by sending display data for window W14 to the user terminal 30. Window W14 includes a button B140 indicating to change to another payment method and a button B141 indicating not to change to another payment method. In the example in Figure 27, the change inquiry unit 114 makes a change inquiry asking whether to change to a lump-sum payment as another payment method.

[0292] The change inquiry unit 114 may make the change inquiry on a screen other than the code screen SC1. For example, as in Modification 1-3, when the store code is read by the user terminal 30, the change inquiry unit 114 may make the change inquiry on the confirmation screen SC5. As another example, in the case of a payment type in which the user selects a store from a list of stores where the payment will be made, the change inquiry unit 114 may make the change inquiry on a screen that instructs that type of payment. The change inquiry unit 114 may make the change inquiry on another screen on the user terminal 30.

[0293] The response execution unit 115 executes processing according to the response to the change inquiry. The response to the change inquiry is a user operation in response to the change inquiry. The user responds to the change inquiry with either a first response indicating that they will change to another payment method, or a second response indicating that they will not change to another payment method. In the example of FIG. 27, the user responds with either the first response or the second response by selecting either button B140 or button B141. The response to the change inquiry may also be performed by operating a part of the user interface other than buttons B140 and B141.

[0294] For example, the user terminal 30 identifies the user's response to the change inquiry based on an operation on the operation unit 34, and transmits response data indicating the user's response to the payment server 10. The payment server 10 receives the response data from the user terminal 30. The response execution unit 115 executes processing according to the response to the change inquiry based on the response data. For example, if the response indicates changing to another payment method, the response execution unit 115 executes payment based on the other payment method. In the example of FIG. 27, when the user selects button B140, the response execution unit 115 changes installment payment, etc. to lump-sum payment and processes the payment as a lump-sum payment. The method of processing the lump-sum payment may be the same as when installment payment, etc. is not used. In other words, the method of processing the lump-sum payment may be the same as that of a known payment service.

[0295] For example, if the response indicates that the payment method should not be changed to another method, the response execution unit 115 does not execute the payment and returns an error. In this case, as in Modification 2-4, a window W13 displaying an error message may be displayed on the code screen SC1. The user can close the window W13, change the setting to lump-sum payment, and execute the payment again, or pay the price using a payment method other than the payment app.

[0296] In the payment system 1 of Variation 2-5, when payment of the price is instructed and it is determined that the terms of use are not satisfied, a change inquiry is made on the user terminal 30 as to whether or not to change the installment payment method for the payment of the price to another payment method. The payment system 1 executes processing according to the response to the change inquiry. This allows the user to change to another payment method in response to the change inquiry, so the payment system 1 executes flexible processing and can effectively improve user convenience.

[0297] [Variation 2-6] For example, as explained somewhat in the second embodiment, the usage conditions may be conditions regarding whether or not the store to be paid accepts installment payments, etc. In Modification 2-6, as in the second embodiment, an example is given in which a lump-sum payment is made initially when paying the price, and the card server 20 determines afterward whether or not the usage conditions are satisfied. Note that, in Modification 2-6 as well, the payment server 10 may determine whether or not the usage conditions are satisfied. That is, in Modification 2-6 as well, the payment server 10 may include the usage condition determination unit 109 and the usage information acquisition unit 112.

[0298] The usage information acquisition unit 202 in Modification 2-6 acquires store information about the store as usage information. The store information is as described in Modification 1-3. In Modification 2-6, the store ID of the store where the payment was made is included as store information in the usage information. The usage condition determination unit 203 determines whether the usage conditions are met by determining whether the store supports installment payments, etc., based on the store information. In Modification 2-6, as in the second embodiment, the data storage unit 200 stores a compatibility database. The usage condition determination unit 203 simply determines whether the store is a compatible store or a non-compatible store based on the compatibility database.

[0299] The payment system 1 of Variation 2-6 determines whether the terms of use are met by determining whether the store supports installment payments, etc., based on store information. This allows the payment system 1 to prevent installment payments, etc., from being used at a store that does not support installment payments, etc.

[0300] [Variation 2-7] For example, in the second embodiment, as in Modification 1-4, installment payments may be used for charging. Modification 2-7 takes as an example a case where the usage condition determination unit 109 and the usage information acquisition unit 112 are realized in the payment server 10. Furthermore, Modification 2-7 takes as an example a case where a charging screen SC6 similar to that in Modification 1-4 is displayed.

[0301] For example, the usage information acquisition unit 112 acquires usage information for charging using a payment method. The usage information for charging indicates the charging conditions specified by the user on the charging screen SC6. The usage information may include charging source information. In variant example 2-7, an example is given in which charging source information is stored in advance in the payment database DB1, but the charging source may also be specified on the charging screen SC6. In this case, the usage information acquisition unit 112 acquires charging source information indicating the charging source specified by the user on the charging screen SC6 from the user terminal 30. The usage information acquisition unit 112 acquires usage information by acquiring information such as the charging conditions specified by the user from the user terminal 30.

[0302] For example, the use condition determination unit 109 determines whether or not the use conditions for charging are met based on the usage information. In variant example 2-7, an example of a use condition is described in which the charging source is a credit card of a specific card company. Furthermore, it is assumed that the charging information is included in the usage information. For example, the use condition determination unit 109 determines whether or not the charging source indicated in the usage information is a credit card of a specific card company. If the use condition determination unit 109 determines that the charging source is not a credit card of a specific card company, it determines that the use conditions are not met. If the use condition determination unit 109 determines that the charging source is a credit card of a specific card company, it determines that the use conditions are met.

[0303] Note that the usage conditions of Modification 2-7 may also be any other conditions, as in the second embodiment. For example, the usage condition may be that the charge amount is equal to or greater than a predetermined amount. In this case, the usage information is assumed to include the charge amount. The usage condition determination unit 109 determines whether the charge amount indicated by the usage information is equal to or greater than a predetermined amount. If the usage condition determination unit 109 determines that the charge amount is less than the predetermined amount, it determines that the usage conditions are not met. If the usage condition determination unit 109 determines that the charge amount is equal to or greater than the predetermined amount, it determines that the usage conditions are met.

[0304] In the modified example 2-7, the processing execution unit 102 executes the charging process based on the determination result of the usage condition determination unit 109. If the processing execution unit 102 determines that the usage conditions are not met, it does not execute the installment payment or other processing for the charging. If the processing execution unit 102 determines that the usage conditions are met, it executes the installment payment or other processing for the charging. For example, the processing execution unit 102 executes the installment payment or other processing by performing the settlement for the charging in installments or other methods. The processing execution unit 102 may, similar to the payment of money, initially process the settlement at the time of charging as a lump sum payment and then execute processing to change it to installments or other methods afterward.

[0305] The payment system 1 in Modification 2-7 acquires usage information for the charge in which the payment method is used. Based on the usage information, the payment system 1 determines whether or not the usage conditions for the charge are met. Based on the result of this determination, the payment system 1 executes the processing for the charge. As a result, the payment system 1 can prevent unintended installment payments, etc., from being executed during the charge, thereby improving user convenience.

[0306] [Variation 2-8] For example, the usage conditions may be whether or not installment payments or other types of charges are permitted. In Modification 2-8, as in Modification 2-7, we will take the example of a case where the payment server 10 implements the usage condition determination unit 109 and the usage information acquisition unit 112. In Modification 2-8, we will take the example of a case where, in addition to the specific card company and charge amount explained in Modification 2-7, the usage conditions include whether or not installment payments or other types of charges are permitted, which are set for each user. For example, the operator of the payment service may specify for each user whether or not installment payments or other types of charges are permitted. In this case, the payment database DB1 is assumed to store permission information associated with the user ID, indicating whether or not installment payments or other types of charges are permitted.

[0307] The payment server 10's usage condition determination unit 109 determines whether the usage conditions are met by determining whether to allow installment payments, etc., in the charge when a charge using a payment method is instructed. For example, the usage condition determination unit 109 determines whether the usage conditions are met by determining whether the permission information stored in the payment database DB1 indicates permission. If the permission information does not indicate permission, the usage condition determination unit 109 determines that the usage conditions are not met, and if the permission information indicates permission, it determines that the usage conditions are met.

[0308] The payment system 1 in Modification 2-8 determines whether the usage conditions are met by deciding whether to allow installment payments, etc., in the charge when a charge using a payment method is instructed. As a result, the payment system 1 can determine whether the usage conditions are met in real time at the time of charge, thereby effectively improving user convenience.

[0309] [Variation 2-9] For example, as explained to some extent in Modification 2-7, the usage conditions may be that a specific payment method that supports installment payments, etc., is used. Modification 2-9 takes the case where the payment server 10 implements a usage condition determination unit 109 and a usage information acquisition unit 112. The data storage unit 100 is assumed to store data that can identify a payment method that supports installment payments, etc., as usage condition data. In Modification 2-9, it is assumed that the usage information indicates information that can identify the payment method used by the user. The processing for the usage information acquisition unit 112 to acquire the usage information may be the same as in the other modifications.

[0310] For example, the usage condition determination unit 109 determines whether the usage conditions are met by determining, based on the usage information, whether the payment method at the user terminal 30 supports installment payments, etc. For example, the usage condition determination unit 109 determines, based on the usage condition data, whether the payment method indicated by the usage information supports installment payments, etc. If the usage condition determination unit 109 determines that the payment method indicated by the usage information does not support installment payments, etc., it determines that the usage conditions are not met. If the usage condition determination unit 109 determines that the payment method indicated by the usage information supports installment payments, etc., it determines that the usage conditions are met.

[0311] In Modification 2-9, the processing execution unit 102 does not execute the installment payment process if it is determined that the payment method does not support installment payments. The processing execution unit 102 executes the installment payment process if it is determined that the payment method does support installment payments. As in the second embodiment, when installment payments are used for payment of the price, the processing execution unit 102 executes the installment payment process for payment of the price if it is determined that the payment method does support installment payments. As in Modification 2-7, when installment payments are used for charging, the processing execution unit 102 executes the installment payment process for charging if it is determined that the payment method does support installment payments.

[0312] The payment system 1 in modified example 2-9 determines whether the usage conditions are met by determining, based on usage information, whether the payment method on the user terminal 30 supports installment payments, etc. This allows the payment system 1 to prevent installment payments, etc., from being executed using an unintended payment method, thereby improving user convenience.

[0313] [Variation 2-10] For example, although described as usage condition 3 in the second embodiment, the usage condition determination unit 203 may determine whether the usage condition is satisfied by determining whether the usage amount at the user terminal 30 is equal to or greater than a predetermined amount based on the usage information. This is as described in the second embodiment. The usage condition may be specified by the user. This is not limited to Modification 2-10, but also applies to the second embodiment and other modifications. The same applies when the first, third, or fourth embodiment is combined with the second embodiment.

[0314] The payment system 1 of Variation 2-10 determines whether the usage conditions are met by determining whether the usage amount at the user terminal 30 is equal to or greater than a predetermined amount based on the usage information. This allows the payment system 1 to prevent installment payments, etc. from being made for low-value payments that cannot be made in installments, etc.

[0315] [Variation 2-11] For example, in Modification 2-10, a user may use points or the like to make payments or charge. Therefore, when a payment method other than the payment method is used for payment, the usage condition determination unit 203 may determine whether the value obtained by subtracting the amount appropriated by the other payment method from the usage amount is equal to or greater than a predetermined amount. In Modification 2-11, when a user uses a credit card as the charge source to charge 10,000 yen, 2,000 yen is appropriated as points. In this case, the usage condition determination unit 203 may determine the usage conditions based on 8,000 yen, which is the charge amount of 10,000 yen minus the appropriated amount of 2,000 yen. The payment server 10 may obtain information on the appropriated amount from the user terminal 30.

[0316] In the case where a payment method other than the current payment method is used for appropriation, the payment system 1 of Variation 2-11 determines whether the value obtained by subtracting the amount appropriated by the other payment method from the amount used is equal to or greater than a predetermined amount. This allows the payment system 1 to appropriately determine the terms of use for installment payments, etc., even when points, etc., are used for appropriation.

[0317] [Variation 2-12] For example, as explained as usage condition 2 in the second embodiment, the usage condition determination unit 203 may determine whether the usage condition is met by determining, based on the usage information, whether the usage is within the usage limit for installment payments, etc. This point is as explained in the second embodiment.

[0318] The payment system 1 in Modification 2-12 determines whether the usage conditions are met by determining, based on usage information, whether the usage falls within the usage limit for installment payments, etc. This allows the payment system 1 to prevent installment payments, etc., from being executed beyond the user's usage limit.

[0319] [Variation 2-13] For example, the payment server 10 may determine some of the usage conditions, and the card server 20 may determine the remaining usage conditions. The usage condition determination unit 109 in Modification 2-13 determines, based on usage information, whether at least some of the usage conditions are met when a payment is executed using the user terminal 30. For example, the usage condition determination unit 109 of the payment server 10 may determine, at the time of payment, whether the payer is a specific payment method. The usage condition determination unit 203 of the card server 20 may determine, after the payment has been executed, whether the remaining usage conditions are met. The usage conditions determined by the payment server 10 and the card server 20 may be any usage conditions exemplified in the second embodiment and in Modifications 2-1 to 2-12, respectively.

[0320] In the modified version 2-13, when a payment is made using the user terminal 30, the payment system 1 determines, based on usage information, whether at least some of the usage conditions are met. This allows the payment system 1 to execute processing according to the result of the usage condition determination when the payment is made. For example, if the payment system 1 notifies the user of the result of the usage condition determination when the payment is made, the user can be informed in real time whether installment payments, etc., are possible.

[0321] [5-3. Modifications of the Third Embodiment] Figure 28 shows an example of a function realized in a modified version of the third embodiment. For example, the payment server 10 includes a setting cancellation notification unit 116. The setting cancellation notification unit 116 is realized by the control unit 11.

[0322] [Variation 3-1] For example, the conditions for canceling installment payments, etc., are not limited to the example of the third embodiment. Modification 3-1 gives an example where the condition for cancellation is that the store is a non-supporting store that does not support installment payments, etc. The meaning of a non-supporting store is as explained in the second embodiment and modification 1-3. In modification 3-1, it is assumed that the store database explained in modification 1-3 is stored in the data storage unit 100. For example, the store database stores the store ID of each store and support store information indicating whether the store is a supporting store or a non-supporting store.

[0323] In Modification 3-1, the setting cancellation unit 105 determines whether the cancellation conditions are met by determining whether the store is a non-supporting store that does not support installment payments, etc. If it is determined that the store is a non-supporting store, the setting for installment payments, etc. is canceled. In Modification 3-1, as in the third embodiment, an example is given in which payment is executed when the code C10 displayed on the user terminal 30 is read by the store terminal 40. For example, the payment request includes the store ID and the code ID.

[0324] For example, the setting cancellation unit 105 retrieves the settings for installment payments, etc., associated with the code ID from the payment database DB1. If the retrieved settings for installment payments, etc., indicate that installment payments will not be made, or if the settings for installment payments, etc., do not exist in the payment database DB1 in the first place, the setting cancellation unit 105 does not perform the process of determining whether or not to cancel the settings for installment payments, etc. In this case, the payment will be made in a lump sum as before.

[0325] For example, the setting cancellation unit 105 performs a process to determine whether or not to cancel the installment payment setting if the acquired setting indicates that an installment payment will be made. The setting cancellation unit 105 refers to the corresponding store information stored in the store database and obtains the corresponding store information associated with the store ID included in the payment request received from the store terminal 40. If the corresponding store information indicates a corresponding store, the setting cancellation unit 105 does not cancel the installment payment setting. That is, if the corresponding store information does not indicate a non-corresponding store, the setting cancellation unit 105 does not cancel the installment payment setting. The installment payment setting that is not canceled may be used as is for subsequent payments or charges.

[0326] For example, the setting cancellation unit 105 cancels the setting for installment payments, etc., if the supported store information indicates a non-supported store. That is, the setting cancellation unit 105 cancels the setting for installment payments, etc., if the supported store information does not indicate a supported store. The setting cancellation unit 105 cancels the setting for installment payments, etc., by deleting the setting for installment payments, etc., stored in the payment database DB1, or by changing the value of the setting for installment payments, etc., to indicate that installment payments will not be made. When the setting for installment payments, etc., is canceled by the setting cancellation unit 105, the processing execution unit 102 may process the payment as a lump sum payment, or it may return an error to the user terminal 30 and the store terminal 40 without making the payment.

[0327] The payment system 1 in modification 3-1 determines whether the store is a non-supporting store that does not support installment payments, etc., and determines whether the conditions for cancellation are met. If it is determined that the store is a non-supporting store, the setting is canceled. This allows the payment system 1 to prevent installment payments, etc., from being made when payment for non-supporting transactions is to be executed.

[0328] [Modification 3-2] For example, in the third embodiment, the setting cancellation unit 105 determines whether the cancellation conditions are met after an instruction to pay the price is given. The setting cancellation unit 105 may be able to acquire information necessary for determining whether the cancellation conditions are met before an instruction to pay the price is given. In this case, the setting cancellation unit 105 may determine whether the cancellation conditions are met and cancel the setting of installment payments, etc., before an instruction to pay the price is given. In Variation 3-2, as in Variation 1-3, an example is given of payment when the user terminal 30 reads a code displayed on the store terminal 40.

[0329] FIG. 29 is a diagram showing an example of a screen displayed on the user terminal 30 in Modification 3-2. For example, when the user terminal 30 reads the code displayed on the store terminal 40, as described in Modification 1-3, the user terminal 30 transmits information included in the code (for example, the store ID and the payment amount) to the payment server 10. The payment server 10 receives the information included in the code from the user terminal 30. The setting cancellation unit 105 determines whether the cancellation condition is met based on the information included in the code.

[0330] For example, in the case of the cancellation condition of Modification Example 3-1, the setting cancellation unit 105 acquires, from the store database, compatible store information associated with the store ID indicated by the information included in the code, and determines whether the store to be paid is a compatible store. If the cancellation condition corresponds to the payment amount being less than a predetermined amount, the setting cancellation unit 105 may determine whether the cancellation condition is satisfied by determining whether the payment amount is less than the predetermined amount based on the payment amount information received from the user terminal 30.

[0331] For example, if it is determined that the cancellation conditions are met, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 in which the installment payment settings, etc. specified on the code screen SC1 have been cancelled (for example, a confirmation screen SC5 including a panel P50 indicating that the three-month payment setting has been cancelled and is now a lump-sum payment), as shown on the left side of FIG. 29. If it is determined that the cancellation conditions are not met, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 in which the installment payment settings, etc. specified on the code screen SC1 have not been cancelled, as shown on the right side of FIG. 29. The processing after the confirmation screen SC5 is displayed may be the same as in variant 1-3.

[0332] In Modification 3-2, similarly to Modification 1-3, the payment server 10 may receive current location information from the user terminal 30, and the setting cancellation unit 105 may determine whether or not the cancellation condition is satisfied based on the current location information. For example, the setting cancellation unit 105 may identify a store located near the current location indicated by the current location information, and determine whether or not the cancellation condition is satisfied based on the corresponding store information of the store.

[0333] For example, in Modification 3-2, as in Modification 1-3, a payment may be performed in which the user selects a store to be paid for from a list of stores displayed on the user terminal 30. In this case, the payment server 10 acquires store information indicating the store selected by the user from the user terminal 30. The setting cancellation unit 105 may determine whether the cancellation condition is met based on the compatible store information of the store indicated in the store information. When the user inputs the payment amount into the payment app, the payment server 10 may acquire the payment amount input by the user from the user terminal 30. The setting cancellation unit 105 may determine whether the cancellation condition is met based on the payment amount acquired from the user terminal 30.

[0334] In the modified version 3-2, payment system 1 cancels the installment payment setting based on the cancellation conditions before payment is instructed. This prevents payment system 1 from executing installment payments even when they are not available.

[0335] [Variation 3-3] For example, in the third embodiment, a case was described in which a user uses installment payments for payment of goods, but a user may also use installment payments in situations other than payment of goods. Modification 3-3 takes the case in which a user uses installment payments for charging as an example. The meaning of installment payments for charging is as explained in Modifications 1-4 and 2-7. In Modification 3-3, the setting acquisition unit 104 acquires the setting for installment payments for charging, in which the payment method is used. In Modification 3-3, as in Modifications 1-4, the setting for installment payments for charging is stored in the payment database DB1. The setting acquisition unit 104 acquires the setting for installment payments for charging from the payment database DB1.

[0336] The process execution unit 102 of Modification Example 3-3 executes the process of the installment payment for the charge, etc. based on the setting of the installment payment for the charge, etc. The process of the installment payment for the charge, etc. may be the same as that of Modification Examples 1-4 and 2-7.

[0337] In Modification 3-3, the setting cancellation unit 105 cancels the setting for installment payments, etc., in the charge based on the cancellation conditions. If the cancellation condition is that the charge amount is less than a predetermined amount, the setting cancellation unit 105 determines whether the cancellation condition is met by determining whether the charge amount is less than a predetermined amount based on the charge conditions specified by the user before the charge is executed. If the cancellation condition is that the charge source is a payment method that does not support installment payments, etc., the setting cancellation unit 105 may determine whether the cancellation condition is met by determining whether the charge source is a supported payment method based on the charge source information.

[0338] For example, if the cancellation condition is not satisfied, the setting cancellation unit 105 does not cancel the setting of installment payments, etc. for charging, and if the cancellation condition is satisfied, the setting cancellation unit 105 cancels the setting of installment payments, etc. for charging. The setting cancellation unit 105 cancels the setting of installment payments, etc. for charging by deleting the setting of installment payments, etc. for charging stored in the payment database DB1, or by changing the setting value to indicate that installment payments, etc. for charging will not be made.

[0339] The payment system 1 of variant example 3-3 acquires settings for installment payments, etc. for charging. The payment system 1 executes processing for installment payments, etc. for charging based on the settings for installment payments, etc. for charging. The payment system 1 cancels the settings for installment payments, etc. for charging based on the cancellation conditions. This eliminates the need for the user to manually cancel the settings for installment payments, etc. for charging, thereby improving the convenience of the user when charging.

[0340] [Modified example 3-4] For example, in Modification 3-3, the cancellation condition may be that a charge is executed. The setting cancellation unit 105 determines whether the cancellation condition is met by determining whether a charge has been executed, and may cancel the setting of installment payments, etc., when it is determined that a charge has been executed. The execution of a charge may be determined by a known method. For example, the setting cancellation unit 105 may determine that a charge has been executed when the balance of electronic money has increased, or may determine that a charge has been executed based on the execution result of a program that shows a series of processes for charging. The cancellation condition may be the charge amount. For example, when a charge of a certain amount or more is executed, the setting of installment payments, etc. may be canceled.

[0341] In the modified example 3-4, the setting cancellation unit 105 may determine whether or not a charge has been performed based on the processing result of the processing execution unit 102. The setting cancellation unit 105 does not determine that a charge has been performed if the processing execution unit 102 has not performed the charge processing, and determines that a charge has been performed if the processing execution unit 102 has performed the charge processing. If the setting cancellation unit 105 does not determine that a charge has been performed, it does not cancel the installment payment or other settings. The installment payment or other settings that were not canceled may be used for subsequent charges.

[0342] The payment system 1 in modified version 3-4 determines whether the cancellation conditions have been met by checking whether a charge has been executed, and cancels the setting if it is determined that a charge has been executed. This allows the payment system 1 to cancel installment payments, etc., each time a charge is executed. For example, if there are few users who wish to use installment payments, etc., consecutively, the payment system 1 can improve user convenience.

[0343] [Modified example 3-5] For example, the release conditions are not limited to the examples of the third embodiment and modifications 3-1 to 3-4. For example, the release condition may be a change in the payment method used by the user terminal 30. The setting release unit 105 determines whether the release condition has been met by determining whether the payment method has been changed, and if it is determined that the payment method has been changed, it releases the setting for installment payments, etc. The payment method is the payment source or the charge source.

[0344] For example, if the payment source corresponds to the payment method to be used, the user changes the payment source on the payment source selection screen SC2. The user terminal 30 transmits payment source information of the payment source selected by the user to the payment server 10. When the payment server 10 receives the payment source information from the user terminal 30, it updates the payment source information stored in the payment database DB1. The setting cancellation unit 105 determines that the payment source has been changed when the payment source information has been updated. If the setting cancellation unit 105 does not determine that the payment source has been changed, it does not cancel the setting of installment payments, etc., and if it determines that the payment source has been changed, it cancels the setting of installment payments, etc.

[0345] For example, if the charge source corresponds to the payment method to be used, the user changes the payment source from the charge source selection screen SC7. The user terminal 30 transmits charge source information of the charge source selected by the user to the payment server 10. When the payment server 10 receives the charge source information from the user terminal 30, it updates the charge source information stored in the payment database DB1. The setting cancellation unit 105 determines that the charge source has been changed when the charge source information has been updated. If the setting cancellation unit 105 does not determine that the charge source has been changed, it does not cancel the setting of installment payment, etc., and if it determines that the charge source has been changed, it cancels the setting of installment payment, etc.

[0346] The payment system 1 of Variation 3-5 determines whether the cancellation condition is met by determining whether the payment method used has been changed, and cancels the settings for installment payments, etc., if it is determined that the payment method used has been changed. This allows the payment system 1 to prevent the settings for installment payments, etc. from being carried over when the payment method used is changed. For example, a user may have desired installment payments, etc., with the payment method used before the change, but may no longer desire installment payments, etc., with the payment method used after the change. In such a case, the payment system 1 can prevent the user from forgetting to cancel the settings for installment payments, etc., and the installment payments, etc., being executed with the payment method used after the change.

[0347] [Variation 3-6] For example, installment payments and the like may only be supported by specific payment methods. Hereinafter, payment methods that support installment payments and the like are referred to as supported payment methods. Payment methods that do not support installment payments and the like are referred to as unsupported payment methods. The setting cancellation unit 105 may determine whether the payment method being used has been changed from a supported payment method that supports installment payments and the like to an unsupported payment method that does not support installment payments and the like, and may cancel the setting if it is determined that the payment method being used has been changed from a supported payment method to an unsupported payment method.

[0348] In Variation 3-6, the data storage unit 100 stores payment method data in which at least one of supported and unsupported payment methods is defined. The payment method data may define only supported payment methods, only unsupported payment methods, or both supported and unsupported payment methods. Variation 3-6 takes as an example a case in which only credit cards from a specific card company, "AAA Card," are supported payment methods.

[0349] For example, when the payment method used is changed, the setting cancellation unit 105 determines, based on the payment method data, whether the payment method used has changed from a supported payment method to an unsupported payment method. If the setting cancellation unit 105 does not determine that the payment method used has changed from a supported payment method to an unsupported payment method, it does not determine that the cancellation condition is met. However, if the setting cancellation unit 105 determines that the payment method used has changed from a supported payment method to an unsupported payment method, it determines that the cancellation condition is met. For example, the setting cancellation unit 105 determines that the cancellation condition is met when the payment method used is changed from the credit card "AAA Card" to another payment method. If a user has two credit cards "AAA Card" registered in the payment app and the payment method used is changed from the first credit card "AAA Card" to the second credit card "AAA Card," the setting cancellation unit 105 determines that the cancellation condition is not met.

[0350] For example, when the payment source is changed, the setting cancellation unit 105 determines whether the payment source has changed from a supported payment method to an unsupported payment method based on the payment method data. If the setting cancellation unit 105 does not determine that the payment source has changed from a supported payment method to an unsupported payment method, it does not determine that the cancellation condition has been met, but if it determines that the payment source has changed from a supported payment method to an unsupported payment method, it determines that the cancellation condition has been met. For example, the setting cancellation unit 105 determines that the cancellation condition has been met when the payment source has changed from the credit card "AAA Card" to another payment method.

[0351] For example, when the charge source is changed, the setting cancellation unit 105 determines whether the charge source has changed from a supported payment method to an unsupported payment method based on the payment method data. If the setting cancellation unit 105 does not determine that the charge source has changed from a supported payment method to an unsupported payment method, it does not determine that the cancellation condition has been met, but if it determines that the charge source has changed from a supported payment method to an unsupported payment method, it determines that the cancellation condition has been met. For example, the setting cancellation unit 105 determines that the cancellation condition has been met when the charge source has changed from the credit card "AAA Card" to another payment method.

[0352] The payment system 1 of variant example 3-6 determines whether the payment means used has been changed from a supported payment means to an unsupported payment means, and if it is determined that the payment means used has been changed from a supported payment means to an unsupported payment means, cancels the setting of installment payments, etc. This eliminates the need for the user to manually cancel the setting of installment payments, etc. when the payment means used has been changed from a supported payment means to an unsupported payment means, thereby reducing the operational burden on the user and effectively improving user convenience.

[0353] [Variation 3-7] For example, in variant example 3-6, if the setting cancellation unit 105 determines that the payment method used has been changed from one of multiple supported payment methods to another supported payment method, it may not cancel the setting for installment payments, etc., but if it determines that the payment method used has been changed from one of multiple supported payment methods to an unsupported payment method, it may cancel the setting for installment payments, etc.

[0354] For example, suppose a user has registered two credit cards, "AAA Cards," in a payment app. If the payment method used is changed from the first credit card, "AAA Card," to the second credit card, "AAA Card," the setting cancellation unit 105 determines that the cancellation condition is not met. If the payment method used is changed from one of the two credit cards, "AAA Cards," to an incompatible payment method, such as a card from another company, the setting cancellation unit 105 determines that the cancellation condition is met.

[0355] For example, if the payment method used is the payment source, the setting cancellation unit 105 determines that the cancellation condition is not satisfied when the payment source is changed from the first credit card "AAA card" to the second credit card "AAA card." The setting cancellation unit 105 determines that the cancellation condition is satisfied when the payment source is changed from either of the two credit cards "AAA card" to an incompatible payment method such as a card of another company.

[0356] For example, if the payment method used is the charge source, the setting cancellation unit 105 determines that the cancellation condition is not satisfied if the charge source is changed from the first credit card "AAA card" to the second credit card "AAA card." The setting cancellation unit 105 determines that the cancellation condition is satisfied if the charge source is changed from one of the two credit cards "AAA card" to an incompatible payment method such as a card of another company.

[0357] In the payment system 1 of Variation 3-7, if it is determined that the payment means used has been changed from one of a plurality of supported payment means to another supported payment means, the payment system 1 does not cancel the setting of installment payments, etc., but if it is determined that the payment means used has been changed from one of a plurality of supported payment means to a non-supported payment means, the payment system 1 cancels the setting of installment payments, etc. This eliminates the need for the user to re-specify the setting of installment payments, etc. when the user changes the payment means used from a supported payment means to another supported payment means, thereby reducing the operational burden on the user and effectively improving user convenience.

[0358] [Variation 3-8] For example, in Modification Example 3-7, the setting cancellation unit 105 may cancel the setting of installment payments, etc., when the payment method used is changed from one of multiple supported payment methods to an incompatible payment method, and may then reapply the setting of installment payments, etc., when it is determined that the payment method used has been changed from an incompatible payment method to one of multiple supported payment methods. In Modification Example 3-7, the setting of installment payments, etc., before cancellation is assumed to be stored in the payment database DB1. In this case, the setting cancellation unit 105 may reactivate the setting of installment payments, etc., by changing the value of a flag indicating whether the setting of installment payments, etc., is valid. The flag may be stored in the payment database DB1. The setting of installment payments, etc., before cancellation may be stored in a location other than the payment database DB1.

[0359] For example, suppose a user has registered two credit cards, "AAA Cards," in the payment app. If the payment method used is changed from the first credit card, "AAA Card," to an unsupported payment method, the setting cancellation unit 105 cancels the installment payment settings. The installment payment settings, etc., before the cancellation are stored in any location, such as the payment database DB1. If the payment method used is then changed from the unsupported payment method to the second credit card, "AAA Card," the setting cancellation unit 105 reapplies the stored installment payment settings, etc., before the cancellation. In other words, the setting cancellation unit 105 stores the installment payment settings, etc., before the cancellation in the payment database DB1.

[0360] For example, if the payment method used is the payment source, the setting cancellation unit 105 will cancel the installment payment setting if the payment source changes from the first credit card "AAA Card" to an unsupported payment method. The installment payment setting before cancellation is stored in an arbitrary location such as the payment database DB1. Subsequently, if the payment source changes from the unsupported payment method to the second credit card "AAA Card", the setting cancellation unit 105 will reapply the stored installment payment setting before cancellation. That is, the setting cancellation unit 105 stores the installment payment setting before cancellation in the payment database DB1.

[0361] For example, if the payment method used is the charge source, the setting cancellation unit 105 will cancel the installment payment setting if the charge source is changed from the first credit card "AAA Card" to an unsupported payment method. The installment payment setting before cancellation is stored in an arbitrary location such as the payment database DB1. Subsequently, if the charge source is changed from an unsupported payment method to the second credit card "AAA Card", the setting cancellation unit 105 will reapply the stored installment payment setting before cancellation. That is, the setting cancellation unit 105 stores the installment payment setting before cancellation in the payment database DB1.

[0362] In the modified version 3-8, payment system 1 cancels the installment payment setting when the payment method used is changed from one of the supported payment methods to an unsupported payment method. Subsequently, if it is determined that the payment method used has been changed from an unsupported payment method to one of the supported payment methods, the installment payment setting is reapplied. As a result, the user does not need to perform an operation to revert the installment payment setting, so payment system 1 can reduce the user's operational burden and effectively improve user convenience.

[0363] [Modification 3-9] For example, the setting cancellation unit 105 may determine whether the cancellation condition is met by determining whether an app (payment app or other app) or browser stored in the user terminal 30 has been terminated, and may cancel the setting of installment payments, etc., when it is determined that the app or browser has been terminated on the user terminal 30. In Variation 3-9, when the user performs an operation to terminate the payment app, the user terminal 30 sends a termination notice indicating the termination of the payment app to the payment server 10. The termination notice is data in a predetermined format indicating the termination of the payment app. Note that operations to terminate the payment app include operations such as deleting, updating, restarting, or logging out of the payment app.

[0364] In Variation 3-9, an example is given in which the termination of the payment app corresponds to the cancellation condition. For example, the setting cancellation unit 105 determines whether the payment app has been terminated by determining whether a termination notification has been received from the user terminal 30. If the setting cancellation unit 105 determines that a termination notification has not been received from the user terminal 30, it does not determine that the payment app has been terminated and does not cancel the settings for installment payments, etc. If the setting cancellation unit 105 determines that a termination notification has been received from the user terminal 30, it determines that the payment app has been terminated and cancels the settings for installment payments, etc.

[0365] Note that the user terminal 30 does not need to send a termination notice when the payment app is terminated. In this case, the setting cancellation unit 105 may determine whether the payment app has been terminated by determining whether a state in which no information has been received from the payment app has continued for a predetermined time (e.g., 10 minutes) or more. When the payment server 10 receives any information from the payment app, it stores the current date and time in the data storage unit 100 as the date and time of the last communication with the payment app. The setting cancellation unit 105 may make the above determination based on the stored date and time.

[0366] For example, if it is determined that a state in which no information is received from the payment app has not continued for a predetermined time or longer, the setting cancellation unit 105 does not determine that the payment app has been terminated and does not cancel the setting of installment payments, etc. If it is determined that a state in which no information is received from the payment app has continued for a predetermined time or longer, the setting cancellation unit 105 determines that the payment app has been terminated and cancels the setting of installment payments, etc. Even when an app or browser other than the payment app is used, the setting cancellation unit 105 may determine the termination of the other app or browser in the same manner as the payment app.

[0367] The payment system 1 of Variation 3-9 determines whether a cancellation condition is met by determining whether an app, such as a payment app, or a browser has been terminated, and cancels the settings for installment payments, etc., when it is determined that the payment app has been terminated on the user terminal 30. This eliminates the need for the user to go through the trouble of canceling the settings for installment payments, etc., in preparation for the next time the payment app is launched, and the payment system 1 can effectively improve user convenience. For example, the payment system 1 can prevent unintended installment payments, etc., from being made if the settings for installment payments, etc., remain the same the next time the user launches the payment app.

[0368] [Modification 3-10] For example, the setting acquisition unit 104 may acquire a first setting regarding whether or not installment payments or the like are to be used, and a second setting regarding whether or not the first setting needs to be canceled. That is, whether or not processing by the setting cancellation unit 105 is required may be specified as one of the settings for installment payments or the like. The payment database DB1 of Modification 3-10 stores the first setting and the second setting as settings for installment payments or the like. The method for setting the first setting may be the same as in the third embodiment. The second setting may be specified by the user, or may be specified in advance on the payment system 1 side.

[0369] In the modified example 3-10, the processing execution unit 102 executes the installment payment process based on the first setting. The first setting is the same as the setting for installment payments in the third embodiment. For example, if the first setting does not indicate the use of installment payments, the processing execution unit 102 does not execute the installment payment process, but if the first setting indicates the use of installment payments, it executes the installment payment process.

[0370] In the modified example 3-10, the setting release unit 105 releases the first setting based on the second setting and the release condition. For example, if the second setting indicates that the first setting should be released, the setting release unit 105 releases the first setting based on the release condition. The process of releasing the first setting based on the release condition may be the same as in the third embodiment and any of the modified examples 3-1 to 3-9. If the second setting indicates that the first setting should be released, the setting release unit 105 does not perform a determination of the release condition, etc., and does not release the first setting.

[0371] The payment system 1 in modified example 3-10 acquires a first setting regarding whether or not installment payments are used, and a second setting regarding whether or not the first setting needs to be canceled. Based on the first setting, the payment system 1 executes the installment payment process. Based on the second setting and the cancellation conditions, the payment system 1 cancels the first setting. As a result, the user can specify whether or not to cancel the installment payment setting, so the payment system 1 can effectively enhance user convenience.

[0372] [Variation 3-11] For example, when the processing by the setting cancellation unit 105 is executed, the user may be notified that the setting for installment payments, etc., has been canceled. The payment system 1 of the modified example 3-11 includes a setting cancellation notification unit 116. When the setting for installment payments, etc., is canceled, the setting cancellation notification unit 116 sends a setting cancellation notification to the user regarding the cancellation of the setting for installment payments, etc. The setting cancellation notification is a notification indicating that the setting for installment payments, etc., has been canceled.

[0373] Figure 30 shows an example of a setting cancellation notification. For example, the setting cancellation notification unit 116 notifies the user of the setting cancellation by displaying a message on the completion screen SC3 indicating that the setting for installment payments, etc., has been canceled (in Figure 30, the message is "The setting for installment payments has been canceled..."). The setting cancellation notification unit 116 identifies that the setting for installment payments, etc., has been canceled based on the processing result by the setting cancellation unit 105. If the setting for installment payments, etc., has been canceled, the setting cancellation notification unit 116 generates display data on the completion screen SC3 indicating this and sends it to the user terminal 30. The setting cancellation notification unit 116 may also be a function included in the display control unit 101.

[0374] Furthermore, the setting cancellation notification may be made by means of a notification other than the completion screen SC3. For example, the setting cancellation notification unit 116 may notify the user of the setting cancellation by means of a notification from the payment app's notification function, email, SMS message, messaging app message, SNS message, message from an app other than the payment app, push notification, pop-up notification, or banner notification. Even when the setting cancellation notification unit 116 makes a setting cancellation notification by means of a notification other than a notification, the setting cancellation notification unit 116 may identify that the installment payment setting has been canceled according to the processing result of the setting cancellation unit 105 and make a setting cancellation notification to the user.

[0375] In the modified example 3-11, payment system 1 sends a notification to the user regarding the cancellation of installment payments or similar settings when these settings are removed. This makes it easier for the user to notice that installment payments or similar settings have been removed, thus effectively improving user convenience.

[0376] [5-4. Modifications of the Fourth Embodiment] 31 is a diagram showing an example of functions realized in a modification of the fourth embodiment. For example, the payment server 10 includes a display control unit 101, a credit limit information acquisition unit 117, a usage amount information acquisition unit 118, a charge execution unit 119, a charge inquiry unit 120, a usage history information acquisition unit 121, and an application acceptance unit 122. Each of the display control unit 101, the credit limit information acquisition unit 117, the usage amount information acquisition unit 118, the charge execution unit 119, the charge inquiry unit 120, the usage history information acquisition unit 121, and the application acceptance unit 122 is realized by the control unit 11.

[0377] [Variation 4-1] For example, as explained in the fourth embodiment, the setting acquisition unit 104 may acquire settings such as installment payments for paying for products or services provided by a store that accepts the payment method. In Modification 4-1, as in the fourth embodiment, a payment may be made in which a code C10 displayed on the user terminal 30 is read by the store terminal 40, but an example will be given of a case in which another type of payment is made. For example, as in Modification 1-3, a payment may be made in which a code displayed on the store terminal 40 is read by the user terminal 30.

[0378] For example, the user terminal 30 obtains information necessary for payment (e.g., a store ID, a payment amount, or other information) from the code displayed on the store terminal 40. The user terminal 30 transmits the information obtained from the code to the payment server 10. When the payment server 10 receives the information from the user terminal 30, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 similar to that shown in FIG. 20. This series of steps may be the same as in Modification 1-3.

[0379] The setting acquisition unit 104 in Modification 4-1 may acquire settings such as installment payments specified on the confirmation screen SC5, as in Modification 1-3, or may acquire settings such as installment payments specified in advance on the code screen SC1 or the like. Furthermore, as described in the fourth embodiment, the setting acquisition unit 104 may acquire settings such as installment payments specified in a location other than the payment app. The setting acquisition unit 104 may also acquire settings such as installment payments specified on the payment system 1 side.

[0380] The process execution unit 102 in Modification 4-1 executes a process such as installment payment for payment of a price based on the settings of installment payment, etc. For example, when a user instructs payment from the confirmation screen SC5, the payment server 10 receives a payment request from the user terminal 30. The process execution unit 102 executes a process such as installment payment based on the payment request received from the user terminal 30 and the settings of installment payment, etc. This series of steps may be the same as in Modification 1-3.

[0381] In addition, in Variation 4-1, as in Variation 1-3, a payment may be made in which the payment destination store is specified from a list of stores displayed on user terminal 30. In this case, as in Variation 1-3, settings such as installment payments may be specified from the payment app, or settings such as installment payments may be specified elsewhere than the payment app. Variation 4-1 differs from Variation 1-3 in that it is not limited to settings such as installment payments being specified from the payment app.

[0382] The payment system 1 of Modification 4-1 includes a display control unit 101. When payment of the price is completed, the display control unit 101 causes the user terminal 30 to display a completion screen SC3 indicating that payment of the price has been completed, the completion screen SC3 indicating that payment related to installment payments, etc. has been made. This differs from the first embodiment in that settings for installment payments, etc. may be specified in a location other than the payment app, but the method of displaying the completion screen SC3 may be the same as in the first embodiment. The display control unit 101 may generate display data for the completion screen SC3 and send it to the user terminal 30, thereby causing the completion screen SC3 to be displayed on the user terminal 30.

[0383] The payment system 1 of variant 4-1 acquires settings for installment payments, etc., for payment of a price. The payment system 1 executes processing for installment payments, etc., for payment of a price based on the settings for installment payments, etc. When payment of a price is completed, the payment system 1 displays a completion screen SC3 on the user terminal 30, indicating that payment for installment payments, etc., has been made. This allows the user to understand on the completion screen SC3 that payment of installment payments, etc., has been made when payment of a price is made using installment payments, etc., so the payment system 1 can effectively improve user convenience.

[0384] [Variation 4-2] For example, as described in the second embodiment, a credit limit for installment payments or the like may be set for the user. In this case, similar to the second embodiment, the user may be allowed to use installment payments or the like within the credit limit. In Modification 4-2, an example is given in which the user's credit limit is displayed on the user terminal 30.

[0385] The payment system 1 of variant 4-2 includes a display control unit 101 and a credit limit information acquisition unit 117. The credit limit information acquisition unit 117 acquires credit limit information related to credit limits for installment payments, etc. In variant 4-2, it is assumed that the credit limit information described in the second embodiment is stored in the payment database DB1. For example, the credit limit information acquisition unit 117 queries the card server 20 for credit limit information and acquires the credit limit information from the card server 20. The credit limit information acquisition unit 117 stores the credit limit information in the payment database. The credit limit information acquisition unit 117 does not necessarily have to store the credit limit information in the payment database.

[0386] The display control unit 101 causes the user terminal 30 to display a credit limit screen related to the credit limit based on the credit limit information. The credit limit screen is a screen displayed on the user terminal 30 that displays the credit limit. In variant example 4-2, a confirmation screen SC5 is described as an example of a credit limit screen. The credit limit screen may be a screen other than the completion screen SC3. For example, the credit limit screen may be a code screen SC1, a payment source selection screen SC2, a confirmation screen SC5, a charge screen SC6, a charge source selection screen SC7, a screen for simply checking the credit limit, or another screen.

[0387] 32 is a diagram showing an example of a confirmation screen SC5 of Modification Example 4-2. For example, the display control unit 101 generates display data for the confirmation screen SC5 indicating the credit limit indicated by the credit limit information and transmits the display data to the user terminal 30. The display control unit 101 may cause the user terminal 30 to display the confirmation screen SC5 indicating at least one of the current amount of installment payments, etc., and the remaining amount of the credit limit. The display control unit 101 may cause the user terminal 30 to display the confirmation screen SC5 including images such as icons or gauges indicating these amounts.

[0388] The payment system 1 of Variation 4-2 displays a credit limit screen on the user terminal 30 based on the credit limit information. This allows the user to understand the credit limit on the credit limit screen on the user terminal 30, so the payment system 1 can effectively improve user convenience.

[0389] [Modified example 4-3] For example, in Modification 4-2, the display control unit 101 may display a code screen SC1 including a code related to payment and indicating a credit limit as a credit limit screen on the user terminal 30. When the code C10 on the code screen SC1 is read, the processing execution unit 102 executes processing such as installment payment based on the settings for installment payment, etc. The processing by the processing execution unit 102 may be the same as that in the fourth embodiment.

[0390] 33 is a diagram showing an example of a code screen SC1 of Modification Example 4-3. For example, the display control unit 101 generates display data for the code screen SC1 indicating the credit limit indicated by the credit limit information and transmits the generated display data to the user terminal 30. The display control unit 101 may cause the user terminal 30 to display the code screen SC1 indicating at least one of the current amount of installment payments, etc., and the remaining amount of the credit limit. The display control unit 101 may cause the user terminal 30 to display the code screen SC1 including images such as icons or gauges indicating these amounts.

[0391] The payment system 1 of variation 4-3 displays a code screen SC1 indicating the credit limit as a credit limit screen on the user terminal 30. When the code C10 on the code screen SC1 is read, the payment system 1 executes a process such as an installment payment based on the settings for the installment payment. This allows the user to understand the credit limit and execute payment directly on the code screen SC1, thereby effectively improving user convenience.

[0392] [Variation 4-4] For example, in Modifications 4-2 and 4-3, information indicating whether the usage amount subject to installment payments, etc. is within the usage limit may be displayed on the usage limit screen. The payment system 1 of Modification 4-4 includes a usage amount information acquisition unit 118. The usage amount information acquisition unit 118 acquires usage amount information related to the usage amount at the user terminal 30. As with Modifications 1-3 and 4-2, Modification 4-4 takes as an example a case where a code displayed on the store terminal 40 is read by the user terminal 30. The usage amount information acquisition unit 118 acquires the usage amount information included in the information acquired from the user terminal 30.

[0393] The display control unit 101 of Modification 4-4 determines whether the usage amount is within the usage limit based on the usage limit information and the usage amount information, and displays a usage limit screen indicating the result of the determination on the user terminal 30. For example, the display control unit 101 determines whether the remaining amount of the usage limit indicated by the usage limit information is equal to or greater than the usage amount indicated by the usage amount information. That is, the display control unit 101 determines whether the usage limit indicated by the usage limit information is sufficient for installment payments of the usage amount indicated by the usage amount information. In Modification 4-4, as in Modification 4-2, an example is given in which the confirmation screen SC5 corresponds to the usage limit screen. In Modification 4-4, as in Modification 4-2, the usage limit screen may be a screen other than the confirmation screen SC5.

[0394] FIG. 34 is a diagram showing an example of a confirmation screen SC5 of Modification Example 4-4. For example, when the display control unit 101 determines that the usage amount is within the usage limit, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 indicating that the usage amount is within the usage limit, as shown on the left side of FIG. 34. When the display control unit 101 determines that the usage amount is not within the usage limit, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 indicating that the usage amount is not within the usage limit, as shown on the right side of FIG. 34. The display control unit 101 may use other means, such as an icon, instead of a message as shown in FIG. 34, to display on the confirmation screen SC5 whether the usage amount is within the usage limit.

[0395] The payment system 1 of Variation 4-4 determines whether the usage amount is within the usage limit based on the usage limit information and the usage amount information, and displays a usage limit screen showing the results of the determination on the user terminal 30. This allows the user to know on the usage limit screen whether the usage limit is sufficient, so the payment system 1 can effectively improve user convenience.

[0396] [Variation 4-5] For example, in the fourth embodiment, as in Modifications 1-4, 2-7, and 3-3, installment payments and the like may be used for charging. Modification 4-5 differs from Modification 1-4 in that it is not limited to specifying settings for installment payments and the like from the payment app, but may be similar to Modification 1-4 in other respects. Modification 4-5 differs from Modification 2-7 in that it does not require the conditions of use to be determined, but may be similar to Modification 1-4 in other respects. Modification 4-5 differs from Modification 3-3 in that it does not require the settings for installment payments and the like to be canceled, but may be similar to Modification 1-4 in other respects.

[0397] The setting acquisition unit 104 in Modification Example 4-5 acquires settings for installment payments, etc. for charging using a payment method. For example, the setting acquisition unit 104 acquires settings for installment payments, etc. for charging stored in the payment database DB1. The processing execution unit 102 executes processing for installment payments, etc. for charging based on the settings for installment payments, etc. for charging. These processes may be similar to the processes in Modification Examples 1-4, 2-7, and 3-3 in which settings for installment payments for charging are acquired, and the processes for installment payments, etc. executed based on the settings.

[0398] The payment system 1 of Modification 4-5 includes a charge execution unit 119. The charge execution unit 119 executes a charge based on the result of a process such as an installment payment. In a charge, the charge amount may exceed the credit limit. In this case, the charge execution unit 119 may treat the charge as an error and not execute the charge. However, if the charge amount exceeds the credit limit for an installment payment or the like, the charge execution unit 119 of Modification 4-5 executes the charge within the credit limit. For example, the charge execution unit 119 may execute a charge using the remaining amount of the current credit limit as the charge amount, or may execute a charge with a charge amount less than the remaining amount of the current credit limit.

[0399] For example, suppose the remaining amount of the credit limit for installment payments, etc. is 8,000 yen. Furthermore, suppose the charge amount is 10,000 yen. In this case, the charge amount exceeds the credit limit. The charge execution unit 119 may execute a charge using the remaining amount of the credit limit, 8,000 yen, as the charge amount, or may execute a charge using an amount less than the remaining amount of the credit limit, 8,000 yen. The charge execution unit 119 determines the charge amount so that it falls within the credit limit, and executes a charge based on the charge amount.

[0400] The payment system 1 of variant 4-5 acquires settings for installment payments, etc. for charging. The payment system 1 executes processing for installment payments, etc. for charging based on the settings for installment payments, etc. for charging. If the charge amount for charging exceeds the usage limit for installment payments, etc., the payment system 1 executes charging within the usage limit. This allows the payment system 1 to execute charging within the usage limit even if the charge amount exceeds the usage limit, thereby improving user convenience. For example, the user will no longer need to instruct charging again if an error occurs during charging, so the payment system 1 can reduce the operational burden on the user and improve user convenience.

[0401] [Variation 4-6] For example, in variant 4-5, the user may be inquired as to whether or not to charge within the usage limit. The payment system 1 of variant 4-6 includes a charge inquiry unit 120. When the charge amount exceeds the usage limit, the charge inquiry unit 120 makes a charge inquiry to the user as to whether or not to charge within the usage limit. In variant 4-6, an example is given in which the inquiry is made on the charge screen SC6, but the charge inquiry unit 120 may make the charge inquiry on a screen other than the charge screen SC6.

[0402] 35 is a diagram showing an example of a charge inquiry. For example, when the charge amount exceeds the usage limit, the charge inquiry unit 120 displays a window W64 on the charge screen SC6, inquiring whether or not to perform a charge within the usage limit. The charge inquiry unit 120 displays the window W64 on the charge screen SC6 by transmitting display data for the window W64 to the user terminal 30. The window W64 includes a button B640 indicating that a charge will be performed within the usage limit, and a button B641 indicating that a charge will not be performed within the usage limit.

[0403] The charge execution unit 119 of variant example 4-6 performs charging within the usage limit based on the response to the charge inquiry. The response to the charge inquiry is a user operation in response to the charge inquiry. The user responds to the charge inquiry with either a first response indicating that charging will be performed within the usage limit, or a second response indicating that charging will not be performed within the usage limit. In the example of Figure 35, the user performs either the first response or the second response by selecting either button B640 or button B641.

[0404] For example, the user terminal 30 identifies the user's response to the charge inquiry based on an operation on the operation unit 34, and transmits response data indicating the user's response to the payment server 10. The payment server 10 receives the response data from the user terminal 30. The charge execution unit 119 determines whether to execute a charge within the value limit based on the response data and the response to the charge inquiry. If the response indicates that the charge will not be executed within the usage limit, the charge execution unit 119 does not execute the charge and generates an error. If the response indicates that the charge will be executed within the usage limit, the charge execution unit 119 executes a charge within the usage limit.

[0405] In the payment system 1 of variant 4-6, when the charge amount exceeds the usage limit, the payment system 1 makes a charge inquiry to the user as to whether or not to charge within the usage limit. Based on the response to the charge inquiry, the payment system 1 performs charging within the usage limit. This allows the user to instruct charging within the usage limit in response to the charge inquiry, so the payment system 1 can perform flexible processing and effectively improve user convenience.

[0406] [Variation 4-7] For example, a screen showing the usage history may be displayed on the user terminal 30. The payment system 1 of variant 4-7 includes a display control unit 101 and a usage history information acquisition unit 121. The usage history information acquisition unit 121 acquires usage history information relating to the usage history on the user terminal 30. The usage history information is usage information stored in the payment database DB1. The usage history information acquisition unit 121 acquires the usage information stored in the payment database DB1 as the usage history information. For example, the usage history information acquisition unit 121 acquires the usage history information when an instruction is given to display a usage history screen described below.

[0407] The display control unit 101 in Modification Example 4-7 causes the user terminal 30 to display a usage history screen showing usage history related to installment payments, etc., based on the usage history information. For example, the display control unit 101 generates display data for the usage history screen including at least part of the information on the usage history indicated by the usage history information and transmits it to the user terminal 30, thereby causing the usage history screen to be displayed on the user terminal 30. The usage history information may indicate the date and time of use of the payment app, the amount used, or whether or not installment payments, etc. were made.

[0408] FIG. 36 is a diagram showing an example of a usage history screen according to Modification 4-7. For example, the display control unit 101 displays a usage history screen SC9 on the user terminal 30, which shows a usage history of payments, charges, etc., made by the user through the payment app based on the usage history information. The display control unit 101 determines whether installment payments, etc., were used for each use based on information indicating whether installment payments, etc., were used in the usage history information. If a lump-sum payment was not changed to installment payments, etc., the usage history information indicates that the lump-sum payment was not changed to installment payments, etc. For a usage history in which a lump-sum payment was not changed to installment payments, etc., the display control unit 101 displays the usage history screen SC9 on the user terminal 30 so as to indicate that a lump-sum payment was made. For example, the display control unit 101 may determine whether installment payments, etc., are available for each use based on information indicating whether installment payments, etc., are available in the usage history information. For example, similar to the first embodiment, if it is determined that installment payments, etc., are available at a store or for an amount, and it is determined that installment payments, etc., are available, the display control unit 101 may display content for which installment payments are available.

[0409] For example, for a use in which installment payments or the like were not used, the display control unit 101 displays information such as the date and time of use on the usage history screen SC9 without displaying information indicating that installment payments or the like were used. For a use in which installment payments or the like were used, the display control unit 101 displays information such as the date and time of use on the usage history screen SC9 along with information indicating that installment payments or the like were used. In FIG. 36, a message such as "Application for 3 installments" or "Application for 5 installments" corresponds to information indicating that installment payments or the like were used. The information indicating that installment payments or the like were used is not limited to a message and may be an image such as an icon.

[0410] The payment system 1 of Variation 4-7 displays a usage history screen SC9 showing usage history related to installment payments, etc., on the user terminal 30 based on the usage history information. This allows the user to understand the usage history related to installment payments, etc. on the usage history screen SC9, so the payment system 1 can effectively improve user convenience.

[0411] [Variation 4-8] For example, in variant 4-7, it may be possible to apply for installment payments, etc. from the usage history screen SC9. The payment system 1 of variant 4-8 includes an application acceptance unit 122. The application acceptance unit 122 accepts applications for installment payments, etc. from the usage history screen SC9. In variant 4-8, it is possible to apply for installment payments, etc. for usage for which a credit card payment has not been debited. An application for installment payments, etc. is made by operating the usage history screen SC9.

[0412] For example, the display control unit 101 identifies a use for which a credit card payment has not been debited from the usage history indicated by the usage history information. The payment server 10 of Modification 4-8 is assumed to be able to acquire information indicating whether a credit card payment has been debited from the card server 20. The display control unit 101 may identify a use for which a credit card payment has not been debited based on the information.

[0413] For example, the display control unit 101 may display an image for accepting an application for installment payments, etc., on the usage history screen SC9 for usage that was not eligible for installment payments, etc., and for which a credit card payment has not yet been made. In the example of the usage history screen SC9 in FIG. 36, a payment to the EEE shop on June 15, 2024, was made as a lump sum payment, but the credit card payment has not yet been made. In this case, the display control unit 101 displays a button such as "Click here for installment payments, etc." in the portion of this payment on the usage history screen SC9. When the user selects the button, the payment is changed to a subsequent installment payment, etc.

[0414] The process execution unit 102 of variant example 4-8 executes a process such as installment payment when an application is accepted. For example, the process execution unit 102 transmits usage information of the application's subject use to the card server 20 and requests that it be changed to installment payment or the like. The process execution unit 102 may execute a process such as installment payment by changing the usage information stored in the payment database DB1 to installment payment or the like. The process of changing a lump-sum payment to installment payment or the like may be similar to the process of a known card service. The payment server 10 executes a subsequent change to installment payment or the like by transmitting data in a format defined by the card service's API to the card server 20.

[0415] The payment system 1 of variation 4-8 accepts an application for installment payments, etc. from the usage history screen SC9. When the application is accepted, the payment system 1 executes the process for installment payments, etc. This allows the user to later change to installment payments, etc. from the usage history screen SC9, thereby effectively improving user convenience.

[0416] [Variation 4-9] For example, in the fourth embodiment, as in Modification 2-11, allocation using points or the like may be possible. Modification 4-9 differs from Modification 4-9 in that the conditions of use may be determined as in Modification 2-11, or in particular the conditions of use may not be determined as in Modification 2-11. When allocation is performed using a payment method other than the payment method, the processing execution unit 102 of Modification 4-9 executes processing based on the value obtained by subtracting the amount allocated by the other payment method from the amount used in the user terminal 30. When the user specifies the amount to be allocated, the payment server 10 obtains the amount to be allocated specified by the user from the user terminal 30 or the store terminal 40. The amount to be allocated may be a fixed value. In this case, the amount to be allocated may be stored in advance in the payment database DB1.

[0417] For example, when payment of a price corresponds to the use of a payment app, the processing execution unit 102 executes processing such as installment payment based on the value obtained by subtracting the amount appropriated by other payment methods such as points from the amount used in payment of the price. The processing execution unit 102 determines the value obtained by subtracting the appropriated amount from the amount used as the payment amount for the installment payment. The processing execution unit 102 executes processing such as installment payment for payment of the price based on the determined payment amount. For example, the processing execution unit 102 may execute a lump-sum payment for the time being based on the determined payment amount, as in the fourth embodiment. Note that if the entire payment amount is appropriated, processing such as installment payment may not be executed.

[0418] For example, when charging a payment app corresponds to using the payment app, the processing execution unit 102 executes processing such as installment payment based on the value obtained by subtracting the amount appropriated by other payment methods such as points from the charge amount. The processing execution unit 102 determines the value obtained by subtracting the appropriated amount from the charge amount as the payment amount for the installment payment. The processing execution unit 102 executes processing such as installment payment for payment of the price based on the determined payment amount. For example, the processing execution unit 102 may execute payment for charging based on the determined payment amount.

[0419] In the case where appropriation is performed using a payment method other than the payment method, the payment system 1 of Variation 4-9 executes processing based on the value obtained by subtracting the amount appropriated by the other payment method from the amount used at the user terminal 30. This allows the payment system 1 to appropriately execute processing for installment payments, etc., even when points, etc., are appropriated.

[0420] [Variation 4-10] For example, the setting acquisition unit 104 may acquire a setting indicating the number of installment payments or the number of revolving payments that cannot be specified when the payment means is used by a means other than the user terminal 30. The other means may be a payment app other than the payment app described in the fourth embodiment, a physical card, or an IC chip in the user terminal 30. For example, the number of installment payments or revolving payments for a credit card may be set to a number that the user cannot select. The payment app of Variation 4-10 may allow such a number to be specified.

[0421] In Variation 4-10, a credit card will be described as an example of a payment method that is eligible for installment payments, etc. With a physical credit card, it is assumed that four installments or revolving payments cannot be specified. With a payment app, four installments, which cannot be specified with a physical credit card, can be specified as the number of installments or revolving payments. It is assumed that number data indicating such a number is stored in the data storage unit 100. It is assumed that the card server 20 is capable of processing such installment payments or revolving payments.

[0422] For example, as in the first embodiment, when the number of installments or the number of revolving payments is specified in the payment app, the display control unit 101 causes the user terminal 30 to display a setting screen on which the number of installments or the number of revolving payments indicated by the number data (the number of installments or the number of revolving payments that cannot be specified with a physical credit card) can be specified. The setting acquisition unit 104 may acquire the number of installments or the number of revolving payments specified in the setting screen as a setting for installments, etc. When the number of installments or the number of revolving payments is specified by another method described in the fourth embodiment and modifications 4-1 to 4-10 instead of the setting screen as in the first embodiment, the setting acquisition unit 104 may acquire the number of installments or the number of revolving payments specified by the other method as a setting for installments, etc. ...

Claims

1. A setting acquisition unit that acquires the user's settings regarding installment payments, revolving credit, or bonus payments for available payment methods, A processing execution unit that performs processing related to installment payments, revolving payments, or bonus payments based on the above settings, A setting release unit that releases the setting based on predetermined release conditions, Payment systems, including:

2. The setting acquisition unit acquires the setting for payment of goods or services provided by the store, The processing execution unit executes the processing for payment of the price based on the settings, The setting release unit releases the setting for payment of the price based on the release condition. The payment system according to claim 1 .

3. the setting cancellation unit determines whether the cancellation condition is satisfied by determining whether the payment of the price has been made, and cancels the setting when it is determined that the payment of the price has been made. The payment system according to claim 2 .

4. The setting cancellation unit determines whether the cancellation condition is satisfied by determining whether the store is a non-compatible store that does not support the installment payment, the revolving payment, or the bonus payment, and cancels the setting when it is determined that the store is a non-compatible store. The payment system according to claim 2 or 3.

5. The setting cancellation unit cancels the setting based on the cancellation conditions before payment of the price is instructed. The payment system according to claim 2 or 3.

6. The setting acquisition unit acquires the setting in the charge in which the payment method is used. The processing execution unit executes the processing in the charge based on the setting, The setting release unit releases the setting in the charge based on the release condition. A payment system according to any one of claims 1 to 3.

7. The setting cancellation unit determines whether the cancellation condition is satisfied by determining whether the charging has been performed, and cancels the setting when it is determined that the charging has been performed. The payment system according to claim 6.

8. The setting cancellation unit determines whether the cancellation condition is satisfied by determining whether the payment means used, which is the payment means used on the user terminal of the user, has been changed, and cancels the setting when it is determined that the payment means used has been changed. A payment system according to any one of claims 1 to 3.

9. The setting cancellation unit determines whether the payment means used has been changed from a corresponding payment means that supports the installment payment, the revolving payment, or the bonus payment to a non-compatible payment means that does not support the installment payment, the revolving payment, or the bonus payment, and cancels the setting when it is determined that the payment means used has been changed from the corresponding payment means to the non-compatible payment means. The payment system according to claim 8.

10. The setting cancellation unit does not cancel the setting when it is determined that the payment means to be used has been changed from one of the plurality of supported payment means to another of the supported payment means, and cancels the setting when it is determined that the payment means to be used has been changed from one of the plurality of supported payment means to the non-supported payment means. The settlement system according to claim 9.

11. the setting cancellation unit cancels the setting when the payment means to be used is changed from one of the plurality of supported payment means to the non-supported payment means, and thereafter, when it is determined that the payment means to be used has been changed from the non-supported payment means to one of the plurality of supported payment means, applies the setting again; The settlement system according to claim 9.

12. the setting cancellation unit determines whether the cancellation condition is satisfied by determining whether an app or a browser stored in the user terminal of the user has been terminated, and cancels the setting when it is determined that the app or the browser has been terminated on the user terminal; A payment system according to any one of claims 1 to 3.

13. The setting acquisition unit acquires a first setting regarding whether or not the installment payment, the revolving payment, or the bonus payment is used, and a second setting regarding whether or not the first setting needs to be canceled, the process execution unit executes the process based on the first setting; the setting cancellation unit cancels the first setting based on the second setting and the cancellation condition. A payment system according to any one of claims 1 to 3.

14. the payment system further includes a setting cancellation notification unit that, when the setting is canceled, sends a setting cancellation notification regarding the cancellation of the setting to the user; A payment system according to any one of claims 1 to 3.

15. a setting acquisition step of acquiring settings regarding installment payments, revolving payments, or bonus payments of payment methods available to the user; a processing execution step of executing processing related to the installment payment, the revolving payment, or the bonus payment based on the setting; a setting cancellation step of canceling the setting based on a predetermined cancellation condition; Payment methods including.

16. a setting acquisition unit that acquires settings regarding installment payments, revolving payments, or bonus payments as payment methods available to the user; a processing execution unit that executes processing related to the installment payment, the revolving payment, or the bonus payment based on the setting; a setting cancellation unit that cancels the setting based on a predetermined cancellation condition; A program that allows a computer to function as a

Images