Settlement processing apparatus, payment processing method, and program

Abstract

To provide means for credit-card payment combined with guarantee function.SOLUTION: A settlement processing apparatus stores billing data and billing statement data indicating results of transaction between a first user and a second user. The settlement processing apparatus executes the steps of: receiving an application for financing to be associated with credit-card payment; generating a deposit request for depositing money to an account of the first user on a scheduled payment date registered in first billing statement data associated with the financing application; generating a guarantee application to be associated with the financing application; and generating card sales data with a sales date set thereto so that account transfer based on the first billing statement data is executed on a desired payment date associated with the financing application.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] The present invention relates to a payment processing device, a payment processing method, and a program. [Background technology]

[0002] In the field of business-to-business (BtoB) transactions, known payment methods from buyers (debtors) to suppliers (creditors) include bank transfers, direct debits, and credit cards, and in recent years, the use of credit cards for payments between corporations has been increasing.

[0003] In business-to-business transactions, the payment date, for example, payment at the end of the month, is determined by the contract concluded between the supplier and the buyer. Depending on the financial condition of the company, the supplier may want to obtain funds early, while the buyer may want to postpone the predetermined payment date. In such cases, the supplier consults with the other company to obtain funds early and / or postpone payment under certain restrictive conditions. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 5866418 Summary of the Invention [Problem to be solved by the invention]

[0005] Conventional credit card functions have a credit limit based on the credit card company's screening, and in business-to-business transactions where the settlement amount tends to be large, the limit can be exceeded, making it difficult to use credit card payments because only a limited number of transactions are available. The credit card advance payment period is also short, about one month, and advance payment over several months is not possible, which is inconvenient. Patent Document 1 proposes raising the card limit by transferring funds in advance to the card company's account, but this method requires a large amount of funds in advance, making it difficult to use for users who want to extend payments over several months.

[0006] In the conventional application for early financing, for example, when a bill or electronically recorded claim was received, the supplier could choose between collecting payment on the normal due date or early financing with recourse only, and when collecting payment at a card affiliated store, early financing with / without recourse only was available, meaning that it was not possible to choose between collecting payment on the normal due date or early financing with / without recourse depending on the situation, and this lacked flexibility.On the other hand, it was not easy for buyers to postpone payment even if they wanted to.

[0007] The present invention has been made to solve these problems, and aims to provide a payment processing device, a payment processing method, and a program that provide buyers with a card payment method combined with a guarantee function, in addition to the conventional direct debit payment method.

[0008] Another object of the present invention is to provide a payment processing device, a payment processing method, and a program that, in addition to the conventional payment by direct debit on the scheduled payment date, enables a user to select either with recourse (company guarantee) or without recourse (bank guarantee) in conjunction with an application for early financing. [Means for solving the problem]

[0009] In order to solve the above problems, the present invention provides a payment processing device including a communication unit for communicating with an external network, a storage unit, and a control unit, The storage unit stores billing data and billing detail data indicating a transaction result between a first user and a second user, The control unit is receiving a financing application associated with card payment from a second user terminal via the communication unit; generating a deposit request for depositing money into the account of the first user on a scheduled payment date registered in a first billing detail data associated with the financing application; generating a guarantee offer associated with the financing offer; generating card sales data in which a sales date is set such that an account transfer process based on the first billing detail data is executed on a desired payment date associated with the financing application; Execute. Effect of the Invention

[0010] According to the present invention, a buyer can apply for payment deferral (advance payment by a financial institution) up to the guaranteed limit amount allowed by the payment processing device, making it possible to make payments in amounts greater than the credit amount of the card company, and since the credit risk of the card company can be eliminated as long as a guarantee is provided, it becomes possible to advance payment in units of several months.

[0011] According to the present invention, the supplier can select from three fund collection methods using the payment processing device, and can flexibly use the advance payment date and credit risk hedging according to the status of the supplier's cash flow and credit management. In other words, the supplier can select one of the following fund collection options: normal payment collection by collection agency on the scheduled payment date based on the settlement conditions with the buyer, early financing with recourse, and early financing without recourse. [Brief description of the drawings]

