A payment method, platform and system based on digital currency

Abstract

The application discloses a payment method, platform and system based on digital currency, and relates to the technical field of computers. A specific implementation manner of the method comprises the following steps: receiving a target payment request for a first digital currency in a frozen state, wherein the first digital currency in the frozen state is generated by a prepayment deposit smart contract based on a prepayment request; generating a second digital currency according to a target payment amount indicated by the target payment request, the first digital currency, a preconfigured prepayment cancellation smart contract and a digital currency balance of a first account corresponding to the first digital currency, wherein the second digital currency is in an available state, and a denomination of the second digital currency is a sum of the target payment amount and the digital currency balance; and sending the second digital currency to the first account. The implementation manner improves transaction security and is beneficial to protecting the rights and interests of users.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a payment method, platform and payment system based on digital currency. Background Technology

[0002] Prepayment is a common payment scenario, such as pre-paid membership programs on various online electronic platforms, and pre-paid programs at offline fitness venues and training institutions.

[0003] In existing prepayment scenarios, the money prepaid by users is directly deposited into the service provider's account, regardless of whether the service provider has actually provided the service. The service provider can then directly use the prepaid money. This could result in users being unable to get a refund for their prepaid money if the service provider terminates the service before the user has finished using it. This reduces transaction security in prepayment scenarios and makes it difficult to protect user rights. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a payment method, platform, and system based on digital currency. This system, based on a pre-configured pre-payment deposit smart contract, freezes the first digital currency corresponding to the pre-payment amount, preventing the user initiating the pre-payment request and the service provider from using it. When a target payment request is received for the frozen first digital currency, the frozen first digital currency is cancelled according to the pre-payment cancellation smart contract. A second digital currency, now available, is generated based on the digital currency balance of the first account corresponding to the first digital currency. The face value of the second digital currency is the sum of the target payment amount indicated in the target payment request and the digital currency balance. The second digital currency is then sent to the first account corresponding to the service provider, allowing the service provider to use it. Thus, the pre-payment smart contract prevents the service provider from using the pre-paid digital currency in advance, improving transaction security in pre-payment scenarios. Furthermore, it can also revoke or cancel unused prepaid digital currency, returning it to the second account corresponding to the first user. This solves the problem that users cannot get a refund for prepaid currency in existing prepayment scenarios, thereby further improving the transaction security of prepayment scenarios and protecting user rights.

[0005] To achieve the above objectives, according to one aspect of the present invention, a payment method based on digital currency is provided.

[0006] When a digital currency-based payment method according to an embodiment of the present invention is applied to a payment platform, it includes:

[0007] Receive a target payment request for a first digital currency that is in a frozen state, the first digital currency being generated based on a pre-payment request and a pre-configured pre-payment deposit smart contract;

[0008] A second digital currency is generated based on the target payment amount indicated by the target payment request, the first digital currency, the pre-configured prepayment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency; wherein, the second digital currency is in an available state, and the face value of the second digital currency is the sum of the target payment amount and the digital currency balance;

[0009] Send the second digital currency to the first account.

[0010] Optionally, a new first digital currency in a frozen state is generated based on the difference between the first digital currency and the target payment amount, and the prepayment verification smart contract.

[0011] Optionally, the method further includes:

[0012] Upon receiving a cancellation request for the first digital currency, obtain the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request;

[0013] Upon obtaining the first signature information and the second signature information, the status of the first digital currency is set to available, and the first digital currency is sent to the second account.

[0014] Optionally, before receiving the target payment request for the first digital currency that is in a frozen state, the method further includes:

[0015] Receive a prepayment request from a first terminal, the prepayment request indicating a second account and a prepayment amount;

[0016] Based on the prepayment request, the third digital currency corresponding to the second account, and the pre-configured prepayment deposit smart contract, a first digital currency corresponding to the prepayment amount is generated, and the first digital currency is in a frozen state.

[0017] Optionally, the prepayment request may also be directed to the first account;

[0018] Write the prepayment deposit smart contract and / or the first account as fields of the first digital currency into the first digital currency.

[0019] Optionally, it can be determined whether the account indicated in this target payment request is the same as the first account;

[0020] If so, generate the second digital currency;

[0021] If not, reject the target payment request.

[0022] Optionally, the prepayment request further indicates a payment period and a payment amount corresponding to the payment period; the method further includes:

[0023] If the payment deadline is met at the current time, a second digital currency is generated based on the payment amount, the digital currency balance of the first account, and the prepayment verification smart contract, wherein the face value of the second digital currency is the sum of the payment amount and the digital currency balance.

[0024] Optionally, the prepayment verification smart contract can be written as a field of the new, frozen first digital currency into the first digital currency.

[0025] Optionally, if the cancellation request is a revocation request sent by the first terminal, it further includes:

[0026] Based on the pre-configured pre-payment cancellation smart contract, determine whether the first digital currency is revocable;

[0027] If so, obtain the first signature information and the second signature information;

[0028] If not, reject the revocation request.

[0029] Optionally, after generating the second digital currency, the process further includes:

[0030] Using its own third signature information, the first digital currency is signed, and based on the signed first digital currency, the second signature information, and the prepayment deposit smart contract, the first prepayment transaction information is generated and stored.

[0031] Optionally, the prepayment request may also indicate a scenario identifier and / or a business identifier;

[0032] The first prepayment transaction information is generated based on the first digital currency, the second signature information, the prepayment deposit smart contract, and the scenario identifier and / or business identifier.

[0033] Optionally, if the target payment request also indicates a scenario identifier and / or a business identifier, it further includes:

[0034] Determine whether the scenario identifier and / or business identifier indicated in the current target payment request are the same as the scenario identifier and / or business identifier indicated in the first prepayment transaction information;

[0035] If so, generate the second digital currency;

[0036] If not, reject the target payment request.

[0037] Optionally, it also includes:

[0038] Determine whether the target payment request includes the signature information of the sender of the target payment request; if so, generate the second digital currency.

[0039] Optionally, it also includes:

[0040] The second prepayment transaction information is generated based on the prepayment verification smart contract, the signature information of the sending end, its own third signature information, and the difference between the first digital currency and the target payment amount.

[0041] Optionally, generating a first digital currency corresponding to the prepayment amount based on the prepayment request, the third digital currency corresponding to the second account, and a pre-configured prepayment deposit smart contract includes:

[0042] Determine the third digital currency in the second account and the available denominations of the third digital currency;

[0043] Based on the available denomination and the amount of the prepayment, the generation method of the first digital currency is determined, and the first digital currency corresponding to the prepayment amount is generated according to the generation method.

[0044] Optionally, when the available face value is greater than the prepayment amount, the generation method is determined to be splitting the third digital currency;

[0045] The third digital currency is split into the first digital currency and the fourth digital currency. The sum of the face value of the first digital currency and the face value of the fourth digital currency is equal to the available face value, and the fourth digital currency is in an available state. The third digital currency is then cancelled.

[0046] Optionally, it also includes:

[0047] The first digital currency is frozen in the first account or the second account or payment platform corresponding to the prepayment request.

[0048] Optionally, it also includes:

[0049] If it is determined that the face value of the first digital currency is less than the target payment amount, a prepayment recovery prompt is sent to the first terminal that initiated the prepayment request.

[0050] Optionally, it also includes:

[0051] When a prepayment recovery request is received from the first terminal according to the prepayment recovery prompt, the system verifies whether the first account and the second account indicated by the prepayment recovery request are empty. If not, the system obtains the first signature information of the first account and the second signature information of the second account.

[0052] Upon obtaining the first signature information and the second signature information, a new first digital currency in a frozen state is generated based on the pre-configured prepayment recovery smart contract, the amount indicated by the prepayment recovery request, and the first digital currency.

[0053] Optionally, it also includes:

[0054] Received termination command;

[0055] Based on the termination instruction and the pre-configured pre-payment termination smart contract, the state of the first digital currency is set to an available state, and the first digital currency is sent to the second account corresponding to the pre-payment request; and

[0056] Send a prepayment termination notification message to the first terminal that initiated the prepayment request and the second terminal corresponding to the first account.

[0057] Optionally, the prepayment request is received via a frozen payment interface; further comprising:

[0058] When a first reverse transaction request is received through the frozen payment interface, the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request are obtained.

[0059] Upon obtaining the first signature information and the second signature information, the status of the first digital currency is set to available, and the first digital currency is sent to the second account.

[0060] Optionally, the target payment request is received via the unfreezing payment interface; it also includes:

[0061] When a second reverse transaction request is received through the unfreezing payment interface, the first signature information corresponding to the first account and the second signature information of the second account corresponding to the prepayment request are obtained.

[0062] Upon obtaining the first signature information and the second signature information, the second digital currency is cancelled, a fifth digital currency with a balance equal to that of the first digital currency is generated, and the first digital currency is updated according to the target payment amount.

[0063] Optionally, after generating the second digital currency, the method further includes: canceling the fifth digital currency corresponding to the digital currency balance of the first account.

[0064] To achieve the above objectives, according to another aspect of the present invention, a payment platform based on digital currency is provided.

[0065] An embodiment of the present invention provides a payment platform based on digital currency, comprising: a request receiving module, a verification module, and a currency sending module; wherein,

[0066] The request receiving module is used to receive a target payment request for a first digital currency that is in a frozen state. The first digital currency in the frozen state is generated based on a pre-payment request and a pre-configured pre-payment deposit smart contract.

