Payment processing method, apparatus, and related device

Abstract

This application provides a payment processing method, apparatus, and related equipment, applied to a payment service platform. The method includes: receiving a payment message sent by a client, the payment message including transaction data of a buyer user for virtual assets in a metaverse application; obtaining the identity information of the buyer user based on the communication service identifier of the payment message source; generating a real-name token for the buyer user based on the identity information; and sending a transaction request to a smart contract gateway, the transaction request including the buyer user's real-name token and the transaction data, the transaction request being used to execute a virtual asset transaction in the metaverse application.

Description

Technical Field

[0001] This application relates to the field of metaverse technology, and in particular to a payment processing method, apparatus and related equipment. Background Technology

[0002] Metaverse is an immersive digital space that integrates virtual reality, augmented reality, blockchain and other technologies, allowing users to engage in activities such as socializing, entertainment, learning and working.

[0003] Currently, payments in the metaverse are mainly executed by third-party payment applications. After a user clicks to purchase virtual assets in the metaverse, they are redirected to the third-party payment application to complete the payment, and then return to the metaverse. This payment processing method requires stepping out of the metaverse scenario, resulting in a fragmented experience and poor payment convenience. Summary of the Invention

[0004] This application provides a payment processing method, apparatus, and related equipment, which can solve the technical problem in the related technology that the payment processing method needs to break out of the metaverse scenario, resulting in a fragmented experience and poor payment convenience.

[0005] In a first aspect, embodiments of this application provide a payment processing method applied to a payment service platform, the method comprising:

[0006] Receive payment messages sent by the client, the payment messages including: transaction data of the buyer user for virtual assets in the Metaverse application;

[0007] Based on the communication service identifier of the payment message source, obtain the identity information of the buyer user;

[0008] Based on the identity information, a real-name token for the buyer user is generated;

[0009] A transaction request is sent to the smart contract gateway. The transaction request includes the buyer's real-name token and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

[0010] Secondly, embodiments of this application provide a payment processing method applied to a smart contract gateway, the method comprising:

[0011] Receive a transaction request sent by a payment service platform, the transaction request including the buyer's real-name token and the buyer's transaction data for virtual assets in the Metaverse application;

[0012] Based on the buyer's real-name token and the transaction data, a smart contract instance is generated by calling the smart contract template library;

[0013] The smart contract instance is invoked to execute the virtual asset transaction of the metaverse application.

[0014] Thirdly, embodiments of this application provide a payment processing method applied to a client, the method comprising:

[0015] Obtain transaction data of virtual assets held by the buyer user in the Metaverse application;

[0016] The transaction data is encapsulated into a payment message, which is an RCS message, and the RCS message includes structured field data generated based on the transaction data;

[0017] The payment message is sent to the payment service platform, and the payment message is used to request the virtual asset transaction of the metaverse application.

[0018] Fourthly, embodiments of this application provide a payment processing apparatus applied to a payment service platform, the apparatus comprising:

[0019] The first receiving module is used to receive payment messages sent by the client, the payment messages including: transaction data of virtual assets of the buyer user for the Metaverse application;

[0020] The first acquisition module is used to acquire the identity information of the buyer user based on the communication service identifier of the payment message source;

[0021] The first generation module is used to generate the real-name token of the buyer user based on the identity information;

[0022] The first sending module is used to send a transaction request to the smart contract gateway. The transaction request includes the real-name token of the buyer user and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

[0023] Fifthly, embodiments of this application provide a payment processing device applied to a smart contract gateway, the device comprising:

[0024] The second receiving module is used to receive transaction requests sent by the payment service platform. The transaction requests include the real-name token of the buyer user and the transaction data of the buyer user for virtual assets of the Metaverse application.

[0025] The second generation module is used to generate a smart contract instance by calling the smart contract template library based on the real-name token of the buyer user and the transaction data.

[0026] The trigger module is used to invoke the smart contract instance to execute the virtual asset transaction of the metaverse application.

[0027] Sixthly, embodiments of this application provide a payment processing device applied to a client, the device comprising:

[0028] The second acquisition module is used to acquire transaction data of virtual assets of the buyer user for the Metaverse application;

[0029] An encapsulation module is used to encapsulate the transaction data into a payment message, wherein the payment message is an RCS message, and the RCS message includes structured field data generated based on the transaction data;

[0030] The second sending module is used to send the payment message to the payment service platform, and the payment message is used to request the virtual asset transaction of the metaverse application.

[0031] In a seventh aspect, embodiments of this application provide a payment service platform, including: a first processor, a first memory, and a program stored on the first memory and executable on the first processor, wherein when the program is executed by the first processor, it implements the steps of the payment processing method as described in the first aspect.

[0032] Eighthly, embodiments of this application provide a smart contract gateway, including: a second processor, a second memory, and a program stored on the second memory and executable on the second processor, wherein when the program is executed by the second processor, it implements the steps of the payment processing method as described in the second aspect.

[0033] In a ninth aspect, embodiments of this application provide a client, including: a third processor, a third memory, and a program stored in the third memory and executable on the third processor, wherein the program, when executed by the third processor, implements the steps of the payment processing method as described in the third aspect.

[0034] In a tenth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the payment processing method as described in the first aspect, or the payment processing method as described in the second aspect, or the payment processing method as described in the third aspect.

[0035] In one aspect, embodiments of this application provide a computer program product, including computer instructions that, when executed by a processor, implement the steps of the payment processing method as described in the first aspect, or the steps of the payment processing method as described in the second aspect, or the steps of the payment processing method as described in the third aspect.

[0036] In this embodiment, the payment service platform receives a payment message sent by a client. The payment message includes: transaction data of the buyer's virtual assets in the Metaverse application; based on the communication service identifier of the payment message source, it obtains the buyer's identity information; based on the identity information, it generates the buyer's real-name token; and sends a transaction request to a smart contract gateway, the transaction request including the buyer's real-name token and the transaction data. Correspondingly, the smart contract gateway receives the transaction request sent by the payment service platform, the transaction request including the buyer's real-name token and the buyer's virtual assets transaction data in the Metaverse application; based on the buyer's real-name token and the transaction data, it calls a smart contract template library to generate a smart contract instance; and calls the smart contract instance to execute the virtual asset transaction in the Metaverse application. In this way, the payment service platform can interact with the client through the communication service, realizing communication-as-payment without needing to jump to the Metaverse scenario, achieving immersive payment. Furthermore, the payment service platform can send the transaction request to the smart contract gateway, which processes the transaction request to execute the virtual asset transaction in the Metaverse application. This bypasses the traditional payment gateway, achieving a gateway direct connection mechanism, thus enabling faster payment. Furthermore, the identity information of the buyer can be obtained through the communication service identifier of the payment message source. This allows for the binding of the buyer's identity when making a transaction request using a real-name token, thereby improving payment security. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is one of the flowcharts of a payment processing method provided in the embodiments of this application;

[0039] Figure 2 This is a second flowchart of a payment processing method provided in the embodiments of this application;