[0012] A more detailed understanding of the embodiments disclosed herein can be had from the following description, taken in conjunction with the accompanying drawings, in which: [Figure 1]1 is a configuration diagram of an entire system including a payment processing device 10. FIG. [Diagram 2] 1 is a system configuration diagram of a payment processing device 10. FIG. [Diagram 3] 3 shows an example of a data structure of a user master 106. FIG. [Figure 4] 13 is a diagram showing an example of a data structure of contract / payment information 107. FIG. [Diagram 5] FIG. 2 is a diagram showing an example of a data structure of billing data 108. [Figure 6] 13 is a diagram showing an example of a data structure of billing details data 109. FIG. [Figure 7] FIG. 1 is a diagram illustrating a process flow for transferring funds between a supplier and a buyer by account transfer and credit. [Figure 8] FIG. 1 is a flow diagram illustrating a financing process for a supplier. [Figure 9] FIG. 1 is a flow diagram illustrating the financing process for a buyer. [Figure 10] FIG. 10 is a diagram illustrating an example of an early financing request screen 1000. [Figure 11] FIG. 11 is a diagram illustrating an example of a trial calculation result display screen 1100. [Figure 12] FIG. 12 is a diagram illustrating an example of a payment deferral request screen 1200. [Figure 13] FIG. 13 is a diagram illustrating an example of a trial calculation result display screen 1300. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] (Overall composition) Figure 1 is a configuration diagram of the entire system including a payment processing device 10, a supplier terminal 11, a buyer terminal 12, an account transfer system 13, a finance system 14, a deposit processing system 15, a first bank system 16, and a second bank system 17 in an embodiment of the present invention.

[0014] The payment processing device 10 is connected to a supplier terminal 11 and a buyer terminal 12 so that they can communicate with each other via a first network 21 such as the Internet. The payment processing device 10 is connected to an account transfer system 13, a finance system 14, a deposit processing system 15, a first bank system 16, and a second bank system 17 so that they can communicate with each other via a second network 22 such as the Internet or a LAN or WAN.

[0015] In this specification, the payment processing device 10 is described as one system or device, but various processes executed by the payment processing device 10 may be configured to be distributed and executed by multiple systems or devices. For ease of explanation, only one supplier terminal 11 and one buyer terminal 12 are shown in Figure 1, but there may be multiple supplier terminals 11 and one buyer terminal 12.

[0016] The supplier terminal 11 is a terminal used by a supplier in a business-to-business transaction. The supplier terminal 11 can be a computer such as a personal computer (PC) or a tablet terminal equipped with a communication function and a data editing / viewing function using a web browser, but is not limited to a specific apparatus or device.

[0017] The buyer terminal 12 is a terminal used by a buyer in a business-to-business transaction. The buyer terminal 12 can be a computer such as a personal computer (PC) or a tablet terminal equipped with a communication function and a data editing / viewing function using a web browser, but is not limited to a specific apparatus or device.

[0018] The account transfer system 13, the finance system 14, and the deposit processing system 15 are systems for executing predetermined processes, may be external systems or subsystems of a financial institution, and provide functions as described below.

[0019] The first bank system 16 and the second bank system 17 are bank systems such as accounting systems controlled by financial institutions. The first bank system 16 is a system of a supplier bank, and the second bank system 17 is a system of a buyer bank. When the supplier bank and the buyer bank are the same financial institution, the first bank system 16 and the second bank system 17 are the same system.

[0020] The payment processing device 10 is a device used for processing payments related to transactions between companies, and provides various functions supporting basic data registration processing, payment processing, finance processing, guarantee processing, deposit processing, etc., as described in this specification, to the supplier terminal 11 and the buyer terminal 12 via a unified web-based interface. The various functions provided by the payment processing device 10 are described below.

[0021] (Basic data registration process) In this specification, "basic data" refers to user information related to suppliers and buyers, contract information for business-to-business transactions, and information showing the actual state of business-to-business transactions (e.g., sales data). The payment processing device 10 issues IDs to each supplier and buyer, receives information related to the supplier and buyer, and stores it as user information. The payment processing device 10 receives and stores payment-related contract information such as closing date, sales data registration date, and payment date from supplier terminal 11.

[0022] The settlement processing device 10 generates unapproved billing data at a predetermined timing based on the sales data, user information, and contract information received from the supplier terminal 11, and provides the unapproved billing data to the supplier terminal 11. In response to the unapproved billing data being approved by the supplier terminal 11, the settlement processing device 10 provides the unapproved billing data to the buyer terminal 12. When the buyer confirms the content of the unapproved billing data and approves it via the buyer terminal 12, the data is treated as approved billing data by the settlement processing device 10. The approved billing data includes information such as the payment date based on the payment accounts of the supplier and the buyer, and the contract information between the supplier and the buyer. Therefore, the buyer can confirm the payment amount and payment date in advance before actually making the payment. In the following description, approved billing data will be simply called "billing data" or "billing detail data", and unapproved billing data will be called "unapproved billing data" or "unapproved billing detail data".

[0023] (Payment processing) The payment processing device 10 generates account transfer claim data based on the amount information in the billing data and billing detail data and the account information of the supplier and buyer. The payment processing device 10 transmits the account transfer claim data to the account transfer system 13 so that the processing will be performed on the debit date indicated by the account transfer claim data. The account transfer claim data includes information such as the debit date, debit account, deposit account, and debit amount, and upon receiving the account transfer claim data, the account transfer system 13 immediately generates an account transfer message and transmits it to the second bank system 17 (the debit date is set to the same day or the next business day).