[0067] The verification module is used to generate a second digital currency corresponding to the target payment amount based on the target payment amount indicated by the target payment request, the first digital currency, and a pre-configured pre-payment verification smart contract.

[0068] The currency sending module is used to send the second digital currency to the first account corresponding to the first digital currency.

[0069] To achieve the above objectives, according to another aspect of the present invention, a payment system based on digital currency is provided.

[0070] An embodiment of the present invention provides a payment system based on digital currency, comprising: any of the payment platforms described above and a first terminal; wherein the first terminal comprises: a prepayment request sending module, a frozen currency storage module, and a target payment request sending module;

[0071] The prepayment request sending module is used to generate a prepayment request in response to the first trigger and send the prepayment request to the payment platform; the prepayment request indicates the second account and the prepayment amount;

[0072] The frozen currency storage module is used to receive the first digital currency corresponding to the prepayment amount and store the first digital currency in a frozen state in the second account;

[0073] The target request sending module is used to generate a target payment request for the first digital currency in response to the second trigger, and send the target payment request to the payment platform.

[0074] Optionally, the first terminal generates the prepayment request and / or the target payment request based on the second signature information of the second account.

[0075] Optionally, in response to the payment platform's feedback on the pre-payment request and / or the target payment request, the first terminal sends the second signature information of the second account to the payment platform.

[0076] Optionally, the target request sending module is used to obtain a payment identifier or payment image corresponding to the first account to determine the first account, and generate the target payment request based on the first account and the second trigger.

[0077] Optionally, the first terminal further includes: a processing module; wherein,

[0078] The processing module is used to receive and display the pre-payment recovery prompt sent by the payment platform; when receiving recovery information input according to the pre-payment recovery prompt, it generates a pre-payment recovery request based on the first account and the second account included in the recovery information, and sends the pre-payment recovery request to the payment platform.

[0079] Optionally, the payment system further includes: a second terminal; wherein,

[0080] The second terminal is used to receive the second digital currency and store the second digital currency in the first account.

[0081] Optionally, the second terminal is configured to generate a target payment request for the first digital currency in response to a third trigger, and send the target payment request to the payment platform.

[0082] Optionally, the second terminal is configured to receive payment information regarding a prepayment recovery request sent by the payment platform, the payment information indicating a first account, a second account, and the amount indicated by the prepayment recovery request; verify the prepayment recovery request based on the payment information, and when the verification passes, send a first signature information corresponding to the first account to the payment platform.

[0083] To achieve the above objectives, according to another aspect of the present invention, an electronic device based on digital currency payment is provided.

[0084] An electronic device based on digital currency payment according to an embodiment of the present invention includes: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a digital currency payment method according to an embodiment of the present invention.

[0085] To achieve the above objectives, according to another aspect of the present invention, a computer-readable storage medium is provided.

[0086] An embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a payment method based on digital currency according to an embodiment of the present invention.

[0087] One embodiment of the above invention has the following advantages or beneficial effects: Based on a pre-configured pre-payment deposit smart contract, the first digital currency corresponding to the pre-payment amount can be frozen, preventing the user initiating the pre-payment request and the service provider from using it. When a target payment request is received for the frozen first digital currency, the frozen first digital currency is cancelled according to the pre-payment cancellation smart contract. A second digital currency, now available, is generated based on the digital currency balance of the first account corresponding to the first digital currency. The face value of the second digital currency is the sum of the target payment amount indicated in the target payment request and the digital currency balance. The second digital currency is then sent to the first account corresponding to the service provider, allowing the service provider to use it. Thus, the pre-payment smart contract prevents the service provider from using the pre-paid digital currency in advance, improving transaction security in pre-payment scenarios. Furthermore, unused pre-paid digital currency can be revoked or cancelled, returning it to the second account corresponding to the first user. This solves the problem of users being unable to get refunds for pre-paid currency in existing pre-payment scenarios, further improving transaction security and protecting user rights.

[0088] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0089] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0090] Figure 1 This is a schematic diagram illustrating the main steps of a payment method based on digital currency according to an embodiment of the present invention;

[0091] Figure 2 This is a schematic diagram of the main modules of a digital currency-based payment platform according to an embodiment of the present invention;

[0092] Figure 3 This is a schematic diagram of the main modules of a digital currency-based payment system according to an embodiment of the present invention;

[0093] Figure 4 This is a schematic diagram illustrating the main steps of another payment method based on digital currency according to an embodiment of the present invention;

[0094] Figure 5This is a schematic diagram of a digital currency generation process according to an embodiment of the present invention;

[0095] Figure 6 This is a schematic diagram illustrating the main steps of another payment method based on digital currency according to an embodiment of the present invention;

[0096] Figure 7 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0097] Figure 8 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0098] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0099] It should be noted that, unless otherwise specified, the embodiments of the present invention and the technical features thereof can be combined with each other.

[0100] Figure 1 This is a schematic diagram illustrating the main steps of a digital currency-based payment method applied to a payment platform according to an embodiment of the present invention.

[0101] like Figure 1 As shown, when a digital currency-based payment method of this invention is applied to a payment platform, it mainly includes the following steps:

[0102] Step S101: Receive a target payment request for a first digital currency that is in a frozen state, the first digital currency being generated based on a prepayment request and a pre-configured prepayment deposit smart contract.

[0103] In one embodiment of the present invention, a first digital currency can be generated based on a prepayment request and a pre-configured prepayment deposit smart contract as follows: receiving a prepayment request from a first terminal, the prepayment request indicating a second account and a prepayment amount; generating a first digital currency corresponding to the prepayment amount based on the prepayment request, a third digital currency corresponding to the second account, and a pre-configured prepayment deposit smart contract, wherein the first digital currency is in a frozen state.

[0104] When a user needs to make a prepayment, they can trigger the prepayment interface on the first terminal. The first terminal then responds to the user's trigger by generating a prepayment request, which specifies the second account and the prepayment amount. The second account is the user's account, and the prepayment amount corresponds to the amount to be deposited in this prepayment.

[0105] It is worth noting that in the embodiments of this invention, terms such as "first" and "second" do not constitute a limitation on the solution, nor do they have an absolute correspondence. For example, "first terminal" does not correspond to "first account." These terms are only used to distinguish different entities and to more clearly illustrate the embodiments of this invention. In the embodiments of this invention, a consumer corresponds to a user, their corresponding terminal is the first terminal, their corresponding account is the second account, and their corresponding signature information is the second signature information. The service provider's corresponding terminal is the second terminal, their corresponding account is the first account, and their corresponding signature information is the first signature information. Furthermore, in the embodiments of this invention, digital currency includes not only the legal digital currency issued by the central bank as commonly referred to, but can also apply to other electronic or digital forms of currency or assets, such as various electronic currencies, legal cryptocurrencies, and crypto assets.

[0106] When generating the first digital currency, the signature of the funding source is required. In one embodiment of the present invention, upon receiving the second signature information corresponding to the second account, the first digital currency corresponding to the prepayment amount is generated based on the prepayment deposit smart contract and the third digital currency in the second account, and the first account corresponding to the first digital currency is determined.

[0107] Specifically, the first digital currency can be generated by writing the prepayment deposit smart contract and / or the first account as fields of the first digital currency into the first digital currency, thereby determining the first account corresponding to the first digital currency. Furthermore, due to the mandatory nature of the prepayment deposit smart contract, the correspondence between the first digital currency and the first account cannot be changed.

[0108] Here, the source of funds is the second account corresponding to the first terminal that initiated the prepayment request. After receiving the second signature information corresponding to the second account, it indicates that the source of funds acknowledges that the prepayment amount indicated by the prepayment request can be frozen as prepayment digital currency corresponding to a specific account (first account). Under these circumstances, the first digital currency corresponding to the prepayment amount is generated according to the prepayment deposit smart contract and the third digital currency to ensure the transaction security of the prepayment process.

[0109] The second signature information is sent from the first terminal to the payment platform. It can be carried along with the pre-payment request, or it can be sent by the payment platform to the first terminal as feedback information after receiving the pre-payment request and preparing to generate the first digital currency. The first terminal then sends the second signature information to the payment platform based on this feedback. The second signature information can be the user's authentication information or the user's payment password, etc.

