JP7776559B2 - Bill payment system, bill payment method, and program - Google Patents

Description

This disclosure relates to a bill payment system, a bill payment method, and a program.

Conventionally, bills have been used to pay for utilities, merchandise, and the like. For example, Patent Document 1 describes the payment of a bill indicated by bill information sent to a user's user terminal on a payment date and time designated by the user. Patent Document 1 also describes the payment of a bill based on pre-charged electronic money or a pre-registered credit card.

Japanese Patent Application Laid-Open No. 2023-085846

However, with the technology of Patent Document 1, if the user does not have enough electronic money on the scheduled payment date and time, the payment will fail. If the payment fails, the user will need to make a new reservation or pay a late fee. While it is possible to provide some kind of notification to the user when the payment fails, simply providing a notification would only let the user know that the payment has failed, and would not sufficiently improve user convenience.

One of the goals of this disclosure is to increase user convenience.

The bill payment system disclosed herein includes a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails, and a notification unit that sends the user a payment failure notification regarding the cause of the payment failure based on the failure cause information.

This disclosure can increase user convenience.

FIG. 1 is a diagram illustrating an example of the hardware configuration of a bill payment system. FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal. FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal. FIG. 1 is a diagram illustrating an example of functions implemented in a bill payment system. FIG. 10 is a diagram illustrating an example of a payment service database. FIG. 1 is a diagram illustrating an example of processing performed in a bill payment system. FIG. 10 is a diagram illustrating an example of a function realized in a modified example. FIG. 10 is a diagram showing an example of a payment failure notice according to the first modification. FIG. 11 is a diagram showing an example of a payment failure notice in Modification 3. FIG. 13 is a diagram showing an example of a payment failure notice according to the fourth modification. FIG. 13 is a diagram showing an example of a payment failure notice according to the fifth modification example. FIG. 20 is a diagram showing an example of a notification in Modification Example 7.

[1. Hardware configuration of bill payment system]
An example of an embodiment of a bill payment system, bill payment method, and program according to the present disclosure will be described. Figure 1 is a diagram showing an example of the hardware configuration of a bill payment system. For example, the bill payment system 1 includes a payment service provider server 10, a card company server 20, a receiving organization server 30, and a user terminal 40. Each of the payment service provider server 10, the card company server 20, the receiving organization server 30, and the user terminal 40 is connected to a network N such as the Internet or a LAN.

The payment provider server 10 is a server computer of a payment provider that operates a payment service. The payment service is a service that provides users with electronic payments (cashless payments). For example, the payment provider server 10 includes a control unit 11, a memory unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The memory unit 12 includes at least one of 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.

The card company server 20 is a server computer of the card company that issued the credit card. For example, the card company server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. In this embodiment, an example is given in which the card company is different from the payment service provider, but the card company may also be the same as the payment service provider.

The collection organization server 30 is a server computer of a collection organization that collects invoices on behalf of the collection organization. A collection organization is sometimes called a collection agent. For example, the collection organization server 30 includes a control unit 31, a memory unit 32, and a communication unit 33. The hardware configurations of the control unit 31, the memory unit 32, and the communication unit 33 may be similar to the control unit 11, the memory unit 12, and the communication unit 13, respectively. This embodiment cites an example in which the collection organization is different from the payment service provider and the card company, but the collection organization may also be the same as at least one of the payment service provider and the card company.

The user terminal 40 is a user's computer. For example, the user terminal 40 is a smartphone, tablet, personal computer, or wearable terminal. The user terminal 40 includes a control unit 41, a memory unit 42, a communication unit 43, an operation unit 44, a display unit 45, and an imaging unit 46. The hardware configurations of the control unit 41, the memory unit 42, and the communication unit 43 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 44 is an input device such as a touch panel or a mouse. The display unit 45 is a display such as an LCD or organic EL. The imaging unit 46 includes at least one camera.

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

Furthermore, the bill payment system 1 only needs to include at least one computer. The computers included in the bill payment system 1 are not limited to the example shown in Figure 1. For example, the bill payment system 1 may include only the payment service provider server 10. In this case, the card company server 20, the collection organization server 30, and the user terminal 40 are external to the bill payment system 1. For example, the bill payment system 1 may include the payment service provider server 10 and other computers not shown in Figure 1.

[2. Overview of the bill payment system]
In this embodiment, an example is taken of a case where a user uses a payment service from a payment app installed on a user terminal 40. The payment app is an application provided by a payment service provider. For example, when a user scans a code (e.g., a barcode or a two-dimensional code) displayed on the payment app with a terminal of a member of the payment service, payment is executed based on a pre-specified payment method.

The payment methods available to users of payment services may be of any type. A payment method is a method used by a user to make a payment. For example, a payment method may be a credit card, electronic money, points, cryptocurrency, debit card, wallet, account such as a bank account, sales proceeds from an online flea market service, or other method. Codes such as barcodes or two-dimensional codes are also a means of payment and therefore qualify as payment methods. A payment method can also be called a payment method.

Furthermore, the payment methods available to users for the payment service are not limited to having the affiliated party's terminal read a code displayed on the payment app. Any payment method may be used. For example, the payment method may be a type in which a code displayed on the affiliated party's terminal is read by the user terminal 40, a type in which a code posted at the affiliated party's facility is read by the user terminal 40, a type that is completed by operating the user terminal 40 alone, a type that uses the IC chip in the user terminal 40, online payment (for example, account payment using the user's account, or ID payment using the user's ID), carrier payment, which is payment by the carrier used by the user terminal 40, or any other type.

In this embodiment, a bill payment service is provided as one of the payment services. The bill service is a service that allows users to pay bills from a payment app. Invoices may be physical paper or electronic data. Invoices are also sometimes called payment slips or payment slips. Invoices can be used for any payment. For example, invoices can be used to pay utility bills such as electricity or gas, pay for goods or services, pay taxes, or for other payments.

In this embodiment, the invoice is a physical piece of paper. The invoice may be in any format. For example, an invoice ID, which is an ID used to identify the invoice, the name of the payee, information about the payee's account, the name of the collection organization, the payment amount, the payment deadline, and a code (e.g., a barcode or two-dimensional code) are printed on the invoice. While a user can pay an invoice at a store such as a convenience store, in this embodiment, the user operates the user terminal 40 to read the invoice with a payment app and pay the invoice.

Figures 2 and 3 are diagrams showing examples of screens displayed on the user terminal 40. For example, when a user launches a payment app, the user terminal 40 displays a top screen SC1, which corresponds to the first view of the payment app, on the display unit 45. The payment app allows the user to perform various operations to use payment services. In this embodiment, operations performed by a user to use a bill payment service, which is one of the payment services, are described. For example, when a user selects button B10 for using the bill payment service in the payment app, the user terminal 40 launches the capture unit 46. As shown in the upper right corner of Figure 2, the user terminal 40 displays a capture screen SC2, which shows a captured image generated by the capture unit 46, on the display unit 45. The user terminal 40 reads the bill code shown in the captured image.

For example, the invoice code is generated based on information required for payment. This information may be information used in publicly known invoices. For example, the invoice code is generated based on at least one of an invoice ID that can identify an individual payment, a payee ID that can identify the payee, a receiving organization ID that can identify the receiving organization, the payment amount, and the payment deadline. When the user terminal 40 reads this information from the invoice code, the user terminal 40 may display a reservation screen SC3 showing the details of the invoice on the display unit 45 based on this information, as shown in the lower left of Figure 2.

In this embodiment, an example is taken of a case where a user pays a bill using online electronic money. For example, the user's electronic money balance is displayed on the user terminal 40. The user can make an immediate payment by selecting button B30. The processing in this case may be similar to the processing employed in known bill payment services. By selecting button B31, the user can schedule a payment rather than making an immediate payment.

For example, when a user selects button B31, the user terminal 40 executes a reservation process with the payment provider server 10, allowing the user to reserve payment of the invoice. The reservation process may be similar to known processes. For example, the user specifies the payment timing. The payment timing is the timing at which payment is made. In this embodiment, an example is given in which the payment timing is expressed only by date, but the payment timing may also be expressed by a date and time that includes not only the date but also the time. The user can specify any payment timing. However, if a payment deadline is set for the invoice, the user will generally specify the payment timing up to the payment deadline.

For example, when a user makes a payment using electronic money, if the user's electronic money balance is insufficient at the time of payment, the payment will result in an error. For this reason, the user needs to manage their electronic money balance so that it does not become insufficient. In this embodiment, the user can perform operations to top up their electronic money from the reservation screen SC3. Furthermore, the user can reserve an electronic money top-up. A top-up reserved by the user is carried out automatically, so it is a type of auto-top-up.

For example, the user can specify the charge amount, the charge method (payment method used to fund the charge), and the charge timing from the reservation screen SC3. The charge timing is the timing at which the charge is carried out. In this embodiment, an example is given in which the charge timing is expressed only by date, but the charge timing may also be expressed by a date and time that includes not only the date but also the time. The user can specify any charge timing.

For example, when the user has completed all reservation operations, the user terminal 40 displays on the reservation screen SC3 that the payment reservation and charge reservation have been completed, as shown in the lower right of Figure 2. Once the payment reservation and charge reservation are completed, the charge is carried out at the charge timing specified by the user, and the payment is carried out at the payment timing specified by the user. In the example in the lower right of Figure 2, the charge is carried out some time before the payment timing.

For example, bill payments can fail for a variety of reasons. Payments can fail due to insufficient electronic money balance, insufficient points balance, credit card suspension, an error in the payment service provider server 10, an error in the card company server 20, an error in the collection organization server 30, a communication failure, or other reasons. Payments can fail for a variety of reasons not only when a user schedules a payment, but also when a user selects button B30 to make an immediate payment. In this embodiment, if bill payment fails, the user is notified according to the cause of the payment failure. Hereinafter, this notification will be referred to as a payment failure notification.

For example, if a user selects icon I11 on the top screen SC1 and selects Payment Failure Notification, the user terminal 40 causes the display unit 45 to display a notification screen SC4 indicating the contents of the Payment Failure Notification, as shown in the upper left of Figure 3. In this embodiment, the payment failure notification is displayed on the notification screen SC4 using the notification function of the payment app. In the example in the upper left of Figure 3, the payment failure notification indicates that the payment failed because the user's electronic money balance was insufficient. The reason indicated in the payment failure notification varies depending on the cause of the payment failure. For example, if the cause is an insufficient points balance, the payment failure notification will indicate that cause. If the cause is a suspended credit card, the payment failure notification will also indicate that cause. Similarly, for other causes, the payment failure notification will also indicate the other cause.

