Refund system and refund method

Abstract

To provide a refund system and a refund method that can improve refund responsiveness while achieving high security and low risk. [Solution] A refund system comprising a user terminal, a merchant terminal, a refund management service server, and a refund smart contract, wherein the user terminal sends a refund request to the refund management service server via the merchant terminal, and if the refund amount is less than or equal to a first threshold, the refund management service server generates information to be signed and sends it to the merchant terminal, the merchant terminal signs the information to be signed and generates a merchant signature, the refund management service server signs the information to be signed, generates a server signature, generates a transaction command based on the merchant signature and the server signature, and constructs a refund transaction based on the transaction command, and the refund smart contract refunds the amount to the user terminal according to the refund transaction.

Description

[Technical Field]

[0001] The present invention relates to a refund system and a refund method. [Background technology]

[0002] Patent Document 1 discloses a trading system that uses a blockchain. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2020-129752 Summary of the Invention [Problem to be solved by the invention]

[0004] In the transaction system described in Patent Document 1, the blockchain performs refunds based on the signed transaction information that has been sent, so refunds are made fully automatically and the responsiveness of refunds can be improved, but the risks associated with large refunds cannot be reduced.

[0005] Therefore, the present invention has been made with an eye on this problem, and aims to provide a refund system and refund method that can improve refund responsiveness while achieving high security and low risk. [Means for solving the problem]

[0006] According to one aspect of the present invention, there is provided a refund system comprising a user terminal, a merchant terminal, a refund management service server, and a refund smart contract, wherein the user terminal transmits a refund request to the merchant terminal, the merchant terminal transmits the request to the refund management service server, the refund management service server determines whether a refund amount included in the request is equal to or less than a first threshold, and if the refund amount is equal to or less than the first threshold, generates information to be signed and transmits it to the merchant terminal, and the merchant terminal signs the information to be signed using a private key. A refund system is provided in which a merchant signature is generated and sent to the refund management service server, the refund management service server generates a server signature by signing the information to be signed using another private key, generates a transaction command based on the merchant signature and the server signature, calls a refund execution function of the refund smart contract, and constructs a refund transaction by introducing the transaction command and the refund amount into the refund execution function, and the refund smart contract refunds the refund amount included in the request to the user terminal in accordance with the refund transaction.

[0007] According to another aspect of the present invention, there is provided a refund method including: a user terminal sending a refund request to a merchant terminal; the merchant terminal sending the request to a refund management service server; the refund management service server determining whether a refund amount included in the request is less than or equal to a first threshold, and if the refund amount is less than or equal to the first threshold, generating information to be signed and sending it to the merchant terminal; the merchant terminal signing the information to be signed using a private key to generate a merchant signature and sending it to the refund management service server; the refund management service server signing the information to be signed using another private key to generate a server signature, generating a transaction command based on the merchant signature and the server signature, calling a refund execution function of a refund smart contract, and constructing a refund transaction to input the transaction command and the refund amount into the refund execution function; and the refund smart contract refunding the refund amount included in the request to the user terminal in accordance with the refund transaction. [Effects of the Invention]

[0008] According to these aspects, it is possible to improve the responsiveness of refunds while achieving high security and low risk. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing the configuration of a refund system according to this embodiment. [Figure 2] FIG. 2 is a sequence diagram showing the processing performed by the refund system according to this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention (hereinafter referred to as the present embodiment) will be described below with reference to the accompanying drawings. In this specification, the same elements are designated by the same reference numerals throughout.

[0011] (Refund system) First, a refund system 100 according to this embodiment will be described with reference to FIG.

[0012] FIG. 1 is a block diagram showing the configuration of a refund system 100 according to this embodiment.

[0013] As shown in Figure 1, the refund system 100 according to this embodiment includes a user terminal 1, a provider terminal 2, a refund management service server 3, a refund smart contract 4, a blockchain network 5, and a wallet 6. The user terminal 1, provider terminal 2, refund management service server 3, blockchain network 5 (refund smart contract 4), and wallet 6 are connected to each other via a network 7 so that they can communicate with each other.