[0040] Figure 3 This is a sample diagram of the fields in the JSON message;

[0041] Figure 4 This is a diagram illustrating the transfer of asset status;

[0042] Figure 5 This is the third flowchart of a payment processing method provided in the embodiments of this application;

[0043] Figure 6 This is an implementation architecture diagram of a specific example of a payment processing method in an embodiment of this application;

[0044] Figure 7 This is a schematic diagram of the interaction flow of a payment processing method according to a specific example in the embodiments of this application;

[0045] Figure 8 This is one of the structural schematic diagrams of a payment processing device provided in the embodiments of this application;

[0046] Figure 9 This is a second schematic diagram of the structure of a payment processing device provided in an embodiment of this application;

[0047] Figure 10 This is the third schematic diagram of a payment processing device provided in the embodiments of this application;

[0048] Figure 11 This is a schematic diagram of the structure of a payment service platform provided in an embodiment of this application;

[0049] Figure 12 This is a schematic diagram of the structure of a smart contract gateway provided in an embodiment of this application;

[0050] Figure 13 This is a schematic diagram of the structure of a client provided in an embodiment of this application. Detailed Implementation

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

[0052] Among related technologies, Metaverse's payment technology solution and its technical shortcomings are as follows:

[0053] 1. The payment is executed by a third-party payment application. After the user clicks to purchase within the metaverse, the payment is completed by being redirected to the third-party payment application before returning to the metaverse. This redirection to the third-party payment application to complete the payment takes an average of 2.3 seconds (S).

[0054] 2. Payments via blockchain wallets typically involve the user accessing the on-chain wallet → signing and uploading the signature to the blockchain → waiting for block confirmation (the average delay on public blockchains is over 15 seconds). The technical drawbacks of this payment method are high gas fees, slow speed, and significant compliance risks. It's important to note that Gas is a unit of computational resources used in a blockchain network to pay for transaction execution costs; it represents the unit of computational workload for blockchain operations (such as transfers and smart contract execution).

[0055] 3. The operator's native communication capabilities are not integrated with the digital currency system.

[0056] 4. The metaverse scenario lacks identity binding and real-time monitoring mechanisms.

[0057] It is known that the payment processing method in the metaverse suffers from technical problems such as requiring payment to exit the current scenario, resulting in a fragmented user experience; slow blockchain confirmation and high transaction fees; difficulties in compliance and regulatory penetration; and ease of identity forgery and transaction repudiation. Therefore, this application proposes a new payment processing method to solve the above-mentioned technical problems. It enables payment through communication, without leaving the metaverse scenario, achieving immersive payment; and utilizes the two-tier operating system of the digital currency system to achieve second-level settlement with zero transaction fees; it can achieve real-time on-chain evidence storage through embedded supervision; and it achieves buyer user identity binding when making transaction requests by signing identity information through communication service identifiers, real-name tokens, and user identification modules, thereby improving payment security.

[0058] It should be noted that the payment processing method in this application embodiment is applied to a payment processing system, which may include a client, a payment service platform, a smart contract gateway, a digital currency system, a virtual asset system, and a regulatory system. It involves technical fields such as metaverse, mobile payment, operator communication, digital currency, and smart contracts, and is particularly suitable for virtual asset transactions and payments within a metaverse scenario that do not require leaving the metaverse application, enabling immersive, real-time compliant, and regulated payments. For example, it can help users purchase NFT digital collectibles, virtual concert tickets, and game equipment on metaverse platforms and 5G messaging platforms.

[0059] See Figure 1 , Figure 1 This is one of the flowcharts of a payment processing method provided in the embodiments of this application, applied to a payment service platform, such as... Figure 1 As shown, the method includes the following steps:

[0060] Step 101: Receive a payment message sent by the client, the payment message including: transaction data of the buyer user for virtual assets in the Metaverse application;

[0061] Step 102: Obtain the identity information of the buyer user based on the communication service identifier of the payment message source;

[0062] Step 103: Based on the identity information, generate the real-name token for the buyer user;

[0063] Step 104: Send a transaction request to the smart contract gateway. The transaction request includes the buyer user's real-name token and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

[0064] The client-side applications include metaverse applications such as games and virtual social platforms.

[0065] In some embodiments, the payment message is a Rich Communication Service (RCS) message, which includes structured field data generated based on the transaction data.

[0066] The transaction request is specifically used by the smart contract gateway to generate a smart contract instance based on the buyer's real-name token and the transaction data. This smart contract instance is used to trigger the virtual asset system of the digital currency system and the metaverse application to execute the virtual asset transaction indicated by the payment message. The contract parameters in the smart contract instance are generated based on the buyer's real-name token and the structured field data.

[0067] The client also deploys a Rich Communication Services (RCS) Software Development Kit (SDK). The RCS SDK is a communication technology based on the IP Multimedia Subsystem (IMS) architecture, designed to upgrade traditional Short Message Service (SMS) / Multimedia Messaging Service (MMS) functionality, providing a richer messaging experience. The RCS SDK is the development tool for implementing this technology, enabling developers to quickly integrate RCS functionality into their applications.

[0068] The RCS SDK can be deeply integrated into metaverse applications (such as games and virtual social platforms). Its core function is to encapsulate and parse RCS messages based on the GSMA UP2.4 standard. When a user initiates a payment, the SDK packages the transaction details (such as product ID, amount, and payee) into structured JSON instructions (such as {"msgType": "Payment", "amount": "100",...}), obtains the payment message, and sends it directly to the payment service platform under the operator's network through the underlying interface of the mobile operating system. Correspondingly, in step 101, the payment service platform can receive the payment message sent by the client, thus completely bypassing third-party payment applications and achieving an "immersive, seamless" payment experience.

[0069] The payment service platform can be an operator's 5G messaging subsystem, which may include a Messaging as a Platform (MaaP). The MaaP platform is the core platform for RCS services provided by the operator. It is responsible for receiving, routing, and processing RCS messages from a massive number of clients, where RCS messages are payment instructions sent by the clients. In this embodiment, it specifically identifies payment-related messages and forwards them to the corresponding processing modules.

[0070] In step 102, the payment service platform may also include a three-factor authentication interface, which can connect to the operator's massive backend database. Its function is to verify the user's real-name identity information in real time based on the communication service identifier of the payment message source, such as name, ID number, and mobile phone number, at the initial stage of the payment process.

[0071] Subsequently, in step 103, a short-term valid identity token can be generated based on the buyer's user identity information. This token can be used throughout the entire transaction chain, providing a reliable source of identity evidence for compliance and supervision.

[0072] In some embodiments, the client further deploys a user identification module, and the payment message further includes: signature information of the transaction data, wherein the signature information is obtained by the user identification module signing the transaction data, and step 104 specifically includes:

[0073] If the signature information is verified, the transaction request is sent to the smart contract gateway.

