JP7621409B2 - Payment management system, payment management method, and payment management program - Google Patents

Description

This invention relates to a payment management system, a payment management method, and a payment management program for payment of goods or services by bank transfer.

As an example of a system for managing the settlement status (payment status) of the price of goods or services by bank transfer, a payment confirmation notification system has been proposed that can manage excess or shortfall amounts by acquiring the purchase price of the goods and the transfer amount related to the purchase price of the goods, and updating the purchase price by reducing it by the transfer amount actually deposited (see Patent Document 1).

The payment confirmation notification system described in Patent Document 1 detects the amount of excess or deficiency, and if the amount transferred by the purchaser is less than the purchase price, notifies the purchaser that the amount is insufficient, and allows the purchaser to continue waiting for the shortfall to be deposited in the designated account.

However, in the payment confirmation notification system described in Patent Document 1, when an amount is insufficient, from the consumer's perspective, a notification is simply sent to that effect, and from the business's perspective, the business simply waits for the shortfall to be paid, so there is room for improvement in terms of convenience from the perspectives of both the business and the consumer.

JP 2013-114389 A

In view of the above problems, this invention aims to provide a payment management system, a payment management method, and a payment management program that can improve the convenience of both businesses and consumers when paying for products or services by bank transfer.

This invention comprises a business terminal used by a business providing a product or service, a user terminal used by a user receiving the provision of the product or service, a sending bank server managed by a sending bank having a sending account which is the transfer source of the payment in a transaction related to the provision of the product or service, a receiving bank server managed by a receiving bank having a receiving account which is the transfer destination of the payment, and a management server capable of communicating with each of the user terminal, the sending bank server, and the receiving bank server, and managing the amount of the deposit related to the payment of the payment from the sending account to the receiving account, and the management server is capable of managing the billing amount related to the payment. The system, method, and program are characterized by comprising: an acquisition means for acquiring an amount and a payment deadline for the amount; a judgment means for judging whether the amount received for payment of the amount satisfies the payment conditions for the invoice amount when the payment deadline arrives; an amount deficiency notification means for notifying the user terminal of an amount deficiency when the judgment means judges that the payment conditions are not satisfied; a reason input means for having the user input a reason for the amount deficiency when the amount deficiency notification is issued; and a reason notification means for notifying the carrier terminal of the reason for the amount deficiency input by the reason input means.

This invention can improve convenience for both businesses and consumers when it comes to paying for products or services by bank transfer.

FIG. 1 is an explanatory diagram showing an example of the configuration of a payment management system of the present invention. FIG. 2 is a block diagram showing an example of the configuration of a user terminal. FIG. 2 is a block diagram showing an example of the configuration of a carrier terminal. FIG. 4 is a block diagram showing an example of the configuration of a bank server. FIG. 2 is a block diagram showing an example of the configuration of a payment management server. Flow diagram for processing insufficient amounts. FIG. 13 is an explanatory diagram showing an example of the screen layout of a screen for notifying an insufficient amount of money. FIG. 13 is an explanatory diagram showing an example of the screen layout of a reason input screen. FIG. 13 is an explanatory diagram showing an example of the screen configuration of an extension application screen. FIG. 13 is an explanatory diagram showing an example of the screen configuration of an extension notification screen. FIG. 13 is an explanatory diagram showing an example of the screen configuration of a reason notification screen. FIG. 11 is a flow diagram of a modified example of an amount determination process.

Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
<System Configuration>

Figure 1 is a block diagram showing an example of the system configuration of the payment management system 1 of the present invention. The payment management system 1 of the present invention is a system for providing a payment management service related to the settlement (payment) of the price in a transaction related to the provision of goods or services by bank transfer. The manner in which the price of a transaction is settled includes a one-time settlement, in which the price of a product or service that is provided temporarily, and a recurring settlement, in which the price of a product or service that is provided periodically and continuously. The payment management system 1 of the present invention assumes that the price is paid by bank transfer in a transaction related to a one-time settlement or a recurring settlement.

As shown in FIG. 1, the payment management system 1 has a user terminal 2, a business operator terminal 3, a bank server 4, and a payment management server 5. The user terminal 2 is a terminal used by a user (consumer) who receives goods or services from a business operator. The business operator terminal 3 is a terminal used by a business operator (product seller or service provider) who provides goods or services to users. The bank server 4 is a server managed by a financial institution such as a bank that holds an account that will be the sender or recipient of the price of the goods or services. The payment management server 5 is a server for providing payment management services.

The user terminal 2, business operator terminal 3, bank server 4, and payment management server 5 are each connected to each other so that they can communicate with each other via a communication line 6 such as the Internet. However, the payment management system 1 has multiple bank servers 4, and communication between the multiple bank servers 4 (between banks) may use a dedicated line for bank data communication.