In this embodiment, the payment failure notification can accept operations related to bill payment. In the example in the upper left of Figure 3, the payment failure notification includes a button B40 that allows the user to change the reservation details. Button B40 includes a link to the bill payment service. The user checks the payment failure notification and determines whether or not the reservation details need to be changed. When the user checks the payment failure notification, the scheduled payment has failed, so the user can determine whether or not a new reservation is necessary. In the example in the upper left of Figure 3, the user used electronic money after auto-charging, resulting in insufficient electronic money balance, causing the payment to fail. For example, the user changes the payment timing to just before the payment deadline, allowing time for electronic money charging. In other words, the user schedules another payment so that it occurs just before the payment deadline.

For example, when a user selects button B40, the user terminal 40 displays a list screen SC5 on the display unit 45, as shown in the upper right of Figure 3, that shows a list of reservations made by the user. The user selects button B50 to change the reservation details indicated in the payment failure notification. Changes to the reservation details can be made from a screen similar to the reservation screen SC3. Button B50 may include information indicating that the payment failed. The user can change any item in the reservation details. For example, the user can change the payment timing to just before the payment deadline. The user can also change the reservation details so that payment is made using a payment method other than electronic money. The user terminal 40 may display the reservation screen SC3 instead of the list screen SC5, and have the user make a new reservation for the failed payment.

As described above, in the bill payment system 1 of this embodiment, if a payment fails, the user is notified of the payment failure on the payment app. The payment failure notification allows the user to understand not only the fact that the payment has failed, but also the cause of the failure. This allows the user to take action according to the cause of the payment failure after checking the payment failure notification. In the example in the upper left of Figure 3, the user would select the payment failure notification button B40 to change the reservation details and prevent the payment from failing again for the same reason. In this way, the bill payment system 1 can improve user convenience. Details of the bill payment system 1 will be explained below.

[3. Functions realized by the bill payment system]
Figure 4 is a diagram showing an example of the functions realized by the bill payment system 1. The various parts realized by the bill payment system 1 can be configured as a single device or as more finely divided devices.

[3-1. Functions realized by the payment service provider server]
For example, the payment service provider server 10 includes a data storage unit 100, a reservation acceptance unit 101, a payment execution unit 102, a cause of failure information acquisition unit 103, and a notification unit 104. The data storage unit 100 is realized by the memory unit 12. The reservation acceptance unit 101, the payment execution unit 102, the cause of failure information acquisition unit 103, and the notification unit 104 are each realized by the control unit 11.

[Data storage unit]
The data storage unit 100 stores data necessary for the payment service. For example, the data storage unit 100 stores a payment service database DB.

Figure 5 shows an example of a payment service database DB. The payment service database DB is a database that stores various information related to users. For example, the payment service database DB stores user IDs, passwords, code IDs, notification destination information, notification information, payment method information, payment history information, charge method information, reservation history information, and payment result information. The payment service database DB may also store other data. For example, the payment service database DB may store information about payment methods used by users to make payments using codes displayed on the payment app, and charge history information related to past charge history.

The user ID for the payment service is an example of user identification information that can identify the user in the payment service. A login account may exist in addition to the user ID. The login account may be freely changeable by the user. The password is information that is confirmed when logging in. The code ID is also an example of user identification information, as it is an ID that can identify the user in the payment service. The code ID is updated each time the code is displayed in the payment app. Any information may be used as user identification information.

Notification destination information is information relating to the notification destination. The notification destination is the destination to which the notification is sent. The notification destination can also be referred to as the destination of the notification. The notification destination information may be information corresponding to the notification means used by the notification unit 104, which will be described later. The notification means is the means used for notification. The notification means can also be referred to as notification media or contact means. The notification means may be a notification function on an application such as a payment app, email, SMS, a messaging app, SNS, push notification, banner notification, pop-up, window, modal, or other means. Notifications may be made using a combination of multiple notification means.

In this embodiment, the notification function of the payment app is used as the notification means, so the notification destination information does not need to be stored in the payment service database DB. If email is used as the notification means, the notification destination information indicates the user's email address. For example, if SMS is used as the notification means, the notification destination information indicates the user's phone number. If a messaging app is used as the notification means, the notification destination information indicates an account in the messaging app. If SNS is used as the notification means, the notification destination information indicates an account in the SNS. Similarly, if another means is used as the notification means, the notification destination information only needs to be information that can identify the user in some way when that other means is used.

Notification information is information related to notifications sent to users. Notification information indicates the content of the notification. For example, notification information may include text, images such as buttons or icons, links, unread/read information, the importance of the notification, the time the notification was made, or other information. This embodiment takes as an example a case where the notification function of a payment app is used, so when the payment app needs to notify the user of something, the payment business operator server 10 generates notification information indicating the content of the notification. The payment business operator server 10 associates the notification information with the user ID of the user and stores it in the payment service database DB.

Payment method information is information that identifies the payment methods that a user can use with a payment service. For example, payment method information is information such as a credit card number, electronic money number, account information such as a bank account, or point card number balance. Payment history information is information related to the user's usage history of a payment service. For example, payment history information indicates the date and time of payment, the payment location, the payment amount, the payment target, or a combination of these. When a user makes a payment, the payment history information is updated to indicate the details of that payment.

Charging method information is information that can identify the charging method specified by the user. For example, charging method information is information such as a credit card number, account information such as a bank account, information such as the number of other electronic money that will serve as the source of funds, or information for identifying sales proceeds from online flea market services. The user can specify any payment method indicated in the payment method information other than the electronic money being charged as the charging method. When the user changes the charging method, the payment service provider server 10 updates the charging method information.

In this embodiment, the case where the charging means corresponds to the payment source is taken as an example, and therefore charging means information is an example of payment source information that can identify the payment source. Therefore, the phrase "charging means information" can be read as "payment source information." If the payment means indirectly used in payment is a payment means other than the charging means (for example, a payment means used in conjunction with the main payment means), the payment source information is information that can identify the other payment means. If a directly used payment means, which is a payment means directly used in payment, corresponds to the payment source, the payment source information is information that can identify the directly used payment means.

A directly used payment source is a payment method through which payment is made at the time of payment. In other words, a directly used payment source is a payment method that serves as the source of funds at the time of payment. In this embodiment, electronic money is described as an example of a directly used payment source. Therefore, any section describing electronic money used for payment can be read as a directly used payment source. A directly used payment source may be a credit card, points, cryptocurrency, debit card, wallet, account such as a bank account, sales proceeds from an online flea market service, or other means. In this embodiment, an example is given in which a directly used payment source is a rechargeable payment method, but a directly used payment source does not have to be rechargeable.

An indirectly used payment source is a payment method that provides funds for a directly used payment source. An indirectly used payment source is a different payment method from a directly used payment source. In other words, an indirectly used payment source is a method by which payment (also known as charging, transferring, or converting) is made before the time of payment. In this embodiment, a credit card is described as an example of an indirectly used payment source. Therefore, any description of a credit card used to pay a bill can be read as an indirectly used payment source. An indirectly used payment source may be electronic money, points, cryptocurrency, debit card, wallet, account such as a bank account, sales proceeds from an online flea market service, or other means. Note that a user may be able to set a directly or indirectly used payment source in the payment app.

Reservation history information is information related to the reservation history of invoices reserved by the user. For example, reservation history information indicates at least one of payment reservations and charge reservations. Reservation history information indicates an invoice ID that can identify the invoice that was the subject of the payment reservation, the payment reservation details specified by the user (for example, at least one of the payment timing specified by the user and information on the directly used payment method specified by the user), and the charge reservation details specified by the user (for example, at least one of the conditions such as the charge timing specified by the user, information on the charge method specified by the user, and the charge amount specified by the user). In this embodiment, an example is given in which reservation history information is stored in the payment service database DB for each invoice, but one piece of reservation history information may also indicate reservation details specified for multiple invoices. Reservation history information may also include information on invoice details such as at least one of the payee, payment amount, and payment deadline.

For example, if the user specifies a payment timing, the reservation history information will indicate the payment timing specified by the user. If the user specifies a charge timing, the reservation history information will indicate the charge timing specified by the user. If the user does not make a charge reservation, the reservation history information will only indicate information related to the payment reservation. The user may specify multiple charge timings for a single bill. For example, the user may specify both a charge timing that occurs before the payment timing and a charge timing that occurs after the payment timing. By specifying a charge timing that occurs after the payment timing, the user can restore the balance of electronic money that was reduced by paying the bill so that the electronic money can be used for payments other than paying the bill.

Payment result information is information about the result of a payment. It can also be said to be information about the processing results of the payment execution unit 102, described below. For example, payment result information includes the success or failure of the payment, the reason for the payment failure, the date and time of the payment, or other information. In this embodiment, failure cause codes that can identify the cause of a payment failure are predefined. For example, a failure cause code of 1 means that the payment failed due to an insufficient balance of electronic money. A failure cause code of 2 means that the payment failed due to an insufficient balance of points. Similarly, failure cause codes corresponding to other causes are prepared for other causes. Data indicating which failure cause code means which cause is assumed to be pre-stored in the data storage unit 100. The payment execution unit 102, described below, generates payment result information based on the result of the payment execution and stores it in the payment service database DB.

Note that the data stored in the data storage unit 100 is not limited to the above example. The data storage unit 100 may store any data necessary for the payment service. For example, the data storage unit 100 may store data for various screens displayed on the payment app. The data storage unit 100 may also store template data indicating templates for notifications made by the notification unit 104, described below. For example, when notifications are made on the payment app, the data storage unit 100 displays a default message for notifications on the payment app. When email is used for notifications, the data storage unit 100 stores template data indicating templates for email. When other notification means are used, the data storage unit 100 may also store template data indicating templates for other notification means.

