Method and System for Wallet-Based On-Chain Payment Using Visual Codes

Abstract

A wallet-based on-chain payment method using a time code according to one technical aspect of the present invention comprises: a payment request providing device generating payment request information including recipient identification information for identifying a payment counterparty and information regarding payment, and encoding and displaying the payment request information using a time code; a user terminal recognizing the time code and obtaining the payment request information from the time code; the user terminal generating a payment transaction including the payment request information for an on-chain payment between a user wallet address managed by the user terminal and a recipient wallet address determined based on the recipient identification information included in the payment request information, based on the payment request information, and transmitting it to a blockchain network; a payment smart contract executed on the blockchain network receiving the payment transaction and performing a transfer of assets from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction; and the payment smart contract recording on-chain payment information corresponding to the payment transaction on the blockchain.

Description

Technology Field

[0001] The present invention relates to the field of electronic payment and digital asset remittance based on blockchain technology, and more specifically, to an on-chain payment method for performing on-chain payment through a wallet of a user terminal using a visual code and managing the payment history as an on-chain receipt including on-chain payment information and non-fungible tokens, and a wallet-based on-chain payment system for performing the same. Background Technology

[0002] As blockchain technology and digital assets become more widespread, there is a continuously increasing demand for payment, remittance, and settlement methods that involve transferring assets directly on the chain. In particular, there are active attempts to reduce dependence on centralized infrastructure, such as existing credit card companies, mobile payment providers, and payment gateways (PGs), by enabling users to generate payment transactions directly from their blockchain wallets and record them in a verifiable form on the chain.

[0003] Meanwhile, payment methods using visual codes are widely used in offline stores, kiosks, and web payment screens. For example, a typical method involves a merchant terminal displaying a visual code in the form of a QR code, which the user scans with a smartphone to launch a payment application.

[0004] However, most of these existing visual code-based payment systems operate through credit card companies or centralized simplified payment servers; consequently, actual payment approval, acquisition, and settlement details are often stored only in the service provider's server database and are not directly recorded on the blockchain. This results in limitations in terms of payment transparency, prevention of forgery and tampering, and long-term verifiability.

[0005] Furthermore, while some services offer on-chain payment features using blockchain wallets, there is a problem where the payment request generation method, on-chain payment transactions, and post-transaction receipt management are separated. For instance, payment amounts, merchant information, and order identifiers are typically managed on off-chain servers, leaving only simple asset transfer transactions on-chain. In this scenario, it is difficult to clearly verify retrospectively which order, store, or settlement corresponds to a specific on-chain transaction, and it creates the inconvenience of having to cross-reference off-chain logs with on-chain records when refunds or disputes arise.

[0006] Ultimately, conventional technologies have technical limitations in terms of preventing tampering and reuse of payment request information transmitted via visual codes, ensuring consistency between on-chain payment transactions and payment request information, managing payment status including post-payment refunds and dispute handling, and consistently representing this in the form of an on-chain receipt.

[0007] These limitations act as obstacles to the safe and reliable application of wallet-based on-chain payments in various real-world scenarios, such as offline store payments, online store payments, cross-border remittances, and automated payment of service fees. Prior art literature

[0008] Korean Patent Publication No. 10-2104826 (Registration Date: April 21, 2020) The problem to be solved

[0009] One technical aspect of the present invention is to solve the problems of the aforementioned prior art by providing a wallet-based on-chain payment method using a time code and an on-chain payment system for the same, which performs on-chain payment through a wallet of a user terminal based on payment request information included in a time code, while ensuring consistency between the payment request information and the on-chain payment transaction and preventing the payment request information from being falsified or reused.

[0010] In addition, one technical aspect of the present invention is to provide a wallet-based on-chain payment method using a time code and an on-chain payment system for the same, which can effectively block attacks on the reuse of the same time code, induce payment using a forged time code, and transfer assets to an unregistered recipient wallet address by configuring the time code generated by a payment request providing device to include recipient identification information, payment amount, order identifier, random number value, validity period information, etc., in the time code, and to have a user terminal perform electronic signature verification, random number and validity period verification on the payment request information restored from the time code, and at the same time, have a payment smart contract verify on-chain whether the random number is reused and the validity of the recipient wallet address based on the payment request information.

[0011] In addition, one technical aspect of the present invention is to provide a wallet-based on-chain payment method using a time code and an on-chain payment system for the same, wherein a unique payment identifier is assigned to each payment transaction on-chain, and a payment record including a user wallet address, a recipient wallet address, a payment amount, a time of payment, a payment status, etc. is stored as on-chain payment information, and a non-fungible token corresponding to each payment identifier is issued to function as an on-chain receipt for the payment, thereby ensuring that changes in payment status, such as payment completion, refund, cancellation, or dispute, are consistently reflected in the on-chain payment information and on-chain receipt, and that a reliable payment history can be presented during long-term accounting verification, settlement, and dispute resolution processes.

[0012] In addition, one technical aspect of the present invention is to provide a wallet-based on-chain payment method using a visual code and an on-chain payment system for the same, wherein the recipient wallet address and recipient business information are managed by an on-chain merchant registration smart contract, and the payment smart contract verifies whether the recipient wallet address is a pre-registered merchant wallet address by referring to the registry when processing a payment transaction, thereby ensuring that even if visual code-based on-chain payment is performed in various payment environments such as offline stores, kiosks, and web stores, the actually approved on-chain payment is limited to registered merchants.

[0013] The above-mentioned objectives and various advantages of the present invention will become more apparent to those skilled in the art from the preferred embodiments of the present invention. means of solving the problem

[0014] One technical aspect of the present invention proposes a wallet-based on-chain payment method using a time code. The method comprises the steps of: a payment request providing device generating payment request information including recipient identification information for identifying a payment counterparty and information regarding payment, and encoding and displaying the payment request information using a time code; a user terminal recognizing the time code and obtaining the payment request information from the time code; the user terminal generating a payment transaction including the payment request information for an on-chain payment between a user wallet address managed by the user terminal and a recipient wallet address determined based on the recipient identification information included in the payment request information, based on the payment request information, and transmitting it to a blockchain network; a payment smart contract executed on the blockchain network receiving the payment transaction and performing a transfer of assets from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction; and the payment smart contract recording on-chain payment information corresponding to the payment transaction on the blockchain.

[0015] Another technical aspect of the present invention proposes a wallet-based on-chain payment system using a time code. The system comprises: a payment request providing device configured to generate payment request information including recipient identification information for identifying a payment counterparty and information regarding payment, and to encode and display the payment request information using a time code; a user terminal configured to recognize the time code to obtain the payment request information from the time code, and to generate a payment transaction including the payment request information for an on-chain payment between a user wallet address managed by the user terminal and a recipient wallet address determined based on the recipient identification information included in the payment request information, based on the payment request information, and to transmit the transaction to a blockchain network; and a blockchain network comprising a payment smart contract executed on the blockchain network, having a blockchain address space in which the user wallet address and the recipient wallet address are defined as valid addresses. The payment smart contract is configured to receive the payment transaction, perform a transfer of assets from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction, and record on-chain payment information corresponding to the payment transaction on the blockchain.

[0016] The means for solving the above-mentioned problem do not enumerate all features of the present invention. Various means for solving the problem of the present invention may be understood in more detail by referring to specific embodiments in the following detailed description. Effects of the invention

[0017] According to one embodiment of the present invention, by providing payment request information generated by a payment request providing device as a visual code and enabling the direct creation of an on-chain payment transaction through a wallet of a user terminal, it is possible to implement a wallet-based on-chain payment in which asset transfer and payment records are consistently managed on a blockchain network without relying on an existing card company or payment gateway (PG) server-centric structure.

[0018] In addition, according to one embodiment of the present invention, the payment request information includes not only recipient identification information and payment amount but also a random number value and validity period information, and by having the user terminal and the payment smart contract perform electronic signature verification, verification of whether the random number is reused, and verification of the validity period, it is possible to effectively prevent security threats such as attacks on the reuse of the same time code, induction of payment using a forged time code, and transfer of assets to an unregistered wallet address.

[0019] In addition, according to one embodiment of the present invention, a merchant registration smart contract is placed on a blockchain network, and when a payment smart contract processes a payment transaction, it directly verifies on-chain whether the recipient wallet address is a pre-registered merchant wallet address, thereby providing a payment infrastructure based on on-chain verification of a reliable recipient in various payment environments such as offline stores, kiosks, and online stores.

[0020] In addition, according to one embodiment of the present invention, a unique payment identifier is assigned to each payment transaction, and a payment record including a user wallet address, recipient wallet address, payment amount, payment time, payment status, etc., is stored as on-chain payment information. At the same time, a corresponding non-fungible token is issued and utilized as an on-chain receipt. This ensures that changes in payment status, such as payment completion, refund, cancellation, and the occurrence and resolution of disputes, are consistently reflected in the on-chain payment information and on-chain receipt, thereby providing the effect of easily securing a reliable payment history during long-term accounting audits, settlements, tax reporting, and dispute resolution processes.