The financial institution that holds the account from which the price of goods or services is to be remitted is called the sending bank, and the financial institution that holds the account to which the price of goods or services is to be remitted is called the receiving bank. Furthermore, in this invention, for the sake of convenience, the bank server 4 managed by the sending bank is called the sending bank server 4a, and the bank server 4 managed by the receiving bank is called the receiving bank server 4b. When there is no particular distinction between the sending bank server 4a and the receiving bank server 4b, they may simply be called "bank server 4."

The multiple bank servers 4 can be managed by banks that have accounts opened for users and/or accounts opened for businesses. Therefore, each of the multiple bank servers 4 may switch between the role of sending bank server 4a and the role of receiving bank server 4b depending on the content of the transaction. Furthermore, it is preferable that the accounts opened for businesses among the accounts at each bank are virtual accounts opened for businesses exclusively for the purpose of receiving transfers. Virtual accounts can be assigned to each transaction or each user. Therefore, when a transfer (deposit) occurs at the receiving bank server 4b, the transaction and user can be identified.

For ease of explanation, one each of the user terminal 2, business operator terminal 3, and bank server 4 (sender bank server 4a, recipient bank server 4b) is shown, but the payment management system 1 of the present invention can be used by multiple users, multiple business operators, multiple sender banks, and multiple recipient banks, and may have multiple user terminals 2, multiple business operator terminals 3, sender bank servers 4a, and recipient bank servers 4b.

The user terminal 2 and the business operator terminal 3 are general-purpose computers (user terminals) used by users. For example, they are desktop PCs, notebook (laptop) PCs, tablet PCs, smartphones, and feature phones. The bank server 4 and the payment management server 5 are each configured as a general-purpose server computer (computing device). Each of the bank server 4 and the payment management server 5 may be configured as one (single) computing device, or may be configured as multiple computing devices. Furthermore, each of the bank server 4 and the payment management server 5 may be configured as a cloud server in part or in whole.

Figure 2 is a block diagram showing an example of the configuration of the user terminal 2. Figure 3 is a block diagram showing an example of the configuration of the business operator terminal 3. Figure 4 is a block diagram showing an example of the configuration of the bank server 4. Figure 5 is a block diagram showing an example of the configuration of the payment management server 5.

As shown in FIG. 2, the user terminal 2 includes a control unit 21, an input unit 22, a display unit 23, a communication unit 24, and an auxiliary memory unit 25. Each of the input unit 22, the display unit 23, the communication unit 24, and the auxiliary memory unit 25 is communicatively connected to the control unit 21. The control unit 21 of the user terminal 2 has a calculation unit 26 and a main memory unit 27, and executes various calculations and control operations in the user terminal 2.

As shown in FIG. 3, the operator terminal 3 includes a control unit 31, an input unit 32, a display unit 33, a communication unit 34, and an auxiliary memory unit 35. The input unit 32, the display unit 33, the communication unit 34, and the auxiliary memory unit 35 are each communicatively connected to the control unit 31. The control unit 31 of the operator terminal 3 has a calculation unit 36 and a main memory unit 37, and executes various calculations and control operations in the operator terminal 3.

As shown in FIG. 4, the bank server 4 includes a control unit 41, a communication unit 42, and an auxiliary memory unit 43. The communication unit 42 and the auxiliary memory unit 43 are each communicatively connected to the control unit 41. The control unit 41 of the bank server 4 has a calculation unit 44 and a main memory unit 45, and executes various calculations and control operations in the bank server 4.

As shown in FIG. 5, the payment management server 5 includes a control unit 51, a communication unit 52, and an auxiliary memory unit 53. The communication unit 52 and the auxiliary memory unit 53 are each communicatively connected to the control unit 51. The control unit 51 of the payment management server 5 has a calculation unit 56 and a main memory unit 57, and executes various calculations and control operations in the payment management server 5.

Each of the calculation units (26, 36, 44, 56) shown in Figures 2 to 5 is a calculation processing unit including a CPU or an MPU. Each of the main memory units (27, 37, 45, 57) has a RAM (DRAM) or the like. The RAM is used as a work area and a buffer area for the calculation units (26, 36, 44, 56).