[0024] The second bank system 17 executes the account transfer process, and the funds are transferred to the account of the payment agent that manages the account transfer system 13. The payment processing device 10 generates a transfer message indicating the transfer of funds from the account of the payment agent to the supplier account based on the supplier account information in the account transfer request data, and transmits it to the first bank system 16. The first bank system 16 then executes the deposit process for the supplier account.

[0025] (Finance processing, deposit processing, guarantee processing) Financing is a payment made in advance by a financial institution, and types of financing include early cash for the supplier (creditor) and deferred payment for the buyer (debtor).

[0026] With regard to early financing, which is a form of financing, the payment processing device 10 provides the supplier terminal 11 with billing data and billing detail data for which the payment date has not yet arrived on a screen interface provided by the payment processing device 10. When the payment processing device 10 receives from the supplier terminal 11 a request for financing for the billing detail data selected by the supplier terminal 11, it generates trial calculation request data based on the billing detail data and transmits it to the financing system 14. The financing request includes selection information for either a bank guarantee (without recourse) or a company guarantee (with recourse) for each detail data. The financing system 14 performs trial calculations for early financing based on the contents of the billing detail data and the guarantee information, and transmits the trial calculation results to the payment processing device 10. The payment processing device 10 provides the trial calculation results to the supplier terminal 11 on a separate screen interface.

[0027] When the payment processing device 10 receives early financing application data from the supplier terminal 11 after providing the trial calculation results, it generates deposit request data based on the application data and sends it to the deposit processing system 15. The deposit processing system 15 generates a transfer message based on the deposit request data and sends it to the first bank system 16. The first bank system 16 performs a deposit process to the supplier account based on the transfer message. The payment processing device 10 also generates account transfer request data based on the application data and sends it to the account transfer system 13. Thereafter, as described above, the account transfer process is performed on the original scheduled payment date. After the account transfer process, no deposit process is performed to the supplier account.

[0028] With regard to payment deferral, which is another form of financing, the payment processor 10 provides the buyer terminal 12 with billing data and billing detail data for which the payment date has not yet arrived on a screen interface provided by the payment processor 10. When the payment processor 10 receives from the buyer terminal 12 a request for financing for the billing detail data and desired payment date selected by the buyer terminal 12, it generates trial calculation request data based on the billing detail data and desired payment date and sends it to the finance system 14. The finance system 14 performs trial calculation for payment deferral based on the contents of the billing detail data and information on the desired payment date, and sends the trial calculation result to the payment processor 10. The payment processor 10 provides the trial calculation result to the buyer terminal 12 on a separate screen interface.

[0029] When the payment processor 10 receives payment deferral application data from the buyer terminal 12 after providing the trial calculation results, it generates deposit request data based on the application data and sends it to the deposit processing system 15. The deposit processing system 15 generates a transfer message based on the deposit request data and sends it to the first bank system 16. The first bank system 16 performs a deposit process to the supplier account based on the transfer message. This deposit is made on the originally scheduled payment date. The payment processor 10 also generates account transfer request data based on the billing detail data associated with the application data, and sends it to the account transfer system 13 so that the process is performed on the deduction date indicated by the account transfer request data. This deduction date is the desired payment date set by the buyer. After the account transfer process, no deposit process is performed to the supplier account.

[0030] In addition, the source account of the transfer message in the finance processing is the bank account of the business entity that manages the deposit processing system 15, and the deposit account in the account transfer processing is the account of the payment agent.

[0031] Furthermore, when the payment processing device 10 receives the early financing application data or the payment deferral application data, it generates guarantee application data corresponding to each application and transmits it to the finance system 14. The finance system 14 executes processing of the guarantee arrangement for early financing or payment deferral based on the guarantee application data.

[0032] (Functionality of external systems or subsystems of financial institutions) Based on the received account transfer request data, the account transfer system 13 requests the second bank system 17 of the financial institution holding the buyer's account to perform account transfer processing to withdraw funds from the buyer's account, and the second bank system 17 transfers the withdrawn funds to a specified account. The received account transfer request data may indicate that the account transfer will be executed on the scheduled payment date included in the contract information, i.e., the day (or the next business day) on which the account transfer request data is received, or the desired payment date specified when the buyer requested financing (advance payment).

[0033] The finance system 14 performs trial calculations based on the billing detail data and guarantee information for which financing is requested, and provides the trial calculation results for early financing to the payment processing device 10. The finance system 14 performs trial calculations based on the billing detail data and guarantee information for which financing is requested, and the desired payment date specified by the buyer, and provides the trial calculation results for payment deferral to the payment processing device 10. The finance system 14 executes processing of the guarantee arrangement based on the guarantee application data.

[0034] The deposit processing system 15 generates a transfer message based on the deposit request data received from the payment processing device 10, and sends the transfer message to a financial institution system corresponding to the transfer destination account included in the deposit request data, for example, a first bank system 16 having a supplier account, to execute the deposit processing.