[Reservations Department]
The reservation reception unit 101 accepts reservations for bill payments. For example, the reservation reception unit 101 accepts reservations by obtaining reservation content information regarding the reservation content of bill payments from the user terminal 40. The reservation content information indicates at least one of a payment reservation and a charge reservation. The items included in the reservation content information may be the same as the reservation history information. For example, the reservation content information indicates the bill ID, payment timing, information on the directly used payment method, charge timing, information on the charge method, charge conditions, or a combination of these. The items included in the reservation content information may be the same as the reservation history information.

The reservation reception unit 101 only needs to accept a reservation for the payment of at least one invoice, and may accept reservations for the payment of multiple invoices. The user terminal 40 generates reservation content information related to the reservation details entered by the user on the reservation screen SC3 and transmits the reservation content information to the payment provider server 10. The user terminal 40 also transmits the user's user ID to the payment provider server 10. For example, when the reservation reception unit 101 accepts a reservation, it associates the reservation content information received from the user terminal 40 with the user ID and stores it as reservation history information in the payment service database DB.

[Payment Execution Department]
The payment execution unit 102 executes payment processing. The payment processing is a payment based on a directly used payment means that is directly used for payment. In this embodiment, since electronic money is used as the directly used payment means, the payment processing is a process of reducing the balance of electronic money. If the directly used payment means is another payment means, the payment processing may be a payment processing based on the other payment means. For example, if the directly used payment means is a credit card, the payment processing is a payment processing based on the credit card. If the directly used payment means is an account such as a bank account, the payment processing is a process of debiting the account. If the directly used payment means is another payment means, the payment processing may be a payment processing based on the other payment means. Note that payment processing may also be performed using multiple directly used payment means.

The payment execution unit 102 can refer to the reservation history information in the payment service database DB and determine the timing of payment. The payment execution unit 102 can refer to the reservation history information in the payment service database DB and determine the timing of payment. The payment execution unit 102 can refer to the reservation history information, etc. in the payment service database DB and execute the payment process. The payment execution unit 102 can execute not only payments reserved by the user, but also payments instructed by the user when they scan the invoice. The only difference is when the payment is executed, and the processing for payment is the same.

In this embodiment, if the payment fails, the payment execution unit 102 stores payment result information including failure cause information indicating the cause in the payment service database DB. For example, if the electronic money balance is less than the payment amount, the payment execution unit 102 determines that the payment has failed, generates payment result information including payment cause information indicating that the cause was an insufficient balance (for example, 1, meaning that the electronic money balance is insufficient), and stores the payment result information in the payment service database DB. If the points balance is less than the payment amount, the payment execution unit 102 determines that the payment has failed, generates payment result information including payment cause information indicating that the cause was an insufficient balance (for example, 2, meaning that the points balance is insufficient), and stores the payment result information in the payment service database DB.

For example, if the directly used payment method is a credit card, the payment execution unit 102 requests a credit card payment from the card company server 20 and receives a notification from the card company server 20 that the credit card has been suspended. In this case, the payment execution unit 102 generates payment result information including payment cause information indicating that the suspension of the credit card was the cause (for example, 3, meaning that the credit card was suspended), and stores the payment result information in the payment service database DB. If an error occurs within the payment provider server 10 during payment, the payment execution unit 102 determines that the payment failed, generates payment result information including payment cause information indicating that the error in the payment provider server 10 was the cause (for example, 4, meaning that the error in the payment provider server 10 was the cause), and stores the payment result information in the payment service database DB.

In addition, if the payment fails for another reason, the payment execution unit 102 may similarly generate payment result information including payment cause information indicating the other reason and store the payment result information in the payment service database DB. The payment execution unit 102 may also obtain other information from the payment result information other than the payment cause information using a known method. The payment cause information may be separate data from the payment result information. In this case, the payment execution unit 102 may generate the payment cause information as separate data from the payment result information and store it in the payment service database DB.

[Failure cause information acquisition part]
When a user's payment of a bill fails, the failure cause information acquisition unit 103 acquires failure cause information regarding the cause of the payment failure. In this embodiment, the failure cause information is stored in the payment service database DB, so the failure cause information acquisition unit 103 acquires the failure cause information from the payment service database DB. In this embodiment, the failure cause information is included in the payment result information, so the failure cause information acquisition unit 103 acquires the failure cause information included in the payment result information stored in the payment service database DB.

Note that if the failure cause information is separate data from the payment result information (i.e., if the failure cause information is not included in the payment result information), the failure cause information is stored separately from the payment result information in the payment service database DB. The failure cause information acquisition unit 103 simply acquires the failure cause information stored separately from the payment result information from the payment service database DB. The failure cause information may be stored in a database other than the payment service database DB. In this case, the failure cause information acquisition unit 103 acquires the failure cause information from the other database. The failure cause information may be stored in a computer other than the payment service provider server 10 or in an external information storage medium. In this case, the failure cause information acquisition unit 103 acquires the failure cause information from the other computer or external information storage medium.

[Notification Department]
The notification unit 104 issues a payment failure notification to the user regarding the cause of the payment failure based on the failure cause information. The payment failure notification is a notification indicating the cause of the payment failure. The cause of the payment failure is indicated by a character string or an image. The cause of the payment failure is not limited to a form understandable to the user in natural language, and may be indicated by a failure cause code. Data necessary for the payment failure notification is stored in the data storage unit 100. The data may be a character string in natural language indicating the cause of the payment failure, or an image indicating the cause of the payment failure. The notification unit 104 issues a payment failure notification to the user based on the data. In this embodiment, an example is given in which the notification unit 104 issues a payment failure notification to the user after the payment timing arrives and the payment fails, but the notification unit 104 may also issue a notification other than a payment failure notification. For example, the notification unit 104 may issue another notification to the user before a reservation is made. As in Variation 7 described below, when the payment timing is predicted based on reservation history, etc., the notification unit 104 may issue another notification based on the predicted payment timing.

In this embodiment, the notification unit 104 can notify the user of the payment failure at any timing after the payment has failed. For example, the notification unit 104 may notify the user of the payment failure immediately after the payment has failed, or may notify the user of the payment failure after a certain amount of time has passed since the payment has failed. The notification unit 104 may notify the user based on notification destination information stored in the payment service database DB.

In this embodiment, the notification unit 104 determines whether the payment is successful or not based on the processing result of the payment execution unit 102. For example, the notification unit 104 determines whether the payment is successful or not based on the success or failure of the payment indicated by the payment result information stored in the payment service database DB. The notification unit 104 determines that the payment is successful if the payment result information indicates success of the payment, and determines that the payment is unsuccessful if the payment result information indicates failure of the payment. The method for determining whether the payment is successful or not may be a known method. For example, the notification unit 104 may determine whether the payment is successful or not based on the results of communication with the card company server 20 and the collection organization server 30.

In this embodiment, the notification function of the payment app is used, so when a payment fails, the notification unit 104 inserts information about the payment that is the subject of the notification into the template indicated by the template data, based on the payment result information stored in the payment service database DB. In the example in the upper left of Figure 3, the notification unit 104 inserts information such as the payee and payment amount into the template. For example, the template indicates the standard text at the beginning of the notification shown on the notification screen SC4 in the upper left of Figure 3 (for example, a sentence such as "The following payment has failed..."). The notification unit 104 inserts information such as the payee and payment amount after the standard text.

For example, the notification unit 104 generates a link to the list screen SC5 and inserts a button B40 including the link into the template. Data related to the link on the list screen SC5 is assumed to be stored in advance in the data storage unit 100. The notification unit 104 can identify the link to be embedded in the button B40 based on the data. The notification unit 104 may insert information such as arguments specific to the user into the link indicated by the data, and then generate the link to be embedded in the button B40. The notification unit 104 generates notification information indicating the payment failure notification generated as described above, associates it with the user ID of the user sending the payment failure notification, and stores the notification information in the payment service database DB.

The method by which the notification unit 104 notifies the user of a payment failure is not limited to the above example. The notification unit 104 may notify the user of a payment failure in a manner appropriate to the notification means. For example, the payment failure notification on the payment app is not limited to the notification displayed on the notification screen SC4 when the user selects icon I11 on the top screen SC1. The payment failure notification on the payment app may also be a pop-up, banner, or other notification. As another example, if email is used to notify the payment failure, the notification unit 104 may send an email as a payment failure notification to the user's email address indicated in the notification destination information. The notification unit 104 may generate the email in the same way as the notification on the payment app. For example, the notification unit 104 may send an email to the user's email address that includes details of the payment that is the subject of the payment failure notification and a link to the list screen SC5.

For example, if SMS is used for payment failure notifications, the notification unit 104 can send an SMS message as a payment failure notification to the user's telephone number indicated in the notification destination information. The notification unit 104 can generate the SMS message in the same way as email. For example, the notification unit 104 can send an SMS message to the user's telephone number that includes the reservation details of the reservation that is the subject of the payment failure notification and a link to the list screen SC5.

For example, if a message app is used for the payment failure notification, the notification unit 104 can send a message in the message app as a payment failure notification to the user's account indicated by the notification destination information. The notification unit 104 can generate a message in the message app in the same way as an email. For example, the notification unit 104 can send a message in the message app to the user's account that includes the reservation details of the reservation that is the subject of the payment failure notification and a link to the list screen SC5. Similarly, if another notification means is used, the notification unit 104 can notify the user of the payment failure in a manner appropriate to the other notification means.

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

[Data storage unit]
The data storage unit 200 stores data necessary for the card service provided by the card company. For example, the data storage unit 200 stores a database that stores various information related to users in the card service. For example, the database stores credit card numbers, expiration dates, cardholder names, credit card usage history, payment methods such as lump-sum payment or installment payments, and other information. The data storage unit 200 only needs to store data according to the card service.

[Service Provision Department]
The service providing unit 201 provides card services to the user based on the data stored in the data storage unit 200. For example, when a credit card is specified as the charging method, the service providing unit 201 executes a charging process using the credit card's limit as the source of funds. The charging process may be a process that is commonly used as a charging process. When a credit card is used to pay an invoice, the service providing unit 201 executes a payment process using the credit card's limit as the source of funds.

[3-3. Functions realized by the receiving organization server]
For example, the receiving organization server 30 includes a data storage unit 300 and a storage unit 301. The data storage unit 300 is realized by the storage unit 32. The storage unit 301 is realized by the control unit 31.