[0074] This Subscriber Identity Module (SIM) is a SIM card security module, specifically referring to a Super SIM card that meets the CC EAL6+ security level. Its built-in Secure Element (SE) supports the Chinese national cryptographic algorithm SM2. The core function of this module is to receive transaction data digests from the RCS SDK and digitally sign them in a hardware-isolated environment to obtain the transaction data's signature information. Because the private key never leaves the card, it provides the highest level of tamper-proof and non-repudiation protection.

[0075] In some embodiments, the client's processing flow is as follows:

[0076] The metaverse application deployed on the client calls the RCS SDK interface to initiate a payment request;

[0077] The RCS SDK sends the transaction data to the SE module of the Super SIM card to request a signature;

[0078] After the SIM card security module completes the signing, it returns the signing information to the RCS SDK.

[0079] The RCS SDK encapsulates the signature information and transaction data together into the final RCS message, which is then sent to the operator's 5G messaging subsystem, i.e., the payment service platform.

[0080] Correspondingly, the payment service platform may also include a signature verification module, which holds the operator's root certificate public key required to verify digital signatures. Its function is to verify the authenticity and integrity of the SM2 signature from the client, ensuring that the transaction instructions have not been tampered with during transmission and that they were indeed issued by the SIM card corresponding to the real-name number.

[0081] In some embodiments, the processing flow of the payment service platform is as follows:

[0082] Receive RCS messages from the client;

[0083] Call the internal three-factor authentication interface to obtain the communication service identifier of the payment message source, namely the identity information bound to the buyer's mobile phone number, and generate a token based on the identity information;

[0084] The internal signature verification module is invoked to verify the signature information.

[0085] After the signature verification is successful, the MaaP platform packages the token and transaction data into a transaction request and sends it to the smart contract gateway through a standard application programming interface (API) (such as RESTful).

[0086] In some embodiments, after step 104, the method further includes:

[0087] The first key information from the transaction data is sent to the regulatory system for storage; wherein...

[0088] The first key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

[0089] See Figure 2 , Figure 2 This is a second flowchart of a payment processing method provided in this application embodiment, applied to a smart contract gateway, such as... Figure 2 As shown, the method includes the following steps:

[0090] Step 201: Receive a transaction request sent by the payment service platform. The transaction request includes the buyer's real-name token and the buyer's transaction data for virtual assets in the Metaverse application.

[0091] Step 202: Based on the buyer's real-name token and the transaction data, call the smart contract template library to generate a smart contract instance;

[0092] Step 203: Invoke the smart contract instance to execute the virtual asset transaction of the metaverse application.

[0093] In some embodiments, the smart contract gateway may include a Hashed Timelock Contract (HTLC) template library, which is a repository of pre-built configurable smart contract templates. The core template is HTLC. After receiving a transaction request, the smart contract gateway quickly instantiates a contract based on the template, generating a unique contract address and locking conditions, such as a hash lock H and a time lock T.

[0094] In some embodiments, the smart contract gateway may also include a compliance verification engine, which can perform a preliminary compliance check on transaction requests before contract deployment, such as amount limits and blacklist verification. Its function is to ensure that transaction requests to be sent to the digital currency system basically comply with risk control rules.

[0095] In some embodiments, step 202 specifically includes:

[0096] The smart contract instance is invoked to generate contract deployment instructions and asset lock requests;

[0097] The contract deployment instruction and the asset lock request are sent to the digital currency system. The contract deployment instruction is used by the digital currency system to deploy the transaction contract address, and the asset lock request is used by the digital currency system to lock the buyer's digital assets according to the transaction contract address.

[0098] The processing flow of the smart contract gateway is as follows:

[0099] Receive transaction requests from the operator's 5G messaging subsystem;

[0100] The compliance verification engine first conducts a preliminary review of the transaction request;

[0101] After the initial review is passed, a customized smart contract instance is generated by calling the HTLC template library based on the buyer's real-name token and transaction data.

[0102] The smart contract gateway can invoke smart contract instances to generate contract deployment instructions and asset lock requests, and send the contract deployment instructions and fund lock requests to the digital currency system through a specified standard interface (such as based on the ISO 20022 financial message standard).

[0103] Digital currency systems can be central bank digital currency systems, such as the digital yuan (e-CNY) clearing network. The e-CNY clearing network is the core underlying infrastructure of the digital yuan. Its function is to execute the final transfer of ownership and clearing of the legal digital currency. Upon receiving a request from a smart contract gateway, it locks the e-CNY funds specified by the buyer in the newly generated transaction contract address within its Layer 2 network and generates a freeze certificate. This solves the technical problems of slow blockchain confirmation and high transaction fees, enabling second-level clearing and zero transaction fees by leveraging the central bank's two-tier operating system.

[0104] In some embodiments, after step 203, the method further includes:

[0105] The second key information instructing the locking of digital assets in the metaverse application will be sent to the monitoring system for storage; wherein...

[0106] The second key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

[0107] In some embodiments, the processing flow of a digital currency system is as follows:

[0108] Receive standardized requests from the smart contract gateway, which may include contract deployment instructions and asset locking requests;

[0109] Perform the fund locking operation and return a successful locking status receipt to the smart contract gateway;

[0110] The freeze event will be recorded as evidence and sent to the regulatory consortium blockchain for filing.

[0111] In some embodiments, step 203 specifically includes:

[0112] The smart contract instance is invoked to lock the digital assets of the buyer in the digital currency system and the virtual assets of the seller in the virtual asset system of the metaverse application.

[0113] If the buyer's digital assets and the seller's virtual assets are locked, and the asset withdrawal certificate submitted by the seller is verified, the transfer of the locked buyer's digital assets to the seller and the transfer of the locked seller's virtual assets to the buyer are triggered.

[0114] The virtual asset system can be a virtual asset consortium blockchain, which may include non-fungible tokens (NFTs) / virtual asset contracts. These contracts manage on-chain contracts for various virtual assets within the metaverse, typically using multi-asset standards such as ERC-1155, and can support extended ERC-1155 (which is a type of token), virtual assets, game items, and other asset templates. Its function is to represent ownership of virtual assets. Ownership transfer is executed only upon receiving final proof of settlement from the digital yuan system, such as transferring an NFT from the seller to the buyer. The digital yuan system may include smart contract gateways and digital currency systems.

[0115] The virtual asset system may also include regulatory nodes, which are special nodes deployed on the virtual asset consortium blockchain. These regulatory nodes can approve new template hashes for online deployment. They are usually run by regulatory agencies and their function is to monitor all asset transfer operations on the chain in real time to ensure that the corresponding underlying payments have been completed and are compliant.

[0116] In some embodiments, the processing flow of the virtual asset system is as follows:

[0117] After receiving a successful lock confirmation from the digital currency system, the smart contract gateway will send a "ready to settle" signal to the virtual asset consortium blockchain; this signal indicates the transfer of digital assets and virtual assets.

[0118] After receiving the virtual assets on the client, the buyer can trigger the final settlement. The asset contract in the virtual asset system can query the fund lock status from the digital currency system.

