Payment system, payment method, and program

Abstract

Improve user convenience. [Solution] A usage information acquisition unit (112, 202) of a payment system (1) acquires usage information regarding the use of payment methods available on a user terminal (30). A usage condition determination unit (109, 203) determines, based on the usage information, whether the usage conditions regarding the use of the payment method as installment payments, revolving payments, or bonus payments are met. A processing execution unit (102, 201) executes processing related to installment payments, revolving payments, or bonus payments based on the determination result of the usage condition determination unit (203).

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 via user terminals have been known. For example, Patent Literature 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 Summary of the Invention [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 make installment payments according to the details of the payment method used. As a result, with the technology of Patent Document 1, installment payments may be made that the user does not intend. This is not limited to installment payments as in Patent Document 1, but also applies to revolving payments or bonus payments. For this reason, conventional technologies have not been able to sufficiently improve user convenience.

[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 usage information acquisition unit that acquires usage information regarding the use of payment methods available on a user terminal, a usage condition determination unit that determines whether usage conditions regarding the use of installment payments, revolving payments, or bonus payments of the payment method are met based on the usage information, and a processing execution unit that executes processing regarding the installment payments, revolving payments, or bonus payments based on the determination result of the usage condition determination unit. [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. 13 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. 13 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] FIG. 10 is a diagram showing 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] FIG. 10 is a diagram showing an example of a confirmation screen of Modification Example 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] FIG. 13 is a diagram showing an example of a completion screen of Modification 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 indicates the current payment source. In the example at the top left of FIG. 2, panel P11 shows information about the credit card "AAA Card" selected as the payment source. When the user selects panel P11, the user terminal 30 causes the display unit 35 to display a payment source selection screen SC2, which includes a panel P20 that shows payment methods that can be selected as the payment source, as shown at the top right of FIG. 2. In the example at the top right of FIG. 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 payments, or bonus payments to pay for the amount using the payment app. Installment payments are a payment method in which the amount used is paid in multiple installments. Revolving payments are a payment method in which payments are made over multiple months so that the monthly payment amount remains constant. Bonus payments are a payment method in which a lump sum payment is made in a predetermined month. The meanings of installment payments, revolving payments, and bonus payments may each have a known meaning.

[0024] Hereinafter, the flow of a user using installment payments from a payment app will be given as an example, but the flow of a user using revolving payments or bonus payments from a payment app may be similar. The user may be able to freely select which of installment payments, revolving payments, and bonus payments to use. The payment app may support only installment payments, only revolving payments, only bonus payments, only installment payments and revolving payments, only installment payments and bonus payments, or only revolving payments and bonus payments.

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

[0026] For example, when the user selects the top panel P20 indicating the credit card selected as the payment source, the user terminal 30 causes the display unit 35 to display a modal M21 including a panel P210 indicating the number of installments, superimposed on the payment source selection screen SC2, as shown in the lower left of FIG. 2. In the example in the lower left of FIG. 2, when the user selects the top panel P210, the user can specify a setting indicating that installment payment is not available. When the user selects a panel P210 from the second panel onward, the user can specify a setting indicating that installment payment is available for the number of installments indicated by panel P210.

[0027] For example, when the user selects the second or subsequent panel P210, the user terminal 30 closes the modal M21 and displays the installment payment settings specified by the user in the top panel P20, as shown in the lower right of Fig. 2. In the example in the lower right of Fig. 2, the user has specified three installments as the installment payment settings. When the user performs an operation to return to the code screen SC1, the user terminal 30 displays the installment payment settings specified by the user in panel P11, as shown in the left of Fig. 3.

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

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

[0030] When the user uses the revolving payment or bonus payment option in the payment app, the user may specify the revolving payment or bonus payment option on the payment source selection screen SC2, as in the case of Figures 2 and 3. When the user specifies the revolving payment or bonus payment option, the revolving payment or bonus payment option specified by the user is displayed on panel P11 of code screen SC1. When the store terminal 40 reads code C10, the revolving payment or bonus payment option is made based on the revolving payment or bonus payment option specified by the user.

[0031] As described above, the payment system 1 of the first embodiment is configured to display on the user terminal 30 a payment source selection screen SC2 that accepts the 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. Details of the payment system 1 of the first embodiment will be explained below. Note that hereinafter, "installment payments, etc." may be used as an abbreviation for "installment payments, revolving payments, or bonus payments." In the following explanation, "installment payments, etc." can be read as "installment payments, revolving payments, or bonus payments."

[0032] [1-3. Functions realized by 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 realized 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 section] The data storage unit 100 stores various data related to the payment service. For example, the data storage unit 100 stores a 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 indicating 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 payments in revolving 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 payment database DB1.

[0039] The usage information is information about the usage of the payment app. The usage information can also be referred to as information about payments made from the payment app. In the first embodiment, payments are made not only when paying but also when charging, so the usage information can also be referred to as information about payments or charging. The usage information may indicate not only payments made from the payment app but also other information such as the user's operation history for the payment app. For example, if the usage information indicates past usage, the usage information can also be referred to as the usage history of the payment app. The usage information may also indicate the content of a payment that is about to be made. The usage information may include information such as an ID that can identify each payment.

[0040] For example, if payment of a price corresponds to use of a payment app, the usage information indicates information on the payment method selected as the payment source, the usage amount, the date and time of use, and the store used. The usage information may also include information on the product or service that was the subject of payment. If charging corresponds to use of a payment app, the usage information indicates information on the payment method selected as the charge source, the charge amount, and the date and time of charge. If settings such as installment payments are specified, the usage information may also indicate the settings such as installment payments specified at the time of use. For example, the usage information may indicate the number of installments in installment payments, the payment amount or number of payments in revolving payments, or the bonus month in bonus payments. The usage information may include any other information.

[0041] For example, when a user uses a payment app, the payment server 10 generates usage information indicating the usage of the payment app and stores the usage information in the payment database DB1 in association with the user ID of the user. When a user pays using the payment app, the payment server 10 generates usage information indicating information on the payment method selected as the payment source, whether or not installment payment is available, the usage amount, the date and time of use, and the store used, and stores the usage information in association with the user ID of the user in the payment database DB1. When a user charges using the payment app, the payment server 10 generates usage information indicating information on the payment method selected as the charge source, the charge amount, whether or not installment payment is available, and the charge date and time, and stores the usage information in association with the user ID of the user in the payment database DB1.

[0042] The data stored in the data storage unit 100 is not limited to the above examples. The data storage unit 100 may store any data related to payment services. For example, the data storage unit 100 may store data for various screens displayed on a payment app. The data storage unit 100 may store various data described below. For example, the data storage unit 100 may store a store database that stores various information related to stores where users can use payment services.

