A payment method, platform, terminal and system based on digital currency

Abstract

This invention discloses a payment method, platform, terminal, and payment system based on digital currency, relating to the field of computer technology. One specific embodiment of the method includes: receiving a target payment request for a first digital currency 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; generating a second digital currency corresponding to the target payment amount according to the target payment amount indicated in the target payment request, the first digital currency, and the pre-configured pre-payment verification smart contract; and sending the second digital currency to a first account corresponding to the first digital currency. This embodiment improves transaction security and helps protect user rights.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a payment method, platform, terminal 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, terminal, and payment system based on digital currency. Based on a pre-configured pre-payment deposit smart contract, the first digital currency corresponding to the pre-payment amount is frozen. During this state, the first user initiating the pre-payment request and the second user corresponding to the service provider cannot use the second 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, generating a second digital currency corresponding to the target payment amount. This 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.

[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] Based on the target payment amount indicated by the target payment request, the first digital currency, and the pre-configured pre-payment reconciliation smart contract, a second digital currency corresponding to the target payment amount is generated;

[0009] The second digital currency is sent to the first account corresponding to the first digital currency.

[0010] Optionally, a new first digital currency in a frozen state is generated based on the difference between the first digital currency and the second digital currency, 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 a second digital currency corresponding to the target payment amount;