[0119] Once confirmed, the asset contract will automatically transfer ownership.

[0120] The regulatory node captures the asset transfer transaction in real time and synchronizes the second key information (such as transaction hash, asset ID, anonymous addresses of the buyer and seller, and the real-name token of the buyer's user) across the chain to the regulatory system, namely the regulatory consortium chain, to complete the closed-loop supervision on the asset side.

[0121] In some embodiments, the regulatory system, or regulatory consortium blockchain, may include nodes such as the central bank and the China Banking Regulatory Commission. This regulatory consortium blockchain is a consortium blockchain jointly maintained by multiple regulatory agencies. Its core function is to provide a global and tamper-proof audit trail for the entire metaverse payment ecosystem. It does not directly process transactions, but rather acts like a "general ledger," recording key events (such as payment instructions, e-CNY locking, and asset transfer) throughout the entire process from payment to asset transfer.

[0122] The regulatory system, i.e., the regulatory consortium blockchain, can also include a RESTful audit interface, which can provide authorized regulators with convenient data query and evidence collection interfaces. Regulatory agencies do not need to delve into every subsystem to quickly trace the complete lifecycle of any transaction and assess systemic risks through this interface. RESTful can be a common interface design style nowadays.

[0123] In some embodiments, the processing flow of the monitoring system is as follows:

[0124] Receive e-CNY funds locked and deposited from the digital yuan system;

[0125] Receive synchronized asset transfer evidence from regulatory nodes of the virtual asset consortium blockchain;

[0126] The operator's 5G messaging subsystem will also send the core information of the transaction, namely the first key information (such as real-name token, transaction hash, transaction amount, time, etc.), to the regulatory consortium blockchain for evidence storage.

[0127] All these scattered pieces of information can be interconnected on the regulatory consortium blockchain through key fields such as transaction hashes and real-name tokens, ultimately forming a complete, transparent, and traceable audit chain. Authorized personnel can query and audit through a RESTful audit interface.

[0128] The above describes in detail the specific process of the payment processing method according to the embodiments of this application. The following describes in detail the information processing and interaction process of each part.

[0129] The operator's 5G messaging subsystem can use the GSMA RCS UP2.4 protocol, IMS bearer, and TLS+operator certificate encryption. The message format can be JSON encapsulation; an example of JSON message fields is shown below. Figure 3 As shown.

[0130] The interaction process between the client and the operator's 5G messaging subsystem can be as follows: the client sends a payment request via HTTPS POST → MaaP platform, and the MaaP platform returns a message receipt (such as a delivery / display receipt).

[0131] The interaction process between the MaaP platform and the three-factor authentication interface and the SIM card security module is as follows:

[0132] Interactive Role (who): SE in the MaaP platform and SIM card security module, MaaP platform calls the three-factor real-name interface.

[0133] Interactive events (What): Real-name verification and SM2 hardware signature.

[0134] Interaction time (when): Before each transaction is initiated.

[0135] Interaction location (where): Any client that supports SuperSIM cards.

[0136] Interaction steps (How):

[0137] The MaaP platform calls the operator's KYC interface (i.e., the three-factor real-name authentication interface) and returns a compliance token.

[0138] The client generates a transaction data digest → the SE private key signs it → the RCS message carries the signature information;

[0139] The MaaP platform uses root certificates for signature verification to prevent tampering.

[0140] In some embodiments, if the client experiences a brief network outage, the RCS message can be cached on the MaaP platform and resent after the network is restored, and the SIM card offline signature remains valid.

[0141] The smart contract gateway can generate smart contract instances, which can include multiple contract parameters. Examples of these fields are shown in Table 1 below.

[0142] Table 1 Contract Parameter Table for Smart Contract Instances

[0143]

[0144] The sender / receiver field can adopt the e-CNY wallet address standard: 20 bytes, prefixed with 0x, conforming to the SECP256K1 public key derivation rule. It can be bound to a mobile phone number through operator KYC to ensure "number is account".

[0145] The minimum precision of the amount field is 0.01 CNY (i.e., 1 cent), and the maximum is 10^12 cents (i.e., 10 billion CNY). It is automatically converted to the smallest unit on the chain by the smart contract gateway (the smallest unit of e-CNY is "cent").

[0146] The generation rules for the hashLock field are as follows: Before the asset is put on the blockchain, the seller user randomly generates a 32-byte secret, which is calculated as H = SHA-256(secret). It can be stored publicly, and anyone can verify it but cannot reverse-engineer the secret.

[0147] The `timeLock` field is a relative time in seconds, starting from the timestamp of the block where the contract lock transaction is packaged and uploaded to the blockchain.

[0148] Recommended values ​​could be: Virtual assets / high-value NFTs: 600–1800 s; Game items / low-value assets: 300–600 s.

[0149] The assetId field can be in a uniform format: {chain}-{contractAddress}-{tokenId}, for example: ETH-0x1234...-2025-001. Its length can be ≤64 bytes, UTF-8 encoded, and it supports ERC-721 / ERC-1155 / domestic consortium blockchain assets.

[0150] The status field is an internal state machine whose state changes as the transaction progresses. Examples of its states are shown in Table 2 below.

[0151] Table 2 Internal State Machine Table

[0152]

[0153] The `complianceToken` field (i.e., the verification token) can be a JSON Web Token (JWT) generated by the MaaP platform, transmitting information based on JSON. This JWT contains the buyer's mobile phone number, verification status, and Anti-Money Laundering (AML) score. JWT is an open standard based on JSON used for securely transmitting information between parties. The contract can verify the token signature and validity period (≤5 minutes) before locking funds.

[0154] The regTxHash field is used to record the hash of the transaction corresponding to the regulatory consortium blockchain, which facilitates auditing and tracing.

[0155] In some embodiments, after step 203, the method further includes:

[0156] During the execution of virtual asset transactions, the contract parameters in the smart contract instance are updated based on the execution status of the digital currency system and the virtual asset system; wherein,

[0157] The contract parameters are generated based on the buyer user's real-name token and structured field data, which in turn are generated based on the transaction data.

[0158] The payment message is an RCS message, which includes structured field data generated based on the transaction data. The contract parameters are generated based on the buyer's real-name token and the structured field data.

[0159] Table 3 below shows an example of how contract parameters are updated during the execution of a virtual asset transaction instructed by a payment message.

[0160] Table 3 Contract Parameter Update Table

[0161] stage sender receiver amount hashLock timeLock assetId status create Fill in Fill in Fill in Fill in Fill in Fill in 0 locking constant constant constant constant constant constant 1 Unlock constant constant →0 verify verify constant 2 Refund constant constant →0 constant trigger constant 3 Cancel constant constant →0 constant neglect constant 4

[0162] The verification rules can vary depending on the stage of the transaction.

[0163] During the creation phase, the validation rules can be:

[0164] sender ≠ receiver;

[0165] amount ∈ [1, 10^12];

[0166] timeLock ∈ [300, 1800];

[0167] The complianceToken signature is valid.

[0168] During the locking phase, the verification rules can be:

[0169] Account balance ≥ amount;

[0170] status = 0 → 1.

[0171] During the unlocking phase, the verification rules can be:

[0172] sha256(secret) == hashLock;

[0173] block.timestamp < (lockTime + timeLock);

[0174] status = 1 → 2.

[0175] During the refund process, the verification rules can be:

[0176] block.timestamp ≥ (lockTime + timeLock);

[0177] status = 1 → 3.

[0178] During the cancellation phase, the verification rules can be:

[0179] Only multi-signature addresses of regulatory consortium blockchains can be used;

[0180] status = 1 → 4.

[0181] Contract parameters can be stored in binary storage format, as shown in Table 4 below.

[0182] Table 4. Storage table for contract parameters

[0183]

[0184] In some embodiments, the smart contract instance is a hash time lock contract, and before triggering the transfer of the locked digital assets of the buyer user to the seller user, and triggering the transfer of the locked virtual assets of the seller user to the buyer user, the method further includes:

[0185] Obtain the preimage of the hash lock submitted by the seller user, where the preimage is the asset withdrawal certificate;

[0186] Perform a hash operation on the preimage to obtain the hash value of the preimage;

[0187] If the hash value of the preimage is equal to the hash value of the hash lock in the hash time lock contract, the asset withdrawal certificate submitted by the seller user is deemed to have passed verification.

[0188] It should be noted that if the preimage verification of the hash lock submitted by the seller fails or times out, the locked funds can be returned to the buyer.

[0189] During the interaction between the smart contract gateway and digital currency systems and virtual asset systems, the state transitions are as follows: Figure 4 As shown, the interaction process can be as follows: the seller submits the preimage R → on-chain verification of whether Hash(R) is equal to the hash lock H → if equal, the locked funds are released → the NFT is transferred from the seller user to the buyer user; if the time lock T is not submitted within the timeout period → the funds are automatically returned to the buyer user.

[0190] Among them, the smart contract gateway can call the central bank digital currency system API → commercial banks to achieve the locking of funds on the second-layer chain.

[0191] Regulating the interaction between the consortium blockchain and other modules.

[0192] Interactive roles (Who): Alliance nodes such as the central bank and the China Banking Regulatory Commission.

[0193] Interactive events (What): Real-time synchronization of RCS logs, contract events, and asset transfers.

[0194] Interaction steps (How): RESTful audit interface + Practical Byzantine Fault Tolerance (PBFT) consensus, supporting millisecond-level risk blocking.

[0195] Figure 5 This is a third flowchart of a payment processing method provided in this application embodiment, applied to a client. The payment processing method includes the following steps:

[0196] Step 501: Obtain transaction data of the buyer's virtual assets for the Metaverse application;

[0197] Step 502: Encapsulate the transaction data into a payment message, the payment message being an RCS message, the RCS message including structured field data generated based on the transaction data;

[0198] Step 503: Send the payment message to the payment service platform. The payment message is used to request the virtual asset transaction of the Metaverse application.

[0199] Optionally, the client also deploys a user identification module, and before step 502, the method further includes:

[0200] The user identification module signs the transaction data to obtain the signature information of the transaction data;

[0201] Step 502 specifically includes:

[0202] The signature information and the transaction data are encapsulated into a payment message.

[0203] Figure 6 This is an implementation architecture diagram of a payment processing method according to a specific example in the embodiments of this application, such as... Figure 6 As shown, its implementation can include five functional terminals: the metaverse side, the operator side, the digital RMB system side, the virtual asset side, and the regulatory consortium blockchain side. The metaverse side can include a client deployed with metaverse applications. The operator side can include a 5G messaging MaaP platform, a three-factor authentication interface, and a signature verification module that verifies signatures via SIM cards. The digital RMB system side can include a smart contract gateway and a central bank digital currency system. The virtual asset side can include a virtual asset system, which can be a virtual asset consortium blockchain. The regulatory consortium blockchain side can include a regulatory consortium blockchain. Each functional terminal can interact internally, and the functional terminals can interact with each other to implement the payment processing method of this application embodiment.

[0204] Figure 7 This is a schematic diagram of the interaction flow of a payment processing method according to a specific example in an embodiment of this application, such as... Figure 7 As shown, it includes the following steps:

[0205] 1. The user clicks "Buy NFT";

[0206] 2. Client → MaaP Platform: Submits RCS message; where, Figure 7 The Metaverse client is a client that has deployed the Metaverse application;

[0207] 3. MaaP platform → KYC: Three-factor authentication; the three factors include name, mobile phone number and ID card number. KYC can be a three-factor authentication interface, and it is a three-factor real-name authentication interface.

[0208] 4. MaaP Platform → SIM Card: Request Signature → Return Signature Information; where, Figure 7 The SIM card can be a signature verification module, which can return signature information and compare it with the signature information in the RCS message. If the comparison matches, the signature verification is successful.

[0209] 5. MaaP Platform → Smart Contract Gateway: Sends transaction requests, which may include messages, tokens, and signatures; where, Figure 7 The smart contract gateway is also known as the contract gateway.

[0210] 6. Smart Contract Gateway → Central Bank Digital Currency System: Its purpose is to deploy HTLC and lock up digital assets;

[0211] 7. Central Bank Digital Currency System → Smart Contract Gateway: Returns the HTLC address where the digital asset is locked;

[0212] 8. Smart Contract Gateway → Virtual Asset System: Locking NFTs; where, Figure 7 The virtual asset chain is a virtual asset system;

[0213] 9. Seller User → Smart Contract Gateway: Submit Preimage R;

[0214] 10. Central Bank Digital Currency System → Seller User: Verify the original image R and release funds to the seller user;

[0215] 11. Central Bank Digital Currency System → Smart Contract Gateway: Funds Arrival Notification;

[0216] 12. Smart Contract Gateway → Virtual Asset Chain: Transferring NFTs to buyer users;

[0217] 13. Virtual Asset Chain → Client: NFT Arrival Notification;

[0218] 14. Display "Transaction Complete";

[0219] 15. The entire process of monitoring the consortium blockchain is recorded.

[0220] It's important to note that in HTLC smart contracts, the preimage (R) refers to a randomly generated, secret numerical value (usually a 256-bit random number), which forms the basis of the hash lock. The technical essence of the preimage R is an unpredictable raw data set (such as a random string or number) generated and kept secret by the buyer during transaction initialization.

[0221] The relationship between the preimage and the hash lock H is that the buyer calculates the hash value of the preimage R to obtain the hash lock H, i.e., H = Hash(R). The hash function typically uses encryption algorithms such as SHA-256 to ensure that deriving R from H is computationally infeasible (i.e., one-way communication). The purpose is to use the preimage R as a "key" to prove that the seller has the right to unlock the contract. Only when the seller submits the correct preimage R, and the on-chain verification of Hash(R) = H is true, will the funds or assets be released.

[0222] In this embodiment, the deep coupling between the operator's RCS message and the contract parameters in the smart contract gateway under the digital RMB system is achieved. For example, the RCS message directly carries HTLC contract parameters using structured JSON instructions. This allows for the fusion of messages and contracts at the protocol layer and can be automated through smart contracts. The digital RMB system can automatically parse the fields in the RCS message to generate HTLC contracts, realizing "message as contract". Moreover, the MaaP platform can pass transaction requests to the digital RMB system through standard interfaces, bypassing traditional payment gateways and thus enabling a gateway pass-through mechanism.

[0223] Furthermore, it can solve the technical problem of third-party payment relying on soft certificates, which makes it vulnerable to Trojan theft. Through a dual identity binding mechanism of three-factor real-name registration + SIM card national cryptographic SM2 signature, for example, using national cryptographic SM2 + CC EAL6 + security chip, through physical anti-cracking, it can make transactions have anti-counterfeiting capabilities and compliance advantages, meeting the requirements of the "Technical Specification for Protection of Personal Financial Information" and the traceable real-name token and signature correspondence of the central bank's regulatory alliance chain.

[0224] Moreover, the embedded regulatory architecture, which records the entire communication-payment-regulation chain logs on the blockchain in real time, makes transactions transparent, allows real-name tokens and mobile phone numbers to penetrate supervision, blocks risky transactions in real time through stream processing, and integrates communication, payment and asset flows, ensuring a complete audit chain.

[0225] In addition, a complete "intent-payment-delivery" closed loop can be achieved through RCS messages, thereby enabling an immersive metaverse payment closed loop without having to switch to metaverse applications.

[0226] The embodiments of this application have significant commercial value.

[0227] It enables users to achieve immersive payment experiences, enhancing user experience and improving user retention. Its convenient deployment allows for faster and easier platform integration, enabling the import of more businesses and driving continuous expansion of market boundaries.

[0228] For example, for operators: it can provide new business models for 5G messaging;

[0229] For the Metaverse platform: it can lower the payment threshold, improve retention, and increase the next-day retention rate by approximately 6%;

[0230] For the central bank: It can enable the rapid implementation of digital RMB scenarios.

[0231] See Figure 8 , Figure 8 This is one of the structural schematic diagrams of a payment processing device provided in the embodiments of this application, which is applied to a payment service platform, such as... Figure 8 As shown, the payment processing device 800 includes:

[0232] The first receiving module 801 is used to receive a payment message sent by the client, the payment message including: transaction data of the buyer user for virtual assets of the Metaverse application;

[0233] The first acquisition module 802 is used to acquire the identity information of the buyer user based on the communication service identifier of the payment message source;

[0234] The first generation module 803 is used to generate the real-name token of the buyer user based on the identity information;

[0235] The first sending module 804 is used to send a transaction request to the smart contract gateway. The transaction request includes the real-name token of the buyer user and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

[0236] Optionally, the client further deploys a user identification module, and the payment message further includes: signature information of the transaction data, the signature information being obtained by the user identification module signing the transaction data, and the first sending module 804 is specifically used for:

[0237] If the signature information is verified, the transaction request is sent to the smart contract gateway.

[0238] Optionally, the device further includes:

[0239] The third sending module is used to send the first key information from the transaction data to the regulatory system for storage; wherein...

[0240] The first key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

[0241] Optionally, the payment message is a Rich Media Communication Service (RCS) message, which includes structured field data generated based on the transaction data.

[0242] The payment processing device 800 can implement all the processes implemented in the above-mentioned payment service platform-side payment processing method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0243] See Figure 9 , Figure 9 This is a second structural schematic diagram of a payment processing device provided in an embodiment of this application, applied to a smart contract gateway, such as... Figure 9 As shown, the payment processing device 900 includes:

[0244] The second receiving module 901 is used to receive a transaction request sent by the payment service platform. The transaction request includes the real-name token of the buyer user and the transaction data of the buyer user's virtual assets for the Metaverse application.

[0245] The second generation module 902 is used to generate a smart contract instance by calling the smart contract template library based on the real-name token of the buyer user and the transaction data.

[0246] Trigger module 903 is used to call the smart contract instance to execute the virtual asset transaction of the metaverse application.

[0247] Optionally, the trigger module 903 is specifically used for:

[0248] The smart contract instance is invoked to lock the digital assets of the buyer in the digital currency system and the virtual assets of the seller in the virtual asset system of the metaverse application.

[0249] If the buyer's digital assets and the seller's virtual assets are locked, and the asset withdrawal certificate submitted by the seller is verified, the transfer of the locked buyer's digital assets to the seller and the transfer of the locked seller's virtual assets to the buyer are triggered.

[0250] Optionally, the trigger module 903 is specifically used for:

[0251] The smart contract instance is invoked to generate contract deployment instructions and asset lock requests;

[0252] The contract deployment instruction and the asset lock request are sent to the digital currency system. The contract deployment instruction is used by the digital currency system to deploy the transaction contract address, and the asset lock request is used by the digital currency system to lock the buyer's digital assets according to the transaction contract address.