[0035] (System configuration of payment processing device 10) Next, the system configuration of the payment processing device 10 will be described. FIG. 2 is a system configuration diagram of the payment processing device 10 according to the embodiment of the present invention. As shown in FIG. 2, the payment processing device 10 includes a control unit 101, a main memory unit 102, an auxiliary memory unit 103, an IF unit 104, and an output unit 105, which are interconnected by a bus 120 or the like, like a general computer. The auxiliary memory unit 103 stores programs that implement the functions of the payment processing device 10 and data handled by the programs. The auxiliary memory unit 103 includes a user master 106, contract / payment information 107, billing data 108, and billing detail data 109 in the form of a file / database or the like. The payment processing device 10 can read, edit, or update information stored in the user master 106, contract / payment information 107, billing data 108, and billing detail data 109. Various programs stored in the auxiliary memory unit 103 are executed by the payment processing device 10.

[0036] The control unit 101, also called a central processing unit (CPU), controls each component of the payment processing device 10 and performs data calculations, and also reads out and executes various programs stored in the auxiliary storage unit 103 into the main storage unit 102. The main storage unit 102, also called a main memory, stores various received data, computer-executable instructions, and data after calculation processing based on the instructions. The auxiliary storage unit 103 is a storage device typified by a hard disk drive (HDD) and is used for long-term storage of data and programs.

[0037] The embodiment in Fig. 2 describes an embodiment in which control unit 101, main memory unit 102, and auxiliary memory unit 103 are provided inside the same computer, but in another embodiment, payment processing device 10 can be configured to realize parallel distributed processing by multiple computers by using multiple control units 101, main memory units 102, and auxiliary memory units 103. In another embodiment, it is also possible to install multiple servers for payment processing device 10, and have the multiple servers share one auxiliary memory unit 103.

[0038] The IF unit 104 plays the role of an interface (IF) when transmitting and receiving data to and from other systems and devices, and also provides an interface for receiving various commands and input data (various masters, tables, etc.) from a system operator. The output unit 105 provides a display screen for displaying processed data and a printing means for printing the data.

[0039] The user master 106 stores information on users such as suppliers and buyers who use the payment processing device 10 according to the present invention. Fig. 3 is a diagram showing an example of a data structure of the user master 106 according to the embodiment of the present invention. The user master 106 can include a user ID 301, a user name 302, and user information 303, but is not limited to these data items and can also include other data items.

[0040] User ID 301 is an identifier that identifies a user (such as a company or any department within a company) who uses the payment processing device 10 according to the present invention. A user can be a supplier or a buyer in a business-to-business transaction. User name 302 indicates the name of the user (such as the company name or department name within the company). User information 303 indicates various information about the user, such as the user's contact information (email address, telephone number, address, etc.), payment account, authorizer, and payment route. The payment account indicates information about the bank account used when processing deposits and withdrawals. The authorizer indicates the person at the supplier or buyer who approves unapproved billing data, and the person who approves may be a department at the user. The payment route indicates the route of the payment order when there are multiple authorizers.

[0041] Returning to FIG. 2, the contract / payment information 107 stores contract information and payment information relating to transactions between a supplier and a buyer in business-to-business transactions. The supplier registers the contract information and payment information via a contract / payment information registration screen (not shown) provided by the payment processing device 10. FIG. 4 is a diagram showing an example of the data structure of the contract / payment information 107 according to an embodiment of the present invention. The contract / payment information 107 may include a supplier ID 401, a buyer ID 402, payment terms 403, and a credit status 404, but is not limited to these data items and may also include other data items.

[0042] Supplier ID 401 is an identifier indicating a supplier in a business-to-business transaction. Buyer ID 402 is an identifier indicating a buyer in a business-to-business transaction. The identifiers set as supplier ID 401 and buyer ID 402 may be user ID 301. Payment terms 403 indicate payment terms agreed upon in advance between the supplier and buyer. The payment terms may be the closing date, the deadline for registering sales data, and the payment date (e.g., the end of the month). Credit status 404 indicates the credit limit (upper limit) and current balance set by the supplier against the buyer.

[0043] Returning to FIG. 2, the billing data 108 stores summary information of sales data uploaded by the supplier. The summary information indicates unapproved billing data or billing data. FIG. 5 is a diagram showing an example of the data structure of the billing data 108 according to an embodiment of the present invention. The billing data 108 may include, but is not limited to, a supplier ID 401, a buyer ID 402, a file ID 501, a file name 502, a creation date 503, a number of data items 504, a total amount 505, a payment date 506, a scheduled payment date before change 507, a payment method 508, and a status 509. The billing data 108 may include other data items.

[0044] Supplier ID 401 is an identifier indicating the supplier in the billing data. Buyer ID 402 is an identifier indicating the buyer in the billing data. File ID 501 is an identifier that identifies a sales data file uploaded by a supplier. The sales data file contains one or more unapproved billing detail data. File name 502 is the name given to the uploaded sales data file. Creation date 503 is the creation date of the sales data file. Data count 504 is the number of data items in the detail data included in the sales data file. Total amount 505 indicates the total billing amount of the billing details included in the sales data file.