[0110] During this process, the value of the initial digital currency used as prepayment is not transferred to the service provider; it is merely locked by the prepayment deposit smart contract, meaning the initial digital currency is in a frozen state. Furthermore, the initial digital currency is generated according to the prepayment deposit smart contract. Due to the mandatory nature of the smart contract, the initial digital currency can only be used for payments to a specific service provider. That is, the first account (the service provider's account) corresponding to the initial digital currency is determined. Only when the initial digital currency is used to pay the first account can it be used by the user for normal payment.

[0111] Based on this, in one embodiment of the present invention, it is determined whether the account indicated by the target payment request is the same as the first account; if so, a second digital currency is generated according to the target payment amount indicated by the target payment request, the first digital currency, and the pre-configured pre-payment verification smart contract; if not, the target payment request is rejected.

[0112] In this embodiment, the payment platform only responds to the target payment request when the account indicated in the current target payment request is the same as the first account corresponding to the first digital currency determined by the prepayment deposit smart contract. According to the prepayment verification smart contract, it generates a second digital currency with a face value equal to the sum of the target payment amount and the digital currency balance of the first account. If the account indicated in the current target payment request is different from the first account, it indicates that the target payment request is not a request to use the prepaid first digital currency for the service provider stipulated in the prepayment deposit smart contract. In this case, the payment platform rejects the target payment request to ensure transaction security and protect the rights of the service provider.

[0113] In addition, in one embodiment of the present invention, after generating the first digital currency, the payment platform can also use its own third signature information to sign the first digital currency, and generate and store the first prepayment transaction information based on the signed first digital currency, the second signature information of the second account, and the prepayment deposit smart contract.

[0114] According to the aforementioned embodiment, the payment platform generates the first digital currency only after obtaining the second signature information corresponding to the second account. Here, after generating the first digital currency, the payment platform uses its own third signature information to sign the first digital currency, so as to generate the first prepayment transaction information based on the second signature information and the prepayment deposit smart contract. In the first prepayment transaction information, the prepayment balance can be recorded as the amount deposited in this prepayment process (the face value of the first digital currency), and the number of prepayment changes is 0.

[0115] In one embodiment of the present invention, the prepaid amount (first digital currency) can be used to pay a specific service provider; it can also be used to pay a specific merchant in a merchant set, such as a specific merchant on an e-commerce platform, or a specific merchant in a large supermarket; it can also be used to pay a specific merchant in a specific scenario, such as a specific merchant in a transportation scenario, or a specific merchant in an entertainment scenario.

[0116] When the prepayment amount is used to pay a specific merchant in a certain scenario, the prepayment request also indicates a scenario identifier and / or a business identifier; in this case, the payment platform can generate the first prepayment transaction information based on the first digital currency and the second signature information, the prepayment deposit smart contract, and the scenario identifier and / or business identifier.

[0117] The scenario identifier corresponds to a specific scenario, with different scenarios having different identifiers. For example, transportation and entertainment scenarios have different scenario identifiers. When the prepayment amount is used to pay a specific merchant in a scenario, the corresponding scenario identifier is included when the prepayment request is sent. This allows for easy verification of the target payment request's accuracy when using the prepayment amount (the frozen first digital currency), thus improving transaction security. Additionally, the business identifier can be the serial number corresponding to this prepayment process (i.e., this prepayment transaction). It can be sent to the payment platform along with the prepayment request from the first terminal, or it can be generated by the payment platform after receiving the prepayment request. In other words, the business identifier can be generated by either the first terminal or the payment platform.

[0118] When the payment platform generates the first prepayment transaction information, it does so not only based on the first digital currency, the first signature information, and the prepayment deposit smart contract, but also based on the scenario identifier and the business identifier. Therefore, the first prepayment transaction information not only records the prepayment balance as the amount deposited in this prepayment process (the face value of the first digital currency), and the number of prepayment changes as 0, but also records the corresponding scenario identifier and business identifier.

[0119] Understandably, after the payment platform generates the corresponding first pre-payment transaction information, it can send corresponding feedback information to the user's first terminal and the service provider's second terminal, so that the first or second terminal carries the correct information when sending the target payment request. For example, if the pre-payment request indicates a scenario identifier and / or a business identifier, the target payment request sent by the first or second terminal will also indicate the scenario identifier and / or business identifier.

[0120] In another embodiment of the present invention, the first digital currency can be generated in the following manner: determining the third digital currency in the second account and the available denomination of the third digital currency; determining the generation method of the first digital currency based on the available denomination and the amount of the prepayment, and generating the first digital currency corresponding to the prepayment amount according to the generation method.

[0121] In one embodiment of the present invention, when the available face value is greater than the prepayment amount, it is determined that the generation method is to split the third digital currency; then, when generating the first digital currency, the third digital currency can be split into the first digital currency and the fourth digital currency, the sum of the face value of the first digital currency and the face value of the fourth digital currency is equal to the available face value, and the fourth digital currency is in an available state, and the third digital currency is cancelled.

[0122] For example, if the available denomination of the third digital currency in the second account is 100, and the prepayment amount is 10, then the method for generating the requested first digital currency is to split the available digital currency. Here, the available third digital currency of 100 is split into a first digital currency of 10 and a fourth digital currency of 90. The denomination of the first digital currency is equal to the requested prepayment amount, and the first digital currency is frozen while the fourth digital currency is available. Simultaneously, the original third digital currency in the second account is cancelled, thus achieving the splitting of the original third digital currency into a frozen first digital currency and an available fourth digital currency.

[0123] In another embodiment of the present invention, when the available face value of the third digital currency in the second account is equal to the prepayment amount, the first digital currency is generated by identifying the third digital currency whose available face value is equal to the prepayment amount as the first digital currency. That is, the third digital currency whose available face value is equal to the prepayment is identified as the first digital currency.

[0124] When the payment platform determines that the second account contains multiple third digital currencies that are in an available state, and the available face value of the multiple third digital currencies is equal to the prepayment amount, it can select one of the multiple third digital currencies that is equal to the prepayment amount and identify it as the first digital currency.

[0125] The identification of digital currency primarily involves marking its status. For example, once a payment platform identifies a third digital currency with an available denomination equal to the pre-payment amount, it can mark the third digital currency as either "frozen" or "pre-payment." Identified digital currencies cannot be used for market circulation in other general scenarios, but only for specific pre-payment scenarios.

[0126] In addition, when there are multiple third digital currencies with available denominations less than the prepayment amount in the second account, the first digital currency can be generated by combining the multiple third digital currencies with available denominations less than the prepayment amount.

[0127] For example, when the payment platform determines that the third digital currency in the second account is available digital currency A and available digital currency B, where the available face value of available digital currency A is 2, the available face value of available digital currency B is 8, and the prepayment amount is 10, then available digital currency A and available digital currency B can be combined to generate the first digital currency.

[0128] Of course, the combined value of multiple third-party digital currencies with available denominations less than the prepayment amount may be greater than the prepayment amount. In other words, the sum of multiple available denominations may be greater than the prepayment amount. For example, when the payment platform determines that the available third-party digital currencies in the second account are available digital currency C and available digital currency D, where available digital currency C has an available denomination of 4, available digital currency D has an available denomination of 8, and the prepayment amount is 10, then the combined value of available digital currency C and available digital currency D is 12, which is greater than the prepayment amount of 10.

[0129] In this scenario, available digital currency C and available digital currency D can be combined to generate a digital currency with a face value of 12. Then, the digital currency with a face value of 12 can be split into digital currencies with a face value of 10 and digital currencies with a face value of 2. This splitting process is the same as splitting available digital currencies with a face value greater than the prepayment amount, and will not be repeated here. The digital currency with a face value of 10 is then designated as the first digital currency. Alternatively, digital currencies with a face value of 10 and digital currencies with a face value of 2 can be generated directly from available digital currency C and available digital currency D. Or, one or more of the third digital currencies can be split first, and then the split third digital currencies can be combined with other third digital currencies to generate the first digital currency corresponding to the prepayment amount. For example, available digital currency D can be split into digital currencies with a face value of 6 and digital currencies with a face value of 2, and then the digital currency with a face value of 6 can be combined with available digital currency D with a face value of 4 in the second account to generate the first digital currency corresponding to the prepayment amount of 10.

[0130] It is worth mentioning that the third digital currency in the second account may include both the third digital currency in an available state and the frozen digital currency in a frozen state. In this case, the frozen digital currency is a pre-generated pre-payment amount corresponding to the prior pre-payment request. Since the frozen digital currency can only be used in the specific pre-payment scenario corresponding to its pre-payment request, the first digital currency is generated only based on the third digital currency in an available state, that is, the first digital currency is generated based on the third digital currency in an available state in the second account.

[0131] After the first digital currency is generated, the first digital currency in the frozen state can remain frozen in the second account. That is to say, the first digital currency generated according to the prepayment deposit smart contract is still stored in the consumer's second account. Its value has not been transferred to the service provider, but is only locked by the prepayment deposit smart contract, so that the first digital currency can only be consumed at the service provider corresponding to the prepayment, that is, it can only be used to transfer to a specific first account.

[0132] Of course, the first digital currency in a frozen state can also be frozen in the first account (the account corresponding to the service provider) or other third parties (such as payment platforms or other trusted third parties). It is understandable that even if the first digital currency is frozen in the first account, that is, stored in the service provider's account, because the first digital currency is frozen, the service provider cannot use it at will, thus ensuring transaction security and protecting consumer rights.

[0133] Step S102: Generate a second digital currency based on the target payment amount indicated by the target payment request, the first digital currency, the pre-configured prepayment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency; wherein, the second digital currency is in an available state, and the face value of the second digital currency is the sum of the target payment amount and the digital currency balance.

[0134] In this embodiment of the invention, upon responding to a target payment request, a second digital currency usable by the service provider is directly generated based on the target payment amount and the digital currency balance in the service provider's first account. This second digital currency is in an available state, allowing the service provider to apply it to general payment scenarios. The digital currency balance in the first account corresponds to the digital currency balance in the second terminal, which is also the service provider's digital currency balance. It can be understood that this digital currency balance corresponds to the face value of the available digital currency in the second terminal. When multiple available digital currencies exist in the second terminal, the digital currency balance in the first account is the sum of the face values ​​of these multiple available digital currencies. When only one available digital currency exists in the second terminal, the digital currency balance in the first account is the face value of that available digital currency.

[0135] When generating the second digital currency, it is directly based on the digital currency balance in the first account, that is, based on the digital currency that is available in the second terminal. Specifically, the payment platform can cancel the digital currency that is available in the second terminal and generate the second digital currency based on the sum of the face value of the available digital currency and the target payment amount. For example, if the sum of the face values ​​of the available digital currency in the service provider's second terminal (the digital currency balance in the first account) is 100, the target payment amount is 10, and the face value of the first digital currency that is frozen is 30, when responding to the target payment request, the face value of the generated second digital currency is 110. Furthermore, the payment platform will also generate a new first digital currency with a face value of 20 based on the target payment amount. The new first digital currency is still frozen, and the fifth digital currency corresponding to the original digital currency balance of 100 in the second terminal will be canceled.

[0136] According to the foregoing embodiments, when the prepayment request indicates a scenario identifier and / or a business identifier, the target payment request sent by the first terminal or the second terminal will also indicate a scenario identifier and / or a business identifier. In this case, since the prepayment amount is used for payment to a merchant in a specific scenario, the scenario identifier will be verified; or, if the prepayment amount does not specify a specific scenario, then only the corresponding business identifier will be verified. In this embodiment, it can be determined whether the scenario identifier and / or business identifier indicated by the target payment request are the same as the scenario identifier and / or business identifier indicated by the first prepayment transaction information; if so, a second digital currency is generated based on the target payment amount indicated by the target payment request, the first digital currency, the pre-configured prepayment reconciliation smart contract, and the digital currency balance of the first account corresponding to the first digital currency, and a second digital currency corresponding to the target payment amount is generated; if not, the target payment request is rejected.

[0137] Here, when the first pre-payment transaction information includes a scenario identifier and a business identifier, if the scenario identifier and business identifier carried in the target payment request are the same as those in the first pre-payment transaction information, then a second digital currency can be generated based on the target payment request; otherwise, the payment platform directly rejects the target payment request, meaning there is no need to generate a second digital currency based on the target payment request. Alternatively, when the first pre-payment transaction information includes a business identifier, if the business identifier carried in the target payment request is the same as those in the first pre-payment transaction information, then a second digital currency can also be generated based on the target payment request; otherwise, the payment platform directly rejects the target payment request, meaning there is no need to generate a second digital currency based on the target payment request. Or, when the first pre-payment transaction information includes a scenario identifier, if the scenario identifier carried in the target payment request is the same as those in the first pre-payment transaction information, then a second digital currency can also be generated based on the target payment request; otherwise, the payment platform directly rejects the target payment request, meaning there is no need to generate a second digital currency based on the target payment request.

[0138] In one embodiment of the present invention, when generating the second digital currency, the payment platform also determines whether the target payment request includes the signature information of the sender of the target payment request. If so, the second digital currency is generated.

[0139] The target payment request can be initiated by the first terminal or the second terminal. That is, the target payment request can be initiated by the consumer or the service provider. Therefore, the sending end of the target payment request can be either the first terminal or the second terminal.

[0140] When the sender of the target payment request is the first terminal, the signature information of the sender becomes the second signature information of the second account. When generating the second digital currency, it is essential to obtain the second signature information to verify the user's authentication of the pre-paid amount. Alternatively, if the sender is the first terminal, the payment platform can also obtain the first signature information from the second terminal to obtain authentication from the service provider regarding the availability of the service.

[0141] When the sender of the target payment request is a second terminal, the signature information of the sender is the first signature information of the first account. The payment platform then determines the service provider that can provide the corresponding service based on the first signature information. In addition, the payment platform also needs to obtain the second signature information from the first terminal to obtain the user's authentication of the pre-payment amount used this time.

[0142] After obtaining the signature information of the sender of the target payment request and generating the second digital currency, in one embodiment of the present invention, the second prepayment transaction information can be generated based on the prepayment verification smart contract, the signature information of the sender, its own third signature information, and the difference between the first digital currency and the target payment amount.

[0143] Here, when using prepayment amounts, the first prepayment transaction information corresponding to the target payment request can be found based on the business identifier, scenario identifier, first account, and / or second account information carried in the target payment request. Then, based on the prepayment reconciliation smart contract, the first digital currency corresponding to the first prepayment transaction information, and the digital currency balance of the first account, a second digital currency is generated. The process of generating the second digital currency can be as follows: a new second digital currency is generated based on the sum of the digital currency balance of the first account and the target payment amount, and a fifth digital currency corresponding to the digital currency balance in the first account is cancelled. This new second digital currency is in an available state, allowing the service provider to conduct other transactions based on it. Furthermore, the payment platform will also generate a new first digital currency based on the difference between the first digital currency and the target payment amount.

[0144] In other words, in one embodiment of the present invention, each time a target payment request for the first digital currency is received, a new first digital currency in a frozen state can be generated based on the difference between the first digital currency and the target payment amount, and the pre-payment verification smart contract. The new first digital currency in a frozen state can be used for the next pre-payment scenario.

[0145] Alternatively, in one embodiment of the present invention, a prepayment period can be agreed upon, and prepayment can be made on schedule according to the prepayment period. In this case, the prepayment request also indicates the payment period and the payment amount corresponding to the payment period. If the payment period is found to be met at the current time, a second digital currency is generated based on the payment amount, the digital currency balance of the first account, and the prepayment reconciliation smart contract. The face value of the second digital currency is the sum of the payment amount and the digital currency balance.

[0146] For example, if a prepayment request indicates a monthly payment period with a corresponding payment amount of 1, then when the payment platform detects that the interval between the current time and the receipt time of the prepayment request is one month, it will generate a new, available second digital currency and a new, frozen first digital currency based on the first digital currency currently in a frozen state. For instance, if the frozen first digital currency is 8 and the available balance of the first account is 10, the generated second digital currency will have a face value of 11, and the generated new first digital currency will have a face value of 7. Alternatively, if the prepayment request indicates a specific year, month, and day, and the current time meets the corresponding year, month, and day, the payment platform can generate a second digital currency based on the frozen first digital currency.

[0147] After the second digital currency is generated, the original first prepayment transaction information can no longer represent the current payment status. Therefore, a second prepayment transaction information can be generated based on the prepayment reconciliation smart contract, the first signature information and / or the second signature information, the payment platform's own third signature information, and the new first digital currency. The prepayment balance in the second prepayment transaction information has been reduced by the amount of this payment (target payment amount), that is, the prepayment amount in the second prepayment transaction information is the difference between the first digital currency and the target payment amount (the face value of the new first digital currency), and the prepayment change count in the second prepayment transaction information is updated to 1. After generating the second prepayment transaction information, the payment platform also records the original first prepayment transaction information as invalid.

[0148] Understandably, when the platform receives another target payment request corresponding to the same prepayment scenario, it can find the currently valid second prepayment transaction information and respond to the target payment request based on the first digital currency in the second prepayment transaction information to complete the prepayment. Afterwards, it will continue to update the second prepayment transaction information. This update operation is essentially the same as the operation of replacing the first prepayment transaction information with the second prepayment transaction information, and will not be elaborated further. In other words, each time a target payment request for prepayment digital currency is received, the platform responds to the target payment request based on the currently valid prepayment transaction information to complete the prepayment, and then updates the valid prepayment transaction information thereafter.

[0149] In addition, when generating a new first digital currency based on the prepayment verification smart contract, the prepayment verification smart contract can also be written as a field into the new first digital currency to ensure transaction security.

[0150] During continuous use, the remaining prepaid balance may be insufficient to fulfill the current target payment request; that is, the prepaid balance may be less than the target payment amount. In this case, the prepaid balance can be recovered according to a pre-configured prepaid recovery smart contract. In one embodiment of the present invention, when it is determined that the face value of the first digital currency is less than the target payment amount, a prepaid recovery prompt is sent to the first terminal that initiated the prepaid request. Thus, the user can be aware of the insufficient prepaid balance based on the prepaid recovery prompt displayed on the first terminal, and thereby initiate a corresponding prepaid recovery request through the first terminal.

[0151] When the payment platform receives a prepayment recovery request sent by the first terminal according to the prepayment recovery prompt, it verifies whether the first account and the second account indicated by the prepayment recovery request are empty. If not, it obtains the first signature information of the first account and the second signature information of the second account. If the first signature information and the second signature information are obtained, it generates a new first digital currency in a frozen state according to the pre-configured prepayment recovery smart contract, the amount indicated by the prepayment recovery request, and the first digital currency.

[0152] Here, when generating a new first digital currency that is in a frozen state, the prepayment recovery smart contract can also be written as a field into the new first digital currency.

[0153] The prepayment recovery smart contract is used to add recharge amounts to existing prepayment terms. Therefore, when initiating a prepayment recovery request, the user should input the second account (payment account) and the first account (receiving account) corresponding to the existing prepayment terms through the first terminal. Upon receiving the prepayment recovery request, the payment platform will verify whether the first and second accounts indicated in the request are empty. If either the first or second account is empty, the prepayment recovery request will be rejected. If the first and second accounts are not empty, the payment platform can also verify the recovery amount indicated in the prepayment recovery request. This recovery amount should be greater than or equal to 0. If the verification passes, the payment platform obtains the first and second signature information.

[0154] The second signature information can be sent to the payment platform along with the prepayment recovery request, or the payment platform can prompt the first terminal to enter it after verifying whether the first and second accounts are empty and the recovery amount. Alternatively, the first signature information can be prompted to the second terminal by the payment platform after verification. When the payment platform receives the second signature information, it indicates that the user has successfully authenticated the prepayment recovery request. Similarly, when the payment platform receives the first signature information, it indicates that the service provider confirms that it can continue to provide the corresponding service for the recovery request. Therefore, if the payment platform obtains both the first and second signature information, it means that both the payer and the service provider corresponding to the recovery request acknowledge the recovery. At this point, the payment platform generates new first digital currency based on the prepayment recovery smart contract, the amount indicated in the prepayment recovery request, the available digital currency in the second account, and the first digital currency corresponding to the current prepayment balance. This new first digital currency remains frozen.

[0155] Understandably, the face value of the new first digital currency is equal to the sum of the face value of the first digital currency generated after the last payment and the recovered amount. Through the prepayment recovery smart contract, the recovery of prepayment amounts is achieved. After recovery, the payment platform can also generate new prepayment transaction information to update the prepayment balance in the prepayment transaction information.

[0156] In addition, consumers or service providers can use the pre-configured prepayment query smart contract to query the prepayment balance based on information such as scenario identifier, business identifier, first account and second account, as well as the payment details data of the prepayment process. They can also sort and paginate the payment details data according to the order of reimbursement time.

[0157] Step S103: Send the second digital currency to the first account.

[0158] In one embodiment of the present invention, if the target payment request is a general payment operation, the second digital currency in an available state can be sent to the first account through the payment platform, that is, the second digital currency in an available state can be sent to the first account of the service provider, and the service provider can use the second digital currency in any digital currency payment scenario.

[0159] When generating the second digital currency, the payment platform also generates a new first digital currency based on the difference between the first digital currency and the target payment amount, as well as the prepayment verification smart contract. The new first digital currency is in a frozen state. The face value of the new first digital currency is the remaining prepayment amount after responding to the target payment request.

[0160] If a consumer or service provider needs to cancel the remaining prepaid amount for any reason, the consumer can send a cancellation request for the first digital currency to the payment platform via a first terminal, or the service provider can send a cancellation request via a second terminal. It is understood that the first digital currency referred to here is the first digital currency generated after the last payment. Upon receiving a cancellation request for the first digital currency, the payment platform obtains the first signature information of the first account and the second signature information of the second account corresponding to the prepaid request; having obtained both the first and second signature information, the platform sets the status of the first digital currency to available and sends the first digital currency to the second account.

[0161] If the payment platform obtains the first signature information and the second signature information, it means that both the consumer and the service provider agree to the cancellation operation for the current prepayment. At this time, the payment platform can restore the frozen first digital currency to a usable state and send the first digital currency to the second account to return the unused prepayment to the user (consumer), so that the user can use the prepayment for other general payment scenarios.

[0162] If the payment platform receives only one party's signature information, such as only the first signature information or the second signature information, it means that at least one party, the consumer or the service provider, does not agree to the cancellation operation for the current prepayment. In this case, the payment platform can act as a third party to verify the cancellation request and determine whether to respond to the cancellation request based on the verification result.

[0163] The cancellation request can be initiated by either the service provider or the consumer. For a cancellation request initiated by the consumer (i.e., when the cancellation request is sent by the first terminal), the payment platform can determine whether the first digital currency is revocable based on the pre-configured pre-payment cancellation smart contract. If so, it obtains the first signature information corresponding to the first account and the second signature information corresponding to the second account; otherwise, it rejects the cancellation request.

[0164] Here, if a prepayment is specified as a revocable contract when it is created, it can be revoked; otherwise, the contract cannot be revoked. In practice, the payment platform can query the prepayment revocation smart contract to determine if it is revocable. If not, the revocation request is rejected; if it is, after obtaining the first and second signature information, the funds are returned to the original payment method, and the prepayment balance is updated to 0. The platform can also notify the first and second terminals that the contract revocation has been completed and update the prepayment transaction information. Understandably, under normal prepayment usage—that is, after generating a second digital currency based on the target payment request and the first digital currency, and sending the second digital currency to the first account—the platform can also notify the first and second terminals of the amount consumed.

[0165] Alternatively, cancellation requests can be initiated by the service provider. For example, if the service provider cancels a consumer's prepaid service according to the terms of service, the payment platform, after obtaining the first and second signature information, will refund the funds to the original payment method and update the prepaid balance to 0. It can also notify the first and second terminals that the contract has been cancelled and update the prepaid transaction information.

[0166] Furthermore, service providers may forcibly shut down the services corresponding to prepayments due to internal transaction anomalies, business closures, or administrative orders. In such cases, the prepayment service must be terminated and the prepayment refunded. In this embodiment, the payment platform receives a termination instruction; based on the termination instruction and a pre-configured prepayment termination smart contract, it sets the status of the first digital currency to an available state and sends the first digital currency to the second account; and it sends a prepayment termination notification to the first terminal that initiated the prepayment request and the second terminal corresponding to the first account, notifying both terminals that the prepayment service has been terminated. Additionally, the payment platform can modify the prepayment transaction information based on the refunded funds, such as changing the prepayment balance to 0.

[0167] In one embodiment of the present invention, the payment platform may provide multiple interfaces to receive different requests, such as a freeze payment interface and an unfreeze payment interface. The freeze payment interface corresponds to operations such as deposit and recovery, while the unfreeze payment interface corresponds to operations such as write-off and cancellation.

[0168] In one embodiment of the present invention, the prepayment request is received through a frozen payment interface; when a first reverse transaction request is received through the frozen payment interface, the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request are obtained; when the first signature information and the second signature information are obtained, the status of the first digital currency is set to an available state, and the first digital currency is sent to the second account.

[0169] Here, the frozen payment interface can receive prepayment requests to enable the payment platform to perform deposit operations, and it can also receive a first reverse transaction request corresponding to the prepayment request. When responding to the first reverse transaction request, the flow of digital currency is reversed compared to the response process for the prepayment request. That is, in the process of responding to the first reverse transaction request, the state of the first digital currency is set to an available state, and the first digital currency is sent to the second account. For example, after a user initiates an erroneous prepayment request, they can initiate a first reverse transaction request to the business platform through a first terminal. After obtaining the first signature information and the second signature information, the payment platform can respond to the first reverse transaction request to return the first digital currency frozen according to the erroneous prepayment request.

[0170] Similarly, in one embodiment of the present invention, the target payment request is received through the unfreezing payment interface; when a second reverse transaction request is received through the unfreezing payment interface, the first signature information corresponding to the first account and the second signature information of the second account corresponding to the pre-payment request are obtained; upon obtaining the first signature information and the second signature information, the second digital currency is cancelled, a fifth digital currency with a balance equal to that of the digital currency is generated, and the first digital currency is updated according to the target payment amount.

[0171] The unfreezing payment interface can receive target payment requests to enable the payment platform to perform verification operations, and it can also receive a second reverse transaction request corresponding to the target payment request. When responding to the second reverse transaction request, the flow of digital currency is reversed compared to the response process of the target payment request. That is, in the process of responding to the second reverse transaction request, the second digital currency is cancelled, and a fifth digital currency equal to the digital currency balance of the first account is generated. Furthermore, based on the difference between the second and fifth digital currencies (the target payment amount) and the first digital currency, the first digital currency, which was in a frozen state, is regenerated. For example, after a user initiates an incorrect target payment request, they can initiate a second reverse transaction request to the business platform through the first terminal; or, due to an internal transaction error within the merchant, they can also initiate a second reverse transaction request to the business platform through the second terminal. After obtaining the first and second signature information, the payment platform can respond to the second reverse transaction request to cancel the new second digital currency generated based on the incorrect target payment request. For example, based on a target transaction request, the business platform generates a second digital currency with a face value of 15 (the target payment amount is 3, and the digital currency balance in the first account is 12) and a new first digital currency with a face value of 7 that is still frozen, and cancels the original first digital currency with a face value of 10. Then, in response to a second reverse transaction request against the target transaction request, the payment platform cancels the second digital currency with a face value of 15 and the first digital currency with a face value of 7 that is still frozen, and regenerates a fifth digital currency with a face value of 12 that is in an available state, as well as the first digital currency with a face value of 10.

[0172] According to an embodiment of the present invention, a digital currency-based payment method can be implemented by using a pre-configured pre-payment deposit smart contract to freeze the first digital currency corresponding to the pre-payment amount. During this freeze, neither the user initiating the pre-payment request nor the service provider can use the first digital currency. When a target payment request is received for the frozen first digital currency, the frozen first digital currency is cancelled according to the pre-payment cancellation smart contract. Based on the digital currency balance of the first account corresponding to the first digital currency, a second digital currency in a usable state is generated. The face value of the second digital currency is the sum of the target payment amount indicated in the target payment request and the digital currency balance. The second digital currency is then sent to the first account corresponding to the service provider, allowing the service provider to use it. Thus, the pre-payment smart contract prevents the service provider from using the pre-paid digital currency in advance, improving transaction security in pre-payment scenarios. Furthermore, unused pre-paid digital currency can be revoked or cancelled, returning it to the second account corresponding to the first user. This solves the problem that users cannot get refunds for pre-paid currency in existing pre-payment scenarios, further improving transaction security and protecting user rights.

[0173] Figure 2 This is a schematic diagram of a digital currency-based payment platform according to an embodiment of the present invention.

[0174] like Figure 2 As shown, an embodiment of the present invention provides a digital currency-based payment platform 200, comprising: a request receiving module 201, a verification module 202, and a currency sending module 203; wherein,

[0175] The request receiving module 201 is used to receive a target payment request for a first digital currency that is in a frozen state. The first digital currency in the frozen state is generated based on a pre-payment request and a pre-configured pre-payment deposit smart contract.

[0176] The verification module 202 is used to generate a second digital currency based on the target payment amount indicated by the target payment request, the first digital currency, the pre-configured pre-payment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency; wherein, the second digital currency is in an available state, and the face value of the second digital currency is the sum of the target payment amount and the digital currency balance;

[0177] The currency sending module 203 is used to send the second digital currency to the first account.

[0178] In one embodiment of the present invention, the verification module 202 is further configured to generate a new first digital currency in a frozen state based on the difference between the first digital currency and the target payment amount, and the prepayment verification smart contract.

[0179] In one embodiment of the present invention, such as Figure 2 As shown, the payment platform further includes a processing module 204; wherein,

[0180] The processing module 204 is further configured to, upon receiving a cancellation request for the first digital currency, obtain the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request; upon obtaining the first signature information and the second signature information, set the status of the first digital currency to an available state and send the first digital currency to the second account.

[0181] In one embodiment of the present invention, the processing module 204 is further configured to receive a prepayment request from a first terminal, the prepayment request indicating a second account and a prepayment amount; and generate a first digital currency corresponding to the prepayment amount based on the prepayment request, the third digital currency corresponding to the second account, and a pre-configured prepayment deposit smart contract, wherein the first digital currency is in a frozen state.

[0182] In one embodiment of the present invention, the prepayment request further indicates the first account; the processing module 204 is configured to write the prepayment deposit smart contract and / or the first account as a field of the first digital currency into the first digital currency.

[0183] In one embodiment of the present invention, the verification module 202 is used to determine whether the account indicated by the target payment request is the same as the first account; if so, generate the second digital currency; if not, reject the target payment request.

[0184] In one embodiment of the present invention, the verification module 202 is used to sign the first digital currency using its own third signature information after the second digital currency is generated, and to generate and store the first prepayment transaction information based on the signed first digital currency, the second signature information and the prepayment deposit smart contract.

[0185] In one embodiment of the present invention, the prepayment request further indicates a payment period and a payment amount corresponding to the payment period; the verification module 202 is further configured to generate a second digital currency based on the payment amount, the digital currency balance of the first account and the prepayment verification smart contract when the payment period is detected to be met at the current time, wherein the face value of the second digital currency is the sum of the payment amount and the digital currency balance.

[0186] In one embodiment of the present invention, the verification module 202 is used to write the prepayment verification smart contract as a field of the new first digital currency that is in a frozen state into the first digital currency.

[0187] In one embodiment of the present invention, when the cancellation request is a revocation request sent by the first terminal, the processing module 204 is further configured to determine whether the first digital currency is revocable based on a pre-configured pre-payment revocation smart contract; if so, obtain the first signature information and the second signature information; if not, reject the revocation request.

[0188] In one embodiment of the present invention, the verification module 202 is further configured to use its own third signature information to sign the first digital currency, and generate and store the first prepayment transaction information based on the signed first digital currency, the second signature information and the prepayment deposit smart contract.

[0189] In one embodiment of the present invention, the prepayment request further indicates a scenario identifier and / or a business identifier; the processing module 204 is configured to generate the first prepayment transaction information based on the first digital currency and the second signature information, the prepayment deposit smart contract, and the scenario identifier and / or business identifier.

[0190] In one embodiment of the present invention, when the target payment request further indicates a scenario identifier and / or a business identifier, the verification module 202 is used to determine whether the scenario identifier and / or business identifier indicated in the target payment request are the same as the scenario identifier and / or business identifier indicated in the first pre-payment transaction information; if so, generate the second digital currency; if not, reject the target payment request.

[0191] In one embodiment of the present invention, the verification module 202 is used to determine whether the target payment request includes the signature information of the sender of the target payment request, and if so, to generate the second digital currency.

[0192] In one embodiment of the present invention, the verification module 202 is used to generate second prepayment transaction information based on the prepayment verification smart contract, the signature information of the sending end, its own third signature information, and the difference between the first digital currency and the target payment amount.

[0193] In one embodiment of the present invention, the processing module 204 is configured to determine the third digital currency in the second account and the available denomination of the third digital currency; determine the generation method of the first digital currency according to the available denomination and the amount of the prepayment, and generate the first digital currency corresponding to the prepayment amount according to the generation method.

[0194] In one embodiment of the present invention, the processing module 204 is configured to determine that the generation method is to split the third digital currency when the available face value is greater than the prepayment amount; split the third digital currency into the first digital currency and the fourth digital currency, wherein the sum of the face value of the first digital currency and the face value of the fourth digital currency is equal to the available face value, and the fourth digital currency is in an available state, and cancel the third digital currency.

[0195] In one embodiment of the present invention, the processing module 204 is used to freeze the first digital currency in the first account or the second account or payment platform corresponding to the prepayment request.

[0196] In one embodiment of the present invention, the verification module 202 is further configured to send a prepayment recovery prompt to the first terminal that initiated the prepayment request when it is determined that the face value of the first digital currency is less than the target payment amount.

[0197] In one embodiment of the present invention, the reconciliation module 202 is further configured to, when receiving a prepayment recovery request sent by the first terminal according to the prepayment recovery prompt, verify whether the first account and the second account indicated by the prepayment recovery request are empty; if not, obtain the first signature information of the first account and the second signature information of the second account; and, if the first signature information and the second signature information are obtained, generate a new first digital currency in a frozen state according to the pre-configured prepayment recovery smart contract, the amount indicated by the prepayment recovery request, and the first digital currency.

[0198] In one embodiment of the present invention, the processing module 204 is further configured to receive a termination command;

[0199] According to the termination instruction and the pre-configured prepayment termination smart contract, the status of the first digital currency is set to an available state, and the first digital currency is sent to the second account corresponding to the prepayment request; and a prepayment termination prompt message is sent to the first terminal that initiated the prepayment request and the second terminal corresponding to the first account.

[0200] In one embodiment of the present invention, the prepayment request is received through a frozen payment interface; the processing module 204 is further configured to, when a first reverse transaction request is received through the frozen payment interface, obtain the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request; and, upon obtaining the first signature information and the second signature information, set the state of the first digital currency to an available state and send the first digital currency to the second account.

[0201] In one embodiment of the present invention, the target payment request is received through the unfreezing payment interface; the processing module 204 is further configured to, when a second reverse transaction request is received through the unfreezing payment interface, obtain the first signature information corresponding to the first account and the second signature information of the second account corresponding to the pre-payment request; upon obtaining the first signature information and the second signature information, cancel the second digital currency, generate a fifth digital currency with a balance equal to the digital currency, and update the first digital currency according to the target payment amount.

[0202] In one embodiment of the present invention, the processing module 204 is further configured to cancel the fifth digital currency corresponding to the digital currency balance of the first account.

[0203] According to an embodiment of the present invention, a digital currency-based payment platform can freeze the first digital currency corresponding to the pre-payment amount based on a pre-configured pre-payment deposit smart contract. During this freeze, neither the user initiating the pre-payment request nor the service provider can use the first digital currency. When a target payment request is received for the frozen first digital currency, the frozen first digital currency is cancelled according to the pre-payment cancellation smart contract. Based on the digital currency balance of the first account corresponding to the first digital currency, a second digital currency in a usable state is generated. The face value of the second digital currency is the sum of the target payment amount indicated in the target payment request and the digital currency balance. The second digital currency is then sent to the first account corresponding to the service provider, allowing the service provider to use it. Thus, the pre-payment smart contract prevents the service provider from using the pre-paid digital currency in advance, improving transaction security in pre-payment scenarios. Furthermore, unused pre-paid digital currency can be revoked or cancelled, returning it to the second account corresponding to the first user. This solves the problem that users cannot get refunds for pre-paid currency in existing pre-payment scenarios, further improving transaction security and protecting user rights.

[0204] Figure 3 This is a schematic diagram of a digital currency-based payment system according to an embodiment of the present invention.

[0205] like Figure 3 As shown, an embodiment of the present invention provides a digital currency-based payment system 300, comprising: a payment platform 200 provided in any of the above embodiments and a first terminal 301; wherein, the first terminal 301 includes: a pre-payment request sending module 3011, a frozen currency storage module 3012, and a target payment request sending module 3013; wherein,

[0206] The prepayment request sending module 3011 is used to generate a prepayment request in response to the first trigger and send the prepayment request to the payment platform; the prepayment request indicates the second account and the prepayment amount;

[0207] The frozen currency storage module 3012 is used to receive the first digital currency corresponding to the prepayment amount and store the first digital currency in a frozen state in the second account;

[0208] The target payment request sending module 3013 is used to generate a target payment request for the first digital currency in response to the second trigger, and send the target payment request to the payment platform.

[0209] Understandably, the first and second triggers are usually initiated by the consumer.

[0210] In one embodiment of the present invention, the first terminal 301 generates the prepayment request and / or the target payment request based on the second signature information of the second account.

[0211] In one embodiment of the present invention, the first terminal may send the second signature information of the second account to the payment platform in response to the feedback from the payment platform on the prepayment request and / or the target payment request.

[0212] In one embodiment of the present invention, the target payment request sending module 3013 is used to obtain a payment identifier or payment image corresponding to the first account to determine the first account; and generate the target payment request based on the first account and the second trigger.

[0213] Here, the first terminal can obtain the first account corresponding to the service provider by acquiring the payment identifier of the first account (such as a payment code) or scanning the payment image corresponding to the first account (such as a QR code or barcode for receiving payment). Then, it can generate various requests such as pre-payment requests, target payment requests, and pre-payment recovery requests based on the first account.

[0214] In one embodiment of the present invention, such as Figure 3 As shown, the first terminal further includes a collection module 3014; wherein, the collection module 3014 is used to receive a pre-payment collection prompt sent by the payment platform and display the pre-payment collection prompt; when receiving collection information input according to the pre-payment collection prompt, generating a pre-payment collection request according to the first account and the second account included in the collection information, and sending the pre-payment collection request to the payment platform.

[0215] Still referencing Figure 3 In one embodiment of the present invention, the payment system 300 may further include: a second terminal 302; wherein,

[0216] The second terminal 302 is used to receive the second digital currency and store the second digital currency in the first account.

[0217] In one embodiment of the present invention, the second terminal 302 is configured to generate a target payment request for the first digital currency in response to a third trigger, and send the target payment request to the payment platform. It is understood that the third trigger is generally initiated by the service provider (merchant).

[0218] In one embodiment of the present invention, the second terminal 302 is used to receive payment information regarding a prepayment recovery request sent by the payment platform, the payment information indicating a first account, a second account, and the amount indicated by the prepayment recovery request; and to verify the prepayment recovery request based on the payment information, and when the verification passes, to send first signature information corresponding to the first account information to the payment platform.

[0219] The following will use the application of a payment system as an example to describe in detail the payment method based on digital currency provided in this embodiment of the invention. Figure 4 The main steps included in the method are shown. Figure 5 This illustrates the process of digital currency generation during payment. For example... Figure 4 As shown, the method mainly includes the following steps:

[0220] Step S401: The first terminal generates a prepayment request based on the consumer's first trigger and sends the prepayment request to the payment platform. The prepayment request indicates the second account and the prepayment amount.

[0221] For example, if the prepayment amount is 10, the digital currency in the second account is all in a usable third digital currency with a face value of 100.

[0222] Step S402: The payment platform generates a first digital currency corresponding to the prepayment amount based on the prepayment request, the third digital currency corresponding to the second account, and the pre-configured prepayment deposit smart contract. The first digital currency is in a frozen state.

[0223] In this example, the payment platform splits the third digital currency with a face value of 100 in the second account into a first digital currency with a face value of 10 and a fourth digital currency with a face value of 90. The first digital currency is frozen, while the fourth digital currency is available.

[0224] Step S403: The payment platform sends the first digital currency to the first terminal, so that the first terminal stores the first digital currency, which is in a frozen state, in the second account.

[0225] Step S404: The first terminal generates a target payment request for the first digital currency that is in a frozen state according to the second trigger of the first user, and sends the target payment request to the payment platform, wherein the target payment request indicates the target payment amount.

[0226] For example, the target payment amount is 3.

[0227] Step S405: The payment platform generates a second digital currency based on the target payment amount, the first digital currency, the pre-configured pre-payment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency.

[0228] Here, assuming the first account has a digital currency balance of 150, the payment platform, according to the pre-payment verification smart contract, generates a second digital currency with a face value of 153 and a new first digital currency with a face value of 7 based on the first digital currency with a face value of 10. The second digital currency is set to an available state, while the new first digital currency remains frozen.

[0229] Step S406: The payment platform sends the second digital currency to the second terminal, so that the second terminal stores the second digital currency in the first account.

[0230] Understandably, the payment platform will also send the new first digital currency to the first terminal, so that the frozen first digital currency remains stored in the second account. When a new target payment request is received again, this target payment request is for the new first digital currency, and the first digital currency can be further split based on the above process to make consumption based on the pre-paid digital currency.

[0231] In this embodiment of the invention, the first digital currency in a frozen state can also be stored on a payment platform or in a first account. During the prepayment reconciliation process, the target payment request can also be initiated by the service provider. (Referring to the following...) Figure 5 The digital currency generation process shown above is described in detail. For example... Figure 6 As shown, the method mainly includes the following steps:

[0232] Step S601: The first terminal generates a prepayment request based on the consumer's first trigger and sends the prepayment request to the payment platform. The prepayment request indicates the second account and the prepayment amount.

[0233] For example, if the prepayment amount is 10, the digital currency in the second account is all in a usable third digital currency with a face value of 100.

[0234] Step S602: The payment platform generates a first digital currency corresponding to the prepayment amount based on the prepayment request, the third digital currency corresponding to the second account, and the pre-configured prepayment deposit smart contract. The first digital currency is in a frozen state.

[0235] In this example, the payment platform splits the third digital currency with a face value of 100 in the second account into a first digital currency with a face value of 10 and a fourth digital currency with a face value of 90. The first digital currency is frozen, while the fourth digital currency is available.

[0236] Step S603: The payment platform sends the first digital currency to the second terminal, so that the second terminal stores the first digital currency, which is in a frozen state, in the first account.

[0237] It is understandable that after generating the first digital currency, the payment platform may also store the first digital currency locally and send a notification to the first terminal and / or the second terminal that the first digital currency has been generated.

[0238] Step S604: The second terminal generates a target payment request for the first digital currency that is in a frozen state according to the third trigger of the service provider, and sends the target payment request to the payment platform, wherein the target payment request indicates the target payment amount.

[0239] For example, the target payment amount is 3.

[0240] Step S605: The payment platform generates a second digital currency based on the target payment amount, the first digital currency, the pre-configured pre-payment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency, thus generating a second digital currency corresponding to the target payment amount.

[0241] Here, assuming the first account has a digital currency balance of 150, the payment platform, according to the pre-payment verification smart contract, generates a second digital currency with a face value of 153 and a new first digital currency with a face value of 7 based on the first digital currency with a face value of 10. The second digital currency is set to an available state, while the new first digital currency remains frozen.

[0242] Step S606: The payment platform sends the second digital currency to the second terminal, so that the second terminal stores the second digital currency in the first account.

[0243] Understandably, the payment platform will also send the new first digital currency to the second terminal, so that the frozen second digital currency remains stored in the first account. When a new target payment request is received again, this target payment request is for the new first digital currency, and the first digital currency can be further split based on the above process to make consumption based on the pre-paid digital currency.

[0244] Furthermore, in this embodiment of the invention, there is no direct correspondence between the storer of the first digital currency and the initiator of the target payment request. For example, it can be done by... Figure 4 and Figure 6 The illustrated embodiment implements advance payment. Besides... Figure 4 and Figure 6 In the embodiments shown, when implementing the payment method provided by the embodiments of the present invention, when the first digital currency is stored in the first terminal, the target payment request can also be initiated by the second terminal; when the first digital currency is stored in the second terminal, the target payment request can also be initiated by the first terminal; or, when the first digital currency is stored in the payment platform, the target payment request can be initiated by the first terminal or the second terminal.

[0245] Figure 7 An exemplary system architecture 700 is shown, which can be applied to a digital currency-based payment method or a digital currency-based payment system according to embodiments of the present invention.

[0246] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0247] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0248] Terminal devices 701, 702, and 703 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0249] Server 705 can be a server providing various services, such as a backend management server supporting shopping websites browsed by users using terminal devices 701, 702, and 703. The backend management server can analyze and process received data such as product information query requests and then return the processing results to the terminal devices.