The input unit (22, 32) shown in Figures 2 and 3 has an input component that accepts operational input from a user (user or business operator's staff) of the user terminal 2 or business operator terminal 3, and an input detection circuit that is interposed between the input component and the control unit (21, 31). The input component is, for example, a touch panel and/or hardware operation keys. The touch panel can be of any type, such as a capacitive type, an electromagnetic induction type, a resistive film type, or an infrared type. The input detection circuit outputs an operation signal or operation data (operation input data) corresponding to the operation of each input component to the control unit (21, 31).

The display unit (23, 33) has a display and a display control circuit interposed between the display and the control unit (21, 31). The display may be, for example, an LCD (liquid crystal display) or an organic EL display.

The communication units (24, 34, 42, 52) shown in Figures 2 to 5 have communication circuits for connecting to the communication line 6. The communication circuits are wired or wireless communication circuits, and communicate with an external computer via the communication line 6 according to instructions from the calculation units (26, 36, 44, 56). In addition, the communication units (24, 34, 42, 52) of the user terminal 2, business operator terminal 3, bank server 4, and payment management server 5 can also communicate directly with each other via a dedicated line or the like, without going through the communication line 6. In particular, the communication unit 42 of the bank server 4 can also communicate via a dedicated line for bank data communication.

The auxiliary memory units (25, 35, 43, 53) are composed of non-volatile memory such as HDD, SSD, flash memory, and EEPROM, and store programs for each calculation unit (26, 36, 44, 56) to control the operation of the user terminal 2, business operator terminal 3, bank server 4, and payment management server 5, as well as various data necessary for using the system.

As shown in FIG. 2, the auxiliary memory unit 25 of the user terminal 2 stores a user program 25a for executing various operations of the user terminal 2 in the system in response to operational input by the user, and user data 25b necessary for using the system. The user program 25a and user data 25b are read out from the auxiliary memory unit 25 as necessary and stored (expanded) in the main memory unit 27. The operation of the user terminal 2 is realized by the calculation unit 26 executing the user program 25a expanded in the main memory unit 27.

The user program 25a includes at least a communication program for accessing (establishing communication with) an external computer (e.g., the business operator terminal 3, the bank server 4, and the payment management server 5), a display program for displaying various screens on the display unit 23, an input program for accepting input operations from the user via the input unit 22, and a program for selecting and executing various functions provided in the user terminal 2. The user data 25b includes at least the user data required in this system.

As shown in FIG. 3, the auxiliary memory unit 35 of the operator terminal 3 stores operator programs 35a for executing various operations of the operator terminal 3, and operator data 35b necessary for using the system. The operator programs 35a and operator data 35b are read from the auxiliary memory unit 35 as necessary and stored (expanded) in the main memory unit 37. The operation of the operator terminal 3 is realized by the calculation unit 36 executing the operator programs 35a expanded in the main memory unit 37.

The business operator program 35a includes at least a communications program for accessing (establishing communication with) an external computer (e.g., the user terminal 2, the bank server 4, and the payment management server 5), a billing amount notification program for notifying the payment management server 5 of data on the price (billing amount) for each transaction (billing amount data), a deadline notification program for notifying the payment management server 5 of data on the payment deadline for the price for each transaction linked to the billing amount data (deadline data), an input program for accepting input operations from the business operator's personnel (user of the business operator terminal 3) via the input unit 32, and a program for selecting and executing various functions provided by the business operator terminal 3.

As shown in FIG. 4, the auxiliary memory unit 43 of the bank server 4 stores a bank program 43a for executing various operations of the bank server 4, and bank data 43b necessary for using the system. The bank program 43a and bank data 43b are read from the auxiliary memory unit 43 as necessary and stored (expanded) in the main memory unit 45. The operation of the business operator terminal 3 is realized by the calculation unit 44 executing the bank program 43a expanded in the main memory unit 45.

The bank program 43a includes at least a communications program for accessing (establishing communication with) external computers (e.g., the user terminal 2, the business terminal 3, other bank servers 4, and the payment management server 5), a remittance program for sending (bank transfer) money to other banks (recipient banks) based on a user's request, a deposit amount notification program for notifying the payment management server 5 of data (deposit amount data) of the amount transferred (remitted) from other banks for each transaction, and a program for selecting and executing various functions provided by the bank server 4.

As shown in FIG. 5, the auxiliary memory unit 53 of the payment management server 5 stores a payment management program 54 for executing various operations of the payment management server 5, and payment management data 55 necessary for using the system. The payment management program 54 and the payment management data 55 are read from the auxiliary memory unit 53 as needed and temporarily stored in the main memory unit 57. The operation of the payment management server 5 is realized by the calculation unit 56 executing the payment management program 54 temporarily stored in the main memory unit 57.

The payment management program 54 includes at least a main processing program 54a for selecting and executing various functions of the payment management server 5, a billing amount management program 54b for managing billing amount data notified from the business terminal 3, a deposit amount management program 54c for managing deposit amount data notified from the bank server 4, an amount determination program 54d for comparing the billing amount with the deposit amount to determine whether payment is complete (deposit is complete) for each transaction, a user notification program 54e for notifying the user (user terminal 2) of the completion of deposit for each transaction or of an insufficient amount, a reason acquisition program 54f for acquiring the reason for the insufficient amount from the user for each transaction in the case of an insufficient amount, and a business notification program 54g for notifying the business of the completion of deposit or of the reason for the insufficient amount for each transaction in the case of an insufficient amount.

The settlement management data 55 includes user data 55a, which is data on users who use the system, business data 55b, which is data on businesses who use the system, billing amount data 55c for each transaction notified from the business terminal 3, deadline data 55d indicating the deadline for payment of the price for each transaction, deposit amount data 55e for each transaction notified from the bank server 4, reason data 55f indicating the reason for a shortfall in the amount for each transaction, etc. User data 55a includes data on a bank account (transfer account) for direct debit that is registered in advance. Note that billing amount data 55c, deadline data 55d, deposit amount data 55e, and reason data 55f are each stored in a manner that allows them to be distinguished for each transaction, such as by being linked to identification information (ID) for each transaction, and when a virtual account is used, the virtual account number is also linked.

The user data 55a includes data for linking the user terminal 2 with the user (the user of the user terminal 2). The business operator data 55b includes data for linking the business operator terminal 3 with the business operator (the user of the business operator terminal 3).

The above-mentioned configurations of the user terminal 2, the bank server 4, the business operator terminal 3, and the payment management server 5 are merely examples, and the present invention is not limited to these.
<System operation example>

An example of the operation of the settlement management system 1 will be described below. First, a brief description will be given of the generation of the billing amount data 55c, which is a premise for describing the example of the operation of the settlement management system 1. When a transaction related to the provision of a product or service is performed between a business operator and a user, the business operator terminal 3 notifies the settlement management server 5 of the data of the price of the transaction (billing amount) (billing amount data) and the data of the payment deadline linked to the billing amount data (expiry date data). The settlement management server 5 stores the billing amount data and the deadline data notified from the business operator terminal 3 as billing amount data 55c and deadline data 55d. In addition, when a user transfers (remits) money from his/her own account (sender bank account) to the business operator's account (recipient bank account) to pay the price of the transaction, the recipient bank server 4b notifies the settlement management server 5 of the data of the amount (deposit amount) transferred (remitted) from the sender bank account (deposit amount data). The settlement management server 5 stores the deposit amount data notified from the recipient bank server 4b as deposit amount data 55e. As described above, the billing amount data 55c, the term data 55d, and the deposit amount data 55e are stored in a manner that allows them to be distinguished for each transaction.
<Processing insufficient amount>

Figure 6 is a flow diagram of the insufficient amount process. Figure 7 is an explanatory diagram showing an example of the screen configuration of the notification mail 100. Figure 8 is an explanatory diagram showing an example of the screen configuration of the reason input screen 110. Figure 9 is an explanatory diagram showing an example of the screen configuration of the extension application screen 120. Figure 10 is an explanatory diagram showing an example of the screen configuration of the extension notification screen 130. Figure 11 is an explanatory diagram showing an example of the screen configuration of the reason notification screen 140. Below, the insufficient amount process that notifies the user of the insufficient amount will be described with reference to Figures 6 to 11. In addition, the insufficient amount process executed in the case of insufficient amount is an automatic extension process that automatically extends the payment deadline for a specified period according to the settings of the business operator, and a manual extension process that extends the payment deadline for a specified period when an extension is applied for by the user. The settlement management server 5 (control unit 51) first checks whether the automatic extension process has been set by the business operator, and if so, automatically extends the payment deadline for a specified period and displays the extension notification screen 130 of Figure 10. If the automatic extension process has not been set by the business operator, the insufficient amount process shown in Figure 6 is executed.

The insufficient amount process shown in Figure 6 is a process performed by the payment management server 5 (control unit 51) in cooperation with the user terminal 2, bank server 4, business operator terminal 3, etc. The insufficient amount process is executed when the payment of a transaction does not satisfy the payment conditions when the payment deadline for that transaction arrives. For example, the payment conditions are whether the deposit amount for the transaction is equal to or greater than the invoice amount (including the same amount), and if the deposit amount is equal to or greater than the invoice amount, it is determined that the payment conditions are satisfied, and if the deposit amount is less than the invoice amount, it is determined that the payment conditions are not satisfied. Note that if it is determined that the payment conditions are satisfied when the payment deadline arrives, the insufficient amount process is not executed.

As shown in FIG. 6, when the payment management server 5 starts the insufficient amount process, it notifies the user terminal 2 used by the user (the billee in the transaction that resulted in the insufficient amount) of the insufficient amount (step S1), and determines whether to proceed to input the reason for the insufficient amount (step S2).

For example, in step S1, the payment management server 5 sends a notification email 100 with the contents shown in FIG. 7 to the user terminal 2 of the user (billed party). The notification email 100 includes a shortage notification section 101 and a link 102 for entering a reason.

The shortage notification section 101 is the main text of the notification email 100, and is composed of a sentence notifying the user that the amount of the deposit is short of the amount of the invoice. The shortage notification section 101 includes information such as the fact that the amount of the deposit is short of the amount of the invoice, the shortfall amount, and a request to input the reason for the shortfall. In the example shown in FIG. 7, the shortage notification section 101 includes information on the expiration date (response deadline) of the reason input link 102. If the business operator does not bear the transfer fee, the notification of this shortage notification section 101 clearly indicates the shortfall amount obtained by subtracting the amount of the deposit (the amount of the money received at the destination bank) from the amount of the invoice, and if the business operator bears the transfer fee, the shortfall can be displayed in a different format (for example, a notice that there is a shortfall, a display showing the range of the amount obtained by subtracting the amount of the deposit from the amount of the invoice and adding the transfer fee, etc.). This allows the notification to be as easy to understand as possible for the user while meeting the convenience of the business operator.

The reason input link 102 is a hyperlink for accessing the payment management server 5 and displaying a web page for inputting the reason for the insufficient amount. The reason input link 102 may be a text link that displays text such as a URL for displaying a web page, or it may be an image link or a button-type link.

In addition, instead of the notification email 100, the notification can be sent to the user terminal 2 as a pop-up screen equivalent to the notification email 100, which has a shortage notification section 101 and a link for inputting a reason 102.

Returning to FIG. 6, if the link for entering the reason 102 is not selected, the payment management server 5 does not decide to proceed to input the reason for the insufficient amount (step S2: NO), and waits until the deadline for entering the reason for the insufficient amount (response deadline). If the deadline for entering the reason for the insufficient amount (response deadline) arrives without the link for entering the reason 102 being selected, the insufficient amount processing is terminated.

On the other hand, in step S2, if the reason input link 102 is selected, the payment management server 5 determines to proceed to input the reason for the insufficient amount (step S2: YES), displays a web page for inputting the reason for the insufficient amount on the display unit 23 of the user terminal 2 (step S3), and determines whether the reason for the insufficient amount has been input (step S4).

For example, in step S3, the payment management server 5 displays (notifies) a reason input screen 110 with the content as shown in FIG. 8 on the user terminal 2 of the user (billed party). The reason input screen 110 has a notification section 111, a reason input section 112, and a scheduled payment completion date input section 113.

The notification section 111 is composed of a notification text 111a that prompts the user to input the reason for the insufficient amount, and a deadline display section 111b that indicates the end of the period during which the reason for the insufficient amount can be input (the response deadline or input deadline).

The reason input unit 112 is provided for inputting the reason for the insufficient amount. For example, the reason input unit 112 presents options corresponding to each of a plurality of predefined candidate reasons for the insufficient amount.

In this embodiment, the reason input unit 112 has a number of selection buttons 112a to 112c that are assigned to multiple types of candidates for the reason for the shortfall. The selection buttons 112a to 112c function as so-called software keys (operation buttons). Hereinafter, the software keys are simply referred to as "buttons." Specifically, the reason input unit 112 has a selection button 112a to which "Mistake in transfer amount" is assigned, which corresponds to the case where the user makes a mistake in the amount of the transfer as the reason for the shortfall, a selection button 112b to which "Upper limit on transfer amount" is assigned, which corresponds to the case where an upper limit is set for the transfer amount and the upper limit is less than the amount claimed, and a selection button 112c to which "Other" is assigned, which corresponds to the reason for the shortfall other than "Mistake in transfer amount" and "Upper limit on transfer amount" as the reason for the shortfall. Instead of the selection buttons 112a-112c, the reason input section 112 may have check boxes or radio buttons assigned to each of a number of possible reasons for the shortfall, or a text box (input field) for receiving input of characters indicating the reason for the shortfall. The expected payment completion date input section 113 is provided for inputting the expected payment completion date for the shortfall amount. For example, the expected payment completion date input section 113 has a text box (input field) 113a for inputting the expected payment completion date. However, the expected payment completion date can only be set to a date prior to the payment deadline.

Returning to FIG. 6, if the reason for the insufficient amount is not input in step S4 (step S2: NO), the payment management server 5 waits until the reason for the insufficient amount is input. However, if the deadline for inputting the reason for the insufficient amount (response deadline) arrives without the reason for the insufficient amount being input, the insufficient amount processing is terminated.

On the other hand, if a reason for the insufficient amount is input in the reason input unit 112, the input reason for the insufficient amount is obtained (step S5), an extension application screen for extending the payment deadline is displayed on the display unit 23 of the user terminal 2 (step S6), and it is determined whether an extension application has been made (whether an extension application has been made) (step S7).

For example, in step S6, the payment management server 5 displays (notifies) an extension application screen 120 as shown in FIG. 9 on the user terminal 2 of the user (claimee). The extension application screen 120 has a content notification section 121, a deadline notification section 122, and an extension necessity selection section 123.

The content notification section 121 is composed of a sentence notifying that it is possible to apply for an extension of the payment deadline. The deadline notification section 122 is composed of text notifying the date of the deadline by which the extension application can be made (extension application deadline) and the date of the extended payment deadline. The dates of the deadline by which the extension application can be made and the extended payment deadline are each set in advance by the business operator for each transaction.

The extension necessity selection unit 123 is provided to select whether or not to make an extension application. For example, the extension necessity selection unit 123 presents options corresponding to the cases where an extension application is made and where an extension application is not made. In this embodiment, the extension necessity selection unit 123 has a selection button 123a assigned to the case where an extension application is made and a selection button 123b assigned to the case where an extension application is not made. Note that the extension necessity selection unit 123 may have check boxes or radio buttons assigned to the cases where an extension application is made and where an extension application is not made, respectively, instead of the selection buttons 123a and 123b.

Returning to FIG. 6, if the settlement management server 5 determines in step S7 that there is no extension request, it proceeds to the unpaid (uncollected) payment collection process assuming that the user has no intention of paying the fee (step S8) and ends the insufficient amount process. Here, the absence of an extension request includes the case where the option assigned to not request an extension (selection button 123b in this embodiment) is selected in the extension necessity selection unit 123, or the case where the option assigned to request an extension by the deadline for which an extension application can be made is not selected. Here, if the receiving account is a virtual account, the settlement management server 5 instructs the sending bank server 4a or the receiving bank server 4b to delete the virtual account. This makes it possible to prevent money from being deposited while the unpaid payment collection process is in progress. In addition, when the unpaid payment collection process is started, the unpaid (uncollected) payment is collected by a method other than the normal payment method. Note that a detailed explanation of the specific method of unpaid payment collection is omitted since it is not essential to the present invention and a known method such as mailing a payment slip to the user for each transaction can be used.

In step S7, if it is determined that there is an extension request, that is, if the option assigned to the case where an extension application is made by the deadline for which an extension application can be made (selection button 123a in this embodiment) is selected, the payment deadline is extended (step S9). Then, when the payment deadline is extended (step S9), the user terminal 2 is notified of the extended payment deadline (step S10), and the business terminal 3 is notified of the expected date of completion of the deposit, the reason for the shortfall in the amount, and the extended payment deadline (step S11), and the shortfall in the amount process is terminated. If the receiving account is a virtual account, the settlement management server 5 issues a continuation instruction to the sending bank server 4a or the receiving bank server 4b so as not to delete the account until the extended payment deadline. Note that if the opening period of the virtual account was set long enough to include the extended payment deadline when the virtual account was opened, a configuration may be adopted in which no particular continuation instruction is issued. Also, if the payment of the amount of the transaction does not satisfy the settlement conditions when the extended payment deadline arrives, the shortfall in the amount process is not executed, and the process moves to the unpaid amount collection process.

Then, in step S9, the payment management server 5 displays (notifies) the user terminal 2 of the user (billed party) of the extended payment deadline by email, a pop-up screen, or the like. For example, in step S9, the payment management server 5 notifies the user terminal 2 of the user (billed party) of an extension notification screen 130 with the content as shown in FIG. 10. The extension notification screen 130 has an extension notification section 131 that notifies that the payment deadline has been extended, an extension deadline notification section 132 that notifies the date of the extended payment deadline, and an amount notification section 133 that notifies the amount of the bill.

In addition, in step S10, the payment management server 5 displays (notifies) the expected payment completion date, the reason for the shortfall, and the extended payment deadline on the business operator's (biller's) business terminal 3 by email, a pop-up screen, etc. For example, in step S10, the payment management server 5 notifies the business operator's (biller's) business terminal 3 of a reason notification screen 140 with content as shown in FIG. 11. The reason notification screen 140 has a reason notification section 141 that notifies the reason for the shortfall, an extended deadline notification section 142 that notifies the extended payment deadline, and a payment schedule notification section 143 that notifies the expected payment completion date.