[0253] Optionally, the smart contract instance is a hash time lock contract, and the device further includes:

[0254] The third acquisition module is used to acquire the preimage of the hash lock submitted by the seller user, and the preimage is the asset extraction certificate;

[0255] A hash operation module is used to perform a hash operation on the preimage to obtain the hash value of the preimage;

[0256] The determination module is used to determine that the asset withdrawal certificate submitted by the seller user has been verified if the hash value of the preimage is equal to the hash value of the hash lock in the hash time lock contract.

[0257] Optionally, the device further includes:

[0258] The update module is used to update the contract parameters in the smart contract instance based on the execution status of the digital currency system and the virtual asset system during the execution of virtual asset transactions; wherein,

[0259] The contract parameters are generated based on the buyer user's real-name token and structured field data, which in turn are generated based on the transaction data.

[0260] Optionally, the device further includes:

[0261] The fourth sending module is used to send the second key information instructing the locking of digital assets in the metaverse application to the monitoring system for storage; wherein,

[0262] The second key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

[0263] The payment processing device 900 can implement all the processes implemented in the above-described smart contract gateway-side payment processing method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0264] See Figure 10 , Figure 10 This is a third schematic diagram of a payment processing device provided in this application embodiment, applied to a client, such as... Figure 10 As shown, the payment processing device 1000 includes:

[0265] The second acquisition module 1001 is used to acquire transaction data of virtual assets of the buyer user for the Metaverse application;

[0266] The encapsulation module 1002 is used to encapsulate the transaction data into a payment message, wherein the payment message is an RCS message and the RCS message includes structured field data generated based on the transaction data.

[0267] The second sending module 1003 is used to send the payment message to the payment service platform, and the payment message is used to request the virtual asset transaction of the metaverse application.

[0268] Optionally, the client also deploys a user identification module, and the device further includes:

[0269] The signature module is used to sign the transaction data through the user identification module to obtain the signature information of the transaction data;

