JP2008152488A - Charge payment system and charge payment method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a charge payment system which can smoothly perform payment of public utility charge, etc., and can reduce payer's burden when the payer is a recipient of a pension, etc. <P>SOLUTION: A billing server 2 of a power company and a benefit server 3 of a local authority which pays pension to the payer M are connected for communication. The billing server 2 transmits an application for payment of electricity charge for the payer M who is registered beforehand to the benefit server 3. The benefit server 3 performs a payment process to pay the electricity charge to the power company and a payment process to pay the residual pension determined by deducting the electricity charge from the pension to the payer M when the payment of the electricity charge is possible from the pension based on the pension to be paid to the payer M who is registered beforehand and the electricity charge to be paid by the payer concerned M. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a charge payment system and a charge payment method for paying a charge such as an electricity charge or a gas charge to an electric power company or a gas company.

For example, there are methods of paying public charges such as electricity charges and gas charges, such as account withdrawal, transfer, bringing a window, and collecting money by a collector. In addition, a charge storage agency system using a POS (Point Of Sales) terminal is known in order to reduce the burden on the payer required for the transfer (see, for example, Patent Document 1). In this system, when a payer brings a transfer card to a convenience store or the like and pays a fee, the bar code of the transfer card is read by a POS terminal installed in the convenience store or the like. Then, the read barcode information is sent to a server such as a power company (payee), and a fee payment process is performed.
Japanese Patent Laid-Open No. 7-244663

  By the way, payments such as electricity charges and gas charges are often required every month, whereas receipts such as national pensions and disability pensions are often every two months. For this reason, recipients of the national pension, etc. may wish to transfer money, bring a window, or collect money by a collector, instead of withdrawing an account, as a payment method for electricity charges. In such a case, since the receipt of the national pension is every two months, the payment of electricity bills required every month may be delayed, and the arrears may have to be paid. Also, in the case of bringing a window, the payer who is a pensioner must go to the electric power company etc. using transportation etc., so that the payer is time-consuming and expensive. On the other hand, in the case of collecting money by a collector, the collector has to visit the payer's house, which increases the burden on the power company.

  Accordingly, the present invention provides a fee payment system and a fee payment method capable of smoothly paying public charges and the like and reducing the burden on the payer when the payer is a pensioner or the like. With the goal.

In order to achieve the above object, the invention described in claim 1 is a charge payment system that pays a charge such as an electricity charge or a gas charge to a charge claiming organization such as an electric power company or a gas company, wherein And a server of a benefit institution that provides a benefit to a payer who pays the fee, and the server of the billing institution sends a bill for the fee to a payer registered in advance to the benefit institution The benefit institution server sends the benefit paid to the pre-registered payer and the billing fee sent from the billing institution server to the payer. Based on the above, if it is possible to pay the fee from the benefit, the fee is paid to the billing institution, and the remaining benefit is calculated by subtracting the fee from the benefit. Characterized by the process of benefit to the payer.
(Function)
When the billing institution server sends a payment request for a pre-registered payer to the benefit institution server, the billing institution charges the fee if the benefit institution server can pay the fee from the benefit. Is paid, and the remaining benefit after subtracting the fee from the benefit is paid to the payer (recipient).

The invention according to claim 2 is the fee payment system according to claim 1, wherein the payment processing to the fee billing organization by the server of the benefit organization is performed for each payment request from the server of the fee billing organization. In addition, it is possible to select whether the payment is made for each benefit.
(Function)
If payment is selected for each billing request, the billing institution server pays the fee to the billing institution each time a billing request is sent from the billing institution server. On the other hand, if payment is selected for each benefit, the payment request is sent from the billing institution server, and when the benefit is paid, the benefit institution server notifies the billing institution. Fees are paid and the remaining benefits are paid to the payer.

