Red packet-based transaction method, device and electronic equipment
By querying the payer's hardware wallet associated with the red packet account and matching the payment rules for digital currency, the convenience issue of hardware wallet red packet processing logic is resolved, and the user experience of hardware wallets and software wallets is aligned.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- THE PEOPLES BANK OF CHINA DIGITAL CURRENCY INST
- Filing Date
- 2023-10-23
- Publication Date
- 2026-07-03
AI Technical Summary
The existing red envelope processing logic cannot meet the flexibility and convenience requirements of hard wallets in terms of issuing, inheriting, using and recycling. Hard wallets cannot obtain red envelopes in real time during payment, and users cannot view red envelopes in real time, which lacks convenience.
By receiving transaction requests, querying the payer's hardware wallet associated with the red packet account, and matching payment digital currency according to usage rules, the system supports the issuance, querying, and refund processing of red packets, achieving experience alignment between hardware and software wallets.
This enables digital currency hardware wallets to use red envelopes, allowing digital wallet operators to check red envelope usage in real time, achieving the same level of convenience as software wallets in terms of marketing capabilities.
Smart Images

Figure CN119887197B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital currency technology, and in particular to a transaction method, apparatus, electronic device, and computer-readable medium based on red envelopes. Background Technology
[0002] With the increasing adoption of digital currency hardware wallets, existing red envelope processing logic can no longer meet market demands. Specifically, hardware wallets face the following technical challenges in the processes of receiving, viewing, and using red envelopes:
[0003] (1) There is a lack of red envelope solutions based on hardware wallets on the market, including red envelopes issued to hardware wallets, red envelopes inherited by hardware wallets from the parent wallet, and the use and recycling of corresponding red envelopes.
[0004] (2) Commercially available hardware wallets lack flexibility and convenience in issuing, using, and viewing red envelopes. For example, red envelopes need to be written into the hardware to be issued and used. Hardware wallets cannot obtain red envelopes from the red envelope management platform in real time during payment, and users cannot view the red envelopes under the hardware wallet in real time, resulting in a lack of convenience. Summary of the Invention
[0005] In view of this, embodiments of the present invention provide a transaction method, apparatus, electronic device, and computer-readable medium based on red envelopes to solve the technical problem that existing red envelope processing logic can no longer meet market demands.
[0006] To achieve the above objectives, according to one aspect of the present invention, a transaction method based on red envelopes is provided, wherein the red envelope is a digital currency with attached usage rules, and the method includes:
[0007] Receive a transaction request sent by the sales terminal, the transaction request carrying the transaction amount, the recipient's wallet number and the payer's wallet number;
[0008] The red packet account associated with the payer's hard wallet is retrieved based on the payer's wallet number, wherein the red packet account is used to receive red packets;
[0009] In response to the transaction request matching the usage rules of the red envelope, digital currency corresponding to the transaction amount is paid to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red envelope account.
[0010] Optionally, before receiving a transaction request sent by the sales terminal, the method further includes:
[0011] Determine whether the red envelope was sent to the red envelope account linked to the payer's hardware wallet via mobile phone number;
[0012] If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet;
[0013] If not, the red packet will be sent from the funder's red packet account to the red packet account associated with the payer's hard wallet via the hard wallet number.
[0014] Optionally, distributing the red packet from the funder's red packet account to the red packet account associated with the payer's hardware wallet includes:
[0015] Determine whether the payer has activated a soft wallet;
[0016] If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet;
[0017] If not, the payer is guided to open a soft wallet in the digital currency application and bind the soft wallet to the payer's hard wallet, and the red packet is sent from the funder's red packet account to the red packet account associated with the payer's hard wallet.
[0018] Optionally, in response to the transaction request matching the usage rules of the red envelope, payment of digital currency corresponding to the transaction amount to the wallet corresponding to the recipient's wallet number is made based on the wallet corresponding to the payer's wallet number and the red envelope account, including:
[0019] Determine whether the red envelope account contains red envelopes whose usage rules match the transaction request;
[0020] If so, the red packet will be transferred from the red packet account to the wallet corresponding to the recipient's wallet number, and / or the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the recipient's wallet number, in order to pay the digital currency corresponding to the transaction amount;
[0021] If not, the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the payee's wallet number, in order to pay the digital currency corresponding to the transaction amount.
[0022] Optionally, the transaction request is triggered by either the payer's hardware wallet or the payer's software wallet.
[0023] Optionally, the red packet account associated with the payer's hard wallet can be queried and retrieved based on the payer's wallet ID, including:
[0024] Determine whether the payer's wallet number is a hard wallet number;
[0025] If so, then query and retrieve the red packet account associated with the payer's hard wallet based on the payer's hard wallet number;
[0026] If not, then query and obtain the hardware wallet bound to the soft wallet based on the payer's soft wallet number, and then query and obtain the red envelope account associated with the hardware wallet based on the hardware wallet number.
[0027] Optionally, the method further includes:
[0028] Receive a refund request sent by the sales terminal, the refund request carrying the refund amount, the wallet number of the refunder and the wallet number of the payer;
[0029] Determine whether the payment method for the transaction corresponding to the refund request is a combination of red envelope and wallet balance payment method;
[0030] If so, the red packet will be returned from the refunder's wallet to the payer's red packet account, and / or, the wallet balance will be returned from the refunder's wallet to the payer's hardware wallet or a software wallet bound to the hardware wallet;
[0031] If not, the red envelope will be returned to the payer's red envelope account.
[0032] Optionally, returning the red envelope from the refunder's wallet to the payer's red envelope account includes:
[0033] Determine whether the red envelope refunded from the refunder's wallet to the payer's red envelope account has expired;
[0034] If not, the red envelope will be returned to the payer's red envelope account;
[0035] If so, the red envelope will be returned to the funder's red envelope account, or the red envelope will be returned to the payer's red envelope account and the validity period of the red envelope will be extended.
[0036] Optionally, returning the red envelope to the payer's red envelope account includes:
[0037] Determine whether the red envelope is a special red envelope for hard wallets;
[0038] If yes, determine whether the payer's hard wallet has been cancelled; if no, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
[0039] If not, determine whether the payer's soft wallet has been cancelled; if not, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
[0040] Furthermore, according to another aspect of the present invention, a transaction device based on red envelopes is provided, wherein the red envelopes are digital currencies with attached usage rules, and the device includes:
[0041] The receiving module is used to receive transaction requests sent by the sales terminal, wherein the transaction request carries the transaction amount, the wallet number of the payee and the wallet number of the payer;
[0042] The query module is used to query and obtain the red packet account associated with the payer's hard wallet based on the payer's wallet number, wherein the red packet account is used to receive red packets;
[0043] The processing module is used to respond to the transaction request and match the usage rules of the red envelope, and pay the digital currency corresponding to the transaction amount to the wallet corresponding to the wallet number of the payer and the red envelope account.
[0044] Optionally, the device further includes a dispensing module for:
[0045] Determine whether the red envelope was sent to the red envelope account linked to the payer's hardware wallet via mobile phone number;
[0046] If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet;
[0047] If not, the red packet will be sent from the funder's red packet account to the red packet account associated with the payer's hard wallet via the hard wallet number.
[0048] Optionally, the disbursement module is further configured to:
[0049] Determine whether the payer has activated a soft wallet;
[0050] If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet;
[0051] If not, the payer is guided to open a soft wallet in the digital currency application and bind the soft wallet to the payer's hard wallet, and the red packet is sent from the funder's red packet account to the red packet account associated with the payer's hard wallet.
[0052] Optionally, the processing module is further configured to:
[0053] Determine whether the red envelope account contains red envelopes whose usage rules match the transaction request;
[0054] If so, the red packet will be transferred from the red packet account to the wallet corresponding to the recipient's wallet number, and / or the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the recipient's wallet number, in order to pay the digital currency corresponding to the transaction amount;
[0055] If not, the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the payee's wallet number, in order to pay the digital currency corresponding to the transaction amount.
[0056] Optionally, the transaction request is triggered by either the payer's hardware wallet or the payer's software wallet.
[0057] Optionally, the query module is further used for:
[0058] Determine whether the payer's wallet number is a hard wallet number;
[0059] If so, then query and retrieve the red packet account associated with the payer's hard wallet based on the payer's hard wallet number;
[0060] If not, then query and obtain the hardware wallet bound to the soft wallet based on the payer's soft wallet number, and then query and obtain the red envelope account associated with the hardware wallet based on the hardware wallet number.
[0061] Optionally, the processing module is further configured to:
[0062] Receive a refund request sent by the sales terminal, the refund request carrying the refund amount, the wallet number of the refunder and the wallet number of the payer;
[0063] Determine whether the payment method for the transaction corresponding to the refund request is a combination of red envelope and wallet balance payment method;
[0064] If so, the red packet will be returned from the refunder's wallet to the payer's red packet account, and / or, the wallet balance will be returned from the refunder's wallet to the payer's hardware wallet or a software wallet bound to the hardware wallet;
[0065] If not, the red envelope will be returned to the payer's red envelope account.
[0066] Optionally, the processing module is further configured to:
[0067] Determine whether the red envelope refunded from the refunder's wallet to the payer's red envelope account has expired;
[0068] If not, the red envelope will be returned to the payer's red envelope account;
[0069] If so, the red envelope will be returned to the funder's red envelope account, or the red envelope will be returned to the payer's red envelope account and the validity period of the red envelope will be extended.
[0070] Optionally, the processing module is further configured to:
[0071] Determine whether the red envelope is a special red envelope for hard wallets;
[0072] If yes, determine whether the payer's hard wallet has been cancelled; if no, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
[0073] If not, determine whether the payer's soft wallet has been cancelled; if not, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
[0074] According to another aspect of the present invention, an electronic device is also provided, comprising:
[0075] One or more processors;
[0076] Storage device for storing one or more programs.
[0077] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.
[0078] According to another aspect of the present invention, a computer-readable medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the methods described in any of the above embodiments.
[0079] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.
[0080] One embodiment of the above invention has the following advantages or beneficial effects: Because it employs a technical means of querying and obtaining the red packet account associated with the payer's hard wallet based on the payer's wallet number, and responding to the transaction request and matching the red packet usage rules, it pays the corresponding digital currency to the wallet corresponding to the recipient's wallet number based on the wallet and red packet account corresponding to the payer's wallet number. Therefore, it overcomes the technical problem that existing red packet processing logic in the prior art can no longer meet market demands. This invention enables digital currency hard wallets to use red packets, allowing digital wallet operators to query red packet usage in real time during hard wallet payments, realizing the use of red packets in hard wallets, and essentially achieving the same level of marketing capabilities as soft wallets, thus aligning the user experience of hard wallets with that of soft wallets.
[0081] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description
[0082] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:
[0083] Figure 1 This is a flowchart of a transaction method based on red envelopes according to the first embodiment of the present invention;
[0084] Figure 2 This is a flowchart of a transaction method based on red envelopes according to a second embodiment of the present invention;
[0085] Figure 3 This is a flowchart of a transaction method based on red envelopes according to a third embodiment of the present invention;
[0086] Figure 4 This is a flowchart of a transaction method based on red envelopes according to the fourth embodiment of the present invention;
[0087] Figure 5 This is a flowchart of a transaction method based on red envelopes according to the fifth embodiment of the present invention;
[0088] Figure 6 This is a schematic diagram of a transaction device based on red envelopes according to an embodiment of the present invention;
[0089] Figure 7 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;
[0090] Figure 8This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation
[0091] 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.
[0092] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.
[0093] Figure 1 This is a flowchart of a transaction method based on red envelopes according to a first embodiment of the present invention. As one embodiment of the present invention, such as... Figure 1 As shown, the transaction method based on red envelopes, when applied to digital wallet operators, may include:
[0094] Step 101: Receive a transaction request sent by the sales terminal. The transaction request carries the transaction amount, the recipient's wallet number, and the payer's wallet number.
[0095] Optionally, the transaction request is triggered based on the payer's hardware wallet or software wallet. Specifically, the payer uses the corresponding hardware wallet to pay according to the usage rules displayed on the red packet details page. For example, the payer conducts a transaction with a sales terminal (such as a POS machine) via tap-to-pay using a hardware wallet (e.g., a mobile phone, SIM card, bank card, or wearable device). The sales terminal sends a transaction request to the digital wallet operator, which carries the transaction amount, the recipient's wallet number, and the payer's hardware wallet number. Alternatively, the payer conducts a transaction with the sales terminal using a software wallet, which sends a transaction request to the digital wallet operator, carrying the transaction amount, the recipient's wallet number, and the payer's software wallet number.
[0096] After receiving a transaction request from a sales terminal, the digital wallet operator parses it to obtain the transaction amount, the recipient's wallet number, and the sender's wallet number carried in the transaction request.
[0097] Step 102: Query and obtain the red packet account associated with the payer's hard wallet based on the payer's wallet number, wherein the red packet account is used to receive red packets;
[0098] After parsing the transaction amount, the recipient's wallet number, and the sender's wallet number from the transaction request, the digital wallet operator queries and retrieves the red envelope account associated with the sender's hardware wallet based on the sender's wallet number. Optionally, step 102 may include: determining whether the sender's wallet number is a hardware wallet number; if so, querying and retrieving the red envelope account associated with the sender's hardware wallet based on the sender's hardware wallet number; if not, querying and retrieving the hardware wallet bound to the sender's software wallet based on the sender's software wallet number, and then querying and retrieving the red envelope account associated with the software wallet based on the hardware wallet number. In an embodiment of the present invention, the red envelope account associated with the payer's hard wallet can be queried and obtained through the hard wallet number. Therefore, it is first determined whether the wallet number of the payer carried in the transaction request is a hard wallet number or a soft wallet number. If it is a hard wallet number, the red envelope account associated with the payer's hard wallet can be directly queried and obtained based on the hard wallet number. If it is a soft wallet number, the hard wallet bound to the soft wallet can be queried and obtained based on the soft wallet number first, and then the red envelope account associated with the hard wallet can be queried and obtained based on the hard wallet number.
[0099] It should be noted that if a soft wallet is bound to a hard wallet, then the soft wallet is the parent wallet of the hard wallet. In other words, a hard wallet can be bound to a soft wallet, meaning the soft wallet is the parent wallet and the hard wallet is the child wallet, and the two have a parent-child relationship.
[0100] Step 103: In response to the transaction request matching the usage rules of the red packet, digital currency corresponding to the transaction amount is paid to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red packet account.
[0101] In this step, the digital wallet operator responds to the transaction request matching the usage rules of the red packet, and pays the digital currency corresponding to the transaction amount to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red packet account.
[0102] In embodiments of this invention, the payer does not need to manually select which red envelope to use or the quantity (specific restrictions are set by the digital wallet operator or funder). The digital wallet operator deducts funds based on the available red envelopes in the payer's account, following a pre-defined order. When the payer makes a payment, red envelopes with nearing their expiration dates are silently deducted first. If the total amount of deducted red envelopes is less than the transaction amount, then the wallet balance is deducted. Therefore, when the total amount of usable red envelopes is greater than or equal to the transaction amount, a red envelope payment method is used; when the total amount of usable red envelopes is less than the transaction amount, a combination of red envelopes and wallet balance is used.
[0103] Optionally, step 103 may include: determining whether there is a red packet in the red packet account whose usage rules match the transaction request; if so, transferring the red packet from the red packet account to the wallet corresponding to the recipient's wallet number, and / or transferring the wallet balance from the payer's hardware wallet or a software wallet bound to the hardware wallet to the wallet corresponding to the recipient's wallet number to pay the digital currency corresponding to the transaction amount; if not, transferring the wallet balance from the payer's hardware wallet or a software wallet bound to the hardware wallet to the wallet corresponding to the recipient's wallet number to pay the digital currency corresponding to the transaction amount. In this step, it is first determined whether there is a matching red packet in the payer's red packet account that matches the transaction request. If there is, the matching red packet is transferred from the payer's red packet account to the recipient's wallet (which can be the recipient's red packet account). If the total amount of the red packet deducted is less than the transaction amount, the wallet balance of the hardware wallet and the software wallet is deducted. If there is no matching red packet, the wallet balance is transferred from the payer's hardware wallet or software wallet to the recipient's wallet (which can be either a software wallet or a hardware wallet).
[0104] It should be noted that if it is an account-based hardware wallet, the wallet balance will be transferred from the payer's soft wallet to the payee's wallet. If it is a quasi-account-based hardware wallet, the wallet balance will be transferred from the payer's hardware wallet to the payee's wallet.
[0105] If the red envelope expires unused, it will be refunded from the payer's red envelope account to the funder's red envelope account upon expiration.
[0106] Based on the various embodiments described above, it can be seen that the embodiments of the present invention solve the technical problem that the existing red packet processing logic in the prior art can no longer meet market demands. This is achieved by querying and obtaining the red packet account associated with the payer's wallet number based on the payer's wallet number, responding to the transaction request and matching the red packet usage rules, and paying the wallet corresponding to the transaction amount with digital currency based on the wallet and red packet account corresponding to the payer's wallet number. The embodiments of the present invention enable digital currency hard wallets to use red packets. Digital wallet operators can query the red packet usage in real time during hard wallet payments, realizing the use of red packets in hard wallets, and basically achieving the same level of marketing capabilities as soft wallets, thus aligning the user experience of hard wallets with that of soft wallets.
[0107] Figure 2 This is a flowchart of a transaction method based on red envelopes according to a second embodiment of the present invention. As another embodiment of the present invention, such as... Figure 2 As shown, the transaction method based on red envelopes may include:
[0108] Step 201: Send the red envelope to the payer's red envelope account.
[0109] First, the digital wallet operator distributes the red envelope to the payer's account. For example, the digital wallet operator distributes the red envelope to the payer's account via mobile phone number or hardware wallet number, and the red envelope is claimed immediately upon distribution, so the payer does not need to manually claim it again. The digital wallet operator may or may not be a funder; this embodiment of the invention does not impose any restrictions on this.
[0110] Optionally, step 201 may include: determining whether the red envelope is sent to the red envelope account associated with the payer's hard wallet via a mobile phone number; if yes, then the red envelope is sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet; if no, then the red envelope is sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet via the hard wallet number. The digital wallet operator can pre-configure the red envelope distribution method, such as sending via mobile phone number or via hard wallet number. When distributing a red envelope, the digital wallet operator reads the red envelope distribution method to determine whether the red envelope is sent to the red envelope account associated with the payer's hard wallet via a mobile phone number. If yes, the red envelope is sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet. If not, the red envelope is sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet via the hard wallet number; distribution is equivalent to receipt.
[0111] Since the soft wallet is linked to the hard wallet, if a red envelope is sent via a mobile phone number to a red envelope account associated with the payer's hard wallet, the process first queries and retrieves the soft wallet associated with that mobile phone number, then queries and retrieves the hard wallet associated with that soft wallet, and finally queries and retrieves the red envelope account associated with that hard wallet.
[0112] Sending the red envelope from the funder's red envelope account to the red envelope account associated with the payer's hard wallet includes: determining whether the payer has already activated a soft wallet; if so, sending the red envelope from the funder's red envelope account to the red envelope account associated with the payer's hard wallet; if not, guiding the payer to activate a soft wallet in the digital currency application and bind the soft wallet to the payer's hard wallet, then sending the red envelope from the funder's red envelope account to the red envelope account associated with the payer's hard wallet. If the payer has not yet activated a soft wallet from a digital wallet operator, they need to be guided to activate a soft wallet in the digital currency app first, and automatically receive the red envelope after binding the soft wallet to the hard wallet. Activating a soft wallet requires the payer to provide a mobile phone number, and the mobile phone number is linked to the soft wallet. If the payer has already activated a soft wallet in the digital currency app, when sending the red envelope via mobile phone number, the red envelope is sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet.
[0113] Digital wallet operators can also configure usage rules for red envelopes, including but not limited to: available merchants, usage period, transaction amount, wallet mode (such as account-mode hardware wallet, quasi-account-mode hardware wallet, etc.), media type (such as SIM card, mobile payment, etc.), specified hardware wallet (such as specified wallet number), specified mobile phone number, and whether it is dedicated to hardware wallets. Digital wallet operators can configure one or more usage rules for red envelopes. Red envelopes under hardware wallets have the ability to combine multiple usage rules. Digital wallet operators can restrict the usage rules of red envelopes from different dimensions, such as combining restrictions on the usage medium and available merchants of red envelopes, and red envelopes that have expired and are not used can be automatically returned to the funder. It should be noted that the embodiments of the present invention are applicable to account-mode hardware wallets or quasi-account-mode hardware wallets.
[0114] Optionally, the method further includes: receiving a red envelope query request sent by a terminal, the red envelope query request carrying a mobile phone number or a soft wallet number; returning each red envelope in the red envelope account to the terminal; wherein the red envelope is issued via the mobile phone number; or, receiving a red envelope query request sent by a terminal, the red envelope query request carrying a soft wallet number or a hardware wallet number; returning each red envelope in the red envelope account to the terminal; wherein the soft wallet is the parent wallet of the hardware wallet, and the red envelope is issued via the hardware wallet number. The hardware wallet can be bound to the soft wallet, that is, the soft wallet is the parent wallet, and the hardware wallet is the child wallet, with a parent-child relationship.
[0115] In some embodiments of the present invention, for red envelopes sent to a red envelope account via a mobile phone number, the payer can use the mobile phone number or the soft wallet number to query each red envelope in the red envelope account. In other embodiments of the present invention, for red envelopes sent to a red envelope account via a hard wallet number, the payer can use the hard wallet number or the soft wallet number of the hard wallet (the two are in a parent-child relationship) to query each red envelope under the red envelope account, but cannot use the mobile phone number to query each red envelope under the red envelope account. Red envelopes sent via hard wallet number have the ability to be received immediately after sending, and can be viewed within the associated soft wallet, thus making the sending, receiving, and viewing of hard wallet red envelopes flexible and convenient. It should be noted that hard wallets not bound to a soft wallet can only query red envelopes in the red envelope account via the hard wallet number.
[0116] Step 202: Receive a transaction request sent by the sales terminal, the transaction request carrying the transaction amount, the recipient's wallet number and the payer's wallet number.
[0117] Optionally, the transaction request is triggered based on the payer's hardware wallet or software wallet. Specifically, the payer uses the corresponding hardware wallet to pay according to the usage rules displayed on the red packet details page. For example, the payer conducts a transaction with a sales terminal (such as a POS machine) via tap-to-pay using a hardware wallet (e.g., a mobile phone, SIM card, bank card, or wearable device). The sales terminal sends a transaction request to the digital wallet operator, which carries the transaction amount, the recipient's wallet number, and the payer's hardware wallet number. Alternatively, the payer conducts a transaction with the sales terminal using a software wallet, which sends a transaction request to the digital wallet operator, carrying the transaction amount, the recipient's wallet number, and the payer's software wallet number.
[0118] After receiving a transaction request from a sales terminal, the digital wallet operator parses it to obtain the transaction amount, the recipient's wallet number, and the sender's wallet number carried in the transaction request.
[0119] Step 203: Determine whether the payer's wallet number is a hard wallet number; if yes, proceed to step 204; if no, proceed to step 205.
[0120] Step 204: Query and obtain the red packet account associated with the payer's hard wallet based on the payer's hard wallet number.
[0121] If the payer's wallet number carried in the transaction request is a hard wallet number, then the red packet account associated with the payer's hard wallet can be directly queried and obtained based on the payer's hard wallet number.
[0122] Step 205: Query and obtain the hardware wallet bound to the soft wallet based on the payer's soft wallet number, and then query and obtain the red envelope account associated with the hardware wallet based on the hardware wallet number.
[0123] If the wallet number of the payer carried in the transaction request is a soft wallet number, then first query and obtain the hardware wallet bound to the soft wallet based on the payer's soft wallet number, indicating that the soft wallet is the parent wallet of the hardware wallet. Then query and obtain the red packet account associated with the hardware wallet based on the hardware wallet number.
[0124] Step 206: In response to the transaction request matching the usage rules of the red packet, digital currency corresponding to the transaction amount is paid to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red packet account.
[0125] In this step, the digital wallet operator responds to the transaction request matching the usage rules of the red packet, and pays the digital currency corresponding to the transaction amount to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red packet account.
[0126] In embodiments of this invention, the payer does not need to manually select which red envelope to use or the quantity (specific restrictions are set by the digital wallet operator or funder). The digital wallet operator deducts funds based on the available red envelopes in the payer's account, following a pre-defined order. When the payer makes a payment, red envelopes with nearing their expiration dates are silently deducted first. If the total amount of deducted red envelopes is less than the transaction amount, then the wallet balance is deducted. Therefore, when the total amount of usable red envelopes is greater than or equal to the transaction amount, a red envelope payment method is used; when the total amount of usable red envelopes is less than the transaction amount, a combination of red envelopes and wallet balance is used.
[0127] Red packets issued through a hard wallet number have both specificity and extensibility. The hard wallet and the soft wallet have a parent-child relationship, so the red packets have both specificity and extensibility. That is, although the red packets are issued through a hard wallet number, they are not limited to use in the hard wallet after being received. They can also be used in the parent wallet, and other media types of hard wallets under the parent wallet are also applicable.
[0128] The embodiments of the present invention enable digital currency hard wallets to use red envelopes. Digital wallet operators can check the red envelope usage in real time when making payments with hard wallets, realize the use of red envelopes with hard wallets, and basically reach the same level of marketing capabilities as soft wallets, so that the user experience of hard wallets and soft wallets are aligned.
[0129] Figure 3 This is a flowchart of a transaction method based on red envelopes according to a third embodiment of the present invention. As another embodiment of the present invention, such as... Figure 3 As shown, the transaction method based on red envelopes may include:
[0130] Step 301: Receive a transaction request sent by the sales terminal, the transaction request carrying the transaction amount, the recipient's wallet number and the payer's wallet number.
[0131] Step 302: Query and obtain the red packet account associated with the payer's hard wallet based on the payer's wallet number, wherein the red packet account is used to receive red packets.
[0132] Step 303: In response to the transaction request matching the usage rules of the red packet, digital currency corresponding to the transaction amount is paid to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red packet account.
[0133] Steps 301-302 in the third embodiment are similar to steps 101-103 in the first embodiment, and will not be described again.
[0134] Step 304: Receive a refund request sent by the sales terminal. The refund request carries the refund amount, the wallet number of the refunder, and the wallet number of the payer.
[0135] Step 305: Determine whether the payment method of the transaction corresponding to the refund request is a combination of red envelope and wallet balance; if yes, proceed to step 306; if no, proceed to step 307.
[0136] Step 306: Return the red packet from the refunder's wallet to the payer's red packet account, and / or return the wallet balance from the refunder's wallet to the payer's hardware wallet or a software wallet bound to the hardware wallet.
[0137] Step 307: Return the red envelope to the payer's red envelope account.
[0138] In embodiments of the present invention, the red envelopes support both full and partial refunds. Refunds are processed according to the original amount used; the exact amount of the red envelope used is returned. Optionally, the red envelope can be refunded from the refunder's wallet to the payer's red envelope account.
[0139] If the transaction for which the refund request corresponds to a payment method combining a red packet and wallet balance, then not only must the red packet be refunded, but the wallet balance must also be refunded from the refunder's wallet to the payer's hardware wallet or the software wallet linked to that hardware wallet. If the transaction for which the refund request corresponds to a payment method based on a red packet, then only the red packet needs to be refunded from the refunder's wallet to the payer's red packet account.
[0140] Optionally, if the payment method for the transaction corresponding to the refund request is a combination of red packet and wallet balance, the red packet will first be refunded from the refunder's wallet to the payer's red packet account. If the refund amount is greater than the total amount of the red packet, the wallet balance will then be refunded from the refunder's wallet to the payer's hardware wallet or the software wallet bound to that hardware wallet.
[0141] Furthermore, the specific implementation details of the transaction method based on red envelopes in one of the reference embodiments of the present invention have been described in detail in the above-described transaction method based on red envelopes, so the details will not be repeated here.
[0142] Figure 4 This is a flowchart of a transaction method based on red envelopes according to a fourth embodiment of the present invention. As another embodiment of the present invention, this embodiment is similar to the third embodiment; in the fourth embodiment, as... Figure 4 As shown, step 307, "returning the red envelope to the payer's red envelope account," can specifically include the following steps:
[0143] Step 401: Determine whether the red envelope refunded from the refunder's wallet to the payer's red envelope account has expired; if not, proceed to step 402; if yes, proceed to step 403.
[0144] Step 402: Return the red envelope to the payer's red envelope account.
[0145] Step 403: Return the red envelope to the funder's red envelope account, or return the red envelope to the payer's red envelope account and extend the validity period of the red envelope.
[0146] In the fourth embodiment, during the process of returning the red envelope from the refunder's wallet to the payer's red envelope account, based on the usage period and the current time, it is determined whether the red envelope returned from the refunder's wallet to the payer's red envelope account has expired. If the red envelope has not expired, it is returned to the payer's red envelope account; if the red envelope has expired, it is returned to the funder's red envelope account, or the red envelope is returned to the payer's red envelope account and the validity period of the red envelope is extended.
[0147] It should be noted that the funder or digital wallet operator can agree in advance on how to handle the expiration of the red envelope. If the method is to extend the validity period of the red envelope, the length of the validity period can also be agreed upon.
[0148] Furthermore, the specific implementation details of the transaction method based on red envelopes in one of the reference embodiments of the present invention have been described in detail in the above-described transaction method based on red envelopes, so the details will not be repeated here.
[0149] Figure 5 This is a flowchart of a transaction method based on red envelopes according to a fifth embodiment of the present invention. As another embodiment of the present invention, this embodiment is similar to the second embodiment; in the fifth embodiment, as... Figure 5 As shown, step 307, "returning the red envelope to the payer's red envelope account," can specifically include the following steps:
[0150] Step 401: Determine whether the red envelope refunded from the refunder's wallet to the payer's red envelope account has expired; if not, proceed to step 402; if yes, proceed to step 407.
[0151] Step 402: Determine whether the red envelope is a special red envelope for hard wallets; if yes, proceed to step 403; if no, proceed to step 406.
[0152] Step 403: Determine whether the payer's hard wallet has been cancelled; if not, proceed to step 404; if yes, proceed to step 405.
[0153] Step 404: Return the red envelope to the payer's red envelope account.
[0154] Step 405: Return the red envelope to the funder's red envelope account.
[0155] Step 406: Determine whether the payer's soft wallet has been cancelled; if not, proceed to step 404; if yes, proceed to step 405.
[0156] Step 407: Return the red envelope to the funder's red envelope account, or return the red envelope to the payer's red envelope account and extend the validity period of the red envelope.
[0157] In the fifth embodiment, during the process of returning the red envelope from the refunder's wallet to the payer's red envelope account, based on the usage period and the current time, it is determined whether the red envelope returned from the refunder's wallet to the payer's red envelope account has expired. If the red envelope has not expired, it is further determined whether the red envelope is a hard wallet-specific red envelope. If the red envelope is a hard wallet-specific red envelope, it is further determined whether the payer's hard wallet has been cancelled. If the hard wallet has been cancelled, the red envelope is retrieved, that is, the red envelope is returned to the funder's red envelope account. If the hard wallet has not been cancelled, the red envelope is returned to the payer's red envelope account. If the red envelope is not a hard wallet-specific red envelope, it is determined whether the payer's soft wallet has been cancelled. If the soft wallet has been cancelled, the red envelope is retrieved, that is, the red envelope is returned to the funder's red envelope account. If the soft wallet has not been cancelled, the red envelope is returned to the payer's red envelope account.
[0158] If the red envelope has expired, it will be returned to the funder's red envelope account, or the red envelope will be returned to the payer's red envelope account and its validity period will be extended.
[0159] If a soft wallet is cancelled, all red packets under the soft wallet will be automatically refunded to the funder's red packet account, without waiting for the red packet expiration date; if a hard wallet is cancelled, red packets specifically for the hard wallet will be automatically refunded to the funder's red packet account. However, unbinding the hard wallet from the parent wallet will not result in the red packet being reclaimed.
[0160] Therefore, this invention provides a transaction method based on red envelopes, which covers functions such as restrictions, issuance, receipt, viewing, use, refund, and recycling of red envelopes, thus aligning the user experience of hardware wallets with that of software wallets.
[0161] Furthermore, the specific implementation details of the transaction method based on red envelopes in one of the reference embodiments of the present invention have been described in detail in the above-described transaction method based on red envelopes, so the details will not be repeated here.
[0162] Figure 6 This is a schematic diagram of a transaction device based on red envelopes according to an embodiment of the present invention. Figure 6As shown, the transaction device 600 based on red envelopes includes a receiving module 601, a query module 602, and a processing module 603. The receiving module 601 receives a transaction request sent by a sales terminal, the transaction request carrying a transaction amount, the recipient's wallet number, and the payer's wallet number. The query module 602 queries and retrieves a red envelope account associated with the payer's hard wallet based on the payer's wallet number, wherein the red envelope account is used to receive red envelopes, and the red envelopes are digital currencies with usage rules. The processing module 603, in response to the transaction request matching the red envelope usage rules, pays the digital currency corresponding to the transaction amount to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red envelope account.
[0163] Optionally, the device further includes a dispensing module for:
[0164] Determine whether the red envelope was sent to the red envelope account linked to the payer's hardware wallet via mobile phone number;
[0165] If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet;
[0166] If not, the red packet will be sent from the funder's red packet account to the red packet account associated with the payer's hard wallet via the hard wallet number.
[0167] Optionally, the disbursement module is further configured to:
[0168] Determine whether the payer has activated a soft wallet;
[0169] If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet;
[0170] If not, the payer is guided to open a soft wallet in the digital currency application and bind the soft wallet to the payer's hard wallet, and the red packet is sent from the funder's red packet account to the red packet account associated with the payer's hard wallet.
[0171] Optionally, the processing module 603 is further configured to:
[0172] Determine whether the red envelope account contains red envelopes whose usage rules match the transaction request;
[0173] If so, the red packet will be transferred from the red packet account to the wallet corresponding to the recipient's wallet number, and / or the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the recipient's wallet number, in order to pay the digital currency corresponding to the transaction amount;
[0174] If not, the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the payee's wallet number, in order to pay the digital currency corresponding to the transaction amount.
[0175] Optionally, the transaction request is triggered by either the payer's hardware wallet or the payer's software wallet.
[0176] Optionally, the query module 602 is further configured to:
[0177] Determine whether the payer's wallet number is a hard wallet number;
[0178] If so, then query and retrieve the red packet account associated with the payer's hard wallet based on the payer's hard wallet number;
[0179] If not, then query and obtain the hardware wallet bound to the soft wallet based on the payer's soft wallet number, and then query and obtain the red envelope account associated with the hardware wallet based on the hardware wallet number.
[0180] Optionally, the processing module 603 is further configured to:
[0181] Receive a refund request sent by the sales terminal, the refund request carrying the refund amount, the wallet number of the refunder and the wallet number of the payer;
[0182] Determine whether the payment method for the transaction corresponding to the refund request is a combination of red envelope and wallet balance payment method;
[0183] If so, the red packet will be returned from the refunder's wallet to the payer's red packet account, and / or, the wallet balance will be returned from the refunder's wallet to the payer's hardware wallet or a software wallet bound to the hardware wallet;
[0184] If not, the red envelope will be returned to the payer's red envelope account.
[0185] Optionally, the processing module 603 is further configured to:
[0186] Determine whether the red envelope refunded from the refunder's wallet to the payer's red envelope account has expired;
[0187] If not, the red envelope will be returned to the payer's red envelope account;
[0188] If so, the red envelope will be returned to the funder's red envelope account, or the red envelope will be returned to the payer's red envelope account and the validity period of the red envelope will be extended.
[0189] Optionally, the processing module 603 is further configured to:
[0190] Determine whether the red envelope is a special red envelope for hard wallets;
[0191] If yes, determine whether the payer's hard wallet has been cancelled; if no, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
[0192] If not, determine whether the payer's soft wallet has been cancelled; if not, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
[0193] It should be noted that the specific implementation details of the transaction device based on red envelopes described in this invention have been described in detail in the transaction method based on red envelopes described above, so the details will not be repeated here.
[0194] Figure 7 An exemplary system architecture 700 is shown that can be applied to the red envelope-based transaction method or red envelope-based transaction device according to embodiments of the present invention.
[0195] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.
[0196] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).
[0197] Terminal devices 701, 702, and 703 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.
[0198] Server 705 can be a server providing various services, such as a backend management server supporting shopping websites browsed by users using terminal devices 701, 702, and 703 (this is just an example). The backend management server can analyze and process received data such as transaction requests and red envelope query requests, and then feed the processing results back to the terminal devices.
[0199] It should be noted that the transaction method based on red envelopes provided in this embodiment of the invention is generally executed by server 705, and correspondingly, the transaction device based on red envelopes is generally set in server 705.
[0200] It should be understood that Figure 7 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.
[0201] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a computer system 800 suitable for implementing a terminal device of the present invention. Figure 8 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.
[0202] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.
[0203] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.
[0204] 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 carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this invention.
[0205] 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.
[0206] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer programs 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 the 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.
[0207] 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 can be described as including a receiving module, a querying module, and a processing module, wherein the names of these modules do not necessarily limit the module itself.
[0208] 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, which, when executed by the device, implement the following method: receiving a transaction request sent by a sales terminal, the transaction request carrying a transaction amount, a payee's wallet number, and a payer's wallet number; querying and obtaining a red packet account associated with the payer's hard wallet based on the payer's wallet number, wherein the red packet account is used to receive red packets, the red packets being digital currency with attached usage rules; and, in response to the transaction request matching the red packet's usage rules, paying the wallet corresponding to the transaction amount to the wallet corresponding to the payee's wallet number based on the wallet corresponding to the payer's wallet number and the red packet account.
[0209] In another aspect, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.
[0210] According to the technical solution of this invention, by querying and obtaining the red packet account associated with the payer's hard wallet based on the payer's wallet number, and responding to the transaction request and matching the red packet usage rules, the technical means of paying the wallet corresponding to the transaction amount with digital currency based on the wallet and red packet account corresponding to the payer's wallet number to the wallet corresponding to the recipient's wallet number, this invention overcomes the technical problem that the existing red packet processing logic in the prior art can no longer meet market demands. This invention enables digital currency hard wallets to use red packets, allowing digital wallet operators to query red packet usage in real time during hard wallet payments, realizing the use of red packets in hard wallets, and essentially achieving the same level of marketing capabilities as soft wallets, thus aligning the user experience of hard wallets with that of soft wallets.
[0211] 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 red packet based transaction method, characterized in that, The red envelope is a digital currency with accompanying usage rules, and the method includes: Receive a transaction request sent by the sales terminal, the transaction request carrying the transaction amount, the recipient's wallet number and the payer's wallet number; The red packet account associated with the payer's hard wallet is retrieved based on the payer's wallet number, wherein the red packet account is used to receive red packets; In response to the transaction request matching the usage rules of the red envelope, digital currency corresponding to the transaction amount is paid to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red envelope account.
2. The method of claim 1, wherein, Before receiving a transaction request from a sales terminal, the method further includes: Determine whether the red envelope was sent to the red envelope account linked to the payer's hardware wallet via mobile phone number; If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet; If not, the red packet will be sent from the funder's red packet account to the red packet account associated with the payer's hard wallet via the hard wallet number.
3. The method of claim 2, wherein, Sending the red packet from the funder's red packet account to the red packet account associated with the payer's hard wallet includes: Determine whether the payer has activated a soft wallet; If so, the red envelope will be sent from the funder's red envelope account to the red envelope account associated with the payer's hard wallet; If not, the payer is guided to open a soft wallet in the digital currency application and bind the soft wallet to the payer's hard wallet, and the red packet is sent from the funder's red packet account to the red packet account associated with the payer's hard wallet.
4. The method of claim 1, wherein, In response to the transaction request matching the usage rules of the red envelope, digital currency corresponding to the transaction amount is paid to the wallet corresponding to the recipient's wallet number based on the wallet corresponding to the payer's wallet number and the red envelope account, including: Determine whether the red envelope account contains red envelopes whose usage rules match the transaction request; If so, the red packet will be transferred from the red packet account to the wallet corresponding to the recipient's wallet number, and / or the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the recipient's wallet number, in order to pay the digital currency corresponding to the transaction amount; If not, the wallet balance will be transferred from the payer's hardware wallet or the software wallet bound to the hardware wallet to the wallet corresponding to the payee's wallet number, in order to pay the digital currency corresponding to the transaction amount.
5. The method of claim 1, wherein, The transaction request is triggered either by the payer's hardware wallet or by the payer's software wallet.
6. The method of claim 1, wherein, Based on the payer's wallet ID, query and retrieve the red packet account associated with the payer's hard wallet, including: Determine whether the payer's wallet number is a hard wallet number; If so, then query and retrieve the red packet account associated with the payer's hard wallet based on the payer's hard wallet number; If not, then query and obtain the hardware wallet bound to the soft wallet based on the payer's soft wallet number, and then query and obtain the red envelope account associated with the hardware wallet based on the hardware wallet number.
7. The method of claim 4, wherein, The method further includes: Receive a refund request sent by the sales terminal, the refund request carrying the refund amount, the wallet number of the refunder and the wallet number of the payer; Determine whether the payment method for the transaction corresponding to the refund request is a combination of red envelope and wallet balance payment method; If so, the red packet will be returned from the refunder's wallet to the payer's red packet account, and / or, the wallet balance will be returned from the refunder's wallet to the payer's hardware wallet or a software wallet bound to the hardware wallet; If not, the red envelope will be returned to the payer's red envelope account.
8. The method of claim 7, wherein, Returning the red packet from the refunder's wallet to the payer's red packet account includes: Determine whether the red envelope refunded from the refunder's wallet to the payer's red envelope account has expired; If not, the red envelope will be returned to the payer's red envelope account; If so, the red envelope will be returned to the funder's red envelope account, or the red envelope will be returned to the payer's red envelope account and the validity period of the red envelope will be extended.
9. The method of claim 8, wherein, Returning the red envelope to the payer's red envelope account includes: Determine whether the red envelope is a special red envelope for hard wallets; If yes, determine whether the payer's hard wallet has been cancelled; if no, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account. If not, determine whether the payer's soft wallet has been cancelled; if not, return the red envelope to the payer's red envelope account; if yes, return the red envelope to the funder's red envelope account.
10. A red packet based transaction device, characterized in that, The red envelope is a digital currency with accompanying usage rules, and the device includes: The receiving module is used to receive transaction requests sent by the sales terminal, wherein the transaction request carries the transaction amount, the wallet number of the payee and the wallet number of the payer; The query module is used to query and obtain the red packet account associated with the payer's hard wallet based on the payer's wallet number, wherein the red packet account is used to receive red packets; The processing module is used to respond to the transaction request and match the usage rules of the red envelope, and pay the digital currency corresponding to the transaction amount to the wallet corresponding to the wallet number of the payer and the red envelope account.
11. An electronic device, comprising: include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-9.
12. A computer readable medium having stored thereon a computer program, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.
13. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-9.