[Data storage unit]
The data storage unit 300 stores data necessary for the collection service provided by the collection organization. For example, the data storage unit 300 stores a database that stores various information related to invoices. The database stores the invoice ID, the name of the payee, the payee's account information, the name of the collection organization, the payment amount, and the payment deadline. The information stored in the database may be information used in known collection services. For example, when a new invoice is issued, information related to the invoice is added to the database. The database may also store information indicating whether the invoice has been paid.

[Storage section]
The receiving unit 301 executes various processes in the payment service. For example, when the receiving unit 301 receives a deposit from a payment service provider, it determines whether or not the invoice, whose information is stored in the database stored in the data storage unit 300, has been paid, and updates the database. The processes executed by the receiving unit 301 may be processes employed in known payment services. For example, when the receiving unit 301 receives an invoice ID from the payment service provider server 10 or the user terminal 40, it may transmit information such as the payment amount associated with the invoice ID to the payment service provider server 10 or the user terminal 40.

[3-4. Functions implemented on user terminals]
For example, the user terminal 40 includes a data storage unit 400, an operation reception unit 401, and a display control unit 402. The data storage unit 400 is realized by the storage unit 42. The operation reception unit 401 and the display control unit 402 are realized by the control unit 41.

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

[Operation reception section]
The operation acceptance unit 401 accepts various operations from the user. For example, the operation acceptance unit 401 accepts operations for the payment application. The operation acceptance unit 401 transmits data indicating the content of the user's operation to the payment business operator server 10.

[Display control unit]
The display control unit 402 displays various screens on the display unit 45. For example, the display control unit 402 displays each of a shooting screen SC2, a reservation screen SC3, a notification screen SC4, and a list screen SC5 on the display unit 45. The display control unit 402 communicates with the payment service provider server 10 or another computer, receives data necessary to display these screens, and displays these screens on the display unit 45.

4. Processing performed by the bill payment system
Figure 6 is a diagram showing an example of the processing executed by the bill payment system 1. Figure 6 shows the processing for notifying a payment failure, which is one of the processing executed by the bill payment system 1. The processing of Figure 6 is executed by the control units 11 and 41 executing programs stored in the storage units 12 and 42, respectively.

As shown in Figure 6, the payment provider server 10 executes processing to accept a reservation for bill payment with the user terminal 40 (S1). In S1, the processing flow described with reference to Figure 2 is executed. The user terminal 40 transmits reservation content information regarding the reservation details entered by the user on the reservation screen SC3 to the payment provider server 10. The payment provider server 10 associates the reservation content information received from the user terminal 40 with the user's user ID and stores it as reservation history information in the payment service database DB.

The payment provider server 10 determines whether the payment timing specified by the user has arrived based on the payment service database DB. If it determines that the payment timing has arrived, it executes payment processing for the invoice scanned by the user between at least one of the card company server 20 and the collection organization server 30 (S2). In S2, the payment provider server 10 executes payment for the invoice based on the directly used payment method. The payment provider server 10 sends data to the collection organization server 30 indicating that payment of the invoice scanned by the user has been completed. This data includes the invoice ID of the invoice to be paid. By receiving this data from the payment provider server 10, the collection organization server 30 can determine that payment of the invoice has been completed. After that, after a certain period of time (e.g., two days) has passed, the payment provider deposits the money into the collection organization. If the payment fails, this series of processes is not executed.

In the process of S2, the payment business server 10 stores payment result information in the payment service database DB based on the execution result of the payment process. If the payment is successful, the payment business server 10 stores payment result information indicating the success of the payment in the payment service database DB. If the payment fails, the payment business server 10 stores payment result information indicating the payment failure and the cause of the payment failure in the payment service database DB. The method for generating payment result information is as described above. The payment business server 10 determines whether the payment failed based on the payment result information stored in the payment service database DB (S3). If it is determined in S3 that the payment was successful (S3: N), this process ends. In this case, a payment failure notification is not sent.

If it is determined in S3 that the payment has failed (S3: Y), the payment provider server 10 obtains information about the cause of failure based on the payment service database DB (S4). The payment provider server 10 notifies the user of the payment failure based on the information about the cause of failure (S5). When the user launches the payment app, selects icon I11, and selects a payment failure notification from the list of notifications, the user terminal 40 displays a notification screen SC4 on the display unit 45 (S6). When the user selects button B40, the user terminal 40 sends a request to the payment provider server 10 to access the list screen SC5 based on the link embedded in button B40 (S7).

When the payment provider server 10 receives an access request from the user terminal 40 (S8), it generates display data for the list screen SC5 based on the payment service database DB (S9). For example, assume that the link of button B40 includes the invoice ID of the payment that is the subject of the payment failure notification. The access request includes this invoice ID. In S9, the payment provider server 10 obtains reservation history information, including the invoice ID included in the access request, from the payment service database DB. The payment provider server 10 generates display data for the list screen SC5 based on this reservation history information. Note that individual reservations may be identified by information other than the invoice ID. For example, if a reservation ID, which is an ID for each individual reservation, is issued, the reservation whose reservation details are displayed on the list screen SC5 may be identified by the reservation ID.

The payment provider server 10 transmits display data for the list screen SC5 to the user terminal 40 (S10). The series of processes from S8 to S10 is an example of screen transition processing. The user terminal 40 receives display data for the list screen SC5 from the payment provider server 10 (S11) and displays the list screen SC5 on the display unit 45 (S12). The user terminal 40 executes processing with the payment provider server 10 to allow the user to change the reservation details (S13), and this processing ends. In S13, the user terminal 40 transmits data indicating the changes entered by the user to the payment provider server 10. The payment provider server 10 updates the reservation history information stored in the payment service database DB based on this data.

5. Summary of the embodiment
In this embodiment, the bill payment system 1 acquires failure cause information when a user's bill payment fails. Based on the failure cause information, the bill payment system 1 sends the user a payment failure notification regarding the cause of the payment failure. This allows the user to take appropriate action based on the payment failure notification after confirming the payment failure, thereby improving user convenience. For example, if the payment failure was due to insufficient electronic money balance, the user can charge electronic money and then schedule a second payment, or make the payment immediately. If the payment failure was due to insufficient points balance, the user can change the direct payment method to another payment method other than points, and then schedule a second payment, or make the payment immediately.

6. Modifications
The present disclosure is not limited to the above-described embodiments, and may be modified as appropriate without departing from the spirit of the present disclosure.

Figure 7 is a diagram showing an example of functions implemented in the modified example. For example, the payment provider server 10 includes a screen transition unit 105, a payment deadline information acquisition unit 106, a reservation history information acquisition unit 107, a prediction unit 108, a payment source information acquisition unit 109, and a future payment information acquisition unit 110. Each of the screen transition unit 105, payment deadline information acquisition unit 106, reservation history information acquisition unit 107, prediction unit 108, payment source information acquisition unit 109, and future payment information acquisition unit 110 is implemented by the control unit 11.

[6-1. Modification 1]
For example, the notification unit 104 may send a payment failure notification to the user, the content corresponding to the cause of the payment failure and including content capable of accepting a payment-related operation. The content is an element (part) included in the payment failure notification. For example, the content may be a button, an icon, an image other than a button or an icon, text, or another part. The payment-related operation may be any operation related to paying a bill. For example, the payment-related operation may be an operation for changing reservation details, an operation for rebooking, an operation for canceling a reservation, an operation for charging a directly used payment method, an operation for transitioning to a screen for a bill payment service, or another operation.

Content capable of accepting payment-related operations is content equivalent to a user interface part for accepting such operations. The parts included in the notification may be publicly known parts. Such parts may also include a link to the destination screen. In the example in the upper left of Figure 3, a notification including button B40 with an embedded link to list screen SC5 corresponds to a notification capable of accepting payment-related operations. The operation to transition to list screen SC5 to change reservation details for payment corresponds to a payment-related operation.

The data storage unit 100 of variant 1 stores content data indicating the relationship between the cause of failure information and the content included in the payment failure notification. The content data may be in any format, such as a table, a mathematical formula, part of a program, a machine learning model, or another format. The notification unit 104 identifies the content associated with the cause of failure information based on the content data, and sends the user a payment failure notification including the identified content. The actual data of the content is also assumed to be stored in the data storage unit 100. The actual data of the content may be included in template data indicating a template for the failure cause notification.

For example, the notification unit 104 may send the user a payment failure notification based on the content data, the payment failure notification including content corresponding to the cause indicated by the failure cause information. For example, if the failure cause information indicates a first cause, the notification unit 104 sends the user a payment failure notification including first content corresponding to the first cause. If the failure cause information indicates a second cause, the notification unit 104 sends the user a payment failure notification including second content corresponding to the second cause. The second cause is different from the first cause. The second content is different from the first content. The second content may be visually identical to the first content, but may have an internally embedded link that is different from the first content.

Figure 8 is a diagram showing an example of a payment failure notification for Variant 1. In Figure 8, the content included in the payment failure notification displayed on notification screen SC4 when the user selects icon I11 is shown for each cause of payment failure. The notification screen SC4 in the upper right of Figure 8 shows a payment failure notification for a payment that failed due to insufficient balance. The notification screen SC4 in the lower left of Figure 8 shows a payment failure notification for a payment that failed due to a system error by the payment service provider server 10 or the like. The notification screen SC4 in the lower right of Figure 8 shows a payment failure notification for a payment that failed due to the deadline having passed.

For example, suppose the content data includes failure cause information indicating insufficient balance and content for top-up. If the failure cause information indicates insufficient balance, the notification unit 104 sends the user a payment failure notification including a top-up button B41 as content corresponding to the insufficient balance, as shown in the upper right of Figure 8. When the user selects button B41, the payment service provider server 10 displays on the user terminal 40 a top-up screen for top-up of the directly used payment method used directly for payment. A link to the top-up screen is embedded in button B41. When the user performs a top-up operation from the top-up screen, the payment service provider server 10 performs a top-up of electronic money. Top-up of electronic money may be performed using known processing. It is assumed that the data necessary to display the top-up screen is stored in the data storage unit 100.