[0014] Here, the user terminal 1 and the provider terminal 2 are configured by electronic devices such as a PC, smartphone, or tablet. The refund management service server 3 is for managing refunds. The refund smart contract 4 is created by a person or AI and is operated on a blockchain network 5. The wallet 6 is for receiving the amount paid by the user. As will be described later, although the wallet 6 can charge the refund smart contract 4, there is no flow of money from the refund smart contract 4 to the wallet 6.

[0015] (Refund method) Next, the refund method (process) by the refund system 100 will be described in detail with reference to FIG.

[0016] FIG. 2 is a sequence diagram showing the processing performed by the refund system 100 according to this embodiment.

[0017] As shown in Fig. 2, first, in step S101, a user performs a refund operation on a merchant platform (e.g., an app or website) using the user terminal 1. Then, in response to the refund operation, the user terminal 1 generates a refund request (hereinafter simply referred to as a request) and sends it to the merchant terminal 2 (e.g., a PC, smartphone, or tablet), and proceeds to step S102. The request includes a payment transaction hash (hereinafter simply referred to as a txHash), a refund amount, etc.

[0018] In step S102, the merchant terminal 2 transmits the request and the merchant ID to the refund management service server 3, and then the process proceeds to step S103.

[0019] In step S103, the refund management service server 3 searches the blockchain network 5 based on the txHash to verify the authenticity of the payment transaction, the success of the payment, and that the payee is the relevant merchant, thereby verifying the payment transaction.

[0020] The refund management service server 3 then verifies that the refund amount is less than or equal to the payment amount. The refund management service server 3 then verifies whether the product is eligible for a refund and whether the timing of the refund is within the refundable period. This makes it possible to verify the reasonableness of the refund. The refund management service server 3 then verifies whether the txHash has already been used for a refund. This makes it possible to prevent duplicate refund requests.

[0021] The refund management service server 3 then determines whether the refund amount included in the request is equal to or less than a first threshold (i.e., a high-value threshold). If the refund amount is equal to or less than the first threshold (i.e., the refund amount is low), the refund management service server 3 generates information to be signed and sends it to the merchant terminal 2, and proceeds to step S104 (fully automated refund processing). On the other hand, if the refund amount is greater than the first threshold (i.e., the refund amount is high), the process proceeds to step S103a (i.e., manual refund processing by a refund management service staff member), and the refund processing by the refund system 100 is terminated. Note that a detailed description of the manual refund processing will be omitted.

[0022] This allows for improved refund responsiveness by allowing a small refund amount to be processed automatically, while allowing a large refund amount to be processed manually rather than automatically, reducing the risk of damage caused by fraudulent large refund requests.

[0023] In step S104, the refund management service server 3 generates a refund ID (i.e., RefundID) to ensure the uniqueness of the request. Note that the RefundID is expressed by the following formula: RefundID=SHA256(txHash+timestamp+nonce)

[0024] The refund management service server 3 then generates information to be signed, transmits the generated information to be signed to the agent terminal 2, and proceeds to step S105. The information to be signed includes the refund ID, the refund amount, the user address, etc.

[0025] In step S105, the merchant terminal 2 generates a merchant signature (i.e., merchantSig) by signing the information to be signed using a private key for multi-party computation (i.e., MPC / Multi-party computation), and transmits it to the refund management service server 3, and then proceeds to step S106. This makes it possible to prove that the merchant agrees to the refund.

[0026] In step S106, the refund management service server 3 generates a server signature (i.e., serverSig) by signing the merchant-signed information to be signed using another private key for multi-party computation. Then, the refund management service server 3 generates a transaction command (i.e., authorizationData) based on the merchant signature and the server signature, and proceeds to step S107.

[0027] In this way, both the merchant signature and the server signature (i.e., multi-party computation (MPC)) are used to generate the transaction command, thereby ensuring high security for the entire refund system 100.

[0028] In step S107, the refund management service server 3 calls the refund execution function (i.e., executeRefund) of the refund smart contract 4, constructs a refund transaction by introducing the user address, refund amount, refund ID and transaction command into the refund execution function, and proceeds to step S108.