[0043] [Display control section] The display control unit 101 displays a payment service screen on the user terminal 30. For example, the display control unit 101 displays a payment app screen on the user terminal 30. The display control unit 101 may also display a screen of an app other than the payment app or a browser screen on the user terminal 30. For example, the display control unit 101 displays the screen to be displayed on the user terminal 30 by transmitting display data of the screen to the user terminal 30. The display data is data that shows all or part of the payment app screen. The display data may be in any format, and may be, for example, data in a markup language such as HTML, image data, or text data. The data storage unit 100 may store the display data itself to be transmitted to the user terminal 30, or may store 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 section] 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 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 linkage of the payment data and the data for installment payments, etc. may be linked separately, or may be linked together and simultaneously. The timing of the determination of whether installment payments, etc. are possible and the recording may be at any timing. These may be done simultaneously, or the recording may be done after the determination of whether installment payments, etc. are possible. The determination of whether installment payments, etc. are possible may be made after the recording is done. For example, if installment payments, etc. are possible after the determination of installment payments, etc., the case will be taken as an example, 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 realized 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 section] The data storage unit 200 stores various data related to the card service. For example, the data storage unit 200 stores a 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 section] 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 section] 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 acceptance unit 301 accepts various operations from the user. For example, the operation acceptance unit 301 accepts operations for the payment application. The operation acceptance unit 301 transmits data indicating the content of the user's operation 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 realized by the storage unit 42. The payment request transmission unit 401 is realized by the control unit 41.

[0072] [Data storage section] 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 sending unit 401 sends a payment request to the payment server 10. For example, when the store terminal 40 reads the code C10 with the reading unit 46, the payment request sending unit 401 acquires a code ID from the code C10. The payment request sending unit 401 sends a payment request including information necessary for payment, such as the code ID, payment amount, and store ID, to the payment server 10. The payment request may be a request used in a known payment service. The payment request sending unit 401 acquires the execution result of the payment from the payment server 10 and completes the payment of the price. This series of processes may also be a process adopted in a known payment service. In the first embodiment, even if a setting such as installment payment is specified, the payment is processed as a lump sum payment for the time being. Therefore, the format of the payment request may be the same whether a setting such as installment payment is specified or not.

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

[0075] As shown in FIG. 7, the user terminal 30 starts the payment app and executes login processing with the payment server 10 to allow the user to log in to the payment service (S100). The user terminal 30 executes processing with the payment server 10 to display a code screen SC1 on the display unit 35 (S101). In S101, the payment server 10 issues a new code ID based on predetermined issuing rules and stores it in the payment database DB1. The payment server 10 transmits the code ID to the user terminal 30. Upon receiving the code ID, the user terminal 30 displays the code screen SC1 including the 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 by the payment system of the second embodiment] Figure 9 is a diagram showing an example of 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 units implemented in the payment system 1 of the second embodiment can be configured by consolidating them into a single device or by distributing them into smaller devices.

[0092] Note that the payment system 1 of the second embodiment may not include the functions described in the first embodiment (for example, the function for displaying a setting screen such as the payment source selection screen SC2). For example, the payment system 1 of the second embodiment may not include the function for displaying a setting screen, 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 may not allow the user to specify settings such as installment payments from the setting screen. For example, the payment database DB1 may not store settings such as installment payments for each user. These points also apply to the third and fourth embodiments described below.

[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 for installment payments, etc. from a location other than the payment app (e.g., a browser). In this case, the payment app does not display a settings screen such as the payment source selection screen SC2, but the user may specify settings for installment payments, etc. from a screen displayed in another location. The payment database DB1 may store settings for installment payments, etc. specified from a screen displayed in another location. These points also apply to the third and fourth embodiments described below.

[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 realized 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 section] The data storage unit 100 may be the same as in the first embodiment.

[0098] [Processing execution section] The process execution unit 102 may be the same as in the first embodiment. For example, when an instruction to pay the price is given, the process execution unit 102 may process the payment as a lump sum payment, and then execute a process to change to installment payment, etc., in the same way as when installment payment, etc. is not specified. This is the same as in the first embodiment. When installment payment, etc. is not specified, it can also be said that the user selects lump sum payment. In other words, when installment payment, etc. is not specified, it is the same as in conventional payment services in which installment payment, etc. cannot be selected. For example, when the process execution unit 102 receives a payment request from the store terminal 40, it may execute a lump sum payment without performing special processing for installment payment, etc.

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

[0100] The process execution unit 102 may have all or part of the functions of the process execution unit 102 described in the first embodiment. For example, the process execution unit 102 may determine whether to execute a process such as installment payment based on the setting of installment payment, etc., similar to the process execution unit 102 of the first embodiment. If the setting of installment payment, etc. is not specified as in the first embodiment, the setting of installment payment, etc. may be included in the payment request. The process execution unit 102 may determine whether to execute a process such as installment payment, etc., based on the setting of installment payment, etc.

[0101] For example, the processing execution unit 102 may execute a lump-sum payment for the time being, and then generate usage information indicating that the payment is subject to installment payments, etc., in the same manner as the processing execution unit 102 of the first embodiment, and store the usage information in the payment database DB1. For example, the usage information may indicate not only information indicating that the payment is subject to installment payments, etc. (for example, a flag, etc.), but also detailed settings such as the number of installments. This information may make it possible to identify that the payment is subject to installment payments, etc.

[0102] [2-2-2. Functions realized by the card server] For example, card server 20 includes data storage unit 200, process execution unit 201, usage information acquisition unit 202, and usage condition determination unit 203. Each of usage information acquisition unit 202 and usage condition determination unit 203 is realized by control unit 21. Note that at least one of usage information acquisition unit 202 and usage condition determination unit 203 may be realized by payment server 10.

[0103] [Data storage section] The data storage unit 200 may be the same as in the first embodiment. In the second embodiment, the data storage unit 200 stores use condition data indicating use conditions. The use condition data may indicate only one use condition, or may indicate multiple use conditions. In the example of FIG. 8, three use conditions are defined, so the use condition data indicates three use conditions. The use condition data may be in any format. For example, the use condition data may be in a table format, a mathematical formula format, part of a program, a machine learning model, or another format. The use condition data may be defined by a payment service administrator or a card service administrator (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, an example is given in which the timing for recording usage information occurs periodically. For example, a predetermined time on a certain 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 occurred by determining whether the predetermined time on a certain day has occurred. The time interval between the timings for recording usage information is not limited to one day, and may be any time interval. For example, the timing for recording usage information may occur every few hours, several days, one week, or other time intervals. When it is determined that the timing for recording usage information has occurred, the usage information acquisition unit 202 acquires usage information including a usage date and time within the period from the most recent determination time to the current time.

[0108] The usage information acquisition unit 202 may determine whether the timing to record the usage information has arrived by determining whether a predetermined time has passed since the date and time of use. In this case, the usage information acquisition unit 202 determines whether the timing to record the 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 to record the usage information has arrived. If no particular recording timing is specified, the usage information acquisition unit 202 may acquire usage information from the payment server 10 every time the payment server 10 generates usage information.

[0109] [Usage conditions judgment section] The usage condition determination unit 203 determines whether or not usage conditions related to the use of payment methods such as installment payments are satisfied based on the usage information acquired by the usage information acquisition unit 202. For example, the usage condition determination unit 203 acquires usage condition data stored in the data storage unit 200 and determines whether or not the usage information satisfies the usage conditions indicated by the usage condition data. When multiple usage conditions are indicated in the usage condition data, the usage condition determination unit 203 determines whether or not each of the multiple usage conditions is satisfied.

[0110] In the example of Fig. 8, the usage condition determination unit 203 determines whether or not usage condition 1 is satisfied by determining whether the store where payment is made does not support installment payments, etc., based on the usage information acquired by the usage information acquisition unit 202. In other words, the usage condition determination unit 203 determines whether or not usage condition 1 is satisfied by determining whether or not the store where payment is made supports installment payments, etc., based on the usage information acquired by the usage information acquisition unit 202. There may be stores that support only some of the installment payments, etc., such as stores that support installment payments but not revolving payments.

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

[0112] For example, the usage condition determination unit 203 determines whether or not usage condition 3 is satisfied by determining whether the usage is within the range of 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 or not usage condition 3 is satisfied by determining whether or not the usage exceeds the range of the user's usage limit. The usage limit is the range within which installment payments, etc. are possible. The usage limit is also called an installment limit. The usage limit may be a limit adopted for well-known installment payments, etc.

[0113] In the second embodiment, it is assumed that credit limit information indicating a user's credit limit is stored in card database DB2. The credit limit information may indicate the total amount of the credit limit allocated to the user, or 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 whom the usage information was acquired, and determines whether the usage amount indicated by the usage information is within the credit limit. If the credit limit information is stored in a database other than card database DB2, the usage condition determination unit 203 may acquire the credit limit information from the other database.

[0114] For example, the usage condition determination unit 203 determines whether or not usage condition 3 is satisfied by determining whether the usage amount of installments or the like is equal to or greater than a predetermined amount based on the usage information acquired by the usage information acquisition unit 202. The predetermined amount information indicating the predetermined amount is assumed to be stored in the data storage unit 100. The predetermined amount may be common to all stores, or may be determined for each store or each user. The usage condition determination unit 203 determines whether or not usage condition 3 is satisfied based on the predetermined amount information stored in the data storage unit 100 and the usage amount indicated by the usage information.

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

[0116] 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 an installment payment or the like and processed. The usage condition determination unit 203 determines whether or not the usage conditions are met after the lump sum payment is initially made. For example, when the time to record the usage information arrives, the usage condition determination unit 203 determines whether or not 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 section] 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 Embodiment] 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 realized by 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 realized by the payment server] For example, the payment server 10 includes a data storage unit 100, a process 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 realized by the control unit 11.