[0250] It should be understood that Figure 7 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0251] The following is for reference. Figure 8It shows a schematic diagram of the structure of a computer system 800 suitable for implementing a terminal device of the present invention. Figure 8 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0252] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0253] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0254] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this invention.

[0255] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0256] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0257] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including a pre-payment request sending module, a frozen currency storage module, and a target payment request sending module. The names of these modules do not necessarily limit the module itself; for example, a request receiving module may also be described as "a module that receives target payment requests for a first digital currency that is in a frozen state."

[0258] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, cause the device to include: receiving a target payment request for a first digital currency in a frozen state, the frozen first digital currency being generated based on a pre-payment request and a pre-configured pre-payment deposit smart contract; generating a second digital currency according to the target payment amount indicated by the target payment request, the first digital currency, the pre-configured pre-payment verification smart contract, and the digital currency balance of a first account corresponding to the first digital currency; wherein the second digital currency is in an available state, and the face value of the second digital currency is the sum of the target payment amount and the digital currency balance; and sending the second digital currency to the first account.

[0259] According to the technical solution of this invention, a pre-configured pre-payment deposit smart contract can freeze the first digital currency corresponding to the pre-payment amount, preventing the user initiating the pre-payment request and the service provider from using it. Upon receiving a target payment request for the frozen first digital currency, the pre-payment cancellation smart contract cancels the frozen first digital currency, and based on the digital currency balance of the first account corresponding to the first digital currency, generates a usable second digital currency. The face value of the second digital currency is the sum of the target payment amount indicated in the target payment request and the digital currency balance. The second digital currency is then sent to the first account corresponding to the service provider, allowing the service provider to use it. Thus, the pre-payment smart contract prevents the service provider from using the pre-paid digital currency in advance, improving transaction security in pre-payment scenarios. Furthermore, unused pre-paid digital currency can be revoked or cancelled, returning it to the second account corresponding to the first user. This solves the problem of users being unable to get refunds for pre-paid currency in existing pre-payment scenarios, further improving transaction security and protecting user rights.