[0021] In addition, according to one embodiment of the present invention, since the generation of a visual code-based payment request, the generation of a wallet-based on-chain payment transaction, asset transfer and payment status management by a payment smart contract, and the issuance of an on-chain receipt are designed as a single integrated protocol, it is possible to reduce implementation complexity compared to the existing structure where visual code payment and blockchain payment were operated separately, and to provide a more consistent user experience and high reliability from the perspectives of service providers, merchants, and end users. Brief explanation of the drawing

[0022] Figure 1 schematically illustrates the overall configuration of a wallet-based on-chain payment system using a visual code according to one embodiment of the present invention. FIG. 2 is a flowchart illustrating the overall flow of a wallet-based on-chain payment method using a visual code according to an embodiment of the present invention. FIG. 3 schematically illustrates the internal configuration of a payment request providing device (200) used in a wallet-based on-chain payment system using a visual code according to one embodiment of the present invention. FIG. 4 is a block diagram illustrating a user terminal used in a wallet-based on-chain payment system using a visual code according to an embodiment of the present invention. FIG. 5 is a block diagram illustrating a blockchain network used in a wallet-based on-chain payment system using a visual code according to an embodiment of the present invention. FIG. 6 is a diagram illustrating an example of a payment state transition managed by a payment smart contract according to one embodiment of the present invention. FIG. 7 is a diagram schematically illustrating the NFT metadata structure for on-chain payment records and non-fungible tokens used in a wallet-based on-chain payment system using a visual code according to an embodiment of the present invention, and the mapping relationship between them. FIG. 8 is a flowchart illustrating a multi-chain dynamic routing and exchange rate hedging type on-chain payment method according to one embodiment of the present invention. FIG. 9 is a flowchart illustrating a privacy-enhanced zero-knowledge-based payment proof NFT generation method according to one embodiment of the present invention. Specific details for implementing the invention

[0023] Preferred embodiments of the present invention will be described below with reference to the attached drawings.

[0024] However, embodiments of the present invention may be modified in various different forms, and the scope of the present invention is not limited to the embodiments described below. Furthermore, embodiments of the present invention are provided to more fully explain the present invention to those with average knowledge in the relevant technical field.

[0025] That is, the aforementioned objectives, features, and advantages will be described in detail below with reference to the attached drawings, and accordingly, a person skilled in the art to which the present invention pertains will be able to easily implement the technical concept of the present invention. In describing the present invention, detailed descriptions of known technologies related to the present invention are omitted if it is determined that such descriptions may unnecessarily obscure the essence of the present invention. Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings. In the drawings, the same reference numerals are used to indicate the same or similar components.

[0026] Additionally, singular expressions used in this specification include plural expressions unless the context clearly indicates otherwise. In this application, terms such as "composed of" or "comprising" should not be interpreted as necessarily including all of the various components or steps described in the specification, and should be interpreted as meaning that some of the components or steps may not be included, or that additional components or steps may be included.

[0027] In addition, various components and their sub-components are described below to explain the system according to the present invention. These components and their sub-components may be implemented in various forms, such as hardware, software, or a combination thereof. For example, each element may be implemented as an electronic configuration to perform a corresponding function, or as software itself that is executable in an electronic system, or as a functional element of such software. Alternatively, it may be implemented as an electronic configuration and corresponding executable software.

[0028] The various techniques described herein may be implemented with hardware or software, or, where appropriate, with a combination of all of these. Terms such as "Unit," "Server," and "System" as used herein may likewise be treated as equivalent to computer-related entities, namely hardware, a combination of hardware and software, software, or software at runtime. Furthermore, each function executed in the system of the present invention may be configured as a module and may be recorded in a single physical memory or distributed among two or more memories and recording media.

[0029] Various flowcharts are disclosed to explain embodiments of the present invention, but these are for the convenience of explaining each step and do not necessarily mean that each step must be performed in the order of the flowchart. That is, each step in the flowchart may be performed simultaneously, in the order according to the flowchart, or in the reverse order of the flowchart.

[0031] Figure 1 schematically illustrates the overall configuration of a wallet-based on-chain payment system using a visual code according to one embodiment of the present invention.

[0032] Referring to FIG. 1, a wallet-based on-chain payment system (10) using a visual code includes a user terminal (100), a payment request providing device (200), and a blockchain network (300), and these are connected to communicate with each other via one or more wired or wireless communication networks, such as the Internet. Here, the visual code is a general term for a one-dimensional or two-dimensional pattern for machine reading that can be recognized by a camera, such as a QR code or a barcode.

[0033] The user terminal (100) is an electronic device that the user carries or uses, and may be, for example, a smartphone, tablet, laptop computer, wearable terminal, and a device that performs similar functions.

[0034] The user terminal (100) is a device that manages a user wallet address used for on-chain payment, recognizes a time code to obtain payment request information, and generates a payment transaction for on-chain payment based on the payment request information and transmits it to a blockchain network (300).

[0035] To this end, a wallet application linked to a blockchain network (300) may be installed and executed on a user terminal (100), and the wallet application performs the function of obtaining payment request information by capturing or scanning a visual code, and generating an on-chain payment transaction based on the payment request information and transmitting it to the blockchain network (300).

[0036] For example, a wallet application can capture or recognize a time code using a camera module or a display capture function, restore payment request information encoded in the time code, determine a recipient wallet address based on the user wallet address and recipient identification information included in the payment request information, and then generate a payment transaction requesting an asset transfer between two wallet addresses.

[0037] The user terminal (100) may also include a display, camera, network interface, etc., and may provide user interface functions such as visual code recognition, receipt of payment approval input, and display of payment results.

[0038] The payment request providing device (200) is a device that generates payment request information from the perspective of the recipient, who is the payment counterparty, and provides it to the user. It may include, for example, a POS terminal installed in an offline store, a kiosk, a table order terminal, or a display device linked to an online merchant server.

[0039] The payment request providing device (200) generates payment request information including payment information such as recipient identification information regarding a merchant, payment amount, and order identifier, and encodes the payment request information in the form of a visual code and displays it on a display so that the user terminal (100) can recognize the visual code using a camera, etc. If necessary, the payment request providing device (200) may be implemented in a way that strengthens the anti-tampering function by performing an electronic signature on the payment request information.

[0040] A blockchain network (300) conceptually represents a set of distributed devices in which multiple nodes maintain a distributed ledger, verify transactions, and create blocks. That is, the blockchain network (300) is a distributed ledger network composed of multiple nodes, which performs verification of payment transactions and block-unit recording.

[0041] In the blockchain network (300), a payment smart contract implementing the payment logic of the present invention, a merchant registration smart contract, and an NFT smart contract issuing a non-fungible token representing a payment receipt (hereinafter abbreviated as 'payment receipt smart contract') may be deployed, and a payment transaction transmitted from a user terminal (100) is verified by nodes within the blockchain network (300) and recorded on the blockchain. At this time, the payment smart contract performs the role of transferring assets from a user wallet address to a recipient wallet address based on payment request information, and generating on-chain payment information and an on-chain receipt corresponding to the payment.

[0042] The configuration illustrated in FIG. 1 is merely a schematic example for the purpose of facilitating understanding, and in actual implementation, the payment request providing device (200) may be configured to be distributed among multiple servers and terminals, and the user terminal (100) may be expanded to simultaneously connect to multiple blockchain networks (300). Additionally, although the communication network is simplified in FIG. 1, in reality, various network layers such as the Internet, mobile communication networks, and short-range wireless communication networks may be configured to overlap, and all such variations are included within the scope of the present invention.

[0044] FIG. 2 is a flowchart illustrating the overall flow of a wallet-based on-chain payment method using a visual code according to an embodiment of the present invention.

[0045] Each step illustrated in FIG. 2 illustrates a procedure in which a payment request providing device (200), a user terminal (100), and a blockchain network (300) cooperate to complete a single on-chain payment.

[0046] In step S201, the payment request providing device (200) generates payment request information including recipient identification information for identifying the payment counterparty and information regarding the payment.

[0047] In this case, the payment information includes at least the payment amount, the type of asset subject to payment, and an order identifier to identify the order, and may additionally include the payment currency, VAT information, and metadata used for internal processing by the merchant as needed.

[0048] In one embodiment, the payment request providing device (200) may configure the payment request information to additionally include a random number value for determining whether the payment request is reused and validity period information indicating the validity period of the payment request.

[0049] In one embodiment, the payment request providing device (200) may perform an electronic signature on the entire payment request information using a previously registered secret key and generate signed payment request information including the result of the electronic signature. According to this structure, a user terminal can independently determine the authenticity of the payment request providing device and whether the payment request information has been tampered with or forged through signature verification.

[0050] In step S202, the payment request providing device (200) encodes the payment request information generated in step S201 into a visual code and displays the encoded visual code on a display device.

[0051] A visual code is implemented as a machine-readable visual pattern recognizable through an image input device such as a camera, and may be, for example, a two-dimensional QR code, a one-dimensional barcode, or a code of a similar form.

[0052] In one embodiment, the payment request providing device (200) may be configured to encode signed payment request information into a visual code and include version information, an error correction code, a data format identifier, etc. within the code. For example, in an offline store, the visual code may be displayed on the screen of a POS terminal installed at the counter, in a kiosk environment, the visual code may be presented on the order completion screen, and in an online environment, the visual code may be rendered within a web payment page to induce a remote user terminal to capture it.