[0142] [Data storage section] 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 section] 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 met 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 met 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 met. The non-execution of payment of the price corresponds to the cancellation condition not being met.

[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 realized on user terminals] The functions of the user terminal 30 may be the same as those in the first or second embodiment.

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

[0153] [3-3. Processing executed 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 will be described, which is an example of an embodiment of the payment system 1, payment method, and program according to the present disclosure. In the fourth embodiment, a description of the same configuration as in the first to third embodiments will be omitted. 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 is a diagram showing an example of functions implemented in payment system 1 of the fourth embodiment. Although Figure 15 does not show some of the functions described in the first to third embodiments, payment system 1 of the fourth embodiment may include the functions described in the first to third embodiments. The units implemented in payment system 1 of the fourth embodiment can be configured by consolidating them into a single device or by distributing them into smaller devices.

[0166] [4-2-1. Functions realized 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 section] 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 payment is made by reading the code C10, so the processing execution unit 102 acquires settings for installment payments and the like for the payment of the price of the product or service provided by the store where the code C10 displayed in the payment app is read. The setting acquisition unit 104 may acquire settings for installment payments and the like from the payment database DB1, as in the first to third embodiments.

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

[0170] [Processing execution section] The process execution unit 102 may be the same as that in the first or third embodiment. The process of the process execution unit 102 may be the same as that in the second embodiment. In the fourth embodiment, a payment is made by reading the code C10. Therefore, when the code C10 is read at the store, the process execution unit 102 executes a process such as installment payment based on the settings of the installment payment or the like. In the example of FIG. 14 , the process execution unit 102 executes a process such as installment payment based on the settings of the installment payment or the like specified on the setting screen SC4 of the store terminal 40. The process such as installment payment itself may be the same as that in the first or third embodiment. The process such as installment payment may be the same as that in the second embodiment.

[0171] [4-2-2. Functions realized by the card server] The function of the card server 20 may be the same as in 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 in 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 in the first to third embodiments.

[0174] [4-3. Processing executed in the payment system of the fourth embodiment] Figure 16 is a diagram showing an example of the processing executed in the payment system 1 of the fourth embodiment. The processing of Figure 16 is executed by the control units 11, 21, 31, and 41 executing programs stored in the storage units 12, 22, 32, and 42, respectively. Figure 16 shows an example in which settings for installment payments, etc. are specified on the setting screen SC4 of the store terminal 40, as in Figure 14, but in the fourth embodiment, the user may also be allowed to use installment payments, etc., in a manner 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. Modifications] 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 of 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 transmits to the payment server 10 the installment payment settings specified by the user from the pull-down menu P110 (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. When the user cancels the installment payment settings from the pull-down menu P110 (in the example in the upper right of FIG. 18, the user selects "lump sum payment"), 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. The meaning of canceling the installment payment settings is as explained in the third embodiment.

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

[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 may generate a code ID that does not overlap with other code IDs, and generate display data for the code screen SC1 based on the code ID. The process of converting the code ID into the code C10 may be executed on the payment server 10 side or on the user terminal 30 side. The display control unit 101 may generate all or part of the data necessary for displaying the code screen SC1, including the code C10 for code payment and user interface parts that accept settings such as installment payment, as display data for the code screen SC1 and transmit the generated data 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] When the user specifies the setting of revolving payment or bonus payment, the display of the code screen SC1 may be controlled in the same manner as when the user specifies the setting of installment payment. For example, when a first operation is performed, the display control unit 101 may display a user interface that accepts a second operation for specifying details of the setting of revolving payment or bonus payment so as to be superimposed on the code screen SC1. The display control unit 101 may control this series of processes by transmitting display data including a script indicating 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 code screen SC1. This series of processes may be indicated in the program code of the payment app.

[0197] Also, although it differs from Variation 1-1 in that display control is performed in response to the first operation and the second operation, the processing for displaying the code C10, such as generating a code ID, may be the same as in Variation 1-1. The processing execution unit 102 of Variation 1-2 executes processing such as installment payments for payment of the price based on the details of the settings for installment payments, etc., specified by the second operation. Although it differs from Variation 1-1 in that display control is performed in response to the first operation and the second operation, the processing after the code C10 is read may be the same as in Variation 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 of code screen SC1 in that it indicates a charge source rather than a payment source. However, the usage of panel P61 is generally similar to that of panel P11. When a user selects panel P61, as shown in the upper right of FIG. 21 , the display control unit 101 may cause the user terminal 30 to display a charge source selection screen SC7, which has a layout similar to that of the payment source selection screen SC2. The charge source selection screen SC7 displays a list of payment methods that can be specified as a charge source. The user may 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 setting screen. The flow for specifying settings such as installment payments from the charge source selection screen SC7 may be similar to the flow shown in the payment source selection screen SC2 of FIG. 2. The charge source selection screen SC7 may also be a screen on which the user can switch charge sources (charge methods) and set their priorities. For example, the charge source selection screen SC7 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 panel P70 of a payment method that is a candidate for the charge source, the user terminal 30 displays modal M71, which accepts settings such as installment payments, on the charge source selection screen SC7, as shown in the lower left of FIG. 21. The series of processes, such as displaying modal M71, may be similar to the processes for displaying modal M21 on the payment source selection screen SC2. For example, the series of processes, such as displaying modal M71, may be executed by a script included in the display data of the charge source selection screen SC7. This series of processes may be specified in the program code of the payment app.

[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, when the user performs an operation to return to the charge screen SC6 in the state shown in the lower right of FIG. 21 , the user terminal 30 causes the display unit 35 to display the charge screen SC6 again. A pull-down menu P610 on the charge screen SC6 displays the user-specified settings for installment payment, etc. In this state, when the user selects the button B62 for confirming the execution of the charge, the process for charge and the process for installment payment, etc. are executed based on the user-specified settings for the charge conditions and the installment payment, etc. In the case where a lump-sum payment is executed, the process for charge may be similar to known processes. The process execution unit 102 generates usage information indicating that the charge source was used from the payment app for charge, including the charge amount, charge date and time, information about the charge source, and information indicating that the payment was subject to installment payment, and stores the generated usage information in the payment database DB1.

[0225] The payment system 1 of Variation 1-4 displays a setting screen on the user terminal 30 that accepts the specification of settings for installment payments, etc., when recharging using a payment method. The payment system 1 executes processing for installment payments, etc., when recharging based on the settings for installment payments, etc. This allows the user to use installment payments, etc., when recharging from a payment app, and the payment system 1 can improve the user's convenience when recharging from a payment app.

[0226] [Variation 1-5] For example, as explained somewhat in Modification 1-4, the display control unit 101 may cause the user terminal 30 to display, as a setting screen, a charge screen SC6 that accepts specification of charge conditions related to charge. For example, when the user selects a pull-down menu P610, the user terminal 30 may cause the pull-down menu P610 to display the number of divisions that the user can specify. The number of divisions displayed in the pull-down menu P610 may be the same as the number of divisions displayed in the pull-down menu P110 of the code screen SC1 in the upper right corner of FIG.

[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] [Variation 1-6] For example, as in variant example 1-5, when the charge screen SC6 corresponds to a setting screen, the display control unit 101 may cause the user terminal 30 to display the charge screen SC6 that accepts a third operation for starting to set up installment payments, etc. The third operation is an operation that is performed before specifying the details of the settings for installment payments, etc. In other words, the third operation is an operation for displaying a part of a user interface that accepts the specification of the details of the settings for installment payments, etc. The third operation is an operation that is performed before the fourth operation described below. The third operation can also be said to be an operation for starting to set up installment payments, etc. The charge screen SC6 includes a part of a user interface that accepts the third operation.

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

[0232] When a third operation is performed on the charge screen SC6, the display control unit 101 of Modification Example 1-6 causes the user terminal 30 to display a user interface that accepts a fourth operation for specifying details of settings for installment payments, etc., so as to be superimposed on the charge screen SC6. The fourth operation is an operation that is performed after the third operation. For example, the fourth operation may be an operation that specifies whether or not to use installment payments, etc. The fourth operation may be an operation that specifies the number of installments in installment payments, the payment amount or number of payments in revolving payments, or the bonus month in bonus payments. The fourth operation can also be an operation that specifies a numerical value that indicates settings for installment payments, etc. In Modification Example 1-6, the user performs at least two operations, including the third operation and the fourth operation, to complete 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] The payment system 1 of Variation 1-6 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 so that the interface is superimposed on the charge screen SC6. The payment system 1 executes the charge process based on the details of the settings, such as installment payments, specified by the fourth operation. This allows the user to specify the settings, such as installment payments, directly from the modal M63 that is displayed superimposed on the charge screen SC6 displayed during charge, thereby 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 settings, such as installment payments.

[0240] [Variation 1-7] For example, as explained somewhat in the first embodiment and modified examples 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 may be only a portion of that information. When 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 payment source or the 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 screen may be a screen other than the payment source selection screen SC2 and the charge source selection screen SC7. For example, the payment method screen may be a screen for specifying a payment method to be registered in the payment app. In this case, the display control unit 101 may display the screen for specifying a payment method to be registered in the payment app as a settings screen. The payment method screen may be a screen for deleting a payment method registered in the payment app. In this case, the display control unit 101 may display the screen for deleting a payment method registered in the payment app as a settings screen.

[0245] The processing execution unit 102 in Modification 1-8 executes processing such as installment payments based on the settings of the payment method to be used and the installment payments, etc. specified on the payment method to be used screen. For example, the processing execution unit 102 executes processing such as installment payments when paying a price based on the settings of the payment source and the installment payments, etc. selected on the payment source selection screen SC2, which is an example of the payment method to be used screen. This processing is as described in the first embodiment. The processing execution unit 102 executes processing such as installment payments when charging based on the settings of the charge source and the installment payments, etc. selected on the charge source selection screen SC7, which is an example of the payment method to be used screen. This processing is as described in Modification 1-4.

[0246] The payment system 1 of Variation 1-8 displays the payment method screen as a settings screen on the user terminal 30. The payment system 1 executes processes such as installment payments based on the payment method and installment payment settings specified on the payment method screen. This allows the user to specify settings such as installment payments on the payment method screen where the user selects the payment method, thereby effectively improving 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 or the like is specified. The payment server 10 includes functions similar to those of the usage information acquisition unit 202 described in the second embodiment. For example, in a type that reads store codes, information on the store to be settled and the usage amount can be acquired before the setting of installment payments or the like is specified. Information on the credit line 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 that is the target of installment payments or the like. The method of determining the usage conditions may be the same as that of the usage condition determination unit 203 described in the second embodiment.

[0254] The display control unit 101 in Modification Example 1-10 displays a setting screen on the user terminal 30 based on the determination result of the use condition determination unit 109. For example, if it is determined that the use conditions are not satisfied, the display control unit 101 does not display the setting screen on the user terminal 30, and if it is determined that the use conditions are satisfied, the display control unit 101 displays the setting screen on the user terminal 30. If it is determined that the use conditions are not satisfied, the display control unit 101 may display a setting screen on the user terminal 30 that does not accept designation of settings such as installment payments (for example, a setting screen in which parts of the user interface that accept designation of settings such as installment payments are grayed out, or a setting screen that does not include such parts), and if it is determined that the use conditions are satisfied, the display control unit 101 may display a setting screen that accepts designation of settings such as installment payments on the user terminal 30.

[0255] The payment system 1 of Variation 1-10 determines whether the terms of use for installment payments or the like are met on the user terminal 30. Based on the results 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 according to the results 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 when the terms of use are not met.

[0256] [Variation 1-11] For example, the display control unit 101 may be capable of displaying, on the user terminal 30, setting screens corresponding to each of a plurality of payment methods available on the user terminal 30. In Modification 1-11, two payment methods are given as examples: a method in which the store terminal 40 reads the code C10 described in the first embodiment, and a method in which the user terminal 30 reads a code displayed on the store terminal 40 described in Modification 1-3. The display control unit 101 is capable of displaying each of 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] The display control unit 101 in variant example 1-11 displays a setting screen corresponding to one of a plurality of payment methods on the user terminal 30 so that settings specified on the setting screen corresponding to the other payment methods are carried over to the setting screen corresponding to the other payment methods. For example, when the display control unit 101 displays the confirmation screen SC5 after settings such as installment payment are specified on the code screen SC1, the display control unit 101 displays the confirmation screen SC5 showing the same settings as the settings such as installment payment on the code screen SC1 on the user terminal 30. When the display control unit 101 displays the code screen SC1 after settings such as installment payment are specified on the confirmation screen SC5, the display control unit 101 displays the code screen SC1 showing the same settings as the settings such as installment payment on the confirmation screen SC5 on the user terminal 30.