If the failure cause information indicates insufficient balance, the notification unit 104 may provide the user with a payment failure notification that includes content for charging without transitioning from the notification screen SC4, rather than a button B41 with an embedded link to the charge screen. For example, the notification unit 104 may provide the user with a payment failure notification that includes an input form for accepting input of conditions such as the charge amount, as content corresponding to the insufficient balance. The user terminal 40 sends a charge execution request to the payment service provider server 10 that includes the conditions entered in the input form for the payment failure notification. The payment service provider server 10 executes the charge process based on the charge execution request.

For example, suppose the content data includes failure cause information indicating a system error by the payment service provider server 10 or the like, and content for a rescheduling reservation. If the failure cause information indicates a system error, the notification unit 104 sends the user a payment failure notification including a button B42 for rescheduling as content corresponding to the system error, as shown in the lower left of Figure 8. Button B42 may be a button for the user to make a payment on the spot. When the user selects button B42, the payment service provider server 10 displays a reservation screen SC3 for the rescheduling reservation on the user terminal 40. A link to the reservation screen SC3 is embedded in button B42. When the user performs an operation to make a rescheduling reservation on the reservation screen SC3, the reservation acceptance unit 101 accepts the rescheduling. The processing executed when making a rescheduling reservation may be similar to the processing executed by the reservation acceptance unit 101 described in the embodiment. Since the details of the reservation that failed due to a system error may be changed rather than a new rescheduling, the notification unit 104 may send a payment failure notification including a button B42 for changing the details of the failed reservation. Furthermore, even if the payment failure is due to a system error, similar to charging, the reservation operation may be accepted again without changing screens. In this case, the notification screen SC4 may suggest an appropriate payment timing within the payment deadline.

For example, suppose the content data includes failure cause information indicating that the payment deadline specified by the user has passed, and content with an embedded link to a solution screen showing how to deal with the situation when the deadline has passed. A payment deadline is exceeded when the payment timing is later than the payment deadline. A payment deadline is exceeded even if the payment deadline has already passed at the time the user scans the invoice with the image capture unit 46. If the failure cause information indicates a deadline has passed, the notification unit 104 sends the user a payment failure notification, as shown in the lower right of Figure 8, which includes a button B43 with an embedded link to the solution screen as content corresponding to the deadline being exceeded. When the user selects button B43, the payment service provider server 10 displays a solution screen on the user terminal 40 showing how to deal with the situation when the deadline has passed. The user reviews the solution screen and considers future actions. It is assumed that the data necessary to display the solution screen is stored in the data storage unit 100. The solution screen may correspond to a help page.

Note that the content corresponding to the cause of payment failure is not limited to the example in Figure 8. The notification unit 104 may send the user a payment failure notification that includes content corresponding to the cause indicated by the failure cause information. For example, even if there is a system error, the notification unit 104 may send the user a payment failure notification that includes different content for each of an error in the payment service provider server 10, an error in the card company server 20, and an error in the collection organization server 30. If the failure cause information indicates a credit card error, the notification unit 104 may send a payment failure notification that includes a button with an embedded link to the card company's help page. In these cases, too, the relationship between the failure cause information and the content to be included in the payment failure notification is indicated in the content data.

The bill payment system 1 of variant 1 sends the user a payment failure notification that includes content corresponding to the cause of the payment failure and that can accept payment-related operations. This allows the user to check the content corresponding to the cause of the payment failure, thereby further improving user convenience. Because the user can perform payment-related operations from the payment failure notification, the bill payment system 1 reduces the operational burden on the user and improves user convenience. For example, after checking the notification screen SC4, the user does not have to perform complicated operations such as returning to the top screen SC1 to display a charge screen, but can simply select the content of the payment failure notification shown on the notification screen SC4, thereby reducing the operational burden on the user.

[6-2. Modification 2]
For example, as explained somewhat in the first modification, when an operation is performed on the content included in the payment failure notification, the user terminal 40 may transition to a payment-related screen related to the payment. The payment-related screen is a screen related to a payment reserved by the user. For example, the payment-related screen may be a screen showing the details of the payment reservation reserved by the user, a screen for charging a directly used payment means, a screen for changing the details of the payment reservation reserved by the user, a screen for canceling the payment reservation reserved by the user, or another screen.

The bill payment system 1 of Variation 2 includes a screen transition unit 105. When an operation on content is performed, the screen transition unit 105 transitions to a payment-related screen related to payment. An operation on content is when the user selects content. For example, an operation on content may be clicking, double-clicking, tapping, long-pressing, or other operations on the content. In the example of Figure 8, an operation on content would be when the user selects one of buttons B41 to B43. The screen transition process performed by the screen transition unit 105 is a process for displaying the aforementioned payment-related screen on the user terminal 40. The display data for the payment-related screen is assumed to be stored in the data storage unit 100. The display data may be any data required to display a screen on the user terminal 40. For example, the display data may be HTML data or image data.

In the example of Figure 8, when a user selects one of buttons B41 to B43, the user terminal 40 accesses the URL of the payment-related screen indicated by the link embedded in one of buttons B41 to B43. When the payment business operator server 10 accepts access from the user terminal 40, the screen transition unit 105 generates display data for the payment-related screen based on data from the payment service database DB, etc. The screen transition unit 105 transitions to the payment-related screen by sending the display data for the payment-related screen to the user terminal 40.

The bill payment system 1 of variant 2 transitions to a payment-related screen when an operation is performed on content. This allows the bill payment system 1 to reduce the operational burden on the user in transitioning to a payment-related screen, improving user convenience. For example, after checking notification screen SC4, the user does not have to perform the cumbersome operation of returning to the top screen SC1 to display the payment-related screen; instead, the user can simply select the payment failure notification content shown on notification screen SC4, thereby allowing the bill payment system 1 to reduce the operational burden on the user.

[6-3. Modification 3]
For example, if payment of a certain bill fails, the appropriate notification to the user may differ depending on whether there is sufficient time before the payment deadline or not. When there is sufficient time before the payment deadline, the user needs to be urged to make the payment immediately, whereas when there is not sufficient time before the payment deadline, the user may be urged not to make the payment immediately but to make a new reservation. Variation 3 takes as an example a case where a payment failure notification is sent according to the payment deadline.

The bill payment system 1 of variant 3 includes a payment deadline information acquisition unit 106. The payment deadline information acquisition unit 106 acquires payment deadline information related to the payment deadline. In variant 3, since payment deadline information is included in the reservation history information stored in the payment service database DB, the payment deadline information acquisition unit 106 acquires payment deadline information from the payment service database DB. The payment deadline information may be stored in a database other than the payment service database DB. In this case, the payment deadline information acquisition unit 106 acquires the payment deadline information from the other database. The payment deadline information may be stored on a computer other than the payment service server 10 (for example, the collection organization server 30) or on an external information storage medium. In this case, the payment deadline information acquisition unit 106 acquires the payment deadline information from the other computer or external information storage medium.

Figure 9 shows an example of a payment failure notification in Variation 3. The notification unit 104 in Variation 3 sends a payment failure notification to the user based on the payment deadline information as well, including content that corresponds to the payment deadline and that is capable of accepting payment-related operations. The meaning of the content may be the same as in Variation 1. The data storage unit 100 in Variation 3 stores content data that indicates the relationship between the conditions related to the payment deadline information and the content included in the payment failure notification. The notification unit 104 identifies the conditions satisfied by the payment deadline information based on the content data. The notification unit 104 identifies the content associated with the identified conditions and sends the user a payment failure notification that includes the identified content.

For example, suppose the content data indicates that the time until payment is less than a threshold and includes content encouraging the user to make payment immediately. As shown in the upper right of FIG. 9 , when the notification unit 104 determines that the time until payment is less than the threshold based on the payment deadline information, it sends the user a payment failure notification including a button B44 encouraging the user to make payment immediately, as content associated with the condition indicating that the time until payment is less than the threshold. Button B44 has an embedded link to a reservation screen SC3 including a button B30 for making immediate payment. This reservation screen SC3 does not need to include a button B31 for making a payment reservation. When the user selects button B44, the payment service provider server 10 displays a reservation screen SC3 on the user terminal 40 for the user to make payment immediately, rather than reserving payment. This reservation screen SC3 may be a known screen. The payment service provider server 10 executes payment processing based on information such as the direct payment method specified by the user on the reservation screen SC3.

For example, suppose the content data indicates that the time until payment is due is greater than or equal to a threshold value and includes content encouraging the user to make a new reservation. As shown in the lower right of Figure 9, when the notification unit 104 determines that the time until payment is due is greater than or equal to the threshold value based on the payment deadline information, it sends the user a payment failure notification including a button B45 encouraging the user to make a new reservation, as content associated with the condition indicating that the time until payment is due is greater than or equal to the threshold value. Button B45 has an embedded link to a reservation screen SC3 including a button B31 for making a new reservation. This reservation screen SC3 does not need to include button B30 for making an immediate payment. When the user selects button B45, the payment service provider server 10 displays on the user terminal 40 a reservation screen SC3 allowing the user to make a new reservation. Since the details of the failed reservation may be changed rather than a new reservation being made, the notification unit 104 may send a payment failure notification including a button B45 for changing the details of the failed reservation.

The bill payment system 1 of variant 3 sends the user a payment failure notification based on the payment deadline information, which notification includes content corresponding to the payment deadline and content that can accept payment-related operations. This allows the user to check the content corresponding to the payment deadline, further improving user convenience. For example, if there is not enough time until the payment deadline, the bill payment system 1 can urge the user to make the payment immediately. If there is enough time until the payment deadline, the bill payment system 1 can urge the user to make a new reservation without rushing.

[6-4. Modification 4]
For example, in Variation 3, an example is given of a case where a payment failure notification including content corresponding to the payment deadline is sent. Variation 4 is given of an example where the notification unit 104 sends a payment failure notification to the user in a manner corresponding to the payment deadline, further based on the payment deadline information. The manner refers to how the notification unit 104 sends the payment failure notification. Variation 4 is given of an example where the notification means corresponds to the manner. The manner is not limited to the notification means. For example, the manner may be the color, size, frequency of notification, timing of notification, or other elements of the payment failure notification. It is assumed that the data necessary for each manner of payment failure notification is stored in the data storage unit 100. The notification unit 104 can send a payment failure notification in any manner based on the data.