[0053] In step S203, the user terminal (100) recognizes the time code displayed in step S202 and obtains payment request information encoded in the time code.

[0054] Specifically, the user terminal (100) acquires a visual code image using a camera module or a screen capture module, decodes the data area inside the code through the decoding function of the wallet application, and recovers payment request information from this data area.

[0055] In one embodiment, the user terminal (100) may operate in such a way that it restores the signed payment request information from the time code and verifies the electronic signature included in the signed payment request information using a public key corresponding to the payment request providing device, so that the payment request information is used to create a payment transaction only when the electronic signature is verified to be valid.

[0056] In one embodiment, the user terminal (100) extracts a random number value and validity period information from the restored payment request information, compares the current time with the validity period information to discard payment request information whose validity period has expired, and can block payment even if the random number value overlaps with the random number value of a previous payment request recorded in the cache or local storage within the user terminal.

[0057] Through this procedure, the user terminal can pre-filter payment requests based on forged time codes, expired time codes, and reused time codes.

[0058] In step S204, the user terminal (100) generates a payment transaction for on-chain payment based on the payment request information obtained in step S203, and transmits the payment transaction to the blockchain network (300).

[0059] At this time, the user terminal (100) sets a user wallet address managed by a wallet application and determines a recipient wallet address based on recipient identification information included in the payment request information. For example, if the recipient identification information is a merchant identifier, the user terminal can obtain a recipient wallet address corresponding to the merchant identifier through a query on a pre-synchronized merchant information table or a merchant registration registry on the blockchain.

[0060] A payment transaction may include a user wallet address, a recipient wallet address, a payment amount, a payment asset, a random number value, an order identifier, and all of the payment request information or the hash value of the payment request information.

[0061] In one embodiment, the user terminal (100) displays the payment amount and network fee to the user on the screen, and only after receiving the user's payment approval input can it create and sign the payment transaction and then broadcast it to the blockchain network (300).

[0062] In another embodiment, the user terminal can be configured to set the chain identifier and asset type of the payment transaction according to the network selected by the user from among a plurality of blockchain network candidates.

[0063] In step S205, a payment smart contract executed on a blockchain network (300) receives a payment transaction transmitted by a blockchain node and performs a transfer of assets from a user wallet address to a recipient wallet address based on payment request information included in the payment transaction.

[0064] Specifically, the payment smart contract verifies the payment request information or the hash value of the payment request information included in the payment transaction, and extracts the random number value and recipient identification information included in the payment request information to verify the recipient wallet address.

[0065] In one embodiment, the payment smart contract maintains reuse management information using a combination of a recipient wallet address and a random number value as a key, and may refuse asset transfer if there is a record that a specific random number value has already been used for a specific recipient wallet address.

[0066] In one embodiment, the payment smart contract may compare the validity period information included in the payment request information with the current block time and not allow asset transfer for payment requests for which the validity period has expired.

[0067] In one embodiment, the blockchain network (300) further includes a merchant registration smart contract that corresponds a recipient wallet address with recipient business information, and the payment smart contract can verify whether the recipient wallet address is a pre-registered merchant wallet address by performing a query on the merchant registration registry during the payment transaction processing process. In this case, the payment smart contract can ensure that on-chain payment is limited to approved recipients by refusing asset transfer for payment transactions with unregistered wallet addresses as recipients.

[0068] In step S206, the payment smart contract records on-chain payment information corresponding to the payment transaction on the blockchain and, if necessary, issues a non-fungible token representing the payment receipt.

[0069] Specifically, the payment smart contract generates a payment identifier uniquely assigned to each payment transaction and stores a payment record as on-chain payment information that includes the payment identifier, user wallet address, recipient wallet address, payment amount, payment time, and payment status. The payment status can be set to one of, for example, a request status, a payment completed status, a refund completed status, a cancellation completed status, and a dispute status, and the payment status can be set to a payment completed status at the time when the asset transfer is successfully completed in step S205.

[0070] In one embodiment, a payment smart contract may be configured to issue a non-fungible token corresponding to a payment identifier and record payment information included in a payment record in the metadata of the non-fungible token so that the non-fungible token functions as an on-chain receipt for a specific payment.

[0071] In one embodiment, when a payment smart contract receives a refund request transaction, it performs an asset refund to a user wallet address, updates the payment status of the on-chain payment information to a refund completed status, and can also reflect the refund fact and the time of refund in the metadata of the non-fungible token.

[0072] In one embodiment, when a merchant or user submits a dispute-raising transaction, the payment status is updated to a dispute status, and the occurrence of a dispute and the time of the dispute are recorded in the metadata of the non-fungible token corresponding to the payment identifier, thereby allowing the on-chain receipt to be used as supporting evidence in the subsequent dispute resolution process.

[0073] Through a series of steps illustrated in FIG. 2, the payment request providing device, user terminal, and blockchain network perform visual code-based on-chain payment, and implement verification of the consistency of payment request information, prevention of payment request reuse, payment restriction for registered merchants, payment status management, and on-chain receipt issuance as an integrated procedure.

[0075] FIG. 3 schematically illustrates the internal configuration of a payment request providing device (200) used in a wallet-based on-chain payment system using a visual code according to one embodiment of the present invention.

[0076] Referring to FIG. 3, the payment request providing device (200) includes a merchant information management module (210), a payment request generation module (220), an electronic signature module (230), a visual code display module (240), and a merchant registration management interface (250), and performs a series of functions including managing merchant information, generating payment request information, and displaying payment request information as a visual code.

[0077] The merchant information management module (210) performs the role of registering and managing merchant-related information used by the payment request providing device (200).

[0078] The merchant information management module (210) can manage a merchant identifier, a merchant name, a business registration number, and settlement account information, along with a recipient wallet address used for on-chain payment.

[0079] Additionally, the merchant information management module (210) can register multiple recipient wallet addresses for a single merchant and perform the function of mapping different recipient wallet addresses by payment channel, asset type, or chain. For example, a payment request providing device (200) installed in an offline store can store not only merchant information at the store level but also internal identification information such as table number, terminal location, and sales channel code, and can subsequently be used to link on-chain payment information with detailed sales records within the store.

[0080] The payment request generation module (220) performs the function of configuring payment request information based on the merchant information and actual order data stored in the merchant information management module (210).

[0081] The payment request generation module (220) generates payment request information including at least recipient identification information and payment amount, and may additionally include an order identifier, type of asset to be paid, chain identifier, VAT information, and memo information for internal merchant use as needed.

[0082] In one embodiment, the payment request generation module (220) may configure the payment request information to include a random number value for determining whether the payment request is reused and validity period information indicating the validity period of the payment request. These random number value and validity period information can subsequently be used in the user terminal and the payment smart contract to verify whether the payment request has been tampered with and whether it has been reused.

[0083] The electronic signature module (230) is responsible for adding an electronic signature to the payment request information configured by the payment request generation module (220).

[0084] The electronic signature module (230) can generate signed payment request information by using a secret key securely stored in the payment request providing device (200) to perform an electronic signature operation on the entire payment request information or the hash value of the payment request information, and combining the signature result with the payment request information.

[0085] In one embodiment, the electronic signature module (230) is configured to use an asymmetric key-based electronic signature algorithm, such as ECDSA, which is widely used in public blockchains, and can register a public key or certificate corresponding to the private key to a blockchain network or a separate authentication system through a merchant registration management interface (250). The payment request information signed in this way can be used as a basis for confirming the authenticity and data integrity of the payment request providing device by having the user terminal independently perform electronic signature verification.

[0086] The visual code display module (240) encodes the signed payment request information generated by the electronic signature module (230) into a visual code format and performs the function of displaying the encoded visual code on the display of the payment request providing device (200).

[0087] The visual code display module (240) can generate a code image by selecting an appropriate version of the visual code specification according to the length and data format of the signed payment request information, and by setting an error correction level and a data block structure.

[0088] In one embodiment, the visual code display module (240) is implemented to support various visual code formats such as QR codes, data matrix codes, and one-dimensional barcodes, and can display the code by adjusting the code size or brightness contrast according to the merchant operating environment so that the camera of the user terminal can stably recognize it.

[0089] The visual code display module (240) can display payment request information as a visual code, and also display amount information, merchant name, order summary, etc., in text form on the same screen so that the user can intuitively check the payment request details.

[0090] The merchant registration management interface (250) is a component responsible for interoperability between the payment request providing device (200) and an external merchant registration system or blockchain network.

[0091] The merchant registration management interface (250) can perform functions such as sending a merchant registration request to a merchant registration smart contract deployed on a blockchain network, or updating or deleting existing registration information, by using the recipient wallet address and merchant identification information stored in the merchant information management module (210).

[0092] In one embodiment, the merchant registration management interface (250) may be implemented as a node program that directly connects to a blockchain network or as an API client that interacts with the backend server of a payment business operator. Through such an interface, the payment smart contract can check whether the recipient wallet address is registered in the merchant registration registry at the time of payment processing, and can consistently apply a policy on-chain that allows only payments to registered merchants.

