Transaction content certification method and system for digital currency payment

Abstract

The invention discloses a digital currency payment-oriented transaction content proving method and system, relates to the technical field of block chain payment, and can solve the problems of payment experience splitting, insufficient address security, compliance processing lagging, complex operation and error proneness in digital currency payment. The scheme comprises: a terminal generates a transaction trigger code; the user side analyzes the transaction trigger code and then obtains the order description of the transaction; after receiving a payment address and a payment currency input by a user, the user side sends a collection address acquisition request to the acquisition server side, the request comprises payment information, and the payment information comprises an order identifier, the payment address, the payment currency, a block chain network type and a constraint condition; the acquiring server dynamically generates a collection address according to the payment information; and after the user side receives the collection address, triggering the risk assessment of the transaction, and after determining that the risk assessment is passed, carrying out the authorization verification of the transaction, and broadcasting the transaction information to the target block chain network.

Description

Technical Field

[0001] This application relates to the field of blockchain payment technology, and in particular to a method and system for proving transaction content for digital currency payments. Background Technology

[0002] With the increasing prevalence of digital currency payments in commercial scenarios, blockchain-based payment methods are gradually being applied to various terminals. Digital currency payment refers to a payment method that uses digital currency based on blockchain technology to transfer value in order to complete the settlement of goods, services, or debts.

[0003] Current digital currency payments typically involve interaction between consumers and merchants via smart terminals (such as POS machines), involving steps such as fiat currency amount input, digital currency type selection, obtaining and confirming the receiving address, transaction broadcasting, and subsequent on-chain and compliance processing. However, current digital currency payments still suffer from issues such as fragmented payment experience, insufficient address security, lagging compliance processing, and complex and error-prone operations. Summary of the Invention

[0004] This application provides a method and system for proving transaction content for digital currency payments, which can solve the problems of fragmented payment experience, insufficient address security, delayed compliance processing, and complex and error-prone operation in digital currency payments.

[0005] To address the above problems, this application provides the following technical solution: In a first aspect, this application provides a method for proving transaction content for digital currency payments, the method comprising: The terminal generates a transaction trigger code; After parsing the transaction trigger code, the user client obtains the order description for this transaction, which includes: merchant information, fiat currency amount, and fiat currency type; After receiving the payment address and payment currency entered by the user based on the order description, the user terminal sends a payment address retrieval request to the acquiring server. The payment address retrieval request includes payment information, which includes order identifier, payment address, payment currency, blockchain network type, and constraints. The acquiring server dynamically generates a receiving address based on the payment information and sends the receiving address to the user terminal; After receiving the payment address, the user terminal triggers a risk assessment for the transaction. Once the risk assessment is passed, the user terminal performs authorization verification for the transaction and broadcasts the transaction information to the target blockchain network.

[0006] As one possible implementation, the transaction trigger code includes a QR code or an NFC tag, and the terminal generates the transaction trigger code by including: The terminal receives the amount and type of fiat currency input by the cashier; The terminal sends the fiat currency amount, the fiat currency type, and the merchant information associated with the terminal to the acquiring server. The acquiring server generates a corresponding order identifier based on the fiat currency amount, the fiat currency type, the merchant information, and the terminal address; The acquiring server sends the order identifier and the access address of the acquiring server to the terminal; The terminal encodes the order identifier and the entry address to form the transaction trigger code.

[0007] As one possible implementation, after parsing the transaction trigger code, the user terminal obtains the order description of this transaction, including: After the user terminal uses a digital currency wallet application or a web service in the application to parse the transaction trigger code, it obtains the order identifier and the entry address; The user terminal sends an order information retrieval request to the entry address based on the application, which is used to request the order description corresponding to the order identifier; The acquiring server returns the order description to the user.

[0008] As one possible implementation, after the user receives the payment address, the method further includes: The user's digital currency wallet application interface displays a summary of the transaction information and automatically triggers a risk assessment of the transaction after receiving confirmation information from the user. The application interface prohibits copying the payment address.

[0009] As one possible implementation, the automatic triggering of the risk assessment for this transaction includes: After receiving the confirmation information input by the user, the client automatically calls the local risk assessment engine to perform a real-time risk assessment on the payment information. Alternatively, after receiving the confirmation information input by the user, the user terminal automatically sends a transaction risk assessment request to the acquiring server. Upon receiving the transaction risk assessment request, the acquiring server calls the risk assessment engine to perform a real-time risk assessment of the payment information.

[0010] As one possible implementation, the invocation of the risk assessment engine to perform real-time risk assessment on the payment information includes: The KYT engine is invoked to assess the payer's asset and behavioral risks based on the payment address, and the KYT assessment results are obtained. If the KYT assessment result indicates that the assessment is passed, and the amount of fiat currency is greater than the preset regulatory threshold, then the KYT engine is invoked to verify the real-name information of the payer and obtain the risk assessment result.