[0029] In step S108, the refund smart contract 4 verifies whether the refund management service server 3 that called the refund execution function is the sole owner of the contract. The refund smart contract 4 then verifies whether the refund ID has been used. This prevents duplicate refund requests. The refund smart contract 4 then verifies whether both signatures in the transaction command are valid signatures of the user and the merchant, and proceeds to step S109. This ensures high security for the entire refund system 100.

[0030] In step S109, if all information is verified in step S108 (i.e., each verification in step S108 is Yes), the refund smart contract 4 refunds the stable currency as the refund amount to the user terminal 1 (i.e., a user address accessible by the user terminal 1) and proceeds to step S110.

[0031] In step S110, the refund smart contract 4 marks the refund ID as processed and proceeds to step S111.

[0032] In step S111, the refund smart contract 4 detects (i.e., monitors) the remaining balance of the refund smart contract 4 and determines whether the detected remaining balance is smaller than a second threshold (minBalance). If the remaining balance is smaller than the second threshold (i.e., if it is determined that charging the refund smart contract 4 from the wallet 6 is necessary), the process proceeds to step S112. On the other hand, if the remaining balance is equal to or greater than the second threshold (i.e., if it is determined that charging the refund smart contract 4 from the wallet 6 is not necessary), the process skips steps S112 to S116 and proceeds to step S117.

[0033] The second threshold is equal to or greater than the first threshold. This ensures that the refund smart contract 4 executes the refund when it is determined that the refund amount is small and charging the refund smart contract 4 from the wallet 6 is unnecessary.

[0034] In step S112, the refund smart contract 4 sends a warning to the refund management service server 3 that the balance is less than the second threshold, and then proceeds to step S113.

[0035] In step S113, the refund management service server 3 counts the number of warnings within a predetermined time (e.g., one hour) and determines whether the counted number of warnings reaches a predetermined number (e.g., three). If the number of warnings does not reach the predetermined number, the process proceeds to step S114. On the other hand, if the number of warnings reaches the predetermined number, the process skips steps S114 and S115 and proceeds to step S116.

[0036] In step S114, the refund management service server 3 determines that there is no abnormality, generates a charge command to execute a charge to the refund smart contract 4 from the wallet 6, sends the generated charge command to the wallet 6, and proceeds to step S115.

[0037] In step S115, the wallet 6 charges the refund smart contract 4 based on the charge command so that the amount of the refund smart contract 4 becomes a predetermined amount, and then proceeds to step S117.

[0038] This reduces the risk of compromising the wallet 6, as refunds to users are not executed directly from the wallet 6, but from a refund smart contract 4 that can be charged from the wallet 6.

[0039] In addition, if it is determined that there is no abnormality, automatic charging from the wallet 6 to the refund smart contract 4 can be easily achieved, thereby further improving the responsiveness of refunds.

[0040] The predetermined amount is set to the largest cumulative amount of refunds on a single day within a predetermined period (for example, the last month or last week). This allows the predetermined amount to be set appropriately.

[0041] Charging the refund smart contract 4 from the wallet 6 is executed by signing the MPC service. The two share keys required for signing the MPC service are stored in the HSM (i.e., Hardware Security Module) and the cloud terminal, respectively. This further enhances the security of the entire refund system 100.

[0042] In step S116, the refund management service server 3 determines that an abnormality exists, does not generate a charge command to charge the refund smart contract 4 from the wallet 6, does not send the charge command to the wallet 6, and proceeds to step S117. As a result, the refund management service server 3 prevents charging the refund smart contract 4 from the wallet 6. This makes it possible to prevent funds from being consumed by a potential attack when it is determined that an abnormality exists.

[0043] In step S117, the refund smart contract 4 generates information indicating that the refund has been executed (i.e., RefundExecuted), transmits the generated information to the refund management service server 3, and then proceeds to step S118.

[0044] In step S118, the refund management service server 3 generates information indicating that the refund has been completed (hereinafter simply referred to as "refund completion information") based on the information indicating that the refund has been executed (i.e., RefundExecuted), and transmits the generated refund completion information to the user terminal 1, thereby completing the entire refund process. This allows the user to easily understand that the refund has been completed.

[0045] (Action and effect) Next, the effects of the above-described embodiment will be described.