[0260] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A payment method based on digital currency, characterized in that, Applied to payment platforms; including: Receive a target payment request for a first digital currency that is in a frozen state, the first digital currency being generated based on a pre-payment request and a pre-configured pre-payment deposit smart contract; A second digital currency is generated based on the target payment amount indicated by the target payment request, the first digital currency, the pre-configured prepayment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency; wherein, the second digital currency is in an available state, and the face value of the second digital currency is the sum of the target payment amount and the digital currency balance; Send the second digital currency to the first account; Based on the difference between the first digital currency and the target payment amount, and the prepayment verification smart contract, a new first digital currency in a frozen state is generated; wherein, the prepayment verification smart contract is written into the first digital currency as a field of the new first digital currency in a frozen state.

2. The method according to claim 1, characterized in that, Also includes: Upon receiving a cancellation request for the first digital currency, obtain the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request; Upon obtaining the first signature information and the second signature information, the status of the first digital currency is set to available, and the first digital currency is sent to the second account.

3. The method according to claim 1, characterized in that, Prior to receiving the target payment request for the first digital currency that is in a frozen state, the method further includes: Receive a prepayment request from a first terminal, the prepayment request indicating a second account and a prepayment amount; Based on the prepayment request, the third digital currency corresponding to the second account, and the pre-configured prepayment deposit smart contract, a first digital currency corresponding to the prepayment amount is generated, and the first digital currency is in a frozen state.