[0011] As one possible implementation, after confirming that the risk assessment has passed, the process of authorizing and verifying the transaction, and broadcasting the transaction information to the target blockchain network, includes: After the risk assessment is confirmed to be successful, the user initiates password payment authorization verification or biometric payment authorization verification, uses the private key corresponding to the payment address to sign the transaction data, generates a transaction signature, and broadcasts the transaction signature to the target blockchain network.

[0012] As one possible implementation, after broadcasting the transaction signature to the target blockchain network, the method further includes: The acquiring server encapsulates the transaction data into a structured data body, signs the structured data body using a private key, and then generates a transaction fact package. The transaction data package can be stored on a blockchain, or stored in a private ledger network jointly maintained by multiple trusted institutions, or pushed to a data receiving system designated by a regulatory agency.

[0013] As one possible implementation, the constraints include: the validity period of the receiving address, a whitelist of payment addresses bound to the receiving address, a fiat currency amount threshold, and the number of times the receiving address can be used.

[0014] In a second aspect, this application provides a transaction content verification system for digital currency payments, the system comprising: a terminal, a user terminal, and an acquiring server. The terminal is used to generate transaction trigger codes; The user terminal is used to parse the transaction trigger code and obtain the order description of this transaction. The order description includes: merchant information, fiat currency amount, and fiat currency type. The user terminal is also used to receive the payment address and payment currency entered by the user based on the order description, and then send a payment address acquisition request to the acquiring server. The payment address acquisition request includes payment information, which includes order identifier, payment address, payment currency, blockchain network type and constraints. The acquiring server is used to dynamically generate a receiving address based on the payment information and send the receiving address to the user terminal; The user terminal is used to trigger a risk assessment for the transaction after receiving the payment address, and after confirming that the risk assessment is passed, to perform authorization verification for the transaction and broadcast the transaction information to the target blockchain network.

[0015] In a third aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the transaction content proof method for digital currency payment described in the first aspect of this application.

[0016] The beneficial effects of the technical solutions provided in this application include at least the following: This application provides a method for proving transaction content for digital currency payments. In this method, the terminal first generates a transaction trigger code. The user terminal parses this trigger code to obtain a description of the transaction order, including merchant information, fiat currency amount, and fiat currency type. The user terminal receives the payment address and payment currency entered by the user based on the order description and sends a request to the acquiring server to obtain the receiving address. This request includes payment information such as order identifier, payment address, payment currency, blockchain network type, and constraints. The acquiring server dynamically generates a receiving address based on the payment information and returns it to the user terminal. After receiving the receiving address, the user terminal triggers a risk assessment of the transaction. If the risk assessment is successful, the user terminal performs transaction authorization verification and broadcasts the transaction information to the target blockchain network.

[0017] The method provided in this application allows cashiers to complete digital currency payments without needing to understand complex concepts such as blockchain, cryptocurrency, or network nodes. This significantly reduces training costs and the barrier to entry, eliminating the risk of misoperation due to conceptual confusion or incorrect procedures from the outset, making digital currency payments as simple and easy to use as traditional electronic payments.

[0018] Furthermore, users do not need to manually copy, paste, or verify lengthy and error-prone blockchain addresses throughout the payment process. All transaction information (amount, payee, remarks, etc.) is automatically filled in within the user's application by parsing the trigger code, requiring only one confirmation authorization from the user. This fundamentally eliminates the risk of malicious address tampering (such as clipboard hijacking) or users entering the wrong address, significantly improving the security and reliability of payment operations.

[0019] Secondly, this application conducts a risk assessment of the transaction before broadcasting it to the blockchain. Once a high-risk address is identified (such as one involved in illegal services), the transaction will be immediately blocked. This avoids the awkward dilemma of "funds being on the blockchain but frozen by the law" common in traditional cryptocurrency payments, achieving proactive risk control and protecting the funds of merchants and consumers.

[0020] Furthermore, the acquiring server dynamically generates a unique, time-limited, and payment-limited address for each transaction, with a configurable upper limit on the amount. This address is used "once and for all," and becomes invalid after completion. This mechanism exponentially increases the difficulty of remote payment (i.e., perpetrators remotely controlling other people's devices to make payments) and fund laundering through merchant channels, because attackers cannot obtain a fixed and usable payment address in advance, thus significantly strengthening the risk control capabilities of the merchant side. Attached Figure Description

[0021] Figure 1 A flowchart illustrating a transaction content proof method for digital currency payments, provided as an embodiment of this application; Figure 2 This is a structural diagram of a transaction content verification system for digital currency payments provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0023] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more.

[0024] In addition, the use of “based on” or “according to” implies openness and inclusivity, because processes, steps, calculations or other actions “based on” or “according to” one or more conditions or values ​​can in practice be based on additional conditions or values ​​beyond those conditions.

[0025] With the increasing prevalence of digital currency payments in commercial scenarios, blockchain-based payment methods are gradually being applied to various terminals. Digital currency payment refers to a payment method that uses digital currency based on blockchain technology to transfer value in order to complete the settlement of goods, services, or debts.

