A payment method and electronic device

Abstract

This invention discloses a payment collection method and an electronic device. The method includes: upon receiving a user order and a payment code from a business system, adding the user order and payment code to a mapping relationship in a smart contract on the network; saving the added mapping relationship on the blockchain; assigning a payment address to the user order according to the smart contract; packaging the payment address and payment code into payment information and sending it to the business system; upon detecting an incoming payment event at the payment address, confirming the order status of the user order corresponding to the payment code based on the payment code carried in the incoming payment event and the mapping relationship saved on the blockchain; if the user order's order status is pending payment, verifying the incoming payment event based on the payment information; updating the order status in the mapping relationship saved on the blockchain after verification, and notifying the business system of successful payment collection. This invention has the advantages and features of improving address reuse rate, solving address reuse delay, ensuring transaction security, and improving reconciliation efficiency.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more particularly to a payment collection method and electronic device. Background Technology

[0002] Blockchain is a decentralized, immutable, distributed ledger technology.

[0003] In business scenarios where blockchain technology is used to complete payment collection, the platform needs to first generate multiple blockchain addresses (i.e., payment addresses) in advance using encryption algorithms. In response to a user's order, the platform creates a payment order corresponding to the order, selects an idle blockchain address from the multiple blockchain addresses, assigns it to the payment order, and synchronizes the blockchain address corresponding to the payment order and the amount to be paid by the user to the user. After detecting that the user's payment is completed (i.e., payment is successful), the blockchain address is released to serve subsequent payment collection business.

[0004] Using the aforementioned blockchain address pool technology in payment collection operations presents a problem of delays in blockchain address reuse. Summary of the Invention

[0005] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a payment collection method and an electronic device for executing the payment collection method, which has the advantages and characteristics of improving address reuse rate, resolving address reuse delays, ensuring transaction security, and improving reconciliation efficiency.

[0006] To achieve the above objectives, as a first aspect of the present invention, a payment collection method is provided for a network node, wherein the payment collection method includes:

[0007] Upon receiving a user order and payment code from the business system, the user order and payment code are added to the mapping relationship of the network's smart contract; wherein, the user order includes the order status;

[0008] Save the updated mapping relationship on the blockchain;

[0009] The smart contract assigns a payment address to the user's order.

[0010] Package the payment address and payment code into a payment information package and send it to the business system;

[0011] If an incoming payment event is detected at the receiving address, the order status of the user order corresponding to the receiving code is confirmed based on the receiving code carried by the incoming payment event and the mapping relationship stored on the blockchain.

[0012] If the order status of the user's order is pending payment, verify the payment event based on the payment information;

[0013] If the verification passes, update the order status of the mapping relationship stored on the chain and notify the business system that the payment has been successfully received.

[0014] Optionally, the smart contract includes the number of orders received at the receiving address and the confirmation status of the received orders;

[0015] The step of allocating a payment address for the user order according to the smart contract includes:

[0016] Count the number of orders received at each payment address;

[0017] If the number of orders received at a payment address is less than the preset order quantity, the payment address will be used as a candidate address to obtain multiple candidate addresses;

[0018] Count the number of unconfirmed orders received for each candidate address;

[0019] Weights are assigned to the number of orders received and the number of orders in the unconfirmed state for each candidate address to obtain a score for each candidate address;

[0020] The payment address is assigned to the user's order based on the score of each candidate address.

[0021] Optionally, assigning a payment address to the user order based on the scores of each candidate address includes:

[0022] Sort the scores of each candidate address and get the lowest score;

[0023] If the lowest score is less than the score threshold, the candidate address corresponding to the lowest score will be assigned to the user's order.

[0024] If the minimum score is greater than or equal to the score threshold, additional payment addresses are added to expand the payment address pool.

[0025] Optionally, when an inflow event is detected at the receiving address, confirming the order status of the user order corresponding to the receiving code based on the receiving code carried in the inflow event and the mapping relationship stored on the blockchain includes:

[0026] The payment event is parsed to obtain the payment code;

[0027] Query the mapping relationship stored on the query chain to find the order status corresponding to the parsed payment code.

[0028] Optionally, the acquiring information also includes the amount to be paid; the billing event also carries the amount to be paid, the receiving address, and the transaction hash; the transaction hash is the hash value of the receiving address, the receiving code, and the amount to be paid in the acquiring information;

[0029] When the order status of the user's order is pending payment, verifying the payment event based on the payment information includes:

[0030] Parse the incoming payment event to obtain the corresponding payment code, receiving address, amount to be paid, and transaction hash;

[0031] The parsed payment code, payment address and amount to be paid corresponding to the payment event are hashed to obtain the verification hash.

[0032] If the verification hash and the transaction hash are consistent, the receipt event verification is successful.

[0033] Optionally, verifying the billing event based on the acquiring information further includes:

[0034] Verify the payment receipt event and the payment code format of the acquiring information;

[0035] Verify the amount due for payment in the recorded transaction event and the acquiring information;

[0036] If the payment code format of the incoming payment event and the payment information are consistent and the difference between the amounts to be paid is less than a preset amount difference, verify the consistency between the verification hash and the transaction hash.