According to a third aspect of the present invention, in the fee payment system according to the first or second aspect, at least one of the server of the fee charging institution and the server of the benefit institution is prior to the payment processing to the fee charging institution. The payer is notified that the fee will be paid from the benefit.
(Function)
When a request for payment is transmitted from the server of the billing institution to the server of the benefit institution, the payer is notified from the benefit institution server or the like that the fee is to be paid from the benefit, and then the fee is paid to the fee institution.

  The invention according to claim 4 is a charge payment method for paying a charge such as an electricity charge or a gas charge to a charge claiming organization such as an electric power company or a gas company, from the charge claiming organization to a payer who pays the charge. A payment request for the fee to a pre-registered payer is sent to the benefit institution that provides the benefit, and the benefit institution provides the benefit to the pre-registered payer and the payer. Based on the billing fee sent from the billing institution, if the fee can be paid from the benefit, the fee is paid to the billing institution and the fee is deducted from the benefit The remaining benefit is provided to the payer.

  The invention according to claim 5 is the fee payment method according to claim 4, wherein the payment from the benefit organization to the fee billing organization is performed for each payment request or for each benefit payment. It is possible to select.

  According to a sixth aspect of the present invention, in the fee payment method according to the fourth or fifth aspect, at least one of the fee billing institution and the benefit institution is provided with the benefit before the payment to the fee billing institution. The payer is notified that the fee is to be paid.

  According to the invention described in claims 1 and 4, when the payment request is sent from the charge institution to the benefit institution, and the charge can be paid from the benefit, the fee is paid from the benefit institution to the charge institution. The remaining benefit is paid to the payer (recipient) from the benefit organization. In this way, since the fee is automatically and directly paid from the benefit organization to the billing organization, there is no need for the payer to make a transfer or bring a counter, and there is no forgetting to pay. As a result, payment can be made smoothly and the burden on the payer can be reduced. On the other hand, as a charge requesting organization, it is possible to reliably collect fees, and it is not necessary to collect money by a collector, thereby reducing collection costs.

  According to the inventions of claims 2 and 5, since it is possible to select whether payment to the billing organization is made for each payment request or for each benefit payment, the benefit conditions and fees from the benefit organization Flexible payment according to the payment conditions to the billing institution becomes possible.

  According to the invention described in claims 3 and 6, since the payer is notified that the fee is to be paid from the benefit before the payment to the billing institution, the fee is charged after confirming the intention of the payer. It is possible to make payments to the institution and respect the intentions and profits of the payer.

  The present invention will be described below based on the illustrated embodiments.

  FIG. 1 is a schematic configuration diagram of a fee payment system 1 according to an embodiment of the present invention. This fee payment system 1 is a system for paying a fee such as an electricity bill or a gas fee to a billing institution such as an electric power company or a gas company. In this embodiment, the payer M who pays the fee receives a pension (benefits). ) Will be explained by taking an example of paying an electricity bill to a power company from a local public entity (benefits organization).

  In the fee payment system 1, a billing server 2 installed in an electric power company and a benefit server 3 installed in a local public entity (insurance agency) are connected via a communication network N so that they can communicate with each other. As shown in FIG. 2, the billing server 2 includes a customer database 21, a billing reception task 22, a billing task 23, a payment cancellation task 24, and a control task 25 that controls the activation of these. Yes. As shown in FIG. 3, the benefit-side server 3 includes a recipient database 31, a benefit-side reception task 32, a benefit task 33, and a control task 34 that controls these activations.

  The customer database 21 is a database that stores information on each customer (payer M). As shown in FIG. 4, for each contract number 211, a customer name 212, a contact address 213, a location 214, and a contract type. 215, service registration 216, and others 217 are stored. The customer name 212 stores the name of the customer (payer M), and the contact 213 stores the customer's contact telephone number and e-mail address. The location 214 stores the location address of the customer's house H, and the contract type 215 stores the type of contract content that the customer contracts with the power company. The service registration 216 stores whether or not to receive the service provided by the system 1, that is, the service for paying the electricity bill from the pension. If not, the pension number 216a and the billing month 216b are NULL (zero). It has become. When receiving the service, the billing reception task 22 stores the customer's pension number in the pension number 216a and the billing month of the electricity bill in the billing month 216b as will be described later.

  The billing-side reception task 22 and the benefit-side reception task 32 are tasks for receiving a service application by the system 1 and perform determination and processing as shown in FIG. That is, when the payer M accesses the billing server 2 through the portable terminal M1 and transmits the application information for this service (step S1), the billing reception task 22 determines whether or not the payment can be accepted (step S2). That is, the contract number in the application information and the contract number 211 in the customer database 21 are compared and confirmed to determine whether or not the payer M who can receive this service is available. If the message cannot be received, a message indicating that the message cannot be received is transmitted to the portable terminal M1 or the like (step S3). On the other hand, if it can be accepted, the application information is transmitted to the benefit server 3 (step S4), and the application information is stored in the memory. Here, the application information includes the payer M's pension number, and the application information is transmitted including the power company name and the contractor number 211 of the payer M in the application information.

  Next, whether or not the service can be provided is determined by the benefit side reception task 32 (step S5). In other words, this service is paid based on whether there is a service provision contract with the electric power company that transmitted the application information, whether the pension number in the application information matches the pension number 311 in the recipient database 31 described later, etc. It is determined whether or not it can be provided to the person M. If the message cannot be provided, a message that cannot be provided is transmitted to the billing server 2 (step S6), and a message that cannot be provided is transmitted from the billing reception task 22 to the mobile terminal M1 of the payer M or the like.

  On the other hand, if the service can be provided, the payment month is determined (step S7). In other words, it is possible to select whether payment to the electric power company is to be made for each payment request from the billing server 2 (monthly) or for each benefit of the pension (every two months). Predetermined by agreement between the public body and the power company. That is, the benefit side reception task 32 determines the payment month based on the power company name. In this embodiment, the following will be described assuming that payment is made every benefit month. Next, service provision is registered based on the application information (step S8). That is, the contract number 211 in the application information is stored in the contract number 315a in the recipient database 31. Subsequently, the registered message is transmitted to the billing server 2 (step S9). This message includes the payer M's pension number and the payment month (billing month). The billing reception task 22 assigns the pension number and payment to the pension number 216a and the billing month 216b in the customer database 21, respectively. The service provision is registered by storing the month (step S10). Then, the registered message is transmitted from the billing side reception task 22 to the portable terminal M1 or the like (step S11).

  The billing task 23 is started every month by the control task 25, and performs a process of creating and shipping a bill to each payer M (customer), and also provides a pre-registered payer M, that is, the provision of this service. This is a task of transmitting an electricity bill payment request to the payer M to be received to the benefit server 3, and is based on the flowchart shown in FIG. First, an electricity rate list of each payer M (each contract number) is acquired from a rate server that calculates an electricity rate based on the power usage of each payer M (step S21). Next, customer information (data) of the first payer M in the electricity rate list is acquired from the customer database 21 (step S22). Then, it is determined whether or not the payer M is provided with the service (step S23). That is, it is confirmed whether or not the payer M's pension number 216a is NULL. If the payment is not received (in the case of NULL), an invoice B is created (step S24). This invoice B is the same as an ordinary invoice, and is an invoice for the payer M to transfer money. Specifically, as shown in FIG. 7, an “electricity bill” indicating a billing amount (electricity fee), a contract number, etc., a “payment handling slip”, and a “payment slip / receipt” are 1 It is written on a sheet of paper.

  On the other hand, when receiving the provision of this service, the billing month 216b of the payer M determines whether or not the month is the billing month (step S25). If it is not the billing month, it sends (notifies) that the billing month is not the billing month together with the contract number of the payer M (step S26). As a result, the charge server adds the monthly electricity charge of the payer M to the next electricity charge.

  If the month is a billing month, data is added to the billing list 231 (step S27). That is, the pension number 216a of the payer M is stored in the pension number 231 of the billing list 231 as shown in FIG. 8, and the contract number 211 of the payer M is stored in the contract number 231b. In addition, the electricity rate in the electricity rate list is stored in the billing amount 231c, and the month is stored in the billing year / month 231d. Next, bill A is created (step S28). As shown in FIG. 9, this invoice A includes an invoice amount, contract number, etc. as an “electricity bill,” and “this electricity fee is paid directly from the customer's pension. Since there is no transfer, etc. are not necessary. "

  Next, it is determined whether or not the processing for all payers M in the electricity rate list has been completed (step S29). And when not complete | finished, the consumer information of the next payer M in an electricity bill list | wrist is acquired from the consumer database 21 (step S30), it returns to step S23, and the same process is repeated. On the other hand, when the processing for all payers M is completed, the created invoices A and B are sent out (step S31). That is, the invoices A and B and the shipping instruction are transmitted to the computer or server of the department that sends out the invoices A and B. Further, the created billing list 231 is transmitted to the benefit server 3 (step S32). Based on this billing list 231, the benefit server 3 stores the billing amount 231c in the billing amount 315b of the recipient database 31 described later, and the billing target month 315c stores the billing target month 231d. It is.

  As described above, in the billing task 23, the bill A is sent to the payer M who receives the provision of this service, so that the electricity bill is paid from the pension before the payment processing by the benefit server 3 described later. The payer M is notified that the payment will be made. In the billing task 23, it is determined whether or not the month is the billing month (step S25), thereby matching the billing month with the pension benefit month. In other words, the payment server 3 is billed only during the payment month of the pension. On the other hand, the meter reading itself is set to the pension benefit month (every two months), and the data of the payer M who receives this service (electricity charges, etc.) is included only in the pension benefit month. You may make it mount on. Alternatively, the payment server 3 may be billed monthly, and the payment server 3 may determine the payment timing.

  The payment cancellation task 24 is performed when a notification that the service is not received for the month is received from the mobile terminal M1 of the payer M who is provided with the service, and from the benefit server 3 as described later. This is a task for performing processing that does not apply this service when the non-payment list 331 is received, and is based on the flowchart shown in FIG. First, when the above notification is received from the payer M (in the case of “Y” in step S41), it is determined whether or not the service application can be canceled (step S42). That is, the notification reception date and the payment processing date are compared to determine whether or not the benefit server 3 can cancel. If cancellation is not possible, a message indicating that cancellation is not possible is transmitted to the mobile terminal M1 of the payer M (step S43).

  On the other hand, if the cancellation can be made, the benefit server 3 is notified that the service is not applied for the month of the payer M (step S44). When the data is already stored in the billing amount 315b and the billing target month / month 315c of the recipient database 31, the data is deleted by the benefit server 3. Next, the bill B as described above is created for the payer M (step S45), and the bill B is sent out as described above (step S46).

  On the other hand, when the non-payment list 331 is received from the benefit server 3 (in the case of “N” in step S41), the invoice C is created for all payers M (contract number 331a) in the non-payment list 331. (Step S47). This invoice C is described in the above invoice B, “This electricity charge could not be paid directly from the customer's pension”. The invoice C is sent out (step S48).

  The beneficiary database 31 is a database that stores information on each pensioner (payer M). As shown in FIG. 11, for each pension number 311, a recipient name 312, a contact 313, a location 314, a service A registration 315 and other 316 are stored. In the recipient name 312, the name of the recipient (payer M) is stored, and in the contact address 313, the recipient's contact telephone number and e-mail address are stored. The location 214 stores the location address of the recipient's home H, and the service registration 315 stores whether or not the service is provided. That is, when not receiving the service, NULL is stored in the contract number 315a, and when receiving the service, the contract number 211 is stored as described above. When receiving a service, as described above, the billing amount 231c is stored in the billing amount 315b, and the billing year / month 231d is stored in the billing year / month 315c.

  The benefit task 33 is a task for performing pension benefit processing for the pensioner. In addition, when the recipient receives the provision of this service, the electricity fee is paid from the pension based on the annual amount paid to the recipient (payer M) and the amount of the electricity fee to be paid by the recipient. This is a task of performing a process of paying an electricity bill to an electric power company when the payment of the electricity is possible, and a process of paying the remaining pension obtained by subtracting the electricity bill from the pension to the beneficiary, based on the flowcharts shown in FIGS. ing.

  First, a list of pension benefits for each recipient is obtained from a pension calculation server that calculates the pension benefits for each recipient (step S51). Next, the recipient information (data) of the first recipient in the pension benefit list is acquired from the recipient database 31 (step S52). Then, it is determined whether or not the recipient receives provision of the service (step S53). That is, it is confirmed whether or not the contract number 315a of the recipient is NULL, and if the provision is not received (in the case of NULL), the benefit C is created (step S54). This benefit C is to notify the transfer of the pension in the same way as a normal benefit. Specifically, as shown in FIG. 14, the “pension” describes the benefit amount (annual amount), pension number, etc. “Transfer notice”.

  On the other hand, when receiving the provision of this service, it is determined whether or not the electricity bill needs to be paid in the month (step S55). That is, it is determined whether or not the billing target month 315c of the recipient is the month, and if payment is not necessary, the benefit C is created in the same manner as described above (step S54). On the other hand, if payment is necessary, it is determined whether or not the electricity bill can be paid from the pension (step S56). That is, the pension benefit amount in the pension benefit list is compared with the billing amount 315b, and if the pension benefit amount is equal to or larger than the billing amount 315b, it is determined that payment is possible. If payment is not possible, data is added to the non-payment list 331 (step S57). That is, the contract number 331a and the pension number 311 of the recipient are stored in the contract number 331a and the pension number 331b of the non-payment list 331 as shown in FIG. 15, respectively, and the billed amount 331c and the billing year / month 331d are stored. , The billing amount 315b and the billing date 315c are stored. Then, a benefit B is created for the recipient (step S58). This benefit B is written in the above-mentioned benefit C, "Because we could not pay the electricity bill from the pension, please pay directly from you."

  On the other hand, when the electricity fee can be paid from the pension, the data of the recipient is added to the payment list (step S59). This payment list has the same data structure as the non-payment list 331, and stores the contract number, the pension number, the billing amount, and the billing date of the recipient (payer M). Next, a remaining pension is calculated by subtracting the electricity bill (billed amount 315b) from the pension benefit amount (step S60), and a benefit A is created (step S61). As shown in FIG. 16, this benefit A is the above-mentioned benefit C, in which the electricity bill is written and the remaining pension (the amount of transfer) is written.

  Subsequently, it is determined whether or not the processing for all recipients in the pension benefit list has been completed (step S62). If it has not been completed, the recipient information of the next recipient in the pension benefit list is acquired from the recipient database 31 (step S63), the process returns to step S53, and the same processing is repeated. On the other hand, when the processing for all recipients is completed, the created benefits A to C are sent out (step S64). That is, the benefits A to C and the shipping instruction are transmitted to the computer or server of the department that delivers the benefits A to C. Further, a process of paying (transferring) a pension (remaining pension) to the recipient is performed (step S65). That is, the benefits A to C and the transfer instruction are transmitted to the computer (server) that transfers the pension. Next, the created payment list and non-payment list 331 are transmitted to the billing server 2 (step S66), and payment processing to the power company is performed (step S67). In other words, the payment list and the transfer instruction are transmitted to the computer (server) that transfers the fee. As a result, electricity charges are transferred to the power company.

  Next, the processing operation of the fee payment system 1 having such a configuration and the fee payment method by the fee payment system 1 will be described based on the flowchart shown in FIG.

  First, when the payer M accesses the billing server 2 and transmits the application information for this service, the request is accepted and registered by the billing reception task 22 and the benefit side reception task 32 as described above. The Then, in the billing server 2, the billing task 23 is started regularly every month (step S71). As described above, for the payer M to which this service is not applied (in the case of “N” in step S72) ), An invoice B is sent from the power company (step S73). On the other hand, for the payer M to which this service is applied (in the case of “Y” in step S72), the bill A is sent from the power company (step S74), and the created billing list 231 is displayed on the benefit server. 3 (step S75). The beneficiary server 3 that has received the billing list 231 updates the recipient database 31 as described above (step S76).

  Next, in the benefit side server 3, the benefit task 33 is activated every benefit month, that is, every two months (step S77), and for the recipients to which this service is not applied as described above (in step S78) In the case of “N”, the benefit C is sent from the local public entity (step S79). On the other hand, to the beneficiary (payer M) to which this service is applied (in the case of “Y” in step S78), the benefit A or B is sent from the local government (step S80) and all payments are received. A pension (remaining pension) is paid to the person (step S81). At the same time, a payment list and a non-payment list 331 are transmitted to the billing server 2 (step S82), and an electric bill is paid from the local public entity to the power company (step S83).

  On the other hand, when the billing server 2 receives the non-payment list 331, the payment cancellation task 24 is activated (step S84), and the invoice C as described above is sent to the payer M on the non-payment list 331. (Step S85). Further, as described above, when the payer M receives a notification that the service is not received for the month (step S86), the payment cancellation task 24 is activated (step S84), and the service application is applied. If the cancellation is possible, the bill B is sent to the payer M (step S87). Then, the payer M who has received the bill B or C pays an electric bill to the electric power company himself.

  As described above, according to the fee payment system 1 and the fee payment method, the recipient (payer M) to which this service is applied can receive a local public charge when the electricity fee can be paid from the pension. Electricity charges are paid from the group to the power company, and the remaining benefits are paid to the beneficiary from the local government. In this way, since the local public body automatically and directly pays the electricity charge to the power company, the payer M does not need to make a transfer or bring a window, and never forget to pay. As a result, payment can be made smoothly and the burden on the payer M can be reduced. On the other hand, as an electric power company, it is possible to reliably collect electricity charges, and it is not necessary to collect money by a collector, thereby reducing collection costs.

  In addition, the payment to the power company can be made for each payment request or for each pension benefit, so flexible payments can be made according to the benefit conditions from local governments or payment conditions to the power company. Is possible. Further, before payment to the power company, the payer M is informed by the bill A that he / she will pay the electricity fee from the pension. For this reason, as described above, when the payer M wants to pay for the month without paying the service, the payment can be made. That is, it is possible to respond flexibly according to the circumstances of the payer M and to respect the intention and profit of the payer M.

  Although the embodiment of the present invention has been described above, the specific configuration is not limited to this embodiment, and even if there is a design change or the like without departing from the gist of the present invention, the present invention is not limited to this embodiment. include. For example, in this embodiment, a case where a local public entity that provides a pension to the payer M pays an electricity fee to a power company has been described. However, from a benefit other than a pension, for example, from a monthly salary to a utility fee or other It can also be applied to pay the fee. In addition, by providing a plurality of service registrations 315 for one pension number 311 in the recipient database 31, it is possible to handle payments to a plurality of billing institutions. Furthermore, in this embodiment, the case where the electricity fee is paid every pension benefit month (every two months) has been described. However, the payment may be made every month, that is, every payment request. That is, the benefit task 33 may be started every month, and payment may be made (paid in advance) if there is a charge even if it is not the benefit month.