[0026] Existing digital currency QR code payment solutions suffer from the following pain points: Fragmented payment experience: Users must first confirm the order on the merchant's page or in a browser, then manually redirect to the wallet application to copy the address or scan the QR code again to complete the payment. The entire process is fragmented across different applications, resulting in disjointed operation and frequent interruptions.

[0027] Payment addresses are easily tampered with or abused: When users manually copy and paste long blockchain addresses, they are vulnerable to malware that hijacks the address via the clipboard, causing funds to be mistakenly transferred to attackers' accounts. Fixed merchant payment addresses can be forwarded at will, not only facilitating "remote payments" (e.g., perpetrators inducing people to pay directly to that address) but also providing a channel for illegal activities.

[0028] Lagging compliance and risk control: Traditional transaction risk monitoring is usually carried out only after the payment is recorded on the blockchain. Once it is identified that the funds originated from a high-risk address, merchants are often caught in a dilemma: either risk accepting problematic funds or try to return the irrevocable on-chain payment—either choice will damage the payment experience and fund security.

[0029] Merchant-side operations are complex and high-risk: cashiers need to manually select the blockchain network, cryptocurrency type, and manage the receiving address on the terminal. Any incorrect selection at any step (such as mistakenly selecting an incompatible network) may lead to payment failure or permanent loss of user funds. Training costs are high, and the operational risks are extremely high.

[0030] Based on the above problems, this application provides a method for proving transaction content for digital currency payments, such as... Figure 1 As shown, the method includes the following steps: Step 101: The terminal generates a transaction trigger code.

[0031] The transaction trigger code includes a QR code or an NFC tag, and the terminal includes devices such as a POS terminal, a computer web page, and a cash register. This application does not make any specific limitations on this.

[0032] Optionally, the transaction trigger code is generated by the terminal after receiving the fiat currency amount and fiat currency type entered by the cashier.

[0033] Step 102: After parsing the transaction trigger code, the user terminal obtains the order description of this transaction, which includes: merchant information, fiat currency amount, and fiat currency type.

[0034] The merchant information clearly informs the user who the recipient of the payment is. This is usually a verified legal name or brand name of the merchant, rather than a confusing blockchain address, and it forms the basis for establishing trust.

[0035] The fiat currency amount specifies the listed price of the goods / services purchased, such as "100.00". This amount is denominated in a familiar fiat currency (such as RMB or USD), avoiding the hassle of calculating cryptocurrency exchange rates in real time. The fiat currency unit specifies the currency of the above amount, such as "CNY" (RMB) or "USD" (US Dollar). Together with the "fiat currency amount", this constitutes a clear understanding of the price.

[0036] Step 103: After receiving the payment address and payment currency entered by the user based on the order description, the user terminal sends a payment address retrieval request to the acquiring server. The payment address retrieval request includes payment information, including order identifier, payment address, payment currency, blockchain network type, and constraints.

[0037] The acquiring server is a back-end processing system operated by a professional payment service provider (which may be a licensed payment institution, fintech company, or exchange). It is responsible for receiving, verifying, and processing payment requests from user wallets and completing the final clearing and settlement on behalf of the merchant.

[0038] Understandably, users select the cryptocurrency asset to pay based on the order description. Once selected, this means the blockchain network type, payment address, and payment currency have been chosen. For example, an Ethereum address might hold different crypto assets such as ETH, USDC, and USDT, which the user needs to select. .

[0039] The constraints include: the validity period of the receiving address, the whitelist of payment addresses bound to the receiving address, the fiat currency amount threshold, and the number of times the receiving address can be used.

[0040] The validity period of a payment address is a dynamically generated time window (e.g., 5 minutes, 15 minutes) set for that address. When generating the address, the acquiring server binds it to an "expiration timestamp." After this time, any transfers to this address will be considered invalid by the system, and the merchant will not confirm the payment. The validity period of the payment address is to prevent malicious users from intercepting the address and initiating payments long afterward (e.g., days or even weeks), which could be used to exploit price fluctuations for arbitrage or other fraudulent purposes.

[0041] A payment address whitelist, which is linked to a receiving address, is a security strategy mechanism used to restrict the sources of funds that can initiate valid payment transactions to that address. When generating dynamic receiving addresses, the acquiring server can selectively bind them to a pre-verified or authorized set of payment addresses, forming a "whitelist." Only payment transactions initiated from addresses listed in this whitelist will be accepted and confirmed as valid by the system; any transfer initiated from an address not included in the whitelist will be automatically rejected by the system, even if the amount, time, and other conditions are met. This allows for identity control of payment sources and compliance risk management by limiting receiving permissions to known and trusted addresses.

[0042] The fiat currency threshold is the maximum payment amount set for this transaction, denominated in fiat currency (such as CNY, USD). The acquiring server will convert this fiat currency threshold into the corresponding maximum cryptocurrency amount based on the real-time exchange rate and lock this rule. If the value of the converted cryptocurrency exceeds this threshold when a user makes a payment, the transaction will be blocked. This is a crucial safety measure to prevent large sums of money from being transferred accidentally due to user errors (such as misplacing a decimal point) or wallet malfunctions. For example, if the order is for 100 yuan, the threshold can be set to 110 yuan; any attempt to pay more than 110 yuan worth of cryptocurrency will fail. Combined with the "one-time validity" constraint, the amount of funds transferred through this address can be strictly limited, making it impossible to use merchant channels for large-scale illegal fund collection or laundering.