The bill payment system 1 of variant 4 includes a payment deadline information acquisition unit 106 similar to variant 3. The data storage unit 100 of variant 4 stores mode data indicating the relationship between conditions related to payment deadline information and the mode of payment failure notification. The notification unit 104 identifies the conditions satisfied by the payment deadline information based on the mode data. The notification unit 104 notifies the user of the payment failure in the mode associated with the identified conditions.

For example, the notification unit 104 may provide the user with a payment failure notification in a manner that corresponds to the cause indicated by the failure cause information, based on the manner data. For example, if the failure cause information indicates a first cause, the notification unit 104 provides the user with a payment failure notification in the first manner. If the failure cause information indicates a second cause, the notification unit 104 provides the user with a payment failure notification in the second manner. The second cause is different from the first cause. The second manner is different from the first manner.

Figure 10 is a diagram showing an example of a payment failure notification in Variation 4. For example, assume that the content data indicates that the time until the payment deadline is less than a threshold and that a payment failure notification should be sent via a pop-up P on the payment app. As shown in the upper right of Figure 10, when the notification unit 104 determines that the time until the payment deadline is less than the threshold based on the payment deadline information, it sends the user a payment failure notification via a pop-up P associated with the condition indicating that the time until the payment deadline is less than the threshold. The notification unit 104 may display the payment failure notification pop-up P on the top screen SC1 instead of the notification screen SC4 that is displayed after icon I11 is selected.

For example, suppose the content data indicates that the time remaining until the payment deadline is greater than or equal to a threshold and that a payment failure notification should be sent by email. As shown in the lower right of Figure 10, when the notification unit 104 determines that the time remaining until the payment deadline is greater than or equal to the threshold based on the payment deadline information, it notifies the user of the payment failure by sending an email associated with the condition indicating that the time remaining until the payment deadline is greater than or equal to the threshold to the user's email address. When the user operates the user terminal 40 to launch an email application or logs into an email service from a browser, the user terminal 40 displays an email screen SC6 on the display unit 45, which displays an email notification of the payment failure. When the user selects the email payment failure notification button B60, the user terminal 40 launches the payment app and displays the screen linked to by button B60.

The bill payment system 1 of variant 4 further provides the user with a payment failure notification in a format appropriate to the payment deadline, based on the payment deadline information. This allows the user to check the payment failure notification in a format appropriate to the payment deadline, further enhancing user convenience. For example, if there is not much time left until the payment deadline, the bill payment system 1 notifies the user of the payment failure via a pop-up P that is easy for the user to notice, making it easier for the user to realize that they need to take action regarding the payment failure. However, some users may find the display of the pop-up P cumbersome, so if there is still time left until the payment deadline, the bill payment system 1 can notify the user of the payment failure via email, which is less likely to be cumbersome for the user.

[6-5. Modification 5]
For example, when a user's multiple payments fail, the failure cause information acquisition unit 103 may acquire failure cause information for each of the multiple payments. When a user makes multiple payments at a certain payment timing, the failure cause information acquisition unit 103 determines whether each of the multiple payments has failed. The method for determining each individual payment may be the same as in the embodiment. When it is determined that multiple payments have failed, the failure cause information acquisition unit 103 acquires failure cause information for each of the multiple payments. The method for acquiring each individual failure cause information may be the same as in the embodiment.

Figure 11 is a diagram showing an example of a payment failure notification in Variation 5. The notification unit 104 in Variation 5 sends a single payment failure notification to the user, consolidating notifications regarding the causes of each of the multiple payments based on the failure cause information for each of the multiple payments. In the example of Figure 11, two payments fail at a certain payment timing. In this case, rather than sending two payment failure notifications, the notification unit 104 sends a single payment failure notification indicating that both payments failed. For example, the notification unit 104 obtains at least one of the reservation history information and payment result information for the two failed payments from the payment service database DB, and generates a single payment failure notification by inserting details of each of the two payments into the template indicated by the template data. The notification unit 104 sends the single payment failure notification to the user.

The notification unit 104 may issue a single notification whether the causes indicated in the failure cause information for each of the multiple payments are different or the same. If the causes indicated in the failure cause information for each of the multiple payments are the same, the notification unit 104 may issue a single notification. If the causes indicated in the failure cause information for each of the multiple payments are different, the notification unit 104 may issue a notification for each individual cause. For example, if the causes indicated in the failure cause information for each of the multiple payments are different and multiple payments failed due to a single cause, the notification unit 104 may combine the notifications for the multiple payments into a single notification. For example, suppose three payments were made on the same day. Of the three payments, two failed due to insufficient balance and one failed due to a system error. In this case, the notification unit 104 may issue a first notification indicating that two payments failed due to insufficient balance and a second notification indicating that one payment failed due to a system error. For example, the first notification may include content for charging depending on the cause of the insufficient balance. The second notification may include content for rebooking depending on the cause of the system error. In this way, by grouping notifications by cause, users can perform actions based on the cause (for example, charging all at once).

In variant 5, when a user's multiple payments fail, the bill payment system 1 obtains information on the cause of failure for each of the multiple payments. Based on the information on the cause of failure for each of the multiple payments, the bill payment system 1 sends the user a single payment failure notification that consolidates information on the causes of each of the multiple payment failures. This eliminates the need for the user to receive multiple payment failure notifications, thereby improving user convenience. For example, if a user receives multiple payment failure notifications, one payment failure notification may be buried under other payment failure notifications. However, because the user can view multiple failed payments together through a single payment failure notification, they are less likely to overlook a failed payment.

[6-6. Modification 6]
For example, if multiple payments are scheduled for a certain payment timing, the payment execution unit 102 executes each of the multiple payments at that payment timing. In this case, depending on the directly used payment means, some of the payments may fail. For example, if the directly used payment means is electronic money, some of the payments may fail due to insufficient balance. The payment execution unit 102 executes as many of the multiple payments as possible based on the balance of the electronic money. The payments to be executed may be prioritized. When a certain payment timing arrives, the payment execution unit 102 executes each of the multiple payments one after another based on the priority associated with each of the multiple payments. For example, the payment execution unit 102 may execute payments in descending order of payment amount, or in order of the nearest payment deadline. If the directly used payment means is electronic money, if the balance runs out midway, subsequent payments will fail.

In variant 6, when one of multiple payments fails at a specific payment timing, the failure cause information acquisition unit 103 acquires failure cause information for that part of the payment. When multiple payments are made by a user at a certain payment timing, the failure cause information acquisition unit 103 determines whether each of the multiple payments has failed. The method for determining each individual payment may be the same as in the embodiment. When it is determined that one of the multiple payments has failed, the failure cause information acquisition unit 103 acquires failure cause information for that part of the payment. There may be only one part of the payment that has failed, or there may be multiple parts of the payment that have failed. The method for acquiring failure cause information may be the same as in the embodiment.

In Variation 6, the notification unit 104 notifies the user of a payment failure based on the failure cause information for the failed partial payment. For example, if only one partial payment has failed, the notification unit 104 notifies the user of the payment failure for that single payment, as in the embodiment. If multiple partial payments have failed, the notification unit 104 may notify the user of a payment failure that consolidates notifications regarding the causes of failure for each of the multiple payments, as in Variation 5. In Variation 6, the notification unit 104 may notify the user of the payment failure for each of the multiple payments separately. The method of notifying each individual payment failure notification may be the same as in the embodiment or any of Variations 1 to 4.

In variant 6, when one of multiple payments fails at a specified payment timing, the bill payment system 1 obtains information about the cause of the failure of that payment. The bill payment system 1 notifies the user of the payment failure based on the information about the cause of the failure of that payment. This allows the user to know the cause of the failure of a payment, even if the payment fails at a timing when multiple payments are made, thereby further improving user convenience.

[6-7. Modification 7]
For example, in the embodiment, a case where a user makes a reservation for payment has been described. The failure cause information acquisition unit 103 acquires failure cause information when the payment reserved by the user fails. The notification unit 104 notifies the user of the payment failure when the payment reserved by the user fails. These processes are as described in the embodiment.

For example, the bill payment system 1 may be able to predict future payments a user will make. Suppose a user regularly pays utility bills, taxes, or the like. In this case, the bill payment system 1 may be able to predict the user's future tendencies based on the user's past reservation history. For example, a user may make a reservation well before the due date of a regular payment, or may make a reservation just before the due date. If the bill payment system 1 can predict such user tendencies, it can predict whether the user will forget to make a reservation for a regular payment. In other words, if the user has not yet made a reservation even when the time has come for the user to make a reservation, the bill payment system 1 can predict that the user has forgotten to make a reservation. This is not limited to regular payments. Even if the payment is not regular, if the user has made similar payments in the past, the bill payment system 1 can predict future payments from that history. The bill payment system 1 may use this prediction to notify the user about future payments.

The bill payment system 1 of variant 7 includes a reservation history information acquisition unit 107 and a prediction unit 108. The reservation history information acquisition unit 107 acquires reservation history information relating to the history of payments made by the user. In variant 7, the reservation history information indicates the acceptance timing of the reservation. The acceptance timing is the timing at which the reservation was accepted. The acceptance timing may be expressed not only as a date but also as a time and date including the time. The user can make a reservation at any acceptance timing. However, if a payment deadline is set on the invoice, the user will, as a general rule, make a reservation at an acceptance timing up to the payment deadline.

For example, the reservation history information acquisition unit 107 acquires reservation history information from the payment service database DB. Note that the reservation history information may be stored in a database other than the payment service database DB. In this case, the reservation history information acquisition unit 107 acquires the reservation history information from the other database. The reservation history information may be stored in a computer or external information storage medium other than the payment service provider server 10. In this case, the reservation history information acquisition unit 107 acquires the reservation history information from the other computer or external information storage medium.

The prediction unit 108 predicts the timing of future payments made by the user based on reservation history information. For example, the prediction unit 108 calculates the average time interval between the payment timings of multiple payments made by the user in the past based on the reservation history information. The prediction unit 108 predicts the timing of future payments made by the user to be a timing that is the calculated average value after the payment timing of the most recent payment. This payment may be a payment made periodically by the user. In this case, the prediction unit 108 may determine whether the payment is periodic based on at least one of whether there has been a predetermined number of past reservation histories and whether the payment is a periodic payment based on the bill attributes, such as utility bills or taxes. The prediction unit 108 may predict the timing of future payments made by the user based on the user's payment timing patterns for periodic payments. For example, if a user's reservation history information includes a history of an electronic payment made on December 30, 2023, and similar history exists every month, the prediction unit 108 predicts the next payment timing to be one month later, on January 30, 2024. In this case, a notification such as "Would you like to make a reservation for electricity payment?" may be sent some time before January 30, 2024 (for example, one week before) through processing by the notification unit 104, which will be described later.

