Payment application device, and program
The payment application device addresses the burden of unavailable payment methods in invoice management systems by allowing business operators to select alternative payment means, thereby reducing operational effort and simplifying the payment process.
Patent Information
- Application Number
- JP2023146133
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-09-08
- Publication Date
- 2025-03-21
AI Technical Summary
Existing invoice management systems burden business operators with payment processing, especially when designated payment methods are unavailable, leading to increased operational effort.
A payment application device that includes an authorization request unit, an authorization result acquisition unit, a selection unit, and an application unit, which allows business operators to select alternative payment means from a variety of preset types, even if the initial payment method is unavailable.
The solution reduces the payment burden on business operators by enabling them to use alternative payment methods, thereby simplifying the payment process and minimizing the operational effort required for handling multiple payment accounts.
Smart Images

Figure 2025039220000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a payment application device and a program. [Background technology]
[0002] Businesses provide their products and services to consumers by forming business transactions with a large number of diverse business partners. Invoice management systems that send and receive invoices for such business transactions online are known. Patent Document 1 describes an invoice management system that electronically manages invoices. This technology makes it possible to accurately process payments based on a large number of invoices in a short period of time. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] WO 2017 / 73102 Summary of the Invention [Problem to be solved by the invention]
[0004] However, such a system is premised on the premise that payment is made with the payment means presented by the system. If payment can be made with the payment means presented by the system, the business can reduce the burden of paying the invoice. If payment cannot be made with the payment means presented by the system, the business cannot reduce the burden of paying the invoice.
[0005] The present invention has been made in consideration of these points, and one of its objects is to reduce the burden on businesses in terms of payment even when payment cannot be made using the specified payment method. [Means for solving the problem]
[0006] [1] One aspect of the present invention is a payment application device comprising: an authorization request unit that transmits an authorization request for a credit card, which is one of the payment methods offered by a business operator; an authorization result acquisition unit that acquires the result of authorization for the credit card for which authorization has been requested; a selection unit that, when the result of authorization for the credit card indicates that the credit card cannot be used, selects at least one payment method from a plurality of types of payment methods that have been preset; and an application unit that applies for payment using the payment method selected by the selection unit.
[0007] [2] Moreover, one aspect of the present invention is a payment application device as described in [1], further comprising a payment means presentation unit that presents the payment means selected by the selection unit to the business operator, and a payment means acquisition unit that acquires the payment means selected by the business operator, wherein the application unit applies for payment using the payment means acquired by the payment means acquisition unit.
[0008] [3] Furthermore, one aspect of the present invention is a payment application device as described in [1] or [2], wherein the application unit applies for payment using the payment means that has been selected by the business operator if the result of authorization is that the payment means is unavailable.
[0009] [4] Moreover, one aspect of the present invention is a payment application device as described in any one of [1] to [3], wherein, when the application unit is unable to apply for payment using the payment means selected by the selection unit, the selection unit selects a payment means other than the payment means for which the application unit was unable to apply for payment.
[0010] [5] Furthermore, in one aspect of the present invention, in the presentation device described in [1] to [4], when the business operator has a plurality of credit cards, the selection unit determines, based on the content of the authorization result, whether payment is possible with a credit card other than the unavailable credit card, and selects the payment method.
[0011] [6] Moreover, in one aspect of the present invention, in a payment application device as described in any of [1] to [5], the device further comprises a claim information acquisition unit which acquires claim information relating to the amount of a confirmed claim, which is a claim that is confirmed to be paid to the business by the business's accounts receivable, a debt information acquisition unit which acquires debt information relating to the amount of accounts payable borne by the business, and a calculation unit which calculates, based on the amount of the confirmed claim, the amount of a future claim, which is a claim that the business is expected to hold in the future, in a case where there is a possibility that the confirmed claim will arise repeatedly, and the preset payment means includes a payment means which makes a payment according to the amount of the confirmed claim or the amount of the future claim, out of the amount of the accounts payable acquired by the debt information acquisition unit.
[0012] [7] Another aspect of the present invention is a program that causes a computer to execute an authorization request step of sending an authorization request for a credit card, which is one of the payment methods of a business operator; an authorization result acquisition step of acquiring an authorization result for the credit card for which authorization has been requested; a selection step of selecting at least one payment method from a plurality of types of payment methods that have been preset, if the authorization result for the credit card indicates that the credit card cannot be used; and an application step of applying for payment with the payment method selected in the selection step. Effect of the Invention
[0013] According to the present invention, even if payment cannot be made using the designated payment method, the burden on the business operator for payment can be reduced. [Brief description of the drawings]
[0014] [Figure 1] FIG. 1 is a first diagram for explaining an example of a service provided by a service provider. [Diagram 2]4 is a flowchart for explaining an example of a flow of payment made by a business operator to a service provider in the first embodiment. [Diagram 3] FIG. 1 is a block diagram of a payment system according to a first embodiment. [Figure 4] 2 is a functional configuration diagram for explaining an example of the functional configuration of the payment application device according to the first embodiment. FIG. [Diagram 5] 4 is a flowchart illustrating an example of a flow of payment by the payment application device of the first embodiment. [Figure 6] 11 is a flowchart for explaining an example of a flow of payment by another credit card according to the first embodiment. [Figure 7] 1 is a flowchart illustrating an example of a flow of payment by bank transfer according to the first embodiment. [Figure 8] 1 is a flowchart for explaining an example of a flow of payment by account transfer according to the first embodiment. [Figure 9] 1 is a flowchart for explaining an example of a flow of payment through a designated account in the first embodiment. [Figure 10] 11 is a flowchart for explaining an example of a flow of payment made by a business operator to a service provider in the second embodiment. [Figure 11] FIG. 11 is a functional configuration diagram for explaining an example of the functional configuration of a payment application device according to a second embodiment. [Figure 12] FIG. 2 is a second diagram for explaining an example of a service provided by a service provider. [Figure 13] 13 is a flowchart for explaining an example of a flow of payment made by a business operator to a service provider in the third embodiment. [Figure 14] FIG. 11 is a functional configuration diagram for explaining an example of the functional configuration of a payment application device according to a third embodiment. [Figure 15] 13 is a flowchart illustrating an example of a flow of payment by the payment application device of the third embodiment. [Figure 16]13 is a flowchart for explaining an example of a flow of payment by claim according to the third embodiment. [Figure 17] 13 is a flowchart for explaining an example of a flow of payment made by a business operator to a service provider in the fourth embodiment. [Figure 18] FIG. 13 is a functional configuration diagram for explaining an example of the functional configuration of a payment application device according to a fourth embodiment. [Figure 19] FIG. 1 is a diagram for explaining an example of a typical commercial transaction between a business operator and a business partner of the business operator. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0015] The payment application device and program according to the present embodiment will be described in detail below with reference to the accompanying drawings, showing preferred embodiments. Note that the present embodiment is not limited to these embodiments, and includes various modifications or improvements. In other words, the components described below include those that a person skilled in the art can easily imagine, and those that are substantially the same, and the components described below can be combined as appropriate. Furthermore, the present embodiment allows for various omissions, substitutions, or modifications of the components without departing from the spirit of the present invention.
[0016] [overview] First, an example of an aspect of a payment-on-delivery service provided to a business operator will be described with reference to FIG. 19 and FIG.
[0017] FIG. 19 is a diagram for explaining an example of a typical mode of commercial transactions between a business operator and the business operator's business partners. Generally, a business operator 93 provides products or services to a consumer (account payable customer 94) by conducting commercial transactions with multiple business partners (account payable customers 92). Account payable customers 92-1 to 92-N shown in the figure are examples of multiple account payable customers 92. Hereinafter, when there is no need to distinguish between account payable customers 92-1 to 92-N, they may be simply referred to as account payable customers 92. Specifically, the business operator 93 purchases goods P or receives services S from multiple account payable customers 92. The business operator 93 purchases goods P or receives services S from account payable customers 94 based on the purchased goods P or the provided services S. In this case, the account payable customer 94 purchases a product P or provides a service S to the business 93. The account payable customer 94 pays the business 93 money C on a specified payment date or immediately in exchange for the provided product P or service S. The business 93 uses the money C paid by the account payable customer 94 to pay the money C to each of the multiple account payable customers 92 by a specified payment due date (for example, the end of the following month) using the money C paid by the account payable customer 94. When the payment method and payment due date differ depending on the account payable customer 92, the business 93 needs to accurately deposit the money for a large number of invoices by the payment due date of each invoice. For this reason, the business 93 has had to make considerable efforts to make payments to each account payable customer 92. By using the advance payment service 1 described below, the business 93 can reduce the efforts required for making payments to each account payable customer 92.
[0018] FIG. 1 is a first diagram for explaining an example of a service provided by a service provider. With reference to the figure, an example of an advance payment service 1 provided by a service provider 5 will be explained. Accounts payable to customers 2-1 to 2-N shown in the figure are examples of multiple accounts payable to customers 2. The service provider 5 provides an advance payment service 1 to a business operator 3, which reduces the burden of making payments to the accounts payable to customers 2. Specifically, the service provider 5 first advances payments that the business operator 3 needs to make to some or all of the accounts payable to customers 2 (hereinafter, sometimes referred to as target accounts payable to customers 2) selected by the business operator 3 as targets for the advance payment service 1. Next, the service provider 5 makes a lump-sum invoice to the business operator 3 for the amount of the advance payment. By receiving the advance payment service 1, the business operator 3 can make lump-sum payments to the service provider 5 that were previously made separately to each account payable to the customer 2. Thus, by making lump-sum payments, the business operator 3 can reduce the burden of making payments to each account payable to customers 2. Furthermore, according to the advance payment service 1, since the service provider 5 has already made the payment to the payable party 2 (advance payment), it is possible to prevent the business operator 3 from missing the payment due date to the payable party 2 due to carelessness or the like, which would result in the business operator 3 losing credibility with the payable party 2.
[0019] [Embodiment 1] Next, an example of a first embodiment of the payment application device 30 used in the advance payment service 1 will be described with reference to FIGS.
[0020] 2 is a flowchart for explaining an example of the flow of payment made by a business operator to a service provider in embodiment 1. The payment method of the business operator 3 will be explained with reference to the same figure.
[0021] To receive the advance payment service 1, the business operator 3 selects a payment method for the service provider 5 (step S101). In FIG. 2, selectable payment methods are exemplified as "credit card" and "bank transfer," which does not necessarily require prior procedures such as applying for a card or opening an account. If the business operator 3 selects payment by bank transfer (step S101; bank transfer), the business operator applies for payment by bank transfer. Note that to receive the advance payment service 1, the business operator 3 may select payment by "direct debit," "designated account," etc., which will be described later, as a payment method other than bank transfer.
[0022] If the business operator 3 selects payment by "credit card" (step S101; credit card), the service provider 5 (or the payment application device 30 described later) executes authorization for the credit card for which the business operator 3 has applied to make payment (step S102). That is, the service provider 5 inquires of the card company that issues the credit card whether payment can be made using the credit card for which the business operator 3 has applied to make payment. If there is no problem with the result of the authorization (step S102; no problem), the service provider 5 makes the payment for the amount paid in advance using the credit card.
[0023] If there is a problem with the result of authorization (step S102; problem), the service provider 5 confirms with the business 3 whether to make the payment with another payment means (step S103). If the business 3 makes the payment with another payment means (step S103; Yes), the service provider 5 acquires the payment means preset by the business 3 (step S104). The service provider 5 presents the selected payment means to the business 3 from the payment means preset. The service provider 5 may present the business 3 with a payment means that is not preset, thereby encouraging the business 3 to make the payment with the new payment means. The service provider 5 makes the payment with the payment means selected by the business 3 (step S105). The service provider 5 may store the payment means selected by the business 3 as the payment means (default payment means) to be selected without confirming with the business 3 from the next time onwards.
[0024] If the business operator 3 does not make the payment by another payment means (step S103; No), the service provider 5 may present to the business operator 3 content recommending payment by another payment means.
[0025] It should be noted that the service provider 5 does not necessarily need to confirm with the business operator 3 whether the payment will be made by another payment means (step S103). At this time, if the business operator 3 does not select any payment means, the service provider 5 determines that the business operator 3 will not make the payment by another payment means. By presenting another payment means without confirming whether to make the payment, the business operator 3 can consider whether to select another payment means after confirming the other payment means.
[0026] 3 and 4, an example of a payment application device that executes the processes from step S102 to step S105 shown in Fig. 2 will be described. The payment application device executes a process when a business operator 3 applies for payment by credit card and the applied credit card cannot be used.
[0027] FIG. 3 is a block diagram of a system according to the first embodiment. An example of a system 10 according to the first embodiment will be described with reference to the figure. The system 10 includes a plurality of terminal devices 20 and a payment application device 30. A terminal device 20-1 and a terminal device 20-N shown in the figure are examples of the plurality of terminal devices 20. The plurality of terminal devices 20 and the payment application device 30 are connected to each other via a network NW. The network NW is a predetermined communication network configured using lines. An example of the network NW is the Internet. The predetermined communication network is an open network, and devices connected to the communication network can communicate with each other using a predetermined protocol. In the Internet layer of the communication network, communication is performed using the Internet Protocol (IP) or the like.
[0028] The terminal device 20 is operated by a business operator 3. The business operator 3 operates the terminal device 20 to receive the advance payment service 1 for the target account payable customer 2. The business operator 3 may select or preset a payment method for the service provider 5 by operating the terminal device 20.
[0029] The terminal device 20 acquires application operation information OI and setting information PI. The application operation information OI is information on the application for payment by credit card based on the operation of the business operator 3. The application operation information OI includes, for example, information on the target payable party 2 selected by the business operator 3 as the target of the on-replacement service 1, credit card information, etc. The setting information PI is information on a payment means for the service provider 5 that is preset by the business operator 3 and is a payment means other than the credit card to which the business operator 3 applies for payment. The setting information PI may include, for example, information on a credit card other than the credit card to which the payment is applied, information on an account owned by the business operator 3, or information on a designated account to be used for payment to the service provider 5. When there are multiple credit cards other than the credit card to which the payment is applied, the setting information PI may include, for example, information on the order in which the multiple credit cards are applied for payment. The terminal device 20 transmits the application operation information OI and the setting information PI to the payment application device 30 via the network NW. The terminal device 20 may be, for example, a personal computer, a tablet computer, a smartphone, or other device.
[0030] The payment application device 30 acquires application operation information OI and setting information PI from the terminal device 20. When the application operation information OI is acquired, the payment application device 30 requests the card company to execute authorization based on the credit card information included in the application operation information OI. That is, the payment application device 30 inquires of the card company whether the payment can be made by the credit card applied for by the business 3. If there is a problem with the result of the authorization, the payment application device 30 transmits selection information MI to the terminal device 20 that transmitted the application operation information OI and setting information PI. The selection information MI is information on the payment means selected based on the setting information PI. The selection information MI may include, for example, information on the payment means such as "a credit card different from the unusable credit card," "bank transfer," and "account transfer." The payment application device 30 presents the business 3 with other payment means candidates so that the business 3 can receive the advance payment service 1 even if the credit card applied for by the business 3 is unusable.
[0031] The selection information MI may include information regarding a payment means selected by the payment application device 30 from among payment means not set by the business operator 3. In other words, the payment application device 30 may prompt the business operator 3 to make a payment using a payment means not set by the business operator 3. Even if the business operator 3 has not set another payment means, the business operator 3 can receive the advance payment service 1 by the payment application device 30 presenting to the business operator 3 a payment means not included in the setting information PI.
[0032] The terminal device 20 acquires selection information MI from the payment application device 30. The terminal device 20 presents the acquired selection information MI to the business operator 3. That is, the terminal device 20 presents other payment means to the business operator 3. If the business operator 3 selects other payment means, the terminal device 20 transmits selection means information SMI to the payment application device 30. The selection means information SMI is information about the payment means selected by the business operator 3 from the selection information MI. The selection means information SMI may include, for example, credit card information, information about an account held by the business operator 3, or information indicating that payment is being applied for by bank transfer.
[0033] The payment application device 30 acquires the selection means information SMI from the terminal device 20. The payment application device 30 applies for payment based on the acquired selection means information SMI, i.e., by the payment means selected by the business operator 3. The payment application device 30 transmits application result information PPI to the terminal device 20 that transmitted the selection means information SMI. The application result information PPI is information on the result of the application for payment by the payment means selected by the business operator 3. The application result information PPI may include, for example, information on whether the credit card selected by the business operator 3 can be used, or may include information on the due date and amount to be debited from the account to which the business operator 3 has applied for payment. The application result information PPI may be, for example, information necessary for a transfer to the bank of the service provider 5.
[0034] FIG. 4 is a functional configuration diagram for explaining an example of the functional configuration of the payment application device according to the first embodiment. With reference to the same figure, an example of the payment application device 30 according to the first embodiment will be explained. The payment application device 30 includes an application acceptance unit 31, an authorization request unit 32, a set means acquisition unit 33, an authorization result acquisition unit 34, a selection unit 35, a payment means presentation unit 36, a payment means acquisition unit 37, an application unit 38, and an application result presentation unit 39. Each of these functional units is realized, for example, by using a computer and software. Also, each functional unit may be realized by using an electronic circuit as necessary. Furthermore, each functional unit does not have to be included in a single device, and the payment application device 30 may be configured by a plurality of devices.
[0035] The application acceptance unit 31 acquires the application operation information OI transmitted from the terminal device 20. That is, the application acceptance unit 31 acquires information regarding the business operator 3 applying for payment by credit card. The application acceptance unit 31 transmits the application operation information OI to the authorization request unit 32.
[0036] The authorization request unit 32 acquires application operation information OI from the application acceptance unit 31. The authorization request unit 32 requests the card company to execute authorization based on the credit card information included in the acquired application operation information OI. That is, the authorization request unit 32 inquires of the card company whether the payment can be made using the credit card for which the business entity 3 has applied for payment.
[0037] The authorization result acquisition unit 34 acquires authorization result information AI from the card company. That is, the authorization result acquisition unit 34 acquires the result of authorization of the credit card for which the business entity 3 has applied for payment. If the result of authorization is that the credit card cannot be used, the authorization result acquisition unit 34 transmits the authorization result information AI to the selection unit 35.
[0038] The set means acquisition unit 33 acquires the setting information PI from the terminal device 20. That is, the set means acquisition unit 33 acquires a payment means that is set in advance by the business operator 3 and is other than a credit card for which the business operator 3 has applied for payment. The set means acquisition unit 33 transmits the acquired setting information PI to the selection unit 35.
[0039] The selection unit 35 acquires the setting information PI from the set means acquisition unit 33. Furthermore, the selection unit 35 acquires the authorization result information AI from the authorization result acquisition unit 34. The selection unit 35 selects a candidate payment means other than the credit card that is not available according to the authorization result information AI from the setting information PI. The selection unit 35 transmits the selection information MI to the payment means presentation unit 36. The selection performed by the selection unit 35 is to select a payment means suited to the business operator 3. For example, the selection unit 35 may select all of the payment means set in advance by the business operator 3 as candidates for the payment means. For example, the selection unit 35 may select some of the payment means set by the business operator 3 that have a high priority to present to the business operator 3 as candidates for the payment means. Here, examples of the payment means with a high priority include "payment by another credit card" and "payment by bank transfer". Since the business operator 3 first applied for payment by credit card, it should want to make the payment using a credit card. According to "payment by another credit card", the business operator 3 can apply for payment using a credit card. Furthermore, with "payment by bank transfer," the business operator 3 is not required to take any prior steps for payment (for example, opening an account), and can make payment reliably.
[0040] The selection unit 35 may determine whether to select a credit card other than the credit card applied for payment by the business 3 as a candidate for the payment method based on the contents of the credit card authorization result. If the credit card is not usable because the business 3 has low credit rating, the authorization result is highly likely to be unusable for other credit cards as well. In this case, the selection unit 35 may determine that if a certain credit card is not usable, the authorization result is also highly likely to be unusable for other credit cards that are not unusable, and select a payment method that does not use a credit card. Here, the contents of the authorization result that makes a credit card unusable due to low credit rating include, for example, "exceeding the credit limit," "there is a default in payment," and "the use of the card is judged to be problematic at the time of ongoing credit check." In addition, if the authorization result is a content attributable to a certain credit card, such as "the credit card has expired," the selection unit 35 may select a payment method to be presented to the business 3, including a payment method using other credit cards that are not unusable.
[0041] The payment means presentation unit 36 acquires the selection information MI from the selection unit 35. The payment means presentation unit 36 transmits the acquired selection information MI to the terminal device 20. The terminal device 20 presents the selection information MI transmitted from the payment means presentation unit 36 to the business operator 3. That is, the payment means presentation unit 36 presents the payment means selected by the selection unit 35 to the business operator 3 via the terminal device 20. The payment means presentation unit 36 may present a plurality of payment means to the business operator 3 together. When the payment means presentation unit 36 presents a plurality of payment means to the business operator 3 together, the business operator 3 can select any payment means from among the plurality of payment means candidates. The payment means presentation unit 36 may also present a plurality of payment means to the business operator 3 in order (for example, one by one in order of priority). When the payment means presentation unit 36 presents a plurality of payment means to the business operator 3 in order, a payment means suitable for the business operator 3 can be presented early.
[0042] The payment method acquisition unit 37 acquires the selected method information SMI transmitted from the terminal device 20. That is, the payment method acquisition unit 37 acquires information on the payment method selected by the business operator 3 from among the payment methods selected by the selection unit 35. The payment method acquisition unit 37 transmits the acquired selected method information SMI to the application unit 38.
[0043] The application unit 38 acquires the selected means information SMI from the payment means acquisition unit 37. The application unit 38 applies for payment of the amount advanced by the service provider 5, using the payment means included in the acquired selected means information SMI. The application unit 38 transmits the application result information PPI to the application result presentation unit 39.
[0044] The application result presentation unit 39 acquires the application result information PPI from the application unit 38. The application result presentation unit 39 transmits the acquired application result information PPI to the terminal device 20. The terminal device 20 transmits the acquired application result information PPI to the business operator 3. In other words, the application result presentation unit 39 presents to the business operator 3, via the terminal device 20, the result of whether or not the payment application was successful using the selected payment means, and information necessary for payment (for example, information on the bank account to which the payment is to be transferred).
[0045] In this embodiment, an example has been described in which there is a problem with the result of authorization in the payment application device 30. In contrast, if there is no problem with the result of authorization of the credit card for which the business entity 3 has applied for payment, the authorization result acquisition unit 34 transmits authorization result information AI to the application unit 38 (not shown). The application unit 38 applies for payment of the amount paid in advance by the service provider 5, using the credit card for which the business entity 3 has applied for payment.
[0046] In this embodiment, the selection unit 35 selects a candidate payment method from the setting information PI that is different from the credit card that is not available according to the authorization result information AI. However, this embodiment is not limited to this example, and the selection unit 35 does not necessarily need to select a candidate payment method from the setting information PI. The selection unit 35 may select a candidate payment method from among payment methods that are not set in advance as a relief measure for the business operator 3 that has not set a payment method other than a credit card in advance. If the business operator 3 has not set a payment method other than a credit card in advance, if the result of the authorization of the credit card is not available, the business operator 3 will not be able to apply for payment of the amount paid in advance by the service provider 5. If the selection unit 35 can select a candidate payment method from among payment methods that are not set, the business operator 3 can apply for payment of the amount paid in advance by the service provider 5 using another payment method.
[0047] In this embodiment, an example is shown in which the application unit 38 applies for payment of the amount paid in advance by the service provider 5 using a payment means selected by the business 3. However, this embodiment is not limited to this example. The application unit 38 may apply for payment of the amount paid in advance by the service provider 5 using a payment means that the business 3 has previously selected. For example, if the credit card applied for payment by the business 3 is unavailable and bank transfer has been selected as another payment means, the application unit 38 may apply for payment by bank transfer. When applying for payment using a payment means that has been selected in the past, the payment application device 30 does not necessarily need to present candidate payment means to the business 3 using the payment means presenting unit 36. By applying for payment using a payment means that the business 3 has previously selected without presenting candidate payment means to the business 3, the business 3 does not need to select a payment means every time there is a problem with the authorization of the credit card, thereby reducing the effort required for operation.
[0048] In this embodiment, an example is shown in which the business operator 3 selects a payment means from among the payment means selected by the selection unit 35. However, this embodiment is not limited to this example, and the business operator 3 does not have to select a payment means from among the payment means selected by the selection unit 35. If a payment means is not selected from among the payment means selected by the selection unit 35, the payment means acquisition unit 37 acquires information indicating that no payment means was selected as the selection means information SMI. The payment means acquisition unit 37 may transmit the acquired selection means information SMI to the selection unit 35 (not shown). The selection unit 35 reselects a payment means different from the payment means presented to the business operator 3 and transmits it to the payment means presentation unit 36. The payment means presentation unit 36 presents the reselected selection information MI to the business operator 3 via the terminal device 20. By the selection unit 35 reselecting a payment means, the payment application device 30 can present a payment means that is more in line with the intention of the business operator 3.
[0049] Next, the flow of processing by the payment application device will be described with reference to FIGS.
[0050] FIG. 5 is a flowchart for explaining an example of the flow of payment by the payment application device according to the first embodiment. With reference to the same figure, an example of the flow of payment by the payment application device 30 will be explained. FIG. 5 shows an example in which the payment application device 30 presents the payment methods to the business operator 3 in the order of "other credit card", "bank transfer", "account transfer", and "payment via designated account". Note that the payment application device 30 does not necessarily have to present the payment methods to the business operator 3 in the same order as in FIG. 5. Furthermore, the payment application device 30 may present only one of the payment methods to the business operator 3, "payment via other credit card", "payment via bank transfer", "payment via account transfer", and "payment via designated account".
[0051] The payment application device 30 presents the business operator 3 with a payment method using another credit card. In response, the business operator 3 selects whether or not to apply for payment using another credit card (step S310). If the business operator 3 selects to apply for payment using another credit card (step S310; Yes), the payment application device 30 applies for payment using a credit card other than the unusable credit card (step S350).
[0052] If the business entity 3 does not select to apply for payment by another credit card (step S310; No), the payment application device 30 presents the business entity 3 with a payment method by bank transfer. In response, the business entity 3 selects whether or not to apply for payment by bank transfer (step S320). If the business entity 3 selects to apply for payment by bank transfer (step S320; Yes), the payment application device 30 applies for payment by bank transfer (step S360).
[0053] If the business operator 3 does not select to apply for payment by bank transfer (step S320; No), the payment application device 30 presents the business operator 3 with a payment method by account transfer (account withdrawal). In response, the business operator 3 selects whether or not to apply for payment by account transfer (step S330). If the business operator 3 selects to apply for payment by account transfer (step S330; Yes), the payment application device 30 applies for payment by account transfer (step S370).
[0054] If the business operator 3 does not select to apply for payment by account transfer (step S330; No), the payment application device 30 presents the business operator 3 with a payment method via a designated account. In response, the business operator 3 selects whether or not to apply for payment via a designated account (step S340). If the business operator 3 selects to apply for payment via a designated account (step S340; Yes), the payment application device 30 applies for payment via a designated account (step S380).
[0055] If the business operator 3 does not choose to apply for payment via a designated account (step S340; No), i.e., if the business operator 3 does not select any payment method, the business operator 3 may not be able to receive the advance payment service 1 provided by the service provider 5.
[0056] In the flowchart shown in Fig. 5, an example is shown in which the payment application device 30 presents the payment means one by one in sequence to the business operator 3. However, this embodiment is not limited to this example. For example, the payment application device 30 may present the selected multiple payment means to the business operator 3 all at once. When multiple payment means are presented all at once by the payment application device 30, the business operator 3 may select one of the presented payment means that suits the business operator 3.
[0057] 6 is a flowchart for explaining an example of the flow of payment by another credit card according to embodiment 1. With reference to the drawing, an example of the flow of payment by another credit card (step S350) will be described in detail.
[0058] If the business operator 3 selects to apply for payment with another credit card (step S310; Yes), the payment application device 30 requests the card company to execute authorization for the credit card selected based on the setting information PI (step S351). That is, the payment application device 30 requests the card company to execute authorization for the credit card set first in the order of credit card payment applications preset by the business operator 3. Note that if the order of credit card payment applications is not preset, the payment application device 30 may select the order of credit card payment applications.
[0059] If there is no problem with the authorization result (step S351; no problem), the payment application device 30 applies for payment for the amount paid in advance by the service provider 5 using the credit card for which there was no problem with the authorization result (step S352).
[0060] If there is a problem with the result of the authorization (step S351; problem), the business entity 3 selects whether or not to apply for payment using a card that has not been authorized (step S353). That is, the business entity 3 selects whether to apply for payment again using a credit card that is second or later in the order of credit card payment applications set in advance. When applying for payment using a second or later credit card (step S353; apply), the business entity 3 requests the card company to execute authorization for the credit card for which payment is applied (step S351). Note that the payment application device 30 may request the business entity 3 to execute authorization for the second or later credit card without confirming whether payment is applied using the second or later credit card. By the payment application device 30 not confirming, the business entity 3 does not need to select whether to execute authorization for another credit card every time there is a problem with the authorization of a credit card, which reduces the effort of the operation.
[0061] If payment is not applied for using the second or subsequent credit cards (step S353; not applied), payment application device 30 may present other payment means to business operator 3 (step S354). Payment application device 30 may, for example, present to business operator 3 a payment means by bank transfer.
[0062] Fig. 7 is a flow chart for explaining an example of the flow of payment by bank transfer according to embodiment 1. With reference to the same figure, an example of the flow of payment by bank transfer (step S360) will be explained in detail. Note that payment is performed in the same flow in steps S107 and S360.
[0063] If the business operator 3 selects to apply for payment by bank transfer (step S320; Yes), the payment application device 30 applies for payment by bank transfer for the amount advanced by the service provider 5 (step S361). The payment application device 30 presents to the business operator 3 information (e.g., an invoice) required for the business operator 3 to transfer money to the destination bank account (step S362). Information required for transfer includes, for example, information identifying the destination bank account, information regarding the transfer due date and the amount to be transferred. Information identifying the bank account includes, for example, the bank name, branch name, account type, account number, account holder, etc. The business operator 3 transfers money to the destination bank account by a specified payment due date (e.g., the end of the following month) (step S363).
[0064] 8 is a flowchart for explaining an example of the flow of payment by account transfer according to embodiment 1. With reference to this figure, an example of the flow of payment by account transfer (step S370) will be described in detail.
[0065] If the business operator 3 selects to apply for payment by direct debit (step S330; Yes), the payment application device 30 applies for payment by direct debit for the amount paid in advance by the service provider 5 (step S371). The payment application device 30 presents the business operator 3 with information on the account for which the direct debit has been applied, the transfer date, the transfer amount, etc., based on information on the account owned by the business operator 3 contained in the setting information PI. The service provider 5 debits the account for which the direct debit has been applied when the direct debit is applied or on a specified transfer date (for example, the end of the following month) (step S372).
[0066] Fig. 9 is a flowchart for explaining an example of the flow of payment through a designated account according to embodiment 1. With reference to the figure, an example of the flow of payment through a designated account (step S380) will be described in detail. Note that the designated account may be, for example, an account opened by the business operator 3 for the purpose of making a payment to the service provider 5, or an account designated by the business operator 3 or the service provider 5. In other words, the designated account may be used for purposes other than the payment of the amount paid in advance by the service provider 5.
[0067] If the business entity 3 selects to apply for payment via a designated account (step S340; Yes), the payment application device 30 applies for payment via a designated account for the amount paid in advance by the service provider 5 (step S381). The payment application device 30 presents the business entity 3 with the withdrawal due date, the withdrawal amount, and the like, based on the information on the account owned by the business entity 3, which is included in the setting information PI. The business entity 3 deposits (charges) the designated account by the withdrawal due date (for example, the end of the following month) (step S382). The service provider 5 withdraws from the designated account on a prescribed withdrawal due date (for example, the end of the following month) (step S381). If the business entity 3 has not opened a designated account in advance, the payment application device 30 may urge the business entity 3 to open a designated account. If the business entity 3 has not opened or set up a designated account, the payment application device 30 may urge the business entity 3 to set up a designated account.
[0068] [Summary of embodiment 1] According to the above-mentioned embodiment, the payment application device 30 includes an authorization request unit 32 that transmits an authorization request for a credit card, which is one of the payment means of the business entity 3, an authorization result acquisition unit 34 that acquires the result of the authorization for the credit card for which the authorization has been requested, a selection unit 35 that selects at least one payment means from among a plurality of types of payment means set in advance when the result of the authorization for the credit card indicates that the credit card cannot be used, and an application unit 38 that applies for payment with the payment means selected by the selection unit 35. According to this embodiment, when the credit card cannot be used, the payment application device 30 applies for payment with another payment means so that the business entity 3 can receive the advance payment service 1. If the business entity 3 can receive the advance payment service 1 with another payment means even if the credit card cannot be used, the business entity 3 does not need to make separate payments to multiple business entities. Therefore, according to the payment application device 30 according to this embodiment, even if the payment cannot be made with the specified payment means, the burden on the business entity for payment can be reduced by presenting another payment means.
[0069] Furthermore, according to the embodiment described above, the payment application device 30 further includes a payment means presenting unit 36 that presents the payment means selected by the selection unit 35 to the business operator 3, and a payment means acquiring unit 37 that acquires the payment means selected by the business operator 3, and the application unit 38 applies for payment using the payment means acquired by the payment means acquiring unit 37. According to this embodiment, when a credit card cannot be used, the payment application device 30 presents other payment means to the business operator 3 so that the business operator 3 can receive the advance payment service 1. According to the payment application device 30 of this embodiment, by presenting other payment means, the business operator 3 can select a payment means that suits him / her and receive the advance payment service 1.
[0070] Also, according to the above-described embodiment, in the payment application device 30, when the result of authorization is unusable, the application unit 38 applies for payment using a payment means that the business operator 3 has previously selected. When there is a problem with the result of authorization, the payment application device 30 applies for payment using a payment means that the business operator 3 has previously selected. In other words, the payment application device 30 does not require the business operator 3 to select a payment means each time, but applies for payment using a payment means that has been selected. According to this embodiment, the business operator 3 is relieved of the trouble of selecting a payment means to apply for payment each time there is a problem with the result of credit card authorization. Therefore, the payment application device 30 according to this embodiment can reduce the burden on the business operator in terms of payment.
[0071] According to the above-described embodiment, in the payment application device, when the business entity 3 has a plurality of credit cards, the application unit 38 determines whether payment is possible with a credit card other than the unavailable credit card based on the contents of the authorization result, and selects the payment method. The business entity 3 first selects a credit card as the payment method. Therefore, it is highly likely that the business entity 3 wants to make payment to the service provider 5 with a credit card in the on-the-fly service 1. According to this embodiment, when one of the credit cards owned by the business entity 3 is unavailable, the payment application device 30 applies for payment with another credit card owned by the business entity 3 before applying for payment with another payment method. Therefore, according to the payment application device 30 of this embodiment, the business entity 3 can apply for payment with a payment method suitable for itself by applying for payment with another credit card owned by the business entity 3.
[0072] [Embodiment 2] Next, an example of payment application device 30A, which is payment application device 30 according to embodiment 2, will be described with reference to FIGS.
[0073] FIG. 10 is a flowchart for explaining an example of the flow of payment made by a business to a service provider in the second embodiment. When payment cannot be made by credit card, the payment application device 30 according to the first embodiment applies for payment by another payment means selected by the business 3. A payment application device 30A (not shown) according to the second embodiment is similar to the payment application device 30 in that when payment cannot be made by credit card, payment is made by another payment means. The payment application device 30A differs from the payment application device 30 in that the business 3 does not need to select a payment means from the presented payment means. Note that the same reference numerals may be used to denote matters already explained in the first embodiment, and explanations may be omitted.
[0074] If there is a problem with the authorization result (step S102; problem), 30A acquires a payment means preset by the business 3 (step S104). The payment application device 30A selects a payment means based on the payment means preset by the business 3, and applies for payment with the selected payment means (step S105A).
[0075] Fig. 11 is a functional configuration diagram for explaining an example of the functional configuration of a payment application device according to embodiment 2. With reference to the diagram, an example of the functional configuration of a payment application device 30A according to embodiment 2 will be described. Payment application device 30A differs from payment application device 30 in that it does not have a payment means presenting unit 36 and a payment means acquiring unit 37 as components.
[0076] The selection unit 35 acquires the setting information PI from the set means acquisition unit 33. Furthermore, the selection unit 35 acquires the authorization result information AI from the authorization result acquisition unit 34. The selection unit 35 selects a payment means other than the unavailable credit card from the setting information PI. The selection unit 35 transmits the selection information MI to the application unit 38. The application unit 38 applies for payment based on the acquired selection information MI. That is, when the credit card is unavailable, the payment application device 30A applies for payment using a payment means other than the unavailable credit card without presenting any options to the business operator 3.
[0077] If payment cannot be applied for using the payment means selected by the application unit 38, the selection unit 35 may again select a payment means other than the payment means for which payment could not be applied for. Specifically, if payment using the selected credit card cannot be applied for, the selection unit 35 may select a credit card that has not yet been selected as the payment means, or may select a payment means that does not require a credit card, such as "bank transfer," "direct debit," or "payment via designated account."
[0078] [Summary of embodiment 2]
[0079] According to the above-described embodiment, in the payment application device 30A, when the application unit 38 is unable to apply for payment using the payment means selected by the selection unit 35, the selection unit 35 selects a payment means other than the payment means that could not be applied for payment. When the payment application device 30A is unable to apply for payment using a payment means preset or selected by the business operator 3, the payment application device 30A does not present a new option to the business operator 3, and applies for payment using the next preset candidate payment means or the payment means selected by the selection unit 35. In other words, according to this embodiment, the business operator 3 is relieved of the trouble of selecting a new payment means when the business operator 3 is unable to apply for payment using the selected payment means. Therefore, the payment application device 30A according to this embodiment can reduce the burden on the business operator in terms of payment.
[0080] [Embodiment 3] An example of a payment application device 30B which is a payment application device according to the third embodiment will be described with reference to FIGS. 12 to 16.
[0081] FIG. 12 is the second diagram for explaining an example of a service provided by a service provider. With reference to the diagram, an example of an advance payment service 1A provided by a service provider 5 will be explained. The advance payment service 1A is similar to the advance payment service 1 in that the service provider 5 advances the payment of the business entity 3 to the target account payable party 2. The advance payment service 1A differs from the advance payment service 1 in that the payment is made to the target account payable party 2 by using accounts receivable to the account payable party 4. Accounts payable parties 4-1 to 4-N shown in the diagram exemplify a plurality of account payable parties 4. Note that in the third embodiment, the items already explained in the first or second embodiment may be denoted by the same reference numerals and explanations thereof may be omitted.
[0082] In the advance payment service 1A, some or all of the accounts receivable customers 4 who receive the advance payment service 1 make payments to the business 3 to the service provider 5. The service provider 5 makes payments from some or all of the accounts receivable customers 4 to the business 3 (accounts receivable / credit of the business 3). Also, in the advance payment service 1A, as in the advance payment service 1, the service provider 5 advances payments that the business 3 needs to make to the target accounts payable customer 2. The service provider 5 makes a lump sum invoice to the business 3 for the amount advanced (accounts payable / credit of the business 3). The advance payment service 1A provides a payment method (hereinafter, sometimes referred to as payment by credit) whereby the accounts payable of the business 3 are paid with the accounts receivable of the business 3. In other words, in the advance payment service 1A, the business 3 can make payments to the target accounts payable customer 2 by offsetting the accounts payable advanced by the service provider 5 with the accounts receivable.
[0083] Figure 13 is a flowchart for explaining an example of the flow of payment made by a business to a service provider in embodiment 3. When payment cannot be made by credit card, payment application device 30 in embodiment 1 applies for payment by another payment means selected by business 3. Payment application device 30B (not shown) in embodiment 3 is similar to payment application device 30 in that when payment cannot be made by credit card, payment is made by another payment means. Payment application device 30B differs from payment application device 30 in that it provides a payment means for paying accounts payable to business 3 with accounts receivable from business 3.
[0084] If the business operator 3 makes the payment by another payment method (step S103; Yes), the service provider 5 acquires the amount (accounts receivable) that is confirmed to be paid to the business operator 3 from multiple accounts receivable 4 and that the service provider 5 has paid in advance (hereinafter, may be referred to as a confirmed claim), the amount (accounts payable) to be paid to the target account payable 2 and that the service provider 5 has paid in advance (hereinafter, may be referred to as a debt), and the payment method preset by the business operator 3 (step S104B). The service provider 5 presents the selected payment method from the preset payment methods to the business operator 3. The service provider 5 makes the payment by the payment method selected by the business operator 3 (step S105).
[0085] FIG. 14 is a functional configuration diagram for explaining an example of the functional configuration of a payment application device according to the third embodiment. With reference to the same figure, an example of a payment application device 30B according to the third embodiment will be described. The payment application device 30B differs from the payment application device 30 in that it further includes a claim information acquisition unit 41, a calculation unit 42, and a debt information acquisition unit 43. Each of these functional units is realized, for example, by using a computer and software. Also, each functional unit may be realized by using an electronic circuit as necessary. Furthermore, each functional unit does not have to be included in a single device, and the payment application device 30B may be configured by a plurality of devices.
[0086] The claim information acquisition unit 41 acquires the claim information FCI. The claim information FCI is information on the confirmed claim held by the business operator 3. The claim information FCI may include, for example, the amount of the confirmed claim, the number of days from the first day of the claim account (for example, the day after the closing date) to the day the claim information acquisition unit 41 acquires the claim information FCI (hereinafter, may be referred to as the basic number of days), the date when the confirmed claim occurred, and the like. The claim information FCI may include, for example, information on the confirmed claim held by the business operator 3 in the past, such as the amount of the confirmed claim held by the business operator 3 in one month, and the date when the confirmed claim occurred. The claim information acquisition unit 41 transmits the claim information FCI to the calculation unit 42. Note that, when the business operator 3 selects payment by the confirmed claim, the claim information acquisition unit 41 may transmit the claim information FCI to the application unit 38 without going through the calculation unit 42.
[0087] The calculation unit 42 acquires the claim information FCI from the claim information acquisition unit 41. Based on the claim information FCI, the calculation unit 42 calculates the amount of the claim (hereinafter, may be referred to as future claim) that the business operator 3 is expected to hold in the future by a predetermined means. For example, when there is a possibility that a confirmed claim held by the business operator 3 will arise repeatedly, the calculation unit 42 may calculate the value of the future claim by a predetermined calculation method based on the amount of the confirmed claim. The calculation unit 42 transmits the calculated claim information PCI including information regarding the calculated amount of the future claim to the application unit 38.
[0088] In addition, for example, when the amount of the currently held confirmed claim is similar to the amount of the confirmed claim held in the past (for example, the same month one year ago) when the basic number of days has passed, the calculation unit 42 may calculate the amount of the confirmed claim held for one month as the value of the future claim. There are cases where the confirmed claims of the business operator 3 are not repeatedly generated in the same amount between the first day of the account and the closing date, but are expected to be generated in large amounts around the closing date. When confirmed claims are expected to be generated in large amounts around the closing date, if the amount of the confirmed claim is multiplied by the value obtained by dividing 30 days by the basic number of days to calculate the future claim, an amount smaller than the amount of the actually expected future claim may be calculated. Therefore, if the amount of the confirmed claim held in the past when the basic number of days has passed from the first day of the account and the amount of the currently held confirmed claim are similar, the calculation unit 42 calculates the amount of the confirmed claim held in the past for one month as the value of the future claim. If the calculation means is based on the amount of the confirmed claim held in the past, it is possible to prevent the future claim from being calculated as being small, even when confirmed claims are expected to be generated in large amounts around the closing date. Therefore, by using a calculation method based on the amount of the confirmed claims held in the past, the business entity 3 can offer payment based on an amount close to the actual expected future claims.
[0089] When the payment means presentation unit 36 presents the means for calculating the future claim to the business operator 3, the calculation unit 42 may calculate the amount of the future claim by the calculation means selected by the business operator 3. By being able to select the calculation means, the business operator 3 can select the calculation means by which the amount of the future claim that the business operator 3 expects is calculated.
[0090] The debt information acquisition unit 43 acquires the debt information DI. The debt information DI is an amount (debt) that needs to be paid to the service provider 5, and the debt information DI may include, for example, information on the amount that needs to be paid to the service provider 5, the date when the debt occurred, etc. The debt information acquisition unit 43 transmits the acquired debt information DI to the application unit 38.
[0091] The application unit 38 acquires the selected means information SMI acquired from the payment means acquisition unit 37. When the selected means information SMI includes information on the means of payment by claim, the application unit 38 applies for payment by the determined claim or the future claim calculated by the calculation unit 42 for the debt borne by the business operator 3.
[0092] Figure 15 is a flow chart for explaining an example of the flow of payment by a payment application device according to embodiment 3. With reference to the same figure, an example of the flow of payment by payment application device 30B according to embodiment 3 will be explained. Payment application device 30B differs from payment application device 30 in that it presents a payment method called "payment by claim" to business operator 3. Figure 15 shows an example where payment application device 30B presents payment methods to business operator 3 in the order of "payment by other credit card," "payment by bank transfer," "payment by account transfer," "payment by designated account," and "payment by claim."
[0093] If the business entity 3 does not select to apply for payment via a designated account (step S340; No), the payment application device 30B presents the business entity 3 with a means of payment via bond. The business entity 3 selects whether or not to apply for payment via bond (step S410). If the business entity 3 selects payment via bond (step S410; Yes), the payment application device 30B applies for payment via bond (step S420).
[0094] If the business operator 3 does not select to apply for payment by credit (step S410; No), the payment application device 30B may present the business operator 3 with other payment methods.
[0095] It is not necessary for the payment application device 30B to present the payment means to the business operator 3 in the same order as in FIG. 15. The payment application device 30B may present the payment means to the business operator 3 in the following order: "payment by other credit card", "payment by claim", "payment by bank transfer", "payment by direct debit", and "payment by designated account". If the business operator 3 has not set a payment means in advance, the payment application device 30B can quickly present to the business operator 3 a payment means that requires less effort (e.g., transfer procedures and input of account information) to apply for payment by presenting "payment by claim" after "payment by other credit card". Thus, the payment application device 30B allows the business operator 3 to apply for a payment means by a simple means, even if a credit card is not available and another payment means has not been set in advance.
[0096] 16 is a flowchart for explaining an example of the flow of payment by claim according to embodiment 3. With reference to the same figure, an example of the flow of payment by claim (step S420) will be described in detail.
[0097] If the business operator 3 selects payment by credit (step S410; Yes), the payment application device 30B applies for payment by credit for the amount advanced by the service provider 5 (step S420). The payment application device 30B acquires the amount of the fixed credit currently held by the business operator 3 (step S422). The business operator 3 selects either a fixed credit or a future credit for the credit to be used for payment (step S423). If the business operator 3 selects payment by a fixed credit (step S423; fixed credit), the payment application device 30B applies for payment according to the amount of the fixed credit for the debt borne by the business operator 3 (step S424).
[0098] If the business operator 3 selects payment with future claims (step S423; future claims), the payment application device 30B calculates the amount of future claims that the business operator 3 is expected to hold in the future based on the amount of the confirmed claims (step S425). The payment application device 30B applies for payment according to the calculated amount of future claims for the debt borne by the business operator 3 (step S424).
[0099] [Summary of embodiment 3] According to the above-mentioned embodiment, the payment application device 30B further includes a claim information acquisition unit 41 that acquires claim information FCI on the amount of a confirmed claim, which is a claim that is confirmed to be paid from the account receivable customer 4 of the business to the business 3, a debt information acquisition unit 43 that acquires debt information DI on the amount of accounts payable borne by the business 3, and a calculation unit 42 that calculates the amount of a future claim, which is a claim that the business 3 is expected to hold in the future, based on the amount of the confirmed claim when there is a possibility that a confirmed claim will occur repeatedly. The preset payment means includes a payment means that makes a payment according to the amount of the confirmed claim or the amount of the future claim among the amount of accounts payable acquired by the debt information acquisition unit 43. If the business 3 selects another payment means, it may be troublesome to open an account or transfer to a bank. According to the payment means based on the confirmed claim or the calculated future claim, the business 3 can apply for payment without performing a new procedure. Therefore, according to the payment application device 30B according to this embodiment, the burden on the business for payment can be reduced.
[0100] According to the above-mentioned embodiment, the payment application device 30B includes a claim information acquisition unit 41 that acquires claim information FCI on the amount of a confirmed claim, which is a claim that is confirmed to be paid from the account receivable customer 4 of the business to the business 3, a debt information acquisition unit 43 that acquires debt information DI on the amount of accounts payable borne by the business 3, and an application unit 38 that applies for payment according to the amount of the confirmed claim acquired by the claim information acquisition unit 41 out of the amount of the accounts payable acquired by the debt information acquisition unit 43. If the business 3 selects another payment method, it may be necessary to open an account or transfer to a bank. According to the payment method based on a confirmed claim, the business 3 can apply for payment without having to carry out a new procedure. Therefore, according to the payment application device 30B according to this embodiment, the burden on the business for payment can be reduced. In addition, since the amount of receivables actually accrued to business operator 3 (accounts receivable) may be smaller than the amount of future receivables used for payment, business operator 3 may feel uneasy about payment instruments based on future receivables. If a payment instrument based on a fixed receivable is used, the amount can be used for payment up to the same amount as the fixed receivables currently held by business operator 3, so business operator 3 can apply for payment without feeling uneasy.
[0101] Furthermore, according to the above-described embodiment, the payment application device 30B further includes a calculation unit 42 that calculates the amount of a future claim, which is a claim that the business operator 3 is expected to hold in the future, based on the amount of the fixed claim when there is a possibility that a fixed claim will occur repeatedly, and the application unit 38 applies for payment according to the amount of the future claim calculated by the calculation unit 42 out of the amount of the accounts payable acquired by the debt information acquisition unit 43. According to this embodiment, the business operator 3 can apply for payment using a future claim that is expected to be held in the future. Therefore, the payment application device 30B according to this embodiment allows the business operator 3 to apply for payment using a future claim that is greater in amount than the fixed claim.
[0102] In addition, according to the above-described embodiment, the payment application device 30B further includes an authorization request unit 32 that transmits an authorization request for a credit card, which is one of the payment means of the business operator 3; an authorization result acquisition unit 34 that acquires the result of authorization for the credit card for which authorization has been requested; a calculation unit 42 that calculates the amount of a future claim, which is a claim that the business operator is expected to hold in the future, based on the amount of the confirmed claim when there is a possibility that a confirmed claim will occur repeatedly; a selection unit 35 that selects at least one of a plurality of types of payment means that have been preset when the result of authorization for the credit card indicates that the credit card cannot be used; a payment means presentation unit 36 that presents the payment means selected by the selection unit 35 to the business operator 3; and a payment means acquisition unit 37 that acquires the payment means selected by the business operator 3, where the preset payment means include payment means that make a payment according to the amount of the confirmed claim or the amount of the future claim, among the amounts of accounts payable acquired by the debt information acquisition unit 43, and the application unit 38 applies for payment using the payment means acquired by the payment means acquisition unit 37. According to this embodiment, when a credit card cannot be used, the payment application device 30B presents other payment means, including a payment means based on credit, to the business operator 3 so that the business operator 3 can receive the advance payment service 1A. By presenting other means, the business operator 3 can select a payment means that suits him / her and receive the advance payment service 1A. If the business operator 3 can receive the advance payment service 1 using other payment means even if a credit card cannot be used, the business operator 3 will not need to make separate payments to multiple business partners. Therefore, the payment application device 30B according to this embodiment can reduce the business operator's burden for payments.
[0103] [Embodiment 4] An example of a payment application device 30C which is a payment application device according to the fourth embodiment will be described with reference to FIGS.
[0104] FIG. 17 is a flowchart for explaining an example of the flow of payment made by a business to a service provider in the fourth embodiment. When payment cannot be made by credit card, the payment application device 30B in the third embodiment applies for payment by another payment means selected by the business 3. The payment application device 30C (not shown) in the fourth embodiment is similar to the payment application device 30B in the third embodiment in that when payment cannot be made by credit card, payment is made by another payment means. The payment application device 30C differs from the payment application device 30B in that the business 3 does not select the payment means. Note that in the fourth embodiment, the explanation of the payment flow already explained in the first to third embodiments may be omitted by assigning the same reference numerals.
[0105] If there is a problem with the authorization result (step S102; problem), the payment application device 30C acquires the amount of the confirmed credit, the amount of the debt (the amount paid in advance by the service provider 5), and the payment method preset by the business operator 3 (step S104B).The payment application device 30C selects a payment method based on the payment method preset by the business operator 3, and applies for payment using the selected payment method (step S105C).
[0106] Fig. 18 is a functional configuration diagram for explaining an example of the functional configuration of a payment application device according to embodiment 4. With reference to the figure, an example of the functional configuration of a payment application device 30C according to embodiment 4 will be described. Payment application device 30C differs from payment application device 30B in that it does not have payment means presenting unit 36 and payment means acquisition unit 37 as components.
[0107] The selection unit 35 acquires the setting information PI from the set means acquisition unit 33. Furthermore, the selection unit 35 acquires the authorization result information AI from the authorization result acquisition unit 34. The selection unit 35 selects a payment means other than the unusable credit card from the setting information PI. The selection unit 35 transmits the selection information MI to the application unit 38. When payment by claim is selected as the payment means, the selection unit 35 selects either a confirmed claim or a future claim for the claim to be used for the payment. When payment by future claim is selected, the selection unit 35 further selects a calculation means for the future claim and transmits it to the calculation unit 42 (not shown). The calculation unit 42 calculates the amount of the future claim by the selected calculation means based on the amount of the confirmed claim acquired from the claim information acquisition unit 41, and transmits it to the application unit 38. The application unit 38 applies for payment based on the acquired selection information MI, calculated claim information PCI, and debt information DI. That is, similar to payment application device 30A, when a credit card cannot be used, payment application device 30C applies for payment by a payment means other than the unavailable credit card without presenting any options to business operator 3. Note that if business operator 3 has set in advance payment by a confirmed claim as the payment means, claim information acquisition unit 41 may transmit claim information FCI directly to application unit 38 without going through calculation unit 42.
[0108] The selection unit 35 may select a payment method based on either a confirmed claim or a future claim based on the contents of the credit card authorization result acquired by the authorization result acquisition unit 34. There are cases where the business entity 3 has accounts receivable, but the business entity 3's ability to repay is in doubt due to reasons such as reaching the credit card limit, and the credit card becomes unavailable. For example, the selection unit 35 may select a payment method based on a future claim having a larger amount than the confirmed claim as a relief measure when the business entity 3 does not have money on hand.
[0109] If a payment is made to a business operator 3 with questionable ability to repay using a future claim that is not certain to be held in the future, the service provider 5 may not be able to recover the entire amount advanced. Therefore, when a credit card cannot be used because of doubts about the business operator 3's ability to repay, the selection unit 35 may select a payment method using a confirmed claim.
[0110] [Summary of the fourth embodiment] According to the above-described embodiment, the payment application device 30C further includes an authorization request unit 32 that transmits an authorization request for a credit card, which is one of the payment means of the business operator 3; an authorization result acquisition unit 34 that acquires the result of authorization for the credit card for which authorization has been requested; a calculation unit 42 that calculates the amount of a future claim, which is a claim that the business operator is expected to hold in the future, based on the amount of the confirmed claim when there is a possibility that a confirmed claim will be generated repeatedly; and a selection unit 35 that selects at least one payment means from a plurality of types of payment means that have been preset when the result of authorization for the credit card indicates that the credit card cannot be used. The claim information FCI includes information on future claims, which are claims that the business operator 3 is expected to hold in the future, and confirmed claims, which are claims that have been confirmed to be paid to the business operator 3 by the business operator's accounts receivable customer 4. The preset payment means include payment means that make payments according to the amount of the confirmed claim or the amount of the future claim, among the amounts of accounts payable acquired by the debt information acquisition unit 43, and the application unit 38 applies for payment using the payment means selected by the selection unit 35. The payment application device 30C does not present options to the business operator 3, but instead applies for payment using a preset payment method or a payment method selected by the selection unit 35. That is, according to this embodiment, the business operator 3 is relieved of the trouble of having to select a new payment method when a credit card cannot be used. Therefore, the payment application device 30C according to this embodiment can reduce the burden on the business operator regarding payment.
[0111] Note that all or part of the functions of each section of payment application device 30, payment application device 30A, payment application device 30B and payment application device 30C in the above-mentioned embodiments may be realized by recording a program for realizing these functions on a computer-readable recording medium, and having a computer system read and execute the program recorded on this recording medium. Note that the term "computer system" here includes hardware such as the OS and peripheral devices.
[0112] Furthermore, the term "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, and recording units such as hard disks built into computer systems. Furthermore, the term "computer-readable recording medium" may also include those that dynamically hold a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, and those that hold a program for a certain period of time, such as a volatile memory inside a computer system that serves as a server or client in such cases. Furthermore, the above-mentioned program may be one that realizes part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.
[0113] Although one embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design changes and the like are possible without departing from the scope of the present invention. In addition, the configurations described in the above-mentioned embodiments and examples may be combined. [Explanation of symbols]
[0114] 1...advance payment service, 2...payable party, 3...business operator, 4...accounts receivable party, 5...service provider, P...product, C...money, S...service, 10...system, 20...terminal device, NW...network, 30...payment application device, OI...application operation information, PI...setting information, SMI...selected means information, MI...selection information, PPI...application result information, 31...application acceptance unit, 32...authorization request unit, 33...set means acquisition unit, 34...authorization result acquisition unit, 35...selection unit, 36...payment means presentation unit, 37...payment means acquisition unit, 38...application unit, 39...application result presentation unit, AI...authorization result information, 41...credit information acquisition unit, 42...calculation unit, 43...debt information acquisition unit, FCI...credit information, PCI...calculated credit information, DI...debt information
Claims
1. an authorization request unit that transmits an authorization request for a credit card, which is one of the payment methods of the business; an authorization result acquisition unit that acquires a result of authorization for the credit card for which authorization has been requested; a selection unit that selects at least one of a plurality of types of the payment means set in advance when the credit card cannot be used as a result of authorization for the credit card; an application unit for applying for payment by the payment means selected by the selection unit; A payment application device comprising:
2. a payment means presenting unit that presents the payment means selected by the selection unit to the business operator; a payment method acquisition unit that acquires the payment method selected by the business; Further equipped with The application unit applies for payment using the payment means acquired by the payment means acquisition unit.
2. The payment application device of claim 1.
3. The application unit applies for payment using the payment means selected by the business operator when the authorization result indicates that the payment means is unavailable.
3. A payment application device according to claim 2.
4. The selection unit, when the application unit is unable to apply for payment using the payment means selected by the selection unit, selects a payment means different from the payment means for which the application unit was unable to apply for payment.
2. The payment application device of claim 1.
5. In the case where the business operator has a plurality of the credit cards, The selection unit determines whether payment can be made with a credit card other than the unusable credit card based on the contents of the authorization result, and selects the payment method. A payment application device according to any one of claims 1 to 4.
6. a claim information acquisition unit that acquires claim information regarding the amount of a confirmed claim, which is a claim that is confirmed to be paid to the business by a customer of the business; a debt information acquisition unit that acquires debt information relating to the amount of accounts payable owed by the business; a calculation unit that calculates the amount of a future claim, which is a claim that the business operator is expected to hold in the future, based on the amount of the confirmed claim when there is a possibility that the confirmed claim will occur repeatedly; Further equipped with The preset payment means includes a payment means for making a payment according to the amount of the confirmed credit or the amount of the future credit among the amount of the accounts payable acquired by the debt information acquisition unit. A payment application device according to any one of claims 1 to 4.
7. On the computer, an authorization request step of transmitting an authorization request for a credit card, which is one of the payment methods of the business; an authorization result acquisition step of acquiring a result of authorization for the credit card for which authorization has been requested; a selection step of selecting at least one of a plurality of types of the payment means set in advance when the credit card cannot be used as a result of authorization for the credit card; an application step of applying for payment using the payment means selected in the selection step; A program that executes the following.
Citation Information
Patent Citations
Information processing device, information processing method, and program
WO2017073102A1