[0093] The modules illustrated in FIG. 3 are represented as functional blocks for understanding logic, and in actual implementation, they may be implemented as software programs on a computing device including a processor and memory, or some modules may be integrated with each other or separated and implemented as separate devices. For example, the merchant information management module (210) and the merchant registration management interface (250) may be integrated into a single merchant management module, and the electronic signature module (230) may be implemented as a separate security processing device linked with a hardware security module. These various modified structures may also be understood as embodiments of the present invention within the scope that does not deviate from the basic concept of a payment request providing device that generates payment request information, adds an electronic signature, and displays a visual code.

[0095] FIG. 4 is a block diagram illustrating a user terminal used in a wallet-based on-chain payment system using a visual code according to an embodiment of the present invention.

[0096] Referring to FIG. 4, the user terminal (100) includes a time code recognition module (110), a wallet application (120), and a communication module (130). The wallet application (120) is subdivided into a time code decoding module (121), an electronic signature verification module (122), a random number and validity verification module (123), a user wallet address management module (124), a payment transaction creation module (125), a blockchain interface module (126), and a user interface module (127). With this configuration, the user terminal integrally performs time code recognition, payment request information verification, and on-chain payment transaction creation and transmission functions.

[0097] The visual code recognition module (110) is responsible for acquiring a visual code image displayed on a payment request providing device using a camera sensor or a display capture function. The visual code recognition module (110) extracts a visual code area by performing automatic focus adjustment, brightness and contrast correction, tilt correction, etc., and then transmits the extracted image to the visual code decoding module (121).

[0098] In one embodiment, the visual code recognition module (110) determines whether code recognition is successful based on the image processing result, and if recognition fails, it can display a re-shooting guidance message through the user interface module (127).

[0099] The wallet application (120) is a software component that runs on a user terminal and implements a series of logics that interpret payment request information included in a time code and create and transmit an on-chain payment transaction using the user wallet address. The time code decoding module (121) receives image or code area data received from the time code recognition module (110) as input and performs decoding operations according to the time code specifications.

[0100] The visual code decoding module (121) interprets the data area and the error correction code to restore payment request information, and if necessary, parses the signed payment request information, random number value, validity period information, recipient identification information, payment amount, order identifier, etc. from the restored data and converts them into an internal representation format.

[0101] The electronic signature verification module (122) performs the role of verifying the validity of the electronic signature included in the signed payment request information restored by the visual code decoding module (121). The electronic signature verification module (122) performs the signature operation in reverse by referencing a public key or certificate to identify the payment request provider device, and determines data integrity and sender authenticity by comparing the hash value used when generating the signature with the recalculated hash value. If the electronic signature verification result is invalid, the electronic signature verification module (122) may indicate that the payment request information should not be used in a subsequent step and instruct the user interface module (127) to output an error message.

[0102] The random number and validity verification module (123) verifies whether a payment request is reused and whether the validity period has expired by using the random number value and validity period information included in the payment request information. The random number and validity verification module (123) records the random number value of a payment request that has already been processed in an internal storage or a database of a wallet application, and checks whether the random number value of the newly restored payment request information duplicates the recorded value. Additionally, the random number and validity verification module (123) compares the validity period information included in the payment request information with the current terminal time, and if the validity period has expired, processes the payment request as invalid.

[0103] In one embodiment, the random number and validity verification module (123) may be designed to determine the validity period with an allowable error range that takes into account network delay or time synchronization error.

[0104] The user wallet address management module (124) is a component that manages user wallet addresses used for on-chain payments and their corresponding private keys. The user wallet address management module (124) stores multiple wallet addresses corresponding to one or more blockchain networks and can provide appropriate user wallet addresses according to the network and asset type selected by the user. Additionally, the user wallet address management module (124) protects the private key from being leaked externally by storing the private key in a secure cryptographic storage and returning the signature result through a restricted interface only when the payment transaction generation module (125) requests a signature operation.

[0105] The payment transaction generation module (125) performs the role of configuring a payment transaction for on-chain payment based on payment request information whose validity has been verified through the electronic signature verification module (122) and the random number and validity verification module (123). The payment transaction generation module (125) can set a user wallet address provided by the user wallet address management module (124) and a recipient wallet address corresponding to the recipient identification information included in the payment request information, and can generate a transaction payload including the payment amount, payment assets, random number value, order identifier, and hash value of the payment request information. The payment transaction generation module (125) adds a private key signature provided by the user wallet address management module (124) to the generated transaction to complete an on-chain payment transaction verifiable on the blockchain network.

[0106] In one embodiment, the payment transaction generation module (125) may dynamically adjust the transaction fee value by reflecting network fee level and block congestion information, or may be linked with the user interface module (127) so that the user can directly select the fee level.

[0107] The blockchain interface module (126) is responsible for transmitting the payment transaction generated by the payment transaction generation module (125) to the blockchain network and monitoring the payment results. The blockchain interface module (126) establishes a network session with a blockchain node or gateway server through the communication module (130) and transmits the payment transaction using a remote procedure call or transaction broadcast protocol according to the specifications. The blockchain interface module (126) can track whether the transaction is included in a block and the number of confirmed blocks based on the hash value of the transmitted transaction, and can determine the payment status by querying the on-chain payment information recorded in the payment smart contract.

[0108] The user interface module (127) is a component responsible for user interaction throughout the payment process. After visual code recognition is completed, the user interface module (127) displays the merchant name, payment amount, asset type, chain information, etc. extracted from the payment request information on the screen and receives input from the user for payment approval or cancellation. In addition, it provides warning messages or guidance messages when various exceptions occur, such as electronic signature verification failure, random number duplication, expiration of validity period, or network error, to help the user intuitively recognize the safety of the payment.

[0109] In one embodiment, the user interface module (127) may be implemented to provide an on-chain receipt lookup link along with a payment identifier after payment is completed, and to allow the user to verify payment history through a blockchain explorer or wallet screen when needed.

[0110] The communication module (130) is a hardware and software component responsible for transmitting and receiving data between the user terminal (100) and an external network. The communication module (130) may include communication interfaces such as a mobile communication network, Wi-Fi, and Ethernet, and provides the network connection required by the blockchain interface module (126). Additionally, the communication module (130) may also be used for communication with a merchant backend server, a price information providing server, a time synchronization server, etc.

[0111] Each module illustrated in FIG. 4 is represented as a logical functional unit, and in actual implementation, it may be executed by being integrated or divided within a single application process, and some functions may be performed in conjunction with an operating system-level module or a hardware security module. All of these various implementation forms can be understood as embodiments of the present invention as long as they do not deviate from the basic concept that a user terminal including a visual code recognition function and a wallet function verifies payment request information and generates and transmits a payment transaction for on-chain payment.

[0113] FIG. 5 is a block diagram illustrating a blockchain network used in a wallet-based on-chain payment system using a visual code according to an embodiment of the present invention.

[0114] Referring to FIG. 5, the blockchain network (300) includes a payment smart contract (310), a merchant registration smart contract (320), and a payment receipt smart contract (330).

[0115] The payment smart contract (310) is subdivided into a payment request verification module (311), a random number reuse verification module (312), a payment state management module (313), a payment record storage module (314), a refund processing module (315), a dispute processing module (316), and an NFT issuance trigger module (317).

[0116] The payment request verification module (311) performs the role of verifying the consistency and validity of the payment request information included in the payment transaction when the payment transaction described in FIG. 2 is submitted to the blockchain network (300). The payment request verification module (311) parses the payment request information or the hash value of the payment request information included in the payment transaction to extract recipient identification information, payment amount, order identifier, validity period information, random number value, etc., and checks whether all required fields are included and whether the format conforms to the specifications.

[0117] In one embodiment, the payment request verification module (311) receives an electronic signature value for the payment request information and a public key corresponding to the payment request providing device as input and performs signature verification, thereby determining whether the payment request information is legitimate data issued by the payment request providing device.

[0118] In one embodiment, the payment request verification module (311) can obtain a recipient wallet address corresponding to the recipient identification information by querying the merchant registration smart contract (320), and can further verify the consistency between the payment request information and the payment transaction by comparing whether it matches the recipient wallet address included in the payment transaction.

[0119] The random number reuse verification module (312) performs the role of managing the random number value included in the payment request information so that it is used only once for the same recipient wallet address. When processing a payment transaction, the random number reuse verification module (312) queries reuse status management information using the combination of the recipient wallet address and the random number value as a key, and if the same combination is already recorded, it does not allow the transfer of assets for the corresponding payment transaction.

[0120] In one embodiment, the random number reuse verification module (312) receives validity period information included in the payment request information from the payment request verification module (311) and can link with the payment logic to prevent asset transfer even for payment requests that have expired.

[0121] The payment status management module (313) is responsible for managing the status of individual payments. Based on a payment identifier to identify each payment, the payment status management module (313) stores a status value among a payment request status, a payment completed status, a refund completed status, a cancellation completed status, and a dispute status, and performs state transitions according to events generated by other modules of the payment smart contract (310). For example, if the payment request verification module (311) and the random number reuse verification module (312) pass verification and the actual asset transfer is successfully completed, the payment status management module (313) sets the status of the corresponding payment identifier to the payment completed status. If the refund processing module (315) completes the refund, it updates to the refund completed status, and if the dispute processing module (316) receives a transaction initiating a dispute, it switches to the dispute status.