[0037] Optionally, the step of updating the order status of the mapping relationship stored on the chain and notifying the business system of successful payment upon successful verification includes:

[0038] If the verification passes, the order status corresponding to the payment code in the on-chain mapping relationship is updated to "confirmed" and the business system is notified that the payment has been successfully received.

[0039] As a second aspect of the present invention, a payment collection method is provided for a business system, wherein the payment collection method includes:

[0040] Use a hash algorithm to generate a payment code for the user's order;

[0041] Send the user's order and the generated payment code to the network node;

[0042] After receiving the payment information sent by the network node, the payment information is parsed to obtain the payment address, payment code and amount to be paid;

[0043] The parsed payment address, payment code, and amount to be paid are hashed to obtain the transaction hash.

[0044] Send the payment event to the receiving address; wherein the payment event carries the payment code, receiving address, amount to be paid and transaction hash.

[0045] Optionally, the user order includes an order identifier, order time, user identifier, and amount to be paid;

[0046] Generating a payment code for the user's order using a hash algorithm includes:

[0047] The order identifier, order time, user identifier, and amount to be paid are concatenated to form order data;

[0048] Perform a salted hash operation on the order data to obtain a salted hash value;

[0049] Encode a specified byte of the salted hash value to obtain the initial payment code;

[0050] Add a verification bit to the initial payment code to generate a new payment code.

[0051] As a third aspect of the present invention, an electronic device is provided, comprising:

[0052] One or more processors;

[0053] A memory having stored one or more computer programs thereon, which, when executed by one or more processors, cause the one or more processors to implement the payment collection method provided according to the first and second aspects of the invention.

[0054] When a network node receives a user order and payment code from the business system, including the user order status, it adds a one-to-one correspondence between the two (user order and payment code) to the mapping relationship deployed in the smart contract on the network, thus completing the on-chain storage. Since the smart contract can also obtain the load status and on-chain status of each payment address in the network, it can assign a payment address (optimal payment address) to the received user order based on these statuses. After address allocation processing, the same payment address can correspond to multiple user orders. Because the payment code and user order are one-to-one, and the user order and payment address are also one-to-one, it is also possible to further refine the smart contract's mapping. The contract additionally obtains the mapping relationship between the payment code and the payment address; considering the security of information transmission between network nodes and business systems, the payment code and payment address, which have low information sensitivity, are packaged into payment information and sent to the business system, and the payment progress is judged by listening to the payment event of the payment address; when the payment event is detected, the order status corresponding to the payment code is first judged by the mapping relationship between the payment code carried by the payment event and the payment code and user order stored on the chain. If the order status indicates that payment is pending, the payment legality is verified based on the payment information. If the verification is successful, the order status in the on-chain mapping relationship is updated and the business system is notified synchronously. In this payment method, the address allocation process differs from the traditional method that can only use idle addresses. By analyzing the load status and on-chain status of each payment address, the optimal payment address is allocated to each order (without requiring the address to be completely idle). This enables dynamic reuse of a single payment address for multiple user orders, significantly improving the efficiency of concurrent use of payment addresses while solving the latency problem of traditional address reuse. Furthermore, due to the immutable nature of the blockchain, the mapping relationship between orders and payment codes stored on the chain has extremely high accuracy and security. Combined with the generation method of the payment codes, which also possess the characteristics of immutability, carrying little information (low information sensitivity), and high security, the payment codes are used to complete the interaction process between network nodes and business systems. Even if the payment code is exposed during this interaction, it will not lead to the destruction or tampering of the on-chain relationship, ensuring transaction security while improving the accuracy of verification of incoming events and reconciliation efficiency.

[0055] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0056] The present invention will be further described below with reference to the accompanying drawings:

[0057] Figure 1 A flowchart of a payment collection method for network nodes provided by the present invention;

[0058] Figure 2 This is a flowchart illustrating one embodiment of step S130 of the payment collection method for network nodes provided by the present invention.

[0059] Figure 3 This is a flowchart illustrating one embodiment of step S135 of the payment collection method for network nodes provided by the present invention.

[0060] Figure 4 This is a flowchart illustrating one embodiment of step S150 of the payment collection method for network nodes provided by the present invention.

[0061] Figure 5 This is a flowchart illustrating one embodiment of step S160 of the payment collection method for network nodes provided by the present invention.

[0062] Figure 6 This is a flowchart illustrating another implementation of step S160 of the payment collection method for network nodes provided by the present invention.

[0063] Figure 7 This is a flowchart illustrating one embodiment of step S170 of the payment collection method for network nodes provided by the present invention.

[0064] Figure 8 A flowchart of a payment collection method for a business system provided by the present invention;

[0065] Figure 9 This is a flowchart illustrating one embodiment of step S210 in the payment collection method for a business system provided by the present invention.

[0066] Figure 10 A flowchart for generating a payment QR code is provided for this invention;

[0067] Figure 11 A flowchart for intelligent allocation of payment addresses using smart contracts provided by the present invention;

[0068] Figure 12 A timing diagram of the payment collection method provided by this invention in terms of users, business systems, and network nodes;