4. The method according to claim 3, characterized in that, The prepayment request also directed to the first account; Write the prepayment deposit smart contract and / or the first account as fields of the first digital currency into the first digital currency.

5. The method according to claim 4, characterized in that, Determine whether the account indicated in this target payment request is the same as the first account; If so, generate the second digital currency; If not, reject the target payment request.

6. The method according to claim 3, characterized in that, The prepayment request also indicates a payment period and a corresponding payment amount; it further includes: If the payment deadline is met at the current time, a second digital currency is generated based on the payment amount, the digital currency balance of the first account, and the prepayment verification smart contract, wherein the face value of the second digital currency is the sum of the payment amount and the digital currency balance.

7. The method according to claim 2, characterized in that, In the case where the cancellation request is a revocation request sent by the first terminal, it also includes: Based on the pre-configured pre-payment cancellation smart contract, determine whether the first digital currency is revocable; If so, obtain the first signature information and the second signature information; If not, reject the revocation request.

8. The method according to claim 7, characterized in that, After generating the second digital currency, the process also includes: Using its own third signature information, the first digital currency is signed, and based on the signed first digital currency, the second signature information, and the prepayment deposit smart contract, the first prepayment transaction information is generated and stored.

9. The method according to claim 8, characterized in that, The prepayment request also indicates a scenario identifier and / or a business identifier; The first prepayment transaction information is generated based on the first digital currency, the second signature information, the prepayment deposit smart contract, and the scenario identifier and / or business identifier.