1 is a schematic configuration diagram of a fee payment system according to an embodiment of the present invention. It is a schematic block diagram of the billing server in the fee payment system of FIG. It is a schematic block diagram of the payment side server in the fee payment system of FIG. It is a data block diagram of the customer database of the billing server of FIG. It is a flowchart which shows the processing flow of the charge side reception task of the claim side server of FIG. 2, and the payment side reception task of the benefit side server of FIG. It is a flowchart of the billing task of the billing server of FIG. It is a figure which shows the bill B produced by the billing task of FIG. FIG. 7 is a data configuration diagram of a billing list created by the billing task of FIG. 6. It is a figure which shows the bill A produced by the billing task of FIG. It is a flowchart of the payment cancellation | release task of the charge side server of FIG. It is a data block diagram of the receiver database of the payment side server of FIG. It is a 1st flowchart of the payment task of the payment side server of FIG. FIG. 13 is a second flowchart of the benefit task of the benefit server in FIG. 3 (continuation of FIG. 12). It is a figure which shows the payment document C created by the payment task of FIG. FIG. 14 is a data configuration diagram of a non-payment list created by the benefit task of FIGS. It is a figure which shows the benefit document A created by the benefit task of FIG. It is a flowchart which shows the processing operation of the fee payment system of FIG. 1, and the fee payment method by this system.