[0122] In one embodiment, the payment status management module (313) can support complex payment scenarios by additionally defining more granular status values, such as partial refund and partial cancellation.

[0123] The payment record storage module (314) performs the function of configuring and recording on-chain payment information to be stored on the blockchain. When processing a payment transaction, the payment record storage module (314) generates a payment record that includes a payment identifier, a user wallet address, a recipient wallet address, a payment amount, a type of payment asset, a time of payment, and a payment status field managed by the payment status management module (313). This payment record is stored in the state area or event log of the blockchain network (300) and subsequently used as a basis for an external system or user terminal to query the on-chain payment history.

[0124] In one embodiment, the payment record storage module (314) can increase connectivity with the off-chain backend system by storing additional metadata such as the hash value of the payment request information, the order identifier, and the merchant internal identifier.

[0125] The refund processing module (315) is a component that performs a refund procedure when a refund request transaction is submitted by a user or a merchant. The refund processing module (315) looks up existing payment records based on the payment identifier included in the refund request transaction, determines whether a refund is possible, and then, if the conditions are met, creates an asset refund transaction to the user's wallet address. After the refund is completed, the refund processing module (315) instructs the payment status management module (313) to update the payment status to a refund completed state, and links with the payment record storage module (314) to record the updated payment record containing refund time and refund amount information.

[0126] The dispute processing module (316) performs the role of processing dispute-raising transactions submitted by merchants or users. The dispute processing module (316) receives the payment identifier and the reason for the dispute included in the dispute-raising transaction and requests the payment status management module (313) to convert the corresponding payment record into a dispute state. If necessary, the dispute processing module (316) transmits the time of the dispute occurrence and the type of dispute to the payment record storage module (314) so ​​that the dispute-related information is reflected in the on-chain payment information and the on-chain receipt issued thereafter.

[0127] In one embodiment, the dispute processing module (316) may include a function to separately manage the address of a third dispute mediator and to readjust the payment status to a refund completed status or a payment completed status according to the dispute resolution transaction submitted by the dispute mediator.

[0128] The NFT issuance trigger module (317) is responsible for calling the payment receipt smart contract (330) to issue a non-fungible token representing the payment receipt. The NFT issuance trigger module (317) transmits a call containing a payment identifier to the payment receipt smart contract (330) when the payment transaction passes the verification of the payment request verification module (311) and the random number reuse verification module (312) and the asset transfer is successfully completed. The payment receipt smart contract (330) issues a new non-fungible token based on the received payment identifier and records payment information managed by the payment record storage module (314) in the token metadata so that the issued non-fungible token functions as an on-chain receipt for a specific payment. In one embodiment, the NFT issuance trigger module (317) calls the payment receipt smart contract (330) to update the metadata even when the refund processing module (315) or the dispute processing module (316) changes the payment status, thereby ensuring that the on-chain receipt reflects the latest payment status.

[0129] The merchant registration smart contract (320) acts as a registry that manages recipient wallet addresses and recipient business information on-chain. The merchant registration smart contract (320) processes registration requests, change requests, and deletion requests submitted through the merchant registration management interface, and stores a set of recipient wallet addresses and business metadata corresponding to each merchant. The payment request verification module (311) and the random number reuse verification module (312) of the payment smart contract (310) can query the merchant registration smart contract (320) when processing a payment transaction to verify whether a specific recipient wallet address is a registered merchant wallet address. Due to this structure, on-chain payments are limited to registered merchants, and the effect of preventing asset transfer to unauthorized wallet addresses can be achieved.

[0130] The payment receipt smart contract (330) is a smart contract responsible for the issuance and management of non-fungible tokens corresponding to a payment. When the payment receipt smart contract (330) receives a payment identifier and related metadata from the NFT issuance trigger module (317), it issues a new token and stores information mapping the token identifier to the payment identifier, thereby enabling the receipt token corresponding to a specific payment to be quickly retrieved. Additionally, the payment receipt smart contract (330) may provide an interface for updating token metadata in response to payment status changes, refunds, and dispute occurrence and resolution events.

[0131] Each smart contract and module illustrated in FIG. 5 represents a logical functional unit, and in actual implementation, some modules may be integrated within a single payment smart contract or separated into a separate library contract. These various forms of implementation can all be interpreted as embodiments of the present invention as long as they maintain the basic concept that the blockchain network performs payment request verification, random number reuse verification, merchant registration verification, payment status management, refund and dispute processing, payment record storage, and non-fungible token-based on-chain receipt issuance functions.

[0133] FIG. 6 is a diagram illustrating an example of a payment state transition managed by a payment smart contract according to one embodiment of the present invention.

[0134] The payment state management module of the payment smart contract described in Fig. 5 records the payment state for each payment identifier and maintains the state field of the on-chain payment information consistently by updating the state according to various events shown in Fig. 6.

[0135] Referring to FIG. 6, five states are exemplified: a payment request state (ST_REQ) (610), a payment completed state (ST_PAID) (620), a refund completed state (ST_REFUND) (630), a cancellation completed state (ST_CANCEL) (640), and a dispute state (ST_DISPUTE) (650), and transition events between each state are exemplified.

[0136] First, the payment request state (ST_REQ) (610) represents the initial state in which the payment smart contract performs payment request verification before or immediately after the payment transaction is included in the block. When a user terminal creates a payment transaction based on payment request information and transmits it to the blockchain network, the payment state management module sets the state corresponding to the payment identifier to the payment request state. In this state, the payment smart contract checks the consistency of the payment request information, the validity period, and whether the random number is reused through the payment request verification module, and, if necessary, performs a query on the merchant registration smart contract to verify whether the recipient wallet address is a registered merchant.

[0137] The payment approval event (E_PAY) is an event that triggers a transition from the payment request state to the payment completion state. When the payment smart contract successfully completes the payment request verification and performs the asset transfer from the user wallet address to the recipient wallet address, the payment state management module changes the state of the corresponding payment identifier to the payment completion state (ST_PAID) (620). At this time, the payment record storage module stores on-chain payment information by setting the payment status field to the payment completion state along with the payment identifier, user wallet address, recipient wallet address, payment amount, and payment time. Additionally, the NFT issuance trigger module can call the payment receipt smart contract to issue a non-fungible token corresponding to the payment identifier, and the payment completion state is reflected in the metadata of the issued non-fungible token.

[0138] The refund event (E_REFUND) represents a transition from the payment completed state to the refund completed state. When a transaction in which a user requests a refund or a merchant approves a refund is submitted to the blockchain network, the refund processing module queries the payment record to check the refund eligibility conditions, and if the conditions are met, executes a transaction to refund assets to the user's wallet address. When the refund processing module successfully completes the refund procedure, the payment state management module updates the state of the payment identifier to the refund completed state (ST_REFUND) (630), and the payment record storage module additionally records the refund time and refund amount information. In conjunction with this, the NFT issuance trigger module requests a metadata update from the payment receipt smart contract and updates the state of the non-fungible token used as an on-chain receipt to refund completed, thereby ensuring that the refund history is clearly revealed during post-verification.

[0139] The cancellation event (E_CANCEL) is an event that triggers a transition from the payment request state or the dispute state to the cancellation completed state. When the cancellation event occurs in the payment request state, it corresponds to a scenario where a merchant or user cancels a payment before payment approval is granted. In this case, the payment smart contract does not perform asset transfer and sets the state to the cancellation completed state (ST_CANCEL) (640) through the payment state management module, and specifies in the payment record that no asset transfer occurred. When the cancellation event occurs in the dispute state, it may correspond to a situation where it is decided to process the payment as a cancellation rather than maintaining it based on the dispute resolution result, and in this case as well, the payment state transitions to the cancellation completed state.

[0140] The dispute filing event (E_DISPUTE) is an event that leads to a transition from the payment completion state to the dispute state. If a user or merchant has an objection to the payment within a certain period after the payment is completed, they may submit a dispute filing transaction. Upon receiving such a transaction, the dispute processing module requests the payment status management module to change the status of the payment identifier to the dispute state (ST_DISPUTE) (650). In the dispute state, the payment record records whether a dispute has occurred and the time of the dispute, and if necessary, codes or summary information indicating the cause of the dispute are also stored. This information is subsequently used in the dispute resolution process and for the judgment of an external mediator.

[0141] The refund decision event (E_RESOLVE_REFUND) indicates a transition from the dispute state to the refund completed state. If the dispute processing module determines that a refund is valid based on the dispute mediation result, it calls the refund processing module to refund assets to the user's wallet address, and the payment state management module updates the status to the refund completed state. At this time, the payment record may specify that the refund was decided through a dispute, and the payment receipt smart contract can reflect both the dispute resolution method and refund information in the metadata of the non-fungible token.

[0142] The payment retention event (E_RESOLVE_UPHOLD) signifies a transition returning from a disputed state back to a payment completed state. If it is decided to retain the payment based on the dispute mediation result, the dispute processing module instructs the payment status management module to reset the payment status to the payment completed state. In this case, since no refund is executed, the payment record retains its original payment completed state information, but history information indicating that a dispute was filed and subsequently dismissed may be added.