[0069] Figure 13 This invention provides different methods for transmitting payment codes on different networks.

[0070] Figure 14 This is a system architecture diagram of the payment collection method of the present invention;

[0071] Figure 15 This is a diagram showing the status changes of an order in the payment collection method of the present invention;

[0072] Figure 16 A module diagram of an electronic device provided by the present invention.

[0073] Explanation of reference numerals in the attached figures

[0074] Among them, 101 is the processor; 102 is the memory; 103 is the I / O interface; and 104 is the bus. Detailed Implementation

[0075] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0076] The terms "an embodiment," "example," or "trademark" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this invention. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0077] In traditional payment methods, when a user creates an order, the system first searches the network for an idle payment address (idle means the address is not currently receiving or processing any orders, nor is it waiting for network block confirmation). After the user completes the transfer to this idle address, it needs to wait for network block confirmation before the address is released for subsequent orders. However, the transaction confirmation time for each block on the blockchain is relatively long. During this waiting period, although the payment address has received the transaction, it is still considered occupied in the network and cannot be immediately reused. With a large order volume, payment addresses may be quickly occupied, and the long block confirmation time can lead to a lack of free addresses to allocate to orders, resulting in address reuse delays or even address shortages, thus affecting order processing efficiency.

[0078] In view of this, in order to solve the aforementioned address reuse delay problem, as a first aspect of the present invention, a payment collection method is provided for network nodes, such as... Figure 1 As shown, the payment collection method includes:

[0079] In step S110, upon receiving a user order and payment code sent by the business system, the user order and payment code are added to the mapping relationship of the network's smart contract; wherein, the user order includes the order status;

[0080] In step S120, the added mapping relationship is saved on the blockchain;

[0081] In step S130, a payment address is assigned to the user order according to the smart contract;

[0082] In step S140, the payment address and payment code are packaged into payment information and sent to the business system;

[0083] In step S150, if an inflow event is detected at the receiving address, the order status of the user order corresponding to the receiving code is confirmed based on the receiving code carried by the inflow event and the mapping relationship stored on the blockchain.

[0084] In step S160, if the order status of the user order is pending payment, the payment event is verified according to the payment information;

[0085] In step S170, if the verification passes, the order status of the mapping relationship stored on the chain is updated, and the business system is notified that the payment has been successfully received.

[0086] It is necessary to describe in detail the smart contract of this method. Before executing the payment collection method of this application, the smart contract is computer-readable code pre-deployed in the blockchain network, and each node in the network can utilize / call the smart contract. The smart contract includes the mapping relationship between user orders and payment codes, the mapping relationship between payment codes and payment addresses (the mapping relationship between payment addresses and payment code lists), the information structure of user orders (for example, the information structure of user orders includes order identifier, amount due, order creation time, order expiration time, order status, and transaction hash), and various functional functions (such as functions for generating payment codes based on user orders, functions for processing payment events, functions for querying order status, and functions for clearing expired orders).

[0087] The payment collection method of this invention is as follows: After receiving a user order and a payment code (including the user order status) sent by the business system, the network node adds a correspondence between the two (one-to-one correspondence between user orders and payment codes) to the mapping relationship deployed in the smart contract on the network, completing the on-chain storage; since the load status and on-chain status of each payment address in the network can also be obtained according to the smart contract, a payment address (optimal payment address) can be assigned to the received user order according to the above status. After address allocation processing, the same payment address can correspond to multiple user orders; since the payment code and user order are one-to-one correspondences, and user orders and payment addresses are also one-to-one correspondences, it is also possible to... The smart contract additionally obtains the mapping relationship between the payment code and the payment address. Considering the security of information transmission between network nodes and business systems, the payment code and payment address, which have lower information sensitivity, are packaged into payment information and sent to the business system. The payment progress is judged by listening for the payment event of the payment address. When a payment event is detected, the order status corresponding to the payment code is first determined by the mapping relationship between the payment code carried by the payment event and the payment code and user order stored on the chain. If the order status indicates that payment is pending, the payment legality is verified based on the payment information. If the verification is successful, the order status in the on-chain mapping relationship is updated and the business system is notified synchronously. In this payment method, the address allocation process differs from the traditional method that can only use idle addresses. By analyzing the load status and on-chain status of each payment address, the optimal payment address is allocated to the order (the address does not need to be completely idle). This realizes the dynamic reuse of a single payment address for multiple user orders, which greatly improves the efficiency of concurrent use of payment addresses and solves the problem of latency in traditional address reuse.

[0088] To illustrate the specific implementation of the present invention for solving the address reuse delay problem, the present invention utilizes smart contracts to obtain the load status and on-chain status of each receiving address in the network. As an optional implementation of step S130, such as... Figure 2 As shown, the smart contract includes the number of orders received at the receiving address and the confirmation status of the received orders; the process of assigning a receiving address to the user order according to the smart contract includes:

[0089] In step S131, the number of orders received at each payment address is counted;

[0090] In step S132, if the number of orders received at a payment address is less than the preset order quantity, the payment address is used as a candidate address to obtain multiple candidate addresses;

[0091] In step S133, the number of unconfirmed orders received for each candidate address is counted;