[0045] Payment date 506 indicates the scheduled date of payment. Pre-change scheduled payment date 507 indicates the previous scheduled payment date when the payment date has been changed. Payment method 508 indicates the method by which payment is made from the buyer to the supplier (e.g., direct debit, bank transfer, card payment, etc.). Status 509 indicates the state of unapproved billing data or billing data. This state indicates, for example, awaiting supplier approval, awaiting buyer approval, awaiting direct debit request, card payment, awaiting payment, paid, etc., and is usually synchronized with the status of the corresponding data group in billing detail data 109.

[0046] Returning to FIG. 2, the billing detail data 109 stores unapproved billing detail data associated with unapproved billing data or billing detail data associated with billing data. FIG. 6 is a diagram showing an example of the data structure of the billing detail data 109 according to an embodiment of the present invention. The billing detail data 109 can include a supplier ID 401, a buyer ID 402, a file ID 501, a payment date 506, a billing number 601, a billing content 602, a billing amount 603, a scheduled payment date 604, a status 605, a finance flag 606, a guarantee flag 607, a deposit account 608, and a withdrawal account 609, but is not limited to these data items and can also include other data items.

[0047] Supplier ID 401 is an identifier indicating the supplier in the billing detail data. Buyer ID 402 is an identifier indicating the buyer in the billing detail data. File ID 501 is an identifier of the sales file associated with each billing detail data. Payment date 506 indicates the payment date of the billing data associated with the billing detail data, and serves as a unit for consolidating one or more detail data between a supplier and a buyer. Billing number 601 is an identifier that identifies the billing detail data. Billing content 602 indicates the content of the bill (e.g., price of goods, price of services). Billing amount 603 indicates the billing amount indicated by the billing detail data. Scheduled payment date 604 indicates the date on which payment is scheduled for each bill.

[0048] Status 605 indicates the state of the billing detail data. The state of the billing detail data indicates, for example, awaiting supplier approval, awaiting buyer approval, awaiting account transfer request, card payment, awaiting payment, paid, etc. Financing flag 606 is a flag indicating whether there is a desire to obtain funds earlier than the payment term previously agreed upon between the supplier and the buyer, or whether the buyer wishes to postpone payment. Guarantee flag 607 indicates whether a bank guarantee or a company guarantee has been selected. Receiving account 608 indicates a receiving account, for example, a supplier account. Withdrawal account 609 indicates a withdrawal account, for example, a buyer account.

[0049] (Explanation of various flows) 7 to 9, various processes executed by the payment processing device 10 will be described, namely, the process flow for transferring funds by account transfer and credit, the process flow for early financing at the request of a supplier, and the process flow for deferring payment using a card payment at the request of a buyer. As a premise for explaining these process flows, it is assumed that users who can become suppliers and buyers are assigned user IDs by the payment processing device 10, various user-related information is registered in the user master 106, contract information and settlement information relating to transactions between suppliers and buyers in business-to-business transactions are registered in the contract / settlement information 107, and billing data and billing detail data based on transactions between suppliers and buyers are stored in billing data 108 and billing detail data 109.

[0050] (Process flow: Funds transfer by account transfer and bank transfer) 7 is a diagram explaining the process flow for transferring funds between a supplier and a buyer by account transfer and credit. More specifically, the process flow will be explained in which the payment processor 10 generates account transfer request data based on billing detail data for which the payment due date is approaching, and transmits the account transfer request data to the account transfer system 13 to transfer the funds.

[0051] In S701, payment processing device 10 reads from billing detail data 109 the billing detail data for which status 605 indicates "waiting for account transfer request".

[0052] In S702, the payment processor 10 generates account transfer request data based on the information on the scheduled payment date 604, the billing amount 603, the deposit account 608, and the withdrawal account 609 contained in the read billing detail data, and updates the statuses 509, 605 of the read billing detail data and the billing data associated with the billing detail data to "waiting for payment", respectively. The deposit account for the account transfer request data may be a supplier account or an account of a payment agent that manages the account transfer system 13.

[0053] The payment processing device 10 transmits the account transfer request data to the account transfer system 13. The account transfer system 13 generates an account transfer request message based on a predetermined format based on the account transfer request data, and transmits the account transfer request message to a second bank system 17 of the financial institution corresponding to the buyer account included in the account transfer request data. The second bank system 17 transmits the result data of the account transfer process to the payment processing device 10 via the account transfer system 13. The second bank system 17 also withdraws funds from the buyer account and transfers them to a bank that holds the account of the payment agent. The bank performs a deposit process into the account of the payment agent.

[0054] In S703, in response to receiving the result data of the account transfer process from the second bank system 17, the payment processing device 10 generates deposit request data corresponding to the account transfer request data. The deposit request data may be deposit request data with the account of the payment agent as the withdrawal account and the supplier account as the deposit account. The payment processing device 10 transmits the deposit request data to the account transfer system 13, which generates a transfer message based on the deposit request data and transmits it to the first bank system 16. The first bank system 16 executes the deposit process to the supplier account based on the transfer message.