[0258] The processing execution unit 102 of Modification 1-11 executes processing for a payment method based on the settings of installment payments, etc. specified on the setting screen corresponding to each of the multiple payment methods. Although this differs from the first embodiment in that the settings of installment payments, etc. are carried over between setting screens, the processing of installment payments, etc. itself is the same as that of 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] [Variation 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 specifies a setting such as installment payment and makes a payment, the user may want to know whether the terms of use were met and the payment was processed as installment payment, or whether the terms of use were not met and the payment was not processed as installment payment, etc. Therefore, in variant example 2-2, a case where the processing result of the processing execution unit 201 is notified to the user is taken as an example.

[0271] The payment system 1 of variant 2-2 includes a processing result notifying unit 111. The processing result notifying unit 111 notifies the user of the payment app 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 is a notification indicating whether or not the terms of use have been satisfied, or a notification indicating whether or not the user's payment has been processed as an installment payment, etc.

[0272] FIG. 25 is a diagram showing an example of a processing result notification. For example, processing result notification unit 111 notifies the user of the processing result using the notification function of the payment app. Processing result notification unit 111 displays a notification screen SC8 on user terminal 30, which shows notifications from the notification function of the payment app. Various notifications from the payment app are displayed on notification screen SC8. In variant example 2-2, processing result notification unit 111 displays a notification screen SC8 including a processing result notification on user terminal 30, as one of the notifications from the payment app. In the example of FIG. 25, the processing result notification includes a message indicating whether the payment for which the user specified settings such as installment payment has been processed as installment payment.

[0273] As in the second embodiment, when the card server 20 determines the terms of use and performs processing according to the determination result, the settlement server 10 receives processing result data indicating the processing result by the card server 20 from the card server 20. The processing result data includes payment identification information (e.g., an ID assigned to each payment) that identifies the payment processed by the processing execution unit 201, and processing information indicating whether the payment has been processed as an installment payment or the like (i.e., information indicating whether the terms of use have been met).

[0274] For example, the processing result notifying unit 111 notifies the user of the processing result based on the processing result data. The processing result notifying unit 111 refers to the usage information stored in the payment database and identifies the user who made the payment indicated by the payment identification information included in the processing result data. The processing result notifying 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 the user. The processing result notifying unit 111 notifies the user of the processing result indicating the identified processing result. When the payment server 10 determines the use conditions, the processing result notifying unit 111 acquires the processing result of the processing execution unit 102 according to the determination result of the use conditions by the use condition determination unit 109 described below, and notifies the user of the processing result.

[0275] The processing result notification may be performed by a notification means other than the notification function of the payment app. For example, the processing result notification unit 111 may notify the user of the processing result by email, an SMS message, a message in a messaging app, a message on an SNS, a message in an app other than the payment app, a push notification, a pop-up notification, or a banner notification. Even when the processing result notification unit 111 notifies the user of the processing result by another notification means, the processing result notification unit 111 may identify how the payment of each user was processed based on the processing result data, and provide the user with a processing result notification indicating the specified execution result.

[0276] The payment system 1 of Variation 2-2 notifies the user of the payment app of the processing result of the processing execution unit 201. This allows the user to know how the payment for which the user has specified a setting such as installment payment has been processed, and therefore the payment system 1 can effectively improve user convenience.

[0277] [Variation 2-3] For example, in the second embodiment, a case is given in which payment of the price is initially processed as a lump sum payment, and then, if the terms of use are satisfied, the lump sum payment is changed to installment payments or the like. Whether or not the terms of use are satisfied may be determined when an instruction to pay the price is given. The determination of the terms of use, which is made when an instruction to pay the price is given, may be performed by card server 20, but in modified example 2-3, a case is given in which the determination is made by payment server 10.

[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 of the price is instructed. For example, the payment server 10 receives a payment request from the store terminal 40, similar to the second embodiment. The payment request includes at least a portion of the usage information (for example, a store ID and a payment amount). When the payment server 10 receives the 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 of the usage information that is not included in the payment request from the payment database DB1.

[0279] For example, when payment of the price is instructed, the usage condition determination unit 109 determines whether the usage conditions are satisfied. The usage condition determination unit 109 determines whether the usage conditions are satisfied based on at least a part of the usage information included in the payment request. In variant 2-3, the data storage unit 100 stores the usage condition data described in the second embodiment. The usage condition determination unit 109 realized by the payment server 10 determines whether the usage conditions are satisfied based on the usage condition 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 usage condition 1 is satisfied by determining whether the store is non-compliant 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 credit limit, and determines whether usage condition 2 is satisfied by determining whether the credit limit is exceeded by the usage amount included in the payment request. The usage condition determination unit 109 determines whether usage condition 3 is satisfied by determining whether the usage amount included in the payment request is equal to or greater than a predetermined amount.

[0281] The process execution unit 102 in modification 2-3 executes a process such as installment payment based on the determination result of the use condition determination unit 109. For example, the process execution unit 102 executes a process such as installment payment for payment of a price based on the determination result of the use condition determination unit 109 executed when an instruction to pay the price is given. If it is determined that the use conditions are not met, the process execution unit 102 does not execute a process such as installment payment. As another example, if it is determined that the use conditions are not met, the process execution unit 102 may change the installment payment to a lump sum payment and execute payment as usual.

[0282] For example, when it is determined that the terms of use are satisfied, the process execution unit 102 executes a process such as installment payment. As in the second embodiment, the process execution unit 102 may first process a lump-sum payment, or may execute a process for installment payment with the card server 20 at the time of processing the payment request. The method by which the process execution unit 102 executes a process for installment payment with the card server 20 may be the same as a method adopted in a known card service. For example, the process execution unit 102 may process installment payment at the time of payment execution by transmitting to the card server 20 data for installment payment (for example, data indicating that installment payment is applicable and that installment payment is set) in a format defined by the API of the card service.

[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 variants 2-3 and 2-4, if payment of the price is instructed and the terms of use are not met, an inquiry may be made as to whether to change to a lump-sum payment and process the payment. The user operates the user terminal 30 to input a response to the inquiry. Depending on the user's response, payment may be processed by changing from installment payment to a lump-sum payment. For example, if the credit limit for installment payment is insufficient, the payment system 1 may suggest to the user, "Do you want to change to installment payment?" as part of the inquiry.

[0290] The payment system 1 of variation 2-5 includes a change inquiry unit 114 and a response execution unit 115. When an instruction to pay the price is given and it is determined that the terms of use are not satisfied, the change inquiry unit 114 makes a change inquiry on the user terminal 30 as to whether or not to change the payment method from installment payment to another payment method. The other payment method is a payment method changed to a lump sum payment while keeping the current payment source, or a payment method changed to another payment source.

[0291] FIG. 27 is a diagram showing an example of a change inquiry. For example, when payment of the price is instructed and it is determined that the terms of use are not satisfied, the change inquiry unit 114 displays a window W14 on the code screen SC1, inquiring whether or not to change to another payment method. The change inquiry unit 114 displays the window W14 on the code screen SC1 by transmitting display data for the window W14 to the user terminal 30. The window W14 includes a button B140 indicating that the payment method should be changed to another payment method, and a button B141 indicating that the payment method should not be changed to another payment method. In the example of FIG. 27, the change inquiry unit 114 makes a change inquiry as to whether or not to change to 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] The process execution unit 102 in modification 2-7 executes the process for charging based on the determination result of the use condition determination unit 109. If it is determined that the use conditions are not satisfied, the process execution unit 102 does not execute the process for installment payment or the like for charging, and if it is determined that the use conditions are satisfied, the process execution unit 102 executes the process for installment payment or the like for charging. For example, the process execution unit 102 executes the process for installment payment or the like by executing the payment for charging as installment payment or the like. As with payment of the price, the process execution unit 102 may execute the process for payment at the time of charging as a lump sum payment for the time being and then change to payment in installments or the like later.

[0305] The payment system 1 of Variation 2-7 acquires usage information for charging using a payment method. Based on the usage information, the payment system 1 determines whether the usage conditions for charging are met. Based on the result of this determination, the payment system 1 executes processing for charging. This allows the payment system 1 to prevent unintended installment payments, etc. from being executed when charging, thereby improving user convenience.

[0306] [Variation 2-8] For example, the usage conditions may be a condition as to whether or not recharging by installment payments or the like is permitted. Similar to the variation 2-7, variation 2-8 also takes as an example a case in which the usage condition determination unit 109 and the usage information acquisition unit 112 are implemented in the payment server 10. Variation 2-8 takes as an example a case in which whether or not recharging by installment payments or the like is permitted is set for each user as a usage condition other than the specific card company and recharging amount described in variation 2-7. For example, the operator of the payment service may specify for each user whether or not recharging by installment payments or the like is permitted. In this case, it is assumed that the payment database DB1 stores permission information associated with the user ID and indicating whether or not recharging by installment payments or the like is permitted.

[0307] When a charge using a payment means is instructed, the use condition determination unit 109 of the payment server 10 determines whether the use conditions are satisfied by determining whether installment payments or the like are permitted for the charge. For example, the use condition determination unit 109 determines whether the use conditions are satisfied by determining whether the permission information stored in the payment database DB1 indicates permission. If the permission information does not indicate permission, the use condition determination unit 109 determines that the use conditions are not satisfied, and if the permission information indicates permission, the use condition determination unit 109 determines that the use conditions are satisfied.

[0308] In the payment system 1 of Variation 2-8, when a charge using a payment method is instructed, the payment system 1 determines whether the terms of use are met by determining whether installment payments, etc. are permitted for the charge. This allows the payment system 1 to determine whether the terms of use are met in real time at the time of charge, thereby effectively improving user convenience.

[0309] [Variation 2-9] For example, as explained somewhat in Modification 2-7, the usage conditions may be that a specific payment method corresponding to installment payments or the like is used. Modification 2-9 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. The data storage unit 100 stores data that can identify payment methods that support installment payments or the like as usage condition data. In Modification 2-9, it is assumed that information that can identify the payment method used by the user is indicated in the usage information. The process by which the usage information acquisition unit 112 acquires 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 satisfied by determining whether the payment method in the user terminal 30 supports installment payments, etc., based on the usage information. For example, the usage condition determination unit 109 determines whether the payment method indicated by the usage information supports installment payments, etc., based on the usage condition data. 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 satisfied. 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 satisfied.

[0311] In Modification 2-9, the process execution unit 102 does not execute the process for installment payment, etc., if it is determined that the payment method supports installment payment, etc. The process execution unit 102 executes the process for installment payment, etc., if it is determined that the payment method supports installment payment, etc. As in the second embodiment, when installment payment, etc. is used to pay the price, the process execution unit 102 executes the process for installment payment, etc., for paying the price, if it is determined that the payment method supports installment payment, etc. As in Modification 2-7, when installment payment, etc. is used to charge, the process execution unit 102 executes the process for installment payment, etc., for charging, if it is determined that the payment method supports installment payment, etc.

[0312] The payment system 1 of Variation 2-9 determines whether the conditions for use are met by determining whether the payment method supports installment payments, etc., on the user terminal 30 based on the usage information. This allows the payment system 1 to prevent installment payments, etc., from being made 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 in the second embodiment as usage condition 2, the usage condition determination unit 203 may determine whether the usage condition is satisfied by determining whether the usage is within the usage limit for installment payments, etc., based on the usage information. This point is as explained in the second embodiment.

[0318] The payment system 1 of Variation 2-12 determines whether the usage conditions are met by determining whether the usage is within the usage limit for installment payments, etc., based on the usage information. This allows the payment system 1 to prevent installment payments, etc., from being made in a range that exceeds the user's usage limit.

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

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

[0321] [5-3. Modifications of the Third Embodiment] 28 is a diagram showing an example of functions realized in a modification 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 cancellation condition for canceling the setting of installment payments, etc. is not limited to the example in the third embodiment. In Modification 3-1, an example is given in which the cancellation condition corresponds to the store being 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 supporting store information indicating whether the store is a supporting store or a non-supporting store.

[0323] The setting cancellation unit 105 in Modification 3-1 determines whether the cancellation condition is met by determining whether the store is a non-supporting store that does not support installment payments, etc., and cancels the setting of installment payments, etc. if it is determined that the store is a non-supporting store. In Modification 3-1, as in the third embodiment, an example is given in which payment is made by reading the code C10 displayed on the user terminal 30 with 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 acquires the setting of installment payment, etc. associated with the code ID from the payment database DB1. If the acquired setting of installment payment, etc. indicates that installment payment, etc. will not be performed, or if the setting of installment payment, etc. does not exist in the payment database DB1, the setting cancellation unit 105 does not perform the process of determining whether to cancel the setting of installment payment, etc. In this case, a lump-sum payment will be made as usual.

[0325] For example, when the acquired settings for installment payments or the like indicate that installment payments or the like will be made, the setting cancellation unit 105 performs processing to determine whether or not to cancel the settings for installment payments or the like. The setting cancellation unit 105 references the compatible store information stored in the store database and acquires the compatible store information associated with the store ID included in the payment request received from the store terminal 40. When the compatible store information indicates a compatible store, the setting cancellation unit 105 does not cancel the settings for installment payments or the like. In other words, when the compatible store information does not indicate a non-compatible store, the setting cancellation unit 105 does not cancel the settings for installment payments or the like. The settings for installment payments or the like that have not been canceled may be used as is for the next payment or charge or thereafter.

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

[0327] The payment system 1 of variation 3-1 determines whether the cancellation condition is met by determining whether the store is a non-supporting store that does not support installment payments, etc., and cancels the setting if it is determined that the store is a non-supporting store. This allows the payment system 1 to prevent installment payments, etc. from being made when payment for an incompatible price is executed.

[0328] [Variation 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 payment system 1 of Variation 3-2, before payment of the price is instructed, the payment system 1 cancels the setting of the installment payment, etc. based on the cancellation conditions. This prevents the payment system 1 from executing the installment payment, etc., even though the installment payment, etc. is not available.

[0335] [Variation 3-3] For example, in the third 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. In variant example 3-3, an example is given where a user uses installment payment or the like to charge. The meaning of installment payment or the like in charge is as explained in variant examples 1-4 and 2-7. The setting acquisition unit 104 in variant example 3-3 acquires settings for installment payment or the like in charge using a payment method. In variant example 3-3, as in variant example 1-4, settings for installment payment or the like in charge are stored in the payment database DB1. The setting acquisition unit 104 acquires settings for installment payment or the like in charge from the payment database DB1.

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

[0337] The setting cancellation unit 105 of Modification Example 3-3 cancels the setting of installment payments, etc. for charging based on the cancellation condition. If the cancellation condition corresponds to the charge amount being 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 condition specified by the user before the charge is executed. If the cancellation condition corresponds to the charge source being 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] [Variation 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] The setting cancellation unit 105 in Modification 3-4 may determine whether or not a charge has been made based on the processing result of the processing execution unit 102. If the processing execution unit 102 has not made a charge process, the setting cancellation unit 105 does not determine that a charge has been made, and if the processing execution unit 102 has made a charge process, the setting cancellation unit 105 determines that a charge has been made. If it is not determined that a charge has been made, the setting cancellation unit 105 does not cancel the setting of installment payment, etc. The setting of installment payment, etc. that has not been canceled may be used for the next or subsequent charge.

[0342] The payment system 1 of Variation 3-4 determines whether a charge has been made, thereby determining whether the cancellation condition has been met, and cancels the setting if it is determined that a charge has been made. This allows the payment system 1 to cancel the setting of installment payments, etc., every time a charge is made. For example, when there are few users who wish to use installment payments, etc., consecutively, the payment system 1 can improve user convenience.

[0343] [Variation 3-5] For example, the cancellation condition is not limited to the examples of the third embodiment and modifications 3-1 to 3-4. For example, the cancellation condition may be a change in the payment method used by the user terminal 30. The setting cancellation unit 105 determines whether the cancellation condition is met by determining whether the payment method used has been changed, and cancels the setting of installment payments, etc., if it is determined that the payment method used has been changed. The payment method used 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 cancels the installment payment settings if the payment source is changed from the first credit card "AAA card" to an unsupported payment method. The settings for installment payments, etc. before cancellation are stored in any location, such as the payment database DB1. Thereafter, if the payment source is changed from an unsupported payment method to the second credit card "AAA card," the setting cancellation unit 105 reapplies the stored settings for installment payments, etc. before cancellation. In other words, the setting cancellation unit 105 stores the settings for installment payments, etc. before cancellation in the payment database DB1.

[0361] For example, if the payment method used is the charge source, the setting cancellation unit 105 cancels the installment payment settings when the charge source is changed from the first credit card "AAA card" to an incompatible payment method. The settings for installment payments, etc. before cancellation are stored in any location, such as the payment database DB1. Thereafter, if the charge source is changed from an incompatible payment method to the second credit card "AAA card," the setting cancellation unit 105 reapplies the stored settings for installment payments, etc. before cancellation. In other words, the setting cancellation unit 105 stores the settings for installment payments, etc. before cancellation in the payment database DB1.

[0362] In the payment system 1 of Variation 3-8, when the payment means used is changed from one of multiple supported payment means to an unsupported payment means, the payment system 1 cancels the setting of installment payments, etc., and when it is subsequently determined that the payment means used has been changed from an unsupported payment means to one of multiple supported payment means, the payment system 1 re-applies the setting of installment payments, etc. This eliminates the need for the user to reset the setting of installment payments, etc., and therefore reduces the operational burden on the user, and effectively improves user convenience.

[0363] [Variation 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] [Variation 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] The process execution unit 102 in Modification 3-10 executes a process such as installment payment based on the first setting. The first setting is the same as the setting for installment payment in the third embodiment. For example, if the first setting does not indicate that installment payment will be used, the process execution unit 102 does not execute a process such as installment payment, and if the first setting indicates that installment payment will be used, the process execution unit 102 executes a process such as installment payment.

[0370] The setting cancellation unit 105 of Modification 3-10 cancels the first setting based on the second setting and the cancellation condition. For example, when the second setting indicates that the first setting should be canceled, the setting cancellation unit 105 cancels the first setting based on the cancellation condition. The process of canceling the first setting based on the cancellation condition may be the same as that of the third embodiment and any of Modifications 3-1 to 3-9. When the second setting indicates that the first setting should be canceled, the setting cancellation unit 105 does not perform a determination on the cancellation condition, and does not cancel the first setting.

[0371] The payment system 1 of variant example 3-10 acquires a first setting regarding whether or not installment payments, etc. are to be used, and a second setting regarding whether or not the first setting needs to be canceled. The payment system 1 executes processing for installment payments, etc., based on the first setting. The payment system 1 cancels the first setting based on the second setting and the cancellation conditions. This allows the user to specify whether or not to cancel the installment payment setting, so the payment system 1 can effectively improve user convenience.

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

[0373] FIG. 30 is a diagram showing an example of a setting cancellation notification. For example, the setting cancellation notification unit 116 issues the setting cancellation notification by displaying a message indicating that the setting of installment payment or the like has been canceled (in FIG. 30, the message is "Installment payment setting has been canceled...") on the completion screen SC3. The setting cancellation notification unit 116 identifies that the setting of installment payment or the like has been canceled based on the processing result by the setting cancellation unit 105. When the setting of installment payment or the like has been canceled, the setting cancellation notification unit 116 generates display data for the completion screen SC3 indicating that the setting has been canceled and transmits the display data to the user terminal 30. The setting cancellation notification unit 116 may be a function included in the display control unit 101.

[0374] The setting cancellation notification may be sent by a notification means other than the completion screen SC3. For example, the setting cancellation notification unit 116 may notify the user of the setting cancellation by a notification from the notification function of the payment app, an email, an SMS message, a message from a messaging app, a message from an SNS, a message in an app other than the payment app, a push notification, a pop-up notification, or a banner notification. Even when the setting cancellation notification unit 116 sends the setting cancellation notification by another notification means, the setting cancellation notification unit 116 may specify that the installment payment setting has been canceled according to the processing result of the setting cancellation unit 105, and send the setting cancellation notification to the user.

[0375] When the setting of installment payment, etc. is canceled, the payment system 1 of Variation 3-11 sends a setting cancellation notice to the user regarding the cancellation of the setting of installment payment, etc. This makes it easier for the user to notice that the setting of installment payment, etc. has been canceled, and the payment system 1 can effectively improve 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] [Variation 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 specif...

Claims

1. a usage information acquisition unit that acquires usage information regarding the use of payment methods available on the user terminal; a usage condition determination unit that determines whether or not a usage condition related to the use of the payment method such as installment payment, revolving payment, or bonus payment is satisfied based on the usage information; a processing execution unit that executes processing related to the installment payment, the revolving payment, or the bonus payment based on a determination result of the use condition determination unit; Payment systems, including:

2. the usage information acquisition unit acquires the usage information in payment for goods or services provided by a store where the payment method can be used, the use condition determination unit determines whether the use conditions for the payment of the price are satisfied based on the use information; the processing execution unit executes the processing for the payment of the price based on the determination result of the use condition determination unit. The payment system according to claim 1 .

3. When the payment of the price is instructed, the processing execution unit processes the payment of the price as a lump sum payment in the same manner as when the installment payment, the revolving payment, or the bonus payment is not designated, and executes the processing to change the payment to the installment payment, the revolving payment, or the bonus payment. The payment system according to claim 2 .

4. When it is determined that the conditions of use are not satisfied, the processing execution unit processes the payment as a lump sum payment without executing the processing for changing the payment to the installment payment, the revolving payment, or the bonus payment. The payment system according to claim 3 .

5. the payment system further includes a processing result notifying unit that notifies a user of the user terminal of a processing result of the processing execution unit.

5. The payment system according to claim 3 or 4.

6. the use condition determination unit determines whether the use conditions are satisfied when an instruction to pay the fee is given; the processing execution unit executes the processing for the payment of the price based on a determination result of the use condition determination unit executed when an instruction to pay the price is given. A payment system according to any one of claims 2 to 4.

7. The settlement system further includes a payment notification unit that, when payment of the price is instructed and it is determined that the terms of use are not satisfied, issues a payment notification regarding the installment payment, the revolving payment, or the bonus payment to the user of the user terminal. The payment system according to claim 6.

8. The payment system includes: a change inquiry unit that, when an instruction to pay the price is given and it is determined that the terms of use are not satisfied, makes a change inquiry on the user terminal as to whether or not to change the installment payment, the revolving payment, or the bonus payment in the payment of the price to another payment method; a response execution unit that executes processing in accordance with a response to the change inquiry; The payment system of claim 6 further comprising:

9. the usage information acquisition unit acquires store information related to the store as the usage information; The use condition determination unit determines whether the use condition is satisfied by determining whether the store supports the installment payment, the revolving payment, or the bonus payment based on the store information. A payment system according to any one of claims 2 to 4.

10. the usage information acquisition unit acquires the usage information for charging using the payment means, the use condition determination unit determines whether the use conditions for the charge are satisfied based on the use information; the processing execution unit executes the processing for the charge based on the determination result of the use condition determination unit. A payment system according to any one of claims 1 to 4.

11. the use condition determination unit, when instructed to charge using the payment means, determines whether the installment payment, the revolving payment, or the bonus payment in the charge is permitted, thereby determining whether the use condition is satisfied; A payment system according to any one of claims 1 to 4.

12. The use condition determination unit determines whether the use conditions are satisfied by determining whether the payment method at the user terminal supports the installment payment, the revolving payment, or the bonus payment based on the use information. A payment system according to any one of claims 1 to 4.

13. the use condition determination unit determines whether the use condition is satisfied by determining whether the usage amount at the user terminal is equal to or greater than a predetermined amount based on the usage information; A payment system according to any one of claims 1 to 4.

14. When appropriation is made by a payment means other than the payment means, the use condition determination unit determines whether or not a value obtained by subtracting the amount appropriated by the other payment means from the use amount is equal to or greater than the predetermined amount. The payment system of claim 13.

15. The use condition determination unit determines whether the use is within a limit for the installment payment, the revolving payment, or the bonus payment, based on the use information, thereby determining whether the use condition is satisfied. A payment system according to any one of claims 1 to 4.

16. the use condition determination unit determines whether at least some of the use conditions are satisfied based on the use information when payment is made using the user terminal; A payment system according to any one of claims 1 to 4.

17. a usage information acquisition step of acquiring usage information regarding the use of payment methods available at the user terminal; a use condition determination step of determining whether or not a use condition relating to the use of installment payment, revolving payment, or bonus payment of the payment means is satisfied based on the use information; a processing execution step of executing processing related to the installment payment, the revolving payment, or the bonus payment based on a determination result of the use condition determination unit; Payment methods including.

18. a usage information acquisition unit that acquires usage information regarding the use of payment methods available on the user terminal; a usage condition determination unit that determines whether or not a usage condition relating to the use of the installment payment, revolving payment, or bonus payment of the payment means is satisfied based on the usage information; a processing execution unit that executes processing related to the installment payment, the revolving payment, or the bonus payment based on the determination result of the use condition determination unit; A program that allows a computer to function as a

Images