As described above, in the payment management system 1 of the present invention, when the payment deadline arrives and the amount deposited for payment is less than the invoiced amount (insufficient amount), the system obtains the reason for the insufficient amount entered by the user (billed party) and notifies the business (biller) of the reason for the insufficient amount. Conventionally, when the amount is insufficient, a business's staff member would visit the user, call or email the user to inquire, and manually obtain the reason for the insufficient amount and the expected date for completion of payment, but the present invention eliminates this hassle.

In addition, according to the present invention, the user is presented with options corresponding to each of multiple pre-set possible reasons for the shortfall, so the user only needs to select an option, improving user convenience.

Furthermore, according to the present invention, when it is determined that the amount of payment is insufficient for the amount of the invoice, the user is allowed to select whether or not to request an extension of the payment deadline, and when an extension of the payment deadline is requested, the payment deadline is extended for a predetermined period of time, thereby improving user convenience. Also, when the business operator has set the payment deadline to be automatically extended when the amount is insufficient, the payment deadline is automatically extended for a predetermined period of time without inquiring of the user. In this case, payment can be made within the extended payment deadline without the user having to apply for an extension, improving both user convenience and business operator convenience.
<Modification of amount judgment process>

In the above embodiment, the payment condition is whether the amount received for payment of the transaction price is equal to or greater than the invoice amount, but this does not have to be limited to this and payment conditions can be set flexibly.