[0043] The validity count of a receiving address specifies the number of times that address can successfully receive payments. In this scheme, this value is typically set to "1". The acquiring server tracks blockchain transactions sent to this address. Once a payment is confirmed and successfully credited (meeting the blockchain confirmation requirement), the address is immediately "circuited," and any funds sent to that address thereafter will not be recognized by the system or settled to the merchant. This is the ultimate means of combating remote payment on behalf and address substitution attacks. Attackers cannot trick victims into paying to a "used" address because each address is immediately invalidated after its mission is completed.

[0044] The four constraints—"validity period," "fiat currency amount threshold," "whitelist of payment addresses linked to the receiving address," and "valid number of uses (one-time use)"—represent the core technological leap of digital currency payments from "free on-chain transfers" to "controlled commercial payments." They transform merchants' static receiving addresses into "smart contract-style" payment instructions dynamically generated by the acquiring system with precise strategies. This is not merely risk control; it builds a programmable, auditable, and highly secure framework for the application of digital currencies in compliant commercial scenarios.

[0045] Step 104: The acquiring server dynamically generates a receiving address based on the payment information and sends the receiving address to the user terminal.

[0046] After receiving a request from the user, the acquiring server (the backend of the payment system) does not select from a fixed address pool. Instead, it dynamically generates a payment address specifically for this unique transaction based on its unique payment information and returns it to the user so that the user can make payment to this address.

[0047] Specifically, the generated receiving address is deeply bound to the order identifier, payment address, and payment currency of each transaction, and the generation logic of the receiving address directly embeds constraint rules. This means that from scanning the code to making the payment, the receiving address seen and used by the user is always authoritatively generated and directly returned by the acquiring server. Attackers have no opportunity to replace the merchant's real address with their own address in the intermediate stages. This is a fundamental defense against attacks such as "clipboard hijacking."

[0048] Step 105: After receiving the payment address, the user terminal triggers a risk assessment for this transaction. After confirming that the risk assessment is passed, it performs authorization verification for this transaction and broadcasts the transaction information to the target blockchain network.

[0049] Optionally, after the user receives the receiving address, the method further includes: the user's digital currency wallet application interface displays a summary of the transaction information, and automatically triggers a risk assessment of the transaction after receiving confirmation information input by the user; wherein, the application interface prohibits copying the receiving address.

[0050] After receiving the payment address, the user's digital currency wallet application interface displays a summary of the transaction information. The user then clicks the confirmation button on the user's end to confirm the transaction details. This automatically triggers a risk assessment for the transaction. Once the risk assessment is passed, either password payment authorization verification or biometric payment authorization verification is initiated to complete the transaction. Finally, the transaction information is broadcast to the target blockchain network.

[0051] Optionally, the process of generating the transaction trigger code at the terminal in step 101 above may include the following: The terminal receives the amount and type of fiat currency input by the cashier; The terminal sends the fiat currency amount, the fiat currency type, and the merchant information associated with the terminal to the acquiring server. The acquiring server generates a corresponding order identifier based on the fiat currency amount, the fiat currency type, the merchant information, and the terminal address; The acquiring server sends the order identifier and the access address of the acquiring server to the terminal; The terminal encodes the order identifier and the entry address to form the transaction trigger code.

[0052] The above process transforms the "total price of goods: 100 yuan" entered by the cashier at the terminal into a QR code or NFC tag that contains all payment elements and can be recognized by a mobile wallet.

[0053] In the aforementioned QR code or NFC tag generation process, the POS machine only needs to generate a simple QR code. It doesn't require connection to the blockchain or knowledge of cryptocurrency exchange rates; all complex conversions and on-chain operations are handled by the backend acquiring server and the user's wallet. This achieves "zero-chain operation" for POS, making it extremely reliable. This process seamlessly transforms the familiar cashier action into the digital starting point for cryptocurrency payments. Through strong authentication and centralized management by the acquiring server, it ensures the authority and security of the front-end QR code (transaction trigger code), laying a solid foundation for a smooth and secure payment experience.

[0054] Optionally, after the user parses the transaction trigger code in step 102 above, the order description for this transaction obtained includes: After the user terminal uses a digital currency wallet application or a web service in the application to parse the transaction trigger code, it obtains the order identifier and the entry address; the user terminal sends an order information retrieval request to the entry address based on the application, which is used to request the order description corresponding to the order identifier; the acquiring server returns the order description to the user terminal.

[0055] Specifically, the process by which the user client sends an order information retrieval request to the entry address based on the application can be as follows: after parsing the entry address, the user client enters the corresponding payment page, and then sends an order information retrieval request to the acquiring server through the order identifier.