[0270] The encapsulation module 1002 is specifically used to encapsulate the signature information and the transaction data into a payment message.

[0271] The payment processing device 1000 can implement all the processes implemented in the above-described client-side payment processing method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0272] See Figure 11 The figure shows a schematic diagram of the structure of a payment service platform provided in an embodiment of the present invention. Figure 11 As shown, the client 1100 includes: a first processor 1101, a first memory 1102, a first user interface 1103, and a first bus interface 1104.

[0273] The first processor 1101 is used to read the program from the first memory 1102 and execute the following procedures:

[0274] Receive payment messages sent by the client, the payment messages including: transaction data of the buyer user for virtual assets in the Metaverse application;

[0275] Based on the communication service identifier of the payment message source, obtain the identity information of the buyer user;

[0276] Based on the identity information, a real-name token for the buyer user is generated;

[0277] A transaction request is sent to the smart contract gateway. The transaction request includes the buyer's real-name token and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

[0278] exist Figure 11In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by the first processor 1101 and the memory represented by the first memory 1102. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The first bus interface 1104 provides an interface. For different devices, the first user interface 1103 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0279] The first processor 1101 is responsible for managing the bus architecture and general processing, and the first memory 1102 can store the data used by the first processor 1101 when performing operations.

[0280] In some embodiments, the client further deploys a user identification module, and the payment message further includes: signature information of the transaction data, the signature information being obtained by the user identification module signing the transaction data; the first processor 1101 is further configured to:

[0281] If the signature information is verified, the transaction request is sent to the smart contract gateway.

[0282] In some embodiments, the first processor 1101 is further configured to:

[0283] The first key information from the transaction data is sent to the regulatory system for storage; wherein...

[0284] The first key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

[0285] In some embodiments, the payment message is a Rich Communication Service (RCS) message, which includes structured field data generated based on the transaction data.

[0286] Preferably, this embodiment of the invention also provides a payment service platform 1100, including a first processor 1101, a first memory 1102, and a computer program stored in the first memory 1102 and executable on the first processor 1101. When the computer program is executed by the first processor 1101, it implements the various processes of the payment processing method embodiment on the payment service platform side described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0287] See Figure 12 The figure shows a schematic diagram of the structure of a smart contract gateway provided in an embodiment of the present invention. Figure 12As shown, the smart contract gateway 1200 includes: a second processor 1201, a second memory 1202, a second user interface 1203, and a second bus interface 1204.

[0288] The second processor 1201 is used to read the program from the second memory 1202 and execute the following procedures:

[0289] Receive a transaction request sent by a payment service platform, the transaction request including the buyer's real-name token and the buyer's transaction data for virtual assets in the Metaverse application;

[0290] Based on the buyer's real-name token and the transaction data, a smart contract instance is generated by calling the smart contract template library;

[0291] The smart contract instance is invoked to execute the virtual asset transaction of the metaverse application.

[0292] exist Figure 12 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by the second processor 1201 and the memory represented by the second memory 1202 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The second bus interface 1204 provides an interface. For different devices, the second user interface 1203 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0293] The second processor 1201 is responsible for managing the bus architecture and general processing, while the second memory 1202 can store the data used by the second processor 1201 when performing operations.

[0294] In some embodiments, the second processor 1201 is further configured to:

[0295] The smart contract instance is invoked to lock the digital assets of the buyer in the digital currency system and the virtual assets of the seller in the virtual asset system of the metaverse application.

[0296] If the buyer's digital assets and the seller's virtual assets are locked, and the asset withdrawal certificate submitted by the seller is verified, the transfer of the locked buyer's digital assets to the seller and the transfer of the locked seller's virtual assets to the buyer are triggered.

[0297] Optionally, the second processor 1201 is also used for:

[0298] The smart contract instance is invoked to generate contract deployment instructions and asset lock requests;

[0299] The contract deployment instruction and the asset lock request are sent to the digital currency system. The contract deployment instruction is used by the digital currency system to deploy the transaction contract address, and the asset lock request is used by the digital currency system to lock the buyer's digital assets according to the transaction contract address.

[0300] Optionally, the smart contract instance is a hash time lock contract, and the second processor 1201 is further used for:

[0301] Obtain the preimage of the hash lock submitted by the seller user, where the preimage is the asset withdrawal certificate;

[0302] Perform a hash operation on the preimage to obtain the hash value of the preimage;

[0303] If the hash value of the preimage is equal to the hash value of the hash lock in the hash time lock contract, the asset withdrawal certificate submitted by the seller user is deemed to have passed verification.

[0304] Optionally, the second processor 1201 is also used for:

[0305] During the execution of virtual asset transactions, the contract parameters in the smart contract instance are updated based on the execution status of the digital currency system and the virtual asset system; wherein,

[0306] The contract parameters are generated based on the buyer user's real-name token and structured field data, which in turn are generated based on the transaction data.

[0307] Optionally, the method further includes:

[0308] The second key information instructing the locking of digital assets in the metaverse application will be sent to the monitoring system for storage; wherein...

[0309] The second key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

[0310] Preferably, the present invention also provides a smart contract gateway 1200, including a second processor 1201, a second memory 1202, and a computer program stored in the second memory 1202 and executable on the second processor 1201. When the computer program is executed by the second processor 1201, it implements the various processes of the above-described smart contract gateway-side payment processing method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0311] See Figure 13The figure shows a schematic diagram of the client structure provided in an embodiment of the present invention. Figure 13 As shown, the client unit 1300 includes: a third processor 1301, a third memory 1302, a third user interface 1303, and a third bus interface 1304.

[0312] The third processor 1301 is used to read the program from the third memory 1302 and execute the following procedures:

[0313] Obtain transaction data of virtual assets held by the buyer user in the Metaverse application;

[0314] The transaction data is encapsulated into a payment message, which is an RCS message, and the RCS message includes structured field data generated based on the transaction data;

[0315] The payment message is sent to the payment service platform, and the payment message is used to request the virtual asset transaction of the metaverse application.

[0316] exist Figure 13 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by the third processor 1301 and the memory represented by the third memory 1302. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The third bus interface 1304 provides an interface. For different user devices, the third user interface 1303 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0317] The third processor 1301 is responsible for managing the bus architecture and general processing, while the third memory 1302 can store the data used by the third processor 1301 when performing operations.

[0318] In some embodiments, the third processor 1301 is further configured to:

[0319] The user identification module signs the transaction data to obtain the signature information of the transaction data;

[0320] The signature information and the transaction data are encapsulated into a payment message.