[0055] In S704, the payment processing device 10 updates the status 605 of the billing detail data associated with the account transfer processing to “Payment completed” based on the result data of the account transfer processing, and updates the status 509 of the billing data associated with the billing detail data to “Payment completed”.

[0056] These processes enable suppliers to significantly reduce the administrative work of managing invoice amounts and payment due dates. In addition, the update process in S704 displays the status of the invoice data and invoice detail data as "paid", making it easier than ever to carry out the administrative work of clearing payments for each invoice. Because the supplier terminal 11 can obtain invoice data and invoice detail data with a status of "paid", suppliers can easily check the clearing of payments.

[0057] (Process flow: Financing and guarantee arrangements) Financing is a payment made on behalf of a financial institution, and the types of financing include early financing for the supplier (creditor) and deferred payment for the buyer (debtor). Figure 8 is a flow diagram explaining the financing process for the supplier, and Figure 9 is a flow diagram explaining the financing process for the buyer.

[0058] Referring to Figure 8, the process flow will be described in which the payment processing device 10 provides the supplier with the results of a trial calculation in response to receiving a financing request (early financing request) from the supplier, and generates deposit request data and guarantee application data in response to receiving a financing application from the supplier.

[0059] In S801, in response to a request from the supplier terminal 11, the payment processing device 10 provides billing detail data for which account transfer request data has not been generated, i.e., billing detail data whose status 605 is “waiting for account transfer request”, to the supplier terminal 11 via the early cash request screen 1000 on a sales data file basis associated with them.

[0060] FIG. 10 is a diagram illustrating an example of an early funding request screen 1000. The early funding request screen 1000 includes a billing data summary 1001, an early funding request summary 1002, a billing detail data selection field 1003, and a register button 1004. The billing data summary 1001 shows summary information of a sales data file associated with one or more billing detail data. The early funding request summary 1002 shows an overview of the request content made by the supplier. The overview of the request content includes whether early funding is desired, the details of early funding of bank guarantees, and the details of early funding of company guarantees. The billing detail data selection field 1003 displays each of the billing detail data associated with the sales data file. The register button 1004 is a button for registering the details of the early funding request entered by the supplier.

[0061] If the supplier selects "Do not want" in the early financing request summary 1002, the account transfer process will be performed according to the scheduled payment date stored in the billing detail data. On the other hand, if the supplier selects "Want" in the early financing request summary 1002, the supplier selects the billing detail data displayed in the billing detail data selection field 1003 for which early financing is desired, and further selects either a bank guarantee or a company guarantee. There are two means of early financing: a bank guarantee (without recourse) and a company guarantee (with recourse). A bank guarantee (without recourse) means that even if the buyer (debtor) is unable to make payment even on the due date and defaults on the debt, the early deposited funds will not be returned from the supplier to the financial institution from which it was transferred, meaning that the financial institution bears the risk of default. On the other hand, a company guarantee (with recourse) means that the early deposited funds will be returned from the supplier to the financial institution from which it was transferred in the event of default, meaning that the supplier bears the risk of default.

[0062] When the supplier presses the register button 1004, the payment processing device 10 receives an early funding request for the selected billing detail data. A predetermined value is set in the financing flag 606 of the received billing detail data. For example, a first value is set in the financing flag 606 of billing detail data for which a bank guarantee has been selected, while a second value is set in the financing flag 606 of billing detail data for which a company guarantee has been selected.

[0063] At S802, the payment processing device 10 transmits a request for trial calculation for early financing based on the contents of the billing detail data and the guarantee information (e.g., the first value and the second value) for which early financing has been requested to the finance system 14. The finance system 14 performs trial calculation based on the contents of the billing detail data and the guarantee information received, and transmits the trial calculation result to the payment processing device 10. The finance system 14 may indicate that the trial calculation result changes depending on the number of days until the scheduled payment date.

[0064] In S803, in response to receiving the trial calculation result from the finance system 14, the payment processing device 10 provides the trial calculation result to the supplier terminal 11 via the trial calculation result display screen 1100.

[0065] FIG. 11 is a diagram for explaining an example of a trial calculation result display screen 1100. The trial calculation result display screen 1100 includes early payment target item information 1101, trial calculation result 1102, an application button 1103, and a withdrawal button 1104. The early payment target item information 1101 shows one or more billing item data for which trial calculation was performed and the trial calculation result for each billing item data. The trial calculation result 1102 shows a summary of the trial calculation result performed for one or more billing item data. The application button 1103 is a button for officially applying for early financing according to the trial calculation result. The withdrawal button 1104 is a button for withdrawing a request when the trial calculation result is not accepted, and when this button is pressed, the payment processing device 10 sets a null value to the finance flag 606 of the billing item data to be withdrawn.