Figure 12 is a flow diagram of the amount determination process of a modified example. The amount determination process shown in Figure 12 is a process performed by the payment management server 5 (control unit 51) in cooperation with the user terminal 2, the bank server 4, the business operator terminal 3, etc.

When the payment management server 5 starts the amount determination process, it obtains the deposit amount directly or indirectly from the receiving bank server 4b (step S21) and determines whether the business operator will cover the transfer fee (step S22).

For example, in step S21, the payment management server 5 can obtain the deposit amount each time a deposit is made, or can obtain the sum of the amounts deposited up to that point (total amount) as the deposit amount when the payment deadline arrives.

If the payment management server 5 determines in step S22 that the business operator will not cover the transfer fee, it sets the invoice amount as an amount for the determination process (determination amount) that serves as the standard for determining whether the payment conditions are met (step S23), and proceeds to step S25, described below. On the other hand, if it determines that the business operator will cover the transfer fee, it sets the determination amount to an acceptable range based on the invoice amount and the amount equivalent to the transfer fee (step S24), and proceeds to step S25. Note that this acceptable range is set arbitrarily for each business operator, and the acceptable range for that business operator is set as the determination amount.

Next, in step S25, it is determined whether the deposit amount is equal to or greater than the determination amount. Note that in step S25, if an acceptable range was set to the determination amount in step S24, it is determined whether the deposit amount is equal to or greater than the lower limit of the acceptable range. In step S25, if it is determined that the deposit amount is not equal to or greater than the determination amount, i.e., the deposit amount is less than the determination amount (step S25: NO), the process proceeds to the amount deficiency process (step S26) described above, and the amount determination process ends.