[0143] According to the payment state transition diagram shown in Fig. 6, the payment smart contract manages various events such as payment requests, payment approvals, cancellations, refunds, and dispute processing as a structured state machine. This state management structure ensures that on-chain payment information and non-fungible token-based on-chain receipts always reflect the same payment state, and enables clear and consistent tracking of payment history during long-term accounting verification, settlement, and dispute resolution processes.

[0145] FIG. 7 is a diagram schematically illustrating the NFT metadata structure for on-chain payment records and non-fungible tokens used in a wallet-based on-chain payment system using a visual code according to an embodiment of the present invention, and the mapping relationship between them.

[0146] Referring to FIG. 7, a payment record structure (710) and an NFT metadata structure (720) are illustrated, and the two structures are connected to each other by a mapping relationship (730).

[0147] The payment record structure (710) exemplifies the configuration of data fields of on-chain payment information maintained by a payment smart contract in a blockchain network. The payment record structure (710) includes a paymentId field for identifying the payment, a userAddress field representing the user wallet address corresponding to the payment subject, a merchantAddress field representing the recipient wallet address, amount, token, and chainId fields containing the payment amount, the type of payment target token, and a chain identifier, a timestamp field representing the time at which the payment was processed, and a status field representing the payment status. Here, the status field may have one of the status values ​​described in FIG. 6: payment request status, payment completed status, refund completed status, cancellation completed status, and dispute status, and the payment status management module appropriately updates the corresponding field during the payment processing process.

[0148] In one embodiment, the payment record structure (710) may further include additional fields such as an order identifier, a merchant internal identifier, payment fee information, and a refund history summary to facilitate integration with an off-chain settlement system.

[0149] The NFT metadata structure (720) exemplifies the composition of metadata held by a non-fungible token issued in a payment receipt smart contract. The NFT metadata structure (720) includes a TokenId field to identify the non-fungible token itself, a LinkedPaymentId field indicating a connection to a payment record, a Summary field summarizing the payment history, a StatusSnapshot field indicating a snapshot of the payment status, and a HistoryRef field for historical reference. The LinkedPaymentId field corresponds one-to-one with the PaymentId of the Payment Record structure (710), thereby clearly identifying which payment record a specific non-fungible token is a receipt for. The Summary field may include human-readable summary information such as abbreviated expressions of the user wallet address and recipient wallet address, the payment amount, the payment asset, and the payment date, and the StatusSnapshot field reflects the payment status at the time of receipt issuance or the latest time by referencing the Status field of the payment record. The historyRef field can be configured to include a reference value to an on-chain event log or an off-chain dispute resolution document, allowing direct access to detailed payment history or dispute resolution results from the non-fungible token.

[0150] The mapping relationship (730) represents a logical connection between the payment record structure (710) and the NFT metadata structure (720). The payment smart contract processes the payment transaction to create a payment record containing a paymentId, and the payment receipt smart contract issues a non-fungible token using the corresponding paymentId value as the linkedPaymentId, thereby enabling one NFT to correspond to one payment. Subsequently, when the payment status changes to a refund or dispute status, the status value of the payment record structure (710) is updated, and the statusSnapshot and historyRef fields of the NFT metadata structure (720) are also updated, so that the non-fungible token functions as an on-chain receipt reflecting the latest status of the payment.

[0151] In this way, through the payment record structure, NFT metadata structure, and mapping relationship illustrated in FIG. 7, on-chain payment information and non-fungible token-based receipts are linked to each other while maintaining consistency, and users can intuitively check the key information and current status of the payment even if they only check a specific NFT on the wallet or block explorer screen.

[0153] FIG. 8 is a flowchart illustrating a multi-chain dynamic routing and exchange rate hedging type on-chain payment method according to one embodiment of the present invention.

[0154] The embodiment of FIG. 8 is characterized by including multiple blockchain networks and token combinations as candidates for a single time code, selecting an optimal payment path by reflecting chain-specific market rates and fee information in real time, and automatically opening and settling an exchange rate hedge position corresponding to the selected path in conjunction with the payment. Through this, users can perform payments targeting a certain nominal amount at stable costs and predictable exchange rates without being involved in complex chain selection or exchange rate risk management, and payment providers can provide an optimized payment infrastructure that considers chain-specific fees and liquidity.

[0155] In addition, this embodiment is designed to go beyond simply selecting one of several chains, to integrally calculate settlement costs and hedging costs for each candidate chain, and to determine a settlement path that minimizes said costs and risks. Unlike conventional structures where exchange rate hedging strategies and settlement transactions are processed asynchronously, the procedure of FIG. 8 defines a settlement policy with a built-in hedging strategy from the settlement request generation stage and manages the settlement of hedging positions at the time of settlement confirmation as a single integrated state machine, thereby significantly reducing subsequent losses from exchange rate fluctuations or unhedged settlement ratios.

[0156] Referring to FIG. 8, first, in step S810, the payment request providing device generates payment request information including multiple chain candidates. Here, the multiple chain candidates represent different blockchain networks and token pairs, and may be configured, for example, as a stablecoin token of public chain A, a highly liquid governance token of public chain B, and a low-fee stablecoin token of sidechain C. The payment request providing device configures the payment request information to include a target amount in a base currency for a single payment, such as "10,000 KRW" or "100 USD," and to include constraints such as the maximum allowable fee limit, maximum allowable latency, and minimum liquidity level for each candidate chain.

[0157] In one embodiment, the payment request providing device may include chain-specific success rate statistics, block congestion profiles, and user's preferred chain information collected from past payment history, and may assign policy-based weights during the subsequent routing process.

[0158] In step S820, the component responsible for routing, such as an on-chain routing smart contract or an off-chain routing service, queries price and fee information for each candidate chain. This component queries the exchange rate of each candidate token against the base currency from a price oracle and obtains the gas price of the individual chain, the estimated block finalization time, and fee estimates reflecting the recent block congestion.

[0159] In one embodiment, the routing component collects query results from a plurality of independent oracle providers and can filter abnormal prices through aggregation methods such as the median or weighted average.

[0160] In another embodiment, the chain-specific fee information can provide a more realistic fee estimate by using the "recent N-block average fee" measured in real-time by a gateway server operating a direct node.

[0161] In step S830, the routing component calculates settlement costs and hedging costs for each candidate chain. First, for each candidate chain, the target nominal amount is converted into the tokens of that chain, and the total settlement cost is calculated by adding the estimated network fees and slippage costs to the converted token quantity. Next, assuming a hedging strategy to mitigate exchange rate fluctuation risk, the size of the required hedge position for each chain and the hedging costs required to construct said position are estimated. Hedging costs may include derivatives trading fees, liquidity pool deposit costs, premium payments, etc. The routing component calculates the total cost per chain by summing the settlement costs and hedging costs calculated in this way, and compares and evaluates the candidate chains based on the total cost.

[0162] In one embodiment, the routing component may evaluate candidate chains using a multi-objective optimization function that assigns additional weight to risk indicators such as the estimated time to settlement confirmation, chain-specific reorg occurrence rate, and regulatory compliance, in addition to simple cost summation.

[0163] In step S840, the routing component selects the optimal chain and token combination based on the previously calculated evaluation results. At this stage, the selection criteria can be set differently depending on the payment policy. For example, general users may use a policy that prioritizes "minimizing total cost," while specific merchants may set a composite policy such as "prioritizing a designated chain, provided that the total cost of the designated chain does not exceed twice that of other chains." The routing component selects the chain with the minimum total cost from among the candidates satisfying these policies and determines the token corresponding to the selected chain, the estimated payment amount, and the necessary hedging strategy parameters. The selection result is reflected in the payment request information so that the user terminal and the payment smart contract can reference the same selection value.

[0164] In one embodiment, the routing component can apply a failover strategy that can quickly re-select an alternative path in the event of a payment failure or chain failure by secondarily storing information on the top 2 or 3 candidate chains along with the optimal chain selection result.

[0165] In step S850, the determination of the exchange rate hedging strategy and the generation of the hedging specification are performed. The hedge management module receives inputs such as the selected chain and token, the target notional amount, and the estimated settlement time, and determines which exchange rate hedging instrument to use. For example, if the selected chain uses a dollar-pegged stablecoin, dollar futures or forward contracts may be used; if it is a highly volatile altcoin, option combinations or a delta hedging structure between spot and futures may be used. The hedge management module evaluates the costs and risks for each hedging instrument to select the most suitable strategy and generates a hedging specification that includes the trading pairs, quantities, expiration dates, liquidation conditions, etc. required for hedging.

[0166] In one embodiment, the hedge management module supports a partial hedging strategy that hedges only a portion of the payment amount rather than the entire amount, thereby balancing the hedging costs and the remaining risk.

[0167] In step S860, the hedge management module transmits a hedge execution transaction according to the hedge specification. The hedge execution transaction may be transmitted to a selected chain or a chain where a separate derivatives protocol is running, for example, to transmit a request to open a position to a smart contract of an on-chain derivatives exchange or to construct a position to offset price fluctuation risk by depositing specific assets into an automated market maker pool. The hedge management module tracks whether the hedge transaction has been executed and records whether the hedge has been successfully opened in a settlement record or a separate hedge status information.