[0321] Preferably, the present invention also provides a client 1300, including a third processor 1301, a third memory 1302, and a computer program stored in the third memory 1302 and executable on the third processor 1301. When the computer program is executed by the third processor 1301, it implements the various processes of the above-described client-side payment processing method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0322] This invention also provides a readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the payment processing methods described above for the payment service platform, smart contract gateway, or client side, achieving the same technical effects. To avoid repetition, these processes will not be elaborated upon here. The readable storage medium may be, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0323] This application also provides a computer program product, including computer instructions. When executed by a processor, these computer instructions implement the various processes of the payment processing method embodiments described above for the payment service platform side, smart contract gateway side, or client side, and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0324] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0325] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0326] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0327] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0328] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0329] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0330] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A payment processing method, characterized in that, Applied to a payment service platform, the method includes: Receive payment messages sent by the client, the payment messages including: transaction data of the buyer user for virtual assets in the Metaverse application; Based on the communication service identifier of the payment message source, obtain the identity information of the buyer user; Based on the identity information, a real-name token for the buyer user is generated; A transaction request is sent to the smart contract gateway. The transaction request includes the buyer's real-name token and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

2. The method according to claim 1, characterized in that, The client also deploys a user identification module, and the payment message further includes: signature information of the transaction data, wherein the signature information is obtained by the user identification module signing the transaction data, and sending the transaction request to the smart contract gateway includes: If the signature information is verified, the transaction request is sent to the smart contract gateway.

3. The method according to claim 1, characterized in that, After sending the transaction request to the smart contract gateway, the method further includes: The first key information from the transaction data is sent to the regulatory system for storage; wherein... The first key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

4. The method according to any one of claims 1 to 3, characterized in that, The payment message is a Rich Communication Service (RCS) message, which includes structured field data generated based on the transaction data.

5. A payment processing method, characterized in that, Applied to a smart contract gateway, the method includes: Receive a transaction request sent by a payment service platform, the transaction request including the buyer's real-name token and the buyer's transaction data for virtual assets in the Metaverse application; Based on the buyer's real-name token and the transaction data, a smart contract instance is generated by calling the smart contract template library; The smart contract instance is invoked to execute the virtual asset transaction of the metaverse application.

6. The method according to claim 5, characterized in that, The invocation of the smart contract instance to execute the virtual asset transaction of the metaverse application includes: The smart contract instance is invoked to lock the digital assets of the buyer in the digital currency system and the virtual assets of the seller in the virtual asset system of the metaverse application. If the buyer's digital assets and the seller's virtual assets are locked, and the asset withdrawal certificate submitted by the seller is verified, the transfer of the locked buyer's digital assets to the seller and the transfer of the locked seller's virtual assets to the buyer are triggered.

7. The method according to claim 6, characterized in that, Invoking the smart contract instance locks the digital assets of the buyer user in the cryptocurrency system, including: The smart contract instance is invoked to generate contract deployment instructions and asset lock requests; The contract deployment instruction and the asset lock request are sent to the digital currency system. The contract deployment instruction is used by the digital currency system to deploy the transaction contract address, and the asset lock request is used by the digital currency system to lock the buyer's digital assets according to the transaction contract address.

8. The method according to claim 6, characterized in that, The smart contract instance is a hash time lock contract. Before triggering the transfer of the locked digital assets of the buyer user to the seller user, and before triggering the transfer of the locked virtual assets of the seller user to the buyer user, the method further includes: Obtain the preimage of the hash lock submitted by the seller user, where the preimage is the asset withdrawal certificate; Perform a hash operation on the preimage to obtain the hash value of the preimage; If the hash value of the preimage is equal to the hash value of the hash lock in the hash time lock contract, the asset withdrawal certificate submitted by the seller user is deemed to have passed verification.

9. The method according to claim 5, characterized in that, After invoking the smart contract instance to execute the virtual asset transaction of the metaverse application, the method further includes: During the execution of virtual asset transactions, the contract parameters in the smart contract instance are updated based on the execution status of the digital currency system and the virtual asset system; wherein, The contract parameters are generated based on the buyer user's real-name token and structured field data, which in turn are generated based on the transaction data.

10. The method according to any one of claims 5 to 9, characterized in that, After invoking the smart contract instance to execute the virtual asset transaction of the metaverse application, the method further includes: The second key information instructing the locking of digital assets in the metaverse application will be sent to the monitoring system for storage; wherein... The second key information includes the transaction hash of the transaction data and the real-name token of the buyer user.

11. A payment processing method, characterized in that, Applied to a client that has a metaverse application deployed thereon, the method includes: Obtain transaction data of virtual assets held by the buyer user in the Metaverse application; The transaction data is encapsulated into a payment message, which is an RCS message, and the RCS message includes structured field data generated based on the transaction data; The payment message is sent to the payment service platform, and the payment message is used to request the virtual asset transaction of the metaverse application.

12. The method according to claim 11, characterized in that, The client also deploys a user identification module, and before encapsulating the transaction data into a payment message, the method further includes: The user identification module signs the transaction data to obtain the signature information of the transaction data; The step of encapsulating the transaction data into a payment message includes: The signature information and the transaction data are encapsulated into a payment message.

13. A payment processing device, characterized in that, The device, used in a payment service platform, includes: The first receiving module is used to receive payment messages sent by the client, the payment messages including: transaction data of virtual assets of the buyer user for the Metaverse application; The first acquisition module is used to acquire the identity information of the buyer user based on the communication service identifier of the payment message source; The first generation module is used to generate the real-name token of the buyer user based on the identity information; The first sending module is used to send a transaction request to the smart contract gateway. The transaction request includes the real-name token of the buyer user and the transaction data. The transaction request is used to execute the virtual asset transaction of the metaverse application.

14. A payment processing device, characterized in that, The device, used in a smart contract gateway, includes: The second receiving module is used to receive transaction requests sent by the payment service platform. The transaction requests include the buyer's real-name token and the buyer's transaction data for virtual assets in the Metaverse application. The second generation module is used to generate a smart contract instance by calling the smart contract template library based on the real-name token of the buyer user and the transaction data. The trigger module is used to invoke the smart contract instance to execute the virtual asset transaction of the metaverse application.

15. A payment processing device, characterized in that, Applied to a client, the device includes: The second acquisition module is used to acquire transaction data of virtual assets of the buyer user for the Metaverse application; An encapsulation module is used to encapsulate the transaction data into a payment message, wherein the payment message is an RCS message, and the RCS message includes structured field data generated based on the transaction data; The second sending module is used to send the payment message to the payment service platform, and the payment message is used to request the virtual asset transaction of the metaverse application.

16. A payment service platform, characterized in that, include: A first processor, a first memory, and a program stored in the first memory and executable on the first processor, wherein the program, when executed by the first processor, implements the steps of the payment processing method as described in any one of claims 1 to 4.

17. A smart contract gateway, characterized in that, include: A second processor, a second memory, and a program stored in the second memory and executable on the second processor, wherein the program, when executed by the second processor, implements the steps of the payment processing method as described in any one of claims 5 to 10.

18. A client application, characterized in that, include: A third processor, a third memory, and a program stored in the third memory and executable on the third processor, wherein the program, when executed by the third processor, implements the steps of the payment processing method as described in any one of claims 11 to 12.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the payment processing method as described in any one of claims 1 to 12.

20. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the payment processing method as described in any one of claims 1 to 12.

Images