[0056] Understandably, the above process describes how the user (digital currency wallet app) securely and reliably obtains order details through interaction with the acquiring server. This is an "indirect acquisition" or "query-response" process, rather than directly reading all information from the QR code. Its core design focuses on security, dynamism, and controllability.

[0057] After a user scans the QR code, the wallet app (or its embedded web service) first parses the code. The parsed result isn't the final merchant and amount, but rather two key pieces of data: an order identifier and a lookup address. Think of it as obtaining an "order number" and a "query server URL." The wallet app automatically sends a request to this "lookup address" (i.e., the acquiring server), presenting the "order identifier" to request the complete details of the order. This step is dynamic and network-connected, ensuring real-time information. After verifying the order identifier, the acquiring server returns a complete, structured order description (including merchant information, fiat currency amount, fiat currency type, etc.) to the user. Only then can the user's wallet app interface securely and accurately display the information "Pay XX yuan to XX merchant."

[0058] The payment information ultimately seen by the user comes directly from the authoritative response of the acquiring server, not from the potentially tampered QR code itself. This fundamentally prevents man-in-the-middle attacks by forging QR codes for illegal activities. The QR code only needs to encode a short identifier and URL, instead of lengthy order information. This makes the QR code simpler, easier to scan, and more compatible. The above design transforms the transaction trigger code from an "information storage carrier" into a "secure access instruction." Through a single interaction with the acquiring server, it obtains the most authoritative and up-to-date transaction instructions for the user, which is the cornerstone of the entire secure and controllable solution, perfectly connecting the offline scanning action with the online trusted payment process.

[0059] It should be noted that the interaction process between the user terminal and the terminal, as well as the interaction process between the user terminal and the acquiring service, in this application can be implemented based on the digital currency wallet app in the user terminal or the web service in the digital currency wallet app.

[0060] Optionally, after the user receives the receiving address, the method further includes: the user's digital currency wallet application interface displays a summary of the transaction information, and automatically triggers a risk assessment of the transaction after receiving confirmation information input by the user; wherein, the application interface prohibits copying the receiving address.

[0061] In practice, after receiving the payment address, the wallet app first displays a clear transaction summary (e.g., "Pay 100 CNY to 'XX Supermarket'"). After the user confirms, the wallet app automatically triggers a background risk assessment. This allows users to understand the payment overview immediately and establish expectations. If subsequent risk control measures intercept the payment, the user will better understand the reason, resulting in a smoother experience. Furthermore, the payment confirmation screen completely prohibits users from copying the long payment address string. This is to absolutely defend against clipboard hijacking attacks. Malware often monitors and secretly replaces the cryptocurrency address copied by the user. Prohibiting copying physically cuts off the path to malicious address replacement, ensuring that the user's payment address is 100% the original address sent by the acquiring server.

[0062] Optionally, the automatic triggering of the risk assessment for this transaction includes: after receiving the confirmation information input by the user, the user terminal automatically calls the local risk assessment engine to perform a real-time risk assessment of the payment information; or, after receiving the confirmation information input by the user, the user terminal automatically sends a transaction risk assessment request to the acquiring server, and the acquiring server, upon receiving the transaction risk assessment request, calls the risk assessment engine to perform a real-time risk assessment of the payment information.

[0063] In other words, risk assessment can be performed either on the user's end or on the acquiring server. Providing these two optional paths reflects the flexibility of the system design, adapting to different security strategies and privacy requirements: for the highest level of privacy and immediate response, local assessment can be chosen; for the strongest risk identification and global collaborative defense, cloud assessment can be selected. In practical applications, the two can also be used in combination, for example, performing a quick local basic check first, followed by a deep cloud analysis to form a defense-in-depth approach. The core objective is to utilize all available resources for a final security scan before the user's final authorization, ensuring absolute security.

[0064] Optionally, the step of invoking the risk assessment engine to perform a real-time risk assessment of the payment information includes: The KYT (Know Your Transaction) engine is invoked to assess the risk of the payer's assets and behavior based on the payment address, and a KYT assessment result is obtained. If the KYT assessment result indicates that the assessment is passed and the fiat currency amount is greater than the preset regulatory threshold, the KYT engine is invoked to verify the payer's real-name information and a risk assessment result is obtained.

[0065] In practice, before the transaction is broadcast to the blockchain, a real-time risk assessment and scoring is performed on the payer's address, the token used, and the transaction context. If the assessment passes, the process continues; if a high risk is identified (such as an address associated with illegal activities), the transaction is immediately suspended. This fundamentally avoids the passive situation of "funds being frozen only after being recorded on the blockchain" in the traditional model, achieving proactive risk interception.

[0066] Building upon pre-transaction KYT (Know Your Customer) verification, an intelligent identity verification trigger rule is introduced: the KYC process is only triggered in the user's wallet when the fiat currency transaction amount reaches or exceeds a preset threshold. At this point, the user only needs to disclose necessary and minimal information to the acquiring service provider. To protect privacy, verification can also be completed using advanced technologies such as verifiable credentials or zero-knowledge proofs, maximizing the protection of ordinary users' privacy and payment convenience while meeting regulatory requirements such as anti-money laundering. In short, this mechanism achieves refined management of "convenient and anonymous low-risk, small-amount transactions, and controlled and compliant high-risk, large-amount transactions."