[0168] In some embodiments, the hedge management module may apply a policy to automatically select an alternative hedge strategy within a range previously allowed by the user or to conservatively postpone the payment itself if the hedge execution fails.

[0169] In step S870, the user terminal creates and transmits a payment transaction based on the selected chain. A wallet application running on the user terminal refers to the chainId and token information determined by the routing component to construct a payment transaction between the user wallet address and the recipient wallet address of the corresponding chain. The transaction may include the payment amount, fee cap, selected chain information, a random number value used for multi-chain routing, and a hedge identifier. The user confirms the selected chain, the estimated total cost, and whether exchange rate hedging is applied through the user interface, approves the payment, and the wallet application signs the transaction with the private key corresponding to the user wallet address and broadcasts it to the blockchain network. This process is an extension of the payment transaction creation and transmission step described in FIG. 2, reflecting dynamic chain selection based on the routing result instead of a single-chain fixed structure.

[0170] In step S880, the settlement smart contract verifies that the settlement has been confirmed on the selected chain, and then performs hedge position settlement and status updates. The settlement smart contract or the linked hedge management module determines whether to liquidate the hedge position and the settlement time based on the point in time when the settlement transaction is included in a sufficient number of blocks and reaches the settlement completion state. For example, if a futures position is held, the position is closed according to the exchange rate at the time of settlement confirmation, and the resulting profit or loss is settled into a dedicated hedge account. These settlement results are recorded as summary information in the supplementary field of the settlement record or in the historyRef field of the NFT metadata, and can be utilized for subsequent accounting processing and risk analysis. (Additional) In one embodiment, the hedge management module may support a "post-settlement dynamic hedging" mode that monitors exchange rate fluctuations for a certain period after settlement is completed and automatically performs additional hedging or position rebalancing if necessary.

[0171] By the procedure illustrated in Fig. 8, the visual code-based on-chain payment moves away from a simple payment method fixed to a single chain and expands into a form that combines a dynamic routing structure that simultaneously considers multiple chains and token candidates with an exchange rate hedging strategy linked to the payment. As a result, users and merchants can be significantly protected from chain-specific fee fluctuations and exchange rate risks, and payment providers gain the advantage of being able to flexibly utilize multiple blockchain networks while providing a consistent payment experience based on nominal amounts.

[0173] FIG. 9 is a flowchart illustrating a privacy-enhanced zero-knowledge-based payment proof NFT generation method according to one embodiment of the present invention.

[0174] The embodiment of FIG. 9 provides a structure that issues a payment proof-only NFT that reflects the result, by presenting only the fact that a payment satisfies specific conditions as a zero-knowledge proof, without directly exposing payment records recorded on the chain. Through this, the user can selectively prove the fact that a legitimate payment was made at a specific merchant, the fact that a payment of more than a certain amount was made, or the fact that repeated payments were made within a specific period, without revealing sensitive payment information, such as the actual payment amount, wallet address, or detailed time information, to a third party.

[0175] In addition, this embodiment introduces an indirect connection structure mediated by an anonymous payment identifier between the payment record and the NFT metadata, and includes the commitment and proof type information used in the zero-knowledge proof in the NFT metadata, thereby ensuring only the legitimacy of the payment on-chain and maintaining detailed information only in an encrypted form or through external reference. While existing on-chain receipt structures exposed the entire payment record directly in the NFT metadata, the embodiment of FIG. 9 has a differentiated technical configuration in that it simultaneously achieves privacy protection and auditability by managing the payment record, commitment, and zero-knowledge proof separately.

[0176] Referring to FIG. 9, in step S910, payment summary data separation and commitment generation are performed. For example, a user terminal or a payment provider's backend server separates personal information or sensitive information that is not required for verification from fields such as paymentId, userAddress, merchantAddress, amount, token, chainId, timestamp, and status in the previously described payment record structure. In this case, fields among the payment records that are not to be disclosed may include real names, detailed locations, and detailed item information. Subsequently, only minimal technical attributes such as payment amount, merchant identifier, and payment time interval are extracted, and one or more commitment values ​​are generated by applying a commitment function, such as a hash function or a Pedersen commitment method, along with a random number. (Additional) In one embodiment, the payment provider may separately generate an amount commitment, a merchant commitment, and a time interval commitment for a single payment, thereby implementing a structure in which only the necessary commitments are selectively used in different types of zero-knowledge circuits.

[0177] In step S920, zero-knowledge circuit selection and proof input configuration are performed. The entity requesting the proof may select different zero-knowledge circuits depending on the attribute to be proven. For example, circuits proving that a payment was made at a specific merchant, proving that a payment exceeding a certain amount was made, or proving that monthly subscription fees were successfully paid for a specific period may be defined. Depending on the selected circuit, the original field of the payment record and the commitment value generated in step S910 are mapped by distinguishing between private and public inputs, and the values ​​to be disclosed and those to be kept private during proof verification are clearly demarcated.

[0178] In one embodiment, the zero-knowledge circuit can be implemented as various verification systems, such as zkSNARK, zkSTARK, and Bulletproof-based circuits, and each system is selected considering circuit complexity and verification costs.

[0179] In step S930, a zero-knowledge payment proof is generated. The user terminal or the security module acting on behalf of the user performs a zero-knowledge proof generation algorithm using the original data of the payment record and the random number used to generate the commitment as private inputs, and the commitment value and circuit identifier as public inputs. In this process, the actual payment amount or wallet address is not directly included in the proof result, and only the commitment and proof value are output; thus, the proof generation process itself is carried out secretly in a local environment.

[0180] In one embodiment, considering the computational performance of the user terminal, a portion of the proof generation can be delegated to an off-chain prober service, and communication with the prober service can be implemented by using encrypted circuit inputs and temporary keys instead of original data to reduce the possibility of data leakage.

[0181] In step S940, a payment proof verification request transaction is transmitted. The user terminal transmits a verification request transaction to the blockchain network that includes the zero-knowledge proof generated in step S930 and corresponding public input values, such as a commitment, circuit identifier, and, if necessary, some limited summary information. The destination of this transaction is a smart contract containing payment proof verification logic, and the transaction may include an existing paymentId or an encrypted paymentId to identify which payment record the proof is intended for.

[0182] In one embodiment, the verification request transaction may include a tag indicating the purpose of use of the proof, such as an identifier like "for credit rating" or "for subscription credentials," to generate a summary representation optimized for that purpose when configuring NFT metadata thereafter.

[0183] In step S950, zero-knowledge proof verification and the issuance of an anonymous payment identifier take place. The payment proof verification smart contract verifies the validity of the zero-knowledge proof included in the transaction using a pre-registered verification key. The verification algorithm uses public input values, such as the commitment and circuit identifier, to determine whether the submitted proof was correctly generated for the corresponding circuit. If verification is successful, the verification smart contract generates a new anonymous payment identifier and stores it on-chain by mapping this anonymous payment identifier to the commitment value and the paymentId of the target payment record. Here, the anonymous payment identifier can be a hash value, a random number-based identifier, or a sequential identifier, and is generated in a form from which the userAddress or merchantAddress cannot be directly inferred.

[0184] In one embodiment, the verification smart contract can prevent the excessive issuance of duplicate proofs for the same payment by reusing the existing identifier without assigning a new anonymous payment identifier when a duplicate proof is submitted for the same combination of commitment and circuit identifier.

[0185] In step S960, privacy-enhanced NFT metadata configuration is performed. The payment receipt smart contract or a separate proof NFT smart contract configures NFT metadata containing information regarding the anonymous payment identifier and commitment, zero-knowledge circuit identifier, and proof type. This metadata may utilize privacy-conscious field configurations such as anonPaymentId, summary, statusSnapshot, and historyRef instead of, for example, tokenId and linkedPaymentId. The summary field records a summary phrase that does not contain sensitive numbers or addresses, such as "Payment completed at a designated merchant" or "Payment exceeding a specific amount has been made," while the statusSnapshot field reflects the payment status and proof verification results. The historyRef field contains reference values ​​to encrypted detailed data in on-chain event logs or off-chain storage, allowing authorized validators to view the details if necessary.

[0186] In step S970, the issuance of a zero-knowledge-based proof of payment NFT is performed. The proof NFT smart contract issues a new NFT using the metadata configured in step S960 and sets the owner of the NFT to the wallet address of the user who requested the proof of payment. The issued NFT functions as a token on-chain representing the result of the proof of payment, and a third party can trust that the payment satisfies specific conditions by presenting only the NFT. However, since the NFT metadata does not directly include the actual payment amount or the user's real name information, detailed personal information cannot be known by querying the NFT alone.

[0187] In some embodiments, when issuing an NFT, a restriction may be added to ensure that only NFTs based on valid proofs are issued through integration with a zero-knowledge proof verification smart contract, and the issuance of NFTs for invalid or expired proofs may be refused.

[0188] In step S980, verification key sharing and third-party verification are performed. The user may grant a certain scope of verification authority to third parties, such as banks, insurers, employers, and regulatory bodies, as needed. To this end, the user shares a viewing key or decryption key via an off-chain channel to access the encrypted detailed data pointed to by the historyRef contained in the NFT. The third party can combine the shared key with NFT metadata, anonymous payment identifiers, and commitment information stored on-chain to verify whether the payment meets specific criteria and whether the submitted zero-knowledge proof is consistent with the actual payment record. Even during this process, the validator is restricted to viewing only the minimum necessary information, so the user's entire payment history and information regarding other payment transactions remain protected.