[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 corresponding to the payment amount is generated based on the payment amount and the prepayment verification smart contract, and the second digital currency corresponding to the payment amount is sent to the first account.

[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 a second digital currency corresponding to the target payment amount;

[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 a second digital currency corresponding to the target payment amount.

[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 second digital currency.

[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, after setting the second digital currency to an available state, the second digital currency in an available state is sent to the first account.

[0049] Optionally, it also includes:

[0050] 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.

[0051] Optionally, it also includes:

[0052] 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.

[0053] 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.

[0054] Optionally, it also includes:

[0055] Received termination command;

[0056] 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

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

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

[0059] 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.

[0060] 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.

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

[0062] 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.

[0063] Upon obtaining the first signature information and the second signature information, the second digital currency is cancelled, and the first digital currency is updated according to the target payment amount.

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

[0065] When a payment method based on digital currency according to an embodiment of the present invention is applied to a first terminal, it includes:

[0066] In response to the first trigger, a prepayment request is generated and sent to the payment platform; the prepayment request indicates the second account and the prepayment amount;

[0067] Receive the first digital currency corresponding to the prepayment amount, and store the first digital currency in a frozen state in the second account;

[0068] In response to the second trigger, a target payment request for the first digital currency is generated and sent to the payment platform.

[0069] Optionally, it also includes:

[0070] The prepayment request and / or the target payment request are generated based on the second signature information of the second account.

[0071] Optionally, in response to the payment platform's feedback on the prepayment request and / or the target payment request, the second signature information of the second account is sent to the payment platform.

[0072] Optionally, it also includes:

[0073] Obtain the payment identifier or payment image corresponding to the first account to identify the first account;

[0074] The target payment request is generated based on the first account and the second trigger.

[0075] Optionally, it also includes:

[0076] Receive and display the prepayment recovery notice sent by the payment platform;

[0077] When the recovery information is received based on the prepayment recovery prompt, a prepayment recovery request is generated based on the first account and the second account included in the recovery information, and the prepayment recovery request is sent to the payment platform.

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

[0079] 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,

[0080] 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.

[0081] 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.

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

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

[0084] An embodiment of the present invention provides a first terminal for digital currency payment, comprising: a pre-payment request sending module, a frozen currency storage module, and a target payment request sending module; wherein,

[0085] 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;

[0086] 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;

[0087] 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.

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

[0089] An embodiment of the present invention provides a payment system based on digital currency, comprising: any of the payment platforms described above and any of the first terminals described above.

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

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

[0092] 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.

[0093] Optionally, the second terminal is configured to receive payment information regarding a prepayment recovery request sent by the payment platform, wherein the payment information indicates a first account, a second account, and the amount indicated by the prepayment recovery request;

[0094] Based on the payment information, the prepayment recovery request is verified. When the verification passes, the first signature information corresponding to the first account is sent to the payment platform.

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

[0096] 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.

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

[0098] 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.

[0099] 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. During this time, the first user initiating the pre-payment request and the second user corresponding to the service provider cannot use the second 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, generating a second digital currency corresponding to the target payment amount. This second digital currency is then sent to the first account corresponding to the service provider, allowing the service provider to use it. Thus, through the pre-payment smart contract, the service provider is prevented 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 a refund for pre-paid currency in existing pre-payment scenarios, further improving transaction security and protecting user rights.

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

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

[0102] 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;

[0103] Figure 2 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;

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

[0105] Figure 4 This is a schematic diagram of the main modules of a first terminal based on digital currency payment according to an embodiment of the present invention;

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

[0107] 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;

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

[0109] Figure 8 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;

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

[0111] Figure 10 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

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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:

[0116] 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.

[0117] 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.

[0118] When the first user needs to make a prepayment, the prepayment interface on the first terminal can be triggered. Then, in response to the first user's trigger, the first terminal generates a prepayment request, which indicates the second account and the prepayment amount. The second account is the first user's account, and the prepayment amount corresponds to the amount to be deposited in this prepayment.

[0119] 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 user" does not correspond to "first account." These terms are only used to distinguish different entities and to more clearly describe the embodiments of this invention. In the embodiments of this invention, the consumer corresponds to the first user, the corresponding terminal is the first terminal, the corresponding account is the second account, and the corresponding signature information is the second signature information. The service provider corresponds to the second user, the corresponding terminal is the second terminal, the corresponding account is the first account, and the corresponding signature information is the first signature information. In addition, 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 be applied to other electronic or digital forms of currency or assets, such as various electronic currencies, cryptocurrencies, and encrypted assets.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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 first user's authentication information or payment password, etc.

[0124] 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 first user for normal payment.

[0125] 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 corresponding to the target payment amount 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.

[0126] In this embodiment, the payment platform only responds to the target payment request and generates a second digital currency corresponding to the target payment amount according to the prepayment settlement smart contract if the account indicated in the target payment request is the same as the first account corresponding to the first digital currency determined by the prepayment deposit smart contract. If the account indicated in the 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 the rights of the service provider.

[0127] 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.

[0128] 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 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 first signature information, 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.

[0129] 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.

[0130] 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.

[0131] 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), thereby 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.

[0132] 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.

[0133] Understandably, after the payment platform generates the corresponding first pre-payment transaction, it can send corresponding feedback information to the first user's first terminal and the service provider's (second user'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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

[0147] Step S102: 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 the pre-configured pre-payment verification smart contract.

[0148] 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 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.

[0149] If so, 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 the pre-configured pre-payment reconciliation smart contract;

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

[0151] 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.

[0152] 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, a second digital currency corresponding to the target payment amount is generated.

[0153] 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.

[0154] When the sender of the target payment request is the first terminal, the signature information of the sender is the second signature information of the second account. When generating the second digital currency, it is necessary to obtain the second signature information to represent the first user's authentication of the pre-payment amount used. Of course, if the sender is the first terminal, the payment platform can also obtain the first signature information from the second terminal to obtain the service provider's authentication of the service that can be provided.

[0155] 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 information. 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 first user's authentication of the prepayment amount used this time.

[0156] 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 second digital currency.

[0157] Here, when using the prepayment amount, 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 and the first digital currency corresponding to the first prepayment information, a second digital currency corresponding to the target payment amount is generated. The process of generating the second digital currency is basically the same as the aforementioned process of generating the first digital currency. For example, by splitting the first digital currency, a second digital currency corresponding to the target payment amount and a new first digital currency with a face value equal to the difference between the first and second digital currencies can be obtained. This new first digital currency remains frozen and is intended for use in the next prepayment under the same prepayment scenario.

[0158] 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 second digital currency, 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.

[0159] Alternatively, in one embodiment of the present invention, a prepayment can be made by agreeing on a prepayment period and making payments on schedule according to the prepayment period. In this case, the prepayment request also indicates a payment period and a payment amount corresponding to the payment period. If the payment period is found to be met at the current time, a second digital currency corresponding to the payment amount is generated according to the payment amount and the prepayment reconciliation smart contract, and the second digital currency corresponding to the payment amount is sent to the first account.

[0160] For example, if the 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 generates a second digital currency with a face value of 1 based on the first digital currency currently frozen, and sends this second digital currency to the service provider's first account. 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 corresponding to the payment amount based on the first digital currency currently frozen. The process of generating the second digital currency corresponding to the payment amount is the same as the process of generating the digital currency corresponding to the target payment amount, and will not be repeated here.

[0161] After the second digital currency is generated, the original first prepayment 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 information has been reduced by the amount of this payment (target payment amount), that is, the prepayment amount in the second prepayment 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 information is updated to 1. After generating the second prepayment information, the payment platform also records the original first prepayment information as invalid.

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

[0163] 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.

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

[0165] 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.

[0166] 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.

[0167] 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.

[0168] The prepayment recovery smart contract is used to add recharge amounts to existing prepayment terms. Therefore, when the first user initiates a prepayment recovery request, they should input the second account (payment account) and the first account (receiver 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 account and the second user 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 signature information and the second signature information.

[0169] The second signature information can be sent to the payment platform along with the prepayment recovery request, or it can be prompted by the payment platform after verifying whether the first and second accounts are empty and the recovery amount. Alternatively, the first signature information can be prompted by the payment platform after verification. When the payment platform receives the second signature information, it indicates that the first user has successfully authenticated the prepayment recovery request. Similarly, when the payment platform receives the first signature information, it indicates that the service provider (second user) 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. Only then does the payment platform generate 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.

[0170] 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.

[0171] 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.

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

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

[0174] If the target payment request still corresponds to a prepayment operation, the payment platform can directly send the frozen second digital currency to the first account. After receiving the frozen second digital currency, the first account still cannot use the second digital currency as a general digital currency in other payment scenarios, but can only apply the second digital currency to the same specific prepayment scenario as the first digital currency.

[0175] When generating the second digital currency, the payment platform also generates a new first digital currency based on the difference between the first and second digital currencies and 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.

[0176] 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.

[0177] 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 first user, so that the first user can use the prepayment for other general payment scenarios.

[0178] 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.

[0179] 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.

[0180] 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 corresponding to the target payment amount 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.

[0181] 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.

[0182] 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.

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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; if the first signature information and the second signature information are obtained, the second digital currency is cancelled, and the first digital currency is updated according to the target payment amount.

[0187] 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 the first digital currency, which is currently frozen, is regenerated based on the second digital currency and the newly generated first digital currency. For example, after a user initiates an incorrect target payment request, they can initiate a second reverse transaction request to the business platform through a 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 a second terminal. After obtaining the first signature information and the second signature information, the payment platform can respond to the second reverse transaction request to cancel the new first digital currency generated based on the incorrect target payment request. For example, the business platform, based on the target transaction request, generates a second digital currency with a face value of 3 based on the first digital currency with a face value of 10, 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. Therefore, in response to the second reverse transaction request against the target transaction request, the payment platform regenerates the first digital currency with a face value of 10 based on the second digital currency with a face value of 3 and the first digital currency with a face value of 7 that is still frozen, and cancels the second digital currency with a face value of 3 and the first digital currency with a face value of 7.

[0188] 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, the first user initiating the pre-payment request and the second user corresponding to the service provider cannot use the second 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, generating a second digital currency corresponding to the target payment amount. This 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.

[0189] Figure 2 This is a schematic diagram illustrating the main steps of a digital currency-based payment method applied to a first terminal according to an embodiment of the present invention.

[0190] like Figure 2 As shown, when a payment method based on digital currency is applied to a first terminal according to an embodiment of the present invention, it mainly includes the following steps:

[0191] Step S201: In response to the first trigger, a prepayment request is generated and sent to the payment platform; the prepayment request indicates the second account and the prepayment amount;

[0192] Step S202: Receive the first digital currency corresponding to the prepayment amount, and store the frozen first digital currency in the second account;

[0193] Step S203: In response to the second trigger, generate a target payment request for the first digital currency and send the target payment request to the payment platform.

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

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

[0196] 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 pre-payment request and / or the target payment request.

[0197] In one embodiment of the present invention, a first terminal acquires a payment identifier or payment image corresponding to a first account to determine the first account; and generates the target payment request based on the first account and the second trigger.

[0198] 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.

[0199] In one embodiment of the present invention, the first terminal may also receive and display a prepayment recovery prompt sent by the payment platform; when receiving recovery information input according to the prepayment recovery prompt, the terminal generates a prepayment recovery request based on the first account and the second account included in the recovery information, and sends the prepayment recovery request to the payment platform.

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

[0201] like Figure 3 As shown, an embodiment of the present invention provides a digital currency-based payment platform 300, comprising: a request receiving module 301, a verification module 302, and a currency sending module 303; wherein,

[0202] The request receiving module 301 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.

[0203] The verification module 302 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.

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

[0205] In one embodiment of the present invention, the verification module 302 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 second digital currency and the prepayment verification smart contract.

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

[0207] The processing module 304 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.

[0208] In one embodiment of the present invention, the processing module 304 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.

[0209] In one embodiment of the present invention, the prepayment request further indicates the first account; the processing module 304 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.

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

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

[0212] In one embodiment of the present invention, the verification module 302 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.

[0213] In one embodiment of the present invention, when the cancellation request is a revocation request sent by the first terminal, the processing module 304 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.

[0214] In one embodiment of the present invention, the verification module 302 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.

[0215] In one embodiment of the present invention, the prepayment request further indicates a scenario identifier and / or a business identifier; the processing module 304 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.

[0216] In one embodiment of the present invention, when the target payment request also indicates a scenario identifier and / or a business identifier, the verification module 302 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 a second digital currency corresponding to the target payment amount; if not, reject the target payment request.

[0217] 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 302 is further configured to, when detecting that the current time meets the payment period, generate a second digital currency corresponding to the payment amount according to the payment amount and the prepayment verification smart contract, and send the second digital currency corresponding to the payment amount to the first account.

[0218] In one embodiment of the present invention, the verification module 302 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 a second digital currency corresponding to the target payment amount.

[0219] In one embodiment of the present invention, the verification module 302 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 second digital currency.

[0220] In one embodiment of the present invention, the processing module 304 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.

[0221] In one embodiment of the present invention, the processing module 304 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.

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

[0223] In one embodiment of the present invention, the currency sending module 303 is used to send the second digital currency in the available state to the first account after setting the second digital currency to an available state.

[0224] In one embodiment of the present invention, the verification module 302 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.

[0225] In one embodiment of the present invention, the reconciliation module 302 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.

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

[0227] 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.

[0228] In one embodiment of the present invention, the prepayment request is received through a frozen payment interface; the processing module 304 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.

[0229] In one embodiment of the present invention, the target payment request is received through the unfreezing payment interface; the processing module 304 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; and, upon obtaining the first signature information and the second signature information, cancel the second digital currency and update the first digital currency according to the target payment amount.

[0230] 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, the first user initiating the pre-payment request and the second user corresponding to the service provider cannot use the second 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, generating a second digital currency corresponding to the target payment amount. This 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.

[0231] Figure 4 This is a schematic diagram of a first terminal based on digital currency payment according to an embodiment of the present invention.

[0232] like Figure 4 As shown, the first terminal 400 based on digital currency payment in this embodiment of the invention includes: a pre-payment request sending module 401, a frozen currency storage module 402, and a target payment request sending module 403; wherein,

[0233] The prepayment request sending module 401 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;

[0234] The frozen currency storage module 402 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;

[0235] The target request sending module 403 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.

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

[0237] In one embodiment of the present invention, the first terminal, in response to the feedback from the payment platform to the pre-payment request and / or the target payment request, sends the second signature information of the second account to the payment platform.

[0238] In one embodiment of the present invention, the first terminal acquires a payment identifier or payment image corresponding to the first account to determine the first account; and generates the target payment request based on the first account and the second trigger.

[0239] In one embodiment of the present invention, the first terminal receives a pre-payment recovery prompt sent by the payment platform and displays the pre-payment recovery prompt; when it receives recovery information input according to the pre-payment recovery prompt, it generates a pre-payment recovery request according to the first account and the second account included in the recovery information, and sends the pre-payment recovery request to the payment platform.

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

[0241] like Figure 5 As shown, a digital currency-based payment system 500 according to an embodiment of the present invention includes: a payment platform 300 provided in any of the above embodiments and a first terminal 400 provided in any of the above embodiments.

[0242] In one embodiment of the present invention, the payment system 500 may further include: a second terminal 501; wherein,

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

[0244] In one embodiment of the present invention, the second terminal 501 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).

[0245] In one embodiment of the present invention, the second terminal 501 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; 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.

[0246] 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 6The main steps included in the method are shown. Figure 7 This illustrates the process of digital currency generation during payment. For example... Figure 6 As shown, the method mainly includes the following steps:

[0247] 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.

[0248] 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.

[0249] In 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.

[0250] 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.

[0251] Step S603: 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.

[0252] Step S604: 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.

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

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

[0255] Here, the payment platform generates a second digital currency with a face value of 3 and a new first digital currency with a face value of 7 based on the first digital currency with a face value of 10, according to the prepayment verification smart contract. The second digital currency can be set to a general state, while the new first digital currency remains frozen.

[0256] 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.

[0257] 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.

[0258] 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 7 The digital currency generation process shown above is described in detail. For example... Figure 8 As shown, the method mainly includes the following steps:

[0259] Step S801: 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.

[0260] 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.

[0261] Step S802: 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.

[0262] 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.

[0263] Step S803: 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.

[0264] 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.

[0265] Step S804: 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.

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

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

[0268] Here, the payment platform generates a second digital currency with a face value of 3 and a new first digital currency with a face value of 7 based on the first digital currency with a face value of 10, according to the prepayment verification smart contract. The second digital currency can be set to a general state, while the new first digital currency remains frozen.

[0269] Step S806: 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.

[0270] 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.

[0271] 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 6 and Figure 8 The illustrated embodiment implements advance payment. Besides... Figure 6 and Figure 8 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 by the second terminal.

[0272] Figure 9 An exemplary system architecture 900 is shown that can be applied to a digital currency-based payment method or a digital currency-based payment system according to embodiments of the present invention.

[0273] like Figure 9As shown, system architecture 900 may include terminal devices 901, 902, and 903, network 904, and server 905. Network 904 is used as a medium to provide a communication link between terminal devices 901, 902, and 903 and server 905. Network 904 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0274] Users can use terminal devices 901, 902, and 903 to interact with server 905 via network 904 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 901, 902, and 903, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0275] Terminal devices 901, 902, and 903 can be various electronic devices with displays that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

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

[0277] It should be understood that Figure 9 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.

[0278] The following is for reference. Figure 10 It shows a schematic diagram of the structure of a computer system 1000 suitable for implementing a terminal device of the present invention. Figure 10 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.

[0279] like Figure 10 As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage section 1008 into a random access memory (RAM) 1003. The RAM 1003 also stores various programs and data required for the operation of the system 1000. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

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

[0281] 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 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs the functions defined in the system of this invention.

[0282] 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.

[0283] 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.

[0284] 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."

[0285] 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 corresponding to the target payment amount according to the target payment amount indicated by the target payment request, the first digital currency, and the pre-configured pre-payment reconciliation smart contract; and sending the second digital currency to a first account corresponding to the first digital currency.

[0286] 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. During this freeze, the first user initiating the pre-payment request and the second user corresponding to the service provider cannot use the second 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, generating a second digital currency corresponding to the target payment amount. This 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.

[0287] 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 method of payment based on digital currency, characterized by, Be applied to payment platform;Including: Receive a target payment request for a first digital currency in a frozen state, the first digital currency in the frozen state being generated based on a prepayment request and a preconfigured prepayment deposit smart contract; Generate a second digital currency corresponding to a target payment amount indicated by the target payment request, the first digital currency, and a preconfigured prepayment cancellation smart contract; Send the second digital currency to a first account corresponding to the first digital currency; Generate a new first digital currency in a frozen state according to the difference between the first digital currency and the target payment amount, and the prepayment cancellation smart contract; Wherein, the prepayment cancellation smart contract is written as a field of the new first digital currency in the frozen state; In the case of receiving a cancellation request for the first digital currency, in the case of a revocation request sent by the first terminal for the cancellation request, determine whether the first digital currency is revocable according to the preconfigured prepayment revocation smart contract; If yes, obtain first signature information of the first account and second signature information of a second account corresponding to the prepayment request; In the case of 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; If not, reject the revocation request.

2. The method of claim 1, wherein, Before the receiving a target payment request for a first digital currency in a frozen state, further comprising: Receive a prepayment request of a first terminal, the prepayment request indicating a second account and a prepayment amount; Generate a first digital currency corresponding to the prepayment amount according to the prepayment request, a third digital currency corresponding to the second account, and a preconfigured prepayment deposit smart contract, the state of the first digital currency being a frozen state.

3. The method of claim 2, wherein, The prepayment request also indicates the first account; Write the prepayment deposit smart contract and / or the first account as a field of the first digital currency into the first digital currency.

4. The method of claim 3, wherein Determine whether the account indicated by the target payment request this time is the same as the first account; If yes, generate a second digital currency corresponding to the target payment amount; If not, reject the target payment request.

5. The method of claim 2, wherein, The prepayment request also indicates a payment deadline and a payment limit corresponding to the payment deadline; Further comprising: In the case of monitoring that the current time meets the payment deadline, generate a second digital currency corresponding to the payment limit according to the payment limit and the prepayment cancellation smart contract, and send the second digital currency corresponding to the payment limit to the first account.

6. The method of claim 1, wherein, After generating the second digital currency, further comprising: Sign the first digital currency with its own third signature information, and generate and store first prepayment transaction information according to the signed first digital currency, the second signature information, and the prepayment deposit smart contract.

7. The method of claim 6, wherein, The prepayment request also indicates a scenario identifier and / or a business identifier; According to the first digital currency, the second signature information, the prepayment deposit smart contract, and the scenario identifier and / or the business identifier, the first prepayment transaction information is generated.

8. The method of claim 7, wherein, In the case where the target payment request also indicates a scenario identifier and / or a business identifier, the method further comprises: Determining whether the scenario identifier and / or the business identifier indicated by the target payment request this time are the same as the scenario identifier and / or the business identifier indicated by the first prepayment transaction information, respectively; If yes, generating a second digital currency corresponding to the target payment amount; If no, rejecting the target payment request.

9. The method of claim 1, wherein, The method further comprises: Determining whether the target payment request includes signature information of a sending end of the target payment request, and if yes, generating a second digital currency corresponding to the target payment amount.

10. The method of claim 9, wherein, The method further comprises: According to the prepayment cancellation smart contract, the signature information of the sending end, third signature information of the payment platform, and the difference between the first digital currency and the second digital currency, the second prepayment transaction information is generated.

11. The method of claim 2, wherein, The method of generating the first digital currency corresponding to the prepayment amount according to the prepayment request, the third digital currency corresponding to the second account, and the preconfigured prepayment deposit smart contract comprises: Determining the third digital currency in the second account and the available denomination of the third digital currency; According to the size of the available denomination and the prepayment amount, determining a generation mode of the first digital currency, and generating the first digital currency corresponding to the prepayment amount according to the generation mode.

12. The method of claim 11, wherein, When the available denomination is greater than the prepayment amount, it is determined that the generation mode is to split the third digital currency; The third digital currency is split into the first digital currency and a fourth digital currency, the sum of the denomination of the first digital currency and the denomination of the fourth digital currency is equal to the available denomination, and the state of the fourth digital currency is an available state, and the third digital currency is cancelled.

13. The method of claim 1, wherein, The method further comprises: Freezing the first digital currency in the first account or the second account corresponding to the prepayment request or a payment platform; And / or, After setting the second digital currency in an available state, sending the second digital currency in the available state to the first account.

14. The method of claim 1, wherein, The method further comprises: When it is determined that the denomination of the first digital currency is less than the target payment amount, sending a prepayment recovery prompt to a first terminal initiating the prepayment request.

15. The method of claim 14, wherein, The method further comprises: When receiving a prepayment recovery request sent by the first terminal according to the prepayment recovery prompt, verifying whether the first account and the second account indicated by the prepayment recovery request are empty, and if not, obtaining first signature information of the first account and second signature information of the second account; In the case where the first signature information and the second signature information are obtained, generating a new first digital currency in a frozen state according to the preconfigured prepayment recovery smart contract, the amount indicated by the prepayment recovery request, and the first digital currency.

16. The method of claim 1, wherein, The method further comprises: Receiving a termination instruction; According to the termination instruction and the pre-configured prepayment termination smart contract, the state of the first digital currency is set to an available state, and the first digital currency is sent to a second account corresponding to the prepayment request; And Prepayment termination prompt information is sent to a first terminal initiating the prepayment request and a second terminal corresponding to the first account.

17. The method of claim 1, wherein, The prepayment request is received through a frozen payment interface; further comprising: When a first reverse transaction request is received through the frozen payment interface, first signature information of the first account and second signature information of a second account corresponding to the prepayment request are obtained; In the case where the first signature information and the second signature information are obtained, the state of the first digital currency is set to an available state, and the first digital currency is sent to the second account.

18. The method of claim 1, wherein, The target payment request is received through an unfreezing payment interface; further comprising: When a second reverse transaction request is received through the unfreezing payment interface, first signature information corresponding to the first account and second signature information of a second account corresponding to the prepayment request are obtained; In the case where the first signature information and the second signature information are obtained, the second digital currency is cancelled, and the first digital currency is updated according to the target payment amount.

19. A method of payment based on a digital currency, characterized by, Applied to a first terminal; comprising: In response to a first trigger, a prepayment request is generated, and the prepayment request is sent to a payment platform; the prepayment request indicates a second account and a prepayment amount; A first digital currency corresponding to the prepayment amount is received, and the first digital currency in a frozen state is stored in the second account; In response to a second trigger, a target payment request for the first digital currency is generated, and the target payment request is sent to the payment platform, so that the payment platform generates new first digital currency in a frozen state according to the difference between the first digital currency and the target payment amount, and a prepayment cancellation smart contract; wherein the prepayment cancellation smart contract is written as a field of the new first digital currency in a frozen state in the first digital currency; Wherein, according to the second signature information of the second account, the prepayment request and / or the target payment request is generated.

20. The method of claim 19, wherein, Further comprising: In response to the feedback of the payment platform to the prepayment request and / or the target payment request, the second signature information of the second account is sent to the payment platform.

21. The method of claim 19, wherein, Further comprising: A payment identifier or a payment image corresponding to a first account is obtained to determine the first account; According to the first account and the second trigger, the target payment request is generated.

22. The method of claim 21, wherein, Further comprising: A prepayment recovery prompt sent by the payment platform is received, and the prepayment recovery prompt is displayed; When receiving recovery information input according to the prepayment recovery prompt, a prepayment recovery request is generated according to the first account and the second account included in the recovery information, and the prepayment recovery request is sent to the payment platform.

23. A digital currency based payment platform characterized in that, Comprising: A request receiving module, a cancellation module and a currency sending module; wherein, The request receiving module is configured to receive a target payment request for a first digital currency in a frozen state, the first digital currency in the frozen state being generated based on a prepayment request and a preconfigured prepayment deposit smart contract; The verification module is configured to generate a second digital currency corresponding to a target payment amount indicated by the target payment request, the first digital currency, and a preconfigured prepayment verification smart contract; The currency sending module is configured to send the second digital currency to a first account corresponding to the first digital currency; A new first digital currency in a frozen state is generated according to a 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 the frozen state; In a case where a cancellation request for the first digital currency is received, in a case where a revocation request sent by the first terminal for the cancellation request is received, whether the first digital currency is revocable is determined according to a preconfigured prepayment revocation smart contract; if yes, first signature information of the first account and second signature information of a second account corresponding to the prepayment request are obtained; in a case where the first signature information and the second signature information are obtained, a state of the first digital currency is set to an available state, and the first digital currency is sent to the second account; if no, the revocation request is rejected. 24.A first terminal based on a digital currency payment, characterized by, Comprise: a prepayment request sending module, a frozen currency storage module, and a target payment request sending module; wherein The prepayment request sending module is configured to generate a prepayment request in response to a first trigger, and send the prepayment request to a payment platform; the prepayment request indicates a second account and a prepayment amount; The frozen currency storage module is configured to receive a first digital currency corresponding to the prepayment amount, and store the first digital currency in a frozen state in the second account; The target request sending module is configured to generate a target payment request for the first digital currency in response to a second trigger, and send the target payment request to the payment platform, so that the payment platform generates a new first digital currency in a frozen state according to a 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 the frozen state; wherein the prepayment request and / or the target payment request is generated according to second signature information of the second account.

25. A digital currency based payment system characterized in that, Comprise: The payment platform of claim 23 and the first terminal of claim 24.

26. The payment system of claim 25, wherein, Further comprise: a second terminal; wherein The second terminal is configured to receive a second digital currency and store the second digital currency in a 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.

27. The payment system of claim 26, wherein, The second terminal is configured to receive payment information about the prepayment recovery request sent by the payment platform, the payment information indicating a first account, a second account, and an amount indicated by the prepayment recovery request. According to the payment information, the prepayment recovery request is verified, and when the verification is passed, first signature information of the first account is sent to the payment platform.

28. An electronic device for digital currency payment based, characterized by, Comprising: one or more processors; a 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 of any one of claims 1-22.

29. A computer readable medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-22.

Images