Note that the method for predicting payment timing is not limited to the above example. For example, the prediction unit 108 may predict future payment timing based on a value obtained by substituting the time interval between payment timings for multiple past reservations into another calculation formula, rather than the average value of the time interval between payment timings for each reservation. In another example, the prediction unit 108 may predict payment timing based on a model that predicts payment timing based on reservation history information, and that is prepared using machine learning techniques. The payment timing predicted by the prediction unit 108 is stored in the payment service database DB or another database. The notification unit 104 obtains the predicted payment timing for each user from the payment service database DB or another database.

Figure 12 is a diagram showing an example of a notification in Variation 7. The notification unit 104 in Variation 7 provides a notification before the payment timing predicted by the prediction unit 108 arrives. In the example of Figure 12, the notification unit 104 provides a notification to the user using the notification function of the payment app. For example, the notification unit 104 obtains the current date and time using a real-time clock or GPS and determines whether the predicted reservation time for each user has arrived. For example, when the notification unit 104 determines that the reservation time for a regular payment predicted by the prediction unit 108 has arrived, it determines whether a reservation for a regular payment has been made based on the reservation history information stored in the payment service database DB. The notification unit 104 may also determine whether the payee is eligible for regular payment based on the payee indicated in the reservation history information. When it is determined that a reservation for a regular payment has not been made, the notification unit 104 provides a notification to the user.

For example, it is assumed that the data storage unit 100 stores template data for notifications. The template for notifications may be generally similar to the template for notifications, but differs in that it includes content for notifications. For example, the template for notifications indicates a string of characters indicating the content of the notification. The notification unit 104 inserts information about the recurring payment that is the subject of the notification into the template indicated by the template data, based on reservation history information for past recurring payments stored in the payment service database DB. In the example of Figure 12, the notification unit 104 inserts information such as the payee and payment amount of the past recurring payment into the template.

For example, the notification unit 104 generates a link to the shooting screen SC2 and inserts a button B46 including the link into the template. Data related to the link of the shooting screen SC2 is assumed to be stored in advance in the data storage unit 100. The notification unit 104 can identify the link to be embedded in the button B46 based on the data. The notification unit 104 may insert information such as arguments specific to the user into the link indicated by the data, and then generate the link to be embedded in the button B46. The notification unit 104 displays a notification screen SC4 indicating the notification generated as described above to the user.

Note that the method by which the notification unit 104 notifies is not limited to the above example. The notification unit 104 may notify the user in a manner appropriate to the notification means. For example, if email is used for notification, the notification unit 104 may send an email as a notification to the user's email address indicated in the notification destination information. The notification unit 104 may generate the email in the same manner as notifications sent on the payment app. For example, the notification unit 104 may send an email message to the user's email address that includes the reservation details of the reservation that is the subject of the notification and a link to the photo capture screen SC2.

For example, if SMS is used for notification, the notification unit 104 can send an SMS message as a notification to the user's telephone number indicated in the notification destination information. The notification unit 104 can generate the SMS message in the same way as an email. For example, the notification unit 104 can send an SMS message to the user's telephone number that includes the reservation details of the reservation that is the subject of the notification and a link to the shooting screen SC2.

For example, if a message app is used for notification, the notification unit 104 may send a message of the message app as a notification to the user's account indicated by the notification destination information. The notification unit 104 may generate a message of the message app in the same manner as an email. For example, the notification unit 104 may send a message of the message app to the user's account that includes the reservation details of the reservation that is the subject of the notification and a link to the shooting screen SC2. Similarly, if another notification means is used, the notification unit 104 may notify the user in a manner appropriate to the other notification means.

The bill payment system 1 of variant 7 acquires reservation history information. Based on the reservation history information, the bill payment system 1 predicts the timing of future payments made by the user. The bill payment system 1 notifies the user before the predicted payment timing arrives. This prevents the user from forgetting to make a reservation for a future payment, thereby improving user convenience.

[6-8. Modification 8]
For example, the appropriate payment failure notification may differ depending on the payment source used for the payment scheduled by the user. If it is necessary to convey to the user content specific to a certain payment source, the bill payment system 1 may issue a payment failure notification including that specific content. If it is necessary to issue a payment failure notification at a timing specific to a certain payment source, the bill payment system 1 may issue the payment failure notification at that timing. Therefore, Variation 8 provides an example of a case where a payment failure notification is issued depending on the payment source.

The bill payment system 1 of variant 8 includes a payment source information acquisition unit 109. The payment source information acquisition unit 109 acquires payment source information related to payment sources used directly or indirectly in payment. For example, the payment source information acquisition unit 109 acquires payment source information from the payment service database DB. For example, if the payment method used directly in payment corresponds to the payment source, the reservation history information indicates information on the directly used payment method (i.e., payment source information), and therefore the payment source information acquisition unit 109 acquires the payment source information by acquiring the reservation history information stored in the payment service database DB.

For example, if the charging method indirectly used for payment corresponds to the payment source, the reservation history information indicates information about the charging method (i.e., payment source information), so the payment source information acquisition unit 109 acquires the payment source information by acquiring the reservation history information stored in the payment service database DB. If the reservation history information does not indicate information about the charging method, the payment source information acquisition unit 109 may acquire the payment source information by acquiring charging method information stored in the payment service database DB.

The payment source information may be stored in a database other than the payment service database DB. The payment source information acquisition unit 109 may acquire the payment source information from another database. The payment source information may be stored in a computer other than the payment service provider server 10, or in an external information storage medium. The payment source information acquisition unit 109 may acquire the payment source information from another database or external information storage medium. The payment source information acquisition unit 109 may acquire all payment source information, or may acquire only part of the payment source information. The payment source information acquisition unit 109 may acquire the payment source information for the payment for which the notification timing is to be determined.

The notification unit 104 further notifies the user of a payment failure based on the payment source information and the deposit period for the payment source. The deposit period is the period required for deposit. The deposit period is not the period from when the user issues a charge instruction until the charge is completed, but the period from when the charge is completed until the deposit from the administrator of the charge method that serves as the source of funds for the charge is received. The deposit period occurs when the administrator of the charge method (the card company in Variation 8) deposits funds to the administrator of the directly used payment method (the payment service provider in Variation 8) that is directly used for payment. Any deposit method, such as bank transfer, may be used for the deposit. Data indicating the length of the deposit period is stored in the data storage unit 100.

The administrator of a charging method is the business that manages the charging method. For example, if the charging method is a credit card, the card company that issued the credit card corresponds to the administrator of the charging method. If the charging method is an account such as a bank account, the financial institution that manages the account corresponds to the administrator of the charging method. The administrator of a directly used payment method is the business that manages the directly used payment method. For example, if the directly used payment method is electronic money, the business that manages the electronic money corresponds to the administrator of the directly used payment method. If the directly used payment method is an account such as a bank account, the financial institution that manages the account corresponds to the administrator of the directly used payment method.

The data storage unit 100 of variant 8 stores deposit period relationship data indicating the relationship between payment source information and notification methods corresponding to deposit periods. The deposit period relationship data may be in any format, such as a table, a mathematical formula, part of a program, a machine learning model, or another format. The notification unit 104 identifies the notification method associated with the payment source information based on the deposit period relationship data, and notifies the user of the payment failure using the identified notification method. The notification method may be the content included in the payment failure notification, the notification timing, the notification means, or any other method.

For example, the notification unit 104 may issue a payment failure notification that suggests at least one of the payment timing and charge timing according to the payment period for the next reservation. Here, it is assumed that the payment source is a charge method. Furthermore, it is assumed that the payment period (e.g., two days) when the payment source is a bank account is shorter than the payment period (e.g., one week) when the payment source is a credit card. When the payment source is a bank account with a relatively short payment period, the notification unit 104 issues a payment failure notification that suggests a charge timing according to the payment period. In this case, the charge timing may be a deadline that is at least the payment period (e.g., two days) before the payment deadline.

For example, if the payment source is a credit card with a relatively long deposit period, the notification unit 104 issues a payment failure notification proposing a charge timing that corresponds to that deposit period. In this case, the charge timing may be a deadline that precedes the payment deadline by the deposit period (for example, one week). Similarly, when the notification unit 104 proposes a payment timing, the notification unit 104 may issue a payment failure notification that proposes a payment timing that corresponds to the deposit period of the payment source indicated by the payment source information. The notification unit 104 may also issue a payment failure notification that proposes both a payment timing and a charge timing that correspond to the deposit period of the payment source indicated by the payment source information.

The bill payment system 1 of variant 8 further provides the user with a payment failure notification based on the payment source information and the payment period associated with the payment source. This allows the bill payment system 1 to provide an appropriate payment failure notification tailored to the payment source. For example, by providing a payment failure notification that suggests a charge timing based on the payment period from the card company to the payment service provider, the bill payment system 1 can encourage the user to charge at an earlier stage, making it easier to avoid a situation where the payment from the card company to the payment service provider is delayed until the payment is made to the collection organization. As a result, the bill payment system 1 can prevent payment service providers from running out of funds and increase convenience for payment service providers.

[6-9. Modification 9]
For example, if a payment fails, future payments scheduled after it may also fail. A future payment is a payment that occurs in the future. If the directly used payment method is electronic money, if a payment fails due to insufficient balance, other payments scheduled after it may also fail due to insufficient balance. Therefore, a payment failure notification may be sent taking into account whether or not there are any future payments.

The bill payment system 1 of variant 9 includes a future payment information acquisition unit 110. When a payment fails, the future payment information acquisition unit 110 acquires future payment information related to a future payment reserved by the user. In variant 9, the future payment information is included in the reservation history information stored in the payment service database DB. Reservation history information in which at least one of the payment timing or payment deadline is in the future corresponds to future payment information. The future payment information acquisition unit 110 acquires the future payment information from the payment service database DB. The future payment information may be stored in a database other than the payment service database DB. In this case, the future payment information acquisition unit 110 acquires the future payment information from the other database. The future payment information may be stored on a computer other than the payment service server 10 (e.g., the collection organization server 30) or on an external information storage medium. In this case, the future payment information acquisition unit 110 acquires the future payment information from the other computer or external information storage medium. Note that the future payment information acquisition unit 110 may acquire future payment information for a future payment for which the same payment source as the payment source of the failed payment is specified.