[0189] In one embodiment, the third-party verification process can be automated by a separate audit smart contract, and the audit results can be summarized again in the form of another zero-knowledge proof to extend to a structure for issuing a secondary proof NFT.

[0190] As such, according to the zero-knowledge-based payment proof NFT generation method of FIG. 9, unlike existing on-chain payment systems where payment records and receipts are exposed as they are, it is possible to selectively prove only the payment facts and payment conditions while cryptographically guaranteeing the association between the payment records, proof, and NFT. As a result, users can provide reliable payment proofs to various online services and financial institutions while protecting their privacy, and service providers can perform the necessary level of verification and regulatory compliance without collecting raw payment data.

[0192] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

[0193] Although the embodiments have been described above with reference to limited examples and drawings, those skilled in the art can make various modifications and variations from the description above. For example, suitable results can be achieved even if the described techniques are performed in a different order than described, and / or the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

[0194] Therefore, other implementations, other embodiments, and equivalents to the claims also fall within the scope of the claims set forth below. Explanation of the symbols

[0195] 10: Wallet-based on-chain payment system using time codes 100: User terminal 110: Time code recognition module 120: Wallet application 121: Time code decoding module 122: Digital Signature Verification Module 123: Random Number and Validity Verification Module 124: User wallet address management module 125: Payment transaction creation module 126: Blockchain Interface Module 127: User Interface Module 130: Communication module 200: Payment request providing device 210: Merchant Information Management Module 220: Payment Request Generation Module 230: Digital signature module 240: Visual code display module 250 : Merchant Registration Management Interface 300 : Blockchain Network 310: Payment Smart Contract 311: Payment Request Validation Module 312: Random Number Reuse Verification Module 313: Payment Status Management Module 314: Payment Record Storage Module 315: Refund Processing Module 316: Dispute Resolution Module 317: NFT Issuance Trigger Module 320: Merchant Registration Smart Contract 330: Payment Receipt Smart Contract

Claims

Claim 1 A wallet-based on-chain payment method using a time code comprises: a payment request providing device generating payment request information including recipient identification information for identifying a payment counterparty and information regarding payment, and encoding and displaying the payment request information in a time code; a user terminal recognizing the time code and obtaining the payment request information from the time code; the user terminal generating a payment transaction including the payment request information for an on-chain payment between a user wallet address managed by the user terminal and a recipient wallet address determined based on the recipient identification information included in the payment request information, based on the payment request information, and transmitting it to a blockchain network; and a payment smart contract executed on the blockchain network receiving the payment transaction and performing a transfer of assets from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction. The above payment smart contract includes the step of recording on-chain payment information corresponding to the payment transaction on a blockchain, and the step of encoding and displaying the payment request information in a time code includes the step of the payment request providing device generating signed payment request information by performing an electronic signature on the payment request information including the recipient identification information and payment information using a previously registered secret key; and the step of encoding and displaying the signed payment request information in a time code, and the step of the user terminal recognizing the time code and obtaining the payment request information from the time code includes the step of the user terminal restoring the signed payment request information from the time code.A wallet-based on-chain payment method using a visual code, comprising the step of the user terminal verifying the electronic signature included in the signed payment request information using a public key corresponding to the payment request providing device, and using the payment request information for generating a payment transaction only when its validity is confirmed. Claim 2 delete Claim 3 delete Claim 4 A wallet-based on-chain payment method using a time code according to claim 1, wherein the payment request information further includes a random number value for determining whether the payment request is reused and validity period information indicating the validity period of the payment request, and the step of the payment smart contract performing the transfer of an asset from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction comprises: the payment smart contract extracting the random number value and recipient identification information from the payment request information included in the payment transaction and determining the recipient wallet address based on the recipient identification information; the payment smart contract querying reuse status management information corresponding to the combination of the recipient wallet address and the random number value and allowing the transfer of the asset only if the random number value has not been previously used; and the payment smart contract comparing the validity period information included in the payment request information with the current block time and allowing the transfer of the asset only if it is within the validity period. Claim 5 A wallet-based on-chain payment method using a time code according to claim 1, wherein the blockchain network further includes a merchant registration smart contract that corresponds a recipient wallet address with recipient business information, and the step of performing an asset transfer from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction comprises: a step in which the payment smart contract queries the merchant registration smart contract for the recipient wallet address included in the payment transaction to verify whether the recipient wallet address is a pre-registered merchant wallet address; and a step of performing an asset transfer from the user wallet address to the recipient wallet address only if the verification result indicates that the recipient wallet address is a registered merchant wallet address. Claim 6 A wallet-based on-chain payment method using a time code according to claim 1, wherein the step of the payment smart contract recording on-chain payment information corresponding to the payment transaction on a blockchain comprises: the payment smart contract generating a payment identifier uniquely assigned to each payment transaction and storing a payment record on-chain including the payment identifier, the user wallet address, the recipient wallet address, the payment amount, and the payment time; and the step of issuing a non-fungible token (NFT) representing a payment receipt corresponding to the payment identifier and recording the payment information included in the payment record in the metadata of the non-fungible token so that the non-fungible token functions as an on-chain receipt for the payment. Claim 7 In claim 6, the on-chain payment information includes a payment status field indicating a payment status, and the payment status field may have at least one status value among a request status, a payment completed status, a refund completed status, a cancellation completed status, and a dispute status; the step of the payment smart contract recording on-chain payment information corresponding to the payment transaction on the blockchain comprises: the payment smart contract setting the payment status field to a payment completed status upon completion of processing of the payment transaction; when a refund request transaction for the payment is received through the blockchain network, performing an asset refund to the user wallet address and updating the payment status field to a refund completed status; and when a dispute raising transaction for the payment is received by a merchant or user, updating the payment status field to a dispute status and updating whether a dispute has occurred and the time of occurrence of the dispute in the metadata of the non-fungible token corresponding to the payment identifier, a wallet-based on-chain payment method using a time code. Claim 8 A wallet-based on-chain payment system using a time code, comprising: a payment request providing device configured to generate payment request information including recipient identification information for identifying a payment counterparty and information regarding payment, and to encode and display said payment request information in a time code; and a user terminal configured to recognize said time code to obtain said payment request information from said time code, and to generate and transmit to a blockchain network a payment transaction including said payment request information for an on-chain payment between a user wallet address managed by a user terminal based on said payment request information and a recipient wallet address determined based on recipient identification information included in said payment request information.A wallet-based on-chain payment using a time code, comprising a blockchain network having a blockchain address space in which the user wallet address and the recipient wallet address are defined as valid addresses, and including a payment smart contract executed on the blockchain network; wherein the payment smart contract is configured to receive the payment transaction, perform a transfer of assets from the user wallet address to the recipient wallet address based on the payment request information included in the payment transaction, and record on-chain payment information corresponding to the payment transaction on the blockchain; wherein the payment request providing device is configured to generate signed payment request information by performing an electronic signature on the payment request information including the recipient identification information and information regarding the payment using a pre-registered secret key, and to display the signed payment request information by encoding it with the time code; wherein the user terminal is configured to recognize the time code and restore the signed payment request information from the time code, and is configured to obtain the payment request information from the signed payment request information and use it for the creation of the payment transaction only when the validity is confirmed by verifying the electronic signature included in the signed payment request information using a public key corresponding to the payment request providing device. System.; Claim 9 delete Claim 10 delete Claim 11 A wallet-based on-chain payment system using a time code, wherein, in claim 8, the payment request information further includes a random number value for determining whether the payment request is reused and validity period information indicating the validity period of the payment request, and the payment smart contract extracts the random number value and the recipient identification information from the payment request information included in the payment transaction, determines the recipient wallet address based on the recipient identification information, queries reuse status management information corresponding to the combination of the recipient wallet address and the random number value to allow the transfer of the asset only if the random number value has not been previously used, and is configured to allow the transfer of the asset only if the validity period information included in the payment request information is compared with the current block time and is within the validity period. Claim 12 A wallet-based on-chain payment system using a time code, wherein, in claim 8, the blockchain network further includes a merchant registration smart contract that corresponds a recipient wallet address with recipient business information, and the payment smart contract is configured to query the merchant registration smart contract for the recipient wallet address included in the payment transaction to verify whether the recipient wallet address is a pre-registered merchant wallet address, and to allow the transfer of assets from the user wallet address to the recipient wallet address only if the verification result confirms that the recipient wallet address is a registered merchant wallet address. Claim 13 A wallet-based on-chain payment system using a time code according to claim 8, wherein the payment smart contract generates a payment identifier uniquely assigned to each payment transaction, records the on-chain payment information on the blockchain by storing a payment record including the payment identifier, the user wallet address, the recipient wallet address, the payment amount, and the payment time in an on-chain state, issues a non-fungible token (NFT) representing a payment receipt corresponding to the payment identifier, and records the payment information included in the payment record in the metadata of the non-fungible token, thereby configuring the non-fungible token to function as an on-chain receipt for a payment corresponding to the payment transaction.

Images