[0067] Furthermore, identity verification follows the "minimum necessary" principle. Users can provide plaintext information voluntarily through decentralized methods; a better approach is to use verifiable credentials or zero-knowledge proof technology, only outputting an assertion of "pass" or "fail" to the acquiring party. This maximizes user privacy while meeting compliance requirements. Zero-knowledge proofs, in particular, can prove that a user meets certain conditions (such as being an adult) without revealing any specific identity information, achieving a balance between privacy and compliance.

[0068] Furthermore, if a transaction fails during the risk assessment phase or an anomaly occurs in the communication session, all temporary data and context related to that transaction will be immediately and automatically destroyed. This adheres to the "fail-safe" principle. Residual state is quickly cleaned up to prevent sensitive information from remaining, while also preventing abnormal sessions from being exploited for probing attacks, ensuring the cleanliness and security of the system state.

[0069] Optionally, the step of verifying the transaction authorization after confirming the risk assessment has passed, and broadcasting the transaction information to the target blockchain network, includes: after confirming the risk assessment has passed, the user initiates password payment authorization verification or biometric payment authorization verification, uses the private key corresponding to the payment address to sign the transaction data, generates a transaction signature, and broadcasts the transaction signature to the target blockchain network. Thus, a payment intention that begins with an offline QR code scan and undergoes multiple layers of verification is securely and accurately converted into a public and permanent blockchain record.

[0070] Optionally, after broadcasting the transaction signature to the target blockchain network, the method further includes: The acquiring server encapsulates the transaction data into a structured data body, signs the structured data body using a private key, and then generates a transaction fact package. The transaction data package can be stored on a blockchain, or stored in a private ledger network jointly maintained by multiple trusted institutions, or pushed to a data receiving system designated by a regulatory agency.

[0071] The above process ensures that each payment not only completes an on-chain transfer but also generates a structured, independently verifiable "digital profile" certified by an authoritative institution. This provides a solid, reliable, and efficient standardized evidentiary foundation for transaction auditing, dispute resolution, judicial evidence collection, and regulatory compliance, greatly enhancing the credibility and legal operability of the entire payment system.

[0072] It should be noted that the transaction content proof method for digital currency payments provided in this application can be easily adapted to any of the aforementioned communication protocols. When implementing this method, the most suitable combination of one or more communication protocols can be selected based on the specific scenario.

[0073] Furthermore, all communication between the user terminal and the acquiring server uses a session key based on elliptic curve Diffie-Hellman key exchange, combined with authentication encryption algorithms for encryption. The protocol includes a counter or time window mechanism to defend against replay attacks.

[0074] The transaction content proof method for digital currency payments provided in this application deeply integrates blockchain technology with QR code payment processes on terminals such as POS terminals. This allows front-line cashiers to complete digital currency payments without needing to understand complex concepts such as blockchain, cryptocurrency, or network nodes. This significantly reduces training costs and lowers the barrier to entry, eliminating the risk of misoperation due to conceptual confusion or incorrect procedures from the outset, making digital currency payments as simple and easy to use as traditional electronic payments.

[0075] Users do not need to manually copy, paste, or verify lengthy and error-prone blockchain addresses throughout the payment process. All transaction information (amount, recipient, remarks, etc.) is automatically filled in within the wallet application by parsing the trigger code, and users only need to confirm and authorize once. This fundamentally eliminates the risk of addresses being maliciously tampered with (such as clipboard hijacking) or users entering the wrong address, significantly improving the security and reliability of payment operations.

[0076] Before a transaction is broadcast to the blockchain, relevant addresses and transaction patterns are scanned in real time through a risk intelligence network. Once a high-risk address is identified (such as one involved in illegal services), the transaction will be blocked immediately. This avoids the awkward dilemma of "funds being on the blockchain but frozen by the law" in traditional cryptocurrency payments, achieving proactive risk control and protecting the funds of merchants and consumers.

[0077] This application does not mandate full identity verification for all transactions. Instead, it intelligently triggers KYC processes of varying intensity based on factors such as transaction amount, frequency, and counterparty risk level. Anonymity is maintained for small, infrequent transactions; users are only required to provide more detailed identity information when a transaction triggers a preset risk threshold. This refined design satisfies regulatory requirements such as anti-money laundering while maximizing the protection of the privacy of the vast majority of low-risk users, thus enhancing the payment experience.