[0046] The refund system 100 according to the embodiment described above is a refund system including a user terminal 1, a merchant terminal 2, a refund management service server 3, and a refund smart contract 4. The user terminal 1 sends a refund request to the merchant terminal 2, which then sends the request to the refund management service server 3. The refund management service server 3 determines whether the refund amount included in the request is equal to or less than a first threshold. If the refund amount is equal to or less than the first threshold, the merchant terminal 2 generates information to be signed and sends it to the merchant terminal 2. The merchant terminal 2 then uses a private key to The refund management service server 3 generates a merchant signature by signing the information to be signed with another private key and sends it to the refund management service server 3. The refund management service server 3 generates a server signature by signing the information to be signed with another private key, generates a transaction command based on the merchant signature and the server signature, calls the refund execution function of the refund smart contract 4, and constructs a refund transaction by introducing the transaction command and the refund amount into the refund execution function. The refund smart contract 4 refunds the refund amount included in the request to the user terminal 1 in accordance with the refund transaction.

[0047] In addition, the refund method according to the above-described embodiment includes the following steps: the user terminal 1 sends a refund request to the agent terminal 2; the agent terminal 2 sends the request to the refund management service server 3; the refund management service server 3 determines whether the refund amount included in the request is equal to or less than a first threshold, and if the refund amount is equal to or less than the first threshold, generates information to be signed and sends it to the agent terminal 2; the agent terminal 2 signs the information to be signed using its private key, thereby generating an agent signature and sending it to the refund management service server 3; the refund management service server 3 signs the information to be signed using another private key, thereby generating a server signature, generating a transaction command based on the agent signature and the server signature, calling the refund execution function of the refund smart contract 4, and constructing a refund transaction by inputting the transaction command and the refund amount into the refund execution function; and the refund smart contract 4 refunds the refund amount included in the request to the user terminal 1 according to the refund transaction.

[0048] According to these configurations, if the refund amount is low, the responsiveness of the refund can be improved by proceeding to automatic refund processing, while if the refund amount is high, the risk of damage due to fraudulent requests for large refunds can be reduced by proceeding to manual refund processing rather than automatic refund processing.

[0049] Furthermore, since both the merchant signature and the server signature (i.e., multi-party computation (MPC)) are used to generate the transaction command, the refund system 100 as a whole can be made highly secure.

[0050] In addition, in this embodiment, the refund system 100 further includes a wallet 6, and the refund smart contract 4 detects the remaining balance of the refund smart contract 4 and determines whether the remaining balance is smaller than a second threshold. If the remaining balance is smaller than the second threshold, the wallet 6 charges the refund smart contract 4 so that the amount of the refund smart contract 4 becomes a predetermined amount.

[0051] According to this configuration, refunds to users are not executed directly from the wallet 6, but from a refund smart contract 4 that can be charged from the wallet 6, thereby reducing the risk of exposing the wallet 6 to risk.

[0052] In addition, when the remaining balance is smaller than the second threshold, automatic charging from the wallet 6 to the refund smart contract 4 can be easily achieved, thereby further improving the responsiveness of refunds.

[0053] In addition, in this embodiment, the refund smart contract 4 sends a warning to the refund management service server 3 when the remaining balance is smaller than the second threshold, and the refund management service server 3 determines whether the number of warnings reaches a predetermined number within a predetermined time, and if the number of warnings reaches the predetermined number, prevents the wallet 6 from charging the refund smart contract 4, and if the number of warnings does not reach the predetermined number, the wallet 6 charges the refund smart contract 4 so that the amount of the refund smart contract becomes the predetermined amount.

[0054] According to this configuration, when the number of warnings reaches a predetermined number (i.e., when it is determined that an abnormality exists), it is possible to prevent the consumption of funds due to a potential attack. On the other hand, when the number of warnings does not reach the predetermined number (i.e., when it is determined that no abnormality exists), it is possible to easily realize automatic charging from the wallet 6 to the refund smart contract 4, thereby further improving the responsiveness of refunds.

[0055] In this embodiment, the second threshold is equal to or greater than the first threshold.

[0056] According to this configuration, if the refund amount is low and it is determined that charging the refund smart contract 4 from the wallet 6 is not necessary, the refund can be executed by the refund smart contract 4.