On the other hand, if it is determined in step S25 that the deposit amount is equal to or greater than the judgment amount (step S25: YES), it is determined whether the deposit amount exceeds the judgment amount (step S27). Note that in step S27, if the allowable range is set to the judgment amount in step S24, it is determined whether the deposit amount exceeds the upper limit of the allowable range.

If it is determined in step S27 that the deposited amount exceeds the determination amount (step S27: YES), the process proceeds to refund processing (step S28) for refunding the excess amount to the user, and the amount determination process ends. For example, in the refund processing, a person in charge at the business informs the user of the refund amount and refund method, or an email informing the user (user terminal 2) of the refund amount and refund method is automatically sent from the payment management server 5. The user informs the business of the refund account by an appropriate method such as email.

On the other hand, if it is determined in step S27 that the deposited amount does not exceed the judgment amount, i.e., that the deposited amount is included in the judgment amount or matches the judgment amount (step S27: NO), the user (billed party) is notified of the completion of the deposit by email or a pop-up screen, etc. (step S29), and the amount judgment process is terminated.

As described above, in the amount determination process of the present invention, in cases where the business entity pays the transfer fee, it is determined that the payment conditions are met if the amount is within an acceptable range based on the invoice amount and the amount equivalent to the transfer fee, and in cases where the business entity does not pay the transfer fee, it is determined that the payment conditions are met if the deposited amount matches the invoice amount. Therefore, payment conditions can be flexibly set according to the practical application of the transaction, improving convenience for both the business entity and the user.