[0092] In step S134, weights are assigned to the number of orders received and the number of unconfirmed orders for each candidate address to obtain a score for each candidate address;

[0093] In step S135, a payment address is assigned to the user order based on the scores of each candidate address.

[0094] For each receiving address, upon receiving an order, a receiving address is assigned according to the smart contract, and the corresponding payment code and address are saved in the payment code-address mapping relationship. Therefore, upon receiving a user order, the number of payment codes corresponding to each receiving address in the network and the number of orders received (one-to-one correspondence between orders and payment codes) can be determined based on the payment code-address mapping relationship. The number of orders received by each receiving address is the address's load state (i.e., address load). Each received order needs to be confirmed by multiple blocks on the blockchain before the transaction is considered complete. Therefore, the number of blocks in the blockchain where received orders for each receiving address are in an unconfirmed state is the address's on-chain state. Combining load state and on-chain state analysis, receiving addresses with lower load state and lower on-chain state should be assigned as the optimal receiving address for user orders. In steps S131-S135 above, multiple candidate addresses with lower loads are selected based on address load. The on-chain state of each candidate address is then calculated. A score for each candidate address is obtained by assigning weights and summing them. Taking into account both the address load and on-chain state of each candidate address, the optimal receiving address is determined for the user's order. One formula for calculating the score of a candidate address is as follows: Formula (1):

[0095] Sorce[addr]=w1×load[addr]+w2×pendind_tx[addr] (1)

[0096] In the above formula (1), addr represents the candidate address, load[addr] is the address load of the candidate address, pending_tx[addr] is the on-chain state of the candidate address, w1 and w1 correspond to the load weight and on-chain weight respectively, and Sorce[addr] is the score of the candidate address.

[0097] After calculating the score of each candidate address according to formula (1), as an optional implementation of step S135, such as Figure 3 As shown, the process of assigning a payment address to the user's order based on the scores of each candidate address includes:

[0098] In step S135a, the scores of each candidate address are sorted to obtain the lowest score;

[0099] In step S135b, if the lowest score is less than the score threshold, the candidate address corresponding to the lowest score is assigned to the user order;

[0100] In step S135c, if the minimum score is greater than or equal to the score threshold, additional payment addresses are added to expand the payment address pool.

[0101] The above allocation method aims to assign the receiving address with the lowest address load and the lowest on-chain status to user orders. However, in practical applications, high-concurrency orders may lead to address pool exhaustion and lengthy expansion processes, resulting in the receiving address with the lowest score still not meeting the preset requirements. To address this issue, the payment method provided by this invention automatically adds receiving addresses, expands the address pool, and then re-determines the optimal receiving address for user orders according to the above method.

[0102] Because this address reuse method doesn't wait for all on-chain blocks to confirm an order before releasing and reusing it, but instead directly selects the address with the lowest combined score of address load and the number of unconfirmed states on the chain for reuse, it solves the address reuse latency problem and significantly improves the address reuse rate. Simultaneously, based on the improved address reuse rate, the address pool only needs to generate a small number of receiving addresses during the initialization phase, reducing storage resource occupancy and address operation costs. In addition to the above, storing the receiving address and payment code as another mapping relationship also has the advantage that when an incoming payment event is detected, the payment code can be directly determined based on the monitored receiving address and this mapping relationship. Then, the corresponding order can be found through the mapping relationship between the payment code and the order, thereby obtaining the order status. For high-concurrency order scenarios, this method can greatly shorten the retrieval path and reduce the retrieval process and time.

[0103] After assigning a payment address to a user order, the payment address and payment code can be packaged into payment information and sent to the business system. Simultaneously, the assigned payment address is monitored to determine if an inflow event has been received. As an optional implementation of step S150, such as... Figure 4 As shown, the step of confirming the order status of the user order corresponding to the payment code based on the payment code carried in the payment event and the mapping relationship stored on the blockchain when an inflow event is detected includes:

[0104] In step S151, the payment event is parsed to obtain the payment code;

[0105] In step S152, the order status corresponding to the parsed payment code is queried from the mapping relationship stored on the chain.

[0106] To prevent the receipt of counterfeit or incorrect payment codes, the system first verifies whether the payment code carried in the incoming payment event of the monitored payment address matches the payment code stored on the blockchain, using the mapping relationship between payment codes and payment addresses in the smart contract. Then, based on the mapping relationship between payment codes and orders stored on the blockchain, the system determines the user order corresponding to the payment code. Finally, it calls the smart contract's order status query function to determine the order status of the user order. For an order, there are multiple statuses, including unpaid, paid, canceled, confirmed, and completed. To avoid duplicate processing of invalid orders (such as paid, canceled, confirmed, and completed), the entire incoming payment event is verified only when the order status is unpaid, based on the payment information. The payment information also includes the amount to be paid; the incoming payment event also carries the amount to be paid, the payment address, and the transaction hash; the transaction hash is the hash value of the payment address, payment code, and amount to be paid in the payment information; as an optional implementation of step S160, such as... Figure 5 As shown, when the order status of the user's order is pending payment, verifying the payment event based on the acquiring information includes:

[0107] In step S161, the payment event is parsed to obtain the payment code, payment address, amount to be paid, and transaction hash corresponding to the payment event;

[0108] In step S162, the parsed payment code, payment address and amount to be paid corresponding to the payment event are hashed to obtain the verification hash;

[0109] In step S163, if the verification hash and the transaction hash are consistent, the receipt event verification passes.

[0110] To further verify the accuracy of the incoming payment events received at the receiving address, the smart contract also includes a payment code format, a preset amount difference (i.e., the tolerable difference between the amount of the payment information and the amount of the incoming payment event), an order expiration time, and an order status; as another optional implementation of step S160, such as Figure 6 As shown, the step of verifying the receipt event based on the acquiring information further includes:

[0111] In step S161, the payment event is parsed to obtain the payment code, payment address, amount to be paid, and transaction hash corresponding to the payment event;

[0112] In step S162, the parsed payment code, payment address and amount to be paid corresponding to the payment event are hashed to obtain the verification hash;

[0113] In step S163, the payment code format of the receipt event and the acquiring information is verified;

[0114] In step S164, the amount to be paid for the receipt event and the acquiring information are verified;

[0115] In step S165, if the payment code format of the incoming payment event and the payment information are consistent and the difference between the amounts to be paid is less than a preset amount difference, the consistency between the verification hash and the transaction hash is verified.

[0116] In step S166, if the verification hash and the transaction hash are consistent, the receipt event verification passes.

[0117] Specifically, one verification process for incoming payment events can be as follows: Parse the payment code of the incoming payment event, and verify the parsed payment code based on its verification bit; after the payment code verification is successful, call the smart contract's order and payment code mapping relationship, and determine whether an order corresponding to the payment code can be found in the mapping relationship; if the mapping relationship finds an order corresponding to the payment code, perform a difference calculation between the amount to be paid carried in the incoming payment event and the amount to be paid packaged in the payment information; if the difference is less than a preset amount difference, the amount verification is successful; if the amount verification is successful, continue to verify the time window; if the time of the incoming payment event is less than the order's expiration time, the time window verification is successful; if the time window verification is successful, monitor whether the order corresponding to the payment code is a duplicate order; if the order status indicates that it is unpaid, receive the incoming payment time, and mark the order status as unpaid in the mapping relationship between the payment code and the order. In the above verification process, if any one of the following verification steps—payment code format verification, amount verification, time window verification, and duplicate payment detection—fails, it means that the incoming payment event received by that address fails verification. If all verification items pass, the accounting event verification is considered successful. This is one possible implementation of step S170, such as... Figure 7 As shown, the step of updating the order status of the mapping relationship stored on the chain and notifying the business system of successful payment upon successful verification includes:

[0118] In step S171, if the verification passes, the order status corresponding to the payment code in the mapping relationship stored on the chain is updated to the confirmed status, and the business system is notified that the payment has been successfully received.

[0119] After receiving a successful payment notification, the business system can further notify the user or store the order status separately in the order database / order system for easy access to the order status later.

[0120] As a second aspect of the present invention, a payment collection method is provided for use in a business system, such as... Figure 8 As shown, the payment collection method includes:

[0121] In step S210, a payment code is generated for the user's order using a hash algorithm;

[0122] In step S220, the user order and the generated payment code are sent to the network node;

[0123] In step S230, after receiving the acquiring information sent by the network node, the acquiring information is parsed to obtain the receiving address, the receiving code, and the amount to be paid;

[0124] In step S240, a hash operation is performed on the parsed receiving address, receiving code, and amount to be paid to obtain the transaction hash;

[0125] In step S250, the receipt event is sent to the receiving address; wherein the receipt event carries a payment code, receiving address, amount to be paid and transaction hash.

[0126] User orders typically contain a large amount of sensitive information, such as order identifier, order time, user identifier, and amount to be paid. Encrypting the user order to generate a payment code with lower security sensitivity ensures the security of the payment process. This is an optional implementation method for step S210, such as... Figure 9 As shown, the step of generating a payment code for the user's order using a hash algorithm includes:

[0127] In step S211, the order identifier, order time, user identifier, and amount to be paid are concatenated to form order data;

[0128] In step S212, a salted hash operation is performed on the order data to obtain a salted hash value;

[0129] In step S213, a specified byte of the salted hash value is encoded to obtain the initial payment code;

[0130] In step S214, a verification bit is added to the initial payment code to generate a payment code.