[0078] The acquiring party dynamically generates a unique, time-limited receiving address with a set upper limit for each transaction. This address is used "once and for all" and becomes invalid after completion. This mechanism exponentially increases the difficulty of remote payment (i.e., illegal actors remotely controlling other people's devices to make payments) and fund laundering through merchant channels, because attackers cannot obtain a fixed and usable receiving address in advance, thus significantly strengthening the risk control capabilities of the merchant side.

[0079] Throughout the entire transaction process (from triggering and authorization to broadcasting), immutable structured logs and cryptographic proofs are automatically generated, forming a complete "transaction process evidence chain." In the event of a transaction dispute (such as a dispute over the amount or a statement of non-payment), merchants, payment platforms, or judicial institutions can use this structured evidence for efficient auditing and liability determination, providing clear and credible technical evidence for resolving disputes and enhancing the credibility and legal operability of the entire payment system.

[0080] In summary, this application systematically addresses the three core challenges of usability, security, and compliance faced by digital currencies in retail payment scenarios through a series of innovative designs. It not only encapsulates complex blockchain technology into a simple checkout operation, but also constructs a mature payment solution that balances user experience, fund security, and legal oversight through proactive risk control, intelligent compliance, and evidence solidification, providing crucial support for the widespread application of digital currencies.

[0081] This application also provides a transaction content proof system for digital currency payments, such as... Figure 2 As shown, the system includes: a terminal 10, a user terminal 20, and an acquiring server 30; The terminal 10 is used to generate a transaction trigger code; The user terminal 20 is used to parse the transaction trigger code and obtain the order description of this transaction. The order description includes: merchant information, fiat currency amount and fiat currency type. The user terminal 20 is also used to receive the payment address and payment currency entered by the user based on the order description, and then send a payment address acquisition request to the acquiring server 30. The payment address acquisition request includes payment information, which includes order identifier, payment address, payment currency, blockchain network type and constraints. The acquiring server 30 is used to dynamically generate a receiving address based on the payment information and send the receiving address to the user terminal 20; The user terminal 20 is used to trigger a risk assessment for this transaction after receiving the payment address, and after confirming that the risk assessment is passed, to perform authorization verification for this transaction and broadcast the transaction information to the target blockchain network.

[0082] In one embodiment, the transaction trigger code includes a QR code or an NFC tag; The terminal 10 is used to receive the amount and type of legal tender entered by the cashier. The terminal 10 is used to send the fiat currency amount, the fiat currency type, and the merchant information associated with the terminal 10 to the acquiring server 30. The acquiring server 30 is used to generate a corresponding order identifier based on the fiat currency amount, the fiat currency type, the merchant information, and the terminal 10 address; The acquiring server 30 is used to send the order identifier and the access address of the acquiring server 30 to the terminal 10; The terminal 10 is used to form the transaction trigger code by encoding the order identifier and the entry address.

[0083] In one embodiment, the user terminal 20 is used to parse the transaction trigger code using a digital currency wallet application or a web service in the application to obtain the order identifier and the entry address; The user terminal 20 is used to send an order information retrieval request to the entry address based on the application, and is used to request the order description corresponding to the order identifier; The acquiring server 30 is used to return the order description to the user terminal 20.

[0084] In one embodiment, the user terminal 20 is configured to display a summary of the transaction information using a digital currency wallet application interface, and automatically trigger a risk assessment of the transaction after receiving confirmation information input by the user; wherein, the application interface prohibits the copying of the receiving address.

[0085] In one embodiment, the user terminal 20 is configured to automatically invoke a local risk assessment engine to perform a real-time risk assessment of the payment information after receiving confirmation information input by the user. Alternatively, the user terminal 20 may automatically send a transaction risk assessment request to the acquiring server 30 after receiving confirmation information input by the user. Upon receiving the transaction risk assessment request, the acquiring server 30 may invoke a risk assessment engine to perform a real-time risk assessment on the payment information.

[0086] In one embodiment, the acquiring server 30 calls the KYT engine to assess the asset and behavioral risks of the payer based on the payment address, and obtains the KYT assessment result; if the KYT assessment result indicates that the assessment is passed, and the fiat currency amount is greater than the preset regulatory threshold, then the KYT engine is called to verify the real-name information of the payer, and obtains the risk assessment result.

[0087] In one embodiment, after the risk assessment is confirmed to be successful, the user terminal 20 initiates password payment authorization verification or biometric recognition payment authorization verification, uses the private key corresponding to the payment address to sign the transaction data, generates a transaction signature, and broadcasts the transaction signature to the target blockchain network.

[0088] In one embodiment, the acquiring server 30 is used to encapsulate the transaction data into a structured data body, sign the structured data body using a private key, and generate a transaction fact package; store the transaction fact package on the blockchain, or store it in a private ledger network jointly maintained by multiple trusted institutions, or push it to a data receiving system designated by a regulatory agency.

[0089] In one embodiment, the constraints include: the validity period of the receiving address, a whitelist of payment addresses bound to the receiving address, a fiat currency amount threshold, and the number of times the receiving address is valid.

[0090] The transaction content proof system for digital currency payments provided in this application can execute the above-described transaction content proof method for digital currency payments. Its implementation principle and technical effects are similar, and will not be repeated here. Specific limitations regarding the transaction content proof system for digital currency payments can be found in the limitations of the transaction content proof method for digital currency payments described above, and will not be repeated here.

[0091] In another embodiment of this application, a computer-readable storage medium is also provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the transaction content proof method for digital currency payment as described in the embodiments of this application are implemented.

[0092] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs).