In variant 9, the notification unit 104 notifies the user of a payment failure based further on the future payment information. For example, if a payment fails, the notification unit 104 notifies the user of a payment failure that includes not only the failed payment but also information about future payments indicated by the future payment information. In an example similar to the embodiment, the notification screen SC4 in the upper left of Figure 3 will include not only the payment that failed due to insufficient balance, but also information about future payments scheduled thereafter. The notification unit 104 generates a payment failure notification by embedding the content indicated by the future payment information (e.g., payment amount, payment deadline, payment timing, and charge timing) into the template indicated by the template data. The notification unit 104 then notifies the user of the generated payment failure notification.

The bill payment system 1 of variant 9 notifies the user of a payment failure based further on future payment information. This allows the user to become aware in advance of payments that may fail in the future, thereby further enhancing user convenience. For example, if a payment fails, the user will be aware of the future payment due to the payment failure notification, and will be able to make an overcharge with future payments in mind.

[6-10. Other Modifications]
For example, the above modifications may be combined.

For example, the embodiment provides an example of a payment failure notification when a payment scheduled by the user fails. If a payment made by the user on the spot by selecting button B30 on the reservation screen SC3 fails, rather than a payment scheduled by the user, the notification unit 104 may provide the user with a payment failure notification indicating the cause of the payment failure. In this case, the payment failure notification differs in that it is a notification for a payment made by the user on the spot, rather than a payment scheduled by the user, but the processing for the payment failure notification may be the same as in the embodiment. The bill payment system 1 does not need to include a function that allows the user to schedule a payment. In this case, the bill payment system 1 does not need to include the reservation acceptance unit 101. The bill payment system 1 may include a function for providing a payment failure notification when a payment made on the spot by the user fails, but may not include a function for providing a payment failure notification when a payment scheduled by the user fails.

For example, the functions described as being implemented by the payment service provider server 10 may be implemented by the card company server 20, the collection organization server 30, the user terminal 40, or another computer. The processing described as being implemented by the payment service provider server 10 may be shared among multiple computers.

[7. Notes]
For example, a bill payment system can be configured as follows:
(1)
a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails;
a notification unit that notifies the user of a payment failure regarding the cause of the payment failure based on the failure cause information;
Bill payment system including.
(2)
the notification unit issues the payment failure notification to the user, the payment failure notification including content corresponding to the cause of the payment failure and accepting an operation related to the payment.
(1) A bill payment system as described in (1).
(3)
The bill payment system further includes a screen transition unit that transitions to a payment-related screen regarding the payment when the operation is performed.
(2) A bill payment system according to (2).
(4)
The bill payment system further includes a payment deadline information acquisition unit that acquires payment deadline information regarding a payment deadline for the payment,
the notification unit issues a payment failure notification to the user based on the payment deadline information, the payment failure notification including the content corresponding to the payment deadline and accepting an operation related to the payment.
A bill payment system according to any one of (1) to (3).
(5)
The bill payment system further includes a payment deadline information acquisition unit that acquires payment deadline information regarding a payment deadline for the payment,
the notification unit issues the payment failure notification to the user in a manner corresponding to the payment deadline, further based on the payment deadline information.
A bill payment system according to any one of (1) to (4).
(6)
the failure cause information acquisition unit acquires the failure cause information for each of the plurality of payments when the plurality of payments by the user fail;
the notification unit issues to the user the payment failure notification, which is a single notification regarding the cause of the failure of each of the plurality of payments, based on the failure cause information for each of the plurality of payments.
A bill payment system according to any one of (1) to (5).
(7)
the failure cause information acquisition unit acquires the failure cause information of a part of the payment when the part of the plurality of payments fails at a predetermined payment timing;
the notification unit notifies the user of the payment failure based on the failure cause information of the partial payment.
A bill payment system according to any one of (1) to (6).
(8)
the failure cause information acquisition unit acquires the failure cause information when the payment for the reservation made by the user fails,
the notification unit notifies the user of the payment failure when the payment for the reservation made by the user fails,
The bill payment system comprises:
a reservation history information acquisition unit that acquires reservation history information relating to the history of the payment for the reservation made by the user;
a prediction unit that predicts a payment timing regarding the payment to be made by the user in the future based on the reservation history information;
Further comprising:
The notification unit issues the notification before the payment timing predicted by the prediction unit arrives.
A bill payment system according to any one of (1) to (7).
(9)
The bill payment system further includes a payment source information acquisition unit that acquires payment source information regarding a payment source that is directly or indirectly used in the payment,
The notification unit sends the user the payment failure notification according to the payment period related to the payment source further based on the payment source information.
A bill payment system according to any one of (1) to (8).
(10)
The bill payment system further includes a future payment information acquisition unit that acquires future payment information regarding a future payment scheduled by the user when the payment fails;
the notification unit notifies the user of the payment failure further based on the future payment information.
A bill payment system according to any one of (1) to (9).

1 Bill payment system, 10 Payment service provider server, 11, 21, 31, 41 Control unit, 12, 22, 32, 42 Memory unit, 13, 23, 33, 43 Communication unit, 20 Card company server, 30 Receiving organization server, 40 User terminal, 44 Operation unit, 45 Display unit, 46 Photography unit, N Network, DB Payment service database, P Pop-up, 100, 200, 300, 400 Data storage unit, 101 Reservation reception unit, 102 Payment execution unit, 103 Failure cause information acquisition unit, 104 Notification unit, 105 Screen transition unit, 106 Payment deadline information acquisition unit, 107 Reservation history information acquisition unit, 108 Reservation time prediction unit, 109 Payment source information acquisition unit, 110 Future payment information acquisition unit, 201 Service provision unit, 301 Receiving unit, 401 Operation reception unit, 402 Display control unit, B10, B30, B31, B40, B41, B42, B43, B44, B45, B46, B50, B60 buttons, I11 icon, SC1 top screen, SC2 shooting screen, SC3 reservation screen, SC4 notification screen, SC5 list screen, SC6 email screen.

Claims (10)

a failure cause information acquisition unit that acquires failure cause information regarding the cause of the payment failure from among a plurality of causes of the payment failure when the user's bill payment fails;
a notification unit that issues a payment failure notification to the user based on content data indicating a relationship between the failure cause information and content included in a payment failure notification related to the cause, the payment failure notification including the content that allows the user to perform an operation to deal with the cause indicated by the failure cause information among the plurality of causes;
Bill payment system including. The bill payment system further includes a screen transition unit that, when the operation is performed, transitions to a payment-related screen related to the payment, the payment-related screen corresponding to the cause of the payment failure.
10. The bill payment system of claim 1. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails;
a payment deadline information acquisition unit that acquires payment deadline information regarding the payment deadline;
a notification unit that identifies a condition satisfied by the payment deadline information based on content data indicating a relationship between a condition related to the payment deadline information and a content included in a payment failure notification related to the cause indicated by the failure cause information, the content accepting an operation related to the payment, identifies content associated with the identified condition, and sends the payment failure notification including the identified content to the user;
Bill payment system including. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails;
a payment deadline information acquisition unit that acquires payment deadline information regarding the payment deadline;
a notification unit that identifies conditions satisfied by the payment deadline information based on mode data indicating the relationship between conditions related to the payment deadline information and a mode that is one of a plurality of notification means, and notifies the user of a payment failure related to the cause indicated by the failure cause information in a mode associated with the identified conditions;
Bill payment system including. a failure cause information acquisition unit that acquires failure cause information regarding the cause of each of a plurality of payments failures of a user when the user fails to pay the plurality of bills;
a notification unit that, when it is determined based on the failure cause information for each of the plurality of payments that the cause of failure for each of the plurality of payments is the same, issues to the user a single payment failure notification relating to the cause, and when it is determined that the causes of failure for each of the plurality of payments are different, issues to the user a payment failure notification for each individual cause;
Bill payment system including. the failure cause information acquisition unit acquires the failure cause information of a part of the payment when the part of the plurality of payments fails at a predetermined payment timing;
the notification unit notifies the user of the payment failure based on the failure cause information of the partial payment.
A bill payment system according to any one of claims 1 to 5. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a payment failure when a payment of an invoice reserved by a user fails;
a notification unit that, when the payment for the reservation made by the user fails, issues a payment failure notification to the user regarding the cause of the payment failure based on the failure cause information;
a reservation history information acquisition unit that acquires reservation history information relating to the history of the payment for the reservation made by the user;
a prediction unit that predicts a payment timing regarding the payment to be made by the user in the future based on the reservation history information;
Including,
the notification unit determines whether or not a reservation for the payment has been made before the payment timing predicted by the prediction unit arrives, and if it is determined that the reservation has not been made, issues a reservation notification to urge the user to make the reservation.
Bill payment system. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails;
a future payment information acquisition unit that acquires future payment information regarding future payments reserved by the user when the payment fails;
a notification unit that generates the payment failure notification by embedding information regarding the future payment indicated by the future payment information into the template based on template data indicating a template of a payment failure notification related to the cause indicated by the failure cause information, and sends the generated payment failure notification to the user;
Bill payment system including. The computer
a failure cause information acquisition step of acquiring failure cause information regarding the cause of the payment failure among a plurality of causes of the payment failure when the user's payment of the bill fails;
a notification step of sending a payment failure notification to the user based on content data indicating a relationship between the failure cause information and content included in a payment failure notification related to the cause, the payment failure notification including the content allowing the user to perform an operation to deal with the cause indicated by the failure cause information among the plurality of causes;
Bill payment methods to perform. a failure cause information acquisition unit that acquires failure cause information regarding the cause of the payment failure among a plurality of causes of the payment failure when the user's bill payment fails;
a notification unit that issues a payment failure notification to the user based on content data indicating a relationship between the failure cause information and content included in a payment failure notification related to the cause, the payment failure notification including the content allowing the user to perform an operation to deal with the cause indicated by the failure cause information among the plurality of causes;
A program that allows a computer to function as a