[0131] Figure 10This is a flowchart illustrating the generation process of a QR code for receiving payments, which includes several key steps such as data concatenation, hash calculation, encoding, and verification. The received user order information includes the order identifier (order_id), the user identifier (user_id) who initiated the order, the amount to be paid (amount), and the order time (time). The above data is concatenated to obtain order data (data), where data = order_id + user_id + amount + time. The secret is a preset system key. The result of summing the order data (data) and the secret key is subjected to SHA256 salted hash calculation to obtain the salted hash value (hash). The first 20 bytes (hd) of the salted hash value are extracted and Base25 encoded. Finally, a CRC check is performed on the encoded result to obtain the checksum. The checksum and the encoded result are concatenated to obtain the final QR code (VRC). Taking user order information order_id="ORD20240115001", user_id="USER123456", amount=99.99, time=1705305600 as an example, the generated payment code VRC="5Km8fG3pQr9Tx2Yw7Hv4". It is important to reiterate that the payment code generated by this invention differs from traditional barcodes or QR codes. Barcodes or QR codes typically carry original sensitive information such as order identifiers and amounts in plaintext; however, the payment code of this invention does not directly carry such sensitive information. The payment code corresponds one-to-one with the order and serves as an order identifier, facilitating the retrieval of order-related information based on the mapping relationship stored on the blockchain. Sensitive information is stored on the blockchain, and the mapping relationship protects the sensitive information on the blockchain. Furthermore, the information carried by traditional QR codes / barcodes is easily leaked, attacked, and tampered with. The payment code of this invention, as an order identifier, poses no risk of information leakage even if exposed. Moreover, even if the payment code is forcibly modified, the payment event, which requires this modified code to be sent to the receiving address, will fail the address verification process. Therefore, the payment code proposed in this invention, and the payment method based on it for network and business system interaction, not only improves information security but also ensures transaction security and compliance.

[0132] Specifically, the following is an embodiment of the payment collection method provided by this invention in a real-world payment collection scenario. First, the first step is system initialization. During initialization, the smart contract is deployed to the network, obtaining the contract address: 0x1234...ABCD; then, payment addresses are created, including creating a pool of 50 payment addresses, where each payment address is sequentially 0xAAAA...1111, 0xBBBB...2222, ...0xZZZZ...5050; finally, the preset maximum concurrent order volume for a single address is configured as 200, the preset amount difference as 0.01, and the order expiration time as 30 minutes. After the above system initialization is completed, the second step begins: the order creation process. A user places an order for an item with a total price of 99.99. The order identifier ORD20240115001, user identifier USER123456, amount to be paid 99.99, and order creation time 1705305600 are entered into the payment code generation function of the smart contract to obtain the payment code VRC, VRC="5Km8fG3pQr9Tx2Yw7Hv4". The smart contract intelligently assigns a physical address to the order, and the selected address is: 0xAAAA...1111. Next, the relationship between the user's order and the payment code is added to the smart contract's order-to-payment-code mapping, and the relationship between the payment code and the selected address is added to the smart contract's payment code-to-payment-address mapping. Finally, the user is shown payment information / acquiring information {payment address: 0xAAAA...1111, payment amount: 99.99, remarks: 5Km8fG3pQr9Tx2Yw7Hv4}; the remarks in this payment information / acquiring information are the payment code corresponding to the order. Third step: User payment. A user initiates a transfer via their wallet. The transaction receipt event for this transfer is {to:0xAAAA...1111, value:99.99, data:0x354b6d3866473370517239547832597737487634, txHash:0xTXHASH123}. In this receipt event, the data field corresponds to the hexadecimal encoding of the VRC payment code, and txHash is the transaction hash value obtained after hashing the received payment information. The fourth step involves on-chain listening and verification of the receipt event.Specifically, after detecting an incoming transaction event on the chain, the VRC is extracted from the date field (data: 0x354b6d3866473370517239547832597737487634) to obtain 5Km8fG3pQr9Tx2Yw7Hv4. A verification function is then called to verify the consistency between the received incoming transaction event and the transaction hash. This verification process involves first calculating the verification hash of the incoming transaction event {to:0xAAAA...1111, value:99.99, VRC:5Km8fG3pQr9Tx2Yw7Hv4}, and then comparing the verification hash with the transaction hash. If they match, the verification passes, and the order status is updated to {OrderInfo.status = PAID, OrderInfo.txHash =0xTXHASH123...}. Finally, the fifth step is executed: business information synchronization. This involves first calling the smart contract to trigger the event emitPaymentConfirmed().

[0133] The process involves updating the order status in the business database, triggering the subsequent shipping process, and sending a payment success notification to the user. Finally, it waits for block confirmation; each block records the transaction data and status. In this embodiment, a single address can concurrently process 200 orders, and a pool of 50 receiving addresses can handle a total of 10,000 orders, improving address utilization by 200 times compared to traditional solutions. The delay in the entire payment process originates solely from the blockchain block confirmation stage, which is an inherent characteristic of the blockchain network and not an additional delay caused by the design of this solution. Since there are no other procedural delays, from a business perspective, the payment delay of this solution can be considered almost zero.