Furthermore, conventionally, when a user makes a transfer, the sending bank would notify the user that the transfer was complete, but the receiving bank would not receive a notification that the funds had arrived. In contrast, with the amount determination process of the present invention, if it is determined that the deposited amount is included in the determined amount or that the deposited amount matches the determined amount, the user is notified that the deposit has been completed, which has the advantage of allowing the user to check whether the money has been sent to the receiving bank, giving the user peace of mind.

The management server of this invention corresponds to the payment management server 5 in the above embodiment, the user terminal corresponds to the user terminal 2, the business terminal corresponds to the business terminal 3, the sending bank server corresponds to the sending bank server 4a, the receiving bank server corresponds to the receiving bank server 4b, the management server corresponds to the payment management server 5, the acquisition means corresponds to the billing amount management program 54b and the control unit 51 that operates in accordance with this, the judgment means corresponds to the amount judgment program 54d and the control unit 51 that operates in accordance with this, the amount deficiency notification means corresponds to the deficiency notification unit 101, the reason input means corresponds to the reason input unit 112, the reason notification means corresponds to the reason notification unit 141, the payment completion notification means corresponds to step S29, the extension application necessity selection means corresponds to the extension necessity selection unit 123, and the payment deadline extension means corresponds to the selection button 123a, but this invention is not limited to this embodiment and can be in various other embodiments. Additionally, the screens and specific configurations described in the above embodiments are merely examples and can be modified as appropriate depending on the actual product.