[0093] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0094] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for proving transaction content for digital currency payments, characterized in that, The method includes: The terminal generates a transaction trigger code; After parsing the transaction trigger code, the user client obtains the order description for this transaction, which includes: merchant information, fiat currency amount, and fiat currency type; After receiving the payment address and payment currency entered by the user based on the order description, the user terminal sends a payment address retrieval request to the acquiring server. The payment address retrieval request includes payment information, which includes order identifier, payment address, payment currency, blockchain network type, and constraints. The acquiring server dynamically generates a receiving address based on the payment information and sends the receiving address to the user terminal; After receiving the payment address, the user terminal triggers a risk assessment for the transaction. Once the risk assessment is passed, the user terminal performs authorization verification for the transaction and broadcasts the transaction information to the target blockchain network.

2. The method according to claim 1, characterized in that, The transaction trigger code includes a QR code or an NFC tag. The terminal generates the transaction trigger code, including: The terminal receives the amount and type of fiat currency input by the cashier; The terminal sends the fiat currency amount, the fiat currency type, and the merchant information associated with the terminal to the acquiring server. The acquiring server generates a corresponding order identifier based on the fiat currency amount, the fiat currency type, the merchant information, and the terminal address; The acquiring server sends the order identifier and the access address of the acquiring server to the terminal; The terminal encodes the order identifier and the entry address to form the transaction trigger code.

3. The method according to claim 2, characterized in that, After parsing the transaction trigger code, the user terminal obtains the order description of this transaction, including: After the user terminal uses a digital currency wallet application or a web service in the application to parse the transaction trigger code, it obtains the order identifier and the entry address; The user terminal sends an order information retrieval request to the entry address based on the application, which is used to request the order description corresponding to the order identifier; The acquiring server returns the order description to the user.

4. The method according to claim 1, characterized in that, After the user receives the payment address, the method further includes: The user's digital currency wallet application interface displays a summary of the transaction information and automatically triggers a risk assessment of the transaction after receiving confirmation information from the user. The application interface prohibits copying the payment address.

5. The method according to claim 4, characterized in that, The risk assessment automatically triggered for this transaction includes: After receiving the confirmation information input by the user, the client automatically calls the local risk assessment engine to perform a real-time risk assessment on the payment information. Alternatively, after receiving the confirmation information input by the user, the user terminal automatically sends a transaction risk assessment request to the acquiring server. Upon receiving the transaction risk assessment request, the acquiring server calls the risk assessment engine to perform a real-time risk assessment of the payment information.

6. The method according to claim 5, characterized in that, The process of calling the risk assessment engine to perform real-time risk assessment on the payment information includes: The KYT engine is invoked to assess the payer's asset and behavioral risks based on the payment address, and the KYT assessment results are obtained. If the KYT assessment result indicates that the assessment is passed, and the amount of fiat currency is greater than the preset regulatory threshold, then the KYT engine is invoked to verify the real-name information of the payer and obtain the risk assessment result.

7. The method according to claim 1, characterized in that, After confirming that the risk assessment has passed, the process of authorizing and verifying the transaction, and broadcasting the transaction information to the target blockchain network, includes: After the risk assessment is confirmed to be successful, the user initiates password payment authorization verification or biometric payment authorization verification, uses the private key corresponding to the payment address to sign the transaction data, generates a transaction signature, and broadcasts the transaction signature to the target blockchain network.

8. The method according to claim 7, characterized in that, After broadcasting the transaction signature to the target blockchain network, the method further includes: The acquiring server encapsulates the transaction data into a structured data body, signs the structured data body using a private key, and then generates a transaction fact package. The transaction data package can be stored on a blockchain, or stored in a private ledger network jointly maintained by multiple trusted institutions, or pushed to a data receiving system designated by a regulatory agency.

9. The method according to claim 1, characterized in that, The constraints include: the validity period of the receiving address, the whitelist of payment addresses bound to the receiving address, the fiat currency amount threshold, and the number of times the receiving address is valid.

10. A transaction content verification system for digital currency payments, characterized in that, The system includes: a terminal, a user terminal, and an acquiring server; The terminal is used to generate transaction trigger codes; The user terminal is used to parse the transaction trigger code and obtain the order description of this transaction. The order description includes: merchant information, fiat currency amount, and fiat currency type. The user terminal is also used to receive the payment address and payment currency entered by the user based on the order description, and then send a payment address acquisition request to the acquiring server. The payment address acquisition request includes payment information, which includes order identifier, payment address, payment currency, blockchain network type and constraints. The acquiring server is used to dynamically generate a receiving address based on the payment information and send the receiving address to the user terminal; The user terminal is used to trigger a risk assessment for the transaction after receiving the payment address, and after confirming that the risk assessment is passed, to perform authorization verification for the transaction and broadcast the transaction information to the target blockchain network.

Images