[0134] Figure 11 The flowchart of this invention, which utilizes smart contracts to intelligently allocate receiving addresses, is provided. First, the address pool list is initialized, with the lowest score set to infinity and the optimal address left empty. The address pool is then traversed. If an address exists, its load and on-chain status are assessed, and a comprehensive score (Score[addr]) is calculated. If the comprehensive score is less than the lowest score, the current address's comprehensive score is set as the lowest score, and the current address is designated as the optimal address. This process continues until the address pool is traversed to find the address with the lowest comprehensive score. If the address pool has no more addresses and all addresses are overloaded, it automatically expands to generate new addresses. This process needs to be combined with the attached... Figure 11To reiterate the address reuse and allocation method of this invention, based on the characteristic that blockchain accounting requires confirmation of blocks from each node, there are situations where the actual completion of a transaction precedes the completion of on-chain accounting (block confirmation). Even if accounting is delayed, the transaction itself has already been completed, and the on-chain accounting will eventually be fully executed. Therefore, to achieve efficient reuse of receiving addresses, this invention does not wait for all blocks to be confirmed, but instead counts the number of blocks in an unconfirmed state and scores the addresses based on the load on orders. Since different blockchain networks have different numbers of blocks, and different networks have different numbers of confirmed blocks (i.e., different networks have different requirements for the number of block confirmations required for a transaction to be considered final and tamper-proof), address scheduling can be completed directly on network nodes or by calling smart contracts within the business system.

[0135] Figure 12 A timing diagram of the payment collection method of this invention is provided, involving the user, business system, and network nodes. Figure 12 It can be seen that the payment code generation method provided by this invention can facilitate the entire payment process by exchanging payment codes with low information sensitivity and high security and privacy between various entities. Since the payment event must carry the payment code to complete tasks such as order matching, address mapping, and payment event verification, different transmission methods can be used in different blockchain networks to embed the payment code into the payment event for transmission. For example, if smart contracts are supported, the payment code can be transmitted using the Input Data field (an additional data field supporting smart contracts); if Memo is supported, the payment code can be transmitted using the Memo field (an additional transaction comment field supporting Memo); in networks that do not support smart contracts and additional data fields for transmitting payment codes, amount fingerprint technology can be used to encode the VRC to a decimal place for transmission. Figure 13 The different methods of transmitting payment codes for different networks are given. Figure 13 In this context, VRC stands for QR code for receiving payments. For networks that support smart contracts, VRC can be carried in the Input Data field; for networks that support Memo, VRC can be carried in the Memo / Tag field; other ways to carry VRC include using amount fingerprint technology (that is, encoding VRC to a decimal place of the amount to achieve the purpose of carrying VRC).

[0136] In addition to the above explanation, Figure 14 and Figure 15 The system architecture diagram and order status change diagram of the payment collection method of the present invention are given respectively. From Figure 15As can be seen, a transaction consists of five states: Pending Payment, Paid, Confirmed, Cancelled, and Completed. The Pending Payment state indicates that the payment is awaiting user payment within the validity period of the payment code; the Paid state indicates that the payment transaction has been detected and is awaiting block confirmation; the Confirmed state indicates that the transaction has reached the required number of on-chain block confirmations and is ready for execution; and the Cancelled state indicates that the payment transaction has expired or the user has actively cancelled the order. A successful payment transaction should sequentially go through four states: Pending Payment, Paid, Confirmed, and Completed. An unsuccessful payment transaction goes through three states: Pending Payment, Cancelled, and Completed. It should be noted again that the order status can be detected and obtained through functions in the smart contract.

[0137] When a network node receives a user order and payment code from the business system, including the user order status, it adds a one-to-one correspondence between the two (user order and payment code) to the mapping relationship deployed in the smart contract on the network, thus completing the on-chain storage. Since the smart contract can also obtain the load status and on-chain status of each payment address in the network, it can assign a payment address (optimal payment address) to the received user order based on these statuses. After address allocation processing, the same payment address can correspond to multiple user orders. Because the payment code and user order are one-to-one, and the user order and payment address are also one-to-one, it is also possible to further refine the smart contract's mapping. The contract additionally obtains the mapping relationship between the payment code and the payment address; considering the security of information transmission between network nodes and business systems, the payment code and payment address, which have low information sensitivity, are packaged into payment information and sent to the business system, and the payment progress is judged by listening to the payment event of the payment address; when the payment event is detected, the order status corresponding to the payment code is first judged by the mapping relationship between the payment code carried by the payment event and the payment code and user order stored on the chain. If the order status indicates that payment is pending, the payment legality is verified based on the payment information. If the verification is successful, the order status in the on-chain mapping relationship is updated and the business system is notified synchronously. In this payment method, the address allocation process differs from the traditional method that can only use idle addresses. By analyzing the load status and on-chain status of each payment address, the optimal payment address is allocated to each order (without requiring the address to be completely idle). This enables dynamic reuse of a single payment address for multiple user orders, significantly improving the efficiency of concurrent use of payment addresses while solving the latency problem of traditional address reuse. Furthermore, due to the immutable nature of the blockchain, the mapping relationship between orders and payment codes stored on the chain has extremely high accuracy and security. Combined with the generation method of the payment codes, which also possess the characteristics of immutability, carrying little information (low information sensitivity), and high security, the payment codes are used to complete the interaction process between network nodes and business systems. Even if the payment code is exposed during this interaction, it will not lead to the destruction or tampering of the on-chain relationship, ensuring transaction security while improving the accuracy of verification of incoming events and reconciliation efficiency.

[0138] As a third aspect of the present invention, an electronic device is provided, such as... Figure 16 As shown, it includes:

[0139] One or more processors 101;

[0140] The memory 102 stores one or more computer programs that, when executed by the one or more processors 101, cause the one or more processors 101 to implement the payment collection method provided according to the first and second aspects of the present invention.

