Payment systems, payment methods, and programs

Abstract

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

Description

Technical Field

[0005]

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

Background Art

[0002] Conventionally, a payment service provided by a payment application stored in a user terminal is known. For example, in Patent Document 1, when a user purchases a product or service sold by a specific member who subscribes to a payment service in installments, a split interest burden ticket for making the member bear the fee is acquired in the payment application, and a payment system that makes installment payments using the split interest burden ticket is described.

Prior Art Documents

Patent Documents

[0003] <000​​​​​​​​​​​​​​​​​​​​​​ The payment system relating to this disclosure includes a setting acquisition unit that acquires settings for installment payments, revolving payments, or bonus payments of payment methods available to the user; a processing execution unit that performs processing related to the installment payments, revolving payments, or bonus payments based on the settings; and a setting cancellation unit that cancels the settings based on predetermined cancellation conditions. [Effects of the Invention]

[0007] This disclosure can improve user convenience. [Brief explanation of the drawing]

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

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

[0010] [1-1. Hardware configuration of the payment system in the first embodiment] Figure 1 shows an example of the hardware configuration of a payment system according to the first embodiment. For example, the payment system 1 of 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, card server 20, user terminal 30, and 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, card server 20, user terminal 30, and store terminal 40.

[0011] The payment server 10 is a server computer for payment services. The payment service is a service that provides electronic payments (cashless payments) to users. For example, the payment server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes at least one of volatile memory such as RAM and 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 the server computer for the card service. The card service is a service operated by the administrator of the cards usable in the payment service (for example, the card company that issued the 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 storage unit 22, and a communication unit 23. The hardware configuration of the control unit 21, the storage unit 22, and the communication unit 23 may be the same as that of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

[0013] The user terminal 30 is the user's computer. For example, the user terminal 30 is a smartphone, tablet, personal computer, or wearable device. The user terminal 30 includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit 34, a display unit 35, and a camera unit 36. The hardware configuration of the control unit 31, the storage unit 32, and the communication unit 33 may be the same as that of the control unit 11, the storage 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. The camera unit 36 ​​includes at least one camera.

[0014] The store terminal 40 is a store computer 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 may be a POS terminal, a self-checkout system, a handheld terminal, a smartphone, a tablet, or a personal computer. The store terminal 40 includes a control unit 41, a storage unit 42, a communication unit 43, an operation unit 44, a display unit 45, and a reading unit 46. The hardware configuration of the control unit 41, storage unit 42, communication unit 43, operation unit 44, and display unit 45 may be the same as that of the control unit 11, storage unit 12, communication unit 13, operation unit 34, and display unit 35, respectively. The reading unit 46 includes at least one code reader or reader / writer. The reading unit 46 may also include at least one camera.

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

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

[0017] [1-2. Overview of the First Embodiment] In the first embodiment, we take the example of a payment service that supports multiple payment methods. A payment method is a means used for payment. A payment method includes payment methods that can be set as the charge source and payment source, as described later. For example, a payment method may be various cards such as credit cards, electronic money, points, crypto assets, wallets, bank accounts, or other means. Codes such as barcodes or two-dimensional codes are also considered payment methods because they are means for payment. A payment method can also be called a payment method because it may be used to pay for goods or services provided by a store (hereinafter simply referred to as payment). A payment service may support only one payment method instead of multiple payment methods.

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

[0019] Figures 2 and 3 show examples of payment application screens. For example, when the payment application is launched, as shown in the upper left of Figure 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. Code C10 is at least one of a barcode and a two-dimensional code. When code C10 is read by the reader unit 46 of the store terminal 40, payment is executed based on the code ID obtained from code C10. The basic flow of payment itself may be the same as that of known payment services.

[0020] Furthermore, payment may be performed by methods other than having the store terminal 40 read code C10. For example, payment may be of a type in which the user terminal 30 reads a code displayed on the store terminal 40, a type in which the user terminal 30 reads a code posted in the store, a type that is completed solely by operations on the user terminal 30, a type that utilizes the IC chip of the user terminal 30, online payment (for example, account payment using the user's account, ID payment using the user's ID), carrier payment which is payment from the carrier used by the user terminal 30, or other types. Alternatively, for example, payment may be performed by the user reading the code on the invoice with the user terminal 30 and paying the invoice.

[0021] For example, a user can select any payment method from among the multiple payment methods available in a payment app as the source of payment. The source of payment is the payment method that the user uses to pay for the goods or services. The source of payment can also be described as the payment method that provides the funds for the payment. If a payment app does not support multiple payment methods and only supports one, the user does not need to specifically select a source of payment. In other words, if the payment app is limited to one available payment method, the user does not need to specifically select a source of payment. The user can also set a priority order for the multiple payment methods available in the payment app, so that the source of payment automatically switches according to the set priority order.

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

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

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

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

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

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

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

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

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

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

[0032] [1-3. Functions realized in the payment system of the first embodiment] Figure 4 shows an example of the functions realized in the payment system 1 of the first embodiment. The components realized in the payment system 1 of the first embodiment can be configured by combining them into a single device, or by further distributing them among multiple devices.

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

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

[0035] Figure 5 shows an example of the payment database DB1. The payment database DB1 is a database that stores various information about users in a payment service. For example, the payment database DB1 stores user ID, password, code ID, payment method information, payment source information, charge source information, installment payment settings, and usage information. The information stored in the payment database DB1 is not limited to the example in Figure 5. Other information may also be stored in the payment database DB1.

[0036] A User ID is an example of user identification information that can identify a user. A separate login account may exist in addition to the User ID. Users may be able to freely change their login account. The login account is also an example of user identification information. A password is information that is verified during login. A 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 Code C10 is displayed. User identification information may include other information besides 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 may include credit card numbers, electronic money numbers, bank account information, or point card numbers. Payment source information is information that can identify the payment method selected as the payment source. Charge source information is information that can identify the payment method selected as the charge source. Charging is the process of increasing the balance of a payment method that has a balance. The charge source is the payment method used for charging. It is the 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 the payment app. Charging may also be the process of increasing the balance of a payment method other than electronic money.

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

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

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

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

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

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

[0044] For example, the display control unit 101 displays a payment source selection screen SC2 on the user terminal 30, which accepts the user's specification of settings related to installment payments and other payment methods available on the user terminal 30. In the first embodiment, since the user can use installment payments and other payment methods for payment, the display control unit 101 displays a payment source selection screen SC2 on the user terminal 30, which accepts the user's specification of settings for payment to stores where the payment method is available. The payment source selection screen SC2 is an example of a settings screen. Therefore, any section describing the payment source selection screen SC2 can be read as a settings screen. The payment source selection screen SC2 may also be a screen that allows the user to switch payment sources (payment methods) and set their priority. 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 settings screen is a user interface screen that accepts the specification of settings such as installment payments. The settings screen may include any part of the user interface. For example, the settings screen may include panels, buttons, checkboxes, sliders, other input forms, icons, links, text, or other images. In the first embodiment, the settings screen may be any screen on the user terminal 30. The settings screen is not limited to the payment source selection screen SC2. For example, the settings screen may be the home screen, the code screen SC1, the payment in progress screen (payment confirmation screen, for example, the confirmation screen SC5 described later), the completion screen SC3, a screen dedicated to setting installment payments, the payment app usage history screen, or any other screen. The settings screen may also be any screen other than the payment app. For example, the screen displayed on the browser of the user terminal 30 shown below may correspond to the settings screen.

[0046] In the example shown in Figure 2, when a user selects panel P11 on the code screen SC1, the user terminal 30 sends a request to the payment server 10 to display the payment source selection screen SC2. 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 request to display the payment source selection screen SC2 from the user terminal 30, the display control unit 101 obtains the payment method information and payment source information of the user who made the request to display the payment source selection screen SC2 from the payment database DB1, and generates display data for the payment source selection screen SC2. The display control unit 101 sends the display data for the payment source selection screen SC2 to the user terminal 30, thereby displaying the payment source selection screen SC2 on 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 the 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 should determine which user's payment method information and payment source information should be retrieved based on the user ID or other information included in the display request. The data showing the basic layout of the payment source selection screen SC2 is stored in the data storage unit 100. The display control unit 101 should generate the display data for the payment source selection screen SC2 by inserting text, images, etc., corresponding to the payment method information and payment source information into the layout shown by the data.

[0048] Furthermore, the display control unit 101 may include a script for displaying modal M21 in the display data of the payment source selection screen SC2. The script contains code indicating that modal M21 should be displayed when panel P20, which allows installment payments, is selected. The user terminal 30 may execute the script to display modal M21 superimposed on the payment source selection screen SC2 without communicating with the payment server 10. Alternatively, the display control unit 101 may not include a script in the display data of the payment source selection screen SC2, but instead communicate with the user terminal 30 when the user selects panel P20 to display modal M21 superimposed on the payment source selection screen SC2. Alternatively, the display control unit 101 may display modal M21 superimposed on the payment source selection screen SC2 by executing program code included in the payment application instead of a script.

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

[0050] Processing related to installment payments is processing that is directly or indirectly related to installment payments. For example, processing related to installment payments may include processing to request installment payments from the card server 20, processing to determine the amount of each installment payment, processing to determine the fees for installment payments, processing to generate usage information indicating that the payment is subject to installment payments, or other processing. Processing related to installment payments may include simply storing data (data related to installment payments, etc.) in the settlement server 10, or transmitting data (data related to installment payments, etc.) to the card server 20. In the first embodiment, we take as an example the case where payment is initially processed as a lump sum payment and then changed from a lump sum payment to installment payments by the card server 20. Therefore, the processing execution unit 102 executes the processing to generate usage information indicating that the payment is subject to installment payments as processing related to installment payments. The processing execution unit 102 stores the usage information in the settlement database DB1 and, at any time thereafter, transmits the usage information to the card server 20 to request a change from a lump sum payment to installment payments. All or part of this series of processing may correspond to processing related to installment payments. Usage information includes information regarding payments or charges, and information regarding the setting of specified installment payments, etc. This information may be transmitted to the card server 20 simultaneously or at different times. The same applies to revolving credit and bonus payments.

[0051] Processing related to revolving payments is processing that is directly or indirectly related to revolving payments. For example, processing related to revolving payments may include processing to request revolving payments from the card server 20, processing to determine the payment amount or number of installments in revolving payments, processing to determine the fees for revolving payments, processing to generate usage information indicating that the payment is subject to revolving payments, or other processing. In the first embodiment, we take as an example the case where payment is initially processed as a lump-sum payment and then changed from a lump-sum payment to revolving payments by the card server 20. Therefore, the processing execution unit 102 executes the processing to generate usage information indicating that the payment is subject to revolving payments as processing related to revolving payments. The processing execution unit 102 stores the usage information in the settlement database DB1 and, at any time thereafter, sends the usage information to the card server 20 to request a change from a lump-sum payment to revolving payments. All or part of this series of processing may correspond to processing related to revolving payments.

[0052] Processing related to bonus payments is processing that is directly or indirectly related to bonus payments. For example, processing related to bonus payments may include processing to request a bonus payment from the card server 20, processing to determine the payment amount for bonus payments, processing to determine the payment month for bonus payments, processing to generate usage information indicating that the payment is subject to bonus payments, or other processing. In the first embodiment, we take as an example the case where payment is initially processed as a lump-sum payment and then changed from a lump-sum payment to a bonus payment by the card server 20. Therefore, the processing execution unit 102 executes the processing to generate usage information indicating that the payment is subject to bonus payments as processing related to bonus payments. The processing execution unit 102 stores the usage information in the settlement database DB1 and, at any time thereafter, sends the usage information to the card server 20 to request a change from a lump-sum payment to a bonus payment. All or part of this series of processing may correspond to processing related to bonus payments.

[0053] For example, when the store terminal 40 reads code C10 on the code screen SC1 with the reading unit 46, it obtains a code ID from 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 that indicates 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 obtains payment source information and settings such as installment payments associated with the code ID shown in the payment request from the payment database DB1. Note that the payment source information and settings such as installment payments may be encoded in code C10 and included in the payment request. Also, as is the case with other embodiments and modifications, the payment server 10 may receive payment requests from the store terminal 40 or from the user terminal 30.

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

[0055] For example, if there is no setting for installment payments, the processing execution unit 102 will perform normal payment processing (processing of settlement data) that does not involve installment payments. This processing may follow the same flow as known payment services. For example, as part of normal payment processing, settlement data is transmitted from the settlement server 10 to the card server 20, the card server 20 receives the settlement data, records it a few days later (reflected in the user's statement), and processes the payment. The payment from the user to the card company is processed as a lump sum payment.

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

[0057] Furthermore, the linking of payment data and data for installment payments, etc., may be done separately or together simultaneously. The timing of determining whether installment payments are possible and recording them may be at any time. These may be done simultaneously, or the recording may be done after determining whether installment payments are possible. The determination of whether installment payments are possible may be made after the recording has been made. For example, if installment payments are possible after the determination of installment payments, the recording may be made as an installment payment, but if a payment is recorded as a lump sum payment and then determined to be possible as an installment payment, it may be changed to an installment payment.

[0058] For example, the processing execution unit 102 retrieves usage information for card payments made during a certain period (for example, a certain day) from the payment database DB1. The processing execution unit 102 sends the retrieved usage information to the card server 20 and requests that it be recorded in the card database DB2. Recording is the process of adding information to the credit card statement. The recording itself may be a process adopted by a well-known card service. The processing execution unit 102 may also immediately send the usage information to the card server 20 and request that it be recorded in the card database DB2 after performing the initial lump-sum payment processing. The card server 20 performs the recording in the card database DB2 through the processing of the processing execution unit 201 described later. At that time, the payment information for usage information that was initially processed as a lump-sum payment is changed to installment payments, etc., and recorded. As a result, the payment is processed in installments, etc.

[0059] The process of changing a lump-sum payment that has been initially executed to installment payments, etc., may be performed by the settlement server 10 instead of the card server 20. In this case, the processing execution unit 102 may execute the installment payment process by changing the initial lump-sum payment indicated in the usage information to installment payments, etc. The processing execution unit 102 transmits the usage information that has been changed to installment payments, etc., to the card server 20. When the card server 20 receives the usage information that has been changed to installment payments, etc., the processing execution unit 201, described later, performs accounting entries to the card database DB2 based on the usage information.

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

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

[0062] Figure 6 shows an example of the card database DB2. The card database DB2 is a database that stores various information about users in the card service. For example, the card database DB2 stores user IDs, passwords, card information, and usage information. The information stored in the card database DB2 is not limited to the example in Figure 6. Other information may also be stored in the card database DB2. For example, in addition to usage information, the card database DB2 may store information indicating the details of the transaction (i.e., information indicating the details of the credit card statement).

[0063] In the first embodiment, we take the example of a case where the user ID is the same for both 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 from each other. If the user ID for the payment service and the user ID for the card service are different from each other, a relational database showing the relationship between these user IDs is stored in the data storage unit 200. The relational database should be used to identify which user corresponds to 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 also be stored in another computer other than the payment server 10 or the card server 20, or on an external information storage medium.

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

[0065] [Processing Execution Unit] The processing execution unit 201 executes the installment payment and other processing performed by the user in the payment application. In the first embodiment, since payment is initially made in a lump sum, the processing execution unit 201 executes the card payment for the lump sum and stores the usage information in the card database DB2. Subsequently, the processing execution unit 201 executes the installment payment and other processing by changing the payment, which was initially made in a lump sum, to an installment payment and recording it. For example, the processing execution unit 201 may record the change from a lump sum payment to an installment payment and other processing indicated by the usage information stored in the card database DB2, or it may generate separate information for recording and store it in the card database DB2.

[0066] For example, when the card server 20 receives a request for accounting entry from the payment server 10 after obtaining usage information for card payments made during a certain period (for example, a certain day), the processing execution unit 201 changes the lump-sum payment indicated by the usage information to installment payments, etc. The processing execution unit 201 performs accounting entry for installment payments, etc. by storing the usage information that has been changed to installment payments, etc. in the card database DB2, or by generating accounting information and storing it in the card database DB2. If the change from lump-sum payment to installment payments, etc. is made on the payment server 10 side, the processing execution unit 201 may perform accounting entry by storing the usage information received from the payment server 10 directly in the card database DB2.

[0067] [1-3-3. Functions implemented on the user terminal] 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 implemented by a storage unit 32. The operation reception unit 301 and the display control unit 302 are implemented by a control unit 31.

[0068] [Data Storage Unit] The data storage unit 300 stores the data necessary for the user to use the payment service. For example, the data storage unit 300 stores the payment application. If the user uses the payment service from a browser instead of the payment application, the data storage unit 300 stores the browser.

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

[0070] [Display Control Unit] The display control unit 302 displays various screens on the display unit 35. For example, the display control unit 302 displays the code screen SC1, the payment source selection screen SC2, and the 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 implemented on store terminals] For example, the store terminal 40 includes a data storage unit 400 and a payment request transmission unit 401. The data storage unit 400 is implemented by a storage unit 42. The payment request transmission unit 401 is implemented by a control unit 41.

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

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

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

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

[0076] When the user terminal 30 selects panel P11, it performs a process with the settlement server 10 to display the payment source selection screen SC2 (S102). In S102, when the settlement server 10 receives a request from the user terminal 30 to display the payment source selection screen SC2, it generates display data for the payment source selection screen SC2 based on the payment method information and payment source information stored in the settlement 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 settlement server 10, it displays the payment source selection screen SC2 on the display unit 35.

[0077] When the user selects a panel P20 that shows cards eligible for installment payments, the user terminal 30 executes a process to display a modal M21 on the display unit 35 that accepts the specification of installment payment settings (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 that script. If the script is not included, the user terminal 30 may obtain the data for modal M21 from the payment server 10 and display modal M21. The process for displaying modal M21 may be shown in the payment application.

[0078] When the user terminal 30 receives a setting for installment payments or the like via modal M21, it performs a process with the payment server 10 to reflect the user's specified settings (S104). In S104, the user terminal 30 sends data to the payment server 10 indicating the settings specified by the user. Upon receiving this data from the user terminal 30, the payment server 10 stores the settings indicated by the data in the payment database DB1, associating them with the user's user ID. Subsequently, the user terminal 30 performs a process with the payment server 10 to display the code screen SC1 on the display unit 35 again (S105). The process in S105 is the same as the process in S101.

[0079] When the code C10 on the code screen SC1 is read by the reader unit 46, the store terminal 40 sends a payment request to the payment server 10 based on the code ID obtained from code C10 (S106). When the payment server 10 receives the payment request from the store terminal 40 (S107), it performs payment processing for card payment with the card server 20 (S108). In S108, it is initially processed as a lump-sum payment.

[0080] The payment server 10 retrieves the installment payment settings stored in the payment database DB1 (S109). The payment server 10 executes the installment payment processing based on the installment payment settings specified by the user (S110). In S110, if the installment payment settings indicate the use of installment payments, the payment server 10 generates usage information indicating that the payment is subject to installment payments, 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 also show details of the settings, such as the number of installments.

[0081] The payment server 10 performs a process with the user terminal 30 to display the completion screen SC3 on the display unit 35 (S111), and this process 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 sends 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. Subsequently, the payment server 10 performs a process with the card server 20 to change the payment method from a lump sum payment to an installment payment or the like.

[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 such as installment payments. The payment system 1 executes the installment payment process based on the settings for installment payments. As a result, the user can use installment payments from the payment app, and the payment system 1 can improve user convenience. For example, the user can use installment payments by using the payment app without having to prepare a physical card, so the user can use various payment methods with the payment app. The user can also complete the settings for installment payments on the user terminal 30, making it easy to use installment payments.

[0083] Furthermore, the payment system 1 displays a payment source selection screen SC2 on the user terminal 30, which accepts the user's specification of installment payment or other payment options for the payment of goods or services provided by the store. Based on the installment payment or other payment options, the payment system 1 executes the installment payment or other payment processing for the payment. As a result, users can use installment payments or other payment options from the payment app when making payments, thus improving the convenience for users when making payments. For example, users can use installment payments or other payment options by presenting the code screen SC1 of the payment app, without having to present a physical card at the store, thus enabling users to 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 related to this disclosure, will be described. In the second embodiment, the same configuration as in the first embodiment will not be described. 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, we take the example of a case where the installment payment or similar payment method available to the user through the payment app has terms and conditions of use. The terms and conditions of use are the criteria for determining whether or not the use of installment payment or similar payment methods from the payment app is permitted. The terms and conditions of use may be arbitrary conditions depending on the content of use from the payment app. Multiple terms and conditions of use may be set for installment payment or similar payment methods. For example, the terms and conditions of use may be whether or not payment is made for goods or services provided by a store that accepts installment payments, whether or not it is within the limits of the installment payment or similar payment method, whether or not the amount used is above a predetermined amount, or other conditions. The terms and conditions of use for installment payments, revolving payments, and bonus payments may be the same or different from each other. In addition, stores that accept installment payments may be determined based on the store's attribute information (for example, the industry or category to which the store belongs), or based on the store's credit information (for example, whether there has been any fraud in the past). The terms and conditions of use may be set by the user.

[0086] Figure 8 shows an example of processing performed in the payment system 1 of the second embodiment. In the second embodiment, as in the first embodiment, an example is given in which payment is initially processed as a lump sum payment, and then the lump sum payment is changed to installment payments or the like. Furthermore, an example is given in which the change from lump sum payment to installment payments is performed on the card server 20. The change from lump sum payment to installment payments or the like may be performed on the payment server 10, or on other computers other than the payment server 10 and the card server 20.

[0087] As shown in Figure 8, when the reading unit 46 of the store terminal 40 reads code C10 on the code screen SC1, 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 the same as explained in the first embodiment. Even if the payment application specifies settings such as installment payments, the store terminal 40 performs the same processing as a normal lump sum payment. Therefore, even if installment payments become possible in the payment application, no modifications are required on the store terminal 40 side, thus reducing the amount of work required for modifications.

[0088] For example, when a predetermined time (for example, a predetermined time on a given day) arrives, the settlement server 10 sends the usage information processed as a lump-sum payment to the card server 20 and requests that it process the transaction. As described in the first embodiment, the usage information for payments subject to installment payments, etc., is assumed to indicate that the payment is subject to installment payments, etc. When the card server 20 receives the usage information from the settlement server 10, it identifies the payment subject to installment payments, etc., based on the usage information. Based on the usage information for the payment subject to installment payments, etc., the card server 20 determines whether the usage conditions are met.

[0089] In the example shown in Figure 8, the card server 20 determines whether (Condition 1) the store to which the payment was made is a store that does not support installment payments, etc., (Condition 2) whether the transaction is within the limits of the installment payment limit (e.g., installment payment limit), and (Condition 3) whether the amount of the installment payment is equal to or greater than a predetermined amount (e.g., 50 yen). If the card server 20 determines that these conditions are met, it changes the lump-sum payment indicated in the transaction information to an installment payment, etc., and records it. If the card server 20 determines that these conditions are not met, it records the lump-sum payment indicated in the transaction information as a lump-sum payment without changing it to an installment payment, etc.

[0090] As described above, the payment system 1 of the second embodiment determines whether the conditions for using installment payments, etc., are met. Based on the result of this determination, the payment system 1 executes the process for installment payments, etc. This prevents installment payments, etc., from being made unintentionally by the user or administrator, thereby improving user convenience. The details of the second embodiment will be described below.

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

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

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

[0094] For example, if the payment system 1 of the second embodiment does not include the functions described in the first embodiment, the user may declare that they will use installment payments at the store. The user may also input that they will use installment payments through the payment app by operating on the store terminal 40. The store terminal 40 may send a payment request to the payment server 10 indicating that the user will use installment payments. The payment request shall also include information equivalent to setting the number of installments, etc. The payment server 10 may identify that the user will use installment payments based on the payment request. These points are also the same for the third and fourth embodiments described later.

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

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

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

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

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

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

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

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

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

[0104] [Usage information acquisition department] The usage information acquisition unit 202 acquires usage information regarding the use of payment methods available on the user terminal 30. In the second embodiment, the usage information is given as an example of a case where the usage information shows the content of past usage, but as shown in the modified example described later, the usage information may also show the content of future usage. The usage information acquisition unit 202 only needs to acquire usage information that shows the use of the payment application that is subject to the determination of usage conditions. The usage information acquisition unit 202 may acquire any number of usage information. For example, the usage information acquisition unit 202 may acquire usage information that shows multiple uses that occurred during a certain period. The usage information acquisition unit 202 may also acquire usage information for each of multiple users.

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

[0106] In the second embodiment, similar to the first embodiment, an example is given where payment corresponds to the use of a payment application. The usage information acquisition unit 202 acquires usage information for payment of goods or services provided by a store where the payment method is available. For example, the usage information shows information about the payment source used for payment (e.g., 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 also indicate whether or not it is subject to installment payments, or it may show details of installment payments (e.g., the number of installments).

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

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

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

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

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

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

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

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

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

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

[0117] The usage conditions determination unit 203 may determine only one or two of usage conditions 1 to 3. The usage conditions determination unit 203 may also determine other usage conditions other than usage conditions 1 to 3. For example, if only specific products or services are eligible for installment payments, the usage conditions determination unit 203 may determine whether the usage conditions are met by determining whether the product or service is eligible for installment payments. If there is a limit to the number of installment payments that a user can make in a certain period (for example, one month) (for example, 10 times per month), the usage conditions determination unit may determine whether the usage conditions are met by determining whether the limit on the number of uses has been reached.

[0118] [Processing Execution Unit] The processing execution unit 201 executes processing related to installment payments, etc., based on the determination result of the usage condition determination unit 203. If the processing execution unit 201 determines that the usage conditions are not met, it does not execute the installment payment processing, etc. If the processing execution unit 201 determines that the usage conditions are met, it executes the installment payment processing, etc. The processing execution unit 201 executes the installment payment processing, etc., on the condition that the usage conditions are met. The meaning of the installment payment processing, etc., may be the same as in the first embodiment. In addition, the processing execution unit 201 in the second embodiment may execute the same processing as in the first embodiment.

[0119] For example, if multiple usage conditions are defined, the processing execution unit 201 may not perform installment payment processing if it determines that at least some of the usage conditions are not met, and may perform installment payment processing if it determines that all of the usage conditions are met. The processing execution unit 201 may not perform installment payment processing if it determines that a predetermined number or more of the usage conditions are not met, and may perform installment payment processing if it determines that a predetermined number or more of the usage conditions are met.

[0120] In the second embodiment, as in the first embodiment, an example is given where payment corresponds to the use of a payment application. The processing execution unit 201 executes processing such as installment payments for payment based on the determination result of the usage condition determination unit 203. If the processing execution unit 201 determines that the usage conditions are not met, it does not execute processing such as installment payments for payment. If the processing execution unit 201 determines that the usage conditions are met, it executes processing such as installment payments for payment.

[0121] In the second embodiment, similar to the first embodiment, an example is given where a lump-sum payment is initially executed, and then the lump-sum payment is changed to installment payments or the like. The processing execution unit 201 executes the process for installment payments or the like in the payment of the price after the initial lump-sum payment has been executed. If the processing execution unit 201 determines that the usage conditions are not met, it processes the payment of the price as a lump-sum payment without changing it to installment payments or the like. If the processing execution unit 201 determines that the usage conditions are met, it processes the payment of the price by changing the lump-sum payment to installment payments or the like.

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

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

[0124] [2-3. Processing performed in the payment system of the second embodiment] Figure 10 shows an example of processing performed in the payment system 1 of the second embodiment. In Figure 10, processing related to the determination of usage conditions is explained among the processing performed in the payment system 1. For example, the processing in Figure 10 may be performed after the processing S100 to S111 described in the first embodiment has been performed. The processing in Figure 10 is performed by the control units 11 and 21 executing the programs stored in the storage units 12 and 22, respectively.

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

[0126] In S200, if it is determined that the time for recording usage information has arrived (S200:Y), the settlement server 10 retrieves the usage information subject to the usage condition determination from the settlement database DB1 (S201). In S201, the settlement server 10 retrieves the usage information from the settlement database DB1 that includes the usage date and time within the period from the most recent determination timing to the present. The settlement server 10 sends the usage information obtained in S201 to the card server 20 (S202). The card server 20 retrieves the usage information from the settlement server 10 (S203).

[0127] The card server 20 identifies payments that are eligible for installment payments, etc., 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 settlement server 10 changes the usage information for which the usage conditions are met from a lump sum payment to installment payments, etc., and records it (S205). If it is determined in S204 that the usage conditions are not met (S204:N), the settlement server 10 does not execute the process in S205 and records the usage information for which the usage conditions are met as a lump sum payment (S206).

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

[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 the usage conditions for installment payments, etc., are met. Based on the determination result of the usage conditions, the payment system 1 executes the installment payment, etc. process. As a result, the payment system 1 can use the determination of whether the usage conditions are met as a condition for executing the installment payment, etc. process, thereby preventing installment payments, etc., that were not intended by the administrator or user of the payment service, etc., and improving user convenience. From the perspective of the administrator or store, it is possible to prevent unintended installment payments, etc., from being executed, so the payment system 1 can improve convenience for the administrator and store. For example, the payment system 1 can prevent installment payments, etc., from being made at stores that do not support installment payments, etc. The payment system 1 can prevent installment payments, etc., that exceed the user's usage limit. The payment system 1 can prevent low-amount installment payments, etc., from being made.

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

[0131] Furthermore, when payment is requested, payment system 1 processes the payment as a lump sum payment, just as if installment payments were not specified, and then executes a process to change it to installment payments. This allows payment system 1 to provide users with installment payment functionality without modifying the store terminal 40. Payment system 1 can also improve user convenience because it can process the payment as a lump sum payment even if the usage conditions are not met.

[0132] [3. Third Embodiment] A third embodiment, which is an example of an embodiment of the payment system 1, payment method, and program relating to this disclosure, will be described. In the third embodiment, the same configuration as in the first or second embodiment will not be described. For example, the hardware configuration of the payment system 1 may be the same as in the first embodiment.

[0133] [3-1. Overview of the Third Implementation] In the third embodiment, an example is given where the setting for installment payments, etc., is automatically canceled based on predetermined cancellation conditions. The cancellation conditions are criteria for determining whether or not the setting for installment payments, etc., is canceled. The cancellation conditions may be any conditions defined in the payment service. Multiple conditions may be combined. For example, the cancellation conditions may be that the payment app is used with the setting for installment payments, etc., enabled, the payment app is terminated, the payment app moves from the foreground to the background, a predetermined amount of time has elapsed since the setting for installment payments, etc., was enabled, the expiration date set for the code ID has expired, or other conditions. The cancellation conditions may also be that the usage conditions are not met. If the usage conditions are not met, the setting for installment payments, etc., may be automatically canceled.

[0134] In the third embodiment, as in the first and second embodiments, an example is given where the user uses the payment service from a payment app. However, the user may use the payment service by means other than the payment app. For example, the user may display code C10 in 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 instead of the screen displayed on the user terminal 30 (e.g., contactless payment). The user may use a card (a physical card) such as an IC card or magnetic card instead of the user terminal 30. The user may use the payment service by biometric authentication without using the user terminal 30 or a card or other medium.

[0135] Figure 11 shows an example of processing performed in the payment system 1 of the third embodiment. In the third embodiment, an example is given where the condition for cancellation is that payment is made with the setting of installment payments specified. For example, when a user specifies the setting of installment payments in the same manner as in the first embodiment, the user terminal 30 displays a code screen SC1, which includes a panel P11 indicating that the setting of installment payments has been made, on the display unit 35, as shown in the upper left of Figure 11.

[0136] For example, when code C10 is read by the store terminal 40, the user terminal 30 displays a completion screen SC3 on the display unit 35, as shown in the upper right of Figure 11, indicating that payment has been completed. The completion screen SC3 may also indicate that the installment payment setting has been canceled. When the user performs an operation to return to the code screen SC1, the user terminal 30 displays a code screen SC1 on the display unit 35, including a panel P11 indicating that the installment payment setting has been canceled, as shown in the lower left of Figure 11. If the user wishes to use installment payments for the next payment, they specify the installment payment setting again in the same manner as in the first embodiment.

[0137] As described above, the payment system 1 of the third embodiment cancels the installment payment setting based on a cancellation condition, for example, when a payment is executed with the installment payment setting specified. This eliminates the need for the user to manually cancel the installment payment setting, thus reducing the user's operational burden and improving user convenience. The details of the third embodiment will be described below.

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

[0139] Furthermore, the payment system 1 of the third embodiment does not necessarily have to include at least one of the functions described in the first embodiment (for example, functions for displaying setting screens such as the payment source selection screen SC2) and the functions described in the second embodiment (for example, functions for determining usage conditions and related functions). For example, the payment system 1 of the third embodiment may perform installment payments, etc., for which no specific usage conditions are defined. The same applies to the fourth embodiment described later.

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

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

[0142] [Data Storage Unit] The data storage unit 100 may be the same as in the first or second embodiment. In the third embodiment, the data storage unit 100 may store release condition data indicating the release conditions. The release condition data may be in any format, for example, a table format, a mathematical formula format, part of a program, a machine learning model, or other format. In the example in Figure 11, the data storage unit 100 stores release condition data indicating that the setting should be released when a payment specified for installment payments, etc., is executed.

[0143] [Setting Acquisition Section] The setting acquisition unit 104 acquires settings related to installment payments and other payment methods available to the user. The functions of the setting acquisition unit 104 may be the same as those described as part of the functions of the processing execution unit 102 in the first embodiment. In the third embodiment, as in the first and second embodiments, an example is given where payment corresponds to the use of a payment application, so the setting acquisition unit 104 acquires settings such as installment payments for payment.

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

[0145] [Processing Execution Unit] The processing execution unit 102 executes processing related to installment payments, etc., based on the settings for installment payments, etc., acquired by the setting acquisition unit 104. In the second embodiment, as in the first embodiment, an example is given where payment of the price corresponds to the use of a payment application, so the processing execution unit 102 executes processing for payment of the 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 where a lump-sum payment is initially made, and then the lump-sum payment is changed to installment payments, etc.

[0146] [Settings Deactivation Section] The setting cancellation unit 105 cancels the setting for installment payments, etc., based on predetermined cancellation conditions. Canceling the setting for installment payments, etc., means changing the setting from a state indicating that installment payments, etc., will be used to a state indicating that installment payments, etc., will not be used. Canceling the setting for installment payments, etc., includes both cases: when the cancellation conditions are met, the setting for installment payments, etc., is canceled and remains canceled thereafter; or when the cancellation conditions are met, the setting for installment payments, etc., is temporarily canceled, but will not be canceled unless the cancellation conditions are met in the next use. For example, deleting the setting for installment payments, etc., stored in the settlement database DB1, or changing the setting for installment payments, etc., stored in the settlement database DB1 to a value indicating that installment payments, etc., will not be used, is equivalent to canceling the setting for installment payments, etc.

[0147] For example, the setting cancellation unit 105 will not cancel the installment payment setting if it is determined that the cancellation conditions have not been met, and will cancel the installment payment setting if it is determined that the cancellation conditions have been met. The setting cancellation unit 105 can determine whether or not the cancellation conditions have been met using a determination method that is appropriate to the content of the cancellation conditions. For example, the setting cancellation unit 105 will retrieve the cancellation condition data stored in the data storage unit 100 and determine whether or not the cancellation conditions indicated in the cancellation condition data have been met. If the cancellation condition data indicates multiple cancellation conditions, the setting cancellation unit 105 will determine whether or not each of the multiple cancellation conditions has been met.

[0148] For example, the setting cancellation unit 105 determines whether the cancellation condition is met by determining whether payment has been made (for example, settlement by reading code C10), and cancels the setting if it determines that payment has been made. The payment here refers to payment made while installment payments or similar settings are in place. 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 performed in response to the settlement request from the store terminal 40. Payment being made corresponds to the cancellation condition being met. Failure to make payment corresponds to the cancellation condition not being met.

[0149] In the second embodiment, as in the first embodiment, we take the example of a case where payment of the price corresponds to the use of a payment app, so the setting cancellation unit 105 cancels the setting for installment payments, etc., in the payment of the price based on the cancellation conditions. For example, if the setting cancellation unit 105 determines that the cancellation conditions have not been met, it does not cancel the setting for installment payments, etc., in the payment of the price, but if it determines that the cancellation conditions have been met, it cancels the setting for installment payments, etc., in the payment of the price.

[0150] [3-2-2. Functions implemented by the card server] The functions of the card server 20 may be the same as those of the first or second embodiment.

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

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

[0153] [3-3. Processing performed in the payment system of the third embodiment] Figure 13 shows an example of processing performed in the payment system 1 of the third embodiment. The control units 11, 21, 31, and 41 execute the programs stored in the storage units 12, 22, 32, and 42, respectively, thereby executing the processing shown in Figure 13. In Figure 13, the processing performed in the payment system 1 will be mainly described for canceling settings such as installment payments.

[0154] As shown in Figure 13, the processes in S300 to S310 are the same as those in S100 to S110. When the installment payment process in S310 is executed, the settlement server 10 determines that the cancellation conditions have been met and cancels the installment payment setting (S311). In S311, the settlement server 10 deletes the installment payment setting stored in the settlement database DB1. The subsequent process in S312 may be the same as in S111. Since the installment payment setting has been canceled in S311, the settlement server 10 may display information such as a message indicating that the installment payment setting 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. Based on the settings for installment payments, etc., the payment system 1 executes the processing for installment payments, etc. Based on predetermined cancellation conditions, the payment system 1 cancels the settings for installment payments, etc. 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 improve user convenience. For example, the payment system 1 can prevent situations where installment payments, etc. are made even though the user does not wish to make installment payments, etc., while the settings for installment payments, etc. remain in place.

[0156] Furthermore, payment system 1 acquires the settings for installment payments, etc., for the payment of the amount. Payment system 1 executes the processing for installment payments, etc., for the payment of the amount based on the settings for installment payments, etc. Payment system 1 cancels the settings for installment payments, etc., for the payment of the amount based on the cancellation conditions. As a result, users no longer need to manually cancel the settings for installment payments, etc., each time they make a payment, so payment system 1 can improve the convenience for users making payments.

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

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

[0159] [4-1. Overview of the Fourth Embodiment] In the fourth embodiment, we take 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 settings screen such as the payment source selection screen SC2), the functions described in the second embodiment (for example, a function for determining usage conditions and related functions), and the functions described in the third embodiment (for example, a function for canceling settings such as installment payments according to the cancellation conditions). For example, the payment system 1 may allow settings such as installment payments from the code screen SC1 without having the functions described in the first embodiment.

[0160] Figure 14 shows an example of processing performed in the payment system 1 of the fourth embodiment. In the fourth embodiment, an example is given where, when a user makes a payment at a store using a payment app, settings such as installment payments are specified to the store terminal 40. In the example in Figure 14, the store terminal 40 is a self-checkout register. For example, the user has the store terminal 40 read the barcode of the product and performs an operation to select a payment method to the store terminal 40. When the user selects code payment using code C10 as the payment method, the store terminal 40 displays a setting screen SC4 for specifying settings such as installment payments on the display unit 45, as shown in Figure 14.

[0161] For example, the user specifies settings such as installment payments from the settings screen SC4. The contents that can be specified as settings such as installment payments may be the same as in the first embodiment. However, while the first embodiment gives an example of when settings such as installment payments are specified from the payment source selection screen SC2 on the user terminal 30, the fourth embodiment gives an example of when settings such as installment payments are specified from the settings screen SC4 on the store terminal 40. Nevertheless, the basic setting flow may be the same as in the first embodiment.

[0162] In the example shown in Figure 14, the settings screen SC4 is displayed when the user selects installment payments. 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. The user may also be allowed to specify a setting on the store terminal 40 to indicate that they will be using revolving credit or bonus payments.

[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 conventional method. If the payment server 10 determines that the payment request does not include a setting for installment payments, etc., it processes the payment request in the same manner as in the first embodiment. In the fourth embodiment, the determination of usage conditions may be performed in the same manner as in the second embodiment, or 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 installment payment processing from the payment application based on the settings for installment payments, etc. For example, the payment system 1 executes installment payment processing for a payment using code C10 on the code screen SC1. Although Figure 14 shows an example of a setting method different from the first embodiment, the setting for installment payments, etc. may also be performed in the fourth embodiment using the same setting method as the first embodiment. For this reason, the payment system 1 of the fourth embodiment can also be said to be a higher-level concept of payment system 1 that encompasses the first embodiment. The payment system 1 of the fourth embodiment may also be a higher-level concept of payment system 1 that encompasses at least the second and third embodiments. The details of the fourth embodiment will be described below.

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

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

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

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

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

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

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

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

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

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

[0175] As shown in Figure 16, the processes of S400 and S401 are the same as those 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 such as installment payments (S402). The store terminal 40 accepts the specification of settings such as installment payments 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 sends a payment request to the payment server 10 based on the code ID obtained from code C10 (S404). If settings such as installment payments are specified, the payment request includes the settings for installment payments.

[0176] When the payment server 10 receives a payment request from the store terminal 40 (S405), it performs processing for card payment with the card server 20 (S406). In S406, it is initially processed as a lump-sum payment. The payment server 10 determines whether the payment request includes settings for installment payments, etc. (S407). If it is determined in S407 that the payment request includes settings for installment payments, etc. (S407:Y), the payment server 10 performs the same processing as S109-S111, from S408 to S410. If it is determined in S407 that the payment request does not include settings for installment payments, etc. (S407:N), the processing in S408 and S409 is not performed, and the processing in S410 is performed.

[0177] [4-4. Summary of the fourth embodiment] The payment system 1 of the fourth embodiment acquires settings for installment payments, etc. The payment system 1 executes the processing for installment payments, etc. As a result, users can use installment payments, etc. from the payment app, and the payment system 1 can improve user convenience. For example, users can use installment payments, etc. by using the payment app without having to prepare a physical card, so users can use various payment methods with the payment app.

[0178] Furthermore, payment system 1 acquires settings for installment payments, etc., for the payment of goods or services provided by the store where code C10 displayed on the payment app is read. When code C10 is read by the store, payment system 1 executes the installment payment, etc. process based on the settings. As a result, users can use installment payments, etc., by using code C10 on the payment app when paying for goods, and payment system 1 can improve the convenience of payments for users. For example, users can use installment payments, etc., by presenting the code screen SC1 of the payment app without having to present a physical card at the store, so users can use various payment methods with the payment app.

[0179] [5. Variant] This disclosure is not limited to the first to fourth embodiments described above. This disclosure may be modified as appropriate without departing from the spirit of this disclosure. Hereafter, variations relating to each of the first to fourth embodiments will be described.

[0180] [5-1. Modifications relating to the first embodiment] Figure 17 shows an example of a function realized in a modified version 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 usage 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 usage condition determination unit 109, and the simulation execution unit 110 is realized by a control unit 11.

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

[0182] Figure 18 shows an example of the code screen SC1 of Modification 1-1. As shown in the upper left of Figure 18, the display control unit 101 displays the code screen SC1 on the user terminal 30 by transmitting the same display data for the code screen SC1 as in the upper left of Figure 2. The user terminal 30 displays the code screen SC1 on the display unit 35 based on the display data. The code screen SC1 of Modification 1-1 includes a user interface part that accepts the specification of settings such as installment payments. In the example in the upper left of Figure 18, the pull-down P110 on panel P11 corresponds to this part. This part is not limited to the pull-down P110. This part may be other parts such as buttons or panels.

[0183] The following example illustrates the case where the user specifies the installment payment settings. For example, when the user selects the dropdown menu P110, the user terminal 30 displays the number of installments the user can specify in the dropdown menu P110, as shown in the upper right of Figure 18. When the user selects the number of installments from the dropdown menu P110, the user terminal 30 displays the number of installments selected by the user in the dropdown menu P110, as shown in the lower left of Figure 18. These processes may be executed by a script included in the display data of the code screen SC1, or they may be executed by the user terminal 30 communicating with the payment server 10 each time the user performs an operation on the code screen SC1. These processes may also be shown in the program code of the payment application.

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

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

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

[0187] In the modified example 1-1, the processing execution unit 102 executes installment payment processing for payment based on the installment payment settings specified on the code screen SC1 when the code C10 on the code screen SC1 is read by the store. For example, when the reading unit 46 of the store terminal 40 reads the code C10, the store terminal 40 sends the code ID obtained from the code C10 to the settlement server 10. Based on the code ID received from the store terminal 40, the processing execution unit 102 executes a lump-sum payment settlement for the time being, and if installment payment settings are specified, it generates transaction information indicating that the payment is subject to installment payments and stores it in the settlement database DB1. The processing after the code C10 is read may be the same as in the first embodiment.

[0188] In the modified example 1-1, the payment system 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 by the store, the payment system 1 executes the installment payment processing for the payment based on the installment payment settings specified on the code screen SC1. Since the user can specify the installment payment settings directly from the code screen SC1 displayed at the time of payment, the payment system 1 can enhance user convenience.

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

[0190] Figure 19 shows an example of the code screen SC1 in Modification 1-2. The code screen SC1 in the upper left of Figure 19 is the same as the code screen SC1 in the upper left of Figure 18. In the example in the upper left of Figure 19, the pull-down menu P110 corresponds to a user interface part that accepts the first operation. The user performs the first operation by selecting from the pull-down menu P110. The first operation is not limited to selecting from 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 to select another part such as a button or panel instead of the pull-down menu P110.

[0191] In Modification 1-2, the display control unit 101 displays a user interface on the user terminal 30, superimposed on the code screen SC1, which accepts a second operation to specify the details of the installment payment settings, etc., when the first operation is performed on the code screen SC1. The second operation is performed after the first operation. For example, the second operation may be an operation to specify whether or not to use installment payments, etc. The second operation may be an operation to specify the number of installments in installment payments, the payment amount or number of installments in revolving payments, or the bonus month in bonus payments. The second operation can also be an operation to specify a numerical value indicating 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] The following example illustrates the case where the user specifies the installment payment settings. For example, the display control unit 101 displays a user interface that accepts a second operation on the user terminal 30 by including a script in the display data of the code screen SC1 that indicates when the first operation is performed. For example, if the user selects the pull-down menu P110 in the state of the code screen SC1 shown in the upper left of Figure 19, the user terminal 30 executes the script included in the display data of the code screen SC1 and displays a modal M12, which includes a panel P120 that accepts the specification of the number of installments, superimposed on the code screen SC1, as shown in the upper right of Figure 19.

[0193] In the upper right example of Figure 19, Modal M12 corresponds to the user interface that accepts the second operation. This user interface may be any other user interface besides Modal M12. For example, this user interface may be any other user interface such as a popup or a window. This user interface is displayed superimposed on all or part of the code screen SC1. In the upper right example of Figure 19, Modal M12 is similar to Modal M21 in the lower left of Figure 2, but it may have a different layout from Modal M21.

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

[0195] For example, user terminal 30 sends the installment payment settings specified by the user from panel P120 of modal M12 (i.e., data indicating the installment payment settings) to payment server 10. Payment server 10 stores the installment payment settings received from user terminal 30 in the payment database DB1, associating them with the user's user ID. If the user cancels the installment payment settings from panel P120 of modal M12 (in the example in the upper right of Figure 19, the user selects "none"), user terminal 30 sends a request to payment server 10 indicating that the installment payment settings should be canceled. Based on the request received from user terminal 30, payment server 10 cancels the installment payment settings associated with the user's user ID.

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

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

[0198] In the modified example 1-2, the payment system 1 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, superimposed on the code screen SC1. Based on the details of the installment payment settings specified by the second operation, the payment system 1 executes the installment payment processing for the payment. As a result, the user can specify the installment payment settings directly from the modal M12 that is superimposed on the code screen SC1 displayed at the time of payment, thus improving user convenience. The modal M12 is displayed superimposed on the code screen SC1 and has sufficient space for the user to perform the second operation, making it easier for the user to specify the details of the installment payment settings.

[0199] [Modifications 1-3] For example, payment system 1 may be able to identify in advance which store the payment will be made for, before the payment operation is performed. In this case, payment system 1 may determine whether the store supports installment payments, etc., and based on the result of this determination, it may display a settings 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 the modified version 1-3 includes a store information acquisition unit 106 and a first correspondence determination unit 107. The store information acquisition unit 106 acquires store information about the store before payment is made. The store information may include a store ID that can identify the store, other information that allows the store ID to be searched (for example, the terminal ID of the store terminal 40), the name of the store, correspondence store information indicating whether the store is a corresponding store that supports installment payments, etc., or other information.

[0201] For example, as in the first embodiment, when the code C10 on the code screen SC1 is read by the store terminal 40, the store information acquisition unit 106 can identify which store the user is in based on the payment request from the store terminal 40. Alternatively, for example, when the user reads a store code with the user terminal 30, the store information acquisition unit 106 can also identify which store the user is in based on the code information obtained from the user terminal 30. On the other hand, before the code is read, for example, when the user enters a store, or when the user stays at a predetermined location for a predetermined time or longer, the store information acquisition unit 106 may acquire store information based on current location information indicating the current location of the user terminal 30. 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 as detected by the GPS receiver. Modification 1-3 gives an example where the current location of the user terminal 30 is expressed in latitude and longitude. The user terminal 30 transmits its 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 represented by information other than latitude and longitude. For example, the current location of the user terminal 30 may be represented by coordinates other than latitude and longitude, an address, or other information. The method by which the user terminal 30 obtains its 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 obtain its current location information by a wireless LAN access point, a mobile base station, or by other means.

[0203] In Modification 1-3, the data storage unit 100 stores a store database containing basic store information. The store database includes a store ID that can identify the store, store location information indicating the store's location, and store support information indicating whether the store is a store that supports installment payments, etc. The store database may also store other information such as the store's name. The store's location may be expressed in latitude and longitude, similar to the current location of the user terminal 30, or it may be expressed in other information such as coordinates.

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

[0205] The method of obtaining store information is not limited to the above example. For example, if a code displayed on the store terminal 40, or a code posted in the store, is read by the user terminal 30, the store information acquisition unit 106 may acquire the store ID contained in these codes as store information. When the user terminal 30 reads these codes, it obtains the store ID from the code and sends it to the payment server 10. The store information acquisition unit 106 may also acquire the store ID from the user terminal 30 as store information. The store information acquisition unit 106 may also acquire the corresponding 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 functions linked with the payment app (for example, the check-in function of a check-in app, or the mini-app "Stores Where You Can Use It" map).

[0206] For example, if a list of stores is displayed on the user terminal 30 and the user selects a store to make a payment, the store information acquisition unit 106 may acquire the store information of the store selected by the user from the list of stores. The user terminal 30 is assumed to store the store IDs of the 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 sends the store ID of that store to the payment server 10. The store information acquisition unit 106 acquires the store ID as store information from the user terminal 30. The store information acquisition unit 106 may also acquire the corresponding store information associated with the store ID acquired from the user terminal 30 as store information.

[0207] The first correspondence determination unit 107 determines whether a store supports installment payments, etc., based on the store information. For example, if the store ID corresponds to store information, the first correspondence determination unit 107 retrieves the corresponding store information associated with the store ID, which is store information, from the store database and determines whether the corresponding store information indicates a supporting store, thereby determining whether the store supports installment payments, etc. If the corresponding store information corresponds to store information, the first correspondence determination unit 107 only needs to determine whether the store supports installment payments, etc., by retrieving the corresponding store information from the store database and determining whether the corresponding store information indicates a supporting store.

[0208] In the modified example 1-3, the display control unit 101 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, the display control unit 101 does not display a setting screen on the user terminal 30 that accepts the specification of installment payment settings. If the first correspondence determination unit 107 determines that the store does support installment payments, the display control unit 101 displays a setting screen on the user terminal 30 that accepts the specification of installment payment settings.

[0209] Figure 20 shows an example of the payment application screen in Modification 1-3. Figure 20 shows an example of a payment where a code displayed on the store terminal 40 is read by the user terminal 30. For example, the code contains information necessary for payment (e.g., store ID and payment amount). When the user terminal 30 reads the code, it sends the information contained in the code to the payment server 10. When the payment server 10 receives the information contained in the code from the user terminal 30, the store information acquisition unit 106 and the first correspondence determination unit 107 are executed. Based on the information contained in the code, the payment server 10 identifies the store to which the payment is to be made (i.e., the store to which the payment is made) and the payment amount. The identification of the store and payment amount may be the same as the mechanism used in known payment services.

[0210] For example, if the display control unit 101 determines that the store does not support installment payments, etc., the display control unit 101 displays a confirmation screen SC5 on the user terminal 30 that does not accept the specification of installment payment settings, etc., as shown on the left side of Figure 20. In the example on the left side of Figure 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 displays the payment source selection screen SC2 on the display unit 35. In the example on the left side of Figure 20, the confirmation screen SC5 does not include the pull-down menu P500 described later.

[0211] For example, if the display control unit 101 determines that the store supports installment payments, etc., the first correspondence determination unit 107 determines that the store supports installment payments, etc., the display control unit 101 displays a confirmation screen SC5 on the user terminal 30, as shown on the right side of Figure 20, which accepts the specification of the installment payment settings, etc. In the example on the right side of Figure 20, panel P50 includes a pull-down menu P500 for specifying the installment payment settings, etc. The pull-down menu P500 may be the same as the pull-down menu P110 on the code screen SC1. The user can specify the installment payment settings, etc. by selecting from the pull-down menu P110. The confirmation screen SC5 on the right side of Figure 20 is an example of a settings screen.

[0212] For example, if the user selects panel P50 while the confirmation screen SC5 is in the state shown on the right side of Figure 20, the display control unit 101 displays the payment source selection screen SC2, similar to the upper right of Figure 2, on the user terminal 30. The process for specifying settings such as installment payments from the payment source selection screen SC2 may be the same as in the first embodiment. If the user selects pull-down P500 in panel P50, the display control unit 101 may display a modal similar to the modal M21 in Figure 19 on the confirmation screen SC5. The process for specifying settings such as installment payments from this modal may be the same as in the modified example 1-2.

[0213] For example, when a user slides the slider 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 slider bar B51 is slid in the state of the confirmation screen SC5 on the left side of Figure 20 may be the same as that of a known payment service. When the processing execution unit 102 receives a payment request from the user terminal 30, it executes the installment payment or similar processing based on the installment payment or similar settings stored in the payment database DB1.

[0214] Although the method of sending the payment request differs from the first embodiment in whether it is sent from the store terminal 40 or the user terminal 30, the installment payment processing itself performed by the processing execution unit 102 may be the same as in the first embodiment. Furthermore, in Modification 1-3, since the payment request is sent from the user terminal 30, the installment payment settings specified by the user from the confirmation screen SC5 may be included in the payment request. The processing execution unit 102 may perform the installment payment processing based on the installment payment settings included in the payment request.

[0215] The payment system 1 in Modification 1-3 acquires store information before payment is made. 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 settings screen on the user terminal 30. This allows the payment system 1 to allow the user to specify installment payment settings from a settings screen that corresponds to whether the store supports installment payments, etc., thereby effectively improving user convenience. For example, the payment system 1 can prevent situations where installment payment settings are specified for payments that do not support installment payments, etc.

[0216] [Modifications 1-4] For example, in the first embodiment, we described a case where a user uses installment payments for payment, but a user may also use installment payments in situations other than payment. Modification 1-4 gives an example of a case where a user uses installment payments for charging electronic money. Installment payments for charging do not mean charging in multiple installments. The charge itself is completed in one go. That is, when a single charge is performed, the electronic money balance increases only once.

[0217] The installment payments in charging described in Variation 1-4 refer to the installment payments in the payment of the source of the charge. For example, suppose a user designates a credit card as the source of the charge and makes a charge of 10,000 yen in 5 installments. The electronic money balance increases by 10,000 yen immediately after the payment for the charge is made. The electronic money balance does not increase by 2,000 yen each of the 5 installments. The withdrawal from the credit card used as the source of the charge is divided into 5 installments. Similarly, if revolving credit or bonus payments are specified for the charge, the electronic money balance increases immediately after the payment for the charge is made, and the subsequent withdrawals are divided into multiple installments or made in bonus months.

[0218] Figure 21 shows an example of a settings screen in Modification 1-4. In the example in Figure 21, the charging screen SC6, which accepts the specification of charging conditions, corresponds to the settings screen. Where it is written as "charging screen SC6" in Modification 1-4, it can be read as "settings screen". In Modification 1-4, the display control unit 101 displays the charging screen SC6, which accepts the specification of settings for charging using a payment method, on the user terminal 30. The display control unit 101 generates display data for the charging screen SC6 and transmits this display data to the user terminal 30, thereby displaying the charging screen SC6 on the user terminal 30.

[0219] For example, as shown in the upper left of Figure 21, the display control unit 101 displays a charge screen SC6 on the user terminal 30, which includes an input form F60 for charge conditions and a panel P61 indicating the payment method set as the charge source. The charge conditions are the conditions for charging. For example, the charge conditions may be the charge amount or the balance after charging. The payment method to be used as the charge source is also a type of charge condition. The conditions that can be specified as charge conditions may be the same as the conditions used in known charges.

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

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

[0222] For example, the display control unit 101 may generate display data including a script and send it to the user terminal 30 to display modal M71, etc. on the user terminal 30. When the user specifies settings such as installment payments for charging from modal M71, the settings such as installment payments are reflected on the charging source selection screen SC7, as shown in the lower right of Figure 21. The settlement server 10 obtains the settings such as installment payments from the user terminal 30 and stores the settings such as installment payments for charging in the settlement database DB1. The settings such as installment payments for payment and the settings such as installment payments for charging may be separate from each other or may be common.

[0223] In the modified example 1-4, the processing execution unit 102 executes the installment payment processing for charging based on the settings for installment payments, etc. The processing execution unit 102 may, similar to payment of goods, first execute the charge as a lump sum payment and then execute processing to change the lump sum payment to installment payments, etc., or it may execute the settlement for charging as installment payments, etc. from the beginning without executing an initial lump sum payment. For example, when the processing execution unit 102 executes the settlement for charging, it requests the card server 20 to execute the settlement for charging as installment payments, etc. Based on this request, the card server 20 executes the settlement for charging as installment payments, etc. The processing by which the card server 20 executes the settlement as installment payments, etc. may be the same as the processing of known payment services.

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

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

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

[0227] For example, if 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 in the pull-down menu P610. This sequence of operations may be the same as that of the code screen SC1 in Figure 18. This sequence of operations may be executed by a script included in the display data of the charge screen SC6, or it 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 sequence of operations may also be shown in the program code of the payment application. Similarly, when revolving credit or bonus payments are executed, the display control unit 101 may display the charge screen SC6, which accepts the setting of revolving credit or bonus payments, as a setting screen on the user terminal 30.

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

[0229] In the modified version 1-5, the payment system 1 displays a charge screen SC6, which accepts the specification of charge conditions, 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 used to input charge conditions, the payment system 1 can enhance user convenience.

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

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

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

[0233] The following examples illustrate cases where the user specifies installment payment settings. For example, the display control unit 101 displays a user interface that accepts a fourth operation on the user terminal 30 by including a script in the display data of the charge screen SC6 that indicates when a third operation is performed. For example, if the user selects the pull-down menu P610 in the state of the charge screen SC6 shown in the upper left of Figure 22, the user terminal 30 executes the script included in the display data of the charge screen SC6 and displays a modal M63, which includes a panel P630 that accepts the number of installments, superimposed on the charge screen SC6, as shown in the upper right of Figure 22.

[0234] In the upper right example of Figure 22, Modal M63 corresponds to the user interface that accepts the fourth operation. This user interface may be any other user interface besides Modal M63. For example, this user interface may be any other user interface such as a pop-up or a window. This user interface is displayed superimposed on all or part of the charge screen SC6. In the upper right example of Figure 22, Modal M63 is generally similar to Modal M21 in the lower left of Figure 2, but it may have a different layout from Modal M21.

[0235] For example, the user performs a fourth operation by selecting a panel P630 from modal M63 that shows the desired number of installments. When the user selects panel P630, the user terminal 30 clears modal M63 and displays the number of installments shown by panel P630 in the pull-down menu P610, as shown in the lower left of Figure 22. These processes may be executed by a script included in the display data of the charge screen SC6, or they 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. These processes may also be shown in the program code of the payment application.

[0236] For example, user terminal 30 sends the installment payment settings specified by the user from panel P630 of modal M63 to payment server 10. Payment server 10 stores the installment payment settings received from user terminal 30 in the payment database DB1, associating them with the user's user ID. If the user cancels the installment payment settings from panel P630 of modal M63 (in the example in the upper right of Figure 22, the user selects "none"), user terminal 30 sends a request to payment server 10 indicating that the installment payment settings should be canceled. Based on the request received from user terminal 30, payment server 10 cancels the installment payment settings associated with the user's user ID.

[0237] Furthermore, when a user specifies whether to set up revolving credit or bonus payments, the display of the charge screen SC6 may be controlled in the same manner as when a user specifies whether to set up installment payments. For example, when the third operation is performed, the display control unit 101 may display a user interface that accepts a fourth operation to specify the details of the revolving credit or bonus payment settings, superimposed on the charge screen SC6. The display control unit 101 may control these processes by sending display data containing a script indicating these processes to the user terminal 30, or it may control these processes by communicating with the user terminal 30 each time the user performs an operation on the charge screen SC6.

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

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

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

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

[0242] The payment system 1 in the modified example 1-7 displays the details of installment payment settings, etc., on the settings screen, in association with the payment method information related to the payment method. As a result, the user can check both the payment method information and the details of installment payment settings, etc., on the settings screen, thus improving user convenience.

[0243] [Variations 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 examples of payment method screens that accept the specification of a payment method to be used by 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 a payment method screen as a setting screen on the user terminal 30 that accepts the specification of a payment method to be used by the user terminal 30 from among a plurality of payment methods available on the user terminal 30. The process by which the display control unit 101 causes the payment source selection screen SC2 or the charge source selection screen SC7 to be displayed as a payment method screen is as described in the first embodiment or modification 1-4.

[0244] Note that the usage payment method screen may be any screen other than the payment source selection screen SC2 and the recharge source selection screen SC7. For example, the usage payment method screen may be a screen for specifying the payment methods registered in the payment application. In this case, the display control unit 101 may display a screen for specifying the payment methods registered in the payment application as the setting screen. The usage payment method screen may be a screen for deleting the payment methods registered in the payment application. In this case, the display control unit 101 may display a screen for deleting the payment methods registered in the payment application as the setting screen.

[0245] The processing execution unit 102 of Modification Example 1-8 executes processing such as installment payment based on the usage payment method specified on the usage payment method screen and settings such as installment payment. For example, the processing execution unit 102 executes processing such as installment payment in the payment of the price based on the payment source selected on the payment source selection screen SC2, which is an example of the usage payment method screen, and settings such as installment payment. This processing is as described in the first embodiment. The processing execution unit 102 executes processing such as installment payment in the recharge based on the recharge source selected on the recharge source selection screen SC7, which is an example of the usage payment method screen, and settings such as installment payment. This processing is as described in Modification Example 1-4.

[0246] The payment system 1 of Modification Example **************************8 displays the usage payment method screen on the user terminal 30 as the setting screen. The payment system 1 executes processing such as installment payment based on the usage payment method specified on the usage payment method screen and settings such as installment payment. Thereby, the user can specify settings such as installment payment in the usage payment method screen for selecting the usage payment method, so that the payment system 1 can effectively improve the convenience of the user.

[0247] [Modification Example 1-9] It seems there is some information missing in the translation of line . Please check and provide the complete text for a more accurate translation.For example, if a payment app supports multiple payment methods, all of them may support installment payments through the payment app, or only some of them may support installment payments through the payment app. In Modification 1-9, we take the example of a case where, among the multiple payment methods supported by a payment app, only a specific payment method supports installment payments through the payment app. In this case, a settings screen may be displayed depending on the result of the determination of whether or not the specific payment method is used.

[0248] The payment system 1 of Modification 1-9 includes a second correspondence determination unit 108. The second correspondence determination unit 108 determines whether the payment method at the user terminal 30 supports installment payments, etc. For example, the data storage unit 100 stores corresponding payment method data indicating the payment method that supports installment payments, etc. The corresponding payment method data may be in any format. For example, the corresponding payment method data may be in table format, mathematical formula format, part of a program, a machine learning model, or other format. The corresponding payment method data may be determined by the administrator of the payment service or by 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 corresponding payment method data. If only credit cards issued by a specific card company support installment payments, etc., the corresponding payment method data will show the credit card of that card company. The second correspondence determination unit 108 identifies the card company of the user's credit card based on a part of the credit card number (for example, a predetermined number of digits), etc., and determines whether that card company supports installment payments, etc. The second correspondence determination unit 108 determines whether the payment source or charge source supports installment payments, etc. This also includes cases where only credit cards of a predetermined type issued by a specific card company support installment payments, etc.

[0250] In the modified example 1-9, the display control unit 101 displays the settings screen on the user terminal 30 based on the determination result of the second correspondence determination unit 108. For example, if the display control unit 101 determines that the user's payment method does not support installment payments, it does not display the settings screen on the user terminal 30, but if it determines that the user's payment method does support installment payments, it displays the settings screen on the user terminal 30. If the display control unit 101 determines that the user's payment method does not support installment payments, it may display a settings screen on the user terminal 30 that does not accept the specification of installment payment settings (for example, a settings screen in which the user interface part that accepts the specification of installment payment settings is grayed out, or a settings screen that does not include such part), and if it determines that the user's payment method does support installment payments, it may display a settings screen on the user terminal 30 that accepts the specification of installment payment settings.

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

[0252] [Variations 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 the usage conditions related to the use of installment payments, etc., at the user terminal 30 are met. 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 content of the usage conditions.

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

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

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

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

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

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

[0259] In the modified version 1-11, the payment system 1 displays the settings screen for one of the multiple payment methods on the user terminal 30 so that the settings specified on the settings screen for that payment method are carried over to the settings screens for the other payment methods. The payment system 1 executes the processing for each payment method based on the settings specified on the settings screen for each of the multiple payment methods. As a result, when a user changes their payment method, they do not need to reconfigure settings such as installment payments, and the payment system 1 can effectively improve user convenience.

[0260] [Variations 1-12] For example, if the amount of payment or charge subject to installment payments is known in advance, the simulation results corresponding to the amount used may be displayed. The settlement system 1 of Modification 1-12 includes a simulation execution unit 110. The simulation execution unit 110 performs a simulation related to installment payments, etc. The simulation calculates the payment amount per installment (withdrawal amount), calculates the fees, calculates the period over which payments occur, or calculates the payment month.

[0261] In the modified example 1-12, the data storage unit 100 stores a simulation program for simulating installment payments, etc. The simulation program defines formulas for calculating fees for each installment payment setting, formulas for calculating the payment amount per installment, or other formulas. The simulation program may be the same as a program used in a well-known card service, etc. For example, when a user uses installment payments, the simulation execution unit 110 calculates the fees required for installment payments and the payment amount per installment based on the amount used, the number of installments, and the simulation program. Similarly, when a user uses revolving credit or bonus payments, the simulation execution unit 110 should execute a simulation based on the amount used, the settings specified by the user, and the simulation program.

[0262] Figure 23 shows an example of the confirmation screen SC5 in Modification 1-12. The display control unit 101 in Modification 1-12 displays the confirmation screen SC5, which is an example of a settings screen, on the user terminal 30 based on the simulation execution results. In the example in Figure 23, when the user selects the pull-down P500 in the state of the confirmation screen SC5 on the right side of Figure 20, the user terminal 30 displays a modal M52 on the confirmation screen SC5 that accepts the specification 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 based on the amount used and each of the multiple installment options, which are identified when the code displayed on the store terminal 40 is read. The display control unit 101 displays the payment amount for each installment in the modal M52. The user checks the simulation results from the panel P520 and selects the number of installments.

[0264] For example, the display control unit 101 may display the simulation results on other setting screens 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). If the simulation results are displayed on the completion screen SC3, the processing execution unit 102 may execute the installment payment or other payment processing when the user requests installment payments or the like from the completion screen SC3.

[0265] The payment system 1 in the modified example 1-12 performs a simulation regarding 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 simulation results, so the payment system 1 can effectively enhance user convenience.

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

[0267] [Modification Example 2-1] For example, in the second embodiment, the case where a batch payment is first executed when the settlement application is used with a credit card set as the payment source is taken as an example. In this case, the payment from the card service administrator to the store is made in a lump sum, not divided. After the first batch payment is executed, if the settlement server 10 and the card server 20 cooperate with each other and the usage conditions are satisfied, a process of changing the first batch payment to an installment payment or the like is executed.

[0268] Although it was also somewhat described in the second embodiment, the processing execution unit 201 may change and process an installment payment or the like to a lump sum payment when it is determined that the usage conditions are not satisfied. That is, when it is determined that the usage conditions are not satisfied, the processing execution unit 201 makes an entry as a lump sum payment without changing the first lump sum payment. Even if the user made a payment with an installment payment or the like set, since it is entered as a lump sum payment, the card server 20 processes the debit for the payment as a lump sum payment. The process for the debit of the lump sum payment may be realized by the same process as a known card service.

[0269] The settlement system 1 of Modification Example 2-1 changes and processes an installment payment or the like to a lump sum payment when it is determined that the usage conditions are not satisfied. Thereby, even if an installment payment or the like is specified for a payment where the usage conditions are not satisfied, the settlement system 1 can process it as a lump sum payment, so that it is possible to prevent the store from not receiving the payment.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0283] The payment system 1 in Modification 2-3 determines whether the usage conditions are met when payment is instructed. Based on the determination result of the usage condition determination unit 109 executed when payment is instructed, the payment system 1 executes the payment processing. As a result, the payment system 1 can determine whether the usage conditions are met at an earlier stage, and can provide users with a more flexible payment service. For example, the payment system 1 can notify the user that an error occurred with installment payments, etc., when code C10 is read by the store terminal 40.

[0284] [Modification 2-4] For example, in Modification 2-3, when payment is instructed, the user may be notified of the processing result, such as installment payments. The payment system 1 in Modification 2-4 includes a payment notification unit 113. When payment is instructed and it is determined that the usage conditions are not met, the payment notification unit 113 sends a payment notification regarding installment payments, etc., to the user of the payment application. The payment notification is a notification indicating the processing result, such as installment payments. The payment notification may be the same as the processing result notification described in Modification 2-2.

[0285] Figure 26 shows an example of a payment notification. For example, if the payment notification unit 113 is instructed to pay and determines that the usage conditions are not met, it displays an error message window W13 on the code screen SC1. The payment notification unit 113 displays window W13 on the code screen SC1 by sending display data for window W13 to the user terminal 30. The user terminal 30 displays window W13 on the code screen SC1 based on the display data. The user closes window W13, changes the setting to lump-sum payment and performs the payment again, or pays the amount using a payment method other than the payment app.

[0286] In addition, in the modified version 2-4, if payment is instructed and it is determined that the usage conditions are not met, installment payments may be changed to a lump-sum payment and processed accordingly. In this case, the payment notification unit 113 may notify the user terminal 30 by displaying a completion screen SC3 on the user terminal 30 indicating that installment payments have been changed to a lump-sum payment and processed accordingly. The completion screen SC3 in this case is an example of a payment notification.

[0287] Furthermore, payment notifications may be made by means other than the display in window W13 on the code screen SC1. For example, the payment notification unit 113 may notify the user of a payment by means of the payment app's notification function, email, SMS message, messaging app message, SNS message, message in an app other than the payment app, push notification, pop-up notification, or banner notification. Even when the payment notification unit 113 makes a payment notification by means of other means, the payment notification unit 113 may identify which user's payment was processed and how, according to the result of the usage conditions determination, and send a payment notification to the user indicating the result of that specific execution.

[0288] In the modified version 2-4, payment system 1 issues a payment notification regarding installment payments, etc., to the user of the payment app when payment is instructed and it is determined that the usage conditions are not met. This allows the user to know how the payment for which they specified installment payments, etc., has been processed, thus effectively enhancing user convenience.

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

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

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

[0292] The change inquiry unit 114 may also make change inquiries on screens other than the code screen SC1. For example, as in the modified example 1-3, when the store code is read by the user terminal 30, the change inquiry unit 114 may make change inquiries on the confirmation screen SC5. Alternatively, for example, in the case of a payment method where the user selects a store from a list of stores to make a payment, the change inquiry unit 114 may make change inquiries on the screen that instructs that type of payment. The change inquiry unit 114 may also make change inquiries on other screens 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 the user's action in response to the change inquiry. The user gives 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 in Figure 27, the user gives either the first or second response by selecting either button B140 or button B141. The response to the change inquiry may also be given by an action on 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 the operation of the operation unit 34 and sends 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 performs processing according to the response to the change inquiry based on the response data. For example, if the response indicates a change to another payment method, the response execution unit 115 performs the payment based on the other payment method. In the example in Figure 27, if the user selects button B140, the response execution unit 115 changes the installment payment or the like to a lump-sum payment and processes the payment as a lump sum payment. The method for processing the payment as a lump sum payment may be the same as when installment payments or the like are not used. That is, the method for processing the payment as a lump sum payment may be the same as that of a known payment service.

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

[0296] In the modified version 2-5, when payment is instructed and it is determined that the usage conditions are not met, the payment system 1 makes a change inquiry on the user terminal 30 regarding whether to change the payment method, such as installment payments, to another payment method. The payment system 1 executes processing according to the answer to the change inquiry. As a result, the user can change to another payment method in response to the change inquiry, so the payment system 1 can perform flexible processing and effectively enhance user convenience.

[0297] [Modification 2-6] For example, as explained to some extent in the second embodiment, the usage conditions may be conditions relating to whether or not the store to which the payment is made supports installment payments, etc. In Modification 2-6, similar to the second embodiment, an initial lump-sum payment is made for the payment, and afterwards, the card server 20 determines whether or not the usage conditions are met. In Modification 2-6 as well, the settlement server 10 may determine whether or not the usage conditions are met. That is, in Modification 2-6 as well, the settlement server 10 may also include a usage condition determination unit 109 and a usage information acquisition unit 112.

[0298] In Modification 2-6, the usage information acquisition unit 202 acquires store information as usage information. The store information is as described in Modification 1-3. In Modification 2-6, it is assumed that the store ID of the store to which payment is made is included in the usage information as store 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, similar to the second embodiment, the data storage unit 200 stores the corresponding database. The usage condition determination unit 203 only needs to determine whether the store is a supported store or a non-supported store based on the corresponding database.

[0299] The payment system 1 in modified example 2-6 determines whether the conditions for use are met by determining, based on store information, whether the store supports installment payments, etc. This allows the payment system 1 to prevent installment payments, etc. from being used at stores that do not support them.

[0300] [Modification 2-7] For example, in the second embodiment, installment payments may be used with the charge, similar to the modification 1-4. Modification 2-7 takes the example of a case where the payment server 10 implements a usage condition determination unit 109 and a usage information acquisition unit 112. Furthermore, modification 2-7 takes the example of a case where the same charge screen SC6 as in modification 1-4 is displayed.

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

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

[0303] The usage conditions in Modification 2-7 may also be any other conditions, similar to those 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 condition is not met. If the usage condition determination unit 109 determines that the charge amount is equal to or greater than a predetermined amount, it determines that the usage condition is met.

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

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

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

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

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

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

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

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

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

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

[0314] The payment system 1 in modified example 2-10 determines whether the usage conditions are met by determining, based on usage information, whether the amount used at the user terminal 30 is equal to or greater than a predetermined amount. This allows the payment system 1 to prevent installment payments from being executed for low-amount payments that are not eligible for installment payments.

[0315] [Variation 2-11] For example, in Modification 2-10, the user may use points or other means to pay for or charge the account. Therefore, if a payment is made using a payment method other than the payment method, the usage condition determination unit 203 may determine whether the amount obtained by subtracting the amount paid 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 charges 10,000 yen using a credit card as the charge source, 2,000 yen is paid with points. In this case, the usage condition determination unit 203 should determine the usage condition based on 8,000 yen, which is the charge amount of 10,000 yen minus the amount paid (2,000 yen). The payment server 10 should obtain the information of the amount paid from the user terminal 30.

[0316] In the modified example 2-11, payment system 1 determines whether the amount obtained by subtracting the amount paid by the other payment method from the total amount used is equal to or greater than a predetermined amount, when payment is made using a payment method other than the specified payment method. This allows payment system 1 to appropriately determine the usage conditions for installment payments, etc., even when points or similar items are used for payment.

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

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

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

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

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

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

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

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

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

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

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

[0328] [Modification 3-2] For example, in the third embodiment, an example was given in which the setting cancellation unit 105 determines the cancellation conditions after payment has been instructed. The setting cancellation unit 105 may be able to obtain the information necessary to determine the cancellation conditions before payment is instructed. In this case, the setting cancellation unit 105 may determine the cancellation conditions and cancel the setting for installment payments, etc., before payment is instructed. Modification 3-2 is similar to Modification 1-3 in that an example of payment is given in which the user terminal 30 reads a code displayed on the store terminal 40.

[0329] Figure 29 shows an example of the 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 explained in Modification 1-3, the user terminal 30 transmits the information contained in the code (e.g., store ID and payment amount) to the payment server 10. The payment server 10 receives the information contained in the code from the user terminal 30. The setting release unit 105 determines whether the release condition is met based on the information contained in the code.

[0330] For example, in the case of the release condition in Modification 3-1, the setting release unit 105 obtains corresponding store information associated with the store ID indicated by the information contained in the code from the store database and determines whether the store to which payment is to be made is a corresponding store. If the release condition is that the payment amount is less than a predetermined amount, the setting release unit 105 may determine whether the release condition is met by determining whether the payment amount is less than a predetermined amount based on the payment amount information received from the user terminal 30.

[0331] For example, if it is determined that the release conditions have been met, the display control unit 101 displays a confirmation screen SC5 on the user terminal 30, as shown on the left side of Figure 29, indicating that the installment payment setting specified on the code screen SC1 has been released (for example, a confirmation screen SC5 that includes a panel P50 indicating that the 3-installment payment setting has been released and it has become a lump-sum payment). If it is determined that the release conditions have not been met, the display control unit 101 displays a confirmation screen SC5 on the user terminal 30, as shown on the right side of Figure 29, indicating that the installment payment setting specified on the code screen SC1 has not been released. The processing after the confirmation screen SC5 is displayed may be the same as in the modified example 1-3.

[0332] In addition, in Modification 3-2, as in 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 the cancellation conditions are met based on the current location information. For example, the setting cancellation unit 105 may identify a store near the current location indicated by the current location information, and determine whether the cancellation conditions are met based on the corresponding store information of that store.

[0333] For example, in Modification 3-2, as in Modification 1-3, a type of payment may be performed in which the user selects the store to be paid for from a list of stores displayed on the user terminal 30. In this case, the payment server 10 obtains store information from the user terminal 30 indicating the store selected by the user. The setting cancellation unit 105 may determine whether the cancellation conditions are met based on the corresponding store information of the store indicated by the store information. If the user enters a payment amount into the payment app, the payment server 10 may obtain the payment amount entered by the user from the user terminal 30. The setting cancellation unit 105 may determine whether the cancellation conditions are met based on the payment amount obtained from the user terminal 30.

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

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

[0336] In the modified example 3-3, the processing execution unit 102 executes the processing for installment payments in the charge based on the settings for installment payments in the charge. The processing for installment payments in the charge may be the same as in the modified examples 1-4 and 2-7.

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

[0338] For example, the setting cancellation unit 105 will not cancel the setting for installment payments in the charge if the cancellation conditions are not met, and will cancel the setting for installment payments in the charge if the cancellation conditions are met. The setting cancellation unit 105 cancels the setting for installment payments in the charge by deleting the setting for installment payments in the charge stored in the settlement database DB1, or by changing the setting value to indicate that installment payments in the charge will not be performed.

[0339] The payment system 1 in modified example 3-3 acquires the settings for installment payments, etc., in the charge. Based on the settings for installment payments, etc., in the charge, the payment system 1 executes the processing for installment payments, etc., in the charge. Based on the cancellation conditions, the payment system 1 cancels the settings for installment payments, etc., in the charge. As a result, the payment system 1 can improve user convenience in the charge because the user no longer needs to manually cancel the settings for installment payments, etc., in the charge.

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

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

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

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

[0344] For example, if the payment source corresponds to the payment method used, the user changes the payment source from the payment source selection screen SC2. The user terminal 30 sends the 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 is updated. If the setting cancellation unit 105 does not determine that the payment source has been changed, it does not cancel the installment payment setting, etc., but if it determines that the payment source has been changed, it cancels the installment payment setting, etc.

[0345] For example, if the charge source corresponds to the payment method used, the user changes the payment source from the charge source selection screen SC7. The user terminal 30 sends the 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 is updated. If the setting cancellation unit 105 does not determine that the charge source has been changed, it does not cancel the installment payment setting, etc., but if it determines that the charge source has been changed, it cancels the installment payment setting, etc.

[0346] The payment system 1 in Modification 3-5 determines whether the cancellation conditions have been met by determining whether the payment method used has been changed, and if it is determined that the payment method used has been changed, it cancels the installment payment setting. This allows the payment system 1 to avoid carrying over the installment payment setting when the payment method used is changed. For example, a user may have wanted installment payments with the previous payment method but not with the new payment method. In such cases, the payment system 1 can prevent the user from forgetting to cancel the installment payment setting, which could result in installment payments being executed with the new payment method.

[0347] [Modification 3-6] For example, installment payments may only be supported for specific payment methods. Hereafter, payment methods that support installment payments will be referred to as supported payment methods. Payment methods that do not support installment payments will be referred to as unsupported payment methods. The setting cancellation unit 105 determines whether the payment method used has been changed from a supported payment method that supports installment payments to an unsupported payment method that does not support installment payments, and may cancel the setting if it determines that the payment method used has been changed from a supported payment method to an unsupported payment method.

[0348] In Modification 3-6, the data storage unit 100 stores payment method data in which at least one of the supported payment method and the unsupported payment method is defined. The payment method data may define only supported payment methods, only unsupported payment methods, or both supported and unsupported payment methods. Modification 3-6 takes the example of a case where only credit cards from a specific card company called "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 been 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 been changed from a supported payment method to an unsupported payment method, it does not determine that the cancellation condition has been met. If it determines that the payment method used has been 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 method used is changed from the credit card "AAA card" to another payment method. If a user has registered two credit cards "AAA cards" 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 has not been met.

[0350] For example, when the payment source is changed, the setting cancellation unit 105 determines, based on the payment method data, whether the payment source has changed from a supported payment method to an unsupported payment method. 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. If it does determine 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 is changed from the credit card "AAA card" to another payment method.

[0351] For example, when the charging source is changed, the setting cancellation unit 105 determines, based on the payment method data, whether the charging source has been changed from a supported payment method to an unsupported payment method. If the setting cancellation unit 105 does not determine that the charging source has been changed from a supported payment method to an unsupported payment method, it does not determine that the cancellation condition has been met. If it determines that the charging source has been 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 charging source is changed from the credit card "AAA card" to another payment method.

[0352] The payment system 1 in Modification 3-6 determines whether the payment method used has been changed from a supported payment method to an unsupported payment method, and if it is determined that the payment method used has been changed from a supported payment method to an unsupported payment method, it cancels the installment payment setting. As a result, the payment system 1 does not need to manually cancel the installment payment setting when the user changes the payment method used from a supported payment method to an unsupported payment method, thereby reducing the operational burden on the user and effectively improving user convenience.

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

[0354] For example, suppose a user has registered two credit cards, "AAA cards," in the payment app. The setting cancellation unit 105 determines that the cancellation condition is not met 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 met if the payment method used is changed from either of the two credit cards "AAA cards" to an unsupported payment method such as a card from another company.

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

[0356] For example, if the payment method used is the charge source, the setting cancellation unit 105 will determine that the cancellation condition is not met 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 will determine that the cancellation condition is met if the charge source is changed from either of the two credit cards "AAA card" to an unsupported payment method such as a card from another company.

[0357] In the modified version 3-7, payment system 1 does not cancel the installment payment setting if it is determined that the payment method used has been changed from one of the multiple supported payment methods to another. Instead, it cancels the installment payment setting if it is determined that the payment method used has been changed from one of the multiple supported payment methods to an unsupported payment method. As a result, payment system 1 does not require the user to specify the installment payment setting again when they change their payment method from one supported payment method to another. This reduces the operational burden on the user and effectively enhances user convenience.

[0358] [Modification 3-8] For example, in Modification 3-7, the setting cancellation unit 105 may cancel the installment payment setting when the payment method used is changed from one of the multiple supported payment methods to an unsupported payment method, and then reapply the installment payment setting if it is determined that the payment method used has since been changed from an unsupported payment method to one of the multiple supported payment methods. In Modification 3-7, it is assumed that the installment payment setting before cancellation is stored in the payment database DB1. In this case, the setting cancellation unit 105 may reapply the installment payment setting by changing the value of a flag indicating whether the installment payment setting is valid or not. The flag may be stored in the payment database DB1. The installment payment setting 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 Card," to the payment app. The setting cancellation unit 105 cancels the installment payment setting if the payment method used is changed from the first credit card "AAA Card" to an unsupported payment method. The installment payment settings before cancellation are stored in an arbitrary location such as the payment database DB1. Subsequently, if the payment method used is changed from the unsupported payment method to the second credit card "AAA Card," the setting cancellation unit 105 reapplies the stored installment payment settings before cancellation. That is, the setting cancellation unit 105 stores the installment payment settings before cancellation in the payment database DB1.

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

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

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

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

[0364] Modification 3-9 gives an example where the termination of the payment application is equivalent to the cancellation condition. For example, the setting cancellation unit 105 determines whether the payment application has terminated by determining whether or not it has received a termination notification from the user terminal 30. If the setting cancellation unit 105 determines that it has not received a termination notification from the user terminal 30, it does not determine that the payment application has terminated and does not cancel the installment payment setting. If the setting cancellation unit 105 determines that it has received a termination notification from the user terminal 30, it determines that the payment application has terminated and cancels the installment payment setting.

[0365] Furthermore, the user terminal 30 does not need to send a termination notification when the payment application is terminated. In this case, the deactivation unit 105 may determine whether the payment application has terminated by determining whether a predetermined period of time (for example, 10 minutes) or longer has passed without receiving any information from the payment application. When the payment server 10 receives any information from the payment application, it shall store the current date and time in the data storage unit 100 as the date and time of the last communication with the payment application. The deactivation unit 105 may then make the above determination based on the stored date and time.

[0366] For example, if the setting cancellation unit 105 determines that it has not received any information from the payment app for a predetermined period of time, it will not determine that the payment app has terminated and will not cancel the installment payment settings. If the setting cancellation unit 105 determines that it has not received any information from the payment app for a predetermined period of time, it will determine that the payment app has terminated and will cancel the installment payment settings. If other apps or browsers are used in addition to the payment app, the setting cancellation unit 105 can determine the termination of the other app or browser in the same way as the payment app.

[0367] The payment system 1 in Modification 3-9 determines whether the cancellation conditions have been met by checking whether an application or browser, such as a payment application, has been terminated. If it is determined that the payment application has been terminated on the user terminal 30, the system cancels the installment payment settings. This eliminates the need for the user to manually cancel the installment payment settings in preparation for the next time they launch the payment application, thus effectively improving user convenience. For example, the payment system 1 can prevent unintended installment payments from being made if the user launches the payment application again and the installment payment settings remain active.

[0368] [Modification 3-10] For example, the setting acquisition unit 104 may acquire a first setting regarding whether or not installment payments are used, and a second setting regarding whether or not the first setting needs to be canceled. That is, one of the settings for installment payments may be whether or not processing by the setting cancellation unit 105 is necessary. In the settlement database DB1 of the modified example 3-10, the first setting and the second setting are stored as settings for installment payments. 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 it may be specified in advance by the settlement system 1.

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

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

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

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

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

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

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

[0376] [5-4. Modified Examples of the Fourth Embodiment] Figure 31 shows an example of a function realized in a modified version of the fourth embodiment. For example, the payment server 10 includes a display control unit 101, a usage 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 usage 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] [Modification 4-1] For example, as explained in the fourth embodiment, the setting acquisition unit 104 may acquire settings such as installment payments for the payment of goods or services provided by a store where the payment method is available. In Modification 4-1, a type of payment in which the code C10 displayed on the user terminal 30 is read by the store terminal 40 may be performed, similar to the fourth embodiment, but an example of a case in which a different type of payment is performed is given. For example, as in Modification 1-3, a type of payment in which the code displayed on the store terminal 40 is read by the user terminal 30 may be performed.

[0378] For example, the user terminal 30 obtains the information necessary for payment (e.g., store ID, 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 this information from the user terminal 30, the display control unit 101 displays a confirmation screen SC5 on the user terminal 30, similar to that shown in Figure 20. This sequence of events may be the same as in the modified example 1-3.

[0379] The setting acquisition unit 104 in Modification 4-1 may acquire the settings for installment payments, etc., specified on the confirmation screen SC5, similar to Modification 1-3, or it may acquire the settings for installment payments, etc., previously specified on the code screen SC1, etc. Furthermore, as described in the fourth embodiment, the setting acquisition unit 104 may acquire the settings for installment payments, etc., specified in a location other than the payment application. The setting acquisition unit 104 may also acquire the settings for installment payments, etc., specified on the payment system 1 side.

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

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

[0382] The payment system 1 of Modification 4-1 includes a display control unit 101. When payment is completed, the display control unit 101 displays a completion screen SC3 on the user terminal 30, which indicates that payment has been completed and that payment related to installment payments, etc., has been made. This differs from the first embodiment in that the 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 can display the completion screen SC3 on the user terminal 30 by generating display data for the completion screen SC3 and sending it to the user terminal 30.

[0383] The payment system 1 in Modification 4-1 acquires the settings for installment payments, etc., for the payment of the price. Based on the settings for installment payments, etc., the payment system 1 executes the processing for installment payments, etc., for the payment of the price. When the payment of the price is completed, the payment system 1 displays a completion screen SC3 on the user terminal 30 indicating that the payment for installment payments, etc., has been made. As a result, when the user uses installment payments, etc., for the payment of the price, they will be able to see on the completion screen SC3 that the payment for installment payments, etc. has been made, so the payment system 1 can effectively improve user convenience.

[0384] [Modification 4-2] For example, as described in the second embodiment, a credit limit for installment payments may be set for the user. In this case, similar to the second embodiment, the user may be allowed to use installment payments, etc., within the limits not exceeding the credit limit. Modification 4-2 gives an example of a case where the user's credit limit is displayed on the user terminal 30.

[0385] The payment system 1 in Modification 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 such as installment payments. In Modification 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 displays a usage limit screen on the user terminal 30 based on the usage limit information. The usage limit screen is the screen displayed on the user terminal 30 that shows the usage limit. Modification 4-2 describes the confirmation screen SC5 as an example of a usage limit screen. The usage limit screen may be any screen other than the completion screen SC3. For example, the usage limit screen may be the code screen SC1, the payment source selection screen SC2, the confirmation screen SC5, the charge screen SC6, the charge source selection screen SC7, a screen solely for checking the usage limit, or any other screen.

[0387] Figure 32 shows an example of the confirmation screen SC5 in modified example 4-2. For example, the display control unit 101 generates display data for the confirmation screen SC5 showing the usage limit indicated by the usage limit information and transmits it to the user terminal 30. The display control unit 101 may also display the confirmation screen SC5 on the user terminal 30 showing at least one of the amount currently being paid in installments, etc., and the remaining amount of the usage limit. The display control unit 101 may also display the confirmation screen SC5 on the user terminal 30 including images such as icons or gauges that show these amounts.

[0388] In the modified version 4-2, the payment system 1 displays the credit limit screen on the user terminal 30 based on the credit limit information. As a result, the user can understand their credit limit on the credit limit screen on the user terminal 30, and the payment system 1 can effectively enhance user convenience.

[0389] [Modification 4-3] For example, in Modification 4-2, the display control unit 101 may display a code screen SC1 containing a code related to payment, and a code screen SC1 indicating the usage limit, as a usage limit screen on the user terminal 30. When the code C10 on the code screen SC1 is read, the processing execution unit 102 executes a payment in installments or the like based on the settings for installment payments or the like. The processing of the processing execution unit 102 may be the same as in the fourth embodiment.

[0390] Figure 33 shows an example of the code screen SC1 in Modification 4-3. For example, the display control unit 101 generates display data for the code screen SC1 that shows the credit limit indicated by the credit limit information and transmits it to the user terminal 30. The display control unit 101 may also display the code screen SC1 on the user terminal 30 that shows at least one of the amount currently being paid in installments, etc., and the remaining amount of the credit limit. The display control unit 101 may also display the code screen SC1 on the user terminal 30 that includes images such as icons or gauges that show these amounts.

[0391] In the modified version 4-3, the payment system 1 displays a code screen SC1 indicating the credit limit on the user terminal 30 as the credit limit screen. When the code C10 on the code screen SC1 is read, the payment system 1 executes a payment process such as installment payments based on the settings for installment payments, etc. This allows the user to understand their credit limit and proceed with payment using the code screen SC1, thus effectively enhancing user convenience.

[0392] [Modification 4-4] For example, in Modifications 4-2 and 4-3, information indicating whether the amount to be paid in installments, etc., is within the credit limit may be displayed on the credit limit screen. The payment system 1 in 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 amount used at the user terminal 30. In Modification 4-4, as in Modifications 1-3 and 4-2, an example is given in which 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 contained in the information acquired from the user terminal 30.

[0393] In Modification 4-4, the display control unit 101 determines whether the amount used is within the usage limit based on the usage limit information and the amount used information, and displays a usage limit screen showing the result of this 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 amount used indicated by the amount used 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 amount used indicated by the amount used information. In Modification 4-4, as in Modification 4-2, the case where the confirmation screen SC5 corresponds to the usage limit screen is given as an example. In Modification 4-4, as in Modification 4-2, the usage limit screen may be a screen other than the confirmation screen SC5.

[0394] Figure 34 shows an example of the confirmation screen SC5 in modification 4-4. For example, if the display control unit 101 determines that the usage amount is within the usage limit, it displays a confirmation screen SC5 indicating that the usage amount is within the usage limit on the user terminal 30, as shown on the left side of Figure 34. If the display control unit 101 determines that the usage amount is not within the usage limit, it displays a confirmation screen SC5 indicating that the usage amount is not within the usage limit on the user terminal 30, as shown on the right side of Figure 34. The display control unit 101 may also use other means, such as icons, to indicate on the confirmation screen SC5 whether or not the usage amount is within the usage limit, instead of a message as shown in Figure 34.

[0395] The payment system 1 in Modification 4-4 determines whether the amount to be used is within the credit limit based on the credit limit information and the amount to be used, and displays a credit limit screen showing the result of this determination on the user terminal 30. As a result, the user can see on the credit limit screen whether or not they have enough credit, so the payment system 1 can effectively improve user convenience.

[0396] [Modification 4-5] For example, in the fourth embodiment, installment payments may be used with the charge, similar to modifications 1-4, 2-7, and 3-3. Modification 4-5 differs from modification 1-4 in that it is not limited to specifying settings for installment payments from the payment app, but other aspects may be the same as modification 1-4. Modification 4-5 differs from modification 2-7 in that the usage conditions do not need to be determined, but other aspects may be the same as modification 1-4. Modification 4-5 differs from modification 3-3 in that the setting for installment payments does not need to be canceled, but other aspects may be the same as modification 1-4.

[0397] In modified example 4-5, the setting acquisition unit 104 acquires settings for installment payments, etc., in a charge where a payment method is used. For example, the setting acquisition unit 104 acquires settings for installment payments, etc., in a charge stored in the payment database DB1. The processing execution unit 102 executes processing for installment payments, etc., in a charge based on the settings for installment payments, etc., in the charge. These processes may be the same as the process in modified examples 1-4, 2-7, and 3-3 where the settings for installment payments in a charge are acquired and the processing for installment payments, etc., executed based on those settings.

[0398] The settlement system 1 in Modification 4-5 includes a charge execution unit 119. The charge execution unit 119 executes a charge based on the results of processing such as installment payments. In some cases, the charge amount may exceed the credit limit. In this case, the charge execution unit 119 does not have to execute the charge and will instead treat it as an error. However, in Modification 4-5, if the charge amount exceeds the credit limit for installment payments, the charge execution unit 119 executes the charge within the limits of the credit limit. For example, the charge execution unit 119 may execute the charge using the remaining amount of the current credit limit as the charge amount, or it may execute the charge with a charge amount less than the remaining amount of the current credit limit.

[0399] For example, suppose the remaining balance 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 the charge with the remaining balance of the credit limit, which is 8,000 yen, or it may execute the charge with an amount less than the remaining balance of the credit limit, which is 8,000 yen. The charge execution unit 119 determines the charge amount so that it falls within the range of the credit limit and executes the charge based on that charge amount.

[0400] The payment system 1 in modified example 4-5 acquires the settings for installment payments, etc., in the charge. Based on the settings for installment payments, etc., in the charge, the payment system 1 executes the processing for installment payments, etc., in the charge. If the charge amount in the charge exceeds the usage limit for installment payments, etc., the payment system 1 executes the charge within the usage limit. As a result, even if the charge amount exceeds the usage limit, the payment system 1 can execute the charge within the usage limit, thereby improving user convenience. For example, the user does not need to instruct the payment system 1 to charge again if the charge fails, so the payment system 1 can reduce the operational burden on the user and improve user convenience.

[0401] [Modification 4-6] For example, in Modification 4-5, the user may be asked whether or not to perform a charge within the limits of the usage limit. The payment system 1 in Modification 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 regarding whether or not to perform a charge within the limits of the usage limit. In Modification 4-6, the case where the inquiry is made on the charge screen SC6 is given as an example, but the charge inquiry unit 120 may make the charge inquiry on a screen other than the charge screen SC6.

[0402] Figure 35 shows an example of a charge inquiry. For example, if the charge amount exceeds the usage limit, the charge inquiry unit 120 displays a window W64 on the charge screen SC6 asking whether to perform a charge within the usage limit. The charge inquiry unit 120 displays the window W64 on the charge screen SC6 by sending display data for the window W64 to the user terminal 30. The window W64 includes a button B640 indicating to perform a charge within the usage limit and a button B641 indicating not to perform a charge within the usage limit.

[0403] In the modified example 4-6, the charge execution unit 119 performs a charge within the limits of the usage limit based on the response to the charge inquiry. The response to the charge inquiry is the user's action in response to the charge inquiry. The user gives either a first response indicating that they will perform a charge within the limits of the usage limit, or a second response indicating that they will not perform a charge within the limits of the usage limit. In the example in Figure 35, the user performs either the first or 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 the operation of the operation unit 34 and sends response data indicating the user's response to the settlement server 10. The settlement server 10 receives the response data from the user terminal 30. The charge execution unit 119 decides whether or not to perform a charge within the limits of the usage limit based on the response to the charge inquiry and the response to the charge inquiry. If the response indicates that a charge should not be performed within the limits of the usage limit, the charge execution unit 119 does not perform the charge and issues an error. If the response indicates that a charge should be performed within the limits of the usage limit, the charge execution unit 119 performs the charge within the limits of the usage limit.

[0405] In the modified version 4-6, payment system 1 prompts the user for a charge inquiry if the charge amount exceeds the usage limit, asking whether to proceed with the charge within the usage limit. Based on the response to the charge inquiry, payment system 1 proceeds with the charge within the usage limit. This allows the user to instruct payment system 1 to proceed with the charge within the usage limit in response to the charge inquiry, enabling flexible processing and effectively enhancing user convenience.

[0406] [Modification 4-7] For example, a screen showing the usage history may be displayed on the user terminal 30. The payment system 1 of Modification 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 related 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 usage history information. For example, the usage history information acquisition unit 121 acquires usage history information when the display of the usage history screen described later is instructed.

[0407] In the modified example 4-7, the display control unit 101 displays a usage history screen showing the usage history related to installment payments, etc., on the user terminal 30 based on the usage history information. For example, the display control unit 101 displays the usage history screen on the user terminal 30 by generating display data for the usage history screen that includes at least some of the usage history information shown in the usage history information and sending it to the user terminal 30. The usage history information may include the date and time of use of the payment app, the amount used, or whether or not installment payments, etc., were made.

[0408] Figure 36 shows an example of the usage history screen in Modification 4-7. For example, the display control unit 101 displays a usage history screen SC9 on the user terminal 30, which shows the usage history of payments or charges made by the user from the payment app, based on the usage history information. The display control unit 101 determines whether or not installment payments were used for each transaction based on the information on whether or not installment payments were used, as indicated in the usage history information. If a lump-sum payment is not changed to installment payments, the usage history information will indicate that the lump-sum payment was not changed to installment payments. For usage history where a lump-sum payment was not changed to installment payments, the display control unit 101 displays the usage history screen SC9 on the user terminal 30 to indicate that a lump-sum payment was made. For example, the display control unit 101 may determine whether or not installment payments are available for each transaction based on the information on whether or not installment payments are available, as indicated in the usage history information. For example, in the same manner as in the first embodiment, if it is determined whether or not installment payments are possible at a store or for an amount, and it is determined that installment payments are possible, the display control unit 101 may display content for which installment payments can be applied for.

[0409] For example, for transactions where installment payments were not used, the display control unit 101 displays information such as the date and time of use on the transaction history screen SC9 without displaying information indicating that installment payments were used. For transactions where installment payments were used, the display control unit 101 displays information such as the date and time of use along with information indicating that installment payments were used on the transaction history screen SC9. In Figure 36, messages such as "Applied for 3 installments" or "Applied for 5 installments" correspond to information indicating that installment payments were used. The information indicating that installment payments were used is not limited to messages, but may also be an image such as an icon.

[0410] In the modified version 4-7, the payment system 1 displays a usage history screen SC9 on the user terminal 30, which shows the usage history related to installment payments, etc., based on the usage history information. As a result, the user can understand the usage history related to installment payments, etc., on the usage history screen SC9, and the payment system 1 can effectively enhance user convenience.

[0411] [Modification 4-8] For example, in Modification 4-7, it may be possible to apply for installment payments, etc., from the transaction history screen SC9. The payment system 1 in Modification 4-8 includes an application acceptance unit 122. The application acceptance unit 122 accepts applications for installment payments, etc., from the transaction history screen SC9. In Modification 4-8, it is possible to apply for installment payments, etc., for transactions where the credit card has not been debited. Applications for installment payments, etc., are made by operating the transaction history screen SC9.

[0412] For example, the display control unit 101 identifies transactions from the transaction history information that have not resulted in a credit card deduction. The payment server 10 in the modified example 4-8 is capable of obtaining information from the card server 20 indicating whether or not a credit card deduction has been made. The display control unit 101 can then identify transactions that have not resulted in a credit card deduction based on this information.

[0413] For example, the display control unit 101 may display an image on the usage history screen SC9 to accept applications for installment payments for transactions that were not eligible for installment payments and for which the credit card payment has not yet been debited. In the example of the usage history screen SC9 in Figure 36, the 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 debited. In this case, the display control unit 101 displays a button such as "Click here for installment payments" in the payment section of the usage history screen SC9. When the user selects the button, the payment is changed to installment payments retroactively.

[0414] In the modified example 4-8, the processing execution unit 102 executes installment payment processing when an application is accepted. For example, the processing execution unit 102 sends the usage information of the application to the card server 20 and requests that it be changed to installment payment. The processing execution unit 102 may also execute installment payment processing by changing the usage information stored in the settlement database DB1 to installment payment. The process of changing a lump-sum payment to installment payment may be the same as the process of a known card service. The settlement server 10 executes the subsequent change to installment payment by sending data in the format specified by the card service API to the card server 20.

[0415] In the modified example 4-8, payment system 1 accepts applications for installment payments, etc., from the transaction history screen SC9. When an application is accepted, payment system 1 executes the installment payment processing. As a result, users can change to installment payments, etc. retrospectively from the transaction history screen SC9, so payment system 1 can effectively enhance user convenience.

[0416] [Modification 4-9] For example, in the fourth embodiment, as in the modified example 2-11, it may be possible to use points or the like for payment. Modified example 4-9 differs from modified example 4-9 in that the usage conditions as in modified example 2-11 may be determined, or in particular, the usage conditions as in modified example 2-11 may not be determined. In modified example 4-9, if payment is made using a payment method other than the payment method, the processing execution unit 102 performs processing based on the value obtained by subtracting the amount paid by the other payment method from the amount used at the user terminal 30. If the user specifies the amount to be paid, the payment server 10 obtains the amount specified by the user from the user terminal 30 or the store terminal 40. The amount to be paid may be a fixed value. In this case, the amount to be paid may be stored in advance in the payment database DB1.

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

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

[0419] In the modified example 4-9, when payment is made using a payment method other than the specified payment method, the payment system 1 performs processing based on the amount obtained by subtracting the amount paid by the other payment method from the amount used at the user terminal 30. This allows the payment system 1 to appropriately perform processing for installment payments, etc., even when points or similar items are used for payment.

[0420] [Modification 4-10] For example, the setting acquisition unit 104 may acquire a setting indicating the number of installment payments or revolving payments that cannot be specified when the payment method is used by means other than the user terminal 30. Other means include other payment applications other than the payment application described in the fourth embodiment, a physical card, or the IC chip of the user terminal 30. For example, the number of installment payments or revolving payments for a credit card may have predetermined numbers that the user cannot select. In the payment application of Modification 4-10, it may be possible to specify such numbers.

[0421] Modification 4-10 describes a credit card as an example of a payment method that is eligible for installment payments, etc. Assume that with a physical credit card, it is not possible to specify 4 installments as the number of installments or revolving payments. However, with a payment app, 4 installments, which cannot be specified with a physical credit card, can be specified as the number of installments or revolving payments. Assume that data indicating such installments is stored in the data storage unit 100. Assume that the card server 20 supports processing installment payments or revolving payments of such an number.

[0422] For example, if the number of installment payments or revolving payments is specified in the payment app in the same manner as in the first embodiment, the display control unit 101 displays a setting screen on the user terminal 30 that allows the user to specify the number of installment payments or revolving payments indicated by the number of installments data (the number of installment payments or revolving payments that cannot be specified with a physical credit card). The setting acquisition unit 104 may acquire the number of installment payments or revolving payments specified on the setting screen as an installment payment setting. If the number of installment payments or revolving payments is specified by a method other than a setting screen like in the first embodiment, as described in the fourth embodiment and modified examples 4-1 to 4-10, the setting acquisition unit 104 may acquire the number of installment payments or revolving payments specified by the other method as an installment payment setting.

[0423] In the modified example 4-10, the processing execution unit 102 executes processing related to installment payments or revolving payments based on the number of installment payments or revolving payments indicated by the installment payment settings. This differs from the fourth embodiment in that the number of installment payments or revolving payments that can be specified as installment payment settings cannot be specified for other payment methods, but the method by which the processing execution unit 102 executes the installment payment processing based on the installment payment settings may be the same as in the fourth embodiment.

[0424] The payment system 1 in modified example 4-10 acquires a setting indicating the number of installment payments or revolving payments that cannot be specified when the payment method is used by means other than the user terminal 30. The payment system 1 executes processing related to installment payments or revolving payments based on the number of installment payments or revolving payments indicated by the installment payment setting. As a result, the user can use the number of installment payments or revolving payments that cannot be specified by other means from the payment app, so the payment system 1 can effectively improve user convenience.

[0425] [Variation 4-11] For example, the setting acquisition unit 104 may acquire settings relating to usage conditions specified by the user, such as whether or not the user will use installment payments. The usage conditions may be the same as those in the second embodiment. In modification 4-11, the user can specify arbitrary usage conditions. Modification 4-11 gives an example where the usage condition is that the usage amount is equal to or greater than a predetermined amount. The predetermined amount that constitutes the usage condition can be freely specified by the user, but at least one of the upper and lower limits of the value that can be specified as the predetermined amount may be defined.

[0426] For example, the user terminal 30 displays a screen for specifying the amount to be used, either from the payment app screen or another screen. The user can specify any amount from this screen. For example, the user can specify a usage condition such as "use installment payments if the amount used is 100,000 yen or more." The user terminal 30 sends data to the payment server 10 indicating the amount specified on that screen. The payment server 10 receives this data.

[0427] For example, the setting acquisition unit 104 stores the setting indicated by the data in the payment database DB1. The setting acquisition unit 104 can acquire the settings for installment payments, etc., stored in the payment database DB1 at any time. The usage conditions that the user can specify are not limited to the amount used. For example, the user may be able to specify the store used, the goods or services to be paid for, the date and time of use, or other usage conditions.

[0428] In the modified example 4-11, the processing execution unit 102 executes installment payment processing based on the usage conditions indicated by the installment payment settings. For example, the pr...

Claims

[Claim 1] A setting acquisition unit that acquires the user's settings regarding installment payments, revolving credit, or bonus payments for available payment methods, A processing execution unit that performs processing related to installment payments, revolving payments, or bonus payments based on the above settings, A setting release unit that releases the setting based on predetermined release conditions, A payment system that includes this.

Images