This invention can be used in industries related to payment for goods or services by bank transfer.

Reference Signs List 1: Settlement management system 2: User terminal 3: Business operator server 4: Bank server 4a: Sender bank server 4b: Recipient bank server 5: Settlement management server 51: Control unit

Claims (7)

A business terminal used by a business that provides a product or service;
A user terminal used by a user who receives the product or service;
a sending bank server managed by a sending bank having a sending account from which the payment for the transaction relating to the provision of the product or service is transferred;
a receiving bank server managed by a receiving bank having a receiving account to which the payment is to be transferred;
a management server capable of communicating with each of the user terminal, the sending bank server, and the receiving bank server, and managing a deposit amount relating to the payment of the price from the sending account to the receiving account;
The management server includes:
An acquisition means for acquiring the billing amount and the payment deadline for the price;
a determination means for determining whether or not the amount of the deposit related to the payment of the price satisfies a settlement condition with respect to the invoice amount when the payment deadline arrives;
an amount deficiency notification means for notifying said user terminal of an amount deficiency when said determination means determines that said payment conditions are not satisfied;
a reason input means for allowing the user to input a reason for the amount deficiency when the amount deficiency notification is issued;
a reason notifying means for notifying the business operator terminal of the reason for the shortfall in the amount input by the reason input means. 2. The payment management system according to claim 1, wherein said reason input means presents to said user options corresponding to each of a plurality of preset candidates for the reason of the shortfall in amount. The management server includes:
3. A payment management system according to claim 2, further comprising a payment completion notifying means for notifying said user terminal of a payment completion when said judging means judges that said payment conditions are satisfied. The determination means is
If the business operator bears the transfer fee, it is determined that the payment conditions are met if the amount is within the range based on the deposit amount and the amount equivalent to the transfer fee;
2. A payment management system as described in claim 1, configured to determine that the payment conditions are met if the amount of the deposit matches the amount of the invoice if the business operator does not cover the transfer fee. The management server includes:
an extension application necessity selection means for allowing a user to select whether or not to request an extension of the payment deadline when the determination means determines that the amount of the deposit is insufficient to cover the amount of the invoice;
5. A payment management system according to claim 1, further comprising a payment deadline extension means for extending the payment deadline for a predetermined period when the extension request is received. A business terminal used by a business that provides a product or service;
A user terminal used by a user who receives the product or service;
a sending bank server managed by a sending bank having a sending account from which the payment for the transaction relating to the provision of the product or service is transferred;
a receiving bank server managed by a receiving bank having a receiving account to which the payment is to be transferred;
A payment management method in a payment management system including a management server capable of communicating with each of the user terminal, the sending bank server, and the receiving bank server, and managing a deposit amount relating to the payment of the price from the sending account to the receiving account, comprising:
The management server ,
Obtain the invoice amount and the payment deadline for said price,
When the payment deadline arrives, it is determined whether the amount of the payment satisfies the settlement conditions for the invoice amount;
generating information for notifying the user terminal of an insufficient amount when it is determined that the payment conditions are not satisfied;
The user terminal receives the notification of the shortage of the amount, and the user inputs the reason for the shortage of the amount.
A payment management method that notifies the business operator terminal of the reason for the insufficient amount of the input amount. a management server computer capable of communicating with a business terminal used by a business providing a product or service, a user terminal used by a user receiving the product or service, a sending bank server managed by a sending bank having a sending account which is the transfer source of the payment in a transaction related to the provision of the product or service, and a receiving bank server managed by a receiving bank having a receiving account which is the transfer destination of the payment, and which manages the amount of the deposit related to the payment from the sending account to the receiving account;
An acquisition means for acquiring the billing amount and the payment deadline for the price;
a determination means for determining whether or not the amount of the deposit related to the payment of the price satisfies a settlement condition with respect to the invoice amount when the payment deadline arrives;
an amount deficiency notification means for notifying said user terminal of an amount deficiency when said determination means determines that said payment conditions are not satisfied;
a reason input means for allowing the user to input a reason for the amount deficiency when the amount deficiency notification is issued;
a payment management program that functions as a reason notifying means for notifying the business operator terminal of the reason for the shortfall in the amount input by the reason input means;

Images