[0141] The tool may also include one or more I / O interfaces 103 connected between the processor 101 and the memory 102, configured to enable information interaction between the processor 101 and the memory 102.

[0142] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit 101 (CPU); the first memory 102 is a device with data storage capabilities, including but not limited to random access memory 102 (RAM, more specifically SDRAM, DDR, etc.), read-only memory 102 (ROM), electrically erasable programmable read-only memory 102 (EEPROM), and flash memory (FLASH); the I / O interface 103 (read-write interface) is connected between the processor 101 and the memory 102, enabling information interaction between the processor 101 and the memory 102, including but not limited to a data bus 104 (Bus).

[0143] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0144] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A payment collection method for network nodes, characterized in that, The payment collection methods include: Upon receiving a user order and payment code from the business system, the user order and payment code are added to the mapping relationship of the network's smart contract; wherein, the user order includes the order status; the smart contract includes the number of orders received by the payment address and the confirmation status of the received orders; Save the updated mapping relationship on the blockchain; Assigning a payment address to the user's order according to the smart contract includes: Count the number of orders received at each payment address; If the number of orders received at a payment address is less than the preset order quantity, the payment address will be used as a candidate address to obtain multiple candidate addresses; Count the number of unconfirmed orders received for each candidate address; Weights are assigned to the number of orders received and the number of orders in the unconfirmed state for each candidate address to obtain a score for each candidate address; The user's order is assigned a payment address based on the score of each candidate address; Package the payment address and payment code into a payment information package and send it to the business system; If an incoming payment event is detected at the receiving address, the order status of the user order corresponding to the receiving code is confirmed based on the receiving code carried by the incoming payment event and the mapping relationship stored on the blockchain. If the order status of the user's order is pending payment, verify the payment event based on the payment information; If the verification passes, update the order status of the mapping relationship stored on the chain and notify the business system that the payment has been successfully received.

2. The payment collection method according to claim 1, characterized in that, The process of assigning a payment address to the user order based on the scores of each candidate address includes: Sort the scores of each candidate address and get the lowest score; If the lowest score is less than the score threshold, the candidate address corresponding to the lowest score will be assigned to the user's order. If the minimum score is greater than or equal to the score threshold, additional payment addresses are added to expand the payment address pool.

3. The payment collection method according to claim 1, characterized in that, When a payment event is detected at the receiving address, the order status of the user order corresponding to the payment code is confirmed based on the payment code carried in the payment event and the mapping relationship stored on the blockchain, including: The payment event is parsed to obtain the payment code; Query the mapping relationship stored on the query chain to find the order status corresponding to the parsed payment code.

4. The payment collection method according to claim 1, characterized in that, The acquiring information also includes the amount to be paid; the billing event also carries the amount to be paid, the receiving address, and the transaction hash; the transaction hash is the hash value of the receiving address, the receiving code, and the amount to be paid in the acquiring information; When the order status of the user's order is pending payment, verifying the payment event based on the payment information includes: Parse the incoming payment event to obtain the corresponding payment code, receiving address, amount to be paid, and transaction hash; The parsed payment code, payment address and amount to be paid corresponding to the payment event are hashed to obtain the verification hash. If the verification hash and the transaction hash are consistent, the receipt event verification is successful.

5. The method according to claim 4, characterized in that, The step of verifying the payment event based on the acquiring information further includes: Verify the payment receipt event and the payment code format of the acquiring information; Verify the amount due for payment in the recorded transaction event and the acquiring information; If the payment code format of the incoming payment event and the payment information are consistent and the difference between the amounts to be paid is less than a preset amount difference, verify the consistency between the verification hash and the transaction hash.

6. The method according to claim 1, characterized in that, Upon successful verification, the order status of the mapping relationship stored on the chain is updated, and the business system is notified of successful payment, including: If the verification passes, the order status corresponding to the payment code in the on-chain mapping relationship is updated to "confirmed" and the business system is notified that the payment has been successfully received.

7. The payment collection method according to claim 1, used in a business system, characterized in that, The payment collection methods include: Use a hash algorithm to generate a payment code for the user's order; Send the user's order and the generated payment code to the network node; After receiving the payment information sent by the network node, the payment information is parsed to obtain the payment address, payment code and amount to be paid; The parsed payment address, payment code, and amount to be paid are hashed to obtain the transaction hash. Send the payment event to the receiving address; wherein the payment event carries the payment code, receiving address, amount to be paid and transaction hash.

8. The payment collection method according to claim 7, characterized in that, The user order includes an order identifier, order time, user identifier, and amount to be paid; The step of generating a payment code for the user's order using a hash algorithm includes: The order identifier, order time, user identifier, and amount to be paid are concatenated to form order data; Perform a salted hash operation on the order data to obtain a salted hash value; Encode a specified byte of the salted hash value to obtain the initial payment code; Add a verification bit to the initial payment code to generate a new payment code.

9. An electronic device, characterized in that, include: One or more processors; A memory having stored thereon one or more computer programs that, when executed by one or more processors, cause the one or more processors to implement the payment collection method according to any one of claims 1 to 8.

Images