10. The method according to claim 9, characterized in that, If the target payment request also indicates a scenario identifier and / or a business identifier, it further includes: Determine whether the scenario identifier and / or business identifier indicated in the target payment request are the same as the scenario identifier and / or business identifier indicated in the first prepayment transaction information; If so, generate the second digital currency; If not, reject the target payment request.

11. The method according to claim 1, characterized in that, Also includes: Determine whether the target payment request includes signature information of the first terminal that sent the target payment request; if so, generate the second digital currency.

12. The method according to claim 8, characterized in that, Also includes: The second prepayment transaction information is generated based on the prepayment verification smart contract, the signature information of the first terminal, its own third signature information, and the difference between the first digital currency and the target payment amount.

13. The method according to claim 3, characterized in that, The step of generating a first digital currency corresponding to the prepayment amount based on the prepayment request, the third digital currency corresponding to the second account, and the pre-configured prepayment deposit smart contract includes: Determine the third digital currency in the second account and the available denominations of the third digital currency; Based on the available denomination and the amount of the prepayment, the generation method of the first digital currency is determined, and the first digital currency corresponding to the prepayment amount is generated according to the generation method.

14. The method according to claim 13, characterized in that, When the available face value is greater than the prepayment amount, it is determined that the generation method is to split the third digital currency; The third digital currency is split into the first digital currency and the fourth digital currency. The sum of the face value of the first digital currency and the face value of the fourth digital currency is equal to the available face value, and the fourth digital currency is in an available state. The third digital currency is then cancelled.