[0066] If the trial calculation result is acceptable, the supplier presses the application button 1103 via the supplier terminal 11 to officially apply for early financing based on the trial calculation result. The payment processing device 10 receives the early financing application from the supplier terminal 11.

[0067] In S804, upon receiving the early financing application, the payment processing device 10 queries the user master 106 to obtain information on the supplier's payment account, generates deposit request data for processing the deposit into the supplier's account, and transmits it to the deposit processing system 15. The deposit processing system 15 transmits a transfer message to the first bank system 16 based on the deposit request data, and the first bank system 16 performs the deposit processing into the supplier's account.

[0068] In S805, upon receiving the early financing application, the payment processing device 10 generates guarantee application data for receiving a guarantee from the bank, and transmits the generated guarantee application data to the finance system 14. The finance system 14 executes processing of the guarantee arrangement based on the guarantee application data.

[0069] The above-mentioned process allows the supplier to cash out receivables earlier than the scheduled payment date. The payment processing device 10 performs an account transfer process on the scheduled payment date for billing detail data that has been cashed early. The account transfer process is performed according to the process described with reference to Figure 7. As a result of the account transfer, funds debited from the buyer's account are deposited into the account of the payment agent, and then deposited into the withdrawal account of the transfer message.

[0070] Next, with reference to Figure 9, we will explain the process flow in which the payment processing device 10, in response to receiving a financing request from a buyer (a request to postpone payment by using a card), provides the buyer with the results of a trial calculation based on the billing statement data and the desired payment date, and in response to receiving a formal financing application from the buyer, generates card sales data and deposit request data, as well as generates guarantee application data.

[0071] In S901, in response to a request from the buyer terminal 12, the payment processing device 10 provides billing detail data for which no account transfer request data has been generated, i.e., billing detail data whose status 605 is “waiting for account transfer request”, to the buyer terminal 12 via the payment deferral request screen 1200 on a sales data file basis associated with them.

[0072] FIG. 12 is a diagram for explaining an example of a payment deferral request screen 1200. The payment deferral request screen 1200 includes a billing data summary 1201, a payment deferral request summary 1202, a billing detail data selection field 1203, and a registration button 1204. The billing data summary 1201 shows summary information of the sales data file associated with one or more billing detail data. The payment deferral request summary 1202 shows an overview of the request content made by the buyer. The desired payment date included in the payment deferral request summary 1202 may be configured to be selected from multiple candidates based on the payment date of the credit card held by the buyer. For example, if the credit card payment date is "payment at the end of the month," the multiple candidates may be the end of the following month, the end of the month after, the end of the month three months later, etc., and if the buyer selects "the end of the month three months later," that date becomes the desired payment date. The billing detail data selection field 1203 displays each of the billing detail data associated with the sales data file. The registration button 1204 is a button for registering the details of the payment deferral request input by the buyer.

[0073] The buyer selects the data for which they wish to postpone payment from among the billing detail data displayed in the billing detail data selection field 1203. When the buyer presses the register button 1204, the payment processor 10 receives a request to postpone payment for the selected billing detail data, and sets a predetermined value (for example, a "third value" indicating payment postponement) to the finance flag 606 of the requested billing detail data. The payment postponement request includes information on the selected billing detail data and the desired payment date.

[0074] In S902, the payment processing device 10 transmits an estimate request including the content of the billing statement data for which payment deferral by card has been requested and the desired payment date to the finance system 14. The finance system 14 performs an estimate based on the content of the billing statement data and the desired payment date received, and transmits the estimate result to the payment processing device 10.

[0075] In S903, in response to receiving the trial calculation result from finance system 14, payment processing device 10 provides the trial calculation result to buyer terminal 12 via trial calculation result display screen 1300.

[0076] FIG. 13 is a diagram for explaining an example of a trial calculation result display screen 1300. The trial calculation result display screen 1300 includes payment deferral target detail information 1301, trial calculation result 1302, an application button 1303, and a withdrawal button 1304. The payment deferral target detail information 1301 shows one or more billing detail data for which trial calculation has been performed, and the trial calculation result for each billing detail data. The trial calculation result 1302 shows a summary of the trial calculation result performed for one or more billing detail data. The application button 1303 is a button for officially applying for processing for payment deferral according to the trial calculation result. The withdrawal button 1304 is a button for withdrawing a request when the trial calculation result is not accepted, and when this button is pressed, the payment processing device 10 sets a null value to the finance flag 606 of the billing detail data to be withdrawn.

[0077] If the estimated result is acceptable, the buyer registers an application for deferred payment via the buyer terminal 12. The payment processing device 10 receives an application for deferred payment by card based on the estimated result from the buyer terminal 12. This application includes information on the billing statement data for which payment is to be deferred and the buyer's desired payment date.

[0078] In S904, when the payment processor 10 receives the application for deferred payment by card payment, it generates deposit request data for performing the deposit process on the scheduled payment date originally registered in the billing detail data, and transmits it to the deposit processing system 15. The deposit processing system 15 transmits a transfer message to the first bank system 16 based on the deposit request data, and the first bank system 16 performs the deposit process to the supplier account.

[0079] In S905, when the payment processing device 10 receives the application for deferred payment by card payment, it generates guarantee application data for receiving a guarantee from the bank, and transmits the generated guarantee application data to the finance system 14. The finance system 14 executes processing of the guarantee arrangement based on the guarantee application data.

[0080] In S906, the payment processing device 10 generates card sales data in which the amount of the billing amount 603 in the billing detail data for which a payment deferral request by card payment has been made is set as the payment amount, and the date on which the account will be debited on the desired payment date is set as the sales date, and transmits the generated data to the deposit processing system 15. Normally, card payments are processed by a card company's system performing a process called authorization to determine whether or not payment is possible based on information such as the card number, settlement amount, and credit information of the cardholder, but in the present invention, such authorization processing is not performed. Therefore, the payment processing device 10 is configured to generate sales data based on the billing detail data and the desired payment date, without generating authorization data.

[0081] In addition, in normal card payments, the date on which direct debit is made by account transfer is determined according to the sales date. In normal cases, direct debit is made approximately one month at the earliest and approximately two months at the latest. In the present invention, the payment processing device 10 generates card sales data with the sales date set so that direct debit is made on the buyer's desired payment date and as long as a guarantee can be provided.

[0082] The payment processor 10 changes the status 605 of the billing detail data associated with the card sales data and the status 509 of the billing data associated with that billing detail data to "card payment." For billing data and billing detail data with a status of "card payment," the account transfer process as described with reference to Figure 7 is not executed, and the settlement amount is debited from the buyer's account on the credit card payment date, i.e., the desired payment date.

[0083] Through the above-described process, the credit card company managing the payment processing system 15 makes an advance payment to the supplier, allowing the supplier to receive the funds on the originally scheduled payment date, while the buyer can postpone the originally scheduled payment date to a desired payment date by selecting credit card payment.

[0084] Although the principles of the present invention have been described above with reference to exemplary embodiments, it will be understood by those skilled in the art that various embodiments that change in configuration and details can be realized without departing from the gist of the present invention. That is, the present invention can be embodied as, for example, a system, an apparatus, a method, a program, or a storage medium. [Explanation of symbols]

[0085] 10 Payment processing device 11 Supplier terminal 12 Buyer terminal 13. Direct Debit System 14. Finance System 15 Deposit Processing System 16 The First Banking System 17 The Second Banking System 21 The First Network 22 The Second Network 101 Control section 102 Main memory 103 Auxiliary storage 104 Interface (IF) section 105 Output section 106 User Master 107 Contract / Payment Information 108 Billing Data 109 Billing details data 1000 Early Funding Request Screen 1100, 1300 trial calculation result display screen 1200 Payment deferral request screen

Claims

1. A payment processing device including a communication unit for communicating with an external network, a storage unit, and a control unit, The storage unit stores billing data and billing detail data indicating a transaction result between a first user and a second user, The control unit is receiving a financing application associated with card payment from a second user terminal via the communication unit; generating a deposit request for depositing money into the account of the first user on a scheduled payment date registered in first billing detail data associated with the financing application; generating a guarantee offer associated with the financing offer; generating card sales data in which a sales date is set such that an account transfer process based on the first billing detail data is executed on a desired payment date associated with the financing application; A payment processor that executes the above.

2. The payment processing device according to claim 1 , wherein the control unit generates the card sales data without generating authorization data.

3. The control unit is receiving a financing request including the first billing detail data for which payment deferral by card payment is desired and the desired payment date from the second user terminal via the communication unit; generating and transmitting a request for estimate based on the financing request; receiving an estimate result in response to the estimate request and providing the estimate result to the second user terminal; receiving the financing application as a response to the trial calculation result from the second user terminal via the communication unit; The payment processing device of claim 1 ,

4. The control unit provides a plurality of candidates based on a payment date of a card associated with the second user to the second user terminal via the communication unit; the desired payment date is a payment date selected by a second user from among the plurality of candidates; The payment processing device of claim 1.

5. 1. A method performed by a payment processor, comprising: The payment processing device includes a communication unit for communicating with an external network, a storage unit, and a control unit, The storage unit stores billing data and billing detail data indicating a transaction result between a first user and a second user, The method comprises: receiving a financing application associated with card payment from a second user terminal via the communication unit; generating a deposit request for depositing money into the account of the first user on a scheduled payment date registered in first billing detail data associated with the financing application; generating a guarantee offer associated with the financing offer; generating card sales data in which a sales date is set such that an account transfer process based on the first billing detail data is executed on a desired payment date associated with the financing application; A method for providing the above.

6. A program for causing a computer to execute the method according to claim 5.

Images