Explanation of symbols

1 Fee payment system 2 Billing server (billing institution server)
21 Customer Database 22 Billing Reception Task 23 Billing Task 24 Payment Cancellation Task 25 Control Task 3 Benefit Server (Benefit Institution Server)
31 Recipient Database 32 Benefit Side Reception Task 33 Benefit Task 34 Control Task M Payer (Receiver)
M1 mobile terminal H Customer's house (receiver's house)
N communication network

Claims (6)

A charge payment system that pays charges such as electricity charges and gas charges to billing agencies such as power companies and gas companies,
The server of the billing institution and the server of the benefit institution that provides a benefit to the payer who pays the fee are connected to be communicable,
The server of the billing institution transmits a billing request for the fee to a pre-registered payer to the server of the benefit institution,
The benefit institution server determines the benefit based on the benefit paid to the pre-registered payer and the fee charged to the payer from the billing institution server. When the fee can be paid, the processing of paying the fee to the billing institution, and the remaining benefit obtained by subtracting the fee from the benefit is processed to be paid to the payer. To charge payment system.   The payment processing to the billing institution by the server of the benefit institution can be selected to be performed for each payment request from the server of the charge institution or for each benefit of the benefit. Item 2. The fee payment system according to Item 1.   At least one of the billing institution server and the benefit institution server notifies the payer that the fee will be paid from the benefit before the payment processing to the billing institution. The fee payment system according to claim 1 or 2. A charge payment method that pays charges such as electricity charges and gas charges to billing agencies such as power companies and gas companies,
The billing institution sends a payment request for the fee to a pre-registered payer to a benefit institution that provides benefits to the payer who pays the fee,
Based on the benefits provided to the pre-registered payer and the payment request fee sent from the charge requesting organization to the payer, the benefit organization determines the amount of the charge from the benefit. When payment is possible, the fee is paid to the billing institution, and a remaining benefit obtained by subtracting the fee from the benefit is paid to the payer.   5. The fee payment method according to claim 4, wherein the payment from the benefit organization to the fee billing organization can be selected for each payment request or for each payment of the benefit. 6. At least one of the billing institution and the benefit institution notifies the payer that the fee will be paid from the benefit before payment to the billing institution. The fee payment method according to any one of the above.

Images