15. The method according to claim 1, characterized in that, Also includes: The first digital currency is frozen in the first account or the second account or payment platform corresponding to the prepayment request.

16. The method according to claim 1, characterized in that, Also includes: If it is determined that the face value of the first digital currency is less than the target payment amount, a prepayment recovery prompt is sent to the first terminal that initiated the prepayment request.

17. The method according to claim 16, characterized in that, Also includes: When a prepayment recovery request is received from the first terminal according to the prepayment recovery prompt, the system verifies whether the first account and the second account indicated by the prepayment recovery request are empty. If not, the system obtains the first signature information of the first account and the second signature information of the second account. Upon obtaining the first signature information and the second signature information, a new first digital currency in a frozen state is generated based on the pre-configured prepayment recovery smart contract, the amount indicated by the prepayment recovery request, and the first digital currency.

18. The method according to claim 1, characterized in that, Also includes: Received termination command; According to the termination instruction and the pre-configured prepayment termination smart contract, the status of the first digital currency is set to an available state, and the first digital currency is sent to the second account corresponding to the prepayment request. as well as Send a prepayment termination notification message to the first terminal that initiated the prepayment request and the second terminal corresponding to the first account.

19. The method according to claim 1, characterized in that, The prepayment request is received via a frozen payment interface; and also includes: When a first reverse transaction request is received through the frozen payment interface, the first signature information of the first account and the second signature information of the second account corresponding to the prepayment request are obtained. Upon obtaining the first signature information and the second signature information, the status of the first digital currency is set to available, and the first digital currency is sent to the second account.

20. The method according to claim 1, characterized in that, Receiving the target payment request through the unfreezing payment interface; also includes: When a second reverse transaction request is received through the unfreezing payment interface, the first signature information corresponding to the first account and the second signature information of the second account corresponding to the prepayment request are obtained. Upon obtaining the first signature information and the second signature information, the second digital currency is cancelled, a fifth digital currency with a balance equal to that of the first digital currency is generated, and the first digital currency is updated according to the target payment amount.

21. The method according to claim 1, characterized in that, After generating the second digital currency, the process also includes: Cancel the fifth digital currency corresponding to the digital currency balance of the first account.

22. A payment platform based on digital currency, characterized in that, include: The module includes a request receiving module, a verification module, and a currency sending module; among them, The request receiving module is used to receive a target payment request for a first digital currency that is in a frozen state. The first digital currency in the frozen state is generated based on a pre-payment request and a pre-configured pre-payment deposit smart contract. The verification module is used to generate a second digital currency based on the target payment amount indicated by the target payment request, the first digital currency, the pre-configured pre-payment verification smart contract, and the digital currency balance of the first account corresponding to the first digital currency; wherein, the second digital currency is in an available state, and the face value of the second digital currency is the sum of the target payment amount and the digital currency balance; The currency sending module is used to send the second digital currency to the first account; The verification module is further configured to generate a new first digital currency in a frozen state based on the difference between the first digital currency and the target payment amount, and the prepayment verification smart contract; wherein the prepayment verification smart contract is written into the first digital currency as a field of the new first digital currency in a frozen state.

23. A payment system based on digital currency, characterized in that, include: The payment platform and the first terminal as described in claim 22; wherein the first terminal includes: a prepayment request sending module, a frozen currency storage module, and a target payment request sending module; The prepayment request sending module is used to generate a prepayment request in response to the first trigger and send the prepayment request to the payment platform; the prepayment request indicates the second account and the prepayment amount; The frozen currency storage module is used to receive the first digital currency corresponding to the prepayment amount and store the first digital currency in a frozen state in the second account; The target payment request sending module is used to generate a target payment request for the first digital currency in response to the second trigger, and send the target payment request to the payment platform.

24. The payment system according to claim 23, characterized in that, The first terminal generates the prepayment request and / or the target payment request based on the second signature information of the second account; And / or, In response to the payment platform's feedback on the pre-payment request and / or the target payment request, the first terminal sends the second signature information of the second account to the payment platform.

25. The payment system according to claim 23, characterized in that, The target payment request sending module is used to obtain a payment identifier or payment image corresponding to the first account to determine the first account, and generate the target payment request based on the first account and the second trigger.

26. The payment system according to claim 25, characterized in that, The first terminal further includes: a processing module; wherein, The processing module is used to receive and display the pre-payment recovery prompt sent by the payment platform; when receiving recovery information input according to the pre-payment recovery prompt, it generates a pre-payment recovery request based on the first account and the second account included in the recovery information, and sends the pre-payment recovery request to the payment platform.

27. The payment system according to claim 23, characterized in that, Also includes: The second terminal; among which, The second terminal is used to receive the second digital currency and store the second digital currency in the first account; And / or, The second terminal is configured to, in response to a third trigger, generate a target payment request for the first digital currency and send the target payment request to the payment platform.

28. The payment system according to claim 27, characterized in that, The second terminal is used to receive payment information regarding a prepayment recovery request sent by the payment platform, the payment information indicating a first account, a second account, and the amount indicated by the prepayment recovery request; and to verify the prepayment recovery request based on the payment information, and when the verification passes, to send a first signature information of the first account to the payment platform.

29. An electronic device based on digital currency payment, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-21.

30. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-21.

Images