[0057] In addition, in this embodiment, the refund management service server 3 transmits information indicating the completion of refund to the user terminal 1 when the remaining balance is equal to or greater than the second threshold, when charging has been performed, or when charging has been prevented.

[0058] This configuration allows the user to easily understand that the refund has been completed.

[0059] In addition, in this embodiment, charging the refund smart contract 4 from the wallet 6 is executed by signing the MPC service.

[0060] This configuration allows the refund system 100 as a whole to have a higher level of security.

[0061] The present embodiment has been described above, but the above-described embodiment merely illustrates some of the application examples of the present invention, and is not intended to limit the technical scope of the present invention to the specific configurations of the above-described embodiment. [Explanation of symbols]

[0062] 1. User terminal 2. Vendor terminal 3. Refund Management Service Server 4. Refund Smart Contract 5. Blockchain Network 6. Wallet 100 Refund System

Claims

1. A refund system comprising a user terminal, a merchant terminal, a refund management service server, and a blockchain network having a refund smart contract, The user terminal sends a refund request to the merchant terminal; The vendor terminal transmits the request to the refund management service server; the refund management service server determines whether the refund amount included in the request is equal to or less than a first threshold, and if the refund amount is equal to or less than the first threshold, generates information to be signed, the information including the user address, the refund ID, and the refund amount, and transmits the information to the merchant terminal; the merchant terminal generates a merchant signature by signing the information to be signed using a private key, and transmits the generated signature to the refund management service server; The refund management service server generates a server signature by signing the information to be signed with another private key, generates a transaction command based on the merchant signature and the server signature, calls a refund execution function of the refund smart contract, constructs a refund transaction, and sends it to the refund smart contract, so as to input the transaction command, the refund amount, the refund ID, and the user address into the refund execution function; In response to the refund transaction, the refund smart contract verifies that a refund ID has not been used, verifies that the merchant signature and the server signature attached to the transaction command are valid signatures, and refunds the refund amount included in the request to the user terminal corresponding to the user address. Refund system.

2. With a wallet, The refund smart contract detects a balance of the refund smart contract, determines whether the balance is less than a second threshold, and sends a warning to the refund management service server if the balance is less than the second threshold; The refund management service server determines whether the number of warnings reaches a predetermined number within a predetermined time based on the warnings sent from the refund smart contract, and if the number of warnings reaches the predetermined number, prevents charging from the wallet to the refund smart contract, and if the number of warnings does not reach the predetermined number, generates a charging command and sends it to the wallet; The wallet charges the refund smart contract based on the charge command sent from the refund management service server so that the amount of the refund smart contract becomes a predetermined amount. The refund system of claim 1 .

3. the second threshold is equal to or greater than the first threshold; The refund system according to claim 2 .

4. the refund management service server transmits information indicating the completion of the refund to the user terminal when the remaining balance is equal to or greater than the second threshold, when the charge has been made, or when the charge has been prevented; The refund system according to claim 2 .

5. The charging of the refund smart contract from the wallet is performed by signing into the MPC service. The refund system according to claim 2 .

6. A refund method executed in a refund system including a user terminal, a merchant terminal, a refund management service server, and a blockchain network having a refund smart contract, comprising: the user terminal sending a refund request to the merchant terminal; the vendor terminal sending the request to the refund management service server; The refund management service server determines whether the refund amount included in the request is equal to or less than a first threshold, and if the refund amount is equal to or less than the first threshold, generates information to be signed, which includes a user address, a refund ID, and the refund amount, and transmits the information to the merchant terminal; The merchant terminal uses a private key to sign the information to be signed, thereby generating a merchant signature and transmitting the signature to the refund management service server; The refund management service server uses another private key to sign the information to be signed to generate a server signature, generate a transaction command based on the merchant signature and the server signature, call a refund execution function of the refund smart contract, and construct and send a refund transaction to the refund smart contract, such that the transaction command, the refund amount, the refund ID, and the user address are input into the refund execution function; The refund smart contract verifies, in response to the refund transaction, that a refund ID is not used, verifies that the merchant signature and the server signature attached to the transaction command are valid signatures, and refunds the refund amount included in the request to the user terminal corresponding